draft-ietf-cdi-known-request-routing-02.txt   draft-ietf-cdi-known-request-routing-03.txt 
Network Working Group B. Cain Network Working Group A. Barbir
Internet-Draft Storigen Systems Internet-Draft Nortel Networks
Expires: May 2, 2003 A. Barbir Expires: October 2, 2003 B. Cain
Nortel Networks Storigen Systems
R. Nair R. Nair
Cisco Cisco
O. Spatscheck O. Spatscheck
AT&T AT&T
November 2002 April 3, 2003
Known CN Request-Routing Mechanisms Known CN Request-Routing Mechanisms
draft-ietf-cdi-known-request-routing-02.txt 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 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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 May 2, 2003. This Internet-Draft will expire on October 2, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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 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. The document covers
Request-Routing represents techniques that are commonly called techniques that were commonly used in the industry on or before
content routing or content redirection. In principle, Request- December 2000. In this memo the term Request-Routing represents
Routing techniques can be classified under: DNS Request-Routing, techniques that is commonly called content routing or content
Transport-layer Request-Routing, and Application-layer Request- redirection. In principle, Request-Routing techniques can be
Routing. classified under: DNS Request-Routing, Transport-layer
Request-Routing, and Application-layer Request-Routing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4 2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4
2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . 7
3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 8 3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 9
4. Application-Layer Request-Routing . . . . . . . . . . . . . 9 4. Application-Layer Request-Routing . . . . . . . . . . . . . 10
4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 9 4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 9 4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 10
4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 10 4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 11
4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 10 4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 11
4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 11 4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 12
4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 11 4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 12
4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 12 4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 13
4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 12 4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 13
5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 13 5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. Additional Authors and Acknowledgements . . . . . . . . . . 15 7. Additional Authors and Acknowledgements . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 18 A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 21
A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 18 A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 21
A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 18 A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 21
A.1.2 Passive Measurement . . . . . . . . . . . . . . . . . . . . 19 A.1.2 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 22
A.1.3 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 19 A.1.3 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 22
A.1.4 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The document provides a summary of current known techniques that The document provides a summary of known request routing techniques
could be used to direct client requests to surrogates based on that are used by the industry before December 2000. Request routing
various policies and a possible set of metrics. The task of techniques are generally used to direct client requests to surrogates
directing clients' requests to surrogates is also called Request- based on various policies and a possible set of metrics. The task of
Routing, Content Routing or Content Redirection. directing clients' requests to surrogates is also called
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
responses for content. Content Networks rely on layer 7 protocols responses for content. Content Networks rely on layer 7 protocols
such as HTTP [4] for transport. 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 could requests for objects to a surrogate or a set of surrogates that could
skipping to change at page 3, line 44 skipping to change at page 3, line 45
example, the choice of the surrogate could be based on network example, the choice of the surrogate could be based on network
proximity, bandwidth availability, surrogate load and availability of proximity, bandwidth availability, surrogate load and availability of
content. Appendix A provides a summary of metrics and measurement content. Appendix A provides a summary of metrics and measurement
techniques that could be used in the selection of the best surrogate. techniques that could be used in the selection of the best surrogate.
The memo is organized as follows: Section 2 provides a summary of The memo is organized as follows: Section 2 provides a summary of
known DNS based Request-Routing techniques. Section 3 discusses known DNS based Request-Routing techniques. Section 3 discusses
transport-layer Request-Routing methods. In section 4 application transport-layer Request-Routing methods. In section 4 application
layer Request-Routing mechanisms are explored. Section 5 provides layer Request-Routing mechanisms are explored. Section 5 provides
insight on combining the various methods that were discussed in the insight on combining the various methods that were discussed in the
earlier sections in order to optimize the performance of the Request- earlier sections in order to optimize the performance of the
Routing System. Appendix A provides a summary of possible metrics Request-Routing System. Appendix A provides a summary of possible
and measurements techniques that could be used by the Request- metrics and measurements techniques that could be used by the
Routing system to choose a given surrogate. Request-Routing system to choose a given surrogate.
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 DNS as a directory service. 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. metrics, or a combination of both. In [11] RFC 2782 (DNS SRV)
provides guidance on the use of DNS for load balancing. The RFC
describes some of the limitations and suggests appropriate usesage of
DNS based techniques. The next sections provides a summary of some 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
skipping to change at page 4, line 52 skipping to change at page 5, line 7
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 Request- The name server authoritative for this domain might be a
Routing NS server. In this case the Request-Routing DNS server can Request-Routing NS server. In this case the Request-Routing DNS
either return a set of A records or can redirect the resolution of server can either return a set of A records or can redirect the
the request a.b.example.com to the DNS server that is authoritative resolution of the request a.b.example.com to the DNS server that is
for example.com using NS records. authoritative for example.com using NS records.
One drawback of using NS records is that the number of Request- One drawback of using NS records is that the number of
Routing DNS servers are limited by the number of parts in the DNS Request-Routing DNS servers are limited by the number of parts in
name. This problem results from DNS policy that causes a client site the DNS name. This problem results from DNS policy that causes a
DNS server to abandon a request if no additional parts of the DNS client site DNS server to abandon a request if no additional parts of
name are resolved in an exchange with an authoritative DNS server. the DNS name are resolved in an exchange with an authoritative DNS
server.
A second drawback is that the last DNS server can determine the TTL 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 record. The client will use this cached NS record for further request
request resolutions until it expires. 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 response, are discarded for security reasons. Another drawback is the
the added delay in resolving the request due to the use of multiple added delay in resolving the request due to the use of multiple DNS
DNS servers. 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 resolving the new domain name. The main advantage of this approach is
is that the number of Request-Routing DNS servers is independent of that the number of Request-Routing DNS servers is independent of the
the format of the domain name. 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 support the service, does not particularly care which server
is used. In an anycast service, a host transmits a datagram to an is used. In an anycast service, a host transmits a datagram to an
anycast address and the inter-network is responsible for providing anycast address and the inter-network is responsible for providing
best effort delivery of the datagram to at least one, and preferably best effort delivery of the datagram to at least one, and preferably
only one, of the servers that accept datagrams for the anycast only one, of the servers that accept datagrams for the anycast
address. 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 task of finding an appropriate server. For example, users, instead of
of consulting a list of servers and choosing the closest one, could 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 Request- Furthermore, to combine measurement and redirection, the
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
receive the packet containing the DNS resolution request. The server receive the packet containing the DNS resolution request. The server
can use this information to make a Request- Routing decision. can use this information to make a Request- Routing decision.
Drawbacks of this approach are listed below: Drawbacks of this approach are listed below:
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.
skipping to change at page 6, line 40 skipping to change at page 6, line 45
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 object. The obvious advantage is that object information is available
available at resolution time. The disadvantage is that the client at resolution time. The disadvantage is that the client site DNS
site DNS server has to perform multiple resolutions to retrieve a server has to perform multiple resolutions to retrieve a single Web
single Web page, which might increase rather than decrease the page, which might increase rather than decrease the overall latency.
overall latency.
2.6 DNS Request-Routing Limitations 2.6 DNS Request-Routing Limitations
Some limitations of DNS based Request-Routing techniques are This section lists some of the limitations of DNS based
described below: 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 outages. This in return may increase the volume of requests to DNS
DNS servers. 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 site DNS server. In this case, the Request-Routing DNS server will
will be exposed to the address of the DNS server that is be exposed to the address of the DNS server that is recursively
recursively requesting the information on behalf of the client's requesting the information on behalf of the client's site DNS
site DNS server. For example, imgs.example.com might be resolved server. For example, imgs.example.com might be resolved by a CN,
by a CN, but the request for the resolution might come from 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 interval. This might lead to overloading of the surrogate during a
a flash crowd. 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
limitations. For example, the use of such techniques can overburden
third party DNS servers, which should not be allowed [19]. In [11]
RFC 2782 provides warnings on the use of DNS for load balancing.
Readers are encouraged to read the RFC for better understanding of
the limitations.
3. Transport-Layer Request-Routing 3. Transport-Layer Request-Routing
At the transport-layer finer levels of granularity can be achieved by At the transport-layer finer levels of granularity can be achieved by
the close inspection of client's requests. In this approach, the the close inspection of client's requests. In this approach, the
Request-Routing system inspects the information available in the Request-Routing system inspects the information available in the
first packet of the client's request to make surrogate selection first packet of the client's request to make surrogate selection
decisions. The inspection of the client's requests provides data decisions. The inspection of the client's requests provides data
about the client's IP address, port information, and layer 4 about the client's IP address, port information, and layer 4
protocol. The acquired data could be used in combination with user- protocol. The acquired data could be used in combination with
defined policies and other metrics to determine the selection of a user-defined policies and other metrics to determine the selection of
surrogate that is better suited to serve the request. The techniques a surrogate that is better suited to serve the request. The
that are used to hand off the session to a more appropriate surrogate techniques [20][18][15] are used to hand off the session to a more
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 makes it The overhead associated with transport-layer Request-Routing [21][19]
better suited for long-lived sessions such as FTP [1]and RTSP [3]. it better suited for long-lived sessions such as FTP [1]and RTSP
However, it also could be used to direct clients away from overloaded [3]. However, it also could be used to direct clients away from
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 client's DNS server IP address. Hence, the DNS based methods could be
be used as a first step in deciding on an appropriate surrogate with 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 control down to the level of individual objects. The process could be
be performed in real time at the time of the object request. The 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 Request-
Routing systems to provide better control over the selection of the Routing systems to provide better control over the selection of the
best surrogate. 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 client request must be directed. These hints may come from the URL of
of the content or other parts of the MIME request header such as 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 requested content by its URL [6]. In many cases, this information is
is sufficient to disambiguate the content and suitably direct the 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
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 application- surrogate. Consequently, the surrogate returns an
specific code such as the 302 (in the case of HTTP [4] or RTSP [3]) application-specific code such as the 302 (in the case of HTTP [4] or
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
skipping to change at page 10, line 24 skipping to change at page 11, line 24
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. Language, and User-Agent, in order to select a surrogate. In [20]
some examples of using this technique are provided.
Cookies can be used to identify a customer or session by a web site. 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 be directed to the
same server to achieve session-level persistence. same server to achieve session-level persistence.
The language header can be used to direct traffic to a language- The language header can be used to direct traffic to a
specific delivery node. The user-agent header helps identify the language-specific delivery node. The user-agent header helps identify
type of client device. For example, a voice-browser, PDA, or cell the type of client device. For example, a voice-browser, PDA, or cell
phone can indicate the type of delivery node that has content phone can indicate the type of delivery node that has content
specialized to handle the content request. 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
skipping to change at page 11, line 11 skipping to change at page 12, line 13
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 origin server. Basically, a content provider can directly communicate
communicate to the client the best surrogate that can serve the to the client the best surrogate that can serve the request.
request. Decisions about the best surrogate can be made on a per- Decisions about the best surrogate can be made on a per-object basis
object basis or it can depend on a set of metrics. The overall goal or it can depend on a set of metrics. The overall goal is to improve
is to improve scalability and the performance for delivering the scalability and the performance for delivering the modified content,
modified content, including all embedded objects. 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 11, line 47 skipping to change at page 12, line 49
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 a software tools
that parse the content and replace embedded URLs. that 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 specifics for Request-Routing. However, it can be used in combination
combination with DNS Request-Routing to direct related DNS queries with DNS Request-Routing to direct related DNS queries into the
into the domain name space of the service provider. Dynamic Request- domain name space of the service provider. Dynamic Request-Routing
Routing based on client specifics are then done using the DNS based on client specifics are then done using the DNS approach.
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 of the client is known and can be considered when rewriting identity of the client is known and can be considered when rewriting
the embedded URLs. In particular, an automated process can the embedded URLs. In particular, an automated process can determine,
determine, on-demand, which surrogate would serve the requesting on-demand, which surrogate would serve the requesting client best.
client best. The embedded URLs can then be rewritten to direct The embedded URLs can then be rewritten to direct the client to
the client to retrieve the objects from the best surrogate rather retrieve the objects from the best surrogate rather than from the
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 the Content modification as a Request-Routing mechanism suffers from many
following limitations: 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
cacheable only for a relatively short period of time. Rewritten cacheable only for a relatively short period of time. Rewritten
URLs on cached pages can cause problems, because they can get URLs on cached pages can cause problems, because they can get
outdated and point to surrogates that are no longer available or outdated and point to surrogates that are no longer available or
skipping to change at page 14, line 9 skipping to change at page 15, line 9
can be used together with DNS Request-Routing to overcome this can be used together with DNS Request-Routing to overcome this
problem. With content modification, references to different objects problem. With content modification, references to different objects
on the same origin server can be rewritten to point into different on the same origin server can be rewritten to point into different
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. The document acknowledges that security implemented in the Internet. However, security must be addressed by
must be addressed by any entity that implements any technique that any entity that implements any technique that redirects client's
redirects client's requests. In [9] RFC 3238 addresses the main requests. In [9] RFC 3238 addresses the main requirements for
requirements for entities that intent to modify requests for content entities that intent to modify requests for content in the Internet.
in the Internet.
The details of security techniques are beyond the scope of this Some active probing techniques will set off intrusion detection
document. systems and firewalls. Therefore, it is recommended that implementers
be aware of routing protocol security [25].
It is important to note the impact of TLS [2] on request routing in
CNs. Specifically, when TLS is used the full URL is not visible to
the content network unless it terminates the TLS session. The current
document focuses on HTTP techniques. TLS based techniques that
require the termination of TLS sessions on Content Peering Gateways
[8] are out of scope.
Furthermore, the details of security techniques are beyond the scope
of this 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).
skipping to change at page 16, line 27 skipping to change at page 17, line 27
[5] C. Partridge et al., "Host Anycasting Service", RFC 1546, [5] C. Partridge et al., "Host Anycasting Service", RFC 1546,
November 1993. November 1993.
[6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC [6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC
1738, May 1994. 1738, May 1994.
[7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time [7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996. Applications", RFC 1889, January 1996.
[8] M. Day et al, "A Model for Content Internetworking (CDI)", [8] M. Day et al, "A Model for Content Internetworking (CDI)", RFC
Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf- 3466 , February 2003.
cdi-model-02.txt (groups Last Call), May 2002.
[9] S. Floyd et al, "IAB Architectural and Policy Considerations for [9] S. Floyd et al, "IAB Architectural and Policy Considerations for
Open Pluggable Edge Services", RFC 3238, January 2002. Open Pluggable Edge Services", RFC 3238, January 2002.
Informative References Informative References
[10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606, [10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,
June 1999. June 1999.
Authors' Addresses [11] A. Gulbrandsen et al, "A DNS RR for specifying the location of
services (DNS SRV)", RFC 2782, February 2002.
Brad Cain [12] P. Mockapetris, "Domain names - concepts and facilities", RFC
Storigen Systems 1034, November 1987.
650 Suffolk Street
Lowell, MA 01854
USA
Phone: +1 978-323-4454 [13] P. Mockapetris, "Domain names - concepts and facilities", RFC
EMail: bcain@storigen.com 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 Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario K2H 8E9 Nepean, Ontario K2H 8E9
Canada Canada
Phone: +1 613 763 5229 Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com 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 Raj Nair
Cisco Cisco
50 Nagog Park 50 Nagog Park
Acton, MA 01720 Acton, MA 01720
USA USA
EMail: rnair@cisco.com EMail: rnair@cisco.com
Oliver Spatscheck Oliver Spatscheck
AT&T AT&T
180 Park Ave, Bldg 103 180 Park Ave, Bldg 103
Florham Park, NJ 07932 Florham Park, NJ 07932
USA USA
EMail: spatsch@research.att.com EMail: spatsch@research.att.com
Appendix A. Measurements Appendix A. Measurements
skipping to change at page 18, line 18 skipping to change at page 21, line 18
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 a DNS Request-Routing direct users to the "closest" surrogate. In this document proximity
system, the measurements are made to the client's local DNS server. means round-trip time. In a DNS Request-Routing system, the
However, when the IP address of the client is accessible more measurements are made to the client's local DNS server. However, when
accurate proximity measurements can be obtained. the IP address of the client is accessible more accurate proximity
measurements can be obtained [24].
Furthermore, proximity measurements can be exchanged between Proximity measurements can be exchanged between surrogates and the
surrogates and the requesting entity. In many cases, proximity requesting entity. In many cases, proximity measurements are
measurements are "one-way" in that they measure either the forward or "one-way" in that they measure either the forward or reverse path of
reverse path of packets from the surrogate to the requesting entity. packets from the surrogate to the requesting entity. This is
This is important as many paths in the Internet are asymmetric. 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 and/or passive measurement employ active probing techniques.
techniques. The following sections describe these two 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 addresses can be cached for later probing. Another potential solution
solution is to use an algorithm to divide address space into blocks is to use an algorithm to divide address space into blocks and to
and to probe random addresses within those blocks. Limitations of probe random addresses within those blocks. Limitations of active
active probing techniques include: 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 Passive Measurement A.1.2 Metric Types
Passive measurements could be obtained when a client performs data
transfers to or from a surrogate. Here, a bootstrap mechanism is
used to direct the client to a bootstrap surrogate. Once the client
connects, the actual performance of the transfer is measured. This
data is then fed back into the Request-Routing system.
An example of passive measurement is to watch the packet loss from a
client to a surrogate by observing TCP behavior. Latency
measurements can also be learned by observing TCP behavior. The
limitations of passive measurement approach are directly related to
the bootstrapping mechanism. Basically, a good mechanism is needed
to ensure that not every surrogate is tested per client in order to
obtain the data.
A.1.3 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 either an active probing approach or a obtained using active probing techniques.
passive network measurement system.
o Packet Loss: Packet loss measurements can be used as a selection
metric. A passive measurement approach can easily obtain packet
loss information from TCP header information. Active probing can
periodically measure packet loss from probes.
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.
A.1.4 Surrogate Feedback It is important to note that the value of BGP AS PATH information can
be meaningless as a good selection metric [24].
A.1.3 Surrogate Feedback
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.4.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.
A.1.4.2 Well Known Metrics Intellectual Property Statement
The following provides a list of several of the popular metrics that
are used for surrogate feedback:
o Surrogate CPU Load.
o Interface Load/Dropped packets.
o Number of connections being served. The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
o Storage I/O Load. The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). 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
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 59 change blocks. 
206 lines changed or deleted 270 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/