Network Working Group                                          A. Barbir
Request for Comments: 3568                               Nortel Networks
Category: Informational                                          B. Cain
                                                        Storigen Systems
                                                                 R. Nair
                                                           O. Spatscheck
                                                               July 2003
Network Working Group                                          A. Barbir
Request for Comments: 3568                               Nortel Networks
Category: Informational                                          B. Cain
                                                        Storigen Systems
                                                                 R. Nair
                                                           O. Spatscheck
                                                               July 2003

Known Content Network (CN) Request-Routing Mechanisms


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2003). All Rights Reserved.




This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
       2.1.  Single Reply . . . . . . . . . . . . . . . . . . . . . 3
       2.2.  Multiple Replies . . . . . . . . . . . . . . . . . . . 3
       2.3.  Multi-Level Resolution . . . . . . . . . . . . . . . . 4
             2.3.1.  NS Redirection . . . . . . . . . . . . . . . . 4
             2.3.2.  CNAME Redirection. . . . . . . . . . . . . . . 5
       2.4.  Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
       2.5.  Object Encoding. . . . . . . . . . . . . . . . . . . . 6
       2.6.  DNS Request-Routing Limitations. . . . . . . . . . . . 6
   3.  Transport-Layer Request-Routing  . . . . . . . . . . . . . . 7
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
       2.1.  Single Reply . . . . . . . . . . . . . . . . . . . . . 3
       2.2.  Multiple Replies . . . . . . . . . . . . . . . . . . . 3
       2.3.  Multi-Level Resolution . . . . . . . . . . . . . . . . 4
             2.3.1.  NS Redirection . . . . . . . . . . . . . . . . 4
             2.3.2.  CNAME Redirection. . . . . . . . . . . . . . . 5
       2.4.  Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
       2.5.  Object Encoding. . . . . . . . . . . . . . . . . . . . 6
       2.6.  DNS Request-Routing Limitations. . . . . . . . . . . . 6
   3.  Transport-Layer Request-Routing  . . . . . . . . . . . . . . 7
   4.  Application-Layer Request-Routing  . . . . . . . . . . . . . 8
       4.1.  Header Inspection. . . . . . . . . . . . . . . . . . . 8
             4.1.1.  URL-Based Request-Routing. . . . . . . . . . . 8
             4.1.2.  Header-Based Request-Routing . . . . . . . . . 9
             4.1.3.  Site-Specific Identifiers. . . . . . . . . . .10
       4.2.  Content Modification . . . . . . . . . . . . . . . . .10
             4.2.1.  A-priori URL Rewriting . . . . . . . . . . . .11
             4.2.2.  On-Demand URL Rewriting. . . . . . . . . . . .11
             4.2.3.  Content Modification Limitations . . . . . . .11
   5.  Combination of Multiple Mechanisms . . . . . . . . . . . . .11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . .12
   7.  Additional Authors and Acknowledgements  . . . . . . . . . .12
   A.  Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
       A.1.  Proximity Measurements . . . . . . . . . . . . . . . .13
             A.1.1.  Active Probing . . . . . . . . . . . . . . . .13
             A.1.2.  Metric Types . . . . . . . . . . . . . . . . .14
             A.1.3.  Surrogate Feedback . . . . . . . . . . . . . .14
   8.  Normative References . . . . . . . . . . . . . . . . . . . .15
   9.  Informative References . . . . . . . . . . . . . . . . . . .15
   10. Intellectual Property and Copyright Statements . . . . . . .17
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
   4.  Application-Layer Request-Routing  . . . . . . . . . . . . . 8
       4.1.  Header Inspection. . . . . . . . . . . . . . . . . . . 8
             4.1.1.  URL-Based Request-Routing. . . . . . . . . . . 8
             4.1.2.  Header-Based Request-Routing . . . . . . . . . 9
             4.1.3.  Site-Specific Identifiers. . . . . . . . . . .10
       4.2.  Content Modification . . . . . . . . . . . . . . . . .10
             4.2.1.  A-priori URL Rewriting . . . . . . . . . . . .11
             4.2.2.  On-Demand URL Rewriting. . . . . . . . . . . .11
             4.2.3.  Content Modification Limitations . . . . . . .11
   5.  Combination of Multiple Mechanisms . . . . . . . . . . . . .11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . .12
   7.  Additional Authors and Acknowledgements  . . . . . . . . . .12
   A.  Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
       A.1.  Proximity Measurements . . . . . . . . . . . . . . . .13
             A.1.1.  Active Probing . . . . . . . . . . . . . . . .13
             A.1.2.  Metric Types . . . . . . . . . . . . . . . . .14
             A.1.3.  Surrogate Feedback . . . . . . . . . . . . . .14
   8.  Normative References . . . . . . . . . . . . . . . . . . . .15
   9.  Informative References . . . . . . . . . . . . . . . . . . .15
   10. Intellectual Property and Copyright Statements . . . . . . .17
   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
1. Introduction
1. 介绍

This document provides a summary of known request routing techniques that are used by the industry before December 2000. Request routing techniques are generally used to direct client requests to surrogates based on various policies and a possible set of metrics. The task of directing clients' requests to surrogates is also called Request-Routing, Content Routing or Content Redirection.


Request-Routing techniques are commonly used in Content Networks (also known as Content Delivery Networks) [8]. Content Networks include network infrastructure that exists in layers 4 through 7. Content Networks deal with the routing and forwarding of requests and responses for content. Content Networks rely on layer 7 protocols such as HTTP [4] for transport.


Request-Routing techniques are generally used to direct client requests for objects to a surrogate or a set of surrogates that could best serve that content. Request-Routing mechanisms could be used to direct client requests to surrogates that are within a Content Network (CN) [8].


Request-Routing techniques are used as a vehicle to extend the reach and scale of Content Delivery Networks. There exist multiple Request-Routing mechanisms. At a high-level, these may be classified under: DNS Request-Routing, transport-layer Request-Routing, and application-layer Request-Routing.


A request routing system uses a set of metrics in an attempt to direct users to surrogate that can best serve the request. For example, the choice of the surrogate could be based on network proximity, bandwidth availability, surrogate load and availability of content. Appendix A provides a summary of metrics and measurement techniques that could be used in the selection of the best surrogate.


The memo is organized as follows: Section 2 provides a summary of known DNS based Request-Routing techniques. Section 3 discusses transport-layer Request-Routing methods. In section 4 application layer Request-Routing mechanisms are explored. Section 5 provides insight on combining the various methods that were discussed in the earlier sections in order to optimize the performance of the Request-Routing System. Appendix A provides a summary of possible metrics and measurements techniques that could be used by the Request-Routing system to choose a given surrogate.


2. DNS based Request-Routing Mechanisms
2. 基于DNS的请求路由机制

DNS based Request-Routing techniques are common due to the ubiquity of the DNS system [10][12][13]. In DNS based Request-Routing techniques, a specialized DNS server is inserted in the DNS resolution process. The server is capable of returning a different set of A, NS or CNAME records based on user defined policies, metrics, or a combination of both. In [11] RFC 2782 (DNS SRV) provides guidance on the use of DNS for load balancing. The RFC describes some of the limitations and suggests appropriate useage of DNS based techniques. The next sections provides a summary of some of the used techniques.

由于DNS系统的普遍性,基于DNS的请求路由技术很常见[10][12][13]。在基于DNS的请求路由技术中,在DNS解析过程中插入专门的DNS服务器。服务器能够根据用户定义的策略、度量或两者的组合返回一组不同的a、NS或CNAME记录。在[11]中,RFC 2782(DNS SRV)提供了使用DNS进行负载平衡的指南。RFC描述了一些限制,并建议适当使用基于DNS的技术。下一节将总结一些使用的技术。

2.1. Single Reply
2.1. 单一答复

In this approach, the DNS server is authoritative for the entire DNS domain or a sub domain. The DNS server returns the IP address of the best surrogate in an A record to the requesting DNS server. The IP address of the surrogate could also be a virtual IP(VIP) address of the best set of surrogates for requesting DNS server.


2.2. Multiple Replies
2.2. 多个答复

In this approach, the Request-Routing DNS server returns multiple replies such as several A records for various surrogates. Common implementations of client site DNS server's cycles through the multiple replies in a Round-Robin fashion. The order in which the records are returned can be used to direct multiple clients using a single client site DNS server.


2.3. Multi-Level Resolution
2.3. 多级分辨率

In this approach multiple Request-Routing DNS servers can be involved in a single DNS resolution. The rationale of utilizing multiple Request-Routing DNS servers in a single DNS resolution is to allow one to distribute more complex decisions from a single server to multiple, more specialized, Request-Routing DNS servers. The most common mechanisms used to insert multiple Request-Routing DNS servers in a single DNS resolution is the use of NS and CNAME records. An example would be the case where a higher level DNS server operates within a territory, directing the DNS lookup to a more specific DNS server within that territory to provide a more accurate resolution.


2.3.1. NS Redirection
2.3.1. NS重定向

A DNS server can use NS records to redirect the authority of the next level domain to another Request-Routing DNS server. The, technique allows multiple DNS server to be involved in the name resolution process. For example, a client site DNS server resolving [10] would eventually request a resolution of from the name server authoritative for The name server authoritative for this domain might be a Request-Routing NS server. In this case the Request-Routing DNS server can either return a set of A records or can redirect the resolution of the request to the DNS server that is authoritative for using NS records.


One drawback of using NS records is that the number of Request-Routing DNS servers are limited by the number of parts in the DNS name. This problem results from DNS policy that causes a client site DNS server to abandon a request if no additional parts of the DNS name are resolved in an exchange with an authoritative DNS server.


A second drawback is that the last DNS server can determine the TTL of the entire resolution process. Basically, the last DNS server can return in the authoritative section of its response its own NS record. The client will use this cached NS record for further request resolutions until it expires.


Another drawback is that some implementations of bind voluntarily cause timeouts to simplify their implementation in cases in which a NS level redirect points to a name server for which no valid A record is returned or cached. This is especially a problem if the domain of the name server does not match the domain currently resolved, since in this case the A records, which might be passed in the DNS response, are discarded for security reasons. Another drawback is the added delay in resolving the request due to the use of multiple DNS servers.


2.3.2. CNAME Redirection
2.3.2. CNAME重定向

In this scenario, the Request-Routing DNS server returns a CNAME record to direct resolution to an entirely new domain. In principle, the new domain might employ a new set of Request-Routing DNS servers.


One disadvantage of this approach is the additional overhead of resolving the new domain name. The main advantage of this approach is that the number of Request-Routing DNS servers is independent of the format of the domain name.


2.4. Anycast
2.4. 选播

Anycast [5] is an inter-network service that is applicable to networking situations where a host, application, or user wishes to locate a host which supports a particular service but, if several servers utilizes the service, it does not particularly care which server is used. In an anycast service, a host transmits a datagram to an anycast address and the inter-network is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.


The motivation for anycast is that it considerably simplifies the task of finding an appropriate server. For example, users, instead of consulting a list of servers and choosing the closest one, could simply type the name of the server and be connected to the nearest one. By using anycast, DNS resolvers would no longer have to be configured with the IP addresses of their servers, but rather could send a query to a well-known DNS anycast address.


Furthermore, to combine measurement and redirection, the Request-Routing DNS server can advertise an anycast address as its IP address. The same address is used by multiple physical DNS servers. In this scenario, the Request-Routing DNS server that is the closest to the client site DNS server in terms of OSPF and BGP routing will receive the packet containing the DNS resolution request. The server can use this information to make a Request-Routing decision.


Drawbacks of this approach are listed below:


o The DNS server may not be the closest server in terms of routing to the client.

o 就到客户端的路由而言,DNS服务器可能不是最近的服务器。

o Typically, routing protocols are not load sensitive. Hence, the closest server may not be the one with the least network latency.

o 通常,路由协议对负载不敏感。因此,最近的服务器可能不是网络延迟最少的服务器。

o The server load is not considered during the Request-Routing process.

o 在请求路由过程中不考虑服务器负载。

2.5. Object Encoding
2.5. 对象编码

Since only DNS names are visible during the DNS Request-Routing, some solutions encode the object type, object hash, or similar information into the DNS name. This might vary from a simple division of objects based on object type (such as and to a sophisticated schema in which the domain name contains a unique identifier (such as a hash) of the object. The obvious advantage is that object information is available at resolution time. The disadvantage is that the client site DNS server has to perform multiple resolutions to retrieve a single Web page, which might increase rather than decrease the overall latency.


2.6. DNS Request-Routing Limitations
2.6. DNS请求路由限制

This section lists some of the limitations of DNS based Request-Routing techniques.


o DNS only allows resolution at the domain level. However, an ideal request resolution system should service requests per object level.

o DNS仅允许在域级别进行解析。然而,理想的请求解析系统应该为每个对象级别的请求提供服务。

o In DNS based Request-Routing systems servers may be required to return DNS entries with a short time-to-live (TTL) values. This may be needed in order to be able to react quickly in the face of outages. This in return may increase the volume of requests to DNS servers.

o 在基于DNS的请求路由系统中,服务器可能需要返回具有短生存时间(TTL)值的DNS条目。这可能是必要的,以便能够在面临停机时快速作出反应。这反过来可能会增加对DNS服务器的请求量。

o Some DNS implementations do not always adhere to DNS standards. For example, many DNS implementations do not honor the DNS TTL field.

o 某些DNS实现并不总是遵循DNS标准。例如,许多DNS实现不支持DNS TTL字段。

o DNS Request-Routing is based only on knowledge of the client DNS server, as client addresses are not relayed within DNS requests. This limits the ability of the Request-Routing system to determine a client's proximity to the surrogate.

o DNS请求路由仅基于客户端DNS服务器的知识,因为客户端地址不会在DNS请求中中继。这限制了请求路由系统确定客户端与代理的接近程度的能力。

o DNS servers can request and allow recursive resolution of DNS names. For recursive resolution of requests, the Request-Routing DNS server will not be exposed to the IP address of the client's site DNS server. In this case, the Request-Routing DNS server will be exposed to the address of the DNS server that is recursively requesting the information on behalf of the client's site DNS server. For example, might be resolved by a CN, but the request for the resolution might come from as a result of the recursion.

o DNS服务器可以请求并允许递归解析DNS名称。对于请求的递归解析,请求路由DNS服务器将不会暴露于客户端站点DNS服务器的IP地址。在这种情况下,请求路由DNS服务器将暴露于代表客户端的站点DNS服务器递归请求信息的DNS服务器的地址。例如,imgs.example.com可能由CN解析,但由于递归,解析请求可能来自。

o Users that share a single client site DNS server will be redirected to the same set of IP addresses during the TTL interval. This might lead to overloading of the surrogate during a flash crowd.

o 共享单个客户端站点DNS服务器的用户将在TTL间隔期间重定向到同一组IP地址。这可能会导致在flash群组中代理项过载。

o Some implementations of bind can cause DNS timeouts to occur while handling exceptional situations. For example, timeouts can occur for NS redirections to unknown domains.

o bind的某些实现在处理异常情况时会导致DNS超时。例如,NS重定向到未知域时可能会发生超时。

DNS based request routing techniques can suffer from serious limitations. For example, the use of such techniques can overburden third party DNS servers, which should not be allowed [19]. In [11] RFC 2782 provides warnings on the use of DNS for load balancing. Readers are encouraged to read the RFC for better understanding of the limitations.

基于DNS的请求路由技术可能受到严重限制。例如,使用此类技术可能会使第三方DNS服务器负担过重,这是不允许的[19]。在[11]中,RFC 2782提供了关于使用DNS进行负载平衡的警告。鼓励读者阅读RFC,以便更好地理解其局限性。

3. Transport-Layer Request-Routing
3. 传输层请求路由

At the transport-layer finer levels of granularity can be achieved by the close inspection of client's requests. In this approach, the Request-Routing system inspects the information available in the first packet of the client's request to make surrogate selection decisions. The inspection of the client's requests provides data about the client's IP address, port information, and layer 4 protocol. The acquired data could be used in combination with user-defined policies and other metrics to determine the selection of a surrogate that is better suited to serve the request. The techniques [20][18][15] are used to hand off the session to a more appropriate surrogate are beyond the scope of this document.


In general, the forward-flow traffic (client to newly selected surrogate) will flow through the surrogate originally chosen by DNS. The reverse-flow (surrogate to client) traffic, which normally transfers much more data than the forward flow, would typically take the direct path.


The overhead associated with transport-layer Request-Routing [21][19] is better suited for long-lived sessions such as FTP [1] and RTSP [3]. However, it also could be used to direct clients away from overloaded surrogates.


In general, transport-layer Request-Routing can be combined with DNS based techniques. As stated earlier, DNS based methods resolve clients requests based on domains or sub domains with exposure to the client's DNS server IP address. Hence, the DNS based methods could be used as a first step in deciding on an appropriate surrogate with more accurate refinement made by the transport-layer Request-Routing system.


4. Application-Layer Request-Routing
4. 应用层请求路由

Application-layer Request-Routing systems perform deeper examination of client's packets beyond the transport layer header. Deeper examination of client's packets provides fine-grained Request-Routing control down to the level of individual objects. The process could be performed in real time at the time of the object request. The exposure to the client's IP address combined with the fine-grained knowledge of the requested objects enable application-layer Request-Routing systems to provide better control over the selection of the best surrogate.


4.1. Header Inspection
4.1. 收割台检查

Some application level protocols such as HTTP [4], RTSP [3], and SSL [2] provide hints in the initial portion of the session about how the client request must be directed. These hints may come from the URL of the content or other parts of the MIME request header such as Cookies.


4.1.1. URL-Based Request-Routing
4.1.1. 基于URL的请求路由

Application level protocols such as HTTP and RTSP describe the requested content by its URL [6]. In many cases, this information is sufficient to disambiguate the content and suitably direct the request. In most cases, it may be sufficient to make Request-Routing decision just by examining the prefix or suffix of the URL.

HTTP和RTSP等应用程序级协议通过其URL描述请求的内容[6]。在许多情况下,这些信息足以消除内容的歧义并适当地引导请求。在大多数情况下,仅通过检查URL的前缀或后缀就可以做出请求路由决定。 302 Redirection 302重定向

In this approach, the client's request is first resolved to a virtual surrogate. Consequently, the surrogate returns an application-specific code such as the 302 (in the case of HTTP [4] or RTSP [3]) to redirect the client to the actual delivery node.


This technique is relatively simple to implement. However, the main drawback of this method is the additional latency involved in sending the redirect message back to the client.

这项技术实现起来相对简单。但是,此方法的主要缺点是将重定向消息发送回客户端时会增加延迟。 In-Path Element 路径内元素

In this technique, an In-Path element is present in the network in the forwarding path of the client's request. The In-Path element provides transparent interception of the transport connection. The In-Path element examines the client's content requests and performs Request-Routing decisions.


The In-Path element then splices the client connection to a connection with the appropriate delivery node and passes along the content request. In general, the return path would go through the In-Path element. However, it is possible to arrange for a direct return by passing the address translation information to the surrogate or delivery node through some proprietary means.


The primary disadvantage with this method is the performance implications of URL-parsing in the path of the network traffic. However, it is generally the case that the return traffic is much larger than the forward traffic.


The technique allows for the possibility of partitioning the traffic among a set of delivery nodes by content objects identified by URLs. This allows object-specific control of server loading. For example, requests for non-cacheable object types may be directed away from a cache.


4.1.2. Header-Based Request-Routing
4.1.2. 基于报头的请求路由

This technique involves the task of using HTTP [4] such as Cookie, Language, and User-Agent, in order to select a surrogate. In [20] some examples of using this technique are provided.


Cookies can be used to identify a customer or session by a web site. Cookie based Request-Routing provides content service differentiation based on the client. This approach works provided that the cookies belong to the client. In addition, it is possible to direct a connection from a multi-session transaction to the same server to achieve session-level persistence.


The language header can be used to direct traffic to a language-specific delivery node. The user-agent header helps identify the type of client device. For example, a voice-browser, PDA, or cell phone can indicate the type of delivery node that has content specialized to handle the content request.


4.1.3. Site-Specific Identifiers
4.1.3. 站点特定标识符

Site-specific identifiers help authenticate and identify a session from a specific user. This information may be used to direct a content request.


An example of a site-specific identifier is the SSL Session Identifier. This identifier is generated by a web server and used by the web client in succeeding sessions to identify itself and avoid an entire security authentication exchange. In order to inspect the session identifier, an In-Path element would observe the responses of the web server and determine the session identifier which is then used to associate the session to a specific server. The remaining sessions are directed based on the stored session identifier.


4.2. Content Modification
4.2. 内容修改

This technique enables a content provider to take direct control over Request-Routing decisions without the need for specific witching devices or directory services in the path between the client and the origin server. Basically, a content provider can directly communicate to the client the best surrogate that can serve the request. Decisions about the best surrogate can be made on a per-object basis or it can depend on a set of metrics. The overall goal is to improve scalability and the performance for delivering the modified content, including all embedded objects.


In general, the method takes advantage of content objects that consist of basic structure that includes references to additional, embedded objects. For example, most web pages, consist of an HTML document that contains plain text together with some embedded objects, such as GIF or JPEG images. The embedded objects are referenced using embedded HTML directives. In general, embedded HTML directives direct the client to retrieve the embedded objects from the origin server. A content provider can now modify references to embedded objects such that they could be fetched from the best surrogate. This technique is also known as URL rewriting.


Content modification techniques must not violate the architectural concepts of the Internet [9]. Special considerations must be made to ensure that the task of modifying the content is performed in a manner that is consistent with RFC 3238 [9] that specifies the architectural considerations for intermediaries that perform operations or modifications on content.

内容修改技术不得违反互联网的体系结构概念[9]。必须特别注意确保修改内容的任务以与RFC 3238[9]一致的方式执行,RFC 3238[9]规定了对内容执行操作或修改的中介机构的体系结构注意事项。

The basic types of URL rewriting are discussed in the following subsections.


4.2.1. A-priori URL Rewriting
4.2.1. 先验URL重写

In this scheme, a content provider rewrites the embedded URLs before the content is positioned on the origin server. In this case, URL rewriting can be done either manually or by using software tools that parse the content and replace embedded URLs.


A-priori URL rewriting alone does not allow consideration of client specifics for Request-Routing. However, it can be used in combination with DNS Request-Routing to direct related DNS queries into the domain name space of the service provider. Dynamic Request-Routing based on client specifics are then done using the DNS approach.


4.2.2. On-Demand URL Rewriting
4.2.2. 按需URL重写

On-Demand or dynamic URL rewriting, modifies the content when the client request reaches the origin server. At this time, the identity of the client is known and can be considered when rewriting the embedded URLs. In particular, an automated process can determine, on-demand, which surrogate would serve the requesting client best. The embedded URLs can then be rewritten to direct the client to retrieve the objects from the best surrogate rather than from the origin server.


4.2.3. Content Modification Limitations
4.2.3. 内容修改限制

Content modification as a Request-Routing mechanism suffers from many limitation [23]. For example:


o The first request from a client to a specific site must be served from the origin server.

o 从客户端到特定站点的第一个请求必须由源服务器提供。

o Content that has been modified to include references to nearby surrogates rather than to the origin server should be marked as non-cacheable. Alternatively, such pages can be marked to be cacheable only for a relatively short period of time. Rewritten URLs on cached pages can cause problems, because they can get outdated and point to surrogates that are no longer available or no longer good choices.

o 已修改为包含对附近代理的引用而不是对源服务器的引用的内容应标记为不可缓存。或者,可以将此类页面标记为仅在相对较短的时间段内可缓存。缓存页面上重写的URL可能会导致问题,因为它们可能会过时,并指向不再可用或不再是好选择的代理。

5. Combination of Multiple Mechanisms
5. 多种机制的组合

There are environments in which a combination of different mechanisms can be beneficial and advantageous over using one of the proposed mechanisms alone. The following example illustrates how the mechanisms can be used in combination.


A basic problem of DNS Request-Routing is the resolution granularity that allows resolution on a per-domain level only. A per-object redirection cannot easily be achieved. However, content modification can be used together with DNS Request-Routing to overcome this problem. With content modification, references to different objects on the same origin server can be rewritten to point into different domain name spaces. Using DNS Request-Routing, requests for those objects can now dynamically be directed to different surrogates.


6. Security Considerations
6. 安全考虑

The main objective of this document is to provide a summary of current Request-Routing techniques. Such techniques are currently implemented in the Internet. However, security must be addressed by any entity that implements any technique that redirects client's requests. In [9] RFC 3238 addresses the main requirements for entities that intend to modify requests for content in the Internet.

本文档的主要目的是总结当前的请求路由技术。这些技术目前在互联网上实施。然而,任何实现重定向客户端请求的技术的实体都必须解决安全问题。在[9]中,RFC 3238解决了打算修改互联网内容请求的实体的主要要求。

Some active probing techniques will set off intrusion detection systems and firewalls. Therefore, it is recommended that implementers be aware of routing protocol security [25].


It is important to note the impact of TLS [2] on request routing in CNs. Specifically, when TLS is used the full URL is not visible to the content network unless it terminates the TLS session. The current document focuses on HTTP techniques. TLS based techniques that require the termination of TLS sessions on Content Peering Gateways [8] are beyond the of scope of this document.


The details of security techniques are also beyond the scope of this document.


7. Additional Authors and Acknowledgements
7. 其他作者和致谢

The following people have contributed to the task of authoring this document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann (Lucent), Doug Potter.


The authors acknowledge the contributions and comments of Ian Cooper, Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).

作者感谢Ian Cooper、Nalin Mistry(北电)、Wayne Ding(北电)和Eric Dean(CrystalBall)的贡献和评论。

Appendix A. Measurements

Request-Routing systems can use a variety of metrics in order to determine the best surrogate that can serve a client's request. In general, these metrics are based on network measurements and feedback from surrogates. It is possible to combine multiple metrics using both proximity and surrogate feedback for best surrogate selection. The following sections describe several well known metrics as well as the major techniques for obtaining them.


A.1. Proximity Measurements
A.1. 邻近测量

Proximity measurements can be used by the Request-Routing system to direct users to the "closest" surrogate. In this document proximity means round-trip time. In a DNS Request-Routing system, the measurements are made to the client's local DNS server. However, when the IP address of the client is accessible more accurate proximity measurements can be obtained [24].


Proximity measurements can be exchanged between surrogates and the requesting entity. In many cases, proximity measurements are "one-way" in that they measure either the forward or reverse path of packets from the surrogate to the requesting entity. This is important as many paths in the Internet are asymmetric [24].


In order to obtain a set of proximity measurements, a network may employ active probing techniques.


A.1.1. Active Probing
A.1.1. 主动探测

Active probing is when past or possible requesting entities are probed using one or more techniques to determine one or more metrics from each surrogate or set of surrogates. An example of a probing technique is an ICMP ECHO Request that is periodically sent from each surrogate or set of surrogates to a potential requesting entity.


In any active probing approach, a list of potential requesting entities need to be obtained. This list can be generated dynamically. Here, as requests arrive, the requesting entity addresses can be cached for later probing. Another potential solution is to use an algorithm to divide address space into blocks and to probe random addresses within those blocks. Limitations of active probing techniques include:


o Measurements can only be taken periodically.

o 只能定期进行测量。

o Firewalls and NATs disallow probes.

o 防火墙和NAT不允许探测。

o Probes often cause security alarms to be triggered on intrusion detection systems.

o 探测器通常会在入侵检测系统上触发安全警报。

A.1.2. Metric Types
A.1.2. 公制类型

The following sections list some of the metrics, which can be used for proximity calculations.


o Latency: Network latency measurements metrics are used to determine the surrogate (or set of surrogates) that has the least delay to the requesting entity. These measurements can be obtained using active probing techniques.

o 延迟:网络延迟测量指标用于确定对请求实体具有最小延迟的代理项(或代理项集)。可以使用主动探测技术获得这些测量值。

o Hop Counts: Router hops from the surrogate to the requesting entity can be used as a proximity measurement.

o 跃点计数:从代理到请求实体的路由器跃点可以用作接近度测量。

o BGP Information: BGP AS PATH and MED attributes can be used to determine the "BGP distance" to a given prefix/length pair. In order to use BGP information for proximity measurements, it must be obtained at each surrogate site/location.

o BGP信息:BGP AS PATH和MED属性可用于确定到给定前缀/长度对的“BGP距离”。为了使用BGP信息进行近程测量,必须在每个代理站点/位置获取BGP信息。

It is important to note that the value of BGP AS PATH information can be meaningless as a good selection metric [24].


A.1.3. Surrogate Feedback
A.1.3. 代理反馈

In order to select a "least-loaded" delivery node. Feedback can be delivered from each surrogate or can be aggregated by site or by location.


A.1.3.1. Probing
A.1.3.1. 探查

Feedback information may be obtained by periodically probing a surrogate by issuing an HTTP request and observing the behavior. The problems with probing for surrogate information are:


o It is difficult to obtain "real-time" information.

o 很难获得“实时”信息。

o Non-real-time information may be inaccurate.

o 非实时信息可能不准确。

Consequently, feedback information can be obtained by agents that reside on surrogates that can communicate a variety of metrics about their nodes.


8. Normative References
8. 规范性引用文件

[1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.

[1] Postel,J.和J.Reynolds,“文件传输协议”,标准9,RFC 959,1985年10月。

[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246, January 1999.

[2] Dierks,T.和C.Allen,“TLS协议版本1”,RFC 2246,1999年1月。

[3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998.

[3] Schulzrinne,H.,Rao,A.和R.Lanphier,“实时流协议”,RFC2326,1998年4月。

[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[4] 菲尔丁,R.,盖蒂斯,J.,莫卧儿,J.,弗莱斯蒂克,H.,马斯特,L.,利奇,P.和T.伯纳斯李,“超文本传输协议——HTTP/1.1”,RFC2616,1999年6月。

[5] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.

[5] 帕特里奇,C.,门德斯,T.和W.米利肯,“主持任意广播服务”,RFC15461993年11月。

[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[6] Berners Lee,T.,Masinter,L.和M.McCahill,“统一资源定位器(URL)”,RFC 17381994年12月。

[7] Schulzrinne, H., Casner, S., Federick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.

[7] Schulzrinne,H.,Casner,S.,Federick,R.和V.Jacobson,“RTP:实时应用的传输协议”,RFC 1889,1996年1月。

[8] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.

[8] Day,M.,Cain,B.,Tomlinson,G.和P.Rzewski,“内容互联网(CDI)模型”,RFC 3466,2003年2月。

[9] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

[9] Floyd,S.和L.Daigle,“开放可插拔边缘服务的IAB架构和政策考虑”,RFC 3238,2002年1月。

9. Informative References
9. 资料性引用

[10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[10] Eastlake,D.和A,Panitz,“保留顶级DNS名称”,BCP 32,RFC 26061999年6月。

[11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2002.

[11] Gulbrandsen,A.,Vixie,P.和L.Esibov,“用于指定服务位置(DNS SRV)的DNS RR”,RFC 2782,2002年2月。

[12] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[12] Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,1987年11月。

[13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1035, November 1987.

[13] Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 10351987年11月。

[14] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[14] Elz,R.和R.Bush,“DNS规范的澄清”,RFC 21811997年7月。

[15] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.

[15] Awduche,D.,Chiu,A.,Elwalid,A.,Widjaja,I.和X.Xiao,“互联网流量工程概述和原则”,RFC 3272,2002年5月。

[16] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.

[16] Crawley,E.,Nair,R.,Rajagopalan,B.和H.Sandick,“互联网中基于QoS的路由框架”,RFC 2386,1998年8月。

[17] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.

[17] Huston,G.“因特网域间路由评论”,RFC 3221,2001年12月。

[18] M. Welsh et al., "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services", Proceedings of the Eighteenth Symposium on Operating Systems Principles (SOSP-18) 2001, October 2001.

[18] M.Welsh等人,“SEDA:条件良好、可扩展互联网服务的体系结构”,第十八届操作系统原理研讨会论文集(SOSP-18),2001年10月。

[19] A. Shaikh, "On the effectiveness of DNS-based Server Selection", INFOCOM 2001, August 2001.

[19] A.Shaikh,“基于DNS的服务器选择的有效性”,INFOCOM 2001年,2001年8月。

[20] C. Yang et al., "An effective mechanism for supporting content-based routing in scalable Web server clusters", Proc. International Workshops on Parallel Processing 1999, September 1999.

[20] C.Yang等人,“在可扩展Web服务器集群中支持基于内容路由的有效机制”,Proc。1999年并行处理国际讲习班,1999年9月。

[21] R. Liston et al., "Using a Proxy to Measure Client-Side Web Performance", Proceedings of the Sixth International Web Content Caching and Distribution Workshop (WCW'01) 2001, August 2001.

[21] R.Liston等人,“使用代理测量客户端Web性能”,2001年第六届国际Web内容缓存和分发研讨会(WCW'01)论文集,2001年8月。

[22] W. Jiang et al., "Modeling of packet loss and delay and their effect on real-time multimedia service quality", Proceedings of NOSSDAV 2000, June 2000.

[22] 蒋文华等,“数据包丢失和延迟的建模及其对实时多媒体服务质量的影响”,《NOSSDAV 2000年学报》,2000年6月。

[23] K. Johnson et al., "The measured performance of content distribution networks", Proceedings of the Fifth International Web Caching Workshop and Content Delivery Workshop 2000, May 2000.

[23] K.Johnson等人,“内容分发网络的测量性能”,2000年第五届国际网络缓存研讨会和内容交付研讨会论文集,2000年5月。

[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM Transactions 1999, June 1999.

[24] V.Paxson,“端到端互联网数据包动态”,IEEE/ACM交易1999年,1999年6月。

[25] F. Wang et al., "Secure routing protocols: Theory and Practice", Technical report, North Carolina State University 1997, May 1997.

[25] F.Wang等人,“安全路由协议:理论与实践”,技术报告,北卡罗来纳州立大学,1997年,1997年5月。

10. Intellectual Property Statement
10. 知识产权声明

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.


11. Authors' Addresses
11. 作者地址

Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada

加拿大安大略省内皮恩卡林大道3500号北电网络有限公司K2H 8E9

   Phone: +1 613 763 5229
   Phone: +1 613 763 5229

Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854 USA

美国马萨诸塞州洛厄尔萨福克街650号Brad Cain Storigen Systems 01854

   Phone: +1 978-323-4454
   Phone: +1 978-323-4454

Raj Nair 6 Burroughs Rd Lexington, MA 02420 USA



Oliver Spatscheck AT&T 180 Park Ave, Bldg 103 Florham Park, NJ 07932 USA


12. Full Copyright Statement
12. 完整版权声明

Copyright (C) The Internet Society (2003). All Rights Reserved.


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.






Funding for the RFC Editor function is currently provided by the Internet Society.