Internet DRAFT - draft-song-alto-usecase-ext

draft-song-alto-usecase-ext







ALTO                                                             H. Song
Internet-Draft                                                    Y. Lee
Intended status: Informational                                    Huawei
Expires: January 16, 2014                                       V. Lopez
                                                                D. Lopez
                                                          Telefonica I+D
                                                                 L. Deng
                                                                 W. Chen
                                                            China Mobile
                                                           July 15, 2013


             Extension Use Cases and Requirements for ALTO
                     draft-song-alto-usecase-ext-00

Abstract

   This document describes new usecases for ALTO, and identifie its
   related requirements to extend the ALTO protocol.  The use cases in
   this document include overlay routing, NaaS, data center information,
   and P2P cache.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Song, et al.            Expires January 16, 2014                [Page 1]

Internet-Draft                 usecase ext                     July 2013


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases and Requirements  . . . . . . . . . . . . . . . . .   3
     3.1.  Minor Extensions in ISP or Overlay Network  . . . . . . .   3
       3.1.1.  Overlay Routing . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Inter NSP ASQ . . . . . . . . . . . . . . . . . . . .   5
       3.1.3.  Network As A Service (NaaS) . . . . . . . . . . . . .   6
       3.1.4.  P2P Cache . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Data Center Network . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Data Center Network Deployment  . . . . . . . . . . .   9
       3.2.2.  VM Migration Between Data Centers . . . . . . . . . .  10
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     4.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   ALTO protocol [I-D.ietf-alto-protocol]provides an interface to
   applications with appropriate information to guide an optimal node
   selection when there are more than one application nodes providing
   the same service.  It usually aggregates network locations into PIDs,
   and assigns lower cost value for a PID pair that are topologically
   close.  So when application node follows the advice from ALTO server
   to choose one resource provider with a PID that has lower cost from
   its own PID, with higher probability the application node can keep
   the content request and response traffic flow intra domain, which can
   reduce the suffering increasing interdomain traffic for ISPs, and
   avoid the congestion in the backbone network.  More factors for node
   selection can be considered, such as pricing, congestion, and etc.

   The existing ALTO protocol has its limitations too.  For example, in
   a cost map it only gives one cost value between source PID and
   destination PID, assuming there is only one path between them.  But
   it can be routed through different paths in overlay routing.  So we
   propose to add a "via" parameter as an extension to the cost map.  In
   this document, we give use cases first, and then the possible way to
   extend the ALTO protocol to achieve it.





Song, et al.            Expires January 16, 2014                [Page 2]

Internet-Draft                 usecase ext                     July 2013


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  And the
   following terms used in this document have their definitions below.

   I2AEX: Infrastructure to Application Exposure.

   ALTO: application layer traffic optimization.  For ALTO protocol,
   please refer to . [I-D.ietf-alto-protocol]

   IaaS: Infrastructure as a Service.  One common IaaS service is
   leasing virtual machines with appropriate bandwidth to tennants.

   NaaS: Networking as a service.  The common NaaS services include
   dynamic VPN service, virtual network service, and etc.

   AP: a wireless access point (WAP) is a device that allows wireless
   devices to connect to a wired network using WLAN.  The AP usually
   connects to a AC as a standalone device, but it can also be an
   integral component of the router itself.

   AC: a wireless access controller (WAC) is the network entity that
   provides wire access via APs to the network infrastructure in the
   data plane, control plane, management plane, or a combination
   therein.

   Fowarding Cache: is a traditional content cache, which caches content
   flows from outside its coverage and serves subsequent requestors
   under its coverage for the content.

   Reverse Cache: is a special content cache proposed for WLAN accessing
   networks, which caches content flows from inside its coverage and
   serves subsequent requests from outside its coverage for the content.

   Bidirectional Cache: is a combination of a forwarding cache and a
   reverse cache.

   Cooperative Cache: is a content cache deployed by network operators
   in cooperation with specific content deliverying SPs (e.g. P2P
   streaming services), which participates in the overlay's service
   provision explicitly.

