Network Working Group Z. Cui Internet-Draft R. Winter Intended status: Informational NEC Expires: April 25, 2014 October 22, 2013 Use Cases and Requirements for MPLS-TP multi-failure protection draft-cui-mpls-tp-mfp-use-case-and-requirements-00 Abstract This document describes the use cases and requirements for multi- failure protection (MFP) in MPLS-TP networks. This document would be used to implement MFP for MPLS-TP data paths without any control 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 April 25, 2014. Copyright Notice Copyright (c) 2013 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. Cui & Winter Expires April 25, 2014 [Page 1] Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 2 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 2 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Single-failure condition . . . . . . . . . . . . . . . . 3 3.2. Resource allocation failure condition . . . . . . . . . . 4 3.3. Multi-failure condition . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Resource reservation . . . . . . . . . . . . . . . . . . 4 4.3. Protection switching time . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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 however is limited to 1+1 and 1:1 protection and not designed to handle multi-failure protection. This document describes use cases to clarify the utility and necessity of multi-failure survivability. Based on these use cases, this document lists a number of requirements for protection functionality in support of multi-failure recovery. 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 control plane-based solutions such as using 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 focus of this document which defines a set of requirements for multi-failure protection not based on control plane support. 1.2. Requirements notation Cui & Winter Expires April 25, 2014 [Page 2] Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 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. Architecture Figure 1 show a 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 does not be selected to deliver user traffic when protection path #1 is available. All examples will be based on the network topology in Figure 1, with a working path and the protection path referenced. The end-points of the protection domain will be referred to as LER-A and LER-Z. +-----+ +-----+ | |=============================| | |LER-A| Working Path |LER-Z| | | | | | |*****************************| | | | Protection Path #1 | | | | | | | |*****************************| | | | Protection Path #2 | | | | | | | | ooo | | | | | | | |*****************************| | | | Protection Path #N | | +-----+ +-----+ |--------Protection Domain--------| Figure 1: A basic sample of multi-failure protetection 3. Use Cases 3.1. Single-failure condition Most failure cases in transport networks are caused by a single failure condition. Common protection schemes include 1+1 protection and 1:N protection which can restore user traffic after a single failure condition. Before the transport path is repaired, the user traffic is unprotected. During this time, another failure (e.g. a human-error) could significantly affect the network. Such multi- failure situations could put pressure on network operations. A Cui & Winter Expires April 25, 2014 [Page 3] Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 multi-failure protection solution provisions one or more backup paths before multiple failure occur. 3.2. Resource allocation failure condition In shared mesh protection ([I-D.ietf-mpls-smp-requirements]), when the reserved resources 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 resource allocation failure condition may be occurred. If a sufficient resource available for an additional protection path, it may help for increase the utility of shared mesh protection. 3.3. Multi-failure condition [RFC5654] mentions that MPLS-TP recovery must meet SLA requirements over multiple domains [Requirements 58]. When a single failure occurs in each domain, it could affect both the working path and the protection path. A multi-failure protection solution might also be helpful in this case. 4. Requirements This section contains the requirements on the protection functionality derived from the use-cases in section 3. 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 as shown in figure 1. The protection paths MAY be added or removed when need, but should be avoided might miss any performance degradation of user traffic. 4.2. Resource reservation The resource of the protection path 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. Cui & Winter Expires April 25, 2014 [Page 4] Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 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., Mirsky, G., Allan, D., King, D., and T. Cheung, "Requirements for MPLS Shared Mesh Protection", draft-ietf-mpls-smp- requirements-01 (work in progress), September 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [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 April 25, 2014 [Page 5]