idnits 2.17.00 (12 Aug 2021) /tmp/idnits21876/draft-zhang-mpls-tp-shared-mesh-protection-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5654]), 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 date (July 04, 2011) is 3974 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) == Missing Reference: 'G.smp' is mentioned on line 78, but not defined == Outdated reference: draft-ietf-mpls-tp-linear-protection has been published as RFC 6378 == Outdated reference: A later version (-02) exists of draft-ezy-mpls-1ton-protection-00 == Outdated reference: draft-ietf-mpls-lsp-ping-ttl-tlv has been published as RFC 7394 == Outdated reference: draft-ietf-mpls-tp-security-framework has been published as RFC 6941 == Outdated reference: draft-ietf-mpls-tp-survive-fwk has been published as RFC 6372 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group F. Zhang, Ed. 3 Internet-Draft WJ. He 4 Intended status: Standards Track ZTE 5 Expires: January 5, 2012 July 04, 2011 7 MPLS-TP Shared Mesh Protection 8 draft-zhang-mpls-tp-shared-mesh-protection-00 10 Abstract 12 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], 13 describes that MPLS-TP MUST support sharing of protection resources. 15 This document describes a shared mesh protection processing based on 16 the existing MPLS-TP linear protection switching mechanisms. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 5, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . . 3 54 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Shared Mesh Protection Architecture . . . . . . . . . . . . . . 4 56 3.1. Planning . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Changes to PSC . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Preemption . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative references . . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 For shared mesh protection, the protection resources are used to 71 protect multiple LSPs which do not all share the same end points. In 72 this way, mesh protection can substantially reduce the network 73 resources that have to be reserved in oder to provide protection. 74 The requirements have been described in [RFC5654] (Req. 66, 67, 68 75 and 69 ). Furthermore, the MPLS Transport Profile (MPLS-TP) 76 Survivability Framework [I-D.ietf-mpls-tp-survive-fwk] outlined the 77 operation. The shared mesh recovery schemes are also discussed in 78 [RFC4428] and [G.smp]. In (1:1)^n protection decribed in [RFC4428], 79 n working paths are protected by n dedicated protection paths while 80 sharing the same protection bandwidth. 82 This document describes a shared mesh protection processing based on 83 the concept of (1:1)^n recovery scheme defined in [RFC4428], and on 84 the protecion mechanism being developed in 85 [I-D.ietf-mpls-tp-linear-protection] [I-D.ezy-mpls-1ton-protection]. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2.1. Acronyms 95 This draft uses the following acronyms: 97 Ack Acknowledge 98 DNR Do not revert 99 FS Forced Switch 100 LER Label Edge Router 101 LO Lockout of protection 102 LSP Label Switched Path 103 MEP Maintenance Entity Group End Point 104 MIP Maintenance Entity Group Intermediate point 105 MPLS-TP Transport Profile for MPLS 106 MS Manual Switch 107 NR No Request 108 P2P Point-to-point 109 PSC Protection State Coordination Protocol 110 SF Signal Fail 111 SMPG Shared Mesh Protection Group 112 WTR Wait-to-Restore 114 3. Shared Mesh Protection Architecture 116 A simple case of shared mesh protection is illustrated in Figure 1. 117 Consider three paths W1 [via nodes A, B, C], W3 [via nodes D, E, F] 118 and W2 [via nodes X, Y, Z]. For these working paths do not share end 119 points, they cannot make use of 1:N protection even though they also 120 do not share any common points of failure. W1 may be protected by 121 the path P1 [via nodes A, G, P, Q, H, C}, W3 may be protected by the 122 path P3 [via nodes D, I, S, T, J, F], and W2 may be protected by the 123 path P2 [via nodes X, V, P, Q, R, S, T, W, Z]. For all these cases, 124 1:1 protection may be used. 126 In the event that the failure only affect one of the working paths, 127 the shared segment PQ or/and ST only carry traffic from the working 128 path being affected. Thus, it is possible for the network resources 129 on the segment PQ and ST to be shared by the two protection paths. 130 In this way, shared mesh protection can substantially reduce the 131 amount of network resources that have to be reserved to provide 132 protection. 134 A------B------C D------E------F 135 \ / \ / 136 G H I J 137 \ / \ / 138 P-----Q----R-----S-----T 139 / \ 140 V W 141 / \ 142 X--------------Y---------------Z 144 Figure 1: An example of shared mesh protection 146 3.1. Planning 148 As described in [I-D.ietf-mpls-tp-survive-fwk], the network becomes 149 more and more complex and the number of LSPs increases, the potential 150 for shared mesh protection also increase. However, this can quickly 151 become unmanageable owing to the increased complexity. Therefore, 152 shared mesh protection is normally pre-planned and configured by the 153 operator, although an automated sytem cannot be ruled out. This will 154 include but not limited to: 156 o Planning the shared mesh protection group (SMPG) which includes 157 the protected paths and protecting paths. Different SPMGs do not 158 share protection resources and are protected independently. This 159 means that working paths which have the higher protection 160 switching priority are planned to be in different SMPGs, in such a 161 way the higher priority paths will be protected mostly when one 162 failure affects different SMPGs. 164 o Configuring the mumbers of the SMPG. The working paths are 165 disjoint as far as possible in one SMPG, so they will not be 166 subject to common failures. Furthermore, each of the working 167 paths may be assigned a relative priority that could be used to 168 decide which working path would be protected in cases of conflict. 169 The relative priority is recommend to be reflected by the entity 170 number of the working path, which is compatible with 1:N linear 171 protection [I-D.ezy-mpls-1ton-protection]. When equal priority 172 requests occur simultaneously, the conflict is resolved in favour 173 of the request with the lowest entity number. 175 4. Changes to PSC 177 Protection State Coordination Protocol (PSC) defined in 178 [I-D.ezy-mpls-1ton-protection] is a multi-phased protocol, the end- 179 points perform any protection switching with waiting for 180 acknowledgement from the far end Label Edge Router (LER). The 181 protocol messages are transmitted using the G-ACh. 183 In order to support shared mesh protection, there is a need to make 184 changes to the format of the PSC message. In particular there is the 185 need to carry TTL TLV [I-D.ietf-mpls-lsp-ping-ttl-tlv] as one 186 optional TLV to indicate which node to receive the return PSC 187 message. Due to this change, the value of the Ver field for PSC 188 messages for a shared mesh protection domain MUST be set to 3. 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |0 0 0 1|Version| Reserved | PSC-CT | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 |Ver|Request|PT |R|K| Reserved1 | FPath | Path | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | TLV Length | Reserved2 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 ~ Optional TLVs ~ 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: Format of shared mesh protection PSC packet with a G-ACh 203 header 205 5. Basic Operation 207 This section illustrates the basic operation of the shared mesh 208 protection for the topology shown in Figure 1 based on the PSC. 210 If a unidirectional failure occurs on the W2 in the direction from 211 node Z to node X at time zero, the shared mesh protection will 212 operate as follows: 214 a. Node X detects the signal failure (SF), sends SF(2,0) to node P 215 with MPLS label TTL to control the hops between the node X and 216 node P. TTL TLV may be inserted in the PSC message as one 217 optional TLV to indicate that node P SHOULD use this value to 218 return the PSC message. 219 b. Node P compares the protection switching priority of W2 and W1. 220 For W1 is in normal state, node P sends SF(2,0) to node P with 221 MPLS label TTL to control the hops between the node P and node Q, 222 similarly, TTL TLV may be inserted in the PSC message as one 223 optional TLV to indicate that node S SHOULD use this value to 224 return the PSC message. The same processing is done on node S 225 and node T. 226 c. When Node Z receives the PSC message, it bridges and selects 227 traffic from P2. Then sends NR(0,2)Ack to node T, TTL TLV may be 228 inserted in the PSC message for the same reason. 229 d. Node T, S, Q, P relay the message until it arrives at node X. 230 e. Node X bridges and selects traffic from P2, then sends SF(2,2). 231 When node Z receives this message, it responses with NR(0,2). 233 5.1. Preemption 235 If a unidirectional failure occurs on the W1 in the direction from 236 node C to node A at time one, the shared mesh protection will operate 237 as follows: 239 a. Node A detects the SF on W1, sends SF(1,0) to node P with MPLS 240 label TTL to control the hops between the node A and node P. TTL 241 TLV may be inserted in the PSC message as one optional TLV to 242 indicate that node P SHOULD use this value to return the PSC 243 message. 244 b. Node P compares the protection switching priority of W2 and W1. 245 For W1's entity number is samller than W2's, it has the higher 246 priority under the SF events on both working paths. So node P 247 sends SF(1,0) on the path P1, and sends LO(2,2) on the path P2. 248 c. Node Q relays the message SF(1,0) on the path P1 to node A, and 249 sends LO(2,2) to node S when it receives LO(2,2) from the 250 previous hop on the path P2. 252 d. When Node C receives the SF(1,0) message, it bridges and selects 253 traffic from P1 and sends NR(0,1)Ack to node Q, TTL TLV may be 254 inserted in the PSC message for the same reason. While node Z 255 receives the LO(2,2) message, it bridges and selects traffic from 256 W2, and responses with NR(0,0). It should be noted that this may 257 cause loss of user data since W1 is still in a failure condition. 258 e. Node A bridges and selects traffic from P1, then sends SF(1,1) 259 when it receives NR(0,1)Ack. Node C will response with NR(0,1) 260 while receives this message. According to the received NR(0,0), 261 node X will bridge and select traffic from W2, and response with 262 SF(2,0), then node P relays with LO(2,0) towards node Z. 264 If a unidirectional failure occurs on the working path W3 (not on the 265 W1) in the direction from node F to node P at time one. Although the 266 resource preemption will fail, the basic PSC processing will be 267 similarly. 269 6. IANA Considerations 271 TBD. 273 7. Security Considerations 275 The generic security considerations for the data-plane of MPLS-TP are 276 described in the security framework document 277 [I-D.ietf-mpls-tp-security-framework] together with the required 278 mechanisms needed to address them. The security considerations for 279 the generic associated control channel are described in [RFC5586]. 280 The security considerations for protection and recovery aspects of 281 MPLS-TP are addressed in [I-D.ietf-mpls-tp-survive-fwk]. 283 The extensions to the protocol described in this document are 284 extensions to the protocol defined in 285 [I-D.ietf-mpls-tp-linear-protection] [I-D.ezy-mpls-1ton-protection] 286 and does not introduce any new security risks. 288 8. Acknowledgement 290 The authors would like to thank all members of the teams (the Joint 291 Working Team, the MPLS Interoperability Design Team in IETF and the 292 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 293 specification of MPLS Transport Profile. 295 9. References 296 9.1. Normative references 298 [I-D.ietf-mpls-tp-linear-protection] 299 Bryant, S., Osborne, E., Sprecher, N., Fulignoli, A., and 300 Y. Weingarten, "MPLS-TP Linear Protection", 301 draft-ietf-mpls-tp-linear-protection-07 (work in 302 progress), June 2011. 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 308 and S. Ueno, "Requirements of an MPLS Transport Profile", 309 RFC 5654, September 2009. 311 9.2. Informative References 313 [I-D.ezy-mpls-1ton-protection] 314 Osborne, E., Zhang, F., and Y. Weingarten, "MPLS-TP 1toN 315 Protection", draft-ezy-mpls-1ton-protection-00 (work in 316 progress), June 2011. 318 [I-D.ietf-mpls-lsp-ping-ttl-tlv] 319 Boutros, S., Sivabalan, S., Swallow, G., Saxena, S., and 320 V. Manral, "Definition of Time-to-Live TLV for LSP-Ping 321 Mechanisms", draft-ietf-mpls-lsp-ping-ttl-tlv-00 (work in 322 progress), June 2011. 324 [I-D.ietf-mpls-tp-security-framework] 325 Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP 326 Security Framework", 327 draft-ietf-mpls-tp-security-framework-01 (work in 328 progress), May 2011. 330 [I-D.ietf-mpls-tp-survive-fwk] 331 Sprecher, N. and A. Farrel, "Multiprotocol Label Switching 332 Transport Profile Survivability Framework", 333 draft-ietf-mpls-tp-survive-fwk-06 (work in progress), 334 June 2010. 336 [RFC4428] Papadimitriou, D. and E. Mannie, "Analysis of Generalized 337 Multi-Protocol Label Switching (GMPLS)-based Recovery 338 Mechanisms (including Protection and Restoration)", 339 RFC 4428, March 2006. 341 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 342 Associated Channel", RFC 5586, June 2009. 344 Authors' Addresses 346 Fei Zhang (editor) 347 ZTE 349 Email: zhang.fei3@zte.com.cn 351 Wenjuan He 352 ZTE 354 Email: hewenjuan@zte.com.cn