Ingrid, Gary, and WRECers,
Enclosed are my comments on the WREC Taxonomy draft. My
comments are interspersed within the original text, prefixed by "> ".
Some of the comments are minor, some indicate new definitions that I
think should be added to the document, and a few are more structural.
The structural comments are summarized below.
- In terms of layout, the current draft seems to have three
"definition lists" of terms with proposed definitions. It is not
clear how these sections are different from each other. I would
like to see a single list of terms with consistent format and definitions.
- In addition to the list of terms I like the notion of having a
diagram to illustrate the relationships among the components in the
user agent to origin server sequence. I'm not sure the diagrams are
necessary to illustrate the sub-relationships, though. Instead, I
recommend having a single illustration for the reader to refer to,
followed by sections that describe the relationships in some detail.
That's all I have for now. Comments, please! Regards,
-- jad --
John Dilley <jad@hpl.hp.com>
Hewlett-Packard Laboratories
1501 Page Mill Road MS 1U-17
Palo Alto, CA 94304 // USA
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.
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]
:
> Regarding "client" and "server": It would help to differentiate the
> client platform (compute node) from the client application. Also the
> client and user agent definitions are confusing. I suggest using the
> terms "user agent" and "client system" to define the host system on
> which the user agent is running.
> How about defining "client" and "server" as roles various entities in
> the network can play, rather than the actual elements themselves.
> Similarly, "origin server system" should refer to the hardware and OS
> platform on which a web server is running. Then define the software
> stack that runs on top of that. A "proxy server" would play the role
> of proxy; it is a "client" to the "origin server". Does this all make
> sense ???
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.
server
> How about "service agent" for this?
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
> How about An intermediary system that 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
> This is not necessarily a "program" - should allow appliances or hardware here.
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
a set of cooperating caching servers
local Web cache server
> Maybe local proxy 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.
> A proxy with a cache, acting as server to one or more clients, and
client to one or more servers.
network element
router or switch
transparent proxying
> transparent proxy
> A proxy server that intercepts user agent requests without the user
> agent's knowledge in order to proxy the user agent's request
Transparency means that the user should not be aware of the
existence of the proxy.
traffic interception
> See above; is a separate definition necessary? If so it should come
> before transparent proxying since transparency requires interception.
???
proxy cluster
> A tightly coupled local cache mesh intended for load sharing.
load sharing, tightly coupled
proxy mesh
loosely coupled co-operating proxies
> ... often arranged into a hierarchy [append to the above]
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.
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]
> This is a very confusing term. Are these terms in common use or do
> they describe current practice? I suggest removing them if not. I
> think the intention is to build the context to describe whole subtree
> (complete) replication versus a partial (incomplete) replica. How
> about some of the following possibilities:
> Authoritative Reference (The logical owner of the data, maybe on a
> publishing system)
> Full Replica (A complete replica of a data set, typically defined as a
> subtree/.)
> Partial Replica (A replica of a portion of a content subtree.)
> Partial Cache (this one is harder - differentiating between cache and
> replica gets to the temporal relationship between the content and the
> origin data in the cache... any other ways to clarify this?)
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.]
> I think the number of separate definition lists should be reduced. If
> possible to one. Some additional items that I think need need
> defining (here or above) are:
> Passive Cache
> Active Cache
> Reverse Proxy Cache
> Cookie (ick - but very important in caching)
> User Authentication and Proxy Authentication
> HTTPS/SHTTP/Security considerations
> I can help provide definitions for some of these, others on the list
> please suggest what else is missing or if this is not the right choice
> and add of course contribute definitions as well...
3. Distributed System Relationships
Diagram of the components that make up a web replication and caching
infrastructure, with communication between the components.
> Document that this a picture of typical current usage of the web. It is
not necessarily the right architecture...
> Another way to describe this other than diagrams is a matrix to represent
relationships between all pairs of {User Agent, Proxy, Replica, Origin
Server}.
------------------ ----------------- ------------------
| 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]
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 |
-----------------
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 |
--------------
|
|
------------
| 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.
> Maybe "avoiding the need to individually configure" ?
Transparency means that the user does not need to be aware of the
proxy.
> See the definition above; is this needed here?
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.
> This is not a transparent caching issue -- it is an issue with any
> proxy (caching or not, transparent or manually configured).
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
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.
> Is there a reference for some of this information? Seems a lot to
> link in here.
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]
> * Capturing of non-port 80 traffic
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
> also referred to as Reverse Proxy Caches
[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]
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
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]
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
Security:
Deployment:
Submitter:
7. Inter-Cache Communication
This section describes the cooperation and communication between
caching proxies.
> Can you refer to the intercache-comproto document here? If not you
> should just include the body of that document, but having two
> redundant documents is non-optimal. My preference is to have two
> neatly divided documents, please let me know if that's not the usual
> or optimal way for IETF or for this draft.
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.
> This rudimentary loss measurement, together with round trip times,
> provide a crude 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:
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
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
> that
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].
> The cache digest implementation includes both ...
Security:
If the contents of a Digest is sensitive, it should be
protected from access by The Wrong People. Any methods
> Caps are not required for T W P...
which would normally be applied to secure an HTTP
connection
can be applied to Cache Digests.
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.
> Are these two paragraphs (above and below) necessary here?
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.
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]
> Do you really want to talk about these products here? If so why not
> discuss existing cache products - software and appliances? There are
> other resources for this information so my leaning is to have the
> taxonomy focus on the common terms used to describe the products and
> technologies, not the technologies themselves. Also products change
> too fast for a draft such as this...
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.]
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
[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 <Ingrid.Melve@uninett.no>
UNINETT
Tempeveien 22, Trondheim, NORWAY
Phone: +47 73 55 79 07
Email: Ingrid.Melve@uninett.no
Gary Tomlinson <garyt@novell.com>
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]
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST