Internet DRAFT - draft-melve-wrec-taxonomy

draft-melve-wrec-taxonomy






Internet Draft                                          Ingrid Melve
Expires: August 1999                                         UNINETT
Informational                                         Gary Tomlinson
WREC Working Group                                            Novell
                                                   February, 26 1999


             Internet Web Replication and Caching Taxonomy

                    draft-melve-wrec-taxonomy-00.txt


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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.

Abstract

   This memo specifies standard terminology and the current taxonomy of
   web replication and caching infrastructure deployed today. It
   introduces standard concepts and protocols uses today within this
   application domain. Currently deployed solutions employing this
   technologies are presented to establish a standard taxonomy.

   Research issues are covered in an accompanying document, and are not
   part of this document. This document presents open protocols and
   points to published RFCs for each protocol.





Melve, Tomlinson                                                [Page 1]

Replication and Caching Taxonomy   February 26, 1999


Contents

       1. Introduction
       2. Terminology
       3. Distributed Relationships
       4. Client to Replica Communication
       5. Inter-Replica Communication
       6. Client to Proxy Communication
       7. Inter-Cache Communication
       8. Network Element Communication
       9. Common Policy Management
      10. Security Considerations
      11. Conclusion
      12. References
      13. Authors' Addresses

1. Introduction

   [Ed note: This is a work in progress.  It is being collaboratively
   contributed to and edited within the WREC working group.  This is the
   first draft released to the working group.  It represents a rough
   template to use as a guide.  There are a number of contributions
   needed by those in attendance at the Orlando kick off meeting,
   primarily relating to the proprietary protocols and submitted
   drafts.]


2. Terminology

   Where possible, existing definitions [5, 6] have been used in this
   document.  Additional terminology has been agreed upon and defined in
   this document.  All of the terminology used in this document is
   considered to be standardized with respect to IETF WREC working group
   RFCs.

   In this document a number of terms are used to refer to the roles
   played by participants in, and objects of, the HTTP communication.
   The following definitions are used in the HTTP/1.1 specification [6]
   :

      client
             An application program that establishes connections for the
             purpose of sending requests.

      user agent
             The client which initiates a request. These are often
             browsers, editors, spiders (web-traversing robots), or
             other end user tools.



Melve, Tomlinson                                                [Page 2]

Replication and Caching Taxonomy   February 26, 1999


      server
             An application program that accepts connections in order to
             service requests by sending back responses. Any given
             program may be capable of being both a client and a server;
             our use of these terms refers only to the role being
             performed by the program for a particular connection,
             rather than to the program's capabilities in
             general. Likewise, any server may act as an origin server,
             proxy, gateway, or tunnel, switching behavior based on the
             nature of each request.

      origin server
             The server on which a given resource resides or is to be
             created.

      proxy
             An intermediary program which acts as both a server and a
             client for the purpose of making requests on behalf of
             other clients. Requests are serviced internally or by
             passing them, with possible translation, on to other
             servers. A proxy must interpret and, if necessary,
             rewrite a request message before forwarding it. Proxies are
             often used as client-side portals through network firewalls
             and as helper applications for handling requests via
             protocols not implemented by the user agent.

      tunnel
             An intermediary program which is acting as a blind relay
             between two connections. Once active, a tunnel is not
             considered a party to the HTTP communication, though the
             tunnel may have been initiated by an HTTP request. The
             tunnel ceases to exist when both ends of the relayed
             connections are closed.

      cache
             A program's local store of response messages and the
             subsystem that controls its message storage, retrieval, and
             deletion. A cache stores cacheable responses in order to
             reduce the response time and network bandwidth consumption
             on future, equivalent requests. Any client or server may
             include a cache, though a cache cannot be used by a server
             while it is acting as a tunnel.

   To these definitions we add definitions specifically concerned with
   Web cache systems:


      cache mesh



Melve, Tomlinson                                                [Page 3]

