idnits 2.17.1 draft-ma-cdni-capabilities-06.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 is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2014) is 3590 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) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-footprint-capabilities-semantics-02 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-11 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Ma 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Seedorf 5 Expires: December 29, 2014 NEC 6 June 27, 2014 8 CDNI Footprint & Capabilities Advertisement Interface 9 draft-ma-cdni-capabilities-06 11 Abstract 13 Content Distribution Network Interconnection (CDNI) is predicated on 14 the ability of downstream CDNs (dCDNs) to handle end-user requests in 15 a functionally equivalent manner to the upstream CDN (uCDN). The 16 uCDN must be able to assess the ability of the dCDN to handle 17 individual requests. The CDNI Footprint & Capabilities Advertisement 18 interface (FCI) is provided for the advertisement of capabilities and 19 the footprints to which they apply by the dCDN to the uCDN. This 20 document describes an approach to implementing the CDNI FCI. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 29, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. CDNI FCI Capability Advertisement . . . . . . . . . . . . . . 4 65 2.1. CDNI FCI Capability Initialization . . . . . . . . . . . 5 66 3. CDNI FCI Capabilities Service . . . . . . . . . . . . . . . . 5 67 3.1. CDNI FCI Map . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 6 69 3.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 6 71 3.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 6 72 3.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.7. CDNI FCI Capabilities . . . . . . . . . . . . . . . . 8 75 3.1.7.1. Delivery Protocol . . . . . . . . . . . . . . . . 8 76 3.1.7.2. Acquisition Protocol . . . . . . . . . . . . . . 10 77 3.1.7.3. Redirection Mode . . . . . . . . . . . . . . . . 12 78 3.1.7.4. Logging Capabilities . . . . . . . . . . . . . . 14 79 3.1.7.5. Metadata Capabilities . . . . . . . . . . . . . . 14 80 3.1.8. Example . . . . . . . . . . . . . . . . . . . . . . . 14 81 4. CDNI FCI Capabilities Filtering Service . . . . . . . . . . . 16 82 4.1. Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . . 16 83 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 16 84 4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 16 85 4.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 16 86 4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 16 87 4.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 16 89 4.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 16 90 5. Footprint via ALTO Network Map . . . . . . . . . . . . . . . 16 91 5.1. ALTO Network Maps . . . . . . . . . . . . . . . . . . . . 16 92 5.2. Example ALTO Network Map for CDNI FCI Footprint . . . . . 17 93 5.3. Example of ALTO Network Map Footprint in FCI Map . . . . 18 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 9.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 22 101 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 22 102 A.2. Internal Request Router Aggregation . . . . . . . . . . . 23 103 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 The need for footprint and capabilities advertisement in CDNI is 109 described in the CDNI requirements document 110 [I-D.ietf-cdni-requirements]. Requirements FCI-1 and FCI-2 describe 111 the need to allow dCDNs to communicate capabilities to the uCDN. 112 Requirement FCI-3 describes how a uCDN may aggregate the footprint 113 and capabilities information for all cascaded dCDNs and use the 114 aggregated information in advertisements to CDNs further upstream. 115 This concept of aggregation can apply to both organizationally 116 different dCDNs (e.g., other CDN providers, or different business 117 units within a larger organization) or logical entities within the 118 same CDN (e.g., using multiple request routers for scalability 119 reasons, to segregate surrogates based on specific protocol support, 120 or to segregate surrogates based on software version or feature 121 level, etc.). 123 Appendix A contains more detailed descriptions of different footprint 124 and capabilities management scenarios, but it is important to note 125 that it is the ability of the dCDN to service each request in a 126 functionally equivalent manner as the uCDN that is important, not the 127 physical layout of resources through which it services the request. 128 The aggregation of resource knowledge by the dCDN into a simple set 129 of capabilities and their affective footprints, that is then 130 advertised to the uCDN enables efficient decision making at each 131 delegation point in the CDN interconnection hierarchy. 133 It is assumed that an authoritative request router in each CDN will 134 be responsible for aggregating and advertising capabilities 135 information in a dCDN, and receiving and aggregating capabilities 136 information in the uCDN. The CDNI Footprint & Capabilities 137 Advertisement interface (FCI) along with the CDNI Request Routing 138 Redirection interface (RI) make up the CDNI Request Routing 139 Interface. As there is no other centralized CDNI controller, the 140 authoritative request router seems the most logical place for 141 capabilities aggregation to occur, as it is the request router that 142 needs such information to make delegation decisions. The protocol 143 defined herein may be implemented as part of an entity other than an 144 authoritative request router, but for the purposes of this 145 discussion, the authoritative request router is assumed to be the 146 centralized capabilities aggregation point. 148 Though there is an obvious need for the ability to exchange and 149 update footprint and capability information in real-time, it is 150 assumed that capabilities do not change very often. It is also 151 assumed that the capabilities are not by themselves useful for making 152 delegation decisions. Capability information is assumed to be input 153 into business logic. It is the business logic which provides the 154 algorithms for delegation decision making. The definition of 155 business logic occurs outside the scope of CDNI and outside the 156 timescale of footprint and capability advertisement. It may be the 157 case that the business logic anticipates and reacts to changes in 158 dCDN capabilities. However, it may also be the case that business 159 logic is tailored through offline processes as dCDN capabilities 160 change. The FCI is agnostic to the business processes employed by 161 any given uCDN. The footprints and capabilities that are advertised 162 over the FCI may be used by the uCDN at its discretion to implement 163 delegation rules. Setting proper defaults in the business logic 164 should prevent any unwanted delegation from occurring when dCDN 165 capabilities change, however, that is beyond the scope of this 166 discussion. 168 1.1. Terminology 170 This document uses the terminology defined in section 1.1 of the CDNI 171 Framework [I-D.ietf-cdni-framework] document. 173 2. CDNI FCI Capability Advertisement 175 The FCI is implemented as an ALTO [I-D.ietf-alto-protocol] Service. 176 The ALTO protocol defines an HTTP-based transport through which ALTO 177 service information may be retrieved using either a GET or POST 178 method. The uCDN request router may at any time query the dCDN ALTO 179 FCI Service for the full set of dCDN capability information. The 180 uCDN may use a separate FCI Filter Service to retrieve a subset of 181 the dCDN capability information. 183 [Ed.: Need to update this with ALTO asynchronous update support.] 185 [Ed.: Need to update this with ALTO incremental update support.] 187 2.1. CDNI FCI Capability Initialization 189 In lieu of any out-of-band pre-configured capability information, 190 when the FCI is first brought up between a uCDN and dCDN, the uCDN 191 SHOULD assume that the dCDN has no CDNI capabilities. If an out-of- 192 band capability baseline has been exchanged, the uCDN MAY use that 193 information to initialize its capabilities database. In either case, 194 the uCDN SHOULD verify the initial state of the dCDN (as a temporary 195 outage may be affecting availability in the dCDN). 197 The dCDN MUST support sending its entire set of capabilities to the 198 uCDN through the ALTO service interface 200 [Ed.: The alternative to using a pull from the uCDN is to use the 201 triggers interface for a triggered push, however, this would not be 202 triggering a CDN function, it would be triggering an FCI function, so 203 given that there is no asynchronous action required by the dCDN, it 204 seems that reducing inter-dependency on other CDNI interfaces makes 205 the most sense in this case.] 207 3. CDNI FCI Capabilities Service 209 As described in Requirement FCI-2, there is a basic set of 210 capabilities that must be supported by the FCI for the uCDN to be 211 able to determine if the dCDN is functionally able to handle a given 212 request. The CDNI Footprint and Capabilities Semantics 213 [I-D.ietf-cdni-footprint-capabilities-semantics] document lists 214 mandatory capabilities types: 216 o Delivery Protocol 218 o Acquisition Protocol 220 o Redirection Mode 222 o CDNI Logging Capabilities 224 o CDNI Metadata Capabilities 226 To be consistent with the base ALTO service definitions, we use the 227 JSON object definition notation as specified in the ALTO 228 [I-D.ietf-alto-protocol] protocol document. 230 3.1. CDNI FCI Map 231 3.1.1. Media Type 233 The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json" 235 3.1.2. HTTP Method 237 A CDNI FCI Map resource is requested using the HTTP GET method. 239 3.1.3. Accept Input Parameters 241 None. 243 3.1.4. Capabilities 245 None. 247 3.1.5. Uses 249 None. 251 3.1.6. Response 253 The data component of a CDNI FCI Map resource is named "fcimap" which 254 is a JSON object of type FCIMapData: 256 object { 257 FCIMapData fcimap<0..*>; 258 } InfoResourceFCIMap : ResponseEntityBase; 260 object { 261 JSONString name; 262 JSONString values<1..*>; 263 FCIFootprint footprint<0..*>; 264 } FCIMapData; 266 object { 267 JSONString type; 268 JSONString values<1..*>; 269 } FCIFootprint; 271 The FCIMapData object contains a capability name which identifies the 272 capability, a values array containing the associated list of 273 supported options for that named capability, as well as an optional 274 list of FCIFootprint objects. The FCIFootprint object specifies a 275 footprint type which identifies the encoding of the individual 276 footprint entries contained in the associated values array. 278 The list of valid capability options for a given capability will be 279 specific to the given named capability. Though the degenerate case 280 may exist where the range of option values is a single value, it is 281 anticipated that all capability types will have more than one 282 capability option value. For consistency in the model, all 283 capability types are implemented with lists of values. To optimize 284 actions on the entire range of capability option values for a given 285 capability type, the capability option value "ALL" is reserved and 286 MUST be supported by all capability types. For completeness, the 287 capability option value "NONE" is also reserved and MUST be supported 288 by all capability types. If a reserved value is specified, it MUST 289 be the only entry in the capability value list. 291 The CDNIFootprint object type field contains a registered footprint 292 type value from the "CDNI Metadata Footprint Types" registry. The 293 CDNI Footprint and Capabilities Semantics 294 [I-D.ietf-cdni-footprint-capabilities-semantics] document lists the 295 mandatory footprint types as: ISO Country Code, AS number, and IP- 296 prefix. The CDNI Metadata Interface [I-D.ietf-cdni-metadata] 297 document defines the footprint type registry and the initial values 298 for the mandatory footprint types. It also describes the process for 299 registering additional optional footprint types. The footprint value 300 "GLOBAL" is reserved and MUST be supported by all footprint types. 301 If the reserved value "GLOBAL" is specified, it MUST be the only 302 entry in the footprint value list. 304 The footprint restriction list MUST NOT contain multiple footprint 305 objects of the same type. Footprint restriction information MAY be 306 specified using multiple different footprint types. If no footprint 307 restriction list is specified (or an empty list is specified), it 308 SHALL be understood that all footprint types MUST be reset to 309 "GLOBAL" coverage. 311 Note: Further optimization of the footprint object to provide quality 312 information for a given footprint is certainly possible, however, it 313 is not critical to the basic interconnection of CDNs. The ability to 314 transfer quality information in capabilities advertisements may be 315 desirable and is noted here for completeness, however, the specifics 316 of such mechanisms are outside the scope of this document. 318 Multiple FCIMapData objects with the same capability type are allowed 319 within a given CDNI FCI Map response as long as the capability option 320 values do not overlap, i.e., a given capability option value MUST NOT 321 show up in multiple FCIMapData objects within a single CDNI FCI Map 322 response. If multiple FCIMapData objects for a given capability type 323 exist, those capability objects SHOULD have different footprint 324 restrictions; capability objects of a given capability type with 325 identical footprint restrictions SHOULD be combined into a single 326 capability object. 328 3.1.7. CDNI FCI Capabilities 330 3.1.7.1. Delivery Protocol 332 The delivery protocol refers to the protocol over which an end user 333 (EU) has requested content. If a dCDN does not support the protocol 334 requested by the client, then the dCDN is not a viable candidate for 335 delegation. 337 Though the delivery protocol is specified in the URI scheme (as 338 defined in RFC3986 [RFC3986]) of the client request URL, protocol 339 feature subsets or augmented protocol feature sets MAY be defined and 340 SHOULD correspond with the protocols supported by the ProtocolACL 341 defined in the CDNI Metadata Interface [I-D.ietf-cdni-metadata] 342 document. The CDNI Metadata Interface document defines the "CDNI 343 Metadata Protocols" registry and the initial supported protocol 344 values. It also describes the process for registering additional 345 protocols. 347 The delivery protocol capability object MUST support a list of 348 protocols for a given footprint. The delivery protocol capability 349 SHOULD support optional footprint restriction information. The 350 following example shows two lists of protocols with different 351 footprints. 353 GET /fcimap HTTP/1.1 354 Host: alto.example.com 355 Accept: application/alto-fcimap+json,application/alto-error+json 357 HTTP/1.1 200 OK 358 Content-Length: 439 359 Content-Type: application/alto-fcimap+json 360 { 361 "meta" : { 362 }, 363 "fcimap": [ 364 { "name": "delivery_protocol", 365 "values": [ 366 "HTTP", 367 "RTSP", 368 "MMS" 369 ] 370 }, 371 { "name": "delivery_protocol", 372 "values": [ 373 "RTMP", 374 "HTTPS" 375 ], 376 "footprint": [ 377 { "type": "IPv4CIDR", 378 "values": [ 379 "10.1.0.0/16", 380 "10.10.10.0/24" 381 ] 382 } 383 ] 384 } 385 ] 386 } 388 In the above example, the three protocols HTTP, RTSP, and MMS are 389 supported globally, while the protocols RTMP and HTTPS are only 390 supported in a restricted footprint (in this case, specified by IP- 391 prefix). 393 A given protocol MUST NOT appear in multiple FCIMapData object value 394 lists. 396 [Ed. need to add reference to registry where the protocol values are 397 defined, once they are finalized in the semantics/metadata draft.] 399 3.1.7.2. Acquisition Protocol 401 The acquisition protocol refers to the protocol over which the dCDN 402 may acquire content from the uCDN. If a dCDN does not support any of 403 the protocols offered by the uCDN, then the dCDN is not a viable 404 candidate for delegation. 406 Though the acquisition protocol is disseminated to the dCDN in the 407 URI scheme (as defined in RFC3986 [RFC3986]) of the URL provided by 408 the uCDN via the CDNI Metadata Interface [I-D.ietf-cdni-metadata], 409 protocol feature subsets or augmented protocol feature sets MAY be 410 defined and SHOULD correspond with the protocols supported by the 411 ProtocolACL defined in the CDNI Metadata Interface 412 [I-D.ietf-cdni-metadata] document. The CDNI Metadata Interface 413 document defines the "CDNI Metadata Protocols" registry and the 414 initial supported protocol values. It also describes the process for 415 registering additional protocols. 417 The acquisition protocol capability object MUST support a list of 418 protocols for a given footprint. The acquisition protocol capability 419 SHOULD support optional footprint restriction information. The 420 following example shows two lists of protocols with different 421 footprints. 423 GET /fcimap HTTP/1.1 424 Host: alto.example.com 425 Accept: application/alto-fcimap+json,application/alto-error+json 427 HTTP/1.1 200 OK 428 Content-Length: 406 429 Content-Type: application/alto-fcimap+json 430 { 431 "meta" : { 432 }, 433 "fcimap": [ 434 { "name": "acquisition_protocol", 435 "values": [ 436 "HTTP", 437 "FTP" 438 ] 439 }, 440 { "name": "acquisition_protocol", 441 "values": [ 442 "SFTP", 443 "HTTPS" 444 ], 445 "footprint": [ 446 { "type": "ASN", 447 "values": [ 448 "0", 449 "65535" 450 ], 451 } 452 ] 453 } 454 ] 455 } 457 In the above example, the two protocols HTTP and FTP are supported 458 globally, while the protocols SFTP and HTTPS are updated to only be 459 supported in a reduced restricted footprint (in this case, specified 460 by ASN). 462 A given protocol MUST NOT appear in multiple FCIMapData object value 463 lists. 465 [Ed. need to add reference to registry where the protocol values are 466 defined, once they are finalized in the semantics/metadata draft.] 468 3.1.7.3. Redirection Mode 470 The redirection mode refers to the method(s) employed by request 471 routers to perform request redirection. The CDNI framework 472 [I-D.ietf-cdni-framework] document describes four possible request 473 routing modes: 475 o DNS iterative (DNS-I) 477 o DNS recursive (DNS-R) 479 o HTTP iterative (HTTP-I) 481 o HTTP recursive (HTTP-R) 483 The CDNI Footprint and Capabilities Semantics 484 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI 485 Capabilities Redirection Modes" registry and the initial supported 486 redirection mode values shown in parentheses above. It also 487 describes the process for registering additional redirection modes. 489 If a dCDN supports only a specific mode or subset of modes that does 490 not overlap with the modes supported by the uCDN, then the dCDN is 491 not a viable candidate for delegation. 493 The redirection mode capability object MUST support a list of 494 redirection modes for a given footprint. The redirection mode 495 capability SHOULD support optional footprint restriction information. 496 The following XML-encoded example shows two lists of modes with 497 different footprints. 499 GET /fcimap HTTP/1.1 500 Host: alto.example.com 501 Accept: application/alto-fcimap+json,application/alto-error+json 503 HTTP/1.1 200 OK 504 Content-Length: 488 505 Content-Type: application/alto-fcimap+json 506 { 507 "meta" : { 508 }, 509 "fcimap": [ 510 { "name": "redirection_mode", 511 "values": [ 512 "DNS-I", 513 "HTTP-I" 514 ] 515 }, 516 { "name": "redirection_mode", 517 "values": [ 518 "DNS-R", 519 "HTTP-R" 520 ], 521 "footprint": [ 522 { "type": "ASN", 523 "values": [ 524 "9" 525 ], 526 }, 527 { "type": "IPv6CIDR", 528 "values": [ 529 "8765:4321::/36" 530 ] 531 } 532 ] 533 } 534 ] 535 } 537 In the above example, iterative redirection is supported globally, 538 while recursive redirection is only supported in a restricted 539 footprint (in this case, specified by both ASN and IP-prefix). 541 A given mode MUST NOT appear in multiple FCIMapData object value 542 lists. 544 3.1.7.4. Logging Capabilities 546 The CDNI Logging interface [I-D.ietf-cdni-logging] document describes 547 optional logging fields and functionality which may be optional for a 548 dCDN to implement. If a dCDN does not support certain logging 549 parameters which may affect billing agreements or legal requirements 550 of the uCDN, then the dCDN is not a viable candidate for delegation. 552 [Ed. need to update this section once the list of logging 553 capabilities is finalized in the semantics/logging draft.] 555 3.1.7.5. Metadata Capabilities 557 The CDNI Metadata interface [I-D.ietf-cdni-metadata] document 558 describes generic metadata types which may be optional for a dCDN to 559 implement, but which, if present, are mandatory-to-enforce. If a 560 dCDN does not support certain metadata types which are designated 561 mandatory-to-enforce and may affect the correctness or security of 562 the content being delivered, then the dCDN is not a viable candidate 563 for delegation. 565 [Ed. need to update this section once the list of metadata 566 capabilities is finalized in the semantics/metadata draft.] 568 3.1.8. Example 570 GET /fcimap HTTP/1.1 571 Host: alto.example.com 572 Accept: application/alto-fcimap+json,application/alto-error+json 574 HTTP/1.1 200 OK 575 Content-Length: 1137 576 Content-Type: application/alto-fcimap+json 577 { 578 "meta" : { 579 }, 580 "fcimap": [ 581 { "name": "delivery_protocol", 582 "values": [ 583 "HTTP", 584 "RTSP", 585 "MMS" 586 ] 587 }, 588 { "name": "delivery_protocol", 589 "values": [ 590 "RTMP", 591 "HTTPS" 593 ], 594 "footprint": [ 595 { "type": "IPv4CIDR", 596 "values": [ 597 "10.1.0.0/16", 598 "10.10.10.0/24" 599 ] 600 } 601 ] 602 } 603 { "name": "acquisition_protocol", 604 "values": [ 605 "HTTP", 606 "FTP" 607 ] 608 }, 609 { "name": "acquisition_protocol", 610 "values": [ 611 "SFTP", 612 "HTTPS" 613 ], 614 "footprint": [ 615 { "type": "ASN", 616 "values": [ 617 "0", 618 "65535" 619 ], 620 } 621 ] 622 } 623 { "name": "redirection_mode", 624 "values": [ 625 "DNS-R", 626 "HTTP-R" 627 ], 628 "footprint": [ 629 { "type": "ASN", 630 "values": [ 631 "9" 632 ], 633 }, 634 { "type": "IPv6CIDR", 635 "values": [ 636 "8765:4321::/36" 637 ] 638 } 639 ] 640 } 642 ] 643 } 645 4. CDNI FCI Capabilities Filtering Service 647 4.1. Filtered CDNI FCI Map 649 4.1.1. Media Type 651 Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the 652 media type defined for CDNI FCI Map (see Section 3.1.1). 654 4.1.2. HTTP Method 656 A Filtered CDNI FCI Map is requested using the HTTP POST method. 658 4.1.3. Accept Input Parameters 660 TBD. 662 4.1.4. Capabilities 664 None. 666 4.1.5. Uses 668 TBD. 670 4.1.6. Response 672 The format is the same as unfiltered CDNI FCI Map (see 673 Section 3.1.6). 675 4.1.7. Example 677 TBD. 679 5. Footprint via ALTO Network Map 681 5.1. ALTO Network Maps 683 The ALTO Protocol offers an information service "ALTO map service" 684 that provides information to ALTO clients in the form of Network Map 685 and Cost Map [I-D.ietf-alto-protocol]. As an alternative to the 686 explicit definition of a footprint (e.g. with type "IPv4CIDR", see 687 examples above), a reference to an ALTO network map can be used to 688 define an FCI footprint. To enable such referencing to ALTO network 689 maps from within an CDNI FCI Map JSON object, a new optional 690 footprint type 'altonetworkmap' is defined (see also Section 6) which 691 has as values a URI to an ALTO server that host an ALTO network map 692 of media type 'application/alto-networkmap+json' (as defined in the 693 ALTO protocol specification [I-D.ietf-alto-protocol]), followed by a 694 list of PIDs [I-D.ietf-alto-protocol] within that network map. 695 Parsing and processing of such an ALTO network map that expresses an 696 FCI footprint follows the ALTO protocol specification 697 [I-D.ietf-alto-protocol]. 699 5.2. Example ALTO Network Map for CDNI FCI Footprint 701 An ALTO client can retrieve a network map of media type 'application/ 702 alto-networkmap+json' under a given URI (e.g. 703 'http://alto.example.com/fcifootprint001') with a GET request for a 704 network map as specified in the ALTO protocol 705 [I-D.ietf-alto-protocol]. The following network map would convey to 706 a uCDN that the given dCDN (which would provide the map) has three 707 footprints called ''south-france'', ''germany'', and ''rest'', and 708 provide the corresponding IPv4 address ranges for these footprints. 709 The entry ''cdni-fruit'' : [''orange''] in the ''south-france'' 710 footprint is an example of how new endpoint types (e.g. proprietary 711 ones that are defined outside the CDNI FCI among certain CDNs) could 712 be used in an ALTO network map. 714 GET /networkmap HTTP/1.1 715 Host: http://alto.example.com/fcifootprint001 716 Accept: application/alto-networkmap+json,application/alto-error+json 718 HTTP/1.1 200 OK 719 Content-Length: TBA 720 Content-Type: application/alto-networkmap+json 722 { 723 "meta" : { 724 "vtag": [ 725 {"resource-id": "my-eu-netmap", 726 "tag": "1266506139" 727 } 728 ] 729 }, 730 "network-map" : { 731 "south-france" : { 732 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ], "cdni-fruit" : ["orange"] 733 }, 734 "germany" : { 735 "ipv4" : [ "192.0.3.0/24"] 736 }, 737 "rest" : { "ipv4": [0.0.0.0/0], "ipv6"; [::/0] } 738 } 739 } 740 } 742 5.3. Example of ALTO Network Map Footprint in FCI Map 744 To reference to an ALTO network map as an FCI footprint, the 745 FCIFootprint JSON object must be of type 'altonetworkmap' with values 746 containing the URI of the ALTO server hosting the network map and a 747 list of PID names contained in the network map. The following 748 example shows the CDNI FCI map on delivery protocol capabilities from 749 Section 3.1.7.1, with the difference that the footprint for the FCI 750 delivery protocol capabilities 'RTMP' and 'HTTPS' is given via a 751 reference to an ALTO network map and corresponding PID names. 753 GET /fcimap HTTP/1.1 754 Host: alto.example.com 755 Accept: application/alto-fcimap+json,application/alto-error+json 757 HTTP/1.1 200 OK 758 Content-Length: 439 759 Content-Type: application/alto-fcimap+json 760 { 761 "meta" : { 762 }, 763 "fcimap": [ 764 { "name": "delivery_protocol", 765 "values": [ 766 "HTTP", 767 "RTSP", 768 "MMS" 769 ] 770 }, 771 { "name": "delivery_protocol", 772 "values": [ 773 "RTMP", 774 "HTTPS" 775 ], 776 "footprint": [ 777 { "type": "altonetworkmap", 778 "values": [ 779 "http://alto.example.com/fcifootprint001", 780 "germany", 781 "south-france", 782 ] 783 } 784 ] 785 } 786 ] 787 } 789 6. IANA Considerations 791 This document requests the registration of two new media types: 793 +-------------+-----------------------------+ 794 | Type | Subtype | 795 +-------------+-----------------------------+ 796 | application | alto-cdni-fcimap+json | 797 | application | alto-cdni-fcimapfilter+json | 798 +-------------+-----------------------------+ 800 This document requests the following addition to the CDNI Footprint 801 type namespace which is defined in the CDNI Metadata Interface 802 [I-D.ietf-cdni-metadata] specification: 804 +----------------+----------------------------------+---------------+ 805 | Type name | Description | Specification | 806 +----------------+----------------------------------+---------------+ 807 | altonetworkmap | URI of an ALTO Server hosting an | RFCthis | 808 | | ALTO network map, followed by a | | 809 | | comma-seperated list of PID- | | 810 | | names | | 811 +----------------+----------------------------------+---------------+ 813 7. Security Considerations 815 There are a number of security concerns associated with the FCI. The 816 FCI essentially provides configuration information which the uCDN 817 uses to make request routing decisions. Injection of fake capability 818 advertisement messages or the interception and discard of real 819 capability advertisement messages may be used for denial of service 820 (e.g., by falsely advertising or deleting capabilities or preventing 821 capability advertisements from reaching the uCDN). dCDN capability 822 advertisements MUST be authenticated by the uCDN to prevent 823 unauthorized capability injection. uCDN FCI servers MUST be 824 authenticated by the dCDN to prevent unauthorized interception of 825 ALTO messages. TLS with client authentication SHOULD be used for all 826 FCI implementations. Deployments in controlled environments where 827 physical security and IP address white-listing is employed MAY choose 828 not to use TLS. 830 8. Acknowledgements 832 The authors would like to thank Jon Peterson, Ray van Brandenburg, 833 Gilles Bertrand, and Scott Wainner for their timely reviews and 834 invaluable comments. 836 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 837 Architecture and Applications of Green Information Centric 838 Networking), a research project supported jointly by the European 839 Commission under its 7th Framework Program (contract no. 608518) and 840 the National Institute of Information and Communications Technology 841 (NICT) in Japan (contract no. 167). The views and conclusions 842 contained herein are those of the authors and should not be 843 interpreted as necessarily representing the official policies or 844 endorsements, either expressed or implied, of the GreenICN project, 845 the European Commission, or NICT. 847 9. References 849 9.1. Normative References 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 855 Resource Identifier (URI): Generic Syntax", STD 66, RFC 856 3986, January 2005. 858 9.2. Informative References 860 [I-D.ietf-alto-protocol] 861 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 862 ietf-alto-protocol-27 (work in progress), March 2014. 864 [I-D.ietf-cdni-footprint-capabilities-semantics] 865 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 866 and K. Ma, "CDNI Request Routing: Footprint and 867 Capabilities Semantics", draft-ietf-cdni-footprint- 868 capabilities-semantics-02 (work in progress), February 869 2014. 871 [I-D.ietf-cdni-framework] 872 Peterson, L., Davie, B., and R. Brandenburg, "Framework 873 for CDN Interconnection", draft-ietf-cdni-framework-14 874 (work in progress), June 2014. 876 [I-D.ietf-cdni-logging] 877 Faucheur, F., Bertrand, G., Oprescu, I., and R. 878 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 879 logging-11 (work in progress), March 2014. 881 [I-D.ietf-cdni-metadata] 882 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 883 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 884 ietf-cdni-metadata-06 (work in progress), February 2014. 886 [I-D.ietf-cdni-requirements] 887 Leung, K. and Y. Lee, "Content Distribution Network 888 Interconnection (CDNI) Requirements", draft-ietf-cdni- 889 requirements-17 (work in progress), January 2014. 891 Appendix A. Capability Aggregation 893 The following sections show examples of three aggregation scenarios. 894 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 895 CDN which must perform capabilities aggregation. 897 A.1. Downstream CDN Aggregation 899 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 900 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 901 Given the setup shown in Figure A1, we can construct a number of use 902 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 903 and C). Note: In all cases, the reachability of the uCDN (i.e., CDN- 904 U) is a don't care as it is assumed that the uCDN knows its own 905 coverage area and is likely to favor itself in most situations, and 906 if it has decided that it needs to delegate to a dCDN, then the only 907 relevant question is if the dCDN can handle the request. 909 ,---,---,---. 910 ,-' `-. 911 ( rr0.u.example.com ) 912 `-. CDN-U ,-' 913 `---'-+-'- --' 914 | 915 ,---,-+-,---. 916 ,-' `-. 917 ( rr0.p.example.com ) 918 `-. CDN-P ,-' 919 `---'-+-'---' 920 | 921 +---------------------+---------------------+ 922 / | \ 923 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 924 ,-' `-. ,-' `-. ,-' `-. 925 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 926 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 927 `---'---'---' `---'---'---' `---'---'---' 929 Figure A1: CDNI dCDN Request Router Aggregation 931 o None of the four dCDNs (CDNs P, A, B, and C) have global 932 reachability. In this case, each CDN is likely to advertise 933 footprint information with its capabilities, specifying its 934 reachability. When CDN-P advertises capabilities to CDN-U, it may 935 advertise the aggregate footprint of itself and CDNs A, B, and C. 936 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 937 per its own internal aggregation decision criteria. 939 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 940 this case, none of the CDNs is likely to advertise any footprint 941 information as none have any footprint restrictions. When CDN-P 942 advertises capabilities to CDN-U, the aggregate of all global 943 reachability is global reachability. 945 o Some of the four dCDNs (CDNs P, A, B, and C) have global 946 reachability and some do not. In this case, even though some 947 dCDNs do not have global reachability, the aggregate of some dCDNs 948 having global reachability and some not should still be global 949 reachability (for the given capability). When CDN-P advertises 950 capabilities to CDN-U, CDN-P may advertise capabilities for which 951 at least one dCDN has global reach as being supported with global 952 reachability. It is up to the CDN-P request router to properly 953 select a dCDN to process individual client requests and not choose 954 a dCDN whose restricted footprint makes it unsuitable for 955 delivering the requested content. 957 A.2. Internal Request Router Aggregation 959 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 960 request routers: the authoritative request router rr0, and three 961 other request routers rr1, rr2, and rr3. The use of multiple request 962 routers may be used to distribute request routing load across 963 resources, possibly in different geographic regions covered by CDN-P. 964 Similar to Figure A1, the setup shown in Figure A2 requires the 965 authoritative request router rr0 in CDN-P to aggregate capabilities 966 information from downstream request routers rr1, rr2, and rr3. The 967 primary difference between the scenario is that the request routers 968 in Figure A2 are logically within the same CDN-P organization. The 969 same reachability scenarios apply to Figure A2 as with Figure A1. 971 ,---,---,---. 972 ,-' `-. 973 ( rr0.u.example.com ) 974 `-. CDN-U ,-' 975 `---'-+-'---' 976 | 977 ,---,---,---,--,-+-,--,---,---,---. 978 ( ) 979 ,-' +-------------------+ `-. 980 ( | rr0.p.example.com | ) 981 ,-' +---------+---------+ `-. 982 ( | ) 983 ,-' +----------+----------+ `-. 984 ( / | \ ) 985 ) +---------+---------+ | +---------+---------+ ( 986 ( | rr1.p.example.com | | | rr3.p.example.com | ) 987 `. +-------------------+ | +-------------------+ ,' 988 ( | ) 989 `-. +---------+---------+ ,-' 990 ( | rr2.p.example.com | ) 991 `-. +-------------------+ ,-' 992 ( CDN-P ) 993 `---'---'---'---'---'---'---'---'---' 995 Figure A2: Local CDN Request Router Aggregation 997 o None of the four CDN-P request routers have global reachability. 998 In this case, each request router is likely to advertise footprint 999 information with its capabilities, specifying its reachability. 1000 When rr0 advertises capabilities to CDN-U, it may advertise the 1001 aggregate footprint of itself and rr1, rr2, and rr3. 1003 o All four CDN-P request routers have global reachability. In this 1004 case, none of the request routers is likely to advertise any 1005 footprint information as none has any footprint restrictions. 1006 When rr0 advertises capabilities to CDN-U, the aggregate of all 1007 global reachability is global reachability. 1009 o Some of the four CDN-P request routers have global reachability 1010 and some do not. In this case, even though some request routers 1011 do not have global reachability, the aggregate of some request 1012 routers having global reachability and some not should still be 1013 global reachability (for the given capability). When rr0 1014 advertises capabilities to CDN-U, CDN-P may advertise capabilities 1015 for which at least one request router has global reach as being 1016 supported with global reachability. It is up to the authoritative 1017 request router rr0 to properly select from the other request 1018 routers for any given request, and not choose a request router 1019 whose restricted footprint makes it unsuitable for delivering the 1020 requested content. 1022 A.3. Internal Capability Aggregation 1024 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 1025 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 1026 Figure A3 differs from Figures A1 and A2 in that request router rr0 1027 of CDN-P is not aggregating the capabilities advertisements of 1028 multiple other downstream request routers, but rather it is managing 1029 the disparate capabilities across resources within its own local CDN. 1030 Though not every delivery node has the same protocol capabilities, 1031 the aggregate delivery protocol capabilities advertised by CDN-A may 1032 include all delivery protocols. Note, Figure A3 should not be 1033 construed to imply anything about the coverage areas for each 1034 delivery protocol. They may all support the same delivery footprint, 1035 or they may have different delivery footprints. It is the 1036 responsibility of the request router rr0 to properly assign protocol- 1037 appropriate delivery nodes to individual content requests. If 1038 certain protocols have limited reachability, CDN-P may advertise 1039 footprint restrictions for each protocol. 1041 It should be noted that though the delivery protocol capability was 1042 selected for this example, the concept of internal capability 1043 aggregation applies to all capabilities as discussed below. 1045 ,---,---,---. 1046 ,-' `-. 1047 ( rr0.u.example.com ) 1048 `-. CDN-U ,-' 1049 `---'-+-'---' 1050 | 1051 ,---,---,---,--,-+-,--,---,---,---. 1052 ( ) 1053 ,-' +-------------------+ `-. 1054 ( | rr0.p.example.com | ) 1055 ,-' +---------+---------+ `-. 1056 ( . ) 1057 ,-' ....................... `-. 1058 ( . . . ) 1059 ) +-------------------+ . +-------------------+ ( 1060 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 1061 `. +-------------------+ . +-------------------+ ,' 1062 ( . ) 1063 `-. +-------------------+ ,-' 1064 ( |http.p.example.com | ) 1065 `-. +-------------------+ ,-' 1066 ( CDN-A ) 1067 `---'---'---'---'---'---'---'---'---' 1069 Figure A3: Local CDN Capability Segregation 1071 Another situation in which physical footprint may not matter in an 1072 aggregated view has to do with feature support (e.g., new CDNI 1073 metadata features or new redirection modes). Situations often arise 1074 when phased roll-out of software upgrades, or staging network 1075 segregation result in only certain portions of a CDN's resources 1076 supporting the new feature set. The dCDN has a few options in this 1077 case: 1079 o Enforce atomic update: The dCDN does not advertise support for the 1080 new capability until all resources have been upgraded to support 1081 the new capability. 1083 o Transparent segregation: The dCDN advertises support for the new 1084 capability, and when requests are received that require the new 1085 capability, the dCDN request router properly selects a resource 1086 which supports that capability. 1088 o Advertised segregation: The dCDN advertises support for the new 1089 capability with a footprint restriction allowing the uCDN to make 1090 delegation decisions based on the dCDN's limit support. 1092 The level of aggregation employed by the dCDN is likely to vary as 1093 business relationships dictate, however, the FCI should support all 1094 possible modes of operation. 1096 Authors' Addresses 1098 Kevin J. Ma 1099 Ericsson 1100 43 Nagog Park 1101 Acton, MA 01720 1102 USA 1104 Phone: +1 978-844-5100 1105 Email: kevin.j.ma@ericsson.com 1107 Jan Seedorf 1108 NEC 1109 Kurfuerstenanlage 36 1110 Heidelberg 69115 1111 Germany 1113 Phone: +49 6221 4342 221 1114 Fax: +49 6221 4342 155 1115 Email: seedorf@neclab.eu