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

Versions: 00 01

Network Working Group                                             L. Xia
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                  Huawei
Expires: April 24, 2014                                          D. King
                                                    Lancaster University
                                                               H. Yokota
                                                                KDDI Lab
                                                        October 21, 2013


  Use cases and Requirements for Virtual Service Node Pool Management
                draft-xia-vsnpool-management-use-case-01

Abstract

   Network edge 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
   requirements begin to emerge.  These use cases and requirements cover
   a broad range of capability and objectives, which will require
   detailed investigation and documentation in order to identify
   relevant architecture, protocol and procedure solutions.

   This document provides an analysis of the key management requirements
   for applications that may be hosted within a virtualized environment.
   These engineering requirements are based on a variety of uses cases
   and goals , which include: virtual application security, 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 April 24, 2014                 [Page 1]


Internet-Draft                   VSNPool                    October 2013


   This Internet-Draft will expire on April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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.



































Xia, et al.              Expires April 24, 2014                 [Page 2]


Internet-Draft                   VSNPool                    October 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Virtual Service Node (VSN) Overview  . . . . . . . . . . . . .  7
     3.1.  Reliability of VSN, VServer, VSNP  . . . . . . . . . . . .  8
     3.2.  Reliability of Network Connectivity  . . . . . . . . . . .  9
   4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  Virtualized Mobile Core Network and Service Systems  . . . 10
     4.2.  Resilience for Stateful Service  . . . . . . . . . . . . . 11
     4.3.  Auto Scale of Virtual Network Function Instances . . . . . 12
     4.4.  Reliable Network Connectivity between Network Nodes  . . . 14
     4.5.  Existing Operating Virtual Network Function Instance
           Replacement  . . . . . . . . . . . . . . . . . . . . . . . 15
     4.6.  Reliable vCDN  . . . . . . . . . . . . . . . . . . . . . . 16
     4.7.  VSN Cluster  . . . . . . . . . . . . . . . . . . . . . . . 16
     4.8.  VSN Resilience Classes . . . . . . . . . . . . . . . . . . 18
     4.9.  Reliable Traffic Steering  . . . . . . . . . . . . . . . . 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24



























Xia, et al.              Expires April 24, 2014                 [Page 3]


Internet-Draft                   VSNPool                    October 2013


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, 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 applications (services), 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 can be termed as service
   nodes.

   In terms of virtualizing network functions, a significant amount of
   service nodes and function instances within the service nodes can be
   migrated into virtualized environments, in essence the middleware
   capability is implemented in software on commodity hardware using
   well defined industry standard servers.  Thus allowing the creation,
   scaling, migration, modification, and deletion of single or groups of
   functions, across few or many service nodes.

   These virtual service nodes 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.  Within this document we
   refer to virtualization of server node pools as Virtual Service Node
   Pool (VSNP).

   [VNF-PS] provides an overview of the problem space related to service
   node reliability.  This document provides an analysis of the key
   applications that may be hosted within a virtualized environment.
   These engineering requirements are based on a variety of objectives
   related to virtual application security, reliability, scalability,
   performance, operation and automation.




Xia, et al.              Expires April 24, 2014                 [Page 4]


Internet-Draft                   VSNPool                    October 2013


   This document is not intended to provide or recommend solutions.  The
   intention of this document is to present an agreed set of objectives
   and use cases for VSNPs, identify requirements and present
   architecture framing.















































Xia, et al.              Expires April 24, 2014                 [Page 5]


Internet-Draft                   VSNPool                    October 2013


2.  Terminology

   Broadband Network Gateway (BNG):  IP Edge Route where bandwidth and
      QoS policies may be applied, to support multi-service delivery
      [TR-101].

   Call Session Control Function (CSCF):  A function that is used to
      manage the mobile IP Multimedia Subsystem (IMS) signaling from
      users to services and network gateways.

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

   IP Multimedia Subsystem (IMS):  The IP Multimedia Subsystem used
      within mobile core networks.

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

   Residential Gateway (RGW):  A device located in the home network
      performing gateway function.

   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.

   Virtualized Server (VServer):  A virtualized server runs a hypervisor
      supporting one or more VMs [NVO3-FWK].

   Virtualized Service Node (VSN):  A virtualized network function
      instance implemented in software on Virtualized Server.

   Virtual Service Node Pool (VSNP):  Virtualized Server resources
      supporting a variety of network functions..













Xia, et al.              Expires April 24, 2014                 [Page 6]


Internet-Draft                   VSNPool                    October 2013


3.  Virtual Service Node (VSN) Overview

   Shifting towards virtualization of hardware 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 Service Node (VSN) may need to deal with
   traffic from millions of hosts.  This represents a significant
   scaling challenge for VSN operation.

                       +----------------------+
                       |                      |
                       |  network application |
                       |                      |
                       +---------/-\----------+
                               //   \\
                             //       \\
                            /           \\
         +-------------+  //              \\  +-------------+
         |    VSNP     |//                  \\|    VSNP     |
         |  manager    +----------------------+   manager   |
         |             |                      |             |
         +---/-\-------+                      +-----/-\-----+
            /   \                                  /   \
           /     \                                /     \
          /       \                             /        \
        -/-----                              ------------ \
      //           \\                   //---            ---\\
    // +--+-+ +----+\\              ///                      \\\
   /   |vSN1| |vSN2|  \           //                            \\
  |    +----+ +----+   |        //                                \\
  |    +----+ ------+  |       /+----+ +----+   +----- +----+  +----\
 |     |VM1 | | VM2 |   |     | |vSN3| |vSN4|   |vSN5| |vSN6|  |vSN7||
 |     +----+ +-----+   |    |  +----+ +----+   +----+ +----+  +----+ |
 |     +------------+   |    |  +------------+  +-------------------+ |
  |    |            |  |    |   |    VM3     |  |        VM4        |  |
  |    |   vServer1 |  |    |   +------------+  +-------------------+  |
   \   |            | /      |  +------------+  +-------------------+ |
    \\ |------------//       |  |            |  |                   | |
      \\- VSNP    -//          | |   vServer2 |  |      vServer3     |
         --------              \|            |  |                   /
                                \\-----------+  +-----------------//+
                                  \\                            //
                                    \\\      VSNP             ///
                                       \\---            ---//
                                            ------------






Xia, et al.              Expires April 24, 2014                 [Page 7]


Internet-Draft                   VSNPool                    October 2013


                  Figure 1: Overall Architecture of VSNP

   As shown in Figure 1, the overall architecture of VSNP includes VS,
   VSN, VSNP, VSNP manager and the connectivity between any two VSs, and
   the connectivity between VSN and VSNP 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 virtualized function instance when it was
   designed.

   Note that VSNP and VSNP manager also can be used to manage
   traditional service node.

3.1.  Reliability of VSN, VServer, VSNP

   The VSN, VServer and VSNP components are implemented in different
   network layers and should be considered as different hardware or
   logical elements.

   Multiple VSNs can be provided on one or more VServers for increased
   reliability.  If a VServer detects the failure of the VSNs, it should
   take the appropriate action for failover and ensures the service
   continuity.

   In order to manage server virtualization across a set of VServers and
   provide fault tolerant and load sharing across VServers, the VSNPs
   may be initiated and established as logical element(e.g., a set of
   VSN providing the same service type), facilitating the migration of a
   large number of VSNs running on different hypervisors and belonging
   to different VServers to register into and deregister out.  In case
   of VSN failure or VServer overloading, such VSNPs can be used to
   support both traditional and virtualized service node replacement or
   service node adding.  However when VSNPs is used to support the
   operation of traditional service nodes, this doesn't scale very well.

   Considering the reliability requirements, VSNP architecture should
   support several key points detailed below:

   o  Application resource monitoring and health checking;

   o  Automatic detection of application failure;

   o  Failover to another VServer or VSNP;

   o  Transparency to other VSNs, VServers or VSNPs;

   o  Isolation and reporting of failures;




Xia, et al.              Expires April 24, 2014                 [Page 8]


Internet-Draft                   VSNPool                    October 2013


   o  Replication of state for active/standby network functions.

3.2.  Reliability of Network Connectivity

   The other category of reliability requirements concerns the network
   connectivity between any two VSNs,or any two VSNP managers and the
   network connectivity between VSN and VSN manager.

   The connectivity between VSNs is used to deliver service through a
   set of VSNs to meet the service requirements.

   The connectivity between VSNP manager and VSN is used by the VSNP
   manager to provide registry service to the VSN belonging to different
   VServer and provide failover of the VSN.  A set of VSNP managers can
   be configured to provide reliable registration.  When one VSN cannot
   obtain a register response from one VSNP manager, it can go to
   another VSNP manager for registration.  This connectivity can also be
   used by VSNP to monitor the work status of VSNs periodically.

   The connectivity between VSNP managers is used to maintain
   synchronization of data between VSNs located in different VSNP.  This
   allows every VSNP to acquire and maintain overall information of all
   VSNs and provide protection for each other.

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

   o  Automatic detection of link failure;

   o  Failover to another usable link;

   o  Automated routing recovery.



















Xia, et al.              Expires April 24, 2014                 [Page 9]


Internet-Draft                   VSNPool                    October 2013


4.  Use Cases

4.1.  Virtualized Mobile Core Network and Service Systems

   A key use case for NFV is the virtualization of key mobile core
   network functions.  The ETSI NFV use case [NFV-ISG-UC] describes
   requirements for server and packet gateways (S/P-GW) used for Packet
   Data Network (PDN) connections and IMS session (see Figure 2:
   Virtualized mobile core network and IMS).  These services are
   typically time dependent and may require a large number of computing
   resources in proportion to the number of users and/or service
   requests.  Therefore it is desirable to scale them according to their
   specific computing requirements.  The virtualization can be applied
   to the Evolved Packet Core (EPC) and the IMS to provide end to end
   service with service availability and resilience.  When those
   virtualized service nodes(e.g., virtualized S/P-GW and IMS functions)
   are failed or overloaded, dynamic relocation of those VSNs can be
   performed, the relocation of the managed sessions and/or connections
   must be accordingly managed.  It also should be noted in [NFV-REL-
   REQ]that the traffic in the original VSN must be routed to the new
   location and it is desirable that the movement of the VSN is
   transparent to other VSN and or physical network entities such as
   client application on the UE.  That is to say the other VSNs don't
   require to take any special action to this movement.

      +----------------+   +---------------------------------+
      | vEPC           |   |    vIMS                         |
      |                |   |                                 |
      |  +---------+   |   |                 +----------+    |
      |  |         |   |   |                 |          |    |
      |  | vP/SGW  +---+-+-|              +--+ vS-CSCF  |    |
      |  |         |   | | |              |  |          |    |
      |  +---------+   | | | +--------+   |  +----------+    |
      |Overload/Failure| |-+-|        +---| Overload/Failure |
      |                |   | | P-CSCF |                      |
      |                | ++++|        +++++                  |
      |  +---------+   | + | +--------+   +  +----------+    |
      |  |         |   | + |              +  |          |    |
      |  | vP/SGW  +++++++ |              +++| vS-CSCF  |    |
      |  |         |   |   |                 |          |    |
      |  +---------+   |   |                 +----------+    |
      |                |   |                                 |
      |  PDN Connection|   |      IMS Session                |
      +----------------+   +---------------------------------+

             Figure 2: Virtualized Mobile Core Network and IMS

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



Xia, et al.              Expires April 24, 2014                [Page 10]


Internet-Draft                   VSNPool                    October 2013


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

   o  State maintenance - network and network function state management
      during VSN relocation, replication, and resource scaling;

   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  Service Availability - achieving the same level of service
      availability for the end-to-end virtualized mobile core network as
      in non-virtualized networks with reduced cost;

   o  Minimum impact on other relevant functions.

   [More detailed description needs to be discussed.]

