E2E:

Edge to Edge

Geneve:

Generic Network Virtualization Encapsulation [RFC 8926]

IOAM:

In situ Operations, Administration, and Maintenance

MTU:

Maximum Transmission Unit

NSH:

Network Service Header [RFC 8300]

OAM:

Operations, Administration, and Maintenance

PMTU:

Path MTU

POT:

Proof of Transit

Short format:

refers to an IOAM-Data-Field that comprises 4 octets

SID:

Segment Identifier

SR:

Segment Routing

VXLAN-GPE:

Virtual eXtensible Local Area Network, Generic Protocol Extension [NVO3-VXLAN-GPE]

Wide format:

refers to an IOAM-Data-Field that comprises 8 octets

Scope:

This document defines the data fields and associated data types for IOAM. The IOAM-Data-Fields can be encapsulated in a variety of protocols, including NSH, Segment Routing, Geneve, and IPv6. Specification details for these different protocols are outside the scope of this document. It is expected that each such encapsulation would be specified by an RFC and jointly designed by the working group that develops or maintains the encapsulation protocol and the IETF IP Performance Measurement (IPPM) Working Group.

Domain (or scope) of in situ OAM deployment:

IOAM is focused on "limited domains", as defined in [RFC 8799]. For IOAM, a limited domain could, for example, be an enterprise campus using physical connections between devices or an overlay network using virtual connections/tunnels for connectivity between said devices. A limited domain that uses IOAM may constitute one or multiple "IOAM-Domains", each disambiguated through separate namespace identifiers. An IOAM-Domain is bounded by its perimeter or edge. IOAM-Domains may overlap inside the limited domain. Designers of protocol encapsulations for IOAM specify mechanisms to ensure that IOAM data stays within an IOAM-Domain. In addition, the operator of such a domain is expected to put provisions in place to ensure that IOAM data does not leak beyond the edge of an IOAM-Domain using, for example, packet filtering methods. The operator SHOULD consider the potential operational impact of IOAM to mechanisms, such as ECMP processing (e.g., load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), PMTU (i.e., ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM), and ICMP message handling (i.e., in case of IPv6, IOAM support for ICMPv6 echo request/reply is desired, which would translate into ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an echo request message to an echo reply message).

IOAM control points:

IOAM-Data-Fields are added to or removed from the user traffic by the devices that form the edge of a domain. Devices that form an IOAM-Domain can add, update, or remove IOAM-Data-Fields. Edge devices of an IOAM-Domain can be hosts or network devices.

Traffic sets that IOAM is applied to:

IOAM can be deployed on all or only on subsets of the user traffic. Using IOAM on a selected set of traffic (e.g., per interface, based on an access control list or flow specification defining a specific set of traffic, etc.) could be useful in deployments where the cost of processing IOAM-Data-Fields by encapsulating, transit, or decapsulating nodes might be a concern from a performance or operational perspective. Thus, limiting the amount of traffic IOAM is applied to could be beneficial in some deployments.

Encapsulation independence:

The definition of IOAM-Data-Fields is independent from the protocols the IOAM-Data-Fields are encapsulated into. IOAM-Data-Fields can be encapsulated into several encapsulating protocols.

Layering:

If several encapsulation protocols (e.g., in case of tunneling) are stacked on top of each other, IOAM-Data-Fields could be present at multiple layers. The behavior follows the "ships-in-the-night" model, i.e., IOAM-Data-Fields in one layer are independent from IOAM-Data-Fields in another layer. Layering allows operators to instrument the protocol layer they want to measure. The different layers could, but do not have to, share the same IOAM encapsulation mechanisms.

IOAM implementation:

The definition of the IOAM-Data-Fields takes the specifics of devices with hardware data planes and software data planes into account.

• Pre-allocated Trace Option-Type
• Incremental Trace Option-Type
• POT Option-Type
• E2E Option-Type

• an operator-assigned range from 0x0001 to 0x7FFF and
• an IANA-assigned range from 0x8000 to 0xFFFF.

