idnits 2.17.1 draft-cjlmw-cdni-metadata-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4281 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) == Missing Reference: 'I-D.jenkins-cdni-names' is mentioned on line 708, but not defined == Unused Reference: 'I-D.zyp-json-schema' is defined on line 1415, but no explicit reference was found in the text == Unused Reference: 'RFC4287' is defined on line 1428, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-davie-cdni-framework-00 == 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 (-04) exists of draft-zyp-json-schema-03 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft R. Murray 4 Intended status: Standards Track G. Watson 5 Expires: January 10, 2013 Velocix (Alcatel-Lucent) 6 M. Caulfield 7 K. Leung 8 Cisco Systems 9 July 9, 2012 11 CDN Interconnect Metadata 12 draft-cjlmw-cdni-metadata-00 14 Abstract 16 The CDNI Metadata Interface enables interconnected CDNs to exchange 17 content distribution metadata in order to enable content acquisition 18 and delivery. The CDNI metadata associated with a piece of content 19 provides a downstream CDN with sufficient information for the 20 downstream CDN to service content requests on behalf of an upstream 21 CDN. This document describes both the core set of CDNI metadata and 22 the protocol for exchanging that metadata. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 10, 2013. 47 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5 66 3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . . 5 67 3.1. HostIndex, HostMetdata & PathMetadata objects . . . . . . 6 68 3.2. Remaining CDNI Metadata objects . . . . . . . . . . . . . 9 69 3.3. Metadata Inheritance . . . . . . . . . . . . . . . . . . . 12 70 4. Encoding-Independent CDNI Metadata Object Descriptions . . . . 12 71 4.1. CDNI Metadata Data Object Descriptions . . . . . . . . . . 12 72 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 13 74 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . . 13 75 4.1.4. Acquisition . . . . . . . . . . . . . . . . . . . . . 14 76 4.1.5. Delivery . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.1.6. PathMatch . . . . . . . . . . . . . . . . . . . . . . 15 78 4.1.7. PathMetadata . . . . . . . . . . . . . . . . . . . . . 15 79 4.1.8. ACL . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.1.9. ACLRule . . . . . . . . . . . . . . . . . . . . . . . 16 81 4.1.10. TimeWindow . . . . . . . . . . . . . . . . . . . . . . 16 82 4.1.11. Location . . . . . . . . . . . . . . . . . . . . . . . 17 83 4.1.12. Source . . . . . . . . . . . . . . . . . . . . . . . . 17 84 4.1.13. Auth . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 4.1.14. Link . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 4.2. CDNI Metadata Simple Data Type Descriptions . . . . . . . 19 87 4.2.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . 19 88 4.2.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 19 89 4.2.3. IPRange . . . . . . . . . . . . . . . . . . . . . . . 19 90 4.2.4. Pattern . . . . . . . . . . . . . . . . . . . . . . . 20 91 4.2.5. PatternFlags . . . . . . . . . . . . . . . . . . . . . 20 92 4.2.6. URI . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 4.2.7. Time . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 5. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 21 95 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 21 96 5.2. Retrieval of CDNI Metadata resources . . . . . . . . . . . 22 97 5.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 23 98 5.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 5.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . . 23 100 5.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . . 24 101 5.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . . 25 102 5.4.3. XML Encoding of Objects . . . . . . . . . . . . . . . 27 103 5.4.3.1. XML Example . . . . . . . . . . . . . . . . . . . 28 104 5.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 30 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 110 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 111 Appendix A. Relationship to the CDNI Requirements . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 114 1. Introduction 116 CDNI enables a downstream CDN to service content requests on behalf 117 of an upstream CDN. In the simplest use case, a content request 118 received by the downstream CDN provides sufficient information for 119 sending a response. More complex use cases require additional 120 context, i.e. metadata. The CDNI metadata associated with a piece of 121 content (or with a set of contents) provides a downstream CDN with 122 sufficient information for servicing content requests on behalf of an 123 upstream CDN in accordance with the policies defined by the upstream 124 CDN. 126 The CDNI Metadata Interface is introduced by 127 [I-D.ietf-cdni-problem-statement] along with three other interfaces 128 that may be used to compose a CDNI solution (Control, Request Routing 129 and Logging). [I-D.davie-cdni-framework] expands on the information 130 provided in [I-D.ietf-cdni-problem-statement] and describes each 131 interface, and the relationships between them, in more detail. The 132 requirements for the CDNI metadata interface are specified in 133 [I-D.ietf-cdni-requirements] 135 This document focuses on the CDNI Metadata interface which enables a 136 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 137 the downstream CDN can properly process and respond to: 139 o Redirection Requests received over the CDNI Request Routing 140 protocol. 141 o Content Requests received directly from User Agents. 143 Specifically this document proposes: 145 o A data structure for mapping content requests to CDNI Metadata 146 properties (Section 3). 147 o An initial set of CDNI Metadata properties (Section 4.1 through 148 Section 4.2). 149 o A RESTful web service for the transfer of CDNI Metadata 150 (Section 5). 152 1.1. Terminology 154 This document reuses the terminology defined in 155 [I-D.ietf-cdni-problem-statement]. 157 Additionally, the following terms are used throughout this document 158 and are defined as follows: 159 o Object - a collection of properties 160 o Property - a key / value pair where the key is a property name and 161 the value is the property value (possibly an object) 163 2. Design Principles 165 The proposed CDNI Metadata Interface aims to achieve the following 166 design principles: 168 1. Cacheability of CDNI metadata objects 169 2. Deterministic mapping from content requests to CDNI metadata 170 properties 171 3. Support for DNS redirection as well as application-specific 172 redirection (for example HTTP redirection) 173 4. Minimal duplication of CDNI metadata 174 5. Leverage existing protocols 176 Cacheability improves the latency of acquiring metadata and therefore 177 improves the latency of serving content requests. The CDNI Metadata 178 Interface uses HTTP to achieve cacheability. 180 Deterministic mappings from content requests to metadata properties 181 eliminates ambiguity and ensures that the same policies are applied 182 consistently by all downstream CDNs. 184 Support for both HTTP and DNS redirection ensures that the CDNI 185 Metadata Interface can be used for HTTP and DNS redirection and also 186 meets the same design principles for both HTTP and DNS based 187 redirection schemes. 189 Minimal duplication of CDNI metadata provides space efficiency on 190 storage in the CDNs, on caches in the network, and across the network 191 between CDNs. 193 Leveraging existing protocols avoids reinventing common mechanisms 194 such as data structure encoding (e.g. XML, JSON) and data transport 195 (e.g. HTTP). 197 3. CDNI Metadata Data Model 199 The CDNI Metadata Model describes a data structure for mapping 200 content requests to metadata properties. Metadata properties 201 describe how to acquire, authorize, and deliver content from a 202 downstream CDN. The data model relies on the assumption that these 203 metadata properties may be aggregated based on the authoritative 204 hostname of the content and subsequently on the resource path of the 205 content. The data model associates a set of CDNI Metadata properties 206 with a Hostname to form a default set of metadata properties for 207 content delivered for that Hostname. That default set of metadata 208 properties can be overridden by properties that apply to specific 209 paths within a URI. 211 Different Hostnames and URI paths will contain different sets of CDNI 212 Metadata properties in order to describe the required behaviour when 213 a dCDN surrogate is processing User Agent requests for content on 214 that Hostname or URI path. As a result of this structure, 215 significant commonality may exist between the CDNI Metadata 216 properties specified for different Hostnames, different URI paths 217 within a Hostname and different URI paths on different Hostnames. 218 For example the definition of which User Agent IP addresses should be 219 treated as being grouped together into a single network or geographic 220 location is likely to be common for a number of different Hostnames. 221 Another example is that although a uCDN is likely to have several 222 different policies configured to express geo-blocking rules, it is 223 likely that a single geo-blocking policy would be applied to multiple 224 Hostnames delivered through the CDN. 226 In order to enable the CDNI Metadata for a given Hostname or URI Path 227 to be decomposed into sets of CDNI Metadata properties that can be 228 reused by multiple Hostnames and URI Paths the CDNI Metadata 229 interface specified in this document splits the CDNI Metadata into a 230 number of objects. Efficiency is improved by enabling a single CDNI 231 Metadata object (that is shared across Hostname and/or URI paths) to 232 be retrieved by a dCDN once, even if it is referenced by the CDNI 233 Metadata of multiple Hostnames. 235 Section 3.1 introduces a high level description of the HostIndex, 236 HostMetadata and PathMetadata objects and describes the relationships 237 between those objects. 239 Section 3.2 introduces a high level description of the remaining CDNI 240 Metadata objects and describes the relationships between those 241 objects as well as the relationships of those objects to HostMetadata 242 and PathMetadata objects. 244 Section 4.1 describes the specific properties of each object in more 245 detail. 247 3.1. HostIndex, HostMetdata & PathMetadata objects 249 A HostIndex object contains a list of Hostnames that may be delegated 250 to the downstream CDN. The HostIndex is the starting point for 251 accessing the uCDN's CDNI Metadata data store. It enables surrogates 252 in the dCDN to deterministically discover, on receipt of a User Agent 253 request for content, which other CDNI Metadata objects it requires in 254 order to deliver the requested content. 256 The HostIndex links end-user facing Hostnames to HostMetadata 257 objects, which contain (or reference) the default CDNI Metadata 258 required to serve content for that Hostname. When looking up CDNI 259 Metadata, the downstream CDN looks up the requested Hostname in the 260 HostIndex, from there it can find HostMetadata which describes 261 delivery rules for a Hostname and PathMetadata which may override 262 those rules for given URI paths within the Hostname. 264 As well as containing the default CDNI Metadata for the specified 265 Hostname, HostMetadata and PathMetadata objects may also contain 266 PathMatch objects which in turn contain PathMetadata objects. 267 PathMatch objects override the CDNI Metadata in the HostMetadata 268 object or one or more preceding PathMetadata objects with more 269 specific CDNI Metadata that applies to content requests matching the 270 pattern defined in that PathMatch object. 272 For the purposes of retrieving CDNI Metadata all other required CDNI 273 Metadata objects and their properties are discoverable from the 274 appropriate HostMetadata, PathMatch and PathMetadata objects for the 275 requested content. 277 The relationships between the HostIndex, HostMatch, HostMetadata, 278 PathMatch and PathMetadata objects are described in Figure 1. 280 +---------+ +---------+ +------------+ 281 |HostIndex+---->|HostMatch|---->|HostMetadata+----------------+ 282 +---------+ +---------+ +------+-----+ | 283 | | 284 V V 285 +---------+ ************************ 286 +--->|PathMatch| *Other Metadata Objects* 287 | +---------+ ************************ 288 | | ^ 289 | V | 290 | +------------+ | 291 +--|PathMetadata+----------------+ 292 +------------+ 294 Key: ----> = References 296 Figure 1: Relationships between the HostIndex, HostMetadata & 297 PathMetadata CDNI Metadata Objects 299 The table below describes the HostIndex, HostMetadata and 300 PathMetadata objects in more detail. 302 +--------------+----------------------------------------------------+ 303 | Data Object | Description | 304 +--------------+----------------------------------------------------+ 305 | HostIndex | A HostIndex object lists the Hostnames that an | 306 | | upstream CDN can provide CDNI metadata for and the | 307 | | URIs to use for retrieving that CDNI Metadata. | 308 | | For example, if "example.com" is a content | 309 | | provider, the HostIndex object may include an | 310 | | entry for "example.com" with the URI of the | 311 | | associated HostMetadata object. These hostnames | 312 | | are contained inside a list of HostMatch objects. | 313 | HostMatch | A HostMatch object defines a hostname to match | 314 | | against a requested host, and contains or | 315 | | references a HostMetadata object which contains | 316 | | CDNI Metadata properties to be applied when a | 317 | | content request matches against the hostname. | 318 | HostMetadata | A HostMetadata object contains (or references) the | 319 | | default CDNI Metadata properties for content | 320 | | served from that hostname, i.e. the CDNI Metadata | 321 | | properties for content requests that do not match | 322 | | any of the PathMatch objects contained or | 323 | | referenced by that HostMetadata object. For | 324 | | example, a HostMetadata object may describe the | 325 | | metadata properties which apply to "example.com" | 326 | | and may contain PathMatches for | 327 | | "example.com/movies/*" and "example.com/music/*" | 328 | | which reference corresponding PathMetadata objects | 329 | | that contain the CDNI Metadata properties for | 330 | | those specific URI paths. | 331 | PathMatch | A PathMatch object defines a pattern to match | 332 | | against the requested path, and contains or | 333 | | references a PathMetadata object which contains | 334 | | (or references) the CDNI Metadata properties to be | 335 | | applied when a content request matches against the | 336 | | defined URI path pattern. | 337 | PathMetadata | A PathMetadata object contains the CDNI Metadata | 338 | | properties for content served with the associated | 339 | | URI path (defined in a PathMatch object). A | 340 | | PathMetadata object may also contain PathMatch | 341 | | objects in order to recursively define more | 342 | | specific URI paths that require different (e.g. | 343 | | more specific) CDNI Metadata to this one. For | 344 | | example, the PathMetadata object which applies to | 345 | | "example.com/movies/*" may describe CDNI metadata | 346 | | which apply to that resource path and may contain | 347 | | a PathMatch object for "example.com/movies/hd/*" | 348 | | which would reference the corresponding | 349 | | PathMetadata object for the | 350 | | "example.com/movies/hd/" path prefix. | 351 +--------------+----------------------------------------------------+ 353 Table 1: HostIndex, HostMetadata and PathMetadata CDNI Metadata 354 Objects 356 3.2. Remaining CDNI Metadata objects 358 The HostMetadata and PathMetadata objects contain or can reference 359 other CDNI Metadata objects that contain properties which describe 360 how User Agent requests for content should be processed, for example 361 where to acquire the content, authorization rules that should be 362 applied, delivery location restrictions and so on. The properties 363 associated with the processing of User Agent requests fall into two 364 categories, Delivery and Acquisition. Delivery properties, such as 365 Location based restrictions, are contained or referenced within a 366 Delivery object. Acquisition properties, such as which Origin Server 367 to use to acquire the content, are contained or referenced within an 368 Acquisition Object. Delivery and Acquisition objects contain or 369 reference other CDNI Metadata objects to define the properties and 370 rules which should be applied when processing requests for content. 371 In some cases the rules that should be applied are complex but also 372 likely to be reusable and repeated across many HostMetadata or 373 PathMetadata objects. 375 The relationships between the HostMetadata and PathMetadata objects 376 and the other CDNI Metadata objects (Delivery object, Acquisition 377 object, etc.) required for CDNI request routing and delivery are 378 illustrated in Figure 2. 380 +-------------+ +----------------+ 381 +--------------+ +--> | Acquisition | -----> | Source | 382 | HostMetadata | | +-------------+ +----------------+ 383 | - or - | ---+ 384 | PathMetadata | | +-------------+ +----------------+ 385 +--------------+ +--> | Delivery | --+--> | TimeWindow ACL | 386 +-------------+ | +----------------+ 387 | 388 | +----------------+ 389 +--> | Location ACL* | 390 | +----------------+ 391 | 392 | +----------------+ 393 +--> | Auth | 394 +----------------+ 396 *example ACL 398 +----------------+ +----------------+ 399 | Location ACL | = | ACL | 400 +----------------+ +----------------+ 401 | 402 v 403 +----------------+ 404 | ACL Rules | 405 +----------------+ 406 | 407 v 408 +----------------+ 409 | Location | 410 +----------------+ 412 Key: ----> = References 414 Figure 2: Relationships between HostMetadata and PathMetadata and the 415 other CDNI Metadata Objects 417 The table below describes the remaining CDNI Metadata objects that 418 were not defined in Section 3.1. 420 +-------------+-----------------------------------------------------+ 421 | Data Object | Description | 422 +-------------+-----------------------------------------------------+ 423 | Acquisition | Container object for metadata that applies to | 424 | | content acquisition. | 425 | Delivery | Container object for metadata that applies to | 426 | | content delivery. | 427 | Source | Information needed by a dCDN to acquire content. | 428 | | For example the host to contact, the protocol to | 429 | | use for acquisition and any authentication and | 430 | | authorization methods that should be used. | 431 | ACL | Contains or references a list of ACLRules that are | 432 | | used to define any delivery restrictions that must | 433 | | be applied e.g. Location restrictions or Time | 434 | | based restrictions. | 435 | ACLRule | Contains or references a list of objects which | 436 | | define to what the restrictions should be applied | 437 | | e.g. an ACLRule may reference a Location Object if | 438 | | a location based ACL is required. | 439 | TimeWindow | Start and end time used to specify windows of | 440 | | availability or unavailability for the content. | 441 | Location | Geographic or network location identified by | 442 | | country code, BGP AS number, or subnet to which | 443 | | content may (or may not) be delivered. | 444 | Auth | Method and credentials for authentication and | 445 | | authorization including URI-signing, token-base, | 446 | | etc. | 447 +-------------+-----------------------------------------------------+ 449 Table 2: Content Distribution Metadata Data Objects 451 The relationships in Figure 1 and Figure 2 are summarised in Table 3 452 below and the properties of each object are described in Section 4.1. 454 +--------------+----------------------------------------------------+ 455 | Data Object | Objects it References | 456 +--------------+----------------------------------------------------+ 457 | HostIndex | 0 or more HostMetadata objects. | 458 | HostMetadata | 0 or more PathMatch objects. 0 or 1 Delivery | 459 | | objects. 0 or 1 Acquisition objects. | 460 | PathMatch | 1 PathMetadata object. | 461 | PathMetadata | 0 or more PathMatch objects. 0 or 1 Delivery | 462 | | objects. 0 or 1 Acquisition objects. | 463 | Acquisition | 0 or more Source objects. | 464 | Delivery | 0 or more ACL objects. 0 or more Auth objects. | 465 | ACL | 0 or more ACLRule objects. | 466 | ACLRule | 0 or more Location objects or 0 or more TimeWindow | 467 | | objects. | 468 +--------------+----------------------------------------------------+ 470 Table 3: Relationships between CDNI Metadata Objects 472 3.3. Metadata Inheritance 474 In the data model, a HostMetadata object may contain (or reference) 475 multiple PathMetadata objects. Each PathMetadata object may in turn 476 contain (or reference) other PathMetadata objects. These 477 relationships form a tree. 479 The tree of HostMetadata objects and PathMetadata objects forms an 480 inheritance tree. Each node in the tree inherits the property values 481 set by its parent. 483 In the tree, a child may override any property value which has been 484 set by its parent. If a HostMetadata object sets the value of a 485 property, that value may be overridden by a PathMetadata object (the 486 child of the HostMetadata object). If a PathMetadata object contains 487 (or references) other PathMetadata objects as children, then those 488 children PathMetadata objects may override the property values set by 489 the parent PathMetadata object. 491 If a child node overrides the value of a list, then the entire list 492 is replaced with the value set by the child node. If a child node 493 overrides the value of an object, then the whole object is replaced 494 with the value set by the child node. 496 4. Encoding-Independent CDNI Metadata Object Descriptions 498 This section provides the definitions of each object type declared in 499 Section 3. The definition of each object contains an unordered set 500 of properties. The type of some properties is another CDNI Metadata 501 object and in those cases the value of the property can be either an 502 object of that type (the object is embedded) or a Link object that 503 describes a URI and relationship that can be dereferenced to retrieve 504 the CDNI Metadata object that should be used as the value of that 505 property. 507 4.1. CDNI Metadata Data Object Descriptions 509 Each of the sub-sections below describes the properties associated 510 with the data objects defined in Table 2. 512 4.1.1. HostIndex 514 The HostIndex object is the entry point into the CDNI Metadata 515 hierarchy. An incoming content request is matched against the list 516 of hosts to find the HostMatch object which applies to the request. 518 Property: hosts 519 Description: List of HostMatch objects 520 Type: List of HostMatch 521 Mandatory: Yes. 523 4.1.2. HostMatch 525 The HostMatch object contains a hostname to match against and a 526 metadata object to apply if a match is found. 528 Property: hostname 529 Description: String to match against the requested host. 530 Type: String 531 Mandatory: Yes 532 Property: hostmetadata 533 Description: CDNI Metadata to apply when delivering content 534 that matches this pattern. 535 Type: HostMetadata 536 Mandatory: Yes 538 4.1.3. HostMetadata 540 The HostMetadata object contains both metadata that applies to 541 content requests for a particular host and a list of pattern matches 542 for finding more specific metadata based on the resource path in a 543 content request. 545 Property: acquisition 546 Description: Container for content acquisition related 547 metadata. 548 Type: Acquisition 549 Mandatory: No. No default. 550 Property: delivery 551 Description: Container for content delivery related metadata. 552 Type: Delivery 553 Mandatory: No. No default. 554 Property: paths 555 Description: Path specific rules. First match applies. 556 Type: List of PathMatch 557 Mandatory: No. Default apply the properties defined in this 558 HostMetadata object to all paths. 560 Property: hostname 561 Description: The end-user facing Hostname for this HostMetadata 562 object. 563 Type: Hostname 564 Mandatory: Yes. 566 4.1.4. Acquisition 568 Metadata which provides the dCDN information about content 569 acquisition e.g. how to contact an uCDN Surrogate or an Origin 570 Server. The sources are not necessarily the actual Origin Servers 571 operated by the CSP but might be a set of Surrogates in the uCDN. 573 Property: sources 574 Description: Sources from which the dCDN can acquire content. 575 Type: List of Source 576 Mandatory: No. Defaults to empty list. 578 4.1.5. Delivery 580 Metadata related to content delivery, e.g. delivery restrictions or 581 content authorization methods. 583 Property: locations 584 Description: Access control list which applies restrictions to 585 delivery based on client location. 586 Type: ACL 587 Mandatory: No. Defaults is allow all locations. 588 Property: times 589 Description: Access control list which applies restrictions to 590 delivery based on request time. 591 Type: ACL 592 Mandatory: No. Defaults is allow all times. 593 Property: auth 594 Description: Options for authenticating content requests. All 595 options in the list are equally valid. 596 Type: List of Auth 597 Mandatory: No. Defaults is no auth. 598 Property: protocol 599 Description: The delivery protocol to be used for content 600 requests that match this HostMetadata object. 601 Type: protocol 602 Mandatory: Yes. 603 Property: active 604 Description: Enable or disable delivery from this host. 605 Type: boolean 606 Mandatory: No. Default yes. 608 4.1.6. PathMatch 610 The PathMatch object contains an expression to match against and a 611 metadata object to apply if a match is found. 613 Property: pattern 614 Description: String to match against the requested path, i.e. 615 against the [RFC3986] path-absolute. 616 Type: Pattern 617 Mandatory: Yes 618 Property: patternflags 619 Description: Flags to control the pattern match. 620 Type: List of PatternFlags 621 Mandatory: No. Default Case-sensitive infix matching. 622 Property: pathmetadata 623 Description: CDNI Metadata to apply when delivering content 624 that matches this pattern. 625 Type: PathMetadata 626 Mandatory: Yes 628 4.1.7. PathMetadata 630 A PathMetadata object contains the CDNI Metadata properties for 631 content served with the associated URI path (defined in a PathMatch 632 object). Note that if CDNI metadata is used as an input to CDNI 633 request routing and DNS-based redirection is employed, then any 634 metadata at the PathMetadata level or below will be inaccessible at 635 request routing time. 637 PathMetadata objects may contain any of the properties of a 638 HostMetadata object with the following exceptions: 640 o PathMetadata objects MUST NOT contain a hostname property. 641 o PathMetadata objects MUST NOT contain a protocol property. 642 o The presence of an sources property is OPTIONAL. 644 4.1.8. ACL 646 An ACL object contains or references a list of ACLRule objects which 647 define a set of restrictions to apply to content delivery e.g. 648 Location restrictions. An ACL may reference or contain ACLRules 649 referencing or containing Location or TimeWindow objects but not 650 both. 652 Property: aclrules 653 Description: 654 Type: List of ACLRule 655 Mandatory: No. Default no rules. 657 4.1.9. ACLRule 659 An ACLRule contains or references a list of either TimeWindow or 660 Location objects. ACLRule objects are used to construct ACL to apply 661 restrictions to content delivery. 663 Note: Although both the allow and deny properties are optional, one 664 and only one of them MUST be present in an ACLRule. An ACLRule must 665 also only refer to one of Location or TimeWindow but not both and 666 should only refer to the objects relevant to the ACL type as defined 667 by Delivery Metadata i.e. a Delivery Metadata object with an ACL with 668 relationship of LocationACL must not reference TimeWindow objects 669 further down in the Metadata hierarchy. 671 Property: allow 672 Description: List of either Locations (Location ACL) or Time 673 Windows (TimeWindow ACL) which must be allowed. 674 Type: List of Location or TimeWindow 675 Mandatory: No. Default implicit Allow. 676 Property: deny 677 Description: List of either Locations (Location ACL) or Time 678 Windows (TimeWindow ACL) which must be denied. 679 Type: List of Location or TimeWindow 680 Mandatory: No. Default implicit Deny. 682 4.1.10. TimeWindow 684 A TimeWindow object describes a time range which may be applied by an 685 ACLRule, e.g. Start 09:00AM 01/01/2000 End 17:00PM 01/01/2000. 687 Property: start 688 Description: The start time of the window. 689 Type: Time 690 Mandatory: Yes 691 Property: end 692 Description: The end time of the window. 693 Type: Time 694 Mandatory: Yes 696 4.1.11. Location 698 A Location object describes a Location which may be applied by an 699 ACLRule, e.g. a Location may be an IPv4 address range or a geographic 700 location. 702 Property: iprange 703 Description: A set of IP Addresses. 704 Type: List of IPRange. 705 Mandatory: Yes 707 [Ed: Location as specified above only supports the Class 1a names 708 described in [I-D.jenkins-cdni-names]. Need to add support for Class 709 1b names to a later version.] 711 4.1.12. Source 713 A Source object describes the Source which should be used by the dCDN 714 for content acquisition, e.g. a Surrogate within the uCDN or an 715 alternate Origin Server, the protocol to be used and any 716 authentication method. 718 Property: auth 719 Description: Authentication method to use when requesting 720 content from this source. 721 Type: Auth 722 Mandatory: No. Default is no authentication. 723 Property: endpoints 724 Description: Origins from which the dCDN can acquire content. 725 Type: List of EndPoint 726 Mandatory: Yes. 727 Property: protocol 728 Description: Protocol to use for content acquisition. 729 Type: Protocol 730 Mandatory: Yes. 732 4.1.13. Auth 734 An Auth object defines authentication and authorization methods to be 735 used during content delivery and content acquisition, e.g. methods 736 such as tokenization and URL Signing. 738 Property: type 739 Description: A string containing the authentication type "url- 740 signing", "url-token", "http-basic", or "http-digest". The 741 type dictates which optional fields are present and valid in 742 the rest of the object. The "url-signing" type refers to URL 743 signing authentication. The "url-token" type refers to token- 744 based authentication. The "basic" and "digest" types refer to 745 HTTP Basic and Digest access authentication. 746 Type: String 747 Mandatory: Yes. 748 Property: algo 749 Description: A string containing the signature algorithm (e.g. 750 "md5", "sha-1", etc.). 751 Type: String 752 Mandatory: Yes, if type is "url-signing". 753 Property: symmetric 754 Description: A boolean if true, URL signing uses symmetric 755 keys, otherwise asymmetric. 756 Type: boolean 757 Mandatory: Yes, if type is "url-signing". 758 Property: key 759 Description: A hex-encoded number containing the public key for 760 verifying signatures, only valid if "symmetric" field is set to 761 false. 762 Type: boolean 763 Mandatory: Yes, if type is "url-signing". 764 Property: username 765 Description: A string containing the username for "basic" and 766 "digest" types. 767 Type: String 768 Mandatory: Yes, if type is "basic" or "digest". 769 Property: password 770 Description: A string containing the password for "basic" and 771 "digest" types. 772 Type: String 773 Mandatory: Yes, if type is "basic" or "digest". 775 4.1.14. Link 777 A link object may be used in place of any of the objects described 778 above. Links can be used to avoid duplication if the same metadata 779 information is repeated within the metadata tree. When a link 780 replaces an object, its href property is set to the URI of the 781 resource, its rel property is set to the name of the property it is 782 replacing, and its type property is set to the type of the object it 783 is replacing. 785 Property: href 786 Description: The URI of the of the addressable object being 787 referenced. 788 Type: URI 789 Mandatory: Yes 791 Property: rel 792 Description: The Relationship between the referring object and 793 the object it is referencing. 794 Type: String 795 Mandatory: Yes 796 Property: type 797 Description: The type of the object being referenced. 798 Type: String 799 Mandatory: Yes 801 4.2. CDNI Metadata Simple Data Type Descriptions 803 This section describes the simpler data types that are used for 804 properties of CDNI Metadata objects. 806 4.2.1. Protocol 808 This type only appears in Links. Links with this type are not 809 machine readable but rather represent particular feature sets of a 810 protocol defined in a specification and implemented in code. The URI 811 contained in the link needs to be defined for each delivery protocol 812 with an associated interoperable feature set. 814 The following examples are illustrative: 816 o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD 817 o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH 818 o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q 820 [Editor's Note: It may be more appropriate to use the 'tag' URI 821 scheme [RFC4151] for these URIs.] 823 4.2.2. Endpoint 825 A hostname (with optional port) or an IP address (with optional 826 port). 828 Note: Client implementations MUST support IPv4 addresses encoded as 829 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 830 MUST support all IPv6 address formats specified in [RFC4291]. Server 831 implementations SHOULD use IPv6 address formats specified in 832 [RFC5952]. 834 4.2.3. IPRange 836 One of: 838 o A range of consecutive IP addresses (IPv4 or IPv6) expressed as 839 Address1-Address2 which does not have to be to power of two 840 aligned, for example the range 192.0.2.1-192.0.2.10 is valid. The 841 first Address in the range MUST be 'lower' than the final address 842 in the range. 843 o A valid IP subnet (IPv4 or IPv6) expressed using CIDR notation. 844 o A single IP address (IPv4 or IPv6). 846 Note: Client implementations MUST support IPv4 addresses encoded as 847 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 848 MUST support all IPv6 address formats specified in [RFC4291]. Server 849 implementations SHOULD use IPv6 address formats specified in 850 [RFC5952]. 852 4.2.4. Pattern 854 A pattern for string matching paths. The string may contain the 855 wildcards * and ?. 857 o * matches any sequence of characters (including the empty string). 858 o ? matches exactly one character. 860 Escaping: The three literals \ , * and ? should be escaped as \\, \* 861 and \? 863 4.2.5. PatternFlags 865 A set of flags indicating how a pattern match is made. The flags 866 are: 868 o Case-insensitive - Perform a case insensitive match (absence 869 indicates case-sensitive match). 870 o Prefix - Match against the start of the string (absence indicates 871 that a match may start anywhere in the string). 872 o Suffix - Match against the end of the string (absence indicates 873 that a match may end anywhere in the string). 875 Absence of both Prefix and Suffix results in a match against any part 876 of the string (infix). 878 4.2.6. URI 880 A URI as specified in [RFC3986]. 882 4.2.7. Time 884 A time value expressed in seconds since Unix epoch in the UTC 885 timezone. 887 5. CDNI Metadata interface 889 This section specifies an interface to enable a Downstream CDN to 890 retrieve CDNI Metadata objects from an Upstream CDN. 892 The interface can be used by a Downstream CDN to retrieve CDNI 893 Metadata objects either dynamically as required by the Downstream CDN 894 to process received requests (for example in response to receiving a 895 CDNI Request Routing request from an Upstream CDN or in response to 896 receiving a request for content from a User Agent) or in advance of 897 being required. 899 The CDNI Metadata interface is built on the principles of RESTful web 900 services. This means that requests and responses over the interface 901 are built around the transfer of representations of hyperlinked 902 resources. A resource in the context of the CDNI Metadata interface 903 is any object in the Data Model (as described in Section 3 through 904 Section 4.1). 906 In the general case a CDNI Metadata server makes each instance of an 907 addressable CDNI Metadata object available via a unique URI that 908 returns a representation of that instance of that CDNI Metadata 909 object. When an object needs to reference another addressable CDNI 910 Metadata object (for example a HostIndex object referencing a 911 HostMetadata object) it does so by including a link to the referenced 912 object. 914 CDNI Metadata servers are free to assign whatever structure they 915 desire to the URIs for CDNI Metadata objects and CDNI Metadata 916 clients MUST NOT make any assumptions regarding the structure of CDNI 917 Metadata URIs or the mapping between CDNI Metadata objects and their 918 associated URIs. Therefore any URIs present in the examples below 919 are purely illustrative and are not intended impose a definitive 920 structure on CDNI Metadata interface implementations. 922 5.1. Transport 924 The CDNI Metadata interface uses HTTP as the underlying protocol 925 transport. 927 The HTTP Method in the request defines the operation the request 928 would like to perform. Servers implementing the CDNI Metadata 929 interface MUST support the HTTP GET and HEAD methods. 931 The corresponding HTTP Response returns the status of the operation 932 in the HTTP Status Code and returns the current representation of the 933 resource (if appropriate) in the Response Body. HTTP Responses from 934 servers implementing the CDNI Metadata interface that contain a 935 response body SHOULD include an ETag to enable validation of cached 936 versions of returned resources. 938 The CDNI Metadata interface specified in this document is a read-only 939 interface. Therefore support for other HTTP methods such as PUT, 940 POST and DELETE etc. is not specified. Server implementations of 941 this interface SHOULD reject all methods other than GET and HEAD. 943 As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata 944 servers may make use of any HTTP feature when implementing the CDNI 945 Metadata interface, for example a CDNI Metadata server may make use 946 of HTTP's caching mechanisms to indicate that the returned response/ 947 representation can be reused without re-contacting the CDNI Metadata 948 server. 950 5.2. Retrieval of CDNI Metadata resources 952 In the general case a CDNI Metadata server makes each instance of an 953 addressable CDNI Metadata object available via a unique URI and 954 therefore in order to retrieve CDNI Metadata, a CDNI Metadata client 955 first makes a HTTP GET request for the URI of the HostIndex which 956 provides the CDNI Metadata client with a list of Hosts (along with 957 their public facing hostnames) that the upstream CDN may delegate to 958 the downstream CDN. 960 In order to retrieve the CDNI Metadata for a particular request the 961 CDNI Metadata client processes the received HostIndex object and 962 finds the corresponding HostMetadata entry (by matching the hostname 963 in the request against the hostnames in the HostIndex). The CDNI 964 metadata client then makes a GET request for the URI specified in the 965 href key of that Host's entry in the HostIndex. 967 In order to retrieve the most specific metadata for a particular 968 request, the CDNI metadata client inspects the HostMetadata for 969 references to more specific PathMetadata objects. If any 970 PathMetadata match the request, the CDNI metadata client makes 971 another GET request for the PathMetadata. Each PathMetadata object 972 may also include references to yet more specific metadata. If this 973 is the case, the CDNI metadata client continues requesting 974 PathMetadata recursively. 976 Where a downstream CDN is interconnected with multiple upstream CDNs, 977 the downstream CDN must decide which upstream CDN's metadata should 978 handle a particular User Agent request. 980 In the case of where application level redirection (e.g. HTTP 302 981 redirects) is being used between CDNs, it is expected that the 982 downstream CDN will be able to determine the upstream CDN that 983 redirected a particular request from information contained in the 984 received request (e.g. via the URI in case of HTTP redirection across 985 CDNs). With knowledge of which upstream CDN routed the request, the 986 downstream CDN can choose the correct metadata server. 988 In the case of DNS redirection there is not sufficient information 989 carried in the DNS request from User Agents to determine the upstream 990 CDN that redirected a particular request and therefore downstream 991 CDNs may have to apply local policy when deciding which upstream 992 CDN's metadata to apply. 994 5.3. Bootstrapping 996 The URI for the HostIndex object of a given upstream CDN needs to be 997 either discovered by or configured in the downstream CDN. All other 998 objects/resources are then discoverable from the HostIndex object by 999 following the links in the HostIndex object and the referenced 1000 HostMetadata and PathMetadata objects. 1002 If the URI for the HostIndex object is not manually configured in the 1003 downstream CDN then the HostIndex URI could be discovered via the 1004 CDNI Control interface. An upstream CDN would advertise the URI of 1005 the HostIndex object to the downstream CDN via the CDNI Control 1006 Interface. 1008 5.4. Encoding 1010 Object are resources that may be: 1012 o Addressable, where the object is a resource that may be retrieved 1013 or referenced via its own URI. 1014 o Embedded, where the object is contained (or inlined) within a 1015 property of an addressable object. 1017 In the descriptions of objects we use the term "X contains Y" to mean 1018 either Y is directly embedded in X or that Y is linked to by X. It is 1019 generally a deployment choice for the uCDN implementation to decide 1020 when and which CDNI Metadata objects to embed and which are 1021 separately addressable. 1023 5.4.1. MIME Media Types 1025 All MIME types are prefixed with "application/cdni." The MIME type 1026 for each object matches the type name of that object as defined by 1027 this document.Table 4 lists a few examples of the MIME Media Type for 1028 each object (resource) that is retrievable through the CDNI Metadata 1029 interface. The MIME type suffix depends on the metadata encoding, 1030 either "+xml" or "+json". 1032 +--------------+-------------------------------+ 1033 | Data Object | MIME Media Type | 1034 +--------------+-------------------------------+ 1035 | HostIndex | application/cdni.HostIndex | 1036 | HostMatch | application/cdni.HostMatch | 1037 | HostMetadata | application/cdni.HostMetadata | 1038 | PathMatch | application/cdni.PathMatch | 1039 | PathMetadata | application/cdni.PathMetadata | 1040 +--------------+-------------------------------+ 1042 Table 4: MIME Media Types for CDNI Metadata resources 1044 See http://www.iana.org/assignments/media-types/index.html for 1045 reference. 1047 5.4.2. JSON Encoding of Objects 1049 One possible encoding for a CDNI Metadata object is a JSON object 1050 containing a dictionary of (key,value) pairs where the keys are the 1051 property names and the values are the associated property values. 1053 The keys of the dictionary are the names of the properties associated 1054 with the object and are therefore dependent on the specific object 1055 being encoded (i.e. dependent on the MIME Media Type of the returned 1056 resource). Likewise, the values associated with each key are 1057 dependent on the specific object being encoded (i.e. dependent on the 1058 MIME Media Type of the returned resource). 1060 Dictionary keys in JSON are case sensitive and therefore any 1061 dictionary key defined by this document (for example the names of 1062 CDNI Metadata object properties) MUST always be represented in 1063 lowercase. 1065 In addition to the properties of the object, the following three 1066 additional keys defined below may be present in any object. 1068 Key: base 1069 Description: Provides a prefix for any relative URLs in the 1070 object. This is similar to the XML base tag [XML-BASE]. If 1071 absent, all URLs in the remainder of the document must be 1072 absolute URLs. 1073 Type: URI 1074 Mandatory: No 1076 Key: links 1077 Description: The links of this object to other addressable 1078 objects. Any property may be replaced by a link to an object 1079 with the same type as the property it replaces. 1081 Type: List of Link 1082 Mandatory: Yes 1084 5.4.2.1. JSON Example 1086 A downstream CDN may request the HostIndex and receive the following 1087 object of type "application/cdni.HostIndex+json": 1089 { 1090 "host": [ 1091 { 1092 "hostname": "video.example.com", 1093 "links": [ 1094 { 1095 "rel": "hostmetadata", 1096 "type": "HostMetadata", 1097 "href": "http://metadata.ucdn.com/video" 1098 } 1099 ] 1100 }, 1101 { 1102 "hostname": "images.example.com", 1103 "links": [ 1104 { 1105 "rel": "hostmetadata", 1106 "type": "HostMetadata", 1107 "href": "http://metadata.ucdn.com/images" 1108 } 1109 ] 1110 } 1111 ] 1112 } 1114 If the incoming request has a Host header with "video.example.com" 1115 then the downstream CDN would fetch from the next metadata object 1116 from "http://metadata.ucdn.com/video" expecting a MIME type of 1117 "application/cdni.HostMetadata+json": 1119 { 1120 "hostname": "video.example.com", 1121 "acquisition": { 1122 "source": [ 1123 { 1124 "links": [{ 1125 "rel": "auth", 1126 "type": "Auth", 1127 "href": "http://metadata.ucdn.com/auth1234" 1128 }], 1129 "endpoint": "acq1.ucdn.com", 1130 "protocol": "ftp" 1131 }, 1132 { 1133 "links": [{ 1134 "rel": "auth", 1135 "type": "Auth", 1136 "href": "http://metadata.ucdn.com/auth1234" 1137 }], 1138 "endpoint": "acq2.ucdn.com", 1139 "protocol": "http" 1140 } 1141 ] 1142 }, 1143 "delivery": { 1144 "location": { 1145 "aclrule": { 1146 "deny": { "iprange": "192.168.0.0/16" } 1147 } 1148 }, 1149 "auth": { 1151 }, 1152 "protocol": "http", 1153 "active": "true" 1154 }, 1155 "path": [ 1156 { 1157 "pattern": "/videos/trailers/*", 1158 "patternflags": "prefix", 1159 "links": [{ 1160 "rel": "pathmetadata", 1161 "type": "PathMetadata", 1162 "href": "http://metadata.ucdn.com/videos/trailers" 1163 }] 1164 }, 1165 { 1166 "pattern": "/videos/movies/*", 1167 "patternflags": "prefix", 1168 "links": [{ 1169 "rel": "pathmetadata", 1170 "type": "PathMetadata", 1171 "href": "http://metadata.ucdn.com/videos/movies" 1172 }] 1173 } 1174 ] 1175 } 1176 Suppose the path of the requested resource matches the "/video/ 1177 movies/*" pattern, the next metadata requested would be for 1178 "http://metadata.ucdn.com/video/movies" with an expected type of 1179 "application/cdni.PathMetadata": 1181 { 1182 "delivery": { 1183 "auth": { 1185 } 1186 }, 1187 "path": { 1188 "pattern": "/videos/movies/hd/*", 1189 "patternflags": "prefix", 1190 "links": [{ 1191 "rel": "pathmetadata", 1192 "type": "PathMetadata", 1193 "href": "http://metadata.ucdn.com/videos/movies/hd" 1194 }] 1195 } 1196 } 1198 Finally, if the path of the requested resource also matches the 1199 "/videos/movies/hd/*" pattern, the downstream CDN would also fetch 1200 the following object from "http://metadata.ucdn.com/videos/movies/hd" 1201 with MIME type "application/cdni.PathMetadata": 1203 { 1204 "delivery": { 1205 "time": { 1206 "aclrule": { 1207 "allow": { 1208 "start": "1213948800", 1209 "end": "1327393200" 1210 } 1211 } 1212 } 1213 } 1214 } 1216 5.4.3. XML Encoding of Objects 1218 Another possible encoding for a CDNI Metadata object is an XML 1219 document containing elements with tag names which match property 1220 names and values which match the associated property values. 1222 Tag names of elements are the names of the properties associated with 1223 the object and are therefore dependent on the specific object being 1224 encoded (i.e. dependent on the MIME Media Type of the returned 1225 resource). Likewise, the values associated with each element are 1226 dependent on the specific object being encoded (i.e. dependent on the 1227 MIME Media Type of the returned resource). 1229 Lists are encoded by repeating the singular form of a property name. 1230 For example the "hosts" property is a list of "HostMatch" objects. 1231 This list would be encoded as multiple "host" elements. 1233 Link objects are a special case. If a Link object replaces a 1234 property then a "link" element replaces the expected element. The 1235 properties of the Link object are encoded as XML attributes. The 1236 type attribute is set to the MIME type of the target object. The 1237 href attribute is set to the URI of the target object. The rel 1238 attribute is set to the name of the element being replaced. 1240 5.4.3.1. XML Example 1242 A downstream CDN may request the HostIndex and receive the following 1243 object of type "application/cdni.HostIndex+json": 1245 1246 1247 video.example.com 1248 1250 1251 1252 images.example.com 1253 1255 1256 1258 If the incoming request has a Host header with "video.example.com" 1259 then the downstream CDN would fetch from the next metadata object 1260 from "http://metadata.ucdn.com/video" expecting a MIME type of 1261 "application/cdni.HostMetadata+json": 1263 1264 video.example.com 1265 1266 1267 1269 acq1.ucdn.com 1270 ftp 1271 1272 1273 1275 acq2.ucdn.com 1276 http 1277 1278 1279 1280 1281 1282 1283 192.168.0.0/16 1284 1285 1286 1287 1288 http 1289 true 1290 1291 1292 /videos/trailers/* 1293 prefix 1294 1296 1297 1298 /videos/movies/* 1299 prefix 1300 1302 1303 1305 Suppose the path of the requested resource matches the "/video/ 1306 movies/*" pattern, the next metadata requested would be for 1307 "http://metadata.ucdn.com/video/movies" with an expected type of 1308 "application/cdni.PathMetadata": 1310 1311 1312 1313 1314 1315 /videos/movies/hd/* 1316 prefix 1317 1319 1320 1322 Finally, if the path of the requested resource also matches the 1323 "/videos/movies/hd/*" pattern, the downstream CDN would also fetch 1324 the following object from "http://metadata.ucdn.com/videos/movies/hd" 1325 with MIME type "application/cdni.PathMetadata": 1327 1328 1329 1337 1338 1340 5.5. Extensibility 1342 The set of metadata properties may be extended with proprietary and / 1343 or custom properties. New properties may be added to any existing 1344 object. 1346 The names of such properties MUST begin with an "x-" prefix. If a 1347 property is vendor specific, then "x-vendor-" SHOULD be used as the 1348 name prefix, where the "vendor" string is replaced by the name of the 1349 vendor. 1351 The values of new properties MAY include an "ignorable" property with 1352 a boolean type. If "ignorable" is set to true, then request routers 1353 and surrogates in any interconnected CDN MAY safely ignore the new 1354 property. If "ignorable" is set to false, then a CDN which does not 1355 understand the property MUST NOT service a request for the 1356 corresponding content. 1358 6. IANA Considerations 1360 This document requests the registration of the "application/cdni" 1361 MIME type. 1363 7. Security Considerations 1365 The CDNI Metadata Interface is expected to be secured as a function 1366 of the transport protocol (e.g. HTTP authentication). 1368 If a malicious metadata server is contacted by a downstream CDN, the 1369 malicious server may provide metadata to the downstream CDN which 1370 denies service for any piece of content to any user agent. The 1371 malicious server may also provide metadata which directs a downstream 1372 CDN to a malicious origin server instead of the actual origin server. 1374 A malicious metadata client could request metadata for a piece of 1375 content from an upstream CDN. However, given the current set of 1376 metadata properties, no useful information would be compromised. 1378 8. Acknowledgements 1380 The authors would like to thank David Ferguson and Francois le 1381 Faucheur for their valuable comments and input to this document. 1383 9. References 1385 9.1. Normative References 1387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1388 Requirement Levels", BCP 14, RFC 2119, March 1997. 1390 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1391 Architecture", RFC 4291, February 2006. 1393 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1394 Address Text Representation", RFC 5952, August 2010. 1396 9.2. Informative References 1398 [I-D.davie-cdni-framework] 1399 Davie, B. and L. Peterson, "Framework for CDN 1400 Interconnection", draft-davie-cdni-framework-00 (work in 1401 progress), July 2011. 1403 [I-D.ietf-cdni-problem-statement] 1404 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 1405 Distribution Network Interconnection (CDNI) Problem 1406 Statement", draft-ietf-cdni-problem-statement-03 (work in 1407 progress), January 2012. 1409 [I-D.ietf-cdni-requirements] 1410 Leung, K. and Y. Lee, "Content Distribution Network 1411 Interconnection (CDNI) Requirements", 1412 draft-ietf-cdni-requirements-02 (work in progress), 1413 December 2011. 1415 [I-D.zyp-json-schema] 1416 Zyp, K. and G. Court, "A JSON Media Type for Describing 1417 the Structure and Meaning of JSON Documents", 1418 draft-zyp-json-schema-03 (work in progress), 1419 November 2010. 1421 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1422 Resource Identifier (URI): Generic Syntax", STD 66, 1423 RFC 3986, January 2005. 1425 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 1426 RFC 4151, October 2005. 1428 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1429 Syndication Format", RFC 4287, December 2005. 1431 [XML-BASE] 1432 Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second 1433 Edition) - http://www.w3.org/TR/xmlbase/", January 2009. 1435 Appendix A. Relationship to the CDNI Requirements 1437 Section 6 of [I-D.ietf-cdni-requirements] lists the requirements for 1438 the CDNI Metadata Distribution interface. This section outlines 1439 which of those requirements are met by the CDNI Metadata interface 1440 specified in this document. 1442 All metadata requirements are met either directly or indirectly by 1443 the CDNI Metadata Interface described in this document. The 1444 following paragraphs describe notable exceptions. 1446 Requirements related to pre-positioning of metadata are not met 1447 directly by this document. Triggering metadata pre-positioning is 1448 beyond the scope of the CDNI Metadata interface. However, the 1449 interface as described by this document supports pulling metadata on- 1450 demand for the purpose of pre-positioning. 1452 Requirement META-13 relating to feedback from the downstream CDN to 1453 the upstream CDN with respect to metadata is not directly supported 1454 by the pull-based interface described in this document. As an 1455 alternative, the downstream CDN may use the CDNI Logging interface to 1456 convey error conditions related to metadata. 1458 Requirement META-18 relating to surrogate cache behavior parameters 1459 is supported via extensibility. However, the example parameters in 1460 META-18 are not described in this document. 1462 Authors' Addresses 1464 Ben Niven-Jenkins 1465 Velocix (Alcatel-Lucent) 1466 3 Ely Road 1467 Milton, Cambridge CB24 6AA 1468 UK 1470 Email: ben@velocix.com 1472 Rob Murray 1473 Velocix (Alcatel-Lucent) 1474 3 Ely Road 1475 Milton, Cambridge CB24 6AA 1476 UK 1478 Email: rmurray@velocix.com 1480 Grant Watson 1481 Velocix (Alcatel-Lucent) 1482 3 Ely Road 1483 Milton, Cambridge CB24 6AA 1484 UK 1486 Email: gwatson@velocix.com 1487 Matt Caulfield 1488 Cisco Systems 1489 1414 Massachusetts Avenue 1490 Boxborough, MA 01719 1491 USA 1493 Phone: +1 978 936 9307 1494 Email: mcaulfie@cisco.com 1496 Kent Leung 1497 Cisco Systems 1498 3625 Cisco Way 1499 San Jose 95134 1500 USA 1502 Phone: +1 408 526 5030 1503 Email: kleung@cisco.com