Internet DRAFT - draft-xiaoyan-cdni-request-routing-protocol

draft-xiaoyan-cdni-request-routing-protocol











 
CDNI Working Group                                         Xiaoyan.He 
Internet Draft                                            Jincheng.Li 
Intended status: Standards Track                      Spencer.Dawkins 
Expires: April 2012                                            Huawei 
                                                              Ge.Chen 
                                                        China Telecom 
                                                     October 13, 2011 
                                                                       
             Request Routing Protocol for CDN Interconnection 
            draft-xiaoyan-cdni-request-routing-protocol-00.txt 


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), its areas, and its working groups.  Note that 
  other groups may also distribute working documents as Internet-Drafts. 

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

  The list of current Internet-Drafts can be accessed at 
  http://www.ietf.org/ietf/1id-abstracts.txt 

  The list of Internet-Draft Shadow Directories can be accessed at 
  http://www.ietf.org/shadow.html 

  This Internet-Draft will expire on April 13,2012. 

Copyright Notice 

  Copyright (c) 2011 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 
 
He                     Expires April 13, 2012                 [Page 1] 
 
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  Legal Provisions and are provided without warranty as described in 
  the Simplified BSD License. 

Abstract 

  The Request Routing Protocol allows the Request Routing system in 
  interconnected Content Delivery Network(CDNs) to communicate 
  to ensure that an end user request can be (re)directed from an 
  upstream CDN to a surrogate in the downstream CDN. This document 
  describes the details of the protocol used to provide this mechanism. 

   
Table of Contents 

   
  1. Introduction ................................................ 3 
     1.1. Terminology ............................................ 3 
     1.2. Reference Model ........................................ 4 
  2. Conventions used in this document ............................ 5 
  3. Protocol Function and Operation Overview ..................... 5 
     3.1. Request Routing ........................................ 6 
        3.1.1. DNS based Request Routing Protocol ................. 8 
           3.1.1.1. HTTP Redirection utilized in a Downstream CDN .. 8 
           3.1.1.2. DNS Redirection utilized of Downstream CDN .... 10 
        3.1.2. HTTP based Request Routing Protocol ............... 12 
     3.2. Capability Information Advertising ..................... 13 
  4. Protocol Specification ..................................... 14 
        4.1.1. Recursive Request Routing ......................... 14 
           4.1.1.1. DNS based Request Routing Protocol ........... 14 
              4.1.1.1.1. Upstream CDN Behavior ................... 14 
              4.1.1.1.2. Downstream CDN Behavior ................. 15 
           4.1.1.2. HTTP based Request Routing Protocol .......... 15 
              4.1.1.2.1. Upstream CDN Behavior ................... 15 
              4.1.1.2.2. Downstream CDN Behavior ................. 15 
        4.1.2. Iterative Request Routing ......................... 16 
     4.2. Capability Information Advertising ..................... 16 
        4.2.1. Capability information description ................ 16 
        4.2.2. Message description ............................... 17 
           4.2.2.1. Report mode .................................. 17 
           4.2.2.2. Query mode................................... 17 
        4.2.3. Message examples .................................. 18 
           4.2.3.1. Report mode .................................. 18 
           4.2.3.2. Query mode................................... 19 
  5. Security Considerations .................................... 19 
  6. IANA Considerations ........................................ 20 
  7. References ................................................. 20 
     7.1. Normative References................................... 20 
     7.2. Informative References ................................. 20 
  8. Acknowledgments ............................................ 21 

 
 
He                     Expires April 13, 2012                 [Page 2] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   


   
1. Introduction 

  A Content Delivery Network(CDN) is a system of computers built on an  
  existing IP network which is used for large scale content delivery, 
  via prefetch or cache contents to its distributed computers close to 
  the end users, a CDN can improve access to the data it caches, reduce 
  access latency and improve end user's experience.   
   
  In recent years the volume of video and multimedia content delivered 
  over the internet is rapidly increasing. To accommodating this 
  increase, existing CDN providers are scaling up their infrastructure
  and many Network Service Providers (NSPs) are deploying their 
  own CDNs. 
  Another emerging requirement is CDN Interconnection (CDNI). 
  Several real world use cases are described in [I-D.draft-cdni-use-
  cases] to prove the necessity for CDN interconnection. The most 
  frenquently mentioned use case is via leveraging the collective CDN
  footprint of interconnected standalone CDNs to achieve the goal of 
  delivering content to additional distributed end users regardless 
  of their location.  
   
  As there is no existing standard to facilitate CDN interconnection, 
  IETF has established a working group to produce specifications needed. 
  This draft is written in response to the problem area described in
  [I-D.draft-cdni-problem-statement], when CDNs are interconnected as
  described in [I-D.draft-cdni-use-cases] based on the requirements
  described in [I-D.draft-cdni-requirements], and using the technology
  framework described in [I-D.davie-cdni-framework].  
   
  The purpose of this document is to define the request routing 
  protocol for CDNI, which is one of the main building blocks of the 
  CDN interconnection architecture described in 
  [I-D.draft-cdni-requirements]. 
   
1.1. Terminology 

   This document reuses the terminology defined in [I-D.draft-cdni-
   problem-statement]. 
    
 
 
He                     Expires April 13, 2012                 [Page 3] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

   The term "Distinguished CDN Domain" defined in [I-D.davie-cdni-
   framework] also reused in this document. 
   
  The following terms are also used by this document: 
   
  DNS Redirection: The act of using DNS name resolution for the routing 
  process of a CDN. In DNS Redirection, the DNS resolver of the CDN 
  makes the routing decision based on a local policy and returns the
  result as the response of a DNS query request to redirect a user 
  agent to a new target. In CDNI, the result may point to a surrogate
  of the CDN, another interconnected CDN etc. 
   
  HTTP Redirection: The act of using an HTTP redirection response to 
  redirect a user agent to a new target. The new target is the result 
  of the routing decision of a CDN at the time it receives a content 
  request via HTTP. In CDNI, the result may point to a surrogate of the
  CDN, another interconnected CDN. etc. 
   
 
1.2. Reference Model 

  Figure 1 from [I-D.draft-cdni-problem-statement] illustrating the 
  CDNI model and the CDNI protocols is replicated below. This document 
  describes the Request Routing Protocol shown in the figure. 
  
  He                     Expires April 13, 2012                 [Page 4] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 



     --------
    /        \
    |   CSP  |
    \        /
     --------
         *
         *
         *                         /\
         *                        /  \
     ----------------------      |CDNI|        ----------------------
    /     Upstream CDN     \     |    |       /    Downstream CDN    \
    |      +-------------+ | Control Interface| +-------------+      |
    |*******   Control   |<======|====|========>|   Control   *******|
    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
    |*            *    *   |     |    |       |   *    *            *|
    |*     +------*------+ | Logging Interface| +------*------+     *|
    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
    |* *     *         *   | Request Routing  |   *         *     * *|
  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
  . |* * *                 .  CDNI Metadata   |                 * * *| .
  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
  . |* * * |             | |  .   \  /        | |             | * * *| .
  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
  . |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
  . |*******  +---------+| |   Acquisition    | |+----------+ *******| .
  . |      +-------------+ |                  | +-------*-----+      | .
  . \                      /                  \         *            / .
  .  ----------------------                    ---------*------------  .
  .                                                     *              .
  .                                                     * Delivery     .
  .                                                     *              .
  .                                                  +--*---+          .
  ...............Request.............................| User |..Request..
                                                     | Agent|
                                                     +------+
               
                <==>  interfaces inside the scope of CDNI                                     
                ****  interfaces outside the scope of CDNI 
                ....  interfaces outside the scope of CDNI                                      
                          Figure 1: CDNI Model 
                                    
2.  Conventions used in this document 

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
  document are to be interpreted as described in RFC-2119 [RFC2119].   
  
He                     Expires April 13, 2012                 [Page 5] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   
3. Protocol Function and Operation Overview 

  The Request Routing Protocol is one of the main building blocks for
  CDNI. The main function of the Request Routing Protocol is to allow
  the Request-Routing systems (see Figure 1) in interconnected CDNs to 
  communicate to facilitate redirection of the request across CDNs. 
  In particular, its function can be summarized as follows: 
  *  allow the Upstream CDN (uCDN)to query the Downstream CDN (dCDN) at
     request-routing time before redirecting the request to the 
     Downstream CDN. 
  *  allow the 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. 
   
  The detailed requirements which the Request Routing Protocol need to  
  meet and priorities of those requirements are described in section 5, 
  [I-D.draft-cdni-requirements]. 
   
  To enable the communications over the Request Routing Interface, the 
  two interconnected CDNs need to know each other's contact address(es). 
  For example, an Upstream CDN needs to know the contact address 
  of a Downstream CDN to send a query request based on HTTP for 
  redirection preference, or a Downstream CDN needs to know the contact 
  address(es) of the upstream peer it should report its capability 
  information to.  

  The contact address may be statically pre-configured, 
  dynamically discovered via control interface, or other means. However, 
  they are not specified in this document, as this is considered not in 
  the scope of the CDNI Request Routing Protocol. 

