Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5655

Specification of the IP Flow Information Export (IPFIX) File Format

Pages: 64
Proposed Standard
Errata
Part 2 of 3 – Pages 14 to 35
First   Prev   Next

Top   ToC   RFC5655 - Page 14   prevText

6. Applicability

This section describes the specific applicability of IPFIX Files to various use cases. IPFIX Files are particularly useful in a flow collection and processing infrastructure using IPFIX for flow export. We explore the applicability and provide guidelines for using IPFIX Files for the storage of flow data collected by IPFIX Collecting Processes and NetFlow V9 collectors, the testing of IPFIX Collecting Processes, and diagnostics of IPFIX Devices.

6.1. Storage of IPFIX-Collected Flow Data

IPFIX Files can naturally be used to store flow data collected by an IPFIX Collecting Process; indeed, this was one of the primary initial motivations behind the file format described within this document. Using IPFIX Files as such provides a single, standard, well- understood encoding to be used for flow data on disk and on the wire, and allows IPFIX implementations to leverage substantially the same code for flow export and flow storage. In addition, the storage of single Transport Sessions in IPFIX Files is particularly important for network measurement research, allowing repeatability of
Top   ToC   RFC5655 - Page 15
   experiments by providing a format for the storage and exchange of
   IPFIX flow trace data much as the libpcap [pcap] format is used for
   experiments on packet trace data.

6.2. Storage of NetFlow-V9-Collected Flow Data

Although the IPFIX protocol is based on the Cisco NetFlow Services, Version 9 (NetFlow V9) protocol [RFC3954], the two have diverged since work began on IPFIX. However, since the NetFlow V9 information model is a compatible subset of the IPFIX Information Model, it is possible to use IPFIX Files to store collected NetFlow V9 flow data. This approach may be particularly useful in multi-vendor, multi- protocol collection infrastructures using both NetFlow V9 and IPFIX to export flow data. The applicability of IPFIX Files to this use case is outlined in Appendix B.

6.3. Testing IPFIX Collecting Processes

IPFIX Files can be used to store IPFIX Messages for the testing of IPFIX Collecting Processes. A variety of test cases may be stored in IPFIX Files. First, IPFIX data collected in real network environments and stored in an IPFIX File can be used as input to check the behavior of new or extended implementations of IPFIX Collectors. Furthermore, IPFIX Files can be used to validate the operation of a given IPFIX Collecting Process in a new environment, i.e., to test with recorded IPFIX data from the target network before installing the Collecting Process in the network. The IPFIX File format can also be used to store artificial, non- compliant reference messages for specific Collecting Process test cases. Examples for such test cases are sets of IPFIX records with undefined Information Elements, Data Records described by missing Templates, or incorrectly framed Messages or Data Sets. Representative error handling test cases are defined in [RFC5471]. Furthermore, fast replay of IPFIX Messages stored in a file can be used for stress/load tests (e.g., high rate of incoming Data Records, large Templates with high Information Element counts), as described in [RFC5471]. The provisioning and use of a set of reference files for testing simplifies the performance of tests and increases the comparability of test results.
Top   ToC   RFC5655 - Page 16

6.4. IPFIX Device Diagnostics

As an IPFIX File can be used to store any collection of flows, the format may also be used for dumping and storing various types of flow data for IPFIX Device diagnostics (e.g., the open flow cache of a Metering Process or the flow backlog of an Exporting or Collecting Process at the time of a process reset or crash). File-based storage is preferable to remote transmission in such error-recovery situations.

7. Detailed File Format Specification

Any valid serialized IPFIX Message stream MUST be accepted by a File Reader as a valid IPFIX File. In this way, the filesystem is simply treated as another IPFIX transport alongside SCTP, TCP, and UDP, albeit a potentially high-latency transport, as the File Reader and File Writer do not necessarily run at the same time. This section specifies the detailed actions of File Readers and File Writers in handling IPFIX Files, and further specifies actions of File Writers in specific use cases. Unless otherwise specified herein, IPFIX File Writers MUST behave as IPFIX Exporting Processes, and IPFIX File Readers MUST behave as IPFIX Collecting Processes, where appropriate.

7.1. File Reader Specification

