Network Working Group Y. Weingarten INTERNET-DRAFT Intended status: Informational S. Aldrin Expires: June 12, 2014 Huawei Technologies P. Pan Infinera J. Ryoo ETRI G. Mirsky Ericsson December 9, 2013 Requirements for MPLS Shared Mesh Protection draft-ietf-mpls-smp-requirements-02.txt Abstract This document presents the basic network objectives for the behavior of shared mesh protection (SMP) not based on control-plane support. This is an expansion of the basic requirements presented in the MPLS Transport Profile Requirements (RFC5654) and MPLS Transport Profile Survivability Framework (RFC6372) documents. This document is to be used as a basis for the definition of any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate executive action for resiliency to the data plane. 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 March 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Weingarten, et al. Expires June 12, 2014 [Page 1] Internet-Draft MPLS SMP Req December 9, 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Shared Mesh Protection Reference Model . . . . . . . . . . . . 3 2.1. Protection or Restoration . . . . . . . . . . . . . . . . 4 2.2. Scope of document . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Relationship to MPLS-TP . . . . . . . . . . . . . . . 4 2.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 3. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 3.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SMP Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Coordination of resources . . . . . . . . . . . . . . . . 7 4.2. Control plane or data plane . . . . . . . . . . . . . . . 7 5. SMP Network Objectives . . . . . . . . . . . . . . . . . . . . 7 5.1. Configuration and resource reservation . . . . . . . . . . 7 5.1.1. Checking resource availability . . . . . . . . . . . . 8 5.2. Multiple triggers . . . . . . . . . . . . . . . . . . . . 8 5.3. Notification . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Revertive protection switching . . . . . . . . . . . . . . 10 5.5. Protection switching time . . . . . . . . . . . . . . . . 10 5.6. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.7. Communicating information and channel . . . . . . . . . . 11 6. Manageability Considerations . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Weingarten, et al. Expires June 12, 2014 [Page 2] Internet-Draft MPLS SMP Req December 9, 2013 1. Introduction MPLS transport networks can be characterized as being a network of connections between nodes within a mesh of nodes and the links between them. The connections, that may be between neighboring nodes, i.e. spanning a single physical link, or spanning a path of several nodes, constitute the Label Switched Paths (LSP) that transport packets between the endpoints of these paths. The survivability of these connections, as described in [RFC6372], is a critical aspect for various service providers that are bound by Service Level Agreements (SLA) with their customers. MPLS provides control-plane tools to support various survivability schemes (Editor's note - add references). In addition, recent efforts in the IETF have started providing for data-plane tools to address aspects of data protection. In particular, [RFC6378] defines a set of triggers and coordination protocol for 1:1 and 1+1 linear protection of p2p paths. When considering a full-mesh network and the protection of different paths that criss-cross the mesh, it is possible to provide an acceptable level of protection while conserving the amount of protection resources needed to protect the different data paths. As pointed out in [RFC6372] and [RFC4428], applying 1+1 linear protection, requires that resources are committed to be used by both the working and protection paths. Applying 1:1 protection requires that all of the resources are committed, but allows the resources of the protection path to be utilized for pre-emptible extra traffic. Extending this to 1:n or m:n protection allows the resources of the protection path to be shared in the protection of several working paths. However, there is a limitation in 1:n protection architectures - that all of the n+1 paths must have identical endpoints. 2. Shared Mesh Protection Reference Model As described in [RFC6372] Shared Mesh Protection (SMP) supports a form of sharing protection resources, while providing protection for multiple working paths that may not have common endpoints and do not share common points of failure. It should be noted that some protection resources may not be shared by multiple protection paths, while other resources are shared. An example of data paths that employ SMP is shown in Figure 1. In this figure, we show two working paths [ABCDE] and [VWXYZ] that are protected employing 1:1 linear protection by protection paths [APQRE] and [VPQRZ] respectively. The segment [PQR] and all of its protection resources are shared by both of the protection paths. Weingarten, et al. Expires June 12, 2014 [Page 3] Internet-Draft MPLS SMP Req December 9, 2013 A----B----C----D----E \ / \ / \ / P-----Q-----R / \ / \ / \ V----W----X----Y----Z Figure 1: Basic SMP architecture 2.1. Protection or Restoration [RFC6372], based upon the definitions in [RFC4427], differentiates between "protection" and "restoration" dependent upon the dynamism of the resource allocation. In SMP, the resources of the protection paths are planned at the time of path creation. However, the commitment of the resources, at least for the shared segments, will only be finalized when the protection path is actually activated. Therefore, for the purists - regarding the terminology - SMP lies somewhere between protection and restoration. 2.2. Scope of document [RFC5654] establishes that MPLS-TP should support shared protection (Requirement 68) and that MPLS-TP must support sharing of protection resources (Requirement 69).This document presents the network objectives and a framework for applying SMP within an MPLS network, without the use of control-plane protocols. There are existing control-plane solutions for SMP within MPLS, however we address those networks that for some reason, e.g. service provider preferences or limitations, do not employ a full control plane operation, or require service restoration faster than achievable with control plane mechanisms. The network objectives will also address possible additional restrictions of the behavior of SMP in networks that delegate executive action for resiliency to the data plane. Definition of logic and specific protocol messaging is out of scope of this document. 2.2.1. Relationship to MPLS-TP While some of the restrictions presented by this framework originate from the considerations of transport networks, there is no real constraint of the information presented here being applied to general Weingarten, et al. Expires June 12, 2014 [Page 4] Internet-Draft MPLS SMP Req December 9, 2013 MPLS networks, and not necessarily as part of the Transport Profile of MPLS. 2.3. Contributing Authors David Allan, Daniel King, Taesik Cheung 3. Terminology and Notation 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]. The terminology used in this document is based on the terminology defined in the MPLS-TP Survivability Framework document [RFC6372] which in-turn is based on [RFC4427]. 3.1. Acronyms This draft uses the following acronyms: LSP Label Switched Path SLA Service Level Agreement SMP Shared Mesh Protection SRLG Shared Risk Link Group 4. SMP Architecture Figure 1 shows a very basic configuration of working and protection paths that may employ SMP. We may consider a slightly more complex configuration, such as the one in Figure 2 in order to illustrate characteristics of a mesh network that implements SMP. A----B----C----D----E---N \ / / \ \ M ---/-- \ \ / \ \ P-----Q-----R-----S----T /| \ \ \ \ / F---G---H J--K---L \ / \ V------W-------X-------Y-------Z Figure 2: Larger sample SMP architecture Weingarten, et al. Expires June 12, 2014 [Page 5] Internet-Draft MPLS SMP Req December 9, 2013 Consider the network presented in Figure 2. There are five working paths - [ABCDE], [MDEN], [FGH], [JKL], and [VWXYZ]. Each of these has a corresponding protection path - [APQRE] (p1), [MSTN] (p2), [FPQH] (p3), [JRSL] (p4), and [VPQRSTZ] (p5). The following segments are shared by two or more of the protection paths - [PQ] is shared by p1, p3, and p5, [QR] is shared by p1 and p5, [RS] is shared by p4 and p5, and [ST] is shared by p2 and p5. In addition, we assume that the available protection resources for these shared segments are not sufficient to support the complete traffic capacity of the respective working paths that may use the protection paths. We can further observe that with a method of coordinating sharing and preemption there is no end to end co-routing constraints on whether shared components are or not co-routed at the segment level. We can further identify "SMP protection group" as the set of different protection paths that share a common segment. For example, referring to Figure 2, we have the following protection groups - {p1, p3, p5} for [PQ], {p1, p5} for [QR], {p4, p5} for [RS], {p2, p5} for [ST]. The use of preemption in the network is typically a business or policy decision such that when protection resources are contended, priority can be applied to determine to which parties the protection resources are committed. RFC6328 defines two types of preemption that can be considered for how the resources of an SMP protection domain, as set of SMP protection groups, are shared. These are "soft preemption" whereby traffic of lower priority paths is degraded and "hard preemption" where traffic of lower priority paths is completely blocked. "Hard Preemption" requires the programming of selectors at the ingress of each shared segment to enforce which backup path has the highest priority when committing protection resources, the others being preempted. When any protection mechanism whereby the protection end point may have a choice of protection paths (e.g. n:1 or m:n) is deployed the shared segment selectors require coordination with the protection end points as well. Typical deployment of services that use SMP would require various network planning activities. These would include: o Determining the number of working and protection paths required to achieve resiliency targets for the service. o Reviewing network topology to determine which working or protection paths are required to be disjointed from each other, and exclude specified resources such as links, nodes, or shared risk link groups (SRLGs). Weingarten, et al. Expires June 12, 2014 [Page 6] Internet-Draft MPLS SMP Req December 9, 2013 o Determining the size (bandwidth) of the shared resource 4.1. Coordination of resources When a protection switch is triggered by any fault condition or operator command, the SMP network must perform two operations almost simultaneously - switch data traffic over to a protection path and commit the associated resources. The commitment of resources is dependent upon their availability at each of the shared segments. When the reserved resources of the shared segments are committed to a particular protection path, there may not be sufficient resources available for an additional protection path. This then implies that if another working path of the SMP domain triggers a protection switch, the commitment of the resources may fail and MUST be treated as described below in Section 5.2. In order to optimize the operation of the commitment and preparing for cases of multiple working paths failing, the commitment of the shared resources SHALL be coordinated between the different working paths in the SMP network. 4.2. Control plane or data plane As stated in both [RFC6372] and [RFC4428], full control of SMP, including both configuration and the coordination of the protection switching is potentially very complex. Therefore, it is suggested that this be carried out under the control of a dynamic control plane similar to GMPLS [RFC3945]. In fact, implementations for SMP with GMPLS exist and the general principles of its operation are well known, if not fully documented. There are, however, operators, in particular in the transport sector, that do not operate their MPLS networks under the control of a control plane or for other reasons have delegated executive action for resilience to the data plane, and require the ability to utilize SMP protection. For such networks it is imperative that it be possible to perform all required coordination of selectors and end points for SMP via data plane operations. 5. SMP Network Objectives 5.1. Configuration and resource reservation SMP is a survivability mechanism that is based on pre-configuration of the network working paths and the corresponding protection paths. This configuration may be based on either a control protocol or static configuration by the management system. It should be noted that even when the configuration is performed by a control protocol, Weingarten, et al. Expires June 12, 2014 [Page 7] Internet-Draft MPLS SMP Req December 9, 2013 e.g. Generalized MPLS (GMPLS), that it is assumed that the control protocol is not used as the primary resilience mechanism. The protection relationship between the working and protection paths SHOULD be configured and the shared segments of the protection path MUST be identified prior to use of the protection paths. Relative priority for working paths MAY be configured ahead of time such that, it could be used to resolve contention for protection path usage by multiple working paths. As opposed to the case of simple linear protection, where the relationship between the working and protection paths is defined, the resources for the protection path may be fully committed for the unshared portions of the protection path. The protection path in the case of SMP consists of segments that are dedicated to the protection of the related working path and also segments that are shared with other protection paths such that typically the protection resources are oversubscribed to support working paths that do not share common points of failure. What is required is a preemption mechanism to implement business priority when multiple failure scenarios occur. As such, the protection resources may be planned but would not be committed until requested and resolved in relation to other members of the SMP protection group as part of a protection switchover. 5.1.1. Checking resource availability In a hard-preemption scenario, when an end point identifies a protection switching trigger and has more than one potential action (e.g. 1:n protection) it MUST verify that the necessary protection resources are available on the selected protection path. The resources may not be available because they already have been committed to the protection of, for example, a higher priority working path, as described above. 5.2. Multiple triggers If more than one working path is triggering a protection switch such that a protection segment is oversubscribed, there are different possible actions that the SMP network may apply. The basic MPLS action MAY allow all of the protection paths to share the resources of the shared segments (soft-preemption), for those networks that support multiplexing packets over the shared segments. For those networks, in particular for networks that support the requirements in [RFC5654][and in particular support for requirement 58], that require the exclusive use of the protection resources, i.e. hard preemtion, the following behavior SHOULD be supported: o Relative priority MAY be assigned to each of the working paths of Weingarten, et al. Expires June 12, 2014 [Page 8] Internet-Draft MPLS SMP Req December 9, 2013 an SMP domain. o Resources of the shared segments SHALL be committed to the protection path according to the highest priority amongst those requesting use of the resources. o If multiple protection paths of equal priority are requesting allocation of the shared resources, the resources SHOULD be committed on a first come first served basis. Tie-breaking rules SHALL be defined in scope of an SMP domain. o If the protection resources are committed to a protection path, whose working path has a lower priority, resources required for the higher priority path SHALL be committed to this path. Traffic with lower priority MAY use available resources or MAY be interrupted. o When triggered, protection switching action SHOULD be initiated immediately to minimize service interruption time. o If the protection resources are already committed to a higher priority protection path the protection switching SHALL not be performed. o Once resources of shared segments been successfully committed to a protection path, the traffic on that protection path SHALL NOT be interrupted by any protection traffic whose priority is equal or lower than the protecting path currently in-use. o During preemption, shared segment resources MAY be used by both existing traffic (that is being preempted) and higher priority traffic only for a short period. o During preemption, if there is an over subscription of resources protected traffic SHOULD be treated as defined in [RFC5712] or [RFC3209] 5.3. Notification When a working path endpoint has a protection switch triggered, it SHOULD attempt to switch the traffic to the protection path and request the commitment of protection resources. If the necessary shared resources are are unavailable to be committed to the protection path, endpoints of the requesting working path SHALL recognize protection switchover failure and the switchover MAY not be completed. Similarly, if preemption is supported and as a result of the Weingarten, et al. Expires June 12, 2014 [Page 9] Internet-Draft MPLS SMP Req December 9, 2013 committing of resources to a different working path that performed a protection switch, and the resources currently committed for a particular working path are being preempted then the endpoints of the thus affected working path whose traffic is being preempted SHALL realize that the resources are being preempted. 5.4. Revertive protection switching When the working path detects that the condition that triggered the protection switch has cleared, it is possible to either revert to using the working path resources or continue to utilize the protection resources. Continuing the use of protection resources allows the operator to delay the disruption of service caused by the switchover until periods of lighter traffic. The switchover would need to be performed via an explicit operator command unless the protection resources are preempted by a higher priority fault. Hence, both automatic and manual revertive behaviors MUST be supported for hard-preemtion in an SMP domain. Normally the network should revert to use of the working path resources in order to clear the protection resources for protection of other path triggers. However, the protocol MUST support non-revertive configurations. During switchover from working path to protected path, if encountered a resource commitment failure due to resource unavailability or some other failure, as identified in sec 4.3, a mechanism to realize such failure by an initiator SHALL be used. At the same time the resources on the protected path already committed for the protected traffic, in order to switchover the traffic, MUST be released. 5.5. Protection switching time Protection switching time refers to the transfer time (Tt) defined in [G.808.1] and recovery switching time defined in [RFC4427], and is defined as the interval after a switching trigger is identified until the traffic begins to be transmitted on the protection path. This time is exclusive of the time needed to initiate the protection switching process after a failure occurred, and the time needed to complete preemption of existing traffic on the shared segments as described in Section 4.2. The former, which is known as detection and correlation time in [RFC4427] is related to the OAM or management process, but the latter is related to the actions within an SMP domain. Support for a protection switching time of 50ms is dependent upon the initial switchover to the protection path, but the preemption time Should also be taken into account to minimize total service interruption time. 5.6. Timers Weingarten, et al. Expires June 12, 2014 [Page 10] Internet-Draft MPLS SMP Req December 9, 2013 In order to prevent multiple switching actions for a single switching trigger, SMP SHOULD be controlled by a hold-off timer that would allow lower level mechanisms to complete their switching actions before invoking SMP protection actions. In addition, to prevent an unstable recovering working path from invoking intermittent switching operation, SMP SHOULD employ a wait- to-restore timer during any reversion switching. 5.7. Communicating information and channel SMP in hard-preemption mode SHOULD include support for communicating information to coordinate the use of the shared protection resources among multiple working paths. The message encoding and communication channel between the nodes of the shared protection resource and the endpoints of the protection path are out of the scope of this document. SMP in hard-preemption mode SHOULD provide a communication channel, along the protection path, between the endpoints of the protection path to support fast protection switching. 6. Manageability Considerations The network management architecture and requirements for MPLS-TP are specified in [RFC5951]. They derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. This document do not introduce any new Manageability requirements beyond those covered in those documents 7. Security Considerations General security considerations for MPLS-TP are covered in [RFC5921]. The security considerations for the generic associated control channel are described in [RFC5586]. This document introduces no new security considerations beyond those covered in those documents. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Acknowledgements Weingarten, et al. Expires June 12, 2014 [Page 11] Internet-Draft MPLS SMP Req December 9, 2013 The authors would like to thank everyone who is involved in Shared Mesh Protection for MPLS-TP discussions. Special thanks to Eric Osborne for facilitating these and this document is outcome of those discussions. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5654] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, "Requirements for the Transport Profile of MPLS", RFC 5654, Sept 2009. [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability Framework", RFC 6372, Sept 2011. [RFC6378] Sprecher, N., Bryant, S., Osborne, E., Fulignoli, A., and Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378, Nov 2011. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, Oct 2004. [G.808.1] ITU, "Generic Protection Switching - Linear trail and subnetwork protection", ITU-T G.808.1, Feb 2010. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for GMPLS", RFC 4427, March 2006. [RFC4428] Mannie, E. and D. Papadimitriou, "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006. [RFC5712] Meyer, M. and JP. Vasseur, "MPLS Traffic Engineering Soft Preemption", RFC 5712, January 2010. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., and V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Authors' Addresses Yaacov Weingarten Weingarten, et al. Expires June 12, 2014 [Page 12] Internet-Draft MPLS SMP Req December 9, 2013 34 Hagefen St. Karnei Shomron, 4485500 Israel Phone: Email: wyaacov@gmail.com Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States Email: aldrin.ietf@gmail.com Ping Pan Infinera Email: ppan@infinera.com Jeong-dong Ryoo ETRI 161 Gajeong Yuseong, Daejeon 305-700 South Korea Email: ryoo@etri.re.kr Greg Mirsky Ericsson Email: gregory.mirsky@ericsson.com Weingarten, et al. Expires June 12, 2014 [Page 13]