INTERNET-DRAFT So et al Intended Status: Proposed Standard Verizon Expires: August 17, 2011 February 13, 2011 VPN Extensions for Private Clouds draft-so-vepc-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. So et al Expires August 17, 2011 [Page 1] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 Abstract This contribution addresses the service providers requirements to support Cloud services interworking with the existing MPLS-based L2 and L3 VPN services. Maintenance of virtual separation of the traffic, data, and queries must be supported for the VPN customers that are conscious of end-to-end security features and functions that VPN technologies provide today. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Cloud Customer End to End Separation . . . . . . . . . . . . . . 3 2.1. VPN Traffic Segregation Requirements . . . . . . . . . . . 3 2.2. Potential Solution . . . . . . . . . . . . . . . . . . . . 4 2.2.1. VPN Gateway Managed Connection Segregation . . . . . . 4 2.2.2 Solution using Provider Backbone Bridging (PBB) and Shortest Path Bridging (SPB) . . . . . . . . . . . . . 4 2.2.3 VPN Gateway Controlled Traffic Flow . . . . . . . . . . 5 2.2.4 Inter-VPN Interworking . . . . . . . . . . . . . . . . 5 2.3. Cloud Services Virtualization . . . . . . . . . . . . . . . 5 2.3.1. Cloud Virtualization Requirements . . . . . . . . . . 5 2.4. Cloud Services Restoration . . . . . . . . . . . . . . . . 6 2.5 Other Non-VPN Specific Areas . . . . . . . . . . . . . . . . 6 2.5.1. Cloud Traffic Load-Balancing and Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . 6 2.5.2. QoS Synchronization . . . . . . . . . . . . . . . . . 6 2.5.3 Cross Layer Optimization . . . . . . . . . . . . . . . 7 2.5.4 Automation end to end Configuration . . . . . . . . . . 7 2.6. End-to-End Quality of Experience (ETE-QoE) . . . . . . . . 7 2.7. OAM Considerations . . . . . . . . . . . . . . . . . . . . 7 2.8. Work Item Considerations in IETF Clouds . . . . . . . . . . 7 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 So et al Expires August 17, 2011 [Page 2] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 1 Introduction Data center, WAN/MAN, and the end user are three of the components that make up the Cloud in the vision of Cloud Computing. However, the existing technologies often treat each component as black boxes, detached from each other. This fact limits the overall cohesiveness of an end-to-end service. For example, the network often views the data center as a black box, meaning the network has no control or visibility (from a standards point-of-view) into the data center. As a network provider, a Cloud-service product may be offered across multiple data centers globally, some of which may be owned by a network provider while others may be owned by a partner/vendor. In addition, multiple Cloud-Service products can be offered in the same data centers. A list of the problems that this situation is causing the network provider/operator, especially for the existing VPN customers, is presented below. These must be addressed immediately, in order for service providers to persuade the existing VPN customers to leverage the deployed Cloud-based services. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Cloud Customer End to End Separation 2.1. VPN Traffic Segregation Requirements The success of VPN services in the enterprise and the government world is largely due to its ability to virtually segregate the customer traffic at layer 2 and layer 3. The lower the layer that segregation can be maintained, the safer it is for the customers from security and privacy perspectives. Today, networks within a data center are administrated by separate entities than the networks which interconnect data centers to end users. Prior to Cloud services age, all applications running on data center's servers and data stored in data center's storage devices are managed by data center owners. The network segregation within data center, usually in Layer 2 VLAN format, is mainly to control broadcast domain and optimize network performance. With the introduction of cloud services, applications running on servers or virtual servers within data center can be owned and administrated by individual users or clients. For clients who already have VPN from service providers to interconnect multiple So et al Expires August 17, 2011 [Page 3] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 sites, they need their cloud service to be integrated within the same VPN. Therefore, it is very crucial for service providers to extend their existing VPNs into data centers. Network service providers view the VPN extension into data center, allowing traffic segregation per VPN, an essential necessity to the success of Cloud-Services in the enterprises and government markets. Cloud-Applications (or the virtualization function) SHOULD have the ability to get access to VPN (including Layer 2/3 VPN) services, to segregate different Cloud- Services traffic trough the network. 2.2. Potential Solution 2.2.1. VPN Gateway Managed Connection Segregation One possible way to achieve this is to have each Cloud-Application setup connections with the VPN gateways, while the gateways attach each connection to corresponding VPN. This can be accomplished using a simple VRF from a provider edge router, each client can be assigned to one VRF. If Provider Edge Router (for provider VPN) is not co-located with the data center gateway, then it is necessary for Data Center gateway to build tunnels to VPN provider edge router. Or requiring each host running within the data center to have an IPSec VPN client, which can establish its own VPN tunnel to the provider edge router. 2.2.2 Solution using Provider Backbone Bridging (PBB) and Shortest Path Bridging (SPB) Ethernet and VLANS are the standard L2 connectivity model throughout the data center environment. As such the IEEE has been working on numerous projects to simplify and extend traditional Ethernet models for scale and flexibility. Additionally the IEEE has projects looking at new attachments models for Virtual Machines (VMs) to become more autonomic and secure for environments that include wholly owned and multi-tenant. The I-SID extensions that are defined in the SPB standard SHOULD also be used to connect a configured I-SID to an existing VRF on the provider edge router when SBPB is used for L2 discovery in the data center. Although VLAN and PPPoE are different types of connections, the two methods described above are fundamentally the same. Consequently, it is possible to generalize the descriptions above to cover both the cases. So et al Expires August 17, 2011 [Page 4] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 2.2.3 VPN Gateway Controlled Traffic Flow When virtual switch function is supported by servers which support VMs, L2/L3 VPN features can be added to the Virtual Switch on the server. One way to do that is to have the VPN gateway manage the traffic flow instead of other way around. In that case, the VPN gateway has the VRF table and the destination server connection address. Once the server receives the traffic, it determines intra- data center destination based on the application. So the control sequence is VPN first, and then application. The control sequence for the first two methods described above is application first, and then VPN. 2.2.4 Inter-VPN Interworking L2/L3 VPN based MPLS network can also be deployed in the data center to manage the intra-data center traffic flow. The data center VPN structure can be set up in such a way that each external VPN can be mapped to a unique internal VPN. 2.3. Cloud Services Virtualization 2.3.1. Cloud Virtualization Requirements Today data center virtualization is totally handled by data center servers and hypervisors. The entire process is invisible to the underlying networks. The virtualization function including application server and virtual machine (VM) allocation and assignment, disk space allocation, traffic loading and balancing, QoS assignments, and so on. There shall be a way that the network can influence some virtualization functions that are important to the concept and spirit of the VPN. - The Private Cloud provisioning and management system SHALL have the ability to dedicate a specific block of disk space per services per VPN. - Each VPN SHALL have the exclusive access to the dedicated block of disk space. - Each VPN SHALL have the ability to indicate the mechanism used to prevent the unwanted data retrieval for the block of disk space after it is no longer used by the VPN, before it can be re-used by other parties. - Each VPN SHALL have the ability to request a dedicated VM with certainly CPU capability, amount of memory and disk space. So et al Expires August 17, 2011 [Page 5] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 - The VPN SHALL have the ability to request dedicated L2/3 network resources within the data center such as bandwidth, priorities, and so on. - The VPN SHALL have the ability to hold the requested resources without sharing with any other parties. 2.4. Cloud Services Restoration Today, data center restoration and diversity designs are not necessarily linked to the network restoration and diversity design. This results in over-redundant design, wasting money and resources, and may cause traffic oscillation and service and performance degradation. This problem is particularly important to the VPN traffic, which is usually highly performance sensitive. The VPN extension SHOULD be able to indicate how the restoration is handled across layers, so that a unified end-to-end design and optimization can be achieved. Furthermore the restoration capability awareness needs to be scalable, meaning problems occur in one area of the Cloud SHALL NOT affect all other areas of the Cloud involved. This way each component of the Cloud can scale independently without causing systemic failures and/or allowing a single failure to cascade across the Cloud. 2.5 Other Non-VPN Specific Areas There are a number of known technology gaps preventing the data centers, networks, and the end users from interworking together in providing optimized and seamless end-to-end services. Although those areas are beyond VPN, they impact the VPN-based cloud services significantly. Those areas are listed below, but they are beyond the scope of this draft. 2.5.1. Cloud Traffic Load-Balancing and Congestion Avoidance Todays Cloud traffic balancing and congestion avoidance is purely data center based. The network condition is not taken into consideration. The VPN extension SHOULD support the network condition to be used for the traffic balancing and congestion avoidance decision-making. 2.5.2. QoS Synchronization It is required that the virtualization functions QoS requirement SHOULD be synchronized with VPN service. So et al Expires August 17, 2011 [Page 6] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 2.5.3 Cross Layer Optimization The VPN resource requested by the server CAN be optimized by statistical multiplexing of the resource. For example, for each VPN resource, it is possible to configure committed BW for each QoS resources and peak BW for best effort traffic, and the peak BW resources CAN be shared by different VPN service. 2.5.4 Automation end to end Configuration The automatic end-to-end network configuration will reduce the operational cost and also the probability of occurrence of misconfiguration. The VPN Extension SHALL support the automatic end- to-end network configuration. 2.6. End-to-End Quality of Experience (ETE-QoE) Quality of experience (QoE) management refers to maintaining a set of application /service layer parameters within certain threshold with an objective to retain the user experience for a specific service. Very often when new underlying technologies and/or mechanisms are introduced for implementing the same services (voice, data, video, messaging, etc.), opportunities exist to improve the user experiences. Conversely the user experience may suffer unless the appropriate transport level parameters that significantly impact the QoE are monitored and managed. 2.7. OAM Considerations The VPN Extension solution MUST have sufficient OAM mechanisms in place to allow consistent end-to-end management of the solution in existing deployed networks. The solution SHOULD use existing protocols (802.3ag, Y.1731, BFD) wherever possible to help with interoperability of existing OAM deployments. 2.8. Work Item Considerations in IETF Clouds In VPN extension to private Clouds, various application level parameters, protocol level parameter, and service monitoring parameters may need to be defined, and the results of monitoring may need to be exchanged periodically. In private cloud environment, since the resources exist in one or co-operative administrative domain, it is easier to monitor and manage the application and transport level parameters for the underlying resources. In some cases, proactive mechanisms can be readily implemented before user experiences degrade to the level of annoyance. In public and hybrid (a smart combination of private and public) clouds it is required to derive a list of mutually agreed upon monitoring and management So et al Expires August 17, 2011 [Page 7] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 parameters. Active monitoring using virtual agents and resources is also possible. However, allocation of resources and placement of the virtual agent including the amount of traffic generated for QoE management, and the exchange of the desired information back and forth need to be achieved. So et al Expires August 17, 2011 [Page 8] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 3 Security Considerations The VPN extension SHOULD support variety of security measures in securing tenancy of virtual resources such as resource locking, containment, authentication, access control, encryption, integrity measure, and etc. The VPN extension SHOULD allow the security to be configure end-to-end on a per VPN per-user bases. For example, the Virtual Systems MUST resource lock resources such as memory, but must also provide a cleaning function to insure confidentiality, before being reallocated. VPN extension for private Clouds SHOULD specify an authentication mechanism based on an authentication algorithms (MD5, HMAC-SHA-1)for both header and payload. Encryption MAY also be use to provide confidentiality. Security boundaries MAY also be create to maintain domains of TRUSTED, UNTRUSTED, and Hybrid. Within each domain access control techniques MAY be uses to secure resource and administrative domains. 4 IANA Considerations None 5 References 5.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2 Informative References None Author's Addresses Ning So Verizon Inc. 2400 N. Glenville Rd., Richardson, TX 75082 ning.so@verizonbusiness.com So et al Expires August 17, 2011 [Page 9] INTERNET DRAFT draft-so-vepc-01.txt February 13, 2011 Henry Yu tw telecom 10475 Park Meadows Dr. Littleton, CO 80124 henry.yu@twtelecom.com John M. Heinz CenturyLink Phone: 913-533-2115 john.m.heinz@centurylink.com Paul Unbehagen Alcatel-Lucent 8742 Lucent Boulevard Highlands Ranch, CO 80129 paul.unbehagen@alcatel-lucent.com Mike Mangino Alcatel-Lucent 8742 Lucent Boulevard Highlands Ranch, CO 80129 mike.mangino@alcatel-lucent.com Bhumip Khasnabish ZTE USA, Inc. 33 Wood Ave. S., 2nd Flr Iselin, NJ, USA vumip1@gmail.com Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China lizhong.jin@zte.com.cn So et al Expires August 17, 2011 [Page 10]