draft-ietf-mpls-tp-shared-ring-protection-02.txt   draft-ietf-mpls-tp-shared-ring-protection-03.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: December 17, 2016 China Mobile Expires: April 2, 2017 China Mobile
H. Helvoort H. Helvoort
Hai Gaoming BV Hai Gaoming BV
K. Liu
J. Dong J. Dong
J. He
Huawei Technologies Huawei Technologies
F. Li September 29, 2016
China Academy of Telecommunication Research, MIIT., China
J. Yang
ZTE Corporation P.R.China
J. Wang
Fiberhome Telecommunication Technologies Co., LTD.
June 15, 2016
MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology Shared-Ring protection (MSRP) mechanism for ring topology
draft-ietf-mpls-tp-shared-ring-protection-02 draft-ietf-mpls-tp-shared-ring-protection-03
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 the ring topology for point- MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point-
to-point (P2P) services. The mechanism of MSRP is illustrated and to-point (P2P) services. The MSRP mechanism is described to meet the
how it satisfies the requirements for optimized ring protection in ring protection requirements as described in RFC 5654. This document
RFC 5654 is analyzed. This document also defines the Ring Protection defines the Ring Protection Switch (RPS) Protocol that is used to
Switch (RPS) Protocol which is used to coordinate the protection coordinate the protection behavior of the nodes on MPLS ring.
behavior of the nodes on MPLS ring.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 10 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 December 17, 2016. This Internet-Draft will expire on April 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements for MPLS-TP Ring Protection . . . . . . . . . . 4 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
2.1. Recovery of Multiple Failures . . . . . . . . . . . . . . 4 3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 4
2.2. Smooth Upgrade from Linear Protection to Ring Protection 5
2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5
3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5
4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6
4.1.2. Label Assignment and Distribution . . . . . . . . . . 8 4.1.2. Label Assignment and Distribution . . . . . . . . . . 7
4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 7
4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 8
4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 13 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12
4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 15 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Interconnected Ring Protection . . . . . . . . . . . . . 18 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17
4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 18 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17
4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 20 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 19
4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 20 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19
4.4.4. Interconnected Ring Switching Procedure . . . . . . . 22 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21
4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 23 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22
5. Ring Protection Coordination Protocol . . . . . . . . . . . . 24 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23
5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 24 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. Transmission and Acceptance of RPS Requests . . . . . 26 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 25
5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . 33 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 32
5.2.3. State transitions When Local Request is Applied . . . 34 5.2.3. State transitions When Local Request is Applied . . . 33
5.2.4. State Transitions When Remote Request is Applied . . 37 5.2.4. State Transitions When Remote Request is Applied . . 37
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 . . . . . . . . . . . . . . . . . . 40
5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 43 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 43
6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 44 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
As described in section 2.5.6.1 of [RFC5654], Ring Protection of As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1,
MPLS-TP requirements, 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
with ring topologies. It calls for an efficient and optimized ring using ring topologies. This calls for an efficient and optimized
protection mechanism to achieve simple operation and fast, sub 50 ms, ring protection mechanism to achieve simple operation and fast, sub
recovery performance. 50 ms, recovery performance.
The requirements for MPLS-TP [RFC5654] state that recovery mechanisms
which are optimized for ring topologies could be further developed if
it can provide the following features:
a. Minimize the number of OAM entities for protection
b. Minimize the number of elements of recovery This document specifies an MPLS-TP Shared-Ring Protection mechanisms
that meets the criteria for ring protection and the ring protection
requirements described in section 2.5.6.1 of [RFC5654].
c. Minimize the required label number The basic concept and architecture of Shared-Ring protection
mechanism are specified in this document. This document describes
the solutions for point-to-point transport paths. While the basic
concept may also apply to point-to-multipoint transport paths, the
solution for point-to-multipoint transport paths is out of the scope
of this document.
d. Minimize the amount of control and management-plane transactions 2. Terminology and Notation
during maintenance operation
e. Minimize the impact on information exchange during protection if Terminology:
a control plane is supported
This document specifies MPLS-TP Shared-Ring Protection mechanisms Ring Node: A ring node is a node in the ring topology that actively
that can meet all those requirements on ring protection listed in participates in the ring protection.
[RFC5654].
The basic concepts and architecture of Shared-Ring protection Ring tunnel: A ring tunnel provides a server layer for the LSPs
mechanism are specified in this document. This document focuses on traverse the ring. The notation for ring tunnel is: xxxx R<d><P>_<x>
the solutions for point-to-point transport paths. While the basic where <d> = c (clockwise) or a (anticlockwise), <P> = W (working) or
concepts may also apply to point-to-multipoint transport paths, the P (protecting), and <x> the node name.
solution for point-to-multipoint transport paths is under study and
will be presented in a separate document.
2. Requirements for MPLS-TP Ring Protection 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,
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
node it enters and leaves the ring. The ring map is used by every
ring node to determine the switchover behavior of the ring tunnels.
The requirements for MPLS-TP ring protection are specified in Notation:
[RFC5654]. This document elaborates on the requirements in detail.
2.1. Recovery of Multiple Failures The following syntax will be used to describe the contents of the
label stack:
MPLS-TP is expected to be used in carrier grade metro networks and 1. The label stack will be enclosed in square brackets ("[]").
backbone transport networks to provide mobile backhaul, business
services etc., in which the network survivability is very important.
According to R106 B in [RFC5654], MPLS-TP recovery mechanisms in a
ring SHOULD protect against multiple failures. The following text
provides some more detailed illustration about "multiple failures".
In metro and backbone networks, a single risk factor often affects
multiple links or nodes. Some examples of risk factors are given as
follows:
o multiple links use fibers in one cable or pipeline 2. Each level in the stack will be separated by the '|' character.
It should be noted that the label stack may contain additional
layers. However, we only present the layers that are related to the
protection mechanism.
o Several nodes share one power supply system 3. If the Label is assigned by Node X, the Node Name is enclosed in
bracket ("()")
o Weather sensitive micro-wave system 3. MPLS-TP Ring Protection Criteria and Requirements
Once one of the above risk factors happens, multiple links or nodes The generic requirements for MPLS-TP protection are specified in
failures may occur simultaneously and those failed links or nodes may [RFC5654]. The requirements specific for ring protection are
be located on a single ring as well as on interconnected rings. Ring specified in section 2.5.6.1 of [RFC5654]. This section describes
protection against multiple failures should cover both multiple how the criteria for ring protection are met:
failures on a single ring and multiple failures on interconnected
rings, as long as the connectivity between the ingress and egress
node of the ring still exists.
2.2. Smooth Upgrade from Linear Protection to Ring Protection a. The number of OAM entities needed to trigger protection
It is beneficial for service providers to upgrade the protection Each ring-node requires only one instance of the RPS protocol. The
scheme from linear protection to ring protection in their MPLS-TP OAM of the links connected to the adjacent ring-nodes has to be
network without service interruption. In-service insertion and forwarded to only this instance in order to trigger protection.
removal of a node on the ring should also be supported. Therefore,
the MPLS-TP ring protection mechanism is supposed to be developed and
optimized for compliance with this smooth upgrading principle.
2.3. Configuration Complexity b. The number of elements of recovery in the ring
Ring protection can reduce the dependency of configuration on the Each ring-node requires only one instance of the RPS protocol and is
quantity of services, thus will simplify the network protection independent of the number of LSPs that are protected.
configuration and operation effort. This is because the ring
protection makes use of the characteristics of ring topology and
mechanisms on the section layer. While in the application scenarios
of deploying linear protection in ring topology MPLS-TP network, the
configuration of protection has a close relationship with the
quantities of services carried. Especially in some large metro
networks with more than ten thousands of services in the access
nodes, the LSP linear protection capabilities of the metro core nodes
needs to be large enough to meet the network planning requirements,
which also leads to the complexity of network protection
configurations and operations.
3. Terminology and Notation c. The required number of labels required for the protection paths
The following syntax will be used to describe the contents of the The RPS protocol uses ring tunnels and each tunnel has a set of
label stack: labels. The number of ring tunnel labels is related to the number of
ring-nodes and is independent of the number of protected LSPs.
1. The label stack will be enclosed in square brackets ("[]"). d. The amount of control and management-plane transactions
Each ring-node requires only one instance of the RPS protocol this
means that only one maintenance operation is required per ring-node.
2. Each level in the stack will be separated by the '|' character. e. Minimize the signaling and routing information exchange during
It should be noted that the label stack may contain additional protection
layers. However, we only present the layers that are related to the
protection mechanism.
3. If the Label is assigned by Node X, the Node Name is enclosed in Information exchange during a protection switch is using the in-band
bracket ("()") RPS and OAM messages. No control plane interactions are required.
4. Shared Ring Protection Architecture 4. Shared Ring Protection Architecture
4.1. Ring Tunnel 4.1. Ring Tunnel
This document introduces a new logical layer of the ring for shared This document introduces a new logical layer of the ring for shared
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 configuration, management and protection of the ring are all the forwarding and protection switching of the ring are all performed
performed at the ring tunnel level. One port can carry multiple ring at the ring tunnel level. A port can carry multiple ring tunnels,
tunnels, while one ring tunnel can carry multiple LSPs. and a ring tunnel can carry multiple LSPs.
+------------- +-------------
+-------------| +-------------|
+-------------| | +-------------| |
=====PW1======| | | =====PW1======| | |
| | Ring | Physical | | Ring | Physical
=====PW2======| LSP | Tunnel | Port =====PW2======| LSP | Tunnel | Port
| | | | | |
=====PW3======| | | =====PW3======| | |
+-------------| | +-------------| |
+-------------| +-------------|
+------------- +-------------
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
shown as below: [Ring Tunnel Label|LSP Label|PW Label](Payload) as illustrated in
figure 2.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring tunnel Label | | Ring tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | | LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Label | | PW 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 share the same ring tunnels. have the same egress node on the ring and travels along the ring in
In other words, all the LSPs that traverse the ring and exit from the the same direction (clockwise or anticlockwise) share the same ring
same node share the same working ring tunnel and protection ring tunnels. In other words, all the LSPs that traverse the ring in the
tunnel. For each egress node, four ring tunnels are established: same direction and exit from the same node share the same working
ring tunnel and protection ring tunnel. For each egress node, four
ring tunnels are established:
o one clockwise working ring tunnel, which is protected by the o one clockwise working ring tunnel, which is protected by the
anticlockwise protection ring tunnel anticlockwise protection ring tunnel
o one anticlockwise protection ring tunnel o one anticlockwise protection ring tunnel
o one anticlockwise working ring tunnel, which is protected by the o one anticlockwise working ring tunnel, which is protected by the
clockwise protection ring tunnel clockwise protection ring tunnel
o one clockwise protection ring tunnel o one clockwise protection ring tunnel
skipping to change at page 8, line 34 skipping to change at page 7, line 34
Figure 3. Ring tunnels in MSRP Figure 3. Ring tunnels in MSRP
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 can be either configured [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can
statically, provisioned by a controller, or distributed dynamically be either configured statically, provisioned by a controller, or
via a control protocol. distributed dynamically via a control protocol.
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 ingress node on the ring pushes the working ring tunnel label which
according to the egress node and sends the traffic to the next hop. is used to reach the specific egress node and sends the traffic to
The transit nodes on the working ring tunnel swap the ring tunnel the next hop. The transit nodes on the working ring tunnel swap the
labels and forward the packets to the next hop. When the packet ring tunnel labels and forward the packets to the next hop. When the
arrives at the egress node, the egress node pops the ring tunnel packet arrives at the egress node, the egress node pops the ring
label and forwards the packets based on the inner LSP label and PW tunnel label and forwards the packets based on the inner LSP label
label. Figure 4 shows the label operation in the MPLS-TP shared ring and PW label. Figure 4 shows the label operation in the MPLS-TP
protection mechanism. Assume that LSP1 enters the ring at Node A and shared ring protection mechanism. Assume that LSP1 enters the ring
exits from Node D, and the following label operations are executed. at Node A and exits from Node D, and the following label operations
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 is supposed to be forwarded in the clockwise direction [LSP1] and is supposed to be forwarded in the clockwise direction
of the ring. The clockwise working ring tunnel label RcW_D will of the ring. The clockwise working ring tunnel label RcW_D will
be pushed at Node A, the label stack for the forwarded packet at be pushed at Node A, the label stack for the forwarded packet at
Node A is changed to [RcW_D(B)|LSP1]. 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
skipping to change at page 9, line 47 skipping to change at page 8, line 47
Figure 4. Label operation of MSRP Figure 4. Label operation of MSRP
4.2. Failure Detection 4.2. Failure Detection
The MPLS-TP section layer OAM is used to monitor the connectivity The MPLS-TP section layer OAM is used to monitor the connectivity
between each two adjacent nodes on the ring using the mechanisms between each two adjacent nodes on the ring using the mechanisms
defined in [RFC6371]. Protection switching is triggered by the defined in [RFC6371]. Protection switching is triggered by the
failure detected on the ring by the OAM mechanisms. failure detected on the ring by the OAM mechanisms.
Two end ports of a link form a Maintenance Entity Group (MEG), and an Two ports of a link form a Maintenance Entity Group (MEG), and an MEG
MEG end point (MEP) function is installed in each ring port. CC OAM end point (MEP) function is installed in each ring port. CC OAM
packets are periodically exchanged between each pair of MEPs to packets are periodically exchanged between each pair of MEPs to
monitor the link health. Three consecutive CC packets losses will be monitor the link health. Three consecutive lost CC packets will be
interpreted as a link failure. interpreted as a link failure.
A node failure is regarded as the failure of two links attached to A node failure is regarded as the failure of two links attached to
that node. The two nodes adjacent to the failed node detect the that node. The two nodes adjacent to the failed node detect the
failure in the links that are connected to the failed node. failure in the links that are connected to the failed node.
4.3. Ring Protection 4.3. Ring Protection
This section specifies the ring protection mechanisms in detail. In This section specifies the ring protection mechanisms in detail. In
general, the description uses the clockwise working ring tunnel and general, the description uses the clockwise working ring tunnel and
the corresponding anti-clockwise protection ring tunnel as example, the corresponding anti-clockwise protection ring tunnel as an
but the mechanism is applicable in the same way to the anti-clockwise example, but the mechanism is applicable in the same way to the anti-
working and clockwise protection ring tunnels. clockwise working and clockwise protection ring tunnels.
In ring network, each working ring tunnel is associated with a In a ring network, each working ring tunnel is associated with a
protection ring tunnel in the opposite direction, and every node can protection ring tunnel in the opposite direction, and every node MUST
obtain the ring topology either by configuration or via some topology obtain the ring topology either by configuration or via a topology
discovery mechanism. The ring topology and the connectivity (Intact discovery mechanism. The ring topology and the connectivity (Intact
or Severed) between the adjacent ring nodes form the ring map. Each or Severed) between two adjacent ring nodes form the ring map. Each
ring node maintains the ring map and use it to peform ring ring node maintains the ring map and use it to perform ring
protection. protection.
Taking the topology in Figure 4 as example, LSP1 enters the ring at Taking the topology in Figure 4 as an example, LSP1 enters the ring
Node A and leaves the ring at Node D. In normal state, LSP1 is at Node A and leaves the ring at Node D. In normal state, LSP1 is
carried by clockwise working ring tunnel (RcW_D) through the path carried by the clockwise working ring tunnel (RcW_D) through the path
A->B->C->D, the label operation is: A->B->C->D. The label operation is:
[LSP1](original data traffic carried by LSP1) -> [LSP1](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB)
[RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload). Then at node D the
LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D packet will be forwarded based on the label stack of LSP1.
the packet will be forwarded based on the label stack of LSP1.
Three typical ring protection mechanisms are specified in this Three typical ring protection mechanisms are described in this
section: wrapping, short wrapping and steering. section: wrapping, short wrapping and steering. All nodes on the
same ring MUST use the same protection mechanism.
In wrapping ring protection, node which detects a failure or accepts Wrapping ring protection: the node which detects a failure or accepts
a switch request switches the traffic impacted by the failure to the a switch request switches the traffic impacted by the failure or the
opposite direction (away from the failure). In this way, the switch request to the opposite direction (away from the failure). In
impacted traffic is switched to the protection ring tunnel by the this way, the impacted traffic is switched to the protection ring
switching node upstream to the failure, then travels around the ring tunnel by the switching node upstream of the failure, then travels
to the other switching node through the protection ring tunnel, where around the ring to the switching node downstream of the failure
it is switched back onto the working ring tunnel and reach the egress through the protection ring tunnel, where it is switched back onto
node. the working ring tunnel to reach the egress node.
Short wrapping ring protection provides some optimization to wrapping Short wrapping ring protection provides some optimization to wrapping
protection, in which the impacted traffic is only switched once to protection, in which the impacted traffic is only switched once to
the protection ring tunnel by the switching node upstream to the the protection ring tunnel by the switching node upstream to the
failure. At the egress node, the traffic leave the ring from the failure. At the egress node, the traffic leave the ring from the
protection ring tunnel. This can reduce the traffic detour of protection ring tunnel. This can reduce the traffic detour of
wrapping protection. wrapping protection.
Steering ring protection implies that the node that detects a failure Steering ring protection implies that the node that detects a failure
sends a request along the ring to the other node adjacent to the sends a request along the ring to the other node adjacent to the
failure, and all nodes in the ring process this information. For the failure, and all nodes in the ring process this information. For the
impaced traffic, the ingress node (which adds traffic to the ring) impaced traffic, the ingress node (which adds traffic to the ring)
perform switching from working to the protection ring tunnel, and at perform switching of the traffic from working to the protection ring
the egress node the traffic leaves the ring from the protection ring tunnel, and the egress node will drop the traffic received from the
tunnel. protection ring tunnel.
The following sections describes these protection mechanisms in The following sections describes these protection mechanisms in
detail. detail.
4.3.1. Wrapping 4.3.1. Wrapping
With the wrapping mechanism, the protection ring tunnel is a closed With the wrapping mechanism, the protection ring tunnel is a closed
ring identified by the egress node. As shown in Figure 4, the RaP_D ring identified by the egress node. As shown in Figure 4, the RaP_D
is the anticlockwise protection ring tunnel for the clockwise working is the anticlockwise protection ring tunnel for the clockwise working
ring tunnel RcW_D. As specified in the following sections, the ring tunnel RcW_D. As specified in the following sections, the
closed ring protection tunnel can protect both the link failure and closed ring protection tunnel can protect both link failures and node
the node failure. failures.
4.3.1.1. Wrapping for Link Failure 4.3.1.1. Wrapping for Link Failure
When a link failure between Node B and Node C occurs, if it is a bi- When a link failure between Node B and Node C occurs, if it is a bi-
directional failure, both Node B and Node C can detect the failure directional failure, both Node B and Node C can detect the failure
via OAM mechanism; if it is a uni-directional failure, one of the two via the OAM mechanism; if it is a uni-directional failure, one of the
nodes would detect the failure and it would inform the other node via two nodes would detect the failure via the OAM mechanism. In both
the Ring Protection Switch Protocol (RPS) which is specified in cases the node at the other side of the detected failure will be
section 5. Then Node B switches the clockwise working ring tunnel determined by the ring-map and informed using the Ring Protection
(RcW_D) to the anticlockwise protection ring tunnel (RaP_D) and Node Switch Protocol (RPS) which is specified in section 5. Then Node B
C switches anticlockwise protection ring tunnel(RaP_D) back to the switches the clockwise working ring tunnel (RcW_D) to the
clockwise working ring tunnel (RcW_D). The data traffic which enters anticlockwise protection ring tunnel (RaP_D) and Node C switches
the ring at Node A and leaves the ring at Node D follows the path anticlockwise protection ring tunnel(RaP_D) back to the clockwise
working ring tunnel (RcW_D). The data traffic which enters the ring
at Node A and leaves the ring at Node D follows the path
A->B->A->F->E->D->C->D. The label operation is: A->B->A->F->E->D->C->D. The label operation is:
[LSP1](Original data traffic) -> [RcW_D(B)|LSP1](Node A) -> [LSP1](Payload) -> [RcW_D(B)|LSP1](Node A) -> [RaP_D(A)|LSP1](Node B)
[RaP_D(A)|LSP1](Node B) -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] -> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] (Node F) ->
(Node F) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) -> [RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) ->
[RcW_D(D)|LSP1](Node C) -> [LSP1](data traffic leaves the ring). [RcW_D(D)|LSP1](Node C) -> [LSP1](Payload).
+---+#####[RaP_D(F)]######+---+ +---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1 | F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+ +---+*****[RcW_D(A)]******+---+
#/* *\# #/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\# #/* *\#
+---+ +---+ +---+ +---+
| E | | B | | E | | B |
+---+ +---+ +---+ +---+
skipping to change at page 12, line 33 skipping to change at page 11, line 33
Figure 5.Wrapping for link failure Figure 5.Wrapping for link failure
4.3.1.2. Wrapping for Node Failure 4.3.1.2. Wrapping for Node Failure
As shown in Figure 6, when Node B fails, Node A detects the failure As shown in Figure 6, when Node B fails, Node A detects the failure
between A and B and switches the clockwise work ring tunnel (RcW_D) between A and B and switches the clockwise work ring tunnel (RcW_D)
to the anticlockwise protection ring tunnel (RaP_D), Node C detects to the anticlockwise protection ring tunnel (RaP_D), Node C detects
the failure between C and B and switches the anticlockwise protection the failure between C and B and switches the anticlockwise protection
ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D). ring tunnel (RaP_D) to the clockwise working ring tunnel (RcW_D).
The node at the other side of the failed node will be determined by
the ring-map and informed using the Ring Protection Switch Protocol
(RPS) specified in section 5.
The data traffic which enters the ring at Node A and exits at Node D The data traffic which enters the ring at Node A and exits at Node D
follows the path A->F->E->D->C->D. The label operation is: follows the path A->F->E->D->C->D. The label operation is:
[LSP1](original data traffic carried by LSP1) -> [LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) ->
[RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) ->
[RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1] [RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1]
(NodeC) -> [LSP1](data traffic carried by LSP1). (NodeC) -> [LSP1](Payload).
In one special case where node D fails, all the ring tunnels with In one special case where node D fails, all the ring tunnels with
node D as egress will become unusable. However, before the failure node D as egress will become unusable. However, before the failure
location information is propagated to all the ring nodes, the location information is propagated to all the ring nodes, the
wrapping protection mechanism may cause temporary traffic loop: node wrapping protection mechanism may cause temporary traffic loop: node
C detects the failure and switches the traffic from the clockwise C detects the failure and switches the traffic from the clockwise
work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel
(RaP_D), node E also detects the failure and would switch the traffic (RaP_D), node E also detects the failure and would switch the traffic
from anticlockwise protection ring tunnel (RaP_D) back to the from anticlockwise protection ring tunnel (RaP_D) back to the
clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate
skipping to change at page 13, line 28 skipping to change at page 12, line 31
LSP1 +-- | D |-------------------| C | LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+ +---+#####[RaP_D(C)]####+---+
-----physical links xxxxxx Failure Node -----physical links xxxxxx Failure Node
*****RcW_D ###### RaP_D *****RcW_D ###### RaP_D
Figure 6. Wrapping for node failure Figure 6. Wrapping for node failure
4.3.2. Short Wrapping 4.3.2. Short Wrapping
With the traditional wrapping protection scheme, protection switching With the wrapping protection scheme, protection switching is executed
is executed at both nodes adjacent to the failure, consequently the at both nodes adjacent to the failure, consequently the traffic will
traffic will be wrapped twice. This mechanism will cause additional be wrapped twice. This mechanism will cause additional latency and
latency and bandwidth consumption when traffic is switched to the bandwidth consumption when traffic is switched to the protection
protection path. path.
With short wrapping protection, data traffic switching is executed With short wrapping protection, data traffic switching is executed
only at the node upstream to the failure, and data traffic leaves the only at the node upstream to the failure, and data traffic leaves the
ring in the protection ring tunnel at the egress node. This scheme ring in the protection ring tunnel at the egress node. This scheme
can reduce the additional latency and bandwidth consumption when can reduce the additional latency and bandwidth consumption when
traffic is switched to the protection path. traffic is switched to the protection path.
In the traditional wrapping solution, in normal state the protection In the wrapping solution, in normal state the protection ring tunnel
ring tunnel is a closed ring, while in the short wrapping solution, is a closed ring, while in the short wrapping solution, the
the protection ring tunnel is ended at the egress node, which is protection ring tunnel is ended at the egress node, which is similar
similar to the working ring tunnel. Short wrapping is easy to to the working ring tunnel. Short wrapping is easy to implement in
implement in shared ring protection because both the working and shared ring protection because both the working and protection ring
protection ring tunnels are terminated on the egress nodes. Figure 7 tunnels are terminated on the egress nodes. Figure 7 shows the
shows the clockwise working ring tunnel and the anticlockwise clockwise working ring tunnel and the anticlockwise protection ring
protection ring tunnel with node D as the egress node. tunnel with node D as the egress node.
4.3.2.1. Short Wrapping for Link Failure 4.3.2.1. Short Wrapping for Link Failure
As shown in Figure 7, in normal state, LSP1 is carried by the As shown in Figure 7, in normal state, LSP1 is carried by the
clockwise working ring tunnel (RcW_D) through the path A->B->C->D. clockwise working ring tunnel (RcW_D) through the path A->B->C->D.
When a link failure between Node B and Node C occurs, Node B switches When a link failure between Node B and Node C occurs, Node B switches
The working ring tunnel RcW_D to the protection ring tunnel RaP_D in the working ring tunnel RcW_D to the protection ring tunnel RaP_D in
the opposite direction. The difference occurs in the protection ring the opposite direction. The difference with wrapping occurs in the
tunnel at egress node. In short wrapping protection, Rap_D ends in protection ring tunnel at egress node. In short wrapping protection,
Node D and then traffic will be forwarded based on the LSP labels. Rap_D ends in Node D and then traffic will be forwarded based on the
Thus with short wrapping mechanism, LSP1 will follow the path LSP labels. Thus with short wrapping mechanism, LSP1 will follow the
A->B->A->F->E->D when link failure between Node B and Node C happens. path A->B->A->F->E->D when link failure between Node B and Node C
happens. The protection switch at node D is based on the information
from its ring map and the information received via the RPS protocol.
+---+#####[RaP_D(F)]######+---+ +---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1 | F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+ +---+*****[RcW_D(A)]******+---+
#/* *\# #/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\# #/* *\#
+---+ +---+ +---+ +---+
| E | | B | | E | | B |
+---+ +---+ +---+ +---+
skipping to change at page 14, line 50 skipping to change at page 13, line 52
For the node failure which happens on a non-egress node, short For the node failure which happens on a non-egress node, short
wrapping protection switching is similar to the link failure case as wrapping protection switching is similar to the link failure case as
described in the previous section. This section specifies the described in the previous section. This section specifies the
scenario of egress node failure. scenario of egress node failure.
As shown in Figure 8, LSP1 enters the ring on node A, and leaves the As shown in Figure 8, LSP1 enters the ring on node A, and leaves the
ring on node D. In normal state, LSP1 is carried by the clockwise ring on node D. In normal state, LSP1 is carried by the clockwise
working ring tunnel (RcW_D) through the path A->B->C->D. When node D working ring tunnel (RcW_D) through the path A->B->C->D. When node D
fails, traffic of LSP1 cannot be protected by any ring tunnels which fails, traffic of LSP1 cannot be protected by any ring tunnels which
use node D as the egress node. However, before the failure location use node D as the egress node. However, before the failure location
information is propagated to all the ring nodes, node C switches all information is propagated to all the ring nodes using the RPS
the traffic on the working ring tunnel RcW_D to the protection ring protocol, node C switches all the traffic on the working ring tunnel
tunnel RaP_D in the opposite direction. When the traffic arrives at RcW_D to the protection ring tunnel RaP_D in the opposite direction
node E which also detects the failure of node D, the protection ring based on the information in the ring map. When the traffic arrives
tunnel RaP_D cannot be used to forward traffic to node D. Since with at node E which also detects the failure of node D, the protection
short wrapping mechanism, protection switching can only be performed ring tunnel RaP_D cannot be used to forward traffic to node D. Since
once from the working ring tunnel to the protection ring tunnel, thus with short wrapping mechanism, protection switching can only be
node E MUST NOT switch the traffic which is already carried on the performed once from the working ring tunnel to the protection ring
protection ring tunnel back to the working ring tunnel in the tunnel, thus node E MUST NOT switch the traffic which is already
opposite direction. Instead, node E will discard the traffic carried on the protection ring tunnel back to the working ring tunnel
in the opposite direction. Instead, node E will discard the traffic
received on RaP_D locally. This can avoid the temporary traffic loop received on RaP_D locally. This can avoid the temporary traffic loop
when the failure happens on the egress node of the ring tunnel. This when the failure happens on the egress node of the ring tunnel. This
also illustrates one of the benefits of having separate working and also illustrates one of the benefits of having separate working and
protection ring tunnels in each ring direction. protection ring tunnels in each ring direction.
+---+#####[RaP_D(F)]######+---+ +---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1 | F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+ +---+*****[RcW_D(A)]******+---+
#/* *\# #/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
skipping to change at page 15, line 47 skipping to change at page 14, line 50
4.3.3. Steering 4.3.3. Steering
With steering protection mechanism, the ingress node (which adds With steering protection mechanism, the ingress node (which adds
traffic to the ring) perform switching from working to the protection traffic to the ring) perform switching from working to the protection
ring tunnel, and at the egress node the traffic leaves the ring from ring tunnel, and at the egress node the traffic leaves the ring from
the protection ring tunnel. the protection ring tunnel.
When a failure occurs in the ring, the node which detects the failure When a failure occurs in the ring, the node which detects the failure
via OAM mechanism sends the failure information in the opposite via OAM mechanism sends the failure information in the opposite
direction of the failure hop by hop along the ring using RPS request direction of the failure hop by hop along the ring using RPS request
message. When a ring node receives the RPS message which identifies message and the ring-map information. When a ring node receives the
a failure, it can quickly determine the location of the fault by RPS message which identifies a failure, it can determine the location
using the topology information that is maintained by the node and of the fault by using the topology information of the ring map and
update the ring map accordingly, then it can determine whether the update the ring map accordingly, then it can determine whether the
LSPs entering the ring locally need to switchover or not. For LSPs LSPs entering the ring locally need to switchover or not. For LSPs
that needs to switchover, it will switch the LSPs from the working that need to switchover, it will switch the LSPs from the working
ring tunnels to its corresponding protection ring tunnels. ring tunnels to its corresponding protection ring tunnels. The
transfer of the failure information by the RPS protocol will increase
the protection switch time.
4.3.3.1. Steering for Link Failure 4.3.3.1. Steering for Link Failure
Ring map of F +--LSPl Ring map of F +--LSPl
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+
|I|I|I|S|I|I| |I|I|S|I|I|I| |I|I|I|S|I|I| |I|I|S|I|I|I|
+-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+
[RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)]
skipping to change at page 16, line 40 skipping to change at page 15, line 45
----- physical links ***** RcW_D ##### RaP_D ----- physical links ***** RcW_D ##### RaP_D
I: Intact S: Severed I: Intact S: Severed
Figure 9. Steering operation and protection switching Figure 9. Steering operation and protection switching
As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2
enters the ring from Node B, and both of them have the same enters the ring from Node B, and both of them have the same
destination node D. destination node D.
In normal state, LSP1 is carried by the clockwise working ring tunnel In normal state, LSP1 is carried by the clockwise working ring tunnel
(RcW_D) through the path A->B->C->D, the label operation is: [LSP1] (RcW_D) through the path A->B->C->D, the label operation is:
-> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> [LSP1](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB)
[RcW_D(D)|LSP1](NodeC) -> [LSP1](data traffic carried by LSP1) . -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload) .
LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught
the path B->C->D, the label operation is: [LSP2] -> the path B->C->D, the label operation is: [LSP2](Payload) ->
[RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](data [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload) .
traffic carried by LSP2) .
If the link between nodes C and D fails, according to the fault If the link between nodes C and D fails, according to the fault
detection and distribution mechanisms, Node D will find out that detection and distribution mechanisms, Node D will find out that
there is a failure in the link between C and D, and it will update there is a failure in the link between C and D, and it will update
the link state of its ring topology, changing the link between C and the link state of its ring topology, changing the link between C and
D from normal to fault. In the direction that opposite to the D from normal to fault. In the direction that opposite to the
failure position, Node D will send the state report message to Node failure position, Node D will send the state report message to Node
E, informing Node E of the fault between C and D, and E will update E, informing Node E of the fault between C and D, and E will update
the link state of its ring topology accordingly, changing the link the link state of its ring topology accordingly, changing the link
between C and D from normal to fault. In this way, the state report between C and D from normal to fault. In this way, the state report
message is sent hop by hop in the clockwise direction. Similar to message is sent hop by hop in the clockwise direction. Similar to
Node D, Node C will send the failure information in the anti- Node D, Node C will send the failure information in the anti-
clockwise direction. clockwise direction.
When Node A receives the failure report message and updates the link When Node A receives the failure report message and updates the link
state of its ring topology, it is aware that there is a fault on the state of its ring map, it is aware that there is a fault on the
clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the
ring locally and is carried by this ring tunnel, thus Node A will ring locally and is carried by this ring tunnel, thus Node A will
decide to switch the LSP1 onto the anticlockwise protection ring decide to switch the LSP1 onto the anticlockwise protection ring
tunnel to node D (RaP_D). After the switchover, LSP1 will follow the tunnel to node D (RaP_D). After the switchover, LSP1 will follow the
path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| path A->F->E->D, the label operation is: [LSP1](Payload) ->
LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) ->
[LSP1](data traffic carried by LSP1). [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload).
The same procedure also applies to the operation of LSP2. When Node The same procedure also applies to the operation of LSP2. When Node
B updates the link state of its ring topology, and finds out that the B updates the link state of its ring topology, and finds out that the
working ring tunnel RcW_D has failed, it will switch the LSP2 to the working ring tunnel RcW_D has failed, it will switch the LSP2 to the
anticlockwise protection tunnel RaP_D. After the switchover, LSP2 anticlockwise protection tunnel RaP_D. After the switchover, LSP2
goes through the path B->A->F->E->D, and the label operation is: goes through the path B->A->F->E->D, and the label operation is:
[LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA)
[RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) ->
traffic carried by LSP2). [LSP2](Payload).
Assume the link between nodes A and B breaks down, as shown in Assume the link between nodes A and B breaks down, as shown in
Figure 10. Similar to the above failure case, Node B will detect a Figure 10. Similar to the above failure case, Node B will detect a
fault in the link between A and B, and it will update its ring map, fault in the link between A and B, and it will update its ring map,
changing the link state between A and B from normal to fault. The changing the link state between A and B from normal to fault. The
state report message is sent hop by hop in the clockwise direction, state report message is sent hop by hop in the clockwise direction,
notifying every node that there is a fault between node A and B, and notifying every node that there is a fault between node A and B, and
every node updates the link state of its ring topology. As a result, every node updates the link state of its ring topology. As a result,
Node A will detect a fault in the working ring tunnel to node D, and Node A will detect a fault in the working ring tunnel to node D, and
switch LSP1 to the protection ring tunnel, while Node B determine switch LSP1 to the protection ring tunnel, while Node B determine
skipping to change at page 20, line 9 skipping to change at page 19, line 9
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| F |------| E |------| D |------| J |------| I | | F |------| E |------| D |------| J |------| I |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Figure 12. Dual-node interconnected rings Figure 12. Dual-node interconnected rings
4.4.2. Interconnected Ring Protection Mechanisms 4.4.2. Interconnected Ring Protection Mechanisms
Interconnected rings can be treated as two independent rings. Ring Interconnected rings can be treated as two independent rings. Ring
protection switching (RPS) protocol operates on each ring protection switching (RPS) protocol operates on each ring
independently. Failure happened on one ring only triggers protection independently. A failure that happens in one ring only triggers
switching on the ring itself and does not affect the other ring, protection switching in the ring itself and does not affect the other
unless the failure is on the interconnection node. This way, ring, unless the failure is on the interconnection node. In this
protection switching on each ring is the same as the mechanisms way, protection switching on each ring is the same as the mechanisms
described in section 4.3. described in section 4.3.
The service LSPs that traverse the interconnected rings use seperate The service LSPs that traverse the interconnected rings use separate
ring tunnels on each ring, and the LSPs on different rings are ring tunnels on each ring, and the LSPs on different rings are
stitched by the interconnection node. On the interconnection node, stitched by the interconnection node. On the interconnection node,
the ring tunnel label of the source ring is popped, then LSP label is the ring tunnel label of the source ring is popped, then LSP label is
swapped, after that the ring tunnel label of the destination ring is swapped, after that the ring tunnel label of the destination ring is
pushed. pushed.
In the dual-node interconnected ring scenario, the two In the dual-node interconnected ring scenario, the two
interconnection nodes can be managed as a virtual node group. In interconnection nodes can be managed as a virtual node group. In
addition to the ring tunnels to each physical ring node, Each ring addition to the ring tunnels to each physical ring node, Each ring
SHOULD assign the working and protection ring tunnels to the virtual SHOULD assign the working and protection ring tunnels to the virtual
skipping to change at page 24, line 18 skipping to change at page 23, line 18
and consequently the service traffic LSP1 traverses the and consequently the service traffic LSP1 traverses the
interconnected rings at Node A. Node A will pop the ring tunnel interconnected rings at Node A. Node A will pop the ring tunnel
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 SHOULD communicate using the individual ring nodes that form the ring MUST communicate using
the G-ACh channel. the G-ACh channel. The described RPS protocol uses 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,
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
number of nodes on the ring supported by the RPS protocol is 127. number of nodes on the ring supported by the RPS protocol is 127.
The node ID SHOULD be independent of the order in which the nodes The node ID SHOULD be independent of the order in which the nodes
appear on the ring. The node ID is used to identity the source and appear on the ring. The node ID is used to identity the source and
skipping to change at page 25, line 23 skipping to change at page 24, line 30
-------| 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
request in opposite directions. request in opposite directions.
o In rings utilizing the wrapping protection. When the destination o In rings utilizing the wrapping protection, each node detects the
node receives the RPS request it MUST perform the switch from/to failure or receives the RPS request as the destination node MUST
the working ring tunnels to/from the protection ring tunnels if it perform the switch from/to the working ring tunnels to/from the
has no higher priority active RPS request. protection ring tunnels if it has no higher priority active RPS
request.
o In rings utilizing the short wrapping protection. Only the node o In rings utilizing the short wrapping protection, each node
which is directly upstream to the failure on the working ring detects the failure or receives the RPS request as the destination
tunnel perform the switch from the working ring tunnels to the node MUST perform the switch only from the working ring tunnels to
protection ring tunnels. This may be triggered by local failure the protection ring tunnels.
detection or the received RPS request.
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 maps (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 (tail end) and MUST source an RPS request carrying the NR
code. The node receiving from both directions such RPS request (head code. The node receiving from both directions such RPS request (head
end) MUST drop its protection switches. end) MUST drop its 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
skipping to change at page 26, line 33 skipping to change at page 25, line 39
5.1.1. Transmission and Acceptance of RPS Requests 5.1.1. Transmission and Acceptance of RPS Requests
A new RPS request MUST be transmitted immediately when a change in A new RPS request MUST be transmitted immediately when a change in
the transmitted status occurs. the transmitted status occurs.
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. 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
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 17 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. The ACH MUST NOT include the ACH TLV Header
[RFC5586] meaning that no ACH TLVs can be included in the 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|0 0 0 0|0 0 0 0 0 0 0 0| RPS Channel Type (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Node ID | Src Node ID | Request | 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
protection swithcing mode used by the sending node of the RPS
message. This can be used to check that the ring nodes on the
same ring use the same protecion switching mechanism. The defined
values of the M field are listed as below:
+------------------+-----------------------------+
| Bits (MSB-LSB) | Protecton Switching Mode |
+------------------+-----------------------------+
| 0 0 | Wrapping |
| 0 1 | Short Wrapping |
| 1 0 | Steering |
| 1 1 | Reserved |
+------------------+-----------------------------+
o RPS request code: A code consisting of eight bits as specified o RPS request code: A code consisting of eight bits as specified
below: below:
+------------------+-----------------------------+----------+ +------------------+-----------------------------+----------+
| Bits | Condition, State | Priority | | Bits | Condition, State | Priority |
| (MSB - LSB) | or external Request | | | (MSB - LSB) | or external Request | |
+------------------+-----------------------------+----------+ +------------------+-----------------------------+----------+
| 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest |
| 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | |
| 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | |
skipping to change at page 28, line 17 skipping to change at page 28, line 5
A node in the switching state MUST source RPS request to adjacent A node in the switching state MUST source RPS request to 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 A node in the switching state MUST terminate RPS requests flow in
both directions. both directions.
As soon as it receives an RPS request from the short path, the node As soon as it receives an RPS request from the short path, the node
to which it is addressed MUST acknowledge the RPS request by replying to which it is addressed MUST acknowledge the RPS request by replying
with the RR code on the short path, and with the received RPS request with the RR code on the short path, and with the received RPS request
code on the long path. Here the short path refers to the shorter code on the long path. Accordingly, if RR code is received from the
short path, then the RPS request sent by the same node over the long
path SHOULD be ignored. Here the short path refers to the shorter
span on the ring between the source and destination node of the RPS span on the ring between the source and destination node of the RPS
request, and the long path refers to the longer span on the ring request, and the long path refers to the longer span on the ring
between the source and destination node of the RPS request. between the source and destination node of the RPS request.
This rule refers to the unidirectional failure detection: the RR This rule refers to the unidirectional failure detection: the RR
SHOULD be issued only when the node does not detect the failure SHOULD be issued only when the node does not detect the failure
condition (i.e., the node is a head end), that is, it is not condition (i.e., the node is a head end), that is, it is not
applicable when a bidirectional failure is detected, because, in this applicable when a bidirectional failure is detected, because, in this
case, both nodes adjacent to the failure will send an RPS request for case, both nodes adjacent to the failure will send an RPS request for
the failure on both paths (short and long). the failure on both paths (short and long).
skipping to change at page 29, line 20 skipping to change at page 29, line 12
When a node is in a pass-through state, it MUST enable the traffic When a node is in a pass-through state, it MUST enable the traffic
flow on protection ring tunnels in both directions. flow on protection ring tunnels in both directions.
5.1.4. RPS State Transitions 5.1.4. RPS State Transitions
All state transitions are triggered by an incoming RPS request All state transitions are triggered by an incoming RPS request
change, a WTR expiration, an externally initiated command, or locally change, a WTR expiration, an externally initiated command, or locally
detected MPLS-TP section failure conditions. detected MPLS-TP section failure conditions.
RPS requests due to a locally detected failure, an externally RPS requests due to a locally detected failure, an externally
initiated command, or received RPS request shall pre-empt existing initiated command, or received RPS request shall preempt existing RPS
RPS requests in the prioritized order given in Section 5.1.2, unless requests in the prioritized order given in Section 5.1.2, unless the
the requests are allowed to coexist. requests are allowed to coexist.
5.1.4.1. Transitions Between Idle and Pass-through States 5.1.4.1. Transitions Between Idle and Pass-through States
The transition from the idle state to pass-through state MUST be The transition from the idle state to pass-through state MUST be
triggered by a valid RPS request change, in any direction, from the triggered by a valid RPS request change, in any direction, from the
NR code to any other code, as long as the new request is not destined NR code to any other code, as long as the new request is not destined
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.
skipping to change at page 32, line 45 skipping to change at page 32, line 32
Automatically initiated commands can be initiated based on MPLS-TP Automatically initiated commands can be initiated based on MPLS-TP
section layer OAM indication and the received switch requests. section layer OAM indication and the received switch requests.
The node can initiate the following switch requests automatically: The node can initiate the following switch requests automatically:
o Signal Fail (SF): This command is issued when the MPLS-TP section o Signal Fail (SF): This command is issued when the MPLS-TP section
layer OAM detects signal failure condition. layer OAM detects signal failure condition.
o Wait-To-Restore (WTR): This command is issued when MPLS-TP section o Wait-To-Restore (WTR): This command is issued when MPLS-TP section
detects that the SF condition has cleared. It is used to maintain detects that the SF condition has cleared. It is used to maintain
the state during the WTR period unless it is pre-empted by a the state during the WTR period unless it is preempted by a higher
higher priority switch request. The WTR time may be configured by priority switch request. The WTR time may be configured by the
the operator in 1 minute steps between 0 and 12 minutes; the operator in 1 minute steps between 0 and 12 minutes; the default
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
+-----------------------------------+----------------+ +-----------------------------------+----------------+
| 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-trough | N/A | | B | Pass-through | N/A |
| | Working: no switch | | | | Working: no switch | |
| | Protection: pass through | | | | Protection: pass through | |
+-----+-----------------------------+----------------+ +-----+-----------------------------+----------------+
| C | Switching - LP | LP | | C | Switching - LP | LP |
| | Working: no switch | | | | Working: no switch | |
| | Protection: no switch | | | | Protection: no switch | |
+-----+-----------------------------+----------------+ +-----+-----------------------------+----------------+
| D | Idle - LW | NR | | D | Idle - LW | NR |
| | Working: no switch | | | | Working: no switch | |
| | Protection: no switch | | | | Protection: no switch | |
skipping to change at page 34, line 25 skipping to change at page 34, line 16
FS E (Switching - FS) FS E (Switching - FS)
SF F (Switching - SF) SF F (Switching - SF)
Recover from SF N/A Recover from SF N/A
MS G (Switching - MS) MS G (Switching - MS)
Clear N/A Clear N/A
WTR expires N/A WTR expires N/A
EXER I (Switching - EXER) EXER I (Switching - EXER)
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
B (Pass-trough) LP C (Switching - LP) B (Pass-through) LP C (Switching - LP)
LW B (Pass-trough) LW B (Pass-through)
FS O - if current state is due to FS O - if current state is due to
LP sent by another node LP sent by another node
E (Switching - FS) - otherwise E (Switching - FS) - otherwise
SF O - if current state is due to SF O - if current state is due to
LP sent by another node LP sent by another node
F (Switching - SF) - otherwise F (Switching - SF) - otherwise
Recover from SF N/A Recover from SF N/A
MS O - if current state is due to MS O - if current state is due to
LP, SF or FS sent by LP, SF or FS sent by
another node another node
skipping to change at page 35, line 5 skipping to change at page 34, line 45
C (Switching - LP) LP N/A C (Switching - LP) LP N/A
LW O LW O
FS O FS O
SF O SF O
Recover from SF N/A Recover from SF N/A
MS O MS O
Clear A (Idle) - if there is no Clear A (Idle) - if there is no
failure in the ring failure in the ring
F (Switching - SF) - if there F (Switching - SF) - if there
is a failure at this node is a failure at this node
B (Pass-trough) - if there is B (Pass-through) - if there is
a failure at another node a failure at another node
WTR expires N/A WTR expires N/A
EXER O EXER O
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP) D (Idle - LW) LP C (Switching - LP)
LW N/A - if on the same span LW N/A - if on the same span
D (Idle - LW) - if on another D (Idle - LW) - if on another
span span
skipping to change at page 35, line 51 skipping to change at page 35, line 43
another span another span
SF O - if on the addressed span SF O - if on the addressed span
E (Switching - FS) - if on E (Switching - FS) - if on
another span another span
Recover from SF N/A Recover from SF N/A
MS O MS O
Clear A (Idle) - if there is no Clear A (Idle) - if there is no
failure in the ring failure in the ring
F (Switching - SF) - if there F (Switching - SF) - if there
is a failure at this node is a failure at this node
B (Pass-trough) - if there is B (Pass-through) - if there is
a failure at another node a failure at another node
WTR expires N/A WTR expires N/A
EXER O EXER O
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP) F (Switching - SF) LP C (Switching - LP)
LW O - if on another span LW O - if on another span
D (Idle - LW) - if on the same D (Idle - LW) - if on the same
span span
FS E (Switching - FS) FS E (Switching - FS)
SF N/A - if on the same span SF N/A - if on the same span
F (Switching - SF) - if on F (Switching - SF) - if on
another span another span
Recover from SF H (Switching - WTR) Recover from SF H (Switching - WTR)
MS O MS O
Clear N/A Clear N/A
WTR expires N/A WTR expires N/A
skipping to change at page 37, line 39 skipping to change at page 37, line 30
FS E (Switching - FS) FS E (Switching - FS)
SF F (Switching - SF) SF F (Switching - SF)
MS G (Switching - MS) MS G (Switching - MS)
WTR N/A WTR N/A
EXER I (Switching - EXER) EXER I (Switching - EXER)
RR N/A RR N/A
NR A (Idle) NR A (Idle)
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
B (Pass-trough) LP C (Switching - LP) B (Pass-through) LP C (Switching - LP)
FS N/A - cannot happen when there FS N/A - cannot happen when there
is LP request in the ring is LP request in the ring
E (Switching - FS) - otherwise E (Switching - FS) - otherwise
SF N/A - cannot happen when there SF N/A - cannot happen when there
is LP request in the ring is LP request in the ring
F (Switching - SF) - otherwise F (Switching - SF) - otherwise
MS N/A - cannot happen when there MS N/A - cannot happen when there
is LP, FS or SF request is LP, FS or SF request
in the ring in the ring
G (Switching - MS) - otherwise G (Switching - MS) - otherwise
skipping to change at page 40, line 17 skipping to change at page 40, line 14
5.2.5. State Transitions When Request Addresses to Another Node is 5.2.5. State Transitions When Request Addresses to Another Node is
Received Received
The priority of a remote request does not depend on the side from The priority of a remote request does not depend on the side from
which the request is received. which the request is received.
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
A (Idle) LP B (Pass-trough) A (Idle) LP B (Pass-through)
FS B (Pass-trough) FS B (Pass-through)
SF B (Pass-trough) SF B (Pass-through)
MS B (Pass-trough) MS B (Pass-through)
WTR B (Pass-trough) WTR B (Pass-through)
EXER B (Pass-trough) EXER B (Pass-through)
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
B (Pass-trough) LP B (Pass-trough) B (Pass-through) LP B (Pass-through)
FS N/A - cannot happen when there FS N/A - cannot happen when there
is LP request in the ring is LP request in the ring
B (Pass-trough) - otherwise B (Pass-through) - otherwise
SF N/A - cannot happen when there SF N/A - cannot happen when there
is LP request in the ring is LP request in the ring
B (Pass-trough) - otherwise B (Pass-through) - otherwise
MS N/A - cannot happen when there MS N/A - cannot happen when there
is LP, FS or SF request is LP, FS or SF request
in the ring in the ring
B (Pass-trough) - otherwise B (Pass-through) - otherwise
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is LP, FS, SF or MS is LP, FS, SF or MS
request in the ring request in the ring
B (Pass-trough) - otherwise B (Pass-through) - otherwise
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is LP, FS, SF, MS or WTR is LP, FS, SF, MS or WTR
request in the ring request in the ring
B (Pass-trough) - otherwise B (Pass-through) - otherwise
RR N/A RR N/A
NR B (Pass-trough) NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP) C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there FS N/A - cannot happen when there
is LP request in the ring is LP request in the ring
SF N/A - cannot happen when there SF N/A - cannot happen when there
is LP request in the ring is LP request in the ring
MS N/A - cannot happen when there MS N/A - cannot happen when there
is LP request in the ring is LP request in the ring
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is LP in the ring is LP in the ring
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is LP request in the ring is LP request in the ring
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
D (Idle - LW) LP B (Pass-trough) D (Idle - LW) LP B (Pass-through)
FS B (Pass-trough) FS B (Pass-through)
SF B (Pass-trough) SF B (Pass-through)
MS B (Pass-trough) MS B (Pass-through)
WTR B (Pass-trough) WTR B (Pass-through)
EXER B (Pass-trough) EXER B (Pass-through)
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
E (Switching - FS) LP B (Pass-trough) E (Switching - FS) LP B (Pass-through)
FS E (Switching - FS) FS E (Switching - FS)
SF E (Switching - FS) SF E (Switching - FS)
MS N/A - cannot happen when there MS N/A - cannot happen when there
is FS request in the ring is FS request in the ring
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is FS request in the ring is FS request in the ring
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is FS request in the ring is FS request in the ring
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
F (Switching - SF) LP B (Pass-trough) F (Switching - SF) LP B (Pass-through)
FS F (Switching - SF) FS F (Switching - SF)
SF F (Switching - SF) SF F (Switching - SF)
MS N/A - cannot happen when there MS N/A - cannot happen when there
is SF request in the ring is SF request in the ring
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is SF request in the ring is SF request in the ring
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is SF request in the ring is SF request in the ring
RR N/A RR N/A
NR N/A NR N/A
skipping to change at page 42, line 9 skipping to change at page 42, line 4
FS F (Switching - SF) FS F (Switching - SF)
SF F (Switching - SF) SF F (Switching - SF)
MS N/A - cannot happen when there MS N/A - cannot happen when there
is SF request in the ring is SF request in the ring
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is SF request in the ring is SF request in the ring
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is SF request in the ring is SF request in the ring
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
G (Switching - MS) LP B (Pass-trough) G (Switching - MS) LP B (Pass-through)
FS B (Pass-trough) FS B (Pass-through)
SF B (Pass-trough) SF B (Pass-through)
MS G (Switching - MS) - release MS G (Switching - MS) - release
the switches but signal MS the switches but signal MS
WTR N/A - cannot happen when there WTR N/A - cannot happen when there
is MS request in the ring is MS request in the ring
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is MS request in the ring is MS request in the ring
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
------------- ----------- --------- ------------- ----------- ---------
H (Switching - WTR) LP B (Pass-trough) H (Switching - WTR) LP B (Pass-through)
FS B (Pass-trough) FS B (Pass-through)
SF B (Pass-trough) SF B (Pass-through)
MS B (Pass-trough) MS B (Pass-through)
WTR N/A WTR N/A
EXER N/A - cannot happen when there EXER N/A - cannot happen when there
is WTR request in the ring is WTR request in the ring
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
Initial state New request New state Initial state New request New state
I (Switching - EXER) LP B (Pass-trough) I (Switching - EXER) LP B (Pass-through)
FS B (Pass-trough) FS B (Pass-through)
SF B (Pass-trough) SF B (Pass-through)
MS B (Pass-trough) MS B (Pass-through)
WTR N/A WTR N/A
EXER I (Switching - EXER) EXER I (Switching - EXER)
RR N/A RR N/A
NR N/A NR N/A
===================================================================== =====================================================================
5.3. RPS and PSC Comparison on Ring Topology 5.3. RPS and PSC Comparison on Ring Topology
This section provides comparison between RPS and PSC [RFC6378] This section provides comparison between RPS and PSC [RFC6378]
[RFC6974] on ring topologies. This can be helpful to explain the [RFC6974] on ring topologies. This can be helpful to explain the
skipping to change at page 43, line 48 skipping to change at page 43, line 38
this way, every ring-node only needs to be configured with 2 MEPs. this way, every ring-node only needs to be configured with 2 MEPs.
As shown in the above example, RPS is designed for ring topologies As shown in the above example, RPS is designed for ring topologies
and can achieve ring protection efficiently with minimum protection and can achieve ring protection efficiently with minimum protection
instances and OAM entities, which meets the requirements on topology instances and OAM entities, which meets the requirements on topology
specific recovery mechanisms as specified in [RFC5654]. specific recovery mechanisms as specified in [RFC5654].
6. IANA Considerations 6. IANA Considerations
IANA is requested to administer the assignment of new values defined IANA is requested to administer the assignment of new values defined
in this document and summarized in this section. in this document and listed in the sections below.
6.1. G-ACh Channel Type 6.1. G-ACh Channel Type
The Channel Types for the Generic Associated Channel (GACH) are The Channel Types for the Generic Associated channel (GACh) are
allocated from the IANA PW Associated Channel Type registry defined allocated from the IANA PW Associated Channel Type registry defined
in [RFC4446] and updated by [RFC5586]. in [RFC4446] and updated by [RFC5586].
IANA is requested to allocate a new GACH Channel Type as follows: IANA is requested to allocate a new GACH Channel Type as follows:
Value| Description | Reference Value| Description | Reference
------+---------------------------+-------------- ------+---------------------------+--------------
TBD | Ring Protection Switching |this document TBD | Ring Protection Switching |this document
| Protocol (RPS) | | Protocol (RPS) |
------+---------------------------+-------------- ------+---------------------------+--------------
6.2. RSP Request Codes 6.2. RPS Request Codes
IANA is requested to create a new sub-registry under the IANA is requested to create a new sub-registry under the
"Multiprotocol Label Switching (MPLS) Operations, Administration, and "Multiprotocol Label Switching (MPLS) Operations, Administration, and
Management (OAM) Parameters" registry called the "MPLS RPS Request Management (OAM) Parameters" registry called the "MPLS RPS Request
Code Registry". All code points within this registry shall be Code Registry". All code points within this registry shall be
allocated according to the "Standards Action" procedure as specified allocated according to the "Standards Action" procedure as specified
in [RFC5226]. in [RFC5226].
The RPS Request Field is 8 bits, the allocated values are as follows: The RPS Request Field is 8 bits, the allocated values are as follows:
Value Description Reference Value Description Reference
------- --------------------------- --------------- ------- --------------------------- ---------------
0 No Request (NR) this document 0 No Request (NR) this document
1 Reverse Request (RR) this document 1 Reverse Request (RR) this document
2 not assigned 2 unassigned
3 Exercise (EXER) this document 3 Exercise (EXER) this document
4 not assigned 4 unassigned
5 Wait-To-Restore (WTR) this document 5 Wait-To-Restore (WTR) this document
6 Manual Switch (MS) this document 6 Manual Switch (MS) this document
7-10 not assigned 7-10 unassigned
11 Signal Fail (SF) this document 11 Signal Fail (SF) this document
12 not assigned 12 unassigned
13 Forced Switch (FS) this document 13 Forced Switch (FS) this document
14 not assigned 14 unassigned
15 Lockout of Protection (LP) this document 15 Lockout of Protection (LP) this document
16-255 not assigned 16-254 unassigned
255 Reserved
7. Security Considerations 7. Security Considerations
The RPS protocol defined in this document is carried in the G-ACh The RPS protocol defined in this document is carried in the G-ACh
[RFC5586], which is a generalization of the Associated Channel [RFC5586], which is a generalization of the Associated Channel
defined in [RFC4385]. The security considerations specified in these defined in [RFC4385]. The security considerations specified in these
documents apply to the proposed RPS mechanism. documents apply to the proposed RPS mechanism.
8. Contributing Authors 8. Contributing Authors
Kai Liu
Huawei Technologies
Email: alex.liukai@huawei.com
Wen Ye, Minxue Wang, Sheng Liu (China Mobile) Jia He
Huawei Technologies
Email: hejia@huawei.com
Guanghui Sun (Huawei) Fang Li
China Academy of Telecommunication Research MIIT., China
Email: lifang@catr.cn
Jian Yang
ZTE Corporation P.R.China
Email: yang.jian90@zte.com.cn
Junfang Wang
Fiberhome Telecommunication Technologies Co., LTD.
Email: wjf@fiberhome.com.cn
Wen Ye
China Mobile
Email: yewen@chinamobile.com
Minxue Wang
China Mobile
Email: wangminxue@chinamobile.com
Sheng Liu
China Mobile
Email: liusheng@chinamobile.com
Guanghui Sun
Huawei Technologies
Email: sunguanghui@huawei.com
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Gregory Mirsky, Yimin Shen, Eric The authors would like to thank Gregory Mirsky, Yimin Shen, Eric
Osborne and Spencer Jackson for their valuable comments and Osborne, Spencer Jackson and Eric Gray for their valuable comments
suggestions. and suggestions.
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
skipping to change at page 47, line 4 skipping to change at page 47, line 32
Han Li Han Li
China Mobile China Mobile
Email: lihan@chinamobile.com Email: lihan@chinamobile.com
Huub van Helvoort Huub van Helvoort
Hai Gaoming BV Hai Gaoming BV
Email: huubatwork@gmail.com Email: huubatwork@gmail.com
Kai Liu
Huawei Technologies
Email: alex.liukai@huawei.com
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Jia He
Huawei Technologies
Email: hejia@huawei.com
Fang Li
China Academy of Telecommunication Research, MIIT., China
Email: lifang@ritt.cn
Jian Yang
ZTE Corporation P.R.China
Email: yang.jian90@zte.com.cn
Junfang Wang
Fiberhome Telecommunication Technologies Co., LTD.
Email: wjf@fiberhome.com.cn
 End of changes. 123 change blocks. 
332 lines changed or deleted 363 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/