Internet Engineering Task Force (IETF) L. Bertz
Request for Comments: 7660 S. Manning
Category: Standards Track Sprint
ISSN: 2070-1721 B. Hirschman
October 2015
Internet Engineering Task Force (IETF) L. Bertz
Request for Comments: 7660 S. Manning
Category: Standards Track Sprint
ISSN: 2070-1721 B. Hirschman
October 2015
Diameter Congestion and Filter Attributes
直径和过滤器属性
Abstract
摘要
This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration.
本文档定义了可选的Diameter属性，可用于帮助管理使用显式拥塞通知（ECN）或Diameter流量过滤器的网络。这些新属性允许改进数据流量识别、支持ECN和最小直径过滤器管理。
RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.
RFC 5777定义了一个过滤规则属性值对（AVP），该对包含分类、条件和操作的扩展。但是，它不支持使用RFC 3168中定义的显式拥塞通知对数据包进行流量标识，并且在过滤规则描述的流拥塞时不提供特定操作。
Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.
此外，过滤规则可以描述多个流，但不能描述流的确切数量。流量计数和其他相关数据（例如，数据包）不会被记帐应用程序捕获，从而使管理员无法获得有关过滤器定义的有效性或适当性的有用信息。
The optional attributes defined in this document are forward and backwards compatible with RFC 5777.
本文档中定义的可选属性与RFC 5777向前和向后兼容。
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/rfc7660.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7660.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4
3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4
3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 4
3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Classifier Example . . . . . . . . . . . . . . . . . . . . 6
5.2. Diameter Credit Control (CC) with Congestion Information . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ECN-IP-Codepoint, Congestion-Treatment and Filter Attributes . 4
3.1. ECN-IP-Codepoint AVP . . . . . . . . . . . . . . . . . . . 4
3.2. Congestion-Treatment AVP . . . . . . . . . . . . . . . . . 4
3.3. Flow-Count AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Packet-Count AVP . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Classifier Example . . . . . . . . . . . . . . . . . . . . 6
5.2. Diameter Credit Control (CC) with Congestion Information . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Two optional AVPs related to Explicit Congestion Notification (ECN) [RFC3168] are specified in this document. The first AVP provides direct support for filtering ECN-marked traffic [RFC3168] and the second AVP provides the ability to define alternate traffic treatment when congestion is experienced.
本文档中指定了两个与显式拥塞通知（ECN）[RFC3168]相关的可选AVP。第一个AVP直接支持过滤ECN标记的流量[RFC3168]，第二个AVP提供在遇到拥塞时定义备用流量处理的能力。
This document also defines two optional AVPs, Flow-Count and Packet-Count, used for conveying flow information within the Diameter protocol [RFC6733]. These AVPs were found to be useful for a wide range of applications. The AVPs provide a way to convey information of the group of flows described by the Filter-Rule, IPFilterRule, or other Diameter traffic filters.
本文件还定义了两个可选的AVP，流量计数和数据包计数，用于在Diameter协议[RFC6733]中传输流量信息。这些AVP被发现具有广泛的应用价值。AVP提供了一种方式来传递由过滤规则、IPFilterRule或其他直径流量过滤器描述的流组的信息。
The semantics and encoding of all AVPs can be found in Section 3.
所有AVP的语义和编码见第3节。
Such AVPs are, for example, needed by some congestion-management functions to determine the number of flows congested or used by administrators to determine the impact of filter definitions.
例如，某些拥塞管理功能需要这样的AVP来确定拥塞流的数量，或者管理员使用这些AVP来确定过滤器定义的影响。
Additional parameters may be defined in future documents as the need arises. All parameters are defined as Diameter-encoded Attribute Value Pairs (AVPs), which are described using a modified version of the Augmented Backus-Naur Form (ABNF), see [RFC6733]. The data types are also taken from [RFC6733].
根据需要，可在未来的文件中定义其他参数。所有参数均定义为直径编码属性值对（AVP），使用改进版的增广巴科斯-诺尔形式（ABNF）进行描述，参见[RFC6733]。数据类型也取自[RFC6733]。
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 RFC2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[RFC2119]中所述进行解释。
The ECN-IP-Codepoint AVP (AVP Code 628) is of type Enumerated and specifies the ECN codepoint values to match in the IP header.
ECN IP码点AVP（AVP代码628）属于枚举类型，并指定要在IP报头中匹配的ECN码点值。
Value | Binary | Keyword | References
-----------------------------------------------------------------
0 | 00 | Not-ECT (Not ECN-Capable Transport)| [RFC3168]
1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168]
2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168]
3 | 11 | CE (Congestion Experienced) | [RFC3168]
Value | Binary | Keyword | References
-----------------------------------------------------------------
0 | 00 | Not-ECT (Not ECN-Capable Transport)| [RFC3168]
1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168]
2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168]
3 | 11 | CE (Congestion Experienced) | [RFC3168]
When this AVP is used for classification in the Filter-Rule, it MUST be part of the Classifier Grouped AVP as defined in RFC 5777.
当此AVP用于筛选规则中的分类时，它必须是RFC 5777中定义的分类器分组AVP的一部分。
The Congestion-Treatment AVP (AVP Code 629) is of type Grouped. It indicates how to treat traffic IP (5-tuple) flow(s) when congestion is detected. The detection of congestion can be based on the reception of IP packets with the Congestion Experience (CE) codepoint set (see [RFC3168]) or by any other administratively defined criteria.
拥塞处理AVP（AVP代码629）属于分组类型。它指示在检测到拥塞时如何处理流量IP（5元组）流。拥塞检测可以基于具有拥塞体验（CE）码点集的IP分组的接收（参见[RFC3168]）或任何其他管理定义的标准。
A Filter-Rule may contain a Classifier that describes one or many 5-tuples per RFC 5777. This treatment applies to all packets associated to all 5-tuples (flows) captured by the Filter-Rule.
过滤规则可以包含一个分类器，该分类器描述每个RFC 5777的一个或多个5元组。此处理适用于与过滤器规则捕获的所有5元组（流）关联的所有数据包。
If the Congestion-Treatment AVP is absent, the treatment of the congested traffic is left to the discretion of the node performing quality-of-service (QoS) treatment.
如果不存在拥塞处理AVP，则拥塞业务的处理由执行服务质量（QoS）处理的节点自行决定。
Congestion-Treatment ::= < AVP Header: 629 >
{ Treatment-Action }
[ QoS-Profile-Template ]
[ QoS-Parameters ]
* [ AVP ]
Congestion-Treatment ::= < AVP Header: 629 >
{ Treatment-Action }
[ QoS-Profile-Template ]
[ QoS-Parameters ]
* [ AVP ]
Treatment-Action, QoS-Profile-Template, and QoS-Parameters are defined in RFC 5777. The Congestion-Treatment AVP is an action and MUST be an attribute of the Filter-Rule Grouped AVP as defined in RFC 5777.
治疗措施、QoS配置文件模板和QoS参数在RFC 5777中定义。拥塞处理AVP是一个动作，必须是RFC 5777中定义的过滤规则分组AVP的属性。
The Flow-Count AVP (AVP Code 630) is of type Unsigned64.
流计数AVP（AVP代码630）的类型为Unsigned64。
It indicates the number of protocol-specific flows. The protocol is determined by the filter (e.g., IPFilterRule, Filter-Id, etc.).
它指示特定于协议的流的数量。协议由过滤器决定（例如，IPFilterRule、过滤器Id等）。
The Packet-Count AVP (AVP Code 631) is of type Unsigned64.
数据包计数AVP（AVP代码631）的类型为Unsigned64。
It indicates the number of protocol-specific packets. The protocol is determined by the filter (e.g., IPFilterRule, Filter-Id, etc.).
它表示特定于协议的数据包的数量。协议由过滤器决定（例如，IPFilterRule、过滤器Id等）。
IANA allocated AVP codes in the IANA-controlled namespace registry specified in Section 11.1.1 of [RFC6733] for the following AVPs that are defined in this document.
IANA在[RFC6733]第11.1.1节规定的IANA受控命名空间注册表中为本文件中定义的以下AVP分配了AVP代码。
+------------------------------------------------------------------+
| AVP Section |
|AVP Code Defined Data Type |
+------------------------------------------------------------------+
|ECN-IP-Codepoint 628 3.1 Enumerated |
|Congestion-Treatment 629 3.2 Grouped |
|Flow-Count 630 3.3 Unsigned64 |
|Packet-Count 631 3.4 Unsigned64 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| AVP Section |
|AVP Code Defined Data Type |
+------------------------------------------------------------------+
|ECN-IP-Codepoint 628 3.1 Enumerated |
|Congestion-Treatment 629 3.2 Grouped |
|Flow-Count 630 3.3 Unsigned64 |
|Packet-Count 631 3.4 Unsigned64 |
+------------------------------------------------------------------+
The following examples illustrate the use of the AVPs defined in this document.
以下示例说明了本文档中定义的AVP的使用。
The Classifier AVP (AVP Code 511) specified in RFC 5777 is a grouped AVP that consists of a set of attributes that specify how to match a packet. The addition of the ECN-IP-Codepoint is shown here.
RFC 5777中指定的分类器AVP（AVP代码511）是分组的AVP，其包括一组指定如何匹配分组的属性。此处显示了添加的ECN IP代码点。
Classifier ::= < AVP Header: 511 >
{ Classifier-ID }
[ Protocol ]
[ Direction ]
[ ECN-IP-Codepoint ]
* [ From-Spec ]
* [ To-Spec ]
* [ Diffserv-Code-Point ]
[ Fragmentation-Flag ]
* [ IP-Option ]
* [ TCP-Option ]
[ TCP-Flags ]
* [ ICMP-Type ]
* [ ETH-Option ]
* [ AVP ]
Classifier ::= < AVP Header: 511 >
{ Classifier-ID }
[ Protocol ]
[ Direction ]
[ ECN-IP-Codepoint ]
* [ From-Spec ]
* [ To-Spec ]
* [ Diffserv-Code-Point ]
[ Fragmentation-Flag ]
* [ IP-Option ]
* [ TCP-Option ]
[ TCP-Flags ]
* [ ICMP-Type ]
* [ ETH-Option ]
* [ AVP ]
Setting the ECN-IP-Codepoint value to 'CE' would permit the capture of CE flags in the Flow.
将ECN IP代码点值设置为“CE”将允许捕获流中的CE标志。
Another Classifier with the ECN-IP-Codepoint value of 'ECT' could be specified and, when coupled with the Flow-Count AVP, reports the number of ECT-capable flows.
可以指定ECN IP代码点值为“ECT”的另一个分类器，当与流量计数AVP结合时，报告支持ECT的流量的数量。
Diameter nodes using Credit Control can use the Congestion-Treatment AVP to trigger specific actions when congestion occurs. This is similar to the Excess-Treatment Action. The ability to detect when congestion occurs is specific to the AVPs in the Filter-Rule and Diameter Client and is no different than how 'Excess' can be determined for Excess-Treatment. If conditions associated with Excess-Treatment [RFC5777] or Congestion-Treatment have occurred, Diameter Clients may autonomously send Credit-Control Requests (CCRs) during the Service Delivery session as interim events. This is shown in Figure 1.
使用信用控制的Diameter节点可以使用拥塞处理AVP在拥塞发生时触发特定操作。这类似于过度治疗作用。检测何时发生拥塞的能力取决于过滤规则和Diameter客户端中的AVP，与如何确定过度治疗的“过度”没有区别。如果出现与过度治疗[RFC5777]或拥堵治疗相关的情况，Diameter客户端可以在服务交付会话期间作为临时事件自动发送信用控制请求（CCR）。这如图1所示。
Service Element
End User (CC Client) CC Server
| | |
|(1) Service Request | |
|-------------------->| |
| |(2) CCR (Initial, |
| | QoS-Resources(QoS-Desired)) |
| |--------------------------------->|
| |(3) CCA (Granted-Units, |
| | QoS-Resources(QoS-Authorized))|
| |<---------------------------------|
|(4) Service Delivery | |
|<------------------->| |
| (5) Congestion Detected |
| (6) Congestion Treatment Occurs |
| |(7) CCR (Termination, Used-Units, |
| | Flow-Count, Packet-Count, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(8) CCA |
| |<-------------------------------->|
| | |
| | |
|(9) End of Service | |
|-------------------->| |
| |(10)CCR (Termination, Used-Units, |
| | Flow-Count, Packet-Count, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(11) CCA |
| |<---------------------------------|
Service Element
End User (CC Client) CC Server
| | |
|(1) Service Request | |
|-------------------->| |
| |(2) CCR (Initial, |
| | QoS-Resources(QoS-Desired)) |
| |--------------------------------->|
| |(3) CCA (Granted-Units, |
| | QoS-Resources(QoS-Authorized))|
| |<---------------------------------|
|(4) Service Delivery | |
|<------------------->| |
| (5) Congestion Detected |
| (6) Congestion Treatment Occurs |
| |(7) CCR (Termination, Used-Units, |
| | Flow-Count, Packet-Count, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(8) CCA |
| |<-------------------------------->|
| | |
| | |
|(9) End of Service | |
|-------------------->| |
| |(10)CCR (Termination, Used-Units, |
| | Flow-Count, Packet-Count, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(11) CCA |
| |<---------------------------------|
Figure 1: Example of a Diameter Credit Control with Congestion Information
图1：具有拥塞信息的Diameter信用控制示例
The 'Used-Service-Units' described in RFC 5777 examples is customarily a Service-Units, Time-Units, or Byte-Count AVP. This is insufficient to represent network state and does not differentiate between throughput and good-put (good or quality throughput) even though the filters may imply good or poor throughput.
RFC 5777示例中描述的“使用的服务单元”通常是服务单元、时间单元或字节计数AVP。这不足以表示网络状态，并且不能区分吞吐量和良好的put（良好或高质量的吞吐量），即使过滤器可能意味着良好或较差的吞吐量。
Flow-Count and Packet-Count AVPs defined in this document could be sent with a CCR when the triggering event is related to Congestion-Treatment. This provides the CC Server with a better view of the type of congested traffic for improved decision making and charging. Sending such AVPs under any condition permits rudimentary traffic profiling regardless of network conditions. For instance, low byte counts per packet is indicative of web traffic and high byte counts
当触发事件与拥塞处理相关时，本文档中定义的流计数和包计数AVP可与CCR一起发送。这使CC服务器能够更好地了解拥塞流量的类型，从而改进决策和收费。在任何条件下发送这样的AVP都允许进行基本的流量分析，而不管网络条件如何。例如，每个数据包的低字节数表示web流量和高字节数
per packet with a small number of flows may be indicative of video traffic. Enriched reporting described here provides relief from Deep Packet Inspection load and loss of information as traffic becomes increasingly encrypted.
具有少量流的每个分组可指示视频流量。这里描述的丰富报告减轻了深度数据包检查负载和信息丢失，因为流量变得越来越加密。
Some services, e.g., streaming services, limit the number of flows, Flow-Count, as opposed to other units, i.e. Byte-Count. In such a case, the Flow-Count AVP may be used in place of Service-Units.
一些服务，例如流式服务，限制流的数量、流计数，而不是其他单位，即字节计数。在这种情况下，可以使用流量计数AVP代替服务单元。
This document describes an extension of RFC 5777 that introduces a new filter parameter applied to ECN as defined by [RFC3168]. It also defines a new Grouped AVP that expresses what action to take should congestion be detected. The Grouped AVP reuses attributes defined in RFC 5777. As these are extensions to RFC 5777, they do not raise new security concerns.
本文档描述了RFC 5777的扩展，该扩展引入了一个新的过滤器参数，该参数应用于[RFC3168]定义的ECN。它还定义了一个新的分组AVP，该AVP表示在检测到拥塞时应采取的操作。分组的AVP重用RFC 5777中定义的属性。由于这些是RFC 5777的扩展，因此不会引起新的安全问题。
The Flow-Count and Packet-Count AVPs can be provided in conjunction with customary AVPs, e.g., Bytes, Time, Service units, during accounting activities as described in the base protocol [RFC6733] or other Diameter applications. These new AVPs provide more information that can be privacy sensitive. The privacy sensitivity is directly related to traffic captured by filters and associated reports. Narrow filtering, which creates the highest level of privacy sensitivity, is too resource intensive to be widely applied on large networks. Paradoxically, improving reporting information lessens the depth of inspection required to characterize traffic for many congestion management activities as noted in Section 5.2.
在基本协议[RFC6733]或其他Diameter应用程序中描述的记帐活动期间，可以结合常规AVP（例如字节、时间、服务单位）提供流计数和包计数AVP。这些新的AVP提供了更多可能对隐私敏感的信息。隐私敏感度与过滤器和相关报告捕获的流量直接相关。狭义过滤产生了最高级别的隐私敏感度，资源过于密集，无法在大型网络上广泛应用。自相矛盾的是，如第5.2节所述，改善报告信息减少了描述许多拥堵管理活动交通特征所需的检查深度。
If an administrator can provide congestion actions without the need to report them to a Diameter application, they should use the Congestion-Treatment AVP, which also reduces Diameter traffic during congestion events.
如果管理员可以提供拥塞操作而无需向Diameter应用程序报告，则他们应该使用拥塞处理AVP，该AVP还可以在拥塞事件期间减少Diameter流量。
The Security Considerations of the Diameter protocol itself have been discussed in RFC 6733 [RFC6733]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol.
Diameter协议本身的安全注意事项已在RFC 6733[RFC6733]中讨论过。使用本文件中定义的AVP必须考虑到Diameter base协议的安全问题和要求。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <http://www.rfc-editor.org/info/rfc5777>.
[RFC5777]Korhonen，J.，Tschofenig，H.，Arumaithurai，M.，Jones，M.，Ed.，和A.Lior，“直径的流量分类和服务质量（QoS）属性”，RFC 5777，DOI 10.17487/RFC5777，2010年2月<http://www.rfc-editor.org/info/rfc5777>.
Acknowledgements
致谢
We would like to thank Avi Lior for his guidance and feedback during the development of this specification.
我们要感谢Avi Lior在本规范制定过程中提供的指导和反馈。
Authors' Addresses
作者地址
Lyle Bertz Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States
莱尔·贝尔茨斯普林特6220斯普林特公园路陆上公园，KS 66251美国
Email: lyleb551144@gmail.com
Email: lyleb551144@gmail.com
Serge Manning Sprint 6220 Sprint Parkway Overland Park, KS 66251 United States
Serge Manning Sprint 6220美国堪萨斯州斯普林特大道陆上公园，邮编66251
Email: sergem913@gmail.com
Email: sergem913@gmail.com
Brent Hirschman
布伦特·赫希曼
Email: Brent.Hirschman@gmail.com
Email: Brent.Hirschman@gmail.com