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