idnits 2.17.1 draft-jenkins-alto-cdn-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 date (April 27, 2011) is 4747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 409, but no explicit reference was found in the text 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 B. Niven-Jenkins 3 Internet-Draft Velocix (Alcatel-Lucent) 4 Intended status: Informational G. Watson 5 Expires: October 29, 2011 BT 6 N. Bitar 7 Verizon 8 April 27, 2011 10 Use Cases for ALTO within CDNs 11 draft-jenkins-alto-cdn-use-cases-00 13 Abstract 15 For some time, Content Distribution Networks (CDNs) have been used in 16 the delivery of some Internet services (e.g. delivery of websites, 17 software updates and video delivery) as they provide numerous 18 benefits including reduced delivery cost for cacheable content, 19 improved quality of experience for end users and increased robustness 20 of delivery. 22 In order to derive the optimal benefit from a CDN it is preferable to 23 deliver content from the servers (caches) that are "closest" to the 24 End User requesting the content, where "closest" may be as simple as 25 "geographical or network distance" combined with CDN server load 26 within a location, but may also consider other more complex 27 combinations of metrics and CDN or Network Service Provider (NSP) 28 policies. 30 There are a number of different ways in which a CDN may obtain the 31 necessary network topology and/or cost information to allow it to 32 serve End Users from the most optimal servers/locations, such as 33 static configuration, passively listening to routing protocols 34 directly, or obtaining topology and cost by querying an information 35 service such as the ALTO map & cost services. 37 This document describes the use cases for a CDN to be able to obtain 38 network topology and cost information from an ALTO server(s) and 39 details additional requirements on the ALTO protocol that result from 40 such use cases. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on October 29, 2011. 59 Copyright Notice 61 Copyright (c) 2011 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. CDN overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. CDN & ALTO Use Cases . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. CDN deployed within a Broadband network . . . . . . . . . 8 81 3.2. CDN delivering Over-The-Top of a NSP's network . . . . . . 9 82 3.3. Additional Use Cases . . . . . . . . . . . . . . . . . . . 10 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 For some time, Content Distribution Networks (CDNs) have been used in 92 the delivery of some Internet services (e.g. delivery of websites, 93 software updates and video delivery) as they provide numerous 94 benefits including reduced delivery cost for cacheable content, 95 improved quality of experience for end users and increased robustness 96 of delivery. 98 A CDN typically consists of a network of servers often attached to 99 Network Service Provider (NSP) networks. The point of attachment is 100 often as close to content consumers and peering points as 101 economically or operationally feasible in order to decrease traffic 102 load on the NSP backbone and to provide better user experience 103 measured by reduced latency and higher throughput. 105 As the volume of video and multimedia content delivered over the 106 Internet is rapidly increasing and expected to continue doing so in 107 the future, existing CDN providers are scaling up their 108 infrastructure and many NSPs are deploying their own CDNs. The 109 result of such deployments is typically that more CDN servers are 110 being deployed within NSP networks and those CDN servers are being 111 deployed in locations that are "deeper" (i.e. geographically closer 112 to the NSP's End Users) than was previously the case. 114 In order to derive the optimal benefit from a CDN it is preferable to 115 deliver content from the servers (caches) that are "closest" to the 116 End User requesting the content, where "closest" may be as simple as 117 "geographical or network distance" combined with CDN server load 118 within a location, but may also consider other more complex 119 combinations of metrics and CDN or NSP policies. 121 When CDN servers are deployed outside of an NSP's network or in a 122 small number of central locations within an NSP's network a 123 simplified view of the NSP's topology or an approximation of 124 proximity is typically sufficient to enable the CDN to serve End 125 Users from the optimal server/location. As CDN servers are deployed 126 deeper within NSP networks it becomes necessary for the CDN to have 127 more detailed knowledge of the underlying network topology and costs 128 between network locations in order to enable the CDN to serve End 129 Users from the most optimal servers for the NSP. 131 There are a number of different ways in which a CDN may obtain the 132 necessary network topology and/or cost information to allow it to 133 serve End Users from the most optimal servers/locations, such as 134 static configuration, passively listening to routing protocols 135 directly, or obtaining topology and cost by querying an information 136 service such as the ALTO map & cost services. 138 The rest of this document describes the use cases for a CDN to be 139 able to obtain network topology and cost information from an ALTO 140 server(s) and details additional requirements on the ALTO protocol 141 that result from such use cases. 143 1.1. Terminology 145 The following terms are taken from 146 [I-D.jenkins-cdni-problem-statement] and repeated here for 147 completeness. 149 Content Distribution Network (CDN) / Content Delivery Network (CDN): 150 Network infrastructure in which the network elements cooperate at 151 layers 4 through layer 7 for more effective delivery of Content to 152 User Agents. Typically a CDN consists of a Request Routing system, a 153 Distribution System (that includes a set of Surrogates), a Logging 154 System and a CDN control system. 156 Content Service Provider (CSP): Provides a Content Service to End 157 Users (which the End Users access via a User Agent). A CSP may own 158 the Content made available as part of the Content Service, or may 159 license content rights from another party. 161 End User (EU): The 'real' user of the system, typically a human but 162 maybe some combination of hardware and/or software emulating a human 163 (e.g. for automated quality monitoring etc.) 165 Network Service Provider (NSP): Provides network-based connectivity/ 166 services to Users. 168 User Agent (UA): Software (or a combination of hardware and software) 169 through which the End User interacts with the Content Service. The 170 User Agent will communicate with the CSP's Service for the selection 171 of content and one or more CDNs for the delivery of the Content. 172 Such communication is not restricted to HTTP and may be via a variety 173 of protocols. Examples of User Agents (non-exhaustive) are: 174 Browsers, Set Top Boxes (STB), Dedicated content applications (e.g. 175 media players), etc. 177 2. CDN overview 179 This section provides a high level and simplified overview of the 180 operation of a CDN to help put the ALTO & CDN use cases into context. 182 A typical CDN consists of a number of functional components, however 183 in the context of ALTO three functional components are of interest: 184 The Request Routing function, the Caching (Surrogate) function and 185 the Origin function. 187 The Request Routing function within a CDN responsible for receiving a 188 content request from a user agent, obtaining and maintaining 189 necessary information about a set of candidate surrogates, and for 190 selecting and redirecting the user to the appropriate surrogate. 192 The Surrogate (Cache) function interacts with other elements of the 193 CDN for the control and distribution of Content within the CDN and 194 interacts with User Agents for the delivery of the Content. 196 The figure below shows a high level call flow showing the interaction 197 between a User Agent, Request Router and Surrogate for the delivery 198 of content in a single CDN. 200 User Agent Request Router Surrogate 201 | | | 202 | (1) Initial Request | | 203 +------------------------------>| | 204 | +--+ | 205 | | | (2) Surrogate Selection | 206 | |<-+ | 207 | (3) Redirection Response | | 208 |<------------------------------+ | 209 | | | 210 | (4) Content Request | | 211 +------------------------------------------------------------>| 212 | | | 213 | | (5) Content | 214 |<------------------------------------------------------------+ 215 | | | 217 1. The User Agent makes an initial request to the CDN. Depending on 218 the type of content being delivered and the configuration of the 219 CDN this request may be an application (e.g. HTTP, RTMP, etc.) 220 level request directly from the User Agent or may be a DNS 221 request via the User Agent's assigned DNS proxy. 222 2. The Request Router selects an appropriate Surrogate based on the 223 User Agent's (or its proxy's) IP address, the Request Router's 224 knowledge of the network topology and reachability cost between 225 CDN caches and end users, and any additional CDN policies. 226 3. The Request Router responds to the UA's initial request with an 227 appropriate response containing a redirection to the selected 228 cache, for example by returning an appropriate DNS A/AAAA record, 229 a HTTP 302 redirect, etc. 231 4. The User Agent uses the information provided in the Redirection 232 Response to connect directly to the Surrogate and request the 233 desired content. 234 5. If CDN policy allows the User Agent to receive the requested 235 content, the Surrogate delivers the content to the User Agent. 236 A. [Not Shown] If the Surrogate does not have a copy of the 237 requested content then it obtains it from the appropriate 238 Origin Server (possibly via ). 239 Note: A Surrogate may not communicate with the Origin server 240 directly and instead obtain the requested content from other 241 surrogates or caching layers in the CDN hierarchy. The 242 details of how content requests filter through the CDN 243 hierarchy to the Origin server are internal to a specific CDN 244 and are out of scope of this document. 246 3. CDN & ALTO Use Cases 248 The primary use case for ALTO in a CDN context is to improve the 249 selection of a CDN surrogate or Origin server. The CDN Request 250 Routing system makes use of an ALTO server to choose a better CDN 251 surrogate or Origin than would otherwise be the case. In its 252 simplest form an ALTO server would provide an NSP with the capability 253 to offer a service to a CDN which provides network map and cost 254 information that the CDN can use to enhance its surrogate and/or 255 Origin selection. 257 Although it is possible to obtain raw network map and cost 258 information in other ways, for example passively listening to the 259 NSP's routing protocols, the use of an ALTO service to expose that 260 information may provide additional control to the NSP over how their 261 network map/cost is exposed. Additionally it may enable the NSP to 262 maintain a functional separation between their routing plane and 263 network map computation functions. This may be attractive for a 264 number of reasons, for example: 266 o The ALTO service could provide a filtered view of the network 267 and/or cost map that relates to CDN locations and their proximity 268 to end users, for example to allow the NSP to control the level of 269 topology detail they are willing to share with the CDN. 270 o The ALTO service could apply additional policies to the network 271 map and cost information to provide a CDN-specific view of the 272 network map/cost, for example to allow the NSP to encourage the 273 CDN to use network links that would not ordinarily be preferred by 274 a Shortest Path First routing calculation. 275 o The routing plane may be operated and controlled by a different 276 operational entity (even within a single NSP) to the CDN and the 277 ALTO service could provide a layer of separation because: 279 * The CDN is not able to passively listen to routing protocols. 280 * The NSP is not willing to allow the CDN to passively listen to 281 routing protocols, e.g. because the NSP is concerned the CDN 282 may inadvertently interfere with the routing plane or because 283 the routing plane and the CDN are operated by different 284 operational entities/groups (including different entities 285 within the same NSP). 286 o Etc. 288 The use cases in this document are not necessarily specific as to the 289 relationship between the commercial/operational entity that "owns" 290 the ALTO service and the commercial/operational entity that "owns" 291 the CDN service as it is assumed that such relationships will be 292 deployment specific. Although the ownership of each service may 293 affect the level of topology detail that the ALTO service will be 294 permitted to expose, it is assumed that the general requirements a 295 CDN places on the ALTO service should not change provided that the 296 ALTO server is able to expose sufficient topology for CDN to make 297 appropriate surrogate selection decisions. 299 For the rest of this document it is assumed that the ALTO service 300 will be operated by the entity that operates the underlying network. 302 The following sections outline some specific, non-exhaustive, example 303 use cases, which are subsets of the primary use case outlined above 304 but applied to specific usage examples to demonstrate how a CDN could 305 make use of ALTO services. 307 3.1. CDN deployed within a Broadband network 309 In this use case an NSP is providing Broadband services to its 310 customers and has deployed a CDN within its Broadband network to 311 alleviate the cost and/or improve the User Experience of content 312 services for its Broadband customers. 314 The topology of Broadband access/backhaul networks is often much more 315 constrained than metro/core networks. If CDN surrogates are deployed 316 within the access/backhaul network, for a given set of End Users, the 317 NSP is likely to want to utilise the surrogates deployed in the same 318 access/backhaul region as the End Users in preference to surrogates 319 deployed within the metro/core or within other access/backhaul 320 regions. It is common for Broadband subscribers to obtain their IP 321 addresses dynamically and in many deployments the IP subnets 322 allocated to a particular access/backhaul region can change 323 relatively frequently. For example new IP subnets are added as the 324 subscriber base grows, IP subnets are moved from one Broadband 325 product in the NSP's portfolio to another as customers migrate in 326 order to optimise the NSP's IP address utilisation, or they are 327 simply moved as part of IP address management, etc. Additionally, in 328 certain cases, CDN surrogates allocated in a regional network may 329 become overloaded, leading to the selection of other CDN caches for 330 content delivery. If this occurs, an NSP would typically prefer a 331 surrogate to be selected that is deployed in the the next best (cost- 332 wise) location. 334 In order to meet the NSP's objective of utilising their CDN to 335 constrain access/backhaul costs and/or improve User Experience it is 336 important that the CDN is able to select the most appropriate 337 surrogate for a given set of End User IP subnets. Although the 338 network topology is often reasonably static, in networks where the IP 339 subnets allocated to a Broadband region are changing relatively 340 frequently, static configuration of End User IP Subnets to CDN 341 surrogates is possible but some NSPs may consider the operational 342 burden of having to update such static configuration too high and 343 would prefer the CDN to be able to dynamically obtain network map and 344 cost information. 346 The NSP could make use of an ALTO service to expose a cost mapping 347 between End User IP subnets and CDN surrogate IP subnets/locations to 348 meet its requirements while avoiding static configuration or direct 349 integration of the CDN into its IP routing plane and to avoid the CDN 350 being required to implement network layer routing computations. 352 3.2. CDN delivering Over-The-Top of a NSP's network 354 In this use case a CDN is deployed within one or more NSPs' networks 355 but is delivering content "Over-The-Top" into another NSP's network 356 (which we will call NSP Z) where the CDN is not deployed. 358 The CDN is unlikely to have direct visibility of NSP Z's network 359 topology and may have a choice of entry points into NSP Z's network 360 from which it could serve content to NSP Z's End Users. For example 361 because NSP Z has direct peering links with the CDN in a number of 362 locations or NSP Z has transit and/or peering relationships with 363 several other NSPs where the CDN is deployed. NSP Z may wish to 364 influence the locations from which the CDN serves content based on 365 some factor(s) that it does not wish to expose directly or that might 366 change over time. For example the available transit/peering capacity 367 in different locations, the cost of connectivity to different 368 locations, etc. 370 For example, a CSP is using NSP A's CDN and another NSP (NSP Z) has 371 peering with NSP A in LA and NYC. NSP Z would like to influence 372 which peering location NSP A's CDN delivers content out of for NSP 373 Z's end users by using their knowledge of the capacity they have 374 deployed between those peering locations and groups of end users 375 without directly exposing their internal topology to NSP A. 377 3.3. Additional Use Cases 379 The following additional use case are relevant to ALTO and will be 380 described in more detail in a future version of this document: 382 o Inter-provider CDN. 383 o Use of ALTO to aid a CDN select from multiple Origins. 385 4. IANA Considerations 387 This document makes no specific request of IANA. 389 Note to RFC Editor: this section may be removed on publication as an 390 RFC. 392 5. Security Considerations 394 TBD. 396 6. Acknowledgements 398 The authors would like to thank Vijay Gurbani for his review comments 399 and contributions to the text. 401 7. Normative References 403 [I-D.jenkins-cdni-problem-statement] 404 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 405 Distribution Network Interconnection (CDNI) Problem 406 Statement", draft-jenkins-cdni-problem-statement-02 (work 407 in progress), March 2011. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 Authors' Addresses 414 Ben Niven-Jenkins 415 Velocix (Alcatel-Lucent) 416 326 Cambridge Science Park 417 Milton Road, Cambridge CB4 0WG 418 UK 420 Email: ben@velocix.com 422 Grant Watson 423 BT 425 Email: grant.watson@bt.com 427 Nabil Bitar 428 Verizon 429 40 Sylvan Road 430 Waltham, MA 02145 431 USA 433 Email: nabil.bitar@verizon.com