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

Versions: 00

Network Working Group                                            L. Deng
Internet-Draft                                              China Mobile
Intended status: Informational                                   H. Song
Expires: December 6, 2014                                         Huawei
                                                             G. Karagian
                                                            U. of Twente
                                                           E. Haleplidis
                                                            U. of Patras
                                                              B. Martini
                                                                    CNIT
                                                            June 4, 2014


                NFV configuration north bound use cases
                   draft-deng-nfvcon-nb-use-cases-00

Abstract

   This specification lists some classical use cases of NFV
   configuration, especially those related to the north bound operation
   with the involvement of network function provider and the network
   function consumers, for example VNF installation, migration,
   replication, on-demand resource allocation and etc.. These use cases
   are only relative to the virtualization characteristics of network
   functions.  These use cases will be used to identify the proper
   standard space and scope for the NFV configuration.

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 December 6, 2014.








Deng, et al.            Expires December 6, 2014                [Page 1]


Internet-Draft                nb use cases                     June 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
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  VNF store: NSP's app store for VNFs . . . . . . . . . . .   5
     3.2.  VNF as a Service (VNFaaS): configuration and management .   5
     3.3.  VNF as a Platform (VNFaaP): configuration and management    7
     3.4.  VNF migration: travel with your NSP "devices" . . . . . .   9
     3.5.  VNF installation: customizing personal VNFs . . . . . . .  10
     3.6.  VNF template: common profile for managing multiple VNF
           instances . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.7.  Dynamic resource usage  . . . . . . . . . . . . . . . . .  11
     3.8.  Service Function Chaining . . . . . . . . . . . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document describes the typical use cases for NFV (Network
   Function Virtualization) configuration and management.  Based on the
   Network Function Configuration Architecture, see VNF configuration
   architecture [I-D.zhou-opsawg-vnf-config-arch], four key roles can be
   identified in these use cases, (1), the network function provider,
   (2) network service provider, (3), the network function consumer,
   (4), the NFV control plane, (5), the NFV infrastructure, see
   Figure 1.





Deng, et al.            Expires December 6, 2014                [Page 2]


Internet-Draft                nb use cases                     June 2014


   Network function providers provide the network function software and
   related description information that are necessary for the network
   function consumer to know.  Network function providers are
   responsible for the lifecycle management of the network functions,
   for example, on-shelf, updates, and delete.

   Network function consumers are those who use the network functions
   deployed inside the network service provider, i.e.  NSP's network.
   The network function consumers can be the home user, the enterprise
   user or the NSP.  Home user and enterprise user can directly manage
   their network functions such like virtual firewall or virtual
   residential gateway in the provider's network.  But NSPs can also be
   the user of network functions, for example, carrier grade NAT.

  +----------------+   +----------------+   +----------------+
  |Network Function|   |Network Function|   |Network Service |
  |   Provider     |   |Consumer        |   |                |
  +----------------+   +-------+--------+   +----------------+
                --             |                  --
                  --           |                --
                    --         |             ---
                      --       |          ---
                        --     |        --
                          --   |     ---
                            -- |   --
                +--------------------------------+
                |NFV Control and Management Plane|
                +--------------------------------+
                               |
                               |
                               |
           +-------------------+---------------------+
           | NFV Infrastructure                      |
           |+----------+    +---------+   +--------+ |
           || Computing|    | Storage |   | Network| |
           |+----------+    +---------+   +--------+ |
           +-----------------------------------------+



            Figure 1 Key roles used in use cases
    (Note: this architecture will be mapped to the published ETSI NFV architecture)

   There are many issues that the NFV control plane may be involved in,
   and it is assumed that the existing standard protocols have already
   solved the physical network functions' management and operation
   problems (despite the fact that they have not), but they have not
   solved the new problems introduced by the virtualization of network



Deng, et al.            Expires December 6, 2014                [Page 3]


Internet-Draft                nb use cases                     June 2014


   functions, for example, the virtualization network function
   installation, the dynamic lifecycle management, the dynamic
   migration, the revocable of a particular network function.  In this
   document, only those use cases relative to the new problems will be
   introduced.

