idnits 2.17.1 draft-cheung-mpls-tp-mesh-protection-05.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 == Line 979 has weird spacing: '...tection and R...' -- The document date (March 12, 2012) is 4428 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group T. Cheung 3 Internet-Draft J. Ryoo 4 Intended status: Standards Track ETRI 5 Expires: September 13, 2012 Y. Weingarten 6 N. Sprecher 7 Nokia Siemens Networks 8 D. King 9 Old Dog Consulting 10 March 12, 2012 12 MPLS-TP Shared Mesh Protection 13 draft-cheung-mpls-tp-mesh-protection-05.txt 15 Abstract 17 This document describes a mechanism to address the requirement to 18 support protection of Label Switched Paths (LSPs) in an MPLS 19 Transport Profile (MPLS-TP) mesh topology. The shared mesh 20 protection mechanism enables multiple protection paths within a 21 shared mesh protection domain to share protection resources for the 22 protection of working paths by coordinating protection switching 23 operations according to the priority assigned to each end-to-end 24 linear protection domain. 26 This document is a product of a joint Internet Engineering Task Force 27 (IETF) / International Telecommunications Union Telecommunications 28 Standardization Sector (ITU-T) effort to include an MPLS Transport 29 Profile within the IETF MPLS and PWE3 architectures to support the 30 capabilities and functionalities of a packet transport network as 31 defined by the ITU-T. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions Used in this Document . . . . . . . . . . . . . . 5 69 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Definitions and Terminology . . . . . . . . . . . . . . . 5 71 3. Shared Mesh Protection Architecture . . . . . . . . . . . . . 6 72 3.1. Shared Mesh Protection Group . . . . . . . . . . . . . . . 7 73 3.2. Shared Start and End Nodes . . . . . . . . . . . . . . . . 8 74 3.3. SMP protocol communication channel . . . . . . . . . . . . 10 75 3.4. Network planning for SMP . . . . . . . . . . . . . . . . . 10 76 3.5. Preemption and race conditions . . . . . . . . . . . . . . 11 77 3.6. SMP Overview . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.6.1. LP Protocol extensions for shared protection . . . . . 12 79 3.6.2. Notifying protection switching event . . . . . . . . . 13 80 3.6.3. Requesting lockout of protection . . . . . . . . . . . 13 81 3.6.4. Resolving race conditions . . . . . . . . . . . . . . 14 82 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.1. PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.2. Message Transmission . . . . . . . . . . . . . . . . . . . 17 85 5. Operation of Shared Mesh Protection . . . . . . . . . . . . . 17 86 6. Manageability Considerations . . . . . . . . . . . . . . . . . 20 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 The MPLS Transport Profile (MPLS-TP) is a packet transport technology 97 based on a profile of the MPLS and Pseudowires (PW) as described in 98 [RFC3031], [RFC3985], and [RFC5085]. MPLS-TP is the application of 99 MPLS to the construction of packet-switched paths that are analogous 100 to traditional circuit-switched technologies. Requirements for 101 MPLS-TP are specified in [RFC5654]. 103 An important feature of a transport network is its survivability 104 function and the ability to maintain or recover traffic following a 105 network failure or attack. According to Requirement 56 of [RFC5654], 106 MPLS-TP must provide protection and restoration mechanisms, and it 107 must also be possible to protect 100% of the traffic on the protected 108 path (Requirement 58). 110 1+1 and 1:1 linear protection meets these requirements by reserving 111 the equivalent amount of network resources for the protection paths 112 as is allocated to the normal traffic that is being protected. While 113 those dedicated protection mechanisms provide very good protection 114 capabilities, they are resource inefficient and will increase overall 115 network resource consumption. Deploying 1+1 and 1:1 protection 116 mechanisms for all services that require resiliency, dramatically 117 increases network costs. 119 [RFC5654] also establishes that MPLS-TP should support shared 120 protection (Requirement 68). 1:n end-to-end protection uses one 121 protection path to protect n working paths between the same two 122 endpoints. This improves overall network utilization, but the 123 resource (bandwidth) allocated to a protection path is typically not 124 sufficient to protect multiple simultaneous failures on different 125 working paths. If multiple working paths require concurrent 126 protection switching, the path with the highest priority should be 127 protected as described in [RFC6372]. 129 In 1+1 and 1:1 protection, the end nodes of the working path must be 130 the same as those of the protection path. Similarly in 1:n 131 protection all pairs of end nodes of the n working paths are the 132 same, and the protection path must also have the same end nodes. In 133 the event that the MPLS-TP network scales up, the number of Label 134 Switched Paths (LSPs) having different end nodes will also increase. 135 The network utilization benefit for sharing protection resources 136 among multiple protected domains for such LSPs will increase 137 accordingly. 139 Requirement 68 of [RFC5654] specifies that MPLS-TP should support 1:n 140 shared mesh recovery, and Requirement 69 states that MPLS-TP must 141 support sharing of protection resources. It may be possible that 142 some working paths are sufficiently disjoint and would be unlikely to 143 be simultaneously affected by a single network failure. Typically, 144 such a scenario is hard to track in real network environments where 145 new services are often added and removed. 147 In mesh protection, network resources may be shared to provide 148 protection for working paths that do not share the same end nodes at 149 the edge of a protection domain. This type of protection can make 150 very efficient use of network resources, but requires coordination of 151 several segments in order to ensure that only a single traffic flow 152 is switched to the protection resources at any time. 154 [RFC4428] defines two shared mesh recovery schemes named (1:1)^n and 155 (M:N)^n. The (1:1)^n recovery scheme is a simple case of (M:N)^n 156 recovery scheme. In (1:1)^n protection, n working paths are 157 protected by n dedicated protection paths while sharing the same 158 protection bandwidth. The protection bandwidth can be optimized to 159 allow only one of the n working paths to be protected at any time. 160 In this case, it achieves network utilization similar to 1:n 161 protection. 163 It should be noted that the (1:1)^n protection scheme described in 164 [RFC4428] differs with that defined in [G.808.1] in that the former 165 allows each n pairs of working and protection paths to have different 166 end nodes while the latter applies to the case where all pairs have 167 the same end nodes. 169 This document defines a data-plane shared mesh protection mechanism 170 based on the concept of the (1:1)^n recovery scheme described in 171 [RFC4428] and a protocol for coordination of the shared protection 172 resources. The actual protection switching is controlled by end-to- 173 end linear protection, while the usage of the shared resources is 174 based on the protection switching priority assigned to each pair of 175 working and protection paths. 177 The shared mesh protection mechanism defined in this document 178 utilizes the existing MPLS-TP linear protection switching mechanism, 179 and assumes that the protection paths are established and ready to 180 forward data prior to a failure. Upon detection of a failure on a 181 working path, only the two end nodes of the failed working path 182 exchange their linear protection protocol messages to switch data 183 traffic. No explicit activation procedure to switch data traffic to 184 the protection path is needed in the intermediate nodes along the 185 protection path. However, the intermediate nodes that are part of 186 the shared segments need to coordinate the resource allocation on the 187 shared nodes and this coordination will be addressed by the protocol 188 proposed in this document. 190 2. Conventions Used in this Document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 2.1. Acronyms 198 This draft uses the following acronyms: 200 G-ACh Generic Associated Channel Header 201 LoP Lockout of Protection 202 LP Linear Protection 203 LSP Label Switched Path 204 MIP Maintenance Entity Group Intermediate Point 205 MPLS-TP Transport Profile for MPLS 206 P2P Point-to-point 207 P2MP Point-to-multipoint 208 PS Protection Switching 209 PW Pseudowire 210 RA Resource Allocation 211 SEN Shared End Node 212 SMP Shared Mesh Protection 213 SMPG Shared Mesh Protection Group 214 SPME Sub-Path Maintenance Entity 215 SRLG Shared Risk Link Group 216 SSN Shared Start Node 218 2.2. Definitions and Terminology 220 This document defines two protection domains as follows: 222 o End-to-end linear protection (LP) domain: A protection domain as 223 defined in [RFC6372] for protecting a P2P or P2MP LSP. It 224 consists of two or more endpoints at the boundary of the domain 225 and a working path and a protection path between the end nodes. 226 An end-to-end linear protection switching protocol runs within the 227 domain. 229 o Shared mesh protection (SMP) domain: A protection domain for 230 protecting a number of P2P or P2MP LSPs. It consists of a number 231 of end-to-end linear protection domains. Each end-to-end linear 232 protection domain shares protection resources with other domains. 233 The shared protection resource may be a node, link, transport path 234 segment or concatenated transport path segment. A shared mesh 235 protection switching protocol runs within the domain. 237 In addition, we define the following: 239 o Protection segment: A protection segment is a portion of the end- 240 to-end protection path. An end-to-end protection path can be 241 broken down into separate protection segments. A protection 242 segment may either be a shared protection segment or a dedicated 243 protection segment. A shared protection segment is a segment that 244 has a set of resources, e.g. link bandwidth that is reserved as 245 shared amongst several end-to-end protection paths. A dedicated 246 protection segment is a segment of the end-to-end protection path 247 whose resources are reserved for use only by that protection path. 249 o Shared mesh protection group (SMPG): A protection group includes 250 the pairs of working and protection paths, whose working paths do 251 not belong to a single SRLG and whose protection paths share the 252 resource of a single shared protection segment. Note that an LSP 253 may belong to multiple SMPGs. 255 3. Shared Mesh Protection Architecture 257 The shared mesh protection domain shown in Figure 1 has two end-to- 258 end linear protection domains. One consists of the two end nodes A 259 and E and includes one working path, ABCDE, and one dedicated 260 protection path APQRE. The second consists of end nodes V and Z and 261 one working path, VWXYZ, and the dedicated protection path, VPQRZ. 262 Those two LP domains include a shared protection segment PQR for 263 their protection paths. This illustrates a simple configuration of 264 shared mesh protection. Note that the two working paths, ABCDE and 265 VWXYZ, do not share endpoints so they cannot make use of 1:n 266 protection even though they also do not share any potential common 267 points of failure. 269 It is possible to apply linear protection to each of these working 270 paths individually. If there are no failures affecting either of the 271 two working paths, the shared protection segment PQR carries no 272 traffic (or only interruptible extra traffic). In the event of only 273 one failure on a working path, the segment PQR carries traffic from 274 the working path that detected the failure. Only in the event that 275 there are failures detected on both of the working paths is there a 276 conflict over the appropriate use of the shared protection segment 277 PQR. It is important to note that there are two distinct LSPs (i.e. 278 APQRE and VPQRZ) that are signaled over the shared protection segment 279 and that although we refer to the singular segment, the traffic is 280 actually being transported on separated transport paths. 282 Thus, it is possible for the network resources of segment PQR to be 283 shared by the two protection paths. In this way, shared mesh 284 protection can substantially reduce the amount of network resources 285 that need to be reserved to provide protection of the multiple paths 286 within the same protection group. 288 A----B----C----D----E 289 \ / 290 \ / 291 \ / 292 P-----Q-----R 293 / \ 294 / \ 295 / \ 296 V----W----X----Y----Z 298 Figure 1: A Shared Mesh Protection Topology 300 3.1. Shared Mesh Protection Group 302 In Figure 1, two working paths, ABCDE and VWXYZ and their 303 corresponding protection paths, APQRE and VPQRZ, are considered a 304 Shared Mesh Protection Group (SMPG). As pointed out above, each 305 protection path belonging to a SMPG is an individual LSP, but it 306 shares the resources with others in a segment. The resources that 307 are being shared are the nodes, ports, links and bandwidth of the 308 segment. 310 The shared resources, for example bandwidth capacity, should be 311 reserved in partitions according to the different SMPGs at the 312 particular segment. 314 A------B-------C D------E 315 \ / / \ 316 \ / / \ 317 F---G----H-----J------K-----L 318 / / \ \ 319 / M----------N \ 320 / \ 321 V-------W-------X-------Y-------Z 323 Figure 2: Shared Mesh Protection Groups 325 To further clarify, consider the mesh network in Figure 2. In this 326 figure we have the following working paths and corresponding 327 protection paths: 329 +----+--------------+-----------------+ 330 | Wx | working path | protection path | 331 +----+--------------+-----------------+ 332 | W1 | A-B-C | A-F-G-H-C | 333 | W2 | D-E | D-J-K-L-E | 334 | W3 | M-N | M-J-K-N | 335 | W4 | V-W-X-Y-Z | V-G-H-J-K-L-Z | 336 +----+--------------+-----------------+ 338 In this network we would define three SMPG - characterized by the 339 three shared segments - 341 o S1 segment G-H - shared by W1 and W4 343 o S2 segment J-K - shared by W2, W3, and W4 345 o S3 segment K-L - shared by W2 and W4 347 The shared segment is always the smallest segment that is shared by 348 multiple protection paths. Therefore, even though segment J-K-L is 349 shared by W2 and W4, we split this into two shared segments - J-K and 350 K-L, since W3 also shares the resources of segment J-K. 352 In addition, this demonstrates that a single working path may be a 353 member of a number of SMPGs. Also a single SMPG may include more 354 than two working paths. 356 3.2. Shared Start and End Nodes 358 For the sake of the discussion of the SMP operation, we designate the 359 two end nodes of the shared protection segment as a Shared Start Node 360 (SSN) and Shared End Node (SEN). To simplify the discussion, this 361 designation is based on referencing the protection path as a pair of 362 unidirectional LSPs. 364 A SSN is the first node of a unidirectional shared protection 365 segment. For example, in Figure 1, node P is a SSN on unidirectional 366 protection paths A-P-Q-R-E and V-P-Q-R-Z. SSN may act as a 367 Maintenance Entity Group Intermediate Point (MIP) for each protection 368 path sharing the same protection resources. 370 Similarly, a SEN is defined as the last node of a unidirectional 371 shared protection segment (for example, node R on unidirectional 372 protection paths A-P-Q-R-E and V-P-Q-R-Z in Figure 1). A SEN acts as 373 a MIP on each protection path that shares the protection resource. 375 Both SEN and SSN are involved in coordinating the use of the 376 unidirectional shared protection segment during the shared mesh 377 protection operation. 379 Table 1 summarizes the relationship between SSN and SEN of the shared 380 protection segment and protection paths sharing it as illustrated in 381 Figure 1. 383 Table 1: SSN/SEN in Figure 1 385 +----------------------+---------------------------+-----+-----+ 386 | Protection paths | Shared protection segment | SSN | SEN | 387 +----------------------+---------------------------+-----+-----+ 388 | A-P-Q-R-E, V-P-Q-R-Z | P-Q-R | P | R | 389 | E-R-Q-P-A, Z-R-Q-P-V | R-Q-P | R | P | 390 +----------------------+---------------------------+-----+-----+ 392 Figure 3 shows a more complex example of the shared mesh protection 393 domain. Three working paths ABC, DEF, and GHJ are protected by the 394 protection paths APQC, DRSF, and GPQRSJ, respectively. Table 2 395 summarizes the relationship between SSN and SEN of the shared 396 protection segments and the related protection paths in the 397 protection domain illustrated in Figure 3. 399 A------B------C D------E------F 400 \ / \ / 401 \ / \ / 402 \ / \ / 403 P-----Q----------R-----S 404 / \ 405 / \ 406 / \ 407 G--------------H---------------J 409 Figure 3: A More Complex Mesh Protection Example 411 Table 2: SSN/SEN in Figure 3 413 +----------------------+---------------------------+-----+-----+ 414 | Protection paths | Shared protection segment | SSN | SEN | 415 +----------------------+---------------------------+-----+-----+ 416 | A-P-Q-C, G-P-Q-R-S-J | P-Q | P | Q | 417 | C-Q-P-A, J-S-R-Q-P-G | Q-P | Q | P | 418 | D-R-S-F, G-P-Q-R-S-J | R-S | R | S | 419 | F-S-R-D, J-S-R-Q-P-G | S-R | S | R | 420 +----------------------+---------------------------+-----+-----+ 422 3.3. SMP protocol communication channel 424 The MPLS-TP Framework [RFC5921] defines the concept of a Sub-Path 425 Maintenance Entity (SPME) and together with [RFC5586] defines the use 426 of the Generic Associated Channel (G-ACh) for communication of 427 MPLS-TP control protocols between the endpoints of a maintenance 428 entity. While the usual utility of a SPME is to allow tunneling of 429 transport traffic while monitoring the segment with in-band 430 connectivity verification messages, it is possible to use concept of 431 a SPME to describe a LSP that is dedicated to carry a control 432 protocol over the G-ACh between the endpoints of the shared 433 protection segment and the endpoints of the protection paths within 434 the SMPG. 436 For example, referring to the network in Figure 3, we would configure 437 the following SPME (without identifying the intermediate nodes): 439 A-P, G-P, P-Q, Q-C and Q-J (for SMPG 1 sharing P-Q), and 440 D-R, G-R, R-S, S-F and S-J (for SMPG 2 sharing R-S). 442 These SPMEs are bidirectional LSPs that are not used to carry any 443 data traffic, but only the SMP protocol traffic described in 444 Section 4. 446 The communication channel between the SSN and SEN of the shared 447 protection segment and between themselves and the endpoints of the 448 protection paths within the SMPG is to coordinate the allocation of 449 the shared segment to a single protection path during a protection 450 switching condition. This process is described more fully in 451 Section 3.6 453 3.4. Network planning for SMP 455 Shared mesh protection will typically be dependent upon careful 456 network planning. This includes: 458 o Preparing the working and protection paths for the different 459 services that require protection. 461 o Determining which working paths are disjoint and so will not be 462 subject to common failures. It should be clear that working paths 463 within the same SRLG should not be included in the same SMPG. 465 o Identifying which protection paths share network resources and can 466 constitute a SMPG. Signaling or configuring the proper path 467 information for the shared segment endpoints to allow for 468 communication between the corresponding endpoints of the shared 469 segment and the protection path. 471 o Assigning Protection Switching Priority and a path identifier for 472 each working path within a shared mesh protection domain. 474 o Ensuring that working paths of high Protection Switching Priority 475 do not share resources on their protection paths in such a way 476 that would mean that one of them could be unprotected. 478 o Enabling the necessary shared mesh protection functions at the 479 endpoints of the shared protection segments. This includes 480 preparing the different SPME used for communication between the 481 corresponding endpoints of the shared protection segments and the 482 protection paths, as well as between the endpoints of the shared 483 protection segment. 485 Note that some control plane features of GMPLS may be used to 486 dynamically configure shared mesh protection. These features are out 487 of scope for this document which focuses on the operation of shared 488 mesh protection switching once it has been configured. 490 3.5. Preemption and race conditions 492 In the normal operation of SMP, when a working path triggers a 493 protection switch, and requests allocation of the shared resources, 494 the SMP process should verify that the resources are available and 495 allocate them to the requesting protection path. There are some 496 cases where the determination of the availability is not simply 497 determined. 499 Within the SMP domain, there is a need to define a "Protection 500 Switching Priority" for each working path. This Protection Switching 501 Priority will be used to determine the use of the shared protection 502 resources in cases of possible preemption. When the shared resources 503 are in use protecting the traffic of a failed working path and a 504 second working path fails, the SMP process should compare the 505 Protection Switching Priority of the two working paths and if the 506 priority of the second path is higher than the priority of the 507 currently protected traffic, then this second path will preempt the 508 currently protected traffic. If the second path has a lower or equal 509 priority to the currently protected traffic, then the second path is 510 locked-out of the protection resources. 512 The Protection Switching Priority may be provisioned by the network 513 management system or configured by some other mechanism that is 514 outside the scope of this document. 516 There is an additional case where the SMP process needs to make a 517 determination of which working path should be allowed to be protected 518 using the shared resources. This is the case of multiple working 519 paths triggering a protection switch virtually simultaneously. This 520 may result in a race condition where the two endpoints of the shared 521 protection segment ostensibly receive requests from two different 522 working paths. By default, working paths with equal priority result 523 in first-come first-served recovery. If multiple working paths 524 request protection switching simultaneously, a pre-defined identifier 525 assigned to each working path in the SMP domain MUST be used to 526 determine the priority among them. The definition of the identifier 527 is for further study. 529 3.6. SMP Overview 531 When a protection switching trigger is activated on any of the 532 working paths within a SMPG, then the local linear protection 533 mechanism (in 1:1 protection mode) should cause a protection switch. 534 If, as a result of the protection switch action, there is a need to 535 transmit working data on the protection path then the endpoint of LP 536 domain should inform the endpoint of the shared protection segment of 537 the allocation of the shared resources. 539 At this point, the shared segment endpoints should notify all of the 540 other protection paths in the SMPG that the resources have been 541 allocated, which could affect the linear protection actions relative 542 to future triggers. 544 3.6.1. LP Protocol extensions for shared protection 546 The shared mesh protection mechanism is designed to fully utilize the 547 existing end-to-end LP switching on the working paths. These LP 548 domains SHALL operate in revertive mode. The LP protocol should use 549 the normal procedures for LP without any changes except support for 550 the following additional functionalities: 552 o Function to generate a protection switching event message to the 553 SEN when a switching trigger occurs at the end-to-end LP domain. 554 Switching to the protection path or reverting to the working path 555 should be notified. 557 o Function to take a Lockout of Protection (LoP) request message 558 from the SEN, and incorporate it as the Lockout of Protection 559 (LoP) command assertion or clearance. 561 o Function to acknowledge the SEN when the LP domain completes the 562 LoP operation. 564 3.6.2. Notifying protection switching event 566 If the endpoint of a working path detects a switching trigger, it 567 triggers the protection switching and exchanges LP switching protocol 568 messages with far endpoint. This operation is independent of the SMP 569 switching mechanism specified in this document. 571 At the same time, for the operation of SMP, the protection path 572 endpoint notifies its protection switching event to SENs by sending a 573 "Protection Switching (PS) Event" message. 575 The PS Event message MUST be transmitted immediately when an endpoint 576 of the end-to-end LP domain changes its selector position either from 577 working to protection or vice versa. The event message SHALL be 578 transmitted over the SPME that is configured between the protection 579 path endpoint and the SEN, using the G-ACh. When bidirectional 580 protection switching is being used by the working path, both 581 endpoints will transmit the event messages to their corresponding 582 SENs using the properly configured SPME. When unidirectional 583 protection switching is being used and a unidirectional failure is 584 detected, only the detecting endpoint will send the messages to its 585 corresponding SENs. 587 The endpoint of the protection path that is becoming active (or 588 released) sends the messages directly to each SEN. This requires 589 that N messages are sent, where N is the number of SMPG that the 590 working path is a member of. This, of course, implies that the 591 endpoints are pre-configured with knowledge of all SENs associated 592 with the SMPG. 594 3.6.3. Requesting lockout of protection 596 When a SEN receives the PS Event message notifying that protection 597 switching to the protection path has begun in an end-to-end LP domain 598 and that the shared resources are to be allocated, it compares the 599 Protection Switching Priority of the working path notifying the event 600 with those of other LP domains in the same SMPG. 602 The SEN determines which of the LP domains (within the SMPG) have a 603 lower or equal priority to that of the notifying LP domain. The SEN 604 then sends a "Lockout of Protection (LoP) Request" message to the 605 endpoints of these protection paths that is equivalent to a "Lockout 606 of Protection" operator command. This prevents any protection 607 switching actions in those LP domains. For those LP domains having 608 higher priorities no request is transmitted and those LP domains may 609 continue to perform protection switching actions which they require. 611 When a protection path endpoint receives the LoP Request message from 612 an SEN, it SHOULD react as if a LoP command was received, according 613 to the actions dictated by the LP protocol. Since the LoP command 614 has the highest priority in the LP switching protocol, it will 615 inhibit any further protection switching in the LP domain. 617 If the LP domain that received the LoP Request message is currently 618 transmitting traffic on the protection path, it SHALL immediately 619 stop transmitting the traffic on the protection path and release the 620 allocated resources. 622 When the protection path endpoint completes LoP operation, it SHOULD 623 immediately reply with a "LoP Acknowledgement" message to inform the 624 completion of the LoP operation to the SEN. 626 To minimize potential congestion that may occur when a protection 627 path having higher priority pre-empts other protection paths having 628 lower priorities, the SEN SHOULD block forwarding traffic from the 629 protection paths having lower priorities until it receives the LoP 630 Ack message from the endpoints of those protection paths. 632 When a SEN receives a PS Event message indicating that the shared 633 protection resources are being released, i.e. the LP domain is 634 reverting to normal state, it sends a LoP Request message to the 635 endpoints of all the protection paths in the SMPG that were 636 previously locked (i.e. those with equal or lower priority) to clear 637 the LoP command. The endpoint of the protection path that receives 638 this message SHALL react as if a Clear command was received. 640 3.6.4. Resolving race conditions 642 As was pointed out in Section 3.5 there are some cases, in particular 643 in unidirectional protection switching triggers, of simultaneous 644 protection switching that could cause race conditions. In these use- 645 cases there is a need for the two end nodes of the shared protection 646 segment, i.e. the SEN and the SSN, to coordinate the selection of the 647 LP domain that will be allocated the shared protection resources. 649 For this purpose, additional messages are defined that are 650 transmitted on the SPME that is defined between the end nodes of the 651 shared protection segment. When a SEN receives a PS Event message 652 from a LP domain indicating that protection switching to the 653 protection path has begun, it SHALL send a "Resource Allocation (RA) 654 Notification" message to the SSN that the resources have been 655 allocated, with an indication of the working path identifier. This 656 allocation needs to be confirmed for cases where both end nodes 657 report allocation to different working path identifiers. 659 The race condition can occur only when more than one protection paths 660 are configured to have the same Protection Switching Priority within 661 a SMP domain. 663 When the SSN receives the RA Notification message from the SEN, it 664 first checks whether it has received a PS Event message from an 665 endpoint of the other LP domain having the same Protection Switching 666 Priority that corresponds to the LP domain sending the RA 667 notification message. 669 If both have the same priority, the SSN compares the working path 670 identifier and sends an RA Ack message to the SEN only when it is 671 determined that the working path identifier contained in the RA 672 Notification message to have been allocated the shared protection 673 resources. Each working path or LP domain has a unique identifier 674 within a SMP domain and rules for deciding the priority will be 675 defined in later. 677 The SEN does not perform the LoP request procedure described in 678 Section 3.6.3 until it receives an RA Ack from the SSN. This results 679 in the overall protection switching time to be increased. To avoid 680 this, it is RECOMMENDED to configure none of the working paths 681 sharing the protection segment in a SMP domain to have the same 682 Protection Switching Priority. 684 4. Protocol 686 4.1. PDU Format 688 The shared mesh protection protocol messages MUST be sent over a 689 G-ACh as defined in [RFC5586]. 691 The shared mesh protection protocol messages are as follows: 693 o Protection Switching (PS) Event message [sent from protection path 694 endpoint to SEN] 696 o Lockout of Protection (LoP) Request message [sent from SEN to 697 protection path endpoint] 699 o Lockout of Protection (LoP) Acknowledgement message [sent from 700 protection path endpoint to SEN] 702 o Resource Allocation (RA) Notification message [sent from SEN to 703 SSN] 705 o Resource Allocation (RA) Acknowledgement message [sent from SSN to 706 SEN] 708 The channel type in ACH is used to indicate that the message is a SMP 709 protocol message. The protocol message MUST follow the ACH. 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 |0 0 0 1|Version| Reserved | Channel Type = Shared Mesh P. | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Shared Mesh Protection Protocol Message | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Figure 4: Shared mesh protection protocol message header 721 The SMP protocol message format is defined as follows: 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 |Version| Mode | Type | ST| Reserved | ID | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Figure 5: Shared mesh protection protocol message format 731 Each protocol message includes the following fields: 733 o Version - Version indicator 734 0x0 - reserved 735 0x1 - This version 736 0x2~0xF - reserved 738 o Mode - SMP switching and operation mode 739 0x0 - Bidirectional 740 0x1 - Unidirectional 741 0x2~0xF - reserved 743 o Type - SMP protocol message type indicator 744 0x0 - reserved 745 0x1 - PS Event 746 0x2 - LoP Request 747 0x3 - LoP Acknowledgement 748 0x4 - RA Notification 749 0x5 - RA Acknowledgement 750 0x6~0xF - reserved 752 o ST - SMP protocol message sub-type indicator 753 0x0 - Switch to working (for PS Event), 754 Clear LoP (for LoP Request) 755 0x1 - Switch to protection (for PS Event), 756 Assert LoP (for LoP Request) 757 0x2~0x3 - reserved 759 o ID - This is either the identifier of the LP domain that is 760 sending the message or the working path that was allocated 761 to the resources (dependent upon the message). 762 0x0 - reserved 763 0x1~0xFE - ID value 764 0xFF - reserved 766 o Reserved - reserved fields 768 All reserved bits SHOULD be zero upon transmission, and MUST be 769 ignored on reception. 771 4.2. Message Transmission 773 A new message must be transmitted immediately. The first three 774 messages should be transmitted as fast as possible so that fast 775 protection switching is possible even if one or two messages are lost 776 or corrupted. The interval of the first three messages should be 777 less than 3.3ms. Messages after the first three should be 778 transmitted with the interval of 5 seconds. 780 If no valid message is received, the last valid received information 781 remains applicable. 783 5. Operation of Shared Mesh Protection 785 This section illustrates the operation of the SMP protocol based on 786 the example illustrated in Figure 3 and the following assumptions: 788 o The SMP domain consists of the following end-to-end LP domains 789 (LPDs): 791 * LPD1: Working path ABC (W1) / Protection path APQC (P1) 793 * LPD2: Working path GHJ (W2) / Protection path GPQRSJ (P2) 795 * LPD3: Working path DEF (W3) / Protection path DRSF (P3) 797 o The SMP domain includes the following SMPG: 799 * S1: LPD1 & LPD2 (Shared protection segment - PQ) 801 * S2: LPD3 & LPD2 (Shared protection segment - RS) 803 o Protection Switching Priority is LPD1 > LPD2 > LPD3 (i.e. LPD1 804 has the highest priority.) 806 o All working paths are protected by 1:1 bidirectional protection 807 switching. 809 If a unidirectional failure occurs on W2 in the direction from node H 810 to node G as shown in Figure 6, SMP will perform the following: 812 a. Node G detects the failure, and initiates linear protection 813 switching for the failed W2. 815 b. At the same time, node G transmits the PS Event message notifying 816 the SENs of the shared protection segments for S1 & S2, i.e. P 817 and R, that a protection switching event occurred to node G. 819 c. SEN P compares the Protection Switching Priority of LPD2 with 820 those of other members of S1, i.e. LPD1. In this example, since 821 the priority of LPD1 is higher than LPD2, SEN P does not send any 822 message to node A. 824 d. SEN R compares the Protection Switching Priority of LPD2 with 825 those of other members of S2, i.e. LPD3. In this example, as 826 the priority of LPD3 is lower than LPD2, SEN R sends the RA 827 Notification message to the SSN S, blocks forwarding of P3 and 828 sends the LoP Request message requesting the assertion of LoP to 829 node D. 831 e. SSN S does not process the RA Notification message. (Since in 832 this example, all the LP domains are configured to have different 833 Protection Switching Priorities.) 835 f. Node D takes the LoP Request message as input to the LP 836 switching, and follows the LP procedure to process the end-to-end 837 LoP command. After completion of the LoP operation, node D sends 838 the LoP Ack message to SEN R. 840 g. SEN R unblocks forwarding of P3 upon receiving the LoP Ack 841 message from node D. 843 h. Since LPD2 operates in 1:1 bidirectional protection switching 844 mode, node J performs the switching operations (i.e. switches its 845 bridge and selector state) to synchronize with node G, and also 846 transmits the PS Event message to node S and Q, which are SENs 847 for G->H->J. Using a parallel procedure to that described in 848 steps c & d, SEN S sends the LoP Request message to node F while 849 the SEN Q does not take an action to node C. 851 W1 W3 852 ==A======B======C== ==D======E======F== 853 \ / \ / 854 \ LPD1 / \ LPD3 / 855 \ / \ / == : Normal traffic 856 P=====Q================R=====S 857 // \\ 858 // LPD2 \\ 859 // \\ 860 ==G------xx---------H------------------J== 861 SF on G<-H W2 863 Figure 6: Shared Mesh Protection Example 1 865 Figure 7 shows a progression from Figure 6. While LPD2 is in 866 protecting state with its traffic transported on protection path P2, 867 another unidirectional failure occurs on W1 in the direction from 868 node B to node A. 870 In this case, the shared mesh protection will operate as follows: 872 a. Node A detects the failure, and initiates the linear protection 873 switching for the failed W1. 875 b. At the same time, node A transmits the PS Event message notifying 876 SEN for S1, i.e. node P, that a protection switching event 877 occurred. 879 c. SEN P compares the Protection Switching Priority of LPD1 with 880 those of the other members in S1, in this case LPD2. In this 881 example, since the priority of LPD2 is lower than LPD1, SEN P 882 sends the RA Notification message requesting the assertion of LoP 883 to node G. 885 d. SSN Q does not process the RA Notification message. (Since in 886 this example, all the LPDs are configured to have different 887 Protection Switching Priorities.) 889 e. Node G accepts the LoP Request message as input to linear 890 protection switching, and follows LP procedure to process the LoP 891 command. When LPD2 is forced to lockout its protection path P2, 892 it may try to find another available path. m:n protection or 893 other recovery mechanism may be used for this, but this 894 discussion is out of scope for this document. After completion 895 of the LoP operation, node G sends the LoP Ack message to SEN P. 897 f. SEN P unblocks forwarding of P2 upon receiving the LoP Ack 898 message from node G. 900 g. As node G changes its bridge and selector states from protection 901 to working, it will transmit the PS Event message to the SENs of 902 S1 & S2, i.e. P & R, notifying that the shared protection 903 resources should be released. 905 h. SEN P compares the Protection Switching Priority of LPD2 with the 906 other members of S1, i.e. LPD1, and does not transmit any 907 message to node A, but SEN R sends the LoP Request message to 908 request the clear of LoP to node D, after comparing the 909 Protection Switching Priorities of the members of S2. 911 i. Node D accepts the message as input to the linear protection 912 switching, and follows the LP procedures to clear the LoP 913 command. 915 SF on 916 A<-B W1 W3 917 ==A-xx---B------C== ==D======E======F== 918 \\ // \ / 919 \\ LPD1 // \ LPD3 / 920 \\ // \ / == : Normal traffic 921 P=====Q---------------R-----S 922 / \ 923 / LPD2 \ 924 / \ 925 ==G------xx---------H-----------------J== 926 SF on G<-H W2 928 Figure 7: Shared Mesh Protection Example 2 930 NOTE: Examples for race condition to be provided in the next version. 932 6. Manageability Considerations 934 To be added in future version. 936 7. IANA Considerations 938 To be added in future version. 940 8. Security Considerations 942 To be added in future version. 944 9. References 946 9.1. Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", RFC 2119, BCP 14, March 1997. 951 [RFC5654] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 952 "Requirements for the Transport Profile of MPLS", 953 RFC 5654, April 2009. 955 9.2. Informative References 957 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 958 Label Switching Architecture", RFC 3031, January 2001. 960 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 961 Edge (PWE3) Architecture", RFC 3985, March 2005. 963 [RFC5921] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP 964 Framework", RFC 5921, July 2010. 966 [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability 967 Framework", RFC 6372, Sept 2011. 969 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudo Wire (PW) Virtual 970 Circuit Connectivity Verification ((VCCV): A Control 971 Channel for Pseudowires", RFC 5085, Dec 2007. 973 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 974 Associated Channel", RFC 5586, June 2009. 976 [RFC4428] Papadimitriou, D. and E. Mannie, "Analysis of Generalized 977 Multi-Protocol Label Switching (GMPLS) based Recovery 978 Mechanisms (including Protection and Restoration) Recovery 979 (Protection and Restoration)", RFC 4428, March 2006. 981 [G.808.1] SG15, "Generic Protection Switching - Linear trail and 982 subnetwork protection", ITU-T G.808.1, Feb 2010. 984 Authors' Addresses 986 Tae-sik Cheung 987 ETRI 988 161 Gajeong 989 Yuseong, Daejeon 305-700 990 South Korea 992 Phone: +82 42 860 5646 993 Email: cts@etri.re.kr 995 Jeong-dong Ryoo 996 ETRI 997 161 Gajeong 998 Yuseong, Daejeon 305-700 999 South Korea 1001 Phone: +82 42 860 5384 1002 Email: ryoo@etri.re.kr 1004 Yaacov Weingarten 1005 Nokia Siemens Networks 1006 3 Hanagar St. Neve Ne'eman B 1007 Hod Hasharon, 45241 1008 Israel 1010 Phone: +972-54-220 0977 1011 Email: wyaacov@gmail.com 1013 Nurit Sprecher 1014 Nokia Siemens Networks 1015 3 Hanagar St. Neve Ne'eman B 1016 Hod Hasharon, 45241 1017 Israel 1019 Email: nurit.sprecher@nsn.com 1020 Daniel King 1021 Old Dog Consulting 1022 United Kingdom 1024 Email: daniel@olddog.co.uk