CDNI Request Routing: Footprint and Capabilities Semantics
Author(s): Stefano Previdi, Kevin Ma, Jon Peterson, Jan Seedorf, Ray van Brandenburg
This document tries to capture the semantics of the 'Footprint and Capabilities Advertisement' part of the CDNI Request Routing interface, i.e. the desired meaning and what 'Footprint and Capabilities Advertisement' is expected to offer within CDNI. The discussion...
CDNI J. Seedorf Internet-Draft NEC Intended status: Informational J. Peterson Expires: August 29, 2013 Neustar S. Previdi Cisco R. van Brandenburg TNO K. Ma Azuki Systems, Inc. February 25, 2013 CDNI Request Routing: Footprint and Capabilities Semantics draft-spp-cdni-rr-foot-cap-semantics-04 Abstract This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Seedorf, et al. Expires August 29, 2013 [Page 1] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and scope . . . . . . . . . . . . . . . . . . . . 3 2. CDNI FCI in existing CDNI Documents . . . . . . . . . . . . . 4 3. Design Decisions for Footprint and Capabilities . . . . . . . 7 3.1. Advertising Limited Coverage . . . . . . . . . . . . . . . 7 3.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 8 3.3. Advertisement versus Queries . . . . . . . . . . . . . . . 9 3.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 9 3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 10 4. Main Use Case to foster the Clarification of Semantics . . . . 11 5. Towards Semantics for Footprint Advertisement . . . . . . . . 12 6. Towards Semantics for Capabilities Advertisement . . . . . . . 14 7. Open Issues and Questions . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Seedorf, et al. Expires August 29, 2013 [Page 2] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 1. Introduction and scope The CDNI working group is working on a set of protocols to enable the interconnection of multiple CDNs to a CDN federation. This CDN- federation should serve multiple purposes, as discussed in [RFC6770], for instance, to extend the reach of a given CDN to areas in the network which are not covered by this particular CDN. The goal of this document is to achieve a clear understanding in the CDNI WG about the semantics associated with the CDNI Request Routing Footprint & Capabilities Advertisement Interface (from now on referred to as FCI), in particular the type of information a downstream CDN 'advertises' regarding its footprint and capabilities. To narrow down undecided aspects of these semantics, this document tries to establish a common understanding of what the FCI should offer and accomplish in the context of CDN Interconnection. It is explicitly outside the scope of this document to decide on specific protocols to use for the FCI. General assumptions in this document: o The CDNs participating in the CDN federation have already performed a boot strap process, i.e., they have connected to each other, either directly or indirectly, and can exchange information amongst each other. o The uCDN has received footprint and/or capability advertisements from a set of dCDNs. Footprint advertisement and capability advertisement need not use the same underlying protocol. o The upstream CDN (uCDN) receives the initial request-routing request from the endpoint requesting the resource. This document is organized as follows. First, a recap of the definition of "footprint and capabilities advertisement" in existing documents is given, attempting to distill the apparent common understanding of what the terms 'footprint' and 'capabilities' mean in the context of CDNI. Then, the detailed semantics of the footprint advertisement mechanism and the capability advertisement mechanism will be discussed. Finally, open issues and questions to be discussed in the CDNI WG will be listed. Seedorf, et al. Expires August 29, 2013 [Page 3] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 2. CDNI FCI in existing CDNI Documents In the following section, the existing descriptions of the CDNI FCI interface in existing documents will be examined. After this, the apparent common understanding of what this interface is intended to offer and accomplish will be carved out. The CDNI Problem Statement [RFC6707] describes footprint and capabilities advertisement as: "[enabling] a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request". In addition, the draft says "the CDNI Request Routing interface is also expected to enable a downstream CDN to provide to the upstream CDN (static or dynamic) information (e.g. resources, footprint, load) to facilitate selection of the downstream CDN by the upstream CDN request routing system when processing subsequent content requests from User Agents". It thus considers "resources" and "load" as capabilities to be advertised by the downstream CDN. The CDNI Use Cases document [RFC6770] describes capabilities as "... supported range of devices and User Agents or the supported range of delivery technologies". Examples for such capabilities given are specific delivery protocols, technology migration, and meeting a certain QoS. The CDNI requirements draft [I-D.ietf-cdni-requirements] lists several requirements relevant for the "footprint and capabilities advertisement" part of the CDNI request routing interface. In summary, the following requirements for the CDNI Request Routing Interface and general requirements are relevant for the understanding of the semantics of "footprint and capabilities advertisement": o GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc." o GEN-9 [MED], "The CDNI solution should support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels beyond the first level." o GEN-10 [MED], "The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e. the CDN topology cannot be restricted to a tree, a loop-free topology, etc.)." Seedorf, et al. Expires August 29, 2013 [Page 4] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 o GEN-11 [HIGH], "The CDNI solution shall prevent looping of any CDNI information exchange." o REQ-1 [HIGH], allowing the downstream CDN "to communicate to the Upstream CDN coarse information about the Downstream CDN ability and/or willingness to handle requests from the Upstream CDN. For example, this could potentially include a binary signal ("Downstream CDN ready/not-ready to take additional requests from Upstream CDN") to be used in case of excessive load or failure condition in the Downstream CDN." o REQ-2 [MED], allowing the downstream CDN to communicate capabilities such as supported content types and delivery protocols, a set of metrics/attributes (e.g. Streaming bandwidth, storage resources, distribution and delivery priority), a set of affinities (e.g. Preferences, indication of distribution/delivery fees), information to facilitate request redirection, as well as footprint information (e.g. "layer-3 coverage"). o REQ-3 [MED], "In the case of cascaded redirection, the CDNI Request-Routing interface shall allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Request- Routing interface shall prevent looping of such information exchange." o REQ-4 [LOW], allowing the downstream CDN to communicate "aggregate information on CDNI administrative limits and policy" (e.g. the maximum number of requests redirected by the Upstream CDN to be served simultaneously by the Downstream CDN or maximum aggregate volume of content (e.g. in Terabytes) to be delivered by the Downstream CDN over a time period). o REQ-11 [LOW], "The CDNI Request-Routing protocol may support a mechanism allowing an Upstream CDN to avoid redirecting a request to a Downstream CDN if that is likely to result in the total redirection time exceeding some limit." Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of what "footprint" information might convey in the CDNI requirements draft [I-D.ietf-cdni-requirements]. Also, note that REQ-3 [MED] addresses cascaded (transitive) downstream CDNs. In such a case, a downstream CDN needs to include (in its advertisement information that it conveys to an upstream CDN) aggregate footprint and capabilities information for any further transitive downstream CDNs. Such information may be included implicitly (i.e. the cascaded dCDN Seedorf, et al. Expires August 29, 2013 [Page 5] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 is oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of the fact that there is a cascaded dCDN is visible to the uCDN). In either case, logic is needed to process incoming footprint information from a cascaded dCDN and decide if/how it is to be re- advertised/aggregated when advertising footprint to an upstream CDN. The CDNI framework draft [I-D.ietf-cdni-framework] describes a "footprint" as in [I-D.previdi-cdni-footprint-advertisement], consisting of two parts: 1) "a class of end user requests (represented, for example, by a set of IP prefixes, or a geographic region) that the dCDN is willing and able to serve directly, without use of another dCDN", and 2) "the connectivity of the dCDN to other CDNs that may be able to serve content to users on behalf of dCDN". The term "connectivity" has recently been replaced with "reachability" in [I-D.previdi-cdni-footprint-advertisement], and as discussed above, "without use of another dCDN" may include aggregated transitive dCDNs. Further examples for capabilities are "the ability to handle certain types of content (e.g. specific streaming formats) or quality of service (QoS)." Content handling capabilities discussed in [I-D.ma-cdni-capabilities] include delivery and acquisition protocols, redirection modes, and metadata related capabilities (e.g., authorization algorithm). From reading the various draft listed above, it is safe to conclude that neither the term 'footprint' nor 'capabilities' has been clearly and unambiguously defined in these documents and a very broad range of potential capabilities is listed. Seedorf, et al. Expires August 29, 2013 [Page 6] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 3. Design Decisions for Footprint and Capabilities A large part of the difficulty in discussing the FCI lies in understanding what exactly is meant when trying to define footprint in terms of "coverage" or "reachability." While the operators of CDNs pick strategic locations to situate caches, a cache with a public IPv4 address is reachable by any endpoint on the Internet unless some policy enforcement precludes the use of the cache. Some CDNs aspire to cover the entire world, which we will henceforth call global CDNs. The footprint advertised by such a CDN in the CDNI environment would, from a coverage or reachability perspective, presumably cover all prefixes. Potentially more interesting for CDNI use cases, however, are CDNs that claim a more limited coverage, but seek to federate with other CDNs in order to create a single CDN fabric which shares resources. Futhermore, not all capabilties need be footprint restricted. Depending upon the use case, the optimal semantics of "footprints with capability attributes" vs. "capabilities with footprint restrictions" are not clear. The key to understanding the semantics of footprint and capability advertisement lies in understand why a dCDN would advertise a limited coverage area, and how a uCDN would use such advertisements to decide among one of several dCDNs. The following section will discuss some of the trade-offs and design decisions that need to be decided upon for the CDNI FCI. 3.1. Advertising Limited Coverage The basic use case that would motivate a dCDN to advertise a limited coverage is that the CDN was built to cover only a particular portion of the Internet. For example, an ISP could purpose-build a CDN to serve only their own customers by situating caches in close topological proximity to high concentrations of their subscribers. The ISP knows the prefixes it has allocated to end users and thus can easily construct a list of prefixes that its caches were positioned to serve. When such a purpose-built CDN joins a federation, however, and advertises its footprint to a uCDN, the original intended coverage of the CDN might not represent its actual value to the federation of CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, which they federate through CDNI. A given user E, who is customer of ISP-B, might happen to be topologically closest to a cache fielded by ISP-A, if E happens to live in a region where ISP-B has few customers and ISP-A has many. In this case, should ISP-A's CDN "cover" E? If Seedorf, et al. Expires August 29, 2013 [Page 7] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 ISP-B's CDN has a failure condition, should the uCDN understand that ISP-A's caches are potentially available back-ups - and if so, how does ISP-A advertise itself as a "standby" for E? What about the case where CDNs advertising to the same uCDN express overlapping coverage (for example, a federation mixing global and limited CDNs)? The answers to these questions greatly depend on how much information we want the uCDN to use to make a selection of a dCDN. If a uCDN has three dCDNs to choose from that "cover" the IP address of user E, obviously the uCDN might be interested to know how optimal the coverage is from each of the dCDNs - coverage need not be binary, either provided or not provided. dCDNs could advertise a coverage "score," for example, and provided that they all reported scores fairly on the same scale, uCDNs could use that to make their topological optimality decision. Alternatively, dCDNs could for their footprint advertise the IP addresses of their caches rather than prefix "coverage," and let the uCDN decide for itself (based on its own topological intelligence) which dCDN has better resources to serve a given user. In summary, the semantics of advertising footprint depend on whether such qualitative metrics for expressing footprint (such as the coverage 'score' mentioned above) should be part of the CDNI FCI, or if it should focus just on 'binary' footprint. 3.2. Capabilities and Dynamic Data In cases where the apparent footprint of dCDNs overlaps, uCDNs might also want to rely on a host of other factors to evaluate the respective merits of dCDNs. These include facts related to the caches themselves, to the network where the cache is deployed, to the nature of the resource sought and to the administrative policies of the respective networks. In the absence of network-layer impediments to reaching caches, the choice to limit coverage is necessarily an administrative policy. Much policy must be agreed upon before CDNs can merge into federations, including questions of membership, compensation, volumes and so on. A uCDN certainly will factor these sorts of considerations into its decision to select a dCDN, but there is probably little need for dCDNs to actually advertise them through an interface - they will be settled out of band as a precondition for federating. Other facts about the dCDN would be expressed through the interface to the uCDN. Some capabilities of a dCDN are static, and some are highly dynamic. Expressing the total storage built into its caches, for example, changes relatively rarely, whereas the amount storage in Seedorf, et al. Expires August 29, 2013 [Page 8] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 use at any given moment is highly volatile. Network bandwidth similarly could be expressed as either total bandwidth available to a cache, or based on the current state of the network. A cache may at one moment lack a particular resource in storage, but have it the next. The semantics of the capabilities interface will depend on how much of the dCDN state needs to be pushed to the uCDN and qualitatively how often that information should be updated. 3.3. Advertisement versus Queries In a federated CDN environment, each dCDN shares some of its state with the uCDN, which the uCDN uses to build a unified picture of all of the dCDNs available to it. In architectures that share detailed capability information, the uCDN could basically perform the entire request-routing intelligence down to selecting a particular cache before sending the request to the dCDN (note that within the current CDNI WG scope, such direct selection of specific caches by the uCDN is out of scope). However, when the uCDN must deal with many potential dCDNs, this approach does not scale. Especially as CDNs scale up from dozens or hundreds of caches to thousands or tens of thousands, the volume of updates to footprint and capability may become onerous. Were the volume of updates to exceed the volumes of requests to the uCDN, it might make more sense for the uCDN to query dCDNs upon receiving requests (as is the case in the recursive redirection mode described in [I-D.ietf-cdni-framework]), instead of receiving advertisements and tracking the state of dCDNs itself. The advantage of querying dCDNs would be that much of the dynamic data that dCDNs cannot share with the uCDN would now be factored into the uCDN's decision. dCDNs need not replicate any state to the uCDN - uCDNs could effectively operate in a stateless mode. The semantics of both footprint and capability advertisement depend on the service model here: are there cases where a synchronous query/ response model would work better for the uCDN decision than a state replication model? 3.4. Avoiding or Handling 'cheating' dCDNs In a situation where more than one dCDN is willing to serve a given end user request, it might be attractive for a dCDN to 'cheat' in the sense that the dCDN provides inaccurate information to the uCDN in order to convince the uCDN to select it opposed to 'competing' dCDNs. It could therefore be desirable to take away the incentive for dCDNs to cheat (in information advertised) as much as possible. One option Seedorf, et al. Expires August 29, 2013 [Page 9] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 here is to make the information the dCDN advertises somehow verifiable for the uCDN. One the other hand, a cheating dCDN might be avoided or handled by the fact that there will be strong contractual agreements between a uCDN and a dCDN, so that a dCDN would risk severe penalties or legal consequences when caught cheating. Overall, it seems that information a dCDN advertises should (in the long run) be somehow qualitatively verifiable by the uCDN, though possibly through non-real-time out-of-band audits. It is probably an overly strict requirement to mandate that such verification be possible "immediately", i.e. during the request routing process itself. If the uCDN can detect a cheating dCDN at a later stage, it should suffice for the uCDN to "de-incentivize" cheating because it would negatively affect the long-term business relationship with a particular dCDN. 3.5. Focus on Main Use Cases may Simplify Things To narrow down semantics for "footprint" and "capabilities" in the CDNI context, it can be useful to initially focus on key use cases to be addressed by the CDNI WG that are to be envisioned the main deployments in the foreseeable future. In this regard, a main realistic use case is the existence of ISP-owned CDNs, which essentially cover a certain operator's network. At the same time, however, the possibility of overlapping footprints should not be excluded, i.e. the scenario where more than one dCDN claims it can serve a given end user request. The ISPs may also choose to federate with a fallback global CDN. It seems reasonable to assume that in most use cases it is the uCDN that makes the decision on selecting a certain dCDN for request routing based on information the uCDN has received from this particular dCDN. It may be assumed that 'cheating' CDNs will be dealt with via means outside the scope of CDNI and that the information advertised between CDNs is accurate. In addition, excluding the use of qualitative information (e.g., cache proximity, delivery latency, cache load) to to predict the quality of delivery would further simplify the use case allowing it to better focus on the basic functionality of the FCI. Seedorf, et al. Expires August 29, 2013 [Page 10] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 4. Main Use Case to foster the Clarification of Semantics Focusing on a main use case that contains a simple (yet somewhat challenging), realistic, and generally imaginable scenario can help in narrowing down the requirements for the CDNI FCI. To this end, the following (simplified) use case can help in clarifying the semantics of footprint and capabilities for CDNI. In particular, the intention of the use case is to clarify what information needs to be exchanged on the CDNI FCI, what types of information need to be supported in a mandatory fashion (and which should be considered optional), and what types of information need to be updated with respect to a priori established CDNI contracts. In short, one can imagine the following use case: A given uCDN has several dCDNs. It selects one dCDN for delivery protocol A and footprint 1 and another dCDN for delivery protocol B and footprint 1. The dCDN that serves delivery protocol B has a further, transitive (level-2) dCDN, that serves delivery protocol B in a subset of footprint 1 where the first-level dCDN cannot serve delivery protocol B itself. What happens if capabilities change in the transitive level-2 dCDN that might affect how the uCDN selects a level-1 dCDN (e.g. in case the level-2 dCDN cannot serve delivery protocol B anymore)? How will these changes be conveyed to the uCDN? In particular, what information does the uCDN need to be able to select a new first-level dCDN, either for all of footprint 1 or only for the subset of footprint 1 that the transitive level-2 dCDN served on behalf of the first-level dCDN? Seedorf, et al. Expires August 29, 2013 [Page 11] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 5. Towards Semantics for Footprint Advertisement Roughly speaking, "footprint" can be defined as "ability and willingness to serve" by a downstream CDN. However, in addition to simple "ability and willingness to serve", the uCDN may wish to have additional information to make a dCDN selection decision, e.g., "how well" a given dCDN can actually serve a given end user request. The "ability and willingness" to serve should be distinguished from the subjective qualitative measurement of "how well" it was served. One can imagine that such additonal information is implicitly associated with a given footprint, e.g. due to contractual agreements (e.g. SLAs), business relationships, or perceived dCDN quality in the past. As an alternative, such additional information could also be explicitly tagged along with the footprint. It is reasonable to assume that a significant part of the actual footprint advertisement will happen in contractual agreements between participating CDNs, i.e. prior to the advertisement phase using the CDNI FCI. The reason for this assumption is that any contractual agreement is likely to contain specifics about the dCDN coverage (i.e. the dCDN footprint) the contractual agreement applies to. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements (i.e. outside of the CDNI FCI). Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high-level aggregated statistics (i.e. not too detailed). Given that a large part of footprint advertisement will actually happen in contractual agreements, the semantics of CDNI footprint advertisement refer to answering the following question: what exactly still needs to be advertised by the CDNI FCI? For instance, updates about temporal failures of part of a footprint can be useful information to convey via the CDNI request routing interface. Such information would provide updates on information previously agreed in contracts between the participating CDNs. In other words, the CDNI FCI is a means for a dCDN to provide changes/updates regarding a footprint it has prior agreed to serve in a contract with a uCDN. Generally speaking, one can imagine two categories of footprint to be advertised by a dCDN: o Footprint could be defined based on (layer-3) "coverage/ reachability", where coverage/reachability refers to a set of prefixes, a geographic region, or similar boundary. The dCDN claims that it can cover/reach 'end user requests coming from this footprint'. Seedorf, et al. Expires August 29, 2013 [Page 12] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 o Footprint could be defined based on "resources", where resources refers to surrogates/caches a dCDN claims to have (e.g., the location of surrogates/resources). The dCDN claims that 'from this footprint' it can serve incoming end user requests. For each of these footprint types, there are capabilities associated with a given footprint, i.e. the capabilities (e.g., delivery protocol, redirection mode, metadata) supported in the coverage area for a "coverage/reachability" defined footprint, or the capabilities of resources (e.g., delivery protocol, redirection mode, metadata support) for a "resources" defined footprint. It seems clear that "coverage/reachability" types of footprint must be supported within CDNI. It needs to be decided, whether - in addition to "coverage/ reachability" types - also "resource" types of footprint should be supported within CDNI. Different concrete candidates for a "coverage/reachability" footprint are imaginable. In particular, the following concrete types of footprint seem useful in the CDNI context: 'set of IP-prefixes', 'AS number list', and 'geographic region'. Among these, 'set of IP- prefixes' must be able to contain full IP addresses (i.e., a /32 for IPv4 and a /128 for IPv6) and also IP prefixes with an arbitrary prefix length. There must also be support for multiple IP address versions, i.e., IPv4 and IPv6, in the footprint. Independent of the exact type of a footprint, a footprint might also include the connectivity of a given dCDN to other CDNs that may be able to serve content to users on behalf of that dCDN, to cover cases where there is a transitive CDN interconnection. Further, the downstream CDN must be able to express its footprint to an interested upstream CDN (uCDN) in a comprehensive form, e.g., as a complete data set containing the complete footprint. Making incremental updates, however, to express dynamic changes in state is also desirable. Seedorf, et al. Expires August 29, 2013 [Page 13] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 6. Towards Semantics for Capabilities Advertisement In general, the dCDN must be able to express its general capabilities to the uCDN. These general capabilities could express if the dCDN supports a given service, for instance, HTTP delivery, RTP/RTSP delivery or RTMP. Furthermore, the dCDN must be able to express particular capabilities for the delivery in a particular footprint area. For example, the dCDN might in general offer RTMP but not in some specific areas, either for maintenance reasons or because the caches covering this particular area cannot deliver this type of service. Hence, in certain cases footprint and capabilities are tied together and cannot be interpreted independently from each other. In such cases, i.e. where capabilities must be expressed on a per footprint basis, it may be beneficial to combine footprint and capabilities advertisement. A high-level and very rough semantic for capabilities is thus the following: Capabilities are types of information that allow a uCDN to determine if a downstream CDN is able (and willing) to accept (and properly handle) a delegated content request. In addition, Capabilities are characterized by the fact that this information may possibly change over time based on the state of the network or caches. At a first glance, several broad categories of capabilities seem useful to convey via an advertisement interface (and indeed many such candidate capabilities have been suggested in CDNI drafts, see Section 2). However, advertising capabilities that change highly dynamically (e.g. real-time delivery performance metrics, CDN resource load, or other highly dynamically changing QoS information) should probably not be in scope for the CDNI FCI. First, out of the multitude of possible metrics and capabilities, it is hard to agree on a subset and the precise metrics to be used. Second, and perhaps more importantly, it seems not feasible to specify such highly dynamically changing capabilities and the corresponding metrics within the CDNI charter time-frame. Useful capabilities refer to information that does not change highly dynamically and which in many cases is absolutely necessary to decide on a particular dCDN for a given end user request. For instance, if an end user request concerns the delivery of a video file with a certain protocol (e.g. RTMP), the uCDN needs to know if a given dCDN has the capabiltity of supporting this delivery protocol. Similar to footprint advertisement, it is reasonable to assume that a significant part of the actual (resource) capabilities advertisement will happen in contractual agreements between participating CDNs, i.e. prior to the advertisement phase using the CDNI FCI. The role Seedorf, et al. Expires August 29, 2013 [Page 14] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 of capability advertisement is hence rather to enable the dCDN to update a uCDN on changes since a contract has been set up (e.g. in case a new delivery protocol is suddenly being added to the list of supported delivery protocols of a given dCDN, or in case a certain delivery protocol is suddenly not being supported anymore due to failures). Capabilities advertisement thus refers to conveying information to a uCDN about changes/updates of certain capabilities with respect to a given contract. Given these semantics, it needs to be decided what exact capabilities are useful and how these can be expressed. Since the details of CDNI contracts are not known at the time of this writing (and the CDNI interface should probably be agnostic to these contracts anyway), it remains to be seen what capabilities will be used to define agreements between CDNs in practice. One implication for standardization may be to initially only specify a very limited set of mandatory capabilities for advertisement and have on top of that a flexible data model that allows exchanging additional capabilities when needed. Still, agreement needs to be found on which capabilities (if any) shoudl be mandatory among CDNs. As discussed in Section 3.5, finding the concrete answers to these questions can benefit from focusing on a small number of key use cases that are highly relevant and contain enough complexity to help in understanding what concrete capabilities are needed to facilitate CDN Interconnection. Under the above considerations, the following capabilities seem useful as 'base' capabilities, i.e. ones that are needed in any case and therefore constitute mandatory capabilities to be supported by the CDNI FCI: o Delivery Protocol (e.g., HTTP vs. RTMP) o Acquisition Protocol (for aquiring content from a uCDN) o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as discussed in [I-D.ietf-cdni-framework]) o Capabilities related to CDNI Logging (e.g., supported logging mechanisms) o Capabilities related to CDNI Metadata (e.g., authorization algorithms or support for proprietary vendor metadata) It is not feasable to enumerate all the possible options for the mandatory capabilities listed above (e.g., all the potential delivery protocols or metadata options) or anticipate all the future needs for additional capabilities. It would be unreasonable to burden the CDNI Seedorf, et al. Expires August 29, 2013 [Page 15] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 FCI specification with defining each supported capability. The CDNI FCI specification should define a generic protocol for conveying any capability information. It would be reasonable to define a registry which initially contains the mandatory capabilities listed above, but may be extended as needs dictate. The CDNI FCI specification SHOULD define the registry (and the rules for adding new entries to the registry) for the different capability types. Each capability type MAY further have a list of valid values. The individual CDNI interface specifications which define a given capability SHOULD define any necessary registries (and the rules for adding new entries to the registry) for the values advertised for a given capability type. The mandatory capabilities listed above generally relate to information that is configured on a content asset or group of assets basis via CDNI metadata. The capability requirements for acquisition and delivery protocol, redirection mode, and other mandatory metadata capabilities (e.g. authorization algorithms) are defined in [I-D.ietf-cdni-metadata]. Note: CDNI interface support for logging configuration (i.e., control interface vs. metadata interface) has not yet been decided. Once it has been decided, the corresponding CDNI interface specification should define the associated capability requirements. Seedorf, et al. Expires August 29, 2013 [Page 16] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 7. Open Issues and Questions The following open issues deserve further discussion in the CDNI WG: o What is the service model of this interface: Does the uCDN always query the dCDNs? Or does the dCDN always push information to the uCDNs? o In addition to "reachability" types of footprint, should also "resource" types of footprint be considered by CDNI (e.g., the location of surrogates/resources a dCDN has)? o Does a footprint need to explicitly include the "transitive reachability" of a dCDN to further dCDNs that may be able to serve content to users on behalf of dCDN? o What is the assumed business relationship between the uCDN and the dCDN? Is the uCDN always the "authoritative" CDN provider which transitively has itself contracted several downstream CDN providers? o How exactly can a given dCDN derive its footprint? o Should the footprint/capabilities advertisement interface only signal the delta with respect to a given contract (between a uCDN and a dCDN) or send the whole dCDN state each time? Seedorf, et al. Expires August 29, 2013 [Page 17] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 8. Security Considerations Security considerations will be discussed in a future version of this document. Seedorf, et al. Expires August 29, 2013 [Page 18] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 9. References 9.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for CDN Interconnection", draft-ietf-cdni-framework-03 (work in progress), February 2013. [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-ietf-cdni-metadata-00 (work in progress), October 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-05 (work in progress), February 2013. [I-D.ma-cdni-capabilities] Ma, K., "Content Distribution Network Interconnection (CDNI) Capabilities Interface", draft-ma-cdni-capabilities-01 (work in progress), February 2013. [I-D.previdi-cdni-footprint-advertisement] Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and L. Faucheur, "CDNI Footprint Advertisement", draft-previdi-cdni-footprint-advertisement-02 (work in progress), September 2012. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC6707, September 2012. [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC6770, November 2012. Seedorf, et al. Expires August 29, 2013 [Page 19] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 Appendix A. Acknowledgment Jan Seedorf is partially supported by the CHANGE project (CHANGE: Enabling Innovation in the Internet Architecture through Flexible Flow-Processing Extensions, http://www.change-project.eu/), a research project supported by the European Commission under its 7th Framework Program (contract no. 257422). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the CHANGE project or the European Commission. Jan Seedorf has been partially supported by the COAST project (COntent Aware Searching, retrieval and sTreaming, http://www.coast-fp7.eu), a research project supported by the European Commission under its 7th Framework Program (contract no. 248036). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the COAST project or the European Commission. Martin Stiemerling provided initial input to this document and valuable comments to the ongoing discussions among the authors of this document. Seedorf, et al. Expires August 29, 2013 [Page 20] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 Authors' Addresses Jan Seedorf NEC Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 221 Fax: +49 6221 4342 155 Email: firstname.lastname@example.org Jon Peterson NeuStar 1800 Sutter St Suite 570 Concord CA 94520 USA Phone: Fax: Email: email@example.com Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy Phone: Fax: Email: firstname.lastname@example.org Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT The Netherlands Phone: +31-88-866-7000 Email: email@example.com Seedorf, et al. Expires August 29, 2013 [Page 21] Internet-Draft CDNI RR Footprint/Capabilities Semantics February 2013 Kevin J. Ma Azuki Systems, Inc. 43 Nagog Park Acton MA 01720 USA Phone: +1 978-844-5100 Email: firstname.lastname@example.org Seedorf, et al. Expires August 29, 2013 [Page 22]