idnits 2.17.1 draft-bryant-mpls-dev-primer-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2021) is 1121 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.kompella-mpls-mspl4f' is mentioned on line 314, but not defined == Missing Reference: 'I-D.li-mpls-enhanced-vpn-vtn-id' is mentioned on line 343, but not defined == Missing Reference: 'I-D.stein-srtsn' is mentioned on line 361, but not defined == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-architecture-00 == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-label-stack-operations-00 == Outdated reference: A later version (-06) exists of draft-gandhi-mpls-ioam-sr-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-04) exists of draft-kompella-mpls-nffrr-01 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-02 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-08 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS S. Bryant 3 Internet-Draft Futurewei US 4 Intended status: Informational March 31, 2021 5 Expires: October 2, 2021 7 A Primer on the Development of MPLS 8 draft-bryant-mpls-dev-primer-00 10 Abstract 12 There has been significant recent interest in developing MPLS to 13 address new needs. This memo collects together various documents 14 that together describe the key aspects of the MPLS architecture 15 together with the development proposals that the author is aware of. 17 The purpose of this document is to bring everyone up to speed on the 18 rational for the existing design and to alert them to the new 19 proposals. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 2, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Background Documents . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Multiprotocol Label Switching Architecture (RFC 3031) . . 3 58 2.2. MPLS Label Stack Encoding (RFC 3032) . . . . . . . . . . 4 59 2.3. Control Word for Use over an MPLS PSN (RFC5586) . . . . . 4 60 2.4. Avoiding Equal Cost Multipath (ECMP) Treatment in MPLS 61 Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.5. Synonymous Flow Labels . . . . . . . . . . . . . . . . . 5 63 2.6. Residence Time Measurement in MPLS Networks . . . . . . . 5 64 3. New Proposals . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. MPLS Extension Header Architecture . . . . . . . . . . . 5 66 3.2. MPLS Label Operations in MPLS EH capable networks . . . . 6 67 3.3. Encapsulation For MPLS Performance Measurement with 68 Alternate Marking . . . . . . . . . . . . . . . . . . . . 7 69 3.4. MPLS Data Plane Encapsulation for In-situ OAM Data . . . 7 70 3.5. Multi-purpose Special Purpose Label for Forwarding 71 Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.6. No Further Fast Reroute . . . . . . . . . . . . . . . . . 8 73 3.7. Carrying Virtual Transport Network Identifier in MPLS 74 Packet . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.8. Segment Routed Time Sensitive Networking . . . . . . . . 8 76 3.9. Options for MPLS Extension Header Indicator . . . . . . . 8 77 3.10. MPLS Extension Header . . . . . . . . . . . . . . . . . . 9 78 3.11. MPLS Payload Protocol Identifier . . . . . . . . . . . . 9 79 3.12. Generic Transport Functions . . . . . . . . . . . . . . . 10 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 6.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 There has been significant recent interest in developing the MPLS 90 data plane to address new needs. This memo collects together various 91 documents that together describe the key aspects of the MPLS 92 architecture together with the development proposals that the author 93 is aware of. 95 The intent of this work is to bring everyone up to speed on the 96 rational for the existing design and to alert them to the new 97 proposals. If I have missed any proposals, then please accept my 98 apologies for the oversight, let me know and I will include it in the 99 list. 101 I do not anticipate that this memo will progress to become an RFC. 103 The interest in this work to develop MPLS was noted by the Chairs of 104 the DETNET, MPLS, PALS, and SPRING IETF working groups who called a 105 joint meeting at IETF 110. The agenda, slides notes etc of the 106 meeting are currently at https://datatracker.ietf.org/meeting/agenda/ 108 Editor's note the above URL will change when the meeting is included 109 in the IETF Proceedings. 111 A video recording of the meeting is to be found at https://youtu.be/ 112 rt_vQTToO1s 114 2. Background Documents 116 2.1. Multiprotocol Label Switching Architecture (RFC 3031) 118 [RFC3031] describes the base architecture of MPLS. This is updated 119 by: 121 o [RFC6178] which describes label edge router forwarding of IPv4 122 option packets and is not relevant to this discussion. 124 o [RFC6790] which describes the use of entropy labels in MPLS 125 forwarding. The entropy label is a two stack entry tuple that 126 consists of a special purpose label (SPL) followed by a label 127 stack entry (LSE) who's label is pure entropy to be applied to the 128 selection of a path from the Equal Cost Multi-Path (ECMP) set. 129 Its use in choosing the ECMP member is optional. This was the 130 first formal introduction of the concept of an MPLS forwarder 131 needing to parse below the top of the label stack. 133 Prior to the introduction of RFC 6790 it was already common practice 134 for LSRs to scan the label stack to the bottom of stack (a simple 135 task requiring the checking of a single bit in each LSE) to 136 heuristically check that the packet was IP and if so to hash the five 137 tuple to determine the ECMP path to use. 139 This approach worked well until Ethernet addresses were 140 (legitimately) deployed that confused these forwarders into thinking 141 that Ethernet packets were IP packets ((RFC8469}}. 143 2.2. MPLS Label Stack Encoding (RFC 3032) 145 [RFC3032] Specifies the encoding of an MPLS LSE. This has been 146 updated by: 148 o [RFC3443] describes the two models of TTL handling in MPLS. In 149 addition that it should be noted that some LSR decrement the TTL 150 of the TOP label _before_ inspecting the label in the top LSE. 152 o [RFC3270] describes the application of diffserv to MPLS and the 153 pipe vs uniform models. It may apply to this work if we are 154 popping xSPLs. 156 EDITOR'S NOTE need to think [RFC3270] some more. 158 o [RFC5129] describes Explicit Congestion Marking in MPLS. It is 159 not clear how widely this is deployed. This is something that 160 needs to be thought through when re-purposing the TC bits as has 161 been proposed in some of the drafts listed below. 163 o [RFC5462] renames the EXP field to TC field. This is a naming 164 convention and not a technology change. 166 o [RFC5586] defines the Generic Associated Channel (see later). 168 o [RFC7274] defines the process for allocating and retiring special 169 purpose labels (SPLs) (formerly known as Reserved Labels). It 170 also creates the extended special purpose labels (eSPLs). eSPLs 171 are another instance of a twin label in the stack, with the first 172 label (15) from the SPL range followed by another label that 173 specifies the function of the twin labels. 175 2.3. Control Word for Use over an MPLS PSN (RFC5586) 177 [RFC5586] describes the first use of a type of meta-data between the 178 bottom of the MPLS label stack and the packet payload. The 179 pseudowire (PW) control word (CW) is used to carry additional 180 information that the egress Provider Edge (PE) LSR needs to construct 181 the outgoing packet. It also tells the forwarder that the packet is 182 not an IP packet and so should not be subjected to ECMP. 184 [RFC8469] is an update to the Ethernet PW specification [RFC4448] to 185 strongly encourage the use of the CW for Ethernet PWs. All other PWs 186 that have been defined require the use of the CW. 188 2.4. Avoiding Equal Cost Multipath (ECMP) Treatment in MPLS Network 190 [RFC4928] describes the issue of accidental ECMP of packets not carry 191 IP. This arises because some forwarders accidentally mistake a non- 192 IP packet for an IP packet. They use a heuristic method of 193 determining that the packet is IP. They sometimes get this wrong 194 causing a misordered the delivery of some of the packets. [RFC4928] 195 formally introduces the concept of using the first nibble of 0b0000 196 to avoid this. Note that the technique is actually older than this 197 having been introduced in [RFC4385]. 199 2.5. Synonymous Flow Labels 201 [RFC8957] describes a technique whereby additional labels are 202 introduced to an MPLS network that mimic the behavior of other MPLS 203 labels but also introduce new properties to the FEC. The main use is 204 to trigger OAM actions, but the method can be used to trigger other 205 agreed actions. 207 2.6. Residence Time Measurement in MPLS Networks 209 [RFC8169] describes a method of measuring the dwell or residence time 210 of a packet in a router. The time is accumulated in a G-ACh packet 211 carried below the label stack. Note that the G-ACh uses first nibble 212 = 0b0001. This is the first instance of a G-ACh packet being 213 specified for operation on a user data packet. 215 The data packet is carried over an RSVP-TE path and thus the top of 216 stack label indicates to the forwarder both the next-hop and outgoing 217 label, but also indicates the presence of the G-ACh and the need to 218 perform the residence time accumulation. 220 The RFC predates segment routing (SR) and does not mention Software 221 Defined Networks (SDNS), but the method could be used in those 222 environments. 224 3. New Proposals 226 This section catalogues new proposals for how metadata is carried and 227 how its presence is indicated to the forwarder. 229 3.1. MPLS Extension Header Architecture 231 [I-D.andersson-mpls-eh-architecture] specifies an architecture for 232 the extension of MPLS to include Extension Headers (EH). The 233 proposal is for the EHs to carry information on in-network services 234 and functions in an MPLS network. The extension headers are carried 235 after the MPLS Label Stack, and the presence of EHs are indicated in 236 the label stack by an Extension Header Indicator (EHI). 238 Proposed use cases are: 240 o In-situ OAM 242 o Network Telemetry and Measurement 244 o Network Security 246 o Segment Routing 248 o Network Programming 250 The draft calls two types of EH: 252 o "hop-by-hop" (HBH) 254 o "End to end" (E2E). 256 The draft proposes to indicate the presence of the EH via the FEC. 257 The ability of a router on the LSP to process a packet correctly is 258 advertised in the routing protocol. 260 3.2. MPLS Label Operations in MPLS EH capable networks 262 [I-D.andersson-mpls-eh-label-stack-operations] provides the operating 263 procedures for EH-capable and non-EH-capable LSRs where MPLS 264 Extension Headers (EH) are carried below the MPLS label stack. 265 Further this describes how MPLS EHs can be gradually introduced into 266 an existing MPLS network. The capability to handle EHs is announced 267 throughout the MPLS network, and LSRs that don't understand this 268 information simply ignore it. 270 The extension headers are carried after the MPLS Label Stack, and the 271 presence of EHs are indicate in the label stack by a Extended Special 272 Purpose label called Extension Header Indicator (EHI) in the label 273 stack. 275 The EH(s) are carried over a G-ACh. Three ACHs are suggested E2E, 276 HBH, Both. A number of EHs can be accommodated with the number being 277 indicated by a parameter in the ACH. 279 The draft considers the stack structure in a number of cases such as 280 VPN (and presumably PW) and non-VPN (native IP payload) cases. 282 The draft shows how RSVP-TE signaling would work. 284 3.3. Encapsulation For MPLS Performance Measurement with Alternate 285 Marking 287 [I-D.cheng-mpls-inband-pm-encapsulation] shows how a flow ID can be 288 carried in a packet. The application is Alternate Marking (AM) and 289 includes an indicator of the measurement type. 291 In an early version it was proposed that an SPL was used, but in the 292 latest version an eSPL is proposed, in both cases at the bottom of 293 stack. 295 The draft discusses IP and VPN, but it is not clear if this what 296 happens in the PW case. 298 3.4. MPLS Data Plane Encapsulation for In-situ OAM Data 300 [I-D.gandhi-mpls-ioam-sr] shows how the IOAM data fields defined in 301 [I-D.ietf-ippm-ioam-data] could be carried in MPLS. It carries the 302 OAM data in an G-Ach and specifies both hop-by-hop and end-to-end 303 versions. 305 The OAM present/type indicator is an e(SPL) at the bottom of the MPLS 306 label stack requiring a P-router to scan the stack to find the label. 308 The draft proposes the stacking of G-Ach blocks at the bottom of 309 stack with the IOAM G-Ach first and any subsequent G-Ach located 310 through the use of a length field in the IOAM G-Ach. 312 3.5. Multi-purpose Special Purpose Label for Forwarding Actions 314 [I-D.kompella-mpls-mspl4f] notes that the forwarder does not need to 315 use the TC, or TTL fields in an LSE that does not become top of 316 stack. It proposes to exploit these fields as indicators of 317 forwarding actions, by modifying the semantics of these fields. 319 There are a number of key proposals in the draft: 321 o Using the "spare bits" as forwarding indicator flags to specify 322 actions or in some cases inactions 324 o Using the method to multi-purpose SPLs and thus expand the number 325 of single label SPLs available to the IETF. 327 o Reusing the Entropy Label fields to carry additional data needed 328 by the forwarder. This latter point could be adopted by any eSPL. 329 One use for this additional data that was proposed (certainly in 330 discussion but I cannot see it in the draft) was the use of this 331 facility to carry a network slice identifier. 333 3.6. No Further Fast Reroute 335 [I-D.kompella-mpls-nffrr] proposes the use of an SPL (note not an 336 eSPL) to indicate that a fast re-route action is not to be undertaken 337 on the packet. 339 Uses an SPL for this single purpose 341 3.7. Carrying Virtual Transport Network Identifier in MPLS Packet 343 [I-D.li-mpls-enhanced-vpn-vtn-id] is a method of carrying a virtual 344 network identifier in an MPLS packet. It does this by carrying meta- 345 data below the MPLS label stack. It does not use the G-ACh but 346 instead a new design with a first nibble value of 0b0011. 348 Note that when we define new first nibbles we are technically taking 349 IP versions away from the IETF Internet Area. When PWE3 first 350 proposed this we agreed with the IETF of the day that we would only 351 take 0b0000 and 0b0001. I am looking to see if this agreement was 352 documented. 354 The presence of the VTN is indicted by an SPL (note not an eSPL) 355 somewhere in the label stack. The draft discusses how multiple VTNs 356 can be placed in the packet, but not how multiple types of meta-data 357 are to be carried. 359 3.8. Segment Routed Time Sensitive Networking 361 [I-D.stein-srtsn] describes how information can be encoded in the 362 MPLS label stack to inform the forwarder when a time sensitive packet 363 should be sent. Each LSE becomes 64 bits, the first 32 bits a 364 conventional MPLS label and the second part contains dispatch time 365 information. 367 Note that as far as I can see there is no provision for an S bit 368 making label stack scanning for other information liable to make a 369 mistake. 371 There is no information that I can see stating how the LSR knows that 372 the LSE is in this format and so I assume that it knows from the FEC. 374 3.9. Options for MPLS Extension Header Indicator 376 [I-D.song-mpls-extension-header] provides a catalogue of methods of 377 identifying the presence of presence of an extension header after the 378 label stack. The methods could of course be used for identifying the 379 presence of some other structure after the label stack. 381 The methods listed are: 383 o A special purpose label 385 o An extended special purpose label pair 387 o A GAL and an associated channel header 389 o A GAL followed by a structure with a different first nibble value 391 o The use of a new FEC 393 3.10. MPLS Extension Header 395 [I-D.song-mpls-extension-header] describes a design for an MPLS 396 extension header to be placed after the MPLS label stack. The Header 397 of Extension Headers (HEH) specifies the number of extension headers 398 that follow. The HEH has the four bit ECMP defeat nibble, a count of 399 number of extension headers, the length of the set of extension 400 headers and the type of the following extension header. An Extension 401 Header (EH) starts with the type of the header that follows this EH, 402 the length of this EH followed by the EH data/payload. 404 Two generic types of EH as specified, End to End and Hop by Hop. 406 3.11. MPLS Payload Protocol Identifier 408 [I-D.xu-mpls-payload-protocol-identifier] describes a method of 409 adding a protocol identifier (PID) to an MPLS packet. 411 A 16 bit PID is carried in a 32 bit structure following the label 412 stack. The structure just has an ECMP defeat nibble 0b000 and the 413 PID. 415 Presence of the PID is indicated by an SPL or an eSPL at the bottom 416 of stack. 418 An alternative method of indicating the PIL is also proposed by using 419 a first nibble of 0b1111. Note that this might be defeated by an 420 MPLS payload other than IP. For reasons discussed in [RFC8469] in 421 this arrangement the PIL could not be used at a mid-point, but would 422 be safe at an endpoint. The first nibble comments in {#VTN} also 423 apply to this proposal. 425 No provision is made for carrying other data beyond the bottom of 426 stack, and there is no discussion on how this works with VPNs and 427 PWs. 429 3.12. Generic Transport Functions 431 [I-D.zzhang-tsvwg-generic-transport-functions] describes a method of 432 adding fragmentation to a number of protocols including MPLS. The 433 fragmentation header follows the end of stack. It does not take any 434 ECMP precautions through the first nibble. Some mitigation could be 435 achieved by the use of the ELI/EL where the P routers can support 436 this. 438 Indication of the fragmentation header is indicated by the FEC. 440 Note that the draft referenced pseudowires (PWs) and that PWs have a 441 fragmentation method [RFC4623]. However this feature is not thought 442 to be widely implemented. 444 4. Security Considerations 446 Any changes to the MPLS security model as a result of a change will 447 need to be considered within the proposals themselves. This document 448 is a catalog of existing RFCs and design proposals and does not 449 itself modify the security of MPLS networks. 451 5. IANA Considerations 453 This document has no IANA requests. 455 6. References 457 6.1. Normative References 459 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 460 Label Switching Architecture", RFC 3031, 461 DOI 10.17487/RFC3031, January 2001, 462 . 464 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 465 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 466 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 467 . 469 6.2. Informative References 471 [I-D.andersson-mpls-eh-architecture] 472 Andersson, L., Guichard, J., Song, H., and S. Bryant, 473 "MPLS Extension Header Architecture", draft-andersson- 474 mpls-eh-architecture-00 (work in progress), February 2019. 476 [I-D.andersson-mpls-eh-label-stack-operations] 477 Andersson, L., Guichard, J., Song, H., and S. Bryant, 478 "MPLS Label Operations in MPLS EH capable networks", 479 draft-andersson-mpls-eh-label-stack-operations-00 (work in 480 progress), February 2019. 482 [I-D.cheng-mpls-inband-pm-encapsulation] 483 Cheng, W., Min, X., Zhou, T., Dong, X., and Y. Peleg, 484 "Encapsulation For MPLS Performance Measurement with 485 Alternate Marking Method", draft-cheng-mpls-inband-pm- 486 encapsulation-04 (work in progress), September 2020. 488 [I-D.gandhi-mpls-ioam-sr] 489 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 490 and V. Kozak, "MPLS Data Plane Encapsulation for In-situ 491 OAM Data", draft-gandhi-mpls-ioam-sr-05 (work in 492 progress), January 2021. 494 [I-D.ietf-ippm-ioam-data] 495 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 496 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 497 progress), November 2020. 499 [I-D.kompella-mpls-nffrr] 500 Kompella, K. and W. Lin, "No Further Fast Reroute", draft- 501 kompella-mpls-nffrr-01 (work in progress), November 2020. 503 [I-D.song-mpls-extension-header] 504 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 505 Extension Header", draft-song-mpls-extension-header-02 506 (work in progress), February 2019. 508 [I-D.xu-mpls-payload-protocol-identifier] 509 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 510 Protocol Identifier", draft-xu-mpls-payload-protocol- 511 identifier-08 (work in progress), December 2020. 513 [I-D.zzhang-tsvwg-generic-transport-functions] 514 Zhang, Z., Bonica, R., and K. Kompella, "Generic Transport 515 Functions", draft-zzhang-tsvwg-generic-transport- 516 functions-00 (work in progress), November 2020. 518 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 519 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 520 Protocol Label Switching (MPLS) Support of Differentiated 521 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 522 . 524 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 525 in Multi-Protocol Label Switching (MPLS) Networks", 526 RFC 3443, DOI 10.17487/RFC3443, January 2003, 527 . 529 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 530 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 531 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 532 February 2006, . 534 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 535 "Encapsulation Methods for Transport of Ethernet over MPLS 536 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 537 . 539 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 540 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 541 DOI 10.17487/RFC4623, August 2006, 542 . 544 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 545 Cost Multipath Treatment in MPLS Networks", BCP 128, 546 RFC 4928, DOI 10.17487/RFC4928, June 2007, 547 . 549 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 550 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 551 2008, . 553 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 554 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 555 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 556 2009, . 558 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 559 "MPLS Generic Associated Channel", RFC 5586, 560 DOI 10.17487/RFC5586, June 2009, 561 . 563 [RFC6178] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Label 564 Edge Router Forwarding of IPv4 Option Packets", RFC 6178, 565 DOI 10.17487/RFC6178, March 2011, 566 . 568 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 569 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 570 RFC 6790, DOI 10.17487/RFC6790, November 2012, 571 . 573 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 574 and Retiring Special-Purpose MPLS Labels", RFC 7274, 575 DOI 10.17487/RFC7274, June 2014, 576 . 578 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 579 and A. Vainshtein, "Residence Time Measurement in MPLS 580 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 581 . 583 [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to 584 Use the Ethernet Control Word", RFC 8469, 585 DOI 10.17487/RFC8469, November 2018, 586 . 588 [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 589 Mirsky, "Synonymous Flow Label Framework", RFC 8957, 590 DOI 10.17487/RFC8957, January 2021, 591 . 593 Author's Address 595 Stewart Bryant 596 Futurewei US 598 Email: sb@stewartbryant.com