idnits 2.17.1 draft-ma-cdni-capabilities-03.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 3918 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-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 (~~), 6 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 CDNI Footprint & Capabilities Advertisement Interface 8 draft-ma-cdni-capabilities-03 10 Abstract 12 Content Distribution Network Interconnection (CDNI) is predicated on 13 the ability of downstream CDNs (dCDNs) to handle end-user requests in 14 a functionally equivalent manner to the upstream CDN (uCDN). The 15 uCDN must be able to assess the ability of the dCDN to handle 16 individual requests. The CDNI Footprint & Capabilities Advertisement 17 interface (FCI) is provided for the advertisement of capabilities and 18 the footprints to which they apply by the dCDN to the uCDN. This 19 document describes an approach to implementing the CDNI FCI. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 05, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Acquisition Protocol . . . . . . . . . . . . . . . . . . 7 66 2.3. Redirection Mode . . . . . . . . . . . . . . . . . . . . 8 67 2.4. Logging Capabilities . . . . . . . . . . . . . . . . . . 10 68 2.5. Metadata Capabilities . . . . . . . . . . . . . . . . . . 10 69 3. Capability Advertisement . . . . . . . . . . . . . . . . . . 10 70 3.1. Capability Initialization . . . . . . . . . . . . . . . . 11 71 3.2. Capability Reset . . . . . . . . . . . . . . . . . . . . 11 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Appendix A. Capability Aggregation . . . . . . . . . . . . . . . 13 79 A.1. Downstream CDN Aggregation . . . . . . . . . . . . . . . 13 80 A.2. Internal Request Router Aggregation . . . . . . . . . . . 14 81 A.3. Internal Capability Aggregation . . . . . . . . . . . . . 16 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The need for footprint and capabilities advertisement in CDNI is 87 described in the CDNI requirements document 88 [I-D.ietf-cdni-requirements]. Requirements FCI-1 and FCI-2 describe 89 the need to allow dCDNs to communicate capabilities to the uCDN. 90 Requirement FCI-3 describes how a uCDN may aggregate the footprint 91 and capabilities information for all cascaded dCDNs and use the 92 aggregated information in advertisements to CDNs further upstream. 93 This concept of aggregation can apply to both organizationally 94 different dCDNs (e.g., other CDN providers, or different business 95 units within a larger organization) or logical entities within the 96 same CDN (e.g., using multiple request routers for scalability 97 reasons, to segregate surrogates based on specific protocol support, 98 or to segregate surrogates based on software version or feature 99 level, etc.). 101 Appendix A contains more detailed descriptions of different footprint 102 and capabilities management scenarios, but it is important to note 103 that it is the ability of the dCDN to service each request in a 104 functionally equivalent manner as the uCDN that is important, not the 105 physical layout of resources through which it services the request. 106 The aggregation of resource knowledge by the dCDN into a simple set 107 of capabilities and their affective footprints, that is then 108 advertised to the uCDN enables efficient decision making at each 109 delegation point in the CDN interconnection hierarchy. 111 It is assumed that an authoritative request router in each CDN will 112 be responsible for aggregating and advertising capabilities 113 information in a dCDN, and receiving and aggregating capabilities 114 information in the uCDN. The CDNI Footprint & Capabilities 115 Advertisement interface (FCI) along with the CDNI Request Routing 116 Redirection interface (RI) make up the CDNI Request Routing 117 Interface. As there is no other centralized CDNI controller, the 118 authoritative request router seems the most logical place for 119 capabilities aggregation to occur, as it is the request router that 120 needs such information to make delegation decisions. The protocol 121 defined herein may be implemented as part of an entity other than an 122 authoritative request router, but for the purposes of this 123 discussion, the authoritative request router is assumed to be the 124 centralized capabilities aggregation point. 126 Though there is an obvious need for the ability to exchange and 127 update footprint and capability information in real-time, it is 128 assumed that capabilities do not change very often. It is also 129 assumed that the capabilities are not by themselves useful for making 130 delegation decisions. Capability information is assumed to be input 131 into business logic. It is the business logic which provides the 132 algorithms for delegation decision making. The definition of 133 business logic occurs outside the scope of CDNI and outside the 134 timescale of footprint and capability advertisement. It may be the 135 case that the business logic anticipates and reacts to changes in 136 dCDN capabilities. However, it may also be the case that business 137 logic is tailored through offline processes as dCDN capabilities 138 change. The FCI is agnostic to the business processes employed by 139 any given uCDN. The footprints and capabilities that are advertised 140 over the FCI may be used by the uCDN at its discretion to implement 141 delegation rules. Setting proper defaults in the business logic 142 should prevent any unwanted delegation from occurring when dCDN 143 capabilities change, however, that is beyond the scope of this 144 discussion. 146 1.1. Terminology 148 This document uses the terminology defined in section 1.1 of the CDNI 149 Framework [I-D.ietf-cdni-framework] document. 151 2. Capabilities 153 As described in Requirement FCI-2, there is a basic set of 154 capabilities that must be supported by the FCI for the uCDN to be 155 able to determine if the dCDN is functionally able to handle a given 156 request. The CDNI Footprint and Capabilities Semantics 157 [I-D.ietf-cdni-footprint-capabilities-semantics] document lists 158 mandatory capabilities types: 160 o Delivery Protocol 162 o Acquisition Protocol 164 o Redirection Mode 166 o CDNI Logging Capabilities 168 o CDNI Metadata Capabilities 170 The following sections describe each of the capabilities in further 171 detail, however, all of the capabilities can be described using the 172 same general format. A capability object is specified as: 174 CapabilityObject: 175 Name: Identifier for the capability 176 Values: List of supported options for the capability 177 Footprint: Optional list of footprint objects 179 The list of valid capability options for a given capability will be 180 specific to the given capability type. Though the degenerate case 181 may exist where the range of option values is a single value, it is 182 anticipated that all capability types will have more than one 183 capability option value. For consistency in the model, all 184 capability types are implemented with lists of values. To optimize 185 actions on the entire range of capability option values for a given 186 capability type, the capability option value "ALL" is reserved and 187 MUST be supported by all capability types. For completeness, the 188 capability option value "NONE" is also reserved and MUST be supported 189 by all capability types. If a reserved value is specified, it MUST 190 be the only entry in the capability value list. 192 The footprint restriction list is optional. When included, the 193 footprint restriction list contains a list of generic footprint 194 objects. The footprint object is specified as: 196 FootprintObject: 197 Type: Identifier for the capability 198 Values: List of footprint entries 199 Mode: Optional footprint application directive 201 The footprint type specifies the format of the footprint value 202 entries. The footprint object type field contains the IANA registry 203 defined footprint type name. The CDNI Footprint and Capabilities 204 Semantics [I-D.ietf-cdni-footprint-capabilities-semantics] document 205 lists the mandatory footprint types as: ISO Country Code, AS number, 206 and IP-prefix. The CDNI Footprint and Capabilities Semantics 207 [I-D.ietf-cdni-footprint-capabilities-semantics] document defines the 208 footprint type names for the mandatory footprint types and describes 209 the process for defining additional optional footprint types. The 210 footprint value "GLOBAL" is reserved and MUST be supported by all 211 footprint types. If the reserved value "GLOBAL" is specified, it 212 MUST be the only entry in the footprint value list. 214 The optional footprint mode describes how the footprint should be 215 applied. The valid footprint mode values are: "replace", "include", 216 and "exclude". The footprint mode "replace" (represented by the 217 integer value 0) indicates that all previous footprint information 218 for the given footprint type (and for the capabilities to which the 219 current footprint object applies) MUST be replaced in its entirety 220 with the footprint information specified in the accompanying 221 footprint value list. The footprint mode "include" (represented by 222 the integer value 1) indicates that the any existing footprint 223 information for the given footprint type (and for the capabilities to 224 which the current footprint object applies) SHOULD be augmented with 225 the footprint information specified in the accompanying footprint 226 value list. The footprint mode "exclude" (represented by the integer 227 value 2) indicates that the any existing footprint information for 228 the given footprint type (and for the capabilities to which the 229 current footprint object applies) SHOULD be reduced by the footprint 230 information specified in the accompanying footprint value list. If 231 no footprint mode value is specified, the default mode SHALL be 232 understood to be "replace". 234 The footprint restriction list MUST NOT contain multiple footprint 235 objects of the same type. Footprint restriction information MAY be 236 specified using multiple different footprint types. If no footprint 237 restriction list is specified (or an empty list is specified), it 238 SHALL be understood that all footprint types MUST be reset to 239 "GLOBAL" coverage. 241 Note: Further optimization of the footprint object to provide quality 242 information for a given footprint is certainly possible, however, it 243 is not critical to the basic interconnection of CDNs. The ability to 244 transfer quality information in capabilities advertisements may be 245 desirable and is noted here for completeness, however, the specifics 246 of such mechanisms are outside the scope of this document. 248 Multiple capability objects of the same capability type are allowed 249 within a given FCI message as long as the capability option values do 250 not overlap, i.e., a given capability option value MUST NOT show up 251 in multiple capability objects within a single FCI message. If 252 multiple capability objects for a given capability type exist, those 253 capability objects SHOULD have different footprint restrictions; 254 capability objects of a given capability type with identical 255 footprint restrictions SHOULD be combined into a single capability 256 object. 258 2.1. Delivery Protocol 260 The delivery protocol refers to the protocol over which an end user 261 (EU) has requested content. If a dCDN does not support the protocol 262 requested by the client, then the dCDN is not a viable candidate for 263 delegation. 265 Though the delivery protocol is specified in the URI scheme (as 266 defined in RFC3986 [RFC3986]) of the client request URL, protocol 267 feature subsets or augmented protocol feature sets MAY be defined and 268 SHOULD correspond with the protocols supported by the ProtocolACL 269 defined in the CDNI Metadata Interface [I-D.ietf-cdni-metadata] 270 document. 272 The delivery protocol capability object MUST support a list of 273 protocols for a given footprint. The delivery protocol capability 274 SHOULD support optional footprint restriction information. The 275 following example shows two lists of protocols with different 276 footprints. 278 { 279 "capabilities": [ 280 { "name": "delivery_protocol", 281 "values": [ 282 "HTTP", 283 "RTSP", 284 "MMS" 285 ] 286 }, 287 { "name": "delivery_protocol", 288 "values": [ 289 "RTMP", 290 "HTTPS" 291 ], 292 "footprint": [ 293 { "type": "IPv4", 294 "values": [ 295 "10.1.0.0/16", 296 "10.10.10.0/24" 297 ] 298 } 299 ] 300 } 301 ] 302 } 304 In the above example, the three protocols HTTP, RTSP, and MMS are 305 supported globally, while the protocols RTMP and HTTPS are only 306 supported in a restricted footprint (in this case, specified by IP- 307 prefix). 309 A given protocol MUST NOT appear in multiple capability object value 310 lists, within a given FCI message. 312 [Ed. need to add reference to registry where the protocol values are 313 defined, once they are finalized in the semantics/metadata draft.] 315 2.2. Acquisition Protocol 317 The acquisition protocol refers to the protocol over which the dCDN 318 may acquire content from the uCDN. If a dCDN does not support any of 319 the protocols offered by the uCDN, then the dCDN is not a viable 320 candidate for delegation. 322 Though the acquisition protocol is disseminated to the dCDN in the 323 URI scheme (as defined in RFC3986 [RFC3986]) of the URL provided by 324 the uCDN via the CDNI Metadata Interface [I-D.ietf-cdni-metadata], 325 protocol feature subsets or augmented protocol feature sets MAY be 326 defined and SHOULD correspond with the protocols supported by the 327 ProtocolACL defined in the CDNI Metadata Interface 328 [I-D.ietf-cdni-metadata] document. 330 The acquisition protocol capability object MUST support a list of 331 protocols for a given footprint. The acquisition protocol capability 332 SHOULD support optional footprint restriction information. The 333 following example shows two lists of protocols with different 334 footprints. 336 { 337 "capabilities": [ 338 { "name": "acquisition_protocol", 339 "values": [ 340 "HTTP", 341 "FTP" 342 ] 343 }, 344 { "name": "acquisition_protocol", 345 "values": [ 346 "SFTP", 347 "HTTPS" 348 ], 349 "footprint": [ 350 { "type": "ASN", 351 "values": [ 352 "0", 353 "65535" 354 ], 355 "mode": 2 356 } 357 ] 358 } 359 ] 360 } 362 In the above example, the two protocols HTTP and FTP are supported 363 globally, while the protocols SFTP and HTTPS are updated to only be 364 supported in a reduced restricted footprint (in this case, specified 365 by ASN). 367 A given protocol MUST NOT appear in multiple capability object value 368 lists, within a given FCI message. 370 [Ed. need to add reference to registry where the protocol values are 371 defined, once they are finalized in the semantics/metadata draft.] 373 2.3. Redirection Mode 375 The redirection mode refers to the method(s) employed by request 376 routers to perform request redirection. The CDNI framework 378 [I-D.ietf-cdni-framework] document describes four possible request 379 routing modes: 381 o DNS iterative (DNS-I) 383 o DNS recursive (DNS-R) 385 o HTTP iterative (HTTP-I) 387 o HTTP recursive (HTTP-R) 389 If a dCDN supports only a specific mode or subset of modes that does 390 not overlap with the modes supported by the uCDN, then the dCDN is 391 not a viable candidate for delegation. 393 The redirection mode capability object MUST support a list of 394 redirection modes for a given footprint. The redirection mode 395 capability SHOULD support optional footprint restriction information. 396 The following XML-encoded example shows two lists of modes with 397 different footprints. 399 { 400 "capabilities": [ 401 { "name": "redirection_mode", 402 "values": [ 403 "DNS-I", 404 "HTTP-I" 405 ] 406 }, 407 { "name": "redirection_mode", 408 "values": [ 409 "DNS-R", 410 "HTTP-R" 411 ], 412 "footprint": [ 413 { "type": "ASN", 414 "values": [ 415 "9" 416 ], 417 "mode": 0 418 }, 419 { "type": "IPv6", 420 "values": [ 421 "8765:4321::/36" 422 ] 423 } 424 ] 425 } 427 ] 428 } 430 In the above example, iterative redirection is supported globally, 431 while recursive redirection is only supported in a restricted 432 footprint (in this case, specified by both ASN and IP-prefix). 434 A given mode MUST NOT appear in multiple capability object value 435 lists, within a given FCI message. 437 [Ed. need to add reference to registry where the mode values are 438 defined, once they are finalized in the semantics/metadata draft.] 440 2.4. Logging Capabilities 442 The CDNI Logging interface [I-D.ietf-cdni-logging] document describes 443 optional logging fields and functionality which may be optional for a 444 dCDN to implement. If a dCDN does not support certain logging 445 parameters which may affect billing agreements or legal requirements 446 of the uCDN, then the dCDN is not a viable candidate for delegation. 448 [Ed. need to update this section once the list of logging 449 capabilities is finalized in the semantics/metadata draft.] 451 2.5. Metadata Capabilities 453 The CDNI Metadata interface [I-D.ietf-cdni-metadata] document 454 describes generic metadata types which may be optional for a dCDN to 455 implement, but which, if present, are mandatory-to-enforce. If a 456 dCDN does not support certain metadata types which are designated 457 mandatory-to-enforce and may affect the correctness or security of 458 the content being delivered, then the dCDN is not a viable candidate 459 for delegation. 461 [Ed. need to update this section once the list of metadata 462 capabilities is finalized in the semantics/metadata draft.] 464 3. Capability Advertisement 466 The FCI relies an HTTP-based protocol using the GET and POST methods. 467 The uCDN request router may at any time query the dCDN request router 468 for the fully capability set of the dCDN. In addition, he dCDN 469 request router SHOULD asynchronously issue HTTP POSTs of FCI messages 470 to the uCDN request router (see Appendix A for detailed descriptions 471 of authoritative request router capabilities aggregation scenarios) 472 whenever changes in the its already advertised capabilities occur. 473 It is assumed that the dCDN request router has been configured with 474 the uCDN request router address, and the uCDN request router has been 475 configured with the dCDN request router address, either through the 476 CDNI Control interface (CI) bootstrapping function, or through some 477 other out-of-band configuration. 479 3.1. Capability Initialization 481 In lieu of any out-of-band pre-configured capability information, 482 when the FCI is first brought up between a uCDN and dCDN, the uCDN 483 SHOULD assume that the dCDN has no CDNI capabilities. If an out-of- 484 band capability baseline has been exchanged, the uCDN MAY use that 485 information to initialize its capabilities database. In either case, 486 the uCDN SHOULD verify the initial state of the dCDN (as a temporary 487 outage may be affecting availability in the dCDN). 489 The dCDN MUST support sending its entire set of capabilities to the 490 uCDN using the footprint mode "replace", in order to (re)initialize 491 the uCDN capabilities database. In response to an FCI GET request 492 from the uCDN, the dCDN MUST send its entire set of capabilities to 493 the uCDN using the footprint mode "replace". 495 [Ed.: The alternative to using a pull from the uCDN is to use the 496 triggers interface for a triggered push, however, this would not be 497 triggering a CDN function, it would be triggering an FCI function, so 498 given that there is no asynchronous action required by the dCDN, it 499 seems that reducing inter-dependency on other CDNI interfaces makes 500 the most sense in this case.] 502 3.2. Capability Reset 504 When using the footprint modes "include" and/or "exclude" for partial 505 update of the footprint for a given capability, there is a dependency 506 and expectation as to what the uCDN believes the current footprint of 507 that capability to be. If any in the sequence of footprint update 508 messages are lost, there could be a loss of coherency between the 509 uCDN and the dCDN. To help prevent this situation, each FCI POST 510 MUST include a sequence number if it intends to use the footprint 511 modes "include" and/or "exclude". The sequence number SHALL be 512 represented as a 32 bit unsigned integer that wraps. The sequence 513 number MUST appear in the "CDNI-FCI-seq" HTTP header and be 514 incremented for every FCI message sent by the dCDN to a given uCDN. 516 If the uCDN ever receives an out of sequence FCI message from a given 517 dCDN, the uCDN SHOULD reinitialize its capabilities database using an 518 FCI GET request. 520 4. IANA Considerations 521 This memo includes no request to IANA. 523 5. Security Considerations 525 There are a number of security concerns associated with the FCI. The 526 FCI essentially provides configuration information which the uCDN 527 uses to make request routing decisions. Injection of fake capability 528 advertisement messages or the interception and discard of real 529 capability advertisement messages may be used for denial of service 530 (e.g., by falsely advertising or deleting capabilities or preventing 531 capability advertisements from reaching the uCDN). dCDN capability 532 advertisements MUST be authenticated by the uCDN to prevent 533 unauthorized FCI message injection. uCDN FCI servers MUST be 534 authenticated by the dCDN to prevent unauthorized interception of FCI 535 messages. TLS with client authentication SHOULD be used for all FCI 536 implementations. Deployments in controlled environments where 537 physical security and IP address white-listing is employed MAY choose 538 not to use TLS. 540 6. Acknowledgements 542 The authors would like to thank Ray van Brandenburg, Gilles Bertrand, 543 and Scott Wainner for their timely reviews and invaluable comments. 545 7. References 547 7.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 553 Resource Identifier (URI): Generic Syntax", STD 66, RFC 554 3986, January 2005. 556 7.2. Informative References 558 [I-D.ietf-cdni-footprint-capabilities-semantics] 559 Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 560 R., and K. Ma, "CDNI Request Routing: Footprint and 561 Capabilities Semantics draft-ietf-cdni-footprint- 562 capabilities-semantics-00", July 2013. 564 [I-D.ietf-cdni-framework] 565 Peterson, L., Ed. and B. Davie, Ed., "Framework for CDN 566 Interconnection draft-ietf-cdni-framework-03", February 567 2013. 569 [I-D.ietf-cdni-logging] 570 Le Faucheur, F., Bertrand, G., Oprescu, I., and R. 571 Peterkofsky, "CDNI Logging Interface draft-ietf-cdni- 572 logging-05", July 2013. 574 [I-D.ietf-cdni-metadata] 575 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 576 Leung, K., and K. Ma, "CDN Interconnect Metadata draft- 577 ietf-cdni-metadata-02", July 2013. 579 [I-D.ietf-cdni-requirements] 580 Leung, K. and Y. Lee, "Content Distribution Network 581 Interconnection (CDNI) Requirements draft-ietf-cdni- 582 requirements-09", July 2013. 584 Appendix A. Capability Aggregation 586 The following sections show examples of three aggregation scenarios. 587 In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate 588 CDN which must perform capabilities aggregation. 590 A.1. Downstream CDN Aggregation 592 Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P, 593 and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated. 594 Given the setup shown in Figure A1, we can construct a number of use 595 cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B, 596 and C). Note: In all cases, the reachability of the uCDN (i.e., 597 CDN-U) is a don't care as it is assumed that the uCDN knows its own 598 coverage area and is likely to favor itself in most situations, and 599 if it has decided that it needs to delegate to a dCDN, then the only 600 relevant question is if the dCDN can handle the request. 602 ,---,---,---. 603 ,-' `-. 604 ( rr0.u.example.com ) 605 `-. CDN-U ,-' 606 `---'-+-'- --' 607 | 608 ,---,-+-,---. 609 ,-' `-. 610 ( rr0.p.example.com ) 611 `-. CDN-P ,-' 612 `---'-+-'---' 613 | 614 +---------------------+---------------------+ 615 / | \ 616 ,---,-+-,---. ,---,-+-,---. ,---,-+-,---. 618 ,-' `-. ,-' `-. ,-' `-. 619 ( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com ) 620 `-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-' 621 `---'---'---' `---'---'---' `---'---'---' 623 Figure A1: CDNI dCDN Request Router Aggregation 625 o None of the four dCDNs (CDNs P, A, B, and C) have global 626 reachability. In this case, each CDN is likely to advertise 627 footprint information with its capabilities, specifying its 628 reachability. When CDN-P advertises capabilities to CDN-U, it may 629 advertise the aggregate footprint of itself and CDNs A, B, and C. 630 Note: CDN-P MAY exclude any dCDN, and consequently its footprint, 631 per its own internal aggregation decision criteria. 633 o All four dCDNs (CDNs P, A, B, and C) have global reachability. In 634 this case, none of the CDNs is likely to advertise any footprint 635 information as none have any footprint restrictions. When CDN-P 636 advertises capabilities to CDN-U, the aggregate of all global 637 reachability is global reachability. 639 o Some of the four dCDNs (CDNs P, A, B, and C) have global 640 reachability and some do not. In this case, even though some 641 dCDNs do not have global reachability, the aggregate of some dCDNs 642 having global reachability and some not should still be global 643 reachability (for the given capability). When CDN-P advertises 644 capabilities to CDN-U, CDN-P may advertise capabilities for which 645 at least one dCDN has global reach as being supported with global 646 reachability. It is up to the CDN-P request router to properly 647 select a dCDN to process individual client requests and not choose 648 a dCDN whose restricted footprint makes it unsuitable for 649 delivering the requested content. 651 A.2. Internal Request Router Aggregation 653 Figure A2 shows CDN-U and CDN-P where CDN-P internally has four 654 request routers: the authoritative request router rr0, and three 655 other request routers rr1, rr2, and rr3. The use of multiple request 656 routers may be used to distribute request routing load across 657 resources, possibly in different geographic regions covered by CDN-P. 658 Similar to Figure A1, the setup shown in Figure A2 requires the 659 authoritative request router rr0 in CDN-P to aggregate capabilities 660 information from downstream request routers rr1, rr2, and rr3. The 661 primary difference between the scenario is that the request routers 662 in Figure A2 are logically within the same CDN-P organization. The 663 same reachability scenarios apply to Figure A2 as with Figure A1. 665 ,---,---,---. 666 ,-' `-. 667 ( rr0.u.example.com ) 668 `-. CDN-U ,-' 669 `---'-+-'---' 670 | 671 ,---,---,---,--,-+-,--,---,---,---. 672 ( ) 673 ,-' +-------------------+ `-. 674 ( | rr0.p.example.com | ) 675 ,-' +---------+---------+ `-. 676 ( | ) 677 ,-' +----------+----------+ `-. 678 ( / | \ ) 679 ) +---------+---------+ | +---------+---------+ ( 680 ( | rr1.p.example.com | | | rr3.p.example.com | ) 681 `. +-------------------+ | +-------------------+ ,' 682 ( | ) 683 `-. +---------+---------+ ,-' 684 ( | rr2.p.example.com | ) 685 `-. +-------------------+ ,-' 686 ( CDN-P ) 687 `---'---'---'---'---'---'---'---'---' 689 Figure A2: Local CDN Request Router Aggregation 691 o None of the four CDN-P request routers have global reachability. 692 In this case, each request router is likely to advertise footprint 693 information with its capabilities, specifying its reachability. 694 When rr0 advertises capabilities to CDN-U, it may advertise the 695 aggregate footprint of itself and rr1, rr2, and rr3. 697 o All four CDN-P request routers have global reachability. In this 698 case, none of the request routers is likely to advertise any 699 footprint information as none has any footprint restrictions. 700 When rr0 advertises capabilities to CDN-U, the aggregate of all 701 global reachability is global reachability. 703 o Some of the four CDN-P request routers have global reachability 704 and some do not. In this case, even though some request routers 705 do not have global reachability, the aggregate of some request 706 routers having global reachability and some not should still be 707 global reachability (for the given capability). When rr0 708 advertises capabilities to CDN-U, CDN-P may advertise capabilities 709 for which at least one request router has global reach as being 710 supported with global reachability. It is up to the authoritative 711 request router rr0 to properly select from the other request 712 routers for any given request, and not choose a request router 713 whose restricted footprint makes it unsuitable for delivering the 714 requested content. 716 A.3. Internal Capability Aggregation 718 Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P 719 is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP). 720 Figure A3 differs from Figures A1 and A2 in that request router rr0 721 of CDN-P is not aggregating the capabilities advertisements of 722 multiple other downstream request routers, but rather it is managing 723 the disparate capabilities across resources within its own local CDN. 724 Though not every delivery node has the same protocol capabilities, 725 the aggregate delivery protocol capabilities advertised by CDN-A may 726 include all delivery protocols. Note, Figure A3 should not be 727 construed to imply anything about the coverage areas for each 728 delivery protocol. They may all support the same delivery footprint, 729 or they may have different delivery footprints. It is the 730 responsibility of the request router rr0 to properly assign protocol- 731 appropriate delivery nodes to individual content requests. If 732 certain protocols have limited reachability, CDN-P may advertise 733 footprint restrictions for each protocol. 735 It should be noted that though the delivery protocol capability was 736 selected for this example, the concept of internal capability 737 aggregation applies to all capabilities as discussed below. 739 ,---,---,---. 740 ,-' `-. 741 ( rr0.u.example.com ) 742 `-. CDN-U ,-' 743 `---'-+-'---' 744 | 745 ,---,---,---,--,-+-,--,---,---,---. 746 ( ) 747 ,-' +-------------------+ `-. 748 ( | rr0.p.example.com | ) 749 ,-' +---------+---------+ `-. 750 ( . ) 751 ,-' ....................... `-. 752 ( . . . ) 753 ) +-------------------+ . +-------------------+ ( 754 ( |rtsp.p.example.com | . |rtmp.p.example.com | ) 755 `. +-------------------+ . +-------------------+ ,' 756 ( . ) 757 `-. +-------------------+ ,-' 758 ( |http.p.example.com | ) 759 `-. +-------------------+ ,-' 760 ( CDN-A ) 761 `---'---'---'---'---'---'---'---'---' 763 Figure A3: Local CDN Capability Segregation 765 Another situation in which physical footprint may not matter in an 766 aggregated view has to do with feature support (e.g., new CDNI 767 metadata features or new redirection modes). Situations often arise 768 when phased roll-out of software upgrades, or staging network 769 segregation result in only certain portions of a CDN's resources 770 supporting the new feature set. The dCDN has a few options in this 771 case: 773 o Enforce atomic update: The dCDN does not advertise support for the 774 new capability until all resources have been upgraded to support 775 the new capability. 777 o Transparent segregation: The dCDN advertises support for the new 778 capability, and when requests are received that require the new 779 capability, the dCDN request router properly selects a resource 780 which supports that capability. 782 o Advertised segregation: The dCDN advertises support for the new 783 capability with a footprint restriction allowing the uCDN to make 784 delegation decisions based on the dCDN's limit support. 786 The level of aggregation employed by the dCDN is likely to vary as 787 business relationships dictate, however, the FCI should support all 788 possible modes of operation. 790 Author's Address 792 Kevin J. Ma 793 Azuki Systems, Inc. 794 43 Nagog Park 795 Acton, MA 01720 796 USA 798 Phone: +1 978-844-5100 799 Email: kevin.ma@azukisystems.com