idnits 2.17.1 draft-cui-mpls-tp-mfp-use-case-and-requirements-01.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 (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.808.1' is mentioned on line 212, but not defined == Unused Reference: 'I-D.ietf-mpls-smp-requirements' is defined on line 226, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-smp-requirements-03 Summary: 1 error (**), 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: Informational NEC 5 Expires: August 18, 2014 February 14, 2014 7 Use Cases and Requirements for MPLS-TP multi-failure protection 8 draft-cui-mpls-tp-mfp-use-case-and-requirements-01 10 Abstract 12 MPLS Transport Profile (MPLS-TP) linear protection is defined in 13 [RFC6378]. That however is limited to 1+1 and 1:1 protection and is 14 not able to care that the multiple failures are occurred on both 15 working and protection paths. 17 This document describes why we need to consider the case for multiple 18 failures, and lists some requirements for multi-failure protection 19 (MFP) functionality. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 18, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 2 57 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 2. Summary of the problem statement and use case . . . . . . . . 3 59 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Resource reservation . . . . . . . . . . . . . . . . . . 5 63 4.3. Protection switching time . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Network survivability - the ability of the network to remain 72 functioning in the face of failures - is an important property of a 73 network built to provide service guarantees. 75 For MPLS-TP networks, the protocol for linear protection is defined 76 in [RFC6378]. That protocol can restores user traffic when a single 77 failure condition is detected. 79 If need take a long time to repair, some operators may have to find 80 other protection resources to protect the user traffic since the user 81 traffic is unprotected. However, common linear protection not allows 82 an overlap between a protection group and a other different path. 84 This document describes the detail of the problem statements, and 85 lists a number of requirements for new protection functionality. 87 1.1. Document scope 89 This document describes the use cases and requirements for multi- 90 failure protection in MPLS-TP networks without the use of control 91 plane protocols. Existing solutions based on control plane such as 92 GMPLS may be able to restore user traffic when multiple failures 93 occur. Some networks however do not use full control plane operation 94 for reasons such as service provider preferences, certain limitations 95 or the requirement for fast service restoration (faster than 96 achievable with control plane mechanisms). These networks are the 97 focus of this document which defines a set of requirements for multi- 98 failure protection not based on control plane support. 100 1.2. Requirements notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Summary of the problem statement and use case 108 The following Figure 1 shows the network topology of an operation 109 scenario. As shown in the Figure 1, there are three independent 110 paths i, j and k between LER-A and LER-B. We assume a protection 111 domain between LER-A and LER-B, using path i (working path) and j 112 (protection path). Additionally, path k is a sharing resource. 114 Path i (working path) 115 ++++++++++++++++++++++++++++ 116 + + 117 + + 118 +-----+ +-----+ 119 | | Path j (protection path) | | 120 |LER-A|--------------------------------|LER-Z| 121 | | | | 122 +-----+ +-----+ 123 * * 124 * Path k (sharing resource) * 125 **************************** 127 Figure 1: The network topology of an operation scenario 129 When a failure is detected in path i, we can restore user traffic to 130 path j using existing protection schemes such as 1+1 protection and 131 1:1 protection. 133 However, since the user traffic is unprotected until the working path 134 is repaired, some operators may take the following measures to 135 protect the user service. 137 1) After a single failure condition is detected on the working path 138 i, 140 1-1) Remove the protection group between path i and j. 142 1-2) Create a new protection group between path j and k to protect 143 user traffic. 145 2) The failure condition of working path is repaired, 147 2-1) In order to clear the sharing resources, remove the 148 relationship of protection group between path j and k. 150 2-2) Re-create a protection group between path i and j. 152 However, above progresses are very complex, may increase the risk for 153 operation mistake and pressure. An automatic restoration mechanism 154 such as GMPLS [RFC3945], are well-known. But some operators in 155 particular in the transport sector that do not operate their MPLS 156 networks under the control plane. Therefore, we suggest that define 157 a non-control-plane based protection scheme that allows an overlap 158 between a protection group and other paths. 160 3. Architecture 162 Figure 2 shows a new protection domain with a single working path and 163 N protection paths. Each of the protection paths MAY be assigned a 164 priority that could decide which protection path to use, i.e. 165 protection path #1 > protection path #2, thus, the protection path #2 166 will not be selected to deliver user traffic when protection path #1 167 is available. 169 +-----+ +-----+ 170 | |=============================| | 171 |LER-A| Working Path |LER-Z| 172 | | | | 173 | |*****************************| | 174 | | Protection Path #1 | | 175 | | | | 176 | |*****************************| | 177 | | Protection Path #2 | | 178 | | | | 179 | | ooo | | 180 | | | | 181 | |*****************************| | 182 | | Protection Path #N | | 183 +-----+ +-----+ 184 |--------Protection Domain----| 186 Figure 2: A basic example of multi-failure protection 188 4. Requirements 190 This section contains the requirements on the protection 191 functionality derived from the problem statement and use case in 192 section 2. 194 4.1. Configuration 196 Before failure detection and/or notification, one or more protection 197 paths are instantiated between the same ingress-egress node pair as 198 the working path shown in figure 2. The protection paths MAY be 199 added or removed if necessary, but any performance degradation of 200 user traffic should be avoided. 202 4.2. Resource reservation 204 The resource of the protection paths MAY be shared with other 205 transport paths. In this case, the multiple failure protection 206 SHOULD be supported by a shared mesh protection solution. The 207 solution is out of scope of this document. 209 4.3. Protection switching time 211 Protection switching time refers to the transfer time (Tt) defined in 212 [G.808.1] and recovery switching time defined in [RFC4427]. A 213 multiple failure protection solution MUST support switching time 214 within 50 ms from the moment of fault detection in a network. 216 5. Security Considerations 218 TBD 220 6. IANA Considerations 222 TBD 224 7. Normative References 226 [I-D.ietf-mpls-smp-requirements] 227 Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. 228 Mirsky, "Requirements for MPLS Shared Mesh Protection", 229 draft-ietf-mpls-smp-requirements-03 (work in progress), 230 January 2014. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, March 1997. 235 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 236 (GMPLS) Architecture", RFC 3945, October 2004. 238 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 239 Restoration) Terminology for Generalized Multi-Protocol 240 Label Switching (GMPLS)", RFC 4427, March 2006. 242 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 243 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 244 Protection", RFC 6378, October 2011. 246 Authors' Addresses 248 Zhenlong Cui 249 NEC 251 Email: c-sai@bx.jp.nec.com 253 Rolf Winter 254 NEC 256 Email: Rolf.Winter@neclab.eu