idnits 2.17.1 draft-ietf-cdi-known-request-routing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 130 has weird spacing: '...ould be used ...' == Line 234 has weird spacing: '... server and b...' == Line 335 has weird spacing: '... suited for l...' == Line 370 has weird spacing: '...quested conte...' == Line 499 has weird spacing: '...then be rew...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7805 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 577, but no explicit reference was found in the text ** Obsolete normative reference: RFC 765 (ref. '1') (Obsoleted by RFC 959) ** Obsolete normative reference: RFC 846 (ref. '2') (Obsoleted by RFC 847) ** Obsolete normative reference: RFC 2326 (ref. '3') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '5') ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1889 (ref. '7') (Obsoleted by RFC 3550) ** Downref: Normative reference to an Informational draft: draft-ietf-cdi-model (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '9') Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Cain 3 Internet-Draft Storigen Systems 4 Expires: May 2, 2003 A. Barbir 5 Nortel Networks 6 R. Nair 7 Cisco 8 O. Spatscheck 9 AT&T 10 November 2002 12 Known CN Request-Routing Mechanisms 13 draft-ietf-cdi-known-request-routing-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 2, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 The work presents a summary of Request-Routing techniques that are 45 used to direct client requests to surrogates based on various 46 policies and a possible set of metrics. In this memo the term 47 Request-Routing represents techniques that are commonly called 48 content routing or content redirection. In principle, Request- 49 Routing techniques can be classified under: DNS Request-Routing, 50 Transport-layer Request-Routing, and Application-layer Request- 51 Routing. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4 57 2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3 Multi-Level Resolution . . . . . . . . . . . . . . . . . . . 4 60 2.3.1 NS Redirection . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3.2 CNAME Redirection . . . . . . . . . . . . . . . . . . . . . 5 62 2.4 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.5 Object Encoding . . . . . . . . . . . . . . . . . . . . . . 6 64 2.6 DNS Request-Routing Limitations . . . . . . . . . . . . . . 6 65 3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 8 66 4. Application-Layer Request-Routing . . . . . . . . . . . . . 9 67 4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 9 68 4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 9 69 4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 10 70 4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 10 71 4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 11 72 4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 11 73 4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 12 74 4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 12 75 5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 13 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 77 7. Additional Authors and Acknowledgements . . . . . . . . . . 15 78 Normative References . . . . . . . . . . . . . . . . . . . . 16 79 Informative References . . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 81 A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 18 82 A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 18 83 A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 18 84 A.1.2 Passive Measurement . . . . . . . . . . . . . . . . . . . . 19 85 A.1.3 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 19 86 A.1.4 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 20 87 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 The document provides a summary of current known techniques that 92 could be used to direct client requests to surrogates based on 93 various policies and a possible set of metrics. The task of 94 directing clients' requests to surrogates is also called Request- 95 Routing, Content Routing or Content Redirection. 97 Request-Routing techniques are commonly used in Content Networks 98 (also known as Content Delivery Networks) [8]. Content Networks 99 include network infrastructure that exists in layers 4 through 7. 100 Content Networks deal with the routing and forwarding of requests and 101 responses for content. Content Networks rely on layer 7 protocols 102 such as HTTP [4] for transport. 104 Request-Routing techniques are generally used to direct client 105 requests for objects to a surrogate or a set of surrogates that could 106 best serve that content. Request-Routing mechanisms could be used to 107 direct client requests to surrogates that are within a Content 108 Network (CN) [8]. 110 Request-Routing techniques are used as a vehicle to extend the reach 111 and scale of Content Delivery Networks. There exist multiple 112 Request-Routing mechanisms. At a high-level, these may be classified 113 under: DNS Request-Routing, transport-layer Request-Routing, and 114 application-layer Request-Routing. 116 A request routing system uses a set of metrics in an attempt to 117 direct users to surrogate that can best serve the request. For 118 example, the choice of the surrogate could be based on network 119 proximity, bandwidth availability, surrogate load and availability of 120 content. Appendix A provides a summary of metrics and measurement 121 techniques that could be used in the selection of the best surrogate. 123 The memo is organized as follows: Section 2 provides a summary of 124 known DNS based Request-Routing techniques. Section 3 discusses 125 transport-layer Request-Routing methods. In section 4 application 126 layer Request-Routing mechanisms are explored. Section 5 provides 127 insight on combining the various methods that were discussed in the 128 earlier sections in order to optimize the performance of the Request- 129 Routing System. Appendix A provides a summary of possible metrics 130 and measurements techniques that could be used by the Request- 131 Routing system to choose a given surrogate. 133 2. DNS based Request-Routing Mechanisms 135 DNS based Request-Routing techniques are common due to the ubiquity 136 of DNS as a directory service. In DNS based Request-Routing 137 techniques, a specialized DNS server is inserted in the DNS 138 resolution process. The server is capable of returning a different 139 set of A, NS or CNAME records based on user defined policies, 140 metrics, or a combination of both. 142 2.1 Single Reply 144 In this approach, the DNS server is authoritative for the entire DNS 145 domain or a sub domain. The DNS server returns the IP address of the 146 best surrogate in an A record to the requesting DNS server. The IP 147 address of the surrogate could also be a virtual IP(VIP) address of 148 the best set of surrogates for requesting DNS server. 150 2.2 Multiple Replies 152 In this approach, the Request-Routing DNS server returns multiple 153 replies such as several A records for various surrogates. Common 154 implementations of client site DNS server's cycles through the 155 multiple replies in a Round-Robin fashion. The order in which the 156 records are returned can be used to direct multiple clients using a 157 single client site DNS server. 159 2.3 Multi-Level Resolution 161 In this approach multiple Request-Routing DNS servers can be involved 162 in a single DNS resolution. The rationale of utilizing multiple 163 Request-Routing DNS servers in a single DNS resolution is to allow 164 one to distribute more complex decisions from a single server to 165 multiple, more specialized, Request-Routing DNS servers. The most 166 common mechanisms used to insert multiple Request-Routing DNS servers 167 in a single DNS resolution is the use of NS and CNAME records. An 168 example would be the case where a higher level DNS server operates 169 within a territory, directing the DNS lookup to a more specific DNS 170 server within that territory to provide a more accurate resolution. 172 2.3.1 NS Redirection 174 A DNS server can use NS records to redirect the authority of the next 175 level domain to another Request-Routing DNS server. The, technique 176 allows multiple DNS server to be involved in the name resolution 177 process. For example, a client site DNS server resolving 178 a.b.example.com [10] would eventually request a resolution of 179 a.b.example.com from the name server authoritative for example.com. 180 The name server authoritative for this domain might be a Request- 181 Routing NS server. In this case the Request-Routing DNS server can 182 either return a set of A records or can redirect the resolution of 183 the request a.b.example.com to the DNS server that is authoritative 184 for example.com using NS records. 186 One drawback of using NS records is that the number of Request- 187 Routing DNS servers are limited by the number of parts in the DNS 188 name. This problem results from DNS policy that causes a client site 189 DNS server to abandon a request if no additional parts of the DNS 190 name are resolved in an exchange with an authoritative DNS server. 192 A second drawback is that the last DNS server can determine the TTL 193 of the entire resolution process. Basically, the last DNS server can 194 return in the authoritative section of its response its own NS 195 record. The client will use this cached NS record for further 196 request resolutions until it expires. 198 Another drawback is that some implementations of bind voluntarily 199 cause timeouts to simplify their implementation in cases in which a 200 NS level redirect points to a name server for which no valid A record 201 is returned or cached. This is especially a problem if the domain of 202 the name server does not match the domain currently resolved, since 203 in this case the A records, which might be passed in the DNS 204 response, are discarded for security reasons. Another drawback is 205 the added delay in resolving the request due to the use of multiple 206 DNS servers. 208 2.3.2 CNAME Redirection 210 In this scenario, the Request-Routing DNS server returns a CNAME 211 record to direct resolution to an entirely new domain. In principle, 212 the new domain might employ a new set of Request-Routing DNS servers. 214 One disadvantage of this approach is the additional overhead of 215 resolving the new domain name. The main advantage of this approach 216 is that the number of Request-Routing DNS servers is independent of 217 the format of the domain name. 219 2.4 Anycast 221 Anycast [5] is an inter-network service that is applicable to 222 networking situations where a host, application, or user wishes to 223 locate a host which supports a particular service but, if several 224 servers support the service, does not particularly care which server 225 is used. In an anycast service, a host transmits a datagram to an 226 anycast address and the inter-network is responsible for providing 227 best effort delivery of the datagram to at least one, and preferably 228 only one, of the servers that accept datagrams for the anycast 229 address. 231 The motivation for anycast is that it considerably simplifies the 232 task of finding an appropriate server. For example, users, instead 233 of consulting a list of servers and choosing the closest one, could 234 simply type the name of the server and be connected to the nearest 235 one. By using anycast, DNS resolvers would no longer have to be 236 configured with the IP addresses of their servers, but rather could 237 send a query to a well-known DNS anycast address. 239 Furthermore, to combine measurement and redirection, the Request- 240 Routing DNS server can advertise an anycast address as its IP 241 address. The same address is used by multiple physical DNS servers. 242 In this scenario, the Request-Routing DNS server that is the closest 243 to the client site DNS server in terms of OSPF and BGP routing will 244 receive the packet containing the DNS resolution request. The server 245 can use this information to make a Request- Routing decision. 246 Drawbacks of this approach are listed below: 248 o The DNS server may not be the closest server in terms of routing 249 to the client. 251 o Typically, routing protocols are not load sensitive. Hence, the 252 closest server may not be the one with the least network latency. 254 o The server load is not considered during the Request-Routing 255 process. 257 2.5 Object Encoding 259 Since only DNS names are visible during the DNS Request-Routing, some 260 solutions encode the object type, object hash, or similar information 261 into the DNS name. This might vary from a simple division of objects 262 based on object type (such as images.a.b.example.com and 263 streaming.a.b.example.com) to a sophisticated schema in which the 264 domain name contains a unique identifier (such as a hash) of the 265 object. The obvious advantage is that object information is 266 available at resolution time. The disadvantage is that the client 267 site DNS server has to perform multiple resolutions to retrieve a 268 single Web page, which might increase rather than decrease the 269 overall latency. 271 2.6 DNS Request-Routing Limitations 273 Some limitations of DNS based Request-Routing techniques are 274 described below: 276 o DNS only allows resolution at the domain level. However, an ideal 277 request resolution system should service requests per object 278 level. 280 o In DNS based Request-Routing systems servers may be required to 281 return DNS entries with a short time-to-live (TTL) values. This 282 may be needed in order to be able to react quickly in the face of 283 outages. This in return may increase the volume of requests to 284 DNS servers. 286 o Some DNS implementations do not always adhere to DNS standards. 287 For example, many DNS implementations do not honor the DNS TTL 288 field. 290 o DNS Request-Routing is based only on knowledge of the client DNS 291 server, as client addresses are not relayed within DNS requests. 292 This limits the ability of the Request-Routing system to determine 293 a client's proximity to the surrogate. 295 o DNS servers can request and allow recursive resolution of DNS 296 names. For recursive resolution of requests, the Request-Routing 297 DNS server will not be exposed to the IP address of the client's 298 site DNS server. In this case, the Request-Routing DNS server 299 will be exposed to the address of the DNS server that is 300 recursively requesting the information on behalf of the client's 301 site DNS server. For example, imgs.example.com might be resolved 302 by a CN, but the request for the resolution might come from 303 dns1.example.com as a result of the recursion. 305 o Users that share a single client site DNS server will be 306 redirected to the same set of IP addresses during the TTL 307 interval. This might lead to overloading of the surrogate during 308 a flash crowd. 310 o Some implementations of bind can cause DNS timeouts to occur while 311 handling exceptional situations. For example, timeouts can occur 312 for NS redirections to unknown domains. 314 3. Transport-Layer Request-Routing 316 At the transport-layer finer levels of granularity can be achieved by 317 the close inspection of client's requests. In this approach, the 318 Request-Routing system inspects the information available in the 319 first packet of the client's request to make surrogate selection 320 decisions. The inspection of the client's requests provides data 321 about the client's IP address, port information, and layer 4 322 protocol. The acquired data could be used in combination with user- 323 defined policies and other metrics to determine the selection of a 324 surrogate that is better suited to serve the request. The techniques 325 that are used to hand off the session to a more appropriate surrogate 326 are beyond the scope of this document. 328 In general, the forward-flow traffic (client to newly selected 329 surrogate) will flow through the surrogate originally chosen by DNS. 330 The reverse-flow (surrogate to client) traffic, which normally 331 transfers much more data than the forward flow, would typically take 332 the direct path. 334 The overhead associated with transport-layer Request-Routing makes it 335 better suited for long-lived sessions such as FTP [1]and RTSP [3]. 336 However, it also could be used to direct clients away from overloaded 337 surrogates. 339 In general, transport-layer Request-Routing can be combined with DNS 340 based techniques. As stated earlier, DNS based methods resolve 341 clients requests based on domains or sub domains with exposure to the 342 client's DNS server IP address. Hence, the DNS based methods could 343 be used as a first step in deciding on an appropriate surrogate with 344 more accurate refinement made by the transport-layer Request-Routing 345 system. 347 4. Application-Layer Request-Routing 349 Application-layer Request-Routing systems perform deeper examination 350 of client's packets beyond the transport layer header. Deeper 351 examination of client's packets provides fine-grained Request-Routing 352 control down to the level of individual objects. The process could 353 be performed in real time at the time of the object request. The 354 exposure to the client's IP address combined with the fine-grained 355 knowledge of the requested objects enable application-layer Request- 356 Routing systems to provide better control over the selection of the 357 best surrogate. 359 4.1 Header Inspection 361 Some application level protocols such as HTTP [4], RTSP [3], and SSL 362 [2] provide hints in the initial portion of the session about how the 363 client request must be directed. These hints may come from the URL 364 of the content or other parts of the MIME request header such as 365 Cookies. 367 4.1.1 URL-Based Request-Routing 369 Application level protocols such as HTTP and RTSP describe the 370 requested content by its URL [6]. In many cases, this information 371 is sufficient to disambiguate the content and suitably direct the 372 request. In most cases, it may be sufficient to make Request- 373 Routing decision just by examining the prefix or suffix of the URL. 375 4.1.1.1 302 Redirection 377 In this approach, the client's request is first resolved to a virtual 378 surrogate. Consequently, the surrogate returns an application- 379 specific code such as the 302 (in the case of HTTP [4] or RTSP [3]) 380 to redirect the client to the actual delivery node. 382 This technique is relatively simple to implement. However, the main 383 drawback of this method is the additional latency involved in sending 384 the redirect message back to the client. 386 4.1.1.2 In-Path Element 388 In this technique, an In-Path element is present in the network in 389 the forwarding path of the client's request. The In-Path element 390 provides transparent interception of the transport connection. The 391 In-Path element examines the client's content requests and performs 392 Request-Routing decisions. 394 The In-Path element then splices the client connection to a 395 connection with the appropriate delivery node and passes along the 396 content request. In general, the return path would go through the 397 In-Path element. However, it is possible to arrange for a direct 398 return by passing the address translation information to the 399 surrogate or delivery node through some proprietary means. 401 The primary disadvantage with this method is the performance 402 implications of URL-parsing in the path of the network traffic. 403 However, it is generally the case that the return traffic is much 404 larger than the forward traffic. 406 The technique allows for the possibility of partitioning the traffic 407 among a set of delivery nodes by content objects identified by URLs. 408 This allows object-specific control of server loading. For example, 409 requests for non-cacheable object types may be directed away from a 410 cache. 412 4.1.2 Header-Based Request-Routing 414 This technique involves the task of using HTTP [4] such as Cookie, 415 Language, and User-Agent, in order to select a surrogate. 417 Cookies can be used to identify a customer or session by a web site. 418 Cookie based Request-Routing provides content service differentiation 419 based on the client. This approach works provided that the cookies 420 belong to the client. In addition, it is possible to direct a 421 connection from a multi-session transaction to be directed to the 422 same server to achieve session-level persistence. 424 The language header can be used to direct traffic to a language- 425 specific delivery node. The user-agent header helps identify the 426 type of client device. For example, a voice-browser, PDA, or cell 427 phone can indicate the type of delivery node that has content 428 specialized to handle the content request. 430 4.1.3 Site-Specific Identifiers 432 Site-specific identifiers help authenticate and identify a session 433 from a specific user. This information may be used to direct a 434 content request. 436 An example of a site-specific identifier is the SSL Session 437 Identifier. This identifier is generated by a web server and used by 438 the web client in succeeding sessions to identify itself and avoid an 439 entire security authentication exchange. In order to inspect the 440 session identifier, an In-Path element would observe the responses of 441 the web server and determine the session identifier which is then 442 used to associate the session to a specific server. The remaining 443 sessions are directed based on the stored session identifier. 445 4.2 Content Modification 447 This technique enables a content provider to take direct control over 448 Request-Routing decisions without the need for specific witching 449 devices or directory services in the path between the client and the 450 origin server. Basically, a content provider can directly 451 communicate to the client the best surrogate that can serve the 452 request. Decisions about the best surrogate can be made on a per- 453 object basis or it can depend on a set of metrics. The overall goal 454 is to improve scalability and the performance for delivering the 455 modified content, including all embedded objects. 457 In general, the method takes advantage of content objects that 458 consist of basic structure that includes references to additional, 459 embedded objects. For example, most web pages, consist of an HTML 460 document that contains plain text together with some embedded 461 objects, such as GIF or JPEG images. The embedded objects are 462 referenced using embedded HTML directives. In general, embedded HTML 463 directives direct the client to retrieve the embedded objects from 464 the origin server. A content provider can now modify references to 465 embedded objects such that they could be fetched from the best 466 surrogate. This technique is also known as URL rewriting. 468 Content modification techniques must not violate the architectural 469 concepts of the Internet [9]. Special considerations must be made to 470 ensure that the task of modifying the content is performed in a 471 manner that is consistent with RFC 3238 [9] that specifies the 472 architectural considerations for intermediaries that perform 473 operations or modifications on content. 475 The basic types of URL rewriting are discussed in the following 476 subsections. 478 4.2.1 A-priori URL Rewriting 480 In this scheme, a content provider rewrites the embedded URLs before 481 the content is positioned on the origin server. In this case, URL 482 rewriting can be done either manually or by using a software tools 483 that parse the content and replace embedded URLs. 485 A-priori URL rewriting alone does not allow consideration of client 486 specifics for Request-Routing. However, it can be used in 487 combination with DNS Request-Routing to direct related DNS queries 488 into the domain name space of the service provider. Dynamic Request- 489 Routing based on client specifics are then done using the DNS 490 approach. 492 4.2.2 On-Demand URL Rewriting 494 On-Demand or dynamic URL rewriting, modifies the content when the 495 client request reaches the origin server. At this time, the 496 identity of the client is known and can be considered when rewriting 497 the embedded URLs. In particular, an automated process can 498 determine, on-demand, which surrogate would serve the requesting 499 client best. The embedded URLs can then be rewritten to direct 500 the client to retrieve the objects from the best surrogate rather 501 than from the origin server. 503 4.2.3 Content Modification Limitations 505 Content modification as a Request-Routing mechanism suffers from the 506 following limitations: 508 o The first request from a client to a specific site must be served 509 from the origin server. 511 o Content that has been modified to include references to nearby 512 surrogates rather than to the origin server should be marked as 513 non-cacheable. Alternatively, such pages can be marked to be 514 cacheable only for a relatively short period of time. Rewritten 515 URLs on cached pages can cause problems, because they can get 516 outdated and point to surrogates that are no longer available or 517 no longer good choices. 519 5. Combination of Multiple Mechanisms 521 There are environments in which a combination of different mechanisms 522 can be beneficial and advantageous over using one of the proposed 523 mechanisms alone. The following example illustrates how the 524 mechanisms can be used in combination. 526 A basic problem of DNS Request-Routing is the resolution granularity 527 that allows resolution on a per-domain level only. A per-object 528 redirection cannot easily be achieved. However, content modification 529 can be used together with DNS Request-Routing to overcome this 530 problem. With content modification, references to different objects 531 on the same origin server can be rewritten to point into different 532 domain name spaces. Using DNS Request-Routing, requests for those 533 objects can now dynamically be directed to different surrogates. 535 6. Security Considerations 537 The main objective of this document is to provide a summary of 538 current Request-Routing techniques. Such techniques are currently 539 implemented in the Internet. The document acknowledges that security 540 must be addressed by any entity that implements any technique that 541 redirects client's requests. In [9] RFC 3238 addresses the main 542 requirements for entities that intent to modify requests for content 543 in the Internet. 545 The details of security techniques are beyond the scope of this 546 document. 548 7. Additional Authors and Acknowledgements 550 The following people have contributed to the task of authoring this 551 document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann 552 (Lucent), Doug Potter. 554 The authors acknowledge the contributions and comments of Ian Cooper, 555 Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean 556 (CrystalBall). 558 Normative References 560 [1] Postel, J.l, "File Transfer Protocol", RFC 765, June 1980. 562 [2] T. Dierks et. al, "The TLS Protocol Version 1", RFC 846, July 563 1999. 565 [3] H. Schulzrinne et. al, "Real Time Streaming Protocol", RFC 2326, 566 April 1998. 568 [4] R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", 569 RFC 2616, June 1999. 571 [5] C. Partridge et al., "Host Anycasting Service", RFC 1546, 572 November 1993. 574 [6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC 575 1738, May 1994. 577 [7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time 578 Applications", RFC 1889, January 1996. 580 [8] M. Day et al, "A Model for Content Internetworking (CDI)", 581 Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf- 582 cdi-model-02.txt (groups Last Call), May 2002. 584 [9] S. Floyd et al, "IAB Architectural and Policy Considerations for 585 Open Pluggable Edge Services", RFC 3238, January 2002. 587 Informative References 589 [10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606, 590 June 1999. 592 Authors' Addresses 594 Brad Cain 595 Storigen Systems 596 650 Suffolk Street 597 Lowell, MA 01854 598 USA 600 Phone: +1 978-323-4454 601 EMail: bcain@storigen.com 603 Abbie Barbir 604 Nortel Networks 605 3500 Carling Avenue 606 Nepean, Ontario K2H 8E9 607 Canada 609 Phone: +1 613 763 5229 610 EMail: abbieb@nortelnetworks.com 612 Raj Nair 613 Cisco 614 50 Nagog Park 615 Acton, MA 01720 616 USA 618 EMail: rnair@cisco.com 620 Oliver Spatscheck 621 AT&T 622 180 Park Ave, Bldg 103 623 Florham Park, NJ 07932 624 USA 626 EMail: spatsch@research.att.com 628 Appendix A. Measurements 630 Request-Routing systems can use a variety of metrics in order to 631 determine the best surrogate that can serve a client's request. In 632 general, these metrics are based on network measurements and feedback 633 from surrogates. It is possible to combine multiple metrics using 634 both proximity and surrogate feedback for best surrogate selection. 635 The following sections describe several well known metrics as well as 636 the major techniques for obtaining them. 638 A.1 Proximity Measurements 640 Proximity measurements can be used by the Request-Routing system to 641 direct users to the "closest" surrogate. In a DNS Request-Routing 642 system, the measurements are made to the client's local DNS server. 643 However, when the IP address of the client is accessible more 644 accurate proximity measurements can be obtained. 646 Furthermore, proximity measurements can be exchanged between 647 surrogates and the requesting entity. In many cases, proximity 648 measurements are "one-way" in that they measure either the forward or 649 reverse path of packets from the surrogate to the requesting entity. 650 This is important as many paths in the Internet are asymmetric. 652 In order to obtain a set of proximity measurements, a network may 653 employ active probing techniques and/or passive measurement 654 techniques. The following sections describe these two techniques. 656 A.1.1 Active Probing 658 Active probing is when past or possible requesting entities are 659 probed using one or more techniques to determine one or more metrics 660 from each surrogate or set of surrogates. An example of a probing 661 technique is an ICMP ECHO Request that is periodically sent from each 662 surrogate or set of surrogates to a potential requesting entity. 664 In any active probing approach, a list of potential requesting 665 entities need to be obtained. This list can be generated 666 dynamically. Here, as requests arrive, the requesting entity 667 addresses can be cached for later probing. Another potential 668 solution is to use an algorithm to divide address space into blocks 669 and to probe random addresses within those blocks. Limitations of 670 active probing techniques include: 672 o Measurements can only be taken periodically. 674 o Firewalls and NATs disallow probes. 676 o Probes often cause security alarms to be triggered on intrusion 677 detection systems. 679 A.1.2 Passive Measurement 681 Passive measurements could be obtained when a client performs data 682 transfers to or from a surrogate. Here, a bootstrap mechanism is 683 used to direct the client to a bootstrap surrogate. Once the client 684 connects, the actual performance of the transfer is measured. This 685 data is then fed back into the Request-Routing system. 687 An example of passive measurement is to watch the packet loss from a 688 client to a surrogate by observing TCP behavior. Latency 689 measurements can also be learned by observing TCP behavior. The 690 limitations of passive measurement approach are directly related to 691 the bootstrapping mechanism. Basically, a good mechanism is needed 692 to ensure that not every surrogate is tested per client in order to 693 obtain the data. 695 A.1.3 Metric Types 697 The following sections list some of the metrics, which can be used 698 for proximity calculations. 700 o Latency: Network latency measurements metrics are used to 701 determine the surrogate (or set of surrogates) that has the least 702 delay to the requesting entity. These measurements can be 703 obtained using either an active probing approach or a 704 passive network measurement system. 706 o Packet Loss: Packet loss measurements can be used as a selection 707 metric. A passive measurement approach can easily obtain packet 708 loss information from TCP header information. Active probing can 709 periodically measure packet loss from probes. 711 o Hop Counts: Router hops from the surrogate to the requesting 712 entity can be used as a proximity measurement. 714 o BGP Information: BGP AS PATH and MED attributes can be used to 715 determine the "BGP distance" to a given prefix/length pair. In 716 order to use BGP information for proximity measurements, it must 717 be obtained at each surrogate site/location. 719 A.1.4 Surrogate Feedback 721 In order to select a "least-loaded" delivery node. Feedback can be 722 delivered from each surrogate or can be aggregated by site or by 723 location. 725 A.1.4.1 Probing 727 Feedback information may be obtained by periodically probing a 728 surrogate by issuing an HTTP request and observing the behavior. The 729 problems with probing for surrogate information are: 731 o It is difficult to obtain "real-time" information. 733 o Non-real-time information may be inaccurate. 735 Consequently, feedback information can be obtained by agents that 736 reside on surrogates that can communicate a variety of metrics about 737 their nodes. 739 A.1.4.2 Well Known Metrics 741 The following provides a list of several of the popular metrics that 742 are used for surrogate feedback: 744 o Surrogate CPU Load. 746 o Interface Load/Dropped packets. 748 o Number of connections being served. 750 o Storage I/O Load. 752 Full Copyright Statement 754 Copyright (C) The Internet Society (2002). All Rights Reserved. 756 This document and translations of it may be copied and furnished to 757 others, and derivative works that comment on or otherwise explain it 758 or assist in its implementation may be prepared, copied, published 759 and distributed, in whole or in part, without restriction of any 760 kind, provided that the above copyright notice and this paragraph are 761 included on all such copies and derivative works. However, this 762 document itself may not be modified in any way, such as by removing 763 the copyright notice or references to the Internet Society or other 764 Internet organizations, except as needed for the purpose of 765 developing Internet standards in which case the procedures for 766 copyrights defined in the Internet Standards process must be 767 followed, or as required to translate it into languages other than 768 English. 770 The limited permissions granted above are perpetual and will not be 771 revoked by the Internet Society or its successors or assigns. 773 This document and the information contained herein is provided on an 774 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 775 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 776 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 777 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 778 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 780 Acknowledgement 782 Funding for the RFC Editor function is currently provided by the 783 Internet Society.