Routing Request Redirection for CDN Interconnection
draft-he-cdni-routing-request-redirection-01
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 | Xiaoyan He , Spencer Dawkins , Ge Chen , Wei Ni , Yunfei Zhang | ||
| Last updated | 2012-02-21 (Latest revision 2012-02-16) | ||
| 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-he-cdni-routing-request-redirection-01
CDNI Working Group Xiaoyan.He
Internet Draft Spencer.Dawkins
Intended status: Standards Track Huawei
Expires: August 2012 Ge.Chen
China Telecom
Wei.Ni
Yunfei.Zhang
China Mobile
February 22, 2012
Routing Request Redirection for CDN Interconnection
draft-he-cdni-routing-request-redirection-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 August 22, 2012.
Copyright Notice
Copyright (c) 2012 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 Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
He et all Expires August 22, 2012 [Page 1]
Internet-Draft Routing Redirection February 2012
Abstract
The Request Routing Interface comprises the asynchronous advertisement of
footprint and capabilities by a dCDN that allows a uCDN to decide whether to
redirect particular user requests to that dCDN; and the synchronous operation of
actually redirecting a user request. This document describes protocol for the part
of user requests redirection.
Table of Contents
1. Introduction ..................................................... 2
1.1. Terminology .................................................3
2. Conventions used in this document.................................... 3
3. Interface function and operation overview ............................. 3
3.1. Discussion on protocol type for RRI ............................. 4
3.1.1. DNS based Request Routing Protocol ......................... 6
3.1.1.1. HTTP Redirection utilized by Downstream CDN ............. 6
3.1.1.2. DNS Redirection utilized by Downstream CDN .............. 7
3.1.2. HTTP based Request Routing Protocol......................... 8
4. Protocol Specification ............................................ 10
5. Security Considerations ........................................... 11
6. IANA Considerations .............................................. 12
7. References ...................................................... 12
7.1. Normative References ......................................... 12
7.2. Informative References ....................................... 12
8. Acknowledgments.................................................. 12
1. Introduction
A Content Delivery Network(CDN) is a system of computers built on an
existing IP network which is used for large scale content delivery,
via prefetch or cache contents to its distributed computers close to
the end users, a CDN can improve access to the data it caches, reduce access
latency and improve end user's experience.
In recent years the volume of video and multimedia content delivered
over the internet is rapidly increasing. To accommodating this
increase, existing CDN providers are scaling up their infrastructure
and many Network Service Providers (NSPs) are deploying their own CDNs. Another
emerging requirement is CDN Interconnection (CDNI).
Several real world use cases are described in [I-D.draft-cdni-use-
cases] to prove the necessity for CDN interconnection. The most
frequently mentioned use case is via leveraging the collective CDN
footprint of interconnected standalone CDNs to achieve the goal of
delivering content to additional distributed end users regardless of their
location.
As there is no existing standard to facilitate CDN interconnection,
He et all Expires August 22, 2012 [Page 2]
Internet-Draft Routing Redirection February 2012
IETF has established a working group to produce specifications needed. This draft
is written in response to the problem area described in [I-D.draft-cdni-problem-
statement], when CDNs are interconnected as described in [I-D.draft-cdni-use-cases]
based on the requirements described in [I-D.draft-cdni-requirements], and using
the technology framework described in [I-D.davie-cdni-framework].
The purpose of this document is to define the protocol for synchronous redirection
operation of the request routing interface, which is one of the main building
blocks of the CDN interconnection architecture described in [I-D.draft-cdni-
requirements].
1.1. Terminology
This document reuses the terminology defined in [I-D.draft-cdni-
problem-statement]. The term "Distinguished CDN Domain" defined in [I-D.davie-
cdni-framework] also reused in this document.
The following terms are introduced by this document in addition:
DNS Redirection: The act of using DNS name resolution for the routing process of a
CDN. In DNS Redirection, the DNS resolver of the CDN makes the routing decision
based on a local policy and returns the result as the response of a DNS query
request to redirect a user agent to a new target. In CDNI, the result may point to
a surrogate of the CDN, another interconnected CDN etc.
HTTP Redirection: The act of using an HTTP redirection response to
redirect a user agent to a new target. The new target is the result
of the routing decision of a CDN at the time it receives a content
request via HTTP. In CDNI, the result may point to a surrogate of the CDN, another
interconnected CDN etc.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [RFC2119].
3. Interface function and operation overview
The Request Routing Protocol is one of the main building blocks for
CDNI. The main function of the Request Routing Protocol is to allow
the Request-Routing systems in interconnected CDNs to communicate to facilitate
redirection of the request across CDNs.
The detailed requirements which the Request Routing Protocol need to
meet and priorities of those requirements are described in section 5,
[I-D.draft-cdni-requirements].
To enable the communications over the Request Routing Interface, the
two interconnected CDNs need to know each other's contact address(es). For example,
an Upstream CDN needs to know the contact address of a Downstream CDN to send a
query request based on HTTP for redirection preference, or a Downstream CDN needs
to know the contact address(es) of the upstream peer it should report its
capability information to.
He et all Expires August 22, 2012 [Page 3]
Internet-Draft Routing Redirection February 2012
The contact address may be statically pre-configured, dynamically discovered via
control interface, or other means. However, they are not specified in this
document, as this is considered not in the scope of the CDNI Request Routing
Protocol.
The CDNI solution must support two request routing mechanisms. As
illustrated in section 3.2 and 3.4 of [I-D.davie-cdni-framework], the Iterative
Request Routing method does not invoke any interaction over the request routing
interface across interconnected CDNs. This document hence will not discuss
Iterative Request Routing further.
In the case of Recursive Request Routing, an Upstream CDN forwards a
routing request from a user agent to a Downstream CDN for surrogate
selection. The candidate protocols for these interactions are DNS and HTTP.
Moreover, the inside routing mechanisms used between the CDN and the user agent
(DNS and HTTP Redirection) of the two interconnected CDNs should also be taken
into account as they may affect the type of query request the Upstream CDN send to
a Downstream CDN and the information the Downstream CDN return in its query
response.
3.1. Discussion on protocol type for RRI
The request routing process has several variants depending on the
factors including:
O Which routing mechanism is adopted by an Upstream CDN inside, DNS Redirection
or HTTP Redirection.
O Which protocol is adopted over the Request Routing Interface, DNS or HTTP.
O Which routing mechanism is adopted by a Downstream CDN inside, DNS Redirection
or HTTP Redirection.
All possible combinations and their validity are shown in Table 1.
+-------+---------+----------+------------ +-----------------------+
|CaseNO.| uCDN | RRI | dCDN | Note |
| | Received| Interface| Response | |
| | Request| | | |
+-------+---------+----------+------------ +-----------------------+
| 1 | DNS | DNS based| DNS with IP | dCDN works in HTTP |
| | | |address of RR| Redirection mode, |
| | | | |illustrated in section |
| | | | |3.1.1.1. |
+-------+---------+----------+------------ +-----------------------+
| 2 | DNS | DNS based| DNS with | dCDN works in DNS |
| | | | hostname of | Redirection mode, |
| | | | RR | illustrated in section|
| | | | |3.1.1.2. |
+-------+---------+----------+------------ +-----------------------+
| 3 | DNS |HTTP based| Invalid case|Protocol conversion |
| | | | |occurs in uCDN, |
| | | | | invalid case. |
He et all Expires August 22, 2012 [Page 4]
Internet-Draft Routing Redirection February 2012
+-------+---------+----------+------------ +-----------------------+
| 4 | HTTP |HTTP based| HTTP 302 | dCDN works in HTTP |
| | | | Redirection | Redirection mode, |
| | | | |illustrated in section |
| | | | |3.1.2. |
+-------+---------+----------+------------ +-----------------------+
| 5 | HTTP |HTTP based| DNS | dCDN works in DNS |
| | | | Redirection | Redirection mode, |
| | | | | invalid case. |
+-------+---------+----------+------------ +-----------------------+
| 6 | HTTP |DNS based| Invalid case| Protocol conversion |
| | | | | occurs, invalid case. |
+-------+---------+----------+------------ +-----------------------+
Table 1: Recursive Routing Cases
The rules to filter the cases and determine the validity of them are
discussed below.
The Upstream CDN must not perform protocol conversion (A DNS
query to an HTTP request or vice versa). To assist the routing
decision of a Downstream CDN, the Upstream CDN shall convey as much
information as possible to the Downstream CDN, e.g. URI of the
requested content, the client's location information. In the case of
HTTP to DNS conversion, a DNS request cannot convey all the
information an HTTP request contains. In the case of DNS to HTTP
conversion, a full HTTP URL cannot be constructed through a simple
domain name contained by a DNS query request. Hence it is concluded
that the protocol type used in the Request Routing Interface will be
consistent with the one the Upstream CDN received from the user
agent. Case3, Case6 are invalid according to this rule.
The Downstream CDN can determine according to its local policy
a DNS Redirection or an HTTP Redirection to be adopted. When
receiving a DNS query request over the Request Routing Interface.
If DNS Redirection is selected, as the location information has
been changed to the Upstream CDN's when it proxies the DNS query
request, the Downstream CDN cannot get the user agent's location
information from the query request. The Downstream CDN sends a
response with a CNAME of the hostname of the Request Router,
so that the user agent issues another DNS query request which
will convey its location information as shown in case2. If HTTP
Redirection is selected, the Downstream CDN sends a response with
the IP address of its Request Router, so that it can receive a
subsequent content request based on HTTP containing the client's
location information, to allow selection of an appropriate surrogate
as shown in case1.
Based on filter rules above, Case 1, 2, and 4 are valid cases for
CDNI. The following section describes these cases in detail.
He et all Expires August 22, 2012 [Page 5]
Internet-Draft Routing Redirection February 2012
3.1.1. DNS based Request Routing Protocol
Editor's note: Whether mention invoke or application of content relevant metadata
in the request redirection procedure or just leave it to the framework document
should be determined.
3.1.1.1. HTTP Redirection utilized by Downstream CDN
This example illustrates the CaseNo1 of Table 1. Based on local
policy, the Upstream CDN adopts the DNS Redirection with the user
agent while the Downstream CDN utilizes the HTTP Redirection. The
Downstream CDN should return the IP address in an RR. In this example,the
distinguished domain name of the Downstream CDN is "cdni.op-b.example".
Note: To simplify the presentation, the full URL of the HTTP GET
message is not shown in the example figures of this document.
Only the FQDN at the beginning of each URL is explicitly
presented, however the rest of the URL e.g. the path parameters contained in the
URL should be considered to be present.
End-User CDN B CDN A
|DNS video.cp.example | |(1)
|-------------------------------------------------->|
| | DNS video.cp.example. |
| | cdni.op-b.example |
| |<------------------------|(2)
| |IPaddr of B's Request Router
| |------------------------>|
| IPaddr of B's Request Router |
|<--------------------------------------------------|(3)
|HTTP GET video.cp.example| |
|------------------------>| (4) |
302 node1.cdni.op-b.example/video.cp.example |
|<------------------------| |
DNS node1.cdni.op-b.example | |
|------------------------>| |
|IP address of B's node1 |(5) |
|<----------------------- | |
HTTP GET node1.cdni.op-b.example/video.cp.example |
|------------------------>| |
|Data |(6) |
|<------------------------| |
| | |
Figure 2 DNS based CDNI Recursive Request Routing 1
1. A Request Routing System of CDN A processes the DNS request for
its customer based on the domain video.cp.example and recognizes
He et all Expires August 22, 2012 [Page 6]
Internet-Draft Routing Redirection February 2012
that the end-user is best served by another CDN, specifically
CDN B. Based on the pre-configured distinguished domain name of
CDN B and a negotiated rules for constructing a domain
name contained in a DNS query request over RRI that have been
negotiated with CDN B, the Request Routing System changes the domain name to CDN
B's domain name, with the CP's domain information, and acts as a proxy server
forwarding the DNS request to CDN B.
Note: For simplicity, the local DNS invoked in the procedure is
not shown.
2. Based on the local policy, CDN B determines that the routing
mechanism utilized internally is HTTP Redirection. CDN B returns
the IP address of a Request Router so that the RR get the
subsequent HTTP content request from the user agent.
3. CDN A proxy the response back to the user agent.
4. The user agent sends the content requests to the Request Router
of CDN B. Based on local routing decision policy, e.g. whether
content hits take the highest priority or location proximity
takes the highest priority, the Request Router selects a
delivery node to serve the user agent and returns an HTTP 302
message to redirect the content request.
5. The user agent performs a DNS lookup for the hostname of the
delivery node and gets the IP address of the node.
6. The user agent requests the content from CDN B's delivery node.
The node contains the content, so it sends the content to
the user agent.
3.1.1.2. DNS Redirection utilized by Downstream CDN
This example illustrates the CaseNo2 of Table 1. Based on local
policy, the Upstream CDN and the Downstream CDN both utilize the DNS
Redirection inside with the user agent. As the Downstream CDN cannot get the user
agent's location information through the DNS request forwarded by the Upstream CDN,
in this case, the DNS resolver of the Downstream CDN is configured to return a
CNAME of the RR to make it receive another DNS query request sent by the user
agent/local DNS with information of the user's location. Again, the distinguished
domain name of the Downstream CDN is "cdni.op-b.example".
End-User CDN B CDN A
|DNS video.cp.example | |(1)
|-------------------------------------------------->|
| | DNS video.cp.example. |
| | cdni.op-b.example |
| |<------------------------|(2)
| |CNAME video.cp.example. |
| | rr.cdni.op-b.example |
| |------------------------>|
He et all Expires August 22, 2012 [Page 7]
Internet-Draft Routing Redirection February 2012
CNAME video.cp.example.rr.cdni.op-b.example |
|<--------------------------------------------------|(3)
| DNS video.cp.example. | |
| rr.cdni.op-b.example | |
|------------------------>| |
IP address of delivery node |(4) |
|<------------------------| |
|HTTP GET video.cp.example| |
|------------------------>| |
|Data |(5) |
|<------------------------| |
| | |
Figure 3 DNS based CDNI Recursive Request Routing 2
1. A Request Routing System of CDN A processes the DNS request for
its customer based on the domain video.cp.example and recognizes
that the end-user is best served by another CDN, specifically
CDN B. Based on the pre-configured distinguished domain name of
CDN B and rules that have been negotiated with CDN B that
describe how to construct a domain name contained in a DNS query
request over RRI, the Request Routing System changes the domain
name to CDN B's domain name accompanying with the CP's domain
information and acts as a proxy server forwarding the DNS
request to CDN B.
Note: For simplicity, the local DNS invoked in the procedure is
not shown.
2. CDN B recognizes that the request is from a peer CDN rather than
a user agent by the distinguished domain name. Based on the
local policy, CDN B determines that the routing mechanism
utilized internally is DNS Redirection. CDN B returns the CNAME
of a Request Router so that the user agent will send another DNS
query request to get the user agent's location information.
3. CDN A proxy the response back to the user agent.
4. The user agent sends the content requests to the Request Router
of CDN B based on DNS with the CNAME of the RR. Based on local
routing decision policy, the Request Router selects a delivery
node to serve the user agent and returns IP address of the node.
5. The user agent requests the content from CDN B's delivery node,
the node holds the content at the time and send the content to
the user agent.
3.1.2. HTTP based Request Routing Protocol
This example illustrates the CaseNo4 of Table 1. Based on local
He et all Expires August 22, 2012 [Page 8]
Internet-Draft Routing Redirection February 2012
policy, the Upstream CDN and the Downstream CDN both utilize the HTTP Redirection
inside with the user agent. The Upstream CDN shall provide as much information as
possible to the Downstream to assist making the routing decision. For example, it
includes the content URI and the user's location information etc.
End-User CDN B CDN A
|DNS video.cp.example | |
|-------------------------------------------------->|
| | | (1)
|IPaddr of A's Request Router |
|<--------------------------------------------------|
|HTTP GET video.cp.example| |
|-------------------------------------------------->|(2)
| HTTP GET cdni.op-b.example/video.cp.example|
| |<------------------------| (3)
| 302 node1.cdni.op-b.example/video.cp.example
| |------------------------>|
| 302 node1.cdni.op-b.example/video.cp.example
|<--------------------------------------------------|(4)
DNS node1.cdni.op-b.example | |
|------------------------>| |
|IP address of B's node1 |(5) |
|<----------------------- | |
HTTP GET node1.cdni.op-b.example/video.cp.example |
|-----------------------> | |
|Data | (6) |
|<------------------------| |
| | |
Figure 4 HTTP protocol based CDNI Recursive Request Routing
1. A DNS resolver for CDN A processes the DNS request for its
customer based on the domain video.cp.example. Based on local
policy, HTTP Redirection is adopted for this request. Hence it
returns the IP address of a Request Router in CDN A.
2. A Request Router of CDN A processes the user agent's content
request and recognizes that the end-user is best served by
another CDN, specifically CDN B. Based on pre-configuration
or other means of discovery, the Request Router pushes the
distinguished domain name of CDN B onto the original URL and
acts as a proxy server forwarding the request to CDN B's Request
Router. It also appends an X-Forwarded-For header into the
request with the value set to the user's IP address extracted
from the IP package header of the HTTP request it received.
3. Based on local routing decision policy, e.g. whether content
hits take the highest priority or location proximity takes the
highest priority, the Request Router of CDN B select a delivery
He et all Expires August 22, 2012 [Page 9]
Internet-Draft Routing Redirection February 2012
node for the end user and returns an HTTP 302 message to
redirect the content request to the node.
4. CDN A proxies the response back to the user agent.
5. The user agent performs a DNS lookup for the hostname of the
delivery node and gets the IP address of the node.
6. The user agent requests the content from CDN B's delivery node.
Since the node holds the content, it sends the content to
the user agent.
4. Protocol Specification
This section specifies how the Request Routing Protocol enables the Upstream CDN
acting as a proxy server to communicate with the downstream CDN to implement routing
redirection.
4.1.1. Recursive Request Routing
4.1.1.1. DNS based Request Routing Protocol
4.1.1.1.1. Upstream CDN Behavior
Upon receiving a DNS query request from a user agent, the Request
Routing System of the Upstream CDN SHALL first determine an inside routing mechanism
according to local policy. In case of DNS Redirection is leveraged, based on the local
routing policy, if it is aware that the user is best served by another CDN, the
Upstream CDN SHALL select a
Downstream CDN and forward the DNS request to the Downstream CDN. When
HTTP Redirection is adopted, the Upstream CDN SHALL respond with the
address of a Request Router of the Upstream CDN.
The QNAME contained in the DNS query request which is forwarded to
the Downstream CDN SHALL be constructed by the rules negotiated by
the two interconnected CDNs and based on the distinguished domain
name of the Downstream CDN.
Upon receiving a response from the Downstream CDN, the Request
Routing System of the Upstream CDN shall forward it back to the user
agent with the DNS payload unchanged.
4.1.1.1.2. Downstream CDN Behavior
Upon receiving a DNS query request, the Downstream CDN SHALL first
identify that this is a request for CDNI based on the distinguished
domain name contained in the query request, and extracts the content
provider's domain name. It then SHALL determine an inside routing mechanism according
to local routing policy.
Note: The local routing policy may take into account the CP's policy
if existed identified by the CP's domain name.
He et all Expires August 22, 2012 [Page 10]
Internet-Draft Routing Redirection February 2012
In case of DNS Redirection, it SHALL select a request router and
return a response containing a CNAME with the hostname of the request
router.
In case of HTTP Redirection, it SHALL select a request router and
return a response containing the IP address of the Request Router.
4.1.1.2. HTTP based Request Routing Protocol
4.1.1.2.1. Upstream CDN Behavior
Upon receiving an HTTP GET request from a user agent for specific
content, based on the local routing policy, if it is determined that
the user is best served by another CDN, the Request Router of the
Upstream CDN SHALL select a Downstream CDN for the end user, insert
an X-Forwarded-For header into the request with the value set to the
User Agent's IP address, augment the original URL with the
distinguished domain name of the Downstream CDN in front of it, and
then forward the request to the elected Downstream CDN.
After receiving an HTTP "302" redirection response from the
Downstream CDN, the Upstream CDN SHALL forward it back to the user
agent.
4.1.1.2.2. Downstream CDN Behavior
Upon receiving an HTTP GET request, the Downstream CDN SHALL select a
delivery node for the user based on the local routing policy.
If the user's location information is required to make the routing
decision, it SHALL obtain that from an X-Forwarded-For header if this
hearder exists. The Downstream CDN SHALL then return a response with
a 302 Redirection message. The Location header's value is constructed
by truncating the CDN B's domain name from the original URL in the
request it received, and inserting the host name of the selected delivery node onto
the front of the remaining URL.
4.1.2. Iterative Request Routing
Note: Whether any content relative to Iterative Request Routing should
be added here is to be determined by the CDNI working group.
5. Security Considerations
In HTTP based Recursive Request Routing, the end user's web
browsers will not send cookies if the content request is redirected
to a URL in a different domain rather than the original CP's domain,
e.g. the Downstream CDN's domain. If the browser is expected to send
any cookies associated with the original CP's domain, this will cause
problem that the CP's policy is not enforced by the CDN.
The section 5.2 of draft [I-D.draft-peterson-cdni-strawman] has
discussed a similar question and given a solution.
He et all Expires August 22, 2012 [Page 11]
Internet-Draft Routing Redirection February 2012
6. IANA Considerations
This document makes no request of IANA.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax and Semantics",
RFC 3986, January 2005.
7.2. Informative References
[I-D.draft-cdni-use-cases]
"Use Cases for Content Delivery Network Interconnection",
Gilles Bertrand, Stephan Emile, Grant Watson, Trevor
Burbridge, Philip Eardley, Kevin Ma, 22-Sep-11, <draft-ietf-
cdni-use-cases-03.txt>.
[I-D.draft-cdni-problem-statement]
"Content Distribution Network Interconnection (CDNI) Problem
Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil
Bitar, 9-Sep-11, <draft-ietf-cdni-problem-statement-03.txt>.
[I-D.draft-cdni-requirements]
"Content Distribution Network Interconnection (CDNI)
Requirements", Kent Leung, Yiu Lee, 9-Sep-11, <draft-ietf-
cdni-requirements-02.txt>.
[I-D.draft-peterson-cdni-strawman]
"A Simple Approach to CDN Interconnection", Larry
Peterson, John Hartman, 18-May-11,<draft-peterson-
cdni-strawman-01.txt,.pdf>.
[I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in
progress), July 2011.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
He et all Expires August 22, 2012 [Page 12]
Internet-Draft Routing Redirection February 2012
Authors?Addresses
Xiaoyan He
Huawei
B2, Huawei Industrial Base, 518129
China
Email: hexiaoyan@huawei.com
Spencer Dawkins
Huawei
Email: spencer.dawkins@wondermaster.com
Ge Chen
China Telecom
109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C
Email: cheng@gsta.com
Wei Ni
China Mobile
No.32 Xuanwumen West Street Xicheng District Beijing, 100053
China
Email: niwei@chinamobile.com
Yunfei Zhang
China Mobile
Email: zhangyunfei@chinamobile.com
He et all Expires August 22, 2012 [Page 13]