[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 draft-ietf-mpls-rsvp-shared-labels

MPLS Working Group                                          H. Sitaraman
Internet-Draft                                                 V. Beeram
Intended status: Standards Track                        Juniper Networks
Expires: January 4, 2018                                       T. Parikh
                                                                 Verizon
                                                                 T. Saad
                                                           Cisco Systems
                                                            July 3, 2017


      Signaling RSVP-TE tunnels on a shared MPLS forwarding plane
             draft-sitaraman-mpls-rsvp-shared-labels-01.txt

Abstract

   As the scale of MPLS RSVP-TE LSPs has grown, various implementation
   recommendations have been proposed to manage control plane state.
   However, the forwarding plane footprint of labels at a transit LSR
   has remained proportional to the total LSP state in the control
   plane.  This draft defines a mechanism to prevent the label space
   limit on an LSR from being a constraint to control plane scaling on
   that node.  It introduces the notion of pre-installed per TE link
   'pop labels' that are shared by MPLS RSVP-TE LSPs that traverse these
   links and thus significantly reducing the forwarding plane state
   required.  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 the LSP, thereby allowing
   the ingress or an external controller to influence how to optimally
   place a LSP.

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 January 4, 2018.




Sitaraman, et al.        Expires January 4, 2018                [Page 1]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


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.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Allocation of pop labels  . . . . . . . . . . . . . . . . . .   4
   5.  RSVP-TE pop and forward tunnel setup  . . . . . . . . . . . .   5
   6.  Delegating label stack imposition . . . . . . . . . . . . . .   6
     6.1.  Stacking at the Ingress . . . . . . . . . . . . . . . . .   6
       6.1.1.  Stack to reach delegation hop . . . . . . . . . . . .   7
       6.1.2.  Stack to reach egress . . . . . . . . . . . . . . . .   7
     6.2.  Explicit Delegation . . . . . . . . . . . . . . . . . . .   8
     6.3.  Automatic Delegation  . . . . . . . . . . . . . . . . . .   9
       6.3.1.  Effective Transport Label-Stack Depth (ETLD)  . . . .   9
   7.  Mixing pop and swap labels in a RSVP-TE tunnel  . . . . . . .  10
   8.  Construction of label stack . . . . . . . . . . . . . . . . .  11
   9.  Facility backup protection  . . . . . . . . . . . . . . . . .  12
     9.1.  Link Protection . . . . . . . . . . . . . . . . . . . . .  12
     9.2.  Node Protection . . . . . . . . . . . . . . . . . . . . .  12
   10. Quantifying pop labels  . . . . . . . . . . . . . . . . . . .  13
   11. Protocol Extensions . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Requirements . . . . . . . . . . . . . . . . . . . . . .  13
     11.2.  Attribute Flags TLV: Pop Label . . . . . . . . . . . . .  14
     11.3.  RRO Label Subobject Flag: Pop Label  . . . . . . . . . .  14
     11.4.  Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . .  14
     11.5.  RRO Label Subobject Flag: Delegation Label . . . . . . .  15
     11.6.  Attributes Flags TLV: LSI-D-S2E  . . . . . . . . . . . .  15
     11.7.  Attributes TLV: ETLD . . . . . . . . . . . . . . . . . .  15
   12. OAM considerations  . . . . . . . . . . . . . . . . . . . . .  16
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   14. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  16
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     15.1.  Attribute Flags: Pop Label, LSI-D, LSI-D-S2E . . . . . .  16



Sitaraman, et al.        Expires January 4, 2018                [Page 2]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


     15.2.  Attribute TLV: ETLD  . . . . . . . . . . . . . . . . . .  17
     15.3.  Record Route Label Sub-object Flags: Pop Label,
            Delegation Label . . . . . . . . . . . . . . . . . . . .  17
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     17.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     17.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Various RSVP-TE scaling recommendations [RFC2961]
   [I-D.ietf-teas-rsvp-te-scaling-rec] have been proposed for
   implementations to adopt guidelines that would allow the RSVP-TE
   [RFC3209] control plane to scale better.  The forwarding plane state
   required to handle the equivalent control plane state remains
   unchanged and is proportional to the total LSP state in the control
   plane.  The motivation of this draft is to prevent the platform
   specific label space limit on an LSR from being a constraint to
   pushing the limits of control plane scaling on that node.

   This document proposes the allocation of a 'pop label' by a LSR for
   each of its TE links.  The label is installed in the MPLS forwarding
   plane with a pop label operation and to forward the received packet
   over the TE link.  This label is sent normally by the LSR in the
   Label object in the Resv message as LSPs are setup.  The ingress LER
   SHOULD construct and push a stack of labels [RFC3031] as received in
   the Record Route object(RRO) in the Resv message.

   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.  The RSVP-TE pop
   and forward tunnels can co-exist with SR LSPs 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: The forwarding plane state is not
       programmed during LSP setup and teardown resulting in faster LSP
       setup time.

   3.  Hitless routes: New transit labels are not required on complete
       path overlap during make-before-break (MBB) resulting in a faster



Sitaraman, et al.        Expires January 4, 2018                [Page 3]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


       MBB event.  This avoids the ingress LER and the services that
       might be using the tunnel from needing to update its forwarding
       plane with new tunnel labels.  Periodic MBB events are relatively
       common in networks that deploy auto-bandwidth 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 mixed
       across transit hops for a single RSVP-TE tunnel (see Section 7).
       This allows backwards compatibility with transit LSRs that
       provides 'swap' labels.

   No additional extensions are required to IGP-TE in order to support
   this pop and forward data plane.  Functionalities such as bandwidth
   admission control, LSP priorities, preemption, auto-bandwidth and
   Fast Reroute continue to work with this forwarding plane.

2.  Conventions used in this document

   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 RFC 2119 [RFC2119].

3.  Terminology

   Pop label: An incoming label at a LSR that will be popped and
   forwarded over a specific TE link to a neighbor.

   Swap label: An incoming label at a LSR that will be swapped to an
   outgoing label and forwarded over a specific downstream TE link.

   Pop and forward data plane: A forwarding plane where every LSR along
   the path uses a pop label.

   RSVP-TE pop and forward tunnel: A MPLS RSVP-TE tunnel that uses a pop
   and forward data plane.

4.  Allocation of pop labels

   A LSR SHOULD allocate a unique pop label for each TE link.  The
   forwarding action for the pop label should it appear on top of the
   label stack MUST be to pop the label and forward the packet over the
   TE link to the downstream neighbor of 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.





Sitaraman, et al.        Expires January 4, 2018                [Page 4]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


5.  RSVP-TE pop and forward tunnel setup

   This section provides an example of how the RSVP-TE signaling
   procedure works to setup a tunnel utilizing a pop and forward data
   plane.  The sample topology below will be used to explain the setup.

        Labels shown at each node are pop labels for that neighbor

    +---+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

   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.

   As RSVP-TE signals the setup (using the pop label attributes flag
   defined in Section 11.2) of tunnel T1, when LSR D receives the Resv
   message from the egress E, it checks the next-hop TE link (D-E) and
   provides the pop label (250) in the Resv message for the tunnel.  The
   label is sent in the Label object and is also recorded in the Label
   sub-object (using the pop label flag defined in Section 11.3) carried
   in the RRO.  Similarly, C provides the pop label (200) for the next-
   hop TE link C-D and B provides the pop label (150) for the next-hop
   TE link B-C.  For the tunnel T2, the transit LSRs provide the same
   pop labels as described for tunnel T1.

   Both LER A and F will push the same stack of labels {150(top), 200,
   250} for tunnels T1 and T2 respectively.  It should be noted that a
   transit LSR does not use the pop label provided in the label object
   by its downstream LSR in the NHLFE as the outgoing label.  The
   recorded labels in the RRO are of interest to the ingress LER in
   order to construct a stack of labels.

   If there were 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(top), 200, 250, 850}. Hence, regardless of the ingress and




