< draft-ali-spring-ioam-srv6-00.txt   draft-ali-spring-ioam-srv6-01.txt >
SPRING Working Group Z. Ali SPRING Working Group Z. Ali
Internet-Draft R. Gandhi Internet-Draft R. Gandhi
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: April 25, 2019 F. Brockners Expires: January 9, 2020 F. Brockners
N. Nainar N. Nainar
C. Pignataro C. Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
C. Li C. Li
M. Chen M. Chen
Huawei Huawei
G. Dawra G. Dawra
LinkedIn LinkedIn
October 22, 2018 July 8, 2019
Segment Routing Header encapsulation for In-situ OAM Data Segment Routing Header encapsulation for In-situ OAM Data
draft-ali-spring-ioam-srv6-00 draft-ali-spring-ioam-srv6-01
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records OAM and PM information from the SR endpoints can be piggybacked in
the data packet. The OAM and PM information piggybacking in the data
packets is also known as In-situ OAM (IOAM). IOAM records
operational and telemetry information in the data packet while the operational and telemetry information in the data packet while the
packet traverses a path between two points in the network. This packet traverses a path between two points in the network. This
document defines how IOAM data fields are transported as part of the document defines how IOAM data fields are transported as part of the
Segment Routing with IPv6 data plane (SRv6) header. Segment Routing with IPv6 data plane (SRv6) header.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. IOAM Data Field Encapsulation in SRH . . . . . . . . . . . . . 4 3. OAM Metadata Piggybacked in Data Packets . . . . . . . . .. . 4
3.1 IOAM Data Field Encapsulation in SRH . . . . . . . . . . . . 4
4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Ingress Node . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Ingress Node . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SR Segment Endpoint Node . . . . . . . . . . . . . . . . . 5 4.2. SR Segment Endpoint Node . . . . . . . . . . . . . . . . . 5
4.3. Egress Node . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Egress Node . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In-situ Operations, Administration, and Maintenance (IOAM) records OAM and PM information from the SR endpoints can be piggybacked in
the data packet. The OAM and PM information piggybacking in the data
packets is also known as In-situ OAM (IOAM). IOAM records
OAM information within the packet while the packet traverses a OAM information within the packet while the packet traverses a
particular network domain. The term "in-situ" refers to the fact particular network domain. The term "in-situ" refers to the fact
that the IOAM data fields are added to the data packets rather than that the IOAM data fields are added to the data packets rather than
being sent within probe packets specifically dedicated to OAM. being sent within probe packets specifically dedicated to OAM.
This document defines how IOAM data fields are transported as part of This document defines how IOAM data fields are transported as part of
the Segment Routing with IPv6 data plane (SRv6) header the Segment Routing with IPv6 data plane (SRv6) header
[I-D.6man-segment-routing-header]. [I-D.6man-segment-routing-header].
The IOAM data fields carried are defined in The IOAM data fields carried are defined in
skipping to change at page 4, line 5 skipping to change at page 4, line 5
PM Performance Measurement PM Performance Measurement
PoT Proof-of-Transit PoT Proof-of-Transit
SR Segment Routing SR Segment Routing
SRH SRv6 Header SRH SRv6 Header
SRv6 Segment Routing with IPv6 Data plane SRv6 Segment Routing with IPv6 Data plane
3. IOAM Data Field Encapsulation in SRH 3. OAM Metadata Piggybacked in Data Packets
The SRv6 encapsulation header (SRH) is defined in OAM and PM information from the SR endpoints can be piggybacked in
[I-D.6man-segment-routing-header]. IOAM data fields are carried in the data packet. The OAM and PM information piggybacking in the data
the SRH, using a single SRH TLV. The different IOAM data fields packets is also known as In-situ OAM (IOAM). This section describes
iOAM functionality in SRv6 network.
The IOAM data is carried in SRH.TLV. This enables the IOAM mechanism
to build on the network programmability capability of SRv6. The
ability for an SRv6 endpoint to determine whether to
process or ignore some specific SRH TLVs is based on the SID
function. This enables collection of the IOAM information from the
intermediate endpoint nodes of choice. The nodes that are not
capable of supporting the IOAM functionality does not have to look or
process SRH TLV (i.e., such nodes can simply ignore the SRH IOAM
TLV).
3.1 IOAM Data Field Encapsulation in SRH
The SRv6 encapsulation header (SRH) is defined in [I-D.ietf-6man-
segment-routing-header]. IOAM data fields are carried in the SRH,
using a single pre-allocated SRH TLV. The different IOAM data fields
defined in [I-D.ietf-ippm-ioam-data] are added as sub-TLVs. defined in [I-D.ietf-ippm-ioam-data] are added as sub-TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRH-TLV-Type | LEN | RESERVED | | SRH-TLV-Type | LEN | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| IOAM-Type | IOAM HDR LEN | RESERVED | | | IOAM-Type | IOAM HDR LEN | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
! | O ! | O
skipping to change at page 5, line 5 skipping to change at page 5, line 12
IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in
4-octet units. 4-octet units.
RESERVED: 8-bit reserved field MUST be set to zero upon transmission RESERVED: 8-bit reserved field MUST be set to zero upon transmission
and ignored upon receipt. and ignored upon receipt.
IOAM Option and Data Space: IOAM option header and data is present IOAM Option and Data Space: IOAM option header and data is present
as defined by the IOAM-Type field, and is defined in Section 4 of as defined by the IOAM-Type field, and is defined in Section 4 of
[I-D.ietf-ippm-ioam-data]. [I-D.ietf-ippm-ioam-data].
The IOAM TLVs MAY change en route [I-D.ietf-ippm-ioam-data]. For the
IOAM TLVs carried in SRH that can change en route, the most
significant bit of the SRH-TLV-Type is set
[I-D.6man-segment-routing-header]. Furthermore, such IOAM TLV in SRH
is considered mutable for ICV computation, the Type Length, and
Variable Length Data is ignored for ICV Computation as defined in
[RFC4302].
4. Procedure 4. Procedure
This section summarizes the procedure for IOAM data encapsulation in This section summarizes the procedure for IOAM data encapsulation in
SRv6 SRH. The SR nodes implementing the IOAM functionality follows SRv6 SRH. The SR nodes implementing the IOAM functionality follows
the MTU and other considerations outlined in the MTU and other considerations outlined in
[I-D.6man-extension-header-insertion]. [I-D.6man-extension-header-insertion].
4.1. Ingress Node 4.1. Ingress Node
The ingress node of an SR domain or an SR Policy As part of the SRH encapsulation, the ingress node of an SR domain or
[I-D.spring-segment-routing-policy] may insert the IOAM TLV in the an SR Policy [I-D.ietf-spring-segment-routing-policy] MAY add the
SRH of the data packet. The ingress node may also insert the IOAM IOAM TLV in the SRH of the data packet. If an ingress node supports
data about the local information in the IOAM TLV in the SRH. When IOAM functionality and, based on a local configuration, wants to
IOAM data from the last node in the segment-list (Egress node) is collect IOAM data, it adds IOAM TLV in the SRH. Based on the size of
desired, the ingress uses an Ultimate Segment Pop (USP) SID at the the segment list (SL), the ingress node preallocates space in the
Egress node. IOAM TLV.
4.2. SR Segment Endpoint Node If IOAM data from the last node in the segment-list (Egress node) is
desired, the ingress uses an Ultimate Segment Pop (USP) SID
advertised by the Egress node.
The ingress node may also insert the IOAM data about the local
information in the IOAM TLV in the SRH at index 0 of the preallocated
IOAM TLV.
4.2. Intermediate SR Segment Endpoint Node
The SR segment endpoint node is any node receiving an IPv6 packet The SR segment endpoint node is any node receiving an IPv6 packet
where the destination address of that packet is a local SID or a where the destination address of that packet is a local SID. As part
local interface address. As part of the SR Header processing as of the SR Header processing as described in [I-D.ietf-6man-segment-
described in [I-D.6man-segment-routing-header] and routing-header] and [I-D.ietf-spring-srv6-network-programming], the
[I-D.spring-srv6-network-programming], the SR Segment Endpoint node SR Segment Endpoint node performs the following IOAM operations.
performs the following IOAM operations. The description borrows the
terminology used in [I-D.6man-segment-routing-header]. Specifically,
n refers to the number of segments encoded in the SRH, "Hdr Ext Len"
refers to the length of the SRH. The "SRH Header Len" is the length
of the SRH header, which is 8 octets
[I-D.6man-segment-routing-header].
The SR Segment Endpoint node compares the "Hdr Ext Len" of the SRH If an intermediate SR segment endpoint node is not capable of
with the length of the "segment-list" in the SRH. Specifically, if processing IOAM TLV, it simply ignores it. I.e., it does not have to
the SRH.Hdr_Ext_Len > n*16 + 8, the node looks for the presence of look or process SRH TLV.
the IOAM TLV in the SRH. If an IOAM TLV is present in the SRH and is
supported by the Segment Endpoint Node, the SR segment endpoint node If an intermediate SR segment endpoint node is capable of processing
MAY modify the IOAM TLV in SRH with local IOAM data as per IOAM draft IOAM TLV and the local SID supports IOAM data recording, it checks if
[I-D.ietf-ippm-ioam-data]. any SRH TLV is present in the packet using procedures defined in [I-
D.ietf-6man-segment-routing-header]. If the node finds IOAM TLV in
the SRH it finds the local index at which it is expected to record
the IOAM data. The local index is found using the SRH.SL field. The
node records the IOAM data at the desired preallocated space.
4.3. Egress Node 4.3. Egress Node
The Egress node is the last node in the segment-list of the SRH. When The Egress node is the last node in the segment-list of the SRH.
IOAM data from the Egress node is desired, a USP SID advertised by When IOAM data from the Egress node is desired, a USP SID advertised
the Egress node is used. by the Egress node is used by the Ingress node.
The processing of IOAM TLV at the Egress node is similar to the The processing of IOAM TLV at the Egress node is similar to the
processing of IOAM TLV at the SR Segment Endpoint Node. The only processing of IOAM TLV at the SR Segment Endpoint Node. The only
difference is that the Egress node also performs the functionality difference is that the Egress node may telemeter the IOAM data to an
required by the Egress node in an IOAM domain. E.g., the Egress node external entity.
may telemeter the IOAM data to a controller.
5. IANA Considerations 5. IANA Considerations
IANA is requested to allocate SRH TLV Type for IOAM TLV data fields IANA is requested to allocate a mutable SRH TLV Type for IOAM TLV data fields
under registry name "Segment Routing Header TLVs" requested by %[I- under registry name "Segment Routing Header TLVs" requested by [I-
D.6man-segment-routing-header]. D.6man-segment-routing-header].
+--------------+--------------------------+---------------+ +--------------+--------------------------+---------------+
| SRH TLV Type | Description | Reference | | SRH TLV Type | Description | Reference |
+--------------+--------------------------+---------------+ +--------------+--------------------------+---------------+
| TBA1 | TLV for IOAM Data Fields | This document | | TBA1 Greater | TLV for IOAM Data Fields | This document |
| than 128 | | |
+--------------+--------------------------+---------------+ +--------------+--------------------------+---------------+
6. Security Considerations 6. Security Considerations
The security considerations of SRv6 are discussed in The security considerations of SRv6 are discussed in
[I-D.spring-srv6-network-programming] and [I-D.spring-srv6-network-programming] and
[I-D.6man-segment-routing-header], and the security considerations of [I-D.6man-segment-routing-header], and the security considerations of
IOAM in general are discussed in [I-D.ietf-ippm-ioam-data]. IOAM in general are discussed in [I-D.ietf-ippm-ioam-data].
IOAM is considered a "per domain" feature, where one or several IOAM is considered a "per domain" feature, where one or several
 End of changes. 18 change blocks. 
53 lines changed or deleted 72 lines changed or added

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