draft-ietf-ippm-ioam-data-10.txt   draft-ietf-ippm-ioam-data-11.txt 
ippm F. Brockners, Ed. ippm F. Brockners, Ed.
Internet-Draft S. Bhandari, Ed. Internet-Draft S. Bhandari, Ed.
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 14, 2021 T. Mizrahi, Ed. Expires: May 26, 2021 T. Mizrahi, Ed.
Huawei Huawei
July 13, 2020 November 22, 2020
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-10 draft-ietf-ippm-ioam-data-11
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 encapsulated into a variety of In-situ OAM data fields can be encapsulated into a variety of
protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension protocols such as NSH, Segment Routing, Geneve, 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 1, line 39 skipping to change at page 1, line 39
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 January 14, 2021. This Internet-Draft will expire on May 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope, Applicability, and Assumptions . . . . . . . . . . . . 5 4. Scope, Applicability, and Assumptions . . . . . . . . . . . . 5
5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6 5. IOAM Data-Fields, Types, Nodes . . . . . . . . . . . . . . . 6
5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 6 5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 6
5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7 5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7
5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 8 5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 8
5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 10 5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 10
5.4.1. Pre-allocated and Incremental Trace Option-Types . . 13 5.4.1. Pre-allocated and Incremental Trace Option-Types . . 13
5.4.2. IOAM node data fields and associated formats . . . . 17 5.4.2. IOAM node data fields and associated formats . . . . 17
5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 17 5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 18
5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 18 5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 18
5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 18 5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19
5.4.2.4. timestamp subseconds . . . . . . . . . . . . . . 18 5.4.2.4. timestamp subseconds . . . . . . . . . . . . . . 19
5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 19 5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 19
5.4.2.6. namespace specific data . . . . . . . . . . . . . 19 5.4.2.6. namespace specific data . . . . . . . . . . . . . 20
5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 19 5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 20
5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20 5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 20
5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 20 5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 21
5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 21 5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22
5.4.2.11. namespace specific data wide . . . . . . . . . . 21 5.4.2.11. namespace specific data wide . . . . . . . . . . 22
5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 22 5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 22
5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 22 5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23
5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 23 5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 23
5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 25 5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 25
5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 27 5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 27
5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 28 5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 28
6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 30 6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 30
6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 30 6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 30
6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 31 6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 32
6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 33 6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 33
7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 34 7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 35 8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 35
8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 35 8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36
8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 36 8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 36
8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 36 8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 37
8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 36 8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 37
8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 37 8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 37
8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 37 8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 37
9. Management and Deployment Considerations . . . . . . . . . . 38 9. Management and Deployment Considerations . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . 40 12.2. Informative References . . . . . . . . . . . . . . . . . 41
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 being sent within data is added to the data packets rather than being sent within
packets specifically dedicated to OAM. IOAM is to complement packets specifically dedicated to OAM. IOAM is to complement
skipping to change at page 9, line 7 skipping to change at page 9, line 7
(Namespace-ID). IOAM-Namespace identifiers MUST be present and (Namespace-ID). IOAM-Namespace identifiers MUST be present and
populated in all IOAM-Option-Types. The Namespace-ID value is populated in all IOAM-Option-Types. The Namespace-ID value is
divided into two sub-ranges: divided into two sub-ranges:
o An operator-assigned range from 0x0001 to 0x7FFF o An operator-assigned range from 0x0001 to 0x7FFF
o An IANA-assigned range from 0x8000 to 0xFFFF o An IANA-assigned range from 0x8000 to 0xFFFF
The IANA-assigned range is intended to allow future extensions to The IANA-assigned range is intended to allow future extensions to
have new and interoperable IOAM functionality, while the operator- have new and interoperable IOAM functionality, while the operator-
assigned range is intended to be domain specific, and managed by the assigned range is intended to be domain specific, and managed by the
network operator. The Namespace-ID value of 0x0000 is default and network operator. The Namespace-ID value of 0x0000 is the "Default-
known to all the nodes implementing IOAM. Namespace-ID". The Default-Namespace-ID indicates that no specific
namespace is associated with the IOAM data fields in the packet. The
Default-Namespace-ID MUST be supported by all nodes implementing
IOAM. A use-case for the Default-Namespace-ID are deployments which
do not leverage specific namespaces for some or all of their packets
that carry IOAM data fields.
Namespace identifiers allow devices which are IOAM capable to Namespace identifiers allow devices which are IOAM capable to
determine: determine:
o whether IOAM-Option-Type(s) need to be processed by a device: If o whether IOAM-Option-Type(s) need to be processed by a device: If
the Namespace-ID contained in a packet does not match any the Namespace-ID contained in a packet does not match any
Namespace-ID the node is configured to operate on, then the node Namespace-ID the node is configured to operate on, then the node
MUST NOT change the contents of the IOAM-Data-Fields. MUST NOT change the contents of the IOAM-Data-Fields.
o which IOAM-Option-Type needs to be processed/updated in case there o which IOAM-Option-Type needs to be processed/updated in case there
skipping to change at page 10, line 39 skipping to change at page 10, line 45
two IOAM-Namespaces, in a way that each IOAM-Namespace is two IOAM-Namespaces, in a way that each IOAM-Namespace is
represented by one of two IOAM-Option-Types in the packet. represented by one of two IOAM-Option-Types in the packet.
Each node would record data only for the IOAM-Namespace that it Each node would record data only for the IOAM-Namespace that it
belongs to, ignoring the other IOAM-Option-Type with a IOAM- belongs to, ignoring the other IOAM-Option-Type with a IOAM-
Namespace to which it doesn't belong. To retrieve a full view Namespace to which it doesn't belong. To retrieve a full view
of the deployment, the captured IOAM-Data-Fields of the two of the deployment, the captured IOAM-Data-Fields of the two
IOAM-Namespaces need to be correlated. IOAM-Namespaces need to be correlated.
5.4. IOAM Trace Option-Types 5.4. IOAM Trace Option-Types
"IOAM tracing data" is expected to be either collected at every IOAM "IOAM tracing data" is expected to be collected at every IOAM transit
transit node that a packet traverses to ensure visibility into the node that a packet traverses to ensure visibility into the entire
entire path a packet takes within an IOAM-Domain. I.e., in a typical path a packet takes within an IOAM-Domain. I.e., in a typical
deployment all nodes in an IOAM-Domain would participate in IOAM and deployment all nodes in an IOAM-Domain would participate in IOAM and
thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating
nodes. If not all nodes within a domain support IOAM functionality nodes. If not all nodes within a domain support IOAM functionality
as defined in this document, IOAM tracing information (i.e., node as defined in this document, IOAM tracing information (i.e., node
data, see below) will only be collected on those nodes which support data, see below) will only be collected on those nodes which support
IOAM functionality as defined in this document. Nodes which do not IOAM functionality as defined in this document. Nodes which do not
support IOAM functionality as defined in this document will forward support IOAM functionality as defined in this document will forward
the packet without any changes to the IOAM-Data-Fields. The maximum the packet without any changes to the IOAM-Data-Fields. The maximum
number of hops and the minimum path MTU of the IOAM domain is assumed number of hops and the minimum path MTU of the IOAM domain is assumed
to be known. An overflow indicator (O-bit) is defined as one of the to be known. An overflow indicator (O-bit) is defined as one of the
skipping to change at page 14, line 4 skipping to change at page 14, line 36
~ ... ~ S ~ ... ~ S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Namespace-ID: 16-bit identifier of an IOAM-Namespace. The Namespace-ID: 16-bit identifier of an IOAM-Namespace. The
Namespace-ID value of 0x0000 is defined as the default value and Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
MUST be known to all the nodes implementing IOAM. For any other ID" (see Section 5.3) and MUST be known to all the nodes
Namespace-ID value that does not match any Namespace-ID the node implementing IOAM. For any other Namespace-ID value that does not
is configured to operate on, the node MUST NOT change the contents match any Namespace-ID the node is configured to operate on, the
of the IOAM-Data-Fields. node MUST NOT change the contents of the IOAM-Data-Fields.
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 22 is not set, then NodeLen specifies the If IOAM-Trace-Type bit 22 is not set, then NodeLen specifies the
actual length added by each node. If IOAM-Trace-Type bit 22 is actual length added by each node. If IOAM-Trace-Type bit 22 is
set, then the actual length added by a node would be (NodeLen + set, then the actual length added by a node would be (NodeLen +
length of the "Opaque State Snapshot" field) in 4 octet units. length of the "Opaque State Snapshot" field) in 4 octet units.
skipping to change at page 26, line 23 skipping to change at page 26, line 35
IOAM proof of transit Option-Type IOAM-Data-Fields MUST be IOAM proof of transit Option-Type IOAM-Data-Fields MUST be
4-octet aligned: 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: 16-bit identifier of an IOAM-Namespace. The
Namespace-ID value of 0x0000 is defined as the default value and Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
MUST be known to all the nodes implementing IOAM. For any other ID" (see Section 5.3) and MUST be known to all the nodes
Namespace-ID value that does not match any Namespace-ID the node implementing IOAM. For any other Namespace-ID value that does not
is configured to operate on, the node MUST NOT change the contents match any Namespace-ID the node is configured to operate on, the
of the IOAM-Data-Fields. 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.
If a node receives an IOAM POT Type value that it does not If a node receives an IOAM POT Type value that it does not
understand, the node MUST NOT change the contents of the IOAM- understand, the node MUST NOT change the contents of the IOAM-
Data-Fields. Data-Fields.
skipping to change at page 27, line 24 skipping to change at page 27, line 37
| 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: 16-bit identifier of an IOAM-Namespace. The
Namespace-ID value of 0x0000 is defined as the default value and Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
MUST be known to all the nodes implementing IOAM. For any other ID" (see Section 5.3) and MUST be known to all the nodes
Namespace-ID value that does not match any Namespace-ID the node implementing IOAM. For any other Namespace-ID value that does not
is configured to operate on, the node MUST NOT change the contents match any Namespace-ID the node is configured to operate on, the
of the IOAM-Data-Fields. 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
skipping to change at page 28, line 38 skipping to change at page 29, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST IOAM Edge-to-Edge Option-Type IOAM-Data-Fields MUST
be 4-octet aligned: 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: 16-bit identifier of an IOAM-Namespace. The
Namespace-ID value of 0x0000 is defined as the default value and Namespace-ID value of 0x0000 is defined as the "Default-Namespace-
MUST be known to all the nodes implementing IOAM. For any other ID" (see Section 5.3) and MUST be known to all the nodes
Namespace-ID value that does not match any Namespace-ID the node implementing IOAM. For any other Namespace-ID value that does not
is configured to operate on, then the node MUST NOT change the match any Namespace-ID the node is configured to operate on, then
contents of the IOAM-Data-Fields. 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 "packet group" 64-bit sequence number added to a specific "packet group"
which is used to detect packet loss, packet reordering, which is used to detect packet loss, packet reordering,
or packet duplication within the group. The "packet or packet duplication within the group. The "packet
skipping to change at page 30, line 30 skipping to change at page 30, line 42
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.
6.1. PTP Truncated Timestamp Format 6.1. PTP Truncated Timestamp Format
The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit
timestamp format. The truncated timestamp format is a 64-bit field, timestamp format. The truncated timestamp format is a 64-bit field,
which is the 64 least significant bits of the 80-bit PTP timestamp. which is the 64 least significant bits of the 80-bit PTP timestamp.
The PTP truncated format is specified in Section 4.3 of The PTP truncated format is specified in Section 4.3 of [RFC8877],
[I-D.ietf-ntp-packet-timestamps], and the details are presented below and the details are presented below 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 [IEEE1588v2] Truncated Timestamp Format Figure 1: PTP [IEEE1588v2] Truncated Timestamp Format
skipping to change at page 31, line 44 skipping to change at page 32, line 13
the timestamp MAY be derived from the PTP-synchronized clock, the timestamp MAY be derived from the PTP-synchronized clock,
allowing the timestamp to be measured with respect to the clock of allowing the timestamp to be measured with respect to the clock of
an PTP Grandmaster clock. an PTP Grandmaster clock.
The PTP truncated timestamp format is not affected by leap The PTP truncated timestamp format is not affected by leap
seconds. seconds.
6.2. NTP 64-bit Timestamp Format 6.2. NTP 64-bit Timestamp Format
The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits
long. This format is specified in Section 4.2.1 of long. This format is specified in Section 4.2.1 of [RFC8877], and
[I-D.ietf-ntp-packet-timestamps], and the details are presented below the details are presented below 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTP [RFC5905] 64-bit Timestamp Format Figure 2: NTP [RFC5905] 64-bit Timestamp Format
skipping to change at page 39, line 37 skipping to change at page 40, line 9
the operator. Indeed, in order to limit the scope of threats the operator. Indeed, in order to limit the scope of threats
mentioned above to within the current network domain the network mentioned above to within the current network domain the network
operator is expected to enforce policies that prevent IOAM traffic operator is expected to enforce policies that prevent IOAM traffic
from leaking outside of the IOAM domain, and prevent IOAM data from from leaking outside of the IOAM domain, and prevent IOAM data from
outside the domain to be processed and used within the domain. outside the domain to be processed and used within the domain.
The security considerations of a system that deploys IOAM, much like The security considerations of a system that deploys IOAM, much like
any system, has to be reviewed on a per-deployment-scenario basis, any system, has to be reviewed on a per-deployment-scenario basis,
based on a systems-specific threat analysis, which can lead to based on a systems-specific threat analysis, which can lead to
specific security solutions that are beyond the scope of the current specific security solutions that are beyond the scope of the current
document. For example, in an IOAM deployment that is not confined to document. Specifically, in an IOAM deployment that is not confined
a single LAN, but spans multiple inter-connected sites, the inter- to a single LAN, but spans multiple inter-connected sites (for
site links can be secured (e.g., by IPsec) in order to avoid external example, using an overlay network), the inter-site links can be
threats. secured (e.g., by IPsec) in order to avoid external threats.
11. Acknowledgements 11. 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, Andrew Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, Andrew
Yourtchenko, Aviv Kfir, Tianran Zhou and Zhenbin (Robin) for the Yourtchenko, Aviv Kfir, Tianran Zhou and Zhenbin (Robin) for the
comments and advice. comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
skipping to change at page 40, line 50 skipping to change at page 41, line 25
[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>.
12.2. Informative References 12.2. Informative References
[I-D.brockners-opsawg-ioam-deployment] [I-D.brockners-opsawg-ioam-deployment]
Brockners, F., Bhandari, S., and d. Brockners, F., Bhandari, S., and d.
daniel.bernier@bell.ca, "In-situ OAM Deployment", draft- daniel.bernier@bell.ca, "In-situ OAM Deployment", draft-
brockners-opsawg-ioam-deployment-01 (work in progress), brockners-opsawg-ioam-deployment-02 (work in progress),
March 2020. September 2020.
[I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-09 (work in progress), March 2020.
[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-16 (work in progress), March 2020. nvo3-geneve-16 (work in progress), March 2020.
[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-09 (work Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan-
in progress), December 2019. gpe-10 (work in progress), July 2020.
[I-D.ietf-sfc-proof-of-transit] [I-D.ietf-sfc-proof-of-transit]
Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
Youell, "Proof of Transit", draft-ietf-sfc-proof-of- Youell, "Proof of Transit", draft-ietf-sfc-proof-of-
transit-06 (work in progress), June 2020. transit-08 (work in progress), November 2020.
[I-D.ioamteam-ippm-ioam-direct-export] [I-D.ioamteam-ippm-ioam-direct-export]
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct-
export-00 (work in progress), October 2019. export-00 (work in progress), October 2019.
[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.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-03 (work in progress), draft-spiegel-ippm-ioam-rawexport-04 (work in progress),
March 2020. November 2020.
[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>.
skipping to change at page 42, line 29 skipping to change at page 42, line 45
[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., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[RFC8877] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", RFC 8877,
DOI 10.17487/RFC8877, September 2020,
<https://www.rfc-editor.org/info/rfc8877>.
[SSS] Wikipedia, "Shamir's Secret Sharing", [SSS] Wikipedia, "Shamir's Secret Sharing",
<https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>. <https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>.
Contributors' Addresses Contributors' Addresses
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
 End of changes. 31 change blocks. 
69 lines changed or deleted 72 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/