Network Working Group Xiaoyan He
Internet Draft Jincheng Li
Intended status: Informational Spencer Dawkins
Expires: December 2011 Huawei
Ge Chen
China Telecom
June 30, 2011
Request Routing for CDN Interconnection
draft-xiaoyan-cdni-requestrouting-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 31, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust
XiaoyanHe, et al. Expires December 31, 2011 [Page 1]
Internet-Draft CDNI Request Routing June 2011
Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
Abstract
This document describes recursive request routing procedures for
CDN interconnection, it also describes content acquisition
procedure using the HTTP protocol when cache miss occurs.
The goal of the present document is to spur discussion about
these procedures and to achieve a consensus on request routing
procedures of CDNI.
Table of Contents
1. Introduction................................................2
2. Conventions used in this document............................4
3. Request routing.............................................4
3.1. Scope definition........................................4
3.2. Protocol considerations on routing procedure............5
3.3. Domain Name examples....................................5
3.4. Operation codes considerations..........................5
3.5. Client location's availability..........................6
4. Configuration summary........................................6
5. Request routing approaches...................................7
5.1. First approach.........................................7
5.2. Second approach.........................................9
6. Conclusions................................................10
7. Security Considerations.....................................10
8. IANA Considerations........................................10
9. References.................................................10
9.1. Normative References...................................10
9.2. Informative References.................................11
1. Introduction
CDNI request routing includes the following two scenarios:
Scenario A: request routing for user initiated requests, where
once the upstream CDN receives the user request (DNS or HTTP),
upstream CDN communicates with a downstream CDN to get the
address of a delivery node to serve the user.
Scenario B: request routing for content acquisition, where the
selected delivery node in downstream CDN receives the
XiaoyanHe, et al. Expires December 31, 2011 [Page 2]
Internet-Draft CDNI Request Routing June 2011
user's request and encounters a cache miss, and communicates with
upstream CDN to select a delivery node to acquire the content.
From procedure perspective, both iterative and recursive request
routing are to be supported by CDNI solution as per requirement
draft [I-D.draft-lefaucheur-cdni-requirements] (requirements R33
and R34 in version -01).
From protocol perspective, either DNS or HTTP[RFC2616] can be
used for request routing.
Therefore, we can have four solution combinations for each
scenario, see table below.
+---------+-------+----+----+----+-----+---------+
| | Protocol | Procedure |
+ Case No.+-------+----+----+----+-----+---------+
| | DNS | HTTP | Iterative|Recursive|
+---------+-------+----+----+----+-----+---------+
| 1 | Y | | Y | |
+---------+-------+----+----+----+-----+---------+
| 2 | Y | | | Y |
+---------+-------+----+----+----+-----+---------+
| 3 | | Y | Y | |
+---------+-------+----+----+----+-----+---------+
| 4 | | Y | | Y |
+---------+-------+----+----+----+-----+---------+
Table 1: solution combinations for CDNI scenarios
Document [I-D.draft-peterson-cdni-strawman] gives a discussion on
iterative routing using DNS. The present document discusses
recursive request routing procedures using DNS or HTTP.
Note: According to the proposed charter and current (individual)
requirement document for CDNI, interfaces inside CDN are out of
scope of CDNI, i.e. interactions
XiaoyanHe, et al. Expires December 31, 2011 [Page 3]
Internet-Draft CDNI Request Routing June 2011
between a delivery node and RR in the downstream CDN during
content acquisition should not be specified in CDNI; hence
this document does not describe that interface in detail.
2. Conventions used in this document
The two terms "Iterative CDNI request routing" and "Recursive
CDNI request routing" in this document are to be interpreted
as defined in [I-D .draft-lefaucheur-cdni-requirements].
3. Request routing
3.1. Scope definition
This document focuses on Recursive CDNI request routing. For
convenience, definition for recursive CDNI request routing from
[I-D .draft-lefaucheur-cdni-requirements] is copied as below.
o Recursive CDNI request routing: When an Upstream CDN
elects to redirect a request towards a Downstream CDN, the
Upstream CDN can query the Downstream CDN Request Routing
system via the CDNI Request Routing protocol (or use
information cached from earlier similar queries) to find out
how the Downstream CDN wants the request to be redirected,
which allows the Upstream CDN to factor in the Downstream
CDN response when redirecting the user agent.
This approach is referred to as "recursive" CDNI request
routing. Note that the Downstream CDN may elect to
have the request redirected directly to a Surrogate inside
the Downstream CDN, to the Request-Routing System of the
Downstream CDN, to another CDN, or to any other system that
the Downstream CDN sees as fit for handling the redirected
request.
Other "recursive" mechanisms also utilized in CDNI, but not for
interactions of RRs during request routing procedures such as
the local DNS's role in DNS lookup, are not in the scope of
this document.
XiaoyanHe, et al. Expires December 31, 2011 [Page 4]
Internet-Draft CDNI Request Routing June 2011
3.2. Protocol considerations on routing procedure
Two main protocols can be used for CDNI recursive request
routing, i.e. HTTP or DNS. The present document obeys a
principle that the protocol utilized between two RR systems
keeps same as that utilized between the end user and the first
touched RR to simplify the RR implementation.
3.3. Domain Name examples
There are several domain names involved in this document, below
are their examples and explanations.
1. video.cp.example
In this document, a content provider with domain name cp.example
contracts with a CDN provider. Domain name video.cp.example
represents the specific sub domain to be accelerated by the
contracted CDN.
Generally, the authoritative DNS server of domain
video.cp.example has a record pointing to a domain of the
contracted CDN,in order to direct the relevant DNS requests to
that CDN.
A contractual CDN may ingest content from the contracted content
provider in advance or dynamically. However, the ingestion
procedures are out of scope of CDNI and therefore not described
in this draft.
2. cdn.op-x.example
Operator X with domain name op-x.example provides CDN services
using sub domain name cdn.op-x.example. This CDN-domain
augmented with a prefix "peer" used to identify the request it
received is from a peer CDN rather than from end users.
3.4. Operation codes considerations
In case of HTTP signaling used between RRs of connected CDNs,
as one CDN may act as a downstream peer and an upstream peer
for different CPs at the same time, it's possible that a CDN
receives requests from other interconnected CDNs for different
purposes. e.g.selecting a delivery node for an end user or
selecting a delivery node holding the content for a downstream
peer. Therefore the CDN needs to distinguish these requests
to act correspondingly.
Operation code "CDNIRoutereq" and "CDNIContentlocate" contained
in the URL of HTTP requests is used for this purpose in the
present document.
XiaoyanHe, et al. Expires December 31, 2011 [Page 5]
Internet-Draft CDNI Request Routing June 2011
3.5. Client location's availability
To select the most appropriate delivery node ultimately to serve
for an end user, usually the user's location is taken into
account by the downstream CDN. Therefore, the user's IP address
or FQDN should be conveyed to the downstream CDN from the
upstream peer during CDNI request routing.
In case of HTTP redirection, the upstream CDN can get the
specific IP address of the end user. It is proposed the
upstream CDN convey this IP address or construct a FQDN to
the downstream CDN for optimal routing decision.
In case of DNS redirection, the upstream CDN may obtain the end
user's IP address through the DNS client subnet extension or by
embedding the client IP address in the DNS name
[I-D.vandergaast-edns-client-subnet]. It is
proposed that the upstream CDN forwards this info to the
downstream CDN directly for optimal routing decision. If the UE
does not support this DNS extension, the upstream CDN therefore
will not convey sort of this extension to its down peer. It is
proposed that the downstream CDN returns the request router's
address. After that the specific HTTP request for content will be
sent to the request router,at this point, the request router can
elect a more accurate delivery node for the user based on its IP
address.
4. Configuration summary
Interconnection CDNs must exchange the following information to
peer with each other:
o The IP address of the entry point of the CDN or distinguished
CDN domain name; and
o Set of IP prefixes for which the CDN is prepared to deliver
to end-users.
o Set of CP domain names for which the CDN is served.
When a Request Router in an upstream sees an end-user IP address
best served by a downstream peer, upstream CDNs needs to forward
the request to the configured entry point of the downstream peer,
or to result of DNS lookup for the configured downstream CDN's
domain name.
When a delivery node in a downstream receives content requests
from end users and result in cache miss, it verifies that the
CP domain
XiaoyanHe, et al. Expires December 31, 2011 [Page 6]
Internet-Draft CDNI Request Routing June 2011
contained in the URL is served by a known CDN peer based on
configuration, and if so, issues a content acquisition request to
that peer.
5. Request routing approaches
5.1. First approach
This alternative utilizes HTTP redirection between the end user
and the upstream CDN. On reception of HTTP request, the upstream
CDN communicates directly with selected downstream CDN to get a
delivery node.
End-User CDN B CDN A
|DNS video.cp.example | |
|-------------------------------------------------->|
| | | (1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP GET video.cp.example| |
|-------------------------------------------------->|
| HTTP POST peer.cdn.op-b.example/CDNIRoutereq| (2)
| |<------------------------|
| 200 Hostname of B's Delivery Node
| |------------------------>| (3)
| 302 Hostname of B's Delivery Node |
|<--------------------------------------------------|
HTTP GET Hostname/video.cp.example |HTTP POST peer.cdn.op-a.example
|------------------------>| /CDNILocatecontent | (4)
| |------------------------>|
| 200 Hostname of A's Delivery Node (5)
| |<------------------------|
| HTTP GET Hostname of A'DN/rest of url|
| |------------------------>| (6)
| |Data |
|Data |<------------------------|
|<------------------------| |
| | |
| | |
Figure 1: Request routing for approach one
1. A Request Router of CDN A processes the DNS request for
its customer and recognizes that the end-user is best
served by another CDN. CDN A returns the IP address of
its Request Router to get the HTTP request of the user.
XiaoyanHe, et al. Expires December 31, 2011 [Page 7]
Internet-Draft CDNI Request Routing June 2011
Note: The domain name in step1 of the CP e.g.video.cp.example
should be changed to the CDN A's when the request is
redirected to CDN A. For simplicity, this is not shown in
the figure.
2. A Request Router of CDN A processes the HTTP request and
again recognizes that the end-user is best served by
another CDN, so based on the configuration and result of
a potential DNS lookup, CDN A issues an HTTP POST to CDN
B's Request Router, with the distinguished CDN b's
domain name and a command code "CDNIRoutreq" contained
in the URL. The command code is used to explicitly
indicate this is a request from a peer for delivery node
selection. Other parameters e.g.the end user's IP address
and the CP's domain name shall be included in the body of
the HTTP POST.
3. CDN B's Request Router recognizes the request is from a
peer CDN, if the end user's IP is included, it selects
and returns a suitable delivery node for the user based
on its location. The address of this node is returned to
the end user via CDN A.
Based on local policy, CDN B may return the request
router's address instead of that of a delivery node.
4. The end-user requests the content from CDN B's delivery
node, potentially resulting in a cache miss. From the
URL CDN B verifies that this CP-domain served by a known
peer. It then sends a HTTP POST with a command code
"CDNILocatecontent" and CDN A's distinguished domain
name contained in the URL to CDN A's Request Router.
Other parameters such as playback URL of the content
shall be included in the body of the HTTP POST.
If the CDN B's Request Router address is returned
in step 3, the content request will first arrive at CDN
B's Request Router and a 302 response with the address
of the selected delivery node will be sent back to the end
user.
5. CDN A recognizes that the HTTP request is from a peer
CDN rather than an end-user based on the command code and so
returns address of a delivery node.
6. CDN A serves content for the requested CDN-domain.
XiaoyanHe, et al. Expires December 31, 2011 [Page 8]
Internet-Draft CDNI Request Routing June 2011
5.2. Second approach
This approach utilizes DNS redirection between an end user and
the upstream CDN. On reception of DNS lookup request, the
upstream CDN communicates directly with the selected downstream
CDN to locate delivery node.
End-User CDN B CDN A
|DNS video.cp.example | |
|-------------------------------------------------->|
| |DNS peer.cdn.op-b.example| (1)
| |<------------------------|
| |IPaddr of B's Delivery Node
| |------------------------>|
| IPaddr of B's Delivery Node | (2)
|<--------------------------------------------------|
|HTTP GET video.cp.example|HTTP POST peer.cdn.op-a.example
|------------------------>|/CDNILocatecontent |(3)
| |------------------------>|
| |200 HostName of A's Delivery Node
| |<------------------------|
| HTTP GET Hostname of A'DN/rest of url| (4)
| |------------------------>|
| |Data |
|Data |<------------------------| (5)
|<------------------------| |
Figure 2: Request routing for approach two
1. A Request Router of CDN A processes the DNS request for
its customer and recognizes that the end-user is best
served by another CDN. The client IP used in this
determination is obtained either through the DNS client
subnet extension or by embedding the client IP in the
DNS name [I-D.vandergaast-edns-client-subnet]. Based on
configuration, the Request Router changes the domain
name to CDN B's distinguished name and forwards the DNS
request to CDN B's Request Router.
2. CDN B's Request Router recognizes the request is from a
peer CDN based on the distinguished domain name, it
returns a suitable delivery node. The address of this
node is returned to the end user via CDN A. Or based on
local policy or CDN B did not get the address of the client
in step 1, CDN B may return the address of the Request
Router.
XiaoyanHe, et al. Expires December 31, 2011 [Page 9]
Internet-Draft CDNI Request Routing June 2011
3. The end-user requests the content from CDN B's delivery
node, potentially resulting in a cache miss. From the
URL CDN B verifies that this CP is served by a known peer.
It then issues an HTTP POST with command code
"CDNILocatecontent" and CDN A's distinguished domain
name contained in the URL to CDN A's Request Router.
Other parameters such as playback URL of the content
shall be included in the body of the HTTP POST.
If the CDN B's Request Router address is returned
in step2, the content request will first arrive at CDN
B's Request Router and a 302 response with the address
of selected delivery node will be sent back to the end
user.
4. CDN A recognizes that the HTTP request is from a peer
CDN rather than an end-user from the command code and so
returns the address of a delivery node.
5. CDN A serves content for the requested CDN-domain.
6. Conclusions
Priorities for proposed approaches in present document will be
worked out later based on discussion on the email list.
7. Security Considerations
For the recursive request routing approach described in
Section 5.2, the user agent may determine to convey its IP
address to the CDN by including its IP address in the DNS
client subnet extension or embedding the IP address in the
DNS name [I-D.vandergaast-edns-client-subnet] for optimizing
the routing.
In case of CDNI, if [RFC1918] address space is utilized by the
end user, the [RFC1918] IP address should not be paased across
the addressing boundary to the downstream CDN, for several
reasons,which include the possibility that the downstream CDN
might also use overlapping [RFC1918] address space.
A possible approach for this is that when the upstream CDN
recognizes that an [RFC1918] address is used by the user agent,
it shall change this address to the global unique IP address of
the local DNS for the end user from the IP packet header and
transfer this address to the downstream peer. The downstream CDN
then may select a delivery node for the user based on the local
DNS's address or just return the RR's address to the upstream CDN.
XiaoyanHe, et al. Expires December 31, 2011 [Page 10]
Internet-Draft CDNI Request Routing June 2011
8. IANA Considerations
If the approach described in this document is adopted, we would
request that IANA allocate the command codes "CDNIRoutereq"
and "CDNIContentlocate" in the HTTP Parameters registry.
9. References
9.1. Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC1918] "Address Allocation for Private Internets", Y.Rekhter,
B.Moskowitz,D.Karrenberg, G.J.de Groot,E.Lear, February
1996.
[I-D.draft-lefaucheur-cdni-requirements]
"Content Distribution Network Interconnection (CDNI)
Requirements", Francois Le Faucheur, Mahesh
Viveganandhan, Grant Watson, Yiu Lee, 14-Mar-11,
<draft-lefaucheur-cdni-requirements-01.txt>
[I-D.draft-peterson-cdni-strawman]
"A Simple Approach to CDN Interconnection", Larry
Peterson, John Hartman, 18-May-11,<draft-peterson-
cdni-strawman-01.txt,.pdf>
[I-D.vandergaast-edns-client-subnet]
Contavalli, C., van der Gaast, W., Leach, S., and D.
Rodden, "Client subnet in DNS requests", January 2011.
9.2. Informative References
Authors' Addresses
XiaoyanHe, et al. Expires December 31, 2011 [Page 11]
Internet-Draft CDNI Request Routing June 2011
Xiaoyan He
Huawei
B2, Huawei Industrial Base, 518129
China
Phone: +86 158 2938 5137
Email: hexiaoyan@huawei.com
Jincheng Li
Huawei
B2, Huawei Industrial Base, 518129
China
Phone: +86 139 9195 3074
Email: lijincheng@huawei.com
Spencer Dawkins
Huawei
1700 Alma Drive,Suite 100 Plano,TX 75075 USA
Phone: +1 469 229 5397
Email: spencer@wonderhamster.org
Ge Chen
China Telecom
109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C
Phone: +86 133 1609 0408
Email: cheng@gsta.com
XiaoyanHe, et al. Expires December 31, 2011 [Page 12]