• whether one or more IOAM-Option-Types need to be processed by a device. If the Namespace-ID contained in a packet does not match any Namespace-ID the node is configured to operate on, then the node MUST NOT change the contents of the IOAM-Data-Fields.
• which IOAM-Option-Type needs to be processed/updated in case there are multiple IOAM-Option-Types present in the packet. Multiple IOAM-Option-Types can be present in a packet in case of overlapping IOAM-Domains or in case of a layered IOAM deployment.
• whether one or more IOAM-Option-Types have to be removed from the packet, e.g., at a domain edge or domain boundary.

• IOAM-Namespaces can be used by an operator to distinguish different IOAM-Domains. Devices at edges of an IOAM-Domain can filter on Namespace-IDs to provide for proper IOAM-Domain isolation.
• IOAM-Namespaces provide additional context for IOAM-Data-Fields and, thus, can be used to ensure that IOAM-Data-Fields are unique and are interpreted properly by management stations or network controllers. The node identifier field (node_id, see below) does not need to be unique in a deployment. This could be the case if an operator wishes to use different node identifiers for different IOAM layers, even within the same device, or node identifiers might not be unique for other organizational reasons, such as after a merger of two formerly separated organizations. The Namespace-ID can be used as a context identifier, such that the combination of node_id and Namespace-ID will always be unique.
• Similarly, IOAM-Namespaces can be used to define how certain IOAM-Data-Fields are interpreted; IOAM offers three different timestamp format options. The Namespace-ID can be used to determine the timestamp format. IOAM-Data-Fields (e.g., buffer occupancy) that do not have a unit associated are to be interpreted within the context of an IOAM-Namespace.
• IOAM-Namespaces can be used to identify different sets of devices (e.g., different types of devices) in a deployment; if an operator wants to insert different IOAM-Data-Fields based on the device, the devices could be grouped into multiple IOAM-Namespaces. This could be due to the fact that the IOAM feature set differs between different sets of devices, or it could be for reasons of optimized space usage in the packet header. It could also stem from hardware or operational limitations on the size of the trace data that can be added and processed, preventing collection of a full trace for a flow.
• By assigning different IOAM Namespace-IDs to different sets of nodes or network partitions and using a separate instance of an IOAM-Option-Type for each Namespace-ID, a full trace for a flow could be collected and constructed via partial traces from each IOAM-Option-Type in each of the packets in the flow. For example, an operator could choose to group the devices of a domain into two IOAM-Namespaces in a way that each IOAM-Namespace is represented by one of two IOAM-Option-Types in the packet. Each node would record data only for the IOAM-Namespace that it belongs to, ignoring the other IOAM-Option-Type with an IOAM-Namespace to which it doesn't belong. To retrieve a full view of the deployment, the captured IOAM-Data-Fields of the two IOAM-Namespaces need to be correlated.

Pre-allocated Trace-Option:

This trace option is defined as a container of node data fields (see below) with pre-allocated space for each node to populate its information. This option is useful for implementations where it is efficient to allocate the space once and index into the array to populate the data during transit (e.g., software forwarders often fall into this class). The IOAM encapsulating node allocates space for the Pre-allocated Trace Option-Type in the packet and sets corresponding fields in this IOAM-Option-Type. The IOAM encapsulating node allocates an array that is used to store operational data retrieved from every node while the packet traverses the domain. IOAM transit nodes update the content of the array and possibly update the checksums of outer headers. A pointer that is part of the IOAM trace data points to the next empty slot in the array. An IOAM transit node that updates the content of the Pre-allocated Trace-Option also updates the value of the pointer, which specifies where the next IOAM transit node fills in its data. The "node data list" array (see below) in the packet is populated iteratively as the packet traverses the network, starting with the last entry of the array, i.e., "node data list [n]" is the first entry to be populated, "node data list [n-1]" is the second one, etc.

Incremental Trace-Option:

This trace option is defined as a container of node data fields, where each node allocates and pushes its node data immediately following the option header. This type of trace recording is useful for some of the hardware implementations, as it eliminates the need for the transit network elements to read the full array in the option and allows for as arbitrarily long packets as the MTU allows. The IOAM encapsulating node allocates space for the Incremental Trace Option-Type. Based on the operational state and configuration, the IOAM encapsulating node sets the fields in the Option-Type that control what IOAM-Data-Fields have to be collected and how large the node data list can grow. IOAM transit nodes push their node data to the node data list subject to any protocol constraints of the encapsulating layer. They then decrease the remaining length available to subsequent nodes and adjust the lengths and possibly checksums in outer headers.

