Skip to main content

ALTO session for CDN Interconnection
draft-stephan-cdni-alto-session-ext-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Stephan Emile , Selim Ellouze
Last updated 2013-04-16
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-stephan-cdni-alto-session-ext-03
Network Working Group                                         E. Stephan
Internet-Draft                                   France Telecom - Orange
Intended status: Standards Track                              S. Ellouze
Expires: October 18, 2013                                          H-log
                                                          April 16, 2013

                  ALTO session for CDN Interconnection
                 draft-stephan-cdni-alto-session-ext-03

Abstract

   The selection of a downstream CDN by an upstream CDN is based on
   multi-dimensional criteria.  Various protocols, such as BGP or ALTO,
   may be used by a downstream CDN to expose content routing information
   and interconnection preferences to an upstream CDN.  The selection of
   such a protocol is premature as the WG, and especially the Footprint/
   Capabilities Design Team, is currently working on this topic.  So
   this draft does not promote the usage of the ALTO protocol for CDN
   interconnection.  It presents the limitations of the current ALTO
   protocol in the case it would be selected for CDN interconnection.
   It specifies the mechanism for controlling the session initialization
   and for limiting the information exchanged.  Then it discusses the
   need of incremental update and proposes to study the usage of Netconf
   /Yang to provide ALTO server with notifications.

Requirements Language

   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 RFC 2119 [RFC2119].

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 October 18, 2013.

Stephan & Ellouze       Expires October 18, 2013                [Page 1]
Internet-Draft             CDNi ALTO session                  April 2013

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  CDN1 views  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  CDN2 views  . . . . . . . . . . . . . . . . . . . . . . .   8
     2.3.  Map Maintenance . . . . . . . . . . . . . . . . . . . . .   8
   3.  Requirements for an ALTO Session for CDNi . . . . . . . . . .   9
     3.1.  ALTO Information Customization  . . . . . . . . . . . . .   9
     3.2.  View download with HTTP GET . . . . . . . . . . . . . . .   9
     3.3.  Initialization of the Session . . . . . . . . . . . . . .  10
     3.4.  Server Discovery  . . . . . . . . . . . . . . . . . . . .  10
     3.5.  Asynchronous Maps Update  . . . . . . . . . . . . . . . .  10
     3.6.  Information Resource Directory  . . . . . . . . . . . . .  10
     3.7.  PID Stability . . . . . . . . . . . . . . . . . . . . . .  11
     3.8.  Scalability . . . . . . . . . . . . . . . . . . . . . . .  11
     3.9.  Performance . . . . . . . . . . . . . . . . . . . . . . .  12
     3.10. dCDN Traffic Optimization . . . . . . . . . . . . . . . .  12
   4.  Specification of the ALTO Session for CDNi  . . . . . . . . .  12
     4.1.  CDNi ALTO session Framework . . . . . . . . . . . . . . .  12

Stephan & Ellouze       Expires October 18, 2013                [Page 2]
Internet-Draft             CDNi ALTO session                  April 2013

     4.2.  View Configuration  . . . . . . . . . . . . . . . . . . .  14
       4.2.1.  PoINT . . . . . . . . . . . . . . . . . . . . . . . .  14
       4.2.2.  View Configuration Examples . . . . . . . . . . . . .  14
     4.3.  Session Configuration Parameters  . . . . . . . . . . . .  15
     4.4.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  16
   5.  Expected Enhancements . . . . . . . . . . . . . . . . . . . .  16
     5.1.  Asynchronous Updates  . . . . . . . . . . . . . . . . . .  16
     5.2.  Incremental Download of the Updates . . . . . . . . . . .  16
       5.2.1.  Level of Details of a Map . . . . . . . . . . . . . .  16
     5.3.  Bi-directional Exchange of Information  . . . . . . . . .  17
   6.  ALTO Extension for Notification Exchange  . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     10.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   The selection of a downstream CDN by an upstream CDN is based on
   multi-dimensional criteria.  Various protocols, such as BGP or ALTO,
   may be used by a downstream CDN to expose content routing information
   and interconnection preferences to an upstream CDN.  The selection of
   such a protocol is premature as the WG, and especially the Footprint/
   Capabilities Design Team, is currently working on this topic.  So
   this draft does not promote the usage of the ALTO protocol for CDN
   interconnection.  It presents the limitations of the current ALTO
   protocol in the case it would be selected for CDN interconnection.
   It specifies the mechanism for controlling the session initialization
   and for limiting the information exchanged.  Then it discusses the
   need of incremental update and proposes to study the usage of Netconf
   /Yang to provide ALTO server with notifications.

   Currently the ALTO protocol is designed for the communication of
   network information to untrusted internet applications.  In the
   context of a CDN interconnection (CDNi) there is a certain level of
   trust, at least enough to mount a subset of the interfaces depicted
   in [RFC6707].  In practice the level of trust differs with each
   interconnection.  There are situations where a CDNi ALTO server has
   to exchange information with an ALTO client of an affiliate and with
   an ALTO client of a competitor (see [RFC6770]).

   In the first case topology hiding [RFC5693] may not be required.  In
   the second case the operator of a dCDN may consider a fine control of
   the exposed information.  Consequently the ALTO server of a dCDN
   operator must be able to adapt the information exposed to each uCDN.

