idnits 2.17.1 draft-spp-cdni-rr-foot-cap-semantics-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 25, 2013) is 4049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HIGH' is mentioned on line 173, but not defined == Missing Reference: 'MED' is mentioned on line 212, but not defined == Missing Reference: 'LOW' is mentioned on line 205, but not defined == Unused Reference: 'RFC2119' is defined on line 698, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-03 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-00 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-05 == Outdated reference: A later version (-09) exists of draft-ma-cdni-capabilities-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: August 29, 2013 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Azuki Systems, Inc. 12 February 25, 2013 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-spp-cdni-rr-foot-cap-semantics-04 17 Abstract 19 This document tries to capture the semantics of the "Footprint and 20 Capabilities Advertisement" part of the CDNI Request Routing 21 interface, i.e. the desired meaning and what "Footprint and 22 Capabilities Advertisement" is expected to offer within CDNI. The 23 discussion in this document has the goal to facilitate the choosing 24 of one or more suitable protocols for "Footprint and Capabilities 25 Advertisement" within CDNI Request Routing. 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 August 29, 2013. 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 and scope . . . . . . . . . . . . . . . . . . . . 3 62 2. CDNI FCI in existing CDNI Documents . . . . . . . . . . . . . 4 63 3. Design Decisions for Footprint and Capabilities . . . . . . . 7 64 3.1. Advertising Limited Coverage . . . . . . . . . . . . . . . 7 65 3.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 8 66 3.3. Advertisement versus Queries . . . . . . . . . . . . . . . 9 67 3.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 9 68 3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 10 69 4. Main Use Case to foster the Clarification of Semantics . . . . 11 70 5. Towards Semantics for Footprint Advertisement . . . . . . . . 12 71 6. Towards Semantics for Capabilities Advertisement . . . . . . . 14 72 7. Open Issues and Questions . . . . . . . . . . . . . . . . . . 17 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 77 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 80 1. Introduction and scope 82 The CDNI working group is working on a set of protocols to enable the 83 interconnection of multiple CDNs to a CDN federation. This CDN- 84 federation should serve multiple purposes, as discussed in [RFC6770], 85 for instance, to extend the reach of a given CDN to areas in the 86 network which are not covered by this particular CDN. 88 The goal of this document is to achieve a clear understanding in the 89 CDNI WG about the semantics associated with the CDNI Request Routing 90 Footprint & Capabilities Advertisement Interface (from now on 91 referred to as FCI), in particular the type of information a 92 downstream CDN 'advertises' regarding its footprint and capabilities. 93 To narrow down undecided aspects of these semantics, this document 94 tries to establish a common understanding of what the FCI should 95 offer and accomplish in the context of CDN Interconnection. 97 It is explicitly outside the scope of this document to decide on 98 specific protocols to use for the FCI. 100 General assumptions in this document: 102 o The CDNs participating in the CDN federation have already 103 performed a boot strap process, i.e., they have connected to each 104 other, either directly or indirectly, and can exchange information 105 amongst each other. 107 o The uCDN has received footprint and/or capability advertisements 108 from a set of dCDNs. Footprint advertisement and capability 109 advertisement need not use the same underlying protocol. 111 o The upstream CDN (uCDN) receives the initial request-routing 112 request from the endpoint requesting the resource. 114 This document is organized as follows. First, a recap of the 115 definition of "footprint and capabilities advertisement" in existing 116 documents is given, attempting to distill the apparent common 117 understanding of what the terms 'footprint' and 'capabilities' mean 118 in the context of CDNI. Then, the detailed semantics of the 119 footprint advertisement mechanism and the capability advertisement 120 mechanism will be discussed. Finally, open issues and questions to 121 be discussed in the CDNI WG will be listed. 123 2. CDNI FCI in existing CDNI Documents 125 In the following section, the existing descriptions of the CDNI FCI 126 interface in existing documents will be examined. After this, the 127 apparent common understanding of what this interface is intended to 128 offer and accomplish will be carved out. 130 The CDNI Problem Statement [RFC6707] describes footprint and 131 capabilities advertisement as: "[enabling] a Request Routing function 132 in an Upstream CDN to query a Request Routing function in a 133 Downstream CDN to determine if the Downstream CDN is able (and 134 willing) to accept the delegated Content Request". In addition, the 135 draft says "the CDNI Request Routing interface is also expected to 136 enable a downstream CDN to provide to the upstream CDN (static or 137 dynamic) information (e.g. resources, footprint, load) to facilitate 138 selection of the downstream CDN by the upstream CDN request routing 139 system when processing subsequent content requests from User Agents". 140 It thus considers "resources" and "load" as capabilities to be 141 advertised by the downstream CDN. 143 The CDNI Use Cases document [RFC6770] describes capabilities as "... 144 supported range of devices and User Agents or the supported range of 145 delivery technologies". Examples for such capabilities given are 146 specific delivery protocols, technology migration, and meeting a 147 certain QoS. 149 The CDNI requirements draft [I-D.ietf-cdni-requirements] lists 150 several requirements relevant for the "footprint and capabilities 151 advertisement" part of the CDNI request routing interface. In 152 summary, the following requirements for the CDNI Request Routing 153 Interface and general requirements are relevant for the understanding 154 of the semantics of "footprint and capabilities advertisement": 156 o GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN 157 information to be exposed to other CDNs for effective and 158 efficient delivery of the content. Examples of intra-CDN 159 information include surrogate topology, surrogate status, cached 160 content, etc." 162 o GEN-9 [MED], "The CDNI solution should support cascaded CDN 163 redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an 164 arbitrary number of levels beyond the first level." 166 o GEN-10 [MED], "The CDNI solution should support an arbitrary 167 topology of interconnected CDNs (i.e. the CDN topology cannot be 168 restricted to a tree, a loop-free topology, etc.)." 170 o GEN-11 [HIGH], "The CDNI solution shall prevent looping of any 171 CDNI information exchange." 173 o REQ-1 [HIGH], allowing the downstream CDN "to communicate to the 174 Upstream CDN coarse information about the Downstream CDN ability 175 and/or willingness to handle requests from the Upstream CDN. For 176 example, this could potentially include a binary signal 177 ("Downstream CDN ready/not-ready to take additional requests from 178 Upstream CDN") to be used in case of excessive load or failure 179 condition in the Downstream CDN." 181 o REQ-2 [MED], allowing the downstream CDN to communicate 182 capabilities such as supported content types and delivery 183 protocols, a set of metrics/attributes (e.g. Streaming bandwidth, 184 storage resources, distribution and delivery priority), a set of 185 affinities (e.g. Preferences, indication of distribution/delivery 186 fees), information to facilitate request redirection, as well as 187 footprint information (e.g. "layer-3 coverage"). 189 o REQ-3 [MED], "In the case of cascaded redirection, the CDNI 190 Request-Routing interface shall allow the Downstream CDN to also 191 include in the information communicated to the Upstream CDN, 192 information on the capabilities, resources and affinities of CDNs 193 to which the Downstream CDN may (in turn) redirect requests 194 received by the Upstream CDN. In that case, the CDNI Request- 195 Routing interface shall prevent looping of such information 196 exchange." 198 o REQ-4 [LOW], allowing the downstream CDN to communicate "aggregate 199 information on CDNI administrative limits and policy" (e.g. the 200 maximum number of requests redirected by the Upstream CDN to be 201 served simultaneously by the Downstream CDN or maximum aggregate 202 volume of content (e.g. in Terabytes) to be delivered by the 203 Downstream CDN over a time period). 205 o REQ-11 [LOW], "The CDNI Request-Routing protocol may support a 206 mechanism allowing an Upstream CDN to avoid redirecting a request 207 to a Downstream CDN if that is likely to result in the total 208 redirection time exceeding some limit." 210 Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of 211 what "footprint" information might convey in the CDNI requirements 212 draft [I-D.ietf-cdni-requirements]. Also, note that REQ-3 [MED] 213 addresses cascaded (transitive) downstream CDNs. In such a case, a 214 downstream CDN needs to include (in its advertisement information 215 that it conveys to an upstream CDN) aggregate footprint and 216 capabilities information for any further transitive downstream CDNs. 217 Such information may be included implicitly (i.e. the cascaded dCDN 218 is oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of 219 the fact that there is a cascaded dCDN is visible to the uCDN). In 220 either case, logic is needed to process incoming footprint 221 information from a cascaded dCDN and decide if/how it is to be re- 222 advertised/aggregated when advertising footprint to an upstream CDN. 224 The CDNI framework draft [I-D.ietf-cdni-framework] describes a 225 "footprint" as in [I-D.previdi-cdni-footprint-advertisement], 226 consisting of two parts: 1) "a class of end user requests 227 (represented, for example, by a set of IP prefixes, or a geographic 228 region) that the dCDN is willing and able to serve directly, without 229 use of another dCDN", and 2) "the connectivity of the dCDN to other 230 CDNs that may be able to serve content to users on behalf of dCDN". 231 The term "connectivity" has recently been replaced with 232 "reachability" in [I-D.previdi-cdni-footprint-advertisement], and as 233 discussed above, "without use of another dCDN" may include aggregated 234 transitive dCDNs. Further examples for capabilities are "the ability 235 to handle certain types of content (e.g. specific streaming formats) 236 or quality of service (QoS)." Content handling capabilities 237 discussed in [I-D.ma-cdni-capabilities] include delivery and 238 acquisition protocols, redirection modes, and metadata related 239 capabilities (e.g., authorization algorithm). 241 From reading the various draft listed above, it is safe to conclude 242 that neither the term 'footprint' nor 'capabilities' has been clearly 243 and unambiguously defined in these documents and a very broad range 244 of potential capabilities is listed. 246 3. Design Decisions for Footprint and Capabilities 248 A large part of the difficulty in discussing the FCI lies in 249 understanding what exactly is meant when trying to define footprint 250 in terms of "coverage" or "reachability." While the operators of 251 CDNs pick strategic locations to situate caches, a cache with a 252 public IPv4 address is reachable by any endpoint on the Internet 253 unless some policy enforcement precludes the use of the cache. 255 Some CDNs aspire to cover the entire world, which we will henceforth 256 call global CDNs. The footprint advertised by such a CDN in the CDNI 257 environment would, from a coverage or reachability perspective, 258 presumably cover all prefixes. Potentially more interesting for CDNI 259 use cases, however, are CDNs that claim a more limited coverage, but 260 seek to federate with other CDNs in order to create a single CDN 261 fabric which shares resources. 263 Futhermore, not all capabilties need be footprint restricted. 264 Depending upon the use case, the optimal semantics of "footprints 265 with capability attributes" vs. "capabilities with footprint 266 restrictions" are not clear. 268 The key to understanding the semantics of footprint and capability 269 advertisement lies in understand why a dCDN would advertise a limited 270 coverage area, and how a uCDN would use such advertisements to decide 271 among one of several dCDNs. The following section will discuss some 272 of the trade-offs and design decisions that need to be decided upon 273 for the CDNI FCI. 275 3.1. Advertising Limited Coverage 277 The basic use case that would motivate a dCDN to advertise a limited 278 coverage is that the CDN was built to cover only a particular portion 279 of the Internet. For example, an ISP could purpose-build a CDN to 280 serve only their own customers by situating caches in close 281 topological proximity to high concentrations of their subscribers. 282 The ISP knows the prefixes it has allocated to end users and thus can 283 easily construct a list of prefixes that its caches were positioned 284 to serve. 286 When such a purpose-built CDN joins a federation, however, and 287 advertises its footprint to a uCDN, the original intended coverage of 288 the CDN might not represent its actual value to the federation of 289 CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, 290 which they federate through CDNI. A given user E, who is customer of 291 ISP-B, might happen to be topologically closest to a cache fielded by 292 ISP-A, if E happens to live in a region where ISP-B has few customers 293 and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If 294 ISP-B's CDN has a failure condition, should the uCDN understand that 295 ISP-A's caches are potentially available back-ups - and if so, how 296 does ISP-A advertise itself as a "standby" for E? What about the 297 case where CDNs advertising to the same uCDN express overlapping 298 coverage (for example, a federation mixing global and limited CDNs)? 300 The answers to these questions greatly depend on how much information 301 we want the uCDN to use to make a selection of a dCDN. If a uCDN has 302 three dCDNs to choose from that "cover" the IP address of user E, 303 obviously the uCDN might be interested to know how optimal the 304 coverage is from each of the dCDNs - coverage need not be binary, 305 either provided or not provided. dCDNs could advertise a coverage 306 "score," for example, and provided that they all reported scores 307 fairly on the same scale, uCDNs could use that to make their 308 topological optimality decision. Alternatively, dCDNs could for 309 their footprint advertise the IP addresses of their caches rather 310 than prefix "coverage," and let the uCDN decide for itself (based on 311 its own topological intelligence) which dCDN has better resources to 312 serve a given user. 314 In summary, the semantics of advertising footprint depend on whether 315 such qualitative metrics for expressing footprint (such as the 316 coverage 'score' mentioned above) should be part of the CDNI FCI, or 317 if it should focus just on 'binary' footprint. 319 3.2. Capabilities and Dynamic Data 321 In cases where the apparent footprint of dCDNs overlaps, uCDNs might 322 also want to rely on a host of other factors to evaluate the 323 respective merits of dCDNs. These include facts related to the 324 caches themselves, to the network where the cache is deployed, to the 325 nature of the resource sought and to the administrative policies of 326 the respective networks. 328 In the absence of network-layer impediments to reaching caches, the 329 choice to limit coverage is necessarily an administrative policy. 330 Much policy must be agreed upon before CDNs can merge into 331 federations, including questions of membership, compensation, volumes 332 and so on. A uCDN certainly will factor these sorts of 333 considerations into its decision to select a dCDN, but there is 334 probably little need for dCDNs to actually advertise them through an 335 interface - they will be settled out of band as a precondition for 336 federating. 338 Other facts about the dCDN would be expressed through the interface 339 to the uCDN. Some capabilities of a dCDN are static, and some are 340 highly dynamic. Expressing the total storage built into its caches, 341 for example, changes relatively rarely, whereas the amount storage in 342 use at any given moment is highly volatile. Network bandwidth 343 similarly could be expressed as either total bandwidth available to a 344 cache, or based on the current state of the network. A cache may at 345 one moment lack a particular resource in storage, but have it the 346 next. 348 The semantics of the capabilities interface will depend on how much 349 of the dCDN state needs to be pushed to the uCDN and qualitatively 350 how often that information should be updated. 352 3.3. Advertisement versus Queries 354 In a federated CDN environment, each dCDN shares some of its state 355 with the uCDN, which the uCDN uses to build a unified picture of all 356 of the dCDNs available to it. In architectures that share detailed 357 capability information, the uCDN could basically perform the entire 358 request-routing intelligence down to selecting a particular cache 359 before sending the request to the dCDN (note that within the current 360 CDNI WG scope, such direct selection of specific caches by the uCDN 361 is out of scope). However, when the uCDN must deal with many 362 potential dCDNs, this approach does not scale. Especially as CDNs 363 scale up from dozens or hundreds of caches to thousands or tens of 364 thousands, the volume of updates to footprint and capability may 365 become onerous. 367 Were the volume of updates to exceed the volumes of requests to the 368 uCDN, it might make more sense for the uCDN to query dCDNs upon 369 receiving requests (as is the case in the recursive redirection mode 370 described in [I-D.ietf-cdni-framework]), instead of receiving 371 advertisements and tracking the state of dCDNs itself. The advantage 372 of querying dCDNs would be that much of the dynamic data that dCDNs 373 cannot share with the uCDN would now be factored into the uCDN's 374 decision. dCDNs need not replicate any state to the uCDN - uCDNs 375 could effectively operate in a stateless mode. 377 The semantics of both footprint and capability advertisement depend 378 on the service model here: are there cases where a synchronous query/ 379 response model would work better for the uCDN decision than a state 380 replication model? 382 3.4. Avoiding or Handling 'cheating' dCDNs 384 In a situation where more than one dCDN is willing to serve a given 385 end user request, it might be attractive for a dCDN to 'cheat' in the 386 sense that the dCDN provides inaccurate information to the uCDN in 387 order to convince the uCDN to select it opposed to 'competing' dCDNs. 388 It could therefore be desirable to take away the incentive for dCDNs 389 to cheat (in information advertised) as much as possible. One option 390 here is to make the information the dCDN advertises somehow 391 verifiable for the uCDN. One the other hand, a cheating dCDN might 392 be avoided or handled by the fact that there will be strong 393 contractual agreements between a uCDN and a dCDN, so that a dCDN 394 would risk severe penalties or legal consequences when caught 395 cheating. 397 Overall, it seems that information a dCDN advertises should (in the 398 long run) be somehow qualitatively verifiable by the uCDN, though 399 possibly through non-real-time out-of-band audits. It is probably an 400 overly strict requirement to mandate that such verification be 401 possible "immediately", i.e. during the request routing process 402 itself. If the uCDN can detect a cheating dCDN at a later stage, it 403 should suffice for the uCDN to "de-incentivize" cheating because it 404 would negatively affect the long-term business relationship with a 405 particular dCDN. 407 3.5. Focus on Main Use Cases may Simplify Things 409 To narrow down semantics for "footprint" and "capabilities" in the 410 CDNI context, it can be useful to initially focus on key use cases to 411 be addressed by the CDNI WG that are to be envisioned the main 412 deployments in the foreseeable future. In this regard, a main 413 realistic use case is the existence of ISP-owned CDNs, which 414 essentially cover a certain operator's network. At the same time, 415 however, the possibility of overlapping footprints should not be 416 excluded, i.e. the scenario where more than one dCDN claims it can 417 serve a given end user request. The ISPs may also choose to federate 418 with a fallback global CDN. 420 It seems reasonable to assume that in most use cases it is the uCDN 421 that makes the decision on selecting a certain dCDN for request 422 routing based on information the uCDN has received from this 423 particular dCDN. It may be assumed that 'cheating' CDNs will be 424 dealt with via means outside the scope of CDNI and that the 425 information advertised between CDNs is accurate. In addition, 426 excluding the use of qualitative information (e.g., cache proximity, 427 delivery latency, cache load) to to predict the quality of delivery 428 would further simplify the use case allowing it to better focus on 429 the basic functionality of the FCI. 431 4. Main Use Case to foster the Clarification of Semantics 433 Focusing on a main use case that contains a simple (yet somewhat 434 challenging), realistic, and generally imaginable scenario can help 435 in narrowing down the requirements for the CDNI FCI. To this end, 436 the following (simplified) use case can help in clarifying the 437 semantics of footprint and capabilities for CDNI. In particular, the 438 intention of the use case is to clarify what information needs to be 439 exchanged on the CDNI FCI, what types of information need to be 440 supported in a mandatory fashion (and which should be considered 441 optional), and what types of information need to be updated with 442 respect to a priori established CDNI contracts. 444 In short, one can imagine the following use case: A given uCDN has 445 several dCDNs. It selects one dCDN for delivery protocol A and 446 footprint 1 and another dCDN for delivery protocol B and footprint 1. 447 The dCDN that serves delivery protocol B has a further, transitive 448 (level-2) dCDN, that serves delivery protocol B in a subset of 449 footprint 1 where the first-level dCDN cannot serve delivery protocol 450 B itself. What happens if capabilities change in the transitive 451 level-2 dCDN that might affect how the uCDN selects a level-1 dCDN 452 (e.g. in case the level-2 dCDN cannot serve delivery protocol B 453 anymore)? How will these changes be conveyed to the uCDN? In 454 particular, what information does the uCDN need to be able to select 455 a new first-level dCDN, either for all of footprint 1 or only for the 456 subset of footprint 1 that the transitive level-2 dCDN served on 457 behalf of the first-level dCDN? 459 5. Towards Semantics for Footprint Advertisement 461 Roughly speaking, "footprint" can be defined as "ability and 462 willingness to serve" by a downstream CDN. However, in addition to 463 simple "ability and willingness to serve", the uCDN may wish to have 464 additional information to make a dCDN selection decision, e.g., "how 465 well" a given dCDN can actually serve a given end user request. The 466 "ability and willingness" to serve should be distinguished from the 467 subjective qualitative measurement of "how well" it was served. One 468 can imagine that such additonal information is implicitly associated 469 with a given footprint, e.g. due to contractual agreements (e.g. 470 SLAs), business relationships, or perceived dCDN quality in the past. 471 As an alternative, such additional information could also be 472 explicitly tagged along with the footprint. 474 It is reasonable to assume that a significant part of the actual 475 footprint advertisement will happen in contractual agreements between 476 participating CDNs, i.e. prior to the advertisement phase using the 477 CDNI FCI. The reason for this assumption is that any contractual 478 agreement is likely to contain specifics about the dCDN coverage 479 (i.e. the dCDN footprint) the contractual agreement applies to. In 480 particular, additional information to judge the delivery quality 481 associated with a given dCDN footprint might be defined in 482 contractual agreements (i.e. outside of the CDNI FCI). Further, one 483 can assume that dCDN contractual agreements about the delivery 484 quality associated with a given footprint will probably be based on 485 high-level aggregated statistics (i.e. not too detailed). 487 Given that a large part of footprint advertisement will actually 488 happen in contractual agreements, the semantics of CDNI footprint 489 advertisement refer to answering the following question: what exactly 490 still needs to be advertised by the CDNI FCI? For instance, updates 491 about temporal failures of part of a footprint can be useful 492 information to convey via the CDNI request routing interface. Such 493 information would provide updates on information previously agreed in 494 contracts between the participating CDNs. In other words, the CDNI 495 FCI is a means for a dCDN to provide changes/updates regarding a 496 footprint it has prior agreed to serve in a contract with a uCDN. 498 Generally speaking, one can imagine two categories of footprint to be 499 advertised by a dCDN: 501 o Footprint could be defined based on (layer-3) "coverage/ 502 reachability", where coverage/reachability refers to a set of 503 prefixes, a geographic region, or similar boundary. The dCDN 504 claims that it can cover/reach 'end user requests coming from this 505 footprint'. 507 o Footprint could be defined based on "resources", where resources 508 refers to surrogates/caches a dCDN claims to have (e.g., the 509 location of surrogates/resources). The dCDN claims that 'from 510 this footprint' it can serve incoming end user requests. 512 For each of these footprint types, there are capabilities associated 513 with a given footprint, i.e. the capabilities (e.g., delivery 514 protocol, redirection mode, metadata) supported in the coverage area 515 for a "coverage/reachability" defined footprint, or the capabilities 516 of resources (e.g., delivery protocol, redirection mode, metadata 517 support) for a "resources" defined footprint. It seems clear that 518 "coverage/reachability" types of footprint must be supported within 519 CDNI. It needs to be decided, whether - in addition to "coverage/ 520 reachability" types - also "resource" types of footprint should be 521 supported within CDNI. 523 Different concrete candidates for a "coverage/reachability" footprint 524 are imaginable. In particular, the following concrete types of 525 footprint seem useful in the CDNI context: 'set of IP-prefixes', 'AS 526 number list', and 'geographic region'. Among these, 'set of IP- 527 prefixes' must be able to contain full IP addresses (i.e., a /32 for 528 IPv4 and a /128 for IPv6) and also IP prefixes with an arbitrary 529 prefix length. There must also be support for multiple IP address 530 versions, i.e., IPv4 and IPv6, in the footprint. 532 Independent of the exact type of a footprint, a footprint might also 533 include the connectivity of a given dCDN to other CDNs that may be 534 able to serve content to users on behalf of that dCDN, to cover cases 535 where there is a transitive CDN interconnection. Further, the 536 downstream CDN must be able to express its footprint to an interested 537 upstream CDN (uCDN) in a comprehensive form, e.g., as a complete data 538 set containing the complete footprint. Making incremental updates, 539 however, to express dynamic changes in state is also desirable. 541 6. Towards Semantics for Capabilities Advertisement 543 In general, the dCDN must be able to express its general capabilities 544 to the uCDN. These general capabilities could express if the dCDN 545 supports a given service, for instance, HTTP delivery, RTP/RTSP 546 delivery or RTMP. Furthermore, the dCDN must be able to express 547 particular capabilities for the delivery in a particular footprint 548 area. For example, the dCDN might in general offer RTMP but not in 549 some specific areas, either for maintenance reasons or because the 550 caches covering this particular area cannot deliver this type of 551 service. Hence, in certain cases footprint and capabilities are tied 552 together and cannot be interpreted independently from each other. In 553 such cases, i.e. where capabilities must be expressed on a per 554 footprint basis, it may be beneficial to combine footprint and 555 capabilities advertisement. 557 A high-level and very rough semantic for capabilities is thus the 558 following: Capabilities are types of information that allow a uCDN to 559 determine if a downstream CDN is able (and willing) to accept (and 560 properly handle) a delegated content request. In addition, 561 Capabilities are characterized by the fact that this information may 562 possibly change over time based on the state of the network or 563 caches. 565 At a first glance, several broad categories of capabilities seem 566 useful to convey via an advertisement interface (and indeed many such 567 candidate capabilities have been suggested in CDNI drafts, see 568 Section 2). However, advertising capabilities that change highly 569 dynamically (e.g. real-time delivery performance metrics, CDN 570 resource load, or other highly dynamically changing QoS information) 571 should probably not be in scope for the CDNI FCI. First, out of the 572 multitude of possible metrics and capabilities, it is hard to agree 573 on a subset and the precise metrics to be used. Second, and perhaps 574 more importantly, it seems not feasible to specify such highly 575 dynamically changing capabilities and the corresponding metrics 576 within the CDNI charter time-frame. 578 Useful capabilities refer to information that does not change highly 579 dynamically and which in many cases is absolutely necessary to decide 580 on a particular dCDN for a given end user request. For instance, if 581 an end user request concerns the delivery of a video file with a 582 certain protocol (e.g. RTMP), the uCDN needs to know if a given dCDN 583 has the capabiltity of supporting this delivery protocol. 585 Similar to footprint advertisement, it is reasonable to assume that a 586 significant part of the actual (resource) capabilities advertisement 587 will happen in contractual agreements between participating CDNs, 588 i.e. prior to the advertisement phase using the CDNI FCI. The role 589 of capability advertisement is hence rather to enable the dCDN to 590 update a uCDN on changes since a contract has been set up (e.g. in 591 case a new delivery protocol is suddenly being added to the list of 592 supported delivery protocols of a given dCDN, or in case a certain 593 delivery protocol is suddenly not being supported anymore due to 594 failures). Capabilities advertisement thus refers to conveying 595 information to a uCDN about changes/updates of certain capabilities 596 with respect to a given contract. 598 Given these semantics, it needs to be decided what exact capabilities 599 are useful and how these can be expressed. Since the details of CDNI 600 contracts are not known at the time of this writing (and the CDNI 601 interface should probably be agnostic to these contracts anyway), it 602 remains to be seen what capabilities will be used to define 603 agreements between CDNs in practice. One implication for 604 standardization may be to initially only specify a very limited set 605 of mandatory capabilities for advertisement and have on top of that a 606 flexible data model that allows exchanging additional capabilities 607 when needed. Still, agreement needs to be found on which 608 capabilities (if any) shoudl be mandatory among CDNs. As discussed 609 in Section 3.5, finding the concrete answers to these questions can 610 benefit from focusing on a small number of key use cases that are 611 highly relevant and contain enough complexity to help in 612 understanding what concrete capabilities are needed to facilitate CDN 613 Interconnection. 615 Under the above considerations, the following capabilities seem 616 useful as 'base' capabilities, i.e. ones that are needed in any case 617 and therefore constitute mandatory capabilities to be supported by 618 the CDNI FCI: 620 o Delivery Protocol (e.g., HTTP vs. RTMP) 622 o Acquisition Protocol (for aquiring content from a uCDN) 624 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 625 discussed in [I-D.ietf-cdni-framework]) 627 o Capabilities related to CDNI Logging (e.g., supported logging 628 mechanisms) 630 o Capabilities related to CDNI Metadata (e.g., authorization 631 algorithms or support for proprietary vendor metadata) 633 It is not feasable to enumerate all the possible options for the 634 mandatory capabilities listed above (e.g., all the potential delivery 635 protocols or metadata options) or anticipate all the future needs for 636 additional capabilities. It would be unreasonable to burden the CDNI 637 FCI specification with defining each supported capability. The CDNI 638 FCI specification should define a generic protocol for conveying any 639 capability information. It would be reasonable to define a registry 640 which initially contains the mandatory capabilities listed above, but 641 may be extended as needs dictate. The CDNI FCI specification SHOULD 642 define the registry (and the rules for adding new entries to the 643 registry) for the different capability types. Each capability type 644 MAY further have a list of valid values. The individual CDNI 645 interface specifications which define a given capability SHOULD 646 define any necessary registries (and the rules for adding new entries 647 to the registry) for the values advertised for a given capability 648 type. 650 The mandatory capabilities listed above generally relate to 651 information that is configured on a content asset or group of assets 652 basis via CDNI metadata. The capability requirements for acquisition 653 and delivery protocol, redirection mode, and other mandatory metadata 654 capabilities (e.g. authorization algorithms) are defined in 655 [I-D.ietf-cdni-metadata]. 657 Note: CDNI interface support for logging configuration (i.e., control 658 interface vs. metadata interface) has not yet been decided. Once it 659 has been decided, the corresponding CDNI interface specification 660 should define the associated capability requirements. 662 7. Open Issues and Questions 664 The following open issues deserve further discussion in the CDNI WG: 666 o What is the service model of this interface: Does the uCDN always 667 query the dCDNs? Or does the dCDN always push information to the 668 uCDNs? 670 o In addition to "reachability" types of footprint, should also 671 "resource" types of footprint be considered by CDNI (e.g., the 672 location of surrogates/resources a dCDN has)? 674 o Does a footprint need to explicitly include the "transitive 675 reachability" of a dCDN to further dCDNs that may be able to serve 676 content to users on behalf of dCDN? 678 o What is the assumed business relationship between the uCDN and the 679 dCDN? Is the uCDN always the "authoritative" CDN provider which 680 transitively has itself contracted several downstream CDN 681 providers? 683 o How exactly can a given dCDN derive its footprint? 685 o Should the footprint/capabilities advertisement interface only 686 signal the delta with respect to a given contract (between a uCDN 687 and a dCDN) or send the whole dCDN state each time? 689 8. Security Considerations 691 Security considerations will be discussed in a future version of this 692 document. 694 9. References 696 9.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 9.2. Informative References 703 [I-D.ietf-cdni-framework] 704 Peterson, L. and B. Davie, "Framework for CDN 705 Interconnection", draft-ietf-cdni-framework-03 (work in 706 progress), February 2013. 708 [I-D.ietf-cdni-metadata] 709 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 710 Leung, K., and K. Ma, "CDN Interconnect Metadata", 711 draft-ietf-cdni-metadata-00 (work in progress), 712 October 2012. 714 [I-D.ietf-cdni-requirements] 715 Leung, K. and Y. Lee, "Content Distribution Network 716 Interconnection (CDNI) Requirements", 717 draft-ietf-cdni-requirements-05 (work in progress), 718 February 2013. 720 [I-D.ma-cdni-capabilities] 721 Ma, K., "Content Distribution Network Interconnection 722 (CDNI) Capabilities Interface", 723 draft-ma-cdni-capabilities-01 (work in progress), 724 February 2013. 726 [I-D.previdi-cdni-footprint-advertisement] 727 Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and 728 L. Faucheur, "CDNI Footprint Advertisement", 729 draft-previdi-cdni-footprint-advertisement-02 (work in 730 progress), September 2012. 732 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 733 Distribution Network Interconnection (CDNI) Problem 734 Statement", RFC 6707, September 2012. 736 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 737 K., and G. Watson, "Use Cases for Content Delivery Network 738 Interconnection", RFC 6770, November 2012. 740 Appendix A. Acknowledgment 742 Jan Seedorf is partially supported by the CHANGE project (CHANGE: 743 Enabling Innovation in the Internet Architecture through Flexible 744 Flow-Processing Extensions, http://www.change-project.eu/), a 745 research project supported by the European Commission under its 7th 746 Framework Program (contract no. 257422). The views and conclusions 747 contained herein are those of the authors and should not be 748 interpreted as necessarily representing the official policies or 749 endorsements, either expressed or implied, of the CHANGE project or 750 the European Commission. 752 Jan Seedorf has been partially supported by the COAST project 753 (COntent Aware Searching, retrieval and sTreaming, 754 http://www.coast-fp7.eu), a research project supported by the 755 European Commission under its 7th Framework Program (contract no. 756 248036). The views and conclusions contained herein are those of the 757 authors and should not be interpreted as necessarily representing the 758 official policies or endorsements, either expressed or implied, of 759 the COAST project or the European Commission. 761 Martin Stiemerling provided initial input to this document and 762 valuable comments to the ongoing discussions among the authors of 763 this document. 765 Authors' Addresses 767 Jan Seedorf 768 NEC 769 Kurfuerstenanlage 36 770 Heidelberg 69115 771 Germany 773 Phone: +49 6221 4342 221 774 Fax: +49 6221 4342 155 775 Email: seedorf@neclab.eu 777 Jon Peterson 778 NeuStar 779 1800 Sutter St Suite 570 780 Concord CA 94520 781 USA 783 Phone: 784 Fax: 785 Email: jon.peterson@neustar.biz 787 Stefano Previdi 788 Cisco Systems 789 Via Del Serafico 200 790 Rome 0144 791 Italy 793 Phone: 794 Fax: 795 Email: sprevidi@cisco.com 797 Ray van Brandenburg 798 TNO 799 Brassersplein 2 800 Delft 2612CT 801 The Netherlands 803 Phone: +31-88-866-7000 804 Email: ray.vanbrandenburg@tno.nl 805 Kevin J. Ma 806 Azuki Systems, Inc. 807 43 Nagog Park 808 Acton MA 01720 809 USA 811 Phone: +1 978-844-5100 812 Email: kevin.ma@azukisystems.com