Internet DRAFT - draft-xie-alto-sdn-extension-use-cases

draft-xie-alto-sdn-extension-use-cases






Internet Engineering Task Force                                   H. Xie
Internet-Draft                                             Huawei & USTC
Intended status: Informational                                   T. Tsou
Expires: July 13, 2013                                      Huawei (USA)
                                                                D. Lopez
                                                          Telefonica I+D
                                                                  H. Yin
                                                            Huawei (USA)
                                                         January 9, 2013


           Use Cases for ALTO with Software Defined Networks
               draft-xie-alto-sdn-extension-use-cases-01

Abstract

   The introduction of SDN fundamentally changes the way that the
   application layer traffic optimization (ALTO) works.  This draft
   describes two architectures, the Vertical Architecture and the
   Horizontal Architecture, allowing coherent coexistence of ALTO and
   software defined network (SDN).  Unique requirements for design and
   operations are identified and summarized, suggesting that the
   Vertical Architecture allows better division, management,
   flexibility, privacy control and long-term evolution of the network.
   We also define the main interactions and information flows, and
   present a set of use cases to illustrate how we extend ALTO to
   support SDN, in the Vertical Architecture.

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 July 13, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the



Xie, et al.               Expires July 13, 2013                 [Page 1]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.








































Xie, et al.               Expires July 13, 2013                 [Page 2]

Internet-Draft           ALTO Use Cases For SDN             January 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  An Overview of Software Defined Network  . . . . . . . . . . .  5
     2.1.  Software Defined Network and Applications  . . . . . . . .  5
     2.2.  Division of Network  . . . . . . . . . . . . . . . . . . .  6
     2.3.  SDN Domain . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Architectures for Co-existing SDN and ALTO . . . . . . . . . .  9
     3.1.  ALTO Changes Due to SDN  . . . . . . . . . . . . . . . . .  9
       3.1.1.  ALTO Scopes  . . . . . . . . . . . . . . . . . . . . .  9
       3.1.2.  ALTO clients . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  The Vertical and Horizontal Architectures  . . . . . . . . 11
     3.3.  Interactions between SDN and ALTO  . . . . . . . . . . . . 13
       3.3.1.  Downward Interaction . . . . . . . . . . . . . . . . . 13
       3.3.2.  Upward Interaction . . . . . . . . . . . . . . . . . . 14
     3.4.  Interactions between Legacy ALTO Clients and ALTO
           Servers  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Information Flows  . . . . . . . . . . . . . . . . . . . . . . 15
     4.1.  Information Flow of SDN Controller . . . . . . . . . . . . 15
     4.2.  Information Flow of Applications, SDN and ALTO . . . . . . 16
       4.2.1.  SDN-aware Applications . . . . . . . . . . . . . . . . 16
       4.2.2.  SDN-unaware Applications . . . . . . . . . . . . . . . 17
       4.2.3.  Legacy Applications  . . . . . . . . . . . . . . . . . 17
     4.3.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.  Messaging  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Service Negotiation  . . . . . . . . . . . . . . . . . . . 18
     5.2.  Status Report (Upward Information Flow)  . . . . . . . . . 18
     5.3.  ALTO Message Dissemination (Downward Information Flow  . . 19
   6.  Use Case for Co-existing SDN and ALTO  . . . . . . . . . . . . 19
     6.1.  Use Case for Upward Flow . . . . . . . . . . . . . . . . . 19
       6.1.1.  Unrestrictive Information Exporting  . . . . . . . . . 20
       6.1.2.  Restrictive Information Exporting  . . . . . . . . . . 20
       6.1.3.  Information Aggregation  . . . . . . . . . . . . . . . 21
     6.2.  Use Case for Downward Flow . . . . . . . . . . . . . . . . 21
       6.2.1.  SDN-Aware QoS Metrics  . . . . . . . . . . . . . . . . 22
       6.2.2.  Content Delivery Networks (CDN)  . . . . . . . . . . . 23
       6.2.3.  Information-Centric Content Delivery Networks
               (IC-CDN) . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 27
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   12. Informative References . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28





Xie, et al.               Expires July 13, 2013                 [Page 3]

Internet-Draft           ALTO Use Cases For SDN             January 2013


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.  For instance, some SDN
   technologies have started to find their ways into Data Center
   Networks (DCNs).  Furthermore, in order to allow efficient and
   flexible implementation of 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 limited in
   relatively small segments of a bigger network.  In other words, it is
   likely that the operator of a large-scale enterprise / carrier
   network prefers to divide the whole networks into multiple smaller
   segments and put each of there segments in an SDN domain.  These
   smaller network segments (therefore their corresponding SDN domains)
   are connected and jointly form the larger 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



Xie, et al.               Expires July 13, 2013                 [Page 4]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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; such
   interactions are characterized by open interfaces which allow
   programming the network equipment's forwarding plane by external
   agents, e.g., SDN controllers.  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 capable (i.e., SDN
   capable devices implement the control/forwarding plane separation and
   the open interfaces allowing external agents to program the devices)
   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., normal devices).  Note that such normal devices
   could still be SDN capable and their control/forwarding planes are
   managed as in normal networks today.  This implies that a network
   with both normal devices and SDN capable devices (managed by SDN
   domains) needs both normal and SDN capable control/forwarding plane
   management.


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.

2.1.  Software Defined Network and Applications

   We refer to as an "SDN" a carrier's or an enterprise's network which
   deploys or implements software defined networking technologies.



Xie, et al.               Expires July 13, 2013                 [Page 5]

Internet-Draft           ALTO Use Cases For SDN             January 2013


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

   There are two types of applications in software defined networks:

   o  SDN-aware applications: applications 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).  Applications that
      are SDN-aware may be able to better utilize the SDN capable
      network due to its knowledge about SDN and its capability of
      proactive, direct interaction with SDN.

   o  SDN-unaware applications: applications indirectly communicate with
      SDN controllers by sending application protocol datagrams with
      specific formats, via which the application can specify its
      requirements for the network resources.  Legacy applications
      (applications for the current IP networks) are largely SDN-
      unaware, and such applications may not be able to utilize the SDN
      capable networks as efficiently as SDN-aware applications.

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

      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



Xie, et al.               Expires July 13, 2013                 [Page 6]

Internet-Draft           ALTO Use Cases For SDN             January 2013


      controller, multiple controllers have to be deployed.  Hence, the
      network is divided into multiple sub-networks; if a sub-network
      has SDN capable 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 capable); 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

      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.



Xie, et al.               Expires July 13, 2013                 [Page 7]

Internet-Draft           ALTO Use Cases For SDN             January 2013


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 capable.  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 [1].

   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 connectivity among
   underlying devices provided by the underlying network; such devices
   belong to different SDN 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 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



Xie, et al.               Expires July 13, 2013                 [Page 8]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   interactions between SDN and ALTO, and therefore designing the
   protocols to enable such interactions.


3.  Architectures for Co-existing SDN and ALTO

   In this section, we first compare the ALTO scopes without and with
   the existence of SDN, and then describe two architectures for co-
   existing SDN and ALTO.

3.1.  ALTO Changes Due to SDN

   SDN incurs significant changes to ALTO scopes and clients.  We
   describe the major differences below.

3.1.1.  ALTO Scopes

   The existence of SDN differentiates two scopes of ALTO, namely,

   o  The current scope of ALTO without SDN (referred to as 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.

   o  The new scope of ALTO with coherent coexistence of SDN (referred
      to as 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 server provides
      information to the controller, as suggested by [2].  However, if



Xie, et al.               Expires July 13, 2013                 [Page 9]

Internet-Draft           ALTO Use Cases For SDN             January 2013


      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 sections.  Furthermore, the design
      originally for the compressed space could be instantiated for the
      unfolded space but could not be as efficient.

3.1.2.  ALTO clients

   We next focus on the SDN-friendly Scope and highlight the complex
   structures and the important differences.

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



Xie, et al.               Expires July 13, 2013                [Page 10]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.  The Vertical and Horizontal Architectures

   We now introduce two architectures that allow coherent co-existence
   of SDN and ALTO in this section:

   o  the Vertical Architecture (or the V Architecture for short) allows
      better division, management, flexibility, privacy control and
      long-term evolution of the network.

      The Vertical Architecture is illustrated in the following figure.
      The network has one or multiple SDN domains and an ALTO server.
      The interactions between the SDN controllers and the SDN capable
      devices fall in the scope of SDN and therefore is out of the scope
      of this draft; instead, the interactions between the SDN domains
      (more specifically, SDN controllers) and the ALTO server is what
      this draft focuses on.

   .----------------------------------------------.
   |                ALTO Server                   |
   `----------------------------------------------'
                             ^            |
   .-------------|------------|-------------------.
   |             |            V                   |
   |     .-------------------------------.        |
   |     |          SDN Controller       |        |
   |     `-------------------------------'        |
   |                    |                         |
   |                    |                         |
   |     .-------------------------------.        |
   |     |       SDN Capable Devices     |        |
   |     `-------------------------------'        |
   |                                              |
   |                        An SDN Domain         |
   `----------------------------------------------'

      The Vertical Architecture is a hierarchical architecture
      consisting 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 the same carrier.
      However, some of the SDN domains (and the networking devices in



Xie, et al.               Expires July 13, 2013                [Page 11]

Internet-Draft           ALTO Use Cases For SDN             January 2013


      them) may be dedicated to certain customers of the carrier (the
      carrier gives the customers privileges access).  This is subject
      to a collaboration agreement between them.

   o  the Horizontal Architecture (or the H Architecture for short)
      simplifies the implementation of ALTO extensions for SDN.  The
      Horizontal Architecture is illustrated in the following figure.
      Each SDN controller is integrated with an ALTO server.  The
      interactions between the SDN controllers and the ALTO server is
      represented by the horizontal line in the figure.  An example of
      this architecture can be found in [2].


 .---------------------------------------------------------------------.
 |   .--------------------------.       .--------------------------.   |
 |   |     SDN Controller       |<----|        ALTO Server         |   |
 |   `--------------------------'       `--------------------------'   |
 `-----------------|---------------------------------------------------'
                                   |
 .-------------------------------.
 |       SDN Capable Devices     |
 `-------------------------------'

      In the Horizontal Architecture, the SDN controller can act as an
      ALTO client and query the network information of the networking
      devices from the ALTO server.  However, such network information
      may not meet the SDN controllers' granularity requirement (i.e.,
      the information provided by the ALTO server may not be as fine-
      grained as needed by the SDN controllers).  In addition, there may
      exist redundant information collection, as SDN controllers are
      inevitably collecting various fine-grain information from the
      devices they manage; the information collection by the ALTO
      server, either mannully or automatically, is likely to be
      redundant.  Furthermore, when the carrier decides to divide its
      network into multiple SDN domains, it can be difficult, if not
      impossible at all, for the Horizontal Architecture to adapt to the
      network division.

   The ALTO server covers a carrier's network as a whole; however, if
   the carrier divide the network into multiple SDN domains, each SDN
   domain covers only a segment of the network.  Additionally, the ALTO
   server has only relatively coarse-grained information, while SDN
   domain controllers could easily collect more fine-grained
   information.  More importantly, different SDN domains may implement
   different information aggregation and privacy policies (e.g., when
   such domains are dedicated to certain customers of the carrier).

   These observations suggest that the Vertical Architecture is



Xie, et al.               Expires July 13, 2013                [Page 12]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   advantageous over the Horizontal Architecture.  With the Vertical
   Architecture, SDN and ALTO are explicitly separated and as a result
   the logic is cleaner and this allows them to evolve independently.
   Furthermore, the Vertical Architecture makes automated information
   collect possible for ALTO, which could make ALTO deployment and
   management easier and more attractive.  Therefore, in the remainder
   of this draft, we mainly focus on the Vertical Architecture.  We will
   describe the interactions and the information flows in further
   details for the Vertical Architecture.

3.3.  Interactions between SDN and ALTO

   The interactions between SDN controllers (as ALTO clients) and ALTO
   servers are significantly different.  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 between the SDN controllers and the ALTO server can
   be divided into two categories.  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).

3.3.1.  Downward Interaction

   The downward interaction is the information flow from ALTO servers to
   ALTO clients (i.e., SDN controllers).  Each SDN controller is also an
   ALTO client and retrieves relevant network information from the ALTO
   server.  This is similar to the current scope of ALTO without the
   existence of SDN; however, the differences are that with the
   existence of SDN, the network information is generally specific to
   SDN and SDN domains; SDN controllers as ALTO clients could query the
   ALTO server for either inter-domain or intra-domain network
   information (provided that intra-domain information is reported and
   made available).

   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



Xie, et al.               Expires July 13, 2013                [Page 13]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   scenarios.

3.3.2.  Upward Interaction

   The upward interaction is the information flow from ALTO clients
   (i.e., SDN controllers) to ALTO servers.  SDN controllers 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 inevitable requirement that SDN
   controllers collect the information of the networking devices in its
   domain.  Each SDN controller may collect network information from the
   devices managed by it and information from other SDN controllers),
   and report such information to the ALTO server, subject to the
   information aggregation and privacy policies defined for the
   corresponding individual SDN domain.  Such network information is
   referred to the inter-domain network information.  The network
   information could include key information such as domain-level
   network cost, bandwidth, domain-specific connectivity, etc.  The
   upward interactions could be implemented in either the push model or
   the pull model.

   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.

   It is worth noting that network information collection has not been
   explored, and that network information collection could introduce
   significant overhead and complexity, in the current scope of ALTO.
   However, automated network information collection is a key to the
   success of ALTO.  With the help of SDN and the Vertical Architecture,
   such automated network information collection becomes feasible and
   appealing.  Note that this does not exclude the possibility of
   network operators manually or automatically update the ALTO server
   with the network information (e.g., the network cost map).  It is
   also worth noting that an SDN controller may choose to report its
   domain-specific network information only (referred to as the intra-



Xie, et al.               Expires July 13, 2013                [Page 14]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   domain information), with or without privacy policies.  In this case,
   SDN controllers become an automated information collector for the
   ALTO server.

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


4.  Information Flows

   We now further describe the two different information flows through
   two sets of use cases, one for the information flow from ALTO servers
   to ALTO clients, the other for the information flow from SDN
   controllers to ALTO servers.

4.1.  Information 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):

   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.





Xie, et al.               Expires July 13, 2013                [Page 15]

Internet-Draft           ALTO Use Cases For SDN             January 2013


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

   o  If the requested path(s) are successfully set up, the
      application's end point starts to communicate with the destination
      end points.








Xie, et al.               Expires July 13, 2013                [Page 16]

Internet-Draft           ALTO Use Cases For SDN             January 2013


4.2.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 capable 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 effort fashion.

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

   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.







Xie, et al.               Expires July 13, 2013                [Page 17]

Internet-Draft           ALTO Use Cases For SDN             January 2013


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

   The information exchanged between the SDN domain controllers and the
   ALTO server is encoded and implemented by specific messaging
   mechanisms.  Below we describe a preferred messaging mechanism where
   we focus mainly on the semantics of the messages.

   Based on the ALTO services, there are two-way message exchanges
   between the SDN controller and the ALTO server.  NBI is used and
   should be adapted to accommodate such message exchanges.  The concept
   of SDN domain is enforced by the controller if its policy defines so;
   therefore, the controller can opt to export the relevant information
   at policy-specific granularities.

5.1.  Service Negotiation

   SDN Domain controllers can communicate with the ALTO server to
   negotiate any or all of the service information described in the next
   two subsections.  After negotiation, such information can be pulled
   from or pushed to ALTO server depending further on the communication
   mechanism provided by NBI.  Further, the detail mechanism of
   consuming the above information will depend on the types of ALTO
   services being offered and not be covered by this use case.

5.2.  Status Report (Upward Information Flow)

   o  network "node" information (its granularity is specified by
      controller's policy), mainly including network and/or geographical
      location, services, etc





Xie, et al.               Expires July 13, 2013                [Page 18]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   o  network "topology" information (at a granularity specified by
      controller's policy), mainly including SDN-domain-level
      (interdomain) topology and an abstract SDN intradomain topology if
      any; if the policy allows, controller can also export detailed
      intradomain topology (the granularity should be specified by the
      policy).

   o  network "link" information, similar to "node" and "topology", such
      information (e.g., link usage and state like congestion, delay,
      cost etc) is policed by the controller's policy and could be
      exported at different levels of granularity

   o  network "routing" information, for flows defined in flow tables,
      at the policy-specified granularity

   o  path information, about the path initiation and status policed by
      controller's policy.

5.3.  ALTO Message Dissemination (Downward Information Flow

   It is important to note that the vanilla ALTO service (i.e., cost map
   or path cost information) is no longer directly applicable to the
   context of co-existing SDN and ALTO.

   In vanilla ALTO service scenarios, paths (i.e., routing between any
   pair of routers) are deterministic a prior, regardless of ALTO
   recommendations.  However, in the context of co-existing SDN and
   ALTO, routing is to be determined based on many factors including
   ALTO.  For instance, the routing between any pair of two SDN capable
   routers may not be fully determined when the SDN domain controller(s)
   query ALTO service for recommendations.

   o  network path-cost map at the granularity of SDN domains (keep in
      mind that the routing path may not be finalized when ALTO is
      consulted, as the flow table may not be propagated for the given
      flows).

   o  selection or preferences of one or multiple paths among a set of
      paths at the granularity of SDN domains; selected/preferred paths
      can have defined priority and/or failover definitions;


6.  Use Case for Co-existing SDN and ALTO

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



Xie, et al.               Expires July 13, 2013                [Page 19]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.

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

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



Xie, et al.               Expires July 13, 2013                [Page 20]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.

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



Xie, et al.               Expires July 13, 2013                [Page 21]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.

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

   An SDN capable 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)

      *  if no path can be selected and the combined bandwidth does not
         match the requirement, the request cannot be satisfied.





Xie, et al.               Expires July 13, 2013                [Page 22]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.

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

   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)





Xie, et al.               Expires July 13, 2013                [Page 23]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   o  An SDN capable 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:

      *  Retrieves the equivalent class for the given destination A

      *  Obtains a cost map from the ALTO server (this step could take
         place asynchronously)

      *  Ranks all CDN servers in the equivalent class according to the
         cost map obtained from the ALTO server

      *  Selects the best CDN server, referred to as B, based on the
         above ranking

      *  Negotiates and sets up a best-effort path to the selected CDN
         server with other controllers

      *  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

   o  The client communicates with the CDN server B

   o  The path and associated forwarding/rewriting rules are expired whe
      n 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).




Xie, et al.               Expires July 13, 2013                [Page 24]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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:

      *  Retrieves the equivalent class for the given destination A

      *  Obtains a cost map from the ALTO server (this step could take
         place asynchronously)

      *  Ranks all CDN servers in the equivalent class according to the
         cost map obtained from the ALTO server

      *  Selects the best CDN server, referred to as B, based on the
         above ranking

      *  Sends the information of the chosen CDN server, i.e., its IP
         address B, to the redirection server R

      *  Negotiates and sets up a best-effort path to the redirection
         server R (if R is not integrated with the SDN controller)

      *  Sets up forwarding rules for the path to R

      *  Negotiates and sets up a best-effort path to the CDN server B

      *  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)



Xie, et al.               Expires July 13, 2013                [Page 25]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   o  The client communicates with the chosen CDN server B (note that
      the path to B has been already set up)

6.2.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 capable networking device picks up the request packet

   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



Xie, et al.               Expires July 13, 2013                [Page 26]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   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.  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
   works.  We present the Vertical Architecture and the Horizontal
   Architecture to allow coherent coexistence of SDN and ALTO.  We
   believe that the Vertical Architecture allows better division,
   management, flexibility, privacy control and long-term evolution of
   the network.  Therefore we mainly focus on the Vertical Architecture
   in this draft.  We also define the main interactions and information
   flows, and present a set of use cases to illustrate how we extend
   ALTO to support SDN, in the Vertical Architecture.


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


9.  Acknowlegements

   The authors would like to thank Tom Taylor and Aditi Vira for editing
   the draft.



Xie, et al.               Expires July 13, 2013                [Page 27]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   This memo is based upon work supported in part by the National
   Science Foundation of China (NSFC) under Grant No. 61073192 and the
   China 973 Program under Grant No. 2011CB302905.  Any opinions,
   findings and conclusions or recommendations expressed in this
   material are those of the authors and do not necessarily reflect the
   views of NSF.


10.  Security Considerations

   TBD.


11.  IANA Considerations

   This document makes no specific request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


12.  Informative References

   [1]  Koponen, T., Casado, M., Gude, N., Stribling, J., Poutievski,
        L., Zhu, M., Ramanathan, R., Iwata, Y., Inoue, H., Hama, T., 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.

   [2]  Gurbani, V., Scharf, M., Lakshman, T., and V. Hilt, "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.


Authors' Addresses

   Haiyong Xie
   Huawei & USTC
   2330 Central Expy
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Haiyong.xie@huawei.com





Xie, et al.               Expires July 13, 2013                [Page 28]

Internet-Draft           ALTO Use Cases For SDN             January 2013


   Tina Tsou
   Huawei (USA)
   2330 Central Expy
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Tina.Tsou.Zouting@huawei.com


   Diego R. Lopez
   Telefonica I+D
   Don Ramon de la Cruz, 84
   Madrid,   28006
   Spain

   Phone:
   Email: diego@tid.es


   Hongtao Yin
   Huawei (USA)
   2330 Central Expy
   Santa Clara, CA  95050
   USA

   Phone:
   Email: Hongtao.yin@huawei.com























Xie, et al.               Expires July 13, 2013                [Page 29]