idnits 2.17.1 draft-cui-mpls-tp-mfp-use-case-and-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Requirements 58' is mentioned on line 168, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-mpls-smp-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cui 3 Internet-Draft R. Winter 4 Intended status: Informational NEC 5 Expires: April 25, 2014 October 22, 2013 7 Use Cases and Requirements for MPLS-TP multi-failure protection 8 draft-cui-mpls-tp-mfp-use-case-and-requirements-00 10 Abstract 12 This document describes the use cases and requirements for multi- 13 failure protection (MFP) in MPLS-TP networks. This document would be 14 used to implement MFP for MPLS-TP data paths without any control 15 plane. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 25, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 2 56 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Single-failure condition . . . . . . . . . . . . . . . . 3 59 3.2. Resource allocation failure condition . . . . . . . . . . 4 60 3.3. Multi-failure condition . . . . . . . . . . . . . . . . . 4 61 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Resource reservation . . . . . . . . . . . . . . . . . . 4 64 4.3. Protection switching time . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 Network survivability - the ability of the network to remain 73 functioning in the face of failures - is an important property of a 74 network built to provide service guarantees. For MPLS-TP networks, 75 the protocol for linear protection is defined in [RFC6378]. That 76 protocol however is limited to 1+1 and 1:1 protection and not 77 designed to handle multi-failure protection. 79 This document describes use cases to clarify the utility and 80 necessity of multi-failure survivability. Based on these use cases, 81 this document lists a number of requirements for protection 82 functionality in support of multi-failure recovery. 84 1.1. Document scope 86 This document describes the use cases and requirements for multi- 87 failure protection in MPLS-TP networks without the use of control 88 plane protocols. Existing control plane-based solutions such as 89 using GMPLS may be able to restore user traffic when multiple 90 failures occur. Some networks however do not use full control plane 91 operation for reasons such as service provider preferences, certain 92 limitations or the requirement for fast service restoration (faster 93 than achievable with control plane mechanisms). These networks are 94 the focus of this document which defines a set of requirements for 95 multi-failure protection not based on control plane support. 97 1.2. Requirements notation 98 Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Architecture 106 Figure 1 show a protection domain with a single working path and N 107 protection paths. Each of the protection paths MAY be assigned a 108 priority that could decide which protection path to use, i.e. 109 protection path #1 > protection path #2, thus, the protection path #2 110 will does not be selected to deliver user traffic when protection 111 path #1 is available. 113 All examples will be based on the network topology in Figure 1, with 114 a working path and the protection path referenced. The end-points of 115 the protection domain will be referred to as LER-A and LER-Z. 117 +-----+ +-----+ 118 | |=============================| | 119 |LER-A| Working Path |LER-Z| 120 | | | | 121 | |*****************************| | 122 | | Protection Path #1 | | 123 | | | | 124 | |*****************************| | 125 | | Protection Path #2 | | 126 | | | | 127 | | ooo | | 128 | | | | 129 | |*****************************| | 130 | | Protection Path #N | | 131 +-----+ +-----+ 133 |--------Protection Domain--------| 135 Figure 1: A basic sample of multi-failure protetection 137 3. Use Cases 139 3.1. Single-failure condition 141 Most failure cases in transport networks are caused by a single 142 failure condition. Common protection schemes include 1+1 protection 143 and 1:N protection which can restore user traffic after a single 144 failure condition. Before the transport path is repaired, the user 145 traffic is unprotected. During this time, another failure (e.g. a 146 human-error) could significantly affect the network. Such multi- 147 failure situations could put pressure on network operations. A 149 Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 151 multi-failure protection solution provisions one or more backup paths 152 before multiple failure occur. 154 3.2. Resource allocation failure condition 156 In shared mesh protection ([I-D.ietf-mpls-smp-requirements]), when 157 the reserved resources are allocated for a particular protection 158 path, there may not be sufficient resources available for an 159 additional protection path. This then implies that if an additional 160 working path triggers a protection switch, the resource allocation 161 failure condition may be occurred. If a sufficient resource 162 available for an additional protection path, it may help for increase 163 the utility of shared mesh protection. 165 3.3. Multi-failure condition 167 [RFC5654] mentions that MPLS-TP recovery must meet SLA requirements 168 over multiple domains [Requirements 58]. When a single failure 169 occurs in each domain, it could affect both the working path and the 170 protection path. A multi-failure protection solution might also be 171 helpful in this case. 173 4. Requirements 175 This section contains the requirements on the protection 176 functionality derived from the use-cases in section 3. 178 4.1. Configuration 180 Before failure detection and/or notification, one or more protection 181 paths are instantiated between the same ingress-egress node pair as 182 the working path as shown in figure 1. The protection paths MAY be 183 added or removed when need, but should be avoided might miss any 184 performance degradation of user traffic. 186 4.2. Resource reservation 188 The resource of the protection path MAY be shared with other 189 transport paths. In this case, the multiple failure protection 190 SHOULD be supported by a shared mesh protection solution. The 191 solution is out of scope of this document. 193 4.3. Protection switching time 195 Protection switching time refers to the transfer time (Tt) defined in 196 G.808.1 and recovery switching time defined in [RFC4427]. A multiple 197 failure protection solution MUST support switching time within 50 ms 198 from the moment of fault detection in a network. 200 Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013 202 5. Security Considerations 204 TBD 206 6. IANA Considerations 208 TBD 210 7. Normative References 212 [I-D.ietf-mpls-smp-requirements] 213 Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., Mirsky, G., 214 Allan, D., King, D., and T. Cheung, "Requirements for MPLS 215 Shared Mesh Protection", draft-ietf-mpls-smp- 216 requirements-01 (work in progress), September 2013. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 222 Restoration) Terminology for Generalized Multi-Protocol 223 Label Switching (GMPLS)", RFC 4427, March 2006. 225 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 226 and S. Ueno, "Requirements of an MPLS Transport Profile", 227 RFC 5654, September 2009. 229 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 230 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 231 Protection", RFC 6378, October 2011. 233 Authors' Addresses 235 Zhenlong Cui 236 NEC 238 Email: c-sai@bx.jp.nec.com 240 Rolf Winter 241 NEC 243 Email: Rolf.Winter@neclab.eu