2.  Terminology

   Note: The following terms used in this document will be aligned with
   their definitions from ETSI GS NFV 003[ETSI_GS_NFV_003] . (Note: It
   will aovid confusion of different terms.  But what about the
   copyright issue? or there is no copyright issue?)

   Network Function Provider: a Network Function Provider (NFP) provides
   virtual network function software.

   Network Service Provider (NSP): a company or organization, that
   provides a network service on a commercial basis to third parties.  A
   network service is a composition of network functions and defined by
   its functional and behavior specification.  The NSP operates the NFV
   Control Plane.

   Network Function Consumer: a Network Function Consumer (NFC) is the
   consumer of virtual network functions.  It can be either an
   individual user, home user or the enterprise user.

   Virtual Network Function: an implementation of an executable software
   program that constitutes the whole or a part of a network function
   that can be deployed on a virtualization infrastructure.

   Physical Network Function: a physical network function indicates a
   physical appliance of functional building block within an operator's
   network infrastructure, which has well-defined external interfaces
   and a well-defined functional behavior.

   NFV Infrastructure: NFV Infrastructure indicates the computing,
   storage and network resources to implement the virtual network
   function.  High performance acceleration platform is also part of it.

   NFV Control and Management Plane: a NFV Control and Management Plane
   is operated by a NSP and orchestrates the NFV Infrastructure to
   provide NFV service to NFC.

3.  Use Cases







Deng, et al.            Expires December 6, 2014                [Page 4]


Internet-Draft                nb use cases                     June 2014


3.1.  VNF store: NSP's app store for VNFs

   By the decoupling between the software implementation and hardware
   platform of network devices enabled by virtualization technology, it
   is envisioned that various functional components of consumer/network
   devices (e.g. gateway, firewall, IDS, WAN acceleration), which are
   traditionally provided by the local NSP/ third party device
   manufactures in the form of dedicated hardware boxes, can be deployed
   into a virtual machine within the local NSP's data center as a piece
   of software instance (i.e. virtual network function or VNF).

   By setting up an VNF store, an NSP operated application store
   dedicated for various VNFs, the local NSP would be able to provide a
   much convenient way for its users (both enterprise and individual
   consumers) to search for, learn more about, compare between and make
   purchase for specific NSP VNFs according to its personalized needs,
   and a more convenient way for the network function providers to
   provide their software package.  Please note that a NSP itself can be
   the customer of the VNF store.  The main motivation for a NSP to
   become the customer is for its transparent service to its
   subscribers, for example, traffic optimization, carrier grade NAT and
   etc.

   (Note: the authors will add the list of what should be done in the
   context of NFVCon.)

3.2.  VNF as a Service (VNFaaS): configuration and management

   This use case is based on Use case #2: Virtual Network Function as a
   Service (VNFaaS) described in ETSI GS NFV 001[ETSI_GS_NFV_001] . This
   use case focuses on the configuration of a virtualized enterprise
   service, where the VNF is the NSP's application and the enterprise
   user is the consumer of this service.  By making the VNF
   functionality available to enterprise users as a service is
   comparable to the cloud computing concept denoted as the Software as
   a Service (SaaS).  According to NIST SP 800-146 [NIST_SP_800-146]
   SaaS is the possibility for the consumer to use software applications
   running on a cloud infrastructure.  The consumer, however, cannot
   manage the application only from a configuration perspective and
   cannot control the underlying infrastructure.

   The main motivation of specifying such virtualized enterprise service
   is that rather than that enterprise users invest their own capital in
   deployment of networking infrastructure, the NSP may be able to
   provide advanced networking features as a measured service on an
   expense basis.





Deng, et al.            Expires December 6, 2014                [Page 5]


Internet-Draft                nb use cases                     June 2014


   Several examples of VNFaaS are provided in ETSI GS NFV
   001[ETSI_GS_NFV_001].  For example, in use case #2: Virtual Network
   Function as a Service (VNFaaS), the VNFaaS is related to the services
   that are deployed by enterprise users at the edge of branch offices.
   Due to the fact that the enterprise users are faced with big required
   investments, such enterprise users are looking for outsource
   alternatives, which can be the virtualization of the enterprise CPE
   (e.g., VFN of an access router) into the NSP's network.  In this
   example the used VNFs are the virtualized CPE and PE (Provider
   Equiment).  In use case #5: Virtualization of Mobile Core and IMS (IP
   Multimedia Subsystem), the VNFaaS is related to services that are
   related to the virtualization of the EPC (Evolved Packet Core).  The
   EPC and IMS are standardized by the 3GPP standardization body.  In
   this example the VNFs are the network entities supported by the EPC,
   such as the MME (Mobility Management Entity), P-GW (Packet Data
   Network Gateway), S-GW (Serving Gateway), Home Subscriber System
   (HSS).  In this example the VNFaaS is the EPCaaS.

   Both that VNFaaS provider and enterprise consumer share the
   responsibility for the management of the VNFaaS.  The NSP is
   responsible for the lifecycle management of the VNFaaS instances to
   provide the expected service level (SLA) for the subscribers to the
   VNFaaS.  The VNFaaS lifecycle management is similar to the cloud
   lifecycle management steps.  In particular, the EU FP7 project Mobile
   Cloud Networking (MCN) [MCN], defined the following lifecycle
   management steps that can also be applied for the VNFaaS lifecycle
   management:

      o Design: at this stage the service's technical design is carried
      out.

      o Implement: with a service design the service is implemented.

      o Deploy and provision: The VNF management is deployed and the
      necessary service instances are starting to be created. o

      o Runtime and Operation: the created VNF and service instances for
      each tenant are monitored and managed.  It is during this step
      where scaling in and out of VFNs is carried out.  Scaling in
      occurs when a VFN is releasing resources and scaling out occurs
      when new resources are allocated to a VFN.

      o Disposal: the VFNs associated with a service instance are
      disposed.

   The enterprise users expect to manage and configure their customer
   premises entities.




