idnits 2.17.1 draft-chen-cdni-intra-cdn-provider-cdni-experiment-03.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 ([RFC6770]), 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 (July 30, 2015) is 3191 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-cdni-metadata' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-19 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-11 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-11 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI WG G. Chen 3 Internet-Draft China Telecom 4 Intended status: Informational M. Li 5 Expires: January 31, 2016 H. Xia 6 ZTE Corporation 7 B. Khasnabish 8 ZTE (TX) Inc. 9 J. Liang 10 China Telecom 11 July 30, 2015 13 Intra-CDN Provider CDNi Experiment 14 draft-chen-cdni-intra-cdn-provider-cdni-experiment-03 16 Abstract 18 In [RFC6770], the Inter-Affiliates CDN Interconnection use case is 19 described. In this scenario, a large CDN Provider may have several 20 autonomous or semi-autonomous subsidiaries that each operates on 21 their own CDN. The CDN Provider needs to make these down-stream CDNs 22 interoperate to provide a consistent service to its customers on the 23 whole collective footprint. 25 This document illustrates in details the CDNi experiment that has 26 been carried out by China Telecom, and the lessons and experiences to 27 CDNi standardization work. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 31, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Intra-CDN Provider CDNi Experiments . . . . . . . . . . . . . 3 66 2.1. Experiment Configuration . . . . . . . . . . . . . . . . 3 67 2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . 7 69 2.4. Request Routing and Content Acquisition . . . . . . . . . 8 70 2.4.1. Request Routing and Content Acquisition in Province B 8 71 2.4.2. Request Routing and Content Acquisition between 72 Province A and Province B . . . . . . . . . . . . . . 9 73 2.4.3. Test Results . . . . . . . . . . . . . . . . . . . . 11 74 2.5. Control . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.1. Simplification of operation procedures . . . . . . . . . 13 77 3.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.3. UniContentID . . . . . . . . . . . . . . . . . . . . . . 13 79 3.4. Metadata and Logging . . . . . . . . . . . . . . . . . . 14 80 3.5. Inter-Operator CDN Interconnection . . . . . . . . . . . 14 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 7.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 the following RFCs: 122 [RFC6707], [RFC6770], [RFC7336], and [RFC7337]. 124 2. Intra-CDN Provider CDNi Experiments 126 2.1. Experiment Configuration 128 The interconnection of four CDNs in two provinces has been tested in 129 this experiment. Each province has two CDNs interconnected which are 130 provided by different CDN vendors. As depicted in Figure 1, CDN A1 131 of Province A has contracts with service providers CP1 and CP2, and 132 it acts as the content storage center of the nation.CDN B1 of 133 Province B has contract with service provider CP3. Meanwhile, CDN A1 134 and CDN B1 are the sub-center CDNs of respective province, while CDN 135 A2 and CDN B2 are the regional CDNs of respective province. CDN A1 136 and CDN B1 are deployed on the provincial backbone networks, while 137 CDN A2 and CDN B2 are deployed on the MANs. CDN A1 is the upstream 138 CDN of CDN A2. Services are provided to the end users by certain 139 node in regional CDN, which is usually the geographically closest one 140 to the end user. However, if this desired node is overloaded, 141 certain re-routing or load-balancing criteria could be used to choose 142 another node. CDN B1 and CDN B2 have similar deployment. The 143 provincial center CDN A1 and CDN B1 are interconnected with each 144 other. They do not have interconnection with the region CDNs in 145 other provinces than themselves. The regional CDNs of the respective 146 provinces do not interconnect with one another either. 148 China Telecom's CDN trial network offers two types of services: 149 intra-province service (provided by CP2 and CP3) and inter-province 150 service (provided by CP1). Intra-province service is provided 151 independently within the province without any interconnection with 152 CDNs in other provinces. When inter-province service is provided, 153 content is ingested to the CDN in a single province and then 154 distributed among the CDNs in all other provinces in the trial 155 network. In this experiment the inter-province service is ingested 156 via CDN A1 node and the end users can obtain services through the 157 CDNs that are located in their own provinces. 159 +------+ 160 | CP1 | 161 +------+ +-----+ 162 +------+ / | CP3 | 163 | CP2 | / +-----+ 164 +------+ / : / 165 \ / : / 166 \ / : / 167 \ : 168 _,.---.,, : _,.---.,, 169 .` `. : .` `. 170 ' \ : ' \ 171 | CDN A1 |---:---- | CDN B1 | 172 , / ---:---- , / 173 ', ,- : ', ,- 174 ``''--'`` : ``''--'`` 175 | | : | | 176 | | : | | 177 | | : | | 178 _,.---.,, : _,.---.,, 179 .` `. : .` `. 180 ' \ : ' \ 181 | CDN A2 | : | CDN B2 | 182 , / : , / 183 ', ,- : ', ,- 184 ``''--'`` : ``''--'`` 185 : 186 Province A : Province B 187 : 189 Figure 1 CDNI between Two Different Provinces, each with Two CDNs 191 The details of the experiment are as presented below: 193 CP3 has contract with CDN B1 to provide content delivery service, 194 e.g., IPTV service, to the end users in the Province B region. CP3 195 does not serve end users outside Province B. As an autonomous 196 service by China Telecom, the content of this service is ingested 197 into CDN B1. As its downstream CDN, CDN B1 can delegate the content 198 requests from end users to CDN B2 to perform content delivery. 200 When CDN B1 receives the content request from EU B of Province B 201 related to service provided by CP3, it redirects this request to CDN 202 B2. If CDN B2 has locally cached the copy of the content requested 203 by EU B (cache hit case), it serves EU B directly by delivering the 204 content to EU B. If CDN B2 does not have the content cached (cache 205 miss case), it acquires the content from CDN B1. 207 CP1 has contract with CDN A1 to provide content delivery service, 208 e.g., OTT service, to end users within Province A and in the region 209 of Province B. The content for this service is ingested from CDN A1. 210 As for the cross-province routing, since it is within the same 211 operator, static configuration can be used for dCDN selection. In 212 this experiment, the national content storage center CDN A1 213 configures locally the relationship table of the end user's IP 214 addresses and the loading condition of dCDNs. 216 When CDN A1 receives a content request from EU B of Province B, it 217 redirects the request to CDN B2 directly after it checks the local 218 configuration table without going through multiple redirection 219 processes like CDN A1->CDN B1->CDN B2. If CDN B2 has locally cached 220 a copy of the content that has been requested by EU B (cache hit 221 case), it serves EU B directly by delivering the content to EU B. If 222 CDN B2 does not have the content cached (cache miss case), it 223 acquires the content from CDN B1. If CDN B1 does not have the 224 content cached either, it acquires the content from CDN A1. 226 In this experiment, we use a content acquisition method that is 227 different from the current CDNi work. The method is based on Content 228 Identification by using UniContentID that is defined to uniquely 229 identify a content item. A detailed description of this method is 230 presented in Section 2.3. 232 +------+ 233 | CP1 | 234 +------+ +-----+ 235 / | CP3 | 236 / +-----+ 237 / : / 238 / : / 239 / : / 240 : 241 _,.---.,, : _,.---.,, 242 .` `. : .` `. 243 ' \ : ' \ 244 | CDN A1 |---:---- | CDN B1 | 245 , / ---:---- , / 246 ', ,- : ', ,- 247 ``''--'`` : ``''--'`` 248 | | : | | 249 | | : | | 250 | | : | | 251 _,.---.,, : _,.---.,, 252 .` `. : .` `. 253 ' \ : ' \ 254 | CDN A2 | : | CDN B2 | 255 , / : , / 256 ', ,- : ', ,- 257 ``''--'`` : ``''--'`` 258 : | 259 Province A : Province B | 260 : +------+ 261 : | EU B | 262 : +------+ 263 : 264 : 265 Figure 2 CDNI between Two Different Provinces 267 2.2. Logging 269 Since in this experiment CDN interconnection is implemented within 270 the scope of the same operator, charging-related operations via 271 Logging Interface are not required. Therefore, we have neither 272 implemented nor tested any Logging operations. 274 2.3. UniContentID 276 In the current IETF CDNi standards, it is required to add the URL of 277 original request and the URL in the process through CDNs in the 278 request routing. When cache is not hit, downstream CDN needs to use 279 the information above to trace the source. The redirection flows are 280 complex and the URL becomes very long which makes the implementation 281 very difficult. 283 In this experiment, the UniContentID as defined in [I-D.draft-chen- 284 cdni-rr-content-acquisition] is used. UniConentID is described by 285 two tuple as (ProviderID, ContentID), e.g. 286 ('iptv.netitv.com','01234567890123456789012345678900'), which can 287 uniquely identify a content item. We trace the content source 288 according to the configuration table of ProviderID and the 289 corresponding relationship between ProviderID and the IP address of 290 upstream CDN. It is our view that redirection and content 291 acquisition are different routes. 293 2.4. Request Routing and Content Acquisition 295 2.4.1. Request Routing and Content Acquisition in Province B 297 +-------------------------+ +------------------------+ 298 | CDN B1 | | CDN B2 | 299 +-------+ | +---------+ +----------+| | +---------+ +--------+| 300 | EU | | |CDN B1 RR| | CDN B1 DN|| | |CDN B2 RR| |CDN B2DN|| 301 +-------+ | +---------+ +----------+| | +---------+ +--------+| 302 | +-------------------------+ +------------------------+ 303 |(1)RTSP or HTTP REQ | | | 304 |------------> | | | | 305 | (2)RTSP or HTTP RES | | | 306 | <------------| | | | 307 | | (3)RTSP or HTTP REQ | | 308 |--------------------------------------------> | | 309 | | (4)RTSP or HTTP REP | | 310 | <--------------------------------------------| | 311 | | | | | 312 | | (5)RTSP or HTTP REQ | | 313 |---------------------------------------------------------> | 314 | | | | | 315 | | | (6)HTTP REQ| | 316 | | |<---------------------------- | 317 | | | | | 318 | | | (7)HTTP REP| | 319 | | |----------------------------> | 320 | | | | | 321 | | | | | 322 | | | | | 323 | | (8)DATA | | 324 |<--------------------------------------------------------- | 325 | | | | | 327 Figure 3 Request Routing and Content A Acquisition in Province B 328 The Message sequence of Figure 3 is shown below in details. 330 (1) End-User sends a request to the load balancer of CDN B1, i.e. RR 331 of CDN B1 for the content.The URL includes the parameter of CMSID and 332 Domain(Please refer to [I-D. draft-chen-cdni-rr-content-acquisition] 333 for corresponding definitions). 335 (2) The RR of CDN B1 chooses an optimal RR of dCDN, i.e. RR of CDN B2 336 for the End-User according to the load of dCDN and the IP Pool 337 information. 339 (3) End-User sends a request to the dCDN, i.e. RR of CDN B2 for 340 content acquisition. 342 (4) RR of CDN B response to the End-User for the information of a 343 delivery node i.e. DN. 345 (5) End-User sends a content request to the DN of CDN B2, the URL 346 include the information of CMSID and Domain. The DN of CDN B2 347 analyses the ProviderID according the information of CMSID and Domain 348 and looks up if the content exists in the cache according to the 349 ProviderID and ContentID. If the content is cached, the DN of CDN B2 350 serves the End-User. Otherwise, it skips to step (6). 352 (6) The DN of CDN B2 looks up the configuration table and determines, 353 according to the ProviderID, to acquire content uniquely identified 354 by the ProviderID and ContentID from the DN of CDN B1. 356 (7) The content in the DN of CDN B1 relays to the DN of CDN B2. 358 (8) The relayed content is served by the DN of CDN B2 to the End-User 359 via playing by downloading. 361 2.4.2. Request Routing and Content Acquisition between Province A and 362 Province B 363 +------------------+ +------------------+ +------------------+ 364 | CDN A1 | | CDN B1 | | CDN B2 | 365 +----+|+------+ +------+ | |+------+ +------+ | |+------+ +------+ | 366 | EU |||CDN A1| |CDN A1| | ||CDN B1| |CDN B1| | ||CDN B2| |CDN B2| | 367 +----+|| RR | | DN | | || RR | | DN | | || RR | | DN | | 368 | |+------+ +------+|| |+------+ +------+|| |+------+ +------+|| 369 | +------------------+ +------------------+ +------------------+ 370 |(1)RTSP or HTTP REQ | | | | 371 |-----> | | | | | | 372 |(2)RTSP or HTTP REP | | | | 373 | <-----| | | | | | 374 | | (3)RTSP or HTTP REQ | | | 375 |-----------------------------------------------> | | 376 | | (4)RTSP or HTTP REP | | | 377 | <-----------------------------------------------| | 378 | | | | | | | 379 | | | (5)RTSP or HTTP REQ | | 380 |----------------------------------------------------------->| 381 | | | | | | | 382 | | | | | (6)HTTP REQ | 383 | | | | |<--------------------| 384 | | | (7)HTTP REQ | | | 385 | | |<-------------------| | | 386 | | | | | | | 387 | | | (8)HTTP REP | | | 388 | | |------------------->| | | 389 | | | | | (9)HTTP REP | 390 | | | | |-------------------->| 391 | | | | | | | 392 | | | (10)DATA| | | | 393 |<---------------------------------------------------------- | 394 | | | | | | | 395 | | | | | | | 396 Figure 4 RR and Content Acquisition between Province A and Province B 398 The Message sequence of Figure 4 is shown below in details. 400 Step (1)~(5) is similar to step(1)~(5)of Section 2.4.1.Note that the 401 request routing process does not need the participation of CDN B1. 403 (6) The DN of CDN B2 looks up the configuration table and determines, 404 according to the ProviderID, to acquire content uniquely identified 405 by the ProviderID and ContentID from the DN of CDN B1. If the 406 content is cached in DN of CDN B1, the DN of CDN B1 serves the End- 407 User. Otherwise, it skips to step (7). 409 (7) The DN of CDN B1 looks up the configuration table and determines, 410 according to the ProviderID, to acquire content from the DN of CDN 411 A1. 413 (8) The content in the DN of CDN A1 relays to the DN of CDN B1. 415 (9) The content in the DN of CDN B1 relays to the DN of CDN B2. 417 (10) The relayed content is served by the DN of CDN B2 to the End- 418 User via playing for downloading. 420 2.4.3. Test Results 422 Based on the experiment model above, we have tested the CDN 423 interconnection scenario in China Telecom's trial network where 1 424 Gbps video traffic is not hit in the local cache and content 425 acquisition is needed. Performance tests are done by using the tools 426 from Shineck and Spirent. We have made such operations as fast 427 forward, fast rewind and positioning play etc. The testing results 428 show that the response time is less than one second and the Max DF is 429 less than 50msec. Also we conducted the test for a period of six 430 hours for stability tests through complex operation of fast forward, 431 fast rewind, positioning play, etc. The tests results show that the 432 response time is less than one second and call loss is less that 433 0.1%. During the process of performance tests, the user requests the 434 video on demand and Live contents through set-up box and conducts 435 complex operation such as fast forward, fast rewind, positioning 436 play, etc. The program is smooth during the play. The tests show 437 that the CDN interconnection architecture for intra-operator video 438 service is both feasible and efficient. 440 2.5. Control 442 In the IETF CDNi draft [I-D.murray-cdni-triggers], the uCDN controls 443 the content operation, i.e., content adding, content purging and 444 content modifying are performed through the control interface. In 445 this section, we describe a general content control flow by using CDN 446 B1 and CDN B2 as an example which are used in this experiment. 448 +--------+ +--------+ 449 | CDN B1 | | CDN B2 | 450 +--------+ +--------+ 451 | | 452 |HTTP://dCDN IP:PORT/ContentDeployReq 453 |-----------------------> | 454 | | 455 |ContentDeployReqResponse | 456 |<----------------------- | 457 | | 458 | | 459 |Achieve XML through FTP | 460 |<----------------------- | 461 | | 462 | | 463 | | 464 |http://uCDN IP:PORT/ContentDeployResult 465 |<----------------------- | 466 | | 467 | | 468 | | 469 |ContentDeployResultResponse 470 |-----------------------> | 471 | | 472 | | 473 Figure 5 Message Exchange for Content Acquisition 475 The Message sequence of Figure 5 is shown below in details. 477 (1) CDN B1 sends a content management requests to the CDN B2 478 including the content adding, content purging and content modifying. 479 The content object can be live content, video on demand content or TV 480 on demand. The object of ContentDeployReq includes the URL address 481 of XML description of the content object. 483 (2) CDN B2 checks if the URL FTP address from CDN B1 is OK. If the 484 result is OK, CDN B2 responds positively (success) to the CDN B1. 486 (3) CDN B2 login in the FTP of CDN B1 to achieve the XML data of 487 content object and executes the operation according to the 488 instruction of CDN B1, i.e., content adding, content purging or 489 content modifying. 491 (4) CDN B2 responds to the CDN B1 for the operation results, i.e., 492 with either a success or a failure result. 494 (5) CDN B1 confirms to the CDN B2 for the operation result and 495 registers the operation result. 497 3. Lessons Learned 499 The CDNi functionality tested in this experiment is applicable to 500 intra-operator case only. The inter-province service is ingested via 501 CDN in one province and can be used throughout the entire trial 502 network in two provinces. During the initial stage of CDNi 503 standardization, the most practical scenario to be considered is the 504 interconnection of CDNs distributed in different geographical regions 505 within one operator so as to enhance the consistency and continuity 506 of the services provided by operators themselves. Therefore, this 507 experiment is intended to provide some experiences and references on 508 CDNi networking to those operators who have initial requirements for 509 internal CDN interconnection across different geographical regions. 511 3.1. Simplification of operation procedures 513 It is demonstrated that relatively simple methods can be used to 514 simplify or optimize the Request Redirection, Content Acquisition, 515 Content Pre-Positioning, Content Addition/Modification/Deletion 516 procedures. This is conducive to operators when they also act as 517 service providers to serve the end users by fulfilling the 518 requirements of of real-time service and demanding user experience. 520 3.2. Redirection 522 According to the HTTP/DNS-based Request Routing process defined in 523 the current [RFC7336], multiple redirection processes are needed to 524 determine the final CDN node that is suitable to serve the end user. 525 This may be convenient in the case of two-level CDNs. But in case of 526 large-scale CDN networking or complex CDN topology, this would cause 527 serious delay. The method provided in this experiment, i.e., the one 528 based on the local configuration of the relationship table of end 529 users' IP addresses and load situation of dCDNs, the uCDN, as the 530 national content storage center, can quickly acquire and locate the 531 final dCDN that is suitable to serve the end user. By using this 532 technique, the routing selection can be largely simplified especially 533 when operators have large-scale internal networking. 535 3.3. UniContentID 537 In current IETF CDNi work [RFC7336], the content acquisition by dCDN 538 from uCDN is achieved via embedding the URL of the original request 539 as well as that of the CDN the request is redirected to during the 540 redirection process. This would result in a very long URL. Limited 541 by the length and format of URL, such approach would cause serious 542 delay and waste of resources. In addition, it would be difficult to 543 implement this, especially under the complex CDNi topology. 545 The unique content identification (named UniContentID in this 546 document) can be used to uniquely identify the content item ingested 547 by the content provider. The content source can also be resolved 548 from UniContentID contained in the end user's content request for 549 content acquisition. Due to the uniformity of UniContentID format 550 and its unchangeable nature during the transmission among CDNs, it 551 can all along identify the content requested by the end user even 552 after multiple forwards under complex CDNi topology. Note that these 553 introduce the need for defining a unique content identification for 554 content item in CDNi framework. 556 3.4. Metadata and Logging 558 The metadata related to CDNi content delivery are as discussed in [I- 559 D.ietf-cdni-metadata]. The policy information like content 560 ingestion, content acquisition, etc. can be obtained from pre- 561 configuration data. Also, since the scope of this experiment is one 562 operator, there may not be any need for obtaining charging-related 563 operations via logging interface. However, if needed the 564 specifications that are being developed in [I-D.ietf-cdni-logging] 565 would be useful. 567 3.5. Inter-Operator CDN Interconnection 569 For CDN interconnection across operators, if the operators are 570 clearly aware of each other's CDN framework (according to their 571 agreements), the method that is used in this experiment can also be 572 utilized as a reference, i.e., for implementing end user's request 573 redirection and content acquisition via maintaining the configuration 574 table, which can also achieve relatively high content delivery 575 efficiency. For those operators who have complicated internal CDN 576 topology or proprietary APIs or CDN topology, it is our view that it 577 requires to seek solutions for dynamic request redirection - as 578 discussed in [I-D.ietf-cdni-redirection] - and content acquisition. 580 4. Security Considerations 582 This experiment is carried out within a single operator. No security 583 issues are considered at this stage of the experiment. 585 5. IANA Considerations 587 There are no IANA considerations for this draft. 589 6. Acknowledgments 591 To be added later 593 7. References 595 7.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 7.2. Informative References 604 [I-D.ietf-cdni-logging] 605 Faucheur, F., Bertrand, G., Oprescu, I., and R. 606 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 607 logging-19 (work in progress), July 2015. 609 [I-D.ietf-cdni-metadata] 610 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 611 "CDN Interconnection Metadata", draft-ietf-cdni- 612 metadata-11 (work in progress), July 2015. 614 [I-D.ietf-cdni-redirection] 615 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 616 Redirection Interface for CDN Interconnection", draft- 617 ietf-cdni-redirection-11 (work in progress), July 2015. 619 [I-D.murray-cdni-triggers] 620 Murray, R. and B. Niven-Jenkins, "CDN Interconnect 621 Triggers", February 2012. 623 [I-D.narten-iana-considerations-rfc2434bis] 624 Narten, T. and H. Alvestrand, "Guidelines for Writing an 625 IANA Considerations Section in RFCs", draft-narten-iana- 626 considerations-rfc2434bis-09 (work in progress), March 627 2008. 629 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 630 DOI 10.17487/RFC2629, June 1999, 631 . 633 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 634 Text on Security Considerations", BCP 72, RFC 3552, 635 DOI 10.17487/RFC3552, July 2003, 636 . 638 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 639 Distribution Network Interconnection (CDNI) Problem 640 Statement", RFC 6707, DOI 10.17487/RFC6707, September 641 2012, . 643 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 644 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 645 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 646 November 2012, . 648 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 649 "Framework for Content Distribution Network 650 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 651 August 2014, . 653 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 654 Network Interconnection (CDNI) Requirements", RFC 7337, 655 DOI 10.17487/RFC7337, August 2014, 656 . 658 Authors' Addresses 660 Ge Chen 661 China Telecom 662 109 West Zhongshan Ave 663 Guangzhou, Tianhe District 664 China 666 Email: cheng@gsta.com 668 Mian Li 669 ZTE Corporation 670 Nanjing 210012 671 China 673 Email: li.mian@zte.com.cn 675 Hongfei Xia 676 ZTE Corporation 677 Nanjing 210012 678 China 680 Email: xia.hongfei@zte.com.cn 681 Bhumip Khasnabish 682 ZTE (TX) Inc. 683 USA 685 Phone: +001-781-752-8003 686 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 687 URI: http://tinyurl.com/bhumip/ 689 Jie Liang 690 China Telecom 691 109 West Zhongshan Ave 692 Guangzhou, Tianhe District 693 China 695 Email: liangj@gsta.com