idnits 2.17.00 (12 Aug 2021) /tmp/idnits22284/draft-pan-shared-mesh-protection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2011) is 3855 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: 'RFC2119' on line 168 == Unused Reference: '4' is defined on line 770, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 773, but no explicit reference was found in the text == Outdated reference: draft-ietf-mpls-tp-survive-fwk has been published as RFC 6372 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-survive-fwk (ref. '2') ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) == Outdated reference: draft-ietf-mpls-tp-linear-protection has been published as RFC 6378 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Ping Pan, Ed. 2 Internet Draft Rajan Rao 3 Biao Lu 4 (Infinera) 5 Luyuan Fang 6 (Cisco) 7 Andrew G. Malis 8 (Verizon) 9 Fatai Zhang 10 Sam Aldrin 11 (Huawei) 12 Fei Zhang 13 (ZTE) 14 Mohana Singamsetty 15 (Tellabs) 17 Expires: January 31, 2012 October 31, 2011 19 Supporting Shared Mesh Protection in MPLS-TP Networks 21 draft-pan-shared-mesh-protection-03.txt 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, and it may not be 31 published except as an Internet-Draft. 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. This document may not be modified, 35 and derivative works of it may not be created, except to publish it 36 as an RFC and to translate it into languages other than English. 38 This document may contain material from IETF Documents or IETF 39 Contributions published or made publicly available before November 40 10, 2008. The person(s) controlling the copyright in some of this 41 material may not have granted the IETF Trust the right to allow 42 modifications of such material outside the IETF Standards Process. 44 Without obtaining an adequate license from the person(s) controlling 45 the copyright in such materials, this document may not be modified 46 outside the IETF Standards Process, and derivative works of it may 47 not be created outside the IETF Standards Process, except to format 48 it for publication as an RFC or to translate it into languages other 49 than English. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as Internet- 54 Drafts. 56 Internet-Drafts are draft documents valid for a maximum of six 57 months and may be updated, replaced, or obsoleted by other documents 58 at any time. It is inappropriate to use Internet-Drafts as 59 reference material or to cite them other than as "work in progress." 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html 67 This Internet-Draft will expire on January 31, 2012. 69 Copyright Notice 71 Copyright (c) 2011 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with 79 respect to this document. 81 Abstract 83 Shared mesh protection is a common protection and recovery mechanism 84 in transport networks, where multiple paths can share the same set 85 of network resources for protection purposes. 87 In the context of MPLS-TP, it has been explicitly requested as a 88 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). 90 It's important to note that each MPLS-TP LSP may be associated with 91 transport network resources. In event of network failure, it may 92 require explicit activation on the protecting paths before switching 93 user traffic over. 95 In this memo, we define a lightweight signaling mechanism for 96 protecting path activation in shared mesh protection-enabled MPLS-TP 97 networks. 99 Table of Contents 101 1. Introduction...................................................3 102 2. Conventions used in this document..............................4 103 2.1. Acronyms..................................................4 104 2.2. Definitions and Terminology....Error! Bookmark not defined. 105 3. Solution Overview..............................................5 106 3.1. Protection Switching......................................7 107 3.2. Operation Overview........................................8 108 4. SMP Message and Action Definition..............................9 109 4.1. Protection Switching Control (PSC) Logic..................9 110 4.2. SMP Action Types.........................................11 111 4.3. PSC Signal to SMP Action Mapping.........................12 112 5. Protocol Definition...........................................13 113 5.1. Message Encapsulation....................................14 114 5.2. Reliable Messaging.......................................15 115 5.3. Message Scoping..........................................15 116 6. Processing Rules..............................................16 117 6.1. Enable a protecting path.................................16 118 6.2. Disable a protecting path................................17 119 6.3. Get protecting path status...............................17 120 6.4. Preemption...............................................17 121 7. Security Consideration........................................18 122 8. IANA Considerations...........................................18 123 9. Normative References..........................................18 124 10. Acknowledgments..............................................18 126 1. Introduction 128 Shared mesh protection (SMP) is a common traffic protection 129 mechanism in transport networks, where multiple paths can share the 130 same set of network resources for protection purposes. 132 In the context of MPLS-TP, it has been explicitly requested as a 133 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its 134 operation has been further outlined in Section 4.7.6 of MPLS-TP 135 Survivability Framework [2]. 137 It's important to note that each MPLS-TP LSP may be associated with 138 transport network resources. In event of network failure, it may 139 require explicit activation on the protecting paths before switching 140 user traffic over. 142 In this memo, we define a lightweight signaling mechanism for 143 protecting path activation in shared mesh protection-enabled MPLS-TP 144 networks. 146 Here are the key design goals: 148 1. Fast: The protocol is to activate the previously configured 149 protecting paths in a timely fashion, with minimal transport and 150 processing overhead. The goal is to support 50msec end-to-end 151 traffic switch-over in large transport networks. 153 2. Reliable message delivery: Activation and deactivation operation 154 have serious impact on user traffic. This requires the protocol to 155 adapt a low-overhead reliable messaging mechanism. The activation 156 messages may either traverse through a "trusted" transport 157 channel, or require some level of built-in reliability mechanism. 159 3. Modular: Depending on deployment scenarios, the signaling may need 160 to support functions such as preemption, resource re-allocation 161 and bi-directional activation in a modular fashion. 163 2. Conventions used in this document 165 Here are some of the conventions used in this document. The key 166 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC-2119 [RFC2119]. 170 2.1. Acronyms 172 This draft uses the following acronyms: 174 SMP Shared Mesh Protection 176 LO Lockout of protection 177 DNR Do not revert 179 FS Forced Switch 181 SF Signal Fail 183 SD Signal Degrade 185 MS Manual Switch 187 NR No Request 189 WTR Wait-to-Restore 191 EXER Exercise 193 RR Reverse Request 195 ACK Acknowledgement 197 NACK Negative Acknowledgement 199 G-ACh Generic Associated Channel 201 MPLS-TP Transport Profile for MPLS 203 3. Solution Overview 205 In this section, we describe the SMP operation in the context of 206 MPLS-TP networks, and outline some of the relevant definitions. 208 We refer to the figure below for illustration: 210 ----- B ------- C ---- 211 / \ 212 / \ 213 A D 214 \ / 215 \ / 216 ==== E === F === G === 217 / \ 218 / \ 219 H K 220 \ / 221 \ / 222 ----- I ------- J ---- 224 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 226 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 228 The links between E, F and G are shared by both protecting paths. 229 All paths are established via MPLS-TP control plane prior to network 230 failure. 232 All paths are assumed to be bi-directional. An edge node is denoted 233 as a headend or tailend for a particular path in accordance to the 234 path setup direction. 236 Initially, the operators setup both working and protecting paths. 237 During setup, the operators specify the network resources for each 238 path. 240 The working path X and Y will configure the appropriate resources on 241 the intermediate nodes, however, the protecting paths, X' and Y', 242 will reserve the resources on the nodes, but won't occupy them. 244 Depending on network planning requirements (such as SRLG), X' and Y' 245 may share the same set of resources on node E, F and G. The resource 246 assignment is a part of the control-plane CAC operation taking place 247 on each node. 249 At some time, link B-C is cut. Node A will detect the outage, and 250 initiate activation messages to bring up the protecting path X'. The 251 intermediate nodes, E, F and G will program the switch fabric and 252 configure the appropriate resources. Upon the completion of the 253 activation, A will switch the user traffic to X'. 255 The operation may have extra caveat: 257 1. Preemption: Protecting paths X' and Y' may share the same 258 resources on node E, F or G due to resource constraints. Y' has 259 higher priority than that of X'. In the previous example, X' is 260 up and running. When there is a link outage on I-J, H can 261 activate its protecting path Y'. On E, F or G, Y' can take over 262 the resources from X' for its own traffic. The behavior is 263 acceptable with the condition that A should be notified about 264 the preemption action. 266 2. Over-subscription (1:N): A unit of network resource may be 267 reserved by one or multiple protecting paths. In the example, 268 the network resources on E-F and F-G are shared by two 269 protecting paths, X' and Y'. In deployment, the over- 270 subscription ratio is an important factor on network resource 271 utilization. 273 3.1. Protection Switching 275 The entire activation and switch-over operation need to be within 276 the range of milliseconds to meet customer's expectation [1]. This 277 section illustrates how this may be achieved on MPLS-TP-enabled 278 transport switches. Note that this is for illustration of protection 279 switching operation, not mandating the implementation itself. 281 The diagram below illustrates the operation. 283 +---------------+ 284 Control | MPLS-TP | Control 285 <=== Signaling ====| Control Plane |=== Signaling ===> 286 +---------------+ 287 / \ 288 / \ (MPLS label assignment) 289 / \ 290 / \ 291 +-------+ +------+ +-------+ 292 Activation |Line | |Switch| |Line | Activation 293 <=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===> 294 +-------+ +------+ +-------+ 296 Typical MPLS-TP user flows (or, LSP's) are bi-directional, and setup 297 as co-routed or associated tunnels, with a MPLS label for each of 298 the upstream and downstream traffic. On this particular type of 299 transport switch, the control-plane can download the labels to the 300 line modules. Subsequently, the line module will maintain a label 301 lookup table on all working and protecting paths. 303 Upon the detection of network failure, the headend nodes will 304 transmit activation messages along the MPLS LSP's. When receiving 305 the messages, the line modules can locate the associated protecting 306 path from the label lookup table, and perform activation procedure 307 by programming the switching fabric directly. Upon its success, the 308 line module will swap the label, and forward the activation messages 309 to the next hop. 311 In summary, the activation procedure involves efficient path lookup 312 and switch fabric re-programming. 314 To achieve the tight end-to-end switch-over budget, it's possible to 315 implement the entire activation procedure with hardware-assistance 316 (such as in FPGA or ASIC). 318 The activation messages are encapsulated with a MPLS-TP Generic 319 Associated Channel Header (GACH) [3]. Detailed message encoding is 320 explained in Section 6. 322 3.2. Operation Overview 324 To achieve high performance, the activation procedure is designed to 325 be simple and straightforward on the network nodes. 327 In this section, we describe the activation procedure using the same 328 figure shown before: 330 ----- B ------- C ---- 331 / \ 332 / \ 333 A D 334 \ / 335 \ / 336 ==== E === F === G === 337 / \ 338 / \ 339 H K 340 \ / 341 \ / 342 ----- I ------- J ---- 344 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 346 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 348 Upon the detection of working path failure, the edge nodes, A, D, H 349 and K may trigger the activation messages to activate the protecting 350 paths, and redirect user traffic immediately after. 352 We assume that there is a consistent definition of priority levels 353 among the paths throughout the network. At activation time, each 354 node may rely on the priority levels to potentially preempt other 355 paths. 357 When the nodes detect path preemption on a particular node, they 358 should inform all relevant nodes to free the resources by sending 359 out notification messages. Upon the reception of notification 360 messages, the relevant nodes will send out de-activation messages. 362 To optimize traffic protection and resource management, each headend 363 may periodically poll the protecting paths about resource 364 availability. The intermediate nodes have the option to inform the 365 current resource utilization. 367 Note that, upon the detection of a working path failure, both 368 headend and tailend may initiate the activation simultaneously 369 (known as bi-directional activation). This may expedite the 370 activation time. However, both headend and tailend nodes need to 371 coordinate the order of protecting paths for activation, since there 372 may be multiple protecting paths for each working path (i.e., 1:N 373 protection). For clarity, we will describe the operation from 374 headend in the memo. The tailend operation will be available in the 375 subsequent revisions. 377 4. SMP Message and Action Definition 379 4.1. Protection Switching Control (PSC) Logic 381 Protection switching processes the local triggers described in 382 requirements 74-79 of [1] together with inputs received from the 383 tailend node. Based on these inputs the headend will take SMP 384 actions, and transmit different protocol messages. 386 Here, we reuse the switching control logic described in MPLS Linear 387 Protection [6], with the following logical decomposition at headend 388 node: 390 Server Indication Control Plane Indication 391 -----------------+ +------------- 392 Operator Command | | OAM Indication 393 ----------------+ | | +--------------- 394 | | | | 395 V V V V 396 +---------------+ +-------+ 397 | Local Request |<--------| WTR | 398 | logic |WTR Exps | Timer | 399 +---------------+ +-------+ 400 | ^ 401 Highest local|request | 402 V | Start/Stop 403 +-----------------+ | 404 Remote PSC | PSC Control |------------+ 405 ------------>| logic | 406 Request +-----------------+ 407 | 408 | Action +------------+ 409 +---------------->| Message | 410 | Generator | 411 +------------+ 412 | 413 Output PSC | Message 414 V 416 The Local Request logic unit accepts the triggers from the OAM, 417 external operator commands, from the local control plane (when 418 present), and the Wait-to-Restore timer. By considering all of these 419 local request sources it determines the highest priority local 420 request. This high-priority request is passed to the PSC Control 421 logic, that will cross-check this local request with the information 422 received from the tailend node. The PSC Control logic uses this 423 input to determine what actions need to be taken, e.g. local actions 424 at the headend, or what message should be sent to the tailend node. 426 Specifically, the signals could be the following: 428 o Clear - if the operator cancels an active local administrative 429 command, i.e. LO/FS/MS. 431 o Lockout of Protection (LO) - if the operator requested to prevent 432 switching data traffic to the protection path, for any purpose. 434 o Signal Fail (SF) - if any of the Server Layer, Control plane, or 435 OAM indications signaled a failure condition on either the 436 protection path or one of the working paths. 438 o Signal Degrade (SD) - if any of the Server Layer, Control plane, 439 or OAM indications signaled a degraded transmission condition on 440 either the protection path or one of the working paths. 442 o Forced Switch (FS) - if the operator requested that traffic be 443 switched from one of the working paths to the protection path, 445 o Manual Switch (MS) - if the operator requested that traffic is 446 switched from the working path to the protection path. This is 447 only relevant if there is no currently active fault condition or 448 Operator command. 450 o WTR Expires - generated by the WTR timer completing its period. 452 If none of the input sources have generated any input then the 453 request logic should generate a No Request (NR) request. 455 In addition to the local requests, the PSC Control Logic SHALL 456 accept PSC messages from the tailend node of the transport path. 457 Remote messages indicate the status of the transport path from the 458 viewpoint of the tailend nodes. The remote requests may include 459 remote LO, SF, SD, FS, MS, WTR and NR. 461 Much of the signal definition is further described in ITU G.709 and 462 G.873.1. 464 4.2. SMP Action Types 466 As shown in the previous section, SMP requires four actions types 467 throughout the operation: 469 o ACTIVATION: This action is triggered by the head-end (or tail- 470 end) to activate a protecting connection. The intermediate nodes 471 need to propagate this towards the other end of the protecting 472 connection. 474 o DE-ACTIVATION: This action is used to de-activate a particular 475 protecting connection. This can be originated by one end of a 476 protecting connection (i.e. head-end, or tail-end). The 477 intermediate nodes need to propagate this towards the other end 478 of the protecting connection. 480 o QUERY: This action is used when an operator decides to query a 481 particular protecting connection. 483 o NOTIFICATION: SMP operation requires the coordination between 484 nodes. The coordination takes places in two occasions: 486 (1) The activation/de-activation is initiated at the headend 487 (tailend) nodes. To avoid potential mis-connection, the user 488 traffic cannot be switched on to the protecting connection until 489 the reception of an acknowledgement from the tailend (headend) 490 nodes. 492 (2) If an intermediate node cannot process the activation 493 requests, due to lack of resources or preemption levels, it needs 494 to report the failure to the request originators. 496 It is conceivable that this message can be used to report the 497 location of the fault, with respect to a protecting connection so 498 that the head-end may use this information as one of the criteria 499 for restoring the working transport entity. The fault location 500 could be used by the head-end node to select among a list of 501 possible protecting connections associated with the working 502 connection (i.e. avoid the faulty location), or to determine that 503 none of the provisioned protecting connections is usable at the 504 time the failure is reported and then fallback to restoring the 505 working connection. 507 4.3. PSC Signal to SMP Action Mapping 509 In SMP operation, there is the action-signal mapping: 511 Activation action: FS, SF, SD, MS, 513 De-activation action: NR 515 Query action: EXER 517 Notification action: ACK, NACK (see next section) 519 5. Protocol Definition 521 Each SMP message has the following format: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Ver|Request|Rsv|R| Reserved | Status | Seq | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 o Version: 1 531 o Request: 533 o 1111b: Lockout of Protection (LO) 535 o 1110b: Forced Switch (FS). This triggers activation 537 o 1100b: Signal Fail (SF). This triggers activation 539 o 1011b: Acknowledgement (ACK). This is to acknowledge a 540 successful activation/de-activation request 542 o 1010b: Signal Degrade (SD). This triggers activation 544 o 1001b: Negative Acknowledgement (NACK). This is to report 545 failure in activation/de-activation process. 547 o 1000b: Manual Switch (MS). This triggers activation 549 o 0110b: Wait-to-Restore (WTR). Used for revertive switching 551 o 0100b: Exercise (EXER). Triggers SMP query 553 o 0001b: Do Not Revert (DNR). Used for revertive switching 555 o 0000b: No Request (NR). This triggers de-activation 557 o R: Revertive field 559 o 0: non-revertive mode 561 o 1: revertive mode 563 o Rsv/Reserved: This field is reserved for future use 564 o Status: this informs the status of the AMP activation. This field 565 is only relevant with ACK and NACK requests. Specifically, the 566 Status Code has the following encoding value and definition: 568 o 1: end-to-end ack 570 o 2: hop-to-hop ack 572 o 3: no such path 574 o 4: no more resource for the path 576 o 5: preempted by another path 578 o 6: system failure 580 o 7: shared resource has been taken by other paths 582 o Seq: This uniquely identifies a particular message. This field is 583 defined to support reliable message delivery 585 Note that the message format and naming convention are very similar 586 to that of MPLS linear protection [6] and ITU G.873.1. 588 5.1. Message Encapsulation 590 SMP messages use MPLS labels to identify the paths. Further, the 591 messages are encapsulated in GAL/GACH: 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | MPLS Label stack | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | GAL | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |0 0 0 1|Version| Reserved | Activation Channel Type | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Activation Message Payload | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 o GAL is described in [3] 606 o Activation Channel Type is the GACH channel number assigned to 607 the protocol. This uniquely identifies the activation messages. 609 Specifically, the messages have the following message format: 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Label | Exp |S| TTL | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Label (13) | Exp |S| TTL | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 |0 0 0 1|Version| Reserved | Activation Channel Type | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |Ver|Request|Rsv|R| Reserved | Status | Seq | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 5.2. Reliable Messaging 625 The activation procedure adapts a simple two-way handshake reliable 626 messaging. 628 Each node maintains a sequence number generator. Each new sending 629 message will have a new sequence number. After sending a message, 630 the node will wait for a response with the same sequence number. 632 Specifically, upon the generation of activation, de-activation, 633 query and notification messages, the message sender expects to 634 receive acknowledgement in reply with same sequence number. 636 If a sender is not getting the reply within a time interval, it will 637 retransmit the same message with a new sequence number, and starts 638 to wait again. After multiple retries (by default, 3), the sender 639 will declare activation failure, and alarm the operators for further 640 service. 642 5.3. Message Scoping 644 Activation signaling uses MPLS label TTL to control how far the 645 message would traverse. Here are the processing rules on each 646 intermediate node: 648 o On receive, if the message has label TTL = 0, the node must drop 649 the packet without further processing 651 o The receiving node must always decrement the label TTL value by 652 one. If TTL = 0 after the decrement, the node must process the 653 message. Otherwise, the node must forward the message without 654 further processing (unless, of course, the node is headend or 655 tailend) 657 o On transmission, the node will adjust the TTL value. For hop-by- 658 hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default. 660 6. Processing Rules 662 6.1. Enable a protecting path 664 Upon the detection of network failure (SF/SD/FS) on a working path, 665 the headend node identifies the corresponding MPLS-TP label and 666 initiates the protection switching by sending an activation message. 668 The activation messages always use MPLS label TTL = 1 to force hop- 669 by-hop process. Upon reception, a next-hop node will locate the 670 corresponding path and activate the path. 672 If the activation message is received on an intermediate node, due 673 to label TTL expiry, the message is processed and then propagated to 674 the next hop of the MPLS TP LSP, by setting the MPLS TP label TTL = 675 1. 677 The headend node will declare the success of the activation only 678 when it gets a positive reply from the tailend node. This requires 679 that the tailend nodes must reply the messages with ACK to the 680 headend nodes in all cases. 682 If the headend node is not receiving the acknowledgement within a 683 time internal, it will retransmit another activation message with a 684 different Seq number. 686 If the headend node is not receiving a positive reply within a 687 longer time interval, it will declare activation failure. 689 If an intermediate node cannot activate a protecting path, it will 690 reply a message with NACK to report failure. When the headend node 691 receives the message for failure, it must initiate the de-activation 692 messages to clean up networks resources on all the relevant nodes on 693 the path. 695 6.2. Disable a protecting path 697 The headend removes the network resources on a path by sending the 698 de-activation messages. 700 In the message, the MPLS label represents the path to be de- 701 activated. The MPLS TTL is one to force hop-by-hop processing. 703 Upon reception, a node will de-activate the path, by freeing the 704 resources from the data-plane. 706 As a part of the clean-up procedure, each de-activation message must 707 traverse through and be processed on all the nodes of the 708 corresponding path. When the de-activation message reaches to the 709 tailend node, the tailend is required to reply with an 710 acknowledgement message to the headend. 712 The de-activation process is complete when the headend receives the 713 corresponding acknowledgement message from the tailend. 715 6.3. Get protecting path status 717 The operators have the option to trigger the query messages from the 718 headend to check on the protecting path periodically or on-demand. 719 The process procedure on each node is very similar to that of the 720 activation messages on the intermediate nodes, except the query 721 messages should not trigger any network resource re-programming. 723 Upon reception, the node will check the availability of resources. 725 If the resource is no longer available, the node will reply an NACK 726 with error conditions. 728 6.4. Preemption 730 The preemption operation typically takes place when processing an 731 activation message. 733 If the activating network resources have been used by another path 734 and carrying user traffic, the node needs to compare the priority 735 levels. 737 If the existing path has higher priority, the node needs to reject 738 the activation request by sending an ACK to the corresponding 739 headend to inform the unavailability of network resources. 741 If the new path has higher priority, the node will reallocate the 742 resource to the new path, and send an ACK to old path's headend node 743 to inform about the preemption. 745 7. Security Consideration 747 The protection activation takes place in a controlled networking 748 environment. Nevertheless, it is expected that the edge nodes will 749 encapsulate and transport external traffic into separated tunnels, 750 and the intermediate nodes will never have to process them. 752 8. IANA Considerations 754 Activation messages are encapsulated in MPLS-TP with a specific GACH 755 channel type that needs to be assigned by IANA. 757 9. Normative References 759 [1] RFC 5654: Requirements of an MPLS Transport Profile, B. Niven- 760 Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno, 761 September 2009 763 [2] IETF draft, Multiprotocol Label Switching Transport Profile 764 Survivability Framework (draft-ietf-mpls-tp-survive-fwk- 765 06.txt), N. Sprecher, A. Farrel, June 2010 767 [3] RFC5586 - Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, 768 R., and D. Ward, "MPLS Generic Associated Channel", May 2009. 770 [4] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, March 1997. 773 [5] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 774 Syntax Specifications: ABNF", RFC 2234, Internet Mail 775 Consortium and Demon Internet Ltd., November 1997. 777 [6] IETF draft, MPLS-TP Linear Protection, (draft-ietf-mpls-tp- 778 linear-protection-09.txt), Bryant, et al. 780 10. Acknowledgments 782 Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and 783 Deborah Brungard for detailed feedback on the earlier work, and the 784 guidance and recommendation for this proposal. 786 We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague, 787 Ann Gui and Tony Jorgenson for discussion on network operation, 788 feasibility and implementation methodology. 790 During ITU-T SG15 Interim meeting in May 2011, we have had long 791 discussion with the G.SMP contributors, in particular Fatai Zhang, 792 Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback 793 and corrections. 795 Authors' Addresses 797 Ping Pan 798 Email: ppan@infinera.com 800 Rajan Rao 801 Email: rrao@infinera.com 803 Biao Lu 804 Email: blu@infinera.com 806 Luyuan Fang 807 Email: lufang@cisco.com 809 Andrew G. Malis 810 Email: andrew.g.malis@verizon.com 812 Fatai Zhang 813 Email: zhangfatai@huawei.com 815 Sam Aldrin 816 Email: sam.aldrin@huawei.com 818 Fei Zhang 819 Email: zhang.fei3@zte.com.cn 821 Sri Mohana Satya Srinivas Singamsetty 822 Email: SriMohanS@Tellabs.com