Extensions to OSPF for Advertising IFIT Node Capability

IFIT provides a complete framework architecture and a reflection-loop working solution for on-path flow telemetry . At present, there are a family of emerging on-path flow telemetry techniques, including In-situ OAM (IOAM) , PBT , IOAM Direct Export (DEX) , Enhanced Alternate Marking (EAM) , etc. IFIT is a solution focusing on network domains. The "network domain" consists of a set of network devices or entities within a single administration. For example, a network domain can be one or more IGP routing domains. The family of emerging on-path flow telemetry techniques may be selectively or partially implemented in different vendors' devices as an emerging feature for various use cases of application-aware network operations. Hence, in order to enable IFIT applications in a network domain, IFIT node capabilities SHOULD be advertised by every OSPF router in the IGP routing domains.

OSPF: Open Shortest Path First RI: Router Information LSA: Link State Advertisement

IFIT is expected to be deployed in a specific domain referred as the IFIT domain. An IFIT domain may cross multiple network domains. One network domain may consists of multiple IFIT domain. Within the IFIT domain, the IFIT data fields of flow information head MAY be updated by network nodes that the packet traverses.

Each IFIT node is configured with a node-id which uniquely identifies a node within the associated IFIT domain. To accommodate the different use cases or requirements of in-situ flow information telemetry, IFIT data fields updated by network nodes fall into different categories which are referred as different IFIT option types, including IOAM Trace Option-Types , IOAM Edge-to-Edge (E2E) Option-Type , IOAM DEX Option-Type and Enhanced Alternate Marking (EAM) Option-Type . So IFIT Option Types SHOULD be carried in IFIT node capability advertisment.

Given that OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities , this document defnes a new IFIT Node Capability TLV within the body of the OSPF RI Opaque LSA to carry the IFIT node capabilities of the router originating the RI LSA. The IFIT Node Capability TLV is composed of three fields, a two-octet Type field, a two-octet Length field, and 4-octet Value field. The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field in octets. The Value field indicates the IFIT Node Capability, which is a 4-octet IFIT Option Type-enabled Flag. The TLV is padded to 4-octet alignment. The IFIT Node-capability Sub-TLV has the following format:

Type: To be assigned by IANA Length: A 8-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. IFIT Option Type-enabled Flag: A 4-octet field, which is defined as following:

Where: p-Flag: IOAM Pre-allocated Trace Option Type-enabled flag. If p bit is set (1), the router is capable of IOAM Pre-allocated Trace . i-Flag: IOAM Incremental Trace Option Type-enabled flag. If i bit is set (1), the router is capable of IOAM Incremental Tracing . d-Flag: IOAM DEX Option Type-enabled flag. If d bit is set (1), the router is capable of IOAM DEX . e-Flag: IOAM E2E Option Type-enabled flag. If e bit is set (1), the router is capable of IOAM E2E processing . m-Flag: Enhanced Alternative Marking enabled flag. If m bit is set (1), then the router is capable of processing Enhanced Alternative Marking packets . Reserved: MUST be set to zero upon transmission and ignored upon receipt. An IFIT node SHALL be capable of more than one IFIT option types. So in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more than one bit being set.

Note to RFC Editor: this section may be removed on publication as an RFC.

This document makes the following registrations for a TLV type of the new IFIT Node Capability TLV proposed in Section 3 of this document within the body of the OSPF RI Opaque LSA. Type Description TBD IFIT Node Capability

This document introduces new TLVs within the existing OSPF RI Opaque LSA. It does not introduce any new security risks to OSPF.