--- 1/draft-ietf-cdi-known-request-routing-00.txt 2007-12-18 18:42:17.000000000 +0100 +++ 2/draft-ietf-cdi-known-request-routing-01.txt 2007-12-18 18:42:18.000000000 +0100 @@ -1,30 +1,30 @@ Network Working Group A. Barbir Internet-Draft Nortel Networks -Expires: August 22, 2002 B. Cain - Cereva Networks +Expires: November 8, 2002 B. Cain + Storigen Systems F. Douglis - AT&T Labs + IBM Research M. Green CacheFlow M. Hofmann Lucent R. Nair D. Potter Cisco O. Spatscheck AT&T Labs - February 22, 2002 + May 8, 2002 Known CN Request-Routing Mechanisms - draft-ietf-cdi-known-request-routing-00.txt + draft-ietf-cdi-known-request-routing-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -33,21 +33,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. -This Internet-Draft will expire on August 22, 2002. +This Internet-Draft will expire on November 08, 2002. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The work 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. In this memo the term @@ -66,21 +66,21 @@ 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.1.1 302 Redirection .............................................9 +4.1.1.1 302 Redirection .............................................8 4.1.1.2 In-Path Element .............................................9 4.1.2 Mime Header-Based Request-Routing ...........................9 4.1.3 Site-Specific Identifiers ...................................10 4.2 Content Modification ........................................10 4.2.1 A-priori URL Rewriting ......................................10 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. Acknowledgements ............................................12 @@ -101,21 +101,21 @@ could be 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)[5]. 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] OR RTP [8] for transport. + 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) [5]. 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 @@ -366,41 +366,30 @@ 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 - Applications 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. + 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 - A Uniform Resource Locator (URL) [7] consists of a naming scheme - followed by a string whose format is a function of the naming - scheme. The string must start with a constant prefix "URL:". - Within the URL of a object, the first element is the name of the - scheme, separated from the rest of the object by a colon. The rest - of the URL follows the colon in a format depending on the scheme. - For example, an FTP URL may optionally specify the FTP data transfer - type by which an object is to be retrieved. Most of the methods - correspond to the FTP Data Types such as ASCII and IMAGE for the - retrieval of a document, as specified in FTP by the "TYPE" Command. - The data type is specified by a suffix to the URL. - - In a similar fashion, HTTP and RTSP content requests describe the - requested content by its URL. In many cases, this information + Application level protocols such as HTTP and RTSP describe the + requested content by its URL [7]. 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. 4.1.1.1 302 Redirection 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 @@ -423,21 +412,21 @@ 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 portioning the 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 Mime Header-Based Request-Routing This technique involves the task of using MIME-headers such as Cookie, Language, and User-Agent, in order to select a surrogate. @@ -557,68 +546,67 @@ The main objective of this document is to provide a summary of current Request-Routing techniques. Such techniques are currently implemented in the Internet. The document acknowledges that security must be addressed by any entity that implements any technique that redirects client's requests. However, the details of such techniques are beyond the scope of this document. 7. Acknowledgements - The authors acknowledge the contributions and comments of Ian Cooper - (Equinix), Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean - (CrystalBall). + The authors acknowledge the contributions and comments of Ian Cooper, + Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall). 8. References [1] Postel, J., "File Transfer Protocol", RFC 765, June 1980, [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC - 2246, January 1999. + 846, January 1999. [3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998. [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. [5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content Internetworking (CDI)", http://www.ietf.org/internet-drafts/ - draft-day-cdnp-model-09.txt (Group Last Call). + draft-ietf-cdi-model-02.txt (Group Last Call). [6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting Service", RFC 1546, November 1993. [7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource - Locator (URL), RFC 1738,May 1994. + Locators (URL)", RFC 1738,May 1994. [8] H. Schulzrinne, H., Fokus, G., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. 9. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada EMail: abbieb@nortelnetworks.com Brad Cain - Cereva Networks - EMail: bcain@cereva.com + Storigen Systems + 650 Suffolk Street + Lowell, MA 01854 US + Phone: +1 978-323-4454 + EMail: bcain@storigen.com Fred Douglis - AT&T Labs - Room B137 - 180 Park Ave, Bldg 103 - Florham Park, NJ 07932, US - EMail: douglis@research.att.com + IBM Research + EMail: fdouglis@us.ibm.com Mark Green CacheFlow 650 Almanor Avenue Sunnyvale, CA 94085, US EMail: markg@cacheflow.com Markus Hofmann Lucent Technologies Room 4F-513