Skip to main content

Requirements and Use Cases for Virtual Network Functions
draft-xia-vnfpool-use-cases-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Liang Xia , Qin Wu , Daniel King , Hidetoshi Yokota , Naseem Khan
Last updated 2014-05-15
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-xia-vnfpool-use-cases-01
Network Working Group                                             L. Xia
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                  Huawei
Expires: November 15, 2014                                       D. King
                                                    Lancaster University
                                                               H. Yokota
                                                                KDDI Lab
                                                                 N. Khan
                                                                 Verizon
                                                            May 15, 2014

        Requirements and Use Cases for Virtual Network Functions
                     draft-xia-vnfpool-use-cases-01

Abstract

   Network function appliances such as subscriber termination, 
   firewalls, tunnel switching, intrusion detection, and routing are 
   currently provided using dedicated network function hardware.  As 
   network function is migrated from dedicated hardware platforms into 
   a virtualized environment, a set of use cases with application 
   specific resilience requirements begin to emerge.

   These use cases and requirements cover a broad range of capabilities
   and objectives, which will require detailed investigation and
   documentation in order to identify relevant architecture, protocol
   and procedure solutions to ensure reliance of user services using
   virtualized functions.

   This document provides an analysis of the key reliability
   requirements for applications and functions that may be hosted within
   a virtualized environment.  These NFV engineering requirements are
   based on a variety of uses cases and goals , which include
   reliability scalability, performance, operation and automation.

   Note that this document is not intended to provide or recommend
   protocol solutions.

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."

Xia, et al.            Expires November 15, 2014            [Page 1]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   This Internet-Draft will expire on November 15, 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  . . . . . . . . . . . . . . . . . . . . . . . .3   
     1.1.  Network Function Virtualization (NFV) Effort  . . . . . .4   
     1.2.  Virtual Network Functions (VNF) Resilience Requirements .4   
       1.2.1.  Service Continuity  . . . . . . . . . . . . . . . . .5   
       1.2.2.  Topological Transparency  . . . . . . . . . . . . . .5   
       1.2.3.  Load Balancing or Scaling . . . . . . . . . . . . . .5   
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .5   
   3.  Virtual Network Function (VNF) Pool Architecture. . . . . . .7   
     3.1.  VNF Instance Resilience Objectives  . . . . . . . . . . .8   
     3.2.  Resilience of Network Connectivity  . . . . . . . . . . .8 
     3.3.  Service Continuity  . . . . . . . . . . . . . . . . . . .9   
   4.  General Resilience Requirements For VNF Use Cases . . . . . .9   
     4.1.  Resilience for Stateful Service . . . . . . . . . . . . .9
       4.1.1 State Synchronization . . . . . . . . . . . . . . . . .10
     4.2.  Auto Scale of Virtual Network Function Instances  . . . .11   
     4.3.  Reliable Network Connectivity between Network Nodes . . .12   
     4.4.  Existing Operating Virtual Network Function Instance        
           Replacement . . . . . . . . . . . . . . . . . . . . . . .13   
     4.5.  Combining Different VNF Functions (a VNF Set) . . . . . .14
     4.6.  VNF Resilience Classes  . . . . . . . . . . . . . . . . .15   
     4.7.  Multi-tier Network Service  . . . . . . . . . . . . . . .15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .17   
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .17   
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .17   
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .17   
     7.2.  Informative References  . . . . . . . . . . . . . . . . .17   
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .17    

Xia, et al.            Expires November 15, 2014            [Page 2]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