3.  Use Cases and Requirements

3.1.  Minor Extensions in ISP or Overlay Network




Song, et al.            Expires January 16, 2014                [Page 3]

Internet-Draft                 usecase ext                     July 2013


3.1.1.  Overlay Routing

   An overlay network is a computer network which is built on the top of
   another network.  Nodes in the overlay can be thought of as being
   connected by virtual or logical links, each of which corresponds to a
   path, perhaps through many physical links, in the underlying
   network[overlay_network].  One example of overlay netwok over IP
   network is CDN network.  A CDN network consists of many CDN nodes
   with different levels.  One edge CDN node often needs to pull content
   from another node that is in a higher distribution level position in
   the CDN topology.  There usually can be several paths to send the
   content from the source CDN node to the edge CDN node.  One way
   obviously is the direct IP routing.  And if the direct routing path
   is not good, then the source CDN node will select another CDN node as
   the intermediate node to transport the content to the that
   destination edge node, which will be more efficiency than the direct
   routing path.  Of course, there are usually more than one
   intermediate node available, and the source CDN node needs to select
   a "best" one.

   In some cases, there can also be a VPN tunnel between two CDN nodes
   to transfer contents.

                                 /--------\
                             |///          \\\|
                            |      CDN Node    |
                             |\\\      1   ///|\
                                 \-+------/|    \\
                                   |       |      \
                                  |        |       \\  overlay routing
                                           |         \
                 direct Internet routing   |          \\
                                           |            \
                                 |         |             \\
            /--------\          |          |          /----\---\
         ///          \\\       |          |      |///          \\\|
        |     CDN Node   |      \          |     |      CDN Node    |
         \\\      2   ///        \         |      |\\\      3   ///|
            \--------/           \         |          \--------/
                                  \   VPN tunnel           /
                                  \        |              /
                                   \       |             /
                                    \      |
                                    \      |          / overlay routing
                                     \     |         /
                                    /------+-\      /
                                |///          \\\| /
                               |      CDN Node    |



Song, et al.            Expires January 16, 2014                [Page 4]

Internet-Draft                 usecase ext                     July 2013


                                |\\\      4   ///|
                                    \--------/



     Figure 1. different ways for sending content from Node 1 to Node 4


   So the transport between two overlay nodes can be from:

      direct routing

      one/more intermediate overlay nodes

      a VPN tunnel

   The proposed extension is to add a "via" parameter to each cost
   value, and the value of the "via" parameter can be "direct routing",
   or location identifiers that can represent intermeidate overlay nodes
   (such like IP address), or "VPN".

3.1.2.  Inter NSP ASQ

   This use case is similiar to the overlay routing use case.  When two
   ASes are connected through more than one pairs of border gateway
   routers, then there are more than one paths from a node in one of
   these two ASes to another node in the other AS.  And these paths
   through different pair of border routers may have different service
   quality.  An ALTO server can contemplate the service quality through
   the locations in one AS to its different boarder gateways, and
   between boarder gateways, and through the other boarder gateway to
   network locations in the other AS, and then provide guidance to
   applications to choose an appropriate path for the service routing.

        +------------------+              +------------------+
        |   Edge NSP A     |              |    Edge NSP B    |
       node----            |              |                  |
        | -    -------     |     PoI      |                node
        |   -         ----BG--------------BG                 |
        |     -     Path 1 |              | \                |
        |       -          |              |  \               |
        |         -        |              |   \            node
       node         -      |              |     \            |
        |             -    |     PoI      |      \           |
        |      Path 2   - BG-------------BG-      \          |
        |                  |              |  -      \        |
       node                |              |    -     \    node
        |                  |              |       -   \      |



Song, et al.            Expires January 16, 2014                [Page 5]

