Network Working Group L-N. Hamer
Request for Comments: 3521 B. Gage
Category: Informational Nortel Networks
H. Shieh
AT&T Wireless
April 2003
Framework for Session Set-up with Media Authorization
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.
マルチメディアストリームを確立することは、エンドツーエンドのQoS、使用するリソースのネットワークリソースの使用量と正確な会計処理の許可のためのアカウント要件を考慮する必要があります。セットアップセッション中に、ポリシーがメディアストリームを要求しているホストのために確立されたサービスプロファイルの範囲内で嘘を要求されていることを確認するために実施することができます。同様に、ホスト要求リソースがパケットフローに関する特定のQoSを提供する場合、ポリシーは必要なリソースを要求しているホストのために確立されたリソースプロファイルの範囲内にあることを確実にするために実施されてもよいです。
To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session.
不正行為を防止し、正確な課金を確実にするために、この文書は、セッションのために要求されたQoSを提供するために使用されるリソースは、インライン要求（および承認）メディアストリームとであることを確認するために必要な結合を提供する様々なシナリオおよびメカニズムを説明しています。
Table of Contents
目次
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Definition of terms.............................................4
4. The Coupled Model...............................................5
4.1 Coupled Model Message Flows...............................6
4.2 Coupled Model Authorization Token.........................8
4.3 Coupled Model Protocol Impacts............................8
5. The Associated Model <<using One Policy Server>>................8
5.1 Associated Model Message Flows
<<using One Policy Server>>...............................9
5.2 Associated Model Authorization Token
<<using One Policy Server>>..............................11
5.3 Associated Model Protocol Impacts
<<using One Policy Server>>..............................11
5.4 Associated Model Network Impacts
<<using One Policy Server>>..............................12
6. The Associated Model <<using Two Policy Servers>>..............12
6.1 Associated Model Message Flows
<<using Two Policy Servers>>.............................13
6.2 Associated Model Authorization Token
<<using Two Policy Servers>>.............................15
6.3 Associated Model Protocol Impacts
<<using Two Policy Servers>>.............................16
7. The Non-Associated Model........................................16
7.1 Non-Associated Model Message Flow........................17
7.2 Non-Associated Model Authorization Token.................19
7.3 Non-Associated Model Protocol Impacts....................19
8. Conclusions....................................................20
9. Security Considerations........................................21
10. Normative References...........................................22
11. Informative References.........................................23
12. Acknowledgments................................................23
13. Authors' Addresses.............................................24
14. Full Copyright Statement.......................................25
Various mechanisms have been defined through which end hosts can use a session management protocol (e.g., SIP [6]) to indicate that QoS requirements must be met in order to successfully set up a session. However, a separate protocol (e.g., RSVP [7]) is used to request the resources required to meet the end-to-end QoS of the media stream. To prevent fraud and to ensure accurate billing, some linkage is required to verify that the resources being used to provide the requested QoS are in-line with the media streams requested (and authorized) for the session.
様々な機構がエンドホストは、セッション管理プロトコルを使用することができ、それを通して定義されている（例えば、SIPは、[6]）QoS要件が正常にセッションをセットアップするために満たされなければならないことを示します。しかし、別のプロトコル（例えば、RSVP [7]）メディアストリームのエンドツーエンドのQoSを満たすために必要なリソースを要求するために使用されます。不正行為を防止するためには、正確な課金を確実にするために、いくつかの結合が要求されたQoSを提供するために使用されているリソースは、インライン要求（および許可）メディアストリームであることを確認するために必要とされるセッションのために。
This document describes such a linkage through use of a "token" that provides capabilities similar to that of a gate in [12] and of a ticket in the push model of [10]. The token is generated by a policy server (or a session management server) and is transparently relayed through the end host to the edge router where it is used as part of the policy-controlled flow admission process.
この文書では、[12]および[10]のプッシュモデルにおけるチケットのゲートと同等の機能を提供する「トークン」の使用によって、このような結合を記載しています。トークンは、ポリシーサーバ（またはセッション管理サーバ）によって生成され、透過的に、それがポリシー制御フローアドミッションプロセスの一部として使用されているエッジルータにエンドホストを介して中継されます。
In some environments, authorization of media streams can exploit the fact that pre-established relationships exist between elements of the network (e.g., session management servers, edge routers, policy servers and end hosts). Pre-established relationships assume that the different network elements are configured with the identities of the other network elements and, if necessary, are configured with security keys, etc. required to establish a trust relationship. In other environments, however, such pre-established relationships may not exist either due to the complexity of creating these associations a priori (e.g., in a network with many elements), or due to the different business entities involved (e.g., service provider and access provider), or due to the dynamic nature of these associations (e.g., in a mobile environment).
いくつかの環境では、メディアストリームの許可は、予め確立された関係は、ネットワークの構成要素（例えば、セッション管理サーバ、エッジルータ、ポリシーサーバとエンドホスト）の間に存在するという事実を利用することができます。事前に確立された関係は、異なるネットワーク要素は、他のネットワーク要素のアイデンティティで構成されており、必要に応じて、信頼関係を確立するために必要などのセキュリティキーで構成されていることを前提としています。他の環境では、しかし、そのような事前に確立された関係が存在しない可能性がいずれかのこれらの関連付けを作成する複雑さのために先験的（例えば、多くの要素を持つネットワーク内）、またはによる関与異なるビジネスエンティティ（例えば、サービスプロバイダとアクセス・プロバイダー）、またはモバイル環境におけるこれらの団体（例えば、の動的な性質による）。
In this document, we describe these various scenarios and the mechanisms used for exchanging information between network elements in order to authorize the use of resources for a service and to coordinate actions between the session and resource management entities. Specific extensions to session management protocols (e.g., SIP [6], H.323), to resource reservation protocols (e.g., RSVP [4], YESSIR) and to policy management protocols (e.g., COPS-PR [9], COPS-RSVP [3]) required to realize these scenarios and mechanisms are beyond the scope of this document.
この文書では、我々は、これらの様々なシナリオおよびサービスのためのリソースの使用を許可し、セッションおよびリソース管理エンティティとの間のアクションを調整するために、ネットワーク要素間で情報を交換するために使用されるメカニズムを説明しています。特定のセッション管理プロトコルの拡張（例えば、SIP [6]、H.323）、予約プロトコルをリソースに（例えば、RSVP [4]、YESSIR）およびポリシー管理プロトコル（例えば、COPS-PR〜[9]、COPS- [3]）これらのシナリオおよびメカニズムを実現するために必要なRSVPは、この文書の範囲を超えています。
For clarity, this document will illustrate the media authorization concepts using SIP for session signalling, RSVP for resource reservation and COPS for interaction with the policy servers. Note, however, that the framework could be applied to a multimedia services scenario using different signalling protocols.
明確にするために、この文書は、セッションシグナリング、ポリシーサーバとの相互作用のためのリソース予約およびCOPSのためのRSVPのためのSIPを使用してメディアの認可の概念を説明します。フレームワークは、異なるシグナリングプロトコルを使用してマルチメディアサービスシナリオに適用することができることは、注意してください。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
Figure 1 introduces a generic model for session establishment, QoS and policy enforcement.
図1は、セッション確立、QoSおよびポリシーの施行のための一般的なモデルを紹介します。
+-------------------------------------+ +---+
| SCD - Service Control Domain | | |
| +-----------------------+ +--------+| | I |
| |Session management | |Policy || | n |
| |server | |Server || | t |
| | +---------+ +------+ | | +----+||<->| e |
| | |SIP Proxy| |PEP |<-|-|->|PDP ||| | r |
| | +---------+ +------+ | | +----+|| | - |
| +-----------------------+ +--------+| | c |
| | | o |
+-------------------------------------+ | n |
| n |
+-------------------------------------+ | e |
| RCD - Resource Control Domain | | c |
| | | t |
| | | i |
| +------------+ +-------------+ | | n |
+----------+ | |Edge Router | |Policy Server| | | g |
| End | | | | | | | | |
| Host | | |+----------+| |+----------+ | | | N |
|+--------+| | ||RSVP Agent|| ||PDP | | | | e |
||RSVP ||<->| |+----------+|<-->|+----------+ | |<->| t |
||Client || | |+----------+| | | | | w |
|+--------+| | || PEP || | | | | o |
||SIP User|| | |+----------+| | | | | r |
||Agent || | +------------+ +-------------+ | | k |
|+--------+| | | | |
+----------+ +-------------------------------------+ +---+
Figure 1: Generic media authorization network model
図1：一般的なメディア認証ネットワークモデル
EH - End Host: The End Host is a device used by a subscriber to access network services. The End Host includes a client for requesting network services (e.g., through SIP) and a client for requesting network resources (e.g., through RSVP).
EH - エンドホスト：エンドホストは、ネットワークサービスにアクセスするために、加入者が使用するデバイスです。エンドホストは、（SIP経由例えば、）ネットワークサービスを要求するため、クライアントと（RSVPを通じて、例えば）ネットワークリソースを要求するクライアントが含まれています。
ER - Edge Router: The Edge Router is a network element connecting the end host to the rest of the Resource Control Domain. The Edge Router contains a PEP to enforce policies related to resource usage in the Resource Control Domain by the End Host. It also contains a signalling agent (e.g., for RSVP) for handling resource reservation requests from the End Host.
ER - エッジルータ：エッジルータは、リソース制御ドメインの残りの部分へのエンドホストを接続するネットワーク要素です。エッジルータは、エンドホストによるリソース制御ドメインでの使用をリソースに関連するポリシーを適用するためにPEPが含まれています。また、エンドホストからのリソース予約リクエストを処理するための（RSVP用など、）シグナル伝達剤を含有します。
PDP - Policy Decision Point: The PDP is a logical entity located in the Policy Server that is responsible for authorizing or denying access to services and/or resources.
PDP - ポリシー決定ポイント：PDPは、サービスおよび/またはリソースへのアクセスを許可または拒否する責任があるポリシーサーバにある論理エンティティです。
PEP - Policy Enforcement Point: The PEP is a logical entity that enforces policy decisions made by the PDP. Note that other PEPs may reside in other network elements not shown in the model of Figure 1, however they will not be discussed in this document.
PEP - ポリシー実行ポイント：PEPは、PDPによって行われた政策決定を強制する論理エンティティです。他のPEPは、図1のモデルには示されていない他のネットワーク要素内に存在してもよいことに留意されたい、しかしながら、それらは本書では説明しません。
PS - Policy Server: The Policy Server is a network element that includes a PDP. Note that there may be a PS in the Service Control Domain to control use of services and there may be a separate PS in the Resource Control Domain to control use of resources along the packet forwarding path. Note also that network topology may require multiple Policy Servers within either Domain, however they provide consistent policy decisions to offer the appearance of a single PDP in each Domain.
PS - ポリシーサーバ：ポリシーサーバがPDPを含むネットワーク要素です。サービスの利用を制御するために、サービス制御ドメインでPSがあるかもしれないと、パケットの転送パスに沿ってリソースの使用を制御するために、リソース制御ドメイン内の別々のPSがあるかもしれないことに注意してください。しかし彼らは、各ドメイン内の単一のPDPの外観を提供するために一貫性のある政策決定を提供し、そのネットワークトポロジがいずれかのドメイン内の複数のポリシーサーバを必要とするかもしれないにも注意してください。
RCD - Resource Control Domain: The Resource Control Domain is a logical grouping of elements that provide connectivity along the packet forwarding paths to and from an End Host. The RCD contains ER and PS entities whose responsibilities include management of resources along the packet forwarding paths. Note that there may be one or more RCDs within an autonomous domain.
RCD - リソース制御ドメイン：資源制御ドメインおよびエンドホストからパケットの転送パスに沿って接続性を提供する要素の論理グループです。 RCDは、その責任パケット転送経路に沿っ資源の管理などがERおよびPSのエンティティが含まれています。自律ドメイン内の1つまたは複数のRCDSがあるかもしれないことに注意してください。
SCD - Service Control Domain: The Service Control Domain is a logical grouping of elements that offer applications and content to subscribers of their services. The Session Management Server resides in the SCD along with a PS. Note that there may be one or more SCDs within an autonomous domain.
SCD - サービスコントロールドメイン：サービスコントロールドメインは、そのサービスの加入者にアプリケーションやコンテンツを提供する要素の論理グループです。セッション管理サーバは、PSと一緒にSCDに存在します。自律ドメイン内の1つのまたは複数のSCDがあるかもしれないことに注意してください。
SMS - Session Management Server: The Session Management Server is a network element providing session management services (e.g., telephony call control). The Session Management Server contains a PEP to enforce policies related to use of services by the End Host. It also contains a signalling agent or proxy (e.g., for SIP) for handling service requests from the End Host.
SMS - セッション管理サーバ：セッション管理サーバは、セッション管理サービスを提供するネットワーク要素である（例えば、テレフォニーコール制御）。セッション管理サーバは、エンドホストでのサービスの使用に関連するポリシーを適用するためにPEPが含まれています。また、エンドホストからのサービス要求を処理するための（SIP用など、）シグナリング・エージェントまたはプロキシが含まれています。
In some environments, a pre-established trust relationship exists between elements of the network (e.g., session management servers, edge routers, policy servers and end hosts). We refer to this as the "coupled model", indicating the tight relationship between entities that is presumed. The key aspects of this scenario are the following:
いくつかの環境では、事前に確立された信頼関係は、ネットワークの構成要素（例えば、セッション管理サーバ、エッジルータ、ポリシーサーバとエンドホスト）との間に存在します。私たちは、推定されるエンティティ間の緊密な関係を示す、「結合モデル」としてこれを参照してください。このシナリオの重要な側面は、次のとおりです。
- Policy decisions, including media authorization, are made by a single Policy Server.
- メディアの認可を含む政策決定は、単一のポリシーサーバによって作られています。
- The Edge Router, Session Management Servers and Policy Server involved in establishing the session are known a priori. For example, the End Host may be configured to use a Session Management Server associated with the Edge Router to which the EH is connected.
- エッジルータでは、セッションの確立に関与セッション管理サーバとポリシーサーバは、事前に知られています。例えば、エンドホストは、EHが接続されているエッジルータに関連付けられたセッション管理サーバを使用するように構成することができます。
- There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS.
- SMSとPS間とERとPS間で事前に定義された信頼関係があります。
+--------+
+------+ | |
| | 1 +--------------------+ 2 | |
| |-------->| Session Management |----->| |
| |<--------| Server |<-----| |
| | 4 +--------------------+ 3 | |
| End | | Policy |
| Host | | Server |
| | | |
| | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| |
| |<--------| Router |<-----| |
| | 8 +--------------------+ 7 | |
+------+ | |
+--------+
Figure 2: The Coupled Model
図2：結合モデル
In this model, it is assumed that there is one Policy Server serving both the Service Control and Resource Control Domains and that there are pre-defined trust relationships between the PS and SMS and between the PS and ER. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、サービスコントロールおよびリソース制御ドメインの両方にサービスを提供する1台のポリシーサーバがあることを前提とし、PSとSMSの間とPSとERとの間に事前定義された信頼関係が存在していることです。以下に説明するように、これらのエンティティ間の通信は、次に、可能です。唯一の起点側の流れが簡潔に記載されています。同じ概念は、終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1.エンドホストは、とりわけ示すセッション管理サーバに（例えば、SIP INVITEを）セッション設定要求を発行し、メディアストリームは、セッションで使用されます。このステップの一環として、エンドホストは、セッション管理サーバに自身を認証することがあります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the session set-up request should be allowed to proceed.
おそらくメディアの交渉を待って完了するストリーム2.セッション管理サーバ、セッション設定要求をさせるべきであるならば、決定するために、ポリシーサーバへの政策決定の要求（例えば、REQをCOPS）を送ります続行。
3. The Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the Policy Server to identify the session and the media it has authorized.
3.ポリシーサーバは、意思決定（例えば、COPS DEC）セッション管理サーバには、おそらくメディアのパラメータを変更した後に使用されることを送信します。この応答に含まれ、その後のセッションと、それが承認したメディアを識別するために、ポリシーサーバで使用できる「トークン」です。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the Policy Server.
4.セッション管理サーバは、そのセッションのセットアップが完了したか、進行中であることを示すエンドホスト（例えば、SIP 200または183）への応答を送信します。この応答に含まポリシーサーバからトークンと一緒に交渉したメディアの説明です。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the Policy Server provided via the Session Management Server.
5.エンドホストは、メディアストリームのために必要なQoSを提供するために必要なリソースを予約するための要求（例えば、RSVPのPATH）を発行します。このリクエストに含まれるセッション管理サーバを介して提供ポリシーサーバからトークンです。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the Policy Server provided by the End Host. The Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server.
前記エッジルータは、予約要求をインターセプトし、リソース予約要求の続行を許可されるべきかどうかを決定するために、ポリシーサーバにポリシー決定要求（例えば、REQをCOPS）を送信します。このリクエストに含まれるエンドホストが提供するポリシーサーバからトークンです。ポリシーサーバは、以前のセッション管理サーバーに提供されるメディアの権限を持つリソースの要求を相関させるために、このトークンを使用しています。
7. The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
7.ポリシーサーバは、決定（例えば、COPS DEC）エッジルータには、おそらくリソースのパラメータを変更した後に予約することを送ります。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing.
8.エッジルータは、おそらく完了するためのリソースのためのエンドツーエンドの交渉を待って、そのリソース予約が完了したか、進んで示すエンドホスト（例えば、RSVPのRESV）に応答を送信します。
In the Coupled Model, the Policy Server is the only network entity that needs to interpret the contents of the token. Therefore, in this model, the contents of the token are implementation dependent. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the token is preserved in transit; the exact mechanisms to be used are also implementation dependent.
結合モデルでは、ポリシーサーバは、トークンの内容を解釈する必要がある唯一のネットワークエンティティです。したがって、このモデルでは、トークンの内容は実装に依存しています。エンドホストが信頼できないことを想定しているため、ポリシーサーバは、トークンの整合性が輸送中に保存されていることを確保するための措置を取るべきです。使用する正確な機構はまた、実装依存です。
The use of a media authorization token in the Coupled Model requires the addition of new fields to several protocols:
結合モデルでメディア許可トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure (if any) of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトを透過的にエッジルータにエンドホストからトークンを輸送するためにリソース予約プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造（もしあれば）は、リソース予約プロトコルに不透明であるべきです。例えば、これは、[8]で定義されたポリシーデータオブジェクトにRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transparently transport the token from the Policy Server to the Session Management Server and from the Edge Router to the Policy Server. The content and internal structure (if any) of this object SHOULD be opaque to the policy management protocol. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドまたはオブジェクトを透過的にセッション管理サーバへとポリシーサーバへのエッジルータからポリシーサーバからトークンを輸送するために、ポリシー管理プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造（もしあれば）は、ポリシー管理プロトコルに不透明であるべきです。例えば、これは、[8]で定義されたポリシーデータオブジェクトにCOPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure (if any) of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。新しいプロトコルフィールドやオブジェクトは、透過的にエンドホストにセッション管理サーバからメディア認証トークンを転送するためにセッション管理プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造（もしあれば）は、セッション管理プロトコル（例えば、SIP [6]）に不透明であるべきです。
In this scenario, there are multiple instances of the Session Management Servers, Edge Routers and Policy Servers. This leads to a network of sufficient complexity that it precludes distributing knowledge of network topology to all network entities. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバ、エッジルータとポリシーサーバの複数のインスタンスがあります。これは、すべてのネットワーク・エンティティにネットワークトポロジの知識を配布不可能に十分な複雑さのネットワークにつながります。このシナリオの重要な側面は、次のとおりです。
- Policy decisions, including media authorization, are made by the same Policy Server for both the Session Management Server and the Edge Router. However, the Policy Server may change on a per-transaction basis, i.e., on a per policy request basis.
- メディアの認可を含む政策決定は、セッション管理サーバとエッジルータの両方に同じポリシーサーバによって作られています。しかし、ポリシーサーバは、ポリシーごとの要求に基づき、すなわち、トランザクションごとに変更されることがあります。
- The Edge Router, Session Management Server and Policy Server involved in establishing the session are not known a priori. For example, the End Host may be dynamically configured to use one of a pool of Session Management Servers and each of the Session Management Servers may be statically configured to use one of a pool of Policy Servers.
- エッジルータ、セッション管理サーバとポリシーサーバが事前に知られていないセッションの確立に関与します。例えば、エンドホストは、動的セッション管理サーバーのプールのいずれかを使用するように構成することができるとのセッション管理サーバのそれぞれは、静的ポリシーサーバのプールのいずれかを使用するように構成することができます。
In another example, the End Host may be mobile and continually changing the Edge Router that its point of attachment uses to communicate with the rest of the network.
別の例では、エンドホストは、移動することが継続的アタッチメントのそのポイントがネットワークの残りと通信するために使用するエッジルータを変更してもよいです。
- There are pre-defined trust relationships between the SMS and the PS and between the ER and the PS.
- SMSとPS間とERとPS間で事前に定義された信頼関係があります。
+---------------------+ +---------+
| SMS 'n' |<-->| PS 'm' |
+---------------------+ +--------+ |
+------+ : : : | | |
| | 1 +--------------------+ 2 | | |
| |-------->| Session Management |----->| | |
| |<--------| Server 1 |<-----| | |
| | 4 +--------------------+ 3 | | |
| End | | Policy | |
| Host | +--------------------+ | Server | |
| | | ER 'n' | | 1 | |
| | 5 +-+------------------+ | | | |
| |-------->| Edge |-+ 6 | | |
| |<--------| Router |----->| | |
| | 8 +--------------------+ 7 | | |
+------+ <-----| |-+
+--------+
Figure 3: The Associated Model using One Policy Server
図3：関連するモデルの一つポリシーサーバを使用して
In this model, it is assumed that a Policy Server can make decisions for both the Service Control and Resource Control Domains and that there are pre-defined trust relationships between the PS and SMS and between the PS and ER. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、ポリシーサーバは、サービス制御およびリソース制御ドメインの両方のための意思決定を行い、PSとSMSの間とPSとERとの間に事前定義された信頼関係があることができるものとします。以下に説明するように、これらのエンティティ間の通信は、次に、可能です。唯一の起点側の流れが簡潔に記載されています。同じ概念は、終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1.エンドホストは、とりわけ示すセッション管理サーバに（例えば、SIP INVITEを）セッション設定要求を発行し、メディアストリームは、セッションで使用されます。このステップの一環として、エンドホストは、セッション管理サーバに自身を認証することがあります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the Policy Server in order to determine if the session set-up request should be allowed to proceed.
おそらくメディアの交渉を待って完了するストリーム2.セッション管理サーバ、セッション設定要求をさせるべきであるならば、決定するために、ポリシーサーバへの政策決定の要求（例えば、REQをCOPS）を送ります続行。
3. The Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the Policy Server to identify the session and the media it has authorized.
3.ポリシーサーバは、意思決定（例えば、COPS DEC）セッション管理サーバには、おそらくメディアのパラメータを変更した後に使用されることを送信します。この応答に含まれ、その後のセッションと、それが承認したメディアを識別するために、ポリシーサーバで使用できる「トークン」です。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the Policy Server.
4.セッション管理サーバは、そのセッションのセットアップが完了したか、進行中であることを示すエンドホスト（例えば、SIP 200または183）への応答を送信します。この応答に含まポリシーサーバからトークンと一緒に交渉したメディアの説明です。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the Policy Server provided via the Session Management Server.
5.エンドホストは、メディアストリームのために必要なQoSを提供するために必要なリソースを予約するための要求（例えば、RSVPのPATH）を発行します。このリクエストに含まれるセッション管理サーバを介して提供ポリシーサーバからトークンです。
6. The Edge Router intercepts the reservation request and inspects the token to learn which Policy Server authorized the media. It then sends a policy decision request to that Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the Policy Server provided by the End Host. The Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server.
6.エッジルータは、予約要求をインターセプトし、ポリシーサーバはメディアを認可している学ぶためにトークンを検査します。これは、リソース予約要求の続行を許可するかどうかを決定するために、そのポリシーサーバにポリシー決定要求を送信します。このリクエストに含まれるエンドホストが提供するポリシーサーバからトークンです。ポリシーサーバは、以前のセッション管理サーバーに提供されるメディアの権限を持つリソースの要求を相関させるために、このトークンを使用しています。
7. The Policy Server sends a decision to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
7.ポリシーサーバは、おそらく予約するリソースのパラメータを変更した後、エッジルータに決定を送信します。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing.
8.エッジルータは、おそらく完了するためのリソースのためのエンドツーエンドの交渉を待って、そのリソース予約が完了したか、進んで示すエンドホスト（例えば、RSVPのRESV）に応答を送信します。
Since the ER does not know which SMS and PS are involved in session establishment, the token MUST include:
ERは、セッションの確立に関与しているSMSおよびPS知らないので、トークンが含まれている必要があります
- A correlation identifier. This is information that the Policy Server can use to correlate the resource reservation request with the media authorized during session set up. The Policy Server is the only network entity that needs to interpret the contents of the correlation identifier therefore, in this model, the contents of the correlation identifier are implementation dependent. Since the End Host is assumed to be untrusted, the Policy Server SHOULD take measures to ensure that the integrity of the correlation identifier is preserved in transit; the exact mechanisms to be used are also implementation dependent.
- 相関識別子。これは、ポリシーサーバのセットアップセッション中に許可メディアとのリソース予約要求を相関させるために使用できる情報です。ポリシーサーバは、このモデルでは、相関識別子の内容は実装に依存しているため、相関識別子の内容を解釈する必要がある唯一のネットワークエンティティです。エンドホストが信頼できないことを想定しているため、ポリシーサーバは、相関識別子の整合性が輸送中に保存されていることを確保するための措置を取るべきです。使用する正確な機構はまた、実装依存です。
- The identity of the authorizing entity. This information is used by the Edge Router to determine which Policy Server should be used to solicit resource policy decisions.
- 認可実体のアイデンティティ。この情報は、ポリシーサーバはリソースの政策決定を勧誘するために使用されるべきかを決定するために、エッジルータで使用されています。
In some environments, an Edge Router may have no means for determining if the identity refers to a legitimate Policy Server within its domain. In order to protect against redirection of authorization requests to a bogus authorizing entity, the token SHOULD also include:
アイデンティティがそのドメイン内の正当なポリシーサーバを参照している場合、一部の環境では、エッジルータが決定するための手段を持たないことがあります。偽の認可実体への認証要求のリダイレクトから保護するために、トークンも含める必要があります。
- Authentication data. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the Edge Router is beyond the scope of this document.
- 認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールド上で計算されます。エッジルータで使用されるメカニズムはこのドキュメントの範囲を超えています。
The detailed semantics of an authorization token are defined in [4].
許可トークンの詳細な意味は、[4]で定義されています。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
関連するモデルのこのバージョンでメディア許可トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object MUST be specified so that the Edge Router can distinguish between the elements of the token described in Section 5.2. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトを透過的にエッジルータにエンドホストからトークンを輸送するためにリソース予約プロトコルに加えなければなりません。エッジルータは、セクション5.2で説明トークンの要素間を区別することができるように、このオブジェクトの内容及び内部構造を指定しなければなりません。例えば、これは、[8]で定義されたポリシーデータオブジェクトにRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transparently transport the token -- or at least the correlation identifier -- from the Edge Router to the Policy Server. The content and internal structure of this object SHOULD be opaque to the policy management protocol. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。または少なくとも相関識別子 - - ポリシーサーバーにエッジルータから新しいプロトコルフィールドまたはオブジェクトを透過的にトークンを転送するために、ポリシー管理プロトコルに追加しなければなりません。このオブジェクトの内容及び内部構造は、ポリシー管理プロトコルに不透明であるべきです。例えば、これは、[8]で定義されたポリシーデータオブジェクトにCOPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。新しいプロトコルフィールドやオブジェクトは、透過的にエンドホストにセッション管理サーバからメディア認証トークンを転送するためにセッション管理プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造は、セッション管理プロトコルに不透明であるべきである（例えば、SIP [6]）。
The use of a media authorization token in this version of the Associated Model requires that the Edge Router inspect the token to learn which Policy Server authorized the media. In some environments, it may not be possible for the Edge Router to perform this function; in these cases, an Associated Model using Two Policy Servers (section 6) is required.
関連するモデルのこのバージョンでメディア許可トークンを使用すると、エッジルータは、ポリシーサーバがメディアを認可している学ぶためにトークンを検査する必要があります。エッジルータがこの機能を実行するためのいくつかの環境では、それは可能ではないかもしれません。これらのケースでは、2台のポリシーサーバを使用して、関連するモデル（セクション6）が必要です。
This version of the Associated Model also requires that the Edge Router interact with multiple Policy Servers. Policy decisions are made by the same Policy Server for both the Session Management Server and the Edge Router, however the Policy Server may change on per-transaction basis. Note that the COPS framework does not currently allow PEPs to change PDP on a per-transaction basis. To use this model, a new framework must be defined for policy decision outsourcing. This model also implies that the Policy Servers are able to interact and/or make decisions for the Edge Router in a consistent manner (e.g., as though there is only a single RCD Policy Server). How this is accomplished is beyond the scope of this document.
関連するモデルのこのバージョンはまた、エッジルータは、複数のポリシーサーバと対話することが必要です。政策決定は、セッション管理サーバとエッジルータの両方に同じポリシーサーバによって作られています、しかし、ポリシーサーバは、トランザクションごとの上変更することがあります。 COPSフレームワークは、現在のPEPは、トランザクション単位でPDPを変更することはできないことに注意してください。このモデルを使用するには、新しいフレームワークは、政策決定のアウトソーシングのために定義する必要があります。また、このモデルでは、ポリシーサーバは、（例えば、単一のRCDポリシーサーバがあるかのように）一貫性のある方法で相互作用および/またはエッジルータのための意思決定を行うことが可能であることを意味します。どのようにこれが達成され、この文書の範囲を超えています。
In this scenario, there are multiple instances of the Session Management Servers, Edge Routers and Policy Servers. This leads to a network of sufficient complexity that it precludes distributing knowledge of network topology to all network entities. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバ、エッジルータとポリシーサーバの複数のインスタンスがあります。これは、すべてのネットワーク・エンティティにネットワークトポロジの知識を配布不可能に十分な複雑さのネットワークにつながります。このシナリオの重要な側面は、次のとおりです。
- Policy decisions, including media authorization, are made by Policy Servers.
- メディアの認可を含む政策決定は、ポリシーサーバによって作られています。
- There is a PS in the Resource Control Domain that is separate from the PS in the Service Control Domain.
- サービス制御ドメインでPSから分離されたリソース制御ドメインでPSがあります。
- The Edge Router, Session Management Server and Policy Servers involved in establishing the session are not known a priori. For example, the End Host may be dynamically configured to use one of a pool of Session Management Servers or the End Host may be mobile and continually changing the Edge Router that it uses to communicate with the rest of the network.
- セッションの確立に関与エッジルータ、セッション管理サーバとポリシーサーバは事前に知られていません。例えば、エンドホストは、動的に携帯し、継続的に、それはネットワークの他の部分と通信するために使用するエッジルータを変えるかもしれセッション管理サーバーのプールまたはエンドホストのいずれかを使用するように構成することができます。
- There is a pre-defined trust relationship between the SMS and the SCD PS.
- SMSとSCD PS間の事前定義された信頼関係があります。
- There is a pre-defined trust relationship between the ER and the RCD PS.
- ERとRCD PS間の事前定義された信頼関係があります。
- There is a pre-defined trust relationship between the RCD and SCD Policy Servers.
- RCDとSCDポリシーサーバ間の事前定義された信頼関係があります。
+--------------------+ +--------+
+------+ | SMS `n' | | |
| | 1 +-+------------------+ | | SCD |
| |-------->| Session Management |-+ 2 | Policy |
| |<--------| Server |----->| Server |
| | 4 +--------------------+<-----| |
| End | 3 +--------+
| | 7 ^ |
| Host | +--------------------+ | v 8
| | | ER 'n' | +--------+
| | 5 +-+------------------+ | | |
| |-------->| Edge |-+ 6 | RCD |
| |<--------| Router |----->| Policy |
| | 10 +--------------------+<--- -| Server |
+------+ 9 | |
+--------+
Figure 4: The Associated Model using Two Policy Servers
図4：関連するモデルは、2台のポリシーサーバを使用して
In this model, it is assumed that there is one Policy Server for the Service Control Domain and a different Policy Server for the Resource Control Domain. There are pre-defined trust relationships between the SCD PS and SMS, between the RCD PS and ER and between the RCD and SCD Policy Servers. Communications between these entities are then possible as described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルでは、1台のサービス制御ドメイン用ポリシーサーバとリソース制御ドメインごとに異なるポリシーサーバがあることを想定しています。 RCD PSとERの間とRCDとSCDポリシーサーバ間のSCD PSとSMSの間で事前に定義された信頼関係があります。以下に説明するように、これらのエンティティ間の通信は、次に、可能です。唯一の起点側の流れが簡潔に記載されています。同じ概念は、終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1.エンドホストは、とりわけ示すセッション管理サーバに（例えば、SIP INVITEを）セッション設定要求を発行し、メディアストリームは、セッションで使用されます。このステップの一環として、エンドホストは、セッション管理サーバに自身を認証することがあります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server in order to determine if the session set-up request should be allowed to proceed.
2.ザ・セッション管理サーバは、完了する可能性がメディアストリームの交渉を待った後、セッション設定要求を許可すべきかどうかを判断するために、SCD Policy Serverに（例えば、REQがCOPS）政策決定要求を送信します続行します。
3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the SCD Policy Server to identify the session and the media it has authorized.
3. SCDポリシーサーバが決定（例えば、COPS DEC）セッション管理サーバには、おそらくメディアのパラメータを変更した後に使用されることを送信します。この応答に含まれ、その後のセッションと、それが承認したメディアを識別するために、SCDポリシーサーバーで使用できる「トークン」です。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the SCD Policy Server.
4.セッション管理サーバは、そのセッションのセットアップが完了したか、進行中であることを示すエンドホスト（例えば、SIP 200または183）への応答を送信します。この応答に含まSCDポリシーサーバからトークンと一緒に交渉したメディアの説明です。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the SCD Policy Server provided via the Session Management Server.
5.エンドホストは、メディアストリームのために必要なQoSを提供するために必要なリソースを予約するための要求（例えば、RSVPのPATH）を発行します。このリクエストに含まれるセッション管理サーバを介して提供SCDポリシーサーバからトークンです。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
前記エッジルータは、予約要求をインターセプトし、リソース予約要求を進行させなければならないかどうかを決定するために、RCDポリシーサーバにポリシー決定要求（例えば、COPS REQ）を送信します。このリクエストに含まれるエンドホストによって提供さSCDポリシーサーバからトークンです。
7. The RCD Policy Server uses this token to learn which SCD Policy Server authorized the media. It then sends an authorization request [11] to that SCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
7. RCDポリシーサーバがSCDポリシーサーバがメディアを認可している学ぶためにこのトークンを使用しています。これは、リソース予約要求の続行を許可するかどうかを決定するために、そのSCDポリシーサーバに認証要求[11]を送信します。このリクエストに含まれるエンドホストによって提供さSCDポリシーサーバからトークンです。
8. The SCD Policy Server uses this token to correlate the request for resources with the media authorization previously provided to the Session Management Server. The SCD Policy Server sends a decision [11] to the RCD Policy Server on whether the requested resources are within the bounds authorized by the SCD Policy Server.
8. SCDポリシーサーバーは、以前のセッション管理サーバーに提供されるメディアの権限を持つリソースの要求を相関させるために、このトークンを使用しています。 SCDポリシーサーバーは、要求されたリソースは、SCDポリシーサーバーによって許可範囲内にあるかどうかにRCD Policy Serverに決定[11]を送信します。
9. The RCD Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
9. RCDポリシーサーバが決定（例えば、COPS DEC）エッジルータには、おそらくリソースのパラメータを変更した後に予約されることを送信します。
10. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing
10.エッジルータは、おそらく完了するためのリソースのためのエンドツーエンドの交渉を待って、エンドホスト（例えば、RSVPのRESV）に応答を送信するリソース予約を指示すると、完了または進行しています
Since the RCD Policy Server does not know which SMS and SCD PS are involved in session establishment, the token MUST include:
RCDポリシーサーバはセッションの確立に関与しているSMSおよびSCD PS知らないので、トークンが含まれている必要があります
- A correlation identifier. This is information that the SCD Policy Server can use to correlate the resource reservation request with the media authorized during session set up. The SCD Policy Server is the only network entity that needs to interpret the contents of the correlation identifier therefore, in this model, the contents of the correlation identifier are implementation dependent. Since the End Host is assumed to be untrusted, the SCD Policy Server SHOULD take measures to ensure that the integrity of the correlation identifier is preserved in transit; the exact mechanisms to be used are also implementation dependent.
- 相関識別子。これは、SCDポリシーサーバのセットアップセッション中に許可メディアとのリソース予約要求を相関させるために使用できる情報です。 SCDポリシーサーバは、このモデルでは、相関識別子の内容は実装に依存しているため、相関識別子の内容を解釈する必要がある唯一のネットワークエンティティです。エンドホストが信頼できないことを想定しているため、SCDポリシーサーバは、相関識別子の整合性が輸送中に保存されていることを確保するための措置を取るべきです。使用する正確な機構はまた、実装依存です。
- The identity of the authorizing entity. This information is used by the RCD Policy Server to determine which SCD Policy Server should be used to verify the contents of the resource reservation request.
- 認可実体のアイデンティティ。この情報は、SCDポリシーサーバはリソース予約リクエストの内容を確認するために使用されるべきかを決定するために、RCDポリシーサーバーによって使用されます。
In some environments, an RCD Policy Server may have no means for determining if the identity refers to a legitimate SCD Policy Server. In order to protect against redirection of authorization requests to a bogus authorizing entity, the token SHOULD include:
身元が正当なSCDポリシーサーバーを参照する場合は一部の環境では、RCDポリシーサーバが判断するための手段を持たないことがあります。偽の認可実体への認証要求のリダイレクトから保護するために、トークンが含まれている必要があります
- Authentication data. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is beyond the scope of this document.
- 認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールド上で計算されます。 RCDポリシーサーバーが使用するメカニズムはこのドキュメントの範囲を超えています。
Note that the information in this token is the same as that in Section 5.2 for the "One Policy Server" scenario.
このトークンの情報は、「1台のポリシーサーバ」のシナリオについては、セクション5.2と同じであることに注意してください。
The detailed semantics of an authorization token are defined in [4].
許可トークンの詳細な意味は、[4]で定義されています。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
関連するモデルのこのバージョンでメディア許可トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトを透過的にエッジルータにエンドホストからトークンを輸送するためにリソース予約プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造は、リソース予約プロトコルに不透明であるべきです。例えば、これは、[8]で定義されたポリシーデータオブジェクトにRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transport the token from the SCD Policy Server to the Session Management Server and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 6.2. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドやオブジェクトは、セッション管理サーバへとエッジルータからRCD Policy ServerにSCDポリシーサーバーからトークンを輸送するために、ポリシー管理プロトコルに加えなければなりません。ポリシーサーバは、セクション6.2に記載したトークンの要素間を区別することができるように、コンテンツと、この物体の内部構造を指定する必要があります。例えば、これは、[8]で定義されたポリシーデータオブジェクトにCOPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。新しいプロトコルフィールドやオブジェクトは、透過的にエンドホストにセッション管理サーバからメディア認証トークンを転送するためにセッション管理プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造は、セッション管理プロトコルに不透明であるべきである（例えば、SIP [6]）。
Note that these impacts are the same as those discussed in Section 5.3 for the "One Policy Server" scenario. However the use of two Policy Servers has one additional impact:
これらの影響は、「1台のポリシーサーバ」シナリオについては、セクション5.3で説明したものと同じであることに注意してください。しかし、2台のポリシーサーバの使用は一つの追加の影響を及ぼします。
- Authorization protocol. A new protocol field or object MUST be added to the authorization protocol to transport the token from the RCD Policy Server to the SCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 6.2.
- 認証プロトコル。新しいプロトコルフィールドやオブジェクトは、SCD Policy ServerにRCDポリシーサーバーからトークンを輸送する認証プロトコルに加えなければなりません。ポリシーサーバは、セクション6.2に記載したトークンの要素間を区別することができるように、コンテンツと、この物体の内部構造を指定する必要があります。
In this scenario, the Session Management Servers and Edge Routers are associated with different Policy Servers, the network entities do not have a priori knowledge of the topology of the network and there are no pre-established trust relationships between entities in the Resource Control Domain and entities in the Service Control Domain. The key aspects of this scenario are the following:
このシナリオでは、セッション管理サーバーとエッジルータは、異なるポリシーサーバに関連付けられている、ネットワークエンティティは、ネットワークのトポロジーの事前の知識を持っていないと、リソース制御ドメイン内のエンティティの間には事前に確立された信頼関係が存在しないとサービス制御ドメイン内のエンティティ。このシナリオの重要な側面は、次のとおりです。
- Policy decisions, including media authorization, are made by Policy Servers.
- メディアの認可を含む政策決定は、ポリシーサーバによって作られています。
- The PS in the Resource Control Domain is separate from the PS in the Service Control Domain.
- リソース制御ドメインでのPSは、サービス制御ドメインでPSから分離されています。
- There is a pre-defined trust relationship between the SMS and the SCD PS.
- SMSとSCD PS間の事前定義された信頼関係があります。
- There is a pre-defined trust relationship between the ER and the RCD PS.
- ERとRCD PS間の事前定義された信頼関係があります。
- There are no pre-defined trust relationships between the ER and SMS or between the RCD and SCD Policy Servers.
- ERとSMSの間またはRCDとSCDポリシーサーバの間には事前に定義された信頼関係はありません。
+--------+
+------+ | |
| | 1 +--------------------+ 2 | SCD |
| |-------->| Session Management |----->| Policy |
| |<--------| Server |<-----| Server |
| | 4 +--------------------+ 3 | |
| End | +--------+
| Host |
| | +--------+
| | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| RCD |
| |<--------| Router |<-----| Policy |
| | 8 +--------------------+ 7 | Server |
+------+ | |
+--------+
Figure 5: The Non-Associated Model
図5：非関連するモデル
In this model it is assumed that the policy servers make independent decisions for their respective domains, obviating the need for information exchange between policy servers. This model also enables session authorization when communication between policy servers is not possible for various reasons. It may also be used as a means to speed up session setup and still ensure proper authorization is performed.
このモデルでは、ポリシーサーバは、ポリシーサーバ間の情報交換の必要性をなくす、それぞれのドメインのための独立した意思決定を行うことが想定されます。ポリシーサーバ間の通信は、様々な理由でできない場合、このモデルは、セッション認証を可能にします。また、セッションセットアップをスピードアップし、まだ適切な承認が行われたことを確認するための手段として使用することができます。
This model does not preclude the possibility that the policy servers may communicate at other times for other purposes (e.g., exchange of accounting information).
このモデルは、ポリシーサーバが他の目的のために他の時間に通信することができるという可能性を排除するものではない（例えば、課金情報の交換）。
Communications between network entities in this model is described below. Only the originating side flows are described for simplicity. The same concepts apply to the terminating side.
このモデルにおけるネットワークエンティティとの間の通信は、以下に記載されています。唯一の起点側の流れが簡潔に記載されています。同じ概念は、終端側に適用されます。
1. The End Host issues a session set-up request (e.g., SIP INVITE) to the Session Management Server indicating, among other things, the media streams to be used in the session. As part of this step, the End Host may authenticate itself to the Session Management Server.
1.エンドホストは、とりわけ示すセッション管理サーバに（例えば、SIP INVITEを）セッション設定要求を発行し、メディアストリームは、セッションで使用されます。このステップの一環として、エンドホストは、セッション管理サーバに自身を認証することがあります。
2. The Session Management Server, possibly after waiting for negotiation of the media streams to be completed, sends a policy decision request (e.g., COPS REQ) to the SCD Policy Server in order to determine if the session set-up request should be allowed to proceed.
2.ザ・セッション管理サーバは、完了する可能性がメディアストリームの交渉を待った後、セッション設定要求を許可すべきかどうかを判断するために、SCD Policy Serverに（例えば、REQがCOPS）政策決定要求を送信します続行します。
3. The SCD Policy Server sends a decision (e.g., COPS DEC) to the Session Management Server, possibly after modifying the parameters of the media to be used. Included in this response is a "token" that can subsequently be used by the RCD Policy Server to determine what media has been authorized.
3. SCDポリシーサーバが決定（例えば、COPS DEC）セッション管理サーバには、おそらくメディアのパラメータを変更した後に使用されることを送信します。この応答に含まれ、その後許可されたものを、メディアを判断するためにRCDポリシーサーバーで使用できる「トークン」です。
4. The Session Management Server sends a response to the End Host (e.g., SIP 200 or 183) indicating that session set-up is complete or is progressing. Included in this response is a description of the negotiated media along with the token from the SCD Policy Server.
4.セッション管理サーバは、そのセッションのセットアップが完了したか、進行中であることを示すエンドホスト（例えば、SIP 200または183）への応答を送信します。この応答に含まSCDポリシーサーバからトークンと一緒に交渉したメディアの説明です。
5. The End Host issues a request (e.g., RSVP PATH) to reserve the resources necessary to provide the required QoS for the media stream. Included in this request is the token from the SCD Policy Server provided via the Session Management Server.
5.エンドホストは、メディアストリームのために必要なQoSを提供するために必要なリソースを予約するための要求（例えば、RSVPのPATH）を発行します。このリクエストに含まれるセッション管理サーバを介して提供SCDポリシーサーバからトークンです。
6. The Edge Router intercepts the reservation request and sends a policy decision request (e.g., COPS REQ) to the RCD Policy Server in order to determine if the resource reservation request should be allowed to proceed. Included in this request is the token from the SCD Policy Server provided by the End Host.
前記エッジルータは、予約要求をインターセプトし、リソース予約要求を進行させなければならないかどうかを決定するために、RCDポリシーサーバにポリシー決定要求（例えば、COPS REQ）を送信します。このリクエストに含まれるエンドホストによって提供さSCDポリシーサーバからトークンです。
7. The RCD Policy Server uses this token to extract information about the media that was authorized by the SCD Policy Server. The RCD Policy Server uses this information in making its decision on whether the resource reservation should be allowed to proceed.
7. RCDポリシーサーバがSCDポリシーサーバーによって承認されたメディアの情報を抽出するために、このトークンを使用しています。 RCDポリシーサーバがリソース予約を進行させすべきかどうかの決定を行う際に、この情報を使用しています。
The Policy Server sends a decision (e.g., COPS DEC) to the Edge Router, possibly after modifying the parameters of the resources to be reserved.
ポリシーサーバは、意思決定（例えば、COPS DEC）エッジルータには、おそらくリソースのパラメータを変更した後に予約されることを送信します。
8. The Edge Router, possibly after waiting for end-to-end negotiation for resources to be completed, sends a response to the End Host (e.g., RSVP RESV) indicating that resource reservation is complete or is progressing
8.エッジルータは、おそらく完了するためのリソースのためのエンドツーエンドの交渉を待って、エンドホスト（例えば、RSVPのRESV）に応答を送信するリソース予約を指示すると、完了または進行しています
In this model, the token MUST contain sufficient information to allow the RCD Policy Server to make resource policy decisions autonomously from the SCD Policy Server. The token is created using information about the session received by the SMS. The information in the token MUST include:
このモデルでは、トークンはRCDポリシーサーバが自律的にSCDポリシーサーバからのリソースポリシーの決定を行うことができるように十分な情報を含まなければなりません。トークンはSMSで受信したセッションに関する情報を使用して作成されます。トークン内の情報が含まれている必要があります
- Calling party name or IP address (e.g., from SDP "c=" parameter).
- 発呼者名またはIPアドレス（例えば、 "C =" パラメータSDPから）。
- Called party name or IP address (e.g., from SDP "c=" parameter).
- 着信側の名前またはIPアドレス（例えば、 "C =" パラメータSDPから）。
- The characteristics of (each of) the media stream(s) authorized for this session (e.g., codecs, maximum bandwidth from SDP "m=" and/or "b=" parameters).
- このセッションのために認可（各）メディアストリーム（単数または複数）の特性（例えば、コーデック、最大SDPから帯域「M =」及び/又は「B =」パラメータ）。
- The authorization lifetime. To protect against replay attacks, the token should be valid for only a few seconds after the start time of the session.
- 認証の有効期間。リプレイ攻撃から保護するために、トークンは、セッションの開始時間後に数秒間しか有効にする必要があります。
- The identity of the authorizing entity to allow for validation of the token.
- トークンの検証を可能にする認可実体のアイデンティティ。
- Authentication data used to prevent tampering with the token. This authentication data is calculated over all other fields of the token using an agreed mechanism. The mechanism used by the RCD Policy Server is beyond the scope of this document.
- トークンの改ざんを防止するために使用される認証データ。この認証データは、合意されたメカニズムを使用して、トークンの他のすべてのフィールド上で計算されます。 RCDポリシーサーバーが使用するメカニズムはこのドキュメントの範囲を超えています。
Furthermore, the token MAY include:
さらに、トークンが含まれることがあります。
- The lifetime of (each of) the media stream(s) (e.g., from SDP "t=" parameter). This field may be useful in pre-paid scenarios in order to limit the lifetime of the session.
- （のそれぞれ）の寿命メディアストリーム（複数可）（例えば、SDP「Tは=」パラメータから）。このフィールドには、セッションの存続期間を制限するためにプリペイドのシナリオで有用である可能性があります。
- The Calling and called party port numbers (e.g., from the "m=" parameter).
- 呼び出しと被呼者のポート番号（例えば、「M =」パラメータから）。
The detailed semantics of an authorization token are defined in [4].
許可トークンの詳細な意味は、[4]で定義されています。
The use of a media authorization token in the Non-Associated Model requires the addition of new fields to several protocols:
非関連するモデルでメディア許可トークンを使用するには、いくつかのプロトコルに新しいフィールドを追加する必要があります。
- Resource reservation protocol. A new protocol field or object MUST be added to the resource reservation protocol to transparently transport the token from the End Host to the Edge Router. The content and internal structure of this object SHOULD be opaque to the resource reservation protocol. For example, this is achieved in RSVP with the Policy Data object defined in [8].
- リソース予約プロトコル。新しいプロトコルフィールドまたはオブジェクトを透過的にエッジルータにエンドホストからトークンを輸送するためにリソース予約プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造は、リソース予約プロトコルに不透明であるべきです。例えば、これは、[8]で定義されたポリシーデータオブジェクトにRSVPで達成されます。
- Policy management protocol. A new protocol field or object MUST be added to the policy management protocol to transport the token from the SCD Policy Server to the Session Management Server and from the Edge Router to the RCD Policy Server. The content and internal structure of this object MUST be specified so that the Policy Servers can distinguish between the elements of the token described in Section 7.2. For example, this is achieved in COPS-RSVP with the Policy Data object defined in [8].
- ポリシー管理プロトコル。新しいプロトコルフィールドやオブジェクトは、セッション管理サーバへとエッジルータからRCD Policy ServerにSCDポリシーサーバーからトークンを輸送するために、ポリシー管理プロトコルに加えなければなりません。ポリシーサーバは、セクション7.2に記載したトークンの要素間を区別することができるように、コンテンツと、この物体の内部構造を指定する必要があります。例えば、これは、[8]で定義されたポリシーデータオブジェクトにCOPS-RSVPで達成されます。
- Session management protocol. A new protocol field or object MUST be added to the session management protocol to transparently transport the media authorization token from the Session Management Server to the End Host. The content and internal structure of this object SHOULD be opaque to the session management protocol (e.g., SIP [6]).
- セッション管理プロトコル。新しいプロトコルフィールドやオブジェクトは、透過的にエンドホストにセッション管理サーバからメディア認証トークンを転送するためにセッション管理プロトコルに加えなければなりません。このオブジェクトの内容及び内部構造は、セッション管理プロトコルに不透明であるべきである（例えば、SIP [6]）。
This document defines three models for session set-up with media authorization:
この文書では、メディアの権限を持つセッションのセットアップのための3つのモデルを定義しています。
- The Coupled Model which assumes a priori knowledge of network topology and where pre-established trust relationships exist between network entities.
- 予め確立された信頼関係は、ネットワークエンティティ間に存在するネットワークトポロジとの先験的な知識を前提と結合モデル。
- The Associated Model where there are common or trusted policy servers but knowledge of the network topology is not known a priori.
- そこに共通または信頼ポリシーサーバですが、ネットワークトポロジーの知識が先験的に知られていない関連するモデル。
- The Non-Associated Model where knowledge of the network topology is not known a priori, where there are different policy servers involved and where a trust relationship does not exist between the policy servers.
- そこに関わる異なるポリシーサーバであり、ネットワークトポロジーの知識が事前に知られていない非関連するモデル、信頼関係は、ポリシーサーバの間に存在しない場合。
The Associated Model is applicable to environments where the network elements involved in establishing a session have a pre-determined trust relationship but where their identities must be determined dynamically during session set up. The Non-Associated Model is applicable to environments where there is a complex network topology and/or where trust relationships between domains do not exist (e.g., when they are different business entities).
関連するモデルは、セッションの確立に関与するネットワーク要素は、所定の信頼関係を持っているが、彼らのアイデンティティはセットアップセッション中に動的に決定されなければならないような環境にも適用することができます。非関連するモデルは、複雑なネットワークトポロジがあるおよび/またはドメイン間の信頼関係は、（例えば、それらが異なる事業者の場合）は存在しないような環境にも適用することができます。
In any given network, one or more of these models may be applicable. Indeed, the model to be used may be chosen dynamically during session establishment based on knowledge of the end points involved in the call. In all cases, however, there is no need for the End Host or the Session Management Server to understand or interpret the authorization token - to them it is an opaque protocol element that is simply copied from one container protocol to another.
任意のネットワークでは、これらのモデルのうちの1つ以上が適用可能です。実際、使用されるモデルは、コールに関連するエンドポイントの知識に基づいて、セッションの確立中に動的に選択することができます。しかし、すべての場合において、認証トークンを理解したり解釈するエンドホストまたはセッション管理サーバは必要ありません - 彼らにそれは単に別のコンテナプロトコルからコピーされた不透明なプロトコル要素です。
Finally, the framework defined in this document is extensible to any kind of session management protocol coupled to any one of a number of resource reservation and/or policy management protocols.
最後に、この文書で定義されたフレームワークは、リソース予約および/またはポリシー管理プロトコルのうちのいずれか一つに連結されたセッション管理プロトコルの任意の種類に拡張可能です。
The purpose of this document is to describe a mechanism for media authorization to prevent theft of service.
このドキュメントの目的は、サービスの盗難を防ぐために、メディアの認可のためのメカニズムを説明することです。
For the authorization token to be effective, its integrity MUST be guaranteed as it passes through untrusted network entities such as the End Host. This can be achieved by using authentication data. There is no requirement for encryption of the token since it does not contain confidential information that may be used by malicious users.
認証トークンが有効であるためには、このようなエンドホストとして信頼できないネットワークエンティティを通過する際に、その整合性が保証されなければなりません。これは、認証データを使用することによって達成することができます。それは、悪意のあるユーザーによって使用される機密情報が含まれていないので、トークンの暗号化のための要件はありません。
This document assumes that trust relationships exist between various network entities, as described in each of the models. The means for establishing these relationships are beyond the scope of this document.
この文書では、各モデルで説明したように信頼関係は、様々なネットワークエンティティ間に存在することを前提としています。これらの関係を確立するための手段は、このドキュメントの範囲を超えています。
The different interfaces between the network entities described in this document have different natures requiring different security characteristics:
本書で説明したネットワークエンティティ間の異なるインタフェースは、異なるセキュリティ特性を必要と異なる性質を有しています。
- The edge router and RCD policy server MUST have a trust relationship. If necessary, this relationship can be enforced through a formal security association [14].
- エッジルータとRCDポリシーサーバは、信頼関係を持たなければなりません。必要であれば、この関係は、正式なセキュリティアソシエーション[14]によって強制することができます。
- The network policies exchanged over the interface between edge router and RCD policy server SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy control protocol (e.g., the Integrity object in COPS [2]) or through generic IP security mechanisms [14].
- ネットワークポリシーは、エッジルータとRCDポリシーサーバ間のインタフェースの整合性を保護すべきで交換しました。これは、ポリシー・コントロール・プロトコルに組み込まれた完全性機構を用いて達成することができる（例えば、COPSにおけるインテグリティオブジェクト[2]）またはジェネリックIPセキュリティメカニズムを通して[14]。
- The SCD and RCD policy servers MUST have a trust relationship in the associated model. If necessary, this relationship can be enforced through a formal security association [14].
- SCDとRCDポリシーサーバは、関連するモデルにおける信頼関係を持たなければなりません。必要であれば、この関係は、正式なセキュリティアソシエーション[14]によって強制することができます。
- The information exchanged over the interface between policy servers SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy exchange protocol [2] or through generic IP security mechanisms [14].
- ポリシーサーバとの間のインタフェースを介して交換される情報には、整合性を保護する必要があります。これは、ポリシー交換プロトコル[2]にまたはジェネリックIPセキュリティメカニズム[14]を介して構築された完全性機構を用いて達成することができます。
- The end host SHOULD be authenticated by the RCD to protect against identity theft. The network resource request/responses should be protected against corruption and spoofing. Thus, the interface between host and edge router SHOULD provide integrity and authentication of messages. For example, [13] provides integrity and authentication of RSVP messages.
- エンドホストは、個人情報の盗難から保護するためにRCDで認証する必要があります。ネットワークリソース要求/応答が破損し、なりすましから保護されなければなりません。したがって、ホストとエッジルータとの間のインターフェースは、メッセージの完全性及び認証を提供すべきです。例えば、[13] RSVPメッセージの完全性及び認証を提供します。
- The end host SHOULD be authenticated by the SCD to protect against identity theft. The session setup request/response should be protected against corruption and spoofing. Thus, the interface between host and SMS SHOULD provide integrity and authentication of messages.
- エンドホストは、個人情報の盗難から保護するためにSCDで認証する必要があります。セッション設定要求/応答は、汚職やなりすましから保護されなければなりません。このように、ホストとSMSとの間のインタフェースは、メッセージの整合性と認証を提供する必要があります。
- The SMS and the SCD policy server MUST have a a trust relationship. If necessary, this relationship can be enforced through a formal security association [14].
- SMSとSCDポリシーサーバは、信頼関係を持たなければなりません。必要であれば、この関係は、正式なセキュリティアソシエーション[14]によって強制することができます。
- The network policies exchanged over the interface between the SMS and SCD policy server SHOULD be integrity protected. This can be accomplished using integrity mechanisms built into the policy control protocol (e.g., the Integrity object in COPS [2]) or through generic IP security mechanisms [14].
- ネットワークポリシーは、SMSおよびSCDポリシーサーバの完全性を保護すべきであるとの間のインターフェイス上で交換しました。これは、ポリシー・コントロール・プロトコルに組み込まれた完全性機構を用いて達成することができる（例えば、COPSにおけるインテグリティオブジェクト[2]）またはジェネリックIPセキュリティメカニズムを通して[14]。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[2]ダラム、D.、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[3] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[3]ヘルツォーク、S.、ボイル、J.、コーエン、R.、ダラム、D.、ラジャン、R.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[4] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[4]ハマー、L-N。、ゲージ、B.、コジンスキー、B.及びH. Shieh、 "セッション承認方針要素"、RFC 3520、2003年4月。
[5] Handley, M. and V. Jacobson, "SDP: session description protocol," RFC 2327, April 1998.
[5]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[6]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC 2205, September 1997.
[7]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様、" RFC 2205、1997年9月。
[8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[8]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[9] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[9]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.およびA.スミス、「使用をCOPSポリシープロビジョニング（COPS-PR）」、RFC 3084、2001年3月のため。
[10] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and P. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[10] Vollbrecht、J.、カルフーン、P.、ファレル、S.、Gommans、L.グロス、G.、デBruijnグラフ、B.、デLAAT、C.、ホールドレッジ、M.およびP.スペンス、 " AAA認証フレームワーク」、RFC 2904、2000年8月。
[11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[11]デLAAT、C.、グロス、G.、Gommans、L.、Vollbrecht、J.およびD.スペンス、 "汎用AAAアーキテクチャ"、RFC 2903、2000年8月。
[12] "PacketCable Dynamic Quality of Service Specification", CableLabs, December 1999.
[12] "サービス仕様のPacketCableのダイナミックな品質"、CableLabsの、1999年12月。
[13] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[13]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[14] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[14]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
The authors would like to thank to following people for their useful comments and suggestions related to this document: Kwok Ho Chan, Doug Reeves, Sam Christie, Matt Broda, Yajun Liu, Brett Kosinski, Francois Audet, Bill Marshall, Diana Rawlins and many others.
クォックホーチャン、ダグ・リーブス、サム・クリスティ、マット・Broda、Yajun劉、ブレット・コジンスキー、フランソワAudet、ビル・マーシャル、ダイアナローリンズおよび他の多く：作者は、このドキュメントに関連する彼らの役に立つコメントと提案については、以下の人々に感謝したいと思います。
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
CANADA K1Y 4H7 ONルイ・ニコラ・ハマーNortel Networksの私書箱3511駅のCオタワ、
Phone: +1 613.768.3409 EMail: nhamer@nortelnetworks.com
電話：+1 613.768.3409 Eメール：nhamer@nortelnetworks.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
CANADA K1Y 4H7 ONビル・ゲージNortel Networksの私書箱3511駅のCオタワ、
Phone: +1 613.763.4400 EMail: gageb@nortelnetworks.com
電話：+1 613.763.4400 Eメール：gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
ヒューShieh AT＆Tワイヤレス7277第164アベニューNEレドモンド、ワシントン州98073から9761
Phone: +1 425.580.6898 EMail: hugh.shieh@attws.com
電話：+1 425.580.6898 Eメール：hugh.shieh@attws.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。