1.  Introduction

   Network virtualization technologies are finding increasing support
   among network and Data Center (DC) operators.  This is due to
   demonstrable capital cost reduction and operational energy savings,
   simplification of service management, potential for increased network
   and service resiliency, network automation, and service and traffic
   elasticity.

   Within traditional DC networks, varied middleware boxes including FW
   (Fire Wall), NAT (Network Address Translation), LB (Load Balancers),
   WoC (Wan Optimization Controller), etc., are being used to provide
   network functions, traffic control and optimization.
   Each function is an essential part of the entire operator and DC
   network, and overall service chain (required traffic path for users)
   Combined these functions and capabilities.

   Currently, a significant amount of network functions are being
   migrated into virtualized entities, in essence the middleware
   capability is implemented in software on commodity hardware using
   well defined industry standard servers.  Thus allowing the creation,
   modification, deletion, scaling, and migration of single or groups of
   network functions, across few or many servers.

   These virtual network functions (VNF) may be location independent,
   i.e., they may exist across distributed or centralized DC 
   hardware.  This architecture will pose new issues and great 
   challenges to the automated provisioning across the DC network, 
   while maintaining high availability, fault-tolerant, load 
   balancing, and plethora of other requirements some of which are 
   technology and policy based.

   Today, architecture and protocol mechanisms exist for the management
   and operation of server hardware supporting applications, these
   hardware resources are known as server node pools, which may be
   accessed by other servers and clients.  These server node pools have
   a well-established set of requirements related to management,
   availability, scalability and performance.  

   [I-D.zong-vnfpool-problem-statement] provides an overview of the
   problems related to the reliability of a VNF set, and also introduces
   briefly a VNF pooling architecture.  This document provides an
   analysis of the key reliability requirements for applications and
   functions that may be hosted within a virtualized environment.  These
   Network Functions Virtualization (NFV) engineering requirements are
   based on a variety of uses cases and goals , which include
   reliability scalability, performance, operation and automation.

   This document is not intended to provide or recommend solutions.  The

Xia, et al.            Expires November 15, 2014            [Page 3]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   intention of this document is to present an agreed set of objectives
   and use cases providing network function using virtualized instances, 
   identification of key requirements across use cases.

1.1.  Network Function Virtualization (NFV) Effort

   NFV, an initiative started within the European Telecommunications
   Standards Institute (ETSI), aims to transform the way that network
   operators architect networks by evolving standard IT virtualization
   technology to consolidate many network equipment types to industry
   standard high volume servers, switches and storage.

   The objectives for NFV being specified within the ETSI organization
   include:

   o  Rapid service innovation through software-based deployment and
      operationalization of network functions and end-to-end services;

   o  Improved operational efficiencies resulting from common automation
      and operating procedures;

   o  Reduced power usage achieved by migrating workloads and powering
      down unused hardware;

   o  Standardized and open interfaces between network functions and
      their management entities so that such decoupled network elements
      can be provided by different players;

   o  Greater flexibility in assigning Virtual Network Functions (VNF)
      to hardware;

   o  Improved capital efficiencies compared with dedicated hardware
      implementations.

1.2.  Virtual Network Functions (VNF) Resilience Requirements

   Deployment of NFV-based services will require the transition of
   resilient capabilities from physical network nodes, which are 
   typically highly available, entities running Virtual Network 
   Functions (VNFs) on abstracted pool of hardware resources.

   Thus, it is critical to ensure that end-to-end user services which
   may require a variety of virtualized functions to be reliable, and in
   the event failure would support seamless failover when required to
   negate or minimize impact on user services.

   A number of requirements have been discussed and documented within
   the NFV Industry Steering Group (ISG) working groups, including
   [ETSI-HA-USECASE] and are highlighted in following sub-sections.

Xia, et al.            Expires November 15, 2014            [Page 4]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

1.2.1.  Service Continuity

   VNFs provide the capability to execute and operate network functions
   on varying types of Virtual machines (VMs), and subsequently physical
   equipment.  It should be possible to inherently provides resiliency
   at the function level, as well as physically.

   Network Functions (NFs) are assigned session IDs, Sequence IDs and
   Authentication IDs.  This information may be static, dynamic and
   temporal so will need to be replicated and maintained as needed for
   failure scenarios.

   Hardware entity such as a storage server or networking node are
   assigned a unique MAC address, which is often pre-configured
   (hardware encoded) and static.

   In the event of a hardware failure or capacity limits (memory and
   CPU) hosting VMs and therefore VNFs, it may be necessary to move VNFs
   to another VM, and/or hardware platform.  Therefore, service
   continuity must be maintained with no or negligible impact to users
   using with services being provided by the NFs.

1.2.2.  Topological Transparency

   Redundant systems are typically configured as an active and standby
   nodes, running a specific NF in the same LAN segment.  It is possible
   that they are assigned duplicate IP addresses, and sometimes the same
   MAC address as well.  In the event of an active node failure the
   standby node can take over transparently.  This should be
   architecture supported by any eventual solution.

   In order to achieve topological transparency and seamless hand-over
   the dependent nodes should replicate and maintain the necessary
   information so that in the event of failure the standby node takes
   over the service without any disruption to the users.

1.2.3.  Load Balancing or Scaling

   When load-balancing or scaling of sessions, the working session may
   be moved to a new VNF instance, or indeed a new VM on another
hardware
   platform.  Again, service continuity must be maintained.

2.  Terminology

   The following terms have been defined by the ETSI Industry Steering
   Group (ISG) responsible for the specification of NFV, and are reused
   in this document:

Xia, et al.            Expires November 15, 2014            [Page 5]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   Network Function (NF):  A functional building block within a network
      infrastructure, which has well-defined external interfaces and a
      functional behavior.  In practical terms, a Network Function is
      today often a network node or physical appliance.

   NFV Orchestrator:  The NFV Orchestrator is in charge of the network
      wide orchestration and management of NFV Infrastructure (NFVI) and
      resources.  The NFV Orchestrator has control and visibility of all
      VNFs running inside the NFVI.  The NFV Orchestrator provides GUI
      and external NFV-Interfaces to the outside world to interact with
      the orchestration software.

   Service Continuity:  The continuous delivery of service in
      conformance with service, functional and behavioral specification
      and SLA requirements, both in the control and data planes, for any
      initiated transaction or session till its full completion even in
      the events of intervening exceptions or anomalies, whether
      scheduled or unscheduled, malicious, intentional or unintentional.
      From an end-user perspective, service continuity implies
      continuation of ongoing communication sessions with multiple media
      traversing different network domains (access, aggregation, and
      core network) or different user equipment.

   Hypervisor:  Software running on a server that allows multiple VMs to
      run on the same physical server.  The hypervisor manages and
      provide network connectivity to Virtual machines [NVO3-FWK].

   Network Functions Virtualization (NFV):  Moving network function from
      dedicated hardware platforms onto industry standard high volume
      servers, switches and storage.

   Set-top Box (STB):  This device contains audio and video decoders and
      is intended to connects to a variety of home user devices media
      servers and televisions.

   Virtual Machine (VM):  Software abstraction of underlying hardware.

   Virtual Application (VA):  A Virtual Application is the more general
      term for a piece of software which can be loaded into a Virtual
      Machine.  A VNSF is just one type of VA amongst many others, which
      may not relate to any VNF (e.g. SW-tools or NFV-Infra-internal
      applications).

   Virtualized Network Function (VNF): a VNF provides the same 
      functional behavior and interfaces as the equivalent network 
      function, but is deployed as software instances building on top 
      of a virtualization layer.

      The VNF Problem statement [I-D.zong-vnfpool-problem-statement]

Xia, et al.            Expires November 15, 2014            [Page 6]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

      defines the terms reliability, VNF, VNF Pool, VNF Pool 
      Manager, and VNF Set. This draft also uses these definitions.  
      In addition to the terms described above, this document also 
      uses the following additional terminology:

   VNF Pool: a group of VNF instances providing the same network 
      function.

   VNF Pool Manager: an entity that manages a VNF pool, and interacts 
      with the service control entity to provide the network function.

   VNF Set: a group of VNF instances that can be used to build network 
      services.

