idnits 2.17.1 draft-ma-cdni-capabilities-02.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 (August 04, 2013) is 3889 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) == Unused Reference: 'I-D.ietf-cdni-logging' is defined on line 486, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-cdni-footprint-capabilities-semantics-00 == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-03 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-05 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-02 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-09 Summary: 0 errors (**), 0 flaws (~~), 7 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 Azuki Systems, Inc. 4 Intended status: Standards Track August 04, 2013 5 Expires: February 05, 2014 7 Content Distribution Network Interconnection (CDNI) Footprint & 8 Capabilities Advertisement Interface 9 draft-ma-cdni-capabilities-02 11 Abstract 13 The interconnection of Content Distribution Networks (CDNs) is 14 predicated on the ability of downstream CDNs (dCDNs) to handle end- 15 user requests in a functionally equivalent manner to the upstream CDN 16 (uCDN). The uCDN must be able to assess the ability of the dCDN to 17 handle individual requests. The CDNI Footprint & Capabilities 18 Advertisement interface (FCI) is provided for the advertisement of 19 capabilities and the footprints to which they apply by the dCDN to 20 the uCDN. This document describes an approach to implementing the 21 CDNI FCI. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 05, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Acquisition Protocol . . . . . . . . . . . . . . . . . . 7 67 2.3. Redirection Mode . . . . . . . . . . . . . . . . . . . . 8 68 3. Capability Advertisement . . . . . . . . . . . . . . . . . . 10 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 11 76 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 11 77 A.2. Internal Request Router Aggregation . . . . . . . . . . . 13 78 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 The need for footprint and capabilities advertisement in CDNI is 84 described in the CDNI requirements document 85 [I-D.ietf-cdni-requirements]. Requirements FCI-1 and FCI-2 describe 86 the need to allow dCDNs to communicate capabilities to the uCDN. 87 Requirement FCI-3 describes how a uCDN may aggregate the footprint 88 and capabilities information for all cascaded dCDNs and use the 89 aggregated information in advertisements to CDNs further upstream. 90 This concept of aggregation can apply to both organizationally 91 different dCDNs (e.g., other CDN providers, or different business 92 units within a larger organization) or logical entities within the 93 same CDN (e.g., using multiple request routers for scalability 94 reasons, to segregate surrogates based on specific protocol support, 95 or to segregate surrogates based on software version or feature 96 level, etc.). 98 Appendix A contains more detailed descriptions of different footprint 99 and capabilities management scenarios, but it is important to note 100 that it is the ability of the dCDN to service each request in a 101 functionally equivalent manner as the uCDN that is important, not the 102 physical layout of resources through which it services the request. 103 The aggregation of resource knowledge by the dCDN into a simple set 104 of capabilities and their affective footprints, that is then 105 advertised to the uCDN enables efficient decision making at each 106 delegation point in the CDN interconnection hierarchy. 108 It is assumed that an authoritative request router in each CDN will 109 be responsible for aggregating and advertising capabilities 110 information in a dCDN, and receiving and aggregating capabilities 111 information in the uCDN. The CDNI Footprint & Capabilities 112 Advertisement interface (FCI) along with the CDNI Request Routing 113 Redirection interface (RI) make up the CDNI Request Routing 114 Interface. As there is no other centralized CDNI controller, the 115 authoritative request router seems the most logical place for 116 capabilities aggregation to occur, as it is the request router that 117 needs such information to make delegation decisions. The protocol 118 defined herein may be implemented as part of an entity other than an 119 authoritative request router, but for the purposes of this 120 discussion, the authoritative request router is assumed to be the 121 centralized capabilities aggregation point. 123 Though there is an obvious need for the ability to exchange and 124 update footprint and capability information in real-time, it is 125 assumed that capabilities do not change very often. It is also 126 assumed that the capabilities are not by themselves useful for making 127 delegation decisions. Capability information is assumed to be input 128 into business logic. It is the business logic which provides the 129 algorithms for delegation decision making. The definition of 130 business logic occurs outside the scope of CDNI and outside the 131 timescale of footprint and capability advertisement. It may be the 132 case that the business logic anticipates and reacts to changes in 133 dCDN capabilities. However, it may also be the case that business 134 logic is tailored through offline processes as dCDN capabilities 135 change. The FCI is agnostic to the business processes employed by 136 any given uCDN. The footprints and capabilities that are advertised 137 over the FCI may be used by the uCDN at its discretion to implement 138 delegation rules. Setting proper defaults in the business logic 139 should prevent any unwanted delegation from occurring when dCDN 140 capabilities change, however, that is beyond the scope of this 141 discussion. 143 1.1. Terminology 145 This document uses the terminology defined in section 1.1 of the CDNI 146 Framework [I-D.ietf-cdni-framework] document. 148 2. Capabilities 150 As described in Requirement FCI-2, there is a basic set of 151 capabilities that must be supported by the FCI for the uCDN to be 152 able to determine if the dCDN is functionally able to handle a given 153 request. The CDNI Footprint and Capabilities Semantics 154 [I-D.ietf-cdni-footprint-capabilities-semantics] document lists 155 mandatory capabilities types: 157 o Delivery Protocol 159 o Acquisition Protocol 161 o Redirection Mode 163 o CDNI Logging Capabilities 165 o CDNI Metadata Capabilities 167 The following sections describe each of the capabilities in further 168 detail, however, all of the capabilities can be described using the 169 same general format. A capability object is specified as: 171 CapabilityObject: 172 Name: Identifier for the capability 173 Values: List of supported options for the capability 174 Footprint: Optional list of footprint objects 176 The list of valid capability options for a given capability will be 177 specific to the given capability type. Though the degenerate case 178 may exist where the range of option values is a single value, it is 179 anticipated that all capability types will have more than one 180 capability option value. For consistency in the model, all 181 capability types are implemented with lists of values. To optimize 182 actions on the entire range of capability option values for a given 183 capability type, the capability option value "ALL" is reserved and 184 MUST be supported by all capability types. For completeness, the 185 capability option value "NONE" is also reserved and MUST be supported 186 by all capability types. If a reserved value is specified, it MUST 187 be the only entry in the capability value list. 189 The footprint restriction list is optional. When included, the 190 footprint restriction list contains a list of generic footprint 191 objects. The footprint object is specified as: 193 FootprintObject: 194 Type: Identifier for the capability 195 Values: List of footprint entries 196 Mode: Optional footprint application directive 198 The footprint type specifies the format of the footprint value 199 entries. The footprint object type field contains the IANA registry 200 defined footprint type name. The CDNI Footprint and Capabilities 201 Semantics [I-D.ietf-cdni-footprint-capabilities-semantics] document 202 lists the mandatory footprint types as: ISO Country Code, AS number, 203 and IP-prefix. The CDNI Footprint and Capabilities Semantics 204 [I-D.ietf-cdni-footprint-capabilities-semantics] document defines the 205 footprint type names for the mandatory footprint types and describes 206 the process for defining additional optional footprint types. The 207 footprint value "GLOBAL" is reserved and MUST be supported by all 208 footprint types. If the reserved value "GLOBAL" is specified, it 209 MUST be the only entry in the footprint value list. 211 The optional footprint mode describes how the footprint should be 212 applied. The valid footprint mode values are: "replace", "include", 213 and "exclude". The footprint mode "replace" (represented by the 214 integer value 0) indicates that all previous footprint information 215 for the given footprint type (and for the capabilities to which the 216 current footprint object applies) MUST be replaced in its entirety 217 with the footprint information specified in the accompanying 218 footprint value list. The footprint mode "include" (represented by 219 the integer value 1) indicates that the any existing footprint 220 information for the given footprint type (and for the capabilities to 221 which the current footprint object applies) SHOULD be augmented with 222 the footprint information specified in the accompanying footprint 223 value list. The footprint mode "exclude" (represented by the integer 224 value 2) indicates that the any existing footprint information for 225 the given footprint type (and for the capabilities to which the 226 current footprint object applies) SHOULD be reduced by the footprint 227 information specified in the accompanying footprint value list. If 228 no footprint mode value is specified, the default mode SHALL be 229 understood to be "replace". 231 The footprint restriction list MUST NOT contain multiple footprint 232 objects of the same type. Footprint restriction information MAY be 233 specified using multiple different footprint types. If no footprint 234 restriction list is specified (or an empty list is specified), it 235 SHALL be understood that all footprint types MUST be reset to 236 "GLOBAL" coverage. 238 Note: Further optimization of the footprint object to provide quality 239 information for a given footprint is certainly possible, however, it 240 is not critical to the basic interconnection of CDNs. The ability to 241 transfer quality information in capabilities advertisements may be 242 desirable and is noted here for completeness, however, the specifics 243 of such mechanisms are outside the scope of this document. 245 Multiple capability objects of the same capability type are allowed 246 within a given FCI message as long as the capability option values do 247 not overlap, i.e., a given capability option value MUST NOT show up 248 in multiple capability objects within a single FCI message. If 249 multiple capability objects for a given capability type exist, those 250 capability objects SHOULD have different footprint restrictions; 251 capability objects of a given capability type with identical 252 footprint restrictions SHOULD be combined into a single capability 253 object. 255 2.1. Delivery Protocol 257 The delivery protocol refers to the protocol over which an end user 258 (EU) has requested content. If a dCDN does not support the protocol 259 requested by the client, then the dCDN is not a viable candidate for 260 delegation. 262 Though the delivery protocol is specified in the URI scheme (as 263 defined in RFC3986 [RFC3986]) of the client request URL, protocol 264 feature subsets or augmented protocol feature sets MAY be defined and 265 SHOULD correspond with the protocols supported by the ProtocolACL 266 defined in the CDNI Metadata Interface [I-D.ietf-cdni-metadata] 267 document. 269 The delivery protocol capability object MUST support a list of 270 protocols for a given footprint. The delivery protocol capability 271 SHOULD support optional footprint restriction information. The 272 following example shows two lists of protocols with different 273 footprints. 275 { 276 "capabilities": [ 277 { "name": "delivery_protocol", 278 "values": [ 279 "HTTP", 280 "RTSP", 281 "MMS" 282 ] 283 }, 284 { "name": "delivery_protocol", 285 "values": [ 286 "RTMP", 287 "HTTPS" 288 ], 289 "footprint": [ 290 { "type": "IPv4", 291 "values": [ 292 "10.1.0.0/16", 293 "10.10.10.0/24" 294 ] 295 } 296 ] 297 } 298 ] 299 } 301 In the above example, the three protocols HTTP, RTSP, and MMS are 302 supported globally, while the protocols RTMP and HTTPS are only 303 supported in a restricted footprint (in this case, specified by IP- 304 prefix). 306 A given protocol MUST NOT appear in multiple capability object value 307 lists, within a given FCI message. 309 2.2. Acquisition Protocol 311 The acquisition protocol refers to the protocol over which the dCDN 312 may acquire content from the uCDN. If a dCDN does not support any of 313 the protocols offered by the uCDN, then the dCDN is not a viable 314 candidate for delegation. 316 Though the acquisition protocol is disseminated to the dCDN in the 317 URI scheme (as defined in RFC3986 [RFC3986]) of the URL provided by 318 the uCDN via the CDNI Metadata Interface [I-D.ietf-cdni-metadata], 319 protocol feature subsets or augmented protocol feature sets MAY be 320 defined and SHOULD correspond with the protocols supported by the 321 ProtocolACL defined in the CDNI Metadata Interface 322 [I-D.ietf-cdni-metadata] document. 324 The acquisition protocol capability object MUST support a list of 325 protocols for a given footprint. The acquisition protocol capability 326 SHOULD support optional footprint restriction information. The 327 following example shows two lists of protocols with different 328 footprints. 330 { 331 "capabilities": [ 332 { "name": "acquisition_protocol", 333 "values": [ 334 "HTTP", 335 "FTP" 336 ] 337 }, 338 { "name": "acquisition_protocol", 339 "values": [ 340 "SFTP", 341 "HTTPS" 342 ], 343 "footprint": [ 344 { "type": "ASN", 345 "values": [ 346 "0", 347 "65535" 348 ], 349 "mode": 2 350 } 351 ] 352 } 353 ] 354 } 356 In the above example, the two protocols HTTP and FTP are supported 357 globally, while the protocols SFTP and HTTPS are updated to only be 358 supported in a reduced restricted footprint (in this case, specified 359 by ASN). 361 A given protocol MUST NOT appear in multiple capability object value 362 lists, within a given FCI message. 364 2.3. Redirection Mode 366 The redirection mode refers to the method(s) employed by request 367 routers to perform request redirection. The CDNI framework 368 [I-D.ietf-cdni-framework] document describes four possible request 369 routing modes: 371 o DNS iterative (DNS-I) 372 o DNS recursive (DNS-R) 374 o HTTP iterative (HTTP-I) 376 o HTTP recursive (HTTP-R) 378 If a dCDN supports only a specific mode or subset of modes that does 379 not overlap with the modes supported by the uCDN, then the dCDN is 380 not a viable candidate for delegation. 382 The redirection mode capability object MUST support a list of 383 redirection modes for a given footprint. The redirection mode 384 capability SHOULD support optional footprint restriction information. 385 The following XML-encoded example shows two lists of modes with 386 different footprints. 388 { 389 "capabilities": [ 390 { "name": "redirection_mode", 391 "values": [ 392 "DNS-I", 393 "HTTP-I" 394 ] 395 }, 396 { "name": "redirection_mode", 397 "values": [ 398 "DNS-R", 399 "HTTP-R" 400 ], 401 "footprint": [ 402 { "type": "ASN", 403 "values": [ 404 "9" 405 ], 406 "mode": 0 407 }, 408 { "type": "IPv6", 409 "values": [ 410 "8765:4321::/36" 411 ] 412 } 413 ] 414 } 415 ] 416 } 418 In the above example, iterative redirection is supported globally, 419 while recursive redirection is only supported in a restricted 420 footprint (in this case, specified by both ASN and IP-prefix). 422 A given mode MUST NOT appear in multiple capability object value 423 lists, within a given FCI message. 425 3. Capability Advertisement 427 The FCI relies an HTTP-based protocol using the POST method. The 428 dCDN request router asynchronously issues FCI messages to the uCDN 429 request router (see Appendix A for detailed descriptions of 430 authoritative request router capabilities aggregation scenarios). It 431 is assumed that the dCDN request router has been configured with the 432 uCDN request router address either through the CDNI Control interface 433 bootstrapping function, or through some other out-of-band 434 configuration. 436 4. IANA Considerations 438 This memo includes no request to IANA. 440 5. Security Considerations 442 There are a number of security concerns associated with the FCI. The 443 FCI essentially provides configuration information which the uCDN 444 uses to make request routing decisions. Injection of fake capability 445 advertisement messages or the interception and discard of real 446 capability advertisement messages may be used for denial of service 447 (e.g., by falsely advertising or deleting capabilities or preventing 448 capability advertisements from reaching the uCDN). dCDN capability 449 advertisements MUST be authenticated by the uCDN to prevent 450 unauthorized FCI message injection. uCDN FCI servers MUST be 451 authenticated by the dCDN to prevent unauthorized interception of FCI 452 messages. TLS with client authentication SHOULD be used for all FCI 453 implementations. Deployments in controlled environments where 454 physical security and IP address white-listing is employed MAY choose 455 not to use TLS. 457 6. Acknowledgements 459 The authors would like to thank Ray van Brandenburg, Gilles Bertrand, 460 and Scott Wainner for their timely reviews and invaluable comments. 462 7. References 464 7.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 470 Resource Identifier (URI): Generic Syntax", STD 66, RFC 471 3986, January 2005. 473 7.2. Informative References 475 [I-D.ietf-cdni-footprint-capabilities-semantics] 476 Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 477 R., and K. Ma, "CDNI Request Routing: Footprint and 478 Capabilities Semantics draft-ietf-cdni-footprint- 479 capabilities-semantics-00", July 2013. 481 [I-D.ietf-cdni-framework] 482 Peterson, L., Ed. and B. Davie, Ed., "Framework for CDN 483 Interconnection draft-ietf-cdni-framework-03", February 484 2013. 486 [I-D.ietf-cdni-logging] 487 Le Faucheur, F., Bertrand, G., Oprescu, I., and R. 488 Peterkofsky, "CDNI Logging Interface draft-ietf-cdni- 489 logging-05", July 2013. 491 [I-D.ietf-cdni-metadata] 492 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 493 Leung, K., and K. Ma, "CDN Interconnect Metadata draft- 494 ietf-cdni-metadata-02", July 2013. 496 [I-D.ietf-cdni-requirements] 497 Leung, K. and Y. Lee, "Content Distribution Network 498 Interconnection (CDNI) Requirements draft-ietf-cdni- 499 requirements-09", July 2013. 501 Appendix A. Capability Aggregation 503 The following sections show examples of three aggregation scenarios. 504 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 505 CDN which must perform capabilities aggregation. 507 A.1. Downstream CDN Aggregation 509 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 510 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 511 Given the setup shown in Figure A1, we can construct a number of use 512 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 513 and C). Note: In all cases, the reachability of the uCDN (i.e., 514 CDN-U) is a don't care as it is assumed that the uCDN knows its own 515 coverage area and is likely to favor itself in most situations, and 516 if it has decided that it needs to delegate to a dCDN, then the only 517 relevant question is if the dCDN can handle the request. 519 ,---,---,---. 520 ,-' `-. 521 ( rr0.u.example.com ) 522 `-. CDN-U ,-' 523 `---'-+-'- --' 524 | 525 ,---,-+-,---. 526 ,-' `-. 527 ( rr0.p.example.com ) 528 `-. CDN-P ,-' 529 `---'-+-'---' 530 | 531 +---------------------+---------------------+ 532 / | \ 533 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 534 ,-' `-. ,-' `-. ,-' `-. 535 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 536 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 537 `---'---'---' `---'---'---' `---'---'---' 539 Figure A1: CDNI dCDN Request Router Aggregation 541 o None of the four dCDNs (CDNs P, A, B, and C) have global 542 reachability. In this case, each CDN is likely to advertise 543 footprint information with its capabilities, specifying its 544 reachability. When CDN-P advertises capabilities to CDN-U, it may 545 advertise the aggregate footprint of itself and CDNs A, B, and C. 546 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 547 per its own internal aggregation decision criteria. 549 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 550 this case, none of the CDNs is likely to advertise any footprint 551 information as none have any footprint restrictions. When CDN-P 552 advertises capabilities to CDN-U, the aggregate of all global 553 reachability is global reachability. 555 o Some of the four dCDNs (CDNs P, A, B, and C) have global 556 reachability and some do not. In this case, even though some 557 dCDNs do not have global reachability, the aggregate of some dCDNs 558 having global reachability and some not should still be global 559 reachability (for the given capability). When CDN-P advertises 560 capabilities to CDN-U, CDN-P may advertise capabilities for which 561 at least one dCDN has global reach as being supported with global 562 reachability. It is up to the CDN-P request router to properly 563 select a dCDN to process individual client requests and not choose 564 a dCDN whose restricted footprint makes it unsuitable for 565 delivering the requested content. 567 A.2. Internal Request Router Aggregation 569 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 570 request routers: the authoritative request router rr0, and three 571 other request routers rr1, rr2, and rr3. The use of multiple request 572 routers may be used to distribute request routing load across 573 resources, possibly in different geographic regions covered by CDN-P. 574 Similar to Figure A1, the setup shown in Figure A2 requires the 575 authoritative request router rr0 in CDN-P to aggregate capabilities 576 information from downstream request routers rr1, rr2, and rr3. The 577 primary difference between the scenario is that the request routers 578 in Figure A2 are logically within the same CDN-P organization. The 579 same reachability scenarios apply to Figure A2 as with Figure A1. 581 ,---,---,---. 582 ,-' `-. 583 ( rr0.u.example.com ) 584 `-. CDN-U ,-' 585 `---'-+-'---' 586 | 587 ,---,---,---,--,-+-,--,---,---,---. 588 ( ) 589 ,-' +-------------------+ `-. 590 ( | rr0.p.example.com | ) 591 ,-' +---------+---------+ `-. 592 ( | ) 593 ,-' +----------+----------+ `-. 594 ( / | \ ) 595 ) +---------+---------+ | +---------+---------+ ( 596 ( | rr1.p.example.com | | | rr3.p.example.com | ) 597 `. +-------------------+ | +-------------------+ ,' 598 ( | ) 599 `-. +---------+---------+ ,-' 600 ( | rr2.p.example.com | ) 601 `-. +-------------------+ ,-' 602 ( CDN-P ) 603 `---'---'---'---'---'---'---'---'---' 605 Figure A2: Local CDN Request Router Aggregation 607 o None of the four CDN-P request routers have global reachability. 608 In this case, each request router is likely to advertise footprint 609 information with its capabilities, specifying its reachability. 611 When rr0 advertises capabilities to CDN-U, it may advertise the 612 aggregate footprint of itself and rr1, rr2, and rr3. 614 o All four CDN-P request routers have global reachability. In this 615 case, none of the request routers is likely to advertise any 616 footprint information as none has any footprint restrictions. 617 When rr0 advertises capabilities to CDN-U, the aggregate of all 618 global reachability is global reachability. 620 o Some of the four CDN-P request routers have global reachability 621 and some do not. In this case, even though some request routers 622 do not have global reachability, the aggregate of some request 623 routers having global reachability and some not should still be 624 global reachability (for the given capability). When rr0 625 advertises capabilities to CDN-U, CDN-P may advertise capabilities 626 for which at least one request router has global reach as being 627 supported with global reachability. It is up to the authoritative 628 request router rr0 to properly select from the other request 629 routers for any given request, and not choose a request router 630 whose restricted footprint makes it unsuitable for delivering the 631 requested content. 633 A.3. Internal Capability Aggregation 635 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 636 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 637 Figure A3 differs from Figures A1 and A2 in that request router rr0 638 of CDN-P is not aggregating the capabilities advertisements of 639 multiple other downstream request routers, but rather it is managing 640 the disparate capabilities across resources within its own local CDN. 641 Though not every delivery node has the same protocol capabilities, 642 the aggregate delivery protocol capabilities advertised by CDN-A may 643 include all delivery protocols. Note, Figure A3 should not be 644 construed to imply anything about the coverage areas for each 645 delivery protocol. They may all support the same delivery footprint, 646 or they may have different delivery footprints. It is the 647 responsibility of the request router rr0 to properly assign protocol- 648 appropriate delivery nodes to individual content requests. If 649 certain protocols have limited reachability, CDN-P may advertise 650 footprint restrictions for each protocol. 652 It should be noted that though the delivery protocol capability was 653 selected for this example, the concept of internal capability 654 aggregation applies to all capabilities as discussed below. 656 ,---,---,---. 657 ,-' `-. 658 ( rr0.u.example.com ) 659 `-. CDN-U ,-' 660 `---'-+-'---' 661 | 662 ,---,---,---,--,-+-,--,---,---,---. 663 ( ) 664 ,-' +-------------------+ `-. 665 ( | rr0.p.example.com | ) 666 ,-' +---------+---------+ `-. 667 ( . ) 668 ,-' ....................... `-. 669 ( . . . ) 670 ) +-------------------+ . +-------------------+ ( 671 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 672 `. +-------------------+ . +-------------------+ ,' 673 ( . ) 674 `-. +-------------------+ ,-' 675 ( |http.p.example.com | ) 676 `-. +-------------------+ ,-' 677 ( CDN-A ) 678 `---'---'---'---'---'---'---'---'---' 680 Figure A3: Local CDN Capability Segregation 682 Another situation in which physical footprint may not matter in an 683 aggregated view has to do with feature support (e.g., new CDNI 684 metadata features or new redirection modes). Situations often arise 685 when phased roll-out of software upgrades, or staging network 686 segregation result in only certain portions of a CDN's resources 687 supporting the new feature set. The dCDN has a few options in this 688 case: 690 o Enforce atomic update: The dCDN does not advertise support for the 691 new capability until all resources have been upgraded to support 692 the new capability. 694 o Transparent segregation: The dCDN advertises support for the new 695 capability, and when requests are received that require the new 696 capability, the dCDN request router properly selects a resource 697 which supports that capability. 699 o Advertised segregation: The dCDN advertises support for the new 700 capability with a footprint restriction allowing the uCDN to make 701 delegation decisions based on the dCDN's limit support. 703 The level of aggregation employed by the dCDN is likely to vary as 704 business relationships dictate, however, the FCI should support all 705 possible modes of operation. 707 Author's Address 709 Kevin J. Ma 710 Azuki Systems, Inc. 711 43 Nagog Park 712 Acton, MA 01720 713 USA 715 Phone: +1 978-844-5100 716 Email: kevin.ma@azukisystems.com