idnits 2.17.00 (12 Aug 2021) /tmp/idnits48711/draft-pan-shared-mesh-protection-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5654]), 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 date (October 15, 2012) is 3498 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: '6' on line 552 == Unused Reference: 'RFC4447' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC6370' is defined on line 744, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pan 3 Internet-Draft R. Rao 4 Intended status: Standards Track B. Lu 5 Expires: April 18, 2013 (Infinera) 6 L. Fang 7 (Cisco) 8 A. Malis 9 (Verizon) 10 F. Zhang 11 S. Aldrin 12 (Huawei) 13 F. Zhang 14 (ZTE) 15 S. Singamsetty 16 (Cisco) 17 October 15, 2012 19 Supporting Shared Mesh Protection in MPLS-TP Networks 20 draft-pan-shared-mesh-protection-05.txt 22 Abstract 24 Shared mesh protection is a common protection and recovery mechanism 25 in transport networks, where multiple paths can share the same set of 26 network resources for protection purposes. 28 In the context of MPLS-TP, it has been explicitly requested as a part 29 of the overall solution (Req. 67, 68 and 69 in RFC5654 [RFC5654]). 31 It's important to note that each MPLS-TP LSP may be associated with 32 transport network resources. In event of network failure, it may 33 require explicit activation on the protecting paths before switching 34 user traffic over. 36 In this memo, we define a lightweight signaling mechanism for 37 protecting path activation in shared mesh protection-enabled MPLS-TP 38 networks. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on April 18, 2013. 63 Copyright Notice 65 Copyright (c) 2012 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 83 3.1. Protection Switching . . . . . . . . . . . . . . . . . . . 7 84 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . . 8 85 4. SMP Message and Action Definition . . . . . . . . . . . . . . 9 86 4.1. Protection Switching Control (PSC) Logic . . . . . . . . . 9 87 4.2. SMP Action Types . . . . . . . . . . . . . . . . . . . . . 11 88 4.3. PSC Signal to SMP Action Mapping . . . . . . . . . . . . . 11 89 5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12 90 5.1. Message Encapsulation . . . . . . . . . . . . . . . . . . 13 91 5.2. Reliable Messaging . . . . . . . . . . . . . . . . . . . . 14 92 5.3. Message Scoping . . . . . . . . . . . . . . . . . . . . . 14 93 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 15 94 6.1. Enable a Protecting Path . . . . . . . . . . . . . . . . . 15 95 6.2. Disable a Protecting Path . . . . . . . . . . . . . . . . 15 96 6.3. Get Protecting Path Status . . . . . . . . . . . . . . . . 16 97 6.4. Preemption . . . . . . . . . . . . . . . . . . . . . . . . 16 98 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 16 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 Shared mesh protection (SMP) is a common traffic protection mechanism 109 in transport networks, where multiple paths can share the same set of 110 network resources for protection purposes. 112 In the context of MPLS-TP, it has been explicitly requested as a part 113 of the overall solution (Req. 67, 68 and 69 in RFC5654 [RFC5654]).Its 114 operation has been further outlined in Section 4.7.6 of MPLS-TP 115 Survivability Framework. 117 It's important to note that each MPLS-TP LSP may be associated with 118 transport network resources. In event of network failure, it may 119 require explicit activation on the protecting paths before switching 120 user traffic over. 122 In this memo, we define a lightweight signaling mechanism for 123 protecting path activation in shared mesh protection-enabled MPLS-TP 124 networks. 126 Here are the key design goals: 128 1. Fast: The protocol is to activate the previously configured 129 protecting paths in a timely fashion, with minimal transport and 130 processing overhead. The goal is to support 50msec end-to-end 131 traffic switch-over in large transport networks. 133 2. Reliable message delivery: Activation and deactivation operation 134 have serious impact on user traffic. This requires the protocol 135 to adapt a low-overhead reliable messaging mechanism. The 136 activation messages may either traverse through a "trusted" 137 transport channel, or require some level of built-in reliability 138 mechanism. 140 3. Modular: Depending on deployment scenarios, the signaling may 141 need to support functions such as preemption, resource re- 142 allocation and bi-directional activation in a modular fashion. 144 2. Acronyms 146 This draft uses the following acronyms: 148 o SMP: Shared Mesh Protection 150 o LO: Lockout of protection 151 o DNR: Do not revert 153 o FS: Forced Switch 155 o SF: Signal Fail 157 o SD: Signal Degrade 159 o MS: Manual Switch 161 o NR: No Request 163 o WTR: Wait-to-Restore 165 o EXER: Exercise 167 o RR: Reverse Request 169 o ACK: Acknowledgement 171 o NACK: Negative Acknowledgement 173 o G-ACh: Generic Associated Channel 175 o MPLS-TP Transport Profile for MPLS 177 3. Solution Overview 179 In this section, we describe the SMP operation in the context of 180 MPLS-TP networks, and outline some of the relevant definitions. 182 We refer to the figure below for illustration: 184 ----- B ------- C ---- 185 / \ 186 / \ 187 A D 188 \ / 189 \ / 190 ==== E === F === G === 191 / \ 192 / \ 193 H K 194 \ / 195 \ / 196 ----- I ------- J ---- 198 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 200 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 202 The links between E, F and G are shared by both protecting paths. 203 All paths are established via MPLS-TP control plane prior to network 204 failure. 206 All paths are assumed to be bi-directional. An edge node is denoted 207 as a headend or tailend for a particular path in accordance to the 208 path setup direction. 210 Initially, the operators setup both working and protecting paths. 211 During setup, the operators specify the network resources for each 212 path. The working path X and Y will configure the appropriate 213 resources on the intermediate nodes, however, the protecting paths, 214 X' and Y', will reserve the resources on the nodes, but won't occupy 215 them. 217 Depending on network planning requirements (such as SRLG), X' and Y' 218 may share the same set of resources on node E, F and G. The resource 219 assignment is a part of the control-plane CAC operation taking place 220 on each node. 222 At some time, link B-C is cut. Node A will detect the outage, and 223 initiate activation messages to bring up the protecting path X'. The 224 intermediate nodes, E, F and G will program the switch fabric and 225 configure the appropriate resources. Upon the completion of the 226 activation, A will switch the user traffic to X'. 228 The operation may have extra caveat: 230 1. Preemption: Protecting paths X' and Y' may share the same 231 resources on node E, F or G due to resource constraints. Y' has 232 higher priority than that of X'. In the previous example, X' is 233 up and running. When there is a link outage on I-J, H can 234 activate its protecting path Y'. On E, F or G, Y' can take over 235 the resources from X' for its own traffic. The behavior is 236 acceptable with the condition that A should be notified about the 237 preemption action. 239 2. Over-subscription (1:N): A unit of network resource may be 240 reserved by one or multiple protecting paths. In the example, 241 the network resources on E-F and F-G are shared by two protecting 242 paths, X' and Y'. In deployment, the over-subscription ratio is 243 an important factor on network resource utilization. 245 3.1. Protection Switching 247 The entire activation and switch-over operation need to be within the 248 range of milliseconds to meet customer's expectation. This section 249 illustrates how this may be achieved on MPLS-TP-enabled transport 250 switches. Note that this is for illustration of protection switching 251 operation, not mandating the implementation itself. 253 The diagram below illustrates the operation: 255 +---------------+ 256 Control | MPLS-TP | Control 257 <=== Signaling ====| Control Plane |=== Signaling ===> 258 +---------------+ 259 / \ 260 / \ (MPLS label assignment) 261 / \ 262 / \ 263 +-------+ +------+ +-------+ 264 Activation |Line | |Switch| |Line | Activation 265 <=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===> 266 +-------+ +------+ +-------+ 268 Typical MPLS-TP user flows (or, LSP's) are bi-directional, and setup 269 as co-routed or associated tunnels, with a MPLS label for each of the 270 upstream and downstream traffic. On this particular type of 271 transport switch, the control-plane can download the labels to the 272 line modules. Subsequently, the line module will maintain a label 273 lookup table on all working and protecting paths. 275 Upon the detection of network failure, the headend nodes will 276 transmit activation messages along the MPLS LSP's. When receiving 277 the messages, the line modules can locate the associated protecting 278 path from the label lookup table, and perform activation procedure by 279 programming the switching fabric directly. Upon its success, the 280 line module will swap the label, and forward the activation messages 281 to the next hop. 283 In summary, the activation procedure involves efficient path lookup 284 and switch fabric re-programming. 286 To achieve the tight end-to-end switch-over budget, it's possible to 287 implement the entire activation procedure with hardware-assistance 288 (such as in FPGA or ASIC). The activation messages are encapsulated 289 with a MPLS-TP Generic Associated Channel Header (GACH) [RFC5586]. 290 Detailed message encoding is explained in later sections. 292 3.2. Operation Overview 294 To achieve high performance, the activation procedure is designed to 295 be simple and straightforward on the network nodes. 297 In this section, we describe the activation procedure using the same 298 figure shown before: 300 ----- B ------- C ---- 301 / \ 302 / \ 303 A D 304 \ / 305 \ / 306 ==== E === F === G === 307 / \ 308 / \ 309 H K 310 \ / 311 \ / 312 ----- I ------- J ---- 314 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 316 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 318 Upon the detection of working path failure, the edge nodes, A, D, H 319 and K may trigger the activation messages to activate the protecting 320 paths, and redirect user traffic immediately after. 322 We assume that there is a consistent definition of priority levels 323 among the paths throughout the network. At activation time, each 324 node may rely on the priority levels to potentially preempt other 325 paths. 327 When the nodes detect path preemption on a particular node, they 328 should inform all relevant nodes to free the resources by sending out 329 notification messages. Upon the reception of notification messages, 330 the relevant nodes will send out de-activation messages. 332 To optimize traffic protection and resource management, each headend 333 may periodically poll the protecting paths about resource 334 availability. The intermediate nodes have the option to inform the 335 current resource utilization. 337 Note that, upon the detection of a working path failure, both headend 338 and tailend may initiate the activation simultaneously (known as bi- 339 directional activation). This may expedite the activation time. 340 However, both headend and tailend nodes need to coordinate the order 341 of protecting paths for activation, since there may be multiple 342 protecting paths for each working path (i.e., 1:N protection). For 343 clarity, we will describe the operation from headend in the memo. 344 The tailend operation will be available in the subsequent revisions. 346 4. SMP Message and Action Definition 348 4.1. Protection Switching Control (PSC) Logic 350 Protection switching processes the local triggers described in 351 requirements 74-79 of [RFC5654] together with inputs received from 352 the tailend node. Based on these inputs the headend will take SMP 353 actions, and transmit different protocol messages. 355 Here, we reuse the switching control logic described in MPLS Linear 356 Protection, with the following logical decomposition at headend node: 358 Server Indication Control Plane Indication 359 -----------------+ +------------- 360 Operator Command | | OAM Indication 361 ----------------+ | | +--------------- 362 | | | | 363 V V V V 364 +---------------+ +-------+ 365 | Local Request |<--------| WTR | 366 | logic |WTR Exps | Timer | 367 +---------------+ +-------+ 368 | ^ 369 Highest local|request | 370 V | Start/Stop 371 +-----------------+ | 372 Remote PSC | PSC Control |------------+ 373 ------------>| logic | 374 Request +-----------------+ 375 | 376 | Action +------------+ 377 +---------------->| Message | 378 | Generator | 379 +------------+ 380 | 381 Output PSC | Message 382 V 384 The Local Request logic unit accepts the triggers from the OAM, 385 external operator commands, from the local control plane (when 386 present), and the Wait-to-Restore timer. By considering all of these 387 local request sources it determines the highest priority local 388 request. This high-priority request is passed to the PSC Control 389 logic, that will cross-check this local request with the information 390 received from the tailend node. The PSC Control logic uses this 391 input to determine what actions need to be taken, e.g. local actions 392 at the headend, or what message should be sent to the tailend node. 394 Specifically, the signals could be the following: 396 o Clear - if the operator cancels an active local administrative 397 command, i.e. LO/FS/MS. 399 o Lockout of Protection (LO) - if the operator requested to prevent 400 switching data traffic to the protection path, for any purpose. 402 o Signal Fail (SF) - if any of the Server Layer, Control plane, or 403 OAM indications signaled a failure condition on either the 404 protection path or one of the working paths. 406 o Signal Degrade (SD) - if any of the Server Layer, Control plane, 407 or OAM indications signaled a degraded transmission condition on 408 either the protection path or one of the working paths. 410 o Forced Switch (FS) - if the operator requested that traffic be 411 switched from one of the working paths to the protection path, 413 o Manual Switch (MS) - if the operator requested that traffic is 414 switched from the working path to the protection path. This is 415 only relevant if there is no currently active fault condition or 416 Operator command. 418 o WTR Expires - generated by the WTR timer completing its period. 419 If none of the input sources have generated any input then the 420 request logic should generate a No Request (NR) request. 422 In addition to the local requests, the PSC Control Logic SHALL accept 423 PSC messages from the tailend node of the transport path. Remote 424 messages indicate the status of the transport path from the viewpoint 425 of the tailend nodes. The remote requests may include remote LO, SF, 426 SD, FS, MS, WTR and NR. 428 Much of the signal definition is further described in ITU G.709 and 429 G.873.1. 431 4.2. SMP Action Types 433 As shown in the previous section, SMP requires four actions types 434 throughout the operation: 436 o ACTIVATION: This action is triggered by the head-end (or tail-end) 437 to activate a protecting connection. The intermediate nodes need 438 to propagate this towards the other end of the protecting 439 connection. 441 o DE-ACTIVATION: This action is used to de-activate a particular 442 protecting connection. This can be originated by one end of a 443 protecting connection (i.e. head-end, or tail-end). The 444 intermediate nodes need to propagate this towards the other end of 445 the protecting connection. 447 o QUERY: This action is used when an operator decides to query a 448 particular protecting connection. 450 o NOTIFICATION: SMP operation requires the coordination between 451 nodes. The coordination takes places in two occasions: 453 1. The activation/de-activation is initiated at the headend 454 (tailend) nodes. To avoid potential mis-connection, the user 455 traffic cannot be switched on to the protecting connection 456 until the reception of an acknowledgement from the tailend 457 (headend) nodes. 459 2. If an intermediate node cannot process the activation 460 requests, due to lack of resources or preemption levels, it 461 needs to report the failure to the request originators. 463 It is conceivable that this message can be used to report the 464 location of the fault, with respect to a protecting connection so 465 that the head-end may use this information as one of the criteria for 466 restoring the working transport entity. The fault location could be 467 used by the head-end node to select among a list of possible 468 protecting connections associated with the working connection (i.e. 469 avoid the faulty location), or to determine that none of the 470 provisioned protecting connections is usable at the time the failure 471 is reported and then fallback to restoring the working connection. 473 4.3. PSC Signal to SMP Action Mapping 475 In SMP operation, there is the action-signal mapping: 477 o Activation action: FS, SF, SD, MS 478 o De-activation action: NR 480 o Query action: EXER 482 o Notification action: ACK, NACK (see next section) 484 5. Protocol Definition 486 Each SMP message has the following format: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 |Ver|Request|Rsv|R| Reserved | Status | Seq | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 o Version: 1 496 o Request: 498 * 1111b: Lockout of Protection (LO) 500 * 1110b: Forced Switch (FS). This triggers activation 502 * 1100b: Signal Fail (SF). This triggers activation 504 * 1011b: Acknowledgement (ACK). This is to acknowledge a 505 successful activation/de-activation request 507 * 1010b: Signal Degrade (SD). This triggers activation 509 * 1001b: Negative Acknowledgement (NACK). This is to report 510 failure in activation/de-activation process. 512 * 1000b: Manual Switch (MS). This triggers activation 514 * 0110b: Wait-to-Restore (WTR). Used for revertive switching 516 * 0100b: Exercise (EXER). Triggers SMP query 518 * 0001b: Do Not Revert (DNR). Used for revertive switching 520 * 0000b: No Request (NR). This triggers de-activation 522 o R: Revertive field 524 * 0: non-revertive mode 526 * 1: revertive mode 528 o Rsv/Reserved: This field is reserved for future use 530 o Status: this informs the status of the AMP activation. This field 531 is only relevant with ACK and NACK requests. Specifically, the 532 Status Code has the following encoding value and definition: 534 * 1: end-to-end ack 536 * 2: hop-to-hop ack 538 * 3: no such path 540 * 4: no more resource for the path 542 * 5: preempted by another path 544 * 6: system failure 546 * 7: shared resource has been taken by other paths 548 o Seq: This uniquely identifies a particular message. This field is 549 defined to support reliable message delivery 551 Note that the message format and naming convention are very similar 552 to that of MPLS linear protection [6] and ITU G.873.1. 554 5.1. Message Encapsulation 556 SMP messages use MPLS labels to identify the paths. Further, the 557 messages are encapsulated in GAL/GACH: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | MPLS Label stack | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | GAL | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 |0 0 0 1|Version| Reserved | Activation Channel Type | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Activation Message Payload | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 GAL is described in [RFC5586]. Activation Channel Type is the GACH 572 channel number assigned to the protocol. This uniquely identifies 573 the activation messages. 575 Specifically, the messages have the following message format: 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Label | Exp |S| TTL | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Label (13) | Exp |S| TTL | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |0 0 0 1|Version| Reserved | Activation Channel Type | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |Ver|Request|Rsv|R| Reserved | Status | Seq | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 5.2. Reliable Messaging 591 The activation procedure adapts a simple two-way handshake reliable 592 messaging. Each node maintains a sequence number generator. Each 593 new sending message will have a new sequence number. After sending a 594 message, the node will wait for a response with the same sequence 595 number. 597 Specifically, upon the generation of activation, de-activation, query 598 and notification messages, the message sender expects to receive 599 acknowledgement in reply with same sequence number. 601 If a sender is not getting the reply within a time interval, it will 602 retransmit the same message with a new sequence number, and starts to 603 wait again. After multiple retries (by default, 3), the sender will 604 declare activation failure, and alarm the operators for further 605 service. 607 5.3. Message Scoping 609 Activation signaling uses MPLS label TTL to control how far the 610 message would traverse. Here are the processing rules on each 611 intermediate node: 613 o On receive, if the message has label TTL = 0, the node must drop 614 the packet without further processing 616 o The receiving node must always decrement the label TTL value by 617 one. If TTL = 0 after the decrement, the node must process the 618 message. Otherwise, the node must forward the message without 619 further processing (unless, of course, the node is headend or 620 tailend) 622 o On transmission, the node will adjust the TTL value. For hop-by- 623 hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default. 625 6. Processing Rules 627 6.1. Enable a Protecting Path 629 Upon the detection of network failure (SF/SD/FS) on a working path, 630 the headend node identifies the corresponding MPLS-TP label and 631 initiates the protection switching by sending an activation message. 633 The activation messages always use MPLS label TTL = 1 to force hop- 634 by-hop process. Upon reception, a next-hop node will locate the 635 corresponding path and activate the path. 637 If the activation message is received on an intermediate node, due to 638 label TTL expiry, the message is processed and then propagated to the 639 next hop of the MPLS TP LSP, by setting the MPLS TP label TTL = 1. 641 The headend node will declare the success of the activation only when 642 it gets a positive reply from the tailend node. This requires that 643 the tailend nodes must reply the messages with ACK to the headend 644 nodes in all cases. 646 If the headend node is not receiving the acknowledgement within a 647 time internal, it will retransmit another activation message with a 648 different Seq number. 650 If the headend node is not receiving a positive reply within a longer 651 time interval, it will declare activation failure. 653 If an intermediate node cannot activate a protecting path, it will 654 reply a message with NACK to report failure. When the headend node 655 receives the message for failure, it must initiate the de-activation 656 messages to clean up networks resources on all the relevant nodes on 657 the path. 659 6.2. Disable a Protecting Path 661 The headend removes the network resources on a path by sending the 662 de-activation messages. 664 In the message, the MPLS label represents the path to be de- 665 activated. The MPLS TTL is one to force hop-by-hop processing. 667 Upon reception, a node will de-activate the path, by freeing the 668 resources from the data-plane. 670 As a part of the clean-up procedure, each de-activation message must 671 traverse through and be processed on all the nodes of the 672 corresponding path. When the de-activation message reaches to the 673 tailend node, the tailend is required to reply with an 674 acknowledgement message to the headend. 676 The de-activation process is complete when the headend receives the 677 corresponding acknowledgement message from the tailend. 679 6.3. Get Protecting Path Status 681 The operators have the option to trigger the query messages from the 682 headend to check on the protecting path periodically or on-demand. 683 The process procedure on each node is very similar to that of the 684 activation messages on the intermediate nodes, except the query 685 messages should not trigger any network resource re-programming. 686 Upon reception, the node will check the availability of resources. 688 If the resource is no longer available, the node will reply an NACK 689 with error conditions. 691 6.4. Preemption 693 The preemption operation typically takes place when processing an 694 activation message. If the activating network resources have been 695 used by another path and carrying user traffic, the node needs to 696 compare the priority levels. 698 If the existing path has higher priority, the node needs to reject 699 the activation request by sending an ACK to the corresponding headend 700 to inform the unavailability of network resources. 702 If the new path has higher priority, the node will reallocate the 703 resource to the new path, and send an ACK to old path's headend node 704 to inform about the preemption. 706 7. Security Consideration 708 The protection activation takes place in a controlled networking 709 environment. Nevertheless, it is expected that the edge nodes will 710 encapsulate and transport external traffic into separated tunnels, 711 and the intermediate nodes will never have to process them. 713 8. IANA Considerations 715 Activation messages are encapsulated in MPLS-TP with a specific GACH 716 channel type that needs to be assigned by IANA. 718 9. Acknowledgments 720 Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and 721 Deborah Brungard for detailed feedback on the earlier work, and the 722 guidance and recommendation for this proposal. 724 We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague, Ann 725 Gui and Tony Jorgenson for discussion on network operation, 726 feasibility and implementation methodology. 728 During ITU-T SG15 Interim meeting in May 2011, we have had long 729 discussion with the G.SMP contributors, in particular Fatai Zhang, 730 Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback 731 and corrections. 733 10. References 735 10.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997. 740 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 741 Heron, "Pseudowire Setup and Maintenance Using the Label 742 Distribution Protocol (LDP)", RFC 4447, April 2006. 744 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 745 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 747 10.2. Informative References 749 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 750 Associated Channel", RFC 5586, June 2009. 752 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 753 and S. Ueno, "Requirements of an MPLS Transport Profile", 754 RFC 5654, September 2009. 756 Authors' Addresses 758 Ping Pan 759 (Infinera) 761 Email: ppan@infinera.com 763 Rajan Rao 764 (Infinera) 766 Email: rrao@infinera.com 768 Biao Lu 769 (Infinera) 771 Email: blu@infinera.com 773 Luyuan Fang 774 (Cisco) 776 Email: lufang@cisco.com 778 Andrew G. Malis 779 (Verizon) 781 Email: andrew.g.malis@verizon.com 783 Fatai Zhang 784 (Huawei) 786 Email: zhangfatai@huawei.com 787 Sam Aldrin 788 (Huawei) 790 Email: sam.aldrin@huawei.com 792 Fei Zhang 793 (ZTE) 795 Email: zhang.fei3@zte.com.cn 797 Sri Mohana Satya Srinivas Singamsetty 798 (Cisco) 800 Email: srsingam@cisco.com