Internet DRAFT - draft-fu-alto-nfv-usecase

draft-fu-alto-nfv-usecase







Internet Engineering Task Force                               Q. Fu, Ed.
Internet-Draft                                              China Mobile
Intended status: Informational                                    Z. Cao
Expires: December 11, 2015
                                                                 H. Song
                                                                  Huawei
                                                            June 9, 2015


    What's the Impact of Virtualization on Application-Layer Traffic
                          Optimization (ALTO)?
                      draft-fu-alto-nfv-usecase-05

Abstract

   This documentation presents a use case of Application-Layer Traffic
   Optimization (ALTO) with the emergence of Network Function
   Virtualization (NFV).  The Application-Layer Traffic Optimization
   (ALTO) Service provides network information (e.g., basic network
   location structure and preferences of network paths) with the goal of
   modifying network resource consumption patterns while maintaining or
   improving application performance.  The emerging NFV, which is
   currently being in progress in ETSI NFV, leverages standard IT
   virtualisation technology to consolidate many network equipment types
   onto industry standard high-volume servers, switches, and storage.
   The use case presented in this document discusses the impact of
   virtualization on the ALTO protocol.  An architecture is proposed for
   the interface between NFV MANO and ALTO server.  And possible end
   point property extention is also discussed for such usecase.

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 11, 2015.





Fu, et al.              Expires December 11, 2015               [Page 1]

Internet-Draft                  VNF-ALTO                       June 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   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.  Impact of Virtualized Endpoints . . . . . . . . . . . . . . .   4
   4.  ALTO use case with NFV  . . . . . . . . . . . . . . . . . . .   6
   5.  Interaction Architecture of ALTO and NFV  . . . . . . . . . .   8
   6.  End Point Property Extention  . . . . . . . . . . . . . . . .   9
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document presents a use case of Application Layer Traffic
   Optimization (ALTO) with the emergence of Network Function
   Virtualization (NFV).  The Application-Layer Traffic Optimization
   (ALTO) Service provides network information (e.g., basic network
   location structure and preferences of network paths) with the goal of
   modifying network resource consumption patterns while maintaining or
   improving application performance.  Typical deployment scenarios of
   ALTO include P2P networks and Content Distribution Networks (CDNs),
   in which the P2P tracker or CDN request router queries the ALTO
   server for network map and cost map, in order to make decisions on
   which peer to select for content sharing.

   The emerging Network Functions Virtualisation (NFV), as currently
   being in progress in ETSI NFV, leverages standard IT virtualisation
   technology to consolidate many network equipment types onto industry
   standard high volume servers, switches and storage.  The NFV
   architecture in ETSI ongoing work includes the NFV MANO(Management
   and Orchestration), the OSS/BSS, the E/NMS (Element/Network
   Management System), the VNF (Virtualized Network Function) and the
   NFVI(Network Function Virtualization Infrastructure), as is shown in



Fu, et al.              Expires December 11, 2015               [Page 2]

Internet-Draft                  VNF-ALTO                       June 2015


   Figure 1.  The NFV MANO is composed of the VIM (Virtualized
   Infrastructure Manager), the NFV Orchestrator, and the VNF Manager.
   The VIM is responsible for controlling and managing the NFVI compute,
   storage and network resources, usually within one Operator's
   infrastructure sub-domain.  The NFV Orchestrator is responsible for
   the lifecycle management of Network Services across the entire
   Operator's domain.  The VNF manager is responsible for the lifecycle
   management of VNF instances.Interactions between NFV MANO, E/NMS, VNF
   and VNFI are beyond scope of this draft.

   With the trend of various network functions being virtualized, there
   will be impacts on cost and network characteristics of the service
   endpoints.  Under the ALTO architecture, we analyze the problems and
   the necessity of extending the ALTO protocols to faithfully reveal
   the network to the clients.  The central problem this draft would
   like to investigate is: what's the impact of virtualization to ALTO.

                                          +---------------------+
                                          |       NFV-MANO      |
                  +-----------+           |    +------------+   |
                  |  OSS/BSS  +-----------+----|Orchestrator|   |
                  +-----+-----+           |    +------+-----+   |
                        |                 |           |         |
                        |                 |    +------+-----+   |
                  +-----------+           |    |            |   |
                  |   E/NMS   |-----------+----+            |   |
                  +-----------+           |    |            |   |
                        |                 |    |    VNFM    |   |
                        |                 |    |            |   |
                  +-----+-----+           |    |            |   |
                  |    VNF    |-----------+----+            |   |
                  +-----------+           |    |            |   |
                        |                 |    +------+-----+   |
                        |                 |           |         |
                  +-----+-----+           |    +------+-----+   |
                  |   NFVI    |-----------+----|     VIM    |   |
                  +-----------+           |    +------------+   |
                                          +---------------------+

                    Figure 1: NFV Architecture in Brief

   This document analyzes the impacts of virtualized endpoints to
   application-layer traffic optimization and presents a use case of
   ALTO in the CDN and P2P network with the peers as a VNF.







Fu, et al.              Expires December 11, 2015               [Page 3]

Internet-Draft                  VNF-ALTO                       June 2015


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   We use the following terms defined in [RFC5693].  Application, Peer,
   ALTO service, ALTO server, ALTO client, ALTO query, ALTO Reply.

   And the following terms used in this document have their definitions
   from the NFV end to end architecture [NFVE2E].

   NFV: network function virtualization.  NFV technology uses the
   commodity servers to replace the dedicated hardware boxes for the
   network functions, for example, home gateway, enterprise access
   router, carrier grade NAT and etc.  So as to improve the re-
   usability, allow more vendors into the market, and reduce time to
   market.  NFV architecture includes a NFV MANO to manage the virtual
   network functions and the infrastructure resources.

   NF: A functional building block within an Operator's network
   infrastructure, which has well-defined external interfaces and a
   well-defined functional behavior.  Note that the totality of all
   network functions constitutes the entire network and services
   infrastructure of an Operator/service provider.  In practical terms,
   a Network Function nowadays is often a network node or physical
   appliance.

   VNF: virtual network function, an implementation of an executable
   software program that constitutes the whole or a part of an NF that
   can be deployed on a virtualization infrastructure.

   VM: virtual machines, a program and configuration of part of a host
   computer server.  Note that the Virtual Machine inherits the
   properties of its host computer server e.g. location, network
   interfaces.

   SLA: Service Layer Agreement.

3.  Impact of Virtualized Endpoints

   This section analyzes the impact of virtualization when application
   or service endpoints are deployed on virtualized infrastructure.

   It is generally believed that generic computing equipment is
   difficult to accomplish the same capability of specilized and
   dedicated equipment.  Operator network normally consists of many
   dedicated equipment, and the services running on them are not



Fu, et al.              Expires December 11, 2015               [Page 4]

Internet-Draft                  VNF-ALTO                       June 2015


   vitualized.  NFV initiatives investigate the use cases, architecture
   and requirements of moving network functions to the virtualized
   infrastructure.

   We analyze the impacts of virtualized endpoints to application layer
   traffic optimization for the following aspects.

   1.  Performance.  The NFV framework is claimed to be able to
       instantiate and configure any given VNF over the underlying
       infrastructure so that the resulting VNF instance performance is
       conforming to the expressed requirement.  Using appropriate VNF
       configuration schemes
       [I-D.song-opsawg-virtual-network-function-config], the Operator
       or service provider can express their performance requirement.
       From this point, it is the same as physical and non-virtualized
       service endpoints.  The difference is that the service assurance
       of virtualized endpoints is more difficult to ensure.

   2.  Portability.  Different from physical equipment, NFV framework is
       able to provide the capability to load, execute and move VNFs
       across different but standard mutlivendor environments, and have
       to support an interface to decouple VNF associated software
       instances from the underlying infrastructure.  Portability has
       impacts on the mobility and network location of the service
       points, which in return will impact the service point selection
       process and service continuity.

   3.  Elasticity.  The NFV framework is able to allow VNFs to be scaled
       with SLA requirements, on-demand scaling or automatically
       scaling.  With the elasticity capability, VNF endpoints
       capability with respect to computing and networking are dynamic.
       The ALTO discovery and selection process will be impact to
       reflect such dynamic information.

   4.  Resilience.  NFV framework provides the necessary mechanisms to
       allow VNF to be recreated after a failure.  In addition to OAM in
       traditional non-virtualized environment, the NFV MANO will manage
       the metrics such as packet loss rate, latency, delay variation of
       flows, maximum time to detect and recover from faults.  All of
       these information will be valuable to ALTO client.

   5.  Energy efficient.  Studies have indicated that NFV could
       potentially deliver up to 50% energy saving compared with
       traditional appliance based network infrastructure.  In service
       point selection, this could be a criteria when the service
       provider is interested in saving power.





Fu, et al.              Expires December 11, 2015               [Page 5]

Internet-Draft                  VNF-ALTO                       June 2015


   6.  Service assurance.  Dedicated carrier-grade devices normally have
       requirements like 99.999%, but the such high availability is
       still challenging for VNFs.  The ALTO server should be aware of
       the assurance level of these virtualized endpoints.

   7.  Network infrastructure maintenance.  The VNFs may be bridged and
       linked using the virtualized switches on the computing node.  The
       network layer performance and availability metrics are only
       possible to collect when the OAM have established the tunnels to
       these virtual network infrastructure.  For example, normal PING
       can only reflect the physical computing node availability, but
       cannot reflect the VMs bridged using virual switchs and hidden
       with tunnel encapsulations.

4.  ALTO use case with NFV

   (1) Use Case #1, a Virtual CDN surrogate.

   The emergence of NFV means that some legacy devices, which used to
   work on a physical server, now can be moved to a VM and work as a
   VNF.  Under such a circumstance, the NFV MANO can act as a dynamic
   network information provider for ALTO.

   The following paragraph will present a use case of ALTO in CDN with
   NFV.  In the CDN network, the user agent makes an initial request to
   the Request Router.  The Request Router will first query the ALTO
   server for network and cost map to select an appropriate surrogate.
   The Request Router then responds to the UA with a redirection to the
   selected surrogate.  The UA then connects directly to the suggested
   surrogate to obtain the content.

   When a certain surrogate changes to a VNF and is managed by a NFV
   MANO, The NFV MANO can dynamically update the network and cost info
   of the surrogate to the ALTO server.  In this, the NFV MANO should
   also inform the ALTO server about the virtualized nature of the VNF
   surrogate.  In the migration stage of NFV, in which VNF and physical
   devices coexist in the network, ALTO server may consider the
   virtualized nature of VNF and should inform the clients.

   In the P2P scenario, similar situations can also happen when peers
   become VNFs.  In this case, NFV MANO should also inform ALTO server
   about the virtualize nature of the VNF peers.

   (2) Use Case #2: SFC Control Plane as ALTO Client.

   In the following paragragh, another use case is presented in which
   ALTO protocol can be used for SFC path optimization.




Fu, et al.              Expires December 11, 2015               [Page 6]

Internet-Draft                  VNF-ALTO                       June 2015


   The definition and instantiation of an ordered set of service
   functions and subsequent 'steering' of traffic through them is termed
   Service Function Chaining (SFC).  The definition of SFC can be found
   in [I-D.ietf-sfc-problem-statement].  With the emergance of NFV, SFC
   becomes an important use case since SFs in the SFC can become VNFs so
   as to provide flexible services to the users.  Howerver, the
   optimization of the SFP (Service Function Path) becomes a huge
   challenge when moving the SF from physical hardware to virtual
   mechines.  Because of the flexible deployment nature of VNFs,
   multiple virtual SFs (vSF) with the same function can be deployed in
   the DC.  In the meantime, vSF can be deployed and migrate easily,
   therefore, the locations of these vSF are not fixed.  Because of
   these characteristics of vSFs, SFP optimization becomes difficult.
   On the one hand, service providers should quickly find the optimized
   path so as to route the service packet to the optimized instance
   within multiple vSF with the same function.  On the other hand,
   service provider should also do such optimization in a continiously
   changing network environment, therefore static routing optimization
   strategies can not be used.

   In such scenario, ALTO can be used to resolve the optimization of
   SFP.  In the architecture of SFC, the SFC control plane is
   responsible for assign the SFP.  Therefore, in this case, SFC control
   plane can be the ALTO Client.  SFC control plane sends the ALTO
   server the request of cost of SFP.  The ALTO server culculate the
   cost and respond this back to the SFC control plane.

   Take the following case as an example.  Assume we have a SFC request,
   in which, the service packet should first go through a Firewall (FW),
   and then through a DPI(Deep Packet Inspection).  In the following
   topology, there are multiple paths for such SFC (FW1->DPI1,
   FW2->DPI1, FW1->DPI2, FW2->DPI2).  At this point, the SFC control
   plane shall request the ALTO server for the cost of each different
   path.  This may require the extension of Endpoint Cost Parameters.
   Possible extension can be found in Figure 3.  Such extension could
   provide the capability of requesting a list of destinations.  The
   ALTO server should calculate the cost of the permutation of the
   destination list and reply the cost.













Fu, et al.              Expires December 11, 2015               [Page 7]

Internet-Draft                  VNF-ALTO                       June 2015


                           +---+  +---+  +----+  +----+
                           |FW1|  |FW2|  |DPI1|  |DPI2|
                           +-+-+  +-+-+  +--+-+  +-+--+
                             |      |       |      |
                             |      +-+   +-+      |
                          +--+-+      +---++    +--+-+
                          |SFF1|      |SFF2|    |SFF3|
                          +-+--+      +-+--+    +-+--+
                            |           |         |
                            |         +-+--+      |
                            +---------+ GW +------+
                                      +----+

                     Figure 2: Use Case of SFC in ALTO

+----------------------------------------------------------------------+
|Current ECS protocol                                                  |
+----------------------------------------------------------------------+
|"cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost"},|
|"endpoints" : { "srcs": [ "ipv4:192.0.2.2" ],                         |
|                "dsts": [ "ipv4:192.0.2.89",                          |
|                "ipv4:198.51.100.34",]                                |
|               }                                                      |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
|Possible ECS protocol extension                                       |
+----------------------------------------------------------------------+
|"cost-type": {"cost-mode" : "ordinal", "cost-metric" : "routingcost"},|
|"endpoints" : { "srcs": [ "ipv4:192.0.2.2" ],                         |
|               "dsts": [ ["ipv4:192.0.2.89",                          |
|                          "ipv4:198.51.100.34"] ,                     |
|                          // FW way point candidates                  |
|                          ["ipv4:192.0.2.88",                         |
|                          "ipv4:198.51.100.33"] ,                     |
|                          // DPI way point candidates                 |
|               }                                                      |
+----------------------------------------------------------------------+

                    Figure 3: Possible extention of ECS

5.  Interaction Architecture of ALTO and NFV

   A vertical architecture is proposed in this draft for ALTO and NFV
   interaction, in which NFV MANO is in responsible of info update to
   the ALTO server, as is shown in Figure 2.






Fu, et al.              Expires December 11, 2015               [Page 8]

Internet-Draft                  VNF-ALTO                       June 2015


                            +---------------------+
                            |       NFV-MANO      |
         +-----------+      |    +------------+   |       +-------------+
         |  OSS/BSS  +------+----|Orchestrator|   +-------+ ALTO server |
         +-----+-----+      |    +------+-----+   |       +-------------+
               |            |           |         |
               |            |    +------+-----+   |
         +-----------+      |    |            |   |
         |   E/NMS   |------+----+            |   |
         +-----------+      |    |            |   |
               |            |    |    VNFM    |   |
               |            |    |            |   |
         +-----+-----+      |    |            |   |
         |    VNF    |------+----+            |   |
         +-----------+      |    |            |   |
               |            |    +------+-----+   |
               |            |           |         |
         +-----+-----+      |    +------+-----+   |
         |   NFVI    |------+----|     VIM    |   |
         +-----------+      |    +------------+   |
                            +---------------------+

Figure 2  ALTO and NFV interaction architecture

   In this architecture, NFV MANO can automatically update fine or
   coarse grained VNF info to the ALTO server timely.  The virtualized
   nature of the VNFs should be informed to the ALTO server by NFV MANO
   as a rating criteria.  In the meantime, details of VNF can be updated
   to the ALTO server by NFV MANO according to privacy privilege
   configured by the user.

6.  End Point Property Extention

   The information NFVO updates to the ALTO server for alto service
   discovery includes, but not limited to, the topology of the VNFs, the
   detail info of the network resource allocated to the VNF
   instances(such as the capacity, the available memory, the available
   CPU, and etc.), the lifecycle management info of VNFs, and etc..
   There is another draft talking about details of the these properties
   [I-D.deng-alto-p2p-ext].

   Endpoint property should also be extended when introducing
   virtualized end points into ALTO.

   1) Endpoint geolocation extention.  In traditional physical networks,
   geolocation for a certain endpoint is determined and should not
   change frequently.  While in the NFV scenarios, endpoints, which
   should be VNFs, can be composed of several Virtual Mechines (VMs)



