Internet Engineering Task Force                            Y. Le Louedec
Internet-Draft                                                 A. Marrec
Intended status: Informational                               G. Bertrand
Expires: January 10, 2013                        France Telecom - Orange
                                                             M. Pilarski
                                                     Orange Polska / WUT
                                                            July 9, 2012


                          CDNI Request Routing
                draft-lelouedec-cdni-request-routing-00

Abstract

   The present document proposes to clarify the CDNI Request Routing
   interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-
   problem-statement], as well as related terminology.

   In particular the present document proposes to split the CDNI Request
   Routing interface into two separate interfaces with clearer roles,
   named respectively CDNI Routing interface and CDNI Downstream
   Resource Identifier Signaling interface (CDNI DRIS interface).

   This part of the CDN interconnection framework the IETF has been
   referring to so far with the term "CDNI Request Routing" is just
   another routing, signaling and forwarding problem in a long series of
   the telecommunication history.  For example, one can draw a direct
   analogy between the IP/MPLS-TE framework and the CDN interconnection
   framework.

   In addition, this document recommends that the specification of ALL
   CDN interconnection interfaces in the scope of the CDNI IETF WG
   relies on the equivalent concept to IP prefix for CDN
   interconnection, named 'contentRequestScope'.  This highly useful and
   powerful concept SHALL be used to simplify the specification of ALL
   CDN interconnection interfaces, as well as to ensure performance and
   scalability in CDN interconnection.

   All these proposals can be smoothly integrated in the WG drafts,
   especially [I-D.ietf-cdni-framework] and
   [I-D.ietf-cdni-requirements], as they essentially propose (useful)
   clarifications of the existing framework.

Status of this Memo

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




Le Louedec, et al.      Expires January 10, 2013                [Page 1]


Internet-Draft            CDNI Request Routing                 July 2012


   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.

   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.

























Le Louedec, et al.      Expires January 10, 2013                [Page 2]


Internet-Draft            CDNI Request Routing                 July 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Motivations and Terminology Clarifications . . . . . . . . . .  4
     2.1.  The CDNI Request Routing interface should be split . . . .  5
     2.2.  The routing function of the CDNI Request Routing
           interface should be clarified  . . . . . . . . . . . . . .  6
     2.3.  CDNI request redirection strategies  . . . . . . . . . . .  7
   3.  Overview of the CDNI Routing interface . . . . . . . . . . . .  8
   4.  The CDNI Downstream Resource Identifier Signaling (DRIS)
       Interface  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Overview of the CDNI DRIS interface  . . . . . . . . . . . 11
     4.2.  Overview of CDNI DRIS operations . . . . . . . . . . . . . 15
       4.2.1.  Case of iterative CDNI request redirection . . . . . . 16
       4.2.2.  Case of recursive CDNI request redirection . . . . . . 18
     4.3.  Key points to note about the CDNI DRIS interface . . . . . 23
   5.  CDNI request routing is just another routing and signaling
       problem  . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  Conclusion and recommendations . . . . . . . . . . . . . . . . 26
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   10. Informative References . . . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Proposal for Section 4.2 of CDNI framework draft  . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29


























Le Louedec, et al.      Expires January 10, 2013                [Page 3]


Internet-Draft            CDNI Request Routing                 July 2012


1.  Introduction

   The present document proposes to clarify the CDNI Request Routing
   interface introduced in [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-
   problem-statement], as well as the related terminology.

   In particular the present document proposes to split the CDNI Request
   Routing interface into two separate interfaces with clearer roles,
   named respectively CDNI Routing interface and CDNI Downstream
   Resource Identifier Signaling interface (CDNI DRIS interface).

   Section 2 presents the motivations for splitting the CDNI Request
   Routing interface.  It also proposes to review and to expand the
   terminology about the terms iterative request routing and recursive
   request routing.

   Section 3 and Section 4 provide a short overview respectively of the
   CDNI Routing interface and of the CDNI DRIS interface.  The detailed
   specifications of each of these interfaces will be made public
   shortly by the authors in dedicated IETF drafts.

   Section 5 provides an analogy with IP/MPLS-TE framework.  This just
   aims at helping readers to understand the proposals and
   recommendations in this document.

   Section 6 concludes this draft with recommendations for the IETF CDNI
   WG.  This includes recommendations about the CDNI WG charter, as well
   as about [I-D.ietf-cdni-framework] and [I-D.ietf-cdni-requirements].

   Appendix A proposes a text to replace Section 4.2 of
   [I-D.ietf-cdni-framework].


2.  Motivations and Terminology Clarifications

   Section 2.1 and Section 2.2 present the motivations for splitting and
   clarifying the CDNI Request Routing interface.

   This document adopts the terminology described in [I-D.ietf-cdni-
   problem-statement] and [I-D.ietf-cdni-framework], except for the
   terms 'iterative request routing' and 'recursive request routing'.
   Section 2.3 proposes to review and to expand the terminology about
   these two terms.

   In addition this document extends this terminology with the terms
   'CDNI routing interface', 'CDNI DRIS interface' and
   'contentRequestScope' introduced and illustrated respectively in
   Sections 3, 4, and 5.  It also introduces the term 'delivery



Le Louedec, et al.      Expires January 10, 2013                [Page 4]


Internet-Draft            CDNI Request Routing                 July 2012


   resource'.  From the perspective of the uCDN, a delivery resource is
   a delivery node or a request routing system towards which a content
   request may be redirected: either a delivery node inside the uCDN, or
   the request routing system of a CDN different from the uCDN, or a
   delivery node within a CDN different from the upstream CDN.

2.1.  The CDNI Request Routing interface should be split

   One key message of the present document is that the term "CDNI
   Request Routing" is confusing as it makes a mix-up of two clearly
   different sets of processes and interfaces.

   As described in [I-D.ietf-cdni-problem-statement], the CDNI Request
   Routing interface's role is twofold:

   1.  "To enable a downstream CDN to provide to the upstream CDN
       (static or dynamic) information (e.g., resources, footprint,
       load) to facilitate selection of the downstream CDN by the
       upstream CDN request routing system when processing subsequent
       content requests from User Agents."

   2.  "To allow the downstream CDN to control what the upstream Request
       Routing function should return to the User Agent in the
       redirection message."

   These two functions are fundamentally different.  Besides, depending
   on the considered use cases, described in [I-D.ietf-cdni-use-cases],
   they could be implemented differently (e.g., the first function could
   be implemented manually while the second function would be
   implemented with a network protocol, or vice versa, or they could
   rely on different network protocols, etc.).

   This idea that the request routing interface comprises two parts has
   started to be visible in the latest version of the Section 4.2 in
   [I-D.ietf-cdni-framework].  We think that it is a good first step
   that requires clarifications.  Indeed, [I-D.ietf-cdni-framework]
   mentions a 'synchronous part' that makes again a mix-up between
   operations involving communications with the user agent and
   operations only between the CDNs.  And the latter ones can be purely
   asynchronous operations in some cases, as illustrated in Section 4 of
   the present memo.

   Therefore, in order to simplify and accelerate the specification of
   the CDNI interfaces, the present document proposes to split the
   current CDNI Request Routing interface into two separate interfaces
   with clearer roles, further detailed in Section 3 and Section 4
   respectively:




