idnits 2.17.1 draft-zulr-mpls-tp-linear-protection-switching-12.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 -- The document date (March 3, 2014) is 3700 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-mpls-psc-updates-01 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-tp-psc-itu-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group H. van Helvoort, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Informational J. Ryoo, Ed. 5 Expires: September 4, 2014 ETRI 6 H. Zhang 7 Huawei Technologies 8 F. Huang 9 Philips 10 H. Li 11 China Mobile 12 A. D'Alessandro 13 Telecom Italia 14 March 3, 2014 16 Pre-standard Linear Protection Switching in MPLS-TP 17 draft-zulr-mpls-tp-linear-protection-switching-12.txt 19 Abstract 21 The IETF Standards Track solution for MPLS Transport Profile (MPLS- 22 TP) Linear Protection is provided in RFC 6378, draft-ietf-mpls-psc- 23 updates and draft-ietf-mpls-tp-psc-itu. 25 This document describes the pre-standard implementation of MPLS-TP 26 Linear Protection that has been deployed by several network operators 27 using equipment from multiple vendors. At the time of publication 28 these pre-standard implementations were still in operation carrying 29 live traffic. 31 The specified mechanism supports 1+1 unidirectional/bidirectional 32 protection switching and 1:1 bidirectional protection switching. It 33 is purely supported by MPLS-TP data plane, and can work without any 34 control plane. 36 [Editor's note] The followings are to be included in "Status of 37 Memo": 39 This document is not an Internet Standards Track specification; it is 40 published for informational purposes. 42 This is a contribution to the RFC Series, independently of any other 43 RFC stream. The RFC Editor has chosen to publish this document at 44 its discretion and makes no statement about its value for 45 implementation or deployment. Documents approved for publication by 46 the RFC Editor are not a candidate for any level of Internet 47 Standard; see Section 2 of RFC 5741. 49 Information about the current status of this document, any errata, 50 and how to provide feedback on it may be obtained at http://www.rfc- 51 editor.org/info/rfcxxxx. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on September 4, 2014. 70 Copyright Notice 72 Copyright (c) 2014 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 89 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 4. Linear protection switching overview . . . . . . . . . . . . 5 91 4.1. Protection architecture types . . . . . . . . . . . . . . 5 92 4.1.1. 1+1 architecture . . . . . . . . . . . . . . . . . . 6 93 4.1.2. 1:1 architecture . . . . . . . . . . . . . . . . . . 6 94 4.1.3. 1:n architecture . . . . . . . . . . . . . . . . . . 6 95 4.2. Protection switching type . . . . . . . . . . . . . . . . 6 96 4.3. Protection operation type . . . . . . . . . . . . . . . . 7 98 5. Protection switching trigger conditions . . . . . . . . . . . 7 99 5.1. Fault conditions . . . . . . . . . . . . . . . . . . . . 7 100 5.2. External commands . . . . . . . . . . . . . . . . . . . . 8 101 5.2.1. End-to-end commands . . . . . . . . . . . . . . . . . 8 102 5.2.2. Local commands . . . . . . . . . . . . . . . . . . . 9 103 6. Protection switching schemes . . . . . . . . . . . . . . . . 9 104 6.1. 1+1 unidirectional protection switching . . . . . . . . . 9 105 6.2. 1+1 bidirectional protection switching . . . . . . . . . 10 106 6.3. 1:1 bidirectional protection switching . . . . . . . . . 12 107 7. APS protocol . . . . . . . . . . . . . . . . . . . . . . . . 13 108 7.1. APS PDU format . . . . . . . . . . . . . . . . . . . . . 13 109 7.2. APS transmission . . . . . . . . . . . . . . . . . . . . 16 110 7.3. Hold-off timer . . . . . . . . . . . . . . . . . . . . . 16 111 7.4. WTR timer . . . . . . . . . . . . . . . . . . . . . . . . 17 112 7.5. Command acceptance and retention . . . . . . . . . . . . 18 113 7.6. Exercise operation . . . . . . . . . . . . . . . . . . . 18 114 8. Protection switching logic . . . . . . . . . . . . . . . . . 18 115 8.1. Principle of operation . . . . . . . . . . . . . . . . . 18 116 8.2. Equal priority requests . . . . . . . . . . . . . . . . . 21 117 8.3. Signal degrade of the protection transport entity . . . . 22 118 9. Protection switching state transition table . . . . . . . . . 22 119 10. Security considerations . . . . . . . . . . . . . . . . . . . 23 120 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 121 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 122 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 123 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 124 13.2. Informative References . . . . . . . . . . . . . . . . . 25 125 Appendix A. Operation examples of APS protocol . . . . . . . . . 25 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 128 1. Introduction 130 The IETF Standards Track solution for MPLS Transport Profile (MPLS- 131 TP) Linear Protection is provided in RFC 6378 [RFC6378], draft-ietf- 132 mpls-psc-updates [I-D.ietf-mpls-psc-updates] and draft-ietf-mpls-tp- 133 psc-itu [I-D.ietf-mpls-tp-psc-itu]. 135 This document describes the pre-standard implementation of MPLS-TP 136 Linear Protection that has been deployed by several network operators 137 using equipment from multiple vendors. At the time of publication 138 these pre-standard implementations were still in operation carrying 139 live traffic. 141 This implementation was considered in the MPLS WG, however a 142 different path was chosen. 144 This document may be useful in the future if a vendor or operator is 145 trying to interwork with a different vendor or operator who has 146 deployed the pre-standard implementation, and it provides a permanent 147 record of the pre-standard implementation. It is also worth noting 148 that the experience gained during deployment of the implementations 149 of this document was used to refine [I-D.ietf-mpls-tp-psc-itu]. 151 MPLS-TP is defined as the transport profile of MPLS technology to 152 allow its deployment in transport networks. A typical feature of a 153 transport network is that it can provide fast protection switching 154 for end-to-end or segments. The protection switching time is 155 generally required to be less than 50ms to meet the strict 156 requirements of services such as voice, private line, etc. 158 The goal of a linear protection switching mechanism is to satisfy the 159 requirement of fast protection switching for an MPLS-TP network. 160 Linear protection switching means that, for one or more working 161 transport entities (working paths), there is one protection transport 162 entity (protection path), which is disjoint from any of working 163 transport entities, ready to take over the service transmission when 164 a working transport entity has failed. 166 This document specifies a 1+1 unidirectional protection switching 167 mechanism for unidirectional transport entity (either point-to-point 168 or point-to-multipoint) as well as a bidirectional point-to-point 169 transport entity, and a 1+1/1:1 bidirectional protection switching 170 mechanism for point-to-point bidirectional transport entity. Since 171 bidirectional protection switching needs the coordination of the two 172 endpoints of the transport entity, this document also specifies the 173 Automatic Protection Switching (APS) protocol which is used for this 174 purpose. 176 The linear protection mechanism described in this document is 177 applicable to both Label Switched Paths (LSPs) and Pseudowires (PWs). 179 The APS protocol specified in this document is based on the same 180 principles and behavior of the APS protocol designed for Synchronous 181 Optical Network (SONET) [T1.105.01]/Synchronous Digital Hierarchy 182 (SDH) [G.841], Optical Transport Netwrok (OTN) [G.873.1] and Carrier 183 Class Ethernet [G.8031] and provides commonality with the established 184 operation models utilized in transport network technologies (e.g., 185 SDH/SONET, OTN and Ethernet). 187 2. Conventions Used in This Document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 3. Acronyms 195 This document uses the following acronyms: 197 APS Automatic Protection Switching 198 DNR Do not Revert 199 EXER Exercise 200 G-ACh Generic Associated Channel 201 FS Forced Switch 202 LO Lockout of Protection 203 LSP Label Switched Path 204 MPLS-TP MPLS Transport Profile 205 MS Manual Switch 206 MS-P Manual Switch to Protection transport entity 207 MS-W Manual Switch to Working transport entity 208 NR No Request 209 OAM Operations, Administration, and Maintenance 210 OTN Optical Transport Network 211 PDU Protocol Data Unit 212 PW Pseudowire 213 RR Reverse Request 214 SD Signal Degrade 215 SD-P Signal Degrade on Protection transport entity 216 SD-W Signal Degrade on Working transport entity 217 SDH Synchronous Digital Hierarchy 218 SF Signal Fail 219 SF-P Signal Fail on Protection transport entity 220 SF-W Signal Fail on Working transport entity 221 SONET Synchronous Optical Network 222 WTR Wait to Restore 224 4. Linear protection switching overview 226 To guarantee the protection switching time for a working transport 227 entity, its protection transport entity is always pre-configured 228 before the failure occurs. Normally, traffic will be transmitted and 229 received on the working transport entity. Switching to the 230 protection transport entity is usually triggered by link or node 231 failure, external commands, etc. Note that external commands are 232 often used in transport networks by operators, and they are very 233 useful in cases of service adjustment, path maintenance, etc. 235 4.1. Protection architecture types 236 4.1.1. 1+1 architecture 238 In the 1+1 architecture, the protection transport entity is 239 associated with a working transport entity. The normal traffic is 240 permanently bridged onto both the working transport entity and the 241 protection transport entity at the source endpoint of the protected 242 domain. The normal traffic on working and protection transport 243 entities is transmitted simultaneously to the destination sink 244 endpoint of the protected domain, where a selection between the 245 working and protection transport entity is made based on 246 predetermined criteria, such as signal fail and signal degrade 247 indications. 249 4.1.2. 1:1 architecture 251 In the 1:1 architecture, the protection transport entity is 252 associated with a working transport entity. When the working 253 transport entity is determined to be impaired, the normal traffic 254 MUST be transferred from the working to the protection transport 255 entity at both the source and sink endpoints of the protected domain. 256 The selection between the working and protection transport entities 257 is made based on predetermined criteria, such as signal fail and 258 signal degrade indications from the working or protection transport 259 entity. 261 The bridge at the source endpoint can be realized in two ways: it is 262 either a selector bridge or a broadcast bridge. With a selector 263 bridge the normal traffic is connected either to the working 264 transport entity or the protection transport entity. With a 265 broadcast bridge the normal traffic is permanently connected to the 266 working transport entity, and in case a protection switch is active 267 also to the protection transport entity. The broadcast bridge is 268 recommended to be used in revertive mode only. 270 4.1.3. 1:n architecture 272 Details for the 1:n protection switching architecture are out of 273 scope of this document and will be provided in a different document 274 in the future. 276 It is worth noting that the APS protocol defined here is capable of 277 supporting 1:n operations. 279 4.2. Protection switching type 281 The linear protection switching types can be a unidirectional 282 switching type or a bidirectional switching type. 284 o Unidirectional switching type: Only the affected direction of 285 working transport entity is switched to protection transport 286 entity; the selectors at each endpoint operate independently. 287 This switching type is recommended to be used for 1+1 protection 288 in this document. 290 o Bidirectional switching type: Both directions of working transport 291 entity, including the affected direction and the unaffected 292 direction, are switched to protection transport entity. For 293 bidirectional switching, the APS protocol is required to 294 coordinate the two endpoints so that both have the same bridge and 295 selector settings, even for a unidirectional failure. This type 296 is applicable for 1+1 and 1:1 protection. 298 4.3. Protection operation type 300 The linear protection operation types can be a non-revertive 301 operation type or a revertive operation type. 303 o Non-revertive operation: The normal traffic will not be switched 304 back to the working transport entity even after a protection 305 switching cause has cleared. This is generally accomplished by 306 replacing the previous switch request with a "Do not Revert (DNR)" 307 request, which has a low priority. 309 o Revertive operation: The normal traffic is restored to the working 310 transport entity after the condition(s) causing the protection 311 switching have cleared. In the case of clearing a command (e.g., 312 Forced Switch), this happens immediately. In the case of clearing 313 of a defect, this generally happens after the expiry of a "Wait to 314 Restore (WTR)" timer, which is used to avoid chattering of 315 selectors in the case of intermittent defects. 317 5. Protection switching trigger conditions 319 5.1. Fault conditions 321 Fault conditions mean the requests generated by the local Operations, 322 Administration, and Maintenance (OAM) function. 324 o Signal Failure (SF): If an endpoint detects a failure by an OAM 325 function or other mechanism, it will submit a local signal failure 326 (local SF) to APS module to request a protection switch. The 327 local SF could be on the working transport entity (Signal Fail on 328 Working transport entity (SF-W)) or the protection transport 329 entity (Signal Fail on Protection transport entity (SF-P)). 331 o Signal Degrade (SD): If an endpoint detects signal degradation by 332 an OAM function or other mechanism, it will submit a local signal 333 degrade (local SD) to the APS module to request a protection 334 switching. The local SD could be on the working transport entity 335 (Signal Degrade on Working transport entity (SD-W)) or the 336 protection transport entity (Signal Degrade on Protection 337 transport entity (SD-P)). 339 5.2. External commands 341 The external command issues an appropriate external request to the 342 protection process. 344 5.2.1. End-to-end commands 346 These commands are applied to both local and remote nodes. When the 347 APS protocol is present, these commands, except the Clear command, 348 are signaled to the far end of the connection. In bidirectional 349 switching, these commands affect the bridge and selector at both 350 ends. 352 o Lockout of Protection (LO): This command is used to provide the 353 operator a tool for temporarily disabling access to the protection 354 transport entity. 356 o Manual switch (MS): This command is used to provide the operator a 357 tool for temporarily switching normal traffic to the working 358 transport entity (Manual Switch to Working transport entity 359 (MS-W)) or to the protection transport entity (Manual Switch to 360 Protection transport entity (MS-P)), unless a higher priority 361 switch request (i.e., LO, FS, or SF) is in effect. 363 o Forced switch (FS): This command is used to provide the operator a 364 tool for temporarily switching normal traffic from working 365 transport entity to protection transport entity, unless a higher 366 priority switch request (i.e., LO or SF-P) is in effect. 368 o Exercise (EXER): Exercise is a command to test if the APS 369 communication is operating correctly. The EXER command SHALL NOT 370 affect the state of the protection selector and bridge. 372 o Clear: This command between management and local protection 373 process is not a request sent by APS to other endpoints. It is 374 used to clear the active near end external command or WTR state. 376 5.2.2. Local commands 378 These commands apply only to the near end (local node) of the 379 protection group. Even when an APS protocol is supported, they are 380 not signaled to the far end. 382 o Freeze: This command freezes the state of the protection group. 383 Until the freeze is cleared, additional near end commands are 384 rejected and condition changes and received APS information are 385 ignored. When the Freeze command is cleared, the state of the 386 protection group is recomputed based on the condition and received 387 APS information. 389 Because the freeze is local, if the freeze is issued at one end 390 only, a failure of protocol can occur as the other end is open to 391 accept any operator command or fault condition. 393 o Clear Freeze: This command clears the local freeze. 395 6. Protection switching schemes 397 6.1. 1+1 unidirectional protection switching 398 +-----------+ +-----------+ 399 | |---------------------------------------| | 400 | -+---------------------------------------+- | 401 | / |---------------------------------------| \ | 402 | / | Working transport entity | \ | 403 --+-------> | | --------+-> 404 | \ | | | 405 | \ |---------------------------------------| | 406 | -+---------------------------------------| | 407 | source |---------------------------------------| sink | 408 +-----------+ Protection transport entity +-----------+ 409 (normal condition) 411 +-----------+ +-----------+ 412 | |---------------------------------------| | 413 | -+------------------XX-------------------+ | 414 | / |---------------------------------------| | 415 | / | Working transport entity (failure) | | 416 --|-------> | | --------+-> 417 | \ | | / | 418 | \ |---------------------------------------| / | 419 | -+---------------------------------------+- | 420 | source |---------------------------------------| sink | 421 +-----------+ Protection transport entity +-----------+ 422 (failure condition) 424 Figure 1: 1+1 unidirectional linear protection switching 426 1+1 unidirectional protection switching is the simplest protection 427 switching mechanism. The normal traffic is permanently bridged on 428 both the working and protection transport entities at the source 429 endpoint of the protected domain. In the normal condition, the sink 430 endpoint receives traffic from the working transport entity. If the 431 sink endpoint detects a failure on the working transport entity, it 432 will switch to receive traffic from the protection transport entity. 433 1+1 unidirectional protection switching is recommended to be used for 434 unidirectional transport. 436 Note that 1+1 unidirectional protection switching does not use the 437 APS coordination protocol since it only perform protection switching 438 based on the local request. 440 6.2. 1+1 bidirectional protection switching 441 +-----------+ +-----------+ 442 | |---------------------------------------| | 443 | -+<--------------------------------------+- | 444 | / +-------------------------------------->+ \ | 445 | sink / /|---------------------------------------|\ \ sink | 446 <-+-------/ / | working transport entity | --\-------+-> 447 --+--------> | | <------+-- 448 | source \ | | / Source| 449 | \|---------------------------------------| / | 450 | +-------------------------------------->| / | 451 | |<--------------------------------------+- | 452 | APS <...................................................> APS | 453 | |---------------------------------------+ | 454 +-----------+ Protection transport entity +-----------+ 455 (normal condition) 457 +-----------+ +-----------+ 458 | |---------------------------------------| | 459 | +<----------------XX--------------------+- | 460 | +-------------------------------------->+ \ | 461 | /|---------------------------------------| \ | 462 | source / | working transport entity (failure) | \ source| 463 --+--------> | | \<-----+-- 464 <-+------- \ | | --/------+-> 465 | sink \ \|---------------------------------------| / / sink | 466 | \ +-------------------------------------->+- / | 467 | --+<--------------------------------------+-/ | 468 | APS <...................................................> APS | 469 | |---------------------------------------+ | 470 +-----------+ Protection transport entity +-----------+ 471 (failure condition) 473 Figure 2: 1+1 bidirectional linear protection switching 475 In 1+1 bidirectional protection switching, for each direction, the 476 normal traffic is permanently bridged on both the working and 477 protection transport entities at the source endpoint of the protected 478 domain. In the normal condition, for each direction, the sink 479 endpoint receives traffic from the working transport entity. 481 If the sink endpoint detects a failure on the working transport 482 entity, it will switch to receive traffic from the protection 483 transport entity. It will also send an APS message to inform the 484 sink endpoint on the other direction to switch to receive traffic 485 from the protection transport entity. 487 The APS mechanism is necessary to coordinate the two endpoints of 488 transport entity and implement 1+1 bidirectional protection switching 489 even for a unidirectional failure. 491 6.3. 1:1 bidirectional protection switching 493 +-----------+ +-----------+ 494 | |---------------------------------------| | 495 | -+<--------------------------------------+- | 496 | / +-------------------------------------->+ \ | 497 | sink / /|---------------------------------------|\ \ source| 498 <-+-------/ / | working transport entity | \ <-------+-- 499 --+--------> | | ---------+-> 500 | source | | sink | 501 | |---------------------------------------| | 502 | | | | 503 | | | | 504 | APS <...................................................> APS | 505 | |---------------------------------------| | 506 +-----------+ Protection transport entity +-----------+ 507 (normal condition) 509 +-----------+ +-----------+ 510 | |---------------------------------------| | 511 | | \/ | | 512 | | /\ | | 513 | |---------------------------------------| | 514 | source | working transport entity (failure) | sink | 515 --+-------> | | --------+-> 516 <-+------- \ | | / <------+-- 517 | sink \ \ |---------------------------------------| / / source| 518 | \ -+-------------------------------------->+- / | 519 | --+<--------------------------------------+-- | 520 | APS <...................................................> APS | 521 | |---------------------------------------+ | 522 +-----------+ Protection transport entity +-----------+ 523 (failure condition) 525 Figure 3: 1:1 bidirectional linear protection switching 527 In 1:1 bidirectional protection switching, for each direction, the 528 source endpoint sends traffic on either the working transport entity 529 or the protection transport entity. The sink endpoint receives the 530 traffic from the transport entity where the source endpoint sends on. 532 In the normal condition, for each direction, the source endpoint and 533 sink endpoint send and receive traffic from the working transport 534 entity. 536 If the sink endpoint detects a failure on the working transport 537 entity, it will switch to send and receive traffic from the 538 protection transport entity. It will also send an APS message to 539 inform the sink endpoint on another direction to switch to send and 540 receive traffic from the protection transport entity. 542 The APS mechanism is necessary to coordinate the two endpoints of the 543 transport entity and implement 1:1 bidirectional protection switching 544 even for a unidirectional failure. 546 7. APS protocol 548 This APS protocol is based upon the APS protocol defined in Clause 11 549 of [G.8031]. See that reference for further definition of the PDU 550 fields and protocol details beyond the description in this document. 552 7.1. APS PDU format 554 APS packets MUST be sent over a Generic Associated Channel (G-ACh) as 555 defined in RFC 5586 [RFC5586]. 557 The format of APS Protocol Data Unit (PDU) is specified in Figure 4 558 below. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Channel Type (=0x7FFA) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | MEL | Version | OpCode | Flags | TLV Offset | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | APS Specific Information | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | End TLV | 570 +-+-+-+-+-+-+-+-+ 572 Figure 4: APS PDU format 574 The following values MUST be used for APS PDU: 576 o Channel Type: The Channel Type MUST be configurable by the 577 implementation. During deployment the local system administrator 578 provisioned the value 0x7FFA. This is a code point value in the 579 range of experimental Channel Types as described in RFC 5586 580 section 10. 582 o MEL (Maintenance Entity group Level): The MEL value to set and 583 check MUST be configurable. The DEFAULT value MUST be "111". 585 With co-routed bidirectional transport paths, the configured MEL 586 MUST be the same in both directions. 588 o Version: 0x00 590 o OpCode: 0x27 (=0d39) 592 o Flags: 0x00 594 o TLV Offset: 4 596 o End TLV: 0x00 598 The format of the APS-specific information is defined in Figure 5. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |Request|Pr.Type| Requested | Bridged | | | 604 | / |-+-+-+-| | |T| Reserved(0)| 605 | State |A|B|D|R| Signal | Signal | | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 5: APS specific information format 610 All bits defined as "Reserved" MUST be transmitted as 0 and ignored 611 on reception. 613 o Request/State: 615 The four bits indicate the protection switching request type. See 616 Figure 6 for the code of each request/state type. 618 In case that there are multiple protection switching requests, 619 only the protection switching request with the highest priority 620 MUST be processed. 622 +------------------------------------+---------------+ 623 | Request/State | code/priority | 624 +------------------------------------+---------------+ 625 |Lockout of Protection (LO) | 1111 (highest)| 626 +------------------------------------+---------------+ 627 |Signal Fail on Protection (SF-P) | 1110 | 628 +------------------------------------+---------------+ 629 |Forced Switch (FS) | 1101 | 630 +------------------------------------+---------------+ 631 |Signal Fail on Working (SF-W) | 1011 | 632 +------------------------------------+---------------+ 633 |Signal Degrade (SD) | 1001 | 634 +------------------------------------+---------------+ 635 |Manual Switch (MS) | 0111 | 636 +------------------------------------+---------------+ 637 |Wait to Restore (WTR) | 0101 | 638 +------------------------------------+---------------+ 639 |Exercise (EXER) | 0100 | 640 +------------------------------------+---------------+ 641 |Reverse Request (RR) | 0010 | 642 +------------------------------------+---------------+ 643 |Do Not Revert (DNR) | 0001 | 644 +------------------------------------+---------------+ 645 |No Request (NR) | 0000 (lowest) | 646 +------------------------------------+---------------+ 648 Figure 6: Protection switching request code/priority 650 o Protection type (Pr.Type): 652 The four bits are used to specify the protection type. 654 A: reserved (set by default to 1) 655 B: 0 - 1+1 (permanent bridge) 656 1 - 1:1 (no permanent bridge) 657 D: 0 - Unidirectional switching 658 1 - Bidirectional switching 659 R: 0 - Non-revertive operation 660 1 - Revertive operation 662 o Requested Signal: 664 This byte is used to indicate the traffic that the near end 665 requests to be carried over the protection entity. 667 value = 0: Null traffic 668 value = 1: Normal traffic 1 669 value = 2~255: Reserved 671 o Bridged Signal: 673 This byte is used to indicate the traffic that is bridged onto the 674 protection entity. 676 value = 0: Null traffic 677 value = 1: Normal traffic 1 678 value = 2~255: Reserved 680 o Bridge Type (T): 682 This bit is used to further specify the type of non-permanent 683 bridge for 1:1 protection switching. 685 value = 0: Selector bridge 686 value = 1: Broadcast bridge 688 o Reserved: 690 This field MUST be set to zero. 692 7.2. APS transmission 694 The APS message MUST be transported on the protection transport 695 entity by encapsulatation with the protection transport entity label 696 (the label of the LSP used to transport protection traffic). If an 697 endpoint receives APS-specific information from the working transport 698 entity, it MUST ignore this information, and MUST report the Failure 699 of Protocol defect (see Section 8.1) to the operator. 701 A new APS packet MUST be transmitted immediately when a change in the 702 transmitted status occurs. The first three APS packets MUST be 703 transmitted as fast as possible only if the APS information to be 704 transmitted has been changed so that fast protection switching is 705 possible even if one or two APS packets are lost or corrupted. The 706 interval of the first three APS packets SHOULD be 3.3ms. APS packets 707 after the first three MUST be transmitted with the interval of 5 708 seconds. 710 If no valid APS-specific information is received, the last valid 711 received information remains applicable. 713 7.3. Hold-off timer 715 In order to coordinate timing of protection switches at multiple 716 layers, a hold-off timer MAY be required. The purpose is to allow a 717 server layer protection switch to have a chance to fix the problem 718 before switching at a client layer. 720 Each selector SHOULD have a provisioned hold-off timer. The 721 suggested range of the hold-off timer is 0 to 10 seconds in steps of 722 100 ms (accuracy of +/-5 ms). 724 When a new defect or more severe defect occurs (new SF or SD) on the 725 active transport entity (the transport entity that currently carries 726 and selects traffic), this event will not be reported immediately to 727 protection switching if the provisioned hold-off timer value is non- 728 zero. Instead, the hold-off timer SHALL be started. When the hold- 729 off timer expires, it SHALL be checked whether a defect still exists 730 on the transport entity that started the timer. If it does, that 731 defect SHALL be reported to protection switching. The defect need 732 not be the same one that started the timer. 734 This hold-off timer mechanism SHALL be applied for both working and 735 protection transport entities. 737 7.4. WTR timer 739 In revertive mode of operation, to prevent frequent operation of the 740 protection switch due to an intermittent defect, a failed working 741 transport entity MUST become fault-free. After the failed working 742 transport entity meets this criterion, a fixed period of time SHALL 743 elapse before a normal traffic signal uses it again. This period, 744 called a WTR period, MAY be configured by the operator in 1 minute 745 steps between 5 and 12 minutes; the default value is 5 minutes. An 746 SF or SD condition will override the WTR. To activate the WTR timer 747 appropriately, even when both ends concurrently detect clearance of 748 SF-W and SD-W, when the local state transits from SF-W or SD-W to No 749 Request (NR) with the requested signal number 1, the previous local 750 state, SF-W or SD-W, MUST be memorized. If both the local state and 751 far-end state are NR with the requested signal number 1, the local 752 state transits to WTR only when the previous local state is SF-W or 753 SD-W. Otherwise, the local state transits to NR with the requested 754 signal number 0. 756 In revertive mode of operation, when the protection is no longer 757 requested, i.e., the failed working transport entity is no longer in 758 SF or SD condition (and assuming no other requesting transport 759 entities), a local WTR state will be activated. Since this state 760 becomes the highest in priority, it is indicated on the APS signal, 761 and maintains the normal traffic signal from the previously failed 762 working transport entity on the protection transport entity. This 763 state SHALL normally time out and become a NR state. The WTR timer 764 deactivates earlier when any request of higher priority request pre- 765 empts this state. 767 7.5. Command acceptance and retention 769 The commands Clear, LO, FS, MS, and EXER are accepted or rejected in 770 the context of previous commands, the condition of the working and 771 protection entities in the protection group, and (in bidirectional 772 switching only) the APS information received. 774 The Clear command MUST be only valid if a near end LO, FS, MS, or 775 EXER command is in effect, or if a WTR state is present at the near 776 end and rejected otherwise. This command will remove the near-end 777 command or WTR state, allowing the next lower-priority condition or 778 (in bidirectional switching) APS request to be asserted. 780 Other commands MUST be rejected unless they are higher priority than 781 the previously existing command, condition, or (in bidirectional 782 switching) APS request. If a new command is accepted, any previous, 783 lower-priority command that is overridden MUST be forgotten. If a 784 higher priority command overrides a lower-priority condition or (in 785 bidirectional switching) APS request, that other request will be 786 reasserted if it still exists at the time the command is cleared. If 787 a command is overridden by a condition or (in bidirectional 788 switching) APS request, that command MUST be forgotten. 790 7.6. Exercise operation 792 Exercise is a command to test if the APS communication is operating 793 correctly. It is lower priority than any "real" switch request. It 794 is only valid in bidirectional switching, since this is the only 795 place where you can get a meaningful test by looking for a response. 797 The Exercise command SHALL issue the command with the same requested 798 and bridged signal numbers of the NR, Reverse Request (RR) or DNR 799 request that it replaces. The valid response will be an RR with the 800 corresponding requested and bridged signal numbers. When Exercise 801 commands are input at both ends, an EXER, instead of RR, MUST be 802 transmitted from both ends. The standard response to DNR MUST be DNR 803 rather than NR. When the exercise command is cleared, it MUST be 804 replaced with NR or RR if the requested signal number is 0, and DNR 805 or RR if the requested signal number is 1. 807 8. Protection switching logic 809 8.1. Principle of operation 810 +-------------+ Persistent +----------+ 811 SF,SD | Hold-off | fault | Local | 812 ----------->| timer logic |----------->| request | 813 +-------------+ | logic | 814 Other local requests ----------------->| | 815 (LO, FS, MS, EXER, Clear) +----------+ 816 | 817 | Highest 818 | local request 819 | 820 Remote APS V 821 Message +-------+ Remote APS +----------------+ 822 ------------->| APS | request/state | APS process | 823 (received | check |-------------->| logic | 824 from far end) +-------+ +----------------+ 825 | ^ | | 826 | | | Signaled | 827 | | | APS | 828 | | Txed | | 829 | | "Requested V | 830 | | Signal" +-----------+ | 831 | +-----------------| APS mess. | | 832 | | generator | | 833 | +-----------+ | 834 | | | 835 V | | 836 Failure of V | 837 Protocol APS Message | 838 Detection V 839 Set local 840 bridge/selector 842 Figure 7: Protection Switching Logic 844 Figure 7 describes the protection switching logic. 846 One or more local protection switching requests may be active. The 847 "local request logic" determines which of these requests is highest 848 using the order of priority given in Figure 6. This highest local 849 request information SHALL be passed on to the "APS process logic". 850 Note that an accepted Clear command, clearance of SF or SD or 851 expiration of WTR timer SHALL NOT be processed by the local request 852 logic, but SHALL be considered as the highest local request and 853 submitted to the APS process logic for processing. 855 The remote APS message is received from the far end and is subjected 856 to the validity check and mismatch detection in "APS check". Failure 857 of Protocol situations are as follows: 859 o The "B" field mismatch due to incompatible provisioning; 861 o The reception of APS message from the working entity due to 862 working/protection configuration mismatch; 864 o No match in sent "Requested Signal" and received "Requested 865 Signal" for more than 50 ms; 867 o No APS message is received on the protection transport entity 868 during at least 3.5 times the long APS interval (e.g. at least 869 17.5 seconds) and there is no defect on the protection transport 870 entity. 872 Provided the "B" field matches: 874 o If "D" bit mismatches, the bidirectional side will fall back to 875 unidirectional switching. 877 o If the "R" bit mismatches, one side will clear switches to WTR and 878 the other will clear to DNR. The two sides will interwork and the 879 traffic is protected. 881 o If the "T" bit mismatches, the side using a broadcast bridge will 882 fall back to using a selector bridge. 884 The APS message with invalid information MUST be ignored, and the 885 last valid received information remains applicable. 887 The linear protection switching algorithm SHALL commence immediately 888 every time one of the input signals changes, i.e., when the status of 889 any local request changes, or when a different APS specific 890 information is received from the far end. The consequent actions of 891 the algorithm are also initiated immediately, i.e., change the local 892 bridge/selector position (if necessary), transmit a new APS specific 893 information (if necessary), or detect the failure of protocol defect 894 if the protection switching is not completed within 50 ms. 896 The state transition is calculated in the "APS process logic" based 897 on the highest local request, the request of the last received 898 "Request/State" information, and state transition tables defined in 899 Section 9, as follows: 901 o If the highest local request is Clear, clearance of SF or SD, or 902 expiration of WTR, a state transition is calculated first based on 903 the highest local request and state machine table for local 904 requests to obtain an intermediate state. This intermediate state 905 is the final state in case of clearance of SF-P otherwise, 906 starting at this intermediate state, the last received far end 907 request and the state machine table for far end requests are used 908 to calculate the final state. 910 o If the highest local request is neither Clear, nor clearance of SF 911 or of SD, nor expiration of WTR, the APS process logic compares 912 the highest local request with the request of the last received 913 "Request/State" information based on Figure 6. 915 1. If the highest local request has higher or equal priority, it 916 is used with the state transition table for local requests 917 defined in Section 9 to determine the final state; otherwise 919 2. The request of the last received "Request/State" information 920 is used with the state transition table for far end requests 921 defined in Section 9 to determine the final state. 923 The "APS message generator" generates APS specific information with 924 the signaled APS information for the final state from the state 925 transition calculation (with coding as described in Figure 5). 927 8.2. Equal priority requests 929 In general, once a switch has been completed due to a request, it 930 will not be overridden by another request of the same priority 931 (first-come, first-served policy). Equal priority requests from both 932 sides of a bidirectional protection group are both considered valid, 933 as follows: 935 o If the local state is NR, with the requested signal number 1, and 936 the far-end state is NR, with the requested signal number 0, the 937 local state transits to NR with the requested signal number 0. 938 This applies to the case when the remote request for switching to 939 the protection transport entity has been cleared. 941 o If both the local and far-end states are NR, with the requested 942 signal number 1, the local state transits to the appropriate new 943 state (DNR state for non-revertive mode and WTR state for 944 revertive mode). This applies to the case when the old request 945 has been cleared at both ends. 947 o If both the local and far-end states are RR, with the same 948 requested signal number, both ends transit to the appropriate new 949 state according to the requested signal number. This applies to 950 the case of concurrent deactivation of EXER from both ends. 952 o In other cases, no state transition occurs, even if equal priority 953 requests are activated from both ends. Note that if MSs are 954 issued simultaneously to both working and protection transport 955 entities, either as local or far-end requests, the MS to the 956 working transport entity is considered as having higher priority 957 than the MS to the protection transport entity. 959 8.3. Signal degrade of the protection transport entity 961 Signal degrade on protection transport entity has the same priority 962 as signal degrade on working transport entity. As a result, if an SD 963 condition affects both transport entities, the first SD detected MUST 964 NOT overridden by the second SD detected. If the SD is detected 965 simultaneously, either as local or far-end requests on both working 966 and protection transport entities, then the SD on the standby 967 transport entity MUST be considered as having higher priority than 968 the SD on the active transport entity, and the normal traffic signal 969 continues to be selected from the active transport entity (i.e., no 970 unnecessary protection switching is performed). 972 In the preceding sentence, "simultaneously" relates to the occurrence 973 of SD on both the active and standby transport entities at input to 974 the protection switching process at the same time, or as long as a SD 975 request has not been acknowledged by the remote end in bidirectional 976 protection switching. 978 9. Protection switching state transition table 980 In this section, state transition tables for the following protection 981 switching configurations are described. 983 o 1:1 bidirectional (revertive mode, non-revertive mode); 985 o 1+1 bidirectional (revertive mode, non-revertive mode); 987 o 1+1 unidirectional (revertive mode, non-revertive mode). 989 Note that any other global or local request which is not described in 990 state transition tables does not trigger any state transition. 992 The states specified in the state transition tables can be described 993 as follows: 995 o NR: NR is the state entered by the local priority under all 996 conditions where no local protection switching requests (including 997 WTR and DNR) are active. NR can also indicates that the highest 998 local request is overridden by the far end request, whose priority 999 is higher than the highest local request. Normal traffic signal 1000 is selected from the corresponding transport entity. 1002 o LO, SF-P, SD-P: The access by the normal traffic to the protection 1003 transport entity is NOT allowed in this state. The normal traffic 1004 is carried by the working transport entity, regardless of the 1005 fault/degrade condition possibly present (due to the highest 1006 priority of the switching triggers leading to this state). 1008 o FS, SF-W, SD-W, MS-W, MS-P: A switching trigger, NOT resulting in 1009 the protection transport entity unavailability is present. The 1010 normal traffic is selected either from the corresponding working 1011 transport entity or from the protection transport entity, 1012 according to the behavior of the specific switching trigger. 1014 o WTR: In revertive operation, after the clearing of an SF-W or 1015 SD-W, maintains normal traffic as selected from the protection 1016 transport entity until the WTR timer expires or another request 1017 with higher priority, including Clear command, is received. This 1018 is used to prevent frequent operation of the selector in the case 1019 of intermittent failures. 1021 o DNR: In non-revertive operation, this is used to maintain a normal 1022 traffic to be selected from the protection transport entity. 1024 o EXER: Exercise of the APS protocol. 1026 o RR: The near end will enter and signal Reverse Request only in 1027 response to an EXER from the far end. 1029 [State transition tables are shown at the end of the PDF form of this 1030 document.] 1032 10. Security considerations 1034 MPLS-TP is a subset of MPLS and so builds upon many of the aspects of 1035 the security model of MPLS. MPLS networks make the assumption that 1036 it is very hard to inject traffic into a network and equally hard to 1037 cause traffic to be directed outside the network. The control-plane 1038 protocols utilize hop-by-hop security and assume a "chain-of-trust" 1039 model such that end-to-end control-plane security is not used. For 1040 more information on the generic aspects of MPLS security, see RFC 1041 5920 [RFC5920]. 1043 This document describes a protocol carried in the G-ACh [RFC5586], 1044 and so is dependent on the security of the G-ACh, itself. The G-ACh 1045 is a generalization of the Associated Channel defined in [RFC4385]. 1046 Thus, this document relies heavily on the security mechanisms 1047 provided for the Associated Channel and described in those two 1048 documents. 1050 11. IANA considerations 1052 There are no IANA actions requested. 1054 12. Acknowledgements 1056 The authors would like to thank Hao Long, Vincenzo Sestito, Italo 1057 Busi, Igor Umansky, and Andy Malis for their input to and review of 1058 the current document. 1060 13. References 1062 13.1. Normative References 1064 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1065 Requirement Levels", BCP 14, RFC 2119, March 1997. 1067 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1068 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1069 Use over an MPLS PSN", RFC 4385, February 2006. 1071 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1072 Associated Channel", RFC 5586, June 2009. 1074 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1075 Networks", RFC 5920, July 2010. 1077 [T1.105.01] 1078 American National Standards Institute, "Synchronous 1079 Optical Network (SONET) - Automatic Protection Switching", 1080 ANSI 0900105.01:2000 (R2010), 2000. 1082 [G.841] International Telecommunications Union, "Types and 1083 characteristics of SDH network protection architectures", 1084 ITU-T Recommendation G.841, October 1998. 1086 [G.873.1] International Telecommunications Union, "Optical Transport 1087 Network (OTN): Linear protection", ITU-T Recommendation 1088 G.873.1, July 2011. 1090 [G.8031] International Telecommunications Union, "Ethernet Linear 1091 Protection Switching", ITU-T Recommendation G.8031/Y.1342, 1092 June 2011. 1094 13.2. Informative References 1096 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1097 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1098 Protection", RFC 6378, October 2011. 1100 [I-D.ietf-mpls-psc-updates] 1101 Osborne, E., "Updates to PSC", draft-ietf-mpls-psc- 1102 updates-01 (work in progress), January 2014. 1104 [I-D.ietf-mpls-tp-psc-itu] 1105 Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., 1106 Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS- 1107 TP) Linear Protection to Match the Operational 1108 Expectations of SDH, OTN and Ethernet Transport Network 1109 Operators", draft-ietf-mpls-tp-psc-itu-02 (work in 1110 progress), February 2014. 1112 Appendix A. Operation examples of APS protocol 1114 The sequence diagrams shown in this section are only a few examples 1115 of the APS operations. The first APS message which differs from the 1116 previous APS message is shown. The operation of hold-off timer is 1117 omitted. The fields whose values are changed during APS packet 1118 exchange are shown in the APS packet exchange. They are Request/ 1119 State, requested traffic, and bridged traffic. For an example, 1120 SF(0,1) represents an APS packet with the following field values: 1121 Request/State = SF, Requested Signal = 0, and Bridged Signal = 1. 1122 The values of the other fields remain unchanged from the initial 1123 configuration. The signal numbers 0 and 1 refer to null signal and 1124 normal traffic signal, respectively. W(A->Z) and P(A->Z) indicate 1125 the working and protection paths in the direction of A to Z, 1126 respectively. 1128 Example 1. 1:1 bidirectional protection switching (revertive mode) - 1129 Unidirectional SF case 1130 A Z 1131 | | 1132 (1) |---- NR(0,0)----->| 1133 |<----- NR(0,0)----| 1134 | | 1135 | | 1136 (2) | (SF on W(Z->A)) | 1137 |---- SF(1,1)----->| (3) 1138 |<----- NR(1,1)----| 1139 (4) | | 1140 | | 1141 (5) | (Recovery) | 1142 |---- WTR(1,1)---->| 1143 /| | 1144 WTR timer | | 1145 \| | 1146 (6) |---- NR(0,0)----->| (7) 1147 (8) |<----- NR(0,0)----| 1148 | | 1150 (1) The protected domain is operating without any defect, and the 1151 working entity is used for delivering the normal traffic. 1153 (2) Signal Fail occurs on the working entity in the Z to A direction. 1154 Selector and bridge of node A select protection entity. Node A 1155 generates SF(1,1) message. 1157 (3) Upon receiving SF(1,1), node Z sets selector and bridge to 1158 protection entity. As there is no local request in node Z, node Z 1159 generates NR(1,1) message. 1161 (4) Node A confirms that the far end is also selecting protection 1162 entity. 1164 (5) Node A detects clearing of SF condition, starts the WTR timer, 1165 and sends WTR(1,1) message. 1167 (6) At expiration of the WTR timer, node A sets selector and bridge 1168 to working entity and sends NR(0,0) message. 1170 (7) Node Z is notified that the far end request has been cleared, and 1171 sets selector and bridge to working entity. 1173 (8) It is confirmed that the far end is also selecting working 1174 entity. 1176 Example 2. 1:1 bidirectional protection switching (revertive mode) - 1177 Bidirectional SF case 1178 A Z 1179 | | 1180 (1) |---- NR(0,0)----->| (1) 1181 |<----- NR(0,0)----| 1182 | | 1183 | | 1184 (2) | (SF on W(Z<->A)) | (2) 1185 |<---- SF(1,1)---->| 1186 (3) | | (3) 1187 | | 1188 (4) | (Recovery) | (4) 1189 |<---- NR(1,1)---->| 1190 (5) |<--- WTR(1,1)---->| (5) 1191 /| |\ 1192 WTR timer | | WTR timer 1193 \| |/ 1194 (6) |<---- NR(1,1)---->| (6) 1195 (7) |<----- NR(0,0)--->| (7) 1196 (8) | | (8) 1198 (1) The protected domain is operating without any defect, and the 1199 working entity is used for delivering the normal traffic. 1201 (2) Nodes A and Z detect local Signal Fail conditions on the working 1202 entity, set selector and bridge to protection entity, and generate 1203 SF(1,1) messages. 1205 (3) Upon receiving SF(1,1), each node confirms that the far end is 1206 also selecting protection entity. 1208 (4) Each node detects clearing of SF condition, and sends NR(1,1) 1209 message as the last received APS message was SF. 1211 (5) Upon receiving NR(1,1), each node starts the WTR timer and sends 1212 WTR(1,1). 1214 (6) At expiration of the WTR timer, each node sends NR(1,1) as the 1215 last received APS message was WTR. 1217 (7) Upon receiving NR(1,1), each node sets selector and bridge to 1218 working entity and sends NR(0,0) message. 1220 (8) It is confirmed that the far end is also selecting working 1221 entity. 1223 Example 3. 1:1 bidirectional protection switching (revertive mode) - 1224 Bidirectional SF case - Inconsistent WTR timers 1225 A Z 1226 | | 1227 (1) |---- NR(0,0)----->| (1) 1228 |<----- NR(0,0)----| 1229 | | 1230 | | 1231 (2) | (SF on W(Z<->A)) | (2) 1232 |<---- SF(1,1)---->| 1233 (3) | | (3) 1234 | | 1235 (4) | (Recovery) | (4) 1236 |<---- NR(1,1)---->| 1237 (5) |<--- WTR(1,1)---->| (5) 1238 /| |\ 1239 WTR timer | | | 1240 \| | WTR timer 1241 (6) |----- NR(1,1)---->| | (7) 1242 | |/ 1243 (9) |<----- NR(0,0)----| (8) 1244 |---- NR(0,0)----->| (10) 1246 (1) The protected domain is operating without any defect, and the 1247 working entity is used for delivering the normal traffic. 1249 (2) Nodes A and Z detect local Signal Fail conditions on the working 1250 entity , set selector and bridge to protection entity, and generate 1251 SF(1,1) messages. 1253 (3) Upon receiving SF(1,1), each node confirms that the far end is 1254 also selecting protection entity. 1256 (4) Each node detects clearing of SF condition, and sends NR(1,1) 1257 message as the last received APS message was SF. 1259 (5) Upon receiving NR(1,1), each node starts the WTR timer and sends 1260 WTR(1,1). 1262 (6) At expiration of the WTR timer in node A, node A sends NR(1,1) as 1263 the last received APS message was WTR. 1265 (7) At node Z, the received NR(1,1) is ignored as the local WTR has a 1266 higher priority. 1268 (8) At expiration of the WTR timer in node Z, node Z node sets 1269 selector and bridge to working entity, and sends NR(0,0) message. 1271 (9) Upon receiving NR(0,0), node A sets selector and bridge to 1272 working entity and sends NR(0,0) message. 1274 (10) It is confirmed that the far end is also selecting working 1275 entity. 1277 Example 4. 1:1 bidirectional protection switching (non-revertive 1278 mode) - Unidirectional SF on working followed by unidirectional SF on 1279 protection 1281 A Z 1282 | | 1283 (1) |---- NR(0,0)----->| (1) 1284 |<----- NR(0,0)----| 1285 | | 1286 | | 1287 (2) | (SF on W(Z->A)) | 1288 |----- SF(1,1)---->| (3) 1289 (4) |<----- NR(1,1)----| 1290 | | 1291 | | 1292 (5) | (Recovery) | 1293 |----- DNR(1,1)--->| (6) 1294 |<--- DNR(1,1)---->| 1295 | | 1296 | | 1297 | (SF on P(A->Z)) | (7) 1298 (8) |<--- SF-P(0,0)----| 1299 |---- NR(0,0)----->| 1300 | | 1301 | | 1302 | (Recovery) | (9) 1303 |<----- NR(0,0)----| 1304 | | 1306 (1) The protected domain is operating without any defect, and the 1307 working entity is used for delivering the normal traffic. 1309 (2) Signal Fail occurs on the working entity in the Z to A direction. 1310 Selector and bridge of node A select the protection entity. Node A 1311 generates SF(1,1) message. 1313 (3) Upon receiving SF(1,1), node Z sets selector and bridge to 1314 protection entity. As there is no local request in node Z, node Z 1315 generates NR(1,1) message. 1317 (4) Node A confirms that the far end is also selecting protection 1318 entity. 1320 (5) Node A detects clearing of SF condition, and sends DNR(1,1) 1321 message. 1323 (6) Upon receiving DNR(1,1), node Z also generates DNR(1,1) message. 1325 (7) Signal Fail occurs on the protection entity in the A to Z 1326 direction. Selector and bridge of node Z select the working entity. 1327 Node Z generates SF-P(0,0) message. 1329 (8) Upon receiving SF-P(0,0), node A sets selector and bridge to 1330 working entity, and generates NR(0,0) message. 1332 (9) Node Z detects clearing of SF condition, and sends NR(0,0) 1333 message. 1335 Exmaple 5. 1:1 bidirectional protection switching (non-revertive 1336 mode) - Bidirectional SF on working followed by bidirectional SF on 1337 protection 1339 A Z 1340 | | 1341 (1) |---- NR(0,0)----->| (1) 1342 |<----- NR(0,0)----| 1343 | | 1344 | | 1345 (2) | (SF on W(A<->Z)) | (2) 1346 (3) |<---- SF(1,1)---->| (3) 1347 | | 1348 | | 1349 (4) | (Recovery) | (4) 1350 (5) |<---- NR(1,1)---->| (5) 1351 |<--- DNR(1,1)---->| 1352 | | 1353 | | 1354 (6) | (SF on P(A<->Z)) | (6) 1355 (7) |<--- SF-P(0,0)--->| (7) 1356 | | 1357 | | 1358 (8) | (Recovery) | (8) 1359 |<---- NR(0,0)---->| 1360 | | 1362 (1) The protected domain is operating without any defect, and the 1363 working entity is used for delivering the normal traffic. 1365 (2) Nodes A and Z detect local Signal Fail conditions on the working 1366 entity, set selector and bridge to protection entity, and generate 1367 SF(1,1) messages. 1369 (3) Upon receiving SF(1,1), each node confirms that the far end is 1370 also selecting protection entity. 1372 (4) Each node detects clearing of SF condition, and sends NR(1,1) 1373 message as the last received APS message was SF. 1375 (5) Upon receiving NR(1,1), each node sends DNR(1,1). 1377 (6) Signal Fail occurs on the protection entity in both directions. 1378 Selector and bridge of each node selects the working entity. Each 1379 node generates SF-P(0,0) message. 1381 (7) Upon receiving SF-P(0,0), each node confirms that the far end is 1382 also selecting working entity 1384 (8) Each node detects clearing of SF condition, and sends NR(0,0) 1385 message. 1387 Authors' Addresses 1389 Huub van Helvoort (editor) 1390 Huawei Technologies 1392 Email: huub.van.helvoort@huawei.com 1394 Jeong-dong Ryoo (editor) 1395 ETRI 1397 Email: ryoo@etri.re.kr 1399 Haiyan Zhang 1400 Huawei Technologies 1402 Email: zhanghaiyan@huawei.com 1404 Feng Huang 1405 Philips 1407 Email: feng.huang@philips.com 1409 Han Li 1410 China Mobile 1412 Email: lihan@chinamobile.com 1413 Alessandro D'Alessandro 1414 Telecom Italia 1416 Email: alessandro.dalessandro@telecomitalia.it