[要約] RFC 5866は、Diameter Quality-of-Service（QoS）アプリケーションに関する標準仕様です。このRFCの目的は、Diameterプロトコルを使用してネットワーク上のQoS情報を交換するためのフレームワークを提供することです。
Internet Engineering Task Force (IETF) D. Sun, Ed.
Request for Comments: 5866 Alcatel-Lucent
Category: Standards Track P. McCann
ISSN: 2070-1721 Motorola Labs
H. Tschofenig
Nokia Siemens Networks
T. Tsou
Huawei
A. Doria
Lulea University of Technology
G. Zorn, Ed.
Network Zen
May 2010
Diameter Quality-of-Service Application
直径のサービス品質アプリケーション
Abstract
概要
This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined.
このドキュメントでは、直径のサービス品質（QOS）アプリケーションのフレームワーク、メッセージ、および手順について説明します。直径QoSアプリケーションにより、ネットワーク内のQOSリソースを割り当てるときに、ネットワーク要素が直径サーバーと対話できます。特に、2つの動作モード、つまり「プル」と「プッシュ」が定義されています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5866.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5866で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Network Element Functional Model . . . . . . . . . . . . . 7
3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 8
3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 8
3.2.2. Interaction Modes between the Authorizing Entity
and Network Element . . . . . . . . . . . . . . . . . 9
3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 10
3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 10
3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 13
3.4. QoS Application Requirements . . . . . . . . . . . . . . . 14
4. QoS Application Session Establishment and Management . . . . . 17
4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 17
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 18
4.2.1. Session Establishment for Pull Mode . . . . . . . . . 18
4.2.2. Session Establishment for Push Mode . . . . . . . . . 21
4.2.3. Discovery and Selection of Peer Diameter QoS
Application Node . . . . . . . . . . . . . . . . . . . 24
4.3. Session Re-Authorization . . . . . . . . . . . . . . . . . 24
4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 25
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 26
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 28
4.4.1. Client-Side Initiated Session Termination . . . . . . 28
4.4.2. Server-Side Initiated Session Termination . . . . . . 28
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 29
5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 30
5.2. QoS-Authorization-Answer (QAA) . . . . . . . . . . . . . . 31
5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 32
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 32
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 33
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 34
6. QoS Application State Machine . . . . . . . . . . . . . . . . 34
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 34
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 35
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 36
7.2. QoS Application-Defined AVPs . . . . . . . . . . . . . . . 36
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Example Call Flow for Pull Mode (Success Case) . . . . . . 38
9.2. Example Call Flow for Pull Mode (Failure Case) . . . . . . 40
9.3. Example Call Flow for Push Mode . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 45
10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 45
10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . . . 48
This document describes the framework, messages, and procedures for the Diameter [RFC3588] Quality-of-Service (QoS) application. The Diameter QoS application allows Network Elements (NEs) to interact with Diameter servers when allocating QoS resources in the network.
このドキュメントでは、直径[RFC3588]サービス品質（QOS）アプリケーションのフレームワーク、メッセージ、および手順について説明します。直径QoSアプリケーションにより、ネットワーク内のQOSリソースを割り当てるときに、ネットワーク要素（NES）が直径サーバーと対話できます。
Two modes of operation are defined. In the first, called "Pull" mode, the network element requests QoS authorization from the Diameter server based on some trigger (such as a QoS signaling protocol) that arrives along the data path. In the second, called "Push" mode, the Diameter server proactively sends a command to the network element(s) to install QoS authorization state. This could be triggered, for instance, by off-path signaling, such as Session Initiation Protocol (SIP) [RFC3261] call control.
2つの動作モードが定義されています。「プル」モードと呼ばれる最初のものでは、ネットワーク要素は、データパスに沿って到着するトリガー（QoSシグナリングプロトコルなど）に基づいて、DiameterサーバーからQoS認証を要求します。2番目の「プッシュ」モードと呼ばれる2番目で、Diameter Serverはコマンドをネットワーク要素に積極的に送信して、QoS認証状態をインストールします。これは、たとえば、セッション開始プロトコル（SIP）[RFC3261]コールコントロールなど、オフパスシグナリングによってトリガーされる可能性があります。
A set of command codes is specified that allows a single Diameter QoS application server to support both Pull and Push modes based on the requirements of network technologies, deployment scenarios, and end-host capabilities. In conjunction with Diameter Attribute Value Pairs (AVPs) defined in [RFC5777] and in [RFC5624], this document depicts basic call-flow procedures used to establish, modify, and terminate a Diameter QoS application session.
一連のコマンドコードが指定されており、単一の直径QoSアプリケーションサーバーが、ネットワークテクノロジー、展開シナリオ、およびエンドホスト機能の要件に基づいてプルモードとプッシュモードの両方をサポートできるようにします。[RFC5777]および[RFC5624]で定義された直径属性値ペア（AVP）と併せて、このドキュメントは、直径QoSアプリケーションセッションの確立、修正、終了に使用される基本的なコールフロー手順を示しています。
This document defines a number of Diameter-encoded AVPs, which are described using a modified version of the Augmented Backus-Naur Form (ABNF), see [RFC3588].
このドキュメントでは、拡張されたバックスNAURフォーム（ABNF）の変更されたバージョンを使用して説明されている直径エンコードAVPの多くを定義します。[RFC3588]を参照してください。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
AAA Cloud An infrastructure of Authentication, Authorization, and Accounting (AAA) entities (clients, agents, servers) communicating via a AAA protocol over trusted, secure connections. It offers authentication, authorization, and accounting services to applications in local and roaming scenarios. Diameter and RADIUS [RFC2865] are both widely deployed AAA protocols.
AAAクラウド認証、承認、および会計（AAA）エンティティ（クライアント、エージェント、サーバー）のインフラストラクチャをAAAプロトコルを介して通信し、信頼できる安全な接続を介して通信します。ローカルおよびローミングシナリオのアプリケーションに認証、承認、および会計サービスを提供します。直径と半径[RFC2865]はどちらも広く展開されているAAAプロトコルです。
Application Endpoint (AppE) An Application Endpoint is an entity in an end-user device that exchanges signaling messages with Application Servers or directly with other Application Endpoints. Based on the result of this signaling, the endpoint may make a request for QoS from the network. For example, a SIP User Agent is one kind of Application Endpoint.
アプリケーションエンドポイント（APPE）アプリケーションエンドポイントは、アプリケーションサーバーと直接、または他のアプリケーションエンドポイントと直接メッセージを交換するエンドユーザーデバイスのエンティティです。このシグナル伝達の結果に基づいて、エンドポイントはネットワークからQoSを要求する場合があります。たとえば、SIPユーザーエージェントは、アプリケーションエンドポイントの1つです。
Application Server (AppS) An Application Server is an entity that exchanges signaling messages with an Application Endpoint (see above). It may be a source of authorization for QoS-enhanced application flows. For example, a SIP server is one kind of Application Server.
アプリケーションサーバー（APPS）アプリケーションサーバーは、アプリケーションエンドポイントとシグナリングメッセージを交換するエンティティです（上記参照）。これは、QoS強化されたアプリケーションフローの許可の源である可能性があります。たとえば、SIPサーバーはアプリケーションサーバーの1つです。
Authorizing Entity (AE) The Authorizing Entity is a Diameter server that supports the QoS application. It is responsible for authorizing QoS requests for a particular application flow or aggregate. The Authorizing Entity may be a standalone entity or may be integrated with an Application Server and may be co-located with a subscriber database. This entity corresponds to the Policy Decision Point (PDP) [RFC2753].
承認エンティティ（AE）認証エンティティは、QoSアプリケーションをサポートする直径サーバーです。特定のアプリケーションフローまたは集計のQoSリクエストを承認する責任があります。承認エンティティは、スタンドアロンエンティティであるか、アプリケーションサーバーと統合されている場合があり、サブスクライバーデータベースと共同で開催される場合があります。このエンティティは、ポリシー決定ポイント（PDP）[RFC2753]に対応しています。
Network Element (NE) A QoS-aware router that acts as a Diameter client for the QoS application. This entity triggers the protocol interaction for Pull mode, and it is the recipient of QoS information in Push mode. The Diameter client at a Network Element corresponds to the Policy Enforcement Point (PEP) [RFC2753].
ネットワーク要素（NE）QOSアプリケーションの直径クライアントとして機能するQOS対応ルーター。このエンティティは、プルモードのプロトコルインタラクションをトリガーし、プッシュモードのQoS情報の受信者です。ネットワーク要素の直径クライアントは、ポリシー執行ポイント（PEP）[RFC2753]に対応します。
Pull Mode In this mode, the QoS authorization process is invoked by the QoS reservation request received from the Application Endpoint. The Network Element then requests the QoS authorization decision from the Authorizing Entity.
プルモードこのモードでは、QoS認証プロセスは、アプリケーションエンドポイントから受信したQoS予約要求によって呼び出されます。次に、ネットワーク要素は、承認エンティティからQoS認可決定を要求します。
Push Mode In this mode, the QoS authorization process is invoked by the request from the Application Server or local policies in the Authorizing Entity. The Authorizing Entity then installs the QoS authorization decision to the Network Element directly.
プッシュモードこのモードでは、QoS認証プロセスは、アプリケーションサーバーまたは認可エンティティのローカルポリシーからの要求によって呼び出されます。承認エンティティは、QoS認証決定をネットワーク要素に直接インストールします。
Resource Requesting Entity (RRE) A Resource Requesting Entity is a logical entity that supports the protocol interaction for QoS resources. The RRE resides in the end-host and is able to communicate with peer logical entities in an Authorizing Entity or a Network Element to trigger the QoS authorization process.
リソース要求エンティティ（RRE）リソース要求エンティティは、QoSリソースのプロトコル相互作用をサポートする論理的エンティティです。RREはエンドホストに存在し、QOS認証プロセスをトリガーするために、認可エンティティまたはネットワーク要素のピア論理エンティティと通信することができます。
The Diameter QoS application runs between an NE (acting as a Diameter client) and the resource AE (acting as a Diameter server). A high-level picture of the resulting architecture is shown in Figure 1.
直径QoSアプリケーションは、NE（直径クライアントとして機能する）とリソースAE（直径サーバーとして機能する）の間で実行されます。結果のアーキテクチャの高レベルの画像を図1に示します。
+-------+---------+
| Authorizing |
| Entity |
|(Diameter Server)|
+-------+---------+
|
|
/\-----+-----/\
//// \\\\
|| AAA Cloud ||
| (Diameter application) |
|| ||
\\\\ ////
\-------+-----/
|
+---+--+ +-----+----+ +---+--+
| | | NE | | | Media
+ NE +===+(Diameter +===+ NE +=============>>
| | | Client) | | | Flow
+------+ +----------+ +------+
Figure 1: An Architecture Supporting QoS-AAA
図1：QOS-AAAをサポートするアーキテクチャ
Figure 1 depicts NEs through which media flows need to pass, a cloud of AAA servers, and an AE. Note that there may be more than one router that needs to interact with the AAA cloud along the path of a given application flow, although the figure only depicts one for clarity.
図1は、メディアフローが通過する必要があるNES、AAAサーバーの雲、およびAEを示しています。図は明確にするためだけに描かれているが、特定のアプリケーションフローのパスに沿ってAAAクラウドと対話する必要がある複数のルーターがあるかもしれないことに注意してください。
In some deployment scenarios, NEs may request authorization through the AAA cloud based on an incoming QoS reservation request. The NE will route the request to a designated AE. The AE will return the result of the authorization decision. In other deployment scenarios, the authorization will be initiated upon dynamic application state, so that the request must be authenticated and authorized based on information from one or more AppSs. After receiving the authorization request from the AppS or the NE, the AE decides the appropriate mode (i.e., Push or Pull). The usage of Push or Pull mode can be determined by the Authorizing Entity either statically or dynamically. Static determination might be based on a configurable defined policy in the Authorizing Entity, while dynamic determination might be based on information received from an application server. For Push mode, the Authorizing Entity needs to identify the appropriate NE(s) to which QoS authorization information needs to be pushed. It might determine this based on information received from the AppS, such as the IP addresses of media flows.
いくつかの展開シナリオでは、NESは、着信QoS予約リクエストに基づいてAAAクラウドを介して許可を要求する場合があります。NEは、リクエストを指定されたAEにルーティングします。AEは、承認決定の結果を返します。他の展開シナリオでは、承認は動的なアプリケーション状態で開始されるため、1つ以上のアプリからの情報に基づいてリクエストを認証および承認する必要があります。アプリまたはNEから承認要求を受信した後、AEは適切なモード（つまり、プッシュまたはプル）を決定します。プッシュモードまたはプルモードの使用は、承認エンティティによって静的または動的に決定することによって決定できます。静的決定は、承認エンティティの構成可能な定義されたポリシーに基づいている可能性がありますが、動的決定はアプリケーションサーバーから受け取った情報に基づいている可能性があります。プッシュモードの場合、承認エンティティは、QoS認証情報をプッシュする必要がある適切なNEを特定する必要があります。メディアフローのIPアドレスなど、アプリから受け取った情報に基づいてこれを決定する場合があります。
In some deployment scenarios, there is a mapping between access network type and the service logic (e.g., selection of Push or Pull mode and other differentiated handling of the resource admission and control). The access network type might be derived from the authorization request from the AppS or the NE, and in this case, the Authorizing Entity can identify the corresponding service logic based on the mapping.
一部の展開シナリオでは、アクセスネットワークタイプとサービスロジックの間にマッピングがあります（たとえば、プッシュモードまたはプルモードの選択、およびリソースの入場と制御のその他の差別化された処理）。アクセスネットワークタイプは、アプリまたはNEからの承認要求から導き出される場合があります。この場合、承認エンティティはマッピングに基づいて対応するサービスロジックを特定できます。
If the interface between the NEs and the AAA cloud is identical regardless of whether or not the AE communicates with an AppS, routers are insulated from the details of particular applications and need not know that Application Servers are involved. Also, the AAA cloud may also encompass business relationships such as those between network operators and third-party application providers. This enables flexible intra- or inter-domain authorization, accounting, and settlement.
AEがアプリと通信するかどうかに関係なく、NESとAAAクラウドの間のインターフェイスが同一である場合、ルーターは特定のアプリケーションの詳細から断熱され、アプリケーションサーバーが関与していることを知る必要はありません。また、AAAクラウドには、ネットワークオペレーターとサードパーティのアプリケーションプロバイダーとのようなビジネス関係も含まれる場合があります。これにより、柔軟な内部またはドメイン間の許可、会計、および決済が可能になります。
Figure 2 depicts a logical operational model of resource management in a router.
図2は、ルーター内のリソース管理の論理的な動作モデルを示しています。
+-------------------------------------------------------+
| DIAMETER Client |
| Functionality |
| +---------------++-----------------++---------------+ |
| | User || QoS Application || Accounting | |
| | Authentication|| Client || Client (e.g., | |
| | Client || (Authorization ||for QoS Traffic| |
| +---------------+| of QoS Requests)|+---------------+ |
| +-----------------+ |
+-------------------------------------------------------+
^
v
+--------------+ +----------+
|QoS Signaling | | Resource |
|Msg Processing|<<<<<>>>>>>>|Management|
+--------------+ +----------+
. ^ | * ^
| v . * ^
+-------------+ * ^
|Signaling msg| * ^
| Processing | * V
+-------------+ * V
| | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V
| | * .............................
. . * . Traffic Control .
| | * . +---------+.
. . * . |Admission|.
| | * . | Control |.
+----------+ +------------+ . +---------+.
<.->| Input | | Outgoing |<.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
| | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+.
.............................
<.-.-> = signaling flow
=====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations
****** = routing table manipulation
Figure 2: Network Element Functional Model
図2：ネットワーク要素機能モデル
The processing of incoming QoS reservation requests includes three actions: admission control, authorization, and resource reservation.
着信QoS予約リクエストの処理には、入場管理、承認、リソース予約の3つのアクションが含まれます。
The admission control function provides information about available resources and determines whether there are enough resources to fulfill the request. Authorization is performed by the Diameter client, which involves contacting an authorization entity through the AAA cloud shown in Section 3. If both checks are successful, the authorized QoS parameters are set in the packet classifier and the packet scheduler. Note that the parameters passed to the Traffic Control function may be different from the ones that requested QoS (depending on the authorization decision). Once the requested resource is granted, the Resource Management function provides accounting information to the AE via the Diameter client.
入場制御機能は、利用可能なリソースに関する情報を提供し、リクエストを満たすのに十分なリソースがあるかどうかを判断します。許可は、セクション3に示すAAAクラウドを介して認証エンティティに連絡することを含むDiameterクライアントによって実行されます。両方のチェックが成功した場合、承認されたQoSパラメーターはパケット分類器とパケットスケジューラに設定されます。トラフィックコントロール機能に渡されたパラメーターは、QoSを要求したパラメーターとは異なる場合があることに注意してください（承認決定に応じて）。要求されたリソースが付与されると、リソース管理機能は、直径クライアントを介してAEに会計情報を提供します。
The QoS capabilities of Application Endpoints are varied, and can be categorized as follows:
アプリケーションエンドポイントのQOS機能はさまざまであり、次のように分類できます。
Category 1 A Category 1 Application Endpoint has no QoS capability at either the application or the network level. This type of AppE may set up a connection through application signaling, but it is incapable of specifying resource/QoS requirements through either application- or network-level signaling.
カテゴリ1カテゴリ1アプリケーションエンドポイントには、アプリケーションまたはネットワークレベルのいずれにもQOS機能がありません。このタイプのAPPEは、アプリケーションシグナリングを介して接続を設定する場合がありますが、アプリケーションまたはネットワークレベルの信号を使用してリソース/QoS要件を指定することはできません。
Category 2 A Category 2 Application Endpoint only has QoS capability at the application level. This type of AppE is able to set up a connection through application signaling with certain resource/QoS requirements (e.g., application attributes), but it is unable to signal any resource/QoS requirements at the network level.
カテゴリ2 Aカテゴリ2アプリケーションエンドポイントには、アプリケーションレベルでQoS機能のみがあります。このタイプのAPPEは、特定のリソース/QoS要件（アプリケーション属性など）を使用したアプリケーションシグナリングを介して接続を設定できますが、ネットワークレベルでリソース/QoS要件を信号することはできません。
Category 3 A Category 3 Application Endpoint has QoS capability at the network level. This type of AppE may set up a connection through application signaling, translate service characteristics into network resource/QoS requirements (e.g., network QoS class) locally, and request the resources through network signaling, e.g., Resource ReSerVation Protocol (RSVP) [RFC2205] or Next Steps in Signaling (NSIS) [NSIS-QOS].
カテゴリ3カテゴリ3アプリケーションエンドポイントには、ネットワークレベルでQoS機能があります。このタイプのAPPEは、アプリケーションシグナリングを介して接続を設定し、サービス特性をネットワークリソース/QoS要件（ネットワークQoSクラスなど）にローカルに変換し、ネットワークシグナリング（例：リソース予約プロトコル（RSVP）[RFC2205]を介してリソースを要求する場合があります。またはシグナリングの次のステップ（NSIS）[NSIS-QOS]。
Different QoS mechanisms are employed in packet networks. Those QoS mechanisms can be categorized into two schemes: IntServ [RFC2211] [RFC2212] and Diffserv [RFC2474]. In the IntServ scheme, network signaling (e.g., RSVP, NSIS, or link-specific signaling) is commonly used to initiate a request from an AppE for the desired QoS resource. In the Diffserv scheme, QoS resources are provisioned based upon some predefined QoS service classes rather than AppE-initiated, flow-based QoS requests.
パケットネットワークでは、さまざまなQoSメカニズムが採用されています。これらのQoSメカニズムは、IntServ [RFC2211] [RFC2212]とDiffserv [RFC2474]の2つのスキームに分類できます。INTSERVスキームでは、ネットワークシグナリング（RSVP、NSI、またはリンク固有のシグナル伝達など）が一般的に使用され、目的のQoSリソースのAPPEからの要求を開始します。DiffServスキームでは、QoSリソースは、Appe開始のフローベースのQoSリクエストではなく、いくつかの事前定義されたQoSサービスクラスに基づいてプロビジョニングされます。
It is obvious that the eligible QoS scheme is correlated to the AppE's capability in the context of QoS authorization. Since Category 1 and 2 AppEs cannot initiate the QoS resource requests by means of network signaling, using the current mechanism of the IntServ model to signal QoS information across the network is not applicable to them in general. Depending on network technology and operator requirements, a Category 3 AppE may either make use of network signaling for resource requests or not.
適格なQoSスキームが、QoS認証のコンテキストでAPPEの能力と相関していることは明らかです。カテゴリ1と2つのアプリは、ネットワークシグナリングを使用してQoSリソース要求を開始できないため、INTSERVモデルの現在のメカニズムを使用して、ネットワーク全体のQoS情報を信号することは、一般的には適用できません。ネットワークのテクノロジーとオペレーターの要件に応じて、カテゴリ3のAPPEは、リソース要求のためにネットワークシグナリングを使用するかどうかのいずれかです。
The diversity of QoS capabilities of endpoints and QoS schemes of network technology leads to the distinction on the interaction mode between the QoS authorization system and underlying NEs. When the IntServ scheme is employed by a Category 3 endpoint, the authorization process is typically initiated by an NE when a trigger is received from the endpoint such as network QoS signaling. In the Diffserv scheme, since the NE is unable to request the resource authorization on its own initiative, the authorization process is typically triggered by either the request of AppSs or policies defined by the operator.
エンドポイントのQoS機能の多様性とネットワークテクノロジーのQoSスキームは、QoS認証システムと基礎となるNES間の相互作用モードの区別につながります。INTSERVスキームがカテゴリ3エンドポイントで採用される場合、ネットワークQoSシグナリングなどのエンドポイントからトリガーが受信されると、認証プロセスがNEによって開始されます。DiffServスキームでは、NEは独自のイニシアチブに関するリソース認証を要求できないため、通常、許可プロセスは、オペレーターによって定義されたアプリまたはポリシーの要求によってトリガーされます。
As a consequence, two interaction modes are needed in support of different combinations of QoS schemes and endpoint's QoS capabilities: Push mode and Pull mode.
結果として、QoSスキームとエンドポイントのQoS機能のさまざまな組み合わせをサポートするには、プッシュモードとプルモードの2つの相互作用モードが必要です。
Push mode The QoS authorization process is triggered by AppSs or local network conditions (e.g., time of day on resource usage and QoS classes), and the authorization decisions are installed by the AE to the network element on its own initiative without explicit request. In order to support Push mode, the AE (i.e., Diameter server) should be able to initiate a Diameter authorization session to communicate with the NE (i.e., Diameter client) without any preestablished connection from the network element.
プッシュモードQoS認証プロセスは、アプリまたはローカルネットワーク条件（例：リソース使用およびQoSクラスの時刻）によってトリガーされ、明示的な要求なしに自社イニシアチブのAEによってAEによってインストールされます。プッシュモードをサポートするために、AE（つまり、直径サーバー）は、ネットワーク要素から事前に確立された接続なしにNE（つまり、直径クライアント）と通信する直径認証セッションを開始できる必要があります。
Pull mode The QoS authorization process is triggered by the network signaling received from end-user equipment or by a local event in the NE according to pre-configured policies, and authorization decisions are produced upon the request of the NE. In order to support Pull mode, the NE (i.e., Diameter client) will initiate a Diameter authorization session to communicate with the Authorizing Entity (i.e., Diameter server).
プルモードQoS認証プロセスは、エンドユーザー機器から受信したネットワークシグナリング、または事前に構成されたポリシーに従ってNEでのローカルイベントによってトリガーされ、NEの要求に応じて認可決定が作成されます。プルモードをサポートするために、NE（つまり、直径クライアント）は、承認エンティティ（つまり、直径サーバー）と通信するための直径認証セッションを開始します。
For Category 1 and 2 Application Endpoints, Push mode is REQUIRED. For a Category 3 AppE, either Push mode or Pull mode MAY be used.
カテゴリ1および2アプリケーションのエンドポイントの場合、プッシュモードが必要です。カテゴリ3のAPPEの場合、プッシュモードまたはプルモードのいずれかを使用できます。
Push mode is applicable to certain networks, for example, Cable network, DSL, Ethernet, and Diffserv-enabled IP/MPLS. Pull mode is more appropriate to IntServ-enabled IP networks or certain wireless networks such as the General Packet Radio Service (GPRS) networks defined by the Third Generation Partnership Project (3GPP). Some networks (for example, Worldwide Interoperability for Microwave Access (WiMAX)) may require both Push and Pull modes.
プッシュモードは、ケーブルネットワーク、DSL、イーサネット、DiffServ対応IP/MPLなど、特定のネットワークに適用できます。プルモードは、INTSERV対応のIPネットワークまたは第3世代パートナーシッププロジェクト（3GPP）で定義された一般的なパケットラジオサービス（GPRS）ネットワークなどの特定のワイヤレスネットワークにより適しています。一部のネットワーク（たとえば、マイクロ波アクセスの世界的な相互運用性（WIMAX））には、プッシュモードとプルモードの両方が必要になる場合があります。
Three types of basic authorization schemes for Pull mode exist: one type of two-party scheme and two types of three-party schemes. The notation adopted here is in respect to the entity that performs the QoS authorization (QoS Authz). The authentication of the QoS requesting entity might be done at the NE as part of the QoS signaling protocol, or by an off-path protocol (on the application layer or for network access authentication) or the AE might be contacted with a request for authentication and authorization of the QoS requesting entity. From the Diameter QoS application's point of view, these schemes differ in type of information that need to be carried. Here we focus on the "Basic Three-Party Scheme" (see Figure 3) and the "Token-Based Three-Party Scheme" (see Figure 4). In the "Two-Party Scheme", the QoS RRE is authenticated by the NE and the authorization decision is made either locally at the NE itself or offloaded to a trusted entity (most likely within the same administrative domain). In the two-party case, no Diameter QoS protocol interaction is required.
プルモードの3つのタイプの基本認証スキームが存在します。1つのタイプの2パーティスキームと2種類の3パーティスキーム。ここで採用されている表記は、QoS認証を実行するエンティティに関するものです（QoS Authz）。QoS要求エンティティの認証は、QoSシグナリングプロトコルの一部としてNEで行われる場合があります。QoS要求エンティティの承認。直径QoSアプリケーションの観点から、これらのスキームは、運ぶ必要がある情報のタイプが異なります。ここでは、「基本的な3つのパーティスキーム」（図3を参照）と「トークンベースの3パーティスキーム」（図4を参照）に焦点を当てます。「2つのパーティスキーム」では、QoS RREがNEによって認証され、認可決定はNE自体でローカルに行われるか、信頼できるエンティティにオフロードされます（おそらく同じ管理領域内で）。2パーティの場合、直径QoSプロトコルの相互作用は必要ありません。
+--------------+
| Authorizing |
| Entity |
| authorizing | <......+
| resource | .
| request | .
+------------+-+ .
--^----------|-- . .
///// | | \\\\\ .
// | | \\ .
| QoS | QoS AAA | QoS |.
| authz| protocol |authz |.
| req.| | res. |.
\\ | | // .
\\\\\ | | ///// .
QoS --|----------v-- . .
+-------------+ request +-+------------+ .
| Entity |----------------->| NE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <.....+
| |<-----------------| reservation | financial
+-------------+ +--------------+ settlement
Figure 3: Three-Party Scheme
図3：3つのパーティスキーム
In the "Basic Three-Party Scheme", a QoS reservation request that arrives at the NE is forwarded to the Authorizing Entity (e.g., in the user's home network), where the authorization decision is made. As shown, financial settlement -- a business relationship, such as a roaming agreement -- between the visited network and the home network ensures that the visited network is compensated for the resources consumed by the user via the home network.
「基本的な3つのパーティスキーム」では、NEに到着するQoS予約要求が、認可決定が下される認可エンティティ（ユーザーのホームネットワークなど）に転送されます。示されているように、訪問されたネットワークとホームネットワークの間の金融和解（ローミング契約などのビジネス関係）により、訪問されたネットワークがホームネットワークを介してユーザーが消費するリソースに対して補償されることが保証されます。
financial settlement
...........................+
Authorization V ------- .
Token Request +--------------+ / QoS AAA \ .
+-------------->| | / protocol \ .
| | Authorizing +--------------+ \ .
| | Entity | | | | .
| +------+ |<--+----+ | | .
| | +--------------+ |QoS | |QoS |.
| | |authz| |authz|.
| |Authorization |req.+| |res. |.
| |Token |Token| | |.
| | | | | . | .
| | \ | | . / .
| | \ | | / .
| | QoS request |-----V . .
+-------------+ + Authz Token +--------+-----+ .
| Entity |----------------->| NE | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <....+
| |<-----------------| reservation |
+-------------+ +--------------+
Figure 4: Token-Based Three-Party Scheme
図4：トークンベースの3パーティスキーム
The "Token-Based Three-Party Scheme" is applicable to environments where a previous protocol interaction is used to request authorization tokens to assist the authorization process at the NE or the AE [RFC3521].
「トークンベースの3つのパーティスキーム」は、以前のプロトコル相互作用を使用して、NEまたはAE [RFC3521]での認証プロセスを支援するための認証トークンを要求する環境に適用できます。
The QoS RRE may be involved in an application-layer protocol interaction, for example, using SIP [RFC3313], with the AE. As part of this interaction, authentication and authorization at the application layer might take place. As a result of a successful authorization decision, which might involve the user's home AAA server, an authorization token is generated by the AE (e.g., the SIP proxy and an entity trusted by the SIP proxy) and returned to the end-host for inclusion into the QoS signaling protocol. The authorization token will be used by an NE that receives the QoS signaling message to authorize the QoS request. Alternatively, the Diameter QoS application will be used to forward the authorization token to the user's home network. The authorization token allows for the authorization decision performed at the application layer to be associated with a corresponding QoS signaling session. Note that the authorization token might either refer to established state concerning the authorization decision or the token might itself carry the authorized parameters (protected by a digital signature or a keyed message digest to prevent tampering). In the latter case, the authorization token may contain several pieces of information pertaining to the authorized application session, but at minimum it should contain:
QOS RREは、AEを使用して、SIP [RFC3313]を使用するなど、アプリケーション層プロトコル相互作用に関与している可能性があります。この相互作用の一部として、アプリケーションレイヤーでの認証と承認が行われる可能性があります。ユーザーのホームAAAサーバーが関与する可能性のある承認決定の成功の結果、AEによって認可トークンが生成され（たとえば、SIPプロキシとSIPプロキシによって信頼されるエンティティ）、インクルージョンのためにエンドホストに戻ります。QoSシグナリングプロトコルに。承認トークンは、QoSリクエストを承認するためにQoS信号メッセージを受信するNEによって使用されます。または、Diameter QoSアプリケーションを使用して、認証トークンをユーザーのホームネットワークに転送します。承認トークンにより、アプリケーションレイヤーで実行された承認決定が、対応するQoSシグナリングセッションに関連付けられます。承認トークンは、承認決定に関する確立された状態を指すか、トークン自体が承認されたパラメーター（改ざんを防ぐためにデジタル署名またはキー付きメッセージダイジェストによって保護されている）を運ぶ可能性があることに注意してください。後者の場合、承認トークンには、承認されたアプリケーションセッションに関するいくつかの情報が含まれている場合がありますが、少なくとも次のことを含める必要があります。
o An identifier for the AE (for example, an AppS) that issued the authorization token;
o 認証トークンを発行したAE（たとえば、アプリ）の識別子。
o An identifier referring to a specific application protocol session for which the token was issued; and
o トークンが発行された特定のアプリケーションプロトコルセッションを参照する識別子。と
o A keyed message digest or digital signature protecting the content of the authorization token.
o 認証トークンのコンテンツを保護するキー付きメッセージダイジェストまたはデジタル署名。
A possible structure for the authorization token and the policy element carrying it are proposed in the context of RSVP [RFC3520].
認証トークンとそれを伝えるポリシー要素の可能な構造は、RSVP [RFC3520]のコンテキストで提案されています。
In the scenario mentioned above, where the QoS resource requesting entity is involved in an application-layer protocol interaction with the AE, it may be worthwhile to consider a token-less binding mechanism also. The application-layer protocol interaction may have indicated the transport port numbers at the QoS RRE where it might receive media streams (for example, in SIP/SDP [RFC4566] signaling, these port numbers are advertised). The QoS RRE may also use these port numbers in some IP filter indications to the NE performing QoS reservation so that it may properly tunnel the inbound packets. The NE performing QoS reservation will forward the QoS resource requesting entity's IP address and the IP filter indications to the AE in the QoS authorization request. The AE will use the QoS RRE's IP address and the port numbers in the IP filter indication, which will match the port numbers advertised in the earlier application-layer protocol interaction, to identify the right piece of policy information to be sent to the NE performing the QoS reservation in the QoS Authorization response.
上記のシナリオでは、QoSリソース要求エンティティがAEとのアプリケーション層プロトコルの相互作用に関与しているため、トークンレスの結合メカニズムも考慮する価値があるかもしれません。アプリケーション層プロトコルの相互作用は、メディアストリームを受け取る可能性のあるQOS RREでの輸送ポート番号を示している可能性があります（たとえば、SIP/SDP [RFC4566]シグナル伝達では、これらのポート番号が宣伝されています）。QoS RREは、これらのポート番号を、QoS予約を実行するNEのIPフィルター表示で使用して、インバウンドパケットを適切にトンネルする可能性があります。QOS予約を実行するNEは、QoS認証リクエストのAEへのQoSリソースリクエストエンティティのIPアドレスとIPフィルター表示を転送します。AEは、QOS RREのIPアドレスとIPフィルター表示のポート番号を使用します。これは、以前のアプリケーション層プロトコルインタラクションで宣伝されているポート番号と一致し、パフォーマンスのあるNEに送信される正しいポリシー情報を特定します。QoS認証応答のQoS予約。
Push mode can be further divided into two types: endpoint-initiated and network-initiated. In the former case, the authorization process is triggered by AppS in response to an explicit QoS request from an endpoint through application signaling, e.g., SIP; in the latter case, the authorization process is triggered by the AppS without an explicit QoS request from an endpoint.
プッシュモードは、エンドポイント開始とネットワーク開始の2つのタイプにさらに分割できます。前者の場合、承認プロセスは、アプリケーションシグナル、たとえばSIPを介したエンドポイントからの明示的なQoS要求に応じて、アプリによってトリガーされます。後者の場合、承認プロセスは、エンドポイントからの明示的なQoS要求なしにアプリによってトリガーされます。
In the endpoint-initiated scheme, the QoS RRE (i.e., the AppE) determines the required application-level QoS and sends a QoS request through an application signaling message. The AppS will extract application-level QoS information and trigger the authorization process to the AE. In the network-initiated scheme, the AE and/or AppS should derive and determine the QoS requirements according to application attribute, subscription, and endpoint capability when the endpoint does not explicitly indicate the QoS attributes. The AE makes an authorization decision based on application-level QoS information, network policies, end-user subscription, network resource availability, etc., and installs the decision to the NE directly.
エンドポイント開始スキームでは、QOS RRE（つまり、APPE）が必要なアプリケーションレベルのQOを決定し、アプリケーションシグナリングメッセージを介してQOS要求を送信します。アプリはアプリケーションレベルのQoS情報を抽出し、AEに承認プロセスをトリガーします。ネットワーク開始スキームでは、AEおよび/またはアプリは、エンドポイントがQOS属性を明示的に示さない場合、アプリケーション属性、サブスクリプション、およびエンドポイント機能に従ってQOS要件を導き出して決定する必要があります。AEは、アプリケーションレベルのQoS情報、ネットワークポリシー、エンドユーザーサブスクリプション、ネットワークリソースの可用性などに基づいて許可決定を下し、決定をNEに直接インストールします。
A Category 1 AppE requires network-initiated Push mode and a Category 2 AppE may use either type of Push Mode.
カテゴリ1のAPPEでは、ネットワーク開始プッシュモードが必要であり、カテゴリ2のAPPEはどちらのタイプのプッシュモードを使用できます。
financial settlement
...........................+
Application V ------- .
signaling msg +--------------+ / QoS AAA \ .
+-------------->| | / protocol \ .
| | Authorizing +--------------+ \ .
| | Entity | | | | .
| + |<--+----+ | | .
| +--------------+ |QoS | |QoS |.
| install| |install
| |rsp. | |req. |.
| | | | |.
| | | | . | .
| \ | | . / .
| \ | | / .
V |-----V . .
+-------------+ +--------+-----+ .
| Entity | | NE | .
| requesting | | performing | .
| resource |QoS rsrc granted | QoS | <....+
| |<-----------------| reservation |
+-------------+ +--------------+
Figure 5: Scheme for Push Mode
図5：プッシュモードのスキーム
A QoS application must meet a number of requirements applicable to a diverse set of networking environments and services. It should be compatible with different deployment scenarios having specific QoS signaling models and security issues. Satisfying the requirements listed below while interworking with QoS signaling protocols, a Diameter QoS application should accommodate the capabilities of the QoS signaling protocols rather than introduce functional requirements on them. A list of requirements for a QoS authorization application is provided here: Identity-based Routing The Diameter QoS application MUST route AAA requests to the Authorizing Entity, based on the provided identity of the QoS requesting entity or the identity of the AE encoded in the provided authorization token.
QoSアプリケーションは、ネットワーキング環境とサービスの多様なセットに適用される多くの要件を満たす必要があります。特定のQoSシグナル伝達モデルとセキュリティの問題を備えたさまざまな展開シナリオと互換性があるはずです。QOSシグナリングプロトコルとのインターワーキング中に以下にリストされている要件を満たすと、直径QoSアプリケーションは、それらに機能的要件を導入するのではなく、QoSシグナリングプロトコルの機能に対応する必要があります。QoS認可アプリケーションの要件のリストはこちらに提供されています：IDベースのルーティング直径QoSアプリケーションは、QoS要求エンティティの提供されたアイデンティティまたは提供されたAEのアイデンティティの身元に基づいて、AAA要求を認証エンティティにルーティングする必要があります。承認トークン。
Flexible Authentication Support The Diameter QoS application MUST support a variety of different authentication protocols for verification of authentication information present in QoS signaling messages. The support for these protocols MAY be provided indirectly by tying the signaling communication for QoS to a previous authentication protocol exchange (e.g., using network access authentication).
柔軟な認証サポート直径QoSアプリケーションは、QoSシグナリングメッセージに存在する認証情報を検証するために、さまざまな異なる認証プロトコルをサポートする必要があります。これらのプロトコルのサポートは、QoSのシグナリング通信を以前の認証プロトコル交換に結びつけることにより間接的に提供される場合があります（たとえば、ネットワークアクセス認証を使用）。
Making an Authorization Decision The Diameter QoS application MUST exchange sufficient information between the AE and the enforcing entity (and vice versa) to compute an authorization decision and to execute this decision.
承認決定を下すDiameter QoSアプリケーションは、AEと執行エンティティ（およびその逆）の間の十分な情報を交換して、許可決定を計算し、この決定を実行する必要があります。
Triggering an Authorization Process The Diameter QoS application MUST allow periodic and event-triggered execution of the authorization process, originated at the enforcing entity or even at the AE.
承認プロセスのトリガーDiameter QoSアプリケーションは、執行エンティティまたはAEでさらに発生する許可プロセスの定期的かつイベントトリガーの実行を許可する必要があります。
Associating QoS Reservations and Application State The Diameter QoS application MUST carry information sufficient for an AppS to identify the appropriate application session and associate it with a particular QoS reservation.
QoS予約とアプリケーションの関連付け状態QoSアプリケーションは、アプリが適切なアプリケーションセッションを識別し、特定のQoS予約に関連付けるのに十分な情報を提供する必要があります。
Dynamic Authorization It MUST be possible for the Diameter QoS application to push updates towards the NE(s) from Authorizing Entities.
動的認証直径QoSアプリケーションが、承認エンティティからNE（s）に向かって更新をプッシュすることが可能である必要があります。
Bearer Gating The Diameter QoS application MUST allow the AE to gate (i.e., enable/disable) authorized application flows based on, e.g., application state transitions.
ベアラーゲーティング直径QoSアプリケーションは、AEがゲートをゲート（つまり、有効化/無効）する必要があります。
Accounting Records The Diameter QoS application MAY define QoS accounting records containing duration, volume (byte count) usage information, and a description of the QoS attributes (e.g., bandwidth, delay, loss rate) that were supported for the flow.
アカウンティングレコード直径QoSアプリケーションは、フローにサポートされているQOS属性（例：帯域幅、遅延、損失率）を含むQoSアカウンティングレコードを定義できます。
Sending Accounting Records The NE SHOULD be able to send accounting records for a particular QoS reservation state to an accounting entity.
会計記録の送信NEは、特定のQoS予約状態の会計記録を会計事業体に送信できるはずです。
Failure Notification The Diameter QoS application MUST allow the NE to report failures, such as loss of connectivity due to movement of a mobile node or other reasons for packet loss, to the Authorizing Entity.
障害通知直径QoSアプリケーションは、NEがモバイルノードの動きやパケット損失のその他の理由による接続の損失など、承認エンティティに障害を報告できるようにする必要があります。
Accounting Correlation The Diameter QoS application MAY support the exchange of sufficient information to allow for correlation between accounting records generated by the NEs and accounting records generated by an AppS.
会計相関直径QoSアプリケーションは、NESによって生成された会計記録とアプリによって生成された会計記録間の相関を可能にするための十分な情報の交換をサポートする可能性があります。
Interaction with Other AAA Applications Interaction with other AAA applications, such as the Diameter Network Access Server Application [RFC4005], may be required for exchange of authorization, authentication, and accounting information.
他のAAAアプリケーションとの相互作用と、承認、認証、および会計情報の交換には、Diameter Network Access Serverアプリケーション[RFC4005]など、他のAAAアプリケーションとの相互作用が必要になる場合があります。
In deployment scenarios where authentication of the QoS reservation requesting entity (e.g., the user) is done by means outside the Diameter QoS application protocol interaction, the AE is contacted only with a request for QoS authorization. Authentication might have taken place already via the interaction with the Diameter application [RFC4005] or as part of the QoS signaling protocol (e.g., Transport Layer Security (TLS) [RFC5246] in the General Internet Signaling Transport (GIST) protocol [NSIS-NTLP]).
QOS予約要求エンティティ（ユーザーなど）の認証が直径QoSアプリケーションプロトコルインタラクションの外側で行われる展開シナリオでは、AEはQoS認証の要求とのみ連絡されます。一般的なインターネットシグナリングトランスポート（GIST）プロトコル[NSIS-NTLPでQOSシグナル伝達プロトコル（たとえば、トランスポートレイヤーセキュリティ（TLS）[RFC5246）の一部として、直径アプリケーション[RFC4005]との相互作用を介して、認証がすでに行われている可能性があります。]）。
Authentication of the QoS reservation requesting entity to the AE is necessary if a particular Diameter QoS application protocol cannot be related (or if there is no intention to relate it) to a prior authentication. In this case, the AE MUST authenticate the QoS reservation requesting entity in order to authorize the QoS request as part of the Diameter QoS protocol interaction.
特定の直径QoSアプリケーションプロトコルが関連性に関連していない場合（またはそれを関連付けるつもりがない場合）、AEへのQoS予約要求の認証が必要です。この場合、AEは、QoSリクエストを直径QoSプロトコル相互作用の一部として承認するために、QoS予約要求エンティティを認証する必要があります。
This document refers to three types of sessions that need to be properly correlated.
このドキュメントでは、適切に相関する必要がある3種類のセッションを指します。
QoS Signaling Session The time period during which a QoS signaling protocol establishes, maintains, and deletes a QoS reservation state at the QoS network element is referred to as a QoS signaling session. Different QoS signaling protocols use different ways to identify QoS signaling sessions. The same applies to different usage environments. Currently, this document supports three types of QoS session identifiers, namely a signaling session id (e.g., the Session Identifier used by the NSIS protocol suite), a flow id (e.g., identifier assigned by an application to a certain flow as used in the 3GPP), and a flow description based on the IP parameters of the flow's endpoints.
QoSシグナリングセッションQoSシグナリングプロトコルがQoSネットワーク要素でQoS予約状態を確立、維持、削除する期間は、QoSシグナリングセッションと呼ばれます。異なるQoSシグナル伝達プロトコルは、さまざまな方法を使用してQoSシグナリングセッションを識別します。同じことが異なる使用環境にも当てはまります。現在、このドキュメントは、3種類のQoSセッション識別子、つまりシグナリングセッションID（たとえば、NSISプロトコルスイートで使用されるセッション識別子）、フローID（例えば、特定のフローにアプリケーションによって割り当てられた識別子によって割り当てられた識別子によって使用される識別子がサポートされています。3GPP）、およびフローのエンドポイントのIPパラメーターに基づくフローの説明。
Diameter Authorization Session The time period for which a Diameter server authorizes a requested service (i.e., QoS resource reservation) is referred to as a Diameter authorization session. It is identified by a Session-Id included in all Diameter messages used for management of the authorized service (initial authorization, re-authorization, termination), see [RFC3588].
直径認証セッション直径サーバーが要求されたサービス（つまり、QoSリソース予約）を承認する期間は、直径認証セッションと呼ばれます。これは、認定サービスの管理に使用されるすべての直径メッセージに含まれるセッションIDによって識別されます（初期承認、再承認、終了）、[RFC3588]を参照してください。
Application-Layer Session The application-layer session identifies the duration of an application-layer service that requires provision of a certain QoS. An application-layer session identifier is provided by the QoS requesting entity in the QoS signaling messages, for example as part of the authorization token. In general, the application session identifier is opaque to the QoS-aware NEs. It is included in the authorization request message sent to the AE and helps it to correlate the QoS authorization request to the application session state information.
アプリケーション層セッションアプリケーション層セッションでは、特定のQOの提供が必要なアプリケーション層サービスの期間を識別します。承認トークンの一部として、アプリケーション層セッション識別子は、QoS信号メッセージのQoS要求エンティティによって提供されます。一般に、アプリケーションセッション識別子はQoS対応NESに不透明です。AEに送信された承認要求メッセージに含まれており、QoS認証リクエストをアプリケーションセッションの状態情報に相関させるのに役立ちます。
Correlating these sessions is done at each of the three involved entities: The QoS requesting entity correlates the application with the QoS signaling sessions. The QoS NE correlates the QoS signaling session with the Diameter authorization sessions. The AE SHOULD bind the information about the three sessions together. Note that in certain scenarios, not all of the sessions are present. For example, the application session might not be visible to the QoS signaling protocol directly if there is no binding between the application session and the QoS requesting entity using the QoS signaling protocol.
これらのセッションを相関させることは、関係する3つのエンティティのそれぞれで行われます。QoS要求エンティティは、アプリケーションをQoSシグナリングセッションと関連付けます。QoS NEは、QoSシグナリングセッションと直径認証セッションと相関しています。AEは、3つのセッションに関する情報を一緒に結合する必要があります。特定のシナリオでは、すべてのセッションが存在するわけではないことに注意してください。たとえば、アプリケーションセッションとQoSシグナリングプロトコルを使用してQoS要求エンティティの間にバインディングがない場合、アプリケーションセッションはQoSシグナリングプロトコルに直接表示されない場合があります。
Authorization models supported by this application include three parties:
このアプリケーションでサポートされている承認モデルには、次の3つの関係者が含まれます。
o Resource Requesting Entity
o エンティティを要求するリソース
o Network Elements (Diameter QoS application (DQA) client)
o ネットワーク要素（直径QoSアプリケーション（DQA）クライアント）
o Authorizing Entity (Diameter QoS application (DQA) server)
o 承認エンティティ（直径QoSアプリケーション（DQA）サーバー）
Note that the QoS RRE is only indirectly involved in the message exchange. This entity provides the trigger to initiate the Diameter QoS protocol interaction by transmitting QoS signaling messages. The Diameter QoS application is only executed between the Network Element (i.e., DQA client) and the Authorizing Entity (i.e., DQA server).
QOS RREは、メッセージ交換に間接的にのみ関与していることに注意してください。このエンティティは、QoSシグナリングメッセージを送信することにより、直径QoSプロトコル相互作用を開始するトリガーを提供します。直径QoSアプリケーションは、ネットワーク要素（つまり、DQAクライアント）と承認エンティティ（つまり、DQAサーバー）の間でのみ実行されます。
The QoS RRE may communicate with the AE using application-layer signaling for the negotiation of service parameters. As part of this application-layer protocol interaction, for example using SIP, authentication and authorization might take place. This message exchange is, however, outside the scope of this document. The protocol communication between the QoS resource requesting entity and the QoS NE might be accomplished using the NSIS protocol suite, RSVP, or a link-layer signaling protocol. A description of these protocols is also outside the scope of this document.
QoS RREは、サービスパラメーターの交渉のためにアプリケーション層シグナル伝達を使用してAEと通信する場合があります。このアプリケーション層プロトコルの相互作用の一部として、たとえばSIPの使用など、認証と承認が行われる場合があります。ただし、このメッセージ交換は、このドキュメントの範囲外です。エンティティとQoS NEを要求するQoSリソースとの間のプロトコル通信は、NSISプロトコルスイート、RSVP、またはリンク層シグナル伝達プロトコルを使用して達成される可能性があります。これらのプロトコルの説明は、このドキュメントの範囲外でもあります。
Pull and Push modes use a different set of command codes for session establishment. For other operations, such as session modification and termination, they use the same set of command codes.
プルモードとプッシュモードは、セッション確立に別のコマンドコードセットを使用します。セッションの変更や終了などの他の操作の場合、同じコマンドコードセットを使用します。
The selection of Pull mode or Push mode operation is based on the trigger of the QoS authorization session. When a QoS-Authorization-Request (QAR, see Section 5.1) message with a new Session-Id is received, the AE operates in Pull mode; when other triggers are received, the AE operates in Push mode. Similarly, when a QoS-Install-Request (QIR, see Section 5.3} with a new Session-Id is received, the NE operates in Push mode; when other triggers are received, the NE operates in Pull mode.
プルモードまたはプッシュモードの操作の選択は、QoS認証セッションのトリガーに基づいています。QOS-Authorization-Request（QAR、セクション5.1を参照）の新しいセッションIDを使用したメッセージが受信されると、AEはプルモードで動作します。他のトリガーを受信すると、AEはプッシュモードで動作します。同様に、QoS-Install-Request（QIR、セクション5.3を参照）を新しいセッションIDを受信すると、NEはプッシュモードで動作します。他のトリガーを受信すると、NEはプルモードで動作します。
The QoS authorization session is typically established per subscriber base (i.e., all requests with the same User-ID), but it is also possible to be established on a per node or per request base. The concurrent sessions between an NE and an AE are identified by different Session-Ids.
QoS認証セッションは通常、サブスクライバーベースごとに確立されます（つまり、同じユーザーIDを使用したすべてのリクエスト）が、ノードごとまたはリクエストベースで確立することもできます。NEとAEの間の同時セッションは、異なるセッションIDによって識別されます。
A request for a QoS reservation or local events received by an NE can trigger the initiation of a Diameter QoS authorization session. The NE converts the required objects from the QoS signaling message to Diameter AVPs and generates a QAR message.
NEが受け取ったQoS予約またはローカルイベントのリクエストは、直径QoS認証セッションの開始をトリガーできます。NEは、必要なオブジェクトをQoS信号メッセージから直径AVPに変換し、QARメッセージを生成します。
Figure 6 shows the protocol interaction between a Resource Requesting Entity, a Network Element, and the Authorizing Entity.
図6は、エンティティを要求するリソース、ネットワーク要素、および認可エンティティ間のプロトコル相互作用を示しています。
The AE's identity, information about the application session and/or identity and credentials of the QoS RRE, requested QoS parameters, and the signaling session identifier and/or QoS-enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent to the AE. The QAR is sent to a Diameter server that can be either the home server of the QoS requesting entity or an AppS.
AEのID、QoS RREのアプリケーションセッションおよび/またはアイデンティティおよび資格情報、QoSパラメーターの要求、および/またはQoS対応データフロー識別子は、それぞれの直径AVPにカプセル化され、直径に含まれる場合があります。AEに送信されたメッセージ。QARは、QoS要求のエンティティまたはアプリのホームサーバーのいずれかであることができる直径サーバーに送信されます。
+------------------------------------------+------------------------+
| QoS-Specific Input Data | Diameter AVPs |
+------------------------------------------+------------------------+
| Authorizing Entity ID (e.g., | Destination-Host |
| Destination-Host taken from | Destination-Realm |
| authorization token, Destination-Realm, | |
| or derived from the Network Access | |
| Identifier (NAI) of the QoS requesting | |
| entity) | |
| Authorization Token Credentials of the | QoS-Authorization-Data |
| QoS requesting entity | User-Name |
| QoS-Resources (including QoS parameters) | |
+------------------------------------------+------------------------+
Table 1: Mapping Input Data to QoS AVPs -- Pull Mode
表1：入力データのマッピングQOSAVPS-プルモード
Authorization processing starts at the Diameter QoS server when it receives the QAR. Based on the information in the QoS-Authentication-Data, User-Name, and QoS-Resources AVPs, the server determines the authorized QoS resources and flow state (enabled/ disabled) from locally available information (e.g., policy information that may be previously established as part of an application-layer signaling exchange or the user's subscription profile). The QoS-Resources AVP is defined in [RFC5777]. The authorization decision is then reflected in the response returned to the Diameter client with the QoS-Authorization-Answer (QAA) message.
承認処理は、QARを受信するときに直径QoSサーバーで始まります。QoS-authentication-Data、ユーザー名、およびQoSリソースAVPの情報に基づいて、サーバーは、ローカルで利用可能な情報（例えば、以前にある可能性のあるポリシー情報から認定されたQoSリソースとフロー状態（有効/無効）を決定します。アプリケーション層シグナリング交換またはユーザーのサブスクリプションプロファイルの一部として確立されています）。QOSリソースAVPは[RFC5777]で定義されています。承認決定は、QoS-Authorization-Answer（QAA）メッセージを使用して、Diameterクライアントに返される応答に反映されます。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
+---QoS-Reserve---->| |
| +- - - - - QAR - - - - - >|
| |(QoS-Resources, |
| | QoS-Auth-Data,User-ID)|
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| |< - - - - QAA - - - - - -+
| |(Result-Code, |
| |QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz session |
| | /Authz-time/ | QoS Responder
| | | Node
| +-------+---------+ |
| +----------QoS-Reserve---....--->|
| | |
| |<---------QoS-Response--....----|
|<--QoS-Response----+ |
| | |
|=====================Data Flow==============....===>|
Figure 6: Initial QoS Request Authorization for Pull Mode
図6：プルモードの初期QoSリクエスト承認
The Authorizing Entity keeps authorization session state and SHOULD save additional information for management of the session (e.g., Signaling-Session-Id, authentication data) as part of the session state information.
承認エンティティは認可セッションの状態を維持し、セッション状態情報の一部としてセッションの管理（シグナリングセッションID、認証データなど）の追加情報を保存する必要があります。
The final result of the authorization request is provided in the Result-Code AVP of the QAA message sent by the Authorizing Entity. In the case of successful authorization (i.e., Result-Code = DIAMETER_LIMITED_SUCCESS (see Section 7.1)), information about the authorized QoS resources and the status of the authorized flow (enabled/disabled) is provided in the QoS-Resources AVP of the QAA message. The QoS information provided via the QAA is installed by the QoS Traffic Control function of the NE. The value DIAMETER_LIMITED_SUCCESS indicates that the AE expects confirmation via another QAR message for successful QoS resource reservation and for final reserved QoS resources (see below).
承認要求の最終結果は、承認エンティティによって送信されたQAAメッセージの結果コードAVPで提供されます。承認が成功した場合（つまり、result-code = diameter_limited_success（セクション7.1を参照））、承認されたQoSリソースと承認されたフローのステータス（有効/無効）のステータスに関する情報がQAAのQOSリソースAVPで提供されますメッセージ。QAAを介して提供されるQoS情報は、NEのQoSトラフィックコントロール機能によってインストールされます。値diameter_limited_successは、AEが成功したQoSリソース予約および最終的な予約済みQoSリソースのために別のQARメッセージを介して確認を期待していることを示しています（以下を参照）。
One important piece of information returned from the Authorizing Entity is the authorization lifetime (carried inside the QAA). The authorization lifetime allows the NE to determine how long the authorization decision is valid for this particular QoS reservation. A number of factors may influence the authorized session duration, such as the user's subscription plan or the currently available credits at the user's account (see Section 8). The authorization duration is time-based, as specified in [RFC3588]. For an extension of the authorization period, a new QoS-Authorization-Request/Answer message exchange SHOULD be initiated. Further aspects of QoS authorization session maintenance are discussed in Sections 4.3, 4.4, and 8.
承認エンティティから返された重要な情報の1つは、認証寿命（QAA内にある）です。承認寿命により、NEは、この特定のQoS予約に対して認可決定が有効である期間を決定することができます。ユーザーのサブスクリプションプランやユーザーのアカウントで現在利用可能なクレジットなど、多くの要因が認定セッション期間に影響を与える可能性があります（セクション8を参照）。[RFC3588]で指定されているように、承認期間は時間ベースです。承認期間を延長するには、新しいQOS-Authorization-Request/Answerメッセージ交換を開始する必要があります。QoS認証セッションのメンテナンスのさらなる側面については、セクション4.3、4.4、および8で説明します。
The indication of a successful QoS reservation and activation of the data flow is provided by the transmission of a QAR message, which reports the parameters of the established QoS state: reserved resources, duration of the reservation, and identification of the QoS enabled flow/QoS signaling session. The Diameter QoS server acknowledges the reserved QoS resources with the QA Answer (QAA) message where the Result-Code is set to 'DIAMETER_SUCCESS'. Note that the reserved QoS resources reported in this QAR message MAY be different than those authorized with the initial QAA message, due to the QoS-signaling-specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path.
成功したQoS予約とデータフローのアクティブ化の兆候は、確立されたQOS状態のパラメーターを報告するQARメッセージの送信によって提供されます。予約リソース、予約期間、QOS対応フロー/QoSの識別シグナリングセッション。Diameter QoSサーバーは、結果コードが「diameter_success」に設定されているQA回答（QAA）メッセージを使用して、予約されたQoSリソースを認めます。このQARメッセージで報告されている予約されたQoSリソースは、QoSシグナル固有の動作（たとえば、1パス付きの1パス付きの承認を伴うレシーバーが開始する予約など）または特定のQAAメッセージで承認されたQAAメッセージとは異なる場合があることに注意してください。データパスに沿ったQoS交渉のプロセス。
The Diameter QoS server in the AE initiates a Diameter QoS authorization session upon the request for a QoS reservation triggered by application-layer signaling or by local events, and generates a QoS-Install-Request (QIR) message to the Diameter QoS client in the NE in which it maps required objects to Diameter payload objects.
AEの直径QoSサーバーは、アプリケーション層シグナリングまたはローカルイベントによってトリガーされるQoS予約を要求すると、直径QoS認証セッションを開始し、QoS-Install-Request（QIR）メッセージを生成します。NEでは、ペイロードオブジェクトを直径にするためにオブジェクトを必要としました。
Figure 7 shows the protocol interaction between the AE, a Network Element, and an RRE.
図7は、AE、ネットワーク要素、およびRRE間のプロトコル相互作用を示しています。
The NE's identity, information about the application session and/or identity and credentials of the QoS resource requesting entity, requested QoS parameters, and signaling session identifier and/or QoS enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent from a Diameter QoS server in the Authorizing Entity to a Diameter QoS client in the NE. This requires that the AE has knowledge of specific information for allocating and identifying the NE that should be contacted and the data flow for which the QoS reservation should be established. This information can be statically configured or dynamically discovered, see Section 4.2.3 for details.
NEのID、アプリケーションセッションに関する情報、および/またはQoSリソース要求のエンティティ、要求されたQoSパラメーター、シグナリングセッション識別子および/またはQoS有効なデータフロー識別子の要求のQoSリソースの資格情報は、それぞれの直径AVPにカプセル化され、直径に含まれる場合があります承認エンティティの直径QoSサーバーからNEの直径QoSクライアントに送信されるメッセージ。これには、AEが接触すべきNEを割り当てて特定するための特定の情報、およびQoS予約を確立する必要があるデータフローの知識を持っていることが必要です。この情報は、静的に構成または動的に検出できます。詳細については、セクション4.2.3を参照してください。
+-----------------------------------------+-------------------------+
| QoS-Specific Input Data | Diameter AVPs |
+-----------------------------------------+-------------------------+
| Network Element ID | Destination-Host |
| | Destination-Realm |
| Authorization Token Credentials of the | QoS-Authorization-Data |
| QoS requesting entity | User-Name |
| QoS-Resources (including QoS | |
| parameters) | |
+-----------------------------------------+-------------------------+
Table 2: Mapping Input Data to QoS AVPs -- Push Mode
表2：入力データのマッピングQOSAVPS-プッシュモード
Authorization processing starts at the Diameter QoS server when it receives a request from an RRE through an AppS (e.g., SIP Invite) or is triggered by a local event (e.g., a pre-configured timer). Based on the received information, the server determines the authorized QoS resources and flow state (enabled/disabled) from locally available information (e.g., policy information that may be previously established as part of an application-layer signaling exchange, or the user's subscription profile). The authorization decision is then reflected in the QoS-Install-Request (QIR) message to the Diameter QoS client.
承認処理は、アプリを介してRREからリクエストを受信する（SIP Inviteなど）、またはローカルイベント（事前に構成されたタイマーなど）によってトリガーされるときに、Diameter QoSサーバーで開始されます。受信した情報に基づいて、サーバーは、ローカルで利用可能な情報（例：アプリケーションレイヤーシグナリング交換の一部として以前に確立されたポリシー情報、またはユーザーのサブスクリプションプロファイルから認定されたQoSリソースとフロー状態（有効/無効）を決定します。）。承認決定は、QoS-Install-Request（QIR）メッセージにDiameter QoSクライアントへのメッセージに反映されます。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
| | |<-- Trigger --
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| | |
| |<-- - -- - QIR - - - - - -+
| |(Initial Request,Decision |
| |(QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz session |
| | /Authz-time/ |
| | |
| +-------+---------+
| + - - - - QIA - - - - - ->|
| | (Result-Code, |
| | QoS-Resources) |
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| | QoS Responder
| | Node
| | |
|=====================Data Flow==============....===>|
Figure 7: Initial QoS Request Authorization for Push Mode
図7：プッシュモードの初期QoS要求承認
The AE keeps authorization session state and SHOULD save additional information for management of the session (e.g., Signaling-Session-Id, authentication data) as part of the session state information.
AEは承認セッションの状態を維持しており、セッション状態情報の一部として、セッションの管理のための追加情報（たとえば、シグナリングセッションID、認証データ）を保存する必要があります。
The final result of the authorization decision is provided in the QoS-Resources AVP of the QIR message sent by the AE. The QoS information provided via the QIR is installed by the QoS Traffic Control function of the NE.
認可決定の最終結果は、AEが送信したQIRメッセージのQOSリソースAVPで提供されます。QIRを介して提供されるQoS情報は、NEのQoSトラフィックコントロール機能によってインストールされます。
One important piece of information from the AE is the authorization lifetime (carried inside the QIR). The authorization lifetime allows the NE to determine how long the authorization decision is valid for this particular QoS reservation. A number of factors may influence the authorized session duration, such as the user's subscription plan or the currently available credits at the user's account (see Section 8). The authorization duration is time-based as specified in [RFC3588]. For an extension of the authorization period, a new QoS-Install-Request/Answer message or QoS-Authorization-Request/Answer message exchange SHOULD be initiated. Further aspects of QoS authorization session maintenance are discussed in Sections 4.3, 4.4, and 8.
AEからの重要な情報の1つは、承認寿命（QIR内にある）です。承認寿命により、NEは、この特定のQoS予約に対して認可決定が有効である期間を決定することができます。ユーザーのサブスクリプションプランやユーザーのアカウントで現在利用可能なクレジットなど、多くの要因が認定セッション期間に影響を与える可能性があります（セクション8を参照）。[RFC3588]で指定されているように、承認期間は時間ベースです。承認期間を延長するには、新しいQoS-Install-Request/AnswerメッセージまたはQoS-Authorization-Request/Answerメッセージ交換を開始する必要があります。QoS認証セッションのメンテナンスのさらなる側面については、セクション4.3、4.4、および8で説明します。
The indication of QoS reservation and activation of the data flow can be provided by the QoS-Install-Answer message immediately. In the case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS, (see Section 7.1)) information is provided in the QIA message. Note that the reserved QoS resources reported in the QIA message may be different than those initially authorized with the QIR message, due to the QoS signaling-specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path. In the case that Multiple AEs control the same NE, the NE should make the selection on the authorization decision to be enforced based on the priority of the request.
QoS予約とデータフローのアクティブ化の兆候は、QoS-Install-Answerメッセージによってすぐに提供できます。施行が成功した場合、結果コード（= diameter_success、（セクション7.1を参照）を参照）情報がQIAメッセージに記載されています。QIAメッセージで報告されている予約されたQoSリソースは、QoSシグナリング固有の動作（たとえば、1パス付きの宣伝付きの1パスで開始された予約）または特定のプロセスにより、QIRメッセージで最初に承認されたQISリソースとは異なる場合があることに注意してください。データパスに沿ったQoS交渉の。複数のAESが同じNEを制御する場合、NEはリクエストの優先順位に基づいて実施される許可決定を選択する必要があります。
The Diameter QoS application node may obtain information of its peer nodes (e.g., Fully-Qualified Domain Name (FQDN), IP address) through static configuration or dynamic discovery as described in Section 5.2 of [RFC3588]. In particular, the NE shall perform the relevant operation for Pull mode; the AE shall perform the relevant operations for Push mode.
直径QoSアプリケーションノードは、[RFC3588]のセクション5.2で説明されているように、静的構成または動的発見を介して、ピアノード（例：完全に適格なドメイン名（FQDN）、IPアドレス）の情報を取得できます。特に、NEはプルモードに関連する操作を実行するものとします。AEは、プッシュモードに関連する操作を実行するものとします。
Upon receipt of a trigger to initiate a new Diameter QoS authorization session, the Diameter QoS application node selects and retrieves the location information of the peer node that is associated with the affected user based on some index information provided by the RRE. For instance, it can be the Authorization Entity's ID stored in the authorization token, the end-user identity (e.g., NAI [RFC4282]), or a globally routable IP address.
新しい直径QoS認証セッションを開始するトリガーを受信すると、直径QoSアプリケーションノードは、RREが提供するいくつかのインデックス情報に基づいて、影響を受けるユーザーに関連付けられているピアノードの位置情報を選択および取得します。たとえば、承認トークンに保存されている承認エンティティのID、エンドユーザーID（例：NAI [RFC4282]）、またはグローバルにルータブルIPアドレスです。
Client- and server-side initiated re-authorizations are considered in the design of the Diameter QoS application. Whether the re-authorization events are transparent for the resource requesting entity or result in specific actions in the QoS signaling protocol is outside the scope of the Diameter QoS application. It is directly dependent on the capabilities of the QoS signaling protocol.
クライアントおよびサーバー側の開始された再承認は、直径QoSアプリケーションの設計で考慮されます。再承認イベントがエンティティを要求するリソースに対して透明であるか、QoSシグナリングプロトコルで特定のアクションをもたらすかどうかは、直径QoSアプリケーションの範囲外です。QoSシグナリングプロトコルの機能に直接依存します。
There are a number of options for policy rules according to which the NE (AAA client) contacts the AE for re-authorization. These rules depend on the semantics and contents of the QAA message sent by the AE:
NE（AAAクライアント）が再承認のためにAEに連絡するポリシールールには多くのオプションがあります。これらのルールは、AEから送信されたQAAメッセージのセマンティクスと内容に依存します。
a. The QAA message contains the authorized parameters of the flow and its QoS and sets their limits (presumably upper). With these parameters, the AE specifies the services that the NE can provide and for which it will be financially compensated. Therefore, any change or request for change of the parameters of the flow and its QoS that do not conform to the authorized limits requires contacting the AE for authorization.
a. QAAメッセージには、フローとそのQoSの承認されたパラメーターが含まれており、制限（おそらく上部）を設定します。これらのパラメーターを使用すると、AEはNEが提供できるサービスを指定し、財政的に補償されます。したがって、フローのパラメーターとそのQoSの変更の変更または要求は、承認された制限に準拠していない場合、AEに連絡するために連絡する必要があります。
b. The QAA message contains authorized parameters of the flow and its QoS. The rules that determine whether parameters' changes require re-authorization are agreed out of band, based on a Service Level Agreement (SLA) between the domains of the NE and the AE.
b. QAAメッセージには、フローとそのQOの承認されたパラメーターが含まれています。NEとAEのドメイン間のサービスレベル契約（SLA）に基づいて、パラメーターの変更が再承認を必要とするかどうかを決定するルールは、バンドから合意されます。
c. The QAA message contains the authorized parameters of the flow and its QoS. Any change or request for change of these parameters requires contacting the AE for re-authorization.
c. QAAメッセージには、フローとそのQOの承認されたパラメーターが含まれています。これらのパラメーターの変更または変更の変更には、再承認のためにAEに連絡する必要があります。
d. In addition to the authorized parameters of the flow and its QoS, the QAA message contains policy rules that determine the NEs actions in case of a change or a request for change in authorized parameters.
d. FlowとそのQoSの承認されたパラメーターに加えて、QAAメッセージには、変更されたパラメーターの変更または変更の要求の場合のNESアクションを決定するポリシールールが含まれています。
Provided options are not exhaustive. Elaborating on any of the listed approaches is deployment/solution specific and is not considered in the current document.
提供されたオプションは網羅的ではありません。リストされているアプローチのいずれかについて詳しく説明することは、展開/ソリューション固有であり、現在のドキュメントでは考慮されていません。
In addition, the AE may use an RAR (Re-Authorization-Request) to perform re-authorization with the authorized parameters directly when the re-authorization is triggered by service request or local events/ policy rules.
さらに、AEはRAR（再承認済み）を使用して、サービスリクエストまたはローカルイベント/ポリシールールによって再承認がトリガーされた場合に、許可されたパラメーターで直接再承認を実行できます。
The AE provides the duration of the authorization session as part of the QoS-Authorization-Answer (QAA) message. At any time before the expiration of this period, a new QoS-Authorization-Request (QAR) message MAY be sent to the AE. The transmission of the QAR MAY be triggered when the NE receives a QoS signaling message that requires modification of the authorized parameters of an ongoing QoS session, or authorization lifetime expires.
AEは、QoS-Authorization-Answer（QAA）メッセージの一部として、承認セッションの期間を提供します。この期間の満了前はいつでも、新しいQOS-Authorization-Request（QAR）メッセージをAEに送信できます。QARの送信は、NEが進行中のQoSセッションの承認されたパラメーターの変更を必要とするQoS信号メッセージを受信したときにトリガーされる場合があります。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
|=====================Data Flow==========================>
| | |
| +-------+----------+ |
| |Authz-time/CC-Time| |
| | expires | |
| +-------+----------+ |
| +- - - - - QAR - - - - - >|
| |(QoS-Resources, |
| | QoS-Authorization-Data,User-ID) |
| +--------+--------------+
NOTE: | | Authorize request |
Re-authorization | | Update session data |
is transparent to | |/Authz-time,Session-Id/|
the End-Host | +--------+--------------+
|< - - - - QAA - - - - - -+
| |(Result-Code, |
| |QoS-Resources,Authz-time)|
| +-------+---------+ |
| |Update QoS state | |
| | + | |
| | Authz session | |
| | /Authz-time/ | |
| | | |
| +-------+---------+ |
| | |
|=====================Data Flow==========================>
| |
Figure 8: Client-side Initiated QoS Re-Authorization
図8：クライアント側が開始されたQoS再認可
The AE MAY initiate a QoS re-authorization by issuing a Re-Authorization-Request (RAR) message as defined in the Diameter base protocol [RFC3588], which may include the parameters of the re-authorized QoS state: reserved resources, duration of the reservation, identification of the QoS-enabled flow/QoS signaling session for re-installation of the resource state by the QoS Traffic Control function of the NE.
AEは、直径ベースプロトコル[RFC3588]で定義されている再承認（RAR）メッセージを発行することにより、QoSの再承認を開始することができます。NEのQoSトラフィックコントロール関数によるリソース状態を再インストールするためのQoS対応フロー/QoSシグナリングセッションの予約、識別。
An NE that receives such an RAR message with Session-Id matching a currently active QoS session acknowledges the request by sending the Re-Auth-Answer (RAA) message towards the AE.
現在アクティブなQoSセッションに一致するセッションIDでこのようなRARメッセージを受信するNEは、AEにReauth-Answer（RAA）メッセージを送信することにより、要求を認めます。
If the RAR does not include any parameters of the re-authorized QoS state, the NE MUST initiate a QoS re-authorization by sending a QoS-Authorization-Request (QAR) message towards the AE.
RARに再承認されたQoS状態のパラメーターが含まれていない場合、NEはQOS-Authorization-Request（QAR）メッセージをAEに送信することにより、QoS再認可を開始する必要があります。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
| | |<-- Trigger --
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| | |
| |<-- - -- - RAR - - - - - -+
| |(Request,Decision |
| |(QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz session |
| | /Authz-time/ |
| | |
| +-------+---------+
| + - - - - RAA - - - - - ->|
| | (Result-Code, |
| | QoS-Resources) |
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| | |
Figure 9: Server-Side Initiated QoS Re-Authorization
図9：サーバー側が開始されたQoS再認可
The authorization session for an installed QoS reservation state MAY be terminated by the Diameter client by sending a Session-Termination-Request (STR) message to the Diameter server with a response Session-Termination-Acknowledgement (STA) message. This is a Diameter base protocol function and it is defined in [RFC3588]. Session termination can be caused by a QoS signaling message requesting deletion of the existing QoS reservation state, or it can be caused as a result of a soft-state expiration of the QoS reservation state.
インストールされているQoS予約状態の承認セッションは、応答セッション-Termination-QualledEgement（STA）メッセージを使用して、セッションターミネーションリクエスト（STR）メッセージを直径サーバーに送信することにより、Diameterクライアントによって終了することができます。これは直径ベースプロトコル関数であり、[RFC3588]で定義されています。セッション終了は、既存のQoS予約状態の削除を要求するQoSシグナリングメッセージによって引き起こされる可能性があります。または、QoS予約状態のソフトステートの有効期限の結果として発生する可能性があります。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
|==Data Flow==>X /Stop of the data flow/ |
| | |
+---QoS-Reserve---->| |
| (Delete QoS +- - - - - STR - - - - - >|
| reservation) | +--------+--------------+
| | | Remove authorization |
| | | session state |
| | +--------+--------------+
| |< - - - - STA - - - - - -+
| +-------+--------+ |
| |Delete QoS state|
| +-------+--------+ QoS Responder
| | Node
| +----------QoS-Reserve-----....--->|
| | (Delete QoS |
| | reservation) |
| |<---------QoS-Response----....----+
|<--QoS-Response----+ |
Figure 10: Client-Side Initiated Session Termination
図10：クライアント側の開始セッション終了
At any time during a session, the AE MAY send an Abort-Session-Request (ASR) message to the NE. This is a Diameter base protocol function and it is defined in [RFC3588]. Possible reasons for initiating the ASR message to the NE are insufficient credits or session termination at the application layer. The ASR message results in termination of the authorized session, release of the reserved resources at the NE, and transmission of an appropriate QoS signaling message indicating a notification to other Network Elements aware of the signaling session.
セッション中はいつでも、AEはNEに中絶セッションレクエスト（ASR）メッセージを送信できます。これは直径ベースプロトコル関数であり、[RFC3588]で定義されています。ASRメッセージをNEに開始する可能性のある理由は、アプリケーションレイヤーでのクレジットまたはセッション終了が不十分です。ASRメッセージの結果、承認されたセッションの終了、NEでの予約されたリソースのリリース、および信号セッションを認識している他のネットワーク要素への通知を示す適切なQoSシグナリングメッセージの送信が発生します。
Authorizing
End-Host Network Element Entity
requesting QoS (Diameter (Diameter
QoS Client) QoS Server)
| | |
|=====================Data Flow==========================>
| |
| |< - - - - ASR - - - - - -+
| | |
|====Data Flow=====>X | QoS Responder
| | | Node
|<--QoS-Notify------+----------QoS-Reserve-----....--->|
| | (Delete QoS | |
| reservation) |
+-------+--------+ |
|Delete QoS state| |
+-------+--------+ |
+- - - - - ASA - - - - - >|
| +--------+--------------+
| | Remove authorization |
| | session state |
| +--------+--------------+
| QoS Responder
| Node
|<---------QoS-Response----....----+
| |
Figure 11: Server-Side Initiated Session Termination
図11：サーバー側の開始セッション終了
The Diameter QoS application requires the definition of new mandatory AVPs and Command-Codes (see Section 3 of [RFC3588]). Four new Diameter messages are defined along with Command-Codes whose values MUST be supported by all Diameter implementations that conform to this specification.
直径QoSアプリケーションには、新しい必須AVPとコマンドコードの定義が必要です（[RFC3588]のセクション3を参照）。4つの新しい直径メッセージは、この仕様に準拠するすべての直径の実装によって値をサポートする必要があるコマンドコードとともに定義されます。
+---------------------------+---------+------+-------------+
| Command Name | Abbrev. | Code | Reference |
+---------------------------+---------+------+-------------+
| QoS-Authorization-Request | QAR | 326 | Section 5.1 |
| QoS-Authorization-Answer | QAA | 326 | Section 5.2 |
| QoS-Install-Request | QIR | 327 | Section 5.3 |
| QoS-Install-Answer | QIA | 327 | Section 5.4 |
+---------------------------+---------+------+-------------+
Table 3: Diameter QoS Commands
表3：直径QoSコマンド
In addition, the following Diameter base protocol messages are used in the Diameter QoS application:
さらに、次の直径ベースプロトコルメッセージは、直径QoSアプリケーションで使用されます。
+-----------------------+---------+------+-----------+
| Command-Name | Abbrev. | Code | Reference |
+-----------------------+---------+------+-----------+
| Re-Auth-Request | RAR | 258 | [RFC3588] |
| Re-Auth-Answer | RAA | 258 | [RFC3588] |
| Abort-Session-Request | ASR | 274 | [RFC3588] |
| Abort-Session-Answer | ASA | 274 | [RFC3588] |
| Session-Term-Request | STR | 275 | [RFC3588] |
| Session-Term-Answer | STA | 275 | [RFC3588] |
+-----------------------+---------+------+-----------+
Table 4: Diameter Base Commands
表4：直径ベースコマンド
Diameter nodes conforming to this specification MAY advertise support for the Diameter QoS application by including the value of 9 in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, see [RFC3588].
この仕様に準拠した直径ノードは、Auth-Application-IDに9の値または機能のACCTアプリケーションID AVPに9の値を含めることにより、直径QoSアプリケーションのサポートを宣伝する場合があります。[RFC3588]を参照してください。
The value of 9 MUST be used as the Application-Id in all QAR/QAA and QIR/QIA commands.
9の値は、すべてのQAR/QAAおよびQIR/QIAコマンドのアプリケーションIDとして使用する必要があります。
The value of zero (0) SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and RAR/RAA commands.
ゼロ（0）の値は、すべてのSTR/STA、ASR/ASA、およびRAR/RAAコマンドのアプリケーションIDとして使用する必要があります。
The QoS-Authorization-Request (QAR) message, indicated by the Command-Code field (see Section 3 of [RFC3588]) being set to 326 and the 'R' bit being set in the Command Flags field, is used by NEs to request quality of service related resource authorization for a given flow.
コマンドコードフィールド（[RFC3588]のセクション3を参照）で示されるQOS-authorization-Request（QAR）メッセージは326に設定され、コマンドフラグフィールドに設定されている「R」ビットがNESによって使用されます。特定のフローのサービスに関連するリソース認証を要求します。
The QAR message MUST carry information for signaling session identification, AE identification, information about the requested QoS, and the identity of the QoS requesting entity. In addition, depending on the deployment scenario, an authorization token and credentials of the QoS requesting entity SHOULD be included.
QARメッセージは、シグナリングセッションの識別、AEの識別、要求されたQoSに関する情報、およびQoS要求エンティティのIDのための情報を掲載する必要があります。さらに、展開シナリオに応じて、QoS要求エンティティの承認トークンと資格情報を含める必要があります。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<QoS-Authorization-Request> ::= < Diameter Header: 326, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ User-Name ]
* [ QoS-Resources ]
[ QoS-Authorization-Data ]
[ Bound-Auth-Session-Id ]
* [ AVP ]
The QoS-Authorization-Answer (QAA) message, indicated by the Command-Code field being set to 326 and the 'R' bit being cleared in the Command Flags field, is sent in response to the QoS-Authorization-Request (QAR) message. If the QoS authorization request is successfully authorized, the response will include the AVPs to allow authorization of the QoS resources and transport plane gating information.
コマンドコードフィールドが326に設定され、コマンドフラグフィールドでクリアされている「R」ビットが設定されているQoS-authorization-Answer（QAA）メッセージは、QOS-Authorization-Request（QAR）に応じて送信されます。メッセージ。QoS認証リクエストが正常に承認された場合、回答にはAVPが含まれ、QoSリソースと輸送機のゲーティング情報の承認を許可します。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<QoS-Authorization-Answer> ::= < Diameter Header: 326, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
* [ QoS-Resources ]
[ Acct-Multisession-Id ]
[ Session-Timeout ]
[ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ]
* [ AVP ]
The QoS-Install Request (QIR) message, indicated by the Command-Code field being set to 327 and the 'R' bit being set in the Command Flags field, is used by the AE to install or update the QoS parameters and the flow state of an authorized flow at the transport plane element.
QoS-Install要求（QIR）メッセージは、コマンドコードフィールドが327に設定され、コマンドフラグフィールドに設定されている「R」ビットで示され、AEがQOSパラメーターとフローをインストールまたは更新するために使用されます。輸送面要素での承認されたフローの状態。
The message MUST carry information for signaling-session identification or identification of the flow to which the provided QoS rules apply, identity of the transport plane element, description of provided QoS parameters, flow state, and duration of the provided authorization.
このメッセージは、指定されたQoSルールが適用されるフロー、輸送平面要素の身元、提供されたQoSパラメーターの説明、フロー状態、および提供された承認の期間の信号セッションの識別または識別のための情報を伝える必要があります。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<QoS-Install-Request> ::= < Diameter Header: 327, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
* [ QoS-Resources ]
[ Session-Timeout ]
[ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ]
[ Authorization-Session-Volume ]
* [ AVP ]
The QoS-Install Answer (QIA) message, indicated by the Command-Code field being set to 327 and the 'R' bit being cleared in the Command Flags, field is sent in response to the QoS-Install Request (QIR) message for confirmation of the result of the installation of the provided QoS reservation instructions.
QoS-Install Answer（QIA）メッセージは、コマンドコードフィールドが327に設定され、コマンドフラグで「R」ビットがクリアされていることで示されています。提供されたQoS予約手順のインストールの結果の確認。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<QoS-Install-Answer> ::= < Diameter Header: 327, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
* [ QoS-Resources ]
* [ AVP ]
The Re-Auth-Request (RAR) message, indicated by the Command-Code field being set to 258 and the 'R' bit being set in the Command Flags field, is sent by the AE to the NE in order to initiate the QoS re-authorization from the DQA server side.
コマンドコードフィールドが258に設定され、コマンドフラグフィールドに設定されている「r」ビットが設定されているReauth-Request（RAR）メッセージは、QOSを開始するためにAEによってNEに送信されますDQAサーバー側からの再承認。
If the RAR command is received by the NE without any parameters of the re-authorized QoS state, the NE MUST initiate a QoS re-authorization by sending a QoS-Authorization-Request (QAR) message towards the AE.
RARコマンドが再承認されたQoS状態のパラメーターなしでNEによって受信された場合、NEはQOS-Authorization-Request（QAR）メッセージをAEに送信することにより、QoSの再承認を開始する必要があります。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ QoS-Resources ]
[ Session-Timeout ]
[ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ]
[ Authorization-Session-Volume ]
* [ AVP ]
The Re-Auth-Answer (RAA) message, indicated by the Command-Code field being set to 258 and the 'R' bit being cleared in the Command Flags field, is sent by the NE to the AE in response to the RAR command.
コマンドコードフィールドが258に設定され、コマンドフラグフィールドで「r」ビットがクリアされていることで示されるreauth-annwer（RAA）メッセージは、RARコマンドに応じてNEによってAEに送信されます。
The message format is defined as follows:
メッセージ形式は次のように定義されています。
<RAA> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Host-Max-Cache-Time ]
* [ Proxy-Info ]
* [ QoS-Resources ]
* [ AVP ]
The QoS application defines its own state machine that is based on the authorization state machine defined in Section 8.1 of the Diameter base protocol ([RFC3588]). The QoS state machine uses its own messages, as defined in Section 5, and QoS AVPs, as defined in Section 7.
QoSアプリケーションは、直径ベースプロトコル（[RFC3588]）のセクション8.1で定義されている認証状態マシンに基づいた独自の状態マシンを定義します。QoS状態マシンは、セクション5で定義されているように、セクション7で定義されているように、QOS AVPSを使用します。
Using the Diameter base protocol state machine as a basis, the following states are supplemented to the first two state machines in which the session state is maintained on the server. These MUST be supported in any QoS application implementations in support of server-initiated Push mode (see Section 4.2.2).
直径ベースプロトコル状態マシンを基礎として使用すると、次の状態は、セッション状態がサーバーに維持されている最初の2つの状態マシンに補完されます。これらは、サーバー開始プッシュモードをサポートするQOSアプリケーションの実装でサポートする必要があります（セクション4.2.2を参照）。
The following states are supplemented to the state machine on the server when state is maintained on the client, as defined in Section 8.1 of the Diameter base protocol[RFC3588]:
直径ベースプロトコル[RFC3588]のセクション8.1で定義されているように、クライアントに状態が維持されている場合、サーバー上の状態マシンに次の状態が補完されます。
SERVER, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle An application or local Send Pending
event triggers an initial QIR initial
QoS request to the server request
Pending Received QIA with a failed Clean up Idle Result-Code
失敗したクリーンアップアイドル結果コードでQIAを受け取った保留中
Pending Received QIA with Result-Code Update Open = SUCCESS session Pending Error in processing received Send Discon QIA with Result-Code = SUCCESS ASR
結果コードの更新でQIAを受け取った保留中オープン=成功セッション処理の保留中のエラーを受信した送信ディスコンQIAを伴うQIAを送信
The following states are supplemented to the state machine on the client when state is maintained on the server, as defined in Section 8.1 of the Diameter base protocol [RFC3588]:
直径ベースプロトコル[RFC3588]のセクション8.1で定義されているように、サーバー上に状態が維持されている場合、クライアントの状態マシンに次の状態が補完されます。
CLIENT, STATEFUL
State Event Action New State
-------------------------------------------------------------
Idle QIR initial request Send Open
received and successfully QIA initial
processed answer,
reserve
resources
Idle QIR initial request Send Idle
received but not QIA initial
successfully processed answer with
Result-Code
!= SUCCESS
Each of the AVPs identified in the QoS-Authorization-Request/Answer and QoS-Install-Request/Answer messages and the assignment of their value(s) is given in this section.
QOS-Authorization-Request/AnswerおよびQoS-Install-Request/Answerメッセージで識別された各AVPは、このセクションに記載されています。
The QoS application uses a number of session management AVPs, defined in the base protocol ([RFC3588]).
QoSアプリケーションは、ベースプロトコル（[RFC3588]）で定義されている多くのセッション管理AVPを使用します。
Attribute Name AVP Code Reference [RFC3588]
Origin-Host 264 Section 6.3
Origin-Realm 296 Section 6.4
Destination-Host 293 Section 6.5
Destination-Realm 283 Section 6.6
Auth-Application-Id 258 Section 6.8
Result-Code 268 Section 7.1
Auth-Request-Type 274 Section 8.7
Session-Id 263 Section 8.8
Authorization-Lifetime 291 Section 8.9
Auth-Grace-Period 276 Section 8.10
Session-Timeout 27 Section 8.13
User-Name 1 Section 8.14
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to Diameter applications. The value of the Auth-Application-Id for the Diameter QoS application is 9.
Auth-Application-ID AVP（AVPコード258）は、IANAによって直径アプリケーションに割り当てられています。直径QoSアプリケーションのAuth-Application-IDの値は9です。
This document reuses the AVPs defined in Section 4 of [RFC5777].
この文書は、[RFC5777]のセクション4で定義されているAVPを再利用します。
This section lists the AVPs that are introduced specifically for the QoS application. The following new AVPs are defined: Bound-Auth-Session-Id and the QoS-Authorization-Data AVP.
このセクションには、QoSアプリケーション専用に導入されたAVPをリストします。次の新しいAVPが定義されています：Bound-auth-session-idおよびqos-authorization-data avp。
The following table describes the Diameter AVPs newly defined in this document for use with the QoS Application, their AVP code values, types, possible flag values, and to determine whether the AVP may be encrypted.
次の表には、QoSアプリケーションで使用するためにこのドキュメントで新しく定義されている直径AVP、AVPコード値、タイプ、可能なフラグ値、およびAVPが暗号化されるかどうかを判断することを説明します。
+-------------------+
| AVP Flag rules |
+----------------------------------------------|----+--------+-----+
| AVP Section | | SHLD| MUST|
| Attribute Name Code Defined Data Type |MUST| NOT| NOT|
+----------------------------------------------+----+--------+-----+
|QoS-Authorization-Data 579 7.2 OctetString| M | | V |
|Bound-Auth-Session-Id 580 7.2 UTF8String | M | | V |
+----------------------------------------------+----+--------+-----+
|M - Mandatory bit. An AVP with the "M" bit set and its value MUST |
| be supported and recognized by a Diameter entity in order for |
| the message, which carries this AVP, to be accepted. |
|V - Vendor-specific bit that indicates whether the AVP belongs to |
| an address space. |
+------------------------------------------------------------------+
QoS-Authorization-Data The QoS-Authorization-Data AVP (AVP Code 579) is of type OctetString. It is a container that carries application-session or user-specific data that has to be supplied to the AE as input to the computation of the authorization decision.
QoS-authorization-data QoS-authorization-Data AVP（AVPコード579）は、タイプのオクテットストリングです。これは、許可決定の計算への入力としてAEに提供する必要があるアプリケーションセッションまたはユーザー固有のデータを搭載するコンテナです。
Bound-Authentication-Session-Id The Bound-Authentication-Session AVP (AVP Code 580) is of type UTF8String. It carries the ID of the Diameter authentication session that is used for the network access [RFC4005]. It is used to tie the QoS authorization request to a prior authentication of the end-host done by a co-located application for network access authentication ([RFC4005]) at the QoS NE.
Bound-authentication-session-id bound-authentication-session avp（AVPコード580）は、utf8stringのタイプです。ネットワークアクセス[RFC4005]に使用される直径認証セッションのIDを運びます。QoS NEのネットワークアクセス認証（[RFC4005]）の共同配置アプリケーションによって行われたエンドホストの事前認証にQoS認証リクエストを結び付けるために使用されます。
An NE MAY start an accounting session by sending an Accounting-Request (ACR) message after successful QoS reservation and activation of the data flow (see Figures 6 and 7). After every successful re-authorization procedure (see Figures 8 and 9), the NE MAY initiate an interim accounting message exchange. After successful session termination (see Figures 10 and 11), the NE may initiate a final exchange of accounting messages for the termination of the accounting session and report final records for the use of the QoS resources reserved. It should be noted that the two sessions (authorization and accounting) have independent management by the Diameter base protocol, which allows for finalizing the accounting session after the end of the authorization session.
NEは、データフローの予約とアクティブ化に成功した後、会計（ACR）メッセージを送信することにより、会計セッションを開始する場合があります（図6および7を参照）。成功したすべての再認可手順（図8および9を参照）の後、NEは暫定会計メッセージ交換を開始する場合があります。セッション終了が成功した後（図10および11を参照）、NEは会計セッションの終了のための会計メッセージの最終交換を開始し、予約されたQoSリソースの使用に関する最終記録を報告することができます。2つのセッション（承認と会計）は、承認セッションの終了後に会計セッションを最終化できる直径ベースプロトコルによって独立した管理を持っていることに注意する必要があります。
The detailed QoS accounting procedures are out of scope in this document.
このドキュメントでは、詳細なQoS会計手順は範囲外です。
This section presents an example of the interaction between the end-host and Diameter QoS application entities using Pull mode. The application-layer signaling is, in this example, provided using SIP. Signaling for a QoS resource reservation is done using the QoS NSIS Signaling Layer Protocol (NSLP). The authorization of the QoS reservation request is done by the Diameter QoS application (DQA).
このセクションでは、プルモードを使用して、エンドホストと直径のQoSアプリケーションエンティティ間の相互作用の例を示します。この例では、アプリケーション層シグナル伝達は、SIPを使用して提供されます。QoSリソース予約のシグナリングは、QoS NSISシグナル伝達層プロトコル（NSLP）を使用して行われます。QoS予約要求の承認は、Diameter QoSアプリケーション（DQA）によって行われます。
End-Host SIP Proxy Correspondent
requesting QoS (DQA Server) Node
| | |
..|....Application-layer SIP signaling.......|..............|..
. | Invite (SDP) | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
. | 100 Trying | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
. | +-.-.-.....-.-.> .
. | | 180 SDP' | .
. | <-.-.-.....-.-.+ .
. | +--------+--------+ | .
. | |Authorize session| | .
. | | parameters | | .
. | 180 (Session parameters) +--------+--------+ | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | .
..|..........................................|... ..........|..
| | |
| +------------+ | |
| | NE | | |
| |(DQA Client)| | |
| +------+-----+ | |
| | | |
|QoS NSLP Reserve | | |
+------------------> QAR | |
| (POLICY_DATA>v +- - - - -<<AAA>>- - - -> |
| QSPEC) v >===>(Destination-Host, | |
| v >=======>QoS-Authorization-Data++------------+ |
| >===========>QoS-Resources) |Authorize | |
| | |QoS resources| |
| | ++------------+ |
| | QAA | |
| <- - - - -<<AAA>>- - - -+ |
| |(Result-Code, | |
| |QoS-Resources, | |
| |Authorization-Lifetime)| |
| +---------+--------+ | |
| |Install QoS state1| | |
| |+ Authz session | | |
| +---------+--------+ | |
| |QoS NSLP Reserve |
| +---------------..............--------->
| | |
| | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+
<------------------+ |
| | QoS NSLP Query|
|QoS NSLP Query <---------------..............---------+
<------------------+ |
|QoS NSLP Reserve | |
+------------------> QAR | |
| +- - - - -<<AAA>>- - - -> |
| | +---+---------+ |
| | |Authorize | |
| | |QoS resources| |
| | QAA +---+---------+ |
| <- - - - -<<AAA>>- - - -+ |
| +---------+--------+ | |
| |Install QoS state2| |
| |+ Authz session | |
| +---------+--------+ |
| | QoS NSLP Reserve |
| +---------------..............--------->
| | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+
<------------------+ |
| | |
/------------------+--Data Flow---------------------------\
\------------------+--------------------------------------/
| | |
.-.-.-.-. SIP signaling
--------- QoS NSLP signaling
- - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol
Figure 12: QoS Authorization Example - Pull Mode
図12：QoS認証の例 - プルモード
The communication starts with SIP signaling between the two endpoints and the SIP proxy for negotiation and authorization of the requested service and its parameters (see Figure 12). As a part of the process, the SIP proxy verifies whether the user at Host A is authorized to use the requested service (and potentially the ability to be charged for the service usage). Negotiated session parameters are provided to the end-host.
通信は、2つのエンドポイント間のSIPシグナルと、要求されたサービスとそのパラメーターの交渉と承認のためのSIPプロキシとの間のSIPシグナリングから始まります（図12を参照）。プロセスの一環として、SIPプロキシは、ホストAのユーザーが要求されたサービスを使用することを許可されているかどうかを確認します（およびサービスの使用に課金される可能性があります）。交渉済みのセッションパラメーターは、エンドホストに提供されます。
Subsequently, Host A initiates a QoS signaling message towards Host B. It sends a QoS NSLP Reserve message, in which it includes description of the required QoS (QSPEC object) and authorization data for negotiated service session (part of the POLICY_DATA object). Authorization data includes, as a minimum, the identity of the AE (e.g., the SIP proxy) and an identifier of the application-service session for which QoS resources are requested.
その後、ホストAはホストBに向かってQoSシグナリングメッセージを開始します。これには、必要なQOS（QSPECオブジェクト）の説明と、ネゴシエートされたサービスセッション（policy_Dataオブジェクトの一部）の認証データの説明が含まれています。承認データには、少なくとも、AEのID（例：SIPプロキシ）と、QoSリソースが要求されるアプリケーションサービスセッションの識別子が含まれます。
A QoS NSLP reserve message is intercepted and processed by the first QoS-aware Network Element. The NE uses the Diameter QoS application to request authorization for the received QoS reservation request. The identity of the AE (in this case, the SIP server that is co-located with a Diameter server) is put into the Destination-Host AVP, any additional session authorization data is encapsulated into the QoS-Authorization-Data AVP, and the description of the QoS resources is included into the QoS-Resources AVP. These AVPs are included into a QoS Authorization Request message, which is sent to the AE.
QoS NSLPリザーブメッセージは、最初のQoS対応ネットワーク要素によって傍受および処理されます。NEは、Diameter QoSアプリケーションを使用して、受信したQoS予約要求の承認を要求します。AEのID（この場合、直径サーバーと共同住宅されたSIPサーバー）が宛先ホストAVPに入れられ、追加のセッション承認データがQoS-Authorization-Data AVPにカプセル化され、QoSリソースの説明は、QoSリソースAVPに含まれています。これらのAVPは、AEに送信されるQoS認証要求メッセージに含まれています。
A QAR message will be routed through the AAA network to the AE. The AE verifies the requested QoS against the QoS resources negotiated for the service session and replies with a QoS-Authorization-Answer (QAA) message. It carries the authorization result (Result-Code AVP) and the description of the authorized QoS parameters (QoS-Resources AVP), as well as duration of the authorization session (Authorization-Lifetime AVP).
QARメッセージは、AAAネットワークを介してAEにルーティングされます。AEは、サービスセッションのためにネゴシエートされたQoSリソースに対して要求されたQoSを検証し、QoS-Authorization-Answer（QAA）メッセージで返信します。承認結果（結果コードAVP）と承認されたQoSパラメーター（QOSリソースAVP）の説明、および承認セッションの期間（承認式AVP）が運ばれます。
The NE interacts with the Traffic Control function and installs the authorized QoS resources and forwards the QoS NSLP reserve message farther along the data path. Moreover, the NE may serve as a signaling proxy and process the QoS signaling (e.g., initiation or termination of QoS signaling) based on the QoS decision received from the Authorizing Entity.
NEはトラフィックコントロール機能と対話し、認定されたQoSリソースをインストールし、QoS NSLPリザーブメッセージをデータパスに沿ってさらに転送します。さらに、NEはシグナリングプロキシとして機能し、認可エンティティから受け取ったQOS決定に基づいてQOSシグナル伝達（QoSシグナルの開始または終了など）を処理する場合があります。
This section repeats the scenario outlined in Section 9.1; however, in this case, we show a session authorization failure instead of success. Failures can occur in various steps throughout the protocol execution, and in this example, we assume that the Diameter QAR request processed by the Diameter server leads to an unsuccessful result. The QAA message responds, in this example, with a permanent error "DIAMETER_AUTHORIZATION_REJECTED" (5003) set in the Result-Code AVP. When the NE receives this response, it discontinues the QoS reservation signaling downstream and provides an error message back to the end-host that initiated the QoS signaling request. The QoS NSLP response signaling message would in this case carry an INFO_SPEC object indicating the permanent failure as "Authorization failure" (0x02).
このセクションでは、セクション9.1で概説されているシナリオを繰り返します。ただし、この場合、成功の代わりにセッション許可失敗を示します。障害はプロトコルの実行全体でさまざまなステップで発生する可能性があり、この例では、直径サーバーによって処理される直径QAR要求が失敗した結果につながると仮定します。QAAメッセージは、この例では、結果コードAVPで設定された永続的なエラー「diameter_authorization_rejected」（5003）で応答します。NEがこの応答を受信すると、QoS予約シグナリングが下流にあることを中止し、QoSシグナリング要求を開始したエンドホストにエラーメッセージを提供します。QoS NSLP応答シグナル伝達メッセージは、この場合、「認証障害」（0x02）として永続的な障害を示すInfo_Specオブジェクトを運びます。
End-Host SIP Proxy Correspondent requesting QoS (DQA Server) Node
QOS（DQA Server）ノードを要求するエンドホストSIPプロキシ特派員
| | |
..|...................SIP Signaling..........|..............|..
. | Invite (SDP) | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
. | 100 Trying | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
. | +-.-.-.....-.-.> .
. | | 180 SDP' | .
. | <-.-.-.....-.-.+ .
. | +--------+--------+ | .
. | |Authorize session| | .
. | | parameters | | .
. | 180 (Session parameters) +--------+--------+ | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | .
..|..........................................|... ..........|..
| | |
| +------------+ | |
| | NE | | |
| |(DQA Client)| | |
| +------+-----+ | |
| | | |
|QoS NSLP Reserve | | |
+------------------> QAR | |
| (POLICY_DATA>v +- - - - -<<AAA>>- - - -> |
| QSPEC) v >===>(Destination-Host, | |
| v >=======>QoS-Authorization-Data++------------+ |
| >===========>QoS-Resources) |Authorize | |
| | |QoS resources| |
| | ++------------+ |
| | QAA | |
| <- - - - -<<AAA>>- - - -+ |
| |(Result-Code = 5003) | |
| | | |
|QoS NSLP Response | | |
|(with error 0x02) | | |
<------------------+ | |
| | | |
| | | |
.-.-.-.-. SIP signaling
--------- QoS NSLP signaling
- - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol
Figure 13: QoS Authorization Example - Pull Mode (Failure Case)
図13：QoS認証の例 - プルモード（障害ケース）
This section presents an example of the interaction between the end-host and Diameter QoS application entities using Push mode. The application-layer signaling is, in this example, provided using SIP. Signaling for a QoS resource reservation is done using the QoS NSLP. The authorization of the QoS reservation request is done by the Diameter QoS application (DQA).
このセクションでは、プッシュモードを使用して、エンドホストと直径のQoSアプリケーションエンティティ間の相互作用の例を示します。この例では、アプリケーション層シグナル伝達は、SIPを使用して提供されます。QoSリソース予約のシグナリングは、QoS NSLPを使用して行われます。QoS予約要求の承認は、Diameter QoSアプリケーション（DQA）によって行われます。
End-Host NE SIP Proxy Correspondent
requesting QoS (DQA Client) (DQA Server) Node
| | | |
..|..................|...SIP Signaling..........|..............|..
. | Invite(SDP Offer)| | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.->| .
. | | | 180 | .
. |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.-.| .
..|.............................................|..............|..
| | +---------+-------------+|
| | | Authorize Request ||
| | | Keep Session Data ||
| | |/Authz-time,Session-Id/||
| | +---------+-------------+|
| | | |
| |<-- - -- - QIR - -- - -- -+ |
| |(Initial Request,Decision | |
| |(QoS-Resources,Authz-time)| |
| +-------+---------+ | |
| |Install QoS State| | |
| | + | | |
| | Authz Session | | |
| | /Authz-time/ | | |
| +-------+---------+ | |
| + - - -- - QIA - - - - - ->| |
| | (Result-Code, | |
| | QoS-Resources) | |
| | +----------+------------+ |
| | | Successful | |
| | | QoS Reservation | |
| | +----------+------------+ |
..|.............................................|..............|..
. | | | | .
. | | | 200 OK (SDP)| .
. | | <-.-.-.....-.-.+ .
. | | +--------+-----------+ | .
. | | | Activate Session | | .
. | | | Parameters | | .
. | | +--------+-----------+ | .
. | 200 (SDP) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
..|.............................................|..............|..
| <- - - - - - RAR - - - - - + |
| +---------+--------+ | |
| |Activate QoS State| | |
| +---------+--------+ | |
| +- - - - - - RAA - - - - - > |
| | |
/------------------+-----Data Flow---------------------------\
\------------------+-----------------------------------------/
| | |
.-.-.-.-. SIP signaling
- - - - - Diameter QoS Application messages
Figure 14: QoS Authorization Example - Push Mode
図14：QoS認証の例 - プッシュモード
The communication starts with SIP signaling between the two endpoints and the SIP proxy for negotiation and authorization of the requested service and its parameters (see Figure 14). As a part of the process, the SIP proxy verifies whether the user at Host A is authorized to use the requested service (and potentially the ability to be charged for the service usage).
通信は、2つのエンドポイントと、要求されたサービスとそのパラメーターの交渉と承認のためのSIPプロキシの間のSIPシグナル伝達から始まります（図14を参照）。プロセスの一環として、SIPプロキシは、ホストAのユーザーが要求されたサービスを使用することを許可されているかどうかを確認します（およびサービスの使用に課金される可能性があります）。
A few implementation choices exist regarding the decision about when to initiate the QoS reservation. [MMUSIC-MEDIA] discusses this aspect with a focus on firewalling. In the example above, the DQA server is triggered to authorize the QoS request based on session parameters from the Session Description Protocol (SDP) payload. It will use a QIR message to do so. For this example message flow, we assume a two-stage commit, i.e., the SIP proxy interacts with the NE twice. First, it only prepares the QoS reservation, and then, with the arrival of the 200 OK, the QoS reservation is activated.
QoS予約をいつ開始するかについての決定に関して、いくつかの実装の選択肢が存在します。[mmusic-media]この側面については、ファイアウォールに焦点を当てて議論します。上記の例では、DQAサーバーがトリガーされ、セッション説明プロトコル（SDP）ペイロードのセッションパラメーターに基づいてQoS要求を承認します。QIRメッセージを使用して使用します。この例のメッセージフローでは、2段階のコミット、つまりSIPプロキシがNEと2回相互作用すると仮定します。まず、QoS予約のみを準備し、その後、200 OKの到着とともにQoS予約がアクティブになります。
This example does not describe how the DQA server learns which DQA client to contact. We assume pre-configuration in this example. In any case, the address of the DQA client is put into the Destination-Host AVP, the description of the QoS resources is included into the QoS-Resources AVP, and the duration of the authorization session is carried in the Authorization-Lifetime AVP.
この例では、DQAサーバーがどのDQAクライアントに連絡するかをどのように学習するかについては説明していません。この例では、事前構成を想定しています。いずれにせよ、DQAクライアントのアドレスが宛先ホストAVPに配置され、QoSリソースの説明はQoSリソースAVPに含まれ、承認セッションの期間は承認式AVPに運ばれます。
When the DQA client receives the QIR, it interacts with the Traffic Control function and reserves the authorized QoS resources accordingly. At this point in time, the QoS reservation is not yet activated.
DQAクライアントがQIRを受信すると、トラフィックコントロール機能と対話し、それに応じて認定されたQoSリソースを留保します。この時点で、QoS予約はまだアクティブ化されていません。
When a 200 OK is returned, the DQA server may verify the accepted QoS against the pre-authorized QoS resources and send a Diameter RAR message to the DQA client in the NE for activating the installed policies and commit the resource allocation.
200 OKが返されると、DQAサーバーは、事前に認可されたQoSリソースに対して受け入れられているQoSを検証し、インストールされたポリシーをアクティブにするためにNEのDQAクライアントに直径RARメッセージを送信し、リソース割り当てをコミットできます。
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.
このセクションには、この仕様で作成されたか、IANAが管理する既存の名前空間に値を割り当てた名前空間が含まれています。
IANA has allocated two AVP codes to the registry defined in [RFC3588]:
IANAは、[RFC3588]で定義されているレジストリに2つのAVPコードを割り当てました。
Registry:
AVP Code AVP Name Reference
-----------------------------------------------------------
579 QoS-Authorization-Data Section 7.2
580 Bound-Auth-Session-Id Section 7.2
IANA has allocated the following application ID from the registry defined in [RFC3588] (using the next available value from the 7-16777215 range).
IANAは、[RFC3588]で定義されたレジストリから次のアプリケーションIDを割り当てました（7-16777215範囲から次の利用可能な値を使用）。
Registry:
ID values Name Reference
-----------------------------------------------------------
9 Diameter QoS application Section 5
IANA has allocated command code values from the registry defined in [RFC3588].
IANAは、[RFC3588]で定義されたレジストリからコマンドコード値を割り当てました。
Registry:
Code Value Name Reference
-----------------------------------------------------------
326 QoS-Authorization-Request (QAR) Section 5.1
326 QoS-Authorization-Answer (QAA) Section 5.2
327 QoS-Install-Request (QIR) Section 5.3
327 QoS-Install-Answer (QIA) Section 5.4
This document describes a mechanism for performing authorization of a QoS reservation at a third-party entity. The Authorizing Entity needs sufficient information to make such an authorization decision and this information may come from various sources, including the application-layer signaling, the Diameter protocol (with its security mechanisms), policy information stored available with a AAA server, and a QoS signaling protocol.
このドキュメントでは、サードパーティのエンティティでQoS予約の承認を実施するメカニズムについて説明します。認可エンティティは、そのような承認決定を下すのに十分な情報を必要とし、この情報はアプリケーション層シグナリング、直径プロトコル（そのセキュリティメカニズムを備えた）、AAAサーバーで利用可能なポリシー情報、QoSなど、さまざまなソースから得られる可能性があります。シグナリングプロトコル。
Below there is a discussion about considerations for the Diameter QoS interaction between an Authorizing Entity and a Network Element. Security between the Authorizing Entity and the Network Element has a number of components: authentication, authorization, integrity, and confidentiality.
以下に、認可エンティティとネットワーク要素の間の直径QoS相互作用に関する考慮事項に関する議論があります。認証、認証、承認、整合性、および機密性という多くのコンポーネントがあります。
Authentication refers to confirming the identity of an originator for all datagrams received from the originator. Lack of authentication of Diameter messages between the Authorizing Entity and the Network Element can seriously jeopardize the fundamental service rendered by the Network Element. A consequence of not authenticating the message sender by the Network Element would be that an attacker could spoof the identity of a "legitimate" Authorizing Entity in order to allocate resources, change resource assignments, or free resources. The adversary can also manipulate the state at the Network Element in such a way that it leads to a denial-of-service attack by, for example, setting the allowed bandwidth to zero or allocating the entire bandwidth available to a single flow.
認証とは、オリジネーターから受信したすべてのデータグラムのオリジネーターの身元を確認することを指します。認証エンティティとネットワーク要素間の直径メッセージの認証の欠如は、ネットワーク要素によって提供される基本的なサービスを著しく危険にさらす可能性があります。ネットワーク要素によってメッセージ送信者を認証しないことの結果、攻撃者がリソースを割り当て、リソースの割り当てを変更する、または無料リソースを割り当てるために、「正当な」承認エンティティの身元を広めることができるということです。敵は、たとえば、許可された帯域幅をゼロに設定するか、単一のフローで利用可能な帯域幅全体を割り当てることにより、サービス拒否攻撃につながるように、ネットワーク要素で状態を操作することもできます。
A consequence of not authenticating the Network Element to an Authorizing Entity is that an attacker could impact the policy-based admission control procedure operated by the Authorizing Entity that provides a wrong view of the resources used in the network. Failing to provide the required credentials should be subject to logging.
ネットワーク要素を認証エンティティに認証しなかった結果、攻撃者は、ネットワークで使用されているリソースの誤ったビューを提供する認可エンティティによって運営されるポリシーベースのアドミッション管理手順に影響を与える可能性があるということです。必要な資格情報の提供に失敗すると、ロギングの対象となる必要があります。
Authorization refers to whether a particular Authorizing Entity is authorized to signal a Network Element with requests for one or more applications, adhering to a certain policy profile. Failing the authorization process might indicate a resource theft attempt or failure due to administrative and/or credential deficiencies. In either case, the Network Element should take the proper measures to log such attempts.
承認とは、特定のポリシープロファイルを順守して、特定の認可エンティティが1つ以上のアプリケーションを要求してネットワーク要素を信号することを許可されているかどうかを指します。許可プロセスに失敗すると、管理および/または資格の欠陥によるリソースの盗難の試みまたは失敗が示される可能性があります。どちらの場合でも、ネットワーク要素は、そのような試みを記録するための適切な措置を講じる必要があります。
Integrity is required to ensure that a Diameter message has not been maliciously altered. The result of a lack of data integrity enforcement in an untrusted environment could be that an imposter will alter the messages exchanged between a Network Entity and an Authorizing Entity potentially causing a denial of service.
直径メッセージが悪意を持って変更されていないことを確認するには、整合性が必要です。信頼されていない環境におけるデータの整合性施行の不足の結果、詐欺師がネットワークエンティティと承認エンティティとの間で交換されるメッセージを変更する可能性があることが、サービスの拒否を引き起こす可能性があることです。
Confidentiality protection of Diameter messages ensures that the signaling data is accessible only to the authorized entities. When signaling messages from the Application Server (via the Authorizing Entity towards the Network Element) traverse untrusted networks, lack of confidentiality will allow eavesdropping and traffic analysis. Additionally, Diameter QoS messages may carry authorization tokens that require confidentiality protection.
直径メッセージの機密性保護により、信号データに認可されたエンティティのみがアクセスできるようになります。（ネットワーク要素に向けて承認エンティティを介して）アプリケーションサーバーからメッセージを信号すると、信頼できないネットワークを横断すると、機密性が不足すると、盗聴とトラフィック分析が可能になります。さらに、直径のQoSメッセージには、機密保護が必要な承認トークンが搭載される場合があります。
Diameter offers security mechanisms to deal with the functionality demanded in the paragraphs above. In particular, Diameter offers communication security between neighboring Diameter peers using Transport Layer Security (TLS) or IPsec. Authorization capabilities are application specific and part of the overall implementation.
直径は、上記の段落で要求されている機能に対処するためのセキュリティメカニズムを提供します。特に、直径は、トランスポートレイヤーセキュリティ（TLS）またはIPSECを使用して、隣接する直径ピア間の通信セキュリティを提供します。承認機能はアプリケーション固有であり、全体的な実装の一部です。
The authors would like to thank John Loughney and Allison Mankin for their input to this document. In September 2005, Robert Hancock, Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis, and Elwyn Davies provided a detailed review. Robert also provided us with good feedback earlier in 2005. Jerry Ash provided us review comments in late 2005/early 2006. Rajith R provided some inputs to the document in early 2007.
著者は、ジョン・ラフニーとアリソン・マンキンがこの文書に入力してくれたことに感謝したいと思います。2005年9月、ロバートハンコック、ジュッカマナー、コーネリアカプラー、Xiaoming Fu、Georgios Karagiannis、およびElwyn Daviesが詳細なレビューを提供しました。ロバートはまた、2005年の初めに良いフィードバックを提供してくれました。ジェリー・アッシュは2005年後半/2006年初頭にレビューコメントを提供しました。RajithRは2007年初頭に文書にいくつかの入力を提供しました。
We would also like to thanks Alexey Melnikov, Adrian Farrel, and Robert Sparks for their IESG reviews.
また、Alexey Melnikov、Adrian Farrel、およびRobert SparksのIESGレビューにも感謝します。
The authors would like to thank Tseno Tsenov and Frank Alfano for starting the Diameter Quality of Service work within the IETF, for their significant contributions and for being the driving force for the first few draft versions.
著者は、IETF内の直径のサービス品質作業を開始し、重要な貢献と最初の数少ないドラフトバージョンの原動力であることについて、Tseno TsenovとFrank Alfanoに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of Service Parameters for Usage with Diameter", RFC 5624, August 2009.
[RFC5624] Korhonen、J.、Tschofenig、H。、およびE. Davies、「直径の使用のためのサービスの質」、RFC 5624、2009年8月。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M。、およびA. Lior、「直径の交通分類とサービス品質（QoS）属性」、RFC 5777、2010年2月。
[MMUSIC-MEDIA] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, March 2009.
[Mmusic-Media] Stucker、B。およびH. Tschofenig、「メディアパスに沿ったシグナリングプロトコル通信のためのミドルボックスインタラクションの分析」、2009年3月、進行中の作業。
[NSIS-NTLP] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet Signalling Transport", Work in Progress, June 2009.
[NSIS-NTLP] Schulzrinne、H。およびM. Stiemerling、「Gist：General Internet Signaling Transport」、2009年6月、進行中の作業。
[NSIS-QOS] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, January 2010.
[NSIS-QOS] Mather、J.、Karagiannis、G。、およびA. McDonald、「サービス品質シグナル伝達のためのNSLP」、2010年1月の作業。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「政策ベースの入場管理の枠組み」、RFC 2753、2000年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) Extensions for Media Authorization", RFC 3313, January 2003.
[RFC3313] Marshall、W。、「プライベートセッション開始プロトコル（SIP）メディア認可の拡張」、RFC 3313、2003年1月。
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003.
[RFC3520] Hamer、L-N。、Gage、B.、Kosinski、B。、およびH. Shieh、「セッション認証政策要素」、RFC 3520、2003年4月。
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003.
[RFC3521] Hamer、L-N。、Gage、B。、およびH. Shieh、「メディア認可とのセットアップのフレームワーク」、RFC 3521、2003年4月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
Authors' Addresses
著者のアドレス
Dong Sun (editor) Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 USA
ドンサン（編集者）アルカテル - ルーセント600マウンテンアベニューマレーヒル、ニュージャージー07974 USA
Phone: +1 908 582 2617
EMail: d.sun@alcatel-lucent.com
Peter J. McCann Motorola Labs 1301 E. Algonquin Rd Schaumburg, IL 60196 USA
Peter J. McCann Motorola Labs 1301 E. Algonquin Rd Schaumburg、IL 60196 USA
Phone: +1 847 576 3440
EMail: pete.mccann@motorola.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Tina Tsou Huawei Shenzhen, P.R.C
Tina Tsou Huawei Shenzhen、P.R.C
EMail: tena@huawei.com
Avri Doria Lulea University of Technology Arbetsvetenskap Lulea, SE-97187 Sweden
Avri Doria Lulea Technology Arbetsvetenskap Lulea、SE-97187スウェーデン
EMail: avri@ltu.se
Glen Zorn (editor)
Network Zen
1310 East Thomas Street
#306
Seattle, Washington 98102
USA
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net