CDNI J. Seedorf Internet-Draft NEC Intended status: Informational J. Peterson Expires: April 25, 2013 Neustar S. Previdi Cisco October 22, 2012 CDNI Request Routing: Footprint and Capabilities Semantics draft-spp-cdni-rr-foot-cap-semantics-02 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 April 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Seedorf, et al. Expires April 25, 2013 [Page 1] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Apparent Understanding of CDNI Footprint and Capabilities Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Description of footprint and capabilities advertisement in existing CDNI documents . . . . . . . . . 4 2.2. Summary of understanding of footprint and capabilities advertisement in existing CDNI documents . . . . . . . . . 6 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' Downstream CDNs . . . . . 9 3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 10 4. Towards Semantics for Footprint Advertisement . . . . . . . . 11 5. Towards Semantics for Capabilities Advertisement . . . . . . . 13 6. Open Issues and Questions . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 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 April 25, 2013 [Page 2] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 1. Introduction 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 [I-D.ietf-cdni-use-cases], 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 interface, in particular regarding the "footprint and capabilities advertisement" of a downstream CDN. To narrow down undecided aspects of these semantics, this document first tries to capture the common understanding of what the "footprint and capabilities advertisement" should offer and accomplish, i.e. what seems to be agreed. Then, the document will discuss open questions. It is the goal of this document to capture the outcome of discussions and answers to open questions in future versions of this draft. In particular, this document summarizes the progress of the recently formed CDNI design team on "footprint and capabilities advertisement". 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. We first recap the descriptions regarding "footprint and capabilities advertisement" in existing documents and try to distill the apparent common understanding of the terms "footprint" and "capabilities" in the CDNI request routing context. We then separately discuss the semantics of the footprint advertisement mechanism, and the capability advertisement mechanism. Finally, we list open issues and questions to be discussed in the CDNI WG. Comments and discussions about this memo should be directed to the CDNI WG: cdni@ietf.org. Seedorf, et al. Expires April 25, 2013 [Page 3] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 2. Apparent Understanding of CDNI Footprint and Capabilities Advertisement In the following, we will summarize the descriptions of the CDNI "footprint and capabilities advertisement" as part of the "request routing" interface in existing documents. We will then carve out the apparent common understanding of what this interface is intended to offer and accomplish. 2.1. Description of footprint and capabilities advertisement in existing CDNI documents The CDNI problem statement draft [I-D.ietf-cdni-problem-statement] describes footprint and capabilities advertisement as: "enabling an upstream CDN to determine if a 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 draft [I-D.ietf-cdni-use-cases] 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 the "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." Seedorf, et al. Expires April 25, 2013 [Page 4] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 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.)." 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 Seedorf, et al. Expires April 25, 2013 [Page 5] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 downstream CDN needs to include (in its advertisement information that it conveys to an upstream CDN) also information the footprint and capabilities of any further transitive downstream CDN. Such information may be included implicitly (i.e. the cascaded dCDN 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 any case, a 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.davie-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]. Further, examples for capabilities are "the ability to handle certain types of content (e.g. specific streaming formats) or quality of service (QoS)." 2.2. Summary of understanding of footprint and capabilities advertisement in existing CDNI documents In summary, neither the term "footprint" nor "capabilities" are clearly defined. Also, a very broad range of potential capabilities is listed in the existing documents. Seedorf, et al. Expires April 25, 2013 [Page 6] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 3. Design Decisions for Footprint and Capabilities A large part of the difficulty lies in understanding what we mean when try to define footprint to 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, henceforth global CDNs; 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. 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 fairly. 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. 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 joined 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 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 Seedorf, et al. Expires April 25, 2013 [Page 7] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 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. 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 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 in order for it to make a decision. Seedorf, et al. Expires April 25, 2013 [Page 8] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 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, 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' Downstream CDNs 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 uDCDN in order to convince the uCDN to select it opposed to "competing" other dCDNs. It is therefore desirable to take away the incentive for dCDNs to cheat (in information advertised) as much as possible. One option 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 verifiable by the uCDN. However, it is probably an overly strict requirement to demand that such verification must be possible "immediately", i.e. during the request routing process Seedorf, et al. Expires April 25, 2013 [Page 9] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 itself. If the uCDN can detect a cheating dCDN at a later stage, it should suffice for the dCDN to "de-incentivize" cheating because it would negatively affect long-term business relationsships with uCDNs. 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. Further, 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. Seedorf, et al. Expires April 25, 2013 [Page 10] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 4. Towards Semantics for Footprint Advertisement Based on the characterizations in existing documents (see Section 2), we can distill some "rough" candidates for definitions of a footprint: o Footprint could be defined by "layer-3 coverage", where coverage refers to a set of prefixes, a geographic region, or similar boundary. o Footprint could alternatively be defined as "a class of end user requests a dCDN is willing to serve". Independent of the exact definition of footprint, a footprint likely needs to be able to 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. Different concrete candidates for a footprint are imaginable (set of prefixes, a geographic region, ...). Among these, "set of IP- prefixes" may potentially be a useful footprint in the CDDNI context. Such footprint information 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 be support for multiple IP address version, i.e., IPv4 and IPv6 in the footprint. Roughly speaking, footprint can be defined as "willingness to serve" by a downstream CDN. However, in addition to simply "willingness to serve", the uCDN needs to have some additional information to make a dCDN selection decision. The uCDN needs additional information so that it can assess "how well" a given dCDN can actually serve a given end user request; otherwise, any dCDN can claim it can deliver content to the whole world. One can imagine that such additonal information is implicitly associated with a given footprint, e.g. due to (from the request routing interface's perspective out-of-band) contractual agreements (e.g. SLAs), business relationships, or perceived dCDN quality in the past. As an alternative, such additional information could also be explicitly be 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 of the CDNI Seedorf, et al. Expires April 25, 2013 [Page 11] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 request routing protocol. 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 RR interface). 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 request routing interface? 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 request routing footprint advertisement 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. Seedorf, et al. Expires April 25, 2013 [Page 12] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 5. Towards Semantics for Capabilities Advertisement 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, WWW delivery, Video on Demand (VoD) delivery based on flash or apple technologies, or live streaming based on RTSP. 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 VoD but not in some areas, either for maintenance reasons or because 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. High-level and very rough semantics for (and characteristics of) capabilities are thus: o Capabilities are types of information that allow a uCDN to determine if a downstream CDN is able (and willing) to accept the delegated content request. o Capabilities are types of information that possibly may change over time based on the state of the network or caches. Candidates for capabilities seem to fall into several broad categories. Some are capabilities associated with a resource itself, like the codecs or streaming technologies in which a particular resource is available. Some capabilities are associated with the cache: these include the load state, available storage resources, and so on. Some capabilities are associated with the network where the cache is deployed, including available bandwidth for streaming, availability of QoS mechanisms, and so on. Some capabilities reflect administrative restrictions or policies that may affect the decisions made up a uCDN. It seems unlikely these factors will be shared through the interface, however. Potential Cache capabilities are: o aggregate information (i.e. not for individual caches, but still helpful for dCDN selection) about load, or "excessive load" o aggregate information (i.e. not for individual caches, but still helpful for dCDN selection) about available resources, storage Seedorf, et al. Expires April 25, 2013 [Page 13] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 resources o aggregate information (i.e. not for individual caches, but still helpful for dCDN selection) regarding failure conditions Potential Resource Capabilities are: o supported range of playback devices o supported range of delivery technologies o specific delivery protocols o supported content types (MIME) Potential Network Capabilities are: o meeting a certain QoS o distribution and delivery priority o streaming bandwidth Outside the scope of capability advertisements are administrative capabilities, such as: o policy (membership in the federation, etc) o administrative limits, e.g. maximum aggregate volume of content delivered monthly o indication of distribution/delivery fees At a first glance, the above list of candidates contains useful capabilities to convey via an advertisement interface (and indeed the candidate capabilities listed above 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) is probably not a good idea. 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 to convey are resource capabilities: Such information does not change highly dynamically and in many cases such Seedorf, et al. Expires April 25, 2013 [Page 14] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 information is absolutely necessary to decide on a dCDN for a given end user request. For instance, if an end user request concerns the delivery of a movie with a certain protocol (e.g. RTMP), the uCDN needs to knwo 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 of the CDNI request routing protocol. The role of capabilities 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). Under the above considerations, the semantics of capabilities advertisement are roughly the following: o The main category of useful capabilities to convey is resource capabilities. o Advertisement 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 capabilities exactly are useful and how these can be expressed. Since the details of CDNI contracts are not known at the time of this writing (i.e. at this point in time there are only very preliminary trials ongoing and no real deployments with actual contracts between CDNs yet), it remains to be seen what capabilities will be used to define agreements between CDNs in practise. One implication for standardization may be to initially only specify very fey mandatory capabilities for advertisement and have on top of that a flexible protocol that allows to exchange additional capabilities when needed. Still, agreement needs to be found on what core capabilities are really needed to convey 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. Seedorf, et al. Expires April 25, 2013 [Page 15] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 6. 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 What exactly is a footprint based on? (e.g. prefix, geographic area, ASN, or location of surrogates/resources) o Does a footprint need to include the "reachability" of the dCDN to other CDNs 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 To what extent should capability advertisement include or factor in dynamic attributes? Seedorf, et al. Expires April 25, 2013 [Page 16] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 7. Security Considerations Security considerations will be discussed in a future version of this document. Seedorf, et al. Expires April 25, 2013 [Page 17] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 8. Conclusion 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, also reflecting ongoing discussions in the CDNI design team on "Footprint and Capabilities Advertisement". Several key design decisions and open questions have been discussed. The discussion in this document has the objective to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. It is the goal of this document to capture the outcome of further progress of the CDNI WG and the design team on "Footprint and Capabilities Advertisement" including answers to currently open questions in future versions of this draft. Seedorf, et al. Expires April 25, 2013 [Page 18] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.davie-cdni-framework] Davie, B. and L. Peterson, "Framework for CDN Interconnection", draft-davie-cdni-framework-01 (work in progress), October 2011. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-08 (work in progress), June 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-03 (work in progress), June 2012. [I-D.ietf-cdni-use-cases] Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", draft-ietf-cdni-use-cases-10 (work in progress), August 2012. [I-D.peterson-cdni-strawman] Peterson, L. and J. Hartman, "A Simple Approach to CDN Interconnection", draft-peterson-cdni-strawman-01 (work in progress), May 2011. [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. [I-D.xiaoyan-cdni-requestrouting] He, X., Li, J., Dawkins, S., and G. Chen, "Request Routing for CDN Interconnection", draft-xiaoyan-cdni-requestrouting-01 (work in progress), June 2011. Seedorf, et al. Expires April 25, 2013 [Page 19] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 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 April 25, 2013 [Page 20] Internet-Draft CDNI RR Footprint/Capabilities Semantics October 2012 Authors' Addresses Jan Seedorf NEC Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 221 Fax: +49 6221 4342 155 Email: seedorf@neclab.eu Jon Peterson NeuStar 1800 Sutter St Suite 570 Concord CA 94520 USA Phone: Fax: Email: jon.peterson@neustar.biz Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy Phone: Fax: Email: sprevidi@cisco.com Seedorf, et al. Expires April 25, 2013 [Page 21]