Stephan & Ellouze       Expires October 18, 2013                [Page 3]
Internet-Draft             CDNi ALTO session                  April 2013

   The document discusses firstly the insightful aspects of such a use
   cases in section 2.  Then in section 3 it presents the motivations
   for specifying an ALTO session to customize the information exposed
   in each CDN interconnection.  In section 4, it provides a proposal
   for an appropriate specification of an ALTO session for a CDN
   interconnection.  Then in section 5 it discusses different
   enhancements of interest to a CDNi ALTO session.  Finally in the
   section it studies the usage of Netconf/Yang works to provide ALTO
   with server notifications.

   N.B.: this version of the memo covers only the Network Map.

1.1.  Terminology

   The reader must be familiar with the terminology given by the drafts
   [RFC6707], and [I-D.ietf-cdni-requirements] , and
   [I-D.ietf-alto-protocol].

   The following abbreviations are recalled:

      dCDN : downstream CDN: The CDN which provide the delivery
      resource;

      uCDN : upstream CDN: The CDN which may rely on dCDN server to
      deliver contents;

      PID : Provider-defined Network Location Identifier;

      NSP : Network Service Provider (e.g.  ISP connecting End User to
      Internet);

      ALTO Information Resource Directory: (Directory): The Information
      Resource Directory indicates to ALTO Clients which Information
      Resources are made available by an ALTO Server (section 7.6
      [I-D.ietf-alto-protocol] ).

   Following are terms and abbreviations introduced in the document:

      adCDN: ALTO downstream CDN server;

      auCDN: ALTO upstream CDN client;

      PIDs of Interest (PoINT) : The PIDs which are in the scope of an
      ALTO session or of a view.  They may be defined as a list or by a
      XSLT-like statement (e.g.  'map/*/ipv6');

      Costs of Interest (CoINT) : The Costs which are in the scope of an
      ALTO session or of a view;

Stephan & Ellouze       Expires October 18, 2013                [Page 4]
Internet-Draft             CDNi ALTO session                  April 2013

   ALTO Client-Server session: The logical association between an CDNi
   ALTO Client and an CDNi ALTO server which maintains the context
   across the ALTO HTTP connections made by the client to the server.

   View: A view is the set of URIs which provide an auCDN with a mean
   for downloading the maps reflecting an agreement between an uCDN and
   a dCDN.  A view is defined by PIDs of Interest (PoINT) and Costs of
   Interest (CoINT).

2.  Use Cases

   This section depicts a situation where a dCDN exposes information
   according to the agreements of each CDN interconnection.  The
   infomation is exposed within an ALTO session based on the current
   ALTO protocol version.  There is not time dependency between the
   content requests received by the upstream CDN and the information
   exchanged over the CDNi ALTO interface.

   To ease the reading, the content of the Network Maps is intentionally
   limited with regards to real situation.

   The use case is about a NSP which deployed a CDN named CDN0 over its
   network and where CDN0 acts as a downstream CDN for two CDNs named
   CDN1 and CDN2.  CDN1 is an affiliate of CDN0.

   In the figure 1, the network of NSP provides CDN0 with an aggregated
   view of the routing information.  The grouping of the routing
   information results from the processing of information provided by
   BGP according to various policies of the NSP (network, content
   distribution, etc).

     +----------------------------------+
     |             NSP                  |
     |                                  |
     |                                  |
     |             +---------+          |
     |             | Network |          |
     |             +---------+          |
     |                 |                |
     |                 |                |
     |              BGP|Info            |
     |                 |                |
     |                 |                |
     |         +-------V---------+      |
     |         | Community Tags, |      |
     |         |Grouping Policies|      |
     |         +-----------------+      |
     |                 |                |

