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