Internet-Draft                 usecase ext                     July 2013


        |                  |              |         -  \     |
        |                  |     PoI      |           -  \   |
      node                BG-------------BG             --\node
        |                  |              |                  |
      node                 |              |                  |
        |                  |              |                node
        +------------------+              +------------------+


                    Figure 2 Inter-NSP ASQ use case


   The "via" extension is also proposed to be used for this use case,
   and the value of it can be the identifier of the boarder gateway.

3.1.3.  Network As A Service (NaaS)

   Network As A Service (NaaS) enables network operators to give
   connectivity service to multiple users on top of the same physical
   infrastructure.  This connectivity service can be offered to
   different customers, which have an interface to request for more
   bandwidth to the network in case they need more capacity.  Although
   end users may have an interface to request for bandwidth to the
   network, an interface is required to disseminate to the end points
   with the changes in the network configuration.  There are two options
   to disseminating information using ALTO protocol:

   o  Dissemination of bandwidth information.  ALTO can inform with a
      cost map related to unreserved bandwidth so end points can decide
      which connections they may use depending on the capacity in the
      connections.  This can be used to update routing tables in the end
      points or priorities to interconnect two end points.  Due to the
      dynamicity of traffic, this unreserved bandwidth is based on
      administrative reservations done through control plane protocols
      like RSVP-TE.

   o  Bandwidth pricing.  ALTO protocol can disseminate a cost map
      related to price of the connectivity between locations (such like
      PIDs).  This information can be used to advertize customers, which
      is the cost to request for more bandwidth between two locations
      periodically.  This can change depending on links utilization in
      the physical infrastructure.  The cost advertize by ALTO is not
      directly the price charged to the customer, but a cost related to.

3.1.4.  P2P Cache

   Efforts have been put on using forwarding caches to reduce P2P
   traffic in cross domain scenarios, which demonstrates great



Song, et al.            Expires January 16, 2014                [Page 6]

Internet-Draft                 usecase ext                     July 2013


   improvement in user experience and considerable cost reduction at
   interworking points.  What's more, bidirectional caches are proposed
   to be deployed at the AC level for mitigation of undesirable downlink
   congestion caused by consistent uplink P2P traffic, as shown in
   Figure 5, the reverse cache can provide uploading service instead of
   the WLAN peers under the AC's coverage.

        +--------------+                +------+
        | ISP 1 network+----------------+Peer 1|
        +-----+--------+                +------+
              |
     +--------+------------------------------------------------------+
     |        |                                      ISP 2 network   |
     |  +----------------+                +------------------+       |
     |  |Interworking GW |----------------| Forwarding Cache |       |
     |  +-----+----------+                +------------------+       |
     |        |                                                      |
     |        |                                                      |
     |  +-----+------+                +---------------------+        |
     |  |    AC      +----------------+ Bidirectional Cache |        |
     |  +-----+------+                +---------------------+        |
     |        |                                                      |
     |        +-------------------------------+                      |
     |   +----+------+                  +-----+-----+                |
     |   |   AP_1    |     . . . .      |   AP_n    |                |
     |   +----+------+                  +-----+-----+                |
     |        |                               |                      |
     +--------+-------------------------------+----------------------+
              |                               |
           +--+----------+                    |
           |             |                    |
        +--+--+       +--+--+              +--+--+
        |Peer2|       |Peer3|              |Peer4|
        +-----+       +-----+              +-----+


                Figure 1: Architecture of T/B-cache in WLAN

   With various P2P caches deployed, especially at a position as low as
   the AC-level, it could be sub-optimal to simply use the accessing
   network type as the divider for different PIDs and assign sufficient
   high cost within the wireless PID to prefer accessing remote peers
   over local peers blindly.  Therefore, it is expected that the
   cooperation between the network operator and the P2P SP in buiding up
   cooperative caching system and sharing information through ALTO
   protocol about these facilities bring benefits to both parties.





Song, et al.            Expires January 16, 2014                [Page 7]