Stephan & Ellouze       Expires October 18, 2013                [Page 5]
Internet-Draft             CDNi ALTO session                  April 2013

     |                 |                |
     |       Routing Information        |
     |                 |                |
     |                 |                |
     |       +---------V---------+      |
     |       |                   |      |
     |       |     CDN0 CDN      |      |
     |       |                   |      |
     |       +-------------------+      |
     +----------------------------------+

   Figure 1: Internal Routing Information

   The Figure 2 shows CDN0 acting as a dCDN for CDN1 and CDN2.  CDN0
   ALTO server (adCDN0) filters and sends stable Network and Cost Maps
   to the uCDN ALTO clients according to its policies and with respect
   to the peering agreement between the NSP and the operators of CDN1
   and CDN2.  adCDN0 is connected to 2 CDNi ALTO clients named auCDN1
   and auCDN2.

                                 +-----------------------------------------+
                                 |                  NSP                    |
                                 |                                         |
                                 |                                         |
                                 |                                         |
      +-----------+              |+--------------------+  +--------------+ |
      |           |   Cost Map   ||  dCDN ALTO server  |  |     CDN0     | |
      |   uCDN1   |<---------------       adCDN0       |  |              | |
      |           |              ||                    |  |              | |
      |   ALTO    |  network Map ||                    |  | +----------+ | |
      |  Client   |<---------------  +---------------+ |  | |Monitoring| | |
      |           |              ||  |               | |<---|  info    | | |
      +-----------+              ||  |Interconnection| |  | +----------+ | |
                                 ||  |  Policies     | |  | +----------+ | |
      +-----------+              ||  |               | |<---|          | | |
      |           |   Cost Map   ||  +---------------+ |  | |  Routing | | |
      |   uCDN2   |<---------------                    |  | |   Info   | | |
      |           |              ||                    |  | +----------+ | |
      |   ALTO    |  network Map ||                    |  |              | |
      |  Client   |<---------------                    |  |              | |
      |           |              |+--------------------+  +--------------+ |
      +-----------+              +-----------------------------------------+

   Figure 2: CDNs interconnection

Stephan & Ellouze       Expires October 18, 2013                [Page 6]
Internet-Draft             CDNi ALTO session                  April 2013

   The Figure 3 presents the internal representation of the Network Map
   computed by CDN0 ALTO server.

        "map" : {
         "PID_DSL" : {
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/25"
           ],
           "ipv6": [
             "2001:db8:0:1::/64",
           ]
           },
         "PID_FTTH" : {
           "ipv4" : [
             "198.51.100.128/25"
           ],
           "ipv6": [
             "2001:db8:0:2::/64"
           ]
         }
       }

   Figure 3: CDN0 internal Network Map

2.1.  CDN1 views

   CDN0 and CDN1 agreed that CDN1 needs only the IPv4 view of the
   Network Map.  The Network Map, presented in figure 4, is downloadable
   by CDN1 at the URI 'http://cdni.alto.example.com/CDN1/networkmap/
   ipv4'.

        "map" : {
         "PID_DSL" : {
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/25"
           ]
           },
         "PID_FTTH" : {
           "ipv4" : [
             "198.51.100.128/25"
           ]
         }
       }

Stephan & Ellouze       Expires October 18, 2013                [Page 7]
Internet-Draft             CDNi ALTO session                  April 2013

   Figure 4: CDN1 IPv4 Network Map view

2.2.  CDN2 views

   CDN0 and CDN2 have 2 separate agreements.  Both are relative to the
   geographical extension of CDN2 coverage . The first agreement
   concerns the exposition of FFTH customers only.  The second one
   covers IPv6 customers only.  They are reflected as separated Network
   Maps.  The first Network Map, exposed in figure 5, is downloadable by
   CDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/FTTH'.

        "map" : {
         "PID_FTTH" : {
           "ipv4" : [
             "198.51.100.128/25"
           ],
           "ipv6": [
             "2001:db8:0:2::/64"
           ]
         }
       }

   Figure 5: CDN2 FTTH Network Map.

   The second Network Map, exposed in the figure 6, is downloadable by
   auCDN2 at the URI 'http://cdni.alto.example.com/CDN2/networkmap/
   IPv6'.

       "map" : {
         "PID_DSL" : {
           "ipv6": [
             "2001:db8:0:1::/64",
           ]
           },
         "PID_FTTH" : {
           "ipv6": [
             "2001:db8:0:2::/64"
           ]
         }
       }

   Figure 6: CDN2 IPv6 Network Map

