draft-ietf-opes-protocol-reqs-02.txt   draft-ietf-opes-protocol-reqs-03.txt 
Open Pluggable Edge Services A. Beck Open Pluggable Edge Services A. Beck
Internet-Draft M. Hofmann Internet-Draft M. Hofmann
Expires: January 31, 2003 Lucent Technologies Expires: June 12, 2003 Lucent Technologies
H. Orman H. Orman
Purple Streak Development Purple Streak Development
R. Penno R. Penno
Nortel Networks Nortel Networks
A. Terzis A. Terzis
Individual Consultant Individual Consultant
August 2, 2002 December 12, 2002
Requirements for OPES Callout Protocols Requirements for OPES Callout Protocols
draft-ietf-opes-protocol-reqs-02 draft-ietf-opes-protocol-reqs-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 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
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 31, 2003. This Internet-Draft will expire on June 12, 2003.
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 document specifies the requirements that the OPES (Open This document specifies the requirements that the OPES (Open
Pluggable Edge Services) callout protocol must satisfy in order to Pluggable Edge Services) callout protocol must satisfy in order to
support the remote execution of OPES services [1]. The requirements support the remote execution of OPES services. The requirements are
are intended to help evaluating possible protocol candidates and to intended to help evaluating possible protocol candidates as well as
guide the development of such protocols. to guide the development of such protocols.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5
3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 3.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . 5
3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5
3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6 3.4 Callout Connections . . . . . . . . . . . . . . . . . . . . 6
3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6 3.5 Asynchronous Message Exchange . . . . . . . . . . . . . . . 6
3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7 3.6 Message Segmentation . . . . . . . . . . . . . . . . . . . . 7
3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7 3.7 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 7
3.8 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 7 3.8 Operation in NAT Environments . . . . . . . . . . . . . . . 8
3.9 Support for Different Application Protocols . . . . . . . . 7 3.9 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 8
3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7 3.10 Multiple OPES Processors . . . . . . . . . . . . . . . . . . 8
3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8 3.11 Support for Different Application Protocols . . . . . . . . 8
3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9 3.12 Capability and Parameter Negotiations . . . . . . . . . . . 8
3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9 3.13 Meta Data and Instructions . . . . . . . . . . . . . . . . . 9
4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11
4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11
5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12
5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12
5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12
5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12
5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . 16
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 21
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
2. Introduction 2. Introduction
The Open Pluggable Edge Services (OPES) architecture [1] enables The Open Pluggable Edge Services (OPES) architecture [1] enables
skipping to change at page 5, line 7 skipping to change at page 5, line 7
callout protocol. This document presents the requirements for such a callout protocol. This document presents the requirements for such a
protocol. protocol.
The requirements in this document are divided into three categories - The requirements in this document are divided into three categories -
functional requirements, performance requirements, and security functional requirements, performance requirements, and security
requirements. Each requirement is presented as one or more requirements. Each requirement is presented as one or more
statements, followed by brief explanatory material as appropriate. statements, followed by brief explanatory material as appropriate.
3. Functional Requirements 3. Functional Requirements
3.1 Callout Transactions 3.1 Reliability
The OPES callout protocol MUST be able to provide ordered reliability
for the communication between OPES processor and callout server.
Additionally, the callout protocol SHOULD be able to provide
unordered reliability.
In order to satisfy the reliability requirements, the callout
protocol SHOULD specify that it must be used with a transport
protocol which provides ordered/unordered reliability at the
transport-layer, for example TCP [6] or SCTP [7].
3.2 Congestion Avoidance
The OPES callout protocol MUST ensure that congestion avoidance that
matches the standard of RFC 2914 [4] is applied on all communication
between OPES processor and callout server. For this purpose, the
callout protocol SHOULD use a congestion-controlled transport-layer
protocol, presumably either TCP [6] or SCTP [7].
3.3 Callout Transactions
The OPES callout protocol MUST enable an OPES processor and a callout The OPES callout protocol MUST enable an OPES processor and a callout
server to perform callout transactions with the purpose of exchanging server to perform callout transactions with the purpose of exchanging
partial or complete application-level protocol messages (or partial or complete application-level protocol messages (or
modifications thereof). More specifically, the callout protocol MUST modifications thereof). More specifically, the callout protocol MUST
enable an OPES processor to forward a partial or complete application enable an OPES processor to forward a partial or complete application
message to a callout server so that one or more OPES services can message to a callout server so that one or more OPES services can
process the forwarded application message (or parts thereof). The process the forwarded application message (or parts thereof). The
result of the service operation may be a modified application result of the service operation may be a modified application
message. The callout protocol MUST therefore enable the callout message. The callout protocol MUST therefore enable the callout
server to return a modified application message or the modified parts server to return a modified application message or the modified parts
of an application message to the OPES processor. of an application message to the OPES processor. Additionally, the
callout protocol MUST enable a callout server to report back to the
OPES processor the result of a callout transaction, e.g. in the form
of a status code.
A callout transaction is defined as a message exchange between an A callout transaction is defined as a message exchange between an
OPES processor and a callout server consisting of a callout request OPES processor and a callout server consisting of a callout request
and a callout response. Both, the callout request as well as the and a callout response. Both, the callout request as well as the
callout response, MAY each consist of one or more callout protocol callout response, MAY each consist of one or more callout protocol
messages, i.e. a series of protocol messages. messages, i.e. a series of protocol messages. A callout request
MUST always contain a partial or complete application message. A
callout response MUST always indicate the result of the callout
transaction. A callout response MAY contain a modified application
message.
Callout transactions are always initiated by a callout request from Callout transactions are always initiated by a callout request from
an OPES processor and typically terminated by a callout response from an OPES processor and typically terminated by a callout response from
a callout server. The OPES callout protocol MUST, however, also a callout server. The OPES callout protocol MUST, however, also
allow either endpoint of a callout transaction to terminate a callout provide a mechanism that allows either endpoint of a callout
transaction prematurely, i.e. before a callout request or response transaction to terminate a callout transaction before a callout
has been completely received by the corresponding endpoint. The request or response has been completely received by the corresponding
callout protocol MAY provide an explicit (e.g. through a termination callout endpoint. Such a mechanism MUST ensure that a premature
message) or implicit (e.g. through a connection tear-down) mechanism termination of a callout transaction does not result in the loss of
to terminate a callout transaction prematurely. Such a mechanism application message data.
MUST ensure, however, that a premature termination of a callout
transaction does not result in the loss of application message data.
A premature termination of a callout transaction is required to A premature termination of a callout transaction is required to
support OPES services which may terminate even before they have support OPES services which may terminate even before they have
processed the entire application message. Content analysis services, processed the entire application message. Content analysis services,
for example, may be able to classify a Web object after having for example, may be able to classify a Web object after having
processed just the first few bytes of a Web object. processed just the first few bytes of a Web object.
The callout protocol MUST further enable a callout server to report 3.4 Callout Connections
back to the OPES processor the result of a callout transaction, e.g.
in the form of a status code.
3.2 Callout Channels
The OPES callout protocol MUST enable an OPES processor and a callout The OPES callout protocol MUST enable an OPES processor and a callout
server to perform multiple callout transactions over a callout server to perform multiple callout transactions over a callout
channel. A callout channel is defined as a logical connection at the connection. Additionally, the callout protocol MUST provide a method
application-layer between an OPES processor and a callout server. to associate callout transactions with callout connections. A
callout connection is defined as a logical connection at the
application-layer between an OPES processor and a callout server. A
callout connection MAY have certain parameters associated with it,
for example parameters that control the fail-over behavior of
connection endpoints. Callout connection-specific parameters MAY be
negotiated between OPES processors and callout servers (see Section
3.12).
Callout channels MUST always be established by an OPES processor. A The OPES callout protocol MAY choose to multiplex multiple callout
callout channel MAY be closed by either endpoint of the callout connections over a single transport-layer connection so long as a
channel provided that all callout transactions associated with the flow control mechanism is applied which guarantees fairness among
channel have terminated. multiplexed callout connections.
A callout channel MAY have certain parameters associated with it, for Callout connections MUST always be initiated by an OPES processor. A
example parameters that control the fail-over behavior of channel callout connection MAY be closed by either endpoint of the connection
endpoints. Callout channel parameters MAY be negotiated between OPES provided that doing so does not affect the normal operation of
processors and callout servers (see Section 3.10). on-going callout transactions associated with the callout connection.
3.3 Reliability 3.5 Asynchronous Message Exchange
The OPES callout protocol MUST be able to provide ordered reliability The OPES callout protocol MUST support an asynchronous message
for the communication between OPES processor and callout server. exchange over callout connections.
Additionally, the callout protocol SHOULD be able to provide
unordered reliability.
In order to satisfy the reliability requirements, the callout In order to allow asynchronous processing on the OPES processor and
protocol MAY specify that it must be used with a lower-level callout server, it MUST be possible to separate request issuance from
transport protocol which provides ordered reliability at the response processing. The protocol MUST therefore allow multiple
transport-layer. outstanding callout requests and provide a method to correlate
callout responses to callout requests.
3.4 Congestion and Flow Control Additionally, the callout protocol MUST enable a callout server to
respond to a callout request before it has received the entire
request.
The OPES callout protocol MUST ensure that congestion and flow 3.6 Message Segmentation
control mechanisms are applied on all callout transactions. For this
purpose, the callout protocol MAY specify callout protocol-specific
mechanisms or refer to a lower-level transport protocol and discuss
how its mechanisms provide for congestion and flow control.
3.5 Support for Keep-Alive Mechanism The OPES callout protocol MUST allow an OPES processor to forward an
application message to a callout server in a series of smaller
message fragments. The callout protocol MUST further enable the
receiving callout server to re-assemble the fragmented application
message.
The OPES callout protocol MUST provide an optional keep-alive Likewise, the callout protocol MUST enable a callout server to return
mechanism which, if used, would allow both endpoints of a callout an application message to an OPES processor in a series of smaller
channel to detect a failure of the other endpoint even in the absence message fragments. The callout protocol MUST enable the receiving
of callout transactions. The callout protocol MAY specify that keep- OPES processor to re-assemble the fragmented application message.
alive messages be exchanged over existing callout channel connections
or a separate connection between OPES processor and callout server. Depending on the application-layer protocol used on the data path,
application messages may be very large in size (for example in the
case of audio/video streams) or of unknown size. In both cases, the
OPES processor has to initiate a callout transaction before it has
received the entire application message to avoid long delays for the
data consumer. The OPES processor MUST therefore be able to forward
fragments or chunks of an application message to a callout server as
it receives them from the data provider or consumer. Likewise, the
callout server MUST be able to process and return application message
fragments as it receives them from the OPES processor.
Application message segmentation is also required if the OPES callout
protocol provides a flow control mechanism in order to multiplex
multiple callout connections over a single transport-layer connection
(see Section 3.4).
3.7 Support for Keep-Alive Mechanism
The OPES callout protocol MUST provide a keep-alive mechanism which,
if used, would allow both endpoints of a callout connection to detect
a failure of the other endpoint even in the absence of callout
transactions. The callout protocol MAY specify that keep-alive
messages be exchanged over existing callout connections or a separate
connection between OPES processor and callout server. The callout
protocol MAY also specify that the use of the keep-alive mechanism is
optional.
The detection of a callout server failure may enable an OPES The detection of a callout server failure may enable an OPES
processor to establish a channel connection with a stand-by callout processor to establish a callout connection with a stand-by callout
server so that future callout transactions do not result in the loss server so that future callout transactions do not result in the loss
of application message data. The detection of the failure of an OPES of application message data. The detection of the failure of an OPES
processor may enable a callout server to release resources which processor may enable a callout server to release resources which
would otherwise not be available for callout transactions with other would otherwise not be available for callout transactions with other
OPES processors. OPES processors.
3.6 Operation in NAT Environments 3.8 Operation in NAT Environments
The OPES protocol SHOULD be NAT-friendly, i.e. its operation should The OPES protocol SHOULD be NAT-friendly, i.e. its operation should
not be compromised by the presence of one or more NAT devices in the not be compromised by the presence of one or more NAT devices in the
path between an OPES processor and a callout server. path between an OPES processor and a callout server.
3.7 Multiple Callout Servers 3.9 Multiple Callout Servers
The OPES callout protocol MUST allow an OPES processor to The OPES callout protocol MUST allow an OPES processor to
simultaneously communicate with more than one callout server. simultaneously communicate with more than one callout server.
In larger networks, OPES services are likely to be hosted by In larger networks, OPES services are likely to be hosted by
different callout servers. Therefore, an OPES processor will likely different callout servers. Therefore, an OPES processor will likely
have to communicate with multiple callout servers. The protocol have to communicate with multiple callout servers. The protocol
design MUST enable an OPES processor to do so. design MUST enable an OPES processor to do so.
3.8 Multiple OPES Processors 3.10 Multiple OPES Processors
The OPES callout protocol MUST allow a callout server to The OPES callout protocol MUST allow a callout server to
simultaneously communicate with more than one OPES processor. simultaneously communicate with more than one OPES processor.
The protocol design MUST support a scenario in which multiple OPES The protocol design MUST support a scenario in which multiple OPES
processors use the services of a single callout server. processors use the services of a single callout server.
3.9 Support for Different Application Protocols 3.11 Support for Different Application Protocols
The OPES callout protocol MUST be application protocol-agnostic, i.e. The OPES callout protocol SHOULD be application protocol-agnostic,
it MUST not make any assumptions about the characteristics of the i.e. it SHOULD not make any assumptions about the characteristics of
application-layer protocol used on the data path between data the application-layer protocol used on the data path between data
provider and data consumer. provider and data consumer. At a minimum, the callout protocol MUST
be compatible with HTTP [5].
The OPES entities on the data path may use different application- The OPES entities on the data path may use different
layer protocols, including, but not limited to, HTTP [3] and RTP [4]. application-layer protocols, including, but not limited to, HTTP [5]
It would be desirable to be able to use the same OPES callout and RTP [8]. It would be desirable to be able to use the same OPES
protocol for any such application-layer protocol. callout protocol for any such application-layer protocol.
3.10 Capability and Parameter Negotiations 3.12 Capability and Parameter Negotiations
The OPES callout protocol MUST support the negotiation of The OPES callout protocol MUST support the negotiation of
capabilities and callout channel parameters between an OPES processor capabilities and callout connection parameters between an OPES
and a callout server. This implies that the OPES processor and the processor and a callout server. This implies that the OPES processor
callout server MUST be able to exchange their capabilities and and the callout server MUST be able to exchange their capabilities
preferences and engage into a deterministic negotiation process at and preferences and engage into a deterministic negotiation process
the end of which the two endpoints have either agreed on the at the end of which the two endpoints have either agreed on the
capabilities and parameters to be used for future callout channel capabilities and parameters to be used for future callout
transactions or determined that their capabilities are incompatible. connections/transactions or determined that their capabilities are
incompatible.
Capabilities and parameters that could be negotiated between an OPES Capabilities and parameters that could be negotiated between an OPES
processor and a callout server include (but are not limited to): processor and a callout server include (but are not limited to):
callout protocol version, transport-layer protocol, fail-over callout protocol version, fail-over behavior, heartbeat rate for
behavior, heartbeat rate for keep-alive messages, security-related keep-alive messages, security-related parameters etc.
parameters etc.
Channel parameters may also pertain to the characteristics of OPES The callout protocol MUST NOT negotiate the transport protocol to be
callout services if, for example, callout channels are associated used for callout connections. The callout protocol MAY, however,
with one or more specific OPES services. An OPES service-specific specify that a certain application message protocol (e.g. HTTP [5],
parameter may, for example, specify which parts of an application RTP [8]) requires the use of a certain transport protocol (e.g. TCP
message an OPES service requires for its operation. [6], SCTP [7]).
Callout channel parameters MUST be negotiated on a per-callout Callout connection parameters may also pertain to the characteristics
channel basis and before any callout transactions are performed over of OPES callout services if, for example, callout connections are
the corresponding channel. Other parameters and capabilities, such associated with one or more specific OPES services. An OPES
as the fail-over behavior, MAY be negotiated between the two service-specific parameter may, for example, specify which parts of
endpoints independently of callout channels. an application message an OPES service requires for its operation.
The parties to a callout protocol MAY use callout channels to Callout connection parameters MUST be negotiated on a per-callout
connection basis and before any callout transactions are performed
over the corresponding callout connection. Other parameters and
capabilities, such as the fail-over behavior, MAY be negotiated
between the two endpoints independently of callout connections.
The parties to a callout protocol MAY use callout connections to
negotiate all or some of their capabilities and parameters. negotiate all or some of their capabilities and parameters.
Alternatively, a separate control connection MAY be used for this Alternatively, a separate control connection MAY be used for this
purpose. purpose.
3.11 Meta Data and Instructions 3.13 Meta Data and Instructions
The OPES callout protocol MUST provide a mechanism for the endpoints The OPES callout protocol MUST provide a mechanism for the endpoints
of a particular callout transaction to include in callout requests of a particular callout transaction to include in callout requests
and responses meta data and instructions for the OPES processor or and responses meta data and instructions for the OPES processor or
callout server. callout server.
Specifically, the callout protocol MUST enable an OPES processor to Specifically, the callout protocol MUST enable an OPES processor to
include information about the forwarded application message in a include information about the forwarded application message in a
callout request, e.g. in order to specify the type of the forwarded callout request, e.g. in order to specify the type of the forwarded
application message or to specify what part(s) of the application application message or to specify what part(s) of the application
message are forwarded to the callout server. Likewise, the callout message are forwarded to the callout server. Likewise, the callout
server MUST be able to include information about the returned server MUST be able to include information about the returned
application message. application message.
The OPES processor MUST further be able to include an ordered list of The OPES processor MUST further be able to include an ordered list of
one or more uniquely specified OPES services which are to be one or more uniquely specified OPES services which are to be
performed on the forwarded application message in the specified performed on the forwarded application message in the specified
order. However, as the callout protocol MAY also choose to associate order. However, as the callout protocol MAY also choose to associate
callout channels with specific OPES services, there may not be a need callout connections with specific OPES services, there may not be a
to identify OPES service on a per-callout transaction basis. need to identify OPES services on a per-callout transaction basis.
Additionally, the OPES callout protocol MUST allow the callout server Additionally, the OPES callout protocol MUST allow the callout server
to indicate to the OPES processor the cacheability of callout to indicate to the OPES processor the cacheability of callout
responses. This implies that callout responses may have to carry responses. This implies that callout responses may have to carry
cache-control instructions for the OPES processor. cache-control instructions for the OPES processor.
The OPES callout protocol MUST further enable the OPES processor to The OPES callout protocol MUST further enable the OPES processor to
indicate to the callout server if it has kept a local copy of the indicate to the callout server if it has kept a local copy of the
forwarded application message (or parts thereof). This information forwarded application message (or parts thereof). This information
enables the callout server to determine whether the forwarded enables the callout server to determine whether the forwarded
application message must be returned to the OPES processor even it application message must be returned to the OPES processor even it
has not been modified by an OPES service. has not been modified by an OPES service.
The OPES callout protocol MUST also allow OPES processors to comply The OPES callout protocol MUST also allow OPES processors to comply
with the tracing requirements of the OPES architecture as laid out in with the tracing requirements of the OPES architecture as laid out in
[1] and [5]. This implies that the callout protocol MUST enable a [1] and [3]. This implies that the callout protocol MUST enable a
callout server to convey to the OPES processor information about the callout server to convey to the OPES processor information about the
OPES service operations performed on the forwarded application OPES service operations performed on the forwarded application
message. message.
3.12 Asynchronous Message Exchange
The OPES callout protocol MUST support an asynchronous message
exchange between an OPES processor and a callout server.
In order to allow asynchronous processing on the OPES processor and
callout server, it MUST be possible to separate request issuance from
response processing. The protocol MUST therefore allow multiple
outstanding requests and provide a method to correlate responses to
requests.
Additionally, the callout protocol MUST enable a callout server to
respond to a callout request before it has received the entire
request.
3.13 Message Segmentation
The OPES callout protocol MUST allow an OPES processor to forward an
application message to a callout server in a series of smaller
message fragments. The callout protocol MUST further enable the
receiving callout server to assemble the fragmented application
message.
Likewise, the callout protocol MUST enable a callout server to return
an application message to an OPES processor in a series of smaller
message fragments. The callout protocol MUST enable the receiving
OPES processor to assemble the fragmented application message.
Depending on the application-layer protocol used on the data path,
application messages may be very large in size (for example in the
case of audio/video streams) or of unknown size. In both cases, the
OPES processor has to initiate a callout transaction before it has
received the entire application message to avoid long delays for the
data consumer. The OPES processor MUST therefore be able to forward
fragments or chunks of an application message to a callout server as
it receives them from the data provider or consumer. Likewise, the
callout server MUST be able to process and return application message
fragments as it receives them from the OPES processor.
4. Performance Requirements 4. Performance Requirements
4.1 Protocol Efficiency 4.1 Protocol Efficiency
The OPES callout protocol SHOULD be efficient in that it minimizes The OPES callout protocol SHOULD be efficient in that it minimizes
the additionally introduced latency, for example by minimizing the the additionally introduced latency, for example by minimizing the
protocol overhead. protocol overhead.
As OPES callout transactions introduce additional latency to As OPES callout transactions introduce additional latency to
application protocol transactions on the data path, callout protocol application protocol transactions on the data path, callout protocol
skipping to change at page 12, line 34 skipping to change at page 12, line 34
The parties to the callout protocol MUST have a sound basis for The parties to the callout protocol MUST have a sound basis for
binding authenticated identities to the protocol endpoints, and they binding authenticated identities to the protocol endpoints, and they
MUST verify that these identities are consistent with their security MUST verify that these identities are consistent with their security
policies. policies.
The OPES callout protocol MUST provide for message authentication, The OPES callout protocol MUST provide for message authentication,
confidentiality, and integrity between the OPES processor and the confidentiality, and integrity between the OPES processor and the
callout server. It MUST provide mutual authentication. For this callout server. It MUST provide mutual authentication. For this
purpose, the callout protocol SHOULD use existing security purpose, the callout protocol SHOULD use existing security
mechanisms. The callout protocol specification is not required to mechanisms. The callout protocol specification is not required to
specify the security mechanisms, but it MAY instead refer to a lower- specify the security mechanisms, but it MAY instead refer to a
level security protocol and discuss how its mechanisms are to be used lower-level security protocol and discuss how its mechanisms are to
with the callout protocol. be used with the callout protocol.
5.2 Hop-by-Hop Confidentiality 5.2 Hop-by-Hop Confidentiality
If end-to-end encryption is a requirement for the content path, then If end-to-end encryption is a requirement for the content path, then
this confidentiality MUST be extended to the communication between this confidentiality MUST be extended to the communication between
the callout servers and the OPES processor. In order to minimize the OPES processor and the callout server. While it is recommended
data exposure, the callout protocol MUST use a different encryption that the communication between OPES processor and callout server
key for each encrypted content stream. always be encrypted, encryption MAY be optional if both the OPES
processor and the callout server are co-located with each other in a
single administrative domain with strong confidentiality guarantees.
5.3 Operation Across Un-trusted Domains In order to minimize data exposure, the callout protocol MUST use a
different encryption key for each encrypted content stream.
5.3 Operation Across Un-trusted Domains
The OPES callout protocol MUST operate securely across un-trusted The OPES callout protocol MUST operate securely across un-trusted
domains between the OPES processor and the callout server. domains between the OPES processor and the callout server.
If the communication channels between the OPES processor and callout If the communication channels between the OPES processor and callout
server cross outside of the organization taking responsibility for server cross outside of the organization taking responsibility for
the OPES services, then endpoint authentication and message the OPES services, then endpoint authentication and message
protection (confidentiality and integrity) MUST be used. protection (confidentiality and integrity) MUST be used.
5.4 Privacy 5.4 Privacy
Any communication carrying information relevant to privacy policies Any communication carrying information relevant to privacy policies
MUST protect the data using encryption. MUST protect the data using encryption.
6. Security Considerations 6. Security Considerations
The security requirements for the OPES callout protocol are discussed The security requirements for the OPES callout protocol are discussed
in Section 5. in Section 5.
References Normative References
[1] Barbir, A., "An Architecture for Open Pluggable Edge Services [1] Barbir, A., "An Architecture for Open Pluggable Edge Services
(OPES)", draft-ietf-opes-architecture-03 (work in progress), (OPES)", draft-ietf-opes-architecture-04 (work in progress),
August 2002. December 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [3] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[4] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[5] 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] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, Informative References
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[5] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
Authors' Addresses Authors' Addresses
Andre Beck Andre Beck
Lucent Technologies Lucent Technologies
101 Crawfords Corner Road 101 Crawfords Corner Road
Holmdel, NJ 07733 Holmdel, NJ 07733
US US
EMail: abeck@bell-labs.com EMail: abeck@bell-labs.com
skipping to change at page 18, line 7 skipping to change at page 19, line 7
Appendix A. Acknowledgments Appendix A. Acknowledgments
This document is based in parts on previous work by Anca Dracinschi This document is based in parts on previous work by Anca Dracinschi
Sailer, Volker Hilt, and Rama R. Menon. Sailer, Volker Hilt, and Rama R. Menon.
The authors would like to thank the participants of the OPES WG for The authors would like to thank the participants of the OPES WG for
their comments on this draft. their comments on this draft.
Appendix B. Change Log Appendix B. Change Log
Changes from draft-ietf-opes-protocol-reqs-01.txt Changes from draft-ietf-opes-protocol-reqs-02.txt
o Re-ordered some sections in the functional requirements part of
the draft
o Clarified in Section 3.3 what callout requests and responses must/
may contain
o Removed reference to explicit and implicit mechanism of
terminating a callout transaction prematurely in Section 3.3
o Added reference to RFC 2914 in congestion avoidance requirement in
Section 3.2
o Added language that states that existing solutions should be used
to achieve congestion avoidance and ordered/unordered reliability
in Section 3.2 and Section 3.1
o Clarified concept of callout connections (previously referred to
as "callout channels") in Section 3.4
o Added statement about the possibility of multiplexing multiple
callout connections over a transport connection to Section 3.4
o Clarified in Section 3.7 that use of a keep-alive mechanism is
optional
o Replaced "MUST" with "SHOULD" in OCP requirement to be application
protocol-agnostic in Section 3.11, added explicit requirement to
support HTTP
o Removed "transport protocol" from list of callout parameters which
may be negotiated, added suggestion to pick transport protocol
depending on the application protocol in Section 3.12.
o Explained that application message segementation is also necessary
for multiplexing callout connections over transport connections in
Section 3.6
o Added statement to Section 5.2 that encryption between OPES
processor and callout server may be optional if they are
co-located with each other in a single administrative domain
Changes from draft-ietf-opes-protocol-reqs-01.txt
o Reworded and clarified several statements of the draft o Reworded and clarified several statements of the draft
Changes from draft-ietf-opes-protocol-reqs-00.txt Changes from draft-ietf-opes-protocol-reqs-00.txt
o Aligned terminology with [1] o Aligned terminology with [1]
o Clarified in Section 3.11 that OCP requests not only have to o Clarified in Section 3.13 that OCP requests not only have to
identify one or more OPES services, but also the order in which identify one or more OPES services, but also the order in which
the services are to be executed the services are to be executed
o Removed requirement from Section 4.1 that OCP must satisfy o Removed requirement from Section 4.1 that OCP must satisfy
performance requirements of the application-layer protocol used performance requirements of the application-layer protocol used
between data consumer and provider between data consumer and provider
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

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