Internet DRAFT - draft-bertrand-cdni-footprint-discovery

draft-bertrand-cdni-footprint-discovery






Internet Engineering Task Force                              G. Bertrand
Internet-Draft                                   France Telecom - Orange
Intended status: Informational                         September 3, 2012
Expires: March 7, 2013


                        CDN Footprint Discovery
               draft-bertrand-cdni-footprint-discovery-01

Abstract

   Interconnected CDNs need to exchange information on the set of end-
   users to which they can deliver content.  This information is
   commonly referred to as "CDN Footprint".  This memo presents use
   cases for CDN Footprint Discovery in CDNI.  It provides a survey of
   existing work on the subject and a set of additional requirements for
   controlling the exchange of Footprint information.

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 March 7, 2013.

Copyright Notice

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

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



Bertrand                  Expires March 7, 2013                 [Page 1]

Internet-Draft           CDN Footprint Discovery          September 2012


   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use-Cases for Footprint Discovery  . . . . . . . . . . . . . .  5
     3.1.  Protocol Not Required  . . . . . . . . . . . . . . . . . .  5
     3.2.  Protocol Potentially Required  . . . . . . . . . . . . . .  6
   4.  Additional Requirements  . . . . . . . . . . . . . . . . . . .  6
   5.  Survey of CDN Footprint Discovery  . . . . . . . . . . . . . .  7
     5.1.  Legacy Protocols . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1.  Legacy BGP . . . . . . . . . . . . . . . . . . . . . .  8
       5.1.2.  Legacy BGP Community Tag . . . . . . . . . . . . . . .  8
     5.2.  New Proposals  . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.1.  BGP Extension for CDNI . . . . . . . . . . . . . . . .  8
       5.2.2.  ALTO Footprint . . . . . . . . . . . . . . . . . . . .  8
   6.  Survey of CDN Delivery Proximity Discovery . . . . . . . . . .  9
     6.1.  BGP-TE . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  BGP AIGP . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.3.  BGP Extension for CDNI . . . . . . . . . . . . . . . . . .  9
     6.4.  ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.5.  Generic Capability Advertisement . . . . . . . . . . . . . 10
   7.  Synthesis  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     11.2. Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13






Bertrand                  Expires March 7, 2013                 [Page 2]

Internet-Draft           CDN Footprint Discovery          September 2012


1.  Terminology

   We adopt the terminology described in
   [I-D.ietf-cdni-problem-statement] and [I-D.davie-cdni-framework], and
   extend it with the additional terms defined below.

   Aggregate CDN Footprint: a set of User-Agent reachability information
   for which a CDN claims that it can deliver content in good
   conditions, by itself or through one of its dCDNs.  The CDN Footprint
   aggregates information on the footprint of the dCDNs with whom a uCDN
   is interconnected.

   High-Level CDN Footprint: the part of the footprint information that
   reflects rather static and business-level information.  As an
   example, the failure of a Surrogate does not change the High-level
   CDN Footprint information but may change detailed information of an
   element of the CDN Footprint.

   On-Net Footprint: a set of User-Agent reachability information for
   which a CDN claims that it can deliver content directly.  For
   instance, a given Access CDN may assert that its On-Net CDN Footprint
   encompasses all end-users in AS 64496 and AS 64497.

   CDN Delivery Proximity: Information on the network distance between a
   set of end-users in the CDN Footprint and the closest Surrogates of
   the considered CDN or of one of its dCDNs.  Various metrics can be
   considered for defining this distance; examples of such metrics
   include the AS hop count or an accumulated Interior Gateway Protocol
   (IGP) metric.

   CDN Footprint Discovery: discovery of information on CDN Footprint
   and CDN Delivery Proximity.  CDN Footprint Discovery provides the
   information that enables a uCDN's Request Routing Interface to select
   the most appropriate dCDN for a given content request.  CDN Footprint
   Discovery encompasses two different parts:

   1.  High-Level Footprint Discovery permits discovering groups of end-
       users/Surrogates and interconnection costs between them.

   2.  Detailed Footprint Discovery permits exchanging information that
       is subject to more scalability and confidentiality constraints.
       The level of information sharing must be tightly controlled.

   CDN Footprint Discovery Interface: An interface that enables CDN
   Footprint Discovery.  Section 3 details the use cases for a CDN
   Footprint Discovery Interface.





Bertrand                  Expires March 7, 2013                 [Page 3]

Internet-Draft           CDN Footprint Discovery          September 2012


2.  Introduction

   This memo presents use cases for CDN Footprint and CDN Delivery
   Proximity discovery in CDNI.  It provides a survey of existing work
   on the subject and a set of additional requirements for controlling
   the exchange of Footprint information.

   The reader should be familiar with the work of the CDNI WG:

   o  CDNI problem statement [I-D.ietf-cdni-problem-statement] defines
      the problem area that the CDNI working group is chartered to
      address.

   o  [I-D.ietf-cdni-use-cases] outlines real world use-cases for
      interconnecting CDNs.  These use cases (e.g., "QoE and QoS
      Improvement") require the discovery of CDN Footprint information.

   o  [I-D.ietf-cdni-requirements] specifies a set of requirements for
      CDN Footprint Discovery.

   The present document describes:

   o  The use cases for CDN Footprint Discovery (Section 3),

   o  The requirements for CDN Footprint Discovery (Section 4),

   o  A survey of Footprint Discovery protocols (Section 5).

2.1.  Abbreviations

   o  CDN: Content Delivery Network

   o  CDNP: Content Delivery Network Provider

   o  CSP: Content Service Provider

   o  dCDN: downstream CDN

   o  IGP: Interior Gateway Protocol

   o  NSP: Network Service Provider

   o  uCDN: upstream CDN








Bertrand                  Expires March 7, 2013                 [Page 4]

Internet-Draft           CDN Footprint Discovery          September 2012


3.  Use-Cases for Footprint Discovery

   The present memo considers the use cases for a Footprint Discovery
   Protocol in a multi-CDN case [I-D.ietf-cdni-use-cases].  It does not
   consider mono-CDN issues.

   [I-D.davie-cdni-framework] (Section 3.5.) describes "Dynamic
   Footprint Discovery" as a situation where "being able to dynamically
   discover the set of requests that a given dCDN is willing and able to
   serve is beneficial.  For example, a CDN might at one time be able to
   serve a certain set of client IP prefixes, but that set might change
   over time due to changes in the topology and routing policies of the
   IP network."  [I-D.davie-cdni-framework] provides an example where
   footprint information exchanges occur through the request routing
   interface and are triggered by an end-user's request (DNS resolution
   or content request).

   In the present memo, we seek to clarify in which cases such Footprint
   Discovery through a protocol is required.

3.1.  Protocol Not Required

   In most cases, High-Level CDN Footprint Discovery does not require a
   protocol, as in the following examples cases:

   o  High-Level CDN Footprint is Germany

   o  High-Level CDN Footprint is AS 64496

   However, the two following special cases deserve particular
   attention:

   1.  When the dCDNs' Footprints overlap,

   2.  When end-users outside the dCDNs' Footprints can request content.

   In these two cases, the uCDN needs additional criteria than the
   dCDN's Footprint to select the "best" CDN.  For instance, a static
   rule can be configured to select one of the available dCDNs.
   Alternatively, the uCDN may use dCDN's Delivery Proximity information
   to elect a delivering CDN.

   The remainder of this memo focuses on cases, where either CDN
   Footprint is defined dynamically or uCDN requires dynamic Delivery
   Proximity information on dCDNs.






Bertrand                  Expires March 7, 2013                 [Page 5]

Internet-Draft           CDN Footprint Discovery          September 2012


3.2.  Protocol Potentially Required

   In some cases, the uCDN needs dCDNs' Delivery Proximity information
   to determine which dCDN is the "best" to serve a given set of end-
   users.  For instance, the "best" CDN can be defined as the one that
   has deployed Surrogates topologically the closest to the end-user
   (e.g., an Access CDN).  This topological information is tightly
   related to the underlying networks: one may consider that a Surrogate
   is topologically far from the end-user if the path between these two
   entities crosses high cost links or many links.  While information
   about the Surrogates location is rather confidential, abstract
   information about the path's cost between a set of end-users and the
   closest Surrogates in a CDN may be generic enough to avoid disclosing
   confidential information about the network.

   CDN federations might involve several levels of CDN interconnection.
   In such scenarios, the CDN Footprint of a given CDN represents the
   aggregation of the CDN Footprint of all its own dCDNs.  Therefore,
   some variations of the dCDNs' Footprint can result in variations of
   the CDN's Footprint.  This example shows that the more levels of
   delegation we consider, the more dynamic the CDN Footprint
   information becomes.  Nevertheless, in the medium term, complex
   deployments scenarios involving more than a few levels of delegations
   are unlikely, because of performance issues.  Consequently, we
   consider that the High-Level CDN Footprint is rather static and
   remains valid for at least 24 hours.

   Depending on the considered metric, the CDN Delivery Proximity may
   change rarely (e.g., AS hop count) or more frequently (e.g.,
   accumulated IGP metric).


