Internet Engineering Task Force (IETF) J. Korhonen
Request for Comments: 5777 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 M. Arumaithurai
University of Goettingen
M. Jones, Ed.
A. Lior
Bridgewater Systems
February 2010
Traffic Classification and Quality of Service (QoS)
Attributes for Diameter
Abstract
抽象
This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy.
この文書では、フィルタリングおよびサービス品質（QoS）の治療のためのアクションを持つトラフィック分類のための直径属性値ペア（AVPの）の数を定義します。これらのAVPは、それぞれ直径コマンド拡張ポリシーの増補バッカス - ナウアフォーム（ABNF）仕様によって許可既存および将来のDiameterアプリケーションで使用することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5777.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5777で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Rule Sets and Rules .............................................4
3.1. QoS-Resources AVP ..........................................5
3.2. Filter-Rule AVP ............................................5
3.3. Filter-Rule-Precedence AVP .................................6
4. Conditions ......................................................6
4.1. Traffic Classifiers ........................................6
4.1.1. Classifier AVP ......................................8
4.1.2. Classifier-ID AVP ...................................9
4.1.3. Protocol AVP ........................................9
4.1.4. Direction AVP .......................................9
4.1.5. From-Spec AVP .......................................9
4.1.6. To-Spec AVP ........................................10
4.1.7. Source and Destination AVPs ........................11
4.1.8. Header Option AVPs .................................15
4.2. Time Of Day AVPs ..........................................22
4.2.1. Time-Of-Day-Condition AVP ..........................22
4.2.2. Time-Of-Day-Start AVP ..............................23
4.2.3. Time-Of-Day-End AVP ................................23
4.2.4. Day-Of-Week-Mask AVP ...............................23
4.2.5. Day-Of-Month-Mask AVP ..............................24
4.2.6. Month-Of-Year-Mask AVP .............................24
4.2.7. Absolute-Start-Time AVP ............................25
4.2.8. Absolute-Start-Fractional-Seconds AVP ..............25
4.2.9. Absolute-End-Time AVP ..............................25
4.2.10. Absolute-End-Fractional-Seconds AVP ...............25
4.2.11. Timezone-Flag AVP .................................25
4.2.12. Timezone-Offset AVP ...............................26
5. Actions ........................................................26
5.1. Treatment-Action AVP ......................................26
5.2. QoS-Profile-Id AVP ........................................27
5.3. QoS-Profile-Template AVP ..................................27
5.4. QoS-Semantics .............................................28
5.5. QoS-Parameters AVP ........................................29
5.6. Excess-Treatment AVP ......................................29
6. QoS Capability Indication ......................................29
7. Examples .......................................................30
7.1. Diameter EAP with QoS Information .........................30
7.2. Diameter NASREQ with QoS Information ......................32
7.3. QoS Authorization .........................................33
7.4. Diameter Server Initiated Re-Authorization of QoS .........33
7.5. Diameter Credit Control (CC) with QoS Information .........34
7.6. Classifier Examples .......................................35
7.7. QoS Parameter Examples ....................................37
8. Acknowledgments ................................................37
9. Contributors ...................................................37
10. IANA Considerations ...........................................38
10.1. AVP Codes ................................................38
10.2. QoS-Semantics IANA Registry ..............................39
10.3. Action ...................................................40
11. Security Considerations .......................................40
12. References ....................................................40
12.1. Normative References .....................................40
12.2. Informative References ...................................41
Appendix A. MAC and EUI64 Address Mask Usage Considerations ......42
This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy.
この文書では、フィルタリングおよびサービス品質（QoS）の治療のためのアクションを持つトラフィック分類のための直径属性値ペア（AVPの）の数を定義します。これらのAVPは、それぞれ直径コマンド拡張ポリシーの増補バッカス - ナウアフォーム（ABNF）仕様によって許可既存および将来のDiameterアプリケーションで使用することができます。
The work on Quality of Service treatment and filtering via Diameter dates back to the base protocol described in RFC 3588 [RFC3588]. The filtering and QoS functionality was provided by the IPFilterRule AVP and the QoSFilterRule AVP. Both AVPs relied on syntax based on the FreeBSD ipfw tool for traffic classification. The functionality of the QoSFilterRule AVP was underspecified in RFC 3588 [RFC3588] and was later updated by RFC 4005 [RFC4005].
ビア径サービス処理及びフィルタリングの品質上の作業は、バックRFC 3588 [RFC3588]に記載のベースプロトコルにさかのぼります。フィルタリングおよびQoS機能がIPFilterRuleのAVPとQoSFilterRule AVPによって提供されました。どちらのAVPは、トラフィック分類のためのFreeBSDのipfwのツールに基づく構文に依存していました。 QoSFilterRule AVPの機能は、RFC 3588 [RFC3588]にunderspecifiedされ、後にRFC 4005 [RFC4005]で更新されました。
As part of the work on updating RFC 3588, the functionality of the IPFilterRule and the QoSFilterRule was revised by the functionality offered by this document with the goals of a uniform and extensible traffic classification mechanism in a native Diameter syntax (instead of the free text previously used). Additionally, an extensible set of actions is provided that offers the ability for filtering and for QoS treatment, whereby the QoS functionality was extended to meet the needs of today's networking environments.
RFC 3588の更新の作業の一環として、IPFilterRuleのとQoSFilterRuleの機能は、以前の代わりにフリーテキストのネイティブ直径構文で均一かつ拡張トラフィック分類メカニズムの目標（と、この文書が提供する機能により改訂されました中古）。また、アクションの拡張可能なセットは、フィルタリングのためおよびQoS機能は、今日のネットワーク環境のニーズを満たすために拡張されたことにより、QoS処理のための機能を提供していますが提供されます。
The QoS-Resources AVP represents a complete rule set with each rule represented by a Filter-Rule AVP. Each rule consists of information for handling conflict resolution, a conditions part and the corresponding actions to be performed if the conditions are satisfied. The AVPs responsible for expressing a condition are defined in Section 4. The capability to match all or a subset of the data traffic is provided. This includes the ability to match on Ethernet specific attributes, which was not possible with the QoS-Filter-Rule AVP. Service differentiation may be based on Ethernet priority bits, a single layer of VLAN-IDs or stacked VLAN-IDs, Logical Link Control (LLC) attributes, MAC addresses, or any combination thereof. The header fields used for Ethernet classification are defined in the IEEE802 series of specifications: [IEEE802.2], [IEEE802.1ad], [IEEE802.1Q], and [IEEE802.1D]. Additionally, time-based conditions can be expressed based on the functionality offered by the attributes in Section 4.2.
QoSの-リソースAVPは、フィルター・ルールAVPによって表される各ルールに設定され、完全なルールを表します。各ルールは、競合解決、条件部と条件が満たされた場合に実行される対応するアクションを処理するための情報で構成されています。条件を表現するための責任のAVPは、第4項または全部のデータトラフィックのサブセットが提供されると一致する機能で定義されています。これは、QoS-FILTER-規則AVPでは不可能だったイーサネット特定の属性、上で照合する機能が含まれています。サービスの差別化は、イーサネット優先ビット、単一のVLAN-IDの層または積層VLAN-IDは、論理リンク制御（LLC）は、属性、MACアドレス、またはそれらの任意の組み合わせに基づいてもよいです。 [IEEE802.1D] [IEEE802.1Q]、[IEEE802.1ad]、[IEEE802.2]、およびイーサネットの分類に使用されるヘッダーフィールド仕様のIEEE802シリーズで定義されています。また、時間ベースの条件はセクション4.2の属性によって提供される機能に基づいて表現することができます。
The action part of a rule contains the type of traffic treatment and further description regarding QoS-related actions.
ルールのアクション部分は、トラフィック処理およびQoS関連のアクションに関する更なる説明の種類が含まれています。
The QoS policy rules are defined as Diameter encoded attribute-value pairs (AVPs) described using a modified version of the Augmented Backus-Naur Form (ABNF) (see [RFC3588]). The AVP datatypes are also taken from [RFC3588].
QoSポリシールールは直径符号化された属性値ペア（AVPの）として定義された拡張バッカス・ナウアフォーム（ABNF）の修正バージョンを使用して記載されている（参照[RFC3588]）。 AVPデータ型はまた、[RFC3588]から取られます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
As mentioned in the introduction, the top-level element is the QoS-Resources AVP that encapsulates one or more Filter-Rule AVPs.
冒頭で述べたように、トップレベルの要素は、1つ以上のフィルタ・ルールのAVPをカプセル化したQoS-リソースAVPです。
The QoS-Resources AVP (AVP Code 508) is of type Grouped and contains a list of filter policy rules.
QoSの資源AVP（AVPコード508）がグループ化タイプであり、フィルタポリシールールのリストを含みます。
QoS-Resources ::= < AVP Header: 508 >
1*{ Filter-Rule }
* [ AVP ]
The Filter-Rule AVP (AVP Code 509) is of type Grouped and defines a specific condition and action combination.
フィルタ規則AVP（AVPコード509）がグループ化されたタイプのものであり、特定の条件およびアクションの組み合わせを定義します。
Filter-Rule ::= < AVP Header: 509 >
[ Filter-Rule-Precedence ]
; Condition part of a Rule
; ------------------------
[ Classifier ] * [ Time-Of-Day-Condition ]
[分類子] * [時刻-条件]
; Action and Meta-Data
; --------------------
[ Treatment-Action ]
[治療アクション]
; Info about QoS related Actions
; ------------------------------
[ QoS-Semantics ] [ QoS-Profile-Template ] [ QoS-Parameters ] [ Excess-Treatment ]
[QoSの-意味論] [QoSの-プロファイルテンプレート] [QoSの-パラメータ] [過剰-処理]
; Extension Point
; ---------------
* [ AVP ]
If the QoS-Profile-Template AVP is not included in the Filter-Rule AVP and the Treatment-Action AVP is set to 'shape' or 'mark' then the default setting is assumed, namely, a setting of the Vendor-Id AVP to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) (for the profile defined in [RFC5624]). Note that the content of the QoS-Parameters are defined in the respective specification defining the QoS parameters. When the Vendor-Id AVP is set to 0 (for IETF) and the
QoSの-プロファイル・テンプレートのAVPは、フィルター・ルールAVPに含まれていないと治療アクションAVPは、「形状」や、デフォルトの設定はベンダーID AVPの、すなわち、設定、想定している「マーク」に設定されている場合（IETFのために）0とにQoS-プロファイル-ID AVPにゼロ（0）（で定義されたプロファイルの[RFC5624]）。 QoSパラメータの内容は、QoSパラメータを規定するそれぞれの仕様で定義されていることに留意されたいです。ベンダーID AVPは、（IETFのために）0に設定されている場合、および
QoS-Profile-Id AVP is set to zero (0), then the AVPs included in the QoS-Parameters AVP are the AVPs defined in [RFC5624].
QoSをプロファイル-ID AVPは[RFC5624]で定義のAVPは、（0）、その後のAVPは、QoSパラメータAVPに含まれるゼロに設定されます。
The Filter-Rule-Precedence AVP (AVP Code 510) is of type Unsigned32 and specifies the execution order of the rules expressed in the QoS-Resources AVP. The lower the numerical value of Filter-Rule-Precedence AVP, the higher the rule precedence. Rules with equal precedence MAY be executed in parallel if supported by the Resource Management Function. If the Filter-Rule-Precedence AVP is absent from the Filter-Rule AVP, the rules SHOULD be executed in the order in which they appear in the QoS-Resources AVP.
フィルタ・ルール優先順位AVP（AVPコード510）はタイプUnsigned32にあるとQoS資源AVPで発現ルールの実行順序を指定します。ルールの優先順位が高いほど、フィルタルール優先AVPの数値が低いです。リソース管理機能でサポートされている場合等しい優先順位のルールが並行して実行することができます。フィルター・ルールの優先順位AVPは、フィルター・ルールAVPに存在しない場合は、ルールは、彼らがQoS-リソースAVPに表示されている順序で実行する必要があります。
This section describes the condition part of a rule. Two condition types are introduced by this document: packet classification conditions represented by the Classifier AVP and time of day conditions represented by the Time-Of-Day-Condition AVP.
このセクションでは、ルールの条件部を説明します。二つの条件タイプは、本書で紹介されています。分類子AVPと時刻-条件AVPで表さ日条件の時に代表されるパケット分類条件を。
If more than one instance of the Time-Of-Day-Condition AVP is present in the Filter-Rule AVP, the current time at rule evaluation MUST be within at least one of the time windows specified in one of the Time-Of-Day-Condition AVPs.
時刻-条件AVPの複数のインスタンスがフィルター・ルールAVPに存在する場合、ルール評価で、現在時刻が時刻の一つに指定された時間ウィンドウの少なくとも1以内でなければなりません-conditionのAVP。
When the Time-Of-Day-Condition AVP and Classifier AVP are present in the same Filter-Rule AVP, both the time of day and packet classification conditions MUST match for the traffic treatment action to be applied.
時刻-条件AVPと分類子AVPは、トラフィックの処理動作のために一致しなければならない日とパケット分類条件の時間の両方に同じフィルター・ルールAVPに存在しているときに適用されます。
Classifiers are used in many applications to specify how to select a subset of data packets for subsequent treatment as indicated in the action part of a rule. For example, in a QoS application, if a packet matches a classifier then that packet will be treated in accordance with a QoS specification associated with that classifier. Figure 1 shows a typical deployment.
分類器は、ルールのアクション部分に示されているように、その後の処理のためのデータパケットのサブセットを選択する方法を指定するために、多くの用途に使用されています。パケットは、次に、分類子と一致する場合、例えば、QoSのアプリケーションでは、そのパケットは、その分類子に関連付けられたQoS仕様に従って処理されるであろう。図1は、典型的な配置を示しています。
+-----------+
+-----------+|
+--------+ +-------------+ +------------+||
| | IN | | | |||
| +--------->| +------------->| |||
|Managed | | Classifying | | Unmanaged |||
|Terminal| OUT | Entity | | Terminal |||
| |<---------+ |<-------------+ ||+
| | | | | |+
+--------+ +-------------+ +------------+
^
| Classifiers
|
+------+------+
| |
| AAA |
| |
+-------------+
Figure 1: Example of a Classifier Architecture
図1：クラシファイアアーキテクチャの例
The managed terminal, the terminal for which the classifiers are being specified, is located on the left of the Classifying Entity. The unmanaged terminals, the terminals that receive packets from the managed terminal or send packets to the managed terminal, are located to the right side of the Classifying Entity.
管理端末が、分類が指定されている端子は、分類エンティティの左側に位置しています。管理対象外の端末、管理端末からのパケットを受信または管理対象の端末にパケットを送信する端末は、分類エンティティの右側に位置しています。
The Classifying Entity is responsible for classifying packets that are incoming (IN) from the managed terminal or packets outgoing (OUT) to the managed terminal.
分類エンティティは、管理端末に管理し、端末またはパケットの発信（OUT）からの着信（IN）のパケットを分類するための責任があります。
A classifier consists of a group of attributes that specify how to match a packet. Each set of attributes expresses values about aspects of the packet -- typically the packet header. Different protocols therefore would use different attributes.
クラシファイアは、パケットを一致させる方法を指定する属性のグループから構成されています。典型的には、パケットヘッダ - 属性の各セットは、パケットの側面についての値を表します。異なるプロトコルは、したがって、異なる属性を使用します。
In general, a classifier consists of the following:
一般的には、分類器の構成は次のとおりです。
Identifier:
識別：
The identifier uniquely identifies this classifier and may be used to reference the classifier from another structure.
識別子は、この分類子を識別し、他の構造から分類子を参照するために使用されてもよいです。
From:
から：
Specifies the rule for matching the protocol-specific source address(es) part of the packet.
プロトコル固有の送信元アドレス（ES）パケットの一部を一致させるためのルールを指定します。
To:
と：
Specifies the rule for matching the protocol-specific destination address(es) part of the packet.
プロトコル固有の宛先アドレス（ES）パケットの一部を一致させるためのルールを指定します。
Protocol:
プロトコル：
Specifies the matching protocol of the packet.
パケットの一致するプロトコルを指定します。
Direction:
方向：
Specifies whether the classifier is to apply to packets flowing from the managed terminal (IN) or to packets flowing to the managed terminal (OUT) or to packets flowing in both directions.
分類器は、管理端子（IN）から流れるパケットにまたは管理端子（OUT）にまたは両方向に流れるパケットに流れるパケットに適用するかどうかを指定します。
Options:
オプション：
Attributes or properties associated with each protocol or layer, or various values specific to the header of the protocol or layer. Options allow matching on those values.
プロトコルまたはレイヤのヘッダに特定の属性または各プロトコルまたはレイヤに関連するプロパティ、または様々な値。オプションは、これらの値に一致することができます。
Each protocol type will have a specific set of attributes that can be used to specify a classifier for that protocol. These attributes will be grouped under a grouped AVP called a Classifier AVP.
各プロトコルの種類はそのプロトコルのための分類子を指定するために使用できる属性の特定のセットを持っています。これらの属性は、分類子AVPと呼ばれるグループ化AVPの下にグループ化されます。
The Classifier AVP (AVP Code 511) is a grouped AVP that consists of a set of attributes that specify how to match a packet.
分類AVP（AVPコード511）は、パケットを一致させる方法を指定する属性のセットから成るグループ化AVPです。
Classifier ::= < AVP Header: 511 >
{ Classifier-ID }
[ Protocol ]
[ Direction ]
* [ From-Spec ]
* [ To-Spec ]
* [ Diffserv-Code-Point ]
[ Fragmentation-Flag ]
* [ IP-Option ]
* [ TCP-Option ]
[ TCP-Flags ]
* [ ICMP-Type ]
* [ ETH-Option ]
* [ AVP ]
The Classifier-ID AVP (AVP Code 512) is of type OctetString and uniquely identifies the classifier. Each application will define the uniqueness scope of this identifier, e.g., unique per terminal or globally unique. Exactly one Classifier-ID AVP MUST be contained within a Classifier AVP.
分類-ID AVP（AVPコード512）はタイプOctetStringにあり、一意に識別器を識別する。各アプリケーションは、端末ごとに一意またはグローバル一意識別子、例えば、一意の範囲を定義します。正確に一つの分類-ID AVPは、分類AVPの中に含まれていなければなりません。
The Protocol AVP (AVP Code 513) is of type Enumerated and specifies the protocol being matched. The attributes included in the Classifier AVP MUST be consistent with the value of the Protocol AVP. Exactly zero or one Protocol AVP may be contained within a Classifier AVP. If the Protocol AVP is omitted from the classifier, then comparison of the protocol of the packet is irrelevant. The values for this AVP are managed by IANA under the Protocol Numbers registry as defined in [RFC2780].
プロトコルAVP（AVPコード513）がタイプ列挙であり、一致しているプロトコルを指定します。分類子AVPに含ま属性は、プロトコルAVPの値と一致していなければなりません。正確にゼロまたは1つのプロトコルAVPは、分類のAVPの中に含まれていてもよいです。プロトコルAVPがクラシファイアから省略されている場合、パケットのプロトコルの比較は無関係です。 [RFC2780]で定義された、このAVPの値は、プロトコル番号レジストリの下でIANAによって管理されています。
The Direction AVP (AVP Code 514) is of type Enumerated and specifies in which direction to apply the classifier. The values of the enumeration are "IN","OUT","BOTH". In the "IN" and "BOTH" directions, the From-Spec refers to the address of the managed terminal and the To-Spec refers to the unmanaged terminal. In the "OUT" direction, the From-Spec refers to the unmanaged terminal whereas the To-Spec refers to the managed terminal. If the Direction AVP is omitted, the classifier matches packets flowing in both directions.
方向AVP（AVPコード514）がタイプ列挙であり、分類器を適用した方向に指定します。列挙の値は、「IN」、「OUT」、「BOTH」です。 「IN」と「BOTH」の方向に、からスペックは、管理対象端末のアドレスを参照し、TO-スペックは、管理対象外の端末を指します。 TO-仕様管理、端末を指し、一方、「OUT」の方向では、からスペックは、管理対象外の端末を指します。方向AVPが省略された場合、分類器は、両方向に流れるパケットを照合します。
Value | Name and Semantic
------+--------------------------------------------------
0 | IN - The classifier applies to flows from the
| managed terminal.
1 | OUT - The classifier applies to flows to the
| managed terminal.
2 | BOTH - The classifier applies to flows both to
| and from the managed terminal.
The From-Spec AVP (AVP Code 515) is a grouped AVP that specifies the Source Specification used to match the packet. Zero or more of these AVPs may appear in the classifier. If this AVP is absent from the classifier, then all packets are matched regardless of the source address. If more than one instance of this AVP appears in the classifier, then the source of the packet can match any From-Spec AVP. The contents of this AVP are protocol specific.
スペックAVP（AVPコード515）出典仕様は、パケットを一致させるために使用される指定グループ化AVPです。これらのAVPのゼロ以上の分類器に表示される場合があります。このAVPは、クラシファイアに存在しない場合、すべてのパケットにかかわらず、送信元アドレスの一致しています。このAVPの複数のインスタンスが分類器に表示された場合、パケットの送信元からスペックAVPいずれかに一致することができます。このAVPの内容は、プロトコル固有のものです。
If one instance (or multiple instances) of the IP address AVP (IP-Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) appears in the From-Spec AVP, then the source IP address of the packet MUST match one of the addresses represented by these AVPs.
IPアドレスAVPの1つのインスタンス（または複数のインスタンスが）（IPアドレス、IP-アドレス範囲、IPアドレス、マスク、使用-割り当て-アドレス）から-specの後、送信元IPアドレスAVP、表示された場合パケットは、これらのAVPによって表されるアドレスのいずれかと一致しなければなりません。
If more than one instance of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the From-Spec, then the source layer 2 address of the packet MUST match one of the addresses represented in these AVPs.
層の複数のインスタンス2つのアドレスのAVP（MACアドレス、MACアドレスマスク、EUI64・アドレス、EUI64・アドレス・マスク）からスペックに表示される場合、パケットの送信元レイヤ2アドレスが一致する必要がありますこれらのAVPで表現アドレスのいずれか。
If more than one instance of the port AVPs (Port, Port-Range) appears in the From-Spec AVP, then the source port number MUST match one of the port numbers represented in these AVPs.
ポートのAVP（ポート、ポートの範囲）の複数のインスタンスからスペックAVPに表示されている場合、送信元ポート番号は、これらのAVPで示されたポート番号のいずれかと一致しなければなりません。
If the IP address, MAC address, and port AVPs appear in the same From-Spec AVP, then the source packet MUST match all the specifications, i.e., match the IP address AND MAC address AND port number.
IPアドレス、MACアドレス、およびポートのAVPからスペックAVP同じに表示された場合は、ソースパケットは、すべての仕様に合致しなければならない、すなわち、IPアドレスとMACアドレスとポート番号と一致します。
From-Spec ::= < AVP Header: 515 >
* [ IP-Address ]
* [ IP-Address-Range ]
* [ IP-Address-Mask ]
* [ MAC-Address ]
* [ MAC-Address-Mask]
* [ EUI64-Address ]
* [ EUI64-Address-Mask]
* [ Port ]
* [ Port-Range ]
[ Negated ]
[ Use-Assigned-Address ]
* [ AVP ]
The To-Spec AVP (AVP Code 516) is a grouped AVP that specifies the Destination Specification used to match the packet. Zero or more of these AVPs may appear in the classifier. If this AVP is absent from the classifier, then all packets are matched regardless of the destination address. If more than one instance of this AVP appears in the classifier, then the destination of the packet can match any To-Spec AVP. The contents of this AVP are protocol specific.
TO-スペックAVP（AVPコード516）パケットを一致させるために使用される宛先仕様を指定するグループ化AVPです。これらのAVPのゼロ以上の分類器に表示される場合があります。このAVPがクラシファイアに存在しない場合、すべてのパケットは関係なく、宛先アドレスの一致しています。このAVPの複数のインスタンスが分類器に表示された場合、パケットの送信先は、TO-スペックAVPいずれかに一致することができます。このAVPの内容は、プロトコル固有のものです。
If one instance (or multiple instances) of the IP address AVP (IP-Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address) appears in the To-Spec AVP, then the destination IP address of the packet MUST match one of the addresses represented by these AVPs.
IPアドレスAVPの1つのインスタンス（または複数インスタンス）（IP-アドレスは、IP-アドレス範囲、IPアドレス、マスク、使用-割り当て-アドレス）のTO-スペックAVPは、宛先IPアドレスに表示された場合パケットは、これらのAVPによって表されるアドレスのいずれかと一致しなければなりません。
If more than one instance of the layer 2 address AVPs (MAC-Address, MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the To-Spec, then the destination layer 2 address of the packet MUST match one of the addresses represented in these AVPs.
レイヤ2アドレスのAVP（MACアドレス、MACアドレスマスク、EUI64・アドレス、EUI64・アドレス・マスク）の複数のインスタンスが、仕様に表示される場合、パケットの宛先レイヤ2アドレスが一致する必要がありますこれらのAVPで表現アドレスのいずれか。
If more than one instance of the port AVPs (Port, Port-Range) appears in the To-Spec AVP, then the destination port number MUST match one of the port numbers represented in these AVPs.
ポートのAVP（ポート、ポートの範囲）の複数のインスタンスは、TO-スペックAVPに表示された場合は、宛先ポート番号は、これらのAVPで示されたポート番号のいずれかと一致しなければなりません。
If the IP address, MAC address, and port AVPs appear in the same To-Spec AVP, then the destination packet MUST match all the specifications, i.e., match the IP address AND MAC address AND port number.
IPアドレス、MACアドレス、およびポートのAVPは、TO-スペックAVP同じに表示された場合は、先のパケットはすべての仕様に合致しなければならない、すなわち、IPアドレスとMACアドレスとポート番号と一致します。
To-Spec ::= < AVP Header: 516 >
* [ IP-Address ]
* [ IP-Address-Range ]
* [ IP-Address-Mask ]
* [ MAC-Address ]
* [ MAC-Address-Mask]
* [ EUI64-Address ]
* [ EUI64-Address-Mask]
* [ Port ]
* [ Port-Range ]
[ Negated ]
[ Use-Assigned-Address ]
* [ AVP ]
For packet classification, the contents of the From-Spec and To-Spec can contain the AVPs listed in the subsections below.
パケット分類のために、from-specおよびto-specの内容は以下のサブセクションに記載されているAVPを含めることができます。
The Negated AVP (AVP Code 517) is of type Enumerated containing the values of True or False. Exactly zero or one of these AVPs may appear in the From-Spec or To-Spec AVP.
否定AVP（AVPコード517）は、TrueまたはFalseの値を含む列挙型です。正確にゼロまたはこれらのAVPの一つは仕様-からまたはTO-スペックAVPに表示される場合があります。
When set to True, the meaning of the match is inverted and the classifier will match addresses other than those specified by the From-Spec or To-Spec AVP. When set to False, or when the Negated AVP is not present, the classifier will match the addresses specified by the From-Spec or To-Spec AVP.
Trueに設定すると、マッチの意味が反転し、分類器は、仕様-からまたはTO-スペックAVPで指定された以外のアドレスと一致します。 Falseに設定した場合、または否定AVPが存在しない場合、分類器は、仕様-からまたはTO-スペックAVPで指定されたアドレスと一致します。
Note that the negation does not impact the port comparisons.
否定はポートの比較に影響を与えないことに注意してください。
Value | Name
------+--------
0 | False
1 | True
The IP-Address AVP (AVP Code 518) is of type Address and specifies a single IP address (IPv4 or IPv6) to match.
IPアドレスAVP（AVPコード518）が型アドレスと一致するように、単一のIPアドレス（IPv4またはIPv6）を指定します。
The IP-Address-Range AVP (AVP Code 519) is of type Grouped and specifies an inclusive IP address range.
IP-アドレス範囲AVP（AVPコード519）は、タイプグループ化であり、包括的なIPアドレスの範囲を指定します。
IP-Address-Range ::= < AVP Header: 519 >
[ IP-Address-Start ]
[ IP-Address-End ]
* [ AVP ]
If the IP-Address-Start AVP is not included, then the address range starts from the first valid IP address up to and including the specified IP-Address-End address.
IP-アドレススタートAVPが含まれていない場合は、アドレス範囲が最初に有効なIPアドレスから起動し、指定したIPアドレス、終了アドレスを含みます。
If the IP-Address-End AVP is not included, then the address range starts at the address specified by the IP-Address-Start AVP and includes all the remaining valid IP addresses.
IP-アドレスエンドAVPが含まれていない場合は、アドレス範囲がIP-アドレススタートAVPで指定されたアドレスから始まり、残りのすべての有効なIPアドレスが含まれています。
For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP MUST contain a value that is less than that of the IP-Address-End AVP.
IP-アドレス範囲AVPが有効であるために、IP-アドレススタートAVPは、IP-アドレスエンドAVPのそれよりも低い値を含まなければなりません。
The IP-Address-Start AVP (AVP Code 520) is of type Address and specifies the first IP address (IPv4 or IPv6) of an IP address range.
IPアドレススタートAVP（AVPコード520）タイプアドレスであり、IPアドレス範囲の最初のIPアドレス（IPv4またはIPv6）を指定します。
The IP-Address-End AVP (AVP Code 521) is of type Address and specifies the last IP address (IPv4 or IPv6) of an address range.
IP-アドレスエンドAVP（AVPコード521）は、タイプアドレスであり、アドレス範囲の最後のIPアドレス（IPv4またはIPv6）を指定します。
The IP-Address-Mask AVP (AVP Code 522) is of type Grouped and specifies an IP address range using a base IP address and the bit-width of the mask. For example, a range expressed as 192.0.2.0/24 will match all IP addresses from 192.0.2.0 up to and including 192.0.2.255. The bit-width MUST be valid for the type of IP address.
IPアドレスマスクAVP（AVPコード522）タイプグループ化であり、ベースIPアドレスとマスクのビット幅を使用してIPアドレスの範囲を指定します。 192.0.2.0/24が192.0.2.255などに、最大192.0.2.0からのすべてのIPアドレスが一致するように、例えば、範囲が発現しました。ビット幅は、IPアドレスのタイプに対して有効である必要があります。
IP-Address-Mask ::= < AVP Header: 522 >
{ IP-Address }
{ IP-Bit-Mask-Width }
* [ AVP ]
The IP-Bit-Mask-Width AVP (AVP Code 523) is of type Unsigned32. The value specifies the width of an IP address bit mask.
IP-ビットマスク幅AVP（AVPコード523）はタイプUnsigned32にあります。値は、IPアドレスのビットマスクの幅を指定します。
The MAC-Address AVP (AVP Code 524) is of type OctetString and specifies a single layer 2 address in MAC-48 format. The value is a 6-octet encoding of the address as it would appear in the frame header.
MACアドレスAVP（AVPコード524）はタイプOctetStringにあり、MAC-48フォーマットでシングルレイヤ2アドレスを指定します。それはフレームヘッダに表示されるように値がアドレスの6オクテットの符号化です。
The MAC-Address-Mask AVP (AVP Code 525) is of type Grouped and specifies a set of MAC addresses using a bit mask to indicate the bits of the MAC addresses that must fit to the specified MAC address attribute. For example, a MAC-Address-Mask with the MAC-Address as 00-10-A4-23-00-00 and with a MAC-Address-Mask-Pattern of FF-FF-FF-FF-00-00 will match all MAC addresses from 00-10-A4-23-00-00 up to and including 00-10-A4-23-FF-FF.
MACアドレスマスクAVP（AVPコード525）タイプグループ化であり、指定されたMACアドレス属性に適合しなければならないMACアドレスのビットを示すために、ビットマスクを使用してMACアドレスのセットを指定します。 00-10-A4-23-00-00として及びFF-FF-FF-FF-00-00のMACアドレスマスクパターンが一致するとMACアドレスと、例えば、MACアドレスマスク00-10-A4-23-00-00からすべてのMACアドレスまでと00-10-A4-23-FF-FFを含みます。
Appendix A describes the considerations that should be given to the use of MAC address masks in constructing classifiers.
付録Aは、分類器を構築する上でMACアドレスマスクの使用に与えられるべきである考慮事項について説明します。
MAC-Address-Mask ::= < AVP Header: 525 >
{ MAC-Address }
{ MAC-Address-Mask-Pattern }
* [ AVP ]
The MAC-Address-Mask-Pattern AVP (AVP Code 526) is of type OctetString. The value is 6 octets specifying the bit positions of a MAC address that are taken for matching.
MACアドレスマスクパターンAVP（AVPコード526）はタイプOctetStringにあります。値は、マッチングのために採取されたMACアドレスのビット位置を指定する6つのオクテットです。
The EUI64-Address AVP (AVP Code 527) is of type OctetString and specifies a single layer 2 address in EUI-64 format. The value is an 8-octet encoding of the address as it would appear in the frame header.
EUI64アドレスAVP（AVPコード527）はタイプOctetStringにあり、EUI64フォーマットで単一レイヤ2アドレスを指定します。それはフレームヘッダに表示されるように値がアドレスの8オクテット符号化です。
The EUI64-Address-Mask AVP (AVP Code 528) is of type Grouped and specifies a set of EUI64 addresses using a bit mask to indicate the bits of the EUI64 addresses that must fit to the specified EUI64 address attribute. For example, a EUI64-Address-Mask with the EUI64- Address as 00-10-A4-FF-FE-23-00-00 and with a EUI64-Address-Mask-Pattern of FF-FF-FF-FF-FF-FF-00-00 will match all EUI64 addresses from 00-10-A4-FF-FE-23-00-00 up to and including 00-10-A4-FF-FE-23- FF-FF.
EUI64-アドレスマスクAVP（AVPコード528）タイプグループ化であり、指定されたEUI64アドレス属性に適合しなければならないEUI64アドレスのビットを示すために、ビットマスクを使用してEUI64アドレスのセットを指定します。例えば、00-10-A4-FF-FE-23-00-00等のFF-FF-FF-FF-FFのEUI64・アドレス・マスクパターンを有するEUI64-アドレスでEUI64・アドレス・マスク-FF-00-00は、最大00-10-A4-FF-FE-23-00-00からすべてのEUI64アドレスと一致し、00-10-A4-FF-FE-23- FF-FFを含めます。
Appendix A describes the considerations that should be given to the use of EUI64 address masks in constructing classifiers.
付録Aは、分類器を構築中EUI64アドレスマスクの使用に与えられるべきである考慮事項について説明します。
EUI64-Address-Mask ::= < AVP Header: 528 >
{ EUI64-Address }
{ EUI64-Address-Mask-Pattern }
* [ AVP ]
The EUI64-Address-Mask-Pattern AVP (AVP Code 529) is of type OctetString. The value is 8 octets specifying the bit positions of a EUI64 address that are taken for matching.
EUI64・住所・マスクパターンAVP（AVPコード529）はタイプOctetStringにあります。値は、マッチングのために取られるEUI64アドレスのビット位置を指定する8つのオクテットです。
The Port AVP (AVP Code 530) is of type Integer32 in the range of 0 to 65535 and specifies port numbers to match. The type of port is indicated by the value of the Protocol AVP; i.e., if Protocol AVP value is 6 (TCP), then the Port AVP represents a TCP port.
ポートAVP（AVPコード530）は、0〜65535の範囲でタイプInteger32のであり、一致するポート番号を指定します。ポートのタイプは、プロトコルAVPの値によって示されます。プロトコルAVP値が6（TCP）である場合、すなわち、ポートAVPは、TCPポートを表します。
The Port-Range AVP (AVP Code 531) is of type Grouped and specifies an inclusive range of ports. The type of the ports is indicated by the value of the Protocol AVP; i.e., if Protocol AVP value is 6 (TCP), then the Port-Range AVP represents an inclusive range of TCP ports.
ポート範囲AVP（AVPコード531）は、タイプのグループ化であり、ポートの包括的な範囲を指定します。ポートのタイプは、プロトコルAVPの値によって示されます。プロトコルAVP値が6（TCP）である場合、すなわち、ポートレンジAVPは、TCPポートを含む範囲を表します。
Port-Range ::= < AVP Header: 531 >
[ Port-Start ]
[ Port-End ]
* [ AVP ]
If the Port-Start AVP is omitted, then port 0 is assumed. If the Port-End AVP is omitted, then port 65535 is assumed.
ポートスタートAVPが省略されている場合は、ポート0が想定されます。ポートエンドAVPが省略されている場合は、ポート65535が想定されます。
The Port-Start AVP (AVP Code 532) is of type Integer32 and specifies the first port number of an IP port range.
ポートスタートAVP（AVPコード532）が型Integer32のであり、IPポート範囲の最初のポート番号を指定します。
The Port-End AVP (AVP Code 533) is of type Integer32 and specifies the last port number of an IP port range.
ポートエンドAVP（AVPコード533）はタイプ構文Integer32のものであり、IPのポート範囲の最後のポート番号を指定します。
In some scenarios, the AAA does not know the IP address assigned to the managed terminal at the time that the classifier is sent to the Classifying Entity. The Use-Assigned-Address AVP (AVP Code 534) is of type Enumerated containing the values of True or False. When present and set to True, it represents the IP address assigned to the managed terminal.
いくつかのシナリオでは、AAAは、分類器は、分類エンティティに送信された時点で管理端末に割り当てられたIPアドレスを知りません。ユース割り当てられたアドレスAVP（AVPコード534）は、TrueまたはFalseの値を含む列挙型です。存在し、Trueに設定すると、それは、管理端末に割り当てられたIPアドレスを表します。
Value | Name
------+--------
0 | False
1 | True
The Classifier AVP may contain one or more of the following AVPs to match on the various possible IP, TCP, or ICMP header options.
分類AVPは、様々な可能なIP、TCP、またはICMPヘッダオプションに一致する次のAVPの一つ以上を含んでいてもよいです。
The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and specifies the Differentiated Services Field Codepoints to match in the IP header. The values are managed by IANA under the Differentiated Services Field Codepoints registry as defined in [RFC2474].
Diffservの-コードポイントAVP（AVPコード535）がタイプ列挙であり、差別化サービスコードポイントフィールドは、IPヘッダに一致するように指定します。 [RFC2474]で定義された値は、差別化サービスフィールドコードポイントレジストリの下でIANAによって管理されています。
The Fragmentation-Flag AVP (AVP Code 536) is of type Enumerated and specifies the packet fragmentation flags to match in the IP header.
断片化フラッグAVP（AVPコード536）がタイプ列挙であり、IPヘッダに一致するパケットの断片化フラグを指定します。
Value | Name and Semantic
------+------------------------------------------------------------
0 | Don't Fragment (DF)
1 | More Fragments (MF)
The IP-Option AVP (AVP Code 537) is of type Grouped and specifies an IP header option that must be matched.
IP-オプションAVP（AVPコード537）がグループ化タイプであり、一致しなければならないIPヘッダオプションを指定します。
IP-Option ::= < AVP Header: 537 >
{ IP-Option-Type }
* [ IP-Option-Value ]
[ Negated ]
* [ AVP ]
If one or more IP-Option-Value AVPs are present, one of the values MUST match the value in the IP header option. If the IP-Option-Value AVP is absent, the option type MUST be present in the IP header but the value is wild carded.
1つ以上のIP-オプション - 値のAVPが存在する場合、のいずれかの値は、IPヘッダオプションの値と一致しなければなりません。 IP-オプション価値AVPが存在しない場合、オプションタイプは、IPヘッダ内に存在していなければなりませんが、値は、カーディング野生あります。
The Negated AVP is used in conjunction with the IP-Option-Value AVPs to specify IP header options that do not match specific values. The Negated AVP is used without the IP-Option-Value AVP to specify IP headers that do not contain the option type.
否定AVPは、特定の値と一致しないIPヘッダオプションを指定するためにIP-オプション - 値のAVPと共に使用されます。否定AVPは、オプションの種類が含まれていないIPヘッダを指定するには、IP-オプション価値のAVPなしで使用されています。
The IP-Option-Type AVP (AVP Code 538) is of type Enumerated and the values are managed by IANA under the IP Option Numbers registry as defined in [RFC2780].
IP-オプションタイプAVP（AVPコード538）がタイプ列挙であり、[RFC2780]で定義されるような値は、IPオプション番号レジストリの下でIANAによって管理されています。
The IP-Option-Value AVP (AVP Code 539) is of type OctetString and contains the option value that must be matched.
IP-OptionキーバリューAVP（AVPコード539）はタイプOctetStringにあると一致しなければならないオプション値が含まれています。
The TCP-Option AVP (AVP Code 540) is of type Grouped and specifies a TCP header option that must be matched.
TCP-オプションAVP（AVPコード540）は、タイプのグループ化であり、一致しなければならないTCPヘッダーオプションを指定します。
TCP-Option ::= < AVP Header: 540 >
{ TCP-Option-Type }
* [ TCP-Option-Value ]
[ Negated ]
* [ AVP ]
If one or more TCP-Option-Value AVPs are present, one of the values MUST match the value in the TCP header option. If the TCP-Option-Value AVP is absent, the option type MUST be present in the TCP header but the value is wild carded.
一つ以上のTCP-オプション - 値のAVPが存在する場合、のいずれかの値は、TCPヘッダオプションの値と一致しなければなりません。 TCP-オプション価値AVPが存在しない場合、オプションタイプは、TCPヘッダに存在していなければなりませんが、値は、野生はカーディングされます。
The Negated AVP is used in conjunction that the TCP-Option-Value AVPs to specify TCP header options that do not match specific values. The Negated AVP is used without the TCP-Option-Value AVP to specify TCP headers that do not contain the option type.
否定AVPは、TCPオプション - 値のAVPが特定値と一致しないTCPヘッダーオプションを指定することに関連して使用されます。否定AVPは、オプションの種類が含まれていないTCPヘッダを指定するには、TCP-オプション価値のAVPなしで使用されています。
The TCP-Option-Type AVP (AVP Code 541) is of type Enumerated and the values are managed by IANA under the TCP Option Numbers registry as defined in [RFC2780].
TCP-オプションタイプAVP（AVPコード541）がタイプ列挙であり、[RFC2780]で定義されるような値は、TCPオプション番号レジストリ下でIANAによって管理されています。
The TCP-Option-Value AVP (AVP Code 542) is of type OctetString and contains the option value that must be matched.
TCP-OptionキーバリューAVP（AVPコード542）はタイプOctetStringにあると一致しなければならないオプション値が含まれています。
The TCP-Flags AVP (AVP Code 543) is of type Grouped and specifies a set of TCP control flags that must be matched.
TCP-フラグAVP（AVPコード543）は、タイプのグループ化であり、一致しなければならないTCP制御フラグのセットを指定します。
TCP-Flags ::= < AVP Header: 543 >
{ TCP-Flag-Type }
[ Negated ]
* [ AVP ]
If the Negated AVP is not present or present but set to False, the TCP-Flag-Type AVP specifies which flags MUST be set. If the Negated AVP is set to True, the TCP-Flag-Type AVP specifies which flags MUST be cleared.
否定AVPは存在か存在するが、フラグを設定しなければならない偽、TCP-FLAG-Type AVPの指定に設定されていない場合。否定AVPがTrueに設定されている場合は、TCP-FLAG-タイプAVPはクリアされなければならないフラグを指定します。
The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and specifies the TCP control flag types that must be matched. The first 16 bits match the TCP header format defined in [RFC3168], and the subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 are unused and bits 4 to 15 are managed by IANA under the TCP Header Flag registry as defined in [RFC3168].
TCP-FLAG-タイプAVP（AVPコード544）はタイプUnsigned32にあり、一致しなければならないTCPコントロールフラグタイプを指定します。最初の16ビットは、[RFC3168]で定義されたTCPヘッダのフォーマットに一致し、それに続く16ビットは未使用です。最初の16ビット以内、3ビット0は未使用であり、[RFC3168]で定義されるように15ビット4は、TCPヘッダフラグレジストリ下でIANAによって管理されています。
The ICMP-Type AVP (AVP Code 545) is of type Grouped and specifies an ICMP message type that must be matched.
ICMPタイプAVP（AVPコード545）がグループ化タイプであり、一致しなければならないICMPメッセージタイプを指定します。
ICMP-Type ::= < AVP Header: 545 >
{ ICMP-Type-Number }
* [ ICMP-Code ]
[ Negated ]
* [ AVP ]
If the ICMP-Code AVP is present, the value MUST match that in the ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be present in the ICMP header but the code is wild carded.
ICMP-コードAVPが存在する場合、値は、ICMPヘッダ内のものと一致しなければなりません。 ICMP-コードAVPが存在しない場合、ICMPタイプは、ICMPヘッダ内に存在していなければなりませんが、コードは、野生はカーディングされます。
The Negated AVP is used in conjunction with the ICMP-Code AVPs to specify ICMP codes that do not match specific values. The Negated AVP is used without the ICMP-Code AVP to specify ICMP headers that do not contain the ICMP type. As such, the Negated AVP feature applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP-Type-Number.
否定AVPは、特定の値と一致しないICMPコードを指定するには、ICMP-コードのAVPと組み合わせて使用されます。否定AVPは、ICMPタイプが含まれていないICMPヘッダを指定するには、ICMPコードAVPなしで使用されています。 ICMP-コードAVPが存在している場合はそのように、否定AVP機能は、ICMP-コードAVPに適用されます。 ICMP-コードAVPが存在しない場合は、否定AVP機能は、ICMP-タイプ番号に適用されます。
The ICMP-Type-Number AVP (AVP Code 546) is of type Enumerated and the values are managed by IANA under the ICMP Type Numbers registry as defined in [RFC2780].
ICMP-タイプ番号AVP（AVPコード546）がタイプ列挙であり、[RFC2780]で定義されるような値は、ICMPタイプ番号レジストリの下でIANAによって管理されています。
The ICMP-Code AVP (AVP Code 547) is of type Enumerated and the values are managed by IANA under the ICMP Type Numbers registry as defined in [RFC2780].
ICMP-コードAVP（AVPコード547）がタイプ列挙であり、[RFC2780]で定義されるような値は、ICMPタイプ番号レジストリの下でIANAによって管理されています。
The ETH-Option AVP (AVP Code 548) is of type Grouped and specifies Ethernet specific attributes.
ETH-オプションAVP（AVPコード548）がグループ化されたタイプのものであり、イーサネットの特定の属性を指定します。
ETH-Option ::= < AVP Header: 548 >
{ ETH-Proto-Type }
* [ VLAN-ID-Range ]
* [ User-Priority-Range ]
* [ AVP ]
The Eth-Proto-Type AVP (AVP Code 549) is of type Grouped and specifies the encapsulated protocol type. ETH-Ether-Type and ETH-SAP are mutually exclusive.
ETH-プロトタイプAVP（AVPコード549）がグループ化タイプのものであり、カプセル化されたプロトコルタイプを指定します。 ETH-エーテル系およびETH-SAPは、相互に排他的です。
ETH-Proto-Type ::= < AVP Header: 549 >
* [ ETH-Ether-Type ]
* [ ETH-SAP ]
* [ AVP ]
The ETH-Ether-Type AVP (AVP Code 550) is of type OctetString. The value is a double octet that contains the value of the Ethertype field in the packet to match. This AVP MAY be present in the case of Digital, Intel, and Xerox (DIX) or if the Subnetwork Access Protocol (SNAP) is present at 802.2, but the ETH-SAP AVP MUST NOT be present in this case.
ETH-エーテル系AVP（AVPコード550）はタイプOctetStringにあります。値が一致するように、パケット内のEthertypeフィールドの値を含むダブルオクテットです。このAVPは、デジタル、インテル、およびゼロックス（DIX）の場合に存在してもよく、またはサブネットワークアクセスプロトコル（SNAP）は802.2で存在するが、ETH-SAP AVPは、このケースで存在してはならない場合。
The ETH-SAP AVP (AVP Code 551) is of type OctetString. The value is a double octet representing the 802.2 SAP as specified in [IEEE802.2]. The first octet contains the Destination Service Access Point (DSAP) and the second the Source Service Access Point (SSAP).
ETH-SAP AVP（AVPコード551）はタイプOctetStringにあります。値は、[IEEE802.2]で指定されるよう802.2 SAPを表す二重オクテットです。最初のオクテットは、送信先サービスアクセスポイント（DSAP）と第二ソースサービスアクセスポイント（SSAP）が含まれています。
The VLAN-ID-Range AVP (AVP Code 552) is of type Grouped and specifies the VLAN range to match. VLAN identities are specified either by a single VLAN-ID according to [IEEE802.1Q] or by a combination of Customer and Service VLAN-IDs according to [IEEE802.1ad].
VLAN-ID-範囲AVP（AVPコード552）がグループ化タイプのものであり、一致するVLANの範囲を指定します。 VLAN IDが[IEEE802.1Q]に、または[IEEE802.1ad]に記載のカスタマー・サービスVLAN-IDの組み合わせによって記載単一VLAN-IDのいずれかによって指定されています。
The single VLAN-ID is represented by the C-VID-Start and C-VID-End AVPs, and the S-VID-Start and S-VID-End AVPs SHALL be omitted in this case. If the VLAN-ID-Range AVP is omitted from the classifier, then comparison of the VLAN identity of the packet is irrelevant.
単一のVLAN-IDは、C-VIDスタートおよびC-VIDエンドのAVPで表され、S-VIDスタートおよびS-VIDエンドのAVPは、この場合には省略する。 VLAN-ID-範囲AVPは、分類器から省略されている場合は、パケットのVLANアイデンティティの比較は無関係です。
VLAN-ID-Range ::= < AVP Header: 552 >
[ S-VID-Start ]
[ S-VID-End ]
[ C-VID-Start ]
[ C-VID-End ]
* [ AVP ]
The following is the list of possible combinations of the S-VID-Start and S-VID-End AVPs and their inference:
S-VID-StartとS-VID-エンドのAVPとその推論の可能な組み合わせの一覧を以下に示します。
o If S-VID-Start AVP is present but the S-VID-End AVP is absent, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits specified in [IEEE802.1ad] for a successful match.
O S-VIDスタートAVPが存在しているが、S-VIDエンドAVPが存在しない場合、S-VIDスタートAVP値は[IEEE802.1ad]のために指定されたIEEE 802.1ad S-VIDビットの値が等しくなければなりません成功した試合。
o If S-VID-Start AVP is absent but the S-VID-End AVP is present, the S-VID-End AVP value MUST equal the value of the IEEE 802.1ad S-VID bits for a successful match.
O場合S-VIDスタートAVPは存在しないが、S-VIDエンドAVPが存在している、S-VIDエンドAVPの値は、成功したマッチのためにIEEE 802.1ad S-VIDビットの値が等しくなければなりません。
o If both S-VID-Start and S-VID-End AVPs are present and their values are equal, the S-VID-Start AVP value MUST equal the value of the IEEE 802.1ad S-VID bits for a successful match.
O両方が場合S-VIDスタートおよびS-VIDエンドのAVPが存在し、それらの値が等しい、S-VIDスタートAVPの値は、成功したマッチのためにIEEE 802.1ad S-VIDビットの値が等しくなければなりません。
o If both S-VID-Start and S-VID-End AVPs are present and the value of S-VID-End AVP is greater than the value of the S-VID-Start AVP, the value of the IEEE 802.1ad S-VID bits MUST be greater than or equal to the S-VID-Start AVP value and less than or equal to the S-VID-End AVP value for a successful match. If the S-VID-Start and S-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad encapsulation MUST NOT match this classifier.
O S-VIDスタートおよびS-VID-両端のAVPが存在し、S-VIDエンドAVPは、S-VIDスタートAVP、IEEEの802.1adの値の値よりも大きい値の場合にはS- VIDビットが成功したマッチのためにS-VIDエンドAVP値以上S-VIDスタートAVPの値に等しく、以下でなければなりません。 S-VID-StartとS-VID-エンドのAVPが指定されている場合は、IEEE 802.1adのカプセル化なしのイーサネットパケットは、この分類器を一致させることはできません。
o If the S-VID-Start and S-VID-End AVPs are omitted, then existence of IEEE802.1ad encapsulation or comparison of the IEEE 802.1ad S-VID bits is irrelevant for this classifier.
S-VIDスタートおよびS-VIDエンドのAVPを省略した場合、Oは、IEEE 802.1ad S-VIDビットのIEEE802.1adカプセル化または比較の存在は、この分類器は無関係です。
The following is the list of possible combinations of the C-VID-Start and C-VID-End AVPs and their inference: o If C-VID-Start AVP is present but the C-VID-End AVP is absent, the C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad C-VID bits specified in [IEEE802.1ad] or the IEEE 802.1Q VLAN-ID bits specified in [IEEE802.1Q] for a successful match.
C-VID-スタートAVPが存在しているが、C-VID-エンドAVPが存在しない場合はO、C-：C-VID-StartおよびC-VID-エンドのAVPとその推論の可能な組み合わせのリストです。 VIDスタートAVP値は[IEEE802.1ad]または成功したマッチのために[IEEE802.1Q]で指定されたIEEE 802.1Q VLAN-IDのビットで指定されたIEEE 802.1ad C-VIDビットの値が等しくなければなりません。
o If C-VID-Start AVP is absent but the C-VID-End AVP is present, the C-VID-End AVP value MUST equal the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for a successful match.
O C-VIDスタートAVPは存在しないが、C-VIDエンドAVPが存在し、C-VIDエンドAVPの値は、IEEE 802.1ad C-VIDビットまたはIEEE 802.1Q VLAN-IDの値に等しくなければならない場合マッチが成功のためのビット。
o If both C-VID-Start and C-VID-End AVPs are present and their values are equal, the C-VID-Start AVP value MUST equal the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits for a successful match.
O C-VIDスタートおよびC-VIDエンドのAVPの両方が存在し、それらの値が等しい、C-VIDスタートAVPの値は、IEEE 802.1ad C-VIDビットまたはIEEE 802.1Q VLANの値に等しくなければならない場合成功したマッチのため-IDビット。
o If both C-VID-Start and C-VID-End AVPs are present and the value of C-VID-End AVP is greater than the value of the C-VID-Start AVP, the value of the IEEE 802.1ad C-VID bits or the IEEE 802.1Q VLAN-ID bits MUST be greater than or equal to the C-VID-Start AVP value and less than or equal to the C-VID-End AVP value for a successful match. If the C-VID-Start and C-VID-End AVPs are specified, then Ethernet packets without IEEE 802.1ad or IEEE 802.1Q encapsulation MUST NOT match this classifier.
O C-VID-Startとの両方のC-VIDエンドのAVPが存在し、C-VIDエンドAVPの値はC-VIDスタートAVP、IEEEの802.1adの値の値よりも大きい場合にはC- VIDビットまたはIEEE 802.1Q VLAN-IDのビットは、成功したマッチのためにC-VIDエンドAVP値以上のC-VIDスタートAVPの値よりも小さいか等しくなければなりません。 C-VID-StartおよびC-VID-エンドのAVPが指定されている場合は、IEEE 802.1adのか、IEEE 802.1Qカプセル化なしのイーサネットパケットは、この分類器を一致させることはできません。
o If the C-VID-Start and C-VID-End AVPs are omitted, the comparison of the IEEE 802.1ad C-VID bits or IEEE 802.1Q VLAN-ID bits for this classifier is irrelevant.
C-VIDスタートおよびC-VIDエンドのAVPを省略している場合は、O、この分類器のためのIEEE 802.1ad C-VIDビットまたはIEEE 802.1Q VLAN-IDのビットの比較は無関係です。
The S-VID-Start AVP (AVP Code 553) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the start value of the range of S-VID VLAN-IDs to be matched.
S-VIDスタートAVP（AVPコード553）はタイプUnsigned32にあります。値は0から4095の範囲でなければなりません。このAVPの値が一致するS-VID VLAN-IDの範囲の開始値を指定します。
The S-VID-End AVP (AVP Code 554) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the end value of the range of S-VID VLAN-IDs to be matched.
S-VIDエンドAVP（AVPコード554）はタイプUnsigned32にあります。値は0から4095の範囲でなければなりません。このAVPの値が一致するS-VID VLAN-IDの範囲の終了値を指定します。
The C-VID-Start AVP (AVP Code 555) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the start value of the range of C-VID VLAN-IDs to be matched.
C-VIDスタートAVP（AVPコード555）はタイプUnsigned32にあります。値は0から4095の範囲でなければなりません。このAVPの値が一致するC-VID VLAN-IDの範囲の開始値を指定します。
The C-VID-End AVP (AVP Code 556) is of type Unsigned32. The value MUST be in the range from 0 to 4095. The value of this AVP specifies the end value of the range of C-VID VLAN-IDs to be matched.
C-VIDエンドAVP（AVPコード556）はタイプUnsigned32にあります。値は0から4095の範囲でなければなりません。このAVPの値が一致するC-VID VLAN-IDの範囲の終了値を指定します。
The User-Priority-Range AVP (AVP Code 557) is of type Grouped and specifies an inclusive range to match the user_priority parameter specified in [IEEE802.1D]. An Ethernet packet containing the user_priority parameter matches this classifier if the value is greater than or equal to Low-User-Priority and less than or equal to High-User-Priority. If this AVP is omitted, then comparison of the IEEE 802.1D user_priority parameter for this classifier is irrelevant.
ユーザプライオリティレンジAVP（AVPコード557）がグループ化タイプであり、[IEEE802.1D]で指定user_priorityパラメータと一致するように包含範囲を指定します。値が高ユーザー優先度よりも大きいかまたは低ユーザ優先度に等しく、以下の場合user_priorityパラメータを含むイーサネットパケットは、この分類子と一致します。このAVPが省略された場合、この分類器のためのIEEE 802.1Dのuser_priorityパラメータの比較は無関係です。
User-Priority-Range ::= < AVP Header: 557 >
* [ Low-User-Priority ]
* [ High-User-Priority ]
* [ AVP ]
The Low-User-Priority AVP (AVP Code 558) is of type Unsigned32. The value MUST be in the range from 0 to 7.
低ユーザープライオリティAVP（AVPコード558）はタイプUnsigned32にあります。値は0から7の範囲でなければなりません。
The High-User-Priority AVP (AVP Code 559) is of type Unsigned32. The value MUST be in the range from 0 to 7.
高ユーザプライオリティAVP（AVPコード559）はタイプUnsigned32にあります。値は0から7の範囲でなければなりません。
In many QoS applications, the QoS specification applied to the traffic flow is conditional upon the time of day when the flow was observed. The following sections define AVPs that can be used to express one or more time windows that determine when a traffic treatment action is applicable to a traffic flow.
多くのQoSアプリケーションでは、トラフィックフローに適用されたQoS仕様は、フローが観測された日の時間に条件付きです。以下のセクションでは、トラフィック処理アクションがトラフィックフローに適用可能であるときを決定する1つまたは複数の時間窓を発現するために使用することができるAVPを定義します。
The Time-Of-Day-Condition AVP (AVP Code 560) is of type Grouped and specifies one or more time windows.
時刻：コンディションAVP（AVPコード560）は、タイプグループ化であり、一つ以上の時間ウィンドウを指定します。
Time-Of-Day-Condition ::= < AVP Header: 560 >
[ Time-Of-Day-Start ]
[ Time-Of-Day-End ]
[ Day-Of-Week-Mask ]
[ Day-Of-Month-Mask ]
[ Month-Of-Year-Mask ]
[ Absolute-Start-Time ]
[ Absolute-End-Time ]
[ Timezone-Flag ]
* [ AVP ]
For example, a time window for 9 a.m. to 5 p.m. (local time) from Monday to Friday would be expressed as:
午後5時〜9午前については、例えば、時間ウィンドウ月曜日から金曜日まで（現地時間）のように表すことになります。
Time-Of-Day-Condition = {
Time-Of-Day-Start = 32400;
Time-Of-Day-End = 61200;
Day-Of-Week-Mask =
( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY );
Timezone-Flag = LOCAL;
}
The Time-Of-Day-Start AVP (AVP Code 561) is of type Unsigned32. The value MUST be in the range from 0 to 86400. The value of this AVP specifies the start of an inclusive time window expressed as the offset in seconds from midnight. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts at midnight.
時刻スタートAVP（AVPコード561）はタイプUnsigned32にあります。値は0から86400までの範囲で、このAVPの値でなければなりません真夜中からの秒数でのオフセットとして表さ包括時間窓の開始を指定します。このAVPは、時刻-条件AVPに存在しない場合は、時間ウィンドウは深夜に始まります。
The Time-Of-Day-End AVP (AVP Code 562) is of type Unsigned32. The value MUST be in the range from 1 to 86400. The value of this AVP specifies the end of an inclusive time window expressed as the offset in seconds from midnight. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window ends one second before midnight.
時刻エンドAVP（AVPコード562）はタイプUnsigned32にあります。値は、このAVPの値は、真夜中から秒単位でのオフセットとして表さ包括時間ウィンドウの終わりを指定する1から86400の範囲になければなりません。このAVPは、時刻-条件AVPに存在しない場合は、時間ウィンドウは、真夜中の前に1秒を終了します。
The Day-Of-Week-Mask AVP (AVP Code 563) is of type Unsigned32. The value is a bit mask that specifies the day of the week for the time window to match. This document specifies the following bits:
曜日・マスクAVP（AVPコード563）はタイプUnsigned32にあります。値が一致するように、時間ウィンドウの曜日を指定するビットマスクです。このドキュメントでは、次のビットを指定します。
Bit | Name
------+------------
0 | SUNDAY
1 | MONDAY
2 | TUESDAY
3 | WEDNESDAY
4 | THURSDAY
5 | FRIDAY
6 | SATURDAY
The bit MUST be set for the time window to match on the corresponding day of the week. Bit 0 is the least significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows match on all days of the week.
ビットは、対応する曜日に合わせて、時間ウィンドウのために設定しなければなりません。ビット0が最下位ビットと未使用のビットをクリアしなければなりませんです。このAVPは週のすべての曜日に時刻-条件AVP、時間ウィンドウの試合から存在しない場合。
The Day-Of-Month AVP (AVP Code 564) is of type Unsigned32. The value MUST be in the range from 0 to 2147483647. The value is a bit mask that specifies the days of the month where bit 0 represents the first day of the month through to bit 30, which represents the last day of the month. The bit MUST be set for the time window to match on the corresponding day of the month. Bit 0 is the least significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows match on all days of the month.
デイ・オブ・月AVP（AVPコード564）はタイプUnsigned32にあります。値は、値はビット0月の最終日を表すビット30に至る月の最初の日を表す月の日を指定するビットマスクであり、0から2147483647までの範囲になければなりません。ビットは、月の該当日に合わせて、時間ウィンドウのために設定しなければなりません。ビット0が最下位ビットと未使用のビットをクリアしなければなりませんです。このAVPは時刻-条件AVP、月のすべての日の時間窓の試合に存在しない場合。
The Month-Of-Year-Mask AVP (AVP Code 565) is of type Unsigned32. The value is a bit mask that specifies the months of the year for the time window to match. This document specifies the following bits:
月・オブ・イヤー・マスクAVP（AVPコード565）はタイプUnsigned32にあります。値が一致するように、時間ウィンドウのための年の月を指定するビットマスクです。このドキュメントでは、次のビットを指定します。
Bit | Name
------+-----------
0 | JANUARY
1 | FEBRUARY
2 | MARCH
3 | APRIL
4 | MAY
5 | JUNE
6 | JULY
7 | AUGUST
8 | SEPTEMBER
9 | OCTOBER
10 | NOVEMBER
11 | DECEMBER
The bit MUST be set for the time window to match on the corresponding month of the year. Bit 0 is the least significant bit and unused bits MUST be cleared. If this AVP is absent from the Time-Of-Day-Condition AVP, the time windows match during all months of the year.
時間ウィンドウは、今年の該当月に一致させるためにビットを設定しなければなりません。ビット0が最下位ビットと未使用のビットをクリアしなければなりませんです。このAVPは、今年のすべての月の間の時刻-条件AVP、時間ウィンドウの試合から存在しない場合。
The Absolute-Start-Time AVP (AVP Code 566) is of type Time. The value of this AVP specifies the time in seconds since January 1, 1900, 00:00 UTC when the time window starts. If this AVP is absent from the Time-Of-Day-Condition AVP, the time window starts on January 1, 1900, 00:00 UTC.
アブソリュート・スタート・タイムAVP（AVPコード566）は、タイプTIMEのです。このAVPの値は、時間ウィンドウが始まる午前0時UTC 1900年1月1日以来の秒数を指定します。このAVPは、時刻-条件AVPに存在しない場合は、時間ウィンドウは1900年1月1日、00:00 UTCに開始します。
The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-Start-Time value in order to determine when the time window starts. If this AVP is absent from the Time-Of-Day-Condition AVP, then the fractional seconds are assumed to be zero.
アブソリュート・スタート・フラクショナル秒AVP（AVPコード567）はタイプUnsigned32にあります。値は時間ウィンドウの開始時に決定するために、絶対スタート時の値に加算されている小数秒を指定します。このAVPは、時刻-条件AVPに存在しない場合には、秒の小数はゼロと仮定されています。
The Time-Of-Day-End AVP (AVP Code 568) is of type Time. The value of this AVP specifies the time in seconds since January 1, 1900, 00:00 UTC when the time window ends. If this AVP is absent from the Time-Of-Day-Condition AVP, then the time window is open-ended.
時刻エンドAVP（AVPコード568）は、タイプTIMEのです。このAVPの値は、時間ウィンドウが終了する午前0時UTC 1900年1月1日以来の秒数を指定します。このAVPは、時刻-条件AVPに存在しない場合は、時間ウィンドウは、オープンエンドです。
The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-End-Time value in order to determine when the time window ends. If this AVP is absent from the Time-Of-Day-Condition AVP, then the fractional seconds are assumed to be zero.
アブソリュート・エンド・フラクショナル秒AVP（AVPコード569）はタイプUnsigned32にあります。値は時間ウィンドウの終了時に決定するために、絶対終了時間値に加算されている小数秒を指定します。このAVPは、時刻-条件AVPに存在しない場合には、秒の小数はゼロと仮定されています。
The Timezone-Flag AVP (AVP Code 570) is of type Enumerated and indicates whether the time windows are specified in UTC, local time, at the managed terminal or as an offset from UTC. If this AVP is absent from the Time-Of-Day-Condition AVP, then the time windows are in UTC.
タイムゾーン・フラグAVP（AVPコード570）がタイプ列挙型であり、時間窓が管理端末で、またはUTCからのオフセットとして、UTC、現地時刻に指定されているかどうかを示します。このAVPは、時刻-条件AVPに存在しない場合は、時間ウィンドウはUTCです。
This document defines the following values:
このドキュメントでは、次の値を定義します。
Value | Name and Semantic
------+--------------------------------------------------
0 | UTC - The time windows are expressed in UTC.
1 | LOCAL - The time windows are expressed in local
| time at the managed terminal.
2 | OFFSET - The time windows are expressed as an
| offset from UTC (see Timezone-Offset AVP).
The Timezone-Offset AVP (AVP Code 571) is of type Integer32. The value of this AVP MUST be in the range from -43200 to 43200. It specifies the offset in seconds from UTC that was used to express Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month-Mask, and Month-Of-Year-Mask AVPs. This AVP MUST be present if the Timezone-Flag AVP is set to OFFSET.
タイムゾーン・オフセットAVP（AVPコード571）が型Integer32のです。このAVPの値は、それが時刻スタート、時刻エンド、曜日を表現するために使用されたUTCからの秒数でのオフセットを指定43200.する-43200の範囲内でなければなりません-mask、デイ・オブ・月・マスク、および月・オブ・イヤー・マスクのAVP。タイムゾーンフラッグAVPを相殺するように設定されている場合は、このAVPが存在しなければなりません。
This section defines the actions associated with a rule.
このセクションでは、ルールに関連付けられたアクションを定義します。
The Treatment-Action AVP (AVP Code 572) is of type Enumerated and lists the actions that are associated with the condition part of a rule. The following actions are defined in this document:
トリートメント・アクションAVP（AVPコード572）がタイプ列挙型であり、ルールの条件部に関連付けられているアクションを示しています。以下のアクションは、この文書で定義されています。
0: drop 1: shape 2: mark 3: permit
0：ドロップ1：形状2：マーク3：許可
drop:
ドロップ：
This action indicates that the respective traffic MUST be dropped.
このアクションは、それぞれのトラフィックが廃棄されなければならないことを示しています。
shape:
形状：
[RFC2475] describes shaping as "the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile". When the action is set to 'shape', the QoS-Parameters AVP SHALL contain QoS information AVPs, such as the TMOD-1 and Bandwidth AVPs [RFC5624], that indicate how to shape the traffic described by the condition part of the rule.
[RFC2475]は、「それはいくつかの定義されたトラフィックプロファイルに適合させるために、トラフィックストリーム内のパケットを遅延させるプロセス」としての成形について説明します。アクションが「形状」に設定されている場合、QoSのパラメータAVPは、ルールの条件部によって記述トラフィックをシェーピングする方法を示すようTMOD-1と帯域幅のAVP [RFC5624]などのQoS情報AVPを、含まなければなりません。
mark:
マーク：
[RFC2475] describes marking as "the process of setting the DS codepoint in a packet based on defined rules". When the action is set to 'mark', the QoS-Parameters AVP SHALL contain QoS information AVPs, such as the PHB-Class AVP [RFC5624], that indicate the Diffserv marking to be applied to the traffic described by the condition part of the rule.
[RFC2475]は、「定義されたルールに基づいて、パケット内のDSコードポイントを設定する処理」としてマーキング記載されています。アクションが「マーク」に設定されている場合、QoSのパラメータAVPは、の条件部によって記述トラフィックに適用するマーキングDiffservのを示すようなPHBクラスAVP [RFC5624]などのQoS情報AVPを、含むものルール。
permit:
許可：
The 'permit' action is the counterpart to the 'drop' action used to allow traffic that matches the condition part of a rule to bypass.
「許可」アクションがバイパスにルールの条件部と一致するトラフィックを許可するために使用される「ドロップ」アクションに対応するものです。
[RFC2475] also describes an action called 'policing' as "the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile". This behavior is modeled in the Filter-Rule through the inclusion of the Excess-Treatment AVP containing a Treatment-Action AVP set to 'drop'.
[RFC2475]も、「トラフィックプロファイルを強制対応メータの状態に応じて、トラフィックストリーム内（点滴器によって）パケットを廃棄する処理」として「ポリシング」と呼ばれるアクションを記述する。この動作は、「ドロップ」にトリートメント・アクションAVPのセットを含む過剰治療AVPを含めることによってフィルター・ルールにモデル化されています。
Further action values can be registered, as described in Section 10.3.
セクション10.3で説明したようにさらに動作値は、登録することができます。
The QoS-Profile-Id AVP (AVP Code 573) is of type Unsigned32 and contains a QoS profile template identifier. An initial QoS profile template is defined with value of 0 and can be found in [RFC5624]. The registry for the QoS profile templates is created with the same document.
QoSをプロファイル-ID AVP（AVPコード573）はタイプUnsigned32にあるとQoSプロファイルテンプレート識別子を含みます。初期QoSプロファイルのテンプレートは、0の値で定義され、[RFC5624]に見出すことができます。 QoSプロファイルテンプレートのレジストリは、同じドキュメントで作成されます。
The QoS-Profile-Template AVP (AVP Code 574) is of type Grouped and defines the namespace of the QoS profile (indicated in the Vendor-ID AVP) followed by the specific value for the profile.
QoSをプロファイルテンプレートAVP（AVPコード574）がグループ化タイプのものであり、プロファイルの特定の値が続く（ベンダーID AVPで示される）QoSプロファイルの名前空間を定義します。
The Vendor-Id AVP contains a 32-bit IANA Private Enterprise Number (PEN), and the QoS-Profile-Id AVP contains the template identifier assigned by the vendor. The vendor identifier of zero (0) is used for the IETF.
ベンダーID AVPは、32ビットIANAプライベートエンタープライズ番号（PEN）が含まれ、およびQoS-プロファイル-ID AVPは、ベンダーによって割り当てられたテンプレート識別子を含みます。ゼロ（0）のベンダー識別子はIETFのために使用されます。
QoS-Profile-Template ::= < AVP Header: 574 >
{ Vendor-Id }
{ QoS-Profile-Id }
* [ AVP ]
The QoS-Semantics AVP (AVP Code 575) is of type Enumerated and provides the semantics for the QoS-Profile-Template and QoS-Parameters AVPs in the Filter-Rule AVP.
QoSの-セマンティクスAVP（AVPコード575）がタイプ列挙型のものであり、フィルター・ルールAVPにおけるQoS-プロファイル・テンプレートおよびQoSパラメータのAVPのためのセマンティクスを提供します。
This document defines the following values:
このドキュメントでは、次の値を定義します。
(0): QoS-Desired (1): QoS-Available (2): QoS-Delivered (3): Minimum-QoS (4): QoS-Authorized
（0）：QoSを所望の（1）：QoSを利用可能（2）：QoSを配信（3）：最小QoS（4）：QoSが許可
The semantics of the QoS parameters depend on the information provided in the list above. The semantics of the different values are as follows:
QoSパラメータの意味は、上記のリストに記載されている情報に依存しています。次のように異なる値の意味は以下のとおりです。
Object Type Direction Semantic
---------------------------------------------------------------------
QoS-Desired C->S Client requests authorization of the
indicated QoS.
QoS-Desired C<-S NA
QoS-Available C->S Admission Control at client indicates
that this QoS is available. (note 1)
QoS-Available C<-S Admission Control at server indicates
that this QoS is available. (note 2)
QoS-Delivered C->S Client is reporting the actual QoS
delivered to the terminal.
QoS-Delivered C<-S NA
Minimum-QoS C->S Client is not interested in authorizing
QoS that is lower than the indicated QoS.
Minimum-QoS C<-S Client must not provide QoS guarantees
lower than the indicated QoS.
QoS-Authorized C->S NA
QoS-Authorized C<-S Server authorizes the indicated QoS.
Legend:
伝説：
C: Diameter client S: Diameter server NA: Not applicable to this document; no semantic defined in this specification
C：DiameterクライアントのS：直径サーバーNA：この文書には適用されません。無セマンティックこの仕様で定義されています
Notes:
ノート：
(1) QoS-Available in this direction indicates to the server that any QoS-Authorized or Minimum-QoS must be less than this indicated QoS.
（1）QoSに利用可能なこの方向では、任意のQoSの許可または最小QoSがこれより小さくなければならないQoSを示すサーバに指示します。
(2) QoS-Available in this direction is only useful when the AAA server performs admission control and knows about the resources in the network.
（2）QoSに利用可能なこの方向では、AAAサーバは、許可制御を実行し、ネットワーク内のリソースを知っている場合にのみ有用です。
The QoS-Parameters AVP (AVP Code 576) is of type Grouped and contains Quality of Service parameters. These parameters are defined in separate documents and depend on the indicated QoS profile template of the QoS-Profile-Template AVP. For an initial QoS parameter specification, see [RFC5624].
QoSのパラメータAVP（AVPコード576）がグループ化されたタイプのものであり、サービス品質パラメータが含まれています。これらのパラメータは、別の文書で定義されているとQoS-プロファイル・テンプレートAVPの指示QoSプロファイルテンプレートに依存しています。初期のQoSパラメータの指定については、[RFC5624]を参照してください。
QoS-Parameters ::= < AVP Header: 576 >
* [ AVP ]
The Excess-Treatment AVP (AVP Code 577) is of type Grouped and indicates how out-of-profile traffic, i.e., traffic not covered by the original QoS-Profile-Template and QoS-Parameters AVPs, is treated. The additional Treatment-Action, QoS-Profile-Template, and QoS-Parameters AVPs carried inside the Excess-Treatment AVP provide information about the QoS treatment of the excess traffic. In case the Excess-Treatment AVP is absent, then the treatment of the out-of-profile traffic is left to the discretion of the node performing QoS treatment.
過剰治療AVP（AVPコード577）がグループ化されたタイプのものであり、アウト・オブ・プロファイル、すなわち、トラフィックが元のQoSプロファイルテンプレートおよびQoSパラメータのAVPによって覆われていないトラフィックが、処理されるかを示します。過剰治療AVP内で行わ追加の治療・アクション、QoSにプロファイル・テンプレート、およびQoSパラメータのAVPは、過剰なトラフィックのQoS処理に関する情報を提供します。場合には過剰処理AVPは、次いで、アウトオブプロファイルトラフィックの処理は、QoS処理を行うノードの裁量に任され、存在しません。
Excess-Treatment ::= < AVP Header: 577 >
{ Treatment-Action }
[ QoS-Profile-Template ]
[ QoS-Parameters ]
* [ AVP ]
The QoS-Capability AVP (AVP Code 578) is of type Grouped and contains a list of supported Quality of Service profile templates (and therefore the support of the respective parameter AVPs).
QoSの-能力AVP（AVPコード578）は、タイプグループ化であるとサポートサービスプロファイルテンプレートの品質（したがって、それぞれのパラメータのAVPのサポート）のリストが含まれています。
The QoS-Capability AVP may be used for a simple announcement of the QoS capabilities and QoS profiles supported by a peer. It may also be used to negotiate a mutually supported set of QoS capabilities and
QoSの-能力AVPは、ピアによってサポートされるQoS機能とQoSプロファイルの簡単な発表のために使用することができます。またQoS機能の相互サポートセットを交渉するために使用することができると
QoS profiles between two peers. In such a case, handling of failed negotiations is application and/or deployment specific.
2つのピア間のQoSプロファイル。このような場合には、失敗した交渉の処理は、アプリケーションおよび/または配備特異的です。
QoS-Capability ::= < AVP Header: 578 >
1*{ QoS-Profile-Template }
* [ AVP ]
The QoS-Profile-Template AVP is defined in Section 5.3.
QoSの-プロファイル・テンプレートのAVPは、セクション5.3で定義されています。
This section shows a number of signaling flows where QoS negotiation and authorization are part of the conventional NASREQ, EAP, or Credit Control applications message exchanges. The signaling flows for the Diameter QoS Application are described in [DIAMETER-QOS].
このセクションでは、QoS交渉および許可は、従来NASREQ、EAP、またはクレジット制御アプリケーションメッセージ交換の一部であるフローシグナリングの数を示します。直径のQoSアプリケーションのためのシグナリング・フローは、[DIAMETER-QOS]に記載されています。
Figure 2 shows a simple signaling flow where a Network Access Server (NAS) (Diameter Client) announces its QoS awareness and capabilities included into the DER message and as part of the access authentication procedure. Upon completion of the EAP exchange, the Diameter server provides a pre-provisioned QoS profile with the QoS-Semantics in the Filter-Rule AVP set to 'QoS-Authorized', to the NAS in the final Diameter-EAP-Answer (DEA) message.
図2は、ネットワークアクセスサーバ（NAS）（Diameterクライアント）がそのQoSの意識と能力がDERメッセージに、アクセス認証手順の一部として含ま発表単純なシグナリング・フローを示します。 EAP交換が完了すると、ダイアメータサーバは、事前プロビジョニングされたQoSは、最終直径-EAP-回答にNASに、「QoSの許可」に設定されたフィルタルールのAVPにおけるQoS-セマンティクスプロファイル（DEA）を提供しますメッセージ。
End Diameter Diameter
Host Client Server
| | |
| (initiate EAP) | |
|<----------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Start) |
| | QoS-Capability |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request #1) |
| |<-------------------------------|
| EAP Request(Identity) | |
|<------------------------------| |
: : :
: <<<more message exchanges>>> :
: : :
| | |
| EAP Response #N | |
|------------------------------>| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response #N) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | (authorization AVPs) |
| | QoS-Resources(QoS-Authorized) |
| |<-------------------------------|
| | |
| EAP Success | |
|<------------------------------| |
| | |
Figure 2: Example of a Diameter EAP Enhanced with QoS Information
図2：直径EAPの例は、QoS情報を強化
Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 but using the NASREQ application instead of EAP application.
図3は、同様の事前プロビジョニングされたQoSは、図2のように、シグナリングが、NASREQアプリケーションの代わりにEAPアプリケーションを使用して示しています。
End Diameter
Host NAS Server
| | |
| Start Network | |
| Attachment | |
|<---------------->| |
| | |
| |AA-Request |
| |NASREQ-Payload |
| |QoS-Capability |
| +----------------------------->|
| | |
| | AA-Answer|
| Result-Code=DIAMETER_MULTI_ROUND_AUTH|
| NASREQ-Payload(NASREQ Request #1)|
| |<-----------------------------+
| | |
| Request | |
|<-----------------+ |
| | |
: : :
: <<<more message exchanges>>> :
: : :
| Response #N | |
+----------------->| |
| | |
| |AA-Request |
| |NASREQ-Payload ( Response #N )|
| +----------------------------->|
| | |
| | AA-Answer|
| | Result-Code=DIAMETER_SUCCESS|
| | (authorization AVPs)|
| | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+
| | |
| Success | |
|<-----------------+ |
| | |
Figure 3: Example of a Diameter NASREQ Enhanced with QoS Information
図3：QoSの情報で強化された直径NASREQの例
Figure 4 shows an example of authorization-only QoS signaling as part of the NASREQ message exchange. The NAS provides the Diameter server with the "QoS-Desired" QoS-Semantics AVP included in the QoS-Resources AVP. The Diameter server then either authorizes the indicated QoS or rejects the request and informs the NAS about the result. In this scenario, the NAS does not need to include the QoS-Capability AVP in the AAR message as the QoS-Resources AVP implicitly does the same and also the NAS is authorizing a specific QoS profile, not a pre-provisioned one.
図4は、NASREQメッセージ交換の一部としてシグナリング認可のみのQoSの例を示しています。 NASは、AVPのQoSリソースAVPに含まれる「QoSの希望」-セマンティクスのQoSをDiameterサーバを提供します。ダイアメータサーバは、その後のいずれかが示されたQoSを許可または要求を拒否し、その結果についてNASに通知します。このシナリオでは、NASは、暗黙的に同じことをしても、NASは、特定のQoSプロファイルではなく、事前にプロビジョニングされたものを許可されたQoS-資源AVPとしてAARメッセージでのQoS機能のAVPを含める必要はありません。
End Diameter
Host NAS Server
| | |
| | |
| QoS Request | |
+----------------->| |
| | |
| |AA-Request |
| |Auth-Request-Type=AUTHORIZE_ONLY
| |NASREQ-Payload |
| |QoS-Resources(QoS-Desired) |
| +----------------------------->|
| | |
| | AA-Answer|
| | NASREQ-Payload(Success)|
| | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+
| Accept | |
|<-----------------+ |
| | |
| | |
| | |
Figure 4: Example of an Authorization-Only Message Flow
図4：認可専用メッセージフローの例
Figure 5 shows a message exchange for a Diameter server-initiated QoS re-authorization procedure. The Diameter server sends the NAS a Re-Auth Request (RAR) message requesting re-authorization for an existing session and the NAS acknowledges it with a RAA message. The NAS is aware of its existing QoS profile and information for the ongoing session that the Diameter server requested for re- authorization. Thus, the NAS must initiate re-authorization of the existing QoS profile. The re-authorization procedure is the same as in Figure 4.
図5は、Diameterサーバによって設定されたQoS再認証手順のためのメッセージ交換を示しています。ダイアメータサーバは、既存のセッションのために再認証を要求するNASに再認証要求（RAR）メッセージを送信し、NASは、RAAメッセージでそれを認めます。 NASは、Diameterサーバは再認証のために要求されたことを進行中のセッションのために、既存のQoSプロファイルと情報を認識しています。このように、NASは、既存のQoSプロファイルの再認証を開始する必要があります。再認証手順は、図4と同じです。
End Diameter
Host NAS Server
| | |
| | |
: : :
: <<<Initial Message Exchanges>>> :
: : :
| | |
| | RA-Request |
| |<-----------------------------+
| | |
| |RA-Answer |
| |Result-Code=DIAMETER_SUCCESS |
| +----------------------------->|
| | |
| | |
| |AA-Request |
| |NASREQ-Payload |
| |Auth-Request-Type=AUTHORIZE_ONLY
| |QoS-Resources(QoS-Desired) |
| +----------------------------->|
| | |
| | AA-Answer|
| | Result-Code=DIAMETER_SUCCESS|
| | (authorization AVPs)|
| | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+
| | |
Figure 5: Example of a Server-Initiated Re-Authorization Procedure
図5：サーバ起動再認証手順の例
In this example, the CC client includes a QoS authorization request (QoS-Semantics=QoS-Desired) in the initial Credit Control Request (CCR). The CC server responds with a Credit Control Answer (CCA), which includes the granted resources with an authorized QoS definition (QoS-Semantics=QoS-Authorized) and the CC client proceeds to deliver service with the specified QoS.
この例では、CCのクライアントは、最初のクレジット制御要求（CCR）内のQoS認可要求を（QoSの-セマンティクス= QoSの希望）が含まれています。 CCサーバは、許可QoS定義（QoSの-セマンティクス=のQoS-認定）で許可されたリソースが含まクレジット制御応答（CCA）、で応答し、CCクライアントは、指定されたQoSとサービスを提供するために進みます。
At the end of service, the CC client reports the units used and the QoS level at which those units were delivered (QoS-Semantics=QoS-Delivered). The end of service could occur because the credit resources granted to the user were exhausted or the service was been successfully delivered or the service was terminated, e.g., because the Service Element could not deliver the service at the authorized QoS level.
サービスの終了時に、CCのクライアントが使用される単位を報告し、QoSは（QoSの-セマンティクス=のQoS-配信）それらのユニットが配信されたレベル。例えば、ユーザーに付与されたクレジット資源が枯渇し、またはサービスが正常に配信されたか、サービスが終了したため、サービス要素が認可QoSレベルでサービスを提供することができなかったため、サービスの終了は、発生する可能性があります。
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) End of Service | |
|-------------------->| |
| |(6) CCR (Termination, Used-Units, |
| | QoS-Resources(QoS-Delivered)) |
| |--------------------------------->|
| |(7) CCA |
| |<---------------------------------|
Figure 6: Example of a Diameter Credit Control with QoS Information
図6：QoSの情報を持つ直径クレジット制御の例
Example: Classify all packets from hosts on subnet 192.0.2.0/24 to ports 80, 8090 or 443 on web servers 192.0.2.123, 192.0.2.124, 192.0.2.125.
例：Webサーバ192.0.2.123、192.0.2.124、192.0.2.125のポート80、8090または443にサブネット192.0.2.0/24上のホストからのすべてのパケットを分類します。
Classifier = {
Classifier-Id = "web_svr_example";
Protocol = TCP;
Direction = OUT;
From-Spec = {
IP-Address-Mask = {
IP-Address = 192.0.2.0;
IP-Bit-Mask-Width = 24;
}
}
To-Spec = {
IP-Address = 192.0.2.123;
IP-Address = 192.0.2.124;
IP-Address = 192.0.2.125;
Port = 80;
Port = 8080;
Port = 443;
}
}
Example: Any SIP signaling traffic from a device with a MAC address of 01:23:45:67:89:ab to servers with IP addresses in the range 192.0.2.90 to 192.0.2.190.
例：のMACアドレスを持つデバイスからのトラフィックシグナリング任意SIP 01：23：45：67：89：AB範囲192.0.2.190に192.0.2.90にIPアドレスを持つサーバへ。
Classifier = {
Classifier-Id = "web_svr_example";
Protocol = UDP;
Direction = OUT;
From-Spec = {
MAC-Address = 01:23:45:67:89:ab;
}
To-Spec = {
IP-Address-Range = {
IP-Address-Start = 192.0.2.90;
IP-Address-End = 192.0.2.190;
}
Port = 5060;
Port = 3478;
Port-Range = {
Port-Start = 16348;
Port-End = 32768;
}
}
}
The following high-level description aims to illustrate the interworking between the Diameter QoS AVPs defined in this document and the QoS parameters defined in [RFC5624].
以下の高レベルの記述は、この文書で定義された直径のQoSのAVPと[RFC5624]で定義されたQoSパラメータとの間のインターワーキングを例示することを目的とします。
Consider the following example where a rule should be installed that limits traffic to 1 Mbit/s and where out-of-profile traffic shall be dropped. The Classifiers are ignored in this example.
ルールが限界1メガビット/秒のトラフィックとアウトオブプロファイルトラフィックが廃棄されなければならないことをインストールする必要があり、以下の例を考えます。クラシファイアは、この例では無視されます。
This would require the Treatment-Action AVP to be set to 'shape' and the QoS-Parameters AVP carries the Bandwidth AVP indicating the 1 Mbit/s limit. The Treatment-Action carried inside the Excess-Treatment AVP would be set to 'drop'.
これは、「形状」に設定されたQoSパラメータAVPは、1メガビット/秒の限界を示す帯域AVPを搬送する処理アクションAVPを必要とするであろう。過剰治療AVP内で行わ治療-アクションを「ドロップ」に設定されます。
In a second, more complex scenario, we consider traffic marking with Diffserv. In-profile traffic (of 5 Mbit/s in our example) shall be associated with a particular PHB-Class "X". Out-of-profile traffic shall belong to a different PHB-Class, in our example "Y".
二、より複雑なシナリオでは、Diffservのマーキングトラフィックを検討してください。 （この例では5メガビット/秒の）では不適合トラフィックは、特定のPHBクラス「X」に関連付けされなければなりません。アウトオブプロファイルトラフィックは、私たちの例「Y」で、異なるPHBクラスに属しているものとします。
This configuration would require the Treatment-Action AVP to be set to 'mark'. The QoS-Parameters AVPs for the traffic conforming of the profile contains two AVPs, namely, the TMOD-1 AVP and the PHB-Class AVP. The TMOD-1 AVP describes the traffic characteristics, namely, 5 Mbit/s, and the PHB-Class AVP is set to class "X". Then, the Excess-Treatment AVP has to be included with the Treatment-Action AVP set to 'mark' and the QoS-Parameters AVP to carry another PHB-Class AVP indicating PHB-Class AVP setting to class "Y".
この構成は、「マーク」に設定することが治療のアクションAVPを必要とします。プロフィールのトラフィック準拠のQoSパラメータのAVPは2つのAVP、すなわち、TMOD-1 AVPおよびPHBクラスAVPが含まれています。 TMOD-1 AVPは、トラフィック特性、即ち、5メガビット/秒を説明し、そしてPHBクラスAVPは、クラス「X」に設定されています。その後、過剰治療AVPは、治療アクションAVPは、クラス「Y」に設定PHBクラスAVPを示す別のPHBクラスAVPを運ぶために「マーク」とのQoSパラメータAVPに設定に含まれている必要があります。
We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel, Yong Li, and Eric Gray for their comments. We thank Victor Fajardo for his job as PROTO document shepherd. Finally, we would like to thank Lars Eggert, Magnus Westerlund, Adrian Farrel, Lisa Dusseault, Ralph Droms, and Eric Gray for their feedback during the IESG review phase.
私たちは、ビクターファハルド、Tseno Tsenov、ロバート・ハンコック、ユッカマナー、コーネリアKappler、暁明フー、フランク・アルファーノ、トルガAsveren、マイク・モンテムッロ、グレン・ソーン、Avriドリア、ドン日、ティナツオウ、ピートマッキャン、ゲオルギオスKaragiannisに感謝したいと思います彼らのコメントのためのエルウィン・デイヴィス、マックスリーゲル、ヨンジュンリー、そしてエリックグレー。私たちは、PROTOドキュメント羊飼いとしての彼の仕事のためにビクターファハルドに感謝します。最後に、我々はIESGレビューの段階で彼らのフィードバックのためにラースエッゲルト、マグヌスウェスター、エードリアンファレル、リサDusseault、ラルフDroms、そしてエリック・グレイに感謝したいと思います。
Max Riegel contributed the VLAN sections.
マックスリーゲルは、VLANのセクションに貢献しました。
IANA has allocated codes from the "AVP Codes" registry under Authentication, Authorization, and Accounting (AAA) Parameters for the following AVPs that are defined in this document.
IANAは、この文書で定義されている以下のAVPの認証、許可、アカウンティング（AAA）パラメータの下で、「AVPコード」レジストリからコードを割り当てています。
+-------------------------------------------------------------------+
| AVP Section |
| Attribute Name Code Defined Data Type |
+-------------------------------------------------------------------+
|QoS-Resources 508 3.1 Grouped |
|Filter-Rule 509 3.2 Grouped |
|Filter-Rule-Precedence 510 3.3 Unsigned32 |
|Classifier 511 4.1.1 Grouped |
|Classifier-ID 512 4.1.2 OctetString |
|Protocol 513 4.1.3 Enumerated |
|Direction 514 4.1.4 Enumerated |
|From-Spec 515 4.1.5 Grouped |
|To-Spec 516 4.1.6 Grouped |
|Negated 517 4.1.7.1 Enumerated |
|IP-Address 518 4.1.7.2 Address |
|IP-Address-Range 519 4.1.7.3 Grouped |
|IP-Address-Start 520 4.1.7.4 Address |
|IP-Address-End 521 4.1.7.5 Address |
|IP-Address-Mask 522 4.1.7.6 Grouped |
|IP-Mask-Bit-Mask-Width 523 4.1.7.7 Unsigned32 |
|MAC-Address 524 4.1.7.8 OctetString |
|MAC-Address-Mask 525 4.1.7.9 Grouped |
|MAC-Address-Mask-Pattern 526 4.1.7.10 OctetString |
|EUI64-Address 527 4.1.7.11 OctetString |
|EUI64-Address-Mask 528 4.1.7.12 Grouped |
|EUI64-Address-Mask-Pattern 529 4.1.7.13 OctetString |
|Port 530 4.1.7.14 Integer32 |
|Port-Range 531 4.1.7.15 Grouped |
|Port-Start 532 4.1.7.16 Integer32 |
|Port-End 533 4.1.7.17 Integer32 |
|Use-Assigned-Address 534 4.1.7.18 Enumerated |
|Diffserv-Code-Point 535 4.1.8.1 Enumerated |
|Fragmentation-Flag 536 4.1.8.2 Enumerated |
|IP-Option 537 4.1.8.3 Grouped |
|IP-Option-Type 538 4.1.8.4 Enumerated |
|IP-Option-Value 539 4.1.8.5 OctetString |
|TCP-Option 540 4.1.8.6 Grouped |
|TCP-Option-Type 541 4.1.8.7 Enumerated |
|TCP-Option-Value 542 4.1.8.8 OctetString |
|TCP-Flags 543 4.1.8.9 Grouped |
|TCP-Flag-Type 544 4.1.8.10 Unsigned32 |
|ICMP-Type 545 4.1.8.11 Grouped |
|ICMP-Type-Number 546 4.1.8.12 Enumerated |
|ICMP-Code 547 4.1.8.13 Enumerated |
|ETH-Option 548 4.1.8.14 Grouped |
|ETH-Proto-Type 549 4.1.8.15 Grouped |
|ETH-Ether-Type 550 4.1.8.16 OctetString |
|ETH-SAP 551 4.1.8.17 OctetString |
|VLAN-ID-Range 552 4.1.8.18 Grouped |
|S-VID-Start 553 4.1.8.19 Unsigned32 |
|S-VID-End 554 4.1.8.20 Unsigned32 |
|C-VID-Start 555 4.1.8.21 Unsigned32 |
|C-VID-End 556 4.1.8.22 Unsigned32 |
|User-Priority-Range 557 4.1.8.23 Grouped |
|Low-User-Priority 558 4.1.8.24 Unsigned32 |
|High-User-Priority 559 4.1.8.25 Unsigned32 |
|Time-Of-Day-Condition 560 4.2.1 Grouped |
|Time-Of-Day-Start 561 4.2.2 Unsigned32 |
|Time-Of-Day-End 562 4.2.3 Unsigned32 |
|Day-Of-Week-Mask 563 4.2.4 Unsigned32 |
|Day-Of-Month-Mask 564 4.2.5 Unsigned32 |
|Month-Of-Year-Mask 565 4.2.6 Unsigned32 |
|Absolute-Start-Time 566 4.2.7 Time |
|Absolute-Start-Fractional-Seconds 567 4.2.8 Unsigned32 |
|Absolute-End-Time 568 4.2.9 Time |
|Absolute-End-Fractional-Seconds 569 4.2.10 Unsigned32 |
|Timezone-Flag 570 4.2.11 Enumerated |
|Timezone-Offset 571 4.2.12 Integer32 |
|Treatment-Action 572 5.1 Grouped |
|QoS-Profile-Id 573 5.2 Unsigned32 |
|QoS-Profile-Template 574 5.3 Grouped |
|QoS-Semantics 575 5.4 Enumerated |
|QoS-Parameters 576 5.5 Grouped |
|Excess-Treatment 577 5.6 Grouped |
|QoS-Capability 578 6 Grouped |
+-------------------------------------------------------------------+
IANA has allocated a new registry under Authentication, Authorization, and Accounting (AAA) Parameters for the QoS-Semantics AVP. The following values are allocated by this specification:
IANAは、QoS-セマンティクスAVPのための認証、認可、アカウンティング（AAA）パラメータの下に新しいレジストリを割り当てています。次の値は、この仕様で割り当てられます。
(0): QoS-Desired
(1): QoS-Available
(2): QoS-Delivered
(3): Minimum-QoS
(4): QoS-Authorized
The definition of new values is subject to the Specification Required policy [RFC5226].
新しい値の定義は、仕様が必要ポリシー[RFC5226]に従うものとします。
IANA has allocated a new registry under Authentication, Authorization, and Accounting (AAA) Parameters for the Treatment-Action AVP. The following values are allocated by this specification:
IANAは、治療アクションAVPのための認証、認可、アカウンティング（AAA）パラメータの下に新しいレジストリを割り当てています。次の値は、この仕様で割り当てられます。
0: drop 1: shape 2: mark 3: permit
0：ドロップ1：形状2：マーク3：許可
The definition of new values is subject to the Specification Required policy [RFC5226].
新しい値の定義は、仕様が必要ポリシー[RFC5226]に従うものとします。
This document describes the extension of Diameter for conveying Quality of Service information. The security considerations of the Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol.
このドキュメントでは、サービス情報の品質を搬送するための直径の拡張を説明しています。 Diameterプロトコル自体のセキュリティ問題は、RFC 3588 [RFC3588]で議論されてきました。この文書で定義されたAVPsの使用を考慮に直径ベースプロトコルのセキュリティ問題や要件を取る必要があります。
[IEEE802.1D] IEEE, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", 2004.
[IEEE802.1D] IEEE、 "地方とメトロポリタンエリアネットワークのためのIEEE規格、メディアアクセス制御（MAC）ブリッジ"、2004年。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks", 2005.
[IEEE802.1Q] IEEE、「地方とメトロポリタンエリアネットワークのためのIEEE規格、仮想ブリッジローカルエリアネットワーク」、2005。
[IEEE802.1ad] IEEE, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", 2005.
[IEEE802.1ad] IEEE、「地方とメトロポリタンエリアネットワークのためのIEEE規格、仮想ブリッジローカルエリアネットワーク、修正4：プロバイダブリッジ」、2005年。
[IEEE802.2] IEEE, "IEEE Standard for Information technology, Telecommunications and information exchange between systems, Local and metropolitan area networks, Specific requirements, Part 2: Logical Link Control", 1998.
[IEEE802.2] IEEE、「IEEE標準情報技術、電気通信及びシステム間での情報交換、ローカルおよびメトロポリタンエリアネットワーク、具体的な要件、パート2：論理リンク制御」、1998年。
[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月。
[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月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]ブラドナー、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[DIAMETER-QOS] Sun, D., Ed., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, Ed., "Diameter Quality of Service Application", Work in Progress, October 2009.
[DIAMETER-QOS]日、D.、エド。、マッキャン、P.、Tschofenig、H.、ツオウ、T.、ドリア、A.、およびG.ツォルン、エド。、 "サービスアプリケーションの直径品質"、仕事プログレス10月2009インチ
[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月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、RFC 4005、2005年8月。
[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of Service Parameters for Usage with Diameter", RFC 5624, August 2009.
[RFC5624] Korhonen、J.、Tschofenig、H.、およびE.デイヴィス、 "直径の使用のためのサービスパラメータの品質"、RFC 5624、2009年8月。
Appendix A. MAC and EUI64 Address Mask Usage Considerations
付録A. MACとEUI64アドレスマスク使用上の注意
The MAC and EUI64 address bit masks are generally used in classifying devices according to Organizationally Unique Identifier (OUI) and/or address blocks specific to the OUI assignee. The bit masks are not intended to introduce a structure into the MAC or EUI64 address space that was not intended by the IEEE.
MACとEUI64アドレスビットマスクは、一般に、組織固有識別子（OUI）および/またはOUIの譲受人に特定のアドレスブロックに応じて分類する装置に使用されています。ビットマスクは、IEEEが意図していなかったMACまたはEUI64アドレス空間に構造を導入することを意図していません。
The MAC address bit mask should be defined as a contiguous series of "N" set bits followed by a contiguous series of "48 - N" clear bits, e.g., the MAC address bit mask of 0xFF00FF000000 would not be valid. Similarly, the EUI64 address bit mask should be defined as a contiguous series of "N" set bits followed by a contiguous series of "64 - N" clear bits.
「48 - N」MACアドレスビットマスクが「N」セットの連続した一連続くビットの連続した一連のように定義されなければならない明確なビット、例えば、0xFF00FF000000のMACアドレスビットマスクは有効ではないであろう。クリアビット - 同様に、EUI64アドレスビットマスクは、「N 64」の連続シリーズに続く「N」の組のビットの連続シリーズとして定義されるべきです。
It should also be noted that some OUIs are assigned for use in applications that require number space management at the organization level (e.g., LLC/SNAP encoding), and are not commonly used for MAC addresses.
また、いくつかのOUIは、組織レベル（例えば、LLC / SNAPエンコード）で数領域管理を必要とする用途に使用するために割り当てられ、一般にMACアドレスのために使用されていないことに留意すべきです。
Authors' Addresses
著者のアドレス
Jouni Korhonen 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
Mayutan Arumaithurai University of Goettingen
ゲッティンゲンのMayutan Arumaithurai大学
EMail: mayutan.arumaithurai@gmail.com
メールアドレス：mayutan.arumaithurai@gmail.com
Mark Jones (editor) Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada
マーク・ジョーンズ（エディタ）ブリッジウォーター・システムズ303テリー・フォックス・ドライブ、スイート500オタワ、オンタリオ州K2K 3J1カナダ
Phone: +1 613-591-6655 EMail: mark.jones@bridgewatersystems.com
電話：+1 613-591-6655電子メール：mark.jones@bridgewatersystems.com
Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada
アビLIORブリッジウォーター・システムズ303テリー・フォックス・ドライブ、スイート500オタワ、オンタリオ州K2K 3J1カナダ
Phone: +1 613-591-6655 EMail: avi@bridgewatersystems.com
電話：+1 613-591-6655電子メール：avi@bridgewatersystems.com