4.2.  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
   VSN, in addition to the replacement of VSN, it is necessary to move
   its key status information to new VSN for service continuity.  See
   Figure 3 (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
   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
   VSNs in the new place and move all vFws on the failed hardware to it.















Xia, et al.              Expires April 24, 2014                [Page 11]


Internet-Draft                   VSNPool                    October 2013


                   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 3: 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 VSN moving from one VM to another VM;

   o  Supporting partial VSNs moving;

   o  Seamless switching user traffic to alternative VMs and VSNs.

4.3.  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 4,
   if more service requests come to a VSN than one physical node can
   accommodate, processing overload occurs.  In this case, the movement
   of the VSN to another physical node with the same resource
   constraints will create a similar overload situation.  A more
   desirable approach is to replicate the VSN and distribute service
   node instances ones to one or more new VSNs and at the same time
   distribute the incoming requests to those nodes.

   In a scenario where a particular VSN requires increased resource



Xia, et al.              Expires April 24, 2014                [Page 12]


Internet-Draft                   VSNPool                    October 2013


   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 VSNs in line with the current
   or predicted performance needs.

                            +--------------+
    +-------------------+   |              |
    |                   |   |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 4: 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.




Xia, et al.              Expires April 24, 2014                [Page 13]


Internet-Draft                   VSNPool                    October 2013


4.4.  Reliable Network Connectivity between Network Nodes

   In the reliable network connectivity between network nodes use case
   provided by ETSI [NFV-INF-UC], the management and orchestration
   entities must be informed of changes in network connectivity
   resources between network nodes.  For example, Some network
   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.

       +-----------+
       |Ochestrator|
       +-----------+

                         Web
            vDPI       vCache      vFW         vNATPT

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

                  Figure 5: Reliable Network connectivity

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

   o  Quick detection of link failures;

   o  Adding network node instances, compute node instances and/or
      hypervisor instances;





Xia, et al.              Expires April 24, 2014                [Page 14]


Internet-Draft                   VSNPool                    October 2013


   o  Removing network node instances, compute node instances and/or
      hypervisor instances;

   o  Adding or removing network links between nodes.

4.5.  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
   overloads or fails, the Management and Orchestration entity
   determines that this vFW instance needs to be replaced by another vFW
   instance.

                              Direct flow to new    |   |
             +------------+        vFW              |   |
             |Orchestrator|---------------|         |   |
             +-|---------|+               |       +-V---V+
               |         |                --------|,--,--|/
    Create and launch    | Report Statist    ,-'  +------+`-.
        new vFW          | (Traffic,CPU     (               ')
               |         |   Failure..)      `-. +-------+,-'
               |         |                      `|  APP  |
      +--------|---+  +--|---------+             | Server|
      |Host2       |  |Host1       |             +-------+
      |            |  |            |
      | +---++---+ |  | +---++---+ |
      | |vFW||vFW| |  | |vFW||vFW| |
      | +---++---+ |  | +---++---+ |
      | +---++---+ |  | +---++---+ |
      | |vFW||vFW| |  | |vFW||vFW| |
      | +---++---+ |  | +---++---+ |
      +------------+  +------------+

                    Figure 6: 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 VSN
      at some location;

   o  Instantiating the new instance of VSN 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



Xia, et al.              Expires April 24, 2014                [Page 15]


Internet-Draft                   VSNPool                    October 2013


      mechanisms;

   o  Pausing or deleting the old VSN instance.

4.6.  Reliable vCDN

   Virtualization of CDNs in the ETSI [NFV-ISG-UC] use case described
   the CDN controller (a centralized component such as Global Load-
   Balancer(GLB)) selects a Cache Node(CN), or a pool of CNs, to
   redirect the proper CN which will deliver user request's content.
   The CDN Controller and CNs may be virtualized so that the resources
   for the vCDN can be scaled up and down according to the volume of
   user requests.  Then, content placed closer to the user is delivered
   for providing cost-effective resource utilization and network
   bandwidth savings.

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

   o  Resource scaling (elastic virtual CN allocation according to the
      number of requests, proximity, etc);

   o  Acceleration of network I/O (I/O centric application needs to
      overcome the network I/O degradation on the virtualized
      environment);

   o  Performance monitoring (vCDN should be monitored in terms of the
      number of sessions, load balancing, storage usage, network
      throughput, etc);

   o  Interoperating 3rd party DC infra (3rd party DC infra can be
      utilized to enhance vCDN coverage globally and to reduce infra
      cost for delivering the short-term international event);

   o  Flexibility to fulfill specific storage density requirements, e.g.
      to cache a large catalog of popular content;

   o  Ability of cache nodes to comply with main monitoring and
      reporting requirements (e.g., SNMP, syslog, etc. so that operator
      shall be able to manage different types of cache node for a
      Delivery Service).

   [More description is needed.]

4.7.  VSN Cluster

   VSN cluster is a set of VSNs which assemble together to support load
   balancing and high availability.  It tends to be a common case in
   virtual networks for the following reasons:



Xia, et al.              Expires April 24, 2014                [Page 16]


Internet-Draft                   VSNPool                    October 2013


   o  The performance of VSN is usually not as good as the appliances on
      dedicated hardware (e.g., physical FW, LB, etc) for VSN is
      realized mainly depending on software, not on dedicated hardware.
      VSN cluster should be supported to achieve the same performance as
      hardware appliance;

   o  New requirements of network virtualization as well as multi-tenant
      support result in a large number of virtual DC network and a large
      amount of traffic going through them.  VSN cluster can be a good
      choice to deal with this challenge.

   There may be multiple different types of VSN clusters in one network.
   A large number of VSNs dispersed in the network brings difficulty to
   connect part of them and assemble them as an integrated network
   function.  Also, there should be a flexible load balancing policy
   between all VSNs in one cluster to achieve good performance.  At
   last, synchronization of status information between lots of VSNs in
   one or more clusters is more complicated than before and needs more
   consideration.

                              ---------------
                     /--------               --------\
                /////    +----------+       +----------+\\\
            ////         |+---++---+|       |+---++---+|   \\\\
         ///             ||vFw||vFw||       ||vLB||vLB||       \\\
       //                |+---++---+|       |+---++---+|          \\
      |                 /||vFw||vFw||       ||vLB||vLB||            |
    ||                // |+---++---+|       |+---++---+|             ||
   |                //   +----------+       +--/-------+               |
   |              //                         //                        |
  |         +----/------+            +------/------+                   |
  |         |           |            |             |                   |
 -+---------+   SBR     +----...-----+    SBR      +--------...        |
   |        |           |            |             |                   |
    |       +-----------+            +-------------+                  |
     |                                                               |
      |                                                             |
       \\                                                         //
         \\\                                                   ///
            \\\\                                           ////
                \\\\\                                 /////
                     \--------               --------/
                              ---------------

                          Figure 10: VSNs cluster

   As shown in Figure 10, two VSNs clusters are in network, each one
   consists of 4 VSNs to provide the FW and LB function in a tenant



Xia, et al.              Expires April 24, 2014                [Page 17]


Internet-Draft                   VSNPool                    October 2013


   network.  The service border routers connecting to them distribute
   different flows to each VSN for load balancing.

   In this case, the following requirements must be satisfied:

   o  Supporting the integration of all connecting VSNs in one cluster
      to provide one network function for services;

   o  Improving performance by providing flexible load balancing policy
      between VSNs in one cluster;

   o  Supporting the synchronization of status information between lots
      of VSNs in one or more clusters while minimizing the complication
      and impaction of signaling traffic.

4.8.  VSN 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.

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

   o  Does VSN 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.9.  Reliable Traffic Steering

   The characteristics shared by aggregation and mobile-backhaul
   networks, include a large number of nodes, middlebox appliances and
   applications providing layer-3 to layer-7 services.  Connections are
   relatively static tunnel, that provide traffic multiplexing for many
   flows (see Figure 11: Reliable Traffic Steering).  These networks are
   also known for their stringent requirements with regard to



Xia, et al.              Expires April 24, 2014                [Page 18]


Internet-Draft                   VSNPool                    October 2013


   reliability and short recovery times.  The virtualization of the
   aggregation network will provide optimization of resource allocation
   and improved traffic forwarding.

   Within the aforementioned networks subscriber traffic may be steered
   through more than one appliances or bypass some appliances
   completely.  For example, traffic may pass through virtualized DPI
   and FW functions, However, once the type of the flow has been
   determined by the virtualized DPI function, the operator may decide
   to modify the services applied to it.  For example, if the flow is an
   internet video stream, it may no longer need to pass the FW service,
   reducing traffic load on it.  Furthermore, in order to reduce traffic
   load on some appliances or isolate fault on some appliances, after
   the service type has been detected, the subsequent packets of the
   same flow may no longer need to pass the LB service either; hence the
   path of the flow can be updated.

                           --,--.,--,--,--.--,--.
                        ,-'                      `-.
                    ,                              -
          Home     (     -------                  | |  -
        Enviroment (   +-|--+ +-|-++----++----+ +----+  )
      +-----------+(   |vDPI| |vLB||vFW1||vNAT| |vFW2|  )
      |           |(   +----+ +---++----++----+ +----+  )
      |  +----+   |(     \      |                /  /   )
      |  |STB |\  |(      \     |               /  /    )
      |  +----+  \|--`       \  /       /-------/  /    )
      |           |(  \    +---+ ,--,+---+_._ _ _ /    -)
      |  +----+   |(   --- |   |----'|SBR|-- .          )
      |  |PC  |++++++++++++|SBR|     +---+  |')         )
      |  +----+   |(------ |   |+        +---+          )
      |  +----+  /|(       +---+ ++++'++'|   |-------   )
      |  |iPad|/  |(                     |SBR|          )
      |  +----+   |(                     |   |++++++-   )
      |           |(                     +---+          )
      +-----------+ .                                   )
                     `-  SBR-Service Border Router   ,-'
                       `-.  --,--.,--,--,--.--,- ,

                   Figure 11: Reliable traffic steering

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

   o  Dynamic steering traffic through a set of virtual service nodes
      with each providing the same or different service [BBF-FSC-UC];

   o  Dynamic changes to the data path for a given traffic session/flow
      [BBF-FSC-UC];



Xia, et al.              Expires April 24, 2014                [Page 19]


Internet-Draft                   VSNPool                    October 2013


   o  Virtualization transparency to services - services using a network
      function need not know whether it's a virtual function or a non-
      virtualized;

   o  Virtualization transparency to network control and management -
      network control and management plane need not be aware whether a
      function is virtualized or not;

   o  Traffic control mechanism - data and management traffic
      identification/separation for non-virtualized and virtualized
      mobile core networks.








































Xia, et al.              Expires April 24, 2014                [Page 20]


Internet-Draft                   VSNPool                    October 2013


5.  IANA Considerations

   This document has no actions for IANA.
















































Xia, et al.              Expires April 24, 2014                [Page 21]


Internet-Draft                   VSNPool                    October 2013


6.  Security Considerations

   TBD.
















































Xia, et al.              Expires April 24, 2014                [Page 22]


Internet-Draft                   VSNPool                    October 2013


7.  References

7.1.  Normative References

   [BBF-FSC-UC]
              Broadband Forum, "Flexible Service Chaining", 2013.

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

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

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

   [RFC6707]  Niven-Jenkins, B., "Content Distribution Network
              Interconnection (CDNI) Problem Statement", September 2012.

   [TR-101]   Broadband Forum, "Migration to Ethernet-Based DSL
              Aggregation", 2006.

   [WT-317]   Broadband Forum, "Network Enhanced Residential Gateway",
              2013.

7.2.  Informative References

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

   [NVO3-FWK]
              Lasserre, M., "Framework for DC Network Virtualization",
              ID draft-ietf-nvo3-framework-00, September 2012.

   [VNF-PS]   Zong, N., "Problem Statement for Reliable Virtualized
              Network Function (VNF) Pool", July 2013.











Xia, et al.              Expires April 24, 2014                [Page 23]


Internet-Draft                   VSNPool                    October 2013


Authors' Addresses

   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



















Xia, et al.              Expires April 24, 2014                [Page 24]


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