Open Pluggable Edge Services (OPES) Entities and End Points Communication
RFC 3897

Document Type RFC - Informational (September 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3897 (Informational)
Telechat date
Responsible AD Ted Hardie
Send notices to <abbieb@nortelnetworks.com>
Network Working Group                                          A. Barbir
Request for Comments: 3897                               Nortel Networks
Category: Informational                                   September 2004

             Open Pluggable Edge Services (OPES) Entities
                      and End Points Communication

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 documents tracing and non-blocking (bypass) requirements
   for Open Pluggable Edge Services (OPES).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  2
   2.  OPES System  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Tracing Requirements . . . . . . . . . . . . . . . . . . . . .  3
       3.1.  Traceable entities . . . . . . . . . . . . . . . . . . .  3
       3.2.  System requirements  . . . . . . . . . . . . . . . . . .  5
       3.3.  Processor requirements . . . . . . . . . . . . . . . . .  5
       3.4.  Callout server requirements  . . . . . . . . . . . . . .  5
   4.  Bypass (Non-blocking feature) Requirements . . . . . . . . . .  6
       4.1.  Bypassable entities  . . . . . . . . . . . . . . . . . .  7
       4.2.  System requirements  . . . . . . . . . . . . . . . . . .  8
       4.3.  Processor requirements . . . . . . . . . . . . . . . . .  8
       4.4.  Callout server requirements  . . . . . . . . . . . . . .  9
   5.  Protocol Binding . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Compliance Considerations  . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
       8.1.  Tracing security considerations  . . . . . . . . . . . . 10
       8.2.  Bypass security considerations . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 12
       9.2.  Informative References . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

Barbir                       Informational                      [Page 1]
RFC 3897        OPES Entities & End Points Communication  September 2004

   11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
   12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14

1.  Introduction

   The Open Pluggable Edge Services (OPES) architecture [1] 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.

   This work specifies OPES tracing and bypass functionality.  The
   architecture document [1] requires that tracing is supported in-band.
   This design goal limits the type of application protocols that OPES
   can support.  The details of what a trace record can convey are also
   dependent on the choice of the application level protocol.  For these
   reasons, this work only documents requirements for OPES entities that
   are needed to support traces and bypass functionality.  The task of
   encoding tracing and bypass features is application protocol
   specific.  Separate documents will address HTTP and other protocols.

   The architecture does not prevent implementers from developing out-
   of-band protocols and techniques to address tracing and bypass.  Such
   protocols are out of scope of the current work.

1.1.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [2].
   When used with the normative meanings, these keywords will be all
   uppercase.  Occurrences of these words in lowercase comprise normal
   prose usage, with no normative implications.

2.  OPES System

   This section provides a definition of OPES System.  This is needed in
   order to define what is traceable (or bypassable) in an OPES Flow.

   Definition: An OPES System is a set of all OPES entities authorized
   by either the data provider or the data consumer application to
   process a given application message.
Show full document text