idnits 2.17.1 draft-penno-alto-cdn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (July 12, 2010) is 5031 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-alto-protocol' is defined on line 736, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-03 Summary: 1 error (**), 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: January 13, 2011 M. Bakshi 6 Juniper Networks 7 R. Alimi 8 Yale University 9 S. Previdi 10 Cisco Systems 11 July 12, 2010 13 ALTO and Content Delivery Networks 14 draft-penno-alto-cdn-01 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 to IETF 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), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 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 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt. 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 This Internet-Draft will expire on January 13, 2011. 61 Copyright Notice 63 Copyright (c) 2010 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 4. Content Location Selection . . . . . . . . . . . . . . . . . . 5 82 4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 5 83 4.1.1. The Map Service . . . . . . . . . . . . . . . . . . . 6 84 4.1.2. The Endpoint Cost Service . . . . . . . . . . . . . . 7 85 4.1.3. CDN Node Discovery and Status . . . . . . . . . . . . 7 86 4.2. DNS Integration . . . . . . . . . . . . . . . . . . . . . 10 87 4.3. ALTO Server Discovery . . . . . . . . . . . . . . . . . . 11 88 5. Administrative domains and ALTO . . . . . . . . . . . . . . . 11 89 5.1. CDN nodes in the ISP administrative domain . . . . . . . . 11 90 5.2. CDN nodes in a separate administrative domain from 91 that of ISP . . . . . . . . . . . . . . . . . . . . . . . 12 92 5.3. Integrating with managed DNS service . . . . . . . . . . . 15 93 5.3.1. Managed DNS resolver used to redirect to local 94 cache . . . . . . . . . . . . . . . . . . . . . . . . 15 95 5.3.2. Managed DNS resolver used with multiple CDN vendors . 17 96 6. Tracker Integration . . . . . . . . . . . . . . . . . . . . . 17 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 105 1. Introduction 107 Content Delivery Networks are becoming increasingly important in the 108 Internet [ARBOR] and many CDNs today already use some form of 109 proximity through geolocation. But in many cases the content 110 provider/distributor and the Internet Service Provider are disjoint 111 and even if content servers are co-located into the ISP's networks, 112 there is no standardized way to share information. Therefore a 113 natural step forward would be to use ALTO to share information. 115 Another key aspect of ALTO in the context of CDNs deployments is that 116 it is desirable that no changes to the hosts are needed (or would be 117 transparent to the user). In other words, a traditional web browser 118 is all there is needed to take advantage of ALTO information. This 119 is a significant difference from the P2P applications where a special 120 client is typically needed and ALTO is normally used as a way to 121 reduce operational expense. 123 2. Scope 125 This document discusses how Content Delivery Networks can benefit 126 from ALTO through integration of the ALTO Service with the main 127 request routing techniques. Whenever a gap in protocol functionality 128 is identified to achieve such integration, it will be enumerated with 129 'GAP-'. Each gap is documented in a section of its own in order 130 to foster parallel discussions and possible adoption. 132 3. Terminology 134 Content-aware Proximity Redirector: The Redirector knows about 135 locations and presence of content & media objects in the network. 136 Therefore the redirection to a CDN node is made based on 137 availability of content or content-type in that CDN node and the 138 proximity of the CDN node to the user. 140 Service-aware Proximity Redirector: The Redirector knows about 141 locations of CDN nodes in the network and redirects user to the 142 closest CDN node. A redirection is made irrespective of content 143 presence in the CDN node; if content is not present, the node will 144 be populated with the content before or when the content is served 145 to the user. 147 HTTP Redirector: a Content-aware or Service-aware Proximity 148 Redirector for HTTP. It embeds an HTTP Server that performs HTTP 149 Redirects, an ALTO client that retrieves network mapping from the 150 ALTO Server and a Location Database which stores network mappings 151 received from the ALTO Client. The HTTP Server consults the 152 Location Database when making redirection decisions. 154 4. Content Location Selection 156 There are multiple mechanisms that ISPs and CDNs can use to select 157 the location from which content is served to a particular host, where 158 information from one or more ALTO Servers can be used to improve or 159 optimize the selection. In particular, two commonly used location 160 selection mechanisms are HTTP Redirect and DNS name resolution. 161 Thus, we focus on these two mechanisms. 163 4.1. HTTP Redirect 165 In this case an HTTP GET request from a host is received by an HTTP 166 Redirector which sends back an HTTP responses with Status-Code 302 167 (Redirect) informing the host of the most optimal location to fetch 168 the content. The HTTP Redirection method is already commonly used in 169 production CDNs as described in RFC3568 [RFC3568]. ALTO integration 170 provides localization services where the device that performs the 171 redirection becomes an ALTO client. 173 Usage of the ALTO Server with HTTP Redirects is shown in the 174 following figure. Either the Map Service or the Endpoint Cost 175 Service can be used by the ALTO client embedded in the HTTP 176 Redirector entity. 178 +-----------------+ 179 | HTTP Redirector | 180 +------+ 1 | +-------------+ | 181 | |--------------> | | HTTP Server | | 182 | Host |<-------------- | +-------------+ | 183 +------+ 2 | ^ | 184 | | | 185 | +-------------+ | 186 | | ALTO Client | | 187 | +-------------+ | 188 +-----------------+ 189 | ^ 190 | | ALTO Protocol 191 v | 192 +-----------------+ 193 | ALTO Server | 194 +-----------------+ 196 Figure 1: HTTP Redirector 198 4.1.1. The Map Service 200 The ALTO client embedded in the HTTP Redirector fetches the Network 201 and Cost Maps from the ALTO Server and provides that information to 202 the HTTP Redirector. As an illustrative example, a simple Redirector 203 may be given (from an external source) the list of available CDN 204 nodes. The Redirector precomputes a redirection table indexed by 205 source PID with values being the closest CDN nodes. This redirection 206 table can be built based on information from Network and Cost Maps. 207 Then when it receives an HTTP GET request (1), it looks up the PID of 208 the source IP address on the GET request, indexes the redirection 209 table using the request PID to select a CDN node, and finally returns 210 an HTTP redirect with the URL of the selected CDN node. In practice, 211 the redirection table may be indexed by both source and content to 212 provide better redirection. 214 The URL in 302 Redirect may contain the IP address of the selected 215 CDN node or a domain name instead of IP address due to virtual 216 hosting. Therefore the IP addresses contained in the cost maps may 217 need to be correlated to domain names a priori. 219 The Network Maps generated by the ALTO server contain Host PIDs and 220 CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain 221 IP addresses of available CDN nodes. Cost Maps contain only cost 222 from each host PID to each CDN PID and not the full matrix across all 223 PIDs. The reason is that the HTTP Redirector can only redirect a 224 host to a CDN node, not to another host as in the P2P case. 225 Moreover, there is no generic way to disambiguate PIDs containing 226 only hosts from PIDs containing CDN nodes (GAP). 228 The cost for CDN PID to CDN PID and between host PIDs are assumed to 229 be infinity (GAP). The HTTP Redirector looks up the source address 230 on the HTTP GET request, and uses the cost map to select the best CDN 231 PID and a CDN node from it. The CDN node selection method can be 232 random, round-robin, or the HTTP Redirector can use some level of 233 content awareness (i.e. send requests for the same content (URL) to 234 the same CDN node. 236 GAP-1 (PID Attributes): In order to disambiguate between PIDs that 237 contain endpoints of a specific class, a PID property is needed. 238 A PID can be classified as containing "CDN nodes", "Mobile Hosts", 239 "Wireline Hosts", etc. Note that the Alto Server will have to be 240 told which subnets belong to hosts and which subnets belong to CDN 241 Nodes. 243 GAP-2 (PID Attributes and Query): PID attributes can be used by 244 the ALTO Client to select an appropriate CDN Node and also passed 245 as a constraint in the map filtering service. 247 GAP-3 (Default Cost): The issue of default cost is one of 248 importance. Without a default PID with endpoint '0.0.0.0/0', what 249 should be the cost between two PIDs? Moreover, is the default PID 250 mandatory in the protocol? 252 4.1.2. The Endpoint Cost Service 254 Alternatively, ALTO client embedded in the HTTP Redirector, requests 255 the endpoint cost service from the ALTO client. 257 The Redirector knows the IP address of the user (content requester) 258 and the different content locations. It then requests the Endpoint 259 Cost Service in order to rank/rate the content locations (i.e., IP 260 addresses of CDN nodes) based on their distance/cost (by default the 261 Endpoint Cost Service operates based on Routing Distance) from/to the 262 user address. 264 Note that the mechanisms through which the CDN acquires the IP 265 addresses of the content locations (i.e.: how to locate the requested 266 content) are part of the CDN implementation and their description is 267 outside the scope of this document. 269 Once the Redirector obtained from the ALTO server the ranked list of 270 locations (for the specific user) it can incorporate this information 271 into its selection mechanisms in order to point the user to the most 272 appropriate location. 274 4.1.3. CDN Node Discovery and Status 276 The method of discovering available caches and their locations is 277 outside the scope of this document. We assume the CDN nodes are 278 discovered in some way. It is desirable that not only CDN node 279 locations, but also real-time status (like health, load, cache 280 utilization, CPU, etc.) is communicated either to the HTTP Redirector 281 or to the ALTO Server. 283 CDN node status can be retrieved from the existing Load Balancer 284 infrastructure. Most Load Balancers today have mechanisms to poll 285 caches/servers via ping, HTTP Get, traceroute, etc. Most LBs have 286 SNMP trap capabilities to let other devices know about these 287 thresholds. The HTTP Redirector or the ALTO Server can implement an 288 SNMP agent and get to know whatever is needed. For greenfield 289 installations, the ALTO Server could also provide an API (for 290 example, a Web Service or XMPP-based API) that could be used by CDN 291 nodes to communicate their status to the ALTO server directly. 293 In addition to the CDN node status, network status can also be 294 retrieved from TE/RP databases. 296 4.1.3.1. CDN Node Status Updates received by HTTP Redirector 298 In this use case the HTTP Redirector receives CDN Status updates. 300 +-----------------+ 301 | HTTP Redirector | 302 +------+ 1 | +-------------+ | 303 | |--------------> | | HTTP Server | | 304 | Host |<-------------- | +-------------+ | 305 +------+ 2 | ^ |<--- Real-time CDN 306 | | | status updates 307 | +-------------+ | 308 | | ALTO Client | | 309 | +-------------+ | 310 +-----------------+ 311 | ^ 312 | | ALTO Protocol 313 v | 314 +-----------------+ 315 | ALTO Server | 316 +-----------------+ 318 Figure 2: RT CDN Updates to HTTP Redirector 320 4.1.3.2. CDN Node Status Updates received by ALTO Server 322 This model generally simplifies the HTTP Redirector. It allows an 323 easier distribution of the HTTP Redirector, and to keep real time CDN 324 status data updates in a logically centralized ALTO Server or in an 325 ALTO Server Cluster. It allows for the HTTP Redirector and the ALTO 326 Server to be in different administrative domains. For example, the 327 HTTP Redirector can be in a Content Provider's domain, the ALTO 328 Server and CDN Nodes in a Network Service Provider's domain. 330 +-----------------+ 331 | HTTP Redirector | 332 +------+ 1 | +-------------+ | 333 | |--------------> | | HTTP Server | | 334 | Host |<-------------- | +-------------+ | 335 +------+ 2 | ^ | 336 | | | 337 | +-------------+ | 338 | | ALTO Client | | 339 | +-------------+ | 340 +-----------------+ 341 | ^ 342 | | ALTO Protocol 343 v | 344 +-----------------+ 345 | ALTO Server |<--- Real-time CDN 346 +-----------------+ status updates 348 Figure 3: RT CDN Updates to ALTO Server 350 In this model it is recommended that a given HTTP Redirector may be 351 designated as being responsible for a fixed set of Host PIDs. This 352 information can be made available to the HTTP Redirector before it 353 receives requests from hosts. If the set of Host PIDs is not known 354 ahead of time, the latency for serving requests will be impacted by 355 the capabilities of the ALTO server. 357 With such information ahead of time, an HTTP Redirector that uses the 358 Network Maps Service may pre-download the network map for the 359 interesting Host PIDs and the CDN PIDs. It can also start 360 periodically pulling cost maps for relevant PID 2-tuples. 362 An HTTP Redirector that uses the Endpoint Cost Service may query the 363 ALTO Server for rankings of CDN Node IP addresses for each 364 interesting Host and cache the results for later usage. 366 The HTTP Redirector can rely on the ALTO Server generated Cache- 367 Control headers to decide how often to fetch CDN PID network map and 368 Host PID network maps. In order to better deal with outages of 369 caches or changes to CDN PIDs, a push mechanism from ALTO server to 370 ALTO client would be needed (GAP-4). In the general P2P scenario 371 this may not make sense, but with content delivery this may be 372 important from a service continuity perspective. 374 If the maps are large and change often a natural extension to the 375 protocol is to allow incremental Map Updates (GAP-5). This 376 requirement becomes more emphasized when the ALTO Server is the 377 recipient of CDN nodes' status updates, because their load/status 378 changes are typically more frequent than topology changes in the 379 network. 381 GAP-4 (Push Mechanism): It is important for the ALTO Service 382 through the ALTO protocol or a companion protocol to provide a 383 push mechanism from server to client. The push mechanism can be a 384 notification that new data is available or the data itself. 386 GAP-5 (Incremental Map Updates): A natural evolution to the 387 protocol if maps are large and change often is to allow for 388 incremental map updates. In this sense the map contained in the 389 reply would be considered the delta from the previous version. 391 4.2. DNS Integration 393 In the case of DNS request routing, the DNS server handling host 394 requests is integrated with an ALTO client. When the host performs a 395 DNS query/lookup, the IP address contained in the response is already 396 optimal for that query. As in the previous example, no changes in 397 the host are needed. 399 DNS queries can be either iterative or recursive. Iterative queries 400 can be used with ALTO if the host itself queries the DNS Servers, or 401 if the DNS Proxy used by the host is topologically close to the host. 402 If the Host queries the DNS Servers, the authoritative DNS Server can 403 see directly the host's IP address. If the the DNS Proxy's is 404 topologically close to the Host, its IP address is a good 405 approximation for the host's location. In recursive queries, the 406 authoritative DNS Server sees the IP address of the previous DNS 407 Server in the resolution chain, and the IP address of the host is 408 unknown. DNS-based request routing does not work with recursive DNS 409 queries. 411 In an iterative DNS lookup with DNS Proxy, as shown in examples in 412 the next section, the host queries the Proxy, which in turn first 413 queries one of the root servers to find the server authoritative for 414 the top-level domain (com in our example). The Proxy then queries 415 the obtained top-level-domain DNS server for the address of the DNS 416 server authoritative for the CDN domain. Finally, the Proxy queries 417 the DNS server that is authoritative for the cdn.com domain. The 418 authoritative DNS Server for the cdn.com will perform the request 419 routing to the most appropriate CDN node, based on the source IP 420 address of the requestor. The host will then request the content 421 directly from the CDN Node. 423 4.3. ALTO Server Discovery 425 5. Administrative domains and ALTO 427 With DNS-based redirection, among others, there are two models that 428 are worth further study - one, where the CDN nodes are in the 429 administrative domain of the ISP and two, where CDN nodes are part of 430 a separate domain from that of the ISP. In the first use case, the 431 Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server 432 for the CDN domain are in the same administrative domain. In the 433 second use case, Hosts and CDN Nodes are in different administrative 434 domains. 436 5.1. CDN nodes in the ISP administrative domain 438 When the CDN nodes are within the ISP's administrative domain, the 439 DNS server with the ALTO client is under the ISP's management. A 440 best CDN nodes can be picked by performing ALTO query on the source 441 IP address (and the target domain name) of the DNS request. 443 2 +----------------+ 444 +------------------> | root | 445 | +----------------- | Name Server | +----------+ 446 | | 3 +----------------+ | Content | 447 | | | Provider | 448 | | 4 +----------------+ +----------+ 449 | | +------------> | com | 450 | | | +----------- | Name Server | 451 | | | | 5 +----------------+ 452 .......|.|...|.|............................................... 453 : | V | V : 454 : +---------+ +----------------+ : 455 : | DNS |---------> | cdn.com | : 456 : | Proxy |<--------- | Name Server | : 457 : +---------+ 7 | | : 458 : ^ | | +------------+ | : 459 : 1 | | 8 | |ALTO Client | | : 460 : | V | +------------+ | : 461 : +---------+ +----------------+ : 462 : | Host | | ^ : 463 : +---------+ | | ALTO Protocol : 464 : | | | : 465 : | V | : 466 : V +----------------+ : 467 : CDN Node | ALTO Server | : 468 : +----------------+ : 469 : : 470 : NSP/CDN Administrative Domain : 471 :.............................................................: 473 Figure 4: DNS Resolution with single admin domain 475 5.2. CDN nodes in a separate administrative domain from that of ISP 477 In many situations, the CDN nodes are in a separate network managed 478 by an entity that is distinct from the ISP. Consequently, the CDN 479 nodes belong to a network with its own ALTO server that is distinct 480 from the ALTO server of the ISP where the subscriber belongs. 482 ................................. 483 : +-----------------+ : 484 : | cdn.com | : 485 : | Name Server | : 486 +----------+ : | | : 487 | Content | : | +-------------+ | : 488 | Provider | : | | ALTO Client | | : 489 +----------+ : | +-------------+ | : 490 : +-----------------+ : 491 : ^ : 492 : | : 493 : +-----------------+ : 494 ................................. : | ALTO Server | : 495 : : : | | : 496 : +----------------+ : : | +-------------+ | : 497 : | ALTO Server |--------------------->| ALTO Client | | : 498 : +----------------+ : : | +-------------+ | : 499 : : : +-----------------+ : 500 : : : : 501 : +------+ C(1-4) +--------+ : : +--------+ C(6-8) +------+ : 502 : | Host |<--------->| Border |: c6 :| Border |<--------->| CDN | : 503 : | PID1 | +-->| Router |-------| Router |<--+ | PID8 | : 504 : +------+ |+->| PID4 | : :| PID6 |<-+| +------+ : 505 : || +--------+ : : +--------+ || : 506 : || : : || : 507 : +------+ C(2-4)|| : : ||C(6-9) +------+ : 508 : | Host |<------+| : : |+------>| CDN | : 509 : | PID2 | | : : | | PID9 | : 510 : +------+ | : : | +------+ : 511 : | : : | : 512 : | : : | : 513 : +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ : 514 : | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | : 515 : | PID3 | | Router |-------| Router | | PID10| : 516 : +------+ | PID5 | : : | PID7 | +------+ : 517 : +--------+ : : +--------+ : 518 : : : : 519 : ISP Administrative Domain : : CDN Administrative Domain : 520 :...............................: :...............................: 522 Figure 5: Map advertising between ISP and CDN domains 524 The ALTO server in the CDN provider network is assumed to be 525 initialized with information about the ISP networks it serves. For 526 every such ISP network, it consults the routing plane to find the set 527 of Border routers. The CDN network ALTO server computes the cost of 528 reaching each Border router from every CDN node (say, C_cdn). 530 Next, the CDN ALTO server contacts the ISP network's ALTO server and 531 downloads the network map. In order to help the CDN ALTO server 532 compute the cost from a CDN node to a subscriber's PID, we break it 533 down into two parts - the cost from the CDN node to the Border Router 534 (C_cdn) and the cost from the Border Router to the subscriber's PID 535 (say, C_isp). Note that for any chosen exit point, C_cdn may be 536 computed locally by the CDN ALTO Server. However, the fundamental 537 issue is that C_isp depends on the exit point (Border outer) chosen 538 by the CDN. There are multiple ways for the CDN ALTO Server to 539 compute C_isp given the Network Map and Cost Map from the ISP's ALTO 540 Server. 542 One possibility is for the ISP ALTO Server to define a special Border 543 Router PID (denoted by a PID attribute) which also indicates the 544 corresponding Border Router PID in the CDN. The attributes and 545 values may be agreed-upon by the ISP and CDN when the ALTO Services 546 are configured. For example, in the example shown in Figure 5, the 547 ISP ALTO Server indicates that its PID4 and PID5 are Border PIDs, 548 with corresponding PIDs in the CDN as PID6, and PID7, respectively. 549 Then, CDN ALTO Server can locally compute C_isp = cost(ISP Border 550 Router PID, Subscriber PID). 552 A second possibility for computing C_isp is to make use of Border 553 Router IP addresses. The CDN's Border Router can locally determine 554 the IP address of the connected border router in the ISP. In this 555 approach, neither the CDN ALTO Server nor the ISP ALTO Server define 556 PID attributes. The ISP ALTO Server is not required to define 557 special PIDs for Border Routers - it only needs to ensure that Border 558 Router IP addresses are aggregated appropriately in its Network Map. 560 Specifically, we identify two scenarios for the CDN ALTO Server to 561 compute C_isp and C_cdn. 563 In the first scenario, the CDN does not conduct CDN-level multi-path 564 routing from the CDN nodes to the subscriber hosts. Thus, the 565 routing path from a CDN IP address to a subscriber host IP address is 566 typically uniquely (if no ECMP) determined by the network routing 567 system. In this scenario, for a given CDN node IP address to a 568 subscriber host IP address, the CDN ALTO Server uses the routing 569 system to compute the Border Egress router inside the CDN, and the 570 corresponding Border Ingress router inside the ISP. Then the CDN 571 ALTO Server has C_cdn(CDN node IP, Border Egress router IP inside the 572 CDN), and C_isp(Border Ingress router IP inside the ISP, Subscriber 573 IP). The computation of C_cdn and C_isp can be done using ALTO in 574 the traditional way through either the Network Map and Cost Map or 575 the Endpoint Cost Service. 577 In the second scenario, the CDN may support CDN-level multi-path 578 routing from the CDN nodes to the subscriber hosts. In particular, 579 from each CDN node, the CDN has a capability (e.g., through 580 tunneling) to send to a subscriber host IP through multiple Border 581 Egress routers (e.g., through any Egress router that receives an 582 announcement from the ISP of the subscriber host IP). In this case, 583 the cost of reaching a host PID from a given CDN node is then 584 determined as the minimum cost among all possible intermediate Border 585 Routers. 587 If the network is homogeneous, then a good approximation of the cost 588 between each host PID and a given CDN node can be given as: C_cdn(CDN 589 Node, Border router) + C_isp(Border router, Subscriber PID). In this 590 computation, the Border Router is the one that is on the best path 591 from the CDN node to the Subscriber PID. 593 The CDN ALTO server now has a cost map that provides the cost from 594 each CDN node to all known Subscriber PIDs. The ALTO client in the 595 CDN DNS server downloads this cost map in preparation for subscriber 596 DNS requests. 598 When a subscriber DNS request arrives at the CDN provider's DNS 599 server, it looks up the network map and maps the source IP address to 600 a Subscriber PID. It then uses the cost map to pick the best CDN 601 node for this Subscriber PID. 603 GAP-6: Federation of ALTO servers: There is a need to define how 604 ALTO servers may communicate with each other in a federated model. 606 GAP-7: ALTO Border Router PID attribute: In order for 607 administrative domains to collate costs across domain boundaries, 608 the border routers may be placed in their own PIDs. Such PIDs may 609 be identified by a Border Router attribute. 611 5.3. Integrating with managed DNS service 613 Many organizations / content providers outsource DNS management to 614 the external vendors for various reasons like reliability, 615 performance improvement, DNS security etc. Managed DNS service could 616 be used either with caches owned by the organization itself (section 617 6.3.1) OR with external CDNs (section 6.3.2) 619 5.3.1. Managed DNS resolver used to redirect to local cache 621 One of the common functions offered by managed DNS service vendor is 622 DNS traffic management where DNS resolver can load balance traffic 623 dynamically across content servers. 625 Typically managed DNS service provider has DNS resolvers spread 626 across geographical locations to improve performance. This also 627 makes easier for DNS resolver to redirect host to the nearest cache. 628 Such a DNS resolver would be an ideal candidate to implement ALTO 629 client where it can fetch network map and cost map from ALTO servers 630 located in the same geographical area only. Load balancing 631 implemented with the knowledge of network and cost map would be more 632 efficient than other mechanisms like round robin. 634 2 +----------------+ 635 +--------------------> | root | 636 | +------------------- | Name Server | 637 | | 3 +----------------+ 638 | | 639 | | 4 +----------------+ 640 | | +--------------> | com | 641 | | | +------------- | Name Server | 642 | | | | 5 +----------------+ 643 | | | | 644 _|-|---|-|--------------------. 645 ,-'' | V | V `--. 646 ' +---------+ 6 +---------------`+. 647 | | DNS |-------->| xyz.com | ` 648 | | Proxy |<--------| DNS Resolver | | 649 | +---------+ 7 | | | 650 | 1^ | 8 | +------------+ | | 651 | | | | |ALTO Client | | | 652 | +-----V---+ | +------------+ | | 653 | | Host | +----------------.-' 654 | +---------+ | ^ .-' 655 | | DOMAIN 1 | |-' ALTO Protocol 656 | V |.-'| (Map Service) 657 `--. CDN Node __.--:-| | 658 `----. _.--' | | 659 `---.-'' ,---------+-------. 660 ,'+----------------+ \ 661 / | ALTO Server | : 662 ( +----------------+ | 663 \ ; 664 \ DOMAIN 2 ,' 665 `-----------------' 667 In the figure above, there exists 2 possibilities: 669 Case 1: Domain 1 and Domain 2 are connected to the same service 670 provider network. This case is similar to section 6.1 672 Case 2: Domain 1 and Domain 2 are connected to different service 673 provider network. This case is similar to section 6.2 675 5.3.2. Managed DNS resolver used with multiple CDN vendors 677 In this Model, Managed DNS service can be used along with multiple 678 CDN vendors where DNS resolver can redirect to different caches 679 depending on the subdomain e.g. DNS resolver could have below 680 records 682 subdomain1.xyz.com CNAME cdn1.com 684 subdomain2.xyz.com CNAME cdn2.com 686 In this case CDN DNS resolver needs to be an ALTO client. This 687 deployment will be similar to ones described in section 6.1 and 688 section 6.2 earlier. 690 6. Tracker Integration 692 In the case of P2P CDNs, the application tracker takes the role of 693 the ALTO Client, fetching the map from the ALTO Server and 694 integrating it its peer database. The result is a peer database 695 taking into account current metrics such as peer availability, 696 content availability and also localization. This architecture in the 697 context of file sharing was extensively studied and trialed by ISPs 698 such as Comcast [RFC5632] under the P4P [P4P] protocol. 700 7. IANA Considerations 702 This document makes no request of IANA. 704 Note to RFC Editor: this section may be removed on publication as an 705 RFC. 707 8. Security Considerations 709 When the ALTO Server and Client are operated by different entities 710 the issue of trust and security comes forward. The exchange of 711 information could be done using the encryption methods already 712 present in HTTP but preventing unauthorized redistribution comes into 713 play. A further issue is if the ALTO information information is 714 transitive, which modifications are allowed. 716 9. Acknowledgements 718 We would like to thank Richard Yang for valuable input and 719 contributions to this draft. We would also like to thank Nabil 720 Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong and Ferry 721 Sutanto for their comments. 723 10. References 725 10.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 10.2. Informative References 732 [ARBOR] Labovitz, "Internet Traffic and Content Consolidation", 733 2009, . 736 [I-D.ietf-alto-protocol] 737 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 738 draft-ietf-alto-protocol-03 (work in progress), 739 March 2010. 741 [P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A. 742 Silberschatz, "P4P: Provider Portal for (P2P) 743 Applications", March 2009. 745 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 746 Content Network (CN) Request-Routing Mechanisms", 747 RFC 3568, July 2003. 749 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 750 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 751 Provider Participation for P2P (P4P) Technical Trial", 752 RFC 5632, September 2009. 754 Authors' Addresses 756 Reinaldo Penno 757 Juniper Networks 759 Email: rpenno@juniper.net 760 Satish Raghunath 761 Juniper Networks 763 Email: satishr@juniper.net 765 Jan Medved 766 Juniper Networks 768 Email: jmedved@juniper.net 770 Mayuresh Bakshi 771 Juniper Networks 773 Email: mbakshi@juniper.net 775 Richard Alimi 776 Yale University 778 Email: richard.alimi@yale.edu 780 Stefano Previdi 781 Cisco Systems 783 Email: sprevidi@cisco.com