Deng, et al.            Expires December 6, 2014                [Page 6]


Internet-Draft                nb use cases                     June 2014


   The NFVcon can focus on providing the interfaces and protocols
   required by the network function provider, network service provider
   and the network function consumer to configure and manage the VNFaaS.

   Some challenges that need to be solved are:

      o Appropriate authentication and authorization mechanism are
      required to support the orchestration of VNF instances.  For
      example only authorized VNF instances are permitted to execute on
      the NFVI.  Moreover, mechanisms should be provided such that VNF
      instances can only access the physical and virtual terminations to
      which their access is authorized.

      o A virtualized environment needs to guarantee complete isolation
      among the network function consumers.  Special considerations are
      needed for protecting network function consumer data and
      configuration files.

      o By providing a VNFaaS as a measured service requires usage
      measurement metrics and infrastructure appropriate to the type of
      VNF as well as appropriate Service Level Agreements.  VNFaaS usage
      measurements need the appropriately auditable accounting treatment
      to be used as basis for service billing arrangements.

      o Resource scaling: scaling up and down network resources used by
      VNFs

      o Service awareness: service aware resource allocation to network
      functions

      o State maintenance: Network and network function state management
      during network function relocation, replication and resource
      scaling

      o Appropriate mechanism for monitoring/fault detection/diagnosis
      of all components and their states after virtualization, e.g., VNF
      instances, hardware, hypervisor

      o Traffic control separation mechanism: Data and management
      traffic identification/separation for non-virtualized and
      virtualized networks.

3.3.  VNF as a Platform (VNFaaP): configuration and management

   This use case is based on Use case #3: Virtual Network Platfom as a
   Service (VNPaaS) described in ETSI GS NFV 001[ETSI_GS_NFV_001].  This
   use case focuses on the configuration of a virtualized network
   platform, where a network service provider makes available a suite of



Deng, et al.            Expires December 6, 2014                [Page 7]


Internet-Draft                nb use cases                     June 2014


   infrastructure and applications as a platform on which the enterprise
   users can deploy their own network applications.  By using this
   platform, the enterprise users could develop their own network
   service that is customized to their business purposes.

   Making the VNF platform available to enterprise users as a service is
   comparable to the cloud computing concept as a Platform as a Service
   (PaaS), which is defined in NIST SP 800-146 [NIST_SP_800-146] as
   follows.  PaaS is the possibility for the consumer to use software
   applications running on a cloud infrastructure.  The consumer can
   control the deployed application, but it cannot control the
   underlying network or the cloud infrastructure (i.e., the NFVI).

   In this use case the NSP provides a toolkit of (1) networking and
   computing infrastructure and (2) potentially some VNFs as a platform,
   for the creation of a virtual network, denoted as Virtual Network
   Platform as a Service (VNPaaS).  The enterprise consumer uses this
   toolkit to develop its own virtual network.

   The VNPaaS is similar to VNFaaS, but it differs mainly on the scope
   of control provided to the consumer of the service.  The VNPaaS is
   able to provide a larger scale service, which typically will be the
   provision of a virtual network rather than a single virtual network
   function.  In particular, the VNFaaS is limited to the configuration
   of a set of VNF instances made available by the NSP, while the VNPaaS
   provides the possibility to the enterprise consumer to introduce
   their own VNF instances as well.

   Several types of services can be supported by a VNPaaS, ranging from
   a simple firewall service for a single enterprise to a whole business
   communication suite based on an IMS network for a 3rd party.

   The NFVcon can focus on providing the interfaces and protocols
   required by the network function provider, network service provider
   and the network function consumer to configure and manage the VNPaaS.

   In addition to the VNFaaS challenges listed in Section 3.3, some
   additional challenges need to solved:

      o Access control should be based on an authorized user identity

      o Infrastructure resources need to provide mechanisms to separate
      workloads from different network service providers.

      o Infrastructure resources and network functions support an
      interface used to monitor, guarantee and limit the usage of the
      resources by each network service provider.




