draft-ietf-cdi-known-request-routing-00.txt   draft-ietf-cdi-known-request-routing-01.txt 
Network Working Group A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: August 22, 2002 B. Cain Expires: November 8, 2002 B. Cain
Cereva Networks Storigen Systems
F. Douglis F. Douglis
AT&T Labs IBM Research
M. Green M. Green
CacheFlow CacheFlow
M. Hofmann M. Hofmann
Lucent Lucent
R. Nair R. Nair
D. Potter D. Potter
Cisco Cisco
O. Spatscheck O. Spatscheck
AT&T Labs AT&T Labs
February 22, 2002 May 8, 2002
Known CN Request-Routing Mechanisms 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 Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
The work presents a summary of Request-Routing techniques that are The work presents a summary of Request-Routing techniques that are
used to direct client requests to surrogates based on various used to direct client requests to surrogates based on various
policies and a possible set of metrics. In this memo the term policies and a possible set of metrics. In this memo the term
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2.3 Multi-Level Resolution ......................................4 2.3 Multi-Level Resolution ......................................4
2.3.1 NS Redirection ..............................................4 2.3.1 NS Redirection ..............................................4
2.3.2 CNAME Redirection ...........................................5 2.3.2 CNAME Redirection ...........................................5
2.4 Anycast .....................................................5 2.4 Anycast .....................................................5
2.5 Object Encoding .............................................6 2.5 Object Encoding .............................................6
2.6 DNS Request-Routing Limitations .............................6 2.6 DNS Request-Routing Limitations .............................6
3. Transport-Layer Request-Routing .............................7 3. Transport-Layer Request-Routing .............................7
4. Application-Layer Request-Routing ...........................8 4. Application-Layer Request-Routing ...........................8
4.1 Header Inspection ...........................................8 4.1 Header Inspection ...........................................8
4.1.1 URL-Based Request-Routing ...................................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.1.2 In-Path Element .............................................9
4.1.2 Mime Header-Based Request-Routing ...........................9 4.1.2 Mime Header-Based Request-Routing ...........................9
4.1.3 Site-Specific Identifiers ...................................10 4.1.3 Site-Specific Identifiers ...................................10
4.2 Content Modification ........................................10 4.2 Content Modification ........................................10
4.2.1 A-priori URL Rewriting ......................................10 4.2.1 A-priori URL Rewriting ......................................10
4.2.2 On-Demand URL Rewriting .....................................11 4.2.2 On-Demand URL Rewriting .....................................11
4.2.3 Content Modification Limitations ............................11 4.2.3 Content Modification Limitations ............................11
5. Combination of Multiple Mechanisms ..........................11 5. Combination of Multiple Mechanisms ..........................11
6. Security Considerations .....................................12 6. Security Considerations .....................................12
7. Acknowledgements ............................................12 7. Acknowledgements ............................................12
skipping to change at page 3, line 18 skipping to change at page 3, line 18
could be used to direct client requests to surrogates based on could be used to direct client requests to surrogates based on
various policies and a possible set of metrics. The task of various policies and a possible set of metrics. The task of
directing clients' requests to surrogates is also called directing clients' requests to surrogates is also called
Request-Routing, Content Routing or Content Redirection. Request-Routing, Content Routing or Content Redirection.
Request-Routing techniques are commonly used in Content Networks Request-Routing techniques are commonly used in Content Networks
(also known as Content Delivery Networks)[5]. Content Networks (also known as Content Delivery Networks)[5]. Content Networks
include network infrastructure that exists in layers 4 through 7. include network infrastructure that exists in layers 4 through 7.
Content Networks deal with the routing and forwarding of requests Content Networks deal with the routing and forwarding of requests
and responses for content. Content Networks rely on layer 7 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 Request-Routing techniques are generally used to direct client
requests for objects to a surrogate or a set of surrogates that requests for objects to a surrogate or a set of surrogates that
could best serve that content. Request-Routing mechanisms could could best serve that content. Request-Routing mechanisms could
be used to direct client requests to surrogates that are within a be used to direct client requests to surrogates that are within a
Content Network (CN) [5]. Content Network (CN) [5].
Request-Routing techniques are used as a vehicle to extend the Request-Routing techniques are used as a vehicle to extend the
reach and scale of Content Delivery Networks. There exist multiple reach and scale of Content Delivery Networks. There exist multiple
Request-Routing mechanisms. At a high-level, these may be classified Request-Routing mechanisms. At a high-level, these may be classified
skipping to change at page 8, line 33 skipping to change at page 8, line 33
fine-grained Request-Routing control down to the level of fine-grained Request-Routing control down to the level of
individual objects. The process could be performed in real individual objects. The process could be performed in real
time at the time of the object request. The exposure to the time at the time of the object request. The exposure to the
client's IP address combined with the fine-grained knowledge client's IP address combined with the fine-grained knowledge
of the requested objects enable application-layer Request- of the requested objects enable application-layer Request-
Routing systems to provide better control over the selection of Routing systems to provide better control over the selection of
the best surrogate. the best surrogate.
4.1 Header Inspection 4.1 Header Inspection
Applications such as HTTP [4], RTSP [3], and SSL [2] provide hints Some application level protocols such as HTTP [4], RTSP [3],
in the initial portion of the session about how the client request and SSL [2] provide hints in the initial portion of the session
must be directed. These hints may come from the URL of the content about how the client request must be directed. These hints may come
or other parts of the MIME request header such as Cookies. 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-Based Request-Routing
A Uniform Resource Locator (URL) [7] consists of a naming scheme Application level protocols such as HTTP and RTSP describe the
followed by a string whose format is a function of the naming requested content by its URL [7]. In many cases, this information
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
is sufficient to disambiguate the content and suitably direct the is sufficient to disambiguate the content and suitably direct the
request. In most cases, it may be sufficient to make Request- request. In most cases, it may be sufficient to make Request-
Routing decision just by examining the prefix or suffix of the URL. Routing decision just by examining the prefix or suffix of the URL.
4.1.1.1 302 Redirection 4.1.1.1 302 Redirection
In this approach, the client's request is first resolved to a In this approach, the client's request is first resolved to a
virtual surrogate. Consequently, the surrogate returns an virtual surrogate. Consequently, the surrogate returns an
application-specific code such as the 302 (in the case of application-specific code such as the 302 (in the case of
HTTP [4] or RTSP [3]) to redirect the client to the actual HTTP [4] or RTSP [3]) to redirect the client to the actual
skipping to change at page 9, line 37 skipping to change at page 9, line 29
content request. In general, the return path would go through the content request. In general, the return path would go through the
In-Path element. However, it is possible to arrange for a direct In-Path element. However, it is possible to arrange for a direct
return by passing the address translation information to the return by passing the address translation information to the
surrogate or delivery node through some proprietary means. surrogate or delivery node through some proprietary means.
The primary disadvantage with this method is the performance The primary disadvantage with this method is the performance
implications of URL-parsing in the path of the network traffic. implications of URL-parsing in the path of the network traffic.
However, it is generally the case that the return traffic is much However, it is generally the case that the return traffic is much
larger than the forward traffic. 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. among a set of delivery nodes by content objects identified by URLs.
This allows object-specific control of server loading. For example, This allows object-specific control of server loading. For example,
requests for non-cacheable object types may be directed away from a requests for non-cacheable object types may be directed away from a
cache. cache.
4.1.2 Mime Header-Based Request-Routing 4.1.2 Mime Header-Based Request-Routing
This technique involves the task of using MIME-headers such as This technique involves the task of using MIME-headers such as
Cookie, Language, and User-Agent, in order to select a surrogate. Cookie, Language, and User-Agent, in order to select a surrogate.
skipping to change at page 12, line 16 skipping to change at page 12, line 16
The main objective of this document is to provide a summary of current The main objective of this document is to provide a summary of current
Request-Routing techniques. Such techniques are currently implemented Request-Routing techniques. Such techniques are currently implemented
in the Internet. The document acknowledges that security must be in the Internet. The document acknowledges that security must be
addressed by any entity that implements any technique that redirects addressed by any entity that implements any technique that redirects
client's requests. However, the details of such techniques are beyond client's requests. However, the details of such techniques are beyond
the scope of this document. the scope of this document.
7. Acknowledgements 7. Acknowledgements
The authors acknowledge the contributions and comments of Ian Cooper The authors acknowledge the contributions and comments of Ian Cooper,
(Equinix), Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).
(CrystalBall).
8. References 8. References
[1] Postel, J., "File Transfer Protocol", RFC 765, June 1980, [1] Postel, J., "File Transfer Protocol", RFC 765, June 1980,
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC [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 [3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol", RFC 2326, April 1998. Protocol", RFC 2326, April 1998.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content [5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content
Internetworking (CDI)", http://www.ietf.org/internet-drafts/ 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 [6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting
Service", RFC 1546, November 1993. Service", RFC 1546, November 1993.
[7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource [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., [8] H. Schulzrinne, H., Fokus, G., Casner, S., Frederick, R.,
Jacobson, V., "RTP: A Transport Protocol for Real-Time Jacobson, V., "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996. Applications", RFC 1889, January 1996.
9. Authors' Addresses 9. Authors' Addresses
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada 3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada
EMail: abbieb@nortelnetworks.com EMail: abbieb@nortelnetworks.com
Brad Cain Brad Cain
Cereva Networks Storigen Systems
EMail: bcain@cereva.com 650 Suffolk Street
Lowell, MA 01854 US
Phone: +1 978-323-4454
EMail: bcain@storigen.com
Fred Douglis Fred Douglis
AT&T Labs IBM Research
Room B137 EMail: fdouglis@us.ibm.com
180 Park Ave, Bldg 103
Florham Park, NJ 07932, US
EMail: douglis@research.att.com
Mark Green Mark Green
CacheFlow CacheFlow
650 Almanor Avenue 650 Almanor Avenue
Sunnyvale, CA 94085, US Sunnyvale, CA 94085, US
EMail: markg@cacheflow.com EMail: markg@cacheflow.com
Markus Hofmann Markus Hofmann
Lucent Technologies Lucent Technologies
Room 4F-513 Room 4F-513
 End of changes. 16 change blocks. 
40 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/