[要約] RFC 3836は、Open Pluggable Edge Services（OPES）のコールアウトプロトコルに関する要件を定義しています。このRFCの目的は、OPESアーキテクチャにおけるコールアウトプロトコルの標準化と相互運用性の向上です。
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）The Internet Society（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（Open Pluggable Edge Services）コールアウトプロトコルが満たさなければならない要件を指定します。要件は、可能なプロトコル候補の評価、およびそのようなプロトコルの開発をガイドするのに役立つことを目的としています。
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
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
Open Pluggable Edge Services（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つ以上のリモートコールアウトサーバーと通信およびコラボレーションすることにより、サービス実行の責任を分配できます。[1]で説明されているように、OPESプロセッサは、Calloutプロトコルを使用してCalloutサーバーでサービスと通信し、呼び出されます。このドキュメントは、このようなプロトコルの要件を提示します。
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.
このドキュメントの要件は、機能要件、パフォーマンス要件、セキュリティ要件の3つのカテゴリに分かれています。各要件は、1つ以上のステートメントとして提示され、その後、必要に応じて簡単な説明資料が続きます。
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 Calloutプロトコルは、OPESプロセッサとCallout Server間の通信に順序付けられた信頼性を提供できる必要があります。さらに、コールアウトプロトコルは、順序付けられていない信頼性を提供できるはずです。
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 Calloutプロトコルは、RFC 2914 [4]の標準に一致する混雑回避が、OPESプロセッサとコールアウトサーバー間のすべての通信に適用されることを保証する必要があります。この目的のために、コールアウトプロトコルは、おそらく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 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 Calloutプロトコルは、部分的または完全なアプリケーションレベルのプロトコルメッセージ（またはその変更）を交換する目的で、OPESプロセッサとCallout ServerがCallOutトランザクションを実行できるようにする必要があります。より具体的には、Callout Protocolは、OPESプロセッサがPartialまたは完全なアプリケーションメッセージをCallout Serverに転送できるようにする必要があり、1つ以上のOPESサービスが転送されたアプリケーションメッセージ（またはその部分）を処理できるようにします。サービス操作の結果は、変更されたアプリケーションメッセージである場合があります。したがって、Callout Protocolは、Callout Serverが変更されたアプリケーションメッセージまたはOPESプロセッサへのアプリケーションメッセージの変更された部分を返すことを可能にする必要があります。さらに、Callout Protocolは、Callout ServerがCallout Transaction（たとえば、ステータスコードの形式）の結果を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.
Callout Transactionは、OpesプロセッサとCallout RequestとCallout Responseで構成されるCallout Serverの間のメッセージ交換として定義されます。両方のコールアウト要求とコールアウト応答の両方が、それぞれ1つ以上のコールアウトプロトコルメッセージ、つまり一連のプロトコルメッセージで構成される場合があります。コールアウトリクエストには、常に部分的または完全なアプリケーションメッセージが含まれている必要があります。コールアウト応答は、常にコールアウトトランザクションの結果を示す必要があります。Callout Responseには、変更されたアプリケーションメッセージが含まれる場合があります。
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 Calloutプロトコルは、コールアウトトランザクションのいずれかのエンドポイントがコールアウトトランザクションを終了して、対応するコールアウトエンドポイントによって完全に受信される前に、コールアウトトランザクションを終了するメカニズムも提供する必要があります。このようなメカニズムは、Callout Transactionの早期終了がアプリケーションメッセージデータの損失をもたらさないことを保証する必要があります。
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サービスをサポートするには、Callout Transactionの早期終了が必要です。これは、アプリケーションメッセージ全体を処理する前であっても終了する場合があります。たとえば、コンテンツ分析サービスは、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 Calloutプロトコルは、OpesプロセッサとCallout ServerがCallout Connectionを介して複数のCalloutトランザクションを実行できるようにする必要があります。さらに、コールアウトプロトコルは、コールアウトトランザクションをコールアウト接続に関連付ける方法を提供する必要があります。Callout接続は、OPESプロセッサとCalloutサーバーの間のアプリケーション層の論理接続として定義されます。コールアウト接続には、接続エンドポイントのフェールオーバー動作を制御するパラメーターなど、特定のパラメーターが関連付けられている場合があります。コールアウト接続固有のパラメーターは、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プロトコルは、多重化されたコールアウト接続間の公平性を保証するフロー制御メカニズムが適用される場合、単一の輸送層接続上の複数のコールアウト接続をマルチプレックスすることを選択できます。
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 Calloutプロトコルは、Callout Connectionを介した非同期メッセージ交換をサポートする必要があります。
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プロセッサとコールアウトサーバーでの非同期処理を許可するには、リクエストの発行を応答処理から分離することができなければなりません。したがって、プロトコルは、複数の未解決のコールアウトリクエストを許可し、コールアウト応答をコールアウトリクエストと相関させる方法を提供する必要があります。
Additionally, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request.
さらに、Callout Protocolは、リクエスト全体を受信する前に、Callout ServerがCalloutリクエストに応答できるようにする必要があります。
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サーバーにアプリケーションメッセージを転送できるようにする必要があります。コールアウトプロトコルは、受信コールアウトサーバーが断片化されたアプリケーションメッセージを再組み立てできるようにする必要があります。
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.
同様に、Callout Protocolは、Callout Serverが一連の小さなメッセージフラグメントでOPESプロセッサにアプリケーションメッセージを返すことを可能にする必要があります。Callout Protocolは、受信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 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.
データパスで使用されるアプリケーション層プロトコルに応じて、アプリケーションメッセージのサイズが非常に大きい場合（たとえば、オーディオ/ビデオストリームの場合）または未知のサイズです。どちらの場合も、OPESプロセッサは、データ消費者の長い遅延を回避するために、アプリケーションメッセージ全体を受信する前にCallout Transactionを開始する必要があります。したがって、OPESプロセッサは、データプロバイダーまたは消費者から受信するため、アプリケーションメッセージのフラグメントまたはチャンクをCalloutサーバーに転送できる必要があります。同様に、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コールアウトプロトコルが単一の輸送層接続に渡る複数のコールアウト接続をマルチプレックスするためにフロー制御メカニズムを提供する場合、アプリケーションメッセージセグメンテーションも必要です（セクション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 Protocolは、既存のCallout接続またはOPESプロセッサとCallout Serverの間の個別の接続を介して、キープアライブメッセージが交換されることを指定する場合があります。コールアウトプロトコルは、キープアライブメカニズムの使用がオプションであることも指定する場合があります。
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.
Callout Serverの障害を検出すると、OPESプロセッサは、将来のCallout Transactionがアプリケーションメッセージデータの損失をもたらさないように、スタンバイコールアウトサーバーとのコールアウト接続を確立できるようにする場合があります。OPESプロセッサの障害の検出により、Calloutサーバーは、他の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プロセッサとコールアウトサーバーの間のパスに1つ以上のNATデバイスが存在することにより、その動作を侵害しないでください。
The OPES callout protocol MUST allow an OPES processor to simultaneously communicate with more than one callout server.
OPES Calloutプロトコルは、OPESプロセッサが複数のCalloutサーバーと同時に通信することを許可する必要があります。
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サービスは異なるCalloutサーバーによってホストされる可能性があります。したがって、OPESプロセッサは、複数のCalloutサーバーと通信する必要がある可能性があります。プロトコル設計により、OPESプロセッサがそうすることを可能にする必要があります。
The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES processor.
Opes Calloutプロトコルは、Callout Serverが複数のOPESプロセッサと同時に通信することを許可する必要があります。
The protocol design MUST support a scenario in which multiple OPES processors use the services of a single callout server.
プロトコル設計は、複数のOPESプロセッサが単一のCalloutサーバーのサービスを使用するシナリオをサポートする必要があります。
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プロトコルは、アプリケーションプロトコルに依存しないものである必要があります。つまり、データプロバイダーとデータ消費者の間のデータパスで使用されるアプリケーション層プロトコルの特性について仮定を立てるべきではありません。少なくとも、コールアウトプロトコルは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 Calloutプロトコルを使用できることが望ましいでしょう。
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 Calloutプロトコルは、OPESプロセッサとCallout Serverの間の機能の交渉とCallout Connectionパラメーターをサポートする必要があります。これは、OPESプロセッサとCallout Serverが機能と好みを交換できる必要があることを意味します。その後、彼らは、将来のコールアウト接続/トランザクションに使用される機能とパラメーターに同意する2つのエンドポイントのいずれかで終了する決定論的ネゴシエーションプロセスに従事することができなければなりません。
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プロセッサとコールアウトサーバーの間でネゴシエートできる機能とパラメーターには、コールアウトプロトコルバージョン、フェイルオーバー動作、キープアライブメッセージのハートビートレート、セキュリティ関連のパラメーターなどが含まれます。
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.
たとえば、コールアウト接続が1つ以上の特定のOPESサービスに関連付けられている場合、Callout Connectionパラメーターは、OPES Callout Servicesの特性にも関係する場合があります。たとえば、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.
コールアウト接続パラメーターは、対応するコールアウト接続でコールアウトトランザクションが実行される前に、コールアウトごとの接続ごとにネゴシエートする必要があります。フェールオーバー動作などの他のパラメーターと機能は、コールアウト接続とは独立して2つのエンドポイント間で交渉できます。
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.
Calloutプロトコルの当事者は、Callout Connectionsを使用して、すべてまたは一部の機能とパラメーターをネゴシエートする場合があります。あるいは、この目的のために別の制御接続を使用することもできます。
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 Calloutプロトコルは、特定のCalloutトランザクションのエンドポイントのメカニズムを提供し、Callout Requests and ResponsesにMetadataとOPESプロセッサまたはCallout Serverの指示を含める必要があります。
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.
具体的には、Callout Protocolは、OPESプロセッサがCalloutリクエストに転送されたアプリケーションメッセージに関する情報を含めることを可能にする必要があります。転送されたアプリケーションメッセージのタイプを指定したり、アプリケーションメッセージのどの部分がCalloutサーバーに転送されたりするかを指定するため。同様に、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プロセッサには、指定された順序で転送されたアプリケーションメッセージで実行される1つ以上のユニークに指定されたOPESサービスの順序付けられたリストをさらに含めることができなければなりません。ただし、Callout ProtocolはCallout Connectionsを特定のOPESサービスに関連付けることも選択する可能性があるため、OPESサービスを1人あたりの取引ベースで特定する必要はない場合があります。
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 Calloutプロトコルは、Callout ServerがOPESプロセッサにCallout Responseのカキアビリティを示すことを許可する必要があります。これは、Callout Responseが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サーバーは、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コールアウトプロトコルは、[1]および[3]にレイアウトされているように、OPESアーキテクチャのトレース要件をOPESプロセッサに遵守することも許可する必要があります。これは、Callout ProtocolがCallout Serverが転送されたアプリケーションメッセージで実行された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 Transactionsは、データパスでのアプリケーションプロトコルトランザクションに遅延を追加するため、コールアウトプロトコル効率は全体的なパフォーマンスに不可欠です。
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 Serverの間で、誤った設定または審議的なインサイダー攻撃を通じて、EndPointのセキュリティとプライバシーポリシーに違反して、Callout Serverの間で機密情報が伝わる場合があります。強力な認証、メッセージ暗号化、および整合性チェックを使用することにより、この脅威は、より小さなインサイダーおよび/またはオペレーター構成エラーに最小限に抑えることができます。
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プロセッサとCalloutサーバーには、通信する当事者を制限し、エンドポイントやその他のデータ（エンドジャーポリシーなど）のアイデンティティに基づいて使用する保護を決定する強制力のあるポリシーが必要です。ポリシーを実施するには、暗号化方法を使用してコールアウトプロトコルエンドポイントを認証できる必要があります。
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.
コールアウトプロトコルの当事者は、プロトコルエンドポイントに認証されたアイデンティティをバインディングするための健全な基盤を持つ必要があり、これらのアイデンティティがセキュリティポリシーと一致していることを確認する必要があります。
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 Calloutプロトコルは、OPESプロセッサとCallout Serverの間のメッセージ認証、機密性、および整合性を提供する必要があります。相互認証を提供する必要があります。この目的のために、コールアウトプロトコルは既存のセキュリティメカニズムを使用する必要があります。セキュリティメカニズムを指定するためにコールアウトプロトコルの仕様は必要ありませんが、代わりに低レベルのセキュリティプロトコルを参照し、そのメカニズムがコールアウトプロトコルでどのように使用されるかを議論する場合があります。
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プロセッサとCalloutサーバーの間の通信に拡張する必要があります。OPESプロセッサとコールアウトサーバー間の通信を常に暗号化することをお勧めしますが、OPESプロセッサとコールアウトサーバーの両方が、強力な機密性保証を持つ単一の管理ドメインで共同で共同住宅されている場合、暗号化がオプションになる場合があります。
In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream.
データ露出を最小限に抑えるために、Callout Protocolは、暗号化されたコンテンツストリームごとに異なる暗号化キーを使用する必要があります。
The OPES callout protocol MUST operate securely across untrusted domains between the OPES processor and the callout server.
OPES Calloutプロトコルは、OPESプロセッサとCallout Serverの間の信頼できないドメイン全体で安全に動作する必要があります。
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.
OPESコールアウトプロトコルのセキュリティ要件については、セクション5で説明します。
[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、「Open Pluggable Edge Services（OPES）のアーキテクチャ」、RFC 3835、2004年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。and L. Daigle、「Open Pluggable Edge Servicesの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。and L. Daigle、「Open Pluggable Edge Servicesの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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] Postel、J。、「トランスミッションコントロールプロトコル」、STD 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 2960、2000年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 3550、2003年7月。
Parts of this document are based on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon.
このドキュメントの一部は、Anca Dracinschi Sailer、Volker Hilt、およびRama R. Menonによる以前の研究に基づいています。
The authors would like to thank the participants of the OPES WG for their comments on this document.
著者は、この文書に関するコメントについてOPES WGの参加者に感謝したいと思います。
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel、NJ 07733 US
EMail: abeck@bell-labs.com
Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US
Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel、NJ 07733 US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
ヒラリーオーマンパープルストリーク開発
EMail: ho@alum.mit.edu
URI: http://www.purplestreak.com
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica、MA 01821 US
EMail: rpenno@nortelnetworks.com
Andreas Terzis Computer Science Department Johns Hopkins University 3400 North Charles Street, 224 NEB Baltimore, MD 21218
アンドレアス・テルツィスコンピューターサイエンス部門ジョンズホプキンス大学3400ノースチャールズストリート、224ネブボルチモア、メリーランド州21218
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。