RFC 5655
Specification of the IP Flow Information Export (IPFIX) File Format
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
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.
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
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.
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.
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
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:
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.
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.27.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
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:
+---------------+---------------------------------------------------+ | 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:
+----------------------------+--------------------------------------+ | 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 |
| | 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
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. |
| | 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. | +----------------------------+--------------------------------------+
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: current8.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: current8.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
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
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
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: seconds8.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
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
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: milliseconds8.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: nanoseconds8.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
ElementId: 265 Status: current Units: seconds8.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: current8.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)