3.  Virtual Network Function (VNF) Pool Architecture

   Shifting towards virtual network function presents a number of 
   challenges and requirements, this document focuses on those   
   related to network function availability and reliability.  In large
   DC environments, a virtual server may need to deal with traffic 
   from millions of hosts.  This represents a significant scaling 
   challenge for Virtual network function deployment and operation.

                            +------------------+
                            | NFV Orchestrator |
                            +------------------+
                                 ^        ^
                                 |        |
                     +-----------+        +-----------+
                     |                                |
                     v                                v
              +----------------+            +----------------+
              |VNF Pool Manager|<---------->|VNF Pool Manager|
              +----------------+            +----------------+
                     ^                                ^
                     |                                |
                     v                                v
  +------------------------------+   +------------------------------+
  |+----------+     +----------+ |   | +----------+     +----------+|
  ||    VNF   |     |   VNF    | |   | |    VNF   |     |    VNF   ||
  ||  Instance| ... | Instance |<+---+>|  Instance| ... |  Instance||
  |+----------+     +----------+ |   | +----------+     +----------+|
  |         VNF Pool             |   |          VNF Pool            |
  +------------------------------+   +------------------------------+

               Figure 1: Typical VNF Pool Network Architecture 

   As shown in Figure 1, the overall architecture of VNF Pool-based 
   network includes:

Xia, et al.            Expires November 15, 2014            [Page 7]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   
   o VNF Instances
   
   o VNF Pool
   
   o VNF Pool Manager 
   
   Rserpool [RFC5351] has the similar architecture to provide high-
   availability and load balancing, However Rserpool are only used to
   manage physical servers and can not deal with VNF
   instance when it was designed.

3.1.  VNF Instance Resilience Objectives

   In order to manage VNF-based nodes and provide fault tolerant and 
   load sharing across nodes, the VNF instances may be initiated and 
   established as logical element. A set of VNFs providing the 
   same service type,  is known as a VNF Pool, or groups of network 
   functions (FW, LB, DPI) running on multiple VNFs, is known as a 
   VNF Set.  
   
   Considering the reliability requirements of a VNF-based 
   node architecture it should support several key points detailed 
   below:

   o  Application resource monitoring and health checking;

   o  Automatic detection of application failure;

   o  Failover to another VNF instance;

   o  Transparency to other VNF instances;

   o  Isolation and reporting of failures;

   o  Replication of state for active/standby network functions.

3.2.  Resilience of Network Connectivity

   The other category of reliability requirements concerns the network
   connectivity between any two VNFs, across a VNF set, or between 
   VNF Pool Manager. 
   
   The connectivity between the VNF Pool Manager and the VNF instance is 
   used to provide registry service to the VNF Set. A set 
   of VNF Pool managers might be configured to provide reliable 
   registration.  
   
   When one VNF instance cannot obtain a register response from the 
   assigned VNF Pool Manager, it should be capable of fail-over to    

Xia, et al.            Expires November 15, 2014            [Page 8]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   another VNF Pool Manager. Connectivity may also be monitored by the 
   VNF Pool Manager to the VNF Instance periodically as well.

   The connectivity between Pool Managers is used to maintain
   synchronization of data between VNFs located in different VNF Pools 
   or VNF Sets. This allows every Pool Manager to acquire and maintain 
   overall information of all VNFs and provide protection for each 
   other.

   For all types of network connectivity discussed previously, the key 
   reliability requirements stay consistent and include:

   o  Automatic detection of link failure;

   o  Failover to another usable link;

   o  Automated routing recovery.

3.3.  Service Continuity

   It is critical to ensure end-to-end service continuity over both
   physical and virtual infrastructure.  A number of requests exist to
   maintain user services in the event of network or VNF 
   instance failure, these include:

   o  Storage and transfer of state information within the VNFs;

   o  VNF capacity (memory and CPU) limitations per instance to avoid
      overbooking, and failure of end-to-end services;

   o  Automated recovery of end-to-end services after failure
      situations;

4.  General Resilience Requirements For VNF Use Cases

4.1.  Resilience for Stateful Service

   In the service continuity use case provided by the European
   Telecommunications Standards Institute (ETSI) Network Function
   Virtualization (NFV) Industry Specification Group (ISG) [NFV-REL-REQ]
   , which describes virtual middlebox appliances providing layer-3 to
   layer-7 services may require maintaining stateful information, e.g.,
   stateful vFW.  In case of hardware failure or processing overload of
   VNF, in addition to the replacement of VNF, it is necessary to move
   its key status information to new VNF for service continuity.  See
   Figure 2 (Resilience for Stateful Service) for clarification.

   In case of multiple vFws on one VM and not enough resources are
   available at the time of failure, two strategies can be taken: one is

Xia, et al.            Expires November 15, 2014            [Page 9]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   to move as many vFws as possible to a new place according to the
   available resources, and the other is to suspend one or more running
   VNFs in the new place and move all vFws on the failed hardware to it.

                      MAC, IP, VLAN,
                      Session id, Sequence No, ...
             +-----------------+-----------------+
             |     *************************************
             |     *           |     |Limited    |     *        |
             |     *           |     |Resource   |     * Suspend|
             |     *           |     V           |     *        V
          +--+-+ +-*--+     +--V-+ +----+     +--V-+ +-V--+  +----+
          |vFw1| |vFw1|     |vFw1| |vFw2|     |vFw1| |vFw1|  |vFw3|
          +----+ +----+     +----+ +----+     +----+ +----+  +----+
          +------------+    +------------+    +-------------------+
          |    VM      |    |    VM      |    |        VM         |
          +------------+    +------------+    +-------------------+
          +------------+    +------------+    +-------------------+
        /-\            |    |            |    |                   |
       |  ||  vServer  |    |   vServer  |    |      vServer      |
        \-/            |    |            |    |                   |
          +------------+    +------------+    +-------------------+
       Hardware
       Failure

                 Figure 2: Resilience for Stateful Service

   In both scenarios, the following requirements need to be satisfied:

   o  Supporting status information maintaining;

   o  Supporting status information moving;

   o  Supporting VNF moving from one VM to another VM;

   o  Supporting partial VNFs moving;

   o  Seamless switching user traffic to alternative VMs and VNFs.

4.1.1 State Synchronization

   As identified in section 4.1 (Resilience for Stateful Service) their 
   is a requirement for for state synchronization. A failure of a 
   vFW would result in the loss of active connections transiting the 
   node. Any connection-orientated or secure sessions, including 
   enterprise and financial transactions, may be critical, and 
   losing them would result in the loss of data.
   

Xia, et al.            Expires November 15, 2014            [Page 10]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   If required it should be possible to ensure that the VNF Pool 
   infrastructure should minimise or negate session data traffic if a 
   vFW failures. Prior to the failure the vFW might advertise and 
   synch the connection information transitioning its node. The 
   connection state synchronization to other vFWs acting as stand-by 
   nodes would provide fast fail-over and minimal connection 
   interruption to users. 
   
   This synchronization mechanism should be supported by the (NFV) 
   infrastructure level, that is, ideally each application does not need 
   to code the redundancy procedures (reserve a VM resource, instantiate 
   one or more backup server(s), copy the state, keep them in sync, 
   etc). Also, such a state can be embedded in each vNF or stored in an 
   external virtual storage, which should be supported by the NFV 
   infrastructure.  
   
4.2.  Auto Scale of Virtual Network Function Instances

   Adjusting resource to achieve dynamic scaling of VMs described in the
   ETSI [NFV-INF-UC] use case and [NFV-REL-REQ].  As shown in Figure 3,
   if more service requests come to a VNF than one physical node can
   accommodate, processing overload occurs.  In this case, the movement
   of the VNF instance to another physical node with the same resource
   constraints will create a similar overload situation.  A more
   desirable approach is to replicate VNF instance to one or more new
   VNF instances and at the same time distribute the incoming 
   requests to those VNF instances.

   In a scenario where a particular VNF requires increased resource
   allocation to improve overall application performance, the network
   function might be distributed across multiple VMs.  To guarantee
   performance improvement, the hypervisor dynamically adjusts (scaling
   up or scaling down) resources to each VNF in line with the current
   or predicted performance needs.

