Internet Engineering Task Force (IETF) B. Niven-Jenkins Request for Comments: 6707 Velocix (Alcatel-Lucent) Category: Informational F. Le Faucheur ISSN: 2070-1721 Cisco N. Bitar Verizon September 2012 Content Distribution Network Interconnection (CDNI) Problem Statement
AbstractContent Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection. The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6707.
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 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. 1. Introduction ....................................................3 1.1. Terminology ................................................4 1.2. CDN Background .............................................9 2. CDN Interconnection Use Cases ...................................9 3. CDN Interconnection Model and Problem Area for IETF ............11 4. Scoping the CDNI Problem .......................................15 4.1. CDNI Control Interface ....................................16 4.2. CDNI Request Routing Interface ............................16 4.3. CDNI Metadata Interface ...................................17 4.4. CDNI Logging Interface ....................................17 5. Security Considerations ........................................17 5.1. Security of the CDNI Control Interface ....................18 5.2. Security of the CDNI Request Routing Interface ............18 5.3. Security of the CDNI Metadata Interface ...................19 5.4. Security of the CDNI Logging Interface ....................19 6. Acknowledgements ...............................................19 7. Informative References .........................................20 Appendix A. Design Considerations for Realizing the CDNI Interfaces ............................................22 A.1. CDNI Control Interface .....................................22 A.2. CDNI Request Routing Interface .............................23 A.3. CDNI Metadata Interface ....................................25 A.4. CDNI Logging Interface .....................................26 Appendix B. Additional Material ...................................27 B.1. Non-Goals for IETF .........................................27 B.2. Relationship to Relevant IETF Working Groups and IRTF Research Groups ............................................29 B.2.1. ALTO WG ................................................29 B.2.2. DECADE WG ..............................................29 B.2.3. PPSP WG ................................................31 B.2.4. IRTF P2P Research Group ................................31
The formation and details of any business relationships between a CSP and a CDN Provider as well as between one CDN Provider and another CDN Provider are out of scope of this document. However, this document concerns itself with the fact that no standards or open specifications currently exist to facilitate such CDN Interconnection from a technical perspective. One possible flow for performing an end-to-end content delivery across a CDN Interconnection is described below: o The initial content request from an EU's User Agent is first received by the authoritative (upstream) CDN, which is the CDN with a business arrangement with the CSP. o The authoritative (upstream) CDN may serve the request itself, or it may elect to use CDN Interconnection to redirect the request to a Downstream CDN that is in a better position to do so (e.g., a Downstream CDN that is "closer" to the EU). o The EU's User Agent will "follow" the redirect returned by the Authoritative CDN and request the content from the Downstream CDN. If required, the Downstream CDN will acquire the requested content from the authoritative (upstream) CDN, and if necessary the Authoritative CDN will acquire the requested content from the Content Service Provider. The goal of this document is to outline the problem area of CDN Interconnection. Section 2 discusses the use cases for CDN Interconnection. Section 3 presents the CDNI model and problem area being considered by the IETF. Section 4 describes each CDNI interface individually and highlights example candidate protocols that could be considered for reuse or leveraging to implement the CDNI interfaces. Appendix B.2 describes the relationships between the CDNI problem space and other relevant IETF working groups and IRTF research groups.
communicate with each other in order to achieve the delivery of content to User Agents by Surrogates in one CDN (the Downstream CDN) on behalf of another CDN (the Upstream CDN). CDN Provider: The service provider who operates a CDN and offers a service of content delivery, typically used by a Content Service Provider or another CDN Provider. Note that a given entity may operate in more than one role. For example, a company may simultaneously operate as a Content Service Provider, a Network Service Provider, and a CDN Provider. CDNI Metadata: The subset of Content Distribution Metadata that has an inter-CDN scope. For example, CDNI Metadata may include geo-blocking information (i.e., information defining geographical areas where the content is to be made available or blocked), availability windows (i.e., information defining time windows during which the content is to be made available or blocked) and access control mechanisms to be enforced (e.g., URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g., pre-positioned vs dynamic acquisition) and about where/ how a CDN can acquire the content. Content: Any form of digital data. One important form of Content with additional constraints on distribution and delivery is continuous media (i.e., where there is a timing relationship between source and sink). Content Distribution Metadata: The subset of Content Metadata that is relevant to the distribution of the content. This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN. In a CDN Interconnection environment, some of the Content Distribution Metadata may have an intra-CDN scope (and therefore need not be communicated between CDNs), while some of the Content Distribution Metadata may have an inter-CDN scope (and therefore needs to be communicated between CDNs). Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents. Typically, a CDN consists of a Request Routing system, a Distribution system (that includes a set of Surrogates), a Logging system, and a CDN Control system.
Content Metadata: This is metadata about Content. Content Metadata comprises: 1. Metadata that is relevant to the distribution of the content (and therefore relevant to a CDN involved in the delivery of that content). We refer to this type of metadata as "Content Distribution Metadata". See also the definition of Content Distribution Metadata. 2. Metadata that is associated with the actual Content or content representation, and not directly relevant to the distribution of that Content. For example, such metadata may include information pertaining to the Content's genre, cast, rating, etc. as well as information pertaining to the Content representation's resolution, aspect ratio, etc. Content Service: The service offered by a Content Service Provider. The Content Service encompasses the complete service, which may be wider than just providing access to items of Content; e.g., the Content Service also includes any middleware, key distribution, program guide, etc. that may not require any direct interaction with the CDN, or CDNs, involved in the distribution and delivery of the content. Content Service Provider (CSP): Provides a Content Service to End Users (which they access via a User Agent). A CSP may own the Content made available as part of the Content Service, or may license content rights from another party. Control system: The function within a CDN responsible for bootstrapping and controlling the other components of the CDN as well as for handling interactions with external systems (e.g., handling delivery service creation/update/removal requests, or specific service provisioning requests). Delivery: The function within CDN Surrogates responsible for delivering a piece of content to the User Agent. For example, delivery may be based on HTTP progressive download or HTTP adaptive streaming. Distribution system: The function within a CDN responsible for distributing Content Distribution Metadata as well as the Content itself inside the CDN (e.g., down to the Surrogates). Downstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) to which the request is redirected by the other CDN (the Upstream CDN). Note that in the case of successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN
(e.g., CDN2) may act as the Downstream CDN for a redirection (e.g., CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection of the same request (e.g., CDN2-->CDN3). Dynamic CDNI Metadata acquisition: In the context of CDN Interconnection, dynamic CDNI Metadata acquisition means that a Downstream CDN acquires CDNI Metadata for content from the Upstream CDN at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific CDNI Metadata is not yet available in the Downstream CDN). See also the definitions for Downstream CDN and Upstream CDN. Dynamic content acquisition: Dynamic content acquisition is where a CDN acquires content from the content source in response to an End User requesting that content from the CDN. In the context of CDN Interconnection, dynamic acquisition means that a Downstream CDN acquires the content from content sources (including Upstream CDNs) at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific content is not yet available in the Downstream CDN). End User (EU): The 'real' user of the system, typically a human but maybe some combination of hardware and/or software emulating a human (e.g., for automated quality monitoring etc.). Logging system: The function within a CDN responsible for collecting the measurement and recording of distribution and delivery activities. The information recorded by the Logging system may be used for various purposes, including charging (e.g., of the CSP), analytics, and monitoring. Metadata: Metadata in general is data about data. Network Service Provider (NSP): Provides network-based connectivity/ services to End Users. Over-the-top (OTT): A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached. Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnection, CDNI Metadata pre-positioning is where the Downstream CDN acquires CDNI Metadata for content prior to, or independently of, any End User requesting that content from the Downstream CDN.
Pre-positioned content acquisition: Content pre-positioning is where a CDN acquires content from the content source prior to, or independently of, any End User requesting that content from the CDN. In the context of CDN Interconnection, the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including Upstream CDNs) in advance of, or independently of, any End User requesting it. Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390]. Request Routing system: The function within a CDN responsible for receiving a Content Request from a User Agent, obtaining and maintaining necessary information about a set of candidate Surrogates or candidate CDNs, and for selecting and redirecting the user to the appropriate Surrogate or CDN. To enable CDN Interconnection, the Request Routing system must also be capable of handling User Agent Content Requests passed to it by another CDN. Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. Typically, Surrogates will cache requested content so that they can directly deliver the same content in response to requests from multiple User Agents (and their End Users), avoiding the need for the content to transit multiple times through the network core (i.e., from the content origin to the Surrogate). Upstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) that redirects the request to the other CDN. User Agent (UA): Software (or a combination of hardware and software) through which the End User interacts with a Content Service. The User Agent will communicate with a Content Service for the selection of content and one or more CDNs for the delivery of the Content. Such communication is not restricted to HTTP and may be via a variety of protocols. Examples of User Agents (non-exhaustive) are browsers, Set Top Boxes (STBs), dedicated content applications (e.g., media players), etc.
RFC3040] describes many of the component technologies that are used in the construction of a CDN. o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the IETF Content Distribution Internetworking (CDI) working group, which was closed in 2003. Note: Some of the terms used in this document are similar to terms used in the above referenced documents. When reading this document, terms should be interpreted as having the definitions provided in Section 1.1.
need for interconnection of these CDNs; this represents a first use case for CDNI. However, there are no open specifications, nor common best practices, defining how to achieve such CDN Interconnection. CSPs have a desire to be able to get (some of) their content to very large numbers of End Users, who are often distributed across a number of geographies, while maintaining a high quality of experience, all without having to maintain direct business relationships with many different CDN Providers (or having to extend their own CDN to a large number of locations). Some NSPs are considering interconnecting their respective CDNs (as well as possibly over-the-top CDNs) so that this collective infrastructure can address the requirements of CSPs in a cost-effective manner. This represents a second use case for CDNI. In particular, this would enable the CSPs to benefit from on-net delivery (i.e., within the Network Service Provider's own network/CDN footprint) whenever possible and off-net delivery otherwise, without requiring the CSPs to maintain direct business relationships with all the CDNs involved in the delivery. Again, CDN Providers (NSPs or over-the-top CDN operators) are faced with a lack of open specifications and best practices. NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment. Some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery, and a CDN for video delivery to mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs, representing a third use case for CDNI. Again, NSPs face the problem of lack of open interfaces for CDN Interconnection. For operational reasons (e.g., disaster, flash crowd) or commercial reasons, an over-the-top CDN may elect to make use of another CDN (e.g., an NSP CDN with on-net Surrogates for a given footprint) for serving a subset of the user requests (e.g., requests from users attached to that NSP), which results in a fourth use case for CDNI because CDN Providers (over-the-top CDN Providers or NSPs) are faced with a lack of open specifications and best practices. Use cases for CDN Interconnection are further discussed in [CDNI-USE-CASES].
CDNI-EXPERIMENTS]. The conclusions of those experiments are that while some basic limited CDN Interconnection functionality can be achieved with existing CDN technology, the current lack of any standardized CDNI interfaces with the necessary level of functionality such as those discussed in this document is preventing the deployment of CDN Interconnection. Listed below are the four interfaces required to interconnect a pair of CDNs and that constitute the problem space of CDN Interconnection along with the required functionality of each interface for which standards do not currently exist. As part of the development of the CDNI interfaces, it will also be necessary to agree on common mechanisms for how to identify and name the data objects that are to be interchanged between interconnected CDNs. The use of the term "interface" is meant to encompass the protocol over which CDNI data representations (e.g., CDNI Metadata objects) are exchanged as well as the specification of the data representations themselves (i.e., what properties/fields each object contains, its structure, etc.). o CDNI Control interface: This interface allows the "CDNI Control" system in interconnected CDNs to communicate. This interface may support the following: * Allow bootstrapping of the other CDNI interfaces (e.g., interface address/URL discovery and establishment of security associations). * Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface). * Allow the Downstream CDN to communicate static (or fairly static) information about its delivery capabilities and policies.
* Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work). * Allow an Upstream CDN to initiate or request specific actions to be undertaken in the Downstream CDN. For example, to allow an Upstream CDN to initiate content or CDNI Metadata acquisition (pre-positioning) or to request the invalidation or purging of content files and/or CDNI Metadata in a Downstream CDN. o CDNI Request Routing interface: This interface allows the Request Routing systems in interconnected CDNs to communicate to ensure that an End User request can be (re)directed from an Upstream CDN to a Surrogate in the Downstream CDN, in particular where selection responsibilities may be split across CDNs (for example, the Upstream CDN may be responsible for selecting the Downstream CDN, while the Downstream CDN may be responsible for selecting the actual Surrogate within that Downstream CDN). In particular, the functions of the CDN Request Routing interface may be divided as follows: * A CDNI Request Routing Redirection interface, which allows the Upstream CDN to query the Downstream CDN at request routing time before redirecting the request to the Downstream CDN. * A CDNI Footprint & Capabilities advertisement interface, which allows the 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. o CDNI Metadata interface: This interface allows the Distribution system in interconnected CDNs to communicate to ensure that CDNI Metadata can be exchanged across CDNs. See Section 1.1 for the definition and examples of CDNI Metadata. o CDNI Logging interface: This interface allows the Logging system in interconnected CDNs to communicate the relevant activity logs in order to allow log-consuming applications to operate in a multi-CDN environment. For example, an Upstream CDN may collect delivery logs from a Downstream CDN in order to perform consolidated charging of the CSP or for settlement purposes across CDNs. Similarly, an Upstream CDN may collect delivery logs from a Downstream CDN in order to provide consolidated reporting and monitoring to the CSP.
Note that the actual grouping of functionalities under these four interfaces is considered tentative at this stage and may be changed after further study (e.g., some subset of functionality may be moved from one interface into another). The above list covers a significant potential problem space, in part because in order to interconnect two CDNs there are several 'touch points' that require standardization. However, it is expected that the CDNI interfaces need not be defined from scratch and instead can reuse or leverage existing protocols to a very significant extent; this is discussed further in Section 4. The interfaces that form the CDNI problem area are illustrated in Figure 1.
-------- / \ | CSP | \ / -------- * * * /\ * / \ ---------------------- |CDNI| ---------------------- / Upstream CDN \ | | / Downstream CDN \ | +-------------+ | Control Interface| +-------------+ | |******* Control |<======|====|========>| Control *******| |* +------*----*-+ | | | | +-*----*------+ *| |* * * | | | | * * *| |* +------*------+ | Logging Interface| +------*------+ *| |* ***** Logging |<======|====|========>| Logging ***** *| |* * +-*-----------+ | | | | +-----------*-+ * *| |* * * * | Request Routing | * * * *| .....*...+-*---------*-+ | Interface | +-*---------*-+...*.*... . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . . |* * * +-------------+.| | | | +-------------+ * * *| . . |* * * . CDNI Metadata | * * *| . . |* * * +-------------+ |. Interface | +-------------+ * * *| . . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . . |* * * | | | . \ / | | | * * *| . . |* * * |+---------+ | | . \/ | | +---------+| * * *| . . |* * ***| +---------+| | ....Request......+---------+ |*** * *| . . |* *****+-|Surrogate|************************|Surrogate|-+***** *| . . |******* +---------+| | Acquisition | |+----------+ *******| . . | +-------------+ | | +-------*-----+ | . . \ / \ * / . . ---------------------- ---------*------------ . . * . . * Delivery . . * . . +--*---+ . ...............Request.............................| User |..Request.. | Agent| +------+ <==> interfaces inside the scope of CDNI **** interfaces outside the scope of CDNI .... interfaces outside the scope of CDNI Figure 1: A Model for the CDNI Problem Area
As illustrated in Figure 1, the acquisition of content between interconnected CDNs is out of scope for CDNI; this deserves some additional explanation. The consequence of such a decision is that the CDNI problem space described in this document is focused on only defining the control plane for CDNI, and the CDNI data plane (i.e., the acquisition and distribution of the actual content objects) is out of scope. The rationale for such a decision is that CDNs today typically already use standardized protocols such as HTTP, FTP, rsync, etc. to acquire content from their CSP customers, and it is expected that the same protocols could be used for acquisition between interconnected CDNs. Therefore, the problem of content acquisition is considered already solved, and all that is required with respect to content acquisition from specifications developed by the CDNI working group is to describe within the CDNI Metadata the parameters to use to retrieve the content -- for example, the IP address/hostname to connect to, what protocol to use to retrieve the content, etc. Section 3 within the CDNI problem area are all control plane interfaces operating at the application layer (Layer 7 in the OSI network model). Firstly, since it is not expected that these interfaces would exhibit unique session, transport, or network requirements as compared to the many other existing applications in the Internet, it is expected that the CDNI interfaces will be defined on top of existing session, transport, and network protocols. Secondly, although a new application protocol could be designed specifically for CDNI, our analysis below shows that this is unnecessary, and it is recommended that existing application protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing Protocol [RFC5023], the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for example) to realize the CDNI interfaces.
Section 3, 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 is expected that such functionality of the CDNI request routing could be specified by the CDNI working group with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example, by leveraging existing routing protocols) or supporting application-level queries for topological information (for example, by leveraging Application-Layer Traffic Optimization (ALTO) [RFC5693]).
RFC6120]. This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface.
The interconnection of CDNs may also introduce additional privacy considerations on top of those that apply to the single-CDN case. In a multi-CDN environment, the different CDNs may reside in different legal regimes that require differing privacy requirements to be enforced. Such privacy requirements may impact the granularity of information that can be exchanged across the CDNI interfaces. For example, the Logging system in a Downstream CDN may need to apply some degree of anonymization, obfuscation, or even the complete removal of some fields before exchanging log records containing details of End User deliveries with an Upstream CDN. Maintaining the security of the content itself, its associated metadata (including delivery policies), and the CDNs distributing and delivering it, are critical requirements for both CDN Providers and CSPs, and the CDN Interconnection interfaces must provide sufficient mechanisms to maintain the security of the overall system of interconnected CDNs as well as the information (content, metadata, logs, etc.) distributed and delivered through any set of interconnected CDNs.
Upstream CDN so the Upstream CDN redirects requests to the rogue Downstream CDN or another Downstream CDN in order to, for example, attract additional delivery revenue.
[ALTO-CDN-USE-CASES] Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012. [ALTO-Charter] "IETF ALTO WG Charter", <http://datatracker.ietf.org/wg/alto/charter/>. [CDNI-EXPERIMENTS] Bertrand, G., Ed., Le Faucheur, F., and L. Peterson, "Content Distribution Network Interconnection (CDNI) Experiments", Work in Progress, February 2012. [CDNI-USE-CASES] Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", Work in Progress, August 2012. [DECADE-Charter] "IETF DECADE WG Charter", <http://datatracker.ietf.org/wg/decade/charter/>. [P2PRG-CDNI] Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka 'Peering Peer-to-Peer'", March 2010, <http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>. [PPSP-Charter] "IETF PPSP WG Charter", <http://datatracker.ietf.org/wg/ppsp/charter/>. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC5023] Gregorio, J., Ed., and B. de hOra, Ed., "The Atom Publishing Protocol", RFC 5023, October 2007. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content Delivery Networks", 2007, <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.
Section 3, the CDNI Control interface may be required to support functionality similar to the following: o Allow an Upstream CDN and Downstream CDN to establish, update, or terminate their CDNI interconnection. o Allow bootstrapping of the other CDNI interfaces (e.g., protocol address discovery and establishment of security associations). o Allow configuration of the other CDNI interfaces (e.g., Upstream CDN specifies information to be reported through the CDNI Logging interface). o Allow the Downstream CDN to communicate static information about its delivery capabilities, resources, and policies. o Allow bootstrapping of the interface between CDNs for content acquisition (even if that interface itself is outside the scope of the CDNI work). It is expected that for the Control interface, as for the other CDNI interfaces, existing protocols can be reused or leveraged. Those will be considered once the requirements for the Control interface have been refined.
RFC2616]. It should be noted that the CDNI architecture needs to consider that a Downstream CDN may receive requests from User Agents without first receiving a Redirection Request from an Upstream CDN for the corresponding User Agent request because, for example: o User Agents (or DNS resolvers) may cache DNS or application responses from Request Routers. o Responses to Redirection Requests over the Request Routing interface may be cacheable.
o Some CDNs may rely on simple coarse policies, e.g., CDN B agrees to always serve CDN A's delegated redirection requests, in which case the necessary redirection details are exchanged out of band (of the CDNI interfaces), e.g., configured. On receiving a Redirection Request, the Downstream CDN will use the information provided in the request to determine if it is able (and willing) to accept the delegated Content Request and needs to return the result of its decision to the Upstream CDN. Thus, a Redirection Response from the Downstream CDN is expected to contain information such as: o Status code indicating acceptance or rejection (possibly with accompanying reasons). o Information to allow redirection by the Upstream CDN. In the case of DNS-based request routing, this is expected to include the equivalent of a DNS record(s) (e.g., a CNAME) that the Upstream CDN should return to the requesting DNS resolver. In the case of application-based request routing, this is expected to include the information necessary to construct the application-specific redirection response(s) to return to the requesting User Agent. For HTTP requests from User Agents, this could include a URI that the Upstream CDN could return in an HTTP 3xx response. The CDNI Request Routing interface is therefore a fairly straightforward request/response interface and could be implemented over any number of request/response protocols. For example, it may be implemented as a WebService using one of the common WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.). This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Request Routing interface. Thus, the CDNI working group would be left only with the task of specifying: o The recommended request/response protocol to use along with any additional semantics and procedures that are specific to the CDNI Request Routing interface (e.g., handling of malformed requests/ responses). o The syntax (i.e., representation/encoding) of the redirection requests and responses. o The semantics (i.e., meaning and expected contents) of the redirection requests and responses.
Additionally, as discussed in Section 3, 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 is expected that such functionality of the CDNI request routing could be specified by the CDNI working group with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example, by leveraging existing routing protocols) or supporting application-level queries for topological information (for example, by leveraging ALTO). RFC6120]. This removes the need for the CDNI working group to define a new protocol for the request/response element of the CDNI Metadata interface.
Thus, the CDNI working group would be left only with the task of specifying: o The recommended request/response protocol to use along with any additional semantics that are specific to the CDNI Metadata interface (e.g., handling of malformed requests/responses). o The syntax (i.e., representation/encoding) of the CDNI Metadata objects that will be exchanged over the interface. o The semantics (i.e., meaning and expected contents) of the individual properties of a Metadata object. o How the relationships between different CDNI Metadata objects are represented.
Although it is not necessary to define a new protocol for exchanging logs across the CDNI Logging interface, the CDNI working group would still need to specify: o The recommended protocol to use. o A default set of log fields and of their syntax and semantics. Today there is no standard set of common log fields across different content delivery protocols, and in some cases there is not even a standard set of log field names and values for different implementations of the same delivery protocol. o A default set of conditions that trigger log records to be generated.
(ATIS IIF CoD)). The CDN Interconnection problem space described in this document may therefore only concern itself with the agreement/negotiation aspects of which content acquisition protocol is to be used between two interconnected CDNs in view of facilitating interoperability. o End User/User Agent Authentication. End User/User Agent authentication and authorization are the responsibility of the Content Service Provider. o Content preparation, including encoding and transcoding. The CDNI architecture aims at allowing distribution across interconnected CDNs of content treated as opaque objects. Interpretation and processing of the objects, as well as optimized delivery of these objects by the Surrogate to the End User, are outside the scope of CDNI. o Digital Rights Management (DRM). DRM is an end-to-end issue between a content protection system and the User Agent. o Applications consuming CDNI logs (e.g., charging, analytics, reporting, ...). o Internal CDN interfaces and protocols (i.e., interfaces and protocols within one CDN). o Scalability of individual CDNs. While scalability of the CDNI interfaces/approach is in scope, how an individual CDN scales is out of scope. o Actual algorithms for selection of CDNs or Surrogates by Request Routing systems (however, some specific parameters required as input to these algorithms may be in scope when they need to be communicated across CDNs). o Surrogate algorithms. For example, caching algorithms and content acquisition methods are outside the scope of the CDNI work. Content management (e.g., Content Deletion) as it relates to CDNI content management policies is in scope, but the internal algorithms used by a cache to determine when to no longer cache an item of Content (in the absence of any specific metadata to the contrary) is out of scope. o Element management interfaces. o Commercial, business, and legal aspects related to the interconnections of CDNs.
ALTO-Charter]: The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The working group will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. In particular, the ALTO service can be used by a CDN Request Routing system to improve its selection of a CDN Surrogate to serve a particular User Agent request (or to serve a request from another Surrogate). [ALTO-CDN-USE-CASES] describes a number of use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s) and discusses how CDN Request Routing could be used as an integration point of ALTO into CDNs. It is possible that the ALTO service could be used in the same manner in a multi-CDN environment based on CDN Interconnection. For example, an Upstream CDN may take advantage of the ALTO service in its decision for selecting a Downstream CDN to which a user request should be delegated. However, the current work of ALTO is complementary to and does not overlap with the work described in this document because the integration between ALTO and a CDN is an internal decision for a specific CDN and is therefore out of scope for the CDNI working group. One area for further study is whether additional information should be provided by an ALTO service to facilitate CDNI CDN selection. DECADE-Charter] is addressing the problem of reducing traffic on the last-mile uplink, as well as backbone and transit links caused by peer-to-peer (P2P) streaming and file-sharing applications. It addresses the problem by enabling an application endpoint to make content available from an in-network storage service and by enabling other application endpoints to retrieve the content from there.
Exchanging data through the in-network storage service in this manner, instead of through direct communication, provides significant gain where: o The network capacity/bandwidth from the in-network storage service to the application endpoint significantly exceeds the capacity/ bandwidth from application endpoint to application endpoint (e.g., because of an end-user uplink bottleneck); and o The content is to be accessed by multiple instances of application endpoints (e.g., as is typically the case for P2P applications). While, as is the case for any other data distribution application, the DECADE architecture and mechanisms could potentially be used for exchange of CDNI control plane information via an in-network storage service (as opposed to directly between the entities terminating the CDNI interfaces in the neighbor CDNs), we observe that: o CDNI would operate as a "Content Distribution Application" from the DECADE viewpoint (i.e., would operate on top of DECADE). o There do not seem to be obvious benefits in integrating the DECADE control plane responsible for signaling information relating to control of the in-network storage service itself, and the CDNI control plane responsible for application-specific CDNI interactions (such as exchange of CDNI Metadata, CDNI request redirection, and transfer of CDNI logging information). o There would typically be limited benefits in making use of a DECADE in-network storage service because the CDNI interfaces are expected to be terminated by a very small number of CDNI clients (if not one) in each CDN, and the CDNI clients are expected to benefit from high bandwidth/capacity when communicating directly to each other (at least as high as if they were communicating via an in-network storage server). The DECADE in-network storage architecture and mechanisms may theoretically be used for the acquisition of the content objects themselves between interconnected CDNs. It is not expected that this would have obvious benefits in typical situations where a content object is acquired only once from an Upstream CDN to a Downstream CDN (and then distributed as needed inside the Downstream CDN). But it might have benefits in some particular situations. Since the acquisition protocol between CDNs is outside the scope of the CDNI work, this question is left for further study.
The DECADE in-network storage architecture and mechanisms may potentially also be used within a given CDN for the distribution of the content objects themselves among Surrogates of that CDN. Since the CDNI work does not concern itself with operation within a CDN, this question is left for further study. Therefore, the work of DECADE may be complementary to, but does not overlap with, the CDNI work described in this document. PPSP-Charter]: The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and time-shifted media content with near real-time delivery requirements... ... The PPSP working group designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. Therefore, PPSP is concerned with the distribution of the streamed content itself along with the necessary signaling and control required to distribute the content. As such, it could potentially be used for the acquisition of streamed content across interconnected CDNs. But since the acquisition protocol is outside the scope of the work proposed for CDNI, we leave this for further study. Also, because of its streaming nature, PPSP is not seen as applicable to the distribution and control of the CDNI control plane and CDNI data representations. Therefore, the work of PPSP may be complementary to, but does not overlap with, the work described in this document for CDNI. P2PRG-CDNI].