diff options
Diffstat (limited to 'doc/rfc/rfc6707.txt')
| -rw-r--r-- | doc/rfc/rfc6707.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc6707.txt b/doc/rfc/rfc6707.txt new file mode 100644 index 0000000..d302432 --- /dev/null +++ b/doc/rfc/rfc6707.txt @@ -0,0 +1,1795 @@ + + + + + + +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 + +Abstract + + Content 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. + + + + +Niven-Jenkins, et al. Informational [Page 1] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +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. + +Table of Contents + + 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 + + + +Niven-Jenkins, et al. Informational [Page 2] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +1. Introduction + + The volume of video and multimedia content delivered over the + Internet is rapidly increasing and expected to continue doing so in + the future. In the face of this growth, Content Delivery Networks + (CDNs) provide numerous benefits for cacheable content: reduced + delivery cost, improved quality of experience for End Users (EUs), + and increased robustness of delivery. For these reasons, CDNs 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 EU regardless of that EU's location or the network they are + attached to. However, a given CDN in charge of delivering a given + content may not have a footprint that expands close enough to the + EU's current location or attachment network, or may not have the + necessary resources, to realize the user experience and cost benefit + that a more distributed CDN infrastructure would allow. This is the + motivation for interconnecting standalone CDNs so that their + collective CDN footprint and resources can be leveraged for the + end-to-end delivery of content from Content Service Providers (CSPs) + to EUs. As an example, a CSP could contract with an "authoritative" + CDN Provider for the delivery of content, and that Authoritative CDN + Provider could contract with one or more downstream CDN Providers to + distribute and deliver some or all of the content on behalf of the + Authoritative CDN Provider. + + A typical end-to-end content delivery scenario would then involve the + following business arrangements: + + o A business arrangement between the EU and his CSP, authorizing + access by the EU to content items controlled by the CSP. + + o A business arrangement between the CSP and an "authoritative" CDN + Provider where the CSP mandates that the CDN Provider perform the + content delivery on behalf of the CSP. + + o A business arrangement between the Authoritative CDN Provider and + another (or other) CDN(s) where the Authoritative CDN may delegate + the actual serving of some of the content delivery requests to the + other CDN(s). A particular case is where this other CDN Provider + happens to also be the Network Service Provider providing network + access to the EU, in which case there is also a separate and + independent business relationship between the EU and the NSP for + the corresponding network access. + + + + + +Niven-Jenkins, et al. Informational [Page 3] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +1.1. Terminology + + This document uses the following terms: + + Authoritative CDN: A CDN that has a direct relationship with a CSP + for the distribution and delivery of that CSP's content by the + Authoritative CDN or by Downstream CDNs of the Authoritative CDN. + + CDN Interconnection (CDNI): A relationship between a pair of CDNs + that enables one CDN to provide content delivery services on behalf + of another CDN. A CDN Interconnection may be wholly or partially + realized through a set of interfaces over which a pair of CDNs + + + +Niven-Jenkins, et al. Informational [Page 4] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 5] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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 + + + +Niven-Jenkins, et al. Informational [Page 6] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + (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. + + + + + + +Niven-Jenkins, et al. Informational [Page 7] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + + + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 8] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +1.2. CDN Background + + Readers are assumed to be familiar with the architecture, features, + and operation of CDNs. For readers less familiar with the operation + of CDNs, the following resources may be useful: + + o RFC 3040 [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. + +2. CDN Interconnection Use Cases + + An increasing number of NSPs are deploying CDNs in order to deal + cost-effectively with the growing usage of on-demand video services + and other content delivery applications. + + CDNs allow caching of content closer to the edge of a network so that + a given item of content can be delivered by a CDN Surrogate (i.e., a + cache) to multiple User Agents (and their End Users) without + transiting multiple times through the network core (i.e., from the + content origin to the Surrogate). This contributes to bandwidth cost + reductions for the NSP and to improved quality of experience for the + End Users. CDNs also enable replication of popular content across + many Surrogates, which enables content to be served to large numbers + of User Agents concurrently. This also helps in dealing with + situations such as flash crowds and denial-of-service attacks. + + The CDNs deployed by NSPs are not just restricted to the delivery of + content to support the Network Service Provider's own 'walled garden' + services, such as IP delivery of television services to Set Top + Boxes, but are also used for delivery of content to other devices, + including PCs, tablets, mobile phones, etc. + + Some service providers operate over multiple geographies and federate + multiple affiliate NSPs. These NSPs typically operate independent + CDNs. As they evolve their services (e.g., for seamless support of + content services to nomadic users across affiliate NSPs), there is a + + + + +Niven-Jenkins, et al. Informational [Page 9] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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]. + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 10] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +3. CDN Interconnection Model and Problem Area for IETF + + This section discusses the problem area for the IETF work on CDN + Interconnection. + + Interconnecting CDNs involves interactions among multiple different + functions and components that form each CDN. Only some of those + require additional specification by the IETF. + + Some NSPs have started to perform experiments to explore whether + their CDN use cases can already be addressed with existing CDN + implementations. One set of such experiments is documented in + [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. + + + +Niven-Jenkins, et al. Informational [Page 11] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + * 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. + + + + +Niven-Jenkins, et al. Informational [Page 12] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 13] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + -------- + / \ + | 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 + + + + + +Niven-Jenkins, et al. Informational [Page 14] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +4. Scoping the CDNI Problem + + This section outlines how the scope of work addressing the CDNI + problem space can be constrained through reuse or leveraging of + existing protocols to implement the CDNI interfaces. This discussion + is not intended to preempt any working group decision as to the most + appropriate protocols, technologies, and solutions to select to + realize the CDNI interfaces but is intended as an illustration of the + fact that the CDNI interfaces need not be created in a vacuum and + that reuse or leverage of existing protocols is likely possible. + + The four CDNI interfaces (CDNI Control interface, CDNI Request + Routing interface, CDNI Metadata interface, and CDNI Logging + interface) described in 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. + + + + + +Niven-Jenkins, et al. Informational [Page 15] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +4.1. CDNI Control Interface + + The CDNI Control interface allows the Control system in + interconnected CDNs to communicate. The exact inter-CDN control + functionality required to be supported by the CDNI Control interface + is less well defined than the other three CDNI interfaces at this + time. + + It is expected that for the Control interface, as for the other CDNI + interfaces, existing protocols can be reused or leveraged. + +4.2. CDNI Request Routing Interface + + The CDNI Request Routing interface enables 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. It also allows the + Downstream CDN to control what should be returned to the User Agent + in the redirection message by the upstream Request Routing function. + + 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 (Extensible Markup Language-Remote Procedure Calling + (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. + + 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 Application-Layer Traffic Optimization + (ALTO) [RFC5693]). + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 16] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +4.3. CDNI Metadata Interface + + The CDNI Metadata interface enables the Distribution system in a + Downstream CDN to request CDNI Metadata from an Upstream CDN so that + the Downstream CDN can properly process and respond to redirection + requests received over the CDNI Request Routing interface and Content + Requests received directly from User Agents. + + The CDNI Metadata interface is therefore similar to the CDNI Request + Routing interface because it is a request/response interface with the + potential addition that CDNI Metadata search may have more complex + semantics than a straightforward Request Routing redirection request. + Therefore, like the CDNI Request Routing interface, the CDNI Metadata + interface may be implemented as a WebService using one of the common + WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) + or possibly using other existing protocols such as XMPP [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. + +4.4. CDNI Logging Interface + + The CDNI Logging interface enables details of content distribution + and delivery activities to be exchanged between interconnected CDNs + -- for example, the exchange of log records related to the delivery + of content, similar to the log records recorded in a web server's + access log. + + Several protocols already exist that could potentially be used to + exchange CDNI logs between interconnected CDNs, including the Simple + Network Management Protocol (SNMP), syslog, FTP (and secure + variants), HTTP POST, etc. + +5. Security Considerations + + Distribution of content by a CDN comes with a range of security + considerations, such as how to enforce control of access to the + content by End Users in line with the CSP policy, or how to trust the + logging information generated by the CDN for the purposes of charging + the CSP. These security aspects are already dealt with by CDN + Providers and CSPs today in the context of standalone CDNs. However, + interconnection of CDNs introduces a new set of security + considerations by extending the trust model to a chain of trust + (i.e., the CSP "trusts" a CDN that "trusts" another CDN). The + mechanisms used to mitigate these risks in multi-CDN environments may + be similar to those used in the single-CDN case, but their + suitability in this more complex environment must be validated. + + + + +Niven-Jenkins, et al. Informational [Page 17] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +5.1. Security of the CDNI Control Interface + + Information exchanged between interconnected CDNs over this interface + is of a sensitive nature. A pair of CDNs use this interface to allow + bootstrapping of all the other CDNI interfaces, possibly including + establishment of the mechanisms for securing these interfaces. + Therefore, corruption of that interface may result in corruption of + all other interfaces. Using this interface, an Upstream CDN may + pre-position or delete content or metadata in a Downstream CDN, a + Downstream CDN may provide administrative information to an Upstream + CDN, etc. All of these operations require that the peer CDNs are + appropriately authenticated and that the confidentiality and + integrity of information flowing between them can be ensured. + +5.2. Security of the CDNI Request Routing Interface + + Appropriate levels of authentication and confidentiality must be used + in this interface because it allows an Upstream CDN to query the + Downstream CDN in order to redirect requests, and conversely, allows + the Downstream CDN to influence the Upstream CDN's Request Routing + function. + + In the absence of appropriate security on this interface, a rogue + Upstream CDN could inundate Downstream CDNs with bogus requests or + have the Downstream CDN send the rogue Upstream CDN private + information. Also, a rogue Downstream CDN could influence the + + + + + +Niven-Jenkins, et al. Informational [Page 18] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +5.3. Security of the CDNI Metadata Interface + + This interface allows a Downstream CDN to request CDNI Metadata from + an Upstream CDN, and therefore the Upstream CDN must ensure that the + former is appropriately authenticated before sending the data. + Conversely, a Downstream CDN must authenticate an Upstream CDN before + requesting metadata to insulate itself from poisoning by rogue + Upstream CDNs. The confidentiality and integrity of the information + exchanged between the peers must be protected. + +5.4. Security of the CDNI Logging Interface + + Logging data consists of potentially sensitive information (which End + User accessed which media resource, IP addresses of End Users, + potential names and subscriber account information, etc.). + Confidentiality of this information must be protected as log records + are moved between CDNs. This information may also be sensitive from + the viewpoint that it can be the basis for charging across CDNs. + Therefore, appropriate levels of protection are needed against + corruption, duplication, and loss of this information. + +6. Acknowledgements + + The authors would like to thank Andre Beck, Gilles Bertrand, Mark + Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, + Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile + Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy + for their review comments and contributions to the text. + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 19] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +7. Informative References + + [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. + + + + +Niven-Jenkins, et al. Informational [Page 20] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + [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>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 21] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +Appendix A. Design Considerations for Realizing the CDNI Interfaces + + This section expands on how CDNI interfaces can reuse and leverage + existing protocols before describing each CDNI interface individually + and highlighting example candidate protocols that could be considered + for reuse or leveraging to implement the CDNI interfaces. However, + the options discussed here are purely examples and do not present any + consensus on protocols to be used later on. + +A.1. CDNI Control Interface + + The CDNI Control interface allows the Control system in + interconnected CDNs to communicate. The exact inter-CDN control + functionality required to be supported by the CDNI Control interface + is less well defined than the other three CDNI interfaces at this + time. + + However, as discussed in 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. + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 22] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +A.2. CDNI Request Routing Interface + + The CDNI Request Routing interface enables 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 and to allow the + Downstream CDN to control what the upstream Request Routing function + should return to the User Agent in the redirection message. + + Therefore, the CDNI Request Routing interface needs to offer a + mechanism for an Upstream CDN to issue a "Redirection Request" to a + Downstream CDN. The Request Routing interface needs to be able to + support scenarios where the initial User Agent request to the + Upstream CDN is received over DNS as well as over a content-specific + application protocol (e.g., HTTP, the Real Time Streaming Protocol + (RTSP), the Real Time Messaging Protocol (RTMP), etc.). + + Therefore, a Redirection Request is expected to contain information + such as: + + o The protocol (e.g., DNS, HTTP) over which the Upstream CDN + received the initial User Agent request. + + o Additional details of the User Agent request that are required to + perform effective Request Routing by the Downstream CDN. For DNS, + this would typically be the IP address of the DNS resolver making + the request on behalf of the User Agent. For requests received + over content-specific application protocols, the Redirection + Request could contain significantly more information related to + the original User Agent request but at a minimum is expected to + include the User Agent's IP address, the equivalent of the HTTP + Host header, and the equivalent of the HTTP abs_path as defined in + [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. + + + + + + + +Niven-Jenkins, et al. Informational [Page 23] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + + + + + +Niven-Jenkins, et al. Informational [Page 24] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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). + +A.3. CDNI Metadata Interface + + The CDNI Metadata interface enables the Distribution system in a + Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that + the Downstream CDN can properly process and respond to: + + o Redirection Requests received over the CDNI Request Routing + interface. + + o Content Requests received directly from User Agents. + + The CDNI Metadata interface needs to offer a mechanism for an + Upstream CDN to: + + o Distribute/update/remove CDNI Metadata to a Downstream CDN. + + and/or to allow a Downstream CDN to: + + o Make direct requests for CDNI Metadata objects. + + o Make recursive requests for CDNI Metadata -- for example, to + enable a Downstream CDN to walk down a tree of objects with + inter-object relationships. + + The CDNI Metadata interface is therefore similar to the CDNI Request + Routing interface because it is a request/response interface with the + potential addition that CDNI Metadata search may have more complex + semantics than a straightforward Request Routing redirection request. + Therefore, like the CDNI Request Routing interface, the CDNI Metadata + interface may be implemented as a WebService using one of the common + WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) + or possibly using other existing protocols such as XMPP [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. + + + +Niven-Jenkins, et al. Informational [Page 25] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +A.4. CDNI Logging Interface + + The CDNI Logging interface enables details of content distribution + and delivery activities to be exchanged between interconnected CDNs, + such as log records related to the delivery of content (similar to + the log records recorded in a web server's access log). + + Within CDNs today, log records are used for a variety of purposes. + Specifically, CDNs use logs to generate Call Data Records (CDRs) for + passing to billing and payment systems and to real-time (and near + real-time) analytics systems. Such applications place requirements + on the CDNI Logging interface to support guaranteed and timely + delivery of log messages between interconnected CDNs. It may also be + necessary to be able to prove the integrity of received log messages. + + Several protocols already exist that could potentially be used to + exchange CDNI logs between interconnected CDNs, including SNMP traps, + syslog, FTP, HTTP POST, etc., although it is likely that some of the + candidate protocols may not be well suited to meet all the + requirements of CDNI. For example, SNMP traps pose scalability + concerns, and SNMP does not support guaranteed delivery of traps and + therefore could result in log records being lost and the consequent + CDRs and billing records for that content delivery not being + produced, as well as that content delivery being invisible to any + analytics platforms. + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 26] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +Appendix B. Additional Material + + This section records related information that was produced as part of + defining the CDNI problem statement. + +B.1. Non-Goals for IETF + + Listed below are aspects of content delivery that the authors propose + be kept outside of the scope of the CDNI working group: + + o The interface between the Content Service Provider and the + Authoritative CDN (i.e., the Upstream CDN contracted by the CSP + for delivery by this CDN or by its Downstream CDNs). + + o The delivery interface between the delivering CDN Surrogate and + the User Agent, such as streaming protocols. + + o The request interface between the User Agent and the Request + Routing system of a given CDN. Existing IETF protocols (e.g., + HTTP, RTSP, DNS) are commonly used by User Agents to request + content from a CDN and by CDN Request Routing systems to redirect + the User Agent requests. The CDNI working group need not define + new protocols for this purpose. Note, however, that the CDNI + control plane interface may indirectly affect some of the + information exchanged through the request interface (e.g., URI). + + o The content acquisition interface between CDNs (i.e., the data + plane interface for actual delivery of a piece of content from one + CDN to the other). This is expected to use existing protocols + such as HTTP or protocols defined in other forums for content + acquisition between an origin server and a CDN (e.g., HTTP-based + C2 reference point of the Alliance for Telecommunications Industry + Solutions IPTV Interoperability Forum Content on Demand service + + + +Niven-Jenkins, et al. Informational [Page 27] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + (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. + + + + +Niven-Jenkins, et al. Informational [Page 28] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +B.2. Relationship to Relevant IETF Working Groups and IRTF Research + Groups + +B.2.1. ALTO WG + + As stated in the ALTO working group charter [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. + +B.2.2. DECADE WG + + The DECADE working group [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. + + + + +Niven-Jenkins, et al. Informational [Page 29] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + + + + + + +Niven-Jenkins, et al. Informational [Page 30] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + + 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. + +B.2.3. PPSP WG + + As stated in the PPSP working group charter [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. + +B.2.4. IRTF P2P Research Group + + Some information on CDN Interconnection motivations and technical + issues were presented in the P2P research group at IETF 77. The + presentation can be found in [P2PRG-CDNI]. + + + + + + + + +Niven-Jenkins, et al. Informational [Page 31] + +RFC 6707 CDN Interconnection Problem Statement September 2012 + + +Authors' Addresses + + Ben Niven-Jenkins + Velocix (Alcatel-Lucent) + 326 Cambridge Science Park + Milton Road, Cambridge CB4 0WG + UK + + EMail: ben@velocix.com + + + Francois Le Faucheur + Cisco Systems + Greenside, 400 Avenue de Roumanille + Sophia Antipolis 06410 + France + + Phone: +33 4 97 23 26 19 + EMail: flefauch@cisco.com + + + Nabil Bitar + Verizon + 60 Sylvan Road + Waltham, MA 02145 + USA + + EMail: nabil.n.bitar@verizon.com + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Informational [Page 32] + |