Xia, et al.            Expires November 15, 2014            [Page 11]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

                               +--------------+
       +-------------------+   |      NFV     |
       |                   |   |Management and|
       |                   <===>Orchestration |
       |    +---------+    |   |    Entity    |
       |    |   #1    |    |   +--------------+
       |  --| vIPS/IDS|--  |           /\
       |  | +---------+ |  |           ||         +---------+
       |  |             |--|--         ||      <--|End User1|
       |  |    VM #1    |  | |         ||         +---------+
       |  +-------------+  | |    +----\/---+
       |                   | |    |         |     +---------+
       |    +---------+    | |    |         |  <--|End User2|
       |    |   #2    |    | |    |         |     +---------+
       |  --| vIPS/IDS|--  | |    |         |
       |  | +---------+ |  | |    |         |     +---------+
       |  |             ---|------- Service |  <--|End User3|
       |  |    VM #2    |  | |    | Router  |     +---------+
       |  +-------------+  | |    |         |     +---------+
       |                   | |    |         |  <--|End User4|
       |    +---------+    | |    |         |     +---------+
       |    |   #3    |    | |    |         |     +---------+
       |  --| vIPS/IDS|--  | |    |         |  <--|End User5|
       |  | +---------+ |  | |    +---------+     +---------+
       |  |             ---|--                        :
       |  |    VM #3    |  |
       |  +-------------+  |                          :
       |                   |
       +-------------------+

       Figure 3: Auto Scaling of Virtual network Function Instances

   In this case, the following requirements need to be satisfied:

   o  Monitoring/fault detection/diagnosis/recovery - appropriate
      mechanism for monitoring/fault detection/diagnosis/recovery of all
      components and their states after virtualization, e.g. VNF,
      hardware, hypervisor;

   o  Resource scaling - elastic service aware resource allocation to
      network functions.

4.3.  Reliable Network Connectivity between Network Nodes

   In the reliable network connectivity between VNFs use case
   provided by ETSI [NFV-INF-UC], the management and orchestration
   entities must be informed of changes in network connectivity
   resources between VNFs.  For example, Some network

Xia, et al.            Expires November 15, 2014            [Page 12]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   connectivity resources may be temporarily put in power savings mode
   when resources are not in use.  This change is not desirable since it
   may have great impact on reachability and topology.  Another example,
   some network connectivity resource may be temporarily in a fault
   state and comes back into an active state, however some other network
   connectivity resource becomes permanent in a fault state and is not
   available for use.

       +----------------+
       |NFV Orchestrator|
       +----------------+

                         Web
            vDPI       vCache      vFW         vNATPT

          +--------+ +--------+  +--------+ +--------+
          | +----+ | | +----+ |  | +-++-+ | | +----+ |
     |------|    ------|    -------| || | ----|    |<-----
     |    | |    | | | |    | |  | | || | | | |    | |   |
     |    | +----+ | | +----+ |  | +-++-+ | | +----+ |   |
     |    |        | |        |  |        | |        |   |
   +----+ |        | | +----+ |  | +-++-+ | |        |   V| ,--,--,--.
   |    | |        | | |    | |  | | || | | |        |  ,-'          `-.
   |    |<->---------- |    |----- | || |-----------<-->    Internet   )
   |    | |        | | +----+ |  | +-++-+ | |        |  `-.          ,-'
   +-|--+ |        | |        |  |        | |        |   A `--'--'--'
     |    | +----+ | |        |  | +-++-+ | | +----+ |   |
     |    | |    ------------------| || ------|    |<----|
     --------    | | |        |  | | || | | | |    | |
          | +----+ | |        |  | +-++-+ | | +----+ |
          +--------+ +--------+  +--------+ +--------+

                  Figure 4: Reliable Network connectivity

   In this case, the following requirements need to be satisfied:

   o  Quick detection of link failures;

   o  Adding or removing VNF instances;

   o  Adding or removing network links between VNFs.

