MPLS Working Group F. Zhang, Ed. Internet-Draft WJ. He Intended status: Standards Track ZTE Expires: January 5, 2012 July 04, 2011 MPLS-TP Shared Mesh Protection draft-zhang-mpls-tp-shared-mesh-protection-00 Abstract The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support sharing of protection resources. This document describes a shared mesh protection processing based on the existing MPLS-TP linear protection switching mechanisms. 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." This Internet-Draft will expire on January 5, 2012. Copyright Notice Copyright (c) 2011 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. Zhang & He Expires January 5, 2012 [Page 1] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Shared Mesh Protection Architecture . . . . . . . . . . . . . . 4 3.1. Planning . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Changes to PSC . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Preemption . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative references . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Zhang & He Expires January 5, 2012 [Page 2] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 1. Introduction For shared mesh protection, the protection resources are used to protect multiple LSPs which do not all share the same end points. In this way, mesh protection can substantially reduce the network resources that have to be reserved in oder to provide protection. The requirements have been described in [RFC5654] (Req. 66, 67, 68 and 69 ). Furthermore, the MPLS Transport Profile (MPLS-TP) Survivability Framework [I-D.ietf-mpls-tp-survive-fwk] outlined the operation. The shared mesh recovery schemes are also discussed in [RFC4428] and [G.smp]. In (1:1)^n protection decribed in [RFC4428], n working paths are protected by n dedicated protection paths while sharing the same protection bandwidth. This document describes a shared mesh protection processing based on the concept of (1:1)^n recovery scheme defined in [RFC4428], and on the protecion mechanism being developed in [I-D.ietf-mpls-tp-linear-protection] [I-D.ezy-mpls-1ton-protection]. 2. Conventions used in this document 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]. 2.1. Acronyms This draft uses the following acronyms: Ack Acknowledge DNR Do not revert FS Forced Switch LER Label Edge Router LO Lockout of protection LSP Label Switched Path MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate point MPLS-TP Transport Profile for MPLS MS Manual Switch NR No Request P2P Point-to-point PSC Protection State Coordination Protocol SF Signal Fail SMPG Shared Mesh Protection Group WTR Wait-to-Restore Zhang & He Expires January 5, 2012 [Page 3] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 3. Shared Mesh Protection Architecture A simple case of shared mesh protection is illustrated in Figure 1. Consider three paths W1 [via nodes A, B, C], W3 [via nodes D, E, F] and W2 [via nodes X, Y, Z]. For these working paths do not share end points, they cannot make use of 1:N protection even though they also do not share any common points of failure. W1 may be protected by the path P1 [via nodes A, G, P, Q, H, C}, W3 may be protected by the path P3 [via nodes D, I, S, T, J, F], and W2 may be protected by the path P2 [via nodes X, V, P, Q, R, S, T, W, Z]. For all these cases, 1:1 protection may be used. In the event that the failure only affect one of the working paths, the shared segment PQ or/and ST only carry traffic from the working path being affected. Thus, it is possible for the network resources on the segment PQ and ST to be shared by the two protection paths. In this way, shared mesh protection can substantially reduce the amount of network resources that have to be reserved to provide protection. A------B------C D------E------F \ / \ / G H I J \ / \ / P-----Q----R-----S-----T / \ V W / \ X--------------Y---------------Z Figure 1: An example of shared mesh protection 3.1. Planning As described in [I-D.ietf-mpls-tp-survive-fwk], the network becomes more and more complex and the number of LSPs increases, the potential for shared mesh protection also increase. However, this can quickly become unmanageable owing to the increased complexity. Therefore, shared mesh protection is normally pre-planned and configured by the operator, although an automated sytem cannot be ruled out. This will include but not limited to: o Planning the shared mesh protection group (SMPG) which includes the protected paths and protecting paths. Different SPMGs do not share protection resources and are protected independently. This means that working paths which have the higher protection Zhang & He Expires January 5, 2012 [Page 4] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 switching priority are planned to be in different SMPGs, in such a way the higher priority paths will be protected mostly when one failure affects different SMPGs. o Configuring the mumbers of the SMPG. The working paths are disjoint as far as possible in one SMPG, so they will not be subject to common failures. Furthermore, each of the working paths may be assigned a relative priority that could be used to decide which working path would be protected in cases of conflict. The relative priority is recommend to be reflected by the entity number of the working path, which is compatible with 1:N linear protection [I-D.ezy-mpls-1ton-protection]. When equal priority requests occur simultaneously, the conflict is resolved in favour of the request with the lowest entity number. 4. Changes to PSC Protection State Coordination Protocol (PSC) defined in [I-D.ezy-mpls-1ton-protection] is a multi-phased protocol, the end- points perform any protection switching with waiting for acknowledgement from the far end Label Edge Router (LER). The protocol messages are transmitted using the G-ACh. In order to support shared mesh protection, there is a need to make changes to the format of the PSC message. In particular there is the need to carry TTL TLV [I-D.ietf-mpls-lsp-ping-ttl-tlv] as one optional TLV to indicate which node to receive the return PSC message. Due to this change, the value of the Ver field for PSC messages for a shared mesh protection domain MUST be set to 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | PSC-CT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|Request|PT |R|K| Reserved1 | FPath | Path | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Length | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of shared mesh protection PSC packet with a G-ACh header Zhang & He Expires January 5, 2012 [Page 5] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 5. Basic Operation This section illustrates the basic operation of the shared mesh protection for the topology shown in Figure 1 based on the PSC. If a unidirectional failure occurs on the W2 in the direction from node Z to node X at time zero, the shared mesh protection will operate as follows: a. Node X detects the signal failure (SF), sends SF(2,0) to node P with MPLS label TTL to control the hops between the node X and node P. TTL TLV may be inserted in the PSC message as one optional TLV to indicate that node P SHOULD use this value to return the PSC message. b. Node P compares the protection switching priority of W2 and W1. For W1 is in normal state, node P sends SF(2,0) to node P with MPLS label TTL to control the hops between the node P and node Q, similarly, TTL TLV may be inserted in the PSC message as one optional TLV to indicate that node S SHOULD use this value to return the PSC message. The same processing is done on node S and node T. c. When Node Z receives the PSC message, it bridges and selects traffic from P2. Then sends NR(0,2)Ack to node T, TTL TLV may be inserted in the PSC message for the same reason. d. Node T, S, Q, P relay the message until it arrives at node X. e. Node X bridges and selects traffic from P2, then sends SF(2,2). When node Z receives this message, it responses with NR(0,2). 5.1. Preemption If a unidirectional failure occurs on the W1 in the direction from node C to node A at time one, the shared mesh protection will operate as follows: a. Node A detects the SF on W1, sends SF(1,0) to node P with MPLS label TTL to control the hops between the node A and node P. TTL TLV may be inserted in the PSC message as one optional TLV to indicate that node P SHOULD use this value to return the PSC message. b. Node P compares the protection switching priority of W2 and W1. For W1's entity number is samller than W2's, it has the higher priority under the SF events on both working paths. So node P sends SF(1,0) on the path P1, and sends LO(2,2) on the path P2. c. Node Q relays the message SF(1,0) on the path P1 to node A, and sends LO(2,2) to node S when it receives LO(2,2) from the previous hop on the path P2. Zhang & He Expires January 5, 2012 [Page 6] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 d. When Node C receives the SF(1,0) message, it bridges and selects traffic from P1 and sends NR(0,1)Ack to node Q, TTL TLV may be inserted in the PSC message for the same reason. While node Z receives the LO(2,2) message, it bridges and selects traffic from W2, and responses with NR(0,0). It should be noted that this may cause loss of user data since W1 is still in a failure condition. e. Node A bridges and selects traffic from P1, then sends SF(1,1) when it receives NR(0,1)Ack. Node C will response with NR(0,1) while receives this message. According to the received NR(0,0), node X will bridge and select traffic from W2, and response with SF(2,0), then node P relays with LO(2,0) towards node Z. If a unidirectional failure occurs on the working path W3 (not on the W1) in the direction from node F to node P at time one. Although the resource preemption will fail, the basic PSC processing will be similarly. 6. IANA Considerations TBD. 7. Security Considerations The generic security considerations for the data-plane of MPLS-TP are described in the security framework document [I-D.ietf-mpls-tp-security-framework] together with the required mechanisms needed to address them. The security considerations for the generic associated control channel are described in [RFC5586]. The security considerations for protection and recovery aspects of MPLS-TP are addressed in [I-D.ietf-mpls-tp-survive-fwk]. The extensions to the protocol described in this document are extensions to the protocol defined in [I-D.ietf-mpls-tp-linear-protection] [I-D.ezy-mpls-1ton-protection] and does not introduce any new security risks. 8. Acknowledgement The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. 9. References Zhang & He Expires January 5, 2012 [Page 7] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 9.1. Normative references [I-D.ietf-mpls-tp-linear-protection] Bryant, S., Osborne, E., Sprecher, N., Fulignoli, A., and Y. Weingarten, "MPLS-TP Linear Protection", draft-ietf-mpls-tp-linear-protection-07 (work in progress), June 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. 9.2. Informative References [I-D.ezy-mpls-1ton-protection] Osborne, E., Zhang, F., and Y. Weingarten, "MPLS-TP 1toN Protection", draft-ezy-mpls-1ton-protection-00 (work in progress), June 2011. [I-D.ietf-mpls-lsp-ping-ttl-tlv] Boutros, S., Sivabalan, S., Swallow, G., Saxena, S., and V. Manral, "Definition of Time-to-Live TLV for LSP-Ping Mechanisms", draft-ietf-mpls-lsp-ping-ttl-tlv-00 (work in progress), June 2011. [I-D.ietf-mpls-tp-security-framework] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", draft-ietf-mpls-tp-security-framework-01 (work in progress), May 2011. [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", draft-ietf-mpls-tp-survive-fwk-06 (work in progress), June 2010. [RFC4428] Papadimitriou, D. and E. Mannie, "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. Zhang & He Expires January 5, 2012 [Page 8] Internet-Draft MPLS-TP Shared Mesh Protection July 2011 Authors' Addresses Fei Zhang (editor) ZTE Email: zhang.fei3@zte.com.cn Wenjuan He ZTE Email: hewenjuan@zte.com.cn Zhang & He Expires January 5, 2012 [Page 9]