rfc-editor | 28 Jul 23:44 2003

RFC 3570 on Content Internetworking (CDI) Scenarios


A new Request for Comments is now available in online RFC libraries.

        RFC 3570

        Title:      Content Internetworking (CDI) Scenarios
        Author(s):  P. Rzewski, M. Day, D. Gilletti
        Status:     Informational
        Date:       July 2003
        Mailbox:    philrz <at> yahoo.com, mday <at> alum.mit.edu,
                    dgilletti <at> yahoo.com
        Pages:      20
        Characters: 42432
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-cdi-scenarios-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3570.txt

In describing content internetworking as a technology targeted for
use in production networks, it is useful to provide examples of the
sequence of events that may occur when two content networks decide
to interconnect.  The scenarios presented here seek to provide some
concrete examples of what content internetworking is, and also to
provide a basis for evaluating content internetworking proposals.

This document is a product of the Content Distribution Internetworking
Working Group of the IETF.

This memo provides information for the Internet community.  It does
(Continue reading)

rfc-editor | 23 Jul 20:16 2003

RFC 3568 on Known Content Network (CN) Request-Routing Mechanisms


A new Request for Comments is now available in online RFC libraries.

        RFC 3568

        Title:      Known Content Network (CN) Request-Routing
                    Mechanisms
        Author(s):  A. Barbir, B. Cain, R. Nair, O. Spatscheck
        Status:     Informational
        Date:       July 2003
        Mailbox:    abbieb <at> nortelnetworks.com, bcain <at> storigen.com,
                    nair_raj <at> yahoo.com, spatsch <at> research.att.com
        Pages:      19
        Characters: 42443
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-cdi-known-request-routing-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3568.txt

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.

(Continue reading)

Mark Day | 3 Jul 19:18 2003
Picon

Seeking Don Gilletti

We're in the final editorial stages for the CDI Scenarios document.  We do
not have any current contact information for Don Gilletti, formerly of
Entera and Cacheflow.

I would appreciate private email with any leads people can offer me in
finding him.  We can't publish the RFC until all listed authors have given
their OK.

Thanks,

--Mark

The IESG | 3 Jun 20:13 2003
Picon

WG Action: Content Distribution Internetworking (cdi) to conclude

The Content Distribution Internetworking (cdi) Working Group in the 
Applications Area of the IETF has concluded.

The IESG contact persons are Ned Freed and Ted Hardie.

CDI's original goal was to define protocols to allow separately administered
content networks to interoperate. Its initial charter was limited to the
description of requirements, models, and scenarios. It was anticipated
that the group would re-charter when that work was complete, in
order to develop the protocols themselves.

The group developed a set of scenarios, a taxonomy of request routing
mechanisms known at a set point in time, and a document containing
an abstract model of content network interworking. These documents are
forthcoming as Informational RFCs. The other milestones for the 
group will not be
met, as the Chair, document authors, and IESG have agreed that there
is insufficient energy in the group to carry the work forward. The IESG also
agreed to close the group in advance of the publication of the Informational
RFCs still in queue, as it believes that any issues raised by the RFC Editor
will need to be resolved by the authors rather than in this forum.

Daniel Harris | 28 May 16:28 2003
Picon

New Kendra Trials launch: Commerce, Catalogue, Rules, Interface...

Hi there All,

Permit me one email to inform you about the current status of Kendra 
Initiative. We invite CDNs to come and join the current Kendra Network 
Trial and other industry players to check out the 4 new trials...

1. Introduction
2. Commerce Trial overview
3. Catalogue Trial overview
4. Rules Trial overview
5. Interface Trial overview
6. kendraTools and kendraBase: collaborative software development
7. License Of Responsibility: free (open source) software license
8. How you can help: spread the word

1. Introduction

As you know we are building an open platform for content distribution. 
We are soft launching our new Commerce, Catalogue, Rules and Interface 
trials over the next few months and will be targeting specific groups 
during this period to drive participation. Here is a brief idea of what 
to expect...

