: a Label Mapping
message with a FEC TLV with a single RMR FEC Element

or

and Label TLV with label L. Label L MUST be allocated
from the per-platform label space of the LSR sending the Label
Mapping message. The use of the interface label space is outside
the scope of this document.
3. RMR Label Withdraw

or

: a Label Withdraw
message with a FEC TLV with a single RMR FEC Element

or

and Label TLV with label L.
4. RMR LSP

or

: A RMR LSP with egress prefix P,
Ring ID R and clockwise direction C or anti-clockwise direction A.
4.2.2 Preliminary
A node X wishing to participate in LDP RMR signaling MUST negotiate
the RMR capability with all its neighbors. When the IGP informs X of
its RMR neighbors A and C for RID R, it MUST check that A and C have
also negotiated the RMR capability with X. If these conditions are
not satisfied, X cannot participate in signaling for ring R. This
applies for all roles that X may play: ingress, transit and egress.
4.2.3 Egress LSR
Every ring node initiates two counter-rotating LSPs that egress on
that node. After the IGP discovers the ring, LDP constructs the
clockwise RMR FEC

and sends it in a Label Mapping message
to anti-clockwise neighbor. Similarly, LDP constructs a anti-
clockwise RMR FEC

and sends it in a Label Mapping message
Esale, et al. Expires May 8, 2019 [Page 7]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
to clockwise neighbor. This SHOULD establish a clockwise and anti-
clockwise LSP - in terms of data traffic - in the clockwise and anti-
clockwise direction respectively.
Furthermore, if a label other than implicit or explicit null is
advertised for a LSP, LDP SHOULD add a pop route for this label in
the Incoming Label Map (ILM) MPLS table.
When the node is no longer part of the ring, it MUST tear down its
egress LSPs - CW and AC - by sending a label withdraw message.
4.2.4 Ingress and Transit LSR
When a transit LSR R5 depicted in figure 1 receives a label map
message with RMR FEC Element from a downstream LDP
session to R4, it SHOULD verify that R4 is indeed its anticlockwise
neighbor for ring 17. If not, it SHOULD stop decoding the FEC TLV,
abort processing the message containing the TLV, send an "Unknown
FEC" Notification message to its LDP peer R4 signaling an error and
close the session.
If the LSR encounters no other error while parsing the RMR FEC
element, it allocates a Label L2 and determines a upstream LDP
session as R6 using the algorithm described in section 'Upstream
LSR'. It also programs a MPLS ILM table with label route L2 swapped
to L1 and Ingress tunnel table with prefix R0 with label push L1 on
all the LDP interfaces to R4, and sends the RMR FEC Element to R6.
If a session to the anti-clockwise neighbor for RID 17 depicted in
Figure 2, namely R6, does not exist, the RMR FEC Element SHOULD NOT be propagated further. Similarly, when the upstream
session changes because of ring topology change, transit LSR should
send a label withdraw for RMR FEC Element to older
upstream session R6 before sending Label Mapping message with RMR FEC
Element to a new upstream session.
4.3 Equal Cost Multipath (ECMP)
A transit and ingress LSR of RMR LSP uses all the links between
itself and downstream LSR to program transit and ingress route. Thus,
ECMP works automatically for a LDP RMR LSP. A vendor could provide
exception when necessary to this behavior by disabling certain ring
links for RMR LSPs.
4.4 Protection
Esale, et al. Expires May 8, 2019 [Page 8]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
RMR uses the two counter-rotating LSPs to protect the other. Say
that R5 wants to protect the LSP to R0 for RID 17. R5 receives RMR
FEC Element from R4 and sends RMR FEC Element to R6. Then the primary path for the AC LSP is to swap L1
with L2 with next hop R4. Also, R5 receives RMR FEC Element from R6 and sends RMR FEC Element to R4. The
primary path for the CW LSP is to swap L3 with L4. The protection
path for the AC LSP is to swap L1 with L4 with next hop R6, thus
sending the traffic back where it came from, but with a different
label. The protection path for the CW LSP is to swap L3 with L2 with
next hop R4.
5. LSP Hierarchy
R9 R10 R11
. . .
. . . .
. .
R8 . . . R12
. .
. .
. .
R0 . . . R1
. .
R7 R2
Anti- | . Ring . |
Clockwise | . . | Clockwise
v . RID = 17 . v
R6 R3
. .
R5 . . . R4
Figure 3: Ring 17 with rest of the Network
Suppose R5 needs to reach R10. Only RMR LSPs are setup inside the
ring 17. Additionally, whenever services on R5 need to reach R10, R5
dynamically establishes a tLDP session to ring 17 master node R0 and
R1. Further, suppose it only learns IPv4 and IPv6 FECs only over this
session using [draft-ietf-mpls-app-aware-tldp-05]. Thus, in order to
reach R10, R5 uses top label as RMR LSP label to R0 or R1 and bottom
label as R10's FEC label received over tLDP session of R0 or R1
respectively.
6. Ring LSPs
Esale, et al. Expires May 8, 2019 [Page 9]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
An RMR LSP consists of two counter-rotating ring LSPs that start and
end at the same node, say R1. As such, this appears to cause a loop,
something that is normally to be avoided by LDP [RSVP-TE]. There are
some benefits to this. Having a ring LSP allows the anchor node R1
to ping 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 operational state of the LSP. [Also, having R1 be the ingress
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
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
more label entries in the LFIB.
Esale, et al. Expires May 8, 2019 [Page 10]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
7. Security Considerations
The Capability and RMR FEC procedures described in this document will
not introduce any change to LDP Security Considerations section
described in [RFC5036].
8. IANA Considerations
This document requires the assignment of a new code point for a
Capability Parameter TLVs from the IANA managed LDP registry "TLV
Type Name Space", corresponding to the advertisement of the RMR
capability. IANA is requested to assign the lowest available value.
Value Description Reference
----- ---------------- ---------
TBD1 RMR capability [this document]
This document requires the assignment of a new code point for a FEC
type from the IANA managed LDP registry "Forwarding Equivalence Class
(FEC) Type Name Space". IANA is requested to assign the lowest
available value.
Value Description Reference
----- ---------------- ---------
TBD1 RMR FEC type [this document]
9. Acknowledgments
TODO.
10. Contributors
Raveendra Torvi
Juniper Networks
10 Technology Park Dr
Westford, MA 01886
USA
Email: rtorvi@juniper.net
Ravi Singh
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Esale, et al. Expires May 8, 2019 [Page 11]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
Email: ravis@juniper.net
Abhishek Deshmukh
Juniper Networks
10 Technology Park Dr
Westford, MA 01886
USA
Email: adeshmukh@juniper.net
11. References
11.1 Normative References
[I-D.ietf-mpls-rmr] Kompella, K. and L. Contreras, "Resilient MPLS
Rings", draft-ietf-mpls-rmr-03 (work in progress), October
2016.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007,
.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, .
11.2 Informative References
[RFC6388] IJ. Wijnands, I. Minei, K. Kompella, B. Thomas, "Label
Distribution Protocol Extensions for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths", RFC
6388, November 2011,
[I-D.draft-deshmukh-mpls-rsvp-rmr-extension] A. Deshmukh, K.
Kompella, "RSVP Extensions for RMR", draft-deshmukh-mpls-
rsvp-rmr-extension-00 (work in progress), July 2016.
[I-D.draft-kompella-isis-ospf-rmr] K. Kompella, "IGP Extensions for
Resilient MPLS Rings", draft-kompella-isis-ospf-rmr-00
Esale, et al. Expires May 8, 2019 [Page 12]
INTERNET DRAFT LDP Extensions for RMR November 4, 2018
(work in progress), October 2016.
[I-D.draft-ietf-mpls-app-aware-tldp] Santosh Esale, Raveendra Torvi,
Luay Jalil, U. Chunduri, Kamran Raza, "Application-aware
Targeted LDP", draft-ietf-mpls-app-aware-tldp-05 (work in
progress), June 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
.
Authors' Addresses
Santosh Esale
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: sesale@juniper.net
Kireeti Kompella
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: kireeti@juniper.net
Esale, et al. Expires May 8, 2019 [Page 13]