|
Network Working Group Request for Comments: 3752 Category: Informational |
A. Barbir Nortel Networks E. Burger Brooktrout Technology, Inc. R. Chen AT&T Labs S. McHenry Individual Contributor H. Orman Purple Streak Development R. Penno Nortel Networks April 2004 |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (2004). All Rights Reserved.
This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses.
1. Introduction
2. Types of OPES services
2.1. Services performed on requests
2.1.1. Services intending to modify requests
2.1.2. Services *not* intending to modify requests
2.2. Services performed on responses
2.2.1. Services intending to modify responses
2.2.2. Services *not* intending to modify responses
2.3. Services creating responses
3. OPES deployment scenarios
3.1. Surrogate Overlays
3.2. Delegate Overlays
3.3. Enterprise environment
3.4. Callout Servers
3.5. Chaining of OPES data filters and callout servers
3.5.1. Chaining along the content path
3.5.2. Chaining along the callout path
4. Failure cases and service notification
5. Security Considerations
6. Informative References
7. Acknowledgements
8. Authors' Addresses
9. Full Copyright Statement
The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of filtering rules installed on the OPES processor.
The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout [6] servers.
The document presents examples of services in which Open Pluggable Edge Services (OPES) would be useful. There are different types of OPES services: services that modify requests, services that modify responses, and a special case of the latter, services that create responses.
The work also examines various deployment scenarios of OPES services. The two main deployment scenarios, as described by the OPES architecture [1], are surrogate overlays and delegate overlays. Surrogate overlays act on behalf of data provider applications, while delegate overlays act on behalf of data consumer applications. The document also describes combined surrogate and delegate overlays, as one might find within an enterprise deployment.
The document is organized as follows: Section 2 discusses the various types of OPES services. Section 3 introduces OPES deployment scenarios. Section 4 discusses failure cases and service notification. Section 5 discusses security considerations.
The IAB has expressed architectural and policy concerns [2] about OPES. Other OPES documents that may be relevant are, "OPES Service Authorization and Enforcement Requirements" [5]. See references [3, 4] for recommended background reading.
OPES scenarios involve services that can be performed on requests for data and/or responses. OPES services can be classified into three categories: services performed on requests, services performed on responses, and services creating responses. In Figure 1, the four service activation points for an OPES processor are depicted. The data dispatcher examines OPES rules, enforces policies, and invokes service applications (if applicable) at each service activation point.
+------------------------------------------------+
| +-------------+-------------+ |
| | Service Application | |
| +---------------------------+ |
Responses | Data Dispatcher | Responses
<============4== +---------------------------+ <=3===========
Requests | HTTP | Requests
=============1=> +---------------------------+ ==2==========>
| OPES Processor |
+------------------------------------------------+
Figure 1: Service Activation Points
An OPES service performed on HTTP requests may occur when a request arrives at an OPES processor (point 1) or when it is about to leave the OPES processor (point 2).
The services performed on requests can further be divided into two cases: those that intend to modify requests and those that do not.
An OPES processor may modify a service request on behalf of the data consumer for various reasons, such as:
services based on various criteria such as time of the day or the employee access privileges.
An OPES processor may also modify a service request on behalf of the data provider in several ways, such as:
An OPES processor may invoke useful service applications that do not modify the user requests. Examples include:
An OPES service performed on HTTP responses may occur when a response arrives at an OPES processor (point 3) or when it is about to leave the OPES processor (point 4). In the case of a caching proxy, the former service may be an encoding operation before the content is stored in the cache, while the latter may be a decoding operation before the content is returned to the data consumer.
The services performed on responses can further be divided into two cases: those that intend to modify responses and those that do not.
There are several reasons why responses from the data providers might be modified before delivery to the data consumer:
profiles and templates necessary to transcode the original content into a format appropriate for mobile devices of limited screen size and display capabilities.
An OPES service may be performed on the responses without modifying them. Examples include:
Services creating responses may include OPES services that dynamically assemble web pages based on the context of the data consumer application.
Consider a content provider offering web pages that include a local weather forecast based on the requestor's preferences. The OPES service could analyze received requests, identify associated user preferences, select appropriate templates, insert the corresponding local weather forecasts, and would then deliver the content to the requestor. Note that the OPES processor may perform the tasks with or without direct access to the weather data. For example, the service could use locally cached weather data or it could simply embed a URL pointing to another server that holds the latest local weather forecast information.
OPES entities can be deployed over an overlay network that supports the provisioning of data services in a distributed manner. Overlay networks are an abstraction that creates a virtual network of connected devices layered on an existing underlying IP networks in order to perform application level services.
The use of overlay networks creates virtual networks that via OPES
entities enables the necessary network infrastructure to provide better services for data consumer and provider applications. At the application level, the resulting overlay networks are termed OPES Services Networks.
There are two parties that are interested in the services that are offered by OPES entities, the delegate and the surrogate. Delegates are authorized agents that act on behalf of data consumers. Surrogates are authorized agents that act on behalf of data providers.
All parties that are involved in enforcing policies must communicate the policies to the parties that are involved. These parties are trusted to adhere to the communicated policies.
In order to delegate fine-grained trust, the parties must convey policy information by implicit contract, by a setup protocol, by a dynamic negotiation protocol, or in-line with application data headers.
A surrogate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more origin servers. Such services include, but are not limited to, dynamic assembling of web pages, watermarking, and content adaptation.
The elements of surrogate overlays act on behalf of origin severs and logically belong to the authoritative domain of the respective origin servers. The scenario is depicted in Figure 2.
*********************************************
* *
* +--------+ Authoritative *
* | Origin | Domain *
* | Server | *
* +--------+ +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* | / *
* | / *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | *
*********************************************
|
|
|
+---------------------------+
| Data consumer application |
+---------------------------+
Figure 2: Authoritative Domains for Surrogate Overlays
A delegate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more data consumer applications.
Delegate overlays provide services that would otherwise be performed by the data consumer applications. Such services include, but are not limited to, virus scanning and content filtering.
The elements of delegate overlays logically belong to the authoritative domain of the respective data consumer application. The situation is illustrated in Figure 3.
+--------+
| Origin |
| Server |
+--------+
|
|
|
*********************************************
* | *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | \ *
* | +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* +---------------------+ *
* | Data consumer Appl. | Authoritative *
* +---------------------+ Domain *
* *
*********************************************
Figure 3: Authoritative Domains for Delegate Overlays
Deployment of OPES services in an enterprise environment is unique in several ways:
In some cases the deployment of OPES services can benefit from the use of callout servers that could distribute the workload of OPES processors or to contract specialized services from other OPES providers.
In general, operations such as virus scanning that operate on large objects are better handled through the use of a dedicated callout server that is better designed to perform the memory intensive task than what an OPES processor could handle.
OPES data processors can be "chained" in two dimensions: along the content path or along the callout path. In the latter case, the callout servers can themselves be organized in series for handling requests. Any content that is touched by more than one data processor or more than one callout server has been handled by a "chain".
NOTE: Chaining of callout servers is deferred from version 1 of the Protocol. The discussion of chaining is included here for completeness.
An OPES provider may have assigned OPES services to a set of processors arranged in series. All content might move through the series, and if the content matches the rules for a processor, it is subjected to the service. In this way, the content can be enhanced by several services. This kind of chaining can be successful if the services are relatively independent. For example, the content might be assembled by a service early in the chain and then further decorated by a later service.
Alternatively, an OPES data processor might act as a content-level switch in a cluster of other data processors and callout servers.
The first stage might develop a processing schedule for the content and direct it to other OPES data processors and/or callout servers. For example, OPES processor A might handle all services assembling content, OPES processor B might handle all services involving URL translation, and OPES processor C might handle all content security services. The first processor would determine that processors A and
C were needed for a particular content object, and it would direct the content to those processors. In turn, the processors might use several callout servers to accomplish the task.
These are illustrative cases where information about OPES processing can help endpoint users determine where and why content modifications are being performed.
provider, resulting in inability for the service to operate, he (or the language service provider) can contact the content provider.
The document presents usage scenarios and deployment cases. Issues related to the overall security of OPES entities are given in [1].
[1] A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Work in Progress, July 2002.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5] OPES Working Group, "OPES Service Authorization and Enforcement Requirements", Work in Progress, May 2002.
[6] Beck, A., et al., "Requirements for OPES Callout Protocols", Work in Progress, July 2002.
The authors would like to thank the participants of the OPES WG for their comments on this document.
Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Eric W. Burger
Brooktrout Technology, Inc.
18 Keewaydin Dr.
Salem, NH 03079
EMail: e.burger@ieee.org
Yih-Farn Robin Chen
AT&T Labs - Research
180 Park Avenue
Florham Park, NJ 07932
US
Phone: +1 973 360 8653
EMail: chen@research.att.com
Stephen McHenry
305 Vineyard Town Center, #251
Morgan Hill, CA 95037
US
Phone: +1 408 683 2700
EMail: stephen@mchenry.net
Hilarie Orman
Purple Streak Development
EMail: ho@alum.mit.edu
Reinaldo Penno
Nortel Networks
600 Technology Park Drive
Billerica, MA 01803
US
EMail: rpenno@nortelnetworks.com
Copyright © The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Funding for the RFC Editor function is currently provided by the Internet Society.