idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-logging' is defined on line 715, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-06 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-08 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-02 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-10 Summary: 1 error (**), 0 flaws (~~), 8 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: April 24, 2014 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Azuki Systems, Inc. 12 October 21, 2013 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-01 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 April 24, 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. Design Decisions for Footprint and Capabilities . . . . . . . 4 63 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 64 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 65 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 66 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 6 67 2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7 68 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 7 69 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 70 5. Semantics for Capabilities Advertisement . . . . . . . . . . 10 71 6. Negotiation of Support for Optional Types of 72 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 14 75 7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 14 76 7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 14 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction and Scope 86 The CDNI working group is working on a set of protocols to enable the 87 interconnection of multiple CDNs to a CDN federation. This CDN- 88 federation should serve multiple purposes, as discussed in [RFC6770], 89 for instance, to extend the reach of a given CDN to areas in the 90 network which are not covered by this particular CDN. 92 The goal of this document is to achieve a clear understanding in the 93 CDNI WG about the semantics associated with the CDNI Request Routing 94 Footprint & Capabilities Advertisement Interface (from now on 95 referred to as FCI), in particular the type of information a 96 downstream CDN 'advertises' regarding its footprint and capabilities. 97 To narrow down undecided aspects of these semantics, this document 98 tries to establish a common understanding of what the FCI should 99 offer and accomplish in the context of CDN Interconnection. 101 It is explicitly outside the scope of this document to decide on 102 specific protocols to use for the FCI. 104 General assumptions in this document: 106 o The CDNs participating in the CDN federation have already 107 performed a boot strap process, i.e., they have connected to each 108 other, either directly or indirectly, and can exchange information 109 amongst each other. 111 o The uCDN has received footprint and/or capability advertisements 112 from a set of dCDNs. Footprint advertisement and capability 113 advertisement need not use the same underlying protocol. 115 o The upstream CDN (uCDN) receives the initial request-routing 116 request from the endpoint requesting the resource. 118 The CDNI Problem Statement [RFC6707] describes footprint and 119 capabilities advertisement as: "[enabling] a Request Routing function 120 in an Upstream CDN to query a Request Routing function in a 121 Downstream CDN to determine if the Downstream CDN is able (and 122 willing) to accept the delegated Content Request". In addition, the 123 RFC says "the CDNI Request Routing interface is also expected to 124 enable a downstream CDN to provide to the upstream CDN (static or 125 dynamic) information (e.g. resources, footprint, load) to facilitate 126 selection of the downstream CDN by the upstream CDN request routing 127 system when processing subsequent content requests from User Agents". 128 It thus considers "resources" and "load" as capabilities to be 129 advertised by the downstream CDN. 131 The range of different footprint definitions and possible 132 capabilities is very broad. Attempting to define a comprehensive 133 advertisement solution quickly becomes intractable. The CDNI 134 requirements draft [I-D.ietf-cdni-requirements] lists the specific 135 requirements for the CDNI Footprint & Capabilities Advertisement 136 Interface in order to disambiguate footprints and capabilities with 137 respect to CDNI. This document attempts to distill the apparent 138 common understanding of what the terms 'footprint' and 'capabilities' 139 mean in the context of CDNI, and detail the semantics of the 140 footprint advertisement mechanism and the capability advertisement 141 mechanism. 143 2. Design Decisions for Footprint and Capabilities 145 A large part of the difficulty in discussing the FCI lies in 146 understanding what exactly is meant when trying to define footprint 147 in terms of "coverage" or "reachability." While the operators of 148 CDNs pick strategic locations to situate caches, a cache with a 149 public IPv4 address is reachable by any endpoint on the Internet 150 unless some policy enforcement precludes the use of the cache. 152 Some CDNs aspire to cover the entire world, which we will henceforth 153 call global CDNs. The footprint advertised by such a CDN in the CDNI 154 environment would, from a coverage or reachability perspective, 155 presumably cover all prefixes. Potentially more interesting for CDNI 156 use cases, however, are CDNs that claim a more limited coverage, but 157 seek to federate with other CDNs in order to create a single CDN 158 fabric which shares resources. 160 Futhermore, not all capabilities need be footprint restricted. 161 Depending upon the use case, the optimal semantics of "footprints 162 with capability attributes" vs. "capabilities with footprint 163 restrictions" are not clear. 165 The key to understanding the semantics of footprint and capability 166 advertisement lies in understand why a dCDN would advertise a limited 167 coverage area, and how a uCDN would use such advertisements to decide 168 among one of several dCDNs. The following section will discuss some 169 of the trade-offs and design decisions that need to be decided upon 170 for the CDNI FCI. 172 2.1. Advertising Limited Coverage 174 The basic use case that would motivate a dCDN to advertise a limited 175 coverage is that the CDN was built to cover only a particular portion 176 of the Internet. For example, an ISP could purpose-build a CDN to 177 serve only their own customers by situating caches in close 178 topological proximity to high concentrations of their subscribers. 179 The ISP knows the prefixes it has allocated to end users and thus can 180 easily construct a list of prefixes that its caches were positioned 181 to serve. 183 When such a purpose-built CDN joins a federation, however, and 184 advertises its footprint to a uCDN, the original intended coverage of 185 the CDN might not represent its actual value to the federation of 186 CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, 187 which they federate through CDNI. A given user E, who is customer of 188 ISP-B, might happen to be topologically closest to a cache fielded by 189 ISP-A, if E happens to live in a region where ISP-B has few customers 190 and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If 191 ISP-B's CDN has a failure condition, should the uCDN understand that 192 ISP-A's caches are potentially available back-ups - and if so, how 193 does ISP-A advertise itself as a "standby" for E? What about the 194 case where CDNs advertising to the same uCDN express overlapping 195 coverage (for example, a federation mixing global and limited CDNs)? 197 The answers to these questions greatly depend on how much information 198 we want the uCDN to use to make a selection of a dCDN. If a uCDN has 199 three dCDNs to choose from that "cover" the IP address of user E, 200 obviously the uCDN might be interested to know how optimal the 201 coverage is from each of the dCDNs - coverage need not be binary, 202 either provided or not provided. dCDNs could advertise a coverage 203 "score," for example, and provided that they all reported scores 204 fairly on the same scale, uCDNs could use that to make their 205 topological optimality decision. Alternatively, dCDNs could for 206 their footprint advertise the IP addresses of their caches rather 207 than prefix "coverage," and let the uCDN decide for itself (based on 208 its own topological intelligence) which dCDN has better resources to 209 serve a given user. 211 In summary, the semantics of advertising footprint depend on whether 212 such qualitative metrics for expressing footprint (such as the 213 coverage 'score' mentioned above) should be part of the CDNI FCI, or 214 if it should focus just on 'binary' footprint. 216 2.2. Capabilities and Dynamic Data 218 In cases where the apparent footprint of dCDNs overlaps, uCDNs might 219 also want to rely on a host of other factors to evaluate the 220 respective merits of dCDNs. These include facts related to the 221 caches themselves, to the network where the cache is deployed, to the 222 nature of the resource sought and to the administrative policies of 223 the respective networks. 225 In the absence of network-layer impediments to reaching caches, the 226 choice to limit coverage is necessarily an administrative policy. 227 Much policy must be agreed upon before CDNs can merge into 228 federations, including questions of membership, compensation, volumes 229 and so on. A uCDN certainly will factor these sorts of 230 considerations into its decision to select a dCDN, but there is 231 probably little need for dCDNs to actually advertise them through an 232 interface - they will be settled out of band as a precondition for 233 federating. 235 Other facts about the dCDN would be expressed through the interface 236 to the uCDN. Some capabilities of a dCDN are static, and some are 237 highly dynamic. Expressing the total storage built into its caches, 238 for example, changes relatively rarely, whereas the amount of storage 239 in use at any given moment is highly volatile. Network bandwidth 240 similarly could be expressed as either total bandwidth available to a 241 cache, or based on the current state of the network. A cache may at 242 one moment lack a particular resource in storage, but have it the 243 next. 245 The semantics of the capabilities interface will depend on how much 246 of the dCDN state needs to be pushed to the uCDN and qualitatively 247 how often that information should be updated. 249 2.3. Advertisement versus Queries 251 In a federated CDN environment, each dCDN shares some of its state 252 with the uCDN, which the uCDN uses to build a unified picture of all 253 of the dCDNs available to it. In architectures that share detailed 254 capability information, the uCDN could basically perform the entire 255 request-routing intelligence down to selecting a particular cache 256 before sending the request to the dCDN (note that within the current 257 CDNI WG scope, such direct selection of specific caches by the uCDN 258 is out of scope). However, when the uCDN must deal with many 259 potential dCDNs, this approach does not scale. Especially as CDNs 260 scale up from dozens or hundreds of caches to thousands or tens of 261 thousands, the volume of updates to footprint and capability may 262 become onerous. 264 Were the volume of updates to exceed the volumes of requests to the 265 uCDN, it might make more sense for the uCDN to query dCDNs upon 266 receiving requests (as is the case in the recursive redirection mode 267 described in [I-D.ietf-cdni-framework]), instead of receiving 268 advertisements and tracking the state of dCDNs itself. The advantage 269 of querying dCDNs would be that much of the dynamic data that dCDNs 270 cannot share with the uCDN would now be factored into the uCDN's 271 decision. dCDNs need not replicate any state to the uCDN - uCDNs 272 could effectively operate in a stateless mode. 274 The semantics of both footprint and capability advertisement depend 275 on the service model here: are there cases where a synchronous query/ 276 response model would work better for the uCDN decision than a state 277 replication model? 279 2.4. Avoiding or Handling 'cheating' dCDNs 281 In a situation where more than one dCDN is willing to serve a given 282 end user request, it might be attractive for a dCDN to 'cheat' in the 283 sense that the dCDN provides inaccurate information to the uCDN in 284 order to convince the uCDN to select it opposed to 'competing' dCDNs. 285 It could therefore be desirable to take away the incentive for dCDNs 286 to cheat (in information advertised) as much as possible. One option 287 here is to make the information the dCDN advertises somehow 288 verifiable for the uCDN. One the other hand, a cheating dCDN might 289 be avoided or handled by the fact that there will be strong 290 contractual agreements between a uCDN and a dCDN, so that a dCDN 291 would risk severe penalties or legal consequences when caught 292 cheating. 294 Overall, it seems that information a dCDN advertises should (in the 295 long run) be somehow qualitatively verifiable by the uCDN, though 296 possibly through non-real-time out-of-band audits. It is probably an 297 overly strict requirement to mandate that such verification be 298 possible "immediately", i.e. during the request routing process 299 itself. If the uCDN can detect a cheating dCDN at a later stage, it 300 should suffice for the uCDN to "de-incentivize" cheating because it 301 would negatively affect the long-term business relationship with a 302 particular dCDN. 304 2.5. Focus on Main Use Cases may Simplify Things 306 To narrow down semantics for "footprint" and "capabilities" in the 307 CDNI context, it can be useful to initially focus on key use cases to 308 be addressed by the CDNI WG that are to be envisioned the main 309 deployments in the foreseeable future. In this regard, a main 310 realistic use case is the existence of ISP-owned CDNs, which 311 essentially cover a certain operator's network. At the same time, 312 however, the possibility of overlapping footprints should not be 313 excluded, i.e. the scenario where more than one dCDN claims it can 314 serve a given end user request. The ISPs may also choose to federate 315 with a fallback global CDN. 317 It seems reasonable to assume that in most use cases it is the uCDN 318 that makes the decision on selecting a certain dCDN for request 319 routing based on information the uCDN has received from this 320 particular dCDN. It may be assumed that 'cheating' CDNs will be 321 dealt with via means outside the scope of CDNI and that the 322 information advertised between CDNs is accurate. In addition, 323 excluding the use of qualitative information (e.g., cache proximity, 324 delivery latency, cache load) to predict the quality of delivery 325 would further simplify the use case allowing it to better focus on 326 the basic functionality of the FCI. 328 3. Main Use Case to Consider 329 Focusing on a main use case that contains a simple (yet somewhat 330 challenging), realistic, and generally imaginable scenario can help 331 in narrowing down the requirements for the CDNI FCI. To this end, 332 the following (simplified) use case can help in clarifying the 333 semantics of footprint and capabilities for CDNI. In particular, the 334 intention of the use case is to clarify what information needs to be 335 exchanged on the CDNI FCI, what types of information need to be 336 supported in a mandatory fashion (and which should be considered 337 optional), and what types of information need to be updated with 338 respect to a priori established CDNI contracts. 340 In short, one can imagine the following use case: A given uCDN has 341 several dCDNs. It selects one dCDN for delivery protocol A and 342 footprint 1 and another dCDN for delivery protocol B and footprint 1. 343 The dCDN that serves delivery protocol B has a further, transitive 344 (level-2) dCDN, that serves delivery protocol B in a subset of 345 footprint 1 where the first-level dCDN cannot serve delivery protocol 346 B itself. What happens if capabilities change in the transitive 347 level-2 dCDN that might affect how the uCDN selects a level-1 dCDN 348 (e.g. in case the level-2 dCDN cannot serve delivery protocol B 349 anymore)? How will these changes be conveyed to the uCDN? In 350 particular, what information does the uCDN need to be able to select 351 a new first-level dCDN, either for all of footprint 1 or only for the 352 subset of footprint 1 that the transitive level-2 dCDN served on 353 behalf of the first-level dCDN? 355 4. Semantics for Footprint Advertisement 357 Roughly speaking, "footprint" can be defined as "ability and 358 willingness to serve" by a downstream CDN. However, in addition to 359 simple "ability and willingness to serve", the uCDN may wish to have 360 additional information to make a dCDN selection decision, e.g., "how 361 well" a given dCDN can actually serve a given end user request. The 362 "ability and willingness" to serve should be distinguished from the 363 subjective qualitative measurement of "how well" it was served. One 364 can imagine that such additional information is implicitly associated 365 with a given footprint, e.g. due to contractual agreements (e.g. 366 SLAs), business relationships, or perceived dCDN quality in the past. 367 As an alternative, such additional information could also be 368 explicitly tagged along with the footprint. 370 It is reasonable to assume that a significant part of the actual 371 footprint advertisement will happen in contractual agreements between 372 participating CDNs, i.e. prior to the advertisement phase using the 373 CDNI FCI. The reason for this assumption is that any contractual 374 agreement is likely to contain specifics about the dCDN coverage 375 (i.e. the dCDN footprint) the contractual agreement applies to. In 376 particular, additional information to judge the delivery quality 377 associated with a given dCDN footprint might be defined in 378 contractual agreements (i.e. outside of the CDNI FCI). Further, one 379 can assume that dCDN contractual agreements about the delivery 380 quality associated with a given footprint will probably be based on 381 high-level aggregated statistics (i.e. not too detailed). 383 Given that a large part of footprint advertisement will actually 384 happen in contractual agreements, the semantics of CDNI footprint 385 advertisement refer to answering the following question: what exactly 386 still needs to be advertised by the CDNI FCI? For instance, updates 387 about temporal failures of part of a footprint can be useful 388 information to convey via the CDNI request routing interface. Such 389 information would provide updates on information previously agreed in 390 contracts between the participating CDNs. In other words, the CDNI 391 FCI is a means for a dCDN to provide changes/updates regarding a 392 footprint it has prior agreed to serve in a contract with a uCDN. 394 Generally speaking, one can imagine two categories of footprint to be 395 advertised by a dCDN: 397 o Footprint could be defined based on "coverage/reachability", where 398 coverage/reachability refers to a set of prefixes, a geographic 399 region, or similar boundary. The dCDN claims that it can cover/ 400 reach 'end user requests coming from this footprint'. 402 o Footprint could be defined based on "resources", where resources 403 refers to surrogates/caches a dCDN claims to have (e.g., the 404 location of surrogates/resources). The dCDN claims that 'from 405 this footprint' it can serve incoming end user requests. 407 For each of these footprint types, there are capabilities associated 408 with a given footprint, i.e. the capabilities (e.g., delivery 409 protocol, redirection mode, metadata) supported in the coverage area 410 for a "coverage/reachability" defined footprint, or the capabilities 411 of resources (e.g., delivery protocol, redirection mode, metadata 412 support) for a "resources" defined footprint. 414 It seems clear that "coverage/reachability" types of footprint must 415 be supported within CDNI. The following such types of footprint are 416 mandatory and must be supported by the CDNI FCI: 418 o List of ISO Country Codes 420 o List of AS numbers 422 o Set of IP-prefixes 423 A 'set of IP-prefixes' must be able to contain full IP addresses, 424 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes with 425 an arbitrary prefix length. There must also be support for multiple 426 IP address versions, i.e., IPv4 and IPv6, in such a footprint. 428 For all of these mandatory-to-implement footprint types, footprints 429 can be viewed as constraints for delegating requests to a dCDN: A 430 dCDN footprint advertisement tells the uCDN the limitations for 431 delegating a request to the dCDN. For IP prefixes or ASN(s), the 432 footprint signals to the uCDN that it should consider the dCDN a 433 candidate only if the IP address of the request routing source falls 434 within the prefix set (or ASN, respectively). The CDNI 435 specifications do not define how a given uCDN determines what address 436 ranges are in a particular ASN. Similarly, for country codes a uCDN 437 should only consider the dCDN a candidate if it covers the country of 438 the request routing source. The CDNI specifications do not define 439 how a given uCDN determines the country of the request routing 440 source. Multiple footprint constraints are additive, i.e. the 441 advertisement of different types of footprint narrows the dCDN 442 candidacy cumulatively. 444 It addition to these mandatory "coverage/reachability" types of 445 footprint, other optional "coverage/reachability" types of footprint 446 or "resource" types of footprint may defined by future 447 specifications. To facilitate this, a clear process for specifying 448 optional footprint types in a IANA registry must be specified. This 449 includes the specification of the level of oversight necessary (e.g. 450 WG decision or expert review) for adding new optional footprints to a 451 IANA registry as well as the specification of a template regarding 452 design choices that must be captured by new optional types of 453 footprints. 455 Independent of the exact type of a footprint, a footprint might also 456 include the connectivity of a given dCDN to other CDNs that may be 457 able to serve content to users on behalf of that dCDN, to cover cases 458 where there is a transitive CDN interconnection. Further, the 459 downstream CDN must be able to express its footprint to an interested 460 upstream CDN (uCDN) in a comprehensive form, e.g., as a complete data 461 set containing the complete footprint. Making incremental updates, 462 however, to express dynamic changes in state is also desirable. 464 5. Semantics for Capabilities Advertisement 466 In general, the dCDN must be able to express its general capabilities 467 to the uCDN. These general capabilities could express if the dCDN 468 supports a given service, for instance, HTTP delivery, RTP/RTSP 469 delivery or RTMP. Furthermore, the dCDN must be able to express 470 particular capabilities for the delivery in a particular footprint 471 area. For example, the dCDN might in general offer RTMP but not in 472 some specific areas, either for maintenance reasons or because the 473 caches covering this particular area cannot deliver this type of 474 service. Hence, in certain cases footprint and capabilities are tied 475 together and cannot be interpreted independently from each other. In 476 such cases, i.e. where capabilities must be expressed on a per 477 footprint basis, it may be beneficial to combine footprint and 478 capabilities advertisement. 480 A high-level and very rough semantic for capabilities is thus the 481 following: Capabilities are types of information that allow a uCDN to 482 determine if a downstream CDN is able (and willing) to accept (and 483 properly handle) a delegated content request. In addition, 484 Capabilities are characterized by the fact that this information may 485 possibly change over time based on the state of the network or 486 caches. 488 At a first glance, several broad categories of capabilities seem 489 useful to convey via an advertisement interface, however, advertising 490 capabilities that change highly dynamically (e.g. real-time delivery 491 performance metrics, CDN resource load, or other highly dynamically 492 changing QoS information) should probably not be in scope for the 493 CDNI FCI. First, out of the multitude of possible metrics and 494 capabilities, it is hard to agree on a subset and the precise metrics 495 to be used. Second, and perhaps more importantly, it seems not 496 feasible to specify such highly dynamically changing capabilities and 497 the corresponding metrics within the CDNI charter time-frame. 499 Useful capabilities refer to information that does not change highly 500 dynamically and which in many cases is absolutely necessary to decide 501 on a particular dCDN for a given end user request. For instance, if 502 an end user request concerns the delivery of a video file with a 503 certain protocol (e.g. RTMP), the uCDN needs to know if a given dCDN 504 has the capabilitity of supporting this delivery protocol. 506 Similar to footprint advertisement, it is reasonable to assume that a 507 significant part of the actual (resource) capabilities advertisement 508 will happen in contractual agreements between participating CDNs, 509 i.e. prior to the advertisement phase using the CDNI FCI. The role 510 of capability advertisement is hence rather to enable the dCDN to 511 update a uCDN on changes since a contract has been set up (e.g. in 512 case a new delivery protocol is suddenly being added to the list of 513 supported delivery protocols of a given dCDN, or in case a certain 514 delivery protocol is suddenly not being supported anymore due to 515 failures). Capabilities advertisement thus refers to conveying 516 information to a uCDN about changes/updates of certain capabilities 517 with respect to a given contract. 519 Given these semantics, it needs to be decided what exact capabilities 520 are useful and how these can be expressed. Since the details of CDNI 521 contracts are not known at the time of this writing (and the CDNI 522 interface should probably be agnostic to these contracts anyway), it 523 remains to be seen what capabilities will be used to define 524 agreements between CDNs in practice. One implication for 525 standardization may be to initially only specify a very limited set 526 of mandatory capabilities for advertisement and have on top of that a 527 flexible data model that allows exchanging additional capabilities 528 when needed. Still, agreement needs to be found on which 529 capabilities (if any) should be mandatory among CDNs. As discussed 530 in Section 2.5, finding the concrete answers to these questions can 531 benefit from focusing on a small number of key use cases that are 532 highly relevant and contain enough complexity to help in 533 understanding what concrete capabilities are needed to facilitate CDN 534 Interconnection. 536 Under the above considerations, the following capabilities seem 537 useful as 'base' capabilities, i.e. ones that are needed in any case 538 and therefore constitute mandatory capabilities to be supported by 539 the CDNI FCI: 541 o Delivery Protocol (e.g., HTTP vs. RTMP) 543 o Acquisition Protocol (for aquiring content from a uCDN) 545 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 546 discussed in [I-D.ietf-cdni-framework]) 548 o Capabilities related to CDNI Logging (e.g., supported logging 549 mechanisms) 551 o Capabilities related to CDNI Metadata (e.g., authorization 552 algorithms or support for proprietary vendor metadata) 554 It is not feasable to enumerate all the possible options for the 555 mandatory capabilities listed above (e.g., all the potential delivery 556 protocols or metadata options) or anticipate all the future needs for 557 additional capabilities. It would be unreasonable to burden the CDNI 558 FCI specification with defining each supported capability. Instead, 559 the CDNI FCI specification should define a generic protocol for 560 conveying any capability information. In this respect, it seems 561 reasonable to define a registry which initially contains the 562 mandatory capabilities listed above, but may be extended as needs 563 dictate. The CDNI FCI specification SHOULD define the registry (and 564 the rules for adding new entries to the registry) for the different 565 capability types. Each capability type MAY further have a list of 566 valid values. The individual CDNI interface specifications which 567 define a given capability SHOULD define any necessary registries (and 568 the rules for adding new entries to the registry) for the values 569 advertised for a given capability type. 571 The mandatory capabilities listed above generally relate to 572 information that is configured on a content asset or group of assets 573 basis via CDNI metadata. The capability requirements for acquisition 574 and delivery protocol and other mandatory metadata capabilities (e.g. 575 authorization algorithms) are defined in [I-D.ietf-cdni-metadata]. 577 Note: CDNI interface support for logging configuration (i.e., control 578 interface vs. metadata interface) has not yet been decided. Once it 579 has been decided, the corresponding CDNI interface specification 580 should define the associated capability requirements. 582 6. Negotiation of Support for Optional Types of Footprint/Capabilities 584 The notion of optional types of footprint and capabilities implies 585 that certain implementations may not support all kinds of footprint 586 and capabilities. Therefore, any FCI solution protocol must define 587 how the support for optional types of footprint/capabilities will be 588 negotiated between a uCDN and a dCDN that use the particular FCI 589 protocol. In particular, any FCI solution protocol needs to specify 590 how to handle failure cases or non-supported types of footprint/ 591 capabilities. 593 In general, a uCDN may ignore capabilities or types of footprint it 594 does not understand; in this case it only selects a suitable 595 downstream CDN based on the types of capabilities and footprint it 596 understands. Similarly, if a dCDN does not use an optional 597 capability or footprint which is, however, supported by a uCDN, this 598 causes no problem for the FCI functionality because the uCDN decides 599 on the remaining capabilities/footprint information that is being 600 conveyed by the dCDN. 602 7. IANA Considerations 604 IANA registries are to be used for mandatory and optional types of 605 footprint and capabilities. Therefore, the mandatory types of 606 footprint and capabilities listed in this document (see Section 5) 607 are to be registered with IANA. In order to prevent namespace 608 collisions for capabilities a new IANA registry is requested for the 609 "CDNI Capabilities" namespace. The namespace shall be split into two 610 partitions: standard and vendor defined. As with the CDNI Metadata 611 Interface [I-D.ietf-cdni-metadata], the vendor defined namespace 612 partition SHOULD use a namespace prefix of "ext.", while the standard 613 namespace partition MUST NOT. 615 The standard namespace partition MUST conform to the "RFC Required" 616 policy as defined in [RFC5226]. The vendor defined namespace 617 partition should be further partitioned into vendor specific 618 partitions with the prefix "ext.vendor_name.". The vendor defined 619 partition SHOULD conform to the "Expert Review" policy as defined in 620 [RFC5226]. The expert review is simply to prevent namespace 621 hoarding. The vendor specific partitions MAY conform to the "First 622 Come First Served" policy as defined in [RFC5226], however, vendors 623 defining new capabilities which conflict with existing capabilities 624 SHOULD follow the guidelines for the "Specification Required" policy 625 as defined in [RFC5226]. 627 The following table defines the initial capabilities for the standard 628 partition: 630 +----------------------+---------------+ 631 | capability | Specification | 632 +----------------------+---------------+ 633 | Delivery Protocol | RFCthis | 634 | | | 635 | Acquisition Protocol | RFCthis | 636 | | | 637 | Redirection Mode | RFCthis | 638 +----------------------+---------------+ 640 Additional capabilities specific to the CDNI Metadata Interface 641 [I-D.ietf-cdni-metadata] and the CDNI Logging Interface 642 [I-D.ietf-cdni-metadata] SHALL be addressed separately by those 643 documents. 645 7.1. Footprint Sub-Registry 647 The "CDNI Metadata Footprint Types" namespace defined in the CDNI 648 Metadata Interface document [I-D.ietf-cdni-metadata] contains the 649 supported footprint formats for use in footprint advertisement. No 650 further IANA action is required here. 652 7.2. Protocol Sub-Registry 654 The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata 655 Interface document [I-D.ietf-cdni-metadata] contains the supported 656 protocol values for the Delivery Protocol and Acquisition Protocol 657 capabilities. No further IANA action is required here. 659 7.3. Redirection Mode Sub-Registry 660 The "CDNI Capabilities Redirection Modes" namespace defines the valid 661 redirection modes that may be advertised as supported by a CDN. 662 Additions to the Redirection Mode namespace MUST conform to the 663 "Expert Review" policy as defined in [RFC5226]. The expert review 664 should verify that new type definitions do not duplicate existing 665 type definitions and prevent gratuitous additions to the namespace. 666 For new Redirection Modes which apply to new standard protocols, it 667 is recommended that registration requests follow the "RFC Required" 668 policy as defined in [RFC5226]. 670 The following table defines the initial Redirection Modes: 672 +------------------+----------------------------------+ 673 | Redirection Mode | definition | 674 +------------------+----------------------------------+ 675 | DNS-I | Iterative DNS-based Redirection | 676 | | | 677 | DNS-R | Recursive DNS-based Redirection | 678 | | | 679 | HTTP-I | Iterative HTTP-based Redirection | 680 | | | 681 | HTTP-R | Recursive HTTP-based Redirection | 682 +------------------+----------------------------------+ 684 8. Security Considerations 686 Security considerations will be discussed in a future version of this 687 document. 689 9. References 691 9.1. Normative References 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, March 1997. 696 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 697 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 698 May 2008. 700 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 701 Distribution Network Interconnection (CDNI) Problem 702 Statement", RFC 6707, September 2012. 704 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 705 K., and G. Watson, "Use Cases for Content Delivery Network 706 Interconnection", RFC 6770, November 2012. 708 9.2. Informative References 710 [I-D.ietf-cdni-framework] 711 Peterson, L. and B. Davie, "Framework for CDN 712 Interconnection", draft-ietf-cdni-framework-06 (work in 713 progress), October 2013. 715 [I-D.ietf-cdni-logging] 716 Faucheur, F., Bertrand, G., Oprescu, I., and R. 717 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 718 logging-08 (work in progress), October 2013. 720 [I-D.ietf-cdni-metadata] 721 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 722 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 723 ietf-cdni-metadata-02 (work in progress), July 2013. 725 [I-D.ietf-cdni-requirements] 726 Leung, K. and Y. Lee, "Content Distribution Network 727 Interconnection (CDNI) Requirements", draft-ietf-cdni- 728 requirements-10 (work in progress), September 2013. 730 Appendix A. Acknowledgment 732 Jan Seedorf is partially supported by the CHANGE project (CHANGE: 733 Enabling Innovation in the Internet Architecture through Flexible 734 Flow-Processing Extensions, http://www.change-project.eu/), a 735 research project supported by the European Commission under its 7th 736 Framework Program (contract no. 257422). The views and conclusions 737 contained herein are those of the authors and should not be 738 interpreted as necessarily representing the official policies or 739 endorsements, either expressed or implied, of the CHANGE project or 740 the European Commission. 742 Jan Seedorf has been partially supported by the COAST project 743 (COntent Aware Searching, retrieval and sTreaming, http://www.coast- 744 fp7.eu), a research project supported by the European Commission 745 under its 7th Framework Program (contract no. 248036). The views and 746 conclusions contained herein are those of the authors and should not 747 be interpreted as necessarily representing the official policies or 748 endorsements, either expressed or implied, of the COAST project or 749 the European Commission. 751 Martin Stiemerling provided initial input to this document and 752 valuable comments to the ongoing discussions among the authors of 753 this document. Thanks to Francois Le Faucheur and Scott Wainner for 754 providing valuable comments and suggestions to the text. 756 Authors' Addresses 758 Jan Seedorf 759 NEC 760 Kurfuerstenanlage 36 761 Heidelberg 69115 762 Germany 764 Phone: +49 6221 4342 221 765 Fax: +49 6221 4342 155 766 Email: seedorf@neclab.eu 768 Jon Peterson 769 NeuStar 770 1800 Sutter St Suite 570 771 Concord CA 94520 772 USA 774 Email: jon.peterson@neustar.biz 776 Stefano Previdi 777 Cisco Systems 778 Via Del Serafico 200 779 Rome 0144 780 Italy 782 Email: sprevidi@cisco.com 784 Ray van Brandenburg 785 TNO 786 Brassersplein 2 787 Delft 2612CT 788 The Netherlands 790 Phone: +31-88-866-7000 791 Email: ray.vanbrandenburg@tno.nl 792 Kevin J. Ma 793 Azuki Systems, Inc. 794 43 Nagog Park 795 Acton MA 01720 796 USA 798 Phone: +1 978-844-5100 799 Email: kevin.ma@azukisystems.com