Sitaraman, et al.        Expires January 4, 2018                [Page 5]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   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 a RSVP-TE
   pop and forward tunnel.  Prior to signaling the LSP, if the ingress
   LER decides that it would be unable to push the entire label stack
   should every transit hop provide a pop label, then the LER can choose
   to either not signal a RSVP-TE pop and forward tunnel or can adopt
   techniques mentioned in Section 6 or Section 7.

6.  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.  From Figure 2, ingress LER
   A can use 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 this LSR with a delegation label, this label
   gets popped and the set of labels it represents gets pushed before
   the packet is forwarded.


        D and I - delegation hops; [Label]p - pop label; [Label]d -
                             delegation label

                                       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 +
         +---+     +---+     +---+     +---+     +---+     +---+

                Figure 2: Delegating Label Stack Imposition

   RSVP-TE tunnel: From A to L on path A-B-C-D-E-F-G-H-I-J-K-L

6.1.  Stacking at the Ingress

   When delegation labels come into play, there are a couple of stacking
   approaches that the ingress can choose from.  Section 8 explains how
   the label stack can be constructed.





Sitaraman, et al.        Expires January 4, 2018                [Page 6]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


6.1.1.  Stack to reach delegation hop

   In this approach, the stack pushed by the ingress carries a set of
   labels that will take the packet to the first delegation hop (if
   present).  When this approach is employed, the set of labels
   represented by a delegation label at a given delegation hop will
   include the corresponding delegation label from the next delegation
   hop (if present).  As a result, this delegation label can only be
   shared among LSPs that are destined to the same egress and traverse
   the same downstream path.

    Delegation label 1250 represents {300,350,400,450,1500}; Delegation
                     label 1500 represents {550, 600}

          +---+               +---+               +---+
          | A |-----.....-----| D |-----.....-----| I |-----.....
          +---+               +---+               +---+

                         Pop 1250 &           Pop 1500 &
           Push                Push                Push
          ......              ......              ......
          : 150:        1250->: 300:        1500->: 550:
          : 200:              : 350:              : 600:
          :1250:              : 400:              ......
          ......              : 450:
                              :1500:
                              ......

                  Figure 3: Stack to reach delegation hop

   With this approach, for the tunnel in Figure 2 the ingress LER A will
   push {150,200,1250}. At LSR D, the delegation label 1250 will get
   popped and {300,350,400,450,1500} will get pushed.  And at LSR I, the
   delegation label 1500 will get popped and the remaining set of labels
   {550,600} will get pushed.

