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