--- 1/draft-ietf-mpls-tp-shared-ring-protection-01.txt 2016-06-15 00:16:11.638630797 -0700 +++ 2/draft-ietf-mpls-tp-shared-ring-protection-02.txt 2016-06-15 00:16:11.746633500 -0700 @@ -1,31 +1,31 @@ Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li -Expires: September 22, 2016 China Mobile +Expires: December 17, 2016 China Mobile H. Helvoort Hai Gaoming BV K. Liu J. Dong J. He Huawei Technologies F. Li China Academy of Telecommunication Research, MIIT., China J. Yang ZTE Corporation P.R.China J. Wang Fiberhome Telecommunication Technologies Co., LTD. - March 21, 2016 + June 15, 2016 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 This document describes requirements, architecture 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 how it satisfies the requirements for optimized ring protection in RFC 5654 is analyzed. This document also defines the Ring Protection Switch (RPS) Protocol which is used to coordinate the protection behavior of the nodes on MPLS ring. @@ -44,21 +44,21 @@ 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." - This Internet-Draft will expire on September 22, 2016. + This Internet-Draft will expire on December 17, 2016. Copyright Notice Copyright (c) 2016 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 @@ -112,28 +112,28 @@ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction - As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP - requirements, several service providers have expressed much interest - in operating MPLS-TP in ring topologies and require a high-level - survivability function in these topologies. In operational transport - network deployment, MPLS-TP networks are often constructed with ring - topologies. It calls for an efficient and optimized ring protection - mechanism to achieve simple operation and fast, sub 50 ms, recovery - performance. + As described in section 2.5.6.1 of [RFC5654], Ring Protection of + MPLS-TP requirements, several service providers have expressed much + interest in operating MPLS-TP in ring topologies and require a high- + level survivability function in these topologies. In operational + transport network deployment, MPLS-TP networks are often constructed + with ring topologies. It calls for an efficient and optimized ring + protection mechanism to achieve simple operation and fast, sub 50 ms, + recovery performance. The requirements for MPLS-TP [RFC5654] state that recovery mechanisms which are optimized for ring topologies could be further developed if it can provide the following features: a. Minimize the number of OAM entities for protection b. Minimize the number of elements of recovery c. Minimize the required label number @@ -1962,25 +1962,25 @@ happen on any segment of the ring, thus RPS SHOULD be capable of identifying and handling the different failures on the ring, and coordinating the protection switching behavior of all the nodes on the ring. As specified in section 5, this is achieved with 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 the RPS Request message. Taking a ring topology with N nodes as example: - With the mechanism specified in RFC6974, on every ring-node, a linear - protection configuration has to be provisioned with every other node - in the ring, i.e. with (N-1) other nodes. This means that on every - ring node there will be (N-1) instances of the PSC protocol. And in - order to detect faults and to transport the PSC message, each + With the mechanism specified in [RFC6974], on every ring-node, a + linear protection configuration has to be provisioned with every + other node in the ring, i.e. with (N-1) other nodes. This means that + on every ring node there will be (N-1) instances of the PSC protocol. + 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 protection path respectively. This means that every node on the ring needs to be configured with (N-1) * 2 MEPs. 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 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 this way, every ring-node only needs to be configured with 2 MEPs. @@ -1995,24 +1995,25 @@ in this document and summarized in this section. 6.1. G-ACh Channel Type The Channel Types for the Generic Associated Channel (GACH) are allocated from the IANA PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586]. IANA is requested to allocate a new GACH Channel Type as follows: - Value Description Reference - ------ -------------------------- --------------- - TBD Ring Protection Switching this document - Protocol (RPS) + Value| Description | Reference + ------+---------------------------+-------------- + TBD | Ring Protection Switching |this document + | Protocol (RPS) | + ------+---------------------------+-------------- 6.2. RSP Request Codes IANA is requested to create a new sub-registry under the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS RPS Request Code Registry". All code points within this registry shall be allocated according to the "Standards Action" procedure as specified in [RFC5226]. @@ -2081,32 +2082,32 @@ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [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, . - [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, . - 10.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . + [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, . + [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, . [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, .