Skip to main content

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

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 2012-07-09
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-01
Network Working Group                                         E. Stephan
Internet-Draft                                                S. Ellouze
Intended status: Standards Track                 France Telecom - Orange
Expires: January 10, 2013                                  July 09, 2012

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

Abstract

   The selection of a downstream CDN by an upstream CDN is based on
   multi-dimensional criteria such as the number of hops, the
   performance of the connections between the user-agent and downstream
   CDNs, the availability of downstream CDNs resources and business
   policies.  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.  This draft specifies
   the parameters of an ALTO session between two interconnected CDNs.

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 January 10, 2013.

Copyright Notice

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

Stephan & Ellouze       Expires January 10, 2013                [Page 1]
Internet-Draft              CDNi ALTO session                  July 2012

   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.

Stephan & Ellouze       Expires January 10, 2013                [Page 2]
Internet-Draft              CDNi ALTO session                  July 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  CDN1 views . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.2.  CDN2 views . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.3.  Map Maintenance  . . . . . . . . . . . . . . . . . . . . .  9
   3.  Requirements for an ALTO Session for CDNi  . . . . . . . . . .  9
     3.1.  ALTO Information Customization . . . . . . . . . . . . . .  9
     3.2.  View HTTP GET  . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Initialization of the Session  . . . . . . . . . . . . . . 10
     3.4.  Server Discovery . . . . . . . . . . . . . . . . . . . . . 10
     3.5.  Maps Update  . . . . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Information Resource Directory . . . . . . . . . . . . . . 11
     3.7.  Redistribution . . . . . . . . . . . . . . . . . . . . . . 11
     3.8.  PID Stability  . . . . . . . . . . . . . . . . . . . . . . 11
     3.9.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.10. Performance  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.11. Heart Beat . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.12. dCDN Traffic Optimization  . . . . . . . . . . . . . . . . 13
   4.  Specification of the ALTO Session for CDNi . . . . . . . . . . 13
     4.1.  ALTO session Framework . . . . . . . . . . . . . . . . . . 13
     4.2.  View Configuration . . . . . . . . . . . . . . . . . . . . 15
       4.2.1.  PoINT  . . . . . . . . . . . . . . . . . . . . . . . . 15
       4.2.2.  View Configuration Examples  . . . . . . . . . . . . . 15
     4.3.  Session Configuration Parameters . . . . . . . . . . . . . 16
     4.4.  Error Handling . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Incremental Update . . . . . . . . . . . . . . . . . . . . 17
       5.1.1.  Level of Details of a Map  . . . . . . . . . . . . . . 18
     5.2.  Bi-directional Exchange of Information . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

Stephan & Ellouze       Expires January 10, 2013                [Page 3]
Internet-Draft              CDNi ALTO session                  July 2012

1.  Introduction

   The selection of a downstream CDN by an upstream CDN is based on
   multi-dimensional criteria such as the number of hops, the
   performance of the connections between the user-agent and downstream
   CDNs, the availability of downstream CDNs resources and business
   policies.  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.  This draft specifies
   the parameters of an ALTO session between two interconnected CDNs.

   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 [I-D.ietf-cdni-problem-statement].  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
   [I-D.ietf-cdni-use-cases]).

   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.

   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.  Finally it discusses different enhancements of
   interest to a CDNi ALTO session.

   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
   [I-D.ietf-cdni-problem-statement], 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;

Stephan & Ellouze       Expires January 10, 2013                [Page 4]
Internet-Draft              CDNi ALTO session                  July 2012

      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;

   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.

Stephan & Ellouze       Expires January 10, 2013                [Page 5]
Internet-Draft              CDNi ALTO session                  July 2012

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

Stephan & Ellouze       Expires January 10, 2013                [Page 6]
Internet-Draft              CDNi ALTO session                  July 2012

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

   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"
              ]
            }
          }

Stephan & Ellouze       Expires January 10, 2013                [Page 7]
Internet-Draft              CDNi ALTO session                  July 2012

   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"
              ]
            }
          }
   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'.

