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.
この文書は、Diameter内QoS情報を搬送するために再利用することができるサービスの品質（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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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].
この文書では、Diameterプロトコル[RFC3588]内のQoS情報を搬送するために再利用することができるサービスの品質（QoS）パラメータの数を定義します。この文書で定義されたQoSパラメータの現在のセットは、広範囲の用途に有用であることが決定され、コアのサブセットです。追加のパラメータは、必要に応じて将来の文書で定義されており、今後の検討課題であることができます。パラメータは増補バッカス - ナウアフォーム（ABNF）の修正バージョンを使用して記載されている直径でエンコードされた属性値ペア（AVPの）として定義され、[RFC3588]を参照。データタイプはまた、[RFC3588]から取られます。
The traffic model (TMOD) AVPs are containers consisting of four AVPs and provide a way to describe the traffic source.
トラフィックモデル（TMOD）のAVPは、4つのAVPからなる容器であり、トラフィックのソースを記述する方法を提供します。
o token rate (r)
Oトークンレート（R）
o bucket depth (b)
Oバケット深さ（B）
o peak traffic rate (p) o minimum policed unit (m)
Oピークトラフィックレート（P）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に見出すことができます。これら二つのAVPのセマンティクスは[RFC2210]のセクション3.1と[RFC2215]のセクション3.6に記載されています。
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の保証転送（AF）トラフィックのために、トークン・バケット・パラメータの二組が必要とされている：平均トラフィックのための1つのトークンバケットと、バーストトラフィックのための1つのトークンバケット。 [RFC2697]は3つのトラフィックパラメータに従ってシングルレート3カラーマーカー（srTCM）、メートルトラフィックストリームを定義し、そのパケットをマーク - 認定情報速度（CIR）、認定バーストサイズ（CBS）、及び超過バーストサイズ（EBSを） - 、緑、黄色、または赤色のいずれかであることが。それがCBSではなく、EBSを超えない場合は黄色、CBSを超え、そして赤そうしない場合、パケットは緑色にマーキングされます。 [RFC2697]は同じ速度で動作2つのトークンバケットを使用して特定の手順を定義します。したがって、2つのTMODのAVPは、廃棄優先順位3つのレベルを区別するのに十分です。例はまた、[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クラス> AVPを使用して）特定のDiffServホップ単位動作（PHB）でパケットプロセッサを参照してください可能性があります。 DiffServアーキテクチャの一般的な説明は、[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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 }
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）は、タイプのfloat32です。
The Peak-Traffic-Rate AVP (AVP Code 498) is of type Float32.
ピークトラフィックレートAVP（AVPコード498）は、タイプのfloat32です。
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 }
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は、帯域幅がある場合、トークンレート（R）=ピークトラフィックレート（P）、（B）が大きい=バケット深さ、および最小ポリシング単位（m）が大きい=れる設定以下TMODの簡略化した説明を表します表現することにします。
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]で使用するために必要なレジストリが既に存在しているので、新しいレジストリは、この目的のために必要とされていません。エンコードは3例が区別されている必要があります。 「予約済み」と示されるすべてのビットはゼロに設定しなければなりません（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ビットのフィールドはゼロにセット15を介してビット6です。
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のセットのための符号化は、ビット14が設定された1に、セット内の種々のPHBのための符号化方式の組の数値的に最も小さい（したがって、AF1xのPHBのために、符号化ビットと、AF11 PHBのものです1〜14セット）
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.
[RFC2474]で許可さのPHBは、標準アクション、すなわち、実験的または局所使用のPHBによって定義されなくてもよいです。この場合には、IANAによって割り当てられた任意の12ビットPHB識別コードは、16ビットのフィールドで左詰めされます。ビット15が1に設定され、のPHBのセットのための単一のPHBのために0または1である14ビットです。ビット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のセットを識別するために使用される場合の両方の場合において、PHBスケジューリングのクラスを構成しなければならないのPHBのセット（すなわち、セットからのPHBの使用がイントラ引き起こしてはならない、（すなわち、14は、1に設定されているビット）セットとは異なるのPHBを同じマイクロトラフィックに適用される-microflowトラフィック並べ替え）。 AF1xのPHB [RFC2597]のセットは、PHBスケジューリングクラスの例です。 PHBスケジューリングクラスを構成しないのPHBのセットは、複数のPHBIDを使用することによって識別することができます。
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 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.
新しいQoSプロファイルの定義を可能にするために、8オクテットレジストリは4オクテットのベンダー及び4オクテットの指定フィールドによって表されるフィールドとして定義されています。 [RFC2578]で定義されるベンダーフィールドはIANAエンタープライズ番号レジストリで保持値から採取した、エンタープライズ番号が含ま。ベンダーフィールドの4つのオクテットは、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は、この文書で定義されている以下のAVPのために[RFC3588]のセクション11.1.1に指定IANA制御名前空間レジストリに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 |
+------------------------------------------------------------------+
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プロファイルは、4オクテットのベンダー及び4オクテットの指定フィールドで表される64ビットのフィールドを指します。ベンダーのフィールドのいずれかの規格が指定するか、ベンダー固有のようなタイプを示します。
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:
ベンダーフィールドの4つのオクテットが0x00000000のであれば、その値は、標準指定され、レジストリは、QoSプロファイルの指定値を維持するために作成されます。指定フィールドは、実際のQoSプロファイルを示しています。要求された値に応じて、新しい値を要求するために必要なアクションは次のとおりです。
0 to 511: Standards Action
511から0：標準アクション
512 to 32767: Specification Required
32767から512：仕様が必要
32768 to 4294967295: Reserved
4294967295から32768：リザーブ
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ワーキンググループメンバーコーネリアKappler、ジェリー・アッシュ、アッティラバーダー、とDaveオランに感謝したいと思います。旧NSISワーキンググループは、ジョンLoughneyとマーティンStiemerlingの議長を務めます。彼らの助けのために、元交通エリアの取締役アリソンマンキンとジョンピーターソン。
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.
私たちは、この文書のパラメータのいくつかについて、彼らのフィードバックのためにケン・カールバーグ氏、ラースEggertの、ヤンエンゲルハート、フランソワ・ルFaucheur、ジョンLoughney、アングエン、デイブ・オラン、ジェームズ・ポーク、マーティンドリー、マーティンStiemerling、およびマグヌスウェスターに感謝したいと思います。
Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu provided help with the semantics of some QSPEC parameters.
ジェリー・アッシュ、アル・モートン、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.
私たちは、彼の交通エリア総局の審査のための彼の詳細エリアディレクターのレビューコメントとスコット・ブラッドナーのためのダンRomascanuに感謝したいと思います。クリス・ニューマン、エードリアンファレル、およびパシEronenはIESGレビュー中にフィードバックを提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC3140]黒、D.、つば、S.、大工、B.、およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen、J.とR.ゲラン、 "シングルレート3カラーマーカー"、RFC 2697、1999年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]デイビー、B.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
Appendix A. ABNF Code Fragment
付録A. ABNFコード・フラグメント
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トラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
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.
このソフトウェアは、著作権所有者によって提供され、貢献者AS IS 'AND明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証を放棄されています。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
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 }
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Jouni Korhonen（編集）、ノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
EMail: jouni.korhonen@nsn.com
メールアドレス：jouni.korhonen@nsn.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at
Elwyn Davies Folly Consulting Soham UK
エルウィン・デイヴィスフォリーコンサルティングソーハム英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com