6.1.2.  Stack to reach egress

   In this approach, the stack pushed by the ingress carries a set of
   labels that will take the packet all the way to the egress (all the
   delegation labels are part of this stack).  When this approach is
   employed, the set of labels represented by a delegation label at a
   given delegation hop will not include the corresponding delegation
   label from the next delegation hop (if present).  As a result, this
   delegation label can be shared among all LSPs traversing the segment
   between the two delegation hops.  The downside of this approach is
   that the number of hops that the LSP can traverse is dictated by the
   label stack push limit of the ingress.



Sitaraman, et al.        Expires January 4, 2018                [Page 7]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   Delegation label 1250 represents {300,350,400,450}; Delegation label
                        1500 represents {550, 600}

          +---+               +---+               +---+
          | A |-----.....-----| D |-----.....-----| I |-----.....
          +---+               +---+               +---+

                         Pop 1250 &           Pop 1500 &
           Push                Push                Push
          ......              ......              ......
          : 150:        1250->: 300:        1500->: 550:
          : 200:              : 350:              : 600:
          :1250:              : 400:              ......
          :1500:              : 450:
          ......              ......
                              |1500|
                              ------

                      Figure 4: Stack to reach egress

   With this approach, for the tunnel in Figure 2 the ingress LER A will
   push {150,200,1250,1500}. At LSR D, the delegation label 1250 will
   get popped and {300,350,400,450} will get pushed.  And at LSR I, the
   delegation label 1500 will get popped and the remaining set of labels
   {550,600} will get pushed.  The signaling extension required for the
   ingress to indicate the chosen stacking approach is defined in
   Section 11.6.

6.2.  Explicit Delegation

   In this delegation option, the ingress LER can explicitly delegate
   one or more specific transit hops to handle pushing labels for a
   certain number of its downstream hops.  In order to accurately pick
   the delegation hops, the ingress needs to be aware of the label stack
   depth push limit of each of the transit LSRs prior to initiating the
   signaling sequence.  The mechanism by which the ingress or controller
   (hosting the path computation element) learns this information is
   outside the scope of this document.

   Signaling extension required for the ingress LER to explicitly
   delegate one or more specific transit hops is defined in
   Section 11.4.  The extension required for the delegation hop to
   indicate that the recorded label is a delegation label is defined in
   Section 11.5.







