RFC 8227
MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology
Pages: 56
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 36 to 56
5.3. RPS State Machine
5.3.1. Switch Initiation Criteria
5.3.1.1. Administrative Commands
Administrative commands can be initiated by the network operator through the Network Management System (NMS). The operator command may be transmitted to the appropriate node via the MPLS-TP RPS message. The following commands can be transferred by the RPS message: o Lockout of Protection (LP): This command prevents any protection activity and prevents using ring switches anywhere in the ring. If any ring switches exist in the ring, this command causes the switches to drop.
o Forced Switch (FS) to protection: This command performs the ring
switch of normal traffic from the working entity to the protection
entity for the link between the node at which the command is
initiated and the adjacent node to which the command is directed.
This switch occurs regardless of the state of the MPLS-TP section
for the requested link, unless a higher-priority switch request
exists.
o Manual Switch (MS) to protection: This command performs the ring
switch of the normal traffic from the working entity to the
protection entity for the link between the node at which the
command is initiated and the adjacent node to which the command is
directed. This occurs if the MPLS-TP section for the requested
link is not satisfying an equal or higher priority switch request.
o Exercise (EXER): This command exercises ring protection switching
on the addressed link without completing the actual switch. The
command is issued and the responses (RRs) are checked, but no
normal traffic is affected.
The following commands are not transferred by the RPS message:
o Clear: This command clears the administrative command and WTR
timer at the node to which the command was addressed. The
node-to-node signaling after the removal of the externally
initiated commands is performed using the NR code.
o Lockout of Working (LW): This command prevents the normal traffic
transported over the addressed link from being switched to the
protection entity by disabling the node's capability of requesting
a switch for this link in case of failure. If any normal traffic
is already switched on the protection entity, the switch is
dropped. If no other switch requests are active on the ring, the
NR code is transmitted. This command has no impact on any other
link. If the node receives the switch request from the adjacent
node from any side, it will perform the requested switch. If the
node receives the switch request addressed to the other node, it
will enter the pass-through state.
5.3.1.2. Automatically Initiated Commands
Automatically initiated commands can be initiated based on MPLS-TP
section-layer OAM indication and the received switch requests.
The node can initiate the following switch requests automatically:
o Signal Fail (SF): This command is issued when the MPLS-TP section-
layer OAM detects a signal failure condition.
o Wait-to-Restore (WTR): This command is issued when the MPLS-TP
section detects that the SF condition has cleared. It is used to
maintain the state during the WTR period unless it is preempted by
a higher-priority switch request. The WTR time may be configured
by the operator in 1 minute steps between 0 and 12 minutes; the
default value is 5 minutes.
o Reverse Request (RR): This command is transmitted to the source
node of the received RPS message over the short path as an
acknowledgment for receiving the switch request.
5.3.2. Initial States
This section describes the possible states of a ring node, the corresponding action of the working and protection ring tunnels on the node, and the RPS request that should be generated in that state. +-----------------------------------+----------------+ | State | Signaled RPS | +-----------------------------------+----------------+ | A | Idle | NR | | | Working: no switch | | | | Protection: no switch | | +-----+-----------------------------+----------------+ | B | Pass-through | 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 | | +-----+-----------------------------+----------------+
5.3.3. State Transitions When Local Request Is Applied
In the state description below, 'O' means that a new local request will be rejected because of an existing request. ===================================================================== Initial state New request New state ------------- ----------- --------- 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-through) LP C (Switching - LP) LW B (Pass-through) 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-through) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
LW N/A - if on the same link
D (Idle - LW) - if on another
link
FS O - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
F (Switching - SF) - if on
another link
Recover from SF N/A
MS O - if on the same link
G (Switching - MS) - if on
another link
Clear A (Idle) - if there is no
failure on addressed link
F (Switching - SF) - if there
is a failure on this link
WTR expires N/A
EXER O
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS N/A - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
E (Switching - FS) - if on
another link
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-through) - 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 link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF N/A - if on the same link
F (Switching - SF) - if on
another link
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 link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS N/A - if on the same link
G (Switching - MS) - if on
another link, 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
MS G (Switching - MS)
Clear A
WTR expires N/A
EXER N/A - if on the same link
I (Switching - EXER)
=====================================================================
5.3.4. State Transitions When Remote Request is Applied
The priority of a 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-through) LP C (Switching - LP) FS N/A - cannot happen when there is an LP request in the ring E (Switching - FS) - otherwise SF N/A - cannot happen when there is an LP request in the ring F (Switching - SF) - otherwise MS N/A - cannot happen when there is an LP, FS, or SF request in the ring G (Switching - MS) - otherwise WTR N/A - cannot happen when there is an LP, FS, SF, or MS request in the ring EXER N/A - cannot happen when there is an LP, FS, SF, MS, or a WTR request in the ring I (Switching - EXER) - otherwise RR N/A NR A (Idle) - if received from both sides
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an 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 an FS request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an 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 an SF request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an 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 an 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 a 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
=====================================================================
5.3.5. State Transitions When Request Addresses to Another Node is
Received
The priority of a remote request does not depend on the side from
which the request is received.
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP B (Pass-through)
FS N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
SF N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
MS N/A - cannot happen when there
is an LP, FS, or SF
request in the ring
B (Pass-through) - otherwise
WTR N/A - cannot happen when there
is an LP, FS, SF, or MS
request in the ring
B (Pass-through) - otherwise
EXER N/A - cannot happen when there
is an LP, FS, SF, MS, or
a WTR request in the
ring
B (Pass-through) - otherwise
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A - cannot happen when there
is an LP request in the
ring
EXER N/A - cannot happen when there
is an LP request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP B (Pass-through)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is an FS request in the
ring
WTR N/A - cannot happen when there
is an FS request in the
ring
EXER N/A - cannot happen when there
is an FS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP B (Pass-through)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is an SF request in the
ring
WTR N/A - cannot happen when there
is an SF request in the
ring
EXER N/A - cannot happen when there
is an SF request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A - cannot happen when there
is an MS request in the
ring
EXER N/A - cannot happen when there
is an MS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER N/A - cannot happen when there
is a WTR request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR N/A
=====================================================================
6. IANA Considerations
IANA has assigned the values listed in the sections below.6.1. G-ACh Channel Type
The Channel Types for G-ACh are allocated from the PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586]. IANA has allocated the following new G-ACh Channel Type in the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry: Value | Description | Reference -------+---------------------------------+-------------- 0x002A | Ring Protection Switching (RPS) | this document | Protocol | -------+---------------------------------+--------------6.2. RPS Request Codes
IANA has created the subregistry "MPLS RPS Request Code Registry" under the "Generic Associated Channel (G-ACh) Parameters" registry. All code points within this registry shall be allocated according to the "Specification Required" procedure as specified in [RFC8126]. The RPS request field is 8 bits; the allocated values are as follows: Value Description Reference ------- --------------------------- ------------- 0 No Request (NR) this document 1 Reverse Request (RR) this document 2 Unassigned 3 Exercise (EXER) this document 4 Unassigned 5 Wait-to-Restore (WTR) this document 6 Manual Switch (MS) this document 7-10 Unassigned 11 Signal Fail (SF) this document 12 Unassigned 13 Forced Switch (FS) this document 14 Unassigned 15 Lockout of Protection (LP) this document 16-254 Unassigned 255 Reserved
7. Operational Considerations
This document describes three protection modes of the RPS protocol. Operators could choose the appropriate protection mode according to their network and service requirement. Wrapping mode provides a ring protection mechanism in which the protected traffic will reach every node of the ring and is applicable to protect both the point-to-point LSPs and LSPs that need to be dropped in several ring nodes, i.e., the point-to-multipoint applications. When protection is inactive, the protected traffic is switched (wrapped) to/from the protection ring tunnel at both sides of the defective link/node. Due to the wrapping, the additional propagation delay and bandwidth consumption of the protection tunnel are considerable. For bidirectional LSPs, the protected traffic in both directions is co-routed. Short-wrapping mode provides a ring protection mechanism that can be used to protect only point-to-point LSPs. When protection is inactive, the protected traffic is wrapped to the protection ring tunnel at the defective link/node and leaves the ring when the protection ring tunnel reaches the egress node. Compared with the wrapping mode, short-wrapping can reduce the propagation latency and bandwidth consumption of the protection tunnel. However, the two directions of a protected bidirectional LSP are not totally co- routed. Steering mode provides a ring protection mechanism that can be used to protect only point-to-point LSPs. When protection is inactive, the protected traffic is switched to the protection ring tunnel at the ingress node and leaves the ring when the protection ring tunnel reaches the egress node. The steering mode has the least propagation delay and bandwidth consumption of the three modes, and the two directions of a protected bidirectional LSP can be kept co-routed. Note that only one protection mode can be provisioned in the whole ring for all protected traffic.8. Security Considerations
MPLS-TP is a subset of MPLS, thus it builds upon many of the aspects of the security model of MPLS. Please refer to [RFC5920] for generic MPLS security issues and methods for securing traffic privacy and integrity. The RPS message defined in this document is used for protection coordination on the ring; if it is injected or modified by an attacker, the ring nodes might not agree on the protection action,
and the improper protection-switching action may cause a temporary break to services traversing the ring. It is important that the RPS message is used within a trusted MPLS-TP network domain as described in [RFC6941]. The RPS message is carried in the G-ACh [RFC5586], so it is dependent on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in [RFC4385]. Thus, this document relies on the security mechanisms provided for the Associated Channel as described in those two documents. As described in the security considerations of [RFC6378], the G-ACh is essentially connection oriented, so injection or modification of control messages requires the subversion of a transit node. Such subversion is generally considered hard in connection-oriented MPLS networks and impossible to protect against at the protocol level. Management-level techniques are more appropriate. The procedures and protocol extensions defined in this document do not affect the security model of MPLS-TP linear protection as defined in [RFC6378].9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <https://www.rfc-editor.org/info/rfc4446>. [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>. [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>. [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <https://www.rfc-editor.org/info/rfc6378>. [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013, <https://www.rfc-editor.org/info/rfc6941>. [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., Fondelli, F., Corsi, M., Wu, B., and X. Dai, "Applicability of MPLS Transport Profile for Ring Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, <https://www.rfc-editor.org/info/rfc6974>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
The authors would like to thank Gregory Mirsky, Yimin Shen, Eric Osborne, Spencer Jackson, and Eric Gray for their valuable comments and suggestions.Contributors
The following people contributed significantly to the content of this document and should be considered co-authors: Kai Liu Huawei Technologies Email: alex.liukai@huawei.com Jia He Huawei Technologies Email: hejia@huawei.com Fang Li China Academy of Telecommunication Research MIIT China Email: lifang@catr.cn Jian Yang ZTE Corporation 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
Authors' Addresses
Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Lei Wang China Mobile Email: wangleiyj@chinamobile.com Han Li China Mobile Email: lihan@chinamobile.com Huub van Helvoort Hai Gaoming BV Email: huubatwork@gmail.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com