Fu, et al.              Expires December 11, 2015               [Page 9]

Internet-Draft                  VNF-ALTO                       June 2015


   located on several physical servers at different geolocatoins.  In
   the meantime, this geolocation may also change due to migration and
   restoration of the VNF.  Such characteristics of VNFs require
   property extention of endpoint geolocation.  How to discribe the
   multiple geolocations of a certain virtual endpoint, and how frequent
   to update the geolocation of these virtual endpoints may need careful
   discussion.  Optimization algrithms may also need to change due to
   the virtualization nature of these endpoints.

   2) Node related property extention.  One of the benefit NFV brings to
   us is we can easily scale up and scale down services with the help of
   the virtualization technology.  Such capability should be noticed and
   taken into consideration by the ALTO server.  For instance, in the
   CDN network, when the request router reach out to the ALTO server
   asking for proper surrogate, the ALTO server may look out for the
   network and cost map of all the possible surrogates.  At this point,
   a certain virtual surrogate may not have enough bandwidth or
   processing capability to handle this request.  But it may scale up
   atomatically when request increase.  Therefore, the ALTO server
   should have knowledge to such capability of the virtual surrogates,
   and even should be able to inform the NFV MANO to scale up certain
   service at a proper point.  Such usecase requires extention of the
   node related property.

7.  Informative References

   [I-D.deng-alto-p2p-ext]
              Lingli, D., Song, H., Kiesel, S., Yang, Y., and W. Wu,
              "Extended End Point Properties for Application-Layer
              Traffic Optimization", draft-deng-alto-p2p-ext-05 (work in
              progress), November 2014.

   [I-D.ietf-sfc-problem-statement]
              Quinn, P. and T. Nadeau, "Service Function Chaining
              Problem Statement", draft-ietf-sfc-problem-statement-13
              (work in progress), February 2015.

   [I-D.song-opsawg-virtual-network-function-config]
              Song, H. and Z. Cao, "The Problems of Virtual Network
              Function Configuration", draft-song-opsawg-virtual-
              network-function-config-01 (work in progress), October
              2013.

   [NFVE2E]   "Network Functions Virtualisation: End to End
              Architecture, http://docbox.etsi.org/ISG/NFV/70-
              DRAFT/0010/NFV-0010v016.zip".





Fu, et al.              Expires December 11, 2015              [Page 10]

Internet-Draft                  VNF-ALTO                       June 2015


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693, October
              2009.

Authors' Addresses

   Qiao Fu (editor)
   China Mobile
   China
   China

   Email: fuqiao1@outlook.com


   Zhen Cao

   Email: zehn.cao@gmail.com


   Haibin Song
   Huawei

   Email: haibin.song@huawei.com

























Fu, et al.              Expires December 11, 2015              [Page 11]