Internet DRAFT - draft-song-alto-usecase-ext
draft-song-alto-usecase-ext
ALTO H. Song
Internet-Draft Y. Lee
Intended status: Informational Huawei
Expires: January 16, 2014 V. Lopez
D. Lopez
Telefonica I+D
L. Deng
W. Chen
China Mobile
July 15, 2013
Extension Use Cases and Requirements for ALTO
draft-song-alto-usecase-ext-00
Abstract
This document describes new usecases for ALTO, and identifie its
related requirements to extend the ALTO protocol. The use cases in
this document include overlay routing, NaaS, data center information,
and P2P cache.
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 January 16, 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
Song, et al. Expires January 16, 2014 [Page 1]
Internet-Draft usecase ext July 2013
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. Use Cases and Requirements . . . . . . . . . . . . . . . . . 3
3.1. Minor Extensions in ISP or Overlay Network . . . . . . . 3
3.1.1. Overlay Routing . . . . . . . . . . . . . . . . . . . 4
3.1.2. Inter NSP ASQ . . . . . . . . . . . . . . . . . . . . 5
3.1.3. Network As A Service (NaaS) . . . . . . . . . . . . . 6
3.1.4. P2P Cache . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data Center Network . . . . . . . . . . . . . . . . . . . 9
3.2.1. Data Center Network Deployment . . . . . . . . . . . 9
3.2.2. VM Migration Between Data Centers . . . . . . . . . . 10
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Normative References . . . . . . . . . . . . . . . . . . 11
4.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
ALTO protocol [I-D.ietf-alto-protocol]provides an interface to
applications with appropriate information to guide an optimal node
selection when there are more than one application nodes providing
the same service. It usually aggregates network locations into PIDs,
and assigns lower cost value for a PID pair that are topologically
close. So when application node follows the advice from ALTO server
to choose one resource provider with a PID that has lower cost from
its own PID, with higher probability the application node can keep
the content request and response traffic flow intra domain, which can
reduce the suffering increasing interdomain traffic for ISPs, and
avoid the congestion in the backbone network. More factors for node
selection can be considered, such as pricing, congestion, and etc.
The existing ALTO protocol has its limitations too. For example, in
a cost map it only gives one cost value between source PID and
destination PID, assuming there is only one path between them. But
it can be routed through different paths in overlay routing. So we
propose to add a "via" parameter as an extension to the cost map. In
this document, we give use cases first, and then the possible way to
extend the ALTO protocol to achieve it.
Song, et al. Expires January 16, 2014 [Page 2]
Internet-Draft usecase ext July 2013
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]. And the
following terms used in this document have their definitions below.
I2AEX: Infrastructure to Application Exposure.
ALTO: application layer traffic optimization. For ALTO protocol,
please refer to . [I-D.ietf-alto-protocol]
IaaS: Infrastructure as a Service. One common IaaS service is
leasing virtual machines with appropriate bandwidth to tennants.
NaaS: Networking as a service. The common NaaS services include
dynamic VPN service, virtual network service, and etc.
AP: a wireless access point (WAP) is a device that allows wireless
devices to connect to a wired network using WLAN. The AP usually
connects to a AC as a standalone device, but it can also be an
integral component of the router itself.
AC: a wireless access controller (WAC) is the network entity that
provides wire access via APs to the network infrastructure in the
data plane, control plane, management plane, or a combination
therein.
Fowarding Cache: is a traditional content cache, which caches content
flows from outside its coverage and serves subsequent requestors
under its coverage for the content.
Reverse Cache: is a special content cache proposed for WLAN accessing
networks, which caches content flows from inside its coverage and
serves subsequent requests from outside its coverage for the content.
Bidirectional Cache: is a combination of a forwarding cache and a
reverse cache.
Cooperative Cache: is a content cache deployed by network operators
in cooperation with specific content deliverying SPs (e.g. P2P
streaming services), which participates in the overlay's service
provision explicitly.
3. Use Cases and Requirements
3.1. Minor Extensions in ISP or Overlay Network
Song, et al. Expires January 16, 2014 [Page 3]
Internet-Draft usecase ext July 2013
3.1.1. Overlay Routing
An overlay network is a computer network which is built on the top of
another network. Nodes in the overlay can be thought of as being
connected by virtual or logical links, each of which corresponds to a
path, perhaps through many physical links, in the underlying
network[overlay_network]. One example of overlay netwok over IP
network is CDN network. A CDN network consists of many CDN nodes
with different levels. One edge CDN node often needs to pull content
from another node that is in a higher distribution level position in
the CDN topology. There usually can be several paths to send the
content from the source CDN node to the edge CDN node. One way
obviously is the direct IP routing. And if the direct routing path
is not good, then the source CDN node will select another CDN node as
the intermediate node to transport the content to the that
destination edge node, which will be more efficiency than the direct
routing path. Of course, there are usually more than one
intermediate node available, and the source CDN node needs to select
a "best" one.
In some cases, there can also be a VPN tunnel between two CDN nodes
to transfer contents.
/--------\
|/// \\\|
| CDN Node |
|\\\ 1 ///|\
\-+------/| \\
| | \
| | \\ overlay routing
| \
direct Internet routing | \\
| \
| | \\
/--------\ | | /----\---\
/// \\\ | | |/// \\\|
| CDN Node | \ | | CDN Node |
\\\ 2 /// \ | |\\\ 3 ///|
\--------/ \ | \--------/
\ VPN tunnel /
\ | /
\ | /
\ |
\ | / overlay routing
\ | /
/------+-\ /
|/// \\\| /
| CDN Node |
Song, et al. Expires January 16, 2014 [Page 4]
Internet-Draft usecase ext July 2013
|\\\ 4 ///|
\--------/
Figure 1. different ways for sending content from Node 1 to Node 4
So the transport between two overlay nodes can be from:
direct routing
one/more intermediate overlay nodes
a VPN tunnel
The proposed extension is to add a "via" parameter to each cost
value, and the value of the "via" parameter can be "direct routing",
or location identifiers that can represent intermeidate overlay nodes
(such like IP address), or "VPN".
3.1.2. Inter NSP ASQ
This use case is similiar to the overlay routing use case. When two
ASes are connected through more than one pairs of border gateway
routers, then there are more than one paths from a node in one of
these two ASes to another node in the other AS. And these paths
through different pair of border routers may have different service
quality. An ALTO server can contemplate the service quality through
the locations in one AS to its different boarder gateways, and
between boarder gateways, and through the other boarder gateway to
network locations in the other AS, and then provide guidance to
applications to choose an appropriate path for the service routing.
+------------------+ +------------------+
| Edge NSP A | | Edge NSP B |
node---- | | |
| - ------- | PoI | node
| - ----BG--------------BG |
| - Path 1 | | \ |
| - | | \ |
| - | | \ node
node - | | \ |
| - | PoI | \ |
| Path 2 - BG-------------BG- \ |
| | | - \ |
node | | - \ node
| | | - \ |
Song, et al. Expires January 16, 2014 [Page 5]
Internet-Draft usecase ext July 2013
| | | - \ |
| | PoI | - \ |
node BG-------------BG --\node
| | | |
node | | |
| | | node
+------------------+ +------------------+
Figure 2 Inter-NSP ASQ use case
The "via" extension is also proposed to be used for this use case,
and the value of it can be the identifier of the boarder gateway.
3.1.3. Network As A Service (NaaS)
Network As A Service (NaaS) enables network operators to give
connectivity service to multiple users on top of the same physical
infrastructure. This connectivity service can be offered to
different customers, which have an interface to request for more
bandwidth to the network in case they need more capacity. Although
end users may have an interface to request for bandwidth to the
network, an interface is required to disseminate to the end points
with the changes in the network configuration. There are two options
to disseminating information using ALTO protocol:
o Dissemination of bandwidth information. ALTO can inform with a
cost map related to unreserved bandwidth so end points can decide
which connections they may use depending on the capacity in the
connections. This can be used to update routing tables in the end
points or priorities to interconnect two end points. Due to the
dynamicity of traffic, this unreserved bandwidth is based on
administrative reservations done through control plane protocols
like RSVP-TE.
o Bandwidth pricing. ALTO protocol can disseminate a cost map
related to price of the connectivity between locations (such like
PIDs). This information can be used to advertize customers, which
is the cost to request for more bandwidth between two locations
periodically. This can change depending on links utilization in
the physical infrastructure. The cost advertize by ALTO is not
directly the price charged to the customer, but a cost related to.
3.1.4. P2P Cache
Efforts have been put on using forwarding caches to reduce P2P
traffic in cross domain scenarios, which demonstrates great
Song, et al. Expires January 16, 2014 [Page 6]
Internet-Draft usecase ext July 2013
improvement in user experience and considerable cost reduction at
interworking points. What's more, bidirectional caches are proposed
to be deployed at the AC level for mitigation of undesirable downlink
congestion caused by consistent uplink P2P traffic, as shown in
Figure 5, the reverse cache can provide uploading service instead of
the WLAN peers under the AC's coverage.
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +----------------+ +------------------+ |
| |Interworking GW |----------------| Forwarding Cache | |
| +-----+----------+ +------------------+ |
| | |
| | |
| +-----+------+ +---------------------+ |
| | AC +----------------+ Bidirectional Cache | |
| +-----+------+ +---------------------+ |
| | |
| +-------------------------------+ |
| +----+------+ +-----+-----+ |
| | AP_1 | . . . . | AP_n | |
| +----+------+ +-----+-----+ |
| | | |
+--------+-------------------------------+----------------------+
| |
+--+----------+ |
| | |
+--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4|
+-----+ +-----+ +-----+
Figure 1: Architecture of T/B-cache in WLAN
With various P2P caches deployed, especially at a position as low as
the AC-level, it could be sub-optimal to simply use the accessing
network type as the divider for different PIDs and assign sufficient
high cost within the wireless PID to prefer accessing remote peers
over local peers blindly. Therefore, it is expected that the
cooperation between the network operator and the P2P SP in buiding up
cooperative caching system and sharing information through ALTO
protocol about these facilities bring benefits to both parties.
Song, et al. Expires January 16, 2014 [Page 7]
Internet-Draft usecase ext July 2013
A straightforward proposal would be to use locations of caches as
dividers of different DIPs to further partition intra-ISP network
domain and mark costs among them according to the location and type
of relevant caches. However, as there is both CAPEX and OPEX
expenditures for dedicated P2P Cache devices, it may be cost-
efficient for caches to make buffering/serving decisions based on the
popularity of the specific content. In addition, in cooperative
mode, a P2P cache may be under the content scheduling of the specific
P2P SP instead of the direct control of the network operator. How to
expose this application-relevant information to ALTO under such
context is an open issue.
Luckily, in the cooperative-mode, a cache is playing as a normal peer
under the tracker, and the latter can make the "right" decision in
choosing in favor of the former under the guidance of the ALTO
response while the tracker itself would take care of the content
availability problem. If the cache doesn't have the content in
question, it would no appear in the peer list handed in to ALTO
server by the tracker.
In this case, the ALTO server can collect the information about
caching sub-system in the network, identify those "caching" peers in
the peer list of an cost request from an ALTO client, and arrange the
returned rank list accordingly. For example, a simple candidate-
ranking policy for a cost query to a WLAN peer, could be caching
peers at the begining, then inside wired peers, and lastly outside
wired peers.
Moreover, the P2P SP and WLAN network operator may benefit even more
by group popular files accroding to peers' geographic location or
access types, and adapt its internal caching scheduling decisions
about which files to be cached on which spot. In other words, it
would be helpful that the ALTO server provides the client with the
requesting peer's subscription types (i.e. wired/WLAN/ celluar/...)
as well as geographic locations.
The proposed extension to ALTO is to distinguish peers not only
according to IP prefixes, but also peer's access types and whether
it's a caching server or not. This kind of information can be
acquired through network management system or application system.
And it also requires that for endpoint property lookup, "exact
matching" has higher priority than "IP prefix matching".
Song, et al. Expires January 16, 2014 [Page 8]
Internet-Draft usecase ext July 2013
3.2. Data Center Network
3.2.1. Data Center Network Deployment
Infrastructure as a service (IaaS) is a way how the data center
provides its services. There are different kinds of resources in a
data center, physical machines, virtual machines, switches,
firewalls, computing power, storage space, and electric power. The
draft [I-D.lee-alto-ext-dc-resource] proposes collecting data center
resource information to make use of such information for a key
decision to allocate the application request to an "optimal" Data
Center location in which to host the application request. Key
constraints in this decision include resource availability (e.g.,
memory, storage, CPU, etc.), DC network cost, DC network resource
constraints (e.g., bandwidth), structure constraints (e.g., Data
Center power consumption) and others.
Combined computing and network resource optimization is of value to
both application owners and data center operators. For example a
data center operator with multiple buildings in a metropolitan area
may also want to balance compute and network costs.
Collect DC information
+----------+
+--------------+ | ALTO |
Resource Request | Application | | Server |
-----------> | Orchestrator | /+----------+
+-------+------+ /
| /
+--------+ +----+----+ / +--------+
| | | |/ | |
| DC 1 |<-------------->| ALTO |<------------->| DC 2 |
| | | Client | | |
+--------+ +---------+ +--------+
/|\
|
|
|
\|/
+---------+
| |
| DC 3 |
| |
+---------+
Figure 3 Data Center Resource Deployment use case
Song, et al. Expires January 16, 2014 [Page 9]
Internet-Draft usecase ext July 2013
The intended ALTO protocol extension is going to provide the
following informaiton:
Data Center Identifier (DCI)
Data Center Location Identifier (e.g., IP address of the
gateway node)
Time Stamp
Abstracted Memory Usage
Abstracted CPU Level
Abstracted Power Consumption Level
DC Network cost
DC Network resource constraints
3.2.2. VM Migration Between Data Centers
Giant or large applications usually have to rent virtual machine
resources in more than one data centers for its application
deployment. These virtual machines do not only communicate with the
end users, but also with other virtual machines. Some applications
rent dedicated VPN links for the traffic among data centers, and some
applications pay money for the traffic among data centers that go
through Internet. There is a requirement to collects each VM traffic
pattern and direction among data centers, and consider them together
with the traffic pricing information, and use some specific
algorithm, to give advice on VM migration. For example, the
algorithm may let the VMs that have much communication traffic
migrate into one data center, so as to reduce the traffic among data
centers, and save money for the application.
A new "cost type" extension is proposed in ALTO, which represents the
cost between VMs, with regarding to the combined traffic volume and
pricing information. An application uses ALTO client to retrieve
this kind of information, and consider it together with the location
and any specific contraints of each VM, then decide whether to
migrate VMs that have high cost valume between each other into one
single data center, so as to reduce inter-DC traffic.
The actual use case is far more complex than the figure below.
Because each VM may communicate with multiple VMs, and a more complex
algorithm should be used for the VM migration. The application have
to compute the new total cost after the migration and compare it with
that before the migration.
+----------+ +------------+
| | | DC 2 |
| DC 1 | | |
| +---+ | average: 2Mbps |+---+ |
Song, et al. Expires January 16, 2014 [Page 10]
Internet-Draft usecase ext July 2013
| |VM1|----+---------------------+|VM2| ---+ |
| +---+ | |+---+ |VM3| |
| | | | +---+ |
+----------+ | | |
| +------------+
----------------------------+----------------------------------
|
|
+----------+ \|/ +----------+
| | | |
| DC 1 | | DC 2 |
| +---+ | | +---+ |
| |VM1| + + |VM3| |
| +-+ | | +---+ |
| |2Mbps | | |
| +-+-+ | +----------+
| |VM2| |
| +---+ |
+----------+
Figure 4: Inter-DC VM migration use case
4. References
4.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[overlay_network]
, "overlay network", .
http://en.wikipedia.org/wiki/Overlay_network
4.2. Informative References
[I-D.lee-alto-ext-dc-resource]
Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for
Collecting Data Center Resource Information", draft-lee-
alto-ext-dc-resource-02 (work in progress), July 2013.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-16 (work in progress), May 2013.
Song, et al. Expires January 16, 2014 [Page 11]
Internet-Draft usecase ext July 2013
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[I-D.ietf-alto-deployments]
Stimerling, M., Kiesel, S., and S. Previdi, "ALTO
Deployment Considerations", draft-ietf-alto-deployments-06
(work in progress), February 2013.
Authors' Addresses
Haibin Song
Huawei
Email: haibin.song@huawei.com
Young Lee
Huawei
Email: leeyoung@huawei.com
Victor Lopez
Telefonica I+D
Email: vlopez@tid.es
Diego R. Lopez
Telefonica I+D
Email: diego@tid.es
Lingli Deng
China Mobile
Email: denglingli@chinamobile.com
Wei Chen
China Mobile
Email: chenwei@chinamobile.com
Song, et al. Expires January 16, 2014 [Page 12]
