CCAMP Working Group WJ. He, Ed. Internet-Draft F. Zhang Intended status: Standards Track ZTE Expires: January 5, 2012 July 4, 2011 RSVP-TE Extensions to Notification for Shared Mesh Protection draft-he-ccamp-notification-shared-mesh-protection-00 Abstract The shared mesh protection(SMP) mechanism enables multiple protection paths within a shared mesh protection domain to share protection resources, which allows only one of the n working paths to be protected at the same time. This document extends RSVP-TE to notify the state of shared resources in MPLS Transport Profile (MPLS-TP) mesh topology. 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 He & Zhang Expires January 5, 2012 [Page 1] Internet-Draft Notification for shared mesh protection July 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 3. Shared Mesh Protection . . . . . . . . . . . . . . . . . . . . 3 3.1. Shared Mesh Protection Planning . . . . . . . . . . . . . . 4 3.2. Signaling Protection LSPs . . . . . . . . . . . . . . . . . 4 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . 5 3.3.2. Rerouting . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.3. Preemption . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 He & Zhang Expires January 5, 2012 [Page 2] Internet-Draft Notification for shared mesh protection July 2011 1. Introduction In mesh protection, network resources may be shared to provide protection for working paths that do not share the same endpoints. This form of protection can make very efficient use of network resources, but requires careful synchronization to ensure that only one set of traffic is switched to the protection resources at any time. [RFC4872] defines the shared mesh restoration schemes based on control plane extensions, but does not cover the shared mesh protection scenarios. In order to coordinate the use of protection resources, this document specifies the notification schemes to notify the endpoint of the protecting LSP the state of the shared resource. 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. 3. Shared Mesh Protection Consider the following topology: A---B---C---D \ / E---F---G / \ H---I---J---K Figure 1 : A Shared Mesh Protection Topology The working LSPs W1[via nodes A,B,C,D] and W2[via nodes H,I,J,K] could be protected by P1[via nodes A,E,F,G,D] and P2[via nodes H,E,F,G,K]respectively. For both cases, 1:1 protection may be used. Thus, it is possible for the network resources on the segment EFG 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. He & Zhang Expires January 5, 2012 [Page 3] Internet-Draft Notification for shared mesh protection July 2011 If there are no failures affecting either of the two working paths, the network segment EFG may carry no traffic. In the event of only one failure, the segment EFG carries traffic from the working path that experiences the failure. 3.1. Shared Mesh Protection Planning Shared mesh protection will typically be subject to careful network planning. Operator plans 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. In Figure 1, the working LSP W1,W2 and protecting LSPs P1,P2 consist of a shared mesh protection group, in which the protecting LSPs P1 and P2 share the segment FEG although they belong to different sessions. In order to achieve this, the "Resource Sharing" Association type that defined in [RFC4873] and [I-D.ietf-ccamp-assoc-ext] can be used here. When operators plan shared mesh protection group, they will assign a group ID and a virtual address for the shared mesh protection group. The protecting LSP will be signaled with the "Resource Sharing" type ASSOCIATION object, the Association ID is set to the group ID, and the Association source is set to the group virtual address. 3.2. Signaling Protection LSPs When the protecting LSPs are signaled, the PROTECTION object, Notify Request object and "Recovery" type ASSOCIATION object are included in the Path message. Furthermore, the "Resource Sharing" type ASSOCIATION object SHOULD be inserted, the Association ID set to the associated protection group ID and the Association source set to the protection group virtual address. Any node processing a Path message for which the node does not have a matching state, and which contains an ASSOCIATION object with a "Resource Sharing" type, examines existing LSPs for matching Association Type, Association Source, and Association ID values. If any match is found, then [RFC3209] style resource sharing SHOULD be provided between the new and old LSPs. 3.3. Processing This section illustrates the realization of the shared mesh protection for the topology shown in Figure 1. He & Zhang Expires January 5, 2012 [Page 4] Internet-Draft Notification for shared mesh protection July 2011 3.3.1. Basic Operation If a failure occurs on the W2, the shared mesh protection will operate as follows: a. Node H detects the signal failure, switches the traffic to P2, and sends Path message to node E with O bit of protection object setting to 1. b. Upon receipt of the Path message with the O bit of protection object from 0 to 1, node E compares the protection switching priority of P2 and P1, then send notify message with the new error code/sub-code "notify error/resource occupied by the high priority" or "notify error/resource occupied by the low priority" to P1's ingress node. When the fault of the working LSP disappears, the shared mesh protection will operate as follows: a. The ingress node H will switch traffic to the working LSP, and refresh the Path message with the O bit of protection object setting to 0. b. Upon receiving the Path message with the O bit of protection object from 1 to 0, sharing start endpoint(node E) will send notify message with new error code/sub-code "notify error/ resource available" to the other protecting LSP's ingress node. 3.3.2. Rerouting If the ingress of the protecting LSP receives notify message with "notify error/resource occupied by the high priority", the node should reroute the protecting LSP. Because that the traffic of higher priority LSP may also be lost during the preemption, the node may also reroute for a more optimized path according to the local policy, when the node receives notify message with "notify error/ resource occupied by the low priority". If the protecting LSP reroutes, the new LSP will exclude the shared segment which was occupied by the other LSP. 3.3.3. Preemption During the sharing resource was occupied by one of the protecting LSPs, the other working LSP may also experiences some fault. In this case, these resource MUST be preempted by the high priority LSP. In Figure 1, if a failure occurs on the W1 while the W2 is still in failure state, the shared mesh protection will operate as follows: He & Zhang Expires January 5, 2012 [Page 5] Internet-Draft Notification for shared mesh protection July 2011 o The node A will not switch the traffic, if it has received the notification that the resource has been occupied by the high priority. o The node A has not received the notification that the resource has been occupied by the high priority LSP. The operation is as follows: 1. Node A switches the traffic to P1, and sends Path message to node E with O bit of protection object setting to 1. 2. Once Node E (sharing start endpoint)receives the Path message with the O bit of protection object from 0 to 1, it compares the protection switching priority of P2 and P1. The node will send notify message with the new error code/sub-code "notify error/resource occupied by the high priority" to P2's ingress node. 3. Upon receipt of the notify message that the resource has been occupied by the high priority, node H will switch the traffic from P2 to W2, and sends Path message to node E with O bit of protection object setting to 0. 4. IANA Considerations TBD 5. Security Considerations TBD 6. Acknowledgement TBD 7. Informative References [I-D.ietf-ccamp-assoc-ext] Berger, L., Faucheur, F., and A. Narayanan, "RSVP Association Object Extensions", draft-ietf-ccamp-assoc-ext-00 (work in progress), May 2011. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE He & Zhang Expires January 5, 2012 [Page 6] Internet-Draft Notification for shared mesh protection July 2011 Extensions in Support of End-to-End Generalized Multi- Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. Authors' Addresses Wenjuan He (editor) ZTE Email: he.wenjuan1@zte.com.cn Fei Zhang ZTE Email: zhang.fei3@zte.com.cn He & Zhang Expires January 5, 2012 [Page 7]