Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data
Extracted elements (20)
A single NSH Next Protocol code point (0x06) was chosen for all IOAM types, with a sub-type (IOAM-Type) field distinguishing option categories. This avoids the additional TLV nesting that NSH MD Type 2 would require and removes the 256-octet maximum size constraint that MD Type 2's 6-bit length field imposes.
Flat serial TLV structures are preferred over nested TLV structures to be hardware-friendly: nested lookups consume additional gates and processing time in hardware forwarders, making flat structures more efficient.
The encapsulation must support large deployments: using the IOAM Trace Option-Type capturing six data fields per hop over a 15-hop path can add up to 300 octets of IOAM data, exceeding the 256-octet limit of NSH MD Type 2 and motivating the use of a Next Protocol-based approach with no hard size cap.
The applicability of IOAM Active and Loopback flags (RFC 9322) to this NSH encapsulation is outside the scope of this document and may be specified in a future document.
When the IOAM Incremental Trace Option-Type is used, an SFC-aware node acting as an IOAM transit node must adjust the IOAM HDR Len field accordingly, as specified in RFC 9197 Section 4.4.
IOAM-Data-Fields carried in NSH MUST follow the definitions corresponding to IOAM Option-Types as defined in RFC 9197 and RFC 9326.
IOAM transit nodes (e.g., a Service Function Forwarder) MUST process all IOAM headers that are relevant based on their configuration.
Multiple IOAM Option-Types MAY be included within a single NSH encapsulation, chained via the Next Protocol field.
Per RFC 8300 Section 2.2, packets with unsupported Next Protocol values SHOULD be silently dropped by default; thus, an NSH forwarding node that does not support the IOAM header SHOULD drop such packets.
Reserved bits in the IOAM header MUST be set to 0x0 upon transmission and ignored upon receipt.
The O bit in the NSH header MUST be handled following the rules in RFC 9451.
The operator MUST ensure that SFC-aware nodes along the Service Function Path support IOAM; otherwise, packets might be dropped.
IOAM HDR Len is an 8-bit field containing the length of the IOAM header in multiples of 4 octets, including the IOAM-Type and IOAM HDR Len fields themselves.
IOAM Option and Optional Data Space carries IOAM-Data-Fields as specified by the IOAM-Type field; these fields are always aligned to 4 octets, so no padding field is needed.
IOAM-Type is an 8-bit field defining the IOAM Option-Type, as defined in the 'IOAM Option-Type' registry in RFC 9197.
The Next Protocol field in the IOAM header is an 8-bit unsigned integer that determines the type of header following IOAM, with semantics identical to the Next Protocol field in RFC 8300. When multiple IOAM Option-Types are chained, the first uses NP=0x06 to point to the second.
The NSH Next Protocol (NP) value 0x06 is allocated for IOAM, indicating that an IOAM header follows the NSH headers.
IANA allocated code point 0x06 in the 'NSH Next Protocol' registry for IOAM, described as 'IOAM (Next Protocol is an IOAM header)', referencing RFC 9452.
IOAM is a per-domain feature; the operator must properly secure the IOAM domain to avoid malicious configuration and use, including injection of malicious IOAM packets. Additional IOAM security considerations are in RFC 9197 Section 9; additional OAM- and NSH-related security considerations are in RFC 9451 Section 5.
The IOAM header encapsulated in NSH consists of: IOAM-Type (8 bits), IOAM HDR Len (8 bits), Reserved (8 bits, set to 0x0), Next Protocol (8 bits), followed by variable-length IOAM Option and Optional Data Space, all 4-octet aligned. The NSH NP field is set to 0x06 to indicate IOAM follows.