Sitaraman, et al.        Expires January 4, 2018                [Page 8]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


6.3.  Automatic Delegation

   In this approach, the ingress LER lets the downstream hops
   automatically pick suitable delegation hops during the initial
   signaling sequence.  The ingress need not be aware up front of the
   label stack depth push limit of each of the transit LSRs.  The
   delegation hops are picked based on a per-hop signaled attribute
   called the Effective Transport Label-Stack Depth (ETLD).

6.3.1.  Effective Transport Label-Stack Depth (ETLD)

   The ETLD is signaled as a per-hop attribute in the Path message.
   When automatic delegation is requested, the ingress MUST populate the
   ETLD with the maximum number of transport labels that it can
   potentially send to its downstream hop.  This value is then
   decremented at each successive hop.  If a node is reached where the
   ETLD set from the previous hop is 1, then that node MUST select
   itself as the delegation hop.  If a node is reached and it is
   determined that this hop cannot receive more than one transport
   label, then that node MUST select itself as the delegation hop.  If
   there is a node or a sequence of nodes along the path of the LSP that
   do not support ETLD, then the immediate hop that supports ETLD MUST
   select itself as the delegation hop.  The ETLD MUST be decremented at
   each non-delegation transit hop by either 1 or some appropriate
   number based on the limitations at that hop.  At each delegation hop,
   the ETLD MUST be reset to the maximum number of transport labels that
   the hop can send and the ETLD decrements start again at each
   successive hop until either a new delegation hop is selected or the
   egress is reached.  The net result is that by the time the Path
   message reaches the egress, all delegation hops are selected.  During
   the Resv processing, at each delegation hop, a suitable delegation
   label is selected (either an existing label is reused or a new label
   is allocated) and recorded in the Resv message.


















Sitaraman, et al.        Expires January 4, 2018                [Page 9]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


    Assumption: Ingress A can push up to 3 transport labels; Remaining
                  nodes can push up to 5 transport labels

          ETLD:3    ETLD:2    ETLD:1    ETLD:5    ETLD:4
          ----->    ----->    ----->    ----->    ----->
                                    1250d
      +---+100p +---+150p +---+200p +---+250p +---+300p +---+
      | A |-----| B |-----| C |-----| D |-----| E |-----| F |  ETLD:3
      +---+     +---+     +---+     +---+     +---+     +---+    |
                                                          |350p  |
                                                          |      |
                                    1500d                 |      |
      +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+    v
      | L |-----| K |-----| J |-----| I |-----| H |-----+ G +
      +---+     +---+     +---+     +---+     +---+     +---+

          ETLD:3    ETLD:4    ETLD:5    ETLD:1    ETLD:2
          <-----    <-----    <-----    <-----    <-----

                              Figure 5: ETLD

   Signaling extension for the ingress LER to request automatic
   delegation is defined in Section 11.4.  The extension for signaling
   the ETLD is defined in Section 11.7.  The extension required for the
   delegation hop to indicate that the recorded label is a delegation
   label is defined in Section 11.5.

7.  Mixing pop and swap labels in a RSVP-TE tunnel

   Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP.
   Certain LSRs can use pop labels and others can use swap labels.  The
   ingress can construct a label stack appropriately based on what type
   of label is recorded from every transit LSR.


















