idnits 2.17.1 draft-so-vpn-o-cs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations and Management Area Working Group N. So 2 Internet Draft Verizon 3 Intended status: Standard Track P. Unbehagen 4 Expires: Sept 2011 Alcatel-Lu 5 L. Dunbar 6 Huawei 7 H.Yu 8 TW Telecom 9 J. Heinz 10 CenturyLink 11 N.Figueira 12 Brocade 13 March 7, 2011 15 Requirement and Framework for VPN-Oriented Cloud Services 17 draft-so-vpn-o-cs-00.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and 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 September 7, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Abstract 59 This contribution addresses the service providers' requirements to 60 support VPN-Oriented Cloud services. It describes the characteristics 61 of VPN-oriented Cloud Service and specifies the requirement on how to 62 maintain and manage the data center resources for those services. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 Error! 69 Reference source not found.. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. Terminology ................................................. 3 75 3. Service definitions and requirements ........................ 4 76 4. Requirements of Data Center networks in support of VPN-Oriented 77 Cloud Services ................................................. 5 78 5. Data Center Resource Management Requirements for VPN-oriented 79 Cloud Service .................................................. 6 80 6. Security Requirement ........................................ 7 81 7. Other Requirements .......................................... 7 82 8. IANA Considerations ......................................... 8 83 9. Acknowledgments ............................................. 8 84 10. References ................................................. 8 85 Authors' Addresses ............................................. 8 86 Intellectual Property Statement................................. 9 87 Disclaimer of Validity ......................................... 9 89 1. Introduction 91 Layer 2 and 3 VPN services offer secure and logically dedicated 92 connectivity among multiple sites for enterprises. VPN-oriented Cloud 93 Service is for those VPN customers who want to offload some dedicated 94 user data center operations such as software, compute, and storage, 95 to the shared cloud centers. Those customers often do not feel 96 comfortable using public Internet as the cloud center access network. 97 They also have more restrictive requirements on what and how the 98 virtualized cloud center resources, e.g., computing power, disk 99 spaces, and/or application licenses, can be shared. 101 VPN-Oriented Cloud Services allow the VPN services to be extended 102 into cloud data centers and to control the virtual resources sharing 103 functions. As a network and cloud service provider, a VPN-Oriented 104 Cloud-service product may be offered globally across multiple data 105 centers. Some of the data centers may be owned by a network provider, 106 while others may be owned by a partner/vendor. In addition, multiple 107 VPN-oriented Cloud-Service products can be offered from the same data 108 center. 110 VPN-Oriented Cloud Services differentiate itself from other cloud 111 services in the following aspects: 113 Strictly maintaining the secure, reliable, and logical isolation 114 characteristics of VPN; 115 Making the traditional data center services (like computing, 116 storage space, or application licenses) as additional attributes to 117 VPNs. 118 VPN having the control on how and what data center resources to be 119 associated with the VPN. 120 This draft describes the characteristics of those services, their 121 service requirements, and the corresponding requirements to data 122 center networks. It also describes a list of the problems that this 123 service is causing to the network provider/operator, especially for 124 the existing VPN customers. These issues must be addressed 125 immediately in order for service providers to facilitate the addition 126 of Cloud-based services to the VPNs of existing customer. 128 2. Terminology 130 DC: Data Center 131 VM: Virtual Machines 133 VPN: Virtual Private Network 135 3. Service definitions and requirements 137 There are various types of VPN-Oriented Cloud Services. Here are just 138 some examples: 140 VPN-oriented cloud computing service 141 This refers to Virtual Machines (VMs) and/or physical servers in a 142 cloud data center being added to a VPN customer. The VPN customer 143 can choose different properties on the computing power, such as 144 dedicated servers, preference on which data center to host those 145 servers, or special VMs which are shared with a group of other VPN 146 customers, and etc. 148 Any cloud data center providing the VPN-oriented computing services 149 SHOULD be able to automatically provision and/or change the 150 required resources based on the specified properties associated 151 with a VPN. 153 VPN customers SHALL be able to automatically instantiate or remove 154 hosts to/from the VPN's associated Virtual Machines or dedicated 155 servers through the changing of the customer's VPN properties. 157 VPN-oriented cloud storage service 158 This refers to disk space, either virtual or actual blocks of hard 159 drives in data centers, being added to a customer's VPN. The VPN 160 customer SHOULD be able to choose different properties on the 161 storage space, such as: if the content has to replicated locally or 162 has to be replicated at geographically different locations; if the 163 storage has to be co-located with certain hosts; or which hosts 164 have access to the content, and etc. 166 These properties are strictly associated with the VPN. Any data 167 center providing the storage space for a VPN SHOULD be able to 168 automatically provision or change the required storage space based 169 on the property associated with the VPN. 171 The VPN customer SHOULD be able to automatically add disc space or 172 remove disc space to the VPN's associated storage through the 173 changing of the VPN properties. 175 Each VPN SHALL have the ability to limit the mobility of the stored 176 data to a certain geographic region confinement (country/state). 178 4. Requirements of Data Center networks in support of VPN-Oriented Cloud 179 Services 181 The success of VPN services in the enterprise and the government 182 world is largely due to its ability to virtually segregate the 183 customer traffic at layer 2 and layer 3. The lower the layer that 184 segregation can be maintained, the safer it is for the customers from 185 security and privacy perspectives. Today's Data Centers use VLANs to 186 segregate servers and traffic from different customers. Since each 187 customer usually needs multiple zones (e.g., DMZ, Web Server zone, 188 and etc) to place different applications, each customer usually needs 189 multiple VLANs. Even small data centers today already consume several 190 thousands of VLANs. Therefore, pure VLAN segregation is not enough 191 for large data centers. 193 Network service providers view data center resources as added 194 attributes to VPNs. Therefore, traffic segregation per VPN is an 195 essential requirement to the success of VPN-oriented Cloud-Services 196 in the enterprises and government markets. Other essential 197 requirements include: 199 Requirements for extending VPNs into data center networks using VPN 200 gateways: 201 o The Cloud Service associated with certain VPN(s) SHALL be 202 transmitted over a pre-defined set of connections, and each 203 VPN utilizing the service SHALL be transmitted over a sub-set 204 of logical connections. 205 o The VPN gateway should maintain a mapping among Virtual or 206 physical Resources, physical/logical connections, with 207 specific VPNs. 208 o The VPN Gateway SHOULD be able to control the connection 209 traffic flow and assign the dedicated virtual resources 210 accordingly. 212 Independent of the L2/3 technology, e.g., TRILL, PBB, SPB, 213 OpenFlow, and etc, used for connecting external (customer) VPNs and 214 data center virtual resources, e.g., , each VPN SHALL be given a 215 unique Service ID, and traffic separation SHALL be maintained per 216 Service ID. 217 When a L2/3 VPN is used as the network technology connecting the 218 external (customer) VPN and the data center virtual resources, each 219 external VPN SHALL be mapped to a unique internal VPN. 221 5. Data Center Resource Management Requirements for VPN-oriented Cloud 222 Service 224 Today, data center server resources are managed by data center 225 servers' administrators or management systems, and supported by 226 hypervisors on the servers. The entire process is invisible to the 227 underlying networks. The data center management functions today 228 include managing servers, instantiating hosts to VMs, managing disk 229 space, and etc. 231 Traffic loading and balancing and QoS assignments for data center 232 networks are usually not considered by Data Center's server 233 administration systems. There shall be a way that the VPN can connect 234 with the Data Center's server administration systems that are 235 important to the concept and spirit of the VPN: 237 The resources in data center MUST be partitioned per VPN's 238 requirements instead of the traditional partitioning per customer. 239 The Cloud orchestration system SHALL have the ability to dedicate 240 a specific block of disk space per services per VPN. 241 If a VPN requires dedicated access to blocks of disk space, the 242 data center disk management system SHALL allocate the required 243 disk space per VPN and be able to let VPN automatically retrieve 244 the identification of those disk spaces. 245 If a VPN specifies its associated storage space to be accessible 246 only by certain hosts, the data center disk management system 247 SHALL have the ability to indicate the mechanism used to prevent 248 the unwanted data retrieval for the block of disk space after it 249 is no longer used by the VPN, before it can be re-used by other 250 parties. 252 The VPN SHALL have the ability to request dedicated L2/3 network 253 resources within the data center such as bandwidth, priorities, 254 and so on. 255 The VPN SHALL have the ability to hold the requested resources 256 without sharing with any other parties. 257 The VPN's QoS assignments SHOULD be able to synchronize with the 258 Cloud virtual resources' QoS assignments. 260 6. Security Requirements 262 VPN-Oriented Cloud Service SHOULD support a variety of security 263 measures in securing tenancy of virtual resources such as 264 resource locking, containment, authentication, access control, 265 encryption, integrity measure, and etc. 266 The VPN-Oriented Cloud Service SHOULD allow the security to be 267 configured end-to-end on a per VPN per-user basis. For example, 268 the Virtual Systems MUST resource-lock resources such as memory, 269 but must also provide a cleaning function to insure 270 confidentiality before being reallocated. 271 VPN-Oriented Cloud Service for private Clouds SHOULD specify an 272 authentication mechanism based on an authentication algorithm 273 (MD5, HMAC-SHA-1) for both header and payload. Encryption MAY 274 also be use to provide confidentiality. 275 Security boundaries MAY also be create to maintain domains of 276 TRUSTED, UNTRUSTED, and Hybrid. Within each domain access 277 control, techniques MAY be used to secure resources and 278 administrative domains. 280 7. Other Requirements 282 The VPN-Oriented Cloud Service SHALL support automatic end-to- 283 end network configuration. 284 The VPN-Oriented Cloud Service solution MUST have sufficient OAM 285 mechanisms in place to allow consistent end-to-end management of 286 the solution in existing deployed networks. The solution SHOULD 287 use existing protocols (e.g., IEEE 802.1ag, ITU-T Y.1731, BFD) 288 wherever possible to facilitate interoperability with existing 289 OAM deployments. 291 8. IANA Considerations 293 9. Acknowledgments 295 This document was prepared using 2-Word-v2.0.template.dot. 297 10. References 299 Authors' Addresses 301 Ning So 302 Verizon Inc. 303 2400 N. Glenville Ave., 304 Richardson, TX75082 305 ning.so@verizonbusiness.com 307 Paul Unbehagen 308 Alcatel-Lucent 309 8742 Lucent Boulevard 310 Highlands Ranch, CO 80129 311 paul.unbehagen@alcatel-lucent.com 313 Linda Dunbar 314 Huawei Technologies 315 1700 Alma Drive, Suite 500 316 Plano, TX 75075, USA 317 Linda.dunbar@huawei.com 319 Henry Yu 320 TW Telecom 321 10475 Park Meadows Dr. 322 Littleton, CO 80124 323 Henry.yu@twtelecom.com 325 John M. Heinz 326 CenturyLink 327 600 New Century PKWY 328 KSNCAA0420-4B116 329 New Century, KS 66031 330 john.m.heinz@centurylink.com 332 Norival Figueira 333 Brocade Networks 334 130 Holger Way 335 San Jose, CA 95134 336 nfigueir@brocade.com 338 Intellectual Property Statement 340 The IETF Trust takes no position regarding the validity or scope of 341 any Intellectual Property Rights or other rights that might be 342 claimed to pertain to the implementation or use of the technology 343 described in any IETF Document or the extent to which any license 344 under such rights might or might not be available; nor does it 345 represent that it has made any independent effort to identify any 346 such rights. 348 Copies of Intellectual Property disclosures made to the IETF 349 Secretariat and any assurances of licenses to be made available, or 350 the result of an attempt made to obtain a general license or 351 permission for the use of such proprietary rights by implementers or 352 users of this specification can be obtained from the IETF on-line IPR 353 repository at http://www.ietf.org/ipr 355 The IETF invites any interested party to bring to its attention any 356 copyrights, patents or patent applications, or other proprietary 357 rights that may cover technology that may be required to implement 358 any standard or specification contained in an IETF Document. Please 359 address the information to the IETF at ietf-ipr@ietf.org. 361 Disclaimer of Validity 363 All IETF Documents and the information contained therein are provided 364 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 365 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 366 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 367 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 368 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 369 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 370 FOR A PARTICULAR PURPOSE. 372 Acknowledgment 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.