idnits 2.17.1 draft-ma-cdni-capabilities-08.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 14, 2016) is 2933 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-17 -- 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 16, 2016 NEC 6 April 14, 2016 8 CDNI Footprint & Capabilities Advertisement Interface 9 draft-ma-cdni-capabilities-08 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 16, 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . 16 81 4.1. Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . . 16 82 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 16 83 4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 16 84 4.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 16 85 4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 16 86 4.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 16 88 4.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 17 89 5. Footprint via ALTO Network Map . . . . . . . . . . . . . . . 17 90 5.1. ALTO Network Maps . . . . . . . . . . . . . . . . . . . . 17 91 5.2. Example ALTO Network Map for CDNI FCI Footprint . . . . . 17 92 5.3. Example of ALTO Network Map Footprint in FCI Map . . . . 18 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 6.1. ALTO Media Types . . . . . . . . . . . . . . . . . . . . 20 96 6.1.1. ALTO CDNI FCI Map Media Type . . . . . . . . . . . . 20 97 6.1.2. ALTO CDNI FCI Map Filter Media Type . . . . . . . . . 21 98 6.2. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 23 99 6.2.1. CDNI FCI Logging Payload Type . . . . . . . . . . . . 23 100 6.2.2. CDNI FCI Metadata Payload Type . . . . . . . . . . . 23 101 6.3. CDNI Footprint Types . . . . . . . . . . . . . . . . . . 23 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 7.1. Securing the CDNI Footprint & Capabilities Advertisement 104 interface . . . . . . . . . . . . . . . . . . . . . . . . 24 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 108 9.2. Informative References . . . . . . . . . . . . . . . . . 26 109 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 27 110 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 27 111 A.2. Internal Request Router Aggregation . . . . . . . . . . . 28 112 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 30 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 115 1. Introduction 117 The need for footprint and capabilities advertisement in Content 118 Distribution Network Interconnection (CDNI) is described in the CDNI 119 requirements document [RFC7337]. Requirements FCI-1 and FCI-2 120 describe the need to allow dCDNs to communicate capabilities to the 121 uCDN. Requirement FCI-3 describes how a uCDN may aggregate the 122 footprint and capabilities information for all cascaded dCDNs and use 123 the aggregated information in advertisements to CDNs further 124 upstream. This concept of aggregation can apply to both 125 organizationally different dCDNs (e.g., other CDN providers, or 126 different business units within a larger organization) or logical 127 entities within the same CDN (e.g., using multiple request routers 128 for scalability reasons, to segregate surrogates based on specific 129 protocol support, or to segregate surrogates based on software 130 version or feature level, etc.). 132 Appendix A contains more detailed descriptions of different footprint 133 and capabilities management scenarios, but it is important to note 134 that it is the ability of the dCDN to service each request in a 135 functionally equivalent manner as the uCDN that is important, not the 136 physical layout of resources through which it services the request. 137 The aggregation of resource knowledge by the dCDN into a simple set 138 of capabilities and their affective footprints, that is then 139 advertised to the uCDN, enables efficient decision making at each 140 delegation point in the CDN interconnection hierarchy. 142 It is assumed that an authoritative request router in each CDN will 143 be responsible for aggregating and advertising capabilities 144 information in a dCDN and/or receiving and aggregating capabilities 145 information in the uCDN. The CDNI Footprint & Capabilities 146 Advertisement interface (FCI) along with the CDNI Request Routing 147 Redirection interface (RI) [I-D.ietf-cdni-redirection] make up the 148 CDNI Request Routing Interface. As there is no other centralized 149 CDNI controller, the authoritative request router seems the most 150 logical place for capabilities aggregation to occur, as it is the 151 request router that needs such information to make delegation 152 decisions. The protocol defined herein may be implemented as part of 153 an entity other than an authoritative request router, but for the 154 purposes of this discussion, the authoritative request router is 155 assumed to be the centralized capabilities aggregation point. 157 Though there is an obvious need for the ability to exchange and 158 update footprint and capability information in real-time, it is 159 assumed that capabilities do not change very often. It is also 160 assumed that the capabilities are not by themselves useful for making 161 delegation decisions. Capability information is assumed to be input 162 into business logic. It is the business logic which provides the 163 algorithms for delegation decision making. The definition of 164 business logic occurs outside the scope of CDNI and outside the 165 timescale of footprint and capability advertisement 166 [I-D.ietf-cdni-footprint-capabilities-semantics]. It may be the case 167 that the business logic anticipates and reacts to changes in dCDN 168 capabilities, however, it may also be the case that business logic is 169 tailored through offline processes as dCDN capabilities change. The 170 FCI is agnostic to the business processes employed by any given uCDN. 171 The footprints and capabilities that are advertised over the FCI may 172 be used by the uCDN at its discretion, to implement delegation rules. 173 Setting proper defaults in the business logic should prevent any 174 unwanted delegation from occurring when dCDN capabilities change, 175 however, that is beyond the scope of this discussion. 177 1.1. Terminology 179 This document uses the terminology defined in section 1.1 of the CDNI 180 Framework [RFC7336] document. 182 2. CDNI FCI Capability Advertisement 184 The FCI is implemented as an ALTO [RFC7285] Service. The ALTO 185 protocol defines an HTTP-based transport through which ALTO service 186 information may be retrieved using either a GET or POST method. The 187 uCDN request router may at any time query the dCDN ALTO FCI Service 188 for the full set of dCDN capability information. The uCDN may use a 189 separate FCI Filter Service to retrieve a subset of the dCDN 190 capability information. 192 [Ed.: Need to update this with ALTO asynchronous update support.] 194 [Ed.: Need to update this with ALTO incremental update support.] 196 2.1. CDNI FCI Capability Initialization 198 In lieu of any out-of-band pre-configured capability information, 199 when the FCI is first brought up between a uCDN and a dCDN, the uCDN 200 SHOULD assume that the dCDN has no CDNI capabilities. If an out-of- 201 band capability baseline has been exchanged, the uCDN MAY use that 202 information to initialize its capabilities database. In either case, 203 the uCDN SHOULD verify the initial state of the dCDN (as a temporary 204 outage may affect availability in the dCDN). 206 The dCDN MUST support sending its entire set of capabilities to the 207 uCDN through the ALTO service interface 209 3. CDNI FCI Capabilities Service 211 As described in Requirement FCI-2, there is a basic set of 212 capabilities that must be supported by the FCI for the uCDN to be 213 able to determine if the dCDN is functionally able to handle a given 214 request. [I-D.ietf-cdni-footprint-capabilities-semantics] lists 215 mandatory capabilities types: 217 o Delivery Protocol 219 o Acquisition Protocol 221 o Redirection Mode 223 o CDNI Logging Capabilities 225 o CDNI Metadata Capabilities 227 To be consistent with the base ALTO service definitions, we use the 228 JSON object definition notation as specified in the ALTO protocol 229 [RFC7285]. 231 3.1. CDNI FCI Map 232 3.1.1. Media Type 234 The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json" 236 3.1.2. HTTP Method 238 A CDNI FCI Map resource is requested using the HTTP GET method. 240 3.1.3. Accept Input Parameters 242 None. 244 3.1.4. Capabilities 246 None. 248 3.1.5. Uses 250 None. 252 3.1.6. Response 254 The data component of a CDNI FCI Map resource is named "fcimap" which 255 is a JSON object of type FCIMapData: 257 object { 258 FCIMapData fcimap<0..*>; 259 } InfoResourceFCIMap : ResponseEntityBase; 261 object { 262 FCICapability capabilities<1..*>; 263 } FCIMapData; 265 object { 266 JSONString capability-type; 267 JSONValue capability-value 268 FCIFootprint footprints<0..*>; 269 } FCICapability; 271 object { 272 JSONString footprint-type; 273 JSONString footprint-value<1..*>; 274 } FCIFootprint; 276 The FCIMapData object contains a CDNI Payload Type [RFC7736] "ptype" 277 which identifies the capability and a "value" object containing the 278 associated Capability Advertisement Object (e.g., delivery-protocols, 279 acquisition-protocols, or redirection-modes, as defined in 281 [I-D.ietf-cdni-footprint-capabilities-semantics]). The FCIMapData 282 object may also contain an optional list of FCIFootprint objects 283 "footprints". The FCIFootprint object specifies a "footprint-type" 284 (as defined by the CDNI Metadata Footprint Types registry, e.g., 285 ipv4cidr, ipv6cidr, asn, or countrycode [I-D.ietf-cdni-metadata]) 286 which identifies the contents and encoding of the individual 287 footprint entries contained in the associated "footprint-value" 288 array. 290 The "footprints" list MUST NOT contain multiple FCIFootprint objects 291 of the same type. Footprint restriction information MAY be specified 292 using multiple different footprint-types. If no footprint 293 restriction list is specified (or an empty list is specified), it 294 SHALL be understood that all footprint types MUST be reset to 295 "global" coverage. 297 Note: Further optimization of the footprint object to provide quality 298 information for a given footprint is certainly possible, however, it 299 is not necessary for the basic interconnection of CDNs. The ability 300 to transfer quality information in capabilities advertisements may be 301 desirable and is noted here for completeness, however, the specifics 302 of such mechanisms are outside the scope of this document. 304 Multiple FCIMapData objects with the same capability type are allowed 305 within a given CDNI FCI Map response as long as the capability option 306 footprint-value do not overlap, i.e., a given capability option value 307 MUST NOT show up in multiple FCIMapData objects within a single CDNI 308 FCI Map response. If multiple FCIMapData objects for a given 309 capability type exist, those capability objects MUST have different 310 footprint restrictions. Capability objects of a given capability 311 type with identical footprint restrictions MUST be combined into a 312 single capability object. 314 3.1.7. CDNI FCI Capabilities 316 3.1.7.1. Delivery Protocol 318 The delivery protocol refers to the protocol over which an end user 319 (EU) has requested content. If a dCDN does not support the protocol 320 requested by the client, then the dCDN is not a viable candidate for 321 delegation. 323 Though the delivery protocol is specified in the URI scheme (as 324 defined in [RFC3986]) of the client request URL, protocol feature 325 subsets or augmented protocol feature sets MAY be defined and SHOULD 326 correspond with the protocols listed in the CDNI Metadata Protocol 327 Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata]. 329 The following example shows two lists of delivery protocols with 330 different footprints. 332 GET /fcimap HTTP/1.1 333 Host: alto.example.com 334 Accept: application/alto-fcimap+json,application/alto-error+json 336 HTTP/1.1 200 OK 337 Content-Length: 627 338 Content-Type: application/alto-fcimap+json 339 { 340 "meta" : { 341 }, 342 "fcimap": { 343 "capabilities": [ 344 { "capability-type": "FCI.DeliveryProtocol" 345 "capability-value": { 346 "delivery-protocols": [ 347 "http1.1" 348 ] 349 } 350 }, 351 { "capability-type": "FCI.DeliveryProtocol" 352 "capability-value": { 353 "delivery-protocols": [ 354 "https1.1" 355 ] 356 }, 357 "footprints": [ 358 { "footprint-type": "ipv4cidr", 359 "footprint-value": [ 360 "10.1.0.0/16", 361 "10.10.10.0/24" 362 ] 363 } 364 ] 365 } 366 ] 367 } 368 } 370 In the above example, the HTTP/1.1 protocol is supported globally, 371 while the HTTP/1.1 over TLS protocol is only supported in a 372 restricted footprint (in this case, specified by IPv4 prefix). 374 A given protocol MUST NOT appear in multiple FCIMapData 375 FCI.DeliveryProtocol object values. 377 3.1.7.2. Acquisition Protocol 379 The acquisition protocol refers to the protocol over which an end 380 user (EU) has requested content. If a dCDN does not support the 381 protocol requested by the client, then the dCDN is not a viable 382 candidate for delegation. 384 Though the acquisition protocol is specified in the URI scheme (as 385 defined in [RFC3986]) of the client request URL, protocol feature 386 subsets or augmented protocol feature sets MAY be defined and SHOULD 387 correspond with the protocols listed in the CDNI Metadata Protocol 388 Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata]. 390 The following example shows two lists of acquisition protocols with 391 different footprints. 393 GET /fcimap HTTP/1.1 394 Host: alto.example.com 395 Accept: application/alto-fcimap+json,application/alto-error+json 397 HTTP/1.1 200 OK 398 Content-Length: 620 399 Content-Type: application/alto-fcimap+json 400 { 401 "meta" : { 402 }, 403 "fcimap": { 404 "capabilities": [ 405 { "capability-type": "FCI.AcquisitionProtocol" 406 "capability-value": { 407 "acquisition-protocols": [ 408 "http1.1" 409 ] 410 } 411 }, 412 { "capability-type": "FCI.AcquisitionProtocol" 413 "capability-value": { 414 "acquisition-protocols": [ 415 "https1.1" 416 ] 417 }, 418 "footprints": [ 419 { "footprint-type": "asn", 420 "footprint-value": [ 421 "AS0", 422 "AS65535" 423 ] 424 } 425 ] 426 } 427 ] 428 } 429 } 431 In the above example, the HTTP/1.1 protocol is supported globally, 432 while the HTTP/1.1 over TLS protocol is only supported in a 433 restricted footprint (in this case, specified by Autonomous System 434 number). 436 A given protocol MUST NOT appear in multiple FCIMapData 437 FCI.AcquisitionProtocol value objects. 439 3.1.7.3. Redirection Mode 441 The redirection mode refers to the method(s) employed by request 442 routers to perform request redirection. The CDNI framework [RFC7336] 443 document describes four possible request routing modes: 445 o DNS iterative (DNS-I) 447 o DNS recursive (DNS-R) 449 o HTTP iterative (HTTP-I) 451 o HTTP recursive (HTTP-R) 453 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI 454 Capabilities Redirection Modes" registry and the initial supported 455 redirection mode values shown in parentheses above. 457 If a dCDN supports only a specific mode or subset of modes that does 458 not overlap with the modes supported by the uCDN, then the dCDN might 459 not be a viable candidate for delegation. 461 The following example shows two lists of redirection modes with 462 different footprints. 464 GET /fcimap HTTP/1.1 465 Host: alto.example.com 466 Accept: application/alto-fcimap+json,application/alto-error+json 468 HTTP/1.1 200 OK 469 Content-Length: 767 470 Content-Type: application/alto-fcimap+json 472 { 473 "meta" : { 474 }, 475 "fcimap": { 476 "capabilities": [ 477 { "capability-type": "FCI.RedirectionMode", 478 "capability-value": { 479 "redirection-modes": [ 480 "DNS-I", 481 "HTTP-I" 482 ] 483 } 484 }, 485 { "capability-type": "FCI.RedirectionMode", 486 "capability-value": { 487 "redirection-modes": [ 488 "DNS-R", 489 "HTTP-R" 490 ] 491 }, 492 "footprints": [ 493 { "footprint-type": "countrycode", 494 "footprint-value": [ 495 "SE" 496 ] 497 }, 498 { "footprint-type": "ipv6cidr", 499 "footprint-value": [ 500 "9876:5432::1/36" 501 ] 502 } 503 ] 504 } 505 ] 506 } 507 } 509 In the above example, iterative redirection is supported globally, 510 while recursive redirection is only supported in a restricted 511 footprint (in this case, specified by both Country Code and IPv6 512 prefix). 514 A given mode MUST NOT appear in multiple FCIMapData 515 FCI.RedirectionMode object values. 517 3.1.7.4. Logging Capabilities 519 [I-D.ietf-cdni-logging] describes the "cdni_http_request_v1" logging 520 record-types and optional vs. mandatory-to-implement logging fields 521 for that record-type. It also allows new logging record-types and 522 logging fields to be defined which would be optional for a dCDN to 523 implement. 525 If a dCDN does not support certain logging parameters which may 526 affect billing agreements or legal requirements of the uCDN, then the 527 dCDN is not a viable candidate for delegation. 529 3.1.7.4.1. CDNI Logging Capability Object 531 The CDNI Logging capability object is used to indicate support for 532 CDNI Logging record-types, as well as CDNI Logging fields which are 533 marked as optional for the specified record-types 534 [I-D.ietf-cdni-logging]. 536 Property: record-type 538 Description: Supported CDNI Logging record-type. 540 Type: String corresponding to an entry from the CDNI Logging 541 record-types registry [I-D.ietf-cdni-logging]) 543 Mandatory-to-Specify: Yes. 545 Property: fields 547 Description: List of supported CDNI Logging fields that are 548 optional for the specified record-type. 550 Type: List of Strings corresponding to entries from the CDNI 551 Logging Field Names registry [I-D.ietf-cdni-logging]. 553 Mandatory-to-Specify: No. Default is that all optional fields 554 are supported. Inclusion of an empty list SHALL be understood 555 to mean that none of the optional fields are supported. 556 Otherwise, only those optional fields that are listed SHALL be 557 understood to be supported. 559 3.1.7.4.2. CDNI Logging Capability Object Serialization 561 The following shows an example of CDNI Logging Capability Object 562 Serialization, for a CDN that supports the optional Content 563 Collection ID logging field (but not the optional Session ID logging 564 field) for the "cdni_http_request_v1" record type. 566 { 567 "capabilities": [ 568 { 569 "capability-type": "FCI.Logging", 570 "capability-value": { 571 "record-type": "cdni_http_request_v1", 572 "fields": [ "s-ccid" ] 573 }, 574 "footprints": [ 575 576 ] 577 } 578 ] 579 } 581 The next example shows the CDNI Logging Capability Object 582 Serialization, for a CDN that supports all optional fields for the 583 "cdni_http_request_v1" record type. 585 { 586 "capabilities": [ 587 { 588 "capability-type": "FCI.Logging", 589 "capability-value": { 590 "record-type": "cdni_http_request_v1" 591 }, 592 "footprints": [ 593 594 ] 595 } 596 ] 597 } 599 3.1.7.5. Metadata Capabilities 601 [I-D.ietf-cdni-metadata] describes GenericMetadata types which may be 602 optional for a dCDN to implement, but which, if present, are 603 mandatory-to-enforce. It also allows for new GenericMetadata to be 604 defined which would be optional for a dCDN to implement. 606 If a dCDN does not support certain GenericMetadata types which are 607 designated mandatory-to-enforce and may affect the correctness or 608 security of the content being delivered, then the dCDN is not a 609 viable candidate for delegation. 611 3.1.7.5.1. CDNI Metadata Capability Object 613 The CDNI Metadata capability object is used to indicate support for 614 CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. 616 Property: metadata 618 Description: List of supported CDNI GenericMetadata types. 620 Type: List of Strings corresponding to entries from the CDNI 621 Payload Type registry [RFC7736]) that correspond to CDNI 622 GenericMetadata objects. 624 Mandatory-to-Specify: Yes. It SHALL be understood that only 625 those GenericMetadata types listed are supported; an empty list 626 SHALL be understood to mean that only structural metadata and 627 simple types are supported [I-D.ietf-cdni-metadata]. 629 3.1.7.5.2. CDNI Metadata Capability Object Serialization 631 The following shows an example of CDNI Metadata Capability Object 632 Serialization, for a CDN that supports only the SourceMetadata 633 GenericMetadata type (i.e., it can acquire and deliver content, but 634 cannot enforce and security policies, e.g., time, location, or 635 protocol ACLs). 637 { 638 "capabilities": [ 639 { 640 "capability-type": "FCI.Metadata", 641 "capability-value": { 642 "metadata": ["MI.SourceMetadata"] 643 }, 644 "footprints": [ 645 646 ] 647 } 648 ] 649 } 651 The next example shows the CDNI Metadata Capability Object 652 Serialization, for a CDN that supports only structural metadata 653 (i.e., it can parse metadata as a transit CDN, but cannot enforce 654 security policies or deliver content). 656 { 657 "capabilities": [ 658 { 659 "capability-type": "FCI.Metadata", 660 "capability-value": { 661 "metadata": [] 662 }, 663 "footprints": [ 664 665 ] 666 } 667 ] 668 } 670 4. CDNI FCI Capabilities Filtering Service 672 4.1. Filtered CDNI FCI Map 674 4.1.1. Media Type 676 Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the 677 media type defined for CDNI FCI Map (see Section 3.1.1). 679 4.1.2. HTTP Method 681 A Filtered CDNI FCI Map is requested using the HTTP POST method. 683 4.1.3. Accept Input Parameters 685 TBD. 687 4.1.4. Capabilities 689 None. 691 4.1.5. Uses 693 TBD. 695 4.1.6. Response 697 The format is the same as unfiltered CDNI FCI Map (see 698 Section 3.1.6). 700 4.1.7. Example 702 TBD. 704 5. Footprint via ALTO Network Map 706 5.1. ALTO Network Maps 708 The ALTO Protocol offers an information service "ALTO map service" 709 that provides information to ALTO clients in the form of Network Map 710 and Cost Map [RFC7285]. As an alternative to the explicit definition 711 of a CDNI Footprint Type (e.g., ipv4cidr, ipv6cidr, as, countrycode), 712 a reference to an ALTO network map can be used to define an FCI 713 footprint. To enable such referencing to ALTO network maps, a new 714 CDNI Footprint Type "altonetworkmap" is defined (see also 715 Section 6.3). 717 The first altonetworkmap entry must be a URI for accessing the ALTO 718 server that hosts the ALTO network map (as defined in the ALTO 719 protocol specification [RFC7285]). All subsequent altonetworkmap 720 entries must be of type PIDName (as defined in [RFC7285], where the 721 PIDName corresponds to a PID in the ALTO network map referenced by 722 the preceding URI. Parsing and processing of an ALTO network map 723 follows the ALTO protocol specification [RFC7285]. 725 5.2. Example ALTO Network Map for CDNI FCI Footprint 727 An ALTO client can retrieve a network map of media type 'application/ 728 alto-networkmap+json' under a given URI (e.g., 729 'http://alto.example.com/fcifootprint001') with a GET request for a 730 network map as specified in the ALTO protocol [RFC7285]. The 731 following network map would convey to a uCDN that the given dCDN 732 (which would provide the map) has three footprints called "south- 733 france" and "germany", and provides the corresponding IPv4 address 734 ranges for these footprints. 736 GET /networkmap HTTP/1.1 737 Host: http://alto.example.com/fcifootprint001 738 Accept: application/alto-networkmap+json,application/alto-error+json 740 HTTP/1.1 200 OK 741 Content-Length: 319 742 Content-Type: application/alto-networkmap+json 744 { 745 "meta" : { 746 "vtag": [ 747 {"resource-id": "my-eu-netmap", 748 "tag": "1266506139" 749 } 750 ] 751 }, 752 "network-map" : { 753 "south-france" : { 754 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] 755 }, 756 "germany" : { 757 "ipv4" : [ "192.0.3.0/24"] 758 } 759 } 760 } 762 5.3. Example of ALTO Network Map Footprint in FCI Map 764 To reference an ALTO network map as an FCI footprint, set the 765 footprint-type to "altonetworkmap", and set the first entry in the 766 footprint-value to the URI of the ALTO server hosting the network 767 map, followed by a list of PID names contained in the network map. 769 The following example shows two lists of delivery protocols (see 770 Section 3.1.7.1), with the second having an ALTO network map 771 footprint. 773 GET /fcimap HTTP/1.1 774 Host: alto.example.com 775 Accept: application/alto-fcimap+json,application/alto-error+json 777 HTTP/1.1 200 OK 778 Content-Length: 618 779 Content-Type: application/alto-fcimap+json 781 { 782 "meta" : { 783 }, 784 "fcimap": { 785 "capabilities": [ 786 { "capability-type": "FCI.DeliveryProtocol", 787 "capability-value": [ 788 "http1.1" 789 ] 790 }, 791 { "capability-type": "FCI.DeliveryProtocol", 792 "capability-value": [ 793 "values": [ 794 "https1.1" 795 ], 796 "footprints": [ 797 { "footprint-type": "altonetworkmap", 798 "footprint-value": [ 799 "http://alto.example.com/fcifootprint001", 800 "germany", 801 "south-france" 802 ] 803 } 804 ] 805 } 806 ] 807 } 808 } 810 In the above example, the HTTP/1.1 protocol is supported globally, 811 while the HTTP/1.1 over TLS protocol is only supported in a 812 restricted footprint (in this case, specified by an ALTO network map 813 for Germany and Southern France). 815 6. IANA Considerations 816 6.1. ALTO Media Types 818 This document requests the registration of the following media types: 820 +-------------+-----------------------------+ 821 | Type | Subtype | 822 +-------------+-----------------------------+ 823 | application | alto-cdni-fcimap+json | 824 | application | alto-cdni-fcimapfilter+json | 825 +-------------+-----------------------------+ 827 6.1.1. ALTO CDNI FCI Map Media Type 829 Type name: application 831 Subtype name: alto-cdni-fcimap+json 833 Required parameters: none 835 Optional parameters: none 837 Encoding considerations: 839 Encoding considerations are identical to those specified for the 840 "application/json" media type. See [RFC7159]. 842 Security considerations: 844 Security considerations relating to the generation and consumption 845 of ALTO Protocol messages are discussed in Section 15 of 846 [RFC7285]. Additional security considerations for the CDNI 847 Footprint & Capabilities Advertisement interface are discussed in 848 Section 7. 850 Interoperability considerations: 852 [RFC7285] and RFCthis specify the format of conforming messages 853 and the interpretation thereof. [RFC Editor: Please replace 854 RFCthis with the published RFC number for this document.] 856 Published specification: RFCthis [RFC Editor: Please replace RFCthis 857 with the published RFC number for this document.] 859 Applications that use this media type: 861 ALTO servers and ALTO clients either stand alone or are embedded 862 within other applications. 864 Fragment identifier considerations: N/A 866 Additional information: N/A 868 Deprecated alias names for this type: N/A 870 Magic number(s): N/A 872 File extension(s): N/A 874 Macintosh file type code(s): N/A 876 Person & email address to contact for further information: 878 Kevin Ma 880 Intended usage: LIMITED USE 882 Restrictions on usage: 884 This media type is intended only for use in CDNI Footprint & 885 Capabilities Advertisement interface protocol message exchanges. 887 Author: IETF CDNI working group 889 Change controller: IETF CDNI working group 891 Provisional registration: no 893 6.1.2. ALTO CDNI FCI Map Filter Media Type 895 Type name: application 897 Subtype name: alto-cdni-fcimapfilter+json 899 Required parameters: none 901 Optional parameters: none 903 Encoding considerations: 905 Encoding considerations are identical to those specified for the 906 "application/json" media type. See [RFC7159]. 908 Security considerations: 910 Security considerations relating to the generation and consumption 911 of ALTO Protocol messages are discussed in Section 15 of 913 [RFC7285]. Additional security considerations for the CDNI 914 Footprint & Capabilities Advertisement interface are discussed in 915 Section 7. 917 Interoperability considerations: 919 [RFC7285] and RFCthis specify the format of conforming messages 920 and the interpretation thereof. [RFC Editor: Please replace 921 RFCthis with the published RFC number for this document.] 923 Published specification: RFCthis [RFC Editor: Please replace RFCthis 924 with the published RFC number for this document.] 926 Applications that use this media type: 928 ALTO servers and ALTO clients either stand alone or are embedded 929 within other applications. 931 Fragment identifier considerations: N/A 933 Additional information: N/A 935 Deprecated alias names for this type: N/A 937 Magic number(s): N/A 939 File extension(s): N/A 941 Macintosh file type code(s): N/A 943 Person & email address to contact for further information: 945 Kevin Ma 947 Intended usage: LIMITED USE 949 Restrictions on usage: 951 This media type is intended only for use in CDNI Footprint & 952 Capabilities Advertisement interface protocol message exchanges. 954 Author: IETF CDNI working group 956 Change controller: IETF CDNI working group 958 Provisional registration: no 960 6.2. CDNI Payload Types 962 This document requests the registration of the following CDNI Payload 963 Types under the IANA CDNI Payload Type registry: 965 +--------------+---------------+ 966 | Payload Type | Specification | 967 +--------------+---------------+ 968 | FCI.Logging | RFCthis | 969 | FCI.Metadata | RFCthis | 970 +--------------+---------------+ 972 [RFC Editor: Please replace RFCthis with the published RFC number for 973 this document.] 975 6.2.1. CDNI FCI Logging Payload Type 977 Purpose: The purpose of this payload type is to distinguish FCI 978 advertisement objects for supported CDNI Logging record-types and 979 optional CDNI Logging Field Names. 981 Interface: FCI 983 Encoding: see Section 3.1.7.4.1 and Section 3.1.7.4.2 985 6.2.2. CDNI FCI Metadata Payload Type 987 Purpose: The purpose of this payload type is to distinguish FCI 988 advertisement objects for supported CDNI GenericMetadata types. 990 Interface: FCI 992 Encoding: see Section 3.1.7.5.1 and Section 3.1.7.5.2 994 6.3. CDNI Footprint Types 996 This document requests the following addition to the "CDNI Metadata 997 Footprint Types" registry: 999 +----------------+----------------------------------+---------------+ 1000 | Footprint Type | Description | Specification | 1001 +----------------+----------------------------------+---------------+ 1002 | altonetworkmap | URI of an ALTO Server hosting an | RFCthis | 1003 | | ALTO network map, followed by a | | 1004 | | list of PID-names | | 1005 +----------------+----------------------------------+---------------+ 1007 [RFC Editor: Please replace RFCthis with the published RFC number for 1008 this document.] 1010 7. Security Considerations 1012 There are a number of security concerns associated with the FCI. The 1013 FCI essentially provides configuration information which the uCDN 1014 uses to make request routing decisions. Injection of fake capability 1015 advertisement messages or the interception and discard of real 1016 capability advertisement messages may be used for denial of service 1017 (e.g., by falsely advertising or deleting capabilities or preventing 1018 capability advertisements from reaching the uCDN). FCI messages may 1019 also be monitored to detect when CDN performance degrades or outages 1020 occur. Such information may be considered private by the dCDN. 1022 dCDN capability advertisements MUST be authenticated by the uCDN to 1023 prevent unauthorized capability injection. uCDN FCI servers MUST be 1024 authenticated by the dCDN to prevent unauthorized interception of 1025 ALTO messages. Encryption MUST be used to ensure confidentiality of 1026 the dCDN's private messages. 1028 7.1. Securing the CDNI Footprint & Capabilities Advertisement interface 1030 An implementation of the CDNI Footprint & Capabilities Advertisement 1031 interface MUST support TLS transport as per [RFC2818] and [RFC7230]. 1032 The use of TLS for transport of the CDNI metadata interface messages 1033 allows: 1035 o The dCDN and uCDN to authenticate each other. 1037 and, once they have mutually authenticated each other, it allows: 1039 o The dCDN and uCDN to authorize each other (to ensure they are 1040 transmitting/receiving CDNI FCI messages from an authorized CDN); 1042 o CDNI FCI messages to be transmitted with confidentiality; and 1044 o The integrity of the CDNI FCI messages to be protected during the 1045 exchange. 1047 In an environment where any such protection is required, TLS MUST be 1048 used (including authentication of the remote end) by the server-side 1049 (uCDN) and the client-side (dCDN) of the CDNI Footprint & 1050 Capabilities Advertisement interface unless alternate methods are 1051 used for ensuring the confidentiality of the information in the CDNI 1052 FCI messages (such as setting up an IPsec tunnel between the two CDNs 1053 or using a physically secured internal network between two CDNs that 1054 are owned by the same corporate entity). 1056 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 1057 followed. 1059 8. Acknowledgements 1061 The authors would like to thank Jon Peterson, Ray van Brandenburg, 1062 Gilles Bertrand, and Scott Wainner for their timely reviews and 1063 invaluable comments. 1065 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 1066 Architecture and Applications of Green Information Centric 1067 Networking), a research project supported jointly by the European 1068 Commission under its 7th Framework Program (contract no. 608518) and 1069 the National Institute of Information and Communications Technology 1070 (NICT) in Japan (contract no. 167). The views and conclusions 1071 contained herein are those of the authors and should not be 1072 interpreted as necessarily representing the official policies or 1073 endorsements, either expressed or implied, of the GreenICN project, 1074 the European Commission, or NICT. 1076 9. References 1078 9.1. Normative References 1080 [I-D.ietf-cdni-footprint-capabilities-semantics] 1081 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 1082 and K. Ma, "CDNI Request Routing: Footprint and 1083 Capabilities Semantics", draft-ietf-cdni-footprint- 1084 capabilities-semantics-16 (work in progress), April 2016. 1086 [I-D.ietf-cdni-logging] 1087 Faucheur, F., Bertrand, G., Oprescu, I., and R. 1088 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 1089 logging-25 (work in progress), April 2016. 1091 [I-D.ietf-cdni-metadata] 1092 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1093 "CDN Interconnection Metadata", draft-ietf-cdni- 1094 metadata-15 (work in progress), April 2016. 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, 1098 DOI 10.17487/RFC2119, March 1997, 1099 . 1101 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1102 Protocol (HTTP/1.1): Message Syntax and Routing", 1103 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1104 . 1106 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1107 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1108 "Application-Layer Traffic Optimization (ALTO) Protocol", 1109 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1110 . 1112 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1113 "Recommendations for Secure Use of Transport Layer 1114 Security (TLS) and Datagram Transport Layer Security 1115 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1116 2015, . 1118 9.2. Informative References 1120 [I-D.ietf-cdni-redirection] 1121 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 1122 Redirection interface for CDN Interconnection", draft- 1123 ietf-cdni-redirection-17 (work in progress), February 1124 2016. 1126 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1127 DOI 10.17487/RFC2818, May 2000, 1128 . 1130 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1131 Resource Identifier (URI): Generic Syntax", STD 66, 1132 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1133 . 1135 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1136 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1137 2014, . 1139 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1140 "Framework for Content Distribution Network 1141 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1142 August 2014, . 1144 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1145 Network Interconnection (CDNI) Requirements", RFC 7337, 1146 DOI 10.17487/RFC7337, August 2014, 1147 . 1149 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 1150 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 1151 December 2015, . 1153 Appendix A. Capability Aggregation 1155 The following sections show examples of three aggregation scenarios. 1156 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 1157 CDN which must perform capabilities aggregation. 1159 A.1. Downstream CDN Aggregation 1161 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 1162 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 1163 Given the setup shown in Figure A1, we can construct a number of use 1164 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 1165 and C). Note: In all cases, the reachability of the uCDN (i.e., CDN- 1166 U) is a don't care as it is assumed that the uCDN knows its own 1167 coverage area and is likely to favor itself in most situations, and 1168 if it has decided that it needs to delegate to a dCDN, then the only 1169 relevant question is if the dCDN can handle the request. 1171 ,---,---,---. 1172 ,-' `-. 1173 ( rr0.u.example.com ) 1174 `-. CDN-U ,-' 1175 `---'-+-'- --' 1176 | 1177 ,---,-+-,---. 1178 ,-' `-. 1179 ( rr0.p.example.com ) 1180 `-. CDN-P ,-' 1181 `---'-+-'---' 1182 | 1183 +---------------------+---------------------+ 1184 / | \ 1185 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 1186 ,-' `-. ,-' `-. ,-' `-. 1187 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 1188 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 1189 `---'---'---' `---'---'---' `---'---'---' 1191 Figure A1: CDNI dCDN Request Router Aggregation 1193 o None of the four dCDNs (CDNs P, A, B, and C) have global 1194 reachability. In this case, each CDN is likely to advertise 1195 footprint information with its capabilities, specifying its 1196 reachability. When CDN-P advertises capabilities to CDN-U, it may 1197 advertise the aggregate footprint of itself and CDNs A, B, and C. 1198 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 1199 per its own internal aggregation decision criteria. 1201 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 1202 this case, none of the CDNs is likely to advertise any footprint 1203 information as none have any footprint restrictions. When CDN-P 1204 advertises capabilities to CDN-U, the aggregate of all global 1205 reachability is global reachability. 1207 o Some of the four dCDNs (CDNs P, A, B, and C) have global 1208 reachability and some do not. In this case, even though some 1209 dCDNs do not have global reachability, the aggregate of some dCDNs 1210 having global reachability and some not should still be global 1211 reachability (for the given capability). When CDN-P advertises 1212 capabilities to CDN-U, CDN-P may advertise capabilities for which 1213 at least one dCDN has global reach as being supported with global 1214 reachability. It is up to the CDN-P request router to properly 1215 select a dCDN to process individual client requests and not choose 1216 a dCDN whose restricted footprint makes it unsuitable for 1217 delivering the requested content. 1219 A.2. Internal Request Router Aggregation 1221 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 1222 request routers: the authoritative request router rr0, and three 1223 other request routers rr1, rr2, and rr3. The use of multiple request 1224 routers may be used to distribute request routing load across 1225 resources, possibly in different geographic regions covered by CDN-P. 1226 Similar to Figure A1, the setup shown in Figure A2 requires the 1227 authoritative request router rr0 in CDN-P to aggregate capabilities 1228 information from downstream request routers rr1, rr2, and rr3. The 1229 primary difference between the scenario is that the request routers 1230 in Figure A2 are logically within the same CDN-P organization. The 1231 same reachability scenarios apply to Figure A2 as with Figure A1. 1233 ,---,---,---. 1234 ,-' `-. 1235 ( rr0.u.example.com ) 1236 `-. CDN-U ,-' 1237 `---'-+-'---' 1238 | 1239 ,---,---,---,--,-+-,--,---,---,---. 1240 ( ) 1241 ,-' +-------------------+ `-. 1242 ( | rr0.p.example.com | ) 1243 ,-' +---------+---------+ `-. 1244 ( | ) 1245 ,-' +----------+----------+ `-. 1246 ( / | \ ) 1247 ) +---------+---------+ | +---------+---------+ ( 1248 ( | rr1.p.example.com | | | rr3.p.example.com | ) 1249 `. +-------------------+ | +-------------------+ ,' 1250 ( | ) 1251 `-. +---------+---------+ ,-' 1252 ( | rr2.p.example.com | ) 1253 `-. +-------------------+ ,-' 1254 ( CDN-P ) 1255 `---'---'---'---'---'---'---'---'---' 1257 Figure A2: Local CDN Request Router Aggregation 1259 o None of the four CDN-P request routers have global reachability. 1260 In this case, each request router is likely to advertise footprint 1261 information with its capabilities, specifying its reachability. 1262 When rr0 advertises capabilities to CDN-U, it may advertise the 1263 aggregate footprint of itself and rr1, rr2, and rr3. 1265 o All four CDN-P request routers have global reachability. In this 1266 case, none of the request routers is likely to advertise any 1267 footprint information as none has any footprint restrictions. 1268 When rr0 advertises capabilities to CDN-U, the aggregate of all 1269 global reachability is global reachability. 1271 o Some of the four CDN-P request routers have global reachability 1272 and some do not. In this case, even though some request routers 1273 do not have global reachability, the aggregate of some request 1274 routers having global reachability and some not should still be 1275 global reachability (for the given capability). When rr0 1276 advertises capabilities to CDN-U, CDN-P may advertise capabilities 1277 for which at least one request router has global reach as being 1278 supported with global reachability. It is up to the authoritative 1279 request router rr0 to properly select from the other request 1280 routers for any given request, and not choose a request router 1281 whose restricted footprint makes it unsuitable for delivering the 1282 requested content. 1284 A.3. Internal Capability Aggregation 1286 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 1287 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 1288 Figure A3 differs from Figures A1 and A2 in that request router rr0 1289 of CDN-P is not aggregating the capabilities advertisements of 1290 multiple other downstream request routers, but rather it is managing 1291 the disparate capabilities across resources within its own local CDN. 1292 Though not every delivery node has the same protocol capabilities, 1293 the aggregate delivery protocol capabilities advertised by CDN-A may 1294 include all delivery protocols. Note, Figure A3 should not be 1295 construed to imply anything about the coverage areas for each 1296 delivery protocol. They may all support the same delivery footprint, 1297 or they may have different delivery footprints. It is the 1298 responsibility of the request router rr0 to properly assign protocol- 1299 appropriate delivery nodes to individual content requests. If 1300 certain protocols have limited reachability, CDN-P may advertise 1301 footprint restrictions for each protocol. 1303 It should be noted that though the delivery protocol capability was 1304 selected for this example, the concept of internal capability 1305 aggregation applies to all capabilities as discussed below. 1307 ,---,---,---. 1308 ,-' `-. 1309 ( rr0.u.example.com ) 1310 `-. CDN-U ,-' 1311 `---'-+-'---' 1312 | 1313 ,---,---,---,--,-+-,--,---,---,---. 1314 ( ) 1315 ,-' +-------------------+ `-. 1316 ( | rr0.p.example.com | ) 1317 ,-' +---------+---------+ `-. 1318 ( . ) 1319 ,-' ....................... `-. 1320 ( . . . ) 1321 ) +-------------------+ . +-------------------+ ( 1322 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 1323 `. +-------------------+ . +-------------------+ ,' 1324 ( . ) 1325 `-. +-------------------+ ,-' 1326 ( |http.p.example.com | ) 1327 `-. +-------------------+ ,-' 1328 ( CDN-A ) 1329 `---'---'---'---'---'---'---'---'---' 1331 Figure A3: Local CDN Capability Segregation 1333 Another situation in which physical footprint may not matter in an 1334 aggregated view has to do with feature support (e.g., new CDNI 1335 metadata features or new redirection modes). Situations often arise 1336 when phased roll-out of software upgrades, or staging network 1337 segregation result in only certain portions of a CDN's resources 1338 supporting the new feature set. The dCDN has a few options in this 1339 case: 1341 o Enforce atomic update: The dCDN does not advertise support for the 1342 new capability until all resources have been upgraded to support 1343 the new capability. 1345 o Transparent segregation: The dCDN advertises support for the new 1346 capability, and when requests are received that require the new 1347 capability, the dCDN request router properly selects a resource 1348 which supports that capability. 1350 o Advertised segregation: The dCDN advertises support for the new 1351 capability with a footprint restriction allowing the uCDN to make 1352 delegation decisions based on the dCDN's limit support. 1354 The level of aggregation employed by the dCDN is likely to vary as 1355 business relationships dictate, however, the FCI should support all 1356 possible modes of operation. 1358 Authors' Addresses 1360 Kevin J. Ma 1361 Ericsson 1362 43 Nagog Park 1363 Acton, MA 01720 1364 USA 1366 Phone: +1 978-844-5100 1367 Email: kevin.j.ma@ericsson.com 1369 Jan Seedorf 1370 NEC 1371 Kurfuerstenanlage 36 1372 Heidelberg 69115 1373 Germany 1375 Phone: +49 6221 4342 221 1376 Fax: +49 6221 4342 155 1377 Email: seedorf@neclab.eu