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
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）インターネット協会（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）を記述するためにホストを含む異なるネットワークデバイスに固有のメカニズムを情報モデルを定義することです。大まかに言えば、これらのメカニズムは、ネットワークデバイスの転送経路（データパス）を介して選択して空調トラフィックに共通の特性を記述する。差別化サービスおよび統合サービス：データパスにおけるトラフィックのこの選択とコンディショニングは、主要な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メカニズム（すなわち、分類、マーキング、計量、落下、キューイング、およびスケジューリング機能）を設定するために定義することができますどのようにモデル化するためのQoSポリシー情報モデル（QPIM）して使用する必要があります。一緒に、これら二つの文書は、デバイスのデータパスに存在する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）を記述するためにホストを含む異なるネットワークデバイスに固有のメカニズムを情報モデルを定義することです。大まかに言えば、これらのメカニズムは、ネットワークデバイスの転送経路（データパス）を介して選択してコンディショニングトラフィックに共通の属性を記述する。 （[R1633]参照）差別化サービス（[R2475]参照）、統合サービス：データパスでこれを選択し、トラフィックのコンディショニングは、主要なQoSアーキテクチャの両方にまたがります。
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メカニズム（すなわち、分類、マーキング、計量、落下、キューイング、およびスケジューリング機能）を管理および設定するために定義することができますどのようにモデル化するためのQoSポリシー情報モデル[QPIM]で使用することを意図しています。一緒に、これら二つの文書は、デバイスのデータパスに存在する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.
本書で取られたアプローチは、デバイスのデータパスにおけるQoSをモデル化するために使用できるクラスの共通セットを定義します。ベンダーは、その後、独自のデバイス固有の実装に、直接または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]).
この文書に記述されたクラス、関連、および集計階層の設計は、Distributed Management Task Force（DMTF）によって定義されたネットワークのQoSサブモデルの影響を受けている - [CIM]を参照してください。これらの階層は方針コア情報モデル[PCIM]に由来していません。デバイスのQoSメカニズムのモデル化は、それらのメカニズムを管理政策のモデリングから独立した別個のだからです。したがって、それらの制御（QoSポリシーの文書[QPIM]によって拡張汎用ポリシー文書[PCIM]を使用して、指定された）からQoSメカニズム（本書）を分離する必要があります。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
オペランドのこれらの2つのセットの間の関係、O。
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].
オペランドは、ジョー（ユーザ）または金（サービス）として、ハイレベルで指定することができます。オペランドはまた、詳細の多くの細かいレベル、装置の動作に非常に近い一方に指定することができます。後者の例としては、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:
ポリシーの条件とアクションの第二成分は、演算子のセットです。オペレータは、両方の関係を表現することができる（より大きい、セット、ブールORなどの部材）と割り当て。併せて、演算子およびオペランドは、次のような条件とアクション、さまざまな表現することができます。
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アドレスは10 MBにxをマーケティングサブネット... 192.0.2.100リミットに設定ジョーのIPアドレスでアプリケーションの帯域幅であれば、ボブは...エンジニアであれば
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:
ポリシーは、本明細書に記載された情報モデルを使用して、低レベルのルールとして実現することができます。例えば、低レベルポリシーに、条件は、このモデルから特定の属性の評価として表すことができます。したがって、例えば、条件「IFフィルタ= HTTP」は、任意のHTTPフィルタがデバイス用に定義されているかどうかを決定するテストとして解釈されます。そのような「プロトコル= 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. DSCPマーカ24 3.バインドHTTPフィルタの値とDSCPマーカーを作成HTTPフィルタ2を作成します
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のマーク、」これらの低レベルのアクションがパケット上で実行されていないことに注意してください。むしろ、彼らは正しいパケット（S）で正しいアクションを行うことができるようにするまでに、デバイス自体に実行される構成アクションです。低レベルのデバイス構成動作の正しいセットにハイレベルのポリシールールから移動する動作は、[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は）（[POLTERM]、[R1633]と[R2475]を参照します）。この文書では、パケットトラフィックが調節されるデータパスをモデル化するためのQoSプロパティとクラスの仕様に焦点を当てています。しかし、この文書のクラスで定義されたフレームワークは、同様に心の中でイントサーブのアドミッション制御部分のニーズに合わせて設計されています。
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は、2つの主成分を有します。一方の成分は、ネットワーク装置のデータパスに埋め込まれています。その機能は、アウトバウンドリンクの分類と個々のフローのポリシング、およびスケジューリングを認めたパケットが含まれます。 IntServの他の構成要素は、シグナリングプロトコル（例えば、RSVPのPATHと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の要素は、クラスの構造に考慮されます。我々が以前に示されているような完全なイントサーブデバイスモデルは、その後の文書で対処されることになります。
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はデータパスでのみ動作します。これは、2つの大きな違いで、イントサーブのデータパスの同じコンポーネントのすべてを持っています。イントサーブは、標準的な流れのアドレッシングの5-タプルのサブセットを調べに対し、まず、DiffServは、単に彼らのDSCPフィールドに基づいてパケットを分類します。この規則の例外は、DiffServのドメインの境界にあるルータまたはホストで発生します。この位置で装置は、そのは、のDiffServドメインへの転送前にパケットをマークするとDSCP値を決定する際に、完全にパケット外5タプル、他のフィールドのパケットに、あるいはアドレス情報を、パケットのDSCPを調べることができます。しかし、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はパーホップ行動（の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マッピング、remarkings、および他の因子の付加的な複雑さを考慮しなければなりません。追加のモデリングは、この分野で必要とされます。しかし、最初に、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ポリシーが発現されるべき抽象化のレベルです。私たちがイベントに反応し、属性を操作したり、新しいイベントを生成するために使用されるルールのセットなどのポリシーを考えると、私たちは、ポリシーは、デバイスまたはのセットによって行われたトラフィックのコンディショニングにビジネス目標とルールを関連付ける仕様の連続を表していることを実感しますデバイス。ビジネス・レベル・ポリシーの例は次のようになります。午後1時PSTから午前7時ESTに、公開市場でのネットワーク容量の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
図1.ポリシーの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.
高レベルのビジネス・ポリシーは、異なるアプリケーションの要件を表現し、ネットワークが混雑している時に、「より良い」治療を受けているアプリケーションの優先順位を決定するために使用されています。目標は、その後、ネットワーク管理者は、デバイスが属するネットワークに実装しようとしているビジネスルールに直接デバイスの動作や構成ニーズに関連するポリシーを使用することです。
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.
デバイスに依存しないポリシーは、任意の特定のデバイスに依存しないが、そのようなランダム早期検出（RED）落としたり、重み付けラウンドロビンスケジューリングなどの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:
これら二つの目標は抽象化の次の一連の必要性を決定づけます：
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.
（[QPIM]で定義されている）これらの抽象化、政策を考えると、この文書で定義されたQoSメカニズムとサービスを制御するために書き込むことができます。
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の（集約トラフィック調整用）とイントサーブ（フローベースのトラフィック調整用）の両方をサポートするデータパスでのサービスの表現に集中します。イントサーブアドミッション制御サービスをモデル化するためのクラスとプロパティは、将来の文書で定義されてもよいです。
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によって非常に限られた方法で対処されます。現在、唯一CurrentQueueDepthは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キュー）であってもよいですキューイング（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サービスを表すために情報モデルを定義することに集中しますが、最終的な目標は、ネットワークデバイスでこれらのサービスを制御するポリシーを適用できるようにすることです。さらに、これらの二つのスキーマ（デバイスおよびポリシーが）しっかり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 MBを取得する）絶対数として表される場合、なぜならリンク容量における幅広い変化を、デバイスまたは複数のデバイス上の複数のポート間でそれらを均一にすることはより困難です。しかし、相対的または比例項（例えば、クラスAF2は、全リンク帯域幅の5％を得る）ことがより困難などの条件およびアクション、特定の種類を表現することを可能にするの属性を表します。
(If ConsumedBandwidth = AssignedBandwidth Then ...)
（消費される帯域幅=次に、帯域幅を割り当てた場合は...）
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は0.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の非公式管理モデル[DSMODEL]の現在のバージョンで提供された情報に基づいて、DiffServのMIB [DSMIB] PIB [PIB]、同様の基本的な定義を構成する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とConditioningService基底クラスから派生します。アソシエーションの組が、より高いレベルのQoSサービスに低レベルQoSServiceサブクラスに関連するトラフィッククラスを処理する際に一緒に調整異なるタイプのサービスに関連し、特定の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配信のためのFlowServiceとDiffServの集計指向の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
QoSサービスはピアとして相互に関連することができ、または彼らはお互いに従属サービスとして実装することができます。 QoSSubService凝集は、一つ以上のQoSServiceオブジェクトが特定QoSServiceオブジェクトに従属していることを示しています。たとえば、これは2つのDiffServのサービス、高品質なトラフィック処理のための1、およびトラフィックの残りの部分をサービスするための1の組み合わせとして、ゴールドサービスを定義することを可能にします。それぞれの
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.
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のサブクラスに比べ、ConditioningService階層内に捕捉されています。
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.
QoSServiceオブジェクトは、両方の凝集QoSServiceのセットは、それに従属オブジェクト、およびそれを実現するConditioningServiceオブジェクトのセット：これらの概念は、関連付けの両方が集計されていることが図2注に示されています。クラスとの関連の定義については、セクション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.
ConditioningServiceクラスの目標は、それがデバイスを出るそれを通して出力インターフェイス上で、デバイスに入り、そこを通って入力インターフェイス上で与えられたトラフィックストリームに適用される交通調節のシーケンスを記述することです。これは、クラスと関係のセットを使用して行われます。特定のパケットが使用するどのイグレスインターフェース選択デバイスコアにルーティング決定は、このモデルで表現されていません。
A single base class, ConditioningService, is the superclass for a set of subclasses representing the mechanisms that condition traffic.
単一の基底クラス、ConditioningServiceは、その条件トラフィック機構を表すサブクラスのセットのスーパークラスです。
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特定の入力または出力インターフェースはConditioningServicesのすべてのタイプを必要としません。
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入力または出力インターフェイス上ConditioningServicesのためのアプリケーションの決まった順序はありません。
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).
したがって、このモデルはConditioningServiceのサブクラス間で一定の順序を決定、または入力または出力インターフェイス上ConditioningServices中で最初または最後に表示しなければならないConditioningServiceのサブクラスを識別しません。代わりに、一緒にこのモデルタイNextService、NextServiceAfterMeter、及びNextServiceAfterConditioningElementアソシエーションを使用して、入力または出力インターフェイス上の様々なConditioningServiceインスタンス。 、それぞれ、その第一ConditioningServiceに入力インターフェイスを結ぶ、その最後ConditioningService（S）に出力インターフェイスを結ぶIngressConditioningServiceOnEndpointとEgressConditioningServiceOnEndpointと呼ばれる別の関連は、もあります。
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]から分岐する一つの重要な方法があります。 【DSMODEL]において、トラフィックは、三の段階でネットワークデバイスを通過します。
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の範囲外ロジックは、デバイスを残すために使用するどのイグレスインタフェース決定ルーティングコアを横切ります。
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モデルは、パケットが出力インターフェイスにパケットと共に通信される入力インターフェイス上で受信された処理に関する情報を可能にするために、この制限が緩和されます。 （この緩和は、多くのネットワークデバイスに存在する機能が追加されました。）QDDIMは、多くのデバイスがそれを実装する方法であるパケットプリアンブルの点で、この情報転送を表します。しかし、実装は同じ結果を達成するために他のメカニズムを自由に使用できます。
+---------+
| Meter-A |
a | | b d
--->| In-|---PM-1--->
| | c e
| Out-|---PM-2--->
+---------+
Figure 3: Meter Followed by Two Preamble Markers
図3：二つの前文マーカーが続くメーター
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は、メータ結果は、パケットのプリアンブルで捕捉された例を示しています。単一文字で標識した矢印はNextServiceアソシエーション（、D、およびE）のいずれか、またはそのピアアソシエーションNextServiceAfterMeter（B及びC）のインスタンスを表します。 PreambleMarker PM-1は、パケットのプリアンブルにパケットがトラフィックを準拠するようメータAを終了した旨の表示を追加します。同様に、PreambleMarker 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.
相互運用性を促進するために、PreambleMarkerによってキャプチャされた情報の基本的な形式が指定されています。情報は、各個々の値順序付け、多値文字列プロパティFilterItemList、で表される - （これは、それがモデルに表されているどれだけある実装は、当然のことながら、内部の異なる方法でこの情報を表すために自由です。）プロパティには、「<タイプ>、<値>」の形式です。 PreambleMarkerが既にパケットのプリアンブル中に存在した情報を、その情報を「追加」するとき、それはリストの最後に示された形式の追加項目を追加することによってそうします。
QDDIM provides a limited set of <type>'s that a PreambleMarker may use:
QDDIMは<タイプ>のPreambleMarkerが使用できることの限られたセットを提供します。
o ConformingFromMeter: the value is the name of the meter.
O ConformingFromMeter：値はメートルの名前です。
o PartConformingFromMeter: the value is the name of the meter.
O PartConformingFromMeter：値はメートルの名前です。
o NonConformingFromMeter: the value is the name of the meter.
O NonConformingFromMeter：値はメートルの名前です。
o VlanId: the value is the virtual LAN identifier (VLAN ID).
VLANID（O）値は、仮想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.
実装は、これらに加えて、他の<タイプ>のを認識することができます。実装固有の<タイプ>の衝突のが問題となっ、<タイプ>可能性がある」場合の、この文書の将来の改訂で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の特定のサブクラスPreambleFilterは「<タイプ>、<値>」の文字列に一致するように、定義されています。単に装置における計量の単一レベルが、各入力インターフェイス上の異なる個々のメーターがありますケースを簡単にするために、PreambleFilterは3メートルに関連するフィルタの<value>の部分は、「任意」のワイルドカードを可能にします。このワイルドカードで、管理者は、別ClassifierElementに個別メーターに名前を付けることなく、適合（または部分的に適合、または不適合）それぞれメートルであることが判明したすべてのパケットを選択するために分類を指定することができます。
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.
ClassifierService、ClassifierElement、FilterList、FilterEntryBase、及びFilterEntryBaseの様々なサブクラス：この文書では、[DSMODEL]で定義された分類器をモデル化するクラスの数を使用します。 ClassifierElementUsesFilterListとEntriesInFilterList：関与する2つの団体もあります。 QDDIMモデルはCIMのFilterEntryクラスを使用しません。
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タプルヘッダフィールド及びDiffServのDSCPのすべての5つに基づいてパケットを選択するための基準は、一個のIPHeaderFilterオブジェクトを含むFilterListで表すことができます。これら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].
FilterListオブジェクトは常にオブジェクト（つまり、1つのFilterEntryBaseサブクラスである）、それが唯一のフィルタエントリが含まれている場合でも、必要とされています。個々FilterEntryとは対照的に、ClassifierElementのみ、フィルタリストに関連付けることができるからです。 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.
（また、[PCIME]で定義される）EntriesInFilterList凝集がFilterListのフィルタエントリの評価順序を指定するために使用することができる（CIMにおける）過去の性質EntrySequenceを有しています。 「0」：さて、しかし、EntrySequenceプロパティが単一の値のみをサポートしています。この値はFilterEntriesパケットがFilterListが表すMFセレクタと一致するかどうかを決定するために一緒にAND処理されることを示します。
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はへのパケットに適用するために、次の調整サービスを決定するためにNextServiceAfterClassifierElementアソシエーションを使用します。
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
ClassifierServiceはClassifierElementsのグルーピングを定義します。 ClassifierServiceが実際にClassifierServicesの凝集を指定する特定の場合があります。各ClassifierServiceは、特定のアプリケーションに関連付けられたポリシーと他ClassifierServiceグループアプリケーション固有ClassifierServiceインスタンスのグループを指定する場合に一つの実用的な場合があろう。この特定のケースでは、アプリケーション固有のClassifierServiceインスタンスが一度指定されているが、必要に応じてこれらClassifierServicesのユニークな組み合わせは、他のClassifierServiceインスタンスを使用して、指定されています。他のClassifierServiceインスタンスをグループ化ClassifierServiceインスタンスが使用FilterListを指定しなくてもよいです
ClassifierElementUsesFilterList association. This special use of ClassifierService serves just as a Classifier collecting function.
ClassifierElementUsesFilterList協会。 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では、ドロッパー、これらのタイプの両方がDropperServiceクラスで、またはそのサブクラスの1つでモデル化されています。両方の場合において、ドロッパーはパケットを廃棄そこからキューがNextServiceアソシエーションのインスタンスによってドロッパーに接続されています。ドロッパーは、常にこれらの団体にPrecedingServiceの役割を果たし、そしてキューは常にFollowingServiceの役割を果たしています。スポイトがパケットをドロップし、そこから正確に一つのキューが常にあります。
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:
絶対的なドロッパーはそのキュー内のすべてのパケットをドロップするので、それはそのキューにNextServiceネクタイを越えて何も設定を必要としません。アルゴリズムのドロッパーのために、しかし、追加の設定が必要です。
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;
アルゴリズムへの入力（複数可）のソース（S）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.
これらの項目の最初の二つはDropperServiceクラスのプロパティ、またはそのサブクラスの1つの特性で表されます。最後の二つは、しかし、追加のクラスと関連を伴います。
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:
HeadTailDropQueueBindingテール点滴器によって実行されるアルゴリズムのための入力を識別する関連です。ヘッドドロッパーは、常にそのドロップアルゴリズムに正確に1つの入力を持っており、この入力は常にそれがパケットを廃棄し、そこからキューであるため、この関連付けは、ヘッド点滴のために使用されていません。テールスポイトでは、この関連付けは、多対多のカーディナリティを持つように定義されています。二つの異なる例は、しかし、があります。
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.
一つのドロッパーは、多くのキューにバインドされた：これは、スポイトのドロップアルゴリズムが複数のキューからの入力を必要とする場合を示しています。ドロッパーはまだ唯一のキュー、それはNextService協会によって結ばれるために1から落下します。しかし、ドロップの決定は、複数のキューの状態によって影響され得ます。クラスHeadTailDropperとHeadTailDropQueueBindingため、複数の入力を結合するためのルールは、単純な加算である：監視対象キューの長さの合計は、スポイトのQueueThreshold値を超えると、パケットがドロップされます。入力を結合するためのこの規則は、しかし、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:
一つのキューは、多くの点滴に結合した：これは、（典型的には、パケットがドロップされるキューである）のキューの状態は、複数のドロッパードロップアルゴリズムへの入力を提供する場合を示します。ここでのユースケースは、トラフィックの4つのクラスを表す、四つの部分、たとえば、へのトラフィックストリームを分割分類器です。部品の各々は、それらが同じキューに再統合されている、別のHeadTailDropperを通過します。ネットは次のドロップしきい値、たとえば、で、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.
ドロッパーは、複数のキューから、他の点滴への入力を提供している1つ以上の入力を受信した場合、ここで説明した2つのケースはまた、一緒に起こり得ます。
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クラスのインスタンスで表されるテールスポイト、REDスポイト、同じように、その入力として、複数のキューの状態をとることがあります。しかしながら、この場合、追加のステップがある：RED点滴器はそれを使用する前に、これらの入力の各々を平滑化することができる、及び平滑化処理自体は、パラメータ化されなければなりません。したがって、REDDropperServiceとQueuingService、第三級、DropThresholdCalculationServiceに加えて、この平滑化処理のキューごとのパラメータを表すために、導入されます。
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
REDドロッパー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会合を介してパケットをドロップし、そこからキューにリンクされている。）これら3つのキューのそれぞれについて、検索時に使用する平滑化量及び時間間隔を表す（DropThresholdCalculationService）DTCSインスタンスが存在しますそのキューで。単一のキューに複数のDTCSインスタンスによって（異なる量および時間値で）を調べてもよい従って、各DTCSインスタンスは、正確に一つのキューに接続されています。また、DTCSインスタンスとその背後にあるキューは、「再利用の単位」と考えることができます。だから、単一DTCSは、複数の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ドロッパーは、そのドロップの決定を行う際に使用する値を作成するために、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.
シンプルな、階層的なスケジューラは、以下の特性を有します。スケジューリング機会は、キューのセットに与えられたときにまず、シングル、実行可能なキューは、帯域幅や優先順位など、いくつかのスケジューリング基準に基づいて決定されます。スケジューラの出力は、単一の論理キューとして第1のスケジューラ（およびそのキュー）を扱う別のスケジューラに入力されます。第1のスケジューラが各キューに割り当てられた優先順位に基づいて解放するために適切なパケットを決定した場合従って、第2のスケジューラは第1のスケジューラによって集約キューの組全体の帯域幅限界/割り当てを指定できます。
+----------+ 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
図5.例1：単純な階層的なスケジューラ
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は、一例を示しており、それは、モデルを使用してどのようにインスタンス化されるであろう。図では、NextServiceは、キューの後に第1のスケジューラを決定します。 NextSchedulerは、スケジューラのその後の順序を決定します。また、ElementSchedulingService関連付けは、特定のスケジューラによって使用されるスケジューリング・パラメータのセットを決定します。スケジューリングパラメータは、キューやスケジューラのいずれかに結合することができます。 QueueToScheduleアソシエーションが使用されるようにSchedulingElement EF1-PRIの場合、結合は、キューにあります。 SchedulingElement PriSched1バンドの場合には、結合は、別のスケジューラにあるので、SchedulerToScheduleアソシエーションが使用されます。文書の空間的な制約のため、SchedulingService PRISched1は、それが他のすべてのオブジェクトに接続されているかを示すために、二回表されることに注意してください。
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は、NextServiceアソシエーションを介して優先スケジューラの両方のポインティングをキュー（BE）EFキューとベストエフォートを記述することによって、この状況を示しています。優先度スケジューラと順番に帯域幅スケジューラ間NextScheduler協会は、スケジューリング階層の順序を定義します。また、各スケジューラが各キューに戻ってバインドされているスケジューリング・パラメータの明確なセットを持っていることに注意してください。これは、キューごとに二つ以上のパラメータセットをサポートする必要性を示しています。
+----------------+
|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アソシエーションを使用していることを除いて、図6に非常に類似して見えます。この関連付けは、明示的に割当スケジューラがスケジューリング検討のために拒否され、空でないキューがある場合、WRRスケジューラが使用されるだけの時間があることを表示しています。その中で、典型的割当スケジューラとWRRスケジューラに結合されているいくつかの複数のキューが存在することになる、図7が不完全であることに留意されたいです。
+------------+
|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）スケジューラは考慮すべき第四のシナリオです。階層CBQでは、各キューは、特定の帯域幅割り当てを割り当てられています。キューは論理的なスケジューラにグループ化されています。順番にこの論理スケジューラは、スケジュールされたキューの合計に等しい総帯域幅の割り当てを持っています。次に、論理スケジューラは、より高いレベルの論理スケジューラに集約することができます。視点を変えると、トップを見下ろして、一番上の論理的なスケジューラは、リンク容量の100％を持っています。この割り当ては、そのような割り当ての合計は100％に等しくなる以下の論理スケジューラに出parceledれます。これらの第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スケジューリングサービスインスタンスで、その結果、理由はスペースの制約の半分に分割されます。上段における全割り当てが50メガビットであることに留意されたいです。ボイス割り当ては22 MBです。残りの23 MBがFTPとWebの間で分割されます。したがって、ウェブ・トラフィックが実際に20メガビット（割り当ての過剰5 MB）を消費している場合。 FTPは、5 MBを消費している場合CBQTier1スケジューラはWebトラフィックへの割り当て3MBのを提供するために、それが可能です。しかし、これでは十分ではありませんので、FailNextScheduler協会は、音声クラスから利用可能な余剰能力があるかどうかを決定するために横断する必要があります。音声クラスのみがその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は、それが他のすべてのオブジェクトに接続されているかを示すために、二回表されることに注意してください。
+-----------+ 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.
それは/が収集に関するものであっても、会合（または凝集）オブジェクトがアトミックユニット（個別インスタンス）として扱われることに注意してください/複数のオブジェクトで構成されています。これは、アソシエーション（または凝集）の決定的な特徴である - 他のオブジェクトに関連する個々の要素は、独自のアイデンティティを持っているが、これらのオブジェクトを使用して構築されている関連付け（または凝集）の目的は、同様に独自のIDと名前を持ちます。
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.
最後に、二つのクラスの間で定義されている団体や集計がクラス自体には影響を与えないことに注意してください。すなわち、関連の付加または欠失または凝集は、それが接続されているクラスのインターフェイスに影響を及ぼしません。
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に表記（CIMCORE）はCIMコアモデルで定義されたクラスを識別し、それぞれ、示されています。これらのクラスの定義について[CIM]を参照してください。同様に、表記[PCIME]は方針コア情報モデルの拡張文書で定義されたクラスを識別する。このモデルは、[CIM]の影響を受け、およびディレクトリ対応ネットワーク（DEN）の努力と互換性がありますされています。
+--ManagedElement (CIMCORE) | +--ManagedSystemElement (CIMCORE) | | | +--LogicalElement (CIMCORE) | | | +--Service (CIMCORE) | | | | | +--ConditioningService | | | | | | | +--ClassifierService | | | | | | | | | +--ClassifierElement | | | | | | | +--MeterService | | | | | | | | | +--AverageRateMeterService | | | | | | | | | +--EWMAMeterService | | | | | | | | | +--TokenBucketMeterService | | | | | | | +--MarkerService | | | | | | | | | +--PreambleMarkerService | | | | | | | | | +--TOSMarkerService | | | | | | | | | +--DSCPMarkerService | | | | |
+ - 管理対象要素（CIMCORE）| + - ManagedSystemElement（CIMCORE）| | | + - LogicalElement（CIMCORE）| | | + - サービス（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
+ - 管理対象要素（CIMCORE）| + - ManagedSystemElement（CIMCORE）| | | + - LogicalElement（CIMCORE）| | | + - サービス（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
+ - 管理対象要素（CIMCORE）| + - ManagedSystemElement（CIMCORE）| | | + - LogicalElement（CIMCORE）| | | + - サービス（CIMCORE）| + - コレクション（CIMCORE）| | | + - CollectionOfMSEs（CIMCORE）| | | + - バッファプール| + - SchedulingElement | + - AllocationSchedulingElement | + - WRRSchedulingElement | + - PrioritySchedulingElement | + - BoundedPrioritySchedulingElement
Figure 9. Class Inheritance Hierarchy
図9.クラスの継承階層
The inheritance hierarchy for the associations defined in this document is shown in Figure 10.
この文書で定義されたアソシエーションの継承階層は、図10に示されています。
+--Dependency (CIMCORE) | | | +--ServiceSAPDependency (CIMCORE) | | | | | +--IngressConditioningServiceOnEndpoint | | | | | +--EgressConditioningServiceOnEndpoint | | | +--HeadTailDropQueueBinding | | | +--CalculationBasedOnQueue | | | +--ProvidesServiceToElement (CIMCORE) | | | | | +--ServiceServiceDependency (CIMCORE) | | | | | +--CalculationServiceForDropper | | | +--QueueAllocation | | | +--ClassifierElementUsesFilterList | +--AFRelatedServices | +--NextService | | | +--NextServiceAfterClassifierElement | | | +--NextScheduler | | | +--FailNextScheduler | +--NextServiceAfterMeter | +--QueueToSchedule | +--SchedulingServiceToSchedule
+ - 依存性（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
図10.関連クラス継承階層
The inheritance hierarchy for the aggregations defined in this document is shown in Figure 11.
この文書で定義された集計の継承階層は、図11に示されています。
+--MemberOfCollection (CIMCORE) | | | +--CollectedBufferPool | +--Component (CIMCORE) | | | +--ServiceComponent (CIMCORE) | | | | | +--QoSSubService | | | | | +--QoSConditioningSubService | | | | | +--ClassifierElementInClassifierService | | | +--EntriesInFilterList [PCIME] | +--ElementInSchedulingService
+ - MemberOfCollection（CIMCORE）| | | + - CollectedBufferPool | + - コンポーネント（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関連のクラスは、この文書で定義されています。しかし、CIMコアモデルから、ならびに[PCIME]から引き出された他のクラスは、簡単に説明されています。読者は詳細について[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でクラス全体の継承階層のルートです。依存関係とMemberOfCollection、集合体である：それを参照する団体の中で、このドキュメントでサブクラス化されている2つです。管理対象要素のプロパティは、キャプションと説明しています。どちらも、インスタンス化されたオブジェクトを記述する自由形式の文字列です。このクラスの完全な定義について[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はフィジカルと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のデバイスの状態モデルで直接使用されません。 QoSSubServiceとQoSConditioningSubService：ただし、別のManagedSystemElementに関する凝集成分は、QoSのデバイス状態モデルのコアを形成する2件の集計の基本クラスです。同様に、サービスへのManagedSystemElementに関する関連ProvidesServiceToElementは、モデルのCalculationServiceForDropperアソシエーションの基本クラスです。
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アソシエーションに参加します。このクラスの完全な定義について[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
これは、CIMのコアクラスのサービスの具体的なサブクラスです。これは、トラフィックがデバイスのデータ転送パスに調整される方法を定義する能力を表します。のサブクラス
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.
ConditioningServiceが行われ、コンディショニングの特定のタイプを定義します。コンディショニングの六の基本的なタイプは、この文書で定義されています。これらは、クラシファイア、メーター、マーカー、スポイト、キュー、およびスケジューラによって実行されるサービスです。エアコンの他、より洗練されたタイプは、将来の文書で定義されてもよいです。
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で定義された時点で、そのスーパークラスは、コンクリートだったのでConditioningServiceは具象クラスです。このクラスはインスタンス化することができますが、コンディショニング、およびそれを制御するパラメータの性質は、唯一ConditioningServiceのサブクラスに指定されているため、そのインスタンスは、何を達成しません。
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.
ConditioningServiceの参加は、QoSにおけるその使用に不可欠である、二つの団体 - QoSConditioningSubServiceとNextService。 QoSConditioningSubServiceは、特定のデバイスにそのQoSサービスの基礎となる特定のコンディショニングの機能を説明するために、（例えば、AFのような）特定のQoSサービスにConditioningServicesを集約します。 NextServiceは、異なるトラフィックストリームのための後続の調整サービス（S）を示します。
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)
NAME ConditioningService DESCRIPTIONトラフィックがホストまたはネットワーク装置のデータ転送経路で調節される方法を定義するための具体的なクラス。サービスタイプコンクリートの性質（なし）に由来します
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は、単一の入力ストリームを取り、そして一つ以上の出力ストリームにそれをソート装置の入力または出力インターフェイスの論理エンティティを表す具象クラスです。ソートは、パケットの内容に基づいてパケットを選択するフィルターのセットによって行われ、または可能性パケットに関連した他の属性に基づいています。各出力ストリームは、特定のフィルタに一致した結果です。
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における分類器の表現は[DSMODEL] [DSMIB]に提示さと密接に関連しています。むしろそのFilterListsに直接リンクされているよりも、分類器はClassifierElementsの集合体として、ここでモデル化されています。これらClassifierElementsの各々は、次に、関連ClassifierElementUsesFilterListによって、単一FilterListに連結されています。
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.
分類器は、それが（QoSConditioningSubService集約を使用して）QoSServiceに集約することができるようにConditioningServiceのサブクラスとしてモデル化され、異なるトラフィックストリームのための後続ConditioningServiceオブジェクトを識別するためにNextServiceの関連付けを使用することができます。
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は別のClassifierServiceを指してもよいです。この目的のために使用される場合には、ClassifierElementはClassifierElementUsesFilterListの関連付けを使用することはできません。
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)
NAME ClassifierService DESCRIPTION A入力トラフィックストリームは1つ以上のフィルタを使用して、複数の出力ストリームに分類される方法を説明する具象クラス。 ConditioningServiceのTYPEコンクリートPROPERTIES（なし）に由来します
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に入ってくるパケットのストリームからのパケットを選択するための基準のセット、そして、彼らはClassifierServiceを離れた後、選択されたパケットがどこへ行くか、次ConditioningServiceを指定FilterListの間、単一ClassifierService内、リンクを表しています。 ClassifierElementは、独自のプロパティがありません。その分類子を持つ集約のため、およびそのFilterListとその次のConditioningServiceとの関連についてのアンカーとして機能する存在です。
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がNextServiceAfterClassifierElementアソシエーションを介しClassifierServiceに関連付けられている場合、ClassifierElementはClassifierElementUsesFilterListアソシエーションを使用しなくてもよいです。上記のようにClassifierElementがClassifierServiceに関連付けられている場合、さらに、関連ClassifierServiceの処理の順序はClassifierElementInClassifierService凝集のClassifierOrder性の関数です。たとえば、次を想定することができます：
1. ClassifierService (C1) aggregates ClassifierElements (E1), (E2) and (E3), with relative ClassifierOrder values of 1, 2, and 3.
1. ClassifierService（C1）は、1,2、及び3の相対ClassifierOrder値とClassifierElements（E1）、（E2）および（E3）を、集約します。
2. ClassifierElements (E1) and (E3) associations to FilterLists (F1) and (F3) respectively using the ClassifierElementUsesFilterList association.
それぞれClassifierElementUsesFilterListアソシエーションを使用して2 ClassifierElements（E1）とFilterListsに（E3）アソシエーション（F1）及び（F3）。
3. (E1) & (E3) are associated with Meters (M1) and (M3) through their respective NextServiceAfterClassifierElement associations.
3.（E1）および（E3）は、それぞれNextServiceAfterClassifierElementアソシエーションを介しメートル（M1）および（M3）と関連しています。
4. (E2) is associated with ClassifierService (C2) through its NextServiceAfterClassifierElement association.
4.（E2）は、そのNextServiceAfterClassifierElement会合を通じてClassifierService（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）がFilterLists（F4）及びClassifierElementUsesFilterListアソシエーションを使用して（F5）に関連しています。
In this example, packet processing would match FilterLists in the order of (F1), (F4), (F5), and (F3).
この例では、パケット処理は、（F1）、（F4）、（F5）、及び（F3）の順にFilterListsにマッチします。
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)
分類器は、特定の次コンディショニングサービスに転送するパケットを選択するためのフィルタを使用するプロセスを表す名前ClassifierElement説明A具象クラス。 ClassifierServiceのTYPEコンクリートPROPERTIES（なし）に由来します
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.
これは、ネットワークトラフィックの計量を表し、具体的なクラスです。計量は、トラフィック・ストリームのパケットの到着時間を監視し、予め確立されたトラフィックプロファイルに対する各パケットの適合性のレベルを決定する機能です。メーターは、トラフィックを準拠し、不適合のために異なるConditioningServicesを呼び出す能力を持っています。メータを出るトラフィックは、さらに別のコンディショニングエレメントにパケットをルーティングすることによって（例えば、廃棄またはキューに入れられた）調整することができます。計量の詳細については、[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.
このクラスは、計器の異なるタイプを定義するための基本クラスです。このように、それはすべてメートルのサブクラスが共有する共通のプロパティが含まれています。それは（QoSConditioningSubServiceアソシエーションを使用して）QoSServiceに集約することができるように、その機能がそのQoSサービスの基礎となることを示すために、ConditioningServiceとしてモデル化されます。 MeterServiceは、トラフィックを適合と不適合のための後続ConditioningServiceオブジェクトを識別するために、NextServiceAfterMeter会合に参加します。
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
事前に確立されたトラフィックプロファイルに対してトラフィックのモニタリングを説明NAME MeterService説明A具象クラス。 ConditioningServiceのTYPEコンクリート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プロパティは、クエリの目的や将来の拡張のために定義されています。ないすべてMeterServicesは、それらを定義するためにサブクラスを必要とすることも可能です。これらの場合において、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:
このプロパティは、MeterServiceのインスタンスで表される計器の特定のタイプを指定するために使用される列挙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ビットの符号なし整数です。それはメートルでサポートされている適合レベルの数を示します。唯一の「プロファイルで」「プロファイルのうち、」対計量がサポートされている場合、例えば、ConformanceLevelsは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
NAME AverageRateMeterService DESCRIPTION具象クラス分類トラフィックのいずれかと合致又はパケットの到着が所定の値を超え、平均到着率を引き起こすかどうかに応じて、不適合。 AverageRate、DeltaInterval MeterServiceのTYPEコンクリートの性質から、派生
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ビットの符号なし整数です。値は、毎秒キロビットで指定されています。
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
具象クラス分類は、パケットの到着が小さい固定のサンプリング間隔における平均到着レートが所定の値か否かを超えるさせるかどうかに応じて、適合又は非適合のいずれかとしてトラフィックを認めEWMAMeterService説明名前。 MeterServiceのTYPEコンクリートPROPERTIES AverageRate、DeltaInterval、ゲインから、派生
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ビット整数です。この速度を超えるサンプリングレートを引き起こす任意のパケットは、非準拠とみなされます。値は、毎秒キロビットで指定されています。
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プロパティに対してチェックされます。その計算された平均到着レートが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パラメータバケット計、及び多段メータ - トークンバケットメートルの二つのタイプは、このクラスを使用して定義されています。
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
NAME TokenBucketMeterServiceの説明は、具体的なクラス分類は、トークンバケットに対するトラフィックを認めました。いずれかの適合性の二つまたは三つのレベルを定義することができます。 AverageRate、peakRateは、BurstSize、ExcessBurstSize MeterServiceのTYPEコンクリートの性質から、派生
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ビット整数です。値は、毎秒キロビットで表されます。
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ビット整数です。値は、毎秒キロビットで表されます。
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.
このプロパティは、（AverageRateプロパティで指定）認定速度のために利用可能なトークンの最大数を指定する符号なし32ビット整数です。値はキロバイト単位で表されます。
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.
このプロパティは、（peakRateはプロパティで指定された）ピーク・レートのために利用可能なトークンの最大数を指定する符号なし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.
それはCIMで定義された時点で、そのスーパークラスは、コンクリートだったのでMarkerServiceは具象クラスです。このクラスはインスタンス化することができますが、フィールドの両方をマークすると、それをマークするために使用される値のみ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.
その機能がそのQoSサービスの基礎となることを示すために、（QoSConditioningSubServiceアソシエーションを使用して）QoSServiceに集約することができるようにMarkerServiceはConditioningServiceとしてモデル化されます。それは、マーカーでマークされた後、トラフィックに作用し、後続ConditioningServiceオブジェクトを識別するために、NextService協会に参加しています。
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)
NAME MarkerService DESCRIPTION指定された値を持つパケットに選択されたフィールドをマーキングする一般的なプロセスを表す具象クラス。パケットは、彼らがその後受け取ることをコンディショニングを制御するためにマークされています。 ConditioningServiceのTYPEコンクリートPROPERTIES（なし）に由来します
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
これは、モデルパケットプリアンブルにおけるトラフィックコンディショニング結果の記憶を具象クラスです。どのように、そしてなぜの議論については、セクション3.8.3、QDDIMモデルパケットプリアンブルにこれらの結果を格納する機能を参照してください。のインスタンス
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.
PreambleMarkerServiceは、パケットのプリアンブル形式の二つの部分文字列「<タイプ>、<値>」を追加します。 3.8.3はQDDIMによって定義された<タイプ>文字列のリストを提供します。実装は、これらに加えて、他の<タイプ>のをサポートすることができます。
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[ ]
パケットプリアンブルにおけるトラフィックコンディショニング結果の保存を表す名前PreambleMarkerService説明A具象クラス。 MarkerServiceのTYPEコンクリート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.
このプロパティは、各文字列の形式は、「<タイプ>、<値>」を持っている文字列の順序付きリストです。これらの各タイプのための<タイプ>のQDDIMで定義されている、のリストと関連した<値>の性質については、セクション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
NAME ToSMarkerService説明指定された値を持つIPv4パケットのヘッダ内のサービス（TOS）フィールドのタイプをマーキングするプロセスを表す具象クラス。パケットは、彼らがその後受け取ることをコンディショニングを制御するためにマークされています。 MarkerServiceのTYPEコンクリートの性質から、派生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
NAME DSCPMarkerService DESCRIPTION指定された値を持つパケットのDSCPフィールドをマーキングするプロセスを表す具象クラス。パケットは、彼らがその後受け取ることをコンディショニングを制御するためにマークされています。 MarkerServiceのTYPEコンクリートの性質から、派生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
指定された値を持つ802.1Q準拠のフレームに優先度フィールドをマーキングする過程を表すNAME 8021QMarkerService説明A具象クラス。フレームは、彼らがその後受け取ることをコンディショニングを制御するためにマークされています。 MarkerServiceのTYPEコンクリートの性質から、派生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.
このプロパティは、802.1Qヘッダーに優先順位フィールドをマーキングするために使用される値を表す8ビットの符号なし整数です。プライオリティフィールドは3ビットで構成されているため、このプロパティの値は、範囲0..7に限定されています。 Priorityフィールドがマークされている場合は、そのオクテットの残りのビットは変更されません。
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].
これは、選択的に、ネットワークトラフィックをドロップする、または削除されていないトラフィックのさらなる処理のために別のConditioningServiceを起動する能力を表す具象クラスです。これは、ドロッパー、異なるタイプの基本クラスです。点滴は、彼らはトラフィックをドロップするために使用するアルゴリズムによって区別されます。ドロッパーの様々なタイプの詳細については、[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.
その機能がそのQoSサービスの基礎となることを示すために、（QoSConditioningSubServiceアソシエーションを使用して）QoSServiceに集約することができるようにDropperServiceはConditioningServiceとしてモデル化されます。それは廃棄されていない残りのトラフィックに作用する後続ConditioningServiceオブジェクトを識別するためにNextService会合に参加します。
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はすべてConditioningServicesに適用されるセマンティクス「次の何が起こるか」一般に加えて、点滴のための特別な意味を持っています。特定のドロッパがパケットをドロップし、そこからキュー（複数可）は、それらがキューに到達するまでスポイトから「右」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
ドロッパの共通の特性を記述するNAME DropperService説明A具体的な基底クラス。 DropperType、OtherDropperType、DropFrom ConditioningServiceのTYPEコンクリートの性質から、派生
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]で定義される絶対ドロッパーは「4」（「絶対ドロッパー」）に設定されDropperTypeとDropperServiceクラスのインスタンスとしてモデル化されます。
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 - HeadTail 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)
（2）尾Oヘッド（1）O（0）O不明
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.
DropFromの値は、（不明）「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.
これは、頭や尾のドロッパーのしきい値情報を表し、具体的なクラスです。継承されたプロパティDropFromは、このクラスの特定のインスタンスは、ヘッドスポイト又はテール点滴器を表すかどうかを示しています。
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.
ヘッドドロッパーは常にそれがパケットを廃棄し、そこから同じキューを調べて、このキューは、常にNextService協会では、次のサービスとして、ドロッパーに関連しています。
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
NAME HeadTailDropperService説明A具体的なクラスは、ヘッドまたはテール点滴器を説明するために使用されます。 DropperServiceのTYPEコンクリートの性質から、派生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.
これは、ランダム早期検出（RED）アルゴリズムを使用してネットワークトラフィックをドロップする能力を示し、具体的なクラスです。このアルゴリズムは、[赤]に記載されています。 REDアルゴリズムの目的は、（輻輳の管理ではなく）輻輳を回避することです。代わりに、キューがいっぱいにするのを待って、その後、多数のパケットがドロップする、REDは、平均キュー深度を監視することで動作します。キュー深度が最小しきい値を超えた場合、パケットがランダムに廃棄されます。これらを廃棄するには、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.
REDドロッパーは常にNextService協会では以下のサービスとしてドロッパーに関連している単一のキューからパケットを廃棄します。ドロップアルゴリズムによって調べたキュー（複数可）は、スポイトのDropThresholdCalculationServiceを見つけるためCalculationServiceForDropperの関連付けを、以下、その後、キュー（複数可）を視聴中見つけるためCalculationBasedOnQueueアソシエーション（S）は、以下によって求められます。
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
NAME REDDropperService DESCRIPTION REDアルゴリズムを使用してドロップ記述するために使用される具体的なクラス（またはその変異体の1つ）。 DropperService TYPEコンクリート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があります。 （REDランダムドロップの一種であるが、REDは異なるランダム滴下タイプもある。）REDDropperServiceクラスは、特にREDアルゴリズムに適用される表の列に対応します。
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ビットの符号なし整数です。単位はThresholdUnitsプロパティによって識別されます。ドロップ確率関数の傾きは、スタート/ StopProbability特性によって説明されます。
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ビットの符号なし整数です。単位はThresholdUnitsプロパティによって識別されます。
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）パケット（2）O
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).
注：ThresholdUnitsの値は、これら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.
このプロパティは、千のパケットあたりの滴のドロップ確率を表します。例えば、値100は、100〜1000あたりのパケット、つまり、10％のドロップ確率を示します。最小値と最大値は、1000年に0です。
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.
このプロパティは、千のパケットあたりの滴のドロップ確率を表します。例えば、値100は、100〜1000あたりのパケット、つまり、10％のドロップ確率を示します。最小値と最大値は、1000年に0です。
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.
その機能がそのQoSサービスの基礎となることを示すために、（QoSConditioningSubServiceアソシエーションを使用して）QoSServiceに集約することができるようにQueuingServiceはConditioningServiceとしてモデル化されます。
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
NAME QueuingService DESCRIPTIONは、ネットワークトラフィックをキューイングし、長期輻輳を決定するための特性を指定する能力を説明する具象クラス。 ConditioningServiceのTYPEコンクリート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.
これはこのキューの現在の深さを表す（読み取り専用）ゲージとして機能する32ビット符号なし整数です。この値は、DropThresholdCalculationServiceによって予期しない動作を診断する上で重要であるかもしれません。
This is an unsigned 16-bit integer enumeration that identifies the units for the CurrentQueueDepth property. Defined enumeration values are:
これはCurrentQueueDepthプロパティの単位を識別する符号なし16ビット整数の列挙です。定義された列挙値は次のとおりです。
o bytes(1) o packets(2)
Oバイト（1）パケット（2）O
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
その機能がそのQoSサービスの基礎となることを示すために、（QoSConditioningSubServiceアソシエーションを使用して）QoSServiceに集約することができるようにPacketSchedulingServiceはConditioningServiceとしてモデル化されます。それはに参加します
NextService association to identify the subsequent ConditioningService object, if any, that acts on traffic after it has been processed by the scheduler.
もしあれば、それはスケジューラによって処理された後、後続のConditioningServiceオブジェクトを識別するためのNextService協会は、そのトラフィックに作用します。
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
NAME PacketSchedulingService説明パケットがキューから除去され、出力インターフェイスに送信されるべきときを決定するために使用される具象クラス。 ConditioningServiceのTYPEコンクリート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から継承したもの以外の任意のプロパティを追加しません。しかし、一つの追加協会、FailNextSchedulerに参加しません。
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)
非作業保存方法で動作することが可能なスケジューラを表すNAME NonWorkConservingSchedulingService説明A具象クラス。 PacketSchedulingServiceのTYPEコンクリートPROPERTIES（なし）に由来します
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サービスのさまざまな種類とConditioningServicesの異なる種類の間の関係を統合する方法として機能します。
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、およびパケットのほとんどに与えられたサービスのための1つのインスタンスで表すことができますDiffServServiceのサブクラスであるAFService、の。高い需要DiffServServiceインスタンスは、それが適用されるトラフィックを示すために、一緒に必要な分類を集約するQoSConditioningSubService集約を使用し、契約制限、パケット内のEF PHBをマークするマーカー、およびキューイング関連のコンディショニングに適しメートルうサービスを提供しています。 AFServiceインスタンスは、その分類及びメートル、パケットに異なるAFのPHBをマークするために使用されるいくつかのマーカー、およびパケット処理を実現するために必要なキューイング関連コンディショニングサービスを集約する、QoSConditioningSubService集約を使用します。
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)
NAME QoSService説明QoSサービスを表すために使用されるか、またはネットワーク管理者によって定義されるように、サービスのセット具象クラス。サービスタイプコンクリートの性質（なし）に由来します
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オブジェクトのセットのひとつであってもよいことに注意してください。
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のサブクラスとしてモデル化されます。これはQoSConditioningSubService介しQoSSubServiceを介して、ならびに特定ConditioningServiceオブジェクト（例えば、計量、ドロップ、キューイングなど）に、より高いレベルの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
NAME DiffServService説明A具象クラスは、特定のパーホップの動作に関連付けられたDiffServのサービスを表すために使用されます。 QoSServiceのTYPEコンクリートの性質から、派生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]).
これは、保証転送（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つの異なる処理を表すために、四つの異なるAFクラスを定義します。このようなバッファ空間及び帯域幅のような転送資源の異なる量は、それぞれAFクラスに割り当てられます。各AFクラス内で、IPパケットは、三つの可能なドロップ優先順位値のいずれかでマークされています。輻輳が発生した場合、パケットのドロップ優先順位は、同じ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当たりホップ動作（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クラスは順番にQoSServiceの専門であるDiffServServiceの専門としてモデル化されます。これは、より高いレベルの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
NAME AFService DESCRIPTION AF PHBグループを使用して、トラフィック転送に影響を与えるために使用されている差別化サービスの共通の特徴を説明するための具体的なクラス。 DiffServServiceのTYPEコンクリート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のインスタンスとQoSConditioningSubService集約を使用して集計インスタンスのうち、一つはAFServiceインスタンスのClassNumberのように多くの異なる値を有するマーカーを見つける必要があります。
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クラスごとの数です。対応ドロッパはQoSConditioningSubService凝集と凝集コンディショニングサービスの集合で発見されるであろう。
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.
このクラスは、特定のマイクロフローをサポートするサービスを表します。マイクロフローは、文字列の値を持つプロパティフローIDによって識別されます。いくつかの実装形態では、このクラスのインスタンスは、実装のフローテーブル内のエントリに対応します。
The class definition is as follows:
次のようにクラス定義は次のとおりです。
NAME FlowService DESCRIPTION A concrete class representing a microflow. DERIVED FROM QoSService TYPE Concrete PROPERTIES FlowID
マイクロフローを表す名前FlowService説明A具象クラス。 QoSServiceのTYPEコンクリートの性質から、派生フローID
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.
このクラスは、平滑化体重およびサンプリング時間間隔に基づいて、キューの平均キュー深度を算出する論理エンティティを表します。これは、スポイトがキューの平滑平均キュー深度に基づいてパケットをドロップするかどうかの決定を下すことができるように、REDドロッパーに代わってこの計算を行います。
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
NAME DropThresholdCalculationService DESCRIPTION平滑重量およびサンプリング時間間隔に基づいて、キューの平均キュー深度を算出する論理エンティティを表す具象クラス。後者は、このサービスの性質、それがどのように動作するかを説明し、その必要なパラメータです。サービスタイプコンクリートPROPERTIES SmoothingWeight、時間間隔から、派生
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:
千分の一に指定された - このプロパティは0〜100,000の範囲、32ビットの符号なし整数です。これは、現在の平均キュー深度の計算に影響を与えることで、過去の歴史の重みを定義します。現在のキューの深さの計算は、その因子と、1マイナス歴史的平均の要因としてその逆として、この値の逆数を用います。計算は次の形式をとります。
average = (old_average*(1-inverse of SmoothingWeight)) + (current_queue_depth*inverse of SmoothingWeight)
平均=（old_average * SmoothingWeightの（1-逆））+（SmoothingWeightのcurrent_queue_depth *逆数）
Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2.
実装は、2の累乗として、指定されたセットに値の許容されるセットを制限することを選択することができます。
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ビットの符号なし整数です。このプロパティが指定されていない場合、CalculationServiceは、適切な間隔を決定することができます。
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は、すべてのフィルタエントリのクラスが派生する抽象基本クラスです。これは、グループがフィルタリストにエントリをフィルタリングEntriesInFilterList集約のためのエンドポイントとして機能します。そのプロパティは、CIMプロパティを命名し、IsNegatedブールプロパティ（そのサブクラスの1つのインスタンスで指定されたにも容易に「NOT」試合情報）が含まれます。
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ヘッダフィルタを表現することができます。プロパティIpVersionは、インスタンス内の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によるパケットのプリアンブルに格納されたトラフィックコンディショニング結果を使用してパケットを分類する具象クラスです。どのように、そしてなぜの議論については、セクション3.8.3、QDDIMモデルパケットプリアンブルにこれらの結果を格納する機能を参照してください。 PreambleFilterのインスタンスは、特定の結果を識別する2の部分文字列に基づいてパケットを選択するために使用されます。この試合のためのロジックは、「少なくとも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[ ]
NAME PreambleFilter DESCRIPTION Aは、具象クラスは、パケットのプリアンブルに格納された前のトラフィックコンディショニング結果に基づいてパケットを選択するための基準を表します。 FilterEntryBaseのTYPEコンクリート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.
このプロパティは、各文字列の形式は、「<タイプ>、<値>」を持っている文字列の順序付きリストです。これらの各タイプのための<タイプ>のQDDIMで定義されている、のリストと関連した<値>の性質については、セクション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".
メータ結果を特徴付けるための二つの平行な用語があることに注意してください。列挙値は「（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).
これは、集約EntriesInFilterList介しFilterEntryBase（のサブクラス）のインスタンスを集約する具象クラスです。例えば、（IPHeaderFilterクラスによって表される）は、パケットヘッダのフィルタとセキュリティフィルタ（IPSecで定義FilterEntryBaseのサブクラスによって表される） - 単一FilterListにフィルタの種類を集約することが可能です。
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.
凝集性のEntriesInFilterList.EntrySequenceは常に集約フィルタエントリは、トラフィックのクラスのセレクタを形成するために一緒にAND演算されることを示すために、0に設定されています。
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で使用するバッファの集合を表す具象クラスです。 （関連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.
複数のバッファサイズがある実装では、バッファプールのインスタンスは、同一または類似のサイズのバッファの各セットのために定義されるべきです。バッファー・プールのこれらのインスタンスは、次いでCollectedBuffersPool集約を使用して一緒にグループ化することができます。
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からではなく、転送またはConditioningServiceから派生していることに注意してください。バッファプールは、唯一のストレージの集まりであり、サービスではありません。
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
バッファのコレクションを表すNAMEバッファー・DESCRIPTION A具象クラス。 CollectionOfMSEsのTYPEコンクリートPROPERTIES名、た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.
このプロパティは、現在QueuingServiceの任意のインスタンスに割り当てられていないプール内のバッファの数を報告し、32ビットの符号なし整数です。 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.
このプロパティは、同時にQueuingServiceの複数のインスタンスに割り当てられているプール内のバッファの数を報告し、32ビットの符号なし整数です。
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.
これは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.
このクラスのサブクラスの中で、いくつかは、そのインスタンスのすべての作業節約されるように定義されています。他のサブクラスには、しかし、のいずれかであるか節約動作していないインスタンスを持つことができます。このクラスでは、ブールプロパティWorkConservingはインスタンスであるか、または保存機能していないかどうかを示します。これらのクラスのインスタンスは、作業節約以外に何もすることはできませんので、WorkConservingの値の範囲は、本質的に処理保存されているサブクラスでTRUEに制限されています。
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
PacketSchedulingServiceそれがスケジューリングされている要素の一つのために有していることが、構成情報を表す名前SchedulingElement説明抽象クラス。管理対象要素TYPE抽象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会合によって、このインスタンスに関連付けられた入力を処理しているかどうかを示します。しかし、唯一の非workconservingモードで動作することができ、これらの要素のために - このプロパティは、管理者がSchedulingElementの動作を変更することを示す、書き込み可能であることに留意されたいです。
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.
このクラスは抽象クラスSchedulingElementのサブクラスです。これは、帯域幅ベースのスケジューリングをサポートするために、5つの新しいプロパティが導入されました。キュー、または別のスケジューラのいずれか：SchedulingElementのすべてのサブクラスの場合と同様、AllocationSchedulingElementのインスタンスに関連付けられた入力は、2つのタイプの一つです。
The class definition is as follows:
次のようにクラス定義は次のとおりです。
NAME AllocationSchedulingElement DESCRIPTION A concrete class containing parameters for controlling bandwidth-based scheduling.
NAME AllocationSchedulingElement DESCRIPTION Aは、具体的なクラスは、帯域ベースのスケジューリングを制御するためのパラメータを含みます。
DERIVED FROM SchedulingElement TYPE Concrete PROPERTIES AllocationUnits, BandwidthAllocation, BurstAllocation, CanShare, WorkFlexible
SchedulingElementのTYPEコンクリート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:
このプロパティは、BandwidthAllocationとBurstAllocation特性が発現される単位を識別する16ビットの符号なし整数の列挙です。次の値が定義されています。
o bytes(1) o packets(2) o cells(3) -- fixed-size, for example, ATM
Oバイト（1）細胞（3）Oパケット（2）O - 固定サイズ、例えば、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.
このプロパティは、BandwidthAllocationプロパティを介して割り当てられた帯域幅の量を超えて、入力に割り当てることができる（秒単位で）一時的または短期的な帯域幅の量を指定する32ビットの符号なし整数です。入力のための最大の実際の帯域幅割り当てを測定するならば、それはBurstAllocationとBandwidthAllocation特性の和であろう。単位は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.
これがTRUEの場合、スケジューラによってサービスされる他の入力に割り当てられる関連した入力から未使用の帯域幅を可能にする、ブール特性です。
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.
これが真の場合、この入力に対するスケジューラの挙動が継承プロパティ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（Weighted Round Robin）スケジューリング規律を表す、抽象クラスSchedulingElementのサブクラスです。これは、いくつかの入力に他の入力よりもサービス中のより高い確率を与えるために、新しいプロパティWeightingFactorを紹介します。それはまた、入力が同じ重み係数を有する場合に使用されるタイブレークとして機能するように、プロパティの優先順位を導入します。キュー、または別のスケジューラのいずれか：SchedulingElementのすべてのサブクラスの場合と同様、WRRSchedulingElementのインスタンスに関連付けられた入力は、2つのタイプの一つです。
Because scheduling of this type is always work conserving, the inherited boolean property WorkConserving is restricted to the value TRUE in this class.
このタイプのスケジューリングは常に保全作業されているので、継承されたブール型プロパティWorkConservingは、このクラスでTRUEの値に制限されています。
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
NAME WRRSchedulingElement説明は、このクラスごとの入力の重量を追加するSchedulingElementクラスを専門。これは、それはそれに関連する入力を処理し、重み付けラウンドロビンパケットスケジューラによって使用されています。また、複数の入力が同じ重みを割り当てられている場合にはタイブレーカとして機能する第二のプロパティを追加します。 SchedulingElementのTYPEコンクリートPROPERTIES WeightingFactor、優先順位から、派生
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ビットの符号なし整数です。このプロパティは、この確率を表します。その最小値は、その最大値は100000であり、その単位は千分の一であり、0です。
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.
このクラスは抽象クラスSchedulingElementのサブクラスです。これは、スケジューラは、優先度スケジューリング規律を使用して入力のセットからのパケットを取っていることを示しています。キュー、または別のスケジューラのいずれか：SchedulingElementのすべてのサブクラスの場合と同様、PrioritySchedulingElementのインスタンスに関連付けられた入力は、2つのタイプの一つです。 PrioritySchedulingElementにおけるプロパティ優先順位は、このPrioritySchedulingElementを集約スケジューラが関連付けられている他の全ての入力の優先度に対する入力の優先順位を表します。スケジューラは、他のスケジューリング規律を経由して関連しているへの入力は、この優先順位付けでは把握していません。
Because scheduling of this type is always work conserving, the inherited boolean property WorkConserving is restricted to the value TRUE in this class.
このタイプのスケジューリングは常に保全作業されているので、継承されたブール型プロパティWorkConservingは、このクラスでTRUEの値に制限されています。
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.
NAME PrioritySchedulingElement DESCRIPTION優先プロパティを追加するSchedulingElementクラスを専門とする具象クラス。このプロパティは、入力の組のための優先度スケジューリングを行っているSchedulingServiceで使用されています。
DERIVED FROM SchedulingElement TYPE Concrete PROPERTIES Priority
SchedulingElement TYPEコンクリートPROPERTIES優先順位から、派生
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から派生したクラスPrioritySchedulingElementのサブクラスです。キュー、または別のスケジューラのいずれか：SchedulingElementのすべてのサブクラスの場合と同様、BoundedPrioritySchedulingElementのインスタンスに関連付けられた入力は、2つのタイプの一つです。 BoundedPrioritySchedulingElementは、入力から処理することができますどのくらいのトラフィックに（キロビット毎秒で）上限を追加します。このデータは、その1つの入力に固有のものです。有界完全優先スケジューリングが実行されるときに必要とされています。
This class inherits from its superclass PrioritySchedulingElement the restriction of the inherited boolean property WorkConserving to the value TRUE.
このクラスは、そのスーパークラスから継承TRUE値にWorkConserving継承されたブール型プロパティの制限をPrioritySchedulingElement。
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.
NAME BoundedPrioritySchedulingElement説明この具象クラスはBandwidthBoundプロパティを追加するPrioritySchedulingElementクラスを専門としています。このプロパティは、関連する入力からのトラフィックを処理できる速度を境界。
DERIVED FROM PrioritySchedulingElement TYPE Concrete PROPERTIES BandwidthBound
PrioritySchedulingElementのTYPEコンクリートの性質から、派生BandwidthBound
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つのオブジェクト参照を定義します。依存基準に依存するエンティティを識別しながら、先行参照は、関連して独立したオブジェクトを識別する。
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.
この関連付けは、プロトコル・エンドポイントとそのプロトコル・エンドポイントを介して受信したパケットを処理する第ConditioningService間、入力方向に、関連ServiceSAPDependencyに由来する、との結合を表しています。唯一のプロトコルエンドポイントのための1つの「第一」ConditioningServiceができるので、従属オブジェクト参照の基数は0..1に0..Nから狭められます。一方、単一ConditioningServiceは、複数のプロトコルのエンドポイントを介して受信したパケットを処理する第一とすることができるので、前例オブジェクト参照の基数は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]]
IngressConditioningServiceOnEndpoint説明をプロトコル・エンドポイントとそのプロトコル・エンドポイントを介して到着するトラフィックを処理する第一のコンディショニングサービス間の依存関係を確立アソシエーション名前を付けます。 ServiceSAPDependency ABSTRACT偽の施設から派生前例[審判のProtocolEndpoint [0..N]]、依存[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.
この関連付けは、プロトコルのエンドポイントと、それらがそのプロトコル・エンドポイントを介してネットワーク装置を出る前にパケットを処理する最後ConditioningService間、出力方向に、関連ServiceSAPDependencyに由来する、との結合を表しています。 （この「最後」ConditioningServiceは、通常スケジューラであるが、それは必要はありません。）代替スケジューラの場合のプロトコル・エンドポイントの複数の「最後」ConditioningServicesができるので、従属オブジェクト参照残るためのカーディナリティ0..N。しかし、単一ConditioningServiceは、複数のプロトコルのエンドポイントのためにパケットを処理する最後のことはできないので、前例オブジェクト参照の基数は0..1に0..Nから狭められます。
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]]
そのプロトコルエンドポイントを介して送信されるプロトコルエンドポイントと最後の調整サービス（S）そのプロセスのトラフィック間の依存関係を確立アソシエーションをEgressConditioningServiceOnEndpoint説明名前。 ServiceSAPDependency ABSTRACT偽の施設から派生前例[審判のProtocolEndpoint [0..1]]、依存[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..Nされます。クラスHeadTailDropperとHeadTailDropQueueBindingために、複数のキューからの入力を結合するためのルールは、単純な加算である：監視対象キューの長さの合計は、スポイトのQueueThreshold値を超えると、パケットがドロップされます。入力を結合するためのこの規則は、しかし、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]]
NAME HeadTailDropQueueBindingの説明は、一般的な関連は、頭や尾のドロッパーと、それは監視キュー間の依存関係を確立するために使用されます。依存関係ABSTRACT偽の施設から派生前例[審判QueuingService [1..nの]]、依存[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]]
NAME CalculationBasedOnQueue説明Aは、一般的な関連付けはQueuingServiceオブジェクトとDropThresholdCalculationServiceオブジェクト間の依存関係を確立するために使用されます。 ServiceServiceDependency ABSTRACT偽の施設から派生前例[審判QueuingService [1..1]]、依存[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.
このプロパティは、（代わりに、より一般的な管理対象要素への）DropThresholdCalculationServiceオブジェクトへのオブジェクト参照として機能するように依存関係の関連付けから継承、及びオーバーライドされています。この基準は、平均キュー深度のその計算への入力の一つとして参照されるキューの現在の深さを使用DropThresholdCalculationServiceを識別する。
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つのオブジェクト参照を定義します。依存性の特定のタイプはTypeOfDependencyプロパティによって表されます。典型的な例は、一つのサービスが存在することが必要または他のサービスが動作するために完了していることが必要であることが挙げられます。
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.
この関連付けはServiceSAPDependency関係に非常によく似ています。後者の場合、サービスは他のサービスで取得するためにアクセスポイントに依存しています。この関係では、それが直接そのサービスの依存関係を特定します。自分の情報が繰り返しているので、どちらの関係は、インスタンス化するべきではありません。
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つのオブジェクト参照を定義ServiceServiceDependencyのサブクラスです。
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
NAME CalculationServiceForDropperは、説明は、一般的な関連は、それがServiceServiceDependency ABSTRACT偽施設から派生平均キュー深度計算を行うための計算サービスとREDDropperSrevice間の依存関係を確立するために使用される前例[REF DropThresholdCalculationService [1..nの]、従属[REF REDDropperService [ 0..N]] 4.4.9.1。参考前例
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.
このプロパティは、（代わりに、より一般的なサービスオブジェクトへの）DropThresholdCalculationServiceオブジェクトへのオブジェクト参照として機能するServiceServiceDependency協会から継承、及びオーバーライドされています。オブジェクト参照の基数はRED点滴器は、1つ以上の計算サービスによって配信されてもよいことを示す、1..Nれます。
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.
このプロパティは、（代わりに、より一般的なサービスオブジェクトへの）REDDropperServiceオブジェクトへのオブジェクト参照として機能するServiceServiceDependency協会から継承、及びオーバーライドされています。この参照はDropThresholdCalculationServiceによって提供REDスポイトを識別します。
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、キュー内のパケットのための記憶空間を提供するバッファプール間の依存関係を確立する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
NAME QueueAllocation説明は、一般的な関連付けはQueuingServiceオブジェクトとバッファー・オブジェクト間の依存関係を確立するために使用されます。依存関係ABSTRACT偽PROPERTIES前例[審判バッファプール[0..N]]、依存[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.
このプロパティは、それが参照QueuingServiceに割り当てられるべきバッファプールの割合を規定するゼロの最小値100の最大値は8ビットの符号なし整数です。絶対的な大きさが所望される場合、これは100に設定QueueAllocation.AllocationPercentagesと、指定されたサイズの個々のバッファー・プールを定義することによって達成されます。
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.
この関連付けは、依存関係協会のサブクラスです。これは、プロセスにClassifierElementsの各々のパケットを選択するための基準を表すFilterList 1つまたはそれ以上のClassifierElementsに関する。
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のセットを集約ClassifierServiceとしてモデル化されます。 ClassifierElementsは（階層分類器を構築するために）別のClassifierServiceに結合することNextServiceAfterClassifierElementアソシエーションを使用する場合、ClassifierElementUsesFilterListアソシエーションを指定してはなりません。
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]]
NAME ClassifierElementUsesFilterList説明処理することClassifierElementのパケットを選択するための基準を表すFilterListにClassifierElementを関連付ける関連付け。依存関係ABSTRACTから派生して偽PROPERTIES前例[審判FilterList [0..1]]、依存[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.
このプロパティは、依存協会から継承され、その代わりに、より一般的な管理対象要素オブジェクトに、FilterListオブジェクトへのオブジェクト参照として機能するように無視されます。また、その基数がClassifierElement一それのためのパケットを選択するFilterList又はClassifierElementが階層分類器を形成する別のClassifierServiceに結合することNextServiceAfterClassifierElementアソシエーションを使用しないFilterListのいずれかを使用することを示し、0および1に制限されます。
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.
このプロパティは、依存協会から継承され、その代わりに、より一般的な管理対象要素オブジェクトに、ClassifierElementオブジェクトへのオブジェクト参照として機能するように無視されます。この参考文献は、そのパケットの選択基準を表す関連FilterListオブジェクトに依存ClassifierElementを識別する。
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]]
NAME AFRelatedServices説明アソシエーションは、二つAFServiceオブジェクト間の依存関係を確立するために使用されます。何もABSTRACT偽の施設から派生AFLowerDropPrecedence [参照AFService [0..1]]、AFHigherDropPrecedence [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.
この関連付けは、二つConditioningServiceオブジェクト間先行-後継関係を確立する2つのオブジェクト参照を定義します。この関連付けは、特定のタイプのトラフィックを処理するのに必要なConditioningServicesの配列を示すために使用されます。
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.
この依存関係のインスタンスは、トラフィックを調整するために集合的に使用されている（例えば等クラシファイア、メーター、点滴など）異なるConditioningServices間の様々な関係を記述する。どちらも1対1、より複雑なファンインおよび/またはファンアウト関係記述することができます。 ConditioningServicesは互いに直接に供給することができる、またはそれらはパケットの特性に基づいて、複数の「次の」サービスにマッピングすることができます。
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]]
NAME NextServiceの説明アソシエーションは、二つConditioningServiceオブジェクト間先行-後継関係を確立するために使用されます。何もABSTRACT偽の施設から派生PrecedingService [参照ConditioningService [0..N]]、FollowingService [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.
このプロパティは、トラフィックの指定された型の処理シーケンスにおける以前に発生ConditioningServiceオブジェクトへのオブジェクト参照として機能します。
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.
このプロパティは、直ちにPrecedingServiceオブジェクト参照によって識別ConditioningService後、トラフィックの指定された型の処理手順の後半で発生ConditioningServiceオブジェクトへのオブジェクト参照として機能します。
This association refines the definition of its superclass, the NextService association, in two ways:
この関連付けは、2つの方法で、そのスーパークラス、NextService協会の定義を洗練します：
o It restricts the PrecedingService object reference to the class ClassifierElement.
OそれはクラスClassifierElementにPrecedingServiceオブジェクト参照を制限します。
o It restricts the cardinality of the FollowingService object reference to exactly 1.
Oそれは、正確に1にFollowingServiceオブジェクト参照の基数を制限します。
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.
NAME NextServiceAfterClassifierElement説明アソシエーションは、分類内の単一ClassifierElementそのClassifierElementによって選択されたトラフィックの更なる処理のために責任がある次ConditioningServiceオブジェクト間先行-後継関係を確立するために使用されます。
DERIVED FROM NextService ABSTRACT False PROPERTIES PrecedingService [ref ClassifierElement[0..n]], FollowingService [ref ConditioningService[1..1]
NextService ABSTRACT偽の施設から派生PrecedingService [参照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.
このプロパティはNextService協会から継承されます。 NextServiceスーパークラスで定義された、より一般的なConditioningServiceとは対照的に、ClassifierElementへのオブジェクト参照を制限するために、このサブクラスにオーバーライドされます。
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.
このプロパティは、単一ClassifierServiceの構成要素であるClassifierElement、オブジェクト参照として機能します。このClassifierElementによって選択されたパケットは、常にFollowingServiceオブジェクト参照によって識別されるConditioningServiceに渡されます。
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.
このプロパティはNextService協会から継承されます。与えられたClassifierServiceで与えられたClassifierElementによって選択されたパケットは、常に1つだけに行く必要があります。DiffServの分類器の動作は決定論的でなければならないという要件を反映して、正確に1を参照の基数を制限するために、このサブクラスでオーバーライドされます1次ConditioningService。
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のスケジューラは、単一の集約入力として第1のスケジューラの出力を処理する階層的キューイング構成では、二つのスケジューラはNextSchedulerアソシエーションを介して関連しています。
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
NAME NextSchedulerの説明会では、単純な階層的なスケジューリングのためPacketSchedulingServiceオブジェクト間の前身、後継関係を確立するために使用されます。 NextService ABSTRACT falseから派生
PROPERTIES PrecedingService[ref PacketSchedulingService[0..n]], FollowingService[ref PacketSchedulingService[0..1]]
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.
このプロパティは、（代わりに、より一般的なConditioningServiceオブジェクトへの）PacketSchedulingServiceオブジェクトへのオブジェクト参照として機能するNextService協会から継承、及びオーバーライドされています。この参考文献は、その出力FollowingService基準によって識別スケジューラによって単一の集約入力として処理されているスケジューラを識別する。 [0..N]基数は、単一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.
このプロパティは、（代わりに、より一般的なConditioningServiceオブジェクトへの）PacketSchedulingServiceオブジェクトへのオブジェクト参照として機能するNextService協会から継承、及びオーバーライドされています。この参考文献は、その入力の一つ以上のPrecedingServiceスケジューラの集約出力のうち含むスケジューラを識別する。
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協会のサブクラスです。第1のスケジューラは、（それによって非作業保存方法で振る舞う）スケジューリング機会を渡し、その使用のための第2のスケジューラに得られた帯域幅を利用可能にする場合FailNextSchedulerは、二つのスケジューラとの関係を示します。セクションにこの関連付けが使用されるかもしれない場所の例については、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
この関連付けはNextSchedulerアソシエーションを専門FailNextScheduler説明名前。これは、非作業保存スケジューラと、それは使用しないことを選択した帯域幅を利用できるようにするための第2のスケジューラとの間の関係を確立します。 NextScheduler ABSTRACT falseから派生
PROPERTIES PrecedingService[ref NonWorkConservingSchedulingService[0..n]]
PROPERTIES PrecedingService [参照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.
このプロパティは、（代わりに、より一般的なPacketSchedulingServiceオブジェクトへの）NonWorkConservingSchedulingServiceオブジェクトへのオブジェクト参照として機能するNextScheduler協会から継承、及びオーバーライドされています。この参考文献は、その余剰帯域FollowingService参照によって同定スケジューラに利用可能にされている非作業保存スケジューラを識別する。 [0..N]基数は、単一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.
この関連付けはMeterServiceおよび1またはプロセスメートルからのトラフィックよりConditioningServiceオブジェクト間の前身、後継関係を説明しています。例えば、プリアンブルマーキングを実装するデバイスのために、（メータ後）FollowingService参照は、プリアンブルに計量の結果を記録するために、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協会が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
NAME NextServiceAfterMeter説明は関連はMeterServiceの特定の出力及びトラフィックのさらなる処理のために責任がある次ConditioningServiceオブジェクト間先行-後継関係を確立するために使用されます。何もABSTRACT falseから派生
PROPERTIES PrecedingService[ref MeterService[0..n]], FollowingService[ref ConditioningService[0..n]], MeterResult
PROPERTIES PrecedingService [REFメーターサービス[0..N]]、FollowingService [REF conditio寧サービス[0..N]]、立っ結果
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.
先行MeterService、パケットの処理シーケンスの「以前」。メーターは1であるので：Nファンアウト装置、この関係は、さらにトラフィックを処理するために使用される次ConditioningServiceに（MeterResultプロパティによって識別される）MeterServiceの特定の出力を関連付けます。
The 'next' or following ConditioningService.
「次へ」または以下の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）、 "PartiallyConforming"（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）とSchedulingElementとの関係を示す、トップレベルの会合です。 SchedulingElementは、今度は、そのような相対的な優先順位または割り当てられた帯域幅として、このキューに特異的であるパケットスケジューリングサービスの情報を表します。
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.
これは、協会のカーディナリティを正式に表現することはできませんが、この協会への参加に関する追加の制約があります。 SchedulingElement（のサブクラス）の特定のインスタンスは、常にこのアソシエーションのうちの正確に1つのインスタンスで、または会合SchedulingServiceToScheduleの正確に一つのインスタンスのいずれかに参加しています。
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]]
NAME QueueToSchedule説明この関連付けは、キューに固有の情報を含むSchedulingElementにキューに関する。何もABSTRACT偽の施設から派生キュー[参照QueuingService [0..1]]、SchedElement [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以上の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).
このプロパティは、SchedulingElementオブジェクトへのオブジェクト参照として機能します。 SchedulingElementは、常に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）とSchedulingElementとの関係を示す、トップレベルの会合です。 SchedulingElementは、今度は、そのような相対的な優先順位または割り当てられた帯域幅として、このスケジューラに特異的であり、後続のパケットスケジューリングサービスの情報を表します。
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.
これは、協会のカーディナリティを正式に表現することはできませんが、この協会への参加に関する追加の制約があります。 SchedulingElement（のサブクラス）の特定のインスタンスは、常にこのアソシエーションのうちの正確に1つのインスタンスで、または会合QueueToScheduleの正確に一つのインスタンスのいずれかに参加しています。
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.
NAME SchedulingServiceToSchedule説明は、この関連は、このスケジューラに固有の情報を含む後続のスケジューラにSchedulingElementのスケジューラに関する。
DERIVED FROM Nothing ABSTRACT False PROPERTIES SchedService[ref PacketSchedulingService[0..1]], SchedElement[ref SchedulingElement[0..n]]
何もABSTRACT偽の施設から派生SchedService [参照PacketSchedulingService [0..1]]、SchedElement [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).
このプロパティは、SchedulingElementオブジェクトへのオブジェクト参照として機能します。 SchedulingElementは、常に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.
この凝集は一般CollectionオブジェクトにManagedElementsのセットの凝集をモデル化するために使用される一般的な関係です。集合の基数は、多くの多くのです。
MemberOfCollection is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
MemberOfCollectionは、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.
この凝集はモデル今度は「高レベル」バッファー・プールに含めることができるプール、または集合としてバッファのセットを治療する能力を。このクラスは、バッファー・クラスのインスタンスであると凝集と一部コンポーネントオブジェクトの両方を制限するより一般的なMemberOfCollection凝集を上書き。
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]]
NAME CollectedBufferPool説明は、一般的な会合は、より高いレベルのバッファ・プールに関連するバッファのセットを集約するために使用されます。 MemberOfCollection ABSTRACT偽PROPERTIESコレクション[REFバッファプール[0..1]]、メンバー由来の[バッファプール[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.
この抽象集約は、「パートの」（GroupComponentとPartComponentという名前の）管理対象オブジェクト間の関係を確立するために使用される一般的な関係です。協会の基数は、多くの多くのです。
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).
この凝集はQoSServiceオブジェクトに、代わりに、より汎用的なサービスオブジェクトのこの関係に参加できるオブジェクトの種類を制限するために、より一般的なServiceComponentスーパークラスから派生しています。それはまた、0または1に凝集のカーディナリティを制限する（代わりに、より一般的な0-OR-以上）。
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]]
NAME QoSSubServiceは、説明は、一般的な関連付けは、「パートの」上位QoSServiceオブジェクト及び/作成し、それを形成するために集計され、下位レベルのQoSServicesのセットとの間の関係を確立するために使用されます。 ServiceComponent ABSTRACT偽の施設から派生GroupComponent [参照QoSService [0..1]]、PartComponent [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.
この凝集は、より一般的なServiceComponentスーパークラスから派生しています。その代わりに、より汎用的なサービスオブジェクトの、ConditioningServiceと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
NAME QoSConditioningSubServiceは、説明は、一般的な凝集は、「パートの」ConditioningServiceオブジェクトのセットとそれらがのトラフィックコンディショニングを提供する特定のQoSServiceオブジェクト（複数可）との間の関係を確立するために使用されます。 ServiceComponent ABSTRACT falseから派生
PROPERTIES GroupComponent[ref QoSService[0..n]], PartComponent[ref ConditioningService[0..n]]
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オブジェクトへのオブジェクト参照を表すためにこの集合でオーバーライドされます。参照の基数は、与えられたConditioningServiceは、0,1、又は1以上QoSServiceオブジェクトのトラフィックコンディショニングを提供し得ることを示すために、0..N残ります。
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つまたは複数のConditioningServiceオブジェクトを集約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.
このプロパティは、（代わりに、そのスーパークラスで定義されたより一般的なサービスオブジェクトへの）ConditioningServiceオブジェクトへのオブジェクト参照を表すためにこの集合でオーバーライドされます。このオブジェクトは、関係の子、または「コンポーネント」、オブジェクトを表します。この場合、このオブジェクトは、一緒に特定QoSServiceのトラフィックが調整される方法を示す1つのまたは複数のConditioningServiceオブジェクトを表します。
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
ClassifierElementInClassifierService説明をクラシファイアとクラシファイア要素間の関係を表す集合に名前を付けます。 ServiceComponent ABSTRACT falseから派生
PROPERTIES GroupComponent[ref ClassifierService[1..1]], PartComponent[ref ClassifierElement[0..n], ClassifierOrder
PROPERTIES ClassifierElement [0..N]、ClassifierOrder REF GroupComponent [REF ClassifierService [1..1]、PartComponent [
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.
このプロパティは、（代わりに、そのスーパークラスで定義されたより一般的なサービスオブジェクトへの）ClassifierServiceオブジェクトへのオブジェクト参照を表すためにこの集合でオーバーライドされます。また、1..1に凝集体のカーディナリティを制限する（代わりに、より一般的な0-OR-以上）、ClassifierElementは常に正確に一つClassifierServiceのコンテキスト内に存在することを表します。
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オブジェクトへのオブジェクト参照を表すためにこの集合でオーバーライドされます。このオブジェクトは、分類器のための単一のトラフィックセレクタを表します。 ClassifierElementは通常分類器に入ってくるトラフィックストリームから、これらの基準によって選択されたパケットするConditioningServiceへのパケットの選択基準を提供FilterListの関連は次の転送されています。
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.
分類器のためのフィルタが重複することができるので、ClassifierServiceによって凝集ClassifierElementsパケットが分類器に入ってくるが提示される順序を指定する必要があります。このプロパティは、この順序を表す符号なし32ビット整数です。ように、次に「2」「1」の最初の、そして：値が昇順に表されています。異なる値は、所与のClassifierServiceによって集約ClassifierElementsのそれぞれに対して割り当てなければなりません。
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.
この凝集は部品集合体の専門です。 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.
凝集自体のカーディナリティはFilterList端部に0..1であり、FilterEntryBase端に0..N。従って一般的な場合において、フィルタエントリは、任意のFilterListに集約されずに存在することができます。しかし、フィルタエントリは、QoSデバイスモデルに把握することができる唯一の方法は、この凝集によりFilterListに集約されることです。
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、その入力にそれを結ぶSchedulingElementsのセットとの間の関係を表します。
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]
NAME ElementInSchedulingService説明素子（QueuingServiceまたは別のPacketSchedulingServiceいずれか）がスケジュールそれのいずれかの構成情報をPacketSchedlingServiceを結びつけるために使用される集約。コンポーネントABSTRACT偽の施設から派生GroupComponent [参照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-OR-以上）、SchedulingElementは最大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.
このプロパティは、（代わりに、そのスーパークラスで定義されたより一般的なサービスオブジェクトへの）SchedulingElementオブジェクトへのオブジェクト参照を表すためにこの集合でオーバーライドされます。このオブジェクトは、スケジューラのための単一のスケジューリング要素を表します。また1..NするSchedulingElementのカーディナリティを制限する（代わりに、より一般的な0-OR-以上）、PacketSchedulingServiceは常に少なくとも一つSchedulingElementを含むことを表します。
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]を参照してください。モデル内の特定のオブジェクトのセキュリティへの影響の議論のために、（実際にQDDIM情報モデルとかなりの程度に対応するデータモデルである）[DSMIB]も参照。
[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。分散管理タスクフォース株式会社、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]ムーア、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]ムーア、B.、エド。、 "方針コア情報モデル（PCIM）拡張機能"、RFC 3460、2003年1月。
[R791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[R791]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "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.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、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]黒、D.、つば、S.、大工、B.およびF.ル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]ベイカー、F.、チャン、K.とA.スミス、 "差別化サービスアーキテクチャのための管理情報ベース"、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.、ブレイク、S.、グロスマン、D.とA.スミス、 "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]チャン、K.、Sahita、R.、ハーン、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.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、および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.、コーエン、R.とB.ムーア、 "ポリシーサービスの品質（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]ブレーデン、R.、クラーク、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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]デイビー、B.、Charny、A.、ベネット、JCR、ベンソン、K.、ルBoudec、JY、コートニー、W.、Davari、S.、Firoiu、V.およびD. Stiliadis、「緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[RED] See http://www.aciri.org/floyd/red.html
[RED]を参照してください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クラスのサービスから派生しています。サービスは抽象クラスですが、それにもかかわらず、主要なプロパティはその定義の一部として含まれています。抽象クラスにキープロパティを含める目的は同じように名前のそのインスタンス化サブクラスのすべてのインスタンスを持つことです。したがって、このモデル内のクラスの大半は、まったく同じようにそのインスタンスに名前を付ける：二つの重要な特性のCreationClassNameとNameで、彼らがサービスを継承していること。
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.
サービスのように、（[PCIME]で定義される）FilterEntryBaseは、その定義において重要な特性を含む抽象クラスです。 FilterEntryBaseは4つの重要な特性を持っています。彼ら二人は、SystemCreationClassNameとのSystemNameは、弱い関連FilterEntryInSystemを経由して、それに伝播されます。他の2、のCreationClassNameとNameは、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.
したがって、ここで定義されPreambleFilterクラスを含むFilterEntryBaseのサブクラスのすべてのインスタンスが同じように命名されている：彼らはFilterEntryBaseから継承する4つの重要な特性を持ちます。
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.
クラスのProtocolEndpointは、そのスーパークラス、ServiceAccessPointからそのキーのプロパティを継承します。 2はキープロパティSystemCreationClassNameとSystemNameを、プラス2つのネイティブキーのプロパティのCreationClassNameとNameを伝播：これらのキーのプロパティは、前に私たちが見てきた同じ命名構造を提供します。
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.
このモデルでは他のクラスとは異なり、バッファプールは、サービスから派生されていません。したがって、サービスからそのキーのプロパティを継承しません。代わりに、それは、そのスーパークラスのコレクションから、そのキーのプロパティの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文字の最大長さの文字列プロパティです。これは、バッファー・プールを識別します。このプロパティは、バッファー・クラスのスーパークラスでは、CollectionOfMSEsはなく、キープロパティとして定義されていることに注意してください。それ、このクラスの複合キーの一部にするために、バッファプールでオーバーライドされます。
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文字の最大長の文字列プロパティです。このクラスは直接インスタンス化されるかどうかは、「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命名性質を持っていません。通常のパターンが続いている場合は、しかし、インスタンスは二つの性質のCreationClassNameとNameで命名されます。
Bob Moore P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
ボブ・ムーアP. O.ボックス12195、BRQA / B501 / G206 3039コーンウォリスRdを。リサーチトライアングルパーク、NC 27709-2195
Phone: (919) 254-4436 EMail: remoore@us.ibm.com
電話：（919）254-4436 Eメール：remoore@us.ibm.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
デビッド・ダーラムインテル2111 NE 25日アベニューヒルズボロ、OR 97124
Phone: (503) 264-6232 EMail: david.durham@intel.com
電話：（503）264-6232 Eメール：david.durham@intel.com
John Strassner INTELLIDEN, Inc. 90 South Cascade Avenue Colorado Springs, CO 80903
ジョンStrassner INTELLIDEN社90南カスケード・アベニューコロラドスプリングス、CO 80903
Phone: (719) 785-0648 EMail: john.strassner@intelliden.com
電話：（719）785-0648 Eメール：john.strassner@intelliden.com
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
アンドレアWesterinenシスコシステムズ、ビル20 725アルダードライブミルピタス、CA 95035
EMail: andreaw@cisco.com
メールアドレス：andreaw@cisco.com
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH 03054
ウォルター・ワイスEllacoya Networksの7ヘンリー・クレイ博士メリマック、NH 03054
Phone: (603) 879-7364 EMail: walterweiss@attbi.com
電話：（603）879-7364 Eメール：walterweiss@attbi.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。