idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-semantics-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3333 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-15 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-09 Summary: 2 errors (**), 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: September 10, 2015 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Ericsson 12 March 9, 2015 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-06 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 of "Footprint" and 22 "Capabilities" in the CDNI context, and what the "Footprint and 23 Capabilities Advertisement Interface (FCI)" is expected to offer 24 within CDNI. The document also provides guidelines for a CDNI FCI 25 protocol. It further defines a Base Advertisement Object, the 26 necessary registries for capabilities and footprints, and guidelines 27 how these registries may be extended in the future. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 10, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 69 2. Design Decisions for Footprint and Capabilities . . . . . . . 4 70 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 71 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 72 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 73 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 74 2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7 75 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 76 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 77 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 78 6. Negotiation of Support for Optional Types of 79 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 80 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 81 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 82 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15 83 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 84 7.4. Redirection Mode Capability Object . . . . . . . . . . . 15 85 7.5. Capability Advertisement Object Serialization . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 10.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction and Scope 97 The CDNI working group is working on a set of protocols to enable the 98 interconnection of multiple CDNs to a CDN federation. This CDN- 99 federation should serve multiple purposes, as discussed in [RFC6770], 100 for instance, to extend the reach of a given CDN to areas in the 101 network which are not covered by this particular CDN. 103 The goal of this document is to achieve a clear understanding about 104 the semantics associated with the CDNI Request Routing Footprint & 105 Capabilities Advertisement Interface (from now on referred to as 106 FCI), in particular the type of information a downstream CDN 107 'advertises' regarding its footprint and capabilities. To narrow 108 down undecided aspects of these semantics, this document tries to 109 establish a common understanding of what the FCI should offer and 110 accomplish in the context of CDN Interconnection. 112 It is explicitly outside the scope of this document to decide on 113 specific protocols to use for the FCI. However, guidelines for such 114 FCI protocols are provided. 116 General assumptions in this document: 118 o The CDNs participating in the CDN federation have already 119 performed a boot strap process, i.e., they have connected to each 120 other, either directly or indirectly, and can exchange information 121 amongst each other. 123 o The uCDN has received footprint and/or capability advertisements 124 from a set of dCDNs. Footprint advertisement and capability 125 advertisement need not use the same underlying protocol. 127 o The upstream CDN (uCDN) receives the initial request-routing 128 request from the endpoint requesting the resource. 130 The CDNI Problem Statement [RFC6707] describes footprint and 131 capabilities advertisement as: "[enabling] a Request Routing function 132 in an Upstream CDN to query a Request Routing function in a 133 Downstream CDN to determine if the Downstream CDN is able (and 134 willing) to accept the delegated Content Request". In addition, the 135 RFC says "the CDNI Request Routing interface is also expected to 136 enable a downstream CDN to provide to the upstream CDN (static or 137 dynamic) information (e.g., resources, footprint, load) to facilitate 138 selection of the downstream CDN by the upstream CDN request routing 139 system when processing subsequent content requests from User Agents". 140 It thus considers "resources" and "load" as capabilities to be 141 advertised by the downstream CDN. 143 The range of different footprint definitions and possible 144 capabilities is very broad. Attempting to define a comprehensive 145 advertisement solution quickly becomes intractable. The CDNI 146 requirements draft [RFC7337] lists the specific requirements for the 147 CDNI Footprint & Capabilities Advertisement Interface in order to 148 disambiguate footprints and capabilities with respect to CDNI. This 149 document attempts to distill the apparent common understanding of 150 what the terms 'footprint' and 'capabilities' mean in the context of 151 CDNI, and detail the semantics of the footprint advertisement 152 mechanism and the capability advertisement mechanism. 154 2. Design Decisions for Footprint and Capabilities 156 A large part of the difficulty in discussing the FCI lies in 157 understanding what exactly is meant when trying to define footprint 158 in terms of "coverage" or "reachability." While the operators of 159 CDNs pick strategic locations to situate caches, a cache with a 160 public IPv4 address is reachable by any endpoint on the Internet 161 unless some policy enforcement precludes the use of the cache. 163 Some CDNs aspire to cover the entire world, which we will henceforth 164 call global CDNs. The footprint advertised by such a CDN in the CDNI 165 environment would, from a coverage or reachability perspective, 166 presumably cover all prefixes. Potentially more interesting for CDNI 167 use cases, however, are CDNs that claim a more limited coverage, but 168 seek to federate with other CDNs in order to create a single CDN 169 fabric which shares resources. 171 Futhermore, not all capabilities need be footprint restricted. 172 Depending upon the use case, the optimal semantics of "footprints 173 with capability attributes" vs. "capabilities with footprint 174 restrictions" are not clear. 176 The key to understanding the semantics of footprint and capability 177 advertisement lies in understand why a dCDN would advertise a limited 178 coverage area, and how a uCDN would use such advertisements to decide 179 among one of several dCDNs. The following section will discuss some 180 of the trade-offs and design decisions that need to be decided upon 181 for the CDNI FCI. 183 2.1. Advertising Limited Coverage 185 The basic use case that would motivate a dCDN to advertise a limited 186 coverage is that the CDN was built to cover only a particular portion 187 of the Internet. For example, an ISP could purpose-build a CDN to 188 serve only their own customers by situating caches in close 189 topological proximity to high concentrations of their subscribers. 190 The ISP knows the prefixes it has allocated to end users and thus can 191 easily construct a list of prefixes that its caches were positioned 192 to serve. 194 When such a purpose-built CDN joins a federation, however, and 195 advertises its footprint to a uCDN, the original intended coverage of 196 the CDN might not represent its actual value to the federation of 197 CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, 198 which they federate through CDNI. A given user E, who is customer of 199 ISP-B, might happen to be topologically closest to a cache fielded by 200 ISP-A, if E happens to live in a region where ISP-B has few customers 201 and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If 202 ISP-B's CDN has a failure condition, should the uCDN understand that 203 ISP-A's caches are potentially available back-ups - and if so, how 204 does ISP-A advertise itself as a "standby" for E? What about the 205 case where CDNs advertising to the same uCDN express overlapping 206 coverage (for example, a federation mixing global and limited CDNs)? 208 The answers to these questions greatly depend on how much information 209 we want the uCDN to use to make a selection of a dCDN. If a uCDN has 210 three dCDNs to choose from that "cover" the IP address of user E, 211 obviously the uCDN might be interested to know how optimal the 212 coverage is from each of the dCDNs - coverage need not be binary, 213 either provided or not provided. dCDNs could advertise a coverage 214 "score," for example, and provided that they all reported scores 215 fairly on the same scale, uCDNs could use that to make their 216 topological optimality decision. Alternatively, dCDNs could for 217 their footprint advertise the IP addresses of their caches rather 218 than prefix "coverage," and let the uCDN decide for itself (based on 219 its own topological intelligence) which dCDN has better resources to 220 serve a given user. 222 In summary, the semantics of advertising footprint depend on whether 223 such qualitative metrics for expressing footprint (such as the 224 coverage 'score' mentioned above) should be part of the CDNI FCI, or 225 if it should focus just on 'binary' footprint. 227 2.2. Capabilities and Dynamic Data 229 In cases where the apparent footprint of dCDNs overlaps, uCDNs might 230 also want to rely on a host of other factors to evaluate the 231 respective merits of dCDNs. These include facts related to the 232 caches themselves, to the network where the cache is deployed, to the 233 nature of the resource sought and to the administrative policies of 234 the respective networks. 236 In the absence of network-layer impediments to reaching caches, the 237 choice to limit coverage is necessarily an administrative policy. 238 Much policy must be agreed upon before CDNs can merge into 239 federations, including questions of membership, compensation, volumes 240 and so on. A uCDN certainly will factor these sorts of 241 considerations into its decision to select a dCDN, but there is 242 probably little need for dCDNs to actually advertise them through an 243 interface - they will be settled out of band as a precondition for 244 federating. 246 Other facts about the dCDN would be expressed through the interface 247 to the uCDN. Some capabilities of a dCDN are static, and some are 248 highly dynamic. Expressing the total storage built into its caches, 249 for example, changes relatively rarely, whereas the amount of storage 250 in use at any given moment is highly volatile. Network bandwidth 251 similarly could be expressed as either total bandwidth available to a 252 cache, or based on the current state of the network. A cache may at 253 one moment lack a particular resource in storage, but have it the 254 next. 256 The semantics of the capabilities interface will depend on how much 257 of the dCDN state needs to be pushed to the uCDN and qualitatively 258 how often that information should be updated. 260 2.3. Advertisement versus Queries 262 In a federated CDN environment, each dCDN shares some of its state 263 with the uCDN, which the uCDN uses to build a unified picture of all 264 of the dCDNs available to it. In architectures that share detailed 265 capability information, the uCDN could basically perform the entire 266 request-routing intelligence down to selecting a particular cache 267 before sending the request to the dCDN (note that within the current 268 CDNI WG scope, such direct selection of specific caches by the uCDN 269 is out of scope). However, when the uCDN must deal with many 270 potential dCDNs, this approach does not scale. Especially as CDNs 271 scale up from dozens or hundreds of caches to thousands or tens of 272 thousands, the volume of updates to footprint and capability may 273 become onerous. 275 Were the volume of updates to exceed the volumes of requests to the 276 uCDN, it might make more sense for the uCDN to query dCDNs upon 277 receiving requests (as is the case in the recursive redirection mode 278 described in [RFC7336]), instead of receiving advertisements and 279 tracking the state of dCDNs itself. The advantage of querying dCDNs 280 would be that much of the dynamic data that dCDNs cannot share with 281 the uCDN would now be factored into the uCDN's decision. dCDNs need 282 not replicate any state to the uCDN - uCDNs could effectively operate 283 in a stateless mode. 285 The semantics of both footprint and capability advertisement depend 286 on the service model here: are there cases where a synchronous query/ 287 response model would work better for the uCDN decision than a state 288 replication model? 290 2.4. Avoiding or Handling 'cheating' dCDNs 292 In a situation where more than one dCDN is willing to serve a given 293 end user request, it might be attractive for a dCDN to 'cheat' in the 294 sense that the dCDN provides inaccurate information to the uCDN in 295 order to convince the uCDN to select it opposed to 'competing' dCDNs. 296 It could therefore be desirable to take away the incentive for dCDNs 297 to cheat (in information advertised) as much as possible. One option 298 here is to make the information the dCDN advertises somehow 299 verifiable for the uCDN. One the other hand, a cheating dCDN might 300 be avoided or handled by the fact that there will be strong 301 contractual agreements between a uCDN and a dCDN, so that a dCDN 302 would risk severe penalties or legal consequences when caught 303 cheating. 305 Overall, it seems that information a dCDN advertises should (in the 306 long run) be somehow qualitatively verifiable by the uCDN, though 307 possibly through non-real-time out-of-band audits. It is probably an 308 overly strict requirement to mandate that such verification be 309 possible "immediately", i.e., during the request routing process 310 itself. If the uCDN can detect a cheating dCDN at a later stage, it 311 should suffice for the uCDN to "de-incentivize" cheating because it 312 would negatively affect the long-term business relationship with a 313 particular dCDN. 315 2.5. Focusing on Main Use Cases 317 To narrow down semantics for "footprint" and "capabilities" in the 318 CDNI context, it can be useful to initially focus on key use cases to 319 be addressed by the CDNI WG that are to be envisioned the main 320 deployments in the foreseeable future. In this regard, a main 321 realistic use case is the existence of ISP-owned CDNs, which 322 essentially cover a certain operator's network. At the same time, 323 however, the possibility of overlapping footprints should not be 324 excluded, i.e., the scenario where more than one dCDN claims it can 325 serve a given end user request. The ISPs may also choose to federate 326 with a fallback global CDN. 328 It seems reasonable to assume that in most use cases it is the uCDN 329 that makes the decision on selecting a certain dCDN for request 330 routing based on information the uCDN has received from this 331 particular dCDN. It may be assumed that 'cheating' CDNs will be 332 dealt with via means outside the scope of CDNI and that the 333 information advertised between CDNs is accurate. In addition, 334 excluding the use of qualitative information (e.g., cache proximity, 335 delivery latency, cache load) to predict the quality of delivery 336 would further simplify the use case allowing it to better focus on 337 the basic functionality of the FCI. 339 3. Main Use Case to Consider 341 Focusing on a main use case that contains a simple (yet somewhat 342 challenging), realistic, and generally imaginable scenario can help 343 in narrowing down the requirements for the CDNI FCI. To this end, 344 the following (simplified) use case can help in clarifying the 345 semantics of footprint and capabilities for CDNI. In particular, the 346 intention of the use case is to clarify what information needs to be 347 exchanged on the CDNI FCI, what types of information need to be 348 supported in a mandatory fashion (and which should be considered 349 optional), and what types of information need to be updated with 350 respect to a priori established CDNI contracts. 352 In short, one can imagine the following use case: A given uCDN has 353 several dCDNs. It selects one dCDN for delivery protocol A and 354 footprint 1 and another dCDN for delivery protocol B and footprint 1. 355 The dCDN that serves delivery protocol B has a further, transitive 356 (level-2) dCDN, that serves delivery protocol B in a subset of 357 footprint 1 where the first-level dCDN cannot serve delivery protocol 358 B itself. What happens if capabilities change in the transitive 359 level-2 dCDN that might affect how the uCDN selects a level-1 dCDN 360 (e.g., in case the level-2 dCDN cannot serve delivery protocol B 361 anymore)? How will these changes be conveyed to the uCDN? In 362 particular, what information does the uCDN need to be able to select 363 a new first-level dCDN, either for all of footprint 1 or only for the 364 subset of footprint 1 that the transitive level-2 dCDN served on 365 behalf of the first-level dCDN? 367 4. Semantics for Footprint Advertisement 369 Roughly speaking, "footprint" can be defined as "ability and 370 willingness to serve" by a downstream CDN. However, in addition to 371 simple "ability and willingness to serve", the uCDN may wish to have 372 additional information to make a dCDN selection decision, e.g., "how 373 well" a given dCDN can actually serve a given end user request. The 374 "ability and willingness" to serve should be distinguished from the 375 subjective qualitative measurement of "how well" it was served. One 376 can imagine that such additional information is implicitly associated 377 with a given footprint, e.g., due to contractual agreements (e.g., 378 SLAs), business relationships, or perceived dCDN quality in the past. 379 As an alternative, such additional information could also be 380 explicitly tagged along with the footprint. 382 It is reasonable to assume that a significant part of the actual 383 footprint advertisement will happen in contractual agreements between 384 participating CDNs, i.e., prior to the advertisement phase using the 385 CDNI FCI. The reason for this assumption is that any contractual 386 agreement is likely to contain specifics about the dCDN coverage 387 (i.e., the dCDN footprint) to which the contractual agreement 388 applies. In particular, additional information to judge the delivery 389 quality associated with a given dCDN footprint might be defined in 390 contractual agreements (i.e. outside of the CDNI FCI). Further, one 391 can assume that dCDN contractual agreements about the delivery 392 quality associated with a given footprint will probably be based on 393 high-level aggregated statistics (i.e., not too detailed). 395 Given that a large part of footprint advertisement will actually 396 happen in contractual agreements, the semantics of CDNI footprint 397 advertisement refer to answering the following question: what exactly 398 still needs to be advertised by the CDNI FCI? For instance, updates 399 about temporal failures of part of a footprint can be useful 400 information to convey via the CDNI request routing interface. Such 401 information would provide updates on information previously agreed in 402 contracts between the participating CDNs. In other words, the CDNI 403 FCI is a means for a dCDN to provide changes/updates regarding a 404 footprint it has prior agreed to serve in a contract with a uCDN. 406 Generally speaking, one can imagine two categories of footprint to be 407 advertised by a dCDN: 409 o Footprint could be defined based on "coverage/reachability", where 410 coverage/reachability refers to a set of prefixes, a geographic 411 region, or similar boundary. The dCDN claims that it can cover/ 412 reach 'end user requests coming from this footprint'. 414 o Footprint could be defined based on "resources", where resources 415 refers to surrogates/caches a dCDN claims to have (e.g., the 416 location of surrogates/resources). The dCDN claims that 'from 417 this footprint' it can serve incoming end user requests. 419 For each of these footprint types, there are capabilities associated 420 with a given footprint, i.e., the capabilities (e.g., delivery 421 protocol, redirection mode, metadata) supported in the coverage area 422 for a "coverage/reachability" defined footprint, or the capabilities 423 of resources (e.g., delivery protocol, redirection mode, metadata 424 support) for a "resources" defined footprint. 426 It seems clear that "coverage/reachability" types of footprint must 427 be supported within CDNI. The following such types of footprint are 428 mandatory and must be supported by the CDNI FCI: 430 o List of ISO Country Codes 432 o List of AS numbers 434 o Set of IP-prefixes 436 A 'set of IP-prefixes' must be able to contain full IP addresses, 437 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes with 438 an arbitrary prefix length. There must also be support for multiple 439 IP address versions, i.e., IPv4 and IPv6, in such a footprint. 441 "Resource" types of footprints are more specific than "coverage/ 442 reachability" types of footprints, where the actual coverage/ 443 reachability are extrapolated from the resource location (e.g., 444 netmask applied to resource IP address to derive IP-prefix). The 445 specific methods for extrapolating coverage/reachability from 446 resource location are beyond the scope of this document. In the 447 degenerate case, the resource address could be specified as a 448 coverage/reachability type of footprint, in which case no 449 extrapolation is necessary. Resource types of footprints may expose 450 the internal structure of a CDN network which may be undesirable. As 451 such, the resource types of footprints are not considered mandatory 452 to support for CDNI. 454 For all of these mandatory-to-implement footprint types, footprints 455 can be viewed as constraints for delegating requests to a dCDN: A 456 dCDN footprint advertisement tells the uCDN the limitations for 457 delegating a request to the dCDN. For IP prefixes or ASN(s), the 458 footprint signals to the uCDN that it should consider the dCDN a 459 candidate only if the IP address of the request routing source falls 460 within the prefix set (or ASN, respectively). The CDNI 461 specifications do not define how a given uCDN determines what address 462 ranges are in a particular ASN. Similarly, for country codes a uCDN 463 should only consider the dCDN a candidate if it covers the country of 464 the request routing source. The CDNI specifications do not define 465 how a given uCDN determines the country of the request routing 466 source. Multiple footprint constraints are additive, i.e., the 467 advertisement of different types of footprint narrows the dCDN 468 candidacy cumulatively. 470 In addition to these mandatory "coverage/reachability" types of 471 footprint, other optional "coverage/reachability" types of footprint 472 or "resource" types of footprint may defined by future 473 specifications. To facilitate this, a clear process for specifying 474 optional footprint types in a IANA registry is specified in 475 Section 8. This includes the specification of the level of oversight 476 necessary (e.g., WG decision or expert review) for adding new 477 optional footprints to a IANA registry as well as the specification 478 of a template regarding design choices that must be captured by new 479 optional types of footprints. 481 Independent of the exact type of a footprint, a footprint might also 482 include the connectivity of a given dCDN to other CDNs that may be 483 able to serve content to users on behalf of that dCDN, to cover cases 484 where there is a transitive CDN interconnection. Further, the 485 downstream CDN must be able to express its footprint to an interested 486 upstream CDN (uCDN) in a comprehensive form, e.g., as a data set 487 containing the complete footprint. Making incremental updates, 488 however, to express dynamic changes in state is also desirable. 490 5. Semantics for Capabilities Advertisement 492 In general, the dCDN must be able to express its general capabilities 493 to the uCDN. These general capabilities could express if the dCDN 494 supports a given service, for instance, HTTP delivery, RTP/RTSP 495 delivery or RTMP. Furthermore, the dCDN must be able to express 496 particular capabilities for the delivery in a particular footprint 497 area. For example, the dCDN might in general offer RTMP but not in 498 some specific areas, either for maintenance reasons or because the 499 caches covering this particular area cannot deliver this type of 500 service. Hence, in certain cases footprint and capabilities are tied 501 together and cannot be interpreted independently from each other. In 502 such cases, i.e., where capabilities must be expressed on a per 503 footprint basis, it may be beneficial to combine footprint and 504 capabilities advertisement. 506 A high-level and very rough semantic for capabilities is thus the 507 following: Capabilities are types of information that allow a uCDN to 508 determine if a downstream CDN is able (and willing) to accept (and 509 properly handle) a delegated content request. In addition, 510 Capabilities are characterized by the fact that this information may 511 possibly change over time based on the state of the network or 512 caches. 514 At a first glance, several broad categories of capabilities seem 515 useful to convey via an advertisement interface, however, advertising 516 capabilities that change highly dynamically (e.g., real-time delivery 517 performance metrics, CDN resource load, or other highly dynamically 518 changing QoS information) should probably not be in scope for the 519 CDNI FCI. First, out of the multitude of possible metrics and 520 capabilities, it is hard to agree on a subset and the precise metrics 521 to be used. Second, and perhaps more importantly, it seems not 522 feasible to specify such highly dynamically changing capabilities and 523 the corresponding metrics within the CDNI charter time-frame. 525 Useful capabilities refer to information that does not change highly 526 dynamically and which in many cases is absolutely necessary to decide 527 on a particular dCDN for a given end user request. For instance, if 528 an end user request concerns the delivery of a video file with a 529 certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN 530 has the capabilitity of supporting this delivery protocol. 532 Similar to footprint advertisement, it is reasonable to assume that a 533 significant part of the actual (resource) capabilities advertisement 534 will happen in contractual agreements between participating CDNs, 535 i.e. prior to the advertisement phase using the CDNI FCI. The role 536 of capability advertisement is hence rather to enable the dCDN to 537 update a uCDN on changes since a contract has been set up (e.g., in 538 case a new delivery protocol is suddenly being added to the list of 539 supported delivery protocols of a given dCDN, or in case a certain 540 delivery protocol is suddenly not being supported anymore due to 541 failures). Capabilities advertisement thus refers to conveying 542 information to a uCDN about changes/updates of certain capabilities 543 with respect to a given contract. 545 Given these semantics, it needs to be decided what exact capabilities 546 are useful and how these can be expressed. Since the details of CDNI 547 contracts are not known at the time of this writing (and the CDNI 548 interface should probably be agnostic to these contracts anyway), it 549 remains to be seen what capabilities will be used to define 550 agreements between CDNs in practice. One implication for 551 standardization may be to initially only specify a very limited set 552 of mandatory capabilities for advertisement and have on top of that a 553 flexible data model that allows exchanging additional capabilities 554 when needed. Still, agreement needs to be found on which 555 capabilities (if any) should be mandatory among CDNs. As discussed 556 in Section 2.5, finding the concrete answers to these questions can 557 benefit from focusing on a small number of key use cases that are 558 highly relevant and contain enough complexity to help in 559 understanding what concrete capabilities are needed to facilitate CDN 560 Interconnection. 562 Under the above considerations, the following capabilities seem 563 useful as 'base' capabilities, i.e., ones that are needed in any case 564 and therefore constitute mandatory capabilities to be supported by 565 the CDNI FCI: 567 o Delivery Protocol (e.g., HTTP vs. RTMP) 569 o Acquisition Protocol (for aquiring content from a uCDN) 571 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 572 discussed in [RFC7336]) 574 o CDNI Logging (i.e., supported logging fields) 576 o CDNI Metadata (i.e., supported Generic Metadata types) 578 It is not feasable to enumerate all the possible options for the 579 mandatory capabilities listed above (e.g., all the potential delivery 580 protocols or metadata options) or anticipate all the future needs for 581 additional capabilities. It would be unreasonable to burden the CDNI 582 FCI specification with defining each supported capability. Instead, 583 the CDNI FCI specification should define a generic protocol for 584 conveying any capability information (e.g. with common encoding, 585 error handling, and security mechanism; further requirements for the 586 CDNI FCI Advertisement Interface are listed in [RFC7337]). In this 587 respect, it seems reasonable to define a registry which initially 588 contains the mandatory capabilities listed above, but may be extended 589 as needs dictate. This document defines the registry (and the rules 590 for adding new entries to the registry) for the different capability 591 types (see Section 8). Each capability type MAY have a list of valid 592 values. Future specifications which define a given capability SHOULD 593 define any necessary registries (and the rules for adding new entries 594 to the registry) for the values advertised for a given capability 595 type. 597 The "CDNI Logging Fields Names" registry defines all supported 598 logging fields, including mandatory-to-implement logging fields. 599 Advertising support for mandatory-to-implement logging fields SHOULD 600 be supported but would be redundant. CDNs SHOULD NOT advertise 601 support for mandatory-to-implement logging fields. The following 602 logging fields are defined as optional in the CDNI Logging Interface 603 document [I-D.ietf-cdni-logging]: 605 o c-ip-anonimizing 607 o s-ccid 609 o s-sid 611 The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does 612 not define any optional GenericMetadata types. Advertiseing support 613 for mandatory-to-implement GenericMetadata types SHOULD be supported 614 but would be redundant. CDNs SHOULD NOT advertise support for 615 mandatory-to-implement GenericMetadata types. 617 6. Negotiation of Support for Optional Types of Footprint/Capabilities 619 The notion of optional types of footprint and capabilities implies 620 that certain implementations may not support all kinds of footprint 621 and capabilities. Therefore, any FCI solution protocol must define 622 how the support for optional types of footprint/capabilities will be 623 negotiated between a uCDN and a dCDN that use the particular FCI 624 protocol. In particular, any FCI solution protocol needs to specify 625 how to handle failure cases or non-supported types of footprint/ 626 capabilities. 628 In general, a uCDN may ignore capabilities or types of footprint it 629 does not understand; in this case it only selects a suitable 630 downstream CDN based on the types of capabilities and footprint it 631 understands. Similarly, if a dCDN does not use an optional 632 capability or footprint which is, however, supported by a uCDN, this 633 causes no problem for the FCI functionality because the uCDN decides 634 on the remaining capabilities/footprint information that is being 635 conveyed by the dCDN. 637 7. Capability Advertisement Object 639 To support extensibility, the FCI defines a generic base object 640 (similar to the CDNI Metadata interface GenericMetadata object) 641 [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory 642 parsing requirements for all future FCI objects. 644 Future object definitions (e.g. regarding CDNI Metadata or Logging) 645 will build off the base object defined here, but will be specified in 646 separate documents. 648 7.1. Base Advertisement Object 650 The FCIBase object is an abstraction for managing individual CDNI 651 capabilities in an opaque manner. 653 Property: capability-type 655 Description: CDNI Capability object type. 657 Type: MIME Type String (from Section 8) 659 Mandatory-to-Specify: Yes. 661 Property: capability-value 663 Description: CDNI Capability object. 665 Type: Format/Type is defined by the value of capability-type 666 property above. 668 Mandatory-to-Specify: Yes. 670 7.2. Delivery Protocol Capability Object 672 The Delivery Protocol capability object is used to indicate support 673 for one or more of the protocols listed in the CDNI Metadata 674 Protocols registry (defined in the CDNI Metadata Interface document 675 [I-D.ietf-cdni-metadata]). 677 Property: delivery-protocols 679 Description: List of supported CDNI Delivery Protocols. 681 Type: List of Protocol Types (from the CDNI Metadata Protocols 682 registry [I-D.ietf-cdni-metadata]) 684 Mandatory-to-Specify: Yes. 686 7.3. Acquisition Protocol Capability Object 688 The Acquisition Protocol capability object is used to indicate 689 support for one or more of the protocols listed in the CDNI Metadata 690 Protocols registry (defined in the CDNI Metadata Interface document 691 [I-D.ietf-cdni-metadata]). 693 Property: acquisition-protocols 695 Description: List of supported CDNI Acquisition Protocols. 697 Type: List of Protocol Types (from the CDNI Metadata Protocols 698 registry [I-D.ietf-cdni-metadata]) 700 Mandatory-to-Specify: Yes. 702 7.4. Redirection Mode Capability Object 704 The Redirection Mode capability object is used to indicate support 705 for one or more of the modes listed in the CDNI Capabilities 706 Redirection Modes registry (see Section 8.1). 708 Property: redirection-modes 710 Description: List of supported CDNI Redirection Modes. 712 Type: List of Redirection Modes (from Section 8.1) 714 Mandatory-to-Specify: Yes. 716 7.5. Capability Advertisement Object Serialization 718 The following shows an example of CDNI FCI Capability Advertisement 719 Object Serialization. 721 { 722 "capabilities": [ 723 { 724 "capability-type": "application/cdni.FCI.DeliveryProtocol.v1+json" 725 "capability-value": { 726 "delivery-protocols": [ 727 "HTTP1.1" 728 ] 729 } 730 }, 731 { 732 "capability-type": "application/cdni.FCI.AcquisitionProtocol.v1+json" 733 "capability-value": { 734 "acquisition-protocols": [ 735 "HTTP1.1", 736 "HTTPS1.1" 737 ] 738 } 739 }, 740 { 741 "capability-type": "application/cdni.FCI.RedirectionMode.v1+json" 742 "capability-value": { 743 "redirection-modes": [ 744 "DNS-I", 745 "HTTP-I" 746 ] 747 } 748 } 749 ] 750 } 752 8. IANA Considerations 754 This document requests the registration of the following MIME Media 755 Types under the IANA MIME Media Type registry 756 (http://www.iana.org/assignments/media-types/index.html). 758 application/cdni.FCI.DeliveryProtocol.v1+json 760 application/cdni.FCI.AcquisitionProtocol.v1+json 762 application/cdni.FCI.RedirectionMode.v1+json 764 8.1. Redirection Mode Registry 766 The IANA is requested to create a new "CDNI Capabilities Redirection 767 Modes" registry. The "CDNI Capabilities Redirection Modes" namespace 768 defines the valid redirection modes that may be advertised as 769 supported by a CDN. Additions to the Redirection Mode namespace 770 conform to the "IETF Review" policy as defined in [RFC5226]. 772 The following table defines the initial Redirection Modes: 774 +------------------+----------------------------------+---------+ 775 | Redirection Mode | Description | RFC | 776 +------------------+----------------------------------+---------+ 777 | DNS-I | Iterative DNS-based Redirection | RFCthis | 778 | | | | 779 | DNS-R | Recursive DNS-based Redirection | RFCthis | 780 | | | | 781 | HTTP-I | Iterative HTTP-based Redirection | RFCthis | 782 | | | | 783 | HTTP-R | Recursive HTTP-based Redirection | RFCthis | 784 +------------------+----------------------------------+---------+ 786 9. Security Considerations 788 This specification describes the semantics for capabilities and 789 footprint advertisement objects in content distribution networks. It 790 does not, however, specify a concrete protocol for transporting those 791 objects, or even a specific object syntax. Specific security 792 mechanisms can only be selected for concrete protocols that 793 instantiate these semantics. This document does, however, place some 794 high-level security constraints on such protocols. 796 All protocols that implement these semantics are REQUIRED to provide 797 integrity and authentication services. Without authentication and 798 integrity, an attacker could trivially deny service by forging a 799 footprint advertisement from a dCDN which claims the network has no 800 footprint or capability. This would prevent the uCDN from delegating 801 any requests to the dCDN. Since a pre-existing relationship between 802 all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary 803 credentials could be conducted before the FCI interface is brought 804 online. The authorization decision to accept advertisements would 805 also follow this pre-existing relationship and any contractual 806 obligations that it stipulates. 808 It is not believed that there are any serious privacy risks in 809 sharing footprint or capability information: it will represent highly 810 aggregated data about networks and at best policy-related information 811 about media, rather than any personally identifying information. 813 However, particular dCDNs may wish to share information about their 814 footprint with a uCDN but not with other, competing dCDNs. For 815 example, if a dCDN incurs an outage that reduces footprint coverage 816 temporarily, that may be information the dCDN would want to share 817 confidentially with the uCDN. Protocols implementing these semantics 818 SHOULD provide confidentiality services. 820 As specified in this document, the security requirements of the FCI 821 could be met by hop-by-hop transport-layer security mechanisms 822 coupled with domain certificates as credentials. There is no 823 apparent need for further object-level security in this framework, as 824 the trust relationships it defines are bilateral relationships 825 between uCDNs and dCDNs rather than transitive relationships. 827 10. References 829 10.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 835 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 836 May 2008. 838 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 839 Distribution Network Interconnection (CDNI) Problem 840 Statement", RFC 6707, September 2012. 842 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 843 K., and G. Watson, "Use Cases for Content Delivery Network 844 Interconnection", RFC 6770, November 2012. 846 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 847 "Framework for Content Distribution Network 848 Interconnection (CDNI)", RFC 7336, August 2014. 850 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 851 Interconnection (CDNI) Requirements", RFC 7337, August 852 2014. 854 10.2. Informative References 856 [I-D.ietf-cdni-logging] 857 Faucheur, F., Bertrand, G., Oprescu, I., and R. 858 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 859 logging-15 (work in progress), February 2015. 861 [I-D.ietf-cdni-metadata] 862 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 863 "CDN Interconnection Metadata", draft-ietf-cdni- 864 metadata-09 (work in progress), March 2015. 866 Appendix A. Acknowledgment 868 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 869 Architecture and Applications of Green Information Centric 870 Networking), a research project supported jointly by the European 871 Commission under its 7th Framework Program (contract no. 608518) and 872 the National Institute of Information and Communications Technology 873 (NICT) in Japan (contract no. 167). The views and conclusions 874 contained herein are those of the authors and should not be 875 interpreted as necessarily representing the official policies or 876 endorsements, either expressed or implied, of the GreenICN project, 877 the European Commission, or NICT. 879 Martin Stiemerling provided initial input to this document and 880 valuable comments to the ongoing discussions among the authors of 881 this document. Thanks to Francois Le Faucheur and Scott Wainner for 882 providing valuable comments and suggestions to the text. 884 Authors' Addresses 886 Jan Seedorf 887 NEC 888 Kurfuerstenanlage 36 889 Heidelberg 69115 890 Germany 892 Phone: +49 6221 4342 221 893 Fax: +49 6221 4342 155 894 Email: seedorf@neclab.eu 896 Jon Peterson 897 NeuStar 898 1800 Sutter St Suite 570 899 Concord CA 94520 900 USA 902 Email: jon.peterson@neustar.biz 903 Stefano Previdi 904 Cisco Systems 905 Via Del Serafico 200 906 Rome 0144 907 Italy 909 Email: sprevidi@cisco.com 911 Ray van Brandenburg 912 TNO 913 Brassersplein 2 914 Delft 2612CT 915 The Netherlands 917 Phone: +31-88-866-7000 918 Email: ray.vanbrandenburg@tno.nl 920 Kevin J. Ma 921 Ericsson 922 43 Nagog Park 923 Acton, MA 01720 924 USA 926 Phone: +1 978-844-5100 927 Email: kevin.j.ma@ericsson.com