idnits 2.17.00 (12 Aug 2021) /tmp/idnits26451/draft-pan-shared-mesh-protection-00.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 9 longer pages, the longest (page 3) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 212 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 (March 7, 2011) is 4093 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 148 == Unused Reference: '4' is defined on line 615, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 618, 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 Mohana Srinivas 4 Rajan Rao 5 Biao Lu 7 Expires: September 7, 2011 March 7, 2011 9 Supporting Shared Mesh Protection in MPLS-TP Networks 11 draft-pan-shared-mesh-protection-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to publish it 26 as an RFC and to translate it into languages other than English. 28 This document may contain material from IETF Documents or IETF 29 Contributions published or made publicly available before November 30 10, 2008. The person(s) controlling the copyright in some of this 31 material may not have granted the IETF Trust the right to allow 32 modifications of such material outside the IETF Standards Process. 33 Without obtaining an adequate license from the person(s) controlling 34 the copyright in such materials, this document may not be modified 35 outside the IETF Standards Process, and derivative works of it may 36 not be created outside the IETF Standards Process, except to format 37 it for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on September 7, 2011. 58 Copyright Notice 60 Copyright (c) 2011 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with 68 respect to this document. 70 Abstract 72 Shared mesh protection is a common protection and recovery mechanism 73 in transport networks, where multiple paths can share the same set 74 of network resources for protection purposes. 76 In the context of MPLS-TP, it has been explicitly requested as a 77 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). 79 It's important to note that each MPLS-TP LSP may be associated with 80 transport network resources. In event of network failure, it may 81 require explicit activation on the protecting paths before switching 82 user traffic over. 84 In this memo, we define a lightweight signaling mechanism for 85 protecting path activation in shared mesh protection-enabled MPLS-TP 86 networks. 88 Table of Contents 90 1. Introduction...................................................3 91 2. Background and Problem Definition..............................4 92 3. Protection Switching...........................................6 93 4. Activation Operation Overview..................................7 94 5. Protocol Definition............................................8 95 5.1. Activation Messages.......................................8 96 5.2. Message Encapsulation.....................................9 97 5.3. Reliable Messaging.......................................11 98 5.4. Message Scoping..........................................12 99 6. Processing Rules..............................................12 100 6.1. Enable a protecting path.................................12 101 6.2. Disable a protecting path................................13 102 6.3. Get protecting path status...............................13 103 6.4. Acknowledgement with STATUS..............................14 104 6.5. Preemption...............................................14 105 7. Security Consideration........................................14 106 8. IANA Considerations...........................................14 107 9. Normative References..........................................14 108 10. Acknowledgments..............................................15 110 1. Introduction 112 Shared mesh protection is a common protection and recovery mechanism 113 in transport networks, where multiple paths can share the same set 114 of network resources for protection purposes. 116 In the context of MPLS-TP, it has been explicitly requested as a 117 part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]).Its 118 operation has been further outlined in Section 4.7.6 of MPLS-TP 119 Survivability Framework [2]. 121 It's important to note that each MPLS-TP LSP may be associated with 122 transport network resources. In event of network failure, it may 123 require explicit activation on the protecting paths before switching 124 user traffic over. 126 In this memo, we define a lightweight signaling mechanism for 127 protecting path activation in shared mesh protection-enabled MPLS-TP 128 networks. 130 Here are the key design goals: 132 1. Fast: The protocol is to activate the previously configured 133 protecting paths in a timely fashion, with minimal transport and 134 processing overhead. The goal is to support 50msec end-to-end 135 traffic switch-over in large transport networks. 137 2. Reliable message delivery: Activation and deactivation operation 138 have serious impact on user traffic. This requires the protocol to 139 adapt a low-overhead reliable messaging mechanism. 141 3. Modular: Depending on deployment scenarios, the signaling may need 142 to support functions such as preemption, resource re-allocation 143 and bi-directional activation in a modular fashion. 145 Here are some of the conventions used in this document. The key 146 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC-2119 [RFC2119]. 150 2. Background and Problem Definition 152 In this section, we describe the operation of shared mesh protection 153 in the context of MPLS-TP networks, and outline some of the relevant 154 definitions. 156 We refer to the figure below for illustration: 158 ----- B ------- C ---- 159 / \ 160 / \ 161 A D 162 \ / 163 \ / 164 ==== E === F === G === 165 / \ 166 / \ 167 H K 168 \ / 169 \ / 170 ----- I ------- J ---- 172 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 174 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 175 The links between E, F and G are shared by both protecting paths. 176 All paths are established via MPLS-TP control plane prior to network 177 failure. 179 All paths are assumed to be bi-directional. An edge node is denoted 180 as a headend or tailend for a particular path in accordance to the 181 path setup direction. 183 Initially, the operators setup both working and protecting paths. 184 During setup, the operators specify the network resources for each 185 path. 187 The working path X and Y will configure the appropriate resources on 188 the intermediate nodes, however, the protecting paths, X' and Y', 189 will reserve the resources on the nodes, but won't occupy them. 191 Depending on network planning requirements (such as SRLG), X' and Y' 192 may share the same set of resources on node E, F and G. The resource 193 assignment is a part of the control-plane CAC operation taking place 194 on each node. 196 At some time, link B-C is cut. Node A will detect the outage, and 197 initiate activation messages to bring up the protecting path X'. The 198 intermediate nodes, E, F and G will program the switch fabric and 199 configure the appropriate resources. Upon the completion of the 200 activation, A will switch the user traffic to X'. 202 The operation may have extra caveat: 204 1. Preemption: Protecting paths X' and Y' may share the same 205 resources on node E, F or G due to resource constraints. Y' has 206 higher priority than that of X'. In the previous example, X' is 207 up and running. When there is a link outage on I-J, H can 208 activate its protecting path Y'. On E, F or G, Y' can take over 209 the resources from X' for its own traffic. The behavior is 210 acceptable with the condition that A should be notified about 211 the preemption action. 213 2. Over-subscription (1:N): A unit of network resource may be 214 reserved by one or multiple protecting paths. In the example, 215 the network resources on E-F and F-G are shared by two 216 protecting paths, X' and Y'. In deployment, the over- 217 subscription ratio is an important factor on network resource 218 utilization. 220 3. Bi-direction Activation: The bi-directional paths can activate 221 protection from both headend and tailend independently. In the 222 example, upon the failure on link B-C, both A and D can trigger 223 the activation of the protecting path X'. This procedure may 224 improve the switch-over performance; however, it requires 225 additional coordination between network nodes. 227 3. Protection Switching 229 The entire activation and switch-over operation need to be within 230 the range of milliseconds to meet customer's expectation. In this 231 section, we illustrate how this may be achieved on MPLS-TP-enabled 232 transport switches. Note that this is for illustration of protection 233 switching operation, not mandating the implementation itself. 235 The diagram below illustrates the operation. 237 +---------------+ 238 Control | MPLS-TP | Control 239 <=== Signaling ====| Control Plane |=== Signaling ===> 240 +---------------+ 241 / \ 242 / \ (MPLS label assignment) 243 / \ 244 / \ 245 +-------+ +------+ +-------+ 246 Activation |Line | |Switch| |Line | Activation 247 <=== Messages ===|Module |===|Fabric|===|Module |=== Messages ===> 248 +-------+ +------+ +-------+ 250 A typical MPLS-TP user flow (or, LSP) is bi-directional, with a MPLS 251 label for each of the upstream and downstream traffic. On this 252 particular type of transport switch, the control-plane can download 253 the labels to the line modules. Subsequently, the line module will 254 maintain a label lookup table on all working and protecting paths. 256 Upon the detection of network failure, the headend nodes will 257 transmit activation messages along the MPLS LSP's. When receiving 258 the messages, the line modules can locate the associated protecting 259 path from the label lookup table, and perform activation procedure 260 by programming the switching fabric directly. Upon its success, the 261 line module will swap the label, and forward the activation messages 262 to the next hop. 264 In summary, the activation procedure involves efficient path lookup 265 and switch fabric re-programming. 267 To achieve the tight end-to-end switch-over budget, it's possible to 268 implement the entire activation procedure with hardware-assistance 269 (such as in FPGA or ASIC). 271 The activation messages are encapsulated with a MPLS-TP Generic 272 Associated Channel Header (GACH) [3]. Detailed message encoding is 273 explained in Section 5. 275 4. Activation Operation Overview 277 In this section, we describe the activation procedure using the same 278 figure shown before: 280 ----- B ------- C ---- 281 / \ 282 / \ 283 A D 284 \ / 285 \ / 286 ==== E === F === G === 287 / \ 288 / \ 289 H K 290 \ / 291 \ / 292 ----- I ------- J ---- 294 Working paths: X = {A, B, C, D}, Y = {H, I, J, K} 296 Protecting paths: X' = {A, E, F, G, D}, Y' = {H, E, F, G, K} 298 Upon the detection of working path failure, the edge nodes, A, D, H 299 and K may trigger the activation messages to activate the protecting 300 paths, and redirect user traffic immediately after. 302 We assume that there is a consistent definition of priority levels 303 among the paths throughout the network. At activation time, each 304 node may rely on the priority levels to potentially preempt other 305 paths. 307 When the nodes detect path preemption on a particular node, they 308 should inform all relevant nodes to free the resources. 310 To optimize traffic protection and resource management, each headend 311 should periodically poll the protecting paths about resource 312 availability. The intermediate nodes have the option to inform the 313 current resource utilization. 315 Note that, upon the detection of a working path failure, both 316 headend and tailend may initiate the activation simultaneously 317 (known as bi-directional activation). This may expedite the 318 activation time. However, both headend and tailend nodes need to 319 coordinate the order of protecting paths for activation, since there 320 may be multiple protecting paths for each working path (i.e., 1:N 321 protection). For clarity, we will describe the operation from 322 headend in the memo. The tailend operation will be available in the 323 subsequent revisions. 325 5. Protocol Definition 327 5.1. Activation Messages 329 The activation requires the following messages: 331 o ENABLE: this is initiated by the headend nodes to activate a 332 protecting path 334 o DISABLE: this is initiated by the headend nodes to disable a 335 protecting path and free the associated network resources 337 o GET: this is initiated by the headend to gather resource 338 availability information on a particular protecting path 340 o NOTIFY: this is initiated by the intermediate nodes and terminate 341 on the headend nodes to report preemption or protection failure 342 conditions 344 o STATUS: this is the acknowledgement message for ENABLE, DISABLE, 345 GET, and NOTIFY messages, and contains the relevant status 346 information 348 Each activation message has the following format: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |Version| Type | Reserved | Seq | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Additional Info | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 o Version: 1 360 o Type: 362 o ENABLE 1 364 o DISABLE 2 366 o GET 3 368 o STATUS 4 370 o NOTIFY 5 372 o Reserved: This field is reserved for future use 374 o Seq: This uniquely identifies a particular message. This field is 375 defined to support reliable message delivery 377 o Additional Info: the message-specific data 379 5.2. Message Encapsulation 381 Activation messages use MPLS labels to identify the paths. Further, 382 the messages are encapsulated in GAL/GACH: 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | MPLS Label stack | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | GAL | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |0 0 0 1|Version| Reserved | Activation Channel Type | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | ACH TLV Header | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Activation Message Payload | 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 o GAL is described in [3] 401 o Activation Channel Type is the GACH channel number assigned to 402 the protocol. This uniquely identifies the activation messages. 404 o ACH TLV Header contains the message length, and is described in 405 [3] 407 Specifically, ENABLE, DISABLE and GET messages have the following 408 message format: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Label | Exp |S| TTL (1) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Label (13) | Exp |S| TTL | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |0 0 0 1|Version| Reserved | Activation Channel Type | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Length | Reserved | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Ver(1)| Type | Reserved (0) | Seq | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Both STATUS and NOTIFY messages have the following message format: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Label | Exp |S| TTL (1) | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Label (13) | Exp |S| TTL | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |0 0 0 1|Version| Reserved | Activation Channel Type | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Length | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Ver(1)| Type | Reserved (0) | Seq | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Status Code | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Currently, the status code has the following definition: 444 o 1xx: OK 446 . 101: end-to-end ack 448 o 2xx: message processing errors 450 . 201: no such path 452 o 3xx: processing issues: 454 . 301: no more resource for the path 456 . 302: preempted by another path 458 . 303: system failure 460 o 4xx: informative data: 462 . 401: shared resource has been taken by other paths 464 5.3. Reliable Messaging 466 The activation procedure adapts a simple two-way handshake reliable 467 messaging. 469 Each node maintains a sequence number generator. Each new sending 470 message will have a new sequence number. After sending a message, 471 the node will wait for a response with the same sequence number. 473 Specifically, upon the generation of ENABLE, DISABLE, GET and NOTIFY 474 messages, the message sender expects to receive a STATUS in reply 475 with same sequence number. 477 If a sender is not getting the reply (STATUS) within a time 478 interval, it will retransmit the same message with a new sequence 479 number, and starts to wait again. After multiple retries (by 480 default, 3), the sender will declare activation failure, and alarm 481 the operators for further service. 483 5.4. Message Scoping 485 Activation signaling uses MPLS TTL to control how far the message 486 would traverse. Here are the processing rules on each intermediate 487 node: 489 o On receive, if the message has TTL = 0, the node must drop the 490 packet without further processing 492 o The receiving node must always decrement the TTL value by one. If 493 TTL = 0 after the decrement, the node must process the message. 494 Otherwise, the node must forward the message without further 495 processing (unless, of course, the node is headend or tailend) 497 o On transmission, the node will adjust the TTL value. For hop-by- 498 hop messages, TTL = 1. Otherwise, TTL = 0xFF, by default. 500 6. Processing Rules 502 6.1. Enable a protecting path 504 Upon the detection of network failure on a working path, the headend 505 node initiates the protection switching by sending an ENABLE 506 message. 508 ENABLE messages always use MPLS TTL one to force hop-by-hop process. 509 Upon reception, a next-hop node will locate the corresponding path 510 and activate the path. 512 The headend node will declare the success of the activation only 513 when it gets a positive reply from the tailend node. This requires 514 that the tailend nodes must reply STATUS messages to the headend 515 nodes in all cases. 517 If the headend node is not receiving the acknowledgement within a 518 time internal, it will retransmit another ENABLE message with a 519 different Seq number. 521 If the headend node is not receiving a positive reply within a 522 longer time interval, it will declare activation failure. 524 If an intermediate node cannot activate a protecting path, it will 525 reply an NOTIFY message to report failure. When the headend node 526 receives a NOTIFY message, it must initiate DISABLE messages to 527 clean up networks resources on all the relevant nodes on the path. 529 6.2. Disable a protecting path 531 The headend removes the network resources on a path by sending 532 DISABLE messages. 534 In the message, the MPLS label represents the path to be de- 535 activated. The MPLS TTL is one to force hop-by-hop processing. 537 Upon reception, a node will de-activate the path, by freeing the 538 resources from the data-plane. 540 As a part of the clean-up procedure, each DISABLE message must 541 traverse through and be processed on all the nodes of the 542 corresponding path. When the DISABLE message reaches to the tailend 543 node, the tailend is required to reply with a STATUS message to the 544 headend. 546 The de-activation process is complete when the headend receives the 547 corresponding STATUS message from the tailend. 549 6.3. Get protecting path status 551 The operators have the option to trigger GET messages from the 552 headend to check on the protecting path periodically or on-demand. 553 The process procedure on each node is very similar to that of ENABLE 554 messages on the intermediate nodes, except the GET messages should 555 not trigger any path re-programming. 557 Upon reception, the node will check the availability of resources. 559 If the resource is no longer available, the node will reply a NOTIFY 560 with error conditions. 562 6.4. Acknowledgement with STATUS 564 The STATUS message is the acknowledgement packet to all messages, 565 and may be generated by any node in the network. 567 Each STATUS message must use the same sequence number as the 568 corresponding message (ENABLE, DISABLE, GET and NOTIFY). 570 When replying to headend, the tailend nodes must originate STATUS 571 messages will a large MPLS TTL value (0xff, by default). 573 6.5. Preemption 575 The preemption operation typically takes place when processing an 576 ENABLE message. 578 If the activating network resources have been used by another path 579 and carrying user traffic, the node needs to compare the priority 580 levels. 582 If the existing path has higher priority, the node needs to reject 583 the ENABLE message by sending a STATUS message to the corresponding 584 headend to inform the unavailability of network resources. 586 If the new path has higher priority, the node will reallocate the 587 resource to the new path, and send an NOTIFY message to old path's 588 headend node to inform about the preemption. 590 7. Security Consideration 592 The protection activation takes place in a controlled networking 593 environment. Nevertheless, it is expected that the edge nodes will 594 encapsulate and transport external traffic into separated tunnels, 595 and the intermediate nodes will never have to process them. 597 8. IANA Considerations 599 Activation messages are encapsulated in MPLS-TP with a specific GACH 600 channel type that needs to be assigned by IANA. 602 9. Normative References 604 [1] RFC 5654: Requirements of an MPLS Transport Profile, B. Niven- 605 Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno, 606 September 2009 608 [2] IETF draft, Multiprotocol Label Switching Transport Profile 609 Survivability Framework (draft-ietf-mpls-tp-survive-fwk- 610 06.txt), N. Sprecher, A. Farrel, June 2010 612 [3] RFC5586 - Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, 613 R., and D. Ward, "MPLS Generic Associated Channel", May 2009. 615 [4] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [5] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 619 Syntax Specifications: ABNF", RFC 2234, Internet Mail 620 Consortium and Demon Internet Ltd., November 1997. 622 10. Acknowledgments 624 Authors like to thank Maneesh Jain, Mohit Misra, Yalin Wang, Ted 625 Sprague, Ann Gui and Tony Jorgenson for review and feedback. 627 Authors' Addresses 629 Ping Pan 630 Email: ppan@infinera.com 632 Sri Mohana Satya Srinivas Singamsetty 633 Email: ssingamsetty@infinera.com 635 Rajan Rao 636 Email: rrao@infinera.com 638 Biao Lu 639 Email: blu@infinera.com