idnits 2.17.1 draft-song-mpls-extension-header-05.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 document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 10, 2021) is 1018 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) ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-06) exists of draft-song-mpls-eh-indicator-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS H. Song, Ed. 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track Z. Li 5 Expires: January 11, 2022 T. Zhou 6 Huawei 7 L. Andersson 8 Bronze Dragon Consulting 9 Z. Zhang 10 Juniper Networks 11 July 10, 2021 13 MPLS Extension Header 14 draft-song-mpls-extension-header-05 16 Abstract 18 Motivated by the need to support multiple in-network services and 19 functions in an MPLS network, this document describes a generic and 20 extensible method to encapsulate extension headers into MPLS packets. 21 The encapsulation method allows stacking multiple extension headers 22 and quickly accessing any of them as well as the original upper layer 23 protocol header and payload. We show how the extension header can be 24 used to support several new network applications and optimize some 25 existing network services. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119][RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 11, 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4 70 3. Type of MPLS Extension Headers . . . . . . . . . . . . . . . 8 71 4. Operation on MPLS Extension Headers . . . . . . . . . . . . . 8 72 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Motivation 84 Some applications require adding instructions and/or metadata to user 85 packets within a network. Such examples include In-situ OAM (IOAM) 86 [I-D.ietf-ippm-ioam-data] and Service Function Chaining (SFC) 87 [RFC7665]. New applications are emerging. It is possible that the 88 instructions and/or metadata for multiple applications are stacked 89 together in one packet to support a compound service. 91 Conceivably, such instructions and/or metadata would be encoded as 92 new headers and encapsulated in user packets. Such headers may 93 require to be processed in fast path or in slow path. Moreover, such 94 headers may require being attended at each hop on the forwarding path 95 (i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to- 96 end or E2E). 98 The encapsulation of the new header(s) poses some challenges to MPLS 99 networks, because the MPLS protocol header contains no explicit 100 indicator for the upper layer protocols by design. We leave the 101 discussion on the indicator of new header(s) in an MPLS packet to 102 another companion document [I-D.song-mpls-eh-indicator]. In this 103 document, we focus on the encode and encapsulation of new headers in 104 an MPLS packet. 106 The similar problem has been tackled for some particular application 107 before. However, these solutions have some drawbacks: 109 o The solutions rely on either the built-in next-protocol indicator 110 in the header or the knowledge of the format and size of the 111 header to access the following packet data. The node is required 112 to be able to parse the new header, which is unrealistic in an 113 incremental deployment environment. 115 o These works only provide piecemeal solution which assumes the new 116 header is the only extra header and its location in the packet is 117 fixed by default. It is impossible or difficult to support 118 multiple new headers in one packet due to the conflicted 119 assumption. 121 o Some previous work such as G-ACH [RFC5586] was explicitly defined 122 for control channel only but what we need is the user packet 123 service. 125 To solve these problems, we introduce extension header as a general 126 and extensible means to support new in-network functions and 127 applications in MPLS networks. The idea is similar to IPv6 extension 128 headers which offer a huge innovation potential (e.g, network 129 security, SRv6 [RFC8754], network programming 130 [I-D.ietf-spring-srv6-network-programming], SFC 131 [I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the 132 existence of extension headers, it is straightforward to introduce 133 new in-network services into IPv6 networks. For example, it has been 134 proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as 135 a new extension header option in IPv6 networks. 137 Nevertheless, IPv6 EH is not perfect either. It has three issues: 139 o IPv6's header is large compared to MPLS, claiming extra bandwidth 140 overhead and complicating the packet processing. We prefer to 141 retain the header compactness in MPLS networks. 143 o IPv6's extension headers are chained with the original upper layer 144 protocol headers in a flat stack. One must scan all the extension 145 headers to access the upper layer protocol headers and the 146 payload. This is inconvenient and raises some performance 147 concerns for some applications(e.g., DPI and ECMP). The new 148 scheme for MPLS header extension needs to address these issues 149 too. 151 o [RFC8200] enforces many constraints to IPv6 extension headers 152 (e.g., EH can only be added or deleted by the end nodes specified 153 by the IP addresses in the IPv6 header, and there is only one Hop- 154 by-Hop EH that can be processed on the path nodes), which are not 155 suitable for MPLS networks. For example, MPLS label stacks are 156 added and changed in network, and there could be tunnel within 157 tunnel, so the extension headers need more flexibility. 159 2. MPLS Extension Header 161 From the previous discussion, we have laid out the design 162 requirements to support extension headers in MPLS networks: 164 Performance: Unnecessary label stack scanning for a label and the 165 full extension header stack scanning for the upper layer protocol 166 should be avoided. The extension headers a node needs to process 167 should be located as close to the MPLS label stack as possible. 168 Each extension header is better to serve only one application to 169 avoid the need of packing multiple TLV options in one extension 170 header. 172 Scalability: New applications can be supported by introducing new 173 extension headers. Multiple extension headers can be easily 174 stacked together to support multiple services simultaneously. 176 Backward Compatibility: Legacy devices which do not recognize the 177 extension header option should still be able to forward the 178 packets as usual. If a device recognize some of the extension 179 headers but not the others in an extension header stack, it can 180 process the known headers only while ignoring the others. 182 Flexibility: A node can be configured to process or not process any 183 EH. Any tunnel end nodes in the MPLS domain can add new EH to the 184 packets which shall be removed on the other end of the tunnel. 186 We assume the MPLS label stack has included some indicator of the 187 extension header(s). The actual extension headers are inserted 188 between the MPLS label stack and the original upper layer packet 189 header. The format of the MPLS packets with extension headers is 190 shown in Figure 1. 192 0 31 193 +--------+--------+--------+--------+ \ 194 | | | 195 ~ MPLS Label Stack ~ | 196 | | | 197 +--------+--------+--------+--------+ | 198 | EH Indicator (TBD) | > MPLS Label Stack 199 +--------+--------+--------+--------+ | (extended with EHI) 200 | | | 201 ~ MPLS Label Stack ~ | 202 | | | 203 +--------+--------+--------+--------+ < 204 | Header of Extension Headers (HEH) | | 205 +--------+--------+--------+--------+ | 206 | | | 207 ~ Extension Header (EH) 1 ~ | 208 | | | 209 +--------+--------+--------+--------+ > MPLS EH Fields 210 ~ ~ | (new) 211 +--------+--------+--------+--------+ | 212 | | | 213 ~ Extension Header (EH) N ~ | 214 | | | 215 +--------+--------+--------+--------+ < 216 | | | 217 ~ Upper Layer Headers/Payload ~ > MPLS Payload 218 | | | (as is) 219 +--------+--------+--------+--------+ / 221 Figure 1: MPLS with Extension Headers 223 Following the MPLS label stack is the 4-octet Header of Extension 224 Headers (HEH), which indicates the total number of extension headers 225 in this packet, the overall length of the extension headers, the type 226 of the original upper layer header, and the type of the next header. 227 The format of the HEH is shown in Figure 2. 229 0 1 2 3 230 0123 4567 89012345 67890123 45678901 231 +----+----+--------+--------+--------+ 232 | R |EHC | EHTL | OUL | NH | 233 +----+----+--------+--------+--------+ 235 Figure 2: HEH Format 237 The meaning of the fields in an HEH is as follows: 239 R: 4-bit reserved. The nibble value means to avoid conflicting with 240 IP version numbers. 242 EHC: 4-bit unsigned integer for the Extension Header Counter. This 243 field keeps the total number of extension headers included in this 244 packet. It does not count the original upper layer protocol 245 headers. At most 15 EHs are allowed in one packet. 247 EHTL: 8-bit unsigned integer for the Extension Header Total Length 248 in 4-octet units. This field keeps the total length of the 249 extension headers in this packet, not including the HEH itself. 251 OUL: 8-bit Original Upper Layer protocol number indicating the 252 original upper layer protocol type. It can be set to "UNKNOWN" if 253 unknown. 255 NH: 8-bit selector for the Next Header. This field identifies the 256 type of the header immediately following the HEH. 258 The value of the reserved nibble needs further consideration. The 259 EHC field can be used to keep track of the number of extension 260 headers when some headers are inserted or removed at some network 261 nodes. The EHTL field can help to skip all the extension headers in 262 one step if the original upper layer protocol headers or payload need 263 to be accessed. The OUL field can help identify the type of the 264 original upper layer protocol. 266 The format of an Extension Header (EH) is shown in Figure 3. 268 0 1 2 3 269 01234567 89012345 67890123 45678901 270 +--------+--------+--------+-------+ 271 | NH | HLEN |EXT | | 272 +--------+--------+--------+ | 273 | | 274 ~ Header Specific Data ~ 275 | | 276 +--------+--------+----------------+ 278 Figure 3: EH Format 280 The meaning of the fields in an EH is as follows: 282 NH: 8-bit indicator for the Next Header. This field identifies the 283 type of the EH immediately following this EH. 285 HLEN: 8-bit unsigned integer for the Extension Header Length in 286 4-octet units, not including the first 4 octets. 288 EXT: 8-bit optional type extension. To save the Next Header numbers 289 and extend the number space, it is possible to use one "Next 290 Header" code to cover a set of sub-types. Each sub-type is 291 assigned a new code in a different name space. This field is 292 optional and it is only specified for some specific EH type. 294 Header Specific Data: Variable length field for the specification of 295 the EH. This field is 4-octet aligned. 297 The extension headers as well as the first original upper layer 298 protocol header are chained together through the NH field in HEH and 299 EHs. The encoding of NH can share the same value registry for IPv4/ 300 IPv6 protocol numbers. Values for new EH types shall be assigned by 301 IANA. 303 Specifically, the NH field of the last EH in a chain can have some 304 special values, which shall be assigned by IANA as well: 306 NONE (No Next Header): Indicates that there is no other header and 307 payload after this header. This can be used to transport packets 308 with only extension header(s), for example, the control packets 309 for control or the probe packets for measurements. Note that 310 value 59 was reserved for "IPv6 No Next Header" indicator. It may 311 be possible for MPLS EH to share this value. 313 UNKNOWN (Unknown Next Header): Indicates that the type of the header 314 after this header is unknown. This is intended to be compatible 315 with the original MPLS design in which the upper layer protocol 316 type is unknown from the MPLS header alone. 318 MPLS: Indicates that the original upper layer protocol is still MPLS 319 and another MPLS label stack follows. 321 Note that the original upper layer protocol can be of type "MPLS", 322 which implies that in a packet there might be multiple label stacks 323 separated by EHs. Having more than one independent label stack is 324 not new. For example, A Bier header could separate the transport/ 325 bier labels and the payload labels; An MPLS PW network could be 326 implemented on the top of another infrastructure MPLS network. In 327 such cases, we have the flexibility to apply different services to 328 different label stacks. 330 3. Type of MPLS Extension Headers 332 Basically, there are two types of MPLS EHs: HBH and E2E. E2E means 333 that the EH is only supposed to be inserted/removed and processed at 334 the MPLS tunnel end points where the MPLS header is inserted or 335 removed. The EHs that need to be processed on path nodes within the 336 MPLS tunnel are of the HBH type. However, any node in the tunnel can 337 be configured to ignore an HBH EH, even if it is capable of 338 processing it. 340 If there are two types of EHs in a packet, the HBH EHs must take 341 precedence over the E2E EHs. 343 Making a distinction of the EH types and ordering the EHs in a packet 344 help improve the forwardidng performance. For example, if a node 345 within an MPLS tunnel finds only E2E EHs in a packet, it can avoid 346 scanning the EH list. 348 4. Operation on MPLS Extension Headers 350 When the first EH X needs to be added to an MPLS packet, an EH 351 indicator is inserted into the proper location in the MPLS label 352 stack. A HEH is then inserted after the MPLS label stack, in which 353 EHCNT is set to 1, EHTLEN is set to the length of X in 4-octet units, 354 and NH is set to the header value of X. At last, X is inserted after 355 the HEH, in which NH and HELN are set accordingly. Note that if this 356 operation happens at a PE device, the upper layer protocol is known 357 before the MPLS encapsulation, so its value can be saved in the NH 358 field if desired. Otherwise, the NH field is filled with the value 359 of "UNKNOWN". 361 When an EH Y needs to be added to an MPLS packet which already 362 contains extension header(s), the EHCNT and EHTLEN in the HEH are 363 updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is 364 incremented by the size of Y in 4-octet units). Then a proper 365 location for Y in the EH chain is located. Y is inserted at this 366 location. The NH field of Y is copied from the previous EH's NH 367 field (or from the HEH's NH field, if Y is the first EH in the 368 chain). The previous EH's NH value, or, if Y is the first EH in the 369 chain, the HEH's NH, is set to the header value of Y. 371 Deleting an EH simply reverses the above operation. If the deleted 372 EH is the last one, the EH indicator and HEH can also be removed. 374 When processing an MPLS packet with extension headers, the node needs 375 to scan through the entire EH chain and process the EH one by one. 376 The node should ignore any unrecognized EH or the EH that is 377 configured as "No Processing". 379 The EH can be categorized into HBH or E2E. Since EHs are ordered 380 based on their type(i.e., HBH EHs are located before E2E EHs), a node 381 can avoid some unnecessary EH scan. 383 5. Use Cases 385 In this section, we show how MPLS extension header can be used to 386 support several new network applications. 388 In-situ OAM: In-situ OAM (IOAM) records flow OAM information within 389 user packets while the packets traverse a network. The 390 instruction and collected data are kept in an IOAM header 391 [I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network, 392 the IOAM header can be encapsulated as an MPLS extension header. 394 Network Telemetry and Measurement: A network telemetry and 395 instruction header can be carried as an extension header to 396 instruct a node what type of network measurements should be done. 397 For example, the method described in [RFC8321] can be implemented 398 in MPLS networks since the EH provides a natural way to color MPLS 399 packets. 401 Network Security: Security related functions often require user 402 packets to carry some metadata. In a DoS limiting network 403 architecture, a "packet passport" header is used to embed packet 404 authentication information for each node to verify. 406 Segment Routing and Network Programming: MPLS extension header can 407 support the implementation of a new flavor of the MPLS-based 408 segment routing, with better performance and richer 409 functionalities. The details will be described in another draft. 411 With MPLS extension headers, multiple in-network applications can be 412 stacked together. For example, IOAM and SFC can be applied at the 413 same time to support network OAM and service function chaining. A 414 node can stop scanning the extension header stack if all the known 415 headers it can process have been located. For example, if IOAM is 416 the first EH in a stack and a node is configured to process IOAM 417 only, it will stop searching the EH stack when the IOAM EH is found. 419 6. Security Considerations 421 TBD 423 7. IANA Considerations 425 This document requests IANA to assign two new Internet Protocol 426 Numbers from the "Protocol Numbers" Registry to indicate "No Next 427 Header" and "Unknown Next Header". 429 This document does not create any other new registries. 431 8. Contributors 433 The other contributors of this document are listed as follows. 435 o James Guichard 437 o Stewart Bryant 439 o Andrew Malis 441 9. Acknowledgments 443 TBD. 445 10. References 447 10.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 455 Chaining (SFC) Architecture", RFC 7665, 456 DOI 10.17487/RFC7665, October 2015, 457 . 459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 460 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 461 May 2017, . 463 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 464 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 465 "Alternate-Marking Method for Passive and Hybrid 466 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 467 January 2018, . 469 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 470 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 471 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 472 . 474 10.2. Informative References 476 [I-D.brockners-inband-oam-transport] 477 Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, 478 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 479 Mozes, D., Lapukhov, P., and R. Chang, "Encapsulations for 480 In-situ OAM Data", draft-brockners-inband-oam-transport-05 481 (work in progress), July 2017. 483 [I-D.ietf-ippm-ioam-data] 484 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 485 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 486 progress), February 2021. 488 [I-D.ietf-spring-srv6-network-programming] 489 Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D., 490 Matsushima, S., and Z. Li, "Segment Routing over IPv6 491 (SRv6) Network Programming", draft-ietf-spring-srv6- 492 network-programming-28 (work in progress), December 2020. 494 [I-D.song-mpls-eh-indicator] 495 Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for 496 MPLS Extension Header Indicator", draft-song-mpls-eh- 497 indicator-03 (work in progress), July 2021. 499 [I-D.xu-clad-spring-sr-service-chaining] 500 Clad, F., Xu, X., Filsfils, C., Bernier, D., Decraene, B., 501 Yadlapalli, C., Henderickx, W., Salsano, S., and S. Ma, 502 "Segment Routing for Service Chaining", draft-xu-clad- 503 spring-sr-service-chaining-00 (work in progress), December 504 2017. 506 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 507 "MPLS Generic Associated Channel", RFC 5586, 508 DOI 10.17487/RFC5586, June 2009, 509 . 511 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 512 (IPv6) Specification", STD 86, RFC 8200, 513 DOI 10.17487/RFC8200, July 2017, 514 . 516 Authors' Addresses 518 Haoyu Song (editor) 519 Futurewei Technologies 521 Santa Clara 522 USA 524 Email: haoyu.song@futurewei.com 526 Zhenbin Li 527 Huawei 529 Beijing 530 P.R. China 532 Email: lizhenbin@huawei.com 534 Tianran Zhou 535 Huawei 537 Beijing 538 P.R. China 540 Email: zhoutianran@huawei.com 542 Loa Andersson 543 Bronze Dragon Consulting 545 Stockholm 546 Sweden 548 Email: loa@pi.nu 550 Zhaohui Zhang 551 Juniper Networks 553 Boston 554 USA 556 Email: zzhang@juniper.net