[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET-DRAFT                                                   TS Choi
Intended Status: Standards Track                                    ETRI
Expires: April 24, 2013                                           YI Seo
                                                                  DJ Kim
                                                                      KT
                                                                  JM Lee
                                                                     SKT
                                                                  JR Koo
                                                                    LGU+
                                                               JDH Shinn
                                                             Solbox Inc.
                                                                 KS Park
                                                                   KAIST
                                                        October 21, 2012

         CDNi Request Routing Redirection with Loop Prevention
          draft-choi-cdni-req-routing-redir-loop-prevention-01


Abstract

   This document describes request routing redirection procedures, loop
   prevention mechanisms, and other operational considerations which are
   associated with redirection.



Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 29, 2012.

Copyright Notice

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



TS Choi et al.           Expires April 24, 2013                 [Page 1]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Redirection Procedures . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Preliminaries  . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Iterative Redirection Procedures . . . . . . . . . . . . .  4
       2.2.1.  HTTP-based Redirection . . . . . . . . . . . . . . . .  4
       2.2.2.  DNS-based Redirection  . . . . . . . . . . . . . . . .  8
     2.3.  Recursive Redirection Procedures . . . . . . . . . . . . . 10
       2.3.1.  HTTP-based Redirection . . . . . . . . . . . . . . . . 10
       2.3.2.  DNS-based Redirection  . . . . . . . . . . . . . . . . 14
   3.  Redirection Loop Prevention  . . . . . . . . . . . . . . . . . 17
   4.  Redirection Operational Considerations . . . . . . . . . . . . 18
   5  Security Considerations . . . . . . . . . . . . . . . . . . . . 19
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1  Normative References  . . . . . . . . . . . . . . . . . . . 19
     7.2  Informative References  . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19


















TS Choi et al.           Expires April 24, 2013                 [Page 2]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


1  Introduction

   According to the CDNi generic and request routing interface
   requirements[I-D.ietf-cdni-requirements], the CDNi solution shall
   support iterative and recursive CDNi request routing, efficient
   request routing for small and large objects, arbitrary number of
   levels of cascaded CDN redirection, looping prevention of any CDN
   request routing redirection, and subsequently allowing the request
   routing redirection.  To meet such requirements, this document
   describes request routing redirection procedures, loop prevention
   mechanisms, and other operational considerations that are associated
   with redirection.

1.1  Terminology

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


2.  Redirection Procedures

2.1.  Preliminaries

   To meet the requirements of request routing redirection, we define
   the term "CDN-Provider-ID".  It uniquely identifies each CDN provider
   during the course of request routing redirection.  It consists of
   "CDN provider name" and "MaxNumRedHops".  A pair of an AS number and
   an additional qualifier is used for CDN provider name.  Since more
   than one CDN providers can belong to the same AS, an additional
   qualifier is used to guarantee the uniqueness.  MaxNumRedHops
   represents a maximum allowed redirections.  The value is decreased
   once every redirection occurs until it reaches 0.  To avoid its usage
   abuse (e.g., end user or CDN operator can set huge number like 100 or
   above), a reasonable upper bound has to be agreed among CDN
   providers.  Security aspect of it is for further study.

   A few examples of the CDN provider names are 100:0 and 200:1.  The
   former means that a CDN provider belong to AS 100 and it is the only
   CDN provider within that AS.  The latter represents the first CDN
   provider in the AS 200.  There are other CDN providers in the same
   AS.

   One example of CDN-Provider-ID is "CDN-Provider-Name=100:0 &
   MaxNumRedHops=10", which means that a CDN provider that belong to AS
   number 100 and it is the only CDN provider and a maximum allowed
   redirection is 10.  An example how a list of CDN-Provider-IDs can be
   carried in the URI query string when a certain cascaded request



TS Choi et al.           Expires April 24, 2013                 [Page 3]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   routing redirection occurs is the following.  We assume that
   redirection is cascaded three times: uCDN -> dCDN1 -> dCDN2.  dCDN1,
   then, carries the following URL, "http://cdn.csp.com?uCDN-Provider-
   ID=100:0&dCDN1-Provider-ID=200:1&MaxNumRedHops=9".  Note that
   MaxNumbRedHops carries the latest number instead of adding in every
   CDN-Provider-ID to save the space in URI query string.

   It is applicable for both HTTP-based and DNS redirections.  For HTTP-
   based redirection, we define a HTTP request routing redirection
   header "CDN-Provider-ID".  For each step of redirection, it is
   attached to the beginning of the provider domain URL.  For example,
   uCDN initiates a redirection with its URL,
   http://100:0:10.cdn.csp.com.  dCDN further attaches its own CDN-
   Provider-ID in the front when another level of redirection is
   required.  For DNS-based redirection, the CDN-Provider-ID can be
   attached in the DNS CNAME.

   Since there is a CDNi requirement to support of arbitrary topology of
   interconnected CDNs, this document assumes that the redirection
   procedures and loop prevention mechanisms must also support arbitrary
   topology.

2.2.  Iterative Redirection Procedures

2.2.1.  HTTP-based Redirection

   In this section, we describe an iterative procedure of HTTP-based
   request routing redirection with loop prevention.


   End-User           dCDNn       dCDNn-1     dCDN1      uCDN
   |DNS cdn.csp.com    |            |            |          |
   |------------------------------------------------------->|
   |                   |            |            |          |(1)
   |IPaddr of uCDN's Request Router |            |          |
   |<-------------------------------------------------------|
   |HTTP cdn.csp.com   |            |            }          |
   |------------------------------------------------------->|
   |                   |            |            |          |(2)
   |302 peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID    |
   |<-------------------------------------------------------|
   |DNS peer-uCDN.dCDN1.net         |            |          |
   |-------------------------------------------->|          |
   |                   |            |            |(3)       |
   |IPaddr of dCDN1's Request Router|            |          |
   |<--------------------------------------------|          |
   |                   |            |            |          |
   |HTTP peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID   |



TS Choi et al.           Expires April 24, 2013                 [Page 4]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   |-------------------------------------------->|          |
   |                   |            |            |(4)       |
   |302 peer-dCDN1.dCDN2.net/cdn.csp.com?dCDN1-Provider-ID  |
   |<--------------------------------------------|          |
   |                   |            |            |          |
   |                   |          .......        |(5)       |
   |                   |            |            |          |
   |302 peer-dCDNn-1.dCDNn.net/cdn.csp.com?dCDNn-1-Provider-ID
   |<-------------------------------|            |          |
   |                   |            |            |          |
   |DNS peer-dCDNn-1.dCDNn.net      |            |          |
   |------------------------------->|            |          |
   |                   |            |(6)         |          |
   |IPaddr of dCDNn's Request Router|            |          |
   |<-------------------------------|            |          |
   |                   |            |            |          |
   |HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com      |          |
   |------------------------------->|            |          |
   |                   |            |(7)         |          |
   |302 node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com |          |
   |<-------------------------------|            |          |
   |                   |            |            |          |
   |DNS node1.peer-dCDNn-1.dCDNn.net|            |          |
   |------------------>|            |            |          |
   |                   |            |(8)         |          |
   |IPaddr of dCDNn's Delivery Node }            |          |
   |<------------------|            |            |          |
   |                   |            |            |          |
   |HTTP node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com|          |
   |------------------>|            |            |          |
   |                   |(9)         |            |          |
   |                   |DNS dCDNn-acq.dCDNn-1.net|          |
   |                   |----------->|            |          |
   |                   |            |(10)        |          |
   |                   |IPaddr of dCDNn-1's Request Router  |
   |                   |<-----------|            |          |
   |                   |HTTP dCDNn-acq.dCDNn-1.net?dCDNn-Provider-ID
   |                   |----------->|            |          |
   |                   |            |(11)        |          |
   |                   |            |   .......  |          |
   |                   |            |            |          |
   |                   |HTTP dCDN1-acq.uCDN.net?dCDN1-Provider-ID
   |                   |            |            |--------->|
   |                   |            |            |          |(12)
   |                   |            |302 node2.dCDN1.acq.uCDN.net
   |                   |            |            |<---------|
   |                   |            |DNS node2.dCDN1-acq.uCDN.net
   |                   |            |            |--------->|



