RFC3521 日本語訳
3521 Framework for Session Set-up with Media Authorization. L-N.Hamer, B. Gage, H. Shieh. April 2003. (Format: TXT=59548 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L-N. Hamer
Request for Comments: 3521 B. Gage
Category: Informational Nortel Networks
H. Shieh
AT&T Wireless
April 2003
ワーキンググループL-Nをネットワークでつないでください。 コメントを求めるヘーマーRequest: 3521年のB.ゲージカテゴリ: 情報のノーテルはAT&T Wireless2003年4月にH.Shiehをネットワークでつなぎます。
Framework for Session Set-up with Media Authorization
メディア承認とのセッションセットアップのためのフレームワーク
Status of this Memo
この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.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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を提供するのに使用されるリソースがインラインであることを確かめるのが必要です。
Hamer, et al. Informational [Page 1] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[1ページ]のRFC3521セッションセットアップ
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
1. 序論…2 2. このドキュメントで中古のコンベンション…3 3. 用語の定義…4 4. 結合したモデル…5 4.1はモデルメッセージ流れを結合しました…6 4.2はモデル承認トークンを結合しました…8 4.3はモデルプロトコル影響を結合しました…8 5. 1つの方針サーバ>>を使用している関連モデル<<…8 5.1は1つの方針サーバ>>を使用することでモデルメッセージ流れ<<を関連づけました…9 5.2は1つの方針サーバ>>を使用することでモデル承認トークン<<を関連づけました…11 5.3 1つの方針サーバ>>を使用することで関連モデルプロトコルは<<に影響を与えます…11 1つの方針サーバ>>を使用することで5.4の関連モデルネットワークは<<に影響を与えます…12 6. 2方針サーバ>>を使用している関連モデル<<…12 6.1は2方針サーバ>>を使用することでモデルメッセージ流れ<<を関連づけました…13 6.2は2方針サーバ>>を使用することでモデル承認トークン<<を関連づけました…15 6.3 2方針サーバ>>を使用することで関連モデルプロトコルは<<に影響を与えます…16 7. 非関連しているモデル…16 7.1 非関連しているモデルメッセージ流動…17 7.2の非関連しているモデル承認トークン…19 7.3 非関連しているモデルプロトコルに影響を与えます…19 8. 結論…20 9. セキュリティ問題…21 10. 標準の参照…22 11. 有益な参照…23 12. 承認…23 13. 作者のアドレス…24 14. 完全な著作権宣言文…25
1. Introduction
1. 序論
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
どの終わりのホストがセッション管理プロトコルを使用できるかを通して様々なメカニズムは定義されました。(例えば、首尾よくセッションをセットアップするためにQoS必要条件を満たさなければならないのを示すSIP[6])。 しかしながら、aはプロトコルを切り離します。(例えばRSVP[7])は、リソースが終わりから終わりへのメディアストリームのQoSに会うのが必要であるよう要求するのに使用されます。 詐欺を防いで、正確な支払いを確実にするために、いくらかのリンケージがそうです。
Hamer, et al. Informational [Page 2] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[2ページ]のRFC3521セッションセットアップ
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.
メディアストリームがセッションのために要求されている状態で(そして、認可されます)要求された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.
このドキュメントは[10]のプッシュモデルにおける[12]でゲートのものと同様の能力を提供する「トークン」とチケットの使用でそのようなリンケージについて説明します。 それが方針で制御された流れ入場プロセスの一部として使用されるところで、トークンは、方針サーバ(または、セッション管理サーバー)によって生成されて、終わりのホストを通して透過的に縁のルータにリレーされます。
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- RSVP[3])がこれらのシナリオとメカニズムがこのドキュメントの範囲を超えているとわかるのが必要です。
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.
明快ために、このドキュメントはセッション合図のためのSIP、資源予約のためのRSVP、および方針サーバとの相互作用のためのCOPSを使用することでメディア承認概念を例証するでしょう。 しかしながら、異なった合図プロトコルを使用することでマルチメディアサービスシナリオにフレームワークを適用できるだろうことに注意してください。
2. Conventions used in this document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
Hamer, et al. Informational [Page 3] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[3ページ]のRFC3521セッションセットアップ
3. Definition of terms
3. 用語の定義
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 |
|+--------+| | | | |
+----------+ +-------------------------------------+ +---+
+-------------------------------------+ +---+ | SCD--サービス制御領域| | | | +-----------------------+ +--------+| | I| | |セッション管理| |方針|| | n| | |サーバ| |サーバ|| | t| | | +---------+ +------+ | | +----+| | <->| e| | | |一口プロキシ| |気力| <、-、|、-、|、-、>|PDP||| | r| | | +---------+ +------+ | | +----+|| | - | | +-----------------------+ +--------+| | c| | | | o | +-------------------------------------+ | n| | n| +-------------------------------------+ | e| | RCD--リソース制御領域| | c| | | | t| | | | i| | +------------+ +-------------+ | | n| +----------+ | |縁のルータ| |方針サーバ| | | g| | 終わり| | | | | | | | | | ホスト| | |+----------+| |+----------+ | | | N| |+--------+| | ||RSVPエージェント|| ||PDP| | | | e| ||RSVP| | <->| |+----------+| <-->、|+----------+ | | <->| t| ||クライアント|| | |+----------+| | | | | w| |+--------+| | || 気力|| | | | | o | ||一口ユーザ|| | |+----------+| | | | | r| ||エージェント|| | +------------+ +-------------+ | | 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).
えっ--終わりのホスト: End Hostはネットワーク・サービスにアクセスするのに加入者によって使用されたデバイスです。 End Hostはネットワーク・サービスを要求するためのクライアント(例えば、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.
えー--縁のルータ: Edge Routerは終わりのホストをResource Control Domainの残りに接続するネットワーク要素です。 Edge RouterはResource Control DomainにEnd Hostでリソース用法に関連する方針を実施するPEPを含みます。 また、それはEnd Hostからの取り扱いリソース予約の要請のために合図エージェントを含みます(例えば、RSVPのために)。
Hamer, et al. Informational [Page 4] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[4ページ]のRFC3521セッションセットアップ
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はサービス、そして/または、リソースへのアクセスを認可するか、または拒絶するのに責任があるPolicy Serverに位置する論理的な実体です。
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はPDPによってされた政策決定を実施する論理的な実体です。 しかしながら、他のPEPsが図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--方針サーバ: Policy ServerはPDPを含んでいるネットワーク要素です。 PSがサービスの使用を制御するService Control Domainにあるかもしれなくて、別々のPSがResource Control Domainにあるかもしれないことに注意して、パケット推進経路に沿ってリソースの使用を制御してください。 また、しかしながら、ネットワーク形態がDomainの中の複数のPolicy Serversを必要とするかもしれなくて、彼らが各Domainの独身の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--リソース制御領域: Resource Control DomainはEnd HostとEnd Hostから経路を進めながらパケットに沿って接続性を提供する要素の論理的な組分けです。 RCDは責任が経路を進めながらパケットに沿ってリソースの管理を含んでいるERとPS実体を含んでいます。 自治のドメインの中に1RCDsがあるかもしれないことに注意してください。
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--制御領域を修理してください: Service Control Domainは彼らのサービスの加入者にアプリケーションと内容を提供する要素の論理的な組分けです。 Session Management ServerはPSに伴うSCDに住んでいます。自治のドメインの中に1SCDsがあるかもしれないことに注意してください。
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--セッション管理サーバー: Session Management Serverはセッション経営指導(例えば、電話呼び出し制御装置)を提供するネットワーク要素です。 Session Management ServerはEnd Hostによるサービスの使用に関連する方針を実施するPEPを含んでいます。 また、それはEnd Hostからの取り扱いサービスのリクエストのために合図エージェントかプロキシを含んでいます(例えば、SIPのために)。
4. The Coupled Model
4. 結合したモデル
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:
いくつかの環境で、プレ確立した信頼関係はネットワーク(例えば、セッション管理サーバー、縁のルータ、方針サーバ、および終わりのホスト)の原理の間に存在しています。 実体の間の推定されるすっきりした関係を示して、私たちは「結合したモデル」にこれについて言及します。 このシナリオの特徴は以下です:
Hamer, et al. Informational [Page 5] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[5ページ]のRFC3521セッションセットアップ
- Policy decisions, including media authorization, are made by a
single Policy Server.
- メディア承認を含む政策決定が独身の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.
- セッションを確立するのにかかわるEdge Router、Session Management Servers、およびPolicy Serverは先験的に知られています。 例えば、End Hostは、EHが接続されているEdge Routerに関連しているSession Management Serverを使用するために構成されるかもしれません。
- 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 | |
+------+ | |
+--------+
+--------+ +------+ | | | | 1 +--------------------+ 2 | | | |、-、-、-、-、-、-、--、>| セッション管理|、-、-、-、--、>|、|、| | <、-、-、-、-、-、-、--、| サーバ| <、-、-、-、--、|、|、|、| 4 +--------------------+ 3 | | | 終わり| | 方針| | ホスト| | サーバ| | | | | | | 5 +--------------------+ 6 | | | |、-、-、-、-、-、-、--、>| 縁|、-、-、-、--、>|、|、| | <、-、-、-、-、-、-、--、| ルータ| <、-、-、-、--、|、|、|、| 8 +--------------------+ 7 | | +------+ | | +--------+
Figure 2: The Coupled Model
図2: 結合したモデル
4.1 Coupled Model Message Flows
4.1 結合したモデルメッセージ流れ
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.
このモデルでは、Service ControlとResource Control Domainsの両方に役立つ1Policy Serverがあって、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. End Hostはセッションのときにメディアストリームが使用されているのを特に示すSession Management Serverにセッションセットアップ要求(例えば、SIP INVITE)を出します。 このステップの一部として、End HostはSession Management Serverにそれ自体を認証するかもしれません。
Hamer, et al. Informational [Page 6] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[6ページ]のRFC3521セッションセットアップ
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. Session Management Serverは、メディアストリームの交渉が終了するのを待ったことによると後に、セッションセットアップ要求が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をPolicy Serverに送ります。
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. Policy Serverは決定(例えば、COPS DEC)をSession Management Serverに送ります、使用されるようにメディアのパラメタを変更したことによると後に。 この応答に含まれているのは、Policy Serverが次にそれが認可したセッションとメディアを特定するのに使用できる「トークン」です。
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. Session Management Serverはセッションセットアップが完全であるか、進歩であることを示すEnd Host(例えば、SIP200か183)への応答を送ります。 この応答に含まれているのは、Policy Serverからのトークンに伴う交渉されたメディアの記述です。
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. End Hostは必要なQoSをメディアストリームに提供するのに必要なリソースを予約するという要求(例えば、RSVP PATH)を出します。 この要求に含まれているのは、Session Management Serverを通して提供されたPolicy Serverからのトークンです。
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.
6. Edge Routerは、予約の要請を傍受して、リソース予約の要請が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をPolicy Serverに送ります。 この要求に含まれているのは、End Hostによって提供されたPolicy Serverからのトークンです。 Policy Serverは、以前にメディア承認をSession Management Serverに提供している状態でリソースに関する要求を関連させるのにこのトークンを使用します。
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. Policy Serverは決定(例えば、COPS DEC)をEdge Routerに送ります、予約されるようにリソースのパラメタを変更したことによると後に。
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. リソースが完成するのを終わりから終わりとの交渉を待ったことによると後に、Edge Routerは資源予約が完全であるか、進歩であることを示すEnd Host(例えば、RSVP RESV)への応答を送ります。
Hamer, et al. Informational [Page 7] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[7ページ]のRFC3521セッションセットアップ
4.2 Coupled Model Authorization Token
4.2 結合したモデル承認トークン
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.
Coupled Modelでは、Policy Serverはトークンのコンテンツを解釈する必要がある唯一のネットワーク実体です。 したがって、このモデルでは、トークンの内容は実装に依存しています。 End Hostが信頼されていないと思われて、Policy Server SHOULDはトークンの保全がトランジットで保持されるのを保証する対策を実施します。 また、使用されるべき正確なメカニズムも実装に依存しています。
4.3 Coupled Model Protocol Impacts
4.3 結合したモデルプロトコル影響
The use of a media authorization token in the Coupled Model requires the addition of new fields to several protocols:
Coupled Modelにおけるメディア承認トークンの使用は新しい分野の追加をいくつかのプロトコルに必要とします:
- 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].
- 資源予約プロトコル。 End HostからEdge Routerまで透過的にトークンを輸送するために新しいプロトコル分野かオブジェクトを資源予約プロトコルに追加しなければなりません。 満足していて内部は資源予約への不透明なものがプロトコルであったなら(もしあれば)このオブジェクトSHOULDを構造化します。 例えば、Policy Dataオブジェクトが[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].
- 政策管理は議定書を作ります。 Policy ServerからSession Management Serverまで透過的にトークンを輸送するために新しいプロトコル分野かオブジェクトを方針管理プロトコルに追加しなければなりません、そして、Edge Routerから. 満足していて内部が構造化する(もしあれば)このオブジェクトSHOULDのPolicy Serverまで、方針管理プロトコルに不透明にしてください。 例えば、Policy Dataオブジェクトが[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]).
- セッション管理は議定書を作ります。 Session Management ServerからEnd Hostまで透過的にメディア承認トークンを輸送するために新しいプロトコル分野かオブジェクトをセッション管理プロトコルに追加しなければなりません。 内容とインターナルがセッションまでの不透明なものが管理プロトコルであったなら(もしあれば)このオブジェクトSHOULDを構造化する、(例えば、SIP[6])。
5. The Associated Model <<using One Policy Server>>
5. 1つの方針サーバ>>を使用している関連モデル<<。
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:
このシナリオには、Session Management Servers、Edge Routers、およびPolicy Serversの複数のインスタンスがあります。 これは、すべてのネットワーク実体にネットワーク形態に関する知識を分配しながら、それが排除する十分な複雑さのネットワークに通じます。 このシナリオの特徴は以下です:
Hamer, et al. Informational [Page 8] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[8ページ]のRFC3521セッションセットアップ
- 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.
- メディア承認を含む政策決定はSession Management ServerとEdge Routerの両方のために同じPolicy Serverによってされます。 しかしながら、Policy Serverがaで変化するかもしれない、-、すなわち、方針要求基礎あたりのaのトランザクション基礎。
- 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.
- セッションを確立するのにかかわるEdge Router、Session Management Server、およびPolicy Serverは先験的に知られていません。 例えば、End HostはSession Management Serversのプールの1つを使用するためにダイナミックに構成されるかもしれません、そして、それぞれのSession Management Serversは、Policy Serversのプールの1つを使用するために静的に構成されるかもしれません。
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.
別の例では、End Hostはモバイルであるかもしれなく、絶えず接着点がネットワークの残りとコミュニケートするのに使用するEdge Routerを変えています。
- 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 | | |
+------+ <-----| |-+
+--------+
+---------------------+ +---------+ | 'SMS、'| <-->、| 'PS、'| +---------------------+ +--------+ | +------+ : : : | | | | | 1 +--------------------+ 2 | | | | |、-、-、-、-、-、-、--、>| セッション管理|、-、-、-、--、>|、|、|、| | <、-、-、-、-、-、-、--、| サーバ1| <、-、-、-、--、|、|、|、|、| 4 +--------------------+ 3 | | | | 終わり| | 方針| | | ホスト| +--------------------+ | サーバ| | | | | '、えー、'| | 1 | | | | 5 +-+------------------+ | | | | | |、-、-、-、-、-、-、--、>| 縁|-+ 6 | | | | | <、-、-、-、-、-、-、--、| ルータ|、-、-、-、--、>|、|、|、|、| 8 +--------------------+ 7 | | | +------+ <。-----| |-+ +--------+
Figure 3: The Associated Model using One Policy Server
図3: 1つの方針サーバを使用している関連モデル
5.1 Associated Model Message Flows <<using One Policy Server>>
5.1 1つの方針サーバ>>を使用する関連モデルメッセージ流れ<<。
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.
このモデルでは、Policy Serverが両方のための決定をService ControlとResource Control Domainsにすることができて、PSとSMSとPSとERとの信頼関係が事前に定義されると思われます。 これらの実体のコミュニケーションはその時、以下で説明されるように可能です。 起因しているサイド流れだけが簡単さのために説明されます。 同じ概念は終わり側に適用されます。
Hamer, et al. Informational [Page 9] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[9ページ]のRFC3521セッションセットアップ
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. End Hostはセッションのときにメディアストリームが使用されているのを特に示すSession Management Serverにセッションセットアップ要求(例えば、SIP INVITE)を出します。 このステップの一部として、End HostはSession Management Serverにそれ自体を認証するかもしれません。
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. Session Management Serverは、メディアストリームの交渉が終了するのを待ったことによると後に、セッションセットアップ要求が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をPolicy Serverに送ります。
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. Policy Serverは決定(例えば、COPS DEC)をSession Management Serverに送ります、使用されるようにメディアのパラメタを変更したことによると後に。 この応答に含まれているのは、Policy Serverが次にそれが認可したセッションとメディアを特定するのに使用できる「トークン」です。
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. Session Management Serverはセッションセットアップが完全であるか、進歩であることを示すEnd Host(例えば、SIP200か183)への応答を送ります。 この応答に含まれているのは、Policy Serverからのトークンに伴う交渉されたメディアの記述です。
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. End Hostは必要なQoSをメディアストリームに提供するのに必要なリソースを予約するという要求(例えば、RSVP PATH)を出します。 この要求に含まれているのは、Session Management Serverを通して提供されたPolicy Serverからのトークンです。
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. Edge Routerは、予約の要請を傍受して、どのPolicy Serverがメディアを認可したかを学ぶためにトークンを点検します。 そして、それは、リソース予約の要請が続くことができるべきであるかどうか決定するために政策決定要求をそのPolicy Serverに送ります。 この要求に含まれているのは、End Hostによって提供されたPolicy Serverからのトークンです。 Policy Serverは、以前にメディア承認をSession Management Serverに提供している状態でリソースに関する要求を関連させるのにこのトークンを使用します。
7. The Policy Server sends a decision to the Edge Router, possibly
after modifying the parameters of the resources to be reserved.
7. Policy Serverは決定をEdge Routerに送ります、予約されるようにリソースのパラメタを変更したことによると後に。
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. リソースが完成するのを終わりから終わりとの交渉を待ったことによると後に、Edge Routerは資源予約が完全であるか、進歩であることを示すEnd Host(例えば、RSVP RESV)への応答を送ります。
Hamer, et al. Informational [Page 10] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[10ページ]のRFC3521セッションセットアップ
5.2 Associated Model Authorization Token <<using One Policy Server>>
5.2 1つの方針サーバ>>を使用する関連モデル承認トークン<<。
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.
- 相関関係識別子。 これはPolicy Serverがメディアがセットアップされたセッションの間、認可されている状態でリソース予約の要請を関連させるのに使用できる情報です。 Policy Serverはしたがって、相関関係識別子のコンテンツを解釈する必要がある唯一のネットワーク実体です、このモデルで相関関係識別子の内容が実装に依存しています。 End Hostが信頼されていないと思われて、Policy Server SHOULDは相関関係識別子の保全がトランジットで保持されるのを保証する対策を実施します。 また、使用されるべき正確なメカニズムも実装に依存しています。
- 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.
- 認可実体のアイデンティティ。 この情報は、どのPolicy Serverがリソース政策決定に請求するのに使用されるべきであるかを決定するのにEdge Routerによって使用されます。
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:
いくつかの環境で、Edge Routerはアイデンティティがドメインの中で正統のPolicy Serverについて言及するかどうか決定するための手段を全く持っていないかもしれません。 また、にせの認可実体に承認要求のリダイレクションから守るために、トークンSHOULD守ります。
- 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.
- 認証データ。 この認証データは、トークンの他のすべての分野に関して同意されたメカニズムを使用することで計算されます。 Edge Routerによって使用されたメカニズムはこのドキュメントの範囲を超えています。
The detailed semantics of an authorization token are defined in [4].
承認トークンの詳細な意味論は[4]で定義されます。
5.3 Associated Model Protocol Impacts <<using One Policy Server>>
5.3 1つの方針サーバ>>を使用することで関連モデルプロトコルは<<に影響を与えます。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
Associated Modelのこのバージョンにおけるメディア承認トークンの使用は新しい分野の追加をいくつかのプロトコルに必要とします:
- 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].
- 資源予約プロトコル。 End HostからEdge Routerまで透過的にトークンを輸送するために新しいプロトコル分野かオブジェクトを資源予約プロトコルに追加しなければなりません。 Edge Routerがセクション5.2で説明されたトークンの要素を見分けることができるように、このオブジェクトの満足していて内部の構造を指定しなければなりません。 例えば、Policy Dataオブジェクトが[8]で定義されている状態で、これはRSVPで達成されます。
Hamer, et al. Informational [Page 11] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[11ページ]のRFC3521セッションセットアップ
- 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].
- 政策管理は議定書を作ります。 新しいプロトコル分野かオブジェクトによる加えられて、政策管理に. このオブジェクトSHOULDの内容と内部の構造がEdge RouterからPolicy Serverまで透過的に、トークン(少なくとも相関関係識別子)を輸送するために議定書を作っているということでなければなりません。方針管理プロトコルに不透明にしてください。 例えば、Policy Dataオブジェクトが[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]).
- セッション管理は議定書を作ります。 Session Management ServerからEnd Hostまで透過的にメディア承認トークンを輸送するために新しいプロトコル分野かオブジェクトをセッション管理プロトコルに追加しなければなりません。 このオブジェクトSHOULDでは、セッション管理プロトコルに不透明にしてください。満足していて内部の構造、(例えば、SIP[6])。
5.4 Associated Model Network Impacts <<using One Policy Server>>
1つの方針サーバ>>を使用することで5.4の関連モデルネットワークは<<に影響を与えます。
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.
Associated Modelのこのバージョンにおけるメディア承認トークンの使用は、Edge RouterがどのPolicy Serverがメディアを認可したかを学ぶためにトークンを点検するのを必要とします。 いくつかの環境で、Edge Routerがこの機能を実行するのは、可能でないかもしれません。 これらの場合では、Two Policy Servers(セクション6)を使用するAssociated Modelが必要です。
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.
また、Associated Modelのこのバージョンは、Edge Routerが複数のPolicy Serversと対話するのを必要とします。 政策決定がSession Management Serverとしかしながら、Edge Router、Policy Serverが変化するかもしれない両方のために同じPolicy Serverによってされる、-、トランザクション基礎。 PEPsが現在1トランザクションあたり1個のベースでCOPSフレームワークでPDPを変えることができないことに注意してください。 このモデルを使用するために、政策決定アウトソーシングのために新しいフレームワークを定義しなければなりません。 また、このモデルは、Edge Routerのために一貫した方法で決定を相互作用する、そして/または、Policy Serversがすることができると暗示します(例えば、まるで独身のRCD Policy Serverしかないかのように)。 これがどう優れているかはこのドキュメントの範囲を超えています。
6. The Associated Model <<using Two Policy Servers>>
6. 2方針サーバ>>を使用している関連モデル<<。
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:
このシナリオには、Session Management Servers、Edge Routers、およびPolicy Serversの複数のインスタンスがあります。 これは、すべてのネットワーク実体にネットワーク形態に関する知識を分配しながら、それが排除する十分な複雑さのネットワークに通じます。 このシナリオの特徴は以下です:
- Policy decisions, including media authorization, are made by
Policy Servers.
- メディア承認を含む政策決定がPolicy Serversによってされます。
Hamer, et al. Informational [Page 12] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[12ページ]のRFC3521セッションセットアップ
- There is a PS in the Resource Control Domain that is separate from
the PS in the Service Control Domain.
- PSがService Control DomainのPSから別々のResource Control Domainにあります。
- 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.
- セッションを確立するのにかかわるEdge Router、Session Management Server、およびPolicy Serversは先験的に知られていません。 例えば、End HostがSession Management Serversのプールの1つを使用するためにダイナミックに構成されるかもしれないか、End Hostはモバイルであるかもしれなく、絶えずそれがネットワークの残りとコミュニケートするのに使用するEdge Routerを変えています。
- 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 Policy Serversとの事前に定義された信頼関係があります。
+--------------------+ +--------+
+------+ | 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 | |
+--------+
+--------------------+ +--------+ +------+ | 'SMS、'| | | | | 1 +-+------------------+ | | SCD| | |、-、-、-、-、-、-、--、>| セッション管理|-+ 2 | 方針| | | <、-、-、-、-、-、-、--、| サーバ|、-、-、-、--、>| サーバ| | | 4 +--------------------+ <。-----| | | 終わり| 3 +--------+ | | 7 ^ | | ホスト| +--------------------+ | 8に対して| | | '、えー、'| +--------+ | | 5 +-+------------------+ | | | | |、-、-、-、-、-、-、--、>| 縁|-+ 6 | RCD| | | <、-、-、-、-、-、-、--、| ルータ|、-、-、-、--、>| 方針| | | 10 +--------------------+ <。--- -| サーバ| +------+ 9 | | +--------+
Figure 4: The Associated Model using Two Policy Servers
図4: 2つの方針サーバを使用している関連モデル
6.1 Associated Model Message Flows <<using Two Policy Servers>>
6.1 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.
このモデルでは、Service Control Domainのための1Policy ServerとResource Control Domainのための異なったPolicy Serverがあると思われます。 SCD PSとSMSと、RCD PSとERとRCDとSCD Policy Serversとの信頼関係は事前に定義されます。 これらの実体のコミュニケーションはその時、以下で説明されるように可能です。 起因しているサイド流れだけが簡単さのために説明されます。 同じ概念は終わり側に適用されます。
Hamer, et al. Informational [Page 13] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[13ページ]のRFC3521セッションセットアップ
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. End Hostはセッションのときにメディアストリームが使用されているのを特に示すSession Management Serverにセッションセットアップ要求(例えば、SIP INVITE)を出します。 このステップの一部として、End HostはSession Management Serverにそれ自体を認証するかもしれません。
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. Session Management Serverは、メディアストリームの交渉が終了するのを待ったことによると後に、セッションセットアップ要求が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をSCD Policy Serverに送ります。
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 Policy Serverは決定(例えば、COPS DEC)をSession Management Serverに送ります、使用されるようにメディアのパラメタを変更したことによると後に。 この応答に含まれているのは、SCD Policy Serverが次にそれが認可したセッションとメディアを特定するのに使用できる「トークン」です。
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. Session Management Serverはセッションセットアップが完全であるか、進歩であることを示すEnd Host(例えば、SIP200か183)への応答を送ります。 この応答に含まれているのは、SCD Policy Serverからのトークンに伴う交渉されたメディアの記述です。
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. End Hostは必要なQoSをメディアストリームに提供するのに必要なリソースを予約するという要求(例えば、RSVP PATH)を出します。 この要求に含まれているのは、Session Management Serverを通して提供されたSCD Policy Serverからのトークンです。
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.
6. Edge Routerは、予約の要請を傍受して、リソース予約の要請が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をRCD Policy Serverに送ります。 この要求に含まれているのは、End Hostによって提供されたSCD Policy Serverからのトークンです。
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 Policy Serverは、どのSCD Policy Serverがメディアを認可したかを学ぶのにこのトークンを使用します。 そして、それは、リソース予約の要請が続くことができるべきであるかどうか決定するために承認要求[11]をそのSCD Policy Serverに送ります。 この要求に含まれているのは、End Hostによって提供されたSCD Policy Serverからのトークンです。
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 Policy Serverは、以前にメディア承認をSession Management Serverに提供している状態でリソースに関する要求を関連させるのにこのトークンを使用します。SCD Policy ServerはSCD Policy Serverによって認可された領域の中に要求されたリソースがあるかのRCD Policy Serverに決定[11]を送ります。
Hamer, et al. Informational [Page 14] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[14ページ]のRFC3521セッションセットアップ
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 Policy Serverは決定(例えば、COPS DEC)をEdge Routerに送ります、予約されるようにリソースのパラメタを変更したことによると後に。
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. リソースが完成するのを終わりから終わりとの交渉を待ったことによると後に、Edge Routerは資源予約が完全であるか、進歩であることを示すEnd Host(例えば、RSVP RESV)への応答を送ります。
6.2 Associated Model Authorization Token <<using Two Policy Servers>>
6.2 関連モデルのトークン<<使用2承認方針サーバ>>。
Since the RCD Policy Server does not know which SMS and SCD PS are involved in session establishment, the token MUST include:
RCD Policy Serverが、どの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 Policy Serverがメディアがセットアップされたセッションの間、認可されている状態でリソース予約の要請を関連させるのに使用できる情報です。 SCD Policy Serverはしたがって、相関関係識別子のコンテンツを解釈する必要がある唯一のネットワーク実体です、このモデルで相関関係識別子の内容が実装に依存しています。 End Hostが信頼されていないと思われて、SCD Policy Server SHOULDは相関関係識別子の保全がトランジットで保持されるのを保証する対策を実施します。 また、使用されるべき正確なメカニズムも実装に依存しています。
- 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 Policy Serverがリソース予約の要請のコンテンツについて確かめるのに使用されるべきであるかを決定するのにRCD Policy Serverによって使用されます。
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:
いくつかの環境で、RCD Policy Serverはアイデンティティが正統のSCD Policy Serverについて言及するかどうか決定するための手段を全く持っていないかもしれません。にせの認可実体に承認要求のリダイレクションから守るために、トークンSHOULD守ります。
- 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 Policy Serverによって使用されたメカニズムはこのドキュメントの範囲を超えています。
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]で定義されます。
Hamer, et al. Informational [Page 15] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[15ページ]のRFC3521セッションセットアップ
6.3 Associated Model Protocol Impacts <<using Two Policy Servers>>
6.3 2方針サーバ>>を使用することで関連モデルプロトコルは<<に影響を与えます。
The use of a media authorization token in this version of the Associated Model requires the addition of new fields to several protocols:
Associated Modelのこのバージョンにおけるメディア承認トークンの使用は新しい分野の追加をいくつかのプロトコルに必要とします:
- 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].
- 資源予約プロトコル。 End HostからEdge Routerまで透過的にトークンを輸送するために新しいプロトコル分野かオブジェクトを資源予約プロトコルに追加しなければなりません。 満足していて内部の構造、このオブジェクトSHOULDでは、資源予約プロトコルに不透明にしてください。 例えば、Policy Dataオブジェクトが[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].
- 政策管理は議定書を作ります。 SCD Policy ServerからSession Management ServerまでEdge RouterからRCD Policy Serverまでトークンを輸送するために新しいプロトコル分野かオブジェクトを方針管理プロトコルに追加しなければなりません。Policy Serversがセクション6.2で説明されたトークンの要素を見分けることができるように、このオブジェクトの満足していて内部の構造を指定しなければなりません。 例えば、Policy Dataオブジェクトが[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]).
- セッション管理は議定書を作ります。 Session Management ServerからEnd Hostまで透過的にメディア承認トークンを輸送するために新しいプロトコル分野かオブジェクトをセッション管理プロトコルに追加しなければなりません。 このオブジェクトSHOULDでは、セッション管理プロトコルに不透明にしてください。満足していて内部の構造、(例えば、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で議論したものと同じであることに注意してください。 しかしながら、2Policy Serversの使用には、1回の追加影響力があります:
- 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.
- 承認プロトコル。 RCD Policy ServerからSCD Policy Serverまでトークンを輸送するために新しいプロトコル分野かオブジェクトを承認プロトコルに追加しなければなりません。Policy Serversがセクション6.2で説明されたトークンの要素を見分けることができるように、このオブジェクトの満足していて内部の構造を指定しなければなりません。
7. The Non-Associated Model
7. 非関連しているモデル
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:
このシナリオでは、Session Management ServersとEdge Routersは異なったPolicy Serversに関連しています、そして、ネットワーク実体には、ネットワークのトポロジーに関する先験的な知識がありません、そして、実体の間には、Service Control DomainのResource Control Domainと実体にどんなプレ確立した信頼関係もありません。 このシナリオの特徴は以下です:
Hamer, et al. Informational [Page 16] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[16ページ]のRFC3521セッションセットアップ
- Policy decisions, including media authorization, are made by
Policy Servers.
- メディア承認を含む政策決定がPolicy Serversによってされます。
- The PS in the Resource Control Domain is separate from the PS in
the Service Control Domain.
- Resource Control DomainのPSはService Control Domainの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 Policy Serversとの信頼関係は事前に定義されません。
+--------+
+------+ | |
| | 1 +--------------------+ 2 | SCD |
| |-------->| Session Management |----->| Policy |
| |<--------| Server |<-----| Server |
| | 4 +--------------------+ 3 | |
| End | +--------+
| Host |
| | +--------+
| | 5 +--------------------+ 6 | |
| |-------->| Edge |----->| RCD |
| |<--------| Router |<-----| Policy |
| | 8 +--------------------+ 7 | Server |
+------+ | |
+--------+
+--------+ +------+ | | | | 1 +--------------------+ 2 | SCD| | |、-、-、-、-、-、-、--、>| セッション管理|、-、-、-、--、>| 方針| | | <、-、-、-、-、-、-、--、| サーバ| <、-、-、-、--、| サーバ| | | 4 +--------------------+ 3 | | | 終わり| +--------+ | ホスト| | | +--------+ | | 5 +--------------------+ 6 | | | |、-、-、-、-、-、-、--、>| 縁|、-、-、-、--、>| RCD| | | <、-、-、-、-、-、-、--、| ルータ| <、-、-、-、--、| 方針| | | 8 +--------------------+ 7 | サーバ| +------+ | | +--------+
Figure 5: The Non-Associated Model
図5: 非関連しているモデル
7.1 Non-Associated Model Message Flow
7.1 非関連しているモデルメッセージ流動
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).
このモデルは方針サーバが他の時に他の目的(例えば、課金情報の交換)のために交信するかもしれない可能性を排除しません。
Hamer, et al. Informational [Page 17] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[17ページ]のRFC3521セッションセットアップ
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. End Hostはセッションのときにメディアストリームが使用されているのを特に示すSession Management Serverにセッションセットアップ要求(例えば、SIP INVITE)を出します。 このステップの一部として、End HostはSession Management Serverにそれ自体を認証するかもしれません。
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. Session Management Serverは、メディアストリームの交渉が終了するのを待ったことによると後に、セッションセットアップ要求が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をSCD Policy Serverに送ります。
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 Policy Serverは決定(例えば、COPS DEC)をSession Management Serverに送ります、使用されるようにメディアのパラメタを変更したことによると後に。 この応答に含まれているのは、RCD Policy Serverが次にどんなメディアが認可されたかを決定するのに使用できる「トークン」です。
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. Session Management Serverはセッションセットアップが完全であるか、進歩であることを示すEnd Host(例えば、SIP200か183)への応答を送ります。 この応答に含まれているのは、SCD Policy Serverからのトークンに伴う交渉されたメディアの記述です。
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. End Hostは必要なQoSをメディアストリームに提供するのに必要なリソースを予約するという要求(例えば、RSVP PATH)を出します。 この要求に含まれているのは、Session Management Serverを通して提供されたSCD Policy Serverからのトークンです。
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.
6. Edge Routerは、予約の要請を傍受して、リソース予約の要請が続くことができるべきであるかどうか決定するために、政策決定要求(例えば、COPS REQ)をRCD Policy Serverに送ります。 この要求に含まれているのは、End Hostによって提供されたSCD Policy Serverからのトークンです。
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 Policy Serverは、SCD Policy Serverによって認可されたメディアの情報を抜粋するのにこのトークンを使用します。RCD Policy Serverは資源予約が続くことができるべきであるかどうかに関する決定をする際にこの情報を使用します。
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.
Policy Serverは決定(例えば、COPS DEC)をEdge Routerに送ります、予約されるようにリソースのパラメタを変更したことによると後に。
Hamer, et al. Informational [Page 18] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[18ページ]のRFC3521セッションセットアップ
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. リソースが完成するのを終わりから終わりとの交渉を待ったことによると後に、Edge Routerは資源予約が完全であるか、進歩であることを示すEnd Host(例えば、RSVP RESV)への応答を送ります。
7.2 Non-Associated Model Authorization Token
7.2 非関連しているモデル承認トークン
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 Policy ServerがSCD Policy Serverからリソース政策決定を自主的にするのを許容できるくらいの情報を含まなければなりません。トークンは、SMSによって受けられたセッション頃に情報を使用することで作成されます。トークンにおける情報は以下を含まなければなりません。
- Calling party name or IP address (e.g., from SDP "c=" parameter).
- パーティー名かIPアドレス(例えば、SDP「c=」パラメタからの)と呼びます。
- Called party name or IP address (e.g., from SDP "c=" parameter).
- 被呼者名かIPアドレス(例えば、SDP「c=」パラメタからの)。
- 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 Policy Serverによって使用されたメカニズムはこのドキュメントの範囲を超えています。
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.
- 生涯、(それぞれ、)、メディアは(s)(例えば、SDP「t=」パラメタからの)を流します。 この分野は、セッションの生涯を制限するためにあらかじめ支払われたシナリオで役に立つかもしれません。
- The Calling and called party port numbers (e.g., from the "m="
parameter).
- Callingと被呼者は数(例えば、「m=」パラメタからの)を移植します。
The detailed semantics of an authorization token are defined in [4].
承認トークンの詳細な意味論は[4]で定義されます。
7.3 Non-Associated Model Protocol Impacts
7.3 非関連しているモデルプロトコル影響
The use of a media authorization token in the Non-Associated Model requires the addition of new fields to several protocols:
Nonが関連しているModelにおけるメディア承認トークンの使用は新しい分野の追加をいくつかのプロトコルに必要とします:
Hamer, et al. Informational [Page 19] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[19ページ]のRFC3521セッションセットアップ
- 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].
- 資源予約プロトコル。 End HostからEdge Routerまで透過的にトークンを輸送するために新しいプロトコル分野かオブジェクトを資源予約プロトコルに追加しなければなりません。 満足していて内部の構造、このオブジェクトSHOULDでは、資源予約プロトコルに不透明にしてください。 例えば、Policy Dataオブジェクトが[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].
- 政策管理は議定書を作ります。 SCD Policy ServerからSession Management ServerまでEdge RouterからRCD Policy Serverまでトークンを輸送するために新しいプロトコル分野かオブジェクトを方針管理プロトコルに追加しなければなりません。Policy Serversがセクション7.2で説明されたトークンの要素を見分けることができるように、このオブジェクトの満足していて内部の構造を指定しなければなりません。 例えば、Policy Dataオブジェクトが[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]).
- セッション管理は議定書を作ります。 Session Management ServerからEnd Hostまで透過的にメディア承認トークンを輸送するために新しいプロトコル分野かオブジェクトをセッション管理プロトコルに追加しなければなりません。 このオブジェクトSHOULDでは、セッション管理プロトコルに不透明にしてください。満足していて内部の構造、(例えば、SIP[6])。
8. Conclusions
8. 結論
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.
- ネットワーク形態に関する先験的な知識を仮定して、プレ確立した信頼関係がネットワーク実体の間に存在するCoupled Model。
- The Associated Model where there are common or trusted policy
servers but knowledge of the network topology is not known a
priori.
- ネットワーク形態に関する一般的であるか信じられた方針サーバにもかかわらず、知識があるAssociated Modelは先験的に知られていません。
- 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.
- かかわった異なった方針サーバがあるところでネットワーク形態に関する知識が先験的に知られていなくて、また信頼関係が方針サーバの間に存在しないNonが関連しているModel。
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).
Associated Modelはセッションを確立するのに伴われるネットワーク要素が持っていますが、彼らのアイデンティティがセットアップされたセッションの間にダイナミックに予定された信頼関係を決定していなければならない環境に適切です。 Nonが関連しているModelは複雑なネットワーク形態があって、ドメインの間の信頼関係が存在しない環境に適切です(例えば、いつそれらは異なった企業体ですか)。
Hamer, et al. Informational [Page 20] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[20ページ]のRFC3521セッションセットアップ
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.
どんな与えられたネットワークでも、これらのモデルのより多くのひとりは適切であるかもしれません。 本当に、使用されるべきモデルは呼び出しにかかわるエンドポイントに関する知識に基づくセッション設立の間、ダイナミックに選ばれるかもしれません。 しかしながら、すべての場合には、End HostかSession Management Serverが承認トークンを理解しているか、または解釈する必要は全くありません--それらに、それは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.
最終的に、本書では定義されたフレームワークは多くの資源予約、そして/または、方針管理プロトコルのいずれとも結合されたどんな種類のセッション管理プロトコルにも広げることができます。
9. Security Considerations
9. セキュリティ問題
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.
End Hostなどの信頼されていないネットワーク実体を通り抜けるので保証されていて、承認トークンが有効であるように、保全はそうしなければなりません。 認証データを使用することによって、これを達成できます。 悪意あるユーザーによって使用されるかもしれない秘密情報を含んでいないので、トークンの暗号化のための要件が全くありません。
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方針サーバSHOULDとのインタフェースの上で交換したネットワーク。 方針制御プロトコルが組み込まれた保全メカニズムを使用することでこれを達成できます。(例えば、Integrityは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]を通してこの関係を励行されることができます。
Hamer, et al. Informational [Page 21] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[21ページ]のRFC3521セッションセットアップ
- 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].
- 保全が保護されていたなら、情報は方針サーバSHOULDの間のインタフェースの上で交換しました。 方針交換プロトコル[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.
- 終わりはSHOULDを接待します。RCDによって認証されて、なりすましから守ってください。 ネットワーク資源要求/応答は、不正に対して保護されて、だまされるべきです。 その結果、SHOULDがメッセージの保全と認証を提供するホストと縁のルータの間とのインタフェース。 例えば、[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.
- 終わりはSHOULDを接待します。SCDによって認証されて、なりすましから守ってください。 セッションセットアップ要求/応答は、不正に対して保護されて、だまされるべきです。 したがって、ホストとSMS SHOULDとのインタフェースはメッセージの保全と認証を提供します。
- 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方針サーバで、aは関係を信じなければなりません。 必要なら、正式なセキュリティ協会[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方針サーバSHOULDとのインタフェースの上で交換したネットワーク。 方針制御プロトコルが組み込まれた保全メカニズムを使用することでこれを達成できます。(例えば、IntegrityはCOPS[2])かジェネリックIPセキュリティー対策[14]を通して反対します。
10. Normative References
10. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、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.とRajanとR.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(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、「セッション承認方針要素」、RFC3520、2003年4月。
[5] Handley, M. and V. Jacobson, "SDP: session description
protocol," RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
Hamer, et al. Informational [Page 22] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[22ページ]のRFC3521セッションセットアップ
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.ジャマン、「リソースReSerVationは(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[8] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[8] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、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.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年3月。
11. Informative References
11. 有益な参照
[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.とGrossとG.とde BruijnとB.とde LaatとC.とHoldregeとM.とP.スペンス、「AAA承認フレームワーク」、RFC2904、2000年8月。
[11] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D.
Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[11]de LaatとC.とGrossとG.とGommansとL.とVollbrechtとJ.とD.スペンス、「ジェネリックAAAアーキテクチャ」、RFC2903、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の暗号の認証」、RFC2747、2000年1月。
[14] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[14] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
12. Acknowledgments
12. 承認
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.
作者はこのドキュメントに関連する彼らの役に立つコメントと提案について人々に続くのに感謝したがっています: クォック・Hoチェン、ダグ・リーブズ、サム・クリスティ、マットBroda、Yajunリュウ、ブレット・コジンスキー、フランソアAudet、ビル・マーシャル、ダイアナ・ローリンズ、および多くの他のもの。
Hamer, et al. Informational [Page 23] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[23ページ]のRFC3521セッションセットアップ
13. Authors' Addresses
13. 作者のアドレス
Louis-Nicolas Hamer Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
ルイス-ニコラスヘーマーノーテルは私書箱3511駅のCオタワをカナダK1Y 4H7にネットワークでつなぎます。
Phone: +1 613.768.3409 EMail: nhamer@nortelnetworks.com
以下に電話をしてください。 +1 613.768 .3409 メール: nhamer@nortelnetworks.com
Bill Gage Nortel Networks PO Box 3511 Station C Ottawa, ON CANADA K1Y 4H7
ビルGageノーテルは私書箱3511駅のCオタワをカナダK1Y 4H7にネットワークでつなぎます。
Phone: +1 613.763.4400 EMail: gageb@nortelnetworks.com
以下に電話をしてください。 +1 613.763 .4400 メール: gageb@nortelnetworks.com
Hugh Shieh AT&T Wireless 7277 164th Avenue NE Redmond, WA USA 98073-9761
第164アベニューNEレッドモンド、ヒューShieh AT&T Wireless7277ワシントン米国98073-9761
Phone: +1 425.580.6898 EMail: hugh.shieh@attws.com
以下に電話をしてください。 +1 425.580 .6898 メール: hugh.shieh@attws.com
Hamer, et al. Informational [Page 24] RFC 3521 Session Set-up with Media Authorization April 2003
ヘーマー、他 メディア承認2003年4月がある情報[24ページ]のRFC3521セッションセットアップ
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Hamer, et al. Informational [Page 25]
ヘーマー、他 情報[25ページ]
一覧
スポンサーリンク