2.3.  Map Maintenance

Stephan & Ellouze       Expires October 18, 2013                [Page 8]
Internet-Draft             CDNi ALTO session                  April 2013

   auCDN1 and auCDN2 need a mean for maintaining the content of the
   maps.  The ALTO server of CDN0 provides each view with an URI towards
   a list of the PIDs which were really modified in the last update.
   Each dCDN can download this information and determine whenever or not
   it have to update the Network Map of this view again.

   This is not optimal.  Nevertheless it provides an update mechanism
   based on HTTP GET which contribute to the reduction of both the
   volume of information exchanged and the processing on each side.

3.  Requirements for an ALTO Session for CDNi

   This section motivates the necessity of specifying an ALTO session
   between a dCDN and a uCDN with adequate features for addressing CDN
   interconnection requirements.

3.1.  ALTO Information Customization

   The current ALTO approach excludes that the Maps exposed by the ALTO
   server differ according to the client.  This is enforced by section
   7.2.6 of [I-D.ietf-alto-protocol] which recommends ignoring HTTP
   session parameters and HTTP cookies.

   CDNi widely differs in such aspects because a dCDN operator must be
   able to adapt the information exposed to each uCDN according first to
   its policies and second to its agreements with uCDN.  Moreover it is
   important for a uCDN client to optimize the volume and the relevance
   of the information received by avoiding downloading unwanted
   information in order to enhance the performance of the processing of
   the received data.

   Consequently the customization of the ALTO interface between an uCDN
   and a dCDN requires the specification of a minimal set of session
   parameters.  This must be specified inside the CDNi WG to provide a
   minimal level of interoperabilty amongst CDNs.

3.2.  View download with HTTP GET

   Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows
   two Information Resources of the Information Resource Directory to
   match the same view of a map and to be downloadable using either an
   HTTP POST or a HTTP GET.

   In the context of ALTO session for CDNi this is not allowed.  An view
   of a map is accessible by an unique URI using HTTP GET request only.
   The session configuration defines all the information resources that
   an auCDN can download.

Stephan & Ellouze       Expires October 18, 2013                [Page 9]
Internet-Draft             CDNi ALTO session                  April 2013

3.3.  Initialization of the Session

   The setting of the session between an uCDN and a dCDN reflects their
   agreements and expectancies.  A minimal configuration of the session
   is required for ensuring an efficient initialization of the
   interface, for decreasing the service time, increasing the
   interoperability and improving the security.

   The exchange of the session configuration parameters can be performed
   either out-of-band (human settings) or through the CDNi Control
   interface.  In both cases the setting of a CDNi ALTO session requires
   an agreement between the 2 CDNs operators and a technical description
   of the session configuration (ALTO server and client addresses, URL,
   authentication methods, etc.), of the information which can be
   exchanged (PID of Interest, Cost of interest, level of details of the
   maps, etc) and of the way the information is exchanged (update
   method, time-scale for updates, etc ).

3.4.  Server Discovery

   The discovery of a dCDN server by a uCDN relies on parameters
   exchanged out-of-band or on the CDNi Control interface.  Consequenty
   a CDN interconnection does not require any discovery mechanisms like
   described in [I-D.ietf-alto-server-discovery].

3.5.  Asynchronous Maps Update

   The way the update is implemented is under discussion in the ALTO WG
   because there is a strong need to optimize the volume of information
   exchanged during the update, the processing of the information.
   [I-D.schwan-alto-incr-updates] presents solutions for incremental
   download where the auCDN download the diff of the Maps.

   Incremental download does not resolve the case where auCDN require to
   be informed in real time each time an information changes.  In this
   case, the adCDN must push the updates on the fly in notifications
   towards the auCDN.

3.6.  Information Resource Directory

   Section 7.6 of [I-D.ietf-alto-protocol] requires the availability of
   Information Resource Directory for exposing the Information Resources
   (i.e.  URIs of the maps).

Stephan & Ellouze       Expires October 18, 2013               [Page 10]
Internet-Draft             CDNi ALTO session                  April 2013

   In a CDNi interconnection it is not necessary to provide such
   directory as the two interconnected CDNs previously agreed on the URI
   names.  Besided, avoiding the exposition of URIs enhances the
   security of the system (see section 11.5.  [I-D.ietf-alto-protocol]
   ).

