idnits 2.17.1 draft-penno-alto-cdn-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 109 has weird spacing: '... domain from ...' == Line 735 has weird spacing: '... domain from...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 14, 2011) is 4785 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-06 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-03 == Outdated reference: A later version (-04) exists of draft-lee-alto-chinatelecom-trial-00 == Outdated reference: A later version (-02) exists of draft-vandergaast-edns-client-subnet-00 Summary: 1 error (**), 0 flaws (~~), 8 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 J. Medved 4 Intended status: Experimental Juniper Networks 5 Expires: September 15, 2011 R. Alimi 6 Google 7 R. Yang 8 Yale University 9 S. Previdi 10 Cisco Systems 11 March 14, 2011 13 ALTO and Content Delivery Networks 14 draft-penno-alto-cdn-03 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, information about what a Provider prefers in terms of 22 traffic optimization -- and a way to distribute it. The ALTO Service 23 provides information such as preferences of network resources with 24 the goal of modifying network resource consumption patterns while 25 maintaining or improving application performance. 27 One of the main use cases of the ALTO Service is its integration with 28 Content Delivery Networks (CDN). The purpose of this draft is 29 twofold: first, to describe how ALTO can be used in existing and new 30 CDNs, both within an ISP and in separate organizational entities from 31 the ISP; second, to collect requirements for ALTO usage in CDNs and 32 to provide recommendations into the development of the ALTO protocol 33 for better support of CDNs. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 This Internet-Draft will expire on September 15, 2011. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 4. Request Routing as an Integration Point of ALTO into CDN . . . 6 85 4.1. HTTP Redirect . . . . . . . . . . . . . . . . . . . . . . 7 86 4.2. DNS Request Routing . . . . . . . . . . . . . . . . . . . 7 87 5. Basic Scheme of CDN/ALTO Integration . . . . . . . . . . . . . 8 88 5.1. Basic Integration Scheme . . . . . . . . . . . . . . . . . 8 89 5.1.1. ALTO for HTTP Redirect . . . . . . . . . . . . . . . . 9 90 5.1.2. ALTO for DNS Resolution . . . . . . . . . . . . . . . 10 91 5.2. Multi-hop Redirection . . . . . . . . . . . . . . . . . . 10 92 6. Request Routing using ALTO Services . . . . . . . . . . . . . 11 93 6.1. ALTO Topology vs. Network Topology . . . . . . . . . . . . 11 94 6.2. CDN Node Discovery and Status Notification . . . . . . . . 11 95 6.2.1. CDN Node Status Updates received by Request 96 Routing Function . . . . . . . . . . . . . . . . . . . 12 97 6.2.2. CDN Node Status Updates received by ALTO . . . . . . . 12 98 6.3. Request Routing using the Map Service . . . . . . . . . . 13 99 6.4. Request Routing using the Endpoint Cost Service . . . . . 14 100 6.4.1. Topology Computation and ECS Delivery . . . . . . . . 15 101 6.4.2. Ranking Service . . . . . . . . . . . . . . . . . . . 15 102 6.5. Update, Redirection of ALTO Info to CDN Request Routing . 16 103 6.5.1. ALTO Update and Network Events . . . . . . . . . . . . 16 104 6.5.2. Caching and Lifetime . . . . . . . . . . . . . . . . . 16 105 6.5.3. ALTO Redirection . . . . . . . . . . . . . . . . . . . 16 106 6.5.4. Groups and Costs . . . . . . . . . . . . . . . . . . . 17 107 7. Multiple Administrative Domains . . . . . . . . . . . . . . . 17 108 7.1. CDN nodes/Request Router in a separate administrative 109 domain from that of ISP . . . . . . . . . . . . . . . . . 18 110 7.2. Managed DNS Domain with Three Administrative Domains . . . 21 111 7.2.1. Managed DNS Redirect to Local CDN . . . . . . . . . . 21 112 7.2.2. Managed DNS with CDN-Provided Request Routing . . . . 22 113 8. Protocol Recommendations . . . . . . . . . . . . . . . . . . . 23 114 8.1. Necessary Additions . . . . . . . . . . . . . . . . . . . 23 115 8.1.1. NA1: PID Attributes . . . . . . . . . . . . . . . . . 23 116 8.1.2. NA2: PID Attributes and Query . . . . . . . . . . . . 24 117 8.2. Helpful Additions . . . . . . . . . . . . . . . . . . . . 24 118 8.2.1. HA1: Push Mechanism . . . . . . . . . . . . . . . . . 24 119 8.2.2. HA2: Incremental Map Updates . . . . . . . . . . . . . 24 120 8.2.3. HA3: ALTO Border Router PID attribute . . . . . . . . 24 121 8.2.4. HA4: CDN ALTO Server Discovery . . . . . . . . . . . . 24 122 8.2.5. HA5: Extensible ALTO Cost Maps . . . . . . . . . . . . 25 123 8.2.6. NA4: Federated Deployment of ALTO Servers . . . . . . 25 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 125 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 128 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 129 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 132 1. Introduction 134 Content Delivery Networks are becoming increasingly important in the 135 Internet [ARBOR] and many CDNs today already use some form of 136 proximity such as latency-based proximity [GoogleCDN]. But in many 137 cases the content provider/distributor and the Internet Service 138 Provider (ISP) are disjoint entities. Consequently, even if content 139 servers are co-located into the ISP's networks, there is not a 140 standardized way to share server location and/or network topology 141 information. Therefore a natural step forward would be to use ALTO 142 to share this information. 144 Another key aspect of ALTO in the context of CDNs deployments is that 145 it is desirable that no changes to the hosts are needed (or that 146 changes to hosts would be transparent to the user). In other words, 147 a traditional web browser using standard HTTP flow is all there is 148 needed to take advantage of ALTO information. This is a significant 149 difference from the P2P applications where a special client is 150 typically needed and ALTO is normally used as a way to reduce 151 operational expense. 153 2. Scope 155 This document discusses how Content Delivery Networks can benefit 156 from ALTO through integration of the ALTO Service with the main 157 request routing techniques. There are two objectives: 159 o Present basic integration schemes of ALTO into CDNs. 161 o Provide protocol recommendations to ALTO: Whenever a new 162 requirement on protocol functionality is identified to achieve 163 integration with CDNs, it will be enumerated with 'REQ-'. Each 164 requirement is documented in a section of its own in order to 165 foster parallel discussions and possible adoption. 167 3. Terminology 169 We use the following terms defined in ALTO Problem Statement 170 [RFC5693]: Application, ALTO Service, ALTO Server, ALTO Client, ALTO 171 Query, ALTO Reply, ALTO Transaction. 173 In addition to the above, the following terms are defined: 175 Content-aware Proximity Request Routing Function: The Request 176 Routing function knows about locations and presence of content & 177 media objects in the network. Therefore the redirection to a CDN 178 node is made based on both the availability of content and/or 179 content-type in that CDN node and the proximity of the CDN node to 180 the requesting user. 182 Service-aware Proximity Request Routing Function: The Request 183 Routing function knows about locations of CDN nodes in the network 184 and redirects user to the closest CDN node. A redirection is made 185 irrespective of content presence in the CDN node; if content is 186 not present, the node will be populated with the content while the 187 content is being served to the user. 189 HTTP Request Routing Function: a Content-aware or Service-aware 190 Proximity Request Routing function for HTTP. It embeds an HTTP 191 Server that performs HTTP Redirects, an ALTO client that retrieves 192 network mapping from the ALTO Server, and a Location Database 193 which stores network mappings received from the ALTO Client. The 194 HTTP Server consults the Location Database when making redirection 195 decisions. 197 4. Request Routing as an Integration Point of ALTO into CDN 199 Content Distribution is a rich and evolving field. New architectures 200 and approaches (e.g., a hybrid architecture using both servers and 201 P2P) continue to be developed in the research community and industry. 202 Several CDN architectures are being deployed in production. While we 203 would like to provide a survey of each possible CDN architecture and 204 show how it may be integrated with ALTO, it would be a daunting task 205 to track such a rapidly-changing field. 207 One scheme that is out of the scope of this document is P2P-only 208 CDNs, where the application tracker takes the role of the ALTO 209 Client, fetching the Network and Cost Maps from the ALTO Server and 210 integrating them with its peer database. The result is a peer 211 database that takes into account both the current peer metrics, such 212 as peer availability or content availability, and network metrics, 213 such as topological localization. This architecture, in the context 214 of file sharing, has been studied extensively and trialed by ISPs 215 such as Comcast [RFC5632] and China Telecom 216 [I-D.lee-alto-chinatelecom-trial] under the ALTO/P4P [P4P] protocol. 217 Thus, P2P-only CDNs are not discussed in this document. 219 The Request Routing Component of a CDN directs a request to a serving 220 CDN node, and thus is the major integration point to utilize 221 information available through ALTO. Today, multiple request routing 222 schemes have been used even in CDNs with purely server-based 223 infrastructure. The specific schemes include HTTP Redirect, DNS name 224 resolution, and anycast. We focus on HTTP Redirect and DNS name 225 resolution. 227 Though anycast is a request routing technique that has been used in 228 deployed CDNs, we do not discuss it in this document. Even though 229 one may be able to integrate ALTO with anycast, we do not believe 230 that this is a proper use of ALTO's capabilities. In particular, 231 ALTO has been developed to improve selection amongst multiple content 232 providers at the application level. In contrast, anycast operates by 233 adjusting the routing layer to match content consumers with the 234 desired content providers. Applying ALTO to routing layer decisions 235 introduces additional complexity because it directly adjusts the 236 routing layer from which the ALTO information is typically generated, 237 creating a tight feedback loop. We leave a more detailed study of 238 integrating ALTO with anycast-based CDNs as future work. 240 We next briefly review the two mechanisms presented in this document, 241 HTTP Redirect and DNS Request Routing. 243 4.1. HTTP Redirect 245 In this mechanism, an HTTP GET request from a host is received by an 246 HTTP Request Routing Function which sends back an HTTP response with 247 Status-Code 302 (Redirect) informing the host of the most preferred 248 location to fetch the content. The HTTP Redirection method is 249 already commonly used in production CDNs as described in RFC3568 250 [RFC3568]. ALTO integration provides localization services where the 251 device that performs the redirection becomes an ALTO client. 253 4.2. DNS Request Routing 255 In this mechanism, the DNS server handling host requests provides the 256 Request Routing Component. When the host performs a DNS query/ 257 lookup, the IP address(es) in the DNS response will indicate the 258 selected location to serve the request. 260 DNS queries can be either iterative or recursive. Iterative queries 261 can be used with ALTO if the host itself queries the DNS Servers, or 262 if the DNS Proxy used by the host is topologically close to the host. 263 If the Host directly queries the DNS Servers, the authoritative DNS 264 Server can see directly the host's IP address. If the DNS Proxy is 265 topologically close to the Host, its IP address is a good 266 approximation for the host's location. In recursive queries, the 267 authoritative DNS Server sees the IP address of the previous DNS 268 Server in the resolution chain, and the IP address of the host is 269 unknown. DNS-based request routing does not work well with recursive 270 DNS queries. 272 In an iterative DNS lookup with a DNS Proxy (say for cdn.com), the 273 host queries the Proxy, which in turn first queries one of the root 274 servers to find the server authoritative for the top-level domain 275 (com in our example). The Proxy then queries the obtained top-level- 276 domain DNS server for the address of the DNS server authoritative for 277 the CDN domain. Finally, the Proxy queries the DNS server that is 278 authoritative for the cdn.com domain. The authoritative DNS Server 279 for cdn.com will perform the request routing to the most appropriate 280 CDN node, based on the source IP address of the requestor. The host 281 will then request the content directly from the CDN Node. 283 Recently, an EDNS0 option in DNS query has been proposed in 284 [I-D.vandergaast-edns-client-subnet] that will provide a mechanism to 285 carry sufficient network information about the client for the 286 authoritative DNS server to tailor DNS response based on the client's 287 subnet. Using this mechanism, the authoritative DNS server can 288 achieve the same request routing accuracy as that of the HTTP Request 289 Routing Function, and both recursive and iterative queuries can be 290 supported. 292 5. Basic Scheme of CDN/ALTO Integration 294 Although HTTP Redirect and DNS are quite different mechanisms to 295 direct a request to a serving CDN node, as we will see, the basic 296 structure of integrating ALTO with them can be quite similar. Thus, 297 we first present common structures. We refer to the HTTP Redirect 298 component or the DNS component of a CDN as a CDN Request Routing 299 Function. 301 5.1. Basic Integration Scheme 303 Figure 1 shows a general structure to embed an ALTO Client into a CDN 304 Request Routing Function. 306 +-----------------+ 307 | Request Routing | 308 +-----------+ 1 | Function | 309 | |---------> | | 310 | Requestor |<-------- | | 311 +-----------+ 2 | | 312 | +-------------+ | 313 | | ALTO Client | | 314 | +-------------+ | 315 +-----------------+ 316 | ^ 317 | | ALTO Protocol 318 v | 319 +-----------------+ 320 | ALTO Server | 321 +-----------------+ 323 Figure 1: Request Routing Function with ALTO 325 An ALTO Server may aggregate information from multiple sources, such 326 as routing protocols, traffic engineering policies, and monitoring 327 systems. Thus, ALTO is complementary to existing infrastructure. 328 For further detail, see Figure 1 of [I-D.ietf-alto-protocol]. 330 5.1.1. ALTO for HTTP Redirect 332 To make the basic scheme more concrete, Figure 2 shows the case that 333 the Request Routing Function is HTTP Redirect. 335 +---------------------+ 336 | HTTP Request | 337 | Routing Function | 338 +------+ 1 | +-------------+ | 339 | |--------------> | | HTTP Server | | 340 | Host |<-------------- | +-------------+ | 341 +------+ 2 | ^ | 342 | | | 343 | +-------------+ | 344 | | ALTO Client | | 345 | +-------------+ | 346 +---------------------+ 347 | ^ 348 | | ALTO Protocol 349 v | 350 +---------------------+ 351 | ALTO Server | 352 +---------------------+ 354 Figure 2: ALTO for HTTP Request Routing Function 356 5.1.2. ALTO for DNS Resolution 358 Figure 3 shows the case that the Request Routing Function uses DNS 359 Resolution. 361 2 +----------------+ 362 +------------------> | root | 363 | +----------------- | Name Server | +----------+ 364 | | 3 +----------------+ | Content | 365 | | | Provider | 366 | | 4 +----------------+ +----------+ 367 | | +------------> | com | 368 | | | +----------- | Name Server | 369 | | | | 5 +----------------+ 370 | | | | 371 | V | V 372 +---------+ 6 +----------------+ 373 | DNS |---------> | cdn.com | 374 | Proxy |<--------- | Name Server | 375 +---------+ 7 | | 376 ^ | | +------------+ | 377 1 | | 8 | |ALTO Client | | 378 | V | +------------+ | 379 +---------+ +----------------+ 380 | Host | | ^ 381 +---------+ | | ALTO Protocol 382 | | | 383 | V | 384 V +----------------+ 385 CDN Node | ALTO Server | 386 +----------------+ 388 Figure 3: ALTO for DNS Resolution. 390 5.2. Multi-hop Redirection 392 The preceding examples show the logical flow for redirection. It is 393 important to state that there maybe multiple redirection hops. 395 For HTTP Redirect, the requestor may be redirected again by the first 396 CDN node. For DNS, the first DNS server may direct, using aggregated 397 ALTO information (e.g., from multiple ALTO Servers of multiple ISPs), 398 the DNS resolution to a second level DNS server, which then may use 399 more specific ALTO information as well as CDN node status. 401 6. Request Routing using ALTO Services 403 Either the Map Service or the Endpoint Cost Service of ALTO can be 404 used by the Request Routing Function. We first discuss two common 405 issues: how to configure ALTO topology at ALTO servers; and how to 406 achieve CDN node discovery and status notification. Then we give 407 specific details on using the Map Service or the Endpoint Cost 408 Service. 410 6.1. ALTO Topology vs. Network Topology 412 To answer queries from CDN Request Routing Functions, the ALTO server 413 builds a ALTO-specific network topology that represents the network 414 as it should be understood and utilized by the application layer (the 415 CDN). Besides the security requirements that consist of not 416 delivering any confidential or critical information about the 417 infrastructure, there are efficiency requirements in terms of what 418 visibility of the network, and at which level of granularity, is 419 required by the CDN and more in general by the application layer. 421 The ALTO server builds topology (for either Map and ECS services) 422 based on multiple sources that may include routing protocols, network 423 policies, state and performance information, geo-location, etc. In 424 all cases, the ALTO topology will not contain any details that would 425 endanger the network integrity and security (for example, there will 426 be no leaking of OSPF/ISIS/BGP databases to ALTO clients). 428 6.2. CDN Node Discovery and Status Notification 430 A design issue of integrating ALTO into Request Routing is how CDN 431 Request Routing discovers the available CDN nodes and their 432 locations. The exact mechanism is outside the scope of this 433 document. 435 It is desirable that not only CDN node locations, but also real-time 436 CDN node status (like health, load, cache utilization, CPU, etc.) is 437 communicated to the Request Routing Function. 439 Specifically, CDN node status can be retrieved from the existing Load 440 Balancer infrastructure. Most Load Balancers today have mechanisms 441 to poll caches/servers via ping, HTTP Get, traceroute, etc. Most LBs 442 have SNMP trap capabilities to let other devices know about these 443 thresholds. Specification of a particular mechanism or API used to 444 fetch load status information into an ALTO Server is out of scope of 445 this document. 447 Note that in addition to the CDN node status, network status can also 448 be retrieved from TE/RP databases. The Request Routing Function may 449 also need to be configured with a proper set of policies and business 450 rules that control routing of requests. For example, it may be 451 desirable to set up a rule that within a CDN certain requests have 452 higher priority. 454 We see two approaches that CDN node status can be communicated to the 455 Request Routing Function. 457 6.2.1. CDN Node Status Updates received by Request Routing Function 459 In the first approach, the Request Routing Function receives CDN 460 Status updates directly. 462 For example, the Request Routing Function can implement an SNMP agent 463 and get to know whatever is needed. 465 +-----------------+ 466 | Request Routing | 467 | Function | 468 +-----------+ 1 | | 469 | |---------> | |<--- Real-time CDN 470 | Requestor |<-------- | | status updates 471 +-----------+ 2 | | 472 | +-------------+ |<--- Business rules 473 | | ALTO Client | | and Policies 474 | +-------------+ | 475 +-----------------+ 476 | ^ 477 | | ALTO Protocol 478 v | 479 +-----------------+ 480 | ALTO Server | 481 +-----------------+ 483 Figure 4: CDN Node Status to Request Routing Function 485 6.2.2. CDN Node Status Updates received by ALTO 487 In the second approach, the Request Routing Function receives CDN 488 Status from ALTO instead of CDN nodes. 490 This model generally simplifies the Request Routing Function. It 491 allows an easier distribution of the Request Routing Function, and to 492 keep real time CDN status data updates in a logically centralized 493 ALTO Server or in an ALTO Server Cluster. It allows for the Request 494 Routing Function and the ALTO Server to be in different 495 administrative domains. For example, the Request Routing Function 496 can be in a Content Provider's domain; the ALTO Server and CDN Nodes 497 in a Network Service Provider's domain. 499 Specifically, ALTO Server could provide an API (for example, a Web 500 Service or XMPP-based API) that could be used by CDN nodes to 501 communicate their status to the ALTO server directly. 503 +-----------------+ 504 | Request Routing | 505 | Function | 506 +-----------+ 1 | | 507 | |---------> | | 508 | Requestor |<-------- | | 509 +-----------+ 2 | | 510 | +-------------+ | 511 | | ALTO Client | | 512 | +-------------+ | 513 +-----------------+ 514 | ^ 515 | | ALTO Protocol 516 v | 517 +-----------------+ 518 | |<--- Real-time CDN 519 | ALTO Server | status updates 520 | | 521 | |<--- Business rules 522 +-----------------+ and policies 524 Figure 5: CDN Node Status to ALTO 526 6.3. Request Routing using the Map Service 528 The ALTO client embedded in the Request Routing Function fetches the 529 Network and Cost Maps from the ALTO Server and provides that 530 information to the Request Router. 532 As an illustrative example, we consider the case of HTTP Redirect. A 533 simple Request Router may be given (from an external source) the list 534 of available CDN nodes. The Request Router precomputes a redirection 535 table indexed by source PID with values being the closest CDN nodes. 536 This redirection table can be built based on information from Network 537 and Cost Maps. Then when the Request Router receives an HTTP GET 538 request, it looks up the PID of the source IP address on the request, 539 indexes the redirection table using the request PID to select a CDN 540 node, and finally returns a response that is an HTTP redirect with 541 the URL of the selected CDN node. The URL in 302 Redirect may 542 contain the IP address of the selected CDN node or a domain name 543 instead of IP address due to virtual hosting. Therefore the IP 544 addresses contained in the cost maps may need to be correlated to 545 domain names a priori. In practice, the redirection table may be 546 indexed by both source and content to provide better redirection. 548 The illustrative example can also be extended to DNS. 550 The Network Maps generated by the ALTO Server will contain both Host 551 PIDs and CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN 552 PIDs contain IP addresses of available CDN nodes. Cost Maps may 553 contain only cost from each host PID to each CDN PID and not the full 554 matrix across all PIDs. The reason is that the Request Router may 555 redirect a host only to a CDN node, not to another host as in the P2P 556 case. Moreover, there is no generic way to disambiguate PIDs 557 containing only hosts from PIDs containing CDN nodes. 559 It is possible that a Request Router may be designated as being 560 responsible only for a fixed set of Host PIDs. This information can 561 be made available to the Request Router before it receives requests 562 from hosts. If the set of Host PIDs is not known ahead of time, the 563 latency for serving requests will be impacted by the capabilities of 564 the ALTO server. 566 With such information ahead of time, a Request Router that uses the 567 Network Maps Service may pre-download the Network Map for the 568 interesting Host PIDs and the CDN PIDs. It can also start 569 periodically pulling Cost Map for relevant PID 2-tuples. 571 The Request Router can rely on the ALTO Server generated Cache- 572 Control headers to decide how often to fetch CDN PID network map and 573 Host PID network maps. 575 For Alto protocol requirements related to request routing with the 576 Map Service see Section 8.1.1 and Section 8.1.2. 578 6.4. Request Routing using the Endpoint Cost Service 580 Alternatively, the Request Router may request the Endpoint service 581 from the ALTO client. 583 Specifically, the Request Router requests the Endpoint Cost Service 584 to rank/rate the content locations (i.e., IP addresses of CDN nodes) 585 based on their distance/cost (by default the Endpoint Cost Service 586 operates based on Routing Distance) from/to the user address. 588 Once the Request Router obtains from the ALTO Server the ranked list 589 of locations (for the specific user) it can incorporate this 590 information into its selection mechanisms in order to point the user 591 to the most appropriate location. 593 A Request Router that uses the Endpoint Cost Service may query the 594 ALTO Server for rankings of CDN Node IP addresses for each requesting 595 host and cache the results for later usage. 597 Maps Services and ECS deliver similar ALTO service by allowing the 598 Request Routing Functino to optimize internal selection mechanisms. 599 Both services deliver similar level of security, confidentiality of 600 layer-specific information (i.e.: application and network) however, 601 Maps and ECS differ in the way the ALTO service is delivered and 602 address a different set of requirements in terms of topology 603 information and network operations. 605 6.4.1. Topology Computation and ECS Delivery 607 ECS allows the Request Routing Function to not have to implement any 608 specific algorithm or mechanism in order to retrieve, maintain and 609 process network topology information (of any kind). The complexity 610 of the network topology (computation, maintenance and distribution) 611 is kept in the ALTO server and ECS is delivered on demand. Thus ECS 612 is used in order to implement a lightweight integration of ALTO 613 services in the CDN layer. ECS implies an ALTO and CDN 614 implementation with the necessary scalability in order to cope with 615 the amount of transactions that CDN and ALTO server will have to 616 handle (knowing that the CDN is able to cache ALTO ECS results for 617 further use). 619 6.4.2. Ranking Service 621 When a user requests a given content, the Request Routing Function 622 locates the content in one or more caches and executes a selection 623 algorithm to redirect the user to the 'best' cache. In order to 624 achieve that, the CDN issues an ECS request with the endpoint address 625 (IPv4/IPv6) of the user (content requester) and the set of endpoint 626 addresses of the content caches (content targets). The ALTO server, 627 receives the request and ranks the list of content targets addresses 628 based on their distance from the content requester. By default, 629 according to [I-D.ietf-alto-protocol], the distance represents the 630 routing cost as computed by the routing layer (OSPF, ISIS, BGP) and 631 may take into consideration other routing criteria such as MPLS-VPN 632 (MP-BGP) and MPLS-TE (RSVP), policy and state & performance 633 information. 635 Once the ALTO server has computed the distance it replies with the 636 ranked list of content target addresses. The list being ranked by 637 distance, the CDN is capable of integrating the rankings into its 638 selection process (that will also incorporate other criteria) and 639 redirect the user accordingly. 641 6.5. Update, Redirection of ALTO Info to CDN Request Routing 643 The information provided by an ALTO server to Request Routing is 644 based on topology information of the network. The different methods 645 and algorithms through which the ALTO server computes topology 646 information and rankings is out of the scope of this document. 647 However, update and rediction of such information may have an impact 648 on the integration of ALTO into CDN Request Routing. 650 6.5.1. ALTO Update and Network Events 652 In the case that ALTO information is based on routing (IP/MPLS) 653 topology, it is obvious that network events may impact the ALTO 654 computation. The scope of the ALTO information delivered to Request 655 Routing is not to maintain the CDN aware of any possible network 656 topology changes since, due to redundancy of current networks, most 657 of the network events happening in the infrastructure will have 658 limited impact on the CDN. However, catastrophic events such as main 659 trunks failures or backbone partition will have to take into account 660 by the ALTO server so to redirect traffic away from the failure 661 impacted area. 663 6.5.2. Caching and Lifetime 665 Each reply sent back by the ALTO server to the ALTO client running in 666 the Request Routing Function has a validity in time so that the CDN 667 can cache the results in order to re-use it and hence reducing the 668 number of transactions between CDN and ALTO server. The ALTO server 669 may indicate in the reply message how long the content of the message 670 is to be considered reliable and insert a lifetime value that will be 671 used by the Request Routing Function in order to cache (and then 672 flush or refresh) the entry. 674 An ALTO server implementation may want to keep state about ALTO 675 clients so to inform and signal to these clients when a major network 676 event happened so to clear the ALTO cache in the client. In a CDN/ 677 ALTO interworking architecture, where there are only a few CDN 678 components interacting with the ALTO server, there are no scalability 679 issues in maintaining state about clients in the ALTO server. 681 6.5.3. ALTO Redirection 683 When ALTO server receives a request from a CDN Request Routing 684 Function, it may not have the most appropriate topology information 685 to reply. In such case, the ALTO server, may want to adopt the 686 following strategies: 688 o Reply with available information (best effort). 690 o Redirect the request to another ALTO server presumed to have 691 better topology information (redirection). 693 o Doing both (best effort and redirection). In this case, the reply 694 message contains both the rankings and the indication of another 695 ALTO server where more accurate information may be delivered. 697 The decision process that is used to determine if redirection is 698 necessary (and which mode to use) is out of the scope of this 699 document. As an example, an ALTO server may decide to redirect any 700 request having addresses that are located into a remote Autonomous 701 System. In such case the redirection message includes the ALTO 702 server to be used and that resides in the remote AS. Redirection 703 implies communication between ALTO servers so to be able to signal 704 their identity, location and type of visibility (AS number). 706 6.5.4. Groups and Costs 708 An automated ALTO implementation may use dynamic algorithms to 709 aggregate network topology. However, it is often desirable to have a 710 mechanism through which the network operator can control the level 711 and details of network aggregation based on a set of requirements and 712 constraints. IP/MPLS networks make use of a common mechanism to 713 aggregate and group prefixes that is called BGP Communities. BGP is 714 the protocol all ISP networks use in order to exchange information 715 about their prefix reachability. BGP Community us an attribute used 716 to tag a prefix so to group prefixes based on mostly any criteria (as 717 an example, most SP networks originate BGP prefixes with communities 718 identifying the Point of Presence (PoP) where the prefix has been 719 originated). 721 The ALTO server may leverage the BGP information that is available in 722 the ISP network layer and compute group of prefixes. By policy, the 723 ALTO server operator may decide an arbitrary cost to set between 724 groups. Alternatively, there are algorithms that allow dynamic 725 computation of cost between groups. 727 7. Multiple Administrative Domains 729 The preceding discussion works well in a single administrative domain 730 setting: the CDN nodes are in the administrative domain of the ISP. 731 However, the CDN nodes, the ISP, and the Request Router can be in 732 different administrative domains. In this section, we consider a few 733 such deployment cases. We use DNS as an example. 735 7.1. CDN nodes/Request Router in a separate administrative domain from 736 that of ISP 738 In many situations, the CDN nodes and the Request Router are in a 739 separate network managed by an entity that is distinct from the ISP. 740 Consequently, the CDN nodes belong to a network with its own ALTO 741 server that is distinct from the ALTO server of the ISP where the 742 subscribers belong to. 744 ................................. 745 : +-----------------+ : 746 : | Request Routing | : 747 : | Function | : 748 +----------+ : | | : 749 | Content | : | +-------------+ | : 750 | Provider | : | | ALTO Client | | : 751 +----------+ : | +-------------+ | : 752 : +-----------------+ : 753 : ^ : 754 : | : 755 : +-----------------+ : 756 ................................. : | ALTO Server | : 757 : : : | | : 758 : +----------------+ : : | +-------------+ | : 759 : | ALTO Server |--------------------->| ALTO Client | | : 760 : +----------------+ : : | +-------------+ | : 761 : : : +-----------------+ : 762 : : : : 763 : +------+ C(1-4) +--------+ : : +--------+ C(6-8) +------+ : 764 : | Host |<--------->| Border |: c6 :| Border |<--------->| CDN | : 765 : | PID1 | +-->| Router |-------| Router |<--+ | PID8 | : 766 : +------+ |+->| PID4 | : :| PID6 |<-+| +------+ : 767 : || +--------+ : : +--------+ || : 768 : || : : || : 769 : +------+ C(2-4)|| : : ||C(6-9) +------+ : 770 : | Host |<------+| : : |+------>| CDN | : 771 : | PID2 | | : : | | PID9 | : 772 : +------+ | : : | +------+ : 773 : | : : | : 774 : | : : | : 775 : +------+ C(3-4) | +--------+ : : +--------+ | C(6-10)+------+ : 776 : | Host |<-------+ | Border |: c7 :| Border | +------->| CDN | : 777 : | PID3 | | Router |-------| Router | | PID10| : 778 : +------+ | PID5 | : : | PID7 | +------+ : 779 : +--------+ : : +--------+ : 780 : : : : 781 : ISP Administrative Domain : : CDN Administrative Domain : 782 :...............................: :...............................: 784 Figure 6: Map advertising between ISP and CDN domains 786 The ALTO server in the CDN provider network is assumed to be 787 initialized with information about the ISP networks it serves. For 788 every such ISP network, it consults the routing plane to find the set 789 of Border routers. The CDN network ALTO server computes the cost of 790 reaching each Border router from every CDN node (say, C_cdn). 792 Next, the CDN ALTO server contacts the ISP network's ALTO server and 793 downloads the network map. In order to help the CDN ALTO server 794 compute the cost from a CDN node to a subscriber's PID, we break it 795 down into two parts - the cost from the CDN node to the Border Router 796 (C_cdn) and the cost from the Border Router to the subscriber's PID 797 (say, C_isp). Note that for any chosen exit point, C_cdn may be 798 computed locally by the CDN ALTO Server. However, the fundamental 799 issue is that C_isp depends on the exit point (Border outer) chosen 800 by the CDN. There are multiple ways for the CDN ALTO Server to 801 compute C_isp given the Network Map and Cost Map from the ISP's ALTO 802 Server. 804 One possibility is for the ISP ALTO Server to define a special Border 805 Router PID (denoted by a PID attribute) which also indicates the 806 corresponding Border Router PID in the CDN. The attributes and 807 values may be agreed-upon by the ISP and CDN when the ALTO Services 808 are configured. For example, in the example shown in Figure 5, the 809 ISP ALTO Server indicates that its PID4 and PID5 are Border PIDs, 810 with corresponding PIDs in the CDN as PID6, and PID7, respectively. 811 Then, CDN ALTO Server can locally compute C_isp = cost(ISP Border 812 Router PID, Subscriber PID). 814 A second possibility for computing C_isp is to make use of Border 815 Router IP addresses. The CDN's Border Router can locally determine 816 the IP address of the connected border router in the ISP. In this 817 approach, neither the CDN ALTO Server nor the ISP ALTO Server define 818 PID attributes. The ISP ALTO Server is not required to define 819 special PIDs for Border Routers - it only needs to ensure that Border 820 Router IP addresses are aggregated appropriately in its Network Map. 822 Specifically, we identify two scenarios for the CDN ALTO Server to 823 compute C_isp and C_cdn. 825 In the first scenario, the CDN does not conduct CDN-level multi-path 826 routing from the CDN nodes to the subscriber hosts. Thus, the 827 routing path from a CDN IP address to a subscriber host IP address is 828 typically uniquely (if no ECMP) determined by the network routing 829 system. In this scenario, for a given CDN node IP address to a 830 subscriber host IP address, the CDN ALTO Server uses the routing 831 system to compute the Border Egress router inside the CDN, and the 832 corresponding Border Ingress router inside the ISP. Then the CDN 833 ALTO Server has C_cdn(CDN node IP, Border Egress router IP inside the 834 CDN), and C_isp(Border Ingress router IP inside the ISP, Subscriber 835 IP). The computation of C_cdn and C_isp can be done using ALTO in 836 the traditional way through either the Network Map and Cost Map or 837 the Endpoint Cost Service. 839 In the second scenario, the CDN may support CDN-level multi-path 840 routing from the CDN nodes to the subscriber hosts. In particular, 841 from each CDN node, the CDN has a capability (e.g., through 842 tunneling) to send to a subscriber host IP through multiple Border 843 Egress routers (e.g., through any Egress router that receives an 844 announcement from the ISP of the subscriber host IP). In this case, 845 the cost of reaching a host PID from a given CDN node is then 846 determined as the minimum cost among all possible intermediate Border 847 Routers. 849 If the network is homogeneous, then a good approximation of the cost 850 between each host PID and a given CDN node can be given as: C_cdn(CDN 851 Node, Border router) + C_isp(Border router, Subscriber PID). In this 852 computation, the Border Router is the one that is on the best path 853 from the CDN node to the Subscriber PID. 855 The CDN ALTO server now has a cost map that provides the cost from 856 each CDN node to all known Subscriber PIDs. The ALTO client in the 857 CDN DNS server downloads this cost map in preparation for subscriber 858 DNS requests. 860 When a subscriber DNS request arrives at the CDN provider's DNS 861 server, it looks up the network map and maps the source IP address to 862 a Subscriber PID. It then uses the cost map to pick the best CDN 863 node for this Subscriber PID. 865 7.2. Managed DNS Domain with Three Administrative Domains 867 Many organizations / content providers outsource DNS management to 868 the external vendors for various reasons like reliability, 869 performance improvement, DNS security etc. Managed DNS service could 870 be used either with caches owned by the organization itself (section 871 6.3.1) OR with external CDNs (section 6.3.2) 873 7.2.1. Managed DNS Redirect to Local CDN 875 One of the common functions offered by managed DNS service vendor is 876 DNS traffic management where DNS resolver can load balance traffic 877 dynamically across CDN servers. 879 Typically managed DNS service provider has DNS resolvers spread 880 across geographical locations to improve performance. This also 881 makes easier for DNS resolver to redirect host to the nearest cache. 882 Such a DNS resolver would be an ideal candidate to implement ALTO 883 client where it can fetch network map and cost map from ALTO servers 884 located in the same geographical area only. Load balancing 885 implemented with the knowledge of network and cost map would be more 886 efficient than other mechanisms like round robin. 888 2 +----------------+ 889 +--------------------> | root | 890 | +------------------- | Name Server | 891 | | 3 +----------------+ 892 | | 893 | | 4 +----------------+ 894 | | +--------------> | com | 895 | | | +------------- | Name Server | 896 | | | | 5 +----------------+ 897 | | | | 898 _|-|---|-|--------------------. 899 ,-'' | V | V `--. 900 ' +---------+ 6 +---------------`+. 901 | | DNS |-------->| xyz.com | ` 902 | | Proxy |<--------| DNS Resolver | | 903 | +---------+ 7 | | | 904 | 1^ | 8 | +------------+ | | 905 | | | | |ALTO Client | | | 906 | +-----V---+ | +------------+ | | 907 | | Host | +----------------.-' 908 | +---------+ | ^ .-' 909 | | DOMAIN 1 | |-' ALTO Protocol 910 | V |.-'| (Map Service) 911 `--. CDN Node __.--:-| | 912 `----. _.--' | | 913 `---.-'' ,---------+-------. 914 ,'+----------------+ \ 915 / | ALTO Server | : 916 ( +----------------+ | 917 \ ; 918 \ DOMAIN 2 ,' 919 `-----------------' 921 In the figure above, there exists 2 possibilities: 923 Case 1: Domain 1 and Domain 2 are connected to the same service 924 provider network. This case is similar to section 6.1 926 Case 2: Domain 1 and Domain 2 are connected to different service 927 provider network. This case is similar to section 6.2 929 7.2.2. Managed DNS with CDN-Provided Request Routing 931 It is also possible to utilize a Managed DNS service and still rely 932 on a CDN's request routing. For example, this could be done if a 933 network provider wishes to utilize a Managed DNS provider, but also 934 wishes to integrate its own CDN using ALTO with DNS-based request 935 routing. 937 To support this, the network provider may submit any necessary 938 configuration files (e.g., indicating necessary CNAME records) to 939 redirect CDN requests to the CDN's DNS Request Routing mechanism. 940 Requests for the CDN (e.g., 'cdn.isp.com') will then be directed by 941 DNS request routing, while requests for other hosts are handled by 942 the Managed DNS solution. 944 8. Protocol Recommendations 946 In the previous sections, this document has taken the approach of 947 providing information on existing CDN approaches and possible 948 benefits of utilizing ALTO. However, in developing the taxonomy, use 949 cases, and deployment scenarios, we have identified cases where the 950 ALTO Protocol [I-D.ietf-alto-protocol] and Server Discovery 951 [I-D.kiesel-alto-3pdisc] [I-D.song-alto-server-discovery] 952 [I-D.stiemerling-alto-dns-discovery] may be lacking capabilities that 953 may be helpful and/or necessary for usage with CDNs. We now focus on 954 detailing these gaps with the goal of providing feedback and 955 recommendations. Note that some protocol changes may be necessary in 956 the core protocol, while others may be implemented as extensions. 958 This section will be updated to track changes in the ALTO Protocol, 959 ALTO Server Discovery, and accompanying protocols. 961 8.1. Necessary Additions 963 This section details changes to the ALTO protocols that would be 964 necessary to make use of ALTO within CDN infrastructures. We 965 classify a change as "necessary" if there is a core feature of a CDN/ 966 ALTO integration that is not possible to implement with the existing 967 protocols. 969 8.1.1. NA1: PID Attributes 971 In order to disambiguate between PIDs that contain endpoints of a 972 specific class, a PID property is needed. A PID can be classified as 973 containing "CDN nodes", "Mobile Hosts", "Wireline Hosts", etc. This 974 mechanism can be used to provide an ALTO Client a list of nodes of a 975 particular type, along with the ALTO Costs to each node. In the 976 context of CDNs, the attributes could describe a type of CDN node. 977 For example an Origin would have one type of attribute while an edge 978 cache would have another. This would allow for more intelligent 979 routing. 981 8.1.2. NA2: PID Attributes and Query 983 PID attributes can be used by the ALTO Client to select a appropriate 984 host and also passed as a constraint in the map filtering service. 986 8.2. Helpful Additions 988 This section details changes to the ALTO Protocol that would be 989 helpful to make use of ALTO within CDN infrastructures. We classify 990 a change as "helpful" if there is a compelling extension to existing 991 CDNs that would be possible with additional functionality within 992 ALTO, or if there is a component of CDN/ALTO integration that could 993 be made more efficient or otherwised improved with additional ALTO 994 functionality. 996 8.2.1. HA1: Push Mechanism 998 It is important for the ALTO Service through the ALTO protocol or a 999 companion protocol to provide a push mechanism from server to client. 1000 The push mechanism can be a notification that new data is available 1001 or the data itself. 1003 8.2.2. HA2: Incremental Map Updates 1005 A natural evolution to the protocol if maps are large and change 1006 often is to allow for incremental map updates. In this sense the map 1007 contained in the reply would be considered the delta from the 1008 previous version. 1010 8.2.3. HA3: ALTO Border Router PID attribute 1012 In order for administrative domains to collate costs across domain 1013 boundaries, the border routers may be placed in their own PIDs. Such 1014 PIDs may be identified by a Border Router attribute. 1016 8.2.4. HA4: CDN ALTO Server Discovery 1018 In certain deployment scenarios, it may be beneficial for an ALTO 1019 client to directly query a CDN's ALTO Server (instead of the CDN's 1020 ALTO Server only being consulted as a backend process). For example, 1021 this can provide more accurate guidance than DNS Request Routing 1022 since the client's IP address may be directly used by the CDN in 1023 order to select a cache node. This would require an ALTO Client 1024 (e.g., an ISP subscriber) to be able to discover an ALTO Server owned 1025 and/or managed by a CDN. This could be done by an extension to the 1026 discovery protocol, or it could be done by allowing an ISP's ALTO 1027 Server to redirect certain queries to a CDN ALTO Server. 1029 8.2.5. HA5: Extensible ALTO Cost Maps 1031 Certain deployment scenarios may benefit from additional information 1032 being carried within ALTO information. For example, a trusted 1033 neighboring ISP B may be able to help ISP A optimize multihoming 1034 costs. To provide an extensible way to communicate additional data, 1035 the ALTO Protocol could be extended to include opaque data strings 1036 (in addition to numeric and ordinal values) in an ALTO Cost Map. 1038 8.2.6. NA4: Federated Deployment of ALTO Servers 1040 There is a need to define how ALTO servers may communicate with each 1041 other in a federated model. 1043 9. IANA Considerations 1045 This document makes no request of IANA. 1047 Note to RFC Editor: this section may be removed on publication as an 1048 RFC. 1050 10. Security Considerations 1052 When the ALTO Server and Client are operated by different entities 1053 the issue of trust and security comes forward. The exchange of 1054 information could be done using the encryption methods already 1055 present in HTTP but preventing unauthorized redistribution comes into 1056 play. A further issue is if the ALTO information information is 1057 transitive, which modifications are allowed. 1059 11. Acknowledgements 1061 We would like to thank Satish Raghunath and Mayuresh Bakshi for 1062 valuable input and contributions to this draft. We would also like 1063 to thank Nabil Bitar, Manish Bhardwaj, Michael Korolyov, Steven Luong 1064 and Ferry Sutanto for their comments. 1066 12. References 1068 12.1. Normative References 1070 [I-D.ietf-alto-protocol] 1071 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 1072 draft-ietf-alto-protocol-06 (work in progress), 1073 October 2010. 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, March 1997. 1078 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1079 Optimization (ALTO) Problem Statement", RFC 5693, 1080 October 2009. 1082 12.2. Informative References 1084 [ARBOR] Labovitz, "Internet Traffic and Content Consolidation", 1085 2009, . 1088 [GoogleCDN] 1089 Madhyastha, H., Jain, S., Srinivasan, S., Krishnamurthy, 1090 A., Anderson, T., and J. Gao, "Moving Beyond End-to-End 1091 Path Information to Optimize CDN Performance", 2009, 1092 . 1094 [I-D.kiesel-alto-3pdisc] 1095 Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M. 1096 Stiemerling, "Third-party ALTO server discovery", 1097 draft-kiesel-alto-3pdisc-03 (work in progress), July 2010. 1099 [I-D.lee-alto-chinatelecom-trial] 1100 Li, K., Wang, A., and K. Zhou, "ALTO and DECADE service 1101 trial within China Telecom", 1102 draft-lee-alto-chinatelecom-trial-00 (work in progress), 1103 July 2010. 1105 [I-D.song-alto-server-discovery] 1106 Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V. 1107 Avila, "ALTO Service Discovery", 1108 draft-song-alto-server-discovery-03 (work in progress), 1109 July 2010. 1111 [I-D.stiemerling-alto-dns-discovery] 1112 Stiemerling, M. and H. Tschofenig, "A DNS-based ALTO 1113 Server Discovery Procedure", 1114 draft-stiemerling-alto-dns-discovery-00 (work in 1115 progress), July 2010. 1117 [I-D.vandergaast-edns-client-subnet] 1118 Contavalli, C., Gaast, W., Leach, S., and D. Rodden, 1119 "Client subnet in DNS requests", 1120 draft-vandergaast-edns-client-subnet-00 (work in 1121 progress), January 2011. 1123 [P4P] Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A. 1124 Silberschatz, "P4P: Provider Portal for (P2P) 1125 Applications", March 2009. 1127 [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known 1128 Content Network (CN) Request-Routing Mechanisms", 1129 RFC 3568, July 2003. 1131 [RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and 1132 Y. Yang, "Comcast's ISP Experiences in a Proactive Network 1133 Provider Participation for P2P (P4P) Technical Trial", 1134 RFC 5632, September 2009. 1136 Authors' Addresses 1138 Reinaldo Penno 1139 Juniper Networks 1141 Email: rpenno@juniper.net 1143 Jan Medved 1144 Juniper Networks 1146 Email: jmedved@juniper.net 1148 Richard Alimi 1149 Google 1151 Email: ralimi@google.com 1153 Richard Yang 1154 Yale University 1156 Email: yry@yale.edu 1158 Stefano Previdi 1159 Cisco Systems 1161 Email: sprevidi@cisco.com