idnits 2.17.1 draft-ietf-mpls-tp-linear-protection-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SurvivFwk]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 3, 2011) is 4643 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) -- Looks like a reference, but probably isn't: '5' on line 1817 -- Looks like a reference, but probably isn't: '1' on line 1809 -- Looks like a reference, but probably isn't: '2' on line 1811 -- Looks like a reference, but probably isn't: '6' on line 1820 -- Looks like a reference, but probably isn't: '3' on line 1813 -- Looks like a reference, but probably isn't: '7' on line 1823 -- Looks like a reference, but probably isn't: '4' on line 1815 -- Looks like a reference, but probably isn't: '8' on line 1826 -- Looks like a reference, but probably isn't: '9' on line 1828 -- Looks like a reference, but probably isn't: '10' on line 1830 -- Looks like a reference, but probably isn't: '16' on line 1844 -- Looks like a reference, but probably isn't: '11' on line 1832 -- Looks like a reference, but probably isn't: '12' on line 1834 -- Looks like a reference, but probably isn't: '14' on line 1838 -- Looks like a reference, but probably isn't: '15' on line 1841 -- Looks like a reference, but probably isn't: '13' on line 1836 -- Looks like a reference, but probably isn't: '17' on line 1848 -- Looks like a reference, but probably isn't: '18' on line 1851 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant 3 Internet-Draft E. Osborne 4 Intended status: Standards Track Cisco 5 Expires: February 4, 2012 N. Sprecher 6 Nokia Siemens Networks 7 A. Fulignoli, Ed. 8 Ericsson 9 Y. Weingarten, Ed. 10 Nokia Siemens Networks 11 August 3, 2011 13 MPLS-TP Linear Protection 14 draft-ietf-mpls-tp-linear-protection-09.txt 16 Abstract 18 The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is 19 being specified jointly by IETF and ITU-T. This document addresses 20 the functionality described in the MPLS-TP Survivability Framework 21 document [SurvivFwk] and defines a protocol that may be used to 22 fulfill the function of the Protection State Coordination for linear 23 protection, as described in that document. 25 This document is a product of a joint Internet Engineering Task Force 26 (IETF) / International Telecommunications Union Telecommunications 27 Standardization Sector (ITU-T) effort to include an MPLS Transport 28 Profile within the IETF MPLS and PWE3 architectures to support the 29 capabilities and functionalities of a packet transport network as 30 defined by the ITU-T. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 4, 2012. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Protection architectures . . . . . . . . . . . . . . . . . 4 80 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 81 1.3. Contributing authors . . . . . . . . . . . . . . . . . . . 6 82 2. Conventions used in this document . . . . . . . . . . . . . . 6 83 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 85 3. Protection switching control logic . . . . . . . . . . . . . . 7 86 3.1. Local Request Logic . . . . . . . . . . . . . . . . . . . 8 87 3.2. Remote Requests . . . . . . . . . . . . . . . . . . . . . 10 88 3.3. PSC Control Logic . . . . . . . . . . . . . . . . . . . . 11 89 3.4. PSC Message Generator . . . . . . . . . . . . . . . . . . 12 90 3.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . . . 12 91 3.6. PSC Control States . . . . . . . . . . . . . . . . . . . . 12 92 3.6.1. Local and Remote state . . . . . . . . . . . . . . . . 14 93 4. Protection state coordination (PSC) protocol . . . . . . . . . 14 94 4.1. Transmission and acceptance of PSC control packets . . . . 15 95 4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 15 96 4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 16 97 4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 16 98 4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 18 99 4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 18 100 4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 18 101 4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 19 102 4.2.7. Additional TLV information . . . . . . . . . . . . . . 19 103 4.3. Principles of Operation . . . . . . . . . . . . . . . . . 19 104 4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 20 105 4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 21 106 4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 22 107 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 5.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 32 109 5.2. PSC Request Field . . . . . . . . . . . . . . . . . . . . 33 110 5.3. Additional TLVs . . . . . . . . . . . . . . . . . . . . . 33 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 112 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 115 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 116 Appendix A. PSC state machine tables . . . . . . . . . . . . . . 36 117 Appendix B. Exercising the protection domain . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the 123 construction and operation of packet-switched transport networks 124 based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for 125 Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of 126 [RFC5654]. 128 Network survivability is the ability of a network to recover traffic 129 delivery following failure, or degradation of network resources. The 130 MPLS-TP Survivability Framework [SurvivFwk] is a framework for 131 survivability in MPLS-TP networks, and describes recovery elements, 132 types, methods, and topological considerations, focusing on 133 mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). 135 Linear protection in mesh networks - networks with arbitrary 136 interconnectivity between nodes - is described in Section 4.7 of 137 [SurvivFwk]. Linear protection provides rapid and simple protection 138 switching. In a mesh network, linear protection provides a very 139 suitable protection mechanism because it can operate between any pair 140 of points within the network. It can protect against a defect in an 141 intermediate node, a span, a transport path segment, or an end-to-end 142 transport path. 144 1.1. Protection architectures 146 Protection switching is a fully allocated survivability mechanism. 147 It is fully allocated in the sense that the route and resources of 148 the protection path are reserved for a selected working path or set 149 of working paths. It provides a fast and simple survivability 150 mechanism, that allows the network operator to easily grasp the 151 active state of the network, that can operate between any pair of 152 points within the network. 154 As described in the Survivability Framework document [SurvivFwk], 155 protection switching is applied to a protection domain. For the 156 purposes of this document, we define the protection domain of a 157 point-to-point LSP as consisting of two Label Edge Routers (LER) and 158 the transport paths that connect them (see Figure 3 below). For a 159 point-to-multipoint LSP the protection domain includes the root (or 160 source) LER, the destination (or sink) LERs, and the transport paths 161 that connect them. 163 In 1+1 unidirectional architecture as presented in [SurvivFwk], a 164 protection transport path is dedicated to the working transport path. 165 Normal traffic is bridged (as defined in [RFC4427])and fed to both 166 the working and the protection paths by a permanent bridge at the 167 source of the protection domain. The sink of the protection domain 168 uses a selector to select either the working or protection paths to 169 receive the traffic from, based on a predetermined criteria, e.g. 170 server defect indication. When used for bidirectional switching the 171 1+1 protection architecture must also support a Protection State 172 Coordination (PSC) protocol. This protocol is used to help 173 coordinate between both ends of the protection domain in selecting 174 the proper traffic flow. 176 In the 1:1 architecture, a protection transport path is dedicated to 177 the working transport path of a single service and the traffic is 178 only transmitted either on the working or the protection path, by 179 using a selector at the source of the protection domain. A selector 180 at the sink of the protection domain then selects the path that 181 carries the normal traffic. Since the source and sink need to be 182 coordinated to ensure that the selector at both ends select the same 183 path, this architecture must support a PSC protocol. 185 The 1:n protection architecture extends the 1:1 architecture above by 186 sharing the protection path among n services. Again, the protection 187 path is fully allocated and disjoint from any of the n working 188 transport paths that it is being used to protect. The normal data 189 traffic for each service is transmitted either on the normal working 190 path for that service or, in cases that trigger protection switching 191 (as listed in [SurvivFwk]), may be sent on the protection path. The 192 switching action is similar to the 1:1 case where a selector is used 193 at the source. It should be noted that in cases where multiple 194 working path services have triggered protection switching that some 195 services, dependent upon their Service Level Agreement (SLA), may not 196 be transmitted as a result of limited resources on the protection 197 path. In this architecture there may be a need for coordination of 198 the protection switching, and also for resource allocation 199 negotiation. The procedures for this are for further study and may 200 be addressed in future documents. 202 1.2. Scope of the document 204 As was pointed out in the Survivability Framework [SurvivFwk] and 205 highlighted above, there is a need for coordination between the end 206 points of the protection domain when employing bidirectional 207 protection schemes. This is especially true when there is a need to 208 verify that the traffic continues to be transported on a bi- 209 directional LSP that is co-routed. 211 The scope of this draft is to present a protocol for the Protection 212 State Coordination of Linear Protection. The protocol addresses the 213 protection of LSPs in an MPLS-TP network as required by [RFC5654] (in 214 particular requirements 63-65 and 74-79) and described in 215 [SurvivFwk]. The basic protocol is designed for use in conjunction 216 with the 1:1 protection architecture bidirectional protection and for 217 1+1 protection of a bidirectional path (for both unidirectional and 218 bidirectional protection switching). Applicability of the protocol 219 for 1:1 unidirectional protection and for 1:n protection schemes may 220 be documented in a future document and are out of scope for this 221 document. The applicability of this protocol to additional MPLS-TP 222 constructs and topologies may be documented in future documents. 224 While the unidirectional 1+1 protection architecture does not require 225 the use of a coordination protocol, the protocol may be used by the 226 ingress node of the path to notify the far-side end point that a 227 switching condition has occurred and verify the consistency of the 228 end point configuration. This use may be especially useful for 229 point-to-multipoint transport paths, that are unidirectional by 230 definition of [RFC5654]. The use of this protocol for point-to- 231 multipoint paths is out of scope for this document and may be 232 addressed in a future applicability document. 234 1.3. Contributing authors 236 Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson), 237 Francesco Fondelli (Ericsson), 239 2. Conventions used in this document 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 243 document are to be interpreted as described in [RFC2119]. 245 2.1. Acronyms 247 This draft uses the following acronyms: 249 DNR Do not revert 250 FS Forced Switch 251 G-ACh Generic Associated Channel 252 LER Label Edge Router 253 LO Lockout of protection 254 MPLS-TP Transport Profile for MPLS 255 MS Manual Switch 256 NR No Request 257 PSC Protection State Coordination Protocol 258 SD Signal Degrade 259 SF Signal Fail 260 SLA Service Level Agreement 261 WTR Wait-to-Restore 263 2.2. Definitions and Terminology 265 The terminology used in this document is based on the terminology 266 defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk]. 267 In addition, we use the term LER to refer to a MPLS-TP Network 268 Element, whether it is a LSR, LER, T-PE, or S-PE. 270 3. Protection switching control logic 272 Protection switching processes the local triggers described in 273 requirements 74-79 of [RFC5654] together with inputs received from 274 the far-end LER. Based on these inputs the LER will take certain 275 protection switching actions, e.g. switching the selector to transmit 276 on the working or protection path for 1:1 protection or switching the 277 selector to receive the traffic for either 1:1 or 1+1 protection, and 278 transmit different protocol messages. 280 The following figure shows the logical decomposition of the 281 Protection Switching Control Logic into different logical processing 282 units. These processing units are presented in subsequent 283 subsections of this document. This logical decomposition is only 284 intended for descriptive purposes, any implementation that produces 285 the external behavior described in section 4 is acceptable. 287 Server Indication Control Plane Indication 288 -----------------+ +------------- 289 Operator Command | | OAM Indication 290 ----------------+ | | +--------------- 291 | | | | 292 V V V V 293 +---------------+ +-------+ 294 | Local Request |<--------| WTR | 295 | logic |WTR Exps | Timer | 296 +---------------+ +-------+ 297 | ^ 298 Highest local|request | 299 V | Start/Stop 300 +-----------------+ | 301 Remote PSC | PSC Control |------------+ 302 ------------>| logic | 303 Request +-----------------+ 304 | 305 | Action +------------+ 306 +---------------->| Message | 307 | Generator | 308 +------------+ 309 | 310 Output PSC | Message 311 V 313 Figure 1: Protection switching control logic 315 Figure 1 describes the logical architecture of the protection 316 switching control. The Local Request logic unit accepts the triggers 317 from the OAM, external operator commands, from the local control 318 plane (when present), and the Wait-to-Restore timer. By considering 319 all of these local request sources it determines the highest priority 320 local request. This high-priority request is passed to the PSC 321 Control logic, that will cross-check this local request with the 322 information received from the far-end LER. The PSC Control logic 323 uses this input to determine what actions need to be taken, e.g. 324 local actions at the LER, or what message should be sent to the far- 325 end LER, and the current status of the protection domain. 327 3.1. Local Request Logic 329 The Local Request logic processes input triggers from five sources: 331 o Operator command - the network operator may issue local 332 administrative commands on the LER that trigger protection 333 switching. The commands Forced Switch, Manual Switch, Clear, 334 Lockout of Protection (see definitions in [RFC4427]) MUST be 335 supported. An implementation MAY provide additional commands for 336 operator use; providing that these commands do not introduce 337 incompatable behavior between two arbitrary implementations, they 338 are outside the scope of this document. For example, an 339 implementation could provide a command to manually trigger a "WTR 340 expires" trigger (see below) input without waiting for the 341 duration of the WTR timer; as this merely hastens the transition 342 from one state to another and has no impact on the state machine 343 itself, it would be perfectly valid. 345 o Server layer alarm indication - the underlying server layer of the 346 network detects failure conditions at the underlying layer and may 347 issue an indication to the MPLS-TP layer. The server layer may 348 employ its own protection switching mechanism, and therefore this 349 input MAY be controlled by a holdoff-timer that SHOULD be 350 configurable by the network operator. The holdoff-timer is 351 described in greater detail in [SurvivFwk]. 353 o Control plane - if there is a control plane active in the network 354 (either signaling or routing), it MAY trigger protection switching 355 based on conditions detected by the control plane. If the control 356 plane is based on GMPLS [RFC3945] then the recovery process SHALL 357 comply with the process described in [RFC4872] and [RFC4873]. 359 o OAM indication - OAM fault management or performance measurement 360 tools may detect a failure or degrade condition on either the 361 working or protection transport path and this MUST input an 362 indication to the Local Request Logic. 364 o WTR expires - The Wait-to-Restore timer is used in conjunction 365 with recovery from failure conditions on the working path in 366 revertive mode. The timer SHALL signal the PSC control process 367 when it expires and the end point SHALL revert to the normal 368 transmission of the user data traffic. 370 The input from these sources SHOULD be retained persistently for the 371 duration of condition that initiated the trigger. The Local request 372 logic processes these different input sources and, based on the 373 priorities between them (see section 4.3.2), produces a current local 374 request. If more than one local input source generates a trigger, 375 then the Local request logic selects the higher priority indicator 376 and ignores any lower priority indicator. As a result, there is a 377 single current local request that is passed to the PSC Control logic. 378 The different local requests that may be output from the Local 379 Request Logic are: 381 o Clear - if the operator cancels an active local administrative 382 command, i.e. LO/FS/MS. 384 o Lockout of Protection (LO) - if the operator requested to prevent 385 switching data traffic to the protection path, for any purpose. 387 o Signal Fail (SF) - if any of the Server Layer, Control plane, or 388 OAM indications signaled a failure condition on either the 389 protection path or one of the working paths. 391 o Signal Degrade (SD) - if any of the Server Layer, Control plane, 392 or OAM indications signaled a degraded transmission condition on 393 either the protection path or one of the working paths. The 394 determination and actions for SD are for further study and may 395 appear in a separate document. All references to SD input are 396 place-holders for this extension. 398 o Clear Signal Fail (SFc) - if all of the Server Layer, Control 399 plane, or OAM indications are no longer indicating a failure 400 condition on a path that was previously indicating a failure 401 condition. 403 o Forced Switch (FS) - if the operator requested that traffic be 404 switched from one of the working paths to the protection path. 406 o Manual Switch (MS) - if the operator requested that traffic be 407 switched from the working path to the protection path. This is 408 only relevant if there is no currently active fault condition or 409 Operator command. 411 o WTR Expires - generated by the WTR timer completing its period. 413 If none of the input sources have generated any input then the Local 414 request logic should generate a No Request (NR) request as the 415 current local request . 417 3.2. Remote Requests 419 In addition to the local requests, generated as a result of the local 420 triggers, indicated in the previous subsection, the PSC Control Logic 421 SHALL accept PSC messages from the far-end LER of the transport path. 422 Remote messages indicate the status of the transport path from the 423 viewpoint of the far-end LER. These messages may drive state changes 424 on the local MEP, as defined later in this document. When using 1+1 425 unidirectional protection, an LER that receives a remote request 426 SHALL NOT perform any protection switching action, i.e. will continue 427 to select traffic from the working path and transport traffic on both 428 paths. 430 The following remote requests may be received by the PSC process: 432 o Remote LO - indicates that the remote end point is in Unavailable 433 state due to a Lockout of Protection operator command. 435 o Remote SF - indicates that the remote end point has detected a 436 Signal Fail condition on one of the transport paths in the 437 protection domain. This remote message includes an indication of 438 which transport path is affected by the SF condition. In 439 addition, it should be noted that the SF condition may be either a 440 unidirectional or a bidirectional failure, even if the transport 441 path is bidirectional. 443 o Remote SD - indicates that the remote end point has detected a 444 Signal Degrade condition on one of the transport paths in the 445 protection domain. This remote message includes an indication of 446 which transport path is affected by the SD condition. In 447 addition, it should be noted that the SD condition may be either a 448 unidirectional or a bidirectional failure, even if the transport 449 path is bidirectional. 451 o Remote FS - indicates that the remote end point is operating under 452 an operator command to switch the traffic to the protection path. 454 o Remote MS - indicates that the remote end point is operating under 455 an operator command to switch the traffic from the working path to 456 the protection path. 458 o Remote WTR - indicates that the remote end point has determined 459 that the failure condition has recovered and has started its WTR 460 timer in preparation for reverting to the Normal state. 462 o Remote DNR - indicates that the remote end point has determined 463 that the failure condition has recovered and will continue 464 transporting traffic on the protection path due to operator 465 configuration that prevents automatic reversion to the Normal 466 state. 468 o Remote NR - indicates that the remote end point has no abnormal 469 condition to report. 471 3.3. PSC Control Logic 473 The PSC Control Logic accepts the following input - 475 a. the current local request output from the Local Request Logic 476 (see Section 3.1), 478 b. the remote request message from the remote end point of the 479 transport path (see Section 3.2), and 481 c. the current state of the PSC Control Logic (maintained internally 482 by the PSC Control Logic). 484 Based on the priorities between the different inputs, the PSC Control 485 Logic determines the new state of the PSC Control Logic and what 486 actions need to be taken. 488 The new state information is retained by the PSC Control Logic, while 489 the requested action should be sent to the PSC Message Generator (see 490 Section 3.4) to generate and transmit the proper PSC message to be 491 transmitted to the remote end point of the protection domain. 493 3.4. PSC Message Generator 495 Based on the action output from the PSC Control Logic this unit 496 formats the PSC protocol message that is transmitted to the remote 497 end point of the protection domain. This message may either be the 498 same as the previously transmitted message or change when the PSC 499 control state (see section 3.6) has changed. The messages are 500 transmitted as described in section 4.1 of this document. 502 3.5. Wait-to-Restore (WTR) timer 504 The WTR timer is used to delay reversion to Normal state when 505 recovering from a failure condition on the working path and the 506 protection domain is configured for revertive behavior. The length 507 of the timer may be provisioned by the operator. The WTR may be in 508 one of two states - either Running or Stopped. The control of the 509 WTR timer is managed by the PSC Control Logic, by use of internal 510 signals to start and stop, i.e. reset, the WTR timer. 512 If the WTR timer expires prior to being stopped it SHALL generate a 513 WTR Expires local signal that is processed by the Local Request 514 Logic. If the WTR timer is running, sending a Stop command SHALL 515 reset the timer, and put the WTR timer into Stopped state, but SHALL 516 NOT generate a WTR Expires local signal. If the WTR timer is 517 stopped, a Stop command SHALL be ignored. 519 3.6. PSC Control States 521 The PSC Control Logic should maintain information on the current 522 state of the protection domain. Information on the state of the 523 domain is maintained by each LER within the protection domain. The 524 state information would include information of the current state of 525 the protection domain, an indication of the cause for the current 526 state (e.g. unavailable due to local LO command, protecting due to 527 remote FS), and, for each LER, should include an indication if the 528 state is related to a remote or local condition. 530 It should be noted that when referring to the "transport" of the data 531 traffic, in the following descriptions and later in the document that 532 the data will be transmitted on both the working and the protection 533 paths when using 1+1 protection, and on either the working or the 534 protection path exclusively when using 1:1 protection. When using 535 1+1 protection, the receiving LER should select the proper 536 transmission, according to the state of the protection domain. 538 The protection domain states that are supported by the PSC Control 539 Logic are: 541 o Normal state - Both the protection and working paths are fully 542 allocated and active, data traffic is being transported over (or 543 selected from) the working path, and no trigger events are 544 reported within the domain. 546 o Unavailable state - The protection path is unavailable - either as 547 a result of an operator Lockout command or a failure condition 548 detected on the protection path. 550 o Protecting failure state - The working path has reported a 551 failure/degrade condition and the user traffic is being 552 transported (or selected) on the protection path. 554 o Protecting administrative state - The operator has issued a 555 command switching the user traffic to the protection path. 557 o Wait-to-restore state - The protection domain is recovering from a 558 SF/SD condition on the working path that is being controlled by 559 the Wait-to-Restore (WTR) timer. 561 o Do-not-revert state - The protection domain has recovered from a 562 Protecting state, but the operator has configured the protection 563 domain to not automatically revert to the Normal state upon 564 recovery. The protection domain SHALL remain in this state until 565 the operator issues a command to revert to the Normal state or 566 there is a new trigger to switch to a different state. 568 See section 4.3.3 for details on what actions are taken by the PSC 569 Process Logic for each state and the relevant input. 571 3.6.1. Local and Remote state 573 An end-point may be in a given state as a result of either a local 574 input indicator, e.g. OAM, WTR timer, or as a result of receiving a 575 PSC message from the far-end LER. If the state is entered as a 576 result of a local input indicator, then the state is considered a 577 local state. If the state is entered as a result of a PSC message, 578 in the absence of a local input, then the state is considered a 579 remote state. This differentiation affects how the LER reacts to 580 different inputs, as described in Section 4.3.3. The PSC Control 581 logic should maintain, together with the current protection domain 582 state, an indication of whether this is a local or remote state, for 583 this LER. 585 In any instance where the LER has both a local and remote indicators 586 that cause the protection domain to enter a particular state, then 587 the state is considered a local state, regardless of the order in 588 which the indicators were processed. If, however, the LER has local 589 and remote indicators that would cause the protection domain to enter 590 different states, e.g. a Local SF on working and a Remote Lockout 591 message, then the input with the higher priority (see section 4.3.2) 592 will be the deciding factor and the source of that indicator will 593 determine whether it is local or remote. In the given example the 594 result would be a Remote Unavailable state transmitting PSC messages 595 that indicate a SF condition on the working path and that the 596 protection path is not being used to transport protected traffic (as 597 described in the next section). 599 4. Protection state coordination (PSC) protocol 601 Bidirectional protection switching, as well as unidirectional 1:1 602 protection, requires coordination between the two end points in 603 determining which of the two possible paths, the working or 604 protection path, is transmitting the data traffic in any given 605 situation. When protection switching is triggered as described in 606 section 3, the end points must inform each other of the switch-over 607 from one path to the other in a coordinated fashion. 609 There are different possibilities for the type of coordinating 610 protocol. One possibility is a two-phased coordination in which the 611 LER that is initiating the protection switching sends a protocol 612 message indicating the switch but the actual switch-over is performed 613 only after receiving an 'Ack' from the far-end LER. The other 614 possibility is a single-phased coordination, in which the initiating 615 LER performs the protection switchover to the alternate path and 616 informs the far-end LER of the switch, and the far-end LER will 617 complete the switchover. 619 This protocol is a single-phased protocol, as described above. In 620 the following subsections we describe the protocol messages that are 621 used between the two end points of the protection domain. 623 4.1. Transmission and acceptance of PSC control packets 625 The PSC control packets SHALL be transmitted over the protection path 626 only. This allows the transmission of the messages without affecting 627 the normal data traffic in the most prevalent case, i.e. the Normal 628 state. In addition, limiting the transmission to a single path 629 avoids possible conflicts and race conditions that could develop if 630 the PSC messages were sent on both paths. 632 When the protection domain state is changed due to a local input, 633 three PSC messages SHALL be transmitted as quickly as possible, to 634 allow for rapid protection switching. This set of three rapid 635 messages allows for fast protection switching even if one or two of 636 these packets are lost or corrupted. When the protection domain 637 state changes due to a remote message the LER SHOULD send the three 638 rapid messages. However, when the LER tranfers from WTR state to 639 Normal state as a result of a remote NR message, the three rapid 640 messages SHALL be transmitted. After the transmission of the three 641 rapid messages, the LER MUST retransmit the most recently transmitted 642 PSC message on a continual basis. 644 Both the default frequency of the three rapid messages as well as the 645 default frequency of the continual message transmission SHALL be 646 configurable by the operator. The actual frequencies used MAY be 647 configurable, at the time of establishment, for each individual 648 protected LSP. For management purposes, the operator SHOULD be able 649 to retrieve the current default frequency values as well as the 650 actual values for any specific LSP. For protection switching within 651 50ms, it is RECOMMENDED that the default interval of the first three 652 rapid PSC messages SHOULD be no larger than 3.3ms. Using this 653 frequency would allow the far-end to be guaranteed of receiving the 654 trigger indication within 10ms and completion of the switching 655 operation within 50ms. Subsequent messages SHOULD be continuously 656 transmitted with a default interval of 5 seconds. The purpose of the 657 continual messages is to verify that the PSC session is still alive. 659 If no valid PSC message is received, over a period of several 660 continual messages intervals, the last valid received message remains 661 applicable. 663 4.2. Protocol format 665 The protocol messages SHALL be sent over the G-ACh as described in 666 [RFC5586]. There is a single channel type for the set of PSC 667 messages. The actual message function SHALL be identified by the 668 Request field of the ACH payload as described below. 670 The channel type for the PSC messages SHALL be PSC-CT=0xHH (to be 671 assigned by IANA) 673 The following figure shows the format for the complete PSC message: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 |0 0 0 1|Version| Reserved | PSC-CT | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 |Ver|Request|PT |R| Reserved1 | FPath | Path | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | TLV Length | Reserved2 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 ~ Optional TLVs ~ 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Figure 2: Format of PSC packet with a G-ACh header 689 Where: 691 o Both Reserved1 and Reserved2 fields MUST be set to 0 and ignored 692 upon receipt. 694 o The following subsections describe the remaining fields of the PSC 695 payload. 697 4.2.1. PSC Ver field 699 The Ver field identifies the version of the protocol. For this 700 version of the document the value SHALL be 1. 702 4.2.2. PSC Request field 704 The PSC protocol SHALL support transmission of the following requests 705 between the two end points of the protection domain: 707 o (14) Lockout of protection - indicates that the end point has 708 disabled the protection path as a result of an administrative 709 command. Both the FPath and Path fields SHALL be set to 0. 711 o (12) Forced switch - indicates that the transmitting end point has 712 switched traffic to the protection path as a result of an 713 administrative command. The Fpath field SHALL indicate that the 714 working path is being blocked (i.e. Fpath set to 1), and the Path 715 field SHALL indicate that user data traffic is being transported 716 on the protection path (i.e. Path set to 1). 718 o (10) Signal Fail - indicates that the transmitting end point has 719 identified a signal fail condition on either the working or 720 protection path. The Fpath field SHALL identify the path that is 721 reporting the failure condition (i.e. if protection path then 722 Fpath is set to 0 and if working path then Fpath is set to 1), and 723 the Path field SHALL indicate where the data traffic is being 724 transported (i.e. if protection path is blocked then Path is set 725 to 0 and if working path is blocked then Path is set to 1). 727 o (7) Signal Degrade - indicates that that the transmitting end 728 point has identified a degradation of the signal, or integrity of 729 the packet transmission on either the working or protection path. 730 This request is presented here only as a place-holder. The 731 specifics for the method of identifying this degradation is out- 732 of-scope for this document. The details of the actions to be 733 taken for this situation is left for future specification. 735 o (5) Manual switch - indicates that the transmitting end point has 736 switched traffic to the protection path as a result of an 737 administrative Manual Switch command. The Fpath field SHALL 738 indicate that the working path is being blocked (i.e. Fpath set 739 to 1), and the Path field SHALL indicate that user data traffic is 740 being transported on the protection path (i.e. Path set to 1). 742 o (4) Wait to restore - indicates that the transmitting end point is 743 recovering from a failure condition of the working path and has 744 started the Wait-to-Restore timer. Fpath SHALL be set to 0 and 745 ignored upon receipt. Path SHALL indicate the working path that 746 is currently being protected (i.e. Path set to 1). 748 o (1) Do not revert - indicates that the transmitting end point has 749 recovered from a failure/blocked condition, but due to the local 750 settings is is requesting that the protection domain continues to 751 transport the data as if it is in a protecting state, rather than 752 revert to the Normal state. Fpath SHALL be set to 0 and ignored 753 upon receipt. Path SHALL indicate the working path that is 754 currently being protected (i.e. Path set to 1). 756 o (0) No request - indicates that the transmitting end point has 757 nothing to report, Fpath and Path fields SHALL be set to according 758 to the state of the end point, see section 4.3.3 for detailed 759 scenarios. 761 All other values are for future extensions (to be administered by 762 IANA) and SHALL be ignored upon receipt. 764 4.2.3. Protection Type (PT) 766 The PT field indicates the currently configured protection 767 architecture type, this SHOULD be validated to be consistent for both 768 ends of the protection domain. If an inconsistency is detected then 769 an alarm SHALL be sent to the management system. The following are 770 the possible values: 772 o 3: bidirectional switching using a permanent bridge 774 o 2: bidirectional switching using a selector bridge 776 o 1: unidirectional switching using a permanent bridge 778 o 0: for future extensions 780 As described in the introduction (section 1.1) a 1+1 protection 781 architecture is characterized by the use of a permanent bridge at the 782 source node, whereas the 1:1 and 1:n protection architectures are 783 characterized by the use of a selector bridge at the source node. 785 4.2.4. Revertive (R) field 787 This field indicates that the transmitting end point is configured to 788 work in revertive mode. If there is an inconsistency between the two 789 end points, i.e. one end point is configured for revertive action and 790 the second end point is in non-revertive mode, then the management 791 system SHOULD be notified. Possible values are: 793 o 0 - non-revertive mode 795 o 1 - revertive mode 797 4.2.5. Fault path (FPath) field 799 The Fpath field indicates which path (i.e. working or protection) is 800 identified to be in a fault condition or affected by an 801 administrative command, when a fault or command is indicated by the 802 Request field to be in effect. The following are the possible 803 values: 805 o 0: indicates that the anomaly condition is on the protection path 807 o 1: indicates that the anomaly condition is on the working path 809 o 2-255: for future extensions and SHALL be ignored by this version 810 of the protocol. 812 4.2.6. Data path (Path) field 814 The Path field indicates which data is being transported on the 815 protection path. Under normal conditions, the protection path 816 (especially in 1:1 or 1:n architecture) does not need to carry any 817 user data traffic. If there is a failure/degrade condition on one of 818 the working paths, then that working path's data traffic will be 819 transported over the protection path. The following are the possible 820 values: 822 o 0: indicates that the protection path is not transporting user 823 data traffic (in 1:n architecture) or transporting redundant user 824 data traffic (in 1+1 architecture). 826 o 1: indicates that the protection path is transmitting user traffic 827 replacing the use of the working path. 829 o 2-255: for future extensions and SHALL be ignored by this version 830 of the protocol. 832 4.2.7. Additional TLV information 834 It may be necessary for future applications of the protocol to 835 include additional information for the proper processing of the 836 requests. For this purpose, we provide for optional additional 837 information to be included in the PSC payload. This information MUST 838 include a header that indicates the total length (in bytes) of the 839 additional information. 841 This information includes the following fields: 843 o TLV Length -- indicates the number of bytes included in the 844 optional TLV information. For the basic PSC protocol operation 845 described in this document this value MUST be 0. 847 o Optional TLVs -- this includes any additional information 848 formatted as TLV units. There are no TLV units defined for the 849 basic PSC operation. 851 4.3. Principles of Operation 853 In all of the following subsections, assume a protection domain 854 between LER-A and LER-Z, using paths W (working) and P (protection) 855 as shown in figure 3. 857 +-----+ //=======================\\ +-----+ 858 |LER-A|// Working Path \\|LER-Z| 859 | /| |\ | 860 | ?< | | >? | 861 | \|\\ Protection Path //|/ | 862 +-----+ \\=======================// +-----+ 864 |--------Protection Domain--------| 866 Figure 3: Protection domain 868 4.3.1. Basic operation 870 The purpose of the PSC protocol is to allow an end point of the 871 protection domain to notify its peer of the status of the domain that 872 is known at the end point and coordinate the transmission of the data 873 traffic. The current state of the end point is expressed in the 874 values of the Request field [reflecting the local requests at that 875 end point] and the Fpath field [reflecting knowledge of a blocked 876 path]. The coordination between the end points is expressed by the 877 value of the Path field [indicating where the user data traffic is 878 being transmitted]. Except during a protection switch, the value of 879 the Path field should be identical for both end points at any 880 particular time. The values of the Request and Fpath fields may not 881 be identical between the two end points. In particular it should be 882 noted that a remote message may not cause the end point to change the 883 Request field that is being transmitted while it does affect the Path 884 field (see details in the following subsections). 886 The protocol is a single-phased protocol. Single-phased implies that 887 each end point notifies its peer of a change in the operation 888 (switching to or from the protection path) and makes the switch 889 without waiting for acknowledgement. As a side-effect of using a 890 single-phased protocol, there will be a short period during state 891 transitions of one-sided triggers (e.g. operator commands, or 892 unidirectional SF) when one LER may be transporting/selecting the 893 data from one transport path while the other end point is 894 transporting/selecting from the other transport path. This should 895 become coordinated once the remote message is received and the far- 896 end LER performs the protection switching operation. 898 The following subsections will identify the messages that will be 899 transmitted by the end point in different scenarios. The messages 900 are described as REQ(FP, P) - where REQ is the value of the Request 901 field, FP is the value of the Fpath field, and P is the value of the 902 Path field. All examples assume a protection domain between LER-A 903 and LER-Z with a single working path and single protection path (as 904 shown in figure 3). Again it should be noted that when using 1:1 905 protection the data traffic will be transmitted exclusively on either 906 the protection or working path, while when using 1+1 protection the 907 traffic will be transmitted on both paths and the receiving LER 908 should select the appropriate signal based on the state. The text 909 will refer to this transmission/selection as "transport" of the data 910 traffic. For 1+1 unidirectional protection, the state of the 911 selector will only be switched in reaction to a local message. When 912 receiving a remote message, a LER that is configured for 1+1 913 unidirectional protection, will transfer to the new remote state, 914 however it will continue to select data according to the latest known 915 local state. When the LER transitions into the Normal state, the PSC 916 Control Process SHALL check the persistent state of the local 917 triggers to decide if it should further transition into a new state. 919 4.3.2. Priority of inputs 921 As noted above (in section 3.1) the PSC Control Process accepts input 922 from five local input sources. There is a definition of priority 923 between the different inputs that may be triggered locally. The list 924 of local requests in order of priority are (from highest to lowest 925 priority): 927 1. Clear (Operator command) 929 2. Lockout of protection (Operator command) 931 3. Forced switch (Operator command) 933 4. Signal Fail on protection (OAM/Control Plane/Server Indication) 935 5. Signal Fail on working (OAM/Control Plane/Server Indication) 937 6. Signal Degrade on working (OAM/Control Plane/Server Indication) 939 7. Clear Signal Fail/Degrade (OAM/Control Plane/Server Indication) 941 8. Manual switch (Operator command) 943 9. WTR expires (WTR Timer) 945 10. No request (default) 947 As was noted above, the Local request logic SHALL always select the 948 local input indicator with the highest priority as the current local 949 request, i.e. only the highest priority local input will be used to 950 affect the control logic. All local inputs with lower priority than 951 this current local request will be ignored. 953 The remote message from the far-end LER is assigned a priority just 954 below the similar local input. For example, a remote Signal Fail on 955 protection would have a priority just below a local Signal Fail on 956 protection but above a local Forced Switch input. As mentioned in 957 section 3.6.1, the state transition is determined by the higher 958 priority input between the highest priority local input and the 959 remote message. This also determines the classification of the state 960 as local or remote. The following subsections detail the transition 961 based on the current state and the higher priority of these two 962 inputs. 964 4.3.3. Operation of PSC States 966 The following sub-sections present the operation of the different 967 states defined in section 3.6. For each state we define the 968 reaction, i.e. the new state and the message to transmit, to each 969 possible input - either the highest priority local input or the PSC 970 message from the remote LER. It should be noted that the new state 971 of the protection domain is described from the point of view of the 972 LER that is reporting the state, therefore, the language of "the LER 973 goes into a state" is referring to the LER reporting that the 974 protection domain is now in this new state. If the definition states 975 to "ignore" the message, the intention is that the protection domain 976 SHALL remain in its current state and the LER SHALL continue 977 transmitting (as presented in section 4.1) the current PSC message. 979 When a LER is in a remote state, i.e. state transition in reaction to 980 a PSC message recieved from the far-end LER, and receives a new PSC 981 message from the far-end LER that indicates a contradictory state, 982 e.g. in remote Unavailable state receiving a remote FS(1,1) message, 983 then the PSC Control Logic SHALL reevaluate all inputs (both the 984 local input and the remote message) as if the LER is in the Normal 985 state. 987 4.3.3.1. Normal State 989 When the protection domain has no special condition in effect, the 990 ingress LER SHALL forward the user data along the working path, and, 991 in the case of 1+1 protection, the Permanent Bridge will bridge the 992 data to the protection path as well. The receiving LER SHALL read 993 the data from the working path. 995 When the LER transitions into the Normal state, the PSC Control 996 Process SHALL check the persistent state of the local triggers to 997 decide if it should further transition into a new state. If the 998 result of this check is a transition into a new state, the LER SHALL 999 transmit the corresponding message described in this section and 1000 SHALL use the data path corresponding to the new state. When the 1001 protection domain remains in Normal State, the end-point SHALL 1002 transmit a NR(0,0) message, indicating - Nothing to report and data 1003 traffic is being transported on the working path. 1005 When the protection domain is in Normal State the following 1006 transitions are relevant in reaction to a local input to the LER: 1008 o A local Lockout of protection input SHALL cause the LER to go into 1009 local Unavailable State and begin transmission of a LO(0,0) 1010 message. 1012 o A local Forced switch input SHALL cause the LER to go into local 1013 Protecting administrative state and begin transmission of a 1014 FS(1,1) message. 1016 o A local Signal Fail indication on the protection path SHALL cause 1017 the LER to go into local Unavailable state and begin transmission 1018 of a SF(0,0) message. 1020 o A local Signal Fail indication on the working path SHALL cause the 1021 LER to go into local Protecting failure state and begin 1022 transmission of a SF(1,1) message. 1024 o A local Manual switch input SHALL cause the LER to go into local 1025 Protecting administrative state and begin transmission of a 1026 MS(1,1) message. 1028 o All other local inputs SHALL be ignored. 1030 In Normal state, remote messages would cause the following reaction 1031 from the LER: 1033 o A remote Lockout of protection message SHALL cause the LER to go 1034 into remote Unavailable state, while continuing to transmit the 1035 NR(0,0) message. 1037 o A remote Forced switch message SHALL cause the LER to go into 1038 remote Protecting administrative state, and begin transmitting a 1039 NR(0,1) message. 1041 o A remote Signal Fail message that indicates that the failure is on 1042 the protection path SHALL cause the LER (LER-A) to go into remote 1043 Unavailable state, while continuing to transmit the NR(0,0) 1044 message. 1046 o A remote Signal Fail message that indicates that the failure is on 1047 the working path SHALL cause the LER to go into remote Protecting 1048 failure state, and transmit a NR(0,1) message. 1050 o A remote Manual switch message SHALL cause the LER to go into 1051 remote Protecting administrative state, and transmit a NR(0,1) 1052 message. 1054 o All other remote messages SHALL be ignored. 1056 4.3.3.2. Unavailable State 1058 When the protection path is unavailable - either as a result of a 1059 Lockout operator command, or as a result of a SF detected on the 1060 protection path - then the protection domain is in the unavailable 1061 state. In this state, the data traffic SHALL be transported on the 1062 working path and is not protected. When the domain is in unavailable 1063 state the PSC messages may not get through and therefore the 1064 protection is more dependent on the local inputs rather than the 1065 remote messages (that may not be received). 1067 The protection domain will exit the unavailable state and revert to 1068 the Normal state when either the operator clears the Lockout command 1069 or the protection path recovers from the signal fail or degraded 1070 situation. Both ends will continue to send the PSC messages over the 1071 protection path, as a result of this recovery. 1073 When the LER (assume LER-A) is in Unavailable State the following 1074 transitions are relevant in reaction to a local input: 1076 o A local Clear input SHALL be ignored if the LER is in remote 1077 Unavailable state. If in local Unavailable state due to a Lockout 1078 command, then the input SHALL cause the LER to go to Normal state. 1080 o A local Lockout of protection input SHALL cause the LER to remain 1081 in local Unavailable State and transmit a LO(0,0) message to the 1082 far-end LER (LER-Z). 1084 o A local Clear SF of the protection path in local Unavailable state 1085 that is due to a SF on the protection path SHALL cause the LER to 1086 go to Normal state. If the LER is in remote Unavailable state but 1087 has an active local SF condition, then the local Clear SF SHALL 1088 clear the SF local condition and the LER SHALL remain in remote 1089 Unavailable state and begin transmitting NR(0,0) messages. In all 1090 other cases the local Clear SF SHALL be ignored. 1092 o A local Forced switch SHALL be ignored by the PSC Control Logic 1093 when in Unavailable state as a result of a (local or remote) 1094 Lockout of protection. If in Unavailable state due to a SF on 1095 protection, then the FS SHALL cause the LER to go into local 1096 Protecting administrative state and begin transmitting a FS(1,1) 1097 message. It should be noted that due to the unavailability of the 1098 protection path (i.e., due to the SF condition) that this FS may 1099 not be received by the far-end until the SF condition is cleared. 1101 o A local Signal Fail on the protection path input when in local 1102 Unavailable state [by implication this is due to a local SF on 1103 protection] SHALL cause the LER to remain in local Unavailable 1104 state and transmit a SF(0,0) message. 1106 o A local Signal Fail on the working path input when in remote 1107 Unavailable state SHALL cause the LER to remain in remote 1108 Unavailable state and transmit a SF(1,0) message. 1110 o All other local inputs SHALL be ignored. 1112 If remote messages are being received over the protection path then 1113 they would have the following affect: 1115 o A remote Lockout of protection message SHALL cause the LER to 1116 remain in Unavailable state, (note that if the LER was previously 1117 in local Unavailable state due to a Signal Fail on the protection 1118 path, then it will now be in remote Unavailable state) and 1119 continue transmission of the current message (either NR(0,0) or 1120 LO(0,0) or SF(0,0)) 1122 o A remote Forced switch message SHALL be ignored by the PSC Control 1123 Logic when in Unavailable state as a result of a (local or remote) 1124 Lockout of protection. If in Unavailable state due to a SF on 1125 protection, then the FS SHALL cause the LER to go into remote 1126 Protecting administrative state and begin transmitting a SF(0,1) 1127 message. 1129 o A remote Signal Fail message that indicates that the failure is on 1130 the protection path SHALL cause the LER to remain in Unavailable 1131 state and continue transmission of the current message (either 1132 NR(0,0) or SF(0,0) or LO(0,0)). 1134 o A remote No Request, when the LER is in remote Unavailable state 1135 and there is no active local Signal Fail SHALL cause the LER to go 1136 into Normal state and continue transmission of the current 1137 message. If there is a local Signal Fail on the protection path, 1138 the LER SHALL remain in local Unavailable state and transmit a 1139 SF(0,0) message. If there is a local Signal Fail on the working 1140 path, the LER SHALL go into local Protecting Failure state and 1141 transmit a SF(1,1) message. When in local Unavailable state, the 1142 remote message SHALL be ignored. 1144 o All other remote messages SHALL be ignored. 1146 4.3.3.3. Protecting administrative state 1148 In the protecting state the user data traffic SHALL be transported on 1149 the protection path, while the working path is blocked due to an 1150 operator command, i.e. Forced Switch or Manual Switch. The 1151 difference between a local FS and local MS affects what local 1152 indicators may be received - the Local request logic will block any 1153 local SF when under the influence of a local FS, whereas the SF would 1154 override a local MS. In general, a MS will be canceled in case of 1155 either a local or remote SF or LO condition. 1157 The following describe the reaction to local input: 1159 o A local Clear SHALL be ignored if in remote Protecting 1160 administrative state. If in local Protecting administrative state 1161 then this input SHALL cause the LER to go into Normal state. 1163 o A local Lockout of protection input SHALL cause the LER to go into 1164 local Unavailable state and begin transmission of a LO(0,0) 1165 message. 1167 o A local Forced switch input SHALL cause the LER to remain in local 1168 Protecting administrative state and transmit a FS(1,1) message. 1170 o A local Signal Fail indication on the protection path SHALL cause 1171 the LER to go into local Unavailable state and begin transmission 1172 of a SF(0,0) message, if the current state is due to a (local or 1173 remote) Manual switch operator command. If the LER is in (local 1174 or remote) Protecting administrative state due to a FS situation, 1175 then the SF on protection SHALL be ignored. 1177 o A local Signal Fail indication on the working path SHALL cause the 1178 LER to go into local Protecting failure state and begin 1179 transmitting a SF(1,1) message, if the current state is due to a 1180 (local or remote) Manual switch operator command. If the LER is 1181 in remote Protecting administrative state due to a remote Forced 1182 Switch command, then this local indication SHALL cause the LER to 1183 remain in remote Protecting administrative state and transmit a 1184 SF(1,1) message. If the LER is in local Protecting administrative 1185 state due to a local Forced Switch command then this indication 1186 SHALL be ignored (i.e. the indication should have been blocked by 1187 the Local request logic). 1189 o A local Clear SF SHALL clear any local SF condition that may 1190 exist. If in remote Protecting administrative state, the LER 1191 SHALL stop transmitting the SF(x,1) message and begin transmitting 1192 an NR(0,1) message. 1194 o A local Manual switch input SHALL be ignored if in remote 1195 Protecting administrative state is due to a remote Forced switch 1196 command. If the current state is due to a (local or remote) 1197 Manual switch operator command, it SHALL cause the LER to remain 1198 in local Protecting administrative state and transmit a MS(1,1) 1199 message. 1201 o All other local inputs SHALL be ignored. 1203 While in Protecting administrative state the LER may receive and 1204 react as follows to remote PSC messages: 1206 o A remote Lockout of protection message SHALL cause the LER to go 1207 into remote Unavailable state and begin transmitting a NR(0,0) 1208 message. It should be noted that this automatically cancels the 1209 current Forced switch or Manual switch command and data traffic is 1210 reverted to the working path. 1212 o A remote Forced switch message SHALL be ignored by the PSC Process 1213 Logic if there is an active local Forced switch operator command. 1214 If the Protecting administrative state is due to a remote Forced 1215 switch message then the LER SHALL remain in remote Protecting 1216 administrative state and continue transmitting the last message. 1217 If the Protecting administrative state is due to either a local or 1218 remote Manual switch then the LER SHALL remain in remote 1219 Protecting administrative state (updating the state information 1220 with the proper relevant information) and begin transmitting a 1221 NR(0,1) message. 1223 o A remote Signal Fail message indicating a failure on the 1224 protection path SHALL cause the LER to go into remote Unavailable 1225 state and begin transmitting a NR(0,0) message, if the Protecting 1226 administrative state is due to a Manual switch command. It should 1227 be noted that this automatically cancels the current Manual switch 1228 command and data traffic is reverted to the working path. 1230 o A remote Signal Fail message indicating a failure on the working 1231 path SHALL be ignored if there is an active local Forced switch 1232 command. If the Protecting state is due to a local or remote 1233 Manual switch then the LER SHALL go to remote Protecting failure 1234 state and begin transmitting a NR(0,1) message. 1236 o A remote Manual switch message SHALL be ignored by the PSC Control 1237 Logic if in Protecting administrative state due to a local or 1238 remote Forced switch. If in Protecting administrative state due 1239 to a remote Manual switch then the LER SHALL remain in remote 1240 Protecting administrative state and continue transmitting the 1241 current message. If in local Protecting administrative state due 1242 to an active Manual switch then the LER SHALL remain in local 1243 Protecting administrative state and continue transmission of the 1244 MS(1,1) message. 1246 o A remote DNR(0,1) message SHALL be ignored if in local Protecting 1247 administrative state. If in remote Protecting administrative 1248 state then the LER SHALL go to Do-not-revert state and continue 1249 transmitting the current message. 1251 o A remote NR(0,0) message SHALL be ignored if in local Protecting 1252 administrative state. If in remote Protecting administrative 1253 state and there is no active local Signal Fail indication then the 1254 LER SHALL go to Normal state and begin transmitting a NR(0,0) 1255 message. If there is a local Signal Fail on the working path, the 1256 LER SHALL go to local Protecting failure state and begin 1257 transmitting a SF(1,1) message. 1259 o All other remote messages SHALL be ignored. 1261 4.3.3.4. Protecting failure state 1263 When the protection mechanism has been triggered and the protection 1264 domain has performed a protection switch, the domain is in the 1265 protecting failure state. In this state the normal data traffic 1266 SHALL be transported on the protection path. When an LER is in this 1267 state it implies that there was either a local SF condition or 1268 received a remote SF PSC message. The SF condition or message 1269 indicated that the failure is on the working path. 1271 This state may be overridden by the Unavailable state triggers, i.e. 1272 Lockout of Protection or SF on the protection path, or by issuing a 1273 FS operator command. This state will be cleared when the SF 1274 condition is cleared. In order to prevent flapping due to an 1275 intermittent fault, the LER SHOULD employ a Wait-to-restore timer to 1276 delay return to Normal state until the network has stabilized (see 1277 section 3.5) 1279 The following describe the reaction to local input: 1281 o A local Clear SF SHALL be ignored if in remote Protecting failure 1282 state. If in local Protecting failure state and the LER is 1283 configured for revertive behavior then this input SHALL cause the 1284 LER to go into Wait-to-restore state, start the WTR timer, and 1285 begin transmitting a WTR(0,1) message. If in local Protecting 1286 failure state and the LER is configured for non-revertive behavior 1287 then this input SHALL cause the LER to go into Do-not-revert state 1288 and begin transmitting a DNR(0,1) message. 1290 o A local Lockout of protection input SHALL cause the LER to go into 1291 Unavailable state and begin transmission of a LO(0,0) message. 1293 o A local Forced switch input SHALL cause the LER to go into 1294 Protecting administrative state and begin transmission of a 1295 FS(1,1) message. 1297 o A local Signal Fail indication on the protection path SHALL cause 1298 the LER to go into Unavailable state and begin transmission of a 1299 SF(0,0) message. 1301 o A local Signal Fail indication on the working path SHALL cause the 1302 LER to remain in local Protecting failure state and transmit a 1303 SF(1,1) message. 1305 o All other local inputs SHALL be ignored. 1307 While in Protecting failure state the LER may receive and react as 1308 follows to remote PSC messages: 1310 o A remote Lockout of protection message SHALL cause the LER to go 1311 into remote Unavailable state and if in local Protecting failure 1312 state then the LER SHALL transmit a SF(1,0) message, otherwise it 1313 SHALL transmit a NR(0,0) message. It should be noted that this 1314 may cause loss of user data since the working path is still in a 1315 failure condition. 1317 o A remote Forced switch message SHALL cause the LER go into remote 1318 Protecting administrative state and if in local Protecting failure 1319 state the LER SHALL transmit the SF(1,1) message, otherwise it 1320 SHALL transmit NR(0,1). 1322 o A remote Signal Fail message indicating a failure on the 1323 protection path SHALL cause the LER to go into remote Unavailable 1324 state and if in local Protecting failure state then the LER SHALL 1325 transmit a SF(1,0) message, otherwise it SHALL transmitting 1326 NR(0,0) message. It should be noted that this may cause loss of 1327 user data since the working path is still in a failure condition. 1329 o If in remote Protecting failure state, a remote Wait-to-Restore 1330 message SHALL cause the LER to go into remote Wait-to-Restore 1331 state and continue transmission of the current message. 1333 o If in remote Protecting failure state, a remote Do-not-revert 1334 message SHALL cause the LER to go into remote Do-not-revert state 1335 and continue transmission of the current message. 1337 o If in remote Protecting failure state, a remote NR(0,0) SHALL 1338 cause the LER to go to Normal state. 1340 o All other remote messages SHALL be ignored. 1342 4.3.3.5. Wait-to-restore state 1344 The Wait-to-Restore state is used by the PSC protocol to delay 1345 reverting to the Normal state, when recovering from a failure 1346 condition on the working path, for the period of the WTR timer to 1347 allow the recovering failure to stabilize. While in the Wait-to- 1348 Restore state the data traffic SHALL continue to be transported on 1349 the protection path. The natural transition from the Wait-to-Restore 1350 state to Normal state will occur when the WTR timer expires. 1352 When in Wait-to-Restore state the following describe the reaction to 1353 local inputs: 1355 o A local Lockout of protection command SHALL cause the LER to Stop 1356 the WTR timer, go into local Unavailable state, and begin 1357 transmitting a LO(0,0) message. 1359 o A local Forced switch command SHALL cause the LER to Stop the WTR 1360 timer, go into local Protecting administrative state, and begin 1361 transmission of a FS(1,1) message. 1363 o A local Signal Fail indication on the protection path SHALL cause 1364 the LER to Stop the WTR timer, go into local Unavailable state, 1365 and begin transmission of a SF(0,0) message. 1367 o A local Signal Fail indication on the working path SHALL cause the 1368 LER to Stop the WTR timer, go into local Protecting failure state, 1369 and begin transmission of a SF(1,1) message. 1371 o A local Manual switch input SHALL cause the LER to Stop the WTR 1372 timer, go into local Protecting administrative state and begin 1373 transmission of a MS(1,1) message. 1375 o A local WTR expires input SHALL cause the LER to remain in Wait- 1376 to-Restore state and begin transmitting a NR(0,1) message. 1378 o All other local inputs SHALL be ignored. 1380 When in Wait-to-Restore state the following describe the reaction to 1381 remote messages: 1383 o A remote Lockout of protection message SHALL cause the LER to Stop 1384 the WTR timer, go into remote Unavailable state, and begin 1385 transmitting a NR(0,0) message. 1387 o A remote Forced switch message SHALL cause the LER to Stop the WTR 1388 timer, go into remote Protecting administrative state, and begin 1389 transmission of a NR(0,1) message. 1391 o A remote Signal Fail message for the protection path SHALL cause 1392 the LER to Stop the WTR timer, go into remote Unavailable state, 1393 and begin transmission of a NR(0,0) message. 1395 o A remote Signal Fail message for the working path SHALL cause the 1396 LER to Stop the WTR timer, go into remote Protecting failure 1397 state, and begin transmission of a NR(0,1) message. 1399 o A remote Manual switch message SHALL cause the LER to Stop the WTR 1400 timer, go into remote Protecting administrative state and begin 1401 transmission of a NR(0,1) message. 1403 o If the WTR timer is running then a remote NR message SHALL be 1404 ignored. If the WTR timer is stopped then a remote NR message 1405 SHALL cause the LER to go into Normal state. 1407 o All other remote messages SHALL be ignored. 1409 4.3.3.6. Do-not-revert state 1411 Do-not-revert state is a continuation of the Protecting failure 1412 state. When the protection domain is configured for non-revertive 1413 behavior. While in Do-not-revert state, data traffic SHALL continue 1414 to be transported on the protection path until the administrator 1415 sends a command to revert to the Normal state. It should be noted 1416 that there is a fundamental difference between this state and Normal 1417 - whereas Forced Switch in Normal state actually causes a switch in 1418 the transport path used, in Do-not-revert state the Forced switch 1419 just switches the state (to Protecting administrative state) but the 1420 traffic would continue to be transported on the protection path! To 1421 revert back to Normal state the administrator SHALL issue a Lockout 1422 of protection command followed by a Clear command. 1424 When in Do-not-revert state the following describe the reaction to 1425 local input: 1427 o A local Lockout of protection command SHALL cause the LER to go 1428 into local Unavailable state and begin transmitting a LO(0,0) 1429 message. 1431 o A local Forced switch command SHALL cause the LER to go into local 1432 Protecting administrative state and begin transmission of a 1433 FS(1,1) message. 1435 o A local Signal Fail indication on the protection path SHALL cause 1436 the LER to go into local Unavailable state and begin transmission 1437 of a SF(0,0) message. 1439 o A local Signal Fail indication on the working path SHALL cause the 1440 LER to go into local Protecting failure state and begin 1441 transmission of a SF(1,1) message. 1443 o A local Manual switch input SHALL cause the LER to go into local 1444 Protecting administrative state and begin transmission of a 1445 MS(1,1) message. 1447 o All other local inputs SHALL be ignored. 1449 When in Do-not-revert state the following describe the reaction to 1450 remote messages: 1452 o A remote Lockout of protection message SHALL cause the LER to go 1453 into remote Unavailable state and begin transmitting a NR(0,0) 1454 message. 1456 o A remote Forced switch message SHALL cause the LER to go into 1457 remote Protecting administrative state and begin transmission of a 1458 NR(0,1) message. 1460 o A remote Signal Fail message for the protection path SHALL cause 1461 the LER to go into remote Unavailable state and begin transmission 1462 of a NR(0,0) message. 1464 o A remote Signal Fail message for the working path SHALL cause the 1465 LER to go into remote Protecting failure state, and begin 1466 transmission of a NR(0,1) message. 1468 o A remote Manual switch message SHALL cause the LER to go into 1469 remote Protecting administrative state and begin transmission of a 1470 NR(0,1) message. 1472 o All other remote messages SHALL be ignored. 1474 5. IANA Considerations 1476 5.1. Pseudowire Associated Channel Type 1478 In the "Pseudowire Name Spaces (PWE3) IANA" maintains the " 1479 Pseudowire Associated Channel Types Registry". 1481 IANA is requested to assign a new code point from this registry. The 1482 code point shall be assigned form the code point space that requires 1483 "IETF Review" as follows: 1485 Registry: 1487 Value Description TLV Follows Reference 1488 ----- ----------------------- ----------- --------------- 1489 0xHH Protection State no [this document] 1490 Coordination Protocol - 1491 Channel Type (PSC-CT) 1493 5.2. PSC Request Field 1495 The IANA is instructed to create and maintain a new registry within 1496 the "Multiprotocol Label Switching Architecture (MPLS)" namespace 1497 called "MPLS PSC Request Registry". All code points within this 1498 registry shall be allocated according to the "Standards Action" 1499 procedures as specified in [RFC5226]. 1501 The PSC Request Field is 4 bits and the values shall be allocated as 1502 follows: 1504 Value Description Reference 1505 ----- --------------------- --------------- 1506 0 No Request [this document] 1507 1 Do not revert [this document] 1508 2 - 3 Unassigned 1509 4 Wait to restore [this document] 1510 5 Manual switch [this document] 1511 6 Unassigned 1512 7 Signal Degrade [this document] 1513 8 - 9 Unassigned 1514 10 Signal Fail [this document] 1515 11 Unassigned 1516 12 Forced switch [this document] 1517 13 Unassigned 1518 14 Lockout of protection [this document] 1519 15 Unassigned 1521 5.3. Additional TLVs 1523 The IANA is instructed to create and maintain a new registry within 1524 the "Multiprotocol Label Switching Architecture (MPLS)" namespace 1525 called "MPLS PSC TLV Registry". All code points within this registry 1526 shall be allocated according to the "IETF Review" procedures as 1527 specified in [RFC5226]. 1529 6. Security Considerations 1531 MPLS-TP is a subset of MPLS and so builds upon many of the aspects of 1532 the security model of MPLS. MPLS networks make the assumption that 1533 it is very hard to inject traffic into a network, and equally hard to 1534 cause traffic to be directed outside the network. The control plane 1535 protocols utilize hop-by-hop security, and assume a "chain-of-trust" 1536 model such that end-to-end control plane security is not used. For 1537 more information on the generic aspects of MPLS security, see 1538 [RFC5920]. 1540 This document describes a protocol carried in the G-ACh [RFC5586], 1541 and so is dependent on the security of the G-ACh, itself. The G-ACh 1542 is a generalization of the Associated Channel defined in [RFC4385]. 1543 Thus, this document relies heavily on the security mechanisms 1544 provided for the Associated Channel and described in those two 1545 documents. 1547 A specific concern for the G-ACh is that is can be used to provide a 1548 covert channel. This problem is wider than the scope of this 1549 document and does not need to be addressed here, but it should be 1550 noted that the channel provides end-to-end connectivity and SHOULD 1551 NOT be policed by transit nodes. Thus, there is no simple way of 1552 preventing any traffic being carried between in the G-ACh consenting 1553 nodes. 1555 A good discussion of the data plane security of an associated channel 1556 may be found in [RFC5085]. That document also describes some 1557 mitigation techniques. 1559 It should be noted that the G-ACh is essentially connection-oriented 1560 so injection or modification of control messages specified in this 1561 document require the subversion of a transit node. Such subversion 1562 is generally considered hard in MPLS networks, and impossible to 1563 protect against at the protocol level. Management level techniques 1564 are more appropriate. 1566 However, a new concern for this document is the accidental corruption 1567 of messages (through faulty implementations, or random corruption). 1568 The main concern is around the Request, FPath and Path fields as a 1569 change to these fields would change the behavior of the peer end 1570 point. Although this document does not define a way to avoid a 1571 change in network behavior upon receipt of a message indicating a 1572 change in protection status, the transition between states will 1573 converge on a known and stable behavior in the face of messages which 1574 do not match reality. 1576 7. Acknowledgements 1578 The authors would like to thank all members of the teams (the Joint 1579 Working Team, the MPLS Interoperability Design Team in IETF and the 1580 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 1581 specification of MPLS Transport Profile. 1583 8. References 1585 8.1. Normative References 1587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1588 Requirement Levels", BCP 14, RFC 2119, March 1997. 1590 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1591 and S. Ueno, "Requirements of an MPLS Transport Profile", 1592 RFC 5654, September 2009. 1594 [RFC5586] Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and 1595 D. Ward, "MPLS Generic Associated Channel", RFC 5586, 1596 May 2009. 1598 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1599 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1600 Use over an MPLS PSN", RFC 4385, Feb 2006. 1602 8.2. Informative References 1604 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1605 Label Switching Architecture", RFC 3031, Jan 2001. 1607 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1608 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1609 Encoding", RFC 3032, Jan 2001. 1611 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1612 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1613 October 2009. 1615 [RFC5920] Fang, Luyuan., "Security Framework for MPLS and GMPLS 1616 Networks", RFC 5920, July 2010. 1618 [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge 1619 (PWE3) Architecture", RFC 3985, March 2005. 1621 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1622 Connectivity Verification (VCCV): A Control Channel for 1623 Pseudowires", RFC 5085, December 2007. 1625 [TPFwk] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1626 Berger, "A Framework for MPLS in Transport Networks", 1627 RFC 5921, July 2010. 1629 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery Terminology for 1630 Generalized Multi-Protocol Label Switching", RFC 4427, 1631 Mar 2006. 1633 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1634 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1635 May 2008. 1637 [SurvivFwk] 1638 Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol 1639 Label Switching Transport Profile Survivability 1640 Framework", ID draft-ietf-mpls-tp-survive-fwk-06.txt, 1641 June 2010. 1643 [RFC4872] Lang, J., Papadimitriou, D., and Y. Rekhter, "RSVP-TE 1644 Extensions in Support of End-to-End Generalized Multi- 1645 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 1646 May 2007. 1648 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1649 "GMPLS Segment Recovery", RFC 4873, May 2007. 1651 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1652 (GMPLS) Architecture", RFC 3945, Oct 2004. 1654 Appendix A. PSC state machine tables 1656 The PSC state machine is described in section 4.3.3. This appendix 1657 provides the same information but in tabular format. In the event of 1658 a mismatch between these tables and the text in section 4.3.3, the 1659 text is authoritative. Note that this appendix is intended to be a 1660 functional description, not an implementation specification. 1662 For the sake of clarity of the table the six states listed in the 1663 text are split into thirteen states. The logic of the split is to 1664 differentiate between the different cases given in the conditional 1665 statements in the descriptions of each state in the text. In 1666 addition, the remote and local states were split for the Unavailable, 1667 Protecting failure, and Protecting administrative states. 1669 There is only one table for the PSC state machine, but it is broken 1670 into two parts for space reasons. The first part lists the thirteen 1671 possible states, the eight possible local inputs (that is, inputs 1672 which are generated by the node in question) and the action taken 1673 when a given input is received when the node is in a particular 1674 state. The second part of the table lists the thirteen possible 1675 states and the eight remote inputs (inputs which come from a node 1676 other than the one executing the state machine). 1678 There are thirteen rows in the table, headers notwithstanding. These 1679 rows are the thirteen possible extended states in the state machine. 1681 The text in the first column is the current state. Those states 1682 which have both source and cause are formatted as State:Cause:Source. 1683 For example, the string UA:LO:L indicates that the current state is 1684 'Unavailable', that the cause of the current state is a Lockoutof 1685 protection that was a Local input. In contrast, the state N simply 1686 is Normal; there is no need to track the cause for entry into Normal 1687 state. 1689 The thirteen extended states, as they appear in the table, are: 1691 N Normal state 1692 UA:LO:L Unavailable state due to local Lockout 1693 UA:P:L Unavailable state due to local SF on protection path 1694 UA:LO:R Unavailable state due to remote Lockout message 1695 UA:P:R Unavailable state due to remote SF message on protection path 1696 PF:W:L Protecting failure state due to local SF on working path 1697 PF:W:R Protecting failure state due to remote SF message on working 1698 path 1699 PA:F:L Protecting administrative state due to local FS operator 1700 command 1701 PA:M:L Protecting administrative state due to local MS operator 1702 command 1703 PA:F:R Protecting administrative state due to remote FS message 1704 PA:M:R Protecting administrative state due to remote MS message 1705 WTR Wait-to-restore state 1706 DNR Do-not-revert state 1708 Each state corresponds to the transmission of a particular set of 1709 Request, FPath and Path bits. The table below lists the message that 1710 is generally sent in each particular state. If the message to be 1711 sent in a particular state deviates from the table below, it is noted 1712 in the footnotes to the state-machine table. 1714 State REQ(FP,P) 1715 ------- --------- 1716 N NR(0,0) 1717 UA:LO:L LO(0,0) 1718 UA:P:L SF(0,0) 1719 UA:LO:R NR(0,0) 1720 UA:P:R NR(0,0) 1721 PF:W:L SF(1,1) 1722 PF:W:R NR(0,1) 1723 PA:F:L FS(1,1) 1724 PA:M:L MS(1,1) 1725 PA:F:R NR(0,1) 1726 PA:M:R NR(0,1) 1727 WTR WTR(0,1) 1728 DNR DNR(0,1) 1730 The top row in each table is the list of possible inputs. The local 1731 inputs are: 1733 NR No Request 1734 OC Operator Clear 1735 LO Lockout of protection 1736 SF-P Signal Fail on protection path 1737 SF-W Signal Fail on working path 1738 FS Forced Switch 1739 SFc Clear Signal Fail 1740 MS Manual Switch 1741 WTRExp WTR Expired 1743 and the remote inputs are: 1745 LO remote LO message 1746 SF-P remote SF message indicating protection path 1747 SF-W remote SF message indicating working path 1748 FS remote FS message 1749 MS remote MS message 1750 WTR remote WTR message 1751 DNR remote DNR message 1752 NR remote NR message 1754 Section 4.3.3 refers to some states as 'remote' and some as 'local'. 1755 By definition, all states listed in the table of local sources are 1756 local states, and all states listed in the table of remote sources 1757 are remote states. For example, section 4.3.3.1 says "A local 1758 Lockout of protection input SHALL cause the LER to go into local 1759 Unavailable State". As the trigger for this state change is a local 1760 one, 'local Unavailable State' is by definition displayed in the 1761 table of local sources. Similarly, "A remote Lockout of protection 1762 message SHALL cause the LER to go into remote Unavailable state" 1763 means that the state represented in the Unavailable rows in the table 1764 of remote sources is by definition a remote Unavailable state. 1766 Each cell in the table below contains either a state, a footnote, or 1767 the letter 'i'. 'i' stands for Ignore, and is an indication to 1768 continue with the current behavior. See section 4.3.3. The 1769 footnotes are listed below the table. 1771 Part 1: Local input state machine 1773 | OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp 1774 --------+-----+-------+------+------+------+------+------+------- 1775 N | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i 1776 UA:LO:L | N | i | i | i | i | i | i | i 1777 UA:P:L | i |UA:LO:L| i |PA:F:L| i | [5] | i | i 1778 UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i 1779 UA:P:R | i |UA:LO:L|UA:P:L|PA:F:L| [3] | [6] | i | i 1780 PF:W:L | i |UA:LO:L|UA:P:L|PA:F:L| i | [7] | i | i 1781 PF:W:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i 1782 PA:F:L | N |UA:LO:L| i | i | i | i | i | i 1783 PA:M:L | N |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i 1784 PA:F:R | i |UA:LO:L| i |PA:F:L| [4] | [8] | i | i 1785 PA:M:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i 1786 WTR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| [9] 1787 DNR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i 1789 Part 2: Remote messages state machine 1791 | LO | SF-P | FS | SF-W | MS | WTR | DNR | NR 1792 --------+-------+------+------+------+------+------+------+------ 1793 N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i 1794 UA:LO:L | i | i | i | i | i | i | i | i 1795 UA:P:L | [10] | i | i |PF:W:R| i | i | i | i 1796 UA:LO:R | i | i | i | i | i | i | i | [16] 1797 UA:P:R |UA:LO:R| i | i |PF:W:R| i | i | i | [16] 1798 PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i 1799 PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N 1800 PA:F:L |UA:LO:R| i | i | i | i | i | i | i 1801 PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i 1802 PA:F:R |UA:LO:R| i | i | i | i | i | i | [17] 1803 PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | N 1804 WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [18] 1805 DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i 1807 The following are the footnotes for the table: 1809 [1] Remain in the current state (UA:LO:R) and transmit SF(0,0) 1811 [2] Remain in the current state (UA:LO:R) and transmit SF(1,0) 1813 [3] Remain in the current state (UA:P:R) and transmit SF(1,0) 1815 [4] Remain in the current state (PA:F:R) and transmit SF(1,1) 1817 [5] If the SF being cleared is SF-P, Transition to N. If it's SF-W, 1818 ignore the clear. 1820 [6] Remain in current state (UA:x:R), if the SFc corresponds to a 1821 previous SF then begin transmitting NR(0,0). 1823 [7] If domain configured for revertive behavior transition to WTR, 1824 else transition to DNR 1826 [8] Remain in PA:F:R and transmit NR(0,1) 1828 [9] Remain in WTR, send NR(0,1) 1830 [10] Transition to UA:LO:R continue sending SF(0,0) 1832 [11] Transition to UA:LO:R and send SF(1,0) 1834 [12] Transition to UA and send SF(1,0) 1836 [13] Transition to PF:W:R and send NR(0,1) 1838 [14] Transition to WTR state and continue to send the current 1839 message. 1841 [15] Transition to DNR state and continue to send the current 1842 message. 1844 [16] If the local input is SF-P then transition to UA:P:L. If the 1845 local input is SF-W then transition to PF:W:L. Else - transition to N 1846 state and continue to send the current message. 1848 [17] If the local input is SF-W then transition to PF:W:L. Else - 1849 transition to N state and continue to send the current message. 1851 [18] If the receiving LER's WTR timer is running, maintain current 1852 state and message. If the WTR timer is stopped, transition to N. 1854 Appendix B. Exercising the protection domain 1856 There is a requirement in [RFC5654] (number 84) that discusses a 1857 requirement to verify that the protection path is viable. While the 1858 PSC protocol does not define a specific operation for this 1859 functionality, it is possible to perform this operation by combining 1860 operations of the PSC and other OAM functionalities. One such 1861 possible combination would be to issue a Lockout of Protection 1862 operation and then use the OAM function for diagnostic testing of the 1863 protection path. Similarly, to test the paths when the working path 1864 is not active would involve performing a Forced Switch to protection 1865 and then perform the diagnostic function on either the working or 1866 protection path. 1868 Authors' Addresses 1870 Stewart Bryant 1871 Cisco 1872 United Kingdom 1874 Email: stbryant@cisco.com 1876 Eric Osborne 1877 Cisco 1878 United States 1880 Email: eosborne@cisco.com 1882 Nurit Sprecher 1883 Nokia Siemens Networks 1884 3 Hanagar St. Neve Ne'eman B 1885 Hod Hasharon, 45241 1886 Israel 1888 Email: nurit.sprecher@nsn.com 1890 Annamaria Fulignoli (editor) 1891 Ericsson 1892 Italy 1894 Email: annamaria.fulignoli@ericsson.com 1895 Yaacov Weingarten (editor) 1896 Nokia Siemens Networks 1897 3 Hanagar St. Neve Ne'eman B 1898 Hod Hasharon, 45241 1899 Israel 1901 Email: yaacov.weingarten@nsn.com