Internet-Draft                 usecase ext                     July 2013


   A straightforward proposal would be to use locations of caches as
   dividers of different DIPs to further partition intra-ISP network
   domain and mark costs among them according to the location and type
   of relevant caches.  However, as there is both CAPEX and OPEX
   expenditures for dedicated P2P Cache devices, it may be cost-
   efficient for caches to make buffering/serving decisions based on the
   popularity of the specific content.  In addition, in cooperative
   mode, a P2P cache may be under the content scheduling of the specific
   P2P SP instead of the direct control of the network operator.  How to
   expose this application-relevant information to ALTO under such
   context is an open issue.

   Luckily, in the cooperative-mode, a cache is playing as a normal peer
   under the tracker, and the latter can make the "right" decision in
   choosing in favor of the former under the guidance of the ALTO
   response while the tracker itself would take care of the content
   availability problem.  If the cache doesn't have the content in
   question, it would no appear in the peer list handed in to ALTO
   server by the tracker.

   In this case, the ALTO server can collect the information about
   caching sub-system in the network, identify those "caching" peers in
   the peer list of an cost request from an ALTO client, and arrange the
   returned rank list accordingly.  For example, a simple candidate-
   ranking policy for a cost query to a WLAN peer, could be caching
   peers at the begining, then inside wired peers, and lastly outside
   wired peers.

   Moreover, the P2P SP and WLAN network operator may benefit even more
   by group popular files accroding to peers' geographic location or
   access types, and adapt its internal caching scheduling decisions
   about which files to be cached on which spot.  In other words, it
   would be helpful that the ALTO server provides the client with the
   requesting peer's subscription types (i.e. wired/WLAN/ celluar/...)
   as well as geographic locations.

   The proposed extension to ALTO is to distinguish peers not only
   according to IP prefixes, but also peer's access types and whether
   it's a caching server or not.  This kind of information can be
   acquired through network management system or application system.
   And it also requires that for endpoint property lookup, "exact
   matching" has higher priority than "IP prefix matching".









Song, et al.            Expires January 16, 2014                [Page 8]

Internet-Draft                 usecase ext                     July 2013


3.2.  Data Center Network

3.2.1.  Data Center Network Deployment

   Infrastructure as a service (IaaS) is a way how the data center
   provides its services.  There are different kinds of resources in a
   data center, physical machines, virtual machines, switches,
   firewalls, computing power, storage space, and electric power.  The
   draft [I-D.lee-alto-ext-dc-resource] proposes collecting data center
   resource information to make use of such information for a key
   decision to allocate the application request to an "optimal" Data
   Center location in which to host the application request.  Key
   constraints in this decision include resource availability (e.g.,
   memory, storage, CPU, etc.), DC network cost, DC network resource
   constraints (e.g., bandwidth), structure constraints (e.g., Data
   Center power consumption) and others.

   Combined computing and network resource optimization is of value to
   both application owners and data center operators.  For example a
   data center operator with multiple buildings in a metropolitan area
   may also want to balance compute and network costs.

                                                   Collect DC information
                                                      +----------+
                               +--------------+       | ALTO     |
             Resource Request  | Application  |       | Server   |
                  -----------> | Orchestrator |      /+----------+
                               +-------+------+    /
                                       |         /
        +--------+                +----+----+  /            +--------+
        |        |                |         |/              |        |
        |  DC 1  |<-------------->|  ALTO   |<------------->|  DC 2  |
        |        |                | Client  |               |        |
        +--------+                +---------+               +--------+
                                      /|\
                                       |
                                       |
                                       |
                                      \|/
                                  +---------+
                                  |         |
                                  |  DC 3   |
                                  |         |
                                  +---------+

        Figure 3  Data Center Resource Deployment use case





Song, et al.            Expires January 16, 2014                [Page 9]

Internet-Draft                 usecase ext                     July 2013


   The intended ALTO protocol extension is going to provide the
   following informaiton:

       Data Center Identifier (DCI)
       Data Center Location Identifier (e.g., IP address of the
        gateway node)
       Time Stamp
       Abstracted Memory Usage
       Abstracted CPU Level
       Abstracted Power Consumption Level
       DC Network cost
       DC Network resource constraints


3.2.2.  VM Migration Between Data Centers

   Giant or large applications usually have to rent virtual machine
   resources in more than one data centers for its application
   deployment.  These virtual machines do not only communicate with the
   end users, but also with other virtual machines.  Some applications
   rent dedicated VPN links for the traffic among data centers, and some
   applications pay money for the traffic among data centers that go
   through Internet.  There is a requirement to collects each VM traffic
   pattern and direction among data centers, and consider them together
   with the traffic pricing information, and use some specific
   algorithm, to give advice on VM migration.  For example, the
   algorithm may let the VMs that have much communication traffic
   migrate into one data center, so as to reduce the traffic among data
   centers, and save money for the application.

   A new "cost type" extension is proposed in ALTO, which represents the
   cost between VMs, with regarding to the combined traffic volume and
   pricing information.  An application uses ALTO client to retrieve
   this kind of information, and consider it together with the location
   and any specific contraints of each VM, then decide whether to
   migrate VMs that have high cost valume between each other into one
   single data center, so as to reduce inter-DC traffic.

   The actual use case is far more complex than the figure below.
   Because each VM may communicate with multiple VMs, and a more complex
   algorithm should be used for the VM migration.  The application have
   to compute the new total cost after the migration and compare it with
   that before the migration.

           +----------+                     +------------+
           |          |                     |  DC 2      |
           |   DC 1   |                     |            |
           | +---+    |  average: 2Mbps     |+---+       |



Song, et al.            Expires January 16, 2014               [Page 10]

Internet-Draft                 usecase ext                     July 2013


           | |VM1|----+---------------------+|VM2|  ---+ |
           | +---+    |                     |+---+ |VM3| |
           |          |          |          |      +---+ |
           +----------+          |          |            |
                                 |          +------------+
     ----------------------------+----------------------------------
                                 |
                                 |
           +----------+         \|/         +----------+
           |          |                     |          |
           |   DC 1   |                     |   DC 2   |
           | +---+    |                     |   +---+  |
           | |VM1|    +                     +   |VM3|  |
           | +-+      |                     |   +---+  |
           |   |2Mbps |                     |          |
           | +-+-+    |                     +----------+
           | |VM2|    |
           | +---+    |
           +----------+

                 Figure 4: Inter-DC VM migration use case


4.  References

4.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [overlay_network]
              , "overlay network", .

              http://en.wikipedia.org/wiki/Overlay_network

4.2.  Informative References

   [I-D.lee-alto-ext-dc-resource]
              Lee, Y., Bernstein, G., and D. Dhody, "ALTO Extensions for
              Collecting Data Center Resource Information", draft-lee-
              alto-ext-dc-resource-02 (work in progress), July 2013.

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
              ietf-alto-protocol-16 (work in progress), May 2013.






Song, et al.            Expires January 16, 2014               [Page 11]

Internet-Draft                 usecase ext                     July 2013


   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693, October
              2009.

   [I-D.ietf-alto-deployments]
              Stimerling, M., Kiesel, S., and S. Previdi, "ALTO
              Deployment Considerations", draft-ietf-alto-deployments-06
              (work in progress), February 2013.

Authors' Addresses

   Haibin Song
   Huawei

   Email: haibin.song@huawei.com


   Young Lee
   Huawei

   Email: leeyoung@huawei.com


   Victor Lopez
   Telefonica I+D

   Email: vlopez@tid.es


   Diego R. Lopez
   Telefonica I+D

   Email: diego@tid.es


   Lingli Deng
   China Mobile

   Email: denglingli@chinamobile.com


   Wei Chen
   China Mobile

   Email: chenwei@chinamobile.com






Song, et al.            Expires January 16, 2014               [Page 12]