[要約] RFC 5624は、Diameterと共に使用するための品質サービスパラメータに関する規格です。このRFCの目的は、Diameterプロトコルを使用してネットワーク上で品質サービスを提供するためのパラメータを定義することです。
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情報を伝えるために再利用できる多数のサービス（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情報には、トークンバケットフィルター、帯域幅パラメーター、およびPERホップの動作クラスオブジェクトを記述するためのデータトラフィックパラメーターが含まれています。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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].
このドキュメントでは、直径プロトコル[RFC3588]内でQoS情報を伝えるために再利用できる多くのサービスの品質（QOS）パラメーターを定義します。このドキュメントで定義されているQoSパラメーターの現在のセットは、幅広いアプリケーションに役立つと判断されたコアサブセットです。追加のパラメーターは、必要性が生じ、将来の研究のための将来のドキュメントで定義される場合があります。パラメーターは、拡張されたバックスNAUR形式（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に記載されています。これら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 Expedited Forwarding（EF）トラフィックは、単一のトークンバケットによって侵入で形作られると想定されています。したがって、単一のTMODパラメーターでは、DiffServ EFトラフィックを信号するのに十分です。ただし、DiffServ Assured Forwarding（AF）トラフィックには、2セットのトークンバケットパラメーターが必要です。平均トラフィックには1つのトークンバケット、バーストトラフィックには1つのトークンバケットが必要です。[RFC2697]は、トラフィックストリームを計算し、3つのトラフィックパラメーター（コミットされた情報レート（CIR）（CIR）、コミットバーストサイズ（CBS）、および過剰バーストサイズ（EB））に従ってパケットをマークする単一レート3色マーカー（SRTCM）を定義します。） - 緑、黄色、または赤のいずれかである。パケットは、CBSを超えない場合は緑色にマークされています。CBSを超えている場合は黄色ではなく、EBSを超えていない場合は、それ以外の場合は赤です。[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").
リソースの予約は、特定のDiffserv Per Hop動作（PHB）を備えたパケットプロセッサを指す場合があります（<PHB-Class> AVPを使用）。Diffservアーキテクチャの一般的な説明は[RFC2475]に記載されており、[RFC2474]のセクション3で区別されたサービスフィールドを説明します。更新された用語は[RFC3260]に記載されています。たとえば、標準化された過ホップあたりの動作は、[RFC2597]（「Assured PHB Group」）および[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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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）は、signed32のタイプです。
The Maximum-Packet-Size AVP (AVP Code 500) is of type Unsigned32.
最大パケットサイズのAVP（AVPコード500）は、符号なし32です。
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で、1秒あたりのIPデータグラムのオクテットで測定されます。帯域幅AVPは、トークンレート（r）=ピークトラフィックレート（p）、バケット深さ（b）=大部分、および最小ポリシーユニット（m）=帯域幅のみが持っている場合に、次のTMOD設定の簡素化された説明を表します。表現される。
The PHB-Class AVP (AVP Code 503) is of type Unsigned32.
PHBクラスAVP（AVPコード503）は、符号なし32です。
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ビットフィールドで左正当化され、ビット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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットフィールドで左正義化されます。ビット15は1に設定されており、ビット14は単一のPHBではゼロまたはPHBのセットで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の使用はイントラを引き起こしてはなりません-microflowのトラフィックは、セットから異なるphbが同じマイクロフロー内のトラフィックに適用される場合に並べ替えます）。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-OCTET仕様フィールドで表されるフィールドとして定義されます。ベンダーフィールドには、IANAエンタープライズ番号レジストリで維持されている値から取られた[RFC2578]で定義されているエンタープライズ番号が含まれています。ベンダーフィールドの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-OCTET仕様フィールドで表される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
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ワーキンググループのメンバーであるコーネリア・カップラー、ジェリー・アッシュ、アッティラ・バダー、デイブ・オランに感謝したいと思います。元NSISワーキンググループの議長ジョン・ラウニーとマーティン・スティメルリング。そして、元交通エリアのディレクターであるアリソン・マンキンとジョン・ピーターソンの助けを求めて。
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.
ケン・カールバーグ、ラース・エガート、ヤン・エンゲルハルト、フランソワ・ル・ファウチュール、ジョン・ラフニー、ジョン・ラフニー、ヌグエン、デイブ・オラン、ジェームズ・ポーク、マーティン・ドリー、マーティン・スティメルリング、マグナス・ウェスターランドに感謝します。。
Jerry Ash, Al Morton, Mayutan Arumaithurai, and Xiaoming Fu provided help with the semantics of some QSPEC parameters.
Jerry Ash、Al Morton、Mayutan Arumaithurai、およびXiaoming Fuは、いくつかの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に感謝します。クリス・ニューマン、エイドリアン・ファレル、およびパシ・エロネンは、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。、「IETF統合サービスでのRSVPの使用」、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. Schoenwaelder、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、「Per Hopの動作識別コード」、RFC 3140、2001年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 2475、1998年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、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999.
[RFC2697] Heinanen、J。およびR. Guerin、「単一レート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.、Bennet、J.、Benson、K.、Le Boudec、J.、Courtney、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] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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.
このソフトウェアは、著作権所有者と貢献者が「現状で」提供し、特定の目的に対する商品性と適合性の暗黙の保証を含むがこれらに限定されない明示的または黙示的な保証によって提供されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
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（編集者）Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
EMail: jouni.korhonen@nsn.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly Consulting Soham UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com