2. Commerce Trial overview

The Kendra Commerce Trial will seek to drive interoperability between 
different payment service providers and subscription service providers. 
We'll be calling on banks, payment providers, electronic cash providers 
and subscription providers to discuss how they can bring about 
interoperability by defining their common business practices. For 
(Continue reading)

The IESG | 22 May 21:05 2003
Picon

Document Action: Content Internetworking (CDI) Scenarios to Informational


The IESG has approved the Internet-Draft 'Content Internetworking (CDI)
Scenarios' <draft-ietf-cdi-scenarios-01.txt> as an Informational RFC.
This document is the product of the Content Distribution 
Internetworking Working Group. The IESG contact persons are Ned Freed 
and Ted Hardie.

Technical Summary

This document presents scenarios for content internetworking,
in order to provide concrete examples of what may happen
when two content networks interconnect. This work was originally
intended to be part of the evaluation process for a standards-track
protocol for content internetworking. While the IETF does not
foresee pursuing continued work on content internetworking
at this time, this document provides both useful scenarios for 
understanding the rational behind the original work and a record of 
the working group's thinking.

Working Group Summary

There was consensus in the working group for this as
an Informational document.

Protocol Quality

This document was reviewed for the IESG by Ted Hardie.

RFC Editor Note:

(Continue reading)

The IESG | 2 May 21:04 2003
Picon

Document Action: Known CN Request-Routing Mechanisms to Informational


The IESG has approved the Internet-Draft 'Known CN Request-Routing 
Mechanisms' <draft-ietf-cdi-known-request-routing-03.txt> as an 
Informational RFC.  This document is the product of the Content 
Distribution Internetworking Working Group.  The IESG contact persons 
are Ned Freed and Ted Hardie.

Abbie Barbir | 3 Apr 22:34 2003

draft-ietf-cdi-known-request-routing-03

Please publish the attached as as Internet-Draft
draft-ietf-cdi-known-request-routing-03
Thanks
Abbie

 


Network Working Group                                          A. Barbir
Internet-Draft                                           Nortel Networks
Expires: October 2, 2003                                         B. Cain
                                                        Storigen Systems
                                                                 R. Nair
                                                                   Cisco
                                                           O. Spatscheck
                                                                    AT&T
                                                           April 3, 2003

                  Known CN Request-Routing Mechanisms
              draft-ietf-cdi-known-request-routing-03.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 2, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   The work presents a summary of Request-Routing techniques that are
   used to direct client requests to surrogates based on various
   policies and a possible set of metrics. 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

Barbir, et al.          Expires October 2, 2003                 [Page 1]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   classified under: DNS Request-Routing, Transport-layer
   Request-Routing, and Application-layer Request-Routing.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    DNS based Request-Routing Mechanisms . . . . . . . . . . . .  4
   2.1   Single Reply . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   Multiple Replies . . . . . . . . . . . . . . . . . . . . . .  4
   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  . . . . . . . . . . . . . .  7
   3.    Transport-Layer Request-Routing  . . . . . . . . . . . . . .  9
   4.    Application-Layer Request-Routing  . . . . . . . . . . . . . 10
   4.1   Header Inspection  . . . . . . . . . . . . . . . . . . . . . 10
   4.1.1 URL-Based Request-Routing  . . . . . . . . . . . . . . . . . 10
   4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 11
   4.1.3 Site-Specific Identifiers  . . . . . . . . . . . . . . . . . 11
   4.2   Content Modification . . . . . . . . . . . . . . . . . . . . 12
   4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 12
   4.2.2 On-Demand URL Rewriting  . . . . . . . . . . . . . . . . . . 13
   4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 13
   5.    Combination of Multiple Mechanisms . . . . . . . . . . . . . 14
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 15
   7.    Additional Authors and Acknowledgements  . . . . . . . . . . 16
         Normative References . . . . . . . . . . . . . . . . . . . . 17
         Informative References . . . . . . . . . . . . . . . . . . . 18
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
   A.    Measurements . . . . . . . . . . . . . . . . . . . . . . . . 21
   A.1   Proximity Measurements . . . . . . . . . . . . . . . . . . . 21
   A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 21
   A.1.2 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 22
   A.1.3 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 22
         Intellectual Property and Copyright Statements . . . . . . . 23

