Network Working Group Z. Cui Internet-Draft R. Winter Intended status: Informational NEC Expires: August 18, 2014 February 14, 2014 Use Cases and Requirements for MPLS-TP multi-failure protection draft-cui-mpls-tp-mfp-use-case-and-requirements-01 Abstract MPLS Transport Profile (MPLS-TP) linear protection is defined in [RFC6378]. That however is limited to 1+1 and 1:1 protection and is not able to care that the multiple failures are occurred on both working and protection paths. This document describes why we need to consider the case for multiple failures, and lists some requirements for multi-failure protection (MFP) functionality. 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 August 18, 2014. Copyright Notice Copyright (c) 2014 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 Cui & Winter Expires August 18, 2014 [Page 1] Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. Summary of the problem statement and use case . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Resource reservation . . . . . . . . . . . . . . . . . . 5 4.3. Protection switching time . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Network survivability - the ability of the network to remain functioning in the face of failures - is an important property of a network built to provide service guarantees. For MPLS-TP networks, the protocol for linear protection is defined in [RFC6378]. That protocol can restores user traffic when a single failure condition is detected. If need take a long time to repair, some operators may have to find other protection resources to protect the user traffic since the user traffic is unprotected. However, common linear protection not allows an overlap between a protection group and a other different path. This document describes the detail of the problem statements, and lists a number of requirements for new protection functionality. 1.1. Document scope This document describes the use cases and requirements for multi- failure protection in MPLS-TP networks without the use of control plane protocols. Existing solutions based on control plane such as GMPLS may be able to restore user traffic when multiple failures occur. Some networks however do not use full control plane operation for reasons such as service provider preferences, certain limitations or the requirement for fast service restoration (faster than achievable with control plane mechanisms). These networks are the Cui & Winter Expires August 18, 2014 [Page 2] Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014 focus of this document which defines a set of requirements for multi- failure protection not based on control plane support. 1.2. Requirements 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]. 2. Summary of the problem statement and use case The following Figure 1 shows the network topology of an operation scenario. As shown in the Figure 1, there are three independent paths i, j and k between LER-A and LER-B. We assume a protection domain between LER-A and LER-B, using path i (working path) and j (protection path). Additionally, path k is a sharing resource. Path i (working path) ++++++++++++++++++++++++++++ + + + + +-----+ +-----+ | | Path j (protection path) | | |LER-A|--------------------------------|LER-Z| | | | | +-----+ +-----+ * * * Path k (sharing resource) * **************************** Figure 1: The network topology of an operation scenario When a failure is detected in path i, we can restore user traffic to path j using existing protection schemes such as 1+1 protection and 1:1 protection. However, since the user traffic is unprotected until the working path is repaired, some operators may take the following measures to protect the user service. 1) After a single failure condition is detected on the working path i, 1-1) Remove the protection group between path i and j. 1-2) Create a new protection group between path j and k to protect user traffic. Cui & Winter Expires August 18, 2014 [Page 3] Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014 2) The failure condition of working path is repaired, 2-1) In order to clear the sharing resources, remove the relationship of protection group between path j and k. 2-2) Re-create a protection group between path i and j. However, above progresses are very complex, may increase the risk for operation mistake and pressure. An automatic restoration mechanism such as GMPLS [RFC3945], are well-known. But some operators in particular in the transport sector that do not operate their MPLS networks under the control plane. Therefore, we suggest that define a non-control-plane based protection scheme that allows an overlap between a protection group and other paths. 3. Architecture Figure 2 shows a new protection domain with a single working path and N protection paths. Each of the protection paths MAY be assigned a priority that could decide which protection path to use, i.e. protection path #1 > protection path #2, thus, the protection path #2 will not be selected to deliver user traffic when protection path #1 is available. +-----+ +-----+ | |=============================| | |LER-A| Working Path |LER-Z| | | | | | |*****************************| | | | Protection Path #1 | | | | | | | |*****************************| | | | Protection Path #2 | | | | | | | | ooo | | | | | | | |*****************************| | | | Protection Path #N | | +-----+ +-----+ |--------Protection Domain----| Figure 2: A basic example of multi-failure protection 4. Requirements This section contains the requirements on the protection functionality derived from the problem statement and use case in section 2. Cui & Winter Expires August 18, 2014 [Page 4] Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014 4.1. Configuration Before failure detection and/or notification, one or more protection paths are instantiated between the same ingress-egress node pair as the working path shown in figure 2. The protection paths MAY be added or removed if necessary, but any performance degradation of user traffic should be avoided. 4.2. Resource reservation The resource of the protection paths MAY be shared with other transport paths. In this case, the multiple failure protection SHOULD be supported by a shared mesh protection solution. The solution is out of scope of this document. 4.3. Protection switching time Protection switching time refers to the transfer time (Tt) defined in [G.808.1] and recovery switching time defined in [RFC4427]. A multiple failure protection solution MUST support switching time within 50 ms from the moment of fault detection in a network. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Normative References [I-D.ietf-mpls-smp-requirements] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. Mirsky, "Requirements for MPLS Shared Mesh Protection", draft-ietf-mpls-smp-requirements-03 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. Cui & Winter Expires August 18, 2014 [Page 5] Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. Authors' Addresses Zhenlong Cui NEC Email: c-sai@bx.jp.nec.com Rolf Winter NEC Email: Rolf.Winter@neclab.eu Cui & Winter Expires August 18, 2014 [Page 6]