4.  Additional Requirements

   [I-D.ietf-cdni-requirements], already specifies two requirements
   related to Footprint Discovery: REQ-2 and REQ-3.  We remind these two
   requirements below.

   "REQ-2 [MED] The CDNI Request-Routing interface should allow the
   Downstream CDN to communicate to the Upstream CDN aggregate
   information to facilitate CDN selection during request routing, such
   as Downstream CDN capabilities, resources and affinities (i.e.
   Preferences or cost).  This information could, for example, include:

   o  supported content types and delivery protocols

   o  footprint (e.g., layer-3 coverage)




Bertrand                  Expires March 7, 2013                 [Page 6]

Internet-Draft           CDN Footprint Discovery          September 2012


   o  a set of metrics/attributes (e.g., Streaming bandwidth, storage
      resources, distribution and delivery priority)

   o  a set of affinities (e.g., Preferences, indication of
      distribution/delivery fees)

   o  information to facilitate request redirection (e.g., Reachability
      information of Downstream CDN Request Routing system)."

   "REQ-3 [MED] In the case of cascaded redirection, the CDNI Request-
   Routing interface shall allow the Downstream CDN to also include in
   the information communicated to the Upstream CDN, information on the
   capabilities, resources and affinities of CDNs to which the
   Downstream CDN may (in turn) redirect requests received by the
   Upstream CDN.  In that case, the CDNI Request-Routing interface shall
   prevent looping of such information exchange."

   We define additional requirements, specific to Footprint Discovery.

   FPT-1 [MED] A uCDN must be able to discover CDN Footprint and CDN
   Delivery Proximity information about dCDNs.

   FPT-2 [HIGH] A dCDN MUST be able to control what other CDNs can
   discover about its CDN Footprint and CDN Delivery Proximity.

   We also clarify REQ-3:

   FPT-3 [MED] A uCDN should not forward to any other CDN the Footprint
   and Delivery Proximity information that it has discovered about a
   dCDN without the explicit agreement of this dCDN.

   Finally, the deployment of a Footprint Discovery Interface imposes
   some operational requirements.  For instance, a Footprint Discovery
   protocol must not affect network stability and scalability.  It must
   also be simple enough to avoid increasing the networks' operation
   complexity.

   FPT-4 [HIGH] A Footprint Discovery protocol should not affect network
   stability and scalability.


5.  Survey of CDN Footprint Discovery

5.1.  Legacy Protocols







Bertrand                  Expires March 7, 2013                 [Page 7]

Internet-Draft           CDN Footprint Discovery          September 2012


5.1.1.  Legacy BGP

   Consider a dCDN that claims its CDN Footprint covers AS 64496.  BGP
   advertises AS-Path information that easily enables a uCDN to map end-
   users to the dCDN, basing on the end-users' IP address and on a
   mapping of IP addresses to AS numbers.

   BGP also provides CDN Delivery Proximity information: for instance, a
   CDN listening to BGP advertisements is able to determine the AS-path
   length to the advertised prefixes.  Note that BGP information might
   be collected in the network and provided to the CDN through another
   protocol rather than directly through BGP.

5.1.2.  Legacy BGP Community Tag

   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 are then used by
   its internal CDN [I-D.jenkins-alto-cdn-use-cases] for fine-grained
   request routing based on these groups.  A protocol (e.g., HTTP-based)
   can be used to advertise aggregated information on such groups rather
   than detailed information per prefix.  This provides a simple way to
   aggregate information for scalability and confidentiality purposes.

   An operator may consider that the grouping of prefixes into zones
   (the list of prefixes with a given community value) is confidential,
   as this grouping discloses information on the network's organization.

