idnits 2.17.1 draft-caviglia-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. 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 RFC 3978 Section 5.4 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 (September 2006) is 6433 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-caviglia-ccamp-pc-and-sc-reqs-04.txt September 2006 3 Network Working Group 4 Internet Draft Diego Caviglia 5 Intended Status: Informational Dino Bramanti 6 Ericsson 7 Dan Li 8 Document: Huawei 9 draft-caviglia-ccamp-pc-and-sc-reqs-04.txt 11 Expires: March 2007 13 Requirements for the Conversion Between Permanent Connections and 14 Switched Connections in a Generalized Multiprotocol Label Switching 15 (GMPLS) Network 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 30 months and may be updated, replaced, or obsoleted by other documents 31 at any 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/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 From a Carrier perspective, the possibility of turning a Permanent 43 Connection (PC) into a Soft Permanent Connection (SPC) and vice 44 versa, without actually affecting Data Plane traffic being carried 45 over it, is a valuable option. In other terms, such operation can be 46 seen as a way of transferring the ownership and control of an 47 existing and in-use Data Plane connection between the Management 48 Plane and the Control Plane, leaving its Data Plane state untouched. 50 This memo sets out the requirements for such procedures within a 51 Generalized Multiprotocol Label Switching (GMPLS) network. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC-2119 [1]. 59 Table of Contents 61 1 Introduction...................................................3 62 1.1 Motivation..................................................3 63 1.2 Label Switched Path Terminology.............................3 64 1.3 LSP within GMPLS Control Plane..............................4 65 1.4 Resource Ownership..........................................4 66 1.5 Setting Up a GMPLS Controlled Network.......................5 67 2 Typical Use Cases..............................................5 68 2.1 PC to SC/SPC Conversion.....................................5 69 2.2 SC to PC Conversion.........................................6 70 3 Requirements...................................................6 71 3.1 Data Plane LSP Consistency..................................6 72 3.2 No Disruption of User Traffic...............................6 73 3.3 Transfer from Management Plane to Control Plane.............6 74 3.4 Transfer from Control Plane to Management Plane.............6 75 3.5 Synchronization of state among nodes during conversion......7 76 3.6 Support of Soft Permanent Connections.......................7 77 3.7 Failure of Transfer.........................................7 78 4 Security Considerations........................................7 79 5 IANA Consideration.............................................7 80 6 References.....................................................8 81 6.1 Normative References........................................8 82 6.2 Informative References......................................8 83 7 Acknowledgments................................................8 85 1 Introduction 87 In a typical, traditional transport network scenario, Data Plane 88 connections between two endpoints are controlled by means of a 89 Network Management System (NMS) operating within the Management 90 Plane (MP). The NMS/MP is the owner of such transport connections, 91 being responsible of their setup, teardown, and maintenance. 92 Provisioned connections of this kind, initiated and managed by the 93 Management Plane, are known as Permanent Connections (PCs). 95 When the setup, teardown, and maintenance of connections is achieved 96 by means of a signaling protocol owned by the Control Plane such 97 connections are known as Switched Connections (SCs). 99 In many deployments a hybrid connection type will be used. A Soft 100 Permanent Connection (SPC) is a combination of a permanent 101 connection segment at the source user-to-network side, a permanent 102 connection segment at the destination user-to-network side, and a 103 switched connection segment within the core network. The permanent 104 parts of the SPC are owned by the Management Plane, and the switched 105 parts are owned by the Control Plane. 107 1.1 Motivation 109 The main motivation for this work is the LSP conversion from 110 Management Plane to Control Plane. The objective is to be able to 111 introduce a control plane into an existing network without 112 disrupting user traffic. 113 Conversion from the Management Plane to Control Plane is proposed as 114 a mandatory requirement while the conversion from the Control Plane 115 to Management is seen as a nice to have feature. The requirement for 116 LSP conversion from Control Plane to Management Plane should be 117 scoped as a back-out procedure. 119 1.2 Label Switched Path Terminology 121 A Label Switched Path (LSP) has different semantics depending on the 122 plane in which it the term is used. 124 In the Data Plane, an LSP indicates the Data Plane forwarding path. 125 It defines the forwarding or switching operations at each network 126 entity. It is the sequence of data plane resources (links, labels, 127 cross-connects) that achieves end-to-end data transport. 129 In the Management Plane, an LSP is the management state information 130 (such as the connection attributes and path information)associated 131 with and necessary for the creation and maintenance of a Data Plane 132 connection. 134 In the Control Plane, an LSP is the control plane state information 135 (such as Path and Resv state)associated with and necessary for the 136 creation and maintenance of a Data Plane connection. 138 A permanent connection has an LSP presence in the Data Plane and the 139 Management Plane. A switched connection has an LSP presence in the 140 Data Plane and the Control Plane. An SPC has LSP presence in the 141 Data Plane for its entire length, but has Management Plane presence 142 for part of its length and Control Plane presence for part of its 143 length. 144 In this document, when we talk about the LSP conversion between 145 Control plane and Management plane, we mainly focus on the 146 conversion of control plane state information and management state 147 information. 149 1.3 LSP within GMPLS Control Plane 151 Generalized Multiprotocol Label Switching (GMPLS)[2], [3] defines a 152 powerful Control Plane architecture for transport networks. This 153 includes both routing and signaling protocols for the creation and 154 maintenance of Label Switched Paths (LSPs) in networks whose Data 155 Plane is based on different technologies such as optical TDM 156 transport ad WDM. 158 1.4 Resource Ownership 160 A resource used by an LSP is said to be 'owned' by the plane that 161 was used to set up the LSP through that part of the network. Thus, 162 all the resources used by a permanent connection are owned by the 163 Management Plane, and all the resources used by a switched 164 connection are owned by the Control Plane. The resources used by an 165 SPC are divided between the Management Plane (for the resources used 166 by the permanent connection segments at the edge of the network) and 167 the Control Plane (for the resources used by the switched segment in 168 the middle of the network). 170 The division of resources available for ownership by the Management 171 and Control Planes is an architectural issue. A carrier may decide 172 to pre-partition the resources at a network entity so that LSPs 173 under Management Plane control use one set of resources and LSPs 174 under Control Plane control use another set of resources. Other 175 carriers may choose to make this distinction resource-by-resource as 176 LSPs are established. 178 It should be noted, however, that even when a resource is owned by 179 the Control Plane it will usually be the case that the Management 180 Plane has a controlling interest in the resource. Consider, for 181 example, that in the event of a Control Plane failure, the 182 Management Plane needs to be able to de-provision resources. Also 183 consider the basic safety requirements that imply that management 184 commands must be available to set laser out of service. 186 1.5 Setting Up a GMPLS Controlled Network 188 The implementation of a new network using a Generalized 189 Multiprotocol Label Switching (GMPLS) Control Plane may be 190 considered as a green field deployment. But in many cases it is 191 desirable to introduce a GMPLS Control Plane into an existing 192 transport network that is already populated with permanent 193 connections under Management Plane control. 195 In a mixed scenario, permanent connections owned by the Management 196 Plane and switched connections owned by the Control Plane have to 197 coexist within the network. 199 It is also desirable to transfer the control of connections from the 200 Management Plane to the Control Plane so that connections that were 201 originally under the control of an NMS are now under the control of 202 the GMPLS protocols. In case such connections are in service, such 203 conversion must be performed in a way that does not affect traffic. 205 Since attempts to move a LSP under GMPLS control might fail due to a 206 number of reasons outside the scope of this draft, it is also 207 advisable to have a mechanism to convert the control of an LSP back 208 to the Management Plane, in fact undoing the whole process. 210 Note that a permanent connection may be converted to a switched 211 connection or to an SPC, and an SPC may be converted to a switched 212 connection as well(PC to SC, PC to SPC, and SPC to SC). So the 213 reverse mappings may be also needed (SC to PC, SC to SPC, and SPC to 214 PC). 216 2 Typical Use Cases 218 2.1 PC to SC/SPC Conversion 220 A typical scenario where a PC to SC (or SPC) procedure can be a 221 useful option is at the initial stage of Control Plane deployment in 222 an existing network. In such a case all the network connections, 223 possibly carrying traffic, are already set up as PCs and are owned 224 by the Management Plane. 226 Next step in such conversion process presents a similar scenario 227 where the network is partially controlled by the Management Plane 228 and partially controlled by the Control Plane (PCs and SCs/SPCs 229 coexist). In this case a network upgrade by a Control Plane coverage 230 extension may be required. 232 In both cases the point is that a connection, set up and owned by 233 the Management Plane, may need to be transferred to Control Plane 234 control. If a connection is carrying traffic, its transfer has to be 235 done without any disruption to the Data Plane traffic. 237 2.2 SC to PC Conversion 239 The main reason making a SC to PC conversion interesting is to give 240 an operator the chance of undoing somehow the action represented by 241 the above introduced PC to SC conversion. 243 In other words the SC to PC conversion is a back-out procedure and 244 as such is not considered mandatory in this document, still being a 245 useful functional resource. 247 Again it is worth stressing the requirement that such `SPC to PC` 248 conversion is achieved without any effect on the associated Data 249 Plane state so that the connection continues to be operational and 250 to carry traffic during the transition. 252 3 Requirements 254 This section sets out the basic requirements for procedures and 255 processes that are used to perform the functions this document is 256 about. 258 3.1 Data Plane LSP Consistency 260 The Data Plane LSP, staying in place throughout the whole transfer 261 process, MUST follow the same path through the network and MUST use 262 the same network resources. 264 3.2 No Disruption of User Traffic 266 The transfer process MUST NOT cause any disruption of user traffic 267 flowing over the LSP whose control is being transferred or any other 268 LSP in the network. 270 3.3 Transfer from Management Plane to Control Plane 272 It MUST be possible to transfer the ownership of an LSP from the 273 Management Plane to the Control Plane 275 3.4 Transfer from Control Plane to Management Plane 276 It SHOULD be possible to transfer the ownership of an LSP from the 277 Control Plane to the Management Plane. 279 3.5 Synchronization of state among nodes during conversion 281 It MUST be assured that the state of the LSP is synchronized among 282 all nodes traversed by it before proceeding to the conversion. 284 3.6 Support of Soft Permanent Connections 286 It MUST be possible to segment an LSP such that it is converted to 287 or from an SPC. 289 3.7 Failure of Transfer 291 It MUST be possible for a transfer from one plane to the other to 292 fail in a non-destructive way leaving the ownership unchanged and 293 without impacting traffic. 295 If during the transfer procedure some issues arise causing an 296 unsuccessful or incomplete, unexpected result it MUST be assured 297 that at the end: 298 1) Traffic over Data Plane is not affected 299 2) The LSP status is consistent in all the TNEs involved in the 300 procedure 302 Point 2 above assures that, even in case of some failure during the 303 transfer, the state of the affected LSP is brought back to the 304 initial one and it is fully under control of the owning entity. 306 4 Security Considerations 308 Allowing control of an LSP to be taken away from a plane introduces 309 another way in which services may be disrupted by malicious 310 intervention. 312 It is expected that any solution to the requirements in this 313 document will utilize the security mechanisms inherent in the 314 Management Plane and Control Plane protocols, and no new security 315 mechanisms are needed if these tools are correctly used. 317 Note also that implementations may enable policy components to help 318 determine whether individual LSPs may be transferred between planes. 320 5 IANA Considerations 322 This requirement document makes no requests for IANA action. 324 6 References 326 6.1 Normative References 328 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 329 Levels", BCP 14, RFC 2119, March 1997 331 6.2 Informative References 333 [2] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching 334 (GMPLS) Signaling Functional Description", RFC 3471, January 2003 336 [3] L. Berger (Ed.) "Generalized Multi-Protocol Label Switching 337 (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering 338 (RSVP-TE) Extensions", RFC 3473, January 2003 340 7 Acknowledgments 342 We whish to thank the following people (listed randomly) Adrian 343 Farrel for his editorial assistance to prepare this draft for 344 publication, Dean Cheng and Julien Meuric, Dimitri Papadimitriou, 345 Deborah Brungard, Igor Bryskin, Lou Berger, Don Fedyk, John Drake 346 and Vijay Pandian for their suggestions and comments on the CCAMP 347 list. 349 8 Authors' Addresses 351 Diego Caviglia 352 Marconi 353 Via A. Negrone 1/A 354 Genova-Sestri Ponente, Italy 355 Phone: +390106003738 356 Email: diego.caviglia@marconi.com 358 Dino Bramanti 359 Marconi 360 Via Moruzzi 1 361 C/O Area Ricerca CNR 362 Pisa, Italy 363 Email: dino.bramanti@marconi.com 365 Nicola Ciulli 366 NextWorks 367 Corso Italia 116 368 56125 Pisa, Italy 369 Email: n.ciulli@nextworks.it 371 Dan Li 372 Huawei Technologies Co., LTD. 373 Huawei Base, Bantian, Longgang, 374 Shenzhen 518129 P.R.China 375 danli@huawei.com 376 Tel: +86-755-28972910 378 Han Li 379 China Mobile Communications Co. 380 53A Xibianmennei Ave. Xuanwu District 381 Beijing 100053 P.R. China 382 lihan@chinamobile.com 383 Tel: +86-10-66006688 ext. 3092 385 Intellectual Property Rights Notices 387 The IETF takes no position regarding the validity or scope of any 388 Intellectual Property Rights or other rights that might be claimed 389 to pertain to the implementation or use of the technology described 390 in this document or the extent to which any license under such 391 rights might or might not be available; nor does it represent that 392 it has made any independent effort to identify any such rights. 393 Information on the procedures with respect to rights in RFC 394 documents can be found in BCP 78 and BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the use 399 of such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR repository 401 at http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights that may cover technology that may be required to implement 406 this standard. Please address the information to the IETF at ietf- 407 ipr@ietf.org. 409 Full Copyright Statement 411 Copyright (C) The Internet Society (2006). This document is subject 412 to the rights, licenses and restrictions contained in BCP 78, and 413 except as set forth therein, the authors retain all their rights. 415 This document and the information contained herein are provided on 416 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 417 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 418 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 419 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 420 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 421 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 422 FOR A PARTICULAR PURPOSE.