3.7.  PID Stability

   Currently ALTO servers scramble the prefixes among the PIDs to
   prevent reverse engineering by ALTO clients (
   [I-D.ietf-alto-protocol], section 12.1).

   CDNi situations differ widely in such aspects.  Such nondeterministic
   semantics is totally unusable by a request routing function of a
   uCDN, or may lead to suboptimal decision.  The dCDN must expose
   meaningful information to uCDN.  Consequently the meaning of the PIDs
   must not change during the session duration.

   As described in section 4.1 of
   [I-D.previdi-cdni-footprint-advertisement] a CDN acquires part of the
   content routing information from legacy BGP.  As given by figure 1,
   The NSP may use part of the community tags carried by its legacy
   internal BGP to filter and gather the prefixes in stable groups (see
   section 5.1.7 of [I-D.ietf-alto-deployments]) that may then by used
   by its internal CDN [I-D.jenkins-alto-cdn-use-cases].

3.8.  Scalability

   The routing function of an uCDN might not require all the information
   that an ALTO server of an dCDN might expose.  Furthermore, as by
   nature an uCDN interconnects with several dCDNs this volume might
   harm its performance and its reliability [I-D.ietf-alto-deployments].

   The same applies for dCDN ALTO server.  It must not be overloaded by
   uCDNs requests.

   Consequently the CDNi ALTO session will provide dCDN and uCDN with a
   mean to shape the information to exchange in an interoperable manner.
   For instance, an uCDN may not want to receive the very last detailed
   level of the network map of all the dCDNs it is interconnected with;
   it may not want to receive each update; it may be interested only by
   one cost type attribute of the Cost Map service, etc.

   N.B.: The situation will be even worse when the maps will include
   multi-cost as proposed by ( [I-D.randriamasy-alto-multi-cost] and
   [I-D.marocco-alto-next] section 3.2) because the size of the maps
   will increase.

Stephan & Ellouze       Expires October 18, 2013               [Page 11]
Internet-Draft             CDNi ALTO session                  April 2013

3.9.  Performance

   The amount of information to be processed impacts directly the
   performance of an auCDN.  As an example an uCDN does not want to
   download all the PIDs when it needs only the PIDs of the Endpoints
   managed directly by each dCDN.  Currently, as given by section 7.2.2.
   of [I-D.ietf-alto-protocol] , this is achieved using HTTP POST
   querying the ALTO Map Filtering Service or by HTTP GET of pre-
   generated maps.

   To optimize the performance the ALTO Map Filtering Service is not
   exposed.  Map filtering is accessible only throught HTTP GET toward
   pre-generated maps according to the configuration of the session
   agreed by the CDNs.  Consequently the ALTO session configuration must
   include must include filters (PIDs, cost, etc) to reduce the volume
   of information exchanged about to the PIDs of Interest (PoINT) and to
   the Cost of Interest (CoINT) agreed by uCDN and dCDN operators.
   These filters apply during all the duration of the ALTO session.

3.10.  dCDN Traffic Optimization

   Considering that ALTO is about traffic optimization at the
   application level, in the context of a CDNi interconnection between
   an uCDN and a dCDN, ALTO is capable of covering the exchange of
   information from dCDN to uCDN, allowing for the optimization of the
   delivery at the uCDN side only.  In contrast, exchanging information
   the other way around for allowing delivery optimization at the dCDN
   level is not addressed yet.

   Indeed a dCDN is subject to rival uCDNs requesting resources based on
   information exposed by the dCDN.  By exposing their constraints and
   their needs, the uCDNs requirements are better addressed by dCDNs
   through a smart resource provisioning and sharing.

   A uCDN should be able to provide dCDN with information that may help
   dCDN to optimize it resources.

4.  Specification of the ALTO Session for CDNi

   This section specifies the ALTO session for CDNi.

4.1.  CDNi ALTO session Framework

   The figure 7 presents the Framework of the ALTO Session for CDN
   interconnection:

