draft-ietf-mpls-tp-shared-ring-protection-01.txt   draft-ietf-mpls-tp-shared-ring-protection-02.txt 
Network Working Group W. Cheng Network Working Group W. Cheng
Internet-Draft L. Wang Internet-Draft L. Wang
Intended status: Standards Track H. Li Intended status: Standards Track H. Li
Expires: September 22, 2016 China Mobile Expires: December 17, 2016 China Mobile
H. Helvoort H. Helvoort
Hai Gaoming BV Hai Gaoming BV
K. Liu K. Liu
J. Dong J. Dong
J. He J. He
Huawei Technologies Huawei Technologies
F. Li F. Li
China Academy of Telecommunication Research, MIIT., China China Academy of Telecommunication Research, MIIT., China
J. Yang J. Yang
ZTE Corporation P.R.China ZTE Corporation P.R.China
J. Wang J. Wang
Fiberhome Telecommunication Technologies Co., LTD. Fiberhome Telecommunication Technologies Co., LTD.
March 21, 2016 June 15, 2016
MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology
draft-ietf-mpls-tp-shared-ring-protection-01 draft-ietf-mpls-tp-shared-ring-protection-02
Abstract Abstract
This document describes requirements, architecture and solutions for This document describes requirements, architecture and solutions for
MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point- MPLS-TP Shared Ring Protection (MSRP) in the ring topology for point-
to-point (P2P) services. The mechanism of MSRP is illustrated and to-point (P2P) services. The mechanism of MSRP is illustrated and
how it satisfies the requirements for optimized ring protection in how it satisfies the requirements for optimized ring protection in
RFC 5654 is analyzed. This document also defines the Ring Protection RFC 5654 is analyzed. This document also defines the Ring Protection
Switch (RPS) Protocol which is used to coordinate the protection Switch (RPS) Protocol which is used to coordinate the protection
behavior of the nodes on MPLS ring. behavior of the nodes on MPLS ring.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on December 17, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 45
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP As described in section 2.5.6.1 of [RFC5654], Ring Protection of
requirements, several service providers have expressed much interest MPLS-TP requirements, several service providers have expressed much
in operating MPLS-TP in ring topologies and require a high-level interest in operating MPLS-TP in ring topologies and require a high-
survivability function in these topologies. In operational transport level survivability function in these topologies. In operational
network deployment, MPLS-TP networks are often constructed with ring transport network deployment, MPLS-TP networks are often constructed
topologies. It calls for an efficient and optimized ring protection with ring topologies. It calls for an efficient and optimized ring
mechanism to achieve simple operation and fast, sub 50 ms, recovery protection mechanism to achieve simple operation and fast, sub 50 ms,
performance. recovery performance.
The requirements for MPLS-TP [RFC5654] state that recovery mechanisms The requirements for MPLS-TP [RFC5654] state that recovery mechanisms
which are optimized for ring topologies could be further developed if which are optimized for ring topologies could be further developed if
it can provide the following features: it can provide the following features:
a. Minimize the number of OAM entities for protection a. Minimize the number of OAM entities for protection
b. Minimize the number of elements of recovery b. Minimize the number of elements of recovery
c. Minimize the required label number c. Minimize the required label number
skipping to change at page 16, line 42 skipping to change at page 16, line 42
I: Intact S: Severed I: Intact S: Severed
Figure 9. Steering operation and protection switching Figure 9. Steering operation and protection switching
As shown in Figure 9, LSP1 enters the ring from Node A while LSP2 As shown in Figure 9, LSP1 enters the ring from Node A while LSP2
enters the ring from Node B, and both of them have the same enters the ring from Node B, and both of them have the same
destination node D. destination node D.
In normal state, LSP1 is carried by the clockwise working ring tunnel In normal state, LSP1 is carried by the clockwise working ring tunnel
(RcW_D) through the path A->B->C->D, the label operation is: [LSP1] (RcW_D) through the path A->B->C->D, the label operation is: [LSP1]
-> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) ->
[RcW_D(D)|LSP1](NodeC) -> [LSP1] (data traffic carried by LSP1) . [RcW_D(D)|LSP1](NodeC) -> [LSP1](data traffic carried by LSP1) .
LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught
the path B->C->D, the label operation is: [LSP2] -> the path B->C->D, the label operation is: [LSP2] ->
[RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2] (data [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](data
traffic carried by LSP2) . traffic carried by LSP2) .
If the link between nodes C and D fails, according to the fault If the link between nodes C and D fails, according to the fault
detection and distribution mechanisms, Node D will find out that detection and distribution mechanisms, Node D will find out that
there is a failure in the link between C and D, and it will update there is a failure in the link between C and D, and it will update
the link state of its ring topology, changing the link between C and the link state of its ring topology, changing the link between C and
D from normal to fault. In the direction that opposite to the D from normal to fault. In the direction that opposite to the
failure position, Node D will send the state report message to Node failure position, Node D will send the state report message to Node
E, informing Node E of the fault between C and D, and E will update E, informing Node E of the fault between C and D, and E will update
the link state of its ring topology accordingly, changing the link the link state of its ring topology accordingly, changing the link
skipping to change at page 17, line 22 skipping to change at page 17, line 22
clockwise direction. clockwise direction.
When Node A receives the failure report message and updates the link When Node A receives the failure report message and updates the link
state of its ring topology, it is aware that there is a fault on the state of its ring topology, it is aware that there is a fault on the
clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the
ring locally and is carried by this ring tunnel, thus Node A will ring locally and is carried by this ring tunnel, thus Node A will
decide to switch the LSP1 onto the anticlockwise protection ring decide to switch the LSP1 onto the anticlockwise protection ring
tunnel to node D (RaP_D). After the switchover, LSP1 will follow the tunnel to node D (RaP_D). After the switchover, LSP1 will follow the
path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)|
LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) ->
[LSP1] (data traffic carried by LSP1). [LSP1](data traffic carried by LSP1).
The same procedure also applies to the operation of LSP2. When Node The same procedure also applies to the operation of LSP2. When Node
B updates the link state of its ring topology, and finds out that the B updates the link state of its ring topology, and finds out that the
working ring tunnel RcW_D has failed, it will switch the LSP2 to the working ring tunnel RcW_D has failed, it will switch the LSP2 to the
anticlockwise protection tunnel RaP_D. After the switchover, LSP2 anticlockwise protection tunnel RaP_D. After the switchover, LSP2
goes through the path B->A->F->E->D, and the label operation is: goes through the path B->A->F->E->D, and the label operation is:
[LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> [LSP2] -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) ->
[RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](data
traffic carried by LSP2). traffic carried by LSP2).
skipping to change at page 43, line 25 skipping to change at page 43, line 25
happen on any segment of the ring, thus RPS SHOULD be capable of happen on any segment of the ring, thus RPS SHOULD be capable of
identifying and handling the different failures on the ring, and identifying and handling the different failures on the ring, and
coordinating the protection switching behavior of all the nodes on coordinating the protection switching behavior of all the nodes on
the ring. As specified in section 5, this is achieved with the the ring. As specified in section 5, this is achieved with the
introduction of the "Pass-Through" state for the ring nodes, and the introduction of the "Pass-Through" state for the ring nodes, and the
location of the protection request is identified via the Node IDs in location of the protection request is identified via the Node IDs in
the RPS Request message. the RPS Request message.
Taking a ring topology with N nodes as example: Taking a ring topology with N nodes as example:
With the mechanism specified in RFC6974, on every ring-node, a linear With the mechanism specified in [RFC6974], on every ring-node, a
protection configuration has to be provisioned with every other node linear protection configuration has to be provisioned with every
in the ring, i.e. with (N-1) other nodes. This means that on every other node in the ring, i.e. with (N-1) other nodes. This means that
ring node there will be (N-1) instances of the PSC protocol. And in on every ring node there will be (N-1) instances of the PSC protocol.
order to detect faults and to transport the PSC message, each And in order to detect faults and to transport the PSC message, each
instance shall have a MEP on the working path and a MEP on the instance shall have a MEP on the working path and a MEP on the
protection path respectively. This means that every node on the ring protection path respectively. This means that every node on the ring
needs to be configured with (N-1) * 2 MEPs. needs to be configured with (N-1) * 2 MEPs.
With the mechanism defined in this document, on every ring node there With the mechanism defined in this document, on every ring node there
will only be a single instance of the RPS protocol. In order to will only be a single instance of the RPS protocol. In order to
detect faults and to transport the RPS message, each node only needs detect faults and to transport the RPS message, each node only needs
to have a MEP on the section to its adjacent nodes respectively. In to have a MEP on the section to its adjacent nodes respectively. In
this way, every ring-node only needs to be configured with 2 MEPs. this way, every ring-node only needs to be configured with 2 MEPs.
skipping to change at page 44, line 13 skipping to change at page 44, line 13
in this document and summarized in this section. in this document and summarized in this section.
6.1. G-ACh Channel Type 6.1. G-ACh Channel Type
The Channel Types for the Generic Associated Channel (GACH) are The Channel Types for the Generic Associated Channel (GACH) are
allocated from the IANA PW Associated Channel Type registry defined allocated from the IANA PW Associated Channel Type registry defined
in [RFC4446] and updated by [RFC5586]. in [RFC4446] and updated by [RFC5586].
IANA is requested to allocate a new GACH Channel Type as follows: IANA is requested to allocate a new GACH Channel Type as follows:
Value Description Reference Value| Description | Reference
------ -------------------------- --------------- ------+---------------------------+--------------
TBD Ring Protection Switching this document TBD | Ring Protection Switching |this document
Protocol (RPS) | Protocol (RPS) |
------+---------------------------+--------------
6.2. RSP Request Codes 6.2. RSP Request Codes
IANA is requested to create a new sub-registry under the IANA is requested to create a new sub-registry under the
"Multiprotocol Label Switching (MPLS) Operations, Administration, and "Multiprotocol Label Switching (MPLS) Operations, Administration, and
Management (OAM) Parameters" registry called the "MPLS RPS Request Management (OAM) Parameters" registry called the "MPLS RPS Request
Code Registry". All code points within this registry shall be Code Registry". All code points within this registry shall be
allocated according to the "Standards Action" procedure as specified allocated according to the "Standards Action" procedure as specified
in [RFC5226]. in [RFC5226].
skipping to change at page 46, line 5 skipping to change at page 46, line 5
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009, DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>. <http://www.rfc-editor.org/info/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <http://www.rfc-editor.org/info/rfc5654>. September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[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, <http://www.rfc-editor.org/info/rfc6371>.
10.2. Informative References 10.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[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, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-
TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378,
October 2011, <http://www.rfc-editor.org/info/rfc6378>. October 2011, <http://www.rfc-editor.org/info/rfc6378>.
[RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D.,
Fondelli, F., Corsi, M., Wu, B., and X. Dai, Fondelli, F., Corsi, M., Wu, B., and X. Dai,
"Applicability of MPLS Transport Profile for Ring "Applicability of MPLS Transport Profile for Ring
Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013,
<http://www.rfc-editor.org/info/rfc6974>. <http://www.rfc-editor.org/info/rfc6974>.
 End of changes. 12 change blocks. 
29 lines changed or deleted 30 lines changed or added

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