idnits 2.17.1 draft-seedorf-alto-for-cdni-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2011) is 4563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Content Delivery Networks J. Seedorf 3 Interconnection NEC 4 Internet-Draft October 19, 2011 5 Intended status: Informational 6 Expires: April 21, 2012 8 ALTO for CDNi Request Routing 9 draft-seedorf-alto-for-cdni-00 11 Abstract 13 Network Service Providers (NSPs) are currently considering to deploy 14 Content Delivery Networks (CDNs) within their networks. As a 15 consequence of this development, there is a need for interconnecting 16 these local CDNs. The necessary interfaces for inter-connecting CDNs 17 are currently being defined in the Content Delivery Networks 18 Interconnection (CDNi) WG. This document focusses on the Request 19 Routing Interface of CDNi, and more specifically on how the solutions 20 currently being defined in the Application Layer Traffic Optimization 21 (ALTO) WG can improve CDNi request routing. The overall intention 22 behind this document is to foster discussions (in the CDNi as well as 23 in the ALTO WG) regarding a) if, b) how, and c) under what conditions 24 ALTO can be useful to optimize CDNi request routing. As basis for 25 this discussion, this document provides concrete examples of how ALTO 26 can be integrated within CDNi request routing. The examples in this 27 document are based on the use cases and examples currently being 28 discussed in the CDNi WG. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 21, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. CDNi Request Routing . . . . . . . . . . . . . . . . . . . . . 4 65 3. Using ALTO within CDNi Request Routing . . . . . . . . . . . . 5 66 3.1. ALTO to simplify DNS-based Request Routing Redirection . . 5 67 3.2. ALTO to simplify http-Redirection for Request Routing . . 7 68 3.3. ALTO to support Selection of Downstream CDN . . . . . . . 9 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 5. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Informative References . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 Many Network Service Providers (NSPs) are currently considering or 78 have already started to deploy Content Delivery Networks (CDNs) 79 within their networks. As a consequence of this development, there 80 is a need for interconnecting these local CDNs. Content Delivery 81 Networks Interconnection (CDNi) has the goal of standardizing 82 protocols to enable such interconnection of CDNs 83 [refs.cdniproblemstatement]. 85 The CDNi problem statement envisions four interfaces to be 86 standardized within the IETF for CDN interconnection 87 [refs.cdniproblemstatement]: 89 o CDNI Request Routing Interface 91 o CDNI Metadata Interface 93 o CDNI Logging Interface 95 o CDNI Control Interface 97 This document focusses solely on the CDNI Request Routing Interface. 98 In particular, this document shows concrete examples of how ALTO 99 [RFC5693] can be integrated in CDNi request routing. The goal of 100 this document is to show in what cases ALTO can benefit CDNi request 101 routing, giving concrete examples and explaining how ALTO improves 102 CDNi request routing in each of these examples. The examples used in 103 this document are based on the use cases and request routing 104 proposals currently being discussed in the CDNi WG 105 [refs.cdniusecases] [refs.cdnistrawman] and in the ALTO WG 106 [refs.altocdn]. The overall rationale of this document is to foster 107 discussions (in the CDNi as well as in the ALTO WG) regarding a) if, 108 b) how, and c) under what conditions ALTO can be useful to optimize 109 CDNi request routing. 111 Throughout this document, we use the terminology for CDNi defined in 112 [refs.cdniproblemstatement]. 114 2. CDNi Request Routing 116 The main purpose of the CDNI Request Routing Interface is described 117 in [refs.cdniproblemstatement] as follows: "The CDNI Request Routing 118 interface enables a Request Routing function in an upstream CDN to 119 query a Request Routing function in a downstream CDN to determine if 120 the downstream CDN is able (and willing) to accept the delegated 121 content request and to allow the downstream CDN to control what the 122 upstream Request Routing function should return to the User Agent in 123 the redirection message". On a high level, the scope of the CDNI 124 Request Routing Interface therefore contains two main tasks: 126 o A) Determining if the downstream CDN is willing to accept a 127 delegated content request 129 o B) Redirecting the content request coming from an upstream CDN to 130 the proper entry point or entity in the downstream CDN 132 3. Using ALTO within CDNi Request Routing 134 Application Layer Traffic Optimization (ALTO) is an approach for 135 guiding the resource provider selection process in distributed 136 applications that can choose among several candidate resources 137 providers to retrieve a given resource. By conveying network layer 138 (topology) information, an ALTO server can provide important 139 information to "guide" the resource provider selection process in 140 distributed applications. Usually, it is assumed that an ALTO server 141 conveys information these applications cannot measure themselves 142 [RFC5693]. 144 Originally, ALTO was motivated by the huge amount of cross-ISP 145 traffic generated by P2P applications [RFC5693]. Recently, however, 146 ALTO is also being considered for improving the request routing in 147 CDNs [refs.altocdn]. In this context, it has also been proposed to 148 use ALTO for selecting an entry-point in a downstream NSP's network 149 (see section 3.4 "CDN delivering Over-The-Top of a NSP's network" in 150 [refs.altocdn]). Also, the CDNi problem statement explicitly 151 mentions ALTO as a candidate protocol for "algorithms for selection 152 of CDN or Surrogate by Request-Routing systems" 153 [refs.cdniproblemstatement]. Yet, there have not been concrete 154 proposals so far on how to use ALTO in the context of CDN 155 interconnection. This document tries to close this gap by giving 156 some examples on how ALTO could be used within CDNi request routing. 158 As explicitly being out-of-scope for CDNi 159 [refs.cdniproblemstatement], the examples used in this document 160 assume that ingestion of content or acquiring content across CDNs is 161 not part of request routing as considered within CDNi standardization 162 work. The focus of using ALTO (as considered in this document) is 163 hence on request routing only, assuming that the content (desired by 164 the end user) is available in the downstream CDN (or can be aquired 165 by the downstream CDN by some means). 167 3.1. ALTO to simplify DNS-based Request Routing Redirection 169 If CDNi request routing is based on DNS, ALTO can potentially help to 170 avoid one or more DNS resolution steps. For instance, Figure 1 shows 171 a modified version of the high-level message sequence chart from 172 Figure 5 of [refs.cdniframework] (note that this figure is similar to 173 the high-level message sequence chart shown in Figure 3 of 174 [refs.cdnistrawman]). In the original figure (i.e. Figure 5 in 175 [refs.cdniframework]), the DNS server hosted by the upstream CDN 176 (assumed to be the authoritative DNS server for the requested 177 content), returns a DNS CNAME and NS record which essentially directs 178 the end user to the request router of the downstream CDN. However, 179 this redirection involves another DNS resolution for the request 180 router of the downstream CDN to be performed by the end user. 182 In the example using ALTO provided in Figure 1 of this document, the 183 downstream CDN provides the upstream CDN an ALTO network (and 184 corresponding cost) map by means of the ALTO protocol 185 [refs.altoprotocol] (0). This ALTO map provides sufficient 186 information for the upstream CDN to directly return a suitable IP- 187 address for the CDN entry point in the downstream CDN (2). 189 In principle, using ALTO this way the downstream CDN provider would 190 provide the decision on which delivery node is best by means of an 191 ALTO network map to the upstream CDN provider. This enables the 192 upstream CDN provider to directly return a suitable delivery node in 193 the downstream CDN to the end user as a response to the initial DNS 194 request received by the upstream CDN provider. 196 An imlicit assumption for the example in Figure 1 to work is that the 197 CDN entry point for the downstream CDN only depends on the location 198 of the end user. Using the cost map, the upstream CDN can determine 199 the "best" entry point in the downstream CDN. If the "best" entry 200 point depends also on the target domain ("cdn.csp.com" in the 201 example), it becomes more tricky to make such information available 202 to the upstream CDN by means of ALTO network map and cost map. One 203 possible way to still use ALTO in this case would be for the 204 downstream CDN to provide a different cost map for each Content 205 Service Provider (CSP). 207 End-User Operator B Operator A 208 | |ALTO network/cost map | 209 | |------------------------>|(0) 210 | | | 211 |DNS cdn.csp.com | | 212 |-------------------------------------------------->|(1) 213 | | | 214 | | | 215 |IPaddr of B's CDN Entry Point |(2) 216 |<--------------------------------------------------| 217 |HTTP cdn.csp.com | | 218 |------------------------>| | 219 | |(3) | 220 | |DNS op-b-acq.op-a.net | 221 | |------------------------>| 222 | | |(4) 223 | |IPaddr of A's Delivery Node 224 | |<------------------------| 225 | |HTTP op-b-acq.op-a.net | 226 | |------------------------>| 227 | | |(5) 228 | |Data | 229 | |<------------------------| 230 |Data | | 231 |<------------------------| | 233 Figure 1 - ALTO within DNS-based redirection of request routing 235 3.2. ALTO to simplify http-Redirection for Request Routing 237 Similar to the example given in the previous subsection, ALTO can 238 also help to reduce intermediate http redirection steps. Figure 2 239 shows a modified version of the the high-level message sequence chart 240 from Figure 3 of [refs.cdniframework] (note that this figure is 241 similar to the high-level message sequence chart shown in Figure 1 of 242 [refs.cdnistrawman]). In this case, the ALTO maps provided in step 243 (0) by the downstream CDN potentially enable the upstream CDN to 244 directly return - as a response to an http request - the hostname of 245 the suitable cache (delivery node) in the downstream CDN by means of 246 302-redirection (4). This use of ALTO would enable to avoid several 247 http-302 redirections and DNS resolutions by the end user (compare 248 with figure 3 of [refs.cdniproblemstatement], steps (2-4)). 250 Depending on how dynamically the actual "best" delivery node changes 251 (from the downstream CDN's request routing perspective), it might 252 only be meaningful to return to the end user the "best" entry point 253 or cluster within the downstream CDN. This would require an 254 additional http-redirect by the downstream request router to the 255 "best" actual cache. However, even in such a case ALTO can save one 256 http-redirect and one DNS resolution at the end user, consequently 257 speeding up the overall process of CDNi request routing. 259 End-User Operator B Operator A 260 | |ALTO network/cost map | 261 | |------------------------>| 262 |DNS cdn.csp.com | | 263 |-------------------------------------------------->| 264 | | |(1) 265 |IPaddr of A's Request Router | 266 |<--------------------------------------------------| 267 |HTTP cdn.csp.com | | 268 |-------------------------------------------------->|(2) 269 | | |(3) 270 | | |(4) 271 |302 node1.peer-a.op-b.net/cdn.csp.com | 272 |<--------------------------------------------------| 273 |DNS node1.peer-a.op-b.net| | 274 |------------------------>| | 275 | |(5) | 276 |IPaddr of B's Delivery Node | 277 |<------------------------| | 278 | | | 279 |HTTP node1.peer-a.op-b.net/cdn.csp.com | 280 |------------------------>| | 281 | |(6) | 282 | |DNS op-b-acq.op-a.net | 283 | |------------------------>| 284 | | |(7) 285 | |IPaddr of A's Request Router 286 | |<------------------------| 287 | |HTTP op-b-acq.op-a.net | 288 | |------------------------>| 289 | | |(8) 290 | |302 node2.op-b.acq.op-A.net 291 | |<------------------------| 292 | |DNS node2.op-b-acq.op-a.net 293 | |------------------------>| 294 | | |(9) 295 | |IPaddr of A's Delivery Node 296 | |<------------------------| 297 | | |(10) 298 | |Data | 299 | |<------------------------| 300 |Data | | 301 |<------------------------| | 303 Figure 2 - ALTO within http-based redirection of request routing 305 3.3. ALTO to support Selection of Downstream CDN 307 ALTO could also help for the upstream CDN provider to select a proper 308 downstream CDN provider for a given end user request. For instance, 309 a network map provided by each of several candidate downstream CDNs 310 could provide information to the upstream CDN provider regarding the 311 geopgraphical coverage, the location of "surrogates", or similar. 312 Future versions of this document will discuss this use case in more 313 detail, and provide concrete examples how ALTO can be used for 314 downstream CDN selection by the upstream CDN provider. 316 4. Security Considerations 318 Security Considerations will be discussed in a future version of this 319 document. 321 5. Summary and Outlook 323 This document presented some examples on how ALTO can be used within 324 CDNi Request Routing and argued why such use of ALTO is meaningful in 325 certain cases. The intention of this document is to arouse 326 discussions in the CDNi WG as well as the ALTO WG in order to find 327 consensus on scenarios where ALTO is beneficial to CDNi request 328 routing and to form agreement on how ALTO should be used in such 329 cases within the CDNi request routing protocol. It is the intention 330 to capture the outcome of such continuing discussions in future 331 versions of this document. 333 6. Acknowledgements 335 Jan Seedorf is partially supported by the COAST project (COntent 336 Aware Searching, retrieval and sTreaming, http://www.coast-fp7.eu), a 337 research project supported by the European Commission under its 7th 338 Framework Program (contract no. 248036). The views and conclusions 339 contained herein are those of the authors and should not be 340 interpreted as necessarily representing the official policies or 341 endorsements, either expressed or implied, of the COAST project or 342 the European Commission. 344 7. Informative References 346 [refs.cdniusecases] 347 Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and 348 P. Eardley, "SPEERMINT Peering Architecture", 349 draft-ietf-cdni-use-cases-00 (work in progress), 350 September 2011. 352 [refs.cdniproblemstatement] 353 Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 354 Distribution Network Interconnection (CDNI) Problem 355 Statement", draft-ietf-cdni-problem-statement-00 (work in 356 progress), September 2011. 358 [refs.altocdn] 359 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 360 S. Previdi, "Use Cases for ALTO within CDNs", 361 draft-jenkins-alto-cdn-use-cases-01 (work in progress), 362 June 2011. 364 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 365 Optimization (ALTO) Problem Statement", RFC 5693, 366 October 2009. 368 [refs.cdnistrawman] 369 Peterson, L. and J. Hartman, "Content Distribution Network 370 Interconnection (CDNI) Problem Statement", 371 draft-peterson-cdni-strawman-01 (work in progress), 372 May 2011. 374 [refs.cdniframework] 375 Davie, B. and L. Peterson, "Framework for CDN 376 Interconnection", draft-davie-cdni-framework-00 (work in 377 progress), July 2011. 379 [refs.altoprotocol] 380 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 381 draft-ietf-alto-protocol-09 (work in progress), June 2011. 383 Author's Address 385 Jan Seedorf 386 NEC Laboratories Europe, NEC Europe Ltd. 387 Kurfuersten-Anlage 36 388 Heidelberg 69115 389 Germany 391 Phone: +49 (0) 6221 4342 221 392 Email: jan.seedorf@neclab.eu 393 URI: http://www.neclab.eu