draft-ietf-opes-end-comm-02.txt   draft-ietf-opes-end-comm-03.txt 
Network Working Group A. Barbir Network Working Group A. Barbir
Internet-Draft Nortel Networks Internet-Draft Nortel Networks
Expires: March 18, 2004 September 18, 2003 Expires: April 3, 2004 October 4, 2003
OPES processor and end points communications OPES processor and end points communications
draft-ietf-opes-end-comm-02 draft-ietf-opes-end-comm-03
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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 March 18, 2004. This Internet-Draft will expire on April 3, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo documents tracing requirements for Open Pluggable Edge This memo documents tracing and non-blocking requirements for Open
Services (OPES). Pluggable Edge Services (OPES).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES Domain and OPES System . . . . . . . . . . . . . . . . 4 2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. OPES Tracing . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements for OPES Tracing . . . . . . . . . . . . . . . . 5
3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . 6 3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . . . 5
3.2 Requirements for Information Related to Traceable 3.2 Requirements for Information Related to Traceable Entities . . 6
Entities? . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Requirements for OPES processors . . . . . . . . . . . . . . . 7
4. Requirements for OPES processors . . . . . . . . . . . . . . 8 3.4 Requirements for callout servers . . . . . . . . . . . . . . . 7
5. Requirements for callout servers . . . . . . . . . . . . . . 9 3.5 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 8
6. Privacy considerations . . . . . . . . . . . . . . . . . . . 10 4. Non-Blocking . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Tracing and Trust Domains . . . . . . . . . . . . . . . . . 10 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
7. How to Support Tracing . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1 Tracing and OPES System Granularity . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . . 14
7.2 Requirements for In-Band Tracing . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 15
7.2.1 Tracing Information Granularity and Persistence levels Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7.3 Protocol Binding . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 17
8. Tracing Examples . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Single OPES Processor: Detailed Trace . . . . . . . . . . . 14
8.2 Single OPES Processor: Partial Trace . . . . . . . . . . . . 15
8.3 Multiple OPES Processors: Full Trace . . . . . . . . . . . . 15
8.4 Multiple OPES Processors: Partial Trace . . . . . . . . . . 16
9. Optional Notification . . . . . . . . . . . . . . . . . . . 18
10. IANA considerations . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . 22
Informative References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 23
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . 25
1. Introduction 1. Introduction
The Open Pluggable Edge Services (OPES) architecture [8] enables The Open Pluggable Edge Services (OPES) architecture [8] enables
cooperative application services (OPES services) between a data cooperative application services (OPES services) between a data
provider, a data consumer, and zero or more OPES processors. The provider, a data consumer, and zero or more OPES processors. The
application services under consideration analyze and possibly application services under consideration analyze and possibly
transform application-level messages exchanged between the data transform application-level messages exchanged between the data
provider and the data consumer. provider and the data consumer.
The execution of such services is governed by a set of rules This work specify the requirements for providing tracing
installed on the OPES processor. The rules enforcement can trigger functionality for the OPES architecture [8]. Tracing functionality
the execution of service applications local to the OPES processor. enables a data provider application to detect inappropriate actions
Alternatively, the OPES processor can distribute the responsibility that are performed by OPES entities. The work also develops
of service execution by communicating and collaborating with one or requirements that can be used to fulfill IAB Notification and
more remote callout servers. As described in [8], an OPES processor Non-Blocking requirements [2].
communicates with and invokes services on a callout server by using a
callout protocol.
The work specify the requirements for providing tracing functionality
for the OPES architecture [8]. This document specifies tracing
mechanisms that the OPES architecture could provide that enable data
provider application to detect inappropriate client centric actions
by OPES entities. The work focus on developing tracing requirements
that can be used to fulfill the notification and Non-Blocking
requirements [2].
In the OPES architecture document [8], there is a requirement of
relaying tracing information in-band. This work investigates this
possibility and discusses possible methods that could be used to
detect faulty OPES processors or callout servers by end points in an
OPES flow.
The document is organized as follows: Section 2 defines OPES Domain
and OPES System. Section 3 discusses entities that are traceable in
an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES
systems and callout servers. Section 6 focus on Tracing and Trust
Domains. Section 7 discusses how to support tracing and provides uses
cases. Section 8 provides some examples of traces. Section 9 examines
Optional Notification. Section 9 looks into IANA considerations.
Section 10 examines security considerations.
2. OPES Domain and OPES System
This sections clarifies the terms OPES system and OPES Domain [8].
These terms are needed in order to define what is traceable in an
OPES Flow [8].
An OPES domain describes the collection of OPES entities that a The architecture document requires [8] that tracing be supported
single provider operates. OPES domains can be based on trust or other in-band. This design goal limits the type of application protocols
operational boundaries. All entities of an "OPES Domain" MUST be in that OPES can support. The details of what a trace record can convey
the same trust domain. This would be independent of any specific OPES is also dependent on the choice of the application level protocol.
Flow.
An OPES system consists of a limited set of OPES entities, parts of a For these reasons, this work documents requirements for application
single or of multiple OPES domains, organized by (or on behalf) of protocols that need to support OPES traces and non-blocking. However,
either a data provider application or a data consumer application to the architecture does not prevent implementers of developing
perform authorized services on a given application message. Each OPES out-of-band protocols and techniques to address these limitation.
entity in an OPES system MUST be directly addressable at the IP level
by a data consumer application.
An OPES system can be formed in a recursive manner. An OPES system 2. OPES System
can start with either a data provider application or a data consumer
application (for a given message). The OPES system then includes any
OPES entity trusted by (accepting authority from) an entity that is
already in the OPES system. The trust and authority delegation is
viewed in the context of the given application message.
As implied by the above definition, some OPES entities in the system This sections provides a definition of OPES System. This is needed in
MAY not participate in the processing of a given message. order to define what is traceable in an OPES Flow.
An OPES domain MUST not be an OPES sub-system. An OPES domain MUST Definition: An OPES System is a set of all OPES entities authorized
require external resources to provide services. An OPES domain is a by either the data provider or the data consumer application to
part of an OPES system belonging to a given operator. OPES domains process a given application message.
have no incidence on the structure of an OPES system, but they may
influence its organization for different reasons such as security,
payment, quality of service, delivery parameters among others.
In Figure 1 an OPES Flow is shown that traverses across various OPES The nature of the authorization agreement determines if authority
Domains starting from a data provider application. A data consumer delegation is transitive (meaning an authorized entities is
application MUST be able to receive tracing information on per authorized to include other entities). Transitive authority
message basis that enable it to determine the set of transformations delegation is common in information systems.
that were performed on the data for a particular OPES Flow. The
formation of an OPES Flow can be static or dynamic, meaning that the
determination of which OPES Domains will participate in a given OPES
Flow (per message basis) can be a function of business arrangements.
+------------------------------------------+ If specific authority agreements allow for re-delegation, an OPES
| Data Consumer Application | system can be formed by induction. In this case, an OPES system
+------------------------------------------+ starts with entities directly authorized by a data provider (or a
^ data consumer) application. The OPES system then includes any OPES
| entity authorized by an entity that is already in the OPES system.
+-------------------------------------------+ The authority delegation is always viewed in the context of a given
| OPES System | O | application message.
| | |
| +-------------------------+ | P |
| | OPES Domain | | |
| | +---------------+ | | E |
| | | OPES Entity | | | |
| | +---------------+ | | S |
| | . | | |
| | . | | |
| | +---------------+ | | F |
| | |Callout Server | | | |
| | +---------------+ | | L |
| | | | |
| +-------------------------+ | O |
| . | |
| . | W |
| +-------------------------+ | |
| | OPES Domain | | |
| | +---------------+ | | |
| | | OPES Entity | | | |
| | +---------------+ | | |
| | . | | |
| | . | | |
| | +---------------+ | | |
| | | OPES Entity | | | |
| | +---------------+ | | |
| +-------------------------+ | |
| v |
| +-----------------------------------+ |
| | Data Provider Application | |
| +-----------------------------------+ |
| |
+-------------------------------------------+
Figure 1: OPES System An OPES System is defined on an application message basis. Having an
authority to process a message does not imply being involved in
message processing. Thus, some OPES system members may not
participate in processing of a message. Similarly, some members may
process the same message several times.
3. OPES Tracing The above definition implies that there can be no more than one OPES
system processing a single message at a given time. This is based on
the assumption that there is a single data provider and a single data
consumer as far as a given application message is concerned.
Before discussing what is traceable in an OPES flow, it is beneficial For example, consider a Content Delivery Network (CDN) delivering an
to define what tracing means. Tracing is defined as the inclusion of image on behalf of a busy web site. OPES processors and services that
necessary information within a message in an OPES flow that could be the CDN uses to adapt and deliver the message comprise an OPES
used to identify the set of transformations or adaptations that have system. In a more complex example, an OPES System would contain CDN
been performed on its content in an OPES System before its delivery entries as well as 3rd-party OPES entities that CDN engages to
to an end point (for example, the data consumer application). perform adaptations (e.g., to adjust image quality).
o OPES trace: application message information about OPES entities in 3. Requirements for OPES Tracing
an OPES System that adapted that message.
o OPES tracing: the process of including, manipulating, and In an OPES System tracing is defined as the inclusion of necessary
interpreting an OPES trace in an OPES System. information within a message in an OPES Flow that identify the set of
transformations or adaptations that have been performed on it before
its delivery to an end point (for example, the data consumer
application). An OPES trace represents a snap shot of the tracing
information that have been added to a given application message.
To emphasize, the above definition means that OPES tracing SHOULD be In an OPES System tracing is performed on per message basis. Trace
performed on per message basis. Trace format is dependent on the format is dependent on the application protocol that is being adapted
application protocol that is being adapted by OPES. Data consumer by OPES. A Data consumer application can use OPES trace to infer the
application can use OPES trace to infer the actions that have been actions that have been performed by the OPES system. Actions are the
performed by the OPES system. The architecture document requires [8] set of authorized OPES services that were performed by OPES entities
that tracing be supported in-band. in an OPES System.
In an OPES System the task of providing tracing information, must Providing tracing information, MUST take into account the following
take into account the following considerations: considerations:
o Providers may be hesitant to reveal information about their o Providers may be hesitant to reveal information about their
internal network infrastructure. internal network infrastructure.
o Within a service provider network, OPES processors may be o Within a service provider network, OPES processors may be
configured to use non-routable, private IP addresses. configured to use non-routable, private IP addresses.
o A Data consumer applications would prefer to have a single point o A Data consumer applications would prefer to have a single point
of contact regarding the trace information. of contact regarding the trace information.
3.1 What is traceable in an OPES Flow? 3.1 What is traceable in an OPES Flow?
This section focuses on identifying the traceable entities in an OPES This section focuses on identifying traceable entities in an OPES
Flow. Tracing information MUST be able to provide a data consumer Flow.
application with useful information without tracing the exact OPES
Processor or callout servers that adapted the data. It is up to the Tracing information provides a data consumer application (or a data
OPES service provider to have maintained appropriate internal provider application) with useful information without tracing the
detailed traces to find the answer to the data consumer applications exact OPES Processor or callout servers that adapted the data. For
inquiry. example, some OPES services are message-agnostic and operate on
message content or parts of a message. Such services cannot
manipulate message headers. Hence, a data consumer application would
be interested in knowing that a translation service on the message
content was performed. It does not need to know the exact entity that
has performed the service.
There are two distinct uses of OPES traces. First, a trace enables an
"end (content provider or consumer) to detect the presence of OPES
processors within an OPES System. Such "end" should be able to see a
trace entry, but does not need to be able to interpret it beyond
identification of the OPES System.
Second, the OPES System administrator is expected to be able to
interpret the contents of an OPES trace. The trace can be provided by
an end (data consumer or provider) as an opaque string. The
administrator can use the trace information to identify the
participating OPES processor(s). The administrator can use the trace
to identify the applied adaptation services along with other
message-specific information.
Since the administrators of various OPES Systems can have various
ways of looking into tracing, they MAY require the choice of freedom
in what to put in trace records and how to format them. Trace records
should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to
the extent possible.
At the implementation level, for a given trace, an OPES entity At the implementation level, for a given trace, an OPES entity
involved in handling the corresponding application message is involved in handling the corresponding application message is
"traceable" or "traced" if information about it appears in that traceable or traced if information about it appears in that trace.
trace. OPES entities have different levels of traceability OPES entities have different levels of traceability requirements.
requirements. Specifically, Specifically,
o An OPES system MUST add its entry to the trace. o An OPES system MUST add its entry to the trace.
o An OPES processor SHOULD add its entry to the trace. o An OPES processor SHOULD add its entry to the trace.
o An OPES service SHOULD add its entry to the trace. o An OPES service May add its entry to the trace.
o An OPES entity MAY manage trace information from entities that are o An OPES entity MAY manage trace information from entities that are
under its control. For example, an OPES processor may add or under its control. For example, an OPES processor may add or
remove callout service entries in order to manage the size of a remove callout service entries in order to manage the size of a
trace. Other considerations include: trace.
* The OPES processor MAY have a fixed configuration that enable
it to respond to tracing inquires.
* The OPES processor MAY insert a summary of the services that it
controls. The summary can be used to respond to tracing
inquiries.
* The OPES processor MAY package tracing information related to
the entities that it control based on the policy of a given
OPES System.
From an OPES context, a good tracing approach is similar to a trouble From an OPES context, a good tracing approach is similar to a trouble
ticket ready for submission to a known address. The trace in itself ticket ready for submission to a known address. The address is
is not necessarily a detailed description of what has happened. It is printed on the ticket. The trace in itself is not necessarily a
the responsibility of the operator to resolve the problems. detailed description of what has happened. It is the responsibility
of the operator to resolve the problems.
3.2 Requirements for Information Related to Traceable Entities? 3.2 Requirements for Information Related to Traceable Entities
The requirements for information as related to entities that are The following MUST requirements apply for information as related to
traceable in an OPES flow are: entities that are traceable in an OPES flow:
o The privacy policy at the time it dealt with the message o Identification of the OPES System privacy policy at the time it
dealt with the message.
o Identification of the party responsible for setting and enforcing o Identification of the party responsible for setting and enforcing
that policy that policy.
o Information pointing to a technical contact o Information pointing to a technical contact.
o Information that identifies, to the technical contact, the OPES o Information that identifies, to the technical contact, the OPES
processors involved in processing the message. processors involved in processing the message.
4. Requirements for OPES processors 3.3 Requirements for OPES processors
In order to facilitate compliance, the concept of an "OPES system"
being traceable, requires that each OPES processor MUST support
tracing. Policy can be set that defines which domain has
authorization to turn on tracing and its granularity. An OPES
provider can have its private policy for trace information, but it
MUST support tracing mechanisms and it MUST reveal its policy.
The requirements for OPES processors that are applicable to tracing The requirements for OPES processors that are applicable to tracing
are: are:
o Each OPES processor MUST belong to a single OPES Domain. o Each OPES processor MUST be uniquely identified in an OPES System.
o Each OPES processor MUST have a Unique Identity in that Domain.
o Each OPES processor MUST support tracing, policy can be used to o Each OPES processor MUST support tracing, policy can be used to
turn tracing on and to determine its granularity. turn tracing on and to determine its granularity.
5. Requirements for callout servers o If tracing is turned on, then the OPES processor MUST add its
identification to the trace.
In an OPES system, it is the task of an OPES processor to add trace
records to application messages. In this case, the callout servers
that uses the OCP protocol [5] are not affected by tracing
requirements. In order for an OCP protocol to be tracing neutral, an
OPES processor in an OPES system MUST be able to meet the following
requirements:
o Callout services adapt payload regardless of the application
protocol in use and leave header adjustment to OPES processor.
o OPES processor SHOULD be able to trace it's own invocation and o OPES processor SHOULD be able to trace it's own invocation and
service(s) execution since they understand the application service(s) execution since it understands the application
protocol. protocol. To fulfill this:
o Callout servers MAY be able to add their own OPES trace records
to application level messages.
6. Privacy considerations
6.1 Tracing and Trust Domains
A trust domain may include several OPES systems and entities. Within
a trust domain, there MUST be at least support for one trace entry
per OPES system. Entities outside of that system may or may not see
any traces, depending on domain policies or configuration. For
example, if an OPES system is on the content provider "side",
end-users are not guaranteed any traces. If an OPES system is working
inside end-user domain, the origin server is not guaranteed any
traces related to user requests.
7. How to Support Tracing
In order to support tracing, the following aspects must be addressed:
o There MUST be a System Identifier that identify a domain that is
employing an OPES system.
o An OPES processor MUST be able to be uniquely identified (MUST * An OPES processor MAY have a fixed configuration that enable it
have an Identifier) within a system. to respond to tracing inquires. For example, entity X performs
service Y and so on.
o An OPES processor SHOULD add its identification to the trace. * An OPES processor MAY package tracing information related to
the entities that it control based on the policy of a given
OPES System. For example, the trace may state that service W
was performed. The OPES processor knows that service W is
composed of services X, Y and Z in a given order
o An OPES processor SHOULD add to the trace identification of every o An OPES processor SHOULD add to the trace identification of every
callout service that received the application message. callout service that processed the application message.
o If the policy in an OPES system requires an OPES processor to turn
tracing on, then the OPES processor MUST add to the trace
identification of the "system or entity" it belongs to. "System"
ID MUST make it possible to access "system" privacy policy.
o An OPES processor MAY group the above information for sequential
trace entries having the same "system/entity" ID. In other words,
trace entries produced within the same "system or entity" MAY be
merged or aggregated into a single less detailed trace entry.
o An OPES processor MAY delegate trace management to a callout o An OPES processor MAY delegate trace management to a callout
service within the same "system or entity". service within the same OPES System.
7.1 Tracing and OPES System Granularity
There are two distinct uses of traces. First, a trace SHOULD enable
the "end (content producer or consumer) to detect OPES processor
presence within end's trust domain. Such "end" should be able to see
a trace entry, but does not need to be able to interpret it beyond
identification of the trust domain(s).
Second, the domain administrator SHOULD be able to take a trace entry
(possibly supplied by an "end? as an opaque string) and interpret it.
The administrator must be able to identify OPES processor(s) involved
and may be able to identify applied adaptation services along with
other message-specific information. That information SHOULD help to
explain what OPES entities were involved and the actions that they
performed. It may be impractical to provide all the required
information in all cases. This document view a trace record as a
hint, as opposed to an exhaustive audit.
Since the administrators of various trust domains can have various
ways of looking into tracing, they MAY require the choice of freedom
in what to put in trace records and how to format them. Trace records
should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to
the extent possible.
It is not expected that entities in one trust domain to be able to
get all OPES-related feedback from entities in other trust domains.
For example, if an end-user suspects that a service was corrupted by
a callout service, then, there is no guarantee that the user will be
able to identify that service, contact its owner, or debug it, unless
the service is within its trust domain. This is no different from the
current situation where it is impossible, in general, to know the
contact person for an application on an origin server that generates
corrupted HTML; and even if the person is known, one should not
expect that person to respond to end-user queries.
7.2 Requirements for In-Band Tracing
The OPES architecture [8] states that traces must be in-band. The
support of this design goal is dependent on the specifics of the
message application level protocol that is being used in an OPES
flow. In-band tracing limits the type of application protocols that
OPES can support. The details of what a trace record can convey is
also dependent on the choice of the application level protocol.
For these reasons, this work documents requirements for application
protocols that need to support OPES traces. However, the architecture
does not prevent implementers of developing out-of-band protocols and
techniques to address the above limitation.
7.2.1 Tracing Information Granularity and Persistence levels
Requirements
In order to be able to trace entities that have acted on an
application message in an OPES flow, there may be requirements to
keep information that is related to the following:
o Message-related information: All data that describes specific
actions performed on the message SHOULD be provided with that
message, as there is no other way to find message level details at
a later stage.
o Session related information: Session level data MUST be preserved 3.4 Requirements for callout servers
for the duration of the session. OPES processor is responsible for
inserting notifications if session-level information changes.
o End-point related data: What profile is activated? Where to get In an OPES system, it is the task of an OPES processor to add trace
profile details? Where to set preferences? records to application messages. However, in some cases, callout
servers May add trace information to application messages. This
should be done under the control of the OPES System provider.
7.3 Protocol Binding 3.5 Protocol Binding
The task of adding tracing information is application protocol The task of adding tracing information is application protocol
specific. Separate documents will address HTTP and other protocols. specific. Separate documents will address HTTP and other protocols.
This work documents what tracing information is required and some This work documents what tracing information is required and some
common tracing elements. common tracing elements.
8. Tracing Examples 4. Non-Blocking
This section provides some examples of tracing that could be
generated by an OPES System. The examples are based on HTTP [3] and
use HTTP extension headers as given in [6]. In [6] trace entries are
supplied using HTTP extension message headers. These headers are
defined using #list constructs. A valid HTTP message may contain
multiple entries of each header. In an OPES Systems, these headers
MUST be used to represent the trace entries.
In [6], the following HTTP extensions are defined:
OPES-System = "OPES-System" ":" #trace-entry
OPES-Processor = "OPES-Processor" ":" #trace-entry
OPES-Service = "OPES-Service" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
8.1 Single OPES Processor: Detailed Trace
This example consider the case of an OPES System consisting of a
single OPES Processor that is capable of locally performing three
OPES services. A data consumer application may receive the following
HTTP response message header after OPES adaptations have been
applied:
HTTP/1.1 200 OK
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: application/octet-stream
OPES-System: http://www.example-opes-systemA.com/
opes?session=ac79a7901549f56
OPES-Service: http:// www.example-opes-systemA.com /?sid=123
OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124
OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=125
In this example, the trace has identified the OPES System and all the
OPES services that were performed on the data consumer application
original request.
8.2 Single OPES Processor: Partial Trace
In this example, the OPES System consisting of a two OPES Processor.
Each Processor is capable of locally performing many OPES services. A
data consumer application may receive the following HTTP response
message header after OPES adaptations have been applied:
HTTP/1.1 200 OK
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: application/octet-stream
OPES-System: http://www.example-opes-systemA.com/
opes?session=ac79a7901549f56
OPES-Service: http:// www.example-opes-systemA.com /?sid=123
OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124 ;
Mode = Aggregate
In this example, several OPES services may be performed on the
request. However, the trace has one entry that fully identifies one
service and the other services are identified through a common ID.
The OPES system is expected to be able to detail the other services
when queried by the data consumer application.
8.3 Multiple OPES Processors: Full Trace
In this example, the OPES System consisting of a two OPES Processors.
Each processor is capable of locally performing two OPES services. A
data consumer application may receive the following HTTP response
message header after OPES adaptations have been applied:
HTTP/1.1 200 OK
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: application/octet-stream
OPES-System: http://www.example-opes-systemA.com/
opes?session=ac79a7901549f56
OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
?sid=123
OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
?sid=124
OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
?sid=111
OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
?sid=112
In this example, the trace has identified the OPES System and all the
OPES services that were performed on the data consumer application
original request.
8.4 Multiple OPES Processors: Partial Trace
In this example, the OPES System consisting of a two OPES Processors. In [9] recommendation addresses the issue of non-blocking in an OPES
Each processor is capable of locally performing several OPES System. The recommendation is restated below for ease of reference.
services. A data consumer application may receive the following HTTP
response message header after OPES adaptations have been applied:
HTTP/1.1 200 OK (3.3) Non-blocking: If there exists a non-OPES version of content
available from the content provider, the OPES architecture must
not prevent users from retrieving this non-OPES version from the
content provider.
Date: Wed, 15 Nov 1995 06:25:24 GMT The IAB recommendation implies that it is up to the content provider
to make non-OPES versions of a given content available. The actual
meaning of non-OPES version of the content depended on the agreement
between the OPES provider and the content provider. The agreement can
allow OPES to perform some services (such as logging services) and
prevent it from performing other services (such as data to audio
transformation).
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Whether an OPES System honor a non-blocking request from a data
consumer application (user) can also be a function of deployment.
Consider the case where Company A has as contract with an OPES
provider to perform virus checking on all e-mail attachments. An
employee X of Company A can issue a non-blocking request for the
virus scanning service. However, the request could be ignored by the
OPES provider since it contradicts its agreement with Company A. As
a second example, a user may issue a non-blocking request for adult
content, this request may be declined by the OPES provider simply
because it contradicts its internal policy or its agreement with the
end subscriber.
Content-type: application/octet-stream In some cases, a data consumer application will issue a non-blocking
request since it suspects that the OPES System is corrupting the
data. For example, an OPES entity has determined that a Virus is
present in an attachment, while the user is aware that some versions
of virus scanners will make that mistake. In this case, the user can
use the non-blocking technique (can be used in combination with the
tracing facility) to solve the problem. However, whether the OPES
System will honor the non-blocking request or not is still a function
of the deployment scenario, content availability and related
policies.
OPES-System: http://www.example-opes-systemA.com/ Like tracing, Non-blocking operates on per application message bases.
opes?session=ac79a7901549f56 Non-Blocking is an end-end operation as opposed to a hop-by-hop
operation. Non-blocking requests are generally client centric and go
in the opposite direction of tracing requests. Non-blocking can be
performed out of band or in-band. This work requires non-blocking to
be performed in-band as an extension to an application specific
protocol. Non-OPES entities should be able to safely ignore the
extensions. The work does not prevent OPES Systems from developing
their own out of band protocols.
OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/ Non-blocking format is dependent on the application protocol that is
?sid=123 being adapted by OPES. For a given application protocol, in an OPES
System there can be services that operate on application message
headers and those that just operate on content. This mix of service
requires that an OPES processor that is calling the service(s) to
handle the non-blocking request. In some cases, the first OPES
processor that will get the non-blocking request may not be the first
OPES processor that will know whether a non-OPES version of the
content is available or not.
OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/ In an OPES System, the OPES provider is expected to configure at
?sid=124 ; Mode A least one OPES processor to process a non-blocking header based on
content availability and related policies. In this case the OPES
processor is expected to determine the set of services that will be
bypassed (or those services that will be performed) or whether the
request should be forwarded directly to the data provider application
(origin content provider).
OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/ Although, IAB recommendation (3.3) has intended for non-blocking
?sid=111 approach to be used as a vehicle to bypass faulty OPES
intermediaries. However, this work recognizes that the same technique
can be used to enable a data consumer application to select the set
of services that it would like to be bypassed for a given application
message. For this reason, a non-blocking request is viewed as a
bypass instruction that contains a URI that identifies an OPES entity
or a group of OPES entities that perform a service (or services) to
be bypassed. An instruction may contain more than one such URI. A
special wildcard identifier can be used to represent all possible
URIs (i.e., all possible OPES services). This version of the work
requires that all non-blocking instructions to use the wildcard
approach.
OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/ For example, an application level protocol (such as HTTP) can be
?sid=112 ; Mode B extended to include the following OPES non-blocking related header:
In this example, several OPES services may be performed on the
request. However, the trace partially indicates the services that
were performed. The OPES system is expected to be able to detail the
other services when queried by the data consumer application.
9. Optional Notification OPES-Bypass: *
This section examines IAB [2] considerations (3.1) and (3.2) The following requirements apply for non-blocking feature:
regarding notification in an OPES architecture.
Notification propagates in opposite direction of tracing and cannot o An OPES System MUST support the non-blocking feature for requests
be attached to the application messages that it notifies about. of non-OPES content for a given application message.
Notification can be done out-band and may require the development of
a new protocol. The direction of data flow for tracing and
notification are depicted in Figure 2.
Notification o An OPES System MUST treat the non-blocking feature as an
+----------------------------------------------- end-to-end operation.
| |
| V
+---------------+ +-------+ +---------------+
| | | | | Data Provider |
| Data Consumer | Tracing | OPES |<----->| Application |
| Application |<-----------| | +---------------+
+---------------+ +-------+
^
|OCP
|
V
+---------+
| Callout |
| Server |
+---------+
Figure 2: Notification Flow * This means that there MUST be at least one OPES processor in an
OPES System that knows how to interpret and process the
non-blocking feature.
In [9] it was argued that Notification is an expensive approach for * The recipient MUST forward the bypass instructions to the next
providing tracing information. However, the current work does not application hop provided that the next hop speaks application
prevent an OPES System from publishing policy and specifications that protocol with OPES bypass support.
allow Optional Notification. For example, an OPES System can adopt a
mechanism that uses a flag that would allow a data consumer and a
data provider application to signal to each other that they are
interested to receive an explicit notification if an OPES service is
applied to a specific message. The value of this optional flag/field
can be a URI that identifies notification method plus parameters. If
a processor understands the method, it would be able to further
decode the field and send a notification. The specification of the
field name and format for an application protocol can be stated in
the associated binding document. The details of the notification
protocol is beyond the scope of this document.
For example, the following HTTP header: * This requirement applies to all bypass instructions, including
those that identify known-to-recipient entities.
OPES-Notify: URI *(pname=pvalue) o Application-specific bindings MUST map the above non-blocking
mechanism to their application protocol.
Or, End users may not be able to know if their non-blocking request was
honored or not by the OPES System. In this case, it would be
beneficial if tracing can provide additional information regarding
whether a non-blocking request was honored or not. For this reason,
the following requirement also apply to the tracing facility:
My-OPES-Notify: foo=bar q=0.5 o An OPES System SHOULD assist the data consumer application in
determining if a non-blocking request was performed by the system.
can be used. Assistance is viewed as the addition of information about services
that were skipped and those that could not be bypassed.
10. IANA considerations 5. IANA considerations
This work does not require any IANA consideration since any actions This work does not require any IANA consideration since any actions
will be addressed in [6]. will be addressed in [6].
11. Security Considerations 6. Security Considerations
The security considerations for OPES are documented in [7]. This The security considerations for OPES are documented in [7]. This
document is a requirement document for tracing and as such does not document is a requirement document for tracing and non-blocking and
develop any new protocols that require security considerations. as such does not develop any new protocols that require security
considerations.
Normative References Normative References
[1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios", [1] A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
Internet-Draft http://www.ietf.org/internet-drafts/ Internet-Draft http://www.ietf.org/internet-drafts/
draft-ietf-opes-scenarios-01.txt, Auguest 2002. draft-ietf-opes-scenarios-01.txt, August 2002.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [3] 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.
[4] A. Barbir et al., "Policy, Authorization and Enforcement [4] A. Barbir et al., "Policy, Authorization and Enforcement
 End of changes. 

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