idnits 2.17.1 draft-caulfield-cdni-metadata-core-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4562 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-davie-cdni-framework-00 ** Downref: Normative reference to an Informational draft: draft-davie-cdni-framework (ref. 'I-D.davie-cdni-framework') == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-00 ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-problem-statement (ref. 'I-D.ietf-cdni-problem-statement') == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-cdni-requirements (ref. 'I-D.ietf-cdni-requirements') ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Caulfield 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: April 26, 2012 October 24, 2011 7 Content Distribution Network Interconnection (CDNI) Core Metadata 8 draft-caulfield-cdni-metadata-core-00 10 Abstract 12 The CDNI Metadata Interface enables interconnected CDNs to exchange 13 content distribution metadata for the purpose of content acquisition 14 and delivery. The CDNI metadata associated with a piece of content 15 provides a downstream CDN with the information necessary for the 16 downstream CDN to service content requests on behalf of an upstream 17 CDN in accordance with the delivery policies defined by the upstream 18 CDN. This document describes the core set of CDNI metadata that all 19 interconnected CDNs must support. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 26, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Core CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Acquisition Metadata . . . . . . . . . . . . . . . . . . . 4 58 2.2. Delivery Metadata . . . . . . . . . . . . . . . . . . . . 5 59 3. Metadata Encoding . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. ContentSource object . . . . . . . . . . . . . . . . . . . 6 61 3.2. ContentDelivery object . . . . . . . . . . . . . . . . . . 7 62 3.3. MetadataScope object . . . . . . . . . . . . . . . . . . . 7 63 3.4. Authentication object . . . . . . . . . . . . . . . . . . 7 64 3.5. DeliveryCriteria object . . . . . . . . . . . . . . . . . 8 65 3.6. DeliveryRules object . . . . . . . . . . . . . . . . . . . 8 66 3.7. Region object . . . . . . . . . . . . . . . . . . . . . . 8 67 3.8. TimeWindow object . . . . . . . . . . . . . . . . . . . . 9 68 3.9. Authorization object . . . . . . . . . . . . . . . . . . . 9 69 3.10. Reference object . . . . . . . . . . . . . . . . . . . . . 9 70 4. Metadata Transport . . . . . . . . . . . . . . . . . . . . . . 10 71 5. CDNI Metadata Interface Bootstrapping . . . . . . . . . . . . 10 72 6. Compliance with CDNI Requirements . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 77 Appendix A. Example Metadata . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Several types of metadata flow through content delivery networks. 83 For readability, a number of definitions from 84 [I-D.ietf-cdni-problem-statement] related to metadata are quoted 85 below: 87 Content Metadata: This is metadata about Content. Content 88 Metadata comprises: 90 1. CDNI Metadata: Content Distribution Metadata with inter-CDN 91 scope. For example, CDNI Metadata may include geo-blocking 92 information (i.e. information defining geographical areas 93 where the content is to be made available or blocked), 94 availability windows (i.e. information defining time windows 95 during which the content is to be made available or blocked) 96 and access control mechanisms to be enforced (e.g. URI 97 signature validation). CDNI Metadata may also include 98 information about desired distribution policy (e.g. 99 prepositioned vs dynamic acquisition) and about where/how a 100 CDN can acquire the content. CDNI Metadata may also include 101 content management information (e.g. request for deletion of 102 Content from Surrogates) across interconnected CDNs. that is 103 relevant to the distribution of the content (and therefore 104 relevant to a CDN involved in the delivery of that content). 105 We refer to this type of metadata as "Content Distribution 106 Metadata". See also the definition of Content Distribution 107 Metadata. 109 2. Metadata that is associated with the actual Content (and not 110 directly relevant to the distribution of that Content) or 111 content representation. For example, such metadata may 112 include information pertaining to the Content's genre, cast, 113 rating, etc as well as information pertaining to the Content 114 representation's resolution, aspect ratio, etc. 116 Content Distribution Metadata: The subset of Content Metadata that 117 is relevant to the distribution of the content. This is the 118 metadata required by a CDN in order to enable and control content 119 distribution and delivery by the CDN. In a CDN Interconnection 120 environment, some of the Content Distribution Metadata may have an 121 intra-CDN scope (and therefore need not be communicated between 122 CDNs), while some of the Content Distribution Metadata have an 123 inter-CDN scope (and therefore needs to be communicated between 124 CDNs). 126 CDNI Metadata: Content Distribution Metadata with inter-CDN scope. 127 For example, CDNI Metadata may include geo-blocking information 128 (i.e. information defining geographical areas where the content is 129 to be made available or blocked), availability windows (i.e. 130 information defining time windows during which the content is to 131 be made available or blocked) and access control mechanisms to be 132 enforced (e.g. URI signature validation). CDNI Metadata may also 133 include information about desired distribution policy (e.g. 134 prepositioned vs dynamic acquisition) and about where/how a CDN 135 can acquire the content. CDNI Metadata may also include content 136 management information (e.g. request for deletion of Content from 137 Surrogates) across interconnected CDNs. 139 Interconnecting CDNs necessitates the exchange of the CDNI metadata 140 as defined above. The CDNI metadata associated with a piece of 141 content (or set of contents) provides a downstream CDN with the 142 information necessary for the downstream CDN to service content 143 requests on behalf of an upstream CDN in accordance with the delivery 144 policies defined by the upstream CDN. 146 The CDNI Metadata Interface is introduced by 147 [I-D.ietf-cdni-problem-statement], and discussed in 148 [I-D.davie-cdni-framework], as one of the four required interfaces 149 for CDN interconnection. The requirements for this interface are 150 specified in [I-D.ietf-cdni-requirements]. 152 This document first describes the core set of CDNI metadata that all 153 interconnected CDNs must support. Then the document describes the 154 relationship between the core metadata and the encoding and transport 155 for exchanging that metadata. 157 2. Core CDNI Metadata 159 Although the CDNI Metadata Interface should be flexible enough to 160 support the exchange of arbitrary pieces of metadata, a CDN 161 implementing the interface must support a set of core metadata. The 162 core CDNI metadata represent common policies for content distribution 163 across CDNs. All CDNI metadata may differ on a per-content-item 164 basis or may be shared by a set of content items. The core CDNI 165 Metadata comprises acquisition metadata and delivery metadata. 167 2.1. Acquisition Metadata 169 If a downstream CDN receives a request for a content that is not yet 170 cached by that CDN, it will attempt to acquire it from either an 171 upstream CDN or an origin server. The acquisition metadata for a 172 piece of content provides the information needed by a downstream CDN 173 to acquire the missing content. The acquisition metadata includes a 174 prioritized list of content sources. Each content source includes 175 the following: 177 1. Protocol - acquisition protocol (e.g. HTTP, FTP, ...). 179 2. URI - either an explicit URI for acquiring the content or a regex 180 rule for converting from the content request URI to the 181 acquisition URI. 183 3. Authentication - an object describing the authentication type 184 (e.g. HTTP Basic, Digest, etc.) and any parameters for that type 185 (e.g. username and password). 187 2.2. Delivery Metadata 189 Once a piece of content is acquired, the delivery metadata controls 190 where, when, how, and to whom the downstream CDN may deliver that 191 content. The delivery metadata includes a list of permissible 192 delivery profiles. Each profile includes criteria and rules for 193 delivery. Profile criteria include the following: 195 1. Protocol - delivery protocol (e.g. HTTP, FTP, RTSP). 197 2. Region - a geographic region identified by country, AS number, or 198 IP subnet. 200 3. Time window - a time period including a start time and an end 201 time. 203 If a content request matches all the criteria of a profile, then the 204 rules for that profile should be applied. Profile rules include the 205 following: 207 1. Allow/deny - flag indicating whether or not the request should be 208 permitted. 210 2. Authorization - a list of permissible authorization methods and 211 their related parameters (e.g. URL-signing, token-based, etc.). 213 If a content request matches the criteria of multiple profiles in a 214 list, it should use the rules of the first matching profile. 216 3. Metadata Encoding 218 Metadata is encoded as a hierarchy of objects which in practice may 219 be implemented in JavaScript Object Notation (JSON), Extensible 220 Markup Language (XML), or another variant. This section describes 221 the structure of the data but does not prescribe a particular 222 encoding (such as JSON or XML). The language used below uses generic 223 terms like "lists", "objects", and "fields" to describe the structure 224 of the metadata. 226 Each piece of content is associated with a CDNIMetadata object which 227 has the following fields: 229 1. acquisitionOptions - an ordered list of ContentSource objects. 230 The content sources are listed in order of priority with the 231 first being the most desirable option. 233 2. deliveryProfiles - an ordered list of ContentDelivery objects. 234 Like the content sources, the content delivery profiles are 235 listed in order of priority. 237 3. metadataScope - a single MetadataScope object. 239 The CDNIMetadata object fields may be expanded in the future to 240 include a richer set of optional metadata. Proprietary fields may be 241 added with the "x-" prefix. 243 All fields in the CDNI metadata are optional unless stated otherwise. 244 If a field is missing, its default value should be used. If the 245 value of the field is the default, it need not be included. The 246 default value of a list is the empty list, an object is an empty 247 object, and a string is an empty string unless stated otherwise. 249 3.1. ContentSource object 251 The ContentSource object describes a single acquisition point that a 252 downstream CDN may contact to acquire the content. This object has 253 the following fields: 255 1. protocol - a string containing the name of the protocol that may 256 be used to acquire the content (e.g. HTTP, FTP, ...). The 257 default protocol is "http". 259 2. uriType - a string containing either "explicit" or "regex" which 260 dictates how the uri field should be interpreted. If the type is 261 "explicit", the URI is to be used as is. If the type is "regex" 262 then the uri field specifies a regex substitution that should be 263 performed on the content URL for mapping to the explicit URI. 264 The default uriType is "explicit". 266 3. uri - a string containing either the URI of the content source or 267 a regex substitution to generate the acquisition URI, depending 268 on the value of uriType. This field is required in a 269 ContentSource object and its value may not be empty. 271 4. auth - a single Authentication object. If the auth field is 272 missing, then authentication is not required for this 273 ContentSource. 275 3.2. ContentDelivery object 277 The ContentDelivery object describes a permissible delivery profile 278 for the content. This object has the following fields: 280 1. deliveryCriteria - an ordered list of DeliveryCriteria objects. 282 2. deliveryRules - a single DeliveryRules object. 284 3.3. MetadataScope object 286 The MetadataScope object indicates that a CDNIMetadata object applies 287 to more than one content and may be used as an optimization by 288 downstream CDNs to avoid refetching duplicate metadata. If a new 289 content request meets the criteria in this object, then the entire 290 CDNIMetadata object applies to that request and the downstream CDN 291 need not refetch it. The object includes the following fields: 293 1. host - an optional string containing a regex that could be 294 checked against the Host header of an incoming HTTP request. 296 2. resource - an optional string containing a regex that could be 297 checked against the requested resource name in an incoming HTTP 298 request, to determine if the metadata object is associated to the 299 requested content item. 301 3. protocol - an optional string containing a protocol name that may 302 be checked against the client request protocol (e.g. "http" or 303 "ftp"). 305 If the MetadataGroup object is missing from the CDNIMetadata object, 306 then the CDNIMetadata object only applies to the requested content 307 and may not be reused for different content requests. 309 3.4. Authentication object 311 The Authentication object describes an authentication type and its 312 parameters. It provides information for content acquisition such 313 that the downstream CDN can be authenticated as a client when 314 acquiring content from an upstream CDN or an origin server. The 315 Authentication object contains the following fields: 317 1. type - a string containing the authentication type "basic" or 318 "digest". The type dictates which optional fields are present 319 and valid in the rest of the object. The "basic" and "digest" 320 types refer to HTTP Basic and Digest access authentication 321 [RFC2617] respectively. 323 2. username - a string containing the username for "basic" and 324 "digest" types. 326 3. password - a string containing the password for "basic" and 327 "digest" types. 329 3.5. DeliveryCriteria object 331 The DeliveryCriteria object specifies a set of criteria to match 332 against incoming content requests including protocol, region, and 333 time window. The object includes the following fields: 335 1. protocol - a string containing the name of a protocol to match 336 (e.g. "http", "ftp", ...). 338 2. region - a single Region object. 340 3. timeWindow - a single TimeWindow object. 342 3.6. DeliveryRules object 344 The DeliveryRules object describes the rules to apply to a particular 345 content request in order to deliver a piece of content to the user 346 agent on behalf of an upstream CDN. This object includes the 347 following fields: 349 1. allow - a boolean stating whether or not delivery is permitted. 351 2. auth - a single Authorization object. 353 3.7. Region object 355 The Region object specifies a region where the content is either 356 allowed or disallowed. A region may be described in three ways, only 357 one of which needs to be present per Region object. The object 358 includes the following fields: 360 1. country - a string containing the country code for the region. 362 2. bgpAs - a number containing the BGP AS identifier of the region. 364 3. subnet - a string containing a dotted decimal IP address and 365 subnet mask. 367 3.8. TimeWindow object 369 The TimeWindow object specifies a time period when a content is 370 available or not available. The object includes the following 371 fields: 373 1. startTime - a string containing an ISO 8601 formatted date and 374 time in UTC. 376 2. endTime - a string containing the same format as startTime. 378 3.9. Authorization object 380 The Authorization object describes an authorization type and its 381 parameters. It provides information for content delivery such that 382 the user agent can be authenticated as a client when requesting 383 content from a downstream CDN. The Authorization object contains the 384 following fields: 386 1. type - a string containing the authorization type "url-signing" 387 or "url-token". The type dictates which optional fields are 388 present and valid in the rest of the object. The "url-signing" 389 type refers to URL signing authorization. The "url-token" type 390 refers to token-based authorization. 392 2. algo - a string containing the signature algorithm (e.g. "md5", 393 "sha-1", etc.). 395 3. symmetric - a boolean if true, URL signing uses symmetric keys, 396 otherwise asymmetric. 398 4. key - a number containing the public key for verifying 399 signatures, only valid if "symmetric" field is set to false. 401 [Editor's note: parameters for URL signing and URL token 402 authorization schemes are TBD. Private key provisioning and 403 distribution are outside the scope of the CDNI Metadata Interface. ] 405 3.10. Reference object 407 In order to avoid refetching large or common objects, any object may 408 be replaced by a Reference object. For example, the ContentSource 409 object could be replaced by a Reference object which points to a URI. 410 The downstream CDN should then request the referenced object in order 411 to complete the metadata. This object includes the following fields: 413 1. ref - a string containing a URI which points to the actual 414 object. 416 A Reference object may be distinguished from any other type of object 417 by checking for the presence of the "ref" field with a non-empty 418 value. 420 4. Metadata Transport 422 Metadata objects (JSON, XML, etc.) are assumed to be transported over 423 HTTP. This section describes the relationship between the encoding 424 and transport layers. 426 Given a content request from an end client, when the downstream CDN 427 needs to acquire the metadata associated with that content, the 428 downstream CDN uses an HTTP GET to query the upstream CDN metadata 429 server for the metadata object. 431 The parameters to the query request are identical to the fields of 432 the MetadataScope object discussed earlier. This similarity is 433 intentional and allows the downstream CDN to avoid refetching the 434 same metadata for two different pieces of content (if the metadata is 435 the same). The query parameters are extracted from an incoming 436 content request and are as follows: 438 1. host - the value of the Host header in an HTTP request. 440 2. resource - the resource on the request line of the HTTP request. 442 3. protocol - the protocol of the incoming request. 444 After extracting these fields from the content request, the 445 downstream CDN should first check its existing cache of metadata 446 objects for possible matches (using the MetadataScope object). If no 447 match is found, the downstream CDN should then form a request to the 448 upstream CDN metadata server, appending the host, resource, and 449 protocol as query string parameters. 451 The metadata server will respond with a CDNIMetadata object encoded 452 in JSON, XML, or some other variant. 454 5. CDNI Metadata Interface Bootstrapping 456 This document makes a number of assumptions regarding the information 457 available to the downstream CDN which is not part of the CDNI Core 458 Metadata. Information such as how a downstream CDN learns the 459 address or hostname of the upstream metadata server is briefly 460 described below. 462 In the simplest case, the Control Interface will provision the URI of 463 the metadata server to the downstream CDN and all metadata requests 464 will be sent directly to this server. The Control Interface could 465 also provision an alternative URI in case the primary server is 466 unreachable. 468 In the case of multiple potential upstream CDNs, the downstream CDN 469 must decide which metadata server should handle its request. It is 470 expected that the downstream CDN will be able to determine the 471 upstream CDN that redirected that particular request from information 472 contained in the received request (e.g. via the URI in case of HTTP 473 redirection across CDNs). With knowledge of which upstream CDN 474 routed the request, the downstream CDN can choose the correct 475 metadata server. 477 6. Compliance with CDNI Requirements 479 This section reviews compliance of the solution proposed in this 480 document against the relevant set of requirements from 481 [I-D.ietf-cdni-requirements]. 483 [Editor's note: the compliance information will be provided in 484 subsequent versions] 486 7. IANA Considerations 488 This document makes no request of IANA. 490 Note to RFC Editor: this section may be removed on publication as an 491 RFC. 493 8. Security Considerations 495 The CDNI Metadata Interface is expected to be secured as a function 496 of the transport protocol (e.g. HTTP authentication). 498 If a malicious metadata server is contacted by a downstream CDN, the 499 malicious server may provide metadata to the downstream CDN which 500 denies service for any piece of content to any user agent. The 501 malicious server may also provide metadata which directs a downstream 502 CDN to a malicious origin server instead of the actual origin server. 504 9. Acknowledgements 506 The authors would like to thank Francois le Faucheur for his input 507 and review. 509 10. Normative References 511 [I-D.davie-cdni-framework] 512 Davie, B. and L. Peterson, "Framework for CDN 513 Interconnection", draft-davie-cdni-framework-00 (work in 514 progress), July 2011. 516 [I-D.ietf-cdni-problem-statement] 517 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 518 Distribution Network Interconnection (CDNI) Problem 519 Statement", draft-ietf-cdni-problem-statement-00 (work in 520 progress), September 2011. 522 [I-D.ietf-cdni-requirements] 523 Leung, K. and Y. Lee, "Content Distribution Network 524 Interconnection (CDNI) Requirements", 525 draft-ietf-cdni-requirements-01 (work in progress), 526 October 2011. 528 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 529 Leach, P., Luotonen, A., and L. Stewart, "HTTP 530 Authentication: Basic and Digest Access Authentication", 531 RFC 2617, June 1999. 533 Appendix A. Example Metadata 535 Below is an example of a JSON object encoding a piece of CDNI 536 metadata. This metadata object applies to any content request with a 537 hostname of "origin.example.com" and a resource identifier matching 538 the regular expression "*/movies/*". The "metadataScope" field 539 summarizes these properties. There is a single acquisition option as 540 seen in the "acquisitionOptions" list. The "deliveryProfiles" 541 information restricts users in subnet "10.1.2.0/24" or using RTSP 542 from accessing this content and allows users using HTTP. 543 { 544 "acquisitionOptions" : 545 [ 546 { 547 "protocol" : "http", 548 "uri" : "http://origin.example.com/movies/content.mpg", 549 "auth" : 551 { 552 "type" : "basic", 553 "username" : "abcd", 554 "password" : "pass123" 555 } 556 } 557 ], 558 "deliveryProfiles" : 559 [ 560 { 561 "deliveryCriteria" : 562 [ 563 { 564 "region" : { "subnet" : "10.1.2.0/24" }, 565 }, 566 { 567 "protocol" : "rtsp" 568 } 569 ], 570 "deliveryRules" : 571 { 572 "allow" : false 573 } 574 }, 575 { 576 "deliveryCriteria" : 577 [ 578 { 579 "protocol" : "http" 580 } 581 ], 582 "deliveryRules" : 583 { 584 "allow" : true 585 } 586 } 587 ], 588 "metadataScope" : 589 { 590 "host" : "origin.example.com", 591 "resource" : "*/movies/*" 592 } 593 } 595 Authors' Addresses 597 Matt Caulfield 598 Cisco Systems 599 1414 Massachusetts Ave 600 Boxborough, MA 01719 601 USA 603 Phone: +1 978 936 9307 604 Email: mcaulfie@cisco.com 606 Kent Leung 607 Cisco Systems 608 3625 Cisco Way 609 San Jose 95134 610 USA 612 Phone: +1 408 526 5030 613 Email: kleung@cisco.com