Deng, et al.            Expires December 6, 2014                [Page 8]


Internet-Draft                nb use cases                     June 2014


3.4.  VNF migration: travel with your NSP "devices"

   A travelling consumer's experience would be highly improved if he/she
   found that all their subscribed network devices are also travelling
   with them automatically/on demand.  The portability of VNF-based NSP
   services is based on VNF migration within the local NSP's data
   centers or even across different NSPs' domains.

      +----------------+    2.vRGW is migrated to a +----------------+
      | Haibin's vRGW  +---------------------------->  Haibin's vRGW |
      +--------+-------+    data center in Shenzhen +--------+-------+
               |                                             |
               |                                             |
      Previous |                                             |
               |                                             | Now
               |                                             |
               |                                             |
               |                                             |
           +---+--+    1.Haibin left Nanjing             +---+--+
           |Haibin+------------------------------------->|Haibin|
           +------+      and moved to Shenzhen           +------+

           Nanjing                                       Shenzhen


                 Figure 2. VNF migration

   As shown in Figure 2, while Haibin moves from Nanjing to Shenzhen,
   his virtual residential gateway (including DHCP, firewall and ALG
   functions and etc) is also migrated from Nanjing to Shenzhen.  This
   kind of migration, when compared with the dedicated hardware box
   residential gateway, can improve the user's experience as he did not
   lose any data or configuration.

   Usually it has the following features:

      o It allows a network function consumer to do migration
      configuration/subscription for a given VNF;

      o It allows the local NSP to detect the movement of a travelling
      consumer and trigger subsequent VNF migration accordingly;

      o It provides robust authentication mechanism for a roaming user
      to access a migrated VNF;

      o It provides clearly stated resource requirement for
      accommodating a migrated VNF in a visiting datacenter/NSP domain,
      and provide reliable resource/performance splicing for a migrated



Deng, et al.            Expires December 6, 2014                [Page 9]


Internet-Draft                nb use cases                     June 2014


      VNF against local abuse from bugs/holes in third party developed
      software.  This may not be visible to the NFC, but the SLA will be
      met during and after the migration.

3.5.  VNF installation: customizing personal VNFs

   A NSC may want to customize its VNF instance, to specialize its
   installation of functional building blocks, with regarding to its own
   requirements from traffic pattern, service preference, and security/
   privacy sensitivity.

   Take traffic pattern for example, if there is a VNF for censoring the
   traffic, if the traffic sent to this VNF are video packets, then the
   NSC may want to install a video censoring function block, e.g. for
   pornography.  If the traffic sent to the VNF is text packets then the
   user may want to install a text censoring function block.  If the
   traffic is a combination of video and text, then the NSC may need to
   install another functional block for classification.  NFCs do not
   need to install unnecessary function blocks on their own VNFs.

   There are also considerations from security or privacy aspects.  A
   website's owner has much more concerns on security protection than an
   individual subscriber, while a habitual on-line shopper cares much
   more on privacy protection than a webpage visitor.  This also brings
   different components to be installed on the NFC's VNF.

   Deployment position considerations can be another advantage of
   virtualization.

   The difference between this VNF installation and the traditional
   dedicated hardware physical network function appliance is that a NFC
   can customize his VNF and the position of the VNF, and make the VNF
   run immediately after his requirements are sent to the NFV control
   plane.

   (Note: the authors will add the list of what should be done in the
   context of NFVCon.)

3.6.  VNF template: common profile for managing multiple VNF instances

   For enterprise scenario, it is often the case that an IT personnel is
   responsible for setting up the network access environments for a
   potentially quite large number of individual employees.  Although
   there maybe variations among employees' requirements and entitlements
   according to their roles and ranks in the organizational hierarchy,
   it is expected that by predefining some general applicable VNF
   templates to capture the common demand for a group and allowing the
   consumer to apply them to multiple VNF instances simultaneously with



Deng, et al.            Expires December 6, 2014               [Page 10]


