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/