Internet Draft S.McHenry
Expires: Jan 2002 CacheWare, Inc.
M. Condry
Category: Informational Intel Corporation
G. Tomlinson
CacheFlow, Inc.
H. Orman
Volera
M. Hoffman
Lucent
July 13, 2001
Open Pluggable Edge Services
Use Cases and Deployment Scenarios
draft-mchenry-opes-deployment-scenarios-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 [1].
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.
Table of Contents
1 Introduction..................................................3
2 Example Use Cases.............................................3
2.1 Virus Scanning..............................................4
2.1.1 Abstract...................................................4
2.1.2 Business model.............................................4
2.1.3 Technical Challenges.......................................4
2.2 Location-based Services.....................................4
2.2.1 Abstract...................................................4
2.2.2 Business model.............................................5
2.2.3 Technical Challenges.......................................5
2.3 Assembling of Personalized Web Pages........................5
2.3.1 Abstract...................................................5
2.3.2 Business Model.............................................5
2.3.3 Technical Challenges.......................................6
2.4 Content Adaptation for Alternate Web Access Devices.........6
2.4.1 Abstract...................................................6
2.4.2 Business model.............................................6
McHenry et al. Expires Jan 2002 1
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
2.4.3 Technical Challenges.......................................7
2.5 Limited Client Bandwidth Adaptation.........................7
2.5.1 Abstract...................................................7
2.5.2 Business model.............................................8
2.5.3 Technical Challenges.......................................8
2.6 Adaptation of Streaming Media...............................8
2.6.1 Abstract...................................................8
2.6.2 Business model.............................................9
2.6.3 Technical Challenges.......................................9
2.7 Request Filtering...........................................9
2.7.1 Abstract...................................................9
2.7.2 Business model.............................................9
2.7.3 Technical Challenges.......................................9
2.8 Request Filtering through Content Analysis.................10
2.8.1 Abstract..................................................10
2.8.2 Business model............................................10
2.8.3 Technical Challenges......................................10
2.9 Search Engine Index on Cached Web Pages....................10
2.9.1 Abstract..................................................10
2.9.2 Business model............................................11
2.9.3 Technical Challenges......................................11
2.10 Language Translation.......................................11
2.10.1 Abstract.................................................11
2.10.2 Business model...........................................11
2.10.3 Technical Challenges.....................................12
2.11 Watermarking...............................................12
2.11.1 Abstract.................................................12
2.11.2 Business model...........................................12
2.11.3 Technical Challenges.....................................12
2.12 Multiple Use Case Applicability............................12
2.12.1 Abstract.................................................12
2.12.2 Business model...........................................12
2.12.3 Technical Challenges.....................................12
3 Types Of Services............................................12
4 Network Topologies...........................................13
4.1 Callout Services on the Edge Proxy Device..................13
4.2 Callout Services on collocated callout servers.............13
4.3 Callout Services on non-collocated callout servers.........13
4.4 Callout for streaming services.............................14
5 Component Deployment Scenarios...............................14
5.1 Near the edge..............................................14
5.2 In Front of Servers........................................14
5.3 At hosting centers.........................................14
6 Processing Scenarios.........................................14
6.1 Edge Side Includes.........................................14
6.2 Virus Scanning.............................................14
7 Rules In Edge Devices........................................14
8 Acknowledgements.............................................15
9 Author's Addresses...........................................15
10 References...................................................16
McHenry et al. Expires Jan 2002 2
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
1 Introduction
The rapid growth of the Internet and the increasing number of Internet users
have resulted in many scaling and growth problems with application designs
focused on operations at the ends (i.e. the client or the server). This has
led to a wide deployment of network edge caching proxies as a key strategy to
address these problems. These systems have been very successful in
accelerating Web content delivery and reducing the load on origin Web
servers.
However, the specific role of these network edge caching proxies as a gateway
between Web users and content providers suggests utilizing them for
intelligent services beyond simple caching.
There are already a variety of existing or proposed approaches that implement
particular services on top of a proxy platform. ICAP [5] extends the basic
idea of implementing value-added services on proxies by handling transport of
web objects between proxies and content modification servers, thus, enabling
remote call out mechanisms. EPSFW [2, 7] describes an extended framework to
provide general services on top of an open proxy platform.
This document discusses a number issues surrounding the deployment of edge
services. Specifically, it provides a discussion of use cases in which edge
services would be useful. It also examines the computational requirements for
various edge services and from that derives several actual configurations
that are anticipated for the deployment of edge services. These include both
the basic network topologies, as well as the domain issues surrounding the
deployments. Finally, it examines some issues relating to the use of rules
(or other policies) in the determination of which services are applicable to
a specific request or response.
2 Example Use Cases
In this section, several service examples possibly being implemented on top
of an open proxy platform as described in [2, 7]. Each of the following
service description consists of three subsections: a short abstract that
describes the service idea, a description of the underlying business model,
and finally a section that mentions technical challenges to be addressed when
implementing these services.
Subsection 1 describes virus scanning as an example service, which currently
is one of the most frequently cited service ideas. Subsections 2 and 3
describe services that dynamically assemble personalized content. These
services exhibit the use of the proxy device managing information about the
client. Subsections 4 and 5 present services that adapt content to the
capability of client devices and client access bandwidth. Some of the
previous service ideas can also be applied to streaming media, which is
discussed in Subsection 6. The services given in Subsections 7, 8, and 9
operate on client requests rather than on the content itself. More service
examples are given in Subsections 10 and 11.
McHenry et al. Expires Jan 2002 3
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
2.1 Virus Scanning
2.1.1 Abstract
Viruses, Trojan Horses, and worms have always posed a threat to Internet
users. Just recently we have seen a number of e-mail based worms that have
hit millions of Internet users worldwide within a few hours.
With the help of a content scanning and filtering system at the caching proxy
level, Web pages and also file transfers could be scanned for malicious
content prior to sending them to the user. In Web pages active content like
ActiveX, Java and JavaScript could be scanned for harmful code (e.g. code
exploiting security holes). File transfers could be scanned for known
viruses. If a virus is found, the adaptation server could try to remove it or
deny the delivery of the infected content. A general rule could be that the
caching proxy may store and/or deliver content only, if it has been scanned
by the content adaptation server and no viruses are found.
2.1.2 Business model
This service could be offered as an additional feature to ISP customers who
are concerned about security issues. Likewise enterprises could be interested
in this solution to prevent any malicious content from entering the company
network.
2.1.3 Technical Challenges
Web pages/files should be scanned for viruses by sending them to a separate
server where virus-scanning software would analyze them. ICAP [5] is an
example protocol for this purpose. The virus scanning operations should not
be performed on the caching proxy as they will probably affect the
performance of the caching proxy.
If HTTP file transfers are to be scanned for viruses and the requested file
cannot be found in the cache, we have to use a different approach than for
Web pages. It would not be feasible if the proxy waited for the requested
file to be received completely before sending it over to the content
adaptation server for the virus scan. This approach would lead to a long
delay at the userÆs end, which is not acceptable. Instead, we would have to
scan the file transfer continuously, as it is being sent to the user (similar
to streaming media).
2.2 Location-based Services
2.2.1 Abstract
If a content provider wants to add user-specific regional information
(weather forecasts for certain areas for example) to his Web pages, he has
little choice but to have the user select his location from a list of
regions. Usually it is not possible for origin servers to reliably detect
from where Web users connect to Web sites because user requests can get
McHenry et al. Expires Jan 2002 4
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
routed through a number of proxy servers on their way from the client to the
origin server.
In a network edge caching proxy environment user requests are usually
redirected to the nearest proxy that is available to respond to the request.
Regional information that is relevant to all users who are likely to connect
to a certain proxy could be stored at the corresponding caching proxy.
Whenever the proxy receives a user request, a module on the caching proxy
could insert the regional information into the requested Web page. If the Web
page does not contain any user-specific non-cacheable content other than the
inserted regional information, the Web page content can now be cached for
future requests.
2.2.2 Business model
This service could be sold to content providers who want to offer regional
information on their Web sites and want to accelerate the delivery of their
Web content. There are many cases in which a content provider could profit
from knowing the location of the user. Users could be targeted with regional
advertisement banners (see also ad insertion scenario). Regional distinctions
(e.g. sales taxes, differing laws etc.) could be taken into consideration
when the Web pages are prepared for the client. It would not be necessary any
more to ask the user for his location prior to presenting him relevant
information.
2.2.3 Technical Challenges
The regional content that is to be inserted into the Web pages would have to
be distributed to the corresponding caching proxies. Since the regional
content represents only a component of a whole Web page, it cannot be cached
in the same way a complete Web page can be cached (unless it is an image). We
have to find a mechanism to determine when a regional text component needs to
be updated (or if the content provider should be responsible for this).
2.3 Assembling of Personalized Web Pages
2.3.1 Abstract
Many Web sites (e.g. Yahoo) offer a service where users can create their own
personalized version of the Web site (e.g. MyYahoo). It basically means that
a user can choose from a number of components (e.g. stock information,
weather forecasts, news etc.) and create a personalized Web page with them.
This leads to dynamic Web pages that usually cannot be cached. However, the
components of the personalized Web page can be cached. Therefore, it is
possible to have a service module on the server create the user-specific Web
pages by assembling the cached Web site components. In that case the origin
server would not have to be contacted again and the page could be served to
the client directly from the network edge caching proxy.
2.3.2 Business Model
McHenry et al. Expires Jan 2002 5
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
This service would be another method of accelerating the delivery of Web
content to the user, particularly the delivery of personalized/customized Web
pages that would not be cacheable otherwise. It also saves bandwidth between
the origin server and the proxy cache.
Content providers who offer their customers the possibility of personalizing
their Web pages are likely to be willing to pay for this kind of service.
2.3.3 Technical Challenges
We would have to find a caching mechanism for the separate components of the
personalized Web pages (unless a component consists of an image only). These
components could be stored at the caching proxy.
The page components would have to be refreshed just like complete Web page
whenever they become stale.
2.4 Content Adaptation for Alternate Web Access Devices
2.4.1 Abstract
There is a growing diversity and heterogeneity in types and capabilities of
client devices as well as the forms of network connections that people use to
access the Web. Clients include cell phones and PDAs as well as PCs, TVs
(with SetTop boxes), etc. However, these appliances have quite diverse
display capabilities, storage, processing power, as well as slow network
access. As a result, Internet access is still constrained on these devices
and users are limited to only a small fraction of the total number of Web
pages available in the Internet today. Organizations such as the WAP forum
[4] have suggested custom Web page design but this results in special code
frequently required on the content server.
Since the number of different access devices is growing constantly content
providers cannot be expected to provide different versions of their Web pages
for each and every Web access device that is available in the market.
Therefore, if it is possible to transcode the general full-fledged Web pages
at some point on their way from the origin server to the user so that they
are optimized for (or at least adapted to) the end users' specific
requirements, it would provide a valuable service for the end customer, the
service provider, and the content provider.
2.4.2 Business model
With the above-mentioned service in place, Web content providers could reach
a much wider audience and the manufactures of diverse Web access devices
could offer potential customers access to a bigger part of the Internet
content, which should make a very good selling point. It would encourage more
people to buy non-desktop Web access devices like cell phones and PDAs
expanding the market.
McHenry et al. Expires Jan 2002 6
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
We would expect this service would be offered as an additional feature to ISP
customers who want to access the Web through different Web-enabled devices.
Also, the service might be paid by content providers because they could serve
their existing content to more users; likewise, the non-desktop device makers
may contribute to this service cost making their client devices more
effective at the Web.
2.4.3 Technical Challenges
Possible adaptations to meet the special requirements of different Web access
devices are:
- Conversion of HTML pages to WML (Wireless Markup Language) pages
- Conversion of JPEG images to black and white GIF images
- Conversion of HTML tables to plain text
- Reduction of image quality
- Removal of redundant information
- Stripping of Java applets / JavaScript
- Audio to text conversion
- Video to key frame or video to text conversion
- Content extraction
We have to ensure that the automatic adaptation process will not make changes
to a Web page that are unwanted by either the content provider or the
recipient. Our suggested strategy to achieve this would be to allow the
content provider as well as the client to define their preferences as to how
they want Web pages to be adapted. The actual adaptation decisions would then
be made based on the given preferences and a set of transformation rules.
There would have to be a mechanism of resolving potential conflicts between
the content provider's and the user's adaptation preferences. If neither the
content provider nor the client has expressed his preferences, a default
adaptation of the requested Web page may be possible but investigation is
needed.
A way for preferences to be specified representing the content provider and
client customer must be provided. For example, client customers could set
their preferences through a Web interface on the ISP Web site. Content
providers could express their preferences by adding meta tags to their Web
pages. This meta data offers the content provider the ability to specify a
number of alternatives and the content adaptation server could then pick the
most appropriate one. This meta data should be independent of specific Web
content but is likely to depend on the types of content in the pages. Another
possibility in the ESPWF [2, 7] framework would be for the content provider
would be to provide an adaptation policy to all ISPs that want to adapt Web
pages for alternate Web access devices. This policy could consist of general
transformation rules or actual code modules that perform the adaptation.
2.5 Limited Client Bandwidth Adaptation
2.5.1 Abstract
McHenry et al. Expires Jan 2002 7
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
Different Internet clients can handle different Internet connection speeds.
Therefore it seems desirable to adapt the requested Web content to the userÆs
bandwidth.
2.5.2 Business model
One of the main benefits is to decrease the Web access time for users. If a
Web site loads too slowly, users tend to leave the site even before it has
completed loading the home page. The improved perceived quality of service by
adaptive content delivery means that users are more likely to stay and
return, thus resulting in a greater profit for e-commerce sites. This can
also result in higher hit rates and return rates, which can lead to higher
sales for e-commerce sites and higher advertising revenues.
2.5.3 Technical Challenges
Possible adaptations to reduce the size of Web objects are:
- Reduction of image quality
- Replacement of images by their ALT text
- Removal of redundant information
- Removal of HTML comments
- Stripping of Java applets / JavaScript
- Audio to text conversion
- Video to key frame or video to text conversion
- Text summarizing
- Content extraction
We would have to find a reliable way of determining the bandwidth between the
client and the proxy cache. One way of measuring this would be to measure the
round trip time (RTT) to determine the connection speed. It is crucial that
this bandwidth detection method works more or less exact or otherwise the
client will either experience very slow Web browsing or be cut off of some
(or all) of the rich Web content. This service requires authorization by the
user like any other adaptation service that changes the content and or format
of Web pages.
The mapping of a userÆs connection speed to appropriate page adaptations
requires defining a set of adaptation rules.
2.6 Adaptation of Streaming Media
2.6.1 Abstract
Some of the above-mentioned services could not only be applied to Web pages
but also to streaming media like audio and video streams. In particular,
media streams could be adapted to meet the bandwidth of the userÆs
connection. It would also be possible to insert pre-recorded advertisements
into audio or video streams. Even content analysis and content filtering
could be applied to streaming media.
McHenry et al. Expires Jan 2002 8
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
2.6.2 Business model
The business models for streaming media adaptation are similar to those for
Web page adaptation services.
2.6.3 Technical Challenges
The adaptation of streaming media will add more complexity to the caching
proxy platform and the technical challenges of these kind of services have
yet to be explored.
2.7 Request Filtering
2.7.1 Abstract
The success of Web filtering/blocking systems like NetNanny
(http://www.netnanny.com) and WebSense (http://www.websense.com) shows that
there is a great need for solutions that let the owner of a Web access device
control what kind of Web content can be accessed with his device. Parents,
for instance, often demand a means of blocking off offending material when
their children browse the Web. Also, companies might want to have control
over what kind of Web pages their employees can have access to. Companies
might also want to prevent their employees from using the available bandwidth
excessively for non-work related activities.
A request filtering service could provide a solution for all of the above. If
all Web page requests of a specific user are routed through a caching proxy
server, the content adaptation server could analyze the requests prior to
fulfilling them. The service module would have to identify the user and
determine the userÆs access level. The next step would be to look up the
classification of the requested Web page in a database.
2.7.2 Business model
This service could be offered to enterprises and to ISPs. A database of Web
pages that contain offending material could be obtained from companies that
have specialized in Web blocking systems.
2.7.3 Technical Challenges
The database on the proxy caching platform that contains the Web page
classifications needs to be updated on a regular basis. If the database is
provided by third parties, we have to provide them with a secure way of
updating the database.
If a Web access device is shared among different users who have different
access levels, it is not sufficient to identify the Web access device.
Therefore it will probably be necessary that different users of a Web access
device use different user accounts.
McHenry et al. Expires Jan 2002 9
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
The owner of a Web access device must be able to define and change the access
rights of the user(s) of his device. This could be done through a Web
interface provided by the ISP/company.
2.8 Request Filtering through Content Analysis
2.8.1 Abstract
While this service is very similar to the one previously described, it works
more dynamically in that the content adaptation server analyzes the Web
content once it has been retrieved from either the proxy cache or the origin
server prior to sending it to the client.
Through the use of sophisticated content analysis algorithms it should be
possible to classify the analyzed Web content. If the classification of the
Web page matches the userÆs access level, the page will be delivered to the
client. Otherwise, the client will be denied the page. The analyzed page
along with its classification should be stored in the proxy cache so that
future requests for the same page do not require the cached Web to be
analyzed again. This will result in a better Web page delivery performance
for popular Web pages. The main benefit of this approach is that there is no
need to provide or maintain lists of forbidden Web sites, a process that per
definition must always lag behind the creation of new Web sites. If common
characteristics of a category of unwanted Web pages can be defined, it should
be possible to automatically detect whether a requested Web page falls in a
forbidden category.
2.8.2 Business model
This service could be offered to enterprises and ISPs. The content analysis
software could be obtained from software companies that have specialized in
this field.
2.8.3 Technical Challenges
In addition to the technical challenges described in the previous service
scenario, we would have to find a way of storing the classification
information of Web pages once they have been analyzed. One way to do this
would be to add a meta tag (possibly using the Resource Description Framework
[6] specification) with content rating information to a Web page before it is
cached. Subsequent requests of the same Web page would then require the
request filtering service module to scan the cached Web page for this
metadata in order to determine the content rating of the requested page.
2.9 Search Engine Index on Cached Web Pages
2.9.1 Abstract
A proxy usually contains the most frequently requested Web pages of the Web
users whose Web requests are routed through it. If we indexed the content of
all Web pages currently contained in one or more proxies, we would have an
index of Web pages that Web users are very likely to request (since they have
McHenry et al. Expires Jan 2002 10
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
been the most popular in the past). A search engine based on this index could
therefore yield a high hit rate when used by a group of users who have
similar interests and usually connect to the same caching proxies. The
benefit of this approach would be that the index could be created very fast
(there is no Web crawling to do) and that the search results could be
returned to the user directly from the network edge caching proxy. The
drawback, however, is that this search engine would index only a small
fraction of the existing Web pages. Web users have to be aware of this fact
when they use the cache-based search index service. Another approach would be
to display the proxy search results first while a global search engine
prepares the results of a global search in the meantime. As soon as the
global search results become available, they will be sent to the user.
2.9.2 Business model
The search engine service described above could be sold to big companies who
have users with similar interests and want to provide a fast search engine.
Companies offering traditional search engines could be interested in
combining their services with a cache-based search engine service to
accelerate the delivery of their search results.
2.9.3 Technical Challenges
If the cached Web pages of more than one caching proxy were to be indexed, we
would have to find a way of replicating the search index to all affected
caching proxy servers.
2.10 Language Translation
2.10.1 Abstract
Soon the majority of all Internet users will be non-English speaking. As most
of the current Web content is written in English, it becomes desirable to be
able to translate the English content to the Web userÆs local language, even
if the content provider does not offer translations of his Web content. An
automatic translation service for all Web pages could be implemented with a
content adaptation server.
The proxy server will determine the Web user's preferred language(s) and ask
whether the content requested should be translated to the user's preferred
language. If the content is to be translated, the proxy cache will forward
the Web content to a translation server where the page then is automatically
translated. The proxy could also locally store translated content eliminating
the need to repeat translations for different users.
2.10.2 Business model
The automatic language translation service will help break language barriers
and open new markets for e-commerce. The average non-English speaking Web
user will have access to more Web content. ISPs, especially those with
customers in non-English speaking countries, could offer this service to
their customers.
McHenry et al. Expires Jan 2002 11
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
2.10.3 Technical Challenges
The automatic translation of text found on Web pages is not a trivial task.
It will not be possible to translate a Web page automatically without running
the risk of rendering parts of it incomprehensible. Worse yet, the original
meaning could be changed and it is not said the reader of the translated page
will notice the change in meaning. It is questionable whether content
providers would even tolerate this kind of translation service.
Therefore it is very important that the client authorizes this translation
service and is fully aware of its potentially faulty behavior. It should also
be considered to mark translated pages in a specific way to remind the user
of the machine translation.
Other technical challenges include the automatic detection of the language
used in the original document and the clientÆs local language.
2.11 Watermarking
2.11.1 Abstract
[To Be Added]
2.11.2 Business model
[To Be Added]
2.11.3 Technical Challenges
[To Be Added]
2.12 Multiple Use Case Applicability
2.12.1 Abstract
[To Be Added]
2.12.2 Business model
[To Be Added]
2.12.3 Technical Challenges
[To Be Added]
3 Types Of Services
Operationally, the proxy/gateways processing of the in-stream data can be
broken into fast-path and slow-path operations. Fast-path can be
characterized as deterministic operations that can be done in real-time
without interfering with the provisioned performance and scale of the device.
McHenry et al. Expires Jan 2002 12
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
Proxying of the data without any additional services clearly falls into the
fast-path. Additional services such as the proposed Edge Side Includes (ESI)
initially suggest that they also fit into fast-path, since they have
predictable behavior and thus can be optimized for real time processing.
Other services such as virus detection have unpredictable processing times
and stall the pipeline process of the proxy. This suggests a slow-path
operation. Experience has shown that slow-path operations can adversely
affect the performance and scaling proxies. Having an OPES callout RPC to a
ôbuddyö server for these operations makes sense, since the operation itself
is much more expensive to perform than the latency tax of the callout RPC
protocol. The strategy is to have a separate cooperating system handle these
expensive operations and keep the more precious proxy resources applied to
fast-path operations.
There doesnÆt appear to be a one size fits all for OPES callout RPC
protocols. Operations that work on headers (URL rewrite comes to mind) or
small objects are well suited to fine grain RPCs, while operations that work
on entire objects (e.g., virus scanners) are well suited to complete stream
vectoring RPCs. Therefore, the OPES framework needs to specify callout
protocol requirements that allow for the possibility of multiple callout
protocols in order to optimally address these differences.
Remote callouts should also provide an extensible services model for proxies
as well. Many of the proxies are appliance based and don't allow general
services to be hosted on them in order to maintain highly reliable and
deterministic service. OPES remote callouts provide a mechanism to deploy
new services that may eventually be implemented in the fast-path should their
service demands warrant it.
4 Network Topologies
(These are illustrations of potential topologies, not scenarios, per se)
4.1 Callout Services on the Edge Proxy Device
This section will describe topologies for services that are likely to be
placed on an edge proxy device (e.g., for fast-path operations). Examples of
services that can be hosted on the edge device include caching, localization
and personalization services.
4.2 Callout Services on collocated callout servers
(e.g., inside the same administrative domain)
This section will describe topologies for services that are likely to be
placed on an nearby callout device (e.g., for slow-path operations). In this
topology, a callout server is a separate device collocated with the edge
server. This topology would be useful for virus scanning, transcoding of
streaming protocols.
4.3 Callout Services on non-collocated callout servers
(e.g., outside the same administrative domain)
This section will describe topologies for services that are likely to be
placed on an not-nearby callout device (e.g., for slow-path operations or
McHenry et al. Expires Jan 2002 13
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
fee-based transformations). Topologically (from a network perspective), this
is identical to the previous example. However, the callout server would be
located outside of the administrative domain in which the edge server
resides.
4.4 Callout for streaming services
This section will describe topologies for services that are likely to be
placed on an edge device used for modification of streaming data.
5 Component Deployment Scenarios
(This section would outline the places an edge server might be deployed and
what types of services might be hosted on them)
5.1 Near the edge
This section will contain a discussion of the deployment of edge services on
edge servers near the edge of the network.
5.2 In Front of Servers
This section will contain a discussion of the deployment of edge services on
edge servers that are located in front of Origin servers.
5.3 At hosting centers
This section will contain a discussion of the deployment of edge services on
edge servers that are located at remote hosting centers.
6 Processing Scenarios
6.1 Edge Side Includes
In this scenario, container pages are composed by the edge server from a
collection of includes, most of which are statically cached for a period of
time. Optimally as fast-path operations handled by local (intrinsic) service
modules.
6.2 Virus Scanning
Edge server virus scanningà In this scenario, large objects that are suspect
for viruses are delivered to remote callout servers for parallel processing.
Optimally as slow-path operations handled by remote service modules.
7 Rules In Edge Devices
(This section will contain a brief discussion of how rules might be applied
in an edge server)
McHenry et al. Expires Jan 2002 14
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
8 Acknowledgements
The authors acknowledge the contributions of influential precursor works done
by Andre Beck, Michael Condry, and Markus Hoffman. Much of this documentÆs
predecessor has been incorporated herein.
9 Author's Addresses
Stephen McHenry
CacheWare, Inc.
655 Campbell Technology Parkway, Suite 150
Campbell, CA 95008
US
Phone: +1-408-540-1270
Email: stephen@cacheware.com
Michael W. Condry
Intel Corporation
2111 NE 25th Avenue
M/S JF3-206
Hillsboro, OR 97124
US
Phone: +1-503-264-9019
Email: condry@intel.com
Gary Tomlinson
CacheFlow Inc.
Suite 201
12034 134th Ct. NE
Redmond, WA 98052
US
Phone: +1 425 820 3009
EMail: garyt@cacheflow.com
Markus Hofmann
Bell Labs Research
Lucent Technologies
101 Crawfords Corner Rd.
Holmdel, NJ 07733
US
Phone: (732) 332-5983
Email: hofmann@bell-labs.com
Hilarie Orman
Volera, Inc.
US
EMail: horman@volera.com
McHenry et al. Expires Jan 2002 15
Internet Draft OPES Use Cases and Deployment Scenarios July 2001
10 References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC
2026, October 1996.
2 Tomlinson, G., et al., "Extensible Proxy Services Framework", Work in
Progress, Internet Draft draft-tomlinson-epsfw-00.txt, July 2000.
3 World Wide Web Consortium (W3C), http://www.w3.org.
4 The Wireless Application Protocol (WAP) Forum, http://www.wapforum.org/.
5 ICAP Protocol Group, "ICAP - the Internet Content Adaptation Protocol",
submitted as Internet Draft draft-elson-opes-icap-00.txt, (previous
version available at http://www.i-cap.org/), November 17, 2000.
6 Resource Description Framework (RDF), http://www.w3.org/RDF.
7 Open Proxy Extensible Services (OPES), http://www.extproxy.org.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole
or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the Internet
Society.
McHenry et al. Expires Jan 2002 16