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]
