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

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.

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

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

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

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

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.

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.

                            +---------------------+       
                            |       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) 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", Internet-Draft draft-deng-alto-p2p-ext-05, November 2014.
[I-D.song-opsawg-virtual-network-function-config]	Song, H. and Z. Cao, "The Problems of Virtual Network Function Configuration", Internet-Draft draft-song-opsawg-virtual-network-function-config-01, October 2013.
[NFVE2E]	Network Functions Virtualisation: End to End Architecture, http://docbox.etsi.org/ISG/NFV/70-DRAFT/0010/NFV-0010v016.zip", .
[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