3.1. Request Routing 

  The CDNI solution must support two request routing mechanisms. As 
  illustrated in section 3.2 and 3.4 of [I-D.davie-cdni-framework], the 
  Iterative Request Routing method does not invoke any interaction over 
  the request routing interface across interconnected CDNS. This 
  document will not discuss Iterative Request Routing further.  

  In the case of Recursive Request Routing, an Upstream CDN forwards a 
  routing request from a user agent to a Downstream CDN for surrogate 
  selection. The candidate protocols for these interactions are DNS and 
  HTTP. Moreover, the routing mechanisms used between the CDN and the 
  user agent (DNS and HTTP Redirection) of the two interconnected CDNs 
  should also be taken into account as they may affect the type of query
  request the Upstream CDN send to a Downstream CDN and the 
  information the Downstream CDN may send in its query response. 

  The request routing procedure has several variants depending on the 
  factors including: 
 
He                     Expires April 13, 2012                 [Page 6] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   
  O Which routing mechanism is adopted by an Upstream CDN, DNS 
    Redirection or HTTP Redirection.  

  O Which protocol is adopted over the Request Routing Interface, DNS 
    or HTTP. 

  O Which routing mechanism is adopted by a Downstream CDN, DNS 
    Redirection or HTTP Redirection. 

  All possible combinations and their validity are shown in Table 1. 
   +-------+---------+----------+------------ +-----------------------+ 
   |CaseNO.|  uCDN   | RRI      |   dCDN      |       Note            | 
   |       | Received| Interface| Response    |                       | 
   |       |  Request|          |             |                       | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  1    |  DNS    | DNS based| DNS with IP | dCDN works in HTTP    | 
   |       |         |          |address of RR| Redirection mode,     | 
   |       |         |          |             |illustrated in section | 
   |       |         |          |             |3.1.1.1.               | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  2    |  DNS    | DNS based|  DNS with   | dCDN works in DNS     | 
   |       |         |          | hostname of | Redirection mode,     | 
   |       |         |          |    RR       | illustrated in section| 
   |       |         |          |             |3.1.1.2.               | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  3    |  DNS    |HTTP based| Invalid case|Protocol conversion    | 
   |       |         |          |             |occurs in uCDN,        | 
   |       |         |          |             | invalid case.         | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  4    |  HTTP   |HTTP based| HTTP 302    | dCDN works in HTTP    | 
   |       |         |          | Redirection | Redirection mode,     | 
   |       |         |          |             |illustrated in section | 
   |       |         |          |             |3.1.2.                 | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  5    |  HTTP   |HTTP based|   DNS       | dCDN works in DNS     | 
   |       |         |          | Redirection | Redirection mode,     | 
   |       |         |          |             | invalid case.         | 
   +-------+---------+----------+------------ +-----------------------+ 
   |  6    |  HTTP   |DNS  based| Invalid case| Protocol conversion   | 
   |       |         |          |             | occurs, invalid case. | 
   +-------+---------+----------+------------ +-----------------------+ 
                    Table 1: Recursive Routing Cases 

  The rules to filter the cases and determine the validity of them are 
  discussed below.  

  The Upstream CDN must not perform protocol conversion (A DNS 
  query to an HTTP request or vice versa). To assist the routing 
  decision of a Downstream CDN, the Upstream CDN conveys as much 
  information as possible to the Downstream CDN, e.g. URI of the 
  requested content, the client's location information. In the case of
  HTTP to DNS conversion, a DNS request cannot convey all the 
  information an HTTP request contains. In the case of DNS to HTTP
  conversion, a full HTTP URL cannot be constructed through a simple
 
He                     Expires April 13, 2012                 [Page 7] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  domain name contained by a DNS query request. Hence it is concluded
  that the protocol type used in the Request Routing Interface will be
  consistent with the one the Upstream CDN received from the user 
  agent.  Case3, Case6 are invalid according to this rule. 

  The Downstream CDN can determine according to its local policy 
  a DNS Redirection or an HTTP Redirection to be adopted. When 
  receiving a DNS query request over the Request Routing Interface. 
  If DNS Redirection is selected, as the location information has 
  been changed to the Upstream CDN's when it proies the DNS query 
  request, the Downstream CDN cannot get the user agent's location 
  information from the query request. The Downstream CDN sends a 
  response with a CNAME with the hostname of the Request Router, 
  so that the user agent issues another DNS query request which 
  will convey its location information as shown in case2. If HTTP 
  Redirection is selected, the Downstream CDN sends a response with
  the IP address of its Request Router, so that it can receive a 
  subsequent content request based on HTTP containing the client's 
  location information, to allow selection of an appropriate surrogate 
  as shown in case1. 

  Based on filter rules above, Case 1, 2, and 4 are valid cases for
  CDNI. The following section describes these cases in detail. 

