idnits 2.17.1 draft-chen-cdni-rr-content-acquisition-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 25, 2013) is 3920 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-cdni-problem-statement-06' is mentioned on line 104, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-requirements-03' is mentioned on line 106, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-framework-00' is mentioned on line 108, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-use-cases-08' is mentioned on line 110, but not defined == Unused Reference: 'I-D.ietf-cdni-problem-statement' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 434, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI G. Chen 3 Internet-Draft China Telecom 4 Intended status: Informational M. Li 5 Expires: December 27, 2013 H. Xia 6 C. Zou 7 ZTE Corporation 8 J. Liang 9 China Telecom 10 June 25, 2013 12 Request Routing and Content Acquisition 13 draft-chen-cdni-rr-content-acquisition-02 15 Abstract 17 This document illustrates the details of an alternative method that 18 can be used to provide request routing and content acquisition 19 services. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 27, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. CDN Interconnection Framework . . . . . . . . . . . . . . 3 59 2.2. UniContentID . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Use Case Description . . . . . . . . . . . . . . . . . . . 7 61 2.3.1. Request Routing and Content Delivery . . . . . . . . . 7 62 2.3.2. Content Acquisition . . . . . . . . . . . . . . . . . 9 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 The scope of CDNi work is described in [I-D.ietf-cdni-problem- 74 statement]: 76 - As illustrated in Figure 1, the acquisition of content between 77 interconnected CDNs is out of scope of CDNi, which deserves some 78 additional explanation. The consequence of such a decision is that 79 the CDNi problem space described in this document only focuses on 80 defining the CDNi control plane; and the CDNi data plane (i.e., the 81 acquisition and distribution of the actual content objects) is out of 82 scope. 84 It can be implied that the delivery process of the actual content 85 objects requested by the end user from uCDN to dCDN is outside the 86 scope of CDNi work. However, in the cache miss case, i.e., the dCDN 87 receives end user's request redirected by the uCDN and fails in 88 locating the corresponding content in the cache, the dCDN needs to 89 determine toward which uCDN it should initiate the content 90 acquisition procedure. And this should be included in scope of CDNi. 92 This document illustrates the mechanism of request routing and 93 content acquisition between uCDN and dCDN on the basis of Content 94 Identification. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 This document reuses the terminology defined in: 104 [I-D.draft-ietf-cdni-problem-statement-06], 106 [I-D.draft-ietf-cdni-requirements-03], 108 [I-D.draft-ietf-cdni-framework-00], and 110 [I-D.draft-ietf-cdni-use-cases-08]. 112 2. Prerequisite 114 2.1. CDN Interconnection Framework 116 In the CDNi framework, the procedure of end user's content request to 117 the uCDN and the content delivery from the dCDN involves two sub- 118 procedures: Request Routing and Content Acquisition. The method used 119 in [I-D.ietf-cdni-framework] is that the CDN operators pre-agree for 120 using 'distinguished' CDN-domains and embed them in URLs that end 121 users request. The example used is a CDN-domain peer-a.op-b.net that 122 will be used as the target of redirections from uCDN to dCDN and a 123 CDN-domain op-b-acq.op-a.net that will be used for inter-CDN 124 acquisition of CSP's content from uCDN by dCDN. 126 When the CDNi framework has even complex topology, i.e., in the case 127 of cascaded CDNs, in order to record the redirection route of the 128 request message, all the redirection routing information is required 129 to be included in the URL, which would result in a very long URL. 130 Limited by the length and format of URL, such approach would cause 131 serious delay and waste of resources, and it would be difficult to 132 implement this. In addition, in the process of request message 133 redirection, there is possibility that the URL is modified by a CDN 134 which may lead to inaccuracy of the redirection and content 135 acquisition information. 137 This document introduces a content identification parameter called 138 'UniContentID' to uniquely identify a content item, the details of 139 which are illustrated in Section 2.2. This document also makes use 140 of a static configuration mechanism, i.e., every CDN provides a fixed 141 URL or IP address for other CDNs to download content from. This 142 fixed URL or IP address is valid to all CDNs and all request messages 143 sent to this address are considered as content downloading requests. 144 By doing this, the change of request URL during multiple redirection 145 processes can be avoided, and it would also accelerate the process of 146 locating corresponding uCDN and the content item requested by the end 147 user. This method is easy to implement and can be used in cascaded 148 CDNs scenario. 150 Editor's Note: The mechanism for using dynamic mechanism to acquire 151 the URL or IP address of uCDN for content downloading is FFS. 153 +------+ 154 | CP | 155 +------+ : 156 | : 157 | : 158 _,.---.,, : _,.---., 159 .` `. : .` `. 160 ' \ : ' \ 161 | uCDN |---:---- | dCDN | 162 , / ---:---- , / 163 ', ,- : ', ,- 164 ``''--'`` : ``''--'`` 165 : | 166 : | 167 : +------+ 168 : | EU B | 169 : +------+ 170 Provider A : Provider B 171 : 172 : 173 : 174 Figure 1 Interconnection of uCDN and dCDN 176 2.2. UniContentID 178 Given that the CDN needs to support the requirements for ingesting 179 content to multi-screen for the same CMS (as described in ITU-T 180 Y.1910 IPTV Functional Architecture), we need to define a two-tuple, 181 i.e., the parameter of UniContentID to uniquely identify different 182 CMSs. 184 UniConentID is defined by a two-tuple as (ProviderID, ContentID), 185 which uniquely identifies only one content item in the CDN. Here the 186 parameter ContentID denotes only one content item in a specific 187 domain of a CMS. The parameter ProviderID is defined as the provider 188 for a specific domain and is only for a specific CMS in a specific 189 domain. We define the configuration table in the CDN which needs to 190 be used in the request routing as follows: 192 * CMSID: refers to the DNS name or IP address of the CMS. 194 * Domain: refers to the different identifiers for IPTV service, PC 195 service and mobile service etc. For example, we define 0 for IPTV 196 service, 1 for PC service, 2 for mobile service and 3 for other 197 services reserved. 199 * ProviderID: refers to the identifier of a content provider in a 200 specific domain, which is unique in this configuration table. For 201 the same parameter of CMSID, different parameter of Domain indicates 202 different parameters of ProviderID. 204 * ProviderType: refers to the provider type (B2B service or B2C 205 service). For example, we define 1 for B2B and 2 for B2C. 207 * PlaybackURLprefix: refers to the prefix of the specific content 208 service URL of the portal. There is a one-to-one relationship 209 between PlaybackURLpredix and ProviderID. For example, if the URL is 210 http://video.netitv.com/01234567890123456789012345678900?..., the 211 PlaybackURLpredix is video.netitv.com. 213 * ContentURLParseRule: refers to the resolution rules for the content 214 item identified by the URL and ContentID in a regular way of 215 expression. 217 +---------------------------------------------------------------+ 218 |CMSID| Domain| ProviderID| Provider Type| Playback | ContentURL| 219 | URLPrefix ParseRule | 220 +---------------------------------------------------------------+ 222 Figure 2 The Configuration Table 224 Example 1: ProviderID matched by CMSID and Domain 226 In the configuration table for IPTV service of a specific CMS, we set 227 the ProviderID to iptv.netitv.com and CMSID to '10.17.45.233'. Then 228 one content is ingested to the CDN and the ContentID is 229 '01234567890123456789012345678900'. Domain is '0'. The two tuple of 230 UniContentID is 231 ('iptv.netitv.com','01234567890123456789012345678900'). 233 In the website portal, the URL of the content serving is 'RTSP RR IP: 234 PORT/ ContentID?CMSID=XXX &Domain=XXX...'. When the streaming server 235 receives the URL, it will analyse the ProviderID which is set to 236 'iptv.netitv.com' by looking up the configuration table. Then the 237 two tuple UniContentID is('iptv.netitv.com', 238 '01234567890123456789012345678900'). The content can be requested in 239 the local cache if the cache hits or be relayed from the uCDN if the 240 cache does not hit. 242 Example 2: ProviderID matched for mobile service 244 In the configuration table for mobile service of specific CMS, we set 245 the ProviderID to mobile.netitv.com and the PlaybackURLPrefix to 246 'mobile.netitv.com'. Then one content is ingested to the CDN and the 247 ContentID is '01234567890123456789012345678900'. Domain is '2'. The 248 two tuple of UniContentID is ('mobile.netitv.com', 249 '01234567890123456789012345678900'). 251 In the website portal, the URL of the content serving is 'RTSP:// 252 mobile.netitv.com/01234567890123456789012345678900?...'. When the 253 streaming server receives the URL, it will analyse the 254 PlaybackURLprefix which is set to 'mobile.netitv.com' and find that 255 the ProviderID is 'mobile.netitv.com' by looking up the configuration 256 table. Then the two tuple UniContentID is ('mobile.netitv.com', ' 257 01234567890123456789012345678900'). The content can be requested in 258 the local cache if cache hits or be relayed from the uCDN if the 259 cache does not hit. 261 Example 3: ProviderID matched for PC service 263 In the configuration table for mobile service of specific CMS, we set 264 the ProviderID to pc.netitv.com and PlaybackURLPrefix 265 to'video.netitv.com'. Then one content is ingested to the CDN and 266 the ContentID is '01234567890123456789012345678900'. Domain is '1'. 267 The two tuple of UniContentID is ('pc.netitv.com', 268 '01234567890123456789012345678900'). 270 In the website portal, the URL of the content serving is 'http:// 271 video.netitv.com/01234567890123456789012345678900?...'. When the 272 streaming server receives the URL, it will analyses the 273 PlaybackURLprefix which is set to 'video.netitv.com' and find that 274 the ProviderID is 'pc.netitv.com' by looking up the configuration 275 table. Then the two tuple UniContentID is ('pc.netitv.com', ' 276 01234567890123456789012345678900'). The content can be requested in 277 the local cache if cache hits or be relayed from the uCDN if the 278 cache does not hit. 280 2.3. Use Case Description 282 2.3.1. Request Routing and Content Delivery 283 +------------------+ 284 | dCDN | 285 +-----+ +------+ |+------+ +------+ | 286 | EU | | uCDN | || dCDN | | dCDN | | 287 +-----+ +------+ || RR | | DN | | 288 | | |+------+ +------+|| 289 | | +------------------+ 290 RTSP or HTTP://uCDN RR IP:Port/ContentID? | 291 |-------------->| | | 292 |CMSID=XXX&domain=XXX... | | 293 | | | | 294 | | | | 295 |302 dCDN RR IP:Port/ | | 296 |<--------------| | | 297 |ContentID?CMSID=XXX&domain=XXX... | 298 | | | | 299 | | | | 300 |RTSP or HTTP://dCDN RR IP:Port/ContentID? 301 |------------------------------>| | 302 | CMSID=XXX&domain=XXX... | | 303 | | | | 304 | IPaddr of dCDN's Delivery Node | 305 |<------------------------------| | 306 | | | | 307 | | | | 308 | RTSP or HTTP://dCDN DN IP:Port/ | 309 |--------------------------------------->| 310 | ContentID?CMSID=XXX&domain=XXX... | 311 | | | | 312 | | | | 314 Figure 3 Message Exchange for Request Routing 316 1. A Request Router of uCDN processes the RTSP or HTTP request and 317 recognizes that the end-user is best served by another CDN. It 318 returns the IP address of dCDN. 320 2. uCDN returns a 302 redirection message with a new URL including 321 the IP address of dCDN. 323 3. The end-user then sends the request to the Request Router of dCDN 324 (i.e. dCDN RR). dCDN RR returns the IP address of corresponding 325 delivery node. 327 4. dCDN RR returns a new URL including the IP address of dCDN DN. 328 Note that, since the name of the delivery node was already obtained 329 from dCDN (i.e. dCDN DN), there should not be any further redirection 330 here. 332 5. The end-user requests the content from dCDN's delivery 333 node,potentially resulting in a cache miss. In the case of cache 334 miss, the content needs to be acquired from uCDN (not the CSP), which 335 is described in the following section. 337 2.3.2. Content Acquisition 339 +-----+ +------+ +-----+ +------+ 340 | EU | | uCDN | | mCDN| | dCDN | 341 +-----+ +------+ +-----+ +------+ 342 | | | | 343 | | RTSP or HTTP://mCDN IP:Port/ 344 | | |<-------------| 345 | | ContentID?ProviderID=XXX... 346 | | | | 347 | RTSP HTTP://uCDN IP:Port/ | 348 | |<------------| | 349 | ContentID?ProviderID=XXX... | 350 | | | | 351 | Content Acquisition Relay | 352 | |------------>| | 353 | | |Content Acquisition Relay 354 | | |------------> | 355 | | | | 356 | | | | 357 | | | | 358 | | DATA | | 359 |<-----------------------------------------| 360 | | | | 362 Figure 4 Message Exchange for Content Acquisition 364 1. The request router of dCDN processes the request from the end- 365 user and forwards the request to the request router of mCDN. Note 366 that the dCDN needs to obtain the ProviderID information by looking 367 up the configuration table. The ProviderID and ContentID information 368 can uniquely identify a content. 370 2. The request router of mCDN finds a cache miss case in the 371 delivery nodes of mCDN. It forwards the request to the request 372 router of uCDN for the content. 374 3. The request router of uCDN finds that the content is cached in 375 the delivery node of uCDN, then the delivery node of uCDN delivers 376 the content to the delivery node of mCDN. 378 4. The delivery node of mCDN delivers the content to the delivery 379 node of dCDN. 381 5. The delivery node of dCDN delivers the content to the end-user. 383 Note: The content acquisition interface in step 3~5 needs to be 384 standardized. 386 3. Security Considerations 388 To be added later 390 4. IANA Considerations 392 This memo has no IANA Considerations. 394 5. Acknowledgments 396 To be added later 398 6. References 400 6.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 6.2. Informative References 407 [I-D.ietf-cdni-framework] 408 Peterson, L. and B. Davie, "Framework for CDN 409 Interconnection", April 2012. 411 [I-D.ietf-cdni-problem-statement] 412 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 413 Distribution Network Interconnection (CDNI) Problem 414 Statement", May 2012. 416 [I-D.ietf-cdni-requirements] 417 Leung, K. and Y. Lee, "Content Distribution Network 418 Interconnection (CDNI) Requirements", December 2011. 420 [I-D.ietf-cdni-use-cases] 421 Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 422 K., and G. Watson, "Use Cases for Content Delivery Network 423 Interconnection", June 2012. 425 [I-D.narten-iana-considerations-rfc2434bis] 426 Narten, T. and H. Alvestrand, "Guidelines for Writing an 427 IANA Considerations Section in RFCs", 428 draft-narten-iana-considerations-rfc2434bis-09 (work in 429 progress), March 2008. 431 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 432 June 1999. 434 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 435 Text on Security Considerations", BCP 72, RFC 3552, 436 July 2003. 438 Authors' Addresses 440 Ge Chen 441 China Telecom 442 109 West Zhongshan Ave 443 Guangzhou, Tianhe District 444 China 446 Phone: 447 Email: cheng@gsta.com 449 Mian Li 450 ZTE Corporation 451 Nanjing, 210012 452 China 454 Phone: 455 Email: li.mian@zte.com.cn 457 Hongfei Xia 458 ZTE Corporation 459 Nanjing, 210012 460 China 462 Phone: 463 Email: xia.hongfei@zte.com.cn 464 Changle Zou 465 ZTE Corporation 466 Nanjing, 210012 467 China 469 Phone: 470 Email: zou.changle@zte.com.cn 472 Jie Liang 473 China Telecom 474 109 West Zhongshan Ave 475 Guangzhou, Tianhe District 476 China 478 Phone: 479 Email: liangj@gsta.com