| Network Working Group | M. Hasan |
| Internet-Draft | A. Chari |
| Intended status: Informational | D. Fahed |
| Expires: August 31, 2012 | France Telecom - Orange Labs |
| L. Tucker | |
| M. Morrow | |
| Cisco Systems, Inc. | |
| M. Malyon | |
| Cisco Systems, Inc. | |
| March 2012 |
A framework for controlling Multitenant Isolation, Connectivity and Reachability in a Hybrid Cloud Environment
Multiple enterprises (tenants) consuming resources in a public Cloud shares the physical infrastructure of one or more DCs out of which the Cloud resources are serviced. Hence one of the major features that has to be supported in public Cloud DCs is multitenant isolation, which is realized via various DC isolation technologies, such as VLAN or VxLAN. In a hybrid Cloud environment where a public Cloud (more specifically off-premises public Cloud resources acquired by a tenant ) becomes an extension of a tenant intranet or private Cloud, the multitenant isolation capability has to be extended beyond the public Cloud DCs. The multitenant isolation domain has to span end-to-end from the tenant network or on-premises resources via the MAN/WAN and the public Cloud DC networks to tenant off-premises resources. While multitenant isolationI isolates one tenant from another (inter-hybrid Cloud isolation), an enterprise may desire controlled connectivity to a hybrid Cloud from another Cloud or network or tenant or select resources. In addition, there may be need for controlling direct reachability of resources within a hybrid Cloud itself (intra-hybrid Cloud). The tenant network may be connected to the public Cloud (DCs) over the Internet or a private IP/MPLS MAN/WAN owned or operated by a service provider, which also may support PPVPN (Provider Provided VPN) service, such as the L3 MPLS VPN. In this work we consider the latter type of network and describe a framework for supporting inter-hybrid Cloud multitenant isolation, inter-hybrid Cloud connectivity and intra-hybrid Cloud reachability.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 31, 2012.
Copyright (c) 2012 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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
A Cloud service provider (CSP) offers services to tenants (enterprises, enterprise departments, employees, end consumers) out of one or more Cloud DCs, where a tenant can acquire or release (CRUD: Create, Read, Update, Delete) compute, storage or network resources on-demand and anytime. The CSP exposes Cloud service interfaces to tenants which are used by tenants to CRUD resources.
The NIST definition of Cloud computing [NIST] has defined following Cloud deployment models:
The NIST definition of the hybrid Cloud refers to multiple interoperable Clouds to which we include a case where an enterprise may not have a private Cloud. Following are the options in which a hybrid Cloud can be architected or deployed:
In this document we focus on A1 and A2 (the other options require further considerations and will be addressed in future work). We assume that the same SP owns or operates both the public Cloud (DCs) and the private MAN/WAN. Employing PPVPN (Provider Provided VPN, such as L3 MPLS VPN) features we describe a framework that facilitates inter-hybrid Cloud multitenant isolation and connectivity and intra-hybrid Cloud direct reachability between resources in the same hybrid Cloud. Note that the realization framework discussed in this document covers only the MAN/WAN segment of the end-to-end network of a hybrid Cloud.
The simplest case of a hybrid Cloud environment is where an enterprise connects to a public Cloud and consumes resources and all-to-all communication, connectivity, reachability and route advertisements are allowed (between the whole enterprise intranet or private Cloud and all the acquired off-premises resources). But enterprises should have the flexibility in defining what constitutes a hybrid Cloud and control communication, connectivity and reachability in and across a hybrid Cloud (for enhanced security, flexibility and enterprise specific needs).
While deploying a hybrid Cloud an enterprise (IaaS admin) should be able to specify following (it is expected that a CSP will support these requirements as part of its hybrid Cloud service and expose relevant tenant facing service interfaces so that an enterprise can choose these features; the full definition of services and tenant facing interfaces is beyond the scope of this document; Readers may check seamless Cloud abstraction, model and interfaces [SHCA] ):
The multitenant isolation will isolate both the data plane traffic and control plane elements, such as routing/forwarding/switching table instances.
Figure 1 shows an example of full view of a network and Cloud. An example of an SHC (as viewed by a tenant) is shown in Figure 2.
-------------------------
| O ONPR-DB O Other | T1 Site 1 FIGURE 1
| | | Resources|
| O FW ------- |
| | | HSW: Hypervisor Switch
| O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall
| | | ER: Edge Router, CE: Customer Edge
| O FW O ONPR- | VM: Virtual Machine, PE: Provider Edge
| | | App-D-0 |
| O ONPR-DMZ | |
| | | | T2 Site 1 T1 Site 5 T1 Site 7
|---------------------- | ------------- ------------- ------------
| Tenant DC Network | | | | | | | | | | |
|---------------------- | | | | | | | | | |
| | | | | | | | | | | |
|----O CE11-------------| |--O CE21---| |--O CE15---| |--O CE17--|
| | | |
------------------------- -----------------
| |
O PE-TS1------------------------------O PE-TS2
| SP Private (IP/MPLS) MAN/WAN |
CSP O PE-CL1------------------------------O PE-CL2 CSP
DC-Loc1 | | DC-Loc2
|-------------O ER-CL1-------------------| |--------O ER-CL2--------|
| | | | | |
| ------------------------- | | ---------------------- |
| | CSP DC 1 Core/Aggr | | | |CSP DC 2 Core/Aggr | |
| ---------O Access SW1---- | | ------O Access SW2---| |
| | | | | \ |
| ------------|----------- | | | \ |
| | | | | | \ |
| ---O HSW 1 ---------- O HSW 2 | | HSW 3 O O HSW 4 |
| | | | | | | | | |
| | | | | | | | | |
| | O VFW | | | | O VFW | |
| | | T11 | | | | | T12 | |
| --------- ---------- ---- ------ | | ----------- --------- |
| | | | | | | | | | | | |
| O ... O O ... O O ... O ... | | O ... O O ... |
| T1 T1 T1 T1 T2 T1 | | T1 T1 T1 |
| VM11 VM12 VM13 VM14 VM21 VM15 | | VM16 VM17 VM18 |
| OFPR- OFPR- OFPR- | | OFPR- OFPR- |
| DMZ1 App1-1 App-D-1| | App1-2 App-D-2|
------------------------------------------ --------------------------
-------------------------
| O ONPR-DB | T1 Site 1 FIGURE 2
| | |
| O FW |
| | | HSW: Hypervisor Switch
| O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall
| | | SHC Cloud Abstractions:
| O FW O ONPR- | ST: Site VST: Virtual Site
| | | App-D-0 | CDCL: Cloud DC Location
| O ONPR-DMZ | |
| | | | T1 Site 7
|---------------------- | ------------
| | | | | |
|---------------------- | | | |
| | | | | |
|----O ST11-------------| |--O ST17--|
| |
|--------- ---------
| |
O-------------------------------------O
| T1-SHC-1 |
CSP O-------------------------------------O CSP
DC-Loc1 | | DC-Loc2
|-------------O CDCL1---------------------| |--------O CDCL2--------|
| / | | | |
| / | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| VST- O ------------ | | VST- O -------- |
| T11 / | | | | T12 | | |
| / | | | | | | |
| | O VFW | | | O VFW | |
| | | T11 | | | | T12 | |
| ------ -------- ---- | | ----------- ---------|
| | | | | | | | | |
| O ... O ... O ... | | O ... O O ... |
| T1 T1 T1 | | T1 T1 T1 |
| VM11 VM13 VM15 | | VM16 VM17 VM18 |
| OFPR- OFPR- OFPR- | | OFPR- OFPR- |
| DMZ1 App1-1 App-D-1 | | App1-2 App-D-2|
------------------------------------------ --------------------------
The realization mechanism described in this document is based on the assumption that the CSP not only owns or operates the public Cloud DCs, but also owns or operates the private IP/MPLS MAN/WAN connecting tenant sites and the CSP DCs (note that with proper framework or interfaces in place this restriction can be lifted). We outline a framework for supporting inter-SHC isolation (multitenant isolation), intra SHC isolation ( reachability rules between SHC components) and inter-SHC connectivity (akin to extranet), which is as follows (note that the realization framework covers only the MAN/WAN segment of the E2E network of an SHC):
We provide two use cases to explain the framework.
This use case shows creation of a flexible logical hybrid Cloud or SHC by selectively associating ONPR, OFPR and enterprise sites with the SHC. It also shows intra-SHC direct reachability.
Referring to Figure 1, a tenant T1 creates an SHC T1-SHC-1 and associates following components to the SHC:
The realization of T1-SHC-1 is as follows:
This use case shows the case of inter-SHC connectivity, where two SHCs are connected in a controlled way. In this use case tenant at the Site 7 accesses App1 instances located on-premises in T1 Site 1 via load balancing through ONPR-DMZ or OFPR-DMZ1. Site 7 is associated with a (dedicated) SHC T1-SHC-7 and App1, DB and DMZ resources are grouped into a second SHC T1-SHC-2.
Referring to Figure 3, a tenant T1 creates an SHC T1-SHC-7 and associates following components to the SHC:
The realization of T1-SHC-7 is as follows:
Referring to Figure 3, a tenant T1 creates an SHC T1-SHC-2, allows connectivity to T1-SHC-7, and associates following components to the SHC:
The realization of T1-SHC-2 is as follows:
-------------------------
| O ONPR-DB | T1 Site 1 FIGURE 3
| | |
| O FW |
| | | HSW: Hypervisor Switch
| O ONPR-App1-0 | VLB/FW: Virtual Load-balancer/Firewall
| | |
| O FW |
| | |
| O ONPR-DMZ |
| | | T1 Site 7
|---------------------- | ------------
|| | | | | |
|---------------------- | | | |
| | | | | |
|----O CE11-------------| |--O CE17--|
| |
------------------------- -----------------
| |
O PE-TS1------------------------------O PE-TS2
| SP Private (IP/MPLS) MAN/WAN |
CSP O PE-CL1------------------------------O PE-CL2
DC-Loc1 |
|-------------O ER-CL1-------------------|
| | |
| ------------------------- |
| | CSP DC 1 Core/Aggr | |
| ---------O Access SW1---- |
| | |
| ------------| |
| | |
| ---O HSW 1 |
| | |
| | |
| | |
| | |
| --------- |
| | |
| O |
| T1 |
| VM11 |
| OFPR- |
| DMZ1 |
------------------------------------------
In this section we discuss various issues that needs future considerations.
The framework described in this document is a network management (NM) framework. Hence the framework can be used on any existing network without any changes. But NM frameworks typically are not built for on-demand operations, as required in a Cloud environment. As described above, creation or deletion of an SHC should result in creation or deletion of L3MV on-demand so that pay-per-use accounting are turned on or off on-demand. Similarly, association or disassociation of SHC components should result in creation or deletion and export or withdrawal of ECRT on-demand. Currently, these actions can be performed via on-demand application of configuration. But current network (CLI or even NetConf based) configuration/provisioning frameworks are cumbersome to use in an on-demand environment. Hence proper Cloud-ready NM framework and interfaces are needed.
In current L3MV the import of ECRT in respective L3MV VRF can only be done via (static) pre-configuration, which is not suitable in an on-demand Cloud environment. This process can be automated, if an L3MV is identified by a unique VPN ID and the information is carried in MP-BGP ECRT update messages.
As described above, the multitenant isolation (MTI) has to reach all the way to the OFPR. But currently E2E MTI (as required in a hybrid Cloud environment) can only be achieved by stitching together multiple isolation technologies (such as L3MV + VRF-Lite + VLAN or L3MV + VxLAN) with their own limitations. Homogenous E2E MTI technology is desirable. For example, L3MV all the way to a TOR switch (TS), where the TS can functions as a PE and the virtual access switches on hypervisors as L3MV multitenant CE. The L3MV technology handles the case of overlapping private IP addresses of multiple tenants. Hence bringing the technology all the way to the hypervisor will be useful.
Typical security considerations of L3MV configuration will apply. In an on-demand dynamic Cloud environment certain security issues may be amplified. For example, uncontrolled BGP updates as resources are CRUD very dynamically (by a rogue entity). The dynamic application of configuration may amplify the situation of mistaken route leaking from one SHC to another. Hence proper steps should be taken.
There is no IANA consideration.
We have discussed a framework for realizing inter-hybrid Cloud end-to-end multitenant isolation, intra-hybrid Cloud reachability and inter-Hybrid Cloud controlled connectivity. The framework allows creation of a logical hybrid Cloud, we call a seamless hybrid Cloud (SHC), consisting of tenant selected subset of enterprise sites, on-premises resources (resident in tenant network) and off-premises resources (acquired by the tenant on-demand in public Cloud DCs). An SHC is mapped to an L3 MPLS VPN (L3MV) to support inter-SHC multitenant isolation and SHC components are mapped to BGP extended community route targets (ECRT) so that route advertisements of SHC associated components can be controlled and isolated from any other Cloud or non-Cloud L3MV. The intra-SHC reachability and inter-SHC connectivity are also controlled via SHC-component to ECRT mapping and via proper import/export policies involving ECRTs. The framework is network management based allowing support of it on existing infrastructure. We have discussed few issues above (in the Discussion section), which should be addressed. We have not covered the cases A3-A5 discussed in the Introduction section, which also should be addressed.
| [RFC4364] | Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. |
| [RFC4360] | Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. |
| [NIST] | Mell, P and T Grance, "The NIST Definition of Cloud Computing", 800-145 NIST, September 2011. |
| [SHCA] | Hasan, M., Morrow, M., Tucker, L., Gudreddi, S. and S. Figueira, "SEAMLESS CLOUD ABSTRACTION, MODEL AND INTERFACES", In Proc. ITU/IEEE Kaleidoscope Conference, December 2011, Cape Town, South Africa, December 2011. |
| [VXLN] | M.Mahalingam, M. and et.al, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-00.txt, August 2011. |
| [RFC2685] | Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. |