Network Working Group WQ. Cheng
Internet-Draft L. Wang
Intended status: Standards Track H. Li
Expires: January 3, 2015 China Mobile
H. van Helvoort
K. Liu
J. He
Huawei Technologies Co., Ltd.
F. Li
China Academy of Telecommunication Research, MIIT., China
J. Yang
ZTE Corporation P.R.China
JF. Wang
Fiberhome Telecommunication Technologies Co., LTD.
July 02, 2014
MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology
draft-cheng-mpls-tp-shared-ring-protection-02
Abstract
This document describes requirements and solutions for MPLS-TP Shared
Ring Protection (MSRP) in the ring topology for point-to-point (P2P)
services. The mechanism of MSRP is illustrated and analyzed how it
satisfies the requirements in RFC6564 [RFC5654] for optimized ring
protection.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Cheng, et al. Expires January 3, 2015 [Page 1]
Internet-Draft MSRP July 2014
This Internet-Draft will expire on January 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements for MPLS-TP ring protection . . . . . . . . 4
1.1.1. Recovery for Multiple failures . . . . . . . . . . . 4
1.1.2. Smooth Upgrade from linear protection to ring
protection . . . . . . . . . . . . . . . . . . . . . 4
1.1.3. Configuration complexity . . . . . . . . . . . . . . 4
1.2. Terminology and Notation . . . . . . . . . . . . . . . . 5
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 5
2. Shared-ring protection for P2P . . . . . . . . . . . . . . . 5
2.1. Basic concept . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. The establishment of the Ring tunnels . . . . . . . . 6
2.1.2. The distribution and management of ring labels . . . 8
2.1.3. Failure detection . . . . . . . . . . . . . . . . . . 9
2.2. P2P wrapping . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Wrapping for Link Failure . . . . . . . . . . . . . . 10
2.2.2. Wrapping for node Failure . . . . . . . . . . . . . . 10
2.3. P2P short wrapping . . . . . . . . . . . . . . . . . . . 11
2.4. P2P steering . . . . . . . . . . . . . . . . . . . . . . 12
2.5. P2P wrapping for Interconnected Rings . . . . . . . . . . 15
2.5.1. Interconnected ring topology . . . . . . . . . . . . 15
2.5.2. Interconnected ring protection scheme . . . . . . . . 16
3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 21
3.1. RPS protocol . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1. Transmission and acceptance of RPS requests . . . . . 23
3.1.2. RPS PDU structure . . . . . . . . . . . . . . . . . . 23
3.1.3. Ring node RPS states . . . . . . . . . . . . . . . . 24
3.1.4. RPS state transitions . . . . . . . . . . . . . . . . 26
3.2. APS state machine . . . . . . . . . . . . . . . . . . . . 28
3.2.1. Initial states . . . . . . . . . . . . . . . . . . . 28
Cheng, et al. Expires January 3, 2015 [Page 2]
Internet-Draft MSRP July 2014
3.2.2. State transitions when local request is applied . . . 29
3.2.3. State transitions when remote request is applied . . 33
3.2.4. State Transitions when request addresses to another
node is received . . . . . . . . . . . . . . 35
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
6. Normative Refereces . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
As described in 2.5.6.1. ring protection of MPLS-TP requirements
RFC5654 [RFC5654], several service providers have expressed much
interest in operating MPLS-TP in ring topologies and required a high-
level survivability function in these topologies. In operation
network deployment, MPLS-TP networks are often constructed with ring
topologies. It calls for an efficient and optimized ring protection
mechanism to achieve simplified operation and fast recovery
performance.
The requirements for MPLS-TPRFC5654 [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
c. Minimize the required label number
d. Minimize the amount of control and management-plane transactions
e. Minimize the impact on information exchange if the control plane
supports
This document specifies MPLS-TP Shared-Ring Protection mechanisms
which can meet all those requirements on ring protection listed in
RFC5654 [RFC5654].
This document focus on the solutions for point-to-point transport
path. The solution for point-to-multipoint transport is under study
and will be presented in a separate document. The basic concept
stated in this document also apply to point-multipoint transport
path.
Cheng, et al. Expires January 3, 2015 [Page 3]
Internet-Draft MSRP July 2014
1.1. Requirements for MPLS-TP ring protection
The requirements for MPLS-TP ring protection are specified in RFC5654
[RFC5654]. This document elaborates the requirements in detail.
1.1.1. Recovery for Multiple failures
MPLS-TP is expected to be used in carrier grade metro networks and
backbone networks to provide mobile backhaul, carry business
customers' services and etc., in which the network survivability is
very important. According to R106 B in RFC5654 [RFC5654], MPLS-TP
recovery mechanisms in a ring SHOULD protect against multiple
failures. The following context provides some more detailed
illustration about "multiple failures". In metro and backbone
networks, the single risk factor often affects multiple links or
nodes. Some examples of risk factors are given as follows:
- multiple links using fibers in one cable or pipeline
- Several nodes shared one power supply system
- weather sensitive micro-wave system
Once one of the above risk factors happens, multiple links or nodes
failures may occur simultaneously and those failed links or nodes may
locate on a single ring as well as on interconnected rings. Ring
protection against multiple failures should cover both multiple
failures on a single ring and multiple failures on interconnected
rings.
1.1.2. Smooth Upgrade from linear protection to ring protection
It is beneficial for service providers to upgrade protection scheme
from linear protection to ring protection in their MPLS-TP network
without service interruption. In-service insertion and removal of a
node on the ring should also be supported. Therefore, the MPLS-TP
ring protection mechanism is supposed be developed and optimized to
comply with this smooth upgrading principle.
1.1.3. Configuration complexity
While deploying linear protection in MPLS-TP networks, the
configuration effort of protection depends on the quantity of the
services carried. In some large metro networks with more than ten
thousand services access, the LSP linear protection capabilities of
the metro core nodes should be large enough to meet the network
planning requirements, which also leads to the complexity of network
protection configuration and operation. While ring protection can
Cheng, et al. Expires January 3, 2015 [Page 4]
Internet-Draft MSRP July 2014
reduce the dependency of configuration on the quantity of services,
it will simplify the network protection configuration and operation
effort.In the application scenarios of deploying linear protection in
MPLS-TP network, the configuration of protection has close
relationship with the services, LSP quantities. Especially in some
large metro networks with more than ten thousands of services access
node, the LSP linear protection capabilities of the metro core nodes
should be large enough to meet the network planning requirements,
which also leads to the complexity of network protection
configurations and operations. While the ring protection is based on
the mechanisms on section layer, it has loose relationship with the
services quantities which could simplify the network protection
configurations and operations effort.
1.2. Terminology and Notation
The following syntax will be used to describe the contents of the
label stack:
1. The label stack will be enclosed in square brackets ("[]").
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.
3. If the Label is assigned by Node x, the Node Name will enclosed
in bracket(" ()")
1.3. Contributing Authors
Wen Ye,Minxue Wang,Sheng Liu (China Mobile)
2. Shared-ring protection for P2P
2.1. Basic concept
This document introduces a novel logic layer of the ring for both
working path and protection path for shared ring protection in MPLS-
TP networks. As shown in Figure 1, the new logic layer is a ring
tunnel on top of the working path or the protection path, namely
working ring tunnel and protection ring tunnel respectively. Once a
ring tunnel is established, the configuration, management and
protection of the ring are all based on the ring tunnel. One port
can carry multiple ring tunnels, while one ring tunnel can carry
multiple LSPs.
Cheng, et al. Expires January 3, 2015 [Page 5]
Internet-Draft MSRP July 2014
|-------------
|-------------|
|-------------| |
=====PW1======| | |
| | Ring | Physical
=====PW2======| LSP | Tunnel | Port
| | |
=====PW3======| | |
|-------------| |
|-------------|
|-------------
Figure 1 the logic layers of the ring
The label stack used in MPLS-TP Shared Ring Protection mechanism is
shown as below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Label stack used in MPLS-TP Shared Ring Protection
2.1.1. The establishment of the Ring tunnels
LSPs which have same exit node share the same ring tunnel. The exit
node is the node where the traffic leaves the ring. In other words,
all the LSPs that traverse the ring and exit from the same node share
the same working ring tunnel and protection ring tunnel. For each
exit node, four ring tunnels are established:
- one clockwise working ring tunnel, which is protected by the
following protection tunnel,
- one anticlockwise protection ring tunnel,
- one anticlockwise working ring tunnel, which is protected by the
following protection tunnel,
- one clockwise protection ring tunnel.
Cheng, et al. Expires January 3, 2015 [Page 6]
Internet-Draft MSRP July 2014
An example is shown in Figure 3 where Node D is the exit node. LSP
1, LSP 2 and LSP 3 enter the ring from Node E, Node A and Node B,
respectively, and all leave the ring from Node D. To protect these
LSPs that traverse the ring, a clockwise working ring tunnel (RcW_D)
via E->F->A->B->C->D, and its protection ring tunnel in the reverse
direction (RaP_D) via D->C->B->A->F->E->D are established,
respectively; Also, an anti-clockwise working ring tunnel (RaW_D) via
C->B->A->F->E->D, and its clockwise protection ring tunnel (RcP_D)
via D->E->F->A->B->C->D are established, respectively. Figure 3 only
shows RcW_D and RaP_D. A similar provisioning should be applied for
any other node on the ring. For other nodes in Figure 3 when acting
as an exit node, the ring tunnels are created as follows:
To Node A: RcW_A, RaW_A, RcP_A, RaP_A;
To Node B: RcW_B, RaW_B, RcP_B, RaP_B;
To Node C: RcW_C, RaW_C, RcP_C, RaP_C;
To Node E: RcW_E, RaW_E, RcP_E, RaP_E;
To Node F: RcW_F, RaW_F, RcP_F, RaP_F;
For exit Node D, two working ring tunnels, RcW_D and RaW_D, are
terminated on Node D, and two protection ring tunnels, RcP_D and
RaP_D, are started from Node D. That means through these working
ring tunnels with protection ring tunnels, LSPs which enter the ring
from Node D can reach any other nodes on the ring, while Node D can
also receive the traffic from any other nodes.
Cheng, et al. Expires January 3, 2015 [Page 7]
Internet-Draft MSRP July 2014
+---+#############+---+
| F |-------------| A | +-- LSP2
+---+*************+---+
#/* *\#
#/* *\#
#/* *\#
+---+ +---+
LSP1-+ | E | | B |+-- LSP3
+---+ +---+
#\ */#
#\ */#
#\ */#
+---+*************+---+
LSP1 +--| D |-------------| C |
LSP2 +---+ +---+
LSP3
---- physical links
**** RcW_D
#### RaP_D
Figure 3 Ring tunnels in MSRP
2.1.2. The distribution and management of ring labels
Ring tunnel labels are distributed by means of downstream-assigned
mechanism as defined in RFC5654 [RFC3031]. When a MPLS-TP transport
path, such as LSP, enters the ring, the ingress node pushes the
working ring tunnel label and sends the traffic to the next hop
according to the ring ID and the exit node. The transit nodes within
the working ring tunnel swap ring tunnel labels and forward the
packets to the next hop; When arriving at the egress node, the egress
node removes the ring tunnel label and forwards the packets based on
the inner LSP label and PW label. Figure 4 shows the label operation
in the MPLS- TP shared ring protection mechanism. Assume that LSP 1
enters the ring at Node A and exits from Node D, and the following
label operations are executed.
1. The traffic LSP1 arrives at Node A with a label stack [LSP1] and
is supposed to be forwarded in the clockwise direction 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 Node A is changed to
[RcW_D(B)|LSP1]
2. Transit nodes, in this case, Node B and Node C forward the
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 B.
Cheng, et al. Expires January 3, 2015 [Page 8]
Internet-Draft MSRP July 2014
3. When the packet arrives at Node D (i.e. egress node) with label
stack [RcW_D(D)|LSP1], Node D removes RcW_D(D), and subsequently
deals with the inner labels of LSP1.
4. All the LSPs which exit from the same node share the same set of
ring tunnel labels.
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)]
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ */#
[RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)]
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links ****** RcW_D ###### RaP_D
Figure 4 Label operation of MSRP
2.1.3. Failure detection
The MPLS-TP section layer OAM is used to monitor the connectivity
between each two adjacent nodes on the ring using the mechanisms
defined in RFC6371 [RFC6371]. Protection switching is triggered by
the failure detection in a link in the ring monitored by OAM
functions.
Two end ports of a link form an MEG, and an MEG end point (MEP)
function is installed in each ring port. CC-V OAM packets are
periodically exchanged between each pair of MEPs to monitor the link
health. Consecutive losses of CC-V packets (3 packets) will be
interpreted as a link failure.
A node failure is regarded as the failure of two links attached to
the node. The two nodes adjacent to the failed node detect the
failure in the links that are connected to the failed node.
2.2. P2P wrapping
Normal state is shown in Figure 4. The clockwise LSP1 towards node D
enters the ring at Node A. In normal state, LSP 1 follows the path
A->B->C-D, label operation is [LSP1](original data traffic carried by
Cheng, et al. Expires January 3, 2015 [Page 9]
Internet-Draft MSRP July 2014
LSP 1)->[RCW_D(B)|LSP1](NodeA)->[RCW_D(C)|LSP1](NodeB)->[RCW_D(D)|
LSP1](NodeC)->[LSP1]( data traffic carried by LSP 1). Then traffic
packet will be forwarded based on LSP1 at nodeD.
2.2.1. Wrapping for Link Failure
When a link failure between Node B and Node C occurs, both Node B and
Node C detect the failure by OAM mechanism. Node B switches the
clockwise working ring tunnel (RcW_D) to the anticlockwise protection
ring tunnel (RaP_D) and Node C switches anticlockwise protection ring
tunnel(RaP_D) to the clockwisework ring tunnel(RcW_D). The data
traffic which enters the ring at Node A and exits at Node D follows
the path A->B->A->F->E->D->C->D. The label operation is
[LSP1](Original data traffic)-> [RcW_D(B)|LSP1](Node A)->
[RaP_D(A)|LSP1](Node B)->[RaP_D(F)|LSP1](Node A)->[RaP_D(E)|LSP1]
(Node F)->[RaP_D(D)|LSP1] (Node E)-> [RaP_D(C)|LSP1] (Node D)->
[RcW_D(D)|LSP1](Node C)->[LSP1](Data traffic exits the ring).
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links xxxx Failure Link
****** RcW_D ###### RaP_D
Figure 5 P2P wrapping for link failure in a single ring
2.2.2. Wrapping for node Failure
When Node B fails, Node A detects the failure between A and B and
switches the clockwise work ring tunnel(RcW_D) to the anticlockwise
protection ring tunnel(RaP_D), Node C detects the failure between C
and B and switches the anticlockwise protection ring tunnel(RaP_D) to
the clockwise working ring tunnel(RcW_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 [LSP1](original data
traffic carried by LSP 1)->
[RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->
Cheng, et al. Expires January 3, 2015 [Page 10]
Internet-Draft MSRP July 2014
[RaP_D(D)|LSP1](NodeE)-> [RaP_D(C)|LSP1] (NodeD)->[RcW_D(D)|LSP1]
(NodeC)->[LSP1](data traffic carried by LSP 1).
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ xxxxx
| E | x B x
+---+ xxxxx
#\ */#
[RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B)
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
-----physical links xxxxxx Failure Node
*****RcW_D ###### RaP_D
Figure 6 P2P wrapping for node failure in a single ring
2.3. P2P short wrapping
For traditional wrapping protection scheme, Protection switching
execute at both nodes neighbored failure respectively , so the
traffic will be wrapped twice. This mechanism will cause more
latency and bandwidth consume when traffic switched to protection
path.
For Short wrapping protection, switching only execute at up-stream
node neighbored failure node, and exited ring in protection ring
tunnel. This scheme can optimized latency and bandwidth consume when
traffic switched to protection path.
In traditional wrapping solution, protection ring tunnel is a closed
path in normal state, while in short wrapping solution, protection
ring tunnel will remove at exit node. Short wrapping is easy to
implement in shared ring protection because the working and
protection ring tunnel is established base on exit nodes.
As show in figure 7, the data traffic which enters the ring at Node A
and exits at Node D follows the path A->B->C->D in normal state.
When a link failure between Node B and Node C occurs, NodeB switched
work ring tunnel RcW_D to opposite protection ring tunnel RaP_D same
as traditionally wrapping. The different occurs in protection ring
tunnel at exit node. In short wrapping protection, Rap_D will remove
in Node D and deal with inner LSP label. So LSP1 will follows the
Cheng, et al. Expires January 3, 2015 [Page 11]
Internet-Draft MSRP July 2014
path A->B->A->F->E->D when link failure between Node B and Node C
when using short wrapping.
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+ +---+
-----physical links xxxx Failure Link
****** RcW_D ###### RaP_D
Figure 7 P2P short wrapping for link failure
2.4. P2P steering
Each working ring tunnel is associated with a protection ring tunnel
in the opposite direction. Every node needs to know the ring
topology by configuration or topology discovery. When the failure
occurs in the ring, the nodes which detect the failure will spread
the failure information in the opposite direction node by node in the
ring respectively. When the node receives the message that informs
the failure, it will quickly figure out the location of the fault by
the topology information that is maintained by itself, so that it
will determine whether the LSPs enter the ring from itself needs
switch-over. If yes, it will switch the LSPs from the working ring
tunnel to its protection ring tunnel.
Cheng, et al. Expires January 3, 2015 [Page 12]
Internet-Draft MSRP July 2014
+--LSP l
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---+ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+
|I|I|I|S|I|I| |I|I|S|I|I|I|
+-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+
[RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)]
#/* [RcW_D(F)] *\#
+-+-+-+-+-+-+-+ #/* *\#
|E|F|A|B|C|D|E| +---+ +---+ +-- LSP 2
+-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+
|I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B|
+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
#\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I|
[RaP_D(D)] #\* */# +-+-+-+-+-+-+
#\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ LSP 1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+
|I|I|I|I|I|S| LSP 2 |S|I|I|I|I|I|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
----- physical links ***** RcW_D ##### RaP_D
Figure 8 P2P steering operation and protection switching (1)
Steering Example is shown in Figure 8. LSP1 enters the ring from
Node A while LSP2 enters the ring from Node B, and both of them have
the same destination node D. As Figure 8 shows, in the normal state,
LSP1 follows the path A->B->C->D, the label operation is
[LSP1](original data traffic carried by LSP 1
)->[RcW_D(B)|LSP1](NodeA)->[RcW_D(C)|
LSP1](NodeB)->[RcW_D(D)|LSP1](NodeC)->[LSP1] ( data traffic carried
by LSP 1) . LSP2 goes through the path B->C->D, the label operation
is [LSP2]->[RcW_D(C)|LSP2](NodeB)->[RcW_D(D)|LSP2](NodeC)-> [LSP2] (
data traffic carried by LSP 1) .
If the link between C and D breaks down, as Figure 8 shows, according
to the fault detection function of each link, Node D will find out
that 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 state
between C and D from normal to fault, as Figure 8 shows. In the
direction that goes away from the failure point, 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 the link state of its ring topology,
changing the link state between C and D from normal to fault. In
this manner, the state report message is sent node by node in the
clockwise direction. Similar to Node D, Node C will spread the
failure information in the anti-clockwise direction.
Cheng, et al. Expires January 3, 2015 [Page 13]
Internet-Draft MSRP July 2014
Until Node A updates the link state of its ring topology and be aware
of there is a fault within its working path, it can reach the
conclusion that the anticlockwise path from A to D is working all
right, and thus Node A will switch the LSP1 operation to the
anticlockwise ring tunnel.
LSP1 will follow the path A->F->E->D, the label operation is
[LSP1](original data traffic carried by LSP 1 )->[RaP_D(F)|
LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->[RaP_D(D)|LSP1](NodeE)->[LSP1]
( data traffic carried by LSP 1).
The same also apply to the operation of LSP2. When Node B updates
the link state of its ring topology, and finds out the working path
fault, it will stop sending the LSP2 operation in the clockwise
direction and switch the LSP2 to the anticlockwise protection tunnel.
LSP2 goes through the path B->A->F->E->D, and the label operation is
[LSP2](original data traffic carried by LSP 2 )-> [RaP_D(A)|LSP2](Nod
eB)->[RaP_D(F)|LSP2](NodeA)->[RaP_D(E)|LSP2](NodeF)->[RaP_D(D)|LSP2](
NodeE)->[LSP2]( data traffic carried by LSP 2).
Assume that the ring between A and B breaks down, as Figure 9 shows.
Like above, Node B will find out that there is a fault in the link
between A and B, and it will update the link state of its ring
topology, changing the link state between A and B from normal to
fault. The state report message is sent node by node in the
clockwise direction, informing every node that there is a fault
between node A and B, so that every node updates the link state of
its ring topology. Node A will find out a fault in the working path
of LSP1, and switch LSP1 to the protection Ring tunnel, while Node B
will find out the LSP2 working path is all right and there is no need
for switching.
Cheng, et al. Expires January 3, 2015 [Page 14]
Internet-Draft MSRP July 2014
+-- LSP l
+-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---+ +-+-+-+-+-+-+-+
|F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A|
+-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+
|I|S|I|I|I|I| #/* x |S|I|I|I|I|I|
+-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+
[RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)]
#/* x +-- LSP 2
+-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+
|E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B|
+-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+
|I|I|S|I|I|I| #\* */# |I|I|I|I|I|S|
+-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+
[RaP_D(D)] #\* */# [RaP_D(B)]
+-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+
|D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C|
+-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+
|I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I|
+-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+
----- physical links ***** RcW_D ##### RaP_D
Figure 9 the P2P steering operation and protection switching (2)
2.5. P2P wrapping for Interconnected Rings
2.5.1. Interconnected ring topology
Interconnected ring topology is often used in MPLS-TP networks.
There are two typical interconnected ring topologies that will be
addressed in this document.
1) Single-node interconnected rings
In single-node interconnected rings, the connection between two rings
is through a single node. As the interconnection node may cause a
single point of failure, this topology should be avoided in real
networks;
2) Dual-node interconnected rings
In dual-node interconnected rings, the connection between two rings
is through two nodes. The two interconnection nodes belong to both
interconnected rings. This topology can recover from one
interconnection node failure.
Cheng, et al. Expires January 3, 2015 [Page 15]
Internet-Draft MSRP July 2014
2.5.1.1. Single-node interconnected rings
Figure 10 shows the topology of single-node interconnected rings.
Node C is interconnection node between Ring1 and Ring2.
+---+ +---+ +---+ +---+
| A |----------| B |------ ------| G |----------| H |
+---+ +---+ \ / +---+ +---+
| \ / |
| \ +---+ / |
| Ring1 | C | Ring2 |
| / +---+ \ |
| / \ |
+---+ +---+ / \ +---+ +---+
| F |----------| E |------ ------| J |----------| I |
+---+ +---+ +---+ +---+
Figure 10 Single-node interconnected rings
2.5.1.2. Dual-node interconnected rings
Figure 11 shows the topology of dual-node interconnected rings. Node
C and Node D are interconnection nodes between Ring1 and Ring2.
+---+ +---+ +---+ +---+ +---+
| A |----------| B |----------| C |----------| G |----------| H |
+---+ +---+ +---+ +---+ +---+
| | | |
| | | |
| Ring1 | | Ring2 |
| | | |
| | | |
+---+ +---+ +---+ +---+ +---+
| F |----------| E |----------| D |----------| J |----------| I |
+---+ +---+ +---+ +---+ +---+
Figure 11 Dual-node interconnected rings
2.5.2. Interconnected ring protection scheme
2.5.2.1. Introduction
- Interconnected rings can be regarded as two independent rings.
Each ring runs protection switching independently. Failure in one
ring only triggers protection switching in itself and does not affect
the other ring. Protection switch in a single ring is same as which
described in section 3 Shared ring protection for P2P.
Cheng, et al. Expires January 3, 2015 [Page 16]
Internet-Draft MSRP July 2014
- The service LSPs that traverse the interconnected rings via the
interconnection nodes must use different ring tunnels in different
rings. The ring tunnel used in the source ring will be removed, and
the ring tunnel of destination ring will be added in interconnection
nodes.
- For protected interconnection node in dual-node interconnected
ring, the service LSPs in the interconnection nodes should use the
same MPLS label. So any interconnection node can terminate source
ring runnel and push destination ring tunnel according to service LSP
label.
- Two interconnection nodes can be managed as a virtual
interconnection node group. Each ring should assign ring tunnels to
the virtual interconnection node group. The interconnection nodes in
the group should terminate the working ring tunnel in each ring.
Protection ring tunnel is a open ring to switch with the working ring
tunnel at the nodes which detect the fault and end at the egress
node.
- When the service traffic passes through the interconnection node,
the direction of the working ring tunnels in each ring for this
service traffic should be the same. For example, if the working ring
tunnel follows the clockwise direction in Ring1, the working ring
tunnel for the same service traffic in Ring2 also follows the
clockwise direction when the service leaves Ring1 and enters Ring2.
2.5.2.2. Ring tunnels of interconnected rings
The same ring tunnels as described in 2.1.1 are used in each ring of
the interconnected rings. Besides, ring tunnels to the virtual
interconnection node group will be established by each ring of the
interconnected rings, i.e.:
- one clockwise working ring tunnel to the virtual interconnection
node group;
- one anticlockwise protection ring tunnel to the virtual
interconnection node group,
- one anticlockwise working ring tunnel to the virtual
interconnection node group;
- one clockwise protection ring tunnel to the virtual interconnection
node group.
These ring tunnel will terminated at all nodes in virtual
interconnection node group.
Cheng, et al. Expires January 3, 2015 [Page 17]
Internet-Draft MSRP July 2014
All the ring tunnels established in Ring1 in Figure 11 is provided as
follows:
To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A;
To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B;
To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C;
To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D;
To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E;
To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F;
To the virtual interconnection node group (including Node F and Node
A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A;
All the ring tunnels established in Ring2 in Figure 11 is provided as
follows:
To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A;
To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F;
To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G;
To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H;
To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I;
To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J;
To the virtual interconnection node group(including Node F and Node
A): R2cW_FandA, R2aW_FandA, R2cP_FandA, R2aP_FandA;
2.5.2.3. Interconnected ring switch mechanism
Cheng, et al. Expires January 3, 2015 [Page 18]
Internet-Draft MSRP July 2014
+---+cccccccccccc +---+
| H |-------------| I |--->LSP1
+---+ +---+
c/a a\
c/a a\
c/a a\
+---+ +---+
| G | Ring2 | J |
+---+ +---+
c\a a/c
c\a a/c
c\a aaaaaaaaaaaaa a/c
+---+ccccccccccccc+---+
| F |-------------| A |
+---+ccccccccccccc+---+
c/aaaaaaaaaaaaaaaaaaa a\
c/ a\
c/ a\
+---+ +---+
| E | Ring1 | B |
+---+ +---+
c\a a/c
c\a a/c
c\a a/c
+---+aaaaaaaaaaaa +---+
LSP1--->| D |-------------| C |
+---+ccccccccccccc+---+
ccccccccccc R1cW_F&A
aaaaaaaaaaa R1aP_F&A
ccccccccccc R2cW_I
aaaaaaaaaaa R2aP_I
Figure 12 Ring tunnels for the interconnected rings
As shown in Figure 12, for the service traffic LSP1 which enters
Ring1 at Node D and leaves Ring1 at Node F and continues to enter
Ring2 at Node F and leaves Ring2 at Node I, the protection scheme is
described below.
In normal state, LSP1 follows R1cW_F&A in Ring1 and R2CW_I in Ring2.
The label used for the working ring tunnel R1cW_F&A in Ring1 is
popped and the label used for the working ring tunnel R2cW_I will be
pushed based the inner label lookup at the interconnection node F.
The working path that the service traffic LSP1 follows is:
LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1.
In case of link failure, for example, when a failure occurs on the
link between Node F and Node E, Node F and E will detect the failure
Cheng, et al. Expires January 3, 2015 [Page 19]
Internet-Draft MSRP July 2014
and execute protection switching as described in 2.2.1.1. The path
that the service traffic LSP1 follows after switching change to
LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A->F)->R1cW_F(F)
->R2cW_I(F->G->H->I)->LSP1.
In case of non interconnection node failure, for example, when the
failure occurs at Node E in Ring1, Node F and E will detect failure
and execute protection switching as described in 2.2.1.2. The path
that the service traffic LSP1 follows after switching becomes:
LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A->F)->
R1cW_F(F)->R2cW_I(F->G->H->I).
In case of interconnection node failure, for example, when failure
occurs at the interconnection Node F. Node E and A in Ring1 will
detect the failure, and execute protection switching as described in
2.2.1.2. Node G and A in Ring2 will also detects the failure, and
execute protection switching. The path that the service traffic LSP1
follows after switching is:
LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R1cW_A(A)
->R2aP_I(A->J->I)->LSP1.
2.5.2.4. Interconnected ring topology detection mechanism
As show in Figure 13, the service traffic LSP1 traverses A->B-C in
Ring1 and C->G->H->I in Ring2. Node C and Node D is the
interconnection node. When both the link between Node C and Node G
and the link between Node C and Node D fail, ring tunnel from Node C
to Node I in Ring 2 becomes unreachable. However, Node D is still
available, by which LSP1 can still reach Node I.
In order to do so, the interconnection nodes need to know the ring
topology in each ring independently so that they can judge whether a
node is reachable. The judgment is based on the knowledge of ring
topology and the fault location as described in section 3.4. The
ring topology can be obtained by NMS or topology discovery
mechanisms. The fault location can be obtained by spreading the
fault information around the ring. The nodes which detect the
failure will spread the fault information in the opposite direction
node by node in the ring respectively. When the interconnection node
receives the message that informs the failure, it will quickly figure
out the location of the fault by the topology information that is
maintained by itself and determine whether the LSPs enter the ring
from itself can reach the destination. If the destination node is
reachable, the LSP will exit the source ring and enter the
destination ring. If the destination node is not reachable, the LSP
will switch to the anticlockwise protection ring tunnel.
Cheng, et al. Expires January 3, 2015 [Page 20]
Internet-Draft MSRP July 2014
In Figure 13 Node C judges the ring tunnel to Node I is unreachable,
the service traffic LSP1 of which the destination node on the ring
tunnel is Node I should switch to the protection LSP (R1aP_C&D) so
that the service traffic LSP1 traverses the interconnected rings at
Node D. Node D will remove the ring tunnel label of Ring1 and add
ring tunnel label of Ring2.
+---+ *********+---+**********+---+ +---+**********+---+
LSP1-> | A |----------| B |----------| C |XXXXXXXXXX| G |----------| H |
+---+##########+---+##########+---+ +---+##########+---+
|# X #|*
|# X #|*
|# Ring1 X Ring2 #|*
|# X #|*
|# X #|*
+---+##########+---+##########+---+######### +---+##########+---+
| F |----------| E |----------| D |----------| J |----------| I | ->LSP1
+---+ +---+ +---+ +---+ +---+
*********** R1cW_C&D
########### R1aP_C&D
*********** R2cW_I
########### R2aP_I
Figure 13 interconnected ring
3. Coordination protocol
3.1. RPS protocol
The MSRP protection operation MUST be controlled with the help of the
Ring Protection Switch Protocol(RPS). The RPS processes in the each
of the individual nodes that form the ring SHOULD communicate using
G-ACh channel.
The RPS protocol MUST carry the ring status information and RPS
requests, both automatic and externally initiated commands, between
the ring nodes.
Each node on the ring MUST be uniquely identified by assigning it a
node ID.The maximum 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 appear on the ring. The node ID is used to identity
the source and destination nodes of each RPS request.
Each node SHOULD have a ring map containing information about the
sequence of the nodes around the ring. The method of configuring the
nodes with the ring maps is TBD.
Cheng, et al. Expires January 3, 2015 [Page 21]
Internet-Draft MSRP July 2014
When no protection switches are active on the ring, each node MUST
dispatch periodically RPS requests to the two adjacent nodes,
indicating No Request (NR). When a node determines that a protection
switching is required, it MUST send the appropriate RPS request in
both directions.
+---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR)
-------| A |-------------| B |-------------| C |-------
(NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+
Figure 14: RPS communication between the ring nodes in case of no
failures in the ring
A destination node is a node that is adjacent to a node that
identified a failed span. When a node that is not the destination
node receives an RPS request and it has no higher priority local
request, it MUST transfer the RPS request as received. In this way,
the switching nodes can maintain direct RPS protocol communication in
the ring.
+---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF)
-------| A |-------------| B |----- X -----| C |-------
(SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+
Figure 15: RPS communication between the ring nodes in case of
failure between nodes B and C
Note that in the case of a bidirectional failure such as a cable cut,
two nodes detect the failure and send each other an RPS request in
opposite directions.
o In rings utilizing the wrapping protection, when the destination
node receives the RPS request it MUST perform the switch from/to the
working ring tunnels to/from the protection ring tunnels if it has no
higher priority active APS request.
o In rings utilizing the steering protection, when a ring switch is
required, any node MUST perform the switches if its added/dropped
traffic is affected by the failure. Determination of the affected
traffic SHOULD be performed by examining the APS requests (indicating
the nodes adjacent to the failure or failures) and the stored ring
maps (indicating the relative position of the failure and the added
traffic destined towards that failure).
When the failure has cleared and the Wait-to-Restore (WTR) timer has
expired, the nodes sourcing RPS requests MUST drop their respective
Cheng, et al. Expires January 3, 2015 [Page 22]
Internet-Draft MSRP July 2014
switches (tail end) and MUST source an RPS request carrying NR code.
The node receiving from both directions such RPS request (head end)
MUST drop its protection switches.
A protection switch MUST be initiated by one of the criteria
specified in Section 3.2. A failure of the RPS protocol or
controller MUST NOT trigger a protection switch.
Ring switches MUST be preempted by higher priority RPS requests. For
example, consider a protection switch that is active due to a manual
switch request on the given span, and another protection switch is
required due to a failure on another span. Then a RPS request MUST
be generated, the former protection switch MUST be dropped, and the
latter protection switch established.
MSPP mechanism SHOULD support multiple protection switches in the
ring, resulting the ring being segmented into two or more separate
segments. This may happen when several APS requests of the same
priority exist in the ring due to multiple failures or external
switch commands.
Proper operation of the MSRP mechanism relies on all nodes having
knowledge of the state of the ring (nodes and spans) so that nodes do
not preempt existing RPS request unless they have a higher-priority
RPS request. In order to accommodate ring state knowledge, during
protection switch the RPS requests MUST be sent in both directions.
3.1.1. Transmission and acceptance of RPS requests
A new RPS request MUST be transmitted immediately when a change in
the transmitted status occurs.
The first three RPS protocol messages carrying new RPS request SHOULD
be transmitted as fast as possible. For fast protection switching
within 50 ms, the interval of the first three RPS protocol messages
SHOULD be 3.3 ms. Then RPS requests SHOULD be transmitted with the
interval of 5 seconds.
3.1.2. RPS PDU structure
Figure 16 depicts the format of an RPS packet that is sent on the
G-ACh. The Channel Type field is set to indicate that the message is
an RPS message. The ACH MUST NOT include the ACH TLV Header RFC5586
[RFC5586]meaning that no ACH TLVs can be included in the message.
Cheng, et al. Expires January 3, 2015 [Page 23]
Internet-Draft MSRP July 2014
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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: G-ACh RPS Packet
The following fields MUST be provided:
o Destination Node ID: The destination node ID MUST always be set to
value of a node ID of the adjacent node. Valid destination node ID
values are 1-127.
o Source node ID: The source node ID MUST always be set to the value
of the node ID generating the APS request. Valid source node ID
values are 1-127.
o RPS request code: A code consisting of four bits as specified
below.
+-------------+-----------------------------+----------+
| Bits 4-1 | Condition, State | Priority |
| (MSB - LSB) | or external Request | |
+-------------------------------------------+----------+
| 1 1 1 1 | Lockout of Protection (LP) | highest |
| 1 1 0 1 | Forced Switch (FS) | |
| 1 0 1 1 | Signal Fail (SF) | |
| 0 1 1 0 | Manual Switch (MS) | |
| 0 1 0 1 | Wait-To-Restore (WTR) | |
| 0 0 1 1 | Exerciser (EXER) | |
| 0 0 0 1 | Reverse Request (RR) | |
| 0 0 0 0 | No Request (NR) | lowest |
+-------------+-----------------------------+----------+
3.1.3. Ring node RPS states
Idle state: A node is in the idle state when it has no RPS request
and is sourcing and receiving NR code to/from both directions.
Switching state: A node not in the idle or pass-through states is in
the switching state.
Pass-through state: A node is in the pass-through state when its
highest priority RPS request is a request not destined to or sourced
by it. The pass-through is bidirectional.
Cheng, et al. Expires January 3, 2015 [Page 24]
Internet-Draft MSRP July 2014
3.1.3.1. Idle state
A node in the idle state MUST source the NR request in both
directions.
A node in the idle state MUST terminate RPS requests flow in both
directions.
A node in the idle state MUST block the traffic flow on protection
LSPs/tunnels in both directions.
3.1.3.2. Switching state
A node in the switching state MUST source RPS request to adjacent
node with its highest RPS request code in both directions when it
detects a failure or receives an external command.
A node in the switching state MUST terminate RPS requests flow in
both directions.
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
with the RR code on the short path, and with the received RPS request
code on the long path.
This rule refers to the unidirectional failure detection: the RR
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
applicable when a failure is detected bidirectionally, because, in
this latter case, both nodes send an RPS request for the failure on
both paths (short and long).
The following switches MUST be allowed to coexist:
o LP with LP
o FS with FS
o SF with SF
o FS with SF
When multiple MS RPS requests over different spans exist at the same
time, no switch SHOULD be executed and existing switches MUST be
dropped. The nodes MUST signal, anyway, the MS APS request code.
Multiple EXER request MUST be allowed to coexist in the ring.
Cheng, et al. Expires January 3, 2015 [Page 25]
Internet-Draft MSRP July 2014
A node in a ring switching state that receives the external command
LW for the affected span MUST drop its switch and MUST signal NR for
the locked span if there is no other APS request on another span.
Node still SHOULD signal relevant APS request for another span.
3.1.3.3. Pass-through state
When a node is in a pass-through state, it MUST transmit on one side,
the same RPS request as it receives from the other side.
When a node is in a pass-through state, it MUST allow the traffic
flow on protection ring tunnels in both directions.
3.1.4. RPS state transitions
All state transitions are triggered by an incoming APS request
change, a WTR expiration, an externally initiated command, or locally
detected MPLS-TP section failure conditions.
RPS requests due to a locally detected failure, an externally
initiated command, or received APS request shall pre-empt existing
RPS requests in the prioritized order given in Section 3.1.2, unless
the requests are allowed to coexist.
3.1.4.1. Transitions between the idle and pass-through states
The transition from the idle state to pass-through state MUST be
triggered by a valid APS request change, in any direction, from the
NR code to any other code, as long as the new request is not destined
for the node itself. Both directions move then into a pass-through
state, so that, traffic entering the node through the protection Ring
tunnels are by-passed across the node.
A node MUST revert from pass-through state to the idle state when it
detects NR codes incoming from both directions. Both directions
revert simultaneously from the pass-through state to the idle state.
3.1.4.2. Transitions between the idle and switching states
Transition of a node from the idle state to the switching state MUST
be triggered by one of the following conditions:
o a valid RPS request change from the NR code to any code received on
either the long or the short path and destined to this node
o an externally initiated command for this node
Cheng, et al. Expires January 3, 2015 [Page 26]
Internet-Draft MSRP July 2014
o the detection of an MPLS-TP section layer failure at this node.
Actions taken at a node in idle state upon transition to switching
state are:
o for all protection switch requests, except EXER and LP, the node
MUST execute the switch
o for EXER, and LP, the node MUST signal appropriate request but not
execute the switch.
A node MUST revert from the switching state to the idle state when it
detects NR codes received from both directions.
o At the tail end: When a WTR time expires or an externally initiated
command is cleared at a node, the node MUST drop its switch, transit
to Idle state and signal the NR code in both directions.
o At the head end: Upon reception of the NR code, from both
directions, the head-end node MUST drop its switch, transition to
Idle state and signal the NR code in both directions.
3.1.4.3. Transitions between switching states
When a node that is currently executing any protection switch
receives a higher priority APS request (due to a locally detected
failure, an externally initiated command, or a ring protection switch
request destined to it) for the same span, it MUST upgrade the
priority of the switch it is executing to the priority of the
received APS request.
When a failure condition clears at a node, the node MUST enter WTR
condition and remain in it for the appropriate time-out interval,
unless:
o a different RPS request of higher priority than WTR is received
o another failure is detected
o an externally initiated command becomes active.
The node MUST send out a WTR code on both the long and short paths.
When a node that is executing a switch in response to incoming SF RPS
request (not due to a locally detected failure) receives a WTR code
(unidirectional failure case), it MUST send out RR code on the short
path and the WTR on the long path.
Cheng, et al. Expires January 3, 2015 [Page 27]
Internet-Draft MSRP July 2014
3.1.4.4. Transitions between switching and pass-through states
When a node that is currently executing a switch receives an RPS
request for a non-adjacent span of higher priority than the switch it
is executing, it MUST drop its switch immediately and enter the pass-
through state.
The transition of a node from pass-through to switching state MUST be
triggered by:
o an equal, higher priority, or allowed coexisting externally
initiated command
o the detection of an equal, higher priority, or allowed coexisting
failure
o the receipt of an equal, higher priority, or allowed coexisting APS
request destined to this node.
3.2. APS state machine
3.2.1. Initial states
Cheng, et al. Expires January 3, 2015 [Page 28]
Internet-Draft MSRP July 2014
+-----------------------------------+----------------+
| State | Signaled APS |
+-----------------------------------+----------------+
| A | Idle | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| B | Pass-trough | N/A |
| | Working: no switch | |
| | Protection: pass through | |
+-----+-----------------------------+----------------+
| C | Switching - LP | LP |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| D | Idle - LW | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| E | Switching - FS | FS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| F | Switching - SF | SF |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| G | Switching - MS | MS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| H | Switching - WTR | WTR |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| I | Switching - EXER | EXER |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
3.2.2. State transitions when local request is applied
In the state description below 'O' means that new local request will
be rejected because of exiting request.
=====================================================================
Initial state New request New state
------------- ----------- ---------
Cheng, et al. Expires January 3, 2015 [Page 29]
Internet-Draft MSRP July 2014
A (Idle) LP C (Switching - LP)
LW D (Idle - LW)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear N/A
WTR expires N/A
EXER I (Switching - EXER)
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-trough) LP C (Switching - LP)
LW B (Pass-trough)
FS O - if current state is due to
LP sent by another node
E (Switching - FS) - otherwise
SF O - if current state is due to
LP sent by another node
F (Switching - SF) - otherwise
Recover from SF N/A
MS O - if current state is due to
LP, SF or FS sent by
another node
G (Switching - MS) - otherwise
Clear N/A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP N/A
LW O
FS O
SF O
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-trough) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
Cheng, et al. Expires January 3, 2015 [Page 30]
Internet-Draft MSRP July 2014
D (Idle - LW) LP C (Switching - LP)
LW N/A - if on the same span
D (Idle - LW) - if on another
span
FS O - if on the same span
E (Switching - FS) - if on
another span
SF O - if on the addressed span
F (Switching - SF) - if on
another span
Recover from SF N/A
MS O - if on the same span
G (Switching - MS) - if on
another span
Clear A (Idle) - if there is no
failure on addressed span
F (Switching - SF) - if there
is a failure on this span
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
LW O - if on another span
D (Idle - LW) - if on the same
span
FS N/A - if on the same span
E (Switching - FS) - if on
another span
SF O - if on the addressed span
E (Switching - FS) - if on
another span
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-trough) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
LW O - if on another span
Cheng, et al. Expires January 3, 2015 [Page 31]
Internet-Draft MSRP July 2014
D (Idle - LW) - if on the same
span
FS E (Switching - FS)
SF N/A - if on the same span
F (Switching - SF) - if on
another span
Recover from SF H (Switching - WTR)
MS O
Clear N/A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
LW O - if on another span
D (Idle - LW) - if on the same
span
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS N/A - if on the same span
G (Switching - MS) - if on
another span release the
switches but signal MS
Clear A
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
LW D (Idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear A
WTR expires A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
LW D (idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
Cheng, et al. Expires January 3, 2015 [Page 32]
Internet-Draft MSRP July 2014
MS G (Switching - MS)
Clear A
WTR expires N/A
EXER N/A - if on the same span
I (Switching - EXER)
=====================================================================
3.2.3. State transitions when remote request is applied
The priority of remote request does not depend on the side from which
the request is received.
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR A (Idle)
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-trough) LP C (Switching - LP)
FS N/A - cannot happen when there
is LP request in the ring
E (Switching - FS) - otherwise
SF N/A - cannot happen when there
is LP request in the ring
F (Switching - SF) - otherwise
MS N/A - cannot happen when there
is LP, FS or SF request
in the ring
G (Switching - MS) - otherwise
WTR N/A - cannot happen when there
is LP, FS, SF or MS
request in the ring
EXER N/A - cannot happen when there
is LP, FS, SF, MS or WTR
request in the ring
I (Switching - EXER) -
otherwise
RR N/A
NR A (Idle) - if received from
both sides
Cheng, et al. Expires January 3, 2015 [Page 33]
Internet-Draft MSRP July 2014
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is LP request in the ring
SF N/A - cannot happen when there
is LP request in the ring
MS N/A - cannot happen when there
is LP request in the ring
WTR N/A
EXER N/A - cannot happen when there
is LP request in the ring
RR C (Switching - LP)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR D (Idle - LW)
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is FS request in the ring
WTR N/A
EXER N/A - cannot happen when there
is FS request in the ring
RR E (Switching - FS)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is SF request in the ring
WTR N/A
Cheng, et al. Expires January 3, 2015 [Page 34]
Internet-Draft MSRP July 2014
EXER N/A - cannot happen when there
is SF request in the ring
RR F (Switching - SF)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A
EXER N/A - cannot happen when there
is MS request in the ring
RR G (Switching - MS)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR H (Switching - WTR)
EXER N/A - cannot happen when there
is WTR request in the ring
RR H (Switching - WTR)
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR I (Switching - EXER)
NR N/A
=====================================================================
3.2.4. State Transitions when request addresses to another node is
received
The priority of remote request does not depend on the side from which
the request is received.
Cheng, et al. Expires January 3, 2015 [Page 35]
Internet-Draft MSRP July 2014
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP B (Pass-trough)
FS B (Pass-trough)
SF B (Pass-trough)
MS B (Pass-trough)
WTR B (Pass-trough)
EXER B (Pass-trough)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-trough) LP B (Pass-trough)
FS N/A - cannot happen when there
is LP request in the ring
B (Pass-trough) - otherwise
SF N/A - cannot happen when there
is LP request in the ring
B (Pass-trough) - otherwise
MS N/A - cannot happen when there
is LP, FS or SF request
in the ring
B (Pass-trough) - otherwise
WTR N/A - cannot happen when there
is LP, FS, SF or MS
request in the ring
B (Pass-trough) - otherwise
EXER N/A - cannot happen when there
is LP, FS, SF, MS or WTR
request in the ring
B (Pass-trough) - otherwise
RR N/A
NR B (Pass-trough)
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is LP request in the ring
SF N/A - cannot happen when there
is LP request in the ring
MS N/A - cannot happen when there
is LP request in the ring
WTR N/A - cannot happen when there
is LP in the ring
EXER N/A - cannot happen when there
Cheng, et al. Expires January 3, 2015 [Page 36]
Internet-Draft MSRP July 2014
is LP request in the ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP B (Pass-trough)
FS B (Pass-trough)
SF B (Pass-trough)
MS B (Pass-trough)
WTR B (Pass-trough)
EXER B (Pass-trough)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP B (Pass-trough)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is FS request in the ring
WTR N/A - cannot happen when there
is FS request in the ring
EXER N/A - cannot happen when there
is FS request in the ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP B (Pass-trough)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is SF request in the ring
WTR N/A - cannot happen when there
is SF request in the ring
EXER N/A - cannot happen when there
is SF request in the ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP B (Pass-trough)
FS B (Pass-trough)
SF B (Pass-trough)
Cheng, et al. Expires January 3, 2015 [Page 37]
Internet-Draft MSRP July 2014
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A - cannot happen when there
is MS request in the ring
EXER N/A - cannot happen when there
is MS request in the ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP B (Pass-trough)
FS B (Pass-trough)
SF B (Pass-trough)
MS B (Pass-trough)
WTR N/A
EXER N/A - cannot happen when there
is WTR request in the ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
I (Switching - EXER) LP B (Pass-trough)
FS B (Pass-trough)
SF B (Pass-trough)
MS B (Pass-trough)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR N/A
=====================================================================
4. IANA Considerations
Channel Types for the Generic Associated Channel are allocated from
the IANA PW Associated Channel Type registry defined in RFC4446
[RFC4446] and updated byRFC5586 [RFC5586].
IANA is requested to allocate further Channel Type as follows:
o 0xXX Ring Protection Switching (RPS) Note to RFC Editor:
this section may be removed on publication as an RFC.
Cheng, et al. Expires January 3, 2015 [Page 38]
Internet-Draft MSRP July 2014
5. Security Considerations
This document does not by itself raise any particular security
considerations.
6. Normative Refereces
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
Authors' Addresses
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Lei Wang
China Mobile
Email: Wangleiyj@chinamobile.com
Cheng, et al. Expires January 3, 2015 [Page 39]
Internet-Draft MSRP July 2014
Han Li
China Mobile
Email: Lihan@chinamobile.com
Huub van Helvoort
Huawei Technologies Co., Ltd.
Email: huub.van.helvoort@huawei.com
Kai Liu
Huawei Technologies Co., Ltd.
Email: alex.liukai@huawei.com
Jia He
Huawei Technologies Co., Ltd.
Email: hejia@huawei.com
Fang Li
China Academy of Telecommunication Research, MIIT., China
Email: lifang@ritt.cn
Cheng, et al. Expires January 3, 2015 [Page 40]
Internet-Draft MSRP July 2014
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
Cheng, et al. Expires January 3, 2015 [Page 41]