Stephan & Ellouze       Expires January 10, 2013                [Page 8]
Internet-Draft              CDNi ALTO session                  July 2012

          "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

   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.

Stephan & Ellouze       Expires January 10, 2013                [Page 9]
Internet-Draft              CDNi ALTO session                  July 2012

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

   Currently [I-D.ietf-alto-protocol] (section 7.6.2 and 7.6.4.1) allows
   2 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.

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

   Maps update is under discussion in the ALTO WG as there is a strong
   need to optimize the volume of exchanged information and to reduce
   the duration of the acquisition of the updates.  ,
   [I-D.schwan-alto-incr-updates] presents solutions for incremental

Stephan & Ellouze       Expires January 10, 2013               [Page 10]
Internet-Draft              CDNi ALTO session                  July 2012

   update (download of update by the client).  Another possibility is
   the specification of a synchronous update procedure where the server
   pushes the updates on the fly towards the client.

   Incremental update and synchronous update may not be required for CDN
   interconnection when the customization of the session leads to a
   limited amount of information to be exchanged.  Nevertheless, the
   adCDN server must at least provide hints to each auCDN for reducing
   the volume of exchanged information.

   If no update mechanism is implemented, each view must include a
   information resource exposing a summary of the map updates (the list
   or the number of PIDs which were updated, etc).  This approach
   provides the client logic with enough information to decide whether
   to re-download the whole map or not (e.g. depending on the importance
   of the PIDs which were updated).

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

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

   Redistribution of network Map and Cost Map by an uCDN is forbidden
   because first it results on the exposition of information exclusively
   destined to a well defined entity and second others uCDNs must not be
   flooded with unwished information.

   The information exposed by dCDN to uCDN reflects only the agreement
   between the operators of these 2 CDNs only.  Hence, redistributing
   maps content will lead to inconsistency because the semantic of the
   information differs with the session.  As an example a PID name may
   cover different meaning or content.

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

Stephan & Ellouze       Expires January 10, 2013               [Page 11]
Internet-Draft              CDNi ALTO session                  July 2012

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

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

Stephan & Ellouze       Expires January 10, 2013               [Page 12]
Internet-Draft              CDNi ALTO session                  July 2012

   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.11.  Heart Beat

   Neither the ALTO server nor the ALTO client want the session to be
   overflooded.  A heart beat parameter is needed to control the
   intensity of the communication for exchanging information over the
   ALTO session.  It provides a hint of the periodicity of the download
   of the maps by the client (e.g. every minute, hour, day, week, etc).

   As an example to avoid useless maps download auCDN and adCDN might
   agreed to set the value of the heart beat to the period of
   refreshment of the considered maps.

3.12.  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.  ALTO session Framework

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

Stephan & Ellouze       Expires January 10, 2013               [Page 13]
Internet-Draft              CDNi ALTO session                  July 2012

      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 PID and Cost 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 the session
      PIDs and Cost 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 replace the Map
      Filtering service of the current version of the ALTO protocol.

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

Stephan & Ellouze       Expires January 10, 2013               [Page 14]
Internet-Draft              CDNi ALTO session                  July 2012

   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 the 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 a optionnal pre-generated Network Map
   Status.  The Network Map Status will be specified in the next version
   of the document.

   Note: Filters value are not exchanged over the network.
   Nevertheless, as ALTO Maps are JSON documents it is desirable to
   write the filter using JSON document filtering mechanisms like JSON
   pointer [I-D.pbryan-zyp-json-pointer].  In this memo the filters are
   defined using a syntax similar to JSON pointer but allowing wildcard
   (like W3C XPATH does).

4.2.2.  View Configuration Examples

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

   Note: View Configurations are internal to an ALTO Server.  They are
   not exchanged between the ALTO server and the ALTO Client.  In this
   section the View Configurations are writen in JSON to ease the
   reading only.

Stephan & Ellouze       Expires January 10, 2013               [Page 15]
Internet-Draft              CDNi ALTO session                  July 2012

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

{
   "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 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 (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, time scale of
   updates ).

