RFC 3836

Requirements for Open Pluggable Edge Services (OPES) Callout Protocols

📅 published August 2004, from ietf

RFC 3836: Requirements for Open Pluggable Edge Services (OPES) Callout Protocols 🎀

Okay bestie, so this is RFC 3836 💅 It's labelled Category: Informational and dated August 2004. The authors are A. Beck, M. Hofmann (Lucent Technologies), H. Orman (Purple Streak Development), R. Penno (Nortel Networks), and A. Terzis (Johns Hopkins University). The header doesn't list anything it obsoletes or updates, so no other RFC gets bumped by this one 🦋

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 (C) The Internet Society (2004).

Abstract 🌸

Okay so this doc lays out what the OPES (Open Pluggable Edge Services) callout protocol has to satisfy so it can support the remote execution of OPES services 🧚 The requirements are meant to help evaluate possible protocol candidates, and also to guide how those protocols get built.

Table of Contents 📚

1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
3.  Functional Requirements . . . . . . . . . . . . . . . . . . .   3
    3.1.  Reliability . . . . . . . . . . . . . . . . . . . . . .   3
    3.2.  Congestion Avoidance  . . . . . . . . . . . . . . . . .   3
    3.3.  Callout Transactions  . . . . . . . . . . . . . . . . .   3
    3.4.  Callout Connections . . . . . . . . . . . . . . . . . .   4
    3.5.  Asynchronous Message Exchange . . . . . . . . . . . . .   5
    3.6.  Message Segmentation  . . . . . . . . . . . . . . . . .   5
    3.7.  Support for Keep-Alive Mechanism  . . . . . . . . . . .   6
    3.8.  Operation in NAT Environments . . . . . . . . . . . . .   6
    3.9.  Multiple Callout Servers  . . . . . . . . . . . . . . .   6
    3.10. Multiple OPES Processors  . . . . . . . . . . . . . . .   6
    3.11. Support for Different Application Protocols . . . . . .   7
    3.12. Capability and Parameter Negotiations . . . . . . . . .   7
    3.13. Meta Data and Instructions  . . . . . . . . . . . . . .   8
4.  Performance Requirements  . . . . . . . . . . . . . . . . . .   9
    4.1.  Protocol Efficiency . . . . . . . . . . . . . . . . . .   9
5.  Security Requirements . . . . . . . . . . . . . . . . . . . .   9
    5.1.  Authentication, Confidentiality, and Integrity  . . . .   9
    5.2.  Hop-by-Hop Confidentiality. . . . . . . . . . . . . . .  10
    5.3.  Operation Across Untrusted Domains. . . . . . . . . . .  10
    5.4.  Privacy . . . . . . . . . . . . . . . . . . . . . . . .  10
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
7.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  10
    7.1.  Normative References. . . . . . . . . . . . . . . . . .  10
    7.2.  Informative References. . . . . . . . . . . . . . . . .  11
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
9.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  12
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  13

1. Terminology ✨

Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are read the way BCP 14, RFC 2119 [2] describes 🫶

2. Introduction 🌈

So OPES is the Open Pluggable Edge Services architecture [1], and it lets application services (called OPES services) team up between a data provider, a data consumer, and zero or more OPES processors 🤝 These services look at application-level messages going between the provider and the consumer, analyze them, and maybe transform them too 👀

The rules for running these services live on the OPES processor. When those rules get enforced, they can kick off service apps that are local to the processor. Or, the processor can hand off some of that work by working with one or more remote callout servers 📡 As [1] explains, an OPES processor talks to a callout server and invokes services on it using a callout protocol. This doc is where the requirements for that protocol live 💖

The requirements here come in three flavors: functional, performance, and security 💜 Each one is written as one or more statements, with a bit of explanation after when it helps.

3. Functional Requirements 🎀

3.1. Reliability

The OPES callout protocol MUST be able to provide ordered reliability for the communication between an OPES processor and callout server. Also, the callout protocol SHOULD be able to provide unordered reliability 🔥

To meet the reliability requirements, the callout protocol SHOULD specify that it has to be used with a transport protocol that gives ordered/unordered reliability at the transport layer. TCP [6] or SCTP [7] are examples 🌸

3.2. Congestion Avoidance

The OPES callout protocol MUST ensure that congestion avoidance matching the standard of RFC 2914 [4] gets applied to all communication between the OPES processor and callout server 🚦 For this, the callout protocol SHOULD use a congestion-controlled transport-layer protocol, presumably either TCP [6] or SCTP [7] ✨

3.3. Callout Transactions

The OPES callout protocol MUST enable an OPES processor and a callout server to perform callout transactions, which exist to exchange partial or complete application-level protocol messages (or modifications of them) 💅 More specifically, the callout protocol MUST enable an OPES processor to forward a partial or complete application message to a callout server, so one or more OPES services can process that forwarded message (or parts of it). The result of that service operation may be a modified application message 🦋 So the callout protocol MUST therefore enable the callout server to return a modified application message, or just the modified parts of one, to the OPES processor. Also, the callout protocol MUST enable a callout server to report the result of a callout transaction (for example, as a status code) back to the OPES processor 📮

A callout transaction is a message exchange between an OPES processor and a callout server, made up of a callout request and a callout response. Both the callout request and the callout response MAY each consist of one or more callout protocol messages, which is basically a series of protocol messages 🧚 A callout request MUST always contain a partial or complete application message. A callout response MUST always indicate the result of the callout transaction. A callout response MAY contain a modified application message 💜

Callout transactions always start with a callout request from an OPES processor, and they usually end with a callout response from a callout server. The OPES callout protocol MUST, however, also provide a mechanism that lets either endpoint of a callout transaction terminate it before the corresponding endpoint has fully received a callout request or response. That mechanism MUST ensure that a premature termination of a callout transaction doesn't lose any application message data 🫶

Premature termination is needed because some OPES services may finish before they've processed the whole application message. Content analysis services, for example, might be able to classify a Web object after looking at just its first few bytes 👀

3.4. Callout Connections

The OPES callout protocol MUST enable an OPES processor and a callout server to perform multiple callout transactions over a callout connection. Also, the callout protocol MUST provide a way to associate callout transactions with callout connections 🔗 A callout connection is a logical connection at the application layer between an OPES processor and a callout server. A callout connection MAY have certain parameters attached to it, such as parameters that control the fail-over behavior of connection endpoints. Callout connection-specific parameters MAY be negotiated between OPES processors and callout servers (see Section 3.12) 🌷

The OPES callout protocol MAY choose to multiplex multiple callout connections over a single transport-layer connection, but only if a flow control mechanism that guarantees fairness among the multiplexed callout connections is applied 🧁

Callout connections MUST always be initiated by an OPES processor. A callout connection MAY be closed by either endpoint, as long as doing so doesn't affect the normal operation of ongoing callout transactions tied to that connection 🚪

3.5. Asynchronous Message Exchange

The OPES callout protocol MUST support an asynchronous message exchange over callout connections 🌊

To let the OPES processor and callout server do asynchronous processing, it MUST be possible to separate request issuance from response processing. So the protocol MUST therefore allow multiple outstanding callout requests, and it has to provide a way to correlate callout responses with callout requests 🧩

Also, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request 🏃‍♀️

3.6. Message Segmentation

The OPES callout protocol MUST allow an OPES processor to forward an application message to a callout server in a series of smaller message fragments. The callout protocol MUST further enable the receiving callout server to reassemble the fragmented application message 🧸

Likewise, the callout protocol MUST enable a callout server to return an application message to an OPES processor in a series of smaller message fragments. The callout protocol MUST enable the receiving OPES processor to reassemble the fragmented application message 💖

Depending on the application-layer protocol on the data path, application messages can be really big (like audio/video streams) or of unknown size 📺 In both cases, the OPES processor has to start a callout transaction before it has received the entire application message, so the data consumer doesn't get stuck waiting forever 😭 So the OPES processor MUST therefore be able to forward fragments or chunks of an application message to a callout server as it receives them from the data provider or consumer. Likewise, the callout server MUST be able to process and return application message fragments as it receives them from the OPES processor 🌈

Message segmentation is also needed if the OPES callout protocol has a flow control mechanism for multiplexing multiple callout connections over a single transport-layer connection (see Section 3.4) 🦋

3.7. Support for Keep-Alive Mechanism 💖

okay bestie, so the OPES callout protocol MUST provide a keep-alive mechanism 🫶 and if it gets used, both endpoints of a callout connection can tell when the other side has died, even when there are zero callout transactions happening. the callout protocol MAY say that keep-alive messages get sent over the callout connections that already exist, OR over a separate connection between the OPES processor and the callout server. it MAY also say that using the keep-alive mechanism is optional 🌸