An IPFIX File Reader MUST act as an IPFIX Collecting Process as specified in [RFC5101], except as modified by this document. An IPFIX File Reader MUST accept as valid any serialized IPFIX Message stream that would be considered valid by one or more of the other defined IPFIX transport layers. Practically, this means that the union of IPFIX Template management features supported by SCTP, TCP, and UDP MUST be supported in IPFIX Files. File Readers MUST: o accept IPFIX Messages containing Template Sets, Options Template Sets, and Data Sets within the same message, as with IPFIX over TCP or UDP; o accept Template Sets that define Templates already defined within the File, as may occur with retransmission of Templates when using IPFIX over UDP as described in Section 10.3.6 of [RFC5101]; o resolve any conflict between a resent definition and a previous definition by assuming that the new Template replaces the old, as consistent with Template expiration and ID reuse when using UDP at the IPFIX transport protocol; and
Top   ToC   RFC5655 - Page 17
   o  accept Template Withdrawals as described in Section 8 of
      [RFC5101], provided that the Template to be withdrawn is defined,
      as is the case with IPFIX over TCP and SCTP.

   Considering the filesystem-as-transport view, in the general case, an
   IPFIX File SHOULD be treated as containing a single Transport Session
   as defined by [RFC5101].  However, some applications may benefit from
   the ability to treat a collection of IPFIX Files as a single
   Transport Session; see especially Section 7.3.3 below.  A File Reader
   MAY be configurable to treat a collection of Files as a single
   Transport Session.  However, a File Reader MUST NOT treat a single
   IPFIX File as containing multiple Transport Sessions.

   If an IPFIX File uses the technique described in [RFC5473] AND all of
   the non-Options Templates in the File contain the commonPropertiesId
   Information Element, a File Reader MAY assume the set of
   commonPropertiesId definitions provides a complete table of contents
   for the File for searching purposes.

7.2. File Writer Specification

An IPFIX File Writer MUST act as an IPFIX Exporting Process as specified in [RFC5101], except as modified by this document. This section contains specifications for IPFIX File Writers in all situations; specifications and recommendations for specific File Writer use cases are found in Section 7.3 below. File Writers SHOULD store the Templates and Options required to decode the data within the File itself, unless modified by the requirements of a specific use case in a subsection of Section 7.3. In this way, a single IPFIX File generally contains a single notional Transport Session as defined by [RFC5101]. File Writers SHOULD emit each Template Set or Options Template Set to appear in the File before any Data Set described by the Templates within that Set, to ensure the File Reader can decode every Data Set without waiting to process subsequent Templates or Options Templates. File Writers SHOULD emit Data Records described by Options Templates to appear in the File before any Data Records that depend on the scopes defined by those options. File Writers SHOULD use Template Withdrawals to withdraw Templates if Template IDs need to be reused. Template Withdrawals SHOULD NOT be used unless it is necessary to reuse Template IDs. File Writers SHOULD write IPFIX Messages within an IPFIX File in ascending Export Time order.
Top   ToC   RFC5655 - Page 18
   File Writers MAY write Data Records to an IPFIX File in any order.
   However, File Writers that write flow records to an IPFIX File in
   flowStartTime or flowEndTime order SHOULD be consistent in this
   ordering within each File.

7.3. Specific File Writer Use Cases

The specifications in this section apply to specific situations. Each section below extends or modifies the base File Writer specification in Section 7.2. Considerations for collocation of a File Writer with IPFIX Collecting Processes and Metering Processes are given, as are specific guidelines for using IPFIX Files for archival storage, or as documents. Also covered are the use of IPFIX Files in the testing and diagnostics of IPFIX Devices.

7.3.1. Collocating a File Writer with a Collecting Process

