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]