Request Interface for CDN Interconnection
draft-choi-cdni-req-intf-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".
|
|
|---|---|---|---|
| Authors | Taesang Choi , Yeong-il Seo , KT Network R&D Laboratory, Jongmin Lee , Ja-Ryeong Koo , John Dongho Shinn , June-koo Rhee | ||
| Last updated | 2013-07-13 | ||
| 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-intf-00
Networking Working Group T. Choi
Internet-Draft ETRI
Intended Status: Standards Track Y. Seo
Expires: January 14, 2014 D. Kim
KT
J. Lee
SKT
J. Koo
LGU+
J. Shinn
Solbox Inc.
J. Rhee
KAIST
July 13, 2013
Request Interface for CDN Interconnection
draft-choi-cdni-req-intf-00
Abstract
This document specifies the request interface between a CDN end-user
and an upstream CDN or downstream CDN to request CDN request routing
redirection or URI signing. It specifies the CDNI Request Interface
information elements and the actual protocol for exchanging them.
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) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
TS Choi et al. Expires January 14, 2014 [Page 1]
INTERNET DRAFT Request Interface July 13, 2013
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. Request Interface Function Overview . . . . . . . . . . . . . . 3
3. Request Interface Information Elements . . . . . . . . . . . . 4
4. Request Procedures . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Iterative Request Routing Redirection with Loop
Prevention Procedures . . . . . . . . . . . . . . . . . . 6
4.1.1. HTTP-based Redirection . . . . . . . . . . . . . . . . 6
4.1.2. DNS-based Redirection . . . . . . . . . . . . . . . . 10
4.2. HTTP-based Redirection with Multiple Location Return . . . 12
4.3. URI Signing . . . . . . . . . . . . . . . . . . . . . . . 16
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
TS Choi et al. Expires January 14, 2014 [Page 2]
INTERNET DRAFT Request Interface July 13, 2013
1. Introduction
According to the CDNi requirements[I-D.ietf-cdni-requirements] and
the CDNI Framework [I-D.ietf-cdni-framework], the need for
interconnected CDNs to be able to support iterative and recursive
CDNi request routing and implement an access control mechanism that
enforces the CSP's distribution policy is described. Recursive CDNi
request routing is specified by request routing redirection interface
[I-D.ietf-cdni-redirection]. URI signing is specified in URI signing
[I-D.leung-cdni-uri-signing].
For generic CDN services, the high availability is a major issue as
most contents providers want more than 99% availability for their
services. Response time is also a major issue as it might be the main
reason why contents providers use CDN services. For CDNi services,
both high availability and response time are required for the same
reason. However, due to the limitation of redirection feature on
HTTP/1.1 which allows only a single location for redirection,
unnecessary connection cost and point of failures are expected during
request routing redirection and content acquisition processes. A new
mechanism to cope with such a limitation is required to support
availability for CDNI services.
Meanwhile, both iterative request routing redirection and URI signing
require interactions between an end-user and uCDN or dCDN. This
implies the need for an interface to support such interactions.
To meet the needs, this document specifies an interface called
"Request Interface" which resides between end-users and CDN
providers. It describes information elements and transport protocols
for the interface.
[Editor's Note: Request Interface is out of scope in the current
charter. There are some contradictions between the requirements and
scope. According to the requirements, both iterative request routing
redirection and secure access control need to be supported. Both
operations cannot be realized without support of request interface.
Thus, scope discussion is necessary in the WG.]
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. Request Interface Function Overview
Request interface operates between a user agent and CDN provider
TS Choi et al. Expires January 14, 2014 [Page 3]
INTERNET DRAFT Request Interface July 13, 2013
(either uCDN or dCDN). Since one end of this interface is user
application such as web browser, it is desirable not to invent a new
protocol for this function. Instead, it uses well-known protocols
used by the existing CDN applications such as HTTP and DNS.
The main function of this interface is to support the iterative
request routing redirection and the URI signing mechanism. For the
iterative request routing redirection, it also supports loop
prevention mechanism.
For the high availability of the CDN service, it also supports
multiple CDN connection choices by returning multiple CDN locations
to a user agent. When the first CDN location fails to serve the
request due to some reason (e.g., the request routing system of that
CDN fails for some reason), the second CDN location can be tried by a
user agent until it succeeds. Detailed semantics on how uCDN selects
multiple locations, the number of locations, and selection priority,
etc. need further work.
3. Request Interface Information Elements
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
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-
TS Choi et al. Expires January 14, 2014 [Page 4]
INTERNET DRAFT Request Interface July 13, 2013
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.
For URI singing, detailed format of information elements carried over
this interface is defined in [I-D.ietf-leung-cdni-uri-signing-02]
For multiple CDN locations support, we define an extension tag
called, "M-Location". As there are still many clients that support
HTTP/1.1 with single location return, it will take some time for them
to upgrade to support the multi location return capability. This will
also guarantee the backward compatibility.
The following is an example of using location tag with HTTP/1.1 or
older versions.
HTTP/1.1 302
Location: http://www.example.com/sample.zip
For backward compatibility, we keep the original location tag and add
an extension tag. The example is as following.
HTTP/2.0 302
Location: http://www.example.com/sample.zip
M-Location: http://www.example.com/sample.zip
http://www2.example.com/sample.zip
http://www3.example.com/sample.zip
M-Redirection-Count: 0
In this way, legacy clients can parse the location tag as usual, and
new clients which support the multiple location tag can parse
multiple locations return.
4. Request Procedures
This section specifies two request procedures: iterative request
routing redirection and URI singing. More specifically, the former
consists of iterative request routing redirection with loop
TS Choi et al. Expires January 14, 2014 [Page 5]
INTERNET DRAFT Request Interface July 13, 2013
prevention and iterative request routing redirection with multiple
location return.
4.1. Iterative Request Routing Redirection with Loop Prevention
Procedures
4.1.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
|<-------------------------------| | |
| | | | |
|DNS peer-dCDNn-1.dCDNn.net | | |
|------------------------------->| | |
| | |(6) | |
|IPaddr of dCDNn's Request Router| | |
|<-------------------------------| | |
| | | | |
|HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com | |
|------------------------------->| | |
TS Choi et al. Expires January 14, 2014 [Page 6]
INTERNET DRAFT Request Interface July 13, 2013
| | |(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 | | | |
|<------------------| | | |
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.
TS Choi et al. Expires January 14, 2014 [Page 7]
INTERNET DRAFT Request Interface July 13, 2013
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.,
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.
TS Choi et al. Expires January 14, 2014 [Page 8]
INTERNET DRAFT Request Interface July 13, 2013
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 (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.
TS Choi et al. Expires January 14, 2014 [Page 9]
INTERNET DRAFT Request Interface July 13, 2013
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.
4.1.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 14, 2014 [Page 10]
INTERNET DRAFT Request Interface July 13, 2013
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 14, 2014 [Page 11]
INTERNET DRAFT Request Interface July 13, 2013
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.
4.2. HTTP-based Redirection with Multiple Location Return
TS Choi et al. Expires January 14, 2014 [Page 12]
INTERNET DRAFT Request Interface July 13, 2013
The following figure describes the situation that if HTTP supports
the return of multiple locations.
TS Choi et al. Expires January 14, 2014 [Page 13]
INTERNET DRAFT Request Interface July 13, 2013
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, |
| peer-uCDN.dCDN2.net/cdn.csp.com?uCDN-Provider-ID, |
| peer-uCDN.dCDNN.net/cdn.csp.com?uCDN-Provider-ID, |
| peer-uCDN.uCDN.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 |
|-------------------------------------------->| |
| Connection fail | | |(4) |
|<--------------------------------------------| |
|DNS peer-uCDN.dCDN2.net | | |
|------------------------------->| | |
| | | |(3) |
|IPaddr of dCDN1's Request Router| | |
|<--------------------------------------------| |
| | | | |
|HTTP peer-uCDN.dCDN2.net/cdn.csp.com?uCDN-Provider-ID |
|-------------------------------------------->| |
| Connection fail | | |(4) |
|<--------------------------------------------| |
| | | | |
| | ....... |(5) |
|<-------------------------------| | |
| | | | |
|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 | |
TS Choi et al. Expires January 14, 2014 [Page 14]
INTERNET DRAFT Request Interface July 13, 2013
|<-------------------------------| | |
| | | | |
|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,
| | | node3.dCDN1.acq.uCDN.net,
| | | origin.csp.com |
| | | |<---------|
| | |DNS node2.dCDN1-acq.uCDN.net
| | | |--------->|
| | | | |(13)
| | |IPaddr of uCDN's Delivery Node2
| | | |<---------|
| | | | |(14)
| | | | Connection fail
| | | |<---------|
| | |DNS node3.dCDN1-acq.uCDN.net
| | | |--------->|
| | | | |(13)
| | |IPaddr of uCDN's Delivery Node3
| | | |<---------|
| | | | |(14)
| | | | Connection fail
| | | |<---------|
| | |DNS origin.csp.com
| | | |--------->|
| | | | |(13)
| | |IPaddr of csp's origin server
TS Choi et al. Expires January 14, 2014 [Page 15]
INTERNET DRAFT Request Interface July 13, 2013
| | | |<---------|
| | | | |(14)
| | | | Data
| | | |<---------|
| | | ....... | |
|Data | | | |
|<------------------| | | |
Figure 3: HTTP-based request routing redirection iterative procedure
with return of multiple locations
The major difference of this figure from Figure 1 is that multiple
locations are returned when a request routing redirect occurs via
HTTP.
On step 2, uCDN provides multiple URLs of dCDN's request routers, so
that End-User could try to connect one after another. uCDN might
check the availability of each dCDN occasionally to eliminate
unavailable dCDN from the multiple location list. However, any of
dCDN could become unavailable during or right after the redirection
response. In that case, End-User still can try another dCDN from the
list.
If all dCDNs become unavailable, uCDN may want to take over the
dCDN's role. For this, uCDN's URL at the end of the list as seen on
step 2 is inserted. In this way, uCDN can manage the service
availability actively.
It can also be applicable to the recursive request routing
redirection and redirection during contents acquisition as shown in
step 12. However, it is out of scope of this document.
4.3. URI Signing
The detailed URI singing procedure is defined in [I-D.ietf-leung-
cdni-uri-signing-02]. Request interface is responsible for all the
steps related with the interactions between a user agent and uCDN or
dCDN.
5 Security Considerations
TBD.
6 IANA Considerations
TBD.
TS Choi et al. Expires January 14, 2014 [Page 16]
INTERNET DRAFT Request Interface July 13, 2013
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.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for
CDN Interconnection", February 2013.
[I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content
Distribution Network Interconnection (CDNI) Requirements",
July 2013.
[I-D.ietf-cdni-redirection] Wang, H. and Niven-Jenkins, B., "Request
Routing Redirection Interface for Content Distribution
Network Interconnection", April 2013.
[I-D.leung-cdni-uri-signing] Leung, K. and Le Faucheur, F., "URI
Signing for Content Distribution Network Interconnection",
May 2013.
7.2. Informative References
TBD.
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
463-1, Jeonmoin-dong,
Yuseong-gu, Daejeon
Republic of Korea
Phone: 82-10-3235-0135
Email: yohan.seo@kt.com
TS Choi et al. Expires January 14, 2014 [Page 17]
INTERNET DRAFT Request Interface July 13, 2013
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
June-koo Rhee
KAIST
335 Gahak-Ro
Yusong-Gu, Daejeon
Republic of Korea
Phone: +82-10-6788-2814
Email: rhee.jk@kaist.ac.kr
TS Choi et al. Expires January 14, 2014 [Page 18]