idnits 2.17.1 draft-cui-mpls-tp-mfp-use-case-and-requirements-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6378]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3945' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC4427' is defined on line 246, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-smp-requirements-06 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-smp-requirements (ref. 'I-D.ietf-mpls-smp-requirements') ** Downref: Normative reference to an Informational RFC: RFC 4427 Summary: 3 errors (**), 0 flaws (~~), 5 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: Standards Track NEC 5 Expires: January 5, 2015 H. Shah 6 Ciena 7 S. Aldrin 8 Huawei Technologies 9 M. Daikoku 10 KDDI 11 July 4, 2014 13 Use Cases and Requirements for MPLS-TP multi-failure protection 14 draft-cui-mpls-tp-mfp-use-case-and-requirements-02 16 Abstract 18 The basic survivability technique has been defined in Multiprotocol 19 Label Switching Transport Profile (MPLS-TP) network [RFC6378]. That 20 protocol however is limited to 1+1 and 1:1 protection, not designed 21 to handle multi-failure protection. 23 This document introduces some use cases and requirements for multi- 24 failure protection functionality. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. m:n protection architecture . . . . . . . . . . . . . . . . . 3 64 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Increase service availability . . . . . . . . . . . . . . 4 66 3.2. Reduce the backup costs . . . . . . . . . . . . . . . . . 5 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Today's packet optical transport networks are able to concentrate 76 large volumes of traffic onto a relatively small number of nodes and 77 links. As a result, the failure of a single network element can 78 potentially interrupt a large amount of traffic. For this reason, 79 ensuring survivability through fault-tolerant network design is an 80 important network design objective. 82 The basic survivability technique has been defined in MPLS-TP network 83 [RFC6378]. That protocol however is limited to 1+1 and 1:1 84 protection, not designed to handle multi-failure protection. 86 The case of multi-failure condition is very rare, but not unheard of. 87 For example, when a working path was closed by network operator for 88 construction work, the network service will become a hazardous 89 condition. During this time, if another failure (e.g. a human-error 90 or network entities failure) is occurred on the protection path, than 91 the operator can't meet service level agreements (SLA). 93 A network must be able to handle multiple failures even that are a 94 rare case, because especially some high-priority services such as 95 emergency telephone calls request to network service provider 96 guarantee their service connections in a timely manner in any 97 situation. 99 On the other hand, many network operators have a very limited budget 100 for improving network survivability. This requires a design 101 approach, which takes budget limitations into consideration. 103 To increase the service availability and to reduce the backup network 104 costs, we propose extend the 1+1 and 1:1 protection protocol to 105 support the m:n architecture type. 107 1.1. Document scope 109 This document describes the use cases and requirements for multi- 110 failure protection in MPLS-TP networks without the use of control 111 plane protocols. Existing solutions based on control plane such as 112 GMPLS may be able to restore user traffic when multiple failures 113 occur. Some networks however do not use full control plane operation 114 for reasons such as service provider preferences, certain limitations 115 or the requirement for fast service restoration (faster than 116 achievable with control plane mechanisms). These networks are the 117 focus of this document which defines a set of requirements for multi- 118 failure protection not based on control plane support. 120 1.2. Requirements notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. m:n protection architecture 128 The following Figure 1 shows a protection domain with n working paths 129 and m protection paths. when a working path is determined to 130 impaired, its normal traffic must be assigned to a protection path if 131 a protection path is available. To reduce the backup network costs, 132 m protection paths are sharing backup resource for n working paths, 133 where m <= n typically. The bandwidth of each protection paths 134 should be allocated enough to protect any of the n working paths. 136 +-----+ +-----+ 137 | |=============================| | 138 |LER-A| Working Path #1 |LER-Z| 139 | | | | 140 | |=============================| | 141 | | .... | | 142 | | | | 143 | |=============================| | 144 | | Working Path #n | | 145 | | | | 146 | | | | 147 | | | | 148 | |*****************************| | 149 | | Protection Path #1 | | 150 | | | | 151 | |*****************************| | 152 | | .... | | 153 | | | | 154 | |*****************************| | 155 | | Protection Path #m | | 156 | | | | 157 +-----+ +-----+ 158 |--------Protection Domain--------| 160 Figure 1: m:n ptorection domain 162 3. Use cases 164 3.1. Increase service availability 166 With technological advancement of mobile services or data center 167 services, dependencies and business impact of network services have 168 been increased phenomenally. End-users expectations of service 169 availability also are increasing, which is driving service providers 170 enhance their network's availability. 172 Network availability must be maintained especially for high-priority 173 services such as emergency telephone calls, even during natural 174 disasters and other catastrophic events such as earthquake or 175 tsunami. Existing 1+1 or 1:n protection however is limited to cover 176 single failure and no sufficient to maintain disaster recovery. 178 The m:n protection can increase service availability because it take 179 multiple protection paths to ensuring high-priority services continue 180 to operate on the 2nd, 3rd or Nth alternate backup, at least one of m 181 protection paths is a available. 183 3.2. Reduce the backup costs 185 Network costs driven by high traffic growth rates are rising 186 steadily, but revenues are no increased in direct proportion to 187 traffic growth rates. This requires a design approach, which takes 188 budget limitations into consideration. 190 Existing protection schemes such as 1+1 protection meet the sub 50 ms 191 performance requirement but only protect against a single failure and 192 are too costly. 194 The m:n protection is a useful solution, that can reduce the backup 195 costs because m dedicated protection paths are sharing backup paths 196 for n working paths, where m =< n typically. 198 The shared Mesh Protection (SMP) also can reduce the backup costs as 199 described in [I-D.ietf-mpls-smp-requirements]. SMP however is based 200 the 1:1 protection and does not able to care that the multiple 201 failures are occurred on both working and protection paths. However, 202 combine use of SMP and a set of m:1 protections to make a m:n 203 protection likely, may be better able to recovers the multiple 204 failures. 206 4. Requirements 208 Some recovery requirements are defined [RFC5654]. That however is 209 limited to cover single failure and is not able to care that the 210 multiple failures. This Section 4 extends the requirements to 211 support the multiple failures scenarios. 213 MPLS-TP MUST support m:n protection with the following requirements: 215 R1 The m:n protection MUST protects against multiple failures that 216 are simultaneously-detected on both of working path and 217 protection path or more than one multiple working paths. 219 R2 Some priority schemes MUST be provided, because the backup 220 resources are shared by multiple working paths dynamically. 222 R3 TBD 224 5. Security Considerations 226 TBD 228 6. IANA Considerations 230 TBD 232 7. Normative References 234 [I-D.ietf-mpls-smp-requirements] 235 Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 236 Mirsky, "Requirements for MPLS-TP Shared Mesh Protection", 237 draft-ietf-mpls-smp-requirements-06 (work in progress), 238 June 2014. 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, March 1997. 243 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 244 (GMPLS) Architecture", RFC 3945, October 2004. 246 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 247 Restoration) Terminology for Generalized Multi-Protocol 248 Label Switching (GMPLS)", RFC 4427, March 2006. 250 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 251 and S. Ueno, "Requirements of an MPLS Transport Profile", 252 RFC 5654, September 2009. 254 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 255 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 256 Protection", RFC 6378, October 2011. 258 Authors' Addresses 260 Zhenlong Cui 261 NEC 263 Email: c-sai@bx.jp.nec.com 265 Rolf Winter 266 NEC 268 Email: Rolf.Winter@neclab.eu 270 Himanshu Shah 271 Ciena 273 Email: hshah@ciena.com 274 Sam Aldrin 275 Huawei Technologies 277 Email: aldrin.ietf@gmail.com 279 Masahiro Daikoku 280 KDDI 282 Email: ms-daikoku@kddi.com