[要約] RFC 5777は、Diameterプロトコルのトラフィック分類と品質サービス（QoS）属性に関するガイドラインです。このRFCの目的は、Diameterネットワークでのトラフィックの分類とQoS属性の一貫性を確保し、ネットワークの効率性とパフォーマンスを向上させることです。
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
直径の交通分類とサービス品質（QOS）属性
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は、それぞれの直径コマンド拡張ポリシーの拡張されたBackus-Naurフォーム（ABNF）仕様によって許可される既存および将来の直径アプリケーションで使用できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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は、それぞれの直径コマンド拡張ポリシーの拡張されたBackus-Naurフォーム（ABNF）仕様によって許可される既存および将来の直径アプリケーションで使用できます。
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]では基づいており、後に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-Rule AVPでは不可能なイーサネット固有の属性で一致する機能が含まれます。サービスの差別化は、イーサネット優先ビット、VLAN-IDまたは積み重ねられたVLAN-IDの単一層、論理リンク制御（LLC）属性、MACアドレス、またはその任意の組み合わせに基づいている場合があります。イーサネット分類に使用されるヘッダーフィールドは、[IEEE802.2]、[IEEE802.1AD]、[IEEE802.1Q]、および[IEEE802.1D]の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ポリシールールは、拡張されたバックスNAURフォーム（ABNF）の変更されたバージョンを使用して記述された直径エンコード属性値ペア（AVP）として定義されます（[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-ResourcesAVP（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 ]
; 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-Profile-Id AVP is set to zero (0), then the AVPs included in the QoS-Parameters AVP are the AVPs defined in [RFC5624].
QoS-Profile-Template AVPがフィルタールールAVPに含まれておらず、処理アクションAVPが「形状」または「マーク」に設定されている場合、デフォルト設定、つまりベンダー-ID AVPの設定が想定されます。0（IETFの場合）およびQOS-Profile-ID AVPからゼロ（0）（[RFC5624]で定義されているプロファイルの場合）。QOSパラメーターのコンテンツは、QoSパラメーターを定義するそれぞれの仕様で定義されていることに注意してください。ベンダー-ID AVPが0（IETFの場合）に設定され、QOS-Profile-ID AVPがゼロ（0）に設定されている場合、QoS-Parametersに含まれるAVPは[RFC5624]で定義されている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.
Filter-Rule-Precedence AVP（AVPコード510）は型Unsigned32であり、QOSリソースAVPで表されるルールの実行順序を指定します。Filter-Rule-PrecedenceAVPの数値が低いほど、ルールの優先順位が高くなります。リソース管理機能によってサポートされている場合、同等の優先順位のあるルールは並行して実行できます。Filter-Rule-Precedence AVPがFilter-Rule 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.
このセクションでは、ルールの条件部分について説明します。このドキュメントでは、2つの条件タイプが紹介されています。分類器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つの時間内でなければなりません - 条件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.
分類エンティティは、管理された端末またはパケットが発信（外出）から管理された端末に着信（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）はタイプのオクテットストリングで、分類器を一意に識別します。各アプリケーションは、この識別子の一意の一意の範囲を定義します。分類器AVP内に1つの分類子ID 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が分類器から省略されている場合、パケットのプロトコルの比較は無関係です。このAVPの値は、[RFC2780]で定義されているプロトコル番号レジストリの下で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」、「両方」です。「in」と「両方」の方向で、From-specは管理された端末のアドレスを指し、To-specは管理されていない端末を指します。「out」方向では、From-specは管理されていない端末を指しますが、to-specは管理された端子を指します。方向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.
From-Spec AVP（AVPコード515）は、パケットと一致するために使用されるソース仕様を指定するグループ化されたAVPです。これらのAVPのゼロ以上は、分類器に表示される場合があります。このAVPが分類器に存在しない場合、すべてのパケットはソースアドレスに関係なく一致します。このAVPの複数のインスタンスが分類器に表示されている場合、パケットのソースは、From-Spec 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-Address、IP-Address-Range、IP-Address-Mask、Use-Asigned-Address）がFrom-Spec AVPに表示される場合、Source IPアドレスはパケットは、これらのAVPで表されるアドレスの1つと一致する必要があります。
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のアドレスAVPS（Mac-Address、Mac-Address-Mask、EUI64-Address、EUI64-Address-Mask）の1つのアドレスAVPSの複数のインスタンスがFrom-Specに表示される場合、パケットのソースレイヤー2アドレスが一致する必要があります。これらのAVPで表されるアドレスの1つ。
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の複数のインスタンス（ポート、ポート範囲）がFrom-Spec AVPに表示される場合、ソースポート番号は、これらのAVPで表されるポート番号の1つと一致する必要があります。
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が同じFrom-Spec 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-Spec AVP（AVPコード516）は、パケットと一致するために使用される宛先仕様を指定するグループ化された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 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-Address、IP-Address-Range、IP-Address-Mask、Use-Adigned-Address）がTo-Spec AVPに表示される場合、パケットは、これらのAVPで表されるアドレスの1つと一致する必要があります。
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アドレスAVPS（Mac-Address、Mac-Address-Mask、EUI64-Address、EUI64-Address-Mask）のAVPS（Mac-Address、Mac-Address-Mask、EUI64-Address-Mask）の複数のインスタンスがTo-Specに表示される場合、パケットの宛先レイヤー2アドレスが一致する必要があります。これらのAVPで表されるアドレスの1つ。
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-Spec AVPに表示される場合、宛先ポート番号は、これらのAVPに表されるポート番号の1つと一致する必要があります。
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-Spec 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のいずれかが、From-SpecまたはTo-Spec 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に設定すると、試合の意味は反転され、分類器はFrom-SpecまたはTo-Spec AVPで指定されたもの以外のアドレスと一致します。falseに設定された場合、または否定されたAVPが存在しない場合、分類器は、From-SpecまたはTo-Spec 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-Address 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-Address-Range 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-Address-Start 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 Address-Range AVPが有効であるためには、IP-Address-Start 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-Address-Start 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-Address-End 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-Address-Mask AVP（AVPコード522）はグループ化されたタイプで、ベースIPアドレスとマスクのビット幅を使用してIPアドレス範囲を指定します。たとえば、192.0.2.0/24として表される範囲は、192.0.2.0から192.0.2.255までのすべての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-Bit-Mask-Width AVP（AVPコード523）は、符号なし32です。値は、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-Address AVP（AVPコード524）はタイプのオクテットストリングで、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-Address-Mask AVP（AVP Code 525）はグループ化されたタイプで、BITマスクを使用してMACアドレスのセットを指定して、指定されたMACアドレス属性に適合するMACアドレスのビットを示します。たとえば、Mac-Addressを00-10-A4-23-00-00にしたMac-Address-Mask、およびFF-FF-FF-FF-00-00のMac-Address-Mask-Patternが一致します00-10-A4-23-00-00から00-10-A4-23-FF-FFまでのすべてのMACアドレス。
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-Address-Mask-Pattern AVP（AVPコード526）は、タイプのオクテットストリングです。値は6オクテットで、一致するために取得されるMACアドレスのビット位置を指定します。
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-Address AVP（AVPコード527）はタイプのオクテットストリングであり、EUI-64形式の単一層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-ADDRESS-MASK AVP（AVPコード528）はグループ化されたタイプで、Bit Maskを使用してEUI64アドレスのセットを指定して、指定されたEUI64アドレス属性に適合するEUI64アドレスのビットを示すことを指定します。たとえば、EUI64-アドレスを00-10-A4-FF-FE-23-00-00としたEUI64-ADDRESS-MASK、およびFF-FF-FF-FF-FF-FFのEUI64-Address-Mask-Patternを備えた-ff-00-00は、00-10-A4-FF-FE-23-00-00から00-10-A4-FF-FE-23-FF-FFを含むすべてのEUI64アドレスと一致します。
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-Address-Mask-Pattern AVP（AVPコード529）は、タイプのオクテットストリングです。値は8オクテットで、一致するために取得されるEUI64アドレスのビット位置を指定します。
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アドレスを知りません。使用されたADDRESS 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の1つ以上が含まれている場合があります。
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-Code-Point AVP（AVPコード535）は列挙されており、IPヘッダーに一致する差別化されたサービスフィールドコードポイントを指定します。値は、[RFC2474]で定義されているように、差別化されたサービスフィールドCodePointsレジストリの下でIANAによって管理されます。
The Fragmentation-Flag AVP (AVP Code 536) is of type Enumerated and specifies the packet fragmentation flags to match in the IP header.
Fragmentation-Flag 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-Option 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-Option-Value AVPが存在する場合、値の1つはIPヘッダーオプションの値と一致する必要があります。IP-Option-Value 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-Option-Value AVPと組み合わせて使用され、特定の値と一致しないIPヘッダーオプションを指定します。否定されたAVPは、IP-Option-Value AVPなしで使用され、オプションタイプを含まないIPヘッダーを指定します。
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-Option-Type 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-Value AVP（AVPコード539）はタイプのオクテットストリングで、一致する必要があるオプション値が含まれています。
The TCP-Option AVP (AVP Code 540) is of type Grouped and specifies a TCP header option that must be matched.
TCP-Option 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.
1つ以上のTCP-Option-Value AVPが存在する場合、値の1つはTCPヘッダーオプションの値と一致する必要があります。TCP-Option-Value 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ヘッダーオプションを指定するためにTCP-Option-Value AVPSがAVPSと組み合わせて使用されます。NEGATED AVPは、TCP-Option-Value AVPなしで使用され、オプションタイプを含まないTCPヘッダーを指定します。
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-Option-Type 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-Value AVP（AVPコード542）はタイプのオクテットストリングで、一致する必要があるオプション値が含まれています。
The TCP-Flags AVP (AVP Code 543) is of type Grouped and specifies a set of TCP control flags that must be matched.
TCP-FLAGS 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が存在しないか存在しないがfalseに設定されている場合、TCP-FLAGタイプの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）は、符号なし32型で、一致する必要があるTCP制御フラグタイプを指定します。最初の16ビットは[RFC3168]で定義されたTCPヘッダー形式と一致し、その後の16ビットは未使用です。最初の16ビット内で、ビット0〜3は未使用であり、ビット4〜15は、[RFC3168]で定義されているように、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.
NEGATED AVPは、ICMPコードAVPと組み合わせて使用され、特定の値と一致しないICMPコードを指定します。NEGATED AVPは、ICMPコードAVPなしで使用され、ICMPタイプを含まないICMPヘッダーを指定します。そのため、ICMP-Code AVPが存在する場合、Negarted AVP機能はICMPコードAVPに適用されます。ICMP-Code AVPが存在しない場合、Negrated 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-Option 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-Proto-Type AVP（AVPコード549）はグループ化されたタイプで、カプセル化されたプロトコルタイプを指定します。Eth-Ether-Typeと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-Ether-Type AVP（AVPコード550）は、タイプのオクテットストリングです。値は、一致するパケット内のEtherTypeフィールドの値を含む二重のオクテットです。このAVPは、デジタル、Intel、およびXerox（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）は、タイプのオクテットストリングです。値は、[IEEE802.2]で指定されている802.2 SAPを表す二重のオクテットです。最初のオクテットには、宛先サービスアクセスポイント（DSAP）と2番目のソースサービスアクセスポイント（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-Range AVP（AVPコード552）はグループ化されており、一致するVLAN範囲を指定します。VLANのアイデンティティは、[IEEE802.1Q]に従って単一のVLAN-IDまたは[IEEE802.1AD]による顧客とサービスの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-STARTおよびC-VIDエンドAVPで表され、この場合はS-VID-STARTおよびS-VID-END AVPSを省略するものとします。VLAN-ID-Range 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-START AVPが存在するが、S-VIDエンドAVPが存在しない場合、S-VID-START 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-START 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-STARTとS-VIDエンドAVPの両方が存在し、その値が等しい場合、S-VID-START 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-STARTとS-VID-END AVPの両方が存在し、S-VID-end AVPの値がS-VID-START AVPの値よりも大きい場合、IEEE 802.1AD S-VIDの値ビットは、S-VID-START AVP値以上であり、成功した試合のためにS-VID-END 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.
o S-VID-STARTおよびS-VID-END AVPが省略されている場合、IEEE802.1ADのカプセル化またはIEEE 802.1AD S-VIDビットの比較の存在は、この分類器では無関係です。
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-startとc-vid-end avpの可能な組み合わせのリストとそれらの推論です。oc-vid-start avpが存在するが、c-vid-end avpが存在しない場合、c-はc-VID-START AVP値は、[IEEE802.1AD]で指定されたIEEE 802.1AD C-VIDビットまたは[IEEE802.1Q]で指定されたIEEE 802.1Q VLAN-IDビットの値に等しくなければなりません。
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-START AVPが存在しないが、C-VIDエンドAVPが存在する場合、C-Vid-end 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-STARTとC-VID-END AVPの両方が存在し、その値が等しい場合、C-VID-START 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-END AVPの両方が存在し、C-Vid-end AVPの値がC-VID-START AVPの値よりも大きい場合、IEEE 802.1AD C-VIDの値BITSまたはIEEE 802.1Q VLAN-IDビットは、成功した試合のためにC-VID-START AVP値以上であり、C-VIDエンドAVP値以下でなければなりません。C-VID-STARTおよびC-VID-END 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.
o C-VID-STARTおよびC-VID-END AVPが省略されている場合、この分類器の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-START AVP（AVP Code 553）は、符号なし32です。値は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-end AVP（AVPコード554）は、符号なし32です。値は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-START AVP（AVPコード555）は、符号なし32です。値は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-end AVP（AVPコード556）は、符号なし32です。値は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ユーザー_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）は、signed32のタイプです。値は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）は、signed32のタイプです。値は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）は、グループ化されたタイプで、1つ以上の時間ウィンドウを指定します。
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:
たとえば、午前9時から午後5時までの時間枠（現地時間）月曜日から金曜日まで、次のように表現されます。
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）は、符号なし32です。値は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）は、符号なし32です。値は1から86400の範囲でなければなりません。このAVPの値は、真夜中から数秒でオフセットとして表される包括的時間ウィンドウの終了を指定します。この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）は、signed32のタイプです。値は、タイムウィンドウが一致するように曜日を指定するビットマスクです。このドキュメントは、次のビットを指定します。
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）は、符号なし32です。値は0から2147483647までの範囲でなければなりません。値は、ビット0が月の最初の日を表す月の日を指定するビットマスクです。これは月の最終日を表します。ビットは、その月の対応する日に一致するようにタイムウィンドウに設定する必要があります。ビット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）は、signed32のタイプです。値は、時間ウィンドウが一致する数か月を指定するビットマスクです。このドキュメントは、次のビットを指定します。
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.
Absolute-Start-Time AVP（AVPコード566）はタイプの時間です。このAVPの値は、1900年1月1日以降の時間を数秒で指定します。00:00 UTCは、時間ウィンドウが開始されます。この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）は、符号なし32です。この値は、時間ウィンドウがいつ開始されるかを決定するために、絶対スタート時間値に追加される分数秒を指定します。この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）はタイプの時間です。このAVPの値は、1900年1月1日以来の数秒、00:00 UTCを指定します。この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 Code 569）は、soting32のタイプです。この値は、時間ウィンドウがいつ終了するかを決定するために、絶対時間値に追加される分数秒を指定します。この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.
TimeZone-Flag 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.
TimeZone-Offset AVP（AVPコード571）は、integer32のタイプです。このAVPの値は、-43200〜43200の範囲でなければなりません。これは、UTCからの数秒でオフセットを指定し、日時、日時、週の日を表現するために使用されました。-MASK、月のマスク、および月のマスクAVPS。TimeZone-Flag 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-Parameters AVPには、ルールの条件部分で説明されているトラフィックを形作る方法を示すTMOD-1や帯域幅AVPなどの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 CodePointを設定するプロセス」とマークを記述しています。アクションが「マーク」に設定されている場合、QoS-Parameters AVPには、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-Profile-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-Profile-Template AVP（AVPコード574）はグループ化されたタイプで、QoSプロファイルの名前空間（ベンダー-ID AVPで示されています）を定義し、それに続いてプロファイルの特定の値を定義します。
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-Profile-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-Semantics AVP（AVPコード575）は列挙されており、フィルタールールAVPのQoS-Profile-TemplateおよびQoS-Parameters AVPのセマンティクスを提供します。
This document defines the following values:
このドキュメントは、次の値を定義します。
(0): QoS-Desired
(1): QoS-Available
(2): QoS-Delivered
(3): Minimum-QoS
(4): QoS-Authorized
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
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がこれに示されているQOよりも少ない必要があることをサーバーに示します。
(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-Parameters AVP（AVPコード576）はグループ化されたタイプで、サービスの品質パラメーターが含まれています。これらのパラメーターは、個別のドキュメントで定義されており、QoS-Profile-Template 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-Profile-Template、およびQoS-Parameters 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 profiles between two peers. In such a case, handling of failed negotiations is application and/or deployment specific.
QoSキャピールAVPは、ピアがサポートするQoS機能とQoSプロファイルの簡単な発表に使用できます。また、2つのピア間で相互にサポートされているQoS機能とQoSプロファイルのセットを交渉するためにも使用できます。そのような場合、失敗した交渉の処理は、アプリケーションおよび/または展開固有です。
QoS-Capability ::= < AVP Header: 578 >
1*{ QoS-Profile-Template }
* [ AVP ]
The QoS-Profile-Template AVP is defined in Section 5.3.
QoS-Profile-Template 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アプリケーションのシグナル伝達フローは、[直径-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）（直径クライアント）がDERメッセージに含まれるQOS認識と機能を発表し、アクセス認証手順の一部として発表する単純なシグナル伝達フローを示しています。EAP交換が完了すると、Diameterサーバーは、最終Diameter-Eap-Answer（DEA）のNASに設定されたフィルタールールAVPのQoS-Semanticsを使用して、事前にプロビジョニングされたQoSプロファイルを提供します。メッセージ。
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：QoS情報で強化された直径EAPの例
Figure 3 shows a similar pre-provisioned QoS signaling as in Figure 2 but using the NASREQ application instead of EAP application.
図3は、図2のように同様の事前に生成されたQoSシグナル伝達を示していますが、EAPアプリケーションではなくNASREQアプリケーションを使用しています。
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は、QOSリソースAVPに含まれる「QOSで定められた」QoS-Semantics AVPを直径サーバーに提供します。次に、Diameterサーバーは、指定されたQoSを承認するか、リクエストを拒否し、結果についてNASに通知します。このシナリオでは、NASは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は、直径サーバーが開始したQoSの再承認手順のメッセージ交換を示しています。Diameterサーバーは、NASに既存のセッションの再承認を要求するReauth Request（RAR）メッセージを送信し、NASはRAAメッセージでそれを認めます。NASは、既存の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-Semantics = QoS-Desired）が含まれています。CCサーバーは、クレジットコントロールの回答（CCA）で応答します。これには、認定されたQoS定義（QOS-Semantics = QOS-Authorized）を含む付与されたリソースが含まれ、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-Semantics = QOS-Delivered）。サービスの終了は、ユーザーに付与されたクレジットリソースが使い果たされたか、サービスが正常に配信されたか、サービスが終了したために発生する可能性があります。たとえば、サービス要素が承認された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.
例：サブネット192.0.2.0/24のホストからWebサーバーのポート80、8090、または443にすべてのパケットを分類192.0.2.123、192.0.2.124、192.0.2.125。
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.
例：01：23：45：67：89：ABのMACアドレスを持つデバイスからのSIPシグナリングトラフィック192.0.2.90から192.0.2.190の範囲の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 Mbit/sに制限するルールをインストールする次の例を考えてください。この例では、分類器は無視されます。
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'.
これには、治療アクションAVPを「形状」に設定する必要があり、QoS-Parameters AVPは1 Mbit/sの制限を示す帯域幅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".
2番目のより複雑なシナリオでは、diffservを使用したトラフィックマークを検討します。プロファイルのトラフィック（私たちの例では5 Mbit/s）は、特定の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-Parameters AVPには、TMOD-1 AVPとPHBクラスAVPの2つのAVPが含まれています。TMOD-1 AVPは、トラフィック特性、つまり5 Mbit/s、およびPHBクラスAVPがクラス「X」に設定されていることを説明しています。次に、過剰治療AVPを「MARK」に設定した治療アクションAVPとQOS-Parameters AVPに含めて、PHBクラスAVPの設定をクラス「Y」に示す別のPHBクラス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.
ビクター・ファハルド、ツェノ・ツェノフ、ロバート・ハンコック、ジュッカ・マナー、コーネリア・カプラー、Xiaoming Fu、フランク・アルファノ、トルガ・アスベレン、マイク・モンテムロ、グレン・ゾーン、アヴリ・ドリア、ドン・サン、ティナスエルウィン・デイビス、マックス・リーゲル、ヨン・リー、エリック・グレイのコメントについて。プロトドキュメントシェパードとしての彼の仕事にビクター・ファハルドに感謝します。最後に、IESGレビューフェーズ中のフィードバックについて、ラースエガート、マグナスウェスターランド、エイドリアンファレル、リサデュセー、ラルフドロム、エリックグレイに感謝します。
Max Riegel contributed the VLAN sections.
Max Riegelが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-Semantics 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.
このドキュメントでは、サービス品質情報を伝えるための直径の拡張について説明しています。直径プロトコル自体のセキュリティに関する考慮事項は、RFC 3588 [RFC3588]で議論されています。このドキュメントで定義されているAVPの使用は、直径ベースプロトコルのセキュリティの問題と要件を考慮する必要があります。
[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、「情報技術、電気通信、およびシステム間の情報交換、ローカルおよび大都市圏ネットワーク、特定の要件、パート2：論理リンク制御」、1998年。
[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月。
[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月。
[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] Bradner、S。およびV. Paxson、「インターネットプロトコルおよび関連するヘッダーの価値の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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[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月。
[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] Sun、D.、Ed。、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、ed。、「直径のサービス品質アプリケーション」、Work進行中、2009年10月。
[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月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、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. Davies、「直径の使用のためのサービスの質」、RFC 5624、2009年8月。
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）に従ってデバイスの分類に使用されます。ビットマスクは、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.
MACアドレスビットマスクは、「N」セットビットの連続シリーズシリーズとして定義する必要があります。その後、「48 -N」クリアビットの連続シリーズが続きます。同様に、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 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
Mayutan Arumaithurai University of Goettingen
メイタン・アルムチャチュライ・ゲッティンゲン大学
EMail: 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
Avi Lior Bridgewater Systems 303 Terry Fox Drive, Suite 500 Ottawa, Ontario K2K 3J1 Canada
Avi Lior Bridgewater Systems 303 Terry Fox Drive、Suite 500オタワ、オンタリオK2K 3J1カナダ
Phone: +1 613-591-6655
EMail: avi@bridgewatersystems.com