TS Choi et al.           Expires April 24, 2013                 [Page 5]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   |                   |            |            |          |(13)
   |                   |            |IPaddr of uCDN's Delivery Node
   |                   |            |            |<---------|
   |                   |            |            |          |(14)
   |                   |            |            |   Data   |
   |                   |            |            |<---------|
   |                   |            |   .......  |          |
   |Data               |            |            |          |
   |<------------------|            |            |          |

   Figure 1: HTTP-based request routing redirection iterative procedure

   The steps illustrated in the figure are as follows:

   1.   A DNS resolver for uCDN provider processes the DNS request for
        its customer based on CDN-domain cdn.csp.com.  It returns the IP
        address of a request router in uCDN provider.

   2.   A Request Router for uCDN provider processes the HTTP request
        and recognizes that the end-user is best served by dCDN1. So it
        returns a 302 redirect message for a new URL constructed by
        "stacking" dCDN1's distinguished CDN-domain (peer-
        uCDN.dCDN1.net) on the front of the original URL.  It also adds
        uCDN's CDN-Provider-ID in the URI query string of the HTTP
        request message. (e.g., uCDN-Provider-ID=100:0 &
        MaxNumRedHops=10).  This information is not processed by the
        customer but conveyed in the HTTP message without any
        modification of the step 4.  The details on how it is used for
        loop prevention is described in the step 4.

   3.   The end-user does a DNS lookup using dCDN1's distinguished
        CDN-domain (peer-uCDN.dCDN1.net).  dCDN1's DNS resolver returns
        the IP address of a request router for dCDN1.

   4.   The request router for dCDN1 processes the HTTP request.  There
        are two options: redirect further to another dCDN (i.e.,
        cascading the request) or process it by itself.  In either
        cases, it performs loop prevention step first.  It checks a list
        of CDN-provider-IDs in the URI query string: it contains a list
        of CDN providers which requested redirections so far.  If either
        it contains own CDN provider name or MaxNumRedHops becomes 0, it
        means that the redirection loop has occurred or the number of
        redirection hops has reached the maximum.  Once loop is
        detected, details on the next steps is described in the section
        3.  If it is loop free, it either redirects further or processes
        based on the local policy.  For the former, it selects another
        dCDN provider and and sends an HTTP redirect message with its
        own CDN-Provider-ID included in its URI query string (e.g.,



TS Choi et al.           Expires April 24, 2013                 [Page 6]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


        uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 &
        MaxNumRedHops=9) attached.   For the latter, it selects a
        suitable delivery node to serve the end-user request, and
        returns a 302 redirect message for a new URL constructed by
        replacing the hostname by a subdomain of the dCDN1's
        distinguished CDN-domain that points to the selected delivery
        node.  Then it goes to the step 6.

   5.   If further redirection is decided, it repeats steps 2 - 4 until
        it either selects dCDN provider to serve the request or
        MaxNumRedHops expires.  If the former occurs, it resumes the
        step 6.  If the latter occurs, it follows the processes
        described in the section 3.

   6.   Assuming that dCDNn is selected as a serving dCDN provider, the
        end-user does a DNS lookup using dCDNn's distinguished
        CDN-domain (peer-dCDNn-1.dCDNn.net).  dCDNn-1's DNS resolver
        returns the IP address of a request router for dCDNn.

   7.   The request router for dCDN1 processes the HTTP request and
        selects a suitable delivery node to serve the end-user request,
        and returns a 302 redirect message for a new URL constructed by
        replacing the hostname by a subdomain of the dCDNn's
        distinguished CDN-domain that points to the selected delivery
        node.

   8.   The end-user does a DNS lookup using dCDNn's delivery node
        subdomain (node1.peer-dCDNn-1.dCDNn.net).  dCDNn's DNS resolver
        returns the IP address of the delivery node.

   9.   The end-user requests the content from dCDNn's delivery node.
        In the case of a cache hit, steps 10 ~ 14 below do not happen,
        and the content data is directly returned by the delivery node
        to the end-user.  In the case of a cache miss, the content needs
        to be acquired by dCDN from either parent dCDN or uCDN (not the
        CSP). The distinguished CDN-domain peer-dCDNn-1.dCDNn.net
        indicates that this content is to be acquired from dCDNn-1;
        stripping the CDN-domain reveals the original CDN-domain
        cdn.csp.com and dCDNn may verify that this CDN-domain belongs to
        a known peer (so as to avoid being tricked into serving as an
        open proxy).  It then does a DNS request for an inter-CDN
        acquisition CDN-domain as agreed above (in this case, dCDNn-
        acq.dCDNn-1.net).  This process repeats recursively until it
        finds a CDN provider that can serve the requested content.

   10.   dCDNn-1's DNS resolver processes the DNS request and returns
        the IP address of a request router in dCDNn-1.




TS Choi et al.           Expires April 24, 2013                 [Page 7]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   11.   The request router for dCDNn-1 processes the HTTP request from
        dCDNn's delivery node.  dCDNn-1 request router recognizes that
        the request is from a peer CDN rather than an end-user because
        of the dedicated inter-CDN acquisition domain
        (dCDNn-acq.dCDNn-1.net).  It also performs loop prevention
        process as described in step 4 based on the provided CDN-
        Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider-
        ID=200:1 & ... & dCDNn-Provider-ID=1000:0 & MaxNumRedHops=1).
        Depending on the number of levels of redirection and
        availability of contents, the same process repeats until either
        content serving CDN provider is found or MaxNumRedHps expires.

   12.  Assuming that all intermediate dCDNs also have a cache miss,
        The request router for uCDN selects a suitable delivery node to
        serve the inter-CDN acquisition request and returns a 302
        redirect message for a new URL constructed by replacing the
        hostname by a subdomain of the uCDN's distinguished inter-CDN
        acquisition domain that points to the selected delivery node.

   13.   uCDN DNS resolver processes the DNS request and returns the IP
        address of the delivery node in uCDN.

   14.  uCDN serves content for the requested CDN-domain to dCDN and
        finally to end-user. Although not shown, it is at this point
        that uCDN processes the rest of the URL: it extracts information
        identifying the origin server, validates that this server has
        been registered, and determines the content provider that owns
        the origin server.  It may also perform its own content
        acquisition steps if needed before returning the content to
        dCDN.

