draft-ietf-teas-rsvp-rmr-extension-00.txt   draft-ietf-teas-rsvp-rmr-extension-01.txt 
TEAS WG A. Deshmukh TEAS WG A. Deshmukh
Internet-Draft K. Kompella Internet-Draft K. Kompella
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Juniper Networks, Inc.
Expires: December 21, 2018 June 19, 2018 Expires: December 30, 2018 June 28, 2018
RSVP Extensions for RMR RSVP Extensions for RMR
draft-ietf-teas-rsvp-rmr-extension-00 draft-ietf-teas-rsvp-rmr-extension-01
Abstract Abstract
Rings are the most common topology in access and aggregation Ring topology is commonly found in access and aggregation networks.
networks. However, the use of MPLS as the transport protocol for However, the use of MPLS as the transport protocol for rings is very
rings is very limited today. draft-ietf-mpls-rmr-02 describes a limited today. draft-ietf-mpls-rmr-02 describes a mechanism to
mechanism to handle rings efficiently using MPLS. This document handle rings efficiently using MPLS. This document describes the
describes the extensions to the RSVP protocol for signaling MPLS extensions to the RSVP-TE protocol for signaling MPLS label switched
label switched paths in rings. paths in rings.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2018. This Internet-Draft will expire on December 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Session Object . . . . . . . . . . . . . . . . . . . . . 4 3.1. Session Object . . . . . . . . . . . . . . . . . . . . . 4
3.2. SENDER_TEMPLATE,FILTER_SPEC Objects . . . . . . . . . . . 5 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects . . . . . . . . . . . 5
4. Ring Signaling Procedures . . . . . . . . . . . . . . . . . . 5 4. Ring Signaling Procedures . . . . . . . . . . . . . . . . . . 5
4.1. Differences from regular RSVP-TE LSPs . . . . . . . . . . 5 4.1. Differences from regular RSVP-TE LSPs . . . . . . . . . . 5
4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 5 4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 7 4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 8
4.2.2. Resv Processing for RMR . . . . . . . . . . . . . . . 8 4.2.2. Resv Processing for RMR . . . . . . . . . . . . . . . 8
4.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Ring changes . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Ring changes . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Bandwidth management . . . . . . . . . . . . . . . . . . 11 4.5. Express Links . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Bandwidth management . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document extends RSVP-TE [RFC3209] to establish label-switched This document extends RSVP-TE [RFC3209] to establish label-switched
path (LSP) tunnels in the ring topology. Rings are auto-discovered path (LSP) tunnels in the ring topology. Rings are auto-discovered
using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02]. using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02].
Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for
auto-discovering the rings. auto-discovering the rings.
After the rings are auto-discovered, each ring node knows its After the rings are auto-discovered, each node in the ring knows its
clockwise (CW) and anti-clockwise (AC) ring neighbors and its ring clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring
links. All of the express links in the ring also get identified as links. All of the express links in the ring also get identified as
part of the auto-discovery process. At this point, every node in the part of the auto-discovery process. At this point, every node in the
ring informs the RSVP protocol to begin the signaling of the ring ring informs the RSVP protocol to begin the signaling of the ring
LSPs. LSPs.
Section 2 covers the terminology used in this document. Section 3 Section 2 covers the terminology used in this document. Section 3
presents the RSVP protocol extensions needed to support MPLS rings. presents the RSVP protocol extensions needed to support MPLS rings.
Section 4 describes the procedures of RSVP LSP signaling in detail. Section 4 describes the procedures of RSVP LSP signaling in detail.
1.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.
2. Terminology 2. Terminology
A ring consists of a subset of n nodes {R_i, 0 <= i < n}. We define Assuming there are n nodes in the network, a ring gets formed by a
the direction from node R_i to R_i+1 as "clockwise" (CW) and the subset of those n nodes {Ri, Ri+1, Ri+2,...Rn}. We define the
reverse direction as "anti-clockwise" (AC). As there may be several direction from node Ri to Ri+1 as "clockwise" (CW) and the reverse
rings in a graph, we number each ring with a distinct ring ID RID. direction as "anti-clockwise" (AC). As there might be several rings
in a graph, each ring is identified by it's own distinct ring ID -
RID.
R0 . . . R1 R0 . . . R1
. . . .
R7 R2 R7 R2
Anti- | . Ring . | Anti- | . Ring . |
Clockwise | . . | Clockwise Clockwise | . . | Clockwise
v . RID = 17 . v v . RID = 17 . v
R6 R3 R6 R3
. . . .
R5 . . . R4 R5 . . . R4
Figure 1: Ring with 8 nodes Figure 1: Ring with 8 nodes
The following terminology is used for ring LSPs: The following terminology is used for ring LSPs:
Ring ID (RID): A non-zero number that identifies a ring; this is Ring ID (RID): A non-zero number that identifies a ring; this is
unique in some scope of a Service Provider's network. A node may unique in a Service Provider's network. A node may belong to
belong to multiple rings. multiple rings.
Ring node: A member of a ring. Note that a device may belong to Ring node: A member of a ring. Note that a device may belong to
several rings. several rings.
Node index: A logical numbering of nodes in a ring, from zero upto Node index: A logical numbering of nodes in a ring, from zero up to
one less than the ring size. Used purely for exposition in this one less than the ring size. Used purely for exposition in this
document. document.
Ring neighbors: Nodes whose indices differ by one (modulo ring Ring neighbors: Nodes whose indices differ by one (modulo ring
size). size).
Ring links: Links that connect ring neighbors. Ring links: Links that connect ring neighbors.
Express links: Links that connect non-neighboring ring nodes. Express links: Links that connect non-neighboring ring nodes.
skipping to change at page 4, line 35 skipping to change at page 4, line 40
| Ring ID | | Ring ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SESSION Object SESSION Object
Ring anchor node address: IPv4 address of the anchor node. Each Ring anchor node address: IPv4 address of the anchor node. Each
anchor node creates a LSP addressed to itself. anchor node creates a LSP addressed to itself.
Ring Instance ID: A 16-bit identifier used in the SESSION. This Ring Instance ID: A 16-bit identifier used in the SESSION. This
Ring Instance ID is useful for graceful ring changes. If a new Ring Instance ID is useful for graceful ring changes. If a new
node is being added to the ring or some existing node goes down node is being added to the ring(resulting in signaling of a larger
and we have to signal a smaller ring, in those cases, anchor node ring) or some existing node goes down(resulting in signaling of a
creates a new tunnel with a different Ring Instance ID. smaller ring), in those cases, anchor node creates a new tunnel
with a different Ring Instance ID.
Ring ID: A 32-bit number that identifies a ring; this is unique in Ring ID: A 32-bit number that identifies a ring; this is unique in
some scope of a Service Provider's network. This number remains some scope of a Service Provider's network. This number remains
constant throughout the existence of ring. constant throughout the existence of ring.
Ring Flags: For each ring, the anchor node starts signaling of a Ring Flags: For each ring, the anchor node starts signaling of a
ring LSP. Ring LSP RL_i, anchored on node R_i, consists of two ring LSP. Ring LSP named RLi, anchored on node Ri, consists of
counter-rotating unicast LSPs that start and end at R_i. One LSP two counter-rotating unicast LSPs that start and end at Ri. One
will be in the clockwise direction and other LSP will be in the LSP will be in the clockwise direction and other LSP will be in
anti-clockwise direction. A ring LSP is "multipoint": any node the anti-clockwise direction. A ring LSP is "multipoint": any
R_j can use RL_i to send traffic to R_i; this can be in either the node along the ring can use LSP RLi to send traffic to Ri; this
CW or AC directions, or both (i.e., load balanced). Two new flags can be in either the CW or AC directions, or both (i.e., load
are defined in the SESSION object which define the ring direction balanced). Two new flags are defined in the SESSION object which
of the corresponding Path message. define the ring direction of the corresponding Path message.
ClockWise(CW) Direction 0x01: This flag indicates that the ClockWise(CW) Direction 0x01: This flag indicates that the
corresponding Path message is traveling in the ClockWise(CW) corresponding Path message is traveling in the ClockWise(CW)
direction along the ring. direction along the ring.
Anti-ClockWise(AC) Direction 0x02: This flag indicates that the Anti-ClockWise(AC) Direction 0x02: This flag indicates that the
corresponding Path message is traveling in the Anti-ClockWise(AC) corresponding Path message is traveling in the Anti-ClockWise(AC)
direction along the ring. direction along the ring.
3.2. SENDER_TEMPLATE,FILTER_SPEC Objects 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects
There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC
objects. The format of the above 2 objects will be similar to the objects. The format of the above 2 objects will be similar to the
definitions in RFC 3209. [RFC3209] Only the semantics of these definitions in RFC 3209. [RFC3209] Only the semantics of these
objects will slightly change. This will be explained in section objects will slightly change. This will be explained in section
Section 4.5 below. Section 4.6 below.
4. Ring Signaling Procedures 4. Ring Signaling Procedures
A ring node indicates in its IGP updates the ring LSP signaling A ring node indicates in its IGP updates the ring LSP signaling
protocols that it supports. This can be LDP and/or RSVP-TE. protocols that it supports. This can be LDP and/or RSVP-TE.
Ideally, each node should support both. If the ring is configured Ideally, each node should support both. If the ring is configured
with RSVP as the signaling protocol, then once a ring node R_i knows with RSVP as the signaling protocol, then once a ring node R_i knows
the RID, its ring links and directions, it kicks off ring RSVP LSP the RID, its ring links and directions, it kicks off ring RSVP LSP
signaling automatically. signaling automatically.
4.1. Differences from regular RSVP-TE LSPs 4.1. Differences from regular RSVP-TE LSPs
Ring LSPs differ from regular RSVP-TE LSPs in several ways: Ring LSPs differ from regular RSVP-TE LSPs in several ways:
1. Ring LSPs (by construction) form a loop. 1. Ring LSPs (by construction) form a loop.
2. Ring LSPs are multipoint-to-point. Any ring node can inject 2. Ring LSPs are multipoint-to-point. Any ring node can inject
traffic into a ring LSP. traffic into a ring LSP.
3. The bandwidth of a ring LSP can change hop-to-hop. 3. The bandwidth of a ring LSP can change hop-by-hop.
4. Ring LSPs are protected without the use of bypass or detour LSPs. 4. Ring LSPs are protected without the use of bypass or detour LSPs.
Ring LSP protection is akin to SONET/SDH ring protection. Protection is handled by the ring LSP traversing in the opposite
direction.
4.2. LSP signaling 4.2. LSP signaling
After the ring auto-discovery process, each anchor node creates a LSP After the ring auto-discovery process, each anchor node creates a LSP
addressed to itself. This ring LSP contains of a pair of counter- addressed to itself. This ring LSP contains of a pair of counter-
rotating unicast LSPs. So, for a ring containing N nodes, there will rotating unicast LSPs. So, for a ring containing N nodes, there will
be 2N total LSPs signaled. be 2N total LSPs signaled.
There is no need for ERO object in the Path message. The Path There is no need for ERO object in the Path message. The Path
message for ring LSPs has the following format: message for ring LSPs has the following format:
skipping to change at page 6, line 19 skipping to change at page 6, line 29
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
<sender descriptor list> <sender descriptor list>
<sender descriptor list> ::= <sender descriptor>| <sender descriptor list> ::= <sender descriptor>|
<sender descriptor list> <sender descriptor> <sender descriptor list> <sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
The anchor node creates 2 Path messages traveling in opposite The anchor node creates 2 Path messages traveling in opposite
directions. The SESSION format MUST be as per the description in directions. The SESSION format MUST be as per the description in
Section 3.1. The anchor node which creates the LSP will insert it's Section 3.1. The anchor node which creates the LSP will insert it's
own address in the "Ring node anchor address" field of the SESSION own address in the "Ring anchor node address" field of the SESSION
object. So effectively, the Path messages are addressed to the object. So effectively, the Path messages are addressed to the
originating node itself. originating node itself.
The SESSION flags of these 2 Path messages are different. The Path The SESSION flags of these 2 Path messages are different. The Path
message sent to the CW neighbor MUST have the CW flag set in the message sent to the CW neighbor MUST have the CW flag set in the
SESSION object to signal the LSP going in the clockwise direction. SESSION object to signal the LSP going in the clockwise direction.
The Path message sent to the AC neighbor MUST have the AC flag set to The Path message sent to the AC neighbor MUST have the AC flag set to
signal the LSP in the anti-clockwise direction. The details for signal the LSP in the anti-clockwise direction.
signaling over express links will be given in a future version.
When an incoming Path message is received at the ring node R_i, it When an incoming Path message is received at the ring node Ri, it
consults the results of auto-discovery to find the appropriate ring consults the results of auto-discovery to find the appropriate ring
neighbor. If the incoming Path message has CW direction flag set, neighbor. If the incoming Path message has CW direction flag set,
then R_i sends a Path message to its CW ring neighbor (and vice then Ri includes its own SENDER_DESCRIPTOR in the path message and
versa) after including its own SENDER_DESCRIPTOR in the path message. forwards the Path message to its CW ring neighbor(Ri+1). Similarly
Thus, there is no need of ERO in the Path message. The Path message if the incoming Path message has AC direction flag set, then Ri
is routed locally at each ring based on the ring auto-discovery includes its own SENDER_TEMPPLATE and forwards that Path message to
calculations. it's AC ring neighbor(Ri-1). Thus, there is no need of ERO in the
Path message. The Path message is routed locally at each ring based
on the ring auto-discovery calculations.
The RESV message for ring LSPs also uses the new RING_IPv4 SESSION The RESV message for ring LSPs also uses the new RING_IPv4 SESSION
object. When the Path message originated from the anchor node R_i object. When the Path message originated from the anchor node Ri
reaches back to R_i, R_i generates a Resv message. Note that this reaches back to Ri, Ri generates a Resv message. Note that this
means that anchor node is both Ingress and Egress for the Path means that anchor node is both Ingress and Egress for the Path
message. The Resv message copies the same ring flags as received in message. The Resv message copies the same ring flags as received in
the corresponding Path message. So, a Resv message for a CW LSP goes the corresponding Path message. So, a Resv message for a CW LSP goes
in the AC direction (unlike the Path message, which goes CW). This in the AC direction (unlike the Path message, which goes CW). This
is done to correctly match Path and corresponding Resv messages at is done to correctly match Path and corresponding Resv messages at
transit ring nodes. Upon receiving Resv message with CW flag set, transit ring nodes. Upon receiving Resv message with CW flag set,
the ring node will forward the Resv message to its AC neighbor. the ring node will forward the Resv message to its AC neighbor.
Each ring node R_i allocates CW and AC labels for each ring LSP RL_k. Each ring node Ri allocates CW and AC labels for each ring LSP RLx(x
As the signaling propagates around the ring, CW and AC labels are between i..n). As the signaling propagates around the ring, CW and
exchanged. When R_i receives CW and AC labels for RL_k from its ring AC labels are exchanged. When Ri receives CW and AC labels for LSP
neighbors, primary and fast reroute (FRR) paths for RL_k are RLx from its ring neighbors, primary and fast reroute (FRR) paths for
installed at R_i. RLx are installed at Ri.
Consider the following three nodes of the ring, and their signaling Consider the following three nodes of the ring, and their signaling
interactions for LSP RL_5 originating from anchor node R5: interactions for LSP RL5 originating from anchor node R5:
P5_CW -> P5_CW -> P5_CW -> P5_CW ->
Q5_CW <- Q5_CW <- Q5_CW <- Q5_CW <-
... ------ R7 --------- R8 --------- R9 ------ ... ... ------ R7 --------- R8 --------- R9 ------ ...
P5_AC <- P5_AC <- P5_AC <- P5_AC <-
Q5_AC -> Q5_AC -> Q5_AC -> Q5_AC ->
P corresponds to the Path message and Q corresponds to the Resv P corresponds to the Path message and Q corresponds to the Resv
message. message.
skipping to change at page 7, line 36 skipping to change at page 7, line 47
TE. There are some benefits to this: TE. There are some benefits to this:
Having a ring LSP form a loop allows the anchor node R1 to ping Having a ring LSP form a loop allows the anchor node R1 to ping
itself and thus verify the end-to-end operation of the LSP. This, in itself and thus verify the end-to-end operation of the LSP. This, in
conjunction with link-level OAM, offers a good indication of the conjunction with link-level OAM, offers a good indication of the
operational state of the LSP. Also, having R1 to be the ingress operational state of the LSP. Also, having R1 to be the ingress
means that R1 can initiate the Path messages for the two ring LSPs. means that R1 can initiate the Path messages for the two ring LSPs.
This avoids R1 having to coordinate with its neighbors to signal the This avoids R1 having to coordinate with its neighbors to signal the
LSPs, and simplifies the case where a ring update changes R1's ring LSPs, and simplifies the case where a ring update changes R1's ring
neighbors. The cost of this is a little more signaling and a couple neighbors. The cost of this is a little more signaling and a couple
more label entries in the LFIB. However, we will let implementation more label entries in the LFIB. However, we will let experiences
guide us to the wisdom of this approach. from implementation guide us when we evaluate this approach.
4.2.1. Path Propagation for RMR 4.2.1. Path Propagation for RMR
Ring LSPs are MP2P in nature. It means that every non-egress node is Ring LSPs are MP2P in nature. It means that every non-egress node is
also an ingress and a merge-point for the LSP. Focussing on ring- also an ingress and a merge-point for the LSP. Focussing on ring-
LSP-0 (i.e ring-LSPs starting at R0): LSP-0 (i.e ring-LSPs starting at R0):
R0---->R1---->R2---->R3---->R4---->R5---->R6--->R7--->R0(CW LSP) R0---->R1---->R2---->R3---->R4---->R5---->R6--->R7--->R0(CW LSP)
R0---->R7---->R6---->R5---->R4---->R3---->R2--->R1--->R0(ACW LSP) R0---->R7---->R6---->R5---->R4---->R3---->R2--->R1--->R0(ACW LSP)
skipping to change at page 11, line 5 skipping to change at page 11, line 25
the same way as the original Path message. Each ring neighbor SHOULD the same way as the original Path message. Each ring neighbor SHOULD
forward the Path message to it's appropriate neighbor based on the forward the Path message to it's appropriate neighbor based on the
new auto-discovery calculations. new auto-discovery calculations.
For the ring links which are common between the old and new LSPs, the For the ring links which are common between the old and new LSPs, the
LSPs will share resources(SE style reservation) on those ring links. LSPs will share resources(SE style reservation) on those ring links.
Note that here we are using Ring Instance ID in the SESSION object to Note that here we are using Ring Instance ID in the SESSION object to
share resources instead of the LSP_ID in the SENDER_TEMPLATE share resources instead of the LSP_ID in the SENDER_TEMPLATE
Object(which is used in RSVP-TE for sharing resources as described in Object(which is used in RSVP-TE for sharing resources as described in
RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different
functionality as described in section Section 4.5. functionality as described in section Section 4.6.
4.5. Bandwidth management 4.5. Express Links
The details for signaling over express links will be given in a
future version.
4.6. Bandwidth management
For RSVP-TE LSPs, bandwidths may be signaled in both directions. For RSVP-TE LSPs, bandwidths may be signaled in both directions.
However, these are not provisioned either; rather, one does "reverse However, these are not provisioned either; rather, one does "reverse
call admission control". When a service needs to use an LSP, the call admission control". When a service needs to use an LSP, the
ring node where the traffic enters the ring attempts to increase the ring node where the traffic enters the ring attempts to increase the
bandwidth on the LSP to the egress. If successful, the service is bandwidth on the LSP to the egress. If successful, the service is
admitted to the ring. admitted to the ring.
. R0 . . . R1 . R0 . . . R1
. __________|| . . __________|| .
skipping to change at page 14, line 10 skipping to change at page 14, line 37
[I-D.ietf-mpls-rmr] [I-D.ietf-mpls-rmr]
Kompella, K. and L. Contreras, "Resilient MPLS Rings", Kompella, K. and L. Contreras, "Resilient MPLS Rings",
draft-ietf-mpls-rmr-07 (work in progress), March 2018. draft-ietf-mpls-rmr-07 (work in progress), March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
8.2. Informative References 8.2. Informative References
[I-D.dai-mpls-rsvp-te-mbb-label-reuse] [I-D.dai-mpls-rsvp-te-mbb-label-reuse]
Dai, M. and M. Chaudhry, "MPLS RSVP-TE MBB Label Reuse", Dai, M. and M. Chaudhry, "MPLS RSVP-TE MBB Label Reuse",
draft-dai-mpls-rsvp-te-mbb-label-reuse-01 (work in draft-dai-mpls-rsvp-te-mbb-label-reuse-01 (work in
progress), September 2015. progress), September 2015.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
 End of changes. 30 change blocks. 
66 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/