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