idnits 2.17.1 draft-penno-alto-cdn-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 : ---------------------------------------------------------------------------- == There are 2 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 04, 2010) is 5075 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 643, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Penno 3 Internet-Draft S. Raghunath 4 Intended status: Experimental J. Medved 5 Expires: December 6, 2010 M. Bakshi 6 Juniper Networks 7 R. Alimi 8 Yale University 9 S. Previdi 10 Cisco Systems 11 June 04, 2010 13 ALTO and Content Delivery Networks 14 draft-penno-alto-cdn-00 16 Abstract 18 Networking applications can request through the ALTO protocol 19 information about the underlying network topology from the ISP or 20 Content Provider (henceforth referred as Provider) point of view. In 21 other words, what a Provider prefers in terms of traffic optimization 22 -- and a way to distribute it. The ALTO Service provides information 23 such as preferences of network resources with the goal of modifying 24 network resource consumption patterns while maintaining or improving 25 application performance. 27 A main use case of the ALTO Service is its integration with of 28 Content Delivery Networks (CDN). In this document we describe the 29 deployment scenarios and considerations for a ALTO Service in the 30 case of CDNs. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 6, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 7 77 4.2. CDN Node Discovery and Status . . . . . . . . . . . . . . 7 78 4.3. CDN Node Status Updates received by HTTP Redirector . . . 7 79 4.4. CDN Node Status Updates received by ALTO Server . . . . . 8 80 5. DNS Integration . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. Administrative domains and ALTO . . . . . . . . . . . . . . . 11 82 6.1. CDN nodes in the ISP administrative domain . . . . . . . . 11 83 6.2. CDN nodes in a separate administrative domain from 84 that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.3. Integrating with managed DNS service . . . . . . . . . . . 14 86 6.3.1. Managed DNS resolver used to redirect to local 87 cache . . . . . . . . . . . . . . . . . . . . . . . . 14 88 6.3.2. Managed DNS resolver used with multiple CDN vendors . 16 89 7. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 16 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 Content Delivery Networks are becoming increasingly important in the 101 Internet [ARBOR] and many CDNs today already use some form of 102 application proximity through geolocation. But in many cases the 103 content provider and the Service Provider are disjoint and even if 104 content servers are co-located into the ISP's networks, there is no 105 standardized way to share information. Therefore a natural step 106 forward would be to use ALTO for full integration. 108 Another key aspect of ALTO in the context of CDNs deployments is that 109 there is an expectation that no changes to the hosts are needed (or 110 would be transparent to the user). In other words, a traditional web 111 browser is all there is needed to take advantage of ALTO information. 112 This is significant difference from the P2P file sharing case where a 113 special client is needed and ALTO is normally used as a way to reduce 114 operational expense. 116 2. Scope 118 This document discusses how Content Delivery Networks can benefit 119 from ALTO through integration of the ALTO Service with the main 120 request routing techniques. Whenever a gap in protocol functionality 121 is identified to achieve such integration, it will be enumerated with 122 'GAP-'. Each gap is documented in a section of their own in order 123 to foster parallel discussion and possible adoption. 125 3. Terminology 127 Content-aware Proximity Redirector: The Redirector knows about 128 locations and presence of content & media objects in the network. 129 Therefore the redirection to a CDN node is made based on 130 availability of content or content-type in that CDN node and the 131 proximity of the CDN node to the user. 133 Service-aware Proximity Redirector: The Redirector knows about 134 locations of CDN nodes in the network and redirects user to the 135 closest CDN node. The redirection made irrespective of content 136 presence in the CDN Node; if content not present, the cache will 137 be populated with the content before or when the content is served 138 to the user. 140 HTTP Redirector: a Content-Aware or Service Aware Proximity 141 Redirector for HTTP. It embeds an HTTP Server that performs HTTP 142 Redirects, an ALTO client that retrieves network mapping from the 143 ALTO Server and a Location Database which stores network mappings 144 received from the ALTO Client. The HTTP Server consults the 145 Location Database when making redirection decisions. 147 4. HTTP Redirect 149 In this case an HTTP GET request from a host is received by an HTTP 150 Redirector which sends back an HTTP responses with Status-Code 302 151 (Redirect) informing the host of the best location to fetch the 152 content. The HTTP Redirection method is already commonly used in 153 production CDNs as described in RFC3568 [RFC3568]. ALTO integration 154 provides localization services where the device that performs the 155 redirection becomes an ALTO client. 157 The ALTO client embedded in the HTTP Redirector fetches the cost and 158 network map from the ALTO Server and provides that information to the 159 HTTP Server. When the HTTP Redirector intercepts an HTTP GET request 160 (1), it looks up the source IP address on the GET request, consults 161 the Location Database and returns an HTTP redirect with the URL of 162 the best CDN node from which to service the host. The URL in 302 163 Redirect may contain the IP address of the selected CDN node or a 164 domain name instead of IP address due to virtual hosting. Therefore 165 the IP addresses contained in the cost maps may need to be correlated 166 to domain names a priori. 168 +-----------------+ 169 | HTTP Redirector | 170 +------+ 1 | +-------------+ | 171 | |--------------> | | HTTP Server | | 172 | Host |<-------------- | +-------------+ | 173 +------+ 2 | ^ | 174 | | | 175 | +-------------+ | 176 | | Location DB | | 177 | +-------------+ | 178 | ^ | 179 | | | 180 | +-------------+ | 181 | | ALTO Client | | 182 | +-------------+ | 183 +-----------------+ 184 | ^ 185 | | ALTO Protocol 186 | | (Map Service) 187 v | 188 +-----------------+ 189 | ALTO Server | 190 +-----------------+ 192 Figure 1: HTTP Redirector 194 The Network Maps generated by the ALTO server contain Host PIDs and 195 CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain 196 IP addresses of available CDN nodes. Cost Maps contain only cost 197 from each host PID to each CDN PID and not the full matrix across all 198 PIDs. The reason is that the HTTP Redirector can only redirect a 199 host to a CDN node, not to another host as in the P2P case. 200 Moreover, there is no generic way to disambiguate PIDs containing 201 only hosts from PIDs containing CDN nodes (GAP). 203 The cost for CDN PID to CDN PID and from between host PIDs are 204 assumed to be infinity (GAP). The HTTP Redirector looks up the 205 source address on the HTTP GET request, and uses the cost map to 206 select the best CDN PID and a CDN node from it. The CDN node 207 selection method can be random, round-robin, or the HTTP Redirector 208 can use some level of content awareness (i.e. send requests for the 209 same content (URL) to the same CDN node. 211 GAP-1 (PID Attributes): In order to disambiguate between PIDs that 212 contain endpoints of a specific class, a PID property is needed. 213 A PID can be classified as containing "CDN nodes", "Mobile Hosts", 214 "Wireline Hosts", etc. 216 GAP-2 (PID Attributes and Query): PID attributes can be used by 217 the Client to select a appropriate host and also passed as a 218 constraint in the map filtering service. 220 GAP-3 (Default Cost): The issue of default cost if one of 221 importance. Without a default PID with endpoint '0.0.0.0/0', what 222 should be the cost between two PIDs? Moreover, if the default PID 223 mandatory in the protocol? 225 A future revision will incorporate analysis of ALTO Server - HTTP 226 Redirector interaction with Endpoint Cost Service 228 4.1. ALTO Server Discovery 230 4.2. CDN Node Discovery and Status 232 The method of discovering available caches and their locations is not 233 specified. We assume the CDN nodes are discovered in some way. It 234 is desirable that not only CDN node locations, but also real-time 235 status (like health, load, cache utilization, CPU, etc.) is 236 communicated either to the HTTP Redirector or to the ALTO Server. 238 CDN node status can be retrieved from the existing Load Balancer 239 infrastructure. Most Load Balancers today have mechanisms to poll 240 caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have 241 SNMP trap capabilities to let other devices know about these 242 thresholds. The HTTP Redirector or the ALTO Server can implement an 243 SNMP agent and get to know whatever is needed. For greenfield 244 installations, the ALTO Server could also provide an API (for 245 example, a Web Service or XMPP-based API) that could be used by CDN 246 nodes to communicate their status to the ALTO server directly. 248 4.3. CDN Node Status Updates received by HTTP Redirector 250 In this use case the HTTP Redirector receives CDN Status updates. 252 +-----------------+ 253 | HTTP Redirector | 254 +------+ 1 | +-------------+ | 255 | |--------------> | | HTTP Server | | 256 | Host |<-------------- | +-------------+ | 257 +------+ 2 | ^ | 258 | | | 259 | +-------------+ | 260 | | Location DB | |<--- Real-time CDN 261 | +-------------+ | status updates 262 | ^ | 263 | | | 264 | +-------------+ | 265 | | ALTO Client | | 266 | +-------------+ | 267 +-----------------+ 268 | ^ 269 | | ALTO Protocol 270 | | (Map Service) 271 v | 272 +-----------------+ 273 | ALTO Server | 274 +-----------------+ 276 Figure 2: RT CDN Updates to HTTP Redirector 278 4.4. CDN Node Status Updates received by ALTO Server 280 This model generally simplifies the HTTP Redirector. It allows an 281 easier distribution of the HTTP Redirector, and to keep real time CDN 282 status data updates in a logically centralized ALTO Server or in an 283 ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO 284 Server to be in different administrative domains. For example, the 285 HTTP Redirector can be in a Content Provider's domain, the ALTO 286 Server and CDN Nodes in a Network Service Provider's domain. 288 +-----------------+ 289 | HTTP Redirector | 290 +------+ 1 | +-------------+ | 291 | |--------------> | | HTTP Server | | 292 | Host |<-------------- | +-------------+ | 293 +------+ 2 | ^ | 294 | | | 295 | +-------------+ | 296 | | Location DB | | 297 | +-------------+ | 298 | ^ | 299 | | | 300 | +-------------+ | 301 | | ALTO Client | | 302 | +-------------+ | 303 +-----------------+ 304 | ^ 305 | | ALTO Protocol 306 | | (Map Service) 307 v | 308 +-----------------+ 309 | ALTO Server |<--- Real-time CDN 310 +-----------------+ status updates 312 Figure 3: RT CDN Updates to ALTO Server 314 In this model it is recommended that a given HTTP Redirector may be 315 designated as being responsible for a fixed set of Host PIDs. This 316 information can be made available to the HTTP Redirector before it 317 receives requests from clients. If the set of Host PIDs is not known 318 ahead of time, the latency for serving requests will be impacted by 319 the capabilities of the ALTO server. With such information ahead of 320 time, the HTTP Redirector may pre-download the network map for the 321 interesting Host PIDs and the CDN PIDs. It can also start 322 periodically pulling cost maps for relevant PID 2-tuples. 324 The HTTP Redirector can rely on the ALTO Server generated Cache- 325 Control headers to decide how often to fetch CDN PID network map and 326 Host PID network maps. In order to better deal with outages of 327 caches or changes to CDN PIDs, a push mechanism from ALTO server to 328 ALTO client would be needed (GAP-4). In the general P2P scenario 329 this may not make sense, but with content delivery this may be 330 important from a service continuity perspective. 332 If the maps are large and change often a natural extension to the 333 protocol is to allow incremental Map Updates (GAP-5). This 334 requirement becomes more emphasized when the ALTO Server is the 335 recipient of CDN nodes' status updates, because their load/status 336 changes are typically more frequent than topology changes in the 337 network. 339 GAP-4 (Push Mechanism): It is important for the ALTO Service 340 through the ALTO protocol or a companion protocol to provide a 341 push mechanism from server to client. The push mechanism can be a 342 notification that new data is vailable or the data itself. 344 GAP-5 (Incremental Map Updates): A natural evolution to the 345 protocol if maps are large and change often is to allow for 346 incremental map updates. In this sense the map contained in the 347 reply would be considered the delta from the previous version. 349 5. DNS Integration 351 In the case of DNS request routing, the DNS server handling client 352 requests is integrated with an ALTO client. When the host performs a 353 DNS query lookup, the IP address contained in the response are 354 already optimal for that query. As in the previous example, no 355 changes in the host are needed. 357 DNS queries can be either iterative or recursive. Iterative queries 358 can be used with ALTO if the client itself queries the DNS Servers, 359 or if the DNS Proxy used by the host is topologically close to the 360 host. If the Host queries the DNS Servers, the authoritative DNS 361 Server can see directly the host's IP address. If the the DNS 362 Proxy's is topologically close to the Host, its IP address is a good 363 approximation for the host's location. In recursive queries, the 364 authoritative DNS Server sees the IP address of the previous DNS 365 Server in the resolution chain, and the IP address of the host is 366 unknown. DNS-based request routing does not work with recursive DNS 367 queries. 369 In an iterative DNS lookup with DNS Proxy, as shown in examples in 370 the next section, the host queries the Proxy, which in turn first 371 queries one of the root servers to find the server authoritative for 372 the top-level domain (com in our example). The Proxy then queries 373 the obtained top-level-domain DNS server for the address of the DNS 374 server authoritative for the cdn domain. Finally, the Proxy queries 375 the DNS server that is authoritative for the cdn.com domain. The 376 authoritative DNS Server for the cdn.com will perform the request 377 routing to the most appropriate CDN node, based on the source IP 378 address of the requestor. The client will then request the content 379 directly from the CDN Node. 381 6. Administrative domains and ALTO 383 With DNS-based redirection, among others, there are two models that 384 are worth further study - one, where the CDN nodes are in the 385 administrative domain of the ISP and two, where CDN nodes are part of 386 a separate domain from that of the ISP. In the first use case, the 387 Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server 388 for the CDN domain are in the same administrative domain. In the 389 second use case, Hosts and CDN Nodes are in different administrative 390 domains. 392 6.1. CDN nodes in the ISP administrative domain 394 When the CDN nodes are within the ISP's administrative domain, the 395 DNS server with the ALTO client is under the ISP's management. As 396 described earlier, the best CDN node is picked by performing an ALTO 397 query on the source IP address of the DNS request. 399 2 +----------------+ 400 +------------------> | root | 401 | +----------------- | Name Server | +----------+ 402 | | 3 +----------------+ | Content | 403 | | | Provider | 404 | | 4 +----------------+ +----------+ 405 | | +------------> | com | 406 | | | +----------- | Name Server | 407 | | | | 5 +----------------+ 408 .......|.|...|.|............................................... 409 : | V | V : 410 : +---------+ +----------------+ : 411 : | DNS |---------> | cdn.com | : 412 : | Proxy |<--------- | Name Server | : 413 : +---------+ 7 | | : 414 : ^ | | +------------+ | : 415 : 1 | | 8 | |ALTO Client | | : 416 : | V | +------------+ | : 417 : +---------+ +----------------+ : 418 : | Host | | ^ : 419 : +---------+ | | ALTO Protocol : 420 : | | | (Map Service) : 421 : | V | : 422 : V +----------------+ : 423 : CDN Node | ALTO Server | : 424 : +----------------+ : 425 : : 426 : NSP/CDN Administrative Domain : 427 :.............................................................: 429 Figure 4: DNS Resolution with single admin domain 431 6.2. CDN nodes in a separate administrative domain from that of ISP 433 In many situations, the CDN nodes are in a separate network managed 434 by an entity that is distinct from the ISP. Consequently, the CDN 435 nodes belong to a network with its own ALTO server that is distinct 436 from the ALTO server of the ISP where the subscriber belongs. 438 ................................. 439 : +-----------------+ : 440 : | cdn.com | : 441 : | Name Server | : 442 +----------+ : | | : 443 | Content | : | +-------------+ | : 444 | Provider | : | | ALTO Client | | : 445 +----------+ : | +-------------+ | : 446 : +-----------------+ : 447 : ^ : 448 : | : 449 : +-----------------+ : 450 ................................. : | ALTO Server | : 451 : : : | | : 452 : +----------------+ : : | +-------------+ | : 453 : | ALTO Server |--------------------->| ALTO Client | | : 454 : +----------------+ : : | +-------------+ | : 455 : : : +-----------------+ : 456 : : : : 457 : +------+ C(1-4) +--------+ : : +--------+ C(6-8) +------+ : 458 : | Host |<--------->| Border |: c6 :| Border |<--------->| CDN | : 459 : | PID1 | +-->| Router |-------| Router |<--+ | PID8 | : 460 : +------+ |+->| PID4 | : :| PID6 |<-+| +------+ : 461 : || +--------+ : : +--------+ || : 462 : || : : || : 463 : +------+ C(2-4)|| : : ||C(6-9) +------+ : 464 : | Host |<------+| : : |+------>| CDN | : 465 : | PID2 | | : : | | PID9 | : 466 : +------+ | : : | +------+ : 467 : | : : | : 468 : | : : | : 469 : +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ : 470 : | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | : 471 : | PID3 | | Router |-------| Router | | PID10| : 472 : +------+ | PID5 | : : | PID7 | +------+ : 473 : +--------+ : : +--------+ : 474 : : : : 475 : ISP Administrative Domain : : CDN Administrative Domain : 476 :...............................: :...............................: 478 Figure 5: Map advertising between ISP and CDN domains 480 The ALTO server in the CDN provider network is assumed to be 481 initialized with information about the ISP networks it serves. For 482 every such ISP network, it consults the routing plane to find the set 483 of Border routers. The CDN network ALTO server computes the cost of 484 reaching each Border router from every CDN node (say, C_cdn). 486 Next, the CDN ALTO server contacts the ISP network's ALTO server and 487 downloads the network map. In order to help the CDN ALTO server 488 compute the cost from a CDN node to a subscriber's PID, we break it 489 down into two parts - the cost from the CDN node to the Border router 490 (C_cdn) and the cost from the Border router to the subscriber's PID 491 (say, C_isp). Note that, this implies that each Border router is a 492 PID in itself to accommodate this cost computation. Hence the cost 493 map at the ISP's ALTO server has the costs between every pair of 494 subscriber PID and Border router PID. 496 With the network map and the cost map from the ISP ALTO server, the 497 CDN ALTO server now computes the cost of reaching each subscriber PID 498 from a given CDN node as: C_cdn(CDN Node, Border router) + 499 C_isp(Border router, Subscriber PID). In this computation, the 500 Border router is the one that is on the best path from the CDN node 501 to the Subscriber PID. 503 The CDN ALTO server now has a cost map that provides the cost from 504 each CDN node to all known Subscriber PIDs. The ALTO client in the 505 CDN DNS server downloads this cost map in preparation for subscriber 506 DNS requests. 508 When a subscriber DNS request arrives at the CDN provider's DNS 509 server, it looks up the network map and maps the source IP address to 510 a Subscriber PID. It then uses the cost map to pick the best CDN 511 node for this Subscriber PID. 513 GAP-6: Federation of ALTO servers: There is a need to define how 514 ALTO servers may communicate with each other in a federated model. 516 GAP-7: ALTO Border Router PID attribute: In order for 517 administrative domains to collate costs across domain boundaries, 518 the border routers may be placed in their own PIDs. Such PIDs may 519 be identified by a Border Router attribute. 521 6.3. Integrating with managed DNS service 523 Many organizations / content providers outsource DNS management to 524 the external vendors for various reasons like reliability, 525 performance improvement, DNS security etc. Managed DNS service could 526 be used either with caches owned by the organization itself (section 527 6.3.1) OR with external CDNs (section 6.3.2) 529 6.3.1. Managed DNS resolver used to redirect to local cache 531 One of the common functions offered by managed DNS service vendor is 532 DNS traffic management where DNS resolver can load balance traffic 533 dynamically across content servers. 535 Typically managed DNS service provider has DNS resolvers spread 536 across geographical locations to improve performance. This also 537 makes easier for DNS resolver to redirect host to the nearest cache. 538 Such a DNS resolver would be an ideal candidate to implement ALTO 539 client where it can fetch network map and cost map from ALTO servers 540 located in the same geographical area only. Load balancing 541 implemented with the knowledge of network and cost map would be more 542 efficient than other mechanisms like round robin. 544 2 +----------------+ 545 +--------------------> | root | 546 | +------------------- | Name Server | 547 | | 3 +----------------+ 548 | | 549 | | 4 +----------------+ 550 | | +--------------> | com | 551 | | | +------------- | Name Server | 552 | | | | 5 +----------------+ 553 | | | | 554 _|-|---|-|--------------------. 555 ,-'' | V | V `--. 556 ' +---------+ 6 +---------------`+. 557 | | DNS |-------->| xyz.com | ` 558 | | Proxy |<--------| DNS Resolver | | 559 | +---------+ 7 | | | 560 | 1^ | 8 | +------------+ | | 561 | | | | |ALTO Client | | | 562 | +-----V---+ | +------------+ | | 563 | | Host | +----------------.-' 564 | +---------+ | ^ .-' 565 | | DOMAIN 1 | |-' ALTO Protocol 566 | V |.-'| (Map Service) 567 `--. CDN Node __.--:-| | 568 `----. _.--' | | 569 `---.-'' ,---------+-------. 570 ,'+----------------+ \ 571 / | ALTO Server | : 572 ( +----------------+ | 573 \ ; 574 \ DOMAIN 2 ,' 575 `-----------------' 577 In the figure above, there exists 2 possibilities: 579 Case 1: Domain 1 and Domain 2 are connected to the same service 580 provider network. This case is similar to section 6.1 582 Case 2: Domain 1 and Domain 2 are connected to different service 583 provider network. This case is similar to section 6.2 585 6.3.2. Managed DNS resolver used with multiple CDN vendors 587 In this Model, Managed DNS service can be used along with multiple 588 CDN vendors where DNS resolver can redirect to different caches 589 depending on the subdomain e.g. DNS resolver could have below 590 records 592 subdomain1.xyz.com CNAME cdn1.com 594 subdomain2.xyz.com CNAME cdn2.com 596 In this case CDN DNS resolver needs to be an ALTO client. This 597 deployment will be similar to ones described in section 6.1 and 598 section 6.2 earlier. 600 7. Tracker Integration 602 In the case of P2P CDNs, the application tracker takes the role of 603 the ALTO Client, fetching the map from the ALTO Server and 604 integrating it its peer database. The result is a peer database 605 taking into account current metrics such as peer availability, 606 content availability and also localization. This architecture in the 607 context of file sharing was extensively studied and trialed by ISPs 608 such as Comcast [RFC5632] under the P4P [P4P] protocol. 610 8. IANA Considerations 612 This document makes no request of IANA. 614 Note to RFC Editor: this section may be removed on publication as an 615 RFC. 617 9. Security Considerations 619 When the ALTO Server and Client are operated by different entities 620 the issue of trust and security comes forward. The exchange of 621 information could be done using the encryption methods already 622 present in HTTP but preventing unauthorized redistribution comes into 623 play. A further issue is if the ALTO information information is 624 transitive, which modifications are allowed. 626 10. Acknowledgements 628 TBD 630 11. References 632 11.1. Normative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 11.2. Informative References 639 [ARBOR] Labovitz, "Internet Traffic and Content Consolidation", 640 2009, . 643 [I-D.ietf-alto-protocol] 644 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 645 draft-ietf-alto-protocol-03 (work in progress), 646 March 2010. 648 [P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A. 649 Silberschatz, "P4P: Provider Portal for (P2P) 650 Applications", March 2009. 652 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 653 Content Network (CN) Request-Routing Mechanisms", 654 RFC 3568, July 2003. 656 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 657 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 658 Provider Participation for P2P (P4P) Technical Trial", 659 RFC 5632, September 2009. 661 Authors' Addresses 663 Reinaldo Penno 664 Juniper Networks 665 1194 N Mathilda Avenue 666 Sunnyvale 667 USA 669 Email: rpenno@juniper.net 670 Satish Raghunath 671 Juniper Networks 672 1194 N Mathilda Avenue 673 Sunnyvale 674 USA 676 Email: satishr@juniper.net 678 Jan Medved 679 Juniper Networks 680 1194 N Mathilda Avenue 681 Sunnyvale 682 USA 684 Email: jmedved@juniper.net 686 Mayuresh Bakshi 687 Juniper Networks 688 1194 N Mathilda Avenue 689 Sunnyvale 690 USA 692 Email: mbakshi@juniper.net 694 Richard Alimi 695 Yale University 697 Email: richard.alimi@yale.edu 699 Stefano Previdi 700 Cisco Systems 702 Email: sprevidi@cisco.com