idnits 2.17.1 draft-he-cdni-cap-info-advertising-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 304 has weird spacing: '... case that ...' == Line 364 has weird spacing: '...ntifies how ...' == Line 421 has weird spacing: '...cquires the ...' == Line 509 has weird spacing: '...dStatus loadS...' == Line 512 has weird spacing: '...nticity auth...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 6, 2012) is 4405 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OPTIONAL' is mentioned on line 507, but not defined == Unused Reference: 'I-D.draft-cdni-use-cases' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-cdni-requirements' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'I-D.davie-cdni-framework' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-caulfield-metadata' is defined on line 727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-03 == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-03 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-02 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 -- No information found for draft-caulfield-cdni-metadata-core - is the name correct? Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI Working Group Xiaoyan.He 3 Internet Draft Spencer.Dawkins 4 Intended status: Standards Track Huawei 5 Expires: September 2012 Ge.Chen 6 China Telecom 7 Yunfei.Zhang 8 Wei.Ni 9 China Mobile 10 March 6, 2012 12 Capability Information Advertising for CDN Interconnection 13 draft-he-cdni-cap-info-advertising-01.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on September 6, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document describes protocol for capability information 56 advertising which is used to communicate capability and status 57 information among interconnected Content Delivery Networks (CDNs). 59 Table of Contents 61 1. Introduction ................................................ 3 62 1.1. Terminology ............................................ 3 63 1.2. Place of capability advertising in CDNI model ........... 3 64 2. Conventions used in this document ............................ 5 65 3. CDN selection criteria ...................................... 5 66 4. Description of information ................................... 6 67 4.1. General information .................................... 6 68 4.1.1. Service status .................................... 6 69 4.1.2. IP version ........................................ 7 70 4.2. Footprint .............................................. 7 71 4.3. Load status ............................................ 7 72 4.3.1. Basic serving indicator ............................ 8 73 4.3.2. Detailed resource status........................... 8 74 4.4. Cost preferences ....................................... 8 75 4.5. Authentication capability ............................... 9 76 4.6. Delivery service capability ............................ 10 77 5. Overview of the capability advertising protocol ............. 10 78 5.1. Transport mechansim of the protocol .................... 10 79 5.2. Opration mode of the protocol .......................... 10 80 5.3. Discovery of the protocol contact point ................ 11 81 6. Protocol Specification ..................................... 11 82 6.1. Encoding of downstream CDN information ................. 11 83 6.1.1. Load status object ................................ 11 84 6.1.2. Cost object ...................................... 12 85 6.1.3. Authenticity object ............................... 12 86 6.1.4. Footprint object .................................. 12 87 6.1.5. Encoding of general information ................... 13 88 6.2. Message description ................................... 13 89 6.2.1. Report mode ...................................... 13 90 6.2.2. Query mode ....................................... 14 91 6.3. Message examples ...................................... 14 92 6.3.1. Report mode ...................................... 14 93 6.3.2. Query mode ....................................... 16 94 7. Security Considerations .................................... 17 95 8. IANA Considerations ........................................ 17 96 9. References ................................................. 17 97 9.1. Normative References................................... 17 98 9.2. Informative References ................................. 18 99 10. Acknowledgments ........................................... 18 101 1. Introduction 103 In the context of CDNI, the downstream CDN needs to advertise some 104 of its information to the upstream CDN to facilitate the upstream 105 CDN selecting an appropriate CDN as the target in request routing, 106 such as downstream CDN capabilities, resources and affinities (i.e. 107 Preferences or cost). 109 This document focuses on defining the information needed to be 110 exchanged in CDNI and the corresponding advertising protocol, which 111 is one of the main components of CDNI. 113 1.1. Terminology 115 This document reuses the terminology defined in [I-D.draft-cdni- 116 problem-statement]. 118 1.2. Place of capability advertising in CDNI model 120 Figure 1 from [I-D.draft-cdni-problem-statement] illustrating the 121 CDNI model. The capability information advertising protocol is not 122 explicitly shown. Although that might be changed later upon the 123 working group's decision, but now it is thought that capability 124 advertisement is part of the function of the Request Routing 125 interface. 127 -------- 128 / \ 129 | CSP | 130 \ / 131 -------- 132 * 133 * 134 * /\ 135 * / \ 136 ---------------------- |CDNI| ---------------------- 137 / Upstream CDN \ | | / Downstream CDN \ 138 | +-------------+ | Control Interface| +-------------+ | 139 |******* Control |<======|====|========>| Control *******| 140 |* +------*----*-+ | | | | +-*----*------+ *| 141 |* * * | | | | * * *| 142 |* +------*------+ | Logging Interface| +------*------+ *| 143 |* ***** Logging |<======|====|========>| Logging ***** *| 144 |* * +-*-----------+ | | | | +-----------*-+ * *| 145 |* * * * | Request Routing | * * * *| 146 .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... 147 . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . 148 . |* * * +-------------+.| | | | +-------------+ * * *| . 149 . |* * * . CDNI Metadata | * * *| . 150 . |* * * +-------------+ |. Interface | +-------------+ * * *| . 151 . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . 152 . |* * * | | | . \ / | | | * * *| . 153 . |* * * |+---------+ | | . \/ | | +---------+| * * *| . 154 . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . 155 . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . 156 . |******* +---------+| | Acquisition | |+----------+ *******| . 157 . | +-------------+ | | +-------*-----+ | . 158 . \ / \ * / . 159 . ---------------------- ---------*------------ . 160 . * . 161 . * Delivery . 162 . * . 163 . +--*---+ . 164 ...............Request.............................| User |..Request.. 165 | Agent| 166 +------+ 168 <==> interfaces inside the scope of CDNI 170 **** interfaces outside the scope of CDNI 171 .... interfaces outside the scope of CDNI 172 Figure 1: CDNI Model 174 2. Conventions used in this document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC-2119 [RFC2119]. 180 3. CDN selection criteria 182 An upstream CDN may perform downstream CDN selection according to 183 different kinds of filtering criteria deriving from CP's requirement 184 and/or its local policy. 186 One kind of criteria is derived from CP's requirement. Each CP is 187 most likely to expect to control the distribution and delivery of 188 its contents by its delegated CDN. To achieve that, CP reflects its 189 requirements via metadata pertaining to the content and transfer the 190 metadata to the CDN to enforce that. In the context of CDNI, this 191 metadata should also be further transferred to a downstream CDN for 192 the same purpose. Subsequently, while the upstream CDN receving a 193 content request and intends to select an appropriate downstream CDN 194 from multiple ones to redirect the request, it should filter the 195 downstream CDNs according the metadata, e.g. in the metadata, it is 196 required the content should be delivered via HTTP adaptive streaming 197 service, a downstream CDN without the capability should not be 198 selected. Therefore, the required capability contained in the 199 metadata as a source of filtering criteria is needed for CDN 200 selection and is to be advertised from a downstream CDN to an 201 upstream CDN. 203 Another kind of criteria is derived from upstream CDN's local policy. 204 There are various kind of local poicy deployed, e.g. minimal load 205 first, minimal expense first, optimal QoS preferred etc. To 206 implement these policies, relative capability/status information of 207 a downstream CDN should be advertised to its upstream CDN. 209 In addition, general information like service status, IP version of 210 downstream CDN should also be taken into account while making the 211 CDN selection. 213 Based on the above mentioned filtering criteria, we can list the 214 corresponding capability and status information needed as followings: 216 * General information like the service status, IP version of the 217 downstream CDN is needed. 219 * Footprint of the downstream CDN is needed if proximity is 220 preferred while making routing decision. 222 * Load status of resources is needed if minimal load is preferred 223 while making routing decision. 225 * Cost information of downstream CDN is needed if minimal cost is 226 preferred while making routing decision. 228 * Delivery capability information like delivery service type, user 229 authentication method of downstream CDN is needed if CP's 230 requirements contained in CDNI metadata is the main preference of 231 routing decision. 233 Note: The information needed to be advertised according to the CDNI 234 metadata should be adjusted once protocol on that interface is 235 finalized. 237 4. Description of information 239 According to the CDN selection criteria listed in section 3, the 240 relative capability and status information advertised from a 241 dwonstream CDN to an interconnected upstream CDN is described in 242 detail in the following clause. The information is considered all as 243 mandatory unless otherwise state explicitly. 245 4.1. General information 247 4.1.1. Service status 249 Service status is used to indicate that the downstream CDN is in 250 service or out of service of CDNI. In service means that the 251 downstream CDN's status is normal and it is willing to take requests 252 from an upstream CDN. Out of service means that the downstream CDN can 253 not take any requests from an upstream CDN due to some abnormal cases, 255 e.g.: 257 O Some kind of resource on the downstream CDN is exhausted. 259 O Network link between the two connected CDNs is abnormal. 261 O Downstream CDN is down. 263 4.1.2. IP version 265 IP address version of which a downstream CDN can serve for endpoints. 266 The value it takes could be "IPV4", "IPV6" and "IPV4&IPV6" the last 267 one means that the downstream CDN can serve for both the types of 268 endpoints. 270 4.2. Footprint 272 Footprint indicates the geographic region for which a CDN can serve. 273 It is identified by a set of country, state and city code 274 combination as defined in ISO 3166-2 or a set of autonomous system 275 number or a set of IP subnet. 277 A downstream CDN may advertise its footprint in a macro level e.g. 278 the country names of the serving regions belong to, it may also 279 advertise its footprint in a granularity of subset of the macro 280 level, e.g. detail state or city name of the serving regions. In the 281 later case, if there are multiple regions belong to one country a 282 downstream CDN can serve, then there will be multiple state or city 283 footprint elements in one advertisement message. This finer 284 granularity allows an upstream CDN understand the downstream CDN 285 more precisely but puts more requirements on the downstream CDN. 286 Therefore, it is up to the downstream CDN to determine to which 287 granularity it should advertise to an upstream CDN. 289 Upon each footprint, the other information like load status of 290 resources, capability information described in the following part of 291 this section are encapsulated to express the current status and 292 capabilities associated to this specific region. 294 4.3. Load status 296 Load status represents the status of resources assigned to an 297 upstream CDN by a downstream CDN and their current usage. This 298 information is important for the upstream CDN to implement the 299 minimal load first local policy. It contains a mandatory binary 300 serving indication to tell the upstream CDN whether the downstream 301 CDN can or cannot serve end users on behalf of the upstream CDN from 302 the perspective of resource load. It can optional contains the 303 detailed contracted and current used value of a specific resource in 304 case that the downstream CDN is willing to advertise such 305 information to the upstream CDN. For example they belong to one 306 group and have a strong trust relationship between them. 308 4.3.1. Basic serving indicator 310 Basic serving indicator is used to tell whether a downstream CDN has 311 the ability to accept more additional requests from the upstream CDN 312 or not from the perspective of its resource load status. 314 4.3.2. Detailed resource status 316 Detailed resource status is used to advertise the maximum value of 317 capacity the downstream CDN committed to the upstream CDN and the 318 current assignments of it. This information can be leveraged by the 319 upstream CDN to implement a more accurate CDN selection if there 320 exists multiple candidate downstream CDNs through the previous basic 321 serving indication. It is reflected through the following three 322 category resource in detail: 324 * Connection Allowed, Connection Assigned 326 This information is used to indicate the maximum number of 327 simultaneous TCP connections for HTTP of the downstream CDN 328 committed to provide to the upstream CDN for content delivery and 329 the current used number respectively. 331 * Bandwidth Allowed, Bandwidth Consumed 333 This information is used to indicate the maximum value of bandwidth 334 for content delivery of the downstream CDN committed to provide to 335 the upstream CDN and current used value respectively. 337 Note: The value of "andwidth Allowed" and "Bandwidth Consumed" may 338 be an absolute value taking only the physical bandwidth of the CDN 339 into account or it may be a normalized value which may also consider 340 the disk I/O capacity and CPU usage as a whole. This depends on the 341 CDN specific implementation and is out of scope of CDNI. 343 * Cached Assets Allowed, Cached Assets 345 This information is used to indicate the maximum value of storage 346 capacity of cache of the downstream CDN committed to provide to the 347 upstream CDN and current used value respectively. 349 4.4. Cost preferences 351 Cost preferences of the downstream CDN. Different downstream CDNs 352 may characterize cost via various metrics e.g. hop-count, air-miles, 353 or monetary cost. An upstream CDN can negotiate with a downstream 354 CDN on how to characterize cost of CDNI via the attributes "cost 355 type" and "cost mode". 357 Note: The detailed mechanism that the two interconnected CDNs 358 negotiating on the abstract cost assignment is out of scope of this 359 draft. 361 o type: identifies what the costs represent, e.g. hop-count, 362 monetary cost etc; 364 o mode: identifies how the costs should be interpreted. 365 Specifically, the mode attribute indicates whether returned costs 366 should be interpreted as numerical values or ordinal rankings. It is 367 important to communicate such information to the upstream CDN, as 368 certain operations may not be valid on certain costs returned by a 369 downstream CDN. 371 o cost: value of the cost corresponding to the selected type and 372 mode. 374 4.5. Authentication capability 376 Authentication capability describes the authentication type and 377 relative parameters a downstream CDN supports to the clients. It 378 provides information for content delivery such that the user agent 379 can be authenticated as a client when requesting content from a 380 downstream CDN. The authentication capability contains the 381 following attributes: 383 O type - a string indicating the authorization type "url-signing" 384 or "url-token". The "url-signing" type refers to URL signing 385 authorization. The "url-token" type refers to token-based 386 authorization. 388 O algorithm- a string containing the signature algorithm (e.g. 389 "md5", "sha-1", etc.). 391 O key type - a boolean if true, URL signing uses symmetric keys, 392 otherwise asymmetric. 394 4.6. Delivery service capability 396 Type of the delivery service a downstream CDN supports, e.g. 397 Microsoft Smooth Streaming, Apple HTTP Live Streaming. It contains 398 the following attributes: 400 O service type- a string containing the type of the delivery 401 service e.g. "HLS"and "DASH". 403 5. Overview of the capability advertising protocol 405 5.1. Transport mechansim of the protocol 407 CDN capability is information coupling with a specified application 408 (CDNI), it should be conveyed via an application layer protocol 409 rather than any other underlying layer protocol e.g. IP layer 410 protocol which should de-coupling with any application. In this 411 document HTTP/1.1 protocol [RFC2616] is used as the transport 412 mechanism for capability information advertising as its a natural 413 choice for integration with existing applications and infrastructure. 415 5.2. Operation mode of the protocol 417 The capability information advertising protocol takes two modes. One 418 is report mode, where the downstream CDN advertises its capability 419 information to the upstream CDN during at a periodic interval, e.g. 420 every 5 minutes. The other one is query mode, where the upstream CDN 421 acquires the capability information from the downstream CDN 422 periodically, e.g. every 5 minutes. The upstream CDN utilizes the 423 capability information to makes its routing decision upon receiving 424 a content request from an end user. 426 5.3. Discovery of the protocol contact point 428 To enable communication over the capability information advertising 429 protocol, the two interconnected CDNs need to know each other's 430 contact address. The contact address may be statically pre- 431 configured, dynamically discovered via control interface, or other 432 means. However, they are not specified in this document, as this is 433 considered not in the scope of the CDNI capability information 434 advertising protocol. 436 6. Protocol Specification 438 This section describes the details of the capability information 439 advertising protocol. 441 6.1. Encoding of downstream CDN information 443 6.1.1. Load status object 445 This object defines load status of resources of a downstream CDN 446 described in section 4.3. 448 Object{ 450 JSONInteger ServeStatus; 452 JSONInteger MaxConnection; 454 JSONInteger CurrentConnection; 456 JSONString MaxBandWidth; 458 JSONString CurrentBandWidth; 460 JSONString MaxCacheStorage; 462 JSONString CurrentCacheStorage; 464 }LoadStatus, 466 6.1.2. Cost object 468 Cost object defines cost preferences described in section 4.4. 470 Object{ 472 JSONString CostType; 474 JSONString CostMode; 476 JSONInteger CostValue; 478 }Cost, 480 6.1.3. Authenticity object 482 Authenticity object defines authentication capability of a 483 downstream CDN described in section 4.5. 485 Object{ 487 JSONString [AuthType]<1..*>; 489 JSONString [Algo]<1..*>; 491 JSONInteger Symmetric; 493 }Authenticity, 495 6.1.4. Footprint object 497 Footprint object defines footprint and status, capability associated 498 with the particular area the footprint identified. Footprint is 499 described in section 4.2. 501 Object{ 503 JSONString Country; 505 JSONString State; [OPTIONAL] 507 JSONString City; [OPTIONAL] 509 LoadStatus loadStatus; 511 Cost cost; 512 Authenticity authenticity; 514 JSONString [DeliveryType]<1..*>; 516 }FootPrint, 518 6.1.5. Encoding of general information 520 { 522 JSONString ServiceStatus; 524 JSONString [IPVersion]<"IPV4","IPV6">; 526 FootPrint [FootPrint]<0..*>; 528 } 530 6.2. Message description 532 The HTTP/1.1 protocol is used for capability advertising. 534 The HTTP request is HTTP POST for Report mode and HTTP GET for Query 535 mode respectively. 537 The request URI in both modes conforms to [RFC3986]. The URI format 538 in this document is as follows: HTTP:///, where the 539 specifies a destination, and the conveys the 540 message name. 542 The message body representation specified in this document takeing 543 JavaScript Object Notation(JSON) as example. However, other well- 544 defined representations (e.g., XML) are also acceptable. 546 6.2.1. Report mode 548 The Downstream CDN issues an HTTP POST message to the Upstream CDN 549 to report its capability information. 551 The message name in the request URI is "CdniCapReport". 553 The Content-Type header field is "application/json". 555 The message body includes capability information. 557 Upon successful receipt of the POST request, the Upstream CDN 558 responds with a 200 OK message. 560 6.2.2. Query mode 562 The Upstream CDN issues a HTTP GET message to a Downstream CDN to 563 query its capability information. 565 The message name in the request URI is "CdniCapQuery". 567 Upon successful receipt of the GET request, the Downstream CDN 568 responds a 200 OK message with its capability information. 570 The Content-Type header field for the response is "application/json". 572 6.3. Message examples 574 This section gives some message examples for capability information 575 advertising protocol. 577 6.3.1. Report mode 579 The POST request and corresponding response are illustrated as below. 581 Request example (Downstream CDN to Upstream CDN): 583 POST http://contact-address.ucdn.example/CdniCapReport HTTP/1.1 584 Content-Type: application/json 585 Content-Length: TBD 587 { 588 "ServiceStatus":"In", 589 "IPVersion":["IPV4","IPV6"], 590 "FootPrint":[ 591 { 592 "Country":"China", 593 "State":"Beijing", 594 "City":"", 595 "LoadStatus":{ 596 "ServeStatus":1, 597 "MaxConnection":5000, 598 "CurrentConnection":1000, 599 "MaxBandWidth":"1500M", 600 "CurrentBandWidth":"1000M", 601 "MaxCacheStorage":"5000TB", 602 "CurrentCacheStorage":"3000TB" 603 }, 604 "Cost":{ 605 "CostType" :"monetary", 606 "CostMode": "ordinal", 607 "CostValue": "1" 608 }, 609 "Authenticity":{ 610 "AuthType":["urlSigning","urlToken"], 611 "Algo":["MD5"], 612 "Symmetric":1 613 }, 614 "DeliveryType":["HLS","HSS","HDS","RTSP"] 615 },{ 616 "Country":"China", 617 "State":"Guangdong", 618 "City":"", 619 "LoadStatus":{ 620 "ServeStatus":0, 621 "MaxConnection":5000, 622 "CurrentConnection":4900, 623 "MaxBandWidth":"1500M", 624 "CurrentBandWidth":"1450M", 625 "MaxCacheStorage":"5000TB", 626 "CurrentCacheStorage":"4990TB" 627 }, 628 "Cost":{ 629 "CostType": "monetary", 630 "CostMode": "numerical", 631 "CostValue": "30" 632 }, 633 "Authenticity":{ 634 "AuthType":["urlToken"], 635 "Algo":["SHA1"], 636 "Symmetric":1 637 }, 638 "DeliveryType":["HLS","HSS","HDS","RTSP"] 639 }] 640 } 642 Response example: 643 HTTP/1.1 200 OK 645 6.3.2. Query mode 647 The GET request and corresponding response are illustrated as below. 649 Request example (Upstream CDN to Downstream CDN): 651 GET http://contact-address.dcdn.example/CdniCapQuery HTTP/1.1 653 Response example: 655 HTTP/1.1 200 OK 656 Content-Type: application/json 657 Content-Length: TBD 658 The content of message body is the same as that of POST message 659 illustrated in section 6.3.1. 661 7. Security Considerations 663 Capability advertising is a main function which will affect the 664 final routing decision of an upstream CDN, security threats on it 665 include that any identity spoofing of the downstream CDN or changing 666 of the capability advertising message with malicious intent which 667 would cause the upstream CDN redirect an end user request to an 668 inappropriate downstream CDN which possible cannot provide service 669 to the end user. 671 It is mentioned in section 8 of the requirement draft [I-D.draft- 672 cdni-requirements], all the CDNI interface shall support secure 673 operation over unsecured IP connectivity (e.g. The Internet). This 674 includes authentication, confidentiality, integrity protection as 675 well as protection against spoofing and replay. As this security 676 requirement applies to all the CDNI interfaces and it is recommended 677 that the working group addresses this issue and considers a 678 consistent solution in another separate document later. 680 8. IANA Considerations 682 If the approach described in this document is adopted, we would 683 request that IANA allocate the message name "CdniCapReport" and 684 CdniCapQuery" in the HTTP Parameters registry. 686 9. References 688 9.1. Normative References 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, March 1997. 693 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 694 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 695 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 697 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 698 Resource Identifiers (URI): Generic Syntax and Semantics", 699 RFC 3986, January 2005. 701 9.2. Informative References 703 [I-D.draft-cdni-use-cases] 704 "Use Cases for Content Delivery Network Interconnection", 705 Gilles Bertrand, Stephan Emile, Grant Watson, Trevor 706 Burbridge, Philip Eardley, Kevin Ma, 22-Sep-11, . 709 [I-D.draft-cdni-problem-statement] 710 "Content Distribution Network Interconnection (CDNI) Problem 711 Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil 712 Bitar, 9-Sep-11, . 714 [I-D.draft-cdni-requirements] 715 "Content Distribution Network Interconnection (CDNI) 716 Requirements", Kent Leung, Yiu Lee, 9-Sep-11, . 718 [I-D.davie-cdni-framework] 719 Davie, B. and L. Peterson, "Framework for CDN 720 Interconnection", draft-davie-cdni-framework-01 (work in 721 progress), July 2011. 723 [I-D.ietf-alto-protocol] 724 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 725 draft-ietf-alto-protocol-10 (work in progress), October 2011. 727 [I-D.draft-caulfield-metadata] 728 Caulfield and Leung, Ledraft-caulfield-cdni-metadata-core-00 729 "Content Distribution Network Interconnect (CDNI) Core Metadata", 730 October 2011. 732 10. Acknowledgments 734 This document was prepared using 2-Word-v2.0.template.dot. 735 The authors would like to thank Scott Wainner and Ben Niven-Jenkins 736 for their review and comments. 738 Authors' Addresses 740 Xiaoyan He 741 Huawei 742 B2, Huawei Industrial Base, 518129 743 China 745 Email: hexiaoyan@huawei.com 747 Spencer Dawkins 748 Huawei 750 Email: spencer@wonderhamster.org 752 Ge Chen 753 China Telecom 754 109 West Zhongshan Ave,Tianhe District,Guangzhou,P.R.C 756 Email: cheng@gsta.com 758 Yunfei Zhang 759 China Mobile 761 Email: zhangyunfei@chinamobile.com 763 Wei Ni 764 China Mobile 765 No.32 Xuanwumen West Street Xicheng District Beijing, 100053 766 China 768 Email: niwei@chinamobile.com