idnits 2.17.1 draft-gandhi-mpls-ioam-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5586, but the abstract doesn't seem to directly say this. It does mention RFC5586 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 March 2022) is 757 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 (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == Outdated reference: A later version (-05) exists of draft-decraene-mpls-slid-encoded-entropy-label-id-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 Updates: 5586 (if approved) F. Brockners 5 Intended status: Standards Track Cisco Systems, Inc. 6 Expires: 3 September 2022 B. Wen 7 Comcast 8 B. Decraene 9 Orange 10 V. Kozak 11 Comcast 12 2 March 2022 14 MPLS Data Plane Encapsulation for In-situ OAM Data 15 draft-gandhi-mpls-ioam-04 17 Abstract 19 In-situ Operations, Administration, and Maintenance (IOAM) is used 20 for recording and collecting operational and telemetry information 21 while the packet traverses a path between two points in the network. 22 This document defines how IOAM data fields are transported with MPLS 23 data plane encapsulation using new Generic Associated Channel (G-ACh) 24 and updates the RFC 5586. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 3 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 63 3. MPLS Extensions for IOAM Data Fields . . . . . . . . . . . . 4 64 3.1. IOAM Generic Associated Channel . . . . . . . . . . . . . 4 65 3.2. IOAM Indicators . . . . . . . . . . . . . . . . . . . . . 6 66 4. Edge-to-Edge IOAM . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. IOAM Indicator . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . 7 69 5. Hop-By-Hop IOAM . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Hop-By-Hop Indicator . . . . . . . . . . . . . . . . . . 8 71 5.2. Procedure for Hop-By-Hop IOAM . . . . . . . . . . . . . . 8 72 6. Considerations for IOAM . . . . . . . . . . . . . . . . . . . 9 73 6.1. Considerations for ECMP . . . . . . . . . . . . . . . . . 9 74 6.2. Node Capability . . . . . . . . . . . . . . . . . . . . . 9 75 6.3. Nested MPLS Encapsulation . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. MPLS Encapsulation with Control Word and Another G-ACh for 80 IOAM Data Fields . . . . . . . . . . . . . . . . . . . . 10 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 In-situ Operations, Administration, and Maintenance (IOAM) is used 90 for recording and collecting operational and telemetry information 91 while the packet traverses a path between two points in the network. 92 The term "in-situ" refers to the fact that the IOAM data fields are 93 added to the data packets rather than being sent within the probe 94 packets specifically dedicated to OAM. The IOAM data fields are 95 defined in [I-D.ietf-ippm-ioam-data]. The IOAM data fields are 96 further updated in [I-D.ietf-ippm-ioam-direct-export] for direct 97 export use-cases. 99 This document defines how IOAM data fields are transported with MPLS 100 data plane encapsulations using new Generic Associated Channel 101 (G-ACh) and updates the [RFC5586]. 103 2. Conventions 105 2.1. Requirement Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119] [RFC8174] 110 when, and only when, they appear in all capitals, as shown here. 112 2.2. Abbreviations 114 Abbreviations used in this document: 116 IOI IOAM Indicator 118 ECMP Equal Cost Multi-Path 120 E2E Edge-To-Edge 122 EL Entropy Label 124 ELI Entropy Label Indicator 126 ELC Entropy Label Control 128 G-ACh Generic Associated Channel 130 HBH Hop-By-Hop 132 HBI Hop-By-Hop Indicator 134 IOAM In-situ Operations, Administration, and Maintenance 135 MPLS Multiprotocol Label Switching 137 OAM Operations, Administration, and Maintenance 139 POT Proof-of-Transit 141 PW PseudoWire 143 3. MPLS Extensions for IOAM Data Fields 145 3.1. IOAM Generic Associated Channel 147 The IOAM header is added containing different IOAM-Data-Fields in the 148 MPLS header as shown in Figure 1. The IOAM-Data-Fields MUST follow 149 the definitions corresponding to IOAM-Option-Types (e.g. see 150 Section 5 of [I-D.ietf-ippm-ioam-data] and Section 3.2 of 151 [I-D.ietf-ippm-ioam-direct-export]). More than one trace options can 152 be present in the IOAM-Data-Fields. 154 G-ACh [RFC5586] provides a mechanism to transport OAM and other 155 control messages over MPLS data plane. The IOAM G-ACh header 156 [RFC5586] with new IOAM G-ACh type MUST be added immediately after 157 the MPLS label stack in the MPLS header as shown in Figure 1, before 158 the IOAM-Data-Fields. The G-ACh label (GAL) [RFC5586] MUST NOT be 159 added in the MPLS label stack. 161 This document updates the following paragraph in Section 2.1 of 162 [RFC5586]: "The G-ACh MUST NOT be used to transport user traffic" to 163 "The G-ACh MAY be used with user traffic to transport OAM 164 information". 166 Note that the G-ACh is not really used to transport the user traffic 167 in this document but to transport the IOAM-Data-Fields with the user 168 traffic. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 173 |0 0 0 1|Version| Length | IOAM G-ACh | | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 175 | IOAM-OPT-Type | IOAM HDR Len | Block Number | Reserved | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 177 | | O 178 | | A 179 ~ IOAM Option and Data Space ~ M 180 | | | 181 | | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 183 | | 184 | | 185 | Optional Payload + Padding | 186 | | 187 | | 188 | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: IOAM Generic Associated Channel with IOAM Data Fields 193 The IOAM-Data-Fields are encapsulated using the following fields in 194 the MPLS header: 196 IP Version Number 0001b: The first four octets are IP Version Field 197 part of a G-ACh header, as defined in [RFC5586]. 199 Version: The Version field is set to 0, as defined in [RFC4385]. 201 Length: Length of IOAM G-ACh data in 4-octet units. Note that this 202 field is marked as Reserved in [RFC5586] and is updated for the new 203 IOAM G-ACh type by this document. 205 IOAM G-ACh: Generic Associated Channel (G-ACh) Type (value TBA1) for 206 IOAM [RFC5586]. 208 Reserved: Reserved Bits MUST be set to zero upon transmission and 209 ignored upon receipt. 211 Block Number: The Block Number can be used to aggregate the IOAM 212 data collected in data plane, e.g. to compute measurement metrics 213 for each block of a data flow. It is also used to correlate the 214 IOAM data on different nodes. 216 IOAM-OPT-Type: 8-bit field defining the IOAM Option type, as defined 217 in the "IOAM Option-Type Registry" specified in 218 [I-D.ietf-ippm-ioam-data]. 220 IOAM HDR Length: 8-bit unsigned integer. Length of the IOAM Header 221 in 4-octet units. 223 IOAM Option and Data Space: IOAM-Data-Fields as specified by the 224 IOAM-OPT-Type field. IOAM-Data-Fields are defined corresponding to 225 the IOAM-Option-Type (e.g. see Section 5 of 226 [I-D.ietf-ippm-ioam-data] and Section 3.2 of 227 [I-D.ietf-ippm-ioam-direct-export]. 229 3.2. IOAM Indicators 231 An IOAM Indicator MUST be used to indicate the presence of the IOAM- 232 Data-Fields in the MPLS header. If both edge and intermediate nodes 233 need to process IOAM data then both IOAM Indicator and HBH Indicator 234 MUST be used. The HBH Indicator allows to optimize the IOAM 235 processing on intermediate nodes and avoids the need to check all 236 IOAM-Data-Fields. 238 A flag called IOI (IOAM Indicator) in the TTL of the X-Label is 239 defined in this document to indicate the presence of IOAM. A flag 240 called HBI (Hop-By-Hop Indicator) in the TTL of the X-Label is 241 defined to indicate that HBH processing is required. The bit 242 positions of these flags in the TTL field can be user-defined, 243 consistently in the network. Alternatively, the bit positions of 244 these flag can be allocated by IANA. 246 The X-Label can be a Special Purpose Label (value TBA1) assigned by 247 IANA or a Network Programming Label (NPL) provisioned by a user 248 [I-D.jags-mpls-ext-hdr] or an Entropy Label 249 [I-D.decraene-mpls-slid-encoded-entropy-label-id]. 251 4. Edge-to-Edge IOAM 253 4.1. IOAM Indicator 255 The IOAM Indicator is used to indicate the presence of the IOAM-Data- 256 Fields in the MPLS header as shown in Figure 2. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Label | TC |S| TTL | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 . . 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | X-Label | TC |1| TTL(IOI) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Packet as shown in Figure 1 | 268 . . 269 +---------------------------------------------------------------+ 271 Figure 2: Example MPLS Encapsulation for IOAM 273 The E2E IOAM-Data-Fields carry the Option-Type(s) that require 274 processing on the encapsulating and decapsulating nodes only. The 275 IOAM Option-Type carried can be IOAM Edge-to-Edge Option-Type 276 [I-D.ietf-ippm-ioam-data]. The E2E IOAM-Data-Fields SHOULD NOT carry 277 any IOAM Option-Type that require IOAM processing on the intermediate 278 nodes as it will not be processed by them. 280 4.2. Procedure for Edge-to-Edge IOAM 282 The E2E IOM procedure is summarized as following: 284 * The encapsulating node inserts the X-Label with the IOAM Indicator 285 (Flag IOI) below the label whose FEC is the end (decapsulating) 286 node and one or more IOAM-Data-Fields in the MPLS header. 288 * The intermediate nodes do not process IOAM-Data-Fields. 290 * The penultimate node MUST NOT remove the MPLS header. This is 291 ensured by the encapsulating node by adding required MPLS header. 293 * The decapsulating node MAY punt a copy of the packet with the 294 receive timestamp to the slow path for IOAM-Data-Fields processing 295 when the node recognizes the IOAM Indicator. The receive 296 timestamp is required by the various E2E OAM use-cases, including 297 streaming telemetry. Note that the packet is not necessarily 298 punted to the control-plane. 300 * The decapsulating node processes the IOAM-Data-Fields using the 301 procedures defined in [I-D.ietf-ippm-ioam-data]. An example of 302 IOAM processing is to export the IOAM-Data-Fields, send IOAM-Data- 303 Fields via streaming telemetry, etc. 305 * The decapsulating node MUST remove the IOAM-Data-Fields from the 306 received packet. The decapsulated packet is forwarded downstream 307 or terminated locally similar to the regular IOAM-Data-Fields. 309 5. Hop-By-Hop IOAM 311 5.1. Hop-By-Hop Indicator 313 The IOAM Indicator (Flag IOI) along with Hop-By-Hop Indicator (Flag 314 HBI) are used to indicate the presence of the HBH IOAM-Data-Fields in 315 the MPLS header as shown in Figure 3. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Label | TC |S| TTL | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | X-Label | TC |1| TTL(IOI, HBI) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Packet as shown in Figure 1 | 327 . . 328 +---------------------------------------------------------------+ 330 Figure 3: Example MPLS Encapsulation for HBH IOAM 332 The HBH IOAM-Data-Fields carry the Option-Type(s) that require 333 processing at the intermediate and/or encapsulating and decapsulating 334 nodes. The IOAM Option-Type carried can be IOAM Pre-allocated Trace 335 Option-Type, IOAM Incremental Trace Option-Type and IOAM Proof of 336 Transit (POT) Option-Type, as well as Edge-to-Edge Option-Type 337 [I-D.ietf-ippm-ioam-data]. 339 5.2. Procedure for Hop-By-Hop IOAM 341 The HBH IOAM procedure is summarized as following: 343 * The encapsulating node inserts the X-Label with the IOAM Indicator 344 (Flag IOI) and HBH Indicator (Flag HBI) below the label whose FEC 345 is the end (decapsulating) node and one or more IOAM-Data-Fields 346 in the MPLS header. 348 * The intermediate node enabled with HBH IOAM function processes the 349 data packet including the IOAM-Data-Fields as defined in 350 [I-D.ietf-ippm-ioam-data] when the node recognizes the HBH 351 Indicator in the MPLS header. 353 * The intermediate node MAY punt a copy of the packet with the 354 receive timestamp to the slow path for IOAM-Data-Fields processing 355 when the node recognizes the HBH Indicator. The receive timestamp 356 is required by the various HBH OAM use-cases, including streaming 357 telemetry. Note that the packet is not necessarily punted to the 358 control-plane. 360 * The intermediate node forwards a copy of the processed data packet 361 downstream. 363 * The penultimate node MUST NOT remove the MPLS header. This is 364 ensured by the encapsulating node by adding required MPLS header. 366 * The processing on the decapsulating node is same as E2E case. 368 6. Considerations for IOAM 370 6.1. Considerations for ECMP 372 The encapsulating node needs to make sure the IOAM-Data-Fields do not 373 start with a well-known IP Version Number (e.g. 0x4 for IPv4 and 0x6 374 for IPv6) as that can alter the hashing function for ECMP that uses 375 the IP header. This is achieved by using the IOAM G-ACh with IP 376 Version Number 0001b after the MPLS label stack [RFC5586]. 378 When entropy label [RFC6790] is used for hashing function for ECMP, 379 the procedure defined in this document does not alter the ECMP 380 behaviour. 382 6.2. Node Capability 384 The decapsulating node that has to remove the IOAM-Data-Fields and 385 perform the IOAM function may not be capable of supporting it. The 386 encapsulating node needs to know if the decapsulating node can 387 support the IOAM function. The signaling extension for this 388 capability exchange is outside the scope of this document. 390 The intermediate node that is not capable of supporting the IOAM 391 functions defined in this document, can simply skip the IOAM 392 processing. 394 6.3. Nested MPLS Encapsulation 396 When a packet is received with IOAM, the nested MPLS encapsulating 397 node that supports a different IOAM, the node MUST add a new X-Label 398 with the supported IOAM as part of the new MPLS encapsulation. 400 7. Security Considerations 402 The security considerations of IOAM in general are discussed in 403 [I-D.ietf-ippm-ioam-data] and apply to the procedure defined in this 404 document. 406 IOAM is considered a "per domain" feature, where one or several 407 operators decide on configuring IOAM according to their needs. IOAM 408 is intended for deployment in limited domains [RFC8799]. As such, it 409 assumes that a node involved in IOAM operation has previously 410 verified the integrity of the path. Still, operators need to 411 properly secure the IOAM domain to avoid malicious configuration and 412 use, which could include injecting malicious IOAM packets into the 413 domain. 415 Routers that support G-ACh are subject to the same security 416 considerations as defined in [RFC4385] and [RFC5586]. 418 8. IANA Considerations 420 IANA maintains G-ACh Type Registry (see 421 https://www.iana.org/assignments/g-ach-parameters/g-ach- 422 parameters.xhtml). IANA is requested to allocate a value for IOAM 423 G-ACh Type from "MPLS Generalized Associated Channel (G-ACh) Types 424 (including Pseudowire Associated Channel Types)" registry. 426 +=======+=================+===============+ 427 | Value | Description | Reference | 428 +=======+=================+===============+ 429 | TBA1 | IOAM G-ACh Type | This document | 430 +-------+-----------------+---------------+ 432 Table 1: IOAM G-ACh Type 434 9. Appendix 436 9.1. MPLS Encapsulation with Control Word and Another G-ACh for IOAM 437 Data Fields 439 The IOAM-Data-Fields, including IOAM G-ACh header are added in the 440 MPLS encapsulation immediately after the MPLS header. Any Control 441 Word [RFC4385] or another G-ACh [RFC5586] MUST be added after the 442 IOAM-Data-Fields in the packet as shown in the Figure 6 and Figure 7, 443 respectively. This allows the intermediate nodes to easily access 444 the HBH IOAM-Data-Fields located immediately after the MPLS header. 445 The decapsulating node can remove the MPLS encapsulation including 446 the IOAM-Data-Fields and then process the Control Word or another 447 G-ACh following it. The subsequent G-ACh and Control Word are 448 located through the use of the "Length" field in the IOAM G-ACh. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | X-Label | TC |1| TTL(IOI, HBI) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |0 0 0 1|Version| Length | IOAM G-ACh | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 457 | IOAM-OPT-Type | IOAM HDR Len | Block Number | Reserved | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 459 | | O 460 | | A 461 ~ IOAM Option and Data Space ~ M 462 | | | 463 | | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 465 |0 0 0 0| Specified by PW Encapsulation [RFC4385] | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | | 468 | | 469 ~ Payload + Padding ~ 470 | | 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 4: Example MPLS Encapsulation with Generic PW Control Word 475 with HBH IOAM 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | X-Label | TC |1| TTL(IOI, HBI) | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |0 0 0 1|Version| Length | IOAM G-ACh | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 484 | IOAM-OPT-Type | IOAM HDR Len | Block Number | Reserved | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 486 | | O 487 | | A 488 ~ IOAM Option and Data Space ~ M 489 | | | 490 | | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 492 |0 0 0 1|Version| Reserved | Channel Type | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 | | 496 ~ Payload + Padding ~ 497 | | 498 | | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 5: Example MPLS Encapsulation with Another G-ACh with HBH IOAM 503 10. References 505 10.1. Normative References 507 [I-D.ietf-ippm-ioam-data] 508 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 509 for In-situ OAM", Work in Progress, Internet-Draft, draft- 510 ietf-ippm-ioam-data-17, 13 December 2021, 511 . 514 [I-D.ietf-ippm-ioam-direct-export] 515 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 516 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 517 OAM Direct Exporting", Work in Progress, Internet-Draft, 518 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 519 . 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 528 "MPLS Generic Associated Channel", RFC 5586, 529 DOI 10.17487/RFC5586, June 2009, 530 . 532 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 533 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 534 RFC 6790, DOI 10.17487/RFC6790, November 2012, 535 . 537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 539 May 2017, . 541 10.2. Informative References 543 [I-D.decraene-mpls-slid-encoded-entropy-label-id] 544 Decraene, B., Filsfils, C., Henderickx, W., Saad, T., 545 Beeram, V. P., and L. Jalil, "Using Entropy Label for 546 Network Slice Identification in MPLS networks.", Work in 547 Progress, Internet-Draft, draft-decraene-mpls-slid- 548 encoded-entropy-label-id-03, 11 February 2022, 549 . 552 [I-D.jags-mpls-ext-hdr] 553 Rajamanickam, J., Gandhi, R., Bhattacharya, J., Decraene, 554 B., Zigler, R., Cheng, W., and L. Jalil, "MPLS Extension 555 Header Encodings Using Entropy Label", Work in Progress, 556 Internet-Draft, draft-jags-mpls-ext-hdr-00, 2 March 2022, 557 . 560 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 561 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 562 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 563 February 2006, . 565 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 566 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 567 . 569 Acknowledgements 571 The authors would like to thank Patrick Khordoc, Sagar Soni, Shwetha 572 Bhandari, Clarence Filsfils, and Vengada Prasad Govindan for the 573 discussions on IOAM. The authors would also like to thank Tarek 574 Saad, Loa Andersson, Greg Mirsky, Stewart Bryant, Xiao Min, and Cheng 575 Li for providing many useful comments. The authors would also like 576 to thank Mach Chen, Andrew Malis, Matthew Bocci, and Nick Delregno 577 for the MPLS-RT reviews. 579 Authors' Addresses 581 Rakesh Gandhi (editor) 582 Cisco Systems, Inc. 583 Canada 584 Email: rgandhi@cisco.com 586 Zafar Ali 587 Cisco Systems, Inc. 588 Email: zali@cisco.com 590 Frank Brockners 591 Cisco Systems, Inc. 592 Hansaallee 249, 3rd Floor 593 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 594 Germany 595 Email: fbrockne@cisco.com 597 Bin Wen 598 Comcast 599 Email: Bin_Wen@cable.comcast.com 601 Bruno Decraene 602 Orange 603 Email: bruno.decraene@orange.com 605 Voitek Kozak 606 Comcast 607 Email: Voitek_Kozak@comcast.com