When collocating a File Writer with an IPFIX Collecting Process for archival storage of collected data in IPFIX Files as described in Section 6.1, the following recommendations may improve the usefulness of the stored data. The simplest way for a File Writer to store the data collected in a single Transport Session is to simply write the incoming IPFIX Messages to an IPFIX File as they are collected. This approach has several drawbacks. First, if the original Exporting Process did not conform to the recommendations in Section 7.2 with respect to Template and Data Record ordering, the written file can be difficult to use later; in this case, File Writers MAY reorder records as received in order to ensure that Templates appear before the Data Records they describe. A File Writer collocated with a Collecting Process that starts writing data from a running Transport Session SHOULD write all the Templates currently active within that Transport Session before writing any Data Records described by them. Also, the resulting IPFIX Files will lack information about the IPFIX Transport Session used to export them, such as the network addresses of the Exporting and Collecting Processes and the protocols used to transport them. In this case, if information about the Transport Session is required, the File Writer SHOULD store a single IPFIX Transport Session in an IPFIX File and SHOULD record information about the Transport Session using the Export Session Details Options Template described in Section 8.1.3.
Top   ToC   RFC5655 - Page 19
   Additional per-Message information MAY be recorded by the File Writer
   using the Message Details Options Template described in
   Section 8.1.4.  Per-Message information includes the time at which
   each IPFIX Message was received at the Collecting Process, and can be
   used to resend IPFIX Messages while keeping the original measurement
   plane traffic profile.

   When collocating a File Writer with a Collecting Process, the Export
   Time of each Message SHOULD be the Export Time of the Message
   received by the Collecting Process containing the first Data Record
   in the Message.  Note that File Writers storing IPFIX data collected
   from an IPFIX Collecting Process using SCTP as the transport protocol
   SHOULD interleave messages from multiple streams in order to preserve
   Export Time order, and SHOULD reorder the written messages as
   necessary to ensure that each Template Set or Options Template Set
   appears in the File before any Data Set described by the Templates
   within that Set.  Template reordering MUST preserve the sequence of
   Template Sets with Template Withdrawals in order to ensure
   consistency of Templates.

   Note that when adding additional information to IPFIX Messages
   received from Collecting Processes (e.g., Message Checksum Options,
   Message Detail Options), the File Writer SHOULD extend the length of
   the Message for the additional data if possible; otherwise, the
   Message SHOULD be split into two approximately equal-size Messages
   aligned on a Data Set or Template Set boundary from the original
   Message if possible; otherwise, the Message SHOULD be split into two
   approximately equal-size Messages aligned on a Data Record boundary.
   Note that, since the Maximum Segment Size (MSS) or MTU of most
   network links (1500-9000 for common Ethernets) is smaller than the
   maximum IPFIX Message size (65536) within an IPFIX File, it is
   expected that message length extension will suffice in most
   circumstances.

   A File Writer collocated with a Collecting Process SHOULD NOT sign a
   File as specified in Section 9.1 unless the Transport Session over
   which the data was exported was protected via TLS or DTLS, and the
   Collecting Process positively identified the Exporting Process by its
   certificate.  See Section 12.2 for more information on this issue.

7.3.2. Collocating a File Writer with a Metering Process

Note that File Writers may also be collocated directly with IPFIX Metering Processes, for writing measured information directly to disk without intermediate IPFIX Exporting or Collecting Processes. This arrangement may be particularly useful when providing data to an
Top   ToC   RFC5655 - Page 20
   analysis environment with an IPFIX-File-based workflow, when testing
   Metering Processes during development, or when the authentication of
   a Metering Process is important.

   When collocating a File Writer with a Metering Process, note that
   Information Elements associated with Exporting or Collecting
   Processes are meaningless, and SHOULD NOT appear in the Export
   Session Details Options Template described in Section 8.1.3 or the
   Message Details Options Template described in Section 8.1.4.

   When collocating a File Writer with a Metering Process, the Export
   Time of each Message SHOULD be the time at which the first Data
   Record in the Message was received from the Metering Process.

   Note that collocating a File Writer with a Metering Process is the
   only way to provide positive authentication of a Metering Process
   through signatures as in Section 9.1.  See Section 12.2 for more
   information on this issue.

7.3.3. Using IPFIX Files for Archival Storage

While in the general case File Writers should store one Transport Session per IPFIX File, some applications storing large collections of data over long periods of time may benefit from the ability to treat a collection of IPFIX Files as a single Transport Session. A File Writer MAY be configurable to write data from a single Transport Session into multiple IPFIX Files; however, File Writers supporting such a configuration option MUST provide a configuration option to support one-file-per-session behavior for interoperability purposes. File Writers using IPFIX Files for archival storage SHOULD support compression as in Section 10.

7.3.4. Using IPFIX Files as Documents

