idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-semantics-16.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 (April 13, 2016) is 2934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-25 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-15 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 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: October 15, 2016 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Ericsson 12 April 13, 2016 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-16 17 Abstract 19 This document captures 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)" offers within CDNI. The 24 document also provides guidelines for the CDNI FCI protocol. It 25 further defines a Base Advertisement Object, the necessary registries 26 for capabilities and footprints, and guidelines on how these 27 registries can 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 October 15, 2016. 51 Copyright Notice 53 Copyright (c) 2016 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. Delivery Protocol Capability Object . . . . . . . . . . . 15 83 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 84 7.4. Redirection Mode Capability Object . . . . . . . . . . . 16 85 7.5. Capability Advertisement Object Serialization . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 88 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 18 89 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 90 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 91 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 10.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. This CDN interconnection (CDNI) 103 can serve multiple purposes, as discussed in [RFC6770], for instance, 104 to extend the reach of a given CDN to areas in the network which are 105 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 (dCDN) 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 needs to 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 interconnected CDN 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 upstream CDN (uCDN) receives footprint and/or capability 128 advertisements from a set of dCDNs. Footprint advertisement and 129 capability advertisement need not use the same underlying 130 protocol. 132 o The uCDN receives the initial request-routing request from the 133 endpoint requesting the resource. 135 The CDNI Problem Statement [RFC6707] describes the Request Routing 136 Interface as: "[enabling] a Request Routing function in a uCDN to 137 query a Request Routing function in a dCDN to determine if the dCDN 138 is able (and willing) to accept the delegated Content Request". In 139 addition, RFC6707 says "the CDNI Request Routing interface is also 140 expected to enable a dCDN to provide to the uCDN (static or dynamic) 141 information (e.g., resources, footprint, load) to facilitate 142 selection of the dCDN by the uCDN request routing system when 143 processing subsequent content requests from User Agents". It thus 144 considers "resources" and "load" as capabilities to be advertised by 145 the dCDN. 147 The range of different footprint definitions and possible 148 capabilities is very broad. Attempting to define a comprehensive 149 advertisement solution quickly becomes intractable. The CDNI 150 requirements draft [RFC7337] lists the specific requirements for the 151 CDNI Footprint & Capabilities Advertisement Interface in order to 152 disambiguate footprints and capabilities with respect to CDNI. This 153 document defines a common understanding of what the terms 'footprint' 154 and 'capabilities' mean in the context of CDNI, and details the 155 semantics of the footprint advertisement mechanism and the capability 156 advertisement mechanism. 158 2. Design Decisions for Footprint and Capabilities 160 A large part of the difficulty in discussing the FCI lies in 161 understanding what exactly is meant when trying to define footprint 162 in terms of "coverage" or "reachability." While the operators of 163 CDNs pick strategic locations to situate caches, a cache with a 164 public IPv4 address is reachable by any endpoint on the Internet 165 unless some policy enforcement precludes the use of the cache. 167 Some CDNs aspire to cover the entire world; we refer to these as 168 global CDNs. The footprint advertised by such a CDN in the CDNI 169 environment would, from a coverage or reachability perspective, 170 presumably cover all prefixes. Potentially more interesting for CDNI 171 use cases, however, are CDNs that claim a more limited coverage, but 172 seek to interconnect with other CDNs in order to create a single CDN 173 fabric which shares resources. 175 Furthermore, not all capabilities need to be footprint restricted. 176 Depending upon the use case, the optimal semantics of "footprints 177 with capability attributes" vs. "capabilities with footprint 178 restrictions" are not clear. 180 The key to understanding the semantics of footprint and capability 181 advertisement lies in understand why a dCDN would advertise a limited 182 coverage area, and how a uCDN would use such advertisements to decide 183 among one of several dCDNs. The following section will discuss some 184 of the trade-offs and design decisions that need to be decided upon 185 for the CDNI FCI. 187 2.1. Advertising Limited Coverage 189 The basic use case that would motivate a dCDN to advertise a limited 190 coverage is that the CDN was built to cover only a particular portion 191 of the Internet. For example, an ISP could purpose-build a CDN to 192 serve only their own customers by situating caches in close 193 topological proximity to high concentrations of their subscribers. 194 The ISP knows the prefixes it has allocated to end users and thus can 195 easily construct a list of prefixes that its caches were positioned 196 to serve. 198 When such a purpose-built CDN interconnects with other CDNs and 199 advertises its footprint to a uCDN, however, the original intended 200 coverage of the CDN might not represent its actual value to the 201 interconnection of CDNs. Consider an ISP-A and ISP-B that both field 202 their own CDNs, which they interconnect via CDNI. A given user E, 203 who is a customer of ISP-B, might happen to be topologically closer 204 to a cache fielded by ISP-A, if E happens to live in a region where 205 ISP-B has few customers and ISP-A has many. In this case, is it ISP- 206 A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is 207 it up to the uCDN to understand that ISP-A's caches are potentially 208 available as back-ups - and if so, how does ISP-A advertise itself as 209 a "standby" for E? What about the case where CDNs advertising to the 210 same uCDN express overlapping coverage (for example, mixing global 211 and limited CDNs)? 213 The answers to these questions greatly depend on how much information 214 the uCDN wants 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. Alternately, dCDNs could advertise 222 the IP addresses of their caches rather than prefix "coverage," and 223 let the uCDN decide for itself (based on its own topological 224 intelligence) which dCDN has better resources to serve a given user. 226 In summary, the semantics of advertising footprint depend on whether 227 such qualitative metrics for expressing footprint (such as the 228 coverage 'score' mentioned above) are included as part of the CDNI 229 FCI, or if the focus is just on 'binary' footprint. 231 2.2. Capabilities and Dynamic Data 233 In cases where the apparent footprints of dCDNs overlap, uCDNs might 234 also want to rely on other factors to evaluate the respective merits 235 of dCDNs. These include facts related to the caches themselves, to 236 the network where the cache is deployed, to the nature of the 237 resource sought, and to the administrative policies of the respective 238 networks. 240 In the absence of network-layer impediments to reaching caches, the 241 choice to limit coverage is necessarily an administrative policy. 242 Much policy needs to be agreed upon before CDNs can interconnect, 243 including questions of membership, compensation, volumes, and so on. 244 A uCDN certainly will factor these sorts of considerations into its 245 decision to select a dCDN, but there is probably little need for 246 dCDNs to actually advertise them through an interface - they will be 247 settled out-of-band as a precondition for interconnection. 249 Other facts about the dCDN would be expressed through the interface 250 to the uCDN. Some capabilities of a dCDN are static, and some are 251 highly dynamic. Expressing the total storage built into its caches, 252 for example, changes relatively rarely, whereas the amount of storage 253 in use at any given moment is highly volatile. Network bandwidth 254 similarly could be expressed as either total bandwidth available to a 255 cache, or based on the current state of the network. A cache can at 256 one moment lack a particular resource in storage, but have it the 257 next. 259 The semantics of the capabilities interface will depend on how much 260 of the dCDN state needs to be pushed to the uCDN and qualitatively 261 how often that information needs to be updated. 263 2.3. Advertisement versus Queries 265 In a CDNI environment, each dCDN shares some of its state with the 266 uCDN. The uCDN uses this information to build a unified picture of 267 all of the dCDNs available to it. In architectures that share 268 detailed capability information, the uCDN could perform the entire 269 request-routing operation down to selecting a particular cache in the 270 dCDN. However, when the uCDN needs to deal with many potential 271 dCDNs, this approach does not scale, especially for dCDNs with 272 thousands or tens of thousands of caches; the volume of updates to 273 footprint and capability becomes onerous. 275 Were the volume of FCI updates from dCDNs to exceed the volume of 276 requests to the uCDN, it might make more sense for the uCDN to query 277 dCDNs upon receiving requests (as is the case in the recursive 278 redirection mode described in [RFC7336]), instead of receiving 279 advertisements and tracking the state of dCDNs. The advantage of 280 querying dCDNs would be that much of the dynamic data that dCDNs 281 cannot share with the uCDN would now be factored into the uCDN's 282 decision. dCDNs need not replicate any state to the uCDN - uCDNs 283 could effectively operate 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 over 'competing' dCDNs. It 296 could therefore be desirable to take away the incentive for dCDNs to 297 cheat (in information advertised) as much as possible. One option is 298 to make the information the dCDN advertises somehow verifiable for 299 the uCDN. On the other hand, a cheating dCDN might be avoided or 300 handled by the fact that there will be strong contractual agreements 301 between a uCDN and a dCDN, so that a dCDN would risk severe penalties 302 or legal consequences when caught cheating. 304 Overall, the information a dCDN advertises (in the long run) needs to 305 be somehow qualitatively verifiable by the uCDN, though possibly 306 through non-real-time out-of-band audits. It is probably an overly 307 strict requirement to mandate that such verification be possible 308 "immediately", i.e., during the request routing process itself. If 309 the uCDN can detect a cheating dCDN at a later stage, it might 310 suffice for the uCDN to "de-incentivize" cheating because it would 311 negatively affect the long-term business relationship with a 312 particular dCDN. 314 2.5. Focusing on Main Use Cases 316 To narrow down semantics for "footprint" and "capabilities" in the 317 CDNI context, it can be useful to initially focus on key use cases to 318 be addressed by the CDNI WG that are to be envisioned in the main 319 deployments in the foreseeable future. In this regard, a main 320 realistic use case is the existence of ISP-owned CDNs, which 321 essentially cover a certain operator's network. At the same time, 322 however, the possibility of overlapping footprints cannot be 323 excluded, i.e., the scenario where more than one dCDN claims it can 324 serve a given end user request. The ISPs can also choose to 325 interconnect with a fallback global CDN. 327 It seems reasonable to assume that in most use cases it is the uCDN 328 that makes the decision on selecting a certain dCDN for request 329 routing based on information the uCDN has received from this 330 particular dCDN. It can be assumed that 'cheating' CDNs will be 331 dealt with via means outside the scope of CDNI and that the 332 information advertised between CDNs is accurate. In addition, 333 excluding the use of qualitative information (e.g., cache proximity, 334 delivery latency, cache load) to predict the quality of delivery 335 would further simplify the use case allowing it to better focus on 336 the basic functionality of the FCI. 338 3. Main Use Case to Consider 340 Focusing on a main use case that contains a simple (yet somewhat 341 challenging), realistic, and generally imaginable scenario can help 342 in narrowing down the requirements for the CDNI FCI. To this end, 343 the following (simplified) use case can help in clarifying the 344 semantics of footprint and capabilities for CDNI. In particular, the 345 intention of the use case is to clarify what information needs to be 346 exchanged on the CDNI FCI, what types of information need to be 347 supported in a mandatory fashion (and which can be considered 348 optional), and what types of information need to be updated with 349 respect to a priori established CDNI contracts. 351 Use case: A given uCDN has several dCDNs. It selects one dCDN for 352 delivery protocol A and footprint 1 and another dCDN for delivery 353 protocol B and footprint 1. The dCDN that serves delivery protocol B 354 has a further, transitive (level-2) dCDN, that serves delivery 355 protocol B in a subset of footprint 1 where the first-level dCDN 356 cannot serve delivery protocol B itself. What happens if 357 capabilities change in the transitive level-2 dCDN that might affect 358 how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN 359 cannot serve delivery protocol B anymore)? How will these changes be 360 conveyed to the uCDN? In particular, what information does the uCDN 361 need to be able to select a new first-level dCDN, either for all of 362 footprint 1 or only for the subset of footprint 1 that the transitive 363 level-2 dCDN served on behalf of the first-level dCDN? 365 4. Semantics for Footprint Advertisement 367 Roughly speaking, "footprint" can be defined as "ability and 368 willingness to serve" by a dCDN. However, in addition to simple 369 "ability and willingness to serve", the uCDN could want additional 370 information to make a dCDN selection decision, e.g., "how well" a 371 given dCDN can actually serve a given end user request. The "ability 372 and willingness" to serve SHOULD be distinguished from the subjective 373 qualitative measurement of "how well" it was served. One can imagine 374 that such additional information is implicitly associated with a 375 given footprint, due to contractual agreements, SLAs, business 376 relationships, or past perceptions of dCDN quality. As an 377 alternative, such additional information could also be explicitly 378 tagged along with the footprint. 380 It is reasonable to assume that a significant part of the actual 381 footprint advertisement will happen in contractual agreements between 382 participating CDNs, prior to the advertisement phase using the CDNI 383 FCI. The reason for this assumption is that any contractual 384 agreement is likely to contain specifics about the dCDN coverage 385 (footprint) to which the contractual agreement applies. In 386 particular, additional information to judge the delivery quality 387 associated with a given dCDN footprint might be defined in 388 contractual agreements, outside of the CDNI FCI. Further, one can 389 assume that dCDN contractual agreements about the delivery quality 390 associated with a given footprint will probably be based on high- 391 level aggregated statistics and not too detailed. 393 Given that a large part of footprint advertisement will actually 394 happen in contractual agreements, the semantics of CDNI footprint 395 advertisement refer to answering the following question: what exactly 396 still needs to be advertised by the CDNI FCI? For instance, updates 397 about temporal failures of part of a footprint can be useful 398 information to convey via the CDNI request routing interface. Such 399 information would provide updates on information previously agreed in 400 contracts between the participating CDNs. In other words, the CDNI 401 FCI is a means for a dCDN to provide changes/updates regarding a 402 footprint it has prior agreed to serve in a contract with a uCDN. 404 Generally speaking, one can imagine two categories of footprint to be 405 advertised by a dCDN: 407 o Footprint could be defined based on "coverage/reachability", where 408 coverage/reachability refers to a set of prefixes, a geographic 409 region, or similar boundary. The dCDN claims that it can cover/ 410 reach 'end user requests coming from this footprint'. 412 o Footprint could be defined based on "resources", where resources 413 refers to surrogates/caches a dCDN claims to have (e.g., the 414 location of surrogates/resources). The dCDN claims that 'from 415 this footprint' it can serve incoming end user requests. 417 For each of these footprint types, there are capabilities associated 418 with a given footprint: 420 o capabilities such as delivery protocol, redirection mode, and 421 metadata, which are supported in the coverage area for a 422 "coverage/reachability" defined footprint, or 424 o capabilities of resources, such as delivery protocol, redirection 425 mode, and metadata, which apply to a "resource" defined footprint. 427 It seems clear that "coverage/reachability" types of footprint MUST 428 be supported within CDNI. The following such types of footprint are 429 mandatory and MUST be supported by the CDNI FCI: 431 o List of ISO Country Codes 433 o List of AS numbers 435 o Set of IP-prefixes 437 A 'set of IP-prefixes' MUST be able to contain full IP addresses, 438 i.e., a /32 for IPv4 and a /128 for IPv6, as well as IP prefixes with 439 an arbitrary prefix length. There also MUST be support for multiple 440 IP address versions, i.e., IPv4 and IPv6, in such a footprint. 442 "Resource" types of footprints are more specific than "coverage/ 443 reachability" types of footprints, where the actual coverage/ 444 reachability are extrapolated from the resource location (e.g., 445 netmask applied to resource IP address to derive IP-prefix). The 446 specific methods for extrapolating coverage/reachability from 447 resource location are beyond the scope of this document. In the 448 degenerate case, the resource address could be specified as a 449 coverage/reachability type of footprint, in which case no 450 extrapolation is necessary. Resource types of footprints could 451 expose the internal structure of a CDN network which could be 452 undesirable. As such, the resource types of footprints are not 453 considered mandatory to support for CDNI. 455 For all of these mandatory-to-implement footprint types, the 456 footprints can be viewed as constraints for delegating requests to a 457 dCDN: A dCDN footprint advertisement tells the uCDN the limitations 458 for delegating a request to the dCDN. For IP prefixes or ASN(s), the 459 footprint signals to the uCDN that it SHOULD consider the dCDN a 460 candidate only if the IP address of the request routing source falls 461 within the prefix set (or ASN, respectively). The CDNI 462 specifications do not define how a given uCDN determines what address 463 ranges are in a particular ASN. Similarly, for country codes a uCDN 464 SHOULD only consider the dCDN a candidate if it covers the country of 465 the request routing source. The CDNI specifications do not define 466 how a given uCDN determines the country of the request routing 467 source. Multiple footprint constraints are additive: the 468 advertisement of different types of footprint narrows the dCDN 469 candidacy cumulatively. 471 In addition to these mandatory "coverage/reachability" types of 472 footprint, other optional "coverage/reachability" types of footprint 473 or "resource" types of footprint MAY be defined by future 474 specifications. To facilitate this, a clear process for specifying 475 optional footprint types in an IANA registry is specified in the CDNI 476 Metadata Footprint Types registry (defined in the CDNI Metadata 477 Interface document [I-D.ietf-cdni-metadata]). 479 Independent of the exact type of a footprint, a footprint might also 480 include the connectivity of a given dCDN to other CDNs that are able 481 to serve content to users on behalf of that dCDN, to cover cases with 482 cascaded CDNs. Further, the dCDN needs to be able to express its 483 footprint to an interested uCDN in a comprehensive form, e.g., as a 484 data set containing the complete footprint. Making incremental 485 updates, however, to express dynamic changes in state is also 486 desirable. 488 5. Semantics for Capabilities Advertisement 490 In general, the dCDN MUST be able to express its general capabilities 491 to the uCDN. These general capabilities could express if the dCDN 492 supports a given service, for instance, HTTP vs HTTPS delivery. 493 Furthermore, the dCDN MUST be able to express particular capabilities 494 for the delivery in a particular footprint area. For example, the 495 dCDN might in general offer HTTPS but not in some specific areas, 496 either for maintenance reasons or because the caches covering this 497 particular area cannot deliver this type of service. Hence, in 498 certain cases footprint and capabilities are tied together and cannot 499 be interpreted independently from each other. In such cases, i.e., 500 where capabilities need to be expressed on a per footprint basis, it 501 could be beneficial to combine footprint and capabilities 502 advertisement. 504 A high-level and very rough semantic for capabilities is thus the 505 following: Capabilities are types of information that allow a uCDN to 506 determine if a dCDN is able (and willing) to accept (and properly 507 handle) a delegated content request. In addition, Capabilities are 508 characterized by the fact that this information can change over time 509 based on the state of the network or caches. 511 At a first glance, several broad categories of capabilities seem 512 useful to convey via an advertisement interface, however, advertising 513 capabilities that change highly dynamically (e.g., real-time delivery 514 performance metrics, CDN resource load, or other highly dynamically 515 changing QoS information) is beyond the scope for CDNI FCI. First, 516 out of the multitude of possible metrics and capabilities, it is hard 517 to agree on a subset and the precise metrics to be used. Second, it 518 seems infeasible to specify such highly dynamically changing 519 capabilities and the corresponding metrics within a reasonable time- 520 frame. 522 Useful capabilities refer to information that does not change highly 523 dynamically and which in many cases is absolutely necessary to decide 524 on a particular dCDN for a given end user request. For instance, if 525 an end user request concerns the delivery of a video file with a 526 certain protocol, the uCDN needs to know if a given dCDN has the 527 capability of supporting this delivery protocol. 529 Similar to footprint advertisement, it is reasonable to assume that a 530 significant part of the actual (resource) capabilities advertisement 531 will happen in contractual agreements between participating CDNs, 532 i.e., prior to the advertisement phase using the CDNI FCI. The role 533 of capability advertisement is hence rather to enable the dCDN to 534 update a uCDN on changes since a contract has been set up (e.g., in 535 case a new delivery protocol is suddenly being added to the list of 536 supported delivery protocols of a given dCDN, or in case a certain 537 delivery protocol is suddenly not being supported anymore due to 538 failures). Capabilities advertisement thus refers to conveying 539 information to a uCDN about changes/updates of certain capabilities 540 with respect to a given contract. 542 Given these semantics, it needs to be decided what exact capabilities 543 are useful and how these can be expressed. Since the details of CDNI 544 contracts are not known at the time of this writing (and the CDNI 545 interface are better off being agnostic to these contracts anyway), 546 it remains to be seen what capabilities will be used to define 547 agreements between CDNs in practice. One implication for 548 standardization could be to initially only specify a very limited set 549 of mandatory capabilities for advertisement and have on top of that a 550 flexible data model that allows exchanging additional capabilities 551 when needed. Still, agreement needs to be found on which 552 capabilities (if any) will be mandatory among CDNs. As discussed in 553 Section 2.5, finding the concrete answers to these questions can 554 benefit from focusing on a small number of key use cases that are 555 highly relevant and contain enough complexity to help in 556 understanding what concrete capabilities are needed to facilitate CDN 557 Interconnection. 559 Under the above considerations, the following capabilities seem 560 useful as 'base' capabilities, i.e., ones that are needed in any case 561 and therefore constitute mandatory capabilities that MUST be 562 supported by the CDNI FCI: 564 o Delivery Protocol (for delivering content to the end user) 566 o Acquisition Protocol (for acquiring content from the uCDN or 567 origin server) 569 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 570 discussed in [RFC7336]) 572 o CDNI Logging (i.e., supported logging fields) 573 o CDNI Metadata (i.e., supported Generic Metadata types) 575 It is not feasible to enumerate all the possible options for the 576 mandatory capabilities listed above (e.g., all the potential delivery 577 protocols or metadata options) or anticipate all the future needs for 578 additional capabilities. It would be unreasonable to burden the CDNI 579 FCI specification with defining each supported capability. Instead, 580 the CDNI FCI specification SHOULD define a generic protocol for 581 conveying any capability information (e.g. with common encoding, 582 error handling, and security mechanism; further requirements for the 583 CDNI FCI Advertisement Interface are listed in [RFC7337]). In this 584 respect, it seems reasonable to initially define the mandatory 585 capabilities listed above and extend the list as needs dictate. This 586 document registers CDNI Payload Types [RFC7736] for the mandatory 587 capability types (see Section 8), prefixing each payload type with 588 "FCI". Updates to capability objects MUST indicate the version of 589 the capability object in a newly registered payload type, e.g., by 590 appending ".v2". Each capability type MAY have a list of valid 591 values. Future specifications which define a given capability MUST 592 define any necessary registries (and the rules for adding new entries 593 to the registry) for the values advertised for a given capability 594 type. 596 The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] 597 defines all known record types, including mandatory-to-implement 598 record-types Advertising support for mandatory-to-implement record- 599 types would be redundant. CDNs SHOULD NOT advertise support for 600 mandatory-to-implement record-types. 602 The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging] 603 defines all known logging fields. Logging fields may be reused by 604 different record-types and be mandatory-to-implement in some record- 605 types, but optional in other record-types. CDNs MUST advertise 606 support for optional logging fields within the context of a specific 607 record-type. CDNs SHOULD NOT advertise support for mandatory-to- 608 implement logging fields, for a given record-type. The following 609 logging fields are defined as optional for the "cdni_http_request_v1" 610 record-type in the CDNI Logging Interface document 611 [I-D.ietf-cdni-logging]: 613 o s-ccid 615 o s-sid 617 The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] 618 requires that CDNs be able to parse all the defined metadata objects, 619 but does not require dCDNs to support enforcement of non-structural 620 GenericMetadata objects. Advertising support for mandatory-to- 621 enforce GenericMetadata types MUST be supported. Advertising support 622 for non-mandatory-to-enforce GenericMetadata types SHOULD be 623 supported. Advertisement of non-mandatory-to-enforce GenericMetadata 624 MAY be necessary, e.g., to signal temporary outages and subsequent 625 recovery. It is expected that structural metadata will be supported 626 at all times. 628 6. Negotiation of Support for Optional Types of Footprint/Capabilities 630 The notion of optional types of footprint and capabilities implies 631 that certain implementations might not support all kinds of footprint 632 and capabilities. Therefore, any FCI solution protocol MUST define 633 how the support for optional types of footprint/capabilities will be 634 negotiated between a uCDN and a dCDN that use the particular FCI 635 protocol. In particular, any FCI solution protocol MUST specify how 636 to handle failure cases or non-supported types of footprint/ 637 capabilities. 639 In general, a uCDN MAY ignore capabilities or types of footprints it 640 does not understand; in this case it only selects a suitable dCDN 641 based on the types of capabilities and footprint it understands. 642 Similarly, if a dCDN does not use an optional capability or footprint 643 which is, however, supported by a uCDN, this causes no problem for 644 the FCI functionality because the uCDN decides on the remaining 645 capabilities/footprint information that is being conveyed by the 646 dCDN. 648 7. Capability Advertisement Object 650 To support extensibility, the FCI defines a generic base object 651 (similar to the CDNI Metadata interface GenericMetadata object) 652 [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory 653 parsing requirements for all future FCI objects. 655 Future object definitions (e.g. regarding CDNI Metadata or Logging) 656 will build off the base object defined here, but will be specified in 657 separate documents. 659 7.1. Base Advertisement Object 661 The FCIBase object is an abstraction for managing individual CDNI 662 capabilities in an opaque manner. 664 Property: capability-type 666 Description: CDNI Capability object type. 668 Type: FCI specific CDNI Payload type (from the CDNI Payload 669 Types registry [RFC7736]) 671 Mandatory-to-Specify: Yes. 673 Property: capability-value 675 Description: CDNI Capability object. 677 Type: Format/Type is defined by the value of capability-type 678 property above. 680 Mandatory-to-Specify: Yes. 682 Property: footprints 684 Description: CDNI Capability Footprint. 686 Type: List of CDNI Footprint objects (as defined in 687 [I-D.ietf-cdni-metadata]). 689 Mandatory-to-Specify: No. 691 7.2. Delivery Protocol Capability Object 693 The Delivery Protocol capability object is used to indicate support 694 for one or more of the protocols listed in the CDNI Metadata Protocol 695 Types registry (defined in the CDNI Metadata Interface document 696 [I-D.ietf-cdni-metadata]). 698 Property: delivery-protocols 700 Description: List of supported CDNI Delivery Protocols. 702 Type: List of Protocol Types (from the CDNI Metadata Protocol 703 Types registry [I-D.ietf-cdni-metadata]) 705 Mandatory-to-Specify: Yes. 707 7.3. Acquisition Protocol Capability Object 709 The Acquisition Protocol capability object is used to indicate 710 support for one or more of the protocols listed in the CDNI Metadata 711 Protocol Types registry (defined in the CDNI Metadata Interface 712 document [I-D.ietf-cdni-metadata]). 714 Property: acquisition-protocols 715 Description: List of supported CDNI Acquisition Protocols. 717 Type: List of Protocol Types (from the CDNI Metadata Protocol 718 Types registry [I-D.ietf-cdni-metadata]) 720 Mandatory-to-Specify: Yes. 722 7.4. Redirection Mode Capability Object 724 The Redirection Mode capability object is used to indicate support 725 for one or more of the modes listed in the CDNI Capabilities 726 Redirection Modes registry (see Section 8.2). 728 Property: redirection-modes 730 Description: List of supported CDNI Redirection Modes. 732 Type: List of Redirection Modes (from Section 8.2) 734 Mandatory-to-Specify: Yes. 736 7.5. Capability Advertisement Object Serialization 738 The following shows an example of CDNI FCI Capability Advertisement 739 Object Serialization. 741 { 742 "capabilities": [ 743 { 744 "capability-type": "FCI.DeliveryProtocol", 745 "capability-value": { 746 "delivery-protocols": [ 747 "http1.1" 748 ] 749 }, 750 "footprints": [ 751 752 ] 753 }, 754 { 755 "capability-type": "FCI.AcquisitionProtocol", 756 "capability-value": { 757 "acquisition-protocols": [ 758 "http1.1", 759 "https1.1" 760 ] 761 } 762 }, 763 { 764 "capability-type": "FCI.RedirectionMode", 765 "capability-value": { 766 "redirection-modes": [ 767 "DNS-I", 768 "HTTP-I" 769 ] 770 } 771 } 772 ] 773 } 775 8. IANA Considerations 777 8.1. CDNI Payload Types 779 This document requests the registration of the following CDNI Payload 780 Types under the IANA CDNI Payload Type registry: 782 +-------------------------+---------------+ 783 | Payload Type | Specification | 784 +-------------------------+---------------+ 785 | FCI.DeliveryProtocol | RFCthis | 786 | | | 787 | FCI.AcquisitionProtocol | RFCthis | 788 | | | 789 | FCI.RedirectionMode | RFCthis | 790 +-------------------------+---------------+ 792 [RFC Editor: Please replace RFCthis with the published RFC number for 793 this document.] 795 8.1.1. CDNI FCI DeliveryProtocol Payload Type 797 Purpose: The purpose of this payload type is to distinguish FCI 798 advertisement objects for supported delivery protocols 800 Interface: FCI 802 Encoding: see Section 7.2 and Section 7.5 804 8.1.2. CDNI FCI AcquisitionProtocol Payload Type 806 Purpose: The purpose of this payload type is to distinguish FCI 807 advertisement objects for supported acquisition protocols 809 Interface: FCI 811 Encoding: see Section 7.3 and Section 7.5 813 8.1.3. CDNI FCI RedirectionMode Payload Type 815 Purpose: The purpose of this payload type is to distinguish FCI 816 advertisement objects for supported redirection modes 818 Interface: FCI 820 Encoding: see Section 7.4 and Section 7.5 822 8.2. Redirection Mode Registry 824 The IANA is requested to create a new "CDNI Capabilities Redirection 825 Modes" registry in the "Content Delivery Networks Interconnection 826 (CDNI) Parameters" category. The "CDNI Capabilities Redirection 827 Modes" namespace defines the valid redirection modes that can be 828 advertised as supported by a CDN. Additions to the Redirection Mode 829 namespace conform to the "IETF Review" policy as defined in 830 [RFC5226]. 832 The following table defines the initial Redirection Modes: 834 +------------------+----------------------------------+---------+ 835 | Redirection Mode | Description | RFC | 836 +------------------+----------------------------------+---------+ 837 | DNS-I | Iterative DNS-based Redirection | RFCthis | 838 | | | | 839 | DNS-R | Recursive DNS-based Redirection | RFCthis | 840 | | | | 841 | HTTP-I | Iterative HTTP-based Redirection | RFCthis | 842 | | | | 843 | HTTP-R | Recursive HTTP-based Redirection | RFCthis | 844 +------------------+----------------------------------+---------+ 846 [RFC Editor: Please replace RFCthis with the published RFC number for 847 this document.] 849 9. Security Considerations 851 This specification describes the semantics for capabilities and 852 footprint advertisement objects across interconnected CDNs. It does 853 not, however, specify a concrete protocol for transporting those 854 objects. Specific security mechanisms can only be selected for 855 concrete protocols that instantiate these semantics. This document 856 does, however, place some high-level security constraints on such 857 protocols. 859 All protocols that implement these semantics are REQUIRED to provide 860 integrity and authentication services. Without authentication and 861 integrity, an attacker could trivially deny service by forging a 862 footprint advertisement from a dCDN which claims the network has no 863 footprint or capability. This would prevent the uCDN from delegating 864 any requests to the dCDN. Since a pre-existing relationship between 865 all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary 866 credentials could be conducted before the FCI interface is brought 867 online. The authorization decision to accept advertisements would 868 also follow this pre-existing relationship and any contractual 869 obligations that it stipulates. 871 All protocols that implement these semantics are REQUIRED to provide 872 confidentiality services. Some dCDNs are willing to share 873 information about their footprint or capabilities with a uCDN but not 874 with other, competing dCDNs. For example, if a dCDN incurs an outage 875 that reduces footprint coverage temporarily, that could be 876 information the dCDN would want to share confidentially with the 877 uCDN. 879 As specified in this document, the security requirements of the FCI 880 could be met by hop-by-hop transport-layer security mechanisms 881 coupled with domain certificates as credentials (e.g., TLS transport 882 for HTTP as per [RFC2818] and [RFC7230], with usage guidance from 883 [RFC7525]). There is no apparent need for further object-level 884 security in this framework, as the trust relationships it defines are 885 bilateral relationships between uCDNs and dCDNs rather than 886 transitive relationships. 888 10. References 890 10.1. Normative References 892 [I-D.ietf-cdni-logging] 893 Faucheur, F., Bertrand, G., Oprescu, I., and R. 894 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 895 logging-25 (work in progress), April 2016. 897 [I-D.ietf-cdni-metadata] 898 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 899 "CDN Interconnection Metadata", draft-ietf-cdni- 900 metadata-15 (work in progress), April 2016. 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, 904 DOI 10.17487/RFC2119, March 1997, 905 . 907 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 908 DOI 10.17487/RFC2818, May 2000, 909 . 911 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 912 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 913 DOI 10.17487/RFC5226, May 2008, 914 . 916 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 917 Protocol (HTTP/1.1): Message Syntax and Routing", 918 RFC 7230, DOI 10.17487/RFC7230, June 2014, 919 . 921 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 922 "Recommendations for Secure Use of Transport Layer 923 Security (TLS) and Datagram Transport Layer Security 924 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 925 2015, . 927 10.2. Informative References 929 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 930 Distribution Network Interconnection (CDNI) Problem 931 Statement", RFC 6707, DOI 10.17487/RFC6707, September 932 2012, . 934 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 935 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 936 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 937 November 2012, . 939 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 940 "Framework for Content Distribution Network 941 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 942 August 2014, . 944 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 945 Network Interconnection (CDNI) Requirements", RFC 7337, 946 DOI 10.17487/RFC7337, August 2014, 947 . 949 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 950 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 951 December 2015, . 953 Appendix A. Acknowledgment 955 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 956 Architecture and Applications of Green Information Centric 957 Networking), a research project supported jointly by the European 958 Commission under its 7th Framework Program (contract no. 608518) and 959 the National Institute of Information and Communications Technology 960 (NICT) in Japan (contract no. 167). The views and conclusions 961 contained herein are those of the authors and should not be 962 interpreted as necessarily representing the official policies or 963 endorsements, either expressed or implied, of the GreenICN project, 964 the European Commission, or NICT. 966 Martin Stiemerling provided initial input to this document and 967 valuable comments to the ongoing discussions among the authors of 968 this document. Thanks to Francois Le Faucheur and Scott Wainner for 969 providing valuable comments and suggestions to the text. 971 Authors' Addresses 973 Jan Seedorf 974 NEC 975 Kurfuerstenanlage 36 976 Heidelberg 69115 977 Germany 979 Phone: +49 6221 4342 221 980 Fax: +49 6221 4342 155 981 Email: seedorf@neclab.eu 983 Jon Peterson 984 NeuStar 985 1800 Sutter St Suite 570 986 Concord CA 94520 987 USA 989 Email: jon.peterson@neustar.biz 991 Stefano Previdi 992 Cisco Systems 993 Via Del Serafico 200 994 Rome 0144 995 Italy 997 Email: sprevidi@cisco.com 999 Ray van Brandenburg 1000 TNO 1001 Brassersplein 2 1002 Delft 2612CT 1003 The Netherlands 1005 Phone: +31-88-866-7000 1006 Email: ray.vanbrandenburg@tno.nl 1007 Kevin J. Ma 1008 Ericsson 1009 43 Nagog Park 1010 Acton, MA 01720 1011 USA 1013 Phone: +1 978-844-5100 1014 Email: kevin.j.ma@ericsson.com