Replication and Caching Taxonomy   February 26, 1999


             a set of cooperating caching servers

      local Web cache server
             caching server running on the same LAN as a client

      local cache , first level Web cache server
             the Web cache server an end user client connects to
             [Ed note: confusion on usage of "local cache" and
             "user agent cache"]

      upper level Web cache server
             seen from the clients view, all caches participating in the
             caching mesh that are not the clients first level cache are
             upper level caches

      top-level Web cache server
             one or more servers in a hierarchical caching mesh,
             normally few requests are made to other caching servers
             from the top level, serves first level Web cache servers

      caching proxy
             A proxy with a cache, acting as server to the client, and
             client to the server.

      network element
             router or switch

      transparent proxying
             Transparency means that the user should not be aware of the
             existence of the proxy.

      traffic interception
             ???

      proxy cluster
             load sharing, tightly coupled

      proxy mesh
             loosely coupled co-operating proxies

      out-of-path transparent caching proxy
             A transparent caching proxy not in the forwarding path
             between client and server. Used with a redirecting network
             element.

      redirecting network element
             A network element which intercepts web traffic and
             redirects it to an out-of-path transparent caching proxy.



Melve, Tomlinson                                                [Page 4]

Replication and Caching Taxonomy   February 26, 1999


      Temporal Domain, sparse working set cache
             collection of caching machines storing temporarily,
             a subset of data sets
             [Ed note: this term is very difficult to capture in a
             concise articulate statement]

      Persistent Domain
             collection of origin servers maintaining complete
             persistent data sets
             [Ed note: this term is very difficult to capture in a
             concise articulate statement]

      Replica Origin Server
             origin server storing a persistent replica of a data set

      Browser
             A browser is a special instance of an end user client (a
             user agent) that acts as a content presentation device for
             the end user.

      Diffused Arrays
             tightly coupled array of caching proxy servers, acting
             logically as one service and partitioning the URL name
             space across the array

   [Ed note: The section above is incomplete and needs a lot of work.
   Need to use generic terms, seek agreement on terms.]



















3. Distributed System Relationships




Melve, Tomlinson                                                [Page 5]

Replication and Caching Taxonomy   February 26, 1999


   Diagram of the components that make up a web replication and caching
   infrastructure, with communication between the components.


    ------------------     -----------------     ------------------
    | Replica Origin |-----| Master Origin |-----| Replica Origin |
    |     Server     |     |    Server     |     |     Server     |
    ------------------     -----------------     ------------------
             \                    |                      /
              \                   |                     /
               -----------------------------------------
                                  |                 Client to
                           -----------------        Replica Server
                           |   Top-Level   |
                           | Caching Proxy |
                           -----------------
                             /            \      Inter Cache
                            /              \     Communication
              -----------------           -----------------
              |  Upper-Level  |-----------|  Upper-Level  |
              | Caching Proxy |           | Caching Proxy |
              -----------------           -----------------
                     /         Inter Cache       \
                    /         Communication       \  Inter Cache
                   /                               \  Communication
                  /                                 \
                 /         ------------------        \
                /         ------------------|         \
    -----------------     ----------------- ||    -----------------
    |  First Level  |-----| Caching Proxy | |-----|  First Level  |
    | Caching Proxy |     |    Array      |--     | Caching Proxy |
    -----------------     -----------------       -----------------
            | Client to         |
            | Proxy Cache       |   Cache to Network Element
       -------------       ------------
       |  Client   |       | Network  |
       -------------       | Element  |
                           ------------
                                |
                                |
                           ------------
                           |  Client  |
                           ------------



   [Ed Note: This diagram  is a first attempt.  There is much work to
   do]



Melve, Tomlinson                                                [Page 6]

Replication and Caching Taxonomy   February 26, 1999


   Client to Replica: cooperation and communication between clients
   (both browser/user agents and proxy caches) and replica origin
   servers.  Used to discover optimal replica proximity.


                    Persistent Domain
                      Complete Idem-Potent Set Replication
    ------------------     -----------------     ------------------
    | Replica Origin |     | Master Origin |     | Replica Origin |
    |     Server     |     |    Server     |     |     Server     |
    ------------------     -----------------     ------------------
             \                    |                      /
              \                   |                     /
               -----------------------------------------
                                  |                 Client to
                           -----------------        Replica Server
                           |     Client    |
                           |               |
                           -----------------


   Inter-Replica: cooperation and communication between replica origin
   servers.  Used in replicating data sets between origin servers.

                   Persistent Domain
                      Complete Idem-Potent Set Replication
    ------------------     -----------------     ------------------
    | Replica Origin |-----| Master Origin |-----| Replica Origin |
    |     Server     |     |    Server     |     |     Server     |
    ------------------     -----------------     ------------------


   Client to Proxy: configuration, cooperation and communication between
   end user clients (browsers and applications) and a caching proxy.

                        Temporal Domain
                          Sparse Working Set Cache
    -----------------     -----------------     -----------------
    |  First Level  |     |  First Level  |     |  First Level  |
    | Caching Proxy |     | Caching Proxy |     | Caching Proxy |
    -----------------     -----------------     -----------------
             \                    |                      /
              \                   |                     /
               -----------------------------------------
                                  |
                           -----------------
                           |     Client    |
                           -----------------