Internet-Draft                nb use cases                     June 2014


   a simple command/interface, the management cost would be greatly
   reduced.  This kind of VNF includes the virtual firewall.

   If there are some exactly same VNFs, the NFV control and management
   plane (1) can map the same configuration to multiple replicas,
   without that the NFC needs to know the position of the VNFs, and (2)
   operates them individually.

   This use case has the following features:

      o It allows pre-defined template for VNF configuration;

      o It allows for template-based VNF group management.

   (Note: the authors will add the list of what should be done in the
   context of NFVCon.)

3.7.  Dynamic resource usage

   Network function customers may have demand for automatic scale out
   and scale in for resource usage, and pay for the amount of resource
   it has used.  This is extremely useful when the NFC cannot predict
   his resource usage or the resource usage is not stable.  For example,
   one enterprise user as a NFC may have much traffic processing load on
   its VNF(s) during the daytime, but in the night, the NFC does not
   have any load on its VNF(s).  Automatic scale out and scale in can be
   implemented in different ways, such like automatically generating/
   deleting new VNF instances while monitoring the load status.

   This use case may require the NFC and the NFV control and management
   plane to negotiate the policy of it.

3.8.  Service Function Chaining

   For service function chains, NFC tells the NFV control and management
   plane about the specific service processing order, to make specific
   traffic go through that order.  The service functions can be inside
   one VNF, different VNFs in one physical server or different VNFs in
   different physical servers.  The description from the NFC to the NFV
   control and management plane may include the traffic classification
   rules, and the service chaining order, and other relative policies.
   The control and management plane can be agnostic of the service
   chaining logic, but must be able to pass the right chain description/
   policy to the right VNF.







Deng, et al.            Expires December 6, 2014               [Page 11]


Internet-Draft                nb use cases                     June 2014


4.  Security Considerations

   Network function virtualization may make attacks easier, when using
   standard IT method to normalize the dedicated network function
   appliances, and make it easily accessed by the consumers.  In
   particular, the following security considerations need to be taken
   into account:

      o Access control should be based on an authorized user identity

      o Provide robust authentication mechanism for a roaming user to
      access a migrated VNF

      o Appropriate authentication and authorization mechanism are
      required to support the orchestration of VNF instances.  For
      example only authorized VNF instances are permitted to execute on
      the NFVI.  Moreover, mechanisms should be provided such that VNF
      instances can only access the physical and virtual terminations to
      which their access is authorized.

      o A virtualized environment needs to guarantee complete isolation
      among the network function consumers.  Special considerations are
      needed for protecting network function consumer data and
      configuration files.

5.  Acknowledgement

   Thanks to Diego Lopez for his valuable comments to this document.
   And thanks to the people who joined the succesful side meeting
   discussion, some of the ideas are from the discussion.  The main
   people are: Diego Lopez, Mehmet Ersue, Melinda Shore, Juergen
   Schoenwaelder, Jiang Yuanlong, Cathy Zhou, Zhen Cao,Hui Deng,
   Georgios Karagian, Evangelos Haleplidis, Deng Lingli, Kostas
   Pentikousis, Michael Scharf.

6.  References

6.1.  Normative References

   [I-D.zhou-opsawg-vnf-config-arch]
              Zhou, H., Song, H., and F. Qiao, "Virtual Network Function
              Configuration Architecture", draft-zhou-opsawg-vnf-config-
              arch-00 (work in progress), September 2013.








Deng, et al.            Expires December 6, 2014               [Page 12]


Internet-Draft                nb use cases                     June 2014


6.2.  Informative References

   [ETSI_GS_NFV_001]
              "Network Functions Virtualisation (NFV); Use Cases", ETSI
              GS NFV specification Network Functions Virtualisation
              (NFV) ETSI ISG, ETSI GS NFV 001, v1.1.1, October 2013.

   [ETSI_GS_NFV_003]
              "Network Function Virtualisation (NFV); Terminology for
              Main Concepts in NFV", ETSI GS NFV specification Network
              Function VIrtualisation (NFV) ETSI ISG, ETSI GS NFV 003,
              v1.1.1, Oct 2013.

   [NIST_SP_800-146]
              "Draft Cloud Computing Synopsis and recommendations", NIST
              specifications , May 2011.

Authors' Addresses

   Deng Lingli
   China Mobile

   Email: denglingli@chinamobile.com


   Haibin Song
   Huawei

   Email: haibin.song@huawei.com


   Georgios Karagian
   U. of Twente

   Email: karagian@cs.utwente.nl


   Evangelos Haleplidis
   U. of Patras

   Email: ehalep@gmail.com


   Barbara Martini
   CNIT

   Email: barbara.martini@cnit.it




Deng, et al.            Expires December 6, 2014               [Page 13]


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