RFC 3752
Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
RFC 3752: Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios 🦋 (part 1 of 3)
okay bestie, let's get into it 💖 This one is an Informational RFC from April 2004, from the Network Working Group. It was written by A. Barbir (Nortel Networks), E. Burger (Brooktrout Technology, Inc.), R. Chen (AT&T Labs), S. McHenry (Individual Contributor), H. Orman (Purple Streak Development), and R. Penno (Nortel Networks). It doesn't list anything it obsoletes or updates. Its whole job is to show why OPES is useful and where it would live in a real network 🌸
Status of this Memo ✨
This memo gives information to the Internet community 🫶 It does not specify an Internet standard of any kind, so this is more "here's the vibe and the use cases" than "here's the rulebook." Distribution of this memo is unlimited 💅
Copyright Notice 🎀
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🧚
This memo talks through use cases and deployment scenarios for Open Pluggable Edge Services (OPES). It looks at the kinds of services that could be run on requests and/or responses 👑
Table of Contents 💜
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 . . . . . . . . . . . . . . . . . . . 141. Introduction 🌈
okay so OPES is the Open Pluggable Edge Services architecture 🦋 It lets services work together between a data provider, a data consumer, and zero or more OPES processors [1]. These services look at application-level messages going between the provider and the consumer, and they might change them too. How a service runs is controlled by a set of filtering rules that live on the OPES processor 💅
The rules can kick off service applications that live on the OPES processor itself. Or, the processor can hand off some of the work by talking to one or more remote callout [6] servers. Main character energy for the processor, honestly 👑
This doc shows examples of where OPES would be useful ✨ There are different kinds of OPES services: ones that modify requests, ones that modify responses, and a special case of the second group, ones that create responses 🎀
We also look at different ways OPES services can be deployed 🧚 The two main deployment scenarios from 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 doc also covers combined surrogate and delegate overlays, which you might see in an enterprise deployment 💼
Here's the roadmap 🗺️ Section 2 covers the types of OPES services. Section 3 introduces OPES deployment scenarios. Section 4 talks about failure cases and service notification. Section 5 covers security considerations 🔥
The IAB has raised architectural and policy concerns [2] about OPES 😬 Another OPES doc that might be relevant is "OPES Service Authorization and Enforcement Requirements" [5]. For recommended background reading, check references [3, 4] 📚
2. Types of OPES services 💖
OPES scenarios involve services that can run on requests for data and/or on responses. OPES services fall into three categories: services performed on requests, services performed on responses, and services creating responses ✨ Figure 1 shows the four service activation points for an OPES processor. The data dispatcher looks at 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 Points2.1. Services performed on requests 🫶
An OPES service performed on HTTP requests can happen when a request arrives at an OPES processor (point 1), or when it's about to leave the OPES processor (point 2) 🦋
These services split into two cases: the ones that intend to modify requests, and the ones that don't 💅
2.1.1. Services intending to modify requests 🔥
An OPES processor might modify a service request on behalf of the data consumer, for a bunch of reasons ✨
- Owner of a Web access device might need control over what kind of Web content can be accessed with the device, parental control for example. 👶
- Organization may restrict or redirect access to certain web services based on various criteria such as time of the day or the employee access privileges. 🕒
- Hiding the data consumer's identity, user agent, or referrer. 🙈
- Adding user preferences or device profile to the service request to get personalized or adapted services. 🎀
- Blocking or redirecting a service request due to a corporate policy. 🚫
An OPES processor might also modify a service request on behalf of the data provider, in a couple of ways 🌸
- Redirecting the request to a different server to reduce the server work load. 🖥️
- Redirecting image requests to improve access time. 🖼️
2.1.2. Services not intending to modify requests 🌷
An OPES processor may invoke useful service applications that don't modify user requests. Examples include:
- Administrative functions for the data provider, such as service monitoring or usage tracking for billing purposes. 🧾
- Useful services for the data consumer, such as user profiling (with the user's consent) for service adaptation later on. 🫧
2.2. Services performed on responses 💜
An OPES service performed on HTTP responses can happen when a response arrives at an OPES processor (point 3), or when it's about to leave the OPES processor (point 4). For a caching proxy, the first one might be an encoding operation before the content gets stored in the cache, while the second might be a decoding operation before the content goes back to the data consumer 🧚
These services split into two cases too: the ones that intend to modify responses, and the ones that don't ✨
2.2.1. Services intending to modify responses 🍓
There are a few reasons responses from data providers might get modified before they reach the data consumer 💅
- Content adaptation: the data provider may not have all the device profiles and templates needed to transcode the original content into a format that works for mobile devices with small screens and limited display capabilities. 📱
- Language translation: the data provider may not have all the translation capabilities needed to deliver the same content in multiple languages to different areas around the world. An OPES processor may do the language translation itself, or it may call different callout servers to handle different translation tasks. 🌍
2.2.2. Services not intending to modify responses 🌙
An OPES service may run on responses without changing them. Examples include:
- Logging/Monitoring: Each response may be examined and recorded for monitoring or debugging purposes. 🔍
- Accounting: An OPES processor may record the usage data (time and space) of each service request for billing purposes. 🧮
2.3. Services creating responses 🌈
Services creating responses may include OPES services that dynamically assemble web pages based on the context of the data consumer application. This is where it gets really fun 🎀
Picture a content provider offering web pages that include a local weather forecast based on the requestor's preferences. The OPES service could analyze the received requests, identify the matching user preferences, select the right templates, insert the corresponding local weather forecasts, and then deliver the content to the requestor 🌤️ Worth noting: the OPES processor may do these tasks with or without direct access to the weather data. For example, the service could use locally cached weather data, or it could just embed a URL pointing to another server that holds the latest local weather forecast information 🦋
3. OPES deployment scenarios ✨
Okay so, OPES entities can be deployed over an overlay network that supports handing out data services in a distributed way 🌸 An overlay network is basically a virtual network of connected devices sitting on top of an existing underlying IP network, and its whole job is to run application-level services. It's giving infrastructure glow-up 💅
Overlays turn into virtual networks through OPES entities, and that's what lets the network infrastructure deliver better services to data consumer and provider applications. At the application level, these overlay networks are called OPES Services Networks 🦋
There are two parties who care about the services OPES entities offer: the delegate and the surrogate. Delegates are authorized agents acting on behalf of data consumers. Surrogates are authorized agents acting on behalf of data providers. Two main characters, no cap 👑
Everyone who enforces policies has to tell the other involved parties what those policies are. Those parties are trusted to stick to what was communicated 🫶
To delegate fine-grained trust, the parties have to share policy information. They can do that through an implicit contract, a setup protocol, a dynamic negotiation protocol, or inline with application data headers ✨
3.1. Surrogate Overlays
A surrogate overlay is a specific kind of OPES service network. It's been given the authority to provide data services on behalf of one or more origin servers. Those services include, but aren't limited to, dynamic assembling of web pages, watermarking, and content adaptation 🎀
The elements of surrogate overlays act on behalf of origin servers, and they logically belong to the authoritative domain of those origin servers. Here's the picture, Figure 2 🧚
*********************************************
* *
* +--------+ Authoritative *
* | Origin | Domain *
* | Server | *
* +--------+ +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* | / *
* | / *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | *
*********************************************
|
|
|
+---------------------------+
| Data consumer application |
+---------------------------+
Figure 2: Authoritative Domains for Surrogate Overlays3.2. Delegate Overlays
A delegate overlay is also a specific kind of OPES service network, and it's been delegated the authority to provide data services on behalf of one or more data consumer applications 💜
Delegate overlays take over services the data consumer applications would otherwise handle themselves. Examples include, but aren't limited to, virus scanning and content filtering 🔥
The elements of delegate overlays logically belong to the authoritative domain of the matching data consumer application. Check out Figure 3 🌈
+--------+
| Origin |
| Server |
+--------+
|
|
|
*********************************************
* | *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | \ *
* | +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* +---------------------+ *
* | Data consumer Appl. | Authoritative *
* +---------------------+ Domain *
* *
*********************************************
Figure 3: Authoritative Domains for Delegate Overlays3.3. Enterprise environment
Running OPES services in an enterprise environment is special in a few ways 🍓
- Data providers and data consumers are in the same administrative domain and the same trust domain. That means the logical OPES administrator has the authority to enforce corporate policies on all data providers, data consumers, and OPES entities. Main character administrator energy 👑
- If a callout server outside the corporate firewall gets invoked for services that can't be done inside the corporation (language translation is the example), care must be taken to guarantee a secure communication channel between that callout server and the corporate OPES entities. The callout server must also adhere to all corporate security policies for the services it's authorized for 🔒
3.4. Callout Servers
Sometimes OPES services get a boost from callout servers. These can spread the workload of OPES processors, or let you contract specialized services from other OPES providers 🧚
Generally, operations like virus scanning that work on large objects are better handled by a dedicated callout server. That server is designed for memory-intensive tasks in a way an OPES processor can't match 💪
3.5. Chaining of OPES data filters and callout servers
OPES data processors can be "chained" in two dimensions: along the content path or along the callout path. In the second case, the callout servers can themselves be lined up in series to handle requests. Any content 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.
3.5.1. Chaining along the content path
An OPES provider can assign OPES services to a set of processors arranged in series. All content might move through the series, and if the content matches a processor's rules, it gets that service. That's how content can be enhanced by several services at once. This works well when the services are fairly independent. For example, content might get assembled by a service early in the chain and then further decorated by a later service 🎨
3.5.2. Chaining along the callout path
Or, 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 build a processing schedule for the content and send it to other OPES data processors and/or callout servers. For example, OPES processor A might handle all services that assemble 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 are needed for a particular content object, and it would direct the content to them. In turn, those processors might use several callout servers to get the job done ✨
4. Failure cases and service notification ✨
okay so this section is all about when things go sideways 😭 and how OPES processing info can help end users figure out where and why their content got changed. let's get into the chaos 💅
- Content provider, local context only 🌸 The provider uses an OPES data processor to tweak content based only on stuff local to the provider, like time of day, local URL, or available advertising. OPES logging might be enough for debugging here. But the provider could also probe directly by sending a request for the content and checking tracing headers. If weird parameters pop up in those trace headers, the provider's admin can fix the OPES rules or catch an unexpected OPES processor sneaking into the content path 👀
- Content provider, requestor-based context 🎀 The provider uses an OPES data processor to enhance content based on who's asking. So the requestor might notice their requests don't get the same response as someone else's, like an error message. If he thinks the OPES data processor is misconfigured, he'll need to give the admin info. For example, if the info includes
OPES service access control, action: blocked, he can ask what it takes to get added to the access control list. Another example: he sees a picture that has nothing to do with the text, and the tracing saysOPES service choose picture, action: insert 640x480 weather.gif. He might complain that the OPES service didn't recognize his geographic location and dropped in the wrong weather map 🌦️ Either way, if that info gets forwarded to the content provider, the problem might get fixed 🙌 - End user with an OPES processor in their network access 🦋 The end user might have picked "translate English to Spanish" as an OPES service. If they see
OPES service language translation, action: destination language not supported, no action, they can ask the OPES service provider which languages the package supports. If the end user feels the source language isn't represented properly so the service can't work, they (or the language service provider) can contact the content provider. 💬 - Provider blocking a service they don't like 💅 If the content provider gets complaints about the translation service and decides the problem is the service and not the content, they can recommend the service not be applied to their pages. They can do that through content headers, like
No OPES service #8D3298EBorNo OPES class language translation. Iconic boundary-setting, honestly 😤 - ISP or enterprise controlling access by user profile 🧱 The end user can see that OPES services are being applied by their ISP, but they can't control them. If they feel the transformations bowdlerize the content, they can complain to the provider organization. Not ideal, but at least they know who to yell at 😭
- Content distribution network with OPES inside 🌐 The content provider or end user relies on a content distribution network, and OPES is used within that network. OPES may be authorized by the content provider, the end user, or both. The content provider might suspect their access control rules aren't being applied properly, so they may ask for notification on all accesses to their content through a log. Heads up though: this request and the logfile are outside the OPES architecture, and there are security implications for the request, the response, and the resources the logfile uses. Bestie, be careful with that one 🙈
5. Security Considerations 🔐
okay real talk, this section is short but it's giving "go read the other doc." 📖 The document just presents usage scenarios and deployment cases. The overall security of OPES entities is covered in [1], so go check that out 💖
6. Informative References 📚
these are the receipts, bestie. every single reference, exactly as written 🧾
[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.7. Acknowledgements 🫶
the authors want to thank everyone in the OPES WG who dropped comments on this doc. you all slayed 💜
8. Authors' Addresses 💌
meet the squad, with all their contact info exactly as it appears in the RFC 🧚
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.com9. Full Copyright Statement ⚖️
Copyright (C) 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.
Intellectual Property 🧠
the IETF doesn't take a position on whether any IPR claims covering this technology are valid or in scope, or whether a license would be available. it also hasn't made any independent effort to find out what rights might apply. for the procedures on rights in RFC documents, check BCP 78 and BCP 79 📜
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
the IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🙏
Acknowledgement 💖
funding for the RFC Editor function is currently provided by the Internet Society. thank you for keeping the lights on 🌈✨
📦 where this page comes from
- ietf: rfc3752 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms