Internet DRAFT - draft-kumaki-actn-multitenant-vno
draft-kumaki-actn-multitenant-vno
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]