When IPFIX Files are used as documents, to store a set of flows relevant to query, investigation, or other common context, or for the publication of traffic datasets relevant to network research, each File MUST be readable as a single Transport Session, self-contained aside from any detached signature as in Section 9.1, and making no reference to metadata stored in separate Files, in order to ensure interoperability. When writing Files to be used as documents, File Writers MAY emit the special Data Records described by Options Templates before any other Data Records in the File in the following order to ease the inspection and use of documents by File Readers:
Top   ToC   RFC5655 - Page 21
   o  Time Window records described by the File Time Window Options
      Template as defined in Section 8.1.2 below; followed by:

   o  Information Element Type Records as described in [RFC5610];
      followed by

   o  commonPropertiesId definitions as described in [RFC5473]; followed
      by

   o  Export Session details records described by the Export Session
      Details Options Template as defined in Section 8.1.3 below.

   The Export Time of each Message within a File used as a document
   SHOULD be the time at which the Message was written by the File
   Writer.

   If an IPFIX File used as a document uses the technique described in
   [RFC5473] AND all of the non-Options Templates in the File contain
   the commonPropertiesId Information Element, a File Reader MAY assume
   the set of commonPropertiesId definitions provides a complete table
   of contents for the File for searching purposes.

7.3.5. Using IPFIX Files for Testing

IPFIX Files can be used for testing IPFIX Collecting Processes in two ways. First, IPFIX Files can be used to store specific flow data for regression and stress testing of Collectors; there are no special considerations for IPFIX Files used in this way. Second, IPFIX Files are useful for storing reference messages that do not comply to the IPFIX protocol in order to test the error handling and recovery behavior of Collectors. Of course, IPFIX Files intended to be used in this application necessarily MAY violate any of the specifications in this document or in [RFC5101], and such Files MUST NOT be transmitted to Collecting Processes or given as input to File Readers not under test. Note that an extremely simple IPFIX Exporting Process may be crafted for testing purposes by simply reading an IPFIX File and transmitting it directly to a Collecting Process. Similarly, an extremely simple Collecting Process may be crafted for testing purposes by simply accepting connections and/or IPFIX Messages from Exporting Processes and writing the session's message stream to an IPFIX File.
Top   ToC   RFC5655 - Page 22

7.3.6. Writing IPFIX Files for Device Diagnostics

IPFIX Files can be used in the debugging of devices that use flow data as internal state, as a common format for the representation of flow tables. In such situations, the opaqueOctets information element can be used to store additional non-IPFIX encoded, non-flow information (e.g., stack backtraces, process state, etc.) within the IPFIX File as in Section 11.1; the IPFIX flow table information could also be embedded in a larger proprietary diagnostic format using delimiters as in Section 11.2

7.3.7. IPFIX File Manipulation

For many applications, it may prove useful for implementations to provide functionality for the manipulation of IPFIX Files; for example, to select data from a File, to change the Templates used within a File, or to split or join data in Files. Any such utility should take special care to ensure that its output remains a valid IPFIX File, specifically with respect to Templates and Options, which are scoped to Transport Sessions. Any operation that splits one File into multiple Files SHOULD write all necessary Templates and Options to each resulting File, and ensure that written Options are valid for each resulting File (e.g., the Time Window Options Template in Section 8.1.2). Any operation that joins multiple Files into a single File should do the same, additionally ensuring that Template IDs do not collide, through the use of different Observation Domain IDs or Template ID rewriting. Combining operations may also want to ensure any desired ordering of flow records is maintained.

7.4. Media Type of IPFIX Files

The media type for IPFIX Files is application/ipfix. The registration information [RFC4288] for this media type is given in the IANA Considerations section.

8. File Format Metadata Specification

This section defines the Options Templates used for IPFIX File metadata, and the Information Elements they require.

8.1. Recommended Options Templates for IPFIX Files

The following Options Templates allow IPFIX Message streams to meet the requirements outlined above without extension to the message format or protocol. They are defined in terms of existing Information Elements defined in [RFC5102], the Information Elements
Top   ToC   RFC5655 - Page 23
   defined in [RFC5610], as well as Information Elements defined in
   Section 8.2.  IPFIX File Readers and Writers SHOULD support these
   Options Templates as defined below.

   In addition, IPFIX File Readers and Writers SHOULD support the
   Options Templates defined in [RFC5610] in order to support self-
   description of enterprise-specific Information Elements.

8.1.1. Message Checksum Options Template

