| Network Working Group | Y. Weingarten |
| Internet-Draft | S. Aldrin |
| Intended status: Informational | Huawei Technologies |
| Expires: January 05, 2013 | July 06, 2012 |
Requirements for MPLS Shared Mesh Protection
draft-weingarten-mpls-smp-requirements-00.txt
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 should be used as a basis for the definition of the mechanism that would be used to implement SMP for MPLS data paths, in networks that do not employ a control plane for its operation.
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 05, 2013.
Copyright (c) 2012 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.
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 conserve 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 allocated and used by both the working and protection paths. Applying 1:1 protection requires that all of the resources are allocated, 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.
Shared Mesh Protection (SMP) supports a limited form of resource sharing of the protection resources, while providing protection for multiple data paths that may not have common endpoints and do not share common points of failure. The basic configuration for data paths that employ SMP is shown in Figure 1. In this figure, we show two working paths [ABCDE] and [VWXYZ] that are protected (by 1:1 linear protection) protection paths [APQRE] and [VPQRZ] respectively. The segment [PQR] and all of its protection resources are shared by both of the protection paths.
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
[RFC6372], based upon the definitions in [RFC4427] makes the differentiation between "protection" and "restoration" dependent upon the dynamism of the resource allocation. In SMP, the resources of the protection paths are reserved at the time of path creation. However, the allocation of the full resources, at least for the shared segments will only be finalized at the time that the protection path is actually activated. Therefore, for the purists – regarding the terminology – SMP lies somewhere between protection and restoration.
[RFC5654] also 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 statically configured operator networks.
Protection Switching Control (PSC) defines the protection switching process, logic and protocol messages, based on the SMP actions sent and received from participating LSRs. Definition of logic and specific protocol messaging is out of scope of this document.
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 MPLS networks, and not necessarily as part of the Transport Profile of MPLS.
David Allan, Gregory Mirsky, Daniel King
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].
This draft uses the following acronyms:
| LSP | Label Switched Path |
| PSC | Protection State Coordination protocol |
| SLA | Service Level Agreement |
| SMP | Shared Mesh Protection |
| SRLG | Shared Risk Link Group |
Figure 1 shows a very basic configuration of working and protection paths that may employ SMP. We may consider a slightly more involved configuration, such as the one in Figure 2 in order to identify certain basic characteristics of an SMP mesh network.
A----B----C----D----E---N
\ / / \
\ M ---/-- \
\ / \ \
P-----Q-----R-----S----T
/| \ \ \ \
/ F---G---H J--K---L \
/ \
V------W-------X-------Y-------Z
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 the main feature of the network that defines it as an SMP network is the fact that the segment [PQRST], that is a sub-segment of p5, is the union of all the shared segments while being a whole shared segment of one of the protection paths.
In other words, the main feature of an SMP "protection domain" will be the segment that is the union of all the shared segments of the protection paths. We can further identify "protection groups" as the 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].
Typical deployment of SMP would require various network planning activities. These would include:
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 verify that the shared resources are allocated for this protection path. The allocation of resources is dependent upon their availability at each of the shared segments.
When the reserved resources of the shared segments are allocated for a particular protection path, there may not be sufficient resources available for an additional protection path. This then implies that if an additional working path triggers a protection switch the allocation of the resources may fail and MUST be treated as described below in Section 4.3. In order to optimize the operation of the allocation and preparing for cases of multiple working path failures, the allocation of the shared resources SHALL be coordinated between the different working paths in the SMP network.
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. 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.
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. On the shared segments, the protection resources may be reserved but would not be allocated until requested as part of a protection switch.
When a working path identifies a protection switching trigger it SHOULD verify that the necessary protection resources are available on the protection path. The resources may not be available because they have been allocated to the protection of a higher priority working path, as described above.
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 and require the ability of performing SMP protection while utilizing data-plane tools for coordination of the protection switching. This requirement is emphasized in different areas of [RFC5654] for MPLS-TP environments. Therefore, it is imperative that it be possible to perform all of the coordination needed for SMP via data plane operations.
If more than one working path is triggering a protection switch 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, 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, the following behavior SHOULD be supported:
When a working path identifies a trigger for implementing a switchover to the protection path, it SHALL attempt to switchover the traffic to the protection path and requesting the allocation of the resources for this protected traffic. If the protection path is not able to allocate the necessary resources (e.g. the resources are being used for protected traffic of higher priority), a notification SHALL be sent to both endpoints of the requesting working path indicating that the requested switchover cannot be fulfilled.
Similarly, if preemption is supported and as a result of the allocation of resources to a different working path that triggered a protection switch, the resources currently allocated for a particular working path are being preempted then a notification SHALL be sent to the endpoints of the working path whose traffic is being preempted indicating that the resources are being preempted.
In general, protection switching time 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 complete preemption of existing traffic on the shared segments as described in Section 4.3. Therefore, support for a switcing time of 50ms is dependent upon the initial switchover to the protection path
In order to prevent multiple switching actions for a single switching trigger, SMP SHOULD be controlled 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.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
To be added in future version.
To be added in future version.
TBD
| [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. |
| [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. |