[要約] RFC 3670は、ネットワークデバイスのQoSデータパスメカニズムを記述するための情報モデルに関するものです。このRFCの目的は、ネットワークデバイスのQoS機能を一貫して記述し、相互運用性を向上させることです。
Network Working Group B. Moore
Request for Comments: 3670 IBM Corporation
Category: Standards Track D. Durham
Intel
J. Strassner
INTELLIDEN, Inc.
A. Westerinen
Cisco Systems
W. Weiss
Ellacoya
January 2004
Information Model for Describing Network Device QoS Datapath Mechanisms
ネットワークデバイスQoSデータパスメカニズムを説明するための情報モデル
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services.
このドキュメントの目的は、ホストを含むさまざまなネットワークデバイスに固有のサービス品質（QOS）メカニズムを記述する情報モデルを定義することです。大まかに言えば、これらのメカニズムは、ネットワークデバイスの転送パス（DataPath）を介してトラフィックの選択と条件付けに共通するプロパティを説明しています。DataPathでのトラフィックのこの選択と条件付けは、差別化されたサービスと統合サービスの両方の主要なQoSアーキテクチャの両方に及びます。
This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.
このドキュメントは、QoSポリシー情報モデル（QPIM）で使用して、QoSメカニズム（つまり、分類、マーキング、メーター、ドロップ、キューイング、スケジューリング機能）を管理および構成するためのポリシーをモデル化する方法をモデル化する必要があります。一緒に、これらの2つのドキュメントは、デバイスのデータパスに存在するQoSメカニズムを構成および管理するためのQoSポリシールールを作成する方法について説明します。
This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository.
このドキュメントとQPIMは情報モデルです。つまり、特定のタイプのリポジトリへの拘束力とは無関係の情報を表しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Policy Management Conceptual Model . . . . . . . . . . . 6
1.2. Purpose and Relation to Other Policy Work. . . . . . . . 7
1.3. Typical Examples of Policy Usage . . . . . . . . . . . . 7
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Common Needs Of DiffServ and IntServ . . . . . . . . . . 8
2.2. Specific Needs Of DiffServ . . . . . . . . . . . . . . . 9
2.3. Specific Needs Of IntServ. . . . . . . . . . . . . . . . 9
3. Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Level of Abstraction for Expressing QoS Policies . . . . 10
3.2. Specifying Policy Parameters . . . . . . . . . . . . . . 11
3.3. Specifying Policy Services . . . . . . . . . . . . . . . 12
3.4. Level of Abstraction for Defining QoS Attributes and
Classes. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Characterization of QoS Properties . . . . . . . . . . . 14
3.6. QoS Information Model Derivation . . . . . . . . . . . . 15
3.7. Attribute Representation . . . . . . . . . . . . . . . . 16
3.8. Mental Model . . . . . . . . . . . . . . . . . . . . . . 17
3.8.1. The QoSService Class . . . . . . . . . . . . . . 17
3.8.2. The ConditioningService Class. . . . . . . . . . 18
3.8.3. Preserving QoS Information from Ingress to
Egress . . . . . . . . . . . . . . . . . . . . . 19
3.9. Classifiers, FilterLists, and Filter Entries . . . . . . 21
3.10. Modeling of Droppers . . . . . . . . . . . . . . . . . . 23
3.10.1. Configuring Head and Tail Droppers . . . . . . . 23
3.10.2. Configuring RED Droppers . . . . . . . . . . . . 24
3.11. Modeling of Queues and Schedulers. . . . . . . . . . . . 25
3.11.1. Simple Hierarchical Scheduler. . . . . . . . . . 25
3.11.2. Complex Hierarchical Scheduler . . . . . . . . . 27
3.11.3. Excess Capacity Scheduler. . . . . . . . . . . . 29
3.11.4. Hierarchical CBQ Scheduler . . . . . . . . . . . 31
4. The Class Hierarchy. . . . . . . . . . . . . . . . . . . . . . 33
4.1. Associations and Aggregations. . . . . . . . . . . . . . 33
4.2. The Structure of the Class Hierarchies . . . . . . . . . 34
4.3. Class Definitions. . . . . . . . . . . . . . . . . . . . 38
4.3.1. The Abstract Class ManagedElement. . . . . . . . 38
4.3.2. The Abstract Class ManagedSystemElement. . . . . 39
4.3.3. The Abstract Class LogicalElement. . . . . . . . 39
4.3.4. The Abstract Class Service . . . . . . . . . . . 39
4.3.5. The Class ConditioningService. . . . . . . . . . 39
4.3.6. The Class ClassifierService. . . . . . . . . . . 40
4.3.7. The Class ClassifierElement. . . . . . . . . . . 41
4.3.8. The Class MeterService . . . . . . . . . . . . . 42
4.3.9. The Class AverageRateMeterService. . . . . . . . 44
4.3.10. The Class EWMAMeterService . . . . . . . . . . . 44
4.3.11. The Class TokenBucketMeterService. . . . . . . . 46
4.3.12. The Class MarkerService. . . . . . . . . . . . . 47
4.3.13. The Class PreambleMarkerService. . . . . . . . . 47
4.3.14. The Class ToSMarkerService . . . . . . . . . . . 48
4.3.15. The Class DSCPMarkerService. . . . . . . . . . . 49
4.3.16. The Class 8021QMarkerService . . . . . . . . . . 49
4.3.17. The Class DropperService . . . . . . . . . . . . 50
4.3.18. The Class HeadTailDropperService . . . . . . . . 52
4.3.19. The Class REDDropperService. . . . . . . . . . . 52
4.3.20. The Class QueuingService . . . . . . . . . . . . 54
4.3.21. The Class PacketSchedulingService. . . . . . . . 55
4.3.22. The Class NonWorkConservingSchedulingService . . 56
4.3.23. The Class QoSService . . . . . . . . . . . . . . 57
4.3.24. The Class DiffServService. . . . . . . . . . . . 58
4.3.25. The Class AFService. . . . . . . . . . . . . . . 59
4.3.26. The Class FlowService. . . . . . . . . . . . . . 60
4.3.27. The Class DropThresholdCalculationService. . . . 60
4.3.28. The Abstract Class FilterEntryBase . . . . . . . 61
4.3.29. The Class IPHeaderFilter . . . . . . . . . . . . 62
4.3.30. The Class 8021Filter . . . . . . . . . . . . . . 62
4.3.31. The Class PreambleFilter . . . . . . . . . . . . 62
4.3.32. The Class FilterList . . . . . . . . . . . . . . 63
4.3.33. The Abstract Class ServiceAccessPoint. . . . . . 63
4.3.34. The Class ProtocolEndpoint . . . . . . . . . . . 63
4.3.35. The Abstract Class Collection. . . . . . . . . . 65
4.3.36. The Abstract Class CollectionOfMSEs. . . . . . . 65
4.3.37. The Class BufferPool . . . . . . . . . . . . . . 65
4.3.38. The Abstract Class SchedulingElement . . . . . . 65
4.3.39. The Class AllocationSchedulingElement. . . . . . 66
4.3.40. The Class WRRSchedulingElement . . . . . . . . . 67
4.3.41. The Class PrioritySchedulingElement. . . . . . . 69
4.3.42. The Class BoundedPrioritySchedulingElement . . . 70
4.4. Association Definitions. . . . . . . . . . . . . . . . . 70
4.4.1. The Abstract Association Dependency. . . . . . . 71
4.4.2. The Association ServiceSAPDependency . . . . . . 71
4.4.3. The Association
IngressConditioningServiceOnEndpoint . . . . . . 71
4.4.4. The Association
EgressConditioningServiceOnEndpoint. . . . . . . 72
4.4.5. The Association HeadTailDropQueueBinding . . . . 72
4.4.6. The Association CalculationBasedOnQueue. . . . . 73
4.4.7. The Association ProvidesServiceToElement . . . . 74
4.4.8. The Association ServiceServiceDependency . . . . 74
4.4.9. The Association CalculationServiceForDropper . . 75
4.4.10. The Association QueueAllocation. . . . . . . . . 75
4.4.11. The Association ClassifierElementUsesFilterList. 76
4.4.12. The Association AFRelatedServices. . . . . . . . 77
4.4.13. The Association NextService. . . . . . . . . . . 78
4.4.14. The Association
NextServiceAfterClassifierElement. . . . . . . . 79
4.4.15. The Association NextScheduler. . . . . . . . . . 80
4.4.16. The Association FailNextScheduler. . . . . . . . 81
4.4.17. The Association NextServiceAfterMeter. . . . . . 82
4.4.18. The Association QueueToSchedule. . . . . . . . . 83
4.4.19. The Association SchedulingServiceToSchedule. . . 84
4.4.20. The Aggregation MemberOfCollection . . . . . . . 85
4.4.21. The Aggregation CollectedBufferPool. . . . . . . 85
4.4.22. The Abstract Aggregation Component . . . . . . . 86
4.4.23. The Aggregation ServiceComponent . . . . . . . . 86
4.4.24. The Aggregation QoSSubService. . . . . . . . . . 86
4.4.25. The Aggregation QoSConditioningSubService. . . . 87
4.4.26. The Aggregation
ClassifierElementInClassifierService . . . . . . 88
4.4.27. The Aggregation EntriesInFilterList. . . . . . . 89
4.4.28. The Aggregation ElementInSchedulingService . . . 90
5. Intellectual Property Statement. . . . . . . . . . . . . . . . 91
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 91
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.1. Normative References. . . . . . . . . . . . . . . . . . . 92
8.2. Informative References . . . . . . . . . . . . . . . . . 92
9. Appendix A: Naming Instances in a Native CIM Implementation . 94
9.1. Naming Instances of the Classes Derived from Service. . . 94
9.2. Naming Instances of Subclasses of FilterEntryBase . . . . 94
9.3. Naming Instances of ProtocolEndpoint. . . . . . . . . . . 94
9.4. Naming Instances of BufferPool. . . . . . . . . . . . . . 95
9.4.1. The Property CollectionID. . . . . . . . . . . . 95
9.4.2. The Property CreationClassName . . . . . . . . . 95
9.5. Naming Instances of SchedulingElement . . . . . . . . . . 95
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 96
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 97
The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services (see [R2475]) and Integrated Services (see [R1633]).
このドキュメントの目的は、ホストを含むさまざまなネットワークデバイスに固有のサービス品質（QOS）メカニズムを記述する情報モデルを定義することです。大まかに言えば、これらのメカニズムは、ネットワークデバイスの転送パス（DataPath）を介したトラフィックの選択とコンディショニングに共通する属性を説明しています。DataPathのトラフィックのこの選択と条件付けは、主要なQoSアーキテクチャの両方に及びます。差別化されたサービス（[R2475]を参照）と統合サービス（[R1633]を参照）です。
This document is intended to be used with the QoS Policy Information Model [QPIM] to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.
このドキュメントは、QoSポリシー情報モデル[QPIM]で使用することを目的としており、デバイスのQoSメカニズム（つまり、分類、計量、メータリング、ドロップ、キュー、スケジューリング機能）を管理および構成するためにポリシーを定義する方法をモデル化することを目的としています。。一緒に、これらの2つのドキュメントは、デバイスのデータパスに存在するQoSメカニズムを構成および管理するためのQoSポリシールールを作成する方法について説明します。
This document, as well as [QPIM], are information models. That is, they represent information independent of a binding to a specific type of repository. A separate document could be written to provide a mapping of the data contained in this document to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. Similarly, a document could be written to provide a mapping of the data in [QPIM] to a directory. Together, these four documents (information models and directory schema mappings) would then describe how to write QoS policy rules that can be used to store information in directories to configure device QoS mechanisms.
このドキュメントと[QPIM]は情報モデルです。つまり、特定のタイプのリポジトリへの拘束力とは無関係の情報を表しています。このドキュメントに含まれるデータのマッピングを、アクセスプロトコルとして（L）DAPを使用するディレクトリでの実装に適したフォームに提供するために、別のドキュメントを作成できます。同様に、ドキュメントを作成して、[QPIM]のデータのマッピングをディレクトリに提供できます。これらの4つのドキュメント（情報モデルとディレクトリスキーママッピング）は、デバイスQoSメカニズムを構成するためにディレクトリに情報を保存するために使用できるQoSポリシールールを作成する方法について説明します。
The approach taken in this document defines a common set of classes that can be used to model QoS in a device datapath. Vendors can then map these classes, either directly or using an intervening format like a COP-PR PIB, to their own device-specific implementations. Note that the admission control element of Integrated Services is not included in the scope of this model.
このドキュメントで採用されたアプローチは、デバイスデータパス内のQOをモデル化するために使用できる共通のクラスセットを定義します。ベンダーは、これらのクラスを直接マップするか、COP-PR PIBなどの介在形式を使用して、独自のデバイス固有の実装にマッピングできます。統合サービスの入場制御要素は、このモデルの範囲に含まれていないことに注意してください。
The design of the class, association, and aggregation hierarchies described in this document is influenced by the Network QoS submodel defined by the Distributed Management Task Force (DMTF) - see [CIM]. These hierarchies are not derived from the Policy Core Information Model [PCIM]. This is because the modeling of the QoS mechanisms of a device is separate and distinct from the modeling of policies that manage those mechanisms. Hence, there is a need to separate QoS mechanisms (this document) from their control (specified using the generic policy document [PCIM] augmented by the QoS Policy document [QPIM]).
このドキュメントで説明されているクラス、関連性、および集約階層の設計は、分散管理タスクフォース（DMTF）によって定義されたネットワークQoSサブモデルの影響を受けます。[CIM]を参照してください。これらの階層は、ポリシーコア情報モデル[PCIM]から派生したものではありません。これは、デバイスのQoSメカニズムのモデリングが、それらのメカニズムを管理するポリシーのモデリングとは別に異なるためです。したがって、QoSメカニズム（このドキュメント）を制御（QoSポリシードキュメント[QPIM]によって補強された一般的なポリシードキュメント[PCIM]を使用して指定）から分離する必要があります。
While it is not a policy model per se, this document does have a dependency on the Policy Core Information Model Extensions document [PCIME]. The device-level packet filtering, through which a Classifier splits a traffic stream into multiple streams, is based on the FilterEntryBase and FilterList classes defined in [PCIME].
それ自体はポリシーモデルではありませんが、このドキュメントはポリシーコア情報モデル拡張ドキュメント[PCIME]に依存しています。分類器がトラフィックストリームを複数のストリームに分割するデバイスレベルのパケットフィルタリングは、[PCIME]で定義されたFilterEntryBaseおよびFilterListクラスに基づいています。
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 BCP 14, RFC 2119 [R2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [R2119]に記載されているように解釈される。
The Policy Core Information Model [PCIM] describes a general methodology for constructing policy rules. PCIM Extensions [PCIME] updates and extends the original PCIM. A policy rule aggregates a set of policy conditions and an ordered set of policy actions. The semantics of a policy rule are such that if the set of conditions evaluates to TRUE, then the set of actions are executed.
ポリシーコア情報モデル[PCIM]は、ポリシールールを構築するための一般的な方法論を説明しています。PCIM拡張[PCIME]は、元のPCIMを更新および拡張します。ポリシールールは、一連のポリシー条件と順序付けられたポリシーアクションセットを集約します。ポリシールールのセマンティクスは、一連の条件がTrueに評価された場合、一連のアクションが実行されるようなものです。
Policy conditions and actions have two principal components: operands and operators. Operands can be constants or variables. To specify a policy, it is necessary to specify:
ポリシー条件とアクションには、オペランドとオペレーターの2つの主要コンポーネントがあります。オペランドは、定数または変数にすることができます。ポリシーを指定するには、指定する必要があります。
o the operands to be examined (also known as state variables);
o 検査されるオペランド（状態変数とも呼ばれます）;
o the operands to be changed (also known as configuration variables);
o 変更するオペランド（構成変数とも呼ばれます）;
o the relationships between these two sets of operands.
o オペランドのこれら2つのセット間の関係。
Operands can be specified at a high-level, such as Joe (a user) or Gold (a service). Operands can also be specified at a much finer level of detail, one that is much closer to the operation of the device. Examples of the latter include an IP Address or a queue's bandwidth allocation. Implicit in the use of operands is the binding of legal values or ranges of values to an operand. For example, the value of an IP address cannot be an integer. The concepts of operands and their ranges are defined in [PCIME].
オペランドは、Joe（ユーザー）やゴールド（サービス）などの高レベルで指定できます。オペランドは、より細かいレベルの詳細で指定することもできます。これは、デバイスの動作にはるかに近いものです。後者の例には、IPアドレスまたはキューの帯域幅割り当てが含まれます。オペランドの使用における暗黙的なのは、法的価値または値の範囲のオペランドへの範囲の拘束力です。たとえば、IPアドレスの値は整数ではありません。オペランドとその範囲の概念は[PCIME]で定義されています。
The second component of policy conditions and actions is a set of operators. Operators can express both relationships (greater than, member of a set, Boolean OR, etc.) and assignments. Together, operators and operands can express a variety of conditions and actions, such as:
ポリシー条件とアクションの2番目のコンポーネントは、オペレーターのセットです。オペレーターは、両方の関係（セットのメンバーよりも大きい、ブール値など）と割り当てを表現できます。一緒に、オペレーターとオペランドは、次のようなさまざまな条件やアクションを表現できます。
If Bob is an Engineer... If the source IP address is in the Marketing Subnet... Set Joe's IP address to 192.0.2.100 Limit the bandwidth of application x to 10 Mb
ボブがエンジニアの場合...ソースIPアドレスがマーケティングサブネットにある場合... JoeのIPアドレスを192.0.2.100に設定します。アプリケーションXの帯域幅を10 MBに制限します
We recognize that the definition of operator semantics is critical to the definition of policies. However, the definition of these operators is beyond the scope of this document. Rather, this document (with [QPIM]) takes the first steps in identifying and standardizing a set of properties (operands) for use in defining policies for Differentiated and Integrated Services.
オペレーターのセマンティクスの定義は、ポリシーの定義にとって重要であることを認識しています。ただし、これらの演算子の定義は、このドキュメントの範囲を超えています。むしろ、このドキュメント（[QPIM]を使用）は、差別化されたサービスと統合サービスのポリシーを定義する際に使用するために、一連のプロパティ（オペランド）を特定して標準化するための第一歩を踏み出します。
This model establishes a canonical model of the QoS mechanisms of a network device (e.g., a router, switch, or host) that is independent of any specific type of network device. This enables traffic conditioning to be described using a common set of abstractions, modeled as a set of services and sub-services.
このモデルは、特定のタイプのネットワークデバイスとは無関係のネットワークデバイス（例：ルーター、スイッチ、またはホストなど）のQOSメカニズムの標準モデルを確立します。これにより、一連のサービスとサブサービスとしてモデル化された抽象化の一般的なセットを使用して、トラフィックコンディショニングを説明できます。
When the concepts of this document are used in conjunction with the concepts of [QPIM], one is able to define policies that bind the services in a network to the needs of applications using that network. In other words, the business requirements of an organization can be reflected in one set of policies, and those policies can be translated to a lower-level set of policies that control and manage the configuration and operation of network devices.
このドキュメントの概念が[QPIM]の概念と組み合わせて使用される場合、ネットワーク内のサービスをそのネットワークを使用してアプリケーションのニーズに拘束するポリシーを定義することができます。言い換えれば、組織のビジネス要件は1つのポリシーセットに反映される可能性があり、それらのポリシーは、ネットワークデバイスの構成と操作を制御および管理する低レベルのポリシーセットに変換できます。
Policies could be implemented as low-level rules using the information model described in this specification. For example, in a low-level policy, a condition could be represented as an evaluation of a specific attribute from this model. Therefore, a condition such as "If filter = HTTP" would be interpreted as a test determining whether any HTTP filters have been defined for the device. A high-level policy, such as "If protocol = HTTP, then mark with Differentiated Services Code Point (DSCP) 24," would be expressed as a series of actions in a low-level policy using the classes and attributes described below:
この仕様で説明されている情報モデルを使用して、ポリシーを低レベルのルールとして実装できます。たとえば、低レベルのポリシーでは、このモデルからの特定の属性の評価として条件を表すことができます。したがって、「Filter = HTTP」などの条件は、デバイスに対してHTTPフィルターが定義されているかどうかを決定するテストとして解釈されます。「protocol = httpの場合、差別化されたサービスコードポイント（DSCP）24でマークする」などの高レベルポリシーは、以下に説明するクラスと属性を使用して、低レベルポリシーの一連のアクションとして表現されます。
1. Create HTTP filter 2. Create DSCP marker with the value of 24 3. Bind the HTTP filter to the DSCP marker
1. HTTPフィルターの作成2. 24の値でDSCPマーカーを作成します3. HTTPフィルターをDSCPマーカーにバインドします
Note that unlike "mark with DSCP 24," these low-level actions are not performed on a packet as it passes through the device. Rather, they are configuration actions performed on the device itself, to make it ready to perform the correct action(s) on the correct packet(s). The act of moving from a high-level policy rule to the correct set of low-level device configuration actions is an example of what [POLTERM] characterizes as "policy translation" or "policy conversion".
「DSCP 24のマーク」とは異なり、これらの低レベルのアクションは、デバイスを通過するときにパケットで実行されないことに注意してください。むしろ、それらはデバイス自体で実行された構成アクションであり、正しいパケットで正しいアクションを実行する準備ができています。高レベルのポリシールールから低レベルのデバイス構成アクションの正しいセットに移行する行為は、[Polterm]が「ポリシー翻訳」または「ポリシー変換」と特徴付けていることの例です。
QoS activities in the IETF have mainly focused in two areas, Integrated Services (IntServ) and Differentiated Services (DiffServ) (see [POLTERM], [R1633] and [R2475]). This document focuses on the specification of QoS properties and classes for modeling the datapath where packet traffic is conditioned. However, the framework defined by the classes in this document has been designed with the needs of the admission control portion of IntServ in mind as well.
IETFのQoSアクティビティは、主に統合サービス（INTSERV）と差別化されたサービス（DIFFSERV）の2つの領域に焦点を当てています（[Polterm]、[R1633]、[R2475]を参照）。このドキュメントは、パケットトラフィックが条件付けられているデータパスをモデル化するためのQoSプロパティとクラスの仕様に焦点を当てています。ただし、このドキュメントのクラスで定義されたフレームワークは、IntServの入場制御部分のニーズを念頭に置いて設計されています。
First, let us consider IntServ. IntServ has two principal components. One component is embedded in the datapath of the networking device. Its functions include the classification and policing of individual flows, and scheduling admitted packets for the outbound link. The other component of IntServ is admission control, which focuses on the management of the signaling protocol (e.g., the PATH and RESV messages of RSVP). This component processes reservation requests, manages bandwidth, outsources decision making to policy servers, and interacts with the Routing Table manager.
まず、intservを考えてみましょう。IntServには2つの主成分があります。1つのコンポーネントは、ネットワークデバイスのデータパスに埋め込まれています。その機能には、個々のフローの分類とポリシング、およびアウトバウンドリンクの入場パケットのスケジューリングが含まれます。INTSERVのもう1つのコンポーネントは、シグナル伝達プロトコルの管理（たとえば、RSVPのRESVメッセージ）の管理に焦点を当てたアミズミコントロールです。このコンポーネントは、予約要求を処理し、帯域幅を管理し、ポリシーサーバーに意思決定を外部委託し、ルーティングテーブルマネージャーと対話します。
We will consider RSVP when defining the structure of this information model. As this document focuses on the datapath, elements of RSVP applicable to the datapath will be considered in the structure of the classes. The complete IntServ device model will, as we have indicated earlier, be addressed in a subsequent document.
この情報モデルの構造を定義する際には、RSVPを検討します。このドキュメントがデータパスに焦点を当てているため、データパスに適用されるRSVPの要素がクラスの構造で考慮されます。完全なIntServデバイスモデルは、前述のように、後続のドキュメントで対処されます。
This document models a small subset of the QoS policy problem, in hopes of constructing a methodology that can be adapted for other aspects of QoS in particular, and of policy construction in general. The focus in this document is on QoS for devices that implement traffic conditioning in the datapath.
このドキュメントは、特にQoSの他の側面、および一般的な政策構築の方法に適合させることができる方法論を構築することを期待して、QoSポリシー問題の小さなサブセットをモデル化しています。このドキュメントの焦点は、データパスにトラフィックコンディショニングを実装するデバイスのQoSにあります。
DiffServ operates exclusively in the datapath. It has all of the same components of the IntServ datapath, with two major differences. First, DiffServ classifies packets based solely on their DSCP field, whereas IntServ examines a subset of a standard flow's addressing 5- tuple. The exception to this rule occurs in a router or host at the boundary of a DiffServ domain. A device in this position may examine a packet's DSCP, its addressing 5-tuple, other fields in the packet, or even information wholly outside the packet, in determining the DSCP value with which to mark the packet prior to its transfer into the DiffServ domain. However, routers in the interior of a DiffServ domain will only need to classify based on the DSCP field.
DiffServは、データパスでのみ動作します。IntServ Datapathのすべての同じコンポーネントがあり、2つの大きな違いがあります。まず、DIFSERVはDSCPフィールドのみに基づいたパケットを分類しますが、IntServは標準フローのアドレス指定5タプルのサブセットを調べます。このルールの例外は、diffservドメインの境界にあるルーターまたはホストで発生します。この位置のデバイスは、パケットのDSCP、パケット内の5タプル、その他のフィールド、さらにはパケットの外側に完全に外側にある情報を調べることができます。。ただし、DiffServドメインの内部のルーターは、DSCPフィールドに基づいて分類するだけです。
The second difference between IntServ and DiffServ is that the signaling protocol used in IntServ (e.g., RSVP) affects the configuration of the datapath in a more dynamic fashion. This is because each newly admitted RSVP reservation requires a reconfiguration of the datapath. In contrast, DiffServ requires far fewer changes to the datapath after the Per Hop Behaviors (PHBs) have been configured.
IntServとdiffServの2番目の違いは、IntServ（RSVPなど）で使用されるシグナル伝達プロトコルが、より動的な方法でデータパスの構成に影響することです。これは、新しく認められた各RSVP予約には、データパスの再構成が必要なためです。対照的に、DIFFSERVは、PERホップの動作（PHB）が構成された後、データパスへの変更がはるかに少ない必要があります。
The approach advocated in this document for the creation of policies that control the various QoS mechanisms of networking devices is to first identify the attributes with which policies are to be constructed. These attributes are the parameters used in expressions that are necessary to construct policies. There is also a parallel desire to define the operators, relations, and precedence constructs necessary to construct the conditions and actions that constitute these policies. However, these efforts are beyond the scope of this document.
ネットワーキングデバイスのさまざまなQoSメカニズムを制御するポリシーの作成に関するこのドキュメントで提唱されたアプローチは、最初にポリシーを構築する属性を特定することです。これらの属性は、ポリシーを構築するために必要な式で使用されるパラメーターです。また、これらのポリシーを構成する条件とアクションを構築するために必要なオペレーター、関係、および優先順位構成を定義するという並行した欲求もあります。ただし、これらの努力はこのドキュメントの範囲を超えています。
DiffServ-specific rules focus on two particular areas: the core and the edges of the network. As explained in the DiffServ Architecture document [R2475], devices at the edge of the network classify traffic into different traffic streams. The core of the network then forwards traffic from different streams by using a set of Per Hop Behaviors (PHBs). A DSCP identifies each PHB. The DSCP is part of the IP header of each packet (as described in [R2474]). This enables multiple traffic streams to be aggregated into a small number of aggregated traffic streams, where each aggregate traffic stream is identified by a particular DSCP, and forwarded using a particular PHB.
DiffServ固有のルールは、ネットワークのコアとエッジの2つの特定の領域に焦点を当てています。DiffServアーキテクチャドキュメント[R2475]で説明されているように、ネットワークの端にあるデバイスは、トラフィックをさまざまなトラフィックストリームに分類します。ネットワークのコアは、一連のホップ動作（PHB）を使用して、さまざまなストリームからトラフィックを転送します。DSCPは各PHBを識別します。DSCPは、各パケットのIPヘッダーの一部です（[R2474]で説明されています）。これにより、複数のトラフィックストリームを少数の集約されたトラフィックストリームに集約し、各集計トラフィックストリームが特定のDSCPによって識別され、特定のPHBを使用して転送されます。
The attributes used to manipulate QoS capabilities in the core of the network primarily address the behavioral characteristics of each supported PHB. At the edges of the DiffServ network, the additional complexities of flow classification, policing, RSVP mappings, remarkings, and other factors have to be considered. Additional modeling will be required in this area. However, first, the standards for edges of the DiffServ network need more detail - to allow the edges to be incorporated into the policy model.
ネットワークのコアのQOS機能を操作するために使用される属性は、主にサポートされている各PHBの行動特性に対処します。DiffServネットワークのエッジでは、フロー分類、ポリシング、RSVPマッピング、発言、およびその他の要因の追加の複雑さを考慮する必要があります。この分野では、追加のモデリングが必要です。ただし、最初に、DiffServネットワークのエッジの標準には、エッジをポリシーモデルに組み込むために、より詳細な詳細が必要です。
This document focuses exclusively on the forwarding aspects of network QoS. Therefore, while the forwarding aspects of IntServ are considered, the management of IntServ is not considered. This topic will be addressed in a future document.
このドキュメントは、ネットワークQoSの転送の側面のみに焦点を当てています。したがって、INTSERVの転送の側面を考慮しますが、INTSERVの管理は考慮されません。このトピックは、将来のドキュメントで説明されます。
There is a clear need to define attributes and behavior that together define how traffic should be conditioned. This document defines a set of classes and relationships that represent the QoS mechanisms used to condition traffic; [QPIM] is used to define policies to control the QoS mechanisms defined in this document.
トラフィックの条件付け方法を一緒に定義する属性と動作を定義する必要性が明確です。このドキュメントは、トラフィックを条件付けるために使用されるQoSメカニズムを表すクラスと関係のセットを定義します。[QPIM]は、このドキュメントで定義されているQOSメカニズムを制御するポリシーを定義するために使用されます。
However, some very basic issues need to be considered when combining these documents. Considering these issues should help in constructing a schema for managing the operation and configuration of network QoS mechanisms through the use of QoS policies.
ただし、これらのドキュメントを組み合わせる際には、いくつかの非常に基本的な問題を考慮する必要があります。これらの問題を考慮すると、QoSポリシーを使用してネットワークQoSメカニズムの操作と構成を管理するためのスキーマの構築に役立ちます。
The first issue requiring consideration is the level of abstraction at which QoS policies should be expressed. If we consider policies as a set of rules used to react to events and manipulate attributes or generate new events, we realize that policy represents a continuum of specifications that relate business goals and rules to the conditioning of traffic done by a device or a set of devices. An example of a business level policy might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the network capacity on the open market. In contrast, a device-specific policy might be: if the queue depth grows at a geometric rate over a specified duration, trigger a potential link failure event.
考慮事項を必要とする最初の問題は、QoSポリシーを表現する必要がある抽象化のレベルです。ポリシーを、イベントに反応し、属性を操作したり、新しいイベントを生成するために使用される一連のルールを考慮した場合、ポリシーは、ビジネスの目標とルールをデバイスまたは一連のトラフィックの条件付けに関連付ける仕様の連続体を表していることを認識しています。デバイス。事業レベルのポリシーの例は、PST 1:00 PSTからESTの午前7時から午前7時まで、公開市場のネットワーク容量の40％を売却します。対照的に、デバイス固有のポリシーは次のとおりです。指定された期間にわたってキューの深さが幾何学的な速度で増加した場合、潜在的なリンク障害イベントをトリガーします。
A general model for this continuum is shown in Figure 1 below.
この連続体の一般的なモデルを以下の図1に示します。
+---------------------+
| High-Level Business | Not directly related to device
| Policies | operation and configuration details
+---------------------+
|
|
+---------V-----------+
| Device-Independent | Translate high-level policies to
| Policies | generic device operational and
+---------------------+ configuration information
|
|
+---------V-----------+
| Device-Dependent | Translate generic device information
| Policies | to specify how particular devices
+---------------------+ should operate and be configured
Figure 1. The Policy Continuum High-level business policies are used to express the requirements of the different applications, and prioritize which applications get "better" treatment when the network is congested. The goal, then, is to use policies to relate the operational and configuration needs of a device directly to the business rules that the network administrator is trying to implement in the network that the device belongs to.
図1.ポリシーの連続体の高レベルのビジネスポリシーを使用して、さまざまなアプリケーションの要件を表現し、ネットワークが混雑しているときにどのアプリケーションが「より良い」扱いを受けるかを優先します。したがって、目標は、ポリシーを使用して、デバイスの運用および構成のニーズを、ネットワーク管理者がデバイスが属するネットワークに実装しようとしているビジネスルールに直接関連付けることです。
Device-independent policies translate business policies into a set of generalized operational and configuration policies that are independent of any specific device, but dependent on a particular set of QoS mechanisms, such as random early detection (RED) dropping or weighted round robin scheduling. Not only does this enable different types of devices (routers, switches, hosts, etc.) to be controlled by QoS policies, it also enables devices made by different vendors that use the same types of QoS mechanisms to be controlled. This enables these different devices to each supply the correct relative conditioning to the same type of traffic.
デバイスに依存しないポリシーは、ビジネスポリシーを、特定のデバイスから独立しているが、ランダムな早期検出（赤）ドロップまたは重み付きラウンドロビンスケジューリングなどの特定のQoSメカニズムのセットに依存する一連の一般化された運用および構成ポリシーに変換します。これにより、さまざまなタイプのデバイス（ルーター、スイッチ、ホストなど）がQoSポリシーによって制御されることができるだけでなく、同じタイプのQoSメカニズムを使用するさまざまなベンダーによって作成されたデバイスを制御することもできます。これにより、これらの異なるデバイスがそれぞれ同じタイプのトラフィックに正しい相対コンディショニングを提供することができます。
In contrast, device-dependent policies translate device-independent policies into ones that are specific for a given device. The reason that a distinction is made between device-independent and device-dependent policies is that in a given network, many different devices having many different capabilities need to be controlled together. Device-independent policies provide a common layer of abstraction for managing multiple devices of different capabilities, while device-dependent policies implement the specific conditioning that is required. This document provides a common set of abstractions for representing QoS mechanisms in a device-independent way.
対照的に、デバイスに依存するポリシーは、デバイスに依存しないポリシーを、特定のデバイスに固有のポリシーに変換します。デバイスに依存しないポリシーとデバイスに依存するポリシーを区別する理由は、特定のネットワークでは、多くの異なる機能を持つ多くの異なるデバイスを一緒に制御する必要があるためです。デバイスに依存しないポリシーは、異なる機能の複数のデバイスを管理するための抽象化の一般的な層を提供しますが、デバイス依存ポリシーは必要な特定の条件付けを実装します。このドキュメントは、QoSメカニズムをデバイスに依存しない方法で表現するための共通の抽象化のセットを提供します。
This document is focused on the device-independent representation of QoS mechanisms. QoS mechanisms are modeled in sufficient detail to provide a common device-independent representation of QoS policies. They can also be used to provide a basis for specialization, enabling each vendor to derive a set of vendor-specific classes that represent how traffic conditioning is done for that vendor's set of devices.
このドキュメントは、QoSメカニズムのデバイスに依存しない表現に焦点を当てています。QoSメカニズムは、QoSポリシーの一般的なデバイスに依存しない表現を提供するのに十分な詳細でモデル化されています。また、各ベンダーがそのベンダーのデバイスのセットでトラフィックコンディショニングが行われる方法を表す一連のベンダー固有のクラスを導き出すことができるようにするために、専門化の基礎を提供することもできます。
Policies are a function of parameters (attributes) and operators (boolean, arithmetic, relational, etc.). Therefore, both need to be defined as part of the same policy in order to correctly condition the traffic. If the parameters of the policy are specified too narrowly, they will reflect the individual implementations of QoS in each device. As there is currently little consensus in the industry on what the correct implementation model for QoS is, most defined attributes would only be applicable to the unique characteristics of a few individual devices. Moreover, standardizing all of these potential implementation alternatives would be a never-ending task as new implementations continued to appear on the market.
ポリシーは、パラメーター（属性）と演算子（ブール、算術、リレーショナルなど）の関数です。したがって、トラフィックを正しく調整するために、両方とも同じポリシーの一部として定義する必要があります。ポリシーのパラメーターがあまりにも狭く指定されている場合、それらは各デバイスでのQoSの個々の実装を反映します。現在、業界ではQOSの正しい実装モデルが何であるかについてはほとんどコンセンサスがないため、ほとんどの定義された属性は、いくつかの個別のデバイスのユニークな特性にのみ適用できます。さらに、これらの潜在的な実装の代替案のすべてを標準化することは、新しい実装が市場に登場し続けているため、終わりのないタスクになります。
On the other hand, if the parameters of the policy are specified too broadly, it is impossible to develop meaningful policies. For example, if we concentrate on the so-called Olympic set of policies, a business policy like "Bob gets Gold Service," is clearly meaningless to the large majority of existing devices. This is because the device has no way of determining who Bob is, or what QoS mechanisms should be configured in what way to provide Gold service.
一方、ポリシーのパラメーターがあまりにも広く指定されている場合、意味のあるポリシーを開発することは不可能です。たとえば、いわゆるオリンピックのポリシーセットに集中すると、「ボブゲットゴールドサービス」のようなビジネスポリシーは、既存のデバイスの大部分にとって明らかに無意味です。これは、デバイスにボブが誰であるか、またはどのQoSメカニズムをゴールドサービスを提供する方法で構成すべきかを決定する方法がないためです。
Furthermore, Gold service may represent a single service, or it may identify a set of services that are related to each other. In the latter case, these services may have different conditioning characteristics.
さらに、ゴールドサービスは単一のサービスを表す場合があります。または、互いに関連するサービスのセットを特定する場合があります。後者の場合、これらのサービスには異なるコンディショニング特性がある場合があります。
This document defines a set of parameters that fit into a canonical model for modeling the elements in the forwarding path of a device implementing QoS traffic conditioning. By defining this model in a device-independent way, the needed parameters can be appropriately abstracted.
このドキュメントでは、QoSトラフィックコンディショニングを実装するデバイスの転送パスの要素をモデル化するための標準モデルに適合するパラメーターのセットを定義します。このモデルをデバイスに依存しない方法で定義することにより、必要なパラメーターを適切に抽出できます。
Administrators want the flexibility to be able to define traffic conditioning without having to have a low-level understanding of the different QoS mechanisms that implement that conditioning. Furthermore, administrators want the flexibility to group different services together, describing a higher-level concept such as "Gold Service". This higher-level service could be viewed as providing the processing to deliver "Gold" quality of service.
管理者は、そのコンディショニングを実装するさまざまなQoSメカニズムを低レベルの理解を深めることなく、トラフィックコンディショニングを定義できる柔軟性を望んでいます。さらに、管理者は、「ゴールドサービス」などの高レベルの概念を説明するために、さまざまなサービスをグループ化する柔軟性を望んでいます。この高レベルのサービスは、「ゴールド」なサービス品質を提供するための処理を提供するものと見なすことができます。
These two goals dictate the need for the following set of abstractions:
これらの2つの目標は、次の一連の抽象化の必要性を決定します。
o a flexible way to describe a service
o サービスを説明する柔軟な方法
o must be able to group different services that may use different technologies (e.g., DiffServ and IEEE 802.1Q) together
o 異なるテクノロジーを使用する可能性のあるさまざまなサービスをグループ化できる必要があります（diffservとIEEE 802.1qなど）
o must be able to define a set of sub-services that together make up a higher-level service
o 高レベルのサービスを構成するサブサービスのセットを定義できる必要があります
o must be able to associate a service and the set of QoS mechanisms that are used to condition traffic for that service
o そのサービスのトラフィックを条件付けるために使用されるサービスとQoSメカニズムのセットを関連付けることができなければなりません
o must be able to define policies that manage the QoS mechanisms used to implement a service.
o サービスの実装に使用されるQoSメカニズムを管理するポリシーを定義できる必要があります。
This document addresses this set of problems by defining a set of classes and associations that can represent abstract concepts like "Gold Service," and bind each of these abstract services to a specific set of QoS mechanisms that implement the conditioning that they require. Furthermore, this document defines the concept of "sub-services," to enable Gold Service to be defined either as a single service or as a set of services that together should be treated as an atomic entity.
このドキュメントは、「ゴールドサービス」などの抽象的な概念を表すことができる一連のクラスと協会を定義し、これらの抽象サービスのそれぞれを、必要な条件付けを実装する特定のQOSメカニズムに結合できるようにすることにより、この一連の問題に対処します。さらに、このドキュメントでは、「サブサービス」の概念を定義して、ゴールドサービスを単一のサービスとして、または一緒に原子エンティティとして扱う必要がある一連のサービスとして定義できます。
Given these abstractions, policies (as defined in [QPIM]) can be written to control the QoS mechanisms and services defined in this document.
これらの抽象化を考えると、このドキュメントで定義されているQoSメカニズムとサービスを制御するために、ポリシー（[QPIM]で定義されている）を書き込むことができます。
This document defines a set of classes and properties to support policies that configure device QoS mechanisms. This document concentrates on the representation of services in the datapath that support both DiffServ (for aggregate traffic conditioning) and IntServ (for flow-based traffic conditioning). Classes and properties for modeling IntServ admission control services may be defined in a future document.
このドキュメントでは、デバイスQoSメカニズムを構成するポリシーをサポートする一連のクラスとプロパティを定義します。このドキュメントは、DIFFSERV（総トラフィックコンディショニング用）とIntServ（フローベースのトラフィックコンディショニング用）の両方をサポートするデータパス内のサービスの表現に集中しています。IntServ入学制御サービスをモデリングするためのクラスとプロパティは、将来のドキュメントで定義できます。
The classes and properties in this document are designed to be used in conjunction with the QoS policy classes and properties defined in [QPIM]. For example, to preserve the delay characteristics committed to an end-user, a network administrator may wish to create policies that monitor the queue depths in a device, and adjust resource allocations when delay budgets are at risk (perhaps as a result of a network topology change). The classes and properties in this document define the specific services and mechanisms required to implement those services. The classes and properties defined in [QPIM] provide the overall structure of the policy that manages and configures this service.
このドキュメントのクラスとプロパティは、[QPIM]で定義されているQoSポリシークラスおよびプロパティと併用するように設計されています。たとえば、エンドユーザーにコミットした遅延特性を保持するために、ネットワーク管理者は、デバイスのキューの深さを監視するポリシーを作成し、遅延予算が危険にさらされている場合にリソースの割り当てを調整したい場合があります（おそらくネットワークの結果としてトポロジの変更）。このドキュメントのクラスとプロパティは、それらのサービスを実装するために必要な特定のサービスとメカニズムを定義します。[QPIM]で定義されているクラスとプロパティは、このサービスを管理および構成するポリシーの全体的な構造を提供します。
This combination of low-level specification (using this document) and high-level structuring (using [QPIM]) of network services enables network administrators to define new services required of the network, that are directly related to business goals, while ensuring that such services can be managed. However, this goal (of creating and managing service-oriented policies) can only be realized if policies can be constructed that are capable of supporting diverse implementations of QoS. The solution is to model the QoS capabilities of devices at the behavioral level. This means that for traffic conditioning services realized in the datapath, the model must support the following characteristics:
ネットワークサービスの低レベル仕様（このドキュメントを使用）と高レベルの構造化（[QPIM]を使用）のこの組み合わせにより、ネットワーク管理者は、ビジネス目標に直接関連するネットワークに必要な新しいサービスを定義でき、そのようなことを保証できます。サービスを管理できます。ただし、（サービス指向のポリシーの作成と管理のこの目標は、QoSの多様な実装をサポートできるポリシーを構築できる場合にのみ実現できます。解決策は、行動レベルでデバイスのQoS機能をモデル化することです。これは、データパスで実現されたトラフィックコンディショニングサービスの場合、モデルは次の特性をサポートする必要があることを意味します。
o modeling of a generic network service that has QoS capabilities o modeling of how the traffic conditioning itself is defined
o QoS機能を備えた一般的なネットワークサービスのモデリングoトラフィックコンディショニング自体の定義方法のモデリング
o modeling of how statistics are gathered to monitor QoS traffic conditioning services - this facet of the model will be added in a future document.
o QOSトラフィックコンディショニングサービスを監視するための統計のモデリング - モデルのこの側面は、将来のドキュメントに追加されます。
This document models a network service, and associates it with one or more QoS mechanisms that are used to implement that service. It also models in a canonical form the various components that are used to condition traffic, such that standard as well as custom traffic conditioning services may be described.
このドキュメントは、ネットワークサービスをモデル化し、そのサービスを実装するために使用される1つ以上のQoSメカニズムに関連付けます。また、標準的なコンポーネントを使用してトラフィックを条件付けるために使用されるさまざまなコンポーネントをモデル化し、標準およびカスタムトラフィックコンディショニングサービスを説明することができます。
The QoS properties and classes will be described in more detail in Section 4. However, we should consider the basic characteristics of these properties, to understand the methodology for representing them.
QoSプロパティとクラスについては、セクション4で詳しく説明します。ただし、これらのプロパティの基本的な特性を考慮して、それらを表現する方法を理解する必要があります。
There are essentially two types of properties, state and configuration. Configuration properties describe the desired state of a device, and include properties and classes for representing desired or proposed thresholds, bandwidth allocations, and how to classify traffic. State properties describe the actual state of the device. These include properties to represent the current operational values of the attributes in devices configured via the configuration properties, as well as properties that represent state (queue depths, excess capacity consumption, loss rates, and so forth).
基本的に、状態と構成の2種類のプロパティがあります。構成プロパティデバイスの目的の状態を説明し、目的または提案されたしきい値、帯域幅の割り当て、およびトラフィックの分類方法を表すためのプロパティとクラスを含みます。状態プロパティは、デバイスの実際の状態を説明しています。これらには、構成プロパティを介して構成されたデバイス内の属性の現在の動作値を表すプロパティ、および状態を表すプロパティ（キューの深さ、過剰容量消費、損失率など）が含まれます。
In order to be correlated and used together, these two types of properties must be modeled using a common information model. The possibility of modeling state properties and their corresponding configuration settings is accomplished using the same classes in this model - although individual instances of the classes would have to be appropriately named or placed in different containers to distinguish current state values from desired configuration settings.
相関して一緒に使用するには、これら2つのタイプのプロパティを共通情報モデルを使用してモデル化する必要があります。状態プロパティとそれに対応する構成設定のモデリングの可能性は、このモデルで同じクラスを使用して達成されますが、クラスの個々のインスタンスは、現在の状態値を目的の構成設定と区別するために、適切に名前が付いているか、異なる容器に配置する必要があります。
State information is addressed in a very limited fashion by QDDIM. Currently, only CurrentQueueDepth is proposed as an attribute on QueuingService. The majority of the model is related to configuration. Given this fact, it is assumed that this model is a direct memory map into a device. All manipulation of model classes and properties directly affects the state of the device. If it is desired to also use these classes to represent desired configuration, that is left to the discretion of the implementor.
状態情報は、Qddimによって非常に限られた方法で対処されています。現在、currenceuedepthのみがqueuingserviceの属性として提案されています。モデルの大部分は構成に関連しています。この事実を考えると、このモデルはデバイスへの直接メモリマップであると想定されています。モデルクラスとプロパティのすべての操作は、デバイスの状態に直接影響します。これらのクラスを使用して目的の構成を表すことが望ましい場合は、実装者の裁量に任されます。
It is acknowledged that additional properties are needed to completely model current state. However, many of the properties defined in this document represent exactly the state variables that will be configured by the configuration properties. Thus, the definition of the configuration properties has an exact correspondence with the state properties, and can be used in modeling both actual (state) and desired/proposed configuration.
現在の状態を完全にモデル化するには、追加のプロパティが必要であることが認められています。ただし、このドキュメントで定義されているプロパティの多くは、構成プロパティによって構成される状態変数を正確に表しています。したがって、構成プロパティの定義は、状態プロパティと正確な対応を持ち、実際の（状態）と希望/提案された構成の両方のモデリングに使用できます。
The question of context also leads to another question: how does the information specified in the core and QoS policy models ([PCIM], [PCIME], and [QPIM], respectively) integrate with the information defined in this document? To put it another way, where should device-independent concepts that lead to device-specific QoS attributes be derived from?
コンテキストの問題は、別の質問にもつながります。コアおよびQoSポリシーモデル（[PCIM]、[PCIME]、および[QPIM]）で指定された情報は、このドキュメントで定義されている情報とどのように統合されますか？別の言い方をすれば、デバイス固有のQoS属性につながるデバイスに依存しない概念はどこから導き出されるべきですか？
Past thinking was that QoS was part of the policy model. This view is not completely accurate, and it leads to confusion. QoS is a set of services that can be controlled using policy. These services are represented as device mechanisms. An important point here is that QoS services, as well as other types of services (e.g., security), are provided by the mechanisms inherent in a given device. This means that not all devices are indeed created equal. For example, although two devices may have the same type of mechanism (e.g., a queue), one may be a simple implementation (i.e., a FIFO queue) whereas one may be much more complex and robust (e.g., class-based weighted fair queuing (CBWFQ)). However, both of these devices can be used to deliver QoS services, and both need to be controlled by policy. Thus, a device-independent policy can instruct the devices to queue certain traffic, and a device-specific policy can be used to control the queuing in each device.
過去の考えは、Qosがポリシーモデルの一部であるということでした。このビューは完全に正確ではなく、混乱につながります。QoSは、ポリシーを使用して制御できるサービスのセットです。これらのサービスは、デバイスメカニズムとして表されます。ここでの重要な点は、QoSサービス、および他のタイプのサービス（セキュリティなど）が、特定のデバイスに固有のメカニズムによって提供されることです。これは、すべてのデバイスが実際に等しく作成されているわけではないことを意味します。たとえば、2つのデバイスには同じタイプのメカニズム（キューなど）がある場合がありますが、1つは簡単な実装（つまり、FIFOキュー）である場合がありますが、1つははるかに複雑で堅牢です（クラスベースの加重フェアなどキューイング（CBWFQ））。ただし、これらのデバイスは両方ともQoSサービスを提供するために使用でき、両方ともポリシーによって制御する必要があります。したがって、デバイスに依存しないポリシーは、デバイスに特定のトラフィックをキューするように指示することができ、デバイス固有のポリシーを使用して各デバイスのキューイングを制御できます。
Furthermore, policy is used to control these mechanisms, not to represent them. For example, QoS services are implemented with classifiers, meters, markers, droppers, queues, and schedulers. Similarly, security is also a characteristic of devices, as authentication and encryption capabilities represent services that networked devices perform (irrespective of interactions with policy servers). These security services may use some of the same mechanisms that are used by QoS services, such as the concepts of filters. However, they will mostly require different mechanisms than the ones used by QoS, even though both sets of services are implemented in the same devices.
さらに、ポリシーは、これらのメカニズムを表すのではなく、これらのメカニズムを制御するために使用されます。たとえば、QoSサービスは、分類子、メーター、マーカー、ドロップ、キュー、スケジューラーで実装されています。同様に、認証と暗号化機能はネットワークデバイスが実行するサービスを表すため、セキュリティもデバイスの特徴です（ポリシーサーバーとの対話に関係なく）。これらのセキュリティサービスは、フィルターの概念など、QoSサービスで使用される同じメカニズムの一部を使用する場合があります。ただし、両方のサービスのセットが同じデバイスに実装されている場合でも、QoSが使用するメカニズムとは異なるメカニズムがほとんど必要になります。
Thus, the similarity between the QoS model and models for other services is not so much that they contain a few common mechanisms. Rather, they model how a device implements their respective services.
したがって、QoSモデルと他のサービスのモデルの類似性は、それらにいくつかの一般的なメカニズムが含まれているほどではありません。むしろ、デバイスがそれぞれのサービスをどのように実装するかをモデル化します。
As such, the modeling of QoS should be part of a networking device schema rather than a policy schema. This allows the networking device schema to concentrate on modeling device mechanisms, and the policy schema to focus on the semantics of representing the policy itself (conditions, actions, operators, etc.). While this document concentrates on defining an information model to represent QoS services in a device datapath, the ultimate goal is to be able to apply policies that control these services in network devices. Furthermore, these two schemata (device and policy) must be tightly integrated in order to enable policy to control QoS services.
そのため、QoSのモデリングは、ポリシースキーマではなくネットワークデバイススキーマの一部である必要があります。これにより、ネットワークデバイススキーマはモデリングデバイスメカニズムに集中し、ポリシースキーマがポリシー自体（条件、アクション、演算子など）を表すセマンティクスに焦点を当てることができます。このドキュメントは、デバイスデータパスでQoSサービスを表す情報モデルを定義することに集中していますが、最終的な目標は、ネットワークデバイスでこれらのサービスを制御するポリシーを適用できることです。さらに、これらの2つのスキーマ（デバイスとポリシー）は、QoSサービスを制御するためのポリシーを有効にするために、しっかりと統合する必要があります。
The last issue to be considered is the question of how attributes are represented. If QoS attributes are represented as absolute numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more difficult to make them uniform across multiple ports in a device or across multiple devices, because of the broad variation in link capacities. However, expressing attributes in relative or proportional terms (e.g., Class AF2 gets 5% of the total link bandwidth) makes it more difficult to express certain types of conditions and actions, such as:
考慮すべき最後の問題は、属性がどのように表現されるかという問題です。QoS属性が絶対数値として表される場合（たとえば、クラスAF2は2 MBSの帯域幅を取得します）、リンク容量の幅広い変動のため、デバイスまたは複数のデバイスで複数のポートで均一にすることはより困難です。ただし、相対的または比例的な用語で属性を表現すること（たとえば、クラスAF2がリンク帯域幅の5％を取得します）により、次のような特定のタイプの条件やアクションを表現することがより困難になります。
(If ConsumedBandwidth = AssignedBandwidth Then ...)
（消費された場合、bandwidth = assignedbandwidth ...）
There are really three approaches to addressing this problem:
この問題に対処するには、本当に3つのアプローチがあります。
o Multiple properties can be defined to express the same value in various forms. This idea has been rejected because of the difficulty in keeping these different properties synchronized (e.g., when one property changes, the others all have to be updated).
o 複数のプロパティを定義して、同じ値をさまざまな形式で表現できます。このアイデアは、これらの異なるプロパティを同期させるのが難しいために拒否されました（たとえば、1つのプロパティが変更された場合、他のプロパティをすべて更新する必要があります）。
o Multi-modal properties can be defined to express the same value, in different terms, based on the access or assignment mode. This option was rejected because it significantly complicates the model and is impossible to express in current directory access protocols (e.g., (L)DAP).
o マルチモーダルプロパティを定義して、アクセスモードまたは割り当てモードに基づいて、異なる用語で同じ値を表すことができます。このオプションは、モデルを大幅に複雑にし、現在のディレクトリアクセスプロトコル（（L）DAP）で表現することが不可能であるため拒否されました。
o Properties can be expressed as "absolutes", but the operators in the policy schema would need to be more sophisticated. Thus, to represent a percentage, division and multiplication operators are required (e.g., Class AF2 gets .05 * the total link bandwidth). This is the approach that has been taken in this document.
o プロパティは「絶対」として表現できますが、ポリシースキーマのオペレーターはより洗練される必要があります。したがって、パーセンテージを表すには、分割演算子と乗算演算子が必要です（たとえば、クラスAF2は.05 *総リンク帯域幅を取得します）。これは、このドキュメントで取得されたアプローチです。
The mental model for constructing this schema is based on the work done in the Differentiated Services working group. This schema is based on information provided in the current versions of the DiffServ Informal Management Model [DSMODEL], the DiffServ MIB [DSMIB], the PIB [PIB], as well as on information in the set of RFCs that constitute the basic definition of DiffServ itself ([R2475], [R2474], [R2597], and [R3246]). In addition, a common set of terminology is available in [POLTERM].
このスキーマを構築するためのメンタルモデルは、差別化されたサービスワーキンググループで行われた作業に基づいています。このスキーマは、DiffServ Informal Managementモデル[DSModel]、Diffserv Mib [DSMIB]、PIB [PIB]の現在のバージョンで提供されている情報と、RFCのセットの情報に基づいて、基本的な定義を構成するRFCのセットの情報に基づいています。Diffserv自体（[R2475]、[R2474]、[R2597]、および[R3246]）。さらに、[Polterm]で一般的な一連の用語が利用可能です。
This model is built around two fundamental class hierarchies that are bound together using a set of associations. The two class hierarchies derive from the QoSService and ConditioningService base classes. A set of associations relate lower-level QoSService subclasses to higher-level QoS services, relate different types of conditioning services together in processing a traffic class, and relate a set of conditioning services to a specific QoS service. This combination of associations enables us to view the device as providing a set of services that can be configured, in a modular building block fashion, to construct application-specific services. Thus, this document can be used to model existing and future standard as well as application-specific network QoS services.
このモデルは、一連の関連付けを使用して結合する2つの基本的なクラス階層を中心に構築されています。2つのクラスの階層は、Qosservice and Conditioningsersingservice Base Classesから派生しています。一連の協会は、低レベルのQosserviceサブクラスを高レベルのQoSサービスに関連付け、トラフィッククラスの処理にさまざまな種類のコンディショニングサービスを一緒に関連付け、一連のコンディショニングサービスを特定のQoSサービスに関連付けます。このアソシエーションの組み合わせにより、デバイスは、モジュール式ビルディングブロックファッションで構成できるセットを提供して、アプリケーション固有のサービスを構築することができます。したがって、このドキュメントは、既存および将来の標準、およびアプリケーション固有のネットワークQoSサービスをモデル化するために使用できます。
The first of the classes defined here, QoSService, is used to represent higher-level network services that require special conditioning of their traffic. An instance of QoSService (or one of its subclasses) is used to bring together a group of conditioning services that, from the perspective of the system manager, are all used to deliver a common service. Thus, the set of classifiers, markers, and related conditioning services that provide premium service to the "selected" set of user traffic may be grouped together into a premium QoS service.
ここで定義されている最初のクラスであるQosserviceは、トラフィックの特別な条件付けを必要とする高レベルのネットワークサービスを表すために使用されます。Qosservice（またはそのサブクラスの1つ）のインスタンスは、システムマネージャーの観点から、すべてが共通のサービスを提供するために使用されるコンディショニングサービスのグループをまとめるために使用されます。したがって、ユーザートラフィックの「選択された」セットにプレミアムサービスを提供する分類器、マーカー、および関連するコンディショニングサービスのセットを、プレミアムQoSサービスにグループ化できます。
QoSService has a set of subclasses that represent different approaches to delivering IP services. The currently defined set of subclasses are a FlowService for flow-oriented QoS delivery and a DiffServService for DiffServ aggregate-oriented QoS service delivery.
Qosserviceには、IPサービスを提供するためのさまざまなアプローチを表すサブクラスのセットがあります。現在定義されているサブクラスのセットは、フロー指向のQoS配信のためのフローサービスであり、Diffserv Aggregate指向のQoSサービス配信用のDiffservserviceです。
The QoS services can be related to each other as peers, or they can be implemented as subservient services to each other. The QoSSubService aggregation indicates that one or more QoSService objects are subservient to a particular QoSService object. For example, this enables us to define Gold Service as a combination of two DiffServ services, one for high quality traffic treatment, and one for servicing the rest of the traffic. Each of these DiffServService objects would be associated with a set of classifiers, markers, etc, such that the high quality traffic would get EF marking and appropriate queuing.
QoSサービスは、仲間として互いに関連しているか、互いに従属的なサービスとして実装することができます。QOSSUBSERVICEアグリゲーションは、1つまたは複数のQOSServiceオブジェクトが特定のQosserviceオブジェクトに従属していることを示しています。たとえば、これにより、ゴールドサービスを2つのDiffServサービスの組み合わせとして定義できます。1つは高品質の交通処理用、もう1つはトラフィックの残りのサービスを提供します。これらのdiffservserviceオブジェクトはそれぞれ、分類器、マーカーなどのセットに関連付けられているため、高品質のトラフィックがEFマーキングと適切なキューイングを取得します。
The DiffServService class itself has an AFService subclass. This subclass is used to represent the specific notion that several related markings within the AF PHB Group work together to provide a single service. When other DiffServ PHB Groups are defined that use more than one code point, these will be likely candidates for additional DiffServService subclasses.
diffservserviceクラス自体には、AfServiceサブクラスがあります。このサブクラスは、AF PHBグループ内のいくつかの関連するマーキングが協力して単一のサービスを提供するという特定の概念を表すために使用されます。複数のコードポイントを使用する他のdiffserv PHBグループが定義されると、これらは追加のdiffservserviceサブクラスの候補になる可能性があります。
Technology-specific mappings of these services, representing the specific use of PHB marking or 802.1Q marking, are captured within the ConditioningService hierarchy, rather than in the subclasses of QoSService.
PHBマーキングまたは802.1Qマーキングの特定の使用を表すこれらのサービスの技術固有のマッピングは、Qosserviceのサブクラスではなく、ConditionService階層内でキャプチャされます。
These concepts are depicted in Figure 2. Note that both of the associations are aggregations: a QoSService object aggregates both the set of QoSService objects subservient to it, and the set of ConditioningService objects that realize it. See Section 4 for class and association definitions.
これらの概念を図2に示します。両方の関連付けは集約であることに注意してください。Qosserviceオブジェクトは、それに従うQosserviceオブジェクトのセットと、それを実現する条件付けサービスオブジェクトのセットの両方を集約します。クラスおよびアソシエーションの定義については、セクション4を参照してください。
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |
| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..n 0..n| |
| | /\______________________| |
| | \/ QoSConditioning | |
+--------------+ SubService +---------------+
Figure 2. QoSService and its Aggregations
図2. Qosserviceとその集約
The goal of the ConditioningService classes is to describe the sequence of traffic conditioning that is applied to a given traffic stream on the ingress interface through which it enters a device, and then on the egress interface through which it leaves the device. This is done using a set of classes and relationships. The routing decision in the device core, which selects which egress interface a particular packet will use, is not represented in this model.
条件付けサービスクラスの目標は、デバイスに入るイングレスインターフェイスの特定のトラフィックストリームに適用されるトラフィックコンディショニングのシーケンスを記述することです。これは、一連のクラスと関係を使用して行われます。このモデルでは、特定のパケットが使用する速度インターフェイスを選択するデバイスコアのルーティング決定は、表示されるものではありません。
A single base class, ConditioningService, is the superclass for a set of subclasses representing the mechanisms that condition traffic.
単一のベースクラス、条件付けサービスは、トラフィックを条件付けるメカニズムを表すサブクラスのセットのスーパークラスです。
These subclasses define device-independent conditioning primitives (including classifiers, meters, markers, droppers, queues, and schedulers) that together implement the conditioning of traffic on an interface. This model abstracts these services into a common set of modular building blocks that can be used, regardless of device implementation, to model the traffic conditioning internal to a device.
これらのサブクラスは、インターフェイス上のトラフィックのコンディショニングを実装するデバイスに依存しないコンディショニングプリミティブ（分類器、メーター、マーカー、ドロッパー、キュー、スケジューラーを含む）を定義します。このモデルは、これらのサービスを、デバイスの実装に関係なく使用できるモジュラービルディングブロックの一般的なセットに抽象化し、デバイス内部のトラフィックコンディショニングをモデル化します。
The different conditioning mechanisms need to be related to each other to describe how traffic is conditioned. Several important variations of how these services are related together exist:
さまざまなコンディショニングメカニズムは、トラフィックがどのように条件付けられているかを説明するために、互いに関連する必要があります。これらのサービスがどのように関連しているかのいくつかの重要なバリエーションが存在します：
o A particular ingress or egress interface may not require all the types of ConditioningServices.
o 特定の侵入または出口インターフェイスは、すべてのタイプの条件付けサービスを必要としない場合があります。
o Multiple instances of the same mechanism may be required on an ingress or egress interface.
o 同じメカニズムの複数のインスタンスが、侵入または出口インターフェイスに必要になる場合があります。
o There is no set order of application for the ConditioningServices on an ingress or egress interface.
o 侵入または出口インターフェイスに条件付けサービスの適用順序はありません。
Therefore, this model does not dictate a fixed ordering among the subclasses of ConditioningService, or identify a subclass of ConditioningService that must appear first or last among the ConditioningServices on an ingress or egress interface. Instead, this model ties together the various ConditioningService instances on an ingress or egress interface using the NextService, NextServiceAfterMeter, and NextServiceAfterConditioningElement associations. There are also separate associations, called IngressConditioningServiceOnEndpoint and EgressConditioningServiceOnEndpoint, which, respectively, tie an ingress interface to its first ConditioningService, and tie an egress interface to its last ConditioningService(s).
したがって、このモデルは、条件付けサービスのサブクラス間で固定された順序付けを決定したり、イングレスまたは出口インターフェイスのコンディショニングサービスの中で最初または最後に表示しなければならないコンディショニングサービスのサブクラスを特定したりしません。代わりに、このモデルは、NextService、NextServiceAftermeter、およびNextServiceAfterConditionIngingElement Associationsを使用して、イングレスまたは出力インターフェイスにさまざまな条件付けサービスインスタンスを結び付けます。また、IngressConditionServiceOnendPointとEugressConditionServiceOnendPointと呼ばれる個別の関連付けもあります。これは、それぞれIngressインターフェイスを最初の条件付けサービスに結び付け、Egressインターフェイスを最後の条件付けサービスに結び付けます。
There is one important way in which the QDDIM model diverges from the [DSMODEL]. In [DSMODEL], traffic passes through a network device in three stages:
QDDIMモデルが[dsmodel]から分岐する重要な方法が1つあります。[dsmodel]では、トラフィックは3つの段階でネットワークデバイスを通過します。
o It comes in on an ingress interface, where it may receive QoS conditioning.
o QoSコンディショニングを受ける可能性のあるイングレスインターフェイスに登場します。
o It traverses the routing core, where logic outside the scope of QoS determines which egress interface it will use to leave the device.
o ルーティングコアを横断します。ここでは、QoSの範囲外のロジックが、デバイスを離れるために使用するEgressインターフェイスを決定します。
o It may receive further QoS conditioning on the selected egress interface, and then it leaves the device.
o 選択した出力インターフェイスでさらにQoSコンディショニングを受ける可能性があり、その後、デバイスを離れます。
In this model, no information about the QoS conditioning that a packet receives on the ingress interface is communicated with the packet across the routing core to the egress interface.
このモデルでは、イングレスインターフェイスでパケットが受信するQOSコンディショニングに関する情報は、ルーティングコアを越えてパケットと出口インターフェイスに通信しません。
The QDDIM model relaxes this restriction, to allow information about the treatment that a packet received on an ingress interface to be communicated along with the packet to the egress interface. (This relaxation adds a capability that is present in many network devices.) QDDIM represents this information transfer in terms of a packet preamble, which is how many devices implement it. But implementations are free to use other mechanisms to achieve the same result.
QDDIMモデルは、この制限を緩和して、侵入インターフェイスで受け取ったパケットがPacketとともに伝達される処理に関する情報を許可します。（このリラクゼーションは、多くのネットワークデバイスに存在する機能を追加します。）QDDIMは、この情報転送をパケットプリアンブルの観点から表します。これは、それを実装するデバイスの数です。しかし、実装は他のメカニズムを使用して同じ結果を達成することができます。
+---------+
| Meter-A |
a | | b d
--->| In-|---PM-1--->
| | c e
| Out-|---PM-2--->
+---------+
Figure 3: Meter Followed by Two Preamble Markers
図3：メーターに続いて2つのプリアンブルマーカーが続きます
Figure 3 shows an example in which meter results are captured in a packet preamble. The arrows labeled with single letters represent instances of either the NextService association (a, d, and e), or of its peer association NextServiceAfterMeter (b and c). PreambleMarker PM-1 adds to the packet preamble an indication that the packet exited Meter A as conforming traffic. Similarly, PreambleMarker PM-2 adds to the preambles of packets that come through it indications that they exited Meter A as nonconforming traffic. A PreambleMarker appends its information to whatever is already present in a packet preamble, as opposed to overwriting what is already there.
図3は、メーターの結果がパケットプリアンブルでキャプチャされる例を示しています。単一文字でラベル付けされた矢印は、Next -Service Association（A、D、およびE）のインスタンスまたはそのピアアソシエーションNextServiceAftermeter（BおよびC）のいずれかのインスタンスを表します。Preamblemarker PM-1は、パケットのプリアンブルに追加され、パケットが適合トラフィックとしてメーターAを出ることを示しています。同様に、Preambremarker PM-2は、不適合なトラフィックとしてメーターAを出たという兆候を通過するパケットのプリアンブルに追加されます。Preamblemarkerは、すでにそこにあるものを上書きするのではなく、その情報をパケットのプリアンブルに既に存在するものに追加します。
To foster interoperability, the basic format of the information captured by a PreambleMarker is specified. (Implementations, of course, are free to represent this information in a different way internally - this is just how it is represented in the model.) The information is represented by an ordered, multi-valued string property FilterItemList, where each individual value of the property is of the form "<type>,<value>". When a PreambleMarker "appends" its information to the information that was already present in a packet preamble, it does so by adding additional items of the indicated format to the end of the list.
相互運用性を促進するために、Preamblembarkerによってキャプチャされた情報の基本形式が指定されています。（もちろん、実装はこの情報を内部的に異なる方法で自由に表すことができます - これはモデルで表現される方法です。）情報は、順序付けられたマルチ値の文字列プロパティFilterItemlistによって表されます。プロパティは「<pype>、<balue>」という形式です。Preamblemarkerがその情報をパケットプリアンブルに既に存在していた情報に情報を「追加」する場合、リストの最後に指定された形式のアイテムを追加することでそうします。
QDDIM provides a limited set of <type>'s that a PreambleMarker may use:
QDDIMは、Preamblembarkerが使用できる<Type>の限られたセットを提供します。
o ConformingFromMeter: the value is the name of the meter.
o Frommeter：値はメーターの名前です。
o PartConformingFromMeter: the value is the name of the meter.
o PartConformingFrommeter：値はメーターの名前です。
o NonConformingFromMeter: the value is the name of the meter.
o nonformingfrommeter：値はメーターの名前です。
o VlanId: the value is the virtual LAN identifier (VLAN ID).
o Vlanid：値は仮想LAN識別子（VLAN ID）です。
Implementations may recognize other <type>'s in addition to these. If collisions of implementation-specific <type>'s become a problem, it is possible that <type>'s may become an IANA-administered range in a future revision of this document.
実装は、これらに加えて他の<タイプ>を認識する場合があります。実装固有の<type>の衝突が問題になる場合、<type>の<type>は、このドキュメントの将来の改訂でIANAが管理する範囲になる可能性があります。
To make use of the information that a PreambleMarker stores in a packet preamble, a specific subclass PreambleFilter of FilterEntryBase is defined, to match on the "<type>,<value>" strings. To simplify the case where there's just a single level of metering in a device, but different individual meters on each ingress interface, PreambleFilter allows a wildcard "any" for the <value> part of the three meter-related filters. With this wildcard, an administrator can specify a Classifier to select all packets that were found to be conforming (or partially conforming, or non-conforming) by their respective meters, without having to name each meter individually in a separate ClassifierElement.
Preamblemarkerがパケットプリアンブルに保存する情報を利用するために、filterentrybaseの特定のサブクラスプリアムブルーフィルターが定義され、「<type>、<balue>」文字列に一致します。デバイスに単一のレベルのメーターがあるが、各イングレスインターフェイスに異なる個々のメーターがある場合を簡素化するために、PreambleFilterは、3メートル関連のフィルターの一部に対してワイルドカード「任意の」を「任意」に「任意」します。このワイルドカードを使用すると、管理者は分類器を指定して、各メーターを個別に個別に名前にすることなく、それぞれのメーターで適合（または部分的に適合または不適合）であることがわかったすべてのパケットを選択できます。
Once a meter result has been stored in a packet preamble, it is available for any subsequent Classifier to use. So while the motivation for this capability has been described in terms of preserving QoS conditioning information from an ingress interface to an egress interface, a prior meter result may also be used for classifying packets later in the datapath on the same interface where the meter resides.
メートルの結果がパケットプリアンブルに保存されると、後続の分類器が使用できるようになります。したがって、この機能の動機は、入り口のインターフェースから出口インターフェイスへのQoSコンディショニング情報を保存するという観点から説明されていますが、メーターが存在する同じインターフェイスでデータパスの後半でパケットを分類するために以前のメーター結果を使用することもできます。
This document uses a number of classes to model the classifiers defined in [DSMODEL]: ClassifierService, ClassifierElement, FilterList, FilterEntryBase, and various subclasses of FilterEntryBase. There are also two associations involved: ClassifierElementUsesFilterList and EntriesInFilterList. The QDDIM model makes no use of CIM's FilterEntry class.
このドキュメントでは、多くのクラスを使用して、[dsmodel]で定義されている分類子：classifierservice、classifierelement、filterlist、filterentrybase、およびfilterentrybaseのさまざまなサブクラスをモデル化します。また、classifierelementusesfilterlistとentriesInfilterlistの2つの関連付けもあります。QDDIMモデルは、CIMのフィルターレントリークラスを使用しません。
In [DSMODEL], a single traffic stream coming into a classifier is split into multiple traffic streams leaving it, based on which of an ordered set of filters each packet in the incoming stream matches. A filter matches either a field in the packet itself, or possibly other attributes associated with the packet. In the case of a multi-field (MF) classifier, packets are assigned to output streams based on the contents of multiple fields in the packet header. For example, an MF classifier might assign packets to an output stream based on their complete IP-addressing 5-tuple.
[dsmodel]では、分類子に入る単一のトラフィックストリームが、着信ストリームの各パケットのどのフィルターセットのセットに基づいて、それを残す複数のトラフィックストリームに分割されます。フィルターは、パケット自体のフィールド、またはパケットに関連付けられた他の属性のいずれかと一致します。マルチフィールド（MF）分類器の場合、パケットヘッダー内の複数のフィールドの内容に基づいて、パケットが出力ストリームに割り当てられます。たとえば、MF分類器は、完全なIPアドレス5タプルに基づいて、パケットを出力ストリームに割り当てる場合があります。
To optimize the representation of MF classifiers, subclasses of FilterEntryBase are introduced, which allow multiple related packet header fields to be represented in a single object. These subclasses are IPHeaderFilter and 8021Filter. With IPHeaderFilter, for example, criteria for selecting packets based on all five of the IP 5-tuple header fields and the DiffServ DSCP can be represented by a FilterList containing one IPHeaderFilter object. Because these two classes have applications beyond those considered in this document, they, as well as the abstract class FilterEntryBase, are defined in the more general document [PCIME] rather than here.
MF分類子の表現を最適化するために、FilterentRybaseのサブクラスが導入され、複数の関連パケットヘッダーフィールドを単一のオブジェクトで表現できます。これらのサブクラスは、ipheaderfilterと8021filterです。たとえば、iPheaderfilterを使用すると、IP 5タプルヘッダーフィールドの5つすべてに基づいてパケットを選択するための基準と、DiffServ DSCPは、1つのiPheaderFilterオブジェクトを含むフィルターリストで表すことができます。これらの2つのクラスには、このドキュメントで検討されているクラスを超えるアプリケーションがあるため、抽象クラスFilterentryBaseは、ここではなく、より一般的なドキュメント[PCIME]で定義されています。
The FilterList object is always needed, even if it contains only one filter entry (that is, one FilterEntryBase subclass) object. This is because a ClassifierElement can only be associated with a Filter List, as opposed to an individual FilterEntry. FilterList is also defined in [PCIME].
フィルターリストオブジェクトは、1つのフィルターエントリ（つまり、1つのFilterEntryBaseサブクラス）オブジェクトのみが含まれている場合でも、常に必要です。これは、個々のフィルタートレントとは対照的に、分類がフィルターリストにのみ関連付けられるためです。FilterListは[PCIME]でも定義されています。
The EntriesInFilterList aggregation (also defined in [PCIME]) has a property EntrySequence, which in the past (in CIM) could be used to specify an evaluation order on the filter entries in a FilterList. Now, however, the EntrySequence property supports only a single value: '0'. This value indicates that the FilterEntries are ANDed together to determine whether a packet matches the MF selector that the FilterList represents.
EntriesInFilterList集約（[PCIME]でも定義されている）には、プロパティエントリシーケンスがあります。これは、過去に（CIM）フィルターエントリの評価順序を指定するために使用できました。ただし、現在、エントリシーケンスプロパティは単一の値のみをサポートしています： '0'。この値は、フィルターエントリが一緒になって、フィルターリストが表すMFセレクターとパケットが一致するかどうかを判断することを示しています。
A ClassifierElement specifies the starting point for a specific policy or data path. Each ClassifierElement uses the NextServiceAfterClassifierElement association to determine the next conditioning service to apply for packets to.
ClassifierElementは、特定のポリシーまたはデータパスの開始点を指定します。各classifierelementは、NextServiceFerClassifierElement Associationを使用して、次のコンディショニングサービスを決定し、パケットを適用します。
A ClassifierService defines a grouping of ClassifierElements. There are certain instances where a ClassifierService actually specifies an aggregation of ClassifierServices. One practical case would be where each ClassifierService specifies a group of policies associated with a particular application and another ClassifierService groups the application-specific ClassifierService instances. In this particular case, the application-specific ClassifierService instances are specified once, but unique combinations of these ClassifierServices are specified, as needed, using other ClassifierService instances. ClassifierService instances grouping other ClassifierService instances may not specify a FilterList using the ClassifierElementUsesFilterList association. This special use of ClassifierService serves just as a Classifier collecting function.
ClassifierServiceは、分類のグループ化を定義します。ClassifierServiceが実際にClassifierServicesの集約を指定する特定のインスタンスがあります。1つの実用的なケースは、各classifierserviceが特定のアプリケーションに関連付けられたポリシーのグループを指定し、別のClassifierServiceがアプリケーション固有のClassifierServiceインスタンスをグループ化する場合です。この特定のケースでは、アプリケーション固有の分類サービスインスタンスが一度指定されますが、これらの分類装置サービスの一意の組み合わせは、必要に応じて、他の分類器サービスインスタンスを使用して指定されています。ClassifierServiceその他のClassifierServiceインスタンスのグループ化は、ClassifierElementUsesFilterList Associationを使用してFilterListを指定しない場合があります。この特別なClassifierServiceは、分類器収集機能として機能します。
In [DSMODEL], a distinction is made between absolute droppers and algorithmic droppers. In QDDIM, both of these types of droppers are modeled with the DropperService class, or with one of its subclasses. In both cases, the queue from which the dropper drops packets is tied to the dropper by an instance of the NextService association. The dropper always plays the PrecedingService role in these associations, and the queue always plays the FollowingService role. There is always exactly one queue from which a dropper drops packets.
[dsmodel]では、絶対ドロッパーとアルゴリズムドロッパーを区別します。QDDIMでは、これらのタイプのドロッパーの両方が、DroperServiceクラス、またはそのサブクラスの1つでモデル化されています。どちらの場合も、DropperドロップパケットがNextService AssociationのインスタンスによってDropperに結び付けられるキューがあります。Dropperは常にこれらの関連付けで先行サービスの役割を果たし、キューは常にフォロースサービスの役割を果たします。ドロッパーがパケットをドロップするキューは常に1つあります。
Since an absolute dropper drops all packets in its queue, it needs no configuration beyond a NextService tie to that queue. For an algorithmic dropper, however, further configuration is needed:
絶対ドロッパーはキューにすべてのパケットをドロップするため、そのキューへの次のサービスタイを超えて構成は必要ありません。ただし、アルゴリズムドロッパーの場合、さらに構成が必要です。
o a specific drop algorithm;
o 特定のドロップアルゴリズム。
o parameters for the algorithm (for example, token bucket size);
o アルゴリズムのパラメーター（たとえば、トークンバケットサイズ）;
o the source(s) of input(s) to the algorithm;
o アルゴリズムへの入力のソース。
o possibly per-input parameters for the algorithm.
o おそらくアルゴリズムの入力ごとのパラメーター。
The first two of these items are represented by properties of the DropperService class, or properties of one of its subclasses. The last two, however, involve additional classes and associations.
これらのアイテムの最初の2つは、Droperserviceクラスのプロパティ、またはそのサブクラスの1つのプロパティで表されます。ただし、最後の2つには、追加のクラスと協会が含まれます。
The HeadTailDropQueueBinding is the association that identifies the inputs for the algorithm executed by a tail dropper. This association is not used for a head dropper, because a head dropper always has exactly one input to its drop algorithm, and this input is always the queue from which it drops packets. For a tail dropper, this association is defined to have a many-to-many cardinality. There are, however, two distinct cases:
ヘッドテールドロップバインディングは、テールドロッパーによって実行されたアルゴリズムの入力を識別する関連です。ヘッドドロッパーは常にドロップアルゴリズムへの入力が常に1つあるため、この関連性はヘッドドロッパーには使用されません。この入力は常にパケットをドロップするキューです。テールドロッパーの場合、この関連性は、多くの多くのカーディナリティを持つように定義されています。ただし、2つの異なるケースがあります。
One dropper bound to many queues: This represents the case where the drop algorithm for the dropper involves inputs from more than one queue. The dropper still drops from only one queue, the one to which it is tied by a NextService association. But the drop decision may be influenced by the state of several queues. For the classes HeadTailDropper and HeadTailDropQueueBinding, the rule for combining the multiple inputs is simple addition: if the sum of the lengths of the monitored queues exceeds the dropper's QueueThreshold value, then packets are dropped. This rule for combining inputs may, however, be overridden by a different rule in subclasses of one or both of these classes.
1つのドロッパーが多くのキューにバインドされています。これは、Dropperのドロップアルゴリズムに複数のキューからの入力が含まれる場合を表します。ドロッパーはまだ1つのキューから落ちます。これは、次のサービス協会によって結び付けられているキューです。しかし、ドロップの決定は、いくつかのキューの状態の影響を受ける可能性があります。クラスのヘッドテールドロッパーとヘッドテールドロップバインディングの場合、複数の入力を組み合わせるためのルールは単純な追加です。監視されたキューの長さの合計がドロッパーの象徴値を超える場合、パケットはドロップされます。ただし、入力を組み合わせるためのこのルールは、これらのクラスの1つまたは両方のサブクラスの異なるルールによってオーバーライドされる場合があります。
One queue bound to many droppers: This represents the case where the state of one queue (which is typically also the queue from which packets are dropped) provides an input to multiple droppers' drop algorithms. A use case here is a classifier that splits a traffic stream into, say, four parts, representing four classes of traffic. Each of the parts goes through a separate HeadTailDropper, then they're re-merged onto the same queue. The net is a single queue containing packets of four traffic types, with, say, the following drop thresholds:
多くのドロッパーにバインドされた1つのキュー：これは、1つのキューの状態（通常、パケットがドロップされるキュー）の状態が複数のドロッパーのドロップアルゴリズムへの入力を提供する場合を表します。ここでのユースケースは、たとえば4つの部品を表す4つのパートにトラフィックストリームを分割する分類器です。各部品は別のヘッドテールドロッパーを通過し、同じキューに再び登録されます。ネットは、4つのトラフィックタイプのパケットを含む単一のキューであり、たとえば、次のドロップしきい値があります。
o Class 1 - 90% full o Class 2 - 80% full o Class 3 - 70% full o Class 4 - 50% full
o クラス1-90％フルOクラス2-80％フルOクラス3-70％フルOクラス4-50％フル
Here the percentages represent the overall state of the queue. With this configuration, when the queue in question becomes 50% full, Class 4 packets will be dropped rather than joining the queue, when it becomes 70% full, Class 3 and 4 packets will be dropped, etc.
ここで、パーセンテージはキューの全体的な状態を表します。この構成を使用すると、問題のキューが50％のフルになると、クラス4パケットがキューに参加するのではなく、70％になると、クラス3と4のパケットがドロップされます。
The two cases described here can also occur together, if a dropper receives inputs from multiple queues, one or more of which are also providing inputs to other droppers.
ここで説明する2つのケースも一緒に発生する可能性があります。ドロッパーが複数のキューから入力を受け取ると、1つ以上が他のドロッパーに入力を提供しています。
Like a tail dropper, a RED dropper, represented by an instance of the REDDropperService class, may take as its inputs the states of multiple queues. In this case, however, there is an additional step: each of these inputs may be smoothed before the RED dropper uses it, and the smoothing process itself must be parameterized. Consequently, in addition to REDDropperService and QueuingService, a third class, DropThresholdCalculationService, is introduced, to represent the per-queue parameterization of this smoothing process.
テールドロッパーのように、ReddropPerserviceクラスのインスタンスで表される赤いドロッパーは、その入力として複数のキューの状態を取ることができます。ただし、この場合、追加のステップがあります。これらの各入力は、赤いドロッパーが使用する前に滑らかになる場合があり、平滑化プロセス自体をパラメーター化する必要があります。その結果、ReddoperServiceとQueuingserviceに加えて、3番目のクラスであるDropthholdCalculationserviceが導入され、この平滑化プロセスの一人一人のパラメーター化を表します。
The following instance diagram illustrates how these classes work with each other:
次のインスタンス図は、これらのクラスが互いにどのように機能するかを示しています。
RDSvc-A
| | |
+-----+ | +-----+
| | |
DTCS-1 DTCS-2 DTCS-3
| | |
Q-1 Q-2 Q-3
Figure 4. Inputs for a RED Dropper
図4.赤いドロッパーの入力
So REDDropperService-A (RDSvc-A) is using inputs from three queues to make its drop decision. (As always, RDSvc-A is linked to the queue from which it drops packets via the NextService association.) For each of these three queues, there is a (DropThresholdCalculationService) DTCS instance that represents the smoothing weight and time interval to use when looking at that queue. Thus each DTCS instance is tied to exactly one queue, although a single queue may be examined (with different weight and time values) by multiple DTCS instances. Also, a DTCS instance and the queue behind it can be thought of as a "unit of reusability". So a single DTCS can be referred to by multiple RDSvc's.
したがって、RedDropPerService-A（RDSVC-A）は、3つのキューからの入力を使用して、ドロップを決定することです。（いつものように、RDSVC-Aは、NextService Associationを介してパケットをドロップするキューにリンクしています。）これら3つのキューのそれぞれには、（DropThresholdCalculationservice）DTCSインスタンスがあります。そのキューで。したがって、各DTCSインスタンスは正確に1つのキューに結び付けられていますが、複数のDTCSインスタンスで単一のキューを（異なる重量と時間の値で）調べることができます。また、DTCSインスタンスとその背後のキューは、「再利用可能性の単位」と考えることができます。したがって、単一のDTCは複数のRDSVCによって参照できます。
Unless it is overridden by a different rule in a subclass of REDDropperService, the rule that a RED dropper uses to combine the smoothed inputs from the DTCS's to create a value to use in making its drop decision is simple addition.
ReddropPerserviceのサブクラスの別のルールによってオーバーライドされない限り、Red DropperがDTCSからの平滑化された入力を組み合わせて使用して、ドロップ決定を行う際に使用する値を作成するルールは簡単です。
In order to appreciate the rationale behind this rather complex model for scheduling, we must consider the rather complex nature of schedulers, as well as the extreme variations in algorithms and implementations. Although these variations are broad, we have identified four examples that serve to test the model and justify its complexity.
スケジューリングのためのこのかなり複雑なモデルの背後にある理論的根拠を理解するには、スケジューラのかなり複雑な性質と、アルゴリズムと実装の極端なバリエーションを考慮する必要があります。これらのバリエーションは広範ですが、モデルをテストし、その複雑さを正当化するのに役立つ4つの例を特定しました。
A simple, hierarchical scheduler has the following properties. First, when a scheduling opportunity is given to a set of queues, a single, viable queue is determined based on some scheduling criteria, such as bandwidth or priority. The output of the scheduler is the input to another scheduler that treats the first scheduler (and its queues) as a single logical queue. Hence, if the first scheduler determined the appropriate packet to release based on a priority assigned to each queue, the second scheduler might specify a bandwidth limit/allocation for the entire set of queues aggregated by the first scheduler.
シンプルで階層的なスケジューラには、次のプロパティがあります。まず、スケジューリングの機会が一連のキューに与えられると、帯域幅や優先度などのいくつかのスケジューリング基準に基づいて、単一の実行可能なキューが決定されます。スケジューラの出力は、最初のスケジューラ（およびそのキュー）を単一の論理キューとして扱う別のスケジューラへの入力です。したがって、最初のスケジューラが各キューに割り当てられた優先度に基づいてリリースする適切なパケットを決定した場合、2番目のスケジューラは、最初のスケジューラによって集約されたキューのセット全体の帯域幅制限/割り当てを指定する場合があります。
+----------+ NextService
|QueuingSvc+----------------------------------------------+
| Name=EF1 | |
| | QueueTo +--------------+ ElementSched |
| +------------+PrioritySched +---------------+ |
+----------+ Schedule |Element | Service | |
| Name=EF1-Pri | | v
| Priority=1 | +-----------+-+-+
+--------------+ |SchedulingSvc +
| Name=PriSched1+
+--------------+ +----------+--+-+
|PrioritySched | ElementSched | ^
+----------+ |Element +---------------+ |
|QueuingSvc| QueueTo | Name=AF1x-Pri| Service |
| Name=AF1x+------------+ Priority=2 | |
| | Schedule +--------------+ |
| | NextService |
| +----------------------------------------------+
+----------+
:
+---------------+ NextScheduler
|SchedulingSvc +--------------------------------------------+
| Name=PriSched1| |
+-------+-------+ +--------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling+--------+ |
+---------------+Element | | |
| Name=PriSched1-Band| | |
| Units=Bytes | | v
| Bandwidth=100 | +------+------+--+
+--------------------+ |SchedulingSvc |
| Name=BandSched1|
+--------------------+ +------+------+--+
|AllocationScheduling| | ^
+---------------+ |Element +--------+ |
|QueuingService | | Name=BE-Band |ElementSchedSvc|
| Name=BE |QueueTo+ Units=Bytes | |
| |-------+ Bandwidth=50 | |
| |Sched +--------------------+ |
| | NextService |
| +--------------------------------------------+
+---------------+
Figure 5. Example 1: Simple Hierarchical Scheduler Figure 5 illustrates the example and how it would be instantiated using the model. In the figure, NextService determines the first scheduler after the queue. NextScheduler determines the subsequent ordering of schedulers. In addition, the ElementSchedulingService association determines the set of scheduling parameters used by a specific scheduler. Scheduling parameters can be bound either to queues or to schedulers. In the case of the SchedulingElement EF1-Pri, the binding is to a queue, so the QueueToSchedule association is used. In the case of the SchedulingElement PriSched1-Band, the binding is to another scheduler, so the SchedulerToSchedule association is used. Note that due to space constraints of the document, the SchedulingService PRISched1 is represented twice, to show how it is connected to all the other objects.
図5.例1：単純な階層スケジューラー図5は、モデルを使用してその例とそれがどのようにインスタンス化されるかを示しています。図では、NextServiceがキュー後の最初のスケジューラを決定します。NextSchedulerは、スケジューラの後続の順序を決定します。さらに、ElementsSchedulingservice Associationは、特定のスケジューラが使用するスケジューリングパラメーターのセットを決定します。スケジューリングパラメーターは、キューまたはスケジューラにバインドできます。スケジューリングエレメントEF1-PRIの場合、バインディングはキューにあるため、Queuetoschedule Associationが使用されます。スケジューリングエレメントがプリシュド1バンドの場合、バインディングは別のスケジューラになるため、スケジュールトスシェッドアソシエーションが使用されます。ドキュメントのスペースの制約により、SchedulingService Prisched1は2回表現され、他のすべてのオブジェクトにどのように接続されているかを示すことに注意してください。
A complex, hierarchical scheduler has the same characteristics as a simple scheduler, except that the criteria for the second scheduler are determined on a per queue basis rather than on an aggregate basis. One scenario might be a set of bounded priority schedulers. In this case, each queue is assigned a relative priority. However, each queue is also not allowed to exceed a bandwidth allocation that is unique to that queue. In order to support this scenario, the queue must be bound to two separate schedulers. Figure 6 illustrates this situation, by describing an EF queue and a best effort (BE) queue both pointing to a priority scheduler via the NextService association. The NextScheduler association between the priority scheduler and the bandwidth scheduler in turn defines the ordering of the scheduling hierarchy. Also note that each scheduler has a distinct set of scheduling parameters that are bound back to each queue. This demonstrates the need to support two or more parameter sets on a per queue basis.
複雑で階層的なスケジューラは、2番目のスケジューラの基準が合計ではなくキューごとに決定されることを除いて、単純なスケジューラと同じ特性を持っています。1つのシナリオは、限界優先度スケジューラのセットになる可能性があります。この場合、各キューには相対的な優先度が割り当てられます。ただし、各キューは、そのキューに固有の帯域幅の割り当てを超えることも許可されていません。このシナリオをサポートするには、キューを2つの別々のスケジューラにバインドする必要があります。図6は、EFキューと最善の努力（BE）キューを説明することにより、この状況を示しています。優先順位スケジューラと帯域幅スケジューラとの間の次のスケジューラー関連は、スケジューリング階層の順序付けを定義します。また、各スケジューラには、各キューにバックバインドされるスケジューリングパラメーターの明確なセットがあることに注意してください。これは、キューごとに2つ以上のパラメーターセットをサポートする必要性を示しています。
+----------------+
|QueuingService |
| Name=EF |
| |QueueTo +----------------+ElementSchedSvc
| +----------+AllocationSched +--------+
++---+-----------+Schedule |Element | |
| | | Name=BandEF | |
| |QueueTo | Units=Bytes | |
| |Schedule | Bandwidth=100 | |
| | +----------------+ +------+---------+
| | |SchedulingSvc |
| | +------------------+ | Name=BandSched |
| +------+PriorityScheduling| +------------+--++
| |Element | ^ |
| | Name=PriEF |ElementSchedSvc | |
| | Priority=1 +---------------------+ | |
| +------------------+ | | |
|NextService | | |
+-------------------------------------------------+ | | |
| | | |
NextService | | | |
+-----------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |PriorityScheduling+--------+ | | | | |
| |Element | | | | | | |
| | Name=PriBE | | v v | | |
| +------+ Priority=2 | +---+--------+-+-+-+Next| |
| | +------------------+ |SchedulingService +----+ |
| | | Name=PriSched |Sched |
| | +------------------+ |
| |QueueTo |
| |Schedule +----------------+ |
| | |AllocationSched |ElementSchedSvc |
+----+---------+ |Element +-----------------+
|QueuingService|QueueTo | Name=BandBE |
| Name=BE +------------+ Units=Bytes |
| |Schedule | Bandwidth=50 |
| | +----------------+
+--------------+
Figure 6. Example 2: Complex Hierarchical Scheduler
図6.例2：複雑な階層スケジューラー
An excess capacity scheduler offers a similar requirement to support two scheduling parameter sets per queue. However, in this scenario the reasons are a little different. Suppose a set of queues have each been assigned bandwidth limits to ensure that no traffic class starves out another traffic class. The result may be that one or more queues have exceeded their allocation while the queues that deserve scheduling opportunities are empty.
過剰容量スケジューラは、キューごとに2つのスケジューリングパラメーターセットをサポートするための同様の要件を提供します。ただし、このシナリオでは、その理由は少し異なります。一連のキューがそれぞれ帯域幅の制限が割り当てられていると仮定し、トラフィッククラスが別のトラフィッククラスを飢えないようにします。その結果、スケジューリングの機会に値するキューが空である一方で、1つ以上のキューが割り当てを超えている可能性があります。
The question then is how is the excess (idle) bandwidth allocated. Conceivably, the scheduling criteria for excess capacity are completely different from the criteria that determine allocations under uniform load. This could be supported with a scheduling hierarchy. However, the problem is that the criteria for using the subsequent scheduler are different from those in the last two cases. Specifically, the next scheduler should only be used if a scheduling opportunity exists that was passed over by the prior scheduler.
問題は、過剰な（アイドル）帯域幅がどのように割り当てられるのかということです。おそらく、過剰容量のスケジューリング基準は、均一な負荷の下での割り当てを決定する基準とはまったく異なります。これは、スケジューリング階層でサポートできます。ただし、問題は、後続のスケジューラを使用するための基準が過去2つのケースの基準とは異なることです。具体的には、次のスケジューラは、前のスケジューラによって引き継がれたスケジューリングの機会が存在する場合にのみ使用する必要があります。
When a scheduler chooses to forgo a scheduling decision, it is behaving as a non-work conserving scheduler. Work conserving schedulers, by definition, will always take advantage of a scheduling opportunity, irrespective of which queue is being serviced and how much bandwidth it has consumed in the past. This point leads to an interesting insight. The semantics of a non-work conserving scheduler are equivalent to those of a meter, in that if a packet is in profile it is given the scheduling opportunity, and if it is out of profile it does not get a scheduling opportunity. However, with meters there are semantics that determine the next action behavior when the packet is in profile and when the packet is out of profile. Similarly, with the non-work conserving scheduler, there needs to be a means for determining the next scheduler when a scheduler chooses not to utilize a scheduling opportunity.
スケジューラがスケジューリングの決定を控えることを選択すると、それは非加工の保全スケジューラとして動作します。定義上、スケジューラーを保存することは、どのキューが整備されているか、過去にどれだけの帯域幅を消費したかに関係なく、常にスケジューリングの機会を利用します。この点は興味深い洞察につながります。非加工の保存スケジューラのセマンティクスはメーターのセマンティクスに相当します。パケットがプロファイルにある場合、スケジューリングの機会が与えられ、それがプロファイルが外れている場合、スケジューリングの機会が得られないからです。ただし、メーターには、パケットがプロファイルにあるときとパケットがプロファイルが外れているときに次のアクション動作を決定するセマンティクスがあります。同様に、非作業保護スケジューラを使用すると、スケジューラがスケジューリングの機会を利用しないことを選択したときに、次のスケジューラを決定するための手段が必要です。
Figure 7 illustrates this last scenario. It appears very similar to Figure 6, except that the binding between the allocation scheduler and the WRR scheduler is using a FailNextScheduler association. This association is explicitly indicating the fact that the only time the WRR scheduler would be used is when there are non-empty queues that the allocation scheduler rejected for scheduling consideration. Note that Figure 7 is incomplete, in that typically there would be several more queues that are bound to an allocation scheduler and a WRR scheduler.
図7は、この最後のシナリオを示しています。割り当てスケジューラとWRRスケジューラの間のバインディングがFailNextScheduler Associationを使用していることを除いて、図6に非常に似ているように見えます。この関連付けは、WRRスケジューラが使用される唯一の時間が、配分スケジューラが検討のために拒否した非空白のキューがある場合だけであるという事実を明示的に示しています。図7は不完全であることに注意してください。通常、割り当てスケジューラとWRRスケジューラに縛られたいくつかのキューがあるからです。
+------------+
|QueuingSvc |
| Name=EF |
| |
| |
++-+---------+
| |
| |QueueTo
| |Schedule +--------------+
| | |SchedulingSvc |
| | +------------------+ | Name=WRRSched|
| +------+AllocationSched | +----------+-+-+
| |Element | ^ |
| | Name=BandEF |ElementSchedSvc | |
| | Units=Bytes +--------------------+ | |
| | Bandwidth=100 | | | |
| +------------------+ | | |
|NextService | | |
+----------------------------------------------+ | | |
| | | |
NextService | | | |
+--------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |AllocationSched +--------+ | | | | |
| |Element | | | | | | |
| | Name=BandwidthAF1| | | | | | |
| | Units=Bytes | | v v | | |
| +------+ Bandwidth=50 | +--+----------+-+-++FailNext| |
| | +------------------+ |SchedulingService +--------+ |
| |QueueTo | Name=BandSched |Scheduler |
| |Schedule +------------------+ |
| | |
| | +---------------------+ |
++-+-----------+ | WRRSchedulingElement| |
|QueuingService|QueueTo | Name=WRRBE +------------+
| Name=BE +-----------+ Weight=30 |ElementSchedSvc
+--------------+Schedule +---------------------+
Figure 7. Example 3: Excess Capacity Scheduler
図7.例3：過剰容量スケジューラ
A hierarchical class-based queuing (CBQ) scheduler is the fourth scenario to be considered. In hierarchical CBQ, each queue is allocated a specific bandwidth allocation. Queues are grouped together into a logical scheduler. This logical scheduler in turn has an aggregate bandwidth allocation that equals the sum of the queues it is scheduling. In turn, logical schedulers can be aggregated into higher-level logical schedulers. Changing perspectives and looking top down, the top-most logical scheduler has 100% of the link capacity. This allocation is parceled out to logical schedulers below it such that the sum of the allocations is equal to 100%. These second tier schedulers may in turn parcel out their allocation across a third tier of schedulers and so forth until the lowest tier that parcels out their allocations to specific queues representing relatively fine-grained classes of traffic. The unique aspect of hierarchical CBQ is that when there is insufficient bandwidth for a specific allocation, schedulers higher in the tree are tested to see if another portion of the tree has capacity to spare.
階層的なクラスベースのキューイング（CBQ）スケジューラは、考慮すべき4番目のシナリオです。階層CBQでは、各キューに特定の帯域幅割り当てが割り当てられます。キューは、一緒に論理スケジューラにグループ化されます。この論理スケジューラには、スケジューリングであるキューの合計に等しい帯域幅割り当てが順番にあります。次に、論理スケジューラを高レベルの論理スケジューラーに集約できます。視点を変えて上下に見えると、最上位の論理スケジューラには、リンク容量の100％があります。この割り当ては、割り当ての合計が100％に等しくなるように、その下の論理スケジュールに分類されます。これらの2番目のティアスケジューラは、比較的細かいクラスのトラフィックを表す特定のキューに割り当てを配置する最下層の層まで、スケジューラーの3番目のティアなどで割り当てを分割することができます。階層的なCBQのユニークな側面は、特定の割り当てに帯域幅が不十分な場合、ツリー内のスケジューラがテストされて、ツリーの別の部分が余裕があるかどうかを確認することです。
Figure 8 demonstrates this example with two tiers. The example is split in half because of space constraints, resulting in the CBQTier1 scheduling service instance being represented twice. Note that the total allocation at the top tier is 50 Mb. The voice allocation is 22 Mb. The remaining 23 Mb is split between FTP and Web. Hence, if Web traffic is actually consuming 20 Mb (5 Mb in excess of the allocation). If FTP is consuming 5 Mb, then it is possible for the CBQTier1 scheduler to offer 3Mb of its allocation to Web traffic. However, this is not enough, so the FailNextScheduler association needs to be traversed to determine if there is any excess capacity available from the voice class. If the voice class is only consuming 15 Mb of its 22 Mb allocation, there are sufficient resources to allow the web traffic through. Note that FailNextScheduler is used as the association. The reason is because the CBQTier1 scheduler in fact failed to schedule a packet because of insufficient resources. It is conceivable that a variant of hierarchical CBQ allows a hierarchy for successful scheduling as well. Hence, both associations are necessary.
図8は、この例を2つの層で示しています。この例は、スペースの制約のために半分に分割され、CBQTIER1スケジューリングサービスインスタンスが2回表現されます。上部層の合計割り当ては50 MBであることに注意してください。音声割り当ては22 MBです。残りの23 MBは、FTPとWebの間に分割されます。したがって、Webトラフィックが実際に20 MB（割り当てを超える5 MBを超える）を消費している場合。FTPが5 MBを消費している場合、CBQTier1スケジューラが3MBのWebトラフィックへの割り当てを提供することが可能です。ただし、これで十分ではないため、Voiceクラスから利用可能な過剰容量があるかどうかを判断するために、FailNextScheduler Associationを横断する必要があります。音声クラスが22 MBの割り当ての15 MBしか消費していない場合、Webトラフィックを許可するのに十分なリソースがあります。failnextschedulerが関連性として使用されることに注意してください。その理由は、CBQTier1スケジューラが実際にリソースが不十分なためパケットのスケジュールに失敗したためです。階層的なCBQのバリアントにより、スケジューリングを成功させるための階層も可能にすることが考えられます。したがって、両方の関連付けが必要です。
Note that due to space constraints of the document, the SchedulingService CBQTier1 is represented twice, to show how it is connected to all the other objects.
ドキュメントのスペース制約により、SchedulingService CBQTier1は2回表現され、他のすべてのオブジェクトにどのように接続されているかを示すことに注意してください。
+-----------+ NextService
|QueuingSvc +-------------------------------------------+
| Name=Web | |
| |QueueTo+----------------+ ElementSchedSvc |
| +-------+AllocationSched +----------------+ |
+-----------+Sched |Element | | |
| Name=Web-Alloc | | v
| Bandwidth=15 | +-----------+-+-+
+----------------+ |SchedulingSvc +
| Name=CBQTier1 +
+----------------+ +-----------+-+-+
|AllocationSched | ElementSchedSvc| ^
+-----------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=FTP-Alloc | |
| Name=FTP +-------+ Bandwidth=8 | |
| |Sched +----------------+ |
| | NextService |
| +-------------------------------------------+
+-----------+
:
+---------------+ FailNextScheduler
|SchedulingSvc +---------------------------------------------+
| Name=CBQTier1 | |
+-------+-------+ +---------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling +--------+ |
+---------------+Element | | |
| Name=LowPri-Alloc | | |
| Bandwidth=23 | | v
+---------------------+ +-----+------+-+
|SchedulingSvc |
| Name=CBQTop |
+---------------------+ +----------+-+-+
|AllocationScheduling |ElementSchedSvc | ^
+------------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=BE-Band | |
| Name=Voice +-------+ Bandwidth=22 | |
| |Sched +---------------------+ |
| | NextService |
| +------------------------------------------------+
+------------+
Figure 8. Example 4: Hierarchical CBQ Scheduler
図8.例4：階層CBQスケジューラ
The following sections present the class and association hierarchies that together comprise the information model for modeling QoS capabilities at the device level.
次のセクションでは、デバイスレベルでQoS機能をモデル化するための情報モデルを一緒に構成するクラスおよびアソシエーションの階層を示します。
Associations and aggregations are a means of representing relationships between two (or theoretically more) objects. Dependency, aggregation, and other relationships are modeled as classes containing two (or more) object references. It should be noted that aggregations represent either "whole-part" or "collection" relationships. For example, aggregation can be used to represent the containment relationship between a system and the components that constitute the system.
関連性と集約は、2つの（または理論的には）オブジェクト間の関係を表す手段です。依存関係、集約、およびその他の関係は、2つ（またはそれ以上）のオブジェクト参照を含むクラスとしてモデル化されます。集約は、「全部」または「収集」関係のいずれかを表していることに注意する必要があります。たとえば、集約を使用して、システムとシステムを構成するコンポーネントとの間の封じ込め関係を表すことができます。
Since associations and aggregations are classes, they can benefit from all of the object-oriented features that other non-relationship classes have. For example, they can contain properties and methods, and inheritance can be used to refine their semantics such that they represent more specialized types of their superclasses.
関連性と集約はクラスであるため、他の非関連クラスが持つオブジェクト指向のすべての機能の恩恵を受けることができます。たとえば、プロパティと方法を含めることができ、継承を使用してセマンティクスを改良するために、より専門化されたタイプのスーパークラスを表すことができます。
Note that an association (or an aggregation) object is treated as an atomic unit (individual instance), even though it relates/collects/is comprised of multiple objects. This is a defining feature of an association (or an aggregation) - although the individual elements that are related to other objects have their own identities, the association (or aggregation) object that is constructed using these objects has its own identity and name as well.
関連付け/収集/収集/複数のオブジェクトで構成されている場合でも、関連性（または集約）オブジェクトは原子単位（個々のインスタンス）として扱われることに注意してください。これは関連性（または集約）の決定的な機能です - 他のオブジェクトに関連する個々の要素には独自のアイデンティティがありますが、これらのオブジェクトを使用して構築される関連付け（または集約）オブジェクトには独自のアイデンティティと名前もあります。。
It is important to note that associations and aggregations form an inheritance hierarchy that is separate from the class inheritance hierarchy. Although associations and aggregations are typically bi-directional, there is nothing that prevents higher order associations or aggregations from being defined. However, such associations and aggregations are inherently more complex to define, understand, and use. In practice, associations and aggregations of orders higher than binary are rarely used, because of their greatly increased complexity and lack of generality. All of the associations and aggregations defined in this model are binary.
関連性と集約は、クラス継承階層とは別の継承階層を形成することに注意することが重要です。関連性と集約は通常、双方向ですが、高次の関連性や集計が定義されるのを防ぐものは何もありません。ただし、そのような関連性と集約は、定義、理解、および使用するために本質的に複雑です。実際には、複雑さが大幅に増加し、一般性の欠如のために、バイナリよりも高い注文の関連性と集約はめったに使用されません。このモデルで定義されているすべての関連性と集約はバイナリです。
Note also that by definition, associations and aggregations cannot be unary.
また、定義上、関連性と集約は統一できないことに注意してください。
Finally, note that associations and aggregations that are defined between two classes do not affect the classes themselves. That is, the addition or deletion of an association or an aggregation does not affect the interfaces of the classes that it is connecting.
最後に、2つのクラス間で定義されている関連性と集約は、クラス自体に影響しないことに注意してください。つまり、関連性または集約の追加または削除は、接続しているクラスのインターフェイスに影響しません。
The structure of the class, association, and aggregation class inheritance hierarchies for managing the datapaths of QoS devices is shown, respectively, in Figure 9, Figure 10, and Figure 11. The notation (CIMCORE) identifies a class defined in the CIM Core model. Please refer to [CIM] for the definitions of these classes. Similarly, the notation [PCIME] identifies a class defined in the Policy Core Information Model Extensions document. This model has been influenced by [CIM], and is compatible with the Directory Enabled Networks (DEN) effort.
QoSデバイスのデータパスを管理するためのクラス、関連性、および集約クラス継承階層の構造をそれぞれ図9、図10、および図11に示します。。これらのクラスの定義については、[CIM]を参照してください。同様に、表記[PCIME]は、ポリシーコア情報モデル拡張ドキュメントで定義されているクラスを識別します。このモデルは[CIM]の影響を受けており、ディレクトリ対応ネットワーク（den）の取り組みと互換性があります。
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--ConditioningService
| | | |
| | | +--ClassifierService
| | | | |
| | | | +--ClassifierElement
| | | |
| | | +--MeterService
| | | | |
| | | | +--AverageRateMeterService
| | | | |
| | | | +--EWMAMeterService
| | | | |
| | | | +--TokenBucketMeterService
| | | |
| | | +--MarkerService
| | | | |
| | | | +--PreambleMarkerService
| | | | |
| | | | +--TOSMarkerService
| | | | |
| | | | +--DSCPMarkerService
| | | | |
(continued from previous page; the first four elements are repeated for convenience)
（前のページから続く。最初の4つの要素が便利に繰り返される）
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | | | +--8021QMarkerService
| | | |
| | | +--DropperService
| | | | |
| | | | +--HeadTailDropperService
| | | | |
| | | | +--RedDropperService
| | | |
| | | +--QueuingService
| | | |
| | | +--PacketSchedulingService
| | | |
| | | +--NonWorkConservingSchedulingService
| | |
| | +--QoSService
| | | |
| | | +--DiffServService
| | | | |
| | | | +--AFService
| | | |
| | | +--FlowService
| | |
| | +--DropThresholdCalculationService
| |
| +--FilterEntryBase [PCIME]
| | |
| | +--IPHeaderFilter [PCIME]
| | |
| | +--8021Filter [PCIME]
| | |
| | +--PreambleFilter
| |
| +--FilterList [PCIME]
| |
| +--ServiceAccessPoint (CIMCORE)
| |
| +--ProtocolEndpoint
(continued from previous page; the first four elements are repeated for convenience)
（前のページから続く。最初の4つの要素が便利に繰り返される）
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
|
+--Collection (CIMCORE)
| |
| +--CollectionOfMSEs (CIMCORE)
| |
| +--BufferPool
|
+--SchedulingElement
|
+--AllocationSchedulingElement
|
+--WRRSchedulingElement
|
+--PrioritySchedulingElement
|
+--BoundedPrioritySchedulingElement
Figure 9. Class Inheritance Hierarchy The inheritance hierarchy for the associations defined in this document is shown in Figure 10.
図9.クラス継承階層このドキュメントで定義されている関連付けの継承階層を図10に示します。
+--Dependency (CIMCORE)
| |
| +--ServiceSAPDependency (CIMCORE)
| | |
| | +--IngressConditioningServiceOnEndpoint
| | |
| | +--EgressConditioningServiceOnEndpoint
| |
| +--HeadTailDropQueueBinding
| |
| +--CalculationBasedOnQueue
| |
| +--ProvidesServiceToElement (CIMCORE)
| | |
| | +--ServiceServiceDependency (CIMCORE)
| | |
| | +--CalculationServiceForDropper
| |
| +--QueueAllocation
| |
| +--ClassifierElementUsesFilterList
|
+--AFRelatedServices
|
+--NextService
| |
| +--NextServiceAfterClassifierElement
| |
| +--NextScheduler
| |
| +--FailNextScheduler
|
+--NextServiceAfterMeter
|
+--QueueToSchedule
|
+--SchedulingServiceToSchedule
Figure 10. Association Class Inheritance Hierarchy The inheritance hierarchy for the aggregations defined in this document is shown in Figure 11.
図10.アソシエーションクラス継承階層このドキュメントで定義されている集約の継承階層を図11に示します。
+--MemberOfCollection (CIMCORE)
| |
| +--CollectedBufferPool
|
+--Component (CIMCORE)
| |
| +--ServiceComponent (CIMCORE)
| | |
| | +--QoSSubService
| | |
| | +--QoSConditioningSubService
| | |
| | +--ClassifierElementInClassifierService
| |
| +--EntriesInFilterList [PCIME]
|
+--ElementInSchedulingService
Figure 11. Aggregation Class Inheritance Hierarchy
図11.集約クラス継承階層
This section presents the classes and properties that make up the Information Model for describing QoS-related functionality in network devices, including hosts. These definitions are derived from definitions in the CIM Core model [CIM]. Only the QoS-related classes are defined in this document. However, other classes drawn from the CIM Core model, as well as from [PCIME], are described briefly. The reader is encouraged to look at [CIM] and at [PCIME] for further information. Associations and aggregations are defined in Section 4.4.
このセクションでは、ホストを含むネットワークデバイスのQoS関連機能を説明するための情報モデルを構成するクラスとプロパティを示します。これらの定義は、CIMコアモデル[CIM]の定義から派生しています。このドキュメントでは、QoS関連のクラスのみが定義されています。ただし、[PCIME]からCIMコアモデルから描かれた他のクラスについて簡単に説明します。読者は、詳細については[CIM]と[PCIME]を見ることをお勧めします。関連性と集約は、セクション4.4で定義されています。
This is an abstract class defined in the Core Model of CIM. It is the root of the entire class inheritance hierarchy in CIM. Among the associations that refer to it are two that are subclassed in this document: Dependency and MemberOfCollection, which is an aggregation. ManagedElement's properties are Caption and Description. Both are free-form strings to describe an instantiated object. Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。CIMのクラス継承階層全体のルートです。それを参照する関連付けの中には、このドキュメントでサブクラス化されている2つがあります：依存関係とメンバーオフコレクション、これは集約です。ManageDelementのプロパティはキャプションと説明です。どちらも、インスタンス化されたオブジェクトを記述するための自由形式の文字列です。このクラスの完全な定義については、[CIM]を参照してください。
This is an abstract class defined in the Core Model of CIM; it is a subclass of ManagedElement. ManagedSystemElement serves as the base class for the PhysicalElement and LogicalElement class hierarchies. LogicalElement, in turn, is the base class for a number of important CIM hierarchies, including System. Any distinguishable component of a System is a candidate for inclusion in this class hierarchy, including physical components (e.g., chips and cards) and logical components (e.g., software components, services, and other objects).
これは、CIMのコアモデルで定義された抽象クラスです。マネージデリメントのサブクラスです。ManageDsystemElementは、PhysicalElementおよびLogicalElementクラスの階層の基本クラスとして機能します。次に、LogicalElementは、システムを含む多くの重要なCIM階層の基本クラスです。システムの識別可能なコンポーネントは、物理コンポーネント（チップやカードなど）や論理コンポーネント（ソフトウェアコンポーネント、サービス、その他のオブジェクトなど）を含む、このクラス階層に含める候補です。
None of the associations in which this class participates is used directly in the QoS device state model. However, the aggregation Component, which relates one ManagedSystemElement to another, is the base class for the two aggregations that form the core of the QoS device state model: QoSSubService and QoSConditioningSubService. Similarly, the association ProvidesServiceToElement, which relates a ManagedSystemElement to a Service, is the base class for the model's CalculationServiceForDropper association.
このクラスが参加する関連付けは、QoSデバイス状態モデルで直接使用されていません。ただし、1つのManageDsystemElementを別のマネージエレメントに関連付ける集約コンポーネントは、QoSデバイス状態モデルのコアを形成する2つの集約の基本クラスであるQossubsubsitionSubsubserviceです。同様に、Association ProvidesserviceToelementは、Managedsystemelementをサービスに関連付けますが、モデルのCalculationerviceFordopper Associationの基本クラスです。
Please refer to [CIM] for the full definition of this class.
このクラスの完全な定義については、[CIM]を参照してください。
This is an abstract class defined in the Core Model of CIM. It is a subclass of the ManagedSystemElement class, and is the base class for all logical components of a managed System, such as Files, Processes, or system capabilities in the form of Logical Devices and Services. None of the associations in which this class participates is relevant to the QoS device state model. Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。これは、ManageDsystemElementクラスのサブクラスであり、論理デバイスとサービスの形でファイル、プロセス、またはシステム機能など、管理されたシステムのすべての論理コンポーネントの基本クラスです。このクラスが参加する関連付けは、QoSデバイス状態モデルに関連していません。このクラスの完全な定義については、[CIM]を参照してください。
This is an abstract class defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects that represent a "service" or functionality in a System. A Service is a general-purpose object that is used to configure and manage the implementation of functionality. As noted above in section 4.3.2, this class participates in the ProvidesServiceToElement association. Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。これは、LogicalElementクラスのサブクラスであり、システム内の「サービス」または機能を表すすべてのオブジェクトの基本クラスです。サービスは、機能の実装を構成および管理するために使用される汎用オブジェクトです。上記のセクション4.3.2で述べたように、このクラスはProvidesserviceToelement Associationに参加しています。このクラスの完全な定義については、[CIM]を参照してください。
This is a concrete subclass of the CIM Core class Service; it represents the ability to define how traffic is conditioned in the data-forwarding path of a device. The subclasses of ConditioningService define the particular types of conditioning that are done. Six fundamental types of conditioning are defined in this document. These are the services performed by a classifier, a meter, a marker, a dropper, a queue, and a scheduler. Other, more sophisticated types of conditioning may be defined in future documents.
これは、CIMコアクラスサービスの具体的なサブクラスです。これは、デバイスのデータフォワードパスでトラフィックがどのように条件付けられているかを定義する能力を表しています。コンディショニングサービスのサブクラスは、行われた特定のタイプの条件付けを定義します。このドキュメントでは、6つの基本タイプの条件付けが定義されています。これらは、分類器、メーター、マーカー、ドロッパー、キュー、スケジューラによって実行されるサービスです。他のより洗練されたタイプのコンディショニングは、将来のドキュメントで定義される場合があります。
ConditioningService is a concrete class because at the time it was defined in CIM, its superclass was concrete. While this class can be instantiated, an instance of it would not accomplish anything, because the nature of the conditioning, and the parameters that control it, are specified only in the subclasses of ConditioningService.
条件付けサービスは、CIMで定義されていたときにスーパークラスが具体的だったため、具体的なクラスです。このクラスはインスタンス化できますが、コンディショニングの性質とそれを制御するパラメーターは、条件付けサービスのサブクラスでのみ指定されているため、そのインスタンスは何も達成できません。
Two associations in which ConditioningService participates are critical to its usage in QoS - QoSConditioningSubService and NextService. QoSConditioningSubService aggregates ConditioningServices into a particular QoS service (such as AF), to describe the specific conditioning functionality that underlies that QoS service in a particular device. NextService indicates the subsequent conditioning service(s) for different traffic streams.
条件付けサービスが参加する2つの協会は、QoS -QosconditionSubserviceとNextServiceでの使用に不可欠です。QosconditionSubSubserviceは、特定のデバイスでのQoSサービスの根底にある特定の条件付け機能を説明するために、特定のQoSサービス（AFなど）にコンディショニングサービスを集約します。NextServiceは、さまざまなトラフィックストリームの後続のコンディショニングサービスを示します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME ConditioningService
DESCRIPTION A concrete class to define how traffic
is conditioned in the data forwarding
path of a host or network device.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)
The concept of a Classifier comes from [DSMODEL]. ClassifierService is a concrete class that represents a logical entity in an ingress or egress interface of a device, that takes a single input stream, and sorts it into one or more output streams. The sorting is done by a set of filters that select packets based on the packet contents, or possibly based on other attributes associated with the packet. Each output stream is the result of matching a particular filter.
分類器の概念は[dsmodel]から来ています。ClassifierServiceは、デバイスの侵入または出口インターフェイスの論理エンティティを表す具体的なクラスであり、単一の入力ストリームを取得し、1つ以上の出力ストリームに並べ替えます。ソートは、パケットのコンテンツに基づいて、またはパケットに関連付けられた他の属性に基づいてパケットを選択するフィルターのセットによって行われます。各出力ストリームは、特定のフィルターと一致した結果です。
The representation of classifiers in QDDIM is closely related to that presented in [DSMIB] and [DSMODEL]. Rather than being linked directly to its FilterLists, a classifier is modeled here as an aggregation of ClassifierElements. Each of these ClassifierElements is then linked to a single FilterList, by the association ClassifierElementUsesFilterList.
QDDIMの分類器の表現は、[DSMIB]および[DSModel]で提示されたものと密接に関連しています。このフィルターリストに直接リンクするのではなく、分類器は分類の集合としてモデル化されています。これらの各分類は、Association classifierElementusesfilterlistによって、単一のフィルターリストにリンクされます。
A Classifier is modeled as a subclass of ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService aggregation), and can use the NextService association to identify the subsequent ConditioningService objects for the different traffic streams.
分類器は、条件付けサービスのサブクラスとしてモデル化されているため、qosservice（qosconditioningsubservice集約を使用）に集約でき、NextService Associationを使用して、さまざまなトラフィックストリームの後続のコンディショニングサービスオブジェクトを特定できます。
ClassifierService is designed to allow hierarchical classification. When hierarchical classification is used, a ClassifierElement may point to another ClassifierService. When used for this purpose, the ClassifierElement must not use the ClassifierElementUsesFilterList association.
ClassifierServiceは、階層分類を可能にするように設計されています。階層分類が使用される場合、分類は別の分類器サービスを指す場合があります。この目的に使用する場合、classifierElementはclassifierementusesfilterlist Associationを使用してはなりません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME ClassifierService
DESCRIPTION A concrete class describing how an input
traffic stream is sorted into multiple
output streams using one or more
filters.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)
The concept of a ClassifierElement comes from [DSMIB]. This concrete class represents the linkage, within a single ClassifierService, between a FilterList that specifies a set of criteria for selecting packets from the stream of packets coming into the ClassifierService, and the next ConditioningService to which the selected packets go after they leave the ClassifierService. ClassifierElement has no properties of its own. It is present to serve as the anchor for an aggregation with its classifier, and for associations with its FilterList and its next ConditioningService.
ClassifierElementの概念は[dsmib]に由来します。このコンクリートクラスは、単一の分類器サービス内のリンケージを表します。フィルターリストは、分類環境に入ってくるパケットのストリームからパケットを選択するための一連の基準を指定し、選択したパケットがClassifierServiceを離れた後に移動する次の条件付けサービスを表します。ClassifierElementには、独自の特性がありません。分類器との集合体のアンカーとして、およびそのフィルターリストと次の条件付けサービスとの関連のアンカーとして機能することが存在します。
When a ClassifierElement is associated with a ClassifierService through the NextServiceAfterClassifierElement association, the ClassifierElement may not use the ClassifierElementUsesFilterList association. Further, when a ClassifierElement is associated with a ClassifierService as described above, the order of processing of the associated ClassifierService is a function of the ClassifierOrder property of the ClassifierElementInClassifierService aggregation. For example, lets assume the following:
classifierelementがNextServicefterclassifierElement Associationを通じて分類係数に関連付けられている場合、classifierelementはclassifierelementususesfilterlist Associationを使用することはできません。さらに、分類が上記のように分類装置に関連付けられている場合、関連する分類環境サービスの処理順序は、分類inclassifierserviceの凝集の分類装置プロパティの関数です。たとえば、以下を想定しましょう。
1. ClassifierService (C1) aggregates ClassifierElements (E1), (E2) and (E3), with relative ClassifierOrder values of 1, 2, and 3.
1. ClassifierService（C1）は、1、2、および3の相対分類装置の値を持つ分類（E1）、（E2）、および（E3）を集約します。
2. ClassifierElements (E1) and (E3) associations to FilterLists (F1) and (F3) respectively using the ClassifierElementUsesFilterList association.
2. ClassifierElements（E1）および（E3）Associations to FilterLists（F1）および（F3）ClassifierElementUsesFilterList Associationを使用します。
3. (E1) & (E3) are associated with Meters (M1) and (M3) through their respective NextServiceAfterClassifierElement associations.
3. （e1）＆（e3）は、それぞれの次のサービスを介してメーター（M1）および（M3）に関連付けられています。
4. (E2) is associated with ClassifierService (C2) through its NextServiceAfterClassifierElement association.
4. （e2）は、次のサービスaffterclassifierelement Associationを通じて、分類サービス（C2）に関連付けられています。
5. ClassifierService (C2) aggregates ClassifierElements (E4) and (E5) with relative ClassifierOrder values of 1 and 2.
5. ClassifierService（C2）は、1および2の相対分類装置の値を持つ分類（E4）および（E5）を集約します。
6. ClassifierElements (E4) and (E5) have associations to FilterLists (F4) and (F5) respectively using the ClassifierElementUsesFilterList association.
6. ClassifierElements（E4）および（E5）は、それぞれClassifierElementUsesFilterList Associationを使用して、フィルターリスト（F4）および（F5）に関連付けられています。
In this example, packet processing would match FilterLists in the order of (F1), (F4), (F5), and (F3).
この例では、パケット処理は、（f1）、（f4）、（f5）、および（f3）の順にフィルターリストを一致させます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME ClassifierElement
DESCRIPTION A concrete class representing
the process by which a classifier
uses a filter to select packets
to forward to a specific next
conditioning service.
DERIVED FROM ClassifierService
TYPE Concrete
PROPERTIES (none)
This is a concrete class that represents the metering of network traffic. Metering is the function of monitoring the arrival times of packets of a traffic stream, and determining the level of conformance of each packet with respect to a pre-established traffic profile. A meter has the ability to invoke different ConditioningServices for conforming and non-conforming traffic. Traffic leaving a meter may be further conditioned (e.g., dropped or queued) by routing the packet to another conditioning element. Please see [DSMODEL] for more information on metering.
これは、ネットワークトラフィックの計量を表す具体的なクラスです。計量とは、トラフィックストリームのパケットの到着時間を監視し、事前に確立されたトラフィックプロファイルに対する各パケットの適合レベルを決定する機能です。メーターには、適合と不適合のトラフィックのためのさまざまな条件付けサービスを呼び出す機能があります。メーターを離れるトラフィックは、パケットを別のコンディショニング要素にルーティングすることにより、さらに条件付けられます（たとえば、ドロップまたはキードされました）。メータリングの詳細については、[dsmodel]を参照してください。
This class is the base class for defining different types of meters. As such, it contains common properties that all meter subclasses share. It is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association), to indicate that its functionality underlies that QoS service. MeterService also participates in the NextServiceAfterMeter association, to identify the subsequent ConditioningService objects for conforming and non-conforming traffic.
このクラスは、さまざまな種類のメーターを定義するための基本クラスです。そのため、すべてのメーターサブクラスが共有する一般的なプロパティが含まれています。条件付けサービスとしてモデル化されているため、QOSService（QosconditionSubservice Associationを使用）に集約できるようにして、その機能がQoSサービスの根底にあることを示します。MeterServiceは、NextServiceAftermeter Associationにも参加して、適合および不適合なトラフィックのための後続の条件付けサービスオブジェクトを特定します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME MeterService
DESCRIPTION A concrete class describing the
monitoring of traffic with respect to a
pre-established traffic profile.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES MeterType, OtherMeterType,
ConformanceLevels
Note: The MeterType property and the MeterService subclasses provide similar information. The MeterType property is defined for query purposes and for future expansion. It is possible that not all MeterServices will require a subclass to define them. In these cases, MeterService will be instantiated directly, and the MeterType property will provide the only way of identifying the type of the meter.
注：MeterTypeプロパティとMeterServiceサブクラスは、同様の情報を提供します。Metertypeプロパティは、クエリ目的と将来の拡張のために定義されています。すべてのメーターサービスがそれらを定義するためにサブクラスを必要とするとは限りません。これらの場合、MeterServiceが直接インスタンス化され、MeterTypeプロパティはメーターのタイプを識別する唯一の方法を提供します。
This property is an enumerated 16-bit unsigned integer that is used to specify the particular type of meter represented by an instance of MeterService. The following enumeration values are defined:
このプロパティは、メーターサービスのインスタンスで表される特定のタイプのメーターを指定するために使用される列挙された16ビットの非署名整数です。次の列挙値が定義されています。
1 - Other 2 - Average Rate Meter 3 - Exponentially Weighted Moving Average Meter 4 - Token Bucket Meter
1-その他2-平均レートメーター3-指数関数的に重み付けされた移動平均メーター4-トークンバケットメーター
Note: if the value of MeterType is not one of these four values, it SHOULD be interpreted as if it had the value '1' (Other).
注：MeterTypeの値がこれらの4つの値のいずれかでない場合、値「1」（その他）があるかのように解釈する必要があります。
This is a string property that defines a vendor-specific description of a type of meter. It is used when the value of the MeterType property in the instance is equal to 1.
これは、メーターの種類のベンダー固有の説明を定義する文字列プロパティです。インスタンスのMeterTypeプロパティの値が1に等しい場合に使用されます。
This property is a 16-bit unsigned integer. It indicates the number of conformance levels supported by the meter. For example, when only "in profile" versus "out of profile" metering is supported, ConformanceLevels is equal to 2.
このプロパティは、16ビットの署名のない整数です。メーターがサポートする適合レベルの数を示します。たとえば、「プロファイル」と「プロファイル外」メーターのみがサポートされている場合、コンフォーマンセレベルは2に等しくなります。
This is a concrete subclass of MeterService that represents a simple meter, called an Average Rate Meter. This type of meter measures the average rate at which packets are submitted to it over a specified time. Packets are defined as conformant if their average arrival rate does not exceed the specified measuring rate of the meter. Any packet that causes the specified measuring rate to be exceeded is defined to be non-conforming. For more information, please see [DSMODEL].
これは、平均レートメーターと呼ばれる単純なメーターを表すMeterServiceの具体的なサブクラスです。このタイプのメーターは、指定された時間にわたってパケットが提出される平均レートを測定します。パケットは、平均到着率が指定されたメーターの測定レートを超えない場合、コンフォーマントとして定義されます。指定された測定レートを超えているパケットは、不適合であると定義されます。詳細については、[dsmodel]を参照してください。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME AverageRateMeterService
DESCRIPTION A concrete class classifying traffic as
either conforming or non-conforming,
depending on whether the arrival of a
packet causes the average arrival rate
to exceed a pre-determined value.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, DeltaInterval
This is an unsigned 32-bit integer that defines the rate used to determine whether admitted packets are in conformance or not. The value is specified in kilobits per second.
これは、認められたパケットが適合かどうかを判断するために使用されるレートを定義する署名されていない32ビット整数です。値は1秒あたりのキロビットで指定されています。
This is an unsigned 64-bit integer that defines the time period over which the average measurement should be taken. The value is specified in microseconds.
これは、平均測定を行う必要がある期間を定義する署名されていない64ビット整数です。値はマイクロ秒単位で指定されています。
This is a concrete subclass of the MeterService class that represents an exponentially weighted moving average meter. This meter is a simple low-pass filter that measures the rate of incoming packets over a small, fixed sampling interval. Any admitted packet that pushes the average rate over a pre-defined limit is defined to be non-conforming. Please see [DSMODEL] for more information.
これは、指数関数的に重み付けされた移動平均メーターを表すMeterServiceクラスの具体的なサブクラスです。このメーターは、小さな固定サンプリング間隔で着信パケットの速度を測定する単純なローパスフィルターです。事前定義された制限にわたって平均レートをプッシュする認められたパケットは、不適合であると定義されます。詳細については、[dsmodel]を参照してください。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME EWMAMeterService
DESCRIPTION A concrete class classifying admitted
traffic as either conforming or non-
conforming, depending on whether the
arrival of a packet causes the average
arrival rate in a small fixed
sampling interval to exceed a
pre-determined value or not.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, DeltaInterval, Gain
This property is an unsigned 32-bit integer that defines the average rate against which the sampled arrival rate of packets should be measured. Any packet that causes the sampled rate to exceed this rate is deemed non-conforming. The value is specified in kilobits per second.
このプロパティは、サンプリングされたパケットの到着率を測定する平均レートを定義する署名されていない32ビット整数です。サンプリングレートをこのレートを超えるパケットは、不適合と見なされます。値は1秒あたりのキロビットで指定されています。
This property is an unsigned 64-bit integer that defines the sampling interval used to measure the arrival rate. The calculated rate is averaged over this interval and checked against the AverageRate property. All packets whose computed average arrival rate is less than the AverageRate are deemed conforming.
このプロパティは、到着率を測定するために使用されるサンプリング間隔を定義する署名されていない64ビット整数です。計算されたレートはこの間隔で平均化され、平均プロパティに対してチェックされます。計算された平均到着率がAveragerateよりも少ないすべてのパケットは、適合と見なされます。
The value is specified in microseconds.
値はマイクロ秒単位で指定されています。
This property is an unsigned 32-bit integer representing the reciprocal of the time constant (e.g., frequency response) of what is essentially a simple low-pass filter. For example, the value 64 for this property represents a time constant value of 1/64.
このプロパティは、本質的に単純なローパスフィルターの時代定数（たとえば、周波数応答）の相互の相互を表す、署名されていない32ビット整数です。たとえば、このプロパティの値64は、1/64の時定数値を表します。
This is a concrete subclass of the MeterService class that represents the metering of network traffic using a token bucket meter. Two types of token bucket meters are defined using this class - a simple, two-parameter bucket meter, and a multi-stage meter.
これは、トークンバケットメーターを使用したネットワークトラフィックの計量を表すMeterServiceクラスの具体的なサブクラスです。このクラスを使用して、2種類のトークンバケットメーターが定義されています。シンプルな2パラメーターバケットメーターとマルチステージメーターです。
A simple token bucket usually has two parameters, an average token rate and a burst size, and has two conformance levels: "conforming" and "non-conforming". This class also defines an excess burst size, which enables the meter to have three conformance levels ("conforming", "partially conforming", and "non-conforming"). In this case, packets that exceed the excess burst size are deemed non-conforming, while packets that exceed the smaller burst size but are less than the excess burst size are deemed partially conforming. Operation of these meters is described in [DSMODEL].
単純なトークンバケットには、通常、平均トークンレートとバーストサイズの2つのパラメーターがあり、2つの適合レベルがあります。「適合」と「不適合」です。また、このクラスは過剰なバーストサイズを定義します。これにより、メーターは3つの適合レベル（「適合」、「部分的に適合する」、および「不適合」）を持つことができます。この場合、過剰バーストサイズを超えるパケットは不適合と見なされますが、バーストサイズが小さいが過剰なバーストサイズよりも少ないパケットは、部分的に適合していると見なされます。これらのメーターの動作は[dsmodel]で説明されています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME TokenBucketMeterService
DESCRIPTION A concrete class classifying admitted
traffic with respect to a token bucket.
Either two or three levels of
conformance can be defined.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize
This property is an unsigned 32-bit integer that specifies the committed rate of the meter. The value is expressed in kilobits per second.
このプロパティは、メーターのコミットされたレートを指定する署名されていない32ビット整数です。値は1秒あたりのキロビットで表されます。
This property is an unsigned 32-bit integer that specifies the peak rate of the meter. The value is expressed in kilobits per second.
このプロパティは、メーターのピークレートを指定する署名されていない32ビット整数です。値は1秒あたりのキロビットで表されます。
This property is an unsigned 32-bit integer that specifies the maximum number of tokens available for the committed rate (specified by the AverageRate property). The value is expressed in kilobytes.
このプロパティは、コミットレートで利用可能な最大数のトークンを指定する署名されていない32ビット整数です（Averagerateプロパティで指定）。値はキロバイトで表されます。
This property is an unsigned 32-bit integer that specifies the maximum number of tokens available for the peak rate (specified by the PeakRate property). The value is expressed in kilobytes.
このプロパティは、ピークレート（ピークレートプロパティで指定）で利用可能な最大数のトークンを指定する署名されていない32ビット整数です。値はキロバイトで表されます。
This is a concrete class that represents the general process of marking some field in a network packet with some value. Subclasses of MarkerService identify particular fields to be marked, and introduce properties to represent the values to be used in marking these fields. Markers are usually invoked as a result of a preceding classifier match. Operation of markers of various types is described in [DSMODEL].
これは、ネットワークパケット内の一部のフィールドを何らかの価値でマークする一般的なプロセスを表す具体的なクラスです。MarkerServiceのサブクラスは、マークされる特定のフィールドを識別し、これらのフィールドをマークする際に使用される値を表すプロパティを導入します。マーカーは通常、前の分類器マッチの結果として呼び出されます。さまざまなタイプのマーカーの操作は、[dsmodel]で説明されています。
MarkerService is a concrete class because at the time it was defined in CIM, its superclass was concrete. While this class can be instantiated, an instance of it would not accomplish anything, because both the field to be marked and the value to be used to mark it are specified only in subclasses of MarkerService.
MarkerServiceは具体的なクラスです。なぜなら、CIMで定義されていたとき、そのスーパークラスは具体的だったからです。このクラスはインスタンス化できますが、マークされるフィールドとマークに使用する値の両方がMarkerServiceのサブクラスでのみ指定されているため、そのインスタンスは何も達成できません。
MarkerService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService object that acts on traffic after it has been marked by the marker.
MarkerServiceは条件付けサービスとしてモデル化されているため、QOSService（QosconditionSubservice Associationを使用）に集約して、その機能がQoSサービスの根底にあることを示します。NextService Associationに参加して、マーカーによってマークされた後にトラフィックに作用する後続の条件付けサービスオブジェクトを特定します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME MarkerService
DESCRIPTION A concrete class representing the
general process of marking a selected
field in a packet with a specified
value. Packets are marked in order
to control the conditioning that
they will subsequently receive.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)
This is a concrete class that models the storing of traffic-conditioning results in a packet preamble. See Section 3.8.3 for a discussion of how, and why, QDDIM models the capability to store these results in a packet preamble. An instance of PreambleMarkerService appends to a packet preamble a two-part string of the form "<type>,<value>". Section 3.8.3 provides a list of the <type> strings defined by QDDIM. Implementations may support other <type>'s in addition to these.
これは、トラフィックコンディショニングの保存をパケットプリアンブルにモデル化する具体的なクラスです。QDDIMがこれらの結果をパケットプリアンブルに保存する機能をモデル化する方法とその理由についての議論については、セクション3.8.3を参照してください。PreamblemarkerServiceのインスタンスは、フォーム「<type>、<value>」の2部構成の文字列をパケットプリアンブルに追加します。セクション3.8.3は、QDDIMによって定義された<Type>文字列のリストを示しています。実装は、これらに加えて他の<タイプ>をサポートする場合があります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME PreambleMarkerService
DESCRIPTION A concrete class representing the saving
of traffic-conditioning results in a
packet preamble.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES FilterItemList[ ]
This property is an ordered list of strings, where each string has the format "<type>,<value>". See Section 3.8.3 for a list of <type>'s defined in QDDIM, and the nature of the associated <value> for each of these types.
このプロパティは、各文字列にフォーマット「<type>、<value>」がある文字列の順序付けられたリストです。QDDIMで定義されている<Type>のリスト、およびこれらの各タイプの関連する<value>の性質については、セクション3.8.3を参照してください。
This is a concrete class that represents the marking of the ToS field in the IPv4 packet header [R791]. Following common practice, the value to be written into the field is represented as an unsigned 8- bit integer.
これは、IPv4パケットヘッダー[R791]のTOSフィールドのマーキングを表す具体的なクラスです。一般的な慣行に続いて、フィールドに書き込まれる値は、署名されていない8ビット整数として表されます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME ToSMarkerService
DESCRIPTION A concrete class representing the
process of marking the type of service
(ToS) field in the IPv4 packet header
with a specified value. Packets are
marked in order to control the
conditioning that they will subsequently
receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES ToSValue
This property is an unsigned 8-bit integer, representing a value to be used for marking the type of service (ToS) field in the IPv4 packet header. The ToS field is defined to be a complete octet, so the range for this property is 0..255. Some implementations, however, require that the lowest-order bit in the ToS field always be '0'. Such an implementation is consequently unable to support an odd TosValue.
このプロパティは、IPv4パケットヘッダーのタイプのサービス（TOS）フィールドをマークするために使用される値を表す、署名されていない8ビット整数です。TOSフィールドは完全なオクテットであると定義されているため、このプロパティの範囲は0..255です。ただし、一部の実装では、TOSフィールドの最低注合のビットが常に「0」であることが必要です。したがって、このような実装は、奇妙なTosValueをサポートすることができません。
This is a concrete class that represents the marking of the differentiated services codepoint (DSCP) within the DS field in the IPv4 and IPv6 packet headers, as defined in [R2474]. Following common practice, the value to be written into the field is represented as an unsigned 8-bit integer.
これは、[R2474]で定義されているように、IPv4およびIPv6パケットヘッダーのDSフィールド内の差別化されたサービスコードポイント（DSCP）のマーキングを表す具体的なクラスです。一般的な慣行に続いて、フィールドに書き込まれる値は、署名されていない8ビット整数として表されます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME DSCPMarkerService
DESCRIPTION A concrete class representing the
process of marking the DSCP field
in a packet with a specified
value. Packets are marked in order
to control the conditioning that
they will subsequently receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES DSCPValue
This property is an unsigned 8-bit integer, representing a value to be used for marking the DSCP within the DS field in an IPv4 or IPv6 packet header. Since the DSCP consists of 6 bits, the values for this property are limited to the range 0..63. When the DSCP is marked, the remaining two bit in the DS field are left unchanged.
このプロパティは、IPv4またはIPv6パケットヘッダーのDSフィールド内のDSCPをマークするために使用される値を表す、署名されていない8ビット整数です。DSCPは6ビットで構成されているため、このプロパティの値は0..63の範囲に制限されています。DSCPがマークされると、DSフィールドの残りの2ビットは変更されません。
This is a concrete class that represents the marking of the user priority field defined in the IEEE 802.1Q specification [IEEE802Q]. Following common practice, the value to be written into the field is represented as an unsigned 8-bit integer.
これは、IEEE 802.1Q仕様[IEEE802Q]で定義されているユーザーの優先度フィールドのマーキングを表す具体的なクラスです。一般的な慣行に続いて、フィールドに書き込まれる値は、署名されていない8ビット整数として表されます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME 8021QMarkerService
DESCRIPTION A concrete class representing the
process of marking the Priority
field in an 802.1Q-compliant frame
with a specified value. Frames are
marked in order to control the
conditioning that they will
subsequently receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES PriorityValue
This property is an unsigned 8-bit integer, representing a value to be used for marking the Priority field in the 802.1Q header. Since the Priority field consists of 3 bits, the values for this property are limited to the range 0..7. When the Priority field is marked, the remaining bits in its octet are left unchanged.
このプロパティは、署名されていない8ビット整数であり、802.1Qヘッダーの優先フィールドをマークするために使用される値を表します。優先フィールドは3ビットで構成されているため、このプロパティの値は範囲0..7に制限されています。優先フィールドがマークされると、オクテットの残りのビットは変更されません。
This is a concrete class that represents the ability to selectively drop network traffic, or to invoke another ConditioningService for further processing of traffic that is not dropped. This is the base class for different types of droppers. Droppers are distinguished by the algorithm that they use to drop traffic. Please see [DSMODEL] for more information about the various types of droppers. Note that this class encompasses both Absolute Droppers and Algorithmic Droppers from [DSMODEL].
これは、ネットワークトラフィックを選択的にドロップする能力を表す具体的なクラス、またはドロップされていないトラフィックのさらなる処理のために別の条件付けサービスを呼び出す能力を表しています。これは、さまざまな種類のドロッパーのベースクラスです。ドロッパーは、トラフィックを落とすために使用するアルゴリズムによって区別されます。さまざまな種類のドロッパーの詳細については、[dsmodel]を参照してください。このクラスには、[dsmodel]の絶対ドロッパーとアルゴリズムドロッパーの両方が含まれることに注意してください。
DropperService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService object that acts on any remaining traffic that is not dropped.
DropPerserviceは条件付けサービスとしてモデル化されているため、Qosservice（QosconditionSubservice Associationを使用）に集約して、その機能がQoSサービスの根底にあることを示します。NextService Associationに参加して、ドロップされていない残りのトラフィックに作用する後続の条件付けサービスオブジェクトを特定します。
NextService has special semantics for droppers, in addition to the general "what happens next" semantics that apply to all ConditioningServices. The queue(s) from which a particular dropper drops packets are identified by following chain(s) of NextService associations "rightwards" from the dropper until they reach a queue.
NextServiceには、すべての条件付けサービスに適用される一般的な「次のこと」セマンティクスに加えて、ドロッパーの特別なセマンティクスがあります。特定のドロッパードロップパケットが、キューに到達するまで、ドロッパーから「右方向」に「右方向」のチェーンをフォローすることによって識別されるキュー。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME DropperService
DESCRIPTION A concrete base class describing the
common characteristics of droppers.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES DropperType, OtherDropperType, DropFrom
Note: The DropperType property and the DropperService subclasses provide similar information. The DropperType property is defined for query purposes, as well as for those cases where a subclass of DropperService is not needed to model a particular type of dropper. For example, the Absolute Dropper defined in [DSMODEL] is modeled as an instance of the DropperService class with its DropperType set to '4' ("Absolute Dropper").
注：DropperTypeプロパティとDropperServiceサブクラスは、同様の情報を提供します。DropperTypeプロパティは、クエリの目的で定義され、特定のタイプのドロッパーをモデル化するためにDropperServiceのサブクラスが必要ない場合があります。たとえば、[dsmodel]で定義されている絶対滴下は、droppertypeが「4」（「絶対ドロッパー」）に設定されたドロッパーサービスクラスのインスタンスとしてモデル化されています。
This is an enumerated 16-bit unsigned integer that defines the type of dropper. Values include:
これは、ドロッパーのタイプを定義する列挙された16ビットの符号なし整数です。値は次のとおりです。
1 - Other 2 - Random 3 - HeadTail 4 - Absolute Dropper
1-その他2-ランダム3-ヘッドテール4-絶対ドロッパー
Note: if the value of DropperType is not one of these four values, it SHOULD be interpreted as if it had the value '1' (Other).
注：DropperTypeの値がこれらの4つの値のいずれかでない場合、値「1」（その他）があるかのように解釈する必要があります。
This string property is used in conjunction with the DropperType property. When the value of DropperType is '1' (i.e., Other), then the name of the type of dropper appears in this property.
この文字列プロパティは、DropperTypeプロパティと組み合わせて使用されます。Droppertypeの値が「1」（つまり、他の）の場合、このプロパティにはドロッパーのタイプの名前が表示されます。
This is an unsigned 16-bit integer enumeration that indicates the point in the associated queue from which packets should be dropped. Defined enumeration values are:
これは、パケットをドロップする必要がある関連するキューのポイントを示す署名されていない16ビット整数列挙です。定義された列挙値は次のとおりです。
o unknown(0) o head(1) o tail(2)
o 不明（0）oヘッド（1）o尾（2）
Note: if the value of DropFrom is '0' (unknown), or if it is not one of the three values listed here, then packets MAY be dropped from any location in the associated queue.
注：ドロップフロムの値が「0」（不明）の場合、またはここにリストされている3つの値のいずれかでない場合、パケットは関連するキュー内の任意の場所から削除される場合があります。
This is a concrete class that represents the threshold information of a head or tail dropper. The inherited property DropFrom indicates whether a particular instance of this class represents a head dropper or a tail dropper.
これは、ヘッドまたはテールドロッパーのしきい値情報を表す具体的なクラスです。継承されたプロパティドロップは、このクラスの特定のインスタンスがヘッドドロッパーかテールドロッパーを表すかを示します。
A head dropper always examines the same queue from which it drops packets, and this queue is always related to the dropper as the following service in the NextService association.
ヘッドドロッパーは常にパケットをドロップするのと同じキューを調べます。このキューは、次のサービス協会の次のサービスとして常にドロッパーに関連しています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME HeadTailDropperService
DESCRIPTION A concrete class used to describe
a head or tail dropper.
DERIVED FROM DropperService
TYPE Concrete
PROPERTIES QueueThreshold
This is an unsigned 32-bit integer that indicates the queue depth at which traffic will be dropped. For a tail dropper, all newly arriving traffic is dropped. For a head dropper, packets at the front of the queue are dropped to make room for new packets, which are added at the end. The value is expressed in bytes.
これは、トラフィックがドロップされるキューの深さを示す署名されていない32ビット整数です。テールドロッパーの場合、新しく到着するすべてのトラフィックがドロップされます。ヘッドドロッパーの場合、キューの前面にあるパケットがドロップされて、最後に追加された新しいパケット用のスペースを作成します。値はバイトで表されます。
This is a concrete class that represents the ability to drop network traffic using a Random Early Detection (RED) algorithm. This algorithm is described in [RED]. The purpose of a RED algorithm is to avoid congestion (as opposed to managing congestion). Instead of waiting for the queues to fill up, and then dropping large numbers of packets, RED works by monitoring the average queue depth. When the queue depth exceeds a minimum threshold, packets are randomly discarded. These discards cause TCP to slow its transmission rate for those connections that experienced the packet discards. Other TCP connections are not affected by these discards. Please see [DSMODEL] for more information about a dropper.
これは、ランダムな早期検出（赤）アルゴリズムを使用してネットワークトラフィックをドロップする機能を表す具体的なクラスです。このアルゴリズムは[赤]で説明されています。赤いアルゴリズムの目的は、混雑を避けることです（混雑の管理とは対照的に）。キューがいっぱいになるのを待ってから、多数のパケットをドロップする代わりに、赤いキューの深さを監視することにより、赤い作品が機能します。キューの深さが最小しきい値を超えると、パケットはランダムに破棄されます。これらの廃棄により、TCPはパケットの破棄を経験した接続の伝送速度を遅くします。他のTCP接続は、これらの廃棄の影響を受けません。ドロッパーの詳細については、[dsmodel]を参照してください。
A RED dropper always drops packets from a single queue, which is related to the dropper as the following service in the NextService association. The queue(s) examined by the drop algorithm are found by following the CalculationServiceForDropper association to find the dropper's DropThresholdCalculationService, and then following the CalculationBasedOnQueue association(s) to find the queue(s) being watched.
赤いドロッパーは常に単一のキューからパケットをドロップします。これは、次のサービス協会の次のサービスとしてドロッパーに関連しています。ドロップアルゴリズムで検査されたキューは、DropperのDropthresholdCalculationserviceを見つけて、CalculationBasedOnqueue Association（s）を見つけて監視されていることを見つけることで、CalculationerviceFordopper Associationに従って発見されます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME REDDropperService
DESCRIPTION A concrete class used to describe
dropping using the RED algorithm (or
one of its variants).
DERIVED FROM DropperService
TYPE Concrete
PROPERTIES MinQueueThreshold, MaxQueueThreshold,
ThresholdUnits, StartProbability,
StopProbability
NOTE: In [DSMIB], there is a single diffServRandomDropTable, which represents the general category of random dropping. (RED is one type of random dropping, but there are also types of random dropping distinct from RED.) The REDDropperService class corresponds to the columns in the table that apply to the RED algorithm in particular.
注：[dsmib]には、ランダムドロップの一般的なカテゴリを表す単一のdiffservrandomdroptableがあります。（赤はランダムドロップの1つですが、赤とは異なるランダムドロップのタイプもあります。）ReddropPerserviceクラスは、特に赤いアルゴリズムに適用されるテーブルの列に対応しています。
This is an unsigned 32-bit integer that defines the minimum average queue depth at which packets are subject to being dropped. The units are identified by the ThresholdUnits property. The slope of the drop probability function is described by the Start/StopProbability properties.
これは、パケットがドロップされる可能性がある最小平均キューの深さを定義する署名されていない32ビット整数です。ユニットは、しきい値のプロパティによって識別されます。ドロップ確率関数の勾配は、開始/停止性プロパティによって説明されます。
This is an unsigned 32-bit integer that defines the maximum average queue length at which packets are subject to always being dropped, regardless of the dropping algorithm and probabilities being used. The units are identified by the ThresholdUnits property.
これは、ドロップするアルゴリズムと使用されている確率に関係なく、パケットが常にドロップされる最大平均キュー長を定義する署名されていない32ビット整数です。ユニットは、しきい値のプロパティによって識別されます。
This is an unsigned 16-bit integer enumeration that identifies the units for the MinQueueThreshold and MaxQueueThreshold properties. Defined enumeration values are:
これは、MinqueuethresholdおよびMaxqueuethresholdプロパティの単位を識別する署名されていない16ビット整数列挙です。定義された列挙値は次のとおりです。
o bytes(1) o packets(2)
o バイト（1）oパケット（2）
Note: if the value of ThresholdUnits is not one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes).
注：しきい値がこれらの2つの値のいずれかでない場合、値「1」（バイト）があるかのように解釈する必要があります。
This is an unsigned 32-bit integer; in conjunction with the StopProbability property, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length.
これは、署名されていない32ビット整数です。StopProbabilityプロパティと組み合わせて、ドロップ確率関数の勾配を定義します。この関数は、キューの長さの関数として、パケットがドロップされる速度を支配します。
This property expresses a drop probability in drops per thousand packets. For example, the value 100 indicates a drop probability of 100 per 1000 packets, that is, 10%. Min and max values are 0 to 1000.
このプロパティは、1,000パケットあたりのドロップのドロップ確率を表します。たとえば、値100は、1000パケットあたり100のドロップ確率、つまり10％を示します。最小値と最大値は0〜1000です。
This is an unsigned 32-bit integer; in conjunction with the StartProbability property, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length.
これは、署名されていない32ビット整数です。StartProbabilityプロパティと組み合わせて、ドロップ確率関数の勾配を定義します。この関数は、キューの長さの関数として、パケットがドロップされる速度を支配します。
This property expresses a drop probability in drops per thousand packets. For example, the value 100 indicates a drop probability of 100 per 1000 packets, that is, 10%. Min and max values are 0 to 1000.
このプロパティは、1,000パケットあたりのドロップのドロップ確率を表します。たとえば、値100は、1000パケットあたり100のドロップ確率、つまり10％を示します。最小値と最大値は0〜1000です。
This is a concrete class that represents the ability to queue network traffic, and to specify the characteristics for determining long-term congestion. Please see [DSMODEL] for more information about queuing functionality.
これは、ネットワークトラフィックをキューする能力を表し、長期的な混雑を決定するための特性を指定する具体的なクラスです。キューイング機能の詳細については、[dsmodel]を参照してください。
QueuingService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service.
Queuingserviceは条件付けサービスとしてモデル化されているため、Qosservice（qosconditioningsubservice Associationを使用）に集約して、その機能がそのQoSサービスの根底にあることを示します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME QueuingService
DESCRIPTION A concrete class describing the ability
to queue network traffic and to specify
the characteristics for determining
long-term congestion.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES CurrentQueueDepth, DepthUnits
This is an unsigned 32-bit integer, which functions as a (read-only) gauge representing the current depth of this one queue. This value may be important in diagnosing unexpected behavior by a DropThresholdCalculationService.
これは、この1つのキューの現在の深さを表す（読み取り専用）ゲージとして機能する署名されていない32ビット整数です。この値は、DropthholdCalculationServiceによる予期しない動作を診断する上で重要かもしれません。
This is an unsigned 16-bit integer enumeration that identifies the units for the CurrentQueueDepth property. Defined enumeration values are:
これは、currenceuedepthプロパティの単位を識別する署名されていない16ビット整数列挙です。定義された列挙値は次のとおりです。
o bytes(1) o packets(2)
o バイト（1）oパケット（2）
Note: if the value of DepthUnits is not one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes). The
注：Depthunitsの値がこれら2つの値のいずれかでない場合、値「1」（バイト）があるかのように解釈する必要があります。
This is a concrete class that represents a scheduling service, which is a process that determines when a queued packet should be removed from a queue and sent to an output interface. Note that output interfaces can be physical network interfaces or interfaces to components internal to systems, such as crossbars or back planes. In either case, if multiple queues are involved, schedulers are used to provide access to the interface.
これは、スケジューリングサービスを表す具体的なクラスです。これは、キューからキューから削除され、出力インターフェイスに送信される時期を決定するプロセスです。出力インターフェイスは、クロスバーやバックプレーンなどのシステム内部のコンポーネントへの物理ネットワークインターフェイスまたはインターフェイスである可能性があることに注意してください。どちらの場合でも、複数のキューが関与している場合、スケジューラを使用してインターフェイスへのアクセスを提供します。
Each instance of a PacketSchedulingService describes a scheduler from the perspective of the queues that it is servicing. Please see [DSMODEL] for more information about a scheduler.
PacketSchedulingserviceの各インスタンスは、サービスであるキューの観点からスケジューラを説明しています。スケジューラの詳細については、[dsmodel]を参照してください。
PacketSchedulingService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService object, if any, that acts on traffic after it has been processed by the scheduler.
PacketSchedulingserviceは、条件付けサービスとしてモデル化されているため、QOSService（QosconditionSubservice Associationを使用）に集約して、その機能がそのQoSサービスの根底にあることを示します。次のサービス協会に参加して、スケジューラによって処理された後にトラフィックに作用する後続の条件付けサービスオブジェクトを特定します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME PacketSchedulingService
DESCRIPTION A concrete class used to determine when
a packet should be removed from a
queue and sent to an output interface.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES SchedulerType, OtherSchedulerType
This property is an enumerated 16-bit unsigned integer, and defines the type of scheduler. Values are:
このプロパティは、列挙された16ビットの符号なし整数であり、スケジューラのタイプを定義します。値は次のとおりです。
1 - Other 2 - FIFO 3 - Priority 4 - Allocation 5 - Bounded Priority 6 - Weighted Round Robin Packet
1-その他2 -FIFO 3-優先度4-割り当て5-境界優先度6-重み付きラウンドロビンパケット
Note: if the value of SchedulerType is not one of these six values, it SHOULD be interpreted as if it had the value '2' (FIFO).
注：SchedulerTypeの値がこれらの6つの値のいずれかでない場合、値「2」（FIFO）があるかのように解釈する必要があります。
This string property is used in conjunction with the SchedulerType property. When the value of SchedulerType is 1 (i.e., Other), then the type of scheduler is specified in this property.
この文字列プロパティは、SchedulerTypeプロパティと組み合わせて使用されます。SchedulerTypeの値が1（つまり、その他）の場合、このプロパティでスケジューラのタイプが指定されます。
This class does not add any properties beyond those it inherits from its superclass, PacketSchedulingService. It does, however, participate in one additional association, FailNextScheduler.
このクラスでは、スーパークラスであるPacketSchedulingserviceから継承するプロパティを超えてプロパティを追加しません。ただし、1つの追加の関連付けに参加しています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME NonWorkConservingSchedulingService
DESCRIPTION A concrete class representing a
scheduler that is capable of operating
in a non-work conserving manner.
DERIVED FROM PacketSchedulingService
TYPE Concrete
PROPERTIES (none)
This is a concrete class that represents the ability to conceptualize a QoS service as a set of coordinated sub-services. This enables the network administrator to map business rules to the network, and the network designer to engineer the network such that it can provide different functions for different traffic streams.
これは、QoSサービスを調整されたサブサービスのセットとして概念化する機能を表す具体的なクラスです。これにより、ネットワーク管理者はビジネスルールをネットワークにマッピングでき、ネットワーク設計者はネットワークをエンジニアリングして、さまざまなトラフィックストリームに異なる機能を提供できるようにします。
This class has two main purposes. First, it serves as a common base class for defining the various sub-services needed to build higher-level QoS services. Second, it serves as a way to consolidate the relationships between different types of QoS services and different types of ConditioningServices.
このクラスには2つの主要な目的があります。まず、高レベルのQoSサービスを構築するために必要なさまざまなサブサービスを定義するための共通の基本クラスとして機能します。第二に、異なるタイプのQoSサービスとさまざまなタイプの条件付けサービスとの関係を統合する方法として機能します。
For example, Gold Service may be defined as a QoSService which aggregates two QoS services together. Each of these QoS services could be represented by an instance of the class DiffServService, one for servicing of very high demand packets (represented by an instance of DiffServService itself), and one for the service given to most of the packets, represented by an instance of AFService, which is a subclass of DiffServService. The high demand DiffServService instance will then use the QoSConditioningSubService aggregation to aggregate together the necessary classifiers to indicate which traffic it applies to, and the appropriate meters for contract limits, the marker to mark the EF PHB in the packets, and the queuing-related conditioning services. The AFService instance will also use the QoSConditioningSubService aggregation, to aggregate its classifiers and meters, the several markers used to mark the different AF PHBs in the packets, and the queuing-related conditioning services needed to deliver the packet treatment.
たとえば、ゴールドサービスは、2つのQoSサービスを一緒に集約するQosserviceとして定義される場合があります。これらの各QoSサービスは、クラスのdiffservserviceのインスタンス、非常に高い需要パケット（diffservservice自体のインスタンスで表される）のサービス用のインスタンス、およびインスタンスで表されるほとんどのパケットに与えられたサービス用の1つで表現できます。diffservserviceのサブクラスであるafserviceの。高需要DiffServServiceインスタンスは、QosconditionSubsubserviceの集約を使用して、必要な分類器を集計して、どのトラフィックに適用されるかを示し、契約制限に適したメーターをパケット内のEF PHBをマークするマーカー、およびキューリング関連の条件付けサービス。AFServiceインスタンスは、QosconditionSubserviceの集約を使用して、その分類器とメーター、パケット内の異なるAF PHBをマークするために使用されるいくつかのマーカー、およびパケット処理を提供するために必要なキューイング関連のコンディショニングサービスを集約します。
QoSService is modeled as a type of Service, which is used as the anchor point for defining a set of sub-services that implement the desired conditioning characteristics for different types of flows. It will direct the specific type of conditioning services to be used in order to implement this service.
Qosserviceは、さまざまな種類のフローの目的のコンディショニング特性を実装する一連のサブサービスを定義するためのアンカーポイントとして使用される、サービスの一種としてモデル化されています。このサービスを実装するために使用する特定のタイプのコンディショニングサービスを指示します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME QoSService
DESCRIPTION A concrete class used to represent a QoS
service or set of services, as defined
by a network administrator.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)
This is a concrete class representing the use of standard or custom DiffServ services to implement a (higher-level) QoS service. Note that a DiffServService object may be just one of a set of coordinated QoSSubServices objects that together implement a higher-level QoS service.
これは、（高レベルの）QoSサービスを実装するための標準またはカスタムDiffServサービスの使用を表す具体的なクラスです。diffservserviceオブジェクトは、高レベルのQoSサービスを実装する調整されたqossubservicesオブジェクトのセットの1つにすぎない可能性があることに注意してください。
DiffServService is modeled as a subclass of QoSService. This enables it to be related to a higher-level QoS service via QoSSubService, as well as to specific ConditioningService objects (e.g., metering, dropping, queuing, and others) via QoSConditioningSubService.
DiffServServiceは、Qosserviceのサブクラスとしてモデル化されています。これにより、QossubServiceを介した高レベルのQoSサービス、および特定の条件付けサービスオブジェクト（たとえば、メータリング、ドロップ、キューイングなど）に関連することができます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME DiffServService
DESCRIPTION A concrete class used to represent a
DiffServ service associated with a
particular Per Hop Behavior.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES PHBID
This property is a 16-bit unsigned integer, which identifies a particular per hop behavior, or family of per hop behaviors. The value here is a Per Hop Behavior Identification Code, as defined in [R3140]. Note that as defined, these identification codes use the default, recommended, code points for PHBs as part of their structure. These values may well be different from the actual value used in the marker, as the marked value is a domain-dependent value. The ability to indicate the PHB Identification Code associated with a service is helpful for tying the QoS Service to reference documents, and for inter-domain coordination and operation.
このプロパティは、16ビットの署名されていない整数であり、特定のホップごとの動作、またはホップごとの動作のファミリを識別します。ここでの値は、[R3140]で定義されているホップの動作識別コードです。定義されているとおり、これらの識別コードは、構造の一部としてPHBのデフォルトの推奨されるコードポイントを使用していることに注意してください。マークされた値はドメイン依存の値であるため、これらの値はマーカーで使用される実際の値とは異なる場合があります。サービスに関連付けられたPHB識別コードを示す機能は、QoSサービスを参照ドキュメントに結び付け、ドメイン間の調整と操作に役立ちます。
This is a concrete class that represents a specialization of the general concept of forwarding network traffic, by adding specific semantics that characterize the operation of the Assured Forwarding (AF) Service ([R2597]).
これは、Assured Forwarding（AF）サービス（[R2597]）の動作を特徴付ける特定のセマンティクスを追加することにより、ネットワークトラフィックの転送の一般的な概念の専門化を表す具体的なクラスです。
[R2597] defines four different AF classes, to represent four different treatments of traffic. A different amount of forwarding resources, such as buffer space and bandwidth, are allocated to each AF class. Within each AF class, IP packets are marked with one of three possible drop precedence values. The drop precedence of a packet determines the relative importance of that packet compared to other packets within the same AF class, if congestion occurs. A congested interface will try to avoid dropping packets marked with a lower drop precedence value, by instead discarding packets marked with a higher drop precedence value.
[R2597]は、トラフィックの4つの異なる治療を表すために、4つの異なるAFクラスを定義します。バッファースペースや帯域幅など、さまざまな量の転送リソースが各AFクラスに割り当てられます。各AFクラス内で、IPパケットには、3つの可能なドロップ優先順位値のいずれかがマークされています。パケットのドロップの優先順位は、混雑が発生した場合、同じAFクラス内の他のパケットと比較して、そのパケットの相対的な重要性を決定します。混雑したインターフェイスは、ドロップの優先順位値が低いマークされたパケットのドロップを避けようとします。
Note that [R2597] defines 12 DSCPs that together represent the AF Per Hop Behavior (PHB) group. Implementations are free to extend this (e.g., add more classes and/or drop precedences).
[R2597]は、一緒にAF Per Hopの動作（PHB）グループを表す12のDSCPを定義していることに注意してください。実装はこれを自由に拡張できます（たとえば、クラスやドロップの優先順位を追加します）。
The AFService class is modeled as a specialization of DiffServService, which is in turn a specialization of QoSService. This enables it to be related to higher-level QoS services, as well as to lower-level conditioning sub-services (e.g., classification, metering, dropping, queuing, and others).
AFServiceクラスは、diffservserviceの専門化としてモデル化されており、これがQosserviceの専門化です。これにより、高レベルのQoSサービス、および低レベルのコンディショニングサブサービス（分類、メータリング、ドロップ、キューイングなど）に関連することができます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME AFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding, using the AF
PHB Group.
DERIVED FROM DiffServService
TYPE Concrete
PROPERTIES ClassNumber, DropperNumber
This property is an 8-bit unsigned integer that indicates the number of AF classes that this AF implementation uses. Among the instances aggregated using the QoSConditioningSubService aggregation with an instance of AFService, one SHOULD find markers with as many distinct values as the ClassNumber of the AFService instance.
このプロパティは、このAF実装が使用するAFクラスの数を示す8ビットの署名のない整数です。AFServiceのインスタンスを使用したQosconditionSubSubserviceの集約を使用して集約されたインスタンスの中で、AfServiceインスタンスのクラス数と同じくらい多くの異なる値を持つマーカーを見つける必要があります。
This property is an 8-bit unsigned integer that indicates the number of drop precedence values that this AF implementation uses. The number of drop precedence values is the number PER AF CLASS. The corresponding droppers will be found in the collection of conditioning services aggregated with the QoSConditioningSubService aggregation.
このプロパティは、このAF実装が使用するドロップ優先値の数を示す8ビットの署名のない整数です。ドロップの優先順位値の数は、AFクラスあたりの数です。対応するドロッパーは、QosconditionSubservice Aggregationと集約されたコンディショニングサービスのコレクションにあります。
This class represents a service that supports a particular microflow. The microflow is identified by the string-valued property FlowID. In some implementations, an instance of this class corresponds to an entry in the implementation's flow table.
このクラスは、特定のマイクロフローをサポートするサービスを表します。マイクロフローは、文字列値のプロパティFlowIDによって識別されます。いくつかの実装では、このクラスのインスタンスは、実装のフローテーブルのエントリに対応しています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME FlowService
DESCRIPTION A concrete class representing a
microflow.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES FlowID
This property is a string containing an identifier for a microflow.
このプロパティは、マイクロフローの識別子を含む文字列です。
This class represents a logical entity that calculates an average queue depth for a queue, based on a smoothing weight and a sampling time interval. It does this calculation on behalf of a RED dropper, to allow the dropper to make its decisions whether to drop packets based on a smoothed average queue depth for the queue.
このクラスは、スムージング重量とサンプリング時間間隔に基づいて、キューの平均キューの深さを計算する論理エンティティを表します。これは、ドロッパーがキューの平滑化された平均キューの深さに基づいてパケットをドロップするかどうかを決定できるようにするために、赤いドロッパーに代わってこの計算を行います。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME DropThresholdCalculationService
DESCRIPTION A concrete class representing a logical
entity that calculates an average queue
depth for a queue, based on a smoothing
weight and a sampling time interval.
The latter are properties of this
Service, describing how it operates and
its necessary parameters.
DERIVED FROM Service
TYPE Concrete
PROPERTIES SmoothingWeight, TimeInterval
This property is a 32-bit unsigned integer, ranging between 0 and 100,000 - specified in thousandths. It defines the weighting of past history in affecting the calculation of the current average queue depth. The current queue depth calculation uses the inverse of this value as its factor, and one minus that inverse as the factor for the historical average. The calculation takes the form:
このプロパティは、32ビットの署名されていない整数で、0〜100,000の範囲で、1000分の1で指定されています。現在の平均キューの深さの計算に影響を与える過去の歴史の重みを定義します。現在のキューの深さ計算では、この値の逆をその因子として使用し、1つは履歴平均の因子としてその逆をマイナスします。計算には次の形式があります。
average = (old_average*(1-inverse of SmoothingWeight))
+ (current_queue_depth*inverse of SmoothingWeight)
Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2.
実装は、許容可能な値のセットを2のPowersなどの指定されたセットに制限することを選択する場合があります。
Min and max values are 0 and 100000.
最小値と最大値は0および100000です。
This property is a 32-bit unsigned integer, defining the number of nanoseconds between each calculation of average/smoothed queue depth. If this property is not specified, the CalculationService may determine an appropriate interval.
このプロパティは32ビットの署名されていない整数であり、平均/平均的なキューの深さの各計算の間にナノ秒数を定義します。このプロパティが指定されていない場合、計算サービスは適切な間隔を決定する場合があります。
FilterEntryBase is the abstract base class from which all filter entry classes are derived. It serves as the endpoint for the EntriesInFilterList aggregation, which groups filter entries into filter lists. Its properties include CIM naming properties and an IsNegated boolean property (to easily "NOT" the match information specified in an instance of one of its subclasses).
filterentrybaseは、すべてのフィルターエントリクラスが導出される抽象的なベースクラスです。これは、エントリフィルターリスト集約のエンドポイントとして機能し、エントリをフィルターリストにグループ化します。そのプロパティには、CIMネーミングプロパティとIsenegated Booleanプロパティが含まれます（サブクラスの1つで指定された一致情報を簡単に「非」します）。
Because FilterEntryBase has general applicability, it is defined in [PCIME]. See [PCIME] for the definition of this class.
filterentrybaseには一般的な適用性があるため、[PCIME]で定義されています。このクラスの定義については、[PCIME]を参照してください。
This concrete class makes it possible to represent an entire IP header filter in a single object. A property IpVersion identifies whether the IP addresses in an instance are IPv4 or IPv6 addresses. (Since the source and destination IP addresses come from the same packet header, they will always be of the same type.)
このコンクリートクラスにより、単一のオブジェクトでIPヘッダーフィルター全体を表すことができます。プロパティIPバージョンは、インスタンスのIPアドレスがIPv4アドレスかIPv6アドレスであるかを識別します。（ソースおよび宛先IPアドレスは同じパケットヘッダーから来ているため、常に同じタイプになります。）
See [PCIME] for the definition of this class.
このクラスの定義については、[PCIME]を参照してください。
This concrete class allows 802.1.source and destination MAC addresses, as well as the 802.1 protocol ID, priority, and VLAN identifier fields, to be expressed in a single object
このコンクリートクラスでは、802.1.Sourceおよび宛先Macアドレス、および802.1プロトコルID、優先度、およびVLAN識別子フィールドを単一のオブジェクトで表現できます。
See [PCIME] for the definition of this class.
このクラスの定義については、[PCIME]を参照してください。
This is a concrete class that models classifying packets using traffic-conditioning results stored in a packet preamble by a PreambleMarkerService. See Section 3.8.3 for a discussion of how, and why, QDDIM models the capability to store these results in a packet preamble. An instance of PreambleFilter is used to select packets based on a two-part string identifying a specific result. The logic for this match is "at least one". That is, a packet with multiple results in its preamble matches a filter if at least one of these results matches the filter.
これは、PreamblemarkerServiceによってパケットプリアンブルに保存されているトラフィックコンディショニング結果を使用してパケットを分類するモデルをモデル化する具体的なクラスです。QDDIMがこれらの結果をパケットプリアンブルに保存する機能をモデル化する方法とその理由についての議論については、セクション3.8.3を参照してください。PreambleFilterのインスタンスは、特定の結果を識別する2部構成の文字列に基づいてパケットを選択するために使用されます。この試合のロジックは「少なくとも1」です。つまり、これらの結果の少なくとも1つがフィルターと一致する場合、そのプリアンブルの複数の結果を持つパケットがフィルターと一致します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME PreambleFilter
DESCRIPTION A concrete class representing criteria
for selecting packets based on prior
traffic-conditioning results stored in
a packet preamble.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES FilterItemList[ ]
This property is an ordered list of strings, where each string has the format "<type>,<value>". See Section 3.8.3 for a list of <type>'s defined in QDDIM, and the nature of the associated <value> for each of these types.
このプロパティは、各文字列にフォーマット「<type>、<value>」がある文字列の順序付けられたリストです。QDDIMで定義されている<Type>のリスト、およびこれらの各タイプの関連する<value>の性質については、セクション3.8.3を参照してください。
Note that there are two parallel terminologies for characterizing meter results. The enumeration value "conforming(1)" is sometimes described as "in profile," and the value "nonConforming(3)" is sometimes described as "out of profile".
メーターの結果を特徴付けるための2つの並列用語があることに注意してください。列挙値「適合（1）」は「プロファイル」として記述されることがあり、値「不適合（3）」は「プロファイル外」と呼ばれることがあります。
This is a concrete class that aggregates instances of (subclasses of) FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, packet header filters (represented by the IPHeaderFilter class) and security filters (represented by subclasses of FilterEntryBase defined by IPsec).
これは、Aggregation entriesInfilterListを介して（サブクラスの）filterentrybaseのインスタンスを集約する具体的なクラスです。さまざまなタイプのフィルターを単一のフィルターリストに集約することができます - たとえば、パケットヘッダーフィルター（ipheaderfilterクラスで表される）とセキュリティフィルター（IPSECで定義されたFilterEntryBaseのサブクラスで表されます）。
The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic.
Aggregation Property entriesInFilterList.EntrySequenceは常に0に設定されており、集約されたフィルターエントリが一緒にAndedであり、トラフィックのクラスのセレクターを形成します。
See [PCIME] for the definition of this class.
このクラスの定義については、[PCIME]を参照してください。
This is an abstract class defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects that manage access to CIM_Services. It represents the management of utilizing or invoking a Service. Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。これは、LogicalElementクラスのサブクラスであり、CIM_Servicesへのアクセスを管理するすべてのオブジェクトのベースクラスです。これは、サービスを利用または呼び出すことの管理を表しています。このクラスの完全な定義については、[CIM]を参照してください。
This is a concrete class derived from ServiceAccessPoint, which describes a communication point from which the services of the network or the system's protocol stack may be accessed. Please refer to [CIM] for the full definition of this class.
これは、ServiceAccessPointから派生した具体的なクラスであり、ネットワークまたはシステムのプロトコルスタックのサービスにアクセスできる通信ポイントを説明しています。このクラスの完全な定義については、[CIM]を参照してください。
This is an abstract class defined in the Core Model of CIM. It is the superclass for all classes that represent groupings or bags, and that carry no status or "state". (The latter would be more correctly modeled as ManagedSystemElements.) Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。グループやバッグを表すすべてのクラスのスーパークラスであり、ステータスや「状態」を持ちません。（後者は、ManageDsystemelementsとしてより正確にモデル化されます。）このクラスの完全な定義については、[CIM]を参照してください。
This is an abstract class defined in the Core Model of CIM. It is a subclass of the Collection superclass, restricting the contents of the Collection to ManagedSystemElements. Please refer to [CIM] for the full definition of this class.
これは、CIMのコアモデルで定義された抽象クラスです。これは、コレクションのスーパークラスのサブクラスであり、コレクションの内容をManagedSystemElementsに制限しています。このクラスの完全な定義については、[CIM]を参照してください。
This is a concrete class that represents the collection of buffers used by a QueuingService. (The association QueueAllocation represents this usage.) The existence and management of individual buffers may be modeled in a future document. At the current level of abstraction, modeling the existence of the BufferPool is necessary. Long term, it is not sufficient.
これは、Queuingserviceが使用するバッファーのコレクションを表す具体的なクラスです。（Association Queueallocationはこの使用法を表しています。）個々のバッファーの存在と管理は、将来のドキュメントでモデル化される場合があります。抽象化の現在のレベルでは、バッファープールの存在をモデル化する必要があります。長期的には、それは十分ではありません。
In implementations where there are multiple buffer sizes, an instance of BufferPool should be defined for each set of buffers with identical or similar sizes. These instances of buffer pools can then be grouped together using the CollectedBuffersPool aggregation.
複数のバッファサイズがある実装では、同一または類似のサイズのバッファーセットごとにバッファープールのインスタンスを定義する必要があります。これらのバッファープールのインスタンスは、収集されたバッファースプールの集約を使用してグループ化できます。
Note that this class is derived from CollectionOfMSEs, and not from Forwarding or ConditioningService. A BufferPool is only a collection of storage, and is NOT a Service.
このクラスは、転送や条件付けサービスからではなく、collectionofmsesから派生していることに注意してください。バッファープールはストレージのコレクションにすぎず、サービスではありません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME BufferPool
DESCRIPTION A concrete class representing
a collection of buffers.
DERIVED FROM CollectionOfMSEs
TYPE Concrete
PROPERTIES Name, BufferSize, TotalBuffers,
AvailableBuffers, SharedBuffers
This property is a string with a maximum length of 256 characters. It is the common name or label by which the object is known.
このプロパティは、最大長さ256文字の文字列です。オブジェクトが既知の一般名またはラベルです。
This property is a 32-bit unsigned integer, identifying the approximate number of bytes in each buffer in the buffer pool. An implementation will typically group buffers of roughly the same size together, to reduce the number of buffer pools it needs to manage. This model does not specify the degree to which buffers in the same buffer pool may differ in size.
このプロパティは、バッファープールの各バッファー内の近似バイト数を識別する32ビットの署名のない整数です。実装は通常、ほぼ同じサイズのバッファーを一緒にグループ化して、管理する必要があるバッファープールの数を減らします。このモデルでは、同じバッファープールのバッファーがサイズが異なる場合がある程度を指定していません。
This property is a 32-bit unsigned integer, reporting the total number of individual buffers in the pool.
このプロパティは、プール内の個々のバッファーの総数を報告する32ビットの署名のない整数です。
This property is a 32-bit unsigned integer, reporting the number of buffers in the Pool that are currently not allocated to any instance of a QueuingService. Buffers allocated to a QueuingService could either be in use (that is, currently contain packet data), or be allocated to a queue pending the arrival of new packet data.
このプロパティは32ビットの署名されていない整数であり、現在、Queuingserviceのどのインスタンスに割り当てられていないプール内のバッファーの数を報告しています。Queuingserviceに割り当てられたバッファーは、使用中（つまり、現在パケットデータが含まれている）か、新しいパケットデータの到着が待機してキューに割り当てられる可能性があります。
This property is a 32-bit unsigned integer, reporting the number of buffers in the Pool that have been simultaneously allocated to multiple instances of QueuingService.
このプロパティは、32ビットの署名されていない整数であり、プール内のバッファーの数を、Queuingserviceの複数のインスタンスに同時に割り当てられていることを報告しています。
This is an abstract class that represents the configuration information that a PacketSchedulingService has for one of the elements that it is scheduling. The scheduled element is either a QueuingService or another PacketSchedulingService.
これは、Schedulingである要素の1つに対してPacketSchedulingserviceが持つ構成情報を表す抽象クラスです。スケジュールされた要素は、QueuingserviceまたはPacketschedulingserviceのいずれかです。
Among the subclasses of this class, some are defined in such a way that all of their instances are work conserving. Other subclasses, however, may have instances that either are or are not work conserving. In this class, the boolean property WorkConserving indicates whether an instance is or is not work conserving. The range of values for WorkConserving is restricted to TRUE in the subclasses that are inherently work conserving, since instances of these classes cannot be anything other than work conserving.
このクラスのサブクラスの中で、いくつかは、すべてのインスタンスが作業節約であるように定義されています。ただし、他のサブクラスには、保存されている場合または動作していないインスタンスがあります。このクラスでは、ブールのプロパティワークコンサイティングは、インスタンスが機能しているかどうかを示します。これらのクラスのインスタンスは、仕事を保存する以外のものではないため、ワークコンサージングの値の範囲は、本質的に仕事をしているサブクラスで真に制限されています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME SchedulingElement
DESCRIPTION An abstract class representing the
configuration information that a
PacketSchedulingService has for one of
the elements that it is scheduling.
DERIVED FROM ManagedElement
TYPE Abstract
PROPERTIES WorkConserving
This boolean property indicates whether the PacketSchedulingService tied to this instance by the ElementInSchedulingService aggregation is treating the input tied to this instance by the QueueToSchedule or SchedulingServiceToSchedule association in a work-conserving manner. Note that this property is writable, indicating that an administrator can change the behavior of the SchedulingElement - but only for those elements that can operate in a non-workconserving mode.
このブールプロパティは、ElementInschedulingserviceの集約によってこのインスタンスに結び付けられたPacketSchedulingserviceが、このインスタンスに関連する入力を、QueuetoscheduleまたはSchedulingserviceToschedule Associationによって仕事を継続的に扱っているかどうかを示します。このプロパティは書き込み可能であり、管理者がスケジューリングエレメントの動作を変更できることを示していますが、非加工モードで動作できる要素についてのみです。
This class is a subclass of the abstract class SchedulingElement. It introduces five new properties to support bandwidth-based scheduling. As is the case with all subclasses of SchedulingElement, the input associated with an instance of AllocationSchedulingElement is of one of two types: either a queue, or another scheduler.
このクラスは、抽象クラスのスケジューリングエレメントのサブクラスです。帯域幅ベースのスケジューリングをサポートするために、5つの新しいプロパティを導入します。スケジューリングエレメントのすべてのサブクラスの場合と同様に、arecationschedulingelementのインスタンスに関連付けられた入力は、キュー、または別のスケジューラの2つのタイプのいずれかの1つです。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME AllocationSchedulingElement DESCRIPTION A concrete class containing parameters for controlling bandwidth-based scheduling.
名前AllocationsChedulingElement説明帯域幅ベースのスケジューリングを制御するためのパラメーターを含むコンクリートクラス。
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES AllocationUnits, BandwidthAllocation,
BurstAllocation, CanShare,
WorkFlexible
This property is a 16-bit unsigned integer enumeration that identifies the units in which the BandwidthAllocation and BurstAllocation properties are expressed. The following values are defined:
このプロパティは、帯域幅のプロパティと爆発特性が表現される単位を識別する16ビットの署名のない整数列挙です。次の値が定義されています。
o bytes(1) o packets(2) o cells(3) -- fixed-size, for example, ATM
o バイト（1）oパケット（2）Oセル（3） - 固定サイズ、たとえば、ATM
Note: if the value of AllocationUnits is not one of these three values, it SHOULD be interpreted as if it had the value '1' (bytes).
注：AllocationUnitsの値がこれら3つの値のいずれかでない場合、値「1」（バイト）があるかのように解釈する必要があります。
This property is a 32-bit unsigned integer that defines the number of units/second that should be allocated to the associated input. The units are identified by the AllocationUnits property.
このプロパティは、関連する入力に割り当てる必要があるユニット/秒の数を定義する32ビットの署名整数です。ユニットは、AllocationUnitsプロパティによって識別されます。
This property is a 32-bit unsigned integer that specifies the amount of temporary or short-term bandwidth (in units per second) that can be allocated to an input, beyond the amount of bandwidth allocated through the BandwidthAllocation property. If the maximum actual bandwidth allocation for the input were to be measured, it would be the sum of the BurstAllocation and the BandwidthAllocation properties. The units are identified by the AllocationUnits property.
このプロパティは、帯域幅の帯域幅を介して割り当てられた帯域幅の量を超えて、入力に割り当てることができる一時的または短期帯域幅（1秒あたりの単位）の量を指定する32ビットの署名のない整数です。入力の最大実際の帯域幅割り当てが測定される場合、それは破裂と帯域幅のプロパティの合計になります。ユニットは、AllocationUnitsプロパティによって識別されます。
This is a boolean property that, if TRUE, enables unused bandwidth from the associated input to be allocated to other inputs serviced by the Scheduler.
これは、真の場合、関連する入力から未使用の帯域幅をスケジューラがサービスする他の入力に割り当てることを可能にするブールのプロパティです。
This is a boolean property that, if TRUE, indicates that the behavior of the scheduler relative to this input can be altered by changing the value of the inherited property WorkConserving.
これは、真実の場合、この入力に対するスケジューラの動作を、継承されたプロパティワークコンサイティングの値を変更することで変更できることを示すブールプロパティです。
This class is a subclass of the abstract class SchedulingElement, representing a weighted round robin (WRR) scheduling discipline. It introduces a new property WeightingFactor, to give some inputs a higher probability of being serviced than other inputs. It also introduces a property Priority, to serve as a tiebreaker to be used when inputs have equal weighting factors. As is the case with all subclasses of SchedulingElement, the input associated with an instance of WRRSchedulingElement is of one of two types: either a queue, or another scheduler.
このクラスは、抽象クラスのスケジューリングエレメントのサブクラスであり、加重ラウンドロビン（WRR）スケジューリングの規律を表しています。新しいプロパティの重み付けファクターを導入して、他の入力よりも多くの入力がサービスを受ける可能性を高めることができます。また、入力に等しい重み付け係数がある場合に使用されるタイブレーカーとして機能するために、プロパティの優先順位を導入します。スケジューリングエレメントのすべてのサブクラスの場合と同様に、wrrschedulingelementのインスタンスに関連付けられた入力は、キューまたは別のスケジューラの2つのタイプのいずれかの1つです。
Because scheduling of this type is always work conserving, the inherited boolean property WorkConserving is restricted to the value TRUE in this class.
このタイプのスケジューリングは常に動作しているため、継承されたブールのプロパティワークコンサイブは、このクラスで真の値に制限されています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME WRRSchedulingElement
DESCRIPTION This class specializes the
SchedulingElement class to add
a per-input weight. This is used
by a weighted round robin packet
scheduler when it handles its
associated inputs. It also adds a
second property to serve as a tie-breaker
in the case where multiple inputs have
been assigned the same weight.
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES WeightingFactor, Priority
This property is a 32-bit unsigned integer, which defines the weighting factor that offers some inputs a higher probability of being serviced than other inputs. This property represents this probability. Its minimum value is 0, its maximum value is 100000, and its units are in thousandths.
このプロパティは、32ビットの署名されていない整数であり、他の入力よりも多くの入力を提供するいくつかの入力を提供する重み係数を定義します。このプロパティは、この確率を表しています。その最小値は0、最大値は100000、その単位は千分の1です。
This property is a 16-bit unsigned integer, which serves as a tiebreaker, in the event that two or more inputs have equal weights. A larger value represents a higher priority. If this property is specified for any of the WRRSchedulingElements associated with a PacketSchedulingService, then it must be specified for all WRRSchedulingElements for that PacketSchedulingService, and the property values for these WRRSchedulingElements must all be different.
このプロパティは、2つ以上の入力が等しい重みを持っている場合に、タイブレーカーとして機能する16ビットの署名の整数です。値が大きいほど優先度が高いことを表します。このプロパティがPacketSchedulingserviceに関連付けられたWRRSCHEDULINGELEMENTSのいずれかに対して指定されている場合、そのPacketSchedulingserviceのすべてのwrrschedulingelementsに指定する必要があり、これらのwrrschedulingelementsのプロパティ値はすべて異なる必要があります。
While this condition may not occur in some implementations of a weighted round-robin scheduler, many implementations require a priority to resolve an equal-weight condition. In instances where this behavior is not necessary or is undesirable, this property may be left unspecified.
この条件は、重み付けされたラウンドロビンスケジューラのいくつかの実装では発生しない場合がありますが、多くの実装では、平等な重量条件を解決するための優先事項が必要です。この動作が不要または望ましくない場合、このプロパティは不特定のままになる可能性があります。
This class is a subclass of the abstract class SchedulingElement. It indicates that a scheduler is taking packets from a set of inputs using the priority scheduling discipline. As is the case with all subclasses of SchedulingElement, the input associated with an instance of PrioritySchedulingElement is of one of two types: either a queue, or another scheduler. The property Priority in PrioritySchedulingElement represents the priority for an input, relative to the priorities of all the other inputs to which the scheduler that aggregates this PrioritySchedulingElement is associated. Inputs to which the scheduler is related via other scheduling disciplines do not figure in this prioritization.
このクラスは、抽象クラスのスケジューリングエレメントのサブクラスです。これは、スケジューラが優先スケジューリングの規律を使用して一連の入力からパケットを取得していることを示しています。スケジューリングエレメントのすべてのサブクラスの場合と同様に、PrioritySchedulingElementのインスタンスに関連付けられた入力は、キューまたは別のスケジューラの2つのタイプのいずれかの1つです。PrioritySchedulingElementのプロパティの優先順位は、この優先順位SchedulingElementを集約するスケジューラが関連付けられている他のすべての入力の優先度と比較して、入力の優先度を表します。スケジューラが他のスケジューリング分野を介して関連する入力は、この優先順位付けでは考えられません。
Because scheduling of this type is always work conserving, the inherited boolean property WorkConserving is restricted to the value TRUE in this class.
このタイプのスケジューリングは常に動作しているため、継承されたブールのプロパティワークコンサイブは、このクラスで真の値に制限されています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME PrioritySchedulingElement DESCRIPTION A concrete class that specializes the SchedulingElement class to add a Priority property. This property is used by a SchedulingService that is doing priority scheduling for a set of inputs.
名前PrioritySchedulingElement説明SchedulingElementクラスを専門とするコンクリートクラスが優先プロパティを追加します。このプロパティは、入力セットの優先スケジューリングを行っているスケジューリングサービスによって使用されます。
DERIVED FROM SchedulingElement TYPE Concrete PROPERTIES Priority
スケジューリングエレメントタイプのコンクリート特性の優先順位から派生しました
This property is a 16-bit unsigned integer that indicates the priority level of a scheduler input relative to the other inputs serviced by this PacketSchedulingService. A larger value represents a higher priority.
このプロパティは、このpacketschedulingserviceによってサービスされる他の入力と比較して、スケジューラ入力の優先レベルを示す16ビットの署名整数です。値が大きいほど優先度が高いことを表します。
This class is a subclass of the class PrioritySchedulingElement, which is itself derived from the abstract class SchedulingElement. As is the case with all subclasses of SchedulingElement, the input associated with an instance of BoundedPrioritySchedulingElement is of one of two types: either a queue, or another scheduler. BoundedPrioritySchedulingElement adds an upper bound (in kilobits per second) on how much traffic can be handled from an input. This data is specific to that one input. It is needed when bounded strict priority scheduling is performed.
このクラスは、クラスの優先順位のSchedulingElementのサブクラスであり、それ自体は抽象クラスのスケジューリングセレメントから派生しています。スケジューリングエレメントのすべてのサブクラスの場合と同様に、BoundedPrioritySchedulingElementのインスタンスに関連付けられた入力は、キューまたは別のスケジューラの2つのタイプのいずれかの1つです。Bounded -PrioritySchedulingElementは、入力からどのくらいのトラフィックを処理できるかについて上限（1秒あたりのキロビット）を追加します。このデータは、その1つの入力に固有です。制限された厳密な優先度スケジューリングが実行される場合が必要です。
This class inherits from its superclass PrioritySchedulingElement the restriction of the inherited boolean property WorkConserving to the value TRUE.
このクラスは、そのスーパークラスの優先度から継承され、継承されたブールのプロパティの制限が真の値になります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME BoundedPrioritySchedulingElement DESCRIPTION This concrete class specializes the PrioritySchedulingElement class to add a BandwidthBound property. This property bounds the rate at which traffic from the associated input can be handled.
名前を削除されたChedulingElementの説明この具体的なクラスは、PrioritySchedulingElementクラスを専門として、帯域幅のプロパティを追加します。このプロパティは、関連する入力からのトラフィックを処理できる速度を削減します。
DERIVED FROM PrioritySchedulingElement TYPE Concrete PROPERTIES BandwidthBound
PrioritySchedulingElementタイプのコンクリートプロパティ帯域幅から導出されました
This property is a 32-bit unsigned integer that defines the upper limit on the amount of traffic that can be handled from the input. This is not a shaped upper bound, since bursts can occur. It is a strict bound, limiting the impact of the input. The units are kilobits per second.
このプロパティは、入力から処理できるトラフィックの量の上限を定義する32ビットの署名整数です。バーストが発生する可能性があるため、これは形の上限ではありません。これは、入力の影響を制限する厳格なバインドです。ユニットは毎秒キロビットです。
This section details the QoS device datapath associations, including the aggregations, which were shown earlier in Figures 4 and 5. These associations are defined as classes in the Information Model. Each of these classes has two properties referring to instances of the two classes that the association links. Some of the association classes have additional properties as well.
このセクションでは、図4および5に前述した集約を含むQoSデバイスデータパスアソシエーションの詳細については、これらの関連付けは情報モデルのクラスとして定義されています。これらの各クラスには、協会がリンクする2つのクラスのインスタンスを指す2つのプロパティがあります。一部の協会クラスには、追加のプロパティもあります。
This abstract association defines two object references (named Antecedent and Dependent) that establish general dependency relationships between different managed objects in the information model. The Antecedent reference identifies the independent object in the association, while the Dependent reference identifies the entity that IS dependent.
この抽象的なアソシエーションは、情報モデル内の異なる管理オブジェクト間の一般的な依存関係を確立する2つのオブジェクト参照（Antecedent and依存者と呼ばれる）を定義します。先行参照は、協会の独立したオブジェクトを識別し、依存参照は依存しているエンティティを識別します。
The association's cardinality is many to many.
協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This association defines two object references that establish a general dependency relationship between a Service object and a ServiceAccessPoint object. This relationship indicates that the referenced Service uses the ServiceAccessPoint of ANOTHER Service. The Service is the Dependent reference, relying on the ServiceAccessPoint to gain access to another Service.
この関連付けは、サービスオブジェクトとServiceAccessPointオブジェクトの間に一般的な依存関係を確立する2つのオブジェクト参照を定義します。この関係は、参照されたサービスが別のサービスのServiceAccessPointを使用していることを示しています。このサービスは、ServiceAccessPointに依存して別のサービスにアクセスするための依存参照です。
The association's cardinality is many to many.
協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This association is derived from the association ServiceSAPDependency, and represents the binding, in the ingress direction, between a protocol endpoint and the first ConditioningService that processes packets received via that protocol endpoint. Since there can only be one "first" ConditioningService for a protocol endpoint, the cardinality for the Dependent object reference is narrowed from 0..n to 0..1. Since, on the other hand, a single ConditioningService can be the first to process packets received via multiple protocol endpoints, the cardinality of the Antecedent object reference remains 0..n.
この関連付けは、Association ServicesApdependencyから導出され、プロトコルエンドポイントとそのプロトコルエンドポイントを介して受信したパケットを処理する最初の条件付けサービスの間の侵入方向の結合を表します。プロトコルエンドポイントの「最初の」条件付けサービスは1つしかないため、依存するオブジェクト参照のカーディナリティは0..nから0..1に狭くなります。一方、単一の条件付けサービスは、複数のプロトコルエンドポイントを介して受信したパケットを最初に処理することができるため、先行オブジェクト参照のカーディナリティは0..nのままです。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME IngressConditioningServiceOnEndpoint
DESCRIPTION An association that establishes a
dependency relationship between a protocol
endpoint and the first conditioning
service that processes traffic arriving
via that protocol endpoint.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..n]],
Dependent[ref ConditioningService[0..1]]
This association is derived from the association ServiceSAPDependency, and represents the binding, in the egress direction, between a protocol endpoint and the last ConditioningService that processes packets before they leave a network device via that protocol endpoint. (This "last" ConditioningService is ordinarily a scheduler, but it doesn't have to be.) Since there can be multiple "last" ConditioningServices for a protocol endpoint in the case of a fallback scheduler, the cardinality for the Dependent object reference remains 0..n. Since, however, a single ConditioningService cannot be the last one to process packets for multiple protocol endpoints, the cardinality of the Antecedent object reference is narrowed from 0..n to 0..1.
この関連付けは、協会のサービスAP依存関係から導き出され、プロトコルのエンドポイントと、そのプロトコルエンドポイントを介してネットワークデバイスを離れる前にパケットを処理する最後の条件付けサービスの間の脱出方向の結合を表します。（この「最後の」条件付けサービスは通常スケジューラですが、そうする必要はありません。）フォールバックスケジューラの場合、プロトコルエンドポイントに複数の「最後の」コンディショニングサービスが存在する可能性があるため、依存するオブジェクト参照のカーディナリティは残りです0..n。ただし、単一の条件付けサービスは、複数のプロトコルエンドポイントのパケットを処理する最後のものになることはできないため、先行オブジェクト参照のカーディナリティは0..Nから0..1に狭くなります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME EgressConditioningServiceOnEndpoint
DESCRIPTION An association that establishes a
dependency relationship between a protocol
endpoint and the last conditioning
service(s) that process traffic to be
transmitted via that protocol endpoint.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..1]],
Dependent[ref ConditioningService[0..n]]
This association is a subclass of Dependency, describing the association between a head or tail dropper and a queue that it monitors to determine when to drop traffic. The referenced queue is the one whose queue depth is compared against the Dropper's threshold. The cardinality is 1..n on the queue side, since a head/tail dropper must monitor at least one queue. For the classes HeadTailDropper and HeadTailDropQueueBinding, the rule for combining the inputs from multiple queues is simple addition: if the sum of the lengths of the monitored queues exceeds the dropper's QueueThreshold value, then packets are dropped. This rule for combining inputs may, however, be overridden by a different rule in subclasses of one or both of these classes.
この関連は、依存関係のサブクラスであり、頭部またはテールドロッパーと監視するキューとの間の関連性を説明し、いつトラフィックを落とすかを判断します。参照されたキューは、キューの深さがドロッパーのしきい値と比較されるキューです。ヘッド/テールドロッパーは少なくとも1つのキューを監視する必要があるため、カーディナリティはキュー側の1..nです。クラスのヘッドテールドロッパーとヘッドテールドロップバインディングの場合、複数のキューからの入力を組み合わせるためのルールは簡単です。監視されたキューの長さの合計がDropperのQueethreshold値を超えると、パケットが削除されます。ただし、入力を組み合わせるためのこのルールは、これらのクラスの1つまたは両方のサブクラスの異なるルールによってオーバーライドされる場合があります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME HeadTailDropQueueBinding
DESCRIPTION A generic association used to establish a
dependency relationship between a
head or tail dropper and a queue that it
monitors.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[1..n]],
Dependent[ref
HeadTailDropperService [0..n]]
This association is a subclass of Dependency, which defines two object references that establish a dependency relationship between a QueuingService and an instance of the DropThresholdCalculationService class. The queue's current depth is used by the calculation service in calculating an average queue depth.
この関連付けは、依存関係のサブクラスであり、QueuingserviceとDropthresholdCalculationserviceクラスのインスタンスとの間の依存関係を確立する2つのオブジェクト参照を定義します。キューの現在の深さは、平均キューの深さを計算する際に計算サービスで使用されます。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME CalculationBasedOnQueue
DESCRIPTION A generic association used to establish a
dependency relationship between a
QueuingService object and a
DropThresholdCalculationService object.
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[1..1]],
Dependent[ref
DropThresholdCalculationService [0..n]]
This property is inherited from the Dependency association, and overridden to serve as an object reference to a QueuingService object (instead of to the more general ManagedElement). This reference identifies the queue that the DropThresholdCalculationService will use in its calculation of average queue depth.
このプロパティは、依存関係協会から継承されており、より一般的な管理者ではなく、Queuingserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、平均キューの深さの計算でDropThresholdCalculationServiceが使用するキューを識別します。
This property is inherited from the Dependency association, and overridden to serve as an object reference to a DropThresholdCalculationService object (instead of to the more general ManagedElement). This reference identifies a DropThresholdCalculationService that uses the referenced queue's current depth as one of the inputs to its calculation of average queue depth.
このプロパティは、依存関係協会から継承されており、より一般的なマネージデリメントの代わりに、DropThholdCalculationServiceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。この参照は、参照されたキューの現在の深さを平均キューの深さの計算の入力の1つとして使用するDropthholdCalculationserviceを識別します。
This association defines two object references that establish a dependency relationship in which a ManagedSystemElement depends on the functionality of one or more Services. The association's cardinality is many to many.
この関連付けは、ManageDsystemElementが1つ以上のサービスの機能に依存する依存関係を確立する2つのオブジェクト参照を定義します。協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This association defines two object references that establish a dependency relationship between two Service objects. The particular type of dependency is represented by the TypeOfDependency property; typical examples include that one Service is required to be present or required to have completed for the other Service to operate.
この関連付けは、2つのサービスオブジェクト間の依存関係を確立する2つのオブジェクト参照を定義します。特定のタイプの依存関係は、Typeof依存性プロパティによって表されます。典型的な例には、1つのサービスが存在する必要があるか、他のサービスが動作するために完了する必要があることが含まれます。
This association is very similar to the ServiceSAPDependency relationship. For the latter, the Service is dependent on an AccessPoint to get at another Service. In this relationship, it directly identifies its Service dependency. Both relationships should not be instantiated, since their information is repetitive.
この関連は、サービスアプ依存関係に非常に似ています。後者の場合、サービスは別のサービスに参加するためのアクセスポイントに依存します。この関係では、サービスの依存関係を直接識別します。情報は繰り返されるため、両方の関係を具体化するべきではありません。
The association's cardinality is many to many.
協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This association is a subclass of ServiceServiceDependency, which defines two object references that represent the reliance of a REDDropperService on a DropThresholdCalculationService - calculating an average queue depth based on the observed depths of one or more queues.
この関連付けは、サービスサービスに基づいた依存関係のサブクラスであり、1つ以上のキューの観測された深さに基づいて、平均キューの深さを計算するDropThresholdCalculationserviceでのReddropPerserviceの依存を表す2つのオブジェクト参照を定義します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME CalculationServiceForDropper
DESCRIPTION A generic association used to establish a
dependency relationship between a
calculation service and a
REDDropperSrevice for which it performs
average queue depth calculations
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref
DropThresholdCalculationService[1..n]],
Dependent[ref REDDropperService[0..n]]
4.4.9.1. The Reference Antecedent
This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a DropThresholdCalculationService object (instead of to the more general Service object). The cardinality of the object reference is 1..n, indicating that a RED dropper may be served by one or more calculation services.
このプロパティは、サービスサービス依存関係の協会から継承されており、より一般的なサービスオブジェクトの代わりに、DropthholdCalculationserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。オブジェクト参照のカーディナリティは1..nであり、1つ以上の計算サービスが赤いドロッパーを提供できることを示しています。
This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a REDDropperService object (instead of to the more general Service object). This reference identifies a RED dropper served by a DropThresholdCalculationService.
このプロパティは、サービスサービス依存関係の協会から継承されており、（より一般的なサービスオブジェクトの代わりに）reddoperserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、DropThholdCalculationServiceが提供する赤いドロッパーを識別します。
This association is a subclass of Dependency, which defines two object references that establish a dependency relationship between a QueuingService and a BufferPool that provides storage space for the packets in the queue.
この関連付けは、依存関係のサブクラスであり、キューイングサービスとキュー内のパケットのストレージスペースを提供するQueuingserviceとBufferPoolの間に依存関係の関係を確立する2つのオブジェクト参照を定義します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME QueueAllocation
DESCRIPTION A generic association used to establish a
dependency relationship between a
QueuingService object and a BufferPool
object.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref BufferPool[0..n]],
Dependent[ref QueuingService[0..n]]
AllocationPercentage
This property is inherited from the Dependency association, and overridden to serve as an object reference to a BufferPool object. This reference identifies the BufferPool in which packets on the QueuingService's queue are stored.
このプロパティは、依存関係協会から継承されており、バッファプールオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、Queuingserviceのキューにあるパケットが保存されるバッファープールを識別します。
This property is inherited from the Dependency association, and overridden to serve as an object reference to a QueuingService object. This reference identifies the QueuingService whose packets are being stored in the BufferPool's buffers.
このプロパティは、依存関係協会から継承されており、Queuingserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、バッファープールのバッファーにパケットが保存されているQueuingserviceを識別します。
This property is an 8-bit unsigned integer with minimum value of zero and maximum value of 100. It defines the percentage of the BufferPool that should be allocated to the referenced QueuingService. If absolute sizes are desired, this would be accomplished by defining individual BufferPools of the specified sizes, with QueueAllocation.AllocationPercentages set to 100.
このプロパティは、ゼロの最小値と最大値が100の8ビットの署名整合体です。参照されるQueuingserviceに割り当てるべきバッファープールの割合を定義します。絶対サイズが必要な場合、これは指定されたサイズの個々のバッファープールを定義することで実現され、QueuealLocation.AllocationPercentagesが100に設定されています。
This association is a subclass of the Dependency association. It relates one or more ClassifierElements with a FilterList representing the criteria for selecting packets for each of the ClassifierElements to process.
この協会は、依存関係協会のサブクラスです。1つ以上の分類を関連付けて、プロセスする各分類のパケットを選択するための基準を表すフィルターリストに関連付けます。
In the QDDIM model, a classifier is always modeled as a ClassifierService that aggregates a set of ClassifierElements. When ClassifierElements use the NextServiceAfterClassifierElement association to bind to another ClassifierService (to construct a hierarchical classifier), the ClassifierElementUsesFilterList association must not be specified.
QDDIMモデルでは、分類器は常に、一連の分類を集計する分類子としてモデル化されます。classifierelementsがNextServicefterclassifierElement Associationを使用して別の分類器サービスにバインドする場合（階層分類器を構築するため）、classifierelementusesfilterlist Associationを指定してはなりません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME ClassifierElementUsesFilterList
DESCRIPTION An association relating a
ClassifierElement to the FilterList
representing the criteria for selecting
packets for that
ClassifierElement to process.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref FilterList [0..1]],
Dependent[ref ClassifierElement [0..n]]
This property is inherited from the Dependency association, and overridden to serve as an object reference to a FilterList object, instead of to the more general ManagedElement object. Also, its cardinality is restricted to 0 and 1, indicating that a ClassifierElement uses either one FilterList to select packets for it or no FilterList when the ClassifierElement uses the NextServiceAfterClassifierElement association to bind to another ClassifierService to form a hierarchical classifier.
このプロパティは、依存関係協会から継承されており、より一般的なマネージデリメントオブジェクトではなく、フィルターリストオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。また、そのカーディナリティは0と1に制限されており、ClassifierElementが1つのフィルターリストを使用して、ClassifierElementがNextServiceAfterClassifierElement Associatesを使用して別のクラシエルサービスにバインドして階層分類剤を形成する場合にフィルターリストを選択しないことを示しています。
This property is inherited from the Dependency association, and overridden to serve as an object reference to a ClassifierElement object, instead of to the more general ManagedElement object. This reference identifies a ClassifierElement that depends on the associated FilterList object to represent its packet-selection criteria.
このプロパティは、依存関係協会から継承されており、より一般的なマネージデリメントオブジェクトではなく、分類オブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。この参照は、関連するFilterListオブジェクトに依存して、パケット選択基準を表す分類を識別します。
This association defines two object references that establish a dependency relationship between two AFService objects. This dependency is the precedence of the individual AF drop-related Services within an AF IP packet-forwarding class.
この関連付けは、2つのAFServiceオブジェクト間の依存関係を確立する2つのオブジェクト参照を定義します。この依存関係は、AF IPパケットフォワードクラス内の個々のAFドロップ関連サービスの優先順位です。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME AFRelatedServices
DESCRIPTION An association used to establish
a dependency relationship between two
AFService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES AFLowerDropPrecedence[ref
AFService[0..1]],
AFHigherDropPrecedence[ref
AFService[0..n]]
This property serves as an object reference to an AFService object that has the lower probability of dropping packets.
このプロパティは、パケットをドロップする確率が低いAFServiceオブジェクトへのオブジェクト参照として機能します。
This property serves as an object reference to an AFService object that has the higher probability of dropping packets.
このプロパティは、パケットをドロップする確率が高いAFServiceオブジェクトへのオブジェクト参照として機能します。
This association defines two object references that establish a predecessor-successor relationship between two ConditioningService objects. This association is used to indicate the sequence of ConditioningServices required to process a particular type of traffic.
この協会は、2つの条件付けサービスオブジェクト間の前任者の関係を確立する2つのオブジェクト参照を定義します。この関連付けは、特定のタイプのトラフィックを処理するために必要な条件付けサービスのシーケンスを示すために使用されます。
Instances of this dependency describe the various relationships between different ConditioningServices (such as classifiers, meters, droppers, etc.) that are used collectively to condition traffic. Both one-to-one and more complicated fan-in and/or fan-out relationships can be described. The ConditioningServices may feed one another directly, or they may be mapped to multiple "next" Services based on the characteristics of the packet.
この依存関係のインスタンスは、トラフィックを条件付けるために集合的に使用される、異なる条件付けサービス（分類器、メーター、滴下など）間のさまざまな関係を説明しています。1対1とより複雑なファンインおよび/またはファンアウト関係の両方を説明できます。条件付けサービスは、互いに直接供給される場合や、パケットの特性に基づいて複数の「次の」サービスにマッピングされる場合があります。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME NextService
DESCRIPTION An association used to establish
a predecessor-successor relationship
between two ConditioningService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref
ConditioningService[0..n]],
FollowingService[ref
ConditioningService[0..n]]
This property serves as an object reference to a ConditioningService object that occurs earlier in the processing sequence for a given type of traffic.
このプロパティは、特定のタイプのトラフィックの処理シーケンスで早期に発生する条件付けサービスオブジェクトへのオブジェクト参照として機能します。
This property serves as an object reference to a ConditioningService object that occurs later in the processing sequence for a given type of traffic, immediately after the ConditioningService identified by the PrecedingService object reference.
このプロパティは、PERISINGSERVICEオブジェクトリファレンスで識別されたコンディショニングサービスの直後に、特定のタイプのトラフィックの処理シーケンスで後で発生する条件付けサービスオブジェクトへのオブジェクト参照として機能します。
This association refines the definition of its superclass, the NextService association, in two ways:
この協会は、次の2つの方法で、そのスーパークラスであるNext -Service Associationの定義を改良します。
o It restricts the PrecedingService object reference to the class ClassifierElement.
o 前のサービスオブジェクトの参照をクラスClassifierElementに制限します。
o It restricts the cardinality of the FollowingService object reference to exactly 1.
o FollowingService Object ReferenceのCardinalityを正確に1に制限します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME NextServiceAfterClassifierElement DESCRIPTION An association used to establish a predecessor-successor relationship between a single ClassifierElement within a Classifier and the next ConditioningService object that is responsible for further processing of the traffic selected by that ClassifierElement.
名前のnextservicefterclassifierelement説明説明分類子内の単一の分類係数と、その分類学的エレメントによって選択されたトラフィックのさらなる処理に責任がある次の条件付けサービスオブジェクトとの間の前任者とサクサスの関係を確立するために使用される関連付け。
DERIVED FROM NextService ABSTRACT False PROPERTIES PrecedingService [ref ClassifierElement[0..n]], FollowingService [ref ConditioningService[1..1]
NextService Abstractから派生したFalse Properties PerioningService [Ref ClassifierElement [0..N]]、FollowingService [Ref ConditioningService [1..1]
This property is inherited from the NextService association. It is overridden in this subclass to restrict the object reference to a ClassifierElement, as opposed to the more general ConditioningService defined in the NextService superclass.
このプロパティは、Next -Service Associationから継承されています。このサブクラスでは、Next -Service SuperClassで定義されているより一般的な条件付けサービスとは対照的に、オブジェクト参照を分類型に制限するためにオーバーライドされています。
This property serves as an object reference to a ClassifierElement, which is a component of a single ClassifierService. Packets selected by this ClassifierElement are always passed to the ConditioningService identified by the FollowingService object reference.
このプロパティは、単一のクラシファイアーサービスのコンポーネントである分類の要素へのオブジェクト参照として機能します。このclassifierElementで選択されたパケットは、常にフォローイングサービスオブジェクトリファレンスによって識別された条件付けサービスに渡されます。
This property is inherited from the NextService association. It is overridden in this subclass to restrict the cardinality of the reference to exactly 1. This reflects the requirement that the behavior of a DiffServ classifier must be deterministic: the packets selected by a given ClassifierElement in a given ClassifierService must always go to one and only one next ConditioningService.
このプロパティは、Next -Service Associationから継承されています。このサブクラスでは、参照のカーディナリティを正確に制限するためにオーバーライドされています。これは、diffserv分類器の動作が決定論的でなければならないという要件を反映しています。1つの次の条件付けサービス。
This association is a subclass of NextService, and defines two object references that establish a predecessor-successor relationship between PacketSchedulingServices. In a hierarchical queuing configuration where a second scheduler treats the output of a first scheduler as a single, aggregated input, the two schedulers are related via the NextScheduler association.
この協会は、NextServiceのサブクラスであり、PacketSchedulingservices間の前任者の関係を確立する2つのオブジェクト参照を定義します。2番目のスケジューラが最初のスケジューラの出力を単一の集約入力として扱う階層的なキューイング構成では、2つのスケジューラはNextScheduler Associationを介して関連しています。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME NextScheduler
DESCRIPTION An association used to establish
predecessor-successor relationships
between PacketSchedulingService objects
for simple hierarchical scheduling.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref
PacketSchedulingService[0..n]],
FollowingService[ref
PacketSchedulingService[0..1]]
This property is inherited from the NextService association, and overridden to serve as an object reference to a PacketSchedulingService object (instead of to the more general ConditioningService object). This reference identifies a scheduler whose output is being treated as a single, aggregated input by the scheduler identified by the FollowingService reference. The [0..n] cardinality indicates that a single FollowingService scheduler may bring together the aggregated outputs of multiple prior schedulers.
このプロパティは、Next -Service Associationから継承されており、より一般的な条件付けサービスオブジェクトの代わりに）PacketSchedulingserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、出力がFollowingServiceリファレンスによって識別されたスケジューラによって単一の集約入力として扱われているスケジューラを識別します。[0..n] Cardinalityは、単一のFollowingServiceスケジューラが複数の以前のスケジューラの集計された出力をまとめることができることを示しています。
This property is inherited from the NextService association, and overridden to serve as an object reference to a PacketSchedulingService object (instead of to the more general ConditioningService object). This reference identifies a scheduler that includes among its inputs the aggregated outputs of one or more PrecedingService schedulers.
このプロパティは、Next -Service Associationから継承されており、より一般的な条件付けサービスオブジェクトの代わりに）PacketSchedulingserviceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされています。このリファレンスは、入力の中から1つ以上の先行サービススケジューラの集約された出力を含むスケジューラを識別します。
This association is a subclass of the NextScheduler association. FailNextScheduler represents the relationship between two schedulers when the first scheduler passes up a scheduling opportunity (thereby behaving in a non-work conserving manner), and makes the resulting bandwidth available to the second scheduler for its use. See Sections 3.11.3 and 3.11.4 for examples of where this association might be used.
この協会は、NextScheduler Associationのサブクラスです。FailNextSchedulerは、最初のスケジューラがスケジューリングの機会を渡すとき（それにより非労働保存方法で動作する）2つのスケジューラー間の関係を表し、結果の帯域幅を2番目のスケジューラーで使用するために利用できるようにします。この関連付けの例については、セクション3.11.3および3.11.4を参照してください。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME FailNextScheduler
DESCRIPTION This association specializes the
NextScheduler association. It
establishes a relationship between a
non-work-conserving scheduler and a
second scheduler to which it makes
available the bandwidth that it elects
not to use.
DERIVED FROM NextScheduler
ABSTRACT False
PROPERTIES PrecedingService[ref
NonWorkConservingSchedulingService[0..n]]
This property is inherited from the NextScheduler association, and overridden to serve as an object reference to a NonWorkConservingSchedulingService object (instead of to the more general PacketSchedulingService object). This reference identifies a non-work-conserving scheduler whose excess bandwidth is being made available to the scheduler identified by the FollowingService reference. The [0..n] cardinality indicates that a single FollowingService scheduler may have the opportunity to use the unused bandwidth of multiple prior non-work-conserving schedulers.
このプロパティは、Next -Scheduler Associationから継承され、より一般的なPacketChedulingserviceオブジェクトの代わりに）非労働ConservingsCheDulingServiceオブジェクトへのオブジェクト参照として機能するようにオーバーライドされます。このリファレンスは、フォロースサービスリファレンスによって識別されたスケジューラが過剰な帯域幅を利用できるようにする非加工を受信するスケジューラを識別します。[0..N] Cardinalityは、単一のFollowingServiceスケジューラが、複数の以前の非作業継承スケジューラの未使用の帯域幅を使用する機会があることを示しています。
This association describes a predecessor-successor relationship between a MeterService and one or more ConditioningService objects that process traffic from the meter. For example, for devices that implement preamble marking, the FollowingService reference (after the meter) is a PreambleMarkerService, to record the results of the metering in the preamble.
この協会は、メーターサービスとメーターからトラフィックを処理する1つ以上の条件付けサービスオブジェクトとの間の前任者との関係について説明しています。たとえば、プリアンブルマーキングを実装するデバイスの場合、PREAMBLEMARKERSERVICE（メーターの後）がPreamblemarkerServiceであり、プリアンブルの計量結果を記録します。
It might be expected that the NextServiceAfterMeter association would subclass from NextService. However, meters are 1:n fan-out elements, and require a mechanism to distinguish between the different results/outputs of the meter. Therefore, this association defines a new key property, MeterResult, which is used to record the result and identify the output through which this traffic left the meter. Because of this additional key, NextServiceAfterMeter cannot be a subclass of NextService.
NextServiceaftermeter Associationは、NextServiceからサブクラス化することが予想される場合があります。ただし、メーターは1：nファンアウト要素であり、メーターの異なる結果/出力を区別するためのメカニズムが必要です。したがって、この関連付けは、結果を記録し、このトラフィックがメーターを離れた出力を識別するために使用される新しい重要なプロパティであるMeterresultを定義します。この追加キーのため、NextServiceaftermeterはNextServiceのサブクラスになることはできません。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME NextServiceAfterMeter
DESCRIPTION An association used to establish
a predecessor-successor relationship
between a particular output of a
MeterService and the next
ConditioningService object that is
responsible for further processing of
the traffic.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref MeterService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
MeterResult
The preceding MeterService, 'earlier' in the processing sequence for a packet. Since Meters are 1:n fan-out devices, this relationship associates a particular output of a MeterService (identified by the MeterResult property) to the next ConditioningService that is used to further process the traffic.
パケットの処理シーケンスの前のメーターサービス。メーターは1：nファンアウトデバイスであるため、この関係は、メーターサービス（Meterresultプロパティによって識別）の特定の出力を、トラフィックをさらに処理するために使用される次のコンディショニングサービスに関連付けます。
The 'next' or following ConditioningService.
「次」または次の条件付けサービス。
This property is an enumerated 16-bit unsigned integer, and represents information describing the result of the metering. Traffic is distinguished as being conforming, non-conforming, or partially conforming. More complicated metering can be built either by extending the enumeration or by cascading meters.
このプロパティは、列挙された16ビットの署名されていない整数であり、計量の結果を説明する情報を表しています。トラフィックは、適合、不適合、または部分的に適合していると区別されます。列挙を拡張するか、メーターをカスケードすることにより、より複雑な計量を構築できます。
The enumerated values are: "Unknown" (0), "Conforming" (1), "PartiallyConforming" (2), "NonConforming" (3).
列挙された値は、「不明」（0）、「適合」（1）、「部分的に構成」（2）、「不適合」（3）です。
This is a top-level association, representing the relationship between a queue (QueuingService) and a SchedulingElement. The SchedulingElement, in turn, represents the information in a packet scheduling service that is specific to this queue, such as relative priority or allocated bandwidth.
これは、キュー（Queuingservice）とスケジューリングエレメントの関係を表すトップレベルの関連付けです。次に、スケジューリングエレメントは、相対的な優先度や割り当てられた帯域幅など、このキューに固有のパケットスケジューリングサービスの情報を表します。
It cannot be expressed formally with the association cardinalities, but there is an additional constraint on participation in this association. A particular instance of (a subclass of) SchedulingElement always participates either in exactly one instance of this association, or in exactly one instance of the association SchedulingServiceToSchedule.
協会の枢機inalで正式に表現することはできませんが、この協会への参加には追加の制約があります。SchedulingElementの（サブクラスの）特定のインスタンスは、常にこの関連の1つのインスタンスのいずれか、またはAssociation SchedulingServiceToscheduleの正確な1つのインスタンスのいずれかに参加します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME QueueToSchedule
DESCRIPTION This association relates a queue to
the SchedulingElement containing
information specific to the queue.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES Queue[ref QueuingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
This property serves as an object reference to a QueuingService object. A QueuingService object may be associated 0 or more SchedulingElement objects.
このプロパティは、キューイングサービスオブジェクトへのオブジェクト参照として機能します。キューイングサービスオブジェクトは、0個以上のスケジューリングエレメントオブジェクトに関連付けられている場合があります。
This property serves as an object reference to a SchedulingElement object. A SchedulingElement is always associated either with exactly one QueuingService or with exactly one upstream scheduler (PacketSchedulingService).
このプロパティは、スケジューリングエレメントオブジェクトへのオブジェクト参照として機能します。スケジューリングエレメントは、常に正確に1つのQueuingserviceまたは1つのアップストリームスケジューラ（PacketSchedulingservice）に関連付けられています。
This is a top-level association, representing the relationship between a scheduler (PacketSchedulingService) and a SchedulingElement, in a configuration involving cascaded schedulers. The SchedulingElement, in turn, represents the information in a subsequent packet scheduling service that is specific to this scheduler, such as relative priority or allocated bandwidth.
これは、カスケードスケジューラを含む構成内のスケジューラ（PacketSchedulingservice）とスケジューリングエレメントとの関係を表すトップレベルの関連付けです。次に、スケジューリングエレメントは、相対的な優先度や割り当てられた帯域幅など、このスケジューラに固有の後続のパケットスケジューリングサービスの情報を表します。
It cannot be expressed formally with the association cardinalities, but there is an additional constraint on participation in this association. A particular instance of (a subclass of) SchedulingElement always participates either in exactly one instance of this association, or in exactly one instance of the association QueueToSchedule.
協会の枢機inalで正式に表現することはできませんが、この協会への参加には追加の制約があります。SchedulingElementの（サブクラス）の特定のインスタンスは、常にこの関連の1つのインスタンス、またはAssociation Queetoscheduleの1つのインスタンスのいずれかに参加します。
The class definition is as follows:
クラスの定義は次のとおりです。
NAME SchedulingServiceToSchedule DESCRIPTION This association relates a scheduler to the SchedulingElement in a subsequent scheduler containing information specific to this scheduler.
名前SchedulingServiceToscheduleの説明この関連付けは、このスケジューラに固有の情報を含む後続のスケジューラのスケジューリングにスケジューラを関連付けます。
DERIVED FROM Nothing ABSTRACT False PROPERTIES SchedService[ref PacketSchedulingService[0..1]], SchedElement[ref SchedulingElement[0..n]]
抽象的な偽のプロパティSchedservice [Ref PacketSchedulingservice [0..1]]、Schedelement [Ref SchedulingElement [0..N]]から派生したもの
This property serves as an object reference to a PacketSchedulingService object. A PacketSchedulingService object may be associated 0 or more SchedulingElement objects.
このプロパティは、PacketSchedulingserviceオブジェクトへのオブジェクト参照として機能します。PacketSchedulingserviceオブジェクトは、0以上のSchedulingElementオブジェクトに関連付けられている場合があります。
This property serves as an object reference to a SchedulingElement object. A SchedulingElement is always associated either with exactly one QueuingService or with exactly one upstream scheduler (PacketSchedulingService).
このプロパティは、スケジューリングエレメントオブジェクトへのオブジェクト参照として機能します。スケジューリングエレメントは、常に正確に1つのQueuingserviceまたは1つのアップストリームスケジューラ（PacketSchedulingservice）に関連付けられています。
This aggregation is a generic relationship used to model the aggregation of a set of ManagedElements in a generalized Collection object. The aggregation's cardinality is many to many.
この集約は、一般化されたコレクションオブジェクトの一連のマネージデリメントの集約をモデル化するために使用される一般的な関係です。集約のカーディナリティは多くの人にとって多くのことです。
MemberOfCollection is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
メンバーオフコレクションは、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This aggregation models the ability to treat a set of buffers as a pool, or collection, that can in turn be contained in a "higher-level" buffer pool. This class overrides the more generic MemberOfCollection aggregation to restrict both the aggregate and the part component objects to be instances only of the BufferPool class.
この集合体は、バッファーのセットをプールまたはコレクションとして扱う機能をモデル化します。これは、「高レベルの」バッファープールに順番に含めることができます。このクラスは、より一般的なメンバーオフコレクション集約をオーバーライドして、骨材クラスと部品コンポーネントオブジェクトの両方をBufferPoolクラスのみのインスタンスに制限します。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME CollectedBufferPool
DESCRIPTION A generic association used to aggregate
a set of related buffers into a
higher-level buffer pool.
DERIVED FROM MemberOfCollection
ABSTRACT False
PROPERTIES Collection[ref BufferPool[0..1]],
Member[ref BufferPool[0..n]]
This property represents the parent, or aggregate, object in the relationship. It is a BufferPool object.
このプロパティは、関係の親または集約のオブジェクトを表します。それはバッファプールオブジェクトです。
This property represents the child, or lower level pool, in the relationship. It is one of the set of BufferPools that together make up the higher-level pool.
このプロパティは、関係における子供、または低レベルのプールを表しています。これは、高レベルのプールを構成するバッファプールのセットの1つです。
This abstract aggregation is a generic relationship used to establish "part-of" relationships between managed objects (named GroupComponent and PartComponent). The association's cardinality is many to many.
この抽象的な集約は、管理されたオブジェクト（グループコンポーネントとパートコンポーネントと呼ばれる）間の「一部の」関係を確立するために使用される一般的な関係です。協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This aggregation is used to model a set of subordinate Services that are aggregated together to form a higher-level Service. This aggregation is derived from the more generic Component superclass to restrict the types of objects that can participate in this relationship. The association's cardinality is many to many.
この集約は、一緒に集約されて高レベルのサービスを形成する一連の下位サービスをモデル化するために使用されます。この集約は、この関係に参加できるオブジェクトの種類を制限するために、より一般的なコンポーネントのスーパークラスから派生しています。協会のカーディナリティは多くの人にとって多くのことです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
関連は、CIMのコアモデルで定義されています。このクラスの完全な定義については、[CIM]を参照してください。
This aggregation represents a set of subordinate QoSService objects (that is, a set of instances of subclasses of the QoSService class) that are aggregated together to form a higher-level QoSService. A QoSService is a specific type of Service that conceptualizes QoS functionality as a set of coordinated sub-services.
この集約は、互いに集約されて高レベルのQosserviceを形成する下位のQosserviceオブジェクト（つまり、Qosserviceクラスのサブクラスのインスタンスのセット）のセットを表します。Qosserviceは、QoS機能を調整されたサブサービスのセットとして概念化する特定のタイプのサービスです。
This aggregation is derived from the more generic ServiceComponent superclass to restrict the types of objects that can participate in this relationship to QoSService objects, instead of a more generic Service object. It also restricts the cardinality of the aggregate to 0-or-1 (instead of the more generic 0-or-more).
この集約は、より一般的なサービスオブジェクトとこの関係に参加できるオブジェクトの種類を制限するために、より一般的なサービスコンポーネントスーパークラスから派生しています。また、集合体のカーディナリティを0-OR-1に制限します（より一般的な0-MOREの代わりに）。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME QoSSubService
DESCRIPTION A generic association used to establish
"part-of" relationships between a
higher-level QoSService object and the
set of lower-level QoSServices that
are aggregated to create/form it.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
PartComponent[ref QoSService[0..n]]
This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). This object represents the parent, or aggregate, object in the relationship.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、Qosserviceオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。このオブジェクトは、関係の親または集計のオブジェクトを表します。
This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). This object represents the child, or "component", object in the relationship.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、Qosserviceオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。このオブジェクトは、関係の子または「コンポーネント」のオブジェクトを表します。
This aggregation identifies the set of conditioning services that together condition traffic for a particular QoS service.
この集約により、特定のQoSサービスのトラフィックを条件付けるコンディショニングサービスのセットが識別されます。
This aggregation is derived from the more generic ServiceComponent superclass; it restricts the types of objects that can participate in it to ConditioningService and QoSService objects, instead of the more generic Service objects.
この集約は、より一般的なサービスコンポーネントのスーパークラスから派生しています。より一般的なサービスオブジェクトの代わりに、それに参加できるオブジェクトの種類を条件付けサービスおよびQosserviceオブジェクトに制限します。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME QoSConditioningSubService
DESCRIPTION A generic aggregation used to establish
"part-of" relationships between a set
of ConditioningService objects and the
particular QoSService object(s) that they
provide traffic conditioning for.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..n]],
PartComponent[ref
ConditioningService[0..n]]
This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). The cardinality of the reference remains 0..n, to indicate that a given ConditioningService may provide traffic conditioning for 0, 1, or more than 1 QoSService objects.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、Qosserviceオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。参照のカーディナリティは0.nのままです。特定の条件付けサービスが0、1、または1つ以上のQosserviceオブジェクトのトラフィックコンディショニングを提供する可能性があることを示します。
This object represents the parent, or aggregate, object in the association. In this case, this object represents the QoSService that aggregates one or more ConditioningService objects to implement the appropriate traffic conditioning for its traffic.
このオブジェクトは、協会の親または集合体のオブジェクトを表します。この場合、このオブジェクトは、1つ以上の条件付けサービスオブジェクトを集約して、トラフィックの適切なトラフィックコンディショニングを実装するQosserviceを表します。
This property is overridden in this aggregation to represent an object reference to a ConditioningService object (instead of to the more generic Service object defined in its superclass). This object represents the child, or "component", object in the relationship. In this case, this object represents one or more ConditioningService objects that together indicate how traffic for a specific QoSService is conditioned.
このプロパティは、この集合体でオーバーライドされ、条件付けサービスオブジェクトへのオブジェクト参照を表します（スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに）。このオブジェクトは、関係の子または「コンポーネント」のオブジェクトを表します。この場合、このオブジェクトは、特定のQosserviceのトラフィックがどのように条件付けられているかを示す1つ以上の条件付けサービスオブジェクトを表します。
This aggregation represents the relationship between a classifier and the classifier elements that provide the fan-out function for the classifier. A classifier typically aggregates multiple classifier elements. A classifier element, however, is aggregated only by a single classifier. See [DSMODEL] and [DSMIB] for more about classifiers and classifier elements.
この集約は、分類器と分類器のファンアウト関数を提供する分類器要素との関係を表します。分類器は通常、複数の分類子要素を集約します。ただし、分類器要素は、単一の分類器によってのみ集約されます。分類器と分類子要素の詳細については、[dsmodel]および[dsmib]を参照してください。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME ClassifierElementInClassifierService
DESCRIPTION An aggregation representing the
relationship between a classifier
and its classifier elements.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref
ClassifierService[1..1]],
PartComponent[ref
ClassifierElement[0..n],
ClassifierOrder
This property is overridden in this aggregation to represent an object reference to a ClassifierService object (instead of to the more generic Service object defined in its superclass). It also restricts the cardinality of the aggregate to 1..1 (instead of the more generic 0-or-more), representing the fact that a ClassifierElement always exists within the context of exactly one ClassifierService.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、分類サービスオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。また、骨材のカーディナリティを1..1（より一般的な0またはムーアの代わりに）に制限し、分類が正確に1つの分類サービスのコンテキスト内に常に存在するという事実を表しています。
This property is overridden in this aggregation to represent an object reference to a ClassifierElement object (instead of to the more generic Service object defined in its superclass). This object represents a single traffic selector for the classifier. A ClassifierElement usually has an association to a FilterList that provides selection criteria for packets from the traffic stream coming into the classifier, and to a ConditioningService to which packets selected by these criteria are next forwarded.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、クラシファイアレメントオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。このオブジェクトは、分類器の単一のトラフィックセレクターを表します。通常、ClassifierElementには、Trafficストリームが分類子に入るパケットの選択基準を提供するフィルターリストと、これらの基準で選択されたパケットが次に転送される条件付けサービスに関連付けられています。
Because the filters for a classifier can overlap, it is necessary to specify the order in which the ClassifierElements aggregated by a ClassifierService are presented with packets coming into the classifier. This property is an unsigned 32-bit integer representing this order. Values are represented in ascending order: first '1', then '2', and so on. Different values MUST be assigned for each of the ClassifierElements aggregated by a given ClassifierService.
分類器のフィルターはオーバーラップできるため、分類器サービスによって集約された分類が分類器に入っているパケットが表示される順序を指定する必要があります。このプロパティは、この順序を表す署名されていない32ビット整数です。値は昇順で表されます：最初の '1'、 '2'など。特定のクラシファイアサービスによって集約された分類の各分類に対して、異なる値を割り当てる必要があります。
This aggregation is a specialization of the Component aggregation; it is used to define a set of filter entries (subclasses of FilterEntryBase) that are aggregated by a FilterList.
この集約は、コンポーネント集約の専門化です。これは、フィルターリストによって集約されているフィルターエントリのセット（FilterEntryBaseのサブクラス）を定義するために使用されます。
The cardinalities of the aggregation itself are 0..1 on the FilterList end, and 0..n on the FilterEntryBase end. Thus in the general case, a filter entry can exist without being aggregated into any FilterList. However, the only way a filter entry can figure in the QoS Device model is by being aggregated into a FilterList by this aggregation.
集約自体の基本は、フィルターリストの端で0..1、filterentrybase endで0..nです。したがって、一般的な場合、フィルターリストに集約することなくフィルターエントリが存在する可能性があります。ただし、QoSデバイスモデルでフィルターエントリが把握できる唯一の方法は、この集約によりフィルターリストに集約されることです。
See [PCIME] for the definition of this aggregation.
この集約の定義については、[PCIME]を参照してください。
This concrete aggregation represents the relationship between a PacketSchedulingService and the set of SchedulingElements that tie it to its inputs.
この具体的な集約は、PacketSchedulingserviceと入力に結び付けるスケジューリングセットのセットとの関係を表しています。
The class definition for the aggregation is as follows:
集約のクラス定義は次のとおりです。
NAME ElementInSchedulingService
DESCRIPTION An aggregation used to tie a
PacketSchedlingService to the
configuration information for one of
the elements (either a QueuingService or
another PacketSchedulingService) that it
schedules.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
PacketSchedulingService[0..1]],
PartComponent[ref
SchedulingElement[1..n]
This property is overridden in this aggregation to represent an object reference to a PacketSchedulingService object (instead of to the more generic Service object defined in its superclass). It also restricts the cardinality of the aggregate to 0..1 (instead of the more generic 0-or-more), representing the fact that a SchedulingElement exists within the context of at most one PacketSchedulingService.
このプロパティは、この集計では、スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに、PacketSchedulingserviceオブジェクトへのオブジェクト参照を表すためにオーバーライドされています。また、集合体のカーディナリティを0..1に制限します（より一般的な0-モアの代わりに）。これは、最大1つのPacketSchedulingserviceのコンテキスト内にスケジューリングセレメントが存在するという事実を表しています。
This property is overridden in this aggregation to represent an object reference to a SchedulingElement object (instead of to the more generic Service object defined in its superclass). This object represents a single scheduling element for the scheduler. It also restricts the cardinality of the SchedulingElement to 1..n (instead of the more generic 0-or-more), representing the fact that a PacketSchedulingService always includes at least one SchedulingElement.
このプロパティは、この集約でオーバーライドされ、スケジューリングエレメントオブジェクトへのオブジェクト参照を表します（スーパークラスで定義されているより一般的なサービスオブジェクトの代わりに）。このオブジェクトは、スケジューラの単一のスケジューリング要素を表します。また、スケジューリングエレメントのカーディナリティを1..n（より一般的な0またはモアの代わりに）に制限します。これは、PacketSchedulingserviceには常に少なくとも1つのスケジューリングエレメントが含まれるという事実を表しています。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。
Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
The authors wish to thank the participants of the Policy Framework and Differentiated Services working groups for their many helpful comments and suggestions. Special thanks to Joel Halpern, who provided some key technical direction during the latter stages of the document's development.
著者は、多くの有用なコメントや提案について、ポリシーフレームワークと差別化されたサービスワーキンググループの参加者に感謝したいと考えています。ドキュメントの開発の後期段階でいくつかの重要な技術的方向性を提供してくれたジョエル・ハルパーンに感謝します。
Like [PCIM] and [PCIME], this document defines an information model that cannot be implemented directly. Consequently, security issues do not arise until it is mapped to an actual, implementable data model such as a MIB, PIB, or LDAP schema. See [PCIM] for a general discussion of security considerations for information models. See also [DSMIB] (which in fact is a data model that corresponds to a large extent with the QDDIM information model), for a discussion of the security implications of specific objects in the model.
[PCIM]や[PCIME]と同様に、このドキュメントは、直接実装できない情報モデルを定義します。その結果、セキュリティの問題は、MIB、PIB、LDAPスキーマなどの実際の実装可能なデータモデルにマッピングされるまで発生しません。情報モデルのセキュリティに関する考慮事項の一般的な議論については、[PCIM]を参照してください。モデル内の特定のオブジェクトのセキュリティへの影響について説明するために、[DSMIB]（実際にはQDDIM情報モデルに大部分が対応するデータモデルです）も参照してください。
[CIM] Common Information Model (CIM) Schema, version 2.5. Distributed Management Task Force, Inc., available at http://www.dmtf.org/standards/cim_schema_v25.php.
[CIM]共通情報モデル（CIM）スキーマ、バージョン2.5。分散管理タスクフォース、Inc。、http：//www.dmtf.org/standards/cim_schema_v25.phpで入手可能。
[IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q, 1998 edition. Approved December 8, 1998
[IEEE802Q]仮想ブリッジ型ローカルエリアネットワーク、ANSI/IEEE STD 802.1Q、1998エディション。1998年12月8日承認
[PCIM] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model - Version 1 Specification", RFC 3060, February 2001.
[PCIM] Moore、B.、Ellesson、E.、Strassner、J。、およびA. Westerinen、「ポリシーコア情報モデル - バージョン1仕様」、RFC 3060、2001年2月。
[PCIME] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[PCIME] Moore、B.、ed。、「ポリシーコア情報モデル（PCIM）拡張機能」、RFC 3460、2003年1月。
[R791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[R791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[R2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[R2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[R2474] 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.
[R2474] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[R2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[R2597] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[R3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[R3140] Black、D.、Brim、S.、Carpenter、B。and F. Le Faucheur、「ホップの動作識別コード」、RFC 3140、2001年6月。
[DSMIB] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[DSMIB] Baker、F.、Chan、K。およびA. Smith、「差別化されたサービスアーキテクチャの管理情報ベース」、RFC 3289、2002年5月。
[DSMODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.
[DSModel] Bernet、Y.、Blake、S.、Grossman、D。、A。Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[PIB] Chan, K., Sahita, R., Hahn, S. and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, March 2003.
[Pib] Chan、K.、Sahita、R.、Hahn、S。、K。McCloghrie、「差別化されたサービスサービスポリシー情報ベース」、RFC 3317、2003年3月。
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[Polterm] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J. and S.Waldbusser、「ポリシーベースの管理のための用語」、RFC 3198、2001年11月。
[QPIM] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R. and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[QPIM] Snir、Y.、Ramberg、Y.、Strassner、J.、Cohen、R。、およびB. Moore、「Policy of Service of Service（QoS）情報モデル」、RFC 3644、2003年11月。
[R1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
[R1633] Braden、R.、Clark、D。、およびS. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、1994年6月。
[R2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[R2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[R3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[R3246] Davie、B.、Charny、A.、Bennet、J.C.R.、Benson、K.、Le Boudec、J.Y.、Courtney、W.、Davari、S.、Firoiu、V。およびD. Stiliadis、 "迅速な転送PHB（PER-HOP行動）」、RFC 3246、2002年3月。
[RED] See http://www.aciri.org/floyd/red.html
[赤] http://www.aciri.org/floyd/red.htmlを参照してください
Following the precedent established in [PCIM], this document has placed the details of how to name instances of its classes in a native CIM implementation here in an appendix. Since Appendix A in [PCIM] has a lengthy discussion of the general principles of CIM naming, this appendix does not repeat that information here. Readers interested in a more global discussion of how instances are named in a native CIM implementation should refer to [PCIM].
[PCIM]で確立された先例に続いて、このドキュメントは、ここのネイティブCIM実装にクラスのインスタンスを付録に名前を付ける方法の詳細を示しました。[PCIM]の付録Aには、CIMネーミングの一般原則について長い議論があるため、この付録はここでその情報を繰り返しません。ネイティブCIM実装でインスタンスがどのように指定されているかについてのよりグローバルな議論に関心のある読者は、[PCIM]を参照する必要があります。
Most of the classes defined in this model are derived from the CIM class Service. Although Service is an abstract class, it nevertheless has key properties included as part of its definition. The purpose of including key properties in an abstract class is to have instances of all of its instantiable subclasses named in the same way. Thus, the majority of the classes in this model name their instances in exactly the same way: with the two key properties CreationClassName and Name that they inherit from Service.
このモデルで定義されているクラスのほとんどは、CIMクラスサービスから派生しています。サービスは抽象クラスですが、それでも定義の一部として重要なプロパティが含まれています。抽象クラスに重要なプロパティを含める目的は、同じ方法で名前が付けられたすべての瞬時のサブクラスのインスタンスを持つことです。したがって、このモデルのクラスの大部分は、インスタンスをまったく同じ方法で名前を付けます。2つの重要なプロパティCREATIONCLASSNAMEと、サービスから継承する名前。
Like Service, FilterEntryBase (defined in [PCIME]) is an abstract class that includes key properties in its definition. FilterEntryBase has four key properties. Two of them, SystemCreationClassName and SystemName, are propagated to it via the weak association FilterEntryInSystem. The other two, CreationClassName and Name, are native to FilterEntryBase.
サービスと同様に、filterentrybase（[PCIME]で定義）は、その定義に重要なプロパティを含む抽象クラスです。filterentrybaseには4つの重要なプロパティがあります。そのうちの2つ、SystemCreationClassNameとSystemNameは、弱い関連付けFilterentryInsystemを介してそれに伝播されます。他の2つのCreationClassNameと名前は、FilterEntryBaseのネイティブです。
Thus, instances of all of the subclasses of FilterEntryBase, including the PreambleFilter class defined here, are named in the same way: with the four key properties they inherit from FilterEntryBase.
したがって、ここで定義されているプリアンブルフィルタークラスを含むFilterentryBaseのすべてのサブクラスのインスタンスは、同じ方法で名前が付けられています。4つの重要なプロパティで、FilterentryBaseから継承します。
The class ProtocolEndpoint inherits its key properties from its superclass, ServiceAccessPoint. These key properties provide the same naming structure that we've seen before: two propagated key properties SystemCreationClassName and SystemName, plus two native key properties CreationClassName and Name.
クラスのプロトコレンドポイントは、スーパークラスのServiceCassPointから重要なプロパティを継承しています。これらのキープロパティは、以前に見たのと同じ命名構造を提供します。2つの伝播されたキープロパティSystemCreationClassNameとSystemNameに加えて、2つのネイティブキープロパティCreationClassNameと名前。
Unlike the other classes in this model, BufferPool is not derived from Service. Consequently, it does not inherit its key properties from Service. Instead, it inherits one of its key properties, CollectionID, from its superclass Collection, and adds its other key property, CreationClassName, in its own definition.
このモデルの他のクラスとは異なり、BufferPoolはサービスから派生していません。その結果、サービスから重要なプロパティを継承しません。代わりに、スーパークラスコレクションから重要なプロパティの1つであるCollectionIDを継承し、独自の定義に他の重要なプロパティであるCreationClassNameを追加します。
CollectionID is a string property with a maximum length of 256 characters. It identifies the buffer pool. Note that this property is defined in the BufferPool class's superclass, CollectionOfMSEs, but not as a key property. It is overridden in BufferPool, to make it part of this class's composite key.
CollectionIDは、最大長さ256文字の文字列プロパティです。バッファープールを識別します。このプロパティは、BufferPoolクラスのスーパークラスであるCollectionOfMSESで定義されているが、重要なプロパティとしてではないことに注意してください。このクラスの複合キーの一部にするために、BufferPoolでオーバーライドされています。
This property is a string property of with a maximum length of 256 characters. It is set to "CIM_BufferPool" if this class is directly instantiated, or to the class name of the BufferPool subclass that is created.
このプロパティは、最大256文字の長さの文字列プロパティです。このクラスが直接インスタンス化されている場合、または作成されたbufferpoolサブクラスのクラス名に「cim_bufferpool」に設定されます。
This class has not yet been incorporated into the CIM model, so it does not have any CIM naming properties yet. If the normal pattern is followed, however, instances will be named with two properties CreationClassName and Name.
このクラスはまだCIMモデルに組み込まれていないため、CIMネーミングプロパティはまだありません。ただし、通常のパターンに従うと、インスタンスは2つのプロパティCreationClassNameと名前で名前が付けられます。
Bob Moore P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
Bob Moore P. O. Box 12195、BRQA/B501/G206 3039 Cornwallis Rd。研究トライアングルパーク、NC 27709-2195
Phone: (919) 254-4436 EMail: remoore@us.ibm.com
電話：（919）254-4436メール：remaore@us.ibm.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
David Durham Intel 2111 NE 25th Avenue Hillsboro、または97124
Phone: (503) 264-6232 EMail: david.durham@intel.com
電話：（503）264-6232メール：David.durham@intel.com
John Strassner INTELLIDEN, Inc. 90 South Cascade Avenue Colorado Springs, CO 80903
John Strassner Intelliden、Inc。90 South Cascade Avenue Colorado Springs、Co 80903
Phone: (719) 785-0648 EMail: john.strassner@intelliden.com
電話：（719）785-0648メール：john.strassner@intelliden.com
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
Andrea Westerinen Cisco Systems、Bldg 20 725 Alder Drive Milpitas、CA 95035
EMail: andreaw@cisco.com
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH 03054
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack、NH 03054
Phone: (603) 879-7364 EMail: walterweiss@attbi.com
電話：（603）879-7364メール：walterweiss@attbi.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。