The Message Checksum Options Template specifies the structure of a Data Record for attaching an MD5 message checksum to an IPFIX Message. An MD5 message checksum as described MAY be used if data integrity is important to the application but file signing is not available or desired. The described Data Record MUST appear only once per IPFIX Message, but MAY appear anywhere within the Message. This Options Template SHOULD contain the following Information Elements: +--------------------+----------------------------------------------+ | IE | Description | +--------------------+----------------------------------------------+ | messageScope | A marker denoting this Option applies to the | | [scope] | whole IPFIX Message; content is ignored. | | | This Information Element MUST be defined as | | | a Scope Field. | | messageMD5Checksum | The MD5 checksum of the containing IPFIX | | | Message. | +--------------------+----------------------------------------------+

8.1.2. File Time Window Options Template

The File Time Window Options Template specifies the structure of a Data Record for attaching a time window to an IPFIX File; this Data Record is referred to as a time window record. A time window record defines the earliest flow start time and the latest flow end time of the flow records within a File. One and only one time window record MAY appear within an IPFIX File if the time window information is available; a File Writer MUST NOT write more than one time window record to an IPFIX File. A File Writer that writes a time window record to a File MUST NOT write any Flow with a start time before the beginning of the window or an end time after the end of the window to that File. This Options Template SHOULD contain the following Information Elements:
Top   ToC   RFC5655 - Page 24
   +---------------+---------------------------------------------------+
   | IE            | Description                                       |
   +---------------+---------------------------------------------------+
   | sessionScope  | A marker denoting this Option applies to the      |
   | [scope]       | whole IPFIX Transport Session (i.e., the IPFIX    |
   |               | File in the common case); content is ignored.     |
   |               | This Information Element MUST be defined as a     |
   |               | Scope Field.                                      |
   | minFlowStart* | Exactly one of minFlowStartSeconds,               |
   |               | minFlowStartMilliseconds,                         |
   |               | minFlowStartMicroseconds, or                      |
   |               | minFlowStartNanoseconds SHOULD match the          |
   |               | precision of the accompanying maxFlowEnd*         |
   |               | Information Element.  The start time of the       |
   |               | earliest flow in the Transport Session (i.e.,     |
   |               | File).                                            |
   | maxFlowEnd*   | Exactly one of maxFlowEndSeconds,                 |
   |               | maxFlowEndMilliseconds, maxFlowEndMicroseconds,   |
   |               | or maxFlowEndNanoseconds SHOULD match the         |
   |               | precision of the accompanying minFlowStart*       |
   |               | Information Element.  The end time of the latest  |
   |               | flow in the Transport Session (i.e., File).       |
   +---------------+---------------------------------------------------+

8.1.3. Export Session Details Options Template

The Export Session Details Options Template specifies the structure of a Data Record for recording the details of an IPFIX Transport Session in an IPFIX File. It is intended for use in storing a single complete IPFIX Transport Session in a single IPFIX File. The described Data Record SHOULD appear only once in a given IPFIX File. This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted on each Information Element:
Top   ToC   RFC5655 - Page 25
   +----------------------------+--------------------------------------+
   | IE                         | Description                          |
   +----------------------------+--------------------------------------+
   | sessionScope [scope]       | A marker denoting this Option        |
   |                            | applies to the whole IPFIX Transport |
   |                            | Session (i.e., the IPFIX File in the |
   |                            | common case); content is ignored.    |
   |                            | This Information Element MUST be     |
   |                            | defined as a Scope Field.            |
   | exporterIPv4Address        | IPv4 address of the IPFIX Exporting  |
   |                            | Process from which the Messages in   |
   |                            | this Transport Session were          |
   |                            | received.  Present only for          |
   |                            | Exporting Processes with an IPv4     |
   |                            | interface.  For multi-homed SCTP     |
   |                            | associations, this SHOULD be the     |
   |                            | primary path endpoint address of the |
   |                            | Exporting Process.                   |
   | exporterIPv6Address        | IPv6 address of the IPFIX Exporting  |
   |                            | Process from which the Messages in   |
   |                            | this Transport Session were          |
   |                            | received.  Present only for          |
   |                            | Exporting Processes with an IPv6     |
   |                            | interface.  For multi-homed SCTP     |
   |                            | associations, this SHOULD be the     |
   |                            | primary path endpoint address of the |
   |                            | Exporting Process.                   |
   | exporterTransportPort      | The source port from which the       |
   |                            | Messages in this Transport Session   |
   |                            | were received.                       |
   | exporterCertificate        | The certificate used by the IPFIX    |
   |                            | Exporting Process from which the     |
   |                            | Messages in this Transport Session   |
   |                            | were received.  Present only for     |
   |                            | Transport Sessions protected by TLS  |
   |                            | or DTLS.                             |
   | collectorIPv4Address       | IPv4 address of the IPFIX Collecting |
   |                            | Process that received the Messages   |
   |                            | in this Transport Session.  Present  |
   |                            | only for Collecting Processes with   |
   |                            | an IPv4 interface.  For multi-homed  |
   |                            | SCTP associations, this SHOULD be    |
   |                            | the primary path endpoint address of |
   |                            | the Collecting Process.              |
   | collectorIPv6Address       | IPv6 address of the IPFIX Collecting |
   |                            | Process that received the Messages   |
   |                            | in this Transport Session.  Present  |
   |                            | only for Collecting Processes with   |
