Network Working Group K. Kumaki Internet-Draft T. Miyasaka Intended status: Informational KDDI Corporation Expires: November 30, 2014 May 29, 2014 ACTN : Use case for Multi Tenant VNO draft-kumaki-actn-multitenant-vno-00 Abstract This document provides a use case that addresses the need for facilitating virtual network operation: creation and operation of multi-tenant virtual networks that use the common core network resources. This will accelerate a rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. This use case addresses the aforementioned needs within a single operator network. Status of this Memo 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 November 30, 2014. Copyright Notice Copyright (c) 2014 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 Kumaki & Miyasaka Expires November 30, 2014 [Page 1] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Multi-tenant Virtual Network Consolidation . . . . . . . . . . 4 4.1. Service Consolidation . . . . . . . . . . . . . . . . . . . 5 4.2. VPN Service Consolidation . . . . . . . . . . . . . . . . . 5 4.3. Network Wholesale Service . . . . . . . . . . . . . . . . . 5 4.4. On-demand Network Service . . . . . . . . . . . . . . . . . 5 4.5. Redundant Network Service . . . . . . . . . . . . . . . . . 5 4.6. Mobile/LTE Access Service . . . . . . . . . . . . . . . . 6 5. Multi-tenant Virtual Network Operation Coordination . . . . . . 6 6. High-level Requirements for Multi-tenant Virtual Network Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Dynamic binding - On-demand Virtual Network Service Creation . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Domain Control Plane/Routing Layer Separation . . . . . . . 7 6.3. Separate Operation of Virtual Services . . . . . . . . . . 8 6.4. QoS/SLA . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.5. VN diversity . . . . . . . . . . . . . . . . . . . . . . . 8 6.6. Security Concerns . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informational References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Kumaki & Miyasaka Expires November 30, 2014 [Page 2] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 1. Introduction This document provides a use case that addresses the need for facilitating virtual network operation: creation and operation of multi-tenant virtual networks that use the common core network resources. This will accelerate a rapid service deployment of new services, including more dynamic and elastic services, and improve overall network operations and scaling of existing services. This use case supports Abstraction and Control of Transport Networks (ACTN). The aim of ACTN is to facilitate virtual network operation, creation of a virtualized environment allowing operators to view and control multi-subnet multi-technology networks into a single virtualized network. Related documents are: [I-D.leeking-actn-problem-statement] and [I-D.ceccarelli-actn-framework] which provide detailed information regarding this work. 2. Requirements Language 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]. 3. Motivation One of the main motivations for multi-tenant virtual networks that share the common core transport network resource is to increase the network utilization of the core transport network. As each service network has evolved in a different time with different service needs, many dedicated overlay networks have formed to support different service needs. This results in an inefficient use of network resources and the complexity in operating such diverse service networks. Due to the lack of the coordination across different service networks and the common service platform, the introduction of new services is not as speedy as the operators' desire. Part of the reasons for this difficulty is due to the lack of the virtual network infrastructure. Figure 1 shows an illustration of the current multiple service network architecture. Kumaki & Miyasaka Expires November 30, 2014 [Page 3] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 +-----------+ +-----------+ | Service A | | Service A | | Network |\ /| Network | | | \ / | | +-----------+ \+-------------------------+/ +-----------+ | | +-----------+ | Core Transport | +-----------+ | Service B | | Network | | Service B | | Network |---| |---| Network | | | | | | | +-----------+ | | +-----------+ +-------------------------+ +-----------+ / \ +-----------+ | Service C | / \ | Service C | | Network |/ \| Network | | | | | +-----------+ +-----------+ Figure 1: Multiple Services Network Architecture The characteristics of the multiple services network are as follows: o Each service has its own dedicated access points (e.g., PE routers) in the core network. o Each service or a group of services may be operated in a different service operations department within an operator. For instance, the VPN service and the mobile service may be operated by two different departments while whole sale Internet service by another department. o There may be dedicated core transport network resources for some services to ensure a strict service guarantee. o There may be little or no coordination for operating multiple services in terms of network resource allocation or sharing of the resources. 4. Multi-tenant Virtual Network Consolidation This section discusses key aspects to support multi-tenant virtual network consolidation. Kumaki & Miyasaka Expires November 30, 2014 [Page 4] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 4.1. Service Consolidation Multi-tenant virtual network operation should support different services as the tenants that share the common core transport network resources. Therefore, it is important to understand the type of various services and its service requirement. 4.2. VPN Service Consolidation Network providers have many different service networks such as VPNs of various types and different QoS requirements. Within VPNs, there are several QoS levels. Some VPN is best-effort VPN while other VPNs require a strict QoS such as bandwidth guarantee and latency. Therefore, multi-level VPNs should be supported in multi-tenant virtual network consolidation. 4.3. Network Wholesale Service Network providers want to provide a network resource (i.e. a network slice) to ISPs. In this case, the network provider must guarantee the SLA to each ISP. There may be different level of SLA as well as different level of virtual network granularity for each ISP. The ISP should be given its virtual network(s) as well as an independent domain control of allocated virtual network(s). It is also to be noted that there may be different grade of services required depending on the nature of the whole sale. For instance, CATV operator may require a different grade of service than best-effort internet services. Therefore, multi-level wholesale services should be supported in multi-tenant virtual network consolidation. Also, network providers should not provide unnecessary network information (e.g. TE database and IGP information in core transport network) to ISPs. To provide unnecessary information in core transport network poses security issues. Therefore, network providers should provide only necessary network information to create ISP's virtual network. 4.4. On-demand Network Service Some ISPs may need a network resource (i.e. a network slice) during the specific time and period. This is referred to as on-demand network service. This implies that virtual networks should be created/deleted dynamically and the resources (e.g. bandwidth) of virtual networks should be added/decreased dynamically. 4.5. Redundant Network Service Some service requires a number of redundant network paths that are physically diverse from one another. This implies that the virtual networks should indicate link and node diversity constraints. Kumaki & Miyasaka Expires November 30, 2014 [Page 5] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 4.6. Mobile/LTE Access Service Consumer mobile/LTE access can be a tenant that shares the resources of the core transport network. In such case, a strict latency with a guaranteed bandwidth should be supported by multi-tenant virtual network operation. 5. Multi-tenant Virtual Network Operation Coordination The following Figure 2 depicts a functional control architecture that shows the need to support virtual networks to a number of different service networks that share the common core network resources. +-----------------+ | Multi-tenant | | VN Coordination | +-----------+ +-----------------+ +-----------+ | Service A |-+ | | | | Service A |-+ | Control |B|-+ | | | | Control |B|-+ +-----------+ |C|---------| | |---------+-----------+ |C| +-----------+ | | +-----------+ | +-----------+ +---------------+ +-----------+ |Core Transport | /------\ |Network Control| /------\ // \\ +---------------+ // \\ | Service A | | | Service A | \\ // ---------- /\ // ------ \ //// \\\\ / ------ /------\ \|| ||/ /------\ // \\ | Core Transport | // \\ | Service B |----| |----| Service B | \\ // || Network || \\ // \------/ \\\\ //// \------/ /------\ / ---------- \ /------\ // \\ / \ // \\ | Service C | \| Service C | \\ // \\ // ------ ------ Figure 2: Multi-tenant control architecture There are a few characteristics of the above architecture. Kumaki & Miyasaka Expires November 30, 2014 [Page 6] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 1. The core transport network is the common transport network resource pool for a number of multiple tenants, which is referred to as network tenancy. 2. Each service is a client to the common transport network. 3. Each service should be guaranteed its operational independence from other services. The separation of service control (depicted as separate boxes) in the above figure represents an operational independence. 4. The virtual network for each service is created and assigned by the multi-tenant virtual network coordination function. This is a functional entity that communicates with each service control and the core transport network control/management entities in order to coordinate with the necessary communication. 5. Each service instantiates its service instance based on its virtual network. 6. Each service is in control of its virtual network and operates on the virtual network. 7. As a number of services carried on the common transport network sharing a common network resource, operational independence for each service has to be guaranteed as if each service owns its dedicated resources. 8. The level of abstraction of a virtual network is determined by each service and may differ from one another. In some cases, a virtual network should represent a graph form of topology abstraction of the virtual network. 6. High-level Requirements for Multi-tenant Virtual Network Operations Based on the discussion in the previous sections, this section provides the overall requirements that must be supported. 6.1. Dynamic binding - On-demand Virtual Network Service Creation The solution needs to provide the ability to create a new virtual network on demand. The virtual network should be built dynamically. 6.2. Domain Control Plane/Routing Layer Separation The solution needs to support an independent control plane for a domain service control. This implies that each service domain has Kumaki & Miyasaka Expires November 30, 2014 [Page 7] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 its own VN control scheme that is independent of other domain or the core transport network control. 6.3. Separate Operation of Virtual Services The solution needs to support an independent operation of a virtual network and a service. Each Service Administrators should be able to control and manage its virtual network in terms of policy and resource allocation (e.g., CPU, Memory, other resources.) In addition, the virtualized networks should not affect each other in any way. 6.4. QoS/SLA The solution needs to provide an independent QoS/SLA per a virtual network depending on a service level. Each QoS on the virtual network should support multiple service levels. Each SLA on the virtual network should fulfill a bandwidth and a latency required by each service. 6.5. VN diversity Each service should be able to create multiple diverse VNs for the diversity purpose. The diversity for VNs must be physically diverse in the core transport network. This implies that the core transport network control/management plane must be able to factor the SRLG information when creating multiple VNs to ensure VN diversity. 6.6. Security Concerns The solution needs to keep the confidentiality between the services. A service should not have the connectivity to an another service through the common core transport network. 7. Acknowledgments The authors wish to thank Young Lee for the discussions in the document. 8. IANA Considerations 9. Security Considerations 10. References Kumaki & Miyasaka Expires November 30, 2014 [Page 8] Internet-Draft ACTN : Use case for Multi Tenant VNO May 2014 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informational References [I-D.ceccarelli-actn-framework] Ceccarelli, D., Fang, L., Lee, Y., and D. Lopez, "Framework for Abstraction and Control of Transport Networks", draft-ceccarelli-actn-framework-01 (work in progress), February 2014. [I-D.leeking-actn-problem-statement] Lee, Y., King, D., Boucadair, M., and R. Jing, "Problem Statement for Abstraction and Control of Transport Networks", draft-leeking-actn-problem-statement-01 (work in progress), February 2014. Authors' Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 Japan Email: ke-kumaki@kddi.com Takuya Miyasaka KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 Japan Email: ta-miyasaka@kddi.com Kumaki & Miyasaka Expires November 30, 2014 [Page 9]