5.2.  New Proposals

5.2.1.  BGP Extension for CDNI

   [I-D.previdi-cdni-footprint-advertisement] proposes a BGP-based
   mechanism to advertise connectivity information in the context of
   CDNI.  It is based on the introduction of a CDN sub address Family
   (SAFI) and leverages BGP (extended) community tags.  It uses
   Multiprotocol-BGP (MP-BGP [RFC4760]) in order for CDNs and/or ISPs to
   advertise their connectivity to footprints.  A new NLRI is defined to
   carry CDN connectivity advertisements.  In summary, the draft defines
   a "CDN-level BGP" to complement the legacy network-level BGP
   described in Section 5.1.1 and Section 5.1.2.

5.2.2.  ALTO Footprint

   [I-D.jenkins-alto-cdn-use-cases] describes the use cases for a CDN to
   be able to obtain network topology and cost information from an ALTO
   server.  These use cases include: "Exposing NSP End User Reachability
   to a CDN, Exposing CDN End User Reachability to CSPs, CDN deployed



Bertrand                  Expires March 7, 2013                 [Page 8]

Internet-Draft           CDN Footprint Discovery          September 2012


   within a Broadband network, CDN delivering Over-The-Top of a NSP's
   network, and CDN acquiring content from multiple upstream sources".
   An additional use case may be to advertise CDN End User Reachability
   to upstream CDNs.

   The NSP CDN acting as a dCDN ALTO server may filter and send prefix
   groups (see Section 5.1.2) to uCDN ALTO clients according to its
   policies and with respect to a separate agreement it has with each
   uCDN.  A group may appear as a PID in ALTO network and cost maps.


6.  Survey of CDN Delivery Proximity Discovery

6.1.  BGP-TE

   [I-D.gredler-idr-ls-distribution] proposes a BGP-based mechanism by
   which link state and traffic engineering information can be collected
   from networks and shared with external components.

6.2.  BGP AIGP

   The Accumulated IGP Metric Attribute for BGP [I-D.ietf-idr-aigp]
   defines a new TLV attribute in BGP that allows redistribution of IGP
   costs between ASes belonging to the same managing entity.  With AIGP,
   path selection can take into account IGP costs from other ASes for
   reaching a certain prefix.  For the interconnection of multiple CDNs
   managed by the same entity ("Inter-Affiliates Interconnection"
   [I-D.ietf-cdni-use-cases]), the AIGP information may enable a uCDN to
   determine which dCDN is topologically the closest to a set of end-
   users.  However, the deployment limitations of AIGP listed in
   [I-D.ietf-idr-aigp] (Section 2. and 3.1.) restrict the applicability
   of AIGP for this use case.

6.3.  BGP Extension for CDNI

   See Section 5.2.1.

6.4.  ALTO

   [I-D.penno-alto-cdn] (Section 7.1.) describes how ALTO can be used by
   CDNs in a different administrative domain than the ISP to provide the
   cost from each CDN node to all known Subscriber PIDs.  This mechanism
   enables the CDN to determine its CDN Delivery Proximity to groups of
   end users.

   [I-D.ietf-alto-deployments] discusses deployment related issues of
   ALTO for peer-to-peer and CDNs.  In Section 5.1, it presents the use
   of ALTO for a mono-CDN case.  The ALTO server may leverage the BGP



Bertrand                  Expires March 7, 2013                 [Page 9]

Internet-Draft           CDN Footprint Discovery          September 2012


   information (e.g., BGP community attribute) to group prefixes into
   PIDs.  ALTO cost map permits providing cost information between PIDs
   and could be used by a dCDN to communicate its CDN Delivery Proximity
   to an uCDN.

   [I-D.seedorf-alto-for-cdni] briefly mentions that ALTO could support
   selection of downstream CDN but does not indicate the way the ALTO
   server is fed.

6.5.  Generic Capability Advertisement

   [I-D.he-cdni-cap-info-advertising] proposes an HTTP/1.1-based
   protocol which is used to communicate capability information (e.g.,
   resources, footprint, load) "to facilitate selection of the
   Downstream CDN by the Upstream CDN request routing system".


7.  Synthesis

   The use cases section shows that in the short term, the need for a
   Footprint Advertisement Protocol is limited to specific use cases.
   The survey shows that multiple new proposals addressing CDN Footprint
   Discovery are being defined, but none is mature and fulfills all the
   requirements yet.

   As a result, we consider that if there is enough interest for
   developing a CDN Footprint Advertisement Protocol, more work is
   needed to fulfill the specific requirements that arise in the context
   of CDNI.

   Key building blocks for a Footprint Discovery protocol are clearly
   identified:

   1.  Information on the network-level connectivity to groups of
       prefixes, i.e., to groups of end-users, is required.  For
       instance, BGP-level inter-domain routing data can typically be
       the source of this type of information, which may be advertised
       through a protocol based on HTTP, for example, or directly
       through BGP.

   2.  A mechanism to group end-users that must be served from the same
       set of Surrogates (e.g., representing a given CDN) is required.
       For example, BGP extended community attribute and ALTO PIDs
       typically provide such mechanisms.  The grouping of end-users can
       disclose confidential information on the CDN or network
       organization, therefore, a CDN/NSP will provide the groups'
       definitions only to its trusted partners.




Bertrand                  Expires March 7, 2013                [Page 10]

Internet-Draft           CDN Footprint Discovery          September 2012


   3.  A mechanism to discover generic cost information (uCDN Delivery
       Proximity) for the delivery from a given set of Surrogates (e.g.,
       a CDN) to a given set of end-users is required.  For example,
       ALTO cost maps, legacy BGP, BGP AIGP, and Previdi's MP-BGP
       extension typically provide such information, which may be
       advertised through the aforementioned protocols directly or
       through another protocol (e.g., HTTP based).  To fulfill the
       topology hiding requirements (identified in [RFC5693] (Section
       5.5.) and [I-D.penno-alto-cdn] (Section 6.1.)), the advertised
       information must not disclose confidential information on the
       CDN's and underlying networks' topology (i.e., it must not permit
       to derive a detailed network map).

   IETF may design a Footprint Discovery mechanism basing on these
   building blocks.  To increase the chances for this mechanism to be
   deployed by operators, such a mechanism should give enough control on
   information advertisement and respect operational requirements such
   as not being too tightly bound to the network.


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Security Considerations

   Footprint Discovery exposes information about the internals of CDNs.
   Therefore, it is subject to confidentiality issues.


10.  Acknowledgments

   The authors would like to thank Christian Jacquenet, Yannick Le
   Louedec, Sophie Nachman-Ghnassia, Iuniana Oprescu, Marcin Pilarski,
   and Emile Stephan for discussions about early versions of this
   document.

   They also thank the contributors of the EU FP7 OCEAN project for
   valuable inputs.


11.  References

11.1.  Normative References

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



Bertrand                  Expires March 7, 2013                [Page 11]

Internet-Draft           CDN Footprint Discovery          September 2012


   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

11.2.  Informative References

   [I-D.davie-cdni-framework]
              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-01 (work in
              progress), October 2011.

   [I-D.gredler-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., and A. Farrel,
              "North-Bound Distribution of Link-State and TE Information
              using BGP", draft-gredler-idr-ls-distribution-02 (work in
              progress), July 2012.

   [I-D.he-cdni-cap-info-advertising]
              He, X., Dawkins, S., Chen, G., Zhang, Y., and W. Ni,
              "Capability Information Advertising for CDN
              Interconnection", draft-he-cdni-cap-info-advertising-01
              (work in progress), March 2012.

   [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-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-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements",
              draft-ietf-cdni-requirements-03 (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-10 (work in
              progress), August 2012.

   [I-D.ietf-idr-aigp]
              Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,



Bertrand                  Expires March 7, 2013                [Page 12]

Internet-Draft           CDN Footprint Discovery          September 2012


              "The Accumulated IGP Metric Attribute for BGP",
              draft-ietf-idr-aigp-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.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.seedorf-alto-for-cdni]
              Seedorf, J., "ALTO for CDNi Request Routing",
              draft-seedorf-alto-for-cdni-00 (work in progress),
              October 2011.

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


Author's Address

   Gilles Bertrand
   France Telecom - Orange
   38-40 rue du General Leclerc
   Issy les Moulineaux,   92130
   FR

   Phone: +33 1 45 29 89 46
   Email: gilles.bertrand@orange.com











Bertrand                  Expires March 7, 2013                [Page 13]