CDNi Request Routing Redirection with Loop Prevention
draft-choi-cdni-req-routing-redir-loop-prevention-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | KT Network R&D Laboratory | ||
| Last updated | 2012-07-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-choi-cdni-req-routing-redir-loop-prevention-00
INTERNET-DRAFT TS Choi
Intended Status: Standards Track ETRI
Expires: January 5, 2013 YI Seo
DJ Kim
KT
JM Lee
SKT
JR Koo
LGU+
JDH Shinn
Solbox Inc.
KS Park
KAIST
July 4, 2012
CDNi Request Routing Redirection with Loop Prevention
draft-choi-cdni-req-routing-redir-loop-prevention-00
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 January 5, 2013 [Page 1]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 January 5, 2013 [Page 2]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 list" and "MaxNumRedHops". The CDN provider list is a
set of uniquely identifiable CDN provider names. A pair of an AS
number and an additional qualifier is used for CDN provider name.
MaxNumRedHops represents a maximum allowed redirections. The value
is decreased once every redirection occurs until it reaches 0. To
avoid its usage abuse (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.
Since more than one CDN providers can belong to the same AS, an
additional qualifier is used to guarantee the uniqueness. A few
examples of CDN provider name 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 100:0: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.
It is applicable for both HTTP-based and DNS redirections. For HTTP-
TS Choi et al. Expires January 5, 2013 [Page 3]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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 the CDNi requirements for the support of arbitrary topology of
interconnected CDNs, this document assumes that the redirection
procedures and loop prevention mechanisms 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 |
|-------------------------------------------->| |
| | | |(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
|<-------------------------------| | |
TS Choi et al. Expires January 5, 2013 [Page 4]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
| | | | |
|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
| | | |--------->|
| | | | |(13)
| | |IPaddr of uCDN's Delivery Node
| | | |<---------|
| | | | |(14)
| | | | Data |
| | | |<---------|
| | | ....... | |
|Data | | | |
|<------------------| | | |
TS Choi et al. Expires January 5, 2013 [Page 5]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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 HTTP request message. It consists
of ASNum:Qualifier:MaxNumRedHos. 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 CDN-
provider-ID: the provider list 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 it own CDN-Provider-ID
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.
TS Choi et al. Expires January 5, 2013 [Page 6]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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.
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. 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
TS Choi et al. Expires January 5, 2013 [Page 7]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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 January 5, 2013 [Page 8]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 January 5, 2013 [Page 9]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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
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.
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
2.3.1. HTTP-based Redirection
TS Choi et al. Expires January 5, 2013 [Page 10]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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
| | | |--------->|
| | | | |(8)
| | |302 node2.dCDN1.acq.uCDN.net
TS Choi et al. Expires January 5, 2013 [Page 11]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
| | | |<---------|
| | |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 for loop
prevention process. It consists of
ASNum:Qualifier:MaxNumRedHos. It checks CDN-Provider-ID: the
provider list 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
the Request Routing Interface.
TS Choi et al. Expires January 5, 2013 [Page 12]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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
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
(dCDNn-acq.dCDNn-1.net). It also performs loop prevention
process as described in the step 2 based on the provided CDN-
Provider-ID. Depending on the number of levels of redirection
and availability of contents, the same process repeats until
TS Choi et al. Expires January 5, 2013 [Page 13]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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 January 5, 2013 [Page 14]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 January 5, 2013 [Page 15]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 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.
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
TS Choi et al. Expires January 5, 2013 [Page 16]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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 redirection. 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. For simplicity of the description, we provide a pseudo
code of the post loop detection processing as below.
if (uCDN.ProviderList contains my.ProviderName or MaxNumRedHops <= 0)
{ //loop detected
if (my.Avail == true) {
request.DoService(my);
} elseif(parent.Avail == true) {
request.Redirect(parent);
} elseif(uCDN.Avail == true) {
request.Redirect(uCDN);
} else {
request.deny(); } }
If a loop is detected and myself can serve the request, the request
is processed in my CDN. For some reason, if myself cannot process
the request, it first checks availability of its parent and then
uCDN. If none of them succeed, then request is denied.
TS Choi et al. Expires January 5, 2013 [Page 17]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 2012
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
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 January 5, 2013 [Page 18]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 January 5, 2013 [Page 19]
INTERNET DRAFT Req. Routing Redirection Loop Prevention July 4, 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 January 5, 2013 [Page 20]