3.1.1. DNS based Request Routing Protocol 

3.1.1.1. HTTP Redirection utilized by Downstream CDN 

  This example illustrates the CaseNo1 of Table 1. Based on local 
  policy, the Upstream CDN adopts the DNS Redirection with the user 
  agent while the Downstream CDN utilizes the HTTP Redirection. The 
  Downstream CDN should return the IP address in an RR. In this example,
  the distinguished domain name of the Downstream CDN is "cdni.op-
  b.example". 
   
  Note: To simplify the presentation, the full URL of the HTTP GET 
        message is not shown in the example figures of this document. 
        Only the FQDN at the beginning of each URL is explicitly 
        presented, however the rest of the URL e.g. the path 

 
 
He                     Expires April 13, 2012                 [Page 8] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

        parameters contained in the URL should be considered to be
        present. 
   
    End-User                      CDN B                     CDN A 
          |DNS video.cp.example     |                         |(1) 
          |-------------------------------------------------->| 
          |                         | DNS video.cp.example.   |  
          |                         |    cdni.op-b.example    | 
          |                         |<------------------------|(2) 
          |                         |IPaddr of B's Request Router 
          |                         |------------------------>| 
          |      IPaddr of B's Request Router                 | 
          |<--------------------------------------------------|(3) 
          |HTTP GET video.cp.example|                         | 
          |------------------------>|        (4)              | 
302 node1.cdni.op-b.example/video.cp.example                   | 
          |<------------------------|                         | 
        DNS node1.cdni.op-b.example |                         | 
          |------------------------>|                         | 
          |IP address of B's node1  |(5)                      | 
          |<----------------------- |                         | 
 HTTP GET node1.cdni.op-b.example/video.cp.example            | 
          |------------------------>|                         | 
          |Data                     |(6)                      | 
          |<------------------------|                         | 
          |                         |                         | 
   
           Figure 2 DNS based CDNI Recursive Request Routing 1 
 
                                     
  1.   A Request Routing System of CDN A processes the DNS request for 
       its customer based on the domain video.cp.example and recognizes 
       that the end-user is best served by another CDN, specifically 
       CDN B. Based on the pre-configured distinguished domain name of 
       CDN B and a negotiated rules for constructing a domain 
       name contained in a DNS query request over RRI that have been
       negotiated with CDN B, the Request 
       Routing System changes the domain name to CDN B's domain name, 
       with the CP's domain information, and acts as a 
       proxy server forwarding the DNS request to CDN B. 
        

 
 
He                     Expires April 13, 2012                 [Page 9] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

       Note: For simplicity, the local DNS invoked in the procedure is 
             not shown. 
   
  2.   Based on the local policy, CDN B determines that the routing 
       mechanism utilized internally is HTTP Redirection. CDN B returns 
       the IP address of a Request Router so that the RR get the 
       subsequent HTTP content request from the user agent. 
   
  3.   CDN A proxy the response back to the user agent. 
 
  4.   The user agent sends the content requests to the Request Router 
       of CDN B. Based on local routing decision policy, e.g. whether 
       content hits take the highest priority or location proximity 
       takes the highest priority, the Request Router selects a 
       delivery node to serve the user agent and returns an HTTP 302
       message to redirect the content request.  
   
  5.   The user agent performs a DNS lookup for the hostname of the 
       delivery node and gets the IP address of the node. 

  6.   The user agent requests the content from CDN B's delivery node. 
       The node contains the content, so it sends the content to 
       the user agent. 
     
3.1.1.2. DNS Redirection utilized by Downstream CDN 

  This example illustrates the CaseNo2 of Table 1. Based on local 
  policy, the Upstream CDN and the Downstream CDN both utilize the DNS 
  Redirection with the user agent. As the Downstream CDN cannot get the 
  user agent's location information through the DNS request forwarded 
  by the Upstream CDN, in this case, the DNS resolver of the Downstream 
  CDN is configured to return a CNAME of the RR to make it receive 
  another DNS query request sent by the user agent/local DNS with 
  information of the user's location. Again, the distinguished domain 
  name of the Downstream CDN is "cdni.op-b.example". 
   
 