Top   ToC   RFC5655 - Page 26
   |                            | an IPv6 interface.  For multi-homed  |
   |                            | SCTP associations, this SHOULD be    |
   |                            | the primary path endpoint address of |
   |                            | the Collecting Process.              |
   | collectorTransportPort     | The destination port on which the    |
   |                            | Messages in this Transport Session   |
   |                            | were received.                       |
   | collectorTransportProtocol | The IP Protocol Identifier of the    |
   |                            | transport protocol used to transport |
   |                            | Messages within this Transport       |
   |                            | Session.                             |
   | collectorProtocolVersion   | The version of the export protocol   |
   |                            | used to transport Messages within    |
   |                            | this Transport Session.  Applicable  |
   |                            | only in mixed NetFlow V9-IPFIX       |
   |                            | collection environments when storing |
   |                            | NetFlow V9 data in IPFIX Messages,   |
   |                            | as in Appendix B.                    |
   | collectorCertificate       | The certificate used by the IPFIX    |
   |                            | Collecting Process that received the |
   |                            | Messages in this Transport Session.  |
   |                            | Present only for Transport Sessions  |
   |                            | protected by TLS or DTLS.            |
   | minExportSeconds           | The Export Time of the first Message |
   |                            | in the Transport Session.            |
   | maxExportSeconds           | The Export Time of the last Message  |
   |                            | in the Transport Session.            |
   +----------------------------+--------------------------------------+

8.1.4. Message Details Options Template

The Message Details Options Template specifies the structure of a Data Record for attaching additional export details to an IPFIX Message. These details include the time at which a message was received and information about the export and collection infrastructure used to transport the Message. This Options Template also allows the storage of the export session metadata provided the Export Session Details Options Template, for storing information from multiple Transport Sessions in the same IPFIX File. This Options Template SHOULD contain at least the following Information Elements, subject to applicability as noted for each Information Element. Note that when used in conjunction with the Export Session Details Options Template, when storing a single complete IPFIX Transport Session in an IPFIX File, this Options Template SHOULD contain only the messageScope and
Top   ToC   RFC5655 - Page 27
   collectionTimeMilliseconds Information Elements, and the
   exportSctpStreamId Information Element for Messages transported via
   SCTP.

   +----------------------------+--------------------------------------+
   | IE                         | Description                          |
   +----------------------------+--------------------------------------+
   | messageScope [scope]       | A marker denoting this Option        |
   |                            | applies to the whole IPFIX message;  |
   |                            | content is ignored.  This            |
   |                            | Information Element MUST be defined  |
   |                            | as a Scope Field.                    |
   | collectionTimeMilliseconds | The absolute time at which this      |
   |                            | Message was received by the IPFIX    |
   |                            | Collecting Process.                  |
   | exporterIPv4Address        | IPv4 address of the IPFIX Exporting  |
   |                            | Process from which this Message was  |
   |                            | received.  Present only for          |
   |                            | Exporting Processes with an IPv4     |
   |                            | interface, and if this information   |
   |                            | is not available via the Export      |
   |                            | Session Details Options Template.    |
   |                            | For multi-homed SCTP associations,   |
   |                            | this SHOULD be the primary path      |
   |                            | endpoint address of the Exporting    |
   |                            | Process.                             |
   | exporterIPv6Address        | IPv6 address of the IPFIX Exporting  |
   |                            | Process from which this Message was  |
   |                            | received.  Present only for          |
   |                            | Exporting Processes with an IPv6     |
   |                            | interface and if this information is |
   |                            | not available via the Export Session |
   |                            | Details Options Template.  For       |
   |                            | multi-homed SCTP associations, this  |
   |                            | SHOULD be the primary path endpoint  |
   |                            | address of the Exporting Process.    |
   | exporterTransportPort      | The source port from which this      |
   |                            | Message was received.  Present only  |
   |                            | if this information is not available |
   |                            | via the Export Session Details       |
   |                            | Options Template.                    |
   | exporterCertificate        | The certificate used by the IPFIX    |
   |                            | Exporting Process from which this    |
   |                            | Message was received.  Present only  |
   |                            | for Transport Sessions protected by  |
   |                            | TLS or DTLS.                         |
   | collectorIPv4Address       | IPv4 address of the IPFIX Collecting |
   |                            | Process that received this Message.  |
