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]