Network Working Group Haiyong Xie
Internet Draft Huawei & USTC
Intended status: Informational Tina Tsou
Expires: June 18, 2012 Hongtao Yin
Huawei
D. Lopez
Telefonica I+D
Christos Kolias
Orange
June 19, 2012
Use Cases for ALTO with Software Defined Networks
draft-xie-alto-sdn-use-cases-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 19, 2012.
Copyright Notice
Copyright (c) 2012 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
Xie, et al. Expires June 19, 2012 [Page 1]
Internet-Draft Use Cases for ALTO with SDN June 2012
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This draft describes a general, umbrella use case that illustrates
application layer traffic optimization with software defined
networks. Unique requirements for design and operations are
identified and summarized. Under this umbrella, this draft also
elaborates three detailed use cases. In addition, extensions to the
existing ALTO protocol are recommended.
Table of Contents
1. Introduction ................................................... 3
1.1. Terminology ............................................... 4
2. An Overview of Software Defined Network ........................ 4
2.1. Software Defined Network .................................. 5
2.2. Division of Network ....................................... 5
2.3. SDN Domain ................................................ 7
3. Interactions between SDN and ALTO .............................. 8
3.1. The Current Scope (The "SDN-unfriendly" Scope) ............ 8
3.2. The New Scope with Existence of SDN (The "SDN-friendly"
Scope) ......................................................... 8
3.2.1. ALTO clients ......................................... 9
3.2.2. Interactions between SDN and ALTO ................... 10
3.2.3. Interactions between Legacy ALTO Clients and ALTO
Servers .................................................... 11
3.3. Summary .................................................. 11
4. Architecture .................................................. 12
4.1. Overview ................................................. 12
4.2. Work Flow of SDN Controller .............................. 12
4.3. Work Flow of Applications, SDN and ALTO .................. 13
4.3.1. SDN-aware Applications .............................. 13
4.3.2. SDN-unaware Applications ............................ 14
4.3.3. Legacy Applications ................................. 14
4.4. Summary .................................................. 15
5. Use Case for Upward Flow ...................................... 15
5.1. Unrestrictive Information Exporting ...................... 15
5.2. Restrictive Information Exporting ........................ 16
5.3. Information Aggregation .................................. 17
6. Use Case for Downward Flow .................................... 17
6.1. SDN-Aware QoS Metrics .................................... 18
6.1.1. Use Case: On-Demand Bandwidth ....................... 18
6.1.2. Delay ............................................... 19
6.2. Content Delivery Networks (CDN) .......................... 19
Xie, et al. Expires June 18, 2012 [Page 2]
Internet-Draft Use Cases for ALTO with SDN June 2012
6.3. Information-Centric Content Delivery Networks (IC-CDN) ... 22
7. Security Considerations ....................................... 23
8. IANA Considerations ........................................... 23
9. Conclusions ................................................... 24
10. References ................................................... 24
10.1. Informative References .................................. 24
Authors' Addresses ............................................... 24
Contributors ..................................................... 25
Intellectual Property Statement .................................. 25
Disclaimer of Validity ........................................... 26
1. Introduction
The concept of Software Defined Network (SDN) has emerged and become
one of the fundamental, promising networking primitives that allow
flexibility of control, separation of functional planes and
continuous evolution in networks.
One of the key features of SDN is the full separation of two
functional planes: the control plane and the data/forwarding plane.
SDN requires that networking devices support such separation,
implementing the data plane mechanisms, while the control plane is
provided by an external entity called the "controller". The other
key feature of SDN is the new interaction process between the
separated control plane and data/forwarding plane. This interaction
is mandated to be performed specific open protocols, allowing for a
free combination of networking devices and controllers, as well as
supporting the controller to take decisions on information
additional to the networking device status.
There could be numerous benefits as a result of the above features
in SDN, e.g., just to name a few, network virtualization, better
flexible control and utilization of the network, networks customized
for scenarios with specific requirements. In particular, OpenFlow,
as a representative SDN technology, has started to find its way into
Data Center Networks (DCNs) and campus networks. Furthermore, In
order to allow efficient and flexible implement the above separation
and interactions, a significant portion of the SDN system could
typically be implemented in software, as opposed to the hardware-
based implementation adopted by most of today's networking devices.
Due to the great potentials of SDN and the unique requirements of
DCNs, Data Centers are likely to become a first place where SDN
could be deployed. We envision that SDN could be gradually adopted
by enterprise networks and then by carrier networks due to its
unique, attractive features. When deploying SDN in large-scale
distributed networks, we expect to see a collection of deployments
Xie, et al. Expires June 18, 2012 [Page 3]
Internet-Draft Use Cases for ALTO with SDN June 2012
limited in portions of a bigger network (referred to as SDN domains).
In other words, the operator of a large-scale enterprise / carrier
network should divide the whole networks into multiple connected SDN
domains, where each of such domains corresponds to a relatively
small portion of the whole network. Such a divide-and-conquer
methodology not only allows gradual deployment and continuous
evolution, but also enables flexible provisioning of the network.
With the deployment of SDN, application layer traffic optimization
(ALTO) faces new challenges including, but not limited to, privacy
preservation, granularity of information collection and exchange,
join optimization, etc. We shall elaborate these challenges and
their impacts on the design of ALTO extensions for SDN in this draft.
1.1. Terminology
While the definition of software defined networks is still
"nebulous" to some extent, we refer to as SDN the networks that
implement the separation of the control and data-forwarding planes
and software defined interactions between these two separated planes.
The software defined interactions could be similar to OpenFlow or
the like. However, how the two separated planes interact is not a
focus of this draft; instead, the ALTO extension for SDN recommended
in this draft is independent of how such interactions would be.
An SDN domain is a portion of a network infrastructure, consisting
of numerous connected networking devices that are SDN compatible and
a domain controller which implements the SDN control plane
functionalities for these devices. An SDN domain can be as small as
a sub-network of a dozen devices or as large as a medium/large data
center network.
A software defined network is a network that has one or multiple SDN
domains. Due to an SDN domain typically has limited coverage, an SDN
may be comprised of networking devices under control of some SDN
domains (i.e., SDN managed devices) and devices under no control of
any SDN domain (i.e., SDN free devices). Note that SDN free devices
could be still SDN compatible.
2. An Overview of Software Defined Network
This section provides a high level and conceptual overview of
software defined network in order to help illustrate its unique
requirements for ALTO.
Xie, et al. Expires June 18, 2012 [Page 4]
Internet-Draft Use Cases for ALTO with SDN June 2012
2.1. Software Defined Network
We refer to as an "SDN" a carrier's or an enterprise's network which
deploys or implements software defined networking technologies.
Since SDN separates the control plane and data-forwarding plane, we
refer to the entity that implements the control-plane
functionalities as the "SDN controller".
In order for a network to be classified as an SDN, it is unnecessary
that all networking devices have to be SDN compatible. Some of
devices in a network may be managed by an SDN controller while the
remaining ones may not; such a network is still qualified as an SDN.
Applications in software defined networks are either SDN-aware or
unaware of SDN.
o If an application is SDN-aware, then the application may prefer
direct communication with SDN controllers, which implies that
there must exist mechanism(s) for SDN-aware applications to
locate and communication with SDN controllers. If the application
prefers indirect communication with SDN controllers, then it
follows the case of SDN-unaware applications (see below).
o If an application is SDN-unaware, then the application indirectly
communicates with SDN controllers by sending application
datagrams with specific formats, via which the application can
specify its requirements for the network resources.
Whether and how applications should/can be SDN-aware or SDN-unaware
is beyond the scope of this draft. However, the framework we
described in this draft is applicable to both SDN-aware and SDN-
unaware cases.
2.2. Division of Network
A network operator may decide to divide the network into multiple
sub-networks, some of which are SDN compatible and thus are managed
by corresponding SDN controllers.
There could be numerous reasons for such division of network. Below
we summarize a few of them:
o Scalability.
Xie, et al. Expires June 18, 2012 [Page 5]
Internet-Draft Use Cases for ALTO with SDN June 2012
The number of devices an SDN controller can feasibly manage is
likely to be limited. Therefore, in order to manage a many
devices that cannot be put under control of a single SDN
controller, multiple controllers have to be deployed. Hence, the
network is divided into multiple sub-networks; if a sub-network
has SDN-compatible devices, it should be managed by an SDN
controller.
o Manageability.
At the network level, in order to reduce the complexity of
management, a carrier may decide to divide the network into
multiple sub-networks and put some of them under control of some
SDN controllers (provided that the devices in such sub-networks
are SDN-compatible); each of the sub-networks can be managed
independently to some extent, thus reducing the overall
complexity of managing the whole network.
Even at the sub-network level, a carrier may still decide to
further divide the sub-network in order to further reduce
complexity of management. For instance, a sub-network under
control of an SDN controller may span across a large geographical
area or cover a large number of devices; in this case it is
reasonable for the carrier to further divide it into two or even
more sub-networks, such that the complexity of managing each
individual sub-network plus the overall complexity of managing
all divided sub-networks are reduced.
o Privacy.
When a carrier divides its network into multiple sub-networks and
put them under control of SDN, the carrier may choose to
implement difference privacy policies in different sub-networks.
For example, a carrier may dedicate a part of its infrastructure
to some certain customers, dividing the whole network and
dedicate some of the sub-networks is a convenient and scalable
way to manage the network resources for these customers. Another
example is that a sub-network in a carrier's network may be
dedicated to some certain customers and such information as
network topology may not be disclosed to any external entity.
o Deployment.
Xie, et al. Expires June 18, 2012 [Page 6]
Internet-Draft Use Cases for ALTO with SDN June 2012
The deployment of network infrastructures, especially new network
infrastructure and technologies, has to be incremental. This
means that at any time, a carrier's network may consist of a
portion of legacy and a portion of non-legacy infrastructure.
When deploying new infrastructure or technologies, it is highly
preferable to limit the scope of new deployment and do it in an
incremental way. In such cases, it is very favorable to divide
the network into multiple individually manageable sub-networks
and choose some of them to deploy the new infrastructure /
technologies.
2.3. SDN Domain
With the introduction of SDN, we believe that it is inevitable for
carriers to divide their networks for many reasons as illustrated in
the preceding subsection. Therefore, we believe that to better suit
this need, it should be recommended that SDN domains are defined and
applied in division of the networks.
An SDN domain is a sub-network, resulted from division of a network
which is determined by the network operator. Each domain typically
consists of numerous connected networking devices, each of which is
SDN compatible. Each domain also has a domain controller which
implements SDN control plane functionalities for the devices in this
domain. Another important task such a domain controller is
responsible for includes fine-grain network information collection
(for devices in this domain). The collected information is necessary
for the controller to make data-forwarding plane decisions. Note
that such a domain controller may be integrated as a part of a so-
called "network operating system" (NOS). An example of such a
network operating system is illustrated in [2].
Any networking device, if under the control of certain SDN domains,
should belong to only one SDN domain and should be under the control
of the SDN domain's controller. In other words, the intersection of
two domains is always empty.
Furthermore, SDN domains are connected (via the connections among
underlying devices belonging to different domains) to form the whole
network. For a large-scale distributed networks owned by a
national/multi-national carrier or enterprise, it is natural to
adopt the "divide-and-conquer" strategy and divide the whole network
into multiple SDN domains. Even for small or medium networks,
multiple SDN domains may be necessary in order to virtualize the
network resources (e.g., set up multiple SDN domains for a large
data center network to instantiate multiple virtual data centers for
many content providers). Note that how multiple SDN domains inside a
Xie, et al. Expires June 18, 2012 [Page 7]
Internet-Draft Use Cases for ALTO with SDN June 2012
carrier's/enterprise' network work together is beyond the scope of
this draft and is handled by other working groups.
Inside each SDN domain, its controller may define domain-specific
policies on information importing from devices, aggregating, and
exporting to external entities. Such policies may not be made public;
therefore, other domain controllers or ALTO may not know the
existence of such policies for any given SDN domain.
The natural network division implemented by SDN domains impose
significantly new and challenging requirement for shaping the
interactions between SDN and ALTO, and therefore designing the
protocols to enable such interactions.
3. Interactions between SDN and ALTO
3.1. The Current Scope (The "SDN-unfriendly" Scope)
In the current scope of ALTO, there exist interactions between ALTO
clients and ALTO servers. Such interactions are one-way interaction,
meaning that ALTO information flows in one direction, i.e., from the
server to the clients. More specifically, ALTO clients submit ALTO
requests to (and subsequently receive ALTO responses from) an ALTO
server.
Additionally, ALTO clients in the current scope of ALTO are network
applications who would like to consume the network resources. ALTO
clients are typically managed by network applications rather than by
network carriers. However, ALTO servers are owned and managed by
network carriers.
3.2. The New Scope with Existence of SDN (The "SDN-friendly" Scope)
With the introduction of SDN, the interactions between ALTO clients
and ALTO servers become more complex. A more careful examination as
well as important ALTO extensions are necessary to make ALTO work in
the context of SDN.
It is important to note that if the network does not implement
network division (i.e., does not implement SDN domains), the
interactions are "compressed" into a compact set of interactions;
specifically, both the SDN controller (recall that there exists only
one single controller for the whole network) and the ALTO server
could be integrated in many equally efficient fashions. For instance,
ALTO server could be put underneath the controller, i.e., ALTO
Xie, et al. Expires June 18, 2012 [Page 8]
Internet-Draft Use Cases for ALTO with SDN June 2012
server provides information to the controller, as suggested by [1].
However, if the network implements division via SDN domains (i.e.,
there exists multiple SDN domains), we essentially "unfold" the
compressed interaction space and need more complex structures that
allow efficient design and implementation, due to the facts that we
listed in the preceding section. Furthermore, the design originally
for the compressed space could be instantiated for the unfolded
space but could not be as efficient.
We now highlight the complex structures and the important
differences below.
3.2.1. ALTO clients
With the existence of SDN and SDN controllers, ALTO clients could be
not only legacy network applications (or proxies for these network
applications), but also SDN controllers.
In SDN, SDN controllers have similar needs as the legacy ALTO
clients which communicate with ALTO servers, because ALTO clients
would like to better understand the network and thus improve the
application performance.
There are multiple reasons for this similarity. The most important
reason is that each SDN controller is only responsible for managing
a sub-network in a carrier's network; therefore, it may not
understand well other sub-networks in the same carrier network.
However, in order to allocate the network resources to satisfy
application requirements (note that the end points of such
applications may well span across multiple SDN domains), an SDN
controller may have to involve other SDN controllers because the
network paths needed may traverse multiple SDN domains. Thus,
obtaining global information from the ALTO server is a significantly
more efficient and more preferable than otherwise from SDN
interconnection protocols; plus, such protocols do not exist yet
today.
Although SDN controllers have similar needs as legacy ALTO
applications do, the fundamental properties of SDN controllers as
ALTO clients are significantly different.
One of the differences is the ownership and management, as most SDN
controllers require additional (and more likely complex) access
privileges. Specifically, SDN controllers are typically owned by the
network carriers who also own their ALTO servers, while legacy ALTO
clients are network applications typically not owned by network
carriers (there are cases where owned collaboratively amongst
Xie, et al. Expires June 18, 2012 [Page 9]
Internet-Draft Use Cases for ALTO with SDN June 2012
operators). In terms of management, the entity managing SDN
controller is the same as that managing the ALTO server. We
emphasize that when an SDN domain is dedicated to some customers of
a network carrier, the use of the SDN domain is owned by these
customers and so is the management. In this case, the SDN
controllers as ALTO clients are slightly more like legacy ALTO
clients. However, there still exist fundamental differences which we
will illustrate later.
3.2.2. Interactions between SDN and ALTO
Another difference is the interactions between SDN controllers as
ALTO clients and ALTO servers. Legacy ALTO clients retrieve
information from ALTO servers. However, SDN controllers may also
need to push information to ALTO servers.
In a carrier's network, SDN controllers and the ALTO server are
owned by the same carrier. Interactions between them could be
significantly more complex. The interactions can be divided into two
categories:
o Information flow from ALTO clients to ALTO servers
SDN controllers also open up the possibilities of conveniently
collecting network information and exporting such information to
ALTO servers. SDN controllers are at the best position to collect
network information. More importantly, it is an evitable
requirement that SDN controllers collect the information of the
networking devices in its domain.
In some scenarios, it is a requirement that information flow from
ALTO clients to ALTO servers. For instance, an SDN domain could be
dedicated to some of a carrier's certain customers; the usage of
such a domain gives privileged client access. However, such a
domain is an integral sub-network of the carrier's network. In
such a case, the ALTO server for the carrier's network is not able
to collect necessary information in a scalable, manageable way.
Even if we assume that the ALTO server can automatically pull
necessary information directly from networking devices, the
dedicated domain may disallow the ALTO server to do so, because
customers who own and manage this domain may enforce stringent
privacy policies and disallow exporting information externally.
The SDN controller is the best entity that can facility the
automation of information collection while at the same time
enforce the specific privacy policy.
o Information flow from ALTO servers to ALTO clients
Xie, et al. Expires June 18, 2012 [Page 10]
Internet-Draft Use Cases for ALTO with SDN June 2012
SDN controllers request information from ALTO servers, similar to
legacy ALTO clients. However, the requested information is
significantly different.
The fundamental difference is a result of SDN and SDN domain
division, which do not exist in legacy network application
scenarios. For instance, an SDN controller for a specific SDN
domain may be interested in obtaining internal information of
other SDN domains (provided that other domains allow to do so), or
obtaining domain-level information such as inter-SDN-domain
connectivity. None of these is applicable to legacy ALTO client
scenarios. As a result, ALTO server and its protocol should be
extended to support such scenarios.
3.2.3. Interactions between Legacy ALTO Clients and ALTO Servers
With the existence of SDN, the way that legacy network
applications (i.e., as legacy ALTO clients) interact with ALTO
servers is also different.
In legacy ALTO client/server scenarios, ALTO clients obtain cost
maps from ALTO servers, with the implicit assumption that ALTO
servers understand how the underlying network routes packets,
which allows ALTO servers to define or compute a cost metric
associated with a given route.
However, with the introduction of SDN, such assumption may no
longer hold, as SDN controllers may dynamically negotiate and
determine a route between two end points (which may belong to two
different SDN domains), especially when applications have specific
requirements for network resources (e.g., bandwidth, delay, etc).
Thus, in order for applications to best utilize the network
resources, the way that legacy ALTO clients communicate with ALTO
servers should be adapted to SDN.
3.3. Summary
In the context of SDN, due to the specific and unique properties of
SDN domains, SDN controllers as ALTO clients are significantly
different from legacy ALTO clients, posing new requirements for the
interactions between ALTO clients and ALTO servers.
We will subsequently illustrate the fundamental differences through
two sets of use cases, one for the information flow from ALTO
servers to ALTO clients, the other for the information flow from
ALTO servers to ALTO clients.
Xie, et al. Expires June 18, 2012 [Page 11]
Internet-Draft Use Cases for ALTO with SDN June 2012
4. Architecture
The preceding discussions on SDN and ALTO suggest we need to put
both SDN and ALTO in a coherent architecture.
4.1. Overview
According to the preceding discussions, SDN domains cover sub-
networks of a carrier's network, while the ALTO server covers the
carrier's network as a whole. Additionally, SDN domain controllers
could collect more fine-grained information, while the ALTO server
has only relatively coarse-grained information. Therefore, SDN
domains should be put under the ALTO server.
In addition, the two types of information flows between SDN
controllers and the ALTO server suggest that the ALTO server needs
inputs from SDN controllers as ALTO clients in order to disseminate
ALTO information. Therefore, SDN domain controllers should be put
under the ALTO server in the architecture.
The architecture is a hierarchical architecture consists of three
tiers. In the first tier, the only entity is the ALTO server. In the
second tier, the only entities are the SDN domain controllers. In
the third tier, the only entities are SDN domains (each domain
consists of numerous networking devices).
In this architecture, all entities are owned by a carrier. However,
some of the SDN domains (and the networking devices in them) may be
dedicated to certain customers of the carrier giving them privileges
access. This is subject to a collaboration agreement among carriers.
We refer to as the ``upward flow'' the information flow from the
second tier (SDN controllers as ALTO clients) to the first tier
(ALTO server), and refer to as the ``downward flow'' the information
flow in the reverse direction, i.e., from the first tier (ALTO
server) to the second tier (SDN controllers as ALTO clients).
4.2. Work Flow of SDN Controller
A network may consist of multiple SDN domains. Note that due to
operational or deployment concerns, there may exist networking
devices that do not belong to any SDN domain. In each SDN domain,
the SDN controller is responsible for the following tasks (only ALTO
related tasks are included below):
Xie, et al. Expires June 18, 2012 [Page 12]
Internet-Draft Use Cases for ALTO with SDN June 2012
o Collect fine-grain information from the networking devices it
manages. Such information could include, but not limited to, SDN
domain topology, link capacity, available bandwidth on each link,
links connected to external devices belonging to other SDN
domains.
o Implement pre-defined domain-specific policies. Such policies
could include, but not limited to, how resources should be
allocated, how the collected information should combined and
presented.
o Optionally aggregate the collected information for external view
purposes per its policies.
o Obtain cost maps at the granularity of SDN domains or obtain
internal cost maps for specific domains (if available), consult
for cross-domain data/forwarding plane recommendations from ALTO.
o Make (ALTO recommended) data/forwarding plane decisions based on
the cost maps obtained from ALTO.
4.3. Work Flow of Applications, SDN and ALTO
We now give three examples to describe a complete work flow, which
connects all key elements in an SDN.
4.3.1. SDN-aware Applications
o An application's end point sends a request for network resources
to the SDN controller it belongs to (i.e., the SDN controller for
the SDN domain where this application's end point belongs to).
The request should include the destination end point or the set
of destination end points, and a set of requirements on network
resources (e.g., bandwidth)
o The SDN controller obtains an SDN-specific cost map from the ALTO
server (this step may occur independent of remaining steps)
o The SDN controller uses the cost map and negotiate one or many
path(s) with other SDN controllers (since the path may span
across multiple SDN domains, thus all SDN controllers of the
involved domains should participate in setting up the paths)
o The SDN controller responds to the requesting application's end
point
Xie, et al. Expires June 18, 2012 [Page 13]
Internet-Draft Use Cases for ALTO with SDN June 2012
o If the requested path(s) are successfully set up, the
application's end point starts to communicate with the
destination end points
4.3.2. SDN-unaware Applications
SDN-unaware applications do not directly communicate with SDN
controllers. Instead, they follow special packet formatting rules to
encode the SDN-specific requests, and the SDN-compatible networking
devices pick up these requests and forward them the SDN controllers.
The remaining work flow is similar to the work flow of SDN-aware
applications, except that SDN controllers do not respond to the
requesting applications. Thus, when the requests cannot be satisfied,
SDN-unaware applications may suffer from packet losses, due to
networking devices process these applications' packets in a best
offer fashion.
4.3.3. Legacy Applications
Legacy applications can be greatly simplified, as it is unnecessary
and is not helpful for them to directly communicate with ALTO
servers any more:
o An end point of a legacy application sends a packet to a known
destination
o A SDN-compatible networking device picks up the packet; however,
if the path for the two end points has not been set up yet, the
SDN controller will be consulted
o The SDN controller obtains a cost map from the ALTO server (this
step may occur independent of remaining steps)
o The SDN controller negotiate with other SDN controllers to set up
a best-effort path for the requesting end point
o The forwarding rules for this path are pushed to all networking
devices that are on the chosen path
o Communications between the two end points continue; the
forwarding rules may expire if the communication is tore down
Xie, et al. Expires June 18, 2012 [Page 14]
Internet-Draft Use Cases for ALTO with SDN June 2012
In this case, legacy applications are relieved from the complexity
of dealing with the ALTO server using the ALTO protocol. ALTO-
related intelligence, which fundamentally belongs to the network
intelligence, is implemented in the network, rather than partly
outside the network.
4.4. Summary
It is worth noting that this architecture is fundamentally different
from common ALTO use cases such as ALTO in CDN or data center (DC).
The differences lie in that in the latter cases the components in
question (e.g., CDN or DC) are largely consumers of ALTO services,
while in the former case SDN domains are not only making decisions
that may affect ALTO and generating/aggregating information that
ALTO needs, but also the consumers of ALTO services. Furthermore, in
the former case, SDN domains are an integral part of the underlying
network infrastructure where their decisions could be treated as
constraints for ALTO; however, in the latter cases, the components
in question (e.g., CDN or DC) are apparently not necessarily
integral parts of the underlying network and their decisions could
be treated as recommended outcomes suggested by ALTO.
5. Use Case for Upward Flow
The upward flow delivers SDN domains' network information by SDN
controllers to the ALTO server. Each SDN controller is responsible
for collecting, aggregating, and submitting its own domain's network
information to the ALTO server.
Due to the possibility of some SDN domain being dedicated to certain
customers, we illustrate the upward flow in two use cases.
5.1. Unrestrictive Information Exporting
SDN domain controllers have to collect various network information
from the networking devices they manage no matter if ALTO exists or
not. The reason is that an SDN controller may have to make decisions
for allocating resources within its domain, and making such
decisions need various network information. Since such information
is readily collected and available, an SDN controller could submit
such information as is (or after simple processing) to the ALTO
server.
Take the available link bandwidth as an example (available link
bandwidth could be used as a measure of ``distance''). An SDN
Xie, et al. Expires June 18, 2012 [Page 15]
Internet-Draft Use Cases for ALTO with SDN June 2012
controller could periodically collect the available bandwidth on all
links in its domain and submit it to the ALTO server. However, such
information should be annotated with the domain information (e.g.,
domain ID). By submitting such information, later other SDN
controllers may request for this domain's available link bandwidth
information.
5.2. Restrictive Information Exporting
An SDN domain belonging to a carrier may be dedicated to certain
customers of that carrier. In this case, the dedicated users of an
SDN domain manage not only how resources should be allocated but
also what information should be exported.
A carrier may dedicate a set of small data centers (on multiple
sites) to its certain customer. These data centers are put under a
single SDN domain. The customer can manage the dedicated multi-site,
small data centers via the SDN controller. Periodically the SDN
controller collects network information from all data centers.
However, different than the former unrestrictive case, the customer
may have stringent privacy policies and therefore decide to
aggregate the collected information before submitting to the ALTO
server.
For instance, the customer may aggregate the information for a data
center network in the same site such that the data center network is
shrunk into a single node; by doing so, the multi-site data center
network is aggregated into a multi-node network topology, each node
in the topology actually corresponds to a small data center in
reality. The aggregated network topology could be annotated with
available link bandwidth information or other information that is
collected and allowed to be exported.
The customer's information aggregation policy defines how the
information should be pre-processed before exporting to the ALTO
server. The main purpose of aggregation is to protect privacy. As a
result of information aggregation, the exported network information
could be a logical topology (annotated with various network
information, e.g., distance or cost) which is totally different from
the physical topology.
Xie, et al. Expires June 18, 2012 [Page 16]
Internet-Draft Use Cases for ALTO with SDN June 2012
5.3. Information Aggregation
Without SDN, ALTO defines cost maps for an aggregated view of the
network topology, where the granularity of aggregation is determined
by the network carrier and could be either coarse-grain or fine-
grain.
However, with the introduction of SDN, such information aggregation
could be greatly simplified and should be policed based on the
policies defined for each SDN domain. For instance, ALTO only needs
to collect information from a pre-defined set of SDN domain
controllers, where the controllers determines at what granularity
they would like to aggregate the information and export them. In
addition, such aggregation is governed by the domain-specific
policies, which defines not only the granularity of aggregation but
also to whom such aggregated information may be exposed.
More specifically, an illustrative use case is as follows. SDN
controllers collect fine-grain information and aggregate it
periodically per their policies. ALTO is configured to obtain the
aggregated information from a set of SDN domain controllers and
obtain possibly raw information from networking devices (or the
network operation center). ALTO then constructs a complete view of
the overall network (an aggregated view of the network). SDN
controllers obtain cost maps from ALTO and apply such maps when
making data/forwarding plane decisions.
Another illustrative use case is as follows. SDN controllers may
choose to export fine-grain information to ALTO. After it obtains
the cost maps from ALTO, it could leverage the cost maps with
greater details about their own domains and make informed decisions.
However, SDN controllers should not overload ALTO by exporting too
much fine-grain information.
6. Use Case for Downward Flow
We illustrate the use of downward flow through several use cases as
follows.
Note that when the originating SDN domain's controller make
decisions for choosing path(s) and set up the path(s), each involved
SDN domain controller should map the overall decision to scoped
decisions specifically for their responsible domains.
Xie, et al. Expires June 18, 2012 [Page 17]
Internet-Draft Use Cases for ALTO with SDN June 2012
6.1. SDN-Aware QoS Metrics
We use two use cases to describe SDN-aware QoS.
When aggregating QoS information, SDN controllers or the information
aggregation policies should understand the semantics of each QoS
metrics. For instance, some metrics (e.g., delay) are additive,
while some others are multiplicative (e.g., packet loss rate). The
information aggregation policy should be flexible enough to specify
such details.
6.1.1. Use Case: On-Demand Bandwidth
An SDN-compatible application / source end-point may request for a
certain amount of end-to-end bandwidth to a destination end-point on
the fly. The two end points in question should be in the same
administrative domain, but they are not in the same SDN domain. The
path(s) set up for such a request span across multiple SDN domains.
The SDN controller of the source domain (i.e., the SDN domain where
the source end-point is located), referred to as the source SDN
controller, should first obtain the cost maps from the ALTO server.
Such cost maps are SDN-domain-specific, namely, the costs are
defined for pairs of SDN domains, rather than for pairs of end
points as in the legacy ALTO case.
The source SDN domain controller should then determine path(s) for
the two end points based on the cost maps and associated information
obtained from ALTO. More specifically, the controller should
o Compute a lowest-cost path at the SDN domain level using the
obtained SDN-domain-specific cost map
o Contact the controllers of those SDN domains on the selected path,
probing for the available bandwidth that could be dedicated to
the requested session
o Check if all of the selected path have sufficient combined
bandwidth that matches the required bandwidth
o if the combined bandwidth of all selected paths cannot match the
requirement, then go back to step 1 and select another lowest-
cost path (different than the already selected ones)
Xie, et al. Expires June 18, 2012 [Page 18]
Internet-Draft Use Cases for ALTO with SDN June 2012
o if no path can be selected and the combined bandwidth does not
match the requirement, the request cannot be satisfied
o if the combined bandwidth of all selected paths match the
requirement, then set up all selected paths by signaling all
involved SDN domain controllers. Note that the signaling protocol
and how to set up paths are beyond the scope of this document.
Data backup and migration among data centers, which typically
require bulk data transfers, is an example of on-demand bandwidth
use case. Data centers may be managed by one or multiple SDN domains;
thus bulk data transfer could be thought of as bulk data transfer
among multiple SDN domains.
6.1.2. Delay
Similar to the preceding use case, applications may request for
paths satisfying some certain QoS metrics, e.g., VoIP applications
may ask for paths with delay being lower than certain thresholds.
This requires that ALTO cost maps embed such information, and that
SDN controller should export such information to ALTO.
6.2. Content Delivery Networks (CDN)
Content Delivery Network (CDN) has been widely deployed to help
dissemination of content at the Internet scale. Network carries are
also deploying CDNs inside their own networks to improve the user
experiences of their customers. With the introduction of SDN, not
only legacy CDN but also a new SDN-based CDN can be seamlessly
implemented and integrated with the current network infrastructure.
Here is an example of the flow of SDN-enabled CDN.
Suppose that there are a set of CDN servers deployed in a carrier's
network and they are willing to be managed by SDN. An equivalent
class for each of the CDN server is defined by either the CDN
carrier or the network carrier (these two carriers can be the same).
An equivalent class is a set of IP addresses, one for a CDN server,
where if one can be used to fulfill requests for a specific content,
then any server in this class can also be used to serve the same
requests. In the extreme case, there is only one equivalent class
for all CDN servers.
Xie, et al. Expires June 18, 2012 [Page 19]
Internet-Draft Use Cases for ALTO with SDN June 2012
Then the pre-defined equivalent classes are pushed to the SDN
controllers, which leverage such information to select CDN servers
and set up paths for any end point to any such servers.
o A network client (e.g., an HTTP-based Web client) obtains the IP
address, referred to as A, of one of the CDN servers in the
carrier's network (e.g., by DNS queries)
o The client sends a first packet destined for A (for HTTP requests,
this packet is a TCP SYN packet)
o An SDN-compatible networking device picks up the packet
o If there are forwarding rules already set up for the
communication between the requesting client and the
destination A, then follow the rules to forward the request
packet
o Otherwise, forward the request packet to the SDN controller of
this domain
o Once receiving a forwarded packet from a networking device, the
SDN controller takes the following actions:
o Retrieves the equivalent class for the given destination A
o Obtains a cost map from the ALTO server (this step could take
place asynchronously)
o Ranks all CDN servers in the equivalent class according to the
cost map obtained from the ALTO server
o Selects the best CDN server, referred to as B, based on the
above ranking
o Negotiates and sets up a best-effort path to the selected CDN
server with other controllers
o Sets up forwarding rules for the path, and rewriting rules for
replacing the IP address of A with the IP address of B (so
that the client is actually communicating with B, although it
may think that it is communicating with A; however, which
server it communicates is not important)
o The request packet is forwarded to the chosen CDN server B,
subject to the forwarding rules and rewriting rules
Xie, et al. Expires June 18, 2012 [Page 20]
Internet-Draft Use Cases for ALTO with SDN June 2012
o The client communicates with the CDN server B
o The path and associated forwarding/rewriting rules are expired
when the communication is torn down (this step is irrelevant to
the ALTO extension for SDN, therefore, it is out of scope)
However, the above use case has two limitations. First, it violates
the TCP semantics; namely, the client intends to and believes that
it is communicating with server A, but actually it is communicating
with server B. Second, it has to rely on the capability of devices
being able to rewrite forwarding rules (e.g., use one IP address to
replace another one in a packet).
If the above two limitations become concerns, e.g., either TCP
semantics should not be violated or rewriting is not available or
both, the above SDN-enabled CDN use case can be implemented in
similar way, with the help of a redirection server. Below we
describe the steps that are different:
o A redirection server (or server farm), referred to as R, is set
up for redirecting client requests
o Each SDN controller sets up path(s) to the given redirection
server R
o Note that the redirection server could be an integral
component of an SDN controller (either collocated or
integrated), in which path(s) are not necessary
o Once receiving a forwarded packet from a networking device, the
SDN controller takes the following actions:
o Retrieves the equivalent class for the given destination A
o Obtains a cost map from the ALTO server (this step could take
place asynchronously)
o Ranks all CDN servers in the equivalent class according to the
cost map obtained from the ALTO server
o Selects the best CDN server, referred to as B, based on the
above ranking
o Sends the information of the chosen CDN server, i.e., its IP
address B, to the redirection server R
Xie, et al. Expires June 18, 2012 [Page 21]
Internet-Draft Use Cases for ALTO with SDN June 2012
o Negotiates and sets up a best-effort path to the redirection
server R (if R is not integrated with the SDN controller)
o Sets up forwarding rules for the path to R
o Negotiates and sets up a best-effort path to the CDN server B
o Sets up forwarding rules for the path to B
o The client communicates with the redirection server R
o R sends an HTTP redirection packet to the client, redirecting
future requests to the CDN server B (which is notified by the SDN
controller)
o The client communicates with the chosen CDN server B (note that
the path to B has been already set up)
6.3. Information-Centric Content Delivery Networks (IC-CDN)
Information-Centric Networking (ICN) is a "host-to-information"
communication model, different from the legacy "host-to-host" model
implemented by the Internet. Content Delivery Network (CDN) is more
of a "host-to-information" model (i.e., CDNs can be treated as a
special instance of ICN), but implemented in the "host-to-host"
model, due to the fact that the current semantics provided by the
Internet only support the "host-to-host" model.
With the introduction of SDN, CDNs can be converted into an
information-centric networking implementation:
o A CDN client sends a request for a specific content
o The request packet is formatted per the CDN in SDN
specification (beyond the scope of this draft), containing
the requested content name in the packet
destination (a specific anycast IP address) which is
reserved for legacy applications to invoke SDN
capabilities
(optional) QoS requirements (e.g., prefer fast/local
servers vs. slow/remote servers, demands are elastic or
not)
o An SDN-compatible networking device picks up the request packet
Xie, et al. Expires June 18, 2012 [Page 22]
Internet-Draft Use Cases for ALTO with SDN June 2012
o If there are forwarding rules set up for this content request
already, then follow the rules to forward the request packet,
and terminate this
o Otherwise, forward the request packet to the SDN controller
for this domain
o The SDN controller communicates with the CDN's name directory to
look up possible CDN servers that can satisfy the request
o The SDN controller obtains a cost map from the ALTO server
o The SDN controller applies the cost map to select the best CDN
server per the QoS requirements if specified in the request
o The SDN controller negotiate the path to the selected CDN server
with other controllers
o The SDN controllers that along the chosen path set up the path,
and push the forwarding rule(s) for this chosen path to all
networking devices that are involved
o The request packet is forwarded to the chosen CDN server
o Data packets flow back to the CDN client
In this use case, the CDN clients could be modified to send the
"information-centric" request. However, in a realistic
implementation, neither the CDN clients nor the CDN servers have to
be significantly modified (e.g., CDN redirection could be leveraged
to implement the above work flow).
7. Security Considerations
TBD.
8. IANA Considerations
This document makes no specific request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Xie, et al. Expires June 18, 2012 [Page 23]
Internet-Draft Use Cases for ALTO with SDN June 2012
9. Conclusions
In this draft, we identify the fundamental differences between
legacy ALTO client/server and ALTO client/server with the existence
of SDN. The introduction of SDN fundamentally changes the way that
the ALTO system works. We present an architecture that consists of
ALTO client/server, SDN controller, SDN domain and SDN applications.
We also define the main interactions existing in this architecture.
We further describe ALTO-related work flows in this architecture. We
then present a set of use cases to illustrate how we extend ALTO to
support SDN.
10. References
10.1. Informative References
[1] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V.,
"Abstracting network state in Software Defined Networks (SDN)
for rendezvous services", IEEE International Conference on
Communications (ICC) Workshop on Software Defined Networks
(SDN), June 2012.
[2] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M.
Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S.
Shenker, "Onix: A Distributed Control Platform for Large-scale
Production Networks", Proceedings of the 9th USENIX Symposium
on Operating Systems Design and Implementation (OSDI 10),
Vancouver, Canada, pp. 351-364, October 2010
Authors' Addresses
Haiyong Xie
Huawei & USTC
2330 Central Expy, Santa Clara, CA 95050
Email: Haiyong.xie@huawei.com
Tina Tsou (Ting Zou)
Huawei
2330 Central Expy, Santa Clara, CA 95050
Email: Tina.Tsou.Zouting@huawei.com
Xie, et al. Expires June 18, 2012 [Page 24]
Internet-Draft Use Cases for ALTO with SDN June 2012
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 84
Madrid 28006
Spain
Email: diego@tid.es
Hongtao Yin
Huawei
2330 Central Expy, Santa Clara, CA 95050
Email: Hongtao.yin@huawei.com
Contributors
The authors would like to thank Vijay K. Gurbani for his many
detailed reviews and helpful assistance on this draft.
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533
Naperville, IL 60566
USA
Email: vkg AT {acm.org,bell-labs.com}
Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
Xie, et al. Expires June 18, 2012 [Page 25]
Internet-Draft Use Cases for ALTO with SDN June 2012
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Xie, et al. Expires June 18, 2012 [Page 26]