• Identification of the IOAM node. An IOAM node identifier can match to a device identifier or a particular control point or subsystem within a device.
• Identification of the interface that a packet was received on, i.e., ingress interface.
• Identification of the interface that a packet was sent out on, i.e., egress interface.
• Time of day when the packet was processed by the node, as well as the transit delay. Different definitions of processing time are feasible and expected, though it is important that all devices of an IOAM-Domain follow the same definition.
• Generic data, i.e., format-free information where syntax and semantics of the information is defined by the operator in a specific deployment. For a specific IOAM-Namespace, all IOAM nodes have to interpret the generic data the same way. Examples for generic IOAM data include geolocation information (location of the node at the time the packet was processed), buffer queue fill level or cache fill level at the time the packet was processed, or even a battery-charge level.
• Information to detect whether IOAM trace data was added at every hop or whether certain hops in the domain weren't IOAM transit nodes.

 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |NodeLen  | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               IOAM Trace-Type                 |  Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                                                               |  |
|                        node data list [0]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  D
|                                                               |  a
|                        node data list [1]                     |  t
|                                                               |  a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
~                             ...                               ~  S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  p
|                                                               |  a
|                        node data list [n-1]                   |  c
|                                                               |  e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
|                        node data list [n]                     |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

Namespace-ID:

16-bit identifier of an IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" (see Section 4.3) and MUST be known to all the nodes implementing IOAM. For any other Namespace-ID value that does not match any Namespace-ID the node is configured to operate on, the node MUST NOT change the contents of the IOAM-Data-Fields.

NodeLen:

5-bit unsigned integer. This field specifies the length of data added by each node in multiples of 4 octets, excluding the length of the "Opaque State Snapshot" field.

If IOAM Trace-Type Bit 22 is not set, then NodeLen specifies the actual length added by each node. If IOAM Trace-Type Bit 22 is set, then the actual length added by a node would be (NodeLen + length of the "Opaque State Snapshot" field) in 4-octet units.

For example, if 3 IOAM Trace-Type bits are set and none of them are in wide format, then NodeLen would be 3. If 3 IOAM Trace-Type bits are set and 2 of them are wide, then NodeLen would be 5.

An IOAM encapsulating node MUST set NodeLen.

A node receiving an IOAM Pre-allocated or Incremental Trace-Option relies on the NodeLen value.

Flags:

4-bit field. Flags are allocated by IANA, as specified in Section 7.3. This document allocates a single flag as follows:

Bit 0:

"Overflow" (O-bit) (most significant bit). In case a network element is supposed to add node data to a packet but detects that there are not enough octets left to record the node data, the network element MUST NOT add any fields and MUST set the overflow "O-bit" to "1" in the IOAM Trace-Option header. This is useful for transit nodes to ignore further processing of the option.

RemainingLen:

7-bit unsigned integer. This field specifies the data space in multiples of 4 octets remaining for recording the node data before the node data list is considered to have overflowed. The sender MUST assign the initial value of the RemainingLen field. The sender MAY calculate the value of the RemainingLen field by computing the number of node data bytes allowed before exceeding the PMTU, given that the PMTU is known to the sender. Subsequent nodes can carry out a simple comparison between RemainingLen and NodeLen, along with the length of the "Opaque State Snapshot", if applicable, to determine whether or not data can be added by this node. When node data is added, the node MUST decrease RemainingLen by the amount of data added. In the Pre-allocated Trace-Option, RemainingLen is used to derive the offset in data space to record the node data element. Specifically, the recording of the node data element would start from RemainingLen - NodeLen - size of (opaque snapshot) in 4-octet units. If RemainingLen in a Pre-allocated Trace-Option exceeds the length of the option, as specified in the lower-layer header (which is not within the scope of this document), then the node MUST NOT add any fields.

IOAM Trace-Type:

24-bit identifier that specifies which data types are used in this node data list.

The IOAM Trace-Type value is a bit field. The following bits are defined in this document, with details on each bit described in Section 4.4.2. The order of packing the data fields in each node data element follows the bit order of the IOAM Trace-Type field as follows:

Bit 0

Most significant bit. When set, indicates the presence of Hop_Lim and node_id (short format) in the node data.

Bit 1

When set, indicates the presence of ingress_if_id and egress_if_id (short format) in the node data.

Bit 2

When set, indicates the presence of timestamp seconds in the node data.

Bit 3

When set, indicates the presence of timestamp fraction in the node data.

Bit 4

When set, indicates the presence of transit delay in the node data.

Bit 5

When set, indicates the presence of IOAM-Namespace-specific data in short format in the node data.

Bit 6

When set, indicates the presence of queue depth in the node data.

Bit 7

When set, indicates the presence of the Checksum Complement node data.

Bit 8

When set, indicates the presence of Hop_Lim and node_id in wide format in the node data.

Bit 9

When set, indicates the presence of ingress_if_id and egress_if_id in wide format in the node data.

Bit 10

When set, indicates the presence of IOAM-Namespace-specific data in wide format in the node data.

Bit 11

When set, indicates the presence of buffer occupancy in the node data.

Bits 12-21

Undefined. These values are available for future assignment in the IOAM Trace-Type Registry (Section 7.2). Every future node data field corresponding to one of these bits MUST be 4 octets long. An IOAM encapsulating node MUST set the value of each undefined bit to 0. If an IOAM transit node receives a packet with one or more of these bits set to 1, it MUST either:

1. add corresponding node data filled with the reserved value 0xFFFFFFFF after the node data fields for the IOAM Trace-Type bits defined above, such that the total node data added by this node in units of 4 octets is equal to NodeLen or
2. not add any node data fields to the packet, even for the IOAM Trace-Type bits defined above.

Bit 22

When set, indicates the presence of the variable-length Opaque State Snapshot field.

Bit 23

Reserved; MUST be set to zero upon transmission and be ignored upon receipt. This bit is reserved to allow for future extensions of the IOAM Trace-Type bit field.

Section 4.4.2 describes the IOAM-Data-Types and their formats. Within an IOAM-Domain, possible combinations of these bits making the IOAM Trace-Type can be restricted by configuration knobs.

Reserved:

8 bits. An IOAM encapsulating node MUST set the value to zero upon transmission. IOAM transit nodes MUST ignore the received value.

Node data List [n]:

Variable-length field. This is a list of node data elements where the content of each node data element is determined by the IOAM Trace-Type. The order of packing the data fields in each node data element follows the bit order of the IOAM Trace-Type field. Each node MUST prepend its node data element in front of the node data elements that it received, such that the transmitted node data list begins with this node's data element as the first populated element in the list. The last node data element in this list is the node data of the first IOAM-capable node in the path. Populating the node data list in this way ensures that the order of the node data list is the same for Incremental and Pre-allocated Trace-Options. In the Pre-allocated Trace-Option, the index contained in RemainingLen identifies the offset for current active node data to be populated.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hop_Lim:

1-octet unsigned integer. It is set to the Hop Limit value in the packet at egress from the node that records this data. Hop Limit information is used to identify the location of the node in the communication path. This is copied from the lower layer, e.g., TTL value in IPv4 header or Hop Limit field from IPv6 header of the packet when the packet is ready for transmission. The semantics of the Hop_Lim field depend on the lower-layer protocol that IOAM is encapsulated into; therefore, its specific semantics are outside the scope of this memo. The value of this field MUST be set to 0xff when the lower level does not have a field equivalent to TTL / Hop Limit.

node_id:

3-octet unsigned integer. A node identifier field to uniquely identify a node within the IOAM-Namespace and associated IOAM-Domain. The procedure to allocate, manage, and map the node_ids is beyond the scope of this document. See [IPPM-IOAM-DEPLOYMENT] for a discussion of deployment-related aspects of the node_id.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ingress_if_id:

2-octet unsigned integer. An interface identifier to record the ingress interface the packet was received on.

egress_if_id:

2-octet unsigned integer. An interface identifier to record the egress interface the packet is forwarded out of.

1. recompute the UDP Checksum field or
2. use the Checksum Complement to make a checksum-neutral update in the UDP payload; the Checksum Complement is assigned a value that complements the rest of the node data fields that were added by the current node, causing the existing UDP Checksum field to remain correct.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Checksum Complement                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         node_id (contd)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hop_Lim:

1-octet unsigned integer. See Section 4.4.2.1 for the definition of the field.

node_id:

7-octet unsigned integer. It is a node identifier field to uniquely identify a node within the IOAM-Namespace and associated IOAM-Domain. The procedure to allocate, manage, and map the node_ids is beyond the scope of this document.

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ingress_if_id                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       egress_if_id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ingress_if_id:

4-octet unsigned integer. It is an interface identifier to record the ingress interface the packet was received on.

egress_if_id:

4-octet unsigned integer. It is an interface identifier to record the egress interface the packet is forwarded out of.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length      |                     Schema ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length:

1-octet unsigned integer. It is the length in multiples of 4 octets of the Opaque data field that follows Schema ID.

Schema ID:

3-octet unsigned integer identifying the schema of Opaque data.

Opaque data:

Variable-length field. This field is interpreted as specified by the schema identified by the Schema ID.

0xD40000:

If the IOAM Trace-Type is 0xD40000 (0b110101000000000000000000), then the format of node data is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     timestamp fraction                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0xC00000:

If the IOAM Trace-Type is 0xC00000 (0b110000000000000000000000), then the format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ingress_if_id             |         egress_if_id          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0x900000:

If the IOAM Trace-Type is 0x900000 (0b100100000000000000000000), then the format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   timestamp fraction                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

0x840000:

If the IOAM Trace-Type is 0x840000 (0b100001000000000000000000), then the format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0x940000:

If the IOAM Trace-Type is 0x940000 (0b100101000000000000000000), then the format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    namespace-specific data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0x308002:

If the IOAM Trace-Type is 0x308002 (0b001100001000000000000010), then the format is:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      timestamp seconds                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    timestamp fraction                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Hop_Lim     |              node_id                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node_id(contd)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Length      |                     Schema ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                        Opaque data                            |
~                                                               ~
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PktID:

unique identifier for the packet

Cumulative:

information that is handed from node to node and updated by every node according to a verification algorithm

 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Namespace-ID            |IOAM POT-Type  | IOAM POT flags| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       POT Option data field determined by IOAM POT-Type       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Namespace-ID:

16-bit identifier of an IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" (see Section 4.3) and MUST be known to all the nodes implementing IOAM. For any other Namespace-ID value that does not match any Namespace-ID the node is configured to operate on, the node MUST NOT change the contents of the IOAM-Data-Fields.

IOAM POT-Type:

8-bit identifier of a particular POT variant that specifies the POT data that is included. This document defines IOAM POT-Type 0:

0:

POT data is a 16-octet field to carry data associated to POT procedures.

If a node receives an IOAM POT-Type value that it does not understand, the node MUST NOT change, add to, or remove the contents of the IOAM-Data-Fields.

IOAM POT flags:

8 bits. This document does not define any flags. Bits 0-7 are available for assignment (see Section 7.5). Bits that have not been assigned MUST be set to zero upon transmission and be ignored upon receipt.

POT Option data:

Variable-length field. The type of which is determined by the IOAM POT-Type.

  
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |IOAM POT-Type=0|R R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                        PktID                                  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  P
|                        PktID (contd)                          |  O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  T
|                        Cumulative                             |  | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                        Cumulative (contd)                     |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+

Namespace-ID:

16-bit identifier of an IOAM-Namespace (see Section 4.3 above).

IOAM POT-Type:

8-bit identifier of a particular POT variant that specifies the POT data that is included (see Section 4.5 above). For this case here, IOAM POT-Type is set to the value 0.

Bit 0-7:

Undefined (see Section 4.5 above).

PktID:

64-bit packet identifier.

Cumulative:

64-bit Cumulative that is updated at specific nodes by processing per packet PktID field and configured parameters.

   
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Namespace-ID           |         IOAM E2E-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       E2E Option data field determined by IOAM-E2E-Type       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Namespace-ID:

16-bit identifier of an IOAM-Namespace. The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" (see Section 4.3) and MUST be known to all the nodes implementing IOAM. For any other Namespace-ID value that does not match any Namespace-ID the node is configured to operate on, the node MUST NOT change the contents of the IOAM-Data-Fields.

IOAM-E2E-Type:

16-bit identifier that specifies which data types are used in the E2E Option data. The IOAM-E2E-Type value is a bit field. The order of packing the E2E Option data field elements follows the bit order of the IOAM E2E-Type field as follows:

Bit 0

Most significant bit. When set, it indicates the presence of a 64-bit sequence number added to a specific "packet group" that is used to detect packet loss, packet reordering, or packet duplication within the group. The "packet group" is deployment dependent and defined at the IOAM encapsulating node, e.g., by n-tuple-based classification of packets. When this bit is set, "Bit 1" (for a 32-bit sequence number, see below) MUST be zero.

Bit 1

When set, it indicates the presence of a 32-bit sequence number added to a specific "packet group" that is used to detect packet loss, packet reordering, or packet duplication within that group. The "packet group" is deployment dependent and defined at the IOAM encapsulating node, e.g., by n-tuple-based classification of packets. When this bit is set, "Bit 0" (for a 64-bit sequence number, see above) MUST be zero.

Bit 2

When set, it indicates the presence of timestamp seconds, representing the time at which the packet entered the IOAM-Domain. Within the IOAM encapsulating node, the time that the timestamp is retrieved can depend on the implementation. Some possibilities are 1) the time at which the packet was received by the node, 2) the time at which the packet was transmitted by the node, or 3) when a tunnel encapsulation is used, the point at which the packet is encapsulated into the tunnel. Each implementation has to document when the E2E timestamp that is going to be put in the packet is retrieved. This 4-octet field has three possible formats, based on either PTP (see e.g., [RFC 8877]), NTP [RFC 5905], or POSIX [POSIX]. The three timestamp formats are specified in Section 5. In all three cases, the timestamp seconds field contains the 32 most significant bits of the timestamp format that is specified in Section 5. If a node is not capable of populating this field, it assigns the value 0xFFFFFFFF. Note that this is a legitimate value that is valid for 1 second in approximately 136 years; the analyzer has to correlate several packets or compare the timestamp value to its own time of day in order to detect the error indication.

Bit 3

When set, it indicates the presence of timestamp fraction, representing the time at which the packet entered the IOAM-Domain. This 4-octet field has three possible formats, based on either PTP (see e.g., [RFC 8877]), NTP [RFC 5905], or POSIX [POSIX]. The three timestamp formats are specified in Section 5. In all three cases, the timestamp fraction field contains the 32 least significant bits of the timestamp format that is specified in Section 5. If a node is not capable of populating this field, it assigns the value 0xFFFFFFFF. Note that this is a legitimate value in the NTP format, valid for approximately 233 picoseconds in every second. If the NTP format is used, the analyzer has to correlate several packets in order to detect the error indication.

Bit 4-15

Undefined. An IOAM encapsulating node MUST set the value of these bits to zero upon transmission and ignore them upon receipt.

E2E Option data:

Variable-length field. The type of which is determined by the IOAM E2E-Type.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Nanoseconds                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp field format:

Seconds:

Specifies the integer portion of the number of seconds since the PTP epoch

Size:

32 bits

Units:

seconds

Nanoseconds:

Specifies the fractional portion of the number of seconds since the PTP epoch

Size:

32 bits

Units:

nanoseconds. The value of this field is in the range 0 to (10⁹)-1.

Epoch:

PTP epoch. For details, see e.g., [RFC 8877].

Resolution:

The resolution is 1 nanosecond.

Wraparound:

This time format wraps around every 2³² seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.

Synchronization Aspects:

It is assumed that the nodes that run this protocol are synchronized among themselves. Nodes MAY be synchronized to a global reference time. Note that if PTP is used for synchronization, the timestamp MAY be derived from the PTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of a PTP Grandmaster clock.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Fraction                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp field format:

Seconds:

specifies the integer portion of the number of seconds since the NTP epoch

Size:

32 bits

Units:

seconds

Fraction:

specifies the fractional portion of the number of seconds since the NTP epoch

Size:

32 bits

Units:

the unit is 2^(-32) seconds, which is roughly equal to 233 picoseconds.

Epoch:

NTP epoch. For details, see [RFC 5905].

Resolution:

The resolution is 2^(-32) seconds.

Wraparound:

This time format wraps around every 2³² seconds, which is roughly 136 years. The next wraparound will occur in the year 2036.

Synchronization Aspects:

Nodes that use this timestamp format will typically be synchronized to UTC using NTP [RFC 5905]. Thus, the timestamp MAY be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Seconds                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Microseconds                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp field format:

Seconds:

specifies the integer portion of the number of seconds since the POSIX epoch

Size:

32 bits

Units:

seconds

Microseconds:

specifies the fractional portion of the number of seconds since the POSIX epoch

Size:

32 bits

Units:

the unit is microseconds. The value of this field is in the range 0 to (10⁶)-1.

Epoch:

POSIX epoch. For details, see [POSIX], Appendix A.4.16.

Resolution:

The resolution is 1 microsecond.

Wraparound:

This time format wraps around every 2³² seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.

Synchronization Aspects:

It is assumed that nodes that use this timestamp format run the Linux operating system and hence use the POSIX time. In some cases, nodes MAY be synchronized to UTC using a synchronization mechanism that is outside the scope of this document, such as NTP [RFC 5905]. Thus, the timestamp MAY be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server.

• IOAM Option-Type
• IOAM Trace-Type
• IOAM Trace-Flags
• IOAM POT-Type
• IOAM POT-Flags
• IOAM E2E-Type
• IOAM Namespace-ID

0:

IOAM Pre-allocated Trace Option-Type

1:

IOAM Incremental Trace Option-Type

2:

IOAM POT Option-Type

3:

IOAM E2E Option-Type

Name:

name of the newly registered Option-Type

Code point:

desired value of the requested code point

Description:

brief description of the newly registered Option-Type

Reference:

reference to the document that defines the new Option-Type

Bit 0:

hop_Lim and node_id in short format

Bit 1:

ingress_if_id and egress_if_id in short format

Bit 2:

timestamp seconds

Bit 3:

timestamp fraction

Bit 4:

transit delay

Bit 5:

namespace-specific data in short format

Bit 6:

queue depth

Bit 7:

checksum complement

Bit 8:

hop_Lim and node_id in wide format

Bit 9:

ingress_if_id and egress_if_id in wide format

Bit 10:

namespace-specific data in wide format

Bit 11:

buffer occupancy

Bit 22:

variable-length Opaque State Snapshot

Bit 23:

reserved

Bit:

desired bit to be allocated in the 24-bit IOAM Trace Option-Type field for the Pre-allocated Trace Option-Type and Incremental Trace Option-Type

Description:

brief description of the newly registered bit

Reference:

reference to the document that defines the new bit

Bit 0:

"Overflow" (O-bit)

Bit:

desired bit to be allocated in the 8-bit flags field of the Pre-allocated Trace Option-Type and Incremental Trace Option-Type

Description:

brief description of the newly registered bit

Reference:

reference to the document that defines the new bit

0:

16-Octet POT data

Name:

name of the newly registered POT-Type

Code point:

desired value of the requested code point

Description:

brief description of the newly registered POT-Type

Reference:

reference to the document that defines the new POT-Type

Bit:

desired bit to be allocated in the 8-bit flags field of the IOAM POT Option-Type

Description:

brief description of the newly registered bit

Reference:

reference to the document that defines the new bit

Bit 0:

64-bit sequence number

Bit 1:

32-bit sequence number

Bit 2:

timestamp seconds

Bit 3:

timestamp fraction

Bit:

desired bit to be allocated in the 16-bit IOAM E2E-Type field

Description:

brief description of the newly registered bit

Reference:

reference to the document that defines the new bit

• Review whether the request is complete, i.e., the registration template has been filled in. The expert will send incomplete requests back to the requester.
• Check whether the request is neither a duplicate of nor conflicting with either an already existing allocation or a pending allocation. In case of duplicates or conflicts, the expert will ask the requester to update the allocation request accordingly.
• Solicit feedback from relevant working groups and communities to ensure that the new allocation request has been properly reviewed and that rough consensus on the request exists. At a minimum, the expert will solicit feedback from the IPPM Working Group by posting the request to the ippm@ietf.org mailing list. The expert will allow for a 3-week review period on the mailing lists. If the feedback received from the relevant working groups and communities within the review period indicates rough consensus on the request, the expert will approve the request and ask IANA to allocate the new Namespace-ID. In case the expert senses a lack of consensus from the feedback received, the expert will ask the requester to engage with the corresponding working groups and communities to further review and refine the request.

0x0000:

default namespace (known to all IOAM nodes)

0x0001 - 0x7FFF:

reserved for private use

0x8000 - 0xFFFF:

unassigned

Name:

name of the newly registered Namespace-ID

Code point:

desired value of the requested Namespace-ID

Description:

brief description of the newly registered Namespace-ID

Reference:

reference to the document that defines the new Namespace-ID

Status of the registration:

Status can be either "permanent" or "provisional". Namespace-ID registrations following a successful expert review will have the status "provisional". Once the RFC that defines the new Namespace-ID is published, the status is changed to "permanent".

[POSIX]

IEEE, "IEEE/Open Group 1003.1-2017 - IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7", IEEE Std 1003.1-2017, January 2018,
<https://standards.ieee.org/ieee/1003.1/7101/>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5905]

D. Mills, J. Martin, J. Burbank, and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[IPPM-IOAM-DATA-INTEGRITY]

Universite de Liege, , , , and , "Integrity of In-situ OAM Data Fields", Internet-Draft draft-ietf-ippm-ioam-data-integrity-01, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-01>.

[IPPM-IOAM-DEPLOYMENT]

Huawei, , , , and , "In-situ OAM Deployment", Internet-Draft draft-ietf-ippm-ioam-deployment-01, April 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment-01>.

[IPPM-IOAM-RAWEXPORT]

Cisco Systems, Inc., , , , and , "In-situ OAM raw data export with IPFIX", Internet-Draft draft-spiegel-ippm-ioam-rawexport-06, February 2022,
<https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-ioam-rawexport-06>.

[IPV6-RECORD-ROUTE]

NEC Corporation, H. Kitamura, "Record Route for IPv6 (RR6) Hop-by-Hop Option Extension", Internet-Draft draft-kitamura-ipv6-record-route-00, November 2000,
<https://datatracker.ietf.org/doc/html/draft-kitamura-ipv6-record-route-00>.

[NVO3-VXLAN-GPE]

Intel, , , and , "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Internet-Draft draft-ietf-nvo3-vxlan-gpe-12, September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12>.

[RFC7276]

T. Mizrahi, N. Sprecher, E. Bellagamba, and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.

[RFC7384]

T. Mizrahi, "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014,
<https://www.rfc-editor.org/info/rfc7384>.

[RFC7665]

J. Halpern, and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.

[RFC7799]

A. Morton, "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016,
<https://www.rfc-editor.org/info/rfc7799>.

[RFC7820]

T. Mizrahi, "UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7820, DOI 10.17487/RFC7820, March 2016,
<https://www.rfc-editor.org/info/rfc7820>.

[RFC7821]

T. Mizrahi, "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 2016,
<https://www.rfc-editor.org/info/rfc7821>.

[RFC8300]

P. Quinn, U. Elzur, and C. Pignataro, "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.

[RFC8799]

B. Carpenter, and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.

[RFC8877]

T. Mizrahi, J. Fabini, and A. Morton, "Guidelines for Defining Packet Timestamps", RFC 8877, DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>.

[RFC8926]

J. Gross, I. Ganga, and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.

Carlos Pignataro

Mickey Spiegel

Barak Gafni

Jennifer Lemon

Hannes Gredler

John Leddy

Stephen Youell

David Mozes

Petr Lapukhov

Remy Chang

Daniel Bernier

Frank Brockners

Shwetha Bhandari

Tal Mizrahi