2.2.2.  DNS-based Redirection

   In this section, we describe an iterative procedure of DNS-based
   request routing redirection with loop prevention.
















TS Choi et al.           Expires April 24, 2013                 [Page 8]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   End-User           dCDNn       dCDNn-1     dCDN1      uCDN
   |DNS cdn.csp.com    |            |            |          |
   |------------------------------------------------------->|
   |                   |            |            |          |
   |CNAME uCDNProviderID.dCDN1.cdn.csp.com       |          |(1)
   |NS records for dCDN1.cdn.csp.com|            |          |
   |<-------------------------------------------------------|
   |DNS dCDN1.cdn.csp.com           |            |          |
   |-------------------------------------------->|          |
   |                   |            |            |          |
   |                   |          .......        |(2)       |
   |                   |            |            |          |
   |CNAME dCDN1.cdn.csp.com         |            |          |
   |NS records for dCDN1.cdn.csp.com|            |          |
   |<-------------------------------|            |          |
   |DNS dCDNn.cdn.csp.com           |            |          |
   |------------------>|            |            |          |
   |                   |            |(3)         |          |
   |IPaddr of dCDNn's Delivery Node }            |          |
   |<------------------|            |            |          |
   |                   |            |            |          |
   |HTTP cdn.csp.com   |            |            |          |
   |------------------>|            |            |          |
   |                   |(4)         |            |          |
   |                   |DNS dCDNn-acq.dCDNn-1.net|          |
   |                   |----------->|            |          |
   |                   |            |            |          |
   |                   |            |   .......  |(5)       |
   |                   |            |            |          |
   |                   |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net
   |                   |            |            |--------->|
   |                   |            |            |          |(6)
   |                   |            |IPaddr of uCDN's Delivery Node
   |                   |            |            |<---------|
   |                   |            |            |          |(7)
   |                   |            |            |   Data   |
   |                   |            |            |<---------|
   |                   |            |   .......  |          |
   |Data               |            |            |          |
   |<------------------|            |            |          |

   Figure 2: DNS-based request routing redirection iterative procedure


   The steps illustrated in the figure are as follows:

   1.  Request Router for uCDN provider processes the DNS request for
       CDN- domain cdn.csp.com and recognizes that the end-user is best



