draft-ietf-opes-architecture-01.txt   draft-ietf-opes-architecture-02.txt 
Network Working Group Abbie. Barbir Network Working Group Abbie. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: December 10, 2002 R. Chen Expires: December 18, 2002 R. Chen
AT&T Labs AT&T Labs
M. Hofmann M. Hofmann
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
H. Orman H. Orman
The Purple Streak Development Purple Streak Development
R. Penno R. Penno
Nortel Networks Nortel Networks
G. Tomlinson G. Tomlinson
Cacheflow The Tomlinson Group
June 11, 2002 June 19, 2002
An Architecture for Open Pluggable Edge Services (OPES) An Architecture for Open Pluggable Edge Services (OPES)
draft-ietf-opes-architecture-01 draft-ietf-opes-architecture-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2002. This Internet-Draft will expire on December 18, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This memo defines an architecture for a cooperative application This memo defines an architecture for a cooperative application
service in which a data provider, a data consumer, and zero or more service in which a data provider, a data consumer, and zero or more
application entities cooperatively realize a data stream service. application entities cooperatively realize a data stream service.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . 4
2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 5
2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 10
3. Security and Privacy Considerations . . . . . . . . . . . . . 11 3. Security and Privacy Considerations . . . . . . . . . . . . 12
3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 13
3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 13 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 14
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
When realizing a data stream service between a provider and a When realizing a data stream service between a provider and a
consumer, the need may arise to provision the use of other consumer, the need may arise to provision the use of other
application entities, in addition to the provider and consumer. For application entities, in addition to the provider and consumer. For
example, some party may wish to customize a data stream as a service example, some party may wish to customize a data stream as a service
to a consumer, e.g., a service might customize the data based on the to a consumer. The customization step might be based on the
customer's geographical locality (e.g., language) or resource customer's geographical locality (e.g., language) or resource
availability (e.g., display capabilities). availability (e.g., display capabilities).
In some cases in may be beneficial to provide a customization service In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment. In this case, one this may be the only option of service deployment. In this case, one
or more additional application entities may participate in the data or more additional application entities may participate in the data
stream service. There are many possible provisioning scenarios which stream service. There are many possible provisioning scenarios which
make a data stream service attractive. The reader is referred to [1] make a data stream service attractive. In [1] a description of
for a description of several scenarios. several scenarios is provided.
The document presents the architectural components of Open Pluggable This document presents the architectural components of Open Pluggable
Edge Services (OPES) that are needed in order to perform a data Edge Services (OPES) that are needed in order to perform a data
stream service. The architecture addresses the IAB considerations stream service. The architecture addresses the IAB considerations
described in [2]. These considerations are covered in the various described in [2]. These considerations are covered in the various
parts of the document, specifically with respect to tracing (Section parts of the document, specifically with respect to tracing (Section
2.6) and security considerations (Section 3). 2.5) and security considerations (Section 3).
The document is organized as follows: Section 2 introduces the OPES The document is organized as follows: Section 2 introduces the OPES
architecture. Section 3 discusses security considerations. Section architecture. Section 3 discusses security considerations. Section
4 provides a summary of the architecture and the requirements for 4 provides a summary of the architecture and the requirements for
interoperability. interoperability.
2. The Architecture 2. The Architecture
The architecture of Open Pluggable Edge Services (OPES) can be The architecture of Open Pluggable Edge Services (OPES) can be
described in terms of three interrelated concepts, mainly: described in terms of three interrelated concepts, mainly:
o OPES entities: processes operating in the network; o OPES entities: processes operating in the network;
o OPES flows: data flows that are cooperatively realized by the o OPES flows: data flows that are cooperatively realized by the
OPES entities; and, OPES entities; and,
o OPES rules: these determine how a given data flow is modified by o OPES rules: these specify when and how to execute OPES
an OPES entity. intermediary services.
2.1 OPES Entities 2.1 OPES Entities
An OPES entity is an application that operates on a data flow between An OPES entity is an application that operates on a data flow between
a data provider application and a data consumer application. OPES a data provider application and a data consumer application. OPES
entities can be one of the following: entities can be one of the following:
o an OPES service application, which analyzes and possibly o an OPES service application, which analyzes and possibly
transforms messages exchanged between the data provider transforms messages exchanged between the data provider
application and the data consumer application; or, application and the data consumer application; or,
skipping to change at page 5, line 33 skipping to change at page 5, line 33
+-------------+ +-------------+
Figure 1: OPES Logical Implementation Figure 1: OPES Logical Implementation
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 1 depicts a "minimal" stack for OPES. However, other Figure 1 depicts a "minimal" stack for OPES. However, other
protocols may be present, depending on the functions that are protocols may be present, depending on the functions that are
performed by the application. performed by the application.
2.1.1 Data Dispatcher
Data dispatchers include a ruleset that can be compiled from several
sources and must resolve into an unambiguous result. The compiled
ruleset enables an OPES processor to determine which service
applications to invoke for which data flow. Accordingly, the data
dispatcher constitutes an enhanced policy enforcement point, where
policy rules are evaluated, service-specific data handlers and state
information is maintained, as depicted in Figure 2.
---------------------------------------------------------------------
+----------+
| callout |
| server |
+----------+
||
||
||
||
+--------------------------+
| +----------+ || |
| | OPES | || |
| | service | || |
| | appl | || |
| +----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | |
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
Figure 2: Data Dispatchers
---------------------------------------------------------------------
The architecture allows more than one policy enforcement point to be
present on an OPES flow.
2.2 OPES Flows 2.2 OPES Flows
An OPES flow is a cooperative undertaking between a data provider An OPES flow is a cooperative undertaking between a data provider
application, a data consumer application, zero or more OPES service application, a data consumer application, zero or more OPES service
applications, and zero or more data dispatchers. applications, and zero or more data dispatchers.
In order to understand the trust relationships between OPES entities, In order to understand the trust relationships between OPES entities,
each is labeled as residing in an administrative domain. Entities each is labeled as residing in an administrative domain. Entities
associated with a given OPES flow may reside in one or more associated with a given OPES flow may reside in one or more
administrative domains. administrative domains.
skipping to change at page 6, line 30 skipping to change at page 7, line 30
| | | | | | | | | | | | | | | | | | | | | | | |
| +----------+ +--------+ | | +--------+ +----------+ | | +----------+ +--------+ | | +--------+ +----------+ |
| | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | |
| +----------+ +--------+ | | +--------+ +----------+ | | +----------+ +--------+ | | +--------+ +----------+ |
| || || || | | || || || | | || || || | | || || || |
| ============= ================= ============= | | ============= ================= ============= |
| | | | | | | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
| <----------------- OPES flow -----------------> | | <----------------- OPES flow -----------------> |
Figure 2: An OPES flow Figure 3: An OPES flow
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 2 depicts two data dispatchers that are present in the OPES Figure 3 depicts two data dispatchers that are present in the OPES
flow. However, the architecture allows for zero or more data flow. However, the architecture allows for zero or more data
dispatchers to be present in any flow. dispatchers to be present in any flow.
2.3 OPES Rules 2.3 OPES Rules
OPES policy regarding services and the data provided to them is OPES policy regarding services and the data provided to them is
determined by a ruleset consisting of OPES rules. The rules consist determined by a ruleset consisting of OPES rules. The rules consist
of a set of conditions and related actions. The ruleset is the of a set of conditions and related actions. The ruleset is the
superset of all OPES rules on the processor. The OPES ruleset superset of all OPES rules on the processor. The OPES ruleset
determines which service applications will operate on a data stream. determines which service applications will operate on a data stream.
skipping to change at page 7, line 21 skipping to change at page 8, line 21
2.4 Callout Servers 2.4 Callout Servers
The evaluation of OPES ruleset determines which service applications The evaluation of OPES ruleset determines which service applications
will operate on a data stream. How the ruleset is evaluated is not will operate on a data stream. How the ruleset is evaluated is not
the subject of the architecture, except to note that it must result the subject of the architecture, except to note that it must result
in the same unambiguous result in all implementations. in the same unambiguous result in all implementations.
In some cases it may be useful for the OPES processor to distribute In some cases it may be useful for the OPES processor to distribute
the responsibility of service evaluation by communicating with one or the responsibility of service evaluation by communicating with one or
more callout servers (cf., [7]). The situation is illustrated in more callout servers (cf., [7]). The situation is illustrated in
Figure 3, which shows a data dispatcher communicating with multiple Figure 4, which shows a data dispatcher communicating with multiple
callout servers as it processes an OPES flow. callout servers as it processes an OPES flow.
--------------------------------------------------------------------- ---------------------------------------------------------------------
data callout callout callout data callout callout callout
dispatcher server server server dispatcher server server server
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
| | | | | | | | | | | | | | | |
| OCP | | OCP | | OCP | ... | OCP | | OCP | | OCP | | OCP | ... | OCP |
| | | | | | | | | | | | | | | |
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
| TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | | Lower | | Lower | | Lower | | Lower |
| Layer | | Layer | | Layer | | Layer |
|Protocols | |Protocols| |Protocols| |Protocols|
| . | | . | | . | | . |
| . | | . | | . | | . |
+----------+ +---------+ +---------+ +---------+ +----------+ +---------+ +---------+ +---------+
|| || || || || || || ||
||================ || ... || ||================ || ... ||
|| || || || || ||
||============================== || ||============================== ||
|| || || ||
================================================ ================================================
Figure 3: An OPES flow with Callout servers Figure 4: An OPES flow with Callout servers
--------------------------------------------------------------------- ---------------------------------------------------------------------
In Figure 3, a data dispatcher invokes the services of a callout In Figure 4, a data dispatcher invokes the services of a callout
server by using the OPES callout protocol (OCP). The requirements server by using the OPES callout protocol (OCP). The requirements
for the OCP are given in [7]. The OCP is application-agnostic, being for the OCP are given in [7]. The OCP is application-agnostic, being
unaware of the semantics of the encapsulated application protocol unaware of the semantics of the encapsulated application protocol
(e.g., HTTP). However, the OCP must incorporate a service aware (e.g., HTTP). However, the OCP must incorporate a service aware
vectoring capability that parses the data flow according to the vectoring capability that parses the data flow according to the
ruleset and delivers the data to the OPES service application that ruleset and delivers the data to the OPES service application that
can be local or remote. can be local or remote.
In this model, OPES applications may be executed either on the same In this model, OPES applications may be executed either on the same
processor (or even in the same application environment) with the processor (or even in the same application environment) with the
dispatcher or on a different OPES processor through OCP. The general dispatcher or on a different OPES processor through OCP. The general
interaction situation is depicted in Figure 4, which illustrates the interaction situation is depicted in Figure 5, which illustrates the
positions and interaction of different components of OPES positions and interaction of different components of OPES
architecture. architecture.
--------------------------------------------------------------------- ---------------------------------------------------------------------
+--------------------------+ +--------------------------+
| +----------+ | | +----------+ |
| | OPES | | | | OPES | |
| | service | | +----------------+ | | service | | +----------------+
| | appl | | | Callout Server | | | appl | | | Callout Server |
skipping to change at page 8, line 37 skipping to change at page 10, line 25
| | data dispatcher | | | | Service| | | | data dispatcher | | | | Service| |
| +----------------------+ | | | App2 | | | +----------------------+ | | | App2 | |
| | HTTP | OCP | | | +--------+ | | | HTTP | OCP | | | +--------+ |
| +------------| |==========| OCP | | | +------------| |==========| OCP | |
| | |---------+ | | +--------+ | | | |---------+ | | +--------+ |
| | TCP/IP | | +----------------+ | | TCP/IP | | +----------------+
=========| |=============== OPES Data Flow ==== =========| |=============== OPES Data Flow ====
| +------------+ | | +------------+ |
+--------------------------+ +--------------------------+
Figure 4: Interaction of OPES Entities Figure 5: Interaction of OPES Entities
---------------------------------------------------------------------
2.5 Policy Enforcement
Data dispatchers include a ruleset that can be compiled from several
sources and must resolve into an unambiguous result. The compiled
ruleset enables an OPES processor to determain which service
applications to invoke for which data flow. Accordingly, the data
dispatcher constitutes an enhanced Policy Enforcement Point (PEP),
where policy rules are evaluated, service-specific data handlers and
state information are maintained, as depicted in Figure 5.
---------------------------------------------------------------------
+----------+
| callout |
| server |
+----------+
||
||
||
||
+---------------------------+
| +----------+ || |
| | OPES | || |
| | service | || |
| | appl | || |
| +----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
Figure 5: Data Dispatchers and Policy Enforcement Point
--------------------------------------------------------------------- ---------------------------------------------------------------------
The architecture allows more than one PEP to be present on an OPES 2.5 Tracing Facility
flow.
2.6 Tracing Facility
The architecture makes no requirements as to how an OPES flow is
negotiated, provided that it is consistent with the security policy
(Section 3) of each administrative domain that hosts the OPES
entities that are associated with the flow.
The OPES architecture requires that each data dispatcher provides The OPES architecture requires that each data dispatcher to provide
tracing facilities that allow the appropriate verification of its tracing facilities that allow the appropriate verification of its
operation. The OPES architecture requires that tracing be feasible operation. The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation. One on the OPES flow per OPES processor using in-band annotation. One
of those annotations could be a URL with more detailed information on of those annotations could be a URL with more detailed information on
the transformation that occurred to the data on the OPES flow. the transformation that occurred to the data on the OPES flow.
Future revisions of the architecture may provide for a tracing
facility to be used for subsequent out-of-band analysis.
Providing the ability for in-band annotation MAY require header Providing the ability for in-band annotation MAY require header
extensions on the application protocol that is used (e.g., HTTP). extensions on the application protocol that is used (e.g., HTTP).
However, the presence of an OPES processor in the data request/ However, the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers. OPES processors, content server and aware clients and servers. OPES processors, content server and
content consumer MAY use OPES extensions to the base protocol (HTTP), content consumer MAY use OPES extensions to the base protocol (HTTP),
but support of these extensions SHALL NOT be required. but support of these extensions SHALL NOT be required.
OPES processors must obey tracing, reporting and notification OPES processors must obey tracing, reporting and notification
requirements set by the center of authority in the trust domain to requirements set by the center of authority in the trust domain to
skipping to change at page 15, line 29 skipping to change at page 16, line 29
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[5] OPES working group, "OPES Service Authorization and Enforcement [5] OPES working group, "OPES Service Authorization and Enforcement
Requirements", Internet-Draft TBD, May 2002. Requirements", Internet-Draft TBD, May 2002.
[6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
May 2002. May 2002.
[7] OPES working group, "OPES Callout Protocol and Tracing Protocol [7] A. Beck et al., "Requirements for OPES Callout Protocols",
Requirements", Internet-Draft TBD, May 2002. Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-
opes-protocol-reqs-00.txt, May 2002.
Authors' Addresses Authors' Addresses
Abbie Barbir Abbie Barbir
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Nepean, Ontario K2H 8E9 Nepean, Ontario K2H 8E9
Canada Canada
Phone: +1 613 763 5229 Phone: +1 613 763 5229
skipping to change at page 16, line 15 skipping to change at page 17, line 24
Bell Labs/Lucent Technologies Bell Labs/Lucent Technologies
Room 4F-513 Room 4F-513
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
US US
Phone: +1 732 332 5983 Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com EMail: hofmann@bell-labs.com
Hilarie Orman Hilarie Orman
The Purple Streak Development Purple Streak Development
EMail: ho@alum.mit.edu EMail: ho@alum.mit.edu
Reinaldo Penno Reinaldo Penno
Nortel Networks Nortel Networks
2305 Mission College Boulevard 4555 Great America Parkway
San Jose, CA 95134 Santa Clara, CA 95054
US US
EMail: rpenno@nortelnetworks.com EMail: rpenno@nortelnetworks.com
Gary Tomlinson Gary Tomlinson
Cacheflow The Tomlinson Group
EMail: gary@tomlinsongroup.net EMail: gary@tomlinsongroup.net
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors gratefully acknowledge the contributions of: Marshall T. The authors gratefully acknowledge the contributions of: Marshall T.
Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper. Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.
Full Copyright Statement Full Copyright Statement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/