< draft-ietf-ippm-ioam-data-15.txt   draft-ietf-ippm-ioam-data-16.txt >
ippm F. Brockners, Ed. ippm F. Brockners, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track S. Bhandari, Ed. Intended status: Standards Track S. Bhandari, Ed.
Expires: April 6, 2022 Thoughtspot Expires: May 12, 2022 Thoughtspot
T. Mizrahi, Ed. T. Mizrahi, Ed.
Huawei Huawei
October 3, 2021 November 8, 2021
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-15 draft-ietf-ippm-ioam-data-16
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 in the network. This document discusses the data traverses a path in the network. This document discusses the data
fields and associated data types for in-situ OAM. In-situ OAM data fields and associated data types for in-situ OAM. In-situ OAM data
fields can be encapsulated into a variety of protocols such as NSH, fields can be encapsulated into a variety of protocols such as NSH,
Segment Routing, Geneve, or IPv6. In-situ OAM can be used to Segment Routing, Geneve, or IPv6. In-situ OAM can be used to
complement OAM mechanisms based on, e.g., ICMP or other types of complement OAM mechanisms based on, e.g., ICMP or other types of
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2022. This Internet-Draft will expire on May 12, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . 7 5.1. IOAM Data-Fields and Option-Types . . . . . . . . . . . . 7
5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7 5.2. IOAM-Domains and types of IOAM Nodes . . . . . . . . . . 7
5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 9 5.3. IOAM-Namespaces . . . . . . . . . . . . . . . . . . . . . 8
5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 11 5.4. IOAM Trace Option-Types . . . . . . . . . . . . . . . . . 11
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 . . . . 18 5.4.2. IOAM node data fields and associated formats . . . . 17
5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 18 5.4.2.1. Hop_Lim and node_id short format . . . . . . . . 18
5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 19 5.4.2.2. ingress_if_id and egress_if_id . . . . . . . . . 19
5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19 5.4.2.3. timestamp seconds . . . . . . . . . . . . . . . . 19
5.4.2.4. timestamp fraction . . . . . . . . . . . . . . . 20 5.4.2.4. timestamp fraction . . . . . . . . . . . . . . . 20
5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 20 5.4.2.5. transit delay . . . . . . . . . . . . . . . . . . 20
5.4.2.6. namespace specific data . . . . . . . . . . . . . 20 5.4.2.6. namespace specific data . . . . . . . . . . . . . 20
5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 21 5.4.2.7. queue depth . . . . . . . . . . . . . . . . . . . 21
5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 21 5.4.2.8. Checksum Complement . . . . . . . . . . . . . . . 21
5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 22 5.4.2.9. Hop_Lim and node_id wide . . . . . . . . . . . . 22
5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22 5.4.2.10. ingress_if_id and egress_if_id wide . . . . . . . 22
5.4.2.11. namespace specific data wide . . . . . . . . . . 22 5.4.2.11. namespace specific data wide . . . . . . . . . . 22
5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 23 5.4.2.12. buffer occupancy . . . . . . . . . . . . . . . . 23
5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23 5.4.2.13. Opaque State Snapshot . . . . . . . . . . . . . . 23
5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 24 5.4.3. Examples of IOAM node data . . . . . . . . . . . . . 24
5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 26 5.5. IOAM Proof of Transit Option-Type . . . . . . . . . . . . 26
5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 28 5.5.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 28
5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 29 5.6. IOAM Edge-to-Edge Option-Type . . . . . . . . . . . . . . 28
6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 31 6. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 31
6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 31 6.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 31
6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 32 6.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 32
6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 34 6.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 33
7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 35 7. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 36 8.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 35
8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36 8.2. IOAM Trace-Type Registry . . . . . . . . . . . . . . . . 36
8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 37 8.3. IOAM Trace-Flags Registry . . . . . . . . . . . . . . . . 37
8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 38 8.4. IOAM POT-Type Registry . . . . . . . . . . . . . . . . . 38
8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 38 8.5. IOAM POT-Flags Registry . . . . . . . . . . . . . . . . . 38
8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 39 8.6. IOAM E2E-Type Registry . . . . . . . . . . . . . . . . . 38
8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 39 8.7. IOAM Namespace-ID Registry . . . . . . . . . . . . . . . 39
9. Management and Deployment Considerations . . . . . . . . . . 40 9. Management and Deployment Considerations . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 44
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 5, line 23 skipping to change at page 5, line 23
comprises 8 octets. comprises 8 octets.
4. Scope, Applicability, and Assumptions 4. Scope, Applicability, and Assumptions
IOAM assumes a set of constraints as well as guiding principles and IOAM assumes a set of constraints as well as guiding principles and
concepts that go hand in hand with the definition of the IOAM data concepts that go hand in hand with the definition of the IOAM data
fields. These constraints, guiding principles, and concepts are fields. These constraints, guiding principles, and concepts are
described in this section. A discussion of how IOAM data fields and described in this section. A discussion of how IOAM data fields and
the associated concepts are applied to an IOAM deployment are out of the associated concepts are applied to an IOAM deployment are out of
scope for this document. Please refer to scope for this document. Please refer to
[I-D.brockners-opsawg-ioam-deployment] for IOAM deployment [I-D.ietf-ippm-ioam-deployment] for IOAM deployment considerations.
considerations.
Scope: This document defines the data fields and associated data Scope: This document defines the data fields and associated data
types for in-situ OAM. The in-situ OAM data fields can be types for in-situ OAM. The in-situ OAM data fields can be
encapsulated in a variety of protocols, including NSH, Segment encapsulated in a variety of protocols, including NSH, Segment
Routing, Geneve, and IPv6. Specification details for these different Routing, Geneve, and IPv6. Specification details for these different
protocols are outside the scope of this document. It is expected protocols are outside the scope of this document. It is expected
that each such encapsulation would be specified by an RFC, jointly that each such encapsulation would be specified by an RFC, jointly
designed by the working group that develops or maintains the designed by the working group that develops or maintains the
encapsulation protocol and the IETF IPPM working group. encapsulation protocol and the IETF IPPM working group.
Deployment domain (or scope) of in-situ OAM deployment: IOAM is Deployment domain (or scope) of in-situ OAM deployment: IOAM is
focused on "limited domains" as defined in [RFC8799]. For IOAM, a focused on "limited domains" as defined in [RFC8799]. For IOAM, a
limited domain could for example be an enterprise campus using limited domain could for example be an enterprise campus using
physical connections between devices or an overlay network using physical connections between devices or an overlay network using
virtual connections / tunnels for connectivity between said devices. virtual connections / tunnels for connectivity between said devices.
A limited domain which uses IOAM may constitute one or multiple "IOAM A limited domain which uses IOAM may constitute one or multiple
domains", each disambiguated through separate namespace identifiers. "IOAM-domains", each disambiguated through separate namespace
An IOAM domain is bounded by its perimeter or edge. IOAM domains may identifiers. An IOAM-domain is bounded by its perimeter or edge.
overlap inside the limited domain. Designers of protocol IOAM-domains may overlap inside the limited domain. Designers of
encapsulations for IOAM specify mechanisms to ensure that IOAM data protocol encapsulations for IOAM specify mechanisms to ensure that
stays within an IOAM domain. In addition, the operator of such a IOAM data stays within an IOAM-domain. In addition, the operator of
domain is expected to put provisions in place to ensure that IOAM such a domain is expected to put provisions in place to ensure that
data does not leak beyond the edge of an IOAM domain using, for IOAM data does not leak beyond the edge of an IOAM-domain using, for
example, packet filtering methods. The operator SHOULD consider the example, packet filtering methods. The operator SHOULD consider the
potential operational impact of IOAM to mechanisms such as ECMP potential operational impact of IOAM to mechanisms such as ECMP
processing (e.g., load-balancing schemes based on packet length could processing (e.g., load-balancing schemes based on packet length could
be impacted by the increased packet size due to IOAM), path MTU be impacted by the increased packet size due to IOAM), path MTU
(i.e., ensure that the MTU of all links within a domain is (i.e., ensure that the MTU of all links within a domain is
sufficiently large to support the increased packet size due to IOAM) sufficiently large to support the increased packet size due to IOAM)
and ICMP message handling (i.e., in case of IPv6, IOAM support for and ICMP message handling (i.e., in case of IPv6, IOAM support for
ICMPv6 Echo Request/Reply is desired which would translate into ICMPv6 Echo Request/Reply is desired which would translate into
ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an
Echo Request message to an Echo Reply message). Echo Request message to an Echo Reply message).
skipping to change at page 7, line 32 skipping to change at page 7, line 32
o Proof of Transit (POT) Option-Type o Proof of Transit (POT) Option-Type
o Edge-to-Edge (E2E) Option-Type o Edge-to-Edge (E2E) Option-Type
Future IOAM-Option-Types can be allocated by IANA, as described in Future IOAM-Option-Types can be allocated by IANA, as described in
Section 8.1. Section 8.1.
5.2. IOAM-Domains and types of IOAM Nodes 5.2. IOAM-Domains and types of IOAM Nodes
IOAM is expected to be deployed in a specific domain. The part of Section 4 already mentioned that IOAM is expected to be deployed in a
the network which employs IOAM is referred to as the "IOAM-Domain". limited domain [RFC8799]. One or more IOAM-Option-Types are added to
One or more IOAM-Option-Types are added to a packet upon entering the a packet upon entering an IOAM-Domain and are removed from the packet
IOAM-Domain and are removed from the packet when exiting the domain. when exiting the domain. Within the IOAM-Domain, the IOAM-Data-
Within the IOAM-Domain, the IOAM-Data-Fields MAY be updated by Fields MAY be updated by network nodes that the packet traverses. An
network nodes that the packet traverses. An IOAM-Domain consists of IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM
"IOAM encapsulating nodes", "IOAM decapsulating nodes" and "IOAM decapsulating nodes" and "IOAM transit nodes". The role of a node
transit nodes". The role of a node (i.e., encapsulating, transit, (i.e., encapsulating, transit, decapsulating) is defined within an
decapsulating) is defined within an IOAM-Namespace (see below). A IOAM-Namespace (see below). A node can have different roles in
node can have different roles in different IOAM-Namespaces. different IOAM-Namespaces.
A device which adds at least one IOAM-Option-Type to the packet is A device which adds at least one IOAM-Option-Type to the packet is
called an "IOAM encapsulating node", whereas a device which removes called an "IOAM encapsulating node", whereas a device which removes
an IOAM-Option-Type is referred to as an "IOAM decapsulating node". an IOAM-Option-Type is referred to as an "IOAM decapsulating node".
Nodes within the domain which are aware of IOAM data and read and/or Nodes within the domain which are aware of IOAM data and read and/or
write and/or process IOAM data are called "IOAM transit nodes". IOAM write and/or process IOAM data are called "IOAM transit nodes". IOAM
nodes which add or remove the IOAM-Data-Fields can also update the nodes which add or remove the IOAM-Data-Fields can also update the
IOAM-Data-Fields at the same time. Or in other words, IOAM IOAM-Data-Fields at the same time. Or in other words, IOAM
encapsulating or decapsulating nodes can also serve as IOAM transit encapsulating or decapsulating nodes can also serve as IOAM transit
nodes at the same time. Note that not every node in an IOAM domain nodes at the same time. Note that not every node in an IOAM-domain
needs to be an IOAM transit node. For example, a deployment might needs to be an IOAM transit node. For example, a deployment might
require that packets traverse a set of firewalls which support IOAM. require that packets traverse a set of firewalls which support IOAM.
In that case, only the set of firewall nodes would be IOAM transit In that case, only the set of firewall nodes would be IOAM transit
nodes rather than all nodes. nodes rather than all nodes.
An "IOAM encapsulating node" incorporates one or more IOAM-Option- An "IOAM encapsulating node" incorporates one or more IOAM-Option-
Types (from the list of IOAM-Types, see Section 8.1) into packets Types (from the list of IOAM-Types, see Section 8.1) into packets
that IOAM is enabled for. If IOAM is enabled for a selected subset that IOAM is enabled for. If IOAM is enabled for a selected subset
of the traffic, the IOAM encapsulating node is responsible for of the traffic, the IOAM encapsulating node is responsible for
applying the IOAM functionality to the selected subset. applying the IOAM functionality to the selected subset.
An "IOAM transit node" read and/or write and/or process one or more An "IOAM transit node" reads and/or writes and/or processes one or
of the IOAM-Data-Fields. If both the Pre-allocated and the more of the IOAM-Data-Fields. If both the Pre-allocated and the
Incremental Trace Option-Types are present in the packet, each IOAM Incremental Trace Option-Types are present in the packet, each IOAM
transit node based on configuration and available implementation of transit node based on configuration and available implementation of
IOAM populates IOAM trace data in either Pre-allocated or Incremental IOAM might populate IOAM trace data in either Pre-allocated or
Trace Option-Type but not both. A transit node MUST ignore IOAM- Incremental Trace Option-Type but not both. Note that not populating
Option-Types that it does not understand. A transit node MUST NOT any of the Trace Option-Types is also valid behavior for an IOAM
add new IOAM-Option-Types to a packet, MUST NOT remove IOAM-Option- transit node. A transit node MUST ignore IOAM-Option-Types that it
Types from a packet, and MUST NOT change the IOAM-Data-Fields of an does not understand. A transit node MUST NOT add new IOAM-Option-
IOAM Edge-to-Edge Option-Type. Types to a packet, MUST NOT remove IOAM-Option-Types from a packet,
and MUST NOT change the IOAM-Data-Fields of an IOAM Edge-to-Edge
Option-Type.
An "IOAM decapsulating node" removes IOAM-Option-Type(s) from An "IOAM decapsulating node" removes IOAM-Option-Type(s) from
packets. packets.
The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
node is always performed within a specific IOAM-Namespace. This node is always performed within a specific IOAM-Namespace. This
means that an IOAM node which is, e.g., an IOAM-decapsulating node means that an IOAM node which is, e.g., an IOAM-decapsulating node
for IOAM-Namespace "A" but not for IOAM-Namespace "B" will only for IOAM-Namespace "A" but not for IOAM-Namespace "B" will only
remove the IOAM-Option-Types for IOAM-Namespace "A" from the packet. remove the IOAM-Option-Types for IOAM-Namespace "A" from the packet.
Note that this applies even for IOAM-Option-Types that the node does Note that this applies even for IOAM-Option-Types that the node does
not understand, for example an IOAM-Option-Type other than the four not understand, for example an IOAM-Option-Type other than the four
described above, that is added in a future revision. An IOAM described above, that is added in a future revision.
decapsulating node situated at the edge of an IOAM domain MUST remove
all IOAM-Option-Types and associated encapsulation headers for all
IOAM-Namespaces from the packet.
IOAM-Namespaces allow for a namespace-specific definition and IOAM-Namespaces allow for a namespace-specific definition and
interpretation of IOAM-Data-Fields. An interface-id could for interpretation of IOAM-Data-Fields. An interface-id could for
example point to a physical interface (e.g., to understand which example point to a physical interface (e.g., to understand which
physical interface of an aggregated link is used when receiving or physical interface of an aggregated link is used when receiving or
transmitting a packet) whereas in another case it could refer to a transmitting a packet) whereas in another case it could refer to a
logical interface (e.g., in case of tunnels). Please refer to logical interface (e.g., in case of tunnels). Please refer to
Section 5.3 for details on IOAM-Namespaces. Section 5.3 for details on IOAM-Namespaces.
5.3. IOAM-Namespaces 5.3. IOAM-Namespaces
An IOAM-Namespace can be associated to a subset or all of the the IOAM-Namespaces add further context to IOAM-Option-Types and
IOAM-Option-Types and their corresponding IOAM-Data-Fields. IOAM- associated IOAM-Data-Fields. The IOAM-Option-Types and associated
Namespaces add further context to IOAM-Option-Types and associated IOAM-Data-Fields are interpreted as defined in this document,
IOAM-Data-Fields. The IOAM-Option-Types and associated IOAM-Data- regardless of the value of the IOAM-Namespace. However, IOAM-
Fields are interpreted as defined in this document, regardless of the Namespaces provide a way to group nodes to support different
value of the IOAM-Namespace. However, IOAM-Namespaces provide a way deployment approaches of IOAM (see a few example use-cases below).
to group nodes to support different deployment approaches of IOAM IOAM-Namespaces also help to resolve potential issues which can occur
(see a few example use-cases below). IOAM-Namespaces also help to due to IOAM-Data-Fields not being globally unique (e.g., IOAM node
resolve potential issues which can occur due to IOAM-Data-Fields not identifiers do not have to be globally unique). IOAM-Data-Fields
being globally unique (e.g., IOAM node identifiers do not have to be significance is always within a particular IOAM-Namespace. Given
globally unique). IOAM-Data-Fields significance is always within a that IOAM-Data-Fields are always interpreted the context of a
particular IOAM-Namespace. Given that IOAM-Data-Fields are always specific namespace, the namespace-id field always needs to be carried
interpreted the context of a specific namespace, the namespace-id along with the IOAM data-fields themselves.
field always needs to be carried along with the IOAM data-fields
themselves.
An IOAM-Namespace is identified by a 16-bit namespace identifier An IOAM-Namespace is identified by a 16-bit namespace identifier
(Namespace-ID). The IOAM-Namespace field is included in all the (Namespace-ID). The IOAM-Namespace field is included in all the
IOAM-Option-Types defined in this document, and MUST be included in IOAM-Option-Types defined in this document, and MUST be included in
all future IOAM-Option-Types. The Namespace-ID value is divided into all future IOAM-Option-Types. The Namespace-ID value is divided into
two sub-ranges: 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
skipping to change at page 10, line 16 skipping to change at page 10, line 8
are multiple IOAM-Option-Types present in the packet. Multiple are multiple IOAM-Option-Types present in the packet. Multiple
IOAM-Option-Types can be present in a packet in case of IOAM-Option-Types can be present in a packet in case of
overlapping IOAM-Domains or in case of a layered IOAM deployment. overlapping IOAM-Domains or in case of a layered IOAM deployment.
o whether IOAM-Option-Type(s) have to be removed from the packet, o whether IOAM-Option-Type(s) have to be removed from the packet,
e.g., at a domain edge or domain boundary. e.g., at a domain edge or domain boundary.
IOAM-Namespaces support several different uses: IOAM-Namespaces support several different uses:
o IOAM-Namespaces can be used by an operator to distinguish o IOAM-Namespaces can be used by an operator to distinguish
different operational domains. Devices at domain edges can filter different IOAM-domains. Devices at edges of an IOAM-domain can
on Namespace-IDs to provide for proper IOAM-Domain isolation. filter on Namespace-IDs to provide for proper IOAM-domain
isolation.
o IOAM-Namespaces provide additional context for IOAM-Data-Fields o IOAM-Namespaces provide additional context for IOAM-Data-Fields
and thus can be used to ensure that IOAM-Data-Fields are unique and thus can be used to ensure that IOAM-Data-Fields are unique
and are interpreted properly by management stations or network and are interpreted properly by management stations or network
controllers. For example, the node identifier field (node_id, see controllers. The node identifier field (node_id, see below) does
below) does not need to be unique in a deployment (e.g., if an not need to be unique in a deployment. This could be the case if
operator wishes to use different node identifiers for different an operator wishes to use different node identifiers for different
IOAM layers, even within the same device; or node identifiers IOAM layers, even within the same device or node identifiers might
might not be unique for other organizational reasons, such as not be unique for other organizational reasons, such as after a
after a merger of two formerly separated organizations), the merger of two formerly separated organizations. The Namespace-ID
Namespace-ID can be used as a context identifier, such that the can be used as a context identifier, such that the combination of
combination of node_id and Namespace-ID will always be unique. node_id and Namespace-ID will always be unique.
Similarly, IOAM-Namespaces can be used to define how certain IOAM-
o Similarly, IOAM-Namespaces can be used to define how certain IOAM-
Data-Fields are interpreted: IOAM offers three different timestamp Data-Fields are interpreted: IOAM offers three different timestamp
format options. The Namespace-ID can be used to determine the format options. The Namespace-ID can be used to determine the
timestamp format. IOAM-Data-Fields (e.g., buffer occupancy) which timestamp format. IOAM-Data-Fields (e.g., buffer occupancy) which
do not have a unit associated are to be interpreted within the do not have a unit associated are to be interpreted within the
context of a IOAM-Namespace. context of a IOAM-Namespace.
o IOAM-Namespaces can be used to identify different sets of devices o IOAM-Namespaces can be used to identify different sets of devices
(e.g., different types of devices) in a deployment: If an operator (e.g., different types of devices) in a deployment: If an operator
desires to insert different IOAM-Data-Fields based on the device, desires to insert different IOAM-Data-Fields based on the device,
the devices could be grouped into multiple IOAM-Namespaces. This the devices could be grouped into multiple IOAM-Namespaces. This
could be due to the fact that the IOAM feature set differs between 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 different sets of devices, or it could be for reasons of optimized
space usage in the packet header. It could also stem from space usage in the packet header. It could also stem from
hardware or operational limitations on the size of the trace data hardware or operational limitations on the size of the trace data
that can be added and processed, preventing collection of a full that can be added and processed, preventing collection of a full
trace for a flow. trace for a flow.
* Assigning different IOAM Namespace-IDs to different sets of o By assigning different IOAM Namespace-IDs to different sets of
nodes or network partitions and using the Namespace-ID as a nodes or network partitions and using a separate instance of an
selector at the IOAM encapsulating node, a full trace for a IOAM-Option-Type for each Namespace-ID, a full trace for a flow
flow could be collected and constructed via partial traces in could be collected and constructed via partial traces from each
different packets of the same flow. Example: An operator could IOAM-Option-Type in each of the packets in the flow. Example: An
choose to group the devices of a domain into two IOAM- operator could choose to group the devices of a domain into two
Namespaces, in a way that on average, only every second hop IOAM-Namespaces, in a way that each IOAM-Namespace is represented
would be recorded by any device. To retrieve a full view of by one of two IOAM-Option-Types in the packet. Each node would
the deployment, the captured IOAM-Data-Fields of the two IOAM- record data only for the IOAM-Namespace that it belongs to,
Namespaces need to be correlated. ignoring the other IOAM-Option-Type with a IOAM-Namespace to which
it doesn't belong. To retrieve a full view of the deployment, the
* Assigning different IOAM Namespace-IDs to different sets of captured IOAM-Data-Fields of the two IOAM-Namespaces need to be
nodes or network partitions and using a separate instance of an correlated.
IOAM-Option-Type for each Namespace-ID, a full trace for a flow
could be collected and constructed via partial traces from each
IOAM-Option-Type in each of the packets in the flow. Example:
An operator could choose to group the devices of a domain into
two IOAM-Namespaces, in a way that each IOAM-Namespace is
represented by one of two IOAM-Option-Types in the packet.
Each node would record data only for the IOAM-Namespace that it
belongs to, ignoring the other IOAM-Option-Type with a IOAM-
Namespace to which it doesn't belong. To retrieve a full view
of the deployment, the captured IOAM-Data-Fields of the two
IOAM-Namespaces need to be correlated.
5.4. IOAM Trace Option-Types 5.4. IOAM Trace Option-Types
"IOAM tracing data" is expected to be collected at every IOAM transit In a typical deployment, all nodes in an IOAM-Domain would
node that a packet traverses to ensure visibility into the entire participate in IOAM and thus be IOAM transit nodes, IOAM
path a packet takes within an IOAM-Domain. I.e., in a typical encapsulating or IOAM decapsulating nodes. If not all nodes within a
deployment, all nodes in an IOAM-Domain would participate in IOAM and domain support IOAM functionality as defined in this document, IOAM
thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating tracing information (i.e., node data, see below) can only be
nodes. If not all nodes within a domain support IOAM functionality collected on those nodes which support IOAM functionality as defined
as defined in this document, IOAM tracing information (i.e., node in this document. Nodes which do not support IOAM functionality as
data, see below) will only be collected on those nodes which support defined in this document will forward the packet without any changes
IOAM functionality as defined in this document. Nodes which do not to the IOAM-Data-Fields. The maximum number of hops and the minimum
support IOAM functionality as defined in this document will forward path MTU of the IOAM-domain is assumed to be known. An overflow
the packet without any changes to the IOAM-Data-Fields. The maximum indicator (O-bit) is defined as one of the ways to deal with
number of hops and the minimum path MTU of the IOAM domain is assumed situations where the PMTU was underestimated, i.e., where the number
to be known. An overflow indicator (O-bit) is defined as one of the of hops which are IOAM capable exceeds the available space in the
ways to deal with situations where the PMTU was underestimated, i.e., packet.
where the number of hops which are IOAM capable exceeds the available
space in the packet.
To optimize hardware and software implementations, IOAM tracing is To optimize hardware and software implementations, IOAM tracing is
defined as two separate options. A deployment can choose to defined as two separate options. A deployment can choose to
configure and support one or both of the following options. configure and support one or both of the following options.
Pre-allocated Trace-Option: This trace option is defined as a Pre-allocated Trace-Option: This trace option is defined as a
container of node data fields (see below) with pre-allocated space container of node data fields (see below) with pre-allocated space
for each node to populate its information. This option is useful for each node to populate its information. This option is useful
for implementations where it is efficient to allocate the space for implementations where it is efficient to allocate the space
once and index into the array to populate the data during transit once and index into the array to populate the data during transit
skipping to change at page 12, line 46 skipping to change at page 12, line 27
checksums in outer headers. checksums in outer headers.
IOAM encapsulating nodes and IOAM decapsulating nodes which support IOAM encapsulating nodes and IOAM decapsulating nodes which support
tracing MUST support both Trace-Option-Types. For IOAM transit nodes tracing MUST support both Trace-Option-Types. For IOAM transit nodes
it is sufficient to support one of the Trace-Option-Types. In the it is sufficient to support one of the Trace-Option-Types. In the
event that both options are utilized in a deployment at the same event that both options are utilized in a deployment at the same
time, the Incremental Trace-Option MUST be placed before the Pre- time, the Incremental Trace-Option MUST be placed before the Pre-
allocated Trace-Option. Deployments which mix devices with either allocated Trace-Option. Deployments which mix devices with either
the Incremental Trace-Option or the Pre-allocated Trace-Option could the Incremental Trace-Option or the Pre-allocated Trace-Option could
result in both Option-Types being present in a packet. Given that result in both Option-Types being present in a packet. Given that
the operator knows which equipment is deployed in a particular IOAM the operator knows which equipment is deployed in a particular IOAM-
domain, the operator will decide by means of configuration which domain, the operator will decide by means of configuration which
type(s) of trace options will be used for a particular domain. type(s) of trace options will be used for a particular domain.
Every node data entry holds information for a particular IOAM transit Every node data entry holds information for a particular IOAM transit
node that is traversed by a packet. The IOAM decapsulating node node that is traversed by a packet. The IOAM decapsulating node
removes the IOAM-Option-Type(s) and processes and/or exports the removes the IOAM-Option-Type(s) and processes and/or exports the
associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of associated data. Like all IOAM-Data-Fields, the IOAM-Data-Fields of
the IOAM-Trace-Option-Types are defined in the context of an IOAM- the IOAM-Trace-Option-Types are defined in the context of an IOAM-
Namespace. Namespace.
skipping to change at page 13, line 24 skipping to change at page 13, line 5
o Identification of the interface that a packet was received on, o Identification of the interface that a packet was received on,
i.e., ingress interface. i.e., ingress interface.
o Identification of the interface that a packet was sent out on, o Identification of the interface that a packet was sent out on,
i.e., egress interface. i.e., egress interface.
o Time of day when the packet was processed by the node as well as o Time of day when the packet was processed by the node as well as
the transit delay. Different definitions of processing time are the transit delay. Different definitions of processing time are
feasible and expected, though it is important that all devices of feasible and expected, though it is important that all devices of
an in-situ OAM domain follow the same definition. an IOAM-domain follow the same definition.
o Generic data: Format-free information where syntax and semantic of o Generic data: Format-free information where syntax and semantic of
the information is defined by the operator in a specific the information is defined by the operator in a specific
deployment. For a specific IOAM-Namespace, all IOAM nodes have to deployment. For a specific IOAM-Namespace, all IOAM nodes have to
interpret the generic data the same way. Examples for generic interpret the generic data the same way. Examples for generic
IOAM data include geo-location information (location of the node IOAM data include geo-location information (location of the node
at the time the packet was processed), buffer queue fill level or at the time the packet was processed), buffer queue fill level or
cache fill level at the time the packet was processed, or even a cache fill level at the time the packet was processed, or even a
battery charge level. battery charge level.
skipping to change at page 18, line 16 skipping to change at page 18, line 9
All the IOAM-Data-Fields MUST be 4-octet aligned. If a node which is All the IOAM-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.
Some IOAM-Data-Fields defined below, such as interface identifiers or Some IOAM-Data-Fields defined below, such as interface identifiers or
IOAM-Namespace specific data, are defined in both "short format" as IOAM-Namespace specific data, are defined in both "short format" as
well as "wide format". "Short format" refers to an IOAM-Data-Field well as "wide format". The use of "short format" or "wide format" is
which comprises 4 octets. "Wide format" refers to an IOAM-Data-Field not mutually exclusive. A deployment could choose to leverage both.
which comprises 8 octets. The use of "short format" or "wide format" For example, ingress_if_id_(short format) could be an identifier for
is not mutually exclusive. A deployment could choose to leverage the physical interface, whereas ingress_if_id_(wide format) could be
both. For example, ingress_if_id_(short format) could be an an identifier for a logical sub-interface of that physical interface.
identifier for the physical interface, whereas ingress_if_id_(wide
format) could be an identifier for a logical sub-interface of that
physical interface.
Data fields and associated data types for each of the IOAM-Data- Data fields and associated data types for each of the IOAM-Data-
Fields are specified in the following sections. The definition of Fields are specified in the following sections. The definition of
IOAM-Data-Fields focuses on the syntax of the data-fields and avoids IOAM-Data-Fields focuses on the syntax of the data-fields and avoids
specifying the semantics where feasible. This is why no units are specifying the semantics where feasible. This is why no units are
defined for data-fields like e.g., "buffer occupancy" or "queue defined for data-fields like e.g., "buffer occupancy" or "queue
depth". With this approach, nodes can supply the information in depth". With this approach, nodes can supply the information in
their native format and are not required to perform unit or format their native format and are not required to perform unit or format
conversions. Systems that further process IOAM information, like conversions. Systems that further process IOAM information, like
e.g., a network management system are assumed to also handle unit e.g., a network management system are assumed to also handle unit
skipping to change at page 19, line 15 skipping to change at page 19, line 6
semantics of the Hop_Lim field depend on the lower layer protocol semantics of the Hop_Lim field depend on the lower layer protocol
that IOAM is encapsulated into, and therefore its specific that IOAM is encapsulated into, and therefore its specific
semantics are outside the scope of this memo. The value of this semantics are outside the scope of this memo. The value of this
field MUST be set to 0xff when the lower level does not have a field MUST be set to 0xff when the lower level does not have a
TTL/Hop limit equivalent field. TTL/Hop limit equivalent field.
node_id: 3-octet unsigned integer. Node identifier field to node_id: 3-octet unsigned integer. Node identifier field to
uniquely identify a node within the IOAM-Namespace and associated uniquely identify a node within the IOAM-Namespace and associated
IOAM-Domain. The procedure to allocate, manage and map the IOAM-Domain. The procedure to allocate, manage and map the
node_ids is beyond the scope of this document. See node_ids is beyond the scope of this document. See
[I-D.brockners-opsawg-ioam-deployment] for a discussion of [I-D.ietf-ippm-ioam-deployment] for a discussion of deployment
deployment related aspects of the node_id. related aspects of the node_id.
5.4.2.2. ingress_if_id and egress_if_id 5.4.2.2. ingress_if_id and egress_if_id
The "ingress_if_id and egress_if_id" field is a 4-octet field that is The "ingress_if_id and egress_if_id" field is a 4-octet field that is
defined as follows: defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 40 skipping to change at page 26, line 40
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. IOAM Proof of Transit Option-Type 5.5. IOAM Proof of Transit Option-Type
IOAM Proof of Transit Option-Type is used to support path or service IOAM Proof of Transit Option-Type is used to support path or service
function chain [RFC7665] verification use cases. For further function chain [RFC7665] verification use cases, i.e., prove that
information on Proof-of-transit, please refer to traffic transited a defined path. While details on how the IOAM data
[I-D.ietf-sfc-proof-of-transit]. While details on how the IOAM data
for the Proof-of-transit option is processed at IOAM encapsulating, for the Proof-of-transit option is processed at IOAM encapsulating,
decapsulating and transit nodes are outside the scope of the decapsulating and transit nodes are outside the scope of the
document, all of these approaches share the need to uniquely identify document, proof of transit approaches share the need to uniquely
a packet as well as iteratively operate on a set of information that identify a packet as well as iteratively operate on a set of
is handed from node to node. Correspondingly, two pieces of information that is handed from node to node. Correspondingly, two
information are added as IOAM-Data-Fields to the packet: pieces of information are added as IOAM-Data-Fields to the packet:
o PktID: Unique identifier for the packet. o PktID: Unique identifier for the packet.
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.
The IOAM Proof-of-Transit Option-Type consist of a fixed size "IOAM The IOAM Proof-of-Transit Option-Type consist of a fixed size "IOAM
proof of transit option header" and "IOAM proof of transit option proof of transit option header" and "IOAM proof of transit option
data fields": data fields":
skipping to change at page 27, line 41 skipping to change at page 27, line 41
ID" (see Section 5.3) and MUST be known to all the nodes ID" (see Section 5.3) and MUST be known to all the nodes
implementing IOAM. For any other Namespace-ID value that does not implementing IOAM. For any other Namespace-ID value that does not
match any Namespace-ID the node is configured to operate on, the match any Namespace-ID the node is configured to operate on, the
node MUST NOT change the contents 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 to carry data associated to POT 0: POT data is a 16 Octet field to carry data associated to POT
procedures. [I-D.ietf-sfc-proof-of-transit] describes an procedures.
implementation of POT and provides details on the data carried
in POT data.
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, add to, or remove the understand, the node MUST NOT change, add to, or remove the
contents of the OAM-Data-Fields. contents of the OAM-Data-Fields.
IOAM POT flags: 8-bit. Following flags are defined: IOAM POT flags: 8-bit. This document does not define any flags.
Bits 0-7 These bits are available for assignment, see Section 8.5.
Bit 0 "Profile-to-use" (P-bit) (most significant bit). For IOAM Bits which have not been assigned MUST be set to zero upon
POT types that use a maximum of two profiles to drive transmission and ignored upon receipt.
computation, indicates which POT-profile (see
[I-D.ietf-sfc-proof-of-transit] for details) is used. The two
profiles are numbered 0, 1. This bit conveys whether profile 0
or profile 1 is used to compute the Cumulative.
Bit 1-7 Undefined: These bits are available for assignment, see
Section 8.5. Bits which have not been assigned 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.
5.5.1. IOAM Proof of Transit Type 0 5.5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID |IOAM POT Type=0|P|R R R R R R R| | Namespace-ID |IOAM POT Type=0|R R R R R R R R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| PktID | | | PktID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| PktID (contd) | O | PktID (contd) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | | | Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd) | | | Cumulative (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Namespace-ID: 16-bit identifier of an IOAM-Namespace (see Namespace-ID: 16-bit identifier of an IOAM-Namespace (see
Section 5.5 above). Section 5.5 above).
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 (see Section 5.5 above). specifies the POT data that is included (see Section 5.5 above).
For this case here, IOAM POT Type is set to the value 0. For this case here, IOAM POT Type is set to the value 0.
Bit 0: 1-bit. "Profile-to-use" (P-bit) (most significant bit), see Bit 0-7: Undefined (see Section 5.5 above).
Section 5.5 above.
Bit 1-7: Undefined (see Section 5.5 above).
PktID: 64-bit packet identifier. PktID: 64-bit packet identifier.
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 PktID field and configured parameters. processing per packet PktID field and configured parameters.
Note: Larger or smaller sizes of "PktID" and "Cumulative" data are Note: Larger or smaller sizes of "PktID" 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 encapsulation protocols used. Future of space constraints in the encapsulation protocols used. Future
documents could introduce different sizes of data for "proof of documents could introduce different sizes of data for "proof of
skipping to change at page 30, line 27 skipping to change at page 30, line 13
added to a specific "packet group" which is used to added to a specific "packet group" which is used to
detect packet loss, packet reordering, or packet detect packet loss, packet reordering, or packet
duplication within that group. The "packet group" is duplication within that group. The "packet group" is
deployment dependent and defined at the IOAM deployment dependent and defined at the IOAM
encapsulating node, e.g., by n-tuple based classification encapsulating node, e.g., by n-tuple based classification
of packets. When this bit is set, "Bit 0" (for 64-bit of packets. When this bit is set, "Bit 0" (for 64-bit
sequence number, see above) MUST be zero. sequence number, see above) MUST be zero.
Bit 2 When set indicates presence of timestamp seconds, Bit 2 When set indicates presence of timestamp seconds,
representing the time at which the packet entered the representing the time at which the packet entered the
IOAM domain. Within the IOAM encapsulating node, the IOAM-domain. Within the IOAM encapsulating node, the
time that the timestamp is retrieved can depend on the time that the timestamp is retrieved can depend on the
implementation. Some possibilities are: 1) the time at implementation. Some possibilities are: 1) the time at
which the packet was received by the node, 2) the time at which the packet was received by the node, 2) the time at
which the packet was transmitted by the node, 3) when a which the packet was transmitted by the node, 3) when a
tunnel encapsulation is used, the point at which the tunnel encapsulation is used, the point at which the
packet is encapsulated into the tunnel. Each packet is encapsulated into the tunnel. Each
implementation has to document when the E2E timestamp implementation has to document when the E2E timestamp
that is going to be put in the packet is retrieved. This that is going to be put in the packet is retrieved. This
4-octet field has three possible formats; based on either 4-octet field has three possible formats; based on either
PTP (see e.g., [RFC8877]), NTP [RFC5905], or POSIX PTP (see e.g., [RFC8877]), NTP [RFC5905], or POSIX
skipping to change at page 30, line 51 skipping to change at page 30, line 37
timestamp format that is specified in Section 6. If a timestamp format that is specified in Section 6. If a
node is not capable of populating this field, it assigns node is not capable of populating this field, it assigns
the value 0xFFFFFFFF. Note that this is a legitimate the value 0xFFFFFFFF. Note that this is a legitimate
value that is valid for 1 second in approximately 136 value that is valid for 1 second in approximately 136
years; the analyzer has to correlate several packets or years; the analyzer has to correlate several packets or
compare the timestamp value to its own time-of-day in compare the timestamp value to its own time-of-day in
order to detect the error indication. order to detect the error indication.
Bit 3 When set indicates presence of timestamp fraction, Bit 3 When set indicates presence of timestamp fraction,
representing the time at which the packet entered the representing the time at which the packet entered the
IOAM domain. This 4-octet field has three possible IOAM-domain. This 4-octet field has three possible
formats; based on either PTP (see e.g., [RFC8877]), NTP formats; based on either PTP (see e.g., [RFC8877]), NTP
[RFC5905], or POSIX [POSIX]. The three timestamp formats [RFC5905], or POSIX [POSIX]. The three timestamp formats
are specified in Section 6. In all three cases, the are specified in Section 6. In all three cases, the
Timestamp fraction field contains the 32 least Timestamp fraction field contains the 32 least
significant bits of the timestamp format that is significant bits of the timestamp format that is
specified in Section 6. If a node is not capable of specified in Section 6. If a node is not capable of
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 has to correlate If the NTP format is used the analyzer has to correlate
skipping to change at page 35, line 29 skipping to change at page 35, line 16
7. IOAM Data Export 7. IOAM Data Export
IOAM nodes collect information for packets traversing a domain that IOAM nodes collect information for packets traversing a domain that
supports IOAM. IOAM decapsulating nodes as well as IOAM transit supports IOAM. IOAM decapsulating nodes as well as IOAM transit
nodes can choose to retrieve IOAM information from the packet, nodes can choose to retrieve IOAM information from the packet,
process the information further and export the information using process the information further and export the information using
e.g., IPFIX. The mechanisms and associated data formats for e.g., IPFIX. The mechanisms and associated data formats for
exporting IOAM data is outside the scope of this document. exporting IOAM data is outside the scope of this document.
Raw data export of IOAM data using IPFIX is discussed in A way to perform raw data export of IOAM data using IPFIX is
[I-D.spiegel-ippm-ioam-rawexport]. discussed in [I-D.spiegel-ippm-ioam-rawexport].
8. IANA Considerations 8. IANA Considerations
This document requests the following IANA Actions. This document requests the following IANA Actions.
IANA is requested to define a registry group named "In-Situ OAM IANA is requested to define a registry group named "In-Situ OAM
(IOAM) Protocol Parameters". (IOAM) Protocol Parameters".
This group will include the following registries: This group will include the following registries:
skipping to change at page 36, line 15 skipping to change at page 36, line 4
The subsequent sub-sections detail the registries herein contained. The subsequent sub-sections detail the registries herein contained.
8.1. IOAM Option-Type Registry 8.1. IOAM Option-Type Registry
This registry defines 128 code points for the IOAM Option-Type field This registry defines 128 code points for the IOAM Option-Type field
for identifying IOAM Option-Types as explained in Section 5. The for identifying IOAM Option-Types as explained in Section 5. The
following code points are defined in this draft: following code points are defined in this draft:
0 IOAM Pre-allocated Trace Option-Type 0 IOAM Pre-allocated Trace Option-Type
1 IOAM Incremental Trace Option-Type 1 IOAM Incremental Trace Option-Type
2 IOAM POT Option-Type 2 IOAM POT Option-Type
3 IOAM E2E Option-Type 3 IOAM E2E Option-Type
4 - 127 are available for assignment via "IETF Review" process as per 4 - 127 are available for assignment via "IETF Review" process as per
[RFC8126]. [RFC8126].
New registration requests MUST use the following template: New registration requests MUST use the following template:
Name: Name of the newly registered Option-Type. Name: Name of the newly registered Option-Type.
Code point: Desired value of the requested code point. Code point: Desired value of the requested code point.
Description: Brief description of the newly registered Option-Type. Description: Brief description of the newly registered Option-Type.
Reference: Reference to the document that defines the new Option- Reference: Reference to the document that defines the new Option-
Type. Type.
The evaluation of a new registration request MUST also include
checking whether the new IOAM Option-Type includes an IOAM-Namespace
field and that the IOAM-Namespace field is the first field in the
newly defined header of the new Option-Type.
8.2. IOAM Trace-Type Registry 8.2. IOAM Trace-Type Registry
This registry defines code point for each bit in the 24-bit IOAM- This registry defines code point for each bit in the 24-bit IOAM-
Trace-Type field for Pre-allocated Trace-Option-Type and Incremental Trace-Type field for Pre-allocated Trace-Option-Type and Incremental
Trace-Option-Type defined in Section 5.4. The meaning of Bits 0 - 11 Trace-Option-Type defined in Section 5.4. The meaning of Bits 0 - 11
is defined in this document in Paragraph 5 of Section 5.4.1: is defined in this document in Paragraph 5 of Section 5.4.1:
Bit 0 hop_Lim and node_id in short format Bit 0 hop_Lim and node_id in short format
Bit 1 ingress_if_id and egress_if_id in short format Bit 1 ingress_if_id and egress_if_id in short format
skipping to change at page 38, line 37 skipping to change at page 38, line 29
Code point: Desired value of the requested code point. Code point: Desired value of the requested code point.
Description: Brief description of the newly registered POT-Type. Description: Brief description of the newly registered POT-Type.
Reference: Reference to the document that defines the new POT-Type. Reference: Reference to the document that defines the new POT-Type.
8.5. IOAM POT-Flags Registry 8.5. IOAM POT-Flags Registry
This registry defines code points 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-Type defined in Section 5.5. The meaning of Bit 0 IOAM POT Option-Type defined in Section 5.5.
for IOAM POT flags is defined in this document in Section 5.5:
Bit 0 "Profile-to-use" (P-bit)
The meaning for Bits 1 - 7 are available for assignment via "IETF The meaning for Bits 0 - 7 are available for assignment via "IETF
Review" process as per [RFC8126]. Review" process as per [RFC8126].
New registration requests MUST use the following template: New registration requests MUST use the following template:
Bit: Desired bit to be allocated in the 8 bit flags field of the Bit: Desired bit to be allocated in the 8 bit flags field of the
IOAM POT Option-Type. IOAM POT Option-Type.
Description: Brief description of the newly registered bit. Description: Brief description of the newly registered bit.
Reference: Reference to the document that defines the new bit. Reference: Reference to the document that defines the new bit.
skipping to change at page 40, line 7 skipping to change at page 39, line 45
requests back to the requestor. requests back to the requestor.
o Check whether the request is neither a duplicate of nor o Check whether the request is neither a duplicate of nor
conflicting with either an already existing allocation or a conflicting with either an already existing allocation or a
pending allocation. In case of duplicates or conflicts, the pending allocation. In case of duplicates or conflicts, the
expert will ask the requestor to update the allocation request expert will ask the requestor to update the allocation request
accordingly. accordingly.
o Solicit feedback from relevant working groups and communities to o Solicit feedback from relevant working groups and communities to
ensure that the new allocation request has been properly reviewed ensure that the new allocation request has been properly reviewed
and that rough consensus on the request exists. At a minumum, the and that rough consensus on the request exists. At a minimum, the
expert will solicit feedback from the IPPM working group in the expert will solicit feedback from the IPPM working group in the
IETF by posting the request to the ippm@ietf.org mailing list. IETF by posting the request to the ippm@ietf.org mailing list.
The expert will allow for a 3-week review period on the mailing The expert will allow for a 3-week review period on the mailing
lists. If the feedback received from the relevant working groups lists. If the feedback received from the relevant working groups
and communities within the review period indicates rough consensus and communities within the review period indicates rough consensus
on the request, the expert will approve the request and ask IANA on the request, the expert will approve the request and ask IANA
for allocating the new Namespace-ID. In case the expert senses a for allocating the new Namespace-ID. In case the expert senses a
lack of consensus from the feedback received, the expert will ask lack of consensus from the feedback received, the expert will ask
the requestor to engage with the corresponding working groups and the requestor to engage with the corresponding working groups and
communities to further review and refine the request. communities to further review and refine the request.
skipping to change at page 41, line 7 skipping to change at page 40, line 46
changed to "permanent". changed to "permanent".
9. Management and Deployment Considerations 9. Management and Deployment Considerations
This document defines the structure and use of IOAM data fields. This document defines the structure and use of IOAM data fields.
This document does not define the encapsulation of IOAM data fields This document does not define the encapsulation of IOAM data fields
into different protocols. Management and deployment aspects for IOAM into different protocols. Management and deployment aspects for IOAM
have to be considered within the context of the protocol IOAM data have to be considered within the context of the protocol IOAM data
fields are encapsulated into and as such, are out of scope for this fields are encapsulated into and as such, are out of scope for this
document. For a discussion of IOAM deployment, please also refer to document. For a discussion of IOAM deployment, please also refer to
[I-D.brockners-opsawg-ioam-deployment], which outlines a framework [I-D.ietf-ippm-ioam-deployment], which outlines a framework for IOAM
for IOAM deployment and provides best current practices. deployment and provides best current practices.
10. Security Considerations 10. 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. In particular, these threats are applicable by compromising ones. In particular, these threats are applicable by compromising
the integrity of IOAM data, either by maliciously modifying IOAM the integrity of IOAM data, either by maliciously modifying IOAM
options in transit, or by injecting packets with maliciously options in transit, or by injecting packets with maliciously
generated IOAM options. All nodes in the path of a IOAM carrying generated IOAM options. All nodes in the path of a IOAM carrying
packet can perform such an attack. packet can perform such an attack.
The Proof of Transit Option-Type (see Section 5.5) is used for The Proof of Transit Option-Type (see Section 5.5) is used for
verifying the path of data packets. The security considerations of verifying the path of data packets, i.e., proving that packets
POT are further discussed in [I-D.ietf-sfc-proof-of-transit]. transited through a defined set of nodes.
In case an attacker gains access to several nodes in a network and In case an attacker gains access to several nodes in a network and
would be able to change the system software of these nodes, IOAM data would be able to change the system software of these nodes, IOAM data
fields could be misused and repurposed for a use different from what fields could be misused and repurposed for a use different from what
is specified in this document. One type of misuse is the is specified in this document. One type of misuse is the
implementation of a covert channel between network nodes. implementation of a covert channel between network nodes.
From a confidentiality perspective, although IOAM options are not From a confidentiality perspective, although IOAM options are not
expected to contain user data, they can be used for network expected to contain user data, they can be used for network
reconnaissance, allowing attackers to collect information about reconnaissance, allowing attackers to collect information about
network paths, performance, queue states, buffer occupancy and other network paths, performance, queue states, buffer occupancy and other
information. Moreover, if IOAM data leaks from the IOAM domain it information. Moreover, if IOAM data leaks from the IOAM-domain it
could enable reconnaissance beyond the scope of the IOAM domain. could enable reconnaissance beyond the scope of the IOAM-domain. One
possible application of such reconnaissance is to gauge the
effectiveness of an ongoing attack, e.g., if buffers and queues are
overflowing.
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 entities that receive, of network devices that take part in IOAM or entities that receive,
collect or analyze the IOAM data. Another example is a packet length collect or analyze the IOAM data. Another example is a packet length
attack, in which an attacker pushes headers associated with IOAM attack, in which an attacker pushes headers associated with IOAM
Option-Types into data packets, causing these packets to be increased Option-Types into data packets, causing these packets to be increased
beyond the MTU size, resulting in fragmentation or in packet drops. beyond the MTU size, resulting in fragmentation or in packet drops.
In case POT is used, an attacker could corrupt the POT data fields in In case POT is used, an attacker could corrupt the POT data fields in
skipping to change at page 42, line 4 skipping to change at page 41, line 50
collect or analyze the IOAM data. Another example is a packet length collect or analyze the IOAM data. Another example is a packet length
attack, in which an attacker pushes headers associated with IOAM attack, in which an attacker pushes headers associated with IOAM
Option-Types into data packets, causing these packets to be increased Option-Types into data packets, causing these packets to be increased
beyond the MTU size, resulting in fragmentation or in packet drops. beyond the MTU size, resulting in fragmentation or in packet drops.
In case POT is used, an attacker could corrupt the POT data fields in In case POT is used, an attacker could corrupt the POT data fields in
the packet, resulting in a verification failure of the POT data, even the packet, resulting in a verification failure of the POT data, even
if the packet followed the correct path. if the packet followed the correct path.
Since IOAM options can include timestamps, if network devices use Since IOAM options can include timestamps, if network devices use
synchronization protocols then any attack on the time protocol synchronization protocols then any attack on the time protocol
[RFC7384] can compromise the integrity of the timestamp-related data [RFC7384] can compromise the integrity of the timestamp-related data
fields. fields.
At the management plane, attacks can be set up by misconfiguring or At the management plane, attacks can be set up by misconfiguring or
by maliciously configuring IOAM-enabled nodes in a way that enables by maliciously configuring IOAM-enabled nodes in a way that enables
other attacks. IOAM configuration should only managed by authorized other attacks. IOAM configuration should only managed by authorized
processes or users. processes or users.
Solutions to ensure the integrity of IOAM data fields are outside the IETF protocols require features to ensure their security. While IOAM
scope of this document. [I-D.brockners-ippm-ioam-data-integrity] data fields don't represent a protocol by themselves, the IOAM data
discusses several methods to ensure the integrity of IOAM data fields fields add to the protocol that the IOAM data fields are encapsulated
for those deployments that have a need to protect the integrity of into. Any specification that defines how IOAM data fields carried in
IOAM data fields. an encapsulating protocol MUST provide for a mechanism for
cryptographic integrity protection of the IOAM data fields.
Cryptographic integrity protection could be either achieved through a
mechanism of the encapsulating protocol or it could incorporate the
mechanisms specified in [I-D.ietf-ippm-ioam-data-integrity].
The current document does not define a specific IOAM encapsulation. The current document does not define a specific IOAM encapsulation.
It has to be noted that some IOAM encapsulation types can introduce It has to be noted that some IOAM encapsulation types can introduce
specific security considerations. A specification that defines an specific security considerations. A specification that defines an
IOAM encapsulation is expected to address the respective IOAM encapsulation is expected to address the respective
encapsulation-specific security considerations. encapsulation-specific security considerations.
Notably, IOAM is expected to be deployed in limited domains, thus Notably, IOAM is expected to be deployed in limited domains, thus
confining the potential attack vectors to within the limited domain. confining the potential attack vectors to within the limited domain.
A limited administrative domain provides the operator with the means A limited administrative domain provides the operator with the means
to select, monitor, and control the access of all the network to select, monitor, and control the access of all the network
devices, making these devices trusted by the operator. Indeed, in devices, making these devices trusted by the operator. Indeed, in
order to limit the scope of threats mentioned above to within the order to limit the scope of threats mentioned above to within the
current limited domain the network operator is expected to enforce current limited domain the network operator is expected to enforce
policies that prevent IOAM traffic from leaking outside of the IOAM policies that prevent IOAM traffic from leaking outside of the IOAM
domain, and prevent IOAM data from outside the domain to be processed domain, and prevent IOAM data from outside the domain to be processed
and used within the domain. and used within the domain.
This document does not define the data contents of custom fields like
"Opaque State Snapshot" and "namespace specific data" IOAM data
fields. These custom data fields will have security considerations
corresponding to their defined data contents that need to be
described where those formats are defined.
IOAM deployments which leverage both IOAM Trace Option-Types, i.e.,
the Pre-allocated Trace Option-Type and Incremental Trace Option-Type
can suffer from incomplete visibility if the information gathered via
the two Trace Option-Types is not correlated and aggregated
appropriately. If IOAM transit nodes leverage the IOAM data fields
in the packet for further actions or insights, then IOAM transit
nodes which only support one IOAM Trace Option-Type in an IOAM
deployment which leverages both Trace Option-Types, have limited
visibility and thus can draw inappropriate conclusions or take wrong
actions.
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. Specifically, in an IOAM deployment that is not confined document. Specifically, in an IOAM deployment that is not confined
to a single LAN, but spans multiple inter-connected sites (for to a single LAN, but spans multiple inter-connected sites (for
example, using an overlay network), the inter-site links can be example, using an overlay network), the inter-site links can be
secured (e.g., by IPsec) in order to avoid external threats. secured (e.g., by IPsec) in order to avoid external threats.
IOAM deployment considerations, including approaches to mitigate the IOAM deployment considerations, including approaches to mitigate the
above discussed threads and potential attacks are outside the scope above discussed threads and potential attacks are outside the scope
of this document. IOAM deployment considerations are discussed in of this document. IOAM deployment considerations are discussed in
[I-D.brockners-opsawg-ioam-deployment]. [I-D.ietf-ippm-ioam-deployment].
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, Zhenbin (Robin) and Greg Mirsky Yourtchenko, Aviv Kfir, Tianran Zhou, Zhenbin (Robin) and Greg Mirsky
for the comments and advice. for the comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
skipping to change at page 44, line 11 skipping to change at page 44, line 26
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.brockners-ippm-ioam-data-integrity] [I-D.ietf-ippm-ioam-data-integrity]
Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of Brockners, F., Bhandari, S., and T. Mizrahi, "Integrity of
In-situ OAM Data Fields", draft-brockners-ippm-ioam-data- In-situ OAM Data Fields", draft-ietf-ippm-ioam-data-
integrity-03 (work in progress), July 2021. integrity-00 (work in progress), October 2021.
[I-D.brockners-opsawg-ioam-deployment] [I-D.ietf-ippm-ioam-deployment]
Brockners, F., Bhandari, S., Bernier, D., and T. Mizrahi, Brockners, F., Bhandari, S., Bernier, D., and T. Mizrahi,
"In-situ OAM Deployment", draft-brockners-opsawg-ioam- "In-situ OAM Deployment", draft-ietf-ippm-ioam-
deployment-03 (work in progress), June 2021. deployment-00 (work in progress), October 2021.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
(Editor), F. M., (editor), L. K., and U. E. (editor), (Editor), F. M., (editor), L. K., and U. E. (editor),
"Generic Protocol Extension for VXLAN (VXLAN-GPE)", draft- "Generic Protocol Extension for VXLAN (VXLAN-GPE)", draft-
ietf-nvo3-vxlan-gpe-12 (work in progress), September 2021. ietf-nvo3-vxlan-gpe-12 (work in progress), September 2021.
[I-D.ietf-sfc-proof-of-transit]
Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S.
Youell, "Proof of Transit", draft-ietf-sfc-proof-of-
transit-08 (work in progress), November 2020.
[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-05 (work in progress), draft-spiegel-ippm-ioam-rawexport-05 (work in progress),
July 2021. July 2021.
 End of changes. 53 change blocks. 
184 lines changed or deleted 171 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/