idnits 2.17.1 draft-ietf-ccamp-pc-and-sc-reqs-06.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 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), 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 -- 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 15, 2008) is 5700 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. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Caviglia 3 Internet-Draft D. Bramanti 4 Intended status: Informational Ericsson 5 Expires: March 19, 2009 D. Li 6 Huawei Technologies Co., LTD. 7 D. McDysan 8 Verizon 9 September 15, 2008 11 Requirements for the Conversion Between Permanent Connections and 12 Switched Connections in a Generalized Multiprotocol Label Switching 13 (GMPLS) Network 15 draft-ietf-ccamp-pc-and-sc-reqs-06.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 March 15, 2009. 42 Abstract 44 From a Carrier perspective, the possibility of turning a Permanent 45 Connection (PC) into a Soft Permanent Connection (SPC) and vice 46 versa, without actually affecting Data Plane traffic being carried 47 over it, is a valuable option. In other terms, such operation can be 48 seen as a way of transferring the ownership and control of an 49 existing and in-use Data Plane connection between the Management 50 Plane and the Control Plane, leaving its Data Plane state untouched. 52 This memo sets out the requirements for such procedures within a 53 Generalized Multiprotocol Label Switching (GMPLS) network. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Label Switched Path Terminology . . . . . . . . . . . . . . . 3 65 3. LSP within GMPLS Control Plane . . . . . . . . . . . . . . . . 4 66 3.1. Resource Ownership . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Setting Up a GMPLS Controlled Network . . . . . . . . . . 5 68 4. Typical Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. PC to SC/SPC Conversion . . . . . . . . . . . . . . . . . 6 70 4.2. SC to PC Conversion . . . . . . . . . . . . . . . . . . . 6 71 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Data Plane LSP Consistency . . . . . . . . . . . . . . . . 7 73 5.2. No Disruption of User Traffic . . . . . . . . . . . . . . 7 74 5.3. Transfer from Management Plane to Control Plane . . . . . 7 75 5.4. Transfer from Control Plane to Management Plane . . . . . 7 76 5.5. Synchronization of State Among Nodes During Conversion . . 7 77 5.6. Support of Soft Permanent Connections . . . . . . . . . . 7 78 5.7. Failure of transfer . . . . . . . . . . . . . . . . . . . 7 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 85 10.2. Informational References . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 Intellectual Property and Copyright Statements . . . . . . . . . . 11 89 1. Introduction 91 In a typical, traditional transport network scenario, Data Plane 92 connections between two end-points are controlled by means of a 93 Network Management System (NMS) operating within the Management Plane 94 (MP). The NMS/MP is the owner of such transport connections, being 95 responsible of their setup, teardown, and maintenance. Provisioned 96 connections of this type, initiated and managed by the Management 97 Plane, are known as Permanent Connections (PCs) [G.8081]. 99 When the setup, teardown, and maintenance of connections are achieved 100 by means of a signaling protocol owned by the Control Plane, such 101 connections are known as Switched Connections (SCs) [G.8081]. 103 In many deployments, a hybrid connection type will be used. A Soft 104 Permanent Connection (SPC) is a combination of a permanent connection 105 segment at the source user-to-network side, a permanent connection 106 segment at the destination user-to-network side, and a switched 107 connection segment within the core network. The permanent parts of 108 the SPC are owned by the Management Plane, and the switched parts are 109 owned by the Control Plane [G.8081]. 111 Note, some aspects of a control plane initiated connection must be 112 capable of being queried/controlled by the Management Plane. These 113 aspects should be independent of how the connection was established. 115 2. Label Switched Path Terminology 117 A Label Switched Path (LSP) has different semantics depending on the 118 plane in which the term is used. 120 In the Data Plane, an LSP indicates the Data Plane forwarding path. 121 It defines the forwarding or switching operations at each network 122 entity. It is the sequence of Data Plane resources (links, labels, 123 cross-connects) that achieves end-to-end data transport. 125 In the Management Plane, an LSP is the management state information 126 (such as the connection attributes and path information) associated 127 with and necessary for the creation and maintenance of a Data Plane 128 connection. 130 In the Control Plane, an LSP is the Control Plane state information 131 (such as RSVP-TE [RFC3473] Path and Resv state) associated with and 132 necessary for the creation and maintenance of a Data Plane 133 connection. 135 A Permanent Connection has an LSP presence in the Data Plane and the 136 Management Plane. A Switched Connection has an LSP presence in the 137 Data Plane and the Control Plane. An SPC has LSP presence in the 138 Data Plane for its entire length, but has Management Plane presence 139 for part of its length and Control Plane presence for part of its 140 length. 142 In this document, when we discuss the LSP conversion between 143 Management Plane and Control Plane, we mainly focus on the conversion 144 of Control Plane state information and Management Plane state 145 information. 147 3. LSP within GMPLS Control Plane 149 Generalized Multiprotocol Label Switching (GMPLS) ([RFC3471], 150 [RFC3473], and [RFC3945]) defines a Control Plane architecture for 151 transport networks. This includes both routing and signaling 152 protocols for the creation and maintenance of Label Switched Paths 153 (LSPs) in networks whose Data Plane is based on different 154 technologies such as TDM (SDH/SONET, G.709 at ODUk level) transport 155 and WDM (G.709 OCh level). 157 3.1. Resource Ownership 159 A resource used by an LSP is said to be 'owned' by the plane that was 160 used to set up the LSP through that part of the network. Thus,all 161 the resources used by a Permanent Connection are owned by the 162 Management Plane, and all the resources used by a Switched Connection 163 are owned by the Control Plane. The resources used by an SPC are 164 divided between the Management Plane (for the resources used by the 165 permanent connection segments at the edge of the network) and the 166 Control Plane (for the resources used by the switched segments in the 167 middle of the network). 169 The division of resources available for ownership by the Management 170 and Control Planes is an architectural issue. A carrier may decide 171 to pre-partition the resources at a network entity so that LSPs under 172 Management Plane control use one set of resources and LSPs under 173 Control Plane control use another set of resources. Other carriers 174 may choose to make this distinction resource-by-resource as LSPs are 175 established. 177 It should be noted, however, that even when a resource is owned by 178 the Control Plane it will usually be the case that the Management 179 Plane has a controlling interest in the resource. For example, the 180 basic safety requirements that management commands must be able to 181 set a laser out of service. 183 3.2. Setting Up a GMPLS Controlled Network 185 The implementation of a new network using a Generalized Multiprotocol 186 Label Switching (GMPLS) Control Plane may be considered as a green 187 field deployment. But in many cases it is desirable to introduce a 188 GMPLS Control Plane into an existing transport network that is 189 already populated with permanent connections under Management Plane 190 control. 192 In a mixed scenario, Permanent Connections owned by the Management 193 Plane and Switched Connections owned by the Control Plane have to 194 coexist within the network. 196 It is also desirable to transfer the control of connections from the 197 Management Plane to the Control Plane so that connections that were 198 originally under the control of an NMS are now under the control of 199 the GMPLS protocols. In case such connections are in service, such 200 conversion must be performed in a way that does not affect traffic. 202 Since attempts to move a LSP under GMPLS control might fail due to a 203 number of reasons outside the scope of this draft, it is also highly 204 desirable to have a mechanism to convert the control of an LSP back 205 to the Management Plane. 207 Note that a Permanent Connection may be converted to a Switched 208 Connection or to an SPC, and an SPC may be converted to a Switched 209 Connection as well (PC to SC, PC to SPC, and SPC to SC). So the 210 reverse mappings may be also needed (SC to PC, SC to SPC, and SPC to 211 PC). 213 Conversion to/from control/management will occur in MIBs or 214 information (e.g., cross-connect, label assignment, label stacking, 215 etc.) is identified as either a specific control protocol, or manual 216 (i.e., NMS). When converting, this hop-level owner information needs 217 to be completed for all hops. If conversion cannot be done for all 218 hops, then the conversion must be done for no hops and the state of 219 the hop level information restored to that before the conversion was 220 attempted, and an error condition reported to the management system. 222 In either case of conversion, the Management Plane shall initiate the 223 change. When converting from a PC to an SC, the management system 224 must indicate to each hop that a control protocol is now to be used, 225 and then configure the data needed by the control protocol at the 226 connection endpoints. When converting from an SC to a PC, the 227 Management Plane must change the owner of each hop. Then the 228 instance in the Control Plane must be removed without affecting the 229 Data Plane. 231 The case where the CP and/or MP fail at one or more nodes during the 232 conversion procedure must be handled in the solution. If the network 233 is viewed as the database of record (including data, control and 234 Management Plane elements), then a solution that has procedures 235 similar to those of a two-phase database commit process may be needed 236 to ensure integrity and support the need to revert to the state prior 237 to the conversion attempt if there is a CP and/or MP failure during 238 the attempted conversion. 240 4. Typical Use Cases 242 4.1. PC to SC/SPC Conversion 244 A typical scenario where a PC to SC (or SPC) procedure can be a 245 useful option is at the initial stage of Control Plane deployment in 246 an existing network. In such a case, all the network connections, 247 possibly carrying traffic, are already set up as PCs and are owned by 248 the Management Plane. 250 At a latter stage, when the network is partially controlled by the 251 Management Plane and partially controlled by the Control Plane (PCs 252 and SCs/SPCs coexist) and it is desired to extend the control plane, 253 a PC to SC procedure can be used to transfer a PC or SPC to a SC. 255 In both cases, a connection, set up and owned by the Management 256 Plane, needs to be transferred to Control Plane control. If a 257 connection is carrying traffic, its control transfer has to be done 258 without any disruption to the Data Plane traffic. 260 4.2. SC to PC Conversion 262 The main need for a SC to PC conversion is to give an operator the 263 capability of undoing the action of the above introduced PC to SC 264 conversion. 266 In other words, the SC to PC conversion is a back-out procedure and 267 as such is not specified as mandatory in this document, but it is 268 still a highly desirable function. 270 Again it is worth stressing the requirement that such 'SPC to PC' 271 conversion needs to be achieved without any effect on the associated 272 Data Plane state so that the connection continues to be operational 273 and to carry traffic during the transition. 275 5. Requirements 277 This section sets out the basic requirements for procedures and 278 processes that are used to perform the functions of this document. 279 Notation from [RFC2119] is used to clarify the level of each 280 requirement. 282 5.1. Data Plane LSP Consistency 284 The Data Plane LSP MUST stay in place throughout the whole control 285 transfer process. It MUST follow the same path through the network 286 and MUST use the same network resources. 288 5.2. No Disruption of User Traffic 290 The transfer process MUST NOT cause any disruption of user traffic 291 flowing over the LSP whose control is being transferred or any other 292 LSP in the network. 294 SC to PC conversion and vice-versa SHALL occur without generating 295 alarms towards the end users or the NMS. 297 5.3. Transfer from Management Plane to Control Plane 299 It MUST be possible to transfer the ownership of an LSP from the 300 Management Plane to the Control Plane. 302 5.4. Transfer from Control Plane to Management Plane 304 It SHOULD be possible to transfer the ownership of an LSP from the 305 Control Plane to the Management Plane. 307 5.5. Synchronization of State Among Nodes During Conversion 309 It MUST be assured that the state of the LSP is synchronized among 310 all nodes traversed by it before the conversion is considered 311 complete. 313 5.6. Support of Soft Permanent Connections 315 It MUST be possible to segment an LSP such that it can be converted 316 to or from an SPC. 318 5.7. Failure of transfer 320 It MUST be possible for a transfer from one plane to the other to 321 fail in a non-destructive way leaving the ownership unchanged and 322 without impacting traffic. 324 If during the transfer procedure issues arise causing an unsuccessful 325 or unexpected result, it MUST be assured: 327 1. Traffic over Data Plane is not affected 329 2. The LSP status is consistent in all the network nodes involved in 330 the procedure 332 Point 2, above, assures that even in case of some failure during the 333 transfer, the state of the affected LSP is brought back to the 334 initial one and it is fully under control of the owning entity. 336 6. Security Considerations 338 Allowing control of an LSP to be taken away from a plane introduces a 339 possible way in which services may be disrupted by malicious 340 intervention. 342 A solution to the requirements in this document will utilize the 343 security mechanisms supported by the Management Plane and GMPLS 344 Control Plane protocols, and no new security requirements over the 345 general requirements described in [RFC3945] are introduced. It is 346 expected that solution documents will include an analysis of the 347 security issues introduced by any new protocol extensions. 349 If SNMP MIBs are used for configuration, then the Management Plane 350 should support authentication for PC-SC configuration changes as 351 specified in [RFC3414]. 353 Note also that implementations may support policy components to 354 determine whether individual LSPs may be transferred between planes. 356 7. IANA Considerations 358 This requirements document makes no requests for IANA action. 360 8. Contributors 361 Nicola Ciulli 362 NextWorks 363 Corso Italia 116 364 56125 Pisa, Italy 365 Email: n.ciulli@nextworks.it 367 Han Li 368 China Mobile Communications Co. 369 53 A Xibianmennei Ave. Xuanwu District 370 Deijing 100053 P.R. China 371 Phone: 10-66006688 ext.3092 372 Email: lihan@chinamobile.com 374 Daniele Ceccarelli 375 Ericsson 376 Via A. Negrone 1/A 377 Genova-Sestri Ponente, Italy 378 Phone: +390106002515 379 Email: daniele.ceccarelli@ericsson.com 381 9. Acknowledgements 383 We wish to thank the following people (listed randomly): Adrian 384 Farrel for his editorial assistance to prepare this draft for 385 publication, Dean Cheng, Julien Meuric, Dimitri Papadimitriou, 386 Deborah Brungard, Igor Bryskin, Lou Berger, Don Fedyk, John Drake and 387 Vijay Pandian for their suggestions and comments on the CCAMP list. 389 10. References 391 10.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 397 (USM) for version 3 of the Simple Network Management 398 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 400 10.2. Informational References 402 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 403 (GMPLS) Signaling Functional Description", RFC 3471, 404 January 2003. 406 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 407 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 408 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 410 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 411 (GMPLS) Architecture", RFC 3945, October 2004. 413 [G.8081] International Telecommunications Union, "Terms and 414 definitions for Automatically Switched Optical Networks 415 (ASON)", Recommendation G.8081/Y.1353, June 2004. 417 Authors' Addresses 419 Diego Caviglia 420 Ericsson 421 Via A. Negrone 1/A 422 Genova - Sestri Ponente 423 Italy 425 Email: diego.caviglia@ericsson.com 427 Dino Bramanti 428 Ericsson 429 Via Moruzzi 1 C/O Area Ricerca CNR 430 Pisa 431 Italy 433 Email: dino.bramanti@ericsson.com 435 Dan Li 436 Huawei Technologies Co., LTD. 437 Shenzhen 518129 438 Huawei Base, Bantian, Longgang 439 China 441 Email: dan.li@huawei.com 443 Dave McDysan 444 Verizon 445 Ashburn, VA 446 USA 448 Email: dave.mcdysan@verizon.com 450 Full Copyright Statement 452 Copyright (C) The IETF Trust (2008). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at 488 ietf-ipr@ietf.org.