4.4.  Existing Operating Virtual Network Function Instance Replacement

   In the Replacement of existing operating VNF instance use case
   provided by ETSI [NFV-INF-UC] use case, the Management and
   Orchestration entity may be configured to support virtualized network
   function replacement.  For example, the Network Service Provider has
   a virtual firewall that is operating.  When the operating vFW

Xia, et al.            Expires November 15, 2014            [Page 13]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   overloads or fails, the Management and Orchestration entity
   determines that this vFW instance needs to be replaced by another vFW
   instance.

                             
                       +----------------+      
                       |NFV Orchestrator|
                       +---|---------|--+ 
                           |         |   
                   Create  |         | Report Stats
               and launch  |         | (Traffic,CPU               
                  new vFW  |         | Failure..)
                           |         |             
                  +--------|---+  +--|---------+   
                  |Host2       |  |Host1       |   
                  |            |  |            |
                  | +---++---+ |  | +---++---+ |
                  | |vFW||vFW| |  | |vFW||vFW| |
                  | +---++---+ |  | +---++---+ |
                  | +---++---+ |  | +---++---+ |
                  | |vFW||vFW| |  | |vFW||vFW| |
                  | +---++---+ |  | +---++---+ |
                  +------------+  +------------+

                Figure 5: Existing vFW replacement

   In this case, the following requirements need to be satisfied:

   o  Verifying if capacity is available for a new instance of the VNF
      at some location;

   o  Instantiating the new instance of a VNF at the location;

   o  Transferring the traffic input and output connections from the old
      instance to the new instance.  This may require transfer of state
      between the instances, and reconfiguration of redundancy
      mechanisms;

   o  Pausing or deleting the old VNF instance.

4.5.  Combining Different VNF Functions (a VNF Set)

   A VNF Set is used to assemble a collection of network functions 
   together to support a type of user or end-to-end service. 
   Connectivity between the VNF sets is known as a VNF Forwarding 
   Graph (a graph of logical links connecting VNFs together for 
   steering traffic between network function). To support the 
   reliability of an end-to-end service, except for satisfying the 
   aforementioned basic use case requirements, a VNF Set presents 
   further requirements of reliability as followed:  

Xia, et al.            Expires November 15, 2014            [Page 14]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   o  As a whole, any failures (i.e., VNF failures, link failures,
   performance degradation, etc) of a VNF Set can be detected and
   recovered in time;
      
   o  Keeping the VNF order and relation unchanged when the VNF Set 
   is updated; 

   o  The integrated VNF Set performance is not denigrated after it 
   is updated;

4.6.  VNF Resilience Classes

   Different end-to-end services(e.g., Web, Video, financial backend,
   etc) have different classes of resilience requirement for the VNFs.

   The use of class-based resiliency to achieve service resiliency SLAs,
   without "building to peak" is critical for operators.

   VNF resilience classes can be specified by some attributes and
   metrics as followed:

   o  Does the VNF need status synchronization;

   o  Fault Detection and Restoration Time Objective (e.g., real-time,
      near-real time, non-realtime) and metrics;

   o  Service availability metrics;

   o  Service Quality metrics;

   o  Service reliability;

   o  Service Latency metrics for components.

   [More description is needed.]

4.7.  Multi-tier Network Service

   Many network services require multiple network functions to be
   performed sequentially on data packets.  A traditional model for
   multi-tier service is shown as below, where for each network
   function, all instances connect to the corresponding entrance point
   (e.g. LB) responsible for sending/receiving data packets to/from
   selected instance(s), and steering the data packets between different
   network functions.

Xia, et al.            Expires November 15, 2014            [Page 15]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

                      Service (e.g. VOIP, Web)
        +--------------+  +--------------+       +--------------+
        | function#1   |  |  function#2  |       |  function#n  |
        | +----------+ |  | +----------+ |       | +----------+ |
        | | Instance | |  | | Instance | |... ...| | Instance | |
        | +----------+ |  | +----------+ |       | +----------+ |
        |      |data   |  |      |data   |       |      |data   |
        |      |conn   |  |      |conn   |       |      |conn   |
        | +----------+ |  | +----------+ |       | +----------+ |
        | | Entrance | |  | | Entrance | |       | | Entrance | |
        | |   Point  | |  | |   Point  | |       | |   Point  | |
        | +----------+ |  | +----------+ |       | +----------+ |
        +-----+--------+  +-------+------+       +-------+------+
              |data conn          |data conn             |
              +-------------------+----------------------+

                       Figure 7: Multi-tier Service

   Such model works well when all instances of the same network function
   are topologically close to each other.  However, VNF instances are
   highly distributed in DC networks, Network Operator networks and even
   customer premised.  When VNF instances are topologically far from
   each other, there could be many network links/nodes between them for
   transferring the data packets.  For two different VNF instances, it
   is possible that they are on the same physical server, but the
   entrance points are many links/nodes away.  To improve network
   efficiency, it is desirable to establish direct data connections
   between VNF instances, as shown below:

                          Service (e.g. VOIP, Web)
        +----------+           +----------+           +----------+
        |   VNF#1  | data conn |   VNF#2  | data conn |   VNF#n  |
        | Instance |-----------| Instance |- ... ... -| Instance |
        +----------+           +----------+           +----------+
                                    ^
                                    | Virtualization
        +--------------------------------------------------------+
        |                Virtualization Platform                 |
        +--------------------------------------------------------+

                Figure 8: VNF Instances Direct Connection'

   In this case, the following requirements need to be satisfied:

   o  End to end failure detection of VNFs or links for multi-tier
      service;

Xia, et al.            Expires November 15, 2014            [Page 16]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   o  Keep running service not be influenced during VNF instance
      transition or failure in the model of VNF instances direct
      connection.

5.  IANA Considerations

   This document has no actions for IANA.

6.  Security Considerations

   TBD.

7.  References

7.1.  Normative References

7.2.  Informative References

   [NFV-INF-UC]
              "Network Functions Virtualisation Infrastructure
              Architecture Part 2: Use Cases", ISG INF Use Case, June
              2013.

   [ETSI-HA-USECASE]
              "Network Function Virtualisation; Use Cases;", ISG NFV Use
              Case, June 2013.

   [NFV-REL-REQ]
              "Network Function Virtualisation Resiliency Requirements",
              ISG REL Requirements, June 2013.

   [I-D.zong-vnfpool-problem-statement]
              Zong, N., "Problem Statement for Reliable Virtualized
              Network Function (VNF) Pool", May 2014.

   [NVO3-FWK]
              Lasserre, M., et al. "Framework for DC Network 
              Virtualization",
              ID draft-ietf-nvo3-framework-05, January 2014.

   [RFC5351]  Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An
              Overview of Reliable Server Pooling Protocols", May 2008.

Authors' Addresses

Xia, et al.            Expires November 15, 2014            [Page 17]

Internet-Draft     Requirements and Use Cases for VNF        May 2014

   Liang Xia
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: frank.xialiang@huawei.com

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com

   Daniel King
   Lancaster University
   UK

   Email: d.king@lancaster.ac.uk

   Hidetoshi Yokota
   KDDI Lab
   Japan

   Email: yokota@kddilabs.jp

   Naseem Khan
   Verizon
   USA
   
   Email: naseem.a.khan@verizon.com
   
   

Xia, et al.            Expires November 15, 2014            [Page 18]

Internet-Draft     Requirements and Use Cases for VNF        May 2014