draft-ietf-ippm-ioam-data-01.txt   draft-ietf-ippm-ioam-data-02.txt 
ippm F. Brockners ippm F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Standards Track C. Pignataro Intended status: Standards Track C. Pignataro
Expires: May 3, 2018 Cisco Expires: September 6, 2018 Cisco
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Leddy J. Leddy
Comcast Comcast
S. Youell S. Youell
JPMC JPMC
T. Mizrahi T. Mizrahi
Marvell Marvell
D. Mozes D. Mozes
Mellanox Technologies Ltd.
P. Lapukhov P. Lapukhov
Facebook Facebook
R. Chang R. Chang
Barefoot Networks Barefoot Networks
D. Bernier D. Bernier
Bell Canada Bell Canada
October 30, 2017 J. Lemon
Broadcom
March 5, 2018
Data Fields for In-situ OAM Data Fields for In-situ OAM
draft-ietf-ippm-ioam-data-01 draft-ietf-ippm-ioam-data-02
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document traverses a path between two points in the network. This document
discusses the data fields and associated data types for in-situ OAM. discusses the data fields and associated data types for in-situ OAM.
In-situ OAM data fields can be embedded into a variety of transports In-situ OAM data fields can be embedded into a variety of transports
such as NSH, Segment Routing, Geneve, native IPv6 (via extension such as NSH, Segment Routing, Geneve, native IPv6 (via extension
header), or IPv4. In-situ OAM can be used to complement OAM header), or IPv4. In-situ OAM can be used to complement OAM
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4 3. Scope, Applicability, and Assumptions . . . . . . . . . . . . 4
4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5 4. IOAM Data Types and Formats . . . . . . . . . . . . . . . . . 5
4.1. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 6 4.1. IOAM Tracing Options . . . . . . . . . . . . . . . . . . 6
4.1.1. Pre-allocated Trace Option . . . . . . . . . . . . . 8 4.1.1. Pre-allocated and Incremental Trace Options . . . . . 8
4.1.2. Incremental Trace Option . . . . . . . . . . . . . . 11 4.1.2. IOAM node data fields and associated formats . . . . 12
4.1.3. IOAM node data fields and associated formats . . . . 14 4.1.3. Examples of IOAM node data . . . . . . . . . . . . . 17
4.1.4. Examples of IOAM node data . . . . . . . . . . . . . 19 4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 19
4.2. IOAM Proof of Transit Option . . . . . . . . . . . . . . 21 4.2.1. IOAM Proof of Transit Type 0 . . . . . . . . . . . . 20
4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 23 4.3. IOAM Edge-to-Edge Option . . . . . . . . . . . . . . . . 22
5. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 23 5. Timestamp Formats . . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5.1. PTP Truncated Timestamp Format . . . . . . . . . . . . . 23
6.1. Creation of a new In-Situ OAM Protocol Parameters 5.2. NTP 64-bit Timestamp Format . . . . . . . . . . . . . . . 25
Registry (IOAM) Protocol 5.3. POSIX-based Timestamp Format . . . . . . . . . . . . . . 26
Parameters IANA registry . . . . . . . . . . . . . . . . 24 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 27
6.2. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.3. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 24 7.1. Creation of a new In-Situ OAM Protocol Parameters
6.4. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 25 Registry (IOAM) Protocol Parameters IANA registry . . . . 28
6.5. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 25 7.2. IOAM Type Registry . . . . . . . . . . . . . . . . . . . 28
7. Manageability Considerations . . . . . . . . . . . . . . . . 25 7.3. IOAM Trace Type Registry . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.4. IOAM Trace Flags Registry . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 7.5. IOAM POT Type Registry . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6. IOAM POT Flags Registry . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 7.7. IOAM E2E Type Registry . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 26 8. Manageability Considerations . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document defines data fields for "in-situ" Operations, This document defines data fields for "in-situ" Operations,
Administration, and Maintenance (IOAM). In-situ OAM records OAM Administration, and Maintenance (IOAM). In-situ OAM records OAM
information within the packet while the packet traverses a particular information within the packet while the packet traverses a particular
network domain. The term "in-situ" refers to the fact that the OAM network domain. The term "in-situ" refers to the fact that the OAM
data is added to the data packets rather than is being sent within data is added to the data packets rather than is being sent within
packets specifically dedicated to OAM. A discussion of the packets specifically dedicated to OAM. IOAM is to complement
motivation and requirements for in-situ OAM can be found in
[I-D.brockners-inband-oam-requirements]. IOAM is to complement
mechanisms such as Ping or Traceroute, or more recent active probing mechanisms such as Ping or Traceroute, or more recent active probing
mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms
of "active" or "passive" OAM, "in-situ" OAM can be considered a of "active" or "passive" OAM, "in-situ" OAM can be considered a
hybrid OAM type. While no extra packets are sent, IOAM adds hybrid OAM type. While no extra packets are sent, IOAM adds
information to the packets therefore cannot be considered passive. information to the packets therefore cannot be considered passive.
In terms of the classification given in [RFC7799] IOAM could be In terms of the classification given in [RFC7799] IOAM could be
portrayed as Hybrid Type 1. "In-situ" mechanisms do not require portrayed as Hybrid Type 1. "In-situ" mechanisms do not require
extra packets to be sent and hence don't change the packet traffic extra packets to be sent and hence don't change the packet traffic
mix within the network. IOAM mechanisms can be leveraged where mix within the network. IOAM mechanisms can be leveraged where
mechanisms using e.g. ICMP do not apply or do not offer the desired mechanisms using e.g. ICMP do not apply or do not offer the desired
skipping to change at page 5, line 41 skipping to change at page 5, line 43
IOAM information retrieved from the packet back to the source address IOAM information retrieved from the packet back to the source address
of the packet or to the encapsulating node. of the packet or to the encapsulating node.
IOAM implementation: The IOAM data-field definitions take the IOAM implementation: The IOAM data-field definitions take the
specifics of devices with hardware data-plane and software data-plane specifics of devices with hardware data-plane and software data-plane
into account. into account.
4. IOAM Data Types and Formats 4. IOAM Data Types and Formats
This section defines IOAM data types and data fields and associated This section defines IOAM data types and data fields and associated
data types required for IOAM. The different uses of IOAM require the data types required for IOAM.
definition of different types of data. The IOAM data fields for the
data being carried corresponds to the three main categories of IOAM
data defined in [I-D.brockners-inband-oam-requirements], which are:
edge-to-edge, per node, and for selected nodes only.
Transport options for IOAM data are outside the scope of this memo, To accommodate the different uses of IOAM, IOAM data fields fall into
and are discussed in [I-D.brockners-inband-oam-transport]. IOAM data different categories, e.g. edge-to-edge, per node tracing, or for
fields are fixed length data fields. A bit field determines the set proof of transit. In IOAM these categories are referred to as IOAM-
of OAM data fields embedded in a packet. Depending on the type of Types. A common registry is maintained for IOAM-Types, see
the encapsulation, a counter field indicates how many data fields are Section 7.2 for details. Corresponding to these IOAM-Types,
included in a particular packet. different IOAM data fields are defined. IOAM data fields can be
encapsulated into a variety of protocols, such as NSH, Geneve, IPv6,
etc. The definition of how IOAM data fields are encapsulated into
other protocols is outside the scope of this document.
IOAM is expected to be deployed in a specific domain rather than on IOAM is expected to be deployed in a specific domain rather than on
the overall Internet. The part of the network which employs IOAM is the overall Internet. The part of the network which employs IOAM is
referred to as the "IOAM-domain". IOAM data is added to a packet referred to as the "IOAM-domain". IOAM data is added to a packet
upon entering the IOAM-domain and is removed from the packet when upon entering the IOAM-domain and is removed from the packet when
exiting the domain. Within the IOAM-domain, the IOAM data may be exiting the domain. Within the IOAM-domain, the IOAM data may be
updated by network nodes that the packet traverses. The device which updated by network nodes that the packet traverses. The device which
adds an IOAM data container to the packet to capture IOAM data is adds an IOAM data container to the packet to capture IOAM data is
called the "IOAM encapsulating node", whereas the device which called the "IOAM encapsulating node", whereas the device which
removes the IOAM data container is referred to as the "IOAM removes the IOAM data container is referred to as the "IOAM
skipping to change at page 7, line 17 skipping to change at page 7, line 21
and sets the fields in the option header. The in situ OAM and sets the fields in the option header. The in situ OAM
encapsulating node allocates an array which is used to store encapsulating node allocates an array which is used to store
operational data retrieved from every node while the packet operational data retrieved from every node while the packet
traverses the domain. IOAM transit nodes update the content of traverses the domain. IOAM transit nodes update the content of
the array. A pointer which is part of the IOAM trace data points the array. A pointer which is part of the IOAM trace data points
to the next empty slot in the array, which is where the next IOAM to the next empty slot in the array, which is where the next IOAM
transit node fills in its data. transit node fills in its data.
Incremental Trace Option: This trace option is defined as a Incremental Trace Option: This trace option is defined as a
container of node data fields where each node allocates and pushes container of node data fields where each node allocates and pushes
its node data immediately following the option header. The its node data immediately following the option header. This type
maximum length of the node data list is written into the option of trace recording is useful for some of the hardware
header. This type of trace recording is useful for some of the implementations as this eliminates the need for the transit
hardware implementations as this eliminates the need for the network elements to read the full array in the option and allows
transit network elements to read the full array in the option and for arbitrarily long packets as the MTU allows. The in-situ OAM
allows for arbitrarily long packets as the MTU allows. The in- encapsulating node allocates the option header. The in-situ OAM
situ OAM encapsulating node allocates the option header. The in- encapsulating node based on operational state and configuration
situ OAM encapsulating node based on operational state and sets the fields in the header that control what node data fields
configuration sets the fields in the header to control how large should be collected, and how large the node data list can grow.
the node data list can grow. IOAM transit nodes push their node The in-situ OAM transit nodes push their node data to the node
data to the node data list and increment the number of node data data list, decrease the remaining length available to subsequent
fields in the header. nodes, and adjust the lengths and possibly checksums in outer
headers.
Every node data entry is to hold information for a particular IOAM Every node data entry is to hold information for a particular IOAM
transit node that is traversed by a packet. The in-situ OAM transit node that is traversed by a packet. The in-situ OAM
decapsulating node removes the IOAM data and processes and/or exports decapsulating node removes the IOAM data and processes and/or exports
the metadata. IOAM data uses its own name-space for information such the metadata. IOAM data uses its own name-space for information such
as node identifier or interface identifier. This allows for a as node identifier or interface identifier. This allows for a
domain-specific definition and interpretation. For example: In one domain-specific definition and interpretation. For example: In one
case an interface-id could point to a physical interface (e.g., to case an interface-id could point to a physical interface (e.g., to
understand which physical interface of an aggregated link is used understand which physical interface of an aggregated link is used
when receiving or transmitting a packet) whereas in another case it when receiving or transmitting a packet) whereas in another case it
skipping to change at page 8, line 28 skipping to change at page 8, line 34
o A mechanism to detect whether IOAM trace data was added at every o A mechanism to detect whether IOAM trace data was added at every
hop or whether certain hops in the domain weren't in-situ OAM hop or whether certain hops in the domain weren't in-situ OAM
transit nodes. transit nodes.
The "node data list" array in the packet is populated iteratively as The "node data list" array in the packet is populated iteratively as
the packet traverses the network, starting with the last entry of the the packet traverses the network, starting with the last entry of the
array, i.e., "node data list [n]" is the first entry to be populated, array, i.e., "node data list [n]" is the first entry to be populated,
"node data list [n-1]" is the second one, etc. "node data list [n-1]" is the second one, etc.
4.1.1. Pre-allocated Trace Option 4.1.1. Pre-allocated and Incremental Trace Options
In-situ OAM pre-allocated trace option:
Pre-allocated trace option header: The in-situ OAM pre-allocated trace option and the in-situ OAM
incremental trace option have similar formats. Except where noted
below, the internal formats and fields of the two trace options are
identical.
Pre-allocated and incremental trace option headers:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type |NodeLen| Flags | Octets-left | | IOAM-Trace-Type | NodeLen | Flags |RemainingLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pre-allocated Trace Option Data MUST be 4-octet aligned: The trace option data MUST be 4-octet aligned:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | | | | |
| node data list [0] | | | node data list [0] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
| | a | | a
| node data list [1] | t | node data list [1] | t
| | a | | a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ S ~ ... ~ S
skipping to change at page 9, line 40 skipping to change at page 9, line 40
| | | | | |
| node data list [n] | | | node data list [n] | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
IOAM-Trace-Type: A 16-bit identifier which specifies which data IOAM-Trace-Type: A 16-bit identifier which specifies which data
types are used in this node data list. types are used in this node data list.
The IOAM-Trace-Type value is a bit field. The following bit The IOAM-Trace-Type value is a bit field. The following bit
fields are defined in this document, with details on each field fields are defined in this document, with details on each field
described in the Section 4.1.3. The order of packing the data described in the Section 4.1.2. The order of packing the data
fields in each node data element follows the bit order of the fields in each node data element follows the bit order of the
IOAM-Trace-Type field, as follows: IOAM-Trace-Type field, as follows:
Bit 0 (Most significant bit) When set indicates presence of Bit 0 (Most significant bit) When set indicates presence of
Hop_Lim and node_id in the node data. Hop_Lim and node_id in the node data.
Bit 1 When set indicates presence of ingress_if_id and Bit 1 When set indicates presence of ingress_if_id and
egress_if_id (short format) in the node data. egress_if_id (short format) in the node data.
Bit 2 When set indicates presence of timestamp seconds in the Bit 2 When set indicates presence of timestamp seconds in the
node data node data.
Bit 3 When set indicates presence of timestamp nanoseconds in Bit 3 When set indicates presence of timestamp subseconds in
the node data. the node data.
Bit 4 When set indicates presence of transit delay in the node Bit 4 When set indicates presence of transit delay in the node
data. data.
Bit 5 When set indicates presence of app_data (short format) in Bit 5 When set indicates presence of app_data (short format) in
the node data. the node data.
Bit 6 When set indicates presence of queue depth in the node Bit 6 When set indicates presence of queue depth in the node
data. data.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
Bit 9 When set indicates presence of ingress_if_id and Bit 9 When set indicates presence of ingress_if_id and
egress_if_id in wide format in the node data. egress_if_id in wide format in the node data.
Bit 10 When set indicates presence of app_data wide in the node Bit 10 When set indicates presence of app_data wide in the node
data. data.
Bit 11 When set indicates presence of the Checksum Complement Bit 11 When set indicates presence of the Checksum Complement
node data. node data.
Bit 12-15 Undefined in this draft. Bit 12-15 Undefined. An IOAM encapsulating node must set the
value of each of these bits to 0. If an IOAM transit
node receives a packet with one or more of these bits set
to 1, it must either:
Section 4.1.3 describes the IOAM data types and their formats. 1. Add corresponding node data filled with the reserved
value 0xFFFFFFFF, after the node data fields for the
IOAM-Trace-Type bits defined above, such that the
total node data added by this node in units of
4-octets is equal to NodeLen, or
2. Not add any node data fields to the packet, even for
the IOAM-Trace-Type bits defined above.
Section 4.1.2 describes the IOAM data types and their formats.
Within an in-situ OAM domain possible combinations of these bits Within an in-situ OAM domain possible combinations of these bits
making the IOAM-Trace-Type can be restricted by configuration making the IOAM-Trace-Type can be restricted by configuration
knobs. knobs.
NodeLen: 4-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. For example, if data added by each node in multiples of 4-octets, excluding the
3 IOAM-Trace-Type bits are set and none of them is wide, then the length of the "Opaque State Snapshot" field.
NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of
them are wide, then the NodeLen would be 5.
Flags 5-bit field. Following flags are defined: If IOAM-Trace-Type bit 7 is not set, then NodeLen specifies the
actual length added by each node. If IOAM-Trace-Type bit 7 is
set, then the actual length added by a node would be (NodeLen +
Opaque Data Length).
For example, if 3 IOAM-Trace-Type bits are set and none of them
are wide, then NodeLen would be 3. If 3 IOAM-Trace-Type bits are
set and 2 of them are wide, then NodeLen would be 5.
An IOAM encapsulating node must set NodeLen.
A node receiving an IOAM Pre-allocated or Incremental Trace Option
may rely on the NodeLen value, or it may ignore the NodeLen value
and calculate the node length from the IOAM-Trace-Type bits.
Flags 4-bit field. Following flags are defined:
Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
by the network element if there is not enough number of octets by the network element if there is not enough number of octets
left to record node data, no field is added and the overflow left to record node data, no field is added and the overflow
"O-bit" must be set to "1" in the header. This is useful for "O-bit" must be set to "1" in the header. This is useful for
transit nodes to ignore further processing of the option. transit nodes to ignore further processing of the option.
Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy Bit 1 "Loopback" (L-bit). Loopback mode is used to send a copy
of a packet back towards the source. Loopback mode assumes of a packet back towards the source. Loopback mode assumes
that a return path from transit nodes and destination nodes that a return path from transit nodes and destination nodes
skipping to change at page 11, line 22 skipping to change at page 11, line 47
for by setting the loopback bit. The encapsulating node also for by setting the loopback bit. The encapsulating node also
needs to ensure that sufficient space is available in the IOAM needs to ensure that sufficient space is available in the IOAM
header for loopback operation. The loopback bit when set header for loopback operation. The loopback bit when set
indicates to the transit nodes processing this option to create indicates to the transit nodes processing this option to create
a copy of the packet received and send this copy of the packet a copy of the packet received and send this copy of the packet
back to the source of the packet while it continues to forward back to the source of the packet while it continues to forward
the original packet towards the destination. The source the original packet towards the destination. The source
address of the original packet is used as destination address address of the original packet is used as destination address
in the copied packet. The address of the node performing the in the copied packet. The address of the node performing the
copy operation is used as the source address. The L-bit MUST copy operation is used as the source address. The L-bit MUST
be cleared in the copy of the packet a nodes sends it back be cleared in the copy of the packet that a node sends back
towards the source. On its way back towards the source, the towards the source. On its way back towards the source, the
packet is processed like a regular packet with IOAM packet is processed like a regular packet with IOAM
information. Once the return packet reaches the IOAM domain information. Once the return packet reaches the IOAM domain
boundary IOAM decapsulation occurs as with any other packet boundary IOAM decapsulation occurs as with any other packet
containing IOAM information. containing IOAM information.
Bit 2-4 Reserved: Must be zero. Bit 2-3 Reserved: Must be zero.
Octets-left: 7-bit unsigned integer. It is the data space in
multiples of 4-octets remaining for recording the node data. This
is used as an offset in data space to record the node data
element.
Node data List [n]: Variable-length field. The type of which is
determined by the IOAM-Trace-Type representing the n-th node data
in the node data list. The node data list is encoded starting
from the last node data of the path. The first element of the
node data list (node data list [0]) contains the last node of the
path while the last node data of the node data list (node data
list[n]) contains the first node data of the path traced. The
index contained in "Octets-left" identifies the offset for current
active node data to be populated.
4.1.2. Incremental Trace Option
In-situ OAM incremental trace option:
In-situ OAM incremental trace option Header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type |NodeLen| Flags | Max Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM Incremental Trace Option Data MUST be 4-octet aligned:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| node data list [0] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| node data list [1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| node data list [n-1] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| node data list [n] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM-trace-type: A 16-bit identifier which specifies which data
types are used in this node data list.
The IOAM-Trace-Type value is a bit field. The following bit
fields are defined in this document, with details on each field
described in the Section 4.1.3. The order of packing the data
fields in each node data element follows the bit order of the
IOAM-Trace-Type field, as follows:
Bit 0 (Most significant bit) When set indicates presence of
Hop_Lim and node_id in the node data.
Bit 1 When set indicates presence of ingress_if_id and
egress_if_id (short format) in the node data.
Bit 2 When set indicates presence of timestamp seconds in the
node data.
Bit 3 When set indicates presence of timestamp nanoseconds in
the node data.
Bit 4 When set indicates presence of transit delay in the node
data.
Bit 5 When set indicates presence of app_data in the node data.
Bit 6 When set indicates presence of queue depth in the node
data.
Bit 7 When set indicates presence of variable length Opaque
State Snapshot field.
Bit 8 When set indicates presence of Hop_Lim and node_id wide
in the node data.
Bit 9 When set indicates presence of ingress_if_id and
egress_if_id in wide format in the node data.
Bit 10 When set indicates presence of app_data wide in the node
data.
Bit 11 When set indicates presence of the Checksum Complement
node data.
Bit 12-15 Undefined in this draft.
Section 4.1.3 describes the IOAM data types and their formats.
NodeLen: 4-bit unsigned integer. This field specifies the length of
data added by each node in multiples of 4-octets. For example, if
3 IOAM-Trace-Type bits are set and none of them is wide, then the
NodeLen would be 3. If 3 IOAM-Trace-Type bits are set and 2 of
them are wide, then the NodeLen would be 5.
Flags 5-bit field. Following flags are defined:
Bit 0 "Overflow" (O-bit) (most significant bit). This bit is set
by the network element if there is not enough number of octets
left to record node data, no field is added and the overflow
"O-bit" must be set to "1" in the header. This is useful for
transit nodes to ignore further processing of the option.
Bit 1 "Loopback" (L-bit). This bit when set indicates to the
transit nodes processing this option to send a copy of the
packet back to the source of the packet while it continues to
forward the original packet towards the destination. The L-bit
MUST be cleared in the copy of the packet before sending it.
Bit 2-4 Reserved. Must be zero.
Maximum Length: 7-bit unsigned integer. This field specifies the RemainingLen: 7-bit unsigned integer. This field specifies the data
maximum length of the node data list in multiples of 4-octets. space in multiples of 4-octets remaining for recording the node
Given that the sender knows the minimum path MTU, the sender can data, before the node data list is considered to have overflowed.
set the maximum length according to the number of node data bytes When RemainingLen reaches 0, nodes are no longer allowed to add
allowed before exceeding the MTU. Thus, a simple comparison node data. Given that the sender knows the minimum path MTU, the
between "NodeLen" and "Max Length" allows to decide whether or not sender MAY set the initial value of RemainingLen according to the
data could be added. number of node data bytes allowed before exceeding the MTU.
Subsequent nodes can carry out a simple comparison between
RemainingLen and NodeLen, along with the length of the "Opaque
State Snapshot" if applicable, to determine whether or not data
can be added by this node. When node data is added, the node MUST
decrease RemainingLen by the amount of data added. In the pre-
allocated trace option, this is used as an offset in data space to
record the node data element.
Node data List [n]: Variable-length field. The type of which is Node data List [n]: Variable-length field. The type of which is
determined by the OAM Type representing the n-th node data in the determined by the IOAM-Trace-Type bit representing the n-th node
node data list. The node data list is encoded starting from the data in the node data list. The node data list is encoded
last node data of the path. The first element of the node data starting from the last node data of the path. The first element
list (node data list [0]) contains the last node of the path while of the node data list (node data list [0]) contains the last node
the last node data of the node data list (node data list[n]) of the path while the last node data of the node data list (node
contains the first node data of the path traced. data list[n]) contains the first node data of the path traced. In
the pre-allocated trace option, the index contained in
RemainingLen identifies the offset for current active node data to
be populated.
4.1.3. IOAM node data fields and associated formats 4.1.2. IOAM node data fields and associated formats
All the data fields MUST be 4-octet aligned. The IOAM encapsulating All the data fields MUST be 4-octet aligned. If a node which is
node MUST initialize data fields that it adds to the packet to zero. supposed to update an IOAM data field is not capable of populating
If a node which is supposed to update an IOAM data field is not the value of a field set in the IOAM-Trace-Type, the field value MUST
capable of populating the value of a field set in the IOAM-Trace- be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF for
Type, the field value MUST be left unaltered except when explicitly 8-octet fields, indicating that the value is not populated, except
specified in the field description below. In the description of data when explicitly specified in the field description below.
below if zero is valid value then a non-zero value to mean not
populated is specified.
Data field and associated data type for each of the data field is Data field and associated data type for each of the data field is
shown below: shown below:
Hop_Lim and node_id: 4-octet field defined as follows: Hop_Lim and node_id: 4-octet field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 18 skipping to change at page 13, line 21
lower layer protocol that IOAM is encapsulated over, and lower layer protocol that IOAM is encapsulated over, and
therefore its specific semantics are outside the scope of this therefore its specific semantics are outside the scope of this
memo. memo.
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 in-situ OAM domain. The uniquely identify a node within in-situ OAM domain. The
procedure to allocate, manage and map the node_ids is beyond procedure to allocate, manage and map the node_ids is beyond
the scope of this document. the scope of this document.
ingress_if_id and egress_if_id: 4-octet field defined as follows: ingress_if_id and egress_if_id: 4-octet field defined as follows:
When this field is part of the data field but a node populating
the field is not able to fill it, the position in the field must
be filled with value 0xFFFFFFFF to mean not populated.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ingress_if_id: 2-octet unsigned integer. Interface identifier to ingress_if_id: 2-octet unsigned integer. Interface identifier to
record the ingress interface the packet was received on. record the ingress interface the packet was received on.
egress_if_id: 2-octet unsigned integer. Interface identifier to egress_if_id: 2-octet unsigned integer. Interface identifier to
record the egress interface the packet is forwarded out of. record the egress interface the packet is forwarded out of.
timestamp seconds: 4-octet unsigned integer. Absolute timestamp in timestamp seconds: 4-octet unsigned integer. Absolute timestamp in
seconds that specifies the time at which the packet was received seconds that specifies the time at which the packet was received
by the node. The structure of this field is identical to the most by the node. This field has three possible formats; based on
significant 32 bits of the 64 least significant bits of the either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX]. The
[IEEE1588v2] timestamp. This truncated field consists of a 32-bit three timestamp formats are specified in Section 5. In all three
seconds field. As defined in [IEEE1588v2], the timestamp cases, the Timestamp Seconds field contains the 32 most
specifies the number of seconds elapsed since 1 January 1970 significant bits of the timestamp format that is specified in
00:00:00 according to the International Atomic Time (TAI). Section 5. If a node is not capable of populating this field, it
assigns the value 0xFFFFFFFF. Note that this is a legitimate
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 value that is valid for 1 second in approximately 136 years; the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ analyzer should correlate several packets or compare the timestamp
| timestamp seconds | value to its own time-of-day in order to detect the error
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ indication.
timestamp nanoseconds: 4-octet unsigned integer in the range 0 to
10^9-1. This timestamp specifies the fractional part of the wall
clock time at which the packet was received by the node in units
of nanoseconds. This field is identical to the 32 least
significant bits of the [IEEE1588v2] timestamp. This fields
allows for delay computation between any two nodes in the network
when the nodes are time synchronized. When this field is part of
the data field but a node populating the field is not able to fill
it, the field position in the field must be filled with value
0xFFFFFFFF to mean not populated.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 timestamp subseconds: 4-octet unsigned integer. Absolute timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in subseconds that specifies the time at which the packet was
| timestamp nanoseconds | received by the node. This field has three possible formats;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ based on either PTP [IEEE1588v2], NTP [RFC5905], or POSIX [POSIX].
The three timestamp formats are specified in Section 5. In all
three cases, the Timestamp Subseconds field contains the 32 least
significant bits of the timestamp format that is specified in
Section 5. If a node is not capable of populating this field, it
assigns the value 0xFFFFFFFF. Note that this is a legitimate
value in the NTP format, valid for approximately 233 picoseconds
in every second. If the NTP format is used the analyzer should
correlate several packets in order to detect the error indication.
transit delay: 4-octet unsigned integer in the range 0 to 2^31-1. transit delay: 4-octet unsigned integer in the range 0 to 2^31-1.
It is the time in nanoseconds the packet spent in the transit It is the time in nanoseconds the packet spent in the transit
node. This can serve as an indication of the queuing delay at the node. This can serve as an indication of the queuing delay at the
node. If the transit delay exceeds 2^31-1 nanoseconds then the node. If the transit delay exceeds 2^31-1 nanoseconds then the
top bit 'O' is set to indicate overflow and value set to top bit 'O' is set to indicate overflow and value set to
0x80000000. When this field is part of the data field but a node 0x80000000. When this field is part of the data field but a node
populating the field is not able to fill it, the field position in populating the field is not able to fill it, the field position in
the field must be filled with value 0xFFFFFFFF to mean not the field must be filled with value 0xFFFFFFFF to mean not
populated. populated.
skipping to change at page 16, line 45 skipping to change at page 14, line 42
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | app_data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
queue depth: 4-octet unsigned integer field. This field indicates queue depth: 4-octet unsigned integer field. This field indicates
the current length of the egress interface queue of the interface the current length of the egress interface queue of the interface
from where the packet is forwarded out. The queue depth is from where the packet is forwarded out. The queue depth is
expressed as the current number of memory buffers used by the expressed as the current number of memory buffers used by the
queue (a packet may consume one or more memory buffers, depending queue (a packet may consume one or more memory buffers, depending
on its size). When this field is part of the data field but a on its size).
node populating the field is not able to fill it, the field
position in the field must be filled with value 0xFFFFFFFF to mean
not populated.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| queue depth | | queue depth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opaque State Snapshot: Variable length field. It allows the network Opaque State Snapshot: Variable length field. It allows the network
element to store an arbitrary state in the node data field , element to store an arbitrary state in the node data field ,
without a pre-defined schema. The schema needs to be made known without a pre-defined schema. The schema needs to be made known
to the analyzer by some out-of-band mechanism. The specification to the analyzer by some out-of-band mechanism. The specification
skipping to change at page 17, line 32 skipping to change at page 15, line 23
| Length | Schema ID | | Length | Schema ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 1-octet unsigned integer. It is the length in octets of Length: 1-octet unsigned integer. It is the length in multiples
the Opaque data field that follows Schema Id. It MUST always of 4-octets of the Opaque data field that follows Schema Id.
be a multiple of 4.
Schema ID: 3-octet unsigned integer identifying the schema of Schema ID: 3-octet unsigned integer identifying the schema of
Opaque data. Opaque data.
Opaque data: Variable length field. This field is interpreted as Opaque data: Variable length field. This field is interpreted as
specified by the schema identified by the Schema ID. specified by the schema identified by the Schema ID.
When this field is part of the data field but a node populating
the field has no opaque state data to report, the Length must be
set to 0 and the Schema ID must be set to 0xFFFFFF to mean no
schema.
Hop_Lim and node_id wide: 8-octet field defined as follows: Hop_Lim and node_id wide: 8-octet field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id ~ | Hop_Lim | node_id ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ node_id (contd) | ~ node_id (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit Hop_Lim: 1-octet unsigned integer. It is set to the Hop Limit
skipping to change at page 18, line 18 skipping to change at page 16, line 14
depend on the lower layer protocol that IOAM is encapsulated depend on the lower layer protocol that IOAM is encapsulated
over, and therefore its specific semantics are outside the over, and therefore its specific semantics are outside the
scope of this memo. scope of this memo.
node_id: 7-octet unsigned integer. Node identifier field to node_id: 7-octet unsigned integer. Node identifier field to
uniquely identify a node within in-situ OAM domain. The uniquely identify a node within in-situ OAM domain. The
procedure to allocate, manage and map the node_ids is beyond procedure to allocate, manage and map the node_ids is beyond
the scope of this document. the scope of this document.
ingress_if_id and egress_if_id wide: 8-octet field defined as ingress_if_id and egress_if_id wide: 8-octet field defined as
follows: When this field is part of the data field but a node follows:
populating the field is not able to fill it, the field position in
the field must be filled with value 0xFFFFFFFFFFFFFFFF to mean not
populated.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | | ingress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| egress_if_id | | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ingress_if_id: 4-octet unsigned integer. Interface identifier to ingress_if_id: 4-octet unsigned integer. Interface identifier to
record the ingress interface the packet was received on. record the ingress interface the packet was received on.
skipping to change at page 18, line 50 skipping to change at page 16, line 43
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app data ~ | app data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ app data (contd) | ~ app data (contd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Checksum Complement: 4-octet node data which contains a two-octet Checksum Complement: 4-octet node data which contains a two-octet
Checksum Complement field, and a 2-octet reserved field. The Checksum Complement field, and a 2-octet reserved field. The
Checksum Complement can be used when IOAM is transported over Checksum Complement is useful when IOAM is transported over
encapsulations that make use of a UDP transport, such as VXLAN-GPE encapsulations that make use of a UDP transport, such as VXLAN-GPE
or Geneve. In this case, incorporating the IOAM node data or Geneve. Without the Checksum Complement, nodes adding IOAM
requires the UDP Checksum field to be updated. Rather than to node data must update the UDP Checksum field. When the Checksum
recompute the Chekcsum field, a node can use the Checksum Complement is present, an IOAM encapsulating node or IOAM transit
Complement to make a checksum-neutral update in the UDP payload; node adding node data MUST carry out one of the following two
the Checksum Complement is assigned a value that complements the alternatives in order to maintain the correctness of the UDP
rest of the node data fields that were added by the current node, Checksum value:
causing the existing UDP Checksum field to remain correct.
1. Recompute the UDP Checksum field.
2. Use the Checksum Complement to make a checksum-neutral update
in the UDP payload; the Checksum Complement is assigned a
value that complements the rest of the node data fields that
were added by the current node, causing the existing UDP
Checksum field to remain correct.
IOAM decapsulating nodes MUST recompute the UDP Checksum field,
since they do not know whether previous hops modified the UDP
Checksum field or the Checksum Complement field.
Checksum Complement fields are used in a similar manner in Checksum Complement fields are used in a similar manner in
[RFC7820] and [RFC7821]. [RFC7820] and [RFC7821].
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 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
8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum Complement | Reserved | | Checksum Complement | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.4. Examples of IOAM node data 4.1.3. Examples of IOAM node data
An entry in the "node data list" array can have different formats, An entry in the "node data list" array can have different formats,
following the needs of the deployment. Some deployments might only following the needs of the deployment. Some deployments might only
be interested in recording the node identifiers, whereas others might be interested in recording the node identifiers, whereas others might
be interested in recording node identifier and timestamp. The be interested in recording node identifier and timestamp. The
section defines different types that an entry in "node data list" can section defines different types that an entry in "node data list" can
take. take.
0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is: 0xD400: IOAM-Trace-Type is 0xD400 then the format of node data is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp nanoseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | app_data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0xC000: IOAM-Trace-Type is 0xC000 then the format is: 0xC000: IOAM-Trace-Type is 0xC000 then the format is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingress_if_id | egress_if_id | | ingress_if_id | egress_if_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x9000: IOAM-Trace-Type is 0x9000 then the format is: 0x9000: IOAM-Trace-Type is 0x9000 then the format is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp nanoseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x8400: IOAM-Trace-Type is 0x8400 then the format is: 0x8400: IOAM-Trace-Type is 0x8400 then the format is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | app_data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x9400: IOAM-Trace-Type is 0x9400 then the format is: 0x9400: IOAM-Trace-Type is 0x9400 then the format is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop_Lim | node_id | | Hop_Lim | node_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp nanoseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| app_data | | app_data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x3180: IOAM-Trace-Type is 0x3180 then the format is: 0x3180: IOAM-Trace-Type is 0x3180 then the format is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp seconds | | timestamp seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp nanoseconds | | timestamp subseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Schema Id | | Length | Schema Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Opaque data | | Opaque data |
~ ~ ~ ~
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 9 skipping to change at page 20, line 9
o Random: Unique identifier for the packet (e.g., 64-bits allow for o Random: Unique identifier for the packet (e.g., 64-bits allow for
the unique identification of 2^64 packets). the unique identification of 2^64 packets).
o Cumulative: Information which is handed from node to node and o Cumulative: Information which is handed from node to node and
updated by every node according to a verification algorithm. updated by every node according to a verification algorithm.
IOAM proof of transit option: IOAM proof of transit option:
IOAM proof of transit option header: IOAM proof of transit option header:
0 1 2 3 4 5 6 7 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
|IOAM POT Type|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ |IOAM POT Type | IOAM POT flags| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM proof of transit option data MUST be 4-octet aligned: IOAM proof of transit option data MUST be 4-octet aligned.:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POT Option data field determined by IOAM-POT-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM POT Type: 8-bit identifier of a particular POT variant that
specifies the POT data that is included. This document defines
POT Type 0:
0: POT data is a 16 Octet field as described below.
IOAM POT flags: 8-bit. Following flags are defined:
Bit 0 "Profile-to-use" (P-bit) (most significant bit). For IOAM
POT types that use a maximum of two profiles to drive
computation, indicates which POT-profile is used. The two
profiles are numbered 0, 1.
Bit 1-7 Reserved: Must be set to zero upon transmission and
ignored upon receipt.
Reserved: 16-bit Reserved bits are present for future use. The
reserved bits Must be set to zero upon transmission and ignored
upon receipt.
POT Option data: Variable-length field. The type of which is
determined by the IOAM-POT-Type.
4.2.1. IOAM Proof of Transit Type 0
IOAM proof of transit option of IOAM POT Type 0:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IOAM POT Type=0|P|R R R R R R R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| Random | | | Random | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Random(contd) | O | Random(contd) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | | | Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd) | | | Cumulative (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
IOAM POT Type: 7-bit identifier of a particular POT variant that IOAM POT Type: 8-bit identifier of a particular POT variant that
dictates the POT data that is included. This document defines POT specifies the POT data that is included. This section defines the
Type 0: POT data when the IOAM POT Type is set to the value 0.
0: POT data is a 16 Octet field as described below. P bit: 1-bit. "Profile-to-use" (P-bit) (most significant bit).
Indicates which POT-profile is used to generate the Cumulative.
Any node participating in POT will have a maximum of 2 profiles
configured that drive the computation of cumulative. The two
profiles are numbered 0, 1. This bit conveys whether profile 0 or
profile 1 is used to compute the Cumulative.
Profile to use (P): 1-bit. Indicates which POT-profile is used to R (7 bits): 7-bit IOAM POT flags for future use. MUST be set to
generate the Cumulative. Any node participating in POT will have zero upon transmission and ignored upon receipt.
a maximum of 2 profiles configured that drive the computation of
cumulative. The two profiles are numbered 0, 1. This bit conveys Reserved: 16-bit Reserved bits are present for future use. The
whether profile 0 or profile 1 is used to compute the Cumulative. reserved bits Must be set to zero upon transmission and ignored
upon receipt.
Random: 64-bit Per packet Random number. Random: 64-bit Per packet Random number.
Cumulative: 64-bit Cumulative that is updated at specific nodes by Cumulative: 64-bit Cumulative that is updated at specific nodes by
processing per packet Random number field and configured processing per packet Random number field and configured
parameters. parameters.
Note: Larger or smaller sizes of "Random" and "Cumulative" data are Note: Larger or smaller sizes of "Random" and "Cumulative" data are
feasible and could be required for certain deployments (e.g. in case feasible and could be required for certain deployments (e.g. in case
of space constraints in the transport protocol used). Future of space constraints in the transport protocol used). Future
versions of this document will address different sizes of data for versions of this document will address different sizes of data for
"proof of transit". "proof of transit".
4.3. IOAM Edge-to-Edge Option 4.3. IOAM Edge-to-Edge Option
The IOAM edge-to-edge option is to carry data that is added by the The IOAM edge-to-edge option is to carry data that is added by the
IOAM encapsulating node and interpreted by IOAM decapsulating node. IOAM encapsulating node and interpreted by IOAM decapsulating node.
The IOAM transit nodes MAY process the data without modifying it. The IOAM transit nodes MAY process the data without modifying it.
Currently only sequence numbers use the IOAM edge-to-edge option. In
order to detect packet loss, packet reordering, or packet duplication
in an in-situ OAM-domain, sequence numbers can be added to packets of
a particular tube (see [I-D.hildebrand-spud-prototype]). Each tube
leverages a dedicated namespace for its sequence numbers.
IOAM edge-to-edge option: IOAM edge-to-edge option:
IOAM edge-to-edge option header: IOAM edge-to-edge option header:
0 1 2 3 4 5 6 7 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
| IOAM-E2E-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | IOAM-E2E-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM edge-to-edge option data MUST be 4-octet aligned: IOAM edge-to-edge option data MUST be 4-octet aligned:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E2E Option data field determined by IOAM-E2E-Type | | E2E Option data field determined by IOAM-E2E-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM-E2E-Type: 8-bit identifier of a particular in situ OAM E2E IOAM-E2E-Type: A 16-bit identifier which specifies which data types
variant. are used in the E2E option data. The IOAM-E2E-Type value is a bit
field. The order of packing the E2E option data field elements
follows the bit order of the IOAM-E2E-Type field, as follows:
0: E2E option data is a 64-bit sequence number added to a Bit 0 (Most significant bit) When set indicates presence of a
specific tube which is used to identify packet loss and 64-bit sequence number added to a specific tube which is
reordering for that tube. used to detect packet loss, packet reordering, or packet
duplication for that tube. Each tube leverages a
dedicated namespace for its sequence numbers.
5. IOAM Data Export Bit 1 When set indicates presence of a 32-bit sequence number
added to a specific tube which is used to detect packet
loss, packet reordering, or packet duplication for that
tube. Each tube leverages a dedicated namespace for its
sequence numbers.
Bit 2 When set indicates presence of timestamp seconds for the
transmission of the frame. This 4-octet field has three
possible formats; based on either PTP [IEEE1588v2], NTP
[RFC5905], or POSIX [POSIX]. The three timestamp formats
are specified in Section 5. In all three cases, the
Timestamp Seconds field contains the 32 most significant
bits of the timestamp format that is specified in
Section 5. If a node is not capable of populating this
field, it assigns the value 0xFFFFFFFF. Note that this
is a legitimate value that is valid for 1 second in
approximately 136 years; the analyzer should correlate
several packets or compare the timestamp value to its own
time-of-day in order to detect the error indication.
Bit 3 When set indicates presence of timestamp subseconds for
the transmission of the frame. This 4-octet field has
three possible formats; based on either PTP [IEEE1588v2],
NTP [RFC5905], or POSIX [POSIX]. The three timestamp
formats are specified in Section 5. In all three cases,
the Timestamp Subseconds field contains the 32 least
significant bits of the timestamp format that is
specified in Section 5. If a node is not capable of
populating this field, it assigns the value 0xFFFFFFFF.
Note that this is a legitimate value in the NTP format,
valid for approximately 233 picoseconds in every second.
If the NTP format is used the analyzer should correlate
several packets in order to detect the error indication.
Bit 4-15 Undefined. An IOAM encapsulating node Must set the value
of these bits to zero upon transmission and ignore upon
receipt.
Reserved: 16-bits Reserved bits are present for future use. The
reserved bits Must be set to zero upon transmission and ignored
upon receipt.
E2E Option data: Variable-length field. The type of which is
determined by the IOAM-E2E-Type.
5. Timestamp Formats
The IOAM data fields include a timestamp field which is represented
in one of three possible timestamp formats. It is assumed that the
management plane is responsible for determining which timestamp
format is used.
5.1. PTP Truncated Timestamp Format
The Precision Time Protocol (PTP) [IEEE1588v2] uses an 80-bit
timestamp format. The truncated timestamp format is a 64-bit field,
which is the 64 least significant bits of the 80-bit PTP timestamp.
The PTP truncated format is specified in Section 4.3 of
[I-D.ietf-ntp-packet-timestamps], and the details are presented below
for the sake of completeness.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PTP [IEEE1588] Truncated Timestamp Format
Timestamp field format:
Seconds: specifies the integer portion of the number of seconds
since the epoch.
+ Size: 32 bits.
+ Units: seconds.
Nanoseconds: specifies the fractional portion of the number of
seconds since the epoch.
+ Size: 32 bits.
+ Units: nanoseconds. The value of this field is in the range 0
to (10^9)-1.
Epoch:
The PTP [IEEE1588v2] epoch is 1 January 1970 00:00:00 TAI, which
is 31 December 1969 23:59:51.999918 UTC.
Resolution:
The resolution is 1 nanosecond.
Wraparound:
This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2106.
Synchronization Aspects:
It is assumed that nodes that run this protocol are synchronized
among themselves. Nodes may be synchronized to a global reference
time. Note that if PTP [IEEE1588v2] is used for synchronization,
the timestamp may be derived from the PTP-synchronized clock,
allowing the timestamp to be measured with respect to the clock of
an PTP Grandmaster clock.
The PTP truncated timestamp format is not affected by leap
seconds.
5.2. NTP 64-bit Timestamp Format
The Network Time Protocol (NTP) [RFC5905] timestamp format is 64 bits
long. This format is specified in Section 4.2.1 of
[I-D.ietf-ntp-packet-timestamps], and the details are presented below
for the sake of completeness.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTP [RFC5905] 64-bit Timestamp Format
Timestamp field format:
Seconds: specifies the integer portion of the number of seconds
since the epoch.
+ Size: 32 bits.
+ Units: seconds.
Fraction: specifies the fractional portion of the number of
seconds since the epoch.
+ Size: 32 bits.
+ Units: the unit is 2^(-32) seconds, which is roughly equal to
233 picoseconds.
Epoch:
The epoch is 1 January 1900 at 00:00 UTC.
Resolution:
The resolution is 2^(-32) seconds.
Wraparound:
This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2036.
Synchronization Aspects:
Nodes that use this timestamp format will typically be
synchronized to UTC using NTP [RFC5905]. Thus, the timestamp may
be derived from the NTP-synchronized clock, allowing the timestamp
to be measured with respect to the clock of an NTP server.
The NTP timestamp format is affected by leap seconds; it
represents the number of seconds since the epoch minus the number
of leap seconds that have occurred since the epoch. The value of
a timestamp during or slightly after a leap second may be
temporarily inaccurate.
5.3. POSIX-based Timestamp Format
This timestamp format is based on the POSIX time format [POSIX]. The
detailed specification of the timestamp format used in this document
is presented below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: POSIX-based Timestamp Format
Timestamp field format:
Seconds: specifies the integer portion of the number of seconds
since the epoch.
+ Size: 32 bits.
+ Units: seconds.
Microseconds: specifies the fractional portion of the number of
seconds since the epoch.
+ Size: 32 bits.
+ Units: the unit is microseconds. The value of this field is in
the range 0 to (10^6)-1.
Epoch:
The epoch is 1 January 1970 00:00:00 TAI, which is 31 December
1969 23:59:51.999918 UTC.
Resolution:
The resolution is 1 microsecond.
Wraparound:
This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2106.
Synchronization Aspects:
It is assumed that nodes that use this timestamp format run Linux
operating system, and hence use the POSIX time. In some cases
nodes may be synchronized to UTC using a synchronization mechanism
that is outside the scope of this document, such as NTP [RFC5905].
Thus, the timestamp may be derived from the NTP-synchronized
clock, allowing the timestamp to be measured with respect to the
clock of an NTP server.
The POSIX-based timestamp format is affected by leap seconds; it
represents the number of seconds since the epoch minus the number
of leap seconds that have occurred since the epoch. The value of
a timestamp during or slightly after a leap second may be
temporarily inaccurate.
6. IOAM Data Export
IOAM nodes collect information for packets traversing a domain that IOAM nodes collect information for packets traversing a domain that
supports IOAM. IOAM decapsulating nodes as well as IOAM transit supports IOAM. IOAM decapsulating nodes as well as IOAM transit
nodes can choose to retrieve IOAM information from the packet, nodes can choose to retrieve IOAM information from the packet,
process the information further and export the information using process the information further and export the information using
e.g., IPFIX. e.g., IPFIX.
The discussion of IOAM data processing and export is left for a The discussion of IOAM data processing and export is left for a
future version of this document. future version of this document.
6. IANA Considerations 7. IANA Considerations
This document requests the following IANA Actions. This document requests the following IANA Actions.
6.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM) 7.1. Creation of a new In-Situ OAM Protocol Parameters Registry (IOAM)
Protocol Parameters IANA registry Protocol Parameters IANA registry
IANA is requested to create a new protocol registry for "In-Situ OAM IANA is requested to create a new protocol registry for "In-Situ OAM
(IOAM) Protocol Parameters". This is the common registry that will (IOAM) Protocol Parameters". This is the common registry that will
include registrations for all IOAM namespaces. Each Registry, whose include registrations for all IOAM namespaces. Each Registry, whose
names are listed below: names are listed below:
IOAM Type
IOAM Trace Type IOAM Trace Type
IOAM Trace flags IOAM Trace flags
IOAM POT Type IOAM POT Type
IOAM POT flags
IOAM E2E Type IOAM E2E Type
will contain the current set of possibilities defined in this will contain the current set of possibilities defined in this
document. New registries in this name space are created via RFC document. New registries in this name space are created via RFC
Required process as per [RFC8126]. Required process as per [RFC8126].
The subsequent sub-sections detail the registries herein contained. The subsequent sub-sections detail the registries herein contained.
6.2. IOAM Trace Type Registry 7.2. IOAM Type Registry
This registry defines 128 code points for the IOAM-Type field for
identifying IOAM options as explained in Section 4. The following
code points are defined in this draft:
0 IOAM Pre-allocated Trace Option Type
1 IOAM Incremental Trace Option Type
2 IOAM POT Option Type
3 IOAM E2E Option Type
4 - 127 are available for assignment via RFC Required process as per
[RFC8126].
7.3. IOAM Trace Type Registry
This registry defines code point for each bit in the 16-bit IOAM- This registry defines code point for each bit in the 16-bit IOAM-
Trace-Type field for Pre-allocated trace option and Incremental trace Trace-Type field for Pre-allocated trace option and Incremental trace
option defined in Section 4.1. The meaning of Bit 0 - 11 for trace option defined in Section 4.1. The meaning of Bit 0 - 11 for trace
type are defined in this document in Paragraph 1 of (Section 4.1.1). type are defined in this document in Paragraph 1 of (Section 4.1.1).
The meaning for Bit 12 - 15 are available for assignment via RFC The meaning for Bit 12 - 15 are available for assignment via RFC
Required process as per [RFC8126]. Required process as per [RFC8126].
6.3. IOAM Trace Flags Registry 7.4. IOAM Trace Flags Registry
This registry defines code point for each bit in the 5 bit flags for This registry defines code point for each bit in the 4 bit flags for
Pre-allocated trace option and Incremental trace option defined in Pre-allocated trace option and Incremental trace option defined in
Section 4.1. The meaning of Bit 0 - 1 for trace flags are defined in Section 4.1. The meaning of Bit 0 - 1 for trace flags are defined in
this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2 this document in Paragraph 5 of Section 4.1.1. The meaning for Bit 2
- 4 are available for assignment via RFC Required process as per - 3 are available for assignment via RFC Required process as per
[RFC8126]. [RFC8126].
6.4. IOAM POT Type Registry 7.5. IOAM POT Type Registry
This registry defines 128 code points to define IOAM POT Type for This registry defines 256 code points to define IOAM POT Type for
IOAM proof of transit option Section 4.2. The code point value 0 is IOAM proof of transit option Section 4.2. The code point value 0 is
defined in this document, 1 - 127 are available for assignment via defined in this document, 1 - 255 are available for assignment via
RFC Required process as per [RFC8126]. RFC Required process as per [RFC8126].
6.5. IOAM E2E Type Registry 7.6. IOAM POT Flags Registry
This registry defines 256 code points to define IOAM-E2E-Type for This registry defines code point for each bit in the 8 bit flags for
IOAM E2E option Section 4.3. The code point value 0 is defined in IOAM POT option defined in Section 4.2. The meaning of Bit 0 for
this document, 1 - 255 are available for assignments via RFC Required IOAM POT flags is defined in this document in Section 4.2. The
meaning for Bit 1 - 7 are available for assignment via RFC Required
process as per [RFC8126]. process as per [RFC8126].
7. Manageability Considerations 7.7. IOAM E2E Type Registry
This registry defines code points for each bit in the 16 bit IOAM-
E2E-Type field for IOAM E2E option Section 4.3. The meaning of Bit 0
- 3 are defined in this document. The meaning of Bit 4 - 15 are
available for assignments via RFC Required process as per [RFC8126].
8. Manageability Considerations
Manageability considerations will be addressed in a later version of Manageability considerations will be addressed in a later version of
this document.. this document..
8. Security Considerations 9. Security Considerations
Security considerations will be addressed in a later version of this Security considerations will be addressed in a later version of this
document. For a discussion of security requirements of in-situ OAM, document.
please refer to [I-D.brockners-inband-oam-requirements].
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and Nadahalli, LJ Wobker, Erik Nordmark, Vengada Prasad Govindan, and
Andrew Yourtchenko for the comments and advice. Andrew Yourtchenko for the comments and advice.
This document leverages and builds on top of several concepts This document leverages and builds on top of several concepts
described in [I-D.kitamura-ipv6-record-route]. The authors would described in [I-D.kitamura-ipv6-record-route]. The authors would
like to acknowledge the work done by the author Hiroshi Kitamura and like to acknowledge the work done by the author Hiroshi Kitamura and
people involved in writing it. people involved in writing it.
The authors would like to gracefully acknowledge useful review and The authors would like to gracefully acknowledge useful review and
insightful comments received from Joe Clarke, Al Morton, and Mickey insightful comments received from Joe Clarke, Al Morton, and Mickey
Spiegel. Spiegel.
10. References 11. References
10.1. Normative References 11.1. Normative References
[IEEE1588v2] [IEEE1588v2]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, "IEEE
"1588-2008 - IEEE Standard for a Precision Clock Std 1588-2008 - IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", IEEE Std 1588-2008, 2008, Control Systems", IEEE Std 1588-2008, 2008,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/1588-2008.html>. standard/1588-2008.html>.
[POSIX] Institute of Electrical and Electronics Engineers, "IEEE
Std 1003.1-2008 (Revision of IEEE Std 1003.1-2004) - IEEE
Standard for Information Technology - Portable Operating
System Interface (POSIX(R))", IEEE Std 1003.1-2008, 2008,
<https://standards.ieee.org/findstds/
standard/1003.1-2008.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC8126] 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>.
10.2. Informative References 11.2. Informative References
[I-D.brockners-inband-oam-requirements]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
T., <>, P., and r. remy@barefootnetworks.com,
"Requirements for In-situ OAM", draft-brockners-inband-
oam-requirements-03 (work in progress), March 2017.
[I-D.brockners-inband-oam-transport]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
D., Lapukhov, P., and R. Chang, "Encapsulations for In-
situ OAM Data", draft-brockners-inband-oam-transport-05
(work in progress), July 2017.
[I-D.hildebrand-spud-prototype] [I-D.hildebrand-spud-prototype]
Hildebrand, J. and B. Trammell, "Substrate Protocol for Hildebrand, J. and B. Trammell, "Substrate Protocol for
User Datagrams (SPUD) Prototype", draft-hildebrand-spud- User Datagrams (SPUD) Prototype", draft-hildebrand-spud-
prototype-03 (work in progress), March 2015. prototype-03 (work in progress), March 2015.
[I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-00 (work in progress), October 2017.
[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-05 (work in progress), September 2017. nvo3-geneve-05 (work in progress), September 2017.
[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-04 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-05 (work
in progress), April 2017. in progress), October 2017.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
October 2017. November 2017.
[I-D.kitamura-ipv6-record-route] [I-D.kitamura-ipv6-record-route]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
Option Extension", draft-kitamura-ipv6-record-route-00 Option Extension", draft-kitamura-ipv6-record-route-00
(work in progress), November 2000. (work in progress), November 2000.
[I-D.lapukhov-dataplane-probe] [I-D.lapukhov-dataplane-probe]
Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane Lapukhov, P. and r. remy@barefootnetworks.com, "Data-plane
probe for in-band telemetry collection", draft-lapukhov- probe for in-band telemetry collection", draft-lapukhov-
dataplane-probe-01 (work in progress), June 2016. dataplane-probe-01 (work in progress), June 2016.
skipping to change at page 28, line 19 skipping to change at page 33, line 4
Email: shwethab@cisco.com Email: shwethab@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States United States
Email: cpignata@cisco.com Email: cpignata@cisco.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
John Leddy John Leddy
Comcast Comcast
United States
Email: John_Leddy@cable.comcast.com Email: John_Leddy@cable.comcast.com
Stephen Youell Stephen Youell
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
skipping to change at page 29, line 4 skipping to change at page 33, line 30
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam 2066721 Yokneam 2066721
Israel Israel
Email: talmi@marvell.com Email: talmi@marvell.com
David Mozes David Mozes
Mellanox Technologies Ltd.
Email: davidm@mellanox.com Email: mosesster@gmail.com
Petr Lapukhov Petr Lapukhov
Facebook Facebook
1 Hacker Way 1 Hacker Way
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
Email: petr@fb.com Email: petr@fb.com
Remy Chang Remy Chang
Barefoot Networks Barefoot Networks
2185 Park Boulevard 4750 Patrick Henry Drive
Palo Alto, CA 94306 Santa Clara, CA 95054
US US
Daniel Daniel Bernier
Bell Canada Bell Canada
Canada
Email: daniel.bernier@bell.ca Email: daniel.bernier@bell.ca
John Lemon
Broadcom
270 Innovation Drive
San Jose, CA 95134
US
Email: john.lemon@broadcom.com
 End of changes. 91 change blocks. 
346 lines changed or deleted 582 lines changed or added

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