idnits 2.17.1 draft-ma-cdni-capabilities-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2016) is 2925 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-16 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-25 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-15 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-18 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). 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: October 24, 2016 NEC 6 April 22, 2016 8 CDNI Footprint & Capabilities Advertisement Interface 9 draft-ma-cdni-capabilities-09 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 October 24, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 75 3.1.7.1. Delivery Protocol . . . . . . . . . . . . . . . . 7 76 3.1.7.2. Acquisition Protocol . . . . . . . . . . . . . . 9 77 3.1.7.3. Redirection Mode . . . . . . . . . . . . . . . . 11 78 3.1.7.4. Logging Capabilities . . . . . . . . . . . . . . 13 79 3.1.7.5. Metadata Capabilities . . . . . . . . . . . . . . 14 80 4. CDNI FCI Capabilities Filtering Service . . . . . . . . . . . 15 81 4.1. Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . . 15 82 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 15 83 4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 15 84 4.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 15 85 4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 15 86 4.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 4.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 16 88 4.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 16 89 5. Footprint via ALTO Network Map . . . . . . . . . . . . . . . 16 90 5.1. ALTO Network Maps . . . . . . . . . . . . . . . . . . . . 16 91 5.2. Example ALTO Network Map for CDNI FCI Footprint . . . . . 16 92 5.3. Example of ALTO Network Map Footprint in FCI Map . . . . 17 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 6.1. ALTO Media Types . . . . . . . . . . . . . . . . . . . . 19 96 6.1.1. ALTO CDNI FCI Map Media Type . . . . . . . . . . . . 19 97 6.1.2. ALTO CDNI FCI Map Filter Media Type . . . . . . . . . 20 98 6.2. CDNI Footprint Types . . . . . . . . . . . . . . . . . . 22 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 7.1. Securing the CDNI Footprint & Capabilities Advertisement 101 interface . . . . . . . . . . . . . . . . . . . . . . . . 22 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 105 9.2. Informative References . . . . . . . . . . . . . . . . . 24 106 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 25 107 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 25 108 A.2. Internal Request Router Aggregation . . . . . . . . . . . 27 109 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 112 1. Introduction 114 The need for footprint and capabilities advertisement in Content 115 Distribution Network Interconnection (CDNI) is described in the CDNI 116 requirements document [RFC7337]. Requirements FCI-1 and FCI-2 117 describe the need to allow dCDNs to communicate capabilities to the 118 uCDN. Requirement FCI-3 describes how a uCDN may aggregate the 119 footprint and capabilities information for all cascaded dCDNs and use 120 the aggregated information in advertisements to CDNs further 121 upstream. This concept of aggregation can apply to both 122 organizationally different dCDNs (e.g., other CDN providers, or 123 different business units within a larger organization) or logical 124 entities within the same CDN (e.g., using multiple request routers 125 for scalability reasons, to segregate surrogates based on specific 126 protocol support, or to segregate surrogates based on software 127 version or feature level, etc.). 129 Appendix A contains more detailed descriptions of different footprint 130 and capabilities management scenarios, but it is important to note 131 that it is the ability of the dCDN to service each request in a 132 functionally equivalent manner as the uCDN that is important, not the 133 physical layout of resources through which it services the request. 134 The aggregation of resource knowledge by the dCDN into a simple set 135 of capabilities and their affective footprints, that is then 136 advertised to the uCDN, enables efficient decision making at each 137 delegation point in the CDN interconnection hierarchy. 139 It is assumed that an authoritative request router in each CDN will 140 be responsible for aggregating and advertising capabilities 141 information in a dCDN and/or receiving and aggregating capabilities 142 information in the uCDN. The CDNI Footprint & Capabilities 143 Advertisement interface (FCI) along with the CDNI Request Routing 144 Redirection interface (RI) [I-D.ietf-cdni-redirection] make up the 145 CDNI Request Routing Interface. As there is no other centralized 146 CDNI controller, the authoritative request router seems the most 147 logical place for capabilities aggregation to occur, as it is the 148 request router that needs such information to make delegation 149 decisions. The protocol defined herein may be implemented as part of 150 an entity other than an authoritative request router, but for the 151 purposes of this discussion, the authoritative request router is 152 assumed to be the centralized capabilities aggregation point. 154 Though there is an obvious need for the ability to exchange and 155 update footprint and capability information in real-time, it is 156 assumed that capabilities do not change very often. It is also 157 assumed that the capabilities are not by themselves useful for making 158 delegation decisions. Capability information is assumed to be input 159 into business logic. It is the business logic which provides the 160 algorithms for delegation decision making. The definition of 161 business logic occurs outside the scope of CDNI and outside the 162 timescale of footprint and capability advertisement 163 [I-D.ietf-cdni-footprint-capabilities-semantics]. It may be the case 164 that the business logic anticipates and reacts to changes in dCDN 165 capabilities, however, it may also be the case that business logic is 166 tailored through offline processes as dCDN capabilities change. The 167 FCI is agnostic to the business processes employed by any given uCDN. 168 The footprints and capabilities that are advertised over the FCI may 169 be used by the uCDN at its discretion, to implement delegation rules. 170 Setting proper defaults in the business logic should prevent any 171 unwanted delegation from occurring when dCDN capabilities change, 172 however, that is beyond the scope of this discussion. 174 1.1. Terminology 176 This document uses the terminology defined in section 1.1 of the CDNI 177 Framework [RFC7336] document. 179 2. CDNI FCI Capability Advertisement 181 The FCI is implemented as an ALTO [RFC7285] Service. The ALTO 182 protocol defines an HTTP-based transport through which ALTO service 183 information may be retrieved using either a GET or POST method. The 184 uCDN request router may at any time query the dCDN ALTO FCI Service 185 for the full set of dCDN capability information. The uCDN may use a 186 separate FCI Filter Service to retrieve a subset of the dCDN 187 capability information. 189 [Ed.: Need to update this with ALTO asynchronous update support.] 191 [Ed.: Need to update this with ALTO incremental update support.] 193 2.1. CDNI FCI Capability Initialization 195 In lieu of any out-of-band pre-configured capability information, 196 when the FCI is first brought up between a uCDN and a dCDN, the uCDN 197 SHOULD assume that the dCDN has no CDNI capabilities. If an out-of- 198 band capability baseline has been exchanged, the uCDN MAY use that 199 information to initialize its capabilities database. In either case, 200 the uCDN SHOULD verify the initial state of the dCDN (as a temporary 201 outage may affect availability in the dCDN). 203 The dCDN MUST support sending its entire set of capabilities to the 204 uCDN through the ALTO service interface 206 3. CDNI FCI Capabilities Service 208 As described in Requirement FCI-2, there is a basic set of 209 capabilities that must be supported by the FCI for the uCDN to be 210 able to determine if the dCDN is functionally able to handle a given 211 request. [I-D.ietf-cdni-footprint-capabilities-semantics] lists 212 mandatory capabilities types: 214 o Delivery Protocol 216 o Acquisition Protocol 218 o Redirection Mode 220 o CDNI Logging Capabilities 222 o CDNI Metadata Capabilities 224 To be consistent with the base ALTO service definitions, we use the 225 JSON object definition notation as specified in the ALTO protocol 226 [RFC7285]. 228 3.1. CDNI FCI Map 230 3.1.1. Media Type 232 The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json" 234 3.1.2. HTTP Method 236 A CDNI FCI Map resource is requested using the HTTP GET method. 238 3.1.3. Accept Input Parameters 240 None. 242 3.1.4. Capabilities 244 None. 246 3.1.5. Uses 248 None. 250 3.1.6. Response 252 The data component of a CDNI FCI Map resource is named "fcimap" which 253 is a JSON object of type FCIMapData: 255 object { 256 FCIMapData fcimap<0..*>; 257 } InfoResourceFCIMap : ResponseEntityBase; 259 object { 260 FCICapability capabilities<1..*>; 261 } FCIMapData; 263 object { 264 JSONString capability-type; 265 JSONValue capability-value 266 FCIFootprint footprints<0..*>; 267 } FCICapability; 269 object { 270 JSONString footprint-type; 271 JSONString footprint-value<1..*>; 272 } FCIFootprint; 274 The FCIMapData object contains a CDNI Payload Type [RFC7736] "ptype" 275 which identifies the capability and a "value" object containing the 276 associated Capability Advertisement Object (e.g., delivery-protocols, 277 acquisition-protocols, or redirection-modes, as defined in 278 [I-D.ietf-cdni-footprint-capabilities-semantics]). The FCIMapData 279 object may also contain an optional list of FCIFootprint objects 280 "footprints". The FCIFootprint object specifies a "footprint-type" 281 (as defined by the CDNI Metadata Footprint Types registry, e.g., 282 ipv4cidr, ipv6cidr, asn, or countrycode [I-D.ietf-cdni-metadata]) 283 which identifies the contents and encoding of the individual 284 footprint entries contained in the associated "footprint-value" 285 array. 287 The "footprints" list MUST NOT contain multiple FCIFootprint objects 288 of the same type. Footprint restriction information MAY be specified 289 using multiple different footprint-types. If no footprint 290 restriction list is specified (or an empty list is specified), it 291 SHALL be understood that all footprint types MUST be reset to 292 "global" coverage. 294 Note: Further optimization of the footprint object to provide quality 295 information for a given footprint is certainly possible, however, it 296 is not necessary for the basic interconnection of CDNs. The ability 297 to transfer quality information in capabilities advertisements may be 298 desirable and is noted here for completeness, however, the specifics 299 of such mechanisms are outside the scope of this document. 301 Multiple FCIMapData objects with the same capability type are allowed 302 within a given CDNI FCI Map response as long as the capability option 303 footprint-value do not overlap, i.e., a given capability option value 304 MUST NOT show up in multiple FCIMapData objects within a single CDNI 305 FCI Map response. If multiple FCIMapData objects for a given 306 capability type exist, those capability objects MUST have different 307 footprint restrictions. Capability objects of a given capability 308 type with identical footprint restrictions MUST be combined into a 309 single capability object. 311 3.1.7. CDNI FCI Capabilities 313 3.1.7.1. Delivery Protocol 315 The delivery protocol refers to the protocol over which an end user 316 (EU) has requested content. If a dCDN does not support the protocol 317 requested by the client, then the dCDN is not a viable candidate for 318 delegation. 320 Though the delivery protocol is specified in the URI scheme (as 321 defined in [RFC3986]) of the client request URL, protocol feature 322 subsets or augmented protocol feature sets MAY be defined and SHOULD 323 correspond with the protocols listed in the CDNI Metadata Protocol 324 Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata]. 326 The following example shows two lists of delivery protocols with 327 different footprints. 329 GET /fcimap HTTP/1.1 330 Host: alto.example.com 331 Accept: application/alto-fcimap+json,application/alto-error+json 333 HTTP/1.1 200 OK 334 Content-Length: 627 335 Content-Type: application/alto-fcimap+json 336 { 337 "meta" : { 338 }, 339 "fcimap": { 340 "capabilities": [ 341 { "capability-type": "FCI.DeliveryProtocol" 342 "capability-value": { 343 "delivery-protocols": [ 344 "http1.1" 345 ] 346 } 347 }, 348 { "capability-type": "FCI.DeliveryProtocol" 349 "capability-value": { 350 "delivery-protocols": [ 351 "https1.1" 352 ] 353 }, 354 "footprints": [ 355 { "footprint-type": "ipv4cidr", 356 "footprint-value": [ 357 "10.1.0.0/16", 358 "10.10.10.0/24" 359 ] 360 } 361 ] 362 } 363 ] 364 } 365 } 367 In the above example, the HTTP/1.1 protocol is supported globally, 368 while the HTTP/1.1 over TLS protocol is only supported in a 369 restricted footprint (in this case, specified by IPv4 prefix). 371 A given protocol MUST NOT appear in multiple FCIMapData 372 FCI.DeliveryProtocol object values. 374 3.1.7.2. Acquisition Protocol 376 The acquisition protocol refers to the protocol over which an end 377 user (EU) has requested content. If a dCDN does not support the 378 protocol requested by the client, then the dCDN is not a viable 379 candidate for delegation. 381 Though the acquisition protocol is specified in the URI scheme (as 382 defined in [RFC3986]) of the client request URL, protocol feature 383 subsets or augmented protocol feature sets MAY be defined and SHOULD 384 correspond with the protocols listed in the CDNI Metadata Protocol 385 Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata]. 387 The following example shows two lists of acquisition protocols with 388 different footprints. 390 GET /fcimap HTTP/1.1 391 Host: alto.example.com 392 Accept: application/alto-fcimap+json,application/alto-error+json 394 HTTP/1.1 200 OK 395 Content-Length: 620 396 Content-Type: application/alto-fcimap+json 397 { 398 "meta" : { 399 }, 400 "fcimap": { 401 "capabilities": [ 402 { "capability-type": "FCI.AcquisitionProtocol" 403 "capability-value": { 404 "acquisition-protocols": [ 405 "http1.1" 406 ] 407 } 408 }, 409 { "capability-type": "FCI.AcquisitionProtocol" 410 "capability-value": { 411 "acquisition-protocols": [ 412 "https1.1" 413 ] 414 }, 415 "footprints": [ 416 { "footprint-type": "asn", 417 "footprint-value": [ 418 "AS0", 419 "AS65535" 420 ] 421 } 422 ] 423 } 424 ] 425 } 426 } 428 In the above example, the HTTP/1.1 protocol is supported globally, 429 while the HTTP/1.1 over TLS protocol is only supported in a 430 restricted footprint (in this case, specified by Autonomous System 431 number). 433 A given protocol MUST NOT appear in multiple FCIMapData 434 FCI.AcquisitionProtocol value objects. 436 3.1.7.3. Redirection Mode 438 The redirection mode refers to the method(s) employed by request 439 routers to perform request redirection. The CDNI framework [RFC7336] 440 document describes four possible request routing modes: 442 o DNS iterative (DNS-I) 444 o DNS recursive (DNS-R) 446 o HTTP iterative (HTTP-I) 448 o HTTP recursive (HTTP-R) 450 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI 451 Capabilities Redirection Modes" registry and the initial supported 452 redirection mode values shown in parentheses above. 454 If a dCDN supports only a specific mode or subset of modes that does 455 not overlap with the modes supported by the uCDN, then the dCDN might 456 not be a viable candidate for delegation. 458 The following example shows two lists of redirection modes with 459 different footprints. 461 GET /fcimap HTTP/1.1 462 Host: alto.example.com 463 Accept: application/alto-fcimap+json,application/alto-error+json 465 HTTP/1.1 200 OK 466 Content-Length: 767 467 Content-Type: application/alto-fcimap+json 469 { 470 "meta" : { 471 }, 472 "fcimap": { 473 "capabilities": [ 474 { "capability-type": "FCI.RedirectionMode", 475 "capability-value": { 476 "redirection-modes": [ 477 "DNS-I", 478 "HTTP-I" 479 ] 480 } 481 }, 482 { "capability-type": "FCI.RedirectionMode", 483 "capability-value": { 484 "redirection-modes": [ 485 "DNS-R", 486 "HTTP-R" 487 ] 488 }, 489 "footprints": [ 490 { "footprint-type": "countrycode", 491 "footprint-value": [ 492 "SE" 493 ] 494 }, 495 { "footprint-type": "ipv6cidr", 496 "footprint-value": [ 497 "9876:5432::1/36" 498 ] 499 } 500 ] 501 } 502 ] 503 } 504 } 506 In the above example, iterative redirection is supported globally, 507 while recursive redirection is only supported in a restricted 508 footprint (in this case, specified by both Country Code and IPv6 509 prefix). 511 A given mode MUST NOT appear in multiple FCIMapData 512 FCI.RedirectionMode object values. 514 3.1.7.4. Logging Capabilities 516 [I-D.ietf-cdni-logging] describes the "cdni_http_request_v1" logging 517 record-types and optional vs. mandatory-to-implement logging fields 518 for that record-type. It also allows new logging record-types and 519 logging fields to be defined which would be optional for a dCDN to 520 implement. 522 If a dCDN does not support certain logging parameters which may 523 affect billing agreements or legal requirements of the uCDN, then the 524 dCDN is not a viable candidate for delegation. 526 3.1.7.4.1. CDNI Logging Capability Object Serialization 528 The following shows an example of CDNI Logging Capability Object 529 Serialization, for a CDN that supports the optional Content 530 Collection ID logging field (but not the optional Session ID logging 531 field) for the "cdni_http_request_v1" record type. 533 { 534 "capabilities": [ 535 { 536 "capability-type": "FCI.Logging", 537 "capability-value": { 538 "record-type": "cdni_http_request_v1", 539 "fields": [ "s-ccid" ] 540 }, 541 "footprints": [ 542 543 ] 544 } 545 ] 546 } 548 The next example shows the CDNI Logging Capability Object 549 Serialization, for a CDN that supports all optional fields for the 550 "cdni_http_request_v1" record type. 552 { 553 "capabilities": [ 554 { 555 "capability-type": "FCI.Logging", 556 "capability-value": { 557 "record-type": "cdni_http_request_v1" 558 }, 559 "footprints": [ 560 561 ] 562 } 563 ] 564 } 566 3.1.7.5. Metadata Capabilities 568 [I-D.ietf-cdni-metadata] describes GenericMetadata types which may be 569 optional for a dCDN to implement, but which, if present, are 570 mandatory-to-enforce. It also allows for new GenericMetadata to be 571 defined which would be optional for a dCDN to implement. 573 If a dCDN does not support certain GenericMetadata types which are 574 designated mandatory-to-enforce and may affect the correctness or 575 security of the content being delivered, then the dCDN is not a 576 viable candidate for delegation. 578 3.1.7.5.1. CDNI Metadata Capability Object Serialization 580 The following shows an example of CDNI Metadata Capability Object 581 Serialization, for a CDN that supports only the SourceMetadata 582 GenericMetadata type (i.e., it can acquire and deliver content, but 583 cannot enforce and security policies, e.g., time, location, or 584 protocol ACLs). 586 { 587 "capabilities": [ 588 { 589 "capability-type": "FCI.Metadata", 590 "capability-value": { 591 "metadata": ["MI.SourceMetadata"] 592 }, 593 "footprints": [ 594 595 ] 596 } 597 ] 598 } 599 The next example shows the CDNI Metadata Capability Object 600 Serialization, for a CDN that supports only structural metadata 601 (i.e., it can parse metadata as a transit CDN, but cannot enforce 602 security policies or deliver content). 604 { 605 "capabilities": [ 606 { 607 "capability-type": "FCI.Metadata", 608 "capability-value": { 609 "metadata": [] 610 }, 611 "footprints": [ 612 613 ] 614 } 615 ] 616 } 618 4. CDNI FCI Capabilities Filtering Service 620 4.1. Filtered CDNI FCI Map 622 4.1.1. Media Type 624 Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the 625 media type defined for CDNI FCI Map (see Section 3.1.1). 627 4.1.2. HTTP Method 629 A Filtered CDNI FCI Map is requested using the HTTP POST method. 631 4.1.3. Accept Input Parameters 633 TBD. 635 4.1.4. Capabilities 637 None. 639 4.1.5. Uses 641 TBD. 643 4.1.6. Response 645 The format is the same as unfiltered CDNI FCI Map (see 646 Section 3.1.6). 648 4.1.7. Example 650 TBD. 652 5. Footprint via ALTO Network Map 654 5.1. ALTO Network Maps 656 The ALTO Protocol offers an information service "ALTO map service" 657 that provides information to ALTO clients in the form of Network Map 658 and Cost Map [RFC7285]. As an alternative to the explicit definition 659 of a CDNI Footprint Type (e.g., ipv4cidr, ipv6cidr, as, countrycode), 660 a reference to an ALTO network map can be used to define an FCI 661 footprint. To enable such referencing to ALTO network maps, a new 662 CDNI Footprint Type "altonetworkmap" is defined (see also 663 Section 6.2). 665 The first altonetworkmap entry must be a URI for accessing the ALTO 666 server that hosts the ALTO network map (as defined in the ALTO 667 protocol specification [RFC7285]). All subsequent altonetworkmap 668 entries must be of type PIDName (as defined in [RFC7285], where the 669 PIDName corresponds to a PID in the ALTO network map referenced by 670 the preceding URI. Parsing and processing of an ALTO network map 671 follows the ALTO protocol specification [RFC7285]. 673 5.2. Example ALTO Network Map for CDNI FCI Footprint 675 An ALTO client can retrieve a network map of media type 'application/ 676 alto-networkmap+json' under a given URI (e.g., 677 'http://alto.example.com/fcifootprint001') with a GET request for a 678 network map as specified in the ALTO protocol [RFC7285]. The 679 following network map would convey to a uCDN that the given dCDN 680 (which would provide the map) has three footprints called "south- 681 france" and "germany", and provides the corresponding IPv4 address 682 ranges for these footprints. 684 GET /networkmap HTTP/1.1 685 Host: http://alto.example.com/fcifootprint001 686 Accept: application/alto-networkmap+json,application/alto-error+json 688 HTTP/1.1 200 OK 689 Content-Length: 319 690 Content-Type: application/alto-networkmap+json 692 { 693 "meta" : { 694 "vtag": [ 695 {"resource-id": "my-eu-netmap", 696 "tag": "1266506139" 697 } 698 ] 699 }, 700 "network-map" : { 701 "south-france" : { 702 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] 703 }, 704 "germany" : { 705 "ipv4" : [ "192.0.3.0/24"] 706 } 707 } 708 } 710 5.3. Example of ALTO Network Map Footprint in FCI Map 712 To reference an ALTO network map as an FCI footprint, set the 713 footprint-type to "altonetworkmap", and set the first entry in the 714 footprint-value to the URI of the ALTO server hosting the network 715 map, followed by a list of PID names contained in the network map. 717 The following example shows two lists of delivery protocols (see 718 Section 3.1.7.1), with the second having an ALTO network map 719 footprint. 721 GET /fcimap HTTP/1.1 722 Host: alto.example.com 723 Accept: application/alto-fcimap+json,application/alto-error+json 725 HTTP/1.1 200 OK 726 Content-Length: 618 727 Content-Type: application/alto-fcimap+json 729 { 730 "meta" : { 731 }, 732 "fcimap": { 733 "capabilities": [ 734 { "capability-type": "FCI.DeliveryProtocol", 735 "capability-value": [ 736 "http1.1" 737 ] 738 }, 739 { "capability-type": "FCI.DeliveryProtocol", 740 "capability-value": [ 741 "values": [ 742 "https1.1" 743 ], 744 "footprints": [ 745 { "footprint-type": "altonetworkmap", 746 "footprint-value": [ 747 "http://alto.example.com/fcifootprint001", 748 "germany", 749 "south-france" 750 ] 751 } 752 ] 753 } 754 ] 755 } 756 } 758 In the above example, the HTTP/1.1 protocol is supported globally, 759 while the HTTP/1.1 over TLS protocol is only supported in a 760 restricted footprint (in this case, specified by an ALTO network map 761 for Germany and Southern France). 763 6. IANA Considerations 764 6.1. ALTO Media Types 766 This document requests the registration of the following media types: 768 +-------------+-----------------------------+ 769 | Type | Subtype | 770 +-------------+-----------------------------+ 771 | application | alto-cdni-fcimap+json | 772 | application | alto-cdni-fcimapfilter+json | 773 +-------------+-----------------------------+ 775 6.1.1. ALTO CDNI FCI Map Media Type 777 Type name: application 779 Subtype name: alto-cdni-fcimap+json 781 Required parameters: none 783 Optional parameters: none 785 Encoding considerations: 787 Encoding considerations are identical to those specified for the 788 "application/json" media type. See [RFC7159]. 790 Security considerations: 792 Security considerations relating to the generation and consumption 793 of ALTO Protocol messages are discussed in Section 15 of 794 [RFC7285]. Additional security considerations for the CDNI 795 Footprint & Capabilities Advertisement interface are discussed in 796 Section 7. 798 Interoperability considerations: 800 [RFC7285] and RFCthis specify the format of conforming messages 801 and the interpretation thereof. [RFC Editor: Please replace 802 RFCthis with the published RFC number for this document.] 804 Published specification: RFCthis [RFC Editor: Please replace RFCthis 805 with the published RFC number for this document.] 807 Applications that use this media type: 809 ALTO servers and ALTO clients either stand alone or are embedded 810 within other applications. 812 Fragment identifier considerations: N/A 814 Additional information: N/A 816 Deprecated alias names for this type: N/A 818 Magic number(s): N/A 820 File extension(s): N/A 822 Macintosh file type code(s): N/A 824 Person & email address to contact for further information: 826 Kevin Ma 828 Intended usage: LIMITED USE 830 Restrictions on usage: 832 This media type is intended only for use in CDNI Footprint & 833 Capabilities Advertisement interface protocol message exchanges. 835 Author: IETF CDNI working group 837 Change controller: IETF CDNI working group 839 Provisional registration: no 841 6.1.2. ALTO CDNI FCI Map Filter Media Type 843 Type name: application 845 Subtype name: alto-cdni-fcimapfilter+json 847 Required parameters: none 849 Optional parameters: none 851 Encoding considerations: 853 Encoding considerations are identical to those specified for the 854 "application/json" media type. See [RFC7159]. 856 Security considerations: 858 Security considerations relating to the generation and consumption 859 of ALTO Protocol messages are discussed in Section 15 of 861 [RFC7285]. Additional security considerations for the CDNI 862 Footprint & Capabilities Advertisement interface are discussed in 863 Section 7. 865 Interoperability considerations: 867 [RFC7285] and RFCthis specify the format of conforming messages 868 and the interpretation thereof. [RFC Editor: Please replace 869 RFCthis with the published RFC number for this document.] 871 Published specification: RFCthis [RFC Editor: Please replace RFCthis 872 with the published RFC number for this document.] 874 Applications that use this media type: 876 ALTO servers and ALTO clients either stand alone or are embedded 877 within other applications. 879 Fragment identifier considerations: N/A 881 Additional information: N/A 883 Deprecated alias names for this type: N/A 885 Magic number(s): N/A 887 File extension(s): N/A 889 Macintosh file type code(s): N/A 891 Person & email address to contact for further information: 893 Kevin Ma 895 Intended usage: LIMITED USE 897 Restrictions on usage: 899 This media type is intended only for use in CDNI Footprint & 900 Capabilities Advertisement interface protocol message exchanges. 902 Author: IETF CDNI working group 904 Change controller: IETF CDNI working group 906 Provisional registration: no 908 6.2. CDNI Footprint Types 910 This document requests the following addition to the "CDNI Metadata 911 Footprint Types" registry: 913 +----------------+----------------------------------+---------------+ 914 | Footprint Type | Description | Specification | 915 +----------------+----------------------------------+---------------+ 916 | altonetworkmap | URI of an ALTO Server hosting an | RFCthis | 917 | | ALTO network map, followed by a | | 918 | | list of PID-names | | 919 +----------------+----------------------------------+---------------+ 921 [RFC Editor: Please replace RFCthis with the published RFC number for 922 this document.] 924 7. Security Considerations 926 There are a number of security concerns associated with the FCI. The 927 FCI essentially provides configuration information which the uCDN 928 uses to make request routing decisions. Injection of fake capability 929 advertisement messages or the interception and discard of real 930 capability advertisement messages may be used for denial of service 931 (e.g., by falsely advertising or deleting capabilities or preventing 932 capability advertisements from reaching the uCDN). FCI messages may 933 also be monitored to detect when CDN performance degrades or outages 934 occur. Such information may be considered private by the dCDN. 936 dCDN capability advertisements MUST be authenticated by the uCDN to 937 prevent unauthorized capability injection. uCDN FCI servers MUST be 938 authenticated by the dCDN to prevent unauthorized interception of 939 ALTO messages. Encryption MUST be used to ensure confidentiality of 940 the dCDN's private messages. 942 7.1. Securing the CDNI Footprint & Capabilities Advertisement interface 944 An implementation of the CDNI Footprint & Capabilities Advertisement 945 interface MUST support TLS transport as per [RFC2818] and [RFC7230]. 946 The use of TLS for transport of the CDNI metadata interface messages 947 allows: 949 o The dCDN and uCDN to authenticate each other. 951 and, once they have mutually authenticated each other, it allows: 953 o The dCDN and uCDN to authorize each other (to ensure they are 954 transmitting/receiving CDNI FCI messages from an authorized CDN); 956 o CDNI FCI messages to be transmitted with confidentiality; and 958 o The integrity of the CDNI FCI messages to be protected during the 959 exchange. 961 In an environment where any such protection is required, TLS MUST be 962 used (including authentication of the remote end) by the server-side 963 (uCDN) and the client-side (dCDN) of the CDNI Footprint & 964 Capabilities Advertisement interface unless alternate methods are 965 used for ensuring the confidentiality of the information in the CDNI 966 FCI messages (such as setting up an IPsec tunnel between the two CDNs 967 or using a physically secured internal network between two CDNs that 968 are owned by the same corporate entity). 970 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 971 followed. 973 8. Acknowledgements 975 The authors would like to thank Jon Peterson, Ray van Brandenburg, 976 Gilles Bertrand, and Scott Wainner for their timely reviews and 977 invaluable comments. 979 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 980 Architecture and Applications of Green Information Centric 981 Networking), a research project supported jointly by the European 982 Commission under its 7th Framework Program (contract no. 608518) and 983 the National Institute of Information and Communications Technology 984 (NICT) in Japan (contract no. 167). The views and conclusions 985 contained herein are those of the authors and should not be 986 interpreted as necessarily representing the official policies or 987 endorsements, either expressed or implied, of the GreenICN project, 988 the European Commission, or NICT. 990 9. References 992 9.1. Normative References 994 [I-D.ietf-cdni-footprint-capabilities-semantics] 995 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 996 and K. Ma, "CDNI Request Routing: Footprint and 997 Capabilities Semantics", draft-ietf-cdni-footprint- 998 capabilities-semantics-16 (work in progress), April 2016. 1000 [I-D.ietf-cdni-logging] 1001 Faucheur, F., Bertrand, G., Oprescu, I., and R. 1002 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 1003 logging-25 (work in progress), April 2016. 1005 [I-D.ietf-cdni-metadata] 1006 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1007 "CDN Interconnection Metadata", draft-ietf-cdni- 1008 metadata-15 (work in progress), April 2016. 1010 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1011 Requirement Levels", BCP 14, RFC 2119, 1012 DOI 10.17487/RFC2119, March 1997, 1013 . 1015 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1016 Protocol (HTTP/1.1): Message Syntax and Routing", 1017 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1018 . 1020 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1021 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1022 "Application-Layer Traffic Optimization (ALTO) Protocol", 1023 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1024 . 1026 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1027 "Recommendations for Secure Use of Transport Layer 1028 Security (TLS) and Datagram Transport Layer Security 1029 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1030 2015, . 1032 9.2. Informative References 1034 [I-D.ietf-cdni-redirection] 1035 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 1036 Redirection interface for CDN Interconnection", draft- 1037 ietf-cdni-redirection-18 (work in progress), April 2016. 1039 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1040 DOI 10.17487/RFC2818, May 2000, 1041 . 1043 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1044 Resource Identifier (URI): Generic Syntax", STD 66, 1045 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1046 . 1048 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1049 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1050 2014, . 1052 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1053 "Framework for Content Distribution Network 1054 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1055 August 2014, . 1057 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1058 Network Interconnection (CDNI) Requirements", RFC 7337, 1059 DOI 10.17487/RFC7337, August 2014, 1060 . 1062 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 1063 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 1064 December 2015, . 1066 Appendix A. Capability Aggregation 1068 The following sections show examples of three aggregation scenarios. 1069 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 1070 CDN which must perform capabilities aggregation. 1072 A.1. Downstream CDN Aggregation 1074 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 1075 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 1076 Given the setup shown in Figure A1, we can construct a number of use 1077 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 1078 and C). Note: In all cases, the reachability of the uCDN (i.e., CDN- 1079 U) is a don't care as it is assumed that the uCDN knows its own 1080 coverage area and is likely to favor itself in most situations, and 1081 if it has decided that it needs to delegate to a dCDN, then the only 1082 relevant question is if the dCDN can handle the request. 1084 ,---,---,---. 1085 ,-' `-. 1086 ( rr0.u.example.com ) 1087 `-. CDN-U ,-' 1088 `---'-+-'- --' 1089 | 1090 ,---,-+-,---. 1091 ,-' `-. 1092 ( rr0.p.example.com ) 1093 `-. CDN-P ,-' 1094 `---'-+-'---' 1095 | 1096 +---------------------+---------------------+ 1097 / | \ 1098 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 1099 ,-' `-. ,-' `-. ,-' `-. 1100 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 1101 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 1102 `---'---'---' `---'---'---' `---'---'---' 1104 Figure A1: CDNI dCDN Request Router Aggregation 1106 o None of the four dCDNs (CDNs P, A, B, and C) have global 1107 reachability. In this case, each CDN is likely to advertise 1108 footprint information with its capabilities, specifying its 1109 reachability. When CDN-P advertises capabilities to CDN-U, it may 1110 advertise the aggregate footprint of itself and CDNs A, B, and C. 1111 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 1112 per its own internal aggregation decision criteria. 1114 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 1115 this case, none of the CDNs is likely to advertise any footprint 1116 information as none have any footprint restrictions. When CDN-P 1117 advertises capabilities to CDN-U, the aggregate of all global 1118 reachability is global reachability. 1120 o Some of the four dCDNs (CDNs P, A, B, and C) have global 1121 reachability and some do not. In this case, even though some 1122 dCDNs do not have global reachability, the aggregate of some dCDNs 1123 having global reachability and some not should still be global 1124 reachability (for the given capability). When CDN-P advertises 1125 capabilities to CDN-U, CDN-P may advertise capabilities for which 1126 at least one dCDN has global reach as being supported with global 1127 reachability. It is up to the CDN-P request router to properly 1128 select a dCDN to process individual client requests and not choose 1129 a dCDN whose restricted footprint makes it unsuitable for 1130 delivering the requested content. 1132 A.2. Internal Request Router Aggregation 1134 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 1135 request routers: the authoritative request router rr0, and three 1136 other request routers rr1, rr2, and rr3. The use of multiple request 1137 routers may be used to distribute request routing load across 1138 resources, possibly in different geographic regions covered by CDN-P. 1139 Similar to Figure A1, the setup shown in Figure A2 requires the 1140 authoritative request router rr0 in CDN-P to aggregate capabilities 1141 information from downstream request routers rr1, rr2, and rr3. The 1142 primary difference between the scenario is that the request routers 1143 in Figure A2 are logically within the same CDN-P organization. The 1144 same reachability scenarios apply to Figure A2 as with Figure A1. 1146 ,---,---,---. 1147 ,-' `-. 1148 ( rr0.u.example.com ) 1149 `-. CDN-U ,-' 1150 `---'-+-'---' 1151 | 1152 ,---,---,---,--,-+-,--,---,---,---. 1153 ( ) 1154 ,-' +-------------------+ `-. 1155 ( | rr0.p.example.com | ) 1156 ,-' +---------+---------+ `-. 1157 ( | ) 1158 ,-' +----------+----------+ `-. 1159 ( / | \ ) 1160 ) +---------+---------+ | +---------+---------+ ( 1161 ( | rr1.p.example.com | | | rr3.p.example.com | ) 1162 `. +-------------------+ | +-------------------+ ,' 1163 ( | ) 1164 `-. +---------+---------+ ,-' 1165 ( | rr2.p.example.com | ) 1166 `-. +-------------------+ ,-' 1167 ( CDN-P ) 1168 `---'---'---'---'---'---'---'---'---' 1170 Figure A2: Local CDN Request Router Aggregation 1172 o None of the four CDN-P request routers have global reachability. 1173 In this case, each request router is likely to advertise footprint 1174 information with its capabilities, specifying its reachability. 1175 When rr0 advertises capabilities to CDN-U, it may advertise the 1176 aggregate footprint of itself and rr1, rr2, and rr3. 1178 o All four CDN-P request routers have global reachability. In this 1179 case, none of the request routers is likely to advertise any 1180 footprint information as none has any footprint restrictions. 1181 When rr0 advertises capabilities to CDN-U, the aggregate of all 1182 global reachability is global reachability. 1184 o Some of the four CDN-P request routers have global reachability 1185 and some do not. In this case, even though some request routers 1186 do not have global reachability, the aggregate of some request 1187 routers having global reachability and some not should still be 1188 global reachability (for the given capability). When rr0 1189 advertises capabilities to CDN-U, CDN-P may advertise capabilities 1190 for which at least one request router has global reach as being 1191 supported with global reachability. It is up to the authoritative 1192 request router rr0 to properly select from the other request 1193 routers for any given request, and not choose a request router 1194 whose restricted footprint makes it unsuitable for delivering the 1195 requested content. 1197 A.3. Internal Capability Aggregation 1199 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 1200 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 1201 Figure A3 differs from Figures A1 and A2 in that request router rr0 1202 of CDN-P is not aggregating the capabilities advertisements of 1203 multiple other downstream request routers, but rather it is managing 1204 the disparate capabilities across resources within its own local CDN. 1205 Though not every delivery node has the same protocol capabilities, 1206 the aggregate delivery protocol capabilities advertised by CDN-A may 1207 include all delivery protocols. Note, Figure A3 should not be 1208 construed to imply anything about the coverage areas for each 1209 delivery protocol. They may all support the same delivery footprint, 1210 or they may have different delivery footprints. It is the 1211 responsibility of the request router rr0 to properly assign protocol- 1212 appropriate delivery nodes to individual content requests. If 1213 certain protocols have limited reachability, CDN-P may advertise 1214 footprint restrictions for each protocol. 1216 It should be noted that though the delivery protocol capability was 1217 selected for this example, the concept of internal capability 1218 aggregation applies to all capabilities as discussed below. 1220 ,---,---,---. 1221 ,-' `-. 1222 ( rr0.u.example.com ) 1223 `-. CDN-U ,-' 1224 `---'-+-'---' 1225 | 1226 ,---,---,---,--,-+-,--,---,---,---. 1227 ( ) 1228 ,-' +-------------------+ `-. 1229 ( | rr0.p.example.com | ) 1230 ,-' +---------+---------+ `-. 1231 ( . ) 1232 ,-' ....................... `-. 1233 ( . . . ) 1234 ) +-------------------+ . +-------------------+ ( 1235 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 1236 `. +-------------------+ . +-------------------+ ,' 1237 ( . ) 1238 `-. +-------------------+ ,-' 1239 ( |http.p.example.com | ) 1240 `-. +-------------------+ ,-' 1241 ( CDN-A ) 1242 `---'---'---'---'---'---'---'---'---' 1244 Figure A3: Local CDN Capability Segregation 1246 Another situation in which physical footprint may not matter in an 1247 aggregated view has to do with feature support (e.g., new CDNI 1248 metadata features or new redirection modes). Situations often arise 1249 when phased roll-out of software upgrades, or staging network 1250 segregation result in only certain portions of a CDN's resources 1251 supporting the new feature set. The dCDN has a few options in this 1252 case: 1254 o Enforce atomic update: The dCDN does not advertise support for the 1255 new capability until all resources have been upgraded to support 1256 the new capability. 1258 o Transparent segregation: The dCDN advertises support for the new 1259 capability, and when requests are received that require the new 1260 capability, the dCDN request router properly selects a resource 1261 which supports that capability. 1263 o Advertised segregation: The dCDN advertises support for the new 1264 capability with a footprint restriction allowing the uCDN to make 1265 delegation decisions based on the dCDN's limit support. 1267 The level of aggregation employed by the dCDN is likely to vary as 1268 business relationships dictate, however, the FCI should support all 1269 possible modes of operation. 1271 Authors' Addresses 1273 Kevin J. Ma 1274 Ericsson 1275 43 Nagog Park 1276 Acton, MA 01720 1277 USA 1279 Phone: +1 978-844-5100 1280 Email: kevin.j.ma@ericsson.com 1282 Jan Seedorf 1283 NEC 1284 Kurfuerstenanlage 36 1285 Heidelberg 69115 1286 Germany 1288 Phone: +49 6221 4342 221 1289 Fax: +49 6221 4342 155 1290 Email: seedorf@neclab.eu