idnits 2.17.1 draft-watson-cdni-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (January 6, 2011) is 4860 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Watson 3 Internet-Draft BT 4 Intended status: Experimental January 6, 2011 5 Expires: July 10, 2011 7 CDN Interconnect Use Cases 8 draft-watson-cdni-use-cases-00 10 Abstract 12 [draft-jenkins-cdni-problem-statement] outlines the problem space for 13 CDN Interconnection within the IETF. This documents provides a 14 complimentary set of technical use cases for how CDNs may be 15 interconnected. The goal of this document is to outline real world 16 use-cases for CDN Interconnect, for the IETF, with the intention of 17 supporting the case for formation of a Working Group which would work 18 on the definition of standardised, interoperable methods of 19 Interconnecting CDNs. The goal of this document is NOT to define the 20 technical solutions to be used. 22 The intent of this document is to outline a set of technical use 23 cases. While the technical use cases may be influenced by business- 24 related and other non-technical factors, this document does not 25 attempt to detail any non-technical aspects of CDN Interconnect. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119] 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 10, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Single CDN . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Base Use Case for CDN Interconnection . . . . . . . . . . . . 6 71 5. Intermediate CDNs . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Other user cases . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 There are many possible combinations for the relationships between 82 the different parties (Network Service Provider (NSP), CDN Provider, 83 Content Service Provider (CSP), etc.) involved in end to end content 84 delivery. However, in the context of interconnecting CDNs the key 85 relationships are: 87 o How the CSP interacts with the CDN to publish and deliver content. 89 o How the End User interacts with the interconnected CDNs to request 90 and receive content. 92 o How the different CDNs interact with one another to deliver the 93 CSP's content to the End User. 95 The role of the NSP in the end to end content delivery is excluded 96 above because although some NSPs may also have their own CDN which 97 may be interconnected with other CDNs (that may or may not have 98 direct relationships with an ISP or ISPs), the existence of such 99 NSP<->CDN relationships does not affect the information that needs to 100 be exchanged across a CDN Interconnect and therefore these NSP<->CDN 101 relationships do not need to be specifically called out within the 102 use cases. In other words no NSP-specific information needs to be 103 exchanged across a CDN Interconnect. 105 Therefore this document will use NSPs to highlight that sets of End 106 Users may be attached to different ISP networks but it does not imply 107 or exclude any further relationship between the NSP and the CDN. 109 Equally, the type of CDNs (e.g. NSP operated, Over The Top, global 110 footprint, regional footprint, etc.) that interact over a CDN 111 Interconnect do not need to be explicitly called out within the use 112 cases. Again this is because the type of CDN that exists on either 113 side on a CDN Interconnect does not place an specific "CDN type" 114 related requirements on the information that needs to be exchanged 115 across the interconnect. 117 Therefore this document will refer to CDNs in a generic fashion where 118 it is meant that any reference to a CDN could refer to any type of 119 deployment and operational model for a CDN including both NSP 120 operated and Over-the-top CDNs, CDNs that partner with NSPs and those 121 that do not, etc. 123 In the sections that follow a number of CDN Interconnection use cases 124 are described along with an set of interactions between the main 125 Actors. The interactions described are illustrative in order to 126 highlight the main touchpoints and interactions, in a number of 127 places various details may be glossed over or omitted in order to 128 avoid complicating the use case description with layers of detail 129 that is not directly relevant to the use case. For example the use 130 cases do not go into detail of how a User Agent is redirected to a 131 Surrogate to avoid detailing the details and nuances of DNS versus 132 application level redirection. 134 2. Terminology 136 This document uses terms defined in 137 [draft-jenkins-cdni-problem-statement] 139 The following additional terms are used: 141 Authoritative CDN: A CDN that maintains a direct business 142 relationship with a CSP for the delivery of the CSP's Content. 144 Request Router: The function responsible for steering or directing a 145 Content Request received directly from a User Agent (or received from 146 another CDN via a CDNI) to a suitable Surrogate (or alternative CDN). 148 Surrogate: A device/function that interacts with other elements of 149 the CDN for the control and distribution of Content within the CDN 150 and interacts with User Agents for the delivery of the Content. 152 End User (EU): The 'real' user of the system, typically a human but 153 maybe some combination of hardware and/or software emulating a human 154 (e.g. for automated quality monitoring etc.). 156 User Agent (UA): Software (or a combination of hardware and software) 157 through which the User interacts with the Content Service. The User 158 Agent will communicate with the CSP's Service for the selection of 159 content and one or more CDNs for the delivery of the Content. Such 160 communication is not restricted to HTTP and may be via a variety of 161 protocols. Examples of User Agents (non-exhaustive) are: Browsers, 162 Set Top Boxes (STB), Dedicated content applications (e.g. media 163 players), etc. 165 3. Single CDN 167 This section outlines an illustrative model for content delivery via 168 a single CDN where there is no interconnection with other CDNs. It 169 does not describe all the details and variations but rather the high 170 level interactions between the different Actors (CSP, CDN, End User) 171 which can be used as a point of comparison with the CDN 172 Interconnection use cases described in subsequent sections. 174 +-------+ 175 | CSP-1 | 176 +-------+ 177 | 178 ,---------. 179 ,-' `-. 180 ( CDN-A ) 181 `-. ,-' 182 `---------' 183 | 184 ,---------. 185 ,-' 0 or `-. 186 ( more other ) 187 `-. networks ,-' 188 / `---------' \ 189 / \ 190 ,---------. ,---------. 191 ,-' `-. ,-' `-. 192 ( NSP-X ) ( NSP-Y ) 193 `-. ,-' `-. ,-' 194 `---------' `---------' 195 | | 196 +-------+ +-------+ 197 | UA-X | | UA-Y | 198 +-------+ +-------+ 200 Single CDN Use Case 202 As shown in the diagram CSP-1 maintains a direct relationship with 203 CDN-A and CDN-A delivers content to User Agents attached to NSP-X and 204 NSP-Y. NSP-X and NSP-Y may or may not have a relationship with CDN-A 205 and traffic from CDN-A may traverse one or more other networks before 206 reaching NSP-X or NSP-Y. 208 In order for UA-X to receive content the following illustrative 209 interactions occur: 211 1. UA-X selects a piece of Content (as directed by an End User) from 212 CSP-1's service (e.g. through a portal or EPG). 214 2. CSP-1 returns a URL for the selected content which resolve to the 215 Request Router in CDN-A. 217 3. CDN-A's Request Router will select an appropriate Surrogate 218 (Cache) and redirect UA-X to the selected Surrogate in CDN-A. 220 4. UA-X will connect to the selected Surrogate and request the 221 Content. 223 4. Base Use Case for CDN Interconnection 225 This section describes the base use case for CDN Interconnection on 226 which the other use cases described in subsequent sections are built 227 upon. 229 "CSPs have a desire to be able to get (some of their) content to very 230 large number of users and/or over many/all geographies and/or with a 231 high quality of experience, all without having to maintain direct 232 business relationships with many different CDN providers" 233 [draft-jenkins-cdni-problem-statement]. In order to minimise the 234 number of direct business relationships between a CSP and a set of 235 interconnected CDNs, it is assumed that a CSP will only be required/ 236 desire to have a direct relationship with a single CDN. The single 237 CDN selected by the CSP is referred to as "The Authoritative CDN" in 238 this document. When receiving requests from User Agents, the 239 Authoritative CDN will select an appropriate Surrogate in its own CDN 240 or will decide to delegate the delivery to another CDN that the 241 Authoritative CDN is interconnected with. 243 Although the Authoritative CDN makes the decision, that decision may 244 be influenced by policies configured by the CDN Operator(s) or the 245 CSP, e.g. "geo-blocking" rules that specify the geographic regions 246 where content can be delivered from (i.e. the location of the 247 Surrogates) and geographic locations where content can be delivered 248 to (i.e. the location of the End Users) or based on prior 249 notification of CDN capacity/availability from its own CDN surrogates 250 or interconnected CDN surrogates. 252 There is a large and diverse range of client software and devices 253 (referred to as User Agents in this document) used to access CSP 254 content via a CDN. It is assumed that content delivery through a set 255 of interconnected CDNs should not require any changes to existing 256 User Agents. 258 Taking the above two assumptions into account the base use case for 259 CDN Interconnection is shown in the diagram below. To simplify the 260 diagram the cloud showing "zero or more other networks" has been 261 excluded and NSPs are shown as though they are directly attached to 262 CDNs. This is not intended to imply any direct relationships or to 263 exclude the case where one or more networks may exist between the NSP 264 illustrated and the CDN. 266 +-------+ 267 | CSP-1 | 268 +-------+ 269 | 270 ,---------. ,---------. 271 ,-' `-. ,-' `-. 272 ( CDN-A )==I==( CDN-B ) 273 `-. ,-' /`-. ,-' 274 `---------' / `---------' 275 | ___/ | 276 | / | 277 ,---------. / ,---------. 278 ,-' `-. ,-' `-. 279 ( NSP-X ) ( NSP-Y ) 280 `-. ,-' `-. ,-' 281 `---------' `---------' 282 | | 283 +-------+ +-------+ 284 | UA-X | | UA-Y | 285 +-------+ +-------+ 287 ==I== CDN Interconnect 289 Base Use Case for CDN Interconnection 291 As shown in the diagram CSP-1 maintains a direct relationship with 292 CDN-A and so CDN-A is The Authoritative CDN for CSP-1. 294 CDN-A maintains a CDN Interconnect with CDN-B. 296 CDN-A may decide to delegate the delivery of contentto a UA/NSP to 297 CDN-B. How CDN-A makes such a decision is out of scope for this 298 document but some example scenarios include: 300 a. CDN-A has run out of capacity and so decides to use CDN-B to 301 handle the overspill rather than deny UA content requests from 302 NSP-X. 304 b. CDN-A may not have good coverage of the geographical region NSP-Y 305 resides in and so prefers to CDN-B to deliver content to that 306 region. 308 Let us assume that EU-Y wishes to use CSP-1's service and that CDN-A 309 decides to delegate the delivery of the content to CDN-B and that 310 CDN-B is willing to perform the delegated delivery. In order for 311 EU-Y to receive content the following illustrative interactions 312 occur: 314 1. UA-Y selects a piece of content (as directed by EU-Y) from 315 CSP-1's service (e.g. through a portal or EPG). 317 2. CSP-1 returns a URL for the selected content which resolve to the 318 Request Router in CDN-A, The Authoritative CDN for CSP-1. 320 3. CDN-A's Request Router makes a decision to delegate the delivery 321 to CDN-B. 323 4. CDN-A makes a request to CDN-B to deliver the content on behalf 324 of CDN-A and CDN-B responds with details of how CDN-A's Request 325 Router should respond to the request. 327 5. CDN-A's Request Router returns the appropriate response to UA-Y. 329 6. UA-Y will connect to CDN-B and request the content. Depending on 330 what CDN-B has returned to CDN-A earlier UA-Y may have connected 331 directly to a cache in CDN-B or may have connected to CDN-B's 332 Request Router where CDN-B's Request Router will select an 333 appropriate Surrogate (or possibly another CDN) and redirect UA-Y 334 to the selected Surrogate in CDN-B. 336 [Ed: There are a potentially couple of options, the above and the 337 option to hand off to CDN-B without making a request first. Consider 338 describing that as an option also? For example in the case of 339 intermediate CDN you might want to hand-off immediately to CDN-C 340 rather than relying on various requests flowing from A to B to C and 341 back.] 343 5. Intermediate CDNs 345 This use case extends the base use case by allowing CDN-B to accept a 346 delegated content delivery from CDN-A and then delegate the delivery 347 to CDN-C. 349 +-------+ 350 | CSP-1 | 351 +-------+ 352 | 353 ,---------. ,---------. ,---------. 354 ,-' `-. ,-' `-. ,-' `-. 355 ( CDN-A )====( CDN-B )====( CDN-B ) 356 `-. ,-' `-. ,-' `-. ,-' 357 `---------' `---------' `---------' 358 | 359 | 360 ,---------. 361 ,-' `-. 362 ( NSP-Z ) 363 `-. ,-' 364 `---------' 365 | 366 +-------+ 367 | UA-Z | 368 +-------+ 370 ==== CDN Interconnect 372 Intermediate CDNs use case 374 6. Other user cases 376 [Ed: Needs expansion, currently just a placeholer for ideas] 378 Acquisition flow (via upstream CDNs and direct to CSP Origin) 380 Accounting flow. 382 7. IANA Considerations 384 This document makes no request of IANA. 386 Note to RFC Editor: this section may be removed on publication as an 387 RFC. 389 8. Security Considerations 391 [Ed: TBD] 393 9. Acknowledgements 395 Thanks to Ben Niven-Jenkins for some valuable discussions and 396 suggestions. 398 10. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [draft-jenkins-cdni-problem-statement] 404 Niven-Jenkins, B., "Content Distribution Network 405 Interconnection (CDNI) Problem Statement", 2010. 407 Author's Address 409 Grant Watson 410 BT 412 Email: grant.watson@bt.com