draft-kompella-mpls-rmr-01.txt   draft-kompella-mpls-rmr-02.txt 
MPLS WG K. Kompella MPLS WG K. Kompella
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track L. Contreras Intended status: Standards Track L. Contreras
Expires: September 9, 2015 Telefonica I+D Expires: March 11, 2016 Telefonica I+D
March 8, 2015 September 8, 2015
Resilient MPLS Rings Resilient MPLS Rings
draft-kompella-mpls-rmr-01 draft-kompella-mpls-rmr-02
Abstract Abstract
This document describes the use of the MPLS control and data planes This document describes the use of the MPLS control and data planes
on ring topologies. It describes the special nature of rings, and on ring topologies. It describes the special nature of rings, and
proceeds to show how MPLS can be effectively used in such topologies. proceeds to show how MPLS can be effectively used in such topologies.
It describes how MPLS rings are configured, auto-discovered and It describes how MPLS rings are configured, auto-discovered and
signaled, as well as how the data plane works. Companion documents signaled, as well as how the data plane works. Companion documents
describe the details of discovery and signaling for specific describe the details of discovery and signaling for specific
protocols. protocols.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 9, 2015. This Internet-Draft will expire on March 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6 3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6
3.3.1. Bypass Links . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Bypass Links . . . . . . . . . . . . . . . . . . . . 6
3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Installing Primary LFIB Entries . . . . . . . . . . . . . 7 3.5. Installing Primary LFIB Entries . . . . . . . . . . . . . 7
3.6. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 7 3.6. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 7
3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 8
4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10
4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 11 4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 11
4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11 4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11
4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 11
5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 11 5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12
6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Rings are a very common topology in transport networks. A ring is Rings are a very common topology in transport networks. A ring is
the simplest topology offering link and node resilience. Rings are the simplest topology offering link and node resilience. Rings are
nearly ubiquitous in access and aggregation networks. As MPLS nearly ubiquitous in access and aggregation networks. As MPLS
increases its presence in such networks, and takes on a greater role increases its presence in such networks, and takes on a greater role
in transport, it is imperative that MPLS handles rings well; this is in transport, it is imperative that MPLS handles rings well; this is
not the case today. not the case today.
This document describes the special nature of rings, and the special This document describes the special nature of rings, and the special
needs of MPLS on rings. It then shows how these needs can be met in needs of MPLS on rings. It then shows how these needs can be met in
several ways, some of which involve extensions to protocols such as several ways, some of which involve extensions to protocols such as
IS-IS [RFC5305], OSPF[RFC3630], RSVP-TE [RFC3209] and LDP [RFC5036]. IS-IS [RFC5305], OSPF[RFC3630], RSVP-TE [RFC3209] and LDP [RFC5036].
The intent of this document is to handle rings that "occur
naturally". Many access and aggregation networks in metros have
their start as a simple ring. They may then grow into more complex
topologies, for example, by adding parallel links to the ring, or by
adding "bypass" links. The goal here is to discover these rings
(with some guidance), and run MPLS over them efficiently. The intent
is not to construct rings in a mesh network, and use those for
protection.
1.1. Definitions 1.1. Definitions
A (directed) graph G = (V, E) consists of a set of vertices (or A (directed) graph G = (V, E) consists of a set of vertices (or
nodes) V and a set of edges (or links) E. An edge is an ordered pair nodes) V and a set of edges (or links) E. An edge is an ordered pair
of nodes (a, b), where a and b are in V. (In this document, the of nodes (a, b), where a and b are in V. (In this document, the
terms node and link will be used instead of vertex and edge.) terms node and link will be used instead of vertex and edge.)
A ring is a subgraph of G. A ring consists of a subset of n nodes A ring is a subgraph of G. A ring consists of a subset of n nodes
{R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, {R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1,
R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic
skipping to change at page 3, line 40 skipping to change at page 3, line 49
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. An RID of 0 unique in some scope of a Service Provider's network. A node may
means the node is a "promiscuous" node. belong to multiple rings.
Ring node: A member of a ring. Note that a device may belong to
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 upto
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 master: The ring master initiates the ring identification Ring master: The ring master initiates the ring identification
process. Mastership is indicated in the IGP by a two-bit field. process. Mastership is indicated in the IGP by a two-bit field.
Ring neighbors: Nodes whose indices differ by one (modulo ring Ring neighbors: Nodes whose indices differ by one (modulo ring
size). size).
skipping to change at page 6, line 19 skipping to change at page 6, line 28
3.3. Ring Links and Directions 3.3. Ring Links and Directions
Ring links must be MPLS-capable. They are by default unnumbered, Ring links must be MPLS-capable. They are by default unnumbered,
point-to-point (from the IGP point of view) and "auto-bundled". The point-to-point (from the IGP point of view) and "auto-bundled". The
last attribute means that parallel links between ring neighbors are last attribute means that parallel links between ring neighbors are
considered as a single link, without the need for explicit considered as a single link, without the need for explicit
configuration for bundling (such as a Link Aggregation Group). Note configuration for bundling (such as a Link Aggregation Group). Note
that each component may be advertised separately in the IGP; however, that each component may be advertised separately in the IGP; however,
signaling messages and labels across one component link apply to all signaling messages and labels across one component link apply to all
components. Parallel links between a pair of ring nodes is often the components. Parallel links between a pair of ring nodes is often the
result of having multiple lambdas or fibers between those nodes. result of having multiple lambdas or fibers between those nodes. RMR
is primarily intended for operation at the packet layer; however,
parallel links at the lambda or fiber layer result in parallel links
at the packet layer.
A ring link is not provisioned as belonging to the ring; it is A ring link is not provisioned as belonging to the ring; it is
discovered to belong to ring RID if both its adjacent nodes belong to discovered to belong to ring RID if both its adjacent nodes belong to
RID. A ring link's direction (CW or AC) is also discovered; this RID. A ring link's direction (CW or AC) is also discovered; this
process is initiated by the ring's ring master. Note that the above process is initiated by the ring's ring master. Note that the above
two attributes can be overridden by provisioning if needed; it is two attributes can be overridden by provisioning if needed; it is
then up to the provisioning system to maintain consistency across the then up to the provisioning system to maintain consistency across the
ring. ring.
3.3.1. Bypass Links 3.3.1. Bypass Links
skipping to change at page 8, line 7 skipping to change at page 8, line 23
If a node R_j detects a failure from R_j+1 -- either all links to If a node R_j detects a failure from R_j+1 -- either all links to
R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW
ring LSPs to the AC direction using the FRR LFIB entries. If the ring LSPs to the AC direction using the FRR LFIB entries. If the
failure is specific to a single ring LSP, R_j switches traffic just failure is specific to a single ring LSP, R_j switches traffic just
for that LSP. In either case, this switchover can be very fast, as for that LSP. In either case, this switchover can be very fast, as
the FRR LFIB entries can be preprogrammed. Fast detection and fast the FRR LFIB entries can be preprogrammed. Fast detection and fast
switchover lead to minimal traffic loss. switchover lead to minimal traffic loss.
R_j then sends an indication to R_j-1 that the CW direction is not R_j then sends an indication to R_j-1 that the CW direction is not
working, so that R_j-1 can similarly switch traffic to the AC working, so that R_j-1 can similarly switch traffic to the AC
direction. These indications propagate AC until each traffic source direction. For RSVP-TE, this indication can be a PathErr or a
on the ring AC of the failure uses the AC direction. Thus, within a Notify; other signaling protocols have similar indications. These
short period, traffic will be flowing in the optimal path, given that indications propagate AC until each traffic source on the ring AC of
there is a failure on the ring. This contrasts with (say) bypass the failure uses the AC direction. Thus, within a short period,
protection, where until the ingress recomputes a new path, traffic traffic will be flowing in the optimal path, given that there is a
will be suboptimal. failure on the ring. This contrasts with (say) bypass protection,
where until the ingress recomputes a new path, traffic will be
suboptimal.
Note that the failure of a node or a link will not necessarily affect
all ring LSPs. Thus, it is important to identify the affected LSPs
(and switch them), but to leave the rest alone.
One point to note is that when a ring node, say R_j, fails, RL_j is One point to note is that when a ring node, say R_j, fails, RL_j is
clearly unusable. However, the above protection scheme will cause a clearly unusable. However, the above protection scheme will cause a
traffic loop: R_j-1 detects a failure CW, and protects by sending CW traffic loop: R_j-1 detects a failure CW, and protects by sending CW
traffic on RL_j back all the way to R_j+1, which in turn sends traffic on RL_j back all the way to R_j+1, which in turn sends
traffic to R_j-1, etc. There are three proposals to avoid this: traffic to R_j-1, etc. There are three proposals to avoid this:
1. Each ring node acting as ingress sends traffic with a TTL of at 1. Each ring node acting as ingress sends traffic with a TTL of at
most 2*n, where n is the number of nodes in the ring. most 2*n, where n is the number of nodes in the ring.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
the ring. Based on that, X picks a CW neighbor and inserts ring link the ring. Based on that, X picks a CW neighbor and inserts ring link
TLVs with ring direction CW for each link to its CW neighbor; X also TLVs with ring direction CW for each link to its CW neighbor; X also
inserts a ring link TLV with direction AC for each link to its AC inserts a ring link TLV with direction AC for each link to its AC
neighbor. Then, X determines its bypass links. These are links neighbor. Then, X determines its bypass links. These are links
connected to ring nodes that are not ring neighbors. X advertises connected to ring nodes that are not ring neighbors. X advertises
ring link TLVs for bypass links by setting the link direction to ring link TLVs for bypass links by setting the link direction to
"bypass link". "bypass link".
4.5. Ring Changes 4.5. Ring Changes
A future version of this document will specify how ring changes are The main changes to a ring are:
detected and handled.
ring link addition;
ring link deletion;
ring node addition; and
ring node deletion.
The main goal of handling ring changes is (as much as possible) not
to perturb existing ring operation. Thus, if the ring master hasn't
changed, all of the above changes should be local to the point of
change. Link adds just update the IGP; signaling should take
advantage of the new capacity as soon as it learns. Link deletions
in the case of parallel links also show up as a change in capacity
(until the last link in the bundle is removed.)
The removal of the last ring link between two nodes, or the removal
of a ring node is an event that triggers protection switching. In a
simple ring, the result is a broken ring. However, if a ring has
bypass links, then it may be able to converge to a smaller ring with
protection. Details of this process will be given in a future
version.
The addition of a new ring node can also be handled incrementally.
Again, the details of this process will be given in a futre version.
5. Ring Signaling 5. Ring Signaling
A future version of this document will specify details about ring LSP A future version of this document will specify protocol-independent
signaling. details about ring LSP signaling.
6. Ring OAM 6. Ring OAM
Each ring node should advertise in its ring node TLV the OAM Each ring node should advertise in its ring node TLV the OAM
protocols it supports. Each ring node is expected to run a link- protocols it supports. Each ring node is expected to run a link-
level OAM over each ring and bypass link. This should be an OAM level OAM over each ring and bypass link. This should be an OAM
protocol that both neighbors agree on. The default hello time is 3.3 protocol that both neighbors agree on. The default hello time is 3.3
millisecond. millisecond.
Each ring node also sends OAM messages over each direction of its Each ring node also sends OAM messages over each direction of its
skipping to change at page 12, line 40 skipping to change at page 13, line 14
9. IANA Considerations 9. IANA Considerations
There are no requests as yet to IANA for this document. There are no requests as yet to IANA for this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 10.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630,
2003. DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Specification", RFC 5036, October 2007. "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
Authors' Addresses Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
 End of changes. 18 change blocks. 
33 lines changed or deleted 85 lines changed or added

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