tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5101


Pages: 63
Top     in Index     Prev     Next
 

Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information

Part 1 of 3, p. 1 to 23
None       Next RFC Part

Obsoleted by:    7011


Top       ToC       Page 1 
Network Working Group                                     B. Claise, Ed.
Request for Comments: 5101                           Cisco Systems, Inc.
Category: Standards Track                                   January 2008


   Specification of the IP Flow Information Export (IPFIX) Protocol
            for the Exchange of IP Traffic Flow Information

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies the IP Flow Information Export (IPFIX)
   protocol that serves for transmitting IP Traffic Flow information
   over the network.  In order to transmit IP Traffic Flow information
   from an Exporting Process to an information Collecting Process, a
   common representation of flow data and a standard means of
   communicating them is required.  This document describes how the
   IPFIX Data and Template Records are carried over a number of
   transport protocols from an IPFIX Exporting Process to an IPFIX
   Collecting Process.

Table of Contents

   1. Introduction ....................................................3
      1.1. IPFIX Documents Overview ...................................4
   2. Terminology .....................................................4
      2.1. Terminology Summary Table ..................................9
   3. IPFIX Message Format ...........................................10
      3.1. Message Header Format .....................................11
      3.2. Field Specifier Format ....................................13
      3.3. Set and Set Header Format .................................14
           3.3.1. Set Format .........................................14
           3.3.2. Set Header Format ..................................15
      3.4. Record Format .............................................16
           3.4.1. Template Record Format .............................16
           3.4.2. Options Template Record Format .....................18
                  3.4.2.1. Scope .....................................19
                  3.4.2.2. Options Template Record Format ............20
           3.4.3. Data Record Format .................................22
   4. Specific Reporting Requirements ................................23
      4.1. The Metering Process Statistics Option Template ...........23

Top      ToC       Page 2 
      4.2. The Metering Process Reliability Statistics Option
           Template ..................................................24
      4.3. The Exporting Process Reliability Statistics
           Option Template ...........................................25
      4.4. The Flow Keys Option Template .............................26
   5. IPFIX Message Header "Export Time" and Flow Record Time ........27
   6. Linkage with the Information Model .............................28
      6.1. Encoding of IPFIX Data Types ..............................28
           6.1.1. Integral Data Types ................................28
           6.1.2. Address Types ......................................28
           6.1.3. float32 ............................................28
           6.1.4. float64 ............................................28
           6.1.5. boolean ............................................28
           6.1.6. string and octetarray ..............................28
           6.1.7. dateTimeSeconds ....................................29
           6.1.8. dateTimeMilliseconds ...............................29
           6.1.9. dateTimeMicroseconds ...............................29
           6.1.10. dateTimeNanoseconds ...............................29
      6.2. Reduced Size Encoding of Integer and Float Types ..........29
   7. Variable-Length Information Element ............................30
   8. Template Management ............................................31
   9. The Collecting Process's Side ..................................34
   10. Transport Protocol ............................................36
      10.1. Transport Compliance and Transport Usage .................36
      10.2. SCTP .....................................................37
           10.2.1. Congestion Avoidance ..............................37
           10.2.2. Reliability .......................................37
           10.2.3. MTU ...............................................37
           10.2.4. Exporting Process .................................38
                  10.2.4.1. Association Establishment ................38
                  10.2.4.2. Association Shutdown .....................38
                  10.2.4.3. Stream ...................................38
                  10.2.4.4. Template Management ......................39
           10.2.5. Collecting Process ................................39
           10.2.6. Failover ..........................................39
      10.3. UDP ......................................................39
           10.3.1. Congestion Avoidance ..............................39
           10.3.2. Reliability .......................................40
           10.3.3. MTU ...............................................40
           10.3.4. Port Numbers ......................................40
           10.3.5. Exporting Process .................................40
           10.3.6. Template Management ...............................40
           10.3.7. Collecting Process ................................41
           10.3.8. Failover ..........................................42
      10.4. TCP ......................................................42
           10.4.1. Connection Management .............................42
                  10.4.1.1. Connection Establishment .................42
                  10.4.1.2. Graceful Connection Release ..............43

