Network Working Group J. Korhonen, Ed.
Request for Comments: 5624 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
E. Davies
Folly Consulting
August 2009
Network Working Group J. Korhonen, Ed.
Request for Comments: 5624 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
E. Davies
Folly Consulting
August 2009
Quality of Service Parameters for Usage with Diameter
使用直径时的服务质量参数
Abstract
摘要
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.
本文档定义了许多服务质量（QoS）参数，这些参数可用于在Diameter中传输QoS信息。
The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object.
定义的QoS信息包括用于描述令牌桶过滤器的数据业务参数、带宽参数和每跳行为类对象。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4
3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4
3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4
3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 4
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5
3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 5
3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. ABNF Code Fragment . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4
3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4
3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4
3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 4
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5
3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 5
3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. ABNF Code Fragment . . . . . . . . . . . . . . . . . 11
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within the Diameter protocol [RFC3588]. The current set of QoS parameters defined in this document are a core subset determined to be useful for a wide range of applications. Additional parameters may be defined in future documents as the need arises and are for future study. The 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 [RFC3588]. The data types are also taken from [RFC3588].
本文档定义了许多服务质量（QoS）参数，这些参数可在Diameter协议[RFC3588]中用于传输QoS信息。本文档中定义的当前QoS参数集是一个核心子集，被确定为适用于广泛的应用。根据需要，可在未来的文件中定义其他参数，以供将来研究。这些参数被定义为直径编码属性值对（AVP），这些属性值对使用改进版的增广巴科斯-诺尔形式（ABNF）进行描述，请参见[RFC3588]。数据类型也取自[RFC3588]。
The traffic model (TMOD) AVPs are containers consisting of four AVPs and provide a way to describe the traffic source.
交通模型（TMOD）AVP是由四个AVP组成的容器，提供了描述交通源的方法。
o token rate (r)
o 令牌速率（r）
o bucket depth (b)
o 铲斗深度（b）
o peak traffic rate (p)
o 高峰交通率（p）
o minimum policed unit (m)
o 最小政策单位（m）
o maximum packet size (M)
o 最大数据包大小（M）
The encoding of the <TMOD-1> and the <TMOD-2> AVPs can be found in Sections 3.1 and 3.2. The semantics of these two AVPs are described in Section 3.1 of [RFC2210] and in Section 3.6 of [RFC2215].
<TMOD-1>和<TMOD-2>AVP的编码见第3.1节和第3.2节。[RFC2210]第3.1节和[RFC2215]第3.6节描述了这两个AVP的语义。
The <TMOD-2> AVP is, for example, needed by some DiffServ applications.
例如，<TMOD-2>AVP是一些DiffServ应用程序所需要的。
It is typically assumed that DiffServ expedited forwarding (EF) traffic is shaped at the ingress by a single-rate token bucket. Therefore, a single TMOD parameter is sufficient to signal DiffServ EF traffic. However, for DiffServ assured forwarding (AF) traffic, two sets of token bucket parameters are needed: one token bucket for the average traffic and one token bucket for the burst traffic. [RFC2697] defines a Single Rate Three Color Marker (srTCM), which meters a traffic stream and marks its packets according to three traffic parameters -- Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS) -- to be either green, yellow, or red. A packet is marked green if it does not exceed the CBS, yellow if it does exceed the CBS but not the EBS, and red otherwise. [RFC2697] defines specific procedures using two token buckets that run at the same rate. Therefore, two TMOD AVPs are sufficient to distinguish among three levels of drop precedence. An example is also described in the appendix of [RFC2597].
通常假设DiffServ加速转发（EF）流量在入口由单速率令牌桶形成。因此，单个TMOD参数足以发出DiffServ EF通信量的信号。然而，对于DiffServ assured forwarding（AF）流量，需要两组令牌桶参数：一组令牌桶用于平均流量，另一组令牌桶用于突发流量。[RFC2697]定义了一个单速率三色标记（srTCM），它测量流量流并根据三个流量参数（提交信息速率（CIR）、提交突发大小（CBS）和多余突发大小（EBS）标记其数据包，即绿色、黄色或红色。如果数据包未超过CBS，则标记为绿色；如果数据包未超过CBS但未超过EBS，则标记为黄色；否则标记为红色。[RFC2697]使用以相同速率运行的两个令牌存储桶定义特定过程。因此，两个TMOD AVP足以区分三个丢弃优先级级别。[RFC2597]的附录中还描述了一个示例。
Resource reservations might refer to a packet processor with a particular DiffServ per-hop behavior (PHB) (using the <PHB-Class> AVP). A generic description of the DiffServ architecture can be found in [RFC2475], and the Differentiated Services Field is described in Section 3 of [RFC2474]. Updated terminology can be found in [RFC3260]. Standardized per-hop behavior is, for example, described in [RFC2597] ("Assured Forwarding PHB Group") and in [RFC3246] ("An Expedited Forwarding PHB").
资源预留可能是指具有特定区分服务每跳行为（PHB）（使用<PHB Class>AVP）的数据包处理器。区分服务体系结构的一般描述见[RFC2475]，区分服务字段见[RFC2474]第3节。更新的术语可在[RFC3260]中找到。例如，[RFC2597]（“保证转发PHB组”）和[RFC3246]（“加速转发PHB”）中描述了标准化的每跳行为。
The above-mentioned parameters are intended to support basic integrated and differentiated services functionality in the network. Additional parameters can be defined and standardized if required to support specific services in the future.
上述参数旨在支持网络中的基本集成和区分服务功能。如果将来需要支持特定服务，可以定义和标准化其他参数。
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 TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The structure of the AVP is as follows:
TMOD-1 AVP从[RFC2210]和[RFC2215]获得。AVP的结构如下所示：
TMOD-1 ::= < AVP Header: 495 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
TMOD-1 ::= < AVP Header: 495 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
The Token-Rate AVP (AVP Code 496) is of type Float32.
令牌速率AVP（AVP代码496）的类型为Float32。
The Bucket-Depth AVP (AVP Code 497) is of type Float32.
铲斗深度AVP（AVP代码497）为浮动32型。
The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32.
峰值流量率AVP（AVP代码498）为32型。
The Minimum-Policed-Unit AVP (AVP Code 499) is of type Unsigned32.
最小策略单元AVP（AVP代码499）的类型为Unsigned32。
The Maximum-Packet-Size AVP (AVP Code 500) is of type Unsigned32.
最大数据包大小AVP（AVP代码500）的类型为Unsigned32。
A description of the semantics of the parameter values can be found in [RFC2215]. The coding for the TMOD-2 AVP is as follows:
参数值的语义说明见[RFC2215]。TMOD-2 AVP的编码如下：
TMOD-2 ::= < AVP Header: 501 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
TMOD-2 ::= < AVP Header: 501 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
The Bandwidth AVP (AVP Code 502) is of type Float32 and is measured in octets of IP datagrams per second. The Bandwidth AVP represents a simplified description of the following TMOD setting whereby the token rate (r) = peak traffic rate (p), the bucket depth (b) = large, and the minimum policed unit (m) = large when only bandwidth has to be expressed.
带宽AVP（AVP代码502）是Float32类型，并且以每秒IP数据报的八位字节为单位进行测量。带宽AVP表示以下TMOD设置的简化描述，其中令牌速率（r）＝峰值业务速率（p）、桶深度（b）＝大，并且最小策略单元（m）＝大，此时仅必须表示带宽。
The PHB-Class AVP (AVP Code 503) is of type Unsigned32.
PHB类AVP（AVP代码503）的类型为Unsigned32。
A description of the semantics of the parameter values can be found in [RFC3140]. The registries needed for usage with [RFC3140] already exist and hence a new registry is not required for this purpose. The encoding requires that three cases be differentiated. All bits indicated as "reserved" MUST be set to zero (0).
有关参数值语义的说明，请参见[RFC3140]。[RFC3140]使用所需的注册表已经存在，因此不需要新的注册表。编码要求区分三种情况。所有指示为“保留”的位必须设置为零（0）。
As prescribed in [RFC3140], the encoding for a single PHB is the recommended Differentiated Services Code Point (DSCP) value for that PHB, left-justified in the 16-bit field with bits 6 through 15 set to zero.
如[RFC3140]中所述，单个PHB的编码是该PHB的建议差异化服务代码点（DSCP）值，在16位字段中左对齐，位6到15设置为零。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus, for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.)
一组PHB的编码是集合中各种PHB的编码集合中数值最小的，位14设置为1。（因此，对于AF1x PHB，编码是AF11 PHB的编码，位14设置为1。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PHBs may not be defined by standards actions i.e., experimental or local use PHBs as allowed by [RFC2474]. In this case, an arbitrary 12-bit PHB identification code, assigned by the IANA, is left-justified in the 16-bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
PHB不得由标准行动定义，即[RFC2474]允许的实验或本地使用PHB。在这种情况下，IANA分配的任意12位PHB识别码在16位字段中左对齐。对于单个PHB，位15设置为1，对于一组PHB，位14为0或1。第12位和第13位为零。
Bits 12 and 13 are reserved either for expansion of the PHB identification code or for other, future use.
位12和13保留用于PHB标识码的扩展或其他未来用途。
In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID.
在这两种情况下，当使用单个PHBID识别一组PHB（即，位14设置为1）时，该组PHB必须构成PHB调度类（即，当同一微流中的不同PHB应用于同一微流中的流量时，使用该组PHB不得导致微流内流量重新排序）。AF1x PHB集合[RFC2597]是PHB调度类的一个示例。可以通过使用多个PHBID来识别不构成PHB调度类的PHB集。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document is designed with extensibility in mind, given that different organizations and groups are used to defining their own Quality of Service parameters. This document provides an initial QoS profile with a common set of parameters. Ideally, these parameters should be used whenever possible, but there are cases where additional parameters might be needed or where the parameters specified in this document are used with different semantics. In that case, it is advisable to define a new QoS profile that may consist of new parameters in addition to parameters defined in this document or an entirely different set of parameters. Finally, it is also possible to register a specific QoS profile that defines a specific set of QoS values rather than parameters that need to be filled with values in order to be used.
考虑到不同的组织和组用于定义自己的服务质量参数，本文档的设计考虑了可扩展性。本文档提供了一个初始QoS配置文件，其中包含一组通用参数。理想情况下，应尽可能使用这些参数，但在某些情况下，可能需要额外的参数，或者本文档中指定的参数使用不同的语义。在这种情况下，建议定义一个新的QoS配置文件，除了本文档中定义的参数或一组完全不同的参数外，该配置文件还可能包含新的参数。最后，还可以注册一个特定的QoS配置文件，该配置文件定义了一组特定的QoS值，而不是需要填充值才能使用的参数。
To enable the definition of new QoS profiles, an 8-octet registry is defined as a field that is represented by 4-octet vendor and 4-octet specifier fields. The vendor field contains an Enterprise Number as defined in [RFC2578], taken from the values maintained in the IANA Enterprise Numbers registry. If the four octets of the vendor field
为了能够定义新的QoS配置文件，8个八位字节的注册表被定义为一个由4个八位字节的供应商字段和4个八位字节的说明符字段表示的字段。供应商字段包含[RFC2578]中定义的企业编号，该编号取自IANA企业编号注册表中维护的值。如果供应商字段的四个八位字节
are 0x00000000 (reserved value for IANA), then the value in the specifier field MUST be registered with IANA (see Section 5.2). If the vendor field is other than 0x00000000, the value of the specifier field represents a vendor-specific value, where allocation is the responsibility of the enterprise indicated in the vendor field.
是0x00000000（IANA的保留值），则必须向IANA注册说明符字段中的值（参见第5.2节）。如果供应商字段不是0x00000000，则说明符字段的值表示供应商特定的值，其中分配是供应商字段中指示的企业的责任。
IANA allocated AVP codes in the IANA-controlled namespace registry specified in Section 11.1.1 of [RFC3588] for the following AVPs that are defined in this document.
IANA在[RFC3588]第11.1.1节规定的IANA受控命名空间注册表中为本文件中定义的以下AVP分配了AVP代码。
+------------------------------------------------------------------+
| AVP Section |
|AVP Name Code Defined Data Type |
+------------------------------------------------------------------+
|TMOD-1 495 3.1 Grouped |
|Token-Rate 496 3.1.1 Float32 |
|Bucket-Depth 497 3.1.2 Float32 |
|Peak-Traffic-Rate 498 3.1.3 Float32 |
|Minimum-Policed-Unit 499 3.1.4 Unsigned32 |
|Maximum-Packet-Size 500 3.1.5 Unsigned32 |
|TMOD-2 501 3.2 Grouped |
|Bandwidth 502 3.3 Float32 |
|PHB-Class 503 3.4 Unsigned32 |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| AVP Section |
|AVP Name Code Defined Data Type |
+------------------------------------------------------------------+
|TMOD-1 495 3.1 Grouped |
|Token-Rate 496 3.1.1 Float32 |
|Bucket-Depth 497 3.1.2 Float32 |
|Peak-Traffic-Rate 498 3.1.3 Float32 |
|Minimum-Policed-Unit 499 3.1.4 Unsigned32 |
|Maximum-Packet-Size 500 3.1.5 Unsigned32 |
|TMOD-2 501 3.2 Grouped |
|Bandwidth 502 3.3 Float32 |
|PHB-Class 503 3.4 Unsigned32 |
+------------------------------------------------------------------+
The QoS profile refers to a 64-bit field that is represented by 4-octet vendor and 4-octet specifier fields. The vendor field indicates the type as either standards-specified or vendor-specific.
QoS配置文件是指一个64位字段，由4个八位字节的供应商字段和4个八位字节的说明符字段表示。“供应商”字段表示指定标准或供应商特定的类型。
If the four octets of the vendor field are 0x00000000, then the value is standards-specified and a registry will be created to maintain the QoS profile specifier values. The specifier field indicates the actual QoS profile. Depending on the value requested, the action needed to request a new value is:
如果供应商字段的四个八位字节为0x00000000，则该值为指定的标准值，并将创建一个注册表来维护QoS配置文件说明符值。说明符字段指示实际的QoS配置文件。根据请求的值，请求新值所需的操作为：
0 to 511: Standards Action
0至511：标准行动
512 to 32767: Specification Required
512至32767：需要规格
32768 to 4294967295: Reserved
32768至4294967295：保留
Standards action is required to add, depreciate, delete, or modify QoS profile values in the range of 0-511, and a specification is required to add, depreciate, delete, or modify existing QoS profile values in the range of 512-32767.
添加、折旧、删除或修改0-511范围内的QoS配置文件值需要标准操作，添加、折旧、删除或修改512-32767范围内的现有QoS配置文件值需要规范。
IANA created such a registry and allocated the value zero (0) for the QoS profile defined in this document.
IANA创建了这样一个注册表，并为本文档中定义的QoS配置文件分配了值零（0）。
Alternative vendor-specific QoS profiles can be created and identified with an Enterprise Number taken from the IANA registry created by [RFC2578] in the vendor field, combined with a vendor-specific value in the specifier field. Allocation of the specifier values is the responsibility of the vendor.
可以创建备选供应商特定的QoS配置文件，并使用从供应商字段中[RFC2578]创建的IANA注册表中获取的企业编号以及说明符字段中的供应商特定值进行标识。指定值的分配由供应商负责。
This document does not raise any security concerns as it only defines QoS parameters and does not yet describe how they are exchanged in an Authentication, Authorization, and Accounting (AAA) protocol. Security considerations are described in documents using this specification.
本文档没有提出任何安全问题，因为它只定义了QoS参数，还没有描述如何在身份验证、授权和计费（AAA）协议中交换这些参数。使用本规范的文档中描述了安全注意事项。
The authors would like to thank the NSIS working group members Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran; the former NSIS working group chairs John Loughney and Martin Stiemerling; and the former Transport Area Directors Allison Mankin and Jon Peterson for their help.
作者要感谢NSIS工作组成员Cornelia Kappler、Jerry Ash、Attila Bader和Dave Oran；前NSIS工作组主席约翰·洛尼和马丁·斯蒂梅林；以及前交通部门主管Allison Mankin和Jon Peterson的帮助。
We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for their feedback regarding some of the parameters in this documents.
我们要感谢Ken Carlberg、Lars Eggert、Jan Engelhardt、Francois Le Faucheur、John Loughney、An Nguyen、Dave Oran、James Polk、Martin Dolly、Martin Stieemering和Magnus Westerlund对本文件中一些参数的反馈。
Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu provided help with the semantics of some QSPEC parameters.
Jerry Ash、Al Morton、Mayutan Arumaithurai和付晓明提供了一些QSPEC参数的语义帮助。
We would like to thank Dan Romascanu for his detailed Area Director review comments and Scott Bradner for his Transport Area Directorate review. Chris Newman, Adrian Farrel, and Pasi Eronen provided feedback during the IESG review.
我们要感谢丹·罗马斯坎努（Dan Romascanu）详细的区域总监审查意见，以及斯科特·布拉德纳（Scott Bradner）的运输区域总监审查意见。Chris Newman、Adrian Farrel和Pasi Eronen在IESG审查期间提供了反馈。
[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月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[RFC2215]Shenker，S.和J.Wroclawski，“综合业务网元的一般特征参数”，RFC 2215，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月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]Black，D.，Brim，S.，Carpenter，B.，和F.Le Faucheur，“每跳行为识别码”，RFC 31402001年6月。
[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月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 25971999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697]Heinanen，J.和R.Guerin，“单速率三色标记”，RFC 26971999年9月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
o 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
o 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
o 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
TMOD-1 ::= < AVP Header: 495 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
TMOD-1 ::= < AVP Header: 495 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
TMOD-2 ::= < AVP Header: 501 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
TMOD-2 ::= < AVP Header: 501 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
Authors' Addresses
作者地址
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Jouni Korhonen（编辑）诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
EMail: jouni.korhonen@nsn.com
EMail: jouni.korhonen@nsn.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
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly咨询英国苏哈姆
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com