idnits 2.17.1 draft-gandhi-mpls-ioam-sr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2021) is 1163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Gandhi, Ed. 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: August 22, 2021 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 February 18, 2021 12 MPLS Data Plane Encapsulation for In-situ OAM Data 13 draft-gandhi-mpls-ioam-sr-06 15 Abstract 17 In-situ Operations, Administration, and Maintenance (IOAM) records 18 operational and telemetry information in the data packet while the 19 packet traverses a path between two nodes in the network. This 20 document defines how IOAM data fields are transported with MPLS data 21 plane encapsulation using new Generic Associated Channel (G-ACh). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 22, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 61 3. MPLS Extensions for IOAM Data Fields . . . . . . . . . . . . 4 62 3.1. IOAM Generic Associated Channel . . . . . . . . . . . . . 4 63 3.2. IOAM Indicator Labels . . . . . . . . . . . . . . . . . . 5 64 4. Edge-to-Edge IOAM . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Edge-to-Edge IOAM Indicator Label . . . . . . . . . . . . 5 66 4.2. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . 6 67 4.3. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . 7 68 5. Hop-by-Hop IOAM . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Hop-by-Hop IOAM Indicator Label . . . . . . . . . . . . . 7 70 5.2. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . 8 71 5.3. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . 8 72 6. Considerations for IOAM Indicator Label . . . . . . . . . . . 9 73 6.1. Considerations for ECMP . . . . . . . . . . . . . . . . . 9 74 6.2. Node Capability . . . . . . . . . . . . . . . . . . . . . 9 75 6.3. MSD Considerations . . . . . . . . . . . . . . . . . . . 9 76 6.4. Nested MPLS Encapsulation . . . . . . . . . . . . . . . . 10 77 7. MPLS Encapsulation with Control Word and Another G-ACh for 78 IOAM Data Fields . . . . . . . . . . . . . . . . . . . . . . 10 79 8. Example MPLS Encapsulations . . . . . . . . . . . . . . . . . 12 80 8.1. Example SR-MPLS Encapsulation with IOAM . . . . . . . . . 12 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 In-situ Operations, Administration, and Maintenance (IOAM) records 93 operational and telemetry information within the packet while the 94 packet traverses a particular network domain. The term "in-situ" 95 refers to the fact that the IOAM data fields are added to the data 96 packets rather than being sent within the probe packets specifically 97 dedicated to OAM or Performance Measurement (PM). The IOAM data 98 fields are defined in [I-D.ietf-ippm-ioam-data], and can be used for 99 various use-cases for OAM and PM. The IOAM data fields are further 100 updated in [I-D.ietf-ippm-ioam-direct-export] for direct export use- 101 cases and in [I-D.ietf-ippm-ioam-flags] for Loopback and Active 102 flags. 104 This document defines how IOAM data fields are transported with MPLS 105 data plane encapsulations using new Generic Associated Channel 106 (G-ACh). 108 2. Conventions 110 2.1. Requirement Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119] [RFC8174] 115 when, and only when, they appear in all capitals, as shown here. 117 2.2. Abbreviations 119 Abbreviations used in this document: 121 ECMP Equal Cost Multi-Path 123 E2E Edge-To-Edge 125 G-ACh Generic Associated Channel 127 HbH Hop-by-Hop 129 IOAM In-situ Operations, Administration, and Maintenance 131 MPLS Multiprotocol Label Switching 133 OAM Operations, Administration, and Maintenance 135 PM Performance Measurement 137 POT Proof-of-Transit 139 PSID Path Segment Identifier 141 PW PseudoWire 143 SR Segment Routing 144 SR-MPLS Segment Routing with MPLS Data plane 146 3. MPLS Extensions for IOAM Data Fields 148 3.1. IOAM Generic Associated Channel 150 The IOAM data fields are defined in [I-D.ietf-ippm-ioam-data]. The 151 IOAM data fields are carried in the MPLS header as shown in Figure 1. 152 More than one trace options can be present in the IOAM data fields. 153 G-ACh [RFC5586] provides a mechanism to transport OAM and other 154 control messages over MPLS data plane. The IOAM G-ACh header 155 [RFC5586] with new IOAM G-ACh type is added immediately after the 156 MPLS label stack in the MPLS header as shown in Figure 1, before the 157 IOAM data fields. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 162 |0 0 0 1|Version| Reserved | IOAM G-ACh | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 164 | Reserved | Block Number | IOAM-OPT-Type |IOAM HDR Length| | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 166 | | O 167 | | A 168 ~ IOAM Option and Data Space ~ M 169 | | | 170 | | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 172 | | 173 | | 174 | Payload + Padding | 175 | | 176 | | 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: IOAM Generic Associated Channel with IOAM Data Fields 182 The IOAM data fields are encapsulated using the following fields in 183 the MPLS header: 185 IP Version Number 0001b: The first four octets are IP Version Field 186 part of a G-ACh header, as defined in [RFC5586]. 188 Version: The Version field is set to 0, as defined in [RFC4385]. 190 IOAM G-ACh: Generic Associated Channel (G-ACh) Type (value TBA3) for 191 IOAM [RFC5586]. 193 Reserved: Reserved Bits MUST be set to zero upon transmission and 194 ignored upon receipt. 196 Block Number: The Block Number can be used to aggregate the IOAM 197 data collected in data plane, e.g. compute measurement metrics for 198 each block of a flow. It is also used to correlate the IOAM data 199 on different nodes. 201 IOAM-OPT-Type: 8-bit field defining the IOAM Option type, as defined 202 in Section 8.1 of [I-D.ietf-ippm-ioam-data]. 204 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 205 4-octet units. 207 IOAM Option and Data Space: IOAM option header and data is present 208 as defined by the IOAM-OPT-Type field, and is defined in Section 5 209 of [I-D.ietf-ippm-ioam-data]. 211 3.2. IOAM Indicator Labels 213 An IOAM Indicator Label is used to indicate the presence of the IOAM 214 data fields in the MPLS header. There are two IOAM types defined in 215 this document: Edge-to-Edge (E2E) and Hop-by-Hop (HbH) IOAM. If only 216 edge nodes need to process IOAM data then E2E IOAM Indicator Label is 217 used so that intermediate nodes can ignore it. If both edge and 218 intermediate nodes need to process IOAM data then HbH IOAM Indicator 219 Label is used. Different IOAM Indicator Labels allow to optimize the 220 IOAM processing on intermediate nodes by checking if IOAM data fields 221 need to be processed. 223 4. Edge-to-Edge IOAM 225 4.1. Edge-to-Edge IOAM Indicator Label 227 The E2E IOAM Indicator Label is used to indicate the presence of the 228 E2E IOAM data fields in the MPLS header as shown in Figure 2. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Label(1) | TC |S| TTL | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 . . 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Label(n) | TC |S| TTL | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | E2E IOAM Indicator Label | TC |1| TTL | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Packet as shown in Figure 1 | 242 . . 243 +---------------------------------------------------------------+ 245 Figure 2: MPLS Encapsulation for E2E IOAM 247 The E2E IOAM data fields carry the Option-Type(s) that require 248 processing on the encapsulating and decapsulating nodes only. The 249 IOAM Option-Type carried can be IOAM Edge-to-Edge Option-Type 250 [I-D.ietf-ippm-ioam-data]. The E2E IOAM data fields SHOULD NOT carry 251 any IOAM Option-Type that require IOAM processing on the intermediate 252 nodes as it will not be processed by them. 254 4.2. Procedure for Edge-to-Edge IOAM 256 The E2E IOM procedure is summarized as following: 258 o The encapsulating node inserts the E2E IOAM Indicator Label and 259 one or more IOAM data fields in the MPLS header. 261 o The intermediate nodes do not process IOAM data fields. 263 o The decapsulating node "punts the timestamped copy" of the 264 received packet as is including the IOAM data fields when the node 265 recognizes the IOAM Indicator Label. The copy of the packet is 266 punted with receive timestamp to the slow path for IOAM data 267 fields processing. The receive timestamp is required by the 268 various E2E OAM use-cases, including streaming telemetry. Note 269 that it is not necessarily punted to the control-plane. 271 o The decapsulating node processes the IOAM data fields using the 272 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 273 IOAM processing is to export the data fields, send data fields via 274 streaming telemetry, etc. 276 o The decapsulating node also pops the IOAM Indicator Label and the 277 IOAM data fields from the received packet. The decapsulated 278 packet is forwarded downstream or terminated locally similar to 279 the regular data packets. 281 4.3. Edge-to-Edge IOAM Indicator Label Allocation 283 The E2E IOAM Indicator Label is used to indicate the presence of the 284 E2E IOAM data fields in the MPLS header. The E2E IOAM Indicator 285 Label can be allocated using one of the following three methods: 287 o Label assigned by IANA with value TBA1 from the Extended Special- 288 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 290 o Label allocated by a Controller from the global table of the 291 decapsulating node. The Controller provisions the label on both 292 encapsulating and decapsulating nodes. 294 o Label allocated by the decapsulating node and signalled or 295 advertised in the network. The signaling and/or advertisement 296 extension for this is outside the scope of this document. 298 5. Hop-by-Hop IOAM 300 5.1. Hop-by-Hop IOAM Indicator Label 302 The HbH IOAM Indicator Label is used to indicate the presence of the 303 HbH IOAM data fields in the MPLS header as shown in Figure 3. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Label(1) | TC |S| TTL | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 . . 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Label(n) | TC |S| TTL | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | HbH IOAM Indicator Label | TC |1| TTL | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Packet as shown in Figure 1 | 317 . . 318 +---------------------------------------------------------------+ 320 Figure 3: MPLS Encapsulation for HbH IOAM 322 The HbH IOAM data fields carry the Option-Type(s) that require 323 processing at the intermediate and/or encapsulating and decapsulating 324 nodes. The IOAM Option-Type carried can be IOAM Pre-allocated Trace 325 Option-Type, IOAM Incremental Trace Option-Type and IOAM Proof of 326 Transit (POT) Option-Type, as well as Edge-to-Edge Option-Type 327 [I-D.ietf-ippm-ioam-data]. 329 5.2. Procedure for Hop-by-Hop IOAM 331 The HbH IOAM procedure is summarized as following: 333 o The encapsulating node inserts the HbH IOAM Indicator Label and 334 one or more IOAM data fields in the MPLS header. 336 o The intermediate node enabled with HbH IOAM functions processes 337 the data packet including the IOAM data fields as defined in 338 [I-D.ietf-ippm-ioam-data] when the node recognizes the HbH IOAM 339 Indicator Label present in the MPLS header. The intermediate node 340 may 'punt the timestamped copy' of the received data packet 341 including the IOAM data fields as required by the IOAM data fields 342 processing. The copy of the packet is punted with receive 343 timestamp to the slow path for IOAM processing. 345 o The intermediate node forwards a copy of the processed data packet 346 downstream. 348 o The decapsulating node "punts the timestamped copy" of the 349 received data packet as is including the IOAM data fields when the 350 node recognizes the IOAM Indicator Label. The copy of the packet 351 is punted with receive timestamp to the slow path for IOAM data 352 fields processing. The receive timestamp is required by the 353 various E2E OAM use-cases, including streaming telemetry. Note 354 that it is not necessarily punted to the control-plane. 356 o The decapsulating node processes the IOAM data fields using the 357 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 358 IOAM processing is to export the data fields, send data fields via 359 streaming telemetry, etc. 361 o The decapsulating node also pops the IOAM Indicator Label and the 362 IOAM data fields from the received packet. The decapsulated 363 packet is forwarded downstream or terminated locally similar to 364 the regular data packets. 366 5.3. Hop-by-Hop IOAM Indicator Label Allocation 368 The HbH IOAM Indicator Label is used to indicate the presence of the 369 HbH IOAM data fields in the MPLS header. The HbH IOAM Indicator 370 Label can be allocated using one of the following three methods: 372 o Label assigned by IANA with value TBA2 from the Extended Special- 373 Purpose MPLS Values [I-D.ietf-mpls-spl-terminology]. 375 o Label allocated by a Controller from the network-wide global 376 table. The Controller provisions the labels on all nodes 377 participating in IOAM functions along the data traffic path. 379 o Labels allocated by the intermediate and decapsulating nodes and 380 signalled or advertised in the network. The signaling and/or 381 advertisement extension for this is outside the scope of this 382 document. 384 6. Considerations for IOAM Indicator Label 386 6.1. Considerations for ECMP 388 The encapsulating node needs to make sure the IOAM data fields do not 389 start with a well-known IP Version Number (e.g. 0x4 for IPv4 and 0x6 390 for IPv6) as that can alter the hashing function for ECMP that uses 391 the IP header. This is achieved by using the IOAM G-ACh with IP 392 Version Number 0001b after the MPLS label stack [RFC5586]. 394 Note that the hashing function for ECMP that uses the labels from the 395 MPLS header may now include the IOAM Indicator Label. 397 When entropy label [RFC6790] is used for hashing function for ECMP, 398 the procedure defined in this document does not alter the hashing 399 function. 401 6.2. Node Capability 403 The decapsulating node that has to pop the IOAM Indicator Label, data 404 fields, and perform the IOAM function may not be capable of 405 supporting it. The encapsulating node needs to know if the 406 decapsulating node can support the IOAM function. The signaling 407 extension for this capability exchange is outside the scope of this 408 document. 410 The intermediate node that is not capable of supporting the IOAM 411 functions defined in this document, can simply skip the IOAM 412 processing of the MPLS header. 414 6.3. MSD Considerations 416 The SR path computation needs to know the Maximum SID Depth (MSD) 417 that can be imposed at each node/link of a given SR path [RFC8664]. 418 This ensures that the SID stack depth of a computed path does not 419 exceed the number of SIDs the node is capable of imposing. The MSD 420 used for path computation MUST include the IOAM Indicator Label. 422 6.4. Nested MPLS Encapsulation 424 The data packets with IOAM data fields carry only one IOAM Indicator 425 Label in the MPLS header. Any intermediate node that adds additional 426 MPLS encapsulation in the MPLS header may further update the IOAM 427 data fields in the header without inserting another IOAM Indicator 428 Label. When a packet is received with a HbH IOAM Indicator Label, 429 the nested MPLS encapsulating node can add a HbH and/or E2E IOAM 430 Option-Type. However, when a packet is received with an E2E IOAM 431 Indicator Label, the nested MPLS encapsulating node SHOULD NOT add a 432 HbH IOAM Option-Type, as intermediate nodes will not process it. 434 7. MPLS Encapsulation with Control Word and Another G-ACh for IOAM Data 435 Fields 437 The IOAM data fields, including IOAM G-ACh header are added in the 438 MPLS encapsulation immediately after the MPLS header. Any Control 439 Word [RFC4385] or another G-ACh [RFC5586] MUST be added after the 440 IOAM data fields in the packet as shown in the Figure 4 and Figure 5, 441 respectively. This allows the intermediate nodes to easily access 442 the HbH IOAM data fields located immediately after the MPLS header. 443 The decapsulating node can remove the MPLS encapsulation including 444 the IOAM data fields and then process the Control Word or another 445 G-ACh following it. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | IOAM Indicator Label | TC |1| TTL | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 452 |0 0 0 1|Version| Reserved | IOAM G-ACh | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 454 | Reserved | Block Number | IOAM-OPT-Type |IOAM HDR Length| | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 456 | | O 457 | | A 458 ~ IOAM Option and Data Space ~ M 459 | | | 460 | | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 462 |0 0 0 0| Specified by PW Encapsulation [RFC4385] | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 | | 466 ~ Payload + Padding ~ 467 | | 468 | | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 4: Example MPLS Encapsulation with Generic PW Control Word 472 with IOAM 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IOAM Indicator Label | TC |1| TTL | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 479 |0 0 0 1|Version| Reserved | IOAM G-ACh | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 481 | Reserved | Block Number | IOAM-OPT-Type |IOAM HDR Length| | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 483 | | O 484 | | A 485 ~ IOAM Option and Data Space ~ M 486 | | | 487 | | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 489 |0 0 0 1|Version| Reserved | Channel Type | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | | 493 ~ Payload + Padding ~ 494 | | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 5: Example MPLS Encapsulation with Another G-ACh with IOAM 500 8. Example MPLS Encapsulations 502 8.1. Example SR-MPLS Encapsulation with IOAM 504 Segment Routing (SR) technology leverages the source routing paradigm 505 [RFC8660]. A node steers a packet through a controlled set of 506 instructions, called segments, by pre-pending the packet with an SR 507 header. In the SR with MPLS data plane (SR-MPLS), the SR header is 508 instantiated through a label stack. 510 An example of data packet with SR-MPLS encapsulation containing Path 511 Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] and E2E 512 IOAM data fields is shown in Figure 6. The PSID allows to identify 513 the path associated with the data traffic being monitored for IOAM on 514 the decapsulating node. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Label(1) | TC |S| TTL | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 . . 522 . . 523 . . 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Label(n) | TC |S| TTL | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | PSID | TC |S| TTL | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Extension Label (15) | TC |S| TTL | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | E2E IOAM Indicator Label TBA1 | TC |1| TTL | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Packet as shown in Figure 1 | 534 . . 535 +---------------------------------------------------------------+ 537 Figure 6: Example SR-MPLS Encapsulation with E2E IOAM Data Fields 539 9. Security Considerations 541 The security considerations of IOAM in general are discussed in 542 [I-D.ietf-ippm-ioam-data]. 544 IOAM is considered a "per domain" feature, where one or several 545 operators decide on leveraging and configuring IOAM according to 546 their needs. Still, operators need to properly secure the IOAM 547 domain to avoid malicious configuration and use, which could include 548 injecting malicious IOAM packets into a domain. 550 Routers that support G-ACh are subject to the same security 551 considerations as defined in [RFC4385] and [RFC5586]. 553 10. IANA Considerations 555 IANA maintains the "Special-Purpose Multiprotocol Label Switching 556 (MPLS) Label Values" registry (see ). IANA is requested to 558 allocate IOAM Indicator Label value from the "Extended Special- 559 Purpose MPLS Label Values" registry: 561 +--------+--------------------------+---------------+ 562 | Value | Description | Reference | 563 +--------+--------------------------+---------------+ 564 | TBA1 | E2E IOAM Indicator Label | This document | 565 +--------+--------------------------+---------------+ 566 | TBA2 | HbH IOAM Indicator Label | This document | 567 +--------+--------------------------+---------------+ 569 Table 1: IOAM Indicator Label Values 571 IANA maintains G-ACh Type Registry (see 572 ). IANA is requested to allocate a value for IOAM 574 G-ACh Type from "MPLS Generalized Associated Channel (G-ACh) Types 575 (including Pseudowire Associated Channel Types)" registry. 577 +-------+-----------------+---------------+ 578 | Value | Description | Reference | 579 +-------+-----------------+---------------+ 580 | TBA3 | IOAM G-ACh Type | This document | 581 +-------+-----------------+---------------+ 583 Table 2: IOAM G-ACh Type 585 11. References 587 11.1. Normative References 589 [I-D.ietf-ippm-ioam-data] 590 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 591 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 592 progress), November 2020. 594 [I-D.ietf-ippm-ioam-direct-export] 595 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 596 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 597 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 598 export-02 (work in progress), November 2020. 600 [I-D.ietf-ippm-ioam-flags] 601 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 602 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 603 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-03 604 (work in progress), October 2020. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 612 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 613 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 614 February 2006, . 616 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 617 "MPLS Generic Associated Channel", RFC 5586, 618 DOI 10.17487/RFC5586, June 2009, 619 . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 11.2. Informative References 627 [I-D.ietf-mpls-spl-terminology] 628 Andersson, L., Kompella, K., and A. Farrel, "Special 629 Purpose Label terminology", draft-ietf-mpls-spl- 630 terminology-06 (work in progress), January 2021. 632 [I-D.ietf-spring-mpls-path-segment] 633 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 634 "Path Segment in MPLS Based Segment Routing Network", 635 draft-ietf-spring-mpls-path-segment-03 (work in progress), 636 September 2020. 638 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 639 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 640 RFC 6790, DOI 10.17487/RFC6790, November 2012, 641 . 643 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 644 Decraene, B., Litkowski, S., and R. Shakir, "Segment 645 Routing with the MPLS Data Plane", RFC 8660, 646 DOI 10.17487/RFC8660, December 2019, 647 . 649 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 650 and J. Hardwick, "Path Computation Element Communication 651 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 652 DOI 10.17487/RFC8664, December 2019, 653 . 655 Acknowledgements 657 The authors would like to thank Patrick Khordoc, Shwetha Bhandari and 658 Vengada Prasad Govindan for the discussions on IOAM. The authors 659 would also like to thank Tarek Saad, Loa Andersson, Greg Mirsky, 660 Stewart Bryant, Xiao Min, and Cheng Li for providing many useful 661 comments. The authors would also like to thank Mach Chen, Andrew 662 Malis, Matthew Bocci, and Nick Delregno for the MPLS-RT reviews. 664 Contributors 666 Sagar Soni 667 Cisco Systems, Inc. 669 Email: sagsoni@cisco.com 671 Authors' Addresses 673 Rakesh Gandhi (editor) 674 Cisco Systems, Inc. 675 Canada 677 Email: rgandhi@cisco.com 679 Zafar Ali 680 Cisco Systems, Inc. 682 Email: zali@cisco.com 684 Clarence Filsfils 685 Cisco Systems, Inc. 686 Belgium 688 Email: cf@cisco.com 690 Frank Brockners 691 Cisco Systems, Inc. 692 Hansaallee 249, 3rd Floor 693 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 694 Germany 696 Email: fbrockne@cisco.com 697 Bin Wen 698 Comcast 700 Email: Bin_Wen@cable.comcast.com 702 Voitek Kozak 703 Comcast 705 Email: Voitek_Kozak@comcast.com