TS Choi et al.           Expires April 24, 2013                 [Page 9]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


       served by another CDN.  (This may depend on the IP address of the
       user's local DNS resolver, or other information discussed below.)
       The Request Router returns a DNS CNAME response by "stacking" the
       distinguished identifier for dCDN1 and uCDN's CDN-Provider-ID
       (e.g., 100:0.10) onto the original CDN-domain (e.g.,
       dCDN1.cdn.csp.com), plus an NS record that maps dCDN1.cdn.csp.com
       to dCDN1's Request Router.

   2.  The end-user does a DNS lookup using the modified CDN-domain
       (i.e., dCDN1.cdn.csp.com).  dCDN1 Request Router processes the
       request and decides to serve the request or redirect further to
       another CDN provider.  It also checks redirection loop.  This
       process iterates until either serving dCDN is selected or
       MaxNumRedHops expires.  In this case, dCDNn is selected as a
       serving dCDN.  If the former occurs, it proceeds to step 3.  If
       the latter occurs, it follows the processes described in the
       section 3.

   3.  The end-user does a DNS lookup using the modified CDN-domain
       (i.e., dCDN1.cdn.csp.com).  This causes dCDNn's request router
       returns an IP address of a suitable delivery node.

   4.   The end-user requests the content from dCDNn's delivery node.
       In the case of a cache hit, steps 5 ~ 7 do not happen, and the
       content data is directly returned by the delivery node to the
       end-user.  In the case of a cache miss, the content needs to be
       acquired by dCDNn from either parent dCDN or uCDN (not the CSP).
       It also performs loop prevention process as described in the step
       2 based on the provided CDN-Provider-ID (e.g.,
       100:0.200:1.....900:0.1)

   5. Depending on the number of levels of redirection and availability
       of contents, the same process repeats until either content
       serving CDN provider is found or MaxNumRedHps expires.

   6.  Assuming that all intermediate dCDNs also miss cache, uCDN is
       selected as a content delivery CDN provider.  Thus, the request
       router for uCDN selects a suitable delivery node to serve the
       inter-CDN acquisition request and returns IP address of the
       suitable uCDN delivery node.

   7.  uCDN serves content to dCDN1 and further down to end-user.
       Although not shown, it is at this point that uCDN processes the
       rest of the URL: it extracts information identifying the origin
       server, validates that this server has been registered, and
       determines the content provider that owns the origin server.

2.3.  Recursive Redirection Procedures



TS Choi et al.           Expires April 24, 2013                [Page 10]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


2.3.1.  HTTP-based Redirection

   In this section, we describe an recursive procedure of HTTP-based
   request routing redirection with loop prevention.

   End-User           dCDNn       dCDNn-1     dCDN1      uCDN
   |DNS cdn.csp.com    |            |            |          |
   |------------------------------------------------------->|
   |                   |            |            |          |(1)
   |IPaddr of uCDN's Request Router |            |          |
   |<-------------------------------------------------------|
   |HTTP cdn.csp.com   |            |            }          |
   |------------------------------------------------------->|
   |                   |            |            |          |
   |                                    RRI REQ cdn.csp.com |
   |                   |            |            |<---------|
   |                   |          .......        |          |
   |                   |<-----------|            |          |
   |                    RRI RESP node1.dCDNn.net |(2)       |
   |                   |----------->|            |          |
   |                   |          .......        |          |
   |                               RRI RESP node1.dCDNn.net |
   |                   |            |            |--------->|
   |                   |            |            |          |
   |302 node1.dCDNn.net/cdn.csp.com |            |          |
   |<-------------------------------------------------------|(3)
   |                   |            |            |          |
   |DNS node1.dCDNn.net|            |            |          |
   |------------------>|            |            |          |
   |                   |(4)         |          |          |
   |IPaddr of dCDNn's Delivery Node }            |          |
   |<------------------|            |            |          |
   |                   |            |            |          |
   |HTTP node1.dCDNn.net/cdn.csp.com|            |          |
   |------------------>|            |            |          |
   |                   |(5)         |            |          |
   |                   |DNS dCDNn-acq.dCDNn-1.net|          |
   |                   |----------->|            |          |
   |                   |            |(6)         |          |
   |                   |IPaddr of dCDNn-1's Request Router  |
   |                   |<-----------|            |          |
   |                   |HTTP dCDNn-acq.dCDNn-1.net?dCDNn ProviderID
   |                   |----------->|            |          |
   |                   |            |            |          |
   |                   |            |   .......  |(7)       |
   |                   |            |            |          |
   |                   |HTTP dCDN1-acq.uCDN.net?dCDN1 ProviderID
   |                   |            |            |--------->|



TS Choi et al.           Expires April 24, 2013                [Page 11]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   |                   |            |            |          |(8)
   |                   |            |302 node2.dCDN1.acq.uCDN.net
   |                   |            |            |<---------|
   |                   |            |DNS node2.op-b-acq.op-a.net
   |                   |            |            |--------->|
   |                   |            |            |          |(9)
   |                   |            |IPaddr of uCDN's Delivery Node
   |                   |            |            |<---------|
   |                   |            |            |          |(10)
   |                   |            |            |   Data   |
   |                   |            |            |<---------|
   |                   |            |   .......  |          |
   |Data               |            |            |          |
   |<------------------|            |            |          |


   Figure 3: HTTP-based request routing redirection recursive procedure


   The steps illustrated in the figure are as follows:

   1.   A DNS resolver for uCDN provider processes the DNS request for
        its customer based on CDN-domain cdn.csp.com.  It returns the IP
        address of a request router in uCDN provider.

   2.   A Request Router for uCDN provider processes the HTTP request
        and recognizes that the end-user is best served by dCDN1. So it
        queries the CDNI Request Routing interface of dCDN1 providing a
        set of information about the request including the URL
        requested.  It also provides uCDN's CDN-Provider-ID (e.g., uCDN-
        Provider-ID=100:0 & MaxNumRedHops=10) for loop prevention
        process.  It contains a list of CDN providers that have
        requested redirections so far.  If either it contains its own
        CDN provider name or MaxNumRedHops becomes 0, it means that the
        redirection loop has occurred or it has reached the maximum
        number of allowed number of redirection hops.  Once loop is
        detected, details on the next steps are described in the section
        3.  If it is loop free, dCDN1 then either replies with the DNS
        name of a delivery node or redirect to another dCDN.  Such
        cascading redirection can continue until a serving dCDN is
        decided.  The RRI RESP can be sent in the reverse order of
        cascaded redirection or directly to the redirection origin CDN
        provider if contact information is known.  The contact
        information can be embedded in the RRI REQ message or pre-
        configured during bootstrapping process. The default behavior is
        recursive RESP.

   3. uCDN returns a 302 redirect message for a new URL obtained from



TS Choi et al.           Expires April 24, 2013                [Page 12]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


        the Request Routing Interface.

   4.   The end-user does a DNS lookup using the host name of the URL
        just provided (node1.dCDNn.net).  dCDNn's DNS resolver returns
        the IP address of the corresponding delivery node.  Note that,
        since the name of the delivery node was already obtained from
        dCDNn using the CDNI Request Routing Interface, there should not
        be any further redirection here (in contrast to the iterative
        method described above.)


   4.   The request router for dCDN1 processes the HTTP request.  There
        are two options: redirect further to another dCDN (i.e.,
        cascading the request) or process it by itself.  In either
        cases, it performs loop prevention step first.    If it is loop
        free, it either redirect further or processes based on the local
        policy.  For the former, it selects another dCDN provider and
        and sends HTTP redirect message with it own CDN-Provider-ID
        (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider-ID=200:1 &
        MaxNumRedHops=9) attached.   For the latter, it selects a
        suitable delivery node to serve the end-user request, and
        returns a 302 redirect message for a new URL constructed by
        replacing the hostname by a subdomain of the dCDN1's
        distinguished CDN-domain that points to the selected delivery
        node.  Then it goes to step 6.

   5.   The end-user requests the content from dCDNn's delivery node.
        In the case of a cache hit, steps 6 ~ 10 below do not happen,
        and the content data is directly returned by the delivery node
        to the end-user.  In the case of a cache miss, the content needs
        to be acquired by dCDN from either parent dCDN or uCDN (not the
        CSP). The distinguished CDN-domain dCDNn.net indicates that this
        content is to be acquired from dCDNn-1; stripping the CDN-domain
        reveals the original CDN-domain cdn.csp.com and dCDNn may verify
        that this CDN-domain belongs to a known peer (so as to avoid
        being tricked into serving as an open proxy).  It then does a
        DNS request for an inter-CDN acquisition CDN-domain as agreed
        above (in this case, dCDNn-acq.dCDNn-1.net).  This process
        repeats recursively until it finds CDN provider that can serve
        the requested content.

   6.   dCDNn-1's DNS resolver processes the DNS request and returns the
        IP address of a request router in dCDNn-1.

   7.   The request router for dCDNn-1 processes the HTTP request from
        dCDNn's delivery node.  dCDNn-1 request router recognizes that
        the request is from a peer CDN rather than an end-user because
        of the dedicated inter-CDN acquisition domain



TS Choi et al.           Expires April 24, 2013                [Page 13]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


        (dCDNn-acq.dCDNn-1.net).  It also performs loop prevention
        process as described in the step 2 based on the provided CDN-
        Provider-ID (e.g., uCDN-Provider-ID=100:0 & dCDN1-Provider-
        ID=200:1 & ... & dCDNn-1-Provider-ID=900:0 & MaxNumRedHops=1).
        Depending on the number of levels of redirection and
        availability of contents, the same process repeats until either
        content serving CDN provider is found or MaxNumRedHps expires.

   8.  Assuming that all intermediate dCDNs also have a cache miss,  The
        request router for uCDN selects a suitable delivery node to
        serve the inter-CDN acquisition request and returns a 302
        redirect message for a new URL constructed by replacing the
        hostname by a subdomain of the uCDN's distinguished inter-CDN
        acquisition domain that points to the selected delivery node.

   9.   uCDN DNS resolver processes the DNS request and returns the IP
        address of the delivery node in uCDN.

   10.  uCDN serves content for the requested CDN-domain to dCDN and
        finally to end-user. Although not shown, it is at this point
        that uCDN processes the rest of the URL: it extracts information
        identifying the origin server, validates that this server has
        been registered, and determines the content provider that owns
        the origin server.  It may also perform its own content
        acquisition steps if needed before returning the content to
        dCDN.


2.3.2.  DNS-based Redirection

   In this section, we describe an recursive procedure of DNS-based
   request routing redirection with loop prevention.



















TS Choi et al.           Expires April 24, 2013                [Page 14]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   End-User           dCDNn       dCDNn-1     dCDN1      uCDN
   |DNS cdn.csp.com    |            |            |          |
   |------------------------------------------------------->|
   |                   |            |            |          |(1)
   |                                    RRI REQ cdn.csp.com |
   |                   |            |            |<---------|
   |                   |          .......        |          |
   |                   |<-----------|            |          |
   |                    RRI RESP node1.dCDNn.net |          |
   |                   |----------->|            |          |
   |                   |          .......        |          |
   |                               RRI RESP node1.dCDNn.net |
   |                   |            |            |--------->|
   |                   |            |            |          |
   |CNAME dCDNn.cdn.csp.com         |            |          |
   |NS records for dCDNn.cdn.csp.com|            |          |(2)
   |<-------------------------------------------------------|
   |                   |            |            |          |
   |DNS dCDNn.cdn.csp.com           |            |          |
   |------------------>|            |            |          |
   |                   |(3)         |            |          |
   |IPaddr of dCDNn's Delivery Node }            |          |
   |<------------------|            |            |          |
   |                   |            |            |          |
   |HTTP cdn.csp.com   |            |            |          |
   |------------------>|            |            |          |
   |                   |(4)         |            |          |
   |                   |DNS dCDNn-acq.dCDNn-1.net|          |
   |                   |----------->|            |          |
   |                   |            |            |          |
   |                   |            |   .......  |(5)       |
   |                   |            |            |          |
   |                   |DNS dCDN1 ProviderID.dCDN1-acq.uCDN.net
   |                   |            |            |--------->|
   |                   |            |            |          |(6)
   |                   |            |IPaddr of uCDN's Delivery Node
   |                   |            |            |<---------|
   |                   |            |            |          |(7)
   |                   |            |            |   Data   |
   |                   |            |            |<---------|
   |                   |            |   .......  |          |
   |Data               |            |            |          |
   |<------------------|            |            |          |

   Figure 4: DNS-based request routing redirection recursive procedure


   The steps illustrated in the figure are as follows:



TS Choi et al.           Expires April 24, 2013                [Page 15]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   1.  Request Router for uCDN provider processes the DNS request for
       CDN-domain cdn.csp.com and recognizes that the end-user is best
       served by dCDN1.  So it queries the CDNI Request Routing
       Interface of dCDN1 providing a set of information about the
       request including the URL requested.  It also provides uCDN's
       CDN-Provider-ID (e.g., uCDN-Provider-ID=100:0 & MaxNumRedHops=10)
       for loop prevention process.  It checks CDN-Provider-ID.  If
       either it contains own CDN provider name or MaxNumRedHops becomes
       0, it means that the redirection loop is occurred.  Once loop is
       detected, details on the next steps are described in the section
       3.  If it is loop-free, dCDN1 then either replies with the DNS
       name of a delivery node or redirect to another dCDN.  Such
       cascaded redirection can continue until a serving dCDN is
       decided.  The RRI RESP can be sent in the reverse order of
       cascaded redirection or directly to the redirection origin CDN
       provider if contact information is known.  The contact
       information can be embedded in the RRI REQ message or pre-
       configured during bootstrapping process.  The default behavior is
       recursive RESP In this case, dCDNn is selected as a serving dCDN.

   2. The Request Router returns a DNS CNAME response by "stacking" the
       distinguished identifier for dCDNn and uCDN's CDN-Provider-ID
       onto the original CDN-domain (e.g., dCDN1.cdn.csp.com), plus an
       NS record that maps dCDN1.cdn.csp.com to dCDN1's Request Router.

   3.  The end-user does a DNS lookup using the modified CDN-domain
       (i.e., dCDN1.cdn.csp.com).  This causes dCDNn's request router
       returns an IP address of a suitable delivery node.

   4.   The end-user requests the content from dCDNn's delivery node.
       In the case of a cache hit, steps 5 ~ 7 do not happen, and the
       content data is directly returned by the delivery node to the
       end-user.  In the case of a cache miss, the content needs to be
       acquired by dCDNn from either parent dCDN or uCDN (not the CSP).
       It also performs loop prevention process as described in the step
       2 based on the provided CDN-Provider-ID (e.g., uCDN-Provider-
       ID=100:0 & dCDN1-Provider-ID=200:1 & ... & dCDNn-1-Provider-
       ID=900:1 & MaxNumRedHops=1).

   5. Depending on the number of levels of redirection and availability
       of contents, the same process repeats until either content
       serving CDN provider is found or MaxNumRedHps expires.

   6.  Assuming that all intermediate dCDNs also miss cache, uCDN is
       selected as a content delivery CDN provider.  Thus, the request
       router for uCDN selects a suitable delivery node to serve the
       inter-CDN acquisition request and returns IP address of the
       suitable uCDN delivery node.



TS Choi et al.           Expires April 24, 2013                [Page 16]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   7.  uCDN serves content to dCDN1 and further down to end-user.
       Although not shown, it is at this point that uCDN processes the
       rest of the URL: it extracts information identifying the origin
       server, validates that this server has been registered, and
       determines the content provider that owns the origin server.

3.  Redirection Loop Prevention

   According to the CDNi generic and request routing interface
   requirements, the CDNi solution shall support loop prevention of any
   CDN request routing redirection and subsequently allowing the request
   routing redirection.  To meet such requirements, this section
   describes request routing redirection loop prevention mechanisms.
   Loop prevention mechanism should support both detection of the loop
   and post processing after loop detection.  Also loop prevention
   should be applicable for the process of redirection CDN provider
   selection and inter CDN content acquisition.

   This document specifies loop prevention mechanisms based on CDN-
   Provider-ID.  Framework document [I-D.ietf-cdni-framework] recommends
   using distinguished acquisition domain for loop detection.  It has
   some drawbacks such as overheads caused by length and processing time
   of domain name stacking in the case of cascading redirection  This
   document defines more general solution which can be applicable in
   both HTTP-based and DNS-based redirections.  CDN-Provider-ID which is
   described in details in the section 2.1 is our proposed solution.
   Unlike distinguished domain name which is proposed in the framework,
   it is simple, unique, and efficient.

   Post-processing after loop detection is also as important as its
   detection.  The most strict option is to deny the service when the
   loop is detected.  This option should the last resort when other
   alternatives are not available.  The simplest choice is the CDN
   provider which detected the loop provide the service by itself
   although the service quality may not be optimal.  If it is not
   possible, it requests its parent.  If the parent can provide the
   service, it does so.  If not, it further checks with other dCDN
   providers at the peer level or downstream until it finds available
   one.  If it all fails its attempts at the its parent, peer, and
   children, it checks with uCDN. If note is available, it finally
   rejects the service.

4.  Redirection Operational Considerations

   For efficient request routing redirection, various operational
   considerations need to be addressed.  In the framework document, for
   the redirection selection criteria, CDNi uses end-user's IP address
   prefix.  However, in real CDN service environments, there are various



TS Choi et al.           Expires April 24, 2013                [Page 17]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   other reasons such as service availability, QoS requirements,
   resource faults, etc.  Both Routing Request Interface and redirection
   request should allow exchange of such information.  The type and
   details of information that can be exchanged among CDN providers for
   the efficient redirection has to be considered together with
   footprint/capability advertisement.  The details are for further
   study.

   Performance feasibility of request routing redirection and loop
   prevention should be addressed.  The requirements may vary depending
   on the CDN service types (e.g., CDN for small and/or large object).
   Also granularity of redirection within or between contents should be
   considered.  It is for further study, too.






































TS Choi et al.           Expires April 24, 2013                [Page 18]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


5  Security Considerations


6  IANA Considerations


7  References

7.1  Normative References


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

   [I-D.davie-cdni-framework] Peterson, L. and B. Davie, "Framework for
              CDN Interconnection", April 2012.

   [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content
              Distribution Network Interconnection (CDNI) Requirements",
              December 2011.

7.2  Informative References


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

   [I-D.ietf-cdni-use-cases] Bertrand, G., Stephan, E., Burbridge, T.,
              Eardley, P., Ma, K., and G. Watson, "Use Cases for Content
              Delivery Network Interconnection", June 2012.



Authors' Addresses


   Taesang Choi
   ETRI
   161 Gajong-Dong
   Yusong-Gu, Daejeon
   Republic of Korea

   Phone: +82-42-860-5628
   Email: choits@etri.re.kr

   Young-IL Seo
   KT Network R&D Laboratory



TS Choi et al.           Expires April 24, 2013                [Page 19]


INTERNET DRAFT  Req. Routing Redirection Loop PreventionOctober 21, 2012


   463-1, Jeonmoin-dong,
   Yuseong-gu, Daejeon
   Republic of Korea

   Phone: 82-10-3235-0135
   Email: yohan.seo@kt.com

   Dong-Ju Kim
   KT Network R&D Laboratory
   463-1, Jeonmoin-dong,
   Yuseong-gu, Daejeon
   Republic of Korea

   Phone: 82-10-2686-9605
   Email: dj.kim@kt.com

   Jongmin Lee
   SK Telecom
   11, Euljiro-2ga
   Jung-gu, Seoul
   Republic of Korea

   Phone: 82-10-9429-6260
   Email: jminlee@sk.com

   Ja-Ryeong Koo
   LG U plus Corporation
   Namdaemunro 5-ga
   Jung-gu, Seoul
   Republic of Korea

   Phone: 82-10-8080-6115
   Email: wjbkoo@lguplus.co.kr

   John Dongho Shinn
   Solbox Inc.
   7F, Haesung Bldg. 747-2 Yeoksam-Dong
   Kangnam-Gu, Seoul
   Republic of Korea

   Phone: +82-10-3005-4785
   Email: eastsky@solbox.com









TS Choi et al.           Expires April 24, 2013                [Page 20]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/