[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/