INTERNET-DRAFT So et al
Intended Status: Proposed Standard Verizon
Expires: November 2011 October 17, 2010
VPN Extensions for Private Clouds
draft-so-vepc-00.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) 2010 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 November 2011 [Page 1]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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 . . . . . . . . . . . . . . . . . . . . 3
2.2.1. VPN Gateway Managed Connection Segregation . . . . . . 3
2.2.2 solution using Provider Backbone Bridging (PBB) and
Shortest Path Bridging (SPB) . . . . . . . . . . . . . 4
2.2.3 VPN Gateway Controlled Traffic Flow . . . . . . . . . . 4
2.2.4 Inter-VPN Interworking . . . . . . . . . . . . . . . . 4
2.3. Cloud Services Virtualization . . . . . . . . . . . . . . . 4
2.3.1. Cloud Virtualization Requirements . . . . . . . . . . 4
2.4. Cloud Services Restoration . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . 6
2.5.4 Automation end to end Configuration . . . . . . . . . . 6
2.6. End-to-End Quality of Experience (ETE-QoE) . . . . . . . . 6
2.7. OAM Considerations . . . . . . . . . . . . . . . . . . . . 7
2.8. Work Item Considerations in IETF Clouds . . . . . . . . . . 7
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Normative References . . . . . . . . . . . . . . . . . . . 8
5.2 Informative References . . . . . . . . . . . . . . . . . . 8
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
So et al Expires November 2011 [Page 2]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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 data centers segregate the
customer traffic at layer 7 (application), and there is no standard
for extending the VPN into data center. 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
So et al Expires November 2011 [Page 3]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
setup connections with the VPN gateways, while the gateways attach
each connection to corresponding VPN. Each Cloud-Application SHALL
be transmitted over a pre-defined set of connections, and each VPN
utilizing the application SHALL be transmitted over a sub-set of
application connections. In this case, each Cloud-Application SHALL
maintain its own independent routing table. This is possible for some
current operating systems, which already support multiple routing
instances for its TCP/IP stack.
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 (VM's) to
become more autonomic and secure for environments that include wholly
owned and multi-tenant.
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.
2.2.3 VPN Gateway Controlled Traffic Flow
It is also possible for each Cloud-Application to acquire access to
L2/L3 VPN with one shared routing table supported 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
So et al Expires November 2011 [Page 4]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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.
- 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
So et al Expires November 2011 [Page 5]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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.
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 mis-
configuration. 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
So et al Expires November 2011 [Page 6]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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
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 November 2011 [Page 7]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
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
So et al Expires November 2011 [Page 8]
INTERNET DRAFT draft-so-vepc-00.txt October 17, 2010
ning.so@verizonbusiness.com
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
Tel.:1-781-752-8003
Email: vumip1@gmail.com
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
So et al Expires November 2011 [Page 9]