idnits 2.17.1 draft-gandhi-mpls-ioam-sr-01.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 (December 6, 2019) is 1575 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: June 8, 2020 F. Brockners 6 Cisco Systems, Inc. 7 B. Wen 8 V. Kozak 9 Comcast 10 December 6, 2019 12 Segment Routing with MPLS Data Plane Encapsulation 13 for In-situ OAM Data 14 draft-gandhi-mpls-ioam-sr-01 16 Abstract 18 In-situ Operations, Administration, and Maintenance (IOAM) records 19 operational and telemetry information in the data packet while the 20 packet traverses a path between two nodes in the network. Segment 21 Routing (SR) technology leverages the source routing paradigm. This 22 document defines how IOAM data fields are transported using the 23 Segment Routing with MPLS data plane (SR-MPLS) encapsulation. The 24 procedures defined are also equally applicable to all other MPLS data 25 plane encapsulations. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified 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. IOAM Data Field Encapsulation in MPLS Header . . . . . . . . . 3 64 3.1. Indicator Labels . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Data Packets with SR-MPLS Header . . . . . . . . . . . . . 6 66 4. Procedure for Edge-to-Edge IOAM . . . . . . . . . . . . . . . 6 67 4.1. Edge-to-Edge IOAM Indicator Label Allocation . . . . . . . 7 68 5. Procedure for Hop-by-Hop IOAM . . . . . . . . . . . . . . . . 7 69 5.1. Hop-by-Hop IOAM Indicator Label Allocation . . . . . . . . 8 70 6. Considerations for ECMP . . . . . . . . . . . . . . . . . . . 8 71 7. Node Capability . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 11.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 In-situ Operations, Administration, and Maintenance (IOAM) records 84 operational and telemetry information within the packet while the 85 packet traverses a particular network domain. The term "in-situ" 86 refers to the fact that the IOAM data fields are added to the data 87 packets rather than being sent within the probe packets specifically 88 dedicated to OAM or Performance Measurement (PM). The IOAM data 89 fields are defined in [I-D.ippm-ioam-data], and can be used for 90 various use-cases for OAM and PM. The IOAM data fields are further 91 updated in [I-D.ippm-direct-export] for direct export use-cases and 92 in [I-D.ippm-ioam-flags] for loopback, active measurements, etc. 94 Segment Routing (SR) technology leverages the source routing paradigm 95 [RFC8660]. A node steers a packet through a controlled set of 96 instructions, called segments, by pre-pending the packet with an SR 97 header. In the MPLS data plane, the SR header is instantiated 98 through a label stack. 100 This document defines how IOAM data fields are transported using the 101 SR with MPLS data plane (SR-MPLS) encapsulation. The procedures 102 defined are also equally applicable to all other MPLS data plane 103 encapsulations. 105 2. Conventions 107 2.1. Requirement Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119] [RFC8174] 112 when, and only when, they appear in all capitals, as shown here. 114 2.2. Abbreviations 116 Abbreviations used in this document: 118 ECMP Equal Cost Multi-Path 120 IOAM In-situ Operations, Administration, and Maintenance 122 MPLS Multiprotocol Label Switching 124 OAM Operations, Administration, and Maintenance 126 PM Performance Measurement 128 POT Proof-of-Transit 130 PSID Path Segment Identifier 132 SR Segment Routing 134 SR-MPLS Segment Routing with MPLS Data plane 136 3. IOAM Data Field Encapsulation in MPLS Header 137 The IOAM data fields defined in [I-D.ippm-ioam-data] are used. IOAM 138 data fields are carried in the MPLS header as shown in Figure 1 and 139 Figure 2. More than one trace options can be present in the IOAM 140 data fields. The Indicator Label is added at the bottom of the MPLS 141 label stack (S flag set to 1) to indicate the presence of the IOAM 142 data field(s) in the MPLS header. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | IOAM Indicator Label | TC |1| TTL | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 149 | IOAM-Type | IOAM HDR LEN | RESERVED | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 151 | | O 152 | | A 153 ~ IOAM Option and Data Space ~ M 154 | | | 155 | | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 157 | | 158 | | 159 | Payload + Padding (L2/L3/ESP/...) | 160 | | 161 | | 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: IOAM Encapsulation in MPLS Header 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | IOAM and Flow Indicator Label | TC |1| TTL | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |0 0 0 0| Flow label | Block Number | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 174 | IOAM-Type | IOAM HDR LEN | RESERVED | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 176 | | O 177 | | A 178 ~ IOAM Option and Data Space ~ M 179 | | | 180 | | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 182 | | 183 | | 184 | Payload + Padding (L2/L3/ESP/...) | 185 | | 186 | | 187 | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 2: IOAM Encapsulation with Flow Label in MPLS Header 192 IOAM Indicator Label (IIL) and IOAM and Flow Indicator Label (IFIL) 193 used are defined in this document. 195 The fields related to the encapsulation of IOAM data fields in the 196 MPLS header are defined as follows: 198 IOAM-Type: 8-bit field defining the IOAM Option type, as defined in 199 Section 7.2 of [I-D.ippm-ioam-data]. 201 IOAM HDR LEN: 8-bit unsigned integer. Length of the IOAM HDR in 202 4-octet units. 204 RESERVED: 8-bit reserved field MUST be set to zero upon 205 transmission and ignored upon receipt. 207 IOAM Option and Data Space: IOAM option header and data is present 208 as defined by the IOAM-Type field, and is defined in Section 4 of 209 [I-D.ippm-ioam-data]. 211 3.1. Indicator Labels 213 IOAM Indicator Label (value TBA1 or TBA3) and IOAM and Flow Indicator 214 Label (value TBA2 or TBA4) are used to indicate the presence of the 215 IOAM data field in the MPLS header. 217 The IOAM and Flow Indicator Label (value TBA2 or TBA4) is used to 218 carry a second label underneath with protocol value 0000b, 20-bit 219 Flow Label and 8-bit Block Number. 221 o The protocol value 0000b allows to avoid incorrect IP header based 222 hashing over ECMP paths that uses the value 0x4 (for IPv4) and 223 value 0x6 (for IPv6) [RFC4928]. 225 o The Flow Label identifies the traffic flow that can be used for 226 IOAM purpose, monitoring a specific traffic flow for latency. 228 o The Block Number can be used to aggregate the IOAM data collected 229 in data plane, e.g. compute measurement metrics for each block of 230 a flow. 232 3.2. Data Packets with SR-MPLS Header 234 An example of data packet carrying the SR-MPLS header with Path 235 Segment Identifier (PSID) [I-D.spring-mpls-path-segment] with IOAM 236 encapsulation is shown in Figure 3. The Path Segment Identifier 237 allows to identify the associated data traffic path (e.g. SR Policy) 238 on the egress node being monitored for IOAM. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Label(1) | TC |S| TTL | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 . . 246 . . 247 . . 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Label(n) | TC |S| TTL | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | PSID | TC |S| TTL | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Packet as shown in Figure 1 or Figure 2 | 254 . . 255 +---------------------------------------------------------------+ 257 Figure 3: Data Packet with SR-MPLS Header 259 The data packets with IOAM data fields carry only one Indicator Label 260 in the MPLS header. Any intermediate node that adds additional MPLS 261 encapsulation in the MPLS header may further update the IOAM data 262 fields in the header without inserting another Indicator Label. 264 4. Procedure for Edge-to-Edge IOAM 266 The Edge-to-Edge (E2E) IOAM includes IOAM Option-Type as Edge-to-Edge 267 Option-Type [I-D.ippm-ioam-data]. This section summarizes the 268 procedure for data encapsulation and decapsulation for Edge-to-Edge 269 IOAM in MPLS header. 271 o The encapsulating node inserts the IOAM Indicator Label or IOAM 272 Flow Indicator Label with Flow Label and one or more IOAM data 273 field(s) in the MPLS header. The procedure to generate the Flow 274 Label is outside the scope of this document. 276 o The decapsulating node "forwards and punts the timestamped copy" 277 of the data packet including IOAM data fields when the node 278 recognizes the IOAM Indicator Label and IOAM Flow Indicator Label. 279 The copy of the data packet is punted to the slow path for OAM 280 processing and is not necessarily punted to the control-plane. 281 The receive timestamp is required by various E2E OAM use-cases. 283 o The decapsulating node processes the IOAM data field(s) using the 284 procedures defined in [I-D.ippm-ioam-data]. An example of IOAM 285 processing may be to export the data fields, send data fields via 286 Telemetry, etc. 288 o The decapsulating node also pops the Indicator Label and the IOAM 289 data fields from the MPLS header. 291 4.1. Edge-to-Edge IOAM Indicator Label Allocation 293 IOAM Indicator Label (value TBA1) and IOAM and Flow Indicator Label 294 (value TBA2) are used to indicate the presence of the E2E IOAM data 295 field in the MPLS header. The E2E IOAM Indicator Label and IOAM and 296 Flow Indicator Label can be allocated using one of the following 297 methods: 299 o Labels assigned by IANA with value TBA1 and TBA2 from the Extended 300 Special-Purpose MPLS Values [I-D.mpls-spl-terminology]. 302 o Labels allocated by a Controller from the global table of the 303 decapsulating node. The Controller provisions the label on both 304 encapsulating and decapsulating nodes. 306 o Labels allocated by the decapsulating node. The signaling 307 extension for this is outside the scope of this document. 309 5. Procedure for Hop-by-Hop IOAM 311 The Hop-by-Hop (HbH) IOAM includes IOAM Option-Types IOAM 312 Pre-allocated Trace Option-Type, IOAM Incremental Trace Option-Type 313 and IOAM Proof of Transit (POT) Option-Type [I-D.ippm-ioam-data]. 314 This section summarizes the procedure for data encapsulation and 315 decapsulation for Hop-by-hop IOAM in MPLS header. 317 o The encapsulating node inserts the IOAM Indicator Label or IOAM 318 Flow Indicator Label with Flow Label and one or more IOAM data 319 field(s) in the MPLS header. The procedure to generate the Flow 320 Label is outside the scope of this document. 322 O. The transit and decapsulating node enabled with IOAM functions 323 "forwards and punts the timestamped copy" of the data packet 324 including IOAM data fields when the node recognizes the IOAM 325 Indicator Label and IOAM Flow Indicator Label. The copy of the 326 data packet is punted to the slow path for OAM processing and is 327 not necessarily punted to the control-plane. The receive 328 timestamp is required by various hop-by-hop OAM use-cases. 330 o The transit and decapsulating node processes the IOAM data 331 field(s) using the procedures defined in [I-D.ippm-ioam-data]. An 332 example of IOAM processing may be to export the data fields, send 333 data fields via Telemetry, etc. 335 o The decapsulating node pops the Indicator Label and the IOAM data 336 fields from the MPLS header. 338 5.1. Hop-by-Hop IOAM Indicator Label Allocation 340 IOAM Indicator Label (value TBA3) and IOAM and Flow Indicator Label 341 (value TBA4) are used to indicate the presence of the HbH IOAM data 342 field in the MPLS header. The HbH IOAM Indicator Label and IOAM and 343 Flow Indicator Label can be allocated using one of the following 344 methods: 346 o Labels assigned by IANA with value TBA3 and TBA4 from the Extended 347 Special-Purpose MPLS Values [I-D.mpls-spl-terminology]. 349 o Labels allocated by a Controller from the network-wide global 350 table. The Controller provisions the labels on all nodes 351 participating in IOAM functions along the data traffic path. 353 6. Considerations for ECMP 355 The encapsulating node needs to make sure the IOAM data field does 356 not start with a well known IP protocol value (e.g. 0x4 for IPv4 and 357 0x6 for IPv6) as it can alter the hashing function for ECMP that uses 358 the IP header. This can be achieved by using the IOAM and Flow 359 Indicator Label (value TBA2 and TBA4) that follows by protocol value 360 0000b. This approach is consistent with the use of utilizing 0000b 361 as the first nibble after the MPLS label stack, as described in 362 [RFC4928] [RFC4385]. 364 Note that the hashing function for ECMP that uses the labels from the 365 MPLS header may now include the Indicator Label. 367 When entropy label [RFC6790] is used for hashing function for ECMP, 368 the procedure defined in this document does not alter the hashing 369 function. 371 7. Node Capability 373 The decapsulating node that has to pop the Indicator Label, data 374 fields, and perform the IOAM function may not be capable of 375 supporting it. The encapsulating node needs to know if the 376 decapsulating node can support the IOAM function. The signaling 377 extension for this capability exchange is outside the scope of this 378 document. 380 The transit node that is not capable of supporting the IOAM functions 381 defined in this document, can simply skip the IOAM processing of the 382 MPLS header. 384 8. IANA Considerations 386 IANA maintains the "Special-Purpose Multiprotocol Label Switching 387 (MPLS) Label Values" registry (see 388 ). IANA is requested to allocate IOAM Indicator Label 390 value and IOAM and Flow Indicator value from the "Extended 391 Special-Purpose MPLS Label Values" registry: 393 +-------------+-----------------------------------+---------------+ 394 | Value | Description | Reference | 395 +-------------+-----------------------------------+---------------+ 396 | TBA1 | E2E IOAM Indicator Label | This document | 397 +-------------+-----------------------------------+---------------+ 398 | TBA2 | E2E IOAM and Flow Indicator Label | This document | 399 +-------------+-----------------------------------+---------------+ 400 | TBA3 | HbH IOAM Indicator Label | This document | 401 +-------------+-----------------------------------+---------------+ 402 | TBA4 | HbH IOAM and Flow Indicator Label | This document | 403 +-------------+-----------------------------------+---------------+ 405 9. Security Considerations 407 The security considerations of SR-MPLS are discussed in [RFC8660], 408 and the security considerations of IOAM in general are discussed in 409 [I-D.ippm-ioam-data]. 411 IOAM is considered a "per domain" feature, where one or several 412 operators decide on leveraging and configuring IOAM according to 413 their needs. Still, operators need to properly secure the IOAM 414 domain to avoid malicious configuration and use, which could include 415 injecting malicious IOAM packets into a domain. 417 10. Acknowledgements 419 The authors would like to thank Shwetha Bhandari and Vengada Prasad 420 Govindan for the discussions on IOAM. The authors would also like to 421 thank Tarek Saad, Loa Andersson and Cheng Li for providing many 422 useful comments. 424 11. References 426 11.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 430 RFC2119, March 1997. 432 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 433 2119 Key Words", RFC 8174, May 2017. 435 [RFC8660] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 436 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 437 data plane", RFC 8660, December 2019. 439 [I-D.ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., 440 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 441 D., Lapukhov, P., Chang, R., and Bernier, D., "Data Fields 442 for In-situ OAM", draft-ietf-ippm-ioam-data, work in 443 progress. 445 [I-D.ippm-direct-export] Song, H., et al., "In-situ OAM Direct 446 Exporting", draft-ioamteam-ippm-ioam-direct-export, work 447 in progress. 449 [I-D.ippm-ioam-flags] Mizrahi, T., et al., "In-situ OAM Flags", 450 draft-ietf-ippm-ioam-flags, work in progress. 452 11.2. Informative References 454 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 455 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 456 Use over an MPLS PSN", RFC 4385, February 2006. 458 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 459 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 460 4928, June 2007. 462 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 463 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 464 RFC 6790, November 2012. 466 [I-D.mpls-spl-terminology] L. Andersson, et al., "Special Purpose 467 Label terminology", draft-ietf-mpls-spl-terminology, work 468 in progress. 470 [I-D.spring-mpls-path-segment] Cheng, W., et al., "Path Segment in 471 MPLS Based Segment Routing Network", 472 draft-ietf-spring-mpls-path-segment, work in progress. 474 Contributors 476 Authors' Addresses 478 Rakesh Gandhi (editor) 479 Cisco Systems, Inc. 480 Canada 482 Email: rgandhi@cisco.com 484 Zafar Ali 485 Cisco Systems, Inc. 487 Email: zali@cisco.com 489 Clarence Filsfils 490 Cisco Systems, Inc. 491 Belgium 493 Email: cf@cisco.com 495 Frank Brockners 496 Cisco Systems, Inc. 497 Hansaallee 249, 3rd Floor 498 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 499 Germany 500 Email: fbrockne@cisco.com 502 Bin Wen 503 Comcast 505 Email: Bin_Wen@cable.comcast.com 507 Voitek Kozak 508 Comcast 510 Email: Voitek_Kozak@comcast.com