Internet DRAFT - draft-zeng-vpn4dc-example-solution
draft-zeng-vpn4dc-example-solution
Network working group Q. Zeng
Internet Draft D. Yu
Intended status: Information Track Huawei Technologies
Expires: April 2012
October 30, 2011
Experiment of Example Solution for VPN4DC
draft-zeng-vpn4dc-example-solution-01.txt
Abstract
More and more service providers proposed VPN4DC requirements. That
is how to maintain and manage the host-to-host connectivity through
Layer 3 Virtual Private Networks (L3VPNs) between an enterprise
legacy VPN site and the virtual datacenter (VDC) in datacenter,
including automated provisioning, monitoring, and so on[VPN4DC].
This document provides an example solution by prototyping experiment
for VPN4DC auto-provision. This solution is focus on the network
side and the DC Edge, the DC inside is out of scope.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Zeng, et al. Expires April 30, 2012 [Page 1]
Internet-Draft Example Solution for VPN4DC October 2011
This Internet-Draft will expire on April 30, 2012.
Copyright 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.
Conventions used in this document
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].
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document............................ 3
3. Example Solution ............................................ 3
3.1. Definitions ............................................ 3
3.2. Overview ............................................... 4
3.3. Prototype1 - Management Plane Solution ..................5
3.4. Prototype2 - Control Plane Solution (ongoing) ...........7
4. Contributors ................................................ 8
5. Acknowledgments ............................................. 9
6. References .................................................. 9
6.1. Normative References.................................... 9
6.2. Informative Reference................................... 9
Authors' Addresses ............................................. 9
1. Introduction
More and more service providers proposed VPN4DC requirements. That
is how to maintain and manage the host-to-host connectivity through
Layer 3 Virtual Private Networks (L3VPNs) between an enterprise
legacy VPN site and the virtual datacenter (VDC) in datacenter,
including automated provisioning, monitoring, and so on[VPN4DC].
Zeng, et al. Expires April 30, 2012 [Page 2]
Internet-Draft Example Solution for VPN4DC October 2011
This document provides an example solution by prototyping experiment
for VPN4DC auto-provision. This solution is focus on the network
side and the DC Edge, the DC inside is out of scope. A finished
prototyping shows basic service mechanism of VPN4DC. And an ongoing
prototyping activity is to go further to experiment more.
2. Conventions used in this document
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Example Solution
3.1. Definitions
VPN4DC Controller: A service controller for VPN4DC, receives user
requests for host to host connection, translates user request into
instructions for VPN network domain to allocate VPN connection and
Data Center domain to allocate cloud resource.
VPN Database: A database stores user information and corresponded
VPN configuration information. By a unique ID, e.g., VPN User ID, it
can by queried VPN configuration information and additional
configuration information correspond this ID.
VPN Manager: A VPN Manager controls a VPN network domain, VPN
Database typically collocates with the VPN Manager, keeps the on-
line VPN configuration information and VPN user information. The VPN
Manager has authentication and authorization functionality to
control the VPN connection's creation.
DC Manager: A DC Manager controls a Data Center domain, manipulates
the Data Center network as well as computing and storage resources
in Data Center. Typically the VPN4DC Controller collocates with DC
Manager.
PE: Provider Edge Device, A network device resides in provider
network act as a control point for VPN4DC accessing. Typically it
can be looked as a PE with extended VPN accessing features, help to
enforce policy control on every VDC connection to a specific VPN.
Zeng, et al. Expires April 30, 2012 [Page 3]
Internet-Draft Example Solution for VPN4DC October 2011
DCG: DC Gateway, A network device resides in DC network issue a
VPN4DC connection to VPN for a user.
VCE: Virtual CE, Virtual customer edge device, it can be a
virtual/logical router in DC gateway, or can be a host in server.
3.2. Overview
The main target for VPN4DC is that we need an automated service. It
mainly because current commercial cloud platforms may be
instantiated or reconfigured by the customer on a self-provision
manner. The traditional VPN models have no characteristics of cloud,
it typically involved a rigid workflow based on human intervention
by service provider. Elasticity of resources, on-demand
reconfiguration, and mobility has never been requirements in VPN
environments.
We need a network device in DC network to know which the VPN the
user want to join. And the network device need this information to
setup the VPN. The question is how the information is provided to
the network device. We assume the initial VPN configuration be
stored in VPN Database, by a unique ID. This VPN configuration
information can be extracted for the DC Side Network Device to
connect the target VPN.
Two example prototypes will be showed in this document.
1. Management Plane Solution: With this solution, we try to keep the
under-network unchanged, the VPN4DC service is mainly process on
an automated management system, VPN Manager communicates with DC
Manager each other directly or via a VPN4DC Controller, so the
two Managers get the consistent VPN configuration information.
The VPN configuration information is downloaded to the PE and DCG
respectively. PE and DCG finish configuration that enable hosts
in a Data Center to join a specific VPN.
2. Control Plane Solution (in-band): VPN Manager doesn't communicate
with DC Manager each other. DCG send a request for VPN-
connectivity to the PE via some control protocol in-band. After
some authentication process on PE and authentication system, PE
gets the target VPN configuration and advertises the information
to the DCG. Both PE and DCG get correct VPN configuration
information that set up the VPN connection. After PE had
authorized the host joint from DCG, PE advertise the host route
into the service provider network that enables hosts in a Data
Center to join a specific VPN.
Zeng, et al. Expires April 30, 2012 [Page 4]
Internet-Draft Example Solution for VPN4DC October 2011
3.3. Prototype1 - Management Plane Solution
Management Plane Solution focuses on the interaction on the
management plane of different management systems.
+--------------------------------+
| VPN4DC Controller |
+--------------------------------+
| |
+---------+ | |
| VPN DB | | |
+---------+ | |
| | |
+--------+ +--------+
| VPN Mgr| | DC Mgr |
+--------+ +--------+
| |
| |
+--------+ +--------+
| PE |------------------|DCG/VCEs|
+--------+ +--------+
Figure 1
The following is the process:
1. The user makes request for VMs on a web-portal, the front-end
of VPN4DC controller. The user provides VPN identifier
information to tell what VPN the VMs be to join in.
Zeng, et al. Expires April 30, 2012 [Page 5]
Internet-Draft Example Solution for VPN4DC October 2011
2. The VPN4DC Controller sends the request for VMs to DC Manager
with a VLAN ID,e.g. 5, and a couple of IP addresses for the
directly connection between PE and VCE, e.g.
192.168.1.1/192.168.1.2.
3. The VPN4DC Controller sends the request to VPN manager to
join a VPN along with the VPN identifier said above, and VLAN ID
5, and IP address 192.168.1.1/192.168.1.2.
4. DC manager finishes VMs allocation and activates the VMs. DC
manager allocates a VCE on DCG. DC managers configures the VLAN
5 (correspond a sub-interface) and IP address 192.168.1.2 on the
VCE. VCE issues iBGP and peers with 192.168.1.1.
5. VPN manager queries VPN configuration information (e.g. RT/RD)
from VPN database by the VPN identifier. VPN manager configure
the PE with VLAN 5 (correspond a sub-interface) and IP address
192.168.1.1. VPN manager configure a VPN instance with the RT/RD
and sub-interface (VLAN 5), and bind the VPN instance with the
sub-interface which has been configured with VLAN 5. PE adds
peer 192.168.1.2 into its iBGP session. Other additional
configuration such as ORF or Qos can be configured with the VPN
instance.
6. After PE and VCE finish the configuration, the binding of VDC
with target VPN is enabled. Along with the host route of VM
advertised from VCE to PE, and from PE to the service provider
network, the binding of VMs with target VPN is enabled.
Summary for this example:
1. The VPN4DC system needs a VPN4DC controller to process original
user request. The VPN4DC controller translates user request into
instructions for VPN configuration and cloud resource
configuration.
2. The VPN4DC system needs a VPN database stores user information
and VPN configuration. Given a unique ID, the VPN configuration
information can be queried from the VPN database and be downloaded
to the PE.
3. The PE and DCG/VCE need to cooperate to bind the cloud resource
to VPN correctly. The PE needs to know some information configured
on VCE, and VCE needs to know some information configured on PE.
But in practice, there may be some problems for this solution.
Zeng, et al. Expires April 30, 2012 [Page 6]
Internet-Draft Example Solution for VPN4DC October 2011
1. It is a challenge to have VPN management system cooperated with
DC management system directly or via VPN4DC Controller.
2. VPN management system is administrative system of the service
provider, but in this context there are a little bit dangerous for
the user/customer accessing it indirectly via VPN4DC Controller.
Furthermore, It is a challenge to change the VPN management system
into an automated one.
3.4. Prototype2 - Control Plane Solution (ongoing)
This example is ongoing. By this example, the network PE and DCG
undertake more work for VPN4DC set up, reduce complexity of among
VPN4DC controller, VPN manager and DC manager.
+--------------------------+
| VPN4DC Controller |
+--------------------------+
|
|
+-----------+ +--------+
| AAA/VPNMgr| | DC Mgr |
| VPNDB | | |
+-----------+ +--------+
| |
| |
+--------+ +--------+
| PE | ---------------- | DCG |
+--------+ +--------+
Figure 2
The following is the process:
Zeng, et al. Expires April 30, 2012 [Page 7]
Internet-Draft Example Solution for VPN4DC October 2011
1. The user makes request for VMs on a web-portal, the front-end
of VPN4DC controller. The user provides VPN identifier
information to tell what VPN the VMs be to join in.
2. The VPN4DC Controller sends the request for VMs to DC Manager
along with the VPN identifier.
3. DC Manager allocates VMs for the user, and configures VLAN for
the VMs. DC manager designates DCG to request to join the target
VPN and send it the VPN identifier and Host ID list of VMs.
4. DCG sends request to PE to join a target VPN. The request
includes the VPN identifier and Host ID list of VMs.
5. PE forwards the request to AAA/VPN Manager/VPNDB system, if
the VPN identifier is authorized by AAA system, the target VPN
configuration is fetched from VPNDB, and downloaded to the PE.
And PE records the Host ID list related the target VPN.
6. The PE does some configuration for the target VPN and sends
response to the DCG, the necessary VPN configuration info is
included in the response.
7. The DCG does some configuration for the target VPN. Then the
VPN connection is to be created.
8. DCG send VM join request for the target VPN to PE, which can
be carried via a host route advertise. After PE had authorized
the host joining, PE could advertise the host route into the
service provider network. Then, the binding of VMs with target
VPN is enabled.
Notes:
1. The signaling between PE and DCG should carry VPN joining and
VM joining request, response and access control processing. None
of existing protocols apply to PE-CE for L3VPN routing learning
is able to provide these capabilities. We plan to extend some
protocol, such as BGP to support it.
4. Contributors
The following individuals contributed to this document: Ying Liu,
Shihui Hu.
Zeng, et al. Expires April 30, 2012 [Page 8]
Internet-Draft Example Solution for VPN4DC October 2011
5. Acknowledgments
The authors would like to thank So Ning, Lucy Yong, Linda Dunbar
for their valuable suggestions and comments to this document.
6. References
6.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E., Rekhter, Y., " BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, Feb 2006.
6.2. Informative Reference
[VPN4DC] So, et al, "Requirement of Layer 3 Virtual Private Network
for Data Centers", draft-so-VPN4DC-00, October 2011.
[PROBLEM] L. Dunbar, et al, "Problem Statement for VPN for Data
Centers", draft-dunbar-vpn4dc-problem-statement-00,
October 2011.
[GAP] Lucy Yong, et al, "L3VPN Protocol Gap Analysis for Data
Centers", draft-yong-vpn4dc-protocol-gap-analysis-00,
October 2011.
Authors' Addresses
Qing Zeng
Huawei Technologies Co.,Ltd.
Email: zengqing@huawei.com
Delei Yu
Huawei Technologies Co.,Ltd.
Email: yudelei@huawei.com
Zeng, et al. Expires April 24, 2012 [Page 9]
