Export of Structured Data in IP Flow Information Export (IPFIX)
updates
- rfc-5102 — Information Model for IP Flow Information Export
Extracted elements (29)
A mediator translating flat IPFIX records into structured data should use the 'undefined' semantic because RFC 5101 contains no semantic information about list relationships, so any inferred semantic would be a guess.
basicList is RECOMMENDED over a single-field subTemplateList for homogeneous lists of single-valued IEs because basicList requires no additional Template Record. subTemplateList is RECOMMENDED over subTemplateMultiList when all elements share the same type, because subTemplateMultiList carries two extra bytes per group and loses the guarantee of uniform element type.
RFC 5101 IPFIX only supports flat Data Records with single-valued attributes, forcing awkward workarounds for repeated structures. The MPLS label stack problem illustrates this: ten numbered IEs (mplsTopLabelStackSection through mplsLabelStackSection10) were needed, and adding an eleventh could not be placed adjacent in the IANA registry. RFC 6313 introduces structured data types to solve this class of problem.
The Semantic field in a subTemplateMultiList expresses only the top-level relationship across different Template groups; it cannot convey semantics among records within a single Template group. When per-group semantics are required, a basicList of subTemplateLists must be used instead.
The three-byte variable-length encoding is RECOMMENDED for all Structured Data IEs even when the encoded length may be less than 255 bytes. This allows the Exporting Process to begin writing data at a known fixed offset and fill in the final length afterwards, avoiding a two-pass encode.
The RFC 5101 rule requiring multiple occurrences of the same IE in a Template to follow the logical order of their processing by the Metering Process MAY be ignored within Structured Data Information Elements.
The structured data specifications in this document apply equally to PSAMP (RFC 5476) because PSAMP is based on IPFIX. A PSAMP Packet Report is effectively a special IPFIX Flow Record containing information about a single packet.
Unlike classical IPFIX, structured data embeds type information inside Data Records rather than Template Records (e.g., a basicList IE in a Template does not specify the list element type). A Collecting Process must therefore resolve Templates mid-record when decoding subTemplateMultiList content.
A Collecting Process MUST note the Information Element identifier of any IE it does not understand and MAY discard it. A Collector that does not support structured data extensions MAY ignore Structured Data IEs or Data Records containing them while continuing to process other records.
An Exporting Process MUST NOT exceed the maximum allowed IPFIX message length of 65535 bytes, including when encoding complex or recursively-defined structured data.
If a basicList, subTemplateList, or subTemplateMultiList is encoded as a variable-length Information Element of 255 or more octets, it MUST use the three-byte length encoding (leading 0xFF byte followed by a 2-byte length) per RFC 5101 Section 7.
New Information Elements defined in this document MUST be sent in canonical format in network-byte order (big-endian).
Templates that are no longer used SHOULD be deleted via a Template Withdrawal Message. A deleted Template MUST NOT be used in subTemplateList or subTemplateMultiList, and a Template ID MUST be deleted before it can be reused.
The Element Length field in a basicList header MUST NOT be omitted even when the list has zero elements, because it is considered part of the header.
When a Structured Data Information Element contains a single element, the 'undefined' semantic SHOULD be used, since allOf, exactlyOneOf, and oneOrMoreOf would all produce the same result for a single element.
When the Enterprise bit in a basicList Field ID is set to 1, a four-byte Enterprise Number MUST be encoded immediately after the Element Length field.
Padding octets MAY be inserted in structured data field values within a Data Record by including the paddingOctets Information Element in a Template Record referenced by a Structured Data IE, as described in RFC 5101 Section 3.3.1.
Six structured data type semantics express relationships among list elements: undefined (default), noneOf (no element is a property of the record), exactlyOneOf (logical XOR), oneOrMoreOf (logical OR), allOf (all elements apply), and ordered (elements are sequentially ordered). These require a new IANA subregistry.
Structured Data Information Elements MAY be used in Options Template Sets, including as scope fields. This enables encoding of complex aggregated Observation Points (e.g., a PSAMP Selection Sequence Report Interpretation combining multiple router interfaces and linecards) that cannot be expressed with flat IPFIX records.
The basicList abstract data type represents a list of zero or more instances of any single Information Element (e.g., port numbers, interface indexes, BGP AS numbers). It requires no additional Template Record and carries a Semantic field and a single Field ID.
The subTemplateList abstract data type represents a list of zero or more Data Records where every element conforms to the same Template Record. It supports recursive nesting because the referenced Template may itself contain Structured Data Information Elements.
The subTemplateMultiList abstract data type represents a list of zero or more Data Records where each top-level element may correspond to a different Template. Each element carries its own Template ID and Data Records Length, consistent with the IPFIX Set Header format.
A new IANA subregistry 'IPFIX Structured Data Types Semantics' is created with six initial values: undefined (0, default), noneOf (1), exactlyOneOf (2), oneOrMoreOf (3), allOf (4), and ordered (5). The 1-byte Semantic field in every Structured Data IE references this registry.
Three new IPFIX abstract data types are registered with IANA: basicList, subTemplateList, and subTemplateMultiList, along with a new data type semantic 'list'.
Three new IPFIX Information Elements are registered: basicList (IANA IPFIX IE 291), subTemplateList, and subTemplateMultiList, each with the 'list' data type semantic and variable-length encoding.
The security considerations for this extension inherit from RFC 5101. A Collecting Process that does not support structured data can safely ignore unrecognized Structured Data IEs or discard Data Records containing them, providing graceful degradation without protocol-level failures.
basicList encoding: 1-byte Semantic, 2-byte Field ID (MSB is Enterprise bit), 2-byte Element Length (0xFFFF for variable-length elements), optional 4-byte Enterprise Number (present when Enterprise bit is 1), followed by basicList Content. The Element Length field is part of the header and present even for zero-element lists.
subTemplateList encoding: 1-byte Semantic, 2-byte Template ID, followed by subTemplateList Content (zero or more Data Records decoded until no remaining data). A zero-element list encodes only the Semantic and Template ID fields with empty content.
subTemplateMultiList encoding: 1-byte Semantic followed by repeating groups of [2-byte Template ID, 2-byte Data Records Length (inclusive of the 4-byte Template ID and Length fields), followed by zero or more Data Records for that Template]. Further Template groups follow until the overall element length is consumed.