idnits 2.17.1 draft-ietf-mpls-smp-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: o When triggered, protection switching action SHOULD be initiated immediately to minimize service interruption time. If the protection resources are already allocated to a higher priority protection path the protection switching SHALL not be performed. -- The document date (March 25, 2013) is 4048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ABCDE' is mentioned on line 225, but not defined == Missing Reference: 'VWXYZ' is mentioned on line 225, but not defined == Missing Reference: 'APQRE' is mentioned on line 226, but not defined == Missing Reference: 'VPQRZ' is mentioned on line 129, but not defined == Missing Reference: 'PQR' is mentioned on line 130, but not defined == Missing Reference: 'MDEN' is mentioned on line 225, but not defined == Missing Reference: 'FGH' is mentioned on line 225, but not defined == Missing Reference: 'JKL' is mentioned on line 225, but not defined == Missing Reference: 'MSTN' is mentioned on line 226, but not defined == Missing Reference: 'FPQH' is mentioned on line 227, but not defined == Missing Reference: 'JRSL' is mentioned on line 227, but not defined == Missing Reference: 'VPQRSTZ' is mentioned on line 227, but not defined == Missing Reference: 'PQ' is mentioned on line 245, but not defined == Missing Reference: 'QR' is mentioned on line 245, but not defined == Missing Reference: 'RS' is mentioned on line 245, but not defined == Missing Reference: 'ST' is mentioned on line 246, but not defined == Missing Reference: 'PQRST' is mentioned on line 235, but not defined Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Weingarten 3 INTERNET-DRAFT 4 Intended status: Informational S. Aldrin 5 Expires: September 26, 2013 Huawei Technologies 6 P. Pan 7 Infinera 8 J. Ryoo 9 ETRI 10 G. Mirsky 11 Ericsson 12 March 25, 2013 14 Requirements for MPLS Shared Mesh Protection 15 draft-ietf-mpls-smp-requirements-00.txt 17 Abstract 19 This document presents the basic network objectives for the behavior 20 of shared mesh protection (SMP) not based on control-plane support. 21 This is an expansion of the basic requirements presented in the MPLS 22 Transport Profile Requirements (RFC5654) and MPLS Transport Profile 23 Survivability Framework (RFC6372) documents. This document should be 24 used as a basis for the definition of the mechanism that would be 25 used to implement SMP for MPLS-TP data paths, in networks that do not 26 employ a control plane for their operation. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 17, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Protection or Restoration . . . . . . . . . . . . . . . . 4 64 1.2. Scope of document . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. Relationship to MPLS-TP . . . . . . . . . . . . . . . 4 66 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 67 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 5 68 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. SMP Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Coordination of resources . . . . . . . . . . . . . . . . 6 71 3.2. Control plane or data plane . . . . . . . . . . . . . . . 7 72 4. SMP Network Objectives . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Configuration and resource reservation . . . . . . . . . . 7 74 4.1.1. Checking resource availability . . . . . . . . . . . . 8 75 4.2. Multiple triggers . . . . . . . . . . . . . . . . . . . . 8 76 4.3. Notification . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.4. Reversion of protection resources . . . . . . . . . . . . 9 78 4.5. Protection switching time . . . . . . . . . . . . . . . . 10 79 4.6. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.7. Communicating information and channel . . . . . . . . . . 10 81 5. Manageability Considerations . . . . . . . . . . . . . . . . . 10 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 MPLS transport networks can be characterized as being a network of 91 connections between nodes within a mesh of nodes and the links 92 between them. The connections, that may be between neighboring 93 nodes, i.e. spanning a single physical link, or spanning a path of 94 several nodes, constitute the Label Switched Paths (LSP) that 95 transport packets between the endpoints of these paths. The 96 survivability of these connections, as described in [RFC6372], is a 97 critical aspect for various service providers that are bound by 98 Service Level Agreements (SLA) with their customers. 100 MPLS provides control-plane tools to support various survivability 101 schemes (Editor's note - add references). In addition, recent 102 efforts in the IETF have started providing for data-plane tools to 103 address aspects of data protection. In particular, [RFC6378] defines 104 a set of triggers and coordination protocol for 1:1 and 1+1 linear 105 protection of p2p paths. 107 When considering a full-mesh network and the protection of different 108 paths that criss-cross the mesh, it is possible to conserve the 109 amount of protection resources needed to protect the different data 110 paths. As pointed out in [RFC6372] and [RFC4428], applying 1+1 111 linear protection, requires that resources are allocated and used by 112 both the working and protection paths. Applying 1:1 protection 113 requires that all of the resources are allocated, but allows the 114 resources of the protection path to be utilized for pre-emptible 115 extra traffic. Extending this to 1:n or m:n protection allows the 116 resources of the protection path to be shared in the protection of 117 several working paths. However, there is a limitation in 1:n 118 protection architectures - that all of the n+1 paths must have 119 identical endpoints. 121 As described in [RFC6372] Shared Mesh Protection (SMP) supports a 122 form of sharing protection resources, while providing protection for 123 multiple data paths that may not have common endpoints and do not 124 share common points of failure. It should be noted that some 125 protection resources may not be shared by multiple protection paths, 126 while other resources are shared. The basic configuration for data 127 paths that employ SMP is shown in Figure 1. In this figure, we show 128 two working paths [ABCDE] and [VWXYZ] that are protected employing 129 1:1 linear protection by protection paths [APQRE] and [VPQRZ] 130 respectively. The segment [PQR] and all of its protection resources 131 are shared by both of the protection paths. 133 A----B----C----D----E 134 \ / 135 \ / 136 \ / 137 P-----Q-----R 138 / \ 139 / \ 140 / \ 141 V----W----X----Y----Z 143 Figure 1: Basic SMP architecture 145 1.1. Protection or Restoration 147 [RFC6372], based upon the definitions in [RFC4427], differentiates 148 between "protection" and "restoration" dependent upon the dynamism of 149 the resource allocation. In SMP, the resources of the protection 150 paths are reserved at the time of path creation. However, the full 151 allocation of the resources, at least for the shared segments, will 152 only be finalized when the protection path is actually activated. 153 Therefore, for the purists - regarding the terminology - SMP lies 154 somewhere between protection and restoration. 156 1.2. Scope of document 158 [RFC5654] establishes that MPLS-TP should support shared protection 159 (Requirement 68) and that MPLS-TP must support sharing of protection 160 resources (Requirement 69).This document presents the network 161 objectives and a framework for applying SMP within an MPLS network, 162 without the use of control-plane protocols. There are existing 163 control-plane solutions for SMP within MPLS, however we address those 164 networks that for some reason, e.g. service provider preferences or 165 limitations, do not employ a full control plane operation, or require 166 service restoration faster than achievable with control plane 167 mechanisms. 169 The network objectives will also address possible additional 170 restrictions of the behavior of SMP in statically configured operator 171 networks. Definition of logic and specific protocol messaging is out 172 of scope of this document. 174 1.2.1. Relationship to MPLS-TP 176 While some of the restrictions presented by this framework originate 177 from the considerations of transport networks, there is no real 178 constraint of the information presented here being applied to general 179 MPLS networks, and not necessarily as part of the Transport Profile 180 of MPLS. 182 1.3. Contributing Authors 184 David Allan, Daniel King, Taesik Cheung 186 2. Terminology and Notation 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 The terminology used in this document is based on the terminology 193 defined in the MPLS-TP Survivability Framework document [RFC6372] 194 which in-turn is based on [RFC4427]. 196 2.1. Acronyms 198 This draft uses the following acronyms: 200 LSP Label Switched Path 201 SLA Service Level Agreement 202 SMP Shared Mesh Protection 203 SRLG Shared Risk Link Group 205 3. SMP Architecture 207 Figure 1 shows a very basic configuration of working and protection 208 paths that may employ SMP. We may consider a slightly more involved 209 configuration, such as the one in Figure 2 in order to identify 210 certain basic characteristics of an SMP mesh network. 212 A----B----C----D----E---N 213 \ / / \ 214 \ M ---/-- \ 215 \ / \ \ 216 P-----Q-----R-----S----T 217 /| \ \ \ \ 218 / F---G---H J--K---L \ 219 / \ 220 V------W-------X-------Y-------Z 222 Figure 2: Larger sample SMP architecture 224 Consider the network presented in Figure 2. There are five working 225 paths - [ABCDE], [MDEN], [FGH], [JKL], and [VWXYZ]. Each of these 226 has a corresponding protection path - [APQRE] (p1), [MSTN] (p2), 227 [FPQH] (p3), [JRSL] (p4), and [VPQRSTZ] (p5). The following segments 228 are shared by two or more of the protection paths - [PQ] is shared by 229 p1, p3, and p5, [QR] is shared by p1 and p5, [RS] is shared by p4 and 230 p5, and [ST] is shared by p2 and p5. In addition, we assume that the 231 available protection resources for these shared segments are not 232 sufficient to support the complete traffic capacity of the respective 233 working paths that may use the protection paths. We can further 234 observe that the main feature of the network that defines it as an 235 SMP network is the fact that the segment [PQRST] is the union of all 236 the shared segments of other protection paths (p1, p2, p3 and p4) 237 while being a whole shared segment of one of the protection paths 238 (p5). 240 In other words, the main feature of an SMP "protection domain" will 241 be the segment that is the union of all the shared segments of the 242 protection paths. We can further identify "protection group" as the 243 different protection paths that share a common segment. For example, 244 referring to Figure 2, we have the following protection groups - {p1, 245 p3, p5} for [PQ], {p1, p5} for [QR], {p4, p5} for [RS], {p2, p5} for 246 [ST]. 248 Typical deployment of SMP would require various network planning 249 activities. These would include: 251 o Identification of key services that require protection, and 252 determining the number of working and protection paths. 254 o Reviewing network topology to determine which working or 255 protection paths are required to be disjointed from each other, 256 and exclude specified resources such as links, nodes, or shared 257 risk link groups (SRLGs). 259 o Determining the size (bandwidth) of the shared resource 261 3.1. Coordination of resources 263 When a protection switch is triggered by any fault condition or 264 operator command, the SMP network must perform two operations almost 265 simultaneously - switch data traffic over to a protection path and 266 verify that the shared resources are allocated for this protection 267 path. The allocation of resources is dependent upon their 268 availability at each of the shared segments. 270 When the reserved resources of the shared segments are allocated for 271 a particular protection path, there may not be sufficient resources 272 available for an additional protection path. This then implies that 273 if an additional working path triggers a protection switch, the 274 allocation of the resources may fail and MUST be treated as described 275 below in Section 4.2. In order to optimize the operation of the 276 allocation and preparing for cases of multiple working path failures, 277 the allocation of the shared resources SHALL be coordinated between 278 the different working paths in the SMP network. 280 3.2. Control plane or data plane 282 As stated in both [RFC6372] and [RFC4428], full control of SMP, 283 including both configuration and the coordination of the protection 284 switching is potentially very complex. Therefore, it is suggested 285 that this be carried out under the control of a dynamic control plane 286 similar to GMPLS [RFC3945]. In fact, implementations for SMP with 287 GMPLS exist and the general principles of its operation are well 288 known, if not fully documented. 290 There are, however, operators, in particular in the transport sector, 291 that do not operate their MPLS networks under the control of a 292 control plane and require the ability of performing SMP protection 293 while utilizing data-plane tools for coordination of the protection 294 switching. This requirement is emphasized in different areas of 295 [RFC5654] for MPLS-TP environments. Therefore, it is imperative that 296 it be possible to perform all of the coordination needed for SMP via 297 data plane operations. 299 4. SMP Network Objectives 301 4.1. Configuration and resource reservation 303 SMP is a survivability mechanism that is based on pre-configuration 304 of the network working paths and the corresponding protection paths. 305 This configuration may be based on either a control protocol or 306 static configuration by the management system. It should be noted 307 that even when the configuration is performed by a control protocol, 308 e.g. Generalized MPLS (GMPLS), that it is assumed that the control 309 protocol is not used during regular operation of the network. 311 The protection relationship between the working and protection paths 312 SHOULD be configured and the shared segments of the protection path 313 MUST be identified prior to use of the protection paths. 315 As opposed to the case of simple linear protection, where the 316 relationship between the working and protection paths is defined, the 317 resources for the protection path may be fully committed for the 318 unshared portions of the protection path. The protection path in the 319 case of SMP consists of segments that are dedicated to the protection 320 of the related working path and also segments that are shared with 321 other protection paths. On the shared segments, the protection 322 resources may be reserved but would not be allocated until requested 323 as part of a protection switch. 325 4.1.1. Checking resource availability 327 When a working path identifies a protection switching trigger it MUST 328 verify that the necessary protection resources are available on the 329 protection path. The resources may not be available because they 330 have been allocated to the protection of a higher priority working 331 path, as described above. 333 4.2. Multiple triggers 335 If more than one working path is triggering a protection switch there 336 are different possible actions that the SMP network may apply. The 337 basic MPLS action MAY allow all of the protection paths to share the 338 resources of the shared segments, for those networks that support 339 multiplexing packets over the shared segments. For those networks, 340 in particular for networks that support the requirements in [RFC5654] 341 [and in particular support for requirement 58], that require the 342 exclusive use of the protection resources, the following behavior 343 SHOULD be supported: 345 o Relative priority MAY be assigned to each of the working paths 346 that share a common protection segment 348 o Resources of the shared segments SHALL be allocated to the 349 protection path according to the highest priority amongst those 350 requesting use of the resources. 352 o If multiple protection paths of equal priority are requesting 353 allocation of the shared resources, the resources SHOULD be 354 allocated on a first come first served basis. Tie-breaking rules 355 SHALL be defined by the SMP process. 357 o If the protection resources are currently in use by a protection 358 path, whose working path has a lower priority, resources required 359 for the higher priority path SHALL be allocated to this path. 360 Traffic with lower priority MAY use available resources or MAY be 361 interrupted. 363 o When triggered, protection switching action SHOULD be initiated 364 immediately to minimize service interruption time. If the 365 protection resources are already allocated to a higher priority 366 protection path the protection switching SHALL not be performed. 368 o Once a protection path occupies the resource of a shared segments 369 successfully, the traffic on that protection path SHALL NOT be 370 interrupted by any protection traffic whose priority is equal or 371 lower than the protecting path currently in-use. 373 o During preemption, shared segment resources MAY be used by both 374 existing traffic (that is being preempted) and higher priority 375 traffic for a short period. 377 o During preemption, if there is an oversubscription of resources 378 protected traffic SHOULD be treated as defined in [RFC5712] or 379 [RFC3209] 381 4.3. Notification 383 When a working path identifies a trigger for implementing a 384 switchover to the protection path, it SHOULD attempt to switchover 385 the traffic to the protection path and requesting the allocation of 386 the resources for this protected traffic. If the necessary shared 387 resources are in use by a protection path of higher priority or are 388 unavailable to be allocated to the protection path, a notification 389 SHALL be sent to both endpoints of the requesting working path and 390 the switchover MAY not be completed. 392 Similarly, if preemption is supported and as a result of the 393 allocation of resources to a different working path that triggered a 394 protection switch, the resources currently allocated for a particular 395 working path are being preempted then a notification SHALL be sent to 396 the endpoints of the working path whose traffic is being preempted 397 indicating that the resources are being preempted. 399 4.4. Reversion of protection resources 401 When the working path detects that the condition that triggered the 402 protection switch has cleared, it is possible to either revert to 403 using the working path resources or continue to utilize the 404 protection resources. Continuing the use of protection resources 405 allows the operator to delay the disruption of service caused by the 406 switchover until periods of lighter traffic. The switchover would 407 need to be performed via an explicit operator command unless the 408 protection resources are preempted by a higher priority fault. The 409 choice between the two modes SHALL depend upon operator 410 configuration. Normally the network should revert to use of the 411 working path resources in order to clear the protection resources for 412 protection of other path triggers. However, the protocol MUST 413 support non-revertive configurations. 415 4.5. Protection switching time 417 Protection switching time refers to the transfer time (Tt) defined in 418 [G.808.1] and recovery switching time defined in [RFC4427], and is 419 defined as the interval after a switching trigger is identified until 420 the traffic begins to be transmitted on the protection path. This 421 time is exclusive of the time needed to initiate the protection 422 switching process after a failure occurred, and the time needed to 423 complete preemption of existing traffic on the shared segments as 424 described in Section 4.2. The former, which is known as detection 425 and correlation time in [RFC4427] is related to the OAM or management 426 process, but the latter is related to the SMP process. Support for a 427 protection switching time of 50ms is dependent upon the initial 428 switchover to the protection path, but the preemption time SHOULD 429 also be taken into account to minimize total service interruption 430 time. 432 4.6. Timers 434 In order to prevent multiple switching actions for a single switching 435 trigger, SMP SHOULD be controlled by a hold-off timer that would 436 allow lower level mechanisms to complete their switching actions 437 before invoking SMP protection actions. 439 In addition, to prevent an unstable recovering working path from 440 invoking intermittent switching operation, SMP SHOULD employ a wait- 441 to-restore timer during any reversion switching. 443 4.7. Communicating information and channel 445 SMP SHOULD include support for communicating information to 446 coordinate the use of the shared protection resources among multiple 447 working paths. The message encoding and communication channel 448 between the nodes of the shared protection resource and the endpoints 449 of the protection path are out of the scope of this document. 451 SMP SHOULD provide a communication channel, along the protection 452 path, between the endpoints of the protection path to support fast 453 protection switching. 455 5. Manageability Considerations 457 To be added in future version. 459 6. Security Considerations 461 To be added in future version. 463 7. IANA Considerations 465 This document makes no request of IANA. 467 Note to RFC Editor: this section may be removed on publication as an 468 RFC. 470 8. Acknowledgements 472 TBD 474 9. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC5654] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 480 "Requirements for the Transport Profile of MPLS", 481 RFC 5654, Sept 2009. 483 [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability 484 Framework", RFC 6372, Sept 2011. 486 [RFC6378] Sprecher, N., Bryant, S., Osborne, E., Fulignoli, A., and 487 Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378, 488 Nov 2011. 490 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 491 (GMPLS) Architecture", RFC 3945, Oct 2004. 493 [G.808.1] ITU, "Generic Protection Switching - Linear trail and 494 subnetwork protection", ITU-T G.808.1, Feb 2010. 496 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 497 Restoration) Terminology for GMPLS", RFC 4427, March 2006. 499 [RFC4428] Mannie, E. and D. Papadimitriou, "Analysis of Generalized 500 Multi-Protocol Label Switching (GMPLS)-based Recovery 501 Mechanisms (including Protection and Restoration)", 502 RFC 4428, March 2006. 504 [RFC5712] Meyer, M. and JP. Vasseur, "MPLS Traffic Engineering Soft 505 Preemption", RFC 5712, January 2010. 507 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., and V. 508 Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 509 RFC 3209, December 2001. 511 Authors' Addresses 513 Yaacov Weingarten 514 34 Hagefen St. 515 Karnei Shomron, 4485500 516 Israel 518 Phone: 519 Email: wyaacov@gmail.com 521 Sam Aldrin 522 Huawei Technologies 523 2330 Central Express Way 524 Santa Clara, CA 95951 525 United States 527 Email: aldrin.ietf@gmail.com 529 Ping Pan 530 Infinera 532 Email: ppan@infinera.com 534 Jeong-dong Ryoo 535 ETRI 536 161 Gajeong 537 Yuseong, Daejeon 305-700 538 South Korea 540 Email: ryoo@etri.re.kr 541 Greg Mirsky 542 Ericsson 544 Email: gregory.mirsky@ericsson.com