He                     Expires April 13, 2012                [Page 10] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   
     End-User                      CDN B                     CDN A 
           |DNS video.cp.example     |                         |(1) 
           |-------------------------------------------------->| 
           |                         | DNS video.cp.example.   |  
           |                         |    cdni.op-b.example    | 
           |                         |<------------------------|(2) 
           |                         |CNAME video.cp.example.  | 
           |                         |   rr.cdni.op-b.example  | 
           |                         |------------------------>|                    
           CNAME video.cp.example.rr.cdni.op-b.example         | 
           |<--------------------------------------------------|(3) 
           |   DNS video.cp.example. |                         | 
           |    rr.cdni.op-b.example |                         | 
           |------------------------>|                         | 
         IP address of delivery node |(4)                      | 
           |<------------------------|                         | 
           |HTTP GET video.cp.example|                         | 
           |------------------------>|                         | 
           |Data                     |(5)                      | 
           |<------------------------|                         | 
           |                         |                         | 
 
          Figure 3 DNS based CDNI Recursive Request Routing 2 
                                    
  1.   A Request Routing System of CDN A processes the DNS request for 
       its customer based on the domain video.cp.example and recognizes 
       that the end-user is best served by another CDN, specifically 
       CDN B. Based on the pre-configured distinguished domain name of 
       CDN B and rules that have been negotiated with CDN B that 
       describe how to construct a domain name contained in a DNS query
       request over RRI, the Request Routing System changes the domain 
       name to CDN B's domain name accompanying with the CP's domain 
       information and acts as a proxy server forwarding the DNS 
       request to CDN B. 
        
       Note: For simplicity, the local DNS invoked in the procedure is 
             not shown. 
 
  2.   CDN B recognizes that the request is from a peer CDN rather than 
       a user agent by the distinguished domain name. Based on the 
       local policy, CDN B determines that the routing mechanism 
       utilized internally is DNS Redirection. CDN B returns the CNAME
       of a Request Router so that the user agent will send another DNS
       query request to get the user agent's location information. 
 
  3.   CDN A proxy the response back to the user agent. 
 
 
He                     Expires April 13, 2012                [Page 11] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

   
  4.   The user agent sends the content requests to the Request Router 
       of CDN B based on DNS with the CNAME of the RR. Based on local 
       routing decision policy, the Request Router selects a delivery 
       node to serve the user agent and returns IP address of the node.  
   
  5.   The user agent requests the content from CDN B's delivery node, 
       the node holds the content at the time and send the content to 
       the user agent. 
 
3.1.2. HTTP based Request Routing Protocol 

  This example illustrates the CaseNo4 of Table 1. Based on local 
  policy, the Upstream CDN and the Downstream CDN both utilize the HTTP 
  Redirection with the user agent. The Upstream CDN shall provide as 
  much information as possible to the Downstream to assist making the 
  routing decision. For example, it includes the content URI and the 
  user's location information etc. 
   
   
        End-User                   CDN B                    CDN A 
           |DNS video.cp.example     |                         | 
           |-------------------------------------------------->| 
           |                         |                         | (1) 
           |IPaddr of A's Request Router                       | 
           |<--------------------------------------------------| 
           |HTTP GET video.cp.example|                         | 
           |-------------------------------------------------->|(2) 
           |        HTTP GET cdni.op-b.example/video.cp.example| 
           |                         |<------------------------| (3) 
           |           302 node1.cdni.op-b.example/video.cp.example 
           |                         |------------------------>| 
           |        302 node1.cdni.op-b.example/video.cp.example 
           |<--------------------------------------------------|(4) 
         DNS node1.cdni.op-b.example |                         | 
           |------------------------>|                         | 
           |IP address of B's node1  |(5)                      | 
           |<----------------------- |                         | 
HTTP GET node1.cdni.op-b.example/video.cp.example              | 
           |-----------------------> |                         | 
           |Data                     | (6)                     |
           |<------------------------|                         | 
           |                         |                         | 

       Figure 4 HTTP protocol based CDNI Recursive Request Routing  

 
 
He                     Expires April 13, 2012                [Page 12] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   


   
  1.  A DNS resolver for CDN A processes the DNS request for its 
      customer based on the domain video.cp.example.  Based on local 
      policy, HTTP Redirection is adopted for this request. Hence it 
      returns the IP address of a Request Router in CDN A. 
 
  2.  A Request Router of CDN A processes the user agent's content 
      request and recognizes that the end-user is best served by 
      another CDN, specifically CDN B. Based on pre-configuration 
      or other means of discovery, the Request Router pushes the 
      distinguished domain name of CDN B onto the original URL and 
      acts as a proxy server forwarding the request to CDN B's Request 
      Router. It also appends an X-Forwarded-For header into the 
      request with the value set to the user's IP address extracted 
      from the IP package header of the HTTP request it received. 
 
  3.   Based on local routing decision policy, e.g. whether content 
       hits take the highest priority or location proximity takes the
       highest priority, the Request Router of CDN B select a delivery
       node for the end user and returns an HTTP 302 message to 
       redirect the content request to the node. 
   
  4.   CDN A proxies the response back to the user agent. 
   
  5.   The user agent performs a DNS lookup for the hostname of the 
       delivery node and gets the IP address of the node. 

  6.   The user agent requests the content from CDN B's delivery node. 
       Since the node holds the content, it sends the content to 
       the user agent. 
   
3.2. Capability Information Advertising 

  Besides forwarding a routing request from the Upstream CDN to the 
  Downstream CDN at the request routing time, another important 
  function of the Request Routing Protocol in Figure 1 is to 
  advertis the capability information of the Downstream CDN to the 
  Upstream CDN.  


 
 
He                     Expires April 13, 2012                [Page 13] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  The Downstream CDN may advertise its delivery capability to the 
  Upstream CDN de-coupled with the routing request itself, during a 
  periodic interval, e.g. every 5 minutes. This is called "report mode"
  in this document. Another one is called "query mode", means the 
  Upstream CDN does not hold sufficient information to decide which
  Downstream CDN is most appropriate to deliver the content for the end
  user. In query mode,it then acquires the capability information from
  the Downstream CDN dynamically before make its routing decision. 

  HTTP/1.1 [RFC2616] protocol is used for capability advertising. The 
  detailed capability information description and message definition is 
  described in section 5 of this document. 

  Note: Although Iterative Request Routing is not discussed in this 
        document, however, the capability information advertising 
        procedures specified are also applicable to Iterative Request 
        Routing. 

4. Protocol Specification 

  This section specifies how the Request Routing Protocol enables 
  the Downstream CDN to advertise its capability to the Upstream CDN 
  and to enable the Upstream CDN acting as a proxy server to forward 
  the routing request from a user agent to the Downstream CDN. 

4.1.1. Recursive Request Routing 

4.1.1.1. DNS based Request Routing Protocol 

4.1.1.1.1. Upstream CDN Behavior 

  Upon receiving a DNS query request from a user agent, the Request 
  Routing System of the Upstream CDN SHALL first determine a routing 
  mechanism according to local policy. In case of DNS Redirection is 
  leveraged, based on the local routing policy, if it is aware that the 
  user is best served by another CDN, the Upstream CDN SHALL select a 
  Downstream CDN and forward the DNS request to the Downstream CDN. When 
  HTTP Redirection is adopted, the Upstream CDN SHALL respond with the 
  address of a Request Router of the Upstream CDN. 

  The QNAME contained in the DNS query request which is forwarded to 
  the Downstream CDN SHALL be constructed by the rules negotiated by 
  the two interconnected CDNs and based on the distinguished domain 
  name of the Downstream CDN. 



 
 
He                     Expires April 13, 2012                [Page 14] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  Upon receiving a response from the Downstream CDN, the Request 
  Routing System of the Upstream CDN shall forward it back to the user 
  agent with the DNS payload unchanged. 

4.1.1.1.2. Downstream CDN Behavior 

  Upon receiving a DNS query request, the Downstream CDN SHALL first 
  identify that this is a request for CDNI based on the distinguished
  domain name contained in the query request, and extracts the content
  provider's domain name. It then SHALL determine a routing mechanism 
  according to local routing policy. 

  Note: The local routing policy may take into account the CP's policy 
        if existed identified by the CP's domain name. 

  In case of DNS Redirection, it SHALL select a request router and 
  return a response containing a CNAME with the hostname of the request
  router.  

  In case of HTTP Redirection, it SHALL select a request router and 
  return a response containing the IP address of the Request Router.  

4.1.1.2. HTTP based Request Routing Protocol 

4.1.1.2.1. Upstream CDN Behavior 

  Upon receiving an HTTP GET request from a user agent for specific
  content, based on the local routing policy, if it is determined that
  the user is best served by another CDN, the Request Router of the
  Upstream CDN SHALL select a Downstream CDN for the end user, insert
  an X-Forwarded-For header into the request with the value set to the
  User Agent's IP address, augment the original URL with the 
  distinguished domain name of the Downstream CDN in front of it, and
  then forward the request to the elected Downstream CDN.  

  After receiving an HTTP "302" redirection response from the 
  Downstream CDN, the Upstream CDN SHALL forward it back to the user 
  agent. 

4.1.1.2.2. Downstream CDN Behavior 

  Upon receiving an HTTP GET request, the Downstream CDN SHALL select a 
  delivery node for the user based on the local routing policy. 
  If the user's location information is required to make the routing 
  decision, it SHALL obtain that from an X-Forwarded-For header if this
  hearder exists. The Downstream CDN SHALL then return a response with
  a 302 Redirection message. The Location header's value is constructed
  by truncating the CDN B's domain name from the original URL in the 
  request it received, and inserting
 
 
He                     Expires April 13, 2012                [Page 15] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  the host name of the selected delivery node onto the front of 
  the remaining URL. 

4.1.2. Iterative Request Routing 

  Note: Whether any content relative to Iterative Request Routing should 
        be added here is to be determined by the CDNI working group. 

4.2. Capability Information Advertising 

4.2.1. Capability information description 

  The Downstream CDN exposes capability information to an Upstream CDN 
  on Request Routing Interface to facilitate CDN selection among other 
  functions. The exposure should be of appropriate granularity  
  to ensure the self-administrative nature of Downstream CDN.  

  The following information in Table 2 is considered for capability 
  exchange.  

   +----------+-----------+-----------------+------------------------+ 
   | Name     |  Type     |   Value         |      Description       | 
   +----------+-----------+-----------------+------------------------+ 
   | IPVersion|ENUM,4 byte|1:IPV4;2:IPV6    |  IP address version    | 
   +----------+-----------+-----------------+------------------------+ 
   | Service- |ENUM,4 byte| 1:in-service;   |  CDNI service status   | 
   | Status   |           |2:out-of-service |                        | 
   +----------+-----------+-----------------+------------------------+ 
   |MaxAcquis-|  UNIT32   | Integer starts  |Concurrent maximal      | 
   |itionBW   |           | from zero.      |availble bandwidth      | 
   |          |           | Unit:Mbps       |for content acquisition | 
   +----------+-----------+-----------------+------------------------+ 
   |UsedAcqui-|           | Integer starts  | Concurrent used        | 
   |sitionBW  |  UNIT32   | from zero.      | bandwidth for content  | 
   |          |           | Unit:Mbps       | acquistion             | 
   +----------+-----------+-----------------+------------------------+ 
   |          |           |  Integer starts |Concurrent maximal      | 
   |MaxDelive-|  UNIT32   |  from zero.     |availble bandwidth      | 
   |ryBW      |           |  Unit:Mbps      |for content delivery    | 
   +----------+-----------+-----------------+------------------------+ 
   |          |           |  Integer starts | Concurrent used        | 
   |UsedDeliv-|  UNIT32   |  from zero.     | bandwidth for          | 
   |eryBW     |           |  Unit:Mbps      | content delivery       | 
   +----------+-----------+-----------------+------------------------+ 
   |Delivery- |  List     |A list of protoc-| Supported delivery     | 
   |Protocol  |           |ols,e.g.HTTP,RTSP| protocols              | 
   +----------+-----------+-----------------+------------------------+ 
   |Coverage  |  List     |Coverage represe-|  CDN coverage          | 
   |          |           |nted by Contry,  |                        | 
   |          |           |State and City   |                        | 
   |          |           |combination      |                        | 
   +----------+-----------+-----------------+------------------------+ 
                Table 2 capability information description 

 
 
He                     Expires April 13, 2012                [Page 16] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   


4.2.2. Message description 

  The HTTP/1.1 protocol is used for capability advertising. 

  The HTTP request is HTTP POST for Report mode and HTTP GET for Query 
  mode respectively. 

  The request URI in both modes conforms to [RFC3986]. The URI format 
  in this document is as follows: HTTP://<host>/<url-path>, where the 
  <host> specifies a destination, and the <url-path>  conveys the 
  message name. 

  The message body representation specified in this document is 
  JavaScript Object Notation(JSON). 

4.2.2.1. Report mode 

  The Downstream CDN issues an HTTP POST message to the Upstream CDN to 
  report its capability information. 

  The message name in the request URI is "CdniCapReport".  

  The Content-Type header field is "application/json". 

  The message body includes capability information. 

  Upon successful receipt of the POST request, the Upstream CDN 
  responds with a 200 OK message. 

4.2.2.2. Query mode 

  The Upstream CDN issues a HTTP GET message to a Downstream CDN to 
  query its capability information. 

  The message name in the request URI is "CdniCapQuery". 
 
 
He                     Expires April 13, 2012                [Page 17] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  Upon successful receipt of the GET request, the Downstream CDN 
  responds a 200 OK message with its capability information. 

  The Content-Type header field for the response is "application/json". 

4.2.3. Message examples 

4.2.3.1. Report mode 

  The POST request and corresponding response are illustrated below. 

  Request example (Downstream CDN to Upstream CDN):  

  POST http://contact-address.ucdn.example/CdniCapReport HTTP/1.1 
  Content-Type: application/json 
  Content-Length: 350 

  { 
       "IPVersion":1, 
       "ServiceStatus":1, 
       "MaxAquisitionBW":10000, 
       "UsedAquisitionBW":2000, 
       "MaxDeliveryBW":20000, 
       "UsedDeliveryBW":5000, 
       "DeliveryProtocol":["HTTP","RSTP"], 
        
       "Coverage": 
       [ 
           { 
                "Country":"China", 
                 "State":[ 
                      { 
                          "Name":"Beijing", 
                          "City":["CityA","CityB"] 
                      }, 
                      { 
                          "Name":"Shanghai", 
                          "City":["CityX"] 
                      } 
                  ] 
           }, 
 
 
He                     Expires April 13, 2012                [Page 18] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

           { 
               "Country":"US", 
                "State":[ 
                   { 
                        "Name":"California", 
                        "City":["CityY"] 
                    } 
               ] 
           } 
      ] 
   } 
   
  Response example:  

  HTTP/1.1 200 OK 

   
4.2.3.2. Query mode 

  The GET request and corresponding response are illustrated below. 

  Request example (Upstream CDN to Downstream CDN):  

  GET http://contact-address.dcdn.example/CdniCapQuery HTTP/1.1 

   

  Response example:  

  HTTP/1.1 200 OK 
  Content-Type: application/json 
  Content-Length: 350 

  The content of message body is the same as that of POST message 
  illustrated in section 5.2.4.1. 

5. Security Considerations 

  In HTTP based Recursive Request Routing, the end user's web 
  browsers will not send cookies if the content request is redirected 
  to a URL in a different domain rather than the original CP's domain, 
  e.g. the Downstream CDN's domain. If the browser is expected to send 
 
 
He                     Expires April 13, 2012                [Page 19] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

  any cookies associated with the original CP's domain, this will cause 
  problem that the CP's policy is not enforced by the CDN. 
   
  The section 5.2 of draft [I-D.draft-peterson-cdni-strawman] has 
  discussed a similar question and given a solution.  
   
6. IANA Considerations 

  If the approach described in this document is adopted, we would 
  request that IANA allocate the message name "CdniCapReport" 
  and "CdniCapQuery" in the HTTP Parameters registry. 
   
7. References 

7.1. Normative References 

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

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 
            Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 
            Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 
   

   [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 
            Resource Identifiers (URI): Generic Syntax and Semantics", 
            RFC 3986, January 2005. 

7.2. Informative References 

  [I-D.draft-cdni-use-cases] 
         "Use Cases for Content Delivery Network Interconnection", 
           Gilles Bertrand, Stephan Emile, Grant Watson, Trevor 
           Burbridge, Philip Eardley, Kevin Ma, 22-Sep-11, <draft-ietf-
           cdni-use-cases-00.txt>. 
   
  [I-D.draft-cdni-problem-statement] 
         "Content Distribution Network Interconnection (CDNI) Problem 
           Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil 
           Bitar, 9-Sep-11, <draft-ietf-cdni-problem-statement-00.txt>. 
 
 
He                     Expires April 13, 2012                [Page 20] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

   
  [I-D.draft-cdni-requirements] 
          "Content Distribution Network Interconnection (CDNI) 
          Requirements", Kent Leung, Yiu Lee, 9-Sep-11, <draft-ietf-
          cdni-requirements-00.txt>. 
      
  [I-D.draft-peterson-cdni-strawman]  
          "A Simple Approach to CDN Interconnection", Larry  
          Peterson, John Hartman, 18-May-11,<draft-peterson- 
          cdni-strawman-01.txt,.pdf>. 
      
  [I-D.davie-cdni-framework] 
           Davie, B. and L. Peterson, "Framework for CDN 
           Interconnection", draft-davie-cdni-framework-00 (work in 
           progress), July 2011. 
   
8. Acknowledgments 

  This document was prepared using 2-Word-v2.0.template.dot. 

























 
 
He                     Expires April 13, 2012                [Page 21] 
   
Internet-Draft      cdni-request-routing-protocol         October 2011 
   

Authors' Addresses 

   
  Xiaoyan He 
  Huawei 
  B2, Huawei Industrial Base, 518129 
  China 
   
  Email: hexiaoyan@huawei.com 
   
   
  Jincheng Li 
  Huawei 
  B2, Huawei Industrial Base, 518129 
  China 
   
  Email: lijincheng@huawei.com 
   
   
  Spencer Dawkins 
  Huawei 
   
  Email: spencer.dawkins@huawei.com 
   
   
  Ge Chen 
  China Telecom 
  109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C 
   
  Email: cheng@gsta.com 















 
 
He                     Expires April 13, 2012                [Page 22]