idnits 2.17.1 draft-chen-cdni-intra-cdn-provider-cdni-experiment-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-cdni-use-cases]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 2, 2012) is 4192 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 123, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-requirements-03' is mentioned on line 125, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-framework-00' is mentioned on line 127, but not defined == Missing Reference: 'I-D.draft-ietf-cdni-use-cases-08' is mentioned on line 129, but not defined == Missing Reference: 'I-D.draft-chen-cdni-rr-content-acquisition' is mentioned on line 290, but not defined == Unused Reference: 'I-D.ietf-cdni-problem-statement' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 639, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 12 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: May 6, 2013 H. Xia 6 B. Khasnabish 7 ZTE Corporation 8 J. Liang 9 China Telecom 10 November 2, 2012 12 Intra-CDN Provider CDNi Experiment 13 draft-chen-cdni-intra-cdn-provider-cdni-experiment-01 15 Abstract 17 In [I-D.ietf-cdni-use-cases], the Inter-Affiliates CDN 18 Interconnection use case is described. In this scenario, a large CDN 19 Provider may have several autonomous or semi-autonomous subsidiaries 20 that each operates on their own CDN. The CDN Provider needs to make 21 these down-stream CDNs interoperate to provide a consistent service 22 to its customers on the whole collective footprint. 24 This document illustrates in details the CDNi experiment that has 25 been carried out by China Telecom, and the lessons and experiences to 26 CDNi standardization work. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 6, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Intra-CDN Provider CDNi Experiments . . . . . . . . . . . . . 3 65 2.1. Experiment Configuration . . . . . . . . . . . . . . . . . 4 66 2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4. Request Routing and Content Acquisition . . . . . . . . . 8 69 2.4.1. Request Routing and Content Acquisition in 70 Province B . . . . . . . . . . . . . . . . . . . . . . 8 71 2.4.2. Request Routing and Content Acquisition between 72 Province A and Province B . . . . . . . . . . . . . . 10 73 2.4.3. Test Results . . . . . . . . . . . . . . . . . . . . . 12 74 2.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.1. Simplification of operation procedures . . . . . . . . . . 14 77 3.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 14 78 3.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . . 14 79 3.4. Metadata and Logging . . . . . . . . . . . . . . . . . . . 15 80 3.5. Inter-Operator CDN Interconnection . . . . . . . . . . . . 15 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 As a CDN service provider, China Telecom has established video CDNs 92 in more than ten provinces in China. These video CDNs, provided by 93 different vendors, are relatively independent and only provide 94 services to the end users of their own provinces. Under this 95 circumstance, if a Content Provider (CP) wants to provide services to 96 multiple provinces, it needs to interact with CDNs in other provinces 97 via interfaces which may support different standards. 99 In 2011, China Telecom launched the CDN interconnection trial network 100 where CDNs from six different vendors (ZTE, Huawei, Cisco, etc.) were 101 used to conduct the interconnection experiment in three provinces. 102 This experiment aims at testing the scenario where the operator 103 provides autonomous services via CDN interconnection in order to 104 provide enhanced user experience. It is noted that a simplification 105 of the interconnection framework and the corresponding procedures 106 would really improve the service and real-time viewing experience. 108 This experiment is not intended to cover all of the use cases or the 109 scenarios that are within the scope of CDNi work. It simply provides 110 some practical information gathered from the actual network 111 experiment as a reference to the CDNi standardization work. These 112 CDN interconnection implementation experiments cover mostly the 113 intra-operator interconnection scenarios. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 This document reuses the terminology defined in: 123 [I-D.draft-ietf-cdni-problem-statement-06], 125 [I-D.draft-ietf-cdni-requirements-03], 127 [I-D.draft-ietf-cdni-framework-00], and 129 [I-D.draft-ietf-cdni-use-cases-08]. 131 2. Intra-CDN Provider CDNi Experiments 132 2.1. Experiment Configuration 134 The interconnection of four CDNs in two provinces has been tested in 135 this experiment. Each province has two CDNs interconnected which are 136 provided by different CDN vendors. As depicted in Figure 1, CDN A1 137 of Province A has contracts with service providers CP1 and CP2, and 138 it acts as the content storage center of the nation.CDN B1 of 139 Province B has contract with service provider CP3. Meanwhile, CDN A1 140 and CDN B1 are the sub-center CDNs of respective province, while CDN 141 A2 and CDN B2 are the regional CDNs of respective province. CDN A1 142 and CDN B1 are deployed on the provincial backbone networks, while 143 CDN A2 and CDN B2 are deployed on the MANs. CDN A1 is the upstream 144 CDN of CDN A2. Services are provided to the end users by certain 145 node in regional CDN, which is usually the geographically closest one 146 to the end user. However, if this desired node is overloaded, 147 certain re-routing or load-balancing criteria could be used to choose 148 another node. CDN B1 and CDN B2 have similar deployment. The 149 provincial center CDN A1 and CDN B1 are interconnected with each 150 other. They do not have interconnection with the region CDNs in 151 other provinces than themselves. The regional CDNs of the respective 152 provinces do not interconnect with one another either. 154 China Telecom's CDN trial network offers two types of services: 155 intra-province service (provided by CP2 and CP3) and inter-province 156 service (provided by CP1). Intra-province service is provided 157 independently within the province without any interconnection with 158 CDNs in other provinces. When inter-province service is provided, 159 content is ingested to the CDN in a single province and then 160 distributed among the CDNs in all other provinces in the trial 161 network. In this experiment the inter-province service is ingested 162 via CDN A1 node and the end users can obtain services through the 163 CDNs that are located in their own provinces. 165 +------+ 166 | CP1 | 167 +------+ +-----+ 168 +------+ / | CP3 | 169 | CP2 | / +-----+ 170 +------+ / : / 171 \ / : / 172 \ / : / 173 \ : 174 _,.---.,, : _,.---.,, 175 .` `. : .` `. 176 ' \ : ' \ 177 | CDN A1 |---:---- | CDN B1 | 178 , / ---:---- , / 179 ', ,- : ', ,- 180 ``''--'`` : ``''--'`` 181 | | : | | 182 | | : | | 183 | | : | | 184 _,.---.,, : _,.---.,, 185 .` `. : .` `. 186 ' \ : ' \ 187 | CDN A2 | : | CDN B2 | 188 , / : , / 189 ', ,- : ', ,- 190 ``''--'`` : ``''--'`` 191 : 192 Pronvince A : Province B 193 : 195 Figure 1 CDNI between Two Different Provinces, each with Two CDNs 197 The details of the experiment are as presented below: 199 CP3 has contract with CDN B1 to provide content delivery service, 200 e.g., IPTV service, to the end users in the Province B region. CP3 201 does not serve end users outside Province B. As an autonomous service 202 by China Telecom, the content of this service is ingested into CDN 203 B1. As its downstream CDN, CDN B1 can delegate the content requests 204 from end users to CDN B2 to perform content delivery. 206 When CDN B1 receives the content request from EU B of Province B 207 related to service provided by CP3, it redirects this request to CDN 208 B2. If CDN B2 has locally cached the copy of the content requested 209 by EU B (cache hit case), it serves EU B directly by delivering the 210 content to EU B. If CDN B2 does not have the content cached (cache 211 miss case), it acquires the content from CDN B1. 213 CP1 has contract with CDN A1 to provide content delivery service, 214 e.g., OTT service, to end users within Province A and in the region 215 of Province B. The content for this service is ingested from CDN A1. 216 As for the cross-province routing, since it is within the same 217 operator, static configuration can be used for dCDN selection. In 218 this experiment, the national content storage center CDN A1 219 configures locally the relationship table of the end user's IP 220 addresses and the loading condition of dCDNs. 222 When CDN A1 receives a content request from EU B of Province B, it 223 redirects the request to CDN B2 directly after it checks the local 224 configuration table without going through multiple redirection 225 processes like CDN A1->CDN B1->CDN B2. If CDN B2 has locally cached 226 a copy of the content that has been requested by EU B (cache hit 227 case), it serves EU B directly by delivering the content to EU B. If 228 CDN B2 does not have the content cached (cache miss case), it 229 acquires the content from CDN B1. If CDN B1 does not have the 230 content cached either, it acquires the content from CDN A1. 232 In this experiment, we use a content acquisition method that is 233 different from the current CDNi work. The method is based on Content 234 Identification by using UniContentID that is defined to uniquely 235 identify a content item. A detailed description of this method is 236 presented in Section 2.3. 238 +------+ 239 | CP1 | 240 +------+ +-----+ 241 / | CP3 | 242 / +-----+ 243 / : / 244 / : / 245 / : / 246 : 247 _,.---.,, : _,.---.,, 248 .` `. : .` `. 249 ' \ : ' \ 250 | CDN A1 |---:---- | CDN B1 | 251 , / ---:---- , / 252 ', ,- : ', ,- 253 ``''--'`` : ``''--'`` 254 | | : | | 255 | | : | | 256 | | : | | 257 _,.---.,, : _,.---.,, 258 .` `. : .` `. 259 ' \ : ' \ 260 | CDN A2 | : | CDN B2 | 261 , / : , / 262 ', ,- : ', ,- 263 ``''--'`` : ``''--'`` 264 : | 265 Pronvince A : Province B | 266 : +------+ 267 : | EU B | 268 : +------+ 269 : 270 : 271 Figure 2 CDNI between Two Different Provinces 273 2.2. Logging 275 Since in this experiment CDN interconnection is implemented within 276 the scope of the same operator, charging-related operations via 277 Logging Interface are not required. Therefore, we have neither 278 implemented nor tested any Logging operations. 280 2.3. UniContentID 282 In the current IETF CDNi standards, it is required to add the URL of 283 original request and the URL in the process through CDNs in the 284 request routing. When cache is not hit, downstream CDN needs to use 285 the information above to trace the source. The redirection flows are 286 complex and the URL becomes very long which makes the implementation 287 very difficult. 289 In this experiment, the UniContentID as defined in 290 [I-D.draft-chen-cdni-rr-content-acquisition] is used. UniConentID is 291 described by two tuple as (ProviderID, ContentID), e.g. 292 ('iptv.netitv.com','01234567890123456789012345678900'), which can 293 uniquely identify a content item. We trace the content source 294 according to the configuration table of ProviderID and the 295 corresponding relationship between ProviderID and the IP address of 296 upstream CDN. It is our view that redirection and content 297 acquisition are different routes. 299 2.4. Request Routing and Content Acquisition 301 2.4.1. Request Routing and Content Acquisition in Province B 302 +-------------------------+ +------------------------+ 303 | CDN B1 | | CDN B2 | 304 +-------+ | +---------+ +----------+| | +---------+ +--------+| 305 | EU | | |CDN B1 RR| | CDN B1 DN|| | |CDN B2 RR| |CDN B2DN|| 306 +-------+ | +---------+ +----------+| | +---------+ +--------+| 307 | +-------------------------+ +------------------------+ 308 |(1)RTSP or HTTP REQ | | | 309 |------------> | | | | 310 | (2)RTSP or HTTP RES | | | 311 | <------------| | | | 312 | | (3)RTSP or HTTP REQ | | 313 |--------------------------------------------> | | 314 | | (4)RTSP or HTTP REP | | 315 | <--------------------------------------------| | 316 | | | | | 317 | | (5)RTSP or HTTP REQ | | 318 |---------------------------------------------------------> | 319 | | | | | 320 | | | (6)HTTP REQ| | 321 | | |<---------------------------- | 322 | | | | | 323 | | | (7)HTTP REP| | 324 | | |----------------------------> | 325 | | | | | 326 | | | | | 327 | | | | | 328 | | (8)DATA | | 329 |<--------------------------------------------------------- | 330 | | | | | 332 Figure 3 Request Routing and Content A Acquisition in Province B 334 The Message sequence of Figure 3 is shown below in details. 336 (1) End-User sends a request to the load balancer of CDN B1, i.e. RR 337 of CDN B1 for the content.The URL includes the parameter of CMSID and 338 Domain(Please refer to [I-D. draft-chen-cdni-rr-content-acquisition] 339 for corresponding definitions). 341 (2) The RR of CDN B1 chooses an optimal RR of dCDN, i.e. RR of CDN 342 B2 for the End-User according to the load of dCDN and the IP Pool 343 information. 345 (3) End-User sends a request to the dCDN, i.e. RR of CDN B2 for 346 content acquisition. 348 (4) RR of CDN B response to the End-User for the information of a 349 delivery node i.e. DN. 351 (5) End-User sends a content request to the DN of CDN B2, the URL 352 include the information of CMSID and Domain. The DN of CDN B2 353 analyses the ProviderID according the information of CMSID and Domain 354 and looks up if the content exists in the cache according to the 355 ProviderID and ContentID. If the content is cached, the DN of CDN B2 356 serves the End-User. Otherwise, it skips to step (6). 358 (6) The DN of CDN B2 looks up the configuration table and determines, 359 according to the ProviderID, to acquire content uniquely identified 360 by the ProviderID and ContentID from the DN of CDN B1. 362 (7) The content in the DN of CDN B1 relays to the DN of CDN B2. 364 (8) The relayed content is served by the DN of CDN B2 to the End-User 365 via playing by downloading. 367 2.4.2. Request Routing and Content Acquisition between Province A and 368 Province B 369 +------------------+ +------------------+ +------------------+ 370 | CDN A1 | | CDN B1 | | CDN B2 | 371 +----+|+------+ +------+ | |+------+ +------+ | |+------+ +------+ | 372 | EU |||CDN A1| |CDN A1| | ||CDN B1| |CDN B1| | ||CDN B2| |CDN B2| | 373 +----+|| RR | | DN | | || RR | | DN | | || RR | | DN | | 374 | |+------+ +------+|| |+------+ +------+|| |+------+ +------+|| 375 | +------------------+ +------------------+ +------------------+ 376 |(1)RTSP or HTTP REQ | | | | 377 |-----> | | | | | | 378 |(2)RTSP or HTTP REP | | | | 379 | <-----| | | | | | 380 | | (3)RTSP or HTTP REQ | | | 381 |-----------------------------------------------> | | 382 | | (4)RTSP or HTTP REP | | | 383 | <-----------------------------------------------| | 384 | | | | | | | 385 | | | (5)RTSP or HTTP REQ | | 386 |----------------------------------------------------------->| 387 | | | | | | | 388 | | | | | (6)HTTP REQ | 389 | | | | |<--------------------| 390 | | | (7)HTTP REQ | | | 391 | | |<-------------------| | | 392 | | | | | | | 393 | | | (8)HTTP REP | | | 394 | | |------------------->| | | 395 | | | | | (9)HTTP REP | 396 | | | | |-------------------->| 397 | | | | | | | 398 | | | (10)DATA| | | | 399 |<---------------------------------------------------------- | 400 | | | | | | | 401 | | | | | | | 402 Figure 4 RR and Content Acquisition between Province A and Province B 404 The Message sequence of Figure 4 is shown below in details. 406 Step (1)~(5) is similar to step(1)~(5)of Section 2.4.1.Note that the 407 request routing process does not need the participation of CDN B1. 409 (6) The DN of CDN B2 looks up the configuration table and determines, 410 according to the ProviderID, to acquire content uniquely identified 411 by the ProviderID and ContentID from the DN of CDN B1. If the 412 content is cached in DN of CDN B1, the DN of CDN B1 serves the End- 413 User. Otherwise, it skips to step (7). 415 (7) The DN of CDN B1 looks up the configuration table and determines, 416 according to the ProviderID, to acquire content from the DN of CDN 417 A1. 419 (8) The content in the DN of CDN A1 relays to the DN of CDN B1. 421 (9) The content in the DN of CDN B1 relays to the DN of CDN B2. 423 (10) The relayed content is served by the DN of CDN B2 to the End- 424 User via playing for downloading. 426 2.4.3. Test Results 428 Based on the experiment model above, we have tested the CDN 429 interconnection scenario in China Telecom's trial network where 1 430 Gbps video traffic is not hit in the local cache and content 431 acquisition is needed. Performance tests are done by using the tools 432 from Shineck and Spirent. We have made such operations as fast 433 forward, fast rewind and positioning play etc. The testing results 434 show that the response time is less than one second and the Max DF is 435 less than 50msec. Also we conducted the test for a period of six 436 hours for stability tests through complex operation of fast forward, 437 fast rewind, positioning play, etc. The tests results show that the 438 response time is less than one second and call loss is less that 439 0.1%. During the process of performance tests, the user requests the 440 video on demand and Live contents through set-up box and conducts 441 complex operation such as fast forward, fast rewind, positioning 442 play, etc. The program is smooth during the play. The tests show 443 that the CDN interconnection architecture for intra-operator video 444 service is both feasible and efficient. 446 2.5. Control 448 In the IETF CDNi draft [I-D.murray-cdni-triggers], the uCDN controls 449 the content operation, i.e., content adding, content purging and 450 content modifying are performed through the control interface. In 451 this section, we describe a general content control flow by using CDN 452 B1 and CDN B2 as an example which are used in this experiment. 454 +--------+ +--------+ 455 | CDN B1 | | CDN B2 | 456 +--------+ +--------+ 457 | | 458 |HTTP://dCDN IP:PORT/ContentDeployReq 459 |-----------------------> | 460 | | 461 |ContentDeployReqResponse | 462 |<----------------------- | 463 | | 464 | | 465 |Achieve XML through FTP | 466 |<----------------------- | 467 | | 468 | | 469 | | 470 |http://uCDN IP:PORT/ContentDeployResult 471 |<----------------------- | 472 | | 473 | | 474 | | 475 |ContentDeployResultResponse 476 |-----------------------> | 477 | | 478 | | 479 Figure 5 Message Exchange for Content Acquisition 481 The Message sequence of Figure 5 is shown below in details. 483 (1) CDN B1 sends a content management requests to the CDN B2 484 including the content adding, content purging and content modifying. 485 The content object can be live content, video on demand content or TV 486 on demand. The object of ContentDeployReq includes the URL address 487 of XML description of the content object. 489 (2) CDN B2 checks if the URL FTP address from CDN B1 is OK. If the 490 result is OK, CDN B2 responds positively (success) to the CDN B1. 492 (3) CDN B2 login in the FTP of CDN B1 to achieve the XML data of 493 content object and executes the operation according to the 494 instruction of CDN B1, i.e., content adding, content purging or 495 content modifying. 497 (4) CDN B2 responds to the CDN B1 for the operation results, i.e., 498 with either a success or a failure result. 500 (5) CDN B1 confirms to the CDN B2 for the operation result and 501 registers the operation result. 503 3. Lessons Learned 505 The CDNi functionality tested in this experiment is applicable to 506 intra-operator case only. The inter-province service is ingested via 507 CDN in one province and can be used throughout the entire trial 508 network in two provinces. During the initial stage of CDNi 509 standardization, the most practical scenario to be considered is the 510 interconnection of CDNs distributed in different geographical regions 511 within one operator so as to enhance the consistency and continuity 512 of the services provided by operators themselves. Therefore, this 513 experiment is intended to provide some experiences and references on 514 CDNi networking to those operators who have initial requirements for 515 internal CDN interconnection across different geographical regions. 517 3.1. Simplification of operation procedures 519 It is demonstrated that relatively simple methods can be used to 520 simplify or optimize the Request Redirection, Content Acquisition, 521 Content Pre-Positioning, Content Addition/Modification/Deletion 522 procedures. This is conducive to operators when they also act as 523 service providers to serve the end users by fulfilling the 524 requirements of of real-time service and demanding user experience. 526 3.2. Redirection 528 According to the HTTP/DNS-based Request Routing process defined in 529 the current [I-D.ietf-cdni-framework], multiple redirection processes 530 are needed to determine the final CDN node that is suitable to serve 531 the end user. This may be convenient in the case of two-level CDNs. 532 But in case of large-scale CDN networking or complex CDN topology, 533 this would cause serious delay. The method provided in this 534 experiment, i.e., the one based on the local configuration of the 535 relationship table of end users' IP addresses and load situation of 536 dCDNs, the uCDN, as the national content storage center, can quickly 537 acquire and locate the final dCDN that is suitable to serve the end 538 user. By using this technique, the routing selection can be largely 539 simplified especially when operators have large-scale internal 540 networking. 542 3.3. UniContentID 544 In current IETF CDNi work [I-D.ietf-cdni-framework], the content 545 acquisition by dCDN from uCDN is achieved via embedding the URL of 546 the original request as well as that of the CDN the request is 547 redirected to during the redirection process. This would result in a 548 very long URL. Limited by the length and format of URL, such 549 approach would cause serious delay and waste of resources. In 550 addition, it would be difficult to implement this, especially under 551 the complex CDNi topology. 553 The unique content identification (named UniContentID in this 554 document) can be used to uniquely identify the content item ingested 555 by the content provider. The content source can also be resolved 556 from UniContentID contained in the end user's content request for 557 content acquisition. Due to the uniformity of UniContentID format 558 and its unchangeable nature during the transmission among CDNs, it 559 can all along identify the content requested by the end user even 560 after multiple forwards under complex CDNi topology. Note that these 561 introduce the need for defining a unique content identification for 562 content item in CDNi framework. 564 3.4. Metadata and Logging 566 The metadata related to CDNi content delivery would be relatively 567 simple. Such policy information as content ingestion, content 568 acquisition, etc. can be achieved by pre-configuration. It is also 569 due to the scope within one single operator, there is no need for 570 charging-related operations via logging interface, which, as a 571 result, can be simplified or may not even be supported. 573 3.5. Inter-Operator CDN Interconnection 575 For CDN interconnection across operators, if the operators are 576 clearly aware of each other's CDN framework (according to their 577 agreements), the method that is used in this experiment can also be 578 utilized as a reference, i.e., for implementing end user's request 579 redirection and content acquisition via maintaining the configuration 580 table, which can also achieve relatively high content delivery 581 efficiency. For those operators who have complicated internal CDN 582 topology or proprietary APIs or CDN topology, it is our view that it 583 requires to seek solutions for dynamic request redirection and 584 content acquisition. 586 4. Security Considerations 588 This experiment is carried out within a single operator. No security 589 issues are considered at this stage of the experiment. 591 5. IANA Considerations 593 This memo has no IANA Considerations. 595 6. Acknowledgments 597 To be added later 599 7. References 601 7.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 7.2. Informative References 608 [I-D.ietf-cdni-framework] 609 Peterson, L. and B. Davie, "Framework for CDN 610 Interconnection", April 2012. 612 [I-D.ietf-cdni-problem-statement] 613 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 614 Distribution Network Interconnection (CDNI) Problem 615 Statement", May 2012. 617 [I-D.ietf-cdni-requirements] 618 Leung, K. and Y. Lee, "Content Distribution Network 619 Interconnection (CDNI) Requirements", December 2011. 621 [I-D.ietf-cdni-use-cases] 622 Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 623 K., and G. Watson, "Use Cases for Content Delivery Network 624 Interconnection", June 2012. 626 [I-D.murray-cdni-triggers] 627 Murray, R. and B. Niven-Jenkins, "CDN Interconnect 628 Triggers", February 2012. 630 [I-D.narten-iana-considerations-rfc2434bis] 631 Narten, T. and H. Alvestrand, "Guidelines for Writing an 632 IANA Considerations Section in RFCs", 633 draft-narten-iana-considerations-rfc2434bis-09 (work in 634 progress), March 2008. 636 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 637 June 1999. 639 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 640 Text on Security Considerations", BCP 72, RFC 3552, 641 July 2003. 643 Authors' Addresses 645 Ge Chen 646 China Telecom 647 109 West Zhongshan Ave 648 Guangzhou, Tianhe District 649 China 651 Phone: 652 Email: cheng@gsta.com 654 Mian Li 655 ZTE Corporation 656 Nanjing, 210012 657 China 659 Phone: 660 Email: li.mian@zte.com.cn 662 Hongfei Xia 663 ZTE Corporation 664 Nanjing, 210012 665 China 667 Phone: 668 Email: xia.hongfei@zte.com.cn 670 Bhumip Khasnabish 671 ZTE Corporation 672 New Jersey, 07960 673 USA 675 Phone: +001-781-752-8003 676 Email: bhumip.khasnabish@zteusa.com 678 Jie Liang 679 China Telecom 680 109 West Zhongshan Ave 681 Guangzhou, Tianhe District 682 China 684 Phone: 685 Email: liangj@gsta.com