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