idnits 2.17.1 draft-ietf-cdni-footprint-capabilities-semantics-12.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 8, 2016) is 2970 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-22 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-12 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 9, 2016 Neustar 6 S. Previdi 7 Cisco 8 R. van Brandenburg 9 TNO 10 K. Ma 11 Ericsson 12 March 8, 2016 14 CDNI Request Routing: Footprint and Capabilities Semantics 15 draft-ietf-cdni-footprint-capabilities-semantics-12 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 September 9, 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 . . . . . . . . . . . 15 85 7.5. Capability Advertisement Object Serialization . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 88 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 89 8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 17 90 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 91 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 10.2. Informative References . . . . . . . . . . . . . . . . . 19 96 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 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. 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 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 an Upstream 137 CDN to query a Request Routing function in a Downstream CDN to 138 determine if the Downstream CDN is able (and willing) to accept the 139 delegated Content Request". In addition, the RFC says "the CDNI 140 Request Routing interface is also expected to enable a downstream CDN 141 to provide to the upstream CDN (static or dynamic) information (e.g., 142 resources, footprint, load) to facilitate selection of the downstream 143 CDN by the upstream CDN request routing system when processing 144 subsequent content requests from User Agents". It thus considers 145 "resources" and "load" as capabilities to be advertised by the 146 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 defines a common understanding of what the terms 'footprint' 155 and 'capabilities' mean in the context of CDNI, and details the 156 semantics of the footprint advertisement mechanism and the capability 157 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; we refer to these as 169 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 interconnect with other CDNs in order to create a single CDN 174 fabric which shares resources. 176 Furthermore, not all capabilities need to 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 interconnects with other CDNs and 200 advertises its footprint to a uCDN, however, the original intended 201 coverage of the CDN might not represent its actual value to the 202 interconnection of CDNs. Consider an ISP-A and ISP-B that both field 203 their own CDNs, which they interconnect via CDNI. A given user E, 204 who is a customer of ISP-B, might happen to be topologically closer 205 to a cache fielded by ISP-A, if E happens to live in a region where 206 ISP-B has few customers and ISP-A has many. In this case, is it ISP- 207 A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is 208 it up to the uCDN to understand that ISP-A's caches are potentially 209 available as back-ups - and if so, how does ISP-A advertise itself as 210 a "standby" for E? What about the case where CDNs advertising to the 211 same uCDN express overlapping coverage (for example, mixing global 212 and limited CDNs)? 214 The answers to these questions greatly depend on how much information 215 the uCDN wants to use to make a selection of a dCDN. If a uCDN has 216 three dCDNs to choose from that "cover" the IP address of user E, 217 obviously the uCDN might be interested to know how optimal the 218 coverage is from each of the dCDNs - coverage need not be binary, 219 either provided or not provided. dCDNs could advertise a coverage 220 "score," for example, and provided that they all reported scores 221 fairly on the same scale, uCDNs could use that to make their 222 topological optimality decision. Alternately, dCDNs could advertise 223 the IP addresses of their caches rather than prefix "coverage," and 224 let the uCDN decide for itself (based on its own topological 225 intelligence) which dCDN has better resources to 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) are included as part of the CDNI 230 FCI, or if the focus is just on 'binary' footprint. 232 2.2. Capabilities and Dynamic Data 234 In cases where the apparent footprints of dCDNs overlap, uCDNs might 235 also want to rely on other factors to evaluate the respective merits 236 of dCDNs. These include facts related to the caches themselves, to 237 the network where the cache is deployed, to the nature of the 238 resource sought, and to the administrative policies of the respective 239 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 needs to be agreed upon before CDNs can interconnect, 244 including questions of membership, compensation, volumes, and so on. 245 A uCDN certainly will factor these sorts of considerations into its 246 decision to select a dCDN, but there is probably little need for 247 dCDNs to actually advertise them through an interface - they will be 248 settled out-of-band as a precondition for interconnection. 250 Other facts about the dCDN would be expressed through the interface 251 to the uCDN. Some capabilities of a dCDN are static, and some are 252 highly dynamic. Expressing the total storage built into its caches, 253 for example, changes relatively rarely, whereas the amount of storage 254 in use at any given moment is highly volatile. Network bandwidth 255 similarly could be expressed as either total bandwidth available to a 256 cache, or based on the current state of the network. A cache can at 257 one moment lack a particular resource in storage, but have it the 258 next. 260 The semantics of the capabilities interface will depend on how much 261 of the dCDN state needs to be pushed to the uCDN and qualitatively 262 how often that information needs to be updated. 264 2.3. Advertisement versus Queries 266 In a CDNI environment, each dCDN shares some of its state with the 267 uCDN. The uCDN uses this information to build a unified picture of 268 all of the dCDNs available to it. In architectures that share 269 detailed capability information, the uCDN could perform the entire 270 request-routing operation down to selecting a particular cache in the 271 dCDN (note: within the current CDNI WG charter, such direct selection 272 of specific caches by the uCDN is out-of-scope). However, when the 273 uCDN needs to deal with many potential dCDNs, this approach does not 274 scale, especially for dCDNs with thousands or tens of thousands of 275 caches; the volume of updates to footprint and capability becomes 276 onerous. 278 Were the volume of FCI updates from dCDNs to exceed the volume of 279 requests to the uCDN, it might make more sense for the uCDN to query 280 dCDNs upon receiving requests (as is the case in the recursive 281 redirection mode described in [RFC7336]), instead of receiving 282 advertisements and tracking the state of dCDNs. The advantage of 283 querying dCDNs would be that much of the dynamic data that dCDNs 284 cannot share with the uCDN would now be factored into the uCDN's 285 decision. dCDNs need not replicate any state to the uCDN - uCDNs 286 could effectively operate in a stateless mode. 288 The semantics of both footprint and capability advertisement depend 289 on the service model here: are there cases where a synchronous query/ 290 response model would work better for the uCDN decision than a state 291 replication model? 293 2.4. Avoiding or Handling 'cheating' dCDNs 295 In a situation where more than one dCDN is willing to serve a given 296 end user request, it might be attractive for a dCDN to 'cheat' in the 297 sense that the dCDN provides inaccurate information to the uCDN in 298 order to convince the uCDN to select it over 'competing' dCDNs. It 299 could therefore be desirable to take away the incentive for dCDNs to 300 cheat (in information advertised) as much as possible. One option is 301 to make the information the dCDN advertises somehow verifiable for 302 the uCDN. On the other hand, a cheating dCDN might be avoided or 303 handled by the fact that there will be strong contractual agreements 304 between a uCDN and a dCDN, so that a dCDN would risk severe penalties 305 or legal consequences when caught cheating. 307 Overall, the information a dCDN advertises (in the long run) needs to 308 be somehow qualitatively verifiable by the uCDN, though possibly 309 through non-real-time out-of-band audits. It is probably an overly 310 strict requirement to mandate that such verification be possible 311 "immediately", i.e., during the request routing process itself. If 312 the uCDN can detect a cheating dCDN at a later stage, it might 313 suffice for the uCDN to "de-incentivize" cheating because it would 314 negatively affect the long-term business relationship with a 315 particular dCDN. 317 2.5. Focusing on Main Use Cases 319 To narrow down semantics for "footprint" and "capabilities" in the 320 CDNI context, it can be useful to initially focus on key use cases to 321 be addressed by the CDNI WG that are to be envisioned in the main 322 deployments in the foreseeable future. In this regard, a main 323 realistic use case is the existence of ISP-owned CDNs, which 324 essentially cover a certain operator's network. At the same time, 325 however, the possibility of overlapping footprints cannot be 326 excluded, i.e., the scenario where more than one dCDN claims it can 327 serve a given end user request. The ISPs can also choose to 328 interconnect with a fallback global CDN. 330 It seems reasonable to assume that in most use cases it is the uCDN 331 that makes the decision on selecting a certain dCDN for request 332 routing based on information the uCDN has received from this 333 particular dCDN. It can be assumed that 'cheating' CDNs will be 334 dealt with via means outside the scope of CDNI and that the 335 information advertised between CDNs is accurate. In addition, 336 excluding the use of qualitative information (e.g., cache proximity, 337 delivery latency, cache load) to predict the quality of delivery 338 would further simplify the use case allowing it to better focus on 339 the basic functionality of the FCI. 341 3. Main Use Case to Consider 343 Focusing on a main use case that contains a simple (yet somewhat 344 challenging), realistic, and generally imaginable scenario can help 345 in narrowing down the requirements for the CDNI FCI. To this end, 346 the following (simplified) use case can help in clarifying the 347 semantics of footprint and capabilities for CDNI. In particular, the 348 intention of the use case is to clarify what information needs to be 349 exchanged on the CDNI FCI, what types of information need to be 350 supported in a mandatory fashion (and which can be considered 351 optional), and what types of information need to be updated with 352 respect to a priori established CDNI contracts. 354 Use case: A given uCDN has several dCDNs. It selects one dCDN for 355 delivery protocol A and footprint 1 and another dCDN for delivery 356 protocol B and footprint 1. The dCDN that serves delivery protocol B 357 has a further, transitive (level-2) dCDN, that serves delivery 358 protocol B in a subset of footprint 1 where the first-level dCDN 359 cannot serve delivery protocol B itself. What happens if 360 capabilities change in the transitive level-2 dCDN that might affect 361 how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN 362 cannot serve delivery protocol B anymore)? How will these changes be 363 conveyed to the uCDN? In particular, what information does the uCDN 364 need to be able to select a new first-level dCDN, either for all of 365 footprint 1 or only for the subset of footprint 1 that the transitive 366 level-2 dCDN served on behalf of the first-level dCDN? 368 4. Semantics for Footprint Advertisement 370 Roughly speaking, "footprint" can be defined as "ability and 371 willingness to serve" by a downstream CDN. However, in addition to 372 simple "ability and willingness to serve", the uCDN could want 373 additional information to make a dCDN selection decision, e.g., "how 374 well" a given dCDN can actually serve a given end user request. The 375 "ability and willingness" to serve SHOULD be distinguished from the 376 subjective qualitative measurement of "how well" it was served. One 377 can imagine that such additional information is implicitly associated 378 with a given footprint, due to contractual agreements, SLAs, business 379 relationships, or past perceptions of dCDN quality. As an 380 alternative, such additional information could also be explicitly 381 tagged along with the footprint. 383 It is reasonable to assume that a significant part of the actual 384 footprint advertisement will happen in contractual agreements between 385 participating CDNs, prior to the advertisement phase using the CDNI 386 FCI. The reason for this assumption is that any contractual 387 agreement is likely to contain specifics about the dCDN coverage 388 (footprint) to which the contractual agreement applies. In 389 particular, additional information to judge the delivery quality 390 associated with a given dCDN footprint might be defined in 391 contractual agreements, outside of the CDNI FCI. Further, one can 392 assume that dCDN contractual agreements about the delivery quality 393 associated with a given footprint will probably be based on high- 394 level aggregated statistics and not too detailed. 396 Given that a large part of footprint advertisement will actually 397 happen in contractual agreements, the semantics of CDNI footprint 398 advertisement refer to answering the following question: what exactly 399 still needs to be advertised by the CDNI FCI? For instance, updates 400 about temporal failures of part of a footprint can be useful 401 information to convey via the CDNI request routing interface. Such 402 information would provide updates on information previously agreed in 403 contracts between the participating CDNs. In other words, the CDNI 404 FCI is a means for a dCDN to provide changes/updates regarding a 405 footprint it has prior agreed to serve in a contract with a uCDN. 407 Generally speaking, one can imagine two categories of footprint to be 408 advertised by a dCDN: 410 o Footprint could be defined based on "coverage/reachability", where 411 coverage/reachability refers to a set of prefixes, a geographic 412 region, or similar boundary. The dCDN claims that it can cover/ 413 reach 'end user requests coming from this footprint'. 415 o Footprint could be defined based on "resources", where resources 416 refers to surrogates/caches a dCDN claims to have (e.g., the 417 location of surrogates/resources). The dCDN claims that 'from 418 this footprint' it can serve incoming end user requests. 420 For each of these footprint types, there are capabilities associated 421 with a given footprint: 423 o capabilities such as delivery protocol, redirection mode, and 424 metadata, which are supported in the coverage area for a 425 "coverage/reachability" defined footprint, or 427 o capabilities of resources, such as delivery protocol, redirection 428 mode, and metadata, which apply to a "resource" defined footprint. 430 It seems clear that "coverage/reachability" types of footprint MUST 431 be supported within CDNI. The following such types of footprint are 432 mandatory and MUST be supported by the CDNI FCI: 434 o List of ISO Country Codes 436 o List of AS numbers 438 o Set of IP-prefixes 440 A 'set of IP-prefixes' MUST be able to contain full IP addresses, 441 i.e., a /32 for IPv4 and a /128 for IPv6, as well as IP prefixes with 442 an arbitrary prefix length. There also MUST be support for multiple 443 IP address versions, i.e., IPv4 and IPv6, in such a footprint. 445 "Resource" types of footprints are more specific than "coverage/ 446 reachability" types of footprints, where the actual coverage/ 447 reachability are extrapolated from the resource location (e.g., 448 netmask applied to resource IP address to derive IP-prefix). The 449 specific methods for extrapolating coverage/reachability from 450 resource location are beyond the scope of this document. In the 451 degenerate case, the resource address could be specified as a 452 coverage/reachability type of footprint, in which case no 453 extrapolation is necessary. Resource types of footprints could 454 expose the internal structure of a CDN network which could be 455 undesirable. As such, the resource types of footprints are not 456 considered mandatory to support for CDNI. 458 For all of these mandatory-to-implement footprint types, the 459 footprints can be viewed as constraints for delegating requests to a 460 dCDN: A dCDN footprint advertisement tells the uCDN the limitations 461 for delegating a request to the dCDN. For IP prefixes or ASN(s), the 462 footprint signals to the uCDN that it SHOULD consider the dCDN a 463 candidate only if the IP address of the request routing source falls 464 within the prefix set (or ASN, respectively). The CDNI 465 specifications do not define how a given uCDN determines what address 466 ranges are in a particular ASN. Similarly, for country codes a uCDN 467 SHOULD only consider the dCDN a candidate if it covers the country of 468 the request routing source. The CDNI specifications do not define 469 how a given uCDN determines the country of the request routing 470 source. Multiple footprint constraints are additive: the 471 advertisement of different types of footprint narrows the dCDN 472 candidacy cumulatively. 474 In addition to these mandatory "coverage/reachability" types of 475 footprint, other optional "coverage/reachability" types of footprint 476 or "resource" types of footprint MAY be defined by future 477 specifications. To facilitate this, a clear process for specifying 478 optional footprint types in an IANA registry is specified in the CDNI 479 Metadata Footprint Types registry (defined in the CDNI Metadata 480 Interface document [I-D.ietf-cdni-metadata]). 482 Independent of the exact type of a footprint, a footprint might also 483 include the connectivity of a given dCDN to other CDNs that are able 484 to serve content to users on behalf of that dCDN, to cover cases with 485 cascaded CDNs. Further, the downstream CDN needs to be able to 486 express its footprint to an interested upstream CDN (uCDN) in a 487 comprehensive form, e.g., as a data set containing the complete 488 footprint. Making incremental updates, however, to express dynamic 489 changes in state is also desirable. 491 5. Semantics for Capabilities Advertisement 493 In general, the dCDN MUST be able to express its general capabilities 494 to the uCDN. These general capabilities could express if the dCDN 495 supports a given service, for instance, HTTP delivery, RTP/RTSP 496 delivery or RTMP. Furthermore, the dCDN MUST be able to express 497 particular capabilities for the delivery in a particular footprint 498 area. For example, the dCDN might in general offer RTMP but not in 499 some specific areas, either for maintenance reasons or because the 500 caches covering this particular area cannot deliver this type of 501 service. Hence, in certain cases footprint and capabilities are tied 502 together and cannot be interpreted independently from each other. In 503 such cases, i.e., where capabilities need to be expressed on a per 504 footprint basis, it could be beneficial to combine footprint and 505 capabilities advertisement. 507 A high-level and very rough semantic for capabilities is thus the 508 following: Capabilities are types of information that allow a uCDN to 509 determine if a downstream CDN is able (and willing) to accept (and 510 properly handle) a delegated content request. In addition, 511 Capabilities are characterized by the fact that this information can 512 change over time based on the state of the network or caches. 514 At a first glance, several broad categories of capabilities seem 515 useful to convey via an advertisement interface, however, advertising 516 capabilities that change highly dynamically (e.g., real-time delivery 517 performance metrics, CDN resource load, or other highly dynamically 518 changing QoS information) is beyond the scope for CDNI FCI. First, 519 out of the multitude of possible metrics and capabilities, it is hard 520 to agree on a subset and the precise metrics to be used. Second, and 521 perhaps more importantly, it seems infeasible to specify such highly 522 dynamically changing capabilities and the corresponding metrics 523 within the CDNI charter time-frame. 525 Useful capabilities refer to information that does not change highly 526 dynamically and which in many cases is absolutely necessary to decide 527 on a particular dCDN for a given end user request. For instance, if 528 an end user request concerns the delivery of a video file with a 529 certain protocol (e.g., RTMP), the uCDN needs to know if a given dCDN 530 has the capability of supporting this delivery protocol. 532 Similar to footprint advertisement, it is reasonable to assume that a 533 significant part of the actual (resource) capabilities advertisement 534 will happen in contractual agreements between participating CDNs, 535 i.e., prior to the advertisement phase using the CDNI FCI. The role 536 of capability advertisement is hence rather to enable the dCDN to 537 update a uCDN on changes since a contract has been set up (e.g., in 538 case a new delivery protocol is suddenly being added to the list of 539 supported delivery protocols of a given dCDN, or in case a certain 540 delivery protocol is suddenly not being supported anymore due to 541 failures). Capabilities advertisement thus refers to conveying 542 information to a uCDN about changes/updates of certain capabilities 543 with respect to a given contract. 545 Given these semantics, it needs to be decided what exact capabilities 546 are useful and how these can be expressed. Since the details of CDNI 547 contracts are not known at the time of this writing (and the CDNI 548 interface are better off being agnostic to these contracts anyway), 549 it remains to be seen what capabilities will be used to define 550 agreements between CDNs in practice. One implication for 551 standardization could be to initially only specify a very limited set 552 of mandatory capabilities for advertisement and have on top of that a 553 flexible data model that allows exchanging additional capabilities 554 when needed. Still, agreement needs to be found on which 555 capabilities (if any) will be mandatory among CDNs. As discussed in 556 Section 2.5, finding the concrete answers to these questions can 557 benefit from focusing on a small number of key use cases that are 558 highly relevant and contain enough complexity to help in 559 understanding what concrete capabilities are needed to facilitate CDN 560 Interconnection. 562 Under the above considerations, the following capabilities seem 563 useful as 'base' capabilities, i.e., ones that are needed in any case 564 and therefore constitute mandatory capabilities that MUST be 565 supported by the CDNI FCI: 567 o Delivery Protocol (e.g., HTTP vs. RTMP) 569 o Acquisition Protocol (for acquiring content from a uCDN) 571 o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 572 discussed in [RFC7336]) 574 o CDNI Logging (i.e., supported logging fields) 576 o CDNI Metadata (i.e., supported Generic Metadata types) 578 It is not feasible to enumerate all the possible options for the 579 mandatory capabilities listed above (e.g., all the potential delivery 580 protocols or metadata options) or anticipate all the future needs for 581 additional capabilities. It would be unreasonable to burden the CDNI 582 FCI specification with defining each supported capability. Instead, 583 the CDNI FCI specification SHOULD define a generic protocol for 584 conveying any capability information (e.g. with common encoding, 585 error handling, and security mechanism; further requirements for the 586 CDNI FCI Advertisement Interface are listed in [RFC7337]). In this 587 respect, it seems reasonable to define a registry which initially 588 contains the mandatory capabilities listed above, but can be extended 589 as needs dictate. This document defines the registry (and the rules 590 for adding new entries to the registry) for the different capability 591 types (see Section 8). Each capability type MAY have a list of valid 592 values. Future specifications which define a given capability MUST 593 define any necessary registries (and the rules for adding new entries 594 to the registry) for the values advertised for a given capability 595 type. 597 The "CDNI Logging Fields Names" registry defines all supported 598 logging fields, including mandatory-to-implement logging fields. 599 Advertising support for mandatory-to-implement logging fields SHOULD 600 be supported but would be redundant. CDNs SHOULD NOT advertise 601 support for mandatory-to-implement logging fields. The following 602 logging fields are defined as optional in the CDNI Logging Interface 603 document [I-D.ietf-cdni-logging]: 605 o s-ccid 607 o s-sid 609 The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does 610 not define any optional GenericMetadata types. Advertising support 611 for mandatory-to-implement GenericMetadata types SHOULD be supported. 612 Advertisement of mandatory-to-implement GenericMetadata MAY be 613 necessary, e.g., to signal temporary outages and subsequent recovery, 614 however, it is expected that mandatory-to-implement GenericMetadata 615 will be supported and available in the typical case. In the typical 616 case, advertising support for mandatory-to-implement GenericMetadata 617 would be redundant, therefore, CDNs SHOULD NOT advertise support for 618 mandatory-to-implement GenericMetadata types by default. 620 6. Negotiation of Support for Optional Types of Footprint/Capabilities 622 The notion of optional types of footprint and capabilities implies 623 that certain implementations might not support all kinds of footprint 624 and capabilities. Therefore, any FCI solution protocol MUST define 625 how the support for optional types of footprint/capabilities will be 626 negotiated between a uCDN and a dCDN that use the particular FCI 627 protocol. In particular, any FCI solution protocol MUST specify how 628 to handle failure cases or non-supported types of footprint/ 629 capabilities. 631 In general, a uCDN MAY ignore capabilities or types of footprints it 632 does not understand; in this case it only selects a suitable 633 downstream CDN based on the types of capabilities and footprint it 634 understands. Similarly, if a dCDN does not use an optional 635 capability or footprint which is, however, supported by a uCDN, this 636 causes no problem for the FCI functionality because the uCDN decides 637 on the remaining capabilities/footprint information that is being 638 conveyed by the dCDN. 640 7. Capability Advertisement Object 642 To support extensibility, the FCI defines a generic base object 643 (similar to the CDNI Metadata interface GenericMetadata object) 644 [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory 645 parsing requirements for all future FCI objects. 647 Future object definitions (e.g. regarding CDNI Metadata or Logging) 648 will build off the base object defined here, but will be specified in 649 separate documents. 651 7.1. Base Advertisement Object 653 The FCIBase object is an abstraction for managing individual CDNI 654 capabilities in an opaque manner. 656 Property: capability-type 658 Description: CDNI Capability object type. 660 Type: FCI specific CDNI Payload type (from the CDNI Payload 661 Types registry [RFC7736]) 663 Mandatory-to-Specify: Yes. 665 Property: capability-value 667 Description: CDNI Capability object. 669 Type: Format/Type is defined by the value of capability-type 670 property above. 672 Mandatory-to-Specify: Yes. 674 7.2. Delivery Protocol Capability Object 676 The Delivery Protocol capability object is used to indicate support 677 for one or more of the protocols listed in the CDNI Metadata Protocol 678 Types registry (defined in the CDNI Metadata Interface document 679 [I-D.ietf-cdni-metadata]). 681 Property: delivery-protocols 683 Description: List of supported CDNI Delivery Protocols. 685 Type: List of Protocol Types (from the CDNI Metadata Protocol 686 Types registry [I-D.ietf-cdni-metadata]) 688 Mandatory-to-Specify: Yes. 690 7.3. Acquisition Protocol Capability Object 692 The Acquisition Protocol capability object is used to indicate 693 support for one or more of the protocols listed in the CDNI Metadata 694 Protocol Types registry (defined in the CDNI Metadata Interface 695 document [I-D.ietf-cdni-metadata]). 697 Property: acquisition-protocols 699 Description: List of supported CDNI Acquisition Protocols. 701 Type: List of Protocol Types (from the CDNI Metadata Protocol 702 Types registry [I-D.ietf-cdni-metadata]) 704 Mandatory-to-Specify: Yes. 706 7.4. Redirection Mode Capability Object 708 The Redirection Mode capability object is used to indicate support 709 for one or more of the modes listed in the CDNI Capabilities 710 Redirection Modes registry (see Section 8.2). 712 Property: redirection-modes 714 Description: List of supported CDNI Redirection Modes. 716 Type: List of Redirection Modes (from Section 8.2) 717 Mandatory-to-Specify: Yes. 719 7.5. Capability Advertisement Object Serialization 721 The following shows an example of CDNI FCI Capability Advertisement 722 Object Serialization. 724 { 725 "capabilities": [ 726 { 727 "capability-type": "FCI.DeliveryProtocol" 728 "capability-value": { 729 "delivery-protocols": [ 730 "http1.1" 731 ] 732 } 733 }, 734 { 735 "capability-type": "FCI.AcquisitionProtocol" 736 "capability-value": { 737 "acquisition-protocols": [ 738 "http1.1", 739 "https1.1" 740 ] 741 } 742 }, 743 { 744 "capability-type": "FCI.RedirectionMode" 745 "capability-value": { 746 "redirection-modes": [ 747 "DNS-I", 748 "HTTP-I" 749 ] 750 } 751 } 752 ] 753 } 755 8. IANA Considerations 757 8.1. CDNI Payload Types 759 This document requests the registration of the following CDNI Payload 760 Types under the IANA CDNI Payload Type registry: 762 +-------------------------+---------------+ 763 | Payload Type | Specification | 764 +-------------------------+---------------+ 765 | FCI.DeliveryProtocol | RFCthis | 766 | | | 767 | FCI.AcquisitionProtocol | RFCthis | 768 | | | 769 | FCI.RedirectionMode | RFCthis | 770 +-------------------------+---------------+ 772 [RFC Editor: Please replace RFCthis with the published RFC number for 773 this document.] 775 8.1.1. CDNI FCI DeliveryProtocol Payload Type 777 Purpose: The purpose of this payload type is to distinguish FCI 778 advertisement objects for supported delivery protocols 780 Interface: FCI 782 Encoding: see Section 7.2 and Section 7.5 784 8.1.2. CDNI FCI AcquisitionProtocol Payload Type 786 Purpose: The purpose of this payload type is to distinguish FCI 787 advertisement objects for supported acquisition protocols 789 Interface: FCI 791 Encoding: see Section 7.3 and Section 7.5 793 8.1.3. CDNI FCI RedirectionMode Payload Type 795 Purpose: The purpose of this payload type is to distinguish FCI 796 advertisement objects for supported redirection modes 798 Interface: FCI 800 Encoding: see Section 7.4 and Section 7.5 802 8.2. Redirection Mode Registry 804 The IANA is requested to create a new "CDNI Capabilities Redirection 805 Modes" registry in the "Content Delivery Networks Interconnection 806 (CDNI) Parameters" category. The "CDNI Capabilities Redirection 807 Modes" namespace defines the valid redirection modes that can be 808 advertised as supported by a CDN. Additions to the Redirection Mode 809 namespace conform to the "IETF Review" policy as defined in 810 [RFC5226]. 812 The following table defines the initial Redirection Modes: 814 +------------------+----------------------------------+---------+ 815 | Redirection Mode | Description | RFC | 816 +------------------+----------------------------------+---------+ 817 | DNS-I | Iterative DNS-based Redirection | RFCthis | 818 | | | | 819 | DNS-R | Recursive DNS-based Redirection | RFCthis | 820 | | | | 821 | HTTP-I | Iterative HTTP-based Redirection | RFCthis | 822 | | | | 823 | HTTP-R | Recursive HTTP-based Redirection | RFCthis | 824 +------------------+----------------------------------+---------+ 826 [RFC Editor: Please replace RFCthis with the published RFC number for 827 this document.] 829 9. Security Considerations 831 This specification describes the semantics for capabilities and 832 footprint advertisement objects across interconnected CDNs. It does 833 not, however, specify a concrete protocol for transporting those 834 objects. Specific security mechanisms can only be selected for 835 concrete protocols that instantiate these semantics. This document 836 does, however, place some high-level security constraints on such 837 protocols. 839 All protocols that implement these semantics are REQUIRED to provide 840 integrity and authentication services. Without authentication and 841 integrity, an attacker could trivially deny service by forging a 842 footprint advertisement from a dCDN which claims the network has no 843 footprint or capability. This would prevent the uCDN from delegating 844 any requests to the dCDN. Since a pre-existing relationship between 845 all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary 846 credentials could be conducted before the FCI interface is brought 847 online. The authorization decision to accept advertisements would 848 also follow this pre-existing relationship and any contractual 849 obligations that it stipulates. 851 It is not believed that there are any serious privacy risks in 852 sharing footprint or capability information: it will represent highly 853 aggregated data about networks and, at best, policy-related 854 information about media, rather than any personally identifying 855 information. However, particular dCDNs could be willing to share 856 information about their footprint with a uCDN but not with other, 857 competing dCDNs. For example, if a dCDN incurs an outage that 858 reduces footprint coverage temporarily, that could be information the 859 dCDN would want to share confidentially with the uCDN. Protocols 860 implementing these semantics SHOULD provide confidentiality services. 862 As specified in this document, the security requirements of the FCI 863 could be met by hop-by-hop transport-layer security mechanisms 864 coupled with domain certificates as credentials. There is no 865 apparent need for further object-level security in this framework, as 866 the trust relationships it defines are bilateral relationships 867 between uCDNs and dCDNs rather than transitive relationships. 869 10. References 871 10.1. Normative References 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels", BCP 14, RFC 2119, 875 DOI 10.17487/RFC2119, March 1997, 876 . 878 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 879 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 880 DOI 10.17487/RFC5226, May 2008, 881 . 883 10.2. Informative References 885 [I-D.ietf-cdni-logging] 886 Faucheur, F., Bertrand, G., Oprescu, I., and R. 887 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 888 logging-22 (work in progress), March 2016. 890 [I-D.ietf-cdni-metadata] 891 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 892 "CDN Interconnection Metadata", draft-ietf-cdni- 893 metadata-12 (work in progress), October 2015. 895 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 896 Distribution Network Interconnection (CDNI) Problem 897 Statement", RFC 6707, DOI 10.17487/RFC6707, September 898 2012, . 900 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 901 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 902 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 903 November 2012, . 905 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 906 "Framework for Content Distribution Network 907 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 908 August 2014, . 910 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 911 Network Interconnection (CDNI) Requirements", RFC 7337, 912 DOI 10.17487/RFC7337, August 2014, 913 . 915 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 916 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 917 December 2015, . 919 Appendix A. Acknowledgment 921 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 922 Architecture and Applications of Green Information Centric 923 Networking), a research project supported jointly by the European 924 Commission under its 7th Framework Program (contract no. 608518) and 925 the National Institute of Information and Communications Technology 926 (NICT) in Japan (contract no. 167). The views and conclusions 927 contained herein are those of the authors and should not be 928 interpreted as necessarily representing the official policies or 929 endorsements, either expressed or implied, of the GreenICN project, 930 the European Commission, or NICT. 932 Martin Stiemerling provided initial input to this document and 933 valuable comments to the ongoing discussions among the authors of 934 this document. Thanks to Francois Le Faucheur and Scott Wainner for 935 providing valuable comments and suggestions to the text. 937 Authors' Addresses 939 Jan Seedorf 940 NEC 941 Kurfuerstenanlage 36 942 Heidelberg 69115 943 Germany 945 Phone: +49 6221 4342 221 946 Fax: +49 6221 4342 155 947 Email: seedorf@neclab.eu 948 Jon Peterson 949 NeuStar 950 1800 Sutter St Suite 570 951 Concord CA 94520 952 USA 954 Email: jon.peterson@neustar.biz 956 Stefano Previdi 957 Cisco Systems 958 Via Del Serafico 200 959 Rome 0144 960 Italy 962 Email: sprevidi@cisco.com 964 Ray van Brandenburg 965 TNO 966 Brassersplein 2 967 Delft 2612CT 968 The Netherlands 970 Phone: +31-88-866-7000 971 Email: ray.vanbrandenburg@tno.nl 973 Kevin J. Ma 974 Ericsson 975 43 Nagog Park 976 Acton, MA 01720 977 USA 979 Phone: +1 978-844-5100 980 Email: kevin.j.ma@ericsson.com