RFC 3752 INFORMATIONAL OPES · INTERMEDIARIES
Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
Examples of what OPES services could do to requests and responses, and how they could be deployed.
RFC EDITOR
Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, DOI 10.17487/RFC3752, April 2004, <https://www.rfc-editor.org/info/rfc3752>.
BIBTEX
@misc{rfc3752,
series = {Request for Comments},
number = 3752,
howpublished = {RFC 3752},
publisher = {RFC Editor},
doi = {10.17487/RFC3752},
url = {https://www.rfc-editor.org/info/rfc3752},
author = {A. Barbir and E. Burger and R. Chen and S. McHenry and H. Orman and R. Penno},
title = {{Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios}},
pagetotal = 14,
year = 2004,
month = apr,
} RFC text
Contents
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.
Abstract
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.
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 . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
2. Types of OPES services
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
2.1. Services performed on requests
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.
2.1.1. Services intending to modify requests
An OPES processor may modify a service request on behalf of the data
consumer for various reasons, such as:
o 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.
o 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.
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.
2.1.2. Services *not* intending to modify requests
An OPES processor may invoke useful service applications that do not
modify the user requests. Examples include:
o Administrative functions for the data provider, such as service
monitoring or usage tracking for billing purposes.
o 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 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.
2.2.1. Services intending to modify responses
There are several reasons why responses from the data providers might
be modified before delivery to the data consumer:
o Content adaptation: the data provider may not have all the device
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.
2.2.2. Services *not* intending to modify responses
An OPES service may be performed on the responses without modifying
them. Examples include:
o Logging/Monitoring: Each response may be examined and recorded for
monitoring or debugging purposes.
o 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.
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.
3. OPES deployment scenarios
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.
3.1. Surrogate Overlays
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
3.2. Delegate 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
3.3. Enterprise environment
Deployment of OPES services in an enterprise environment is unique in
several ways:
o Both data providers and data consumers are in the same
administrative domain and trust domain. This implies that the
logical OPES administrator has the authority to enforce corporate
policies on all data providers, data consumers, and OPES entities.
o In the case when a callout server outside the corporate firewall
is invoked for services (such as language translation) that cannot
be performed inside the corporation, care must be taken to
guarantee a secure communication channel between the callout
server and corporate OPES entities. The callout server must also
adhere to all corporate security policies for the services
authorized.
3.4. Callout Servers
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.
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 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.
3.5.1. Chaining along the content path
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.
3.5.2. Chaining along the callout path
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.
4. Failure cases and service notification
These are illustrative cases where information about OPES processing
can help endpoint users determine where and why content modifications
are being performed.
o Content provider uses an OPES data processor to enhance content
based only on context local to the provider. The local context
might be time of day, local URL, or available advertising, for
example. The content provider might find OPES logging to be
sufficient for debugging any problems in this case. However, the
content provider might also try direct probing by issuing a
request for the content and examining headers related to tracing.
If unexpected parameters show up in the trace headers, the content
provider's administrator can use these to correct the OPES rules
or detect the presence of an unexpected OPES processor in the
content path.
o Content provider uses an OPES data processor to enhance content
based on context related to the requestor. The requestor may
notice that his requests do not elicit the same response as
another requestor. He may, for example, get an error message. If
he believes there is a configuration error on the OPES data
processor, he will need to provide information to the
administrator of it. If the information includes "OPES service
access control, action: blocked", for example, he can inquire
about the circumstances that will allow him to be added to the
access control list. In another example, if he sees a picture
unrelated to the surrounding text, and if the tracing shows "OPES
service choose picture, action: insert 640x480 weather.gif", he
might complain that the OPES service does not properly recognize
his geographic location and inserts the wrong weather map. In any
case, if the information is forwarded to the content provider, the
problem may be fixed.
o End user has OPES processor available as part of his network
access environment. The end user may have selected "translate
English to Spanish" as an OPES service. If he sees "OPES service
language translation, action: destination language not supported,
no action", then he may inquire of the OPES service provider about
what languages are supported by the package. If the end user
feels that the source language is not properly represented by the
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.
5. Security Considerations
The document presents usage scenarios and deployment cases. Issues
related to the overall security of OPES entities are given in [1].
6. Informative References
[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 would like to thank the participants of the OPES WG for
their comments on this document.
8. Authors' Addresses
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
9. 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
PROBLEMThe OPES architecture allows services at intermediaries to analyze and transform application-level messages, but it needs concrete examples of what such services are and where they run.
MECHANISMThe memo sorts OPES services into those acting on requests, on responses, and those creating responses, then describes surrogate, delegate, enterprise, callout server and chaining deployments.
WHAT IT OFFERSIt also gives illustrative failure cases showing how tracing information can tell users and providers where a modification happened. It defines no protocol.
§1What OPES Is For
The Open Pluggable Edge Services (OPES) architecture enables cooperative application services between a data provider, a data consumer, and zero or more OPES processors. These services analyze and possibly transform application-level messages. Filtering rules installed on the processor decide when a service runs, and the service may run locally or on remote callout servers.
This memo collects examples of useful services and of deployment scenarios. The two main scenarios from the OPES architecture are surrogate overlays, which act for data providers, and delegate overlays, which act for data consumers. The authors note that the IAB has expressed architectural and policy concerns in RFC 3238.
An OPES helper sits between a website and a visitor and can change or check the messages. Rules tell it when to do its job, and it can ask other helpers for hard jobs.
§2Types of OPES Services
Figure 1 of the RFC shows four service activation points in an OPES processor handling HTTP: a request arriving (1), a request leaving (2), a response arriving (3) and a response leaving (4). A data dispatcher examines the rules, enforces policy and invokes service applications at each point.
Services on requests that modify them include parental control, restricting or redirecting access by time of day or employee privileges, hiding the consumer's identity, user agent or referrer, adding user preferences or a device profile, and redirecting requests to reduce server load. Services that do not modify requests include service monitoring, usage tracking for billing, and user profiling with the user's consent.
Services on responses include content adaptation for mobile devices with limited screens and language translation. Logging, monitoring and accounting are examples that leave responses alone. In a caching proxy, an encoding step may happen before storing content and a decoding step before returning it.
Some services create responses, such as assembling a web page with a local weather forecast based on the requestor's preferences, from cached weather data or by embedding a URL that points to another server.
The helper can look at a question on its way in, or at an answer on its way back, and it can change what it sees or just take notes. Sometimes it even builds the answer itself.
- 1Request arrives — A request enters the OPES processor.
- 2Request leaves — A request is about to leave the processor.
- 3Response arrives — A response enters the processor.
- 4Response leaves — A response is about to leave the processor.
§3Deployment Scenarios
OPES entities can be deployed on an overlay network, a virtual network layered over an existing IP network to perform application-level services. At the application level this is called an OPES Services Network. Two kinds of parties want these services: delegates, authorized agents acting for data consumers, and surrogates, authorized agents acting for data providers. Parties enforcing policies must communicate them, and are trusted to follow them.
A surrogate overlay has authority to provide services for one or more origin servers (for example dynamic page assembly, watermarking and content adaptation) and sits in the origin server's authoritative domain. A delegate overlay acts for data consumer applications (for example virus scanning and content filtering) and belongs to the consumer's authoritative domain.
In an enterprise, providers and consumers share one administrative and trust domain, so the OPES administrator can enforce corporate policy on all of them. If a callout server outside the corporate firewall is used, for example for translation, the channel must be secure and the server must follow corporate security policies.
Callout servers can share workload or supply specialized services; operations on large objects such as virus scanning are better handled on a dedicated server. Processors can also be chained along the content path, where content passes through several processors in series, or along the callout path, where one processor acts as a content-level switch. Chaining of callout servers is deferred from version 1 of the protocol.
Some helpers work for the website and some work for the visitor. Inside a company one boss runs everything. A helper can pass heavy jobs to a bigger helper, and helpers can be lined up like an assembly line.
| Overlay | Acts on behalf of | Example services | Authoritative domain |
|---|---|---|---|
| Surrogate | Data providers (origin servers) | Page assembly, watermarking, content adaptation | The origin server's |
| Delegate | Data consumer applications | Virus scanning, content filtering | The consumer's |
§4Failures and Service Notification
The RFC gives illustrative cases where information about OPES processing helps endpoints learn where and why content was changed. A content provider can probe by requesting its own content and examining trace headers, which may reveal wrong parameters or an unexpected OPES processor in the path.
A requestor who gets a different response than another may report trace text such as "OPES service access control, action: blocked" to the administrator. A user who chose "translate English to Spanish" might see "destination language not supported, no action". A provider unhappy with a translation service might signal "No OPES service #8D3298EB" or "No OPES class language translation" in content headers.
Where an ISP or enterprise applies OPES, the end user can see it but cannot control it. For a content distribution network, a provider's log request is outside the OPES architecture and has its own security implications.
If a helper changes something, it should leave a note saying so. Then people can tell who did it and ask them to fix it.
§5Security Considerations
The document presents usage scenarios and deployment cases only. For the overall security of OPES entities it points to the OPES architecture document, which at the time was a work in progress. Trust and policy communication are touched on in the deployment discussion above, but the memo adds no security requirements of its own.
This note only lists examples. The safety rules for helpers are written in a different document.
§6References
[2]RFC 3238Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.January 2002[3]RFC 3198Westerinen, A., et al., "Terminology for Policy-Based Management", RFC 3198, November 2001.November 2001[4]RFC 2616Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.June 1999