doc: Add RFC documents

1 files changed, 3531 insertions, 0 deletions

diff --git a/doc/rfc/rfc5101.txt b/doc/rfc/rfc5101.txt
new file mode 100644
index 0000000..a2681e0
--- /dev/null
+++ b/doc/rfc/rfc5101.txt
@@ -0,0 +1,3531 @@
+
+
+
+
+
+
+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
+
+
+
+Claise, et al.              Standards Track                     [Page 1]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+      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
+
+
+
+Claise, et al.              Standards Track                     [Page 2]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+                  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
+
+
+
+Claise, et al.              Standards Track                     [Page 3]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                     [Page 4]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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...).
+
+
+
+Claise, et al.              Standards Track                     [Page 5]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+         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.
+
+
+
+
+Claise, et al.              Standards Track                     [Page 6]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                     [Page 7]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+Claise, et al.              Standards Track                     [Page 8]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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).
+
+
+
+
+
+
+Claise, et al.              Standards Track                     [Page 9]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+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
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 10]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 11]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 12]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+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].
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 13]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+Claise, et al.              Standards Track                    [Page 14]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+Claise, et al.              Standards Track                    [Page 15]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+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
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 16]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 17]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+    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.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 18]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 19]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+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.
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 20]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 21]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 22]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+    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
+
+4.  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 Option Template and Options Template Records defined in these
+   subsections, which impose some constraints on the Metering Process
+   and Exporting Process implementations, 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.
+
+4.1.  The Metering Process Statistics Option Template
+
+   The Metering Process Statistics Option Template specifies the
+   structure of a Data Record for reporting Metering Process statistics.
+   It SHOULD contain the following Information Elements that are defined
+   in [RFC5102]:
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 23]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   observationDomainId
+                           An identifier of an Observation Domain that
+                           is locally unique to the Exporting Process.
+                           This Information Element MUST be defined as a
+                           Scope Field.
+
+   exportedMessageTotalCount
+                           The total number of IPFIX Messages that the
+                           Exporting Process successfully sent to the
+                           Collecting Process since the Exporting
+                           Process re-initialization.
+
+   exportedFlowTotalCount
+                           The total number of Flow Records that the
+                           Exporting Process successfully sent to the
+                           Collecting Process since the Exporting
+                           Process re-initialization.
+
+   exportedOctetTotalCount
+                           The total number of octets that the Exporting
+                           Process successfully sent to the Collecting
+                           Process since the Exporting Process re-
+                           initialization.
+
+   The Exporting Process SHOULD export the Data Record specified by the
+   Metering Process Statistics Option Template on a regular basis or
+   based on some export policy.  This periodicity or export policy
+   SHOULD be configurable.
+
+   Note that if several Metering Processes are available on the Exporter
+   Observation Domain, the Information Element meteringProcessId MUST be
+   specified as an additional Scope Field.
+
+4.2.  The Metering Process Reliability Statistics Option Template
+
+   The Metering Process Reliability Option Template specifies the
+   structure of a Data Record for reporting lack of reliability in the
+   Metering Process.  It SHOULD contain the following Information
+   Elements that are defined in [RFC5102]:
+
+   observationDomainId
+                           An identifier of an Observation Domain that
+                           is locally unique to the Exporting Process.
+                           This Information Element MUST be defined as a
+                           Scope Field.
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 24]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   ignoredPacketTotalCount
+                           The total number of IP packets that the
+                           Metering Process did not process.
+
+   ignoredOctetTotalCount
+                           The total number of octets in observed IP
+                           packets that the Metering Process did not
+                           process.
+
+   time first ignored
+                           The timestamp of the first IP packet that was
+                           ignored by the Metering Process.  For this
+                           timestamp, any of the "flowStart" timestamp
+                           Information Elements flowStartMilliseconds,
+                           flowStartMicroseconds, flowStartNanoseconds,
+                           and flowStartDeltaMicroseconds can be used.
+
+   time last ignored
+                           The timestamp of the last IP packet that was
+                           ignored by the Metering Process.  For this
+                           timestamp, any of the "flowEnd" timestamp
+                           Information Elements flowEndMilliseconds,
+                           flowEndMicroseconds, flowEndNanoseconds, and
+                           flowEndDeltaMicroseconds can be used.
+
+   The Exporting Process SHOULD export the Data Record specified by the
+   Metering Process Reliability Statistics Option Template on a regular
+   basis or based on some export policy.  This periodicity or export
+   policy SHOULD be configurable.
+
+   Note that if several Metering Processes are available on the Exporter
+   Observation Domain, the Information Element meteringProcessId MUST be
+   specified as an additional Scope Field.
+
+4.3.  The Exporting Process Reliability Statistics Option Template
+
+   The Exporting Process Reliability Option Template specifies the
+   structure of a Data Record for reporting lack of reliability in the
+   Exporting process.  It SHOULD contain the following Information
+   Elements that are defined in [RFC5102]:
+
+   Exporting Process ID
+                        The identifier of the Exporting Process for
+                        which lack of reliability is reported.  There
+                        are three Information Elements specified in
+                        [RFC5102] that can be used for this purpose:
+                        exporterIPv4Address, exporterIPv6Address, or
+
+
+
+
+Claise, et al.              Standards Track                    [Page 25]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+                        exportingProcessId.  This Information Element
+                        MUST be defined as a Scope Field.
+
+   notSentFlowTotalCount
+                        The total number of Flows that were generated by
+                        the Metering Process and dropped by the Metering
+                        Process or by the Exporting Process instead of
+                        being sent to the Collecting Process.
+
+   notSentPacketTotalCount
+                        The total number of packets in Flow Records that
+                        were generated by the Metering Process and
+                        dropped by the Metering Process or by the
+                        Exporting Process instead of being sent to the
+                        Collecting Process.
+
+   notSentOctetTotalCount
+                        The total number of octets in packets in Flow
+                        Records that were generated by the Metering
+                        Process and dropped by the Metering Process or
+                        by the Exporting Process instead of being sent
+                        to the Collecting Process.
+
+   time first flow dropped
+                        The timestamp of the first Flow was dropped by
+                        the Metering Process.  For this timestamp, any
+                        of the "flowStart" timestamp Information
+                        Elements flowStartMilliseconds,
+                        flowStartMicroseconds, flowStartNanoseconds, and
+                        flowStartDeltaMicroseconds can be used.
+
+   time last flow dropped
+                        The timestamp of the last IP packet that was
+                        ignored by the Metering Process.  For this
+                        timestamp, any of the "flowEnd" timestamp
+                        Information Elements flowEndMilliseconds,
+                        flowEndMicroseconds, flowEndNanoseconds, and
+                        flowEndDeltaMicroseconds can be used.
+
+   The Exporting Process SHOULD export the Data Record specified by the
+   Exporting Process Reliability Statistics Option Template on a regular
+   basis or based on some export policy.  This periodicity or export
+   policy SHOULD be configurable.
+
+4.4.  The Flow Keys Option Template
+
+   The Flow Keys Option Template specifies the structure of a Data
+   Record for reporting the Flow Keys of reported Flows.  A Flow Keys
+
+
+
+Claise, et al.              Standards Track                    [Page 26]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   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.
+
+5.  IPFIX Message Header "Export Time" and Flow Record Time
+
+   The IPFIX Message Header "Export Time" field is the time in seconds
+   since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves
+   the Exporter.  The time-related Information Elements specified in
+   [RFC5102] MAY use this "Export Time" as base time and specify an
+   offset relative to it, instead of using a common base time, such as
+   0000 UTC Jan 1, 1970.  All Information Elements that do not have
+   their base time defined by their data type MUST have the base time
+   clearly specified in their description.
+
+   For example, Data Records requiring a microsecond precision can
+   export the flow start and end times with the flowStartMicroseconds
+   and flowEndMicroseconds Information Elements [RFC5102], containing
+   the time since 0000 UTC Jan 1, 1970.  An alternate solution is to
+   export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
+   Information Elements [RFC5102] in the Data Record, which respectively
+   report the flow start and end time offsets compared to the IPFIX
+   Message Header "Export Time".  The latter solution lowers the export
+   bandwidth requirement while it increases the load on the Exporter, as
+   the Exporting Process must calculate the flowStartDeltaMicroseconds
+   and flowEndDeltaMicroseconds of every single Data Record before
+   exporting the IPFIX Message.
+
+   It must be noted that using time-related Information Elements with
+   offset times, compared to the IPFIX Message Header "Export Time",
+   imposes some time constraints on the Data Records contained in the
+   IPFIX Message.  In the example of 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.
+
+
+
+Claise, et al.              Standards Track                    [Page 27]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+6.  Linkage with the Information Model
+
+   The Information Elements [RFC5102] MUST be sent in canonical format
+   in network-byte order (also known as the big-endian byte ordering).
+
+6.1.  Encoding of IPFIX Data Types
+
+   The following sections will define the encoding of the data types
+   specified in [RFC5102].
+
+6.1.1.  Integral Data Types
+
+   Integral data types -- octet, signed8, unsigned16, signed16,
+   unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded
+   using the default canonical format in network-byte order.  Signed
+   Integral data types are represented in two's complement notation.
+
+6.1.2.  Address Types
+
+   Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
+   encoded the same way as the integral data types.  The macAddress is
+   treated as a 6-octet integer, the ipv4Address as a 4-octet integer,
+   and the ipv6Address as a 16-octet integer.
+
+6.1.3.  float32
+
+   The float32 data type MUST be encoded as an IEEE single-precision
+   32-bit floating point-type, as specified in [IEEE.754.1985].
+
+6.1.4.  float64
+
+   The float64 data type MUST be encoded as an IEEE double-precision
+   64-bit floating point-type, as specified in [IEEE.754.1985].
+
+6.1.5.  boolean
+
+   The boolean data type is specified according to the TruthValue in
+   [RFC2579]: it is an integer with the value 1 for true and a value 2
+   for false.  Every other value is undefined.  The boolean data type
+   MUST be encoded in a single octet.
+
+6.1.6.  string and octetarray
+
+   The data type string represents a finite length string of valid
+   characters of the Unicode character encoding set.  The string data
+   type MUST be encoded in UTF-8 format.  The string is sent as an array
+   of octets using an Information Element of fixed or variable length.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 28]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   The length of the Information Element specifies the length of the
+   octetarray.
+
+6.1.7.  dateTimeSeconds
+
+   The data type dateTimeseconds represents a time value in units of
+   seconds normalized to the GMT timezone.  It MUST be encoded in a
+   32-bit integer containing the number of seconds since 0000 UTC Jan 1,
+   1970.  The 32-bit integer allows the time encoding up to 136 years.
+
+6.1.8.  dateTimeMilliseconds
+
+   The data type dateTimeMilliseconds represents a time value in units
+   of milliseconds normalized to the GMT timezone.  It MUST be encoded
+   in a 64-bit integer containing the number of milliseconds since 0000
+   UTC Jan 1, 1970.
+
+6.1.9.  dateTimeMicroseconds
+
+   The data type dateTimeMicroseconds represents a time value in units
+   of microseconds normalized to the GMT timezone.  It MUST be encoded
+   in a 64-bit integer, according to the NTP format given in [RFC1305].
+
+6.1.10.  dateTimeNanoseconds
+
+   The data type of dateTimeNanoseconds represents a time value in units
+   of nanoseconds normalized to the GMT time zone.  It MUST be encoded
+   in a 64-bit integer, according to the NTP format given in [RFC1305].
+
+6.2.  Reduced Size Encoding of Integer and Float Types
+
+   Information Elements containing integer, string, float, and
+   octetarray types in the information model MAY be encoded using fewer
+   octets than those implied by their type in the information model
+   definition [RFC5102], based on the assumption that the smaller size
+   is sufficient to carry any value the Exporter may need to deliver.
+   This reduces the network bandwidth requirement between the Exporter
+   and the Collector.  Note that the Information Element definitions
+   [RFC5102] will always define the maximum encoding size.
+
+   For instance, the information model [RFC5102] defines byteCount as an
+   unsigned64 type, which would require 64 bits.  However, if the
+   Exporter will never locally encounter the need to send a value larger
+   than 4294967295, it may chose to send the value instead as an
+   unsigned32.  For example, a core router would require an unsigned64
+   byteCount, while an unsigned32 might be sufficient for an access
+   router.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 29]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   This behavior is indicated by the Exporter by specifying a type size
+   with a smaller length than that associated with the assigned type of
+   the Information Element.  In the example above, the Exporter would
+   place a length of 4 versus 8 in the Template.
+
+   If reduced sizing is used, it MUST only be applied to the following
+   integer types: unsigned64, signed64, unsigned32, signed32,
+   unsigned16, and signed16.  The signed versus unsigned property of the
+   reported value MUST be preserved.  The reduction in size can be to
+   any number of octets smaller than the original type if the data value
+   still fits, i.e., so that only leading zeroes are dropped.  For
+   example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or
+   1 octet(s).
+
+   Reduced sizing can also be used to reduce float64 to float32.  The
+   float32 not only has a reduced number range, but due to the smaller
+   mantissa, is also less precise.
+
+   The reduced size encoding MUST NOT be applied to dateTimeMicroseconds
+   or to dateTimeNanoseconds because these represent an inherent
+   structure that would be destroyed by using less than the original
+   number of bytes.
+
+7.  Variable-Length Information Element
+
+   The IPFIX Template mechanism is optimized for fixed-length
+   Information Elements [RFC5102].  Where an Information Element has a
+   variable length, the following mechanism MUST be used to carry the
+   length information for both the IETF and proprietary Information
+   Elements.
+
+   In the Template Set, the Information Element Field Length is recorded
+   as 65535.  This reserved length value notifies the Collecting Process
+   that length of the Information Element will be carried in the
+   Information Element content itself.
+
+   In most cases, the length of the Information Element will be less
+   than 255 octets.  The following length-encoding mechanism optimizes
+   the overhead of carrying the Information Element length in this
+   majority case.  The length is carried in the octet before the
+   Information Element, as shown in Figure R.
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 30]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Length (< 255)|          Information Element                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      ... continuing as needed                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure R: Variable-Length Information Element (length < 255 octets)
+
+   If the length of the Information Element is greater than or equal to
+   255 octets, the length is encoded into 3 octets before the
+   Information Element.  The first octet is 255, and the length is
+   carried in the second and third octets, as shown in Figure S.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      255      |      Length (0 to 65535)      |       IE      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      ... continuing as needed                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure S: Variable-Length Information Element (length 0 to 65535
+   octets)
+
+   The octets carrying the length (either the first or the first three
+   octets) MUST NOT be included in the length of the Information
+   Element.
+
+8.  Template Management
+
+   This section describes Template Management when using SCTP and
+   PR-SCTP as the transport protocol.  Any necessary changes to Template
+   Management specifically related to TCP or UDP transport protocols are
+   specified in Section 10.
+
+   The Exporting Process assigns and maintains the Template IDs per SCTP
+   association for the Exporter's Observation Domains.  A newly created
+   Template Record is assigned an unused Template ID by the Exporting
+   Process.
+
+   If a specific Information Element is required by a Template, but is
+   not available in observed packets, the Exporting Process MAY choose
+   to export Flow Records without this Information Element in a Data
+   Record defined by a new Template.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 31]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   If an Information Element is required more than once in a Template,
+   the different occurrences of this Information Element SHOULD follow
+   the logical order of their treatments by the Metering Process.  For
+   example, if a selected packet goes through two hash functions, and if
+   the two hash values are sent within a single Template, the first
+   occurrence of the hash value should belong to the first hash function
+   in the Metering Process.  For example, when exporting the two source
+   IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address
+   Information Element occurrence should be the IPv4 address of the
+   outer header, while the second occurrence should be the inner header
+   one.
+
+   Template Sets and Options Template Sets may be sent on any SCTP
+   stream.  Template Sets and Options Template Sets MUST be sent
+   reliably, using SCTP-ordered delivery.  As such, the Collecting
+   Process MUST store the Template Record information for the duration
+   of the SCTP association so that it can interpret the corresponding
+   Data Records that are received in subsequent Data Sets.
+
+   The Exporting Process SHOULD transmit the Template Set and Options
+   Template Set in advance of any Data Sets that use that (Options)
+   Template ID, to help ensure that the Collector has the Template
+   Record before receiving the first Data Record.  Data Records that
+   correspond to a Template Record MAY appear in the same and/or
+   subsequent IPFIX Message(s).
+
+   Different Observation Domains from the same SCTP association may use
+   the same Template ID value to refer to different Templates.
+
+   The Templates that are not used anymore SHOULD be deleted.  Before
+   reusing a Template ID, the Template MUST be deleted.  In order to
+   delete an allocated Template, the Template is withdrawn through the
+   use of a Template Withdrawal Message.
+
+   The Template Withdrawal Message MUST NOT be sent until sufficient
+   time has elapsed to allow the Collecting Process to receive and
+   process the last Data Record using this Template information.  This
+   time MUST be configurable.  A suitable default value is 5 seconds
+   after the last Data Record has been sent.
+
+   The Template ID from a withdrawn Template MUST NOT be reused until
+   sufficient time has elapsed to allow for the Collecting Process to
+   receive and process the Template Withdrawal Message.
+
+   A Template Withdrawal Message is a Template Record for that Template
+   ID with a Field Count of 0.  The format of the Template Withdrawal
+   Message is shown in Figure T.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 32]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+    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 or 3)       |          Length = 16          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Template ID N        |        Field Count = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Template ID ...      |        Field Count = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Template ID M        |        Field Count = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure T: Template Withdrawal Message Format
+
+   The Set ID field MUST contain the value 2 for Template Set Withdrawal
+   and the value 3 for Options Template Set Withdrawal.  Multiple
+   Template IDs MAY be withdrawn with a single Template Withdrawal
+   Message, in that case, padding MAY be used.
+
+   The Template Withdrawal Message withdraws the Template IDs for the
+   Observation Domain ID specified in the IPFIX Message Header.
+
+   The Template Withdrawal Message may be sent on any SCTP stream.  The
+   Template Withdrawal Message MUST be sent reliably, using SCTP-ordered
+   delivery.
+
+   The Template Withdrawal Message MUST NOT contain new Template or
+   Options Template Records.
+
+   If the measurement parameters change such that a new Template is
+   required, the Template MUST be withdrawn (using a Template Withdraw
+   Message and a new Template definition) or an unused Template ID MUST
+   be used.  Examples of the measurement changes are: a new sampling
+   rate, a new Flow expiration process, a new filtering definition, etc.
+
+   When the SCTP association shuts down or the Exporting Process
+   restarts, all Template assignments are lost and Template IDs MUST be
+   reassigned.
+
+   If the Metering Process restarts, the Exporting Process MUST either
+   reuse the previously assigned Template ID for each Template, or it
+   MUST withdraw the previously issued Template IDs by sending Template
+   Withdraw Message(s) before reusing them.
+
+   A Template Withdrawal Message to withdraw all Templates for the
+   Observation Domain ID specified in the IPFIX Message Header MAY be
+   used.  Its format is shown in Figure U.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 33]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+    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 = 8           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Template ID = 2       |        Field Count = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure U: All Data Templates Withdrawal Message Format
+
+   A Template Withdrawal Message to withdraw all Options Templates for
+   the Observation Domain ID specified in the IPFIX Message Header MAY
+   be used.  Its format is shown in Figure V.
+
+    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 = 8           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Template ID = 3       |        Field Count = 0        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Figure V: All Options Templates Withdrawal Message Format
+
+   When the SCTP association restarts, the Exporting Process MUST resend
+   all the Template Records.
+
+9.  The Collecting Process's Side
+
+   This section describes the Collecting Process when using SCTP and
+   PR-SCTP as the transport protocol.  Any necessary changes to the
+   Collecting Process specifically related to TCP or UDP transport
+   protocols are specified in Section 10.
+
+   The Collecting Process SHOULD listen for a new association request
+   from the Exporting Process.  The Exporting Process will request a
+   number of streams to use for export.  An Exporting Process MAY
+   request and support more than one stream per SCTP association.
+
+   If the Collecting Process receives a malformed IPFIX Message, it MUST
+   reset the SCTP association, discard the IPFIX Message, and SHOULD log
+   the error.  Note that non-zero Set padding does not constitute a
+   malformed IPFIX Message.
+
+   Template Sets and Option Template Sets are only sent once.  The
+   Collecting Process MUST store the Template Record information for the
+   duration of the association so that it can interpret the
+   corresponding Data Records that are received in subsequent Data Sets.
+
+
+
+Claise, et al.              Standards Track                    [Page 34]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   Template IDs are unique per SCTP association and per Observation
+   Domain.  If the Collecting Process receives a Template that has
+   already been received but that has not previously been withdrawn
+   (i.e., a Template Record from the same Exporter Observation Domain
+   with the same Template ID received on the SCTP association), then the
+   Collecting Process MUST shut down the association.
+
+   When an SCTP association is closed, the Collecting Process MUST
+   discard all Templates received over that association and stop
+   decoding IPFIX Messages that use those Templates.
+
+   The Collecting Process normally receives Template Records from the
+   Exporting Process before receiving Data Records.  The Data Records
+   are then decoded and stored by the Collector.  If the Template
+   Records have not been received at the time Data Records are received,
+   the Collecting Process MAY store the Data Records for a short period
+   of time and decode them after the Template Records are received.  A
+   Collecting Process MUST NOT assume that the Data Set and the
+   associated Template Set (or Options Template Set) are exported in the
+   same IPFIX Message.
+
+   The Collecting Process MUST note the Information Element identifier
+   of any Information Element that it does not understand and MAY
+   discard that Information Element from the Flow Record.
+
+   The Collector MUST accept padding in Data Records and Template
+   Records.  The padding size is the Set Length minus the size of the
+   Set Header (4 octets for the Set ID and the Set Length), modulo the
+   Record size deduced from the Template Record.
+
+   The IPFIX protocol has a Sequence Number field in the Export header
+   that increases with the number of IPFIX Data Records in the IPFIX
+   Message.  A Collector may detect out-of-sequence, dropped, or
+   duplicate IPFIX Messages by tracking the Sequence Number.  A
+   Collector SHOULD provide a logging mechanism for tracking
+   out-of-sequence IPFIX Messages.  Such out-of-sequence IPFIX Messages
+   may be due to Exporter resource exhaustion where it cannot transmit
+   messages at their creation rate, an Exporting Process reset,
+   congestion on the network link between the Exporter and Collector,
+   Collector resource exhaustion where it cannot process the IPFIX
+   Messages at their arrival rate, out-of-order packet reception,
+   duplicate packet reception, or an attacker injecting false messages.
+
+   If a Collecting Process receives a Template Withdrawal Message, the
+   Collecting Process MUST delete the corresponding Template Records
+   associated with the specific SCTP association and specific
+   Observation Domain, and stop decoding IPFIX Messages that use the
+   withdrawn Templates.
+
+
+
+Claise, et al.              Standards Track                    [Page 35]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   If the Collecting Process receives a Template Withdraw message for a
+   Template Record it has not received before on this SCTP association,
+   it MUST reset the SCTP association, discard the IPFIX Message, and
+   SHOULD log the error as it does for malformed IPFIX Messages.
+
+   A Collecting Process that receives IPFIX Messages from several
+   Observation Domains on the same Transport Session MUST be aware that
+   the uniqueness of the Template ID is not guaranteed across
+   Observation Domains.
+
+   The Collector MUST support the use of Templates containing multiple
+   occurrences of the similar Information Elements.
+
+10.  Transport Protocol
+
+   The IPFIX Protocol Specification has been designed to be transport
+   protocol independent.  Note that the Exporter can export to multiple
+   Collecting Processes using independent transport protocols.
+
+   The IPFIX Message Header 16-bit Length field limits the length of an
+   IPFIX Message to 65535 octets, including the header.  A Collecting
+   Process MUST be able to handle IPFIX Message lengths of up to 65535
+   octets.
+
+10.1.  Transport Compliance and Transport Usage
+
+   We need to differentiate between what must be implemented (so that
+   operators can interoperably deploy compliant implementations from
+   different vendors) and what should or could be used in various
+   operational environments.  We must also make sure that ALL
+   implementations can operate in a congestion-aware and
+   congestion-avoidance mode.
+
+   SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758]
+   MUST be implemented by all compliant implementations.  UDP [UDP] MAY
+   also be implemented by compliant implementations.  TCP [TCP] MAY also
+   be implemented by compliant implementations.
+
+   PR-SCTP SHOULD be used in deployments where Exporters 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 Exporters and Collectors
+   communicate over links that are susceptible to congestion, but
+   PR-SCTP is preferred due to its ability to limit back pressure on
+   Exporters and its message versus stream orientation.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 36]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   UDP MAY be used, although it is not a congestion-aware protocol.
+   However, the IPFIX traffic between Exporter and Collector MUST run in
+   an environment where IPFIX traffic has been provisioned for, or is
+   contained through some other means.
+
+10.2.  SCTP
+
+   This section describes how IPFIX can be transported over SCTP
+   [RFC4960] using the PR-SCTP [RFC3758] extension.
+
+10.2.1.  Congestion Avoidance
+
+   The SCTP transport protocol provides the required level of congestion
+   avoidance by design.
+
+   SCTP will detect congestion in the end-to-end path between the IPFIX
+   Exporting Process and the IPFIX Collecting Process, and limit the
+   transfer rate accordingly.  When an IPFIX Exporting Process has
+   records to export, but detects that transmission by SCTP is
+   temporarily impossible, it can either wait until sending is possible
+   again, or it can decide to drop the record.  In the latter case, the
+   dropped export data MUST be accounted for, so that the amount of
+   dropped export data can be reported.
+
+10.2.2.  Reliability
+
+   The SCTP transport protocol is by default reliable, but has the
+   capability to deliver messages with partial reliability  [RFC3758].
+
+   Using reliable SCTP messages for the IPFIX export is not in itself a
+   guarantee that all Data Records will be delivered.  If there is
+   congestion on the link from the Exporting Process to the Collecting
+   Process, or if a significant number of retransmissions are required,
+   the send queues on the Exporting Process may fill up; the Exporting
+   Process MAY either suspend, export, or discard the IPFIX Messages.
+   If Data Records are discarded the IPFIX Sequence Numbers used for
+   export MUST reflect the loss of data.
+
+10.2.3.  MTU
+
+   SCTP provides the required IPFIX Message fragmentation service based
+   on path MTU discovery.
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 37]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+10.2.4.  Exporting Process
+
+10.2.4.1.  Association Establishment
+
+   The IPFIX Exporting Process SHOULD initiate an SCTP association with
+   the IPFIX Collecting Process.  By default, the Collecting Process
+   listens for connections on SCTP port 4739.  By default, the
+   Collecting Process listens for secure connections on SCTP port 4740
+   (refer to the Security Considerations section).  By default, the
+   Exporting Process tries to connect to one of these ports.  It MUST be
+   possible to configure both the Exporting and Collecting Processes to
+   use a different SCTP port.
+
+   The Exporting Process MAY establish more than one association
+   (connection "bundle" in SCTP terminology) to the Collecting Process.
+
+   An Exporting Process MAY support more than one active association to
+   different Collecting Processes (including the case of different
+   Collecting Processes on the same host).
+
+10.2.4.2.   Association Shutdown
+
+   When an Exporting Process is shut down, it SHOULD shut down the SCTP
+   association.
+
+   When a Collecting Process no longer wants to receive IPFIX Messages,
+   it SHOULD shut down its end of the association.  The Collecting
+   Process SHOULD continue to receive and process IPFIX Messages until
+   the Exporting Process has closed its end of the association.
+
+   When a Collecting Process detects that the SCTP association has been
+   abnormally terminated, it MUST continue to listen for a new
+   association establishment.
+
+   When an Exporting Process detects that the SCTP association to the
+   Collecting Process is abnormally terminated, it SHOULD try to
+   re-establish the association.
+
+   Association timeouts SHOULD be configurable.
+
+10.2.4.3.  Stream
+
+   An Exporting Process MAY request more than one SCTP stream per
+   association.  Each of these streams may be used for the transmission
+   of IPFIX Messages containing Data Sets, Template Sets, and/or Options
+   Template Sets.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 38]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   Depending on the requirements of the application, the Exporting
+   Process may send Data Sets with full or partial reliability, using
+   ordered or out-of-order delivery, over any SCTP stream established
+   during SCTP Association setup.
+
+   An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as
+   per Section 4 of the PR-SCTP [RFC3758] specification when using
+   partial reliability to transmit IPFIX Messages containing only Data
+   Sets.
+
+   However, Exporting Processes SHOULD mark such IPFIX Messages for
+   retransmission for as long as resource or other constraints allow.
+
+10.2.4.4.  Template Management
+
+   When the transport protocol is SCTP, the default Template Management
+   described in Section 8 is used.
+
+10.2.5.  Collecting Process
+
+   When the transport protocol is SCTP, the default Collector processing
+   described in Section 9 is used.
+
+10.2.6.  Failover
+
+   If the Collecting Process does not acknowledge the attempt by the
+   Exporting Process to establish an association, the Exporting Process
+   should retry using the SCTP exponential backoff feature.  The
+   Exporter MAY log an alarm if the time to establish the association
+   exceeds a specified threshold, configurable on the Exporter.
+
+   If Collecting Process failover is supported by the Exporting Process,
+   a second SCTP association MAY be opened in advance.
+
+10.3.  UDP
+
+   This section describes how IPFIX can be transported over UDP [UDP].
+
+10.3.1.  Congestion Avoidance
+
+   UDP has no integral congestion-avoidance mechanism.  Its use over
+   congestion-sensitive network paths is therefore not recommended.  UDP
+   MAY be used in deployments where Exporters and Collectors always
+   communicate over dedicated links that are not susceptible to
+   congestion, i.e., over provisioned links compared to the maximum
+   export rate from the Exporters.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 39]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+10.3.2.  Reliability
+
+   UDP is not a reliable transport protocol, and cannot guarantee
+   delivery of messages.  IPFIX Messages sent from the Exporting Process
+   to the Collecting Process using UDP may therefore be lost.  UDP MUST
+   NOT be used unless the application can tolerate some loss of IPFIX
+   Messages.
+
+   The Collecting Process SHOULD deduce the loss and reordering of IPFIX
+   Data Records by looking at the discontinuities in the IPFIX Sequence
+   Number.  In the case of UDP, the IPFIX Sequence Number contains the
+   total number of IPFIX Data Records sent for the UDP Transport Session
+   prior to the receipt of this IPFIX Message, modulo 2^32.  A Collector
+   SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
+   by tracking the Sequence Number.  Templates sent from the Exporting
+   Process to the Collecting Process using UDP as a transport MUST be
+   re-sent at regular intervals, in case previous copies were lost.
+
+10.3.3.  MTU
+
+   The maximum size of exported messages MUST be configured such that
+   the total packet size does not exceed the path MTU.  If the path MTU
+   is unknown, a maximum packet size of 512 octets SHOULD be used.
+
+10.3.4.  Port Numbers
+
+   By default, the Collecting Process listens on the UDP port 4739.  By
+   default, the Collecting Process listens for secure connections on UDP
+   port 4740 (refer to the "Security Considerations" section).  By
+   default, the Exporting Process tries to connect to one of these
+   ports.  It MUST be possible to configure both the Exporting and
+   Collecting Processes to use a different UDP port.
+
+10.3.5.  Exporting Process
+
+   The Exporting Process MAY duplicate the IPFIX Message to the several
+   Collecting Processes.
+
+10.3.6.  Template Management
+
+   When IPFIX uses UDP as the transport protocol, Template Sets and
+   Option Template Sets MUST be re-sent at regular intervals.  The
+   frequency of the (Options) Template transmission MUST be
+   configurable.  The default value for the frequency of the (Options)
+   Template transmission is 10 minutes.  The Exporting Process SHOULD
+   transmit the Template Set and Options Template Set in advance of any
+   Data Sets that use that (Options) Template ID to help ensure that the
+
+
+
+
+Claise, et al.              Standards Track                    [Page 40]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   Collector has the Template Record before receiving the first Data
+   Record.
+
+   In the event of configuration changes, the Exporting Process SHOULD
+   send multiple copies of the new Template definitions, in different
+   IPFIX Messages, at an accelerated rate.  In such a case, it SHOULD
+   transmit the changed Template Record(s) and Options Template
+   Record(s), without any data, in advance to help ensure that the
+   Collector will have the correct Template information before receiving
+   the first data.
+
+   If the Option Template scope is defined in another Template, then
+   both Templates SHOULD be sent in the same IPFIX Message.  For
+   example, if a Flow Key Option Template (see Section 4.4) is sent in
+   an Option Template, then the associated Template SHOULD be sent in
+   the same IPFIX Message.
+
+   Following a configuration change that can modify the interpretation
+   of the Data Records (for example, a sampling rate change) a new
+   Template ID MUST be used, and the old Template ID MUST NOT be reused
+   until its lifetime (see Section 10.3.7) has expired.
+
+   If UDP is selected as the transport protocol, the Template Withdraw
+   Messages MUST NOT be used, as this method is inefficient due to the
+   unreliable nature of UDP.
+
+10.3.7.  Collecting Process
+
+   The Collecting Process MUST associate a lifetime with each Template
+   (or another definition of an identifier considered unique within the
+   Transport Session) received via UDP.  Templates (and similar
+   definitions) not refreshed by the Exporting Process within the
+   lifetime are expired at the Collecting Process.  If the Template (or
+   other definition) is not refreshed before that lifetime has expired,
+   the Collecting Process MUST discard that definition and any current
+   and future associated Data Records.  In which case, an alarm MUST be
+   logged.  The Collecting Process MUST NOT decode any further Data
+   Records that are associated with the expired Template.  If a Template
+   is refreshed with a Template Record that differs from the previously
+   received Template Record, the Collecting Process SHOULD log a warning
+   and replace the previously received Template Record with the new one.
+   The Template lifetime at the Collecting Process MUST be at least 3
+   times higher than the Template refresh timeout configured on the
+   Exporting Process.
+
+   Template IDs are unique per UDP session and per Observation Domain.
+   At any given time, the Collecting Process SHOULD maintain the
+   following for all the current Template Records and Options Template
+
+
+
+Claise, et al.              Standards Track                    [Page 41]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   Records: <IPFIX Device, Exporter source UDP port, Observation Domain
+   ID, Template ID, Template Definition, Last Received>.
+
+   The Collecting Process SHOULD accept Data Records without the
+   associated Template Record (or other definitions) required to decode
+   the Data Record.  If the Template Records (or other definitions such
+   as Common Properties) have not been received at the time Data Records
+   are received, the Collecting Process SHOULD store the Data Records
+   for a short period of time and decode them after the Template Records
+   (or other definitions) are received.  The short period of time MUST
+   be lower than the lifetime of definitions associated with identifiers
+   considered unique within the UDP session.
+
+   If the Collecting Process receives a malformed IPFIX Message, it MUST
+   discard the IPFIX Message and SHOULD log the error.
+
+10.3.8.  Failover
+
+   Because UDP is not a connection-oriented protocol, the Exporting
+   Process is unable to determine from the transport protocol that the
+   Collecting Process is no longer able to receive the IPFIX Messages.
+   Therefore, it cannot invoke a failover mechanism.  However, the
+   Exporting Process MAY duplicate the IPFIX Message to several
+   Collecting Processes.
+
+10.4.  TCP
+
+   This section describes how IPFIX can be transported over TCP [TCP].
+
+10.4.1.  Connection Management
+
+10.4.1.1.  Connection Establishment
+
+   The IPFIX Exporting Process initiates a TCP connection to the
+   Collecting Process.  By default, the Collecting Process listens for
+   connections on TCP port 4739.  By default, the Collecting Process
+   listens for secure connections on TCP port 4740 (refer to the
+   Security Considerations section).  By default, the Exporting Process
+   tries to connect to one of these ports.  It MUST be possible to
+   configure both the Exporting Process and the Collecting Process to
+   use a different TCP port.
+
+   An Exporting Process MAY support more than one active connection to
+   different Collecting Processes (including the case of different
+   Collecting Processes on the same host).
+
+   The Exporter MAY log an alarm if the time to establish the connection
+   exceeds a specified threshold, configurable on the Exporter.
+
+
+
+Claise, et al.              Standards Track                    [Page 42]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+10.4.1.2.  Graceful Connection Release
+
+   When an Exporting Process is shut down, it SHOULD shut down the TCP
+   connection.
+
+   When a Collecting Process no longer wants to receive IPFIX Messages,
+   it SHOULD close its end of the connection.  The Collecting Process
+   SHOULD continue to read IPFIX Messages until the Exporting Process
+   has closed its end.
+
+10.4.1.3.  Restarting Interrupted Connections
+
+   When a Collecting Process detects that the TCP connection to the
+   Exporting Process has terminated abnormally, it MUST continue to
+   listen for a new connection.
+
+   When an Exporting Process detects that the TCP connection to the
+   Collecting Process has terminated abnormally, it SHOULD try to
+   re-establish the connection.  Connection timeouts and retry schedules
+   SHOULD be configurable.  In the default configuration, an Exporting
+   Process MUST NOT attempt to establish a connection more frequently
+   than once per minute.
+
+10.4.1.4.  Failover
+
+   If the Collecting Process does not acknowledge the attempt by the
+   Exporting Process to establish a connection, it will retry using the
+   TCP exponential backoff feature.
+
+   If Collecting Process failover is supported by the Exporting Process,
+   a second TCP connection MAY be opened in advance.
+
+10.4.2.  Data Transmission
+
+   Once a TCP connection is established, the Exporting Process starts
+   sending IPFIX Messages to the Collecting Process.
+
+10.4.2.1.  IPFIX Message Encoding
+
+   IPFIX Messages are sent over the TCP connection without any special
+   encoding.  The Length field in the IPFIX Message Header defines the
+   end of each IPFIX Message and thus the start of the next IPFIX
+   Message.  This means that IPFIX Messages cannot be interleaved.
+
+   In the case of TCP, the IPFIX Sequence Number contains the total
+   number of IPFIX Data Records sent from this TCP connection, from the
+   current Observation Domain by the Exporting Process, prior to the
+   receipt of this IPFIX Message, modulo 2^32.
+
+
+
+Claise, et al.              Standards Track                    [Page 43]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   If an Exporting Process exports data from multiple Observation
+   Domains, it should be careful to choose IPFIX Message lengths
+   appropriately to minimize head-of-line blocking between different
+   Observation Domains.  Multiple TCP connections MAY be used to avoid
+   head-of-line between different Observation Domains.
+
+10.4.2.2.  Template Management
+
+   For each Template, the Exporting Process MUST send the Template
+   Record before exporting Data Records that refer to that Template.
+
+   Template IDs are unique per TCP connection and per Observation
+   Domain.  A Collecting Process MUST record all Template and Options
+   Template Records for the duration of the connection, as an Exporting
+   Process is not required to re-export Template Records.
+
+   When the TCP connection restarts, the Exporting Process MUST resend
+   all the Template Records.
+
+   When a TCP connection is closed, the Collecting Process MUST discard
+   all Templates received over that connection and stop decoding IPFIX
+   Messages that use those Templates.
+
+   The Templates that are not used anymore SHOULD be deleted.  Before
+   reusing a Template ID, the Template MUST be deleted.  In order to
+   delete an allocated Template, the Template is withdrawn through the
+   use of a Template Withdrawal Message over the TCP connection.
+
+   If the Collecting Process receives a malformed IPFIX Message, it MUST
+   reset the TCP connection, discard the IPFIX Message, and SHOULD log
+   the error.
+
+10.4.2.3.  Congestion Handling and Reliability
+
+   TCP ensures reliable delivery of data from the Exporting Process to
+   the Collecting Process.  TCP also controls the rate at which data can
+   be sent from the Exporting Process to the Collecting Process, using a
+   mechanism that takes into account both congestion in the network and
+   the capabilities of the receiver.
+
+   Therefore, an IPFIX Exporting Process may not be able to send IPFIX
+   Messages at the rate that the Metering Process generates it, either
+   because of congestion in the network or because the Collecting
+   Process cannot handle IPFIX Messages fast enough.  As long as
+   congestion is transient, the Exporting Process can buffer IPFIX
+   Messages for transmission.  But such buffering is necessarily
+   limited, both because of resource limitations and because of
+
+
+
+
+Claise, et al.              Standards Track                    [Page 44]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   timeliness requirements, so ongoing and/or severe congestion may lead
+   to a situation where the Exporting Process is blocked.
+
+   When an Exporting Process has Data Records to export but the
+   transmission buffer is full, and it wants to avoid blocking, it can
+   decide to drop some Data Records.  The dropped Data Records MUST be
+   accounted for, so that the amount can later be exported.
+
+   When an Exporting Process finds that the rate at which records should
+   be exported is consistently higher than the rate at which TCP sending
+   permits, it should provide back pressure to the Metering Processes.
+   The Metering Process could then adapt by temporarily reducing the
+   amount of data it generates, for example, using sampling or
+   aggregation.
+
+10.4.3.  Collecting Process
+
+   The Collecting Process SHOULD listen for a new TCP connection from
+   the Exporting Process.
+
+   If the Collecting Process receives a malformed IPFIX Message, it MUST
+   reset the TCP connection, discard the IPFIX Message, and SHOULD log
+   the error.  Note that non-zero Set padding does not constitute a
+   malformed IPFIX Message.
+
+   Template Sets and Option Template Sets are only sent once.  The
+   Collecting Process MUST store the Template Record information for the
+   duration of the connection so that it can interpret the corresponding
+   Data Records that are received in subsequent Data Sets.
+
+   Template IDs are unique per TCP connection and per Observation
+   Domain.  If the Collecting Process receives a Template that has
+   already been received but that has not previously been withdrawn
+   (i.e., a Template Record from the same Exporter Observation Domain
+   with the same Template ID received on the TCP connection), then the
+   Collecting Process MUST shut down the connection.
+
+   When a TCP connection is closed, the Collecting Process MUST discard
+   all Templates received over that connection and stop decoding IPFIX
+   Messages that use those Templates.
+
+   If a Collecting Process receives a Template Withdrawal Message, the
+   Collecting Process MUST delete the corresponding Template Records
+   associated with the specific TCP connection and specific Observation
+   Domain, and stop decoding IPFIX Messages that use the withdrawn
+   Templates.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 45]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   If the Collecting Process receives a Template Withdrawal Message for
+   a Template Record it has not received before on this TCP connection,
+   it MUST reset the TCP association, discard the IPFIX Message, and
+   SHOULD log the error as it does for malformed IPFIX Messages.
+
+11.  Security Considerations
+
+   The security considerations for the IPFIX protocol have been derived
+   from an analysis of potential security threats, as discussed in the
+   "Security Considerations" section of IPFIX requirements [RFC3917].
+   The requirements for IPFIX security are as follows:
+
+   1. IPFIX must provide a mechanism to ensure the confidentiality of
+      IPFIX data transferred from an Exporting Process to a Collecting
+      Process, in order to prevent disclosure of Flow Records
+      transported via IPFIX.
+
+   2. IPFIX must provide a mechanism to ensure the integrity of IPFIX
+      data transferred from an Exporting Process to a Collecting
+      Process, in order to prevent the injection of incorrect data or
+      control information (e.g., Templates) into an IPFIX Message
+      stream.
+
+   3. IPFIX must provide a mechanism to authenticate IPFIX Collecting
+      and Exporting Processes, to prevent the collection of data from an
+      unauthorized Exporting Process or the export of data to an
+      unauthorized Collecting Process.
+
+   Because IPFIX can be used to collect information for network
+   forensics and billing purposes, attacks designed to confuse, disable,
+   or take information from an IPFIX collection system may be seen as a
+   prime objective during a sophisticated network attack.
+
+   An attacker in a position to inject false messages into an IPFIX
+   Message stream can either affect the application using IPFIX (by
+   falsifying data), or the IPFIX Collecting Process itself (by
+   modifying or revoking Templates, or changing options); for this
+   reason, IPFIX Message integrity is important.
+
+   The IPFIX Messages themselves may also contain information of value
+   to an attacker, including information about the configuration of the
+   network as well as end-user traffic and payload data, so care must be
+   taken to confine their visibility to authorized users.  When an
+   Information Element containing end-user payload information is
+   exported, it SHOULD be transmitted to the Collecting Process using a
+   means that secures its contents against eavesdropping.  Suitable
+   mechanisms include the use of either a direct point-to-point
+   connection or the use of an encryption mechanism.  It is the
+
+
+
+Claise, et al.              Standards Track                    [Page 46]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   responsibility of the Collecting Process to provide a satisfactory
+   degree of security for this collected data, including, if necessary,
+   anonymization of any reported data.
+
+11.1.  Applicability of TLS and DTLS
+
+   Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer
+   Security (DTLS) [RFC4347] were designed to provide the
+   confidentiality, integrity, and authentication assurances required by
+   the IPFIX protocol, without the need for pre-shared keys.
+
+   With the mandatory SCTP and PR-SCTP transport protocols for IPFIX,
+   DTLS [RFC4347] MUST be implemented.  If UDP is selected as the IPFIX
+   transport protocol, DTLS [RFC4347] MUST be implemented.  If TCP is
+   selected as the IPFIX transport protocol, TLS [RFC4346] MUST be
+   implemented.
+
+   Note that DTLS is selected as the security mechanism for SCTP and
+   PR-SCTP.  Though TLS bindings to SCTP are defined in [RFC3436], they
+   require all communication to be over reliable, bidirectional streams,
+   and require one TLS connection per stream.  This arrangement is not
+   compatible with the rationale behind the choice of SCTP as an IPFIX
+   transport protocol.
+
+   Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man
+   in the middle may attempt to take data out of an association and fool
+   the sender into thinking that the data was actually received by the
+   peer.  In generic TLS for SCTP (and/or TCP), this is not possible.
+   This means that the removal of a message may become hidden from the
+   sender or receiver.  Another vulnerability of using PR-SCTP with DTLS
+   is that someone could inject SCTP control information to shut down
+   the SCTP association, effectively generating a loss of IPFIX Messages
+   if those are buffered outside of the SCTP association.  In the
+   future, techniques such as [dtls-for-sctp] could be used to overcome
+   these vulnerabilities.
+
+   When using DTLS over SCTP, the Exporting Process MUST ensure that
+   each IPFIX Message is sent over the same SCTP stream that would be
+   used when sending the same IPFIX Message directly over SCTP.  Note
+   that DTLS may send its own control messages on stream 0 with full
+   reliability; however, this will not interfere with the processing of
+   stream 0 IPFIX Messages at the Collecting Process, because DTLS
+   consumes its own control messages before passing IPFIX Messages up to
+   the application layer.
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 47]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+11.2.  Usage
+
+   The IPFIX Exporting Process initiates the communication to the IPFIX
+   Collecting Process, and acts as a TLS or DTLS client according to
+   [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a
+   TLS or DTLS server.  The DTLS client opens a secure connection on the
+   SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as
+   the transport protocol.  The TLS client opens a secure connection on
+   the TCP port 4740 of the TLS server if TCP is selected as the
+   transport protocol.  The DTLS client opens a secure connection on the
+   UDP port 4740 of the DTLS server if UDP is selected as the transport
+   protocol.
+
+11.3.  Authentication
+
+   IPFIX Exporting Processes and IPFIX Collecting Processes are
+   identified by the fully qualified domain name of the interface on
+   which IPFIX Messages are sent or received, for purposes of X.509
+   client and server certificates as in [RFC3280].
+
+   To prevent man-in-the-middle attacks from impostor Exporting or
+   Collecting Processes, the acceptance of data from an unauthorized
+   Exporting Process, or the export of data to an unauthorized
+   Collecting Process, strong mutual authentication via asymmetric keys
+   MUST be used for both TLS and DTLS.  Each of the IPFIX Exporting and
+   Collecting Processes MUST verify the identity of its peer against its
+   authorized certificates, and MUST verify that the peer's certificate
+   matches its fully qualified domain name, or, in the case of SCTP, the
+   fully qualified domain name of one of its endpoints.
+
+   The fully qualified domain name used to identify an IPFIX Collecting
+   Process or Exporting Process may be stored either in a subjectAltName
+   extension of type dNSName, or in the most specific Common Name field
+   of the Subject field of the X.509 certificate.  If both are present,
+   the subjectAltName extension is given preference.
+
+   Internationalized domain names (IDN) in either the subjectAltName
+   extension of type dNSName or the most specific Common Name field of
+   the Subject field of the X.509 certificate MUST be encoded using
+   Punycode [RFC3492] as described in Section 4 of [RFC3490],
+   "Conversion Operations".
+
+11.4.  Protection against DoS Attacks
+
+   An attacker may mount a denial-of-service (DoS) attack against an
+   IPFIX collection system either directly, by sending large amounts of
+   traffic to a Collecting Process, or indirectly, by generating large
+   amounts of traffic to be measured by a Metering Process.
+
+
+
+Claise, et al.              Standards Track                    [Page 48]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   Direct denial-of-service attacks can also involve state exhaustion,
+   whether at the transport layer (e.g., by creating a large number of
+   pending connections), or within the IPFIX Collecting Process itself
+   (e.g., by sending Flow Records pending Template or scope information,
+   a large amount of Options Template Records, etc.).
+
+   SCTP mandates a cookie-exchange mechanism designed to defend against
+   SCTP state exhaustion denial-of-service attacks.  Similarly, TCP
+   provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN
+   cookies SHOULD be used by any Collecting Process accepting TCP
+   connections.  DTLS also provides cookie exchange to protect against
+   DTLS server state exhaustion.
+
+   The reader should note that there is no way to prevent fake IPFIX
+   Message processing (and state creation) for UDP & SCTP communication.
+   The use of TLS and DTLS can obviously prevent the creation of fake
+   states, but they are themselves prone to state exhaustion attacks.
+   Therefore, Collector rate limiting SHOULD be used to protect TLS &
+   DTLS (like limiting the number of new TLS or DTLS session per second
+   to a sensible number).
+
+   IPFIX state exhaustion attacks can be mitigated by limiting the rate
+   at which new connections or associations will be opened by the
+   Collecting Process, the rate at which IPFIX Messages will be accepted
+   by the Collecting Process, and adaptively limiting the amount of
+   state kept, particularly records waiting on Templates.  These rate
+   and state limits MAY be provided by a Collecting Process; if
+   provided, the limits SHOULD be user configurable.
+
+   Additionally, an IPFIX Collecting Process can eliminate the risk of
+   state exhaustion attacks from untrusted nodes by requiring TLS or
+   DTLS mutual authentication, causing the Collecting Process to accept
+   IPFIX Messages only from trusted sources.
+
+   With respect to indirect denial of service, the behavior of IPFIX
+   under overload conditions depends on the transport protocol in use.
+   For IPFIX over TCP, TCP congestion control would cause the flow of
+   IPFIX Messages to back off and eventually stall, blinding the IPFIX
+   system.  PR-SCTP improves upon this situation somewhat, as some IPFIX
+   Messages would continue to be received by the Collecting Process due
+   to the avoidance of head-of-line blocking by SCTP's multiple streams
+   and partial reliability features, possibly affording some visibility
+   of the attack.  The situation is similar with UDP, as some datagrams
+   may continue to be received at the Collecting Process, effectively
+   applying sampling to the IPFIX Message stream, implying that some
+   forensics may be left.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 49]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   To minimize IPFIX Message loss under overload conditions, some
+   mechanism for service differentiation could be used to prioritize
+   IPFIX traffic over other traffic on the same link.  Alternatively,
+   IPFIX Messages can be transported over a dedicated network.  In this
+   case, care must be taken to ensure that the dedicated network can
+   handle the expected peak IPFIX Message traffic.
+
+11.5.  When DTLS or TLS Is Not an Option
+
+   The use of DTLS or TLS might not be possible in some cases due to
+   performance issues or other operational concerns.
+
+   Without TLS or DTLS mutual authentication, IPFIX Exporting Processes
+   and Collecting Processes can fall back on using IP source addresses
+   to authenticate their peers.  A policy of allocating Exporting
+   Process and Collecting Process IP addresses from specified address
+   ranges, and using ingress filtering to prevent spoofing, can improve
+   the usefulness of this approach.  Again, completely segregating IPFIX
+   traffic on a dedicated network, where possible, can improve security
+   even further.  In any case, the use of open Collecting Processes
+   (those that will accept IPFIX Messages from any Exporting Process
+   regardless of IP address or identity) is discouraged.
+
+   Modern TCP and SCTP implementations are resistant to blind insertion
+   attacks (see [RFC1948], [RFC4960]); however, UDP offers no such
+   protection.  For this reason, IPFIX Message traffic transported via
+   UDP and not secured via DTLS SHOULD be protected via segregation to a
+   dedicated network.
+
+11.6.  Logging an IPFIX Attack
+
+   IPFIX Collecting Processes MUST detect potential IPFIX Message
+   insertion or loss conditions by tracking the IPFIX Sequence Number,
+   and SHOULD provide a logging mechanism for reporting out-of-sequence
+   messages.  Note that an attacker may be able to exploit the handling
+   of out-of-sequence messages at the Collecting Process, so care should
+   be taken in handling these conditions.  For example, a Collecting
+   Process that simply resets the expected Sequence Number upon receipt
+   of a later Sequence Number could be temporarily blinded by deliberate
+   injection of later Sequence Numbers.
+
+   IPFIX Exporting and Collecting Processes SHOULD log any connection
+   attempt that fails due to authentication failure, whether due to
+   being presented an unauthorized or mismatched certificate during TLS
+   or DTLS mutual authentication, or due to a connection attempt from an
+   unauthorized IP address when TLS or DTLS is not in use.
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 50]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   IPFIX Exporting and Collecting Processes SHOULD detect and log any
+   SCTP association reset or TCP connection reset.
+
+11.7.  Securing the Collector
+
+   The security of the Collector and its implementation is important to
+   achieve overall security.  However, it is outside the scope of this
+   document.
+
+12.  IANA Considerations
+
+   IPFIX Messages use two fields with assigned values.  These are the
+   IPFIX Version Number, indicating which version of the IPFIX Protocol
+   was used to export an IPFIX Message, and the IPFIX Set ID, indicating
+   the type for each set of information within an IPFIX Message.
+
+   The IPFIX Version Number value of 10 is reserved for the IPFIX
+   protocol specified in this document.  Set ID values of 0 and 1 are
+   not used for historical reasons [RFC3954].  The Set ID value of 2 is
+   reserved for the Template Set.  The Set ID value of 3 is reserved for
+   the Option Template Set.  All other Set ID values from 4 to 255 are
+   reserved for future use.  Set ID values above 255 are used for Data
+   Sets.
+
+   New assignments in either IPFIX Version Number or IPFIX Set ID
+   assignments require a Standards Action [RFC2434], i.e., they are to
+   be made via Standards Track RFCs approved by the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 51]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+Appendix A.  IPFIX Encoding Examples
+
+   This appendix, which is a not a normative reference, contains IPFIX
+   encoding examples.
+
+   Let's consider the example of an IPFIX Message composed of a Template
+   Set, a Data Set (which contains three Data Records), an Options
+   Template Set and a Data Set (which contains 2 Data Records related to
+   the previous Options Template Record).
+
+   IPFIX Message:
+
+   +--------+------------------------------------------. . .
+   |        | +--------------+ +------------------+
+   |Message | | Template     | | Data             |
+   | Header | | Set          | | Set              |   . . .
+   |        | | (1 Template) | | (3 Data Records) |
+   |        | +--------------+ +------------------+
+   +--------+------------------------------------------. . .
+
+        . . .-------------------------------------------+
+              +------------------+ +------------------+ |
+              | Options          | | Data             | |
+       . . .  | Template Set     | | Set              | |
+              | (1 Template)     | | (2 Data Records) | |
+              +------------------+ +------------------+ |
+        . . .-------------------------------------------+
+
+A.1.  Message Header Example
+
+   The Message Header is composed of:
+    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 = 0x000a          |         Length = 152          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Export Time                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Sequence Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Observation Domain ID                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 52]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+A.2.  Template Set Examples
+
+A.2.1.  Template Set Using IETF-Specified Information Elements
+
+
+   We want to report the following Information Elements:
+
+   - The IPv4 source IP address: sourceIPv4Address in [RFC5102],
+     with a length of 4 octets
+
+   - The IPv4 destination IP address: destinationIPv4Address in
+     [RFC5102], with a length of 4 octets
+
+   - The next-hop IP address (IPv4): ipNextHopIPv4Address in
+     [RFC5102], with a length of 4 octets
+
+   - The number of packets of the Flow: inPacketDeltaCount in
+     [RFC5102], with a length of 4 octets
+
+   - The number of octets of the Flow: inOctetDeltaCount in
+     [RFC5102], with a length of 4 octets
+
+   Therefore, the Template Set will be composed of the following:
+
+    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 = 28 octets       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Template ID 256         |       Field Count = 5         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|    sourceIPv4Address = 8    |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0| destinationIPv4Address = 12 |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   inPacketDeltaCount = 2    |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   inOctetDeltaCount =  1    |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.2.2.  Template Set Using Enterprise-Specific Information Elements
+
+   We want to report the following Information Elements:
+
+   - The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a
+     length of 4 octets
+
+
+
+Claise, et al.              Standards Track                    [Page 53]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   - The IPv4 destination IP address: destinationIPv4Address in
+     [RFC5102], with a length of 4 octets
+
+   - An enterprise-specific Information Element representing proprietary
+     information, with a type of 15 and a length of 4
+
+   - The number of packets of the Flow: inPacketDeltaCount in [RFC5102],
+     with a length of 4 octets
+
+   - The number of octets of the Flow: inOctetDeltaCount in [RFC5102],
+     with a length of 4 octets
+
+   Therefore, the Template Set will be composed of the following:
+
+    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 = 32 octets       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Template ID 257         |       Field Count = 5         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|    sourceIPv4Address = 8    |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0| destinationIPv4Address = 12 |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |1| Information Element Id. = 15|       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Enterprise number                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   inPacketDeltaCount = 2    |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   inOctetDeltaCount = 1     |       Field Length = 4        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 54]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+A.3.  Data Set Example
+
+   In this example, we report the following three Flow Records:
+
+   Src IP addr. | Dst IP addr.  | Next Hop addr. | Packet | Octets
+                |               |                | Number | Number
+   ------------------------------------------------------------------
+   192.0.2.12   | 192.0.2.254   | 192.0.2.1      | 5009   | 5344385
+   192.0.2.27   | 192.0.2.23    | 192.0.2.2      | 748    | 388934
+   192.0.2.56   | 192.0.2.65    | 192.0.2.3      | 5      | 6534
+
+    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 = 256         |          Length = 64          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.12                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.254                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.1                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             5009                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                            5344385                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.27                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.23                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.2                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              748                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             388934                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.56                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.65                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          192.0.2.3                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               5                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              6534                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Note that padding is not necessary in this example.
+
+
+
+Claise, et al.              Standards Track                    [Page 55]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+A.4.  Options Template Set Examples
+
+A.4.1.  Options Template Set Using IETF-Specified Information Elements
+
+   Per line card (the router being composed of two line cards), we want
+   to report the following Information Elements:
+
+   - Total number of IPFIX Messages: exportedPacketCount [RFC5102], with
+     a length of 2 octets
+
+   - Total number of exported Flows: exportedFlowCount [RFC5102], with a
+     length of 2 octets
+
+   The line card, which is represented by the lineCardId Information
+   Element [RFC5102], is used as the Scope Field.
+
+   Therefore, the Options Template Set will be:
+
+    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 = 24          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Template ID 258         |        Field Count = 3        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Scope Field Count = 1     |0|     lineCardId = 141        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Scope 1 Field Length = 4    |0|  exportedPacketCount = 41   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Field Length = 2        |0|   exportedFlowCount = 42    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Field Length = 2        |           Padding             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.2.  Options Template Set Using Enterprise-Specific Information
+        Elements
+
+   Per line card (the router being composed of two line cards), we want
+   to report the following Information Elements:
+
+      - Total number of IPFIX Messages: exportedPacketCount [RFC5102],
+        with a length of 2 octets
+
+      - An enterprise-specific number of exported Flows, with a type of
+        42 and a length of 4 octets
+
+   The line card, which is represented by the lineCardId Information
+   Element [RFC5102], is used as the Scope Field.
+
+
+
+Claise, et al.              Standards Track                    [Page 56]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   The format of the Options Template Set is as follows:
+
+     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 = 28          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Template ID 259         |        Field Count = 3        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     Scope Field Count = 1     |0|     lineCardId = 141        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   Scope 1 Field Length = 4    |0|  exportedPacketCount = 41   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Field Length = 2        |1|Information Element Id. = 42 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Field Length = 4        |       Enterprise number     ...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ...      Enterprise number      |           Padding             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.3.  Options Template Set Using an Enterprise-Specific Scope
+
+   In this example, we want to export the same information as in the
+   example in Section A.4.1:
+
+      - Total number of IPFIX Messages: exportedPacketCount [RFC5102],
+        with a length of 2 octets
+
+      - Total number of exported Flows: exportedFlowCount [RFC5102],
+        with a length of 2 octets
+
+   But this time, the information pertains to a proprietary scope,
+   identified by enterprise-specific Information Element number 123.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 57]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   The format of the Options Template Set is now as follows:
+
+     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 = 28          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Template ID 260         |        Field Count = 3        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     Scope Field Count = 1     |1|Scope 1 Infor. El. Id. = 123 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    Scope 1 Field Length = 4   |       Enterprise Number      ...
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ...       Enterprise Number      |0|  exportedPacketCount = 41   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Field Length = 2        |0|   exportedFlowCount = 42    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       Field Length = 2        |           Padding             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.4.4.  Data Set Using an Enterprise-Specific Scope
+
+   In this example, we report the following two Data Records:
+
+   Line Card ID               | IPFIX Message  | Exported Flow Records
+   -------------------------------------------------------------------
+   Line Card 1 (lineCardId=1) | 345            | 10201
+   Line Card 2 (lineCardId=2) | 690            | 20402
+
+    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 = 260             |         Length = 20           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               1                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             345               |            10201              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               2                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             690               |            20402              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 58]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+A.5.  Variable-Length Information Element Examples
+
+A.5.1.  Example of Variable-Length Information Element with Length
+        Inferior to 255 Octets
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       5       |          5 octet Information Element          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+A.5.2.  Example of Variable-Length Information Element with Length 255
+        to 65535 Octets
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      255      |             1000              |    IE ...     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                1000 octet Information Element                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :                              ...                              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             ... IE            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+References
+
+Normative References
+
+   [RFC1305]       Mills, D., "Network Time Protocol (Version 3)
+                   Specification, Implementation and Analysis", RFC
+                   1305, March 1992.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]       Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26, RFC
+                   2434, October 1998.
+
+   [RFC3280]       Housley, R., Polk, W., Ford, W., and D. Solo,
+                   "Internet X.509 Public Key Infrastructure Certificate
+                   and Certificate Revocation List (CRL) Profile", RFC
+                   3280, April 2002.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 59]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   [RFC3436]       Jungmaier, A., Rescorla, E., and M. Tuexen,
+                   "Transport Layer Security over Stream Control
+                   Transmission Protocol", RFC 3436, December 2002.
+
+   [RFC3758]       Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+                   Conrad, "Stream Control Transmission Protocol (SCTP)
+                   Partial Reliability Extension", RFC 3758, May 2004.
+
+   [RFC4346]       Dierks, T. and E. Rescorla, "The Transport Layer
+                   Security (TLS) Protocol Version 1.1", RFC 4346, April
+                   2006.
+
+   [RFC4347]       Rescorla, E. and N. Modadugu, "Datagram Transport
+                   Layer Security", RFC 4347, April 2006.
+
+   [RFC3490]       Faltstrom, P., Hoffman, P., and A. Costello,
+                   "Internationalizing Domain Names in Applications
+                   (IDNA)", RFC 3490, March 2003.
+
+   [RFC3492]       Costello, A., "Punycode: A Bootstring encoding of
+                   Unicode for Internationalized Domain Names in
+                   Applications (IDNA)", RFC 3492, March 2003.
+
+   [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.
+
+   [TCP]           Postel, J., "Transmission Control Protocol", STD 7,
+                   RFC 793, September 1981.
+
+   [UDP]           Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                   August 1980.
+
+Informative References
+
+   [IPFIX-ARCH]    Sadasivan, G., Brownlee, N., Claise, B., and J.
+                   Quittek, "Architecture Model for IP Flow Information
+                   Export", Work in Progress, September 2006.
+
+   [IPFIX-AS]      Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
+                   "IPFIX Applicability", Work in Progress, June 2007.
+
+   [PEN]           IANA Private Enterprise Numbers registry
+                   http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+
+Claise, et al.              Standards Track                    [Page 60]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+   [RFC1948]       Bellovin, S., "Defending Against Sequence Number
+                   Attacks", RFC 1948, May 1996.
+
+   [RFC2579]       McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+                   "Textual Conventions for SMIv2", STD 58, RFC 2579,
+                   April 1999.
+
+   [RFC3917]       Quittek, J., Zseby, T., Claise, B., and S. Zander,
+                   "Requirements for IP Flow Information Export
+                   (IPFIX)", RFC 3917, October 2004.
+
+   [RFC3550]       Schulzrinne, H., Casner, S., Frederick, R., and V.
+                   Jacobson, "RTP: A Transport Protocol for Real-Time
+                   Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3954]       Claise, B., Ed., "Cisco Systems NetFlow Services
+                   Export Version 9", RFC 3954, October 2004.
+
+   [IEEE.754.1985] Institute of Electrical and Electronics Engineers,
+                   "Standard for Binary Floating-Point Arithmetic", IEEE
+                   Standard 754, August 1985.
+
+   [dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer
+                   Security for Stream Control Transmission Protocol",
+                   Work in Progress, November 2007.
+
+Acknowledgments
+
+   We would like to thank the following persons: Ganesh Sadasivan for
+   his significant contribution during the initial phases of the
+   protocol specification; Juergen Quittek for the coordination job
+   within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and
+   Andrew Johnson for the thorough reviews; Randall Stewart and Peter
+   Lei for their SCTP expertise and contributions; Martin Djernaes for
+   the first essay on the SCTP section; Michael Behringer and Eric
+   Vyncke for their advice and knowledge in security; Michael Tuexen for
+   his help regarding the DTLS section; Elisa Boschi for her
+   contribution regarding the improvement of SCTP sections; Mark
+   Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter
+   Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul
+   Calato, and many more, for the technical reviews and feedback.
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 61]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+Authors' Addresses
+
+   Benoit Claise
+   Cisco Systems
+   De Kleetlaan 6a b1
+   1831 Diegem
+   Belgium
+   Phone: +32 2 704 5622
+   EMail: bclaise@cisco.com
+
+   Stewart Bryant
+   Cisco Systems, Inc.
+   250, Longwater,
+   Green Park,
+   Reading, RG2 6GB,
+   United Kingdom
+   Phone: +44 (0)20 8824-8828
+   EMail: stbryant@cisco.com
+
+   Simon Leinen
+   SWITCH
+   Werdstrasse 2
+   P.O. Box
+   CH-8021 Zurich
+   Switzerland
+   Phone: +41 44 268 1536
+   EMail: simon.leinen@switch.ch
+
+   Thomas Dietz
+   NEC Europe Ltd.
+   NEC Laboratories Europe
+   Network Research Division
+   Kurfuersten-Anlage 36
+   69115 Heidelberg
+   Germany
+   Phone: +49 6221 4342-128
+   EMail: Thomas.Dietz@nw.neclab.eu
+
+   Brian H. Trammell
+   CERT Network Situational Awareness
+   Software Engineering Institute
+   4500 Fifth Avenue
+   Pittsburgh, PA 15213
+   United States
+   Phone: +1 412 268 9748
+   EMail: bht@cert.org
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 62]
+
+RFC 5101              IPFIX Protocol Specification          January 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Claise, et al.              Standards Track                    [Page 63]
+