idnits 2.17.1 draft-song-mpls-extension-header-00.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 15, 2018) is 2111 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 (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-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 Network Working Group H. Song, Ed. 3 Internet-Draft Z. Li 4 Intended status: Standards Track T. Zhou 5 Expires: January 16, 2019 Huawei 6 July 15, 2018 8 MPLS Extension Header 9 draft-song-mpls-extension-header-00 11 Abstract 13 Motivated by the need to support multiple in-network services and 14 functions in an MPLS network, this document describes a generic 15 method to encapsulate extension headers into MPLS packets. The 16 encapsulation method allows stacking multiple extension headers and 17 quickly accessing any of them as well as the original upper layer 18 protocol header and payload. We show how the extension header can be 19 used to support several new network applications. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 https://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 This Internet-Draft will expire on January 16, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4 63 3. Operation on MPLS Extension Headers . . . . . . . . . . . . . 7 64 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 10.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Motivation 77 Some applications require adding instructions and/or metadata to user 78 packets within a network. Such examples include In-situ OAM (IOAM) 79 [I-D.brockners-inband-oam-requirements] and Service Function Chaining 80 (SFC) [RFC7665]. New applications are emerging. It is possible that 81 the instructions and/or metadata for multiple applications are 82 stacked together in one packet to support a compound service. 84 However, the encapsulation of the new header(s) poses some challenges 85 to the ubiquitous MPLS networks. A problem of the MPLS protocol 86 header is that there is no explicit indicator for the upper layer 87 protocols. The succinct MPLS header provide little room to encode 88 any extra information. Moreover, the backward compatibility issue 89 discourages any attempts trying to overload the semantics of the 90 existing MPLS header fields. 92 The similar "header extension" requirement for MPLS has led to 93 several proposals. A special Generic Associated Channel Label (GAL) 94 [RFC5586] is assigned to support the identification of an Associated 95 Channel Header (ACH). Later, it was proposed to use GAL to indicate 96 the presence of a Metadata Channel Header (MCH) 97 [I-D.guichard-sfc-mpls-metadata] as well. 99 GAL has several limitations: 101 o It must be located at the bottom of a label stack for its chief 102 use case of MPLS-TP. An LSR needs to scan the entire label stack 103 to be able to identify the presence of a new header. This can 104 impact the performance when the label stack is deep. 106 o When GAL is present, the first nibble of the word following the 107 GAL needs to be checked to determine the header type. Since the 108 value of the nibble cannot be greater than 3, this approach is 109 neither scalable nor reliable. 111 o By design, GAL can only indicate the presence of a single header. 112 Therefore, the solution alone is not sufficient to support adding 113 multiple headers at the same time. 115 o The presence of GAL makes the network load balancing or deep 116 packet inspection based on upper layer protocol headers and 117 payload difficult. 119 In addition to the above limitations, it is not desirable to keep 120 overloading GAL with new semantics. Instead of trying to patch on 121 existing schemes, we propose a general mechanism to solve the above 122 mentioned issues and create new innovation opportunities. We derive 123 our scheme from the experience of the IPv4 to IPv6 evolution. The 124 adoption of IPv6 is gaining its momentum. Ironically, this is not 125 due much to the extended address space over IPv4. One true power of 126 IPv6 is that it supports extension headers, which offer a huge 127 innovation potential (e.g, network security, SRv6 128 [I-D.ietf-spring-segment-routing], network programming 129 [I-D.filsfils-spring-srv6-network-programming], SFC 130 [I-D.xu-clad-spring-sr-service-chaining], etc.). It is 131 straightforward to introduce new in-network services into IPv6 132 networks through extension headers. For example, it has been 133 proposed to carry IOAM header [I-D.brockners-inband-oam-transport] 134 and NSH as new extension headers in IPv6 networks. 136 Nevertheless, IPv6 is not perfect either. For one thing, IPv6's 137 header overhead is large compared to MPLS. We would like to retain 138 the header compactness in MPLS networks. On the other hand, IPv6's 139 extension headers are chained with the original upper layer protocol 140 headers in a flat stack. One has to scan all the extension headers 141 to access the upper layer protocol headers and the payload. This is 142 inconvenient and raises some performance concerns for some 143 applications (e.g., DPI and ECMP). The new scheme for MPLS header 144 extension needs to address these issues too. 146 2. MPLS Extension Header 148 From the previous discussion, we have laid out the design 149 requirements to support extension headers in MPLS networks: 151 Performance: If possible, unnecessary label stack scanning and 152 extension header scanning should be avoided. 154 Scalability: New applications can be easily supported by introducing 155 new extension headers. Multiple extension headers can be easily 156 stacked together to support multiple services simultaneously. 158 Backward Compatibility: Legacy devices which do not recognize the 159 extension header option should still be able to forward the 160 packets as usual. If a device recognize some of the extension 161 headers but not the others in an extension header stack, it can 162 process the known headers only while ignoring the others. 164 To support the extension header in MPLS, we need to assign a new 165 special label, namely the Extension Header Label (EHL). So far 8 166 special label values are left unsigned by IANA (which are 4 to 6 and 167 8 to 12). We believe this use case is significant enough to deserve 168 one dedicated special label. Alternatively, a two label scheme with 169 the use of the extension label (XL) plus an EHL is possible, but it 170 does use one more label. It is also possible to use FEC labels to 171 indicate the presence of extension headers. Although this approach 172 avoid the need of a new special label, it introduces a good deal of 173 complexity into the control plane. In the remaining of the document, 174 we assume a special EHL is assigned. 176 The format of the MPLS packets with extension headers is shown in 177 Figure 1. An EHL can be located in anywhere in an MPLS label stack. 178 However, if there are legacy devices which do not recognize the EHL 179 in the network, then for backward compatibility, the EHL must be 180 located at the bottom of the stack (i.e., only the MPLS tunnel ends 181 and EHL-aware nodes will look up and process it). Otherwise, the EHL 182 can be located close to the top of the stack for better lookup 183 performance. 185 The format of an EHL is the same as an MPLS label. The first 20-bit 186 label value will be assigned by IANA. The BoS bit is used to 187 indicate the location of the label. The other fields, CoS and TTL, 188 are unused in the context of EHL. 190 0 31 191 +--------+--------+--------+--------+ 192 | | 193 ~ MPLS Label Stack ~ 194 | | 195 +--------+--------+--------+--------+ 196 | EHL | 197 +--------+--------+--------+--------+ 198 | | 199 ~ MPLS Label Stack ~ 200 | | 201 +--------+--------+--------+--------+ 202 | Header of Extension Headers (HEH) | 203 +--------+--------+--------+--------+ 204 | | 205 ~ Extension Header (EH) 1 ~ 206 | | 207 +--------+--------+--------+--------+ 208 ~ ~ 209 +--------+--------+--------+--------+ 210 | | 211 ~ Extension Header (EH) N ~ 212 | | 213 +--------+--------+--------+--------+ 214 | | 215 ~ Upper Layer Protocols/Payload ~ 216 | | 217 +--------+--------+--------+--------+ 219 Figure 1: MPLS with Extension Header 221 Following the MPLS label stack is the 4-octet Header of Extension 222 Headers (HEH), which indicates the total number of extension headers 223 in this packet, the overall length of the extension headers, and the 224 type of the next header. The format of the HEH is shown in Figure 2. 226 0 1 2 3 227 0123 45678901 234567890123 45678901 228 +----+--------+------------+--------+ 229 | R | EHCNT | EHTLEN | NH | 230 +----+--------+------------+--------+ 232 Figure 2: HEH Format 234 The meaning of the fields in an HEH is as follows: 236 R: 4-bit reserved. 238 EHCNT: 8-bit unsigned integer for the Extension Header Counter. 239 This field keeps the total number of extension headers included in 240 this packet. It does not count the original upper layer protocol 241 headers. 243 EHTLEN: 12-bit unsigned integer for the Extension Header Total 244 Length in 4-octet units. This field keeps the total length of the 245 extension headers in this packet, not including the HEH itself. 247 NH: 8-bit selector for the Next Header. This field identifies the 248 type of the header immediately following the HEH. 250 The EHCNT field can be used to keep track of the number of extension 251 headers when some headers are inserted or removed at some network 252 nodes. The EHLEN field can help to skip all the extension headers in 253 one step if the original upper layer protocol headers or payload need 254 to be accessed. 256 The format of an Extension Header (EH) is shown in Figure 3. 258 0 1 2 3 259 01234567 89012345 6789012345678901 260 +--------+--------+----------------+ 261 | NH | HLEN | | 262 +--------+--------+ + 263 | | 264 ~ Header Specific Data ~ 265 | | 266 +--------+--------+----------------+ 268 Figure 3: EH Format 270 The meaning of the fields in an EH is as follows: 272 NH: 8-bit selector for the Next Header. This field identifies the 273 type of the EH immediately following this EH. 275 HLEN: 8-bit unsigned integer for the Extension Header Length in 276 4-octet units, not including the first 4 octets. 278 Header Specific Data: Variable length field for the specification of 279 the EH. This field is 4-octet aligned. 281 The extension headers as well as the first original upper layer 282 protocol header are chained together through the NH field in HEH and 283 EHs. The encoding of NH uses the same values as the IPv4 protocol 284 field. Values for new EH types shall be assigned by IANA. 286 Specifically, the NH field of the last EH in a chain can have two 287 special values, which shall be assigned by IANA: 289 NONE: Indicates that there is no any other header and payload after 290 this header. This can be used to transport packets with only 291 extension header(s). 293 UNKNOWN: Indicates that the type of the header after this header is 294 unknown. This is intended to be compatible with the original MPLS 295 design in which the upper layer protocol type is unknown from the 296 MPLS header alone. 298 3. Operation on MPLS Extension Headers 300 When the first EH X needs to be added to an MPLS packet, an EHL is 301 inserted into the proper location in the MPLS label stack. A HEH is 302 then inserted after the MPLS label stack, in which EHCNT is set to 1, 303 EHTLEN is set to the length of X in 4-octet units, and NH is set to 304 the header value of X. At last, X is inserted after the HEH, in 305 which NH and HELN are set accordingly. Note that if this operation 306 happens at a PE device, the upper layer protocol is known before the 307 MPLS encapsulation, so its value can be saved in the NH field if 308 desired. Otherwise, the NH field is filled with the value of 309 "UNKNOWN". 311 When an EH Y needs to be added to an MPLS packet which already 312 contains extension header(s), the EHCNT and EHTLEN in the HEH are 313 updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is 314 incremented by the size of Y in 4-octet units). Then a proper 315 location for Y in the EH chain is located. Y is inserted at this 316 location. The NH field of Y is copied from the previous EH's NH 317 field (or from the HEH's NH field, if Y is the first EH in the 318 chain). The previous EH's NH value, or, if Y is the first EH in the 319 chain, the HEH's NH, is set to the header value of Y. 321 Deleting an EH simply reverses the above operation. If the deleted 322 EH is the last one, the EHL and HEH can also be deleted. 324 When processing an MPLS packet with extension headers, the node needs 325 to scan through the entire EH chain and process the EH one by one. 326 The node should ignore any unrecognized EH. 328 4. Use Cases 330 In this section, we show how MPLS extension header can be used to 331 support several new network applications. 333 In-situ OAM: In-situ OAM (IOAM) records flow OAM information within 334 user packets while the packets traverse a network. The 335 instruction and collected data are kept in an IOAM header 336 [I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network, 337 the IOAM header can be encapsulated as an MPLS extension header. 339 NSH: Network Service Header (NSH) [RFC8300] provides a service plane 340 for Service Function Chaining (SFC). NSH maintains the SFC 341 context and metadata. If MPLS is used as the transport protocol 342 for NSH, NSH can be encapsulated as an MPLS extension header. 344 Network Telemetry and Measurement: A network telemetry and 345 instruction header can be carried as an extension header to 346 instruct a node what type of network measurements should be done. 347 For example, the method described in [RFC8321] can be implemented 348 in MPLS networks since the EH provides a natural way to color MPLS 349 packets. 351 Network Security: Security related functions often require user 352 packets to carry some metadata. In a DoS limiting network 353 architecture, a "packet passport" header is used to embed packet 354 authentication information for each node to verify. 356 Segment Routing: MPLS extension header can support the 357 implementation of a new flavor of the MPLS-based segment routing, 358 with better performance and richer functionalities. The details 359 will be described in another draft. 361 With MPLS extension headers, multiple in-network applications can be 362 stacked together. For example, IOAM and SFC can be applied at the 363 same time to support network OAM and service function chaining. A 364 node can stop scanning the extension header stack if all the known 365 headers it can process have been located. For example, if IOAM is 366 the first EH in a stack and a node is configured to process IOAM 367 only, it will stop searching the EH stack when the IOAM EH is found. 369 5. Summary 371 Evidenced by the existing and emerging use cases, MPLS networks need 372 a standard way to support extension headers. In Figure 4, we 373 summarize the potential schemes that allow MPLS packets to carry 374 extension headers and list the main issues for each scheme. 376 +---+---------------------------+---------------------------------+ 377 |No.| Description | Issues | 378 +---+---------------------------+---------------------------------+ 379 | 1 | GAL + MCH with multi- |- Label location limitation lead | 380 | | header extension | to performance concern | 381 | | |- Interfere with load balancing | 382 | | | and DPI functions | 383 | | |- Overlaod GAL semantics | 384 | | |- Need standard extension | 385 +---+---------------------------+---------------------------------+ 386 | 2 | GAL + another nibble value|- Same as above | 387 | | to encode the EHs (e.g., | | 388 | | "0010") | | 389 +---+---------------------------+---------------------------------+ 390 | 3 | FEC label to indicate EH |- Complex control plane | 391 +---+---------------------------+---------------------------------+ 392 | 4 | XL(15) + EHL |- One extra label | 393 | | |- Need standard extension | 394 +---+---------------------------+---------------------------------+ 395 | 5 | Sepcial EHL |- Need standard extension | 396 +---+---------------------------+---------------------------------+ 398 Figure 4: Potential Schemes for MPLS Extension Headers 400 Through comprehensive considerations on the pros and cons of each 401 scheme, we currently recommend the scheme No.5. The proposed MPLS 402 extension header scheme provides a generic way to support in-network 403 services and functions in MPLS networks. 405 6. Security Considerations 407 TBD 409 7. IANA Considerations 411 This document requires IANA to assign a new special MPLS label value 412 ("EHL") which is dedicated to indicate the presence of MPLS extension 413 header(s). 415 This document also requires IANA to assign two new protocol numbers 416 which are used to indicate no next header ("NONE") or an unknown next 417 header ("UNKNOWN"). 419 The new header type values shall be assigned by IANA on a case-by- 420 case basis. 422 8. Contributors 424 The other contributors of this document are listed as follows. 426 o James Guichard 428 o Stewart Bryant 430 o Andrew Malis 432 9. Acknowledgments 434 TBD. 436 10. References 438 10.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 446 "MPLS Generic Associated Channel", RFC 5586, 447 DOI 10.17487/RFC5586, June 2009, 448 . 450 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 451 Chaining (SFC) Architecture", RFC 7665, 452 DOI 10.17487/RFC7665, October 2015, 453 . 455 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 456 "Network Service Header (NSH)", RFC 8300, 457 DOI 10.17487/RFC8300, January 2018, 458 . 460 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 461 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 462 "Alternate-Marking Method for Passive and Hybrid 463 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 464 January 2018, . 466 10.2. Informative References 468 [I-D.brockners-inband-oam-requirements] 469 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 470 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 471 T., <>, P., and r. remy@barefootnetworks.com, 472 "Requirements for In-situ OAM", draft-brockners-inband- 473 oam-requirements-03 (work in progress), March 2017. 475 [I-D.brockners-inband-oam-transport] 476 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 477 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 478 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 479 situ OAM Data", draft-brockners-inband-oam-transport-05 480 (work in progress), July 2017. 482 [I-D.filsfils-spring-srv6-network-programming] 483 Filsfils, C., Camarillo, P., Leddy, J., 484 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 485 Network Programming", draft-filsfils-spring-srv6-network- 486 programming-05 (work in progress), July 2018. 488 [I-D.guichard-sfc-mpls-metadata] 489 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 490 "Carrying Metadata in MPLS Networks", draft-guichard-sfc- 491 mpls-metadata-00 (work in progress), September 2013. 493 [I-D.ietf-ippm-ioam-data] 494 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 495 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 496 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 497 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 498 data-03 (work in progress), June 2018. 500 [I-D.ietf-spring-segment-routing] 501 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 502 Litkowski, S., and R. Shakir, "Segment Routing 503 Architecture", draft-ietf-spring-segment-routing-15 (work 504 in progress), January 2018. 506 [I-D.xu-clad-spring-sr-service-chaining] 507 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 508 d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, 509 S., and S. Ma, "Segment Routing for Service Chaining", 510 draft-xu-clad-spring-sr-service-chaining-00 (work in 511 progress), December 2017. 513 Authors' Addresses 515 Haoyu Song (editor) 516 Huawei 517 2330 Central Expressway 518 Santa Clara 519 USA 521 Email: haoyu.song@huawei.com 523 Zhenbin Li 524 Huawei 525 156 Beiqing Road 526 Beijing, 100095 527 P.R. China 529 Email: lizhenbin@huawei.com 531 Tianran Zhou 532 Huawei 533 156 Beiqing Road 534 Beijing, 100095 535 P.R. China 537 Email: zhoutianran@huawei.com