MPLS Working Group H. Sitaraman Internet-Draft V. Beeram Intended status: Standards Track Juniper Networks Expires: March 10, 2018 T. Parikh Verizon T. Saad Cisco Systems September 6, 2017 Signaling RSVP-TE tunnels on a shared MPLS forwarding plane draft-sitaraman-mpls-rsvp-shared-labels-02.txt Abstract As the scale of MPLS RSVP-TE networks has grown, so the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in control plane state. However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane. This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control plane scaling on that node. That is, it allows many more LSPs to be supported than there are forwarding plane labels available. This work introduces the notion of pre-installed 'pop labels' that are applied per Traffic Engineering link and that can be shared by MPLS RSVP-TE LSPs that traverse these links. This approach significantly reduces the forwarding plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. This document also introduces the ability to mix different types of label operations along the path of an LSP, thereby allowing the ingress router or an external controller to influence how to optimally place a LSP in the network. Sitaraman, et al. Expires March 10, 2018 [Page 1] Internet-Draft RSVP-TE pop and forward tunnel September 2017 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 10, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Allocation of Pop Labels . . . . . . . . . . . . . . . . . . 5 4. RSVP-TE Pop and Forward Tunnel Setup . . . . . . . . . . . . 5 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7 5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8 5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 9 Sitaraman, et al. Expires March 10, 2018 [Page 2] Internet-Draft RSVP-TE pop and forward tunnel September 2017 5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 10 5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 10 5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 10 6. Mixing Pop and Swap Labels in an RSVP-TE Tunnel . . . . . . . 11 7. Construction of Label Stacks . . . . . . . . . . . . . . . . 12 8. Facility Backup Protection . . . . . . . . . . . . . . . . . 13 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 8.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 14 9. Quantifying Pop Labels . . . . . . . . . . . . . . . . . . . 14 10. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 14 10.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Attribute Flags TLV: Pop Label . . . . . . . . . . . . . 15 10.3. RRO Label Subobject Flag: Pop Label . . . . . . . . . . 15 10.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 15 10.5. RRO Label Subobject Flag: Delegation Label . . . . . . . 16 10.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . 16 10.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 16 11. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 14.1. Attribute Flags: Pop Label, LSI-D, LSI-D-S2E . . . . . . 18 14.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 18 14.3. Record Route Label Sub-object Flags: Pop Label, Delegation Label . . . . . . . . . . . . . . . . . . . . 18 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 16.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The scaling of RSVP-TE [RFC3209] control plane implementations can be improved by adopting the guidelines and mechanisms described in [RFC2961] and [I-D.ietf-teas-rsvp-te-scaling-rec]. These documents do not make any difference to the forwarding plane state required to handle the control plane state. The forwarding plane state remains unchanged and is directly proportional to the total number of Label Switching Paths (LSPs) supported by the control plane. This document describes a mechanism that prevents the size of the platform specific label space on a Label Switching Router (LSR) from being a constraint to pushing the limits of control plane scaling on that node. This work introduces the notion of pre-installed 'pop labels' that are allocated by an LSR for each of its Traffic Engineering (TE) Sitaraman, et al. Expires March 10, 2018 [Page 3] Internet-Draft RSVP-TE pop and forward tunnel September 2017 links. Each such label is installed in the MPLS forwarding plane with a 'pop' operation and the instruction to forward the received packet over the TE link. An LSR advertises this label in the Label object of a Resv message as LSPs are set up and they are recorded hop by hop in the Record Route object (RRO) of the Resv message as it traverses the network. To make use of this feature, the ingress Label Edge Router (LER) pushes a stack of labels [RFC3031] as received in the RRO. These 'pop labels' can be shared by MPLS RSVP- TE LSPs that traverse the same TE link. This pop and forward data plane behavior is similar to that used by Segment Routing (SR) [I-D.ietf-spring-segment-routing] using a MPLS forwarding plane and a series of adjacency segments. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. The RSVP-TE pop and forward tunnels can co-exist with MPLS-SR LSPs [I-D.ietf-spring-segment-routing-mpls] as described in [I-D.ietf-teas-sr-rsvp-coexistence-rec]. RSVP-TE using a pop and forward data plane offers the following benefits: 1. Shared forwarding plane: The transit label on a TE link is shared among RSVP-TE tunnels traversing the link and is used independent of the ingress and egress of the LSPs. 2. Faster LSP setup time: No forwarding plane state needs to be programmed during LSP setup and teardown resulting in faster time for provisioning and deprovisioning LSPs. 3. Hitless re-routing: New transit labels are not required during make-before-break (MBB) in scenarios where the new LSP instance traverses the exact same path as the old LSP instance. This saves the ingress LER and the services that use the tunnel from needing to update the forwarding plane with new tunnel labels and so makes MBB events faster. Periodic MBB events are relatively common in networks that deploy the 'auto-bandwidth' feature on RSVP-TE LSPs to monitor bandwidth utilization and periodically adjust LSP bandwidth. 4. Mix and match labels: Both 'pop' and 'swap' labels can be used on transit hops for a single RSVP-TE tunnel (see Section 6). This allows backward compatibility with transit LSRs that provide 'swap' labels in Resv messages. No additional extensions are required to routing protocols (IGP-TE) in order to support this pop and forward data plane. Functionalities such as bandwidth admission control, LSP priorities, preemption, Sitaraman, et al. Expires March 10, 2018 [Page 4] Internet-Draft RSVP-TE pop and forward tunnel September 2017 auto-bandwidth and Fast Reroute continue to work with this forwarding plane. 2. Terminology The following terms are defined for use in this document: Pop label: An incoming label at an LSR that will be popped by the LSR with the packet being forwarded over a specific outgoing TE link to a neighbor. Swap label: An incoming label at a LSR that will be swapped to an outgoing label with the packet being forwarded over a specific outgoing TE link to a neighbor. RSVP-TE pop and forward tunnel: An MPLS RSVP-TE tunnel that uses a pop and forward labels on every hop of the LSP. Pop and forward data plane: A forwarding plane where every LSR uses pop labels on every LSP. 3. Allocation of Pop Labels An LSR SHOULD allocate a unique pop label for each TE link. When an LSR encounters a pop label at the top of the label stack it MUST pop the label and forward the packet over the TE link to the downstream neighbor on the RSVP-TE tunnel. Multiple labels MAY be allocated for the TE link to accommodate tunnels requesting no protection, link-protection and node-protection over the specific TE link. 4. RSVP-TE Pop and Forward Tunnel Setup This section provides an example of how the RSVP-TE signaling procedure works to set up a tunnel utilizing a pop and forward data plane. The sample topology below is used to explain the example. Labels shown at each node are pop labels that, when present at the top of the label stack, indicate that they should be popped and that the packet should be forwarded on the TE link to the neighbor. Sitaraman, et al. Expires March 10, 2018 [Page 5] Internet-Draft RSVP-TE pop and forward tunnel September 2017 +---+100 +---+150 +---+200 +---+250 +---+ | A |-----| B |-----| C |-----| D |-----| E | +---+ +---+ +---+ +---+ +---+ |110 |450 |550 |650 |850 | | | | | | |400 |500 |600 |800 | +---+ +---+ +---+ +---+ +-------| F |-----|G |-----|H |-----|I | +---+300 +---+350 +---+700 +---+ Figure 1: Pop and Forward Label Topology Consider two tunnels: RSVP-TE tunnel T1: From A to E on path A-B-C-D-E RSVP-TE tunnel T2: From F to E on path F-B-C-D-E Both tunnels share the TE links B-C, C-D, and D-E. RSVP-TE is used to signal the setup of tunnel T1 (using the pop label attributes flag defined in Section 10.2). When LSR D receives the Resv message from the egress LER E, it checks the next-hop TE link (D-E) and provides the pop label (250) in the Resv message for the tunnel placing the label value in the Label object and also in the Label subobject carried in the RRO and setting the pop label flag as defined in Section 10.3. Similarly, LSR C provides the pop label (200) for the TE link C-D, and LSR B provides the pop label (150) for the TE link B-C. For tunnel T2, the transit LSRs provide the same pop labels as described for tunnel T1 as the links B-C, C-D, and D-E are common between the two LSPs. The ingress LERs (A and F) will push the same stack of labels (from top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and T2 respectively. It should be noted that a transit LSR does not swap the top pop label on an incoming packet (the label that it advertised in the Resv message it sent). All it has to do is pop the top label and forward the packet. The values in the Label subobjects in the RRO are of interest to the ingress LERs in order to construct the stack of labels to impose on the packets. Sitaraman, et al. Expires March 10, 2018 [Page 6] Internet-Draft RSVP-TE pop and forward tunnel September 2017 If, in this example, there was another RSVP-TE tunnel T3 from F to I on path F-B-C-D-E-I, then this would also share the TE links B-C, C-D, and D-E and additionally traverse link E-I. The label stack used by F would be {150, 200, 250, 850}. Hence, regardless of the ingress and egress LERs from where the LSPs start and end, they will share LSR labels at shared hops in the pop and forward data plane. There MAY be local operator policy at the ingress LER that influences the maximum depth of the label stack that can be pushed for an RSVP- TE pop and forward tunnel. Prior to signaling the LSP, the ingress LER may decide that it would be unable to push a label stack containing one label for each hop along the path. In this case the LER can choose either to not signal an RSVP-TE pop and forward tunnel (using normal LSP signaling instead), or can adopt the techniques described in Section 5 or Section 6. 5. Delegating Label Stack Imposition One or more transit LSRs can assist the ingress LER by imposing part of the label stack required for the path. Consider the example in Figure 2 with an RSVP-TE tunnel from A to L on path A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A to impose the full label stack, so it uses the assistance of delegation hops LSR D and LSR I to impose parts of the label stack. Each delegation hop allocates a delegation label to represent a set of labels that will be pushed at this hop. When a packet arrives at a delegation hop LSR with a delegation label, the LSR pops the label and pushes a set of labels before forwarding the packet. 1250d +---+100p +---+150p +---+200p +---+250p +---+300p +---+ | A |------| B |------| C |------| D |------| E |------| F | +---+ +---+ +---+ +---+ +---+ +---+ |350p | 1500d | +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ | L |------| K |------| J |------| I |------| H |------+ G + +---+ +---+ +---+ +---+ +---+ +---+ Notation :