Sitaraman, et al.        Expires January 4, 2018               [Page 10]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


    Labels shown at each node are pop labels for that TE link. (#) are
                               swap labels.

                             (#)       (#)
    +---+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 6: Mix pop and swap label topology

   If the transit LSR allocates a swap label to be sent upstream in the
   Resv, then the label operation in the NHLFE MUST be a swap to any
   label received from the downstream LSR.  If the transit LSR is using
   a pop label to be sent upstream in the Resv, then the label operation
   in the NHLFE MUST be a pop and forward regardless of any label
   received from the downstream LSR.

   Section 8 explains how the label stack can be constructed.  For
   example, the LSP from A to I using path A-B-C-D-E-I will use a label
   stack of {150(top), 200}.

8.  Construction of label stack

   The ingress LER or delegation hop MUST check the type of label
   received from each transit hop as recorded in the RRO in the Resv
   message and generate the appropriate label stack to reach the next
   delegation hop or egress, whichever is earlier.

   The following logic could be used by the node constructing the label
   stack:

   Each RRO label sub-object SHOULD be processed starting with the label
   sub-object from the first downstream hop.  Any label provided by the
   first downstream hop MUST always be pushed on the label stack
   regardless of the label type.  If the label type is a pop label, then
   any label from the next downstream hop MUST also be pushed on the
   constructed label stack.  If the label type is a swap label, then any
   label from the next downstream hop MUST NOT be pushed on the
   constructed label stack.  If the label type is a delegation label,
   then the stacking procedure stops at that delegation hop.  Approaches
   in Section 6.1 SHOULD be used to determine how the delegation labels
   are pushed in the label stack.



Sitaraman, et al.        Expires January 4, 2018               [Page 11]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


9.  Facility backup protection

   The following section describe how link and node protection works
   with facility backup protection [RFC4090] for the RSVP-TE pop and
   forward tunnels.

9.1.  Link Protection

   To provide link protection at a PLR with a pop and forward data
   plane, the LSR SHOULD allocate a separate pop label for the TE link
   that will be used for RSVP-TE tunnels that request link-protection
   from the ingress.  No signaling extensions are required to support
   link protection for RSVP-TE tunnels over the pop and forward data
   plane.

       (*) are pop labels to offer link protection for that TE link


         101(*)    151(*)    201(*)    251(*)
    +---+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 7: Link protection topology

   At each LSR, link protected pop labels can be allocated for each TE
   link and a link protecting facility backup LSP can be created to
   protect the TE link.  This label can be sent by the LSR for LSPs
   requesting link-protection over the specific TE link.  Since the
   facility backup terminates at the next-hop (merge point), the
   incoming label on the packet will be what the merge point expects.

   As an example, LSR B can install a facility backup LSP for the link
   protected pop label 151.  When the TE link B-C is up, LSR B will pop
   151 and send the packet to C.  If the TE link B-C is down, the LSR
   can pop 151 and send the packet via the facility backup to C.

9.2.  Node Protection

   The solutions for the PLR to provide node-protection for the pop and
   forward RSVP-TE tunnel will be explained in the next version of the
   document.



Sitaraman, et al.        Expires January 4, 2018               [Page 12]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


10.  Quantifying pop labels

   This section attempts to quantify the number of labels required in
   the forwarding plane to provide sharing of labels across RSVP-TE pop
   and forward tunnels.  A MPLS RSVP-TE tunnel offers either no
   protection, link protection or node protection and only one of these
   labels is required per tunnel during signaling.  The scale of the
   number of pop labels required per LSR can be deduced as follows:


   o  For a LSR having X neighbors reachable across Y interfaces, the
      number of unprotected pop labels = X

   o  For a PLR having X neighbors reachable across Y interfaces, number
      of link protected pop labels = X

   o  For a PLR having X neighbors, each having Nx neighbors (i.e. next-
      nexthop for PLR), number of node protected pop labels =
      SUM_OF_ALL(Nx)

   Total number of pop labels = Unprotected pop labels + link protected
   pop labels + node protected pop labels = 2X + SUM_OF_ALL(Nx)

11.  Protocol Extensions

11.1.  Requirements

   The functionality discussed in this document imposes the following
   requirements on the signaling protocol.


   o  The Ingress of the LSP SHOULD have the ability to mandate/request
      the use and recording of pop labels at all hops along the path of
      the LSP.

   o  When the use of pop labels is mandated/requested for the path,

       - the node recording the pop label SHOULD have the ability to
       indicate if the recorded label is a pop label.

       - the ingress SHOULD have the ability to delegate label stack
       imposition by

           * explicitly mandating specific hops to be delegation hops
           (or)

           * requesting automatic delegation




Sitaraman, et al.        Expires January 4, 2018               [Page 13]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


       - When explicit delegation is mandated or automatic delegation is
       requested,

           * the ingress SHOULD have the ability to indicate the chosen
           stacking approach

           * the delegation hop SHOULD have the ability to indicate that
           the recorded label is a delegation label.

11.2.  Attribute Flags TLV: Pop Label

   Bit Number (TBD1): Pop Label

   The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
   object of a Path message indicates that the ingress has requested/
   mandated the use and recording of pop labels at all hops along the
   path of this LSP.  When a node that does not cater to the mandate
   receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object
   with this flag set, it MUST send a PathErr message with an error code
   of 'routing problem' and an error value of 'pop label usage failure'.


11.3.  RRO Label Subobject Flag: Pop Label

   Bit Number (TBD2): Pop Label

   The presence of this flag indicates that the recorded label is a pop
   label.  This flag MUST be used by a node only if the use and
   recording of pop labels is requested/mandated for the LSP.

11.4.  Attribute Flags TLV: LSI-D

   Bit Number (TBD3): Label Stack Imposition - Delegation (LSI-D)

   Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES
   object of a Path message indicates that the ingress has requested
   automatic delegation of label stack imposition.  This flag MUST be
   set in the LSP_ATTRIBUTES object of a Path message only if the use
   and recording of pop labels is requested/mandated for this LSP.

   Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES
   subobject [RFC7570] of an ERO object in the Path message indicates
   that the hop identified by the preceding IPv4 or IPv6 or Unnumbered
   Interface ID subobject has been picked as an explicit delegation hop.
   The HOP_ATTRIBUTES subobject carrying this flag MUST have the R
   (Required) bit set.  This flag MUST be set in the HOP_ATTRIBUTES
   subobject of an ERO object in the Path message only if the use and
   recording of pop labels is requested/mandated for this LSP.  If the



Sitaraman, et al.        Expires January 4, 2018               [Page 14]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   hop is not able to comply with this mandate, it MUST send a PathErr
   message with an error code of 'routing problem' and an error value of
   'label stack imposition failure'.


11.5.  RRO Label Subobject Flag: Delegation Label

   Bit Number (TBD4): Delegation Label

   The presence of this flag indicates that the recorded label is a
   delegation label.  This flag MUST be used by a node only if the use
   and recording of pop labels and delegation are requested/mandated for
   the LSP.

11.6.  Attributes Flags TLV: LSI-D-S2E

   Bit Number (TBD5): Label Stack Imposition - Delegation - Stack to
   reach egress (LSI-D-S2E)

   The presence of this flag in the LSP_ATTRIBUTES object of a Path
   message indicates that the ingress has chosen to use the "Stack to
   reach egress" approach for stacking.  The absence of this flag in the
   LSP_ATTRIBUTES object of a Path message indicates that the ingress
   has chosen to use the "Stack to reach delegation hop" approach for
   stacking.  This flag MUST be set in the LSP_ATTRIBUTES object of a
   Path message only if the use and recording of pop labels and
   delegation are requested/mandated for this LSP.

11.7.  Attributes TLV: ETLD

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved                              |     ETLD      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Attribute TLV Type: TBD6

   The presence of this TLV in the HOP_ATTRIBUTES subobject of an RRO
   object in the Path message indicates that the hop identified by the
   preceding IPv4 or IPv6 or Unnumbered Interface ID subobject supports
   automatic delegation.  This attribute MUST be used only if the use
   and recording of pop labels is requested/mandated and automatic
   delegation is requested for the LSP.  The ETLD field specifies the
   maximum number of transport labels that this hop can potentially send
   to its downstream hop.





Sitaraman, et al.        Expires January 4, 2018               [Page 15]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


12.  OAM considerations

   MPLS LSP ping and traceroute [RFC8029] are applicable for RSVP-TE pop
   and forward tunnels.  The existing procedures allow for the label
   stack imposed at a delegation hop to be reported back in the Label
   Stack Sub-TLV in the MPLS echo reply for traceroute.

13.  Acknowledgements

   The authors would like to thank Adrian Farrel, Kireeti Kompella,
   Markus Jork and Ross Callon for their input from discussions.

14.  Contributors

   The following individuals contributed to this document:

   Raveendra Torvi
   Juniper Networks
   Email: rtorvi@juniper.net

   Chandra Ramachandran
   Juniper Networks
   Email: csekar@juniper.net

   George Swallow
   Email: swallow.ietf@gmail.com

15.  IANA Considerations

15.1.  Attribute Flags: Pop Label, LSI-D, LSI-D-S2E

   IANA manages the 'Attribute Flags' registry as part of the 'Resource
   Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters'
   registry located at http://www.iana.org/assignments/rsvp-te-
   parameters.  This document introduces three new Attribute Flags.

      Bit  Name              Attribute Attribute RRO ERO Reference
      No.                    FlagsPath FlagsResv
      TBD1 Pop Label         Yes       No        No  No  This document
                                                         (Section 11.2)
      TBD3 LSI-D             Yes       No        No  Yes This document
                                                         (Section 11.4)
      TBD5 LSI-D-S2E         Yes       No        No  No  This document
                                                         (Section 11.6)







Sitaraman, et al.        Expires January 4, 2018               [Page 16]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


15.2.  Attribute TLV: ETLD

   IANA manages the "Attribute TLV Space" registry as part of the
   'Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
   Parameters' registry located at http://www.iana.org/assignments/rsvp-
   te-parameters.  This document introduces a new Attribute TLV.

      Type   Name    Allowed on  Allowed on   Allowed on  Reference
                     LSP         LSP REQUIRED LSP Hop
                     ATTRIBUTES  ATTRIBUTES   Attributes


      TBD6   ETLD    No          No           Yes         This document
                                                          (Section 11.7)

15.3.  Record Route Label Sub-object Flags: Pop Label, Delegation Label

   IANA manages the 'Record Route Object Sub-object Flags' registry as
   part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP-
   TE) Parameters' registry located at http://www.iana.org/assignments/
   rsvp-te-parameters.  This registry currently does not include Label
   Sub-object Flags.  This document proposes the addition of a new sub-
   registry for Label Sub-object Flags as shown below.

      Flag  Name                    Reference

      0x1   Global Label            RFC 3209
      TBD2  Pop Label               This document (Section 11.3)
      TBD4  Delegation Label        This document (Section 11.5)


16.  Security Considerations

   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC2205] and
   RSVP-TE [RFC3209] and those that are described in [RFC5920] remain
   relevant.