Top   ToC   RFC5655 - Page 28
   |                            | Present only for Collecting          |
   |                            | Processes with an IPv4 interface,    |
   |                            | and if this information is not       |
   |                            | available via the Export Session     |
   |                            | Details Options Template.  For       |
   |                            | multi-homed SCTP associations, this  |
   |                            | SHOULD be the primary path endpoint  |
   |                            | address of the Collecting Process.   |
   | collectorIPv6Address       | IPv6 address of the IPFIX Collecting |
   |                            | Process that received this Message.  |
   |                            | Present only for Collecting          |
   |                            | Processes with an IPv6 interface,    |
   |                            | and if this information is not       |
   |                            | available via the Export Session     |
   |                            | Details Options Template.  For       |
   |                            | multi-homed SCTP associations, this  |
   |                            | SHOULD be the primary path endpoint  |
   |                            | address of the Collecting Process.   |
   | collectorTransportPort     | The destination port on which this   |
   |                            | Message was received.  Present only  |
   |                            | if this information is not available |
   |                            | via the Export Session Details       |
   |                            | Options Template.                    |
   | collectorTransportProtocol | The IP Protocol Identifier of the    |
   |                            | transport protocol used to transport |
   |                            | this Message.  Present only if this  |
   |                            | information is not available via the |
   |                            | Export Session Details Options       |
   |                            | Template.                            |
   | collectorProtocolVersion   | The version of the export protocol   |
   |                            | used to transport this Message.      |
   |                            | Present only if necessary and if     |
   |                            | this information is not available    |
   |                            | via the Export Session Details       |
   |                            | Options Template.                    |
   | collectorCertificate       | The certificate used by the IPFIX    |
   |                            | Collecting Process that received     |
   |                            | this Message.  Present only for      |
   |                            | Transport Sessions protected by TLS  |
   |                            | or DTLS.                             |
   | exportSctpStreamId         | The SCTP stream used to transport    |
   |                            | this Message.  Present only if the   |
   |                            | Message was transported via SCTP.    |
   +----------------------------+--------------------------------------+
Top   ToC   RFC5655 - Page 29

8.2. Recommended Information Elements for IPFIX Files

The following Information Elements are used by the Options Templates in Section 8.1 to allow IPFIX Message streams to meet the requirements outlined above without extension of the protocol. IPFIX File Readers and Writers SHOULD support these Information Elements as defined below. In addition, IPFIX File Readers and Writers SHOULD support the Information Elements defined in [RFC5610] in order to support full self-description of Information Elements.

8.2.1. collectionTimeMilliseconds

Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element SHOULD be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below. Abstract Data Type: dateTimeMilliseconds ElementId: 258 Status: current

8.2.2. collectorCertificate

Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element, or to its containing IPFIX Message via an options record and the messageScope Information Element. Abstract Data Type: octetArray ElementId: 274 Status: current

8.2.3. exporterCertificate

Description: The full X.509 certificate, encoded in ASN.1 DER format, used by the Collector when IPFIX Messages were transmitted using TLS or DTLS. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and
Top   ToC   RFC5655 - Page 30
      the sessionScope Information Element, or to its containing IPFIX
      Message via an options record and the messageScope Information
      Element.

   Abstract Data Type:   octetArray

   ElementId:   275

   Status:   current

8.2.4. exportSctpStreamId

Description: The value of the SCTP Stream Identifier used by the Exporting Process for exporting IPFIX Message data. This is carried in the Stream Identifier field of the header of the SCTP DATA chunk containing the IPFIX Message(s). Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 259 Status: current

8.2.5. maxExportSeconds

Description: The absolute Export Time of the latest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. Abstract Data Type: dateTimeSeconds ElementId: 260 Status: current Units: seconds