Le Louedec, et al.      Expires January 10, 2013                [Page 5]


Internet-Draft            CDNI Request Routing                 July 2012


   1.  The CDNI Routing Interface

   2.  The CDNI Downstream Resource Identifier Signaling (DRIS)
       Interface.

2.2.  The routing function of the CDNI Request Routing interface should
      be clarified

   Quoting [I-D.ietf-cdni-problem-statement], "The CDNI Request Routing
   interface enables a Request Routing function in an upstream CDN to
   query a Request Routing function in a downstream CDN to determine if
   the downstream CDN is able (and willing) to accept the delegated
   content request".

   The "ability" and the "willingness" of the downstream CDN to accept
   the delegated content request match two fully different processes in
   CDN interconnection.  And the description of both these processes
   should be reviewed and clarified for the following reasons:

   o  Regarding the former process, i.e. related to the "ability"
      ("enables a Request Routing function in an upstream CDN to query a
      Request Routing function in a downstream CDN to determine if the
      downstream CDN is able (...) to accept the delegated content
      request"), a routing protocol is used to achieve such a process,
      called routing process, in many other technologies and networks
      (IP, ATM, etc.).  In all these technologies, it is the downstream
      entity that provides routing information to the upstream entity.
      The same approach should be applied to CDN interconnection.  The
      reverse approach ("uCDN queries it downstream CDNs dCDN 1, dCDN 2,
      dCDN 3, and then it selects one of them based on their responses")
      would suffer from latency, signaling overhead and/or lack of
      reactivity to events that impact the ability of the downstream
      CDNs to accept delegated content requests.

   o  Regarding the latter process, i.e. related to the "willingness"
      ("enables a Request Routing function in an upstream CDN to query a
      Request Routing function in a downstream CDN to determine if the
      downstream CDN (...) is willing (...)to accept the delegated
      content request"), it is to be noted that the relationship between
      a uCDN and a dCDN is always in the frame of a contractual
      agreement between the administrative entity owning the uCDN,
      acting as the customer, and the administrative entity owning the
      dCDN, acting as the service provider.  Therefore, consider a case
      where

      *  the uCDN has a content request to redirect which is in full
         conformance with the terms of this contractual agreement, and




Le Louedec, et al.      Expires January 10, 2013                [Page 6]


Internet-Draft            CDNI Request Routing                 July 2012


      *  the uCDN has selected this dCDN.

      As the uCDN knows, thanks to the routing information exchanged via
      the aforementioned routing process, that the dCDN is able to
      accept this content request, the uCDN MAY redirect the content
      request to the dCDN and the dCDN MUST accept the content request.
      Exchanging over the CDNI Request Routing interface information
      about the "willingness" of the dCDN to accept the content request
      is not relevant.

2.3.  CDNI request redirection strategies

   The terms "Iterative CDNI request routing" and "Recursive CDNI
   request routing" are defined in [I-D.ietf-cdni-framework].  As
   explained above the term "CDNI request routing" is confusing,
   therefore, the present document proposes to use the terms "Iterative
   CDNI request redirection" and "Recursive CDNI request redirection"
   instead.  We consider that these new terms are more appropriate than
   the definitions provided in [I-D.ietf-cdni-framework].

   The definition of "Recursive CDNI request routing" given in
   [I-D.ietf-cdni-framework] indicates "...that the Downstream CDN may
   elect to have the request redirected directly to a delivery node
   inside the Downstream CDN, to the Request-Routing System of the
   Downstream CDN, to another CDN, or to any other system that the
   Downstream CDN sees as fit for handling the redirected request."

   In order to clarify this point, and for the purpose of Section 3 to
   Section 6, the present document introduces the terms "full-recursive
   CDNI request redirection" and "semi-recursive CDNI request
   redirection".

   Full-recursive CDNI request redirection and semi-recursive CDNI
   request redirection are two subtypes of recursive CDNI request
   redirection.  A recursive CDNI request redirection is either a full-
   recursive CDNI request redirection or a semi-recursive request
   redirection.

   "Full-recursive CDNI request redirection" refers to the case where
   the considered CDN redirects the content request directly to a
   delivery node of another CDN, as illustrated in Figure 4.  It means
   the content request is redirected:

   o  either directly to a delivery node inside the Downstream CDN,

   o  or directly to a delivery node inside a downstream CDN of the
      downstream CDN,




Le Louedec, et al.      Expires January 10, 2013                [Page 7]


Internet-Draft            CDNI Request Routing                 July 2012


   o  or directly to a delivery node inside a downstream CDN of a
      downstream CDN of the downstream CDN,

   o  etc. (anyway directly to a delivery node).

   In contrast, "semi-recursive CDNI request redirection" refers to the
   case, illustrated on Figure 5, where the considered CDN does not
   directly redirect the content request to a delivery node.  It means
   the request is redirected:

   o  either to the request routing system of the Downstream CDN that
      will deliver the content

   o  or to the request routing system of another CDN that will deliver
      the content and that is a downstream CDN of the downstream CDN,

   o  or to the request routing system of another CDN that will deliver
      the content and that is a downstream CDN of a downstream CDN of
      the downstream CDN,

   o  etc. (anyway not directly to a delivery node).

   Full-recursive redirection has the advantage over semi-recursive
   redirection of being more transparent from the user agent's
   perspective, but the disadvantage of the downstream CDN exposing more
   of its internal structure (in particular, the addresses of delivery
   nodes) to the upstream CDN (and possibly to the upstream CDN(s) of
   its upstream CDN, etc.).  By contrast, semi-recursive redirection
   does not require dCDN to expose the addresses of its delivery nodes
   to uCDN.  The specifications for the CDNI interfaces elaborated
   within the IETF CDNI WG MUST allow to support both these recursive
   CDNI request redirection strategies.


3.  Overview of the CDNI Routing interface

   The CDNI routing interface is dedicated to the CDNI routing process.
   The CDNI routing process consists in the advertisement of CDNI
   routing information from the downstream CDN to the upstream CDN.

   Note: The upstream CDN never provides the downstream CDN with any
   CDNI routing information.

   CDNI routing information details "capabilities" of the downstream CDN
   that the upstream CDN must take into account in its CDN selection
   process.  The CDN selection process consists for the upstream CDN to
   select the CDN (either the upstream CDN or one of its downstream
   CDN(s)) that should handle the content request the upstream CDN



Le Louedec, et al.      Expires January 10, 2013                [Page 8]


Internet-Draft            CDNI Request Routing                 July 2012


   receives from the user agent.

   Note: The term "capabilities" refer to the capacity of the downstream
   CDN to handle correctly content requests from user agents.  It does
   not necessarily mean that the downstream CDN will satisfy (alone) all
   these content requests by delivering the requested content to the
   user agent.  Indeed the downstream CDN may have its own downstream
   CDN(s) and may decide that some or all of these content requests will
   be handled by its own downstream CDN(s).

   Figure 1 provides a short illustration of the CDNI routing interface.
   The upstream CDN on Figure 1 has two downstream CDNs: CDN1 and CDN2.

   Via their respective CDNI routing interfaces established with the
   upstream CDN, CDN1 and CDN2 provide the upstream CDN with CDNI
   routing information about the capabilities that they offer to the
   upstream CDN in the frame of their respective CDNI agreements
   contracted with the upstream CDN.

   The inner architecture of the upstream CDN is beyond the scope of the
   current charter of the IETF CDNI WG.  Figure 1 provides a high level
   representation of a possible implementation just in order to ease
   understanding of the global picture.

   Basically and typically, the CDNI routing information received from
   CDN1 and CDN2 will feed a CDNI routing table controlled by a routing
   module in the upstream CDN.  And every time the upstream CDN receives
   a content request from a user agent (either a DNS request in case of
   DNS based request redirection, or an HTTP request in case of HTTP
   based request redirection, etc.), its CDN selection module (in charge
   of the CDN selection process) will consult this CDNI routing module
   to decide about which CDN will handle this request (the upstream CDN,
   CDN1, or CDN2).  In the example on Figure 1, the upstream CDN selects
   CDN 2 for the considered content request.

















Le Louedec, et al.      Expires January 10, 2013                [Page 9]


Internet-Draft            CDNI Request Routing                 July 2012


   +-----+   +------------------------------------------------+
   |     |   |               Upstream CDN                     |
   |     |   |                                                |
   |     |   |  (1) Content request  +----------------------+ |
   |     |-------------------------->|                      | |
   |     |   |                       |     CDN selection    | |
   |     |   |                  (2)  |     Module           | |
   |     |   |            +--------->|                      | |
   |     |   |            |          |  (Selection of CDN2) | |
   |     |   |            |          +----------------------+ |
   |User |   |            |                                   |
   |Agent|   |            |                                   |
   |     |   |            |                                   |
   |     |   |            V                                   |
   |     |   | +--------------------------------------------+ |
   |     |   | |                                            | |
   |     |   | |          CDNI Routing Module               | |
   |     |   | |                                            | |
   |     |   | +--------------------------------------------+ |
   |     |   |           ^                      ^             |
   |     |   |           |                      |             |
   |     |   +-----------|----------------------|-------------+
   |     |               |(A)  CDNI Routing  (A)|
   |     |               |      Interfaces      |
   |     |       +-------+-------+      +-------+-------+
   |     |       |Downstream CDN1|      |Downstream CDN2|
   +-----+       +---------------+      +---------------+


                     Figure 1: CDNI routing interface

   The operations shown on Figure 1 are as follows:

   1.  A content request from a user agent (and/or from an intermediate
       local DNS in case it is a DNS request) arrives at the upstream
       CDN.

   2.  Within the upstream CDN, the CDN selection module consults the
       routing module to decide which CDN will handle this content
       request (i.e. whether it will be the upstream CDN or one of its
       downstream CDNs).  The interface between these internal modules
       is out of standardization scope.

   A. The operations achieved over the CDNI Routing interfaces aim at
   providing all information about the capabilities offered by the
   downstream CDNs to the upstream CDN in the frame of their respective
   CDNI agreements contracted with the upstream CDN.




Le Louedec, et al.      Expires January 10, 2013               [Page 10]


Internet-Draft            CDNI Request Routing                 July 2012


   The operations referenced with numeric indexes on Figure 1 ("1", "2")
   show a time dependency: every time the upstream CDN receives a
   content request ("1") its CDN selection process consults the routing
   table ("2").

   In contrast, Routing information is to be exchanged continuously,
   with keep alive and update messages.  There is no time dependency
   between the content requests received by the upstream CDN and the
   operations over the CDNI routing interfaces.  By reference to the
   terminology used in [I-D.ietf-cdni-framework], CDNI Routing
   operations are asynchronous.  The CDNI routing interfaces are
   referenced with an alphabetic index ("A") on Figure 1 to reflect this
   point.


4.  The CDNI Downstream Resource Identifier Signaling (DRIS) Interface

4.1.  Overview of the CDNI DRIS interface

   AFTER the CDN selection process is achieved by the upstream CDN for a
   given content request (see Section 3), the upstream CDN MUST generate
   a response redirecting that content request towards the selected
   delivery resource by using in this response an identifier of that
   selected delivery resource.

   The selected delivery resource can be:

   1.  Either a delivery node within the upstream CDN

   This corresponds to the case where the CDN selection process of the
   upstream CDN selects the upstream CDN for that content request.  In
   this case, the upstream CDN delivers the requested content to the
   client through one of its delivery nodes.  The selected delivery
   resource is the upstream CDN's delivery node.

   2.  Or the request routing system of a CDN different from the
   upstream CDN

   This corresponds to the case where the upstream CDN did select a
   downstream CDN for that content request, and where the CDNI request
   redirection strategy between the upstream CDN and this downstream CDN
   is based either on the iterative mode or on the semi-recursive mode.
   If the CDNI request redirection strategy between the uCDN and the
   dCDN is based on the iterative mode, the CDN to which the request
   routing system belongs is the downstream CDN selected by the upstream
   CDN for that content request (see Figure 3: Iterative CDNI request
   redirection).  If the CDNI request redirection strategy between the
   uCDN and the dCDN is based on the semi-recursive mode, the CDN to



Le Louedec, et al.      Expires January 10, 2013               [Page 11]


Internet-Draft            CDNI Request Routing                 July 2012


   which that request routing system belongs can possibly be

   o  the downstream CDN selected by the upstream CDN for that content
      request, or

   o  a downstream CDN of that downstream CDN, or

   o  a downstream CDN of a downstream CDN of that downstream CDN,

   o  etc.,

   due to the recursive nature of this mode (see Figure 5).

   3.  Or a delivery node within a CDN different from the upstream CDN

   This corresponds to the case where the upstream CDN did select a
   downstream CDN for that content request, and where the CDNI request
   redirection strategy between the upstream CDN and this downstream CDN
   is based on the full-recursive mode.

   The CDN to which the selected delivery node belongs can possibly be a
   delivery node within the downstream CDN selected by the upstream CDN
   for that content request, or a delivery node within a downstream CDN
   of that downstream CDN, or a delivery node within a downstream CDN of
   a downstream CDN of that downstream CDN, etc., due to the recursive
   nature of this mode (see Figure 4: Full-recursive CDNI request
   redirection).

   In the cases "2." and "3.", the downstream CDN MUST provide the
   identifier of the selected delivery resource to the upstream CDN.
   The downstream CDN uses the CDNI DRIS interface to provide the
   upstream CDN with this identifier called "Downstream Resource
   Identifier" (DRI).

   Note.  In the recursive modes (full-recursive and semi-recursive) the
   upstream CDN does not need to know if the selected delivery resource
   belongs to the downstream CDN that the uCDN selected for that content
   request or to another CDN (i.e. to one downstream CDN of this
   downstream CDN, or to one downstream CDN of one downstream CDN of
   this downstream CDN, etc.).  The upstream CDN just needs to get from
   the selected downstream CDN the "Downstream Resource Identifier"
   (DRI) of the selected delivery resource, so as to generate with this
   identifier a response redirecting that content request towards that
   selected delivery resource.







Le Louedec, et al.      Expires January 10, 2013               [Page 12]


Internet-Draft            CDNI Request Routing                 July 2012


  +-----+            +-------------------------------------------------+
  |     |(1) Content |                                                 |
  |     |    request |                Upstream CDN                     |
  |     |----------------+                                             |
  |     |            |   |                                             |
  |     |            |   |   (5) Content request response              |
  |     |<---------------|---------------------------------+           |
  |     |            |   |                                 |           |
  |     |            | +-V--------------+         +--------+---------+ |
  |     |            | | CDN selection  |         | Content request  | |
  |     |            | | Module         |(3)      | response         | |
  |     |            | |                |-------->| generation       | |
  |     |            | |  (Selection    |Internal | Module           | |
  |User |            | |   of CDN2)     |Interface|                  | |
  |Agent|            | +----------------+         +------------------+ |
  |     |            |          ^                          ^           |
  |     |            |       (2)|Internal               (4)|Internal   |
  |     |            |          |interface                 |interface  |
  |     |            |          V                          V           |
  |     |            |    +-------------+           +-----------+      |
  |     |            |    |CDNI Routing |           |DRI        |      |
  |     |            |    |Module       |           |Module     |      |
  |     |            |    +-------------+           +-----------+      |
  |     |            |          ^   ^                 ^   ^            |
  |     |            +----------|---|-----------------|---|------------+
  |     |           CDNI Routing|(A)+--------------+  |(B)|CDNI DRIS
  |     |           Interfaces  |     +------------|--+   |Interfaces
  |     |                       |     |            |      |
  |     |                +------+-----v--+       +-+------v------+
  |     |                |Downstream CDN1|       |Downstream CDN2|
  +-----+                +---------------+       +---------------+


                       Figure 2: CDNI DRIS interface

   Figure 2 is an extension of Figure 1.  Again, the inner architecture
   of the CDN is beyond the scope of the IETF CDNI WG charter; Figure 2
   provides a high level representation of a possible implementation
   just in order to ease the understanding of the global picture.

   The operations shown on Figure 2 are as follows:

   1.  A content request from a user agent (and/or from an intermediate
       local DNS in case it is a DNS request) arrives at the upstream
       CDN.

   2.  Within the upstream CDN, the CDN selection Module consults the
       routing module to decide which CDN will handle this content



Le Louedec, et al.      Expires January 10, 2013               [Page 13]


Internet-Draft            CDNI Request Routing                 July 2012


       request (i.e. whether it will be the upstream CDN or one of its
       downstream CDNs).  The interface between these internal modules
       is out of standardization scope.  Let us consider that the CDN
       selection module selected the downstream CDN2 for that content
       request (so as to continue with the illustrating example
       introduced in Section 3).

   3.  Once this CDN selection is achieved, the module in charge of
       generating the response to the content request ('Content request
       response generation Module' on Figure 2) is called.  The
       interface between these internal modules is out of
       standardization scope.  In order to generate the response, the
       Content request response generation module needs to get the
       identifier of the selected delivery resource (DRI) to where the
       content request must be redirected.

   4.  The Content request response generation module consults the DRI
       module to get this adequate DRI.  The interface between these
       internal modules is out of standardization scope.  The DRI module
       is in charge of getting and storing the DRI(s) provided by each
       downstream CDN over their CDNI DRIS interfaces with the upstream
       CDN.

   5.  Once the Content request response generation module has this
       adequate DRI, it generates the response to the content request so
       as to the request be redirected towards the selected delivery
       resource.

   A. The operations achieved over the CDNI Routing interfaces aim at
   providing all information about the capabilities offered by the
   downstream CDNs to the upstream CDN in the frame of their respective
   CDNI agreements contracted with the upstream CDN.

   B. The operations achieved over the CDNI DRIS Interface with the
   downstream CDN2 aim at providing the upstream CDN with the DRI, i.e.
   the identifier of the selected delivery resource.

   The operations referenced with numeric indexes on Figure 2 ("1", "2",
   "3", "4", "5") show a strict time dependency.  In particular, it is
   to be highlighted that the CDN selection process of the upstream CDN
   does not take the DRI information into account.  This identifier is
   used by the content request response generation module only after the
   CDN selection process is achieved.

   As explained in Section 3, the CDNI routing interfaces are referenced
   with an alphabetic index ("A") to indicate that the CDNI routing
   information are exchanged asynchronously and continuously, with keep
   alive and update messages.



Le Louedec, et al.      Expires January 10, 2013               [Page 14]


Internet-Draft            CDNI Request Routing                 July 2012


   The CDNI DRIS interfaces are also referenced with an alphabetic index
   ("B") to indicate there is not always a systematic time dependency
   between the content requests received by the upstream CDN and the
   operations occurring over the CDNI DRIS interfaces.  This depends,
   among others, on the CDNI request redirection strategy enforced
   between the CDNs (recursive or iterative).  This means that the
   specification of the CDNI DRIS interface MUST enable synchronous and
   asynchronous operations, as illustrated in the next Section 4.2.

4.2.  Overview of CDNI DRIS operations

   This section gives an overview of operations over the CDNI DRIS
   interfaces for each CDNI request redirection strategy (iterative,
   full-recursive and semi-recursive).

   All the figures present the same network topology with three cascaded
   CDNs so as to show very clearly the difference between the full-
   recursive and semi-recursive modes.  The case where only two CDNs are
   involved can be straightforwardly deduced.  In addition, the CDNI
   request redirection strategy applied between the first CDN and the
   second CDN (e.g., iterative) could differ from the strategy applied
   between the second CDN and the third CDN (e.g., semi- recursive).
   The three figures are for illustration purpose only; they do not aim
   at reflecting exhaustively the full flexibility that the CDN service
   providers have when choosing their CDNI request redirection
   strategies.

   The same situation and content request are considered in all the
   three figures:

   o  There is one CDNI agreement and one CDN interconnection between
      CDN-a and CDN-b for the considered request.  CDN-b is a downstream
      CDN of CDN-a.  And there is one CDNI DRIS interface between CDN-a
      and CDN-b, bootstrapped with configuration information exchanged
      over the CDNI control interface during the initial CDN
      interconnection activation process (see
      [I-D.ietf-cdni-framework]).

   o  In the same way there is one CDNI agreement, one CDN
      interconnection and one CDNI DRIS interface between CDN-b and
      CDN-c.  CDN-c is a downstream CDN of CDN-b for the considered
      request.

   o  CDN-a receives a content request and decides CDN-b will handle it.
      CDN-b decides the content request will be handled by CDN-c.  CDN-c
      delivers the content to the user agent from one of its delivery
      nodes (cache hit).




Le Louedec, et al.      Expires January 10, 2013               [Page 15]


Internet-Draft            CDNI Request Routing                 July 2012


4.2.1.  Case of iterative CDNI request redirection

   Figure 3 presents the case where the iterative CDNI request
   redirection mode is applied between CDN-a and CDN-b, and between
   CDN-b and CDN-c.


   +-----+                                       +------------------+
   |     |                                       |CDN-a             |
   |     | 1                                     | (uCDN for CDN-b) |
   |     |-------------------------------------->|                  |
   |     | 2                                     |                  |
   |     |<--------------------------------------|                  |
   |     |      +------------------+             |    +--------+    |
   |     |      |CDN-b             |             |    |        |    |
   |     | 3    | (uCDN for CDN-c) |             |    |DRI     |    |
   |     |----->|                  |   +------------->|Module  |    |
   |     | 4    |    +--------+    | 0 |         |    |        |    |
   |     |<-----|    |        |--------+         |    +--------+    |
   |     |      |    |        |    |             +------------------+
   |User |      |    |DRI     |    |
   |Agent|      |    |Module  |    |
   |     |      |    |        |    |
   |     |      |    |        |    | 0
   |     |      |    |        |<-------+
   |     |      |    +--------+    |   |
   |     |      +------------------+   |         +------------------+
   |     |                             |         |CDN-c             |
   |     |                             |         |    +--------+    |
   |     |                             |         |    |        |    |
   |     |                             +--------------|DRI     |    |
   |     |                                       |    |Module  |    |
   |     |                                       |    |        |    |
   |     | 5                                     |    +--------+    |
   |     |-------------------------------------->|                  |
   |     | 6                                     |                  |
   |     |<--------------------------------------|                  |
   |     | 7                                     |    +--------+    |
   |     |------------------------------------------->|        |    |
   |     | 8                                     |    |Delivery|    |
   |     |<-------------------------------------------|Node    |    |
   |     |                                       |    |        |    |
   |     |                                       |    +--------+    |
   +-----+                                       +------------------+


               Figure 3: Iterative CDNI request redirection




Le Louedec, et al.      Expires January 10, 2013               [Page 16]


Internet-Draft            CDNI Request Routing                 July 2012


   The operations shown in Figure 3 are as follows:

   0.  CDN-a gets from CDN-b, over the CDNI DRIS interface between CDN-a
   and CDN-b, a DRI valid for any content request within their mutual
   CDNI agreement, and possibly before any user agent content request is
   received by CDN-a.

   In the iterative case, the CDNI DRIS interface may indeed provide the
   upstream CDN with a unique DRI valid in the frame of their mutual
   CDNI agreement for any content request received by the upstream CDN.

   Basically, it means that the downstream CDN informs the upstream CDN
   that, when the upstream CDN decides to redirect a content request to
   this downstream CDN in the frame of their mutual CDNI agreement, the
   upstream CDN just has to use systematically that DRI to forge the
   response sent by the upstream CDN to redirect the content request to
   that downstream CDN.

   For example, in case the CDNI request redirection mechanism is based
   on HTTP 302 redirect messages, this DRI includes a distinguished CDN-
   domain, which is to be "stacked" in front of the original URL to
   construct the new URL to redirect the content request to the request
   routing system of the downstream CDN, as detailed in
   [I-D.ietf-cdni-framework].

   This static and unique DRI for a CDNI agreement set between CDN-a and
   CDN-b can be exchanged even before the first content request received
   by CDN-a.  This is an example of asynchronous operation over the CDNI
   DRIS interface.  And this is one case where it may be relevant to
   implement the CDNI DRIS interface "manually"; for example the DRI can
   be exchanged on the phone or by email simply and only once for the
   whole duration of the CDNI agreement between CDN-a and CDN-b.

   We describe the other operations of Figure 3 below.

   0.  The same way, CDN-b gets from CDN-c, over the CDNI DRIS interface
   between CDN-b and CDN-c, a DRI valid for any content request within
   their mutualCDNI agreement, and possibly before any user agent
   content request is received by CDN-b.

   1.  The considered content request, sent by a user agent (and/or by
   an intermediate local DNS in case it is a DNS request), arrives at
   CDN-a.

   2.  CDN-a decides this content request is to be best handled by
   CDN-b.  Therefore, CDN-a sends a response to the content request,
   forged with the DRI provided by CDN-b.




Le Louedec, et al.      Expires January 10, 2013               [Page 17]


Internet-Draft            CDNI Request Routing                 July 2012


   3.  A request is thus sent by the user agent (and/or by an
   intermediate local DNS in case it is a DNS request) to CDN-b.

   4.  CDN-b decides this content request is to be best handled by
   CDN-c.  Thus, CDN-b sends a response to the content request forged
   with the DRI provided by CDN-c.

   5.  A request is sent by the user agent (and/or by an intermediate
   local DNS in case it is a DNS request) to CDN-c.

   6.  CDN-c decides it will handle the request, i.e. it will be the one
   to deliver the content to the user agent.  CDN-c selects one of its
   delivery nodes to handle that content request.  CDN-c generates a
   response redirecting the content request to this delivery node.

   7.  The user agent emits a content request to the selected delivery
   node.

   8.  The selected delivery node from CDN-c delivers the requested
   content to the user agent.

4.2.2.  Case of recursive CDNI request redirection

   Figure 4 presents the case where the full-recursive CDNI request
   redirection mode is applied between CDN-a and CDN-b, and between
   CDN-b and CDN-c.

























Le Louedec, et al.      Expires January 10, 2013               [Page 18]


Internet-Draft            CDNI Request Routing                 July 2012


    +-----+                                       +------------------+
    |     |                                       |CDN-a             |
    |     | 1                                     | (uCDN for CDN-b) |
    |     |-------------------------------------->|                  |
    |     | 6                                     |                  |
    |     |<--------------------------------------|                  |
    |     |      +------------------+             |    +--------+    |
    |     |      |CDN-b             |   +--------------|        |    |
    |     |      | (uCDN for CDN-c) |   |         |    |DRI     |    |
    |     |      |                  |   |    +-------->|Module  |    |
    |     |      |    +--------+    | 2 |    |    |    |        |    |
    |     |      |    |        |<-------+    |    |    +--------+    |
    |     |      |    |        |    | 5      |    +------------------+
    |User |      |    |DRI     |-------------+
    |Agent|      |    |Module  |    | 3
    |     |      |    |        |-------------+
    |     |      |    |        |    | 4      |
    |     |      |    |        |<-------+    |
    |     |      |    +--------+    |   |    |
    |     |      +------------------+   |    |    +------------------+
    |     |                             |    |    |CDN-c             |
    |     |                             |    |    |    +--------+    |
    |     |                             |    +-------->|        |    |
    |     |                             |         |    |DRI     |    |
    |     |                             +--------------|Module  |    |
    |     |                                       |    |        |    |
    |     |                                       |    +--------+    |
    |     | 7                                     |    +--------+    |
    |     |------------------------------------------->|        |    |
    |     | 8                                     |    |Delivery|    |
    |     |<-------------------------------------------|Node    |    |
    |     |                                       |    |        |    |
    |     |                                       |    +--------+    |
    +-----+                                       +------------------+


             Figure 4: Full-recursive CDNI request redirection

   The operations shown in Figure 4 are as follows:

   1.  The considered content request, sent by a user agent (and/or by
   an intermediate local DNS in case it is a DNS request), arrives at
   CDN-a.

   2.  CDN-a decides this content request is to be best handled by
   CDN-b.  CDN-a sends a request to CDN-b over the CDNI DRIS interface
   set up between CDN-a and CDN-b.  The request includes all information
   about the content request CDN-b needs in order to select the most



Le Louedec, et al.      Expires January 10, 2013               [Page 19]


Internet-Draft            CDNI Request Routing                 July 2012


   appropriate delivery resource and to response to CDN-a with the
   corresponding adequate DRI.

   3.  CDN-b decides this content request is to be best handled by
   CDN-c.  CDN-b sends a request to CDN-c over the CDNI DRIS interface
   set up between CDN-b and CDN-c.  The request includes all information
   about the content request CDN-c needs in order to select the most
   appropriate delivery resource and to response to CDN-b with the
   corresponding adequate DRI.

   4.  CDN-c decides it will handle the content request, i.e. it will be
   the one to deliver the content to the user agent.  CDN-c selects one
   of its delivery nodes to handle that content request.  CDN-c sends a
   response to CDN-b, over the CDNI DRIS interface between CDN-b and
   CDN-c, with a DRI corresponding to that delivery node.

   5.  CDN-b sends a response to CDN-a, over the CDNI DRIS interface
   between CDN-a and CDN-b, with a DRI corresponding to the selected
   delivery node from CDN-c.  This DRI is based on the DRI provided by
   CDN-c.  Details about the manipulations achieved by CDN-b over the
   DRI received from CDN-c to generate the DRI sent to CDN-a are to be
   provided in the dedicated specification of the CDNI DRIS interface.

   6.  CDN-a sends a response to the content request, forged with the
   DRI provided by CDN-b.

   7.  The user agent emits a content request directly to the selected
   delivery node from CDN-c.

   8.  The selected delivery node from CDN-c delivers the requested
   content to the user agent.

   The Figure 5 below presents the case where the semi-recursive CDNI
   request redirection mode is applied between CDN-a and CDN-b, and
   between CDN-b and CDN-c.
















Le Louedec, et al.      Expires January 10, 2013               [Page 20]


Internet-Draft            CDNI Request Routing                 July 2012


   +-----+                                       +------------------+
    |     |                                       |CDN-a             |
    |     | 1                                     | (uCDN for CDN-b) |
    |     |-------------------------------------->|                  |
    |     | 6                                     |                  |
    |     |<--------------------------------------|                  |
    |     |      +------------------+             |    +--------+    |
    |     |      |CDN-b             |   +--------------|        |    |
    |     |      | (uCDN for CDN-c) |   |         |    |DRI     |    |
    |     |      |                  |   |    +-------->|Module  |    |
    |     |      |    +--------+    | 2 |    |    |    |        |    |
    |     |      |    |        |<-------+    |    |    +--------+    |
    |     |      |    |        |    | 5      |    +------------------+
    |User |      |    |DRI     |-------------+
    |Agent|      |    |Module  |    | 3
    |     |      |    |        |-------------+
    |     |      |    |        |    | 4      |
    |     |      |    |        |<-------+    |
    |     |      |    +--------+    |   |    |
    |     |      +------------------+   |    |    +------------------+
    |     |                             |    |    |CDN-c             |
    |     |                             |    |    |    +--------+    |
    |     |                             |    +-------->|        |    |
    |     |                             |         |    |DRI     |    |
    |     |                             +--------------|Module  |    |
    |     |                                       |    |        |    |
    |     | 7                                     |    +--------+    |
    |     |-------------------------------------->|                  |
    |     | 8                                     |                  |
    |     |<--------------------------------------|                  |
    |     | 9                                     |    +--------+    |
    |     |------------------------------------------->|        |    |
    |     | 10                                    |    |Delivery|    |
    |     |<-------------------------------------------|Node    |    |
    |     |                                       |    |        |    |
    |     |                                       |    +--------+    |
    +-----+                                       +------------------+


             Figure 5: Semi-recursive CDNI request redirection

   The operations shown in Figure 5 are as follows:

   1.  The considered content request, sent by a user agent (and/or by
   an intermediate local DNS in case it is a DNS request), arrives at
   CDN-a.

   2.  CDN-a decides this content request is to be best handled by



Le Louedec, et al.      Expires January 10, 2013               [Page 21]


Internet-Draft            CDNI Request Routing                 July 2012


   CDN-b.  CDN-a sends a request to CDN-b over the CDNI DRIS interface
   set up between CDN-a and CDN-b.  The request includes all information
   about the content request CDN-b needs in order to select the most
   appropriate delivery resource and to response to CDN-a with the
   corresponding adequate DRI.

   3.  CDN-b decides this content request is to be best handled by
   CDN-c.  CDN-b sends a request to CDN-c over the CDNI DRIS interface
   set up between CDN-b and CDN-c.  The request includes all information
   about the content request CDN-c needs in order to select the most
   appropriate delivery resource and to response to CDN-b with the
   corresponding adequate DRI.

   4.  CDN-c decides it will handle the content request, i.e. it will be
   the one to deliver the content to the user agent.  CDN-c sends a
   response to CDN-b, over the CDNI DRIS interface between CDN-b and
   CDN-c, with a DRI corresponding to its request routing system.

   5.  CDN-b sends a response to CDN-a, over the CDNI DRIS interface
   between CDN-a and CDN-b, with a DRI corresponding to the selected
   delivery resource (i.e. to the request routing system of CDN-c).
   This DRI is based on the DRI provided by CDN-c.  Details about the
   manipulations achieved by CDN-b over the DRI received from CDN-c to
   generate the DRI sent to CDN-a are to be provided in the dedicated
   specification of the CDNI DRIS interface.

   6.  CDN-a sends a response to the content request, forged with the
   DRI provided by CDN-b.

   7.  The content request is redirected by the user agent (and/or by an
   intermediate local DNS in case it is a DNS request) to the selected
   delivery resource, i.e. to CDN-c.

   8.  CDN-c decides it will handle the content request, i.e. it will be
   the one to deliver the content to the user agent.  CDN-c selects one
   of its delivery nodes to handle that content request.  CDN-c
   generates a response redirecting the content request to this delivery
   node.

   9.  The user agent emits a content request to the selected delivery
   node.

   10.  The selected delivery node from CDN-c delivers the requested
   content to the user agent.

   As shown on Figure 4 and 5, when the recursive mode is applied, the
   upstream CDN may have to send a request over a CDNI DRIS interface
   every time it receives a content request.  This is an example of



Le Louedec, et al.      Expires January 10, 2013               [Page 22]


Internet-Draft            CDNI Request Routing                 July 2012


   synchronous operations over the CDNI DRIS interface.  Having one CDNI
   DRIS request per content request may lead to scalability issues, even
   if the CDNI DRIS interface is implemented with a network protocol
   rather than "manually".  Yet these issues can be solved.  This is to
   be documented in the dedicated specification of the CDNI DRIS
   interface.

4.3.  Key points to note about the CDNI DRIS interface

   To conclude this section, the key points to note about the CDNI DRIS
   interface are the following:

   o  The CDNI DRIS interface MUST always exist between two
      interconnected CDNs.  Whatever the CDNI request redirection
      strategy applied (recursive or iterative), the CDNI DRIS interface
      exists, even if it is implemented "manually" in some cases, as
      suggested in the example of Figure 3 above.

   o  Moreover the CDNI DRIS interface MUST be unique from a functional
      perspective.  Another way to say this is that, from a functional
      perspective, this is the exact same CDNI DRIS interface that is
      used, and the exact same type of information that are exchanged
      over this interface, whatever the CDNI request redirection
      strategy applied (recursive or iterative).

   o  The specification of the CDNI DRIS interface MUST enable
      synchronous and asynchronous CDNI DRIS operations: operations
      possibly triggered by the CDN selection process for a given
      content request (as shown on Figure 4 and 5), as well as
      operations achieved independently of any content request (as shown
      on Figure 3).

   o  The specification of the CDNI DRIS interface MUST enable
      operations initiated by uCDN (as shown on Figure 4 and 5) or by
      dCDN (as shown on Figure 3).

   o  The specification of the CDNI DRIS interface MUST be compatible
      with "automatic" (i.e. "with a specific network protocol") and
      "manual" implementations, as discussed in Section 4.2.  The
      specification of the CDNI DRIS interface SHALL include a
      description for each of these implementation options.

   o  The CDNI routing and CDNI DRIS interfaces MUST be independent.








Le Louedec, et al.      Expires January 10, 2013               [Page 23]


Internet-Draft            CDNI Request Routing                 July 2012


5.  CDNI request routing is just another routing and signaling problem

   This part of the CDN interconnection framework the IETF has been
   referring to so far with the term "CDNI Request Routing" is just
   another routing, signaling and forwarding problem in a long series of
   the telecommunication history.

   For example one can draw an analogy with the IP/MPLS-TE framework,
   notably, as shown on Figure 6 and below, between:

   o  the CDNI routing interface and any IP routing protocol/interface
      (such as BGP/IGP IP routing protocols),

   o  the CDNI DRIS interface and a signaling protocol such as RSVP-TE.

   It is to be noted that such an analogy must be considered with care
   because the context and objectives of CDN interconnection are
   different from IP routing, signaling and forwarding.  In particular,
   the type of information exchanged via the CDNI DRIS interface is
   totally different from the information exchanged by protocols like
   RSVP-TE in IP/MPLS networks.  Anyway this analogy may ease to
   understand the role of the CDNI DRIS interface in the CDNI framework.

   Another key point to note in this analogy is that IP prefix is one of
   the most important concepts in IP networks.  It is used in most IP
   processes (IP routing, packet filtering, MPLS-TE signaling, etc.).
   It has been a highly useful and powerful concept to simplify the
   specification of TCP/IP protocols as well as to ensure performance
   and scalability of IP networks.  For example exchanging IP routing
   information per IP prefix has been a MUST to ensure IP routing
   performance and scalability.

   The equivalent concept to IP prefix has the same importance in the
   CDN interconnection framework.  The concept is named
   "contentRequestScope" in Figure 6.  A contentRequestScope designates
   a class of content requests sharing common properties (e.g., "all the
   HTTP requests", or "all HTTP requests issued by French users", or
   "all RTSP and HTTP requests with signed URL", etc.).

   In the same way as IP prefix is a key concept for specifying TCP/IP
   protocols, "contentRequestScope" is THE main concept for the CDN
   interconnection framework.  This highly useful and powerful concept
   SHALL be used to simplify the specification of ALL CDN
   interconnection interfaces, as well as to ensure performance and
   scalability in CDN interconnection.






Le Louedec, et al.      Expires January 10, 2013               [Page 24]


Internet-Draft            CDNI Request Routing                 July 2012


   +--------------------------------+----------------------------------+
   | IP/MPLS-TE concepts            | CDN Interconnection concepts     |
   +--------------------------------+----------------------------------+
   | IP packet Forwarding           | Content request redirection      |
   +--------------------------------+----------------------------------+
   | IP prefix                      | ContentRequestScope              |
   | (correspond to a class of IP   |  (correspond to a class of       |
   |  addresses sharing the same    |   content requests sharing       |
   |  prefix)                       |   common properties)             |
   +--------------------------------+----------------------------------+
   | Ingress Provider Edge Router   | upstream CDN (uCDN)              |
   | (ILSR)                         |                                  |
   +--------------------------------+----------------------------------+
   | Egress Provider Edge Router    | Delivery resource (delivery node |
   | (ELSR)                         | or downstream CDN)               |
   +--------------------------------+----------------------------------+
   | IP routing interfaces (running | CDNI routing interface           |
   | IGP/BGP IP routing protocols)  |                                  |
   +--------------------------------+----------------------------------+
   | IP routing information         | CDNI routing information         |
   | (IP prefix <-> Next Hop)       | (ContentRequestScope <-> dCDN)   |
   +--------------------------------+----------------------------------+
   | IP FEC table construction      | Redirection table construction   |
   | (IP prefix <-> ELSR)           | (ContentRequestScope <-> delivery|
   |                                | resource)                        |
   +--------------------------------+----------------------------------+
   | Signaling information provided | Signaling information provided   |
   | by the RSVP-TE protocol        | by the CDNI DRIS interface       |
   | (MPLS label <-> ELSR)          | (DRI <-> delivery resource)      |
   +--------------------------------+----------------------------------+
   | To encapsulate an IP packet in | To generate a redirected content |
   | an MPLS frame (using an MPLS   | request (using a DRI)            |
   | Label)                         |                                  |
   +--------------------------------+----------------------------------+
   | To forward a packet out of the | To redirect a content request    |
   | nominal route based on IGP     | out of the authoritative CDN,    |
   | and BGP routing information,   | to another CDN, thanks to CDN    |
   | thanks to MPLS Traffic         | interconnection technologies     |
   | Engineering technologies       |                                  |
   +--------------------------------+----------------------------------+
   | To forward an IP packet        | To redirect a content request to |
   | encapsulated in an MPLS frame  | to the selected downstream CDN   |
   | via - or to - the destination  | - or to the selected delivery    |
   | ELSR thanks to the MPLS        | node - thanks to the             |
   | header of the MPLS frame       | Downtream Resource Identifier    |
   |                                | (DRI) used to forge the response |
   |                                | to the initial content request   |
   +--------------------------------+----------------------------------+



Le Louedec, et al.      Expires January 10, 2013               [Page 25]


Internet-Draft            CDNI Request Routing                 July 2012


          Figure 6: Analogy between IP/MPLS-TE and CDNI concepts

   CDNI Routing interfaces exchanges CDNI routing information per
   contentRequestScope, i.e. per class of content requests sharing
   common properties.

   Analogically: IP routing protocols like IGP/BGP exchange routing
   information per IP prefix, i.e. per class of IP addresses sharing
   common properties.

   The upstream CDN builds its redirection table with information
   provided by the CDNI Routing interface and the CDNI DRIS interface.

   Analogically: The Ingress Provider Edge Router (ILSR) builds its
   forwarding table with information provided by the IP routing and
   MPLS-TE signaling protocols.

   When receiving a content request, which has possibly been already
   redirected by some upstream CDNs, a CDN consults its forwarding table
   to generate a response using the adequate DRI, provided by the CDNI
   DRIS interface, which redirects the content request to the selected
   delivery resource (which is a CDN or a node downstream).

   Analogically: When receiving an IP packet, possibly encapsulated in
   an MPLS frame, an Ingress Provider Edge Router (ILSR) consults its
   forwarding table to manipulate it adequately.  This manipulation may
   include to encapsulate it in an MPLS frame, based on the signaling
   information provided by the RSVP-TE protocol, which makes it being
   then forwarded to the right Egress Provider Edge router (ELSR).


6.  Conclusion and recommendations

   A first key message of this document is that the term "CDNI request
   routing" is confusing as it makes a mix-up of clearly different set
   of processes and interfaces.

   A second key message of this document is that this part of the CDN
   interconnection framework the IETF has been referring to so far with
   the term "CDNI Request Routing" is just another routing, signaling
   and forwarding problem in a long series of the telecommunication
   history.  For example, one can draw a direct analogy between the IP/
   MPLS-TE framework and the CDN interconnection framework.

   Thus one can directly be inspired by the best practices and results
   of the efforts invested over years, even decades, to develop
   technologies in the past, such as IP/MPLS-TE, to specify adequately
   CDN interconnection interfaces.



Le Louedec, et al.      Expires January 10, 2013               [Page 26]


Internet-Draft            CDNI Request Routing                 July 2012


   The proposals from the current document can be smoothly integrated in
   the WG drafts, especially [I-D.ietf-cdni-framework] and
   [I-D.ietf-cdni-requirements], as they essentially propose (useful)
   clarifications of the existing framework.

   We recommend to review [I-D.ietf-cdni-framework], at least its
   section 4.2.  Appendix A provides a proposal to replace the current
   Section 4.2 of [I-D.ietf-cdni-framework].

   We recommend to review [I-D.ietf-cdni-requirements], to clearly
   distinguish the requirements specific to the CDNI routing interface
   from the requirements specific to the CDNI DRIS interface.

   We also recommend to review the charter of the CDNI WG, in particular
   to replace the following objective:

   o  "WG Creation + 18 months: Submit specification of the CDNI Request
      Routing protocol to IESG as Proposed Standard"

   by the two following objectives:

   o  "WG Creation + 18 months: Submit specification of the CDNI Routing
      interface to IESG as Proposed Standard"

   o  "WG Creation + 18 months: Submit specification of the CDNI
      Downstream Resource Identifier Signaling (DRIS) Interface to IESG
      as Proposed Standard"

   Last but not least, we recommend that the specification of ALL CDN
   interconnection interfaces, including the CDNI routing interface and
   the CDNI DRIS interface, rely on the "contentRequestScope" concept,
   i.e. the equivalent concept to IP prefix for CDN interconnection.  In
   the same way as IP prefix is a key concept for specifying TCP/IP
   protocols, "contentRequestScope" is THE main concept for the CDN
   interconnection framework.  This highly useful and powerful concept
   SHALL be used to simplify the specification of ALL CDN
   interconnection interfaces, as well as to ensure performance and
   scalability in CDN interconnection.


7.  Acknowledgments

   The authors would like to thank Chris Hawinkel, Larry Peterson, Yvan
   Massot, Ali Gouta, Emile Stephan, and Patrick Fleming for their
   inputs and comments.

   They also thank the contributors of the EU FP7 OCEAN project in the
   frame of which these proposals have been elaborated.



Le Louedec, et al.      Expires January 10, 2013               [Page 27]


Internet-Draft            CDNI Request Routing                 July 2012


   The work leading to these results has received funding from the
   European Union's Seventh Framework Programme (FP7/2007-2013) in OCEAN
   project (FP7-ICT-248775; http://www.ict-ocean.eu/).


8.  IANA Considerations

   This memo includes no request to IANA.


9.  Security Considerations

   Those are discussed in [I-D.ietf-cdni-problem-statement].


10.  Informative References

   [I-D.ietf-cdni-framework]
              Peterson, L. and B. Davie, "Framework for CDN
              Interconnection", draft-ietf-cdni-framework-00 (work in
              progress), April 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-08 (work in
              progress), June 2012.


Appendix A.  Proposal for Section 4.2 of CDNI framework draft

   "4.2.  Request Routing Interface

   The request routing interface is not a single interface, it
   corresponds to two separate interfaces with clear roles:




Le Louedec, et al.      Expires January 10, 2013               [Page 28]


Internet-Draft            CDNI Request Routing                 July 2012


   1) The CDNI Routing Interface

   The CDNI routing interface is dedicated to the CDNI routing process.
   The CDNI routing process consists in the advertisement of CDNI
   routing information from the downstream CDN to the upstream CDN (the
   upstream CDN never provides the downstream CDN with any CDNI routing
   information).  CDNI routing information details capabilities of the
   downstream CDN that the upstream CDN must take into account in its
   dCDN selection process.

   2) The CDNI Downstream resource Identifier Signaling (DRIS) Interface

   AFTER the CDN selection process is achieved by the upstream CDN for a
   given content request, the upstream CDN MUST generate a response
   redirecting that request towards the selected delivery resource by
   inserting in this response an identifier of that selected delivery
   resource.

   This selected delivery resource can be:

   1.  a delivery node within the upstream CDN,

   2.  a downstream CDN (i.e. the request routing system of that
       downstream CDN), or

   3.  a delivery node within a downstream CDN.

   In the cases "2." and "3." , the identifier of that selected delivery
   resource MUST be provided by the downstream CDN to the upstream CDN.
   The downstream CDN uses the CDNI DRIS interface to provide the
   upstream CDN with this identifier called "Downstream resource
   Identifier" (DRI).


Authors' Addresses

   Yannick Le Louedec
   France Telecom - Orange
   2 avenue Pierre Marzin
   Lannion,   22307
   France

   Phone: +33 2 96 05 17 64
   Email: yannick.lelouedec@orange.com







Le Louedec, et al.      Expires January 10, 2013               [Page 29]


Internet-Draft            CDNI Request Routing                 July 2012


   Anne Marrec
   France Telecom - Orange
   2 avenue Pierre Marzin
   Lannion,   22307
   France

   Phone: +33 2 96 05 18 71
   Email: anne.marrec@orange.com


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

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


   Marcin Pilarski
   Orange Polska / WUT
   ul. Obrzezna 7 / ul. Koszykowa 75
   Warsaw, Mazowieckie  02-691 / 00-662
   Poland

   Email: marcin.pilarski@orange.com / marcin.pilarski@mini.pw.edu.pl
























Le Louedec, et al.      Expires January 10, 2013               [Page 30]