idnits 2.17.1 draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([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 (February 15, 2010) is 5156 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: August 19, 2010 Ericsson 6 D. Li 7 Huawei Technologies 8 S. Bardalai 9 Fujitsu Network 10 February 15, 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-07 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 connection. 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 August 19, 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 Simplified 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . 15 100 5. Minimum Information for MP to CP Handover . . . . . . . . . . 17 101 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 18 102 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 18 103 7.1. Administrative Status Object . . . . . . . . . . . . . . . 18 104 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 105 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 108 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 109 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 111 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 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 the 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 a Label Switched Path (LSP) in any DP 131 switching technology and any network architecture. 133 This memo describes an extension to GMPLS Resource reSerVation 134 Protocol - Traffic Engineering (RSVP-TE) [RFC3471], [RFC3473] 135 signaling that enables the handover of connection ownership between 136 the Management and the Control Planes. All handover related 137 procedures are defined below. This includes the handling of failure 138 conditions and subsequent reversion to original state. A basic 139 premise of the extension is that the handover procedures must never 140 impact the exchange of user data on LSPs that are already established 141 in the DP. 143 1.1. Dedication 145 We would like to dedicate this work to our friend and colleague Dino 146 Bramanti, who passed away at the early age of 38. Dino has been 147 involved in this work since its beginning. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Motivation 157 The main motivation behind this work is the definition of a simple 158 and very low impact procedure that satisfies the requirements defined 159 in [RFC5493]. Such a procedure is aimed at giving the transport 160 network operators the chance to handover the ownership of existing 161 LSPs provisioned by NMS from the MP to the CP without disrupting user 162 traffic flowing on them. Handover from MP to CP (i.e. when existing 163 DP connection ownership and control is passed from MP to CP) has been 164 defined as a mandatory requirement, while the opposite operation, CP 165 to MP handover, has been considered as a nice-to-have feature that 166 can be seen as an emergency procedure to disable the CP and take the 167 manual control of the LSP. For more details on requirements and 168 motivations please refer to [RFC5493]. 170 4. Procedures 172 The modification defined in this document refers only to the 173 ADMIN_STATUS Object, that is, the message flow is left unmodified for 174 both LSP set-up and deletion. Moreover a new Error Value is defined 175 to identify the failure of a Handover procedure. 177 The following paragraphs give detailed description of the "MP to CP 178 handover" and "CP to MP handover" procedures, based on the usage a 179 newly defined bit called H bit. 181 Just as when setting up an LSP using the CP [RFC3473], the Path 182 message may contain full information about the explicit route 183 including the links and labels traversed by the LSP. This 184 information is encoded in the Explicit Route Object (ERO), and must 185 be supplied by the MP using details recorded when the LSP was 186 provisioned, or collected by the MP by inspecting the nodes along the 187 path. 189 Alternatively, and also just as when setting up an LSP using the CP 190 [RFC3473] the ERO may include less information such that the details 191 of the next hop have to be determined by each node along the LSP as 192 it processes the Path message. This approach may be desirable when 193 the full information is not available to the MP or cannot be passed 194 to the head-end node when initiating the handover from MP to CP. 196 This section (Section 4) describes the general procedures and 197 protocol extensions for MP to CP handover, and uses the case of a 198 fully detailed ERO to describe the mechanism. Section 5 describes 199 how each node behaves in the case of a limited amount of information 200 in the ERO. 202 Note that when handover is being performed for a bidirectional LSP 203 and the ERO contains full information including labels, the ERO 204 SHOULD include both upstream and downstream labels. Per Section 205 5.1.1 of [RFC3473], the labels are indicated on an output basis; this 206 means that the labels are used by the upstream node to create the 207 LABEL_SET Object and, for bidirectional LSPs, the UPSTREAM_LABEL 208 Object used in the outgoing Path message. 210 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 211 Control Plane 213 The MP to CP handover procedure MUST create an RSVP-TE session along 214 the path of the LSP to be moved from MP to CP, associating it to the 215 existing cross-connected resources owned by the MP (e.g. lambdas, 216 time slots or reserved bandwidth) and at the same time transferring 217 their ownership to the CP. 219 The operator instructs the ingress node to handover control of the 220 LSP from the MP to the CP. In this handover mode, it supplies the 221 exact path of the LSP including any resource reservation and label 222 information. 224 The ingress MUST check that no corresponding Path state exists and 225 that corresponding Data Plane state does exist. If there is an 226 error, this MUST be reported to the operator and further protocol 227 action MUST NOT be taken. 229 The ingress signals the LSP using a Path message with the H bit and R 230 bit set in the ADMIN_STATUS object. In this mode of handover, the 231 Path message also carries an ERO that includes Label subobjects 232 indicating the labels used by the LSP at each hop. The ingress MUST 233 start the Expiration timer (see Section 4.2.1.2 for expiration of 234 this timer). Such timer SHOULD be configurable per LSP and have a 235 default value of 30 seconds. 237 Each Label Switching Router (LSR) that receives a Path message with 238 the H bit set checks to see whether there is any matching Path state. 240 - If matching Path state is found with the H bit set, this is a 241 Path refresh and should be treated accordingly [RFC3473]. 242 - If matching Path state is found with the H bit clear, this is an 243 error and MUST be treated according to the error case description 244 in Section 4.2.1.1 245 - If no Path state is found, the LSR goes on to check whether 246 there is any matching Data Plane state. 247 - If no matching Data Plane state is found (including only 248 partially matching Data Plane state), this is an error or a race 249 condition. It MUST be handled according to the description in 250 Section 4.2.1.1 251 - If matching Data Plane state is found, the LSR MUST save the 252 Path state (including the set H bit), and MUST forward the Path 253 message to the egress. The LSR MUST retain any MP state 254 associated with the LSP at this point. 256 An egress LSR MUST act as any other LSR, except that there is no 257 downstream node to which to forward the Path message. If all checks 258 are passed, the egress MUST respond with a Resv with the H bit set. 260 A transit LSR MUST process each Resv according to the normal rules of 261 [RFC3473]. 263 When an ingress LSR receives a Resv message carrying the H bit set, 264 it checks the Expiration Timer. 266 - If the timer is not running, the Resv is treated as a refresh and 267 no special action is taken [RFC3473]. 269 - If the timer is running, the ingress MUST cancel the timer and 270 SHOULD notify the operator that the first stage of handover is 271 complete. The ingress MUST send a Path message that is no different 272 from the previous message except that the H bit MUST be clear. 274 The Path message with the H bit clear will travel the length of the 275 LSP and will result in the return of a Resv with the H bit clear 276 according to normal processing [RFC3473]. As a result, the H bit 277 will be cleared in the stored Path state at each transit LSR and at 278 the egress LSR. Each LSR SHOULD release any associated MP state 279 associated with the LSP when it receives the Path message with H bit 280 clear, but MAY retain the information according to local policy for 281 use in future MP processing. 283 When the ingress receives a Resv with the H bit clear, the handover 284 is completed. The ingress SHOULD notify the operator that the 285 handover is correctly completed. 287 4.2. MP to CP Handover Procedure Failure Handling 289 In the case of MP to CP Handover, two different failure scenarios can 290 happen: Path Failure and Resv Failure. Moreover, each failure can be 291 due to two different causes: DP failure or Communication Failure. In 292 any case the LSP ownership MUST be immediately rolled back to the one 293 previous to the handover procedure. A section for each combination 294 will be analyzed in the following. 296 4.2.1. MP to CP Handover Failure - Path Failure 298 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 299 Failure 301 In this paragraph we will analyze the case where the handover 302 procedure fails during the Path message processing. 304 | Path | | | 305 |--------------->| Path | | 306 | |---------------X| | 307 | | PathErr | | 308 | PathErr |<---------------| | 309 |<---------------| | | 310 | | | | 311 Ingress LER LSR A LSR B Egress LER 313 Figure 1: MP2CP - Path Msg and DP Failure 315 If an error occurs, the node detecting the error MUST respond to the 316 received Path message with a PathErr message, and MUST abort the 317 handover procedure. The PathErr message SHOULD have the 318 Path_State_Removed flag set [RFC3473], but implementations MAY retain 319 their local state and wait for Path state timeout as per normal RSVP 320 processing. 322 Nodes receiving a PathErr message MUST follow standard PathErr 323 message processing and the associated DP resources MUST NOT be 324 impacted. If the local CP state indicates that a Handover is in 325 progress (based on the H bit in the Path message) the LSR MUST revert 326 the LSP ownership to the MP. 328 4.2.1.2. MP to CP Handover Failure - Path message and Communication 329 failure 331 Other possible scenarios are shown in the following pictures and are 332 based on the inability to reach a node along the path of the LSP. 334 The below scenario postulates the usage of a reliable message 335 delivery based on the mechanism defined in [RFC2961]. 337 | Path | | | 338 |--------------->| Path | | 339 | |---------------X| | 340 | |---------------X| | 341 | | ... | | 342 | |---------------X| | 343 | | | | 344 Ingress LER LSR A LSR B Egress LER 346 Figure 2: MP2CP - Path Msg and Communication Failure (reliable 347 delivery) 349 The Path message sent from LSR A towards LSR B is lost or does not 350 reach the destination for any reason. As a reliable delivery 351 mechanism is implemented, LSR A retransmits the Path message for a 352 configurable number of times and if no ack is received the handover 353 procedure will be aborted (via the Expiration timer). 355 In the next scenario RSVP-TE messages are sent without reliable 356 message delivery, that is, no [RFC2961] MessageID procedure is used. 358 | Path | | | 359 |--------------->| Path | | 360 | |----------X | | 361 | | | | 362 TIMER EXPIRES | | | 363 | Path Tear | Path Tear | Path Tear | 364 |--------------->|--------------->|--------------->| 365 | | | | 366 Ingress LER LSR A LSR B Egress LER 368 Figure 3: MP2CP - Path Msg and Communication Failure (no reliable 369 delivery) 371 If the Resv message is not received before the expiration of the 372 Expiration timer the handover procedure is aborted as described in 373 Section 4.2.1.1. Please note that any node that has forwarded a Path 374 (LSR A), i.e. has installed local path state, will send a PathTear 375 when that state is removed (accordingly to [RFC2205]). 377 4.2.2. MP to CP Handover Failure - Resv Error 379 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 381 In the case of failure occurrence during the Resv message processing, 382 (in case there has been any change in the data plane during the 383 signaling) the node MUST send a PathErr message [RFC2205] in the 384 upstream direction. The PathErr message is constructed and processed 385 as defined above in Section 4.2.1.1. The failure detection node MUST 386 also send a PathTear message downstream. The PathTear message is 387 constructed and processed as defined above in Section 4.2.1.1. 389 | Path | Path | Path | 390 |--------------->|--------------->|--------------->| 391 | | | Resv | 392 | | Resv |<---------------| 393 | |X---------------| | 394 | PathErr | PathTear | PathTear | 395 |<---------------|--------------->|--------------->| 396 | | | | 397 Ingress LER LSR A LSR B Egress LER 399 Figure 4: MP2CP - Resv Error and DP Failure 401 In the case shown in Figure 4, the failure occurs in LSR A. A 402 PathTear message is sent towards B and a PathErr message (with 403 ErrorCode set to "Handover Procedure Failure") is sent in the 404 upstream direction. The PathErr and PathTear messages remove the 405 Path state established by the Path messages along the nodes of the 406 LSP and abort the handover procedure. 408 Please note that the failure occurred after the handover procedure 409 was successfully completed in LSR B, but Handover state will still be 410 maintained locally as, per Section 4.1, a Path message with the H bit 411 clear will have not yet been sent or received. A node that receives 412 a PathTear when it has Path state with the H bit set MUST remove Path 413 state, but MUST NOT change data plane state. It MUST return LSP 414 ownership to the MP. 416 4.2.2.2. MP to CP Handover Failure - Resv Error and Communication 417 failure 419 When a Resv message cannot reach one or more of the upstream nodes, 420 the procedure is quite similar to the one previously seen about the 421 Path message. Even in this case it is possible to distinguish two 422 different scenarios. 424 In the first scenario we consider the utilization of a reliable 425 message delivery based on the mechanism defined in [RFC2961]. After 426 a correct forwarding of the Path message along the nodes of the LSP, 427 the Egress LSR sends a Resv message in the opposite direction. It 428 might happen that the Resv message does not reach the ingress Label 429 Edge Router (LER) or an LSR, say LSR A. LSR B MUST send a Resv 430 message again for a configurable number of times and then, if the 431 delivery does not succeed, the adoption procedure will be aborted 432 (via the Expiration timer). 434 | Path | Path | Path | 435 |--------------->|--------------->|--------------->| 436 | | | Resv | 437 | | Resv |<---------------| 438 | | X---------| | 439 | | X---------| | 440 | | ... | | 441 | | X---------| | 442 | | | | 443 Ingress 444 LSR A LSR B Egress LER 446 Figure 5: MP2CP - Resv Error and Communication Failure (reliable 447 delivery) 449 Considering that the Resv message did not manage to reach LSR A, it 450 is highly probable that the PathErr would fail too. Due to this 451 fact, the Expiration timer is used on the Ingress LER after sending 452 the path and on LSR A after forwarding it. When the timer expires, 453 if no Resv or PathErr message is received, the handover procedure is 454 aborted as described in Section 4.2.1.1 and the LSP ownership 455 returned to the Management Plane. 457 Figure 6, on the other hand, shows the scenario in which no reliable 458 delivery mechanism is implemented. 460 | Path | Path | Path | 461 |--------------->|--------------->|--------------->| 462 | | | Resv | 463 | | Resv |<---------------| 464 | | X---------| | 465 TIMER EXPIRES | | | 466 | Path Tear | Path Tear | Path Tear | 467 |--------------->|--------------->|--------------->| 468 | | | | 469 Ingress LER LSR A LSR B Egress LER 471 Figure 6: MP2CP - Resv Error and Communication Failure (no reliable 472 delivery) 474 If non Resv message is received before the Expiration timer expires, 475 the ingress LER follows the same procedure defined in Section 4.1. 477 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 479 In the case of node restart and graceful restart is enabled then one 480 of the following scenarios will happen. 482 Case I - Finite Restart Time 484 In this case, the Restart Time (see [RFC3473]) is finite, i.e., not a 485 value of 0xffffffff. In the sequence diagram below, assume LSR A 486 restarts. If the ingress LER does not receive the Resv message in 487 time it MUST abort the handover process by generating a PathTear 488 message downstream. Also, if LSR A does not complete the restart 489 process within the restart time interval then LSR B MUST start 490 tearing down all LSPs between LSR A and LSR B and this includes the 491 LSP that is being used to carry out the handover of MP resources to 492 CP. LSP B MUST generate a PathTear message downstream and a PathErr 493 message upstream. Both LSR B and the egress LER MUST NOT release the 494 DP resources because in both nodes the H bit is set in the local Path 495 state. 497 | Path | Path | Path | 498 |--------------->|--------------->|--------------->| 499 | | | Resv | 500 | | Resv |<---------------| 501 | X X---------| | 502 | PathTear | | 503 |-------X Restart Timer | 504 | Expires | 505 | PathErr | PathTear | 506 | X--------|--------------->| 507 | | | 508 | X | | 509 | | | | 510 Ingress LER LSR A LSR B Egress LER 512 Figure 7: MP2CP - Node graceful restart - Case I 514 Case II - Infinite Restart Time 516 In this case, the Restart Time (see [RFC3473]) indicates that the 517 restart of the sender's control plane may occur over an indeterminate 518 interval, i.e., is 0xffffffff. The sequence is quite similar to the 519 previous one. In this sequence the restart timer will not expire in 520 LSR B since it is run infinitely. Instead after LSR A restarts LSR B 521 MUST start the recovery timer. The recovery timer will expire since 522 there will be no Path message with the RECOVERY LABEL received from 523 LSR A given the ingress node had already removed the local Path state 524 after it aborts the handover process. Thus LSR B MUST tear-down the 525 specific LSP that is being used to convert the MP resources to CP by 526 generating a PathTear message downstream and PathErr message 527 upstream. Similarly to the previous case both LSR B and the egress 528 LER MUST NOT release the DP resources because the H bit is set in the 529 local Path state. 531 | Path | Path | Path | 532 |--------------->|--------------->|--------------->| 533 | | | Resv | 534 | | Resv |<---------------| 535 | X X---------| | 536 | PathTear | | 537 |-------X | | 538 | | | 539 | X | | 540 | | | | 541 | | Recovery Timer | 542 | | Expires | 543 | PathErr | PathErr | PathTear | 544 |<---------------|<---------------|--------------->| 545 | | | | 546 Ingress LER LSR A LSR B Egress LER 548 Figure 8: MP2CP - Node graceful restart - Case II 550 Case III 552 In this case, the ingress LER does not abort the handover process. 553 When LSR A restarts, the ingress LER detects the restart and MUST re- 554 generate the Path message with the H bit set in order to re-start the 555 handover. 557 When LSR B receives the Path message, it sees the H-bit set on the 558 message and also sees that it has the H-bit set in its own state and 559 that it has sent the Resv. But it is also aware that LSR A has 560 restarted and could have sent a Path message with a RECOVERY LABEL 561 object. LSR B may attempt to resume the handover process or may 562 abort the handover. This choice is made according to local policy. 564 If resuming the handover, LSR B MUST treat the received Path message 565 as a retransmission, and MUST retransmit its Resv. If aborting 566 handover, LSR B MUST return a PathErr and MUST send a PathTear 567 downstream. In both cases, LSR B MUST NOT modify the DP state. 569 | Path | Path | Path | 570 |--------------->|--------------->|--------------->| 571 | | | Resv | 572 | | Resv |<---------------| 573 | X X---------| | 574 | | | 575 | X | | 576 | | | | 577 | Path | Path | | 578 |--------------->|--------------->| | 579 | PathErr | PathErr | PathTear | 580 |<---------------|<---------------|--------------->| 581 | | | | 582 Ingress LER LSR A LSR B Egress LER 584 Figure 9: MP2CP - Node graceful restart - Case III 586 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To 587 Management Plane 589 Let's now consider the case of LSP Ownership Transfer From Control 590 Plane To Management Plane. Also in this section we will analyze the 591 handover procedure success and failure. 593 The scenario is still a DP connection between two nodes acting as 594 ingress and egress for a LSP, but in this case the CP has the 595 ownership and control of the LSP. The CP to MP handover procedure 596 MUST delete the existing RSVP-TE session information and MUST NOT 597 affect the cross-connected resources, but just move their ownership 598 to the MP. 600 In other words, after LSP ownership transfer from CP to MP, the LSP 601 is no longer under control of RSVP-TE, which is no more able to "see" 602 the LSP itself. The CP to MP handover procedure MUST be a standard 603 LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. 604 The procedure is initiated at the ingress node of the LSP by a MP 605 entity. Ingress node and MP exchange the relevant information for 606 this task and then propagate it over CP by means of RSVP-TE tear down 607 signaling as described below. 609 The ingress node MUST send a Path message in the downstream direction 610 with Handover and Reflect bits set in the ADMIN_STATUS Object. No 611 action is taken over the DP and transit LSRs must forward such 612 message towards the egress node. All of the nodes MUST keep track of 613 the procedure storing the H bit in their local Path and Resv states. 614 Then every node waits for the H bit to be received within the related 615 Resv message. After the Resv message is received by the ingress LER, 616 it MUST send a PathTear message in order to clear the whole LSP 617 information recorded on the RSVP-TE data structures of the nodes. 618 Downstream nodes processing a PathTear message which follows a Path 619 message with the H bit set, MUST NOT remove any associated data plane 620 state. In other words, a normal LSP tear down signaling is exchanged 621 between nodes traversed by the LSP, but H bit set in the Path message 622 indicates that no DP action has to correspond to CP signaling. 624 4.4. CP to MP Handover Procedure Failure 626 Failures during CP to MP handover procedure MUST NOT result in the 627 removal of any associated data plane state. To that end, when a Resv 628 message containing an ADMIN_STATUS Object with the H bit is not 629 received during the period of time described in Section 7.2.2. of 630 [RFC3473] different processing is required. While the H bit is set 631 in the Path state, a node MUST NOT send a PathTear when a failure is 632 detected. Instead, the failure is reported upstream using a PathErr. 633 The only node that can send a PathTear is the ingress node, and it 634 can only do this as a step in the procedures specified in this 635 document. This applies to both MP to CP and CP to MP handover. The 636 ingress node MAY choose to report the failure in the CP to MP 637 handover procedure via the MP. 639 The CP to MP handover procedure can fail also due to two causes: 640 PathTear lost or node down. In the former case, if the LSP is not 641 under MP control after the Expiration Timer elapses, a manual 642 intervention from the network operator is requested, while in the 643 latter case different scenarios may happen: 645 - CASE I - Path message and node down 647 | Path | Path X | 648 |--------------->|--------------X | 649 | | | 650 | | X | 651 | | | | 652 | | | | 653 Ingress LER LSR A LSR B Egress LER 655 Figure 10: Case I - Path message and node down 657 Per [RFC3473] section 7.2.2 the ingress node should wait for a 658 configurable amount of time (30 seconds by default) and then send a 659 PathTear message. In this case the normal deletion procedure MUST 660 NOT be followed. When the Expiration timer elapses a manual 661 intervention from network operator is requested and normal, i.e., pre 662 CP to MP handover, LSP processing continues. 664 - CASE II - Resv message and node down 666 | Path | Path | Path | 667 |--------------->|--------------->|--------------->| 668 | | | Resv | 669 | | Resv |<---------------| 670 | X X---------| | 671 | | | 672 | X | | 673 | | | | 674 Ingress LER LSR A LSR B Egress LER 676 Figure 11: Case II - Resv message and node down 678 The procedure to be followed is the same depicted in CASE I. The 679 network operator can ask for the automatic CP to MP procedure again 680 after the failed node comes back up. Per [RFC3473] section 7.2 the 681 nodes will forward the new Path and Resv messages correctly. 683 - CASE III - PathTear message and node down 685 | Path | Path | Path | 686 |--------------->|--------------->|--------------->| 687 | Resv | Resv | Resv | 688 |<---------------|<---------------|<---------------| 689 | PathTear | | | 690 |--------------->| PathTear X | 691 | |------------X | 692 | | X | 693 | | | | 694 Ingress LER LSR A LSR B Egress LER 696 Figure 12: Case III - PathTear message and node down 698 This scenario can be managed as a normal PathTear lost described 699 above in this section. 701 5. Minimum Information for MP to CP Handover 703 As described in Section 4, it is also possible for the ERO to contain 704 less than the full set of path information for the LSP being handed 705 over. This arises when only a minimal set of information is handed 706 to the CP by the MP at the LSP's head end. Instead of collecting all 707 of the LSP information (including the labels) and formatting it into 708 an ERO, as described in Section 4, it is possible to start with a 709 minimum amount of information. The full ERO method and the 710 partial/no ERO method are not mutually exclusive; support of both 711 methods are required. 713 At the ingress node, the information needed to specify the LSP is the 714 outgoing interface ID, upstream label and downstream label of this 715 interface and the egress node ID. The remaining information about an 716 existing LSP can then be collected hop by hop, as the signaling is 717 going on, by looking up the cross-connection table in DP at each node 718 along the LSP path. 720 Starting from the information available at ingress LER about the 721 outgoing interface ID of that ingress node, the incoming interface ID 722 of next hop can be found by looking up the link resource table/ 723 database in the LER itself. 725 The Path message is hence built with the LABEL_SET Object ([RFC3473]) 726 and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label 727 and downstream label of ingress outgoing interface of the LSP are 728 included in these two objects. In addition to above mentioned 729 objects, the Path message MUST include the ADMIN_STATUS Object with H 730 bit set, as already defined in previous chapters for the detailed ERO 731 based way of proceeding. Such handover Path is sent to the incoming 732 interface of next hop. When this Path message reaches the second 733 node along the LSP path, the information about incoming interface ID 734 and the upstream and downstream labels of this interface is extracted 735 from it and it is used to find next hop outgoing interface ID and the 736 upstream/downstream labels by looking up the DP cross-connection 737 table. 739 After having determined in this way the parameters describing the 740 LSPs next hop, the outgoing Path message to be sent is built 741 replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with 742 the looked-up values of upstream and downstream labels. 744 By repeating this procedure for each transit node along the LSP, it 745 is possible to make the handover Path message reach the egress node, 746 exactly following the LSP that is in place over DP. The ERO MAY in 747 this case be included in the Path message as an optional object, and 748 MAY be filled with the LSP relevant information down to either the 749 port level with interface ID or the Label level with upstream and 750 downstream labels. The ERO can be used to check the consistency of 751 resource in DP down to the port level or label level at each 752 intermediate node along the LSP path. 754 Where the DP path continues beyond the egress, by indicating the 755 Egress label at the head-end of an LSP, the traffic can be directed 756 to the right destination. The GMPLS Signaling Procedure for Egress 757 Control is described in [RFC4003] 759 6. RSVP Message Formats 761 This memo does not introduce any modification in RSVP messages object 762 composition. 764 7. Objects Modification 766 The modifications required concern two RSVP objects: the ADMIN_STATUS 767 and the ERROR_SPEC Object. 769 7.1. Administrative Status Object 771 This memo introduces a new flag into the ADMIN_STATUS object. The 772 ADMIN_STATUS Object is defined in [RFC3473]. This document uses the 773 H bit of the ADMIN_STATUS Object. The bit is bit number (TBD by 774 IANA) (25). 776 7.2. Error Spec Object 778 It is possible that a failure, such as the loss of DCN connection or 779 the restart of a node, occurs during the LSP ownership handing over. 780 In this case the LSP handover procedure is interrupted, the ownership 781 of the LSP must remain with the ownership prior to the initiation of 782 the handover procedure. It is important that the transaction failure 783 does not affect the DP. The LSP is kept in place and no traffic hit 784 occurs. 786 The failure is signaled by PathErr in the upstream direction and 787 PathTear Messages in the downstream direction. The PathErr messages 788 include an ERROR_SPEC Object specifying the causes of the failure. 790 This memo introduces a new Error Code (with different Error Values) 791 into the ERROR_SPEC Object, defined in [RFC2205]. 793 The defined Error Code is "Handover Procedure Failure", and its value 794 is (TBD by IANA)(35). For this Error Code the following Error Values 795 are defined: 797 1 = Cross-connection mismatch 799 2 = Other failure 801 8. Compatibility 803 The main requirement for Handover procedure to work is that all nodes 804 along the path MUST support the extension defined in this draft. 805 This requirement translates to an administrative requirement as it is 806 not enforced at the protocol level. As defined, non-supporting nodes 807 will simply propagate the H bit without setting local state. This 808 may result in an impact on data traffic during the handover 809 procedure. 811 9. Security Considerations 813 The procedures described in this document rely completely on RSVP-TE 814 messages and mechanism. The use of H bit set in ADMIN_STATUS Object 815 basically informs the receiving entity that no operations are to be 816 done over DP as consequence of such special signaling flow. Using 817 specially flagged signaling messages we want to limit the function of 818 setup and tear down messages to CP, making them not effective over 819 related DP resource usage. 821 However the handover procedures allow the control plane to be used to 822 take an LSP out of the control of the Management Plane. This could 823 cause considerable disruption and could introduce a new security 824 concern. As a consequence the use of GMPLS security techniques is 825 more important. For RSVP-TE Security please refer to [RFC3473], 826 while for GMPLS security framework please refer to [sec-fwk]. 828 10. IANA Considerations 830 IANA has been asked to manage the bit allocations for the 831 ADMIN_STATUS Object ([RFC3473]). This document requires the 832 allocation of the Handover bit: the H bit. IANA is requested to 833 allocate a bit for this purpose. 835 Bit Number Hex Value Name Reference 836 ---------- ----------- ----------------------------------- --------- 837 25 0x00000040 Handover (H) [This.I-D] 838 IANA has also been asked to allocate a new error code: 840 35 Handover failure 842 This Error Code has the following globally-defined Error 843 Value sub-code: 845 1 = Cross-connection mismatch 846 2 = Other failure 848 11. Acknowledgments 850 We wish to thank Adrian Farrel, Lou Berger, Alan Elder, and Ben 851 Campbell for their assistance and precious advices to prepare this 852 draft for publication. We also wish to thank Nicola Ciulli 853 (Nextworks) who contributed to the initial stage of this draft. 855 12. Contributors 857 Shan Zhu 858 Fujitsu Network Communications Inc. 859 2801 Telecom Parkway, 860 Richardson, Texas 75082 USA 861 Email: Shan.Zhu@us.fujitsu.com 862 Tel: +1-972-479-2041 864 Igor Bryskin 865 ADVA Optical Networking Inc 866 7926 Jones Branch Drive 867 Suite 615 868 McLean, VA - 22102 869 Email: ibryskin@advaoptical.com 871 Francesco Fondelli 872 Ericsson 873 Via Negrone 1/A 874 Genova - 16145 875 Email: francesco.fondelli@ericsson.com 877 Lou Berger 878 LabN Consulting, LLC 879 Phone: +1 301 468 9228 880 EMail: lberger@labn.net 882 13. References 883 13.1. Normative References 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, March 1997. 888 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 889 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 890 Functional Specification", RFC 2205, September 1997. 892 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 893 and S. Molendini, "RSVP Refresh Overhead Reduction 894 Extensions", RFC 2961, April 2001. 896 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 897 (GMPLS) Signaling Functional Description", RFC 3471, 898 January 2003. 900 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 901 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 902 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 904 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 905 (GMPLS) Architecture", RFC 3945, October 2004. 907 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 908 Control", RFC 4003, February 2005. 910 13.2. Informational References 912 [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 913 "Requirements for the Conversion between Permanent 914 Connections and Switched Connections in a Generalized 915 Multiprotocol Label Switching (GMPLS) Network", RFC 5493, 916 April 2009. 918 [sec-fwk] Fang, L., "Security Framework for MPLS and GMPLS 919 Networks", July 2009. 921 Authors' Addresses 923 Diego Caviglia 924 Ericsson 925 Via A. Negrone 1/A 926 Genova - Sestri Ponente 927 Italy 929 Email: diego.caviglia@ericsson.com 931 Daniele Ceccarelli 932 Ericsson 933 Via A. Negrone 1/A 934 Genova - Sestri Ponente 935 Italy 937 Email: daniele.ceccarelli@ericsson.com 939 Dino Bramanti 940 Ericsson 942 Dan Li 943 Huawei Technologies 944 F3-5-B R&D Center, Huawei Base 945 Shenzhen 518129 946 P.R.China 948 Email: danli@huawei.com 950 Snigdho Bardalai 951 Fujitsu Network 952 2801 Telecom Parkway 953 Richrdson, Texas 75082 954 USA 956 Email: Snigdho.Bardalai@us.fujitsu.com