Network Working Group A. Beck
Request for Comments: 3836 M. Hofmann
Category: Informational Lucent Technologies
H. Orman
Purple Streak Development
R. Penno
Nortel Networks
A. Terzis
Johns Hopkins University
August 2004
Network Working Group A. Beck
Request for Comments: 3836 M. Hofmann
Category: Informational Lucent Technologies
H. Orman
Purple Streak Development
R. Penno
Nortel Networks
A. Terzis
Johns Hopkins University
August 2004
Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
开放式可插拔边缘服务（OPES）调用协议的要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols.
本文件规定了OPES（开放可插拔边缘服务）调用协议必须满足的要求，以支持远程执行OPES服务。这些要求旨在帮助评估可能的候选方案，并指导此类方案的制定。
Table of Contents
目录
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 3
3.1. Reliability . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Congestion Avoidance . . . . . . . . . . . . . . . . . 3
3.3. Callout Transactions . . . . . . . . . . . . . . . . . 3
3.4. Callout Connections . . . . . . . . . . . . . . . . . . 4
3.5. Asynchronous Message Exchange . . . . . . . . . . . . . 5
3.6. Message Segmentation . . . . . . . . . . . . . . . . . 5
3.7. Support for Keep-Alive Mechanism . . . . . . . . . . . 6
3.8. Operation in NAT Environments . . . . . . . . . . . . . 6
3.9. Multiple Callout Servers . . . . . . . . . . . . . . . 6
3.10. Multiple OPES Processors . . . . . . . . . . . . . . . 6
3.11. Support for Different Application Protocols . . . . . . 7
3.12. Capability and Parameter Negotiations . . . . . . . . . 7
3.13. Meta Data and Instructions . . . . . . . . . . . . . . 8
4. Performance Requirements . . . . . . . . . . . . . . . . . . 9
4.1. Protocol Efficiency . . . . . . . . . . . . . . . . . . 9
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 9
5.1. Authentication, Confidentiality, and Integrity . . . . 9
5.2. Hop-by-Hop Confidentiality. . . . . . . . . . . . . . . 10
5.3. Operation Across Untrusted Domains. . . . . . . . . . . 10
5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References. . . . . . . . . . . . . . . . . . 10
7.2. Informative References. . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 3
3.1. Reliability . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Congestion Avoidance . . . . . . . . . . . . . . . . . 3
3.3. Callout Transactions . . . . . . . . . . . . . . . . . 3
3.4. Callout Connections . . . . . . . . . . . . . . . . . . 4
3.5. Asynchronous Message Exchange . . . . . . . . . . . . . 5
3.6. Message Segmentation . . . . . . . . . . . . . . . . . 5
3.7. Support for Keep-Alive Mechanism . . . . . . . . . . . 6
3.8. Operation in NAT Environments . . . . . . . . . . . . . 6
3.9. Multiple Callout Servers . . . . . . . . . . . . . . . 6
3.10. Multiple OPES Processors . . . . . . . . . . . . . . . 6
3.11. Support for Different Application Protocols . . . . . . 7
3.12. Capability and Parameter Negotiations . . . . . . . . . 7
3.13. Meta Data and Instructions . . . . . . . . . . . . . . 8
4. Performance Requirements . . . . . . . . . . . . . . . . . . 9
4.1. Protocol Efficiency . . . . . . . . . . . . . . . . . . 9
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 9
5.1. Authentication, Confidentiality, and Integrity . . . . 9
5.2. Hop-by-Hop Confidentiality. . . . . . . . . . . . . . . 10
5.3. Operation Across Untrusted Domains. . . . . . . . . . . 10
5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References. . . . . . . . . . . . . . . . . . 10
7.2. Informative References. . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的描述进行解释。
The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze, and possibly transform, application-level messages exchanged between the data provider and the data consumer.
开放可插拔边缘服务（OPES）体系结构[1]支持数据提供者、数据使用者和零个或多个OPES处理器之间的协作应用程序服务（OPES服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。
The execution of such services is governed by a set of rules installed on the OPES processor. The enforcement of rules can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [1], an OPES processor communicates with and invokes services on a callout server by using a callout protocol. This document presents the requirements for such a protocol.
此类服务的执行由安装在OPES处理器上的一组规则控制。规则的实施可以触发OPES处理器本地服务应用程序的执行。或者，OPES处理器可以通过与一个或多个远程调出服务器通信和协作来分配服务执行的责任。如[1]所述，OPES处理器通过调用协议与调用调用服务器上的服务进行通信。本文件介绍了此类协议的要求。
The requirements in this document are divided into three categories - functional requirements, performance requirements, and security requirements. Each requirement is presented as one or more statements, followed by brief explanatory material as appropriate.
本文档中的需求分为三类：功能需求、性能需求和安全需求。每项要求都以一个或多个陈述的形式呈现，然后根据需要提供简要的解释材料。
The OPES callout protocol MUST be able to provide ordered reliability for the communication between an OPES processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability.
OPES调出协议必须能够为OPES处理器和调出服务器之间的通信提供有序的可靠性。此外，调用协议应能够提供无序的可靠性。
In order to satisfy the reliability requirements, the callout protocol SHOULD specify that it must be used with a transport protocol that provides ordered/unordered reliability at the transport-layer, for example TCP [6] or SCTP [7].
为了满足可靠性要求，调出协议应规定必须与在传输层提供有序/无序可靠性的传输协议一起使用，例如TCP[6]或SCTP[7]。
The OPES callout protocol MUST ensure that congestion avoidance matching the standard of RFC 2914 [4] is applied on all communication between the 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].
OPES调出协议必须确保在OPES处理器和调出服务器之间的所有通信上应用符合RFC 2914[4]标准的拥塞避免。为此，callout协议应使用拥塞控制传输层协议，可能是TCP[6]或SCTP[7]。
The OPES callout protocol MUST enable an OPES processor and a callout server to perform callout transactions with the purpose of exchanging partial or complete application-level protocol messages (or modifications thereof). More specifically, the callout protocol MUST enable an OPES processor to forward a partial or complete application message to a callout server so that one or more OPES services can process the forwarded application message (or parts thereof). The result of the service operation may be a modified application message. The callout protocol MUST therefore enable the callout
OPES调用协议必须使OPES处理器和调用服务器能够执行调用事务，以交换部分或完整的应用程序级协议消息（或其修改）。更具体地说，调用协议必须使OPES处理器能够将部分或完整的应用程序消息转发到调用服务器，以便一个或多个OPES服务能够处理转发的应用程序消息（或其部分）。服务操作的结果可能是修改的应用程序消息。因此，调用协议必须启用调用
server to return a modified application message or the modified parts of an application message to the OPES processor. Additionally, the callout protocol MUST enable a callout server to report the result of a callout transaction (e.g., in the form of a status code) back to the OPES processor.
服务器将修改后的应用程序消息或应用程序消息的修改部分返回给OPES处理器。此外，调用协议必须使调用服务器能够将调用事务的结果（例如，以状态代码的形式）报告回OPES处理器。
A callout transaction is defined as a message exchange between an OPES processor and a callout server consisting of a callout request and a callout response. Both, the callout request and the callout response MAY each consist of one or more callout protocol 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.
调用事务定义为OPES处理器和调用服务器之间的消息交换，包括调用请求和调用响应。调出请求和调出响应都可能包含一个或多个调出协议消息，即一系列协议消息。调用请求必须始终包含部分或完整的应用程序消息。调出响应必须始终指示调出事务的结果。调出响应可能包含修改的应用程序消息。
Callout transactions are always initiated by a callout request from an OPES processor and are typically terminated by a callout response from a callout server. The OPES callout protocol MUST, however, also provide a mechanism that allows either endpoint of a callout transaction to terminate a callout transaction before a callout request or response has been completely received by the corresponding callout endpoint. Such a mechanism MUST ensure that a premature termination of a callout transaction does not result in the loss of application message data.
调出事务始终由OPES处理器的调出请求发起，通常由调出服务器的调出响应终止。然而，OPES调用协议还必须提供一种机制，允许调用事务的任一端点在相应调用端点完全接收调用请求或响应之前终止调用事务。这种机制必须确保调用事务的提前终止不会导致应用程序消息数据的丢失。
A premature termination of a callout transaction is required to support OPES services, which may terminate even before they have processed the entire application message. Content analysis services, for example, may be able to classify a Web object after having processed just the first few bytes of a Web object.
为支持OPES服务，需要提前终止调用事务，OPES服务甚至可能在处理整个应用程序消息之前终止。例如，内容分析服务可能能够在只处理Web对象的前几个字节之后对Web对象进行分类。
The OPES callout protocol MUST enable an OPES processor and a callout server to perform multiple callout transactions over a callout connection. Additionally, the callout protocol MUST provide a method of associating 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).
OPES调用协议必须允许OPES处理器和调用服务器通过调用连接执行多个调用事务。此外，调用协议必须提供将调用事务与调用连接关联的方法。调用连接定义为OPES处理器和调用服务器之间应用层的逻辑连接。详图索引连接可能具有与之关联的某些参数，例如控制连接端点故障转移行为的参数。调用连接特定参数可在OPES处理器和调用服务器之间协商（见第3.12节）。
The OPES callout protocol MAY choose to multiplex multiple callout connections over a single transport-layer connection if a flow control mechanism that guarantees fairness among multiplexed callout connections is applied.
如果应用了保证多路调用连接之间公平性的流控制机制，则OPES调用协议可以选择在单个传输层连接上多路调用多个调用连接。
Callout connections MUST always be initiated by an OPES processor. A callout connection MAY be closed by either endpoint of the connection, provided that doing so does not affect the normal operation of on-going callout transactions associated with the callout connection.
调用连接必须始终由OPES处理器启动。调用连接可以由连接的任一端点关闭，前提是这样做不会影响与调用连接关联的正在进行的调用事务的正常操作。
The OPES callout protocol MUST support an asynchronous message exchange over callout connections.
OPES调用协议必须支持调用连接上的异步消息交换。
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 callout requests and provide a method of correlating callout responses with callout requests.
为了允许在OPES处理器和callout服务器上进行异步处理，必须能够将请求发出与响应处理分开。因此，协议必须允许多个未完成的调用请求，并提供一种将调用响应与调用请求关联起来的方法。
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 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.
OPES callout协议必须允许OPES处理器以一系列较小的消息片段将应用程序消息转发到callout服务器。callout协议必须进一步使接收callout服务器能够重新组装碎片化的应用程序消息。
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 re-assemble the fragmented application message.
同样，调用协议必须允许调用服务器以一系列较小的消息片段将应用程序消息返回给OPES处理器。调出协议必须使接收OPES处理器能够重新组装分段应用程序消息。
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
根据数据路径上使用的应用层协议，应用消息的大小可能非常大（例如在音频/视频流的情况下）或未知大小。在这两种情况下，OPES处理器必须在收到整个应用程序消息之前启动调出事务，以避免数据使用者的长时间延迟。因此，OPES处理器必须能够将应用程序消息的片段或区块转发到callout服务器
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.
它从数据提供者或使用者接收数据。同样，callout服务器从OPES处理器接收应用程序消息片段时，必须能够处理并返回这些片段。
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).
如果OPES callout协议提供流量控制机制，以便在单个传输层连接上多路复用多个callout连接，则还需要应用程序消息分段（参见第3.4节）。
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.
OPES callout协议必须提供一个保持活动的机制，如果使用该机制，将允许callout连接的两个端点检测另一个端点的故障，即使在没有callout事务的情况下也是如此。调用协议可以指定通过现有调用连接或OPES处理器和调用服务器之间的单独连接交换保持活动消息。调用协议还可以指定使用保持活动机制是可选的。
The detection of a callout server failure may enable an OPES processor to establish a callout connection with a stand-by callout server so that future callout transactions do not result in the loss of application message data. The detection of the failure of an OPES processor may enable a callout server to release resources which would otherwise not be available for callout transactions with other OPES processors.
检测到调出服务器故障可能使OPES处理器能够与备用调出服务器建立调出连接，以便将来的调出事务不会导致应用程序消息数据丢失。OPES处理器故障检测可使调出服务器释放资源，否则这些资源将无法用于与其他OPES处理器的调出事务。
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 path between an OPES processor and a callout server.
OPES协议应为NAT友好协议，即其操作不应因OPES处理器和呼叫服务器之间的路径中存在一个或多个NAT设备而受损。
The OPES callout protocol MUST allow an OPES processor to simultaneously communicate with more than one callout server.
OPES调出协议必须允许OPES处理器同时与多个调出服务器通信。
In larger networks, OPES services are likely to be hosted by different callout servers. Therefore, an OPES processor will likely have to communicate with multiple callout servers. The protocol design MUST enable an OPES processor to do so.
在较大的网络中，OPES服务可能由不同的调用服务器托管。因此，OPES处理器可能必须与多个调出服务器通信。协议设计必须使OPES处理器能够这样做。
The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES processor.
OPES调用协议必须允许调用服务器同时与多个OPES处理器通信。
The protocol design MUST support a scenario in which multiple OPES processors use the services of a single callout server.
协议设计必须支持多个OPES处理器使用单个调出服务器服务的场景。
The OPES callout protocol SHOULD be application protocol-agnostic, i.e., it SHOULD not make any assumptions about the characteristics of the application-layer protocol used on the data path between the data provider and data consumer. At a minimum, the callout protocol MUST be compatible with HTTP [5].
OPES callout协议应与应用程序协议无关，也就是说，它不应对数据提供者和数据使用者之间的数据路径上使用的应用程序层协议的特性进行任何假设。callout协议至少必须与HTTP兼容[5]。
The OPES entities on the data path may use different application-layer protocols, including, but not limited to, HTTP [5] and RTP [8]. It would be desirable to be able to use the same OPES callout protocol for any such application-layer protocol.
数据路径上的OPES实体可以使用不同的应用层协议，包括但不限于HTTP[5]和RTP[8]。希望能够对任何此类应用层协议使用相同的OPES调用协议。
The OPES callout protocol MUST support the negotiation of capabilities and callout connection parameters between an OPES processor and a callout server. This implies that the OPES processor and the callout server MUST be able to exchange their capabilities and preferences. Then they MUST be able to engage in a deterministic negotiation process that terminates either with the two endpoints agreeing on the capabilities and parameters to be used for future callout connections/transactions or with a determination that their capabilities are incompatible.
OPES调用协议必须支持OPES处理器和调用服务器之间的功能和调用连接参数协商。这意味着OPES处理器和调出服务器必须能够交换其功能和首选项。然后，他们必须能够参与确定性协商过程，该过程终止于两个端点就未来调用连接/事务使用的功能和参数达成一致，或确定其功能不兼容。
Capabilities and parameters that could be negotiated between an OPES processor and a callout server include (but are not limited to): callout protocol version, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters, etc.
OPES处理器和callout服务器之间可以协商的功能和参数包括（但不限于）：callout协议版本、故障转移行为、保持活动消息的心跳速率、安全相关参数等。
The callout protocol MUST NOT use negotiation to determine the transport protocol to be used for callout connections. The callout protocol MAY, however, specify that a certain application message protocol (e.g., HTTP [5], RTP [8]) requires the use of a certain transport protocol (e.g., TCP [6], SCTP [7]).
调出协议不得使用协商来确定用于调出连接的传输协议。然而，调出协议可以指定特定应用消息协议（例如HTTP[5]，RTP[8]）需要使用特定传输协议（例如TCP[6]，SCTP[7]）。
Callout connection parameters may also pertain to the characteristics of OPES callout services if, for example, callout connections are associated with one or more specific OPES services. An OPES service-specific parameter may, for example, specify which parts of an application message an OPES service requires for its operation.
例如，如果调用连接与一个或多个特定的OPES服务相关联，则调用连接参数也可能与OPES调用服务的特征有关。例如，OPES服务特定参数可以指定OPES服务操作所需的应用程序消息的哪些部分。
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. Alternatively, a separate control connection MAY be used for this purpose.
调用协议各方可以使用调用连接协商其全部或部分功能和参数。或者，可为此目的使用单独的控制连接。
The OPES callout protocol MUST provide a mechanism for the endpoints of a particular callout transaction to include metadata and instructions for the OPES processor or callout server in callout requests and responses.
OPES调出协议必须为特定调出事务的端点提供一种机制，以便在调出请求和响应中包含用于OPES处理器或调出服务器的元数据和指令。
Specifically, the callout protocol MUST enable an OPES processor to include information about the forwarded application message in a callout request, e.g. in order to specify the type of forwarded application message or to specify what part(s) of the application message are forwarded to the callout server. Likewise, the callout server MUST be able to include information about the returned application message.
具体而言，调出协议必须使OPES处理器能够在调出请求中包含有关转发的应用程序消息的信息，例如，为了指定转发的应用程序消息的类型或指定将应用程序消息的哪些部分转发到调出服务器。同样，callout服务器必须能够包含有关返回的应用程序消息的信息。
The OPES processor MUST further be able to include an ordered list of one or more uniquely specified OPES services which are to be performed on the forwarded application message in the specified order. However, as the callout protocol MAY also choose to associate callout connections with specific OPES services, there may not be a need to identify OPES services on a per-callout transaction basis.
OPES处理器还必须能够包括一个或多个唯一指定的OPES服务的有序列表，这些服务将以指定顺序在转发的应用程序消息上执行。但是，由于callout协议也可以选择将callout连接与特定的OPES服务相关联，因此可能不需要根据每个callout事务识别OPES服务。
Additionally, the OPES callout protocol MUST allow the callout server to indicate to the OPES processor the cacheability of callout responses. This implies that callout responses may have to carry cache-control instructions for the OPES processor.
此外，OPES调用协议必须允许调用服务器向OPES处理器指示调用响应的可缓存性。这意味着调用响应可能必须携带OPES处理器的缓存控制指令。
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 forwarded application message (or parts thereof). This information enables the callout server to determine whether the forwarded application message must be returned to the OPES processor, even if it has not been modified by an OPES service.
OPES callout协议必须进一步使OPES处理器能够向callout服务器指示其是否保存了转发的应用程序消息（或其部分）的本地副本。此信息使callout server能够确定转发的应用程序消息是否必须返回给OPES处理器，即使它未被OPES服务修改。
The OPES callout protocol MUST also allow OPES processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [3]. This implies that the callout protocol MUST enable a callout server to convey to the OPES processor information about the OPES service operations performed on the forwarded application message.
OPES调出协议还必须允许OPES处理器遵守[1]和[3]中规定的OPES体系结构的跟踪要求。这意味着调出协议必须使调出服务器能够向OPES处理器传递有关在转发的应用程序消息上执行的OPES服务操作的信息。
The OPES callout protocol SHOULD have minimal latency. For example, the size and complexity of its headers could be minimized.
OPES调出协议应具有最小的延迟。例如，它的头的大小和复杂性可以最小化。
Because OPES callout transactions add latency to application protocol transactions on the data path, callout protocol efficiency is crucial to overall performance.
由于OPES callout事务增加了数据路径上应用程序协议事务的延迟，因此callout协议的效率对整体性能至关重要。
In the absence of any security mechanisms, sensitive information might be communicated between the OPES processor and the callout server in violation of either endpoint's security and privacy policy, through misconfiguration or deliberate insider attack. By using strong authentication, message encryption, and integrity checks, this threat can be minimized to a smaller set of insiders and/or operator configuration errors.
在没有任何安全机制的情况下，可能会通过错误配置或蓄意内部攻击，违反任一端点的安全和隐私策略，在OPES处理器和callout服务器之间传输敏感信息。通过使用强身份验证、消息加密和完整性检查，可以将此威胁最小化为一组较小的内部人员和/或操作员配置错误。
The OPES processor and the callout servers SHOULD have enforceable policies that limit the parties they communicate with and that determine the protections to use based on identities of the endpoints and other data (such as enduser policies). In order to enforce the policies, they MUST be able to authenticate the callout protocol endpoints using cryptographic methods.
OPES处理器和调出服务器应具有可强制执行的策略，以限制其与之通信的各方，并根据端点和其他数据的身份确定要使用的保护（如最终用户策略）。为了实施这些策略，它们必须能够使用加密方法对调用协议端点进行身份验证。
The parties to the callout protocol MUST have a sound basis for binding authenticated identities to the protocol endpoints, and they MUST verify that these identities are consistent with their security policies.
callout协议各方必须具备将经过身份验证的身份绑定到协议端点的良好基础，并且必须验证这些身份是否与其安全策略一致。
The OPES callout protocol MUST provide for message authentication, confidentiality, and integrity between the OPES processor and the callout server. It MUST provide mutual authentication. For this purpose, the callout protocol SHOULD use existing security mechanisms. The callout protocol specification is not required to specify the security mechanisms, but it MAY instead refer to a lower-level security protocol and discuss how its mechanisms are to be used with the callout protocol.
OPES调出协议必须在OPES处理器和调出服务器之间提供消息身份验证、机密性和完整性。它必须提供相互认证。为此，callout协议应使用现有的安全机制。不需要callout协议规范来指定安全机制，但它可以参考较低级别的安全协议，并讨论如何将其机制与callout协议一起使用。
If hop-by-hop encryption is a requirement for the content path, then this confidentiality MUST be extended to the communication between the OPES processor and the callout server. While it is recommended that the communication between the OPES processor and callout server always be encrypted, encryption MAY be optional if both the OPES processor and the callout server are co-located together in a single administrative domain with strong confidentiality guarantees.
如果内容路径需要逐跳加密，则必须将此保密性扩展到OPES处理器和调出服务器之间的通信。虽然建议始终加密OPES处理器和调出服务器之间的通信，但如果OPES处理器和调出服务器都位于一个具有强大保密保证的管理域中，则加密可能是可选的。
In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream.
为了最大限度地减少数据泄露，callout协议必须为每个加密的内容流使用不同的加密密钥。
The OPES callout protocol MUST operate securely across untrusted domains between the OPES processor and the callout server.
OPES callout协议必须在OPES处理器和callout服务器之间跨不受信任的域安全运行。
If the communication channels between the OPES processor and callout server cross outside of the organization which is responsible for the OPES services, then endpoint authentication and message protection (confidentiality and integrity) MUST be used.
如果OPES处理器和callout server之间的通信通道跨越负责OPES服务的组织之外，则必须使用端点身份验证和消息保护（机密性和完整性）。
Any communication carrying information relevant to privacy policies MUST protect the data using encryption.
任何携带与隐私政策相关信息的通信必须使用加密保护数据。
The security requirements for the OPES callout protocol are discussed in Section 5.
第5节讨论了OPES调出协议的安全要求。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 38352004年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[3] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] 《传输控制协议》，标准7，RFC 793，1981年9月。
[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.
[7] Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
Parts of this document are based on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon.
本文件的部分内容基于安卡·德拉辛斯基·赛勒、沃尔克·希尔特和拉玛·R·梅农之前的工作。
The authors would like to thank the participants of the OPES WG for their comments on this document.
作者要感谢OPES工作组的与会者对本文件的评论。
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US
美国新泽西州霍姆德尔克劳福德角路101号安德烈·贝克·朗讯科技公司，邮编：07733
EMail: abeck@bell-labs.com
EMail: abeck@bell-labs.com
Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US
Markus Hofmann-Lucent Technologies 4F-513室美国新泽西州霍姆德尔克劳福德角路101号，邮编07733
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
Hilarie Orman紫色条纹发育
EMail: ho@alum.mit.edu
URI: http://www.purplestreak.com
EMail: ho@alum.mit.edu
URI: http://www.purplestreak.com
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
雷纳尔多·佩诺北电网络公司美国马萨诸塞州比尔里卡科技园大道600号，邮编01821
EMail: rpenno@nortelnetworks.com
EMail: rpenno@nortelnetworks.com
Andreas Terzis Computer Science Department Johns Hopkins University 3400 North Charles Street, 224 NEB Baltimore, MD 21218
Andreas Terzis计算机科学系约翰霍普金斯大学3400北查尔斯街224号马里兰州巴尔的摩市21218
Phone: +1 410 516 5847
EMail: terzis@cs.jhu.edu
Phone: +1 410 516 5847
EMail: terzis@cs.jhu.edu
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。