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
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.
本文档描述Diameter服务质量（QoS）应用程序的框架、消息和过程。Diameter QoS应用程序允许网元在网络中分配QoS资源时与Diameter服务器交互。特别是，定义了两种操作模式，即“拉”和“推”。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请审阅这些文件
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.
请仔细阅读，因为他们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
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.
本文档描述Diameter[RFC3588]服务质量（QoS）应用程序的框架、消息和过程。Diameter QoS应用程序允许网元（NE）在网络中分配QoS资源时与Diameter服务器交互。
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.
定义了两种操作模式。在第一种称为“拉”模式中，网元基于沿数据路径到达的某个触发器（例如QoS信令协议）从Diameter服务器请求QoS授权。在第二种称为“推送”模式下，Diameter服务器主动向网元发送命令以安装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.
指定了一组命令代码，允许单个Diameter QoS应用程序服务器根据网络技术、部署场景和终端主机功能的要求同时支持拉模式和推模式。结合[RFC5777]和[RFC5624]中定义的Diameter属性值对（AVP），本文档描述了用于建立、修改和终止Diameter 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].
本文件定义了许多直径编码的AVP，这些AVP使用改进版的增广巴科斯诺尔表（ABNF）进行描述，参见[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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用户代理是一种应用程序端点。
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服务器是一种应用服务器。
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应用程序的Diameter服务器。它负责授权特定应用程序流或聚合的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应用程序的Diameter客户端。该实体触发拉模式下的协议交互，它是推模式下QoS信息的接收者。网元上的Diameter客户端对应于策略实施点（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.
Diameter QoS应用程序在NE（充当Diameter客户端）和资源AE（充当Diameter服务器）之间运行。图1显示了最终架构的高级图。
+-------+---------+
| Authorizing |
| Entity |
|(Diameter Server)|
+-------+---------+
|
|
/\-----+-----/\
//// \\\\
|| AAA Cloud ||
| (Diameter application) |
|| ||
\\\\ ////
\-------+-----/
|
+---+--+ +-----+----+ +---+--+
| | | NE | | | Media
+ NE +===+(Diameter +===+ NE +=============>>
| | | Client) | | | Flow
+------+ +----------+ +------+
+-------+---------+
| 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描述了媒体流需要通过的网元、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.
在某些部署场景中，网元可能会基于传入的QoS保留请求通过AAA云请求授权。网元将请求路由到指定的AE。AE将返回授权决策的结果。在其他部署场景中，授权将在动态应用程序状态下启动，因此必须根据来自一个或多个应用程序的信息对请求进行身份验证和授权。在接收到来自应用程序或网元的授权请求后，AE决定适当的模式（即推或拉）。推或拉模式的使用可由授权实体静态或动态确定。静态确定可能基于授权实体中定义的可配置策略，而动态确定可能基于从应用程序服务器接收的信息。对于推送模式，授权实体需要识别需要将QoS授权信息推送到的适当网元。它可能会根据从应用程序接收到的信息（如媒体流的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.
在某些部署场景中，存在接入网络类型和服务逻辑之间的映射（例如，推送或拉送模式的选择以及资源许可和控制的其他区别处理）。接入网络类型可能来自应用程序或网元的授权请求，在这种情况下，授权实体可以基于映射识别相应的服务逻辑。
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是否与应用程序通信，网元和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
+-------------------------------------------------------+
| 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保留请求的处理包括三个操作：接纳控制、授权和资源保留。
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.
准入控制功能提供有关可用资源的信息，并确定是否有足够的资源来满足请求。授权由Diameter客户端执行，包括通过第3节所示的AAA云联系授权实体。如果两个检查都成功，则在数据包分类器和数据包调度器中设置授权的QoS参数。请注意，传递给流量控制功能的参数可能不同于请求QoS的参数（取决于授权决策）。一旦请求的资源被授予，资源管理功能将通过Diameter客户端向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类别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]）请求资源。
3.2.2. Interaction Modes between the Authorizing Entity and Network Element
3.2.2. 授权实体与网元的交互方式
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]。在IntServ方案中，网络信令（例如，RSVP、NSIS或链路特定信令）通常用于从AppE发起对期望QoS资源的请求。在Diffserv方案中，QoS资源是基于一些预定义的QoS服务类而不是AppE发起的、基于流的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类AppEs无法通过网络信令发起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授权系统和底层网元之间的交互模式不同。当第3类端点采用IntServ方案时，当从该端点接收到诸如网络QoS信令之类的触发时，授权过程通常由NE发起。在区分服务方案中，由于网元无法主动请求资源授权，因此授权过程通常由apps请求或运营商定义的策略触发。
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能力：推模式和拉模式。
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（即Diameter服务器）应该能够启动Diameter授权会话，以便在没有来自网元的任何预先建立的连接的情况下与NE（即Diameter客户端）通信。
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的请求生成授权决策。为了支持拉模式，网元（即Diameter客户端）将启动Diameter授权会话以与授权实体（即Diameter服务器）通信。
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、以太网和支持区分服务的IP/MPLS。拉模式更适合于支持IntServ的IP网络或某些无线网络，如第三代合作伙伴计划（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.
拉式模式存在三种基本授权方案：一种是两方方案，两种是三方方案。这里采用的符号是关于执行QoS授权（QoS Authz）的实体的。QoS请求实体的认证可以作为QoS信令协议的一部分在NE处完成，或者通过非路径协议（在应用层上或用于网络接入认证）完成，或者AE可以与QoS请求实体的认证和授权请求联系。从Diameter QoS应用程序的角度来看，这些方案需要携带的信息类型不同。这里我们重点讨论“基本三方方案”（见图3）和“基于令牌的三方方案”（见图4）。在“两方方案”中，QoS RRE由网元进行身份验证，授权决策要么在网元本身本地做出，要么卸载到可信实体（最有可能在同一管理域内）。在双方情况下，不需要Diameter 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
+--------------+
| 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：三方计划
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.
在“基本三方方案”中，到达网元的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 |
+-------------+ +--------------+
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：基于令牌的三方方案
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].
“基于令牌的三方方案”适用于使用先前协议交互来请求授权令牌以协助网元或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
QoS RRE可涉及应用层协议交互，例如，使用SIP[RFC3313]与AE。作为此交互的一部分，可能会在应用程序层进行身份验证和授权。作为可能涉及用户的家庭AAA服务器的成功授权决策的结果，授权令牌由AE（例如，SIP代理和SIP代理信任的实体）生成，并返回给终端主机以包含在QoS信令协议中。授权令牌将由接收QoS信令消息的NE用于授权QoS请求。或者，Diameter QoS应用程序将用于将授权令牌转发到用户的家庭网络。授权令牌允许在应用层执行的授权决策与相应的QoS信令会话相关联。请注意，授权令牌可能是指与授权决策有关的已建立状态，或者令牌本身可能携带授权参数（由数字签名或密钥消息摘要保护以防止篡改）。在后一种情况下
authorization token may contain several pieces of information pertaining to the authorized application session, but at minimum it should contain:
授权令牌可能包含与授权应用程序会话相关的多条信息，但至少应包含：
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还可以在一些IP滤波器指示中使用这些端口号来指示执行QoS预留的NE，以便它可以正确地隧道入站分组。执行QoS预留的NE将QoS资源请求实体的IP地址和IP过滤器指示转发给QoS授权请求中的AE。AE将使用QoS RRE的IP地址和IP筛选器指示中的端口号（与先前应用层协议交互中公布的端口号相匹配），以识别要发送到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.
推送模式可进一步分为两种类型：端点启动和网络启动。在前一种情况下，授权过程由应用通过应用信令（例如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
在端点发起方案中，QoS-RRE（即，AppE）确定所需的应用级QoS，并通过应用信令消息发送QoS请求。这些应用程序将提取应用程序级别的QoS信息，并触发AE的授权过程。在网络启动方案中，AE和/或
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属性时，应用程序应根据应用程序属性、订阅和端点功能派生并确定QoS需求。AE根据应用级QoS信息、网络策略、最终用户订阅、网络资源可用性等做出授权决策，并将该决策直接安装到网元。
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 |
+-------------+ +--------------+
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:
QoS应用程序必须满足一系列适用于各种网络环境和服务的要求。它应该与具有特定QoS信令模型和安全问题的不同部署场景兼容。当与QoS信令协议交互工作时，满足下列要求的Diameter QoS应用程序应适应QoS信令协议的功能，而不是对其引入功能要求。此处提供了QoS授权应用程序的要求列表：
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.
基于身份的路由Diameter 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).
灵活的身份验证支持Diameter 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保留和应用程序状态Diameter QoS应用程序必须携带足够的信息，以便应用程序识别适当的应用程序会话并将其与特定QoS保留关联。
Dynamic Authorization It MUST be possible for the Diameter QoS application to push updates towards the NE(s) from Authorizing Entities.
动态授权Diameter QoS应用程序必须能够从授权实体向网元推送更新。
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.
承载选通Diameter 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.
记帐记录Diameter 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.
发送记帐记录网元应该能够向记帐实体发送特定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.
故障通知Diameter QoS应用程序必须允许网元向授权实体报告故障，例如由于移动节点的移动或数据包丢失的其他原因导致的连接丢失。
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.
会计关联Diameter 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应用程序的交互与其他AAA应用程序（如Diameter Network Access Server应用程序[RFC4005]）的交互可能是交换授权、身份验证和记帐信息所必需的。
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保留请求实体（例如，用户）的认证通过Diameter QoS应用协议交互之外的方式完成的部署场景中，仅通过QoS授权请求联系AE。认证可能已经通过与Diameter应用程序[RFC4005]的交互或作为QoS信令协议的一部分（例如，通用互联网信令传输（GIST）协议[NSIS-NTLP]中的传输层安全（TLS）[RFC5246]）进行。
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.
如果特定的Diameter QoS应用协议不能与先前的认证相关（或者如果无意将其相关），则需要向AE认证QoS保留请求实体。在这种情况下，AE必须验证QoS保留请求实体，以便将QoS请求授权为Diameter QoS协议交互的一部分。
This document refers to three types of sessions that need to be properly correlated.
本文档涉及需要适当关联的三种类型的会话。
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信令会话。这同样适用于不同的使用环境。目前，本文档支持三种类型的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].
Diameter授权会话Diameter服务器授权请求的服务（即QoS资源保留）的时间段称为Diameter授权会话。它由用于管理授权服务（初始授权、重新授权、终止）的所有Diameter消息中包含的会话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.
应用层会话应用层会话标识需要提供特定QoS的应用层服务的持续时间。应用层会话标识符由QoS请求实体在QoS信令消息中提供，例如作为授权令牌的一部分。一般来说，应用程序会话标识符对于感知QoS的网元是不透明的。它包含在发送给AE的授权请求消息中，并帮助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.
关联这些会话是在三个相关实体中的每一个完成的：QoS请求实体将应用程序与QoS信令会话关联起来。QoS NE将QoS信令会话与Diameter授权会话相关联。AE应将有关三次会议的信息绑定在一起。请注意，在某些场景中，并非所有会话都存在。例如，如果应用会话和使用QoS信令协议的QoS请求实体之间没有绑定，则应用会话可能对QoS信令协议不直接可见。
Authorization models supported by this application include three parties:
此应用程序支持的授权模型包括三方：
o Resource Requesting Entity
o 资源请求实体
o Network Elements (Diameter QoS application (DQA) client)
o 网元（Diameter QoS应用程序（DQA）客户端）
o Authorizing Entity (Diameter QoS application (DQA) server)
o 授权实体（Diameter 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信令消息来提供触发来启动Diameter QoS协议交互。Diameter 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资源请求实体和QoS NE之间的协议通信可以使用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授权会话的触发。当接收到具有新会话Id的QoS授权请求（QAR，参见第5.1节）消息时，AE以拉模式运行；当接收到其他触发器时，AE在推送模式下工作。类似地，当接收到具有新会话Id的QoS安装请求（QIR，参见第5.3节）时，网元以推模式运行；当接收到其他触发器时，网元以拉模式运行。
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的所有请求），但也可以在每个节点或每个请求基础上建立。网元和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.
网元接收到的QoS保留请求或本地事件可触发Diameter QoS授权会话的启动。网元将所需对象从QoS信令消息转换为Diameter 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的标识、关于应用会话和/或QoS RRE的标识和凭证的信息、请求的QoS参数以及信令会话标识符和/或启用QoS的数据流标识符可以封装到各自的Diameter AVP中，并包括在发送给AE的Diameter消息中。QAR被发送到Diameter服务器，该服务器可以是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) | |
+------------------------------------------+------------------------+
+------------------------------------------+------------------------+
| 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：将输入数据映射到QoS AVP——拉模式
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.
授权处理在Diameter QoS服务器接收QAR时开始。根据QoS身份验证数据、用户名和QoS资源AVP中的信息，服务器根据本地可用信息确定授权的QoS资源和流状态（启用/禁用）（例如，以前可能作为应用层信令交换或用户订阅配置文件的一部分建立的策略信息）。QoS资源AVP在[RFC5777]中定义。然后，授权决策将反映在返回给Diameter客户端的响应中，并带有QoS授权应答（QAA）消息。
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==============....===>|
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
授权请求的最终结果在授权实体发送的QAA消息的结果代码AVP中提供。在成功授权的情况下（即，结果代码=DIAMETER_LIMITED_SUCCESS（参见第7.1节）），QAA消息的QoS资源AVP中提供了有关授权QoS资源和授权流状态（启用/禁用）的信息。通过QAA提供的QoS信息由NE的QoS业务控制功能安装。价值
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).
DIAMETER_LIMITED_SUCCESS表示AE希望通过另一个QAR消息确认QoS资源预留成功和最终预留的QoS资源（见下文）。
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.
授权实体返回的一条重要信息是授权寿命（携带在QAA中）。授权生存期允许网元确定授权决策对该特定QoS保留有效的时间。许多因素可能会影响授权会话持续时间，例如用户的订阅计划或用户帐户上当前可用的信用（参见第8节）。根据[RFC3588]中的规定，授权持续时间是基于时间的。为了延长授权期限，应启动新的QoS授权请求/应答消息交换。第4.3、4.4和8节讨论了QoS授权会话维护的其他方面。
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.
通过传输QAR消息来提供成功的QoS保留和数据流的激活的指示，该QAR消息报告所建立的QoS状态的参数：保留资源、保留的持续时间以及启用QoS的流/QoS信令会话的标识。Diameter QoS服务器通过QA应答（QAA）消息确认保留的QoS资源，其中结果代码设置为“Diameter_SUCCESS”。注意，由于QoS信令特定行为（例如，接收器发起的具有一条带有广告的路径的保留）或沿着数据路径的QoS协商的特定过程，在该QAR消息中报告的保留QoS资源可能不同于使用初始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中的Diameter QoS服务器根据由应用层信令或本地事件触发的QoS保留请求发起Diameter QoS授权会话，并生成QoS安装请求（QIR）消息到网元中的Diameter QoS客户端，在该消息中，它将所需对象映射到Diameter有效负载对象。
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
网元的标识、关于应用会话的信息和/或QoS资源请求实体的标识和凭证、请求的QoS参数，和信令会话标识符和/或启用QoS的数据流标识符可以封装到各自的Diameter avp中，并包括在从授权实体中的Diameter QoS服务器发送到Diameter QoS服务器的Diameter消息中
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.
网元中的客户端。这要求AE了解用于分配和识别应联系的网元以及应为其建立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) | |
+-----------------------------------------+-------------------------+
+-----------------------------------------+-------------------------+
| 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：将输入数据映射到QoS AVPs——推送模式
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.
当Diameter QoS服务器通过应用程序（例如SIP Invite）接收来自RRE的请求或由本地事件（例如预先配置的计时器）触发时，授权处理开始于Diameter QoS服务器。基于接收到的信息，服务器根据本地可用信息（例如，先前可作为应用层信令交换的一部分建立的策略信息，或用户的订阅简档）确定授权QoS资源和流状态（启用/禁用）。授权决策随后反映在发送给Diameter QoS客户端的QoS安装请求（QIR）消息中。
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==============....===>|
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信息由网元的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的一条重要信息是授权寿命（携带在QIR中）。授权生存期允许网元确定授权决策对该特定QoS保留有效的时间。许多因素可能会影响授权会话持续时间，例如用户的订阅计划或用户帐户上当前可用的信用（参见第8节）。授权持续时间基于[RFC3588]中规定的时间。为了延长授权期限，应启动新的QoS安装请求/应答消息或QoS授权请求/应答消息交换。第4.3、4.4和8节讨论了QoS授权会话维护的其他方面。
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保留和数据流激活的指示。在成功实施的情况下，结果代码（=直径_成功，（见第7.1节））信息在QIA信息中提供。注意，由于QoS信令特定行为（例如，接收器发起的带有广告的一条路径的保留）或沿着数据路径的QoS协商的特定过程，在QIA消息中报告的保留QoS资源可能不同于最初使用QIR消息授权的资源。在多个AEs控制同一个网元的情况下，网元应根据请求的优先级选择要执行的授权决策。
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.
Diameter QoS应用节点可通过静态配置或动态发现（如[RFC3588]第5.2节所述）获取其对等节点的信息（例如，完全限定域名（FQDN）、IP地址）。具体而言，网元应执行拉模式的相关操作；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.
在接收到发起新的Diameter QoS授权会话的触发器时，Diameter QoS应用节点基于RRE提供的一些索引信息选择并检索与受影响用户相关联的对等节点的位置信息。例如，它可以是存储在授权令牌中的授权实体的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
在Diameter QoS应用程序的设计中，考虑了客户端和服务器端发起的重新授权。重新授权事件对于请求的资源是否透明
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信令协议中特定操作的实体或结果不在Diameter 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指定网元可以提供的服务以及它将获得经济补偿的服务。因此，任何不符合授权限制的流参数及其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消息包含流及其QoS的授权参数。根据网元和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消息包含流的授权参数及其QoS。这些参数的任何更改或更改请求都需要联系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. 除了流的授权参数及其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
AE提供授权会话的持续时间，作为QoS授权应答（QAA）消息的一部分。在该时段到期之前的任何时间，可以向AE发送新的QoS授权请求（QAR）消息。当NE接收到需要的QoS信令消息时，可以触发QAR的传输
modification of the authorized parameters of an ongoing QoS session, or authorization lifetime expires.
修改正在进行的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==========================>
| |
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可通过发出在Diameter基本协议[RFC3588]中定义的再授权请求（RAR）消息来发起QoS再授权，该消息可包括再授权QoS状态的参数：保留资源、保留持续时间、，通过网元的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.
接收会话Id与当前活动QoS会话匹配的RAR消息的网元通过向AE发送重新验证应答（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必须通过向AE发送QoS授权请求（QAR）消息来发起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 |
| | +--------+--------------+
| | |
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.
Diameter客户端可以通过向Diameter服务器发送会话终止请求（STR）消息和响应会话终止确认（STA）消息来终止已安装QoS保留状态的授权会话。这是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----+ |
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
在会话期间的任何时候，AE都可以向网元发送中止会话请求（ASR）消息。这是Diameter基本协议函数，在[RFC3588]中定义。向网元发起ASR消息的可能原因是信用不足或应用层的会话终止。ASR消息导致授权会话终止，并释放
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.
网元上的保留资源，以及适当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----....----+
| |
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.
Diameter QoS应用程序要求定义新的强制性AVP和命令代码（见[RFC3588]第3节）。定义了四条新的Diameter消息以及命令代码，所有符合本规范的Diameter实现都必须支持这些消息的值。
+---------------------------+---------+------+-------------+
| 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 |
+---------------------------+---------+------+-------------+
+---------------------------+---------+------+-------------+
| 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:Diameter QoS命令
In addition, the following Diameter base protocol messages are used in the Diameter QoS application:
此外，Diameter QoS应用程序中使用了以下Diameter基本协议消息：
+-----------------------+---------+------+-----------+
| 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] |
+-----------------------+---------+------+-----------+
+-----------------------+---------+------+-----------+
| 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].
符合本规范的Diameter节点可通过在功能交换请求和功能交换应答命令的验证应用程序Id或Acct应用程序Id AVP中包含值9来公布对Diameter 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.
在所有STR/STA、ASR/ASA和RAR/RAA命令中，应将零（0）的值用作应用程序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授权请求（QAR）消息被设置为326，并且在命令标志字段中设置的“R”位被网元用于请求给定流的服务质量相关资源授权。
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请求实体的标识的信息。此外，根据部署场景，应包括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 ]
<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.
QoS授权应答（QAA）消息是响应QoS授权请求（QAR）消息而发送的，该消息由设置为326的命令代码字段和在命令标志字段中清除的“R”位指示。如果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 ]
<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安装请求（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 ]
<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安装应答（QIA）消息由设置为327的命令代码字段和在命令标志中清除的“R”位指示，该消息被发送以响应QoS安装请求（QIR）消息，以确认所提供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 ]
<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.
重新授权请求（RAR）消息由设置为258的命令代码字段和在命令标志字段中设置的“R”位指示，由AE发送到网元，以便从DQA服务器端启动QoS重新授权。
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.
如果网元在没有重新授权的QoS状态的任何参数的情况下接收到RAR命令，则网元必须通过向AE发送QoS授权请求（QAR）消息来发起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 ]
<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.
重新认证应答（RAA）消息由被设置为258的命令代码字段和被清除的命令标志字段中的“R”位指示，由网元发送给AE以响应RAR命令。
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 ]
<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应用程序根据Diameter基本协议（[RFC3588]）第8.1节中定义的授权状态机定义自己的状态机。QoS状态机使用第5节中定义的自己的消息和第7节中定义的QoS AVP。
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).
以Diameter基本协议状态机为基础，将以下状态补充到在服务器上维护会话状态的前两个状态机。在支持服务器启动的推送模式的任何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]:
根据Diameter基本协议[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
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，结果代码更新打开=成功会话未决处理收到的发送Discon QIA时出错，结果代码=成功ASR
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]:
按照Diameter基本协议[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
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
Idle QIR初始请求发送接收到的Idle但未收到QIA初始成功处理的应答，结果代码！=成功
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授权请求/应答和QoS安装请求/应答消息中标识的每个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
属性名称AVP代码参考[RFC3588]源主机264第6.3节源域296第6.4节目标主机293第6.5节目标域283第6.6节身份验证应用程序Id 258第6.8节结果代码268第7.1节身份验证请求类型274第8.7节会话Id 263第8.8节授权生存期291第8.9节身份验证宽限期276第8.10节会话超时27第8.13节用户名1第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.
IANA将身份验证应用程序Id AVP（AVP代码258）分配给Diameter应用程序。Diameter QoS应用程序的身份验证应用程序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：绑定身份验证会话Id和QoS授权数据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应用程序的Diameter 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. |
+------------------------------------------------------------------+
+-------------------+
| 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授权数据QoS授权数据AVP（AVP代码579）的类型为OctetString。它是一个容器，承载应用程序会话或特定于用户的数据，这些数据必须作为授权决策计算的输入提供给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.
绑定身份验证会话Id绑定身份验证会话AVP（AVP代码580）的类型为UTF8String。它携带用于网络访问的Diameter身份验证会话的ID[RFC4005]。它用于将QoS授权请求与由位于同一位置的应用程序（用于QoS网元上的网络访问身份验证（[RFC4005]）对终端主机进行的先前身份验证联系起来。
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.
在成功的QoS保留和数据流激活之后，网元可以通过发送记帐请求（ACR）消息来启动记帐会话（见图6和图7）。在每个成功的重新授权过程（见图8和图9）之后，网元可以启动临时记帐消息交换。在成功终止会话（见图10和图11）后，网元可发起会计消息的最终交换以终止会计会话，并报告使用保留的QoS资源的最终记录。应注意的是，两个会话（授权和记帐）通过Diameter base协议进行独立管理，允许在授权会话结束后完成记帐会话。
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).
本节介绍了使用拉模式在终端主机和Diameter 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)| |
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---------------------------\
\------------------+--------------------------------------/
| | |
| +---------+--------+ | |
| |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
.-.-.-.-. 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.
通信从两个端点和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 NSLP保留消息，其中包括所需QoS的描述（QSPEC对象）和协商服务会话的授权数据（策略数据对象的一部分）。授权数据至少包括AE的标识（例如，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感知网元截获和处理。网元使用Diameter QoS应用程序为接收到的QoS保留请求请求授权。AE的标识（在这种情况下，与Diameter服务器共存的SIP服务器）被放入目的主机AVP中，任何附加会话授权数据被封装到QoS授权数据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授权应答（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.
网元与流量控制功能交互，安装授权的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
本节重复第9.1节中概述的场景；但是，在本例中，我们显示的是会话授权失败而不是成功。在整个协议执行过程中，失败可能发生在各个步骤中，在本例中，我们假设Diameter服务器处理的Diameter QAR请求导致失败
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).
后果在本例中，QAA消息响应结果代码AVP中设置的永久性错误“DIAMETER_AUTHORIZATION_REJECTED”（5003）。当网元接收到该响应时，它中断下游的QoS保留信令，并向发起QoS信令请求的终端主机返回错误消息。在这种情况下，QoS NSLP响应信令消息将携带一个INFO_SPEC对象，将永久性故障指示为“授权故障”（0x02）。
End-Host SIP Proxy Correspondent requesting QoS (DQA Server) Node
终端主机SIP代理通信请求QoS（DQA服务器）节点
| | |
..|...................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..........|..............|..
. | 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
.-.-.-.-. 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).
本节介绍使用推送模式在终端主机和Diameter QoS应用程序实体之间进行交互的示例。在此示例中，应用层信令是使用SIP提供的。QoS资源预留的信令使用QoS NSLP完成。QoS保留请求的授权由Diameter QoS应用程序（DQA）完成。
End-Host NE SIP Proxy Correspondent requesting QoS (DQA Client) (DQA Server) Node
终端主机NE SIP代理通信请求QoS（DQA客户端）（DQA服务器）节点
| | | |
..|..................|...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 | |
| | +----------+------------+ |
| | | |
..|..................|...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---------------------------\
\------------------+-----------------------------------------/
| | |
..|.............................................|..............|..
. | | | | .
. | | | 200 OK (SDP)| .
. | | <-.-.-.....-.-.+ .
. | | +--------+-----------+ | .
. | | | Activate Session | | .
. | | | Parameters | | .
. | | +--------+-----------+ | .
. | 200 (SDP) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
..|.............................................|..............|..
| <- - - - - - RAR - - - - - + |
| +---------+--------+ | |
| |Activate QoS State| | |
| +---------+--------+ | |
| +- - - - - - RAA - - - - - > |
| | |
/------------------+-----Data Flow---------------------------\
\------------------+-----------------------------------------/
| | |
.-.-.-.-. SIP signaling
- - - - - Diameter QoS Application messages
.-.-.-.-. 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).
通信从两个端点和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消息来执行此操作。对于这个示例消息流，我们假设两阶段提交，即SIP代理与网元交互两次。首先，它只准备QoS预留，然后，随着200ok的到来，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
此示例不描述DQA服务器如何了解要联系的DQA客户端。在本例中，我们假设预配置。在任何情况下，将DQA客户端的地址放入目的主机AVP中，QoS资源的描述包括在目的主机AVP中
QoS-Resources AVP, and the duration of the authorization session is carried in the Authorization-Lifetime AVP.
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，并向网元中的DQA客户端发送Diameter 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]中定义的注册表分配了两个AVP代码：
Registry:
AVP Code AVP Name Reference
-----------------------------------------------------------
579 QoS-Authorization-Data Section 7.2
580 Bound-Auth-Session-Id Section 7.2
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]中定义的注册表（使用7-16777215范围中的下一个可用值）分配了以下应用程序ID。
Registry:
ID values Name Reference
-----------------------------------------------------------
9 Diameter QoS application Section 5
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
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保留授权的机制。授权实体需要足够的信息来做出这样的授权决策，并且该信息可以来自各种来源，包括应用层信令、Diameter协议（及其安全机制）、存储在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.
下面讨论授权实体和网元之间的Diameter 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.
认证是指确认从发端人接收的所有数据报的发端人身份。授权实体和网元之间缺少Diameter消息的身份验证可能会严重危害网元提供的基本服务。如果网元未对消息发送者进行身份验证，则攻击者可能伪造“合法”授权实体的身份，以便分配资源、更改资源分配或释放资源。对手还可以通过例如将允许带宽设置为零或将整个可用带宽分配给单个流来操纵网元上的状态，从而导致拒绝服务攻击。
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.
授权是指是否授权特定授权实体向网元发送一个或多个应用程序的请求，遵守特定的策略配置文件。授权过程失败可能表示由于管理和/或凭据缺陷而导致资源盗窃企图或失败。在任何一种情况下，网元都应采取适当措施记录此类尝试。
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.
Diameter消息的机密性保护确保只有授权实体才能访问信令数据。当来自应用服务器（通过授权实体指向网元）的信令消息穿越不受信任的网络时，缺乏机密性将允许窃听和流量分析。此外，Diameter 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.
Diameter提供了安全机制来处理上述段落中要求的功能。尤其是，Diameter使用传输层安全性（TLS）或IPsec提供相邻Diameter对等方之间的通信安全性。授权功能是特定于应用程序的，是整个实现的一部分。
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.
作者要感谢John Loughney和Allison Mankin对本文件的投入。2005年9月，罗伯特·汉考克、朱卡·韦德、科妮莉亚·卡普勒、傅晓明、乔治·卡拉吉安尼斯和埃尔文·戴维斯提供了详细的审查。Robert在2005年初也向我们提供了良好的反馈。Jerry Ash在2005年末/2006年初向我们提供了审查意见。Rajith R在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.
作者要感谢Tseno Tsenov和Frank Alfano，感谢他们在IETF中开始了Diameter服务质量工作，感谢他们的重大贡献，感谢他们成为最初几个草案版本的驱动力。
[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网络访问服务器应用”，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 56242009年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 57772010年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，“要点：通用互联网信号传输”，正在进行的工作，2009年6月。
[NSIS-QOS] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", Work in Progress, January 2010.
[NSIS-QOS]Way，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 22052997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211]Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，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 28652000年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：会话启动协议”，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 35212003年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.Erenen，“网络访问标识符”，RFC 42822005年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：会话描述协议”，RFC4566，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，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Dong Sun (editor) Alcatel-Lucent 600 Mountain Ave Murray Hill, NJ 07974 USA
东孙（编辑）美国新泽西州默里山阿尔卡特朗讯山大道600号07974
Phone: +1 908 582 2617
EMail: d.sun@alcatel-lucent.com
Phone: +1 908 582 2617
EMail: d.sun@alcatel-lucent.com
Peter J. McCann Motorola Labs 1301 E. Algonquin Rd Schaumburg, IL 60196 USA
美国伊利诺伊州绍姆堡阿尔冈金东路1301号摩托罗拉实验室，邮编60196
Phone: +1 847 576 3440
EMail: pete.mccann@motorola.com
Phone: +1 847 576 3440
EMail: pete.mccann@motorola.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Tina Tsou Huawei Shenzhen, P.R.C
中华人民共和国深圳市华为公司
EMail: tena@huawei.com
EMail: tena@huawei.com
Avri Doria Lulea University of Technology Arbetsvetenskap Lulea, SE-97187 Sweden
瑞典科技大学阿里贝斯滕斯卡普卢埃拉，SE-97 187
EMail: avri@ltu.se
EMail: avri@ltu.se
Glen Zorn (editor) Network Zen 1310 East Thomas Street #306 Seattle, Washington 98102 USA
格伦·佐恩（编辑）美国华盛顿州西雅图东托马斯街1310号，306号，邮编98102
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net
Phone: +1 (206) 377-9035
EMail: gwz@net-zen.net