Internet DRAFT - draft-chen-cdni-intra-cdn-provider-cdni-experiment
draft-chen-cdni-intra-cdn-provider-cdni-experiment
CDNI WG G. Chen
Internet-Draft China Telecom
Intended status: Experimental M. Li
Expires: August 3, 2016 H. Xia
ZTE Corporation
B. Khasnabish
ZTE (TX) Inc.
J. Liang
China Telecom
January 31, 2016
Intra-CDN Provider CDNi Experiment
draft-chen-cdni-intra-cdn-provider-cdni-experiment-04
Abstract
In [RFC6770], the Inter-Affiliates CDN Interconnection use case is
described. In this scenario, a large CDN Provider may have several
autonomous or semi-autonomous subsidiaries that each operates on
their own CDN. The CDN Provider needs to make these down-stream CDNs
interoperate to provide a consistent service to its customers on the
whole collective footprint.
This document illustrates in details the CDNi experiment that has
been carried out by China Telecom, and the lessons and experiences to
CDNi standardization work.
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 August 3, 2016.
Chen, et al. Expires August 3, 2016 [Page 1]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
Copyright Notice
Copyright (c) 2016 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Intra-CDN Provider CDNi Experiments . . . . . . . . . . . . . 3
2.1. Experiment Configuration . . . . . . . . . . . . . . . . 3
2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Request Routing and Content Acquisition . . . . . . . . . 8
2.4.1. Request Routing and Content Acquisition in Province B 8
2.4.2. Request Routing and Content Acquisition between
Province A and Province B . . . . . . . . . . . . . . 9
2.4.3. Test Results . . . . . . . . . . . . . . . . . . . . 11
2.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Simplification of operation procedures . . . . . . . . . 13
3.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Metadata and Logging . . . . . . . . . . . . . . . . . . 14
3.5. Inter-Operator CDN Interconnection . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Chen, et al. Expires August 3, 2016 [Page 2]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
1. Introduction
As a CDN service provider, China Telecom has established video CDNs
in more than ten provinces in China. These video CDNs, provided by
different vendors, are relatively independent and only provide
services to the end users of their own provinces. Under this
circumstance, if a Content Provider (CP) wants to provide services to
multiple provinces, it needs to interact with CDNs in other provinces
via interfaces which may support different standards.
In 2011, China Telecom launched the CDN interconnection trial network
where CDNs from six different vendors (ZTE, Huawei, Cisco, etc.) were
used to conduct the interconnection experiment in three provinces.
This experiment aims at testing the scenario where the operator
provides autonomous services via CDN interconnection in order to
provide enhanced user experience. It is noted that a simplification
of the interconnection framework and the corresponding procedures
would really improve the service and real-time viewing experience.
This experiment is not intended to cover all of the use cases or the
scenarios that are within the scope of CDNi work. It simply provides
some practical information gathered from the actual network
experiment as a reference to the CDNi standardization work. These
CDN interconnection implementation experiments cover mostly the
intra-operator interconnection scenarios.
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].
This document reuses the terminology defined in the following RFCs:
[RFC6707], [RFC6770], [RFC7336], and [RFC7337].
2. Intra-CDN Provider CDNi Experiments
2.1. Experiment Configuration
The interconnection of four CDNs in two provinces has been tested in
this experiment. Each province has two CDNs interconnected which are
provided by different CDN vendors. As depicted in Figure 1, CDN A1
of Province A has contracts with service providers CP1 and CP2, and
it acts as the content storage center of the nation.CDN B1 of
Province B has contract with service provider CP3. Meanwhile, CDN A1
and CDN B1 are the sub-center CDNs of respective province, while CDN
A2 and CDN B2 are the regional CDNs of respective province. CDN A1
and CDN B1 are deployed on the provincial backbone networks, while
Chen, et al. Expires August 3, 2016 [Page 3]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
CDN A2 and CDN B2 are deployed on the MANs. CDN A1 is the upstream
CDN of CDN A2. Services are provided to the end users by certain
node in regional CDN, which is usually the geographically closest one
to the end user. However, if this desired node is overloaded,
certain re-routing or load-balancing criteria could be used to choose
another node. CDN B1 and CDN B2 have similar deployment. The
provincial center CDN A1 and CDN B1 are interconnected with each
other. They do not have interconnection with the region CDNs in
other provinces than themselves. The regional CDNs of the respective
provinces do not interconnect with one another either.
China Telecom's CDN trial network offers two types of services:
intra-province service (provided by CP2 and CP3) and inter-province
service (provided by CP1). Intra-province service is provided
independently within the province without any interconnection with
CDNs in other provinces. When inter-province service is provided,
content is ingested to the CDN in a single province and then
distributed among the CDNs in all other provinces in the trial
network. In this experiment the inter-province service is ingested
via CDN A1 node and the end users can obtain services through the
CDNs that are located in their own provinces.
Chen, et al. Expires August 3, 2016 [Page 4]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
+------+
| CP1 |
+------+ +-----+
+------+ / | CP3 |
| CP2 | / +-----+
+------+ / : /
\ / : /
\ / : /
\ :
_,.---.,, : _,.---.,,
.` `. : .` `.
' \ : ' \
| CDN A1 |---:---- | CDN B1 |
, / ---:---- , /
', ,- : ', ,-
``''--'`` : ``''--'``
| | : | |
| | : | |
| | : | |
_,.---.,, : _,.---.,,
.` `. : .` `.
' \ : ' \
| CDN A2 | : | CDN B2 |
, / : , /
', ,- : ', ,-
``''--'`` : ``''--'``
:
Province A : Province B
:
Figure 1 CDNI between Two Different Provinces, each with Two CDNs
The details of the experiment are as presented below:
CP3 has contract with CDN B1 to provide content delivery service,
e.g., IPTV service, to the end users in the Province B region. CP3
does not serve end users outside Province B. As an autonomous
service by China Telecom, the content of this service is ingested
into CDN B1. As its downstream CDN, CDN B1 can delegate the content
requests from end users to CDN B2 to perform content delivery.
When CDN B1 receives the content request from EU B of Province B
related to service provided by CP3, it redirects this request to CDN
B2. If CDN B2 has locally cached the copy of the content requested
by EU B (cache hit case), it serves EU B directly by delivering the
content to EU B. If CDN B2 does not have the content cached (cache
miss case), it acquires the content from CDN B1.
Chen, et al. Expires August 3, 2016 [Page 5]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
CP1 has contract with CDN A1 to provide content delivery service,
e.g., OTT service, to end users within Province A and in the region
of Province B. The content for this service is ingested from CDN A1.
As for the cross-province routing, since it is within the same
operator, static configuration can be used for dCDN selection. In
this experiment, the national content storage center CDN A1
configures locally the relationship table of the end user's IP
addresses and the loading condition of dCDNs.
When CDN A1 receives a content request from EU B of Province B, it
redirects the request to CDN B2 directly after it checks the local
configuration table without going through multiple redirection
processes like CDN A1->CDN B1->CDN B2. If CDN B2 has locally cached
a copy of the content that has been requested by EU B (cache hit
case), it serves EU B directly by delivering the content to EU B. If
CDN B2 does not have the content cached (cache miss case), it
acquires the content from CDN B1. If CDN B1 does not have the
content cached either, it acquires the content from CDN A1.
In this experiment, we use a content acquisition method that is
different from the current CDNi work. The method is based on Content
Identification by using UniContentID that is defined to uniquely
identify a content item. A detailed description of this method is
presented in Section 2.3.
Chen, et al. Expires August 3, 2016 [Page 6]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
+------+
| CP1 |
+------+ +-----+
/ | CP3 |
/ +-----+
/ : /
/ : /
/ : /
:
_,.---.,, : _,.---.,,
.` `. : .` `.
' \ : ' \
| CDN A1 |---:---- | CDN B1 |
, / ---:---- , /
', ,- : ', ,-
``''--'`` : ``''--'``
| | : | |
| | : | |
| | : | |
_,.---.,, : _,.---.,,
.` `. : .` `.
' \ : ' \
| CDN A2 | : | CDN B2 |
, / : , /
', ,- : ', ,-
``''--'`` : ``''--'``
: |
Province A : Province B |
: +------+
: | EU B |
: +------+
:
:
Figure 2 CDNI between Two Different Provinces
2.2. Logging
Since in this experiment CDN interconnection is implemented within
the scope of the same operator, charging-related operations via
Logging Interface are not required. Therefore, we have neither
implemented nor tested any Logging operations.
2.3. UniContentID
In the current IETF CDNi standards, it is required to add the URL of
original request and the URL in the process through CDNs in the
request routing. When cache is not hit, downstream CDN needs to use
the information above to trace the source. The redirection flows are
Chen, et al. Expires August 3, 2016 [Page 7]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
complex and the URL becomes very long which makes the implementation
very difficult.
In this experiment, the UniContentID as defined in [I-D.draft-chen-
cdni-rr-content-acquisition] is used. UniConentID is described by
two tuple as (ProviderID, ContentID), e.g.
('iptv.netitv.com','01234567890123456789012345678900'), which can
uniquely identify a content item. We trace the content source
according to the configuration table of ProviderID and the
corresponding relationship between ProviderID and the IP address of
upstream CDN. It is our view that redirection and content
acquisition are different routes.
2.4. Request Routing and Content Acquisition
2.4.1. Request Routing and Content Acquisition in Province B
+-------------------------+ +------------------------+
| CDN B1 | | CDN B2 |
+-------+ | +---------+ +----------+| | +---------+ +--------+|
| EU | | |CDN B1 RR| | CDN B1 DN|| | |CDN B2 RR| |CDN B2DN||
+-------+ | +---------+ +----------+| | +---------+ +--------+|
| +-------------------------+ +------------------------+
|(1)RTSP or HTTP REQ | | |
|------------> | | | |
| (2)RTSP or HTTP RES | | |
| <------------| | | |
| | (3)RTSP or HTTP REQ | |
|--------------------------------------------> | |
| | (4)RTSP or HTTP REP | |
| <--------------------------------------------| |
| | | | |
| | (5)RTSP or HTTP REQ | |
|---------------------------------------------------------> |
| | | | |
| | | (6)HTTP REQ| |
| | |<---------------------------- |
| | | | |
| | | (7)HTTP REP| |
| | |----------------------------> |
| | | | |
| | | | |
| | | | |
| | (8)DATA | |
|<--------------------------------------------------------- |
| | | | |
Figure 3 Request Routing and Content A Acquisition in Province B
Chen, et al. Expires August 3, 2016 [Page 8]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
The Message sequence of Figure 3 is shown below in details.
(1) End-User sends a request to the load balancer of CDN B1, i.e. RR
of CDN B1 for the content.The URL includes the parameter of CMSID and
Domain(Please refer to [I-D. draft-chen-cdni-rr-content-acquisition]
for corresponding definitions).
(2) The RR of CDN B1 chooses an optimal RR of dCDN, i.e. RR of CDN B2
for the End-User according to the load of dCDN and the IP Pool
information.
(3) End-User sends a request to the dCDN, i.e. RR of CDN B2 for
content acquisition.
(4) RR of CDN B response to the End-User for the information of a
delivery node i.e. DN.
(5) End-User sends a content request to the DN of CDN B2, the URL
include the information of CMSID and Domain. The DN of CDN B2
analyses the ProviderID according the information of CMSID and Domain
and looks up if the content exists in the cache according to the
ProviderID and ContentID. If the content is cached, the DN of CDN B2
serves the End-User. Otherwise, it skips to step (6).
(6) The DN of CDN B2 looks up the configuration table and determines,
according to the ProviderID, to acquire content uniquely identified
by the ProviderID and ContentID from the DN of CDN B1.
(7) The content in the DN of CDN B1 relays to the DN of CDN B2.
(8) The relayed content is served by the DN of CDN B2 to the End-User
via playing by downloading.
2.4.2. Request Routing and Content Acquisition between Province A and
Province B
Chen, et al. Expires August 3, 2016 [Page 9]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
+------------------+ +------------------+ +------------------+
| CDN A1 | | CDN B1 | | CDN B2 |
+----+|+------+ +------+ | |+------+ +------+ | |+------+ +------+ |
| EU |||CDN A1| |CDN A1| | ||CDN B1| |CDN B1| | ||CDN B2| |CDN B2| |
+----+|| RR | | DN | | || RR | | DN | | || RR | | DN | |
| |+------+ +------+|| |+------+ +------+|| |+------+ +------+||
| +------------------+ +------------------+ +------------------+
|(1)RTSP or HTTP REQ | | | |
|-----> | | | | | |
|(2)RTSP or HTTP REP | | | |
| <-----| | | | | |
| | (3)RTSP or HTTP REQ | | |
|-----------------------------------------------> | |
| | (4)RTSP or HTTP REP | | |
| <-----------------------------------------------| |
| | | | | | |
| | | (5)RTSP or HTTP REQ | |
|----------------------------------------------------------->|
| | | | | | |
| | | | | (6)HTTP REQ |
| | | | |<--------------------|
| | | (7)HTTP REQ | | |
| | |<-------------------| | |
| | | | | | |
| | | (8)HTTP REP | | |
| | |------------------->| | |
| | | | | (9)HTTP REP |
| | | | |-------------------->|
| | | | | | |
| | | (10)DATA| | | |
|<---------------------------------------------------------- |
| | | | | | |
| | | | | | |
Figure 4 RR and Content Acquisition between Province A and Province B
The Message sequence of Figure 4 is shown below in details.
Step (1)~(5) is similar to step(1)~(5)of Section 2.4.1.Note that the
request routing process does not need the participation of CDN B1.
(6) The DN of CDN B2 looks up the configuration table and determines,
according to the ProviderID, to acquire content uniquely identified
by the ProviderID and ContentID from the DN of CDN B1. If the
content is cached in DN of CDN B1, the DN of CDN B1 serves the End-
User. Otherwise, it skips to step (7).
Chen, et al. Expires August 3, 2016 [Page 10]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
(7) The DN of CDN B1 looks up the configuration table and determines,
according to the ProviderID, to acquire content from the DN of CDN
A1.
(8) The content in the DN of CDN A1 relays to the DN of CDN B1.
(9) The content in the DN of CDN B1 relays to the DN of CDN B2.
(10) The relayed content is served by the DN of CDN B2 to the End-
User via playing for downloading.
2.4.3. Test Results
Based on the experiment model above, we have tested the CDN
interconnection scenario in China Telecom's trial network where 1
Gbps video traffic is not hit in the local cache and content
acquisition is needed. Performance tests are done by using the tools
from Shineck and Spirent. We have made such operations as fast
forward, fast rewind and positioning play etc. The testing results
show that the response time is less than one second and the Max DF is
less than 50msec. Also we conducted the test for a period of six
hours for stability tests through complex operation of fast forward,
fast rewind, positioning play, etc. The tests results show that the
response time is less than one second and call loss is less that
0.1%. During the process of performance tests, the user requests the
video on demand and Live contents through set-up box and conducts
complex operation such as fast forward, fast rewind, positioning
play, etc. The program is smooth during the play. The tests show
that the CDN interconnection architecture for intra-operator video
service is both feasible and efficient.
2.5. Control
In the IETF CDNi draft [I-D.murray-cdni-triggers], the uCDN controls
the content operation, i.e., content adding, content purging and
content modifying are performed through the control interface. In
this section, we describe a general content control flow by using CDN
B1 and CDN B2 as an example which are used in this experiment.
Chen, et al. Expires August 3, 2016 [Page 11]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
+--------+ +--------+
| CDN B1 | | CDN B2 |
+--------+ +--------+
| |
|HTTP://dCDN IP:PORT/ContentDeployReq
|-----------------------> |
| |
|ContentDeployReqResponse |
|<----------------------- |
| |
| |
|Achieve XML through FTP |
|<----------------------- |
| |
| |
| |
|http://uCDN IP:PORT/ContentDeployResult
|<----------------------- |
| |
| |
| |
|ContentDeployResultResponse
|-----------------------> |
| |
| |
Figure 5 Message Exchange for Content Acquisition
The Message sequence of Figure 5 is shown below in details.
(1) CDN B1 sends a content management requests to the CDN B2
including the content adding, content purging and content modifying.
The content object can be live content, video on demand content or TV
on demand. The object of ContentDeployReq includes the URL address
of XML description of the content object.
(2) CDN B2 checks if the URL FTP address from CDN B1 is OK. If the
result is OK, CDN B2 responds positively (success) to the CDN B1.
(3) CDN B2 login in the FTP of CDN B1 to achieve the XML data of
content object and executes the operation according to the
instruction of CDN B1, i.e., content adding, content purging or
content modifying.
(4) CDN B2 responds to the CDN B1 for the operation results, i.e.,
with either a success or a failure result.
(5) CDN B1 confirms to the CDN B2 for the operation result and
registers the operation result.
Chen, et al. Expires August 3, 2016 [Page 12]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
3. Lessons Learned
The CDNi functionality tested in this experiment is applicable to
intra-operator case only. The inter-province service is ingested via
CDN in one province and can be used throughout the entire trial
network in two provinces. During the initial stage of CDNi
standardization, the most practical scenario to be considered is the
interconnection of CDNs distributed in different geographical regions
within one operator so as to enhance the consistency and continuity
of the services provided by operators themselves. Therefore, this
experiment is intended to provide some experiences and references on
CDNi networking to those operators who have initial requirements for
internal CDN interconnection across different geographical regions.
3.1. Simplification of operation procedures
It is demonstrated that relatively simple methods can be used to
simplify or optimize the Request Redirection, Content Acquisition,
Content Pre-Positioning, Content Addition/Modification/Deletion
procedures. This is conducive to operators when they also act as
service providers to serve the end users by fulfilling the
requirements of of real-time service and demanding user experience.
3.2. Redirection
According to the HTTP/DNS-based Request Routing process defined in
the current [RFC7336], multiple redirection processes are needed to
determine the final CDN node that is suitable to serve the end user.
This may be convenient in the case of two-level CDNs. But in case of
large-scale CDN networking or complex CDN topology, this would cause
serious delay. The method provided in this experiment, i.e., the one
based on the local configuration of the relationship table of end
users' IP addresses and load situation of dCDNs, the uCDN, as the
national content storage center, can quickly acquire and locate the
final dCDN that is suitable to serve the end user. By using this
technique, the routing selection can be largely simplified especially
when operators have large-scale internal networking.
3.3. UniContentID
In current IETF CDNi work [RFC7336], the content acquisition by dCDN
from uCDN is achieved via embedding the URL of the original request
as well as that of the CDN the request is redirected to during the
redirection process. This would result in a very long URL. Limited
by the length and format of URL, such approach would cause serious
delay and waste of resources. In addition, it would be difficult to
implement this, especially under the complex CDNi topology.
Chen, et al. Expires August 3, 2016 [Page 13]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
The unique content identification (named UniContentID in this
document) can be used to uniquely identify the content item ingested
by the content provider. The content source can also be resolved
from UniContentID contained in the end user's content request for
content acquisition. Due to the uniformity of UniContentID format
and its unchangeable nature during the transmission among CDNs, it
can all along identify the content requested by the end user even
after multiple forwards under complex CDNi topology. Note that these
introduce the need for defining a unique content identification for
content item in CDNi framework.
3.4. Metadata and Logging
The metadata related to CDNi content delivery are as discussed in [I-
D.ietf-cdni-metadata]. The policy information like content
ingestion, content acquisition, etc. can be obtained from pre-
configuration data. Also, since the scope of this experiment is one
operator, there may not be any need for obtaining charging-related
operations via logging interface. However, if needed the
specifications that are being developed in [I-D.ietf-cdni-logging]
would be useful.
3.5. Inter-Operator CDN Interconnection
For CDN interconnection across operators, if the operators are
clearly aware of each other's CDN framework (according to their
agreements), the method that is used in this experiment can also be
utilized as a reference, i.e., for implementing end user's request
redirection and content acquisition via maintaining the configuration
table, which can also achieve relatively high content delivery
efficiency. For those operators who have complicated internal CDN
topology or proprietary APIs or CDN topology, it is our view that it
requires to seek solutions for dynamic request redirection - as
discussed in [I-D.ietf-cdni-redirection] - and content acquisition.
4. Security Considerations
This experiment is carried out within a single operator. No security
issues are considered at this stage of the experiment.
5. IANA Considerations
There are no IANA considerations for this draft.
Chen, et al. Expires August 3, 2016 [Page 14]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
6. Acknowledgments
To be added later
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-21 (work in progress), November 2015.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 2015.
[I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection interface for CDN Interconnection", draft-
ietf-cdni-redirection-16 (work in progress), January 2016.
[I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDN Interconnect
Triggers", February 2012.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>.
Chen, et al. Expires August 3, 2016 [Page 15]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>.
Authors' Addresses
Ge Chen
China Telecom
109 West Zhongshan Ave
Guangzhou, Tianhe District
China
Email: cheng@gsta.com
Mian Li
ZTE Corporation
Nanjing 210012
China
Email: li.mian@zte.com.cn
Hongfei Xia
ZTE Corporation
Nanjing 210012
China
Email: xia.hongfei@zte.com.cn
Chen, et al. Expires August 3, 2016 [Page 16]
Internet-Draft Intra-CDN Provider CDNi Experiment January 2016
Bhumip Khasnabish
ZTE (TX) Inc.
USA
Phone: +001-781-752-8003
Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com
URI: http://tinyurl.com/bhumip/
Jie Liang
China Telecom
109 West Zhongshan Ave
Guangzhou, Tianhe District
China
Email: liangj@gsta.com
Chen, et al. Expires August 3, 2016 [Page 17]
