An Architecture for Open Pluggable Edge Services (OPES)
RFC 3835

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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] document