idnits 2.17.1 draft-andersson-mpls-eh-architecture-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 (February 13, 2019) is 1896 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Informational J. Guichard 5 Expires: August 17, 2019 H. Song 6 S. Bryant 7 Huawei Technologies 8 February 13, 2019 10 MPLS Extension Header Architecture 11 draft-andersson-mpls-eh-architecture-00 13 Abstract 15 Extension Headers (EH) carry information on in-network services and 16 functions in an MPLS network. This document describes an 17 architecture for EHs and what actions an EH capable Label Switching 18 Router (LSR) takes when finding or not finding an EH in the packet. 20 Multiprotocol Label Switching (MPLS) is a widely deployed forwarding 21 technology. It uses label stack entries that are pre-pended to 22 either the EH or the ACH which in turn is pre-pended to the payload. 23 The label stack entries are used to identify the forwarding actions 24 by each LSR. Actions may include pushing, swapping or popping the 25 labels, and using the labels to determine the next hop for forwarding 26 the packet. Labels may also be used to establish the context under 27 which the packet is forwarded. 29 The extension headers are carried after the MPLS Label Stack, and the 30 presence of EHs are indicated in the label stack by an Extension 31 Header Indicator (EHI). 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 August 17, 2019. 50 Copyright Notice 52 Copyright (c) 2019 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 4 69 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. Extension Header Overview . . . . . . . . . . . . . . . . 4 71 2.2. Extension Header Terminology . . . . . . . . . . . . . . 4 72 3. Extension Header Basics . . . . . . . . . . . . . . . . . . . 5 73 3.1. General Principles . . . . . . . . . . . . . . . . . . . 5 74 3.2. LSPs in a EH capable Network . . . . . . . . . . . . . . 5 75 3.3. EH capable nodes . . . . . . . . . . . . . . . . . . . . 6 76 3.4. EH path and LSP . . . . . . . . . . . . . . . . . . . . . 6 77 3.5. Announcement of EH Capability . . . . . . . . . . . . . . 7 78 3.6. LSP establishment with LDP Downstream on Demand (DoD) in 79 an EH capable network . . . . . . . . . . . . . . . . . . 7 80 3.7. LSP establishment with LDP Downstream Unsolicited (DU) in 81 an EH capable network . . . . . . . . . . . . . . . . . . 9 82 3.8. Forwarding Behavior of EH Capable Nodes . . . . . . . . . 10 83 3.9. EH for RSVP-TE tunnels . . . . . . . . . . . . . . . . . 11 84 3.10. Ways to indicate an EH after the Label Stack . . . . . . 11 85 4. EH in VPNs . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5. EH and MPLS-SR . . . . . . . . . . . . . . . . . . . . . . . 11 87 6. Extension Header Applications . . . . . . . . . . . . . . . . 11 88 7. EH distribution and EH capability announcement . . . . . . . 12 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 11.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 This document specifies the architecture for the extension of MPLS to 100 include Extension Headers (EH). EHs carry information on in-network 101 services and functions in an MPLS network. This document describes 102 an architecture for EHs and what actions an EH capable Label 103 Switching Router (LSR) takes when finding or not finding an EH in the 104 packet, 106 The extension headers are carried after the MPLS Label Stack, and the 107 presence of EHs are indicated in the label stack by an Extension 108 Header Indicator (EHI). 110 Below some exmple use cases are listed. More details will be found 111 in [I-D.song-mpls-extension-header] 113 o In-situ OAM: In-situ OAM (IOAM) records flow OAM information 114 within user packets while the packets traverse a network. 116 o Network Telemetry and Measurement: A network telemetry and 117 instruction header can be carried as an extension header to 118 instruct a node what type of network measurements should be 119 performed on the packets. 121 o Network Security: Security related functions may require user 122 packets to carry some metadata. 124 o Segment Routing and Network Programming: MPLS extension header 125 could support MPLS-based segment routing. The details will be 126 described in a separate draft. 128 It is possible to distinguish between two types of MPLS EHs, "hop-by 129 hop" (HBH) and "End to end" (E2E). 131 An HBH EH is processed by every node along an LSP, HBH EHs MAY be 132 inserted by an ingress LSR or a transit LSR. A HBH EH MUST be 133 removed by an LSR along the LSP or by the egress LSR. An LSR along 134 the LSP may be configured to ignore HBH EHs. 136 An E2E EH will be inserted by the ingress LSR and, processed and MUST 137 be removed by the egress LSR, no other LSR along the LSP will process 138 the E2E EH. 140 Only EH capable LSRs will process EHs, LSR that are EH non-capable 141 will ignore the EH and forward the packet as if the information was 142 not there. 144 This document describes the interaction between EH capable neighbour 145 LSRs, and between EH capable LSRs and a neighbour that is EH non- 146 capable. 148 1.1. Requirement Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 2. Specification 158 This document specifies the use of Extension Headers (EH) with MPLS. 159 Further information on EH processing and formats will be found in 160 [I-D.song-mpls-extension-header]. 162 2.1. Extension Header Overview 164 Applications carried over an MPLS network may require that specific 165 instructions and/or metadata are added to user packets. One such 166 example could be In-situ OAM (IOAM) [I-D.brockners-inband-oam- 167 requirements]. It is likely that new such applications will emerge 168 over time. 170 One or more EHs may be added by an ingress node to an Extension 171 Header Path (EHP) and be removed by one or more EH capable nodes 172 along the EHP. Such ingress and egress nodes may be nodes at the 173 head end and tail end of a Label Switched Path (LSP), or any other 174 intermediate node of the LSP that is EH capable. For more details on 175 EHPs see Figure 1. 177 2.2. Extension Header Terminology 179 This section lists the abbreviations and concepts that are used 180 throughout this document in the context of Extension Headers. 182 o EH - Extension Header 184 o EHI - Extension Header Indicator 186 o LDP DoD - LDP Downstream on Demand 188 o LDP DU - LDP Downstream Unsolicited 190 o LSP - Label Switched Path 191 o LSR - Label Switching Router 193 The following concepts new for MPLS are defined: 195 o EH capable node - an LSR that can process Extension Headers and 196 announce its EH capability 198 o EH capable LSR - this may be used interchangeably with EH capable 199 node. 201 o EH non-capable node - an LSR that is unaware of and unable to 202 process Extension Headers. 204 o EH path - an EH path starts at the node adding an EH and ends at 205 the node that removes it. 207 3. Extension Header Basics 209 3.1. General Principles 211 Any EH capable node along an LSP may add an EH as long as it can be 212 verified that there is another EH capable LSR downstream that can 213 remove it. Any EH capable node downstream may remove an EH. An EH 214 path starts when one or more EHs are added and ends where the last EH 215 is removed. If there is no node downstream capable to remove the EH, 216 it MUST NOT be added. It is assumed that a control plane will make 217 this determination, the specification of which is outside the scope 218 of this document. 220 In the context of the MPLS EH architecture an EH capable node assumes 221 that all user packets on the default LSP carry EHs. As an 222 optimization a second parallel LSP may be instantiated using a 223 Forwarding Equivalence Class (FEC) that does not permit EHs, thus 224 indicating to the LSR that there are no EHs in the packet. 226 3.2. LSPs in a EH capable Network 228 For an EH capable LSP between two EH capable LSRs there are two label 229 mappings: 231 o first, a label mapping for the FEC that indicates that the packet 232 carries IP 234 o second, a label mapping for a new FEC indicating that there are no 235 EHs in the packet 237 3.3. EH capable nodes 239 EH capable nodes may process Extension Headers, i.e. add, augment, 240 remove or do required processing at a transit node. 242 An EH capable node may not add an extension header to a packet if 243 unless it is sure that there is a downstream node that can remove it. 245 If an LSP forks due to ECMP, the node that does the forking MUST be 246 sure that all LSP branches (which may be re-merged) eventually 247 terminate at an EH capable node which will remove the EH. 249 3.4. EH path and LSP 251 EH capable nodes may process Extension Headers, i.e. add, remove or 252 do required processing at a transit node. 254 Figure 1 will be used for illustration. 256 <------------------LSP--------------------> 258 A------b------c------D------E------F------G 260 <------------------EHP1-------------------> 261 <------------EHP2-----------> 262 <--------EHP3--------> 263 <-----EHP4----> 264 <-EHP5-> 266 A, D, E, F and G are EH capable nodes 268 b and c are non-EH capable nodes. 270 Figure 1: EH path vs. LSP 272 LSP - the LSP originates at ingress LSR A and terminates at egress 273 LSR G, packets flow from A to G. 275 EHP1 - EHP1 originates with the EH capable node A adding an 276 extension header to the packet and terminates when the EH capable 277 node G removes the EH 278 EHP2 - EHP2 originates with the EH capable node A adding an 279 extension header to the packet and terminates when the EH capable 280 node E removes the EH. i.e. the EH path is shorter than the LSP 282 EHP3 - EHP3 originates with the EH capable node D adding an 283 extension header to the packet and terminates when the EH capable 284 node G removes the EH. 286 EHP4 - EHP4 originates with the EH capable node D adding an 287 extension header to the packet and terminates when the EH capable 288 node F removes the EH, i.e. it is not necessary that an EH path 289 originates or terminate on an MPLS LER. 291 EHP5 - EHP5 originates with the EH capable node F adding an 292 extension header to the packet and terminates when the EH capable 293 node G removes the EH 295 Further discussion on the information needed in the packet to 296 identify and process EHs are found in 297 [I-D.song-mpls-extension-header]. 299 3.5. Announcement of EH Capability 301 A node that is EH capable MUST have a way to announce this capability 302 to other nodes in the same domain. Additions to the IGPs should be a 303 baseline for such capabilities. 305 3.6. LSP establishment with LDP Downstream on Demand (DoD) in an EH 306 capable network 308 LSPs for EH handling and processing in an MPLS network may be set up 309 by LDP [RFC5036], a centralized controller and/or MPLS-SR. To enable 310 this small extensions to the protocols are required. 312 In the examples in Section 3.6 and Section 3.7 we for simplicity 313 assume that the payload of the packet is IP. It is of course 314 possible that the payload will be a Pseudowire (PW) or a Virtual 315 Private Network (VPN). This will be described in a later version of 316 the document. 318 It is anticipated that the difference in establishment procedures for 319 IP, PW and VPN will be minor. 321 It is possible to use the simplified physical topology show in 322 Figure 2 which uses LDP Downstream on Demand (DoD) to illustrate how 323 LSP setup work in a network with a mix of EH capable and EH non- 324 capable nodes. In LDP DoD the action to set up an LSP is taken by 325 the node at the head-end of the potential LSP. 327 +---+ +---+ +---+ +---+ +---+ 328 | | | | | | | | | | 329 | A +------+ b +------+ D +------+ E +------+ G + 330 | | | | | | | | | | 331 +---+ +---+ +---+ +---+ +---+ 332 A, D, E, and G are EH capable nodes 334 b is a non-EH capable node. 336 Figure 2: EH topology 338 The following steps would be taken assuming that node A wants to set 339 up connectivity with node G to support EH handling and processing: 341 o A sends an LDP Label Request message to b, indicating that an EH 342 capable LSP should be set up to G. A keeps track of the 343 outstanding request. 345 o b is not EH capable and treat the Label Request as a normal 346 request, however, the information indicating that an EH capable 347 LSP is requested is transitive and sent to D. 349 o D receives the Label Request, forwards it to E, and keeps track of 350 the outstanding request. 352 o E treats the label request the same way as D, and forward it to G. 354 o G receives the label request, finds out that it is the egress node 355 for this LSP. G allocates two labels one for the IP FEC and one 356 for the new "no EH present" FEC. G sends a label mapping to E 357 with both labels, and asks E to PHP both LSPs. 359 o E receives the label mapping and installs PHP for both the IP FEC 360 and for the new "no EH present"-FEC. E allocates two labels one 361 for the IP FEC (label value 201) and one for the new FEC (label 362 value 301). E sends a label mapping message to D, with the two 363 labels. 365 o D receives the label mapping message and installs label 201 for 366 the IP FEC and label value 301 for the new FEC. Since D know that 367 b is not EH capable it will only allocate one label (202 for the 368 IP FEC) and send a label mapping message to with that label. 370 o b receives the label mapping messages and installs label 202 for 371 the IP FEC. Since b is not EH capable it will only allocate one 372 label (203 for the IP FEC). b sends a label mapping message to A 373 with that label. 375 o A receives the label mapping and installs label value 203 for the 376 IP FEC. 378 This will result in installed labels like this. 380 +---+ +---+ +---+ +---+ +---+ 381 | |...203...| |...202...| |...201...| |...php...| | 382 | A +---------+ b +---------+ D +---------+ E +---------+ G + 383 | | | | | |...301...| |...php...| | 384 +---+ +---+ +---+ +---+ +---+ 385 A, D, E and G are EH capable nodes. 387 b is a non-EH capable node. 389 Figure 3: EH topology 391 3.7. LSP establishment with LDP Downstream Unsolicited (DU) in an EH 392 capable network 394 In LDP Downstream Unsolicited (DU) the initiative to establish a LSP 395 is taken by the egress router. The egress will establish an LSP to 396 every prefix it learns of from the IGP. With the exception from how 397 the set up of the LSP(s) are triggered the label mappings are similar 398 to how it is done with LDP DoD. 400 The same topoplogy as in the LDP DoD example Figure 2 will be used 401 for LDP DU. 403 o G learns that an EH capable LSP to egress LSR A is needed. G 404 allocates two labels one for the IP FEC and one for the new "no EH 405 present" FEC. G sends a label mapping to E with both labels, and 406 asks E to PHP both LSPs. 408 o E receives the label mapping and installs PHP for both the IP FEC 409 and for the new "no EH present"-FEC. E allocates two labels one 410 for the IP FEC (label value 201) and one for the new FEC (label 411 value 301). E sends a label mapping message to D, with the two 412 labels. 414 o D receives the label mapping message and installs label 201 for 415 the IP FEC and label value 301 for the new FEC. Since D know that 416 b is not EH capable it will only allocate one label (202 for the 417 IP FEC) and send a label mapping message to with that label. 419 o b receives the label mapping messages and installs label 202 for 420 the IP FEC. Since b is not EH capable it will only allocate one 421 label (203 for the IP FEC). b sends a label mapping message to A 422 with that label. 424 o A receives the label mapping and installs label value 203 for the 425 IP FEC. 427 o This will result in the exact the same label mappings as in the 428 Dod Example, see Figure 3. 430 3.8. Forwarding Behavior of EH Capable Nodes 432 A EH capable node will always search the label stack for EHs, with 433 the exception of when a packet is received on the new FEC (no EH 434 present). 436 Non-EH capable nodes will never search the label stack for EHs. 438 Given the configuration in Figure 3 packets will be forwarded as 439 follows through the network. 441 If Node A sends a packet with an extension header folling the label 442 stack: 444 1. A sends a packet with label 203 with an EH after the label stack 445 to b 447 2. b receives the packet and swaps the label to 202 and forward it 448 to D. 450 3. D receives the packet, and since D is EH capable it will search 451 the stack to find an EH-indicator. Since there is EH present, D 452 will decide whether it should process the extension header or 453 not. When that decision is taken and potential processing is 454 done, D will swap the label to 201 and send it to E. 456 4. E receives the packet on LSP with a FEC that indicates that "EH 457 may present" and will search the packet for an EH. When the EH 458 is found by E it will, if required, process the EH, after that 459 the top label is popped and the packet is forwarded to G. 461 5. G receives the packet, it will search the label stack to find the 462 EHI. It will find the EH and since G is the egress node it will 463 do necessary processing and as a last step remove the EH. G will 464 forward the packet based on the IP address. 466 If Node A sends a packet without an extension header: 468 1. A sends a packet with label 203 without an EH to b 470 2. b receives the packet and swaps the label to 202 and forward it 471 to D. 473 3. D receives the packet, and since D is EH capable it will search 474 the stack to find an EH. Since there is no EH present, D will 475 swap the label to 301 and send it to E (FEC indicates no EH 476 present). 478 4. E receives the packet on FEC "no EH present" and understand that 479 it does not need to search the packet for an EH. E pops the 480 label and forward to G 482 5. G receives the packet on FEC "no EH present" and understand that 483 it does not need to search the packet for an EH. G will forward 484 it based on the IP address. 486 3.9. EH for RSVP-TE tunnels 488 Extension Headers for RSVP-TE tunnels is for further study. 489 Essentially it expected to be similzar to the LDP case. 491 3.10. Ways to indicate an EH after the Label Stack 493 There are several ways to indicate the presence of EHs after the 494 label stack. This will be discussed in a separate document. 496 4. EH in VPNs 498 TBA 500 5. EH and MPLS-SR 502 TBA 504 6. Extension Header Applications 506 TBA 508 7. EH distribution and EH capability announcement 510 TBA 512 8. Security Considerations 514 TBA 516 9. IANA Considerations 518 MPLS extension headers will require code point allocations from more 519 than one IANA registry. It is not yet decided which document that 520 will make which allocation. 522 However, tentatively the "No EH present" FEC will be assigned from 523 this document. 525 IANA is requested to allocate lowest free value from the "IETF 526 Review" range as new FEC from the "Forwarding Equivalence Class (FEC) 527 Type Name Space" in the "Label Distribution Protocol (LDP) 528 Parameters", like this: 530 +-------+-----+----------+------------------+-----------+-----------+ 531 | Value | Hex | Name | Label | Reference | Note/Reg. | 532 | | | | Distribution | | Date | 533 | | | | Discipline | | | 534 +-------+-----+----------+------------------+-----------+-----------+ 535 | TBD | TBD | No EH | DoD or DU | This | TBA | 536 | | | present | | Document | | 537 +-------+-----+----------+------------------+-----------+-----------+ 539 Table 1: No EH present 541 10. Acknowledgements 543 - 545 - 547 11. References 549 11.1. Normative References 551 [I-D.song-mpls-extension-header] 552 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 553 Extension Header", draft-song-mpls-extension-header-02 554 (work in progress), February 2019. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, 558 DOI 10.17487/RFC2119, March 1997, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 11.2. Informative References 567 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 568 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 569 October 2007, . 571 Authors' Addresses 573 Loa Andersson 574 Bronze Dragon Consulting 576 Email: loa@pi.nu 578 James N Guichard 579 Huawei Technologies 581 Email: james.n.guichard@huawei.com 583 Haoyu Song 584 Huawei Technologies 586 Email: haoyu.song@huawei.com 588 Stewart Bryant 589 Huawei Technologies 591 Email: stewart.bryant@gmail.com