idnits 2.17.00 (12 Aug 2021) /tmp/idnits37732/draft-song-mpls-extension-header-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 : ---------------------------------------------------------------------------- ** 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 (August 8, 2018) is 1382 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 ** Downref: Normative reference to an Experimental RFC: RFC 8321 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-03 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song, Ed. 3 Internet-Draft Z. Li 4 Intended status: Standards Track T. Zhou 5 Expires: February 9, 2019 Huawei 6 L. Andersson 7 Bronze Dragon Consulting 8 August 8, 2018 10 MPLS Extension Header 11 draft-song-mpls-extension-header-01 13 Abstract 15 Motivated by the need to support multiple in-network services and 16 functions in an MPLS network, this document describes a method to 17 encapsulate extension headers into MPLS packets. The encapsulation 18 method allows stacking multiple extension headers and quickly 19 accessing any of them as well as the original upper layer protocol 20 header and payload. We show how the extension header can be used to 21 support several new network applications. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119][RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 9, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4 67 3. Operation on MPLS Extension Headers . . . . . . . . . . . . . 8 68 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 10.2. Informative References . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Motivation 81 Some applications require adding instructions and/or metadata to user 82 packets within a network. Such examples include In-situ OAM (IOAM) 83 [I-D.brockners-inband-oam-requirements] and Service Function Chaining 84 (SFC) [RFC7665]. New applications are emerging. It is possible that 85 the instructions and/or metadata for multiple applications are 86 stacked together in one packet to support a compound service. 88 However, the encapsulation of the new header(s) poses some challenges 89 to the ubiquitous MPLS networks. The MPLS protocol header contains 90 no explicit indicator for the upper layer protocols by design. The 91 compact MPLS header, while beneficial to forwarding, allows little 92 room for any extra information. Moreover, the backward compatibility 93 issue discourages any attempts trying to overload the semantics of 94 the existing MPLS header fields. While it is possible to designate 95 "service labels" with special semantics by an operator, the non- 96 standard approach burdens the control plane and impairs the 97 interoperability. 99 The similar "header extension" requirement for MPLS has led to 100 several proposals. A special Generic Associated Channel Label (GAL) 101 [RFC5586] is assigned to support the identification of an Associated 102 Channel Header (ACH). Later, it was proposed to use GAL to indicate 103 the presence of a Metadata Channel Header (MCH) 104 [I-D.guichard-sfc-mpls-metadata] as well. 106 GAL has several limitations: 108 o It must be located at the bottom of a label stack for its chief 109 use case of MPLS-TP. An LSR needs to search the entire label 110 stack for the BoS bit and check if the corresponding label is GAL. 111 This can impact the performance when the label stack is deep. 113 o When GAL is present, the first nibble of the word following the 114 GAL needs to be checked to determine the header type. Since the 115 value of the nibble cannot be greater than 3 to avoid any possible 116 confliction with IP version numbers, this approach is not 117 scalable. 119 o By design, GAL can only indicate the presence of a single header. 120 Therefore, the solution alone is not sufficient to support adding 121 multiple headers at the same time. 123 o The presence of GAL makes the network load balancing or deep 124 packet inspection based on upper layer protocol headers and 125 payload difficult. 127 In addition to the above limitations, it is not desirable to keep 128 overloading GAL with new semantics. Instead of trying to patch on 129 existing schemes, we propose a new mechanism to solve the above 130 mentioned issues and create new innovation opportunities, similar to 131 the way that IPv6 supports extension headers, which offer a huge 132 innovation potential (e.g, network security, SRv6 133 [I-D.ietf-spring-segment-routing], network programming 134 [I-D.filsfils-spring-srv6-network-programming], SFC 135 [I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the 136 existing of extension headers, it is straightforward to introduce new 137 in-network services into IPv6 networks. For example, it has been 138 proposed to carry IOAM header [I-D.brockners-inband-oam-transport] 139 and NSH as new extension headers in IPv6 networks. 141 Nevertheless, IPv6 is not perfect either. It has two main issues. 142 First, IPv6's header is large compared to MPLS, claiming extra 143 bandwidth overhead and complicating the packet processing. We prefer 144 to retain the header compactness in MPLS networks. Second, IPv6's 145 extension headers are chained with the original upper layer protocol 146 headers in a flat stack. One must scan all the extension headers to 147 access the upper layer protocol headers and the payload. This is 148 inconvenient and raises some performance concerns for some 149 applications (e.g., DPI and ECMP). The new scheme for MPLS header 150 extension needs to address these issues too. 152 2. MPLS Extension Header 154 From the previous discussion, we have laid out the design 155 requirements to support extension headers in MPLS networks: 157 Performance: If possible, unnecessary label stack scanning for a 158 label and extension header stack scanning for the upper layer 159 protocol should be avoided. 161 Scalability: New applications can be easily supported by introducing 162 new extension headers. Multiple extension headers can be easily 163 stacked together to support multiple services simultaneously. 165 Backward Compatibility: Legacy devices which do not recognize the 166 extension header option should still be able to forward the 167 packets as usual. If a device recognize some of the extension 168 headers but not the others in an extension header stack, it can 169 process the known headers only while ignoring the others. 171 Extension headers can be be supported in several ways in an MPLS 172 network, we have outlined some of them in this document. However, it 173 should be noted that we do not intend to close this discussion yet, 174 and are prepared to listen to arguments why and how any other methods 175 could be used. One interesting line of thought is whether it would 176 be possible to let a label that is received on top of the stack 177 indicate whether there are extension headers beneath the stack. 179 Our investigations indicate that a special purpose label and/or an 180 extended special purpose label will be the optimal way to go. A new 181 special purpose label, namely the Extension Header Label (EHL), can 182 be used to indicate EHs. So far 8 special purpose label values are 183 left unsigned by IANA (which are 4 to 6 and 8 to 12). Alternatively, 184 a two label scheme with the use of the extension label (XL) plus an 185 EHL is possible, but it does use one more label. It is also possible 186 to use FEC labels to indicate the presence of extension headers. 187 Although this approach avoid the need of a new special purpose label, 188 it introduces a good deal of complexity into the control plane. In 189 the remaining of the document, we assume a special EHL is assigned 190 and use it as an example to illustrate the scheme. A formal 191 recommendation on the Extension Header (EH) indicator approach will 192 be given in a future revision of this document. 194 The format of the MPLS packets with extension headers is shown in 195 Figure 1. An EHL can be located in anywhere in an MPLS label stack. 196 However, if there are legacy devices which do not recognize the EHL 197 in the network, then for backward compatibility, the EHL must be 198 located at the bottom of the stack (i.e., only the MPLS tunnel ends 199 and EHL-aware nodes will look up and process it). Otherwise, the EHL 200 can be located close to the top of the stack for better lookup 201 performance. 203 The format of an EHL is the same as an MPLS label. The first 20-bit 204 label value will be assigned by IANA. The BoS bit is used to 205 indicate the location of the label. The other fields, CoS and TTL, 206 are unused in the context of EHL. 208 0 31 209 +--------+--------+--------+--------+ 210 | | 211 ~ MPLS Label Stack ~ 212 | | 213 +--------+--------+--------+--------+ 214 | EHL | 215 +--------+--------+--------+--------+ 216 | | 217 ~ MPLS Label Stack ~ 218 | | 219 +--------+--------+--------+--------+ 220 | Header of Extension Headers (HEH) | 221 +--------+--------+--------+--------+ 222 | | 223 ~ Extension Header (EH) 1 ~ 224 | | 225 +--------+--------+--------+--------+ 226 ~ ~ 227 +--------+--------+--------+--------+ 228 | | 229 ~ Extension Header (EH) N ~ 230 | | 231 +--------+--------+--------+--------+ 232 | | 233 ~ Upper Layer Protocols/Payload ~ 234 | | 235 +--------+--------+--------+--------+ 237 Figure 1: MPLS with Extension Header 239 Following the MPLS label stack is the 4-octet Header of Extension 240 Headers (HEH), which indicates the total number of extension headers 241 in this packet, the overall length of the extension headers, and the 242 type of the next header. The format of the HEH is shown in Figure 2. 244 0 1 2 3 245 0123 45678901 234567890123 45678901 246 +----+--------+------------+--------+ 247 | R | EHCNT | EHTLEN | NH | 248 +----+--------+------------+--------+ 250 Figure 2: HEH Format 252 The meaning of the fields in an HEH is as follows: 254 R: 4-bit reserved. 256 EHCNT: 8-bit unsigned integer for the Extension Header Counter. 257 This field keeps the total number of extension headers included in 258 this packet. It does not count the original upper layer protocol 259 headers. 261 EHTLEN: 12-bit unsigned integer for the Extension Header Total 262 Length in 4-octet units. This field keeps the total length of the 263 extension headers in this packet, not including the HEH itself. 265 NH: 8-bit selector for the Next Header. This field identifies the 266 type of the header immediately following the HEH. 268 The EHCNT field can be used to keep track of the number of extension 269 headers when some headers are inserted or removed at some network 270 nodes. The EHLEN field can help to skip all the extension headers in 271 one step if the original upper layer protocol headers or payload need 272 to be accessed. 274 The format of an Extension Header (EH) is shown in Figure 3. 276 0 1 2 3 277 01234567 89012345 6789012345678901 278 +--------+--------+----------------+ 279 | NH | HLEN | | 280 +--------+--------+ + 281 | | 282 ~ Header Specific Data ~ 283 | | 284 +--------+--------+----------------+ 286 Figure 3: EH Format 288 The meaning of the fields in an EH is as follows: 290 NH: 8-bit selector for the Next Header. This field identifies the 291 type of the EH immediately following this EH. 293 HLEN: 8-bit unsigned integer for the Extension Header Length in 294 4-octet units, not including the first 4 octets. 296 Header Specific Data: Variable length field for the specification of 297 the EH. This field is 4-octet aligned. 299 The extension headers as well as the first original upper layer 300 protocol header are chained together through the NH field in HEH and 301 EHs. The encoding of NH uses the same values as the IPv4 protocol 302 field. Values for new EH types shall be assigned by IANA. 304 Specifically, the NH field of the last EH in a chain can have two 305 special values, which shall be assigned by IANA: 307 NONE (No Next Header): Indicates that there is no other header and 308 payload after this header. This can be used to transport packets 309 with only extension header(s). 311 UNKNOWN (Unknown Next Header): Indicates that the type of the header 312 after this header is unknown. This is intended to be compatible 313 with the original MPLS design in which the upper layer protocol 314 type is unknown from the MPLS header alone. 316 3. Operation on MPLS Extension Headers 318 When the first EH X needs to be added to an MPLS packet, an EHL is 319 inserted into the proper location in the MPLS label stack. A HEH is 320 then inserted after the MPLS label stack, in which EHCNT is set to 1, 321 EHTLEN is set to the length of X in 4-octet units, and NH is set to 322 the header value of X. At last, X is inserted after the HEH, in 323 which NH and HELN are set accordingly. Note that if this operation 324 happens at a PE device, the upper layer protocol is known before the 325 MPLS encapsulation, so its value can be saved in the NH field if 326 desired. Otherwise, the NH field is filled with the value of 327 "UNKNOWN". 329 When an EH Y needs to be added to an MPLS packet which already 330 contains extension header(s), the EHCNT and EHTLEN in the HEH are 331 updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is 332 incremented by the size of Y in 4-octet units). Then a proper 333 location for Y in the EH chain is located. Y is inserted at this 334 location. The NH field of Y is copied from the previous EH's NH 335 field (or from the HEH's NH field, if Y is the first EH in the 336 chain). The previous EH's NH value, or, if Y is the first EH in the 337 chain, the HEH's NH, is set to the header value of Y. 339 Deleting an EH simply reverses the above operation. If the deleted 340 EH is the last one, the EHL and HEH can also be deleted. 342 When processing an MPLS packet with extension headers, the node needs 343 to scan through the entire EH chain and process the EH one by one. 344 The node should ignore any unrecognized EH. 346 4. Use Cases 348 In this section, we show how MPLS extension header can be used to 349 support several new network applications. 351 In-situ OAM: In-situ OAM (IOAM) records flow OAM information within 352 user packets while the packets traverse a network. The 353 instruction and collected data are kept in an IOAM header 354 [I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network, 355 the IOAM header can be encapsulated as an MPLS extension header. 357 NSH: Network Service Header (NSH) [RFC8300] provides a service plane 358 for Service Function Chaining (SFC). NSH maintains the SFC 359 context and metadata. If MPLS is used as the transport protocol 360 for NSH, NSH can be encapsulated as an MPLS extension header. 362 Network Telemetry and Measurement: A network telemetry and 363 instruction header can be carried as an extension header to 364 instruct a node what type of network measurements should be done. 365 For example, the method described in [RFC8321] can be implemented 366 in MPLS networks since the EH provides a natural way to color MPLS 367 packets. 369 Network Security: Security related functions often require user 370 packets to carry some metadata. In a DoS limiting network 371 architecture, a "packet passport" header is used to embed packet 372 authentication information for each node to verify. 374 Segment Routing: MPLS extension header can support the 375 implementation of a new flavor of the MPLS-based segment routing, 376 with better performance and richer functionalities. The details 377 will be described in another draft. 379 With MPLS extension headers, multiple in-network applications can be 380 stacked together. For example, IOAM and SFC can be applied at the 381 same time to support network OAM and service function chaining. A 382 node can stop scanning the extension header stack if all the known 383 headers it can process have been located. For example, if IOAM is 384 the first EH in a stack and a node is configured to process IOAM 385 only, it will stop searching the EH stack when the IOAM EH is found. 387 5. Summary 389 Evidenced by the existing and emerging use cases, MPLS networks need 390 a standard way to support extension headers. In Figure 4, we 391 summarize the potential schemes that allow MPLS packets to carry 392 extension headers and list the main issues for each scheme. 394 +---+---------------------------+---------------------------------+ 395 |No.| Description | Issues | 396 +---+---------------------------+---------------------------------+ 397 | 1 | GAL + MCH with multi- |- Label location limitation lead | 398 | | header extension | to performance concern | 399 | | |- Interfere with load balancing | 400 | | | and DPI functions | 401 | | |- Overload GAL semantics | 402 | | |- Need standard extension | 403 +---+---------------------------+---------------------------------+ 404 | 2 | GAL + another nibble value|- Same as above | 405 | | to encode the EHs (e.g., | | 406 | | "0010") | | 407 +---+---------------------------+---------------------------------+ 408 | 3 | FEC label to indicate EH |- Complex control plane | 409 | | |- Interoperability | 410 +---+---------------------------+---------------------------------+ 411 | 4 | XL(15) + EHL |- One extra label | 412 | | |- Need standard extension | 413 +---+---------------------------+---------------------------------+ 414 | 5 | Special purpose EHL |- Need standard extension | 415 +---+---------------------------+---------------------------------+ 417 Figure 4: Potential Schemes for MPLS Extension Headers 419 Through comprehensive considerations on the pros and cons of each 420 scheme, we currently recommend the scheme No.5. The proposed MPLS 421 extension header scheme provides a generic way to support in-network 422 services and functions in MPLS networks. 424 6. Security Considerations 426 TBD 428 7. IANA Considerations 430 If the EHL approach is adopted to indicate the presence of MPLS 431 extension header(s), this document requests IANA to assign a new 432 Special-Purpose MPLS Label Value from the Special-Purpose 433 Multiprotocol Label Switching (MPLS) Label Values Registry of 434 "Extension Header Label (EHL)". 436 This document also requests IANA to assign two new Internet Protocol 437 Numbers from the "Protocol Numbers" Registry to indicate "No Next 438 Header" or "Unknown Next Header". 440 This document does not create any new registries. 442 8. Contributors 444 The other contributors of this document are listed as follows. 446 o James Guichard 448 o Stewart Bryant 450 o Andrew Malis 452 9. Acknowledgments 454 TBD. 456 10. References 458 10.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 466 "MPLS Generic Associated Channel", RFC 5586, 467 DOI 10.17487/RFC5586, June 2009, 468 . 470 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 471 Chaining (SFC) Architecture", RFC 7665, 472 DOI 10.17487/RFC7665, October 2015, 473 . 475 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 476 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 477 May 2017, . 479 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 480 "Network Service Header (NSH)", RFC 8300, 481 DOI 10.17487/RFC8300, January 2018, 482 . 484 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 485 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 486 "Alternate-Marking Method for Passive and Hybrid 487 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 488 January 2018, . 490 10.2. Informative References 492 [I-D.brockners-inband-oam-requirements] 493 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 494 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 495 T., <>, P., and r. remy@barefootnetworks.com, 496 "Requirements for In-situ OAM", draft-brockners-inband- 497 oam-requirements-03 (work in progress), March 2017. 499 [I-D.brockners-inband-oam-transport] 500 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 501 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 502 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 503 situ OAM Data", draft-brockners-inband-oam-transport-05 504 (work in progress), July 2017. 506 [I-D.filsfils-spring-srv6-network-programming] 507 Filsfils, C., Camarillo, P., Leddy, J., 508 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 509 Network Programming", draft-filsfils-spring-srv6-network- 510 programming-05 (work in progress), July 2018. 512 [I-D.guichard-sfc-mpls-metadata] 513 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 514 "Carrying Metadata in MPLS Networks", draft-guichard-sfc- 515 mpls-metadata-00 (work in progress), September 2013. 517 [I-D.ietf-ippm-ioam-data] 518 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 519 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 520 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 521 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 522 data-03 (work in progress), June 2018. 524 [I-D.ietf-spring-segment-routing] 525 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 526 Litkowski, S., and R. Shakir, "Segment Routing 527 Architecture", draft-ietf-spring-segment-routing-15 (work 528 in progress), January 2018. 530 [I-D.xu-clad-spring-sr-service-chaining] 531 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 532 d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, 533 S., and S. Ma, "Segment Routing for Service Chaining", 534 draft-xu-clad-spring-sr-service-chaining-00 (work in 535 progress), December 2017. 537 Authors' Addresses 539 Haoyu Song (editor) 540 Huawei 541 2330 Central Expressway 542 Santa Clara 543 USA 545 Email: haoyu.song@huawei.com 547 Zhenbin Li 548 Huawei 549 156 Beiqing Road 550 Beijing, 100095 551 P.R. China 553 Email: lizhenbin@huawei.com 555 Tianran Zhou 556 Huawei 557 156 Beiqing Road 558 Beijing, 100095 559 P.R. China 561 Email: zhoutianran@huawei.com 563 Loa Andersson 564 Bronze Dragon Consulting 565 Stockholm 566 Sweden 568 Email: loa@pi.nu