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