idnits 2.17.00 (12 Aug 2021) /tmp/idnits36317/draft-song-mpls-extension-header-02.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 (February 5, 2019) is 1201 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) == Unused Reference: 'RFC5586' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'I-D.guichard-sfc-mpls-metadata' is defined on line 438, but no explicit reference was found in the text ** 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-06 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-04 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 3 errors (**), 0 flaws (~~), 7 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 Z. Li 4 Intended status: Standards Track T. Zhou 5 Expires: August 9, 2019 Huawei 6 L. Andersson 7 Bronze Dragon Consulting 8 February 5, 2019 10 MPLS Extension Header 11 draft-song-mpls-extension-header-02 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 and optimize some existing 22 network services. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119][RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 9, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. MPLS Extension Header . . . . . . . . . . . . . . . . . . . . 4 68 3. Type of MPLS Extension Headers . . . . . . . . . . . . . . . 7 69 4. Operation on MPLS Extension Headers . . . . . . . . . . . . . 7 70 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Motivation 82 Some applications require adding instructions and/or metadata to user 83 packets within a network. Such examples include In-situ OAM (IOAM) 84 [I-D.brockners-inband-oam-requirements] and Service Function Chaining 85 (SFC) [RFC7665]. New applications are emerging. It is possible that 86 the instructions and/or metadata for multiple applications are 87 stacked together in one packet to support a compound service. 89 Conceivably, such instructions and/or metadata would be encoded as 90 new headers and encapsulated in user packets. Such headers may 91 require to be processed in fast path or in slow path. Moreover, such 92 headers may require being attended at each hop on the forwarding path 93 (i.e., hop-by-hop or HBH) or at designated end nodes (i.e., end-to- 94 end or E2E). 96 The encapsulation of the new header(s) poses some challenges to MPLS 97 networks, because the MPLS protocol header contains no explicit 98 indicator for the upper layer protocols by design. We leave the 99 discussion on the indicator of new header(s) in an MPLS packet to 100 another companion document. In this document, we focus on the encode 101 and encapsulation of new headers in an MPLS packet. 103 The similar problem has been tackled for some particular application 104 before. However, the solutions have some drawbacks: 106 o These solutions rely on either the built-in next-protocol 107 indicator in the header or the knowledge of the format and size of 108 the header to access the following packet data. The node is 109 required to be able to parse the new header, which is unrealistic 110 in an incremental deployment environment. 112 o A piecemeal solution often assumes the new header is the only 113 extra header and its location in the packet is fixed by default. 114 It is impossible or difficult to support multiple new headers in 115 one packet due to the conflicted assumption. 117 To solve these issues, we propose to introduce extension header as a 118 general and extensible means to support new in-network functions and 119 applications in MPLS networks. The idea is similar to IPv6 extension 120 headers which offer a huge innovation potential (e.g, network 121 security, SRv6 [I-D.ietf-spring-segment-routing], network programming 122 [I-D.filsfils-spring-srv6-network-programming], SFC 123 [I-D.xu-clad-spring-sr-service-chaining], etc.). Thanks to the 124 existing of extension headers, it is straightforward to introduce new 125 in-network services into IPv6 networks. For example, it has been 126 proposed to carry IOAM header [I-D.brockners-inband-oam-transport] as 127 a new extension header in IPv6 networks. 129 Nevertheless, IPv6 is not perfect either. It has two main issues. 130 First, IPv6's header is large compared to MPLS, claiming extra 131 bandwidth overhead and complicating the packet processing. We prefer 132 to retain the header compactness in MPLS networks. Second, IPv6's 133 extension headers are chained with the original upper layer protocol 134 headers in a flat stack. One must scan all the extension headers to 135 access the upper layer protocol headers and the payload. This is 136 inconvenient and raises some performance concerns for some 137 applications (e.g., DPI and ECMP). The new scheme for MPLS header 138 extension needs to address these issues too. 140 2. MPLS Extension Header 142 From the previous discussion, we have laid out the design 143 requirements to support extension headers in MPLS networks: 145 Performance: If possible, unnecessary label stack scanning for a 146 label and extension header stack scanning for the upper layer 147 protocol should be avoided. 149 Scalability: New applications can be easily supported by introducing 150 new extension headers. Multiple extension headers can be easily 151 stacked together to support multiple services simultaneously. 153 Backward Compatibility: Legacy devices which do not recognize the 154 extension header option should still be able to forward the 155 packets as usual. If a device recognize some of the extension 156 headers but not the others in an extension header stack, it can 157 process the known headers only while ignoring the others. 159 We assume the MPLS label stack has included some indicator of the 160 extension header(s). The actual extension headers are inserted 161 between the MPLS label stack and the original upper layer packet 162 header. The format of the MPLS packets with extension headers is 163 shown in Figure 1. 165 0 31 166 +--------+--------+--------+--------+ - 167 | | | 168 ~ MPLS Label Stack ~ | 169 | | | 170 +--------+--------+--------+--------+ | 171 | EH Indicator (TBD) | > MPLS Label Stack 172 +--------+--------+--------+--------+ | (extended with EHI) 173 | | | 174 ~ MPLS Label Stack ~ | 175 | | | 176 +--------+--------+--------+--------+ = 177 | Header of Extension Headers (HEH) | | 178 +--------+--------+--------+--------+ | 179 | | | 180 ~ Extension Header (EH) 1 ~ | 181 | | | 182 +--------+--------+--------+--------+ > MPLS EH Fields 183 ~ ~ | (new) 184 +--------+--------+--------+--------+ | 185 | | | 186 ~ Extension Header (EH) N ~ | 187 | | | 188 +--------+--------+--------+--------+ = 189 | | | 190 ~ Upper Layer Headers/Payload ~ > MPLS Payload 191 | | | (as is) 192 +--------+--------+--------+--------+ - 194 Figure 1: MPLS with Extension Headers 196 Following the MPLS label stack is the 4-octet Header of Extension 197 Headers (HEH), which indicates the total number of extension headers 198 in this packet, the overall length of the extension headers, and the 199 type of the next header. The format of the HEH is shown in Figure 2. 201 0 1 2 3 202 0123 45678901 234567890123 45678901 203 +----+--------+------------+--------+ 204 | R | EHCNT | EHTLEN | NH | 205 +----+--------+------------+--------+ 207 Figure 2: HEH Format 209 The meaning of the fields in an HEH is as follows: 211 R: 4-bit reserved. 213 EHCNT: 8-bit unsigned integer for the Extension Header Counter. 214 This field keeps the total number of extension headers included in 215 this packet. It does not count the original upper layer protocol 216 headers. 218 EHTLEN: 12-bit unsigned integer for the Extension Header Total 219 Length in 4-octet units. This field keeps the total length of the 220 extension headers in this packet, not including the HEH itself. 222 NH: 8-bit selector for the Next Header. This field identifies the 223 type of the header immediately following the HEH. 225 The EHCNT field can be used to keep track of the number of extension 226 headers when some headers are inserted or removed at some network 227 nodes. The EHLEN field can help to skip all the extension headers in 228 one step if the original upper layer protocol headers or payload need 229 to be accessed. 231 The format of an Extension Header (EH) is shown in Figure 3. 233 0 1 2 3 234 01234567 89012345 6789012345678901 235 +--------+--------+----------------+ 236 | NH | HLEN | | 237 +--------+--------+ + 238 | | 239 ~ Header Specific Data ~ 240 | | 241 +--------+--------+----------------+ 243 Figure 3: EH Format 245 The meaning of the fields in an EH is as follows: 247 NH: 8-bit selector for the Next Header. This field identifies the 248 type of the EH immediately following this EH. 250 HLEN: 8-bit unsigned integer for the Extension Header Length in 251 4-octet units, not including the first 4 octets. 253 Header Specific Data: Variable length field for the specification of 254 the EH. This field is 4-octet aligned. 256 The extension headers as well as the first original upper layer 257 protocol header are chained together through the NH field in HEH and 258 EHs. The encoding of NH uses the same values as the IPv4 protocol 259 field. Values for new EH types shall be assigned by IANA. 261 Specifically, the NH field of the last EH in a chain can have two 262 special values, which shall be assigned by IANA: 264 NONE (No Next Header): Indicates that there is no other header and 265 payload after this header. This can be used to transport packets 266 with only extension header(s). 268 UNKNOWN (Unknown Next Header): Indicates that the type of the header 269 after this header is unknown. This is intended to be compatible 270 with the original MPLS design in which the upper layer protocol 271 type is unknown from the MPLS header alone. 273 3. Type of MPLS Extension Headers 275 Basically, there are two types of MPLS EHs: HBH and E2E. E2E means 276 that the EH is only supposed to be inserted/removed and processed at 277 the MPLS tunnel end points where the MPLS header is inserted or 278 removed. The EHs that are inserted or removed within the MPLS tunnel 279 are of the HBH type. However, any node in the tunnel can be 280 configured to ignore an HBH EH, even if it is capable of processing 281 the EH. 283 If there are two types of EHs in a packet, the HBH EHs must take 284 precedence over the E2E EHs. 286 Making a distinction of the EH types and ordering the EHs in a packet 287 help improve the forwardidng performance. For example, if a node 288 within an MPLS tunnel finds only E2E EHs in a packet, it can avoid 289 scanning the EH list. 291 4. Operation on MPLS Extension Headers 293 When the first EH X needs to be added to an MPLS packet, an EH 294 indicator is inserted into the proper location in the MPLS label 295 stack. A HEH is then inserted after the MPLS label stack, in which 296 EHCNT is set to 1, EHTLEN is set to the length of X in 4-octet units, 297 and NH is set to the header value of X. At last, X is inserted after 298 the HEH, in which NH and HELN are set accordingly. Note that if this 299 operation happens at a PE device, the upper layer protocol is known 300 before the MPLS encapsulation, so its value can be saved in the NH 301 field if desired. Otherwise, the NH field is filled with the value 302 of "UNKNOWN". 304 When an EH Y needs to be added to an MPLS packet which already 305 contains extension header(s), the EHCNT and EHTLEN in the HEH are 306 updated accordingly (i.e., EHCNT is incremented by 1 and EHTLEN is 307 incremented by the size of Y in 4-octet units). Then a proper 308 location for Y in the EH chain is located. Y is inserted at this 309 location. The NH field of Y is copied from the previous EH's NH 310 field (or from the HEH's NH field, if Y is the first EH in the 311 chain). The previous EH's NH value, or, if Y is the first EH in the 312 chain, the HEH's NH, is set to the header value of Y. 314 Deleting an EH simply reverses the above operation. If the deleted 315 EH is the last one, the EH indicator and HEH can also be removed. 317 When processing an MPLS packet with extension headers, the node needs 318 to scan through the entire EH chain and process the EH one by one. 319 The node should ignore any unrecognized EH. 321 The EH can be categorized into HBH or E2E. If the EH indicator can 322 indicate the EH types and the EHs are ordered (i.e., HBH EHs are 323 located before E2E EHs), a node can avoid some unnecessary EH scan. 325 5. Use Cases 327 In this section, we show how MPLS extension header can be used to 328 support several new network applications. 330 In-situ OAM: In-situ OAM (IOAM) records flow OAM information within 331 user packets while the packets traverse a network. The 332 instruction and collected data are kept in an IOAM header 333 [I-D.ietf-ippm-ioam-data]. When applying IOAM in an MPLS network, 334 the IOAM header can be encapsulated as an MPLS extension header. 336 Network Telemetry and Measurement: A network telemetry and 337 instruction header can be carried as an extension header to 338 instruct a node what type of network measurements should be done. 339 For example, the method described in [RFC8321] can be implemented 340 in MPLS networks since the EH provides a natural way to color MPLS 341 packets. 343 Network Security: Security related functions often require user 344 packets to carry some metadata. In a DoS limiting network 345 architecture, a "packet passport" header is used to embed packet 346 authentication information for each node to verify. 348 Segment Routing and Network Programming: MPLS extension header can 349 support the implementation of a new flavor of the MPLS-based 350 segment routing, with better performance and richer 351 functionalities. The details will be described in another draft. 353 With MPLS extension headers, multiple in-network applications can be 354 stacked together. For example, IOAM and SFC can be applied at the 355 same time to support network OAM and service function chaining. A 356 node can stop scanning the extension header stack if all the known 357 headers it can process have been located. For example, if IOAM is 358 the first EH in a stack and a node is configured to process IOAM 359 only, it will stop searching the EH stack when the IOAM EH is found. 361 6. Security Considerations 363 TBD 365 7. IANA Considerations 367 This document requests IANA to assign two new Internet Protocol 368 Numbers from the "Protocol Numbers" Registry to indicate "No Next 369 Header" or "Unknown Next Header". 371 This document does not create any new registries. 373 8. Contributors 375 The other contributors of this document are listed as follows. 377 o James Guichard 379 o Stewart Bryant 381 o Andrew Malis 383 9. Acknowledgments 385 TBD. 387 10. References 389 10.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 397 "MPLS Generic Associated Channel", RFC 5586, 398 DOI 10.17487/RFC5586, June 2009, 399 . 401 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 402 Chaining (SFC) Architecture", RFC 7665, 403 DOI 10.17487/RFC7665, October 2015, 404 . 406 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 407 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 408 May 2017, . 410 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 411 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 412 "Alternate-Marking Method for Passive and Hybrid 413 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 414 January 2018, . 416 10.2. Informative References 418 [I-D.brockners-inband-oam-requirements] 419 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 420 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 421 T., Lapukhov, P., and r. remy@barefootnetworks.com, 422 "Requirements for In-situ OAM", draft-brockners-inband- 423 oam-requirements-03 (work in progress), March 2017. 425 [I-D.brockners-inband-oam-transport] 426 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 427 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 428 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 429 situ OAM Data", draft-brockners-inband-oam-transport-05 430 (work in progress), July 2017. 432 [I-D.filsfils-spring-srv6-network-programming] 433 Filsfils, C., Camarillo, P., Leddy, J., 434 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 435 Network Programming", draft-filsfils-spring-srv6-network- 436 programming-06 (work in progress), October 2018. 438 [I-D.guichard-sfc-mpls-metadata] 439 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 440 "Carrying Metadata in MPLS Networks", draft-guichard-sfc- 441 mpls-metadata-00 (work in progress), September 2013. 443 [I-D.ietf-ippm-ioam-data] 444 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 445 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 446 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 447 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 448 data-04 (work in progress), October 2018. 450 [I-D.ietf-spring-segment-routing] 451 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 452 Litkowski, S., and R. Shakir, "Segment Routing 453 Architecture", draft-ietf-spring-segment-routing-15 (work 454 in progress), January 2018. 456 [I-D.xu-clad-spring-sr-service-chaining] 457 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 458 d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano, 459 S., and S. Ma, "Segment Routing for Service Chaining", 460 draft-xu-clad-spring-sr-service-chaining-00 (work in 461 progress), December 2017. 463 Authors' Addresses 465 Haoyu Song (editor) 466 Huawei 467 2330 Central Expressway 468 Santa Clara 469 USA 471 Email: haoyu.song@huawei.com 473 Zhenbin Li 474 Huawei 475 156 Beiqing Road 476 Beijing, 100095 477 P.R. China 479 Email: lizhenbin@huawei.com 481 Tianran Zhou 482 Huawei 483 156 Beiqing Road 484 Beijing, 100095 485 P.R. China 487 Email: zhoutianran@huawei.com 489 Loa Andersson 490 Bronze Dragon Consulting 491 Stockholm 492 Sweden 494 Email: loa@pi.nu