wdiff rfc8577.original rfc8577.txt

MPLS Working Group
Internet Engineering Task Force (IETF) H. Sitaraman
Internet-Draft
Request for Comments: 8577 V. Beeram
Intended status:
Category: Standards Track Juniper Networks
Expires: August 4, 2019
ISSN: 2070-1721 T. Parikh
Verizon
T. Saad
Cisco Systems
January 31,
April 2019

Signaling RSVP-TE tunnels Tunnels on a shared Shared MPLS forwarding plane
draft-ietf-mpls-rsvp-shared-labels-09.txt Forwarding Plane

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. the amount of control-plane state
information.

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 control-plane
scaling on that node. It introduces the notion of pre-installed 'per
Traffic Engineering (TE) preinstalled 'per-
TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse
these TE links. This approach significantly reduces the forwarding 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 (SR) MPLS forwarding plane.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

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 an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 August 4, 2019.
https://www.rfc-editor.org/info/rfc8577.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)
(https://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 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 5 6
4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 5 6
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7 8
5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 9
5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8 10
5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 9 11
5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 10 11
5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 10 11
5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 10 11
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 12 13
7. Construction of Label Stacks . . . . . . . . . . . . . . . . 12 14
8. Facility Backup Protection . . . . . . . . . . . . . . . . . 13 14
8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 14
9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 14 15
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 14 15
9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 15 16
9.3. RRO Label Subobject Sub-object Flag: TE Link Label . . . . . . . . . 15 16
9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 15 16
9.5. RRO Label Subobject Sub-object Flag: Delegation Label . . . . . . . 16 17
9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 16 17
9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 16 18
10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 17 18
11. Acknowledgements . . . IANA Considerations . . . . . . . . . . . . . . . . . . . 17
12. Contributors . . 19
11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 19
11.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations 19
11.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . . . . . . . . . . . 20
11.4. Error Codes and Error Values . 18
13.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 18
13.2. Attribute TLV: ETLD . . . . . . . . . 20
12. Security Considerations . . . . . . . . . 18
13.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . 20
13. References . . . . . . . . . . 19
13.4. Error Codes and Error Values . . . . . . . . . . . . . . 19
14. Security Considerations . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 19
15. 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . 22
Contributors . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . 21 . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 24

1. Introduction

The scaling of RSVP-TE [RFC3209] control plane control-plane implementations can be
improved by adopting the guidelines and mechanisms described in
[RFC2961] and [RFC8370]. These documents do not make any difference
to affect the forwarding plane
forwarding-plane state required to handle the control plane control-plane state.
The forwarding plane 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
platform-specific label space on a Label Switching Router (LSR) from
being a constraint to pushing the limits of control plane control-plane scaling on
that node.

This work introduces the notion of pre-installed 'per Traffic
Engineering (TE) preinstalled 'per-TE link labels'
that are allocated by an LSR. Each such label is installed in the
MPLS forwarding plane with a 'pop' operation and the instruction instructions 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 up, and
they are recorded hop-by-hop hop by hop in the Record Route object Object (RRO) of the
Resv message as it traverses the network. To make use of this feature, the The ingress Label Edge
Router (LER) constructs and pushes a stack of labels [RFC3031] as using
the labels received in the RRO. These 'TE link labels' can be shared
by MPLS RSVP-TE LSPs that traverse the same TE link.

This forwarding plane forwarding-plane behavior fits in the MPLS architecture
[RFC3031] and is the same as that exhibited by Segment Routing (SR)
[RFC8402] when using an MPLS forwarding plane and a series of
adjacency segments [I-D.ietf-spring-segment-routing-mpls]. [SEG-ROUTING]. This work couples the feature
benefits of the RSVP-TE control plane with the simplicity of the Segment Routing SR
MPLS forwarding plane.

RSVP-TE using a shared MPLS forwarding plane offers the following
benefits:

1. Shared Labels: labels: The transit label on a TE link is shared among
RSVP-TE tunnels traversing the link and is used independent independently of
the ingress and egress of the LSPs.

2. Faster LSP setup time: No forwarding plane forwarding-plane state needs to be
programmed during LSP setup and teardown teardown, resulting in faster time
for
provisioning and deprovisioning of LSPs.

3. Hitless re-routing: rerouting: 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 labels,
thereby making 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 Mix-and-match labels: Both 'TE link labels' and regular 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 regular labels in Resv messages.

No additional extensions to routing protocols are required in order
to support key functionalities such as bandwidth admission control,
LSP priorities, preemption preemption, and auto-bandwidth on this shared MPLS
forwarding plane. This document also discusses how Fast Reroute
[RFC4090] via facility backup link protection using regular bypass
tunnels can be supported on this forwarding plane.

The signaling procedures and extensions discussed in this document do
not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels. tunnels.

2. Terminology

The following terms are used in this document:

TE link 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.

Shared MPLS forwarding plane: An MPLS forwarding plane where every
participating LSR uses TE link labels on every LSP.

Segment Routed RSVP-TE tunnel: An MPLS RSVP-TE tunnel that requests
the use of a shared MPLS forwarding plane at every hop of the LSP.
The corresponding LSPs are referred to as Segment "Segment Routed RSVP-TE
LSPs.
LSPs".

Delegation hop: A transit hop of a Segment Routed RSVP-TE LSP that
is selected to assist in the imposition of the label stack in
scenarios where the ingress LER cannot impose the full label
stack. There could can be multiple delegation hops along the path of a
Segment Routed RSVP-TE LSP.

Delegation label: A label assigned at the delegation hop to
represent a set of labels that will be pushed at this hop.

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Allocation of TE Link Labels

An LSR that participates in a shared MPLS forwarding plane MUST
allocate a unique TE link label for each TE link. When an LSR
encounters a TE link label at the top of the label stack stack, it MUST pop
the label and forward the packet over the TE link to the downstream
neighbor on the RSVP-TE tunnel.

Multiple TE link labels MAY be allocated for the TE link to
accommodate tunnels requesting protection.

Implementations that maintain per label per-label bandwidth accounting at each
hop must aggregate the reservations made for all the LSPs using the
shared TE link label.

4. Segment Routed RSVP-TE Tunnel Setup

This section provides an example of how the RSVP-TE signaling
procedure works to set up a tunnel utilizing a shared MPLS forwarding
plane. The sample topology below is used to explain the example.
Labels shown at each node are TE link 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.

+---+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: Sample Topology - -- TE Link Labels
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 TE link
label attributes flag defined in Section 9.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 TE link label (250) in the Resv message
for the tunnel placing the label value in the Label object and object. It also
provides the TE link label (250) in the Label subobject sub-object carried in
the RRO and setting sets the TE link label flag as defined in Section 9.3.

Similarly, LSR C provides the TE link label (200) for the TE link
C-D, and LSR B provides the TE link label (150) for the TE link B-C.

For tunnel T2, the transit LSRs provide the same TE link 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
T2, respectively.

It should be noted that a transit LSR does not swap the top TE link
label on an incoming packet (the label that it advertised in the Resv
message it sent). All sent); all it has to do is pop the top label and forward
the packet.

The values in the Label subobjects sub-objects in the RRO are of interest to the
ingress LERs in order to construct when constructing the stack of labels to impose on the
packets.

If, in this example, there was were another RSVP-TE tunnel T3 from F to I
on path F-B-C-D-E-I, then this tunnel 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
shared MPLS forwarding plane.

There MAY be a local operator policy at the ingress LER that
influences the maximum depth of the label stack that can be pushed
for a Segment Routed RSVP-TE tunnel. Prior to signaling the LSP, the
ingress LER may determine that it would be is unable to push a label stack
containing one label for each hop along the path. In some scenarios,
the ingress LER may not have sufficient information to make that
determination. In these cases cases, the LER SHOULD adopt the techniques
described in Section 5.

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 :

Notation: <Label>p - TE link label
<Label>d - delegation Delegation label

Figure 2: Delegating Label Stack Imposition

5.1. Stacking at the Ingress

When delegation labels come into play, there are two stacking
approaches that from which the ingress can choose from. choose. Section 7 explains how
the label stack can be constructed.

5.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. 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. 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.

This approach is shown in Figure 3. The delegation label 1250
represents the stack {300, 350, 400, 450, 1500} 1500}, and the delegation
label 1500 represents the label stack {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, the ingress LER A will push {150, 200, 1250} for
the tunnel in Figure 2. At LSR D, the delegation label 1250 will get
popped
popped, and {300, 350, 400, 450, 1500} will get pushed. And at At LSR I,
the delegation label 1500 will get popped popped, and the remaining set of
labels {550, 600} will get pushed.

5.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 so that
all the delegation labels are part of the 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. 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.

This approach is shown in Figure 4. The delegation label 1250
represents the stack {300, 350, 400, 450} 450}, and the delegation label
1500 represents the label stack {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 Reach Egress

With this approach, the ingress LER A will push {150, 200, 1250,
1500} for the tunnel in Figure 2. At LSR D, the delegation label
1250 will get popped popped, and {300, 350, 400, 450} will get pushed. And
at At
LSR I, the delegation label 1500 will get popped 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 9.6.

5.2. Explicit Delegation

In this delegation option, the ingress LER can explicitly delegate
one or more specific transit LSRs to handle pushing labels for a
certain number of their downstream hops. In order to accurately pick
the delegation hops, the ingress needs to be aware of the label stack
depth push limit (total number of MPLS labels that can be imposed,
including all service/transport/special labels) 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. An Base MPLS Imposition MSD (BMI-MSD) advertisement,
specified in [RFC8491], is an example of such a mechanism is specified in
[RFC8491] (BMI-MSD advertisement). mechanism.

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

5.3. Automatic Delegation

In this approach, the ingress LER lets the downstream LSRs
automatically pick suitable delegation hops during the initial
signaling sequence. The ingress does not need to be aware up front
of the label stack depth push limit of each of the transit LSRs.
This approach SHOULD be used if there are loose hops [RFC3209] in the
explicit route. The delegation hops are picked based on a per-hop
signaled attribute called the Effective Transport Label-Stack Depth
(ETLD)
(ETLD), as described in the next section.

5.3.1. Effective Transport Label-Stack Depth (ETLD)

The ETLD is signaled as a per-hop recorded attribute in the Path
message [RFC7570]. 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 and it is determined that this hop cannot support automatic
delegation, then it MUST NOT use TE link labels and use regular
labels instead. 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 local
policy. For example, consider a transit node with a local policy
that mandates it to take the label stack read limit into account when
decrementing the ETLD. With this policy, the ETLD is decremented in
such a way that the transit hop does not receive any more labels in the
stack than it can read. At each delegation hop, the ETLD MUST be
reset to the maximum number of transport labels that the hop can send
send, and the ETLD decrements start again at each successive hop
until either a new delegation hop is selected or the egress is
reached. As a result, 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.

Consider the example shown in Figure 5. Let's assume ingress LER A
can push up to 3 three transport labels while the remaining nodes can
push up to 5 five transport labels. The ingress LER A signals the
initial Path message with ETLD set to 3. The ETLD value is adjusted
at each successive hop and signaled downstream as shown. By the time
the Path message reaches the egress LER L, LSRs D and I are
automatically selected as delegation hops.

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

When an LSP that requests automatic delegation also requests facility
backup protection [RFC4090], the ingress or the delegation hop MUST
account for the bypass tunnel's label(s) when populating the ETLD.
Hence, when a regular bypass tunnel is used to protect the facility,
the ETLD that gets populated on these nodes is one less than what
gets populated for a corresponding unprotected LSP.

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

6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel

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

(#) (#)
+---+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 +---+

Notation :

Notation: (#) denotes regular labels
Other labels are TE link labels

Figure 6: Sample Topology - -- TE Link Labels and Regular Labels

If the transit LSR allocates a regular label to be sent upstream in
the Resv, then the label operation at the LSR is a swap to the label
received from the downstream LSR. If the transit LSR is using a TE
link label to be sent upstream in the Resv, then the label operation
at the LSR is a pop and forward regardless of any label received from
the downstream LSR. There is no change in the behavior of a
penultimate hop popping (PHP) LSR [RFC3031].

Section 7 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, 200}.

7. Construction of Label Stacks

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 the egress.

The following logic is used by the node constructing the label stack:

Each RRO label sub-object MUST 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
TE link label, then any label from the next downstream hop MUST
also be pushed on the constructed label stack. If the label type
is a regular 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 type of stacking approach
chosen by the ingress for this LSP (Section 5.1) MUST be used to
determine how the delegation labels are pushed in the label stack.

8. Facility Backup Protection

The following section describes how link protection works with
facility backup protection [RFC4090] using regular bypass tunnels for
the Segment Routed RSVP-TE tunnels. The procedures for supporting
node protection are not discussed in this document. The use of
Segment Routed bypass tunnels for providing facility protection is
left for further study.

8.1. Link Protection

To provide link protection at a Point of Local Repair (PLR) with a
shared MPLS forwarding plane, the LSR MUST allocate a separate TE
link 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
shared MPLS forwarding plane.

At each LSR, link protected link-protected TE link labels can be allocated for each
TE link link, and a link protecting link-protecting facility backup LSP can be created to
protect the TE link. The link protected link-protected TE link 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 next hop (merge
point), the incoming label on the packet will be what the merge point
expects.

Consider the network shown in Figure 7. LSR B can install a facility
backup LSP for the link protected link-protected TE link 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.

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

Notation :

Notation: (*) denotes link protection link-protected TE link labels

Figure 7: Link Protection Topology

9. Protocol Extensions

9.1. Requirements

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

o The Ingress ingress of the LSP needs to have the ability to mandate/
request the use and recording of TE link labels at all hops along
the path of the LSP.

o When the use of TE link labels is mandated/requested for the path:

* the node recording the TE link label needs to have the ability
to indicate if whether the recorded label is a TE link label.

* the ingress needs to have the ability to delegate label stack
imposition by:

+ explicitly mandating specific hops to be delegation hops
(or) hops, or

+ requesting automatic delegation.

* When explicit delegation is mandated or automatic delegation is
requested:

+ the ingress needs to have the ability to indicate the chosen
stacking approach (and) approach, and

+ the delegation hop needs to have the ability to indicate
that the recorded label is a delegation label.

9.2. Attribute Flags TLV: TE Link Label

Bit Number 16 (Early allocation by IANA): 16: TE Link Label

The presence of this flag in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES LSP_ATTRIBUTES/
LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message indicates
that the ingress has requested/mandated the use and recording of TE
link labels at all hops along the path of this LSP. When a node that
recognizes this flag but does not cater to the mandate because of
local policy 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 (24)' and an
error value of 'TE link label usage failure (TBD3)'. (70)'. A transit hop
that caters to this request/mandate MUST also check for the presence
of other Attribute Flags introduced in this document (Section (Sections 9.4
and Section 9.6) and process them as specified. An ingress LER that sets
this bit MUST also set the "label recording desired" flag [RFC3209]
in the SESSION_ATTRIBUTE object.

9.3. RRO Label Subobject Sub-object Flag: TE Link Label

Bit Number (TBD1):

Flag (0x02): TE Link Label

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

9.4. Attribute Flags TLV: LSI-D

Bit Number 17 (Early allocation by IANA): 17: 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 TE link labels is are requested/mandated for this LSP.
If the transit hop does not support this flag, it MUST NOT use TE
link labels and use regular labels instead. If the use of TE link
labels was mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST
send a PathErr message with an error code of 'Routing Problem (24)'
and an error value of 'TE link label usage failure (TBD3)'. (70)'.

Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES
subobject
sub-object [RFC7570] of an Explicit Route Object (ERO) in the Path
message indicates that the hop identified by the preceding IPv4 or
IPv6 or Unnumbered Interface ID subobject sub-object has been picked as an
explicit delegation hop. The HOP_ATTRIBUTES subobject sub-object carrying this
flag MUST have the R (Required) bit set. This flag MUST be set in
the HOP_ATTRIBUTES subobject sub-object of an ERO object in the Path message
only if the use and recording of TE link labels is requested/mandated are requested/
mandated for this LSP. If the hop recognizes this flag but is not
able to comply with this mandate because of local policy, it MUST
send a PathErr message with an error code of 'Routing Problem (24)'
and an error value of 'Label stack imposition failure (TBD4)'. (71)'.

9.5. RRO Label Subobject Sub-object Flag: Delegation Label

Bit Number (TBD2):

Flag (0x04): 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 TE link labels and delegation are requested/mandated
for the LSP.

9.6. Attributes Flags TLV: LSI-D-S2E

Bit Number 18 (Early allocation by IANA): 18: Label Stack Imposition - Delegation - Stack to reach egress 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 TE link labels and
delegation are requested/mandated for this LSP. If the transit hop
is not able to support the "Stack to reach egress" approach, it MUST
send a PathErr message with an error code of 'Routing Problem (24)'
and an error value of 'Label stack imposition failure (TBD4)'. (71)'.

9.7. Attributes TLV: ETLD

The format of the ETLD Attributes TLV is shown in Figure 8. The
Attribute TLV Type is 6 (Early allocation by IANA). 6.

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

Figure 8: The ETLD Attributes TLV

The presence of this TLV in the HOP_ATTRIBUTES subobject sub-object of an RRO
object in the Path message indicates that the hop identified by the
preceding IPv4 or IPv6 or Unnumbered Interface ID subobject sub-object supports
automatic delegation. This attribute MUST be used only if the use
and recording of TE link labels is are requested/mandated and automatic
delegation is requested for the LSP.

The ETLD field specifies the effective number of transport labels
that this hop (in relation to its position in the path) can
potentially send to its downstream hop. It MUST be set to a non-zero
value.

The Reserved field is for future specification. It SHOULD be set to
zero on transmission and MUST be ignored on receipt to ensure future
compatibility.

10. OAM Considerations

MPLS LSP ping and traceroute [RFC8029] are applicable for Segment
Routed RSVP-TE 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.

11. Acknowledgements

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

Adrian Farrel provided a review and text suggestion for clarity and
readability.

12. 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

13. IANA Considerations

13.1.

11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E

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

Bit Name Attribute Attribute RRO ERO Reference
No. FlagsPath FlagsResv
No Flags Path Flags Resv

16 TE Link Label Yes No No No [This.ID]
(Section 9.2) [RFC8577],
Section 9.2

17 LSI-D Yes No No Yes [This.ID]
(Section 9.4) [RFC8577],
Section 9.4

18 LSI-D-S2E Yes No No No [This.ID]
(Section 9.6)

Note: The code points specified for TE Link Label, LSI-D and LSI-
D-S2E are early allocations by IANA.

13.2. [RFC8577],
Section 9.6

11.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. <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_ATTRIBUTES LSP_REQUIRED LSP Hop
ATTRIBUTES ATTRIBUTES
_ATTRIBUTES Attributes

6 ETLD No No Yes [This.ID]
(Section 9.7)

Note: The code point specified for ETLD is an early allocation by
IANA.

13.3. [RFC8577],
Section 9.7

11.3. Record Route Label Sub-object Flags: TE Link Label, Delegation
Label

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

Flag Name Reference

0x1 Global Label RFC 3209
TBD1 [RFC3209]
0x02 TE Link Label [This.ID] (Section 9.3)
TBD2 [RFC8577], Section 9.3
0x04 Delegation Label [This.ID] (Section 9.5)

All assignments in this sub-registry are to be performed via
Standards Action.

13.4. [RFC8577], Section 9.5

11.4. Error Codes and Error Values

IANA maintains a registry called "Resource Reservation Protocol
(RSVP) Parameters" with a subregistry called "Error Codes and
Globally-Defined Error Value Sub-Codes". Within this subregistry
there is
a definition of the "Routing Problem" error code with error
code value 24. Error Code (24). The
definition lists a number of error values that may be used with this
error code. IANA is requested to allocate has allocated further error values for use with
this error code Error Code as described in this document. The resulting entry
in the registry should look is as follows.

24 Routing Problem [RFC3209]

This Error Code has the following globally-defined globally defined Error
Value sub-codes:

TBD3

70 = TE link label usage failure [This.ID]
TBD4 [RFC8577]
71 = Label stack imposition failure [This.ID]

14. [RFC8577]

12. 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.

15.

13. References

15.1.

13.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, <https://www.rfc-
editor.org/info/rfc2119>.
<https://www.rfc-editor.org/info/rfc2119>.

[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, <https://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, <https://www.rfc-
editor.org/info/rfc3031>.
<https://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,
<https://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, <https://www.rfc-
editor.org/info/rfc4090>.
<https://www.rfc-editor.org/info/rfc4090>.

[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <https://www.rfc-editor.org/info/rfc5420>.

[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, <https://www.rfc-
editor.org/info/rfc7570>.
<https://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, <https://www.rfc-
editor.org/info/rfc8029>.
<https://www.rfc-editor.org/info/rfc8029>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

15.2.

13.2. Informative References

[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), December 2018.

[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,
<https://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,
<https://www.rfc-editor.org/info/rfc5920>.

[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
T. Saad, "Techniques to Improve the Scalability of RSVP-TE
Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
<https://www.rfc-editor.org/info/rfc8370>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018, <https://www.rfc-
editor.org/info/rfc8491>.
<https://www.rfc-editor.org/info/rfc8491>.

[SEG-ROUTING]
Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with MPLS data plane", Work in Progress,
draft-ietf-spring-segment-routing-mpls-18, December 2018.

Acknowledgements

The authors would like to thank Adrian Farrel, Kireeti Kompella,
Markus Jork, and Ross Callon for their input from discussions.
Adrian Farrel provided a review and a text suggestion for clarity and
readability.

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

Authors' Addresses

Harish Sitaraman
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
US
United States of America

Email: hsitaraman@juniper.net harish.ietf@gmail.com

Vishnu Pavan Beeram
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
US
United States of America

Email: vbeeram@juniper.net

Tejal Parikh
Verizon
400 International Parkway
Richardson, TX 75081
US
United States of America

Email: tejal.parikh@verizon.com

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

Email: tsaad@cisco.com tsaad.net@gmail.com