IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream
Extracted elements (27)
By restricting each Template and its Data Records to a single SCTP stream and enforcing in-order delivery, any Data Record loss detected via the IPFIX Sequence Number can be attributed to the specific Template(s) using that stream, resolving the RFC 5101 limitation where multi-Template associations made per-Template loss calculation impossible.
Exporting Templates and their Data Records in the same ordered SCTP stream ensures Templates always arrive before their associated Data Records, removing the Collecting Process's need to buffer Data Sets while waiting for a Template Record and reducing the risk of Data Record discard.
In-order delivery within a single SCTP stream guarantees that the Template Withdrawal Message arrives before any new Template definition, eliminating the need for the 5-second Template Reuse Delay when reusing Template IDs within the same stream. This delay is still required when reusing on a different stream.
Adding new SCTP streams to an existing association per RFC 6525 requires that both Exporting and Collecting Processes support RFC 6525 stream reconfiguration; without it, the only alternative to accommodate additional Templates is restarting the SCTP association with more streams, potentially causing Flow Record loss.
Exporting Processes implementing this extension interoperate with RFC 5101-compliant Collecting Processes without requiring changes at the Collecting Process; however, Collecting Processes must implement additional support to realize the full benefits (per-Template loss calculation, immediate Template reuse, no Data Set buffering).
A Collecting Process SHOULD support the RFC 6525 procedure for addition of SCTP streams so that the Exporting Process can add new streams dynamically during a Transport Session without restarting the association.
A Template ID MAY be reused on the same SCTP stream immediately after the Template Withdrawal Message is sent (Template Reuse Delay of 0), because in-order delivery guarantees the withdrawal arrives before the new Template definition.
A Template Withdrawal Message to withdraw all Templates for the Observation Domain ID specified in the IPFIX Message header MUST NOT be used under this extension.
After defining a Template ID and before sending any associated Data Records on an SCTP stream, the Exporting Process MUST notify the Collecting Process of its intention to send those Data Records reliably or unreliably by sending a Data Record via the Data Records Reliability Options Template. If it fails to do so, the Collecting Process MUST disable this extension for the SCTP association.
All IPFIX Messages within an SCTP stream MUST be sent in order, enforcing in-order delivery within each stream as a core requirement of this extension.
Any Data Sets associated with a Template Record MUST be sent on the same SCTP stream on which the Template Record was sent.
If a Template ID is to be reused on a different SCTP stream, the new Template Record MUST NOT be sent before the Template Reuse Delay interval, as in-order delivery guarantees do not extend across streams.
If an SCTP stream contains a mixture of Data Records defined by Template Records and Options Template Records, the Data Records defined by the Options Template Records SHOULD be sent reliably so that the Collecting Process does not attribute any loss to Options Data Records.
If the Exporting Process needs to export a new Template Record but no free SCTP streams are available, it SHOULD attempt to increase the number of outbound SCTP streams per RFC 6525 rather than multiplexing Templates onto existing streams.
If the Exporting Process wants to change the dataRecordsReliability value for Data Records on an SCTP stream, the Template MUST be withdrawn and a new Template MUST be used.
It is RECOMMENDED that the Exporting Process send only a single Template and corresponding Data Sets within a single SCTP stream to enable precise calculation of potential Data Record loss for that Template.
PR-SCTP (RFC 3758) MUST be implemented by all compliant implementations of this extension.
The Collecting Process MUST accept other non-scope Information Elements in the Data Records Reliability Options Template beyond the mandatory Template ID scope and dataRecordsReliability non-scope fields.
The Collecting Process MUST detect if the Exporting Process fails to meet the per-SCTP-stream specification. Upon detecting any of the six listed violations, the Collecting Process MUST log an error message and disable this extension for the SCTP association.
The Template Withdrawal Message MUST be sent on the same SCTP stream as the associated Template Record.
The Template Withdrawal Message MUST be sent reliably using SCTP ordered delivery. Because all IPFIX Messages in a stream are sent in order, this guarantees that no Data Records will be lost due to delayed withdrawal arrival at the Collecting Process.
Data Record loss per Template is calculated using the IPFIX Sequence Number: loss = (S2 - (S0 + N0)) mod(2^32), where S0 is the sequence number of the last IPFIX Message before the loss, N0 is the Data Record count in that message, and S2 is the sequence number of the first message after the loss. Unsigned32 arithmetic handles the modulo automatically.
The Data Records Reliability Options Template is used to notify the Collecting Process which Templates are active on each SCTP stream and whether their Data Records will be sent reliably or unreliably. It MUST contain Template ID as scope and dataRecordsReliability as a non-scope Information Element.
The dataRecordsReliability Information Element (ElementId 276) is a boolean (1 octet, 1=True, 2=False) that reports whether the Exporting Process MUST send Data Records associated with the scoped element reliably (True) or MAY send them unreliably (False) within the SCTP stream.
IANA allocated the dataRecordsReliability Information Element (ElementId 276, abstract type boolean, semantics identifier, status current) in the IPFIX Information Elements registry per the process in RFC 5102.
The security considerations from the IPFIX protocol specification (RFC 5101) apply without modification to this extension. No additional security concerns specific to per-SCTP-stream export are identified.
The Collecting Process enables the per-SCTP-stream extension for a Transport Session when the first Data Record received is associated with the Data Records Reliability Options Template; otherwise, the extension MUST NOT be enabled. The extension is disabled (and an error logged) if any of six violation conditions are detected, including: Data Record before reliability notification, cross-stream Template/Data Record mismatch, duplicate reliability notification, unordered message flag set, or unexplained loss in a reliably-declared stream.