draft-ietf-mpls-tp-shared-ring-protection-04.txt   draft-ietf-mpls-tp-shared-ring-protection-05.txt 
Network Working Group W. Cheng Network Working Group W. Cheng
Internet-Draft L. Wang Internet-Draft L. Wang
Intended status: Standards Track H. Li Intended status: Standards Track H. Li
Expires: June 16, 2017 China Mobile Expires: September 28, 2017 China Mobile
H. Helvoort H. Helvoort
Hai Gaoming BV Hai Gaoming BV
J. Dong J. Dong
Huawei Technologies Huawei Technologies
December 13, 2016 March 27, 2017
Shared-Ring protection (MSRP) mechanism for ring topology Shared-Ring protection (MSRP) mechanism for ring topology
draft-ietf-mpls-tp-shared-ring-protection-04 draft-ietf-mpls-tp-shared-ring-protection-05
Abstract Abstract
This document describes requirements, architecture and solutions for This document describes requirements, architecture and solutions for
MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point-
to-point (P2P) services. The MSRP mechanism is described to meet the to-point (P2P) services. The MSRP mechanism is described to meet the
ring protection requirements as described in RFC 5654. This document ring protection requirements as described in RFC 5654. This document
defines the Ring Protection Switch (RPS) Protocol that is used to defines the Ring Protection Switch (RPS) Protocol that is used to
coordinate the protection behavior of the nodes on MPLS ring. coordinate the protection behavior of the nodes on MPLS ring.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 June 16, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.1.2. Label Assignment and Distribution . . . . . . . . . . 7 4.1.2. Label Assignment and Distribution . . . . . . . . . . 7
4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 7 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 7
4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 8 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 8
4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 9 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12
4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17
4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17
4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 19 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 19
4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 20
4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 22
4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22
5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23
5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 23 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Transmission and Acceptance of RPS Requests . . . . . 25 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 25
5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 25 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26
5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27
5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29
5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31
5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31 5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31
5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 32 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 33
5.2.3. State transitions When Local Request is Applied . . . 33 5.2.3. State transitions When Local Request is Applied . . . 34
5.2.4. State Transitions When Remote Request is Applied . . 37 5.2.4. State Transitions When Remote Request is Applied . . 38
5.2.5. State Transitions When Request Addresses to Another 5.2.5. State Transitions When Request Addresses to Another
Node is Received . . . . . . . . . . . . . . . . . . 40 Node is Received . . . . . . . . . . . . . . . . . . 41
5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 42 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 43 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44
6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 44 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1, As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1,
Ring Protection, several service providers have expressed much Ring Protection, several service providers have expressed much
interest in operating MPLS-TP in ring topologies and require a high- interest in operating MPLS-TP in ring topologies and require a high-
level survivability function in these topologies. In operational level survivability function in these topologies. In operational
transport network deployment, MPLS-TP networks are often constructed transport network deployment, MPLS-TP networks are often constructed
using ring topologies. This calls for an efficient and optimized using ring topologies. This calls for an efficient and optimized
ring protection mechanism to achieve simple operation and fast, sub ring protection mechanism to achieve simple operation and fast, sub
skipping to change at page 4, line 8 skipping to change at page 4, line 8
MUST actively participate in the ring protection. MUST actively participate in the ring protection.
Ring tunnel: A ring tunnel provides a server layer for the LSPs Ring tunnel: A ring tunnel provides a server layer for the LSPs
traversing the ring. The notation used for a ring tunnel is: traversing the ring. The notation used for a ring tunnel is:
R<d><p><X> where <d> = c (clockwise) or a (anticlockwise), <p> = W R<d><p><X> where <d> = c (clockwise) or a (anticlockwise), <p> = W
(working) or P (protecting), and <X> = the node name. (working) or P (protecting), and <X> = the node name.
Ring map: A ring map is present in each ring-node. The ring-map Ring map: A ring map is present in each ring-node. The ring-map
contains the ring topology information, i.e. the nodes in the ring, contains the ring topology information, i.e. the nodes in the ring,
the adjacency of the ring-nodes and the status of the links between the adjacency of the ring-nodes and the status of the links between
ring-nodes (Intact or Severed) and for each protected LSP at which ring-nodes (Intact or Severed). The ring map is used by every ring
node it enters and leaves the ring. The ring map is used by every node to determine the switchover behavior of the ring tunnels.
ring node to determine the switchover behavior of the ring tunnels.
Notation: Notation:
The following syntax will be used to describe the contents of the The following syntax will be used to describe the contents of the
label stack: label stack:
1. The label stack will be enclosed in square brackets ("[]"). 1. The label stack will be enclosed in square brackets ("[]").
2. Each level in the stack will be separated by the '|' character. 2. Each level in the stack will be separated by the '|' character.
It should be noted that the label stack may contain additional It should be noted that the label stack may contain additional
skipping to change at page 5, line 28 skipping to change at page 5, line 28
ring protection in MPLS-TP networks. As shown in Figure 1, the new ring protection in MPLS-TP networks. As shown in Figure 1, the new
logical layer consists of ring tunnels which provides a server layer logical layer consists of ring tunnels which provides a server layer
for the LSPs traverse the ring. Once a ring tunnel is established, for the LSPs traverse the ring. Once a ring tunnel is established,
the forwarding and protection switching of the ring are all performed the forwarding and protection switching of the ring are all performed
at the ring tunnel level. A port can carry multiple ring tunnels, at the ring tunnel level. A port can carry multiple ring tunnels,
and a ring tunnel can carry multiple LSPs. and a ring tunnel can carry multiple LSPs.
+------------- +-------------
+-------------| +-------------|
+-------------| | +-------------| |
=====PW1======| | | ===Service1===| | |
| | Ring | Physical | | Ring | Physical
=====PW2======| LSP | Tunnel | Port ===Service2===| LSP | Tunnel | Port
| | | | | |
=====PW3======| | | ===Service3===| | |
+-------------| | +-------------| |
+-------------| +-------------|
+------------- +-------------
Figure 1. The logical layers of the ring Figure 1. The logical layers of the ring
The label stack used in MPLS-TP Shared Ring Protection mechanism is The label stack used in MPLS-TP Shared Ring Protection mechanism is
[Ring Tunnel Label|LSP Label|PW Label](Payload) as illustrated in [Ring Tunnel Label|LSP Label|service Label](Payload) as illustrated
figure 2. in figure 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring tunnel Label | | Ring tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | | LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Label | | Service Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload | | Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Label stack used in MPLS-TP Shared Ring Protection Figure 2. Label stack used in MPLS-TP Shared Ring Protection
4.1.1. Establishment of Ring Tunnel 4.1.1. Establishment of Ring Tunnel
The Ring tunnels are established based on the egress nodes. The The Ring tunnels are established based on the egress nodes. The
egress node is the node where traffic leaves the ring. LSPs which egress node is the node where traffic leaves the ring. LSPs which
have the same egress node on the ring and travels along the ring in have the same egress node on the ring and travels along the ring in
skipping to change at page 7, line 36 skipping to change at page 7, line 36
Through these working and protection ring tunnels, LSPs which enter Through these working and protection ring tunnels, LSPs which enter
the ring from any node can reach any egress nodes on the ring, and the ring from any node can reach any egress nodes on the ring, and
are protected from failures on the ring. are protected from failures on the ring.
4.1.2. Label Assignment and Distribution 4.1.2. Label Assignment and Distribution
The ring tunnel labels are downstream-assigned labels as defined in The ring tunnel labels are downstream-assigned labels as defined in
[RFC3031]. The ring tunnel labels on each hop of the ring tunnel can [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can
be either configured statically, provisioned by a controller, or be either configured statically, provisioned by a controller, or
distributed dynamically via a control protocol. distributed dynamically via a control protocol. For an LSP which
traverses the ring tunnel, the ingress ring node and the egress ring
node are considered adjacent at the LSP layer, and LSP label needs to
be allocated at these two ring nodes. The control plane for label
distribution is outside the scope of this document.
4.1.3. Forwarding Operation 4.1.3. Forwarding Operation
When an MPLS-TP transport path, such as an LSP, enters the ring, the When an MPLS-TP transport path, such as an LSP, enters the ring, the
ingress node on the ring pushes the working ring tunnel label which ingress node on the ring pushes the working ring tunnel label which
is used to reach the specific egress node and sends the traffic to is used to reach the specific egress node and sends the traffic to
the next hop. The transit nodes on the working ring tunnel swap the the next hop. The transit nodes on the working ring tunnel swap the
ring tunnel labels and forward the packets to the next hop. When the ring tunnel labels and forward the packets to the next hop. When the
packet arrives at the egress node, the egress node pops the ring packet arrives at the egress node, the egress node pops the ring
tunnel label and forwards the packets based on the inner LSP label tunnel label and forwards the packets based on the inner LSP label
and PW label. Figure 4 shows the label operation in the MPLS-TP and service label. Figure 4 shows the label operation in the MPLS-TP
shared ring protection mechanism. Assume that LSP1 enters the ring shared ring protection mechanism. Assume that LSP1 enters the ring
at Node A and exits from Node D, and the following label operations at Node A and exits from Node D, and the following label operations
are executed. are executed.
1. Ingress node: Packets of LSP1 arrive at Node A with a label stack 1. Ingress node: Packets of LSP1 arrive at Node A with a label stack
[LSP1] and are supposed to be forwarded in the clockwise [LSP1] and are supposed to be forwarded in the clockwise
direction of the ring. The clockwise working ring tunnel label direction of the ring. The label of the clockwise working ring
RcW_D will be pushed at Node A, the label stack for the forwarded tunnel RcW_D will be pushed at Node A, the label stack for the
packet at Node A is changed to [RcW_D(B)|LSP1]. forwarded packet at Node A is changed to [RcW_D(B)|LSP1].
2. Transit nodes: In this case, Node B and Node C forward the 2. Transit nodes: In this case, Node B and Node C forward the
packets by swapping the working ring tunnel labels. For example, packets by swapping the working ring tunnel labels. For example,
the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node
B. B.
3. Egress node: When the packet arrives at Node D (i.e. the egress 3. Egress node: When the packet arrives at Node D (i.e. the egress
node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and
subsequently deals with the inner labels of LSP1. subsequently deals with the inner labels of LSP1.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
1. Single-node interconnected rings 1. Single-node interconnected rings
In single-node interconnected rings, the connection between In single-node interconnected rings, the connection between
the two rings is through a single node. Because the the two rings is through a single node. Because the
interconnection node is in fact a single point of failure, interconnection node is in fact a single point of failure,
this topology should be avoided in real transport networks. this topology should be avoided in real transport networks.
Figure 11 shows the topology of single-node interconnected Figure 11 shows the topology of single-node interconnected
rings. Node C is the interconnection node between Ring1 and rings. Node C is the interconnection node between Ring1 and
Ring2. Ring2.
2. Dual-node interconnected rings Figure 11 shows the topology of single-node interconnected
rings. Node C is the interconnection node between Ring1 and
In dual-node interconnected rings, the connection between the Ring2.
two rings is through two nodes. The two interconnection nodes
belong to both interconnected rings. This topology can
recover from one interconnection node failure.
Figure 11 shows the topology of single-node interconnected rings.
Node C is the interconnection node between Ring1 and Ring2.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A |------| B |----- -----| G |------| H | | A |------| B |----- -----| G |------| H |
+---+ +---+ \ / +---+ +---+ +---+ +---+ \ / +---+ +---+
| \ / | | \ / |
| \ +---+ / | | \ +---+ / |
| Ring1 | C | Ring2 | | Ring1 | C | Ring2 |
| / +---+ \ | | / +---+ \ |
| / \ | | / \ |
+---+ +---+ / \ +---+ +---+ +---+ +---+ / \ +---+ +---+
| F |------| E |----- -----| J |------| I | | F |------| E |----- -----| J |------| I |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Figure 11. Single-node interconnected rings Figure 11. Single-node interconnected rings
Figure 12 shows the topology of dual-node interconnected rings. 2. Dual-node interconnected rings
Nodes C and Node D are the interconnection nodes between Ring1 and
Ring2. In dual-node interconnected rings, the connection between the
two rings is through two nodes. The two interconnection nodes
belong to both interconnected rings. This topology can
recover from one interconnection node failure.
Figure 12 shows the topology of dual-node interconnected
rings. Nodes C and Node D are the interconnection nodes
between Ring1 and Ring2.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A |------| B |------| C |------| G |------| H | | A |------| B |------| C |------| G |------| H |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | |
| | | | | | | |
| Ring1 | | Ring2 | | Ring1 | | Ring2 |
| | | | | | | |
| | | | | | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 20, line 11 skipping to change at page 20, line 24
o one anticlockwise protection ring tunnel to the virtual o one anticlockwise protection ring tunnel to the virtual
interconnection node group interconnection node group
o one anticlockwise working ring tunnel to the virtual o one anticlockwise working ring tunnel to the virtual
interconnection node group interconnection node group
o one clockwise protection ring tunnel to the virtual o one clockwise protection ring tunnel to the virtual
interconnection node group interconnection node group
These ring tunnels will terminated at any node in the virtual The ring tunnels to the virtual interconnection node group are shared
interconnection node group. by all LSPs that need to be forwarded to other rings. These ring
tunnels can terminate at any node in the virtual interconnection node
group.
For example, all the ring tunnels on Ring1 in Figure 13 are For example, all the ring tunnels on Ring1 in Figure 13 are
provisioned as follows: provisioned as follows:
o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A
o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B
o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C
skipping to change at page 22, line 15 skipping to change at page 22, line 29
In case of link failure, for example, when a failure occurs on the In case of link failure, for example, when a failure occurs on the
link between Node F and Node E, Node E will detect the failure and link between Node F and Node E, Node E will detect the failure and
execute protection switching as described in 4.3.2. The path that execute protection switching as described in 4.3.2. The path that
the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D-
>E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1.
In case of a non-interconnection node failure, for example, when the In case of a non-interconnection node failure, for example, when the
failure occurs at Node E in Ring1, Node D will detect the failure and failure occurs at Node E in Ring1, Node D will detect the failure and
execute protection switching as described in 4.3.2. The path that execute protection switching as described in 4.3.2. The path that
the service LSP1 follows after switching becomes: the service LSP1 follows after switching becomes:
LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. LSP1->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1.
In case of an interconnection node failure, for example, when the In case of an interconnection node failure, for example, when the
failure occurs at the interconnection Node F, Node E in Ring1 will failure occurs at the interconnection Node F, Node E in Ring1 will
detect the failure, and execute protection switching as described in detect the failure, and execute protection switching as described in
4.3.2. Node A in Ring2 will also detect the failure, and execute 4.3.2. Node A in Ring2 will also detect the failure, and execute
protection switching as described in 4.3.2. The path that the protection switching as described in 4.3.2. The path that the
service traffic LSP1 follows after switching is: service traffic LSP1 follows after switching is:
LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1. LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1.
4.4.5. Interconnected Ring Detection Mechanism 4.4.5. Interconnected Ring Detection Mechanism
skipping to change at page 23, line 20 skipping to change at page 23, line 32
label of Ring1 and push the ring tunnel label of Ring2 and send the label of Ring1 and push the ring tunnel label of Ring2 and send the
traffic to Node I via ring tunnel (R2aW_I). traffic to Node I via ring tunnel (R2aW_I).
5. Ring Protection Coordination Protocol 5. Ring Protection Coordination Protocol
5.1. RPS Protocol 5.1. RPS Protocol
The MSRP protection operation MUST be controlled with the help of the The MSRP protection operation MUST be controlled with the help of the
Ring Protection Switch protocol (RPS). The RPS processes in each of Ring Protection Switch protocol (RPS). The RPS processes in each of
the individual ring nodes that form the ring MUST communicate using the individual ring nodes that form the ring MUST communicate using
the G-ACh channel. The described RPS protocol uses the short- the G-ACh channel. The RPS protocol is applicable to all the three
wrapping mechanism described in section 4.3.2 as an example. ring protection modes. This section takes the short-wrapping
mechanism described in section 4.3.2 as an example.
All nodes in the same ring MUST use the same protection mechanism, All nodes in the same ring MUST use the same protection mechanism,
Wrapping, steering or short-wrapping. Wrapping, steering or short-wrapping.
The RPS protocol MUST carry the ring status information and RPS The RPS protocol MUST carry the ring status information and RPS
requests, either automatically initiated or externally initiated, requests, either automatically initiated or externally initiated,
between the ring nodes. between the ring nodes.
Each node on the ring MUST be uniquely identified by assigning it a Each node on the ring MUST be uniquely identified by assigning it a
node ID. The node ID MUST be unique on each ring. The maximum node ID. The node ID MUST be unique on each ring. The maximum
skipping to change at page 23, line 45 skipping to change at page 24, line 10
destination nodes of each RPS request. destination nodes of each RPS request.
Every node obtains the ring topology either by configuration or via Every node obtains the ring topology either by configuration or via
some topology discovery mechanism. The ring map consists of the ring some topology discovery mechanism. The ring map consists of the ring
topology information, and connectivity status (Intact or Severed) topology information, and connectivity status (Intact or Severed)
between the adjacent ring nodes, which is determined via the OAM between the adjacent ring nodes, which is determined via the OAM
message exchanged between the adjacent nodes. The ring map is used message exchanged between the adjacent nodes. The ring map is used
by every ring node to determine the switchover behavior of the ring by every ring node to determine the switchover behavior of the ring
tunnels. tunnels.
When no protection switching is active on the ring, each node MUST As shown in Figure 14, when no protection switching is active on the
dispatch periodically RPS requests to the two adjacent nodes, ring, each node MUST send RPS requests with No Request (NR) to its
indicating No Request (NR). When a node determines that a protection two adjacent nodes periodically.
switching is required, it MUST send the appropriate RPS request in
both directions.
+---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR)
-------| A |-------------| B |-------------| C |------- -------| A |-------------| B |-------------| C |-------
(NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+
Figure 14. RPS communication between the ring nodes in case of Figure 14. RPS communication between the ring nodes in case of
no failure in the ring no failure in the ring
A destination node is a node that is adjacent to a node that As shown in Figure 15, When a node detects a failure and determines
identified a failed link. When a node that is not the destination that protection switching is required, it MUST send the appropriate
node receives an RPS request and it has no higher priority local RPS request in both directions to the destination node. The
request, it MUST transfer in the same direction the RPS request as destination node is the other node that is adjacent to the identified
received. In this way, the switching nodes can maintain direct RPS failure. When a node that is not the destination node receives an
protocol communication in the ring. RPS request and it has no higher priority local request, it MUST
transfer in the same direction the RPS request as received. In this
way, the switching nodes can maintain RPS protocol communication in
the ring.
+---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF) +---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF)
-------| A |-------------| B |----- X -----| C |------- -------| A |-------------| B |----- X -----| C |-------
(SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+
Figure 15. RPS communication between the ring nodes in case of Figure 15. RPS communication between the ring nodes in case of
failure between nodes B and C failure between nodes B and C
Note that in the case of a bidirectional failure such as a cable cut, Note that in the case of a bidirectional failure such as a cable cut,
the two adjacent nodes detect the failure and send each other an RPS the two adjacent nodes detect the failure and send each other an RPS
skipping to change at page 24, line 51 skipping to change at page 25, line 15
o In rings utilizing the steering protection. When a ring switch is o In rings utilizing the steering protection. When a ring switch is
required, any node MUST perform the switches if its added/dropped required, any node MUST perform the switches if its added/dropped
traffic is affected by the failure. Determination of the affected traffic is affected by the failure. Determination of the affected
traffic SHOULD be performed by examining the RPS requests traffic SHOULD be performed by examining the RPS requests
(indicating the nodes adjacent to the failure or failures) and the (indicating the nodes adjacent to the failure or failures) and the
stored ring map (indicating the relative position of the failure stored ring map (indicating the relative position of the failure
and the added traffic destined towards that failure). and the added traffic destined towards that failure).
When the failure has cleared and the Wait-to-Restore (WTR) timer has When the failure has cleared and the Wait-to-Restore (WTR) timer has
expired, the nodes sourcing RPS requests MUST drop their respective expired, the nodes sourcing RPS requests MUST drop their respective
switches (tail end) and MUST source an RPS request carrying the NR switches and MUST source an RPS request carrying the NR code. The
code. The node receiving from both directions such an RPS request node receiving from both directions such an RPS request MUST drop its
(head end) MUST drop its protection switches. protection switches.
A protection switch MUST be initiated by one of the criteria A protection switch MUST be initiated by one of the criteria
specified in Section 5.2. A failure of the RPS protocol or specified in Section 5.2. A failure of the RPS protocol or
controller MUST NOT trigger a protection switch. controller MUST NOT trigger a protection switch.
Ring switches MUST be preempted by higher priority RPS requests. For Ring switches MUST be preempted by higher priority RPS requests. For
example, consider a protection switch that is active due to a manual example, consider a protection switch that is active due to a manual
switch request on the given link, and another protection switch is switch request on the given link, and another protection switch is
required due to a failure on another link. Then an RPS request MUST required due to a failure on another link. Then an RPS request MUST
be generated, the former protection switch MUST be dropped, and the be generated, the former protection switch MUST be dropped, and the
skipping to change at page 25, line 44 skipping to change at page 26, line 7
The first three RPS protocol messages carrying new RPS request SHOULD The first three RPS protocol messages carrying new RPS request SHOULD
be transmitted as fast as possible. For fast protection switching be transmitted as fast as possible. For fast protection switching
within 50 ms, the interval of the first three RPS protocol messages within 50 ms, the interval of the first three RPS protocol messages
SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted
with the interval of 5 seconds. A ring node which is not the with the interval of 5 seconds. A ring node which is not the
destination of the received RPS message MUST forward it to the next destination of the received RPS message MUST forward it to the next
node along the ring immediately. node along the ring immediately.
5.1.2. RPS PDU Format 5.1.2. RPS PDU Format
Figure 17 depicts the format of an RPS packet that is sent on the Figure 16 depicts the format of an RPS packet that is sent on the
G-ACh. The Channel Type field is set to indicate that the message is G-ACh. The Channel Type field is set to indicate that the message is
an RPS message. The ACH MUST NOT include the ACH TLV Header an RPS message.
[RFC5586] meaning that no ACH TLVs can be included in the message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) | |0 0 0 1|Version| Reserved | RPS Channel Type (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Node ID | Src Node ID | Request | M | Reserved | | Dest Node ID | Src Node ID | Request | M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16. G-ACh RPS Packet Format Figure 16. G-ACh RPS Packet Format
The following fields MUST be provided: The following fields MUST be provided:
o Destination Node ID: The destination node ID MUST always be set to o Destination Node ID: The destination node ID MUST always be set to
value of the node ID of the adjacent node. The Node ID MUST be value of the node ID of the adjacent node. The Node ID MUST be
unique on each ring. Valid destination node ID values are 1-127. unique on each ring. Valid destination node ID values are 1-127.
o Source Node ID: The source node ID MUST always be set to the ID o Source Node ID: The source node ID MUST always be set to the ID
value of the node generating the RPS request. The Node ID MUST be value of the node generating the RPS request. The Node ID MUST be
unique on each ring. Valid source node ID values are 1-127. unique on each ring. Valid source node ID values are 1-127.
o Protection Switching Mode (M): This 2-bit field indicates the o Protection Switching Mode (M): This 2-bit field indicates the
protection switching mode used by the sending node of the RPS protection switching mode used by the sending node of the RPS
message. This can be used to check that the ring nodes on the message. This can be used to check that the ring nodes on the
sane ring use the same protection switching mechanism. The same ring use the same protection switching mechanism. The
defined values of the M field are listed as below: defined values of the M field are listed as below:
+------------------+-----------------------------+ +------------------+-----------------------------+
| Bits (MSB-LSB) | Protecton Switching Mode | | Bits (MSB-LSB) | Protecton Switching Mode |
+------------------+-----------------------------+ +------------------+-----------------------------+
| 0 0 | Reserved | | 0 0 | Reserved |
| 0 1 | Wrapping | | 0 1 | Wrapping |
| 1 0 | Short Wrapping | | 1 0 | Short Wrapping |
| 1 1 | Steering | | 1 1 | Steering |
+------------------+-----------------------------+ +------------------+-----------------------------+
skipping to change at page 27, line 48 skipping to change at page 27, line 48
A node in the idle state MUST block the traffic flow on protection A node in the idle state MUST block the traffic flow on protection
ring tunnels in both directions. ring tunnels in both directions.
5.1.3.2. Switching State 5.1.3.2. Switching State
A node in the switching state MUST source RPS request to its adjacent A node in the switching state MUST source RPS request to its adjacent
node with its highest RPS request code in both directions when it node with its highest RPS request code in both directions when it
detects a failure or receives an external command. detects a failure or receives an external command.
A node in the switching state MUST terminate RPS requests flow in In bidirectional failure condition, both of the nodes adjacent to the
both directions. failure detect the failure and send the RPS request in both
directions with the destination set to each other, while each node
can only receive the RPS request via the long path, the message sent
via the short path will get lost due to the bidirectional failure.
As soon as it receives an RPS request from the short path, the node Here the short path refers to the shorter path on the ring between
to which it is addressed MUST acknowledge the RPS request by replying the source and destination node of the RPS request, and the long path
with the RR code on the short path, and with the received RPS request refers to the longer path on the ring between the source and
code on the long path. Accordingly, if RR code is received from the destination node of the RPS request. Upon receipt of the RPS request
short path, then the RPS request sent by the same node over the long on the long path, the destination node of the RPS request MUST send
path SHOULD be ignored. Here the short path refers to the shorter RPS request with its highest request code periodically along the long
path on the ring between the source and destination node of the RPS path to the other node adjacent to the failure.
request, and the long path refers to the longer path on the ring
between the source and destination node of the RPS request.
This rule refers to the unidirectional failure detection: the RR In unidirectional failure condition, the node which detects the
SHOULD be issued only when the node does not detect the failure failure MUST send the RPS request in both directions with the
condition (i.e., the node is a head end), that is, it is not destination node set to the other node adjacent to the failure. The
applicable when a bidirectional failure is detected, because, in this destination node of the RPS request cannot detect the failure itself
case, both nodes adjacent to the failure will send an RPS request for but will receive RPS request from both the short path and the long
the failure on both paths (short and long). path. The destination node MUST acknowledge the received RPS request
by replying an RPS request with the RR code on the short path, and an
RPS request with the received RPS request code on the long path.
Accordingly, when the node which detects the failure receives RPS
request with RR code on the short path, then the RPS request received
from the same node along the long path SHOULD be ignored.
A node in the switching state MUST terminate the received RPS
requests in both directions and not forward it further along the
ring.
The following switches MUST be allowed to coexist: The following switches MUST be allowed to coexist:
o LP and LP o LP and LP
o FS and FS o FS and FS
o SF and SF o SF and SF
o FS and SF o FS and SF
skipping to change at page 29, line 31 skipping to change at page 29, line 39
to the node itself. Both directions move then into a pass-through to the node itself. Both directions move then into a pass-through
state, so that, traffic entering the node through the protection Ring state, so that, traffic entering the node through the protection Ring
tunnels are transferred transparently through the node. tunnels are transferred transparently through the node.
A node MUST revert from pass-through state to the idle state when it A node MUST revert from pass-through state to the idle state when it
detects NR codes incoming from both directions. Both directions detects NR codes incoming from both directions. Both directions
revert simultaneously from the pass-through state to the idle state. revert simultaneously from the pass-through state to the idle state.
5.1.4.2. Transitions Between Idle and Switching States 5.1.4.2. Transitions Between Idle and Switching States
Transition of a node from the idle state to the switching state MUST Transition of a node from the Idle state to the Switching state MUST
be triggered by one of the following conditions: be triggered by one of the following conditions:
o A valid RPS request change from the NR code to any code received o A valid RPS request change from the NR code to any code received
on either the long or the short path and destined to this node on either the long or the short path and is destined to this node
o An externally initiated command for this node o An externally initiated command for this node
o The detection of an MPLS-TP section layer failure at this node o The detection of an MPLS-TP section layer failure at this node
Actions taken at a node in the idle state upon transition to the Actions taken at a node in the Idle state upon transition to the
switching state are: switching state are:
o For all protection switch requests, except EXER and LP, the node o For all protection switch requests, except EXER and LP, the node
MUST execute the switch MUST execute the switch
o For EXER, and LP, the node MUST signal appropriate request but not o For EXER, and LP, the node MUST signal appropriate request but not
execute the switch execute the switch
A node MUST revert from the switching state to the idle state when it In one of the following conditions, transition from the Idle state to
detects NR codes received from both directions. the Switching state MUST be triggered:
o At the tail end: When a WTR time expires or an externally o On node which triggers the protection switching, when the WTR time
initiated command is cleared at a node, the node MUST drop its expires or an externally initiated command is cleared, the node
switch, transit to the Idle State and signal the NR code in both MUST transit from Switching state to Idle State and signal the NR
directions. code using RPS message in both directions.
o At the head end: Upon reception of the NR code, from both o On node which enters the switching state due to the received RPS
directions, the head-end node MUST drop its switch, transition to request: Upon reception of the NR code from both directions, the
Idle State and signal the NR code in both directions. head-end node MUST drop its switch, transition to Idle State and
signal the NR code in both directions.
5.1.4.3. Transitions Between Switching States 5.1.4.3. Transitions Between Switching States
When a node that is currently executing any protection switch When a node that is currently executing any protection switch
receives a higher priority RPS request (due to a locally detected receives a higher priority RPS request (due to a locally detected
failure, an externally initiated command, or a ring protection switch failure, an externally initiated command, or a ring protection switch
request destined to it) for the same link, it MUST update the request destined to it) for the same link, it MUST update the
priority of the switch it is executing to the priority of the priority of the switch it is executing to the priority of the
received RPS request. received RPS request.
skipping to change at page 32, line 8 skipping to change at page 32, line 21
but no normal traffic is affected. but no normal traffic is affected.
The following commands are not transferred by the RPS message: The following commands are not transferred by the RPS message:
o Clear: This command clears the administrative command and Wait-To- o Clear: This command clears the administrative command and Wait-To-
Restore timer (WTR) at the node to which the command was Restore timer (WTR) at the node to which the command was
addressed. The node-to-node signaling after the removal of the addressed. The node-to-node signaling after the removal of the
externally initiated commands is performed using the no-request externally initiated commands is performed using the no-request
code (NR). code (NR).
o Lockout of Working: This command prevents the normal traffic o Lockout of Working (LW): This command prevents the normal traffic
transported over the addressed link from being switched to the transported over the addressed link from being switched to the
protection entity by disabling the node's capability of requesting protection entity by disabling the node's capability of requesting
switch for this link in case of failure. If any normal traffic is switch for this link in case of failure. If any normal traffic is
already switched on the protection entity, the switch is dropped. already switched on the protection entity, the switch is dropped.
If no other switch requests are active on the ring, the no-request If no other switch requests are active on the ring, the no-request
code (NR) is transmitted. This command has no impact on any other code (NR) is transmitted. This command has no impact on any other
link. If the node receives the switch request from the adjacent link. If the node receives the switch request from the adjacent
node from any side it will perform the requested switch. If the node from any side it will perform the requested switch. If the
node receives the switch request addressed to the other node, it node receives the switch request addressed to the other node, it
will enter the pass-through state. will enter the pass-through state.
skipping to change at page 33, line 4 skipping to change at page 33, line 10
the state during the WTR period unless it is preempted by a higher the state during the WTR period unless it is preempted by a higher
priority switch request. The WTR time may be configured by the priority switch request. The WTR time may be configured by the
operator in 1 minute steps between 0 and 12 minutes; the default operator in 1 minute steps between 0 and 12 minutes; the default
value is 5 minutes. value is 5 minutes.
o Reverse Request (RR): This command is transmitted to the source o Reverse Request (RR): This command is transmitted to the source
node of the received RPS message over the short path as an node of the received RPS message over the short path as an
acknowledgment for receiving the switch request. acknowledgment for receiving the switch request.
5.2.2. Initial States 5.2.2. Initial States
This section describes the possible states of a ring node, the
corresponding action of the working and protection ring tunnels on
the node, and the RPS request which should be generated in that
state.
+-----------------------------------+----------------+ +-----------------------------------+----------------+
| State | Signaled RPS | | State | Signaled RPS |
+-----------------------------------+----------------+ +-----------------------------------+----------------+
| A | Idle | NR | | A | Idle | NR |
| | Working: no switch | | | | Working: no switch | |
| | Protection: no switch | | | | Protection: no switch | |
+-----+-----------------------------+----------------+ +-----+-----------------------------+----------------+
| B | Pass-through | N/A | | B | Pass-through | N/A |
| | Working: no switch | | | | Working: no switch | |
| | Protection: pass through | | | | Protection: pass through | |
 End of changes. 41 change blocks. 
103 lines changed or deleted 127 lines changed or added

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