What's the Impact of Virtualization to ALTO?
draft-fu-alto-nfv-usecase-00
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 | Qiao Fu , Zehn Cao , Haibin Song | ||
| Last updated | 2013-10-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-fu-alto-nfv-usecase-00
Internet Engineering Task Force Q. Fu, Ed.
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: April 22, 2014 H. Song
Huawei
October 19, 2013
What's the Impact of Virtualization to ALTO?
draft-fu-alto-nfv-usecase-00
Abstract
This draft 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 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.
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 April 22, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fu, et al. Expires April 22, 2014 [Page 1]
Internet-Draft VNF-ALTO October 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Impact of Virtualized Endpoints . . . . . . . . . . . . . . . 4
4. ALTO usecase with NFV . . . . . . . . . . . . . . . . . . . . 6
5. Interaction Architecture of ALTO and NFV . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This draft present 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 and CDN, in which P2P tracker or CDN request router
queries 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 an NFV Management and
Orchestrator (M&O), the VNF(Virtualized Network Function) and the
VNFI(Virtualized Network Function Infrastructure), as is shown in
Figure 1. The NFV M&O is responsible for creating and managing the
VNFs on the VNFI. Interactions between NFV M&O, 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
Fu, et al. Expires April 22, 2014 [Page 2]
Internet-Draft VNF-ALTO October 2013
the network to the clients. The central problem this draft would
like to investigate is: what's the impact of virtualization to ALTO.
+-----------+
| NFV M&O |
+-----+-----+
|
|
+----------+-----------+
| |
| |
+----+----+ +-----+-----+
| VNF |-----------| VNFI |
+---------+ +-----------+
Figure 1: NFV Architecture in Brief
This draft analyzes the impacts of virtualized endpoints to
application layer traffic optimization and presents a usecase of ALTO
in CDN and P2P network with the peers as a VNF(Virtualized Network
Function). .
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 controller (orchestrator) 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,
Fu, et al. Expires April 22, 2014 [Page 3]
Internet-Draft VNF-ALTO October 2013
a Network Function is today 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.
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 the same as physical and non-virtualized
service endpoints. The difference is that the service assurance
of virtualized endpoints is more difficult to ensure.
Fu, et al. Expires April 22, 2014 [Page 4]
Internet-Draft VNF-ALTO October 2013
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 the turn 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 M&O 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.
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
the 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.
Fu, et al. Expires April 22, 2014 [Page 5]
Internet-Draft VNF-ALTO October 2013
4. ALTO usecase with NFV
The emergance 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 circumstance, the NFV M&O can act as a Dynamic
Network Info provider for ALTO.
The following paragraph will present a usecase of ALTO in CDN with
NFV. In the CDN network, the user agent first makes 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
M&O, The NFV M&O can dynamically update the network and cost info of
the surrogate to the ALTO server. In the meantime, the NFV M&O
should also keep ALTO server informed about the virtualized nature of
the VNF surrogate, since its performance might be lower than physical
devices. 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 as a rating criteria that should inform the
clients. Clients may choose physical devices instead of VNF
surrogates due to consideration of performance.
In the P2P scenario, similar situations can also happen when peers
become VNFs. In this case, NFV M&O should also inform ALTO server
about the virtualize nature of the VNF peers. And P2P trackers can
take such nature into consideration when selecting peers to obtain
content.
5. Interaction Architecture of ALTO and NFV
A vertical architecture is proposed in this draft for ALTO and NFV
interaction, in which NFV M&O is in responsible of info update to the
ALTO server, as is shown in Figure 2.
+-------------+
| ALTO server |
+-----+-------+
|
|
+-----+-----+
| NFV M&O |
+-----+-----+
|
+----------+-----------+
Fu, et al. Expires April 22, 2014 [Page 6]
Internet-Draft VNF-ALTO October 2013
| |
+----+----+ +-----+-----+
| VNF |-----------| VNFI |
+---------+ +-----------+
Figure 2 ALTO and NFV interaction architecture
In this architecture, NFV M&O 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 M&O as a
rating criteria. In the meantime, details of VNF can be updated to
the ALTO server by NFV M&O according to privacy privilege configured
by the user.
6. Informative References
[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", .
[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
Fu, et al. Expires April 22, 2014 [Page 7]
Internet-Draft VNF-ALTO October 2013
Zhen Cao
China Mobile
Xuanwumenxi Ave. No.32
Beijing 100053
China
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Haibin Song
Huawei
Email: haibin.song@huawei.com
Fu, et al. Expires April 22, 2014 [Page 8]