RFC 7337
Content Distribution Network Interconnection (CDNI) Requirements
RFC 7337: Content Distribution Network Interconnection (CDNI) Requirements 🎀
Okay bestie, this one is from August 2014 and it's an Informational doc, so it's not a Standards Track spec 💅. It was written by K. Leung, Ed. (Cisco) and Y. Lee, Ed. (Comcast), and it's published by the Internet Engineering Task Force (IETF) with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨.
Abstract ✨
Content delivery is usually handled by CDNs (Content Delivery Networks) that are specifically architected and provisioned for the job 🌸. Content delivered over IP networks has grown a LOT, so existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are building their own CDNs too 🦋. To get content from the Content Service Provider (CSP) to end users, that content might travel through multiple CDNs. So there's a need to interconnect CDNs that used to be standalone, so they can work together as one delivery platform from the CSP all the way to the end users 🫶.
The goal of this doc is to outline the requirements for the solution and interfaces that the CDNI working group is going to specify 🔥.
Status of This Memo 🌈
This document is not an Internet Standards Track specification. It's published for informational purposes 🍓.
This document is a product of the IETF. It represents the consensus of the IETF community. It has gotten public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💅.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7337 🔗.
Copyright Notice 💜
Copyright (c) 2014 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) as in effect on the date of publication. Please review these documents carefully, because they explain your rights and restrictions with respect to this document 🧚. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⭐.
Table of Contents 🦋
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. CDNI Model and CDNI Interfaces ..................................4
3. Generic CDNI Requirements .......................................6
4. CDNI Control Interface Requirements .............................7
5. CDNI Request Routing Redirection Interface Requirements ........10
6. CDNI Footprint & Capabilities Advertisement Interface
Requirements ...................................................12
7. CDNI Metadata Interface Requirements ...........................14
8. CDNI Logging Interface Requirements ............................18
9. CDNI Security Requirements .....................................20
10. Security Considerations .......................................21
11. Contributors ..................................................21
12. Acknowledgements ..............................................21
13. References ....................................................22
13.1. Normative References .....................................22
13.2. Informative References ...................................221. Introduction 🎀
Okay so video and multimedia content on the Internet is growing super fast and it's not stopping anytime soon 📈. CDNs are honestly the move here, because they bring real perks: lower delivery cost for cacheable content, a better quality of experience for end users, and more robust delivery 💖. That's why CDNs get used for large-scale content delivery all the time. With content growing like this, existing CDN providers are scaling up and lots of NSPs and ESPs are building their own CDNs too ✨.
Depending on the policy of the Content Service Provider (CSP), it's usually desirable that a given piece of content can reach an end user no matter where that user is or what network they're attached to 🌍. So CDNs that used to be standalone need to interconnect, so they can interoperate and act together like one delivery infrastructure 🫶. The Content Distribution Network Interconnection (CDNI) working group was chartered to develop an interoperable and scalable solution for exactly that 👑.
The CDNI Problem Statement [RFC6707] lays out the problem area the CDNI working group is chartered to tackle 🔍. The Use Cases for CDNI document [RFC6770] talks about the use cases for CDN Interconnection 💅. The Framework for CDN Interconnection [RFC7336] covers the technology framework for the CDNI solution and its interfaces 🧩.
The goal of this document is to write down the requirements for the CDNI solution and interfaces 🎯. To hit the timelines in the working group charter, this doc sorts the CDNI requirements into "High Priority", "Medium Priority", and "Low Priority" 🌸.
1.1. Terminology 💜
This document uses the terminology defined in [RFC6707]. On top of that, the phrases "High Priority", "Medium Priority", and "Low Priority" should be read like this 🦋:
- "High Priority": when a requirement is tagged
{HIGH}, the working group considers it an essential function for CDNI and necessary for a deployable solution 🔥. It has to be met, even if that delays the working group in delivering a deployable solution. - "Medium Priority": when a requirement is tagged
{MED}, the working group considers it an important function for CDNI ✨. It has to be met, unless it's established that trying to meet it would delay the working group in delivering a deployable solution. - "Low Priority": when a requirement is tagged
{LOW}, the working group considers it a useful function for CDNI 🧚. The working group will try to meet it as long as that doesn't block the "High Priority" and "Medium Priority" requirements and doesn't delay the working group in delivering a deployable solution 🌈.
Part 1 of 6 is done bestie 💖 Part 2 is coming up next, so stay tuned ✨
2. CDNI Model and CDNI Interfaces ✨
okay so this section is the map 🗺️ of all the CDNI interfaces. the "CDNI Expanded Model and CDNI Interfaces" figure and the short descriptions of each interface are copied here just for convenience 💖. the real, definitive version lives in [RFC7336], so if anything here looks off, go check there 🫶
- CDNI Control interface (CI): operations to bootstrap and parameterize the other CDNI interfaces, plus operations to pre-position, revalidate, and purge both metadata and content. the second half of that list is sometimes called the "Trigger interface" 🎀
- CDNI Request Routing interface: operations to decide which CDN (and optionally which Surrogate inside that CDN) serves an end user's requests. it's actually a bundle of two related interfaces 📦
- CDNI Footprint & Capabilities Advertisement interface (FCI): asynchronous operations (as defined in [RFC7336]) that swap routing info, like the network footprint and capabilities a given CDN serves. this is what lets CDN selection happen for later user requests ✨
- CDNI Request Routing Redirection interface (RI): synchronous operations (as defined in [RFC7336]) that pick a delivery CDN (Surrogate) for one specific user request 🦋
- CDNI Metadata interface (MI): operations that communicate the metadata governing how interconnected CDNs deliver content. examples are geo-blocking directives, availability windows, access control mechanisms, and purge directives. it may be a mix of:
- asynchronous operations that exchange metadata governing later user requests for content 🌸
- synchronous operations that govern behavior for one given user request for content 💅
- CDNI Logging interface (LI): operations that let interconnected CDNs share relevant activity logs 📝. it may be a mix of:
- real-time exchanges, good for runtime traffic monitoring 👀
- offline exchanges, good for analytics and billing 💰
Here's the figure, copied exactly so the diagram stays intact 🧚:
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** and .... interfaces outside the scope of CDNI
Figure 1: CDNI Expanded Model and CDNI Interfacesquick legend 🔑: <==> means the interfaces are inside the scope of CDNI, and **** and .... mean they're outside it 🙈
3. Generic CDNI Requirements 💜
this section is the big list of generic requirements that don't belong to any one interface. some of them are going to touch multiple or even all of the interfaces, so they're kind of a whole vibe 🌈. management is a huge deal for CDN operation, but only the fault and performance management is covered here, under the CDNI Logging interface requirements 📊. the other kinds of management are specific to each CDN provider, so they don't need to match for CDNs to work together 🫶
The requirements are listed below, with their IDs and priority levels, copied exactly 💅:
GEN-1{MED}Wherever possible, the CDNI interfaces should reuse or leverage existing IETF protocols.GEN-2{HIGH}The CDNI solution shall not require a change, or an upgrade, to the User Agent to benefit from content delivery through interconnected CDNs.GEN-3{HIGH}The CDNI solution shall not require a change, or an upgrade, to the Content Service Provider delivering content through a single CDN, to benefit from content delivery through interconnected CDNs.GEN-4{HIGH}The CDNI solution shall not depend on intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include Surrogate topology, Surrogate status, cached content, etc.GEN-5{HIGH}The CDNI solution shall support CDN interconnection when delivery to the User Agent is based on HTTP [RFC7230]. (Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols. Hence, it is useful to state requirements on the CDNI solution in terms of specifying which acquisition and delivery protocols are to be supported).GEN-6{HIGH}The CDNI solution shall support acquisition across CDNs based on HTTP [RFC7230]. (The note above applies to this requirement, too.)GEN-7{LOW}The CDNI solution may support delivery to the User Agent based on protocols other than HTTP.GEN-8{LOW}The CDNI solution may support acquisition across CDNs based on protocols other than HTTP.GEN-9{MED}The CDNI solution should support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels beyond the first level.GEN-10{MED}The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e., the topology of interconnected CDNs cannot be restricted to a tree, ring, star, etc.).GEN-11{HIGH}The CDNI solution shall prevent looping of any CDNI information exchange.GEN-12{HIGH}When making use of third-party reference, the CDNI solution shall consider the potential issues associated with the use of various format of third-party references (e.g., NAT or IPv4/IPv6 translation potentially breaking third-party references based on an IP addresses such as URI containing IPv4 or IPv6 address literals, split DNS situations potentially breaking third-party references based on DNS FQDNs) and wherever possible avoid, minimize or mitigate the associated risks based on the specifics of the environments where the reference is used (e.g., likely or unlikely presence of NAT in the path). In particular, this applies to situations where the CDNI solution needs to construct and convey uniform resource identifiers for directing/redirecting a content request, as well as to situations where the CDNI solution needs to pass on a third-party reference (e.g., identify the IP address of a User Agent) in order to allow another entity to make a more informed decision (e.g., make a more informed request routing decision by attempting to derive location information from the third-party reference).GEN-13{HIGH}The CDNI solution shall support HTTP Adaptive Streaming content.
4. CDNI Control Interface Requirements ✨
okay so the CDNI Control interface (CI) is basically the bestie that gets everything started 🫶 its main jobs are setting up the interconnection across CDNs, bootstrapping the other CDNI interfaces, and letting the Upstream CDN trigger actions in the Downstream CDN, like deleting objects from caches or kicking off pre-positioned content acquisition 🧚 the working group tried to line each requirement up with the right interface, but ngl a solution for one requirement might end up applying to a different interface too, or to more than one 💅
CI-1 {HIGH} 💖 the CDNI Control interface shall let the Upstream CDN ask the Downstream CDN (including any cascaded Downstream CDNs) to delete an object or a set of objects, and/or their CDNI Metadata, from the CDN Surrogates and any storage. the only stuff that can be purged is the object(s) and CDNI Metadata that belong to the Upstream CDN making the request. no touching anyone else's stuff, periodt 🙅♀️
CI-2 {MED} ✨ the CDNI Control interface should let you purge multiple content items identified by a Content Collection ID in one single Content Purge action. so much more efficient, it's giving productivity 🌈
CI-3 {MED} 🦋 the CDNI Control interface should let the Upstream CDN ask the Downstream CDN (including cascaded Downstream CDNs) to mark an object or set of objects and/or their CDNI Metadata as "stale" and revalidate them before they get delivered again. not deleted, just flagged so they get rechecked first 👀
CI-4 {HIGH} 🔥 the CDNI Control interface shall let the Downstream CDN report back when these actions are done (both its own and any cascaded Downstream CDNs'), in a way that fits the action, like synchronously or asynchronously. the confirmation receipt should include a success or failure indication. and if the Downstream CDN can't delete the content from its storage, the failure indication and the reason must be included too. accountability is everything 💅
CI-5 {MED} 🌸 the CDNI Control interface should support the Upstream CDN starting and controlling pre-positioned CDNI Metadata acquisition by the Downstream CDN ✨
CI-6 {MED} 🍓 the CDNI Control interface should support the Upstream CDN starting and controlling pre-positioned content acquisition by the Downstream CDN. same energy as CI-5 but for the actual content 🎀
CI-7 {LOW} 🧚 the CDNI Control interface may let a CDN set up, update and end a CDN interconnection with another CDN, where one CDN acts as the Downstream CDN for the other CDN (which is the Upstream CDN) 🦋
CI-8 {LOW} 💜 the CDNI Control interface may let you control the CDNI interfaces between any two CDNs separately for each direction. for example, the direction where CDN1 is the Upstream CDN and CDN2 is the Downstream CDN can be handled independently from the direction where CDN2 is the Upstream CDN and CDN1 is the Downstream CDN. two-way street, but make it separate lanes 🛣️
CI-9 {LOW} 🌈 the CDNI Control interface may let you bootstrap the CDNI Request Routing interface. stuff this could potentially include:
- negotiating the request routing method, like DNS versus HTTP, if more than one method is specified.
- discovering the CDNI Request Routing interface endpoints.
- the info needed to set up secure communication between the CDNI Request Routing interface endpoints.
CI-10 {LOW} 🫧 the CDNI Control interface may let you bootstrap the CDNI Metadata interface. this info could include:
- discovering the CDNI Metadata interface endpoints.
- the info needed to set up secure communication between the CDNI Metadata interface endpoints.
CI-11 {LOW} 🎀 the CDNI Control interface may let you bootstrap the Content Acquisition interface. this could include exchanging and negotiating which Content Acquisition methods get used across the CDNs, like HTTP, HTTPS, FTP, or ATIS C2 [ATIS-0800042] 🛰️
CI-12 {LOW} 💅 the CDNI Control interface may let you bootstrap the CDNI Logging interface. this info could include:
- discovering the CDNI Logging interface endpoints.
- the info needed to set up secure communication between the CDNI Logging interface endpoints.
- negotiating or defining the log file format and the set of fields exported through the logging protocol, with some granularity (for example, per content type).
- negotiating or defining parameters for transaction log exports, like the export protocol, file compression, export frequency, and directory.
5. CDNI Request Routing Redirection Interface Requirements ✨
the CDNI Request Routing Redirection interface (RI) is the one that lets the Request Routing systems in interconnected CDNs talk to each other so a request can get redirected across CDNs 🦋 it's giving teamwork
RI-1 {HIGH} 🌸 the CDNI Request Routing Redirection interface shall support efficient request routing for small objects. for example, it might use a mode like DNS-based request routing, where you trade off some freshness and accuracy of CDN/Surrogate selection for less request routing load (like lighter-weight queries and caching of request routing decisions) 💖
RI-2 {HIGH} 🔥 the CDNI Request Routing Redirection interface shall support efficient request routing for large objects. this might call for a mode like HTTP-based request routing, where the freshness and accuracy of CDN/Surrogate selection is worth a per-request decision and a per-request CDNI Request-Routing protocol call 👑
RI-3 {HIGH} ✨ the CDNI Request Routing Redirection interface shall support recursive CDNI request routing 🧚
RI-4 {HIGH} 🫶 the CDNI Request Routing Redirection interface shall support iterative CDNI request routing 🌈
RI-5 {MED} 💀 if a request redirection loop is detected, the loop prevention mechanism of the CDNI Request Routing Redirection interface should let the request be redirected on an alternate CDN path, instead of not being redirected at all. so no dead ends, just a detour 🛣️
RI-6 {MED} 🍓 the CDNI Request Routing Redirection interface should support a mechanism that enforces a limit on how many successive CDN redirections a single request can go through 🙅♀️
RI-7 {LOW} 🎀 the CDNI Request Routing Redirection interface may support a mechanism that lets an Upstream CDN avoid redirecting a request to a Downstream CDN when that's likely to make the total redirection time go over some limit. no one wants to wait forever to load their stuff 🙈
RI-8 {HIGH} 💜 the CDNI Request Routing Redirection interface shall let the Upstream CDN include, in the query to the Downstream CDN, whatever info the Downstream CDN needs to process the redirection query. this could include:
- info from which the geographic region of the IP address of the User Agent that originated the request can be inferred (for example, the User Agent FQDN for HTTP-based request routing, or the DNS Proxy FQDN for DNS-based request routing).
- requested resource info (for example, the Resource URI for HTTP-based request routing, or the Resource hostname for DNS-based request routing).
- any other available request info (for example, request headers for HTTP-based request routing).
RI-9 {LOW} 🌸 the CDNI Request Routing Redirection interface may also let the Upstream CDN point to the CDNI Metadata that applies to the requested content, whether directly or through inheritance. for illustration, the CDNI Metadata being pointed to could cover metadata that applies to any content, metadata that applies to a content collection (that the requested content belongs to), and/or metadata that applies to the requested content individually 🧚
RI-10 {HIGH} 🔥 the CDNI Request Routing Redirection interface shall let the Downstream CDN include the following in its response to the Upstream CDN:
- a status code, especially one that says whether the request was accepted or rejected (for example, because the Downstream CDN is unwilling or unable to serve it). if the request is rejected, an error code must also be provided, so the Upstream CDN can react appropriately, like picking another Downstream CDN or serving the request itself.
- redirection info (for example, the Resource URI for HTTP-based request routing, or the equivalent of a DNS record for DNS-based request routing).
RI-11 {HIGH} 🦋 the CDNI Request Routing Redirection interface shall allow per-chunk request routing of HTTP Adaptive Streaming content 📺
RI-12 {LOW} ✨ the CDNI Request Routing Redirection interface may let the Upstream CDN use the info the Downstream CDN conveyed during the Recursive Request Routing process to rewrite an HTTP Adaptive Streaming manifest file 🎬
RI-13 {LOW} 🫧 the CDNI Request Routing interface may let the Upstream CDN recompute the message digest or digital signature over the invariant portion of the chunk URIs embedded in the HTTP Adaptive Streaming manifest file. keeping the signature valid even after the URIs change 🔐
RI-14 {MED} 💖 the CDNI Request Routing Redirection interface should correlate the HTTP Adaptive Stream manifest file with the related chunks it references 🧩
RI-15 {MED} 👑 the CDNI Request Routing Redirection interface should allow an efficient method for transferring request routing info for multiple chunks from the Downstream CDN to the Upstream CDN during the recursive request routing process. batch it, bestie, don't send them one by one 🚀
6. CDNI Footprint & Capabilities Advertisement Interface Requirements ✨
okay bestie, this section is all about the Footprint & Capabilities Advertisement interface (FCI) 💅. Its whole job is to let the Downstream CDN tell the Upstream CDN what it's got going on: where it can serve, what it can do, and whether it's even up for taking more requests right now 🌸.
Let's get into the requirements 🦋
FCI-1 {HIGH} The CDNI Footprint & Capabilities Advertisement interface shall let the Downstream CDN share coarse info with the Upstream CDN about whether it's able and/or willing to handle requests from the Upstream CDN 💖. Think of it as a simple yes/no vibe check, like "ready for more requests" or "not ready," which is super handy when the Downstream CDN is overloaded or having a failure 😭.
FCI-2 {MED} The CDNI Footprint & Capabilities Advertisement interface should let the Downstream CDN share aggregate info so the Upstream CDN can pick the right CDN during request routing ✨. This is the stuff like capabilities, resources, and affinities (aka preferences or cost) 🎀. It could include:
- supported content types and delivery protocols 🍓
- footprint (e.g., Layer 3 coverage) 🌍
- a set of metrics/attributes (e.g., streaming bandwidth, storage resources, distribution and delivery priority) 📊
- a set of affinities (e.g., preferences, indication of distribution/delivery fees) 💜
- information to facilitate request redirection (e.g., Reachability information of Downstream CDN Request Routing system) 🧚
[Note: Some of this information, such as supported content types and delivery protocols, may also potentially be taken into account by the Distribution system in the Upstream CDN for pre-positioning of content and/or metadata in the Downstream CDN in case of pre-positioned content acquisition and/or pre-positioned CDNI Metadata acquisition.] 🫶
FCI-3 {MED} When cascaded redirection is happening, the CDNI Footprint & Capabilities Advertisement interface should also let the Downstream CDN include info about the capabilities, resources, and affinities of any CDNs it might redirect requests to 🔥. Then the CDNI Request Routing interface shall prevent this info exchange from looping forever 🙈. Nobody wants that chaos!
FCI-4 {LOW} The CDNI Footprint & Capabilities Advertisement interface may let the Downstream CDN share aggregate info on CDNI administrative limits and policy 👑. The Upstream CDN's Request Routing system can use this when it's deciding which CDN to pick ✨. For example, it could include:
- maximum number of requests redirected by the Upstream CDN to be served simultaneously by the Downstream CDN. 🌈
- maximum aggregate volume of content (e.g., in Terabytes) to be delivered by the Downstream CDN over a time period. 💅
FCI-5 {MED} The CDNI Footprint & Capabilities Advertisement interface should support advertising these types of capabilities 🦋:
- delivery protocol (e.g., HTTP versus Real Time Messaging Protocol [RTMP]) 🎀
- acquisition protocol (for acquiring content from an Upstream CDN) 🌸
- redirection mode (e.g., DNS Redirection versus HTTP Redirection) 🧚
- capabilities related to CDNI Logging (e.g., supported logging mechanisms) 📝
- capabilities related to CDNI Metadata (e.g., authorization algorithms or support for proprietary vendor metadata) 💜
FCI-6 {LOW} The CDNI Control interface may allow CDNs to exchange and negotiate which delivery authorization mechanisms they support, like URI-signature-based validation 🔐. Ooh, very cute teamwork energy 💖.
FCI-7 {HIGH} The CDNI Footprint & Capabilities Advertisement interface shall support extensible fields for conveying CDN capabilities, and for indicating the footprint, in the advertisement from the Downstream CDN to the Upstream CDN 🌈. Extensible means future-proof, and that's giving main character energy ⭐.
7. CDNI Metadata Interface Requirements ✨
okay so the CDNI Metadata interface (MI) 🦋 is basically how the Distribution systems in interconnected CDNs talk to each other, so that content distribution metadata with inter-CDN scope can actually get exchanged across CDNs 💖. it's giving main character energy, fr.
ngl people keep talking about the CDNI Metadata Distribution thing like it's one single "protocol" 🤔, but further analysis is needed to figure out whether these requirements should live on one interface and protocol or be split across several. like, some metadata could ride along in-band with the actual content acquisition across CDNs (e.g., content MD5 in HTTP header) 🎀, while other metadata might need its own out-of-band interface and protocol (e.g., geo-blocking information) 🌍. we'll see 🔮
MI-1 {HIGH} 💌 The CDNI Metadata interface shall let the Upstream CDN hand the Downstream CDN content distribution metadata with inter-CDN scope.
MI-2 {HIGH} 🌸 The CDNI Metadata interface shall support exchanging CDNI Metadata for both the dynamic content acquisition model and the pre-positioning content acquisition model. both models get the love 💅
MI-3 {HIGH} 🧚 The CDNI Metadata interface shall support a mode where no CDNI Metadata, or just a subset of it, is initially communicated to the Downstream CDN, along with info about how/where to acquire the rest of the CDNI Metadata (i.e., Dynamic CDNI Metadata acquisition). the "get the rest later" era 🫶
MI-4 {MED} 🍓 The CDNI Metadata interface should support a mode where all the relevant CDNI Metadata is initially communicated to the Downstream CDN (i.e., pre-positioned CDNI Metadata acquisition). ideally everything arrives up front ✨
MI-5 {HIGH} 🗝️ Whether we're in the pre-positioned content acquisition model or the dynamic content acquisition model, the CDNI Metadata interface shall provide the necessary info so the Downstream CDN can acquire the content from an upstream source (e.g., acquisition protocol and Uniform Resource Identifier in Upstream CDN -- or rules to construct this URI). no mystery URIs allowed 🙅♀️
MI-6 {HIGH} 🌈 The CDNI Metadata shall allow signaling of one or more upstream sources. each upstream source can be in the Upstream CDN, in another CDN, at the CSP origin server, or at any arbitrary source designated by the Upstream CDN. note that some upstream sources (e.g., the content origin server) may or may not be willing to serve the content to the Downstream CDN. if the Upstream CDN knows this policy, then it may omit those sources when exchanging CDNI Metadata. 💅
MI-7 {HIGH} 📬 The CDNI Metadata interface (possibly in conjunction with the CDNI Control interface) shall let the Upstream CDN request addition and modification of CDNI Metadata into the Downstream CDN. ask and you shall receive 🙏
MI-8 {HIGH} 🧹 The CDNI Metadata interface (possibly in conjunction with the CDNI Control interface) shall allow removal of obsolete CDNI Metadata from the Downstream CDN. this could happen through an explicit removal request from the Upstream CDN, or through expiration of a Time-To-Live (TTL) attached to the CDNI Metadata. bye bye old stuff 👋
MI-9 {HIGH} 🔍 The CDNI Metadata interface shall allow association of CDNI Metadata at the granularity of an individual object. this is needed for fine-grain CDNI Metadata distribution down to a single object when necessary 🎯
MI-10 {HIGH} 📦 The CDNI Metadata interface shall allow association of CDNI Metadata at the granularity of an object set. this is needed for scalable metadata distribution when a bunch of objects share the same distribution policy. efficiency is the moment ⚡
MI-11 {HIGH} 👑 The CDNI Metadata interface shall support multiple levels of inheritance, with precedence going to more specific metadata. for example, the CDNI Metadata Distribution protocol may support metadata that applies to any content, metadata that applies to a content collection, and metadata that applies to an individual content item. content level metadata overrides content collection metadata, which overrides metadata for any content. the most specific one wins, periodt 💖
MI-12 {HIGH} ⚖️ The CDNI Metadata interface shall make sure that conflicting metadata with overlapping scope is either prevented or deterministically handled. no drama allowed 🙅♀️
MI-13 {HIGH} 🛑 The CDNI Metadata interface shall allow signaling of content distribution control policies. for example, this could potentially 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; expiration time may also be included to remove content).
- delegation whitelist/blacklist (i.e., information defining through which Downstream CDNs the content may/may not be delivered).
MI-14 {HIGH} ⏰ The CDNI Metadata interface shall be able to exchange a set of metadata elements with specified semantics (e.g., start of time window, end of time window). clear meanings only, no vibes-based metadata 🫶
MI-15 {HIGH} 🎁 The CDNI Metadata interface shall allow exchange of opaque metadata elements, whose semantics are not defined in CDNI but are established by private CDN agreement. mystery box energy, but make it legal 🤫
MI-16 {HIGH} 🔐 The CDNI Metadata interface shall allow signaling of authorization checks and validation that the Surrogate has to perform before delivery. for example, this could potentially include the need to validate info (e.g., Expiry time, Client IP address) required for access authorization. check the vibes before you serve 🙅♀️
MI-17 {MED} 🧁 The CDNI Metadata interface should allow signaling of CDNI-relevant Surrogate cache behavior parameters. for example, this could potentially include:
- control of whether the query string of an HTTP URI is to be ignored by the Surrogate cache.
- enforcement of caching directives by the Downstream CDN that are different from the ones signaled in the HTTP headers (e.g.,
Expiresfield). - rate-pacing by the Downstream CDN for content delivery (e.g., Progressive Download).
MI-18 {HIGH} 🎬 The CDNI Metadata interface shall provide an indication of related content (e.g., HTTP Adaptive Bit Rate chunks) through the Content Collection ID (CCID) metadata. the Downstream CDN can use this to do operations on the whole group of content. for example, this could potentially include:
- content acquisition for the entire set of files when one piece of content is requested.
- local file management and storage that bundles all the files for the content.
- purging the entire set of files associated with the content.
- logging of the delivery of the content for the session when at least one file in the set was delivered.
MI-19 {MED} 📊 The CDNI Metadata interface should support an optional mechanism that lets the Upstream CDN tell the Downstream CDN which CDNI Log fields to provide for all content items, for specific sets of content items, or for specific content items delivered using HTTP. a CDNI implementation that doesn't support this optional CDNI Metadata Distribution interface mechanism shall ignore this log format indication, and generate CDNI Logging format for HTTP Adaptive Streaming using the default set of CDNI Logging fields. (note: this function may be part of the CDNI Metadata interface or the CDNI Control interface.) 🙈
MI-20 {MED} 🏷️ The CDNI Metadata interface should allow the Upstream CDN to signal the Content Collection ID value to the Downstream CDN, for all content items, for specific sets of them, or for specific content items delivered using HTTP. whenever the Downstream CDN is told by the Upstream CDN to report the Content Collection ID field in the log records, the Downstream CDN is to use the value provided through the CDNI Metadata interface for the corresponding content. note that the Session ID field along with the Content Collection ID may be used for HTTP Adaptive Streaming content. 💜
MI-21 {MED} 🎟️ The CDNI Metadata interface should allow the Upstream CDN to signal the Authorization Group ID value to the Downstream CDN for all the related HTTP Adaptive Streaming content (i.e., manifest file and chunks). the authorization result for one piece of content (e.g., the manifest file) is carried over to the related content (e.g., the chunks). one check, whole group, iconic 👑
MI-22 {HIGH} 🧩 The CDNI Metadata interface shall support an extensible format for CDNI Metadata delivery from the Upstream CDN to the Downstream CDN. room to grow, always 🌷🦋
8. CDNI Logging Interface Requirements ✨
okay so this section is all about the CDNI Logging interface (LI) 📝 and bestie, the authors are being super honest here: right now people talk about it like it's ONE "protocol," but they're still figuring out whether these requirements should live on a single interface and protocol or spread across multiple ones 🤷♀️ that's literally the plot twist.
LI-1 {HIGH} The CDNI Logging interface and architecture shall ensure reliable transfer of CDNI logging information across CDNs. 💖
LI-2 {HIGH} The CDNI Logging interface shall provide logging of deliveries and incomplete deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN. 🎀
LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface should allow the Downstream CDN to report to the Upstream CDN logging for deliveries and incomplete deliveries performed by the Downstream CDN itself as well as logging for deliveries and incomplete deliveries performed by cascaded CDNs on behalf of the Downstream CDN. 🦋
LI-4 {HIGH} The CDNI Logging interface shall support batch/offline exchange of logging records. 📦
LI-5 {MED} The CDNI Logging interface should also support an additional mechanism taking into account the timing constraints for some types of logging records (e.g., near-real time for monitoring and analytics applications). ⏱️
LI-6 {HIGH} The CDNI Logging interface shall define a log file format and a set of fields to be exported for various CDNI Logging events. 🌸
LI-7 {HIGH} The CDNI Logging interface shall define a transport mechanism to exchange CDNI Logging files. 🚚
LI-8 {MED} The CDNI Logging interface should allow a CDN to query another CDN for relevant current logging records (e.g., for on-demand access to real-time logging information). 🔍
LI-9 {LOW} The CDNI Logging interface may support aggregate/summarized logs (e.g., total bytes delivered for a content regardless of individual User Agents to which it was delivered). 🧮
LI-10 {LOW} The CDNI Logging interface may support logging of performance data for deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN. Performance data may include various traffic statistics (the specific parameters are to be determined). The CDNI Logging interface may support the Upstream CDN to indicate the nature and contents of the performance data to be reported by the Downstream CDN. 📊
LI-11 {MED} The CDNI Logging interface should support logging of consumed resources (e.g., storage, bandwidth) to the Upstream CDN for deliveries where content is stored by the Downstream CDN for delivery to User Agents. The information logged may include the type of storage (e.g., Origin, Intermediate, Edge, Cache) as well as the amount of storage (e.g., total GB, GB used, per time period, per content domain) all of which may impact the cost of the services. 💸
LI-12 {MED} In the case of cascaded CDNs, the CDNI Logging interface should support the Downstream CDN to report consumed resources (e.g. storage, bandwidth) to the Upstream CDN where content is stored by the Downstream CDN itself as well as logging for storage resources when content storage is performed by cascaded CDNs on behalf of the Downstream CDN. 🌐
LI-13 {HIGH} The CDNI Logging interface shall support logging of deleted objects from the Downstream CDN to the Upstream CDN as a result of explicit delete requests on via the CDNI Control interface from the Upstream CDN. 🗑️
LI-14 {HIGH} The CDNI Logging interface shall support the exchange of extensible log file formats to support proprietary information fields. These information fields shall be agreed upon ahead of time between the corresponding CDNs. 🧩
LI-15 {HIGH} The CDNI Logging interface shall allow a CDN to notify another CDN about which CDNI Logging information is available for transfer and/or no longer available (e.g., it exceeded some logging retention period or some logging retention volume). 🔔
LI-16 {MED} The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content. 🎬
LI-17 {MED} The CDNI Logging interface should provide privacy protection by not disclosing information that can be used to identify the user (e.g., method that anonymizes the IP address carried in the logging field). The use of the privacy protection mechanism is optional. 🙈
9. CDNI Security Requirements 🔐
okay the security section is SERIOUS but make it cute 💅 it says this section identifies the requirements related to CDNI security, and some of these are expected to affect multiple or all protocols. so yeah, these are main character requirements that touch basically everything 👑
SEC-1 {HIGH} All the CDNI interface shall support secure operation over unsecured IP connectivity (e.g., the Internet). This includes authentication, confidentiality, integrity protection as well as protection against spoofing and replay. 🛡️
SEC-2 {HIGH} The CDNI solution shall provide sufficient protection against denial-of-service attacks. This includes protection against spoofed delivery requests sent by User Agents directly to a Downstream CDN attempting to appear as if they had been redirected by a given Upstream CDN when they have not. 🚨
SEC-3 {MED} The CDNI solution should be able to ensure that for any given request redirected to a Downstream CDN, the Downstream CDN can determine the Upstream CDN that redirected the request directly to the Downstream CDN (leading to that request being served by that CDN, or being further redirected). 🔗
SEC-4 {MED} The CDNI solution should be able to ensure that for any given transaction log generated by the Downstream CDN and communicated to an Upstream CDN, the Upstream CDN can confirm the transmitted log record corresponds to a request redirection by the Upstream CDN. 🧾
SEC-5 {LOW} The CDNI solution may provide a mechanism allowing an Upstream CDN that has credentials to acquire content from the CSP origin server (or another CDN), to allow establishment of credentials authorizing the Downstream CDN to acquire the content from the CSP origin server (or the other CDN) (e.g., in case the content cannot be acquired from the Upstream CDN). 🗝️
10. Security Considerations 🛡️
okay this one is short but it matters: this document discusses CDNI security requirements in Section 9. go read that part, it's where the drama is 🎭
11. Contributors 🫶
this document reflects contributions from the following individuals, and these amazing people deserve all the flowers 💐
Francois Le Faucheur Cisco Systems EMail: flefauch@cisco.com
Mahesh Viveganandhan Cisco Systems EMail: mvittal@cisco.com
Grant Watson Alcatel-Lucent (Velocix) EMail: gwatson@velocix.com
12. Acknowledgements 🌷
this document leverages the earlier work of the IETF CDI working group, in particular as documented in [REQ-ROUTE], [DIST-REQS], and [AAA-REQS]. the whole CDI crew laid the groundwork, so thank you queens 👑
the authors would like to thank Gilles Bertrand, Christophe Caillet, Bruce Davie, Phil Eardley, Ben Niven-Jenkins, Agustin Schapira, Emile Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana Oprescu, and Spencer Dawkins for their input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and Ramki Krishnan contributed to this document by addressing the requirements of the ATIS Cloud Services Forum. 💕
Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI Logging interface, respectively. 🎞️
Stephen Farrell, Adrian Farrel, Benoit Claise, Sean Turner, Christer Holmberg, and Carlos Pignataro provided review comments that helped improve the document. ✨
13. References 📚
13.1. Normative References
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC7336] Peterson, L., Davie, B., and R. Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, August 2014.
13.2. Informative References
[AAA-REQS] Gilletti, D., Nair, R., Scharber, J., and J. Guha, "Content Internetworking (CDI) Authentication, Authorization, and Accounting Requirements", Work in Progress, June 2001.
[ATIS-0800042] ATIS, "ATIS IPTV Content on Demand Service", ATIS-0800042 v002, September 2011, <https://www.atis.org/docstore/product.aspx?id=25670>.
[DIST-REQS] Amini, L., "Distribution Requirements for Content Internetworking", Work in Progress, November 2001.
[REQ-ROUTE] Cain, B., "Request Routing Requirements for Content Internetworking", Work in Progress, November 2001.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RTMP] Parmar, H., Ed. and M. Thornburgh, Ed., "Adobe's Real Time Messaging Protocol", December 2012, <http://www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf>.
Authors' Addresses 📮
Kent Leung (editor) Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Phone: +1 408 526 5030 EMail: kleung@cisco.com
Yiu Lee (editor) Comcast One Comcast Center Philadelphia, PA 19103 USA
EMail: yiu_lee@cable.comcast.com
📦 where this page comes from
- ietf: rfc7337 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms