idnits 2.17.1 draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5493]), 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 a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 08, 2010) is 5222 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) == Missing Reference: 'RFC 3473' is mentioned on line 635, but not defined == Unused Reference: 'RFC3471' is defined on line 850, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Caviglia 3 Internet-Draft D. Ceccarelli 4 Intended status: Standards Track D. Bramanti 5 Expires: July 12, 2010 Ericsson 6 D. Li 7 Huawei Technologies 8 S. Bardalai 9 Fujitsu Network 10 January 08, 2010 12 RSVP-TE Signaling Extension For Management Plane To Control Plane LSP 13 Handover In A GMPLS Enabled Transport Network. 14 draft-ietf-ccamp-pc-spc-rsvpte-ext-05 16 Abstract 18 In a transport network scenario, where Data Plane connections are 19 controlled either by a Generalized Multi-Protocol Label Switching 20 (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a 21 Management System (Permanent Connections - PC) may independently 22 coexist, the ability of transforming an existing PC into a SPC and 23 vice versa - without actually affecting Data Plane traffic being 24 carried over it - is a requirement. The requirements for the 25 conversion between permanent connections and switched connections in 26 a GMPLS Network are defined in [RFC5493]. 28 This memo describes an extension to GMPLS RSVP-TE signaling that 29 enables the transfer of connection ownership between the Management 30 and the Control Planes. Such a transfer is referred to as a 31 Handover. This document defines all Handover related procedures. 32 This includes the handling of failure conditions and subsequent 33 reversion to original state. A basic premise of the extension is 34 that the handover procedures must never impact an already established 35 Data plane. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on July 12, 2010. 60 Copyright Notice 62 Copyright (c) 2010 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Dedication . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4.1. MP to CP handover: LSP Ownership Transfer From 83 Management Plane To Control Plane . . . . . . . . . . . . 5 84 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 85 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7 86 4.2.1.1. MP to CP Handover Failure - Path message and 87 Data Plane Failure . . . . . . . . . . . . . . . . 7 88 4.2.1.2. MP to CP Handover Failure - Path message and 89 Communication failure . . . . . . . . . . . . . . 8 90 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 9 91 4.2.2.1. MP to CP Handover Failure - Resv Error and 92 Data Plane failure . . . . . . . . . . . . . . . . 9 93 4.2.2.2. MP to CP Handover Failure - Resv Error and 94 Communication failure . . . . . . . . . . . . . . 10 95 4.2.2.3. MP to CP Handover Failure - Node Graceful 96 Restart . . . . . . . . . . . . . . . . . . . . . 11 97 4.3. CP to MP handover : LSP Ownership Transfer From 98 Control Plane To Management Plane . . . . . . . . . . . . 14 99 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 14 100 5. Minimum Information for MP to CP Handover . . . . . . . . . . 16 101 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 17 102 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 103 7.1. Administrative Status Object . . . . . . . . . . . . . . . 17 104 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 17 105 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 106 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 107 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 108 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 109 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 112 13.2. Informational References . . . . . . . . . . . . . . . . . 21 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 115 1. Introduction 117 In a typical traditional transport network scenario, Data Plane (DP) 118 connections between two endpoints are controlled by means of a 119 Network Management System (NMS) operating within Management Plane 120 (MP). NMS/MP is the owner of such transport connections, being 121 responsible of their set up, tear down and maintenance. 123 The adoption of a Generalized MPLS (GMPLS) [RFC3945] Control Plane 124 (CP) in a network that is already in service - controlled by NMS at 125 MP level - introduces the need for a procedure able to coordinate a 126 controlled handover of a data plane connection from MP to CP. 128 In addition, the control handover in the opposite direction, from CP 129 to MP should be possible as well. The procedures described in this 130 memo can be applied to an LSP in any DP switching technology and any 131 network architecture. 133 This memo describes an extension to GMPLS RSVP-TE signaling that 134 enables the handover of connection ownership between the Management 135 and the Control Planes. All handover related procedures are defined 136 below. This includes the handling of failure conditions and 137 subsequent reversion to original state. A basic premise of the 138 extension is that the handover procedures must never impact the 139 exchange of user data on LSPs that are already established in the DP. 141 1.1. Dedication 143 We would like to dedicate this work to our friend and colleague Dino 144 Bramanti, who passed away at the early age of 38. Dino has been 145 involved in this work since its beginning. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Motivation 155 The main motivation behind this work is the definition of a simple 156 and very low impact procedure that satisfies the requirements defined 157 in [RFC5493]. Such a procedure is aimed at giving the transport 158 network operators the chance to handover the ownership of existing 159 LSPs provisioned by NMS from the MP to the CP without disrupting user 160 traffic flowing on them. Handover from MP to CP (i.e. when existing 161 DP connection ownership and control is passed from MP to CP) has been 162 defined as a mandatory requirement, while the opposite operation, CP 163 to MP handover, has been considered as a nice-to-have feature that 164 can be seen as an emergency procedure to disable the CP and take the 165 manual control of the LSP. For more details on requirements and 166 motivations please refer to [RFC5493]. 168 4. Procedures 170 The modification defined in this document refers only to the 171 ADMIN_STATUS Object, that is, the message flow is left unmodified for 172 both LSP set-up and deletion. Moreover a new Error Value is defined 173 to identify the failure of a Handover procedure. 175 The following paragraphs give detailed description of the "MP to CP 176 handover" and "CP to MP handover" procedures, based on the usage a 177 newly defined bit called H bit. 179 The MP to CP handover procedures support two different methods for 180 retrieving required information. The primary one consists of 181 receiving the full Explicit Route Object (ERO) from the MP while the 182 alternative one is described in Section 5. 184 Please note that if the primary method is used the labels SHOULD be 185 included in the ERO and for bidirectional LSPs both upstream and 186 downstream labels SHOULD be included. Per Section 5.1.1. of 187 [RFC3473], the labels are indicated on an output basis. As 188 described, this means that the labels are used by the upstream node 189 to create the LABEL_SET Object and, for bidirectional LSPs, 190 UPSTREAM_LABEL Object used in the outgoing Path message. 192 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 193 Control Plane 195 The MP to CP handover procedure MUST create an RSVP-TE session along 196 the path of the LSP to be moved from MP to CP, associating it to the 197 existing cross-connected resources owned by the MP (e.g. lambdas, 198 time slots or reserved bandwidth) and at the same time transferring 199 their ownership to the CP. 201 The operator instructs the ingress node to handover control of the 202 LSP from the MP to the CP. In this handover mode, it supplies the 203 exact path of the LSP including any resource reservation and label 204 information. 206 The ingress MUST check that no corresponding Path state exists and 207 that corresponding Data Plane state does exist. If there is an 208 error, this MUST be reported to the operator and further protocol 209 action MUST NOT be taken. 211 The ingress signals the LSP using a Path message with the H bit and R 212 bit set in the ADMIN_STATUS object. In this mode of handover, the 213 Path message also carries an ERO that includes Label subobjects 214 indicating the labels used by the LSP at each hop. The ingress MUST 215 start the Expiration timer (see Section 4.2.1.2 for expiration of 216 this timer). Such timer SHOULD be configurable per LSP. 218 Each LSR that receives a Path message with the H bit set checks to 219 see whether there is any matching Path state. 221 - If matching Path state is found with the H bit set, this is a 222 Path refresh and should be treated accordingly [RFC3473]. 223 - If matching Path state is found with the H bit clear, this is an 224 error and MUST be treated according to the error case description 225 in Section 4.2.xx 226 - If no Path state is found, the LSR goes on to check whether 227 there is any matching Data Plane state. 228 - If no matching Data Plane state is found (including only 229 partially matching Data Plane state), this is an error or a race 230 condition. It MUST be handled according to the description in 231 Section 4.2.xx 232 - If matching Data Plane state is found, the LSR MUST save the 233 Path state (including the set H bit), and MUST forward the Path 234 message to the egress. The LSR MUST retain any MP state 235 associated with the LSP at this point. 237 An egress LSR MUST act as any other LSR, except that there is no 238 downstream node to which to forward the Path message. If all checks 239 are passed, the egress MUST respond with a Resv with the H bit set. 241 A transit LSR MUST process each Resv according to the normal rules of 242 [RFC3473]. 244 When an ingress LSR receives a Resv message carrying the H bit set, 245 it checks the Expiration Timer. 247 - If the timer is not running, the Resv is treated as a refresh and 248 no special action is taken [RFC3473]. 250 - If the timer is running, the ingress MUST cancel the timer and MAY 251 notify the operator that the first stage of handover is complete. 252 The ingress MUST send a Path message that is no different from the 253 previous message except that the H bit MUST be clear. 255 The Path message with the H bit clear will travel the length of the 256 LSP and will result in the return of a Resv with the H bit clear 257 according to normal processing [RFC3473]. As a result, the H bit 258 will be cleared in the stored Path state at each transit LSR and at 259 the egress LSR. Each LSR SHOULD release any associated MP state 260 associated with the LSP when it receives the Path message with H bit 261 clear. 263 When the ingress receives a Resv with the H bit clear, the handover 264 is completed. The ingress SHOULD notify the operator that the 265 handover is correctly completed. 267 4.2. MP to CP Handover Procedure Failure Handling 269 In the case of MP to CP Handover, two different failure scenarios can 270 happen: Path Failure and Resv Failure. Moreover, each failure can be 271 due to two different causes: DP failure or Communication Failure. In 272 any case the LSP ownership MUST be immediately rolled back to the one 273 previous to the handover procedure. A section for each combination 274 will be analyzed in the following. 276 4.2.1. MP to CP Handover Failure - Path Failure 278 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 279 Failure 281 In this paragraph we will analyze the case where the handover 282 procedure fails during the Path message processing. 284 | Path | | | 285 |--------------->| Path | | 286 | |---------------X| | 287 | | PathErr | | 288 | PathErr |<---------------| | 289 |<---------------| | | 290 | | | | 291 Ingress LER LSR A LSR B Egress LER 293 MP2CP - Path Msg and DP Failure 295 If an error occurs in an LSR or a LER, the last node that has 296 received the Path message MUST send a PathErr message in the upstream 297 direction and the handover procedure is aborted. Upon receiving the 298 PathErr message the Path state of the node MUST be removed. The 299 PathErr message SHOULD have the Path_State_Removed flag set. 301 Nodes receiving a PathErr message MUST follow standard PathErr 302 message processing with the exception that when their local state 303 indicates that a Handover is in progress (based on the H bit in the 304 Path message) the associated DP resources MUST NOT be impacted during 305 such processing and the LSR MUST revert the LSP ownership to the MP. 307 4.2.1.2. MP to CP Handover Failure - Path message and Communication 308 failure 310 Other possible scenarios are shown in the following pictures and are 311 based on the inability to reach a node along the path of the LSP. 313 The below scenario postulates the usage of a reliable message 314 delivery based on the mechanism defined in [RFC2961]. 316 | Path | | | 317 |--------------->| Path | | 318 | |---------------X| | 319 | |---------------X| | 320 | | ... | | 321 | |---------------X| | 322 | | | | 323 Ingress LER LSR A LSR B Egress LER 325 MP2CP - Path Msg and Communication Failure (reliable delivery) 327 The Path message sent from LSR A towards LSR B is lost or does not 328 reach the destination for any reason. As a reliable delivery 329 mechanism is implemented, LSR A retransmits the Path message for a 330 configurable number of times and if no ack is received the handover 331 procedure will be aborted (via the Expiration timer). 333 In the next scenario RSVP-TE messages are sent without reliable 334 message delivery, that is, no [RFC2961] MessageID procedure is used. 336 | Path | | | 337 |--------------->| Path | | 338 | |----------X | | 339 | | | | 340 TIMER EXPIRES | | | 341 | Path Tear | Path Tear | Path Tear | 342 |--------------->|--------------->|--------------->| 343 | | | | 344 Ingress LER LSR A LSR B Egress LER 346 MP2CP - Path Msg and Communication Failure (no reliable delivery) 348 If the Resv message is not received before the expiration of the 349 Expiration timer the handover procedure is aborted as described in 350 Section 4.1. Please note that any node that has forwarded a Path 351 (LSR A), i.e. has installed local path state, MUST send a PathTear 352 when that state is removed. 354 4.2.2. MP to CP Handover Failure - Resv Error 356 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 358 In the case of failure occurrence during the Resv message processing, 359 (in case there has been any change in the data plane during the 360 signaling) the node MUST send a PathErr message in the upstream 361 direction. The PathErr message is constructed and processed as 362 defined above in Section 4.2.1.1. The failure detection node MUST 363 also send a PathTear message downstream. The PathTear message is 364 constructed and processed as defined above in Section 4.2.1.1. 366 | Path | Path | Path | 367 |--------------->|--------------->|--------------->| 368 | | | Resv | 369 | | Resv |<---------------| 370 | |X---------------| | 371 | PathErr | PathTear | PathTear | 372 |<---------------|--------------->|--------------->| 373 | | | | 374 Ingress LER LSR A LSR B Egress LER 376 MP2CP - Resv Error and DP Failure 378 In the case shown in the above picture, the failure occurs in LSR A. 379 A PathTear message is sent towards B and a PathErr message (with 380 ErrorCode set to "Handover Procedure Failure") is sent in the 381 upstream direction. The PathErr and PathTear messages remove the 382 Path state established by the Path messages along the nodes of the 383 LSP and abort the handover procedure. 385 Please note that the failure occurred after the handover procedure 386 was successfully completed in LSR B, but Handover state will still be 387 maintained locally as, per Section 4.1, a Path message with the H bit 388 clear will have not yet been sent or received. A node that receives 389 a PahTear when it has Path state with the H bit set MUST remove Path 390 state, but MUST NOT change data plane state. It MUST return LSP 391 ownership to the MP. 393 4.2.2.2. MP to CP Handover Failure - Resv Error and Communication 394 failure 396 When a Resv message cannot reach one or more of the upstream nodes, 397 the procedure is quite similar to the one previously seen about the 398 Path message. Even in this case it is possible to distinguish two 399 different scenarios. 401 In the first scenario we consider the utilization of a reliable 402 message delivery based on the mechanism defined in [RFC2961]. After 403 a correct forwarding of the Path message along the nodes of the LSP, 404 the Egress LSR sends a Resv message in the opposite direction. It 405 might happen that the Resv message does not reach the ingress LER or 406 an LSR, say LSR A. LSR B MUST send a Resv message again for a 407 configurable number of times and then, if the delivery does not 408 succeed, the adoption procedure will be aborted (via the Expiration 409 timer). 411 | Path | Path | Path | 412 |--------------->|--------------->|--------------->| 413 | | | Resv | 414 | | Resv |<---------------| 415 | | X---------| | 416 | | X---------| | 417 | | ... | | 418 | | X---------| | 419 | | | | 420 Ingress LER LSR A LSR B Egress LER 422 MP2CP - Resv Error and Communication Failure (reliable delivery) 424 Considering that the Resv message did not manage to reach LSR A, it 425 is highly probable that the PathErr would fail too. Due to this 426 fact, the Expiration timer is used on the Ingress LER after sending 427 the path and on LSR A after forwarding it. When the timer expires, 428 if no Resv or PathErr message is received, the handover procedure is 429 aborted as described in Section 4.1 and the LSP ownership returned to 430 the Management Plane. 432 The following picture, on the other hand, shows the scenario in which 433 no reliable delivery mechanism is implemented. 435 | Path | Path | Path | 436 |--------------->|--------------->|--------------->| 437 | | | Resv | 438 | | Resv |<---------------| 439 | | X---------| | 440 TIMER EXPIRES | | | 441 | Path Tear | Path Tear | Path Tear | 442 |--------------->|--------------->|--------------->| 443 | | | | 444 Ingress LER LSR A LSR B Egress LER 446 MP2CP - Resv Error and Communication Failure (no reliable delivery) 448 If non Resv message is received before the Expiration timer expires, 449 the ingress LER follows the same procedure defined in Section 4.1. 451 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 453 In the case of node restart and graceful restart is enabled then one 454 of the following scenarios will happen. 456 Case I - Finite Restart Time 458 In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a 459 value of 0xffffffff. In the sequence diagram below, assume LSR A 460 restarts. If the ingress LER does not receive the Resv message in 461 time it MUST abort the handover process by generating a PathTear 462 message downstream. Also, if LSR A does not complete the restart 463 process within the restart time interval then LSR B MUST start 464 tearing down all LSPs between LSR A and LSR B and this includes the 465 LSP that is being used to carry out the handover of MP resources to 466 CP. LSP B MUST generate a PathTear message downstream and a PathErr 467 message upstream. Both LSR B and the egress LER MUST NOT release the 468 DP resources because in both nodes the H bit is set in the local Path 469 state. 471 | Path | Path | Path | 472 |--------------->|--------------->|--------------->| 473 | | | Resv | 474 | | Resv |<---------------| 475 | X X---------| | 476 | PathTear | | 477 |-------X Restart Timer | 478 | Expires | 479 | PathErr | PathTear | 480 | X--------|--------------->| 481 | | | 482 | X | | 483 | | | | 484 Ingress LER LSR A LSR B Egress LER 486 MP2CP - Node graceful restart - Case I 488 Case II - Infinite Restart Time 490 In this case, the Restart Time (see [RFC3473]) indicates that the 491 restart of the sender's control plane may occur over an indeterminate 492 interval, i.e., is 0xffffffff. The sequence is quite similar to the 493 previous one. In this sequence the restart timer will not expire in 494 LSR B since it is run infinitely. Instead after LSR A restarts LSR B 495 MUST start the recovery timer. The recovery timer will expire since 496 there will be no Path message with the RECOVERY LABEL received from 497 LSR A given the ingress node had already removed the local Path state 498 after it aborts the handover process. Thus LSR B MUST tear-down the 499 specific LSP that is being used to convert the MP resources to CP by 500 generating a PathTear message downstream and PathErr message 501 upstream. Similarly to the previous case both LSR B and the egress 502 LER MUST NOT release the DP resources because the H bit is set in the 503 local Path state. 505 | Path | Path | Path | 506 |--------------->|--------------->|--------------->| 507 | | | Resv | 508 | | Resv |<---------------| 509 | X X---------| | 510 | PathTear | | 511 |-------X | | 512 | | | 513 | X | | 514 | | | | 515 | | Recovery Timer | 516 | | Expires | 517 | PathErr | PathErr | PathTear | 518 |<---------------|<---------------|--------------->| 519 | | | | 520 Ingress LER LSR A LSR B Egress LER 522 MP2CP - Node graceful restart - Case II 524 Case III 526 Ingress LER did not abort the handover process. Once LSR A restarts 527 the ingress LER MUST re-generate the Path message with the H bit set. 528 When LSR B receives the Path message it MAY generate a PathErr since 529 the RECOVERY LABEL may not be present. The reason is LSR A may not 530 have the label. Similarly LSR B and egress LER MUST NOT release the 531 DP resources since the H bit is set. 533 | Path | Path | Path | 534 |--------------->|--------------->|--------------->| 535 | | | Resv | 536 | | Resv |<---------------| 537 | X X---------| | 538 | | | 539 | X | | 540 | | | | 541 | Path | Path | | 542 |--------------->|--------------->| | 543 | PathErr | PathErr | PathTear | 544 |<---------------|<---------------|--------------->| 545 | | | | 546 Ingress LER LSR A LSR B Egress LER 548 MP2CP - Node graceful restart - Case III 550 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To 551 Management Plane 553 Let's now consider the case of LSP Ownership Transfer From Control 554 Plane To Management Plane. Also in this section we will analyze the 555 handover procedure success and failure. 557 The scenario is still a DP connection between two nodes acting as 558 ingress and egress for a LSP, but in this case the CP has the 559 ownership and control of the LSP. The CP to MP handover procedure 560 MUST delete the existing RSVP-TE session information and MUST NOT 561 affect the cross-connected resources, but just move their ownership 562 to the MP. 564 In other words, after LSP ownership transfer from CP to MP, the LSP 565 is no longer under control of RSVP-TE, which is no more able to "see" 566 the LSP itself. The CP to MP handover procedure MUST be a standard 567 LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. 568 The procedure is initiated at the ingress node of the LSP by a MP 569 entity. Ingress node and MP exchange the relevant information for 570 this task and then propagate it over CP by means of RSVP-TE tear down 571 signaling as described below. 573 The ingress node MUST send a Path message in the downstream direction 574 with Handover and Reflect bits set in the ADMIN_STATUS Object. No 575 action is taken over the DP and transit LSRs must forward such 576 message towards the egress node. All of the nodes MUST keep track of 577 the procedure storing the H bit in their local Path and Resv states. 578 Then every node waits for the H bit to be received within the related 579 Resv message. After the Resv message is received by the ingress LER, 580 it MUST send a PathTear message in order to clear the whole LSP 581 information recorded on the RSVP-TE data structures of the nodes. 582 Downstream nodes processing a PathTear message which follows a Path 583 message with the H bit set, MUST NOT remove any associated data plane 584 state. In other words, a normal LSP tear down signaling is exchanged 585 between nodes traversed by the LSP, but H bit set in the Path message 586 indicates that no DP action has to correspond to CP signaling. 588 4.4. CP to MP Handover Procedure Failure 590 Failures during CP to MP handover procedure MUST NOT result in the 591 removal of any associated data plane state. To that end, when a Resv 592 message containing an ADMIN_STATUS Object with the H bit is not 593 received during the period of time described in Section 7.2.2. of 594 [RFC3473] different processing is required. Specifically, the 595 ingress node MUST NOT send a PathTear message before a Resv message 596 containing the H bit is received. The ingress node MAY choose to 597 report the failure in the CP to MP handover procedure via the MP. 599 The CP to MP handover procedure can fail also due to two causes: 600 PathTear lost or node down. In the former case, if the LSP is not 601 under MP control after the Expiration Timer elapses, a manual 602 intervention from the network operator is requested, while in the 603 latter case different scenarios may happen: 605 - CASE I - Path message and node down 607 | Path | Path X | 608 |--------------->|--------------X | 609 | | | 610 | | X | 611 | | | | 612 | | | | 613 Ingress LER LSR A LSR B Egress LER 615 Per [RFC 3473] section 7.2.2 the ingress node should wait for a 616 configurable amount of time (30 seconds by default) and then send a 617 PathTear message. In this case the normal deletion procedure MUST 618 NOT be followed. When the Expiration timer elapses a manual 619 intervention from network operator is requested. 621 - CASE II - Resv message and node down 623 | Path | Path | Path | 624 |--------------->|--------------->|--------------->| 625 | | | Resv | 626 | | Resv |<---------------| 627 | X X---------| | 628 | | | 629 | X | | 630 | | | | 631 Ingress LER LSR A LSR B Egress LER 633 The procedure to be followed is the same depicted in CASE I. The 634 network operator can ask for the automatic CP to MP procedure again 635 after the failed node comes back up. Per [RFC 3473] section 7.2 the 636 nodes will forward the new Path and Resv messages correctly. 638 - CASE III - PathTear message and node down 639 | Path | Path | Path | 640 |--------------->|--------------->|--------------->| 641 | Resv | Resv | Resv | 642 |<---------------|<---------------|<---------------| 643 | PathTear | | | 644 |--------------->| PathTear X | 645 | |------------X | 646 | | X | 647 | | | | 648 Ingress LER LSR A LSR B Egress LER 650 This scenario can be managed as a normal PathTear lost described 651 above in this section. 653 5. Minimum Information for MP to CP Handover 655 An alternative way of getting the LSP related information required 656 for the MP to CP handover is also defined in this draft. The 657 rationale behind this way is that only a minimal set of information 658 is handed over from MP to CP at LSPs Ingress node. Instead of 659 collecting within MP all the LSP relevant information down to the 660 Label level, formatting it to an ERO and passing it to CP, as in 661 previously described solution, it is possible to start with a minimum 662 amount of information. The full ERO method and the partial/no ERO 663 one do not exclude each other; both methods are required. 665 At the ingress node, the information needed to specify the LSP is the 666 outgoing interface ID, upstream label and downstream label of this 667 interface and the egress node ID. The remaining information about an 668 existing LSP can then be collected hop by hop, as the signaling is 669 going on, by looking up the cross-connection table in DP at each node 670 along the LSP path. 672 Starting from the information available at ingress LER about the 673 outgoing interface ID of that ingress node, the incoming interface ID 674 of next hop can be found by looking up the link resource table/ 675 database in the LER itself. 677 The Path message is hence built with the LABEL_SET Object ([RFC3473]) 678 and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label 679 and downstream label of ingress outgoing interface of the LSP are 680 included in these two objects. In addition to above mentioned 681 objects, the Path message MUST include the ADMIN_STATUS Object with H 682 bit set, as already defined in previous chapters for the detailed ERO 683 based way of proceeding. Such handover Path is sent to the incoming 684 interface of next hop. When this Path message reaches the second 685 node along the LSP path, the information about incoming interface ID 686 and the upstream and downstream labels of this interface is extracted 687 from it and it is used to find next hop outgoing interface ID and the 688 upstream/downstream labels by looking up the DP cross-connection 689 table. 691 After having determined in this way the parameters describing the 692 LSPs next hop, the outgoing Path message to be sent is built 693 replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with 694 the looked-up values of upstream and downstream labels. 696 By repeating this procedure for each transit node along the LSP, it 697 is possible to make the handover Path message reach the egress node, 698 exactly following the LSP that is in place over DP. The ERO MAY in 699 this case be included in the Path message as an optional object, and 700 MAY be filled with the LSP relevant information down to either the 701 port level with interface ID or the Label level with upstream and 702 downstream labels. The ERO can be used to check the consistency of 703 resource in DP down to the port level or label level at each 704 intermediate node along the LSP path. 706 Where the DP path continues beyond the egress, by indicating the 707 Egress label at the head-end of an LSP, the traffic can be directed 708 to the right destination. The GMPLS Signaling Procedure for Egress 709 Control is described in [RFC4003] 711 6. RSVP Message Formats 713 This memo does not introduce any modification in RSVP messages object 714 composition. 716 7. Objects Modification 718 The modifications required concern two RSVP objects: the ADMIN_STATUS 719 and the ERROR_SPEC Object. 721 7.1. Administrative Status Object 723 This memo introduces a new flag into the ADMIN_STATUS object. The 724 ADMIN_STATUS Object is defined in [RFC3473]. This document uses the 725 H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by 726 IANA) (25). 728 7.2. Error Spec Object 730 It is possible that a failure, such as the loss of DCN connection or 731 the restart of a node, occurs during the LSP ownership handing over. 733 In this case the LSP handover procedure is interrupted, the ownership 734 of the LSP must remain with the ownership prior to the initiation of 735 the handover procedure. It is important that the transaction failure 736 does not affect the DP. The LSP is kept in place and no traffic hit 737 occurs. 739 The failure is signaled by PathErr in the upstream direction and 740 PathTear Messages in the downstream direction. The PathErr messages 741 include an ERROR_SPEC Object specifying the causes of the failure. 743 This memo introduces a new Error Code (with different Error Values) 744 into the ERROR_SPEC Object, defined in [RFC2205]. 746 The defined Error Code is "Handover Procedure Failure", and its value 747 is (TBD by IANA)(35). For this Error Code the following Error Values 748 are defined: 750 1 = Cross-connection mismatch 752 2 = Other failure 754 8. Compatibility 756 The main requirement for Handover procedure to work is that all nodes 757 along the path MUST support the extension defined in this draft. 758 This requirement translates to an administrative requirement as it is 759 not enforced at the protocol level. As defined, non-supporting will 760 simply propagate the H bit without setting local state. This may 761 result in an impact data traffic during the handover procedure. 763 9. Acknowledgments 765 We wish to thank Adrian Farrel and Lou Berger for their assistance 766 and precious advices to prepare this draft for publication. We also 767 wish to thank Nicola Ciulli (Nextworks), that contributed to the 768 initial stage of this draft. 770 10. Contributors 772 Shan Zhu 773 Fujitsu Network Communications Inc. 774 2801 Telecom Parkway, 775 Richardson, Texas 75082 USA 776 Email: Shan.Zhu@us.fujitsu.com 777 Tel: +1-972-479-2041 779 Igor Bryskin 780 ADVA Optical Networking Inc 781 7926 Jones Branch Drive 782 Suite 615 783 McLean, VA - 22102 784 Email: ibryskin@advaoptical.com 786 Francesco Fondelli 787 Ericsson 788 Via Negrone 1/A 789 Genova - 16145 790 Email: francesco.fondelli@ericsson.com 792 Lou Berger 793 LabN Consulting, LLC 794 Phone: +1 301 468 9228 795 EMail: lberger@labn.net 797 11. Security Considerations 799 The procedures described in this document rely completely on RSVP-TE 800 messages and mechanism. The use of H bit set in ADMIN_STATUS Object 801 basically informs the receiving entity that no operations are to be 802 done over DP as consequence of such special signaling flow. Using 803 specially flagged signaling messages we want to limit the function of 804 setup and tear down messages to CP, making them not effective over 805 related DP resource usage. 807 However the handover procedures allow the control plane to be used to 808 take an LSP out of the control of the Management Plane. This could 809 cause considerable disruption and could introduce a new security 810 concern. As a consequence the use of GMPLS security techniques is 811 more important. For RSVP-TE Security please refer to [RFC3473], 812 while for GMPLS security framework please refer to [sec-fwk]. 814 12. IANA Considerations 816 IANA has been asked to manage the bit allocations for the 817 ADMIN_STATUS Object ([RFC3473]). This document requires the 818 allocation of the Handover bit: the H bit. IANA is requested to 819 allocate a bit for this purpose. 821 Bit Number Hex Value Name Reference 822 ---------- ----------- ------------------------------------ --------- 823 25 0x00000040 Handover (H) [This.I-D] 825 IANA has also been asked to allocate a new error code: 827 35 Handover failure 829 This Error Code has the following globally-defined Error 830 Value sub-code: 832 1 = Cross-connection mismatch 833 2 = Other failure 835 13. References 837 13.1. Normative References 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, March 1997. 842 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 843 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 844 Functional Specification", RFC 2205, September 1997. 846 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 847 and S. Molendini, "RSVP Refresh Overhead Reduction 848 Extensions", RFC 2961, April 2001. 850 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 851 (GMPLS) Signaling Functional Description", RFC 3471, 852 January 2003. 854 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 855 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 856 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 858 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 859 (GMPLS) Architecture", RFC 3945, October 2004. 861 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 862 Control", RFC 4003, February 2005. 864 13.2. Informational References 866 [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 867 "Requirements for the Conversion between Permanent 868 Connections and Switched Connections in a Generalized 869 Multiprotocol Label Switching (GMPLS) Network", RFC 5493, 870 April 2009. 872 [sec-fwk] Fang, L., "Security Framework for MPLS and GMPLS 873 Networks", July 2009. 875 Authors' Addresses 877 Diego Caviglia 878 Ericsson 879 Via A. Negrone 1/A 880 Genova - Sestri Ponente 881 Italy 883 Email: diego.caviglia@ericsson.com 885 Daniele Ceccarelli 886 Ericsson 887 Via A. Negrone 1/A 888 Genova - Sestri Ponente 889 Italy 891 Email: daniele.ceccarelli@ericsson.com 893 Dino Bramanti 894 Ericsson 896 Dan Li 897 Huawei Technologies 898 F3-5-B R&D Center, Huawei Base 899 Shenzhen 518129 900 P.R.China 902 Email: danli@huawei.com 903 Snigdho Bardalai 904 Fujitsu Network 905 2801 Telecom Parkway 906 Richrdson, Texas 75082 907 USA 909 Email: Snigdho.Bardalai@us.fujitsu.com