Network Working Group G. Watson Internet-Draft BT Intended status: Experimental January 6, 2011 Expires: July 10, 2011 CDN Interconnect Use Cases draft-watson-cdni-use-cases-00 Abstract [draft-jenkins-cdni-problem-statement] outlines the problem space for CDN Interconnection within the IETF. This documents provides a complimentary set of technical use cases for how CDNs may be interconnected. The goal of this document is to outline real world use-cases for CDN Interconnect, for the IETF, with the intention of supporting the case for formation of a Working Group which would work on the definition of standardised, interoperable methods of Interconnecting CDNs. The goal of this document is NOT to define the technical solutions to be used. The intent of this document is to outline a set of technical use cases. While the technical use cases may be influenced by business- related and other non-technical factors, this document does not attempt to detail any non-technical aspects of CDN Interconnect. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 10, 2011. Watson Expires July 10, 2011 [Page 1] Internet-Draft CDN Interconnect Use Cases January 2011 Copyright Notice Copyright (c) 2011 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Base Use Case for CDN Interconnection . . . . . . . . . . . . 6 5. Intermediate CDNs . . . . . . . . . . . . . . . . . . . . . . 8 6. Other user cases . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Watson Expires July 10, 2011 [Page 2] Internet-Draft CDN Interconnect Use Cases January 2011 1. Introduction There are many possible combinations for the relationships between the different parties (Network Service Provider (NSP), CDN Provider, Content Service Provider (CSP), etc.) involved in end to end content delivery. However, in the context of interconnecting CDNs the key relationships are: o How the CSP interacts with the CDN to publish and deliver content. o How the End User interacts with the interconnected CDNs to request and receive content. o How the different CDNs interact with one another to deliver the CSP's content to the End User. The role of the NSP in the end to end content delivery is excluded above because although some NSPs may also have their own CDN which may be interconnected with other CDNs (that may or may not have direct relationships with an ISP or ISPs), the existence of such NSP<->CDN relationships does not affect the information that needs to be exchanged across a CDN Interconnect and therefore these NSP<->CDN relationships do not need to be specifically called out within the use cases. In other words no NSP-specific information needs to be exchanged across a CDN Interconnect. Therefore this document will use NSPs to highlight that sets of End Users may be attached to different ISP networks but it does not imply or exclude any further relationship between the NSP and the CDN. Equally, the type of CDNs (e.g. NSP operated, Over The Top, global footprint, regional footprint, etc.) that interact over a CDN Interconnect do not need to be explicitly called out within the use cases. Again this is because the type of CDN that exists on either side on a CDN Interconnect does not place an specific "CDN type" related requirements on the information that needs to be exchanged across the interconnect. Therefore this document will refer to CDNs in a generic fashion where it is meant that any reference to a CDN could refer to any type of deployment and operational model for a CDN including both NSP operated and Over-the-top CDNs, CDNs that partner with NSPs and those that do not, etc. In the sections that follow a number of CDN Interconnection use cases are described along with an set of interactions between the main Actors. The interactions described are illustrative in order to highlight the main touchpoints and interactions, in a number of Watson Expires July 10, 2011 [Page 3] Internet-Draft CDN Interconnect Use Cases January 2011 places various details may be glossed over or omitted in order to avoid complicating the use case description with layers of detail that is not directly relevant to the use case. For example the use cases do not go into detail of how a User Agent is redirected to a Surrogate to avoid detailing the details and nuances of DNS versus application level redirection. 2. Terminology This document uses terms defined in [draft-jenkins-cdni-problem-statement] The following additional terms are used: Authoritative CDN: A CDN that maintains a direct business relationship with a CSP for the delivery of the CSP's Content. Request Router: The function responsible for steering or directing a Content Request received directly from a User Agent (or received from another CDN via a CDNI) to a suitable Surrogate (or alternative CDN). Surrogate: A device/function 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. 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.). User Agent (UA): Software (or a combination of hardware and software) through which the User interacts with the Content Service. The User Agent will communicate with the CSP's 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 (STB), Dedicated content applications (e.g. media players), etc. 3. Single CDN This section outlines an illustrative model for content delivery via a single CDN where there is no interconnection with other CDNs. It does not describe all the details and variations but rather the high level interactions between the different Actors (CSP, CDN, End User) which can be used as a point of comparison with the CDN Interconnection use cases described in subsequent sections. Watson Expires July 10, 2011 [Page 4] Internet-Draft CDN Interconnect Use Cases January 2011 +-------+ | CSP-1 | +-------+ | ,---------. ,-' `-. ( CDN-A ) `-. ,-' `---------' | ,---------. ,-' 0 or `-. ( more other ) `-. networks ,-' / `---------' \ / \ ,---------. ,---------. ,-' `-. ,-' `-. ( NSP-X ) ( NSP-Y ) `-. ,-' `-. ,-' `---------' `---------' | | +-------+ +-------+ | UA-X | | UA-Y | +-------+ +-------+ Single CDN Use Case As shown in the diagram CSP-1 maintains a direct relationship with CDN-A and CDN-A delivers content to User Agents attached to NSP-X and NSP-Y. NSP-X and NSP-Y may or may not have a relationship with CDN-A and traffic from CDN-A may traverse one or more other networks before reaching NSP-X or NSP-Y. In order for UA-X to receive content the following illustrative interactions occur: 1. UA-X selects a piece of Content (as directed by an End User) from CSP-1's service (e.g. through a portal or EPG). 2. CSP-1 returns a URL for the selected content which resolve to the Request Router in CDN-A. 3. CDN-A's Request Router will select an appropriate Surrogate (Cache) and redirect UA-X to the selected Surrogate in CDN-A. Watson Expires July 10, 2011 [Page 5] Internet-Draft CDN Interconnect Use Cases January 2011 4. UA-X will connect to the selected Surrogate and request the Content. 4. Base Use Case for CDN Interconnection This section describes the base use case for CDN Interconnection on which the other use cases described in subsequent sections are built upon. "CSPs have a desire to be able to get (some of their) content to very large number of users and/or over many/all geographies and/or with a high quality of experience, all without having to maintain direct business relationships with many different CDN providers" [draft-jenkins-cdni-problem-statement]. In order to minimise the number of direct business relationships between a CSP and a set of interconnected CDNs, it is assumed that a CSP will only be required/ desire to have a direct relationship with a single CDN. The single CDN selected by the CSP is referred to as "The Authoritative CDN" in this document. When receiving requests from User Agents, the Authoritative CDN will select an appropriate Surrogate in its own CDN or will decide to delegate the delivery to another CDN that the Authoritative CDN is interconnected with. Although the Authoritative CDN makes the decision, that decision may be influenced by policies configured by the CDN Operator(s) or the CSP, e.g. "geo-blocking" rules that specify the geographic regions where content can be delivered from (i.e. the location of the Surrogates) and geographic locations where content can be delivered to (i.e. the location of the End Users) or based on prior notification of CDN capacity/availability from its own CDN surrogates or interconnected CDN surrogates. There is a large and diverse range of client software and devices (referred to as User Agents in this document) used to access CSP content via a CDN. It is assumed that content delivery through a set of interconnected CDNs should not require any changes to existing User Agents. Taking the above two assumptions into account the base use case for CDN Interconnection is shown in the diagram below. To simplify the diagram the cloud showing "zero or more other networks" has been excluded and NSPs are shown as though they are directly attached to CDNs. This is not intended to imply any direct relationships or to exclude the case where one or more networks may exist between the NSP illustrated and the CDN. Watson Expires July 10, 2011 [Page 6] Internet-Draft CDN Interconnect Use Cases January 2011 +-------+ | CSP-1 | +-------+ | ,---------. ,---------. ,-' `-. ,-' `-. ( CDN-A )==I==( CDN-B ) `-. ,-' /`-. ,-' `---------' / `---------' | ___/ | | / | ,---------. / ,---------. ,-' `-. ,-' `-. ( NSP-X ) ( NSP-Y ) `-. ,-' `-. ,-' `---------' `---------' | | +-------+ +-------+ | UA-X | | UA-Y | +-------+ +-------+ ==I== CDN Interconnect Base Use Case for CDN Interconnection As shown in the diagram CSP-1 maintains a direct relationship with CDN-A and so CDN-A is The Authoritative CDN for CSP-1. CDN-A maintains a CDN Interconnect with CDN-B. CDN-A may decide to delegate the delivery of contentto a UA/NSP to CDN-B. How CDN-A makes such a decision is out of scope for this document but some example scenarios include: a. CDN-A has run out of capacity and so decides to use CDN-B to handle the overspill rather than deny UA content requests from NSP-X. b. CDN-A may not have good coverage of the geographical region NSP-Y resides in and so prefers to CDN-B to deliver content to that region. Let us assume that EU-Y wishes to use CSP-1's service and that CDN-A decides to delegate the delivery of the content to CDN-B and that CDN-B is willing to perform the delegated delivery. In order for EU-Y to receive content the following illustrative interactions occur: Watson Expires July 10, 2011 [Page 7] Internet-Draft CDN Interconnect Use Cases January 2011 1. UA-Y selects a piece of content (as directed by EU-Y) from CSP-1's service (e.g. through a portal or EPG). 2. CSP-1 returns a URL for the selected content which resolve to the Request Router in CDN-A, The Authoritative CDN for CSP-1. 3. CDN-A's Request Router makes a decision to delegate the delivery to CDN-B. 4. CDN-A makes a request to CDN-B to deliver the content on behalf of CDN-A and CDN-B responds with details of how CDN-A's Request Router should respond to the request. 5. CDN-A's Request Router returns the appropriate response to UA-Y. 6. UA-Y will connect to CDN-B and request the content. Depending on what CDN-B has returned to CDN-A earlier UA-Y may have connected directly to a cache in CDN-B or may have connected to CDN-B's Request Router where CDN-B's Request Router will select an appropriate Surrogate (or possibly another CDN) and redirect UA-Y to the selected Surrogate in CDN-B. [Ed: There are a potentially couple of options, the above and the option to hand off to CDN-B without making a request first. Consider describing that as an option also? For example in the case of intermediate CDN you might want to hand-off immediately to CDN-C rather than relying on various requests flowing from A to B to C and back.] 5. Intermediate CDNs This use case extends the base use case by allowing CDN-B to accept a delegated content delivery from CDN-A and then delegate the delivery to CDN-C. Watson Expires July 10, 2011 [Page 8] Internet-Draft CDN Interconnect Use Cases January 2011 +-------+ | CSP-1 | +-------+ | ,---------. ,---------. ,---------. ,-' `-. ,-' `-. ,-' `-. ( CDN-A )====( CDN-B )====( CDN-B ) `-. ,-' `-. ,-' `-. ,-' `---------' `---------' `---------' | | ,---------. ,-' `-. ( NSP-Z ) `-. ,-' `---------' | +-------+ | UA-Z | +-------+ ==== CDN Interconnect Intermediate CDNs use case 6. Other user cases [Ed: Needs expansion, currently just a placeholer for ideas] Acquisition flow (via upstream CDNs and direct to CSP Origin) Accounting flow. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations [Ed: TBD] Watson Expires July 10, 2011 [Page 9] Internet-Draft CDN Interconnect Use Cases January 2011 9. Acknowledgements Thanks to Ben Niven-Jenkins for some valuable discussions and suggestions. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [draft-jenkins-cdni-problem-statement] Niven-Jenkins, B., "Content Distribution Network Interconnection (CDNI) Problem Statement", 2010. Author's Address Grant Watson BT Email: grant.watson@bt.com Watson Expires July 10, 2011 [Page 10]