An Architecture for Open Pluggable Edge Services (OPES)
RFC 3835
Document | Type | RFC - Informational (August 2004; No errata) | |
---|---|---|---|
Authors | Hilarie Orman , Robin Chen , Reinaldo Penno , Markus Hofmann , Abbie Barbir | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3835 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ned Freed | ||
Send notices to | <mrose+mtr.ietf@dbc.mtview.ca.us> |
Network Working Group A. Barbir Request for Comments: 3835 R. Penno Category: Informational Nortel Networks R. Chen AT&T Labs M. Hofmann Bell Labs/Lucent Technologies H. Orman Purple Streak Development August 2004 An Architecture for Open Pluggable Edge Services (OPES) 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). Abstract This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. Barbir, et al. Informational [Page 1] RFC 3835 An Architecture for OPES August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 . The Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. OPES Entities. . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Data Dispatcher. . . . . . . . . . . . . . . . . 5 2.2. OPES Flows . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. OPES Rules . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Callout Servers. . . . . . . . . . . . . . . . . . . . . 7 2.5. Tracing Facility . . . . . . . . . . . . . . . . . . . . 8 3. Security and Privacy Considerations . . . . . . . . . . . . . 9 3.1. Trust Domains. . . . . . . . . . . . . . . . . . . . . . 9 3.2. Establishing Trust and Service Authorization . . . . . . 11 3.3. Callout Protocol . . . . . . . . . . . . . . . . . . . . 11 3.4. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. End-to-end Integrity . . . . . . . . . . . . . . . . . . 12 4. IAB Architectural and Policy Considerations for OPES . . . . . 12 4.1. IAB consideration (2.1) One-party Consent. . . . . . . . 12 4.2. IAB consideration (2.2) IP-Layer Communications. . . . . 13 4.3. IAB consideration (3.1 and 3.2) Notification . . . . . . 13 4.4. IAB consideration (3.3) Non-Blocking . . . . . . . . . . 13 4.5. IAB consideration (4.1) URI Resolution . . . . . . . . . 13 4.6. IAB consideration (4.2) Reference Validity . . . . . . . 13 4.7. IAB consideration (4.3) Application Addressing Extensions . . . . . . . . . . . . . . . . . . . . . . . 14 4.8. IAB consideration (5.1) Privacy. . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 1. Introduction When supplying a data stream service between a provider and a consumer, the need to provision the use of other application entities, in addition to the provider and consumer, may arise. For example, some party may wish to customize a data stream as a service to a consumer. The customization step might be based on the customer's resource availability (e.g., display capabilities). In some cases it may be beneficial to provide a customization service at a network location between the provider and consumer host rather than at one of these endpoints. For certain services performed on Barbir, et al. Informational [Page 2] RFC 3835 An Architecture for OPES August 2004 behalf of the end-user, this may be the only option of service deployment. In this case, zero or more additional application entities may participate in the data stream service. There are many possible provisioning scenarios which make a data stream service attractive. The OPES Use Cases and Deployment Scenarios [1] documentShow full document text