Encapsulations for In-band OAM Data

This document discusses transport mechanisms for "in-band" operation, administration, and maintenance (OAM) data records. In-band OAM records OAM information within the packet while the packet traverses a particular network domain. The term "in-band" refers to the fact that the OAM data is added to the data packets rather than is being sent within packets specifically dedicated to OAM. A discussion of the motivation and requirements for in-band OAM can be found in . Data types and data formats for in-band OAM are defined in . This document outlines transport encapsulations for the in-band OAM data defined in . This document is to serve informational purposes only. As part of an in-band OAM implementation study different protocol encapsulations for in-band OAM data are being explored. Once data formats and encapsulation approaches are settled, protocol specific specifications for in-band OAM data transport will address the standardization aspect. The data for in-band OAM defined in can be carried in a variety of protocols based on the deployment needs. This document discusses transport of in-band OAM data for the following protocols: IPv6 VXLAN-GPE NSH Segment Routing (IPv6 and MPLS) This list is non-exhaustive, as it is possible to carry the in-band OAM data in several other protocols and transports. A feasibility study of in-band OAM is currently underway as part of the FD.io project . The in-band OAM implementation study should be considered as a "tool box" to showcase how "in-band" OAM can complement probe-packet based OAM mechanisms for different deployments and packet transport formats. For details, see the open source code in the FD.io .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Abbreviations used in this document: Maximum Transmit Unit Operations, Administration, and Maintenance Segment Routing Segment Identifier Network Service Header Proof of Transit Service Function Chain Virtual eXtensible Local Area Network, Generic Protocol Extension

This mechanisms of in-band OAM in IPv6 complement others proposed to enhance diagnostics of IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics Destination Option described in . The IP Performance and Diagnostic Metrics Destination Option is destination focused and specific to IPv6, whereas in-band OAM is performed between end-points of the network or a network domain where it is enabled and used. A historical note: The idea of IPv6 route recording was originally introduced by back in year 2000. With IPv6 now being generally deployed and new concepts such as Segment Routing being introduced, it is imperative to further mature the operations, administration, and maintenance mechanisms available to IPv6 networks. The in-band OAM options translate into options for an IPv6 extension header. The extension header would be inserted by either a host source of the packet, or by a transit/domain-edge node.

This section defines in-band OAM for IPv6 transport. In-band OAM data is transported as an IPv6 hop-by-hop extension header.

Brief recap of the IPv6 hop-by-hop header as well as the options used for carrying in-band OAM data:

In-band OAM data records are inserted as options in an IPv6 hop-by-hop extension header: Tracing Option: The in-band OAM Tracing option defined in is represented as a IPv6 option in hop by hop extension header by allocating following type: 001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_TRACE_OPTION_IPV6. Proof of Transit Option: The in-band OAM POT option defined in is represented as a IPv6 option in hop by hop extension header by allocating following type: 001xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_POT_OPTION_IPV6. Edge to Edge Option: The in-band OAM E2E option defined in is represented as a IPv6 option in hop by hop extension header by allocating following type: 000xxxxxx 8-bit identifier of the type of option. xxxxxx=TBD_IANA_E2E_OPTION_IPV6.

In an administrative domain where in-band OAM is used, insertion of the in-band OAM header is enabled at the required edge nodes by means of configuration. Such a config SHOULD allow selective enablement of in-band OAM header insertion for a subset of traffic (e.g., one or several "pipes"). Further the ingress edge node should be aware of maximum size of the header that can be inserted. Details on how the maximum size/size of the in-band OAM domain are retrieved are outside the scope of this document.

If a network node receives a packet with an in-band OAM header and it is enabled to process in-band OAM data it performs the following:

0)) { populate node data at : node_data_start[Segments Left] Segments Left = Segments Left - 1 } }]]>

VXLAN-GPE encapsulation is somewhat similar to IPv6 extension headers in that a series of headers can be contained in the header as a linked list. The different in-band OAM types are added as options within a new in-band OAM protocol header in VXLAN GPE.

The VXLAN-GPE header and fields are defined in . in-band OAM specific fields and header are defined here: 8-bit unsigned integer defining in-band OAM header type 8-bit unsigned integer. Length of the in-band OAM HDR in 8-octet units Variable-length field, of length such that the complete in-band OAM header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options of the format:

The in-band OAM options defined in are encoded with an option type allocated in the new in-band OAM IANA registry - in-band OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In addition the following padding options are defined to be used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length.

In Service Function Chaining (SFC) , the Network Service Header (NSH) already includes path tracing capabilities , but currently does not offer a solution to securely prove that packets really traversed the service chain. The "Proof of Transit" capabilities (see and ) of in-band OAM can be leveraged within NSH. Proof of transit in-band OAM data is added as NSH Type 2 metadata:

Describes the scope of the "Type" field. In some cases, the TLV Class will identify a specific vendor, in others, the TLV Class will identify specific standards body allocated types. POT is currently defined using the Cisco (0x0009) TLV class. The specific type of information being carried, within the scope of a given TLV Class. Value allocation is the responsibility of the TLV Class owner. Currently a type value of 0x94 is used for proof of transit Two reserved bit are present for future use. The reserved bits MUST be set to 0x0. One bit. Indicates which POT-profile is active. 0 means the even POT-profile is active, 1 means the odd POT-profile is active. Length of the variable metadata, in 4-octet words. Here the length is 4. 64-bit Per packet Random number. 64-bit Cumulative that is updated by the Service Functions.

Similar to NSH, a service chain or path defined using Segment Routing for IPv6 can be verified using the in-band OAM "Proof of Transit" approach. The Segment Routing Header (SRH) for IPv6 offers the ability to transport TLV structured data, similar to what NSH does (see ). A new "POT TLV" is defined for the SRH which is to carry proof of transit in-band OAM data.

To be assigned by IANA. 18. 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. 1 bit. Indicates which POT-profile is active. 0 means the even POT-profile is active, 1 means the odd POT-profile is active. 8 bits. No flags are defined in this document. 64-bit per packet random number. 64-bit cumulative value that is updated at specific nodes that form the service path to be verified.

In-band OAM "Proof of Transit" data can also be carried as part of the MPLS label stack. Details will be addressed in a future version of this document.

IANA considerations will be added in a future version of this document.

Manageability considerations will be addressed ín a later version of this document..

Security considerations will be addressed ín a later version of this document. For a discussion of security requirements of in-band OAM, please refer to .

The authors would like to thank Steve Youell, Eric Vyncke, Nalini Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Nadahalli, and Andrew Yourtchenko for the comments and advice. For the IPv6 encapsulation, this document leverages and builds on top of several concepts described in . The authors would like to acknowledge the work done by the author Hiroshi Kitamura and people involved in writing it.