Barbir, et al.          Expires October 2, 2003                 [Page 2]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

1. Introduction

   The 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].

   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.

Barbir, et al.          Expires October 2, 2003                 [Page 3]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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 usesage 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.

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

Barbir, et al.          Expires October 2, 2003                 [Page 4]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   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.

   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

Barbir, et al.          Expires October 2, 2003                 [Page 5]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   servers support the service, 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.
   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.

Barbir, et al.          Expires October 2, 2003                 [Page 6]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.

   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

Barbir, et al.          Expires October 2, 2003                 [Page 7]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   the limitations.

Barbir, et al.          Expires October 2, 2003                 [Page 8]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.

   The overhead associated with transport-layer Request-Routing [21][19]
   it 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.

Barbir, et al.          Expires October 2, 2003                 [Page 9]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.

   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

Barbir, et al.          Expires October 2, 2003                [Page 10]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   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 be directed 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.

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

Barbir, et al.          Expires October 2, 2003                [Page 11]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   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.

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 a 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

Barbir, et al.          Expires October 2, 2003                [Page 12]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   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.

Barbir, et al.          Expires October 2, 2003                [Page 13]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.

   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.

Barbir, et al.          Expires October 2, 2003                [Page 14]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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 intent 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 out of scope.

   Furthermore, the details of security techniques are beyond the scope
   of this document.

Barbir, et al.          Expires October 2, 2003                [Page 15]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.          Expires October 2, 2003                [Page 16]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

Normative References

   [1]  Postel, J.l, "File Transfer Protocol", RFC 765, June  1980.

   [2]  T. Dierks  et. al, "The TLS Protocol Version 1", RFC 846, July
        1999.

   [3]  H. Schulzrinne et. al, "Real Time Streaming Protocol", RFC 2326,
        April 1998.

   [4]  R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1",
        RFC 2616, June  1999.

   [5]  C. Partridge  et al., "Host Anycasting  Service", RFC 1546,
        November  1993.

   [6]  T. Berners-Lee et al, "Uniform Resource  Locators (URL)", RFC
        1738, May  1994.

   [7]  H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time
        Applications", RFC 1889, January  1996.

   [8]  M. Day et al, "A Model for Content Internetworking (CDI)", RFC
        3466 , February  2003.

   [9]  S. Floyd et al, "IAB Architectural and Policy Considerations for
        Open Pluggable Edge Services", RFC 3238, January  2002.

Barbir, et al.          Expires October 2, 2003                [Page 17]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

Informative References

   [10]  D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,
         June  1999.

   [11]  A. Gulbrandsen et al, "A DNS RR for specifying the location of
         services (DNS SRV)", RFC 2782, February  2002.

   [12]  P. Mockapetris, "Domain names - concepts and facilities", RFC
         1034, November  1987.

   [13]  P. Mockapetris, "Domain names - concepts and facilities", RFC
         1035, November  1987.

   [14]  R. Elz et al, "Clarifications to the DNS Specification", RFC
         2181, July  1997.

   [15]  D. Awduche et al, "Overview and Principles of Internet Traffic
         Engineering", RFC 3272, May  2002.

   [16]  E. Crawley et al, "A Framework for QoS-based Routing in the
         Internet", RFC 2386, August  1998.

   [17]  G. Huston, "Commentary on Inter-Domain Routing in the
         Internet", RFC 3221, December  2001.

   [18]  M. Welsh et al., "SEDA: An Architecture for Well-Conditioned,
         Scalable Internet Services", Proceedings of the Eighteenth
         Symposium on Operating Systems Principles (SOSP-18) 2001,
         October 2001.

   [19]  A. Shaikh, "On the effectiveness of DNS-based Server
         Selection", INFOCOM  2001, August 2001.

   [20]  C. Yang et al., "An effective mechanism for supporting
         content-based routing in scalable Web server clusters", Proc.
         International Workshops on Parallel Processing 1999, September
         1999.

   [21]  R. Liston et al., "Using a Proxy to Measure Client-Side Web
         Performance", Proceedings of the Sixth International Web
         Content Caching and Distribution Workshop (WCW'01) 2001, August
         2001.

   [22]  W. Jiang et al., "Modeling of packet loss and delay and their
         effect on real-time multimedia service quality", Proceedings of
         NOSSDAV 2000, June 2000.

Barbir, et al.          Expires October 2, 2003                [Page 18]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   [23]  K. Johnson et al., "The measured performance of content
         distribution networks", Proceedings of the Fifth International
         Web Caching Workshop and Content Delivery Workshop 2000, May
         2000.

   [24]  V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
         Transactions 1999, June 1999.

   [25]  F. Wang et al., "Secure routing protocols: Theory and
         Practice", Technical report, North Carolina State University
         1997, May 1997.

Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb <at> nortelnetworks.com

   Brad Cain
   Storigen Systems
   650 Suffolk Street
   Lowell, MA  01854
   USA

   Phone: +1 978-323-4454
   EMail: bcain <at> storigen.com

   Raj Nair
   Cisco
   50 Nagog Park
   Acton, MA  01720
   USA

   EMail: rnair <at> cisco.com

Barbir, et al.          Expires October 2, 2003                [Page 19]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   Oliver Spatscheck
   AT&T
   180 Park Ave, Bldg 103
   Florham Park, NJ  07932
   USA

   EMail: spatsch <at> research.att.com

Barbir, et al.          Expires October 2, 2003                [Page 20]

Internet-Draft    Known CN Request-Routing Mechanisms         April 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.          Expires October 2, 2003                [Page 21]

Internet-Draft    Known CN Request-Routing Mechanisms         April 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.          Expires October 2, 2003                [Page 22]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

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.

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

Barbir, et al.          Expires October 2, 2003                [Page 23]

Internet-Draft    Known CN Request-Routing Mechanisms         April 2003

   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.          Expires October 2, 2003                [Page 24]


The IESG | 2 Apr 16:53 2003
Picon

Last Call: Content Internetworking (CDI) Scenarios to Informational


The IESG has received a request from the Content Distribution 
Internetworking Working Group to consider Content Internetworking (CDI) 
Scenarios <draft-ietf-cdi-scenarios-01.txt> as an Informational RFC.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2003-4-16.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-cdi-scenarios-01.txt

Michael Speer | 18 Mar 01:57 2003
Picon

Is CDI dead?

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner <at> ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

All,

Is CDI dead?  No activity and no interest leads me to believe the group 
is dead.  Mark
do you have any comments?

Michael

rfc-editor | 5 Mar 00:46 2003

RFC 3466 on A Model for Content Internetworking (CDI)


A new Request for Comments is now available in online RFC libraries.

        RFC 3466

        Title:      A Model for Content Internetworking (CDI)
        Author(s):  M. Day, B. Cain, G. Tomlinson, P. Rzewski
        Status:     Informational
        Date:       February 2003
        Mailbox:    mday <at> alum.mit.edu, bcain <at> storigen.com,
                    gary <at> tomlinsongroup.net, philrz <at> yahoo.com
        Pages:      17
        Characters: 37684
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-cdi-model-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3466.txt

Content (distribution) internetworking (CDI) is the technology for
interconnecting content networks, sometimes previously called
"content peering" or "CDN peering".  A common vocabulary helps the
process of discussing such interconnection and interoperation.  This
document introduces content networks and content internetworking, and
defines elements for such a common vocabulary.

This document is a product of the Content Distribution Internetworking
(cdi) Working Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc3466.txt): message/external-body, 71 bytes

Gmane