Network Working Group A. Barbir Request for Comments: 3752 Nortel Networks Category: Informational 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 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios Status of this Memo 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 Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThis 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 2. Types of OPES services . . . . . . . . . . . . . . . . . . . . 3 2.1. Services performed on requests . . . . . . . . . . . . . 3 2.1.1. Services intending to modify requests . . . . . 3 2.1.2. Services *not* intending to modify requests . . 4 2.2. Services performed on responses. . . . . . . . . . . . . 4 2.2.1. Services intending to modify responses . . . . . 4 2.2.2. Services *not* intending to modify responses . . 5 2.3. Services creating responses. . . . . . . . . . . . . . . 5 3. OPES deployment scenarios . . . . . . . . . . . . . . . . . . 5 3.1. Surrogate Overlays . . . . . . . . . . . . . . . . . . . 6 3.2. Delegate Overlays . . . . . . . . . . . . . . . . . . . 7
3.3. Enterprise environment . . . . . . . . . . . . . . . . . 8 3.4. Callout Servers . . . . . . . . . . . . . . . . . . . . 9 3.5. Chaining of OPES data filters and callout servers . . . 9 3.5.1. Chaining along the content path. . . . . . . . . 9 3.5.2. Chaining along the callout path. . . . . . . . . 9 4. Failure cases and service notification . . . . . . . . . . . . 10 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 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  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 , 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  about OPES. Other OPES documents that may be relevant are, "OPES Service Authorization and Enforcement Requirements" . See references [3, 4] for recommended background reading. 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
services based on various criteria such as time of the day or the employee access privileges. o Hiding the data consumer's identity, user agent, or referrer. o Adding user preferences or device profile to the service request to get personalized or adapted services. o Blocking or redirecting a service request due to a corporate policy. An OPES processor may also modify a service request on behalf of the data provider in several ways, such as: o Redirecting the request to a different server to reduce the server work load. o Redirecting image requests to improve access time.
profiles and templates necessary to transcode the original content into a format appropriate for mobile devices of limited screen size and display capabilities. o Language translation: the data provider may not have all the translation capabilities needed to deliver the same content in multiple languages to various areas around the world. An OPES processor may perform the language translation or it may invoke different callout servers to perform different language translation tasks.
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. 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 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
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.
provider, resulting in inability for the service to operate, he (or the language service provider) can contact the content provider. o If the content provider gets complaints from users about the translation service and feels that the problem is not in the content but in the service, he may recommend that the service not be applied to his pages. He can do that through content headers, for example, with the notation "No OPES service #8D3298EB" or "No OPES class language translation". o End user's ISP or enterprise uses OPES to control user access based on user profiles. The end user can see that the OPES services are being applied by his ISP, but he cannot control them. If he feels that the transformations bowdlerize the content he can complain to the provider organization. o The content provider or end user relies on a content distribution network and OPES is used within that network. OPES may be authorized by either the content provider, end user, or both. The content provider may suspect that his access control rules are not being applied properly, for example. He may ask for notification on all accesses to his content through a log. This request and the logfile are outside the OPES architecture; there are security implications for the request, the response, and the resources used by the logfile. 1].  A. Barbir et al., "An Architecture for Open Pluggable Edge Services (OPES)", Work in Progress, July 2002.  Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.  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.
 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.  OPES Working Group, "OPES Service Authorization and Enforcement Requirements", Work in Progress, May 2002.  Beck, A., et al., "Requirements for OPES Callout Protocols", Work in Progress, July 2002.
Stephen McHenry 305 Vineyard Town Center, #251 Morgan Hill, CA 95037 US Phone: +1 408 683 2700 EMail: firstname.lastname@example.org Hilarie Orman Purple Streak Development EMail: email@example.com Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01803 US EMail: firstname.lastname@example.org
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. Intellectual Property 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.