Top      ToC       Page 3 
                  10.4.1.3. Restarting Interrupted Connections .......43
                  10.4.1.4. Failover .................................43
           10.4.2. Data Transmission .................................43
                  10.4.2.1. IPFIX Message Encoding ...................43
                  10.4.2.2. Template Management ......................44
                  10.4.2.3. Congestion Handling and Reliability ......44
           10.4.3. Collecting Process ................................45
   11. Security Considerations .......................................46
      11.1. Applicability of TLS and DTLS ............................47
      11.2. Usage ....................................................48
      11.3. Authentication ...........................................48
      11.4. Protection against DoS Attacks ...........................48
      11.5. When DTLS or TLS Is Not an Option ........................50
      11.6. Logging an IPFIX Attack ..................................50
      11.7. Securing the Collector ...................................51
   12. IANA Considerations ...........................................51
   Appendix A. IPFIX Encoding Examples ...............................52
      A.1. Message Header Example.....................................52
      A.2. Template Set Examples......................................53
           A.2.1. Template Set Using IETF-Specified Information
                  Elements ...........................................53
           A.2.2. Template Set Using Enterprise-Specific Information
                  Elements ...........................................53
      A.3. Data Set Example ..........................................55
      A.4. Options Template Set Examples .............................56
           A.4.1. Options Template Set Using IETF-Specified
                  Information Elements ...............................56
           A.4.2. Options Template Set Using Enterprise-Specific
                  Information Elements ...............................56
           A.4.3. Options Template Set Using an Enterprise-Specific
                  Scope ..............................................57
           A.4.4. Data Set Using an Enterprise-Specific Scope ........58
      A.5. Variable-Length Information Element Examples ..............59
           A.5.1. Example of Variable-Length Information Element
                  with Length Inferior to 255 Octets .................59
           A.5.2. Example of Variable-Length Information Element
                  with Length 255 to 65535 Octets ....................59
   References ........................................................59
      Normative References ...........................................59
      Informative References .........................................60
   Acknowledgments ...................................................61

1.  Introduction

   A data network with IP traffic primarily consists of IP flows passing
   through the network elements.  It is often interesting, useful, or
   even required to have access to information about these flows that
   pass through the network elements for administrative or other

Top      ToC       Page 4 
   purposes.  The IPFIX Collecting Process should be able to receive the
   flow information passing through multiple network elements within the
   data network.  This requires uniformity in the method of representing
   the flow information and the means of communicating the flows from
   the network elements to the collection point.  This document
   specifies the protocol to achieve these aforementioned requirements.
   This document specifies in detail the representation of different
   flows, the additional data required for flow interpretation, packet
   format, transport mechanisms used, security concerns, etc.

1.1.  IPFIX Documents Overview

   The IPFIX protocol 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 [IPFIX-ARCH], per the requirements defined in
   [RFC3917].  This document specifies how IPFIX data records and
   templates are carried via a number of transport protocols 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 [RFC5102].
   Finally, [IPFIX-AS] 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.

2.  Terminology

   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].

   The definitions of the basic terms like IP Traffic Flow, Exporting
   Process, Collecting Process, Observation Points, etc.  are
   semantically identical to those found in the IPFIX requirements
   document [RFC3917].  Some of the terms have been expanded for more
   clarity when defining the protocol.  Additional terms required for
   the protocol have also been defined.  Definitions in this document
   and in [IPFIX-ARCH] are equivalent, except that definitions that are
   only relevant to the IPFIX protocol only appear here.

   The terminology summary table in Section 2.1 gives a quick overview
   of the relationships between some of the different terms defined.

Top      ToC       Page 5 
   Observation Point

      An Observation Point is a location in the network where IP packets
      can be observed.  Examples include: a line to which a probe is
      attached, a shared medium, such as an Ethernet-based LAN, a single
      port of a router, or a set of interfaces (physical or logical) of
      a router.

      Note that every Observation Point is associated with an
      Observation Domain (defined below), and that one Observation Point
      may be a superset of several other Observation Points.  For
      example, one Observation Point can be an entire line card.  That
      would be the superset of the individual Observation Points at the
      line card's interfaces.

   Observation Domain

      An Observation Domain is the largest set of Observation Points for
      which Flow information can be aggregated by a Metering Process.
      For example, a router line card may be an Observation Domain if it
      is composed of several interfaces, each of which is an Observation
      Point.  In the IPFIX Message it generates, the Observation Domain
      includes its Observation Domain ID, which is unique per Exporting
      Process.  That way, the Collecting Process can identify the
      specific Observation Domain from the Exporter that sends the IPFIX
      Messages.  Every Observation Point is associated with an
      Observation Domain.  It is RECOMMENDED that Observation Domain IDs
      also be unique per IPFIX Device.

   IP Traffic Flow or Flow

      There are several definitions of the term 'flow' being used by the
      Internet community.  Within the context of IPFIX we use the
      following definition:

      A Flow is defined as a set of IP packets passing an Observation
      Point in the network during a certain time interval.  All packets
      belonging to a particular Flow have a set of common properties.
      Each property is defined as the result of applying a function to
      the values of:

         1. one or more packet header fields (e.g., destination IP
            address), transport header fields (e.g., destination port
            number), or application header fields (e.g., RTP header
            fields [RFC3550]).

         2. one or more characteristics of the packet itself (e.g.,
            number of MPLS labels, etc...).

Top      ToC       Page 6 
         3. one or more of fields derived from packet treatment (e.g.,
            next hop IP address, the output interface, etc...).

      A packet is defined as belonging to a Flow if it completely
      satisfies all the defined properties of the Flow.

      This definition covers the range from a Flow containing all
      packets observed at a network interface to a Flow consisting of
      just a single packet between two applications.  It includes
      packets selected by a sampling mechanism.

   Flow Key

      Each of the fields that:

      1.  belong to the packet header (e.g., destination IP address),

      2.  are a property of the packet itself (e.g., packet length),

      3.  are derived from packet treatment (e.g., Autonomous System
          (AS) number),

      and that are used to define a Flow are termed Flow Keys.

   Flow Record

      A Flow Record contains information about a specific Flow that was
      observed at an Observation Point.  A Flow Record contains measured
      properties of the Flow (e.g., the total number of bytes for all
      the Flow's packets) and usually characteristic properties of the
      Flow (e.g., source IP address).

   Metering Process

      The Metering Process generates Flow Records.  Inputs to the
      process are packet headers and characteristics observed at an
      Observation Point, and packet treatment at the Observation Point
      (for example, the selected output interface).

      The Metering Process consists of a set of functions that includes
      packet header capturing, timestamping, sampling, classifying, and
      maintaining Flow Records.

      The maintenance of Flow Records may include creating new records,
      updating existing ones, computing Flow statistics, deriving
      further Flow properties, detecting Flow expiration, passing Flow
      Records to the Exporting Process, and deleting Flow Records.

Top      ToC       Page 7 
   Exporting Process

      The Exporting Process sends Flow Records to one or more Collecting
      Processes.  The Flow Records are generated by one or more Metering
      Processes.

   Exporter

      A device that hosts one or more Exporting Processes is termed an
      Exporter.

   IPFIX Device

      An IPFIX Device hosts at least one Exporting Process.  It may host
      further Exporting Processes and arbitrary numbers of Observation
      Points and Metering Processes.

   Collecting Process

      A Collecting Process receives Flow Records from one or more
      Exporting Processes.  The Collecting Process might process or
      store received Flow Records, but such actions are out of scope for
      this document.

   Collector

      A device that hosts one or more Collecting Processes is termed a
      Collector.

   Template

      A Template is an ordered sequence of <type, length> pairs used to
      completely specify the structure and semantics of a particular set
      of information that needs to be communicated from an IPFIX Device
      to a Collector.  Each Template is uniquely identifiable by means
      of a Template ID.

   IPFIX Message

      An IPFIX Message is a message originating at the Exporting Process
      that carries the IPFIX records of this Exporting Process and whose
      destination is a Collecting Process.  An IPFIX Message is
      encapsulated at the transport layer.

Top      ToC       Page 8 
   Message Header

      The Message Header is the first part of an IPFIX Message, which
      provides basic information about the message, such as the IPFIX
      version, length of the message, message sequence number, etc.

   Template Record

      A Template Record defines the structure and interpretation of
      fields in a Data Record.

   Data Record

      A Data Record is a record that contains values of the parameters
      corresponding to a Template Record.

   Options Template Record

      An Options Template Record is a Template Record that defines the
      structure and interpretation of fields in a Data Record, including
      defining how to scope the applicability of the Data Record.

   Set

      Set is a generic term for a collection of records that have a
      similar structure.  In an IPFIX Message, one or more Sets follow
      the Message Header.

      There are three different types of Sets: Template Set, Options
      Template Set, and Data Set.

   Template Set

      A Template Set is a collection of one or more Template Records
      that have been grouped together in an IPFIX Message.

   Options Template Set

      An Options Template Set is a collection of one or more Options
      Template Records that have been grouped together in an IPFIX
      Message.

   Data Set

      A Data Set is one or more Data Records, of the same type, that are
      grouped together in an IPFIX Message.  Each Data Record is
      previously defined by a Template Record or an Options Template
      Record.

Top      ToC       Page 9 
   Information Element

      An Information Element is a protocol and encoding-independent
      description of an attribute that may appear in an IPFIX Record.
      The IPFIX information model [RFC5102] defines the base set of
      Information Elements for IPFIX.  The type associated with an
      Information Element indicates constraints on what it may contain
      and also determines the valid encoding mechanisms for use in
      IPFIX.

   Transport Session

      In Stream Control Transmission Protocol (SCTP), the transport
      session is known as the SCTP association, which is uniquely
      identified by the SCTP endpoints [RFC4960]; in TCP, the transport
      session is known as the TCP connection, which is uniquely
      identified by the combination of IP addresses and TCP ports used.
      In UDP, the transport session is known as the UDP session, which
      is uniquely identified by the combination of IP addresses and UDP
      ports used.

2.1.  Terminology Summary Table

   +------------------+---------------------------------------------+
   |                  |                 contents                    |
   |                  +--------------------+------------------------+
   |       Set        |      Template      |         record         |
   +------------------+--------------------+------------------------+
   |     Data Set     |          /         |     Data Record(s)     |
   +------------------+--------------------+------------------------+
   |   Template Set   | Template Record(s) |           /            |
   +------------------+--------------------+------------------------+
   | Options Template | Options Template   |           /            |
   |       Set        | Record(s)          |                        |
   +------------------+--------------------+------------------------+

   Figure A: Terminology Summary Table

   A Data Set is composed of Data Record(s).  No Template Record is
   included.  A Template Record or an Options Template Record defines
   the Data Record.

   A Template Set contains only Template Record(s).

   An Options Template Set contains only Options Template Record(s).

Top      ToC       Page 10 
3.  IPFIX Message Format

   An IPFIX Message consists of a Message Header, followed by one or
   more Sets.  The Sets can be any of the possible three types: Data
   Set, Template Set, or Options Template Set.

   The format of the IPFIX Message is shown in Figure B.

   +----------------------------------------------------+
   | Message Header                                     |
   +----------------------------------------------------+
   | Set                                                |
   +----------------------------------------------------+
   | Set                                                |
   +----------------------------------------------------+
     ...
   +----------------------------------------------------+
   | Set                                                |
   +----------------------------------------------------+

   Figure B: IPFIX Message Format

   The Exporter MUST code all binary integers of the Message Header and
   the different Sets in network-byte order (also known as the
   big-endian byte ordering).

   Following are some examples of IPFIX Messages:

   1. An IPFIX Message consisting of interleaved Template, Data, and
      Options Template Sets -- A newly created Template is exported as
      soon as possible.  So, if there is already an IPFIX Message with a
      Data Set that is being prepared for export, the Template and
      Option Template Sets are interleaved with this information,
      subject to availability of space.

   +--------+--------------------------------------------------------+
   |        | +----------+ +---------+     +-----------+ +---------+ |
   |Message | | Template | | Data    |     | Options   | | Data    | |
   | Header | | Set      | | Set     | ... | Template  | | Set     | |
   |        | |          | |         |     | Set       | |         | |
   |        | +----------+ +---------+     +-----------+ +---------+ |
   +--------+--------------------------------------------------------+

   Figure C: IPFIX Message, Example 1

Top      ToC       Page 11 
   2. An IPFIX Message consisting entirely of Data Sets -- After the
      appropriate Template Records have been defined and transmitted to
      the Collecting Process, the majority of IPFIX Messages consist
      solely of Data Sets.

   +--------+----------------------------------------------+
   |        | +---------+     +---------+      +---------+ |
   |Message | | Data    |     | Data    |      | Data    | |
   | Header | | Set     | ... | Set     | ...  | Set     | |
   |        | +---------+     +---------+      +---------+ |
   +--------+----------------------------------------------+

   Figure D: IPFIX Message, Example 2

   3. An IPFIX Message consisting entirely of Template and Options
      Template Sets.

   +--------+-------------------------------------------------+
   |        | +----------+     +----------+      +----------+ |
   |Message | | Template |     | Template |      | Options  | |
   | Header | | Set      | ... | Set      | ...  | Template | |
   |        | |          |     |          |      | Set      | |
   |        | +----------+     +----------+      +----------+ |
   +--------+-------------------------------------------------+

   Figure E: IPFIX Message, Example 3

3.1.  Message Header Format

   The format of the IPFIX Message Header is shown in Figure F.

    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 F: IPFIX Message Header Format

Top      ToC       Page 12 
   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, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX
      Message Header leaves the Exporter.

   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 subsections 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.

   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 also be 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 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 a hierarchy of
      Collectors when aggregated Data Records are exported.

Top      ToC       Page 13 
3.2.  Field Specifier Format

   Vendors need the ability to define proprietary Information Elements,
   because, for example, they are delivering a pre-standards product, or
   the Information Element is, in some way, commercially sensitive.
   This section describes the Field Specifier format for both
   IETF-specified Information Elements [RFC5102] and enterprise-specific
   Information Elements.

   The Information Elements are identified by the Information Element
   identifier.  When the Enterprise bit is set to 0, the corresponding
   Information Element identifier will report an IETF-specified
   Information Element, and the Enterprise Number MUST NOT be present.
   When the Enterprise bit is set to 1, the corresponding Information
   Element identifier will report an enterprise-specific Information
   Element; the Enterprise Number MUST be present.  An example of this
   is shown in Section A.4.2.

   The Field Specifier format is shown in Figure G.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|  Information Element ident. |        Field Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Enterprise Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure G: Field Specifier Format

   Where:

   E

      Enterprise bit.  This is the first bit of the Field Specifier.  If
      this bit is zero, the Information Element Identifier identifies an
      IETF-specified Information Element, and the four-octet Enterprise
      Number field MUST NOT be present.  If this bit is one, the
      Information Element identifier identifies an enterprise-specific
      Information Element, and the Enterprise Number filed MUST be
      present.

   Information Element identifier

      A numeric value that represents the type of Information Element.
      Refer to [RFC5102].

Top      ToC       Page 14 
   Field Length

      The length of the corresponding encoded Information Element, in
      octets.  Refer to [RFC5102].  The field length may be smaller than
      the definition in [RFC5102] if the reduced size encoding is used
      (see Section 6.2).  The value 65535 is reserved for variable-
      length Information Elements (see Section 7).

   Enterprise Number

      IANA enterprise number [PEN] of the authority defining the
      Information Element identifier in this Template Record.

3.3.  Set and Set Header Format

   A Set is a generic term for a collection of records that have a
   similar structure.  There are three different types of Sets: Template
   Sets, Options Template Sets, and Data Sets.  Each of these Sets
   consists of a Set Header and one or more records.  The Set Format and
   the Set Header Format are defined in the following sections.

3.3.1.  Set Format

   A Set has the format shown in Figure H.  The record types can be
   either Template Records, Options Template Records, or Data Records.
   The record types MUST NOT be mixed within a Set.

   +--------------------------------------------------+
   | Set Header                                       |
   +--------------------------------------------------+
   | record                                           |
   +--------------------------------------------------+
   | record                                           |
   +--------------------------------------------------+
    ...
   +--------------------------------------------------+
   | record                                           |
   +--------------------------------------------------+
   | Padding (opt.)                                   |
   +--------------------------------------------------+

   Figure H: Set Format

   The Set Field Definitions are as follows:

   Set Header

      The Set Header Format is defined in Section 3.3.2.

Top      ToC       Page 15 
   Record

      One of the record Formats: Template Record, Options Template
      Record, or Data Record Format.

   Padding

      The Exporting Process MAY insert some padding octets, so that the
      subsequent Set starts at an aligned boundary.  For security
      reasons, the padding octet(s) MUST be composed of zero (0) valued
      octets.  The padding length MUST be shorter than any allowable
      record in this Set.  If padding of the IPFIX Message is desired in
      combination with very short records, then the padding Information
      Element 'paddingOctets' [RFC5102] can be used for padding records
      such that their length is increased to a multiple of 4 or 8
      octets.  Because Template Sets are always 4-octet aligned by
      definition, padding is only needed in case of other alignments
      e.g., on 8-octet boundaries.

3.3.2.  Set Header Format

   Every Set contains a common header.  This header is defined in Figure
   I.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID               |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure I: Set Header Format

   The Set Header Field Definitions are as follows:

   Set ID

      Set ID value identifies the Set.  A value of 2 is reserved for the
      Template Set.  A value of 3 is reserved for the Option Template
      Set.  All other values from 4 to 255 are reserved for future use.
      Values above 255 are used for Data Sets.  The Set ID values of 0
      and 1 are not used for historical reasons [RFC3954].

   Length

      Total length of the Set, in octets, including the Set Header, all
      records, and the optional padding.  Because an individual Set MAY
      contain multiple records, the Length value MUST be used to
      determine the position of the next Set.

Top      ToC       Page 16 
3.4.   Record Format

   IPFIX defines three record formats, defined in the next sections: the
   Template Record Format, the Options Template Record Format, and the
   Data Record Format.

3.4.1.  Template Record Format

   One of the essential elements in the IPFIX record format is the
   Template Record.  Templates greatly enhance the flexibility of the
   record format because they allow the Collecting Process to process
   IPFIX Messages without necessarily knowing the interpretation of all
   Data Records.  A Template Record contains any combination of
   IANA-assigned and/or enterprise-specific Information Elements
   identifiers.

   The format of the Template Record is shown in Figure J.  It consists
   of a Template Record Header and one or more Field Specifiers.  The
   definition of the Field Specifiers is given in Figure G above.

   +--------------------------------------------------+
   | Template Record Header                           |
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+
    ...
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+

   Figure J: Template Record Format

   The format of the Template Record Header is shown in Figure K.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID (> 255)      |         Field Count           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure K: Template Record Header Format

Top      ToC       Page 17 
   The Template Record Header Field Definitions are as follows:

   Template ID

      Each of the newly generated Template Records is given a unique
      Template ID.  This uniqueness is local to the Transport Session
      and Observation Domain that generated the Template ID.  Template
      IDs 0-255 are reserved for Template Sets, Options Template Sets,
      and other reserved Sets yet to be created.  Template IDs of Data
      Sets are numbered from 256 to 65535.  There are no constraints
      regarding the order of the Template ID allocation.

   Field Count

      Number of fields in this Template Record.

   The example in Figure L shows a Template Set with mixed standard and
   enterprise-specific Information Elements.  It consists of a Set
   Header, a Template Header, and several Field Specifiers.

Top      ToC       Page 18 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 2           |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 256        |         Field Count = N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Information Element id. 1.1 |        Field Length 1.1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Enterprise Number  1.1                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| Information Element id. 1.2 |        Field Length 1.2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Information Element id. 1.N |        Field Length 1.N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Enterprise Number  1.N                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Template ID = 257        |         Field Count = M       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| Information Element id. 2.1 |        Field Length 2.1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Information Element id. 2.2 |        Field Length 2.2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Enterprise Number  2.2                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Information Element id. 2.M |        Field Length 2.M       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Enterprise Number  2.M                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Padding (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure L: Template Set Example

   Information Element Identifiers 1.2 and 2.1 are defined by the IETF
   (Enterprise bit = 0) and, therefore, do not need an Enterprise Number
   to identify them.

3.4.2.  Options Template Record Format

   Thanks to the notion of scope, The Options Template Record gives the
   Exporter the ability to provide additional information to the
   Collector that would not be possible with Flow Records alone.

Top      ToC       Page 19 
   One Options Template Record example is the "Flow Keys", which reports
   the Flow Keys for a Template, which is defined as the scope.  Another
   example is the "Template configuration", which reports the
   configuration sampling parameter(s) for the Template, which is
   defined as the scope.

3.4.2.1.  Scope

   The scope, which is only available in the Options Template Set, gives
   the context of the reported Information Elements in the Data Records.
   Note that the IPFIX Message Header already contains the Observation
   Domain ID (the identifier of the Observation Domain).  If not zero,
   this Observation Domain ID can be considered as an implicit scope for
   the Data Records in the IPFIX Message.  The Observation Domain ID
   MUST be zero when the IPFIX Message contains Data Records with
   different Observation Domain ID values defined as scopes.

   Multiple Scope Fields MAY be present in the Options Template Record,
   in which case, the composite scope is the combination of the scopes.
   For example, if the two scopes are defined as "metering process" and
   "template", the combined scope is this Template for this Metering
   Process.  The order of the Scope Fields, as defined in the Options
   Template Record, is irrelevant in this case.  However, if the order
   of the Scope Fields in the Options Template Record is relevant, the
   order of the Scope Fields MUST be used.  For example, if the first
   scope defines the filtering function, while the second scope defines
   the sampling function, the order of the scope is important.  Applying
   the sampling function first, followed by the filtering function,
   would lead to potentially different Data Records than applying the
   filtering function first, followed by the sampling function.  In this
   case, the Collector deduces the function order by looking at the
   order of the scope in the Options Template Record.

   The scope is an Information Element specified in the IPFIX
   Information Model [RFC5102].  An IPFIX-compliant implementation of
   the Collecting Process SHOULD support this minimum set of Information
   Elements as scope: LineCardId, TemplateId, exporterIPv4Address,
   exporterIPv6Address, and ingressInterface.  Note that other
   Information Elements, such as meteringProcessId, exportingProcessId,
   observationDomainId, etc. are also valid scopes.  The IPFIX protocol
   doesn't prevent the use of any Information Elements for scope.
   However, some Information Element types don't make sense if specified
   as scope; for example, the counter Information Elements.

   Finally, note that the Scope Field Count MUST NOT be zero.

Top      ToC       Page 20 
3.4.2.2.  Options Template Record Format

   An Options Template Record contains any combination of IANA-assigned
   and/or enterprise-specific Information Elements identifiers.

   The format of the Options Template Record is shown in Figure M.  It
   consists of an Options Template Record Header and one or more Field
   Specifiers.  The definition of the Field Specifiers is given in
   Figure G above.

   +--------------------------------------------------+
   | Options Template Record Header                   |
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+
    ...
   +--------------------------------------------------+
   | Field Specifier                                  |
   +--------------------------------------------------+

   Figure M: Options Template Record Format

   The format of the Options Template Record Header is shown in Figure
   N.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Template ID (> 255)   |         Field Count           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Scope Field Count        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure N: Options Template Record Header Format

   The Options Template Record Header Field Definitions are as follows:

   Template ID

   Template ID of this Options Template Record.  This value is greater
   than 255.

Top      ToC       Page 21 
   Field Count

   Number of all fields in this Options Template Record, including the
   Scope Fields.

   Scope Field Count

   Number of scope fields in this Options Template Record.  The Scope
   Fields are normal Fields except that they are interpreted as scope at
   the Collector.  The Scope Field Count MUST NOT be zero.

   The example in Figure O shows an Option Template Set with mixed IETF
   and enterprise-specific Information Elements.  It consists of a Set
   Header, an Option Template Header, and several Field Specifiers.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 3           |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Template ID = 258     |         Field Count = N + M   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope Field Count = N     |0|  Scope 1 Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope 1 Field Length      |0|  Scope 2 Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope 2 Field Length      |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ...                |1|  Scope N Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope N Field Length      |   Scope N Enterprise Number ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...  Scope N Enterprise Number   |1| Option 1 Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Option 1 Field Length      |  Option 1 Enterprise Number ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ... Option 1 Enterprise Number   |              ...              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             ...               |0| Option M Infor. Element Id. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Option M Field Length     |      Padding (optional)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure O: Option Template Set Example

Top      ToC       Page 22 
3.4.3.  Data Record Format

   The Data Records are sent in Data Sets.  The format of the Data
   Record is shown in Figure P.  It consists only of one or more Field
   Values.  The Template ID to which the Field Values belong is encoded
   in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".

   +--------------------------------------------------+
   | Field Value                                      |
   +--------------------------------------------------+
   | Field Value                                      |
   +--------------------------------------------------+
    ...
   +--------------------------------------------------+
   | Field Value                                      |
   +--------------------------------------------------+

   Figure P: Data Record Format

   Note that Field Values do not necessarily have a length of 16 bits.
   Field Values are encoded according to their data type specified in
   [RFC5102].

   Interpretation of the Data Record format can be done only if the
   Template Record corresponding to the Template ID is available at the
   Collecting Process.

   The example in Figure Q shows a Data Set. It consists of a Set Header
   and several Field Values.

Top      ToC       Page 23 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Set ID = Template ID        |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 1 - Field Value 3    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 2 - Field Value 3    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 3 - Field Value 1    |   Record 3 - Field Value 2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Record 3 - Field Value 3    |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |      Padding (optional)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure Q: Data Set, Containing Data Records



(page 23 continued on part 2)

Next RFC Part