the detection of a callout server failure may let an OPES processor set up a callout connection with a stand-by callout server ✨ so future callout transactions don't end up losing application message data. and if an OPES processor fails, the callout server may be able to free up resources that would otherwise be stuck and unavailable for callout transactions with other OPES processors 💅

3.8. Operation in NAT Environments 🦋

the OPES protocol SHOULD be NAT-friendly, which just means its operation shouldn't get wrecked by one or more NAT devices sitting in the path between an OPES processor and a callout server 🧚

3.9. Multiple Callout Servers 👑

the OPES callout protocol MUST allow an OPES processor to talk to more than one callout server at the same time 🔥

in bigger networks, OPES services are probably going to be hosted on different callout servers 😭 so an OPES processor will likely have to chat with multiple callout servers. the protocol design MUST make it possible for an OPES processor to do that 💜

3.10. Multiple OPES Processors 🌈

the OPES callout protocol MUST allow a callout server to talk to more than one OPES processor at once ⭐

the protocol design MUST support a setup where multiple OPES processors are all using the services of one single callout server. iconic 🍓

3.11. Support for Different Application Protocols 🎀

the OPES callout protocol SHOULD be application protocol-agnostic, meaning it SHOULD not make any assumptions about what the application-layer protocol on the data path (between the data provider and the data consumer) is like 🙈 at the very least, the callout protocol MUST be compatible with HTTP [5] 💖

the OPES entities on the data path might use different application-layer protocols, including but not limited to HTTP [5] and RTP [8] 🦋 it would be super desirable to be able to use the same OPES callout protocol no matter which application-layer protocol is involved ✨

3.12. Capability and Parameter Negotiations 💅

the OPES callout protocol MUST support negotiating capabilities and callout connection parameters between an OPES processor and a callout server 🫶 which means the OPES processor and the callout server MUST be able to swap their capabilities and preferences. then they MUST be able to run a deterministic negotiation process, and it has to end with either both endpoints agreeing on the capabilities and parameters to use for future callout connections or transactions, OR with a determination that their capabilities are incompatible 😭