Stephan & Ellouze       Expires January 10, 2013               [Page 16]
Internet-Draft              CDNi ALTO session                  July 2012

   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;

      views: a list of views;

      PoINTs;

      CoINTs;

      nmap_heartbeat: Order of magnitude of the periodicity of the
      download of the Network Maps by the client (e.g. every minute or
      every week);

      cmap_heartbeat: Order of magnitude of the periodicity of the
      download of the Cost Maps by the client (e.g. every minute or
      every week);

4.4.  Error Handling

   Errors are reported using legacy ALTO and HTTP errors.

5.  Enhancements

   The ALTO session presented in this memo relies on basic ALTO services
   to permit a good level of interoperability, performance and security
   and to help preserving individual CDN know-how.  This section
   discussed enhancements to a CDNi ALTO session.

5.1.  Incremental Update

   There are different ways to implement maps update
   [I-D.schwan-alto-incr-updates].  Two important aspects are to be
   considered: Improving the processing time in the ALTO client and
   providing auCDN with relevant updates.  An update based on the diff
   of JSON file entries is useful but not optimized with regard to the
   uCDN processing because it requires the re-processing of the whole
   map from scratch after each upload.  A better approach consists in
   defining an update mechanism providing the diff for a grouping of
   entries such as PIDs.

   The approach proposed in section 4.2.1 does not optimize the protocol
   but provide additionnal Information Resources to let the uCDN

Stephan & Ellouze       Expires January 10, 2013               [Page 17]
Internet-Draft              CDNi ALTO session                  July 2012

   optimizes it exchanges according to its logic.

5.1.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.  It may need
   the details later.

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

   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 parameters which
   set the level of detail of the maps.

5.2.  Bi-directional Exchange of Information

   In the CDNi context, tied interactions between an uCDN and a dCDN may
   be required.  As Discussed in section 3, there are different aspects
   requiring a Bi-directionnal exchange of information including:

      Network Map Update Notifications: The update mechanism based on
      HTTP download is sub-optimal when the uCDN requires a real time
      propagation of the updates.  Bi-directional interactions allow
      adCDN to notify auCDN with Network Map updates;

      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.

   One solution consists in upgrading the HTTP session to a bi
   directional protocol.  WebSocket Protocol [RFC6455] is one potential
   candidate.

Stephan & Ellouze       Expires January 10, 2013               [Page 18]
Internet-Draft              CDNi ALTO session                  July 2012

6.  IANA Considerations

   This document will request the registration of the media type
   corresponding to new information services introduced, if any.

7.  Security Considerations

   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.

   Know-how protection: unlike section 8 of [I-D.ietf-alto-protocol], an
   ALTO client is not allowed to redistribute information received from
   a ALTO server.

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

9.  References

Stephan & Ellouze       Expires January 10, 2013               [Page 19]
Internet-Draft              CDNi ALTO session                  July 2012

9.1.  Normative References

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

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

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

9.2.  Informative References

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

   [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-03 (work in progress),
              March 2012.

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-08 (work in
              progress), June 2012.

   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
              K., and G. Watson, "Use Cases for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-08 (work in
              progress), June 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.marocco-alto-next]

Stephan & Ellouze       Expires January 10, 2013               [Page 20]
Internet-Draft              CDNi ALTO session                  July 2012

              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.medved-alto-svr-apis]
              Medved, J., Ward, D., Peterson, J., Woundy, R., and D.
              McDysan, "ALTO Network-Server and Server-Server APIs",
              draft-medved-alto-svr-apis-00 (work in progress),
              March 2011.

   [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]
              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-01 (work in
              progress), March 2012.

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

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

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

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

Stephan & Ellouze       Expires January 10, 2013               [Page 21]
Internet-Draft              CDNi ALTO session                  July 2012

Authors' Addresses

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

   Email: emile.stephan@orange.com

    Selim Ellouze
   France Telecom - Orange
   2 avenue Pierre Marzin
   Lannion  F-22307
   France

   Email: selim.ellouze@orange.com

Stephan & Ellouze       Expires January 10, 2013               [Page 22]