Stephan & Ellouze       Expires October 18, 2013               [Page 12]
Internet-Draft             CDNi ALTO session                  April 2013

      The Map filtering logic is represented to reflect the
      customization of the content of the internal maps to the server
      according to the scope of the sessions with uCDNs.

      There are filters to limit the scope of the session with regard to
      the content of the internal maps content of the server.

      Network Map and Cost Map are unchanged.  Nevertheless session
      filtering applies to all the information exchanged;

      It does not require the support of the End point Information
      Services because an uCDN does not request individual endpoints
      information to a dCDN.

      The Sessions Handler maintains the logical association between an
      uCDN and a dCDN.  It controls the session according to the session
      parameters: It handles the filtering of the network Map and of the
      Cost Map according the PoINTs and of the CoINTs of the session.

      The Sessions Handler handles the views given by the configuration
      of the session.

      Information Services are accessible through HTTP GET messages
      only.

      A dCDN ALTO server does not expose the URIs nor provides an
      Information Resource Directory.

      The Map Filtering logic and the sessions handler are similar to
      the Map Filtering service of the current version of the ALTO
      protocol.

    .-------------------------------.
    |                               |
    |  .-----------. .-----------.  |
    |  |  Network  | |    Cost   |  |
    |  |   Map     | |    Map    |  |
    |  |           | |           |  |
    |  `-----------' `-----------'  |
    |                               |
    |  .-----------. .-----------.  |
    |  |  Sessions | |   Map     |  |
    |  |  Handler  | | Filtering |  |
    |  |           | |  logic    |  |
    |  `-----------' `-----------'  |
    |                               |
    `-------------------------------'

Stephan & Ellouze       Expires October 18, 2013               [Page 13]
Internet-Draft             CDNi ALTO session                  April 2013

   Figure 5: ALTO Protocol for CDN interconnection

4.2.  View Configuration

   Views are similar to pre-generated maps presented in the section
   7.6.3.  of [I-D.ietf-alto-protocol].  Their configurations are local
   to the ALTO server.

   The configuration includes a name, a PoINT and a CoINT.  A view
   provides an ALTO CLient with at least 2 Information Resources: the
   network map associated with the PoINT and the cost map associated
   with the CoINT.

   Its definition includes the setting of the URIs towards these pre-
   generated maps.

   N.B.: Cost of Interest (CoINT) will be defined in a next version fo
   the document.

4.2.1.  PoINT

   A PoINT applies at the view level.  It specifies a local filter tied
   to an URI which provides the ALTO client with a link to download the
   ouput of this filter (see examples in section 4.2.2).  It applies
   during all the duration of the session.

   This filter produces pre-generated maps.  The output of the filter is
   a pre-generated network map and an optionnal pre-generated Network
   Map Status.  The Network Map Status will be specified in a next
   version of the document.

4.2.2.  View Configuration Examples

   Following are the views corresponding to the use case of the section
   2.

   {
      "view"  : "ipv4",
      "point" : {
        "filter": "map/PID_*/ipv4" ,
        "map"   : "http://cdni.alto.example.com/CDN1/networkmap/ipv4"
        "map_status"   : "http://cdni.alto.example.com/CDN1/networkmap/ipv4/status"
      }
      "coint" : []
   }

   CDN1 IPv4 view

Stephan & Ellouze       Expires October 18, 2013               [Page 14]
Internet-Draft             CDNi ALTO session                  April 2013

   {
      "view"  : "FTTH",
      "point" : {
        "filter": "map/PID_FTTH" ,
        "map"   : "http://cdni.alto.example.com/CDN2/networkmap/FTTH"
        "map_status"  : "http://cdni.alto.example.com/CDN2/networkmap/FTTH/status"
      }
      "coint" : []
   }

   CDN2 FTTH view

   {
      "view"  : "IPv6",
      "point" : {
        "filter": "map/PID_*/IPv6" ,
        "map"   : "http://cdni.alto.example.com/CDN2/networkmap/IPv6"
        "map_status"  : "http://cdni.alto.example.com/CDN2/networkmap/ipv6/status"
      }
      "coint" : []
   }

   CDN2 IPv6 view

4.3.  Session Configuration Parameters

   The agreement between uCDN and dCDN operators defines the
   configuration set of the ALTO session.  The configuration of the ALTO
   interface between an uCDN and a dCDN requires the exchange of session
   parameters between the two CDNs operators.  This can be performed
   either out-of-band (by phone call, etc) or through the CDNi Control
   interface.  In both cases the setting of a CDNi ALTO session requires
   an agreement between the 2 CDNs operators and a technical description
   of the session configuration (Server addresses, URL, authentication
   methods, etc.), of the information which can be exchanged (PID
   filtering, level of details of the maps) and of the way the
   information is exchanged (update procedure, etc).

   The session configuration relies on the following parameters:

      connection: server and client addresses, URL base, authentication
      methods, etc.;

      session_filter: The PIDs which are in the scope of the session.
      The Cost parameters which are in the scope of the session;

Stephan & Ellouze       Expires October 18, 2013               [Page 15]
Internet-Draft             CDNi ALTO session                  April 2013

      views: a list of views;

4.4.  Error Handling

   Errors are reported using legacy ALTO and HTTP errors.

5.  Expected Enhancements

   This section discussed enhancements which might be required to
   improve a CDNi ALTO session.

5.1.  Asynchronous Updates

   In the CDNi context, there are tied interactions between an uCDN and
   a dCDN interconnected.  It requires generally a high level of
   synchronization of the Maps of the dCDN and of the uCDN.  The update
   mechanism based on HTTP download is sub-optimal when the uCDN
   requires a real time propagation of the updates.  To meet this
   requirement the adCDN must notify the update to adCDN.

5.2.  Incremental Download of the Updates

   Incremental download reduces the volume of the information exchanged.
   An update based on the diff of JSON file entries is useful but not
   optimized because it requires the re-processing of the whole map from
   scratch after each upload.  A better approach might consist in
   defining an update mechanism providing the diff for a grouping of
   entries such as PIDs.  T

   The drawback is that incremental download does not provide a high
   level of synchronization of the Maps of the dCDN and of the uCDN.

5.2.1.  Level of Details of a Map

   The level of information exchanged between a dCDN ALTO server and a
   uCDN ALTO client must be customizable in order to decrease the amount
   of exchanged data while providing the required information.

   uCDN may not need the full details of each entry map or it may need
   the details later.

   Furthermore there are cases where an uCDN needs only the list of the
   PIDs of dCDN (e.g.  the very detail of each PID of a Network Map is
   available over existing interfaces like BGP).

Stephan & Ellouze       Expires October 18, 2013               [Page 16]
Internet-Draft             CDNi ALTO session                  April 2013

   For these reasons an uCDN ALTO client should be allowed to get only
   the summary of the maps (e.g.  the list of the PIDs of a Network
   Map).  This can be achieved by defining additional session
   configuration parameters which set the level of detail of the maps.

5.3.  Bi-directional Exchange of Information

   As Discussed in section 3, there are different aspects requiring a
   Bi-directionnal exchange of information including:

      Exposition of uCDN constraints: Allowing an uCDN to inform dCDN
      about its high level constraints like forecast indications
      provides dCDN with valuable information for optimizing its
      resources provisioning;

      Session Customization: There are situations where an uCDN may
      require other Views or modify existing Views and where there is a
      high level of trust between the two CDNs.  Consequently the ALTO
      session might support the modification of the Views by the auCDN.

6.  ALTO Extension for Notification Exchange

   There are many ways to address the enhancements expected in the
   section 5.

   One solution consists in upgrading the HTTP session to a bi-
   directional protocol.  WebSocket Protocol [RFC6455] is one potential
   candidate as it 'provides an alternative to HTTP polling for two-way
   communication'.  Nevertheless carrying Maps update in notifications
   directly over WebSocket Protocol comes with an open issue
   [I-D.marocco-alto-ws] because [RFC6455] does'nt specify a
   notification mechanism.

   Netconf [RFC6241] and YANG [RFC6020] works fill this gap.
   [I-D.iijima-netconf-websocket-ps] is specifying the carrying of
   Netconf over Websocket.

   Netconf already include the specification of notifications [RFC6470]
   based on subscriptions [RFC5277].  Maps update information might be
   simple to insert into Netconf notifications as JSON object can be
   modeled in [I-D.lhotka-yang-json].

7.  IANA Considerations

   none.

8.  Security Considerations

Stephan & Ellouze       Expires October 18, 2013               [Page 17]
Internet-Draft             CDNi ALTO session                  April 2013

   This memo defines an ALTO session for CDN interconnection.  It
   specifies a mean to manage finely the information exchanged over the
   ALTO protocol.  By reducing the information exposed it increase the
   security in general.

   Performance:

   The usage of the ALTO services by the client may stress the server.
   Consequently the volume and the number of these messages may affect
   the availability and the performance of the ALTO server.

   Despite the information services provide an uCDN ALTO client with
   means to control the amount of information downloaded from a dCDN
   ALTO server it should protect itself from the download of huge
   network map.

   Privacy:

   The extension has less privacy concerns than the current ALTO
   specification because it does not require the support of the End
   point Information Services.

9.  Acknowledgments

   Part of this work is funded by the EU FP7 Envision project.

   The authors would like to thank Christian Jacquenet for its feedbacks
   on preliminary versions of this document.

10.  References

10.1.  Normative References

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

   [I-D.ietf-cdni-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements", draft-ietf-cdni-
              requirements-06 (work in progress), April 2013.

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

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, September 2012.

Stephan & Ellouze       Expires October 18, 2013               [Page 18]
Internet-Draft             CDNi ALTO session                  April 2013

   [RFC6770]  Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
              K., and G. Watson, "Use Cases for Content Delivery Network
              Interconnection", RFC 6770, November 2012.

10.2.  Informative References

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

   [I-D.ietf-alto-server-discovery]
              Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              S. Yongchao, "ALTO Server Discovery", draft-ietf-alto-
              server-discovery-08 (work in progress), March 2013.

   [I-D.iijima-netconf-websocket-ps]
              Iijima, T., Kimura, H., Atarashi, Y., and H. Higuchi,
              "NETCONF over WebSocket", draft-iijima-netconf-websocket-
              ps-04 (work in progress), October 2012.

   [I-D.jenkins-alto-cdn-use-cases]
              Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
              S. Previdi, "Use Cases for ALTO within CDNs", draft-
              jenkins-alto-cdn-use-cases-03 (work in progress), June
              2012.

   [I-D.lhotka-yang-json]
              Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka-
              yang-json-01 (work in progress), June 2012.

   [I-D.marocco-alto-next]
              Marocco, E. and V. Gurbani, "Extending the Application-
              Layer Traffic Optimization (ALTO) Protocol", draft-
              marocco-alto-next-00 (work in progress), January 2012.

   [I-D.marocco-alto-ws]
              Marocco, E. and J. Seedorf, "WebSocket-based server-to-
              client notifications for the Application-Layer Traffic
              Optimization (ALTO) Protocol", draft-marocco-alto-ws-01
              (work in progress), July 2012.

   [I-D.pbryan-json-patch]
              Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work
              in progress), December 2011.

   [I-D.pbryan-zyp-json-pointer]

Stephan & Ellouze       Expires October 18, 2013               [Page 19]
Internet-Draft             CDNi ALTO session                  April 2013

              Bryan, P. and K. Zyp, "JSON Pointer", draft-pbryan-zyp-
              json-pointer-02 (work in progress), October 2011.

   [I-D.penno-alto-cdn]
              Penno, R., Medved, J., Alimi, R., Yang, R., and S.
              Previdi, "ALTO and Content Delivery Networks", draft-
              penno-alto-cdn-03 (work in progress), March 2011.

   [I-D.previdi-cdni-footprint-advertisement]
              Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
              L. Faucheur, "CDNI Footprint Advertisement", draft-
              previdi-cdni-footprint-advertisement-02 (work in
              progress), September 2012.

   [I-D.randriamasy-alto-multi-cost]
              Randriamasy, S., Roome, B., and N. Schwan, "Multi-Cost
              ALTO", draft-randriamasy-alto-multi-cost-07 (work in
              progress), October 2012.

   [I-D.schwan-alto-incr-updates]
              Schwan, N. and B. Roome, "ALTO Incremental Updates",
              draft-schwan-alto-incr-updates-02 (work in progress), July
              2012.

   [NETCONF_YANG_TUT]
              , "Network Conguration Management with NETCONF and YANG",
              , <http://cnds.eecs.jacobs-university.de/slides/
              2012-ietf-84-netconf-yang.pdf>.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

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

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6244]  Shafer, P., "An Architecture for Network Management Using
              NETCONF and YANG", RFC 6244, June 2011.

Stephan & Ellouze       Expires October 18, 2013               [Page 20]
Internet-Draft             CDNi ALTO session                  April 2013

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

   [RFC6470]  Bierman, A., "Network Configuration Protocol (NETCONF)
              Base Notifications", RFC 6470, February 2012.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

   [WS_API]   , "The WebSocket API", ,
              <http://www.w3.org/TR/2011/WD-websockets-20110929/>.

Authors' Addresses

    Emile Stephan
   France Telecom - Orange
   2 avenue Pierre Marzin
   Lannion  F-22307
   France

   Email: emile.stephan@orange.com

    Selim Ellouze
   H-log
   5 rue Guy Moquet
   Orsay  F-91400
   France

   Email: selim.ellouze@h-log.fr

Stephan & Ellouze       Expires October 18, 2013               [Page 21]