draft-ietf-mpls-rmr-09.txt   draft-ietf-mpls-rmr-10.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: July 15, 2019 Telefonica Expires: November 22, 2019 Telefonica
January 11, 2019 May 21, 2019
Resilient MPLS Rings Resilient MPLS Rings
draft-ietf-mpls-rmr-09 draft-ietf-mpls-rmr-10
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 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 July 15, 2019. This Internet-Draft will expire on November 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Ring Nodes . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6 3.3. Ring Links and Directions . . . . . . . . . . . . . . . . 6
3.3.1. Express Links . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Express Links . . . . . . . . . . . . . . . . . . . . 6
3.4. Ring LSPs . . . . . . . . . . . . . . . . . . . . . . . . 7 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. Protection . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 9
4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10
4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 12
5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12
6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 12 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 12 7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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-negative number. When the RID identifies a
unique in some scope of a Service Provider's network. A node may ring, it must be positive and unique in some scope of a Service
belong to multiple rings. Provider's network. An RID of zero, when assigned to a node,
indicates that the node must behave in "promiscuous mode" (see
Section 3.2). A node may belong to 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 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).
Ring links: Links that connnect ring neighbors. Ring links: Links that connect ring neighbors.
Express links: Links that connnect non-neighboring ring nodes. Express links: Links that connect non-neighboring ring nodes.
Ring direction: A two-bit field in the IGP indicating the direction Ring direction: A two-bit field in the IGP indicating the direction
of a link. The choices are: of a link. The choices are:
UN: 00 undefined link UN: 00 undefined link
CW: 01 clockwise ring link CW: 01 clockwise ring link
AC: 10 anticlockwise ring link AC: 10 anticlockwise ring link
skipping to change at page 5, line 5 skipping to change at page 5, line 7
R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW
neighbor R_(k+1). neighbor R_(k+1).
RL_k: A (unicast) Ring LSP anchored on node R_k. RL_k: A (unicast) Ring LSP anchored on node R_k.
CL_jk: A label allocated by R_j for RL_k in the CW direction. CL_jk: A label allocated by R_j for RL_k in the CW direction.
AL_jk: A label allocated by R_j for RL_k in the AC direction. AL_jk: A label allocated by R_j for RL_k in the AC direction.
P_jk (Q_jk): A Path (Resv) message sent by R_j for RL_k.
2. Motivation 2. Motivation
A ring is the simplest topology that offers resilience. This is A ring is the simplest topology that offers resilience. This is
perhaps the main reason to lay out fiber in a ring. Thus, effective perhaps the main reason to lay out fiber in a ring. Thus, effective
mechanisms for fast failover on rings are needed. Furthermore, there mechanisms for fast failover on rings are needed. Furthermore, there
are large numbers of rings. Thus, configuration of rings needs to be are large numbers of rings. Thus, configuration of rings needs to be
as simple as possible. Finally, bandwidth management on access rings as simple as possible. Finally, bandwidth management on access rings
is very important, as bandwidth is generally quite constrained here. is very important, as bandwidth is generally quite constrained here.
The goals of this document are to present mechanisms for improved The goals of this document are to present mechanisms for improved
skipping to change at page 5, line 39 skipping to change at page 5, line 39
knows its CW and AC ring neighbors and its ring links, and all knows its CW and AC ring neighbors and its ring links, and all
express links have been identified, ring identification is complete. express links have been identified, ring identification is complete.
Once ring identification is complete, each node signals one or more Once ring identification is complete, each node signals one or more
ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter- ring LSPs RL_i. RL_i, anchored on node R_i, consists of two counter-
rotating unicast LSPs that start and end at R_i. A ring LSP is rotating unicast LSPs that start and end at R_i. A ring LSP is
"multipoint": any node R_j can use RL_i to send traffic to R_i; this "multipoint": any node R_j can use RL_i to send traffic to R_i; this
can be in either the CW or AC directions, or both (i.e., load can be in either the CW or AC directions, or both (i.e., load
balanced). Both of these counter-rotating LSPs are "active"; the balanced). Both of these counter-rotating LSPs are "active"; the
choice of direction to send traffic to R_i is determined by policy at choice of direction to send traffic to R_i is determined by policy at
the node where traffic is injected into the ring. The default is to the node where traffic is injected into the ring. The default policy
send traffic along the shortest path. Bidirectional connectivity is to send traffic along the shortest path. Bidirectional
between nodes R_i and R_j is achieved by using two different ring connectivity between nodes R_i and R_j is achieved by using two
LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to reach R_i. different ring LSPs: R_i uses RL_j to reach R_j, and R_j uses RL_i to
reach R_i.
3.1. Provisioning 3.1. Provisioning
The goal here is to provision rings with the absolute minimum The goal here is to provision rings with the absolute minimum
configuration. The exposition below aims to achieve that using auto- configuration. The exposition below aims to achieve that using auto-
discovery via a link-state IGP (see Section 4). Of course, auto- discovery via a link-state IGP (see Section 4). Of course, auto-
discovery can be overriden by configuration. For example, a link discovery can be overriden by configuration. For example, a link
that would otherwise be classified by auto-discovery as a ring link that would otherwise be classified by auto-discovery as a ring link
might be configured not to be used for ring LSPs. might be configured not to be used for ring LSPs.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
provisioned; everything else is auto-discovered. provisioned; everything else is auto-discovered.
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 it supports. This can be LDP and/or RSVP-TE. Ideally, protocols it supports. This can be LDP and/or RSVP-TE. Ideally,
each node should support both. each node should support both.
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 "auto-bundled" attribute means that parallel links between ring
considered as a single link, without the need for explicit neighbors are considered as a single link, without the need for
configuration for bundling (such as a Link Aggregation Group). Note explicit configuration for bundling (such as a Link Aggregation
that each component may be advertised separately in the IGP; however, Group). Note that each component may be advertised separately in the
signaling messages and labels across one component link apply to all IGP; however, signaling messages and labels across one component link
components. Parallel links between a pair of ring nodes is often the apply to all components. Parallel links between a pair of ring nodes
result of having multiple lambdas or fibers between those nodes. RMR is often the result of having multiple lambdas or fibers between
is primarily intended for operation at the packet layer; however, those nodes. RMR is primarily intended for operation at the packet
parallel links at the lambda or fiber layer result in parallel links layer; however, parallel links at the lambda or fiber layer result in
at the packet layer. 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. Express Links 3.3.1. Express Links
Express links are discovered once ring nodes, ring links and Express links are discovered once ring nodes, ring links and
directions have been established. As defined earlier, express links directions have been established. As defined earlier, express links
are links joining non-neighboring ring nodes; often, this may be the are links joining non-neighboring ring nodes; often, this may be the
result of optically bypassing ring nodes. The use of express links result of optically bypassing ring nodes.
will be described in a future version of this document.
3.4. Ring LSPs 3.4. Ring LSPs
Ring LSPs are not provisioned. Once a ring node R_i knows its RID, Ring LSPs are not provisioned. Once a ring node R_i knows its RID,
its ring links and directions, it kicks off ring LSP signaling its ring links and directions, it kicks off ring LSP signaling
automatically. R_i allocates CW and AC labels for each ring LSP automatically. R_i allocates CW and AC labels for each ring LSP
RL_k. R_i also initiates the creation of RL_i. As the signaling RL_k. R_i also initiates the creation of RL_i. As the signaling
propagates around the ring, CW and AC labels are exchanged. When R_i propagates around the ring, CW and AC labels are exchanged. When R_i
receives CW and AC labels for RL_k from its ring neighbors, primary receives CW and AC labels for RL_k from its ring neighbors, primary
and fast reroute (FRR) paths for RL_k are installed at R_i. More and fast reroute (FRR) paths for RL_k are installed at R_i. More
skipping to change at page 7, line 42 skipping to change at page 7, line 40
LSR for RL_k. R_j also installs an LFIB entry to push CL_j+1,k with LSR for RL_k. R_j also installs an LFIB entry to push CL_j+1,k with
next hop R_j+1 to act as ingress for RL_k. Similarly, in the AC next hop R_j+1 to act as ingress for RL_k. Similarly, in the AC
direction, R_j swaps incoming label AL_jk with AL_j-1,k with next hop direction, R_j swaps incoming label AL_jk with AL_j-1,k with next hop
R_j-1 (as LSR), and an entry to push AL_j-1,k with next hop R_j-1 (as R_j-1 (as LSR), and an entry to push AL_j-1,k with next hop R_j-1 (as
ingress). ingress).
Clearly, R_k does not act as ingress for its own LSPs. However, R_k Clearly, R_k does not act as ingress for its own LSPs. However, R_k
can send OAM messages, for example, an MPLS ping or traceroute can send OAM messages, for example, an MPLS ping or traceroute
([I-D.ietf-mpls-rfc4379bis]), using labels CL_k,k+1 and AL_k-1,k, to ([I-D.ietf-mpls-rfc4379bis]), using labels CL_k,k+1 and AL_k-1,k, to
test the entire ring LSP anchored at R_k in both directions. test the entire ring LSP anchored at R_k in both directions.
Furthermore, if these LSPs use UHP, then R_k installs LFIB entries to Furthermore, if these LSPs use Ultimate Hop Popping, then R_k
pop CL_k,k for packets received from R_k-1 and to pop AL_k,k for installs LFIB entries to pop CL_k,k for packets received from R_k-1
packets received from R_k+1. and to pop AL_k,k for packets received from R_k+1.
3.6. Installing FRR LFIB Entries
At the same time that R_j sets up its primary CW and AC LFIB entries,
it can also set up the protection forwarding entries for RL_k. In
the CW direction, R_j sets up an FRR LFIB entry to swap incoming
label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction,
R_j sets up an FRR LFIB entry to swap incoming label AL_jk with
CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB
entries in this manner.
3.7. Protection 3.6. Protection
In this scheme, there are no protection LSPs as such -- no node or In this scheme, there are no protection LSPs as such -- no node or
link bypass LSPs, no standby LSPs, no detours, and no LFA-type link bypass LSPs, no standby LSPs, no detours, and no LFA-type
protection. Protection is via the "other" direction around the ring, protection. Protection is via the "other" direction around the ring,
which is why ring LSPs are in counter-rotating pairs. Protection which is why ring LSPs are in counter-rotating pairs. Protection
works in the same way for link, node and ring LSP failures. works in the same way for link, node and ring LSP failures.
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
skipping to change at page 9, line 13 skipping to change at page 9, line 5
egress. egress.
3. A ring node sends protected traffic with a special purpose label 3. A ring node sends protected traffic with a special purpose label
below the ring LSP label. A protecting node first checks for the below the ring LSP label. A protecting node first checks for the
presence of this label; if present, it means that the traffic is presence of this label; if present, it means that the traffic is
looping and MUST be dropped. looping and MUST be dropped.
It is recommended that (2) be implemented. The other methods are It is recommended that (2) be implemented. The other methods are
optional. optional.
3.7. Installing FRR LFIB Entries
At the same time that R_j sets up its primary CW and AC LFIB entries,
it can also set up the protection forwarding entries for RL_k. In
the CW direction, R_j sets up an FRR LFIB entry to swap incoming
label CL_jk with AL_j-1,k with next hop R_j-1. In the AC direction,
R_j sets up an FRR LFIB entry to swap incoming label AL_jk with
CL_j+1,k with next hop R_j+1. Again, R_k does not install FRR LFIB
entries in this manner.
4. Autodiscovery 4. Autodiscovery
4.1. Overview 4.1. Overview
Auto-discovery proceeds in three phases. The first phase is the Auto-discovery proceeds in three phases. The first phase is the
announcement phase. The second phase is the mastership phase. The announcement phase. The second phase is the mastership phase. The
third phase is the ring identification phase. third phase is the ring identification phase.
S1 S1
/ \ / \
skipping to change at page 10, line 13 skipping to change at page 10, line 17
Ring Neighbor Sub-TLV Format Ring Neighbor Sub-TLV Format
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MV | SS | SO | MBZ |SU |M| |MV | SS | SO | MBZ |SU |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MV: Mastership Value MV: Mastership Value
SS: Supported Signaling Protocols SS: Supported Signaling Protocols
(100 = RSVP-TE; 010 = LDP; 001 = SPRING) (100 = RSVP-TE; 010 = LDP; 001 = SPRING)
MBZ: Must be zero
SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM) SO: Supported OAM Protocols (100 = BFD; 010 = CFM; 001 = EFM)
SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE) SU: Signaling Protocol to Use (00 = none; 01 = LDP; 10 = RSVP-TE)
M : Elected Master (0 = no, 1 = yes) M : Elected Master (0 = no, 1 = yes)
Flags for a Ring Node TLV Flags for a Ring Node TLV
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RD |OAM| MBZ | |RD |OAM| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RD: Ring Direction RD: Ring Direction
OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM) OAM: OAM Protocol to use (00 = none; 01 = BFD; 10 = CFM; 11 = EFM)
MBZ: Must be zero
Flags for a Ring Neighbor TLV Flags for a Ring Neighbor TLV
4.2. Ring Announcement Phase 4.2. Ring Announcement Phase
Each node participating in an MPLS ring is assigned an RID; in the Each node participating in an MPLS ring is assigned an RID; in the
example, RID = 17. A node is also provisioned with a mastership example, RID = 17. A node is also provisioned with a mastership
value. Each node advertises a ring node TLV for each ring it is value. Each node advertises a ring node TLV for each ring it is
participating in, along with the associated flags. It then starts participating in, along with the associated flags. It then starts
timer T1. timer T1; this timer is to allow each node time to hear from all
other nodes in the ring.
A node in promiscuous mode doesn't advertise any ring node TLVs. A node in promiscuous mode doesn't advertise any ring node TLVs.
However, when it hears a ring node TLV from an IGP neighbor, it joins However, when it hears a ring node TLV from an IGP neighbor, it joins
that ring, and sends its own ring node TLV with that RID. that ring, and sends its own ring node TLV with that RID.
The announcement phase allows a ring node to discover other ring The announcement phase allows a ring node to discover other ring
nodes in the same ring so that a ring master can be elected. nodes in the same ring so that a ring master can be elected.
4.3. Mastership Phase 4.3. Mastership Phase
When timer T1 fires, a node enters the mastership phase. In this When timer T1 fires, a node enters the mastership phase. In this
phase, each ring node N starts timer T2 and checks if it is master. phase, each ring node N starts timer T2 and checks if it is master.
If it is the node with the lowest loopback address of all nodes with If it is the node with the lowest loopback address of all nodes with
the highest mastership values, N declares itself master by the highest mastership values, N declares itself master by
readvertising its ring node TLV with the M bit set. readvertising its ring node TLV with the M bit set.
When timer T2 fires, each node examines the ring node TLVs from all When timer T2 fires, each node examines the ring node TLVs from all
other nodes in the ring to identify the ring master. There should be other nodes in the ring to identify the ring master. There should be
exaclty one; if not, each node restarts timer T2 and tries again. exactly one; if not, each node restarts timer T2 and tries again.
The nodes that set their M bit should be extra careful in advertising
their M bit in subsequent tries. Barring software bugs or malicious code, the principal reason for
multiple nodes for setting their M bit is late-arriving ring
announcements. Say nodes N1 and N2 have the highest mastership
values, and N1 has the lowest loopback address, while N2 has the
second lowest loopback address. If N1 makes its ring announcement
just as N2's T1 timer fires, both N1 and N2 will think they are the
master (since N2 will not have heard N1's announcment in time).
However, in the next round, N2 will realize that N1 is indeed the
master. In the worst case, the mastership phase will occur as many
times as there are nodes in the ring.
4.4. Ring Identification Phase 4.4. Ring Identification Phase
When there is exactly one ring master M, M enters the Ring When there is exactly one ring master M, M enters the Ring
Identification Phase. M indicates that it has successfully completed Identification Phase. M indicates that it has successfully completed
this phase by advertising ring link TLVs. This is the trigger for this phase by advertising ring link TLVs. This is the trigger for
M's CW neighbor to enter the Ring Identification Phase. This phase M's CW neighbor to enter the Ring Identification Phase. This phase
passes CW until all ring nodes have completed ring identification. passes CW until all ring nodes have completed ring identification.
In the Ring Identification Phase, a node X that has two or more IGP In the Ring Identification Phase, a node X that has two or more IGP
skipping to change at page 12, line 4 skipping to change at page 12, line 24
ring node deletion. ring node deletion.
The main goal of handling ring changes is (as much as possible) not 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 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 changed, all of the above changes should be local to the point of
change. Link adds just update the IGP; signaling should take change. Link adds just update the IGP; signaling should take
advantage of the new capacity as soon as it learns. Link deletions 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 in the case of parallel links also show up as a change in capacity
(until the last link in the bundle is removed.) (until the last link in the bundle is removed.)
The removal of the last ring link between two nodes, or the removal 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 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 simple ring, the result is a broken ring. However, if a ring has
express links, then it may be able to converge to a smaller ring with express links, then it may be able to converge to a smaller ring with
protection. Details of this process will be given in a future protection.
version.
The addition of a new ring node can also be handled incrementally. 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 protocol-independent The ring LSP signaling procedures will be described in separate
details about ring LSP signaling. documents describing signaling solution options.
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 link. This should be an OAM protocol that level OAM over each ring link. This should be an OAM protocol that
both neighbors agree on. The default hello time is 3.3 millisecond. both neighbors agree on. The default hello time is 3.3 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
ring LSP. This is a multi-hop OAM to check LSP liveness; typically, ring LSP. This is a multi-hop OAM to check LSP liveness; typically,
skipping to change at page 13, line 18 skipping to change at page 13, line 40
If H1 fails, traffic from X to Z will drop until the T-LDP session If H1 fails, traffic from X to Z will drop until the T-LDP session
from H1 to Z fails, the IGP reconverges, and H2's label to Z is from H1 to Z fails, the IGP reconverges, and H2's label to Z is
chosen. Thereafter, traffic will go from X to H2 via a ring LSP, chosen. Thereafter, traffic will go from X to H2 via a ring LSP,
then to Z via LDP. However, this convergence could take a long time. then to Z via LDP. However, this convergence could take a long time.
Since this is a very common and important situation, it is again a Since this is a very common and important situation, it is again a
useful problem to solve. However, this topic too will not be useful problem to solve. However, this topic too will not be
addressed in this document; that task is left for a future document. addressed in this document; that task is left for a future document.
8. Security Considerations 8. Security Considerations
It is not anticipated that either the notion of MPLS rings or the This document presents a new method of using MPLS in rings. The use
extensions to various protocols to support them will cause new of MPLS in rings is not new, so this per se does not pose security
security loopholes. As this document is updated, this section will concerns. The question is, rather, whether the extensions to
also be updated. protocols suggested here do so. IS-IS and OSPF have security
mechanisms that ensure secure exchange of information, as do RSVP-TE
and LDP. The extensions proposed here are protected by the same
mechanisms.
One can also ask whether the semantic content of these extensions can
be used to compromise a network or initiate a denial-of-service
attack. To do so would require either compromising the control plane
processing these requests, or manipulating the content of the
messages. The former is outside the scope of this document; the
latter is addressed by the security mechanisms of the underlying
protocols.
9. Acknowledgments 9. Acknowledgments
Many thanks to Pierre Bichon whose exemplar of self-organizing Many thanks to Pierre Bichon whose exemplar of self-organizing
networks and whose urging for ever simpler provisioning led to the networks and whose urging for ever simpler provisioning led to the
notion of promiscuous nodes. notion of promiscuous nodes.
10. IANA Considerations 10. IANA Considerations
There are no requests as yet to IANA for this document. There are no requests as yet to IANA for this document.
 End of changes. 28 change blocks. 
68 lines changed or deleted 90 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/