draft-ietf-cdi-known-request-routing-03.txt		rfc3568.txt
	Network Working Group A. Barbir		Network Working Group A. Barbir
	Internet-Draft Nortel Networks		Request for Comments: 3568 Nortel Networks
	Expires: October 2, 2003 B. Cain		Category: Informational B. Cain
	Storigen Systems		Storigen Systems
	R. Nair		R. Nair
	Cisco		Consultant
	O. Spatscheck		O. Spatscheck
	AT&T		AT&T
	April 3, 2003		Known Content Network (CN) Request-Routing Mechanisms
	Known CN Request-Routing Mechanisms
	draft-ietf-cdi-known-request-routing-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This memo provides information for the Internet community. It does
	all provisions of Section 10 of RFC2026.		not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	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.
	Internet-Drafts are draft documents valid for a maximum of six 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 October 2, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	The work presents a summary of Request-Routing techniques that are		This document presents a summary of Request-Routing techniques that
	used to direct client requests to surrogates based on various		are used to direct client requests to surrogates based on various
	policies and a possible set of metrics. The document covers		policies and a possible set of metrics. The document covers
	techniques that were commonly used in the industry on or before		techniques that were commonly used in the industry on or before
	December 2000. In this memo the term Request-Routing represents		December 2000. In this memo, the term Request-Routing represents
	techniques that is commonly called content routing or content		techniques that is commonly called content routing or content
	redirection. In principle, Request-Routing techniques can be		redirection. In principle, Request-Routing techniques can be
	classified under: DNS Request-Routing, Transport-layer		classified under: DNS Request-Routing, Transport-layer
	Request-Routing, and Application-layer Request-Routing.		Request-Routing, and Application-layer Request-Routing.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4		2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
	2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Single Reply . . . . . . . . . . . . . . . . . . . . . 3
	2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Multiple Replies . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . 7		2.6. DNS Request-Routing Limitations. . . . . . . . . . . . 6
	3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 9		3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 7
	4. Application-Layer Request-Routing . . . . . . . . . . . . . 10		4. Application-Layer Request-Routing . . . . . . . . . . . . . 8
	4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 10		4.1. Header Inspection. . . . . . . . . . . . . . . . . . . 8
	4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 10		4.1.1. URL-Based Request-Routing. . . . . . . . . . . 8
	4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 11		4.1.2. Header-Based Request-Routing . . . . . . . . . 9
	4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 11		4.1.3. Site-Specific Identifiers. . . . . . . . . . .10
	4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 12		4.2. Content Modification . . . . . . . . . . . . . . . . .10
	4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 12		4.2.1. A-priori URL Rewriting . . . . . . . . . . . .11
	4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 13		4.2.2. On-Demand URL Rewriting. . . . . . . . . . . .11
	4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 13		4.2.3. Content Modification Limitations . . . . . . .11
	5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 14		5. Combination of Multiple Mechanisms . . . . . . . . . . . . .11
	6. Security Considerations . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . .12
	7. Additional Authors and Acknowledgements . . . . . . . . . . 16		7. Additional Authors and Acknowledgements . . . . . . . . . .12
	Normative References . . . . . . . . . . . . . . . . . . . . 17		A. Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
	Informative References . . . . . . . . . . . . . . . . . . . 18		A.1. Proximity Measurements . . . . . . . . . . . . . . . .13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19		A.1.1. Active Probing . . . . . . . . . . . . . . . .13
	A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 21		A.1.2. Metric Types . . . . . . . . . . . . . . . . .14
	A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 21		A.1.3. Surrogate Feedback . . . . . . . . . . . . . .14
	A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 21		8. Normative References . . . . . . . . . . . . . . . . . . . .15
	A.1.2 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 22		9. Informative References . . . . . . . . . . . . . . . . . . .15
	A.1.3 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 22		10. Intellectual Property and Copyright Statements . . . . . . .17
	Intellectual Property and Copyright Statements . . . . . . . 23		11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
			12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
	1. Introduction		1. Introduction
	The document provides a summary of known request routing techniques		This document provides a summary of known request routing techniques
	that are used by the industry before December 2000. Request routing		that are used by the industry before December 2000. Request routing
	techniques are generally used to direct client requests to surrogates		techniques are generally used to direct client requests to surrogates
	based on various policies and a possible set of metrics. The task of		based on 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) [8]. Content Networks		(also known as Content Delivery Networks) [8]. 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 and		Content Networks deal with the routing and forwarding of requests and
	skipping to change at page 4, line 14		skipping to change at page 3, line 37
	2. DNS based Request-Routing Mechanisms		2. DNS based Request-Routing Mechanisms
	DNS based Request-Routing techniques are common due to the ubiquity		DNS based Request-Routing techniques are common due to the ubiquity
	of the DNS system [10][12][13]. In DNS based Request-Routing		of the DNS system [10][12][13]. In DNS based Request-Routing
	techniques, a specialized DNS server is inserted in the DNS		techniques, a specialized DNS server is inserted in the DNS
	resolution process. The server is capable of returning a different		resolution process. The server is capable of returning a different
	set of A, NS or CNAME records based on user defined policies,		set of A, NS or CNAME records based on user defined policies,
	metrics, or a combination of both. In [11] RFC 2782 (DNS SRV)		metrics, or a combination of both. In [11] RFC 2782 (DNS SRV)
	provides guidance on the use of DNS for load balancing. The RFC		provides guidance on the use of DNS for load balancing. The RFC
	describes some of the limitations and suggests appropriate usesage of		describes some of the limitations and suggests appropriate useage of
	DNS based techniques. The next sections provides a summary of some of		DNS based techniques. The next sections provides a summary of some
	the used techniques.		of the used techniques.
	2.1 Single Reply		2.1. Single Reply
	In this approach, the DNS server is authoritative for the entire DNS		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		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		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		address of the surrogate could also be a virtual IP(VIP) address of
	the best set of surrogates for requesting DNS server.		the best set of surrogates for requesting DNS server.
	2.2 Multiple Replies		2.2. Multiple Replies
	In this approach, the Request-Routing DNS server returns multiple		In this approach, the Request-Routing DNS server returns multiple
	replies such as several A records for various surrogates. Common		replies such as several A records for various surrogates. Common
	implementations of client site DNS server's cycles through the		implementations of client site DNS server's cycles through the
	multiple replies in a Round-Robin fashion. The order in which 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		records are returned can be used to direct multiple clients using a
	single client site DNS server.		single client site DNS server.
	2.3 Multi-Level Resolution		2.3. Multi-Level Resolution
	In this approach multiple Request-Routing DNS servers can be involved		In this approach multiple Request-Routing DNS servers can be involved
	in a single DNS resolution. The rationale of utilizing multiple		in a single DNS resolution. The rationale of utilizing multiple
	Request-Routing DNS servers in a single DNS resolution is to allow		Request-Routing DNS servers in a single DNS resolution is to allow
	one to distribute more complex decisions from a single server to		one to distribute more complex decisions from a single server to
	multiple, more specialized, Request-Routing DNS servers. The most		multiple, more specialized, Request-Routing DNS servers. The most
	common mechanisms used to insert multiple Request-Routing DNS servers		common mechanisms used to insert multiple Request-Routing DNS servers
	in a single DNS resolution is the use of NS and CNAME records. An		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		example would be the case where a higher level DNS server operates
	within a territory, directing the DNS lookup to a more specific DNS		within a territory, directing the DNS lookup to a more specific DNS
	server within that territory to provide a more accurate resolution.		server within that territory to provide a more accurate resolution.
	2.3.1 NS Redirection		2.3.1. NS Redirection
	A DNS server can use NS records to redirect the authority of the next		A DNS server can use NS records to redirect the authority of the next
	level domain to another Request-Routing DNS server. The, technique		level domain to another Request-Routing DNS server. The, technique
	allows multiple DNS server to be involved in the name resolution		allows multiple DNS server to be involved in the name resolution
	process. For example, a client site DNS server resolving		process. For example, a client site DNS server resolving
	a.b.example.com [10] would eventually request a resolution of		a.b.example.com [10] would eventually request a resolution of
	a.b.example.com from the name server authoritative for example.com.		a.b.example.com from the name server authoritative for example.com.
	The name server authoritative for this domain might be a		The name server authoritative for this domain might be a
	Request-Routing NS server. In this case the Request-Routing DNS		Request-Routing NS server. In this case the Request-Routing DNS
	server can either return a set of A records or can redirect the		server can either return a set of A records or can redirect the
	resolution of the request a.b.example.com to the DNS server that is		resolution of the request a.b.example.com to the DNS server that is
	authoritative for example.com using NS records.		authoritative for example.com using NS records.
	One drawback of using NS records is that the number of		One drawback of using NS records is that the number of
	Request-Routing DNS servers are limited by the number of parts in		Request-Routing DNS servers are limited by the number of parts in the
	the DNS name. This problem results from DNS policy that causes a		DNS name. This problem results from DNS policy that causes a client
	client site DNS server to abandon a request if no additional parts of		site DNS server to abandon a request if no additional parts of the
	the DNS name are resolved in an exchange with an authoritative DNS		DNS name are resolved in an exchange with an authoritative DNS
	server.		server.
	A second drawback is that the last DNS server can determine the TTL		A second drawback is that the last DNS server can determine the TTL
	of the entire resolution process. Basically, the last DNS server can		of the entire resolution process. Basically, the last DNS server can
	return in the authoritative section of its response its own NS		return in the authoritative section of its response its own NS
	record. The client will use this cached NS record for further request		record. The client will use this cached NS record for further
	resolutions until it expires.		request resolutions until it expires.
	Another drawback is that some implementations of bind voluntarily		Another drawback is that some implementations of bind voluntarily
	cause timeouts to simplify their implementation in cases in which a		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		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		is returned or cached. This is especially a problem if the domain of
	the name server does not match the domain currently resolved, since		the name server does not match the domain currently resolved, since
	in this case the A records, which might be passed in the DNS		in this case the A records, which might be passed in the DNS
	response, are discarded for security reasons. Another drawback is the		response, are discarded for security reasons. Another drawback is
	added delay in resolving the request due to the use of multiple DNS		the added delay in resolving the request due to the use of multiple
	servers.		DNS servers.
	2.3.2 CNAME Redirection		2.3.2. CNAME Redirection
	In this scenario, the Request-Routing DNS server returns a CNAME		In this scenario, the Request-Routing DNS server returns a CNAME
	record to direct resolution to an entirely new domain. In principle,		record to direct resolution to an entirely new domain. In principle,
	the new domain might employ a new set of Request-Routing DNS servers.		the new domain might employ a new set of Request-Routing DNS servers.
	One disadvantage of this approach is the additional overhead of		One disadvantage of this approach is the additional overhead of
	resolving the new domain name. The main advantage of this approach is		resolving the new domain name. The main advantage of this approach
	that the number of Request-Routing DNS servers is independent of the		is that the number of Request-Routing DNS servers is independent of
	format of the domain name.		the format of the domain name.
	2.4 Anycast		2.4. Anycast
	Anycast [5] is an inter-network service that is applicable to		Anycast [5] is an inter-network service that is applicable to
	networking situations where a host, application, or user wishes to		networking situations where a host, application, or user wishes to
	locate a host which supports a particular service but, if several		locate a host which supports a particular service but, if several
	servers support the service, does not particularly care which server		servers utilizes the service, it does not particularly care which
	is used. In an anycast service, a host transmits a datagram to an		server is used. In an anycast service, a host transmits a datagram
	anycast address and the inter-network is responsible for providing		to an anycast address and the inter-network is responsible for
	best effort delivery of the datagram to at least one, and preferably		providing best effort delivery of the datagram to at least one, and
	only one, of the servers that accept datagrams for the anycast		preferably only one, of the servers that accept datagrams for the
	address.		anycast address.
	The motivation for anycast is that it considerably simplifies the		The motivation for anycast is that it considerably simplifies the
	task of finding an appropriate server. For example, users, instead of		task of finding an appropriate server. For example, users, instead
	consulting a list of servers and choosing the closest one, could		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		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		one. By using anycast, DNS resolvers would no longer have to be
	configured with the IP addresses of their servers, but rather could		configured with the IP addresses of their servers, but rather could
	send a query to a well-known DNS anycast address.		send a query to a well-known DNS anycast address.
	Furthermore, to combine measurement and redirection, the		Furthermore, to combine measurement and redirection, the
	Request-Routing DNS server can advertise an anycast address as its IP		Request-Routing DNS server can advertise an anycast address as its IP
	address. The same address is used by multiple physical DNS servers.		address. The same address is used by multiple physical DNS servers.
	In this scenario, the Request-Routing DNS server that is the closest		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		to the client site DNS server in terms of OSPF and BGP routing will
	skipping to change at page 6, line 37		skipping to change at page 6, line 16
	o The DNS server may not be the closest server in terms of routing		o The DNS server may not be the closest server in terms of routing
	to the client.		to the client.
	o Typically, routing protocols are not load sensitive. Hence, the		o Typically, routing protocols are not load sensitive. Hence, the
	closest server may not be the one with the least network latency.		closest server may not be the one with the least network latency.
	o The server load is not considered during the Request-Routing		o The server load is not considered during the Request-Routing
	process.		process.
	2.5 Object Encoding		2.5. Object Encoding
	Since only DNS names are visible during the DNS Request-Routing, some		Since only DNS names are visible during the DNS Request-Routing, some
	solutions encode the object type, object hash, or similar information		solutions encode the object type, object hash, or similar information
	into the DNS name. This might vary from a simple division of objects		into the DNS name. This might vary from a simple division of objects
	based on object type (such as images.a.b.example.com and		based on object type (such as images.a.b.example.com and
	streaming.a.b.example.com) to a sophisticated schema in which the		streaming.a.b.example.com) to a sophisticated schema in which the
	domain name contains a unique identifier (such as a hash) of the		domain name contains a unique identifier (such as a hash) of the
	object. The obvious advantage is that object information is available		object. The obvious advantage is that object information is
	at resolution time. The disadvantage is that the client site DNS		available at resolution time. The disadvantage is that the client
	server has to perform multiple resolutions to retrieve a single Web		site DNS server has to perform multiple resolutions to retrieve a
	page, which might increase rather than decrease the overall latency.		single Web page, which might increase rather than decrease the
			overall latency.
	2.6 DNS Request-Routing Limitations		2.6. DNS Request-Routing Limitations
	This section lists some of the limitations of DNS based		This section lists some of the limitations of DNS based
	Request-Routing techniques.		Request-Routing techniques.
	o DNS only allows resolution at the domain level. However, an ideal		o DNS only allows resolution at the domain level. However, an ideal
	request resolution system should service requests per object		request resolution system should service requests per object
	level.		level.
	o In DNS based Request-Routing systems servers may be required to		o In DNS based Request-Routing systems servers may be required to
	return DNS entries with a short time-to-live (TTL) values. This		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		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		outages. This in return may increase the volume of requests to
	servers.		DNS servers.
	o Some DNS implementations do not always adhere to DNS standards.		o Some DNS implementations do not always adhere to DNS standards.
	For example, many DNS implementations do not honor the DNS TTL		For example, many DNS implementations do not honor the DNS TTL
	field.		field.
	o DNS Request-Routing is based only on knowledge of the client DNS		o DNS Request-Routing is based only on knowledge of the client DNS
	server, as client addresses are not relayed within DNS requests.		server, as client addresses are not relayed within DNS requests.
	This limits the ability of the Request-Routing system to determine		This limits the ability of the Request-Routing system to determine
	a client's proximity to the surrogate.		a client's proximity to the surrogate.
	o DNS servers can request and allow recursive resolution of DNS		o DNS servers can request and allow recursive resolution of DNS
	names. For recursive resolution of requests, the Request-Routing		names. For recursive resolution of requests, the Request-Routing
	DNS server will not be exposed to the IP address of the client's		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		site DNS server. In this case, the Request-Routing DNS server
	be exposed to the address of the DNS server that is recursively		will be exposed to the address of the DNS server that is
	requesting the information on behalf of the client's site DNS		recursively requesting the information on behalf of the client's
	server. For example, imgs.example.com might be resolved by a CN,		site DNS server. For example, imgs.example.com might be resolved
	but the request for the resolution might come from		by a CN, but the request for the resolution might come from
	dns1.example.com as a result of the recursion.		dns1.example.com as a result of the recursion.
	o Users that share a single client site DNS server will be		o Users that share a single client site DNS server will be
	redirected to the same set of IP addresses during the TTL		redirected to the same set of IP addresses during the TTL
	interval. This might lead to overloading of the surrogate during a		interval. This might lead to overloading of the surrogate during
	flash crowd.		a flash crowd.
	o Some implementations of bind can cause DNS timeouts to occur while		o Some implementations of bind can cause DNS timeouts to occur while
	handling exceptional situations. For example, timeouts can occur		handling exceptional situations. For example, timeouts can occur
	for NS redirections to unknown domains.		for NS redirections to unknown domains.
	DNS based request routing techniques can suffer from serious		DNS based request routing techniques can suffer from serious
	limitations. For example, the use of such techniques can overburden		limitations. For example, the use of such techniques can overburden
	third party DNS servers, which should not be allowed [19]. In [11]		third party DNS servers, which should not be allowed [19]. In [11]
	RFC 2782 provides warnings on the use of DNS for load balancing.		RFC 2782 provides warnings on the use of DNS for load balancing.
	Readers are encouraged to read the RFC for better understanding of		Readers are encouraged to read the RFC for better understanding of
	skipping to change at page 9, line 26		skipping to change at page 8, line 6
	techniques [20][18][15] are used to hand off the session to a more		techniques [20][18][15] are used to hand off the session to a more
	appropriate surrogate are beyond the scope of this document.		appropriate surrogate are beyond the scope of this document.
	In general, the forward-flow traffic (client to newly selected		In general, the forward-flow traffic (client to newly selected
	surrogate) will flow through the surrogate originally chosen by DNS.		surrogate) will flow through the surrogate originally chosen by DNS.
	The reverse-flow (surrogate to client) traffic, which normally		The reverse-flow (surrogate to client) traffic, which normally
	transfers much more data than the forward flow, would typically take		transfers much more data than the forward flow, would typically take
	the direct path.		the direct path.
	The overhead associated with transport-layer Request-Routing [21][19]		The overhead associated with transport-layer Request-Routing [21][19]
	it better suited for long-lived sessions such as FTP [1]and RTSP		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		[3]. However, it also could be used to direct clients away from
	overloaded surrogates.		overloaded surrogates.
	In general, transport-layer Request-Routing can be combined with DNS		In general, transport-layer Request-Routing can be combined with DNS
	based techniques. As stated earlier, DNS based methods resolve		based techniques. As stated earlier, DNS based methods resolve
	clients requests based on domains or sub domains with exposure to the		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		client's DNS server IP address. Hence, the DNS based methods could
	used as a first step in deciding on an appropriate surrogate with		be used as a first step in deciding on an appropriate surrogate with
	more accurate refinement made by the transport-layer Request-Routing		more accurate refinement made by the transport-layer Request-Routing
	system.		system.
	4. Application-Layer Request-Routing		4. Application-Layer Request-Routing
	Application-layer Request-Routing systems perform deeper examination		Application-layer Request-Routing systems perform deeper examination
	of client's packets beyond the transport layer header. Deeper		of client's packets beyond the transport layer header. Deeper
	examination of client's packets provides fine-grained Request-Routing		examination of client's packets provides fine-grained Request-Routing
	control down to the level of individual objects. The process could be		control down to the level of individual objects. The process could
	performed in real time at the time of the object request. The		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		exposure to the client's IP address combined with the fine-grained
	knowledge of the requested objects enable application-layer Request-		knowledge of the requested objects enable application-layer
	Routing systems to provide better control over the selection of the		Request-Routing systems to provide better control over the selection
	best surrogate.		of the best surrogate.
	4.1 Header Inspection		4.1. Header Inspection
	Some application level protocols such as HTTP [4], RTSP [3], and SSL		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		[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		client request must be directed. These hints may come from the URL
	the content or other parts of the MIME request header such as		of the content or other parts of the MIME request header such as
	Cookies.		Cookies.
	4.1.1 URL-Based Request-Routing		4.1.1. URL-Based Request-Routing
	Application level protocols such as HTTP and RTSP describe the		Application level protocols such as HTTP and RTSP describe the
	requested content by its URL [6]. In many cases, this information is		requested content by its URL [6]. In many cases, this information
	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- Routing		request. In most cases, it may be sufficient to make Request- Routing
	decision just by examining the prefix or suffix of the URL.		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 virtual		In this approach, the client's request is first resolved to a virtual
	surrogate. Consequently, the surrogate returns an		surrogate. Consequently, the surrogate returns an
	application-specific code such as the 302 (in the case of HTTP [4] or		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.		RTSP [3]) to redirect the client to the actual delivery node.
	This technique is relatively simple to implement. However, the main		This technique is relatively simple to implement. However, the main
	drawback of this method is the additional latency involved in sending		drawback of this method is the additional latency involved in sending
	the redirect message back to the client.		the redirect message back to the client.
	4.1.1.2 In-Path Element		4.1.1.2. In-Path Element
	In this technique, an In-Path element is present in the network in		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		the forwarding path of the client's request. The In-Path element
	provides transparent interception of the transport connection. The		provides transparent interception of the transport connection. The
	In-Path element examines the client's content requests and performs		In-Path element examines the client's content requests and performs
	Request-Routing decisions.		Request-Routing decisions.
	The In-Path element then splices the client connection to a		The In-Path element then splices the client connection to a
	connection with the appropriate delivery node and passes along the		connection with the appropriate delivery node and passes along the
	content request. In general, the return path would go through the		content request. In general, the return path would go through the
	skipping to change at page 11, line 21		skipping to change at page 9, line 35
	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 partitioning 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 Header-Based Request-Routing		4.1.2. Header-Based Request-Routing
	This technique involves the task of using HTTP [4] such as Cookie,		This technique involves the task of using HTTP [4] such as Cookie,
	Language, and User-Agent, in order to select a surrogate. In [20]		Language, and User-Agent, in order to select a surrogate. In [20]
	some examples of using this technique are provided.		some examples of using this technique are provided.
	Cookies can be used to identify a customer or session by a web site.		Cookies can be used to identify a customer or session by a web site.
	Cookie based Request-Routing provides content service differentiation		Cookie based Request-Routing provides content service differentiation
	based on the client. This approach works provided that the cookies		based on the client. This approach works provided that the cookies
	belong to the client. In addition, it is possible to direct a		belong to the client. In addition, it is possible to direct a
	connection from a multi-session transaction to be directed to the		connection from a multi-session transaction to the same server to
	same server to achieve session-level persistence.		achieve session-level persistence.
	The language header can be used to direct traffic to a		The language header can be used to direct traffic to a
	language-specific delivery node. The user-agent header helps identify		language-specific delivery node. The user-agent header helps
	the type of client device. For example, a voice-browser, PDA, or cell		identify the type of client device. For example, a voice-browser,
	phone can indicate the type of delivery node that has content		PDA, or cell phone can indicate the type of delivery node that has
	specialized to handle the content request.		content specialized to handle the content request.
	4.1.3 Site-Specific Identifiers		4.1.3. Site-Specific Identifiers
	Site-specific identifiers help authenticate and identify a session		Site-specific identifiers help authenticate and identify a session
	from a specific user. This information may be used to direct a		from a specific user. This information may be used to direct a
	content request.		content request.
	An example of a site-specific identifier is the SSL Session		An example of a site-specific identifier is the SSL Session
	Identifier. This identifier is generated by a web server and used by		Identifier. This identifier is generated by a web server and used by
	the web client in succeeding sessions to identify itself and avoid an		the web client in succeeding sessions to identify itself and avoid an
	entire security authentication exchange. In order to inspect the		entire security authentication exchange. In order to inspect the
	session identifier, an In-Path element would observe the responses of		session identifier, an In-Path element would observe the responses of
	the web server and determine the session identifier which is then		the web server and determine the session identifier which is then
	used to associate the session to a specific server. The remaining		used to associate the session to a specific server. The remaining
	sessions are directed based on the stored session identifier.		sessions are directed based on the stored session identifier.
	4.2 Content Modification		4.2. Content Modification
	This technique enables a content provider to take direct control over		This technique enables a content provider to take direct control over
	Request-Routing decisions without the need for specific witching		Request-Routing decisions without the need for specific witching
	devices or directory services in the path between the client and the		devices or directory services in the path between the client and the
	origin server. Basically, a content provider can directly communicate		origin server. Basically, a content provider can directly
	to the client the best surrogate that can serve the request.		communicate to the client the best surrogate that can serve the
	Decisions about the best surrogate can be made on a per-object basis		request. Decisions about the best surrogate can be made on a per-
	or it can depend on a set of metrics. The overall goal is to improve		object basis or it can depend on a set of metrics. The overall goal
	scalability and the performance for delivering the modified content,		is to improve scalability and the performance for delivering the
	including all embedded objects.		modified content, including all embedded objects.
	In general, the method takes advantage of content objects that		In general, the method takes advantage of content objects that
	consist of basic structure that includes references to additional,		consist of basic structure that includes references to additional,
	embedded objects. For example, most web pages, consist of an HTML		embedded objects. For example, most web pages, consist of an HTML
	document that contains plain text together with some embedded		document that contains plain text together with some embedded
	objects, such as GIF or JPEG images. The embedded objects are		objects, such as GIF or JPEG images. The embedded objects are
	referenced using embedded HTML directives. In general, embedded HTML		referenced using embedded HTML directives. In general, embedded HTML
	directives direct the client to retrieve the embedded objects from		directives direct the client to retrieve the embedded objects from
	the origin server. A content provider can now modify references to		the origin server. A content provider can now modify references to
	embedded objects such that they could be fetched from the best		embedded objects such that they could be fetched from the best
	skipping to change at page 12, line 41		skipping to change at page 11, line 5
	Content modification techniques must not violate the architectural		Content modification techniques must not violate the architectural
	concepts of the Internet [9]. Special considerations must be made to		concepts of the Internet [9]. Special considerations must be made to
	ensure that the task of modifying the content is performed in a		ensure that the task of modifying the content is performed in a
	manner that is consistent with RFC 3238 [9] that specifies the		manner that is consistent with RFC 3238 [9] that specifies the
	architectural considerations for intermediaries that perform		architectural considerations for intermediaries that perform
	operations or modifications on content.		operations or modifications on content.
	The basic types of URL rewriting are discussed in the following		The basic types of URL rewriting are discussed in the following
	subsections.		subsections.
	4.2.1 A-priori URL Rewriting		4.2.1. A-priori URL Rewriting
	In this scheme, a content provider rewrites the embedded URLs before		In this scheme, a content provider rewrites the embedded URLs before
	the content is positioned on the origin server. In this case, URL		the content is positioned on the origin server. In this case, URL
	rewriting can be done either manually or by using a software tools		rewriting can be done either manually or by using software tools that
	that parse the content and replace embedded URLs.		parse the content and replace embedded URLs.
	A-priori URL rewriting alone does not allow consideration of client		A-priori URL rewriting alone does not allow consideration of client
	specifics for Request-Routing. However, it can be used in combination		specifics for Request-Routing. However, it can be used in
	with DNS Request-Routing to direct related DNS queries into the		combination with DNS Request-Routing to direct related DNS queries
	domain name space of the service provider. Dynamic Request-Routing		into the domain name space of the service provider. Dynamic
	based on client specifics are then done using the DNS approach.		Request-Routing based on client specifics are then done using the DNS
			approach.
	4.2.2 On-Demand URL Rewriting		4.2.2. On-Demand URL Rewriting
	On-Demand or dynamic URL rewriting, modifies the content when the		On-Demand or dynamic URL rewriting, modifies the content when the
	client request reaches the origin server. At this time, the		client request reaches the origin server. At this time, the identity
	identity of the client is known and can be considered when rewriting		of the client is known and can be considered when rewriting the
	the embedded URLs. In particular, an automated process can determine,		embedded URLs. In particular, an automated process can determine,
	on-demand, which surrogate would serve the requesting client best.		on-demand, which surrogate would serve the requesting client best.
	The embedded URLs can then be rewritten to direct the client to		The embedded URLs can then be rewritten to direct the client to
	retrieve the objects from the best surrogate rather than from the		retrieve the objects from the best surrogate rather than from the
	origin server.		origin server.
	4.2.3 Content Modification Limitations		4.2.3. Content Modification Limitations
	Content modification as a Request-Routing mechanism suffers from many		Content modification as a Request-Routing mechanism suffers from many
	limitation [23]. For example:		limitation [23]. For example:
	o The first request from a client to a specific site must be served		o The first request from a client to a specific site must be served
	from the origin server.		from the origin server.
	o Content that has been modified to include references to nearby		o Content that has been modified to include references to nearby
	surrogates rather than to the origin server should be marked as		surrogates rather than to the origin server should be marked as
	non-cacheable. Alternatively, such pages can be marked to be		non-cacheable. Alternatively, such pages can be marked to be
	skipping to change at page 15, line 12		skipping to change at page 12, line 21
	domain name spaces. Using DNS Request-Routing, requests for those		domain name spaces. Using DNS Request-Routing, requests for those
	objects can now dynamically be directed to different surrogates.		objects can now dynamically be directed to different surrogates.
	6. Security Considerations		6. Security Considerations
	The main objective of this document is to provide a summary of		The main objective of this document is to provide a summary of
	current Request-Routing techniques. Such techniques are currently		current Request-Routing techniques. Such techniques are currently
	implemented in the Internet. However, security must be addressed by		implemented in the Internet. However, security must be addressed by
	any entity that implements any technique that redirects client's		any entity that implements any technique that redirects client's
	requests. In [9] RFC 3238 addresses the main requirements for		requests. In [9] RFC 3238 addresses the main requirements for
	entities that intent to modify requests for content in the Internet.		entities that intend to modify requests for content in the Internet.
	Some active probing techniques will set off intrusion detection		Some active probing techniques will set off intrusion detection
	systems and firewalls. Therefore, it is recommended that implementers		systems and firewalls. Therefore, it is recommended that
	be aware of routing protocol security [25].		implementers be aware of routing protocol security [25].
	It is important to note the impact of TLS [2] on request routing in		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		CNs. Specifically, when TLS is used the full URL is not visible to
	the content network unless it terminates the TLS session. The current		the content network unless it terminates the TLS session. The
	document focuses on HTTP techniques. TLS based techniques that		current document focuses on HTTP techniques. TLS based techniques
	require the termination of TLS sessions on Content Peering Gateways		that require the termination of TLS sessions on Content Peering
	[8] are out of scope.		Gateways [8] are beyond the of scope of this document.
	Furthermore, the details of security techniques are beyond the scope		The details of security techniques are also beyond the scope of this
	of this document.		document.
	7. Additional Authors and Acknowledgements		7. Additional Authors and Acknowledgements
	The following people have contributed to the task of authoring this		The following people have contributed to the task of authoring this
	document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann		document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann
	(Lucent), Doug Potter.		(Lucent), Doug Potter.
	The authors acknowledge the contributions and comments of Ian Cooper,		The authors acknowledge the contributions and comments of Ian Cooper,
	Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean		Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean
	(CrystalBall).		(CrystalBall).
	Normative References
	[1] Postel, J.l, "File Transfer Protocol", RFC 765, June 1980.
	[2] T. Dierks et. al, "The TLS Protocol Version 1", RFC 846, July
	1999.
	[3] H. Schulzrinne et. al, "Real Time Streaming Protocol", RFC 2326,
	April 1998.
	[4] R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2616, June 1999.
	[5] C. Partridge et al., "Host Anycasting Service", RFC 1546,
	November 1993.
	[6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC
	1738, May 1994.
	[7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time
	Applications", RFC 1889, January 1996.
	[8] M. Day et al, "A Model for Content Internetworking (CDI)", RFC
	3466 , February 2003.
	[9] S. Floyd et al, "IAB Architectural and Policy Considerations for
	Open Pluggable Edge Services", RFC 3238, January 2002.
	Informative References
	[10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,
	June 1999.
	[11] A. Gulbrandsen et al, "A DNS RR for specifying the location of
	services (DNS SRV)", RFC 2782, February 2002.
	[12] P. Mockapetris, "Domain names - concepts and facilities", RFC
	1034, November 1987.
	[13] P. Mockapetris, "Domain names - concepts and facilities", RFC
	1035, November 1987.
	[14] R. Elz et al, "Clarifications to the DNS Specification", RFC
	2181, July 1997.
	[15] D. Awduche et al, "Overview and Principles of Internet Traffic
	Engineering", RFC 3272, May 2002.
	[16] E. Crawley et al, "A Framework for QoS-based Routing in the
	Internet", RFC 2386, August 1998.
	[17] G. Huston, "Commentary on Inter-Domain Routing in the
	Internet", RFC 3221, December 2001.
	[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.
	[19] A. Shaikh, "On the effectiveness of DNS-based Server
	Selection", INFOCOM 2001, August 2001.
	[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.
	[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.
	[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.
	[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.
	[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
	Transactions 1999, June 1999.
	[25] F. Wang et al., "Secure routing protocols: Theory and
	Practice", Technical report, North Carolina State University
	1997, May 1997.
	Authors' Addresses
	Abbie Barbir
	Nortel Networks
	3500 Carling Avenue
	Nepean, Ontario K2H 8E9
	Canada
	Phone: +1 613 763 5229
	EMail: abbieb@nortelnetworks.com
	Brad Cain
	Storigen Systems
	650 Suffolk Street
	Lowell, MA 01854
	USA
	Phone: +1 978-323-4454
	EMail: bcain@storigen.com
	Raj Nair
	Cisco
	50 Nagog Park
	Acton, MA 01720
	USA
	EMail: rnair@cisco.com
	Oliver Spatscheck
	AT&T
	180 Park Ave, Bldg 103
	Florham Park, NJ 07932
	USA
	EMail: spatsch@research.att.com
	Appendix A. Measurements		Appendix A. Measurements
	Request-Routing systems can use a variety of metrics in order to		Request-Routing systems can use a variety of metrics in order to
	determine the best surrogate that can serve a client's request. In		determine the best surrogate that can serve a client's request. In
	general, these metrics are based on network measurements and feedback		general, these metrics are based on network measurements and feedback
	from surrogates. It is possible to combine multiple metrics using		from surrogates. It is possible to combine multiple metrics using
	both proximity and surrogate feedback for best surrogate selection.		both proximity and surrogate feedback for best surrogate selection.
	The following sections describe several well known metrics as well as		The following sections describe several well known metrics as well as
	the major techniques for obtaining them.		the major techniques for obtaining them.
	A.1 Proximity Measurements		A.1. Proximity Measurements
	Proximity measurements can be used by the Request-Routing system to		Proximity measurements can be used by the Request-Routing system to
	direct users to the "closest" surrogate. In this document proximity		direct users to the "closest" surrogate. In this document proximity
	means round-trip time. In a DNS Request-Routing system, the		means round-trip time. In a DNS Request-Routing system, the
	measurements are made to the client's local DNS server. However, when		measurements are made to the client's local DNS server. However,
	the IP address of the client is accessible more accurate proximity		when the IP address of the client is accessible more accurate
	measurements can be obtained [24].		proximity measurements can be obtained [24].
	Proximity measurements can be exchanged between surrogates and the		Proximity measurements can be exchanged between surrogates and the
	requesting entity. In many cases, proximity measurements are		requesting entity. In many cases, proximity measurements are
	"one-way" in that they measure either the forward or reverse path of		"one-way" in that they measure either the forward or reverse path of
	packets from the surrogate to the requesting entity. This is		packets from the surrogate to the requesting entity. This is
	important as many paths in the Internet are asymmetric [24].		important as many paths in the Internet are asymmetric [24].
	In order to obtain a set of proximity measurements, a network may		In order to obtain a set of proximity measurements, a network may
	employ active probing techniques.		employ active probing techniques.
	A.1.1 Active Probing		A.1.1. Active Probing
	Active probing is when past or possible requesting entities are		Active probing is when past or possible requesting entities are
	probed using one or more techniques to determine one or more metrics		probed using one or more techniques to determine one or more metrics
	from each surrogate or set of surrogates. An example of a probing		from each surrogate or set of surrogates. An example of a probing
	technique is an ICMP ECHO Request that is periodically sent from each		technique is an ICMP ECHO Request that is periodically sent from each
	surrogate or set of surrogates to a potential requesting entity.		surrogate or set of surrogates to a potential requesting entity.
	In any active probing approach, a list of potential requesting		In any active probing approach, a list of potential requesting
	entities need to be obtained. This list can be generated		entities need to be obtained. This list can be generated
	dynamically. Here, as requests arrive, the requesting entity		dynamically. Here, as requests arrive, the requesting entity
	addresses can be cached for later probing. Another potential solution		addresses can be cached for later probing. Another potential
	is to use an algorithm to divide address space into blocks and to		solution is to use an algorithm to divide address space into blocks
	probe random addresses within those blocks. Limitations of active		and to probe random addresses within those blocks. Limitations of
	probing techniques include:		active probing techniques include:
	o Measurements can only be taken periodically.		o Measurements can only be taken periodically.
	o Firewalls and NATs disallow probes.		o Firewalls and NATs disallow probes.
	o Probes often cause security alarms to be triggered on intrusion		o Probes often cause security alarms to be triggered on intrusion
	detection systems.		detection systems.
	A.1.2 Metric Types		A.1.2. Metric Types
	The following sections list some of the metrics, which can be used		The following sections list some of the metrics, which can be used
	for proximity calculations.		for proximity calculations.
	o Latency: Network latency measurements metrics are used to		o Latency: Network latency measurements metrics are used to
	determine the surrogate (or set of surrogates) that has the least		determine the surrogate (or set of surrogates) that has the least
	delay to the requesting entity. These measurements can be		delay to the requesting entity. These measurements can be
	obtained using active probing techniques.		obtained using active probing techniques.
	o Hop Counts: Router hops from the surrogate to the requesting		o Hop Counts: Router hops from the surrogate to the requesting
	entity can be used as a proximity measurement.		entity can be used as a proximity measurement.
	o BGP Information: BGP AS PATH and MED attributes can be used to		o BGP Information: BGP AS PATH and MED attributes can be used to
	determine the "BGP distance" to a given prefix/length pair. In		determine the "BGP distance" to a given prefix/length pair. In
	order to use BGP information for proximity measurements, it must		order to use BGP information for proximity measurements, it must
	be obtained at each surrogate site/location.		be obtained at each surrogate site/location.
	It is important to note that the value of BGP AS PATH information can		It is important to note that the value of BGP AS PATH information can
	be meaningless as a good selection metric [24].		be meaningless as a good selection metric [24].
	A.1.3 Surrogate Feedback		A.1.3. Surrogate Feedback
	In order to select a "least-loaded" delivery node. Feedback can be		In order to select a "least-loaded" delivery node. Feedback can be
	delivered from each surrogate or can be aggregated by site or by		delivered from each surrogate or can be aggregated by site or by
	location.		location.
	A.1.3.1 Probing		A.1.3.1. Probing
	Feedback information may be obtained by periodically probing a		Feedback information may be obtained by periodically probing a
	surrogate by issuing an HTTP request and observing the behavior. The		surrogate by issuing an HTTP request and observing the behavior. The
	problems with probing for surrogate information are:		problems with probing for surrogate information are:
	o It is difficult to obtain "real-time" information.		o It is difficult to obtain "real-time" information.
	o Non-real-time information may be inaccurate.		o Non-real-time information may be inaccurate.
	Consequently, feedback information can be obtained by agents that		Consequently, feedback information can be obtained by agents that
	reside on surrogates that can communicate a variety of metrics about		reside on surrogates that can communicate a variety of metrics about
	their nodes.		their nodes.
	Intellectual Property Statement		8. Normative References
			[1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
			959, October 1985.
			[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246,
			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] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
			Service", RFC 1546, November 1993.
			[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
			Locators (URL)", RFC 1738, December 1994.
			[7] Schulzrinne, H., Casner, S., Federick, R. and V. Jacobson, "RTP:
			A Transport Protocol for Real-Time Applications", RFC 1889,
			January 1996.
			[8] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
			Content Internetworking (CDI)", RFC 3466, February 2003.
			[9] Floyd, S. and L. Daigle, "IAB Architectural and Policy
			Considerations for Open Pluggable Edge Services", RFC 3238,
			January 2002.
			9. Informative References
			[10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP
			32, RFC 2606, June 1999.
			[11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
			specifying the location of services (DNS SRV)", RFC 2782,
			February 2002.
			[12] Mockapetris, P., "Domain names - concepts and facilities", STD
			13, RFC 1034, November 1987.
			[13] Mockapetris, P., "Domain names - concepts and facilities", STD
			13, RFC 1035, November 1987.
			[14] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
			RFC 2181, July 1997.
			[15] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao,
			"Overview and Principles of Internet Traffic Engineering", RFC
			3272, May 2002.
			[16] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A
			Framework for QoS-based Routing in the Internet", RFC 2386,
			August 1998.
			[17] Huston, G., "Commentary on Inter-Domain Routing in the
			Internet", RFC 3221, December 2001.
			[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.
			[19] A. Shaikh, "On the effectiveness of DNS-based Server Selection",
			INFOCOM 2001, August 2001.
			[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.
			[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.
			[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.
			[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.
			[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
			Transactions 1999, June 1999.
			[25] F. Wang et al., "Secure routing protocols: Theory and Practice",
			Technical report, North Carolina State University 1997, May
			1997.
			10. Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of		claims of rights made available for publication and any assurances of
	skipping to change at page 23, line 27		skipping to change at page 18, line 5
	obtain a general license or permission for the use of such		obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can		proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		11. Authors' Addresses
			Abbie Barbir
			Nortel Networks
			3500 Carling Avenue
			Nepean, Ontario K2H 8E9
			Canada
			Phone: +1 613 763 5229
			EMail: abbieb@nortelnetworks.com
			Brad Cain
			Storigen Systems
			650 Suffolk Street
			Lowell, MA 01854
			USA
			Phone: +1 978-323-4454
			EMail: bcain@storigen.com
			Raj Nair
			6 Burroughs Rd
			Lexington, MA 02420
			USA
			EMail: nair_raj@yahoo.com
			Oliver Spatscheck
			AT&T
			180 Park Ave, Bldg 103
			Florham Park, NJ 07932
			USA
			EMail: spatsch@research.att.com
			12. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
End of changes. 63 change blocks.
	295 lines changed or deleted		285 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/