Internet DRAFT - draft-chen-cdni-rr-content-acquisition
draft-chen-cdni-rr-content-acquisition
CDNI G. Chen
Internet-Draft China Telecom
Intended status: Informational M. Li
Expires: December 27, 2013 H. Xia
C. Zou
ZTE Corporation
J. Liang
China Telecom
June 25, 2013
Request Routing and Content Acquisition
draft-chen-cdni-rr-content-acquisition-02
Abstract
This document illustrates the details of an alternative method that
can be used to provide request routing and content acquisition
services.
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 27, 2013.
Copyright Notice
Copyright (c) 2013 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
Chen, et al. Expires December 27, 2013 [Page 1]
Internet-Draft Request Routing and Content Acquisition June 2013
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. Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. CDN Interconnection Framework . . . . . . . . . . . . . . 3
2.2. UniContentID . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Use Case Description . . . . . . . . . . . . . . . . . . . 7
2.3.1. Request Routing and Content Delivery . . . . . . . . . 7
2.3.2. Content Acquisition . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Chen, et al. Expires December 27, 2013 [Page 2]
Internet-Draft Request Routing and Content Acquisition June 2013
1. Introduction
The scope of CDNi work is described in [I-D.ietf-cdni-problem-
statement]:
- As illustrated in Figure 1, the acquisition of content between
interconnected CDNs is out of scope of CDNi, which deserves some
additional explanation. The consequence of such a decision is that
the CDNi problem space described in this document only focuses on
defining the CDNi control plane; and the CDNi data plane (i.e., the
acquisition and distribution of the actual content objects) is out of
scope.
It can be implied that the delivery process of the actual content
objects requested by the end user from uCDN to dCDN is outside the
scope of CDNi work. However, in the cache miss case, i.e., the dCDN
receives end user's request redirected by the uCDN and fails in
locating the corresponding content in the cache, the dCDN needs to
determine toward which uCDN it should initiate the content
acquisition procedure. And this should be included in scope of CDNi.
This document illustrates the mechanism of request routing and
content acquisition between uCDN and dCDN on the basis of Content
Identification.
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:
[I-D.draft-ietf-cdni-problem-statement-06],
[I-D.draft-ietf-cdni-requirements-03],
[I-D.draft-ietf-cdni-framework-00], and
[I-D.draft-ietf-cdni-use-cases-08].
2. Prerequisite
2.1. CDN Interconnection Framework
In the CDNi framework, the procedure of end user's content request to
the uCDN and the content delivery from the dCDN involves two sub-
Chen, et al. Expires December 27, 2013 [Page 3]
Internet-Draft Request Routing and Content Acquisition June 2013
procedures: Request Routing and Content Acquisition. The method used
in [I-D.ietf-cdni-framework] is that the CDN operators pre-agree for
using 'distinguished' CDN-domains and embed them in URLs that end
users request. The example used is a CDN-domain peer-a.op-b.net that
will be used as the target of redirections from uCDN to dCDN and a
CDN-domain op-b-acq.op-a.net that will be used for inter-CDN
acquisition of CSP's content from uCDN by dCDN.
When the CDNi framework has even complex topology, i.e., in the case
of cascaded CDNs, in order to record the redirection route of the
request message, all the redirection routing information is required
to be included in the URL, which 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, and it would be difficult to
implement this. In addition, in the process of request message
redirection, there is possibility that the URL is modified by a CDN
which may lead to inaccuracy of the redirection and content
acquisition information.
This document introduces a content identification parameter called
'UniContentID' to uniquely identify a content item, the details of
which are illustrated in Section 2.2. This document also makes use
of a static configuration mechanism, i.e., every CDN provides a fixed
URL or IP address for other CDNs to download content from. This
fixed URL or IP address is valid to all CDNs and all request messages
sent to this address are considered as content downloading requests.
By doing this, the change of request URL during multiple redirection
processes can be avoided, and it would also accelerate the process of
locating corresponding uCDN and the content item requested by the end
user. This method is easy to implement and can be used in cascaded
CDNs scenario.
Editor's Note: The mechanism for using dynamic mechanism to acquire
the URL or IP address of uCDN for content downloading is FFS.
Chen, et al. Expires December 27, 2013 [Page 4]
Internet-Draft Request Routing and Content Acquisition June 2013
+------+
| CP |
+------+ :
| :
| :
_,.---.,, : _,.---.,
.` `. : .` `.
' \ : ' \
| uCDN |---:---- | dCDN |
, / ---:---- , /
', ,- : ', ,-
``''--'`` : ``''--'``
: |
: |
: +------+
: | EU B |
: +------+
Provider A : Provider B
:
:
:
Figure 1 Interconnection of uCDN and dCDN
2.2. UniContentID
Given that the CDN needs to support the requirements for ingesting
content to multi-screen for the same CMS (as described in ITU-T
Y.1910 IPTV Functional Architecture), we need to define a two-tuple,
i.e., the parameter of UniContentID to uniquely identify different
CMSs.
UniConentID is defined by a two-tuple as (ProviderID, ContentID),
which uniquely identifies only one content item in the CDN. Here the
parameter ContentID denotes only one content item in a specific
domain of a CMS. The parameter ProviderID is defined as the provider
for a specific domain and is only for a specific CMS in a specific
domain. We define the configuration table in the CDN which needs to
be used in the request routing as follows:
* CMSID: refers to the DNS name or IP address of the CMS.
* Domain: refers to the different identifiers for IPTV service, PC
service and mobile service etc. For example, we define 0 for IPTV
service, 1 for PC service, 2 for mobile service and 3 for other
services reserved.
* ProviderID: refers to the identifier of a content provider in a
specific domain, which is unique in this configuration table. For
Chen, et al. Expires December 27, 2013 [Page 5]
Internet-Draft Request Routing and Content Acquisition June 2013
the same parameter of CMSID, different parameter of Domain indicates
different parameters of ProviderID.
* ProviderType: refers to the provider type (B2B service or B2C
service). For example, we define 1 for B2B and 2 for B2C.
* PlaybackURLprefix: refers to the prefix of the specific content
service URL of the portal. There is a one-to-one relationship
between PlaybackURLpredix and ProviderID. For example, if the URL is
http://video.netitv.com/01234567890123456789012345678900?..., the
PlaybackURLpredix is video.netitv.com.
* ContentURLParseRule: refers to the resolution rules for the content
item identified by the URL and ContentID in a regular way of
expression.
+---------------------------------------------------------------+
|CMSID| Domain| ProviderID| Provider Type| Playback | ContentURL|
| URLPrefix ParseRule |
+---------------------------------------------------------------+
Figure 2 The Configuration Table
Example 1: ProviderID matched by CMSID and Domain
In the configuration table for IPTV service of a specific CMS, we set
the ProviderID to iptv.netitv.com and CMSID to '10.17.45.233'. Then
one content is ingested to the CDN and the ContentID is
'01234567890123456789012345678900'. Domain is '0'. The two tuple of
UniContentID is
('iptv.netitv.com','01234567890123456789012345678900').
In the website portal, the URL of the content serving is 'RTSP RR IP:
PORT/ ContentID?CMSID=XXX &Domain=XXX...'. When the streaming server
receives the URL, it will analyse the ProviderID which is set to
'iptv.netitv.com' by looking up the configuration table. Then the
two tuple UniContentID is('iptv.netitv.com',
'01234567890123456789012345678900'). The content can be requested in
the local cache if the cache hits or be relayed from the uCDN if the
cache does not hit.
Example 2: ProviderID matched for mobile service
In the configuration table for mobile service of specific CMS, we set
the ProviderID to mobile.netitv.com and the PlaybackURLPrefix to
'mobile.netitv.com'. Then one content is ingested to the CDN and the
Chen, et al. Expires December 27, 2013 [Page 6]
Internet-Draft Request Routing and Content Acquisition June 2013
ContentID is '01234567890123456789012345678900'. Domain is '2'. The
two tuple of UniContentID is ('mobile.netitv.com',
'01234567890123456789012345678900').
In the website portal, the URL of the content serving is 'RTSP://
mobile.netitv.com/01234567890123456789012345678900?...'. When the
streaming server receives the URL, it will analyse the
PlaybackURLprefix which is set to 'mobile.netitv.com' and find that
the ProviderID is 'mobile.netitv.com' by looking up the configuration
table. Then the two tuple UniContentID is ('mobile.netitv.com', '
01234567890123456789012345678900'). The content can be requested in
the local cache if cache hits or be relayed from the uCDN if the
cache does not hit.
Example 3: ProviderID matched for PC service
In the configuration table for mobile service of specific CMS, we set
the ProviderID to pc.netitv.com and PlaybackURLPrefix
to'video.netitv.com'. Then one content is ingested to the CDN and
the ContentID is '01234567890123456789012345678900'. Domain is '1'.
The two tuple of UniContentID is ('pc.netitv.com',
'01234567890123456789012345678900').
In the website portal, the URL of the content serving is 'http://
video.netitv.com/01234567890123456789012345678900?...'. When the
streaming server receives the URL, it will analyses the
PlaybackURLprefix which is set to 'video.netitv.com' and find that
the ProviderID is 'pc.netitv.com' by looking up the configuration
table. Then the two tuple UniContentID is ('pc.netitv.com', '
01234567890123456789012345678900'). The content can be requested in
the local cache if cache hits or be relayed from the uCDN if the
cache does not hit.
2.3. Use Case Description
2.3.1. Request Routing and Content Delivery
Chen, et al. Expires December 27, 2013 [Page 7]
Internet-Draft Request Routing and Content Acquisition June 2013
+------------------+
| dCDN |
+-----+ +------+ |+------+ +------+ |
| EU | | uCDN | || dCDN | | dCDN | |
+-----+ +------+ || RR | | DN | |
| | |+------+ +------+||
| | +------------------+
RTSP or HTTP://uCDN RR IP:Port/ContentID? |
|-------------->| | |
|CMSID=XXX&domain=XXX... | |
| | | |
| | | |
|302 dCDN RR IP:Port/ | |
|<--------------| | |
|ContentID?CMSID=XXX&domain=XXX... |
| | | |
| | | |
|RTSP or HTTP://dCDN RR IP:Port/ContentID?
|------------------------------>| |
| CMSID=XXX&domain=XXX... | |
| | | |
| IPaddr of dCDN's Delivery Node |
|<------------------------------| |
| | | |
| | | |
| RTSP or HTTP://dCDN DN IP:Port/ |
|--------------------------------------->|
| ContentID?CMSID=XXX&domain=XXX... |
| | | |
| | | |
Figure 3 Message Exchange for Request Routing
1. A Request Router of uCDN processes the RTSP or HTTP request and
recognizes that the end-user is best served by another CDN. It
returns the IP address of dCDN.
2. uCDN returns a 302 redirection message with a new URL including
the IP address of dCDN.
3. The end-user then sends the request to the Request Router of dCDN
(i.e. dCDN RR). dCDN RR returns the IP address of corresponding
delivery node.
4. dCDN RR returns a new URL including the IP address of dCDN DN.
Note that, since the name of the delivery node was already obtained
from dCDN (i.e. dCDN DN), there should not be any further redirection
here.
Chen, et al. Expires December 27, 2013 [Page 8]
Internet-Draft Request Routing and Content Acquisition June 2013
5. The end-user requests the content from dCDN's delivery
node,potentially resulting in a cache miss. In the case of cache
miss, the content needs to be acquired from uCDN (not the CSP), which
is described in the following section.
2.3.2. Content Acquisition
+-----+ +------+ +-----+ +------+
| EU | | uCDN | | mCDN| | dCDN |
+-----+ +------+ +-----+ +------+
| | | |
| | RTSP or HTTP://mCDN IP:Port/
| | |<-------------|
| | ContentID?ProviderID=XXX...
| | | |
| RTSP HTTP://uCDN IP:Port/ |
| |<------------| |
| ContentID?ProviderID=XXX... |
| | | |
| Content Acquisition Relay |
| |------------>| |
| | |Content Acquisition Relay
| | |------------> |
| | | |
| | | |
| | | |
| | DATA | |
|<-----------------------------------------|
| | | |
Figure 4 Message Exchange for Content Acquisition
1. The request router of dCDN processes the request from the end-
user and forwards the request to the request router of mCDN. Note
that the dCDN needs to obtain the ProviderID information by looking
up the configuration table. The ProviderID and ContentID information
can uniquely identify a content.
2. The request router of mCDN finds a cache miss case in the
delivery nodes of mCDN. It forwards the request to the request
router of uCDN for the content.
3. The request router of uCDN finds that the content is cached in
the delivery node of uCDN, then the delivery node of uCDN delivers
the content to the delivery node of mCDN.
Chen, et al. Expires December 27, 2013 [Page 9]
Internet-Draft Request Routing and Content Acquisition June 2013
4. The delivery node of mCDN delivers the content to the delivery
node of dCDN.
5. The delivery node of dCDN delivers the content to the end-user.
Note: The content acquisition interface in step 3~5 needs to be
standardized.
3. Security Considerations
To be added later
4. IANA Considerations
This memo has no IANA Considerations.
5. Acknowledgments
To be added later
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", April 2012.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", May 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", December 2011.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
Chen, et al. Expires December 27, 2013 [Page 10]
Internet-Draft Request Routing and Content Acquisition June 2013
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", June 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,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
Authors' Addresses
Ge Chen
China Telecom
109 West Zhongshan Ave
Guangzhou, Tianhe District
China
Phone:
Email: cheng@gsta.com
Mian Li
ZTE Corporation
Nanjing, 210012
China
Phone:
Email: li.mian@zte.com.cn
Hongfei Xia
ZTE Corporation
Nanjing, 210012
China
Phone:
Email: xia.hongfei@zte.com.cn
Chen, et al. Expires December 27, 2013 [Page 11]
Internet-Draft Request Routing and Content Acquisition June 2013
Changle Zou
ZTE Corporation
Nanjing, 210012
China
Phone:
Email: zou.changle@zte.com.cn
Jie Liang
China Telecom
109 West Zhongshan Ave
Guangzhou, Tianhe District
China
Phone:
Email: liangj@gsta.com
Chen, et al. Expires December 27, 2013 [Page 12]
