Internet DRAFT - draft-kumaki-teas-actn-multitenant-vno
draft-kumaki-teas-actn-multitenant-vno
Network Working Group K. Kumaki
Internet-Draft T. Miyasaka
Intended status: Informational KDDI Corporation
Expires: January 7, 2016 July 6, 2015
ACTN : Use case for Multi Tenant VNO
draft-kumaki-teas-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 January 7, 2016.
Copyright Notice
Copyright (c) 2015 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 January 7, 2016 [Page 1]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
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 . . . . . . . . . . . . . . . . . . 4
4.2. VPN Service Consolidation . . . . . . . . . . . . . . . . 5
4.3. Network Wholesale Service . . . . . . . . . . . . . . . . 5
4.4. On-demand Network Service . . . . . . . . . . . . . . . . 5
4.5. Redundant Network Service . . . . . . . . . . . . . . . . 6
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 . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informational References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Kumaki & Miyasaka Expires January 7, 2016 [Page 2]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
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.
Generally, carrier's core network consists of multi-domain networks.
For instance, a network may have multiple confederation ASes that
have each own IGP network using IS-IS or OSPF. In other instance, a
network may consist of multiple vendor's optical transport networks
that have each own Network Management System (NMS). In such a
carrier's multi-domain core network, it is difficult to create an
end-to-end virtual network that meets customer's requirements (e.g.
topology, AS, bandwidth, delay and jitter).
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-teas-actn-problem-statement] and
[I-D.ceccarelli-teas-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 January 7, 2016 [Page 3]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
+-----------+ +-----------+
| 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.
4.1. Service Consolidation
Multi-tenant virtual network operation should support different
services as the tenants that share the common core transport network
Kumaki & Miyasaka Expires January 7, 2016 [Page 4]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
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. Generally, ISPs have each own ASes and they do not
want to change their own network policy. We can deploy these network
wholesale services by using "carrier's carrier" in [RFC4364].
However, ISPs need to change their network policy and run LDP at an
edge router at ISP's edge routers although just IP is running on
their original network. Additionally, they (i.e. network architects
at ISPs) need to transfer MPLS knowledge to their network operators.
In another aspect, 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.
Kumaki & Miyasaka Expires January 7, 2016 [Page 5]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
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.
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 |-+ | |
| Control |B|-+ | |
+-----------+ |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
Kumaki & Miyasaka Expires January 7, 2016 [Page 6]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
There are a few characteristics of the above architecture.
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 virtual 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.
Kumaki & Miyasaka Expires January 7, 2016 [Page 7]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
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
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 and Dhruv Dhody for the
discussions in the document.
8. IANA Considerations
Kumaki & Miyasaka Expires January 7, 2016 [Page 8]
Internet-Draft ACTN : Use case for Multi Tenant VNO July 2015
9. Security Considerations
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
10.2. Informational References
[I-D.ceccarelli-teas-actn-framework]
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Transport Networks", draft-ceccarelli-teas-
actn-framework-00 (work in progress), June 2015.
[I-D.leeking-teas-actn-problem-statement]
Lee, Y., King, D., Boucadair, M., Jing, R., and L.
Contreras, "Problem Statement for Abstraction and Control
of Transport Networks", draft-leeking-teas-actn-problem-
statement-00 (work in progress), June 2015.
Authors' Addresses
Kenji Kumaki
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: ke-kumaki@kddi.com
Takuya Miyasaka
KDDI Corporation
1-20-1 Nishishinjuku
Shinjuku-ku, Tokyo 160-0023
Japan
Email: ta-miyasaka@kddi.com
Kumaki & Miyasaka Expires January 7, 2016 [Page 9]
