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]