< draft-ietf-ippm-ioam-data-04.txt   draft-ietf-ippm-ioam-data-05.txt >
ippm F. Brockners ippm F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: April 23, 2019 Cisco Expires: September 11, 2019 Cisco
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Leddy J. Leddy
Comcast Comcast
S. Youell S. Youell
JPMC JPMC
T. Mizrahi T. Mizrahi
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
D. Mozes D. Mozes
P. Lapukhov P. Lapukhov
Facebook Facebook
R. Chang R. Chang
Barefoot Networks Barefoot Networks
D. Bernier D. Bernier
Bell Canada Bell Canada
J. Lemon J. Lemon
Broadcom Broadcom
October 20, 2018 March 10, 2019
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-04 draft-ietf-ippm-ioam-data-05
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
discusses the data fields and associated data types for in-situ OAM. discusses the data fields and associated data types for in-situ OAM.
In-situ OAM data fields can be embedded into a variety of transports In-situ OAM data fields can be embedded into a variety of transports
such as NSH, Segment Routing, Geneve, native IPv6 (via extension such as NSH, Segment Routing, Geneve, native IPv6 (via extension
header), or IPv4. In-situ OAM can be used to complement OAM header), or IPv4. In-situ OAM can be used to complement OAM
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2019. This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4 3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4
4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5 4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5
4.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 6 4.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 7
4.2. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 8 4.2. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 9
4.2.1. Pre-allocated and Incremental Trace Options . . . . . 10 4.2.1. Pre-allocated and Incremental Trace Options . . . . . 11
4.2.2. IOAM node data fields and associated formats . . . . 15 4.2.2. IOAM node data fields and associated formats . . . . 17
4.2.3. Examples of IOAM node data . . . . . . . . . . . . . 20 4.2.3. Examples of IOAM node data . . . . . . . . . . . . . 22
4.3. IOAM Proof of Transit Option . . . . . . . . . . . . . . 22 4.3. IOAM Proof of Transit Option . . . . . . . . . . . . . . 24
4.3.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 23 4.3.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 26
4.4. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 24 4.4. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 27
5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 26 5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 29
5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 26 5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 29
5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 28 5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 30
5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 29 5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 31
6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 30 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7.1. Creation of a new In-Situ OAM Protocol Parameters 7.1. Creation of a new In-Situ OAM Protocol Parameters
Registry (IOAM) Protocol Parameters IANA registry . . . . 31 Registry (IOAM) Protocol Parameters IANA registry . . . . 33
7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 31 7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 34
7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 32 7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 34
7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 32 7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 35
7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 33 7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 35
7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 33 7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 35
7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 33 7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 36
7.8. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 33 7.8. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines data fields for "in-situ" Operations, This document defines data fields for "in-situ" Operations,
Administration, and Maintenance (IOAM). In-situ OAM records OAM Administration, and Maintenance (IOAM). In-situ OAM records OAM
information within the packet while the packet traverses a particular information within the packet while the packet traverses a particular
network domain. The term "in-situ" refers to the fact that the OAM network domain. The term "in-situ" refers to the fact that the OAM
data is added to the data packets rather than is being sent within data is added to the data packets rather than is being sent within
packets specifically dedicated to OAM. IOAM is to complement packets specifically dedicated to OAM. IOAM is to complement
mechanisms such as Ping or Traceroute, or more recent active probing mechanisms such as Ping or Traceroute, or more recent active probing
skipping to change at page 5, line 36 skipping to change at page 5, line 36
Layering: If several encapsulation protocols (e.g., in case of Layering: If several encapsulation protocols (e.g., in case of
tunneling) are stacked on top of each other, IOAM data-records could tunneling) are stacked on top of each other, IOAM data-records could
be present at every layer. The behavior follows the ships-in-the- be present at every layer. The behavior follows the ships-in-the-
night model, i.e. IOAM data in one layer is independent from IOAM night model, i.e. IOAM data in one layer is independent from IOAM
data in another layer. Layering allows operators to instrument the data in another layer. Layering allows operators to instrument the
protocol layer they want to measure. The different layers could, but protocol layer they want to measure. The different layers could, but
do not have to share the same IOAM encapsulation and decapsulation. do not have to share the same IOAM encapsulation and decapsulation.
Combination with active OAM mechanisms: IOAM should be usable for Combination with active OAM mechanisms: IOAM should be usable for
active network probing, enabling for example a customized version of active network probing, enabling for example a customized version of
traceroute. Decapsulating IOAM nodes may have an ability to send the traceroute. IOAM may also be carried out on cloned or sampled copies
IOAM information retrieved from the packet back to the source address of data packets, when the operator prefers not to directly modify
of the packet or to the encapsulating node. data packets for IOAM purposes. Decapsulating IOAM nodes must have
the ability to discard active IOAM packets, potentially in addition
to retrieving the IOAM information.
IOAM implementation: The IOAM data-field definitions take the IOAM implementation: The IOAM data-field definitions take the
specifics of devices with hardware data-plane and software data-plane specifics of devices with hardware data-plane and software data-plane
into account. into account.
4. IOAM Data Types and Formats 4. IOAM Data Types and Formats
This section defines IOAM data types and data fields and associated This section defines IOAM data types and data fields and associated
data types required for IOAM. data types required for IOAM.
To accommodate the different uses of IOAM, IOAM data fields fall into To accommodate the different uses of IOAM, IOAM data fields fall into
different categories, e.g. edge-to-edge, per node tracing, or for different categories, as specified below. In IOAM these categories
proof of transit. In IOAM these categories are referred to as IOAM- are referred to as IOAM-Types. A common registry is maintained for
Types. A common registry is maintained for IOAM-Types, see IOAM-Types, see Section 7.2 for details. Corresponding to these
Section 7.2 for details. Corresponding to these IOAM-Types, IOAM-Types, different IOAM data fields are defined. IOAM data fields
different IOAM data fields are defined. IOAM data fields can be can be encapsulated into a variety of protocols, such as NSH, Geneve,
encapsulated into a variety of protocols, such as NSH, Geneve, IPv6, IPv6, etc. The definition of how IOAM data fields are encapsulated
etc. The definition of how IOAM data fields are encapsulated into into other protocols is outside the scope of this document.
other protocols is outside the scope of this document.
This document defines four IOAM-Types, as specified in this section:
o Pre-allocated Trace Option
o Incremental Trace Option
o Proof of Transit (POT) Option
o Edge-to-Edge (E2E) Option
IOAM is expected to be deployed in a specific domain rather than on IOAM is expected to be deployed in a specific domain rather than on
the overall Internet. The part of the network which employs IOAM is the overall Internet. The part of the network which employs IOAM is
referred to as the "IOAM-domain". IOAM data is added to a packet referred to as the "IOAM-domain". IOAM data is added to a packet
upon entering the IOAM-domain and is removed from the packet when upon entering the IOAM-domain and is removed from the packet when
exiting the domain. Within the IOAM-domain, the IOAM data may be exiting the domain. Within the IOAM-domain, the IOAM data may be
updated by network nodes that the packet traverses. The device which updated by network nodes that the packet traverses. The device which
adds an IOAM data container to the packet to capture IOAM data is adds an IOAM data container to the packet to capture IOAM data is
called the "IOAM encapsulating node", whereas the device which called the "IOAM encapsulating node", whereas the device which
removes the IOAM data container is referred to as the "IOAM removes the IOAM data container is referred to as the "IOAM
decapsulating node". Nodes within the domain which are aware of IOAM decapsulating node". Nodes within the domain which are aware of IOAM
data and read and/or write or process the IOAM data are called "IOAM data and read and/or write or process the IOAM data are called "IOAM
transit nodes". IOAM nodes which add or remove the IOAM data transit nodes". IOAM nodes which add or remove the IOAM data fields
container can also update the IOAM data fields at the same time. Or can also update the IOAM data fields at the same time. Or in other
in other words, IOAM encapsulation or decapsulating nodes can also words, IOAM encapsulating or decapsulating nodes can also serve as
serve as IOAM transit nodes at the same time. Note that not every IOAM transit nodes at the same time. Note that not every node in an
node in an IOAM domain needs to be an IOAM transit node. For IOAM domain needs to be an IOAM transit node. For example, a
example, a Segment Routing deployment might require the segment deployment might require that packets traverse a set of firewalls.
routing path to be verified. In that case, only the SR nodes would In that case, only the set of firewall nodes would be IOAM transit
also be IOAM transit nodes rather than all nodes. nodes rather than all nodes.
An IOAM encapsulating node incorporates one or more IOAM-Types (from
the list of four IOAM-Types above) into packets that IOAM is enabled
for. If IOAM is enabled for a selected subset of the traffic, the
encapsulating node is responsible for applying the IOAM functionality
to the selected subset.
An IOAM transit node updates one or more of the IOAM data fields. If
both the pre-allocated and the incremental trace options are present
in the packet, each IOAM transit node will update at most one of
these options. A transit node cannot add new IOAM options to a
packet, and cannot change an IOAM Edge-to-Edge Option.
An IOAM decapsulating node removes all the IOAM-Types from packets.
The role of a node (i.e. encapsulating, transit, decapsulating) is
defined within an IOAM namespace (see below). A node can have
different roles in different IOAM namespaces.
4.1. IOAM Namespaces 4.1. IOAM Namespaces
IOAM data fields are defined within an IOAM namespace. An IOAM IOAM data fields are defined within an IOAM namespace. An IOAM
namespace is identified by a 16-bit namespace identifier (Namespace- namespace is identified by a 16-bit namespace identifier (Namespace-
ID). Namespace identifiers MUST be present and populated in all IOAM ID). Namespace identifiers MUST be present and populated in all IOAM
option headers. The Namespace-ID value is divided into two sub- option headers. The Namespace-ID value is divided into two sub-
ranges: ranges:
o An operator-assigned range from 0x0001 to 0x7FFF o An operator-assigned range from 0x0001 to 0x7FFF
skipping to change at page 7, line 25 skipping to change at page 8, line 6
o whether IOAM option header(s) should be removed from the packet, o whether IOAM option header(s) should be removed from the packet,
e.g. at a domain edge or domain boundary. e.g. at a domain edge or domain boundary.
IOAM namespaces support several different uses: IOAM namespaces support several different uses:
o Namespaces can be used by an operator to distinguish different o Namespaces can be used by an operator to distinguish different
operational domains. Devices at domain edges can filter on operational domains. Devices at domain edges can filter on
Namespace-IDs to provide for proper IOAM domain isolation. Namespace-IDs to provide for proper IOAM domain isolation.
o Namespaces provide additional context for IOAM data fields and o Namespaces provide additional context for IOAM data fields and
thus ensure that IOAM data is unique. While, for example, the thus ensure that IOAM data is unique and can be interpreted
IOAM node identifier (Node-ID) does not have to be unique in a properly by management stations or network controllers. While,
deployment, the combination of Node-ID and Namespace-ID will for example, the IOAM node identifier (Node-ID) does not need to
be unique in a deployment (e.g. an operator may wish to use
different Node-IDs for different IOAM layers, even within the same
device; or Node-IDs might not be unique for other organizational
reasons, such as after a merger of two formerly separated
organizations), the combination of Node-ID and Namespace-ID will
always be unique. Similarly, namespaces can be used to define how always be unique. Similarly, namespaces can be used to define how
certain IOAM data fields are interpreted: IOAM offers three certain IOAM data fields are interpreted: IOAM offers three
different timestamp format options. The Namespace-ID can be used different timestamp format options. The Namespace-ID can be used
to determine the timestamp format. to determine the timestamp format. IOAM data fields (e.g. buffer
occupancy) which do not have a unit associated are to be
interpreted within the context of a namespace.
o Namespaces can be used to identify different sets of devices o Namespaces can be used to identify different sets of devices
(e.g., different types of devices) in a deployment: If an operator (e.g., different types of devices) in a deployment: If an operator
desires to insert different IOAM data based on the device, the desires to insert different IOAM data based on the device, the
devices could be grouped into multiple namespaces. This could be devices could be grouped into multiple namespaces. This could be
due to the fact that the IOAM feature set differs between due to the fact that the IOAM feature set differs between
different sets of devices, or it could be for reasons of optimized different sets of devices, or it could be for reasons of optimized
space usage in the packet header. This could also stem from space usage in the packet header. This could also stem from
hardware or operational limitations on the size of the trace data hardware or operational limitations on the size of the trace data
that can be added and processed, preventing collection of a full that can be added and processed, preventing collection of a full
skipping to change at page 9, line 7 skipping to change at page 9, line 42
Pre-allocated Trace Option: This trace option is defined as a Pre-allocated Trace Option: This trace option is defined as a
container of node data fields with pre-allocated space for each container of node data fields with pre-allocated space for each
node to populate its information. This option is useful for node to populate its information. This option is useful for
software implementations where it is efficient to allocate the software implementations where it is efficient to allocate the
space once and index into the array to populate the data during space once and index into the array to populate the data during
transit. The IOAM encapsulating node allocates the option header transit. The IOAM encapsulating node allocates the option header
and sets the fields in the option header. The in situ OAM and sets the fields in the option header. The in situ OAM
encapsulating node allocates an array which is used to store encapsulating node allocates an array which is used to store
operational data retrieved from every node while the packet operational data retrieved from every node while the packet
traverses the domain. IOAM transit nodes update the content of traverses the domain. IOAM transit nodes update the content of
the array. A pointer which is part of the IOAM trace data points the array, and possibly update the checksums of outer headers. A
to the next empty slot in the array, which is where the next IOAM pointer which is part of the IOAM trace data points to the next
transit node fills in its data. empty slot in the array. An IOAM transit node that updates the
content of the pre-allocated option also updates the value of the
pointer, which specifies where the next IOAM transit node fills in
its data.
Incremental Trace Option: This trace option is defined as a Incremental Trace Option: This trace option is defined as a
container of node data fields where each node allocates and pushes container of node data fields where each node allocates and pushes
its node data immediately following the option header. This type its node data immediately following the option header. This type
of trace recording is useful for some of the hardware of trace recording is useful for some of the hardware
implementations as this eliminates the need for the transit implementations as this eliminates the need for the transit
network elements to read the full array in the option and allows network elements to read the full array in the option and allows
for arbitrarily long packets as the MTU allows. The in-situ OAM for arbitrarily long packets as the MTU allows. The in-situ OAM
encapsulating node allocates the option header. The in-situ OAM encapsulating node allocates the option header. The in-situ OAM
encapsulating node based on operational state and configuration encapsulating node based on operational state and configuration
skipping to change at page 12, line 17 skipping to change at page 13, line 17
For example, if 3 IOAM-Trace-Type bits are set and none of them For example, if 3 IOAM-Trace-Type bits are set and none of them
are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are
set and 2 of them are wide, then NodeLen would be 5. set and 2 of them are wide, then NodeLen would be 5.
An IOAM encapsulating node must set NodeLen. An IOAM encapsulating node must set NodeLen.
A node receiving an IOAM Pre-allocated or Incremental Trace Option A node receiving an IOAM Pre-allocated or Incremental Trace Option
may rely on the NodeLen value, or it may ignore the NodeLen value may rely on the NodeLen value, or it may ignore the NodeLen value
and calculate the node length from the IOAM-Trace-Type bits. and calculate the node length from the IOAM-Trace-Type bits.
Flags 4-bit field. Following flags are defined: Flags 4-bit field. The following flags are defined:
Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
by the network element if there is not enough number of octets by the network element if there is not enough number of octets
left to record node data, no field is added and the overflow left to record node data, no field is added and the overflow
"O-bit" must be set to "1" in the header. This is useful for "O-bit" must be set to "1" in the header. This is useful for
transit nodes to ignore further processing of the option. transit nodes to ignore further processing of the option.
Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy
of a packet back towards the source. Loopback mode assumes of a packet back towards the source. Loopback mode assumes
that a return path from transit nodes and destination nodes that a return path from transit nodes and destination nodes
towards the source exists. The encapsulating node decides towards the source exists. The encapsulating node decides
(e.g. using a filter) which packets loopback mode is enabled (e.g., using a filter) which packets loopback mode is enabled
for by setting the loopback bit. The encapsulating node also for by setting the loopback bit. The encapsulating node also
needs to ensure that sufficient space is available in the IOAM needs to ensure that sufficient space is available in the IOAM
header for loopback operation. The loopback bit when set header for loopback operation, which includes intermediate
indicates to the transit nodes processing this option to create nodes adding trace data on the original path and then again on
a copy of the packet received and send this copy of the packet the return path. A loopback bit that is set indicates to the
back to the source of the packet while it continues to forward transit nodes processing this option that they are to create a
the original packet towards the destination. The source copy of the received packet and send the copy back to the
address of the original packet is used as destination address source of the packet. The copy has its metadata added after
in the copied packet. The address of the node performing the being copied in order to allow any egress-dependent information
copy operation is used as the source address. The L-bit MUST to be set based on the egress of the copy rather than the
be cleared in the copy of the packet that a node sends back original. The original packet continues towards its
towards the source. On its way back towards the source, the destination. The source address of the original packet is used
packet is processed like a regular packet with IOAM as the destination address in the copied packet. The address
information. Once the return packet reaches the IOAM domain of the node performing the copy operation is used as the source
boundary IOAM decapsulation occurs as with any other packet address. The L-bit MUST be cleared in the copy of the packet
containing IOAM information. that a node sends back towards the source. On its way back
towards the source, the copied packet is processed like any
other packet with IOAM information, including adding any
requested data at each transit node (assuming there is
sufficient space). Once the return packet reaches the IOAM
domain boundary, IOAM decapsulation occurs as with any other
packet containing IOAM information. Because any intermediate
node receiving such a packet would not know how to process the
original packet, and because there would be a risk of the
original packet leaking past the initiator of the IOAM
loopback, the initiator of an IOAM loopback MUST be the
initiator of the packet. Once a loopback packet is received
back at the initiator, it is a local matter how it is
recognized as a loopback packet.
Bit 2-3 Reserved: Must be zero. Bit 2 "Active" (A-bit). When set, this indicates that this is an
active OAM packet, where "active" is used in the sense defined
in [RFC7799], rather than a data packet. For example, the
packet may be a probe, or it may be a (possibly truncated) copy
of a data packet. At the IOAM decapsulating node, in addition
to processing and/or exporting the metadata, the packet must be
discarded rather than forwarded. If this bit is not set, then
the decapsulating node should attempt to forward the packet
after IOAM decapsulation.
Bit 3 "Immediate Export" (I-bit). Immediate export mode is used
to export IOAM data fields immediately at every IOAM supported
network node, instead of adding the IOAM data fields to the
packet traversing the network. The various types of IOAM nodes
MUST process packets with the I-bit set as follows:
1. An encapsulating IOAM node configured to set the I-bit
encapsulates the packet with the IOAM header and sets the
I-bit, leaving the IOAM header without locally collected
data, and exports the requested IOAM data immediately. The
encapsulating IOAM node is the only type of node allowed to
set the I-bit.
2. A transit node that processes a packet with the I-bit set
is expected to export the requested IOAM data, and not
incorporate it into the IOAM header.
3. A decapsulating IOAM node that processes a packet with the
I-bit set is expected to export the requested IOAM data,
and decapsulate the IOAM header.
Note that in case of "Immediate Export" being employed, no IOAM
trace data is added to the packets traversing the network. As
a means to support correlation of exported IOAM data different
nodes in the network, a deployment could consider attaching an
IOAM E2E option in addition to the trace option, that includes
a sequence number. See Bit 1 in the IOAM-E2E-Types. Please
refer to Section 6 for a discussion of IOAM data export and
associated formats.
RemainingLen: 7-bit unsigned integer. This field specifies the data RemainingLen: 7-bit unsigned integer. This field specifies the data
space in multiples of 4-octets remaining for recording the node space in multiples of 4-octets remaining for recording the node
data, before the node data list is considered to have overflowed. data, before the node data list is considered to have overflowed.
When RemainingLen reaches 0, nodes are no longer allowed to add When RemainingLen reaches 0, nodes are no longer allowed to add
node data. Given that the sender knows the minimum path MTU, the node data. Given that the sender knows the minimum path MTU, the
sender MAY set the initial value of RemainingLen according to the sender MAY set the initial value of RemainingLen according to the
number of node data bytes allowed before exceeding the MTU. number of node data bytes allowed before exceeding the MTU.
Subsequent nodes can carry out a simple comparison between Subsequent nodes can carry out a simple comparison between
RemainingLen and NodeLen, along with the length of the "Opaque RemainingLen and NodeLen, along with the length of the "Opaque
State Snapshot" if applicable, to determine whether or not data State Snapshot" if applicable, to determine whether or not data
can be added by this node. When node data is added, the node MUST 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- decrease RemainingLen by the amount of data added. In the pre-
allocated trace option, this is used as an offset in data space to allocated trace option, this is used as an offset in data space to
skipping to change at page 13, line 17 skipping to change at page 15, line 22
sender MAY set the initial value of RemainingLen according to the sender MAY set the initial value of RemainingLen according to the
number of node data bytes allowed before exceeding the MTU. number of node data bytes allowed before exceeding the MTU.
Subsequent nodes can carry out a simple comparison between Subsequent nodes can carry out a simple comparison between
RemainingLen and NodeLen, along with the length of the "Opaque RemainingLen and NodeLen, along with the length of the "Opaque
State Snapshot" if applicable, to determine whether or not data State Snapshot" if applicable, to determine whether or not data
can be added by this node. When node data is added, the node MUST 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- decrease RemainingLen by the amount of data added. In the pre-
allocated trace option, this is used as an offset in data space to allocated trace option, this is used as an offset in data space to
record the node data element. record the node data element.
IOAM-Trace-Type: A 16-bit identifier which specifies which data IOAM-Trace-Type: A 24-bit identifier which specifies which data
types are used in this node data list. types are used in this node data list.
The IOAM-Trace-Type value is a bit field. The following bit The IOAM-Trace-Type value is a bit field. The following bit
fields are defined in this document, with details on each field fields are defined in this document, with details on each field
described in the Section 4.2.2. The order of packing the data described in the Section 4.2.2. The order of packing the data
fields in each node data element follows the bit order of the fields in each node data element follows the bit order of the
IOAM-Trace-Type field, as follows: IOAM-Trace-Type field, as follows:
Bit 0 (Most significant bit) When set indicates presence of Bit 0 (Most significant bit) When set indicates presence of
Hop_Lim and node_id in the node data. Hop_Lim and node_id in the node data.
skipping to change at page 14, line 14 skipping to change at page 16, line 20
Bit 9 When set indicates presence of ingress_if_id and Bit 9 When set indicates presence of ingress_if_id and
egress_if_id in wide format in the node data. egress_if_id in wide format in the node data.
Bit 10 When set indicates presence of namespace specific data in Bit 10 When set indicates presence of namespace specific data in
wide format in the node data. wide format in the node data.
Bit 11 When set indicates presence of buffer occupancy in the Bit 11 When set indicates presence of buffer occupancy in the
node data. node data.
Bit 12-22 Undefined. An IOAM encapsulating node must set the Bit 12-22 Undefined. An IOAM encapsulating node MUST set the
value of each of these bits to 0. If an IOAM transit value of each of these bits to 0. If an IOAM transit
node receives a packet with one or more of these bits set node receives a packet with one or more of these bits set
to 1, it must either: to 1, it must either:
1. Add corresponding node data filled with the reserved 1. Add corresponding node data filled with the reserved
value 0xFFFFFFFF, after the node data fields for the value 0xFFFFFFFF, after the node data fields for the
IOAM-Trace-Type bits defined above, such that the IOAM-Trace-Type bits defined above, such that the
total node data added by this node in units of total node data added by this node in units of
4-octets is equal to NodeLen, or 4-octets is equal to NodeLen, or
skipping to change at page 14, line 44 skipping to change at page 16, line 50
knobs. knobs.
Reserved: 8-bits. Must be zero. Reserved: 8-bits. Must be zero.
Node data List [n]: Variable-length field. The type of which is Node data List [n]: Variable-length field. The type of which is
determined by the IOAM-Trace-Type bit representing the n-th node determined by the IOAM-Trace-Type bit representing the n-th node
data in the node data list. The node data list is encoded data in the node data list. The node data list is encoded
starting from the last node data of the path. The first element starting from the last node data of the path. The first element
of the node data list (node data list [0]) contains the last node of the node data list (node data list [0]) contains the last node
of the path while the last node data of the node data list (node of the path while the last node data of the node data list (node
data list[n]) contains the first node data of the path traced. In data list[n]) contains the first node data of the path traced.
the pre-allocated trace option, the index contained in Populating the node data list in this way ensures that the order
RemainingLen identifies the offset for current active node data to of node data list is the same for incremental and pre-allocated
be populated. trace options. In the pre-allocated trace option, the index
contained in RemainingLen identifies the offset for current active
node data to be populated.
4.2.2. IOAM node data fields and associated formats 4.2.2. IOAM node data fields and associated formats
All the data fields MUST be 4-octet aligned. If a node which is All the data fields MUST be 4-octet aligned. If a node which is
supposed to update an IOAM data field is not capable of populating supposed to update an IOAM data field is not capable of populating
the value of a field set in the IOAM-Trace-Type, the field value MUST the value of a field set in the IOAM-Trace-Type, the field value MUST
be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF for be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF for
8-octet fields, indicating that the value is not populated, except 8-octet fields, indicating that the value is not populated, except
when explicitly specified in the field description below. when explicitly specified in the field description below.
skipping to change at page 16, line 5 skipping to change at page 18, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ingress_if_id: 2-octet unsigned integer. Interface identifier to ingress_if_id: 2-octet unsigned integer. Interface identifier to
record the ingress interface the packet was received on. record the ingress interface the packet was received on.
egress_if_id: 2-octet unsigned integer. Interface identifier to egress_if_id: 2-octet unsigned integer. Interface identifier to
record the egress interface the packet is forwarded out of. record the egress interface the packet is forwarded out of.
Note that due to the fact that IOAM uses its own namespaces for
IOAM data fields, data fields like interface identifiers can be
used in a flexible way to represent system resources that are
associated with ingressing or egressing packets, i.e. an IOAM
interface ID could represent a physical interface, a virtual or
logical interface, or even a queue.
timestamp seconds: 4-octet unsigned integer. Absolute timestamp in timestamp seconds: 4-octet unsigned integer. Absolute timestamp in
seconds that specifies the time at which the packet was received seconds that specifies the time at which the packet was received
by the node. This field has three possible formats; based on by the node. This field has three possible formats; based on
either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX]. The either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX]. The
three timestamp formats are specified in Section 5. In all three three timestamp formats are specified in Section 5. In all three
cases, the Timestamp Seconds field contains the 32 most cases, the Timestamp Seconds field contains the 32 most
significant bits of the timestamp format that is specified in significant bits of the timestamp format that is specified in
Section 5. If a node is not capable of populating this field, it Section 5. If a node is not capable of populating this field, it
assigns the value 0xFFFFFFFF. Note that this is a legitimate assigns the value 0xFFFFFFFF. Note that this is a legitimate
value that is valid for 1 second in approximately 136 years; the value that is valid for 1 second in approximately 136 years; the
skipping to change at page 19, line 15 skipping to change at page 21, line 36
context of a specific namespace. context of a specific namespace.
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 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 specific data ~ | namespace specific data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ namespace specific data (contd) | ~ namespace specific data (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
buffer occupancy: 4-octet unsigned integer field. This field buffer occupancy: 4-octet unsigned integer field. This field
indicates the current status of the buffer occupancy. The buffer indicates the current status of the occupancy of the common buffer
occupancy is expressed as the current number of memory buffers pool used by a set of queues. The units of this field depend on
used by the set of queues that share a common buffer pool. the equipment type and deployment and has to be interpreted within
the context of a namespace and/or node-id if used.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| buffer occupancy | | buffer occupancy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum Complement: 4-octet node data which contains a two-octet Checksum Complement: 4-octet node data which contains a two-octet
Checksum Complement field, and a 2-octet reserved field. The Checksum Complement field, and a 2-octet reserved field. The
Checksum Complement is useful when IOAM is transported over Checksum Complement is useful when IOAM is transported over
encapsulations that make use of a UDP transport, such as VXLAN-GPE encapsulations that make use of a UDP transport, such as VXLAN-GPE
skipping to change at page 20, line 19 skipping to change at page 22, line 38
4.2.3. Examples of IOAM node data 4.2.3. Examples of IOAM node data
An entry in the "node data list" array can have different formats, An entry in the "node data list" array can have different formats,
following the needs of the deployment. Some deployments might only following the needs of the deployment. Some deployments might only
be interested in recording the node identifiers, whereas others might be interested in recording the node identifiers, whereas others might
be interested in recording node identifier and timestamp. The be interested in recording node identifier and timestamp. The
section defines different types that an entry in "node data list" can section defines different types that an entry in "node data list" can
take. take.
0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is: 0xD40000: IOAM-Trace-Type is 0xD40000 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 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 | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp subseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| namespace specific data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0xC000: IOAM-Trace-Type is 0xC000 then the format is: 0xC00000: IOAM-Trace-Type is 0xC00000 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 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 | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x9000: IOAM-Trace-Type is 0x9000 then the format is: 0x900000: IOAM-Trace-Type is 0x900000 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 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 | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp subseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x8400: IOAM-Trace-Type is 0x8400 then the format is: 0x840000: IOAM-Trace-Type is 0x840000 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 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 | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| namespace specific data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x9400: IOAM-Trace-Type is 0x9400 then the format is: 0x940000: IOAM-Trace-Type is 0x940000 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 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 | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp subseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| namespace specific data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x3180: IOAM-Trace-Type is 0x3180 then the format is: 0x318000: IOAM-Trace-Type is 0x318000 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 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 seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp subseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Schema Id | | Length | Schema Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 22, line 25 skipping to change at page 25, line 11
a set of information that is handed from node to node. a set of information that is handed from node to node.
Correspondingly, two pieces of information are added as IOAM data to Correspondingly, two pieces of information are added as IOAM data to
the packet: the packet:
o Random: Unique identifier for the packet (e.g., 64-bits allow for o Random: Unique identifier for the packet (e.g., 64-bits allow for
the unique identification of 2^64 packets). the unique identification of 2^64 packets).
o Cumulative: Information which is handed from node to node and o Cumulative: Information which is handed from node to node and
updated by every node according to a verification algorithm. updated by every node according to a verification algorithm.
IOAM proof of transit option:
IOAM proof of transit option header: IOAM proof of transit option header:
0 1 2 3 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 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| | Namespace-ID |IOAM POT Type | IOAM POT flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM proof of transit option data MUST be 4-octet aligned.: IOAM proof of transit option data MUST be 4-octet aligned.:
skipping to change at page 25, line 5 skipping to change at page 27, line 21
of space constraints in the transport protocol used). Future of space constraints in the transport protocol used). Future
versions of this document will address different sizes of data for versions of this document will address different sizes of data for
"proof of transit". "proof of transit".
4.4. IOAM Edge-to-Edge Option 4.4. IOAM Edge-to-Edge Option
The IOAM edge-to-edge option is to carry data that is added by the The IOAM edge-to-edge option is to carry data that is added by the
IOAM encapsulating node and interpreted by IOAM decapsulating node. IOAM encapsulating node and interpreted by IOAM decapsulating node.
The IOAM transit nodes MAY process the data without modifying it. The IOAM transit nodes MAY process the data without modifying it.
IOAM edge-to-edge option: IOAM edge-to-edge option header:
IOAM edge-to-edge option header:
0 1 2 3 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 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 | | Namespace-ID | IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM edge-to-edge option data MUST be 4-octet aligned: IOAM edge-to-edge option data MUST be 4-octet aligned:
0 1 2 3 0 1 2 3
skipping to change at page 25, line 36 skipping to change at page 27, line 50
Namespace-ID value that does not match any Namespace-ID the node Namespace-ID value that does not match any Namespace-ID the node
is configured to operate on, then the node MUST NOT change the is configured to operate on, then the node MUST NOT change the
contents of the IOAM data fields. contents of the IOAM data fields.
IOAM-E2E-Type: A 16-bit identifier which specifies which data types IOAM-E2E-Type: A 16-bit identifier which specifies which data types
are used in the E2E option data. The IOAM-E2E-Type value is a bit 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 field. The order of packing the E2E option data field elements
follows the bit order of the IOAM-E2E-Type field, as follows: follows the bit order of the IOAM-E2E-Type field, as follows:
Bit 0 (Most significant bit) When set indicates presence of a Bit 0 (Most significant bit) When set indicates presence of a
64-bit sequence number added to a specific tube which is 64-bit sequence number added to a specific "packet group"
used to detect packet loss, packet reordering, or packet which is used to detect packet loss, packet reordering,
duplication for that tube. Each tube leverages a or packet duplication within the group. The "packet
dedicated namespace for its sequence numbers. group" is deployment dependent and defined at the IOAM
encapsulating node e.g. by n-tuple based classification
of packets.
Bit 1 When set indicates presence of a 32-bit sequence number Bit 1 When set indicates presence of a 32-bit sequence number
added to a specific tube which is used to detect packet added to a specific "packet group" which is used to
loss, packet reordering, or packet duplication for that detect packet loss, packet reordering, or packet
tube. Each tube leverages a dedicated namespace for its duplication within that group. The "packet group" is
sequence numbers. deployment dependent and defined at the IOAM
encapsulating node e.g. by n-tuple based classification
of packets.
Bit 2 When set indicates presence of timestamp seconds for the Bit 2 When set indicates presence of timestamp seconds for the
transmission of the frame. This 4-octet field has three transmission of the frame. This 4-octet field has three
possible formats; based on either PTP [IEEE1588v2], NTP possible formats; based on either PTP [IEEE1588v2], NTP
[RFC5905], or POSIX [POSIX]. The three timestamp formats [RFC5905], or POSIX [POSIX]. The three timestamp formats
are specified in Section 5. In all three cases, the are specified in Section 5. In all three cases, the
Timestamp Seconds field contains the 32 most significant Timestamp Seconds field contains the 32 most significant
bits of the timestamp format that is specified in bits of the timestamp format that is specified in
Section 5. If a node is not capable of populating this Section 5. If a node is not capable of populating this
field, it assigns the value 0xFFFFFFFF. Note that this field, it assigns the value 0xFFFFFFFF. Note that this
skipping to change at page 30, line 44 skipping to change at page 33, line 19
of leap seconds that have occurred since the epoch. The value of of leap seconds that have occurred since the epoch. The value of
a timestamp during or slightly after a leap second may be a timestamp during or slightly after a leap second may be
temporarily inaccurate. temporarily inaccurate.
6. IOAM Data Export 6. IOAM Data Export
IOAM nodes collect information for packets traversing a domain that IOAM nodes collect information for packets traversing a domain that
supports IOAM. IOAM decapsulating nodes as well as IOAM transit supports IOAM. IOAM decapsulating nodes as well as IOAM transit
nodes can choose to retrieve IOAM information from the packet, nodes can choose to retrieve IOAM information from the packet,
process the information further and export the information using process the information further and export the information using
e.g., IPFIX. e.g., IPFIX. The mechanisms and associated data formats for
exporting IOAM data is outside the scope of this document.
Raw data export of IOAM data using IPFIX is discussed in Raw data export of IOAM data using IPFIX is discussed in
[I-D.spiegel-ippm-ioam-rawexport]. [I-D.spiegel-ippm-ioam-rawexport].
7. IANA Considerations 7. IANA Considerations
This document requests the following IANA Actions. This document requests the following IANA Actions.
7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM) 7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM)
Protocol Parameters IANA registry Protocol Parameters IANA registry
skipping to change at page 32, line 7 skipping to change at page 34, line 30
2 IOAM POT Option Type 2 IOAM POT Option Type
3 IOAM E2E Option Type 3 IOAM E2E Option Type
4 - 127 are available for assignment via RFC Required process as per 4 - 127 are available for assignment via RFC Required process as per
[RFC8126]. [RFC8126].
7.3. IOAM Trace Type Registry 7.3. IOAM Trace Type Registry
This registry defines code point for each bit in the 16-bit IOAM- This registry defines code point for each bit in the 24-bit IOAM-
Trace-Type field for Pre-allocated trace option and Incremental trace Trace-Type field for Pre-allocated trace option and Incremental trace
option defined in Section 4.2. The meaning of Bits 0 - 11 for trace option defined in Section 4.2. The meaning of Bits 0 - 11 for trace
type are defined in this document in Paragraph 5 of Section 4.2.1: type are defined in this document in Paragraph 5 of Section 4.2.1:
Bit 0 hop_Lim and node_id in short format Bit 0 hop_Lim and node_id in short format
Bit 1 ingress_if_id and egress_if_id in short format Bit 1 ingress_if_id and egress_if_id in short format
Bit 2 timestamp seconds Bit 2 timestamp seconds
skipping to change at page 32, line 45 skipping to change at page 35, line 19
Bit 23 checksum complement Bit 23 checksum complement
The meaning for Bits 12 - 22 are available for assignment via RFC The meaning for Bits 12 - 22 are available for assignment via RFC
Required process as per [RFC8126]. Required process as per [RFC8126].
7.4. IOAM Trace Flags Registry 7.4. IOAM Trace Flags Registry
This registry defines code points for each bit in the 4 bit flags for This registry defines code points for each bit in the 4 bit flags for
Pre-allocated trace option and Incremental trace option defined in Pre-allocated trace option and Incremental trace option defined in
Section 4.2. The meaning of Bit 0 - 1 for trace flags are defined in Section 4.2. The meaning of Bit 0 - 2 for trace flags are defined in
this document in Paragraph 3 of Section 4.2.1: this document in Paragraph 3 of Section 4.2.1:
Bit 0 "Overflow" (O-bit) Bit 0 "Overflow" (O-bit)
Bit 1 "Loopback" (L-bit) Bit 1 "Loopback" (L-bit)
The meaning for Bits 2 - 3 are available for assignment via RFC
Required process as per [RFC8126]. Bit 2 "Active" (A-bit)
Bit 3 "Immediate Export" (I-bit)
7.5. IOAM POT Type Registry 7.5. IOAM POT Type Registry
This registry defines 256 code points to define IOAM POT Type for This registry defines 256 code points to define IOAM POT Type for
IOAM proof of transit option Section 4.3. The code point value 0 is IOAM proof of transit option Section 4.3. The code point value 0 is
defined in this document: defined in this document:
0: 16 Octet POT data 0: 16 Octet POT data
1 - 255 are available for assignment via RFC Required process as per 1 - 255 are available for assignment via RFC Required process as per
skipping to change at page 34, line 28 skipping to change at page 36, line 52
failures or anomalies, or create a false illusion of nonexistent failures or anomalies, or create a false illusion of nonexistent
ones. ones.
The Proof of Transit option (Section Section 4.3) is used for The Proof of Transit option (Section Section 4.3) is used for
verifying the path of data packets. The security considerations of verifying the path of data packets. The security considerations of
POT are further discussed in [I-D.brockners-proof-of-transit]. POT are further discussed in [I-D.brockners-proof-of-transit].
The data elements of IOAM can be used for network reconnaissance, The data elements of IOAM can be used for network reconnaissance,
allowing attackers to collect information about network paths, allowing attackers to collect information about network paths,
performance, queue states, buffer occupancy and other information. performance, queue states, buffer occupancy and other information.
Note that in case IOAM is used in "immediate export" mode, the IOAM
related trace information would not be available in the customer data
packets, but would be exported by every IOAM node. IOAM data export
and securing IOAM data export is outside the scope of this document.
IOAM can be used as a means for implementing Denial of Service (DoS) IOAM can be used as a means for implementing Denial of Service (DoS)
attacks, or for amplifying them. For example, a malicious attacker attacks, or for amplifying them. For example, a malicious attacker
can add an IOAM header to packets in order to consume the resources can add an IOAM header to packets in order to consume the resources
of network devices that take part in IOAM or collectors that analyze of network devices that take part in IOAM or collectors that analyze
the IOAM data. Another example is a packet length attack, in which the IOAM data. Another example is a packet length attack, in which
an attacker pushes IOAM headers into data packets, causing these an attacker pushes IOAM headers into data packets, causing these
packets to be increased beyond the MTU size, resulting in packets to be increased beyond the MTU size, resulting in
fragmentation or in packet drops. fragmentation or in packet drops.
skipping to change at page 35, line 7 skipping to change at page 37, line 34
enables other attacks. Thus, IOAM configuration should be secured in enables other attacks. Thus, IOAM configuration should be secured in
a way that authenticates authorized users and verifies the integrity a way that authenticates authorized users and verifies the integrity
of configuration procedures. of configuration procedures.
Notably, IOAM is expected to be deployed in specific network domains, Notably, IOAM is expected to be deployed in specific network domains,
thus confining the potential attack vectors to within the network thus confining the potential attack vectors to within the network
domain. Indeed, in order to limit the scope of threats to within the domain. Indeed, in order to limit the scope of threats to within the
current network domain the network operator is expected to enforce current network domain the network operator is expected to enforce
policies that prevent IOAM traffic from leaking outside of the IOAM policies that prevent IOAM traffic from leaking outside of the IOAM
domain, and prevent IOAM data from outside the domain to be processed domain, and prevent IOAM data from outside the domain to be processed
and used within the domain. and used within the domain. Another way to prevent the data to get
leaked is using the Immediate Export mode of the trace option.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew
Andrew Yourtchenko for the comments and advice. Yourtchenko, Aviv Kfir, Tianran Zhou, Haoyu song and Robin
<lizhenbin@huawei.com> for the comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
described in [I-D.kitamura-ipv6-record-route]. The authors would described in [I-D.kitamura-ipv6-record-route]. The authors would
like to acknowledge the work done by the author Hiroshi Kitamura and like to acknowledge the work done by the author Hiroshi Kitamura and
people involved in writing it. people involved in writing it.
The authors would like to gracefully acknowledge useful review and The authors would like to gracefully acknowledge useful review and
insightful comments received from Joe Clarke, Al Morton, and Mickey insightful comments received from Joe Clarke, Al Morton, and Mickey
Spiegel. Spiegel.
The authors would like to acknowledge the contribution of "Immediate
export" of IOAM trace by Barak Gafni.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IEEE1588v2] [IEEE1588v2]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Std 1588-2008 - IEEE Standard for a Precision Clock Std 1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008, 2008, Control Systems", IEEE Std 1588-2008, 2008,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
skipping to change at page 36, line 26 skipping to change at page 39, line 8
[I-D.brockners-proof-of-transit] [I-D.brockners-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
of Transit", draft-brockners-proof-of-transit-05 (work in of Transit", draft-brockners-proof-of-transit-05 (work in
progress), May 2018. progress), May 2018.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-04 (work in progress), October 2018. timestamps-06 (work in progress), February 2019.
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-08 (work in progress), October 2018. nvo3-geneve-11 (work in progress), March 2019.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
in progress), April 2018. in progress), April 2018.
[I-D.kitamura-ipv6-record-route] [I-D.kitamura-ipv6-record-route]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
Option Extension", draft-kitamura-ipv6-record-route-00 Option Extension", draft-kitamura-ipv6-record-route-00
(work in progress), November 2000. (work in progress), November 2000.
[I-D.lapukhov-dataplane-probe] [I-D.lapukhov-dataplane-probe]
Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane
probe for in-band telemetry collection", draft-lapukhov- probe for in-band telemetry collection", draft-lapukhov-
dataplane-probe-01 (work in progress), June 2016. dataplane-probe-01 (work in progress), June 2016.
[I-D.spiegel-ippm-ioam-rawexport] [I-D.spiegel-ippm-ioam-rawexport]
Spiegel, M., Brockners, F., Bhandari, S., and R. Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX", Sivakolundu, "In-situ OAM raw data export with IPFIX",
draft-spiegel-ippm-ioam-rawexport-00 (work in progress), draft-spiegel-ippm-ioam-rawexport-01 (work in progress),
March 2018. October 2018.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
 End of changes. 44 change blocks. 
117 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/