RFC3670 日本語訳
3670 Information Model for Describing Network Device QoS DatapathMechanisms. B. Moore, D. Durham, J. Strassner, A. Westerinen, W.Weiss. January 2004. (Format: TXT=221687 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループB.ムーア要求をネットワークでつないでください: 3670年のIBM社のカテゴリ: 標準化過程D.ダラムインテルJ.Strassner INTELLIDEN Inc.A.WesterinenシスコシステムズW.ワイスEllacoya2004年1月
Information Model for Describing
Network Device QoS Datapath Mechanisms
ネットワーク装置QoS Datapathメカニズムについて説明するための情報モデル
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services.
このドキュメントの目的は異なったネットワーク装置の固有であるサービスの質(QoS)メカニズムについて説明するために情報モデルを定義することです、ホストを含んでいて。 概して、これらのメカニズムはネットワーク装置の推進経路(datapath)を通した交通を選択して、条件とさせるのに共通の特性について説明します。 datapathの交通のこの選択と調節は両方の主要なQoS構造にかかっています: 微分されたサービスと統合サービス。
This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.
このドキュメントは、装置のQoSメカニズム(すなわち、機能性をマークして、計量して、落として、列に並ばせて、計画をする分類)を管理して、構成するためにどう方針を定義できるかをモデル化するのにQoS Policy情報Model(QPIM)と共に使用されるべきです。 これらの2通のドキュメントが装置のdatapathsの現在のQoSメカニズムを構成して、管理するためにQoSに政策ルールを書く方法を一緒に、説明します。
Moore, et al. Standards Track [Page 1] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 政策管理の概念モデル. . . . . . . . . . . 6 1.2。 他の方針との目的と関係は働いています。 . . . . . . . 7 1.3. 方針用法. . . . . . . . . . . . 7 2の典型的な例。 .82.1にアプローチしてください。 DiffServとIntServ. . . . . . . . . . 8 2.2の共通の要求。 DiffServ. . . . . . . . . . . . . . . 9 2.3の特定の必要性。 IntServの特定の必要性。 . . . . . . . . . . . . . . . 9 3. 方法論。 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. QoS方針. . . . 10 3.2を言い表すための抽象化のレベル。 方針パラメタ. . . . . . . . . . . . . . 11 3.3を指定します。 方針サービス. . . . . . . . . . . . . . . 12 3.4を指定します。 QoS属性とクラスを定義するための抽象化のレベル。 . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. QoSの特性. . . . . . . . . . . 14 3.6の特殊化。 QoS情報モデル派生. . . . . . . . . . . . 15 3.7。 表現. . . . . . . . . . . . . . . . 16 3.8を結果と考えてください。 メンタル・モデル. . . . . . . . . . . . . . . . . . . . . . 17 3.8.1。 QoSServiceのクラス. . . . . . . . . . . . . . 17 3.8.2。 ConditioningServiceのクラス。 . . . . . . . . . 18 3.8.3. イングレスから出口. . . . . . . . . . . . . . . . . . . . . 19 3.9までQoS情報を保存します。 クラシファイア(FilterLists)とフィルタエントリー. . . . . . 21 3.10。 点滴器. . . . . . . . . . . . . . . . . . 23 3.10.1のモデル。 ヘッドとテール点滴器. . . . . . . 23 3.10.2を構成します。 赤い点滴器. . . . . . . . . . . . 24 3.11を構成します。 待ち行列とスケジューラのモデル。 . . . . . . . . . . . 25 3.11.1. 簡単な階層的なスケジューラ。 . . . . . . . . . 25 3.11.2. 複雑な階層的なスケジューラ. . . . . . . . . 27 3.11.3。 過剰生産能力スケジューラ。 . . . . . . . . . . . 29 3.11.4. 階層的なCBQスケジューラ. . . . . . . . . . . 31 4。 クラス階層構造。 . . . . . . . . . . . . . . . . . . . . . 33 4.1. 協会と集合。 . . . . . . . . . . . . . 33 4.2. クラス階層構造. . . . . . . . . 34 4.3の構造。 クラス定義。 . . . . . . . . . . . . . . . . . . . 38 4.3.1. 抽象クラスManagedElement。 . . . . . . . 38 4.3.2. 抽象クラスManagedSystemElement。 . . . . 39 4.3.3. 抽象クラスLogicalElement。 . . . . . . . 39 4.3.4. 抽象クラスサービス. . . . . . . . . . . 39 4.3.5。 クラスConditioningService。 . . . . . . . . . 39 4.3.6. クラスClassifierService。 . . . . . . . . . . 40 4.3.7. クラスClassifierElement。 . . . . . . . . . . 41
Moore, et al. Standards Track [Page 2] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[2ページ]。
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.3.8. クラスMeterService. . . . . . . . . . . . . 42 4.3.9。 クラスAverageRateMeterService。 . . . . . . . 44 4.3.10. クラスEWMAMeterService. . . . . . . . . . . 44 4.3.11。 クラスTokenBucketMeterService。 . . . . . . . 46 4.3.12. クラスMarkerService。 . . . . . . . . . . . . 47 4.3.13. クラスPreambleMarkerService。 . . . . . . . . 47 4.3.14. クラスToSMarkerService. . . . . . . . . . . 48 4.3.15。 クラスDSCPMarkerService。 . . . . . . . . . . 49 4.3.16. クラス8021QMarkerService. . . . . . . . . . 49 4.3.17。 クラスDropperService. . . . . . . . . . . . 50 4.3.18。 クラスHeadTailDropperService. . . . . . . . 52 4.3.19。 クラスREDDropperService。 . . . . . . . . . . 52 4.3.20. クラスQueuingService. . . . . . . . . . . . 54 4.3.21。 クラスPacketSchedulingService。 . . . . . . . 55 4.3.22. クラスNonWorkConservingSchedulingService. . 56 4.3.23。 クラスQoSService. . . . . . . . . . . . . . 57 4.3.24。 クラスDiffServService。 . . . . . . . . . . . 58 4.3.25. クラスAFService。 . . . . . . . . . . . . . . 59 4.3.26. クラスFlowService。 . . . . . . . . . . . . . 60 4.3.27. クラスDropThresholdCalculationService。 . . . 60 4.3.28. 抽象クラスFilterEntryBase. . . . . . . 61 4.3.29。 クラスIPHeaderFilter. . . . . . . . . . . . 62 4.3.30。 クラス8021Filter. . . . . . . . . . . . . . 62 4.3.31。 クラスPreambleFilter. . . . . . . . . . . . 62 4.3.32。 クラスFilterList. . . . . . . . . . . . . . 63 4.3.33。 抽象クラスServiceAccessPoint。 . . . . . 63 4.3.34. クラスProtocolEndpoint. . . . . . . . . . . 63 4.3.35。 抽象クラス収集。 . . . . . . . . . 65 4.3.36. 抽象クラスCollectionOfMSEs。 . . . . . . 65 4.3.37. クラスBufferPool. . . . . . . . . . . . . . 65 4.3.38。 抽象クラスSchedulingElement. . . . . . 65 4.3.39。 クラスAllocationSchedulingElement。 . . . . . 66 4.3.40. クラスWRRSchedulingElement. . . . . . . . . 67 4.3.41。 クラスPrioritySchedulingElement。 . . . . . . 69 4.3.42. クラスBoundedPrioritySchedulingElement. . . 70 4.4。 協会定義。 . . . . . . . . . . . . . . . . 70 4.4.1. 抽象的な協会の依存。 . . . . . . 71 4.4.2. 協会ServiceSAPDependency. . . . . . 71 4.4.3。 協会IngressConditioningServiceOnEndpoint. . . . . . 71 4.4.4。 協会EgressConditioningServiceOnEndpoint。 . . . . . . 72 4.4.5. 協会HeadTailDropQueueBinding. . . . 72 4.4.6。 協会CalculationBasedOnQueue。 . . . . 73 4.4.7. 協会ProvidesServiceToElement. . . . 74 4.4.8。 協会ServiceServiceDependency. . . . 74 4.4.9。 協会CalculationServiceForDropper. . 75 4.4.10。 協会QueueAllocation。 . . . . . . . . 75
Moore, et al. Standards Track [Page 3] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[3ページ]。
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
4.4.11. 協会ClassifierElementUsesFilterList。 76 4.4.12. 協会AFRelatedServices。 . . . . . . . 77 4.4.13. 協会NextService。 . . . . . . . . . . 78 4.4.14. 協会NextServiceAfterClassifierElement。 . . . . . . . 79 4.4.15. 協会NextScheduler。 . . . . . . . . . 80 4.4.16. 協会FailNextScheduler。 . . . . . . . 81 4.4.17. 協会NextServiceAfterMeter。 . . . . . 82 4.4.18. 協会QueueToSchedule。 . . . . . . . . 83 4.4.19. 協会SchedulingServiceToSchedule。 . . 84 4.4.20. 集合MemberOfCollection. . . . . . . 85 4.4.21。 集合CollectedBufferPool。 . . . . . . 85 4.4.22. 抽象的な集合成分. . . . . . . 86 4.4.23。 集合ServiceComponent. . . . . . . . 86 4.4.24。 集合QoSSubService。 . . . . . . . . . 86 4.4.25. 集合QoSConditioningSubService。 . . . 87 4.4.26. 集合ClassifierElementInClassifierService. . . . . . 88 4.4.27。 集合EntriesInFilterList。 . . . . . . 89 4.4.28. 集合ElementInSchedulingService. . . 90 5。 知的所有権声明。 . . . . . . . . . . . . . . . 91 6. 承認. . . . . . . . . . . . . . . . . . . . . . . 91 7。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 91 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 92 8.1。 引用規格。 . . . . . . . . . . . . . . . . . . 92 8.2. 有益な参照. . . . . . . . . . . . . . . . . 92 9。 付録A: 固有のCIMにおける例を実現. 94 9.1と命名します。 サービスから得られたクラスの例を命名します。 . . 94 9.2. FilterEntryBase. . . . 94 9.3のサブクラスの例を命名します。 ProtocolEndpointの例を命名します。 . . . . . . . . . . 94 9.4. BufferPoolの例を命名します。 . . . . . . . . . . . . . 95 9.4.1. 特性のCollectionID。 . . . . . . . . . . . 95 9.4.2. 特性CreationClassName. . . . . . . . . 95 9.5。 SchedulingElement. . . . . . . . . . 95 10の例を命名します。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 96 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 97
1. Introduction
1. 序論
The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services (see [R2475]) and Integrated Services (see [R1633]).
このドキュメントの目的は異なったネットワーク装置の固有であるサービスの質(QoS)メカニズムについて説明するために情報モデルを定義することです、ホストを含んでいて。 概して、これらのメカニズムはネットワーク装置の推進経路(datapath)を通した交通を選択して、条件とさせるのに共通の属性について説明します。 datapathの交通のこの選択と調節は両方の主要なQoS構造にかかっています: 微分されたサービス([R2475]を見る)と統合サービス([R1633]を見ます)。
Moore, et al. Standards Track [Page 4] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[4ページ]。
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 Policy情報Model[QPIM]と共にこのドキュメントが使用されることを意図します。 これらの2通のドキュメントが装置のdatapathsの現在の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.
本書では取られたアプローチは装置datapathでQoSをモデル化するのに使用できる一般的なセットのクラスを定義します。 次に、直接これらのクラスを写像できるか、または介入している形式を使用している業者がそれら自身の装置特有の実現にCOP-PR PIBが好きです。 Integrated Servicesの入場制御要素がこのモデルの範囲に含まれていないことに注意してください。
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)によって定義されたNetwork QoS submodelによって本書では影響を及ぼされます--[CIM]を見てください。 これらの階層構造はPolicy Core情報Model[PCIM]から得られません。 これは装置のQoSメカニズムのモデルがそれらのメカニズムを管理する方針のモデルと別々であって、異なっているからです。したがって、彼らのコントロール(QoS Policyドキュメント[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].
それはそういうものの政策モデルではありませんが、このドキュメントはPolicy Core情報Model Extensionsドキュメント[PCIME]の上に依存を持っています。 装置レベルパケットフィルタリング(Classifierは交通の流れを複数の流れに分ける)はクラスが[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[R2119]で説明されるように本書では解釈されることであるべきです。
Moore, et al. Standards Track [Page 5] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[5ページ]。
1.1. Policy Management Conceptual Model
1.1. 政策管理の概念モデル
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.
Policy Core情報Model[PCIM]は、政策ルールを構成するために一般的な方法論について説明します。 PCIM Extensions[PCIME]はオリジナルのPCIMをアップデートして、広げています。 政策ルールは1セットの保険約款と1つの順序集合の政策的措置に集められます。 政策ルールの意味論は状態のセットがTRUE、その時まで動作のセットを評価するなら実行されるそのようなものです。
Policy conditions and actions have two principal components: operands and operators. Operands can be constants or variables. To specify a policy, it is necessary to specify:
保険約款と動作には、2つの主成分があります: オペランドとオペレータ。 オペランドは、定数か変数であるかもしれません。 方針を指定するために、指定するのが必要です:
o the operands to be examined (also known as state variables);
o 調べられるべき(また、州の変数として、知られています)オペランド。
o the operands to be changed (also known as configuration
variables);
o 変えられるべき(また、構成変数として、知られています)オペランド。
o the relationships between these two sets of operands.
o これらの2セットのオペランドの間の関係。
Operands can be specified at a high-level, such as Joe (a user) or Gold (a service). Operands can also be specified at a much finer level of detail, one that is much closer to the operation of the device. Examples of the latter include an IP Address or a queue's bandwidth allocation. Implicit in the use of operands is the binding of legal values or ranges of values to an operand. For example, the value of an IP address cannot be an integer. The concepts of operands and their ranges are defined in [PCIME].
ジョー(ユーザ)やGold(サービス)のようにハイレベルのaでオペランドを指定できます。 また、はるかにすばらしいレベルの詳細(装置の操作のはるかに近くにあるもの)でオペランドを指定できます。 後者に関する例はIP Addressか待ち行列の帯域幅配分を含んでいます。 オペランドの使用で暗黙であることは、法的な値か範囲のオペランドへの値の結合です。 例えば、IPアドレスの値は整数であるはずがありません。 オペランドの概念とそれらの範囲は[PCIME]で定義されます。
The second component of policy conditions and actions is a set of operators. Operators can express both relationships (greater than, member of a set, Boolean OR, etc.) and assignments. Together, operators and operands can express a variety of conditions and actions, such as:
保険約款と動作の2番目のコンポーネントは1セットのオペレータです。 オペレータが両方の関係を言い表すことができる、(すばらしさ、1セットのメンバー、ブール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
ボブがEngineerであるなら… ソースIPアドレスがマーケティングSubnetにあるなら… 設定ジョーのIPが.2を192.0まで記述する、.100Limit、10Mbへのアプリケーションxの帯域幅
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]がある)は、DifferentiatedとIntegrated Servicesのために方針を定義することにおける使用のために、1セットの特性(オペランド)を特定して、標準化しながら、第一歩を中に入れます。
Moore, et al. Standards Track [Page 6] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[6ページ]。
1.2. Purpose and Relation to Other Policy Work
1.2. 他の方針仕事との目的と関係
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メカニズムの規範的モデルを確立します。 これは、交通調節が説明されるのを1セットのサービスとしてモデル化された抽象化と一般的なサブサービスを利用することで可能にします。
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つはネットワークでアプリケーションの必要性にそのネットワークを使用することでサービスを縛る方針を定義できます。 言い換えれば、方針の1セットに組織に関するビジネス要件を反映できます、そして、ネットワーク装置の構成と操作を制御して、管理する方針の低レベルセットにそれらの方針を翻訳できます。
1.3. Typical Examples of Policy Usage
1.3. 方針用法の典型的な例
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:
低レベルである規則としてこの仕様で説明された情報モデルを使用することで政策を実施されることができるでしょう。 例えば、低レベルである方針で、状態は特定の属性の評価としてこのモデルから表されるかもしれません。 したがって、aがそのようなものを条件とさせる、「フィルタはHTTPと等しい」なら、何かHTTPフィルタが装置のために定義されたかどうか決定するテストとして解釈されるでしょう。 高値は方針を平らにします、あれほどです。「プロトコル=HTTP、そして、Differentiated Services Code Point(DSCP)24があるマークです」なら、低レベルである方針における一連の動作として以下で説明されたクラスと属性を使用することで言い表されるでしょう:
1. Create HTTP filter 2. Create DSCP marker with the value of 24 3. Bind the HTTP filter to the DSCP marker
1. HTTPフィルタ2を作成してください。 24の値で3にDSCPマーカーを創造してください。 DSCPマーカーにHTTPフィルタを縛ってください。
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".
装置を通り抜けるとき、「DSCP24があるマーク」と異なって、これらの低レベルである動作がパケットに実行されないことに注意してください。 むしろ、それらは正しいパケットへの正しい動作を実行するためにそれを用意するために装置自体に実行された構成動作です。 ハイレベルの政策ルールから低レベルである正しいセットの装置構成機能まで動く行為は[POLTERM]が「方針翻訳」か「方針変換」として特徴付けることに関する例です。
Moore, et al. Standards Track [Page 7] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[7ページ]。
2. Approach
2. アプローチ
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活動は2つの領域、Integrated Services(IntServ)、およびDifferentiated Services(DiffServ)で主に集中しました([POLTERM]、[R1633]、および[R2475]を見てください)。 このドキュメントは、パケット交通が条件とするdatapathをモデル化するためにQoSの特性とクラスの仕様に焦点を合わせます。 しかしながら、また、クラスによって定義された枠組みは本書ではIntServの入場コントロール部分の必要性をもって念頭に設計されています。
2.1. Common Needs Of DiffServ and IntServ
2.1. DiffServとIntServの共通の要求
First, let us consider IntServ. IntServ has two principal components. One component is embedded in the datapath of the networking device. Its functions include the classification and policing of individual flows, and scheduling admitted packets for the outbound link. The other component of IntServ is admission control, which focuses on the management of the signaling protocol (e.g., the PATH and RESV messages of RSVP). This component processes reservation requests, manages bandwidth, outsources decision making to policy servers, and interacts with the Routing Table manager.
まず最初に、IntServを考えましょう。 IntServには、2つの主成分があります。 1つのコンポーネントがネットワーク装置のdatapathに埋め込まれています。 機能は、個々の流れの分類と取り締まりと、アウトバウンドリンクのために認められたパケットの計画をするのを含んでいます。 IntServのもう片方の部品は入場コントロールです。(そのコントロールはシグナリングプロトコル(例えば、RSVPに関するPATHとRESVメッセージ)の管理に焦点を合わせます)。 このコンポーネントは、予約の要請を処理して、帯域幅を管理して、方針サーバに意志決定を社外調達して、ルート設定Tableマネージャと対話します。
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を考えるつもりです。 datapathの上の焦点、datapathに適切なRSVPの要素がそうするこのドキュメントとクラスの構造で考えられてください。 私たちが、より早くその後のドキュメントに記述されるように示して、完全なIntServ装置モデルはそうするでしょう。
This document models a small subset of the QoS policy problem, in hopes of constructing a methodology that can be adapted for other aspects of QoS in particular, and of policy construction in general. The focus in this document is on QoS for devices that implement traffic conditioning in the datapath.
このドキュメントはQoS方針問題の小さい部分集合をモデル化します、特にQoS、および一般に、方針工事の他の局面に適合させることができる方法論を構成するという望みで。 焦点がdatapathで交通調節を実行する装置のための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は排他的にdatapathで作動します。 それには、2つの主要な違いがあるIntServ datapathの同じ部品のすべてがあります。 まず最初に、DiffServは唯一それらのDSCPフィールドに基づくパケットを分類しますが、IntServは標準の流れのアドレシング5tupleの部分集合を調べます。 この規則への例外はDiffServドメインの境界のルータかホストに起こります。 この位置の装置はパケットのDSCP、アドレシング5-tuple、パケットの他の分野、または完全なパケットの外の情報さえ調べるかもしれません、転送の前にDiffServドメインにパケットをマークするDSCP値を決定する際に。 しかしながら、DSCP分野に基づいて、分類しますDiffServドメインの内陸部のルータが、必要があるだけである。
Moore, et al. Standards Track [Page 8] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[8ページ]。
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)で使用されるシグナリングプロトコルが、よりダイナミックなファッションによるdatapathの構成に影響するということです。 これはそれぞれの新たに認められたRSVPの予約がdatapathの再構成を必要とするからです。 対照的に、Per Hop Behaviors(PHBs)が構成された後にDiffServは遠くにdatapathへの、より少ない変化を必要とします。
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メカニズムを制御する方針の創造のために支持されたアプローチは最初に組み立てられる方針がことである属性を特定することです。 これらの属性は方針を構成するのに必要な表現に使用されるパラメタです。 これらの方針を構成する状態と動作を構成するのに必要なオペレータを定義する平行な願望も、関係、および先行構造物があります。 しかしながら、これらの努力はこのドキュメントの範囲を超えています。
2.2. Specific Needs Of DiffServ
2.2. DiffServの特定の必要性
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 Architectureドキュメント[R2475]で説明されるように、ネットワークの縁の装置は交通を異なった交通の流れに分類します。次に、ネットワークのコアは、異なった流れからPer Hop Behaviors(PHBs)の1セットを使用することによって、交通を送ります。 DSCPは各PHBを特定します。 DSCPはそれぞれのパケットのIPヘッダーの一部([R2474]で説明されるように)です。 これは、複数の交通の流れが少ない数の集められた交通の流れの中に集められるのを可能にします、それぞれの集合交通の流れは特定のDSCPが特定して、特定のPHBを使用するのを進めるところで。
The attributes used to manipulate QoS capabilities in the core of the network primarily address the behavioral characteristics of each supported PHB. At the edges of the DiffServ network, the additional complexities of flow classification, policing, RSVP mappings, remarkings, and other factors have to be considered. Additional modeling will be required in this area. However, first, the standards for edges of the DiffServ network need more detail - to allow the edges to be incorporated into the policy model.
ネットワークのコアで主としてQoS能力を操るのに使用される属性はPHBであるとサポートされたそれぞれの行動の特性を扱います。 DiffServネットワークの縁では、流れ分類、取り締まり、RSVPマッピング、「再-印」、および他の要素の追加複雑さが考えられなければなりません。 追加モデルがこの領域で必要でしょう。 しかしながら、最初に、DiffServネットワークの縁の規格はその他の詳細を必要とします--縁が政策モデルに組み入れられるのを許容するために。
2.3. Specific Needs Of IntServ
2.3. IntServの特定の必要性
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の管理は考えられません。 この話題は将来のドキュメントで扱われるでしょう。
Moore, et al. Standards Track [Page 9] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[9ページ]。
3. Methodology
3. 方法論
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メカニズムを表す1セットのクラスと関係を定義します。 [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メカニズムの操作と構成を管理するために図式を構成するのを手伝うべきです。
3.1. Level of Abstraction for Expressing QoS Policies
3.1. 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セットの規則であるとみなすなら、私たちは、方針がデバイスによって行われたトラフィックの調節に企業目標と規則に関連する仕様の連続かデバイスのセットを表すとわかります。 ビジネスレベル方針に関する例は以下の通りです。 太平洋標準時の午後1時0分から米国東部標準時の午前7時0分まで、自由市場のネットワーク容量の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
+---------------------+ | ハイレベルのビジネス| 直接デバイスに関連されません。| 方針| 操作と構成の詳細+---------------------+ | | +---------V-----------+ | デバイスから、独立しています。| ハイレベルの方針を翻訳します。| 方針| ジェネリックデバイス操作上、+---------------------+ 設定情報| | +---------V-----------+ | デバイス依存しています。| ジェネリックデバイス情報を翻訳してください。| 方針| 指定する、どれくらい特定のデバイス+---------------------+は作動して、構成されるべきです。
Figure 1. The Policy Continuum
図1。 方針連続
Moore, et al. Standards Track [Page 10] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[10ページ]。
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.
デバイスから独立している方針は1セットのどんな特定のデバイスからも独立していますが、特定のセットのQoSメカニズムに依存する操作上と構成の一般化された方針に営業方針を翻訳します、無作為の早期発見(RED)低下や荷重している連続スケジューリングのように。 また、これは、異なったタイプのデバイス(ルータ、スイッチ、ホストなど)が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方針の一般的なデバイスから独立している表現を提供できるくらい詳細にモデル化されます。 また、専門化の基礎を提供するのにそれらを使用できます、各ベンダーがそのベンダーのデバイスのセットのためにどうトラフィック調節をするかを表す1セットのベンダー特有のクラスを引き出すのを可能にして。
3.2. Specifying Policy Parameters
3.2. 方針パラメタを指定します。
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
方針はパラメタ(属性)とオペレータ(算数の、そして、関係している論理演算子など)の機能です。 したがって、両方が、トラフィックを正しく条件とさせるように同じ方針の一部と定義される必要があります。 方針のパラメタがあまり狭く指定されると、それらはQoSの個々の実装を各デバイスに反映するでしょう。 現在、QoSの正しい実装モデルが何であるかの産業にコンセンサスがほとんどないとき、ほとんどの定義された属性が単にいくつかの個々のデバイスのユニークな特性に適切でしょう。 そのうえ、これらをすべて、標準化すること。
Moore, et al. Standards Track [Page 11] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[11ページ]。
potential implementation alternatives would be a never-ending task as new implementations continued to appear on the market.
新しい実装がずっと市販に現れたので、潜在的実装代替手段は果てしないタスクでしょう。
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.
他方では、方針のパラメタがあまり広く指定されるなら、重要な方針を開発するのは不可能です。 既存のデバイスの大多数には、例えば、「ボブはGold Serviceを手に入れます」のような営業方針は私たちがいわゆるオリンピックのセットの方針に集中するなら明確に無意味です。 これはデバイスにはボブがだれであるか、そして、Goldが提供するどんな風を修理するかでどんな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.
その上、Goldサービスがただ一つのサービスを表すかもしれませんか、またはそれは互いに関連する1セットのサービスを特定するかもしれません。 後者の場合では、これらのサービスは異なった調節の特性を持っているかもしれません。
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トラフィックが調節であると実装しながらデバイスの推進経路で要素をモデル化するために規範的モデルに収まる1セットのパラメタを定義します。 デバイスから独立している方法でこのモデルを定義することによって、適切に必要なパラメタを抜き取ることができます。
3.3. Specifying Policy Services
3.3. 方針サービスを指定します。
Administrators want the flexibility to be able to define traffic conditioning without having to have a low-level understanding of the different QoS mechanisms that implement that conditioning. Furthermore, administrators want the flexibility to group different services together, describing a higher-level concept such as "Gold Service". This higher-level service could be viewed as providing the processing to deliver "Gold" quality of service.
管理者は、柔軟性にその調節を実装する異なったQoSメカニズムの低レベルである理解を持つ必要はなくてトラフィック調節を定義できて欲しいです。 その上、管理者は、「ゴールドサービス」などの、よりハイレベルの概念について説明して、柔軟性に異なったサービスを分類して欲しいです。 「金」サービスの質を提供するために処理を提供するとこのよりハイレベルのサービスを見なすことができました。
These two goals dictate the need for the following set of abstractions:
これらの2つの目標が以下のセットの抽象化の必要性を決めます:
o a flexible way to describe a service
o サービスについて説明するフレキシブルな方法
o must be able to group different services that may use different
technologies (e.g., DiffServ and IEEE 802.1Q) together
o 異なった技術(例えば、DiffServとIEEE 802.1Q)を一緒に、使用するかもしれない異なったサービスは分類できなければなりません。
o must be able to define a set of sub-services that together make up
a higher-level service
o 1セットのそんなに一緒にいるサブサービス造をよりハイレベルのサービスと定義できなければなりません。
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メカニズムを管理する方針は定義できなければならなくなってください。
Moore, et al. Standards Track [Page 12] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[12ページ]。
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.
このドキュメントが1セットのクラスを定義することによってこのセットのその問題を訴えて、抽象概念を表すことができる協会が、「ゴールドサービス」が好きであり、彼らが必要とする調節を実装する特定のセットのQoSメカニズムに対するそれぞれのこれらの抽象的なサービスを縛ります。 その上、このドキュメントは、Gold Serviceがただ一つのサービスと定義されるのを可能にするために「サブサービス」の概念を定義するべきであるか、または1セットのそんなに一緒にいるサービスとして原子実体として扱われるべきです。
Given these abstractions, policies (as defined in [QPIM]) can be written to control the QoS mechanisms and services defined in this document.
これらの抽象化を考えて、本書では定義されたQoSメカニズムとサービスを制御するために、方針([QPIM]で定義されるように)を書くことができます。
3.4. Level of Abstraction for Defining QoS Attributes and Classes
3.4. 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メカニズムを構成する方針をサポートするために1セットのクラスと特性を定義します。このドキュメントはdatapathでのDiffServ(集合トラフィック調節のための)とIntServ(流れベースのトラフィック調節のための)の両方をサポートするサービスの表現に集中します。 モデルIntServ入場コントロールサービスのためのクラスと特性は将来のドキュメントで定義されるかもしれません。
The classes and properties in this document are designed to be used in conjunction with the QoS policy classes and properties defined in [QPIM]. For example, to preserve the delay characteristics committed to an end-user, a network administrator may wish to create policies that monitor the queue depths in a device, and adjust resource allocations when delay budgets are at risk (perhaps as a result of a network topology change). The classes and properties in this document define the specific services and mechanisms required to implement those services. The classes and properties defined in [QPIM] provide the overall structure of the policy that manages and configures this service.
クラスと特性は、[QPIM]で定義されたQoS方針のクラスと特性に関連して使用されるように本書では設計されています。 例えば、遅れの特性がエンドユーザ、ネットワーク管理者に遂行した保護区に、デバイスの深層は待ち行列をモニターする方針を作成したがっているかもしれません、そして、遅れ予算が危険である(恐らくネットワーク形態変化の結果、)ときには資源配分を調整してください。 クラスと特性は本書では特定のサービスを定義します、そして、メカニズムがそれらのサービスを実装するのが必要です。 [QPIM]で定義されたクラスと特性はこのサービスを管理して、構成する方針の全体的な構造を提供します。
This combination of low-level specification (using this document) and high-level structuring (using [QPIM]) of network services enables network administrators to define new services required of the network, that are directly related to business goals, while ensuring that such services can be managed. However, this goal (of creating and managing service-oriented policies) can only be realized if policies can be constructed that are capable of supporting diverse implementations of QoS. The solution is to model the QoS capabilities of devices at the behavioral level. This means that for traffic conditioning services realized in the datapath, the model must support the following characteristics:
ネットワーク・サービスの低レベルである仕様(このドキュメントを使用する)とハイレベルの構造([QPIM]を使用する)のこの組み合わせは、ネットワーク管理者がネットワークについて必要である新種業務を定義するのを可能にして、そのようなサービスに対処できるのを確実にしている間、それは直接企業目標に関連します。 しかしながら、QoSのさまざまの実装をサポートすることができる方針を構成できる場合にだけ、この目標(サービス志向の方針を作成して、管理する)を実現できます。 ソリューションは行動のレベルでデバイスのQoS能力をモデル化することです。 これは、datapathに実現されたトラフィック調節サービスのためにモデルが以下の特性をサポートしなければならないことを意味します:
o modeling of a generic network service that has QoS capabilities
o QoS能力を持っているジェネリックネットワーク・サービスのモデル
Moore, et al. Standards Track [Page 13] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[13ページ]。
o modeling of how the traffic conditioning itself is defined
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メカニズムに、ネットワーク・サービスをモデル化して、それを関連づけます。 また、それは標準形で状態トラフィックに使用される様々なコンポーネントをモデル化します、標準の、そして、カスタムのトラフィック調節サービスについて説明できるように。
3.5. Characterization of QoS Properties
3.5. 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で提案されます。 モデルの大部分が構成に関連します。 この事実を考えて、このモデルがデバイスへのダイレクトメモリマップであると思われます。 モデルのクラスと特性のすべての操作が直接デバイスの状態に影響します。 また、必要な構成を表すのにこれらのクラスを使用するのが必要であるなら、それは作成者に任せます。
Moore, et al. Standards Track [Page 14] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[14ページ]。
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.
追加特性が現状を完全にモデル化するのが必要であると認められます。 しかしながら、本書では定義された特性の多くがまさに構成の特性によって構成される州の変数を表します。 したがって、構成の特性の定義は、州の所有地で正確な通信を持って、実際の(状態)と必要であるか提案された構成の両方をモデル化する際に使用できます。
3.6. QoS Information Model Derivation
3.6. QoS情報モデル派生
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は方針を使用することで制御できる1セットのサービスです。 これらのサービスはデバイスメカニズムとして表されます。与えられたデバイスの固有であるメカニズムで、QoSサービス、および他のタイプのサービス(例えば、セキュリティ)を提供するという重要なポイントがここにあります。 これは、本当に、すべてのデバイスが等しい状態で作成されるというわけではないことを意味します。 例えば、2台のデバイスには、同じタイプのメカニズム(例えば、待ち行列)があるかもしれませんが、1つは簡単な実装であるかもしれません(すなわち、先入れ先出し待ち行列)が、はるかに複雑であって、強健であるかもしれません(例えば、クラスベースの均等化キューイング(CBWFQ))。 しかしながら、サービスをQoSに提供するのにこれらのデバイスの両方を使用できます、そして、両方が方針で制御される必要があります。 その結果、デバイスから独立している方針は、あるトラフィックを列に並ばせるようデバイスに命令できます、そして、中の列を作りを制御するのにデバイス特定保険証券は使用できます。各デバイス。
Furthermore, policy is used to control these mechanisms, not to represent them. For example, QoS services are implemented with classifiers, meters, markers, droppers, queues, and schedulers. Similarly, security is also a characteristic of devices, as authentication and encryption capabilities represent services that networked devices perform (irrespective of interactions with policy servers). These security services may use some of the same mechanisms that are used by QoS services, such as the concepts of filters. However, they will mostly require different mechanisms than the ones used by QoS, even though both sets of services are implemented in the same devices.
その上、方針は、それらを表すのではなく、これらのメカニズムを制御するのに使用されます。 例えば、QoSサービスはクラシファイア、メーター、マーカー、点滴器、待ち行列、およびスケジューラで実装されます。 同様に、また、セキュリティはデバイスの特性です、認証と暗号化能力がネットワークでつながれたデバイスが実行する(方針サーバとの相互作用の如何にかかわらず)サービスを表すとき。 これらのセキュリティー・サービスはQoSサービスで使用される同じメカニズムのいくつかを使用するかもしれません、フィルタの概念などのように。 しかしながら、彼らはQoSによって使用されたものと異なったメカニズムをほとんど必要とするでしょう、両方のセットのサービスが同じデバイスで実装されますが。
Thus, the similarity between the QoS model and models for other services is not so much that they contain a few common mechanisms. Rather, they model how a device implements their respective services.
したがって、他のサービスのためのQoSモデルとモデルの間の類似性が非常に多くでないので、それらはいくつかの一般的なメカニズムを含んでいます。むしろ、デバイスがどう彼らのそれぞれのサービスを実装するかをモデル化します。
Moore, et al. Standards Track [Page 15] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[15ページ]。
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はデバイスでdatapathを調整して、ネットワークデバイスでこれらのサービスを制御する方針を適用することであることができます。 その上、これらの2概要(デバイスと方針)は、方針がQoSサービスを制御するのを可能にするためにしっかり統合していなければなりません。
3.7. Attribute Representation
3.7. 属性表現
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属性が無名数として表されるなら(例えば、Class AF2は帯域幅の2Mbsを手に入れます)、彼らをデバイスの複数のポートか複数のデバイスの向こう側に一定にするのは、より難しいです、リンク能力の広い変化のために。 しかしながら、相対的であるか比例している用語(例えば、Class AF2は総リンク帯域幅の5%を得る)で属性を言い表すのに、あるタイプの状態と動作を言い表すのは、より難しくなります、以下のように
(If ConsumedBandwidth = AssignedBandwidth Then ...)
(ConsumedBandwidthがその時AssignedBandwidthと等しいなら)
There are really three approaches to addressing this problem:
本当に、このその問題を訴えることへの3つのアプローチがあります:
o Multiple properties can be defined to express the same value in
various forms. This idea has been rejected because of the
difficulty in keeping these different properties synchronized
(e.g., when one property changes, the others all have to be
updated).
o 様々なフォームで同じ値を言い表すために複数の特性を定義できます。この考えはこれらの異なった特性を同期させ続けることにおける苦労で拒絶されました(例えば、1であるときに、資産は変化します、アップデートするためにすべてがいる他のもの)。
o Multi-modal properties can be defined to express the same value,
in different terms, based on the access or assignment mode. This
option was rejected because it significantly complicates the model
and is impossible to express in current directory access protocols
(e.g., (L)DAP).
o アクセスか課題モードに基づいて異なった用語で同じ値を言い表すためにマルチモーダルの特性を定義できます。 カレントディレクトリアクセス・プロトコルで((L) 例えば、DAP)を言い表すのがモデルをかなり複雑にして、不可能であるので、このオプションは拒絶されました。
o Properties can be expressed as "absolutes", but the operators in
the policy schema would need to be more sophisticated. Thus, to
represent a percentage, division and multiplication operators are
required (e.g., Class AF2 gets .05 * the total link bandwidth).
This is the approach that has been taken in this document.
o 「絶対的なもの」として特性を示すことができますが、方針図式のオペレータは、より洗練されている必要があるでしょう。 したがって、割合を表すために、分割と乗算演算子が必要です(例えば、Class AF2は総リンク帯域幅を.05*に得ます)。 これは本書では取られたアプローチです。
Moore, et al. Standards Track [Page 16] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[16ページ]。
3.8. Mental Model
3.8. メンタル・モデル
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].
この図式を構成するためのメンタル・モデルはDifferentiated Servicesワーキンググループで行われた仕事に基づいています。 この図式はDiffServ Informal Management Model[DSMODEL]、DiffServ MIB[DSMIB]、PIB[PIB]の最新版に提供された情報と、そして、DiffServ([R2475]、[R2474]、[R2597]、および[R3246])自身の基本的な定義を構成するRFCsのセットにおける情報に基づいています。 さらに、一般的な用語は[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つの1セットの協会を使用するのにおいて一緒に制限された基本的なクラス階層構造がこのモデルに築き上げられます。 2つのクラス階層構造がQoSServiceとConditioningServiceから基底クラスを引き出します。 1セットの協会は、よりハイレベルのQoSサービスに低レベルQoSServiceサブクラスに関連して、トラフィックのクラスを処理する際に異なったタイプの調節サービスを一緒に関係づけて、特定のQoSサービスにサービスを適合させるセットを関係づけます。 協会のこの組み合わせは、私たちがアプリケーション特有のサービスを構成するためにモジュールのブロックファッションで構成できる1セットのサービスを提供するとデバイスをみなすのを可能にします。 したがって、存在と今後の標準の、そして、アプリケーション特有のネットワークQoSサービスをモデル化するのにこのドキュメントを使用できます。
3.8.1. The QoSService Class
3.8.1. QoSServiceのクラス
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.
ここで定義された、クラスの1番目、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サービスを提供することへの異なるアプローチを表す1セットのサブクラスがあります。 現在定義されたセットのサブクラスは、流れ指向の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集合は、1個以上のQoSServiceオブジェクトが特定のQoSServiceオブジェクトに補助的であることを示します。 例えば、これは、私たちが2つのDiffServサービスの組み合わせ、高品質のトラフィック処理のためのもの、およびトラフィックの残りを修理するための1つとGold Serviceを定義するのを可能にします。 それぞれのこれら
Moore, et al. Standards Track [Page 17] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[17ページ]。
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オブジェクトは1セットのクラシファイア、マーカー、など、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 Groupの中のいくつかの関連する印がただ一つのサービスを提供するために一緒に働いているという特定の概念を表すのに使用されます。 1コード・ポイント以上を使用する他のDiffServ PHB Groupsが定義されるとき、これらは追加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.
これらの概念は図2に表現されます。 協会の両方が集合であることに注意してください: QoSServiceオブジェクトはそれがわかるそれに補助的なQoSServiceオブジェクトのセットとConditioningServiceオブジェクトのセットの両方に集められます。 クラスと協会定義に関してセクション4を見てください。
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |
| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..n 0..n| |
| | /\______________________| |
| | \/ QoSConditioning | |
+--------------+ SubService +---------------+
/\______ 0..1 \/ | +--------------+ | QoSSubService+---------------+ | |0..n| | | | QoSService|----- | 調節| | | | サービス| | | | | | |0..n0。n| | | | /\______________________| | | | \/QoSConditioning| | +--------------+ SubService+---------------+
Figure 2. QoSService and its Aggregations
図2。 QoSServiceとそのAggregations
3.8.2. The ConditioningService Class
3.8.2. ConditioningServiceのクラス
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のクラスの目標はそして、出口のインタフェースでそれがデバイスを入れるイングレスインタフェースの上と、そして、上デバイスが残っている与えられたトラフィックストリームに適用されるトラフィック調節の系列について説明することです。 これは1セットのクラスと関係を使用し終わっています。 デバイスコアでのルーティング決定はこのモデルで表されません。(コアは、特定のパケットがどの出口のインタフェースを使用するかを選択します)。
A single base class, ConditioningService, is the superclass for a set of subclasses representing the mechanisms that condition traffic.
単独ベースのクラス(ConditioningService)は交通を条件とさせるメカニズムを表す1セットのサブクラスのための「スーパー-クラス」です。
Moore, et al. Standards Track [Page 18] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[18ページ]。
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).
したがって、このモデルは、イングレスか出口のインタフェースのConditioningServicesの中でConditioningServiceのサブクラスの中で固定注文を決めもしませんし、最初にか最後に現れなければならないConditioningServiceのサブクラスを特定もしません。 代わりに、このモデルは、NextService、NextServiceAfterMeter、およびNextServiceAfterConditioningElement協会を使用することで様々なConditioningService例をイングレスか出口のインタフェースに結びつけます。 また、それぞれイングレスインタフェースを最初のConditioningServiceに結んで、出口のインタフェースを最後のConditioningService(s)に結ぶIngressConditioningServiceOnEndpointとEgressConditioningServiceOnEndpointと呼ばれる別々の協会があります。
3.8.3. Preserving QoS Information from Ingress to Egress
3.8.3. イングレスから出口までQoS情報を保存します。
There is one important way in which the QDDIM model diverges from the [DSMODEL]. In [DSMODEL], traffic passes through a network device in three stages:
QDDIMモデルが[DSMODEL]からそれる1つの重要な方法があります。 [DSMODEL]では、交通は3つの段階をネットワーク装置を通り抜けます:
o It comes in on an ingress interface, where it may receive QoS
conditioning.
o それはイングレスインタフェースに参加します。そこでは、それがQoS調節を受けるかもしれません。
o It traverses the routing core, where logic outside the scope of
QoS determines which egress interface it will use to leave the
device.
o それはルーティングコアを横断します。そこでは、QoSの範囲の外の論理が、それが装置を残すのにどの出口のインタフェースを使用するかを決定します。
Moore, et al. Standards Track [Page 19] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[19ページ]。
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--->
+---------+
+---------+ | メーターA| a| | b d--->| コネ|---午後の1--->|、| c e| アウト|---午後の2--->+---------+
Figure 3: Meter Followed by Two Preamble Markers
図3: 2人の序文マーカーによって続かれたメーター
Figure 3 shows an example in which meter results are captured in a packet preamble. The arrows labeled with single letters represent instances of either the NextService association (a, d, and e), or of its peer association NextServiceAfterMeter (b and c). PreambleMarker PM-1 adds to the packet preamble an indication that the packet exited Meter A as conforming traffic. Similarly, PreambleMarker PM-2 adds to the preambles of packets that come through it indications that they exited Meter A as nonconforming traffic. A PreambleMarker appends its information to whatever is already present in a packet preamble, as opposed to overwriting what is already there.
図3はメーター結果がパケット序文で得られる例を示しています。 ただ一つの手紙でラベルされた矢はNextService協会(a、d、およびe)、または同輩協会NextServiceAfterMeter(bとc)の例を表します。 PreambleMarker PM-1はパケットが交通を従わせるとしてMeter Aを出たという指示をパケット序文に追加します。 同様に、PreambleMarker PM-2は、「非-従」うとしてMeter 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がパケット序文に既に存在している情報に情報を「追加する」とき、それは、示された形式の追加項目をリストの終わりに加えることによって、そうします。
Moore, et al. Standards Track [Page 20] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[20ページ]。
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).
o VlanId: 値はバーチャルLAN識別子(VLAN ID)です。
Implementations may recognize other <type>'s in addition to these. If collisions of implementation-specific <type>'s become a problem, it is possible that <type>'s may become an IANA-administered range in a future revision of this document.
実現はこれらに加えてタイプ>の他の<ものを認識するかもしれません。 実現特有の>の<タイプものの衝突が問題になるなら、タイプ>の<ものがこのドキュメントの今後の改正における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個のメーター関連のフィルタの<値の>部分への「いずれも」をワイルドカードに許容します。 このワイルドカードで、管理者はそれらのそれぞれのメーターに従って、従うのと、(部分的に従うか、または非従うこと)であることがわかったすべてのパケットを選択するためにClassifierを指定できます、別々の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.
メーター結果がパケット序文にいったん格納されると、どんなその後のClassifierも使用するように、それは利用可能です。 それで、また、この能力に関する動機がイングレスインタフェースからの情報を出口のインタフェースに適合させるQoSを保存することに関して説明されている間、先のメーター結果は、後で同じインタフェースでdatapathでパケットを分類するのにメーターがあるところで使用されるかもしれません。
3.9. Classifiers, FilterLists, and Filter Entries
3.9. クラシファイア(FilterLists)とフィルタエントリー
This document uses a number of classes to model the classifiers defined in [DSMODEL]: ClassifierService, ClassifierElement, FilterList, FilterEntryBase, and various subclasses of FilterEntryBase. There are also two associations involved: ClassifierElementUsesFilterList and EntriesInFilterList. The QDDIM model makes no use of CIM's FilterEntry class.
このドキュメントは[DSMODEL]で定義されたクラシファイアをモデル化するのに多くのクラスを使用します: FilterEntryBaseのClassifierService、ClassifierElement、FilterList、FilterEntryBase、および様々なサブクラス。 また、かかわった2つの協会があります: ClassifierElementUsesFilterListとEntriesInFilterList。 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
[DSMODEL]では、クラシファイアに入るただ一つの交通の流れはそれを残す複数の交通の流れに分けられます。流れに基づいて、1つの順序集合のフィルタでは、入って来る流れにおける各パケットは合っています。 A
Moore, et al. Standards Track [Page 21] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[21ページ]。
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.
パケット自体の分野か属性のどちらかがことによると他のパケットに関連づけたマッチをフィルターにかけてください。 マルチ分野(MF)クラシファイアの場合では、パケットはパケットのヘッダーの複数の分野のコンテンツに基づく出力ストリームに割り当てられます。 例えば、MFクラシファイアはそれらの完全なIPに演説している5-tupleに基づく出力ストリームにパケットを割り当てるかもしれません。
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と共に、1個のIPHeaderFilter物を含むFilterListはすべての5つのIP5-tupleヘッダーフィールドとDiffServ DSCPに基づくパケットを選択する評価基準を表すことができます。 これらの2つのクラスがそれらを超えたアプリケーションを本書では考えさせるので、それら、および抽象クラスFilterEntryBaseはここよりむしろさらに一般的なドキュメント[PCIME]で定義されます。
The FilterList object is always needed, even if it contains only one filter entry (that is, one FilterEntryBase subclass) object. This is because a ClassifierElement can only be associated with a Filter List, as opposed to an individual FilterEntry. FilterList is also defined in [PCIME].
1個のフィルタエントリー(すなわち、1つのFilterEntryBaseサブクラス)物だけを含んでも、FilterList物がいつも必要です。 これは個々のFilterEntryと対照的にClassifierElementをFilter Listに関連づけることができるだけであるからです。 また、FilterListは[PCIME]で定義されます。
The EntriesInFilterList aggregation (also defined in [PCIME]) has a property EntrySequence, which in the past (in CIM) could be used to specify an evaluation order on the filter entries in a FilterList. Now, however, the EntrySequence property supports only a single value: '0'. This value indicates that the FilterEntries are ANDed together to determine whether a packet matches the MF selector that the FilterList represents.
EntriesInFilterList集合(また、[PCIME]で定義される)には特性のEntrySequenceがあります。(過去(CIMにおける)にFilterListのフィルタエントリーに関する評価命令を指定するのにEntrySequenceを使用できます)。 今、しかしながら、EntrySequenceの特性はただ一つの値だけを支持します: '0'. この値は、パケットがFilterListが表すMFセレクタに合っているかどうか決定するためにFilterEntriesが一緒にANDedであることを示します。
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の集合を指定するところにあります。 1つの実用的なケースが各ClassifierServiceが特定用途に関連している方針のグループを指定するところでしょう、そして、別のClassifierServiceはアプリケーション特有のClassifierService例を分類します。 この場合は、アプリケーション特有のClassifierService例は一度指定されますが、これらのClassifierServicesのユニークな組み合わせは指定されます、必要に応じて、他のClassifierService例を使用して。 他のClassifierService例を分類するClassifierService例はFilterList使用を指定しないかもしれません。
Moore, et al. Standards Track [Page 22] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[22ページ]。
ClassifierElementUsesFilterList association. This special use of ClassifierService serves just as a Classifier collecting function.
ClassifierElementUsesFilterList協会。 ClassifierServiceのこの特別な使用はちょうどClassifier収集機能として機能します。
3.10. Modeling of Droppers
3.10. ドロッパーズのモデル
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の役割を果たします。 まさに点滴器がパケットを落とす1つの待ち行列がいつもあります。
Since an absolute dropper drops all packets in its queue, it needs no configuration beyond a NextService tie to that queue. For an algorithmic dropper, however, further configuration is needed:
絶対点滴器が待ち行列ですべてのパケットを落とすので、それは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;
o アルゴリズムへの入力の源。
o possibly per-input parameters for the algorithm.
o アルゴリズムのためのことによると入力あたりのパラメタ。
The first two of these items are represented by properties of the DropperService class, or properties of one of its subclasses. The last two, however, involve additional classes and associations.
これらの2つの最初の項目がDropperServiceのクラスの特性、またはサブクラスの1つの特性によって表されます。 しかしながら、最後の2は追加クラスと協会にかかわります。
3.10.1. Configuring Head and Tail Droppers
3.10.1. ヘッドとTailドロッパーズを構成します。
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つの入力を低下アルゴリズムに持って、いつもこの入力がそれがパケットを落とす待ち行列であるので。 テール点滴器に関しては、この協会は、多くへの多く基数を持つために定義されます。 しかしながら、2つの異なったケースがあります:
One dropper bound to many queues: This represents the case where the drop algorithm for the dropper involves inputs from more than one queue. The dropper still drops from only one queue, the one to which it is tied by a NextService association. But the drop decision may be influenced by the state of several queues. For the classes HeadTailDropper and HeadTailDropQueueBinding, the rule for combining the multiple inputs is simple addition: if the sum of the lengths of the monitored queues exceeds the dropper's QueueThreshold value, then
1個の点滴器が多くの待ち行列に固まりました: これは点滴器のための低下アルゴリズムが1つ以上の待ち行列から入力を伴うケースを表します。 点滴器は1つの待ち行列だけ、それがNextService協会によって結ばれるものからまだ低下しています。 しかし、低下決定はいくつかの待ち行列の州によって影響を及ぼされるかもしれません。 クラスのHeadTailDropperとHeadTailDropQueueBindingにおいて、複数の入力を結合するための規則は簡単な添加です: 次に、モニターされた待ち行列の長さの合計が点滴器のQueueThreshold値を超えているなら
Moore, et al. Standards Track [Page 23] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[23ページ]。
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のサブクラスかこれらのクラスの両方で異なった規則でくつがえされるかもしれません。
One queue bound to many droppers: This represents the case where the state of one queue (which is typically also the queue from which packets are dropped) provides an input to multiple droppers' drop algorithms. A use case here is a classifier that splits a traffic stream into, say, four parts, representing four classes of traffic. Each of the parts goes through a separate HeadTailDropper, then they're re-merged onto the same queue. The net is a single queue containing packets of four traffic types, with, say, the following drop thresholds:
1つの待ち行列が多くの点滴器に付きました: これはある待ち行列(また、通常、パケットが落とされる待ち行列である)の州が複数の点滴器の低下アルゴリズムに入力を提供するケースを表します。Aは、交通の流れをたとえば、4つの部品に分けるクラシファイアであり、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--3--70%の2--80%の90%の完全な○完全な○Class完全な○Class Class4--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%完全になるとき、この構成で、Class4パケットはClass3、70%完全になって、4つのパケットが落とされるとき待ち行列に参加するのなどよりむしろ落とされるでしょう。
The two cases described here can also occur together, if a dropper receives inputs from multiple queues, one or more of which are also providing inputs to other droppers.
また、ここで説明された2つのケースが一緒に現れることができます、点滴器が複数の待ち行列から他の点滴器までの入力を受け取るなら。また、それのものか以上が待ち行列のために入力を提供しています。
3.10.2. Configuring RED Droppers
3.10.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点滴器がそれを使用する前にそれぞれのこれらの入力は整えられるかもしれません、そして、平滑化処理自体をparameterizedしなければなりません。 その結果、REDDropperServiceとQueuingServiceに加えて、この平滑化処理の1待ち行列あたりのパラメタリゼーションを表すために、3番目のクラス(DropThresholdCalculationService)を導入します。
Moore, et al. Standards Track [Page 24] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[24ページ]。
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
RDSvc-A| | | +-----+ | +-----+ | | | DTCS-1 DTCS-2 DTCS-3| | | Q-1 Q-2 Q-3
Figure 4. Inputs for a RED Dropper
図4。 赤い点滴器のための入力
So REDDropperService-A (RDSvc-A) is using inputs from three queues to make its drop decision. (As always, RDSvc-A is linked to the queue from which it drops packets via the NextService association.) For each of these three queues, there is a (DropThresholdCalculationService) DTCS instance that represents the smoothing weight and time interval to use when looking at that queue. Thus each DTCS instance is tied to exactly one queue, although a single queue may be examined (with different weight and time values) by multiple DTCS instances. Also, a DTCS instance and the queue behind it can be thought of as a "unit of reusability". So a single DTCS can be referred to by multiple RDSvc's.
そのように、REDDropperService-A。(RDSvc-a)がそうである使用は、低下を決定にするように3から待ち行列を入力します。 (いつものように、RDSvc-AはそれがNextService協会を通してパケットを落とす待ち行列にリンクされます。) それぞれのこれらの3つの待ち行列のために、それが列を作るのを見るとき使用するスムージング重りと時間間隔を表す(DropThresholdCalculationService)DTCS例があります。 したがって、それぞれのDTCS例はまさに1つの待ち行列に結ばれます、ただ一つの待ち行列が複数のDTCS例によって調べられるかもしれませんが(異なった重さと時間的価値で)。 また、「リユーザビリティのユニット」としてDTCS例とそれの後ろの待ち行列を考えることができます。 それで、RDSvcの複数のものが独身のDTCSについて言及できます。
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のものからの平坦な入力を結合するのに使用する規則は簡単な添加です。
3.11. Modeling of Queues and Schedulers
3.11. 待ち行列とスケジューラのモデル
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つの例を特定しました。
3.11.1. Simple Hierarchical Scheduler
3.11.1. 簡単な階層的なスケジューラ
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
簡単で、階層的なスケジューラには、以下の特性があります。 1セットの待ち行列にスケジューリングの機会を与えるとき、まず最初に、単一の、そして、実行可能な待ち行列はいくつかのスケジューリング評価基準に基づいて決定しています、帯域幅や優先権のように。 スケジューラの出力はただ一つの論理的な待ち行列として最初のスケジューラ(そして、待ち行列)を扱う別のスケジューラへの入力です。 したがって、最初のスケジューラが好個を決定したなら、放出するパケットはそれぞれに割り当てられた優先を基礎づけました。
Moore, et al. Standards Track [Page 25] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[25ページ]。
queue, the second scheduler might specify a bandwidth limit/allocation for the entire set of queues aggregated by the first scheduler.
列を作ってください、そして、2番目のスケジューラは最初のスケジューラによって集められた全体のセットの待ち行列のための帯域幅限界/配分を指定するかもしれません。
+----------+ NextService
|QueuingSvc+----------------------------------------------+
| Name=EF1 | |
| | QueueTo +--------------+ ElementSched |
| +------------+PrioritySched +---------------+ |
+----------+ Schedule |Element | Service | |
| Name=EF1-Pri | | v
| Priority=1 | +-----------+-+-+
+--------------+ |SchedulingSvc +
| Name=PriSched1+
+--------------+ +----------+--+-+
|PrioritySched | ElementSched | ^
+----------+ |Element +---------------+ |
|QueuingSvc| QueueTo | Name=AF1x-Pri| Service |
| Name=AF1x+------------+ Priority=2 | |
| | Schedule +--------------+ |
| | NextService |
| +----------------------------------------------+
+----------+
:
+---------------+ NextScheduler
|SchedulingSvc +--------------------------------------------+
| Name=PriSched1| |
+-------+-------+ +--------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling+--------+ |
+---------------+Element | | |
| Name=PriSched1-Band| | |
| Units=Bytes | | v
| Bandwidth=100 | +------+------+--+
+--------------------+ |SchedulingSvc |
| Name=BandSched1|
+--------------------+ +------+------+--+
|AllocationScheduling| | ^
+---------------+ |Element +--------+ |
|QueuingService | | Name=BE-Band |ElementSchedSvc|
| Name=BE |QueueTo+ Units=Bytes | |
| |-------+ Bandwidth=50 | |
| |Sched +--------------------+ |
| | NextService |
| +--------------------------------------------+
+---------------+
+----------+ NextService|QueuingSvc+----------------------------------------------+ | 名前=EF1| | | | QueueTo+--------------+ ElementSched| | +------------+ PrioritySched+---------------+ | +----------+ スケジュール|要素| サービス| | | 名前=EF1-Pri| | v| 優先権=1| +-----------+-+-+ +--------------+ |SchedulingSvc+| =PriSched1を+ +と命名してください。--------------+ +----------+--+-+ |PrioritySched| ElementSched| ^ +----------+ |要素+---------------+ | |QueuingSvc| QueueTo| 名前=AF1x-Pri| サービス| | =AF1xを+と命名してください。------------+ 優先権=2| | | | スケジュール+--------------+ | | | NextService| | +----------------------------------------------+ +----------+ : +---------------+ NextScheduler|SchedulingSvc+--------------------------------------------+ | 名前=PriSched1| | +-------+-------+ +--------------------+ ElementSchedSvc| | SchedToSched|AllocationScheduling+--------+ | +---------------+ 要素| | | | 名前=PriSched1-バンド| | | | ユニット=バイト| | v| 帯域幅=100| +------+------+--+ +--------------------+ |SchedulingSvc| | 名前=BandSched1| +--------------------+ +------+------+--+ |AllocationScheduling| | ^ +---------------+ |要素+--------+ | |QueuingService| | 名前、= いてください、-組になってください。|ElementSchedSvc| | 名前、= いてください。|QueueTo+ユニット=バイト| | | |-------+ 帯域幅=50| | | |+をSchedしました。--------------------+ | | | NextService| | +--------------------------------------------+ +---------------+
Figure 5. Example 1: Simple Hierarchical Scheduler
図5。 例1: 簡単な階層的なスケジューラ
Moore, et al. Standards Track [Page 26] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[26ページ]。
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は待ち行列の後に最初のスケジューラを決定します。 NextSchedulerはスケジューラのその後の注文を決定します。 さらに、ElementSchedulingService協会は特定のスケジューラによって使用されるスケジューリングパラメタのセットを決定します。 待ち行列、または、スケジューラにスケジューリングパラメタを縛ることができます。 SchedulingElement EF1-Priの場合では、待ち行列には結合があるので、QueueToSchedule協会は使用されています。 SchedulingElement PriSched1-バンドの場合では、別のスケジューラには結合があるので、SchedulerToSchedule協会は使用されています。 ドキュメントの宇宙規制のため、SchedulingService PRISched1がそれがどう他のすべての物に接続されるかを示しているために二度表されることに注意してください。
3.11.2. Complex Hierarchical Scheduler
3.11.2. 複雑な階層的なスケジューラ
A complex, hierarchical scheduler has the same characteristics as a simple scheduler, except that the criteria for the second scheduler are determined on a per queue basis rather than on an aggregate basis. One scenario might be a set of bounded priority schedulers. In this case, each queue is assigned a relative priority. However, each queue is also not allowed to exceed a bandwidth allocation that is unique to that queue. In order to support this scenario, the queue must be bound to two separate schedulers. Figure 6 illustrates this situation, by describing an EF queue and a best effort (BE) queue both pointing to a priority scheduler via the NextService association. The NextScheduler association between the priority scheduler and the bandwidth scheduler in turn defines the ordering of the scheduling hierarchy. Also note that each scheduler has a distinct set of scheduling parameters that are bound back to each queue. This demonstrates the need to support two or more parameter sets on a per queue basis.
複雑で、階層的なスケジューラには、簡単なスケジューラと同じ特性があります、2番目のスケジューラの評価基準が集合ベースでというよりむしろ待ち行列基礎あたりのaで決定しているのを除いて。 1つのシナリオが1セットの境界がある優先度スケジューラであるかもしれません。 この場合、相対的な優先は各待ち行列に割り当てられます。 しかしながら、また、各待ち行列はその待ち行列にユニークな帯域幅配分を超えることができません。 このシナリオを支持するために、待ち行列を2つの別々のスケジューラまで縛らなければなりません。 図6はこの状況を例証します、NextService協会を通してともに優先度スケジューラを示すEF待ち行列とベストエフォート型(ある)の待ち行列について説明することによって。 優先度スケジューラと帯域幅スケジューラとのNextScheduler協会は順番にスケジューリング階層構造の注文を定義します。 また、各スケジューラには縛り返されるパラメタがそれぞれ列を作る計画をする異なったセットがあることに注意してください。 これは待ち行列基礎あたりのaの2つ以上のパラメタセットを支える必要性を示します。
Moore, et al. Standards Track [Page 27] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[27ページ]。
+----------------+
|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 |
| | +----------------+
+--------------+
+----------------+ |QueuingService| | 名前=EF| | |QueueTo+----------------+ ElementSchedSvc| +----------+ AllocationSched+--------+ ++---+-----------+ スケジュール|要素| | | | | 名前=BandEF| | | |QueueTo| ユニット=バイト| | | |スケジュール| 帯域幅=100| | | | +----------------+ +------+---------+ | | |SchedulingSvc| | | +------------------+ | 名前=BandSched| | +------+ PriorityScheduling| +------------+--++ | |要素| ^ | | | 名前=PriEF|ElementSchedSvc| | | | 優先権は1+と等しいです。---------------------+ | | | +------------------+ | | | |NextService| | | +-------------------------------------------------+ | | | | | | | NextService| | | | +-----------------------------------------------+ | | | | | | | | | | | +------------------+ ElementSchedSvc| | | | | | |PriorityScheduling+--------+ | | | | | | |要素| | | | | | | | | 名前=PriBE| | vに対して| | | | +------+ 優先権=2| +---+--------+ + + 次の+| | | | +------------------+ |SchedulingService+----+ | | | | 名前=PriSched|Schedしました。| | | +------------------+ | | |QueueTo| | |スケジュール+----------------+ | | | |AllocationSched|ElementSchedSvc| +----+---------+ |要素+-----------------+ |QueuingService|QueueTo| 名前=BandBE| | 名前、= +になってください。------------+ ユニット=バイト| | |スケジュール| 帯域幅=50| | | +----------------+ +--------------+
Figure 6. Example 2: Complex Hierarchical Scheduler
図6。 例2: 複雑な階層的なスケジューラ
Moore, et al. Standards Track [Page 28] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[28ページ]。
3.11.3. Excess Capacity Scheduler
3.11.3. 過剰生産能力スケジューラ
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.
過剰生産能力スケジューラは1待ち行列あたり2つのスケジューリングパラメタセットを支えるという同様の要件を提供します。 しかしながら、このシナリオでは、理由は少し異なっています。 どんな交通のクラスももう1人の交通のクラスを飢えさせないのを保証するためにそれぞれ1セットの待ち行列に帯域幅限界を割り当ててあると仮定してください。 結果はスケジューリングの機会に値する待ち行列が空である間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.
スケジューラが、スケジューリング決定を差し控えるのを選ぶと、それは、スケジューラを保存しながら、非仕事として反応しています。 定義上スケジューラを保存する仕事がいつもスケジューリングの機会を利用するでしょう、どの待ち行列が修理されているか、そして、過去にどのくらいの帯域幅を消費したかの如何にかかわらず。 このポイントはおもしろい洞察につながります。 スケジューラを保存する非仕事の意味論は1メーターのものに同等です、パケットがプロフィールにあるならスケジューリングの機会をそれに与えて、プロフィールを使い果たしたならスケジューリングの機会を得ないので。 しかしながら、あるメーターで、パケットがプロフィールにあって、パケットであるときに次の動作の振舞いを決定する意味論がプロフィールを使い果たしました。 同様に、非仕事がスケジューラを保存している状態で、スケジューラが、スケジューリングの機会を利用しないのを選ぶと次のスケジューラを決定するための手段があるのが必要です。
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はこの最後のシナリオを例証します。 それは図6と非常に同様に見えます、配分スケジューラとWRRスケジューラの間の結合がFailNextScheduler協会を使用しているのを除いて。 この協会は明らかに、WRRスケジューラが使用される唯一の時が配分スケジューラがスケジューリングの考慮のために拒絶した非空の待ち行列がある時であるという事実を示しています。 図7が不完全であることに注意してください、配分スケジューラとWRRスケジューラに縛られる数個の、より多くの待ち行列が通常あるでしょう、したがって。
Moore, et al. Standards Track [Page 29] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[29ページ]。
+------------+
|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 +---------------------+
+------------+ |QueuingSvc| | 名前=EF| | | | | ++-+---------+ | | | |QueueTo| |スケジュール+--------------+ | | |SchedulingSvc| | | +------------------+ | 名前=WRRSched| | +------+ AllocationSched| +----------+-+-+ | |要素| ^ | | | 名前=BandEF|ElementSchedSvc| | | | ユニット=バイト+--------------------+ | | | | 帯域幅=100| | | | | +------------------+ | | | |NextService| | | +----------------------------------------------+ | | | | | | | NextService| | | | +--------------------------------------------+ | | | | | | | | | | | +------------------+ ElementSchedSvc| | | | | | |AllocationSched+--------+ | | | | | | |要素| | | | | | | | | 名前=BandwidthAF1| | | | | | | | | ユニット=バイト| | vに対して| | | | +------+ 帯域幅=50| +--+----------++++FailNext| | | | +------------------+ |SchedulingService+--------+ | | |QueueTo| 名前=BandSched|スケジューラ| | |スケジュール+------------------+ | | | | | | +---------------------+ | ++-+-----------+ | WRRSchedulingElement| | |QueuingService|QueueTo| =WRRBEを+と命名してください。------------+ | 名前、= +になってください。-----------+ 重さの=30|ElementSchedSvc+--------------+ スケジュール+---------------------+
Figure 7. Example 3: Excess Capacity Scheduler
図7。 例3: 過剰生産能力スケジューラ
Moore, et al. Standards Track [Page 30] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[30ページ]。
3.11.4. Hierarchical CBQ Scheduler
3.11.4. 階層的なCBQスケジューラ
A hierarchical class-based queuing (CBQ) scheduler is the fourth scenario to be considered. In hierarchical CBQ, each queue is allocated a specific bandwidth allocation. Queues are grouped together into a logical scheduler. This logical scheduler in turn has an aggregate bandwidth allocation that equals the sum of the queues it is scheduling. In turn, logical schedulers can be aggregated into higher-level logical schedulers. Changing perspectives and looking top down, the top-most logical scheduler has 100% of the link capacity. This allocation is parceled out to logical schedulers below it such that the sum of the allocations is equal to 100%. These second tier schedulers may in turn parcel out their allocation across a third tier of schedulers and so forth until the lowest tier that parcels out their allocations to specific queues representing relatively fine-grained classes of traffic. The unique aspect of hierarchical CBQ is that when there is insufficient bandwidth for a specific allocation, schedulers higher in the tree are tested to see if another portion of the tree has capacity to spare.
階層的なクラスベースの列を作り(CBQ)スケジューラは4番目の考えられるべきシナリオです。 階層的なCBQでは、特定の帯域幅配分を各待ち行列に割り当てます。 待ち行列は論理的なスケジューラに一緒に分類されます。 この論理的なスケジューラには、それが計画をしている待ち行列の合計と等しい集合帯域幅配分が順番にあります。 順番に、論理的なスケジューラをよりハイレベルの論理的なスケジューラに集めることができます。 見解を変えて、トップダウンに見えて、最も先端の論理的なスケジューラにはリンク容量の100%があります。 それの下の論理的なスケジューラにこの配分を分配するので、配分の合計は100%と等しいです。 これらの2番目の層のスケジューラは、きめ細かに比較的粒状のクラスの交通を表しながら、スケジューラなどの3番目の層の向こう側に彼らの配分を特定の待ち行列に分配する最も低い層まで順番に彼らの配分を分配するかもしれません。 特定の配分、スケジューラのための不十分な木では、より高い帯域幅があるとき木の別の一部で割く容量があるかどうか確認するためにテストされる階層的なCBQのユニークな局面があります。
Figure 8 demonstrates this example with two tiers. The example is split in half because of space constraints, resulting in the CBQTier1 scheduling service instance being represented twice. Note that the total allocation at the top tier is 50 Mb. The voice allocation is 22 Mb. The remaining 23 Mb is split between FTP and Web. Hence, if Web traffic is actually consuming 20 Mb (5 Mb in excess of the allocation). If FTP is consuming 5 Mb, then it is possible for the CBQTier1 scheduler to offer 3Mb of its allocation to Web traffic. However, this is not enough, so the FailNextScheduler association needs to be traversed to determine if there is any excess capacity available from the voice class. If the voice class is only consuming 15 Mb of its 22 Mb allocation, there are sufficient resources to allow the web traffic through. Note that FailNextScheduler is used as the association. The reason is because the CBQTier1 scheduler in fact failed to schedule a packet because of insufficient resources. It is conceivable that a variant of hierarchical CBQ allows a hierarchy for successful scheduling as well. Hence, both associations are necessary.
エイト環は2つの層があるこの例を示します。 二度表されるCBQTier1スケジューリングサービス例をもたらして、例は宇宙規制のために半分に分けられます。 最高層での総配分が50Mbであることに注意してください。 声の配分は22Mbです。 残っている23MbはFTPとウェブの間で分けられます。 したがって、ウェブであるなら、交通は実際に、20Mb(配分を超えた5Mb)を消費することです。 FTPが5Mbを消費しているなら、CBQTier1スケジューラが配分の3Mbをウェブ交通に提供するのは、可能です。 しかしながら、これが十分でないので、FailNextScheduler協会は、何か声のクラスから利用可能な過剰生産能力があるかどうか決定するために横断される必要があります。 声のクラスが22Mbの配分の15Mbしか消費していないなら、ウェブ・トラフィックの通ることを許すことができるくらいのリソースがあります。 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がそれがどう他のすべての物に接続されるかを示しているために二度表されることに注意してください。
Moore, et al. Standards Track [Page 31] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[31ページ]。
+-----------+ 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 |
| +-------------------------------------------+
+-----------+
:
+-----------+ NextService|QueuingSvc+-------------------------------------------+ | 名前=ウェブ| | | |QueueTo+----------------+ ElementSchedSvc| | +-------+ AllocationSched+----------------+ | +-----------Schedされた+|要素| | | | 名前=ウェブ-Alloc| | v| 帯域幅=15| +-----------+-+-+ +----------------+ |SchedulingSvc+| =CBQTier1を+ +と命名してください。----------------+ +-----------+-+-+ |AllocationSched| ElementSchedSvc| ^ +-----------+ |要素+----------------+ | |QueuingSvc|QueueTo| 名前=FTP-Alloc| | | =FTPを+と命名してください。-------+ 帯域幅=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 |
| +------------------------------------------------+
+------------+
+---------------+ FailNextScheduler|SchedulingSvc+---------------------------------------------+ | 名前=CBQTier1| | +-------+-------+ +---------------------+ ElementSchedSvc| | SchedToSched|AllocationScheduling+--------+ | +---------------+ 要素| | | | 名前=LowPri-Alloc| | | | 帯域幅=23| | +に対して---------------------+ +-----+------+-+ |SchedulingSvc| | 名前=CBQTop| +---------------------+ +----------+-+-+ |AllocationScheduling|ElementSchedSvc| ^ +------------+ |要素+----------------+ | |QueuingSvc|QueueTo| 名前、= いてください、-組になってください。| | | =声を+と命名してください。-------+ 帯域幅=22| | | |+をSchedしました。---------------------+ | | | NextService| | +------------------------------------------------+ +------------+
Figure 8. Example 4: Hierarchical CBQ Scheduler
エイト環。 例4: 階層的なCBQスケジューラ
Moore, et al. Standards Track [Page 32] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[32ページ]。
4. The Class Hierarchy
4. クラス階層構造
The following sections present the class and association hierarchies that together comprise the information model for modeling QoS capabilities at the device level.
以下のセクションはモデルQoS能力のために装置レベルでそんなに一緒にいる階層構造が包括するクラスと協会に情報モデルを提示します。
4.1. Associations and Aggregations
4.1. 協会と集合
Associations and aggregations are a means of representing relationships between two (or theoretically more) objects. Dependency, aggregation, and other relationships are modeled as classes containing two (or more) object references. It should be noted that aggregations represent either "whole-part" or "collection" relationships. For example, aggregation can be used to represent the containment relationship between a system and the components that constitute the system.
協会と集合は2個(または、理論的に以上)の物の間の関係を表す手段です。 依存、集合、および他の関係は2つ(さらに)の物の参照箇所を含むクラスとしてモデル化されます。 集合が「全体の部分」か「収集」関係のどちらかを表すことに注意されるべきです。 例えば、システムを構成するシステムとコンポーネントとの封じ込め関係を表すのに集合を使用できます。
Since associations and aggregations are classes, they can benefit from all of the object-oriented features that other non-relationship classes have. For example, they can contain properties and methods, and inheritance can be used to refine their semantics such that they represent more specialized types of their superclasses.
協会と集合がクラスであるので、それらは他の非関係のクラスが持っているオブジェクト指向特徴のすべての利益を得ることができます。 例えば、特性と方法を含むことができて、それらの意味論を洗練するのに遺産は使用できるので、それらは彼らの「スーパー-クラス」の、より専門化しているタイプの代理をします。
Note that an association (or an aggregation) object is treated as an atomic unit (individual instance), even though it relates/collects/is comprised of multiple objects. This is a defining feature of an association (or an aggregation) - although the individual elements that are related to other objects have their own identities, the association (or aggregation) object that is constructed using these objects has its own identity and name as well.
協会(または、集合)物が原子力ユニット(個々の例)として扱われるというメモ、関係づけるか、または集まりますが、/は複数の物から成ります。 これは協会(または、集合)の定義の特徴です--他の物に関連する個々の要素はそれら自身のアイデンティティを持っていますが、これらの物を使用することで組み立てられる協会(または、集合)物はまた、それ自身のアイデンティティと名前を持っています。
It is important to note that associations and aggregations form an inheritance hierarchy that is separate from the class inheritance hierarchy. Although associations and aggregations are typically bi- directional, there is nothing that prevents higher order associations or aggregations from being defined. However, such associations and aggregations are inherently more complex to define, understand, and use. In practice, associations and aggregations of orders higher than binary are rarely used, because of their greatly increased complexity and lack of generality. All of the associations and aggregations defined in this model are binary.
協会と集合がクラス遺産階層構造から別々の遺産階層構造を形成することに注意するのは重要です。 協会と集合は2通常方向上ですが、何もより高いオーダー協会か集合が定義されるのを防ぐものがありません。 しかしながら、そのような協会と集合は、本来定義して、理解して、使用するために、より複雑です。 実際には、バイナリーより高い命令の協会と集合はめったに使用されません、それらの一般性の大いに増加する複雑さと不足のために。 このモデルで定義された協会と集合のすべてが2進です。
Note also that by definition, associations and aggregations cannot be unary.
また、定義上、協会と集合が単項であるはずがないことに注意してください。
Moore, et al. Standards Track [Page 33] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[33ページ]。
Finally, note that associations and aggregations that are defined between two classes do not affect the classes themselves. That is, the addition or deletion of an association or an aggregation does not affect the interfaces of the classes that it is connecting.
最終的に、2つのクラスの間で定義される協会と集合がクラス自体に影響しないことに注意してください。 すなわち、協会か集合の添加か削除がそれが接続しているクラスのインタフェースに影響しません。
4.2. The Structure of the Class Hierarchies
4.2. クラス階層構造の構造
The structure of the class, association, and aggregation class inheritance hierarchies for managing the datapaths of QoS devices is shown, respectively, in Figure 9, Figure 10, and Figure 11. The notation (CIMCORE) identifies a class defined in the CIM Core model. Please refer to [CIM] for the definitions of these classes. Similarly, the notation [PCIME] identifies a class defined in the Policy Core Information Model Extensions document. This model has been influenced by [CIM], and is compatible with the Directory Enabled Networks (DEN) effort.
クラス、協会、およびQoS装置のdatapathsを管理するための集合クラス遺産階層構造の構造は図9、図10、および図11でそれぞれ見せられます。 記法(CIMCORE)はCIM Coreモデルで定義されたクラスを特定します。 これらのクラスの定義について[CIM]を参照してください。 同様に、記法[PCIME]はPolicy Core情報Model Extensionsドキュメントで定義されたクラスを特定します。 このモデルは、[CIM]によって影響を及ぼされて、ディレクトリEnabled Networks(DEN)の努力と互換性があります。
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--ConditioningService
| | | |
| | | +--ClassifierService
| | | | |
| | | | +--ClassifierElement
| | | |
| | | +--MeterService
| | | | |
| | | | +--AverageRateMeterService
| | | | |
| | | | +--EWMAMeterService
| | | | |
| | | | +--TokenBucketMeterService
| | | |
| | | +--MarkerService
| | | | |
| | | | +--PreambleMarkerService
| | | | |
| | | | +--TOSMarkerService
| | | | |
| | | | +--DSCPMarkerService
| | | | |
+--ManagedElement(CIMCORE)| +--ManagedSystemElement(CIMCORE)| | | +--LogicalElement(CIMCORE)| | | +--サービス(CIMCORE)| | | | | +--ConditioningService| | | | | | | +--ClassifierService| | | | | | | | | +--ClassifierElement| | | | | | | +--MeterService| | | | | | | | | +--AverageRateMeterService| | | | | | | | | +--EWMAMeterService| | | | | | | | | +--TokenBucketMeterService| | | | | | | +--MarkerService| | | | | | | | | +--PreambleMarkerService| | | | | | | | | +--TOSMarkerService| | | | | | | | | +--DSCPMarkerService| | | | |
Moore, et al. Standards Track [Page 34] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[34ページ]。
(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
+--ManagedElement(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
Moore, et al. Standards Track [Page 35] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[35ページ]。
(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
+--ManagedElement(CIMCORE)| +--ManagedSystemElement(CIMCORE)| | | +--LogicalElement(CIMCORE)| | | +--サービス(CIMCORE)| +--収集(CIMCORE)| | | +--CollectionOfMSEs(CIMCORE)| | | +--BufferPool| +--SchedulingElement| +--AllocationSchedulingElement| +--WRRSchedulingElement| +--PrioritySchedulingElement| +--BoundedPrioritySchedulingElement
Figure 9. Class Inheritance Hierarchy
図9。 クラス遺産階層構造
Moore, et al. Standards Track [Page 36] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[36ページ]。
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。 協会クラス遺産階層構造
Moore, et al. Standards Track [Page 37] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[37ページ]。
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。 集合クラス遺産階層構造
4.3. Class Definitions
4.3. クラス定義
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関連の機能性について説明するために情報Modelを作るクラスと特性を提示します、ホストを含んでいて。 CIM Coreモデル[CIM]との定義からこれらの定義を得ます。 QoS関連のクラスだけが本書では定義されます。 しかしながら、よく[PCIME]のようにCIM Coreモデルから得られた他のクラスは簡潔に説明されます。 読者が詳細がないかどうか[CIM]において[PCIME]を見るよう奨励されます。 協会と集合はセクション4.4で定義されます。
4.3.1. The Abstract Class ManagedElement
4.3.1. 抽象クラスManagedElement
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のCore Modelで定義された抽象クラスです。 それはCIMで、クラス全員遺産階層構造の根です。 それについて言及する協会における本書では副分類される2があります: 依存とMemberOfCollection。(そのMemberOfCollectionは集合です)。 ManagedElementの特性は、Captionと記述です。 ともに、自由形式ストリングは例示された物について説明することになっていますか? このクラスの完全な定義について[CIM]を参照してください。
Moore, et al. Standards Track [Page 38] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[38ページ]。
4.3.2. The Abstract Class ManagedSystemElement
4.3.2. 抽象クラスManagedSystemElement
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のCore Modelで定義された抽象クラスです。 それはManagedElementのサブクラスです。 ManagedSystemElementはPhysicalElementとLogicalElementクラス階層構造のための基底クラスとして機能します。 LogicalElementは順番にSystemを含む多くの重要なCIM階層構造のための基底クラスです。 Systemのどんな区別可能な部品もこのクラス階層構造における包含の候補です、物理的構成要素(例えば、チップとカード)と論理的なコンポーネント(例えば、ソフトウェアコンポーネント、サービス、および他の物)を含んでいて。
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装置州のモデルで使用されません。 しかしながら、集合Component(別のものに1ManagedSystemElementに関連する)はQoS装置州のモデルのコアを形成する2つの集合のための基底クラスです: QoSSubServiceとQoSConditioningSubService。 同様に、協会ProvidesServiceToElement(ServiceにManagedSystemElementに関連する)はモデルのCalculationServiceForDropper協会のための基底クラスです。
Please refer to [CIM] for the full definition of this class.
このクラスの完全な定義について[CIM]を参照してください。
4.3.3. The Abstract Class LogicalElement
4.3.3. 抽象クラスLogicalElement
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のCore Modelで定義された抽象クラスです。 それは、ManagedSystemElementのクラスのサブクラスであり、管理されたSystemのLogical DevicesとServicesの形のFiles、Processes、またはシステム能力などの論理的なすべての部品のための基底クラスです。 協会のこのクラスが参加するいずれもQoS装置州のモデルに関連していません。 このクラスの完全な定義について[CIM]を参照してください。
4.3.4. The Abstract Class Service
4.3.4. 抽象クラスサービス
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のCore Modelで定義された抽象クラスです。 それは、LogicalElementのクラスのサブクラスであり、Systemの「サービス」か機能性を表すすべての物のための基底クラスです。 Serviceは機能性の実現を構成して、管理するのに使用される汎用物です。 上で述べたようにセクション4.3.2では、このクラスはProvidesServiceToElement協会に参加します。 このクラスの完全な定義について[CIM]を参照してください。
4.3.5. The Class ConditioningService
4.3.5. クラスConditioningService
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 CoreのクラスServiceの具体的なサブクラスです。 それは交通が装置のデータを転送する経路でどう条件とするかを定義する能力を表します。 サブクラス
Moore, et al. Standards Track [Page 39] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[39ページ]。
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は行われる調節の特定のタイプを定義します。 調節の6つの基本的なタイプが本書では定義されます。 これらはクラシファイア、1メーター、マーカー、点滴器、待ち行列、およびスケジューラによって実行されたサービスです。 他の、そして、より高度なタイプの調節は将来のドキュメントで定義されるかもしれません。
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.
2つの協会がConditioningServiceが参加するQoSの用法に重要です--QoSConditioningSubServiceとNextService。 QoSConditioningSubServiceは、特定の装置でそのQoSサービスの基礎となる特定の調節の機能性について説明するために特定のQoSサービス(AFなどの)へのConditioningServicesに集めます。 NextServiceは異なった交通の流れのためのその後の調節サービスを示します。
The class definition is as follows:
クラス定義は以下の通りです:
NAME ConditioningService
DESCRIPTION A concrete class to define how traffic
is conditioned in the data forwarding
path of a host or network device.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)
交通がホストかネットワーク装置のデータ推進経路でどう条件とするかを定義するNAME ConditioningService記述A具象クラス。 サービスタイプコンクリートの特性から、派生します。(なにも)
4.3.6. The Class ClassifierService
4.3.6. クラスClassifierService
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.
Classifierの概念は[DSMODEL]から来ます。 ClassifierServiceは装置のイングレスか出口のインタフェースに論理的な実体を表して、ただ一つの入力ストリームを取って、それを1つ以上の出力ストリームに分類する具象クラスです。パケットコンテンツに基づいているか、またはことによるとパケットに関連している他の属性に基づくパケットを選択する1セットのフィルタはソーティングをします。 各出力ストリームは特定のフィルタを合わせるという結果です。
The representation of classifiers in QDDIM is closely related to that presented in [DSMIB] and [DSMODEL]. Rather than being linked directly to its FilterLists, a classifier is modeled here as an aggregation of ClassifierElements. Each of these ClassifierElements is then linked to a single FilterList, by the association ClassifierElementUsesFilterList.
QDDIMのクラシファイアの表現は密接に[DSMIB]と[DSMODEL]に提示されたそれに関連します。 むしろ、クラシファイアは直接FilterListsにリンクされるよりClassifierElementsの集合としてここでモデル化されます。 そして、それぞれのこれらのClassifierElementsは協会ClassifierElementUsesFilterListによって独身のFilterListにリンクされます。
Moore, et al. Standards Track [Page 40] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[40ページ]。
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.
ClassifierはそれをQoSServiceに集めることができる(QoSConditioningSubService集合を使用して)ように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)
入力交通ストリームが1個以上のフィルタを使用することでどう分類されるかを複数の出力ストリームに説明するNAME ClassifierService記述A具象クラス。 ConditioningServiceタイプコンクリートの特性から、派生します。(なにも)
4.3.7. The Class ClassifierElement
4.3.7. クラスClassifierElement
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に入るパケットの流れからパケットを選択するための1セットの評価基準を指定するFilterListと、次のConditioningServiceで間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(1E)、(2E)、および(3E)に集めます。
Moore, et al. Standards Track [Page 41] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[41ページ]。
2. ClassifierElements (E1) and (E3) associations to FilterLists (F1)
and (F3) respectively using the ClassifierElementUsesFilterList
association.
2. FilterLists(F1)とそれぞれClassifierElementUsesFilterList協会を使用する(F3)へのClassifierElements(1E)と(3E)の協会。
3. (E1) & (E3) are associated with Meters (M1) and (M3) through their
respective NextServiceAfterClassifierElement associations.
3. (1E) (E3)はそれらのそれぞれのNextServiceAfterClassifierElement協会を通したMeters(M1)と(M3)に関連しています。
4. (E2) is associated with ClassifierService (C2) through its
NextServiceAfterClassifierElement association.
4. (2E) NextServiceAfterClassifierElement協会を通してClassifierService(C2)に関連づけられます。
5. ClassifierService (C2) aggregates ClassifierElements (E4) and (E5)
with relative ClassifierOrder values of 1 and 2.
5. ClassifierService(C2)は1と2の相対的なClassifierOrder値でClassifierElements(4E)と(5E)に集めます。
6. ClassifierElements (E4) and (E5) have associations to FilterLists
(F4) and (F5) respectively using the
ClassifierElementUsesFilterList association.
6. ClassifierElements(4E)と(5E)は、それぞれClassifierElementUsesFilterList協会を使用することでFilterLists(F4)と(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)
クラシファイアがパケットが次の特定の調節サービスに送るのを選択するフィルタを使用する過程を表すNAME ClassifierElement記述A具象クラス。 ClassifierServiceタイプコンクリートの特性から、派生します。(なにも)
4.3.8. The Class MeterService
4.3.8. クラスMeterService
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.
これはネットワークトラフィックの計量を表す具象クラスです。 計量は交通の流れのパケットの到着時間をモニターして、プレ確立した交通プロフィールに関してそれぞれのパケットの順応のレベルを決定する機能です。 1メーターには、従って非の従う交通へ異なったConditioningServicesを呼び出す能力があります。 1個のメーターを残す交通は、別の調節要素にパケットを発送することによって、さらに条件とするかもしれません(例えば、落とされるか、または列に並ばせられます)。 計量の詳しい情報に関して[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
このクラスは、異なったタイプのメーターを定義するための基底クラスです。 そういうものとして、それはすべてのメーターサブクラスが共有する通有性を含んでいます。 それがそれをQoSServiceに集めることができるようにConditioningServiceとしてモデル化される、(QoSConditioningSubServiceを使用すること。
Moore, et al. Standards Track [Page 42] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[42ページ]。
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.
協会)、それを示すために、機能性はそのQoSサービスの基礎となります。 また、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タイプコンクリートの特性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の特性は唯一の道にメーターのタイプを特定するのを提供するでしょう。
4.3.8.1. The Property MeterType
4.3.8.1. 特性の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つでなく、それはSHOULDです。まるで値'1'を(他)であるのに持っているかのように、解釈されてください。
4.3.8.2. The Property OtherMeterType
4.3.8.2. 特性のOtherMeterType
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と等しいときに、それは使用されています。
Moore, et al. Standards Track [Page 43] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[43ページ]。
4.3.8.3. The Property ConformanceLevels
4.3.8.3. 特性のConformanceLevels
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と等しいです。
4.3.9. The Class AverageRateMeterService
4.3.9. クラスAverageRateMeterService
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].
Average Rate Meterは、これが簡単なメーターを表すMeterServiceの具体的なサブクラスであると呼びました。 このタイプのメーターはパケットが指定された時間それに提出される平均相場を測定します。 それらの平均到着率がメーターの指定された測定レートを超えていないなら、パケットはconformantと定義されます。 指定された測定レートを超えているどんなパケットも、非の従うことであることのようになるように定義されます。 詳しくは、[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記述A具象クラスが従うか、非従うとして交通を分類して、パケットの到着が平均した到着を引き起こすかどうかによって、予定された値を超えていると評価してください。 MeterServiceタイプコンクリートの特性AverageRate、DeltaIntervalから、派生します。
4.3.9.1. The Property AverageRate
4.3.9.1. 特性のAverageRate
This is an unsigned 32-bit integer that defines the rate used to determine whether admitted packets are in conformance or not. The value is specified in kilobits per second.
これは認められたパケットが順応中であるかを決定するのに使用されるレートを定義する無記名の32ビットの整数です。 値は1秒あたりのキロビットで指定されます。
4.3.9.2. The Property DeltaInterval
4.3.9.2. 特性のDeltaInterval
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ビットの整数です。 値はマイクロセカンドのときに指定されます。
4.3.10. The Class EWMAMeterService
4.3.10. クラスEWMAMeterService
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
これは指数加重移動平均メーターを表すMeterServiceのクラスの具体的なサブクラスです。 このメーターは入って来るパケットのレートを測定する簡単なローパスフィルタです。
Moore, et al. Standards Track [Page 44] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[44ページ]。
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.
小さくて、固定された標本抽出間隔の間。 事前に定義された限界の上に平均相場を押すどんな認められたパケットも、非の従うことであることのようになるように定義されます。 詳しい情報に関して[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
小さい固定標本抽出間隔の平均到着率がパケットの到着で予定された値を超えているかどうかによって、従うか、非従うとして認められた交通を分類するNAME EWMAMeterService記述A具象クラス。 タイプコンクリートの特性AverageRate(DeltaInterval)が獲得するMeterServiceから、派生します。
4.3.10.1. The Property AverageRate
4.3.10.1. 特性のAverageRate
This property is an unsigned 32-bit integer that defines the average rate against which the sampled arrival rate of packets should be measured. Any packet that causes the sampled rate to exceed this rate is deemed non-conforming. The value is specified in kilobits per second.
この特性はパケットの抽出された到着率が測定されるべきである平均相場を定義する無記名の32ビットの整数です。 抽出されたレートがこのレートを超えているどんなパケットも非従うと考えられます。 値は1秒あたりのキロビットで指定されます。
4.3.10.2. The Property DeltaInterval
4.3.10.2. 特性のDeltaInterval
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.
値はマイクロセカンドのときに指定されます。
4.3.10.3. The Property Gain
4.3.10.3. 特性の利得
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の時定数値を表します。
Moore, et al. Standards Track [Page 45] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[45ページ]。
4.3.11. The Class TokenBucketMeterService
4.3.11. クラスTokenBucketMeterService
This is a concrete subclass of the MeterService class that represents the metering of network traffic using a token bucket meter. Two types of token bucket meters are defined using this class - a simple, two-parameter bucket meter, and a multi-stage meter.
これは象徴バケットメーターを使用することでネットワークトラフィックの計量を表すMeterServiceのクラスの具体的なサブクラスです。 2つのタイプの象徴バケットメーターはこのクラスを使用することで定義されます--簡単で、2パラメタのバケットメーター、およびマルチステージメーター。
A simple token bucket usually has two parameters, an average token
rate and a burst size, and has two conformance levels: "conforming"
and "non-conforming". This class also defines an excess burst size,
which enables the meter to have three conformance levels
("conforming", "partially conforming", and "non-conforming"). In
this case, packets that exceed the excess burst size are deemed non-
conforming, while packets that exceed the smaller burst size but are
less than the excess burst size are deemed partially conforming.
Operation of these meters is described in [DSMODEL].
簡単な象徴バケツは、通常、2つのパラメタ、平均した象徴レート、および放出量を持っていて、2つの順応レベルを持っています: 「従うこと」と「非の従うこと」。 また、このクラスは余分な放出量を定義します。(それは、メーターが(「従うこと」と、「部分的に従う」、「非従う」)であるのに3つの順応レベルを持っているのを可能にします)。 この場合、余分な放出量を超えているパケットは非従うと考えられます、よりわずかな放出量を超えていますが、余分な放出量以下であるパケットは部分的に従うと考えられますが。 これらのメーターの操作は[DSMODEL]で説明されます。
The class definition is as follows:
クラス定義は以下の通りです:
NAME TokenBucketMeterService
DESCRIPTION A concrete class classifying admitted
traffic with respect to a token bucket.
Either two or three levels of
conformance can be defined.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize
象徴バケツに関して認められた交通を分類するNAME TokenBucketMeterService記述A具象クラス。 2か3つのレベルの順応を定義できます。 MeterServiceタイプコンクリートの特性AverageRate、PeakRate、BurstSize、ExcessBurstSizeから、派生します。
4.3.11.1. The Property AverageRate
4.3.11.1. 特性のAverageRate
This property is an unsigned 32-bit integer that specifies the committed rate of the meter. The value is expressed in kilobits per second.
この特性はメーターの遂行されたレートを指定する無記名の32ビットの整数です。 値は1秒あたりのキロビットで言い表されます。
4.3.11.2. The Property PeakRate
4.3.11.2. 特性のPeakRate
This property is an unsigned 32-bit integer that specifies the peak rate of the meter. The value is expressed in kilobits per second.
この特性はメーターのピークレートを指定する無記名の32ビットの整数です。 値は1秒あたりのキロビットで言い表されます。
4.3.11.3. The Property BurstSize
4.3.11.3. 特性のBurstSize
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ビットの整数です。 値はキロバイトで言い表されます。
Moore, et al. Standards Track [Page 46] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[46ページ]。
4.3.11.4. The Property ExcessBurstSize
4.3.11.4. 特性のExcessBurstSize
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ビットの整数です。 値はキロバイトで言い表されます。
4.3.12. The Class MarkerService
4.3.12. クラスMarkerService
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.
MarkerServiceは、機能性がそのQoSサービスの基礎となるのを示すためにそれをQoSService(QoSConditioningSubService協会を使用する)に集めることができるように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記述A具象クラス。 パケットは、それらが次に受ける調節を制御するために著しいです。 ConditioningServiceタイプコンクリートの特性から、派生します。(なにも)
4.3.13. The Class PreambleMarkerService
4.3.13. クラスPreambleMarkerService
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はパケット序文にこれらの結果を格納する能力をモデル化します。 例
Moore, et al. Standards Track [Page 47] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[47ページ]。
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は「<タイプ>、<値の>」を形式のパケットの序文のaの2部分のストリングに追加します。 セクション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[ ]
交通調節の節約を表すNAME PreambleMarkerService記述A具象クラスがパケット序文をもたらします。 MarkerServiceタイプコンクリートの特性FilterItemListから、派生します。[ ]
4.3.13.1. The Multi-valued Property FilterItemList
4.3.13.1. マルチ評価された特性の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を見てください。
4.3.14. The Class ToSMarkerService
4.3.14. クラスToSMarkerService
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
(ToS)がIPv4パケットのヘッダーで規定値でさばくサービスのタイプをマークする過程を表すNAME ToSMarkerService記述A具象クラス。 パケットは、それらが次に受ける調節を制御するために著しいです。 MarkerServiceタイプコンクリートの特性ToSValueから、派生します。
Moore, et al. Standards Track [Page 48] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[48ページ]。
4.3.14.1. The Property ToSValue
4.3.14.1. 特性の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.
この特性は無記名の8ビットの整数です、(ToS)がIPv4パケットのヘッダーでさばくサービスのタイプをマークするのに使用されるために値を表して。 ToS分野が完全な八重奏になるように定義されるので、この特性のための範囲は0です。255. しかしながら、いくつかの実現が、ToS分野の最も少ないオーダービットがいつも'0'であると必要とします。 その結果、そのような実現は変なTosValueを支持できません。
4.3.15. The Class DSCPMarkerService
4.3.15. クラスDSCPMarkerService
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.
これはIPv4とIPv6パケットのヘッダーのDS分野の中に微分されたサービスcodepoint(DSCP)のマークを表す具象クラスです、[R2474]で定義されるように。 一般的な習慣に続いて、分野に書かれている値は無記名の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
パケットのDSCP分野に規定値を付ける過程を表すNAME DSCPMarkerService記述A具象クラス。 パケットは、それらが次に受ける調節を制御するために著しいです。 MarkerServiceタイプコンクリートの特性DSCPValueから、派生します。
4.3.15.1. The Property DSCPValue
4.3.15.1. 特性の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.
この特性は無記名の8ビットの整数です、IPv4かIPv6パケットのヘッダーのDS分野の中でDSCPをマークするのに使用されるために値を表して。 DSCPが6ビットから成るので、この特性のための値は範囲0に制限されます。63. DSCPが著しいときに、噛み付かれた残っている2はDS分野で変わりがないままにされます。
4.3.16. The Class 8021QMarkerService
4.3.16. クラス8021QMarkerService
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ビットの整数として表されます。
Moore, et al. Standards Track [Page 49] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoS装置Datapathインフォメーションモデル2004年1月にRFC3670を追跡します[49ページ]。
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対応することのフレームのPriority分野を示す過程を表すNAME 8021QMarkerService記述A具象クラス。 フレームは、それらが次に受ける調節を制御するために著しいです。 MarkerServiceタイプコンクリートの特性PriorityValueから、派生します。
4.3.16.1. The Property PriorityValue
4.3.16.1. 特性のPriorityValue
This property is an unsigned 8-bit integer, representing a value to be used for marking the Priority field in the 802.1Q header. Since the Priority field consists of 3 bits, the values for this property are limited to the range 0..7. When the Priority field is marked, the remaining bits in its octet are left unchanged.
この特性は無記名の8ビットの整数です、802.1QヘッダーのPriority分野を示すのに使用されるために値を表して。 Priority分野が3ビットから成るので、この特性のための値は範囲0に制限されます。7. Priority分野が著しいときに、八重奏における残っているビットは変わりがないままにされます。
4.3.17. The Class DropperService
4.3.17. クラスDropperService
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]からAbsoluteドロッパーズとAlgorithmicドロッパーズの両方を取り囲むことに注意してください。
DropperService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService object that acts on any remaining traffic that is not dropped.
DropperServiceは、機能性がそのQoSサービスの基礎となるのを示すためにそれをQoSService(QoSConditioningSubService協会を使用する)に集めることができるように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協会のチェーンに「右方へ」続くことによって、特定されます。
Moore, et al. Standards Track [Page 50] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[50ページ]。
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コンクリート基底クラス。 ConditioningServiceタイプコンクリートの特性DropperType、OtherDropperType、DropFromから、派生します。
Note: The DropperType property and the DropperService subclasses
provide similar information. The DropperType property is defined for
query purposes, as well as for those cases where a subclass of
DropperService is not needed to model a particular type of dropper.
For example, the Absolute Dropper defined in [DSMODEL] is modeled as
an instance of the DropperService class with its DropperType set to
'4' ("Absolute Dropper").
以下に注意してください。 DropperTypeの特性とDropperServiceサブクラスは同様の情報を提供します。 DropperTypeの特性は質問目的のために定義されます、よくDropperServiceのサブクラスが特定のタイプの点滴器をモデル化するのに必要でないそれらのケースのように。 例えば、DropperTypeがあるDropperServiceのクラスのインスタンスが'4'(「絶対点滴器」)にセットしたので、[DSMODEL]で定義されたAbsolute Dropperはモデル化されます。
4.3.17.1. The Property DropperType
4.3.17.1. 特性のDropperType
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--HeadTail4--絶対点滴器
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つでなく、それはSHOULDです。まるで値'1'を(他)であるのに持っているかのように、解釈されてください。
4.3.17.2. The Property OtherDropperType
4.3.17.2. 特性のOtherDropperType
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'(すなわち、Other)であるときに、点滴器のタイプの名前はこの所有地に現れます。
4.3.17.3. The Property DropFrom
4.3.17.3. 特性のDropFrom
This is an unsigned 16-bit integer enumeration that indicates the point in the associated queue from which packets should be dropped. Defined enumeration values are:
これはパケットが下げられるべきである関連待ち行列でポイントを示す未署名の16ビットの整数列挙です。 定義された列挙値は以下の通りです。
o unknown(0)
o head(1)
o tail(2)
o 未知の(0)oヘッド(1)oテール(2)
Moore, et al. Standards Track [Page 51] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[51ページ]。
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つの値の1つでないなら、パケットは関連待ち行列におけるどんな位置からも下げられるかもしれません。
4.3.18. The Class HeadTailDropperService
4.3.18. クラスHeadTailDropperService
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タイプコンクリートの特性QueueThresholdから、派生します。
4.3.18.1. The Property QueueThreshold
4.3.18.1. 特性の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ビットの整数です。 テール点滴器に関しては、すべての新たに到着しているトラフィックが下げられます。 ヘッド点滴器に関しては、待ち行列の前部のパケットは、新しいパケットに場所を開けるために下げられます。(パケットは終わりに加えられます)。 値はバイトで言い表されます。
4.3.19. The Class REDDropperService
4.3.19. クラスREDDropperService
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.
これはRandom Early Detection(RED)アルゴリズムを使用することでネットワークトラフィックを下げる能力を表す具象クラスです。 このアルゴリズムは[RED]で説明されます。 REDアルゴリズムの目的は混雑(混雑を管理することと対照的に)を避けることです。 満たす待ち行列を待っていて、次に、多くのパケットを下げることの代わりに、REDは、平均した待ち行列の深さをモニターすることによって、働いています。 待ち行列の深さが最小の敷居を超えているとき、パケットは手当たりしだいに捨てられます。 これらの破棄で、TCPはパケット破棄を経験したそれらの接続のために通信速度を遅くします。 他のTCP接続はこれらの破棄で影響を受けません。 点滴器に関する詳しい情報に関して[DSMODEL]を見てください。
Moore, et al. Standards Track [Page 52] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[52ページ]。
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協会に続いて、次に、待ち行列が(s)であることがわかる見られるCalculationBasedOnQueue協会に続くことによって、見つけられます。
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記述A具象クラスは、以前はよくREDアルゴリズムを使用することで(または、異形の1つ)低下すると説明していました。 DropperServiceタイプコンクリートの特性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があります。(diffServRandomDropTableは無作為の低下の一般的なカテゴリを表します)。 (REDは1つのタイプの無作為の低下ですが、REDと異なった無作為の低下のタイプもあります。) REDDropperServiceのクラスはテーブルの特にREDアルゴリズムに適用されるコラムに対応します。
4.3.19.1. The Property MinQueueThreshold
4.3.19.1. 特性のMinQueueThreshold
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の特性によって特定されます。 低下確率関数のスロープはStart/StopProbabilityの特性によって説明されます。
4.3.19.2. The Property MaxQueueThreshold
4.3.19.2. 特性のMaxQueueThreshold
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の特性によって特定されます。
4.3.19.3. The Property ThresholdUnits
4.3.19.3. 特性の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ビットの整数列挙です。 定義された列挙値は以下の通りです。
Moore, et al. Standards Track [Page 53] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[53ページ]。
o bytes(1)
o packets(2)
o バイト(1)oパケット(2)
Note: if the value of ThresholdUnits is not one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes).
以下に注意してください。 ThresholdUnitsの値はこれらの2つの値の1つでなく、それはSHOULDです。まるでそれには値'1'(バイト)があるかのように、解釈されてください。
4.3.19.4. The Property StartProbability
4.3.19.4. 特性のStartProbability
This is an unsigned 32-bit integer; in conjunction with the StopProbability property, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length.
これは未署名の32ビットの整数です。 StopProbabilityの特性に関連して、それは低下確率関数のスロープを定義します。 この機能はパケットが待ち行列の長さの関数として下げられるのを受けることがあるレートを決定します。
This property expresses a drop probability in drops per thousand packets. For example, the value 100 indicates a drop probability of 100 per 1000 packets, that is, 10%. Min and max values are 0 to 1000.
この特性は1,000のパケットあたりの低下で低下確率を表します。 例えば、値100はすなわち、1000のパケットあたり100、10%の低下確率を示します。 分と最大値は、0〜1000です。
4.3.19.5. The Property StopProbability
4.3.19.5. 特性のStopProbability
This is an unsigned 32-bit integer; in conjunction with the StartProbability property, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length.
これは未署名の32ビットの整数です。 StartProbabilityの特性に関連して、それは低下確率関数のスロープを定義します。 この機能はパケットが待ち行列の長さの関数として下げられるのを受けることがあるレートを決定します。
This property expresses a drop probability in drops per thousand packets. For example, the value 100 indicates a drop probability of 100 per 1000 packets, that is, 10%. Min and max values are 0 to 1000.
この特性は1,000のパケットあたりの低下で低下確率を表します。 例えば、値100はすなわち、1000のパケットあたり100、10%の低下確率を示します。 分と最大値は、0〜1000です。
4.3.20. The Class QueuingService
4.3.20. クラスQueuingService
This is a concrete class that represents the ability to queue network traffic, and to specify the characteristics for determining long-term congestion. Please see [DSMODEL] for more information about queuing functionality.
これはネットワークトラフィックを列に並ばせて、長期の混雑を決定するのに特性を指定する能力を表す具象クラスです。 機能性を列に並ばせることに関する詳しい情報に関して[DSMODEL]を見てください。
QueuingService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service.
QueuingServiceは、機能性がそのQoSサービスの基礎となるのを示すためにそれをQoSService(QoSConditioningSubService協会を使用する)に集めることができるようにConditioningServiceとしてモデル化されます。
Moore, et al. Standards Track [Page 54] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[54ページ]。
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記述A具象クラス。 ConditioningServiceタイプコンクリートの特性CurrentQueueDepth、DepthUnitsから、派生します。
4.3.20.1. The Property CurrentQueueDepth
4.3.20.1. 特性のCurrentQueueDepth
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ビットの整数です。(その整数はこの1つの待ち行列の現在の深さを表す(書き込み禁止)ゲージとして機能します)。 この値はDropThresholdCalculationServiceによる予期していなかった振舞いを診断するのにおいて重要であるかもしれません。
4.3.20.2. The Property DepthUnits
4.3.20.2. 特性のDepthUnits
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)oパケット(2)
Note: if the value of DepthUnits is not one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes). The
以下に注意してください。 DepthUnitsの値はこれらの2つの値の1つでなく、それはSHOULDです。まるでそれには値'1'(バイト)があるかのように、解釈されてください。 The
4.3.21. Class PacketSchedulingService
4.3.21. クラスPacketSchedulingService
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
PacketSchedulingServiceは、機能性がそのQoSサービスの基礎となるのを示すためにそれをQoSService(QoSConditioningSubService協会を使用する)に集めることができるようにConditioningServiceとしてモデル化されます。 それは参加します。
Moore, et al. Standards Track [Page 55] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[55ページ]。
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記述A具象クラスは、以前はよくパケットがいつ待ち行列から移されて、出力インタフェースに送られるべきであるかを決定していました。 ConditioningServiceタイプコンクリートの特性SchedulerType、OtherSchedulerTypeから、派生します。
4.3.21.1. The Property SchedulerType
4.3.21.1. 特性のSchedulerType
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--先入れ先出し法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つの値の1つでなく、それはSHOULDです。まるでそれには値'2'(先入れ先出し法)があるかのように、解釈されてください。
4.3.21.2. The Property OtherSchedulerType
4.3.21.2. 特性のOtherSchedulerType
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(すなわち、Other)であるときに、スケジューラのタイプはこの所有地で指定されます。
4.3.22. The Class NonWorkConservingSchedulingService
4.3.22. クラスNonWorkConservingSchedulingService
This class does not add any properties beyond those it inherits from its superclass, PacketSchedulingService. It does, however, participate in one additional association, FailNextScheduler.
このクラスはそれが「スーパー-クラス」、PacketSchedulingServiceから引き継ぐものを超えた少しの特性も加えません。 しかしながら、それは1つの追加協会、FailNextSchedulerに参加します。
Moore, et al. Standards Track [Page 56] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[56ページ]。
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タイプコンクリートの特性から、派生します。(なにも)
4.3.23. The Class QoSService
4.3.23. クラスQoSService
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.
これは1セットの連携サブサービスとして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サービスを組み込む必要があったので、まず最初に、それは役立ちます。 2番目に、それは異なったタイプの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.
例えば、Gold Serviceは2つのQoSサービスに一緒に集めるQoSServiceと定義されるかもしれません。 クラスDiffServServiceのインスタンス、非常に高い要求パケット(DiffServService自身のインスタンスで、表される)の整備点検のためのもの、およびAFServiceのインスタンスによって表されたパケットの大部分に与えられたDiffServServiceのサブクラスであるサービスのためのもの時までにそれぞれのこれらのQoSサービスを表すことができました。 そして、高需要DiffServServiceインスタンスは、それが、どのトラフィックがそうするのに申し込むかを示す必要なクラシファイア、請負境界線のための適切なメーター、パケットでEF PHBをマークするマーカー、および列を作り関連の調節サービスを一緒に集めるのにQoSConditioningSubService集合を使用するでしょう。 また、AFServiceインスタンスは、クラシファイア、メーター、パケットで異なったAF PHBsをマークするのに使用される数個のマーカー、およびパケット処理を提供するのに必要である列を作り関連の調節サービスに集めるのに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は一種のServiceとしてモデル化されます。(Serviceは、異なったタイプの流れのために必要な調節が特性であると実装する1セットのサブサービスを定義するのにアンカー・ポイントとして使用されます)。 それは、このサービスを実装するのに使用されるよう調節サービスの特定のタイプに指示するでしょう。
Moore, et al. Standards Track [Page 57] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[57ページ]。
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記述A具象クラスは以前はよくサービスのQoSサービスかセットを表していました、ネットワーク管理者によって定義されるように。 サービスタイプコンクリートの特性から、派生します。(なにも)
4.3.24. The Class DiffServService
4.3.24. クラスDiffServService
This is a concrete class representing the use of standard or custom DiffServ services to implement a (higher-level) QoS service. Note that a DiffServService object may be just one of a set of coordinated QoSSubServices objects that together implement a higher-level QoS service.
これは(よりハイレベル)のQoSがサービスであると実装するために標準の、または、カスタムのDiffServサービスの使用を表す具象クラスです。 DiffServServiceオブジェクトがただよりハイレベルのQoSがサービスを提供するそんなに一緒にいるオブジェクトが実装する連携QoSSubServicesの1セットの1つであるかもしれないことに注意してください。
DiffServService is modeled as a subclass of QoSService. This enables it to be related to a higher-level QoS service via QoSSubService, as well as to specific ConditioningService objects (e.g., metering, dropping, queuing, and others) via QoSConditioningSubService.
DiffServServiceはQoSServiceのサブクラスとしてモデル化されます。 これは、それがQoSSubServiceを通して、よりハイレベルのQoSサービスに関連するのを可能にします、よくQoSConditioningSubServiceを通した特定のConditioningServiceオブジェクト(例えば、計量、低下、列を作り、および他のもの)のように。
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具象クラスは以前はよく特定のPer Hop Behaviorに関連しているDiffServサービスを表していました。 QoSServiceタイプコンクリートの特性PHBIDから、派生します。
4.3.24.1. The Property PHBID
4.3.24.1. 特性の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ビットの符号のない整数かファミリーである、ホップの振舞い単位で。(符号のない整数はホップの振舞いあたり1つの事項を特定します)。 ここの値は[R3140]で定義されるようにPer Hop Behavior Identification Codeです。 これらの識別コードが定義されるようにコードがPHBsのために彼らの構造の一部として示すお勧めのデフォルトを使用することに注意してください。 これらの値はたぶんマーカーで使用される実価と異なっているでしょう、著しい値がドメイン依存する値であるので。 QoS Serviceを参考書類に結ぶ、相互ドメインコーディネート、および操作において、サービスに関連しているPHB Identification Codeを示す能力は役立っています。
Moore, et al. Standards Track [Page 58] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[58ページ]。
4.3.25. The Class AFService
4.3.25. クラスAFService
This is a concrete class that represents a specialization of the general concept of forwarding network traffic, by adding specific semantics that characterize the operation of the Assured Forwarding (AF) Service ([R2597]).
これは推進ネットワークトラフィックに関する一般概念の専門化を表す具象クラスです、Assured Forwarding(AF)サービス([R2597])の操作を特徴付ける特定の意味論を加えることによって。
[R2597] defines four different AF classes, to represent four different treatments of traffic. A different amount of forwarding resources, such as buffer space and bandwidth, are allocated to each AF class. Within each AF class, IP packets are marked with one of three possible drop precedence values. The drop precedence of a packet determines the relative importance of that packet compared to other packets within the same AF class, if congestion occurs. A congested interface will try to avoid dropping packets marked with a lower drop precedence value, by instead discarding packets marked with a higher drop precedence value.
[R2597]は、トラフィックの4つの異なった処理を表すために4つの異なったAFのクラスを定義します。 バッファ領域や帯域幅などの異なった量の推進リソースをそれぞれのAFのクラスに割り当てます。 それぞれのAFのクラスの中では、IPパケットは3つの可能な低下先行値の1つでマークされます。 同じ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]がそんなに一緒にいる12DSCPsを定義するというメモはAF Per Hop Behavior(PHB)グループを代表します。 実装は自由にこれを広げることができます(例えば、より多くのクラスを加えてください、そして、先行を下げてください)。
The AFService class is modeled as a specialization of DiffServService, which is in turn a specialization of QoSService. This enables it to be related to higher-level QoS services, as well as to lower-level conditioning sub-services (e.g., classification, metering, dropping, queuing, and others).
AFServiceのクラスはDiffServServiceの専門化としてモデル化されて、専門化は順番にどれのものであるか。QoSService。 これは、それが、よりハイレベルのQoSサービスに関連するのを可能にします、よく低レベル調節サブサービス(例えば、分類、計量、低下、列を作り、および他のもの)のように。
The class definition is as follows:
クラス定義は以下の通りです:
NAME AFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding, using the AF
PHB Group.
DERIVED FROM DiffServService
TYPE Concrete
PROPERTIES ClassNumber, DropperNumber
AF PHB Groupを使用して、トラフィック推進に影響するのに利用される差別化されたサービスの共通する特徴について説明するためのNAME AFService記述A具象クラス。 DiffServServiceタイプコンクリートの特性ClassNumber、DropperNumberから、派生します。
4.3.25.1. The Property ClassNumber
4.3.25.1. 特性のClassNumber
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集合を使用することで集められたインスタンスの中では、1SHOULDがAFServiceインスタンスのClassNumberと同じくらい多くの異なった値でマーカーを見つけます。
Moore, et al. Standards Track [Page 59] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[59ページ]。
4.3.25.2. The Property DropperNumber
4.3.25.2. 特性のDropperNumber
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ビットの符号のない整数です。 低下先行値の数は数のPER AF CLASSです。 対応する点滴器はQoSConditioningSubService集合で集められた調節サービスの収集で見つけられるでしょう。
4.3.26. The Class FlowService
4.3.26. クラスFlowService
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.
このクラスは特定のmicroflowをサポートするサービスを表します。 microflowはストリングで評価された特性のFlowIDによって特定されます。 いくつかの実装では、このクラスのインスタンスは実装のフロー・テーブルのエントリーに対応しています。
The class definition is as follows:
クラス定義は以下の通りです:
NAME FlowService
DESCRIPTION A concrete class representing a
microflow.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES FlowID
microflowを表すNAME FlowService記述A具象クラス。 QoSServiceタイプコンクリートの特性FlowIDから、派生します。
4.3.26.1. The Property FlowID
4.3.26.1. 特性のFlowID
This property is a string containing an identifier for a microflow.
この特性はmicroflowのための識別子を含むストリングです。
4.3.27. The Class DropThresholdCalculationService
4.3.27. クラスDropThresholdCalculationService
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点滴器を代表してこの計算をします。
Moore, et al. Standards Track [Page 60] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[60ページ]。
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記述A具象クラス。 後者はこのService、どう作動するかを説明して、およびその必要なパラメタの特性です。 サービスタイプコンクリートの特性SmoothingWeight、TimeIntervalから、派生します。
4.3.27.1. The Property SmoothingWeight
4.3.27.1. 特性の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:
この特性は、32ビットの符号のない整数、及んでいる0〜10万です--1000第年代に、指定されます。 それは現在の平均した待ち行列の深さの計算に影響する際に過去の歴史の重さを定義します。 現在の待ち行列深さ計算は歴史的な平均に要素、および1として要素としてのその逆を引いてこの価値の逆を使用します。 計算は形を取ります:
average = (old_average*(1-inverse of SmoothingWeight))
+ (current_queue_depth*inverse of SmoothingWeight)
平均は+と等しいです(古い_平均*(SmoothingWeightの1逆))。(SmoothingWeightの現在の_待ち行列_深さ*逆)
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です。
4.3.27.2. The Property TimeInterval
4.3.27.2. 特性のTimeInterval
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は適切な間隔を決定するかもしれません。
4.3.28. The Abstract Class FilterEntryBase
4.3.28. 抽象クラスFilterEntryBase
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論理演算子の特性を含んでいます(容易に「NOT」にマッチ情報はサブクラスの1つのインスタンスで指定しました)。
Moore, et al. Standards Track [Page 61] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[61ページ]。
Because FilterEntryBase has general applicability, it is defined in [PCIME]. See [PCIME] for the definition of this class.
FilterEntryBaseには一般的な適用性があるので、それは[PCIME]で定義されます。 このクラスの定義に関して[PCIME]を見てください。
4.3.29. The Class IPHeaderFilter
4.3.29. クラスIPHeaderFilter
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]を見てください。
4.3.30. The Class 8021Filter
4.3.30. クラス8021Filter
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、802.1がIDについて議定書の中で述べるときまた、MACが扱う目的地、優先権、およびVLANに識別子分野を許容します。
See [PCIME] for the definition of this class.
このクラスの定義に関して[PCIME]を見てください。
4.3.31. The Class PreambleFilter
4.3.31. クラスPreambleFilter
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」です。 少なくともこれらの結果の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記述A具象クラス。 FilterEntryBaseタイプコンクリートの特性FilterItemListから、派生します。[ ]
Moore, et al. Standards Track [Page 62] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[62ページ]。
4.3.31.1. The Multi-valued Property FilterItemList
4.3.31.1. マルチ評価された特性の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".
メーター結果を特徴付けるための2つの平行な用語があることに注意してください。 列挙値の「従う(1)」は時々「プロフィール」として記述されています、そして、値の"nonConforming(3)"は時々「プロフィール」として記述されています。
4.3.32. The Class FilterList
4.3.32. クラスFilterList
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。 独身のFilterListへの異なったタイプのフィルタに集めるのは可能です--例えば、パケットのヘッダーフィルタ(IPHeaderFilterのクラスによって表される)とセキュリティフィルタ(IPsecによって定義されたFilterEntryBaseのサブクラスで、表されます)。
The aggregation property EntriesInFilterList.EntrySequence is always set to 0, to indicate that the aggregated filter entries are ANDed together to form a selector for a class of traffic.
集合特性EntriesInFilterList.EntrySequenceはトラフィックのクラスのためにセレクタを形成するために集められたフィルタエントリーが一緒にANDedであることを示すのを0にいつも用意ができています。
See [PCIME] for the definition of this class.
このクラスの定義に関して[PCIME]を見てください。
4.3.33. The Abstract Class ServiceAccessPoint
4.3.33. 抽象クラスServiceAccessPoint
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のCore Modelで定義された抽象クラスです。 それは、LogicalElementのクラスのサブクラスであり、CIM_Servicesへのアクセスを管理するすべてのオブジェクトのための基底クラスです。 それはServiceを利用するか、または呼び出すことの管理を代表します。 このクラスの完全な定義について[CIM]を参照してください。
4.3.34. The Class ProtocolEndpoint
4.3.34. クラスProtocolEndpoint
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]を参照してください。
Moore, et al. Standards Track [Page 63] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[63ページ]。
4.3.35. The Abstract Class Collection
4.3.35. 抽象クラス収集
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のCore Modelで定義された抽象クラスです。 それは組分けかバッグを表して、状態か「状態」を全く運ばないすべてのクラスのための「スーパー-クラス」です。 (後者はManagedSystemElementsとして、より正しくモデル化されるでしょう。) このクラスの完全な定義について[CIM]を参照してください。
4.3.36. The Abstract Class CollectionOfMSEs
4.3.36. 抽象クラスCollectionOfMSEs
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のCore Modelで定義された抽象クラスです。 CollectionのコンテンツをManagedSystemElementsに制限して、それはCollection superclassのサブクラスです。 このクラスの完全な定義について[CIM]を参照してください。
4.3.37. The Class BufferPool
4.3.37. クラスBufferPool
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はこの用法を表します。) 個々のバッファの存在と管理は将来のドキュメントでモデル化されるかもしれません。 現在のレベルの抽象化では、BufferPoolの存在をモデル化するのが必要です。 長い期間、それは十分ではありません。
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.
実装では、複数のバッファサイズがあるところでBufferPoolのインスタンスはそれぞれのセットのバッファのために同じであるか同様のサイズで定義されるべきです。 そして、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.
このクラスがForwardingかConditioningServiceから引き出されるのではなく、CollectionOfMSEsから引き出されることに注意してください。 BufferPoolはストレージの収集だけであり、Serviceではありません。
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 BufferPool記述A具象クラス。 タイプコンクリートの特性が命名するCollectionOfMSEs、BufferSize、TotalBuffers、AvailableBuffers、SharedBuffersから、派生します。
4.3.37.1. The Property Name
4.3.37.1. 特性の名
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のキャラクタの最大の長さがあるストリングです。 それは、オブジェクトが知られている一般名かラベルです。
Moore, et al. Standards Track [Page 64] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[64ページ]。
4.3.37.2. The Property BufferSize
4.3.37.2. 特性のBufferSize
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ビットの符号のない整数です。 実装は、それが管理するために必要とするバッファプールの数を減少させるためにおよそ同じサイズに関するバッファを通常分類するでしょう。 このモデルは同じバッファプールにおけるバッファがサイズにおいて異なるかもしれない度合いを指定しません。
4.3.37.3. The Property TotalBuffers
4.3.37.3. 特性のTotalBuffers
This property is a 32-bit unsigned integer, reporting the total number of individual buffers in the pool.
プールの中の個々のバッファの総数を報告して、この特性は32ビットの符号のない整数です。
4.3.37.4. The Property AvailableBuffers
4.3.37.4. 特性のAvailableBuffers
This property is a 32-bit unsigned integer, reporting the number of buffers in the Pool that are currently not allocated to any instance of a QueuingService. Buffers allocated to a QueuingService could either be in use (that is, currently contain packet data), or be allocated to a queue pending the arrival of new packet data.
この特性は32ビットの符号のない整数です、現在QueuingServiceのどんなインスタンスにも割り当てられないPoolのバッファの数を報告して。 QueuingServiceに割り当てられたバッファは、使用中であるか(すなわち、現在、パケットデータを含みます)、または新しいパケットデータの到着まで待ち行列に割り当てることができました。
4.3.37.5. The Property SharedBuffers
4.3.37.5. 特性のSharedBuffers
This property is a 32-bit unsigned integer, reporting the number of buffers in the Pool that have been simultaneously allocated to multiple instances of QueuingService.
この特性は32ビットの符号のない整数です、同時にQueuingServiceの複数のインスタンスに割り当てられたPoolのバッファの数を報告して。
4.3.38. The Abstract Class SchedulingElement
4.3.38. 抽象クラスSchedulingElement
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がそれが計画をしている要素の1つのために持っている設定情報を表す抽象クラスです。 予定されている要素は、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に制限されます。
Moore, et al. Standards Track [Page 65] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[65ページ]。
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がそれが計画をしている要素の1つのために持っている設定情報を表すNAME SchedulingElement記述An抽象クラス。 ManagedElementのタイプの抽象的な特性のWorkConservingから、派生します。
4.3.38.1. The Property WorkConserving
4.3.38.1. 特性の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協会によって仕事を保存する方法でこのインスタンスに結ばれた入力を扱っているかどうかを示します。 この特性が書き込み可能であることに注意してください、管理者がSchedulingElementの動きを変えることができるのを示して--しかし非workconservingモードで作動できるそれらの要素のためだけに。
4.3.39. The Class AllocationSchedulingElement
4.3.39. クラスAllocationSchedulingElement
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のすべてのサブクラスがあるケースのように、2つのタイプのひとりにはAllocationSchedulingElementのインスタンスに関連している入力があります: 待ち行列かスケジューラのどちらか別。
The class definition is as follows:
クラス定義は以下の通りです:
NAME AllocationSchedulingElement
DESCRIPTION A concrete class containing parameters
for controlling bandwidth-based
scheduling.
帯域幅ベースのスケジューリングを制御するためのパラメタを含むNAME AllocationSchedulingElement記述A具象クラス。
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES AllocationUnits, BandwidthAllocation,
BurstAllocation, CanShare,
WorkFlexible
SchedulingElementタイプコンクリートの特性AllocationUnits、BandwidthAllocation、BurstAllocation、CanShare、WorkFlexibleから、派生します。
Moore, et al. Standards Track [Page 66] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[66ページ]。
4.3.39.1. The Property AllocationUnits
4.3.39.1. 特性のAllocationUnits
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)oパケット(2)oセル(3)--例えば、固定サイズのATM
Note: if the value of AllocationUnits is not one of these three values, it SHOULD be interpreted as if it had the value '1' (bytes).
以下に注意してください。 AllocationUnitsの値はこれらの3つの値の1つでなく、それはSHOULDです。まるでそれには値'1'(バイト)があるかのように、解釈されてください。
4.3.39.2. The Property BandwidthAllocation
4.3.39.2. 特性のBandwidthAllocation
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の特性によって特定されます。
4.3.39.3. The Property BurstAllocation
4.3.39.3. 特性のBurstAllocation
This property is a 32-bit unsigned integer that specifies the amount of temporary or short-term bandwidth (in units per second) that can be allocated to an input, beyond the amount of bandwidth allocated through the BandwidthAllocation property. If the maximum actual bandwidth allocation for the input were to be measured, it would be the sum of the BurstAllocation and the BandwidthAllocation properties. The units are identified by the AllocationUnits property.
この特性は入力に割り当てることができる一時的であるか短期的な帯域幅(1秒あたりのユニットの)の量を指定する32ビットの符号のない整数です、BandwidthAllocation所有地を通して割り当てられた帯域幅の量を超えて。 入力のための最大の実際の帯域幅配分が測定されることであるなら、それはBurstAllocationとBandwidthAllocationの特性の合計です。 ユニットはAllocationUnitsの特性によって特定されます。
4.3.39.4. The Property CanShare
4.3.39.4. 特性のCanShare
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であるなら関連入力からの未使用の帯域幅がSchedulerによって修理された他の入力に割り当てられるのを可能にする論理演算子の特性です。
4.3.39.5. The Property WorkFlexible
4.3.39.5. 特性のWorkFlexible
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.
これはTRUEであるなら相続財産WorkConservingの値を変えることによってこの入力に比例したスケジューラの働きを変更できるのを示す論理演算子の特性です。
4.3.40. The Class WRRSchedulingElement
4.3.40. クラスWRRSchedulingElement
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
規律の計画をしながら荷重している連続(WRR)を表して、このクラスは抽象クラスSchedulingElementのサブクラスです。 それは、いくつかの入力aを与えるためにa新しい特性のWeightingFactorを導入します。
Moore, et al. Standards Track [Page 67] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[67ページ]。
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.
修理されるというもう一方が入力するより高い確率。 また、それは、入力に等しい重み係数があるとき、使用されるべきタイブレークとして機能するように特性のPriorityを導入します。 SchedulingElementのすべてのサブクラスがあるケースのように、2つのタイプのひとりにはWRRSchedulingElementのインスタンスに関連している入力があります: 待ち行列かスケジューラのどちらか別。
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記述Thisのクラスは、1入力あたり1個の重りを加えるためにSchedulingElementのクラスを専門とします。 関連入力を扱うとき、これは荷重している連続パケットスケジューラによって使用されます。 また、それはタイブレークとして同じ重さを複数の入力に割り当ててある場合で2番目の特性をサーブに加えます。 SchedulingElementタイプコンクリートの特性WeightingFactor、優先権から、派生します。
4.3.40.1. The Property WeightingFactor
4.3.40.1. 特性の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ビットの符号のない整数です。(その符号のない整数は修理されるというより高い確率をいくつかの入力に提供する重み係数を定義します)。 この特性はこの確率を表します。 最小値は0です、そして、最大値は100000です、そして、1000第年代に、ユニットがあります。
4.3.40.2. The Property Priority
4.3.40.2. 特性の優先権
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.
この特性は16ビットの符号のない整数です、2つ以上の入力に同量がある場合。(それは、タイブレークとして機能します)。 より大きい値は、より高い優先度を表します。 この特性がPacketSchedulingServiceに関連しているWRRSchedulingElementsのどれかに指定されるなら、そのPacketSchedulingServiceとしてすべてのWRRSchedulingElementsにそれを指定しなければなりません、そして、これらのWRRSchedulingElementsのための特性の値はすべて異なっていなければなりません。
Moore, et al. Standards Track [Page 68] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[68ページ]。
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.
この状態が荷重している連続スケジューラのいくつかの実装で現れていないかもしれない間、多くの実装が、同量状態を決議するために優先を必要とします。 インスタンスでは、この振舞いが必要でないか、または望ましくないところでこの特性は不特定のままにされるかもしれません。
4.3.41. The Class PrioritySchedulingElement
4.3.41. クラスPrioritySchedulingElement
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のサブクラスです。 それは、スケジューラが1セットの入力から優先度スケジュール規律を使用することでパケットを取っているのを示します。 SchedulingElementのすべてのサブクラスがあるケースのように、2つのタイプのひとりにはPrioritySchedulingElementのインスタンスに関連している入力があります: 待ち行列かスケジューラのどちらか別。 PrioritySchedulingElementの特性のPriorityは入力のために優先権を表します、この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.
Priorityの特性を加えるためにSchedulingElementのクラスを専門とするNAME PrioritySchedulingElement記述A具象クラス。 この特性は1セットの入力のために優先度スケジュールをしているSchedulingServiceによって使用されます。
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES Priority
SchedulingElementタイプコンクリートの特性優先権から、派生します。
4.3.41.1. The Property Priority
4.3.41.1. 特性の優先権
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ビットの符号のない整数です。 より大きい値は、より高い優先度を表します。
Moore, et al. Standards Track [Page 69] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[69ページ]。
4.3.42. The Class BoundedPrioritySchedulingElement
4.3.42. クラスBoundedPrioritySchedulingElement
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.
このクラスはクラスPrioritySchedulingElementのサブクラスです。(PrioritySchedulingElementは抽象クラスSchedulingElementから得られます)。 SchedulingElementのすべてのサブクラスがあるケースのように、2つのタイプのひとりにはBoundedPrioritySchedulingElementのインスタンスに関連している入力があります: 待ち行列かスケジューラのどちらか別。 BoundedPrioritySchedulingElementは入力からどのくらいのトラフィックを扱うことができるかに関して上限(1秒あたりのキロビットにおける)を加えます。 このデータはその1つの入力に特定です。 境界がある厳しい優先度スケジュールが実行されるとき、それが必要です。
This class inherits from its superclass PrioritySchedulingElement the restriction of the inherited boolean property WorkConserving to the value TRUE.
このクラスはsuperclass PrioritySchedulingElementから値のTRUEへの引き継いでいる論理演算子の特性のWorkConservingの制限を引き継ぎます。
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記述This具象クラスは、BandwidthBoundの特性を加えるためにPrioritySchedulingElementのクラスを専門とします。 この特性はバウンドしています。関連入力からのトラフィックを扱うことができる速度。
DERIVED FROM PrioritySchedulingElement
TYPE Concrete
PROPERTIES BandwidthBound
PrioritySchedulingElementタイプコンクリートの特性BandwidthBoundから、派生します。
4.3.42.1. The Property BandwidthBound
4.3.42.1. 特性の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ビットの符号のない整数です。 炸裂が起こることができるので、これは形成上限ではありません。 入力の影響を制限して、それは厳しいバウンドです。 ユニットは1秒あたりキロビットです。
4.4. Association Definitions
4.4. 協会定義
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デバイスdatapath協会について詳述します。 これらの協会は情報Modelでクラスと定義されます。 それぞれのこれらのクラスは2つの特性を協会がリンクする2つのクラスのインスタンスについて言及させます。 協会のクラスの中には、また、追加特性を持っているものもあります。
Moore, et al. Standards Track [Page 70] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[70ページ]。
4.4.1. The Abstract Association Dependency
4.4.1. 抽象的な協会の依存
This abstract association defines two object references (named Antecedent and Dependent) that establish general dependency relationships between different managed objects in the information model. The Antecedent reference identifies the independent object in the association, while the Dependent reference identifies the entity that IS dependent.
この抽象的な協会は異なった管理オブジェクトの間の一般的な依存関係を情報モデルに確立する2つのオブジェクト参照箇所(AntecedentとDependentと命名される)を定義します。 Antecedent参照は協会で独立しているオブジェクトを特定しますが、Dependent参照は依存する実体を特定します。
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のCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.2. The Association ServiceSAPDependency
4.4.2. 協会ServiceSAPDependency
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.
この協会はServiceオブジェクトとServiceAccessPointオブジェクトとの一般的な依存関係を確立する2つのオブジェクト参照箇所を定義します。 この関係は、参照をつけられたServiceがANOTHER ServiceのServiceAccessPointを使用するのを示します。 別のServiceへのアクセスを得るためにServiceAccessPointを当てにして、ServiceはDependent参照です。
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のCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.3. The Association IngressConditioningServiceOnEndpoint
4.4.3. 協会IngressConditioningServiceOnEndpoint
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.
この協会は、協会ServiceSAPDependencyから得られて、結合を表します、イングレス方向に、そのプロトコル終点を通って受け取られたプロトコル終点とパケットを処理する最初のConditioningServiceの間で。 プロトコル終点への1「1番目」のConditioningServiceがあることができるだけであるので、Dependentオブジェクト参照のための基数は0から狭くされます。nから0。1. 他方では、独身のConditioningServiceが複数のプロトコル終点を通って受け取られたパケットを処理する1番目であることができるので、Antecedentオブジェクト参照の基数は0のままで残っています。n。
Moore, et al. Standards Track [Page 71] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[71ページ]。
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]]
そのプロトコル終点を通って到着するトラフィックを処理するプロトコル終点と最初の調節サービスとの依存関係を確立するNAME IngressConditioningServiceOnEndpoint記述An協会。 ServiceSAPDependencyの抽象的な誤った特性の前例[審判ProtocolEndpoint[0..n]]から派生していて、依存しています。[審判ConditioningService[0 .1]]
4.4.4. The Association EgressConditioningServiceOnEndpoint
4.4.4. 協会EgressConditioningServiceOnEndpoint
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.
この協会は、協会ServiceSAPDependencyから得られて、結合を表します、出口の方向に、プロトコル終点とそのプロトコル終点を通ってネットワークデバイスを残す前にパケットを処理する最後のConditioningServiceの間で。 通常、しかし、スケジューラ、それはそうする必要はありません。(この「最後」のConditioningServiceがそう、いてください、) 後退スケジューラの場合にはプロトコル終点には「最後」の複数のConditioningServicesがあることができるので、Dependentオブジェクト参照のための基数が0のままで残っています。n。 しかしながら、独身のConditioningServiceが複数のプロトコル終点へのパケットを処理する最後のものであるはずがないので、Antecedentオブジェクト参照の基数は0から狭くされます。nから0。1.
The class definition is as follows:
クラス定義は以下の通りです:
NAME EgressConditioningServiceOnEndpoint
DESCRIPTION An association that establishes a
dependency relationship between a protocol
endpoint and the last conditioning
service(s) that process traffic to be
transmitted via that protocol endpoint.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..1]],
Dependent[ref ConditioningService[0..n]]
そのプロトコル終点を通って伝えられるためにトラフィックを処理するプロトコル終点と最後の調節サービスとの依存関係を確立するNAME EgressConditioningServiceOnEndpoint記述An協会。 ServiceSAPDependencyの抽象的な誤った特性の前例[審判ProtocolEndpoint[0 .1]]から派生していて、依存しています。[審判ConditioningService[0..n]]
4.4.5. The Association HeadTailDropQueueBinding
4.4.5. 協会HeadTailDropQueueBinding
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
この協会はDependencyのサブクラスです、それがいつトラフィックを下げるかを決定するためにモニターするヘッドかテール点滴器と待ち行列との仲間について説明して。 参照をつけられた待ち行列は待ち行列の深さがDropperの敷居に対してたとえられるものです。 基数は1です。a以来の待ち行列側のn
Moore, et al. Standards Track [Page 72] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[72ページ]。
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つの待ち行列をモニターしなければなりません。 クラスの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記述Aジェネリック協会は以前はよくそれがモニターするヘッドかテール点滴器と待ち行列との依存関係を確立していました。 依存の抽象的な誤った特性の前例[審判QueuingService[1..n]]から派生していて、依存しています。[審判HeadTailDropperService[0..n]]
4.4.6. The Association CalculationBasedOnQueue
4.4.6. 協会CalculationBasedOnQueue
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.
この協会はDependencyのサブクラスです。(DependencyはDropThresholdCalculationServiceのクラスのQueuingServiceとインスタンスとの依存関係を確立する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の抽象的な誤った特性の前例[審判QueuingService[1 .1]]から派生していて、依存しています。[審判DropThresholdCalculationService[0..n]]
Moore, et al. Standards Track [Page 73] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[73ページ]。
4.4.6.1. The Reference Antecedent
4.4.6.1. 参照前例
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.
この特性は、Dependency協会から引き継がれて、QueuingServiceオブジェクト(より一般的なManagedElementの代わりに)のオブジェクト参照として機能するように無視されます。 この参照はDropThresholdCalculationServiceが平均した待ち行列の深さの計算に使用する待ち行列を特定します。
4.4.6.2. The Reference Dependent
4.4.6.2. 参照扶養家族
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.
この特性は、Dependency協会から引き継がれて、DropThresholdCalculationServiceオブジェクト(より一般的なManagedElementの代わりに)のオブジェクト参照として機能するように無視されます。 この参照は入力の1つとして平均した待ち行列の深さの計算に参照をつけられた待ち行列の現在の深さを使用するDropThresholdCalculationServiceを特定します。
4.4.7. The Association ProvidesServiceToElement
4.4.7. 協会ProvidesServiceToElement
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が1Servicesの機能性に依存する依存関係を確立する2つのオブジェクト参照箇所を定義します。 協会の基数は多くに多くです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
協会はCIMのCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.8. The Association ServiceServiceDependency
4.4.8. 協会ServiceServiceDependency
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個のServiceオブジェクトの間の依存関係を確立する2つのオブジェクト参照箇所を定義します。 特定のタイプの依存はTypeOfDependencyの特性によって表されます。 典型的な例はServiceが存在しているのが必要でなければならなかった、またはもう片方のServiceが作動するように完成していなければならなかったそれを含んでいます。
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関係と非常に同様です。 後者において、Serviceは別のServiceに届くAccessPointに依存しています。 この関係では、それは直接Serviceの依存を特定します。 それらの情報が反復性であるので、両方の関係を例示するべきではありません。
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のCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
Moore, et al. Standards Track [Page 74] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[74ページ]。
4.4.9. The Association CalculationServiceForDropper
4.4.9. 協会CalculationServiceForDropper
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.
この協会はServiceServiceDependencyのサブクラスです。(ServiceServiceDependencyは1つ以上の待ち行列の観測された深層に基づく平均した待ち行列の深さについて計算して、DropThresholdCalculationServiceへのREDDropperServiceの信用を表す2つのオブジェクト参照箇所を定義します)。
The class definition is as follows:
クラス定義は以下の通りです:
NAME CalculationServiceForDropper
DESCRIPTION A generic association used to establish a
dependency relationship between a
calculation service and a
REDDropperSrevice for which it performs
average queue depth calculations
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref
DropThresholdCalculationService[1..n]],
Dependent[ref REDDropperService[0..n]]
4.4.9.1. The Reference Antecedent
NAME CalculationServiceForDropper記述Aジェネリック協会は以前はよくそれが.1に平均した待ち行列深さ計算DERIVED FROM ServiceServiceDependency要約False PROPERTIES Antecedent[審判DropThresholdCalculationService[1..n]]、Dependent[審判REDDropperService[0..n]]4.4.9を実行する計算サービスとREDDropperSreviceとの依存関係を確立していました。 参照前例
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.
この特性は、ServiceServiceDependency協会から引き継がれて、DropThresholdCalculationServiceオブジェクト(より一般的なServiceオブジェクトの代わりに)のオブジェクト参照として機能するように無視されます。 オブジェクト参照の基数は1です。1つ以上の計算サービスでRED点滴器が役立たれるかもしれないのを示すn。
4.4.9.2. The Reference Dependent
4.4.9.2. 参照扶養家族
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.
この特性は、ServiceServiceDependency協会から引き継がれて、REDDropperServiceオブジェクト(より一般的なServiceオブジェクトの代わりに)のオブジェクト参照として機能するように無視されます。 この参照はDropThresholdCalculationServiceによって役立たれたRED点滴器を特定します。
4.4.10. The Association QueueAllocation
4.4.10. 協会QueueAllocation
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.
この協会はDependencyのサブクラスです。(DependencyはQueuingServiceとBufferPoolとの待ち行列で集積スペースをパケットに提供する依存関係を確立する2つのオブジェクト参照箇所を定義します)。
Moore, et al. Standards Track [Page 75] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[75ページ]。
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記述Aジェネリック協会は以前はよくQueuingServiceオブジェクトとBufferPoolオブジェクトとの依存関係を確立していました。 依存の抽象的な誤った特性の前例[審判BufferPool[0..n]]、[審判QueuingService[0..n]]依存するAllocationPercentageから、派生します。
4.4.10.1. The Reference Antecedent
4.4.10.1. 参照前例
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.
この特性は、Dependency協会から引き継がれて、BufferPoolオブジェクトのオブジェクト参照として機能するように無視されます。 この参照はQueuingServiceの待ち行列のパケットが保存されるBufferPoolを特定します。
4.4.10.2. The Reference Dependent
4.4.10.2. 参照扶養家族
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.
この特性は、Dependency協会から引き継がれて、QueuingServiceオブジェクトのオブジェクト参照として機能するように無視されます。 この参照はパケットがBufferPoolのバッファに保存されているQueuingServiceを特定します。
4.4.10.3. The Property AllocationPercentage
4.4.10.3. 特性のAllocationPercentage
This property is an 8-bit unsigned integer with minimum value of zero and maximum value of 100. It defines the percentage of the BufferPool that should be allocated to the referenced QueuingService. If absolute sizes are desired, this would be accomplished by defining individual BufferPools of the specified sizes, with QueueAllocation.AllocationPercentages set to 100.
この特性はゼロの最小値と100の最大値がある8ビットの符号のない整数です。 それは割り当てられるべきであるBufferPool対参照をつけられたQueuingServiceの割合を定義します。 実寸が望まれているなら、これは指定されたサイズの個々のBufferPoolsを定義することによって、達成されるでしょう、100に用意ができているQueueAllocation.AllocationPercentagesと共に。
4.4.11. The Association ClassifierElementUsesFilterList
4.4.11. 協会ClassifierElementUsesFilterList
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.
この協会はDependency協会のサブクラスです。 それはそれぞれのClassifierElementsが処理するようにパケットを選択する評価基準を表すFilterListに1ClassifierElementsを関連づけります。
In the QDDIM model, a classifier is always modeled as a ClassifierService that aggregates a set of ClassifierElements. When ClassifierElements use the NextServiceAfterClassifierElement
QDDIMモデルでは、クラシファイアはClassifierElementsの1セットに集めるClassifierServiceとしていつもモデル化されます。 ClassifierElementsがNextServiceAfterClassifierElementを使用する場合
Moore, et al. Standards Track [Page 76] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[76ページ]。
association to bind to another ClassifierService (to construct a hierarchical classifier), the ClassifierElementUsesFilterList association must not be specified.
別のClassifierService(階層的なクラシファイアを組み立てる)、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]]
そのClassifierElementが処理するようにパケットを選択する評価基準を表すFilterListにClassifierElementに関連するNAME ClassifierElementUsesFilterList記述An協会。 依存の抽象的な誤った特性の前例[審判FilterList[0 .1]]から派生していて、依存しています。[審判ClassifierElement[0..n]]
4.4.11.1. The Reference Antecedent
4.4.11.1. 参照前例
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.
この特性は、Dependency協会から引き継がれて、FilterListオブジェクトのオブジェクト参照として機能するように無視されます、より一般的なManagedElementオブジェクトの代わりに。 また、基数は0と1に制限されます、ClassifierElementが階層的なクラシファイアを形成するために別のClassifierServiceに付くNextServiceAfterClassifierElement協会を使用するとClassifierElementがそれにもかかわらず、どんなFilterListのためにもパケットを選択しないように1FilterListを使用するのを示して。
4.4.11.2. The Reference Dependent
4.4.11.2. 参照扶養家族
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.
この特性は、Dependency協会から引き継がれて、ClassifierElementオブジェクトのオブジェクト参照として機能するように無視されます、より一般的なManagedElementオブジェクトの代わりに。 この参照はパケット選択評価基準を表すために関連FilterListオブジェクトによるClassifierElementを特定します。
4.4.12. The Association AFRelatedServices
4.4.12. 協会AFRelatedServices
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低下関連のServicesの先行です。
Moore, et al. Standards Track [Page 77] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[77ページ]。
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記述An協会は以前はよく2個のAFServiceオブジェクトの間の依存関係を確立していました。 何も抽象的なものから派生していない偽の特性のAFLowerDropPrecedence[審判AFService[0 .1]]、AFHigherDropPrecedence[審判AFService[0..n]]
4.4.12.1. The Reference AFLowerDropPrecedence
4.4.12.1. 参照AFLowerDropPrecedence
This property serves as an object reference to an AFService object that has the lower probability of dropping packets.
この特性はパケットを下げるという低い確率を持っているAFServiceオブジェクトのオブジェクト参照として機能します。
4.4.12.2. The Reference AFHigherDropPrecedence
4.4.12.2. 参照AFHigherDropPrecedence
This property serves as an object reference to an AFService object that has the higher probability of dropping packets.
この特性はパケットを下げるというより高い確率を持っているAFServiceオブジェクトのオブジェクト参照として機能します。
4.4.13. The Association NextService
4.4.13. 協会NextService
This association defines two object references that establish a predecessor-successor relationship between two ConditioningService objects. This association is used to indicate the sequence of ConditioningServices required to process a particular type of traffic.
この協会は2個の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が直接お互いに食べさせるかもしれませんか、または彼らはパケットの特性に基づく「次」の複数のServicesに写像されるかもしれません。
Moore, et al. Standards Track [Page 78] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[78ページ]。
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記述An協会は以前はよく2個のConditioningServiceオブジェクトの間の前任者後継者関係を確立していました。 何も抽象的なものから派生していない偽の特性のPrecedingService[審判ConditioningService[0..n]]、FollowingService[審判ConditioningService[0..n]]
4.4.13.1. The Reference PrecedingService
4.4.13.1. 参照PrecedingService
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オブジェクトのオブジェクト参照として機能します。
4.4.13.2. The Reference FollowingService
4.4.13.2. 参照FollowingService
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オブジェクトのオブジェクト参照として機能します。
4.4.14. The Association NextServiceAfterClassifierElement
4.4.14. 協会NextServiceAfterClassifierElement
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記述An協会は以前はよくClassifierの中の独身のClassifierElementと次のConditioningServiceオブジェクトとのそのClassifierElementによって選択されたトラフィックのさらなる処理に原因となる前任者後継者関係を確立していました。
Moore, et al. Standards Track [Page 79] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[79ページ]。
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService
[ref ClassifierElement[0..n]],
FollowingService
[ref ConditioningService[1..1]
NextServiceの抽象的な偽の特性のPrecedingService[審判ClassifierElement[0..n]]、FollowingServiceから派生する、[審判ConditioningService[1..1]
4.4.14.1. The Reference PrecedingService
4.4.14.1. 参照PrecedingService
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協会から引き継がれます。 それはClassifierElementのオブジェクト参照を制限するためにこのサブクラスでくつがえされます、NextService superclassで定義されたより一般的なConditioningServiceと対照的に。
This property serves as an object reference to a ClassifierElement, which is a component of a single ClassifierService. Packets selected by this ClassifierElement are always passed to the ConditioningService identified by the FollowingService object reference.
この特性はClassifierElementのオブジェクト参照として機能します。(ClassifierElementは独身のClassifierServiceの部品です)。 このClassifierElementによって選択されたパケットはいつもFollowingServiceオブジェクト参照で特定されたConditioningServiceに通過されます。
4.4.14.2. The Reference FollowingService
4.4.14.2. 参照FollowingService
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協会から引き継がれます。 それは、まさに1の参照の基数を制限するためにこのサブクラスでくつがえされます。 これはDiffServクラシファイアの働きが決定論的であるに違いないという要件を反映します: 与えられたClassifierServiceで与えられたClassifierElementによって選択されたパケットはいつも次の唯一無二の1ConditioningServiceまで行かなければなりません。
4.4.15. The Association NextScheduler
4.4.15. 協会NextScheduler
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つのスケジューラがNextScheduler協会を通して2番目のスケジューラが単一の、そして、集められた入力として最初のスケジューラの出力を扱うところで関係づけられます。
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記述An協会は簡単な階層的なスケジューリングのために以前はよくPacketSchedulingServiceオブジェクトの間の前任者後継者関係を確立していました。 NextService要約から、虚偽で派生します。
Moore, et al. Standards Track [Page 80] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[80ページ]。
PROPERTIES PrecedingService[ref
PacketSchedulingService[0..n]],
FollowingService[ref
PacketSchedulingService[0..1]]
特性のPrecedingService[審判PacketSchedulingService[0..n]]、FollowingService[審判PacketSchedulingService[0 .1]]
4.4.15.1. The Reference PrecedingService
4.4.15.1. 参照PrecedingService
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.
この特性は、NextService協会から引き継がれて、PacketSchedulingServiceオブジェクト(より一般的なConditioningServiceオブジェクトの代わりに)のオブジェクト参照として機能するように無視されます。 この参照は出力がFollowingService参照で特定されたスケジューラによって単一の、そして、集められた入力として扱われているスケジューラを特定します。 [0..n]基数は、単一のFollowingServiceスケジューラが複数の先のスケジューラの集められた出力を集めるかもしれないのを示します。
4.4.15.2. The Reference FollowingService
4.4.15.2. 参照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.
この特性は、NextService協会から引き継がれて、PacketSchedulingServiceオブジェクト(より一般的なConditioningServiceオブジェクトの代わりに)のオブジェクト参照として機能するように無視されます。 この参照は入力の中に1つ以上のPrecedingServiceスケジューラの集められた出力を含んでいるスケジューラを特定します。
4.4.16. The Association FailNextScheduler
4.4.16. 協会FailNextScheduler
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協会のサブクラスです。 FailNextSchedulerは最初のスケジューラがスケジューリングの機会を無視するとき(その結果、方法を保存しながら、非仕事で振る舞います)、2つのスケジューラの間の関係を表して、結果として起こる帯域幅を使用のための2番目のスケジューラに利用可能にします。 セクション3.11.3と3.11を見てください。.4 どこに関する例のために、この協会は使用されるかもしれないか。
The class definition is as follows:
クラス定義は以下の通りです:
NAME FailNextScheduler
DESCRIPTION This association specializes the
NextScheduler association. It
establishes a relationship between a
non-work-conserving scheduler and a
second scheduler to which it makes
available the bandwidth that it elects
not to use.
DERIVED FROM NextScheduler
ABSTRACT False
NAME FailNextScheduler記述This協会はNextScheduler協会を専門とします。 それは仕事を保存しないスケジューラと2番目のスケジューラとの関係を利用可能にするものに確立します。それが使用しないのを選ぶ帯域幅。 NextScheduler要約から、虚偽で派生します。
Moore, et al. Standards Track [Page 81] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[81ページ]。
PROPERTIES PrecedingService[ref
NonWorkConservingSchedulingService[0..n]]
特性のPrecedingService[審判NonWorkConservingSchedulingService[0..n]]
4.4.16.1. The Reference PrecedingService
4.4.16.1. 参照PrecedingService
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.
この特性は、NextScheduler協会から引き継がれて、NonWorkConservingSchedulingServiceオブジェクト(より一般的なPacketSchedulingServiceオブジェクトの代わりに)のオブジェクト参照として機能するように無視されます。 この参照はFollowingService参照で特定されたスケジューラが余分な帯域幅を入手している仕事を保存しないスケジューラを特定します。 [0..n]基数は、単一のFollowingServiceスケジューラには複数の先の仕事を保存しないスケジューラの未使用の帯域幅を使用する機会があるかもしれないのを示します。
4.4.17. The Association NextServiceAfterMeter
4.4.17. 協会NextServiceAfterMeter
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を定義します。(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記述An協会は以前はよくMeterServiceの特定の出力と次のConditioningServiceオブジェクトとのトラフィックのさらなる処理に原因となる前任者後継者関係を確立していました。 何も抽象的なものから、虚偽で派生しません。
Moore, et al. Standards Track [Page 82] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[82ページ]。
PROPERTIES PrecedingService[ref MeterService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
MeterResult
特性のPrecedingService[審判MeterService[0..n]]、FollowingService[審判ConditioningService[0..n]]、MeterResult
4.4.17.1. The Reference PrecedingService
4.4.17.1. 参照PrecedingService
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。 Metersが1:nがデバイスを四方八方に広げるということであるので、この関係はMeterService(MeterResultの特性で、特定される)の特定の出力をさらにトラフィックを処理するのに使用される次のConditioningServiceに関連づけます。
4.4.17.2. The Reference FollowingService
4.4.17.2. 参照FollowingService
The 'next' or following ConditioningService.
'次'の、または、次のConditioningService。
4.4.17.3. The Property MeterResult
4.4.17.3. 特性のMeterResult
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)、"NonConforming"(3)。
4.4.18. The Association QueueToSchedule
4.4.18. 協会QueueToSchedule
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の1つのインスタンスに参加します。
Moore, et al. Standards Track [Page 83] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[83ページ]。
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記述This協会は待ち行列に特定の情報を含むSchedulingElementに待ち行列に関連します。 抽象的な偽の特性が列に並ばせないものは何[審判QueuingService[0 .1]]、SchedElementからでも、派生します。[審判SchedulingElement[0..n]]
4.4.18.1. The Reference Queue
4.4.18.1. 参照待ち行列
This property serves as an object reference to a QueuingService object. A QueuingService object may be associated 0 or more SchedulingElement objects.
この特性はQueuingServiceオブジェクトのオブジェクト参照として機能します。 QueuingServiceオブジェクトは0個以上の関連SchedulingElementオブジェクトであるかもしれません。
4.4.18.2. The Reference SchedElement
4.4.18.2. 参照SchedElement
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はいつもちょうど1QueuingServiceかちょうど1つの上流のスケジューラ(PacketSchedulingService)に関連しています。
4.4.19. The Association SchedulingServiceToSchedule
4.4.19. 協会SchedulingServiceToSchedule
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の1つのインスタンスに参加します。
The class definition is as follows:
クラス定義は以下の通りです:
NAME SchedulingServiceToSchedule
DESCRIPTION This association relates a scheduler to
the SchedulingElement in a subsequent
scheduler containing information specific
to this scheduler.
このスケジューラに特定の情報を含んでいて、NAME SchedulingServiceToSchedule記述This協会はその後のスケジューラでSchedulingElementにスケジューラに関連します。
Moore, et al. Standards Track [Page 84] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[84ページ]。
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES SchedService[ref
PacketSchedulingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
何も抽象的なものから派生していない偽の特性のSchedService[審判PacketSchedulingService[0 .1]]、SchedElement[審判SchedulingElement[0..n]]
4.4.19.1. The Reference SchedService
4.4.19.1. 参照SchedService
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オブジェクトであるかもしれません。
4.4.19.2. The Reference SchedElement
4.4.19.2. 参照SchedElement
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はいつもちょうど1QueuingServiceかちょうど1つの上流のスケジューラ(PacketSchedulingService)に関連しています。
4.4.20. The Aggregation MemberOfCollection
4.4.20. 集合MemberOfCollection
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の1セットの集合をモデル化するのに使用されるジェネリック関係です。 集合の基数は多くに多くです。
MemberOfCollection is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
MemberOfCollectionはCIMのCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.21. The Aggregation CollectedBufferPool
4.4.21. 集合CollectedBufferPool
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.
この集合は「より高いレベル」バッファプールに順番に含むことができるプール、または収集として1セットのバッファを扱う能力をモデル化します。 このクラスは、BufferPoolのクラスだけのインスタンスになるように集合と部分コンポーネントオブジェクトの両方を制限するために、より多くのジェネリック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記述Aジェネリック協会は以前はよくよりハイレベルのバッファプールへの1セットの関連するバッファに集められていました。 MemberOfCollection抽象的な誤った特性の収集[審判BufferPool[0 .1]]、メンバーから、派生します。[審判BufferPool[0..n]]
Moore, et al. Standards Track [Page 85] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[85ページ]。
4.4.21.1. The Reference Collection
4.4.21.1. 参照収集
This property represents the parent, or aggregate, object in the relationship. It is a BufferPool object.
この特性は親、または集合、関係におけるオブジェクトの代理をします。 それはBufferPoolオブジェクトです。
4.4.21.2. The Reference Member
4.4.21.2. 参照メンバー
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.
この特性は関係で子供、または下のレベルプールの代理をします。 そんなに一緒にいるBufferPoolsのセットの1つが、よりハイレベルのプールを作るということです。
4.4.22. The Abstract Aggregation Component
4.4.22. 抽象的な集合成分
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のCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.23. The Aggregation ServiceComponent
4.4.23. 集合ServiceComponent
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.
この集合は、よりハイレベルのServiceを形成するために一緒に集められる下位のServicesの1セットをモデル化するのに使用されます。 この関係に参加できるオブジェクトのタイプを制限するために、より多くのジェネリックComponent superclassからこの集合を得ます。 協会の基数は多くに多くです。
The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class.
協会はCIMのCore Modelで定義されます。 このクラスの完全な定義について[CIM]を参照してください。
4.4.24. The Aggregation QoSSubService
4.4.24. 集合QoSSubService
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を形成するために一緒に集められる1セットの下位のQoSServiceオブジェクト(すなわち、QoSServiceのクラスのサブクラスのインスタンスのセット)を表します。 QoSServiceは1セットの連携サブサービスとしてQoSの機能性を概念化するServiceの特定のタイプです。
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 superclassからこの集合を得て、より多くのジェネリックServiceの代わりに反対してください。 また、それは集合の基数を0か1(より多くの、よりジェネリック0以上の代わりに)に制限します。
Moore, et al. Standards Track [Page 86] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[86ページ]。
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]]
」 集められる低レベルQoSServicesの、よりハイレベルのQoSServiceオブジェクトとセットとの関係は/フォームを作成します。NAME QoSSubService記述Aジェネリック協会が以前はよく設立していた、「部分、-、それ。 ServiceComponentの抽象的な偽の特性のGroupComponent[審判QoSService[0 .1]]、PartComponentから、派生します。[審判QoSService[0..n]]
4.4.24.1. The Reference GroupComponent
4.4.24.1. 参照GroupComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 このオブジェクトは親、または集合、関係におけるオブジェクトの代理をします。
4.4.24.2. The Reference PartComponent
4.4.24.2. 参照PartComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 このオブジェクトは子供、または「コンポーネント」、関係におけるオブジェクトの代理をします。
4.4.25. The Aggregation QoSConditioningSubService
4.4.25. 集合QoSConditioningSubService
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 superclassからこの集合を得ます。 それはConditioningServiceにそれに参加できるオブジェクトとQoSServiceオブジェクトのタイプを制限します、より多くのジェネリックServiceオブジェクトの代わりに。
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記述Aジェネリック集合が以前はよく設立していた、「部分、-、」 それらがトラフィック調節を提供する1セットのConditioningServiceオブジェクトと特定のQoSServiceオブジェクトとの関係。 ServiceComponent要約から、虚偽で派生します。
Moore, et al. Standards Track [Page 87] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[87ページ]。
PROPERTIES GroupComponent[ref QoSService[0..n]],
PartComponent[ref
ConditioningService[0..n]]
特性のGroupComponent[審判QoSService[0..n]]、PartComponent[審判ConditioningService[0..n]]
4.4.25.1. The Reference GroupComponent
4.4.25.1. 参照GroupComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 参照の基数は0のままで残っています。n、与えられたConditioningServiceはそれを示すために、0、1のための調節をトラフィックに供給するか、または1QoSServiceにオブジェクトを供給するかもしれません。
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を表します。
4.4.25.2. The Reference PartComponent
4.4.25.2. 参照PartComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 このオブジェクトは子供、または「コンポーネント」、関係におけるオブジェクトの代理をします。 この場合、このオブジェクトが1を表すか、またはそんなに一緒にいるより多くのConditioningServiceオブジェクトが特定のQoSServiceのためのトラフィックがどう条件とするかを示します。
4.4.26. The Aggregation ClassifierElementInClassifierService
4.4.26. 集合ClassifierElementInClassifierService
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
クラシファイアとそのクラシファイア要素との関係を表すNAME ClassifierElementInClassifierService記述An集合。 ServiceComponent要約から、虚偽で派生します。
Moore, et al. Standards Track [Page 88] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[88ページ]。
PROPERTIES GroupComponent[ref
ClassifierService[1..1]],
PartComponent[ref
ClassifierElement[0..n],
ClassifierOrder
特性のGroupComponent[審判ClassifierService[1 .1]]、PartComponent、[審判ClassifierElement[0..n]、ClassifierOrder
4.4.26.1. The Reference GroupComponent
4.4.26.1. 参照GroupComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 また、それは集合の基数を1に制限します。ClassifierElementがちょうど1ClassifierServiceの文脈の中にいつも存在しているという事実を表す1(より多くの、よりジェネリック0以上の代わりに)。
4.4.26.2. The Reference PartComponent
4.4.26.2. 参照PartComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 このオブジェクトはクラシファイアのために単一のトラフィックセレクタを表します。 通常、ClassifierElementはクラシファイアの中と、そして、ConditioningServiceに来るトラフィックストリームからこれらの評価基準によって選択されたどのパケットが次になるかまで進められたパケットの選択評価基準を提供するFilterListに協会を持っています。
4.4.26.3. The Property ClassifierOrder
4.4.26.3. 特性のClassifierOrder
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ビットの整数です。 値は昇順に表されます: 最初に、'1'、次に、'2'など。 与えられたClassifierServiceによって集められたそれぞれのClassifierElementsのために異価を割り当てなければなりません。
4.4.27. The Aggregation EntriesInFilterList
4.4.27. 集合EntriesInFilterList
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.
この集合はComponent集合の専門化です。 それは、FilterListによって集められる1セットのフィルタエントリー(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
集合自体の基数は0です。1 FilterListエンド、および0に関して。FilterEntryBaseのnは終わります。 したがって、一般的な場合では、フィルタエントリーは集められるのに存在できます。
Moore, et al. Standards Track [Page 89] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[89ページ]。
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。 しかしながら、フィルタエントリーがQoS Deviceモデルを含むことができる唯一の方法はこの集合によってFilterListに集めることにされます。
See [PCIME] for the definition of this aggregation.
この集合の定義に関して[PCIME]を見てください。
4.4.28. The Aggregation ElementInSchedulingService
4.4.28. 集合ElementInSchedulingService
This concrete aggregation represents the relationship between a PacketSchedulingService and the set of SchedulingElements that tie it to its inputs.
この具体的な集合はそれを入力に結ぶSchedulingElementsのPacketSchedulingServiceとセットとの関係を表します。
The class definition for the aggregation is as follows:
集合のためのクラス定義は以下の通りです:
NAME ElementInSchedulingService
DESCRIPTION An aggregation used to tie a
PacketSchedlingService to the
configuration information for one of
the elements (either a QueuingService or
another PacketSchedulingService) that it
schedules.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
PacketSchedulingService[0..1]],
PartComponent[ref
SchedulingElement[1..n]
NAME ElementInSchedulingService記述An集合はそれが計画をする要素(QueuingServiceかPacketSchedulingServiceのどちらか別)の1つに設定情報へのPacketSchedlingServiceを繋がりに使用しました。 コンポーネントの抽象的な偽の特性のGroupComponent[審判PacketSchedulingService[0 .1]]、PartComponentから派生する、[審判SchedulingElement[1..n]
4.4.28.1. The Reference GroupComponent
4.4.28.1. 参照GroupComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 また、それは集合の基数を0に制限します。SchedulingElementが高々1PacketSchedulingServiceの文脈の中に存在しているという事実を表す1(より多くの、よりジェネリック0以上の代わりに)。
4.4.28.2. The Reference PartComponent
4.4.28.2. 参照PartComponent
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オブジェクト(「スーパー-クラス」で定義されたより多くのジェネリックServiceオブジェクトの代わりに)のオブジェクト参照を表すためにこの集合で無視されます。 このオブジェクトはスケジューラのためにただ一つのスケジューリング要素を表します。 また、それはSchedulingElementの基数を1に制限します。PacketSchedulingServiceがいつも少なくとも1SchedulingElementを含んでいるという事実を表すn(より多くの、よりジェネリック0以上の代わりに)。
Moore, et al. Standards Track [Page 90] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[90ページ]。
5. Intellectual Property Statement
5. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。
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.
権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
6. Acknowledgements
6. 承認
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.
作者は彼らの多くの役に立つコメントと提案についてPolicy FrameworkとDifferentiated Servicesワーキンググループの関係者に感謝したがっています。 ジョエル・アルペルンへの特別な感謝。(アルペルンは、後者のステージのドキュメントの開発の間、何らかの主要な技術的な方向を提供しました)。
7. Security Considerations
7. セキュリティ問題
Like [PCIM] and [PCIME], this document defines an information model that cannot be implemented directly. Consequently, security issues do not arise until it is mapped to an actual, implementable data model such as a MIB, PIB, or LDAP schema. See [PCIM] for a general discussion of security considerations for information models. See also [DSMIB] (which in fact is a data model that corresponds to a large extent with the QDDIM information model), for a discussion of the security implications of specific objects in the model.
[PCIM]と[PCIME]のように、このドキュメントは直接実装することができない情報モデルを定義します。 その結果、それがMIB、PIB、またはLDAP図式などの実際の、そして、実装可能なデータモデルに写像されるまで、安全保障問題は起こりません。 セキュリティ問題の一般的な議論に関して情報モデルに関して[PCIM]を見てください。 また、[DSMIB](事実上、大体においてQDDIM情報モデルに文通するデータモデルである)を見てください、モデルにおける、特定のオブジェクトのセキュリティ含意の議論のために。
Moore, et al. Standards Track [Page 91] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[91ページ]。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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]一般的な情報Model(CIM)図式、バージョン2.5。 http://www.dmtf.org/standards/cim_schema_v25.php で利用可能な分配されたManagement Task Force Inc.。
[IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q,
1998 edition. Approved December 8, 1998
[IEEE802Q]仮想のBridgedローカル・エリア・ネットワーク、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仕様」、RFC3060、2001年2月。
[PCIME] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[PCIME] ムーア、B.、エド、「方針コア情報モデル(PCIM)拡大」、RFC3460、1月2003日
[R791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[R791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[R2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[R2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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分野)の定義」RFC2474(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は分類する」RFC2597、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.Le Faucheur、「ホップ振舞い識別コード」、RFC3140、2001年6月。
8.2. Informative References
8.2. 有益な参照
[DSMIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[DSMIB] ベイカー、F.、チェン、K.、およびA.スミス(「差別化されたサービスアーキテクチャのための管理情報ベース」、RFC3289)は2002がそうするかもしれません。
[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ルータのためにモデル化します」、RFC3290、2002年5月。
Moore, et al. Standards Track [Page 92] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[92ページ]。
[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)は、「サービスサービスの質方針Information基地を差別化しました」、RFC3317、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.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(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.とランベルクとY.とStrassnerとJ.とコーエンとR.とB.ムーア、「方針サービスの質(QoS)情報モデル」、RFC3644、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、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、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.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、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.とシャルニーとA.とアメリカダイコンソウとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とコートニーとW.とDavariとS.とFiroiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[RED] See http://www.aciri.org/floyd/red.html
[赤] http://www.aciri.org/floyd/red.html を見てください。
Moore, et al. Standards Track [Page 93] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[93ページ]。
9. Appendix A: Naming Instances in a Native CIM Implementation
9. 付録A: ネイティブのCIM実装におけるインスタンスを命名します。
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]のAppendix AがCIM命名の綱領の長い議論をするので、この付録はここでその情報を繰り返しません。 インスタンスがネイティブのCIM実装でどう命名されるかに関する、より世界的規模の議論に興味を持っている読者は[PCIM]を参照するべきです。
9.1. Naming Instances of the Classes Derived from Service
9.1. サービスから得られたクラスのインスタンスを命名します。
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のクラスServiceからこのモデルで定義されたクラスの大部分を得ます。 Serviceは抽象クラスですが、それで、それにもかかわらず、定義の一部として基本性質を含んでいます。 抽象クラスに基本性質を含む目的は同様に、instantiableサブクラスのすべてのインスタンスを命名させることです。 したがって、このモデルのクラスの大部分がまさに同じようにそれらのインスタンスを命名します: それらがServiceから引き継ぐ2の基本性質CreationClassNameとNameと共に。
9.2. Naming Instances of Subclasses of FilterEntryBase
9.2. FilterEntryBaseのサブクラスのインスタンスを命名します。
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.
Serviceのように、FilterEntryBase([PCIME]では、定義される)は定義に基本性質を含んでいる抽象クラスです。 FilterEntryBaseには、4個の基本性質があります。 それら、SystemCreationClassName、および2SystemNameが弱い協会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のサブクラスのすべてのインスタンスは命名されます: 4個の基本性質で、それらはFilterEntryBaseから世襲します。
9.3. Naming Instances of ProtocolEndpoint
9.3. ProtocolEndpointのインスタンスを命名します。
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を伝播して、プラスtwoは、固有の基本性質のCreationClassNameとNameです。
Moore, et al. Standards Track [Page 94] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[94ページ]。
9.4. Naming Instances of BufferPool
9.4. BufferPoolのインスタンスを命名します。
Unlike the other classes in this model, BufferPool is not derived from Service. Consequently, it does not inherit its key properties from Service. Instead, it inherits one of its key properties, CollectionID, from its superclass Collection, and adds its other key property, CreationClassName, in its own definition.
このモデルの他のクラスと異なって、BufferPoolはServiceから得られません。 その結果、それはServiceから基本性質を引き継ぎません。 代わりに、superclass Collectionからの基本性質の1つ、CollectionIDを引き継いで、他の主要な特性を加えます、CreationClassName、それ自身の定義で。
9.4.1. The Property CollectionID
9.4.1. 特性のCollectionID
CollectionID is a string property with a maximum length of 256 characters. It identifies the buffer pool. Note that this property is defined in the BufferPool class's superclass, CollectionOfMSEs, but not as a key property. It is overridden in BufferPool, to make it part of this class's composite key.
CollectionIDは256のキャラクタの最大の長さがあるストリングの特性です。 それはバッファプールを特定します。 この特性がBufferPoolのクラスsの「スーパー-クラス」、CollectionOfMSEsで定義されることに注意しますが、主要な特性として注意するというわけではなくなってください。 それはBufferPoolでくつがえされて、それを作るために、このクラスsの部分は合成物主要です。
9.4.2. The Property CreationClassName
9.4.2. 特性のCreationClassName
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.
この特性はaです。最大の長さの256のキャラクタと共に特性を結びます。 このクラスが直接例示されるなら、それが「CIM_BufferPool」に設定されるか、またはBufferPoolサブクラスのクラス名に、それは作成されます。
9.5. Naming Instances of SchedulingElement
9.5. SchedulingElementのインスタンスを命名します。
This class has not yet been incorporated into the CIM model, so it does not have any CIM naming properties yet. If the normal pattern is followed, however, instances will be named with two properties CreationClassName and Name.
このクラスがまだCIMモデルに組み入れられていないので、それには、まだ特性を命名しているどんなCIMもありません。 しかしながら、正常なパターンが従われていると、インスタンスは2の特性のCreationClassNameとNameと共に命名されるでしょう。
Moore, et al. Standards Track [Page 95] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[95ページ]。
10. Authors' Addresses
10. 作者のアドレス
Bob Moore P. O. Box 12195, BRQA/B501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
ボブムーアP. O. Box12195、BRQA/B501/G206 3039コーンウォリス通り リサーチトライアングル公園、NC27709-2195
Phone: (919) 254-4436 EMail: remoore@us.ibm.com
以下に電話をしてください。 (919) 254-4436 メールしてください: remoore@us.ibm.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
第25デヴィッドダラムインテル2111Ne Avenueヒースボロー、または97124
Phone: (503) 264-6232 EMail: david.durham@intel.com
以下に電話をしてください。 (503) 264-6232 メールしてください: david.durham@intel.com
John Strassner INTELLIDEN, Inc. 90 South Cascade Avenue Colorado Springs, CO 80903
ジョンStrassner INTELLIDEN Inc.90の南カスケードアベニューコロラド・スプリングス、CO 80903
Phone: (719) 785-0648 EMail: john.strassner@intelliden.com
以下に電話をしてください。 (719) 785-0648 メールしてください: john.strassner@intelliden.com
Andrea Westerinen Cisco Systems, Bldg 20 725 Alder Drive Milpitas, CA 95035
アンドレアWesterinenシスコシステムズ、Bldg20 725ハンノキDriveミルピタス、カリフォルニア 95035
EMail: andreaw@cisco.com
メール: andreaw@cisco.com
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH 03054
ウォルターワイスEllacoyaはメリマク、7ヘンリー・クレイニューハンプシャー博士 03054をネットワークでつなぎます。
Phone: (603) 879-7364 EMail: walterweiss@attbi.com
以下に電話をしてください。 (603) 879-7364 メールしてください: walterweiss@attbi.com
Moore, et al. Standards Track [Page 96] RFC 3670 QoS Device Datapath Info Model January 2004
ムーア、他 規格はQoSデバイスDatapathインフォメーションモデル2004年1月にRFC3670を追跡します[96ページ]。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Moore, et al. Standards Track [Page 97]
ムーア、他 標準化過程[97ページ]
一覧
スポンサーリンク
