Skip to main content

Specification of the Protocol for IPFIX Mediation
draft-ietf-ipfix-mediation-protocol-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7119.
Authors Benoît Claise , Atsushi Kobayashi , Brian Trammell
Last updated 2011-12-06
Replaces draft-claise-ipfix-mediation-protocol
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7119 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ipfix-mediation-protocol-00
IPFIX Working Group                                    B. Claise 
     Internet-Draft                               Cisco Systems, Inc. 
     Intended Status: Standards Track                    A. Kobayashi 
     Expires: June 5, 2012                                NTT PF Lab. 
                                                          B. Trammell 
                                                           ETH Zurich   
                                                     December 5, 2011 
                                                                      
      
            Specification of the Protocol for IPFIX Mediation 
                  draft-ietf-ipfix-mediation-protocol-00 

     Abstract 

        This document specifies the IP Flow Information Export 
        (IPFIX) protocol specific to Mediation. 
         
     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79.  
         
        Internet-Drafts are working documents of the Internet 
        Engineering Task Force (IETF), its areas, and its working 
        groups.  Note that other groups may also distribute working 
        documents as Internet-Drafts.  
         
        Internet-Drafts are draft documents valid for a maximum of six 
        months and may be updated, replaced, or obsoleted by other 
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as "work 
        in progress."  
         
        The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt  
         
        The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html  
         
        This Internet-Draft will expire on April, 2011. 
         
         
     Copyright Notice 
      
        Copyright (c) 2011 IETF Trust and the persons identified as the 
        document authors.  All rights reserved. 
         
        This document is subject to BCP 78 and the IETF Trust's Legal 
        Provisions Relating to IETF Documents 
        (http://trustee.ietf.org/license-info) in effect on the date of 
        publication of this document.  Please review these documents 
      

     <Claise, et. Al>         Expires June 5 2012             [Page 1] 

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        carefully, as they describe your rights and restrictions with 
        respect to this document.  Code Components extracted from this 
        document must include Simplified BSD License text as described 
        in Section 4.e of the Trust Legal Provisions and are provided 
        without warranty as described in the Simplified BSD License. 
         
         
     Conventions used in this document 

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
        and "OPTIONAL" in this document are to be interpreted as 
        described in RFC 2119 [RFC2119]. 
      

     Table of Contents 

         
        1. Introduction............................................. 4 
           1.1. IPFIX Documents Overview............................ 5 
           1.2. IPFIX Mediator Documents Overview................... 5 
           1.3. Relationship with IPFIX and PSAMP................... 7 
        2. Terminology.............................................. 7 
        3. Specifications.......................................... 10 
           3.1. Encoding of IPFIX Message Header................... 11 
           3.2. Template Management................................ 13 
              3.2.1. Template Management Without Template Records 
              Change............................................... 13 
              3.2.2. Template Management With New Template Records. 16 
           3.3. Time Management.................................... 20 
           3.4. Observation Point Management....................... 21 
              3.4.1. Observation Domain Management................. 23 
           3.5. Specific Reporting Requirements.................... 24 
              3.5.1. The Flow Keys Options Template................ 24 
              3.5.2. IPFIX Protocol Options Template............... 25 
              3.5.3. IPFIX Mediator Options Template............... 25 
           3.6. The Collecting Process's Side...................... 26 
           3.7. Configuration Management........................... 26 
        4. New Information Elements................................ 26 
        5. Security Considerations................................. 27 
        6. IANA Considerations..................................... 27 
           6.1. originalExporterIPv4Address........................ 28 
           6.2. originalExporterIPv6Address........................ 28 
           6.3. originalObservationDomainId........................ 28 
        7. References.............................................. 29 
           7.1. Normative References............................... 29 
           7.2. Informative References............................. 30 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 2] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        8. Author's Addresses...................................... 31 
        Appendix A.  Additions to XML Specification of IPFIX 
        Information Elements....................................... 32 
         
         
        TO DO: 
        - Change the reference from RFC5102 to RFC5102bis, or should we 
          list IANA? 
        - There are still changes in RFC5101bis that must be integrated 
          here. Example: Template withdrawal and template life time 
        - Definition change proposal for the Intermediate Process, 
          Intermediate Conversion Process, Intermediate Selection 
          Process, Intermediate Anonymization Process, and IPFIX 
          Mediator.  See http://www.ietf.org/mail-
          archive/web/ipfix/current/msg05969.html. However, the 
          definitions are copied over verbatim from RFC6183. Also note 
          that Intermediate Anonymization Process in this document is 
          not in line with the RFC6235. 
        - "the IPFIX Mediator MAY keep the export time received from 
          the incoming Transport Session", and " Therefore, as there is 
          not a single rule that fits all different situations, the 
          precise rules of applying the Flow Record timestamps in IPFIX 
          Mediators is out of the scope of this document." Do we need 
          something more specific? 
        - Agree upon "Practically, the Original Exporters will not 
          exporting these Information Elements. Therefore, the 
          Intermediate Process SHOULD report the Original Observation 
          Point(s) to the best of its knowledge.  Note that the 
          Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] may 
          help." 
        - What Paul Aikten would like to see in section 3.5: 
             What about IE ordering? May an exporter re-order received 
             fields? eg, two devices sending the same information, 
             though with the fields in a different order. Or the 
             mediator is extracting the same information from two 
             sources. That seems to be a valid scenario. eg, this 
             reduces the number of templates received at the collector. 
              
             What about temporal re-ordering? How should a mediator deal 
             with out-of-order data coming from multiple devices? It 
             can't expect all received data to be in time order. 
              
             What should a mediator do with a field which it doesn't 
             know/understand? Inevitably, exporters will be updated 
             without mediators keeping in step. It's also very likely 
             that mediators will see Enterprise-specific IEs. May a 
             mediator re-export unknown IEs unchanged, or should it drop 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 3] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

             them? Presumably a mediator may report received Enterprise-
             specific IEs even from multiple different Enterprises. 
              
             What if an unknown field depends on the field ordering? eg, 
             it's a bitfield like flowKeyIndicator. Re-ordering, adding 
             or removing fields breaks the meaning of this field, so it 
             can't be passed on. It can only be used if the received 
             fields are reported unchanged. 
         
         
         
     1. Introduction 

        The IPFIX architectural components in [RFC5470] consist of 
        IPFIX Devices and IPFIX Collectors communicating using the 
        IPFIX protocol [RFC5101bis], which specifies how to export IP 
        Flow information.  This protocol is designed to export 
        information about IP traffic Flows and related measurement 
        data, where a Flow is defined by a set of key attributes 
        (e.g. source and destination IP address, source and 
        destination port, etc.).  
         
        However, thanks to its Template mechanism, the IPFIX protocol 
        can export any type of information, as long as the relevant 
        Information Element is specified in the IPFIX Information 
        Model [RFC5102], registered with IANA, or specified as an 
        enterprise-specific Information Element.  The specifications 
        in the IPFIX protocol [RFC5101bis] have not been defined in 
        the context of an IPFIX Mediator receiving, aggregating, 
        correlating, anonymizing, etc... Flow Records from the one or 
        multiple Exporters.  Indeed, the IPFIX protocol must be 
        adapted for Intermediate Processes, as defined in the IPFIX 
        Mediation Reference Model as specified in Figure A of [IPFIX-
        MED-FMWK], which is based on the IPFIX Mediation Problem 
        Statement [RFC5982]. 
         
        This document specifies the IP Flow Information Export 
        (IPFIX) protocol in the context of the implementation and 
        deployment of IPFIX Mediators.  The use of the IPFIX 
        protocol within a Mediator -- a device which contains both 
        as a Collecting Process and an Exporting Process -- has an 
        impact on the technical details of the usage of the 
        protocol.  An overview of the technical problem is covered 
        in section 6 of [RFC5982]: loss of original exporter 
        information, loss of base time information, transport 
        sessions management, loss of Options Template Information, 
        Template Id management, considerations for network 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 4] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        topology, IPFIX Mediation interpretation, and 
        considerations for aggregation. 
         
        The specifications in this document are based on the IPFIX 
        protocol specifications [RFC5101bis] but adapted according 
        to the IPFIX Mediation Framework [IPFIX-MED-FMWK]. 
      
      
     1.1. IPFIX Documents Overview 

        The IPFIX Protocol [RFC5101bis] provides network 
        administrators with access to IP Flow information. 
         
        The architecture for the export of measured IP Flow 
        information out of an IPFIX Exporting Process to a Collecting 
        Process is defined in the IPFIX Architecture [RFC5470], per 
        the requirements defined in the IPFIX Requirement doc,  
        [RFC3917]. 
         
        The IPFIX Architecture [RFC5470] specifies how IPFIX Data 
        Records and Templates are carried via a congestion-aware 
        transport protocol from IPFIX Exporting Processes to IPFIX 
        Collecting Processes. 
         
        IPFIX has a formal description of IPFIX Information Elements, 
        their name, type and additional semantic information, as 
        specified in the IPFIX Information Model [RFC5102].   
         
        The IPFIX Applicability Statement [RFC5472] describes what 
        type of applications can use the IPFIX protocol and how they 
        can use the information provided.  It furthermore shows how 
        the IPFIX framework relates to other architectures and 
        frameworks.  
         
        "IPFIX Mediation: Problem Statement" [RFC5982], describing the 
        IPFIX Mediation applicability examples, along with some problems 
        that network administrators have been facing, is the basis for 
        the "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].  This 
        framework details the IPFIX Mediation reference model and the 
        components of an IPFIX Mediator. 
              
      
     1.2. IPFIX Mediator Documents Overview 

        The "IPFIX Mediation: Problem Statement" [RFC5982] provides an 
        overview of the applicability of Mediators, and defines 
        requirements for Mediators in general terms.  This document is 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 5] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        of use largely to define the problems to be solved through the 
        deployment of IPFIX Mediators, and to provide scope to the role 
        of Mediators within an IPFIX collection infrastructure.   
         
        The "IPFIX Mediation: Framework" [IPFIX-MED-FMWK] provides more 
        architectural details of the arrangement of Intermediate 
        Processes within a Mediator. 
      
        The details of specific Intermediate Processes, when these have 
        additional export specifications (e.g., metadata about the 
        intermediate processing conveyed through IPFIX Options 
        Templates), are each treated in their own document (e.g., the 
        "IP Flow Anonymization Support" [RFC6235]).  Documents 
        specifying the operations of specific Intermediate Processes 
        cover the operation of these Processes within the Mediator 
        framework, and comply with the specifications given in this 
        document; they may additionally specify the operation of the 
        process independently, outside the context of a Mediator, when 
        this is appropriate.  As of today, these documents are:  
         
        1. "IP Flow Anonymization Support", [RFC6235], which describes 
        Anonymization techniques for IP flow data and the export of 
        Anonymized data using the IPFIX protocol.  
         
        2. "Flow Selection Techniques" [IPFIX-MED-FLOWSEL], which 
        describes the process of selecting a subset of flows from all 
        flows observed at an observation point, the flow selection 
        motivations, and some specific flow selection techniques. 
         
        3. "Exporting Aggregated Flow Data using the IP Flow Information 
        Export" [IPFIX-MED-AGGR] which describes Aggregated Flow export 
        within the framework of IPFIX Mediators and defines an 
        interoperable, implementation-independent method for Aggregated 
        Flow export. 
         
        This document specifies the IP Flow Information Export 
        (IPFIX) protocol specific to Mediation, i.e. the 
        specifications that all Intermediate Processes type must 
        comply to.  Some extra specifications might be required per 
        Intermediate Process type (In which case, the Intermediate 
        Process specific document would cover those). 
         
         
         

      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 6] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

     1.3. Relationship with IPFIX and PSAMP 

        The specification in this document applies to the IPFIX 
        protocol specifications [RFC5101bis].  All specifications 
        from [RFC5101bis] apply unless specified otherwise in this 
        document. 
      
        As the Packet Sampling (PSAMP) protocol specifications 
        [RFC5476] are based on the IPFIX protocol specifications, the 
        specifications in this document are also valid for the PSAMP 
        protocol.  Therefore, the method specified by this document 
        also applies to PSAMP. 
         
         
     2. Terminology 

        The IPFIX-specific terms, such as Observation Domain, Flow, Flow 
        Key, Metering Process, Exporting Process, Exporter, IPFIX 
        Device, Collecting Process, Collector, Template, IPFIX Message, 
        Message Header, Template Record, Data Record, Options Template 
        Record, Set, Data Set, Information Element, and Transport 
        Session, used in this document are defined in [RFC5101bis].  
        The PSAMP-specific terms used in this document, such as 
        Filtering and Sampling are defined in [RFC5476].  
         
        The IPFIX Mediation terms related to the aggregation, such as 
        the Interval, Aggregated Flow, and Aggregated Function are 
        defined in [IPFIX-MED-AGGR]. 
         
        The IPFIX Mediation-specific terminology used in this document 
        is defined in "IPFIX Mediation: Problem Statement" [RFC5982], 
        and reused in "IPFIX Mediation: Framework" [IPFIX-MED-FMWK].  
        However, since both of those documents are an informational 
        RFCs, the definitions have been reproduced here along with 
        additional definitions.   
         
        Similarly, since [RFC6235] is an experimental RFC, the 
        Anonymization Record, Anonymized Data Record, and Intermediate 
        Anonymization Process terms, specified in [RFC6235], are also 
        reproduced here. 
      
        In this document, as in [RFC5101bis], [RFC5476], [IPFIX-MED-
        AGGR], and [RFC6235], the first letter of each IPFIX-specific 
        and PSAMP-specific term is capitalized along with the IPFIX 
        Mediation-specific term defined here.  In this document, we call 
        a stream of records carrying flow- or packet-based information a 

      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 7] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        "record stream".  The records may be encoded as IPFIX Data 
        Records of any other format. 
         
        Transport Session Information 
         
         The Transport Session is specified in [RFC5101bis].  In SCTP, 
         the Transport Session Information is the SCTP association.  In 
         TCP and UDP, the Transport Session Information corresponds to 
         a 5-tuple {Exporter IP address, Collector IP address, Exporter 
         transport port, Collector transport port, transport protocol}. 
         
        Original Exporter 
         
          An Original Exporter is an IPFIX Device that hosts the  
          Observation Points where the metered IP packets are observed. 
           
        Original Observation Point 
         
         An Observation Point of the Original Exporter.  In the case of 
         the Intermediate Aggregation Process on an IPFIX Mediator, the 
         Original Observation Point can be composed of, but not limited 
         to, a (set of) specific exporter(s), a (set of) specific 
         interface(s) on an Exporter, a (set of) line card(s) on an 
         Exporter, or any combinations of these. 
      
        IPFIX Mediation 
         
          IPFIX Mediation is the manipulation and conversion of a record 
          stream for subsequent export using the IPFIX protocol. 
         
        The following terms are used in this document to describe the 
        architectural entities used by IPFIX Mediation. 
         
        Intermediate Process 
         
          An Intermediate Process takes a record stream as its input 
          from Collecting Processes, Metering Processes, IPFIX File 
          Readers, other Intermediate Processes, or other record 
          sources; performs some transformations on this stream, based 
          upon the content of each record, states maintained across 
          multiple records, or other data sources; and passes the 
          transformed record stream as its output to Exporting 
          Processes, IPFIX File Writers, or other Intermediate 
          Processes, in order to perform IPFIX Mediation. Typically, an 
          Intermediate Process is hosted by an IPFIX Mediator. 
          Alternatively, an Intermediate Process may be hosted by an 
          Original Exporter. 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 8] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

           
        IPFIX Mediator 
         
          An IPFIX Mediator is an IPFIX Device that provides IPFIX 
          Mediation by receiving a record stream from some data sources, 
          hosting one or more Intermediate Processes to transform that 
          stream, and exporting the transformed record stream into IPFIX 
          Messages via an Exporting Process.  In the common case, an 
          IPFIX Mediator receives a record stream from a Collecting 
          Process, but it could also receive a record stream from data 
          sources not encoded using IPFIX, e.g., in the case of 
          conversion from the NetFlow V9 protocol [RFC3954] to IPFIX 
          protocol. 
         
        Specific Intermediate Processes are described below.  However, 
        this is not an exhaustive list. 
         
          Intermediate Conversion Process 
           
            An Intermediate Conversion Process is an Intermediate 
            Process that transforms non-IPFIX into IPFIX, or manages the 
            relation among Templates and states of incoming/outgoing 
            Transport Sessions (or equivalent for non IPFIX protocols) 
            in the case of transport protocol conversion (e.g., from UDP 
            to SCTP). 
           
          Intermediate Aggregation Process 
           
            An Intermediate Aggregation Process is an Intermediate 
            Process that aggregates records based upon a set of Flow 
            Keys or functions applied to fields from the record (e.g., 
            binning and subnet aggregation). 
           
          Intermediate Correlation Process 
           
            An Intermediate Correlation Process is an Intermediate 
            Process that adds information to records, noting 
            correlations among them, or generates new records with 
            correlated data from multiple records (e.g., the production 
            of bidirectional flow records from unidirectional flow 
            records). 
           
          Intermediate Selection Process 
           
            An Intermediate Selection Process is an Intermediate Process 
            that selects records from a sequence based upon criteria-
            evaluated record values and passes only those records that 
      
      
     <Claise, et. Al>         Expires June 6, 2012             [Page 9] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

            match the criteria (e.g., Filtering only records from a 
            given network to a given Collector). 
           
          Intermediate Anonymization Process 
           
            An Intermediate Anonymization Process is an Intermediate 
            Process that transforms records in order to anonymize them, 
            to protect the identity of the entities described by the 
            records (e.g., by applying prefix-preserving 
            pseudonymization of IP addresses). 
        
          Template Mapping 
           
           A mapping from Template Records and/or Options Template 
           Records received by a Mediator to Template Records and/or 
           Options Template Records sent by that IPFIX Mediator.  Each 
           entry in a Template Mapping is scoped by incoming or 
           outgoing Transport Session and Observation Domain, as with 
           Templates and Options Templates in the IPFIX Protocol. 
             
          Anonymization Record    
           
           A record, defined by the Anonymization Options Template in 
           Section 6.1, that defines the properties of the 
           Anonymization applied to a single Information Element within 
           a single Template or Options Template. 
           
          Anonymized Data Record    
           
           A Data Record within a Data Set containing at least one 
           Information Element with Anonymized values.  The Information 
           Element(s) within the Template or Options Template 
           describing this Data Record SHOULD have a corresponding 
           Anonymization Record. 
      
      
     3. Specifications 

        This section describes the IPFIX specifications for Mediation:   
        more specifically,  specifications for generic Intermediate 
        Processes.  Possible specific Intermediate Processes are: 
        Intermediate Conversion Process, Intermediate Aggregation 
        Process, Intermediate Correlation Process, Intermediate 
        Selection Process, Intermediate Anonymization Process.  
         

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 10] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        For a specific Intermediate Process, the specifications in the 
        following references MUST be followed, on top of the 
        specifications in this document: 
         
          - For the Intermediate Aggregation Process, the 
            specifications in [IPFIX-MED-AGGR] MUST be followed. 
             
          - For the Intermediate Selection Process, the specifications 
            in [IPFIX-MED-FLOWSEL] MUST be followed. 
      
          - For the Intermediate Anonymization Process, the 
            specifications in [RFC6235] should be considered as 
            guidelines as [RFC6235] is an experimental RFC. 
             
       Note that no specific document deals with the Intermediate 
       Conversion Process at the time of this publication.  
        
       These new specifications, which are more specific compared than 
       [RFC5101bis], are described with the key words described in 
       [RFC2119].  
         
     3.1. Encoding of IPFIX Message Header 

        The format of the IPFIX Message Header is shown in Figure A. 
        Note that the format is similar to the IPFIX Message in 
        [RFC5101bis], but some field definitions (for the example, the 
        Export Time) have been updated in the context of the IPFIX 
        Mediator.  
         

       0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |       Version Number          |            Length             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                           Export Time                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Sequence Number                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                    Observation Domain ID                      | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
         

                      Figure A: IPFIX Message Header format 

         

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 11] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        Message Header Field Descriptions  
         
        Version 

                Version of Flow Record format exported in this message.  
                The value of this field is 0x000a for the current 
                version, incrementing by one the version used in the 
                NetFlow services export version 9 [RFC3954]. 

        Length 

                Total length of the IPFIX Message, measured in octets, 
                including Message Header and Set(s). 

        Export Time 

                Time at which the IPFIX Message Header leaves the 
                Mediator, expressed in seconds since the UNIX epoch of 
                1 January 1970 at 00:00 UTC, encoded as an unsigned 32-
                bit integer.  

        Sequence Number 

                Incremental sequence counter modulo 2^32 of all IPFIX 
                Data Records sent on this PR-SCTP stream from the 
                current Observation Domain by the Exporting Process.  
                Check the specific meaning of this field in the sub-
                sections of section 10 when UDP or TCP is selected as 
                the transport protocol.  This value SHOULD be used by 
                the Collecting Process to identify whether any IPFIX 
                Data Records have been missed.  Template and Options 
                Template Records do not increase the Sequence Number. 
                RFC'S EDITOR: section 10 referred to RFC5101. Now it 
                must be aligned with RFC5101bis 
                 
        Observation Domain ID 

                A 32-bit identifier of the Observation Domain that is 
                locally unique to the Exporting Process.  The Exporting 
                Process uses the Observation Domain ID to uniquely 
                identify to the Collecting Process the Observation 
                Domain that metered the Flows.  It is RECOMMENDED that 
                this identifier is also unique per IPFIX 
                Device.  Collecting Processes SHOULD use the Transport 
                Session and the Observation Domain ID field to separate 
                different export streams originating from the same 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 12] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

                Exporting Process.  The Observation Domain ID SHOULD be 
                0 when no specific Observation Domain ID is relevant for 
                the entire IPFIX Message.  For example, when exporting 
                the Exporting Process Statistics, or in case of 
                hierarchy of Collector when aggregated Data Records are 
                exported.   
                Note: the Observation Domain Management is discussed in 
                section 3.4.1.   
      

     3.2. Template Management 

     3.2.1. Template Management Without Template Records Change 

        The first case is a situation where the IPFIX Mediator doesn't 
        modify the (Options) Template Record(s) content.  A typical 
        example is an Intermediate Selection Process acting as 
        distributor, which collects Flow Records from one or more 
        Exporters, and based on the Information Elements content, 
        redirects the Flow Records to the appropriate Collector.  This 
        example is a typical case of a single network operation center 
        managing multiple universities: an unique IPFIX Collector 
        collects all Flow Records for the common infrastructure, but 
        might be re-exporting specific university Flow Records to the 
        responsible system administrator. 
         
        As specified in [RFC5101bis], the Template IDs are unique per 
        Exporter, per Transport Session, and per Observation Domain.  As 
        there is no guarantee that, for similar Template Records, the 
        Template IDs received on the incoming Transport Session and 
        exported to the outgoing Transport Session would be same, the 
        IPFIX Mediator MUST maintain a Template Mapping composed of 
        related received and exported (Options) Template Records: 
         
          - for each received (Options) Template Record: Template 
            Record Flow Keys and non Flow Keys, Template ID, 
            Observation Domain Id, and Transport Session Information 
             
          - for each exported (Options) Template Record: Template 
            Record Flow Keys and non Flow Keys, Template ID, Collector, 
            Observation Domain Id, and Transport Session Information 
         
        If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
        (Options) Template Record that is not used anymore in any other  
        Template Mappings, the IPFIX Mediator SHOULD export the 
        appropriate IPFIX Withdrawal Message(s) on the outgoing 

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 13] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        Transport Session, and remove the corresponding entry in the 
        Template Mapping. 
         
        If a (Options) Template Record is not used anymore in an 
        outgoing Transport Session, it MUST be withdrawn with an IPFIX 
        Template Withdrawal Message on that specific outgoing Transport 
        Session, and its entry MUST be removed from the Template 
        Mapping. 
         
        If an incoming or outgoing Transport Session is gracefully 
        shutdown or reset, the (Options) Template Records corresponding 
        to that Transport Session MUST be removed from the Template 
        Mapping.  
         
        For example, Figure B displays an example of an Intermediate 
        Selection Process, re-distributing Data Records to Collectors on 
        the basis of customer networks, i.e. the Route Distinguisher 
        (RD).  In this example, the Template Record received from the 
        Exporter#1 is reused towards Collector#1, Collector#2, and 
        Collector#3.   
      
         
                                         Templ. .---------. 
                                         ID 256 |         | 
                                          .---->|Collector|<==>Customer 
                                          |     |#1       |    #A 
                                          |     |         | 
                                       RD=100:1 '---------' 
        .---------.Templ.  .---------.    | 
        |         |Id      |         |----'     .---------. 
        |         |258     |         | RD=100:2 |         | 
        |IPFIX    |------->|IPFIX    |--------->|Collector|<==>Customer 
        |Exporter |        |Mediator | Templ.   |#2       |    #B 
        |#1       |        |         | ID 257   |         | 
        |         |        |         |----.     '---------' 
        '---------'        '---------'    |  
                                         RD=100:3 
                                    Templ.|     .---------. 
                                    ID    |     |         | 
                                    257   '---->|Collector|<==>Customer 
                                                |#3       |    #C 
                                                |         | 
                                                '---------' 
      
             Figure B: Intermediate Aggregation Process Example 
      
        The following table shows the Template Mapping for the system 
        shown in Figure B. 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 14] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

         
        Template Entry A: 
         Incoming Transport Session Information (from Exporter#1): 
           Source IP: <Exporter#1 export IP address> 
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 258        
           Flow Keys: <series of Flow Keys> 
           Non Flow Keys: <series of non Flow Keys> 
                                                                    
        Template Entry B: 
         Outgoing Transport Session Information (to Collector#1): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#1 IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX)  
         Observation Domain Id: <Observation Domain ID>   
         Template Id: 256    
           Flow Keys: <series of Flow Keys>  
           Non Flow Keys: <series of non Flow Keys> 
                
        Template Entry C: 
         Outgoing Transport Session Information (to Collector#2): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#2 IP address> 
           Protocol: SCTP 
           Source Port: <source port>   
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257 
           Flow Keys: <series of Flow Keys> 
           Non Flow Keys: <series of non Flow Keys> 
                                                                
        Template Entry D: 
         Outgoing Transport Session Information (to Collector#3): 
           Source IP: <IPFIX Mediator IP address> 
           Destination IP: <IPFIX Collector#3 IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 257 
           Flow Keys: <series of Flow Keys> 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 15] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

           Non Flow Keys: <series of non Flow Keys> 
            
        The Template Mapping corresponding to figure B can be displayed 
        as: 
         
           Template Entry A   <----> Template Entry B 
           Template Entry A   <----> Template Entry C 
           Template Entry A   <----> Template Entry D 
            
        Alternatively, the Template Mapping may be optimized as: 
      
                                  +--> Template Entry B  
                                  | 
            Template Entry A   <--+--> Template Entry C  
                                  | 
                                  +--> Template Entry D  
      
        Note that all examples use Transport Sessions based on the SCTP 
        protocol, as simplified use cases.  However, the protocol would 
        be important in situations such as an Intermediate Conversion 
        Process doing transport protocol conversion. 
      
      
     3.2.2. Template Management With New Template Records  

        The second case is a situation where the IPFIX Mediator 
        generates new (Options) Template Records as a result of the 
        Intermediate Process. 
         
        In such a situation, the IPFIX Mediator doesn't need to maintain 
        a Template Mapping, as it generates its own series of (Options) 
        Template Records.  However, the following special case might 
        still require a Template Mapping, i.e. a situation where the 
        IPFIX Mediator, typically containing an Intermediate Conversion 
        Process, Intermediate Aggregation Process [IPFIX-MED-AGGR], or 
        Intermediate Anonymization Process in case of black-marker 
        Anonymization [RFC6235], generates new (Options) Template 
        Records based on what it receives from the Exporter(s), and 
        based on the Intermediate Process function.  In such a case, 
        it's interesting to keep the correlation between the received 
        (Options) Template Records and exported Derived (Options) 
        Template Records in the Template Mapping.  
         
        Therefore, the IPFIX Mediator MAY maintain a Template Mapping  
        composed of received (Options) Template Records and exported 
        derived Options) Template Records: 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 16] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

         
          - for each received (Options) Template Record: Template 
            Record Flow Keys and non Flow Keys, Template ID, 
            Observation Domain, and Transport Session Information 
             
          - for each exported derived Options) Template Record: 
            Template Record Flow Keys and non Flow Keys, Template ID, 
            Collector, Observation Domain, and Transport Session 
            Information 
        
       If an IPFIX Mediator receives an IPFIX Withdrawal Message for a 
       (Options) Template Record that is not used anymore as the basis 
       of an inferred (Options) Template Record(s), the IPFIX Mediator 
       SHOULD export the appropriate IPFIX Withdrawal Message(s) for 
       the inferred (Options) Template Record on the outgoing Transport 
       Session, and remove the corresponding entry in the Template 
       Mapping. 
        
       The following two examples illustrate this.  
        
       First, consider an IPFIX Mediator hosting an Intermediate 
       Aggregation Process that generates time-series traffic octet 
       counts per source IP address (as in the example in section 8.1 
       of [IPFIX-MED-AGGR]).  Here, the Intermediate Process accepts 
       Flow Records fitting any Template, discards all Information 
       Elements other than the sourceIPv[46]Address and 
       octetDeltaCount, aggregates these across all Original Exporters 
       in a given regular time interval, and exports Flow Records 
       according to a Template Record containing 
       flowStartTimeMilliseconds, flowEndTimeMilliseconds, 
       sourceIPv[46]Address, and octetDeltaCount. 
        
       In this case, no Template Mapping is necessary.  New Templates 
       and Template Withdrawals in the Transport Sessions from the 
       Original Exporters are handled as they would be at any 
       Collecting Process.  Records according to Templates which do not 
       contain at least a timestamp, sourceIPv[46]Address, and 
       octetDeltaCount IE are simply discarded by the Collector. 
        
       Next, consider a more generic case of this Intermediate 
       Aggregation Process, which creates time-series aggregates across 
       all Original Exporters, imposing a time interval but keeping a 
       subset of the incoming Flow Key received from the Original 
       Exporter.  In this case, a Template Mapping is necessary, as 
       there is a relationship between incoming and outgoing Templates. 
      
        .--------. tid 256  
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 17] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        |IPFIX   |  
        |Exporter|----+ 
        |#1      |    | 
        '--------'    | 
        .--------.    |          .----------.              .---------. 
        |IPFIX   |    '--------->|          |              |         | 
        |Exporter|-------------->|IPFIX     |------------->|IPFIX    | 
        |#2      | tid 257       |Mediator  |tid 256       |Collector| 
        '--------'    +--------->|          |    257       |         | 
        .--------.    |          '----------'              '---------' 
        |IPFIX   |    | 
        |Exporter|----' 
        |#3      | tid 257  
        '--------' 
      
             Figure C: Intermediate Aggregation Process Example 
      
       In Figure C, above, the Mediator accepts a Template Record 
       containing only the sourceIPv4Address as the Flow Key from 
       Exporters 1 and 2, and a Template Record containing only the 
       destinationIPv4Address as the Flow Key from exporter 3.  It 
       exports time-series source aggregates as Template ID 256, and 
       time-series destination aggregates as Template ID 257. The 
       Template Entries in this case are as follows: 
      
        Template Entry A: 
         Incoming Transport Session Information (from Exporter#1): 
           Source IP: <Exporter#1 export IP address>  
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX)     
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 256      
           Flow Keys: sourceIPv4Address 
           Non Flow Keys: octetDeltaCount, [others]   
                       
        Template Entry B: 
         Incoming Transport Session Information (from Exporter#2): 
           Source IP: <Exporter#2 export IP address> 
           Destination IP: <IPFIX Mediator IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX)  
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257           
           Flow Keys: sourceIPv4Address 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 18] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

           Non Flow Keys: octetDeltaCount, [others]   
                                    
        Template Entry C: 
         Incoming Transport Session Information (from Exporter#3): 
           Source IP: <Exporter#3 export IP address> 
           Destination IP: <IPFIX Mediator IP address>  
           Protocol: SCTP 
           Source Port: <source port>    
           Destination Port: 4739 (IPFIX)   
         Observation Domain Id: <Observation Domain ID> 
         Template Id: 257     
           Flow Keys: destinationIPv4Address     
           Non Flow Keys: octetDeltaCount, [others]      
      
        Template Entry D: 
         Outgoing Transport Session Information (to IPFIX Collector): 
           Source IP: <IPFIX Mediator export IP address> 
           Destination IP: <IPFIX Collector IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 256 
           Flow Keys: sourceIPv4Address 
           Non Flow Keys: octetDeltaCount 
            
        Template Entry E: 
         Outgoing Transport Session Information (to IPFIX Collector): 
           Source IP: <IPFIX Mediator export IP address> 
           Destination IP: <IPFIX Collector IP address> 
           Protocol: SCTP 
           Source Port: <source port> 
           Destination Port: 4739 (IPFIX) 
         Observation Domain Id: <Observation Domain ID> 
           Template Id: 257 
           Flow Keys: destinationIPv4Address 
           Non Flow Keys: octetDeltaCount 
            
        The Template Mapping corresponding to figure C can be displayed 
        as: 
         
           Template Entry A   <----> Template Entry D 
           Template Entry B   <----> Template Entry D 
           Template Entry C   <----> Template Entry E 
      
        Note that all examples use Transport Sessions based on the SCTP 
        protocol, as simplified use cases.  However, the protocol would 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 19] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        be important in situations such as an Intermediate Conversion 
        Process doing transport protocol conversion. 
      
      
     3.3. Time Management 

        The IPFIX Message Header "Export Time" field is the time in 
        seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message 
        leaves the IPFIX Mediator.  However, in the specific case of an 
        IPFIX Mediator containing an Intermediate Conversion Process, 
        the IPFIX Mediator MAY keep the export time received from the 
        incoming Transport Session. 
         
        It is RECOMMENDED that Mediators handle time using absolute 
        timestamps (e.g. flowStartSeconds, flowStartMilliseconds, 
        flowStartNanoseconds), which are specified relative to the UNIX 
        epoch (00:00 UTC 1 Jan 1970), where possible, rather than 
        relative timestamps (e.g. flowStartSysUpTime, 
        flowStartDeltaMicroseconds), which are specified relative to 
        protocol structures such as system initialization or message 
        export time.   
         
        The latter are difficult to manage for two reasons.  First, 
        they require constant translation, as the system 
        initialization time of an intermediate system and the export 
        time of an intermediate message will change across mediation 
        operations.  Further, relative timestamps introduce range 
        problems. For example, when using the 
        flowStartDeltaMicroseconds and flowEndDeltaMicroseconds 
        Information Elements [RFC5102], the Data Record must be 
        exported within a maximum of 71 minutes after its creation.  
        Otherwise, the 32-bit counter would not be sufficient to 
        contain the flow start time offset.  Those time constraints 
        might be incompatible with some of the Intermediate Processes: 
        Intermediate Aggregation Process (temporal) and Intermediate 
        Correlation Process, for example. 
         
        When an Intermediate Aggregation Process aggregates information 
        from different Flow Records, the typical reporting times SHOULD 
        be the minimum of the start times and the maximum of the end 
        times.  However, if the Flow Records do not overlap, i.e. if 
        there is a time gap between the times in the Flow Records, then 
        the report may be inaccurate.  The IPFIX Mediator is only 
        reporting what it knows, on the basis of the information made 
        available to it - and there may not have been any data to 
        observe during the gap.  Then again, if there is an overlap in 
        timestamps, there's the potential of double-accounting: 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 20] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        different Observation Points may have observed the same traffic 
        simultaneously.  Therefore, as there is not a single rule that 
        fits all different situations, a complete specification of the 
        precise rules of applying Flow Record timestamps at IPFIX 
        Mediators is out of the scope of this document.   
         
        Note that [IPFIX-MED-AGGR] provides additional specifications 
        for handling of timestamps at an Intermediate Aggregation 
        Process.  
         
         
     3.4. Observation Point Management 

        Depending on the use case, the Collector in an Exporter-
        Mediator-Collector structure model may need to receive the 
        Original Observation Point(s), otherwise it may wrongly conclude 
        that the IPFIX Device exporting the Flow Records to him, i.e. 
        the IPFIX Mediator, directly observed the packets that generated 
        the Flow Records.  Two new Information Elements are introduced 
        to solve this use case: originalExporterIPv4Address and 
        originalExporterIPv6Address.  Practically, the Original 
        Exporters will not exporting these Information Elements. 
        Therefore, the Intermediate Process SHOULD report the Original 
        Observation Point(s) to the best of its knowledge.  Note that 
        the Configuration Data Model for IPFIX and PSAMP [IPFIX-CONF] 
        may help. 

        In the IPFIX Mediator, the Observation Point(s) may be 
        represented by: 
            - A single Original Exporter (represented by the 
            originalExporterIPv4Address or originalExporterIPv6Address 
            Information Elements) 
            - A list of Original Exporter (represented by the 
            originalExporterIPv4Address or originalExporterIPv6Address 
            Information Elements) 
            - Any combination or list of Information Elements 
            representing Observation Points. For example: 
                o  A list of Original Exporter interface(s) 
                (represented by the originalExporterIPv4Address or 
                originalExporterIPv6Address, the ingressInterface 
                and/or egressInterface Information Elements, 
                respectively)  
                o  A list of Original Exporter line card (represented 
                by the originalExporterIPv4Address or 
                originalExporterIPv6Address, the lineCardId Information 
                Elements, respectively)  
        
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 21] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        Some Information Elements characterizing the Observation Point 
        may be added.  For example, the flowDirection Information 
        Element specifies the direction of the observation, and, as 
        such, characterizes the Observation Point. 
      
        Any combination of the above examples is possible.  For example, 
        in case of an Intermediate Aggregation Process, an Original 
        Observation Point can be composed of: 
              exporterIPv4Address 192.0.2.1  
              exporterIPv4Address 192.0.2.2,  
                       interface ethernet 0, direction ingress 
                       interface ethernet 1, direction ingress 
                       interface serial 1, direction egress 
                       interface serial 2, direction egress 
              exporterIPv4Address 192.0.2.3,  
                       lineCardId 1, direction ingress 
      
        If the Original Observation Point is composed of a list, then 
        the IPFIX Structured Data [RFC6313] MUST be used to export it 
        from the IPFIX Mediator.   
         
        The most generic way to export the Original Observation Point is 
        to use a subTemplateMultiList, with the semantic "exactlyOneOf".  
        Taking the previous example, the following encoding can be used: 
         
                 Template Record 257: exporterIPv4Address 
                 Template Record 258: exporterIPv4Address, basicList of 
                                    ingressInterface, flowDirection 
                 Template Record 259: exporterIPv4Address, lineCardId,  
                                    flowDirection 
         
        The Original Observation Point is modeled with the Data Records 
        corresponding to either Template Record 1, Template Record 2, or 
        Template Record 3 but not more than one of these ("exactlyOneOf" 
        semantic).  This implies that the Flow was observed at exactly 
        one of the Observation Points reported. 
         
        When an IPFIX Mediator receives Flow Records containing the 
        Original Observation Point Information Element, i.e. 
        originalExporterIPv6Address or originalExporterIPv4Address, the 
        IPFIX Mediator SHOULD NOT modify its value(s) when composing new 
        Flow Records in the general case.   Known exceptions include 
        anonymization per [RFC6235] section 7.2.4 and an Intermediate 
        Correlation Process rewriting addresses across NAT.  In other 
        words, the Original Observation Point should not be replaced the 

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 22] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        IPFIX Mediator Observation Point.  The daisy chain of (Exporter, 
        Observation Point) representing the path the Flow Records took 
        from the Exporter to the top Collector in the Exporter-
        Mediator(s)-Collector structure model is out of the scope of 
        this specification.   
         
         

     3.4.1. Observation Domain Management 

        In any case, the Observation Domain ID of any IPFIX Message 
        containing Flow Records relevant to no particular Observation 
        Domain, or to multiple Observation Domains, MUST have an 
        Observation Domain ID of 0, as in section 3.1 above, and section 
        3.1 of [RFC5101bis]. 
         
        IPFIX Mediators that do not change (Options) Template Records 
        MUST maintain a Template Mapping, as detailed in section 3.2.1, 
        to ensure that the combination of Observation Domain IDs and 
        Template IDs do not collide on export. 
         
        For IPFIX Mediators that export New (Options) Template Records 
        unchanged, as in section 3.2.2, there are two options for 
        Observation Domain ID management.  The first and simplest of 
        these is to completely decouple exported Observation Domain IDs 
        from received Observation Domain IDs; the IPFIX Mediator, in 
        this case, comprises its own set of Observation Domain(s) 
        independent of the Observation Domain(s) of the Original 
        Exporters. 
         
        The second option is to provide or maintain a Template Mapping 
        for received (Options) Template Records and exported inferred 
        (Options) Template Records, along with the appropriate 
        Observation Domain IDs per Transport Session, which ensures that 
        the combination of Observation Domain IDs and Template IDs do 
        not collide on export.   
      
        In some cases where the IPFIX Message Header can't contain a 
        consistent Observation Domain for the entire IPFIX Message, but 
        the Flow Records exported from the IPFIX Mediator should anyway 
        contain the Observation Domain of the Original Exporter, the 
        (Options) Template Record must contain the 
        originalObservationDomainId Information Element.  When an IPFIX 
        Mediator receives Flow Records containing the 
        originalObservationDomainId Information Element, the IPFIX 
        Mediator MUST NOT modify its value(s) when composing new Flow 
        Records with the originalObservationDomainId Information  
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 23] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        Element. 
      
         

     3.5. Specific Reporting Requirements 

        Some specific Options Templates and Options Template Records are 
        necessary to provide extra information about the Flow Records 
        and about the Metering Process. 
         
        The Options Template Records defined in these subsections, which 
        impose some constraints on the Metering Process and Exporting 
        Process implementations in Intermediate Processes, MAY be 
        implemented.  If implemented, the specific Option Templates 
        SHOULD be implemented as specified in these subsections. 
         
        The minimum set of Information Elements is always specified in 
        these specific IPFIX Options Templates.  Nevertheless, extra 
        Information Elements may be used in these specific Options 
        Templates. 
         

     3.5.1. The Flow Keys Options Template 

        Exactly like the IPFIX protocol [RFC5101bis], the Flow Keys 
        Option Template specifies the structure of a Data Record for 
        reporting the Flow Keys of reported Flows.  A Flow Keys Data 
        Record extends a particular Template Record that is referenced 
        by its templateId identifier.  The Template Record is extended 
        by specifying which of the Information Elements contained in the 
        corresponding Data Records describe Flow properties that serve 
        as Flow Keys of the reported Flow. 
         
        The Flow Keys Option Template SHOULD contain the following 
        Information Elements that are defined in [RFC5102] 
         
           templateId              An identifier of a Template.  This 
                                   Information Element MUST be defined  
                                   as a Scope Field. 
         
           flowKeyIndicator        Bitmap with the positions of the Flow  
                                   Keys in the Data Records. 
        When any Intermediate Process changes the Flow Keys, the Flow 
        Keys Option Template MUST include the new set of Flow Keys. 
        Typically, an Intermediate Aggregation Process keeps or reduces 
        the number of Flow Keys.  However, the number of Flow Keys may 

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 24] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        increase when the Original Exporter or/and Original Observation 
        Point is/are added. 
         
     3.5.2. IPFIX Protocol Options Template 

        The "Metering Process Statistics Options Template", "The 
        Metering Process Reliability Statistics Options Template", and 
        "The Exporting Process Reliability Statistics Options Template", 
        as specified in [RFC5101bis], SHOULD be implemented on the IPFIX 
        Mediator. 
         
        Refer to the document specifying a particular Intermediate 
        Process type for specific values for these Options Template 
        Records.  For example, in case of an Intermediate Aggregation 
        Process, [IPFIX-MED-AGGR] specifies which values to insert into 
        the fields of "Metering Process Statistics Options Template", 
        "The Metering Process Reliability Statistics Options Template", 
        and "The Exporting Process Reliability Statistics Options 
        Template" 
      
         
     3.5.3. IPFIX Mediator Options Template 

        There is no need for a specific Options Template for the IPFIX 
        Mediator; instead, each Intermediate Process type requires some 
        particular metadata.  For example, a specification of IPFIX flow 
        Anonymization including an Options Template for the export of 
        metadata about Anonymized flows is described in [RFC6235]; when 
        Anonymizing Flows Records, IPFIX Mediators SHOULD add the 
        Options Template specified therein to annotate the exported 
        data.   
         
        Transport Session Management SCTP [RFC4960] using the PR-SCTP 
        extension specified in [RFC3758] MUST be implemented by all 
        compliant IPFIX Mediator implementations.  UDP [RFC768] MAY also 
        be implemented by compliant IPFIX Mediator implementations.  TCP 
        [RFC793] MAY also be implemented by IPFIX Mediator compliant 
        implementations. 
         
        PR-SCTP SHOULD be used in deployments where IPFIX Mediators and 
        Collectors are communicating over links that are susceptible to 
        congestion.  PR-SCTP is capable of providing any required degree 
        of reliability. 

        TCP MAY be used in deployments where IPFIX Mediators and 
        Collectors communicate over links that are susceptible to 
        congestion, but PR-SCTP is preferred due to its ability to limit 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 25] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        back pressure on Exporters and its message versus stream 
        orientation.  

        UDP MAY be used, although it is not a congestion-aware protocol. 
        However, in this case, the IPFIX traffic between IPFIX Mediator 
        and Collector MUST run in an environment where IPFIX traffic has 
        been provisioned for, or is contained through some other means. 
         

     3.6. The Collecting Process's Side 

        An IPFIX Mediator produces IPFIX Messages understandable by a 
        IPFIX-compliant Collector, with the additional specifications in 
        IPFIX Structured Data [RFC6313]. 
         
        Therefore the Collecting Process on the top Collector MUST 
        support the IPFIX protocol [RFC5101bis] and the IPFIX Structured 
        Data [RFC6313]. 
      
      
     3.7. Configuration Management 

        In some cases such as an Intermediate Aggregation Process 
        aggregating Flow Records from multiple Original Exporters, a 
        consistent configuration of the Metering Processes and Exporting 
        Processes on these Original Exporters offers some advantages.  
        For example, consistent active timeout, inactive timeout, and/or 
        consistent export time allows the number of the Flow Records per 
        period of time to be compared.  For example, consistent Sampling 
        algorithm and parameters might allow Flow Records accuracy to be 
        compared. 
         
        While this is tempting to include all configuration parameters 
        in Flow Records for the IPFIX Mediator to draw its own 
        conclusion, the consistency of the configuration should be 
        verified out of band, with the MIB modules ([RFC5815bis] and 
        [PSAMP-MIB]) or with the Configuration Data Model for IPFIX and 
        PSAMP [IPFIX-CONF]  
           
         
     4. New Information Elements 

       Three new Information Elements are requested in this 
       specifications: originalExporterIPv4Address, 
       originalExporterIPv6Address, and originalObservationDomainId.  
       See Section 6.1. , Section 6.2. , and Section 6.3. ,  
       respectively, for the formal definitions. 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 26] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

      

     5. Security Considerations 

        The same security considerations as for the IPFIX Protocol 
        [RFC5101bis] apply. 
         
        As they act as both IPFIX Collecting Processes and Exporting 
        Processes, the Security Considerations for IPFIX Protocol 
        [RFC5101bis] also apply to Mediators.  The Security 
        Considerations for IPFIX Files [RFC5655] also apply to IPFIX 
        Mediators that write IPFIX Files or use them for internal 
        storage.  However, there are a few specific considerations that 
        IPFIX Mediator implementations must also take into account. 
         
        By design, IPFIX Mediators are "men-in-the-middle": they 
        intercede in the communication between an Original Exporter (or 
        another upstream Mediator) and a downstream Collecting Process. 
        This has two important implications for the level of 
        confidentiality provided across an IPFIX Mediator, and the 
        ability to protect data integrity and Original Exporter 
        authenticity across a Mediator. These are addressed in more 
        detail in the Security Considerations for Mediators in [IPFIX-
        MED-FMWK]. 
         
        Note that, while Mediators can use the exporterCertificate and 
        collectorCertificate Information Elements defined in [RFC5655] 
        as described in section 9.3 of [IPFIX-MED-FMWK] to export 
        information about X.509 identities in upstream TLS-protected 
        Transport Sessions, this mechanism cannot be used to provide 
        true end-to-end assertions about a chain of IPFIX Mediators: any 
        Mediator in the chain can simply falsify the information about 
        upstream Transport Sessions  In situations where information 
        about the chain of mediation is important, it must be determined 
        out of band. 

      
     6. IANA Considerations 

      This document specifies three new IPFIX Information Elements: the 
      applicationDescription, applicationTag and the applicationName. 
       
      New Information Elements to be added to the IPFIX Information 
      Element registry at [IANA-IPFIX] are listed below. 
       
      XML specifications of these elements can be found in Appendix A. 
       
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 27] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

      EDITOR'S NOTE: please change the TBD1, TBD2, and TBD3, with the 
      IANA newly assigned numbers. Note that the XML specification in 
      Appendix A must also be updated with the elementId values 
      allocated. 
         
     6.1. originalExporterIPv4Address 

      Name: originalExporterIPv4Address 
      Description:  
        The IPv4 address used by the Exporting Process on the Original 
        Exporter. This is used by an IPFIX Mediator Exporting Process 
        to identify the Original Exporter.  
      Abstract Data Type: ipv4Address 
      Data Type Semantics: identifier 
      ElementId: TBD1 
      Status: current  
       
       
     6.2. originalExporterIPv6Address 

      Name: originalExporterIPv6Address  
      Description:  
        The IPv6 address used by the Exporting Process on the Original 
        Exporter. This is used by the IPFIX Mediator Exporting Process 
        to identify the Original Exporter.  
      Abstract Data Type: ipv6Address 
      Data Type Semantics: identifier 
      ElementId: TBD2 
      Status: current  
       
       
     6.3. originalObservationDomainId 

      Name: originalObservationDomainId 
      Description:  
         An identifier of the Observation Domain on the Original 
         Exporter, where the metered IP packets are observed. This is 
         used by the IPFIX Mediator Exporting Process to identify an 
         Observation Domain as received from the Original Exporter. 
      Abstract Data Type: unsigned32 
     Data Type Semantics: identifier 
     ElementId: TBD3 
     Status: current  
         

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 28] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

     7. References 

     7.1. Normative References 

        [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 
                Requirement Levels, BCP 14, RFC 2119, March 1997 
         
        [RFC3758] Stewart, R., Ramalho, M, Xie, Q., Tuexen, M., and P. 
                Conrad, "Stream Control Transmission Protocol (SCTP), 
                Partial Reliability Extension", May 2004 
         
        [RFC4960] Stewart, R., Ed., "Stream Control Transmission 
                Protocol", RFC 4960, September 2007. 
      
        [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and 
                J. Meyer, "Information Model for IP Flow Information 
                Export", RFC 5102, January 2008. 
         
        [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 
                Wagner, "Specification of the IP Flow Information 
                Export (IPFIX) File Format", RFC 5655, October 2009. 
         
        [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 
                "Export of Structured Data in IP Flow Information 
                Export (IPFIX)", RFC6313, July 2011. 
      
        [IPFIX-MED-FLOWSEL] D'antonio, S., Zseby, T., Henke, C. and L. 
                Peluso, "Flow Selection Techniques", draft-ietf-ipfix-
                flow-selection-tech-09.txt, Internet-Draft work in 
                progress, November 2011. 
         
        [IPFIX-MED-AGGR] Trammell, B., Boschi, E., A. Wagner, and B. 
                Claise, "Exporting Aggregated Flow Data using the IP 
                Flow Information Export (IPFIX) Protocol", draft-
                trammell-ipfix-a9n-03.txt, Internet-Draft work in 
                progress, June 2011. 
         
        [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek "Definitions 
                of Managed Objects for Packet Sampling", draft-ietf-
                ipfix-psamp-mib-04.txt, Internet-Draft work in 
                progress, October 2011. 
         
        [IPFIX-CONF] Muenz, G., Claise, B., and P. Aitken "Configuration 
                Data Model for IPFIX and PSAMP", draft-ietf-ipfix-
                configuration-model-10, Internet-Draft work in 
                progress, July 2011.  
         
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 29] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        [RFC5101bis] Claise, B., and B. Trammell, "Specification of the 
                IP Flow Information eXport (IPFIX) Protocol for the 
                Exchange of IP Traffic Flow Information", draft-ietf-
                ipfix-protocol-rfc5101bis-00, Work in Progress, 
                November 2011. 
         
        [RFC5815bis] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 
                "Definitions of Managed Objects for IP Flow Information 
                Export", draft-ietf-ipfix-rfc5815bis-00.txt, Work in 
                Progress, April 2010. 
         
      
         
     7.2. Informative References 

         
        [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 
                August 1980. 
          
        [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 
                793, September 1981. 
         
        [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 
                "Requirements for IP Flow Information Export", RFC 
                3917, October 2004 
         
        [RFC3954] Claise, B. (Ed), "Cisco Systems NetFlow Services 
                Export Version 9", RFC 3954, October 2004 
         
        [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. 
                Quittek, "Architecture Model for IP Flow Information 
                Export", RFC5470, March 2009 
         
        [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, 
                "IP Flow Information Export (IPFIX) Applicability", RFC 
                5472, March 2009 
         
        [RFC5476] Claise, B., Quittek, J., and A. Johnson, "Packet 
                Sampling (PSAMP) Protocol Specifications", RFC 5476, 
                March 2009. 
         
        [RFC5982] Kobayashi, A. (Ed), Claise, B. (Ed), "P Flow 
                Information Export (IPFIX) Mediation: Problem 
                Statement", RFC 5982, August 2010. 
         

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 30] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        [IPFIX-MED-FMWK] Kobayashi, A., Claise, B., Muenz, G., and K. 
                Ishibashi, "IPFIX Mediation: Framework", RFC 6183, 
                April 2011. 
         
        [RFC6235] Boschi, E., Trammell, B. "IP Flow Anonymization 
                Support", RFC 6235, May 2011. 
         
        [IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xhtml 
         
         
        Acknowledgments 
         
        We would like to thank the IPFIX contributors and specifically 
        Paul Aitken for his thorough review.   
      
         
         
     8. Author's Addresses 

        Benoit Claise 
        Cisco Systems, Inc. 
        De Kleetlaan 6a b1 
        Diegem 1813 
        Belgium 
            
        Phone: +32 2 704 5622 
        Email: bclaise@cisco.com 
      
      
        Atsushi Kobayashi 
        NTT Information Sharing Platform Laboratories 
        3-9-11 Midori-cho 
        Musashino-shi, Tokyo  180-8585 
        Japan 
         
        Phone: +81-422-59-3978 
        Email: akoba@nttv6.net 
        URI:   http://www3.plala.or.jp/akoba/ 
         
         
        Brian Trammell 
        ETH Zurich 
        Gloriastrasse 35 
        8092 Zurich 
        Switzerland 
         
        Phone: +41 44 632 70 13 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 31] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

        EMail: trammell@tik.ee.ethz.ch 
         
       

      Appendix A.  Additions to XML Specification of IPFIX Information 
      Elements 

        This appendix contains additions to the machine-readable 
        description of the IPFIX information model coded in XML in 
        Appendix A and Appendix B in [RFC5102].  Note that this appendix 
        is of informational nature, while the text in Section 6. 
        (generated from this appendix) is normative. 
         
        The following field definitions are appended to the IPFIX 
        information model in Appendix A of [RFC5102]. 
      
        <field name="originalExporterIPv4Address" 
                 dataType="ipv4Address" 
                 group="config" 
                 elementId="TBD1" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                The IPv4 address used by the Exporting Process on the 
                Original Exporter. This is used by an IPFIX Mediator 
                Exporting Process to identify the Original Exporter. 
              </paragraph> 
            </description> 
          </field> 
         
      
        <field name="originalExporterIPv6Address" 
                 dataType="ipv6Address" 
                 group="config" 
                 elementId="TBD2" applicability="all" status="current"> 
            <description> 
              <paragraph> 
                The IPv6 address used by the Exporting Process on the 
                Original Exporter. This is used by the IPFIX Mediator 
                Exporting Process to identify the Original Exporter.  
              </paragraph> 
            </description> 
          </field> 
         
        <field name="originalObservationDomainId" 
                 dataType="unsigned32" 
                 group="config" 
                 elementId="TBD3" applicability="all" status="current"> 
      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 32] 
         

     Internet-Draft     <Protocol for IPFIX Mediations>       Dec 2011 
         

            <description> 
              <paragraph> 
                An identifier of the Observation Domain on the Original 
                Exporter, where the metered IP packets are observed. 
                This is used by the IPFIX Mediator Exporting Process to 
                identify an Observation Domain as received from the 
                Original Exporter. 
              </paragraph> 
            </description> 
          </field> 
         
         

      
      
     <Claise, et. Al>         Expires June 6, 2012            [Page 33]