8.2.6. maxFlowEndMicroseconds

Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope
Top   ToC   RFC5655 - Page 31
      Information Element.  This Information Element SHOULD be used only
      in Transport Sessions containing Flow Records with microsecond-
      precision (or better) timestamp Information Elements.

   Abstract Data Type:   dateTimeMicroseconds

   ElementId:   268

   Status:   current

   Units:   microseconds

8.2.7. maxFlowEndMilliseconds

Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond- precision (or better) timestamp Information Elements. Abstract Data Type: dateTimeMilliseconds ElementId: 269 Status: current Units: milliseconds

8.2.8. maxFlowEndNanoseconds

Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements. Abstract Data Type: dateTimeNanoseconds ElementId: 270 Status: current Units: nanoseconds
Top   ToC   RFC5655 - Page 32

8.2.9. maxFlowEndSeconds

Description: The latest absolute timestamp of the last packet within any Flow within the scope containing this Information Element, rounded up to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via IPFIX Options and the sessionScope Information Element. Abstract Data Type: dateTimeSeconds ElementId: 261 Status: current Units: seconds

8.2.10. messageMD5Checksum

Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message. This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. Abstract Data Type: octetArray (16 bytes) ElementId: 262 Status: current Reference: RFC 1321, The MD5 Message-Digest Algorithm [RFC1321]

8.2.11. messageScope

Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Message that contains them. It is defined for general purpose message scoping of options, and proposed specifically to allow the attachment of checksum and collection information to a message via IPFIX Options. The value
Top   ToC   RFC5655 - Page 33
      of this Information Element MUST be written as 0 by the File
      Writer or Exporting Process.  The value of this Information
      Element MUST be ignored by the File Reader or the Collecting
      Process.

   Abstract Data Type:   unsigned8

   ElementId:   263

   Status:   current

8.2.12. minExportSeconds

Description: The absolute Export Time of the earliest IPFIX Message within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. Abstract Data Type: dateTimeSeconds ElementId: 264 Status: current Units: seconds

8.2.13. minFlowStartMicroseconds

Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the microsecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with microsecond- precision (or better) timestamp Information Elements. Abstract Data Type: dateTimeMicroseconds ElementId: 271 Status: current Units: microseconds
Top   ToC   RFC5655 - Page 34

8.2.14. minFlowStartMilliseconds

Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the millisecond if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with millisecond- precision (or better) timestamp Information Elements. Abstract Data Type: dateTimeMilliseconds ElementId: 272 Status: current Units: milliseconds

8.2.15. minFlowStartNanoseconds

Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. This Information Element SHOULD be used only in Transport Sessions containing Flow Records with nanosecond-precision timestamp Information Elements. Abstract Data Type: dateTimeNanoseconds ElementId: 273 Status: current Units: nanoseconds

8.2.16. minFlowStartSeconds

Description: The earliest absolute timestamp of the first packet within any Flow within the scope containing this Information Element, rounded down to the second if necessary. This Information Element SHOULD be bound to its containing IPFIX Transport Session via an options record and the sessionScope Information Element. Abstract Data Type: dateTimeSeconds
Top   ToC   RFC5655 - Page 35
   ElementId:   265

   Status:   current

   Units:   seconds

8.2.17. opaqueOctets

Description: This Information Element is used to encapsulate non- IPFIX data into an IPFIX Message stream, for the purpose of allowing a non-IPFIX data processor to store a data stream inline within an IPFIX File. A Collecting Process or File Writer MUST NOT try to interpret this binary data. This Information Element differs from paddingOctets as its contents are meaningful in some non-IPFIX context, while the contents of paddingOctets MUST be 0x00 and are intended only for Information Element alignment. Abstract Data Type: octetArray ElementId: 266 Status: current

8.2.18. sessionScope

Description: The presence of this Information Element as scope in an Options Template signifies that the options described by the Template apply to the IPFIX Transport Session that contains them. Note that as all options are implicitly scoped to Transport Session and Observation Domain, this Information Element is equivalent to a "null" scope. It is defined for general purpose session scoping of options, and proposed specifically to allow the attachment of time window and collection information to an IPFIX File via IPFIX Options. The value of this Information Element MUST be written as 0 by the File Writer or Exporting Process. The value of this Information Element MUST be ignored by the File Reader or the Collecting Process. Abstract Data Type: unsigned8 ElementId: 267 Status: current


(next page on part 3)

Next Section