idnits 2.17.00 (12 Aug 2021) /tmp/idnits51529/draft-ietf-mpls-tp-psc-itu-04.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 28, 2014) is 2969 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group J. Ryoo, Ed. 3 Internet-Draft ETRI 4 Updates: 6378 (if approved) E. Gray, Ed. 5 Intended status: Standards Track Ericsson 6 Expires: September 29, 2014 H. van Helvoort 7 Huawei Technologies 8 A. D'Alessandro 9 Telecom Italia 10 T. Cheung 11 ETRI 12 E. Osborne 14 March 28, 2014 16 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the 17 Operational Expectations of SDH, OTN and Ethernet Transport Network 18 Operators 19 draft-ietf-mpls-tp-psc-itu-04.txt 21 Abstract 23 This document describes alternate mechanisms to perform some of the 24 functions of MPLS Transport Profile (MPLS-TP) linear protection 25 defined in RFC 6378, and also defines additional mechanisms. The 26 purpose of these alternate and additional mechanisms is to provide 27 operator control and experience that more closely models the behavior 28 of linear protection seen in other transport networks. 30 This document also introduces capabilities and modes for linear 31 protection. A capability is an individual behavior, and a mode is a 32 particular combination of capabilities. Two modes are defined in 33 this document: Protection State Coordination (PSC) mode and Automatic 34 Protection Switching (APS) mode. 36 This document describes the behavior of the PSC protocol including 37 priority logic and state machine when all the capabilities associated 38 with the APS mode are enabled. 40 This document updates RFC 6378 in that the capability advertisement 41 method defined here is an addition to that document. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 29, 2014. 60 Copyright Notice 62 Copyright (c) 2014 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 79 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Capability 1: Priority Modification . . . . . . . . . . . . . 6 81 4.1. Motivation for swapping priorities of FS and SF-P . . . . 6 82 4.2. Motivation for raising the priority of SFc . . . . . . . 7 83 4.3. Motivation for introducing Freeze command . . . . . . . . 7 84 4.4. Procedures in support of priority modification . . . . . 7 85 5. Capability 2: Non-revertive Behavior Modification . . . . . . 8 86 6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8 87 6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8 88 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9 89 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9 90 6.4. Equal priority resolution for MS . . . . . . . . . . . . 10 91 7. Capability 4: Support of Protection against SD . . . . . . . 10 92 7.1. Motivation for supporting protection against SD . . . . . 10 93 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10 94 7.3. Behavior of protection against SD . . . . . . . . . . . . 11 95 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12 97 8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13 98 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14 99 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 100 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15 101 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16 103 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16 104 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16 105 10.1. Request field in PSC protocol message . . . . . . . . . 16 106 10.2. Priorities of local inputs and remote requests . . . . . 17 107 10.2.1. Equal priority requests . . . . . . . . . . . . . . 18 108 10.3. Acceptance and retention of local inputs . . . . . . . . 19 109 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20 110 11.1. State transition by local inputs . . . . . . . . . . . . 22 111 11.2. State transition by remote messages . . . . . . . . . . 24 112 11.3. State transition for 1+1 unidirectional 113 protection . . . . . . . . . . . . . . . . . . . . . . . 26 114 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27 115 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 117 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28 118 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28 119 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28 120 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 121 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 122 16.1. Normative References . . . . . . . . . . . . . . . . . . 29 123 16.2. Informative References . . . . . . . . . . . . . . . . . 29 124 Appendix A. An Example of Out-of-service Scenarios . . . . . . . 30 125 Appendix B. An Example of Sequence Diagram Showing 126 the Problem with the Priority Level of SFc . . . . . 31 127 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33 128 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 131 1. Introduction 133 Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) 134 are described in RFC 6378 [RFC6378] to meet the requirements 135 described in RFC 5654 [RFC5654]. 137 This document describes alternate mechanisms to perform some of the 138 functions of linear protection, and also defines additional 139 mechanisms. The purpose of these alternate and additional mechanisms 140 is to provide operator control and experience that more closely 141 models the behavior of linear protection seen in other transport 142 networks, such as Synchronous Digital Hierarchy (SDH), Optical 143 Transport Network (OTN) and Ethernet transport networks. Linear 144 protection for SDH, OTN, and Ethernet transport networks are defined 145 in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031 146 [G8031], respectively. 148 The reader of this document is assumed to be familiar with [RFC6378]. 150 The alternative mechanisms described in this document are for the 151 following capabilities: 153 1. Priority modification, 155 2. non-revertive behavior modification, 157 and the following capabilities have been added to define additional 158 mechanisms: 160 3. support of Manual Switch to Working path (MS-W) command, 162 4. support of protection against Signal Degrade (SD), and 164 5. support of Exercise (EXER) command. 166 The priority modification includes raising the priority of Signal 167 Fail on Protection path (SF-P) relative to Forced Switch (FS), and 168 raising the priority level of Clear Signal Fail (SFc) above SF-P. 170 Non-revertive behavior is modified to align with the behavior defined 171 in RFC 4427 [RFC4427] as well as to follow the behavior of linear 172 protection seen in other transport networks. 174 Support of MS-W command to revert traffic to the working path in non- 175 revertive operation is covered in this document. 177 Support of protection switching protocol against SD is covered in 178 this document. The specifics for the method of identifying SD is out 179 of the scope for this document and is treated similarly to Signal 180 Fail (SF) in [RFC6378]. 182 Support of EXER command to test if the Protection State Coordination 183 (PSC) communication is operating correctly is also covered in this 184 document. EXER command tests and validates the linear protection 185 mechanism and PSC protocol including the aliveness of the priority 186 logic, the PSC state machine and the PSC message generation and 187 reception, and the integrity of the protection path, without 188 triggering the actual traffic switching. 190 This document introduces capabilities and modes. A capability is an 191 individual behavior. The capabilities of a node are advertised using 192 the method given in this document. A mode is a particular 193 combination of capabilities. Two modes are defined in this document: 194 PSC mode and Automatic Protection Switching (APS) mode. 196 Other modes may be defined as new combinations of the capabilities 197 defined in this document or through the definition of additional 198 capabilities. In either case, the specification defining a new mode 199 will be responsible for documenting the behavior, the priority logic, 200 and the state machine of the PSC protocol when the set of 201 capabilities in the new mode are enabled. 203 This document describes the behavior, the priority logic, and the 204 state machine of the PSC protocol when all the capabilities 205 associated with the APS mode are enabled. The PSC protocol behavior 206 for the PSC mode is as defined in [RFC6378]. 208 This document updates [RFC6378] by adding a capability advertisement 209 mechanism. It is recommended that existing implementations of the 210 PSC protocol be updated to support this capability. Backward 211 compatibility with existing implementations that do not support this 212 mechanism is described in Section 9.2.1. 214 Implementations are expected to be configured to support a specific 215 set of capabilities (a mode) and to reject messages that indicate the 216 use of a different set of capabilities (a different mode). Thus, the 217 capabilities advertisement is not a negotiation, but a verification 218 that peers are using the same mode. 220 2. Conventions Used in This Document 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [RFC2119]. 226 3. Acronyms 227 This document uses the following acronyms: 229 APS Automatic Protection Switching 230 DNR Do-not-Revert 231 EXER Exercise 232 FS Forced Switch 233 LO Lockout of protection 234 MS Manual Switch 235 MS-P Manual Switch to Protection path 236 MS-W Manual Switch to Working path 237 MPLS-TP MPLS Transport Profile 238 NR No Request 239 OC Operator Clear 240 OTN Optical Transport Network 241 PSC Protection State Coordination 242 RR Reverse Request 243 SD Signal Degrade 244 SDH Synchronous Digital Hierarchy 245 SD-P Signal Degrade on Protection path 246 SD-W Signal Degrade on Working path 247 SF Signal Fail 248 SFc Clear Signal Fail 249 SFDc Clear Signal Fail or Degrade 250 SF-P Signal Fail on Protection path 251 SF-W Signal Fail on Working path 252 WTR Wait-to-Restore 254 4. Capability 1: Priority Modification 256 [RFC6378] defines the priority of FS to be higher than that of SF-P. 257 That document also defines the priority of Clear SF (SFc) to be low. 258 This document defines the priority modification capability whereby 259 the relative priorities of FS and SF-P are swapped and the priority 260 of Clear SF (SFc) is raised. In addition, this capability introduces 261 the Freeze command as described in Appendix C. The rationale for 262 these changes is detailed in the following sub-sections from both the 263 technical and network operational aspects. 265 4.1. Motivation for swapping priorities of FS and SF-P 267 Defining the priority of FS higher than that of SF-P can result in a 268 situation where the protected traffic is taken out-of-service. When 269 the protection path fails PSC communication may stop as a result. In 270 this case, if any input that is supposed to be signaled to the other 271 end has a higher priority than SF-P then this can result in 272 unpredictable protection switching state. An example scenario that 273 may result in an out-of-service situation is presented in Appendix A 274 of this document. 276 According to Section 2.4 of [RFC5654] it MUST be possible to operate 277 an MPLS-TP network without using a control plane. This means that 278 the PSC communication channel is very important for the transfer of 279 external switching commands (e.g., FS), and these commands should not 280 rely on the presence of a control plane. In consequence, the failure 281 of the PSC communication channel has higher priority than FS. 283 In other transport networks (such as SDH, OTN, and Ethernet transport 284 networks) the priority of SF-P has been higher than that of FS. It 285 is therefore important to offer network operators the option of 286 having the same behavior in their MPLS-TP networks so that they can 287 have the same operational protection switching behavior to which they 288 have become accustomed. Typically, FS command is issued before 289 network maintenance jobs, (e.g., replacing optical cables or other 290 network components). When an operator pulls out a cable on the 291 protection path, by mistake, the traffic should continue to be 292 protected and the operator expects this behavior based on his/her 293 experience on the traditional transport network operations. 295 4.2. Motivation for raising the priority of SFc 297 The priority level of SFc defined in [RFC6378] can cause traffic 298 disruption when a node that has experienced local signal fails on 299 both the working and the protection paths is recovering from these 300 failures. 302 An example of sequence diagram highlighting the problem with the 303 priority level of SFc as defined in [RFC6378] is presented in 304 Appendix B. 306 4.3. Motivation for introducing Freeze command 308 With the priority swapping between FS and SF-P, the traffic is always 309 moved back to the working path when SF-P occurs in Protecting 310 Administrative state. In case network operators need an option to 311 control their networks so that the traffic can remain on the 312 protection path even when the PSC communication channel is broken, 313 the Freeze command can be used. Freeze is defined to be a "local" 314 command that is not signaled to the remote node. The use of the 315 Freeze command is described in Appendix C. 317 4.4. Procedures in support of priority modification 319 When the modified priority order specified in this document is in 320 use, the list of local requests in order of priority SHALL be as 321 follows: 323 (from highest to lowest) 325 o Clear Signal Fail 327 o Signal Fail on Protection path 329 o Forced Switch 331 o Signal Fail on Working path 333 This requires modification to the PSC Control Logic (including the 334 state machine) relative to that described in [RFC6378]. Sections 10 335 and 11 present the PSC Control Logic when all capabilities of APS 336 mode are enabled. 338 5. Capability 2: Non-revertive Behavior Modification 340 Non-revertive operation of protection switching is defined in 341 [RFC4427]. In this operation, the traffic does not return to the 342 working path when switch-over requests are terminated. 344 However, the PSC protocol defined in [RFC6378] supports this 345 operation only when recovering from a defect condition: it does not 346 support the non-revertive function when an operator's switch-over 347 command, such as FS or Manual Switch (MS), is cleared. To be aligned 348 with the behavior in other transport networks and to be consistent 349 with [RFC4427], a node should go into the Do-not-Revert (DNR) state 350 not only when a failure condition on the working path is cleared, but 351 also when an operator command that requested switch-over is cleared. 353 This requires modification to the PSC Control Logic (including the 354 state machine) relative to that described in [RFC6378]. Sections 10 355 and 11 present the PSC Control Logic when all capabilities of APS 356 mode are enabled. 358 6. Capability 3: Support of MS-W Command 360 6.1. Motivation for adding MS-W 362 Changing the non-revertive operation as described in Section 5 363 introduces necessity of a new operator command to revert traffic to 364 the working path in the DNR state. When the traffic is on the 365 protection path in the DNR state, a Manual Switch to Working (MS-W) 366 command is issued to switch the normal traffic back to the working 367 path. According to Section 4.3.3.6 (Do-not-Revert State) in 368 [RFC6378], "to revert back to the Normal state, the administrator 369 SHALL issue a Lockout of protection (LO) command followed by a Clear 370 command." However, using LO command introduces the potential risk of 371 an unprotected situation while the LO is in effect. 373 Manual Switch-over for recovery LSP/span command is defined in 374 [RFC4427]. Requirement 83 in [RFC5654] states that the external 375 commands defined in [RFC4427] MUST be supported. Since there is no 376 support for this external command in [RFC6378], this functionality 377 should be added to PSC. This support is provided by introducing the 378 MS-W command. The MS-W command, as described here, corresponds to 379 the "Manual Switch-over for recovery LSP/span" command. 381 6.2. Terminology to support MS-W 383 [RFC6378] uses the term "Manual Switch" and its acronym "MS". This 384 document uses the term "Manual Switch to Protection path" and "MS-P" 385 to have the same meaning, while avoiding confusion with "Manual 386 Switch to Working path" and its acronym "MS-W". 388 Similarly, we modify the name of "Protecting Administrative" state 389 (as defined in [RFC6378]) to be "Switching Administrative" state to 390 include the case where traffic is switched to the working path as a 391 result of the external MS-W command. 393 6.3. Behavior of MS-P and MS-W 395 MS-P and MS-W SHALL have the same priority. We consider different 396 instances of determining the priority of the commands when they are 397 received either in succession or simultaneously. 399 o When two commands are received in succession, the command that is 400 received after the initial command SHALL be cancelled. 402 o If two nodes simultaneously receive commands that indicate 403 opposite operations (i.e., one node receives MS-P and the other 404 node receives MS-W) and transmit the indications to the remote 405 node, the MS-W SHALL be considered to have a higher priority, and 406 the MS-P SHALL be cancelled and discarded. 408 Two commands, MS-P and MS-W are transmitted using the same Request 409 field value, but SHALL indicate in the Fault Path (FPath) value the 410 path that the traffic is being diverted from. When traffic is 411 switched to the protection path, the FPath field value SHALL be set 412 to 1, indicating that traffic is being diverted from the working 413 path. When traffic is switched to the working path, the FPath field 414 value SHALL be set to 0, indicating that traffic is being diverted 415 from the protection path. The Data Path (Path) field SHALL indicate 416 where user data traffic is being transported (i.e., if the working 417 path is selected, then Path is set to 0; if the protection path is 418 selected, then Path is set to 1). 420 When an MS command is in effect at a node, any subsequent MS or EXER 421 command and any other lower priority requests SHALL be ignored. 423 6.4. Equal priority resolution for MS 425 [RFC6378] defines only one rule for equal priority condition in 426 Section 4.3.2 as "The remote message from the remote LER is assigned 427 a priority just below the similar local input." In order to support 428 the manual switch behavior described in Section 6.3, additional rules 429 for equal priority resolution are required. Since the support of 430 protection against signal degrade also requires a similar equal 431 priority resolution, the rules are described in Section 7.4. 433 Support of this function requires changes to the PSC Control Logic 434 (including the state machine) relative to that shown in [RFC6378]. 435 Sections 10 and 11 present the PSC Control Logic when all 436 capabilities of APS mode are enabled. 438 7. Capability 4: Support of Protection against SD 440 7.1. Motivation for supporting protection against SD 442 In the MPLS-TP Survivability Framework [RFC6372], both SF and SD 443 fault conditions can be used to trigger protection switching. 445 [RFC6378], which defines the protection switching protocol for MPLS- 446 TP, does not specify how the SF and SD are detected, and specifies 447 the protection switching protocol associated with SF only. 449 The PSC protocol associated with SD is covered in this document, but 450 the specifics for the method of identifying SD is out of scope for 451 the protection protocol in the same way that SF detection and MS or 452 FS command initiation are out of scope. 454 7.2. Terminology to support SD 456 In this document the term Clear Signal Fail or Degrade (SFDc) is used 457 to indicate the clearance of either a degraded condition or a failure 458 condition. 460 The second paragraph of Section 4.3.3.2 Unavailable state in 461 [RFC6378] shows the intention of including Signal Degrade on 462 Protection path (SD-P) in the Unavailable state. Even though the 463 protection path can be partially available under the condition of 464 SD-P, this document follows the same state grouping as [RFC6378] for 465 SD-P. 467 The bullet item on the Protecting Failure state in Section 3.6 of 468 [RFC6378] includes the degraded condition in the Protecting Failure 469 state. This document follows the same state grouping as [RFC6378] 470 for Signal Degrade on Working path (SD-W). 472 7.3. Behavior of protection against SD 474 To better align the behavior of MPLS-TP networks with that of other 475 transport networks (such as SDH, OTN, and Ethernet transport 476 networks) we define the followings: 478 o The priorities of SD-P and SD-W SHALL be equal. 480 o Once a switch has been completed due to SD on one path, it will 481 not be overridden by SD on the other path (first come, first 482 served behavior), to avoid protection switching that cannot 483 improve signal quality. 485 The SD message indicates that the transmitting node has identified 486 degradation of the signal or integrity of the packet received on 487 either the working path or the protection path. The FPath field 488 SHALL identify the path that is reporting the degraded condition 489 (i.e., if the protection path, then FPath is set to 0; if the working 490 path, then FPath is set to 1), and the Path field SHALL indicate 491 where the data traffic is being transported (i.e., if the working 492 path is selected, then Path is set to 0; if the protection path is 493 selected, then Path is set to 1). 495 When the SD condition is cleared and the protected domain is 496 recovering from the situation, the Wait-to-Restore (WTR) timer SHALL 497 be used if the protected domain is configured for revertive behavior. 498 The WTR timer SHALL be started at the node that recovers from a local 499 degraded condition on the working path. 501 Protection switching against SD is always provided by a selector 502 bridge duplicating user data traffic and feeding it to both the 503 working path and the protection path under SD condition. When a 504 local or remote SD occurs on either the working path or the 505 protection path, the node SHALL duplicate user data traffic and SHALL 506 feed to both the working path and the protection path. The packet 507 duplication SHALL continue as long as any SD condition exists in the 508 protected domain. When the SD condition is cleared, in revertive 509 operation, the packet duplication SHALL continue in the WTR state and 510 SHALL stop when the node leaves the WTR state; while in non-revertive 511 operation, the packet duplication SHALL stop immediately. 513 The selector bridge with the packet duplication under SD condition, 514 which is a non-permanent bridge, is considered to be a 1:1 protection 515 architecture. 517 Protection switching against SD does not introduce any modification 518 to the operation of the selector at the sink node described in 519 [RFC6378]. The selector chooses either the working or protection 520 path from which to receive the normal traffic in both 1:1 and 1+1 521 architectures. The position of the selector, i.e., which path to 522 receive the traffic, is determined by the PSC protocol in 523 bidirectional switching or by the local input in unidirectional 524 switching. 526 7.4. Equal priority resolution 528 In order to support the MS behavior described in Section 6.3 and the 529 protection against SD described in Section 7.3, it is necessary to 530 expand rules for treating equal priority inputs. 532 For equal priority local inputs, such as MS and SD, apply a simple 533 first-come, first-served rule. Once a local input is determined as 534 the highest priority local input, then a subsequent equal priority 535 local input requesting a different action, i.e., the action results 536 in the same PSC Request field but different FPath value, will not be 537 presented to the PSC Control Logic as the highest local request. 538 Furthermore, in the case of MS command, the subsequent local MS 539 command requesting a different action will be cancelled. 541 If a node is in a remote state due to a remote SD (or MS) message, a 542 subsequent local input having the same priority but requesting a 543 different action to the PSC Control Logic, will be considered as 544 having lower priority than the remote message, and will be ignored. 545 For examples, if a node is in remote Switching Administrative state 546 due to a remote MS-P, then any subsequent local MS-W SHALL be ignored 547 and automatically cancelled. If a node is in remote Unavailable 548 state due to a remote SD-P, then any subsequent local SD-W input will 549 be ignored. However, the local SD-W SHALL continue to appear in the 550 Local Request Logic as long as the SD condition exists, but SHALL NOT 551 be the top priority global request, which determines the state 552 transition at the PSC Control Logic. 554 Cases where two end-points of the protected domain simultaneously 555 receive local triggers of the same priority that request different 556 actions (for example, one node receives SD-P and the other receives 557 SD-W) may occur. Subsequently, each node will receive a remote 558 message with the opposing action indication. To address these cases, 559 we define the following priority resolution rules: 561 o When MS-W and MS-P occur simultaneously at both nodes, MS-W SHALL 562 be considered as having higher priority than MS-P at both nodes. 564 o When SD-W and SD-P occur simultaneously at both nodes, the SD on 565 the standby path (the path from which the selector does not select 566 the user data traffic) is considered as having higher priority 567 than the SD on the active path (the path from which the selector 568 selects the user data traffic) regardless of its origin (local or 569 remote message). Therefore, no unnecessary protection switching 570 is performed and the user data traffic continues to be selected 571 from the active path. 573 In the preceding paragraphs, the "simultaneously" refers to the case 574 a sent SD (or MS) request has not been confirmed by the remote end in 575 bidirectional protection switching. When a local node that has 576 transmitted a SD message receives a SD (or MS) message that indicates 577 a different value of Path field from the value of Path field in the 578 transmitted SD (or MS) message, both the local and remote SD requests 579 are considered to occur simultaneously. 581 The addition of support for protection against SD requires 582 modification to the PSC Control Logic (including the state machine) 583 relative to that described in [RFC6378]. Sections 10 and 11 present 584 the PSC Control Logic when all capabilities of APS mode are enabled. 586 8. Capability 5: Support of EXER Command 588 The EXER command is used to verify the correct operation of the PSC 589 communication, such as the aliveness of the Local Request Logic, the 590 integrity of the PSC Control Logic, the PSC message generation and 591 reception mechanism, and the integrity of the protection path. EXER 592 does not trigger any actual traffic switching. 594 The command is only relevant for bidirectional protection switching, 595 since it is dependent upon receiving a response from the remote node. 596 The EXER command is assigned lower priority than any switching 597 message. It may be used regardless of the traffic usage of the 598 working path. 600 When a node receives a remote EXER message, it SHOULD respond with a 601 Reverse Request (RR) message with the FPath and Path fields set 602 according to the current condition of the node. The RR message SHALL 603 be generated only in response to a remote EXER message. 605 This command is documented in R84 of [RFC5654]. 607 If EXER commands are input at both ends, then a race condition may 608 arise. This is resolved as follows: 610 o If a node has issued EXER and receives EXER before receiving RR, 611 it MUST treat the received EXER as it would an RR, and SHOULD NOT 612 respond with RR. 614 The following PSC Requests are added to the PSC Request field to 615 support the Exercise command (see also Section 14.1): 617 (3) Exercise - indicates that the transmitting end point is 618 exercising the protection channel and mechanism. FPath and Path 619 are set to the same value of the No Request (NR), RR or DNR 620 message whose transmission is stopped by EXER. 622 (2) Reverse Request - indicates that the transmitting end point is 623 responding to an EXER command from the remote node. FPath and 624 Path are set to the same value of the NR or DNR message whose 625 transmission is stopped by RR. 627 The relative priorities of EXER and RR are defined in Section 10.2. 629 9. Capabilities and Modes 631 9.1. Capabilities 633 A Capability is an individual behavior whose use is signaled in a 634 Capabilities TLV, which is placed in Optional TLVs field inside the 635 PSC message shown in Figure 2 of [RFC6378]. The format of the 636 Capabilities TLV is: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type = Capabilities | Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Value = Flags | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Figure 1: Format of Capabilities TLV 648 The value of the Type field is TBD pending IANA allocation. 650 The value of the Length field is the length of the Flags field in 651 octets. The length of the Flags field MUST be a multiple of 4 octets 652 and MUST be the minimum required to signal all the required 653 capabilities. 655 Section 4 to Section 8 discuss five capabilities that are signaled 656 using the five most significant bits; if a node wishes to signal 657 these five capabilities, it MUST send a Flags field of 4 octets. A 658 node would send a Flags field greater than 4 octets only if it had 659 more than 32 Capabilities to indicate. All unused bits MUST be set 660 to zero. 662 If the bit assigned for an individual capability is set to 1, it 663 indicates the sending node's intent to use that capability in the 664 protected domain. If a bit is set to 0, the sending node does not 665 intend to use the indicated capability in the protected domain. Note 666 that it is not possible to distinguish between the intent not to use 667 a capability and a node's complete non-support (i.e., lack of 668 implementation) of a given capability. 670 This document defines five specific capabilities that are described 671 in Section 4 to Section 8. Each capability is assigned bit as 672 follows: 674 0x80000000: priority modification 676 0x40000000: non-revertive behavior modification 678 0x20000000: support of MS-W command 680 0x10000000: support of protection against SD 682 0x08000000: support of EXER command 684 If all the five capabilities should be used, a node SHALL set the 685 Flags field to 0xF8000000. 687 9.1.1. Sending and receiving the Capabilities TLV 689 A node MUST include its Capabilities TLV in every PSC message that it 690 transmits. The transmission and acceptance of the PSC message is 691 described in Section 4.1 of [RFC6378]. 693 When a node receives a Capabilities TLV it MUST compare the Flags 694 value to its most recent Flags value transmitted by the node. If the 695 two are equal, the protected domain is said to be running in the mode 696 indicated by that set of capabilities (see Section 9.2). If the sent 697 and received Capabilities TLVs are not equal, this indicates a 698 capabilities TLV mismatch. When this happens, the node MUST alert 699 the operator and MUST NOT perform any protection switching until the 700 operator resolves the mismatch between the two end-points. 702 9.2. Modes 704 A mode is a given set of Capabilities. Modes are shorthand; 705 referring to a set of capabilities by their individual values or by 706 the name of their mode does not change the protocol behavior. This 707 document defines two modes - PSC and APS. Capability TLVs with other 708 combinations than the one specified by a mode are not supported in 709 this specification. 711 9.2.1. PSC mode 713 PSC mode is defined as the lack of support for any of the additional 714 capabilities defined in this document - that is, a Capabilities set 715 of 0x0. It is the behavior specified in [RFC6378]. 717 There are two ways to declare PSC mode. A node can send no 718 Capabilities TLV at all since there are no TLV units defined in 719 [RFC6378], or it can send a Capabilities TLV with Flags value set to 720 0x0. In order to allow backward compatibility between two end-points 721 - one which supports sending the Capabilities TLV, and one which does 722 not, the node that has the ability to send and process the PSC mode 723 Capabilities TLV MUST be able to both send the PSC mode Capabilities 724 TLV and send no Capabilities TLV at all. An implementation MUST be 725 configurable between these two options. 727 9.2.2. APS mode 729 APS mode is defined as the use of all the five specific capabilities, 730 which are described in Section 4 to Section 8 in this document. APS 731 mode is indicated with the Flags value of 0xF8000000. 733 10. PSC Protocol in APS Mode 735 This section and the following section define the behavior of PSC 736 protocol when all of the aforementioned capabilities are enabled, 737 i.e., APS mode. 739 10.1. Request field in PSC protocol message 741 This document defines two new values for the "Request" field in the 742 PSC protocol message that is shown in Figure 2 of [RFC6378] as 743 follows: 745 (3) Exercise 747 (2) Reverse Request 749 See also Section 14.1 of this document. 751 10.2. Priorities of local inputs and remote requests 753 Based on the description in Sections 3 and 4.3.2 in [RFC6378], the 754 priorities of multiple outstanding local inputs are evaluated in the 755 Local Request Logic, where the highest priority local input (highest 756 local request) is determined. This highest local request is passed 757 to the PSC Control Logic, that will determine the higher priority 758 input (top priority global request) between the highest local request 759 and the last received remote message. When a remote message comes to 760 the PSC Control Logic, the top priority global request is determined 761 between this remote message and the highest local request which is 762 present. The top priority global request is used to determine the 763 state transition, which is described in Section 11. In this 764 document, in order to simplify the description on the PSC Control 765 Logic, we strictly decouple the priority evaluation from the state 766 transition table lookup. 768 The priorities for both local and remote requests are defined as 769 follows from highest to lowest: 771 o Operator Clear (Local only) 773 o Lockout of protection (Local and Remote) 775 o Clear Signal Fail or Degrade (Local only) 777 o Signal Fail on Protection path (Local and Remote) 779 o Forced Switch (Local and Remote) 781 o Signal Fail on Working path (Local and Remote) 783 o Signal Degrade on either Protection path or Working path (Local 784 and Remote) 786 o Manual Switch to either Protection path or Working path (Local and 787 Remote) 789 o WTR Timer Expiry (Local only) 791 o WTR (Remote only) 793 o Exercise (Local and Remote) 795 o Reverse Request (Remote only) 797 o Do-Not-Revert (Remote only) 798 o No Request (Remote and Local) 800 Note that the "Local only" requests are not tranmitted to the remote 801 node. Likewise, the "Remote only" requests do not exist in the Local 802 Request Logic as local inputs. For example, the priority of WTR only 803 applies to the received WTR message, which is generated from the 804 remote node. The remote node that is running the WTR timer in the 805 WTR state has no local request. 807 The remote SF and SD on either the working path or the protection 808 path and the remote MS to either the working path or the protection 809 path are indicated by the values of the Request and FPath fields in 810 the PSC message. 812 The remote request from the remote node is assigned a priority just 813 below the same local request except NR and equal priority requests, 814 such as SD and MS. Since a received NR message needs to be used in 815 the state transition table lookup when there is no outstanding local 816 request, the remote NR request SHALL have a higher priority than the 817 local NR. For the equal priority requests, see Section 10.2.1. 819 10.2.1. Equal priority requests 821 As stated in Section 10.2, the remote request from the remote node is 822 assigned a priority just below the same local request. However, for 823 equal priority requests, such as SD and MS, the priority SHALL be 824 evaluated as described in this section. 826 For equal priority local requests, first-come, first-served rule 827 SHALL be applied. Once a local request appears in the Local Request 828 Logic, a subsequent equal priority local request requesting a 829 different action, i.e., the action results in the same Request value 830 but a different FPath value, SHALL be considered to have a lower 831 priority. Furthermore, in the case of MS command, the subsequent 832 local MS command requesting a different action SHALL be rejected and 833 cleared. 835 When the priority is evaluated in the PSC Control Logic between the 836 highest local request and a remote request, the following equal 837 priority resolution rules SHALL be applied: 839 o If two requests request the same action, i.e., the same Request 840 and FPath values, then the local request SHALL be considered to 841 have a higher priority than the remote request. 843 o When the highest local request comes to the PSC Control Logic, if 844 the remote request that requests a different action exists, then 845 the highest local request SHALL be ignored and the remote request 846 SHALL remain to be the top priority global request. In the case 847 of MS command, the local MS command requesting a different action 848 SHALL be cancelled. 850 o When the remote request comes to the PSC Control Logic, if the 851 highest local request that requests a different action exists, 852 then the top priority global request SHALL be determined by the 853 following rules: 855 * For MS requests, the MS-W request SHALL be considered to have a 856 higher priority than the MS-P request. The node that has local 857 MS-W request SHALL maintain the local MS-W request as the top 858 priority global request. The other node that has local MS-P 859 request SHALL cancel the MS-P command and SHALL generate 860 "Operator Clear" internally as the top priority global request. 862 * For SD requests, the SD on the standby path (the path from 863 which the selector does not select the user data traffic) SHALL 864 be considered to have a higher priority than the SD on the 865 active path (the path from which the selector selects the user 866 data traffic) regardless of its origin (local or remote 867 message). The node that has the SD on the standby path SHALL 868 maintain the local SD on the standby path request as the top 869 priority global request. The other node that has local SD on 870 the active path SHALL use the remote SD on the standby path as 871 the top priority global request to lookup the state transition 872 table. The differentiation of the active and standby paths is 873 based upon which path had been selected for the user data 874 traffic "when each node detected its local SD". 876 10.3. Acceptance and retention of local inputs 878 A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W, 879 SHALL be accepted and retained persistently in the Local Request 880 Logic as long as the defect condition exists. If there is any higher 881 priority local input than the local defect input, the higher priority 882 local input is passed to the PSC Control Logic as the highest local 883 request, but the local defect input cannot be removed but remains in 884 the Local Request Logic. When the higher priority local input is 885 cleared, the local defect will become the highest local request if 886 the defect condition still exists. 888 Operator Clear (OC) command, SFDc and WTR Timer Expiry are not 889 persistent. Once they appear to the Local Request Logic and complete 890 all the operations in the protection switching control, they SHALL 891 disappear. 893 LO, FS, MS, and EXER commands SHALL be rejected if there is any 894 higher priority local input in the Local Request Logic. If a new 895 higher-priority local request (including an operator command) is 896 accepted, any previous lower-priority local operator command SHALL be 897 cancelled. When any higher-priority remote request is received, a 898 lower-priority local operator command SHALL be cancelled. The 899 cancelled operator command is cleared. If the operators wish to 900 renew the cancelled command then they should reissue the command. 902 11. State Transition Tables in APS Mode 904 When there is a change in the highest local request or in remote PSC 905 messages, the top priority global request SHALL be evaluated and the 906 state transition tables SHALL be looked up in the PSC Control Logic. 907 The following rules are applied to the operation related to the state 908 transition table lookup. 910 o If the top priority global request, which determines the state 911 transition, is the highest local request, the local state 912 transition table in Section 11.1 SHALL be used to decide the next 913 state of the node. Otherwise, the remote state transition table 914 in Section 11.2 SHALL be used. 916 o If in remote state, the highest local defect condition (SF-P, 917 SF-W, SD-P or SD-W) SHALL always be reflected in the Request and 918 Fpath fields. 920 o For the node currently in the local state, if the top priority 921 global request is changed to OC or SFDc causing the next state to 922 be Normal, WTR or DNR, then all the local and remote requests 923 SHALL be re-evaluated as if the node is in the state specified in 924 the footnotes to the state transition tables, before deciding the 925 final state. If there are no active requests, the node enters the 926 state specified in the footnotes to the state transition tables. 927 This re-evaluation is an internal operation confined within the 928 local node, and the PSC messages are generated according to the 929 final state. 931 o The WTR timer is started only when the node which has recovered 932 from a local failure or degradation enters the WTR state. A node 933 which is entering into the WTR state due to a remote WTR message 934 does not start the WTR timer. The WTR timer SHALL be stopped when 935 any local or remote request triggers the state change out of the 936 WTR state. 938 The extended states, as they appear in the table, are as follows: 940 N Normal state 941 UA:LO:L Unavailable state due to local LO command 942 UA:P:L Unavailable state due to local SF-P 943 UA:DP:L Unavailable state due to local SD-P 944 UA:LO:R Unavailable state due to remote LO message 945 UA:P:R Unavailable state due to remote SF-P message 946 UA:DP:R Unavailable state due to remote SD-P message 947 PF:W:L Protecting Failure state due to local SF-W 948 PF:DW:L Protecting Failure state due to local SD-W 949 PF:W:R Protecting Failure state due to remote SF-W message 950 PF:DW:R Protecting Failure state due to remote SD-W message 951 SA:F:L Switching Administrative state due to local FS command 952 SA:MW:L Switching Administrative state due to local MS-W command 953 SA:MP:L Switching Administrative state due to local MS-P command 954 SA:F:R Switching Administrative state due to remote FS message 955 SA:MW:R Switching Administrative state due to remote MS-W message 956 SA:MP:R Switching Administrative state due to remote MS-P message 957 WTR Wait-to-Restore state 958 DNR Do-not-Revert state 959 E::L Exercise state due to local EXER command 960 E::R Exercise state due to remote EXER message 962 Each state corresponds to the transmission of a particular set of 963 Request, FPath and Path fields. The table below lists the message 964 that is generally sent in each particular state. If the message to 965 be sent in a particular state deviates from the table below, it is 966 noted in the footnotes to the state transition tables. 968 State Request(FPath,Path) 969 ------- ------------------------------------ 970 N NR(0,0) 971 UA:LO:L LO(0,0) 972 UA:P:L SF(0,0) 973 UA:DP:L SD(0,0) 974 UA:LO:R highest local request(local FPath,0) 975 UA:P:R highest local request(local FPath,0) 976 UA:DP:R highest local request(local FPath,0) 977 PF:W:L SF(1,1) 978 PF:DW:L SD(1,1) 979 PF:W:R highest local request(local FPath,1) 980 PF:DW:R highest local request(local FPath,1) 981 SA:F:L FS(1,1) 982 SA:MW:L MS(0,0) 983 SA:MP:L MS(1,1) 984 SA:F:R highest local request(local FPath,1) 985 SA:MW:R NR(0,0) 986 SA:MP:R NR(0,1) 987 WTR WTR(0,1) 988 DNR DNR(0,1) 989 E::L EXER(0,x), where x is the existing Path value 990 when Exercise command is issued. 991 E::R RR(0,x), where x is the existing Path value 992 when RR message is generated. 994 Some operation examples of APS mode are shown in Appendix D. 996 In the state transition tables below, the letter 'i' stands for 997 "ignore", and is an indication to remain in the current state and 998 continue transmitting the current PSC message 1000 11.1. State transition by local inputs 1001 | OC | LO | SFDc | SF-P | FS | SF-W | 1002 --------+-----+---------+------+--------+--------+--------+ 1003 N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1004 UA:LO:L | (1) | i | i | i | i | i | 1005 UA:P:L | i | UA:LO:L | (1) | i | i | i | 1006 UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L | 1007 UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 1008 UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | 1009 UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1010 PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i | 1011 PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L | 1012 PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1013 PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1014 SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i | 1015 SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1016 SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1017 SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1018 SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1019 SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1020 WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1021 DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1022 E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1023 E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | 1025 | SD-P | SD-W | MS-W | MS-P | WTRExp | EXER 1026 --------+---------+---------+---------+---------+--------+------ 1027 N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1028 UA:LO:L | i | i | i | i | i | i 1029 UA:P:L | i | i | i | i | i | i 1030 UA:DP:L | i | i | i | i | i | i 1031 UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i 1032 UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i 1033 UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i 1034 PF:W:L | i | i | i | i | i | i 1035 PF:DW:L | i | i | i | i | i | i 1036 PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i 1037 PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i 1038 SA:F:L | i | i | i | i | i | i 1039 SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i 1040 SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i 1041 SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i 1042 SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i 1043 SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i 1044 WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i 1045 DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1046 E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i 1047 E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L 1048 NOTES: 1050 (1) Re-evaluate to determine final state as if the node is in the 1051 Normal state. If there are no active requests, the node enters 1052 the Normal State. 1054 (2) In the case that both local input after SFDc and the last 1055 received remote message are no requests, the node enters into 1056 the WTR state when the domain is configured for revertive 1057 behavior, or the node enters into the DNR state when the domain 1058 is configured for non-revertive behavior. In all the other 1059 cases, where one or more active requests exist, re-evaluate to 1060 determine the final state as if the node is in the Normal state. 1062 (3) Re-evaluate to determine final state as if the node is in the 1063 Normal state when the domain is configured for revertive 1064 behavior, or as if the node is in the DNR state when the domain 1065 is configured for non-revertive behavior. If there are no 1066 active requests, the node enters either the Normal state when 1067 the domain is configured for revertive behavior or the DNR state 1068 when the domain is configured for non-revertive behavior. 1070 (4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if 1071 it is running. In APS mode, OC can cancel the WTR timer and 1072 hasten the state transition to the Normal state as in other 1073 transport networks. 1075 (5) If Path value is 0, re-evaluate to determine final state as if 1076 the node is in the Normal state. If Path value is 1, re- 1077 evaluate to determine final state as if the node is in the DNR 1078 state. If there are no active requests, the node enters the 1079 Normal state when Path value is 0, or the DNR state when Path 1080 value is 1. 1082 (6) Remain in the WTR state and send NR(0,1). 1084 11.2. State transition by remote messages 1085 | LO | SF-P | FS | SF-W | SD-P | SD-W | 1086 --------+---------+--------+--------+--------+---------+---------+ 1087 N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1088 UA:LO:L | i | i | i | i | i | i | 1089 UA:P:L | UA:LO:R | i | i | i | i | i | 1090 UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) | 1091 UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1092 UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1093 UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R | 1094 PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i | 1095 PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i | 1096 PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R | 1097 PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i | 1098 SA:F:L | UA:LO:R | UA:P:R | i | i | i | i | 1099 SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1100 SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1101 SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R | 1102 SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1103 SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1104 WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1105 DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1106 E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1107 E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | 1109 | MS-W | MS-P | WTR | EXER | RR | DNR | NR 1110 --------+---------+---------+-----+------+----+------+---- 1111 N | SA:MW:R | SA:MP:R | i | E::R | i | i | i 1112 UA:LO:L | i | i | i | i | i | i | i 1113 UA:P:L | i | i | i | i | i | i | i 1114 UA:DP:L | i | i | i | i | i | i | i 1115 UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1116 UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1117 UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N 1118 PF:W:L | i | i | i | i | i | i | i 1119 PF:DW:L | i | i | i | i | i | i | i 1120 PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1121 PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) 1122 SA:F:L | i | i | i | i | i | i | i 1123 SA:MW:L | i | i | i | i | i | i | i 1124 SA:MP:L | i | i | i | i | i | i | i 1125 SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N 1126 SA:MW:R | i | SA:MP:R | i | E::R | i | i | N 1127 SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N 1128 WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12) 1129 DNR | SA:MW:R | SA:MP:R | (13)| E::R | i | i | i 1130 E::L | SA:MW:R | SA:MP:R | i | i | i | i | i 1131 E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N 1132 NOTES: 1134 (7) If the received SD-W message has Path=0, ignore the message. If 1135 the received SD-W message has Path=1, go to the PF:DW:R state 1136 and transmit SD(0,1) 1138 (8) If the received SD-P message has Path=1, ignore the message. If 1139 the received SD-P message has Path=0, go to the UA:DP:R state 1140 and transmit SD(1,0). 1142 (9) Transition to the WTR state and continue to send the current 1143 message. 1145 (10) Transition to the DNR state and continue to send the current 1146 message. 1148 (11) If the received NR message has Path=1, transition to the WTR 1149 state if domain configured for revertive behavior, else 1150 transition to the DNR state. If the received NR message has 1151 Path=0, transition to the Normal state. 1153 (12) If the receiving node's WTR timer is running, maintain current 1154 state and message. If the WTR timer is not running, transition 1155 to the Normal state. 1157 (13) Transit to the WTR state and send NR(0,1) message. The WTR 1158 timer is not initiated. 1160 11.3. State transition for 1+1 unidirectional protection 1162 The state transition tables given in Sections 11.1 and 11.2 are for 1163 bidirectional protection switching, where remote PSC protocol 1164 messages are used to determine the protection switching actions. 1+1 1165 unidirectional protection switching does not require the remote 1166 information in PSC protocol message and acts upon local inputs only. 1167 The state transition by local inputs in Section 11.1 SHALL be reused 1168 for 1+1 unidirectional protection under the following conditions: 1170 o The value of Request field in the received remote message is 1171 ignored and always assumed to be no request. 1173 o Replace footnote (4) with "Stop the WTR timer and transit to the 1174 Normal state." 1176 o Replace footnote (6) with "Transit to the Normal state." 1178 o Exercise command is not relevant. 1180 12. Provisioning Mismatch and Protocol Failure in APS Mode 1182 The remote PSC message that is received from the remote node is 1183 subject to the detection of provisioning mismatch and protocol 1184 failure conditions. In APS mode, provisioning mismatches are handled 1185 as follows: 1187 o If the PSC message is received from the working path due to 1188 working/protection path configuration mismatch, the node MUST 1189 alert the operator and MUST NOT perform any protection switching 1190 until the operator resolves this path configuration mismatch. 1192 o In the case that the mismatch happens in two-bit "Protection Type 1193 (PT)" field, which indicates permanent/selector bridge type and 1194 uni/bidirectional switching type, 1196 * If the value of the PT field of one side is 2 (i.e., selector 1197 bridge) and the value of PT field of the other side is 1 or 3 1198 (i.e., permanent bridge), then this event MUST be notified to 1199 the operator and each node MUST NOT perform any protection 1200 switching until the operator resolves this bridge type 1201 mismatch. 1203 * If the bridge type matches but the switching type mismatches, 1204 i.e., one side has PT=1 (unidirectional switching) while the 1205 other side has PT=2 or 3 (bidirectional switching), then the 1206 node provisioned for bidirectional switching SHOULD fall back 1207 to unidirectional switching to allow interworking. The node 1208 SHOULD notify the operator of this event. 1210 o If the "Revertive (R)" bit mismatches, two sides will interwork 1211 and traffic is protected according to the state transition 1212 definition given in Section 11. The node SHOULD notify the 1213 operator of this event. 1215 o If the Capabilities TLV mismatches, the node MUST alert the 1216 operator and MUST NOT perform any protection switching until the 1217 operator resolves the mismatch in the Capabilities TLV. 1219 The followings are the protocol failure situations and the actions to 1220 be taken: 1222 o No match in sent "Data Path (Path)" and received "Data Path 1223 (Path)" for more than 50 ms: The node MAY continue to perform 1224 protection switching and SHOULD notify the operator of this event. 1226 o No PSC message is received on the protection path during at least 1227 3.5 times the long PSC message interval, (e.g. at least 17.5 1228 seconds with a default message interval of 5 seconds) and there is 1229 no defect on the protection path: The node MUST alert the operator 1230 and MUST NOT perform any protection switching until the operator 1231 resolves this defect. 1233 13. Security Considerations 1235 This document introduces no new security risks. [RFC6378] points out 1236 that MPLS relies on assumptions about traffic injection difficulty 1237 and assumes that the control plane does not have end-to-end security. 1238 [RFC5920] describes MPLS security issues and generic methods for 1239 securing traffic privacy and integrity. MPLS use should conform such 1240 advice. 1242 14. IANA Considerations 1244 14.1. MPLS PSC Request Registry 1246 In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA 1247 maintains the "MPLS PSC Request Registry". 1249 IANA is requested to assign two new code points from this registry. 1250 The values shall be allocated as follows: 1252 Value Description Reference 1253 ----- --------------------- --------------- 1254 2 Reverse Request (this document) 1255 3 Exercise (this document) 1257 14.2. MPLS PSC TLV Registry 1259 In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA 1260 maintains the "MPLS PSC TLV Registry". 1262 This document defines a new value for the Capabilities TLV type in 1263 the "MPLS PSC TLV Registry". 1265 Value Description Reference 1266 ------ --------------------- --------------- 1267 TBD Capabilities (this document) 1269 14.3. MPLS PSC Capability Flag Registry 1271 IANA is requested to create and maintain a new registry within the 1272 "Generic Associated Channel (G-ACh) Parameters" registry called "MPLS 1273 PSC Capability Flag Registry". All flags within this registry SHALL 1274 be allocated according to the "Standards Action" procedures as 1275 specified in RFC 5226 [RFC5226]. 1277 The length of the flags MUST be a multiple of 4 octets. This 1278 document defines 4 octet flags. Flags greater than 4 octets SHALL be 1279 used only if more than 32 Capabilities need to be defined. Flags 1280 defined in this document are: 1282 Bit Hex Value Capability Reference 1283 ---- ---------- ----------------------------------- --------------- 1284 0 0x80000000 priority modification (this document) 1285 1 0x40000000 non-revertive behavior modification (this document) 1286 2 0x20000000 support of MS-W command (this document) 1287 3 0x10000000 support of protection against SD (this document) 1288 4 0x08000000 support of EXER command (this document) 1289 5-31 Unassigned (this document) 1291 15. Acknowledgements 1293 The authors would like to thank Yaacov Weingarten, Yuji Tochio, 1294 Malcolm Betts, Ross Callon, Qin Wu and Xian Zhang for their valuable 1295 comments and suggestions on this document. 1297 We would also like to acknowledge explicit text provided by Loa 1298 Andersson and Adrian Farrel. 1300 16. References 1302 16.1. Normative References 1304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1305 Requirement Levels", BCP 14, RFC 2119, March 1997. 1307 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1308 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1309 May 2008. 1311 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1312 and S. Ueno, "Requirements of an MPLS Transport Profile", 1313 RFC 5654, September 2009. 1315 [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and 1316 A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear 1317 Protection", RFC 6378, October 2011. 1319 16.2. Informative References 1321 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1322 Restoration) Terminology for Generalized Multi-Protocol 1323 Label Switching (GMPLS)", RFC 4427, March 2006. 1325 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1326 Networks", RFC 5920, July 2010. 1328 [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- 1329 TP) Survivability Framework", RFC 6372, September 2011. 1331 [G841] International Telecommunications Union, "Types and 1332 characteristics of SDH network protection architectures", 1333 ITU-T Recommendation G.841, October 1998. 1335 [G873.1] International Telecommunications Union, "Optical Transport 1336 Network (OTN): Linear protection", ITU-T Recommendation 1337 G.873.1, July 2011. 1339 [G8031] International Telecommunications Union, "Ethernet Linear 1340 Protection Switching", ITU-T Recommendation G.8031/Y.1342, 1341 June 2011. 1343 Appendix A. An Example of Out-of-service Scenarios 1345 The sequence diagram shown is an example of the out-of-service 1346 scenarios based on the priority level defined in [RFC6378]. The 1347 first PSC message which differs from the previous PSC message is 1348 shown. 1350 A Z 1351 | | 1352 (1) |-- NR(0,0) ------>| (1) 1353 |<----- NR(0,0) ---| 1354 | | 1355 | | 1356 | (FS issued at Z) | (2) 1357 (3) |<------ FS(1,1) --| 1358 |-- NR(0,1) ------>| 1359 | | 1360 | | 1361 (4) | (SF on P(A<-Z)) | 1362 | | 1363 | | 1364 | (Clear FS at Z) | (5) 1365 (6) | X <- NR(0,0) --| 1366 | | 1367 | | 1369 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1371 (2) When a FS command is issued at node Z, node Z goes into local 1372 Protecting Administrative state (PA:F:L) and begins transmission of 1373 an FS(1,1) messages. 1375 (3) A remote FS message causes node A to go into remote Protecting 1376 Administrative state (PA:F:R), and node A begins transmitting NR(0,1) 1377 messages. 1379 (4) When node A detects a unidirectional SF-P, node A keeps sending 1380 NR(0,1) message because SF-P is ignored under the PA:F:R state. 1382 (5) When a Clear command is issued at node Z, node Z goes into the 1383 Normal state and begins transmission of NR(0,0) messages. 1385 (6) But, node A cannot receive PSC message because of local 1386 unidirectional SF-P. Because no valid PSC message is received, over 1387 a period of several successive message intervals, the last valid 1388 received message remains applicable and the node A continue to 1389 transmit an NR(0,1) message in the PA:F:R state. 1391 Now, there exists a mismatch between the bridge/selector positions of 1392 node A (transmitting an NR(0,1)) and node Z (transmitting an 1393 NR(0,0)). It results in out-of-service even when there is neither 1394 SF-W nor FS. 1396 Appendix B. An Example of Sequence Diagram Showing the Problem with the 1397 Priority Level of SFc 1399 An example of sequence diagram showing the problem with the priority 1400 level of SFc defined in [RFC6378] is given below. The following 1401 sequence diagram is depicted for the case of bidirectional signal 1402 fails. However, other cases with unidirectional signal fails can 1403 result in the same problem. The first PSC message which differs from 1404 the previous PSC message is shown. 1406 A Z 1407 | | 1408 (1) |-- NR(0,0) ------>| (1) 1409 |<----- NR(0,0) ---| 1410 | | 1411 | | 1412 (2) | (SF on P(A<->Z)) | (2) 1413 |-- SF(0,0) ------>| 1414 |<------ SF(0,0) --| 1415 | | 1416 | | 1417 (3) | (SF on W(A<->Z)) | (3) 1418 | | 1419 | | 1420 (4) | (Clear SF-P) | (4) 1421 | | 1422 | | 1423 (5) | (Clear SF-W) | (5) 1424 | | 1425 | | 1427 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1429 (2) When SF-P occurs, each node enters into the UA:P:L state and 1430 transmits SF(0,0) messages. Traffic remains on the working path. 1432 (3) When SF-W occurs, each node remains in the UA:P:L state as SF-W 1433 has a lower priority than SF-P. Traffic is still on the working 1434 path. Traffic cannot be delivered as both the working path and the 1435 protection path are experiencing signal fails. 1437 (4) When SF-P is cleared, local "Clear SF-P" request cannot be 1438 presented to the PSC Control Logic, which takes the highest local 1439 request and runs PSC state machine, since the priority of "Clear 1440 SF-P" is lower than that of SF-W. Consequently, there is no change 1441 in state, and the selector and/or bridge keep pointing at the working 1442 path, which has signal fail condition. 1444 Now, traffic cannot be delivered while the protection path is 1445 recovered and available. It should be noted that the same problem 1446 will occur in the case that the sequence of SF-P and SF-W events is 1447 changed. 1449 If we further continue with this sequence to see what will happen 1450 after SF-W is cleared, 1452 (5) When SF-W is cleared, local "Clear SF-W" request can be passed to 1453 the PSC Control Logic as there is no higher priority local input, but 1454 this will be ignored in the PSC Control Logic according to the state 1455 transition definition in [RFC6378]. There will be no change in state 1456 or protocol message transmitted. 1458 As SF-W is now cleared and the selector and/or bridge are still 1459 pointing at the working path, traffic delivery is resumed. However, 1460 each node is in the UA:P:L state and transmitting SF(0,0) message, 1461 while there exists no outstanding request for protection switching. 1462 Moreover, any future legitimate protection switching requests, such 1463 as SF-W, will be rejected as each node thinks the protection path is 1464 unavailable. 1466 Appendix C. Freeze Command 1468 The "Freeze" command applies only to the local node of the protection 1469 group and is not signaled to the remote node. This command freezes 1470 the state of the protection group. Until the Freeze is cleared, 1471 additional local commands are rejected and condition changes and 1472 received PSC information are ignored. 1474 "Clear Freeze" command clears the local freeze. When the Freeze 1475 command is cleared, the state of the protection group is recomputed 1476 based on the persistent condition of the local triggers. 1478 Because the freeze is local, if the freeze is issued at one end only, 1479 a failure of protocol can occur as the other end is open to accept 1480 any operator command or a fault condition. 1482 Appendix D. Operation Examples of the APS Mode 1484 The sequence diagrams shown in this section are only a few examples 1485 of the APS mode operations. The first PSC protocol message which 1486 differs from the previous message is shown. The operation of hold- 1487 off timer is omitted. The Request, FPath and Path fields, whose 1488 values are changed during PSC message exchange are shown. For an 1489 example, SF(1,0) represents an PSC message with the following field 1490 values: Request=SF, FPath=1 and Path=1. The values of the other 1491 fields remain unchanged from the initial configuration. W(A->Z) and 1492 P(A->Z) indicate the working path and the protection path in the 1493 direction of A to Z, respectively. 1495 Example 1. 1:1 bidirectional protection switching (revertive 1496 operation) - Unidirectional SF case 1497 A Z 1498 | | 1499 (1) |<---- NR(0,0)---->| (1) 1500 | | 1501 | | 1502 (2) | (SF on W(Z->A)) | 1503 |---- SF(1,1)----->| (3) 1504 (4) |<----- NR(0,1)----| 1505 | | 1506 | | 1507 (5) | (Clear SF-W) | 1508 |---- WTR(0,1)---->| 1509 /| | 1510 | | | 1511 WTR timer | | 1512 | | | 1513 \| | 1514 (6) |---- NR(0,1)----->| (7) 1515 (8) |<----- NR(0,0)----| 1516 |---- NR(0,0)----->| (9) 1517 | | 1519 (1) The protected domain is operating without any defect, and the 1520 working path is used for delivering the traffic in the Normal state. 1522 (2) SF-W occurs in the Z to A direction. Node A enters into the 1523 PF:W:L state and generates SF(1,1) message. Selector and bridge of 1524 node A are pointing at the protection path. 1526 (3) Upon receiving SF(1,1), node Z sets selector and bridge to the 1527 protection path. As there is no local request in node Z, node Z 1528 generates NR(0,1) message in the PF:W:R state. 1530 (4) Node A confirms that the remote node is also selecting the 1531 protection path. 1533 (5) Node A detects clearing of SF condition, starts the WTR timer, 1534 and sends WTR(0,1) message in the WTR state. 1536 (6) At expiration of the WTR timer, node A sets selector and bridge 1537 to the working path and sends NR(0,1) message. 1539 (7) Node Z is notified that the remote request has been cleared. 1540 Node Z transits to the Normal state and sends NR(0,0) message. 1542 (8) Upon receiving NR(0,0) message, node A transits to the Normal 1543 state and sends NR(0,0) message. 1545 (9) It is confirmed that the remote node is also selecting the 1546 working path. 1548 Example 2. 1:1 bidirectional protection switching (revertive 1549 operation) - Bidirectional SF case - Inconsistent WTR timers 1551 A Z 1552 | | 1553 (1) |<---- NR(0,0)---->| (1) 1554 | | 1555 | | 1556 (2) | (SF on W(A<->Z)) | (2) 1557 |<---- SF(1,1)---->| 1558 | | 1559 | | 1560 (3) | (Clear SF-W) | (3) 1561 |<---- NR(0,1)---->| 1562 (4) |<--- WTR(0,1) --->| (4) 1563 /| |\ 1564 | | | | 1565 WTR timer | | WTR timer 1566 | | | | 1567 | | |/ 1568 | |<------ NR(0,1)---| (5) 1569 | | | 1570 \| | 1571 (6) |--- NR(0,1)------>| 1572 |<------ NR(0,0)---| (7) 1573 (8) |--- NR(0,0)------>| 1574 | | 1576 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1578 (2) When SF-W occurs, each node enters into the PF:W:L state and 1579 transmits SF(1,1) messages. Traffic is switched to the protection 1580 path. Upon receiving SF(1,1), each node confirms that the remote 1581 node is also sending and receiving the traffic from the protection 1582 path. 1584 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1585 transmits NR(0,1) messages as the last received message is SF-W. 1587 (4) Upon receiving NR(0,1) messages, each node goes into the WTR 1588 state, starts the WTR timer, and sends the WTR(0,1) messages. 1590 (5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as 1591 the last received APS message was WTR. When NR(0,1) arrives at node 1592 A, node A maintains the WTR state and keeps sending current WTR 1593 messages as described in the state transition table. 1595 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1597 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1598 Normal state, sets selector and bridge to the working path, and sends 1599 NR(0,0) message. 1601 (8) The received NR(0,0) message causes node A to go to the Normal 1602 state. Now, the traffic is switched back to the working path. 1604 Example 3. 1:1 bidirectional protection switching - R bit mismatch 1606 This example shows that both sides will interwork and the traffic is 1607 protected when one side (node A) is configured as revertive operation 1608 and the other (node Z) is configured as non-revertive operation. The 1609 interworking is covered in the state transition tables. 1611 (revertive) A Z (non-revertive) 1612 | | 1613 (1) |<---- NR(0,0)---->| (1) 1614 | | 1615 | | 1616 (2) | (SF on W(A<->Z)) | (2) 1617 |<---- SF(1,1)---->| 1618 | | 1619 | | 1620 (3) | (Clear SF-W) | (3) 1621 |<---- NR(0,1)---->| 1622 (4) |<----- DNR(0,1)---| (4) 1623 /|-- WTR(0,1)------>| 1624 | |<----- NR(0,1)----| (5) 1625 | | | 1626 WTR timer | | 1627 | | | 1628 | | | 1629 \| | 1630 (6) |--- NR(0,1)------>| 1631 |<------ NR(0,0)---| (7) 1632 (8) |--- NR(0,0)------>| 1633 | | 1635 (1) Each end is in the Normal state, and transmits NR(0,0) messages. 1637 (2) When SF-W occurs, each node enters into the PF:W:L state and 1638 transmits SF(l,l) messages. Traffic is switched to the protection 1639 path. Upon receiving SF(1,1), each node confirms that the remote 1640 node is also sending and receiving the traffic on the protection 1641 path. 1643 (3) When SF-W is cleared, each node transits to the PF:W:R state and 1644 transmits NR(0,1) messages as the last received message is SF-W. 1646 (4) Upon receiving NR(0,1) messages, node A goes into the WTR state, 1647 starts the WTR timer, and sends WTR(0,1) messages. At the same time, 1648 node Z transits to the DNR state and sends DNR(0,1) message. 1650 (5) When the WTR message arrives at node Z, node Z transits to the 1651 WTR state and send NR(0,1) message according to the state transition 1652 table. At the same time, the DNR message arrived at node Z is 1653 ignored according to the state transition table. Therefore, node Z, 1654 which is configured as non-revertive operation, is operating as if in 1655 revertive operation. 1657 (6) At expiration of the WTR timer in node A, node A sends NR(0,1). 1659 (7) When the NR(0,1) message arrives at node Z, node Z moves to the 1660 Normal state, sets selector and bridge to the working path, and sends 1661 NR(0,0) message. 1663 (8) The received NR(0,0) message causes node A to transits to the 1664 Normal state. Now, the traffic is switched back to the working path. 1666 Authors' Addresses 1668 Jeong-dong Ryoo (editor) 1669 ETRI 1670 218 Gajeongno 1671 Yuseong-gu, Daejeon 305-700 1672 South Korea 1674 Phone: +82-42-860-5384 1675 Email: ryoo@etri.re.kr 1677 Eric Gray (editor) 1678 Ericsson 1680 Email: eric.gray@ericsson.com 1681 Huub van Helvoort 1682 Huawei Technologies 1683 Karspeldreef 4, 1684 Amsterdam 1101 CJ 1685 the Netherlands 1687 Phone: +31 20 4300936 1688 Email: huub.van.helvoort@huawei.com 1690 Alessandro D'Alessandro 1691 Telecom Italia 1692 via Reiss Romoli, 274 1693 Torino 10148 1694 Italy 1696 Phone: +39 011 2285887 1697 Email: alessandro.dalessandro@telecomitalia.it 1699 Taesik Cheung 1700 ETRI 1701 218 Gajeongno 1702 Yuseong-gu, Daejeon 305-700 1703 South Korea 1705 Phone: +82-42-860-5646 1706 Email: cts@etri.re.kr 1708 Eric Osborne 1710 Email: eric.osborne@notcom.com