Information Model for Packet Sampling Exports
Extracted elements (25)
A dedicated selectorAlgorithm Information Element is defined even though the selection method can sometimes be inferred from the presence of other IEs. The explicit IE is required so it can be used as scope in Selector Report Interpretation Options Templates, providing unambiguous binding between reported statistics and the selection method that generated them.
PSAMP is built directly on top of IPFIX: a PSAMP Report is a special IPFIX Data Record representing an IPFIX Flow containing only a single packet. This reuse allows the IPFIX information model to serve as the basis for PSAMP Reports, with this document providing only the extensions required.
The information model is formally specified in an XML document (Appendix A) to enable automated syntactical checking and code generation. Although XML-aware tools may benefit collectors, the use of XML is not mandatory in exporters or collectors for PSAMP deployment; the normative specification is the text in Section 8, not the appendix.
PSAMP Information Element IDs were started at 301 to leave a gap for any ongoing IPFIX work requiring new Information Elements below that value. It is expected that IANA will fill this gap with new IPFIX Information Elements over time.
Information Elements pertaining to packet sections (ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection) MUST target no more than the packet header, some subsequent bytes, and any encapsulating headers. Full packet capture of arbitrary packet streams is explicitly out of scope per RFC 2804.
Information Elements SHOULD NOT be overloaded with multiple meanings or re-used for multiple purposes; different Information Elements SHOULD be allocated for each requirement. A separate selectorAlgorithm IE is provided even when the selection method could be inferred from other IEs, in order to serve as explicit scope for Selector Report Interpretation.
The PSAMP Information Elements MUST be constructed from the basic abstract data types and data type semantics described in Section 3 of the IPFIX information model (RFC 5102). The encoding of these data types is described in the IPFIX protocol (RFC 5101).
Four observation timestamp IEs allow reporting packet observation time at different precisions: observationTimeSeconds (322, dateTimeSeconds), observationTimeMilliseconds (323), observationTimeMicroseconds (324), and observationTimeNanoseconds (325), all with quantity semantics.
Hash-based filtering is parameterized by nine IEs: digestHashValue (326, unsigned64), hashIPPayloadOffset (327, unsigned64), hashIPPayloadSize (328, unsigned64), hashOutputRangeMin/Max (329–330, unsigned64), hashSelectedRangeMin/Max (331–332, unsigned64), hashDigestOutput (333, boolean), and hashInitialiserValue (334, unsigned64).
hashDigestOutput (ElementId 333, boolean) indicates whether the hash output is configured to be included in the packet report as a packet digest. When TRUE, the digestHashValue (326) carries that digest.
Measurement accuracy is reported via absoluteError (320, float64) or relativeError (321, float64) for directly measured values, and via the triplet upperCILimit (336), lowerCILimit (337), confidenceLevel (338) — all float64 — for estimated (sampled) values. The three confidence IEs must be used together and should be disregarded if any one is absent.
Random n-out-of-N sampling is configured via samplingSize (ElementId 309, unsigned32, packets) and samplingPopulation (ElementId 310, unsigned32, packets). Uniform probabilistic sampling uses samplingProbability (ElementId 311, float64), a value between 0 and 1 applied equally to every packet.
Selector statistics are reported via selectorIdTotalPktsObserved (ElementId 318, unsigned64, totalCounter) and selectorIdTotalPktsSelected (ElementId 319, unsigned64, totalCounter). Both should be used in an Options Template scoped to the relevant observation, per RFC 5101 Section 3.4.2.1.
selectorAlgorithm (ElementId 304, unsigned16 identifier) identifies the packet selection method in use. Eight initial methods are defined: systematic count-based sampling (1), systematic time-based sampling (2), random n-out-of-N sampling (3), uniform probabilistic sampling (4), property match filtering (5), and hash-based filtering using BOB (6), IPSX (7), or CRC (8).
Systematic count-based sampling is configured via samplingPacketInterval (ElementId 305, unsigned32, packets) — the number of consecutive packets sampled — and samplingPacketSpace (ElementId 306, unsigned32, packets) — the number of packets skipped between intervals.
Systematic time-based sampling is configured via samplingTimeInterval (ElementId 307, unsigned32, microseconds) — the duration during which all packets are sampled — and samplingTimeSpace (ElementId 308, unsigned32, microseconds) — the gap between successive intervals.
The selectorAlgorithm registry is maintained by IANA as an extension of the IPFIX Information Elements registry. Initial values (IDs 1–8) are defined in Section 8.2.1. New assignments require Expert Review per RFC 5226; each new method MUST receive a unique ID and MUST have its configuration parameters clearly specified along with an Options Template reporting method.
This document extends the IPFIX Information Elements registry (maintained by IANA per RFC 5102) with 34 new PSAMP-specific IEs starting at ElementId 301. IDs 301–338 (with some gaps) are assigned; the gap below 301 is intentionally left for future IPFIX elements.
Exporting packet header field values may enable attacks by the receiver that would otherwise require direct on-path observation. The underlying export protocol MUST therefore apply appropriate procedures to guarantee integrity and confidentiality of exported information; such procedures are defined in the IPFIX protocol document (RFC 5101).
informationElementId (ElementId 303) is encoded as unsigned16 with identifier semantics. It carries the ID of another Information Element, enabling meta-referencing within Options Templates.
ipHeaderPacketSection (ElementId 313, octetArray, variable length) carries octets from the start of the IP header of a sampled packet. The data MUST NOT be padded. With sufficient length it may include payload bytes, subject to RFC 2804 wiretapping policy.
ipPayloadPacketSection (ElementId 314, octetArray, variable length) carries octets from the start of the IP payload (post-header for IPv4; post-40-byte header including extension headers for IPv6). The data MUST NOT be padded.
mplsLabelStackSection (ElementId 316, octetArray, variable length) carries the first n octets of the MPLS label stack; mplsPayloadPacketSection (ElementId 317, octetArray) carries the first n octets of the MPLS payload following the label stack. Both MUST NOT be padded.
selectionSequenceId (ElementId 301) is encoded as unsigned64 with identifier semantics. It uniquely identifies, per Observation Domain, both the Observation Point and the sequence of Selectors through which packets are selected.
selectorId (ElementId 302) is encoded as unsigned16 with identifier semantics. It is the unique ID of a Primitive Selector within an Observation Domain.