idnits 2.17.00 (12 Aug 2021) /tmp/idnits23731/draft-pan-shared-mesh-protection-02.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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 214 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 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 (July 11, 2011) is 3967 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 161 == Unused Reference: '4' is defined on line 639, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 642, 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) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Ping Pan 3 Internet Draft Rajan Rao 4 Biao Lu 5 (Infinera) 6 Luyuan Fang 7 (Cisco) 8 Andy Malis 9 (Verizon) 10 Sam Aldrin 11 (Huawei) 12 Mohana Singamsetty 13 (Tellabs) 15 Expires: January 11, 2012 July 11, 2011 17 Supporting Shared Mesh Protection in MPLS-TP Networks 19 draft-pan-shared-mesh-protection-02.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be modified, 28 and derivative works of it may not be created, and it may not be 29 published except as an Internet-Draft. 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. This document may not be modified, 33 and derivative works of it may not be created, except to publish it 34 as an RFC and to translate it into languages other than English. 36 This document may contain material from IETF Documents or IETF 37 Contributions published or made publicly available before November 38 10, 2008. The person(s) controlling the copyright in some of this 39 material may not have granted the IETF Trust the right to allow 40 modifications of such material outside the IETF Standards Process. 41 Without obtaining an adequate license from the person(s) controlling 42 the copyright in such materials, this document may not be modified 43 outside the IETF Standards Process, and derivative works of it may 44 not be created outside the IETF Standards Process, except to format 45 it for publication as an RFC or to translate it into languages other 46 than English. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six 54 months and may be updated, replaced, or obsoleted by other documents 55 at any time. It is inappropriate to use Internet-Drafts as 56 reference material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 This Internet-Draft will expire on January 11, 2012. 66 Copyright Notice 68 Copyright (c) 2011 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with 76 respect to this document. 78 Abstract 80 Shared mesh protection is a common protection and recovery mechanism 81 in transport networks, where multiple paths can share the same set 82 of network resources for protection purposes. 84 In the context of MPLS-TP, it has been explicitly requested as a 85 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). 87 It's important to note that each MPLS-TP LSP may be associated with 88 transport network resources. In event of network failure, it may 89 require explicit activation on the protecting paths before switching 90 user traffic over. 92 In this memo, we define a lightweight signaling mechanism for 93 protecting path activation in shared mesh protection-enabled MPLS-TP 94 networks. 96 Table of Contents 98 1. Introduction...................................................3 99 2. Background.....................................................4 100 3. Problem Definition.............................................5 101 4. Protection Switching...........................................6 102 5. Activation Operation Overview..................................8 103 6. Protocol Definition............................................9 104 6.1. Activation Messages.......................................9 105 6.2. Message Encapsulation....................................10 106 6.3. Reliable Messaging.......................................11 107 6.4. Message Scoping..........................................12 108 7. Processing Rules..............................................12 109 7.1. Enable a protecting path.................................12 110 7.2. Disable a protecting path................................13 111 7.3. Get protecting path status...............................14 112 7.4. Acknowledgement with STATUS..............................14 113 7.5. Preemption...............................................14 114 8. Security Consideration........................................14 115 9. IANA Considerations...........................................15 116 10. Normative References.........................................15 117 11. Acknowledgments..............................................15 119 1. Introduction 121 Shared mesh protection is a common traffic protection mechanism in 122 transport networks, where multiple paths can share the same set of 123 network resources for protection purposes. 125 In the context of MPLS-TP, it has been explicitly requested as a 126 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its 127 operation has been further outlined in Section 4.7.6 of MPLS-TP 128 Survivability Framework [2]. 130 It's important to note that each MPLS-TP LSP may be associated with 131 transport network resources. In event of network failure, it may 132 require explicit activation on the protecting paths before switching 133 user traffic over. 135 In this memo, we define a lightweight signaling mechanism for 136 protecting path activation in shared mesh protection-enabled MPLS-TP 137 networks. The framework version of the document has been presented 138 in ITU-T SG15 Interim Meeting in May 2011, and is in-sync with the 139 on-going G.SMP work in ITU-T. 141 Here are the key design goals: 143 1. Fast: The protocol is to activate the previously configured 144 protecting paths in a timely fashion, with minimal transport and 145 processing overhead. The goal is to support 50msec end-to-end 146 traffic switch-over in large transport networks. 148 2. Reliable message delivery: Activation and deactivation operation 149 have serious impact on user traffic. This requires the protocol to 150 adapt a low-overhead reliable messaging mechanism. The activation 151 messages may either traverse through a "trusted" transport 152 channel, or require some level of built-in reliability mechanism. 154 3. Modular: Depending on deployment scenarios, the signaling may need 155 to support functions such as preemption, resource re-allocation 156 and bi-directional activation in a modular fashion. 158 Here are some of the conventions used in this document. The key 159 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC-2119 [RFC2119]. 163 2. Background 165 Transport network protection can be typically categorized into three 166 types: 168 Cold Standby: In this type of protection, the nodes will only 169 negotiate and establish backup path after the detection of network 170 failure. 172 Hot Standby: The protecting paths are established prior to network 173 failure. This is also known as "make-before-break". Upon the 174 detection of network failure, the edge nodes will switch data 175 traffic into pre-established backup path immediately. 177 Warm Standby: The nodes will negotiate and reserve protecting path 178 prior to network failure. However, data forwarding path will not be 179 programmed. Upon the detection of network failure, the nodes will 180 send explicit messages to relevant nodes to "wake up" the protecting 181 path. 183 The activation signaling defined in this memo is to support warm 184 standby in the context of MPLS-TP. 186 Further, the activation procedure may be triggered using the failure 187 notification methods defined in MPLS-TP OAM specifications. 189 3. Problem Definition 191 In this section, we describe the operation of shared mesh protection 192 in the context of MPLS-TP networks, and outline some of the relevant 193 definitions. 195 We refer to the figure below for illustration: 197 ----- B ------- C ---- 198 / \ 199 / \ 200 A D 201 \ / 202 \ / 203 ==== E === F === G === 204 / \ 205 / \ 206 H K 207 \ / 208 \ / 209 ----- I ------- J ---- 211 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 213 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 215 The links between E, F and G are shared by both protecting paths. 216 All paths are established via MPLS-TP control plane prior to network 217 failure. 219 All paths are assumed to be bi-directional. An edge node is denoted 220 as a headend or tailend for a particular path in accordance to the 221 path setup direction. 223 Initially, the operators setup both working and protecting paths. 224 During setup, the operators specify the network resources for each 225 path. 227 The working path X and Y will configure the appropriate resources on 228 the intermediate nodes, however, the protecting paths, X' and Y' 229 will reserve the resources on the nodes, but won't occupy them. 231 Depending on network planning requirements (such as SRLG), X' and Y' 232 may share the same set of resources on node E, F and G. The resource 233 assignment is a part of the control-plane CAC operation taking place 234 on each node. 236 At some time, link B-C is cut. Node A will detect the outage, and 237 initiate activation messages to bring up the protecting path X' The 238 intermediate nodes, E, F and G will program the switch fabric and 239 configure the appropriate resources. Upon the completion of the 240 activation, A will switch the user traffic to X' 242 The operation may have extra caveat: 244 1. Preemption: Protecting paths X' and Y' may share the same 245 resources on node E, F or G due to resource constraints. Y' has 246 higher priority than that of X' In the previous example, X' is 247 up and running. When there is a link outage on I-J, H can 248 activate its protecting path Y' On E, F or G, Y' can take over 249 the resources from X' for its own traffic. The behavior is 250 acceptable with the condition that A should be notified about 251 the preemption action. 253 2. Over-subscription (1:N): A unit of network resource may be 254 reserved by one or multiple protecting paths. In the example, 255 the network resources on E-F and F-G are shared by two 256 protecting paths, X' and Y' In deployment, the over- 257 subscription ratio is an important factor on network resource 258 utilization. 260 4. Protection Switching 262 The entire activation and switch-over operation need to be within 263 the range of milliseconds to meet customer's expectation [1]. This 264 section illustrates how this may be achieved on MPLS-TP-enabled 265 transport switches. Note that this is for illustration of protection 266 switching operation, not mandating the implementation itself. 268 The diagram below illustrates the operation. 270 +---------------+ 271 Control | MPLS-TP | Control 272 <=== Signaling ====| Control Plane |=== Signaling ===> 273 +---------------+ 274 / \ 275 / \ (MPLS label assignment) 276 / \ 277 / \ 278 +-------+ +------+ +-------+ 279 Activation |Line | |Switch| |Line | Activation 280 <=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===> 281 +-------+ +------+ +-------+ 283 Typical MPLS-TP user flows (or, LSP's) are bi-directional, and setup 284 as co-routed or associated tunnels, with a MPLS label for each of 285 the upstream and downstream traffic. On this particular type of 286 transport switch, the control-plane can download the labels to the 287 line modules. Subsequently, the line module will maintain a label 288 lookup table on all working and protecting paths. 290 Upon the detection of network failure, the headend nodes will 291 transmit activation messages along the MPLS LSP's. When receiving 292 the messages, the line modules can locate the associated protecting 293 path from the label lookup table, and perform activation procedure 294 by programming the switching fabric directly. Upon its success, the 295 line module will swap the label, and forward the activation messages 296 to the next hop. 298 In summary, the activation procedure involves efficient path lookup 299 and switch fabric re-programming. 301 To achieve the tight end-to-end switch-over budget, it's possible to 302 implement the entire activation procedure with hardware-assistance 303 (such as in FPGA or ASIC). 305 The activation messages are encapsulated with a MPLS-TP Generic 306 Associated Channel Header (GACH) [3]. Detailed message encoding is 307 explained in Section 6. 309 5. Activation Operation Overview 311 To achieve high performance, the activation procedure is designed to 312 be simple and straightforward on the network nodes. 314 In this section, we describe the activation procedure using the same 315 figure shown before: 317 ----- B ------- C ---- 318 / \ 319 / \ 320 A D 321 \ / 322 \ / 323 ==== E === F === G === 324 / \ 325 / \ 326 H K 327 \ / 328 \ / 329 ----- I ------- J ---- 331 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 333 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 335 Upon the detection of working path failure, the edge nodes, A, D, H 336 and K may trigger the activation messages to activate the protecting 337 paths, and redirect user traffic immediately after. 339 We assume that there is a consistent definition of priority levels 340 among the paths throughout the network. At activation time, each 341 node may rely on the priority levels to potentially preempt other 342 paths. 344 When the nodes detect path preemption on a particular node, they 345 should inform all relevant nodes to free the resources. 347 To optimize traffic protection and resource management, each headend 348 may periodically poll the protecting paths about resource 349 availability. The intermediate nodes have the option to inform the 350 current resource utilization. This procedure may be conducted by 351 other OAM mechanisms. 353 Note that, upon the detection of a working path failure, both 354 headend and tailend may initiate the activation simultaneously 355 (known as bi-directional activation). This may expedite the 356 activation time. However, both headend and tailend nodes need to 357 coordinate the order of protecting paths for activation, since there 358 may be multiple protecting paths for each working path (i.e., 1:N 359 protection). For clarity, we will describe the operation from 360 headend in the memo. The tailend operation will be available in the 361 subsequent revisions. 363 6. Protocol Definition 365 6.1. Activation Messages 367 The activation requires the following messages: 369 o ENABLE: this is initiated by the headend nodes to activate a 370 protecting path 372 o DISABLE: this is initiated by the headend nodes to disable a 373 protecting path and free the associated network resources 375 o GET: this is initiated by the headend to gather resource 376 availability information on a particular protecting path 378 o NOTIFY: this is initiated by the intermediate nodes and terminate 379 on the headend nodes to report preemption or protection failure 380 conditions 382 o STATUS: this is the acknowledgement message for ENABLE, DISABLE, 383 GET, and NOTIFY messages, and contains the relevant status 384 information 386 Each activation message has the following format: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |Version| Type | Reserved | Seq | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Additional Info | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 o Version: 1 398 o Type: 400 o ENABLE 1 402 o DISABLE 2 404 o GET 3 406 o STATUS 4 408 o NOTIFY 5 410 o Reserved: This field is reserved for future use 412 o Seq: This uniquely identifies a particular message. This field is 413 defined to support reliable message delivery 415 o Additional Info: the message-specific data 417 6.2. Message Encapsulation 419 Activation messages use MPLS labels to identify the paths. Further, 420 the messages are encapsulated in GAL/GACH: 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | MPLS Label stack | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | GAL | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |0 0 0 1|Version| Reserved | Activation Channel Type | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Activation Message Payload | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 o GAL is described in [3] 436 o Activation Channel Type is the GACH channel number assigned to 437 the protocol. This uniquely identifies the activation messages. 439 Specifically, the messages have the following message format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Label | Exp |S| TTL | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Label (13) | Exp |S| TTL | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |0 0 0 1|Version| Reserved | Activation Channel Type | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Ver(1)| Type | Status Code | Seq | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 For STATUS and NOTIFY messages, the Status Code has the following 454 encoding value and definition: 456 o 0-19: OK 458 . 1: end-to-end ack 460 o 20-39: message processing errors 462 . 20: no such path 464 o 40-59: processing issues: 466 . 40: no more resource for the path 468 . 41: preempted by another path 470 . 42: system failure 472 o 60-79: informative data: 474 . 60: shared resource has been taken by other paths 476 Further, for preemption notification, we may consider of using the 477 existing MPLS-TP OAM messaging. More details will be available in 478 the future revisions. 480 6.3. Reliable Messaging 482 The activation procedure adapts a simple two-way handshake reliable 483 messaging. 485 Each node maintains a sequence number generator. Each new sending 486 message will have a new sequence number. After sending a message, 487 the node will wait for a response with the same sequence number. 489 Specifically, upon the generation of ENABLE, DISABLE, GET and NOTIFY 490 messages, the message sender expects to receive a STATUS in reply 491 with same sequence number. 493 If a sender is not getting the reply (STATUS) within a time 494 interval, it will retransmit the same message with a new sequence 495 number, and starts to wait again. After multiple retries (by 496 default, 3), the sender will declare activation failure, and alarm 497 the operators for further service. 499 6.4. Message Scoping 501 Activation signaling uses MPLS label TTL to control how far the 502 message would traverse. Here are the processing rules on each 503 intermediate node: 505 o On receive, if the message has label TTL = 0, the node must drop 506 the packet without further processing 508 o The receiving node must always decrement the label TTL value by 509 one. If TTL = 0 after the decrement, the node must process the 510 message. Otherwise, the node must forward the message without 511 further processing (unless, of course, the node is headend or 512 tailend) 514 o On transmission, the node will adjust the TTL value. For hop-by- 515 hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default. 517 7. Processing Rules 519 7.1. Enable a protecting path 521 Upon the detection of network failure on a working path, the headend 522 node identifies the corresponding MPLS-TP label and initiates the 523 protection switching by sending an ENABLE message. 525 ENABLE messages always use MPLS label TTL = 1 to force hop-by-hop 526 process. Upon reception, a next-hop node will locate the 527 corresponding path and activate the path. 529 If the Enable message is received on an intermediate node, due to 530 label TTL expiry, the message is processed and then propagated to 531 the next hop of the MPLS TP LSP, by setting the MPLS TP label TTL = 532 1. The intermediate node may NOT respond back to the headend node 533 with STATUS message. 535 The headend node will declare the success of the activation only 536 when it gets a positive reply from the tailend node. This requires 537 that the tailend nodes must reply STATUS messages to the headend 538 nodes in all cases. 540 If the headend node is not receiving the acknowledgement within a 541 time internal, it will retransmit another ENABLE message with a 542 different Seq number. 544 If the headend node is not receiving a positive reply within a 545 longer time interval, it will declare activation failure. 547 If an intermediate node cannot activate a protecting path, it will 548 reply an NOTIFY message to report failure. When the headend node 549 receives a NOTIFY message for failure, it must initiate DISABLE 550 messages to clean up networks resources on all the relevant nodes on 551 the path. 553 7.2. Disable a protecting path 555 The headend removes the network resources on a path by sending 556 DISABLE messages. 558 In the message, the MPLS label represents the path to be de- 559 activated. The MPLS TTL is one to force hop-by-hop processing. 561 Upon reception, a node will de-activate the path, by freeing the 562 resources from the data-plane. 564 As a part of the clean-up procedure, each DISABLE message must 565 traverse through and be processed on all the nodes of the 566 corresponding path. When the DISABLE message reaches to the tailend 567 node, the tailend is required to reply with a STATUS message to the 568 headend. 570 The de-activation process is complete when the headend receives the 571 corresponding STATUS message from the tailend. 573 7.3. Get protecting path status 575 The operators have the option to trigger GET messages from the 576 headend to check on the protecting path periodically or on-demand. 577 The process procedure on each node is very similar to that of ENABLE 578 messages on the intermediate nodes, except the GET messages should 579 not trigger any network resource re-programming. 581 Upon reception, the node will check the availability of resources. 583 If the resource is no longer available, the node will reply a NOTIFY 584 with error conditions. 586 7.4. Acknowledgement with STATUS 588 The STATUS message is the acknowledgement packet to all messages, 589 and may be generated by any node in the network. 591 Each STATUS message must use the same sequence number as the 592 corresponding message (ENABLE, DISABLE, GET and NOTIFY). 594 When replying to headend, the tailend nodes must originate STATUS 595 messages with a large MPLS TTL value (0xff, by default). 597 7.5. Preemption 599 The preemption operation typically takes place when processing an 600 ENABLE message. 602 If the activating network resources have been used by another path 603 and carrying user traffic, the node needs to compare the priority 604 levels. 606 If the existing path has higher priority, the node needs to reject 607 the ENABLE message by sending a STATUS message to the corresponding 608 headend to inform the unavailability of network resources. 610 If the new path has higher priority, the node will reallocate the 611 resource to the new path, and send an NOTIFY message to old path's 612 headend node to inform about the preemption. 614 8. Security Consideration 616 The protection activation takes place in a controlled networking 617 environment. Nevertheless, it is expected that the edge nodes will 618 encapsulate and transport external traffic into separated tunnels, 619 and the intermediate nodes will never have to process them. 621 9. IANA Considerations 623 Activation messages are encapsulated in MPLS-TP with a specific GACH 624 channel type that needs to be assigned by IANA. 626 10. Normative References 628 [1] RFC 5654: Requirements of an MPLS Transport Profile, B. Niven- 629 Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno, 630 September 2009 632 [2] IETF draft, Multiprotocol Label Switching Transport Profile 633 Survivability Framework (draft-ietf-mpls-tp-survive-fwk- 634 06.txt), N. Sprecher, A. Farrel, June 2010 636 [3] RFC5586 - Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, 637 R., and D. Ward, "MPLS Generic Associated Channel", May 2009. 639 [4] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, March 1997. 642 [5] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 643 Syntax Specifications: ABNF", RFC 2234, Internet Mail 644 Consortium and Demon Internet Ltd., November 1997. 646 11. Acknowledgments 648 Authors like to thank Eric Osborne, Lou Berger, Nabil Bitar and 649 Deborah Brungard for detailed feedback on the earlier work, and the 650 guidance and recommendation for this proposal. 652 We also thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted Sprague, 653 Ann Gui and Tony Jorgenson for discussion on network operation, 654 feasibility and implementation methodology. 656 During ITU-T SG15 Interim meeting in May 2011, we have had long 657 discussion with the G.SMP contributors, in particular Fatai Zhang, 658 Bin Lu, Maarten Vissers and Jeong-dong Ryoo. We thank their feedback 659 and corrections. 661 Authors' Addresses 663 Ping Pan 664 Email: ppan@infinera.com 666 Rajan Rao 667 Email: rrao@infinera.com 669 Biao Lu 670 Email: blu@infinera.com 672 Luyuan Fang 673 Email: lufang@cisco.com 675 Andy Malis 676 Email: andrew.g.malis@verizon.com 678 Sam Aldrin 679 Email: sam.aldrin@huawei.com 681 Sri Mohana Satya Srinivas Singamsetty 682 Email: SriMohanS@Tellabs.com