17.  References

17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.





Sitaraman, et al.        Expires January 4, 2018               [Page 17]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <http://www.rfc-editor.org/info/rfc2205>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

   [RFC7570]  Margaria, C., Ed., Martinelli, G., Balls, S., and B.
              Wright, "Label Switched Path (LSP) Attribute in the
              Explicit Route Object (ERO)", RFC 7570,
              DOI 10.17487/RFC7570, July 2015,
              <http://www.rfc-editor.org/info/rfc7570>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <http://www.rfc-editor.org/info/rfc8029>.

17.2.  Informative References

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-12 (work in progress), June 2017.

   [I-D.ietf-teas-rsvp-te-scaling-rec]
              Beeram, V., Minei, I., Shakir, R., Pacella, D., and T.
              Saad, "Implementation Recommendations to Improve the
              Scalability of RSVP-TE Deployments", draft-ietf-teas-rsvp-
              te-scaling-rec-04 (work in progress), March 2017.







Sitaraman, et al.        Expires January 4, 2018               [Page 18]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   [I-D.ietf-teas-sr-rsvp-coexistence-rec]
              Sitaraman, H., Beeram, V., Minei, I., and S. Sivabalan,
              "Recommendations for RSVP-TE and Segment Routing LSP co-
              existence", draft-ietf-teas-sr-rsvp-coexistence-rec-01
              (work in progress), June 2017.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
              <http://www.rfc-editor.org/info/rfc2961>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <http://www.rfc-editor.org/info/rfc5920>.

Authors' Addresses

   Harish Sitaraman
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   US

   Email: hsitaraman@juniper.net


   Vishnu Pavan Beeram
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   US

   Email: vbeeram@juniper.net


   Tejal Parikh
   Verizon
   400 International Parkway
   Richardson, TX  75081
   US

   Email: tejal.parikh@verizon.com









Sitaraman, et al.        Expires January 4, 2018               [Page 19]


Internet-Draft       RSVP-TE pop and forward tunnel            July 2017


   Tarek Saad
   Cisco Systems
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada

   Email: tsaad@cisco.com












































Sitaraman, et al.        Expires January 4, 2018               [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/