< draft-ietf-ippm-ioam-data-03.txt   draft-ietf-ippm-ioam-data-04.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: December 29, 2018 Cisco Expires: April 23, 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
Marvell 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
June 27, 2018 October 20, 2018
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-03 draft-ietf-ippm-ioam-data-04
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
mechanisms based on e.g. ICMP or other types of probe packets. mechanisms based on e.g. ICMP or other types of probe packets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 December 29, 2018. This Internet-Draft will expire on April 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://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 Tracing Options . . . . . . . . . . . . . . . . . . 6 4.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Pre-allocated and Incremental Trace Options . . . . . 8 4.2. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 8
4.1.2. IOAM node data fields and associated formats . . . . 12 4.2.1. Pre-allocated and Incremental Trace Options . . . . . 10
4.1.3. Examples of IOAM node data . . . . . . . . . . . . . 17 4.2.2. IOAM node data fields and associated formats . . . . 15
4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 19 4.2.3. Examples of IOAM node data . . . . . . . . . . . . . 20
4.2.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 20 4.3. IOAM Proof of Transit Option . . . . . . . . . . . . . . 22
4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 22 4.3.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 23
5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 23 4.4. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 24
5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 23 5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 26
5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 25 5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 26
5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 26 5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 28
6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 27 5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . 28 Registry (IOAM) Protocol Parameters IANA registry . . . . 31
7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 28 7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 31
7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 29 7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 32
7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 29 7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 32
7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 29 7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 33
7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 29 7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 33
7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 29 7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7.8. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 4, line 4 skipping to change at page 4, line 6
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Abbreviations used in this document: Abbreviations used in this document:
E2E Edge to Edge E2E Edge to Edge
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
IOAM: In-situ Operations, Administration, and Maintenance IOAM: In-situ Operations, Administration, and Maintenance
MTU: Maximum Transmit Unit MTU: Maximum Transmit Unit
NSH: Network Service Header [I-D.ietf-sfc-nsh] NSH: Network Service Header [RFC8300]
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
POT: Proof of Transit POT: Proof of Transit
SFC: Service Function Chain SFC: Service Function Chain
SID: Segment Identifier SID: Segment Identifier
SR: Segment Routing SR: Segment Routing
skipping to change at page 6, line 30 skipping to change at page 6, line 31
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
container can also update the IOAM data fields at the same time. Or container can also update the IOAM data fields at the same time. Or
in other words, IOAM encapsulation or decapsulating nodes can also in other words, IOAM encapsulation or decapsulating nodes can also
serve as IOAM transit nodes at the same time. Note that not every serve as IOAM transit nodes at the same time. Note that not every
node in an IOAM domain needs to be an IOAM transit node. For node in an IOAM domain needs to be an IOAM transit node. For
example, a Segment Routing deployment might require the segment example, a Segment Routing deployment might require the segment
routing path to be verified. In that case, only the SR nodes would routing path to be verified. In that case, only the SR nodes would
also be IOAM transit nodes rather than all nodes. also be IOAM transit nodes rather than all nodes.
4.1. IOAM Tracing Options 4.1. IOAM Namespaces
IOAM data fields are defined within an IOAM namespace. An IOAM
namespace is identified by a 16-bit namespace identifier (Namespace-
ID). Namespace identifiers MUST be present and populated in all IOAM
option headers. The Namespace-ID value is divided into two sub-
ranges:
o An operator-assigned range from 0x0001 to 0x7FFF
o An IANA-assigned range from 0x8000 to 0xFFFF
The IANA-assigned range is intended to allow future extensions to
have new and interoperable IOAM functionality, while the operator-
assigned range is intended to be domain specific, and managed by the
network operator. The Namespace-ID value of 0x0000 is default and
known to all the nodes implementing IOAM.
Namespace identifiers allow devices which are IOAM capable to
determine:
o whether IOAM option header(s) 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.
o which IOAM option headers need to be processed/updated in case
there are multiple IOAM option headers present in the packet.
Multiple option headers can be present in a packet in case of
overlapping IOAM domains or in case of a layered IOAM deployment.
o whether IOAM option header(s) should be removed from the packet,
e.g. at a domain edge or domain boundary.
IOAM namespaces support several different uses:
o Namespaces can be used by an operator to distinguish different
operational domains. Devices at domain edges can filter on
Namespace-IDs to provide for proper IOAM domain isolation.
o Namespaces provide additional context for IOAM data fields and
thus ensure that IOAM data is unique. While, for example, the
IOAM node identifier (Node-ID) does not have to be unique in a
deployment, the combination of Node-ID and Namespace-ID will
always be unique. Similarly, 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.
o Namespaces can be used to identify different sets of devices
(e.g., different types of devices) in a deployment: If an operator
desires to insert different IOAM data based on the device, the
devices could be grouped into multiple 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. This 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.
* Assigning different Namespace-IDs to different sets of nodes or
network partitions and using the Namespace-ID as a selector at
the IOAM encapsulating node, a full trace for a flow could be
collected and constructed via partial traces in different
packets of the same flow. Example: An operator could choose to
group the devices of a domain into two namespaces, in a way
that at average, only every second hop would be recorded by any
device. To retrieve a full view of the deployment, the
captured IOAM data fields of the two namespaces need to be
correlated.
* Assigning different Namespace-IDs to different sets of nodes or
network partitions and using a separate IOAM header for each
Namespace-ID, a full trace for a flow could be collected and
constructed via partial traces from each IOAM header in each of
the packets in the flow. Example: An operator could choose to
group the devices of a domain into two namespaces, in a way
that each namespace is represented by one of two IOAM headers
in the packet. Each node would record data only for the IOAM
namespace that it belongs to, ignoring the other IOAM header
with a namespace to which it doesn't belong. To retrieve a
full view of the deployment, the captured IOAM data fields of
the two namespaces need to be correlated.
4.2. IOAM Tracing Options
"IOAM tracing data" is expected to be collected at every node that a "IOAM tracing data" is expected to be collected at every node that a
packet traverses to ensure visibility into the entire path a packet packet traverses to ensure visibility into the entire path a packet
takes within an IOAM domain, i.e., in a typical deployment all nodes takes within an IOAM domain, i.e., in a typical deployment all nodes
in an in-situ OAM-domain would participate in IOAM and thus be IOAM in an in-situ OAM-domain would participate in IOAM and thus be IOAM
transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If transit nodes, IOAM encapsulating or IOAM decapsulating nodes. If
not all nodes within a domain are IOAM capable, IOAM tracing not all nodes within a domain are IOAM capable, IOAM tracing
information will only be collected on those nodes which are IOAM information will only be collected on those nodes which are IOAM
capable. Nodes which are not IOAM capable will forward the packet capable. Nodes which are not IOAM capable will forward the packet
without any changes to the IOAM data fields. The maximum number of without any changes to the IOAM data fields. The maximum number of
skipping to change at page 8, line 38 skipping to change at page 10, line 25
o A mechanism to detect whether IOAM trace data was added at every o A mechanism to detect whether IOAM trace data was added at every
hop or whether certain hops in the domain weren't in-situ OAM hop or whether certain hops in the domain weren't in-situ OAM
transit nodes. transit nodes.
The "node data list" array in the packet is populated iteratively as The "node data list" array in the packet is populated iteratively as
the packet traverses the network, starting with the last entry of the 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, array, i.e., "node data list [n]" is the first entry to be populated,
"node data list [n-1]" is the second one, etc. "node data list [n-1]" is the second one, etc.
4.1.1. Pre-allocated and Incremental Trace Options 4.2.1. Pre-allocated and Incremental Trace Options
The in-situ OAM pre-allocated trace option and the in-situ OAM The in-situ OAM pre-allocated trace option and the in-situ OAM
incremental trace option have similar formats. Except where noted incremental trace option have similar formats. Except where noted
below, the internal formats and fields of the two trace options are below, the internal formats and fields of the two trace options are
identical. identical.
Pre-allocated and incremental trace option headers: Pre-allocated and incremental trace option headers:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | NodeLen | Flags |RemainingLen | | Namespace-ID |NodeLen | Flags | RemainingLen|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The trace option data MUST be 4-octet aligned: The trace option data MUST be 4-octet aligned:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | | | |
| node data list [0] | | | node data list [0] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
| | a | | a
skipping to change at page 9, line 35 skipping to change at page 11, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p
| | a | | a
| node data list [n-1] | c | node data list [n-1] | c
| | e | | e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | |
| node data list [n] | | | node data list [n] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
IOAM-Trace-Type: A 16-bit identifier which specifies which data Namespace-ID: 16-bit identifier of an IOAM namespace. The
types are used in this node data list. Namespace-ID value of 0x0000 is defined as the default value and
MUST be known to all the nodes implementing IOAM. For any other
The IOAM-Trace-Type value is a bit field. The following bit Namespace-ID value that does not match any Namespace-ID the node
fields are defined in this document, with details on each field is configured to operate on, the node MUST NOT change the contents
described in the Section 4.1.2. The order of packing the data of the IOAM data fields.
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 presence of
Hop_Lim and node_id in the node data.
Bit 1 When set indicates presence of ingress_if_id and
egress_if_id (short format) in the node data.
Bit 2 When set indicates presence of timestamp seconds in the
node data.
Bit 3 When set indicates presence of timestamp subseconds in
the node data.
Bit 4 When set indicates presence of transit delay in the node
data.
Bit 5 When set indicates presence of app_data (short format) in
the node data.
Bit 6 When set indicates presence of queue depth in the node
data.
Bit 7 When set indicates presence of variable length Opaque
State Snapshot field.
Bit 8 When set indicates presence of Hop_Lim and node_id in
wide format in the node data.
Bit 9 When set indicates presence of ingress_if_id and
egress_if_id in wide format in the node data.
Bit 10 When set indicates presence of app_data wide in the node
data.
Bit 11 When set indicates presence of the Checksum Complement
node data.
Bit 12-15 Undefined. An IOAM encapsulating node must set the
value of each of these bits 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.
Section 4.1.2 describes the IOAM data types and their formats.
Within an in-situ OAM domain possible combinations of these bits
making the IOAM-Trace-Type can be restricted by configuration
knobs.
NodeLen: 5-bit unsigned integer. This field specifies the length of NodeLen: 5-bit unsigned integer. This field specifies the length of
data added by each node in multiples of 4-octets, excluding the data added by each node in multiples of 4-octets, excluding the
length of the "Opaque State Snapshot" field. length of the "Opaque State Snapshot" field.
If IOAM-Trace-Type bit 7 is not set, then NodeLen specifies the If IOAM-Trace-Type bit 7 is not set, then NodeLen specifies the
actual length added by each node. If IOAM-Trace-Type bit 7 is actual length added by each node. If IOAM-Trace-Type bit 7 is
set, then the actual length added by a node would be (NodeLen + set, then the actual length added by a node would be (NodeLen +
Opaque Data Length). Opaque Data Length).
skipping to change at page 12, line 10 skipping to change at page 13, line 4
packet is processed like a regular packet with IOAM packet is processed like a regular packet with IOAM
information. Once the return packet reaches the IOAM domain information. Once the return packet reaches the IOAM domain
boundary IOAM decapsulation occurs as with any other packet boundary IOAM decapsulation occurs as with any other packet
containing IOAM information. containing IOAM information.
Bit 2-3 Reserved: Must be zero. Bit 2-3 Reserved: Must be zero.
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
record the node data element. record the node data element.
IOAM-Trace-Type: A 16-bit identifier which specifies which data
types are used in this node data list.
The IOAM-Trace-Type value is a bit field. The following bit
fields are defined in this document, with details on each field
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
IOAM-Trace-Type field, as follows:
Bit 0 (Most significant bit) When set indicates presence of
Hop_Lim and node_id in the node data.
Bit 1 When set indicates presence of ingress_if_id and
egress_if_id (short format) in the node data.
Bit 2 When set indicates presence of timestamp seconds in the
node data.
Bit 3 When set indicates presence of timestamp subseconds in
the node data.
Bit 4 When set indicates presence of transit delay in the node
data.
Bit 5 When set indicates presence of namespace specific data
(short format) in the node data.
Bit 6 When set indicates presence of queue depth in the node
data.
Bit 7 When set indicates presence of variable length Opaque
State Snapshot field.
Bit 8 When set indicates presence of Hop_Lim and node_id in
wide format in the node data.
Bit 9 When set indicates presence of ingress_if_id and
egress_if_id in wide format in the node data.
Bit 10 When set indicates presence of namespace specific data in
wide format in the node data.
Bit 11 When set indicates presence of buffer occupancy in the
node data.
Bit 12-22 Undefined. An IOAM encapsulating node must set the
value of each of these bits 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 23 When set indicates presence of the Checksum Complement
node data.
Section 4.2.2 describes the IOAM data types and their formats.
Within an in-situ OAM domain possible combinations of these bits
making the IOAM-Trace-Type can be restricted by configuration
knobs.
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. In
the pre-allocated trace option, the index contained in the pre-allocated trace option, the index contained in
RemainingLen identifies the offset for current active node data to RemainingLen identifies the offset for current active node data to
be populated. be populated.
4.1.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.
Data field and associated data type for each of the data field is Data field and associated data type for each of the data field is
shown below: shown below:
skipping to change at page 14, line 27 skipping to change at page 16, line 47
0x80000000. When this field is part of the data field but a node 0x80000000. When this field is part of the data field but a node
populating the field is not able to fill it, the field position in populating the field is not able to fill it, the field position in
the field must be filled with value 0xFFFFFFFF to mean not the field must be filled with value 0xFFFFFFFF to mean not
populated. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| transit delay | |O| transit delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
app_data: 4-octet placeholder which can be used by the node to add namespace specific data: 4-octet field which can be used by the node
application specific data. App_data represents a "free-format" to add namespace specific data. This represents a "free-format"
4-octet bit field with its semantics defined by a specific 4-octet bit field with its semantics defined in the context of a
deployment. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
queue depth: 4-octet unsigned integer field. This field indicates queue depth: 4-octet unsigned integer field. This field indicates
the current length of the egress interface queue of the interface the current length of the egress interface queue of the interface
from where the packet is forwarded out. The queue depth is from where the packet is forwarded out. The queue depth is
expressed as the current number of memory buffers used by the expressed as the current number of memory buffers used by the
queue (a packet may consume one or more memory buffers, depending queue (a packet may consume one or more memory buffers, depending
on its size). on its size).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| queue depth | | queue depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opaque State Snapshot: Variable length field. It allows the network Opaque State Snapshot: Variable length field. It allows the network
element to store an arbitrary state in the node data field , element to store an arbitrary state in the node data field,
without a pre-defined schema. The schema needs to be made known without a pre-defined schema. The schema is to be defined within
to the analyzer by some out-of-band mechanism. The specification the context of a namespace. The schema needs to be made known to
of this mechanism is beyond the scope of this document. The the analyzer by some out-of-band mechanism. The specification of
24-bit "Schema Id" field in the field indicates which particular this mechanism is beyond the scope of this document. A 24-bit
schema is used, and should be configured on the network element by "Schema Id" field, interpreted within the context of a namespace,
the operator. indicates which particular schema is used, and should be
configured on the network element by the operator.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Schema ID | | Length | Schema ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
skipping to change at page 16, line 29 skipping to change at page 18, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egress_if_id | | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ingress_if_id: 4-octet unsigned integer. Interface identifier to ingress_if_id: 4-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: 4-octet unsigned integer. Interface identifier to egress_if_id: 4-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.
app_data wide: 8-octet placeholder which can be used by the node to namespace specific data wide: 8-octet field which can be used by the
add application specific data. App data represents a "free- node to add namespace specific data. This represents a "free-
format" 8-octed bit field with its semantics defined by a specific format" 8-octet bit field with its semantics defined in the
deployment. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app data ~ | namespace specific data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ app data (contd) | ~ namespace specific data (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
buffer occupancy: 4-octet unsigned integer field. This field
indicates the current status of the buffer occupancy. The buffer
occupancy is expressed as the current number of memory buffers
used by the set of queues that share a common buffer pool.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
or Geneve. Without the Checksum Complement, nodes adding IOAM or Geneve. Without the Checksum Complement, nodes adding IOAM
node data must update the UDP Checksum field. When the Checksum node data must update the UDP Checksum field. When the Checksum
Complement is present, an IOAM encapsulating node or IOAM transit Complement is present, an IOAM encapsulating node or IOAM transit
node adding node data MUST carry out one of the following two node adding node data MUST carry out one of the following two
skipping to change at page 17, line 25 skipping to change at page 20, line 10
Checksum field or the Checksum Complement field. Checksum field or the Checksum Complement field.
Checksum Complement fields are used in a similar manner in Checksum Complement fields are used in a similar manner in
[RFC7820] and [RFC7821]. [RFC7820] and [RFC7821].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum Complement | Reserved | | Checksum Complement | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.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: 0xD400: IOAM-Trace-Type is 0xD400 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0xC000: IOAM-Trace-Type is 0xC000 then the format is: 0xC000: IOAM-Trace-Type is 0xC000 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 27 skipping to change at page 21, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp subseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x8400: IOAM-Trace-Type is 0x8400 then the format is: 0x8400: IOAM-Trace-Type is 0x8400 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x9400: IOAM-Trace-Type is 0x9400 then the format is: 0x9400: IOAM-Trace-Type is 0x9400 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | namespace specific data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x3180: IOAM-Trace-Type is 0x3180 then the format is: 0x3180: IOAM-Trace-Type is 0x3180 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 25 skipping to change at page 22, line 5
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node_id(contd) | | node_id(contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. IOAM Proof of Transit Option 4.3. IOAM Proof of Transit Option
IOAM Proof of Transit data is to support the path or service function IOAM Proof of Transit data is to support the path or service function
chain [RFC7665] verification use cases. Proof-of-transit uses chain [RFC7665] verification use cases. Proof-of-transit uses
methods like nested hashing or nested encryption of the IOAM data or methods like nested hashing or nested encryption of the IOAM data or
mechanisms such as Shamir's Secret Sharing Schema (SSSS). While mechanisms such as Shamir's Secret Sharing Schema (SSSS). While
details on how the IOAM data for the proof of transit option is details on how the IOAM data for the proof of transit option is
processed at IOAM encapsulating, decapsulating and transit nodes are processed at IOAM encapsulating, decapsulating and transit nodes are
outside the scope of the document, all of these approaches share the outside the scope of the document, all of these approaches share the
need to uniquely identify a packet as well as iteratively operate on need to uniquely identify a packet as well as iteratively operate on
a set of information that is handed from node to node. a set of information that is handed from node to node.
skipping to change at page 20, line 12 skipping to change at page 22, line 32
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IOAM POT Type | IOAM POT flags| Reserved | | 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.:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POT Option data field determined by IOAM-POT-Type | | 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 value 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 IOAM POT Type: 8-bit identifier of a particular POT variant that
specifies the POT data that is included. This document defines specifies the POT data that is included. This document defines
POT Type 0: POT Type 0:
0: POT data is a 16 Octet field as described below. 0: POT data is a 16 Octet field as described below.
IOAM POT flags: 8-bit. Following flags are defined: IOAM POT flags: 8-bit. Following flags are defined:
Bit 0 "Profile-to-use" (P-bit) (most significant bit). For IOAM Bit 0 "Profile-to-use" (P-bit) (most significant bit). For IOAM
POT types that use a maximum of two profiles to drive POT types that use a maximum of two profiles to drive
computation, indicates which POT-profile is used. The two computation, indicates which POT-profile is used. The two
profiles are numbered 0, 1. profiles are numbered 0, 1.
Bit 1-7 Reserved: Must be set to zero upon transmission and Bit 1-7 Reserved: Must be set to zero upon transmission and
ignored upon receipt. ignored upon receipt.
Reserved: 16-bit Reserved bits are present for future use. The
reserved bits Must be set to zero upon transmission and ignored
upon receipt.
POT Option data: Variable-length field. The type of which is POT Option data: Variable-length field. The type of which is
determined by the IOAM-POT-Type. determined by the IOAM-POT-Type.
4.2.1. IOAM Proof of Transit Type 0 4.3.1. IOAM Proof of Transit Type 0
IOAM proof of transit option of IOAM POT Type 0: IOAM proof of transit option of IOAM POT Type 0:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IOAM POT Type=0|P|R R R R R R R| Reserved | | Namespace-ID |IOAM POT Type=0|P|R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| Random | | | Random | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Random(contd) | O | Random(contd) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | | | Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd) | | | Cumulative (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Namespace-ID: 16-bit identifier of an IOAM namespace. The
Namespace-ID value of 0x0000 is defined as the default value 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 IOAM POT Type: 8-bit identifier of a particular POT variant that
specifies the POT data that is included. This section defines the specifies the POT data that is included. This section defines the
POT data when the IOAM POT Type is set to the value 0. POT data when the IOAM POT Type is set to the value 0.
P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit). P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit).
Indicates which POT-profile is used to generate the Cumulative. Indicates which POT-profile is used to generate the Cumulative.
Any node participating in POT will have a maximum of 2 profiles Any node participating in POT will have a maximum of 2 profiles
configured that drive the computation of cumulative. The two configured that drive the computation of cumulative. The two
profiles are numbered 0, 1. This bit conveys whether profile 0 or profiles are numbered 0, 1. This bit conveys whether profile 0 or
profile 1 is used to compute the Cumulative. profile 1 is used to compute the Cumulative.
R (7 bits): 7-bit IOAM POT flags for future use. MUST be set to R (7 bits): 7-bit IOAM POT flags for future use. MUST be set to
zero upon transmission and ignored upon receipt. zero upon transmission and ignored upon receipt.
Reserved: 16-bit Reserved bits are present for future use. The
reserved bits Must be set to zero upon transmission and ignored
upon receipt.
Random: 64-bit Per packet Random number. Random: 64-bit Per packet Random number.
Cumulative: 64-bit Cumulative that is updated at specific nodes by Cumulative: 64-bit Cumulative that is updated at specific nodes by
processing per packet Random number field and configured processing per packet Random number field and configured
parameters. parameters.
Note: Larger or smaller sizes of "Random" and "Cumulative" data are Note: Larger or smaller sizes of "Random" and "Cumulative" data are
feasible and could be required for certain deployments (e.g. in case feasible and could be required for certain deployments (e.g. in case
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.3. 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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-E2E-Type | Reserved | | 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E2E Option data field determined by IOAM-E2E-Type | | 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 value 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, then the node MUST NOT change the
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 tube which is
used to detect packet loss, packet reordering, or packet used to detect packet loss, packet reordering, or packet
duplication for that tube. Each tube leverages a duplication for that tube. Each tube leverages a
dedicated namespace for its sequence numbers. dedicated namespace for its sequence numbers.
skipping to change at page 23, line 30 skipping to change at page 26, line 31
populating this field, it assigns the value 0xFFFFFFFF. populating this field, it assigns the value 0xFFFFFFFF.
Note that this is a legitimate value in the NTP format, Note that this is a legitimate value in the NTP format,
valid for approximately 233 picoseconds in every second. valid for approximately 233 picoseconds in every second.
If the NTP format is used the analyzer should correlate If the NTP format is used the analyzer should correlate
several packets in order to detect the error indication. several packets in order to detect the error indication.
Bit 4-15 Undefined. An IOAM encapsulating node Must set the value Bit 4-15 Undefined. An IOAM encapsulating node Must set the value
of these bits to zero upon transmission and ignore upon of these bits to zero upon transmission and ignore upon
receipt. receipt.
Reserved: 16-bits Reserved bits are present for future use. The
reserved bits Must be set to zero upon transmission and ignored
upon receipt.
E2E Option data: Variable-length field. The type of which is E2E Option data: Variable-length field. The type of which is
determined by the IOAM-E2E-Type. determined by the IOAM-E2E-Type.
5. Timestamp Formats 5. Timestamp Formats
The IOAM data fields include a timestamp field which is represented The IOAM data fields include a timestamp field which is represented
in one of three possible timestamp formats. It is assumed that the in one of three possible timestamp formats. It is assumed that the
management plane is responsible for determining which timestamp management plane is responsible for determining which timestamp
format is used. format is used.
skipping to change at page 24, line 13 skipping to change at page 27, line 13
for the sake of completeness. for the sake of completeness.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds | | Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PTP [IEEE1588] Truncated Timestamp Format Figure 1: PTP [IEEE1588v2] Truncated Timestamp Format
Timestamp field format: Timestamp field format:
Seconds: specifies the integer portion of the number of seconds Seconds: specifies the integer portion of the number of seconds
since the epoch. since the epoch.
+ Size: 32 bits. + Size: 32 bits.
+ Units: seconds. + Units: seconds.
skipping to change at page 28, line 29 skipping to change at page 31, line 29
IOAM Trace Type IOAM Trace Type
IOAM Trace flags IOAM Trace flags
IOAM POT Type IOAM POT Type
IOAM POT flags IOAM POT flags
IOAM E2E Type IOAM E2E Type
IOAM Namespace-ID
will contain the current set of possibilities defined in this will contain the current set of possibilities defined in this
document. New registries in this name space are created via RFC document. New registries in this name space are created via RFC
Required process as per [RFC8126]. Required process as per [RFC8126].
The subsequent sub-sections detail the registries herein contained. The subsequent sub-sections detail the registries herein contained.
7.2. IOAM Type Registry 7.2. IOAM Type Registry
This registry defines 128 code points for the IOAM-Type field for This registry defines 128 code points for the IOAM-Type field for
identifying IOAM options as explained in Section 4. The following identifying IOAM options as explained in Section 4. The following
skipping to change at page 29, line 9 skipping to change at page 32, line 9
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 16-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.1. The meaning of Bit 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 1 of (Section 4.1.1). type are defined in this document in Paragraph 5 of Section 4.2.1:
The meaning for Bit 12 - 15 are available for assignment via RFC
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 subseconds
Bit 4 transit delay
Bit 5 namespace specific data in short format
Bit 6 queue depth
Bit 7 variable length Opaque State Snapshot
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 23 checksum complement
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 point 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.1. The meaning of Bit 0 - 1 for trace flags are defined in Section 4.2. The meaning of Bit 0 - 1 for trace flags are defined in
this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2 this document in Paragraph 3 of Section 4.2.1:
- 3 are available for assignment via RFC Required process as per
[RFC8126]. Bit 0 "Overflow" (O-bit)
Bit 1 "Loopback" (L-bit)
The meaning for Bits 2 - 3 are available for assignment via RFC
Required process as per [RFC8126].
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.2. The code point value 0 is IOAM proof of transit option Section 4.3. The code point value 0 is
defined in this document, 1 - 255 are available for assignment via defined in this document:
RFC Required process as per [RFC8126].
0: 16 Octet POT data
1 - 255 are available for assignment via RFC Required process as per
[RFC8126].
7.6. IOAM POT Flags Registry 7.6. IOAM POT Flags Registry
This registry defines code point for each bit in the 8 bit flags for This registry defines code points for each bit in the 8 bit flags for
IOAM POT option defined in Section 4.2. The meaning of Bit 0 for IOAM POT option defined in Section 4.3. The meaning of Bit 0 for
IOAM POT flags is defined in this document in Section 4.2. The IOAM POT flags is defined in this document in Section 4.3:
meaning for Bit 1 - 7 are available for assignment via RFC Required
process as per [RFC8126]. Bit 0 "Profile-to-use" (P-bit)
The meaning for Bits 1 - 7 are available for assignment via RFC
Required process as per [RFC8126].
7.7. IOAM E2E Type Registry 7.7. IOAM E2E Type Registry
This registry defines code points for each bit in the 16 bit IOAM- This registry defines code points for each bit in the 16 bit IOAM-
E2E-Type field for IOAM E2E option Section 4.3. The meaning of Bit 0 E2E-Type field for IOAM E2E option Section 4.4. The meaning of Bit 0
- 3 are defined in this document. The meaning of Bit 4 - 15 are - 3 are defined in this document:
available for assignments via RFC Required process as per [RFC8126].
Bit 0 64-bit sequence number
Bit 1 32-bit sequence number
Bit 2 timestamp seconds
Bit 3 timestamp subseconds
The meaning of Bits 4 - 15 are available for assignment via RFC
Required process as per [RFC8126].
7.8. IOAM Namespace-ID Registry
IANA is requested to set up an "IOAM Namespace-ID Registry",
containing 16-bit values. The meaning of Bit 0 is defined in this
document. IANA is requested to reserve the values 0x0001 to 0x7FFF
for private use (managed by operators), as specified in Section 4.1
of the current document. Registry entries for the values 0x8000 to
0xFFFF are to be assigned via the "Expert Review" policy defined in
[RFC8126].
0: default namespace (known to all IOAM nodes)
0x0001 - 0x7FFF: reserved for private use
0x8000 - 0xFFFF: unassigned
8. Security Considerations 8. Security Considerations
As discussed in [RFC7276], a successful attack on an OAM protocol in As discussed in [RFC7276], a successful attack on an OAM protocol in
general, and specifically on IOAM, can prevent the detection of general, and specifically on IOAM, can prevent the detection of
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.2) 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, and other information. performance, queue states, buffer occupancy and other information.
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 31, line 30 skipping to change at page 35, line 46
[POSIX] Institute of Electrical and Electronics Engineers, "IEEE [POSIX] Institute of Electrical and Electronics Engineers, "IEEE
Std 1003.1-2008 (Revision of IEEE Std 1003.1-2004) - IEEE Std 1003.1-2008 (Revision of IEEE Std 1003.1-2004) - IEEE
Standard for Information Technology - Portable Operating Standard for Information Technology - Portable Operating
System Interface (POSIX(R))", IEEE Std 1003.1-2008, 2008, System Interface (POSIX(R))", IEEE Std 1003.1-2008, 2008,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/1003.1-2008.html>. standard/1003.1-2008.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 32, line 8 skipping to change at page 36, line 26
[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-02 (work in progress), June 2018. timestamps-04 (work in progress), October 2018.
[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-06 (work in progress), March 2018. nvo3-geneve-08 (work in progress), October 2018.
[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.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017.
[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-00 (work in progress),
March 2018. March 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, <https://www.rfc- DOI 10.17487/RFC7276, June 2014,
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>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, <https://www.rfc- DOI 10.17487/RFC7665, October 2015,
editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way
Active Measurement Protocol (OWAMP) and Two-Way Active Active Measurement Protocol (OWAMP) and Two-Way Active
Measurement Protocol (TWAMP)", RFC 7820, Measurement Protocol (TWAMP)", RFC 7820,
DOI 10.17487/RFC7820, March 2016, <https://www.rfc- DOI 10.17487/RFC7820, March 2016,
editor.org/info/rfc7820>. <https://www.rfc-editor.org/info/rfc7820>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/info/rfc7821>. 2016, <https://www.rfc-editor.org/info/rfc7821>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
Authors' Addresses Authors' Addresses
Frank Brockners Frank Brockners
Cisco Systems, Inc. Cisco Systems, Inc.
Hansaallee 249, 3rd Floor Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Shwetha Bhandari Shwetha Bhandari
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Sarjapura Marathalli Outer Ring Road Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087 Bangalore, KARNATAKA 560 087
India India
Email: shwethab@cisco.com Email: shwethab@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 34, line 4 skipping to change at page 38, line 19
Email: shwethab@cisco.com Email: shwethab@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States United States
Email: cpignata@cisco.com Email: cpignata@cisco.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
John Leddy John Leddy
Comcast Comcast
United States United States
Email: John_Leddy@cable.comcast.com Email: John_Leddy@cable.comcast.com
Stephen Youell Stephen Youell
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
Tal Mizrahi Tal Mizrahi
Marvell Huawei Network.IO Innovation Lab
6 Hamada St.
Yokneam 2066721
Israel Israel
Email: talmi@marvell.com Email: tal.mizrahi.phd@gmail.com
David Mozes David Mozes
Email: mosesster@gmail.com Email: mosesster@gmail.com
Petr Lapukhov Petr Lapukhov
Facebook Facebook
1 Hacker Way 1 Hacker Way
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
 End of changes. 63 change blocks. 
185 lines changed or deleted 371 lines changed or added

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