idnits 2.17.1 draft-ietf-ccamp-pc-and-sc-reqs-04.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 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2008) is 5818 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Diego Caviglia 3 Internet Draft Dino Bramanti 4 Ericsson 5 Dan Li 6 Huawei 7 Dave McDysan 8 Verizon 10 Intended Status: Informational 11 Expires: November, 19 2008 May 19, 2008 13 Requirements for the Conversion Between Permanent Connections and 14 Switched Connections in a Generalized Multiprotocol Label Switching 15 (GMPLS) Network 17 draft-ietf-ccamp-pc-and-sc-reqs-04.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that 22 any applicable patent or other IPR claims of which he or she is 23 aware have been or will be disclosed, and any of which he or she 24 becomes aware will be disclosed, in accordance with Section 6 of 25 BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on November 19, 2008. 45 Abstract 47 From a Carrier perspective, the possibility of turning a Permanent 48 Connection (PC) into a Soft Permanent Connection (SPC) and vice 49 versa, without actually affecting Data Plane traffic being carried 50 over it, is a valuable option. In other terms, such operation can 51 be seen as a way of transferring the ownership and control of an 52 existing and in-use Data Plane connection between the Management 53 Plane and the Control Plane, leaving its Data Plane state untouched. 55 This memo sets out the requirements for such procedures within a 56 Generalized Multiprotocol Label Switching (GMPLS) network. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC-2119 [RFC2119]. 64 Table of Contents 66 1. Introduction..................................................3 67 2. Motivation....................................................3 68 3. Label Switched Path Terminology...............................4 69 4. LSP within GMPLS Control Plane................................4 70 4.1. Resource Ownership.......................................4 71 4.2. Setting Up a GMPLS Controlled Network....................5 72 5. Typical Use Cases.............................................6 73 5.1. PC to SC/SPC Conversion..................................6 74 5.2. SC to PC Conversion......................................7 75 6. Requirements..................................................7 76 6.1. Data Plane LSP Consistency...............................7 77 6.2. No Disruption of User Traffic............................7 78 6.3. Transfer from Management Plane to Control Plane..........7 79 6.4. Transfer from Control Plane to Management Plane..........7 80 6.5. Synchronization of state among nodes during conversion...8 81 6.6. Support of Soft Permanent Connections....................8 82 6.7. Failure of Transfer......................................8 83 7. Security Considerations.......................................8 84 8. IANA Considerations...........................................9 85 9. References....................................................9 86 9.1. Normative References.....................................9 87 9.2. Informative References...................................9 88 10. Acknowledgments..............................................9 89 11. Authors' Addresses...........................................9 90 12. Full Copyright Statement....................................10 91 13. Intellectual Property Statement.............................11 93 1. Introduction 95 In a typical, traditional transport network scenario, Data Plane 96 connections between two end-points are controlled by means of a 97 Network Management System (NMS) operating within the Management Plane 98 (MP). The NMS/MP is the owner of such transport connections, being 99 responsible of their setup, teardown, and maintenance. Provisioned 100 connections of this kind, initiated and managed by the Management 101 Plane, are known as Permanent Connections (PCs) [G.8081]. 103 When the setup, teardown, and maintenance of connections are achieved 104 by means of a signaling protocol owned by the Control Plane such 105 connections are known as Switched Connections (SCs) [G.8081]. 107 In many deployments a hybrid connection type will be used. A Soft 108 Permanent Connection (SPC) is a combination of a permanent connection 109 segment at the source user-to-network side, a permanent connection 110 segment at the destination user-to-network side, and a switched 111 connection segment within the core network. The permanent parts of 112 the SPC are owned by the Management Plane, and the switched parts are 113 owned by the Control Plane [G.8081]. 115 At least some aspects of a control plane initiated connection must be 116 capable of being queried by the Management Plane. These aspects 117 should be independent of how the connection was established. 119 2. Motivation 121 The main motivation for this work is the LSP conversion from 122 Management Plane PC to Control Plane SC. The objective is to be able 123 to introduce a control plane into an existing network without 124 disrupting user traffic. An example of this is an operator 125 establishing PCs before the SC technology is mature, or before SC 126 interoperation is achieved between multiple implementations. 128 Conversion from the Management Plane to Control Plane is stated as 129 a mandatory requirement while the conversion from the Control Plane 130 to Management is a desirable feature, or desirable, feature. The 131 requirement for LSP conversion from Control Plane to Management Plane 132 is scoped as a back-out procedure. 134 A significant benefit of GMPLS in networks is discovering and 135 validating the current state of the network. For example, an operator 136 could invoke an SC, determine that the automatically discovered path 137 is good and then "pin" a connection to this specific path using the 138 SC to PC conversion procedures. This is attractive to network 139 operators who prefer the static nature of the path for a PC as 140 compared with the potentially dynamic path of an SC. 142 3. Label Switched Path Terminology 144 A Label Switched Path (LSP) has different semantics depending on the 145 plane in which it the term is used. 147 In the Data Plane, an LSP indicates the Data Plane forwarding path. 148 It defines the forwarding or switching operations at each network 149 entity. It is the sequence of Data Plane resources (links, labels, 150 cross-connects) that achieves end-to-end data transport. 152 In the Management Plane, an LSP is the management state information 153 (such as the connection attributes and path information) associated 154 with and necessary for the creation and maintenance of a Data Plane 155 connection. 157 In the Control Plane, an LSP is the Control Plane state information 158 (such as RSVP-TE [RFC3473] Path and Resv state) associated with and 159 necessary for the creation and maintenance of a Data Plane 160 connection. 162 A Permanent Connection has an LSP presence in the Data Plane and the 163 Management Plane. A Switched Connection has an LSP presence in the 164 Data Plane and the Control Plane. An SPC has LSP presence in the Data 165 Plane for its entire length, but has Management Plane presence for 166 part of its length and Control Plane presence for part of its length. 168 In this document, when we talk about the LSP conversion between 169 Management Plane and Control Plane, we mainly focus on the conversion 170 of Control Plane state information and Management Plane state 171 information. 173 4. LSP within GMPLS Control Plane 175 Generalized Multiprotocol Label Switching (GMPLS) [RFC3471], 176 [RFC3473], [RFC3945] defines a powerful Control Plane architecture 177 for transport networks. This includes both routing and signaling 178 protocols for the creation and maintenance of Label Switched Paths 179 (LSPs) in networks whose Data Plane is based on different 180 technologies such as TDM (SDH/SONET G.709 at ODUk level) transport 181 and WDM (G.709 OCh level). 183 4.1. Resource Ownership 185 A resource used by an LSP is said to be 'owned' by the plane that was 186 used to set up the LSP through that part of the network. Thus, all 187 the resources used by a Permanent Connection are owned by the 188 Management Plane, and all the resources used by a Switched Connection 189 are owned by the Control Plane. The resources used by an SPC are 190 divided between the Management Plane (for the resources used by the 191 permanent connection segments at the edge of the network) and the 192 Control Plane (for the resources used by the switched segment in the 193 middle of the network). 195 The division of resources available for ownership by the Management 196 and Control Planes is an architectural issue. A carrier may decide to 197 pre-partition the resources at a network entity so that LSPs under 198 Management Plane control use one set of resources and LSPs under 199 Control Plane control use another set of resources. Other carriers 200 may choose to make this distinction resource-by-resource as LSPs are 201 established. 203 It should be noted, however, that even when a resource is owned by 204 the Control Plane it will usually be the case that the Management 205 Plane has a controlling interest in the resource. Consider e.g. the 206 basic safety requirements that imply that management commands must be 207 available to set laser out of service. 209 4.2. Setting Up a GMPLS Controlled Network 211 The implementation of a new network using a Generalized Multiprotocol 212 Label Switching (GMPLS) Control Plane may be considered as a green 213 field deployment. But in many cases it is desirable to introduce a 214 GMPLS Control Plane into an existing transport network that is 215 already populated with permanent connections under Management Plane 216 control. 218 In a mixed scenario, Permanent Connections owned by the Management 219 Plane and Switched Connections owned by the Control Plane have to 220 coexist within the network. 222 It is also desirable to transfer the control of connections from the 223 Management Plane to the Control Plane so that connections that were 224 originally under the control of an NMS are now under the control of 225 the GMPLS protocols. In case such connections are in service, such 226 conversion must be performed in a way that does not affect traffic. 228 Since attempts to move a LSP under GMPLS control might fail due to a 229 number of reasons outside the scope of this draft, it is also highly 230 desirable to have a mechanism to convert the control of an LSP back 231 to the Management Plane, in fact undoing the whole process for 232 reasons summarized in the motivation section. 234 Note that a Permanent Connection may be converted to a Switched 235 Connection or to an SPC, and an SPC may be converted to a Switched 236 Connection as well (PC to SC, PC to SPC, and SPC to SC). So the 237 reverse mappings may be also needed (SC to PC, SC to SPC, and SPC to 238 PC). 240 Conversion to/from control/management will occur in many MIBs or 241 network management data structures where the owner of the hop level 242 information (e.g., cross-connect, label assignment, label stacking, 243 etc.) is identified as either a specific control protocol, or manual 244 (i.e., NMS). When converting, this hop-level owner information needs 245 to be completed for all hops. If conversion cannot be done for all 246 hops, then the conversion must be done for no hops and the state of 247 the hop level information restored to that before the conversion was 248 attempted, and an error condition reported to the management system. 250 In either case of conversion, the Management Plane shall initiate the 251 change. When converting from a PC to an SC, the management system 252 must somehow indicate to each hop that a control protocol is now to 253 be used, and then configure the data needed by control protocol at 254 the connection endpoints. When converting from an SC to a PC, the 255 Management Plane must change the owner of each hop. Somehow, then the 256 instance in the Control Plane must be removed without affecting the 257 Data Plane. 259 The case where the CP and/or MP fail at one or more nodes during the 260 conversion procedure must be handled in the solution. If the network 261 is viewed as the database of record (including data, control and 262 Management Plane elements), then a solution that has procedures 263 similar to those of a two-phase database commit process may be needed 264 to ensure integrity and support the need to revert to the state prior 265 to the conversion attempt if there is a CP and/or MP failure during 266 the attempted conversion. 268 5. Typical Use Cases 270 5.1. PC to SC/SPC Conversion 272 A typical scenario where a PC to SC (or SPC) procedure can be a 273 useful option is at the initial stage of Control Plane deployment in 274 an existing network. In such a case all the network connections, 275 possibly carrying traffic, are already set up as PCs and are owned by 276 the Management Plane. 278 The next step in this conversion process presents a similar scenario 279 where the network is partially controlled by the Management Plane and 280 partially controlled by the Control Plane (PCs and SCs/SPCs coexist). 282 In this case an upgrade of the Control Plane functionalities, such as 283 new signaling extensions, may be required. 285 In both cases the point is that a connection, set up and owned by 286 the Management Plane, may need to be transferred to Control Plane 287 control. If a connection is carrying traffic, its transfer has to be 288 done without any disruption to the Data Plane traffic. 290 5.2. SC to PC Conversion 292 The main reason making a SC to PC conversion interesting is to give 293 an operator the chance of undoing somehow the action represented by 294 the above introduced PC to SC conversion. 296 In other words the SC to PC conversion is a back-out procedure and as 297 such is not specified as mandatory in this document, but is still a 298 highly desirable function. 300 Again it is worth stressing the requirement that such 'SPC to PC' 301 conversion is achieved without any effect on the associated Data 302 Plane state so that the connection continues to be operational and to 303 carry traffic during the transition. 305 6. Requirements 307 This section sets out the basic requirements for procedures and 308 processes that are used to perform the functions this document is 309 about. Notation form [RFC2119] is used to clarify the level of each 310 requirement. 312 6.1. Data Plane LSP Consistency 314 The Data Plane LSP, staying in place throughout the whole transfer 315 process, MUST follow the same path through the network and MUST use 316 the same network resources. 318 6.2. No Disruption of User Traffic 320 The transfer process MUST NOT cause any disruption of user traffic 321 flowing over the LSP whose control is being transferred or any other 322 LSP in the network. 324 SC to PC conversion and vice-versa SHALL occur without generating 325 Management Plane alarms toward the end users at neither the UNI 326 endpoints nor the NMS. 328 6.3. Transfer from Management Plane to Control Plane 330 It MUST be possible to transfer the ownership of an LSP from the 331 Management Plane to the Control Plane 333 6.4. Transfer from Control Plane to Management Plane 335 It SHOULD be possible to transfer the ownership of an LSP from the 336 Control Plane to the Management Plane. 338 6.5. Synchronization of State Among Nodes During Conversion 340 It MUST be assured that the state of the LSP is synchronized among 341 all nodes traversed by it before the conversion in considered 342 complete. 344 6.6. Support of Soft Permanent Connections 346 It MUST be possible to segment an LSP such that it is converted to or 347 from an SPC. 349 6.7. Failure of Transfer 351 It MUST be possible for a transfer from one plane to the other to 352 fail in a non-destructive way leaving the ownership unchanged and 353 without impacting traffic. 355 If during the transfer procedure some issues arise causing an 356 unsuccessful or incomplete, unexpected result it MUST be assured that 357 at the end: 359 1. Traffic over Data Plane is not affected 361 2. The LSP status is consistent in all the Transport Network Elements 362 (TNEs) involved in the procedure 364 Point 2 above assures that, even in case of some failure during the 365 transfer, the state of the affected LSP is brought back to the 366 initial one and it is fully under control of the owning entity. 368 7. Security Considerations 370 Allowing control of an LSP to be taken away from a plane introduces 371 another way in which services may be disrupted by malicious 372 intervention. 374 It is expected that any solution to the requirements in this document 375 will utilize the security mechanisms inherent in the Management Plane 376 and Control Plane protocols, and no new security mechanisms are 377 needed if these tools are correctly used. 379 If SNMP MIBs are used for configuration, then the Management Plane 380 should support at least authentication for PC<>SC configuration 381 changes as specified in [RFC3414]. 383 Note also that implementations may enable policy components to help 384 determine whether individual LSPs may be transferred between planes. 386 8. IANA Considerations 388 This requirement document makes no requests for IANA action. 390 9. References 392 9.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC2119, March 1997 397 [G.8081] ITU-T, "Terms and definitions for Automatically Switched 398 Optical Networks (ASON)," Recommendation G.8081/Y.1353, 399 June 2004 401 [RFC3414] U. Blumenthal, B. Wijnen, "User-based Security Model(USM) 402 for version 3 of the Simple Network Management Protocol 403 (SNMPv3)," RFC 3414, December 2002 405 9.2. Informative References 407 [RFC3471] L. Berger (Ed.) "Generalized Multi-Protocol Label 408 Switching (GMPLS) Signaling Functional Description", RFC 409 3471, January 2003 411 [RFC3473] L. Berger (Ed.) "Generalized Multi-Protocol Label 412 Switching (GMPLS) Signaling Resource ReserVation 413 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 414 3473, January 2003 416 [RFC3945] E. Mannie (Ed.) "Generalized Multi-Protocol Label 417 Switching (GMPLS) Architecture", RFC 3945, October 2004 419 10. Acknowledgments 421 We whish to thank the following people (listed randomly) Adrian 422 Farrel for his editorial assistance to prepare this draft for 423 publication, Dean Cheng and Julien Meuric, Dimitri Papadimitriou, 424 Deborah Brungard, Igor Bryskin, Lou Berger, Don Fedyk, John Drake and 425 Vijay Pandian for their suggestions and comments on the CCAMP list. 427 11. Authors' Addresses 429 Diego Caviglia 430 Ericsson 431 Via A. Negrone 1/A 432 Genova-Sestri Ponente, Italy 434 Phone: +390106003738 435 Email: diego.caviglia@ericsson.com 436 Dino Bramanti 437 Ericsson 438 Via Moruzzi 1 439 C/O Area Ricerca CNR 440 Pisa, Italy 442 Email: dino.bramanti@ericsson.com 444 Nicola Ciulli 445 NextWorks 446 Corso Italia 116 447 56125 Pisa, Italy 449 Email: n.ciulli@nextworks.it 451 Dan Li 452 Huawei Technologies Co., LTD. 453 Huawei Base, Bantian, Longgang, 454 Shenzhen 518129 P.R.Chin 456 Phone: +86-755-28972910 457 Email: danli@huawei.com 459 Han Li 460 China Mobile Communications Co. 461 53A Xibianmennei Ave. Xuanwu District 462 Beijing 100053 P.R. China 464 Phone: +86-10-66006688 ext.3092 465 Email: lihan@chinamobile.com 467 Dave McDysan 468 Verizon 469 Ashburn, VA, USA 471 Email: dave.mcdysan@verizon.com 473 12. Full Copyright Statement 475 Copyright (C) The IETF Trust (2008). 477 This document is subject to the rights, licenses and restrictions 478 contained in BCP 78, and except as set forth therein, the authors 479 retain all their rights. 481 This document and the information contained herein are provided on 482 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 483 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 484 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 485 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 486 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 487 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 488 FOR A PARTICULAR PURPOSE. 490 13. Intellectual Property 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org.