idnits 2.17.1 draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2205], [RFC3471], [RFC3473], [RFC5493], [RFC4872]), 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 (July 27, 2009) is 5380 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: 2 errors (**), 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: January 28, 2010 Ericsson 6 D. Li 7 Huawei Technologies 8 S. Bardalai 9 Fujitsu Network 10 July 27, 2009 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-03 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 28, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 We would like to dedicate this work to our friend and colleague Dino 53 Bramanti, who passed away at the early age of 38. Dino has been 54 involved in this work since its beginning. 56 In a transport network scenario, where Data Plane connections 57 controlled either by GMPLS Control Plane (Soft Permanent Connections 58 - SPC) or by Management System (Permanent Connections - PC) may 59 independently coexist, the ability of transforming an existing PC 60 into a SPC and vice versa - without actually affecting Data Plane 61 traffic being carried over it - is a requirement [RFC5493]. 63 This memo provides a minor extension to RSVP-TE [RFC2205], [RFC3471], 64 [RFC3473], [RFC4872] signaling protocol, within GMPLS architecture, 65 to enable such connection ownership transfer and describes the 66 defined procedures. Failure conditions and subsequent roll back are 67 also defined taking into account that an handover failure MUST NOT 68 impact the already established data plane connections. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4.1. MP to CP handover: LSP Ownership Transfer From 77 Management Plane To Control Plane . . . . . . . . . . . . 5 78 4.2. MP to CP Handover Procedure Failure Handling . . . . . . . 6 79 4.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 6 80 4.2.1.1. MP to CP Handover Failure - Path message and 81 Data Plane Failure . . . . . . . . . . . . . . . . 6 82 4.2.1.2. MP to CP Handover Failure - Path message and 83 Communication failure . . . . . . . . . . . . . . 7 84 4.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 85 4.2.2.1. MP to CP Handover Failure - Resv Error and 86 Data Plane failure . . . . . . . . . . . . . . . . 8 87 4.2.2.2. MP to CP Handover Failure - Resv Error and 88 Communication failure . . . . . . . . . . . . . . 9 89 4.2.2.3. MP to CP Handover Failure - Node Graceful 90 Restart . . . . . . . . . . . . . . . . . . . . . 10 91 4.3. CP to MP handover : LSP Ownership Transfer From 92 Control Plane To Management Plane . . . . . . . . . . . . 13 93 4.4. CP to MP Handover Procedure Failure . . . . . . . . . . . 13 94 5. Alternative Way Of Retrieving Information Needed For MP To 95 CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 6. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 15 97 7. Objects Modification . . . . . . . . . . . . . . . . . . . . . 15 98 7.1. Administrative Status Object . . . . . . . . . . . . . . . 15 99 7.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 16 100 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 102 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 107 13.2. Informational References . . . . . . . . . . . . . . . . . 18 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 110 1. Introduction 112 In a typical traditional transport network scenario, Data Plane (DP) 113 connections between two endpoints are controlled by means of a 114 Network Management System (NMS) operating within Management Plane 115 (MP). NMS/MP is the owner of such transport connections, being 116 responsible of their set up, tear down and maintenance. 118 The adoption of a GMPLS Control Plane (CP) over networks that are 119 already in service - controlled by NMS at MP level - introduces the 120 need for a procedure able to coordinate a control handover of a 121 generic data plane connection from MP to CP. 123 In addition, the control handover in the opposite direction, from CP 124 to MP SHOULD be possible as well. The procedures described in this 125 memo can be applied to any kind of LSP and network architecture. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Motivation 135 The main motivation behind this work is the definition of a simple 136 and very low impacting procedure that satisfies the requirements 137 defined in [RFC5493]. Such procedure is aimed at giving the 138 transport network operators the chance to handover the ownership of 139 existing LSPs provisioned by NMS from the MP to the CP without 140 disrupting user traffic flowing on them. Handover from MP to CP 141 (i.e. when existing DP connection ownership and control is passed 142 from MP to CP) has been defined as mandatory requirement, while the 143 opposite operation, CP to MP handover, has been considered as a nice- 144 to-have feature that can be seen as an emergency procedure to disable 145 the CP and take the manual control of the LSP. For more details on 146 requirements and motivations please refer to [RFC5493]. 148 4. Procedures 150 The modification defined in this document refers only to 151 Administrative Status object, that is, the message flow is left 152 unmodified for both LSP set-up and deletion. Moreover a new Error 153 Value is defined to identify the failure of a Handover procedure. 155 Following paragraphs give detailed description of defined "MP to CP 156 handover" and "CP to MP handover" procedures, based on the usage a 157 newly define bit called H bit. 159 MP to CP handover procedure foreseen two different methods for 160 retrieving required information. The primary one consists on 161 receiving the full Explicit Route Object (ERO) from the MP while the 162 alternative one is described in Section 5. 164 Please note that if the primary method is used the labels SHOULD be 165 included in the ERO and for bidirectional LSPs both upstream and 166 downstream labels SHOULD be included. Per Section 5.1.1. of 167 [RFC3473], the labels are indicated on an output basis. As 168 described, this means that the labels are used by the upstream node 169 to create the LABEL_SET object and, for bidirectional LSPs, 170 UPSTREAM_LABEL object used in the outgoing Path message. 172 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To 173 Control Plane 175 The MP to CP handover procedure MUST create an RSVP-TE session along 176 the path of the LSP to be moved from MP to CP, associating it to the 177 existing cross-connected resources owned by the MP (e.g. lambdas, 178 time slots or reserved bandwidth) and at the same time transferring 179 their ownership to the CP. 181 A standard RSVP-TE signaling flow MUST be used to inform nodes about 182 the ownership handover request. Such flow MUST be tagged with a 183 newly introduced flag, here named H bit and described in Section 7.1, 184 that is set in the Administrative Status Object ([RFC3471] and 185 [RFC3473]) of RSVP-TE messages. The H bit MUST be set in order to 186 discriminate the handover procedure from normal, DP affecting, LSP 187 setup/release procedure. The DP MUST NOT be affected from the 188 handover procedure. 190 The ingress node MUST send a Path message in the downstream direction 191 with the H and R ([RFC3471]) bit set. Upon receiving a Path Message 192 containing an Administrative Status Object with the H bit set, each 193 node MUST check if there is a local Path State matching the MP to CP 194 Handover request. If no local Path State exists, the node MUST 195 confirm that there is an existing DP state that corresponds to the 196 Path message. In case such DP state exists (failure cases are 197 defined in the next sections), local Path state MUST be installed. 198 The H bit MUST be stored in the local Path state. 200 After propagating a Path message with the H bit set, a node MUST wait 201 for a Resv message including Administrative Status Object with H bit 202 set. After the ingress node receives it, the actual migration of LSP 203 information is complete, the LSP is left completely under control of 204 RSVP-TE within Control Plane. 206 If the Resv message is not received by the expiration of a timer 207 (called Expiration timer in the following) set by the ingress LER, 208 the handover procedure is aborted, that is, a PathTear message MUST 209 be sent in the downstream direction. 211 In order to complete the Handover process the ingress node MUST send 212 a Path message with the H bit cleared (set to zero) upon receipt of a 213 corresponding Resv message. The R bit SHOULD NOT be set in this 214 message. Downstream nodes MUST clear their local "Handover" state 215 based on a received Path message with the H bit cleared. This means 216 that once a downstream node processes a Path message with the cleared 217 H bit, any state related to the former MP ownership of the LSP is 218 lost. Normal ResvConf process occurs as normal. The handover 219 procedure does not modify the Confirmation procedure. 221 In case the path of the LSP is not fully passed to the ingress LER, 222 each node can determine the next hop looking at its data plane and 223 exploit the similarity between the MP to CP Handover procedure and 224 the Restart Procedure. Please refer to Section 5. 226 4.2. MP to CP Handover Procedure Failure Handling 228 In case of MP to CP Procedure, two different failure scenarios can 229 happen: Path Failure and Resv Failure. Moreover, each failure can be 230 due to two different causes: DP failure or Communication Failure. In 231 any case the LSP ownership MUST be immediately roll backed to the one 232 previous to the handover procedure. A section for each combination 233 will be analyzed in the following. 235 4.2.1. MP to CP Handover Failure - Path Failure 237 4.2.1.1. MP to CP Handover Failure - Path message and Data Plane 238 Failure 240 In this paragraph we will analyze the case where the handover 241 procedure fails during the Path message processing. 243 | Path | | | 244 |--------------->| Path | | 245 | |---------------X| | 246 | | | | 247 | PathErr | | | 248 |<---------------| | | 249 | | | | 250 Ingress LER LSR A LSR B Egress LER 252 MP2CP - Path Msg and DP Failure 254 If an error occurs in an LSR or a LER, the last node that has 255 received the Path message MUST send a PathErr message in the upstream 256 direction and the handover procedure is aborted. The PathErr message 257 SHOULD have the Path_State_Removed flag set. 259 Nodes receiving a PathErr message MUST follow standard PathErr 260 message processing with the exception that when their local state 261 indicates that a Handover is in progress (based on the H bit in the 262 Path message) the associated DP resources MUST NOT be impacted during 263 such processing. 265 4.2.1.2. MP to CP Handover Failure - Path message and Communication 266 failure 268 Other possible scenarios are shown in the following pictures and 269 consist on inability to reach a node along the path of the LSP. 271 The below scenario postulates the usage of a reliable message 272 delivery based on the mechanism defined in [RFC2961]. 274 | Path | | | 275 |--------------->| Path | | 276 | |---------------X| | 277 | |---------------X| | 278 | | ... | | 279 | |---------------X| | 280 | | | | 281 Ingress LER LSR A LSR B Egress LER 283 MP2CP - Path Msg and Communication Failure (reliable delivery) 285 The Path message sent from LSR A towards LSR B is lost or does not 286 reach the destination for any reason. As a reliable delivery 287 mechanism is implemented, LSR A retransmits the Path message for a 288 configurable number of times and if no ack is received the handover 289 procedure will be aborted (via the Expiration timer). 291 In the next scenario RSVP-TE messages are sent without reliable 292 message delivery, that is, no [RFC2961] MessageID procedure is used. 294 | Path | | | 295 |--------------->| Path | | 296 | |----------X | | 297 | | | | 298 |-TIMER EXPIRES--| | | 299 | Path Tear | | | 300 |--------------->| | | 301 | | | | 302 Ingress LER LSR A LSR B Egress LER 304 MP2CP - Path Msg and Communication Failure (no reliable delivery) 306 If the Resv message is not received by the expiration of the 307 Expiration timer the handover procedure is aborted as described in 308 Section 4.1. 310 4.2.2. MP to CP Handover Failure - Resv Error 312 4.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 314 In case a failure occurs during the Resv message processing, the node 315 MUST send a PathErr message in the upstream direction. The PathErr 316 message is constructed and processed as defined above in 317 Section 4.2.1.1. The failure detection node MUST also send a 318 PathTear message downstream. The PathTear message is constructed and 319 processed as defined above in Section 4.2.1.1. 321 | Path | Path | Path | 322 |--------------->|--------------->|--------------->| 323 | | | Resv | 324 | | Resv |<---------------| 325 | | X---------| | 326 | PathErr | PathTear | PathTear | 327 |<---------------|--------------->|--------------->| 328 | | | | 329 Ingress LER LSR A LSR B Egress LER 331 MP2CP - Resv Error and DP Failure 333 In the case shown in the above picture, the failure occurs in LSR A. 334 A PathTear message is sent towards B and a PathErr message is sent in 335 the upstream direction. The PathErr and PathTear messages remove the 336 Path state established by the Path messages along the nodes of the 337 LSP and abort the handover procedure. 339 Please note that the failure occurred after the handover procedure 340 was successfully completed in LSR B, but Handover state will still be 341 maintained locally as, per Section 4.1, a Path message with the H bit 342 clear will have not yet been sent or received. 344 4.2.2.2. MP to CP Handover Failure - Resv Error and Communication 345 failure 347 In case a Resv message cannot reach one or more of the upstream 348 nodes, the procedure is quite similar to the one previously seen 349 about the Path message. Even in this case it is possible to 350 distinguish two different scenarios. 352 In the first scenario we consider the utilization of a reliable 353 message delivery based on the mechanism defined in [RFC2961]. After 354 a correct forwarding of the Path message along the nodes of the LSP, 355 the Egress LSR sends a Resv message in the opposite direction. It 356 might happen that the Resv message does not reach the ingress LER or 357 an LSR, say LSR A. LSR B MUST send a Resv message again for a 358 configurable number of times and then, if the delivery does not 359 succeed, the adoption procedure will be aborted (via the Expiration 360 timer). 362 | Path | Path | Path | 363 |--------------->|--------------->|--------------->| 364 | | | Resv | 365 | | Resv |<---------------| 366 | | X---------| | 367 | | X---------| | 368 | | ... | | 369 | | X---------| | 370 | | | | 371 Ingress LER LSR A LSR B Egress LER 373 MP2CP - Resv Error and Communication Failure (reliable delivery) 375 Considering that the Resv message did not manage to reach LSR A, it 376 is highly probable that the PathErr would fail too. Due to this 377 fact, the Expiration timer is used on the Ingress LER after sending 378 the path and on LSR A after forwarding it. When the timer expires, 379 if no Resv or PathErr message is received, the handover procedure is 380 aborted as described in Section 4.1 and the LSP ownership returned to 381 the Management Plane. 383 The following picture, on the other hand, shows the scenario in which 384 no reliable delivery mechanism is implemented. 386 | Path | Path | Path | 387 |--------------->|--------------->|--------------->| 388 | | | Resv | 389 | | Resv |<---------------| 390 | | X---------| | 391 |-TIMER EXPIRES--| | | 392 | Path Tear | Path Tear | Path Tear | 393 |--------------->|--------------->|--------------->| 394 | | | | 395 Ingress LER LSR A LSR B Egress LER 397 MP2CP - Resv Error and Communication Failure (no reliable delivery) 399 If non Resv message is received before the Expiration timer expires, 400 the ingress LER follows the same procedure defined in Section 4.1. 402 4.2.2.3. MP to CP Handover Failure - Node Graceful Restart 404 In case one of the nodes restarts and graceful restart is enabled 405 then one of the following scenarios will happen. 407 Case I 409 Restart timer is not infinite. In the sequence diagram below, assume 410 LSR A restarts. In case the ingress LER does not receive the Resv 411 message in time it MUST abort the handover process by generating a 412 PathTear message downstream. Also, if LSR A does not complete the 413 restart process within the restart time interval then LSR B MUST 414 start tearing down all LSPs between LSR A and LSR B and this includes 415 the LSP that is being used to carry out the handover of MP resources 416 to CP. LSP B MUST generate a PathTear message downstream and a 417 PathErr message upstream. Both LSR B and the egress LER MUST NOT 418 release the DP resources because in both nodes the H bit is set in 419 the local Path state. 421 | Path | Path | Path | 422 |--------------->|--------------->|--------------->| 423 | | | Resv | 424 | | Resv |<---------------| 425 | X X---------| | 426 | PathTear | | 427 |-------X Restart Timer | 428 | Expires | 429 | PathErr | PathTear | 430 | X--------|--------------->| 431 | | | 432 | X | | 433 | | | | 434 Ingress LER LSR A LSR B Egress LER 436 MP2CP - Node graceful restart - Case I 438 Case II 440 Restart timer is infinite. The sequence is quite similar to the 441 previous one. In this sequence the restart timer will not expire in 442 LSR B since it is run infinitely. Instead after LSR A restarts LSR B 443 MUST start the recovery timer. The recovery timer will expire since 444 there will be no Path message with the RECOVERY LABEL received from 445 LSR A given the ingress node had already removed the local Path state 446 after it aborts the handover process. Thus LSR B MUST tear-down the 447 specific LSP that is being used to convert the MP resources to CP by 448 generating a PathTear message downstream and PathErr message 449 upstream. Similarly to the previous case both LSR B and the egress 450 LER MUST NOT release the DP resources because the H bit is set in the 451 local Path state. 453 | Path | Path | Path | 454 |--------------->|--------------->|--------------->| 455 | | | Resv | 456 | | Resv |<---------------| 457 | X X---------| | 458 | PathTear | | 459 |-------X | | 460 | | | 461 | X | | 462 | | | | 463 | | Recovery Timer | 464 | | Expires | 465 | PathErr | PathErr | PathTear | 466 |<---------------|<---------------|--------------->| 467 | | | | 468 Ingress LER LSR A LSR B Egress LER 470 MP2CP - Node graceful restart - Case II 472 Case III 474 Ingress LER did not abort the handover process. Once LSR A restarts 475 the ingress LER MUST re-generate the Path message with the H bit set. 476 When LSR B receives the Path message it MAY generate a PathErr since 477 the RECOVERY LABEL may not be present. The reason is LSR A may not 478 have the label. Similarly LSR B and egress LER MUST NOT release the 479 DP resources since the H bit is set. 481 | Path | Path | Path | 482 |--------------->|--------------->|--------------->| 483 | | | Resv | 484 | | Resv |<---------------| 485 | X X---------| | 486 | | | 487 | X | | 488 | | | | 489 | Path | Path | | 490 |--------------->|--------------->| | 491 | PathErr | PathErr | PathTear | 492 |<---------------|<---------------|--------------->| 493 | | | | 494 Ingress LER LSR A LSR B Egress LER 496 MP2CP - Node graceful restart - Case III 498 4.3. CP to MP handover : LSP Ownership Transfer From Control Plane To 499 Management Plane 501 Let's now consider the case of LSP Ownership Transfer From Control 502 Plane To Management Plane. Also in this sections we will analyze the 503 handover procedure success and failure. 505 The scenario is still a DP connection between two nodes acting as 506 ingress and egress for a LSP, but in this case the CP has the 507 ownership and control of the LSP. The CP to MP handover procedure 508 MUST delete the existing RSVP-TE session information and MUST NOT 509 affect the cross-connected resources, but just move their ownership 510 to the MP. 512 In other words, after LSP ownership transfer from CP to MP, the LSP 513 is no longer under control of RSVP-TE, which is no more able to "see" 514 the LSP itself. The CP to MP handover procedure MUST be a standard 515 LSP deletion procedure as described in Section 7.2.1 of [RFC3473]. 516 The procedure is initiated at the ingress node of the LSP by a MP 517 entity. Ingress node and MP exchange the relevant information for 518 this task and then propagate it over CP by means of RSVP-TE tear down 519 signaling as described below. 521 The ingress node MUST send a Path message in the downstream direction 522 with Handover and Reflect bits set in the Admin Status Object. No 523 action is taken over the DP and transit LSRs must forward such 524 message towards the egress node. All of the nodes MUST keep track of 525 the procedure storing the H and R bits in their local Path and Resv 526 states. Then every node waits for the H bit to be received within 527 the related Resv message. After the Resv message is received by the 528 ingress LER, it MUST send a PathTear message in order to clear the 529 whole LSP information recorded on the RSVP-TE data structures of the 530 nodes. Downstream nodes processing a PathTear message which follows 531 a Path message with the H bit set, MUST NOT remove any associated 532 data plane state. In other words, a normal LSP tear down signaling 533 is exchanged between nodes traversed by the LSP, but H bit set in the 534 Path message indicates that no DP action has to correspond to CP 535 signaling. 537 4.4. CP to MP Handover Procedure Failure 539 Failures during CP to MP handover procedure MUST be managed at 540 signaling level as in normal LSP tear down procedure. The only 541 difference is the H bit set in Administrative Status Object inside 542 Path message which MUST be read by receiving node and imposes that no 543 action has to be made over DP resource whose corresponding Control 544 Plane record is involved in handover procedure. 546 5. Alternative Way Of Retrieving Information Needed For MP To CP 547 Handover 549 An alternative way of getting the LSP related information required 550 for the MP to CP handover is also defined in this draft. The 551 rationale behind this way is that only a minimal set of information 552 is handed over from MP to CP at LSPs Ingress node. Instead of 553 collecting within MP all the LSP relevant information down to the 554 Label level, formatting it to an ERO and passing it to CP, as in 555 previously described solution, it is possible to start with a minimum 556 amount of information. At the ingress node, the information needed 557 to specify the LSP is the outgoing interface ID, upstream label and 558 downstream label of this interface and the egress node ID. The 559 remaining information about an existing LSP can then be collected hop 560 by hop, as the signalling is going on, by looking up the cross- 561 connection table in DP at each node along the LSP path. 563 Starting from the information available at ingress LER about the 564 outgoing interface ID of that ingress node, the incoming interface ID 565 of next hop can be found by looking up the link resource table/ 566 database in the LER itself. 568 The Path message is hence built with the LABEL_SET Object ([RFC3473]) 569 and the UPSTREAM_LABEL Object ([RFC3473]), where the upstream label 570 and downstream label of ingress outgoing interface of the LSP are 571 included in these two objects. In addition to above mentioned 572 objects, the Path message MUST include the Administrative Status 573 Object with H bit set, as already defined in previous chapters for 574 the detailed ERO based way of proceeding. Such handover Path is sent 575 to the incoming interface of next hop. When this Path message 576 reaches the second node along the LSP path, the information about 577 incoming interface ID and the upstream and downstream labels of this 578 interface is extracted from it and it is used to find next hop 579 outgoing interface ID and the upstream/downstream labels by looking 580 up the DP cross-connection table. 582 After having determined in this way the parameters describing the 583 LSPs next hop, the outgoing Path message to be sent is built 584 replacing the LABEL_SET Object and UPSTREAM_LABEL Object content with 585 the looked-up values of upstream and downstream labels. 587 By repeating this procedure for each transit node along the LSP path, 588 it is possible to make the handover Path message reach the egress 589 node, exactly following the LSP that is in place over DP. The ERO 590 MAY in this case be included in the Path message as an optional 591 object, and MAY be filled with the LSP relevant information down to 592 either the port level with interface ID or the Label level with 593 upstream and downstream labels. The ERO can be used to check the 594 consistency of resource in DP down to the port level or label level 595 at each intermediate node along the LSP path. 597 Where the DP path continues beyond the egress, by indicating the 598 Egress label at the head-end of an LSP, the traffic can be directed 599 to the right destination. The GMPLS Signaling Procedure for Egress 600 Control is described in [RFC4003] 602 6. RSVP Message Formats 604 This memo does not introduce any modification in RSVP messages object 605 composition. 607 7. Objects Modification 609 The modifications required concern two RSVP Objects: the 610 Administrative Status and the Error Spec Object. 612 7.1. Administrative Status Object 614 This memo introduces a new flag into the Administrative Status 615 object. The Admin_Status Object is defined in [RFC3473]. This 616 document uses the H bit of the Admin_Status object. The bit is bit 617 number (TBD by IANA). The format of the Admin_Status Object is: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Length | Class-Num(196)| C-Type (1) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |R| Reserved |H|L|I|C|T|A|D| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 The different flags are defined as follows: 629 - Reflect (R): 1 bit - Defined in [RFC3471] 631 - Handover (H): 1bit 632 When set, the H bit indicates that a Handover procedure for the 633 transfer of LSP ownership between Management and Control Planes is 634 ongoing. 636 - Lockout (L): 1 bit - Defined in [RFC4872] 638 - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783] 639 - Call Control (C): 1 bit - Defined in [RFC3471] 641 - Testing (T): 1 bit - Defined in [RFC3471] 643 - Administratively down (A): 1 bit - Defined in [RFC4974] 645 - Deletion in progress (D): 1 bit - Defined in [RFC3471] 647 7.2. Error Spec Object 649 It is possible that a failure, such as the loss of DCN connection or 650 the restart of a node, occurs during the LSP ownership handing over. 651 In this case the LSP handover is interrupted and the ownership of the 652 LSP moved back to the Plane it belonged to. It is important that the 653 transaction failure does not affect the DP. The LSP is kept in place 654 and no traffic hit occurs. 656 The failure is signaled by PathErr in the upstream direction and 657 PathTear Messages in the downstream direction. The PathErr messages 658 include an Error_Spec_Object specifying the causes of the failure. 660 This memo introduces a new Error Code (with different Error Values) 661 into the Error_Spec Object, defined in [RFC2205]. 663 The defined Error Code is "Handover Procedure Failure", and its value 664 is (TBD by IANA)(33). For this Error Code the following Error Values 665 are defined: 667 1 = Cross-connection mismatch 669 2 = DCN error 671 3 = Other failure 673 8. Compatibility 675 The main requirement for Handover procedure to work is that all nodes 676 along the path MUST support the extension defined in this draft. In 677 case a node does not support the Handover procedure, the upstream 678 node along the path MUST send a PathErr message in the upstream 679 direction including an Error_Spec_Object specifying the causes of the 680 failure. 682 9. Acknowledgments 684 We wish to thank Adrian Farrel and Lou Berger for their assistance 685 and precious advices to prepare this draft for publication. We also 686 wish to thank Nicola Ciulli, that contributed to initial stage of 687 this draft. 689 10. Contributors 691 Shan Zhu 692 Fujitsu Network Communications Inc. 693 2801 Telecom Parkway, 694 Richardson, Texas 75082 695 USA 696 Email: Shan.Zhu@us.fujitsu.com 697 Tel: +1-972-479-2041 699 Igor Bryskin 700 ADVA Optical Networking Inc 701 7926 Jones Branch Drive 702 Suite 615 703 McLean, VA - 22102 704 Email: ibryskin@advaoptical.com 706 Lou Berger 707 LabN Consulting, LLC 708 Phone: +1 301 468 9228 709 EMail: lberger@labn.net 711 11. Security Considerations 713 The procedures described in this document rely completely on RSVP-TE 714 messages and mechanism. The use of H bit set in Admin Status Object 715 basically informs the receiving entity that no operations are to be 716 done over DP as consequence of such special signaling flow. Using 717 specially flagged signaling messages we want to limit the function of 718 setup and tear down messages to CP, making them not effective over 719 related DP resource usage. So, no additional or special issues are 720 arisen by adopting this procedure, that aren't already brought up by 721 the use of the same messages, without H bit setting, for LSP control. 722 For RSVP-TE Security please refer to [RFC3473]. 724 12. IANA Considerations 726 IANA has been asked to manage the bit allocations for the 727 Administrative Status object ([RFC3473]). This document requires the 728 allocation of the Handover bit: the H bit. IANA is requested to 729 allocate a bit for this purpose. 731 13. References 733 13.1. Normative References 735 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 736 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 737 Functional Specification", RFC 2205, September 1997. 739 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 740 and S. Molendini, "RSVP Refresh Overhead Reduction 741 Extensions", RFC 2961, April 2001. 743 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 744 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 745 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 747 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 748 Control", RFC 4003, February 2005. 750 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) 751 RSVP-TE Signaling Extensions in Support of Calls", 752 RFC 4974, August 2007. 754 13.2. Informational References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 760 (GMPLS) Signaling Functional Description", RFC 3471, 761 January 2003. 763 [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", 764 RFC 4783, December 2006. 766 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 767 Extensions in Support of End-to-End Generalized Multi- 768 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 769 May 2007. 771 [RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 772 "Requirements for the Conversion between Permanent 773 Connections and Switched Connections in a Generalized 774 Multiprotocol Label Switching (GMPLS) Network", RFC 5493, 775 April 2009. 777 Authors' Addresses 779 Diego Caviglia 780 Ericsson 781 Via A. Negrone 1/A 782 Genova - Sestri Ponente 783 Italy 785 Email: diego.caviglia@ericsson.com 787 Daniele Ceccarelli 788 Ericsson 789 Via A. Negrone 1/A 790 Genova - Sestri Ponente 791 Italy 793 Email: daniele.ceccarelli@ericsson.com 795 Dino Bramanti 796 Ericsson 797 Via Moruzzi 1 C/O Area Ricerca CNR 798 Pisa 799 Italy 801 Email: dino.bramanti@ericsson.com 803 Dan Li 804 Huawei Technologies 805 F3-5-B R&D Center, Huawei Base 806 Shenzhen 518129 807 P.R.China 809 Email: danli@huawei.com 810 Snigdho Bardalai 811 Fujitsu Network 812 2801 Telecom Parkway 813 Richrdson, Texas 75082 814 USA 816 Email: Snigdho.Bardalai@us.fujitsu.com