idnits 2.17.1 draft-ma-cdni-capabilities-07.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 (March 8, 2015) is 3309 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) ** Downref: Normative reference to an Informational RFC: RFC 7336 ** Downref: Normative reference to an Informational RFC: RFC 7337 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-footprint-capabilities-semantics-05 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-15 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-09 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-08 Summary: 3 errors (**), 0 flaws (~~), 5 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: September 9, 2015 NEC 6 March 8, 2015 8 CDNI Footprint & Capabilities Advertisement Interface 9 draft-ma-cdni-capabilities-07 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 September 9, 2015. 45 Copyright Notice 47 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 7 75 3.1.7.1. Delivery Protocol . . . . . . . . . . . . . . . . 7 76 3.1.7.2. Acquisition Protocol . . . . . . . . . . . . . . 8 77 3.1.7.3. Redirection Mode . . . . . . . . . . . . . . . . 10 78 3.1.7.4. Logging Capabilities . . . . . . . . . . . . . . 13 79 3.1.7.5. Metadata Capabilities . . . . . . . . . . . . . . 13 80 4. CDNI FCI Capabilities Filtering Service . . . . . . . . . . . 13 81 4.1. Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . . 13 82 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 83 4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13 84 4.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 13 85 4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 13 86 4.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 4.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 14 88 4.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 14 89 5. Footprint via ALTO Network Map . . . . . . . . . . . . . . . 14 90 5.1. ALTO Network Maps . . . . . . . . . . . . . . . . . . . . 14 91 5.2. Example ALTO Network Map for CDNI FCI Footprint . . . . . 14 92 5.3. Example of ALTO Network Map Footprint in FCI Map . . . . 15 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 99 9.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 19 101 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 19 102 A.2. Internal Request Router Aggregation . . . . . . . . . . . 20 103 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 22 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 The need for footprint and capabilities advertisement in CDNI is 109 described in the CDNI requirements document [RFC7337]. Requirements 110 FCI-1 and FCI-2 describe the need to allow dCDNs to communicate 111 capabilities to the uCDN. Requirement FCI-3 describes how a uCDN may 112 aggregate the footprint and capabilities information for all cascaded 113 dCDNs and use the aggregated information in advertisements to CDNs 114 further upstream. This concept of aggregation can apply to both 115 organizationally different dCDNs (e.g., other CDN providers, or 116 different business units within a larger organization) or logical 117 entities within the same CDN (e.g., using multiple request routers 118 for scalability reasons, to segregate surrogates based on specific 119 protocol support, or to segregate surrogates based on software 120 version or feature level, etc.). 122 Appendix A contains more detailed descriptions of different footprint 123 and capabilities management scenarios, but it is important to note 124 that it is the ability of the dCDN to service each request in a 125 functionally equivalent manner as the uCDN that is important, not the 126 physical layout of resources through which it services the request. 127 The aggregation of resource knowledge by the dCDN into a simple set 128 of capabilities and their affective footprints, that is then 129 advertised to the uCDN, enables efficient decision making at each 130 delegation point in the CDN interconnection hierarchy. 132 It is assumed that an authoritative request router in each CDN will 133 be responsible for aggregating and advertising capabilities 134 information in a dCDN, and receiving and aggregating capabilities 135 information in the uCDN. The CDNI Footprint & Capabilities 136 Advertisement interface (FCI) along with the CDNI Request Routing 137 Redirection interface (RI) [I-D.ietf-cdni-redirection] make up the 138 CDNI Request Routing Interface. As there is no other centralized 139 CDNI controller, the authoritative request router seems the most 140 logical place for capabilities aggregation to occur, as it is the 141 request router that needs such information to make delegation 142 decisions. The protocol defined herein may be implemented as part of 143 an entity other than an authoritative request router, but for the 144 purposes of this discussion, the authoritative request router is 145 assumed to be the centralized capabilities aggregation point. 147 Though there is an obvious need for the ability to exchange and 148 update footprint and capability information in real-time, it is 149 assumed that capabilities do not change very often. It is also 150 assumed that the capabilities are not by themselves useful for making 151 delegation decisions. Capability information is assumed to be input 152 into business logic. It is the business logic which provides the 153 algorithms for delegation decision making. The definition of 154 business logic occurs outside the scope of CDNI and outside the 155 timescale of footprint and capability advertisement. It may be the 156 case that the business logic anticipates and reacts to changes in 157 dCDN capabilities. However, it may also be the case that business 158 logic is tailored through offline processes as dCDN capabilities 159 change. The FCI is agnostic to the business processes employed by 160 any given uCDN. The footprints and capabilities that are advertised 161 over the FCI may be used by the uCDN at its discretion to implement 162 delegation rules. Setting proper defaults in the business logic 163 should prevent any unwanted delegation from occurring when dCDN 164 capabilities change, however, that is beyond the scope of this 165 discussion. 167 1.1. Terminology 169 This document uses the terminology defined in section 1.1 of the CDNI 170 Framework [RFC7336] document. 172 2. CDNI FCI Capability Advertisement 174 The FCI is implemented as an ALTO [RFC7285] Service. The ALTO 175 protocol defines an HTTP-based transport through which ALTO service 176 information may be retrieved using either a GET or POST method. The 177 uCDN request router may at any time query the dCDN ALTO FCI Service 178 for the full set of dCDN capability information. The uCDN may use a 179 separate FCI Filter Service to retrieve a subset of the dCDN 180 capability information. 182 [Ed.: Need to update this with ALTO asynchronous update support.] 184 [Ed.: Need to update this with ALTO incremental update support.] 186 2.1. CDNI FCI Capability Initialization 188 In lieu of any out-of-band pre-configured capability information, 189 when the FCI is first brought up between a uCDN and a dCDN, the uCDN 190 SHOULD assume that the dCDN has no CDNI capabilities. If an out-of- 191 band capability baseline has been exchanged, the uCDN MAY use that 192 information to initialize its capabilities database. In either case, 193 the uCDN SHOULD verify the initial state of the dCDN (as a temporary 194 outage may affect availability in the dCDN). 196 The dCDN MUST support sending its entire set of capabilities to the 197 uCDN through the ALTO service interface 199 [Ed.: The alternative to using a pull from the uCDN is to use the 200 triggers interface for a triggered push, however, this would not be 201 triggering a CDN function, it would be triggering an FCI function, so 202 given that there is no asynchronous action required by the dCDN, it 203 seems that reducing inter-dependency on other CDNI interfaces makes 204 the most sense in this case.] 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. The CDNI Footprint and Capabilities Semantics 212 [I-D.ietf-cdni-footprint-capabilities-semantics] document lists 213 mandatory capabilities types: 215 o Delivery Protocol 217 o Acquisition Protocol 219 o Redirection Mode 221 o CDNI Logging Capabilities 223 o CDNI Metadata Capabilities 225 To be consistent with the base ALTO service definitions, we use the 226 JSON object definition notation as specified in the ALTO [RFC7285] 227 protocol RFC. 229 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 JSONString type; 261 JSONValue value; 262 FCIFootprint footprint<0..*>; 263 } FCIMapData; 265 object { 266 JSONString type; 267 JSONString values<1..*>; 268 } FCIFootprint; 270 The FCIMapData object contains a capability name which identifies the 271 capability, a value object containing the associated Capability 272 Advertisement Object (e.g., delivery-protocols, acquisition- 273 protocols, or redirection-modes, as defined in the CDNI Footprint and 274 Capabilities Semantics 275 [I-D.ietf-cdni-footprint-capabilities-semantics] document). The 276 FCIMapData object may also contain an optional list of FCIFootprint 277 objects. The FCIFootprint object specifies a footprint type (as 278 defined by the CDNI Metadata Footprint Types registry, e.g., 279 IPv4CIDR, IPv6CIDR, ASN, or CountryCode [I-D.ietf-cdni-metadata]) 280 which identifies the contents and encoding of the individual 281 footprint entries contained in the associated values array. 283 The footprint restriction list MUST NOT contain multiple footprint 284 objects of the same type. Footprint restriction information MAY be 285 specified using multiple different footprint types. If no footprint 286 restriction list is specified (or an empty list is specified), it 287 SHALL be understood that all footprint types MUST be reset to 288 "global" coverage. 290 Note: Further optimization of the footprint object to provide quality 291 information for a given footprint is certainly possible, however, it 292 is not critical to the basic interconnection of CDNs. The ability to 293 transfer quality information in capabilities advertisements may be 294 desirable and is noted here for completeness, however, the specifics 295 of such mechanisms are outside the scope of this document. 297 Multiple FCIMapData objects with the same capability type are allowed 298 within a given CDNI FCI Map response as long as the capability option 299 values do not overlap, i.e., a given capability option value MUST NOT 300 show up in multiple FCIMapData objects within a single CDNI FCI Map 301 response. If multiple FCIMapData objects for a given capability type 302 exist, those capability objects MUST have different footprint 303 restrictions; capability objects of a given capability type with 304 identical footprint restrictions MUST be combined into a single 305 capability object. 307 3.1.7. CDNI FCI Capabilities 309 3.1.7.1. Delivery Protocol 311 The delivery protocol refers to the protocol over which an end user 312 (EU) has requested content. If a dCDN does not support the protocol 313 requested by the client, then the dCDN is not a viable candidate for 314 delegation. 316 Though the delivery protocol is specified in the URI scheme (as 317 defined in RFC3986 [RFC3986]) of the client request URL, protocol 318 feature subsets or augmented protocol feature sets MAY be defined and 319 SHOULD correspond with the protocols listed in the CDNI Metadata 320 Protocol Types registry, e.g., HTTP1.1 or HTTPS1.1 321 [I-D.ietf-cdni-metadata]. 323 The delivery protocol capability SHOULD support optional footprint 324 restriction information. The following example shows two lists of 325 protocols with different footprints. 327 GET /fcimap HTTP/1.1 328 Host: alto.example.com 329 Accept: application/alto-fcimap+json,application/alto-error+json 331 HTTP/1.1 200 OK 332 Content-Length: 623 333 Content-Type: application/alto-fcimap+json 334 { 335 "meta" : { 336 }, 337 "fcimap": [ 338 { "type": "application/cdni.FCI.DeliveryProtocol.v1+json" 339 "value": { 340 "delivery-protocols": [ 341 "HTTP1.1" 342 ] 343 } 344 }, 345 { "type": "application/cdni.FCI.DeliveryProtocol.v1+json" 346 "value": { 347 "delivery-protocols": [ 348 "HTTPS1.1" 349 ] 350 }, 351 "footprint": [ 352 { "type": "IPv4CIDR", 353 "values": [ 354 "10.1.0.0/16", 355 "10.10.10.0/24" 356 ] 357 } 358 ] 359 } 360 ] 361 } 363 In the above example, the HTTP1.1 protocol is supported globally, 364 while the HTTPS1.1 protocol is only supported in a restricted 365 footprint (in this case, specified by IPv4 prefix). 367 A given protocol MUST NOT appear in multiple FCIMapData application/ 368 cdni.FCI.DeliveryProtocol.v1+json object values. 370 3.1.7.2. Acquisition Protocol 372 The acquisition protocol refers to the protocol over which an end 373 user (EU) has requested content. If a dCDN does not support the 374 protocol requested by the client, then the dCDN is not a viable 375 candidate for delegation. 377 Though the acquisition protocol is specified in the URI scheme (as 378 defined in RFC3986 [RFC3986]) of the client request URL, protocol 379 feature subsets or augmented protocol feature sets MAY be defined and 380 SHOULD correspond with the protocols listed in the CDNI Metadata 381 Protocol Types registry, e.g., HTTP1.1 or HTTPS1.1 382 [I-D.ietf-cdni-metadata]. 384 The acquisition protocol capability SHOULD support optional footprint 385 restriction information. The following example shows two lists of 386 protocols with different footprints. 388 GET /fcimap HTTP/1.1 389 Host: alto.example.com 390 Accept: application/alto-fcimap+json,application/alto-error+json 392 HTTP/1.1 200 OK 393 Content-Length: 616 394 Content-Type: application/alto-fcimap+json 395 { 396 "meta" : { 397 }, 398 "fcimap": [ 399 { "type": "application/cdni.FCI.AcquisitionProtocol.v1+json" 400 "value": { 401 "acquisition-protocols": [ 402 "HTTP1.1" 403 ] 404 } 405 }, 406 { "type": "application/cdni.FCI.AcquisitionProtocol.v1+json" 407 "value": { 408 "acquisition-protocols": [ 409 "HTTPS1.1" 410 ] 411 }, 412 "footprint": [ 413 { "type": "ASN", 414 "values": [ 415 "AS0", 416 "AS65535" 417 ] 418 } 419 ] 420 } 421 ] 422 } 424 In the above example, the HTTP1.1 protocol is supported globally, 425 while the HTTPS1.1 protocol is only supported in a restricted 426 footprint (in this case, specified by IPv4 prefix). 428 A given protocol MUST NOT appear in multiple FCIMapData application/ 429 cdni.FCI.AcquisitionProtocol.v1+json value objects. 431 3.1.7.3. Redirection Mode 433 The redirection mode refers to the method(s) employed by request 434 routers to perform request redirection. The CDNI framework [RFC7336] 435 document describes four possible request routing modes: 437 o DNS iterative (DNS-I) 439 o DNS recursive (DNS-R) 441 o HTTP iterative (HTTP-I) 443 o HTTP recursive (HTTP-R) 445 The CDNI Footprint and Capabilities Semantics 446 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI 447 Capabilities Redirection Modes" registry and the initial supported 448 redirection mode values shown in parentheses above. 450 If a dCDN supports only a specific mode or subset of modes that does 451 not overlap with the modes supported by the uCDN, then the dCDN is 452 not a viable candidate for delegation. 454 The redirection mode capability SHOULD support optional footprint 455 restriction information. The following XML-encoded example shows two 456 lists of modes with different footprints. 458 GET /fcimap HTTP/1.1 459 Host: alto.example.com 460 Accept: application/alto-fcimap+json,application/alto-error+json 462 HTTP/1.1 200 OK 463 Content-Length: 750 464 Content-Type: application/alto-fcimap+json 465 { 466 "meta" : { 467 }, 468 "fcimap": [ 469 { "name": "application/cdni.FCI.RedirectionMode.v1+json", 470 "value": { 471 "redirection-modes": [ 472 "DNS-I", 473 "HTTP-I" 474 ] 475 } 476 }, 477 { "name": "application/cdni.FCI.RedirectionMode.v1+json", 478 "value": { 479 "redirection-modes": [ 480 "DNS-R", 481 "HTTP-R" 482 ] 483 }, 484 "footprint": [ 485 { "type": "CountryCode", 486 "values": [ 487 "SE" 488 ] 489 }, 490 { "type": "IPv6CIDR", 491 "values": [ 492 "9876:5432::1/36" 493 ] 494 } 495 ] 496 } 497 ] 498 } 500 In the above example, iterative redirection is supported globally, 501 while recursive redirection is only supported in a restricted 502 footprint (in this case, specified by both Country Code and IPv6 503 prefix). 505 A given mode MUST NOT appear in multiple FCIMapData application/ 506 cdni.FCI.RedirectionMode.v1+json object values. 508 3.1.7.4. Logging Capabilities 510 The CDNI Logging interface [I-D.ietf-cdni-logging] document describes 511 optional logging fields and functionality which may be optional for a 512 dCDN to implement. If a dCDN does not support certain logging 513 parameters which may affect billing agreements or legal requirements 514 of the uCDN, then the dCDN is not a viable candidate for delegation. 516 3.1.7.5. Metadata Capabilities 518 The CDNI Metadata interface [I-D.ietf-cdni-metadata] document 519 describes generic metadata types which may be optional for a dCDN to 520 implement, but which, if present, are mandatory-to-enforce. If a 521 dCDN does not support certain metadata types which are designated 522 mandatory-to-enforce and may affect the correctness or security of 523 the content being delivered, then the dCDN is not a viable candidate 524 for delegation. 526 4. CDNI FCI Capabilities Filtering Service 528 4.1. Filtered CDNI FCI Map 530 4.1.1. Media Type 532 Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the 533 media type defined for CDNI FCI Map (see Section 3.1.1). 535 4.1.2. HTTP Method 537 A Filtered CDNI FCI Map is requested using the HTTP POST method. 539 4.1.3. Accept Input Parameters 541 TBD. 543 4.1.4. Capabilities 545 None. 547 4.1.5. Uses 549 TBD. 551 4.1.6. Response 553 The format is the same as unfiltered CDNI FCI Map (see 554 Section 3.1.6). 556 4.1.7. Example 558 TBD. 560 5. Footprint via ALTO Network Map 562 5.1. ALTO Network Maps 564 The ALTO Protocol offers an information service "ALTO map service" 565 that provides information to ALTO clients in the form of Network Map 566 and Cost Map [RFC7285]. As an alternative to the explicit definition 567 of a footprint (e.g. with type "IPv4CIDR", see examples above), a 568 reference to an ALTO network map can be used to define an FCI 569 footprint. To enable such referencing to ALTO network maps from 570 within an CDNI FCI Map JSON object, a new optional footprint type 571 'altonetworkmap' is defined (see also Section 6) which has as values 572 a URI to an ALTO server that host an ALTO network map of media type 573 'application/alto-networkmap+json' (as defined in the ALTO protocol 574 specification [RFC7285]), followed by a list of PIDs [RFC7285] within 575 that network map. Parsing and processing of such an ALTO network map 576 that expresses an FCI footprint follows the ALTO protocol 577 specification [RFC7285]. 579 5.2. Example ALTO Network Map for CDNI FCI Footprint 581 An ALTO client can retrieve a network map of media type 'application/ 582 alto-networkmap+json' under a given URI (e.g. 583 'http://alto.example.com/fcifootprint001') with a GET request for a 584 network map as specified in the ALTO protocol [RFC7285]. The 585 following network map would convey to a uCDN that the given dCDN 586 (which would provide the map) has three footprints called ''south- 587 france'', ''germany'', and ''rest'', and provide the corresponding 588 IPv4 address ranges for these footprints. The entry ''cdni-fruit'' : 589 [''orange''] in the ''south-france'' footprint is an example of how 590 new endpoint types (e.g. proprietary ones that are defined outside 591 the CDNI FCI among certain CDNs) could be used in an ALTO network 592 map. 594 GET /networkmap HTTP/1.1 595 Host: http://alto.example.com/fcifootprint001 596 Accept: application/alto-networkmap+json,application/alto-error+json 598 HTTP/1.1 200 OK 599 Content-Length: TBA 600 Content-Type: application/alto-networkmap+json 602 { 603 "meta" : { 604 "vtag": [ 605 {"resource-id": "my-eu-netmap", 606 "tag": "1266506139" 607 } 608 ] 609 }, 610 "network-map" : { 611 "south-france" : { 612 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ], "cdni-fruit" : ["orange"] 613 }, 614 "germany" : { 615 "ipv4" : [ "192.0.3.0/24"] 616 }, 617 "rest" : { "ipv4": [0.0.0.0/0], "ipv6"; [::/0] } 618 } 619 } 620 } 622 5.3. Example of ALTO Network Map Footprint in FCI Map 624 To reference to an ALTO network map as an FCI footprint, the 625 FCIFootprint JSON object must be of type 'altonetworkmap' with values 626 containing the URI of the ALTO server hosting the network map and a 627 list of PID names contained in the network map. The following 628 example shows the CDNI FCI map on delivery protocol capabilities from 629 Section 3.1.7.1, with the difference that the footprint for the FCI 630 delivery protocol capabilities 'RTMP' and 'HTTPS' is given via a 631 reference to an ALTO network map and corresponding PID names. 633 GET /fcimap HTTP/1.1 634 Host: alto.example.com 635 Accept: application/alto-fcimap+json,application/alto-error+json 637 HTTP/1.1 200 OK 638 Content-Length: 439 639 Content-Type: application/alto-fcimap+json 640 { 641 "meta" : { 642 }, 643 "fcimap": [ 644 { "name": "delivery_protocol", 645 "values": [ 646 "HTTP", 647 "RTSP", 648 "MMS" 649 ] 650 }, 651 { "name": "delivery_protocol", 652 "values": [ 653 "RTMP", 654 "HTTPS" 655 ], 656 "footprint": [ 657 { "type": "altonetworkmap", 658 "values": [ 659 "http://alto.example.com/fcifootprint001", 660 "germany", 661 "south-france", 662 ] 663 } 664 ] 665 } 666 ] 667 } 669 6. IANA Considerations 671 This document requests the registration of two new media types: 673 +-------------+-----------------------------+ 674 | Type | Subtype | 675 +-------------+-----------------------------+ 676 | application | alto-cdni-fcimap+json | 677 | application | alto-cdni-fcimapfilter+json | 678 +-------------+-----------------------------+ 680 This document requests the following addition to the CDNI Footprint 681 type namespace which is defined in the CDNI Metadata Interface 682 [I-D.ietf-cdni-metadata] specification: 684 +----------------+----------------------------------+---------------+ 685 | Type name | Description | Specification | 686 +----------------+----------------------------------+---------------+ 687 | altonetworkmap | URI of an ALTO Server hosting an | RFCthis | 688 | | ALTO network map, followed by a | | 689 | | comma-seperated list of PID- | | 690 | | names | | 691 +----------------+----------------------------------+---------------+ 693 7. Security Considerations 695 There are a number of security concerns associated with the FCI. The 696 FCI essentially provides configuration information which the uCDN 697 uses to make request routing decisions. Injection of fake capability 698 advertisement messages or the interception and discard of real 699 capability advertisement messages may be used for denial of service 700 (e.g., by falsely advertising or deleting capabilities or preventing 701 capability advertisements from reaching the uCDN). dCDN capability 702 advertisements MUST be authenticated by the uCDN to prevent 703 unauthorized capability injection. uCDN FCI servers MUST be 704 authenticated by the dCDN to prevent unauthorized interception of 705 ALTO messages. TLS with client authentication SHOULD be used for all 706 FCI implementations. Deployments in controlled environments where 707 physical security and IP address white-listing is employed MAY choose 708 not to use TLS. 710 8. Acknowledgements 712 The authors would like to thank Jon Peterson, Ray van Brandenburg, 713 Gilles Bertrand, and Scott Wainner for their timely reviews and 714 invaluable comments. 716 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 717 Architecture and Applications of Green Information Centric 718 Networking), a research project supported jointly by the European 719 Commission under its 7th Framework Program (contract no. 608518) and 720 the National Institute of Information and Communications Technology 721 (NICT) in Japan (contract no. 167). The views and conclusions 722 contained herein are those of the authors and should not be 723 interpreted as necessarily representing the official policies or 724 endorsements, either expressed or implied, of the GreenICN project, 725 the European Commission, or NICT. 727 9. References 729 9.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 735 Resource Identifier (URI): Generic Syntax", STD 66, RFC 736 3986, January 2005. 738 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 739 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 740 Traffic Optimization (ALTO) Protocol", RFC 7285, September 741 2014. 743 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 744 "Framework for Content Distribution Network 745 Interconnection (CDNI)", RFC 7336, August 2014. 747 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 748 Interconnection (CDNI) Requirements", RFC 7337, August 749 2014. 751 9.2. Informative References 753 [I-D.ietf-cdni-footprint-capabilities-semantics] 754 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 755 and K. Ma, "CDNI Request Routing: Footprint and 756 Capabilities Semantics", draft-ietf-cdni-footprint- 757 capabilities-semantics-05 (work in progress), March 2015. 759 [I-D.ietf-cdni-logging] 760 Faucheur, F., Bertrand, G., Oprescu, I., and R. 761 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 762 logging-15 (work in progress), February 2015. 764 [I-D.ietf-cdni-metadata] 765 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 766 "CDN Interconnection Metadata", draft-ietf-cdni- 767 metadata-09 (work in progress), March 2015. 769 [I-D.ietf-cdni-redirection] 770 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 771 Redirection Interface for CDN Interconnection", draft- 772 ietf-cdni-redirection-08 (work in progress), February 773 2015. 775 Appendix A. Capability Aggregation 777 The following sections show examples of three aggregation scenarios. 778 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 779 CDN which must perform capabilities aggregation. 781 A.1. Downstream CDN Aggregation 783 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 784 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 785 Given the setup shown in Figure A1, we can construct a number of use 786 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 787 and C). Note: In all cases, the reachability of the uCDN (i.e., CDN- 788 U) is a don't care as it is assumed that the uCDN knows its own 789 coverage area and is likely to favor itself in most situations, and 790 if it has decided that it needs to delegate to a dCDN, then the only 791 relevant question is if the dCDN can handle the request. 793 ,---,---,---. 794 ,-' `-. 795 ( rr0.u.example.com ) 796 `-. CDN-U ,-' 797 `---'-+-'- --' 798 | 799 ,---,-+-,---. 800 ,-' `-. 801 ( rr0.p.example.com ) 802 `-. CDN-P ,-' 803 `---'-+-'---' 804 | 805 +---------------------+---------------------+ 806 / | \ 807 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 808 ,-' `-. ,-' `-. ,-' `-. 809 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 810 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 811 `---'---'---' `---'---'---' `---'---'---' 813 Figure A1: CDNI dCDN Request Router Aggregation 815 o None of the four dCDNs (CDNs P, A, B, and C) have global 816 reachability. In this case, each CDN is likely to advertise 817 footprint information with its capabilities, specifying its 818 reachability. When CDN-P advertises capabilities to CDN-U, it may 819 advertise the aggregate footprint of itself and CDNs A, B, and C. 820 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 821 per its own internal aggregation decision criteria. 823 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 824 this case, none of the CDNs is likely to advertise any footprint 825 information as none have any footprint restrictions. When CDN-P 826 advertises capabilities to CDN-U, the aggregate of all global 827 reachability is global reachability. 829 o Some of the four dCDNs (CDNs P, A, B, and C) have global 830 reachability and some do not. In this case, even though some 831 dCDNs do not have global reachability, the aggregate of some dCDNs 832 having global reachability and some not should still be global 833 reachability (for the given capability). When CDN-P advertises 834 capabilities to CDN-U, CDN-P may advertise capabilities for which 835 at least one dCDN has global reach as being supported with global 836 reachability. It is up to the CDN-P request router to properly 837 select a dCDN to process individual client requests and not choose 838 a dCDN whose restricted footprint makes it unsuitable for 839 delivering the requested content. 841 A.2. Internal Request Router Aggregation 843 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 844 request routers: the authoritative request router rr0, and three 845 other request routers rr1, rr2, and rr3. The use of multiple request 846 routers may be used to distribute request routing load across 847 resources, possibly in different geographic regions covered by CDN-P. 848 Similar to Figure A1, the setup shown in Figure A2 requires the 849 authoritative request router rr0 in CDN-P to aggregate capabilities 850 information from downstream request routers rr1, rr2, and rr3. The 851 primary difference between the scenario is that the request routers 852 in Figure A2 are logically within the same CDN-P organization. The 853 same reachability scenarios apply to Figure A2 as with Figure A1. 855 ,---,---,---. 856 ,-' `-. 857 ( rr0.u.example.com ) 858 `-. CDN-U ,-' 859 `---'-+-'---' 860 | 861 ,---,---,---,--,-+-,--,---,---,---. 862 ( ) 863 ,-' +-------------------+ `-. 864 ( | rr0.p.example.com | ) 865 ,-' +---------+---------+ `-. 866 ( | ) 867 ,-' +----------+----------+ `-. 868 ( / | \ ) 869 ) +---------+---------+ | +---------+---------+ ( 870 ( | rr1.p.example.com | | | rr3.p.example.com | ) 871 `. +-------------------+ | +-------------------+ ,' 872 ( | ) 873 `-. +---------+---------+ ,-' 874 ( | rr2.p.example.com | ) 875 `-. +-------------------+ ,-' 876 ( CDN-P ) 877 `---'---'---'---'---'---'---'---'---' 879 Figure A2: Local CDN Request Router Aggregation 881 o None of the four CDN-P request routers have global reachability. 882 In this case, each request router is likely to advertise footprint 883 information with its capabilities, specifying its reachability. 884 When rr0 advertises capabilities to CDN-U, it may advertise the 885 aggregate footprint of itself and rr1, rr2, and rr3. 887 o All four CDN-P request routers have global reachability. In this 888 case, none of the request routers is likely to advertise any 889 footprint information as none has any footprint restrictions. 890 When rr0 advertises capabilities to CDN-U, the aggregate of all 891 global reachability is global reachability. 893 o Some of the four CDN-P request routers have global reachability 894 and some do not. In this case, even though some request routers 895 do not have global reachability, the aggregate of some request 896 routers having global reachability and some not should still be 897 global reachability (for the given capability). When rr0 898 advertises capabilities to CDN-U, CDN-P may advertise capabilities 899 for which at least one request router has global reach as being 900 supported with global reachability. It is up to the authoritative 901 request router rr0 to properly select from the other request 902 routers for any given request, and not choose a request router 903 whose restricted footprint makes it unsuitable for delivering the 904 requested content. 906 A.3. Internal Capability Aggregation 908 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 909 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 910 Figure A3 differs from Figures A1 and A2 in that request router rr0 911 of CDN-P is not aggregating the capabilities advertisements of 912 multiple other downstream request routers, but rather it is managing 913 the disparate capabilities across resources within its own local CDN. 914 Though not every delivery node has the same protocol capabilities, 915 the aggregate delivery protocol capabilities advertised by CDN-A may 916 include all delivery protocols. Note, Figure A3 should not be 917 construed to imply anything about the coverage areas for each 918 delivery protocol. They may all support the same delivery footprint, 919 or they may have different delivery footprints. It is the 920 responsibility of the request router rr0 to properly assign protocol- 921 appropriate delivery nodes to individual content requests. If 922 certain protocols have limited reachability, CDN-P may advertise 923 footprint restrictions for each protocol. 925 It should be noted that though the delivery protocol capability was 926 selected for this example, the concept of internal capability 927 aggregation applies to all capabilities as discussed below. 929 ,---,---,---. 930 ,-' `-. 931 ( rr0.u.example.com ) 932 `-. CDN-U ,-' 933 `---'-+-'---' 934 | 935 ,---,---,---,--,-+-,--,---,---,---. 936 ( ) 937 ,-' +-------------------+ `-. 938 ( | rr0.p.example.com | ) 939 ,-' +---------+---------+ `-. 940 ( . ) 941 ,-' ....................... `-. 942 ( . . . ) 943 ) +-------------------+ . +-------------------+ ( 944 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 945 `. +-------------------+ . +-------------------+ ,' 946 ( . ) 947 `-. +-------------------+ ,-' 948 ( |http.p.example.com | ) 949 `-. +-------------------+ ,-' 950 ( CDN-A ) 951 `---'---'---'---'---'---'---'---'---' 953 Figure A3: Local CDN Capability Segregation 955 Another situation in which physical footprint may not matter in an 956 aggregated view has to do with feature support (e.g., new CDNI 957 metadata features or new redirection modes). Situations often arise 958 when phased roll-out of software upgrades, or staging network 959 segregation result in only certain portions of a CDN's resources 960 supporting the new feature set. The dCDN has a few options in this 961 case: 963 o Enforce atomic update: The dCDN does not advertise support for the 964 new capability until all resources have been upgraded to support 965 the new capability. 967 o Transparent segregation: The dCDN advertises support for the new 968 capability, and when requests are received that require the new 969 capability, the dCDN request router properly selects a resource 970 which supports that capability. 972 o Advertised segregation: The dCDN advertises support for the new 973 capability with a footprint restriction allowing the uCDN to make 974 delegation decisions based on the dCDN's limit support. 976 The level of aggregation employed by the dCDN is likely to vary as 977 business relationships dictate, however, the FCI should support all 978 possible modes of operation. 980 Authors' Addresses 982 Kevin J. Ma 983 Ericsson 984 43 Nagog Park 985 Acton, MA 01720 986 USA 988 Phone: +1 978-844-5100 989 Email: kevin.j.ma@ericsson.com 991 Jan Seedorf 992 NEC 993 Kurfuerstenanlage 36 994 Heidelberg 69115 995 Germany 997 Phone: +49 6221 4342 221 998 Fax: +49 6221 4342 155 999 Email: seedorf@neclab.eu