Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5101

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

Pages: 63
Obsoleted by:  7011
Part 2 of 3 – Pages 23 to 46
First   Prev   Next

ToP   noToC   RFC5101 - Page 23   prevText

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]:
ToP   noToC   RFC5101 - Page 24
   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.
ToP   noToC   RFC5101 - Page 25
   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
ToP   noToC   RFC5101 - Page 26
                        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
ToP   noToC   RFC5101 - Page 27
   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.
ToP   noToC   RFC5101 - Page 28

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.
ToP   noToC   RFC5101 - Page 29
   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.
ToP   noToC   RFC5101 - Page 30
   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.
ToP   noToC   RFC5101 - Page 31
    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.
ToP   noToC   RFC5101 - Page 32
   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.
ToP   noToC   RFC5101 - Page 33
    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.
ToP   noToC   RFC5101 - Page 34
    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.
ToP   noToC   RFC5101 - Page 35
   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.
ToP   noToC   RFC5101 - Page 36
   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.
ToP   noToC   RFC5101 - Page 37
   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.
ToP   noToC   RFC5101 - Page 38

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.
ToP   noToC   RFC5101 - Page 39
   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.
ToP   noToC   RFC5101 - Page 40

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
ToP   noToC   RFC5101 - Page 41
   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
ToP   noToC   RFC5101 - Page 42
   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.
ToP   noToC   RFC5101 - Page 43
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.
ToP   noToC   RFC5101 - Page 44
   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
ToP   noToC   RFC5101 - Page 45
   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.
ToP   noToC   RFC5101 - Page 46
   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.



(page 46 continued on part 3)

Next Section