idnits 2.17.1 draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1022. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 111 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [RFC3471], [RFC3473], [RFC4872], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: It is possible that a failure, such as the lost of DCN connection or the restart of a node, occurs during the LSP ownership handing over. In this case the LSP adoption MUST be interrupted and the ownership of the LSP MUST be moved back to the Plane it belonged to. It is important that the transaction failure MUST not affect the Data Plane. The LSP MUST be kept in place and no traffic hit MUST occur. -- 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 (October 28, 2008) is 5630 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) == Unused Reference: 'RFC4606' is defined on line 919, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Expires: May 1, 2009 D. Bramanti 5 Ericsson 6 D. Li 7 Huawei Technologies Co., LTD. 8 S. Bardalai 9 Fujitsu Network Communications Inc 10 October 28, 2008 12 RSVP-TE Signaling Extension For The Conversion Between Permanent 13 Connections And Soft Permanent Connections In A GMPLS Enabled Transport 14 Network. 16 draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on May 1, 2009. 43 Abstract 45 We would like to dedicate this work to our friend and colleague Dino 46 Bramanti, who passed away at the early age of 38. Dino has been 47 involved in this work since its beginning. 49 In a transport network scenario, where Data Plane connections 50 controlled either by GMPLS Control Plane (Soft Permanent Connections 51 - SPC) or by Management System (Permanent Connections - PC) may 52 independently coexist, the ability of transforming an existing PC 53 into a SPC and vice versa - without actually affecting Data Plane 54 traffic being carried over it - is a requirement. See draft 55 "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor 56 extension to RSVP-TE [RFC2205], [RFC3471], [RFC3473], [RFC4872] 57 signaling protocol, within GMPLS architecture, to enable such 58 connection ownership transfer and describes the proposed procedures. 59 Failure conductions and subsequent roll back are also illustrated 60 taking into account that an handover failure must not impact the 61 already established data plane connections. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Overview Of Proposed RSVP-TE Based Solution . . . . . . . . . 3 69 5. MP to CP handover: LSP Ownership Transfer From Management 70 Plane To Control Plane . . . . . . . . . . . . . . . . . . . . 5 71 5.1. MP to CP Handover Procedure Success . . . . . . . . . . . 6 72 5.2. MP to CP Handover Procedure Failure Handling . . . . . . . 7 73 5.2.1. MP to CP Handover Failure - Path Failure . . . . . . . 7 74 5.2.2. MP to CP Handover Failure - Resv Error . . . . . . . . 8 75 6. CP to MP handover : LSP Ownership Transfer From Control 76 Plane To Management Plane . . . . . . . . . . . . . . . . . . 13 77 6.1. CP to MP Handover Procedure Success . . . . . . . . . . . 13 78 6.2. CP to MP Handover Procedure Failure . . . . . . . . . . . 14 79 7. Discovery Phase . . . . . . . . . . . . . . . . . . . . . . . 14 80 8. Alternative Way Of Retrieving Information Needed For MP To 81 CP Handover . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. RSVP Message Formats . . . . . . . . . . . . . . . . . . . . . 16 83 10. Objects Modification . . . . . . . . . . . . . . . . . . . . . 17 84 10.1. Administrative Status Object . . . . . . . . . . . . . . . 17 85 10.2. Error Spec Object . . . . . . . . . . . . . . . . . . . . 18 86 11. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 87 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 92 15.2. Informational References . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Intellectual Property and Copyright Statements . . . . . . . . . . 23 96 1. Introduction 98 In a typical traditional transport network scenario, Data Plane 99 connections between two endpoints are controlled by means of a 100 Network Management System (NMS) operating within Management Plane 101 (MP). NMS/MP is the owner of such transport connections, being 102 responsible of their set up, tear down and maintenance. 104 The adoption of a GMPLS Control Plane over networks that are already 105 in service - controlled by NMS at Management Plane level - introduces 106 the need for a procedure able to coordinate a control handover of a 107 generic data plane connection from MP to CP. 109 In addition, the control handover in the opposite direction, from CP 110 to MP SHOULD be possible as well. The procedures described in this 111 memo can be applied to any kind of LSP and network architecture. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Motivation 121 The main motivation behind this work is the definition of a simple 122 and very low impacting procedure that satisfies the requirements 123 defined in "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. Such procedure 124 is aimed at giving the transport network operators the chance to 125 convert existing LSP provisioned as PC by NMS to SPC without 126 disrupting user traffic flowing on it. Conversion from PC to SPC 127 (i.e. when existing Data Plane connection ownership and control is 128 passed from MP to CP) has been proposed as mandatory requirement, 129 while the opposite operation, SPC to SC conversion, has been 130 considered as a nice-to-have feature that can be seen as a back-out 131 option. For more details on requirements and motivations please 132 refer to "draft-ietf-ccamp-pc-and-reqs-04.txt [1]. 134 4. Overview Of Proposed RSVP-TE Based Solution 136 The whole process comprises of the discovery and conversion phases. 137 The discovery phase being described in this document is an OPTIONAL 138 procedure and not mandatory for the conversion phase to proceed. The 139 discovery phase is typically initiated by the operator and is 140 performed hop-by-hop in order to discover the route. The route 141 discovered SHOULD be consistent with the network topology. For 142 example, for a multi-layer network the hops discovered should be 143 contained within the same layer. 145 Prior to initiating the discovery process it is assumed that the 146 Control Plane domains have been established. The operator at the 147 originating node can optionally specify the terminating end-point at 148 the time of initiating the discovery request or it could be 149 automatically discovered. For example, at a network layer boundary 150 the discovery process can be terminated generating a response back to 151 the originator. Another possibility is to terminate the request at 152 the Control Plane domain boundary. 154 For conversion to PC or SPC the conversion phase will create an RSVP- 155 TE session along the discovered or user-specified route and bind with 156 the existing Management Plane owned cross-connect resources (e.g. 157 lambdas, time slots and reserved bandwidth)and at the same time 158 transfer the ownership to the Control Plane. For conversion to PC 159 the conversion phase will delete the existing RSVP- TE session 160 information without deleting the cross-connect resources and transfer 161 the ownership to the Management Plane. 163 Proposed procedure relies on the utilization of a newly introduced 164 flag, here named Handover flag, in the Administrative Status Object 165 [RFC3471] and [RFC3473]. The point is that standard RSVP-TE 166 signaling flow can be used to inform nodes about the ownership 167 handover request regarding one LSP that is already in place on their 168 Data Plane, where such flow has to be flagged in order to 169 discriminate it from normal, Data Plane affecting, LSP setup/release 170 procedure. When a LSP owned by Management Plane (i.e. a PC) has to 171 be handed over to Control Plane (i.e. converted into a SPC), a 172 signaling set-up with HANDOVER flag set has to be sent from ingress 173 node. 175 For the opposite procedure (when a LSP owned and controlled by 176 Control Plane has to be handed over to Management Plane, i.e. SPC to 177 PC conversion - or back out procedure for previous case) a signaling 178 tear-down with HANDOVER flag set has to be sent from ingress or 179 egress node, following the same procedure of a normal tear-down, from 180 which is recognizable again by reading flag value. 182 So, basically the HANDOVER flag is introduced and exploited to tell 183 apart a normal set-up (or tear-down) procedure - that has to trigger 184 an action on Data Plane state at each addressed node along the path 185 as usual - from the LSP ownership handover procedure that MUST leave 186 untouched Data Plane state. 188 This is in some way similar as an approach to the Restart Procedure, 189 ([RFC2119]), in the sense that the status of the physical resources 190 at Data Plane has to stay unmodified but the associated information 191 allowing its control has to be transferred. The modification 192 proposed in this document refers only to Administrative Status 193 object, that is, the message flow is left unmodified for both set-up 194 and deletion. Moreover a new Error Value is defined to identify the 195 failure of an Handover procedure. 197 It is worth stressing that, when the LSP over Data Plane is adopted 198 either by CP or MP, i.e. at the end of signaling with Handover flag 199 set, normal CP procedures or MP procedures have to take their place 200 as usual when needed. This means that a LSP formerly owned by MP, 201 signalled within CP with Handover flag set (i.e. handed over to CP) 202 can be controlled by usual relevant Control Plane signaling flows 203 (i.e. with Handover flag not set). The same applies when considering 204 the handover of a LSP from CP to MP when, at the end of procedure, 205 the LSP belongs to Management Plane and can be fully controlled by 206 NMS. In other words, after the LSP handover procedures have taken 207 place, the LSP is not different from the other LSP owned by handover 208 destination entity and it has to be treated with usual rules for that 209 entity. 211 Following paragraphs give detailed description of proposed "MP to CP 212 handover" and "CP to MP handover" procedure, based on Handover flag 213 usage. Handover of a bidirectional LSP is assumed. The case of 214 unidirectional LSP can be easily derived from that. 216 5. MP to CP handover: LSP Ownership Transfer From Management Plane To 217 Control Plane 219 Let's consider the case of a Data Plane connection created by NMS. 220 The Management Plane has the ownership and control of the LSP and 221 wants to hand it over to Control Plane. At the ingress node NMS 222 initiates the transfer of LSP related information residing within 223 Management Plane to RSVP-TE records within Control Plane. We assume 224 that this happens under operator or management application control 225 and in particular that: 227 - Control requests are sent to the ingress LSR by the MP 228 - The MP has some way of knowing when the CP has completed its 229 task or has failed. 231 Ingress node collects from MP all the LSP related information needed 232 at Control Plane level. The way this operation is done and where 233 such information is collected within MP is outside the scope of this 234 document. One possible (optional) way to collect it is explained in 235 Section 8. 237 A relevant part of such information is represented by the LSP path, 238 which has to be handed over to CP to be used by signalling entity to 239 fill the Explicit Route Object (ERO) during setup. In order to 240 support the MP to CP handover of LSP, the ERO object in the Path 241 message MUST be filled with all the LSP relevant information down to 242 the Label level. That can be done by means of the object and 243 procedures defined in [RFC3473]. 245 The precise filling of the ERO object is needed as we are assuming 246 that the LSP already exists in Data Plane and that every signalling 247 relevant info about it is available and accessible to MP in terms of 248 required LSP parameters to build a RSVP-TE PATH message. After the 249 collection of all the LSP related information, the ingress node 250 starts the handover procedure issuing a RSVP-TE PATH message 251 including the Administrative Status Object with both HANDOVER and 252 REFLECT flags set. The R flag set assures that also the Resv message 253 will set the H flag. Upon reception of such RSVP-TE PATH, a node 254 MUST be able to understand that a MP to CP handover procedure is in 255 progress by reading the Handover flag. 257 Either the ingress node of the LSP (upon request from MP) and 258 intermediate and egress nodes (when receiving a Path/Resv message 259 containing an Administrative Status object with the Handover flag 260 set) are informed about the fact that a LSP handover procedure is 261 requested or ongoing. The node assumes that a Data Plane resource 262 related to the info carried in Path Message is already allocated and 263 in place. 265 The following of the section illustrates in detail the procedure in 266 cases in success and failures. 268 5.1. MP to CP Handover Procedure Success 270 Upon receiving a Path Message, each node SHOULD check the consistence 271 of the actual Data Plane status of such resource. Say the check goes 272 OK (failure cases are illustrated in the next sections), then a 273 RSVP-TE record for the LSP is created associating it to the 274 corresponding Data Plane state. The node accepts all the LSP 275 information carried in the Path message (if the node is not the 276 Ingress LER of the LSP, otherwise the information is sent from 277 relevant MP entity) and stores it in Path State Block. After that, 278 the procedure goes on as described below. 280 After propagating handover Path message, a node MUST wait for a Resv 281 message including Administrative Status Object with Handover flag 282 set. After receiving it, the actual migration of LSP information is 283 complete, the LSP is left completely under control of RSVP- TE within 284 Control Plane. This means that any memory about the former MP 285 ownership of the LSP is lost. If a Confirmation message was 286 requested, then it is generated. The handover procedure does not 287 modify the Confirmation procedure. 289 5.2. MP to CP Handover Procedure Failure Handling 291 In case of Management Plane to Control Plane Procedure, two different 292 failure scenarios can happen: Path Failure and Resv Failure. 293 Moreover, each failure can be due to two different causes: Data Plane 294 failure or Communication Failure. A section for each combination 295 will be analyzed in the following. 297 5.2.1. MP to CP Handover Failure - Path Failure 299 5.2.1.1. MP to CP Handover Failure - Path Message and Data Plane 300 Failure 302 The handover procedure can fail due to different causes, but in any 303 case the network status MUST be immediately rollbacked to the one 304 previous to the handover procedure. The failure can happen during 305 the Path message or the Resv message forwarding. In this paragraph 306 we will analyze the first case. 308 | Path | | | 309 |---------------------->| Path | | 310 | |----------------------X| | 311 | | | | 312 | Path Err | | | 313 |<----------------------| | | 314 | | | | 315 Ingress LER LSR A LSR B Egress LER 317 If an error occurs in an LSR or a LER, the last node that has 318 received the Path message MUST send a Path Error message in the 319 upstream direction including an Error_Spec object and the Handover 320 flag set. The Path Error message SHOULD have the Path_State_Removed 321 flag set and the upstream nodes MAY process the Error_Spec object. 323 5.2.1.2. MP to CP Handover Failure - Path Message and Communication 324 failure 326 Other possible scenarios are shown in the following pictures and 327 consist on the unreachability of a node of the LSP. 329 The below scenario postulates the usage of a reliable message 330 delivery based on the mechanism defined in [RFC2961]. 332 | Path | | | 333 |---------------------->| Path | | 334 | |------------X | | 335 | |------------X | | 336 | | ... | | 337 | |------------X | | 338 | | | | 339 | Path Err | | | 340 |<----------------------| | | 341 | | | | 342 Ingress LER LSR A LSR B Egress LER 344 The Path message sent from LSR A towards LSR B is lost or does not 345 reach the destination for any reason. A reliable delivery mechanism 346 is implemented, LSR A retransmits the Path Message for a configurable 347 number of times, then, if no ack is received, a Path Error message 348 MUST be sent back to the ingress LER, the Path_State_Removed flag 349 SHOULD be set and the adoption procedure is aborted. 351 In the next scenario RSVP-TE messages are sent without reliable 352 message delivery, that is, no [RFC2961] MessageID procedure is used. 354 | Path | | | 355 |---------------------->| Path | | 356 | |------------X | | 357 | | | | 358 | | | | 359 |----TIMER EXPIRES------| | | 360 | Path Tear | | | 361 |---------------------->| | | 362 | | | | 363 Ingress LER LSR A LSR B Egress LER 365 If the Resv Message is not received by the expiration of a timer set 366 by the ingress LER, the adoption procedure is again aborted and a 367 PathTear message MAY be sent in the downstream direction with the H 368 bit set. 370 5.2.2. MP to CP Handover Failure - Resv Error 372 5.2.2.1. MP to CP Handover Failure - Resv Error and Data Plane failure 374 In case a failure occurs during the Resv Message forwarding, things 375 are quite different, because after the handover procedure an LSR is 376 not able to distinguish an LSP created by the Control Plane from an 377 LSP created by the Management Plane and then moved to the Control 378 Plane. 380 | Path | Path | Path | 381 |---------------------->|---------------------->|---------------------->| 382 | | | Resv | 383 | | Resv |<----------------------| 384 | |X----------------------| | 385 | Path Err | Path Tear | | 386 |<----------------------|---------------------->| Path Tear | 387 | | |---------------------->| 388 | | | | 389 Ingress LER LSR A LSR B Egress LER 391 In the case shown in the above picture, the failure occurs in LSR A. 392 Considering to have a reliable message delivery mechanism, a Path 393 Tear message MUST be sent in the downstream direction and a Path 394 Error message MUST sent in the upstream direction and the 395 Path_State_Removed SHOULD flag should be set. The Path Err and Path 396 Tear messages remove the Path state established by the Path messages 397 along the nodes of the LSP and abort the adoption procedure. 399 Please note that the failure occurred after the handover procedure 400 was successfully completed in LSR B. This means that LSR B is no 401 longer able to know if the LSP was created by the Control Plane or a 402 handover procedure took place. 404 Upon receiving a Path Tear message, LSR B would delete the LSP also 405 from the Data Plane point of view. To prevent this from happening, 406 LSR A MUST set the handover flag in the Path Tear message. The 407 downstream node move the LSP ownership back to the Management Plane 408 and MUST NOT modify the Data Plane. 410 5.2.2.2. MP to CP Handover Failure - Resv Error and Communication 411 failure 413 In case a Resv Message cannot reach one or more of the downstream 414 nodes, the procedure is quite similar to the one previously seen 415 about the Path Message. Even in this case it is possible to 416 distinguish two different scenarios. 418 In the first scenario we consider the utilization of a reliable 419 message delivery based on the mechanism defined in [RFC2961]. After 420 a correct forwarding of the Path message along the nodes of the LSP, 421 the Egress LSR sends a Resv message in the opposite direction. It 422 might happen that the Resv message does not reach an LSR, say LSR A. 424 LSR B, after sending the Resv message again for a configurable number 425 of times, MUST send a Path Tear message in the downstream direction 426 towards the Egress LER and a Path Error message (with the 427 Path_State_Removed flag set) in the upstream direction towards the 428 Ingress LER in order to inform the nodes of the path that the 429 adoption procedure has failed and that the LSP ownership is to be 430 moved back to the management plane. 432 | Path | Path | Path | 433 |---------------------->|---------------------->|---------------------->| 434 | | | Resv | 435 | | Resv |<----------------------| 436 | | X-----------| | 437 | | X-----------| | 438 | | ... | | 439 | | X-----------| | 440 | | | | 441 | Path Err | Path Err | Path Tear | 442 |<----------------------|<----------------------|---------------------->| 443 | | | | 444 Ingress LER LSR A LSR B Egress LER 446 Please note that the failure occurred after the handover procedure 447 was successfully completed in the Egress LER. This means that it is 448 no longer able to know if the LSP was created by the Control Plane or 449 a handover procedure took place. 451 Upon receiving a Path Tear message, the downstream nodes would delete 452 the LSP also from the Data Plane point of view. To prevent this from 453 happening, the Path Tear message MUST include the Handover flag. 455 Considering that the Resv message did not manage to reach LSR A, it 456 is highly probable that the Path Error would fail too. Due to this 457 fact, a configurable timer MUST be set on the Ingress LER after 458 sending the path and on LSR A after forwanding it. When the timer 459 expires, if no Resv or Path Error message is received, the handover 460 procedure MUST be aborted and the LSP ownership returned to the 461 Management Plane. 463 The following picture, on the other hand, shows the scenario in which 464 no reliable delivery mechanism is implemented. 466 | Path | Path | Path | 467 |---------------------->|---------------------->|---------------------->| 468 | | | Resv | 469 | | Resv |<----------------------| 470 | | X-----------| | 471 | | | | 472 | | | | 473 |----TIMER EXPIRES------| | | 474 | Path Tear | Path Tear | Path Tear | 475 |---------------------->|---------------------->|---------------------->| 476 | | | | 477 Ingress LER LSR A LSR B Egress LER 479 After sending the path message, the ingress LER sets a timer. If non 480 Resv message is received before the timer expires, then the adoption 481 procedure is aborted and the Ingress LER MAY signal it by a Path Tear 482 message with the H bit set. 484 5.2.2.3. MP to CP Handover Failure - Node Graceful Restart 486 In case one of the nodes restarts and graceful restart is enabled 487 then one of the following scenarios will happen. 489 Case I 491 Restart timer is not infinite. In the sequence diagram below, assume 492 LSR A restarts. In case the ingress LER does not receive the Resv 493 message in time it will abort the conversion process by generating a 494 PathTear message downstream. Also, if LSR A does not complete the 495 restart process within the restart time interval then LSR B will 496 start tearing down all LSPs between LSR A and LSR B and this includes 497 the LSP that is being used to carry out the conversion of MP 498 resources to CP. LSP B will generate a PathTear message downstream 499 and a PathErr message upstream. Both LSR B and the egress LER will 500 not release the data-plane resources because in both nodes the H-bit 501 is set in the PSB. 503 | Path | Path | Path | 504 |---------------------->|---------------------->|---------------------->| 505 | | | Resv | 506 | | Resv |<----------------------| 507 | X X-----------| | 508 | PathTear | | 509 |----------X | | 510 | Restart Timer | 511 | PathErr Expires PathTear | 512 | X-----------|---------------------->| 513 | X | | 514 | | | | 515 Ingress LER LSR A LSR B Egress LER 517 Case II 519 Restart timer is infinite. The sequence is quite similar to the 520 previous one. In this sequence the restart timer will not expire in 521 LSR B since it is run infinitely. Instead after LSR A restarts LSR B 522 will start the recovery timer. The recovery timer will expire since 523 there will be no Path message with the RECOVERY LABEL received from 524 LSR A given the ingress node had already removed the PSB after it 525 aborts the conversion process. Thus LSR B will tear-down the 526 specific LSP that is being used to convert the MP resources to CP by 527 generating a PathTear downstream and PathErr upstream. Similarily to 528 the previous case both LSR B and the egress LER will not release the 529 data-plane resources because the H-bit is set in the PSB. 531 | Path | Path | Path | 532 |---------------------->|---------------------->|---------------------->| 533 | | | Resv | 534 | | Resv |<----------------------| 535 | X X-----------| | 536 | PathTear | | 537 |----------X | | 538 | | | 539 | X | | 540 | | | | 541 | | Recovery Timer | 542 | | PathErr Expires PathTear | 543 | | X-----------|---------------------->| 544 | | | 545 Ingress LER LSR A LSR B Egress LER 547 Case III 549 Ingress LER did not abort the conversion process. Once LSR A 550 restarts the ingress LER will re-generate the Path message with the 551 H-bit set. When LSR B receives the Path message it may generate a 552 PathErr since the RECOVERY LABEL may not be present. The reason is 553 LSR A may not have the label. Similarily LSR B and egress LER will 554 not release the data-plane resources since the H-bit is set. 556 | Path | Path | Path | 557 |---------------------->|---------------------->|---------------------->| 558 | | | Resv | 559 | | Resv |<----------------------| 560 | X X-----------| | 561 | | | 562 | | | 563 | X | | 564 | Path | Path | | 565 |---------------------->|---------------------->| | 566 | PathErr | PathErr | PathTear | 567 |<----------------------|<----------------------|---------------------->| 568 | | | | 569 Ingress LER LSR A LSR B Egress LER 571 6. CP to MP handover : LSP Ownership Transfer From Control Plane To 572 Management Plane 574 Let's now consider the case of LSP Ownership Transfer From Control 575 Plane To Management Plane. Also in this sections we will analyze the 576 handover procedure success and failure. 578 6.1. CP to MP Handover Procedure Success 580 The scenario is still a Data Plane connection between two nodes 581 acting as ingress and egress for a LSP. But let's assume in this 582 case that Control Plane has the ownership and control of the LSP and 583 that we want to hand it over to Management Plane. This means that at 584 the end of such procedure, the Data Plane state related to that 585 connection is still untouched, but the LSP related information record 586 is no more owned by RSVP-TE over Control Plane. 588 In other words, after LSP ownership transfer from CP to MP, the LSP 589 is no more under control of RSVP-TE, which is no more able to "see" 590 the LSP itself. This Section covers the procedure needed to manage 591 this procedure as a dual, opposite procedure respect to the one 592 described in previous section. The procedure is performed at a 593 signaling level as described in Section 7.2.1 of [RFC3473]. 595 At LSP ingress node, relevant MP entity requests the ownership of the 596 LSP, How this is done is outside the scope of memo. Ingress node and 597 MP exchange the relevant information for this task and then 598 propagates it over Control Plane by means of RSVP-TE tear down 599 signaling flow as detailed below. 601 Ingress node MUST send out a Path message, with Handover and Reflect 602 bits in Admin Status set. No action is taken over Data Plane and 603 Control Plane keeps track of special handover state the LSP is in. 604 Transit and Egress nodes, upon reception of such handover Path, 605 propagate it without any Data Plane action, retaining the handover 606 state information associated to the LSP. After that, every node 607 waits until the Handover bit is received back in the Resv. Then a 608 PathTear is issued and the whole LSP information record is cleared 609 from RSVP- TE data structures. In other words, a normal LSP tear 610 down signaling is exchanged between nodes traversed by the LSP, but 611 handover flag set in Path message indicates that no Data Plane action 612 has to correspond to Control Plane signaling. At the end of handover 613 tear down signaling flow, the LSP is released from Control Plane 614 point of view, but its Data Plane state is still unmodified and it is 615 now owned and controllable by MP. 617 6.2. CP to MP Handover Procedure Failure 619 Failures during CP to MP handover procedure MUST be managed at 620 signaling level as in normal LSP tear down procedure. The only 621 difference is the handover flag set in Administrative Status Object 622 inside Path message which MUST be read by receiving node and imposes 623 that no action has to be made over Data Plane resource whose 624 corresponding Control Plane record is involved in handover procedure. 626 7. Discovery Phase 628 The discovery process starts at the orignating end-point, which 629 transmits a discovery request Notify message on the link identified 630 to be part of the LSP to be converted. The Notify message is 631 forwarded hop-by-hop tracing the LSP information and identifying the 632 next-hop. The assumption being made here is that information 633 regarding individual neighbors is already available. 635 In case the destination address is not known the RSVP-TE session 636 destination address MAY not be specified (i.e. set to 0.0.0.0) in the 637 discovery request Notify message. 639 Any node that decides to terminate the discovery process will not 640 forward the Notify message and will generate a discovery response 641 Notify message. 643 If any error prevents the discovery process to be successfully 644 completed, the ERROS_SPEC object in the response Notify message will 645 be filled with a failure code, else it MUST be se set to the success 646 code. The discovery response message SHOULD be sent hop-by-hop back 647 to the requestor. 649 In case the destination address in the request message is 0.0.0.0 650 then it MUST be filled in by the terminating entity in the response 651 message SESSION object. 653 The format of the Notify Message is as follows: 655 ::= [ ] 656 [[ | ]...] 657 [ ] 658 659 661 ::= 662 [ ] 663 [ ] 664 [ ] 665 [ ] 666 [ ] 668 The RECORD_ROUTE object in the discovery response SHOULD be put 669 together such that it can be directly used in a Path message for the 670 coversion phase. For example, explitcit label sub-objects can be 671 specified only for outgoing links in the Path message [RFC3473]. 673 8. Alternative Way Of Retrieving Information Needed For MP To CP 674 Handover 676 An alternative way of getting the LSP related information required 677 for the MP to CP handover is also proposed in this draft. The 678 rationale behind this way is that only a minimal set of information 679 is handed over from MP to CP at LSPs Ingress node. Instead of 680 collecting within MP all the LSP relevant information down to the 681 Label level, formatting it to an ERO and passing it to CP, as in 682 previously described solution, it is possible to start with a minimum 683 amount of information. At the ingress node, the information needed 684 to specify the LSP is the outgoing interface ID, upstream label and 685 downstream label of this interface and the incoming interface ID of 686 egress node. The remaining information about an existing LSP can 687 then be collected hop by hop, as the signalling is going on, by 688 looking up the cross-connection table in Data Plane at each node 689 along the LSP path. 691 Starting from the information available at ingress LER about the 692 outgoing interface ID of that ingress node, the incoming interface ID 693 of next hop can be found by looking up the link resource table/ 694 database in the LER itself. Following the similarity existing 695 between the MP to CP handover procedure and the Restart Procedure, 696 the Recovery Label Object MUST be used to carry the downstream label 697 and the Upstream Label Object MUST be used to carry the upstream 698 label to the next node. 700 The Path message is hence built with the Recovery Label Object 701 ([RFC3473]) and the Upstream Label Object ([RFC3473]), where the 702 upstream label and downstream label of ingress outgoing interface of 703 the LSP are included in these two objects. In addition to above 704 mentioned objects, the Path message MUST include the Administrative 705 Status Object with HANDOVER flag set, as already defined in previous 706 chapter for the detailed ERO based way of proceeding. Such handover 707 Path is sent to the incoming interface of next hop. When this Path 708 message reaches the second node along the LSP path, the information 709 about incoming interface ID and the upstream and downstream labels of 710 this interface is extracted from it and it is used to find next hop 711 outgoing interface ID and the upstream/downstream labels by looking 712 up the Data Plane cross-connection table. 714 After having determined in this way the parameters describing the 715 LSPs next hop, the outgoing Path message to be sent is built 716 replacing the Recovery Label Object and Upstream Label Object content 717 with the looked-up values of upstream and downstream labels. 719 Re-iterating this procedure for each transit node along the LSP path, 720 it is possible to make the handover Path message reach the egress 721 node, exactly following the LSP that is in place over Data Plane. 722 The ERO MAY in this case be included in the Path message as an 723 optional object, and MAY be filled with the LSP relevant information 724 down to either the port level with interface ID or the Label level 725 with upstream and downstream labels. The ERO can be used to check 726 the consistence of resource in Data Plane down to the port level or 727 label level at each intermediate node along the LSP path. 729 9. RSVP Message Formats 731 This memo does not introduce any modification in RSVP messages object 732 composition. 734 10. Objects Modification 736 The modifications required concern two RSVP Objects: the 737 Administrative Status and the Error Spec Object. 739 10.1. Administrative Status Object 741 This memo introduces a new flag into the Administrative Status 742 object. The Admin_Status Object is defined in [RFC3473]. This 743 document uses the H-bit of the Admin_Status object. The bit is bit 744 number (TBD by IANA). The format of the Admin_Status Object is: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Length | Class-Num(196)| C-Type (1) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |R| Reserved |H|L|I|C|T|A|D| 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 The different flags are defined as follows: 756 - Reflect (R): 1 bit - Defined in [RFC3471] 757 When set, indicates that the edge node SHOULD reflect the object/ 758 TLV back in the appropriate message. 760 - Handover (H): 1bit 761 When set, the H bit indicates that a Handover procedure for the 762 transfer of LSP ownership between Management and Control Planes is 763 ongoing. 765 - Lockout (L): 1 bit - Defined in [RFC4872] 766 When set, forces the recovery LSP to be temporarily unavailable to 767 transport traffic (either normal or extra traffic). 769 - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783] 770 When set, indicates that alarm communication is disabled for the 771 LSP and that nodes SHOULD NOT add local alarm information. 773 - Call Control (C): 1 bit - Defined in 774 draft-ietf-ccamp-gmpls-rsvp-te-call-04 [2] 775 This bit is set when the message is being used to control and 776 manage a Call. 778 - Testing (T): 1 bit - Defined in [RFC3471] 779 When set, indicates that the local actions related to the 780 "testing" mode should be taken. 782 - Administratively down (A): 1 bit - Defined in [RFC3471] 783 When set, indicates that the local actions related to the 784 "administratively down" state should be taken. 786 - Deletion in progress (D): 1 bit - Defined in [RFC3471] 787 When set, indicates that that the local actions related to LSP 788 teardown should be taken. 790 The H bit must be used in conjunction with the R flag when is set in 791 the Path message. This will assures that the Resv message will 792 maintain the H flag set. 794 10.2. Error Spec Object 796 It is possible that a failure, such as the lost of DCN connection or 797 the restart of a node, occurs during the LSP ownership handing over. 798 In this case the LSP adoption MUST be interrupted and the ownership 799 of the LSP MUST be moved back to the Plane it belonged to. It is 800 important that the transaction failure MUST not affect the Data 801 Plane. The LSP MUST be kept in place and no traffic hit MUST occur. 803 The failure is signaled by Path Error in the upstream direction and 804 Path Tear Messages in the downstream direction. The Path Error 805 messages include an Error_Spec_Object (the Path_State_Removed flag 806 SHOUL always be set) specifying the causes of the failure, while the 807 Path Tear messages, required in case of reliable recovery and 808 optional otherwise, include the handover flag to prevent the deletion 809 of the LSP from the Data Plane. 811 This memo introduces a new Flag and a new Error Code (with different 812 Error Values) into the Error_Spec Object, defined in [RFC2205]. 814 * ERROR_SPEC class = 6. 815 * IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 817 +-------------+-------------+-------------+-------------+ 818 | IPv4 Error Node Address (4 bytes) | 819 +-------------+-------------+-------------+-------------+ 820 | Flags | Error Code | Error Value | 821 +-------------+-------------+-------------+-------------+ 823 The fields of the object are defined as follows: 825 - Error Node Address 826 The IP address of the node in which the error was detected. 827 - Error Code 828 A one-octet error description. 829 - Error Value 830 A two-octet field containing additional information about the 831 error. Its contents depend upon the Error Type 832 - Flags 833 Flags assigned values: 835 * 0x01 = InPlace 837 * 0x02 = NotGuilty 838 Proposed new value (TBD) = HandOverFailure 840 The new flag is "Handover Procedure Failure" and the actual value is 841 (TBD by IANA). When this flag is set during an handover from 842 Management Plane to Control Plane, the receiver must delete the 843 Control Plane status associated with the LSP and move the ownership 844 of the cross-connections back to the Management Plane. 846 The proposed Error Code is "Handover Procedure Failure", and its 847 value is (TBD by IANA)(33). For this Error Code the following Error 848 Values are defined: 850 1 = Cross-connection mismatch 852 2 = DCN error 854 11. Acknoledgments 856 We wish to thank Adrian Farrel for his editorial assistance and 857 precious advices to prepare this draft for publication. We also wish 858 to thank Nicola Ciulli, that contributed to initial stage of this 859 draft. 861 12. Contributors 862 Shan Zhu 863 Fujitsu Network Communications Inc. 864 2801 Telecom Parkway, 865 Richardson, Texas 75082 866 USA 867 Email: Shan.Zhu@us.fujitsu.com 868 Tel: +1-972-479-2041 870 Igor Bryskin 871 ADVA Optical Networking Inc 872 7926 Jones Branch Drive 873 Suite 615 874 McLean, VA - 22102 875 Email: ibryskin@advaoptical.com 877 13. Security Considerations 879 The procedures described in this document rely completely on RSVP-TE 880 messages and mechanism. The use of Handover Flag set in Admin Status 881 Object basically informs the receiving entity that no operations are 882 to be done over Data Plane as consequence of such special signaling 883 flow. Using specially flagged signaling messages we want to limit 884 the function of setup and tear down messages to Control Plane, making 885 them not effective over related Data Plane resource usage. So, no 886 additional or special issues are arisen by adopting this procedure, 887 that aren't already brought up by the use of the same messages, 888 without handover flag setting, for LSP control. For RSVP-TE Security 889 please refer to [RFC3473]. 891 14. IANA Considerations 893 IANA has been asked to manage the bit allocations for the 894 Administrative Status object ([RFC3473]). This document requires the 895 allocation of the Handover bit: the H-bit. IANA is requested to 896 allocate a bit for this purpose. 898 15. References 900 15.1. Normative References 902 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 903 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 904 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 906 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 907 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 908 Functional Specification", RFC 2205, September 1997. 910 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 911 and S. Molendini, "RSVP Refresh Overhead Reduction 912 Extensions", RFC 2961, April 2001. 914 15.2. Informational References 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 920 Protocol Label Switching (GMPLS) Extensions for 921 Synchronous Optical Network (SONET) and Synchronous 922 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 924 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 925 (GMPLS) Signaling Functional Description", RFC 3471, 926 January 2003. 928 [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE 929 Extensions in Support of End-to-End Generalized Multi- 930 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 931 May 2007. 933 [RFC4783] Berger, L., "GMPLS - Communication of Alarm Information", 934 RFC 4783, December 2006. 936 URIs 938 [1] 940 [2] 943 Authors' Addresses 945 Diego Caviglia 946 Ericsson 947 Via A. Negrone 1/A 948 Genova - Sestri Ponente 949 Italy 951 Email: diego.caviglia@ericsson.com 952 Daniele Ceccarelli 953 Ericsson 954 Via A. Negrone 1/A 955 Genova - Sestri Ponente 956 Italy 958 Email: daniele.ceccarelli@ericsson.com 960 Dino Bramanti 961 Ericsson 962 Via Moruzzi 1 C/O Area Ricerca CNR 963 Pisa 964 Italy 966 Email: dino.bramanti@ericsson.com 968 Dan Li 969 Huawei Technologies Co., LTD. 970 Shenzhen 518129 971 Huawei Base, Bantian, Longgang 972 Italy 974 Email: dan.li@huawei.com 976 Snigdho Bardalai 977 Fujitsu Network Communications Inc 978 2801 Telecom Parkway 979 Richrdson, Texas 75082 980 USA 982 Email: Snigdho.Bardalai@us.fujitsu.com 984 Full Copyright Statement 986 Copyright (C) The IETF Trust (2008). 988 This document is subject to the rights, licenses and restrictions 989 contained in BCP 78, and except as set forth therein, the authors 990 retain all their rights. 992 This document and the information contained herein are provided on an 993 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 994 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 995 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 996 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 997 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 998 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1000 Intellectual Property 1002 The IETF takes no position regarding the validity or scope of any 1003 Intellectual Property Rights or other rights that might be claimed to 1004 pertain to the implementation or use of the technology described in 1005 this document or the extent to which any license under such rights 1006 might or might not be available; nor does it represent that it has 1007 made any independent effort to identify any such rights. Information 1008 on the procedures with respect to rights in RFC documents can be 1009 found in BCP 78 and BCP 79. 1011 Copies of IPR disclosures made to the IETF Secretariat and any 1012 assurances of licenses to be made available, or the result of an 1013 attempt made to obtain a general license or permission for the use of 1014 such proprietary rights by implementers or users of this 1015 specification can be obtained from the IETF on-line IPR repository at 1016 http://www.ietf.org/ipr. 1018 The IETF invites any interested party to bring to its attention any 1019 copyrights, patents or patent applications, or other proprietary 1020 rights that may cover technology that may be required to implement 1021 this standard. Please address the information to the IETF at 1022 ietf-ipr@ietf.org.