capabilities and parameters that could get negotiated between an OPES processor and a callout server include (but aren't limited to): callout protocol version, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters, etc. 🌸

the callout protocol MUST NOT use negotiation to figure out which transport protocol gets used for callout connections 🙅‍♀️ the callout protocol MAY, however, specify that a certain application message protocol (for example HTTP [5] or RTP [8]) requires the use of a certain transport protocol (for example TCP [6] or SCTP [7]) 💜

callout connection parameters might also be about the characteristics of OPES callout services, for example if callout connections are tied to one or more specific OPES services 🧚 an OPES service-specific parameter could, for example, say which parts of an application message an OPES service needs in order to do its thing 👑

callout connection parameters MUST be negotiated on a per-callout connection basis, and this has to happen before any callout transactions run over that callout connection ⭐ other parameters and capabilities, like the fail-over behavior, MAY be negotiated between the two endpoints independently of callout connections 🌈

the parties to a callout protocol MAY use callout connections to negotiate all or some of their capabilities and parameters 🎀 or, alternatively, a separate control connection MAY be used for this purpose 🦋

3.13. Meta Data and Instructions 🍓

the OPES callout protocol MUST provide a mechanism that lets the endpoints of a particular callout transaction include metadata and instructions for the OPES processor or the callout server in callout requests and responses 💖

specifically, the callout protocol MUST enable an OPES processor to include info about the forwarded application message in a callout request ✨ for example, to say what type of forwarded application message it is, or which part(s) of the application message get forwarded to the callout server 💅 likewise, the callout server MUST be able to include info about the returned application message 🫶

the OPES processor MUST further be able to include an ordered list of one or more uniquely specified OPES services that are to be performed on the forwarded application message, in the order listed 🔥 however, since the callout protocol MAY also choose to tie callout connections to specific OPES services, there might not be any need to identify OPES services on a per-callout-transaction basis 🙈

the OPES callout protocol MUST also allow the callout server to tell the OPES processor how cacheable the callout responses are 🌸 which means callout responses may have to carry cache-control instructions for the OPES processor 🧚

the OPES callout protocol MUST further enable the OPES processor to tell the callout server if it has kept a local copy of the forwarded application message (or parts of it) 💜 this helps the callout server figure out whether the forwarded application message has to be sent back to the OPES processor, even if no OPES service modified it ⭐

the OPES callout protocol MUST also allow OPES processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [3] 🌈 this means the callout protocol MUST enable a callout server to pass along to the OPES processor info about the OPES service operations performed on the forwarded application message 🎀

4. Performance Requirements 🏎️

4.1. Protocol Efficiency ⚡

the OPES callout protocol SHOULD have minimal latency 🦋 for example, the size and complexity of its headers could be kept as small as possible 🍓

because OPES callout transactions add latency to application protocol transactions on the data path, callout protocol efficiency is crucial to overall performance 💖

5. Security Requirements 🔐

in the absence of any security mechanisms, sensitive info might get communicated between the OPES processor and the callout server in a way that breaks either endpoint's security and privacy policy 😱 this could happen through misconfiguration or a deliberate insider attack 💀 by using strong authentication, message encryption, and integrity checks, this threat can be cut down to a smaller set of insiders and/or operator configuration errors ✨

the OPES processor and the callout servers SHOULD have enforceable policies that limit who they talk to, and that decide which protections to use based on the identities of the endpoints and other data (such as enduser policies) 👑 to enforce those policies, they MUST be able to authenticate the callout protocol endpoints using cryptographic methods 🔥

5.1. Authentication, Confidentiality, and Integrity 🛡️

the parties to the callout protocol MUST have a sound basis for binding authenticated identities to the protocol endpoints, and they MUST verify that these identities are consistent with their security policies 🫶

the OPES callout protocol MUST provide for message authentication, confidentiality, and integrity between the OPES processor and the callout server 💜 it MUST provide mutual authentication 🙌 for this purpose, the callout protocol SHOULD use existing security mechanisms 🧚 the callout protocol specification is not required to specify the security mechanisms, but it MAY instead refer to a lower-level security protocol and discuss how its mechanisms are to be used with the callout protocol 🌈

5.2. Hop-by-Hop Confidentiality 🔒

if hop-by-hop encryption is a requirement for the content path, then this confidentiality MUST be extended to the communication between the OPES processor and the callout server 💅 while it is recommended that the communication between the OPES processor and callout server always be encrypted, encryption MAY be optional if both the OPES processor and the callout server are co-located together in a single administrative domain with strong confidentiality guarantees 🍓

in order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream 🗝️✨

5.3. Operation Across Untrusted Domains 🌐

the OPES callout protocol MUST operate securely across untrusted domains between the OPES processor and the callout server 😤

if the communication channels between the OPES processor and callout server cross outside of the organization that's responsible for the OPES services, then endpoint authentication and message protection (confidentiality and integrity) MUST be used 🚨

5.4. Privacy 🙈

any communication carrying info relevant to privacy policies MUST protect the data using encryption 🫣

6. Security Considerations 🛡️

the security requirements for the OPES callout protocol are discussed in Section 5 💖

7. References 📚

7.1. Normative References

  • [1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
  • [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
  • [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

7.2. Informative References

  • [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
  • [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.

8. Acknowledgments 🫶

parts of this document are based on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon 🌸

the authors would like to thank the participants of the OPES WG for their comments on this document 💜

9. Authors' Addresses 💌

Here's how to reach the squad behind this one 🫶

Andre Beck
Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ  07733
US

EMail: abeck@bell-labs.com
Markus Hofmann
Lucent Technologies
Room 4F-513
101 Crawfords Corner Road
Holmdel, NJ  07733
US

Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman
Purple Streak Development

EMail: ho@alum.mit.edu
URI:   http://www.purplestreak.com
Reinaldo Penno
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US

EMail: rpenno@nortelnetworks.com
Andreas Terzis
Computer Science Department
Johns Hopkins University
3400 North Charles Street, 224 NEB
Baltimore, MD 21218

Phone: +1 410 516 5847
EMail: terzis@cs.jhu.edu

Okay, the legal bit, but make it cute 💅 Copyright belongs to The Internet Society (2004), and the usual rules apply. Here's the official wording, verbatim, because it matters 🫶

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.

That's a wrap on RFC 3836 🌈✨💖

📦 where this page comes from