doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3568.txt b/doc/rfc/rfc3568.txt
new file mode 100644
index 0000000..5274106
--- /dev/null
+++ b/doc/rfc/rfc3568.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                          A. Barbir
+Request for Comments: 3568                               Nortel Networks
+Category: Informational                                          B. Cain
+                                                        Storigen Systems
+                                                                 R. Nair
+                                                              Consultant
+                                                           O. Spatscheck
+                                                                    AT&T
+                                                               July 2003
+
+
+         Known Content Network (CN) Request-Routing Mechanisms
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document presents a summary of Request-Routing techniques that
+   are used to direct client requests to surrogates based on various
+   policies and a possible set of metrics.  The document covers
+   techniques that were commonly used in the industry on or before
+   December 2000.  In this memo, the term Request-Routing represents
+   techniques that is commonly called content routing or content
+   redirection.  In principle, Request-Routing techniques can be
+   classified under: DNS Request-Routing, Transport-layer
+   Request-Routing, and Application-layer Request-Routing.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
+       2.1.  Single Reply . . . . . . . . . . . . . . . . . . . . . 3
+       2.2.  Multiple Replies . . . . . . . . . . . . . . . . . . . 3
+       2.3.  Multi-Level Resolution . . . . . . . . . . . . . . . . 4
+             2.3.1.  NS Redirection . . . . . . . . . . . . . . . . 4
+             2.3.2.  CNAME Redirection. . . . . . . . . . . . . . . 5
+       2.4.  Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
+       2.5.  Object Encoding. . . . . . . . . . . . . . . . . . . . 6
+       2.6.  DNS Request-Routing Limitations. . . . . . . . . . . . 6
+   3.  Transport-Layer Request-Routing  . . . . . . . . . . . . . . 7
+
+
+
+Barbir, et al.               Informational                      [Page 1]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   4.  Application-Layer Request-Routing  . . . . . . . . . . . . . 8
+       4.1.  Header Inspection. . . . . . . . . . . . . . . . . . . 8
+             4.1.1.  URL-Based Request-Routing. . . . . . . . . . . 8
+             4.1.2.  Header-Based Request-Routing . . . . . . . . . 9
+             4.1.3.  Site-Specific Identifiers. . . . . . . . . . .10
+       4.2.  Content Modification . . . . . . . . . . . . . . . . .10
+             4.2.1.  A-priori URL Rewriting . . . . . . . . . . . .11
+             4.2.2.  On-Demand URL Rewriting. . . . . . . . . . . .11
+             4.2.3.  Content Modification Limitations . . . . . . .11
+   5.  Combination of Multiple Mechanisms . . . . . . . . . . . . .11
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . .12
+   7.  Additional Authors and Acknowledgements  . . . . . . . . . .12
+   A.  Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
+       A.1.  Proximity Measurements . . . . . . . . . . . . . . . .13
+             A.1.1.  Active Probing . . . . . . . . . . . . . . . .13
+             A.1.2.  Metric Types . . . . . . . . . . . . . . . . .14
+             A.1.3.  Surrogate Feedback . . . . . . . . . . . . . .14
+   8.  Normative References . . . . . . . . . . . . . . . . . . . .15
+   9.  Informative References . . . . . . . . . . . . . . . . . . .15
+   10. Intellectual Property and Copyright Statements . . . . . . .17
+   11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
+   12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
+
+1.  Introduction
+
+   This document provides a summary of known request routing techniques
+   that are used by the industry before December 2000.  Request routing
+   techniques are generally used to direct client requests to surrogates
+   based on various policies and a possible set of metrics.  The task of
+   directing clients' requests to surrogates is also called
+   Request-Routing, Content Routing or Content Redirection.
+
+   Request-Routing techniques are commonly used in Content Networks
+   (also known as Content Delivery Networks) [8].  Content Networks
+   include network infrastructure that exists in layers 4 through 7.
+   Content Networks deal with the routing and forwarding of requests and
+   responses for content. Content Networks rely on layer 7 protocols
+   such as HTTP [4] for transport.
+
+   Request-Routing techniques are generally used to direct client
+   requests for objects to a surrogate or a set of surrogates that could
+   best serve that content.  Request-Routing mechanisms could be used to
+   direct client requests to surrogates that are within a Content
+   Network (CN) [8].
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 2]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   Request-Routing techniques are used as a vehicle to extend the reach
+   and scale of Content Delivery Networks.  There exist multiple
+   Request-Routing mechanisms.  At a high-level, these may be classified
+   under: DNS Request-Routing, transport-layer Request-Routing, and
+   application-layer Request-Routing.
+
+   A request routing system uses a set of metrics in an attempt to
+   direct users to surrogate that can best serve the request.  For
+   example, the choice of the surrogate could be based on network
+   proximity, bandwidth availability, surrogate load and availability of
+   content.  Appendix A provides a summary of metrics and measurement
+   techniques that could be used in the selection of the best surrogate.
+
+   The memo is organized as follows: Section 2 provides a summary of
+   known DNS based Request-Routing techniques.  Section 3 discusses
+   transport-layer Request-Routing methods.  In section 4 application
+   layer Request-Routing mechanisms are explored.  Section 5 provides
+   insight on combining the various methods that were discussed in the
+   earlier sections in order to optimize the performance of the
+   Request-Routing System.  Appendix A provides a summary of possible
+   metrics and measurements techniques that could be used by the
+   Request-Routing system to choose a given surrogate.
+
+2.  DNS based Request-Routing Mechanisms
+
+   DNS based Request-Routing techniques are common due to the ubiquity
+   of the DNS system [10][12][13].  In DNS based Request-Routing
+   techniques, a specialized DNS server is inserted in the DNS
+   resolution process.  The server is capable of returning a different
+   set of A, NS or CNAME records based on user defined policies,
+   metrics, or a combination of both.  In [11] RFC 2782 (DNS SRV)
+   provides guidance on the use of DNS for load balancing.  The RFC
+   describes some of the limitations and suggests appropriate useage of
+   DNS based techniques.  The next sections provides a summary of some
+   of the used techniques.
+
+2.1.  Single Reply
+
+   In this approach, the DNS server is authoritative for the entire DNS
+   domain or a sub domain.  The DNS server returns the IP address of the
+   best surrogate in an A record to the requesting DNS server.  The IP
+   address of the surrogate could also be a virtual IP(VIP) address of
+   the best set of surrogates for requesting DNS server.
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 3]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+2.2.  Multiple Replies
+
+   In this approach, the Request-Routing DNS server returns multiple
+   replies such as several A records for various surrogates.  Common
+   implementations of client site DNS server's cycles through the
+   multiple replies in a Round-Robin fashion.  The order in which the
+   records are returned can be used to direct multiple clients using a
+   single client site DNS server.
+
+2.3.  Multi-Level Resolution
+
+   In this approach multiple Request-Routing DNS servers can be involved
+   in a single DNS resolution.  The rationale of utilizing multiple
+   Request-Routing DNS servers in a single DNS resolution is to allow
+   one to distribute more complex decisions from a single server to
+   multiple, more specialized, Request-Routing DNS servers.  The most
+   common mechanisms used to insert multiple Request-Routing DNS servers
+   in a single DNS resolution is the use of NS and CNAME records.  An
+   example would be the case where a higher level DNS server operates
+   within a territory, directing the DNS lookup to a more specific DNS
+   server within that territory to provide a more accurate resolution.
+
+2.3.1.  NS Redirection
+
+   A DNS server can use NS records to redirect the authority of the next
+   level domain to another Request-Routing DNS server.  The, technique
+   allows multiple DNS server to be involved in the name resolution
+   process.  For example, a client site DNS server resolving
+   a.b.example.com [10] would eventually request a resolution of
+   a.b.example.com from the name server authoritative for example.com.
+   The name server authoritative for this domain might be a
+   Request-Routing NS server.  In this case the Request-Routing DNS
+   server can either return a set of A records or can redirect the
+   resolution of the request a.b.example.com to the DNS server that is
+   authoritative for example.com using NS records.
+
+   One drawback of using NS records is that the number of
+   Request-Routing DNS servers are limited by the number of parts in the
+   DNS name.  This problem results from DNS policy that causes a client
+   site DNS server to abandon a request if no additional parts of the
+   DNS name are resolved in an exchange with an authoritative DNS
+   server.
+
+   A second drawback is that the last DNS server can determine the TTL
+   of the entire resolution process.  Basically, the last DNS server can
+   return in the authoritative section of its response its own NS
+   record.  The client will use this cached NS record for further
+   request resolutions until it expires.
+
+
+
+Barbir, et al.               Informational                      [Page 4]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   Another drawback is that some implementations of bind voluntarily
+   cause timeouts to simplify their implementation in cases in which a
+   NS level redirect points to a name server for which no valid A record
+   is returned or cached.  This is especially a problem if the domain of
+   the name server does not match the domain currently resolved, since
+   in this case the A records, which might be passed in the DNS
+   response, are discarded for security reasons.  Another drawback is
+   the added delay in resolving the request due to the use of multiple
+   DNS servers.
+
+2.3.2.  CNAME Redirection
+
+   In this scenario, the Request-Routing DNS server returns a CNAME
+   record to direct resolution to an entirely new domain.  In principle,
+   the new domain might employ a new set of Request-Routing DNS servers.
+
+   One disadvantage of this approach is the additional overhead of
+   resolving the new domain name.  The main advantage of this approach
+   is that the number of Request-Routing DNS servers is independent of
+   the format of the domain name.
+
+2.4.  Anycast
+
+   Anycast [5] is an inter-network service that is applicable to
+   networking situations where a host, application, or user wishes to
+   locate a host which supports a particular service but, if several
+   servers utilizes the service, it does not particularly care which
+   server is used.  In an anycast service, a host transmits a datagram
+   to an anycast address and the inter-network is responsible for
+   providing best effort delivery of the datagram to at least one, and
+   preferably only one, of the servers that accept datagrams for the
+   anycast address.
+
+   The motivation for anycast is that it considerably simplifies the
+   task of finding an appropriate server.  For example, users, instead
+   of consulting a list of servers and choosing the closest one, could
+   simply type the name of the server and be connected to the nearest
+   one.  By using anycast, DNS resolvers would no longer have to be
+   configured with the IP addresses of their servers, but rather could
+   send a query to a well-known DNS anycast address.
+
+   Furthermore, to combine measurement and redirection, the
+   Request-Routing DNS server can advertise an anycast address as its IP
+   address.  The same address is used by multiple physical DNS servers.
+   In this scenario, the Request-Routing DNS server that is the closest
+   to the client site DNS server in terms of OSPF and BGP routing will
+   receive the packet containing the DNS resolution request.  The server
+   can use this information to make a Request-Routing decision.
+
+
+
+Barbir, et al.               Informational                      [Page 5]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   Drawbacks of this approach are listed below:
+
+   o  The DNS server may not be the closest server in terms of routing
+      to the client.
+
+   o  Typically, routing protocols are not load sensitive.  Hence, the
+      closest server may not be the one with the least network latency.
+
+   o  The server load is not considered during the Request-Routing
+      process.
+
+2.5.  Object Encoding
+
+   Since only DNS names are visible during the DNS Request-Routing, some
+   solutions encode the object type, object hash, or similar information
+   into the DNS name.  This might vary from a simple division of objects
+   based on object type (such as images.a.b.example.com and
+   streaming.a.b.example.com) to a sophisticated schema in which the
+   domain name contains a unique identifier (such as a hash) of the
+   object.  The obvious advantage is that object information is
+   available at resolution time.  The disadvantage is that the client
+   site DNS server has to perform multiple resolutions to retrieve a
+   single Web page, which might increase rather than decrease the
+   overall latency.
+
+2.6.  DNS Request-Routing Limitations
+
+   This section lists some of the limitations of DNS based
+   Request-Routing techniques.
+
+   o  DNS only allows resolution at the domain level.  However, an ideal
+      request resolution system should service requests per object
+      level.
+
+   o  In DNS based Request-Routing systems servers may be required to
+      return DNS entries with a short time-to-live (TTL) values.  This
+      may be needed in order to be able to react quickly in the face of
+      outages.  This in return may increase the volume of requests to
+      DNS servers.
+
+   o  Some DNS implementations do not always adhere to DNS standards.
+      For example, many DNS implementations do not honor the DNS TTL
+      field.
+
+   o  DNS Request-Routing is based only on knowledge of the client DNS
+      server, as client addresses are not relayed within DNS requests.
+      This limits the ability of the Request-Routing system to determine
+      a client's proximity to the surrogate.
+
+
+
+Barbir, et al.               Informational                      [Page 6]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   o  DNS servers can request and allow recursive resolution of DNS
+      names.  For recursive resolution of requests, the Request-Routing
+      DNS server will not be exposed to the IP address of the client's
+      site DNS server.  In this case, the Request-Routing DNS server
+      will be exposed to the address of the DNS server that is
+      recursively requesting the information on behalf of the client's
+      site DNS server.  For example, imgs.example.com might be resolved
+      by a CN, but the request for the resolution might come from
+      dns1.example.com as a result of the recursion.
+
+   o  Users that share a single client site DNS server will be
+      redirected to the same set of IP addresses during the TTL
+      interval.  This might lead to overloading of the surrogate during
+      a flash crowd.
+
+   o  Some implementations of bind can cause DNS timeouts to occur while
+      handling exceptional situations.  For example, timeouts can occur
+      for NS redirections to unknown domains.
+
+   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
+
+   At the transport-layer finer levels of granularity can be achieved by
+   the close inspection of client's requests.  In this approach, the
+   Request-Routing system inspects the information available in the
+   first packet of the client's request to make surrogate selection
+   decisions.  The inspection of the client's requests provides data
+   about the client's IP address, port information, and layer 4
+   protocol.  The acquired data could be used in combination with
+   user-defined policies and other metrics to determine the selection of
+   a surrogate that is better suited to serve the request.  The
+   techniques [20][18][15] are used to hand off the session to a more
+   appropriate surrogate are beyond the scope of this document.
+
+   In general, the forward-flow traffic (client to newly selected
+   surrogate) will flow through the surrogate originally chosen by DNS.
+   The reverse-flow (surrogate to client) traffic, which normally
+   transfers much more data than the forward flow, would typically take
+   the direct path.
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 7]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   The overhead associated with transport-layer Request-Routing [21][19]
+   is better suited  for long-lived sessions such as FTP [1] and RTSP
+   [3].  However, it also could be used to direct clients away from
+   overloaded surrogates.
+
+   In general, transport-layer Request-Routing can be combined with DNS
+   based techniques.  As stated earlier, DNS based methods resolve
+   clients requests based on domains or sub domains with exposure to the
+   client's DNS server IP address.  Hence, the DNS based methods could
+   be used as a first step in deciding on an appropriate surrogate with
+   more accurate refinement made by the transport-layer Request-Routing
+   system.
+
+4.  Application-Layer Request-Routing
+
+   Application-layer Request-Routing systems perform deeper examination
+   of client's packets beyond the transport layer header.  Deeper
+   examination of client's packets provides fine-grained Request-Routing
+   control down to the level of individual objects.  The process could
+   be performed in real time at the time of the object request.  The
+   exposure to the client's IP address combined with the fine-grained
+   knowledge of the requested objects enable application-layer
+   Request-Routing systems to provide better control over the selection
+   of the best surrogate.
+
+4.1.  Header Inspection
+
+   Some application level protocols such as HTTP [4], RTSP [3], and SSL
+   [2] provide hints in the initial portion of the session about how the
+   client request must be directed.  These hints may come from the URL
+   of the content or other parts of the MIME request header such as
+   Cookies.
+
+4.1.1.  URL-Based Request-Routing
+
+   Application level protocols such as HTTP and RTSP describe the
+   requested  content by its URL [6].  In many cases, this information
+   is sufficient to disambiguate the content and suitably direct the
+   request.  In most cases, it may be sufficient to make Request-Routing
+   decision just by examining the prefix or suffix of the URL.
+
+4.1.1.1.  302 Redirection
+
+   In this approach, the client's request is first resolved to a virtual
+   surrogate.  Consequently, the surrogate returns an
+   application-specific code such as the 302 (in the case of HTTP [4] or
+   RTSP [3]) to redirect the client to the actual delivery node.
+
+
+
+
+Barbir, et al.               Informational                      [Page 8]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   This technique is relatively simple to implement.  However, the main
+   drawback of this method is the additional latency involved in sending
+   the redirect message back to the client.
+
+4.1.1.2.  In-Path Element
+
+   In this technique, an In-Path element is present in the network in
+   the forwarding path of the client's request.  The In-Path element
+   provides transparent interception of the transport connection.  The
+   In-Path element examines the client's content requests and performs
+   Request-Routing decisions.
+
+   The In-Path element then splices the client connection to a
+   connection with the appropriate delivery node and passes along the
+   content request.  In general, the return path would go through the
+   In-Path element.  However, it is possible to arrange for a direct
+   return by passing the address translation information to the
+   surrogate or delivery node through some proprietary means.
+
+   The primary disadvantage with this method is the performance
+   implications of URL-parsing in the path of the network traffic.
+   However, it is generally the case that the return traffic is much
+   larger than the forward traffic.
+
+   The technique allows for the possibility of partitioning the traffic
+   among a set of delivery nodes by content objects identified by URLs.
+   This allows object-specific control of server loading.  For example,
+   requests for non-cacheable object types may be directed away from a
+   cache.
+
+4.1.2.  Header-Based Request-Routing
+
+   This technique involves the task of using HTTP [4] such as Cookie,
+   Language, and User-Agent, in order to select a surrogate.  In [20]
+   some examples of using this technique are provided.
+
+   Cookies can be used to identify a customer or session by a web site.
+   Cookie based Request-Routing provides content service differentiation
+   based on the client.  This approach works provided that the cookies
+   belong to the client.  In addition, it is possible to direct a
+   connection from a multi-session transaction to the same server to
+   achieve session-level persistence.
+
+   The language header can be used to direct traffic to a
+   language-specific delivery node.  The user-agent header helps
+   identify the type of client device.  For example, a voice-browser,
+   PDA, or cell phone can indicate the type of delivery node that has
+   content specialized to handle the content request.
+
+
+
+Barbir, et al.               Informational                      [Page 9]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+4.1.3.  Site-Specific Identifiers
+
+   Site-specific identifiers help authenticate and identify a session
+   from a specific user.  This information may be used to direct a
+   content request.
+
+   An example of a site-specific identifier is the SSL Session
+   Identifier.  This identifier is generated by a web server and used by
+   the web client in succeeding sessions to identify itself and avoid an
+   entire security authentication exchange.  In order to inspect the
+   session identifier, an In-Path element would observe the responses of
+   the web server and determine the session identifier which is then
+   used to associate the session to a specific server.  The remaining
+   sessions are directed based on the stored session identifier.
+
+4.2.  Content Modification
+
+   This technique enables a content provider to take direct control over
+   Request-Routing decisions without the need for specific witching
+   devices or directory services in the path between the client and the
+   origin server.  Basically, a content provider can directly
+   communicate to the client the best surrogate that can serve the
+   request.  Decisions about the best surrogate can be made on a per-
+   object basis or it can depend on a set of metrics.  The overall goal
+   is to improve scalability and the performance for delivering the
+   modified content, including all embedded objects.
+
+   In general, the method takes advantage of content objects that
+   consist of basic structure that includes references to additional,
+   embedded objects.  For example, most web pages, consist of an HTML
+   document that contains plain text together with some embedded
+   objects, such as GIF or JPEG images.  The embedded objects are
+   referenced using embedded HTML directives.  In general, embedded HTML
+   directives direct the client to retrieve the embedded objects from
+   the origin server.  A content provider can now modify references to
+   embedded objects such that they could be fetched from the best
+   surrogate.  This technique is also known as URL rewriting.
+
+   Content modification techniques must not violate the architectural
+   concepts of the Internet [9].  Special considerations must be made to
+   ensure that the task of modifying the content is performed in a
+   manner that is consistent with RFC 3238 [9] that specifies the
+   architectural considerations for intermediaries that perform
+   operations or modifications on content.
+
+   The basic types of URL rewriting are discussed in the following
+   subsections.
+
+
+
+
+Barbir, et al.               Informational                     [Page 10]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+4.2.1.  A-priori URL Rewriting
+
+   In this scheme, a content provider rewrites the embedded URLs before
+   the content is positioned on the origin server.  In this case, URL
+   rewriting can be done either manually or by using software tools that
+   parse the content and replace embedded URLs.
+
+   A-priori URL rewriting alone does not allow consideration of client
+   specifics for Request-Routing.  However, it can be used in
+   combination with DNS Request-Routing to direct related DNS queries
+   into the domain name space of the service provider.  Dynamic
+   Request-Routing based on client specifics are then done using the DNS
+   approach.
+
+4.2.2.  On-Demand URL Rewriting
+
+   On-Demand or dynamic URL rewriting, modifies the content when the
+   client request reaches the origin server.  At this time, the identity
+   of the client is known and can be considered when rewriting the
+   embedded URLs.  In particular, an automated process can determine,
+   on-demand, which surrogate would serve the requesting client best.
+   The embedded URLs can then be rewritten to direct the client to
+   retrieve the objects from the best surrogate rather than from the
+   origin server.
+
+4.2.3.  Content Modification Limitations
+
+   Content modification as a Request-Routing mechanism suffers from many
+   limitation [23].  For example:
+
+   o  The first request from a client to a specific site must be served
+      from the origin server.
+
+   o  Content that has been modified to include references to nearby
+      surrogates rather than to the origin server should be marked as
+      non-cacheable.  Alternatively, such pages can be marked to be
+      cacheable only for a relatively short period of time.  Rewritten
+      URLs on cached pages can cause problems, because they can get
+      outdated and point to surrogates that are no longer available or
+      no longer good choices.
+
+5.  Combination of Multiple Mechanisms
+
+   There are environments in which a combination of different mechanisms
+   can be beneficial and advantageous over using one of the proposed
+   mechanisms alone.  The following example illustrates how the
+   mechanisms can be used in combination.
+
+
+
+
+Barbir, et al.               Informational                     [Page 11]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   A basic problem of DNS Request-Routing is the resolution granularity
+   that allows resolution on a per-domain level only.  A per-object
+   redirection cannot easily be achieved.  However, content modification
+   can be used together with DNS Request-Routing to overcome this
+   problem.  With content modification, references to different objects
+   on the same origin server can be rewritten to point into different
+   domain name spaces.  Using DNS Request-Routing, requests for those
+   objects can now dynamically be directed to different surrogates.
+
+6.  Security Considerations
+
+   The main objective of this document is to provide a summary of
+   current Request-Routing techniques.  Such techniques are currently
+   implemented in the Internet.  However, security must be addressed by
+   any entity that implements any technique that redirects client's
+   requests.  In [9] RFC 3238 addresses the main requirements for
+   entities that intend to modify requests for content in the Internet.
+
+   Some active probing techniques will set off intrusion detection
+   systems and firewalls.  Therefore, it is recommended that
+   implementers be aware of routing protocol security [25].
+
+   It is important to note the impact of TLS [2] on request routing in
+   CNs.  Specifically, when TLS is used the full URL is not visible to
+   the content network unless it terminates the TLS session.  The
+   current document focuses on HTTP techniques.  TLS based techniques
+   that require the termination of TLS sessions on Content Peering
+   Gateways [8] are beyond the of scope of this document.
+
+   The details of security techniques are also beyond the scope of this
+   document.
+
+7.  Additional Authors and Acknowledgements
+
+   The following people have contributed to the task of authoring this
+   document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann
+   (Lucent), Doug Potter.
+
+   The authors acknowledge the contributions and comments of Ian Cooper,
+   Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean
+   (CrystalBall).
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 12]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+Appendix A.  Measurements
+
+   Request-Routing systems can use a variety of metrics in order to
+   determine the best surrogate that can serve a client's request.  In
+   general, these metrics are based on network measurements and feedback
+   from surrogates.  It is possible to combine multiple metrics using
+   both proximity and surrogate feedback for best surrogate selection.
+   The following sections describe several well known metrics as well as
+   the major techniques for obtaining them.
+
+A.1.  Proximity Measurements
+
+   Proximity measurements can be used by the Request-Routing system to
+   direct users to the "closest" surrogate.  In this document proximity
+   means round-trip time.  In a DNS Request-Routing system, the
+   measurements are made to the client's local DNS server.  However,
+   when the IP address of the client is accessible more accurate
+   proximity measurements can be obtained [24].
+
+   Proximity measurements can be exchanged between surrogates and the
+   requesting entity.  In many cases, proximity measurements are
+   "one-way" in that they measure either the forward or reverse path of
+   packets from the surrogate to the requesting entity.  This is
+   important as many paths in the Internet are asymmetric [24].
+
+   In order to obtain a set of proximity measurements, a network may
+   employ active probing techniques.
+
+A.1.1.  Active Probing
+
+   Active probing is when past or possible requesting entities are
+   probed using one or more techniques to determine one or more metrics
+   from each surrogate or set of surrogates.  An example of a probing
+   technique is an ICMP ECHO Request that is periodically sent from each
+   surrogate or set of surrogates to a potential requesting entity.
+
+   In any active probing approach, a list of potential requesting
+   entities need to be obtained.  This list can be generated
+   dynamically.  Here, as requests arrive, the requesting entity
+   addresses can be cached for later probing.  Another potential
+   solution is to use an algorithm to divide address space into blocks
+   and to probe random addresses within those blocks.  Limitations of
+   active probing techniques include:
+
+   o  Measurements can only be taken periodically.
+
+   o  Firewalls and NATs disallow probes.
+
+
+
+
+Barbir, et al.               Informational                     [Page 13]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   o  Probes often cause security alarms to be triggered on intrusion
+      detection systems.
+
+A.1.2.  Metric Types
+
+   The following sections list some of the metrics, which can be used
+   for proximity calculations.
+
+   o  Latency: Network latency measurements metrics are used to
+      determine the surrogate (or set of surrogates) that has the least
+      delay to the requesting entity.  These measurements can be
+      obtained using active probing techniques.
+
+   o  Hop Counts: Router hops from the surrogate to the requesting
+      entity can be used as a proximity measurement.
+
+   o  BGP Information: BGP AS PATH and MED attributes can be used to
+      determine the "BGP distance" to a given prefix/length pair.  In
+      order to use BGP information for proximity measurements, it must
+      be obtained at each surrogate site/location.
+
+   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
+   delivered from each surrogate or can be aggregated by site or by
+   location.
+
+A.1.3.1.  Probing
+
+   Feedback information may be obtained by periodically probing a
+   surrogate by issuing an HTTP request and observing the behavior.  The
+   problems with probing for surrogate information are:
+
+   o  It is difficult to obtain "real-time" information.
+
+   o  Non-real-time information may be inaccurate.
+
+   Consequently, feedback information can be obtained by agents that
+   reside on surrogates that can communicate a variety of metrics about
+   their nodes.
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 14]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+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.
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 15]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+   [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.
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 16]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+10.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 17]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 18]
+
+RFC 3568          Known CN Request-Routing Mechanisms          July 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 19]
+