idnits 2.17.1 draft-spp-cdni-rr-foot-cap-semantics-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HIGH' is mentioned on line 183, but not defined == Missing Reference: 'MED' is mentioned on line 222, but not defined == Missing Reference: 'LOW' is mentioned on line 215, but not defined == Unused Reference: 'RFC2119' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-cdni-strawman' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'I-D.xiaoyan-cdni-requestrouting' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-03 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-09 == Outdated reference: A later version (-02) exists of draft-previdi-cdni-footprint-advertisement-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI J. Seedorf 3 Internet-Draft NEC 4 Intended status: Informational J. Peterson 5 Expires: January 17, 2013 Neustar 6 S. Previdi 7 Cisco 8 July 16, 2012 10 CDNI Request Routing: Footprint and Capabilities Semantics 11 draft-spp-cdni-rr-foot-cap-semantics-01 13 Abstract 15 This document tries to capture the semantics of the "Footprint and 16 Capabilities Advertisement" part of the CDNI Request Routing 17 interface, i.e. the desired meaning and what "Footprint and 18 Capabilities Advertisement" is expected to offer within CDNI. The 19 discussion in this document has the goal to facilitate the choosing 20 of one or more suitable protocols for "Footprint and Capabilities 21 Advertisement" within CDNI Request Routing. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 17, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Apparent Understanding of CDNI Footprint and Capabilities 59 Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Description of footprint and capabilities 61 advertisement in existing CDNI documents . . . . . . . . . 4 62 2.2. Summary of understanding of footprint and capabilities 63 advertisement in existing CDNI documents . . . . . . . . . 6 64 3. Design Decisions for Footprint and Capabilities . . . . . . . 7 65 3.1. Advertising Limited Coverage . . . . . . . . . . . . . . . 7 66 3.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 8 67 3.3. Advertisement versus Queries . . . . . . . . . . . . . . . 9 68 3.4. Avoiding or Handling 'cheating' Downstream CDNs . . . . . 9 69 3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 10 70 4. Towards Semantics for Footprint Advertisement . . . . . . . . 11 71 5. Towards Semantics for Capabilities Advertisement . . . . . . . 12 72 6. Open Issues and Questions . . . . . . . . . . . . . . . . . . 14 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 The CDNI working group is working on a set of protocols to enable the 84 interconnection of multiple CDNs to a CDN federation. This CDN- 85 federation should serve multiple purposes, as discussed in 86 [I-D.ietf-cdni-use-cases], for instance, to extend the reach of a 87 given CDN to areas in the network which are not covered by this 88 particular CDN. 90 The goal of this document is to achieve a clear understanding in the 91 CDNI WG about the semantics associated with the CDNI request routing 92 interface, in particular regarding the "footprint and capabilities 93 advertisement" of a downstream CDN. To narrow down undecided aspects 94 of these semantics, this document first tries to capture the common 95 understanding of what the "footprint and capabilities advertisement" 96 should offer and accomplish, i.e. what seems to be agreed. Then, the 97 document will discuss open questions. It is the goal of this 98 document to capture the outcome of discussions and answers to open 99 questions in future versions of this draft. In particular, this 100 document summarizes the progress of the recently formed CDNI design 101 team on "footprint and capabilities advertisement". 103 General assumptions in this document: 105 o The CDNs participating in the CDN federation have already 106 performed a boot strap process, i.e., they have connected to each 107 other, either directly or indirectly, and can exchange information 108 amongst each other. 110 o The uCDN has received footprint and/or capability advertisements 111 from a set of dCDNs. Footprint advertisement and capability 112 advertisement need not use the same underlying protocol. 114 o The upstream CDN (uCDN) receives the initial request-routing 115 request from the endpoint requesting the resource. 117 This document is organized as follows. We first recap the 118 descriptions regarding "footprint and capabilities advertisement" in 119 existing documents and try to distill the apparent common 120 understanding of the terms "footprint" and "capabilities" in the CDNI 121 request routing context. We then separately discuss the semantics of 122 the footprint advertisement mechanism, and the capability 123 advertisement mechanism. Finally, we list open issues and questions 124 to be discussed in the CDNI WG. 126 Comments and discussions about this memo should be directed to the 127 CDNI WG: cdni@ietf.org. 129 2. Apparent Understanding of CDNI Footprint and Capabilities 130 Advertisement 132 In the following, we will summarize the descriptions of the CDNI 133 "footprint and capabilities advertisement" as part of the "request 134 routing" interface in existing documents. We will then carve out the 135 apparent common understanding of what this interface is intended to 136 offer and accomplish. 138 2.1. Description of footprint and capabilities advertisement in 139 existing CDNI documents 141 The CDNI problem statement draft [I-D.ietf-cdni-problem-statement] 142 describes footprint and capabilities advertisement as: "enabling an 143 upstream CDN to determine if a downstream CDN is able (and willing) 144 to accept the delegated content request". In addition, the draft 145 says "the CDNI Request Routing interface is also expected to enable a 146 downstream CDN to provide to the upstream CDN (static or dynamic) 147 information (e.g. resources, footprint, load) to facilitate selection 148 of the downstream CDN by the upstream CDN request routing system when 149 processing subsequent content requests from User Agents". It thus 150 considers "resources" and "load" as capabilities to be advertised by 151 the downstream CDN. 153 The CDNI use cases draft [I-D.ietf-cdni-use-cases] describes 154 capabilities as "... supported range of devices and User Agents or 155 the supported range of delivery technologies". Examples for such 156 capabilities given are specific delivery protocols, technology 157 migration, and meeting a certain QoS. 159 The CDNI requirements draft [I-D.ietf-cdni-requirements] lists 160 several requirements relevant for the "footprint and capabilities 161 advertisement" part of the CDNI request routing interface. In 162 summary, the following requirements for the CDNI Request Routing 163 Interface and general requirements are relevant for the understanding 164 of the semantics of the "footprint and capabilities advertisement": 166 o GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN 167 information to be exposed to other CDNs for effective and 168 efficient delivery of the content. Examples of intra-CDN 169 information include surrogate topology, surrogate status, cached 170 content, etc." 172 o GEN-9 [MED], "The CDNI solution should support cascaded CDN 173 redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an 174 arbitrary number of levels beyond the first level." 176 o GEN-10 [MED], "The CDNI solution should support an arbitrary 177 topology of interconnected CDNs (i.e. the CDN topology cannot be 178 restricted to a tree, a loop-free topology, etc.)." 180 o GEN-11 [HIGH], "The CDNI solution shall prevent looping of any 181 CDNI information exchange." 183 o REQ-1 [HIGH], allowing the downstream CDN "to communicate to the 184 Upstream CDN coarse information about the Downstream CDN ability 185 and/or willingness to handle requests from the Upstream CDN. For 186 example, this could potentially include a binary signal 187 ("Downstream CDN ready/not-ready to take additional requests from 188 Upstream CDN") to be used in case of excessive load or failure 189 condition in the Downstream CDN." 191 o REQ-2 [MED], allowing the downstream CDN to communicate 192 capabilities such as supported content types and delivery 193 protocols, a set of metrics/attributes (e.g. Streaming bandwidth, 194 storage resources, distribution and delivery priority), a set of 195 affinities (e.g. Preferences, indication of distribution/delivery 196 fees), information to facilitate request redirection, as well as 197 footprint information (e.g. "layer-3 coverage"). 199 o REQ-3 [MED], "In the case of cascaded redirection, the CDNI 200 Request-Routing interface shall allow the Downstream CDN to also 201 include in the information communicated to the Upstream CDN, 202 information on the capabilities, resources and affinities of CDNs 203 to which the Downstream CDN may (in turn) redirect requests 204 received by the Upstream CDN. In that case, the CDNI Request- 205 Routing interface shall prevent looping of such information 206 exchange." 208 o REQ-4 [LOW], allowing the downstream CDN to communicate "aggregate 209 information on CDNI administrative limits and policy" (e.g. the 210 maximum number of requests redirected by the Upstream CDN to be 211 served simultaneously by the Downstream CDN or maximum aggregate 212 volume of content (e.g. in Terabytes) to be delivered by the 213 Downstream CDN over a time period). 215 o REQ-11 [LOW], "The CDNI Request-Routing protocol may support a 216 mechanism allowing an Upstream CDN to avoid redirecting a request 217 to a Downstream CDN if that is likely to result in the total 218 redirection time exceeding some limit." 220 Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of 221 what "footprint" information might convey in the CDNI requirements 222 draft [I-D.ietf-cdni-requirements]. Also, note that REQ-3 [MED] 223 addresses cascaded (transitive) downstream CDNs. In such a case, a 224 downstream CDN needs to include (in its advertisement information 225 that it conveys to an upstream CDN) also information the footprint 226 and capabilities of any further transitive downstream CDN. Such 227 information may be included implicitly (i.e. the cascaded dCDN is 228 oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of the 229 fact that there is a cascaded dCDN is visible to the uCDN). In any 230 case, a logic is needed to process incoming footprint information 231 from a cascaded dCDN and decide if/how it is to be re-advertised/ 232 aggregated when advertising footprint to an upstream CDN. 234 The CDNI framework draft [I-D.davie-cdni-framework] describes a 235 "footprint" as in [I-D.previdi-cdni-footprint-advertisement], 236 consisting of two parts: 1) "a class of end user requests 237 (represented, for example, by a set of IP prefixes, or a geographic 238 region) that the dCDN is willing and able to serve directly, without 239 use of another dCDN", and 2) "the connectivity of the dCDN to other 240 CDNs that may be able to serve content to users on behalf of dCDN". 241 The term "connectivity" has recently been replaced with 242 "reachability" in [I-D.previdi-cdni-footprint-advertisement]. 243 Further, examples for capabilities are "the ability to handle certain 244 types of content (e.g. specific streaming formats) or quality of 245 service (QoS)." 247 2.2. Summary of understanding of footprint and capabilities 248 advertisement in existing CDNI documents 250 In summary, neither the term "footprint" nor "capabilities" are 251 clearly defined. Also, a very broad range of potential capabilities 252 is listed in the existing documents. 254 3. Design Decisions for Footprint and Capabilities 256 A large part of the difficulty lies in understanding what we mean 257 when try to define footprint to terms of "coverage" or 258 "reachability." While the operators of CDNs pick strategic locations 259 to situate caches, a cache with a public IPv4 address is reachable by 260 any endpoint on the Internet unless some policy enforcement precludes 261 the use of the cache. 263 Some CDNs aspire to cover the entire world, henceforth global CDNs; 264 which we will henceforth call global CDNs. The footprint advertised 265 by such a CDN in the CDNi environment would, from a coverage or 266 reachability perspective, presumably cover all prefixes. More 267 interesting for CDNi use cases, however, are CDNs that claim a more 268 limited coverage, but seek to federate with other CDNs in order to 269 create a single CDN fabric which shares resources fairly. 271 The key to understanding the semantics of footprint and capability 272 advertisement lies in understand why a dCDN would advertise a limited 273 coverage area, and how a uCDN would use such advertisements to decide 274 among one of several dCDNs. 276 3.1. Advertising Limited Coverage 278 The basic use case that would motivate a dCDN to advertise a limited 279 coverage is that the CDN was built to cover only a particular portion 280 of the Internet. For example, an ISP could purpose-build a CDN to 281 serve only their own customers by situating caches in close 282 topological proximity to high concentrations of their subscribers. 283 The ISP knows the prefixes it has allocated to end users and thus can 284 easily construct a list of prefixes that its caches were positioned 285 to serve. 287 When such a purpose-built CDN joined a federation, however, and 288 advertises its footprint to a uCDN, the original intended coverage of 289 the CDN might not represent its actual value to the federation of 290 CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, 291 which they federate through CDNi. A given user E, who is customer of 292 ISP-B, might happen to be topologically closest to a cache fielded by 293 ISP-A, if E happens to live in a region where ISP-B has few customers 294 and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If 295 ISP-B's CDN has a failure condition, should the uCDN understand that 296 ISP-A's caches are potentially available back-ups - and if so, how 297 does ISP-A advertise itself as a "standby" for E? What about the 298 case where CDNs advertising to the same uCDN express overlapping 299 coverage (for example, a federation mixing global and limited CDNs)? 301 The answers to these questions greatly depend on how much information 302 we want the uCDN to use to make a selection of a dCDN. If a uCDN has 303 three dCDNs to choose from that "cover" the IP address of user E, 304 obviously the uCDN might be interested to know how optimal the 305 coverage is from each of the dCDNs - coverage need not be binary, 306 either provided or not provided. dCDNs could advertise a coverage 307 "score," for example, and provided that they all reported scores 308 fairly on the same scale, uCDNs could use that to make their 309 topological optimality decision. Alternatively, dCDNs could for 310 their footprint advertise the IP addresses of their caches rather 311 than prefix "coverage," and let the uCDN decide for itself (based on 312 its own topological intelligence) which dCDN has better resources to 313 serve a given user. 315 3.2. Capabilities and Dynamic Data 317 In cases where the apparent footprint of dCDNs overlaps, uCDNs might 318 also want to rely on a host of other factors to evaluate the 319 respective merits of dCDNs. These include facts related to the 320 caches themselves, to the network where the cache is deployed, to the 321 nature of the resource sought and to the administrative policies of 322 the respective networks. 324 In the absence of network-layer impediments to reaching caches, the 325 choice to limit coverage is necessarily an administrative policy. 326 Much policy must be agreed upon before CDNs can merge into 327 federations, including questions of membership, compensation, volumes 328 and so on. A uCDN certainly will factor these sorts of 329 considerations into its decision to select a dCDN, but there is 330 probably little need for dCDNs to actually advertise them through an 331 interface - they will be settled out of band as a precondition for 332 federating. 334 Other facts about the dCDN would be expressed through the interface 335 to the uCDN. Some capabilities of a dCDN are static, and some are 336 highly dynamic. Expressing the total storage built into its caches, 337 for example, changes relatively rarely, whereas the amount storage in 338 use at any given moment is highly volatile. Network bandwidth 339 similarly could be expressed as either total bandwidth available to a 340 cache, or based on the current state of the network. A cache may at 341 one moment lack a particular resource in storage, but have it the 342 next. 344 The semantics of the capabilities interface will depend on how much 345 of the dCDN state needs to be pushed to the uCDN in order for it to 346 make a decision. 348 3.3. Advertisement versus Queries 350 In a federated CDN environment, each dCDN shares some of its state 351 with the uCDN, which the uCDN uses to build a unified picture of all 352 of the dCDNs available to it. In architectures that share detailed 353 capability information, the uCDN could basically perform the entire 354 request-routing intelligence down to selecting a particular cache 355 before sending the request to the dCDN (note that within the current 356 CDNI WG scope, such direct selection of specific caches by the uCDN 357 is out of scope). However, when the uCDN must deal with many 358 potential dCDNs, this approach does not scale. Especially as CDNs 359 scale up from dozens or hundreds of caches to thousands or tens of 360 thousands, the volume of updates to footprint and capability may 361 become onerous. 363 Were the volume of updates to exceed the volumes of requests to the 364 uCDN, it might make more sense for the uCDN to query dCDNs upon 365 receiving requests, instead of receiving advertisements and tracking 366 the state of dCDNs itself. The advantage of querying dCDNs would be 367 that much of the dynamic data that dCDNs cannot share with the uCDN 368 would now be factored into the uCDN's decision. dCDNs need not 369 replicate any state to the uCDN - uCDNs could effectively operate in 370 a stateless mode. 372 The semantics of both footprint and capability advertisement depend 373 on the service model here: are there cases where a synchronous query/ 374 response model would work better for the uCDN decision than a state 375 replication model? 377 3.4. Avoiding or Handling 'cheating' Downstream CDNs 379 In a situation where more than one dCDN is willing to serve a given 380 end user request, it might be attractive for a dCDN to "cheat" in the 381 sense that the dCDN provides inaccurate information to the uDCDN in 382 order to convince the uCDN to select it opposed to "competing" other 383 dCDNs. It is therefore desirable to take away the incentive for 384 dCDNs to cheat (in information advertised) as much as possible. One 385 option here is to make the information the dCDN advertises somehow 386 verifiable for the uCDN. One the other hand, a cheating dCDN might 387 be avoided or handled by the fact that there will be strong 388 contractual agreements between a uCDN and a dCDN, so that a dCDN 389 would risk severe penalties or legal consequences when caught 390 cheating. 392 Overall, it seems that information a dCDN advertises should (in the 393 long run) be somehow verifiable by the uCDN. However, it is probably 394 an overly strict requirement to demand that such verification must be 395 possible "immediately", i.e. during the request routing process 396 itself. If the uCDN can detect a cheating dCDN at a later stage, it 397 should suffice for the dCDN to "de-incentivize" cheating because it 398 would negatively affect long-term business relationsships with uCDNs. 400 3.5. Focus on Main Use Cases may Simplify Things 402 To narrow down semantics for "footprint" and "capabilities" in the 403 CDNI context, it can be useful to initially focus on key use cases to 404 be addressed by the CDNI WG that are to be envisioned the main 405 deployments in the foreseeable future. In this regard, a main 406 realistic use case is the existence of ISP-owned CDNs, which 407 essentially cover a certain operator's network. At the same time, 408 however, the possibility of overlapping footprints should not be 409 excluded, i.e. the scenario where more than one dCDN claims it can 410 serve a given end user request. Further, it seems reasonable to 411 assume that in most use cases it is the uCDN that makes the decision 412 on selecting a certain dCDN for request routing based on information 413 the uCDN has received from this particular dCDN. 415 4. Towards Semantics for Footprint Advertisement 417 Based on the characterizations in existing documents (see Section 2), 418 we can distill some "rough" candidates for definitions of a 419 footprint: 421 o Footprint could be defined by "layer-3 coverage", where coverage 422 refers to a set of prefixes, a geographic region, or similar 423 boundary. 425 o Footprint could alternatively be defined as "a class of end user 426 requests a dCDN is willing to serve". 428 Independent of the exact definition of footprint, a footprint likely 429 needs to be able to include the connectivity of a given dCDN to other 430 CDNs that may be able to serve content to users on behalf of that 431 dCDN, to cover cases where there is a transitive CDN interconnection. 432 Further, the downstream CDN must be able to express its footprint to 433 an interested upstream CDN (uCDN) in a comprehensive form, e.g., as a 434 complete data set containing the complete footprint. Making 435 incremental updates, however, to express dynamic changes in state is 436 also desirable. 438 Different concrete candidates for a footprint are imaginable (set of 439 prefixes, a geographic region, ...). Among these, "set of IP- 440 prefixes" may potentially be a useful footprint in the CDDNI context. 441 Such footprint information must be able to contain full IP addresses 442 (i.e., a /32 for IPv4 and a /128 for IPv6) and also IP prefixes with 443 an arbitrary prefix length. There must be support for multiple IP 444 address version, i.e., IPv4 and IPv6 in the footprint. 446 Roughly speaking, footprint can be defined as "willingness to serve" 447 by a downstream CDN. However, in addition to simply "willingness to 448 serve", the uCDN needs to have some additional information to make a 449 dCDN selection decision. The uCDN needs additional information so 450 that it can assess "how well" a given dCDN can actually serve a given 451 end user request. One can imagine that such additonal information is 452 implicitly associated with a given footprint, e.g. due to (from the 453 request routing interface's perspective out-of-band) contractual 454 agreements (e.g. SLAs), business relationships, or perceived dCDN 455 quality in the past. As an alternative, such additional information 456 could also be explicitly be tagged along with the footprint. 458 5. Towards Semantics for Capabilities Advertisement 460 The dCDN must be able to express its general capabilities to the 461 uCDN. These general capabilities could express if the dCDN supports 462 a given service, for instance, WWW delivery, Video on Demand (VoD) 463 delivery based on flash or apple technologies, or live streaming 464 based on RTSP. 466 The dCDN must be able to express particular capabilities for the 467 delivery in a particular footprint area. For example, the dCDN might 468 in general offer VoD but not in some areas, either for maintenance 469 reasons or because this particular area cannot deliver this type of 470 service. In such cases, i.e. where capabilities must be expressed on 471 a per footprint basis, it may be beneficial to combine footprint and 472 capabilities advertisement. 474 High-level and very rough semantics for (and characteristics of) 475 capabilities are thus: 477 o Capabilities are types of information that allow a uCDN to 478 determine if a downstream CDN is able (and willing) to accept the 479 delegated content request. 481 o Some capabilities may change dynamically based on the state of the 482 network or a cache. 484 Capabilities seem to fall into several broad categories. Some are 485 capabilities associated with a resource itself, like the codecs or 486 streaming technologies in which a particular resource is available. 487 Some capabilities are associated with the cache: these include the 488 load state, available storage resources, and so on. Some 489 capabilities are associated with the network where the cache is 490 deployed, including available bandwidth for streaming, availability 491 of QoS mechanisms, and so on. 493 Some capabilities reflect administrative restrictions or policies 494 that may affect the decisions made up a uCDN. It seems unlikely 495 these factors will be shared through the interface, however. 497 Cache capabilities are: 499 o aggregate information (i.e. not for individual caches, but still 500 helpful for dCDN selection) about load, or "excessive load" 502 o aggregate information (i.e. not for individual caches, but still 503 helpful for dCDN selection) about available resources, storage 504 resources 506 o aggregate information (i.e. not for individual caches, but still 507 helpful for dCDN selection) regarding failure conditions 509 Resource Capabilities: 511 o supported range of playback devices 513 o supported range of delivery technologies 515 o specific delivery protocols 517 o supported content types (MIME) 519 Network Capabilities: 521 o meeting a certain QoS 523 o distribution and delivery priority 525 o streaming bandwidth 527 Outside the scope of capability advertisements are administrative 528 capabilities, such as: 530 o policy (membership in the federation, etc) 532 o administrative limits, e.g. maximum aggregate volume of content 533 delivered monthly 535 o indication of distribution/delivery fees 537 6. Open Issues and Questions 539 The following open issues deserve discussion in the CDNI WG: 541 o What is the service model of this interface: Does the uCDN always 542 query the dCDNs? Or does the dCDN always push information to the 543 uCDNs? 545 o Should footprint advertisement be based on prefixes, on cache 546 addresses, or on other facts? 548 o Should capability advertisement include only static attributes of 549 the CDN, or should it factor in dynamic attributes as well? 551 o How can the dCDN express the associated costs of delivery, either 552 monetary or virtual costs, to the uCDN for the actual delivery? 553 Is this in scope of this interface? 555 o Are monetary delivery costs explicitly in scope of capabilities 556 advertisement? 558 o Does a footprint need to include the "reachability" of the dCDN to 559 other CDNs that may be able to serve content to users on behalf of 560 dCDN? 562 o What is the assumed business relationship between the uCDN and the 563 dCDN? Is the uCDN always the "authoritative" CDN provider which 564 transitively has itself contracted several downstream CDN 565 providers? 567 7. Security Considerations 569 Security considerations will be discussed in a future version of this 570 document. 572 8. Conclusion 574 This document tries to capture the semantics of the "Footprint and 575 Capabilities Advertisement" part of the CDNI Request Routing 576 interface, i.e. the desired meaning and what "Footprint and 577 Capabilities Advertisement" is expected to offer within CDNI, also 578 reflecting ongoing discussions in the CDNI design team on "Footprint 579 and Capabilities Advertisement". Several key design decisions and 580 open questions have been discussed. 582 The discussion in this document has the objective to facilitate the 583 choosing of one or more suitable protocols for "Footprint and 584 Capabilities Advertisement" within CDNI Request Routing. It is the 585 goal of this document to capture the outcome of further progress of 586 the CDNI WG and the design team on "Footprint and Capabilities 587 Advertisement" including answers to currently open questions in 588 future versions of this draft. 590 9. References 592 9.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 9.2. Informative References 599 [I-D.davie-cdni-framework] 600 Davie, B. and L. Peterson, "Framework for CDN 601 Interconnection", draft-davie-cdni-framework-01 (work in 602 progress), October 2011. 604 [I-D.ietf-cdni-problem-statement] 605 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 606 Distribution Network Interconnection (CDNI) Problem 607 Statement", draft-ietf-cdni-problem-statement-08 (work in 608 progress), June 2012. 610 [I-D.ietf-cdni-requirements] 611 Leung, K. and Y. Lee, "Content Distribution Network 612 Interconnection (CDNI) Requirements", 613 draft-ietf-cdni-requirements-03 (work in progress), 614 June 2012. 616 [I-D.ietf-cdni-use-cases] 617 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 618 K., and G. Watson, "Use Cases for Content Delivery Network 619 Interconnection", draft-ietf-cdni-use-cases-09 (work in 620 progress), July 2012. 622 [I-D.peterson-cdni-strawman] 623 Peterson, L. and J. Hartman, "A Simple Approach to CDN 624 Interconnection", draft-peterson-cdni-strawman-01 (work in 625 progress), May 2011. 627 [I-D.previdi-cdni-footprint-advertisement] 628 Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and 629 L. Faucheur, "CDNI Footprint Advertisement", 630 draft-previdi-cdni-footprint-advertisement-01 (work in 631 progress), March 2012. 633 [I-D.xiaoyan-cdni-requestrouting] 634 He, X., Li, J., Dawkins, S., and G. Chen, "Request Routing 635 for CDN Interconnection", 636 draft-xiaoyan-cdni-requestrouting-01 (work in progress), 637 June 2011. 639 Appendix A. Acknowledgment 641 Jan Seedorf is partially supported by the COAST project (COntent 642 Aware Searching, retrieval and sTreaming, http://www.coast-fp7.eu), a 643 research project supported by the European Commission under its 7th 644 Framework Program (contract no. 248036). The views and conclusions 645 contained herein are those of the authors and should not be 646 interpreted as necessarily representing the official policies or 647 endorsements, either expressed or implied, of the COAST project or 648 the European Commission. 650 Martin Stiemerling provided initial input to this document and 651 valuable comments to the ongoing discussions among the authors of 652 this document. 654 Authors' Addresses 656 Jan Seedorf 657 NEC 658 Kurfuerstenanlage 36 659 Heidelberg 69115 660 Germany 662 Phone: +49 6221 4342 221 663 Fax: +49 6221 4342 155 664 Email: seedorf@neclab.eu 666 Jon Peterson 667 NeuStar 668 1800 Sutter St Suite 570 669 Concord CA 94520 670 USA 672 Phone: 673 Fax: 674 Email: jon.peterson@neustar.biz 676 Stefano Previdi 677 Cisco Systems 678 Via Del Serafico 200 679 Rome 0144 680 Italy 682 Phone: 683 Fax: 684 Email: sprevidi@cisco.com