Melve, Tomlinson                                                [Page 7]

Replication and Caching Taxonomy   February 26, 1999


   Inter-Cache: cooperation and communication between caching proxies.

                        Temporal Domain
                          Sparse Working Set Cache
                           -----------------
                           |   Top-Level   |
                           | Caching Proxy |
                           -----------------
                             /            \
                            /              \
              -----------------           -----------------
              |  Upper-Level  |-----------|  Upper-Level  |
              | Caching Proxy |           | Caching Proxy |
              -----------------           -----------------
                     / \                    /    \
                    /   \                  /      \
                   /     \                /        \
                  /       \              /          \
                 /         \            /            \
                /           \          /              \
    -----------------     -----------------       -----------------
    |  First Level  |-----|  First Level  |-------|  First Level  |
    | Caching Proxy |     | Caching Proxy |       | Caching Proxy |
    -----------------     -----------------       -----------------


   Network Element to Proxy Cache: cooperation and communication between
   caching proxy and network elements.  Examples include routes and
   switches.  Generally used for transparent caching and/or diffused
   arrays.

                        Temporal Domain
                          Sparse Working Set Cache
    -----------------     -----------------     -----------------
    | Caching Proxy |     | Caching Proxy |     | Caching Proxy |
    |     Array     |     |     Array     |     |     Array     |
    -----------------     -----------------     -----------------
             \                    |                      /
              \                   |                     /
               -----------------------------------------
                                  |
                             --------------
                             |  Network   |
                             |  Element   |
                             --------------
                                  |
                                  |
                              ------------



Melve, Tomlinson                                                [Page 8]

Replication and Caching Taxonomy   February 26, 1999


                              |  Client  |
                              ------------


 Replicated Origin Servers

   [Ed Note: To be completed]

 Caching Proxies

   [Ed Note: To be completed. Explain "normal" proxy setup, with more
   than one proxy as cluster or mesh. Brief intro to problem.]

 Caching Proxies with Transparency

   [Ed note: Currently contains citations from NetApp document, need
   rewording to avoid specific products and concentrate on generic
   properties. Explain network elements and NATs and other ways
   interception may happen. Intro to usage and "normal" setup.]

   Reference [1,2,3,4] for introduction to caching proxies with
   transparency.

   The goal of intercepting web traffic is to provide a transparent web
   proxy, thus avoiding the hassle of individually configuring each
   client.

   Transparency means that the user does not need to be aware of the
   proxy.

   The web origin server see connections coming from the proxy, not from
   the individual end user. Authentication based on client IP address do
   not work if there is a transparent proxy cache in the way to the web
   server.

   A web cache is said to be transparent if clients can access the cache
   without the need to configure their browsers, using either a proxy
   auto-configuration URL or a manual proxy setting. Transparent caches
   appear as a seamless part of the network infrastructure, rather than
   a set of discrete proxy servers, and function much like a transparent
   firewall. Many ISPs and carriers desire transparent caches because it
   lets them retrofit their network with caching without action at the
   client. However, when deployed transparently, a web cache must be as
   fail-safe and scalable as the rest of the network. [2]

   A transparent cache acts much like a gateway or firewall -- it
   effectively sits between the users and the network. The advantage of
   transparent caching is that it eliminates the need to configure



Melve, Tomlinson                                                [Page 9]

Replication and Caching Taxonomy   February 26, 1999


   browsers to use caching. Another strength (and sometimes a weakness)
   is that it is impossible to bypass caching. [2]

   Conceptually, transparency works by modifying the TCP/IP stack of a
   cache so that it operates in "promiscuous mode" and effectively binds
   itself to all possible IP addresses. [2]

   We need to give a far more abstract definition which includes the way
   that router and switch redirection, and within-router action,
   operate.

   Comment on some of the problems:
        * limited number of ports which can be captured
        * due to "unexpected" data on other ports
          (or even on well known ports), as experienced by setting up
          various services on port 80
        * well known problems with use of HTTP for transport [20]


 Out-of-path Transparent Caching Proxies

   An Out-of-path Transparent Caching Proxy performs the same proxy and
   caching functions as a Transparent Caching Proxy and is similarly
   transparent to the client. However it does not lie on the forwarding
   path between a client and a server and does not perform web traffic
   interception. Instead it relies upon a redirecting network element in
   the path between client and server to intercept and redirect web
   traffic to it. One advantage of this method of transparent caching is
   that in the case of cache failure the network element can, providing
   it monitors the state of the caches, revert to forwarding web traffic
   direct to the server. It is also possible for the network element to
   distribute the web traffic load across a group of caches. This method
   of transparent caching generally requires a protocol to be run
   between the redirecting network element and the cache or caches.

 Caching Accelerators

   [Ed note: to be completed]

4. Client to Replica Communication

   This section describes the cooperation and communication between
   clients (both browser/user agents and proxy caches) and replica
   origin servers.  Used to discover optimal replica proximity.

 URL Redirection

   [Ed note: to be completed]



Melve, Tomlinson                                               [Page 10]

Replication and Caching Taxonomy   February 26, 1999


 DNS Redirection

   [Ed note: to be completed]


5. Inter-Replica Communication

   This section describes the cooperation and communication between
   replica origin servers.  Used in replicating data sets between origin
   servers.

 Batch Driven Mirror Replication

   [Ed note: to be completed]

 Demand Driven Mirror Replication

   [Ed note: to be completed by Gary Tomlinson]


6. Client to Proxy Configuration

   This section describes the configuration, cooperation and
   communication between end user clients (browsers and applications) a
   proxy.


 Manual Proxy Configuration

   Manual Proxy Configuration

   [Ed note: Does not need to be submitted for Informational RFC, in
   Ingrid's opinion]

      Authoritative reference:
             None.

      Description:
             Each user needs to configure its browser by typing in
             information

      Security:
             The potential for doing wrong is high, as each user
             individually sets preferences

      Deployment:
             Widely deployed, used in all current browsers. Most
   browsers



Melve, Tomlinson                                               [Page 11]

Replication and Caching Taxonomy   February 26, 1999


             support other options as well.

      Submitter:


 PAC

   [7] PAC

   [Ed note: Does it really need to be submitted for Informational RFC?]

      Authoritative reference:
             Navigator Proxy Auto-Config File Format. Available from
             http://home.netscape.com/eng/mozilla/2.0/
               relnotes/demo/proxy-live.html

      Description:
             A JavaScript page on a web server hands out information on
             where to find proxies. Clients need to point at the URL of
             this page. No bootstrap mechanism, manual configuration
             necessary.

             Manual configuration is made easier by centralizing the
             script to one URL.

      Security:
             Common policy per organization possible. Does still require
             manual configuration. PAC is better than "manual proxy
             configuration" because with PAC administrators can update
             the proxy configuration without user intervention.

             Interoperability of PAC files is not as good as wanted,
             since more popular browsers have slightly different
             interpretation of the script, and this may lead to
             undesired effects.

      Deployment:
             Implemented in most web clients.

      Submitter:


 CARP

   [9] CARP Cache Array Routing Protocol v1.0

   [Ed note: to be completed]




Melve, Tomlinson                                               [Page 12]

Replication and Caching Taxonomy   February 26, 1999


      Authoritative reference:
             Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt

      Description:
             Clients may use CARP directly as a hash function based
             proxy selection mechanism. They need to be configured with
             the location of the cluster information.

      Security:

      Deployment:

      Submitter:


 WPAD

   [Ed note: to be completed]

      Authoritative reference:
             None

      Description:
             WPAD uses a collection of pre-existing Internet resource
             discovery mechanisms to perform web proxy auto-discovery.

             The only goal of WPAD is to locate the PAC URL. WPAD does
             not specify which proxies will be used. WPAD gets you to
             the PAC URL, and the PAC script chooses the proxies for
   you.

             The WPAD protocol specifies the following:

             + how to use each mechanism for the specific purpose of
               web proxy auto-discovery
             + the order in which the mechanisms should be performed
             + the minimal set of mechanisms which must be attempted
               by a WPAD compliant web client

             The resource discovery mechanisms utilized by WPAD are as
             follows:

             + Dynamic Host Configuration Protocol DHCP
             + Service Location Protocol SLP
             + "Well Known Aliases" using DNS A records
             + DNS SRV records
             + "service: URLs" in DNS TXT records




Melve, Tomlinson                                               [Page 13]

Replication and Caching Taxonomy   February 26, 1999


      Security:

      Deployment:

      Submitter:




7. Inter-Cache Communication

   This section describes the cooperation and communication between
   caching proxies.

 ICP

   [10, 11, 12, 13, 14] ICP Internet Cache Protocol

      Authoritative reference:
             RFC 2186 [10] Internet Cache Protocol (ICP), version 2

      Description:
             ICP is used by caches to query other caches about web
             objects, to see if a web object is present at the other
             cache.

             ICP uses UDP. Since UDP is unreliable, an estimate of
             network congestion and availability may be calculated
             by ICP loss. This rudimentary loss measurement does,
             together with round trip times provide a load balancing
             method for caches.

      Security:
             ICP does not convey information about HTTP headers
             associated with a web object. HTTP headers may include
             access control and cache directives, Since caches ask for
             objects, and then download the objects using HTTP, false
             cache hits may occur (object present in cache, but not
             accessible for sibling cache is one example).

             ICP suffer from all the security problems of UDP.

      Deployment:
             Widely deployed. Most current cache implementations support
             ICP in one form or the other.

      Submitter:




Melve, Tomlinson                                               [Page 14]

Replication and Caching Taxonomy   February 26, 1999


 HTCP

   [15] HTCP, Hyper Text Caching Protocol (HTCP/0.0).

   [Ed note: to be completed]

      Authoritative reference:
             Internet Draft draft-vixie-htcp-proto-03.txt,
             Work in Progress

      Description:
             HTCP is a protocol for discovering HTTP caches and cached
             data, managing sets of HTTP caches, and monitoring cache
             activity.

             HTCP includes HTTP headers, while ICPv2 does not. HTTP
             headers are vital information for web proxy caches.

      Security:

      Deployment:
             Implemented in caching proxies (two independent
             implementations)

      Submitter:

 CARP

   [9] CARP

   [Ed note: to be completed]

      Authoritative reference:
             Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt
             [Ed note: current draft has expired]

      Description:
             CARP is a hashing function for dividing URL-space among a
             cluster of proxy caches. Included in CARP is the definition
             of a Proxy Array Membership Table, and ways to download
             this information.

             An HTTP client agent (either a proxy server or a client
             browser) which implements CARP v1.0 can allocate and
             intelligently route requests for the correct URLs to any
             member of the Proxy Array. Due to the resulting sorting of
             requests through these proxies, duplication of cache
             contents is eliminated and global cache hit rates may be



Melve, Tomlinson                                               [Page 15]

Replication and Caching Taxonomy   February 26, 1999


             improved.

      Security:

      Deployment:
             Implemented in caching proxy servers. More than two
             independent implementations.

      Submitter:


 Cache Digest

   [16] Cache Digest


      Authoritative reference:
             No RFC published, no Internet-Draft
             Cache Digest specification
             http://squid.nlanr.net/Squid/CacheDigest/
                    cache-digest-v5.txt
             Squid Digest FAQ entry
             http://squid.nlanr.net/Squid/FAQ/FAQ-16.html

      Description:
             Cache Digests are a response to the problems of latency and
             congestion associated with previous inter-cache
             communications mechanisms such as the Internet Cache
             Protocol (ICP) [10, 11] and the HyperText Cache Protocol
             [15]. Unlike most of these protocols, Cache Digests support
             peering between cache servers without a request-response
             exchange taking place. Instead, a summary of the contents
             of the server (the Digest) is fetched by other servers
   which
             peer with it. Using Cache Digests it is possible to
             determine with a relatively high degree of accuracy
             whether a given URL is cached by a particular server.

             Cache Digests are both an exchange protocol and a data
             format [16a,16b].

      Security:
             If the contents of a Digest is sensitive, it should be
             protected from access by The Wrong People. Any methods
             which would normally be applied to secure an HTTP
   connection
             can be applied to Cache Digests.




Melve, Tomlinson                                               [Page 16]

Replication and Caching Taxonomy   February 26, 1999


             A 'Trojan horse' attack is currently possible in a cache
             mesh: Cache A can build a fake peer Digest for cache B and
             serve it to B's peers if requested. This way A can direct
             traffic toward/from B. The impact of this problem is
             minimized by the 'pull' model of transferring Cache Digests
             from one server to another.

             Cache Digests provide knowledge about peer cache content on
             a URL level. Hence, they do not dictate a particular level
             of policy management and can be used to implement various
             policies on any level (user, organization, etc.).

      Deployment:
             Cache Digests are supported in Squid; several commercial
             vendors are looking into Digest support.

             Cache Meshes:
             + NLANR Mesh
             + TF-CACHE mesh (European Academic networks)

      Submitter:
             Alex Rousskov, NLANR, rousskov@nlanr.net


8. Network Element Communication

   This section describes the cooperation and communication between
   caching proxy and network elements.  Examples include routers and
   switches.  Generally used for transparent caching and/or diffused
   arrays.

 WCCP

   [18] WCCP, Web Cache Coordination Protocol V1

      Authoritative reference:
             Internet Draft draft-forster-web-pro-00.txt
             Work in Progress

      Description:
             WCCP V1 runs between a router functioning as a redirecting
             network element and out-of-path transparent caching
             proxies. The protocol allows one or more caching proxies
             to register themselves with a single router to receive
             redirected web traffic. It also allows one of the proxies,
             the designated proxy, to dictate to the router how
             redirected web traffic is distributed across the caching
             proxies.



Melve, Tomlinson                                               [Page 17]

Replication and Caching Taxonomy   February 26, 1999


      Security:
             WCCP V1 has no security features.

      Deployment:
             Network elements: WCCP V1 is deployed on a wide range of
             Cisco routers.
             Caching proxies: WCCP V1 is deployed on a number of
             vendors' caches.

      Submitter:
             David Forster, CISCO, dforster@cisco.com


 SOCKS

   [Ed note: to be completed]

 Alteon L4 Switch Protocol

   [Ed note: to be completed]

 ArrowPoint L4 Switch Protocol

   [Ed note: to be completed]

 Foundry L4 Switch Protocol

   [Ed note: to be completed]

9. Security Considerations

   Information on security in each protocol is provided in the
   description of the protocol, and in the accompanying RFC for each
   protocol.


   [Ed note: more information needed]

10. Conclusion

   [Ed note: to be completed]

11. Acknowledgements

   [Ed note: No decision made on authors list. Submitters of individual
   entries are acknowledged in the text. Need to sort out how to give
   credits where they are due.]




Melve, Tomlinson                                               [Page 18]

Replication and Caching Taxonomy   February 26, 1999


   Ian Cooper, MirrorImage ian@mirror-image.com for really helpful
   comments.

   David Forster, Cisco, dforster@cisco.com provided info on Out-of-path
   Transparent Caching Proxies.

   Alex Rousskov and David Forster for protocol information.

12. References

   [1] Duane Wessels.  Squid FAQ: Transparent Caching/Proxying.
   National Laboratory for Applied Network Research.  Available from:
   http://squid.nlanr.net/Squid/FAQ/FAQ-17.html

   [2] Peter Danzig and Karl L. Swartz.  Transparent, Scalable, Fail-
   Safe Web Caching.  Network Appliance, Inc. Available from
   http://www.netapp.com/technology/level3/3033.html

   [3] Bert Williams. Transparent Web Caching Solutions.  Alteon
   Networks.  Available from Transparent Web Caching Solutions

   [4] Tony Hain.  Architectural Implications of NAT. Internet
   Architecture Board. Internet Draft (Work in Progress). Available from
   ftp://ftp.nordu.net/internet-drafts/draft-iab-nat-implications-02.txt

   [5] Ingrid Melve, Lars Slettjord, Ton Verschuren, Henny Bekker,
   Technical report European Union RE1004-M4.3 "Web caching
   architecture"

   [6] Fielding, et al. Hypertext Transfer Protocol -- HTTP/1.1.  IETF
   RFC2068. Available from http://info.internet.isi.edu/in-
   notes/rfc/files/rfc2068.txt

   [7] Netscape, Inc. Navigator Proxy Auto-Config File Format.
   Available from
   http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-
   live.html

   [8] Paul Gauthier, J. Cohen, Martin Dunsmuir and Charles Perkins.
   The Web Proxy Auto-Discovery Protocol. Available from
   http://eggplant.rte.microsoft.com/wpad/

   [9] Vinod Valloppillil and Keith W. Ross.  Cache Array Routing
   Protocol. Internet Draft (Work in Progress) Available from
   ftp://ftp.nordu.net/internet-drafts/draft-vinod-carp-v1-03.txt

   [10] D. Wessels and K. Claffy. Internet Cache Protocol (ICP), version
   2. 'RFC2186. Available from ftp://ftp.nordu.net/rfc/rfc2186.txt



Melve, Tomlinson                                               [Page 19]

Replication and Caching Taxonomy   February 26, 1999


   [11] D. Wessels and K. Claffy. Application of Internet Cache Protocol
   (ICP), version 2, RFC2187. Available from
   ftp://ftp.nordu.net/rfc/rfc2187.txt

   [12] Ivan Lovric. Internet Cache Protocol Extension Internet Draft
   (Work in Progress) Available from ftp://ftp.nordu.net/internet-
   drafts/draft-lovric-icp-ext-01.txt

   [13] Duane Wessels. ICP Home Page, National Laboratory for Applied
   Research.  Available from [52]http://ircache.nlanr.net/Cache/ICP/

   [14] University of Southern California.  Internet Cache Protocol
   Specification 1.4. Available from
   http://excalibur.usc.edu/icpdoc/icp.html

   [15] Paul Vixie and Duane Wessels. Hyper Text Caching Protocol
   (HTCP/0.0). Internet Draft (Work in Progress) Available from
   ftp://ftp.nordu.net/internet-drafts/draft-vixie-htcp-proto-03.txt

   [16] Alex Rouskov and Duane Wessels. Cache Digests.  National
   Laboratory for Applied Network Research.  Available from [16a] Cache
   Digest specification http://squid.nlanr.net/Squid/CacheDigest/cache-
   digest-v5.txt [16b] Squid Digest FAQ entry
   http://squid.nlanr.net/Squid/FAQ/FAQ-16.html

   [17] Berners-Lee, et al. Hypertext Transfer Protocol -- HTTP/1.0 IETF
   RFC1945 Available from http://info.internet.isi.edu/in-
   notes/rfc/files/rfc1945.txt

   [18] Cisco Web Cache Control Protocol (WCCP). Internet Draft (Work
   Progress) Available from ftp://ftp.nordu.net/internet-drafts/draft-
   forster-web-pro-00.txt

   [19] Leech, et al. SOCKS Protocol Version 5, RFC1928 Available from
   http://info.internet.isi.edu/in-notes/rfc/files/rfc1928.txt

   [20] Keith Moore, On the use of HTTP as a Substrate for Other
   Protocols. Internet Draft (Work in Progress) Available from
   ftp://ftp.nordu.net/internet-drafts/draft-iesg-using-http-00.txt


13. Authors' Addresses

   Ingrid Melve
   UNINETT
   Tempeveien 22, Trondheim, NORWAY
   Phone: +47 73 55 79 07
   Email: Ingrid.Melve@uninett.no



Melve, Tomlinson                                               [Page 20]

Replication and Caching Taxonomy   February 26, 1999


   Gary Tomlinson
   Novell, Inc.
   122 East 1700 South
   Provo, Utah 84606 USA
   Phone: +1 801 861 7021
   Email: garyt@novell.com


Appendix

 Template

   Protocol information template

   Authoritative reference:
             (RFC published, or Internet-Draft)
   Description:
             (What does it do. Its benefits, intended purpose, etc)
   Security:
             (Security relative the protocol, Policy Management)
   Deployment:
             (Deployment scenario(s))
   Submitter:
             (Name, email, institution)



























Melve, Tomlinson                                               [Page 21]