RFC3644 日本語訳
3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y.Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: TXT=170150 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Snir
Request for Comments: 3644 Y. Ramberg
Category: Standards Track Cisco Systems
J. Strassner
Intelliden
R. Cohen
Ntear LLC
B. Moore
IBM
November 2003
Snirがコメントのために要求するワーキンググループY.をネットワークでつないでください: 3644年のY.ランベルクカテゴリ: 標準化過程シスコシステムズJ.Strassner Intelliden R.コーエンNtear LLC B.ムーアIBM2003年11月
Policy Quality of Service (QoS) Information Model
方針サービスの質(QoS)情報モデル
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.
このドキュメントは、Service(QoS)ネットワークマネージメント方針のQualityを表すためにオブジェクト指向情報モデルを提示します。 このドキュメントはIETF Policy Core情報Modelとその拡大に基づいています。 それは、微分されて統合しているサービスのためのQoS実施のために方針を使用することで情報モデルを定義します。 このドキュメントが定義上どんな特定のデータ保存メカニズムとアクセス・プロトコルからも独立している情報モデルを定義することに注意するのは重要です。
Snir, et al. Standards Track [Page 1] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[1ページ]。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. The Process of QoS Policy Definition. . . . . . . . . . 5
1.2. Design Goals and Their Ramifications. . . . . . . . . . 8
1.2.1. Policy-Definition Oriented. . . . . . . . . . . 8
1.2.1.1. Rule-based Modeling . . . . . . . . . 9
1.2.1.2. Organize Information Hierarchically . 9
1.2.1.3. Goal-Oriented Policy Definition . . . 10
1.2.2. Policy Domain Model. . . . . . . . . . . . . . . 11
1.2.2.1. Model QoS Policy in a Device- and
Vendor-Independent Manner . . . . . . 11
1.2.2.2. Use Roles for Mapping Policy to
Network Devices . . . . . . . . . . . 11
1.2.2.3. Reusability . . . . . . . . . . . . . 12
1.2.3. Enforceable Policy. . . . . . . . . . . . . . . 12
1.2.4. QPIM Covers Both Signaled And Provisioned QoS . 14
1.2.5. Interoperability for PDPs and Management
Applications. . . . . . . . . . . . . . . . . . 14
1.3. Modeling Abstract QoS Policies. . . . . . . . . . . . . 15
1.4. Rule Hierarchy. . . . . . . . . . . . . . . . . . . . . 17
1.4.1. Use of Hierarchy Within Bandwidth Allocation
Policies. . . . . . . . . . . . . . . . . . . . 17
1.4.2. Use of Rule Hierarchy to Describe Drop
Threshold Policies. . . . . . . . . . . . . . . 21
1.4.3. Restrictions of the Use of Hierarchy Within
QPIM. . . . . . . . . . . . . . . . . . . . . . 22
1.5. Intended Audiences. . . . . . . . . . . . . . . . . . . 23
2. Class Hierarchies . . . . . . . . . . . . . . . . . . . . . . 23
2.1. Inheritance Hierarchy . . . . . . . . . . . . . . . . . 23
2.2. Relationship Hierarchy. . . . . . . . . . . . . . . . . 26
3. QoS Actions . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . 26
3.2. RSVP Policy Actions . . . . . . . . . . . . . . . . . . 27
3.2.1. Example: Controlling COPS Stateless Decision. . 28
3.2.2. Example: Controlling the COPS Replace Decision. 29
3.3. Provisioning Policy Actions . . . . . . . . . . . . . . 29
3.3.1. Admission Actions: Controlling Policers and
Shapers . . . . . . . . . . . . . . . . . . . . 29
3.3.2. Controlling Markers . . . . . . . . . . . . . . 32
3.3.3. Controlling Edge Policies - Examples. . . . . . 33
3.4. Per-Hop Behavior Actions. . . . . . . . . . . . . . . . 34
3.4.1. Controlling Bandwidth and Delay . . . . . . . . 35
3.4.2. Congestion Control Actions. . . . . . . . . . . 35
3.4.3. Using Hierarchical Policies: Examples for PHB
Actions . . . . . . . . . . . . . . . . . . . . 36
4. Traffic Profiles. . . . . . . . . . . . . . . . . . . . . . . 38
4.1. Provisioning Traffic Profiles . . . . . . . . . . . . . 38
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. QoS方針定義の過程。 . . . . . . . . . 5 1.2. 目標と彼らの分岐を設計してください。 . . . . . . . . . 8 1.2.1. 適応する方針定義。 . . . . . . . . . . 8 1.2.1.1. 規則ベースのモデル. . . . . . . . . 9 1.2.1、.2 階層的で情報を組織化してください。.91.2 .1 .3。 目標指向の方針定義. . . 10 1.2.2。 方針ドメインモデル。 . . . . . . . . . . . . . . 11 1.2.2.1. .2に装置と業者から独立している方法. . . . . . 11 1.2.2におけるQoS方針をモデル化してください。 ネットワーク装置. . . . . . . . . . . 11 1.2.2.3に方針を写像するのに役割を使用してください。 リユーザビリティ. . . . . . . . . . . . . 12 1.2.3。 実施できる方針。 . . . . . . . . . . . . . . 12 1.2.4. QPIMカバーは、ともにQoS. 14 1.2.5に合図して、食糧を供給しました。 PDPsと管理アプリケーションのための相互運用性。 . . . . . . . . . . . . . . . . . 14 1.3. 抽象的なQoS方針をモデル化します。 . . . . . . . . . . . . 15 1.4. 階層構造を統治してください。 . . . . . . . . . . . . . . . . . . . . 17 1.4.1. 帯域幅配分方針の中の階層構造の使用。 . . . . . . . . . . . . . . . . . . . 17 1.4.2. 低下敷居方針を説明する規則階層構造の使用。 . . . . . . . . . . . . . . 21 1.4.3. QPIMの中の階層構造の使用の制限。 . . . . . . . . . . . . . . . . . . . . . 22 1.5. 対象とする訪問者。 . . . . . . . . . . . . . . . . . . 23 2. クラス階層構造. . . . . . . . . . . . . . . . . . . . . . 23 2.1。 遺産階層構造. . . . . . . . . . . . . . . . . 23 2.2。 関係階層構造。 . . . . . . . . . . . . . . . . 26 3. QoS動作. . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1。 概観。 . . . . . . . . . . . . . . . . . . . . . . . 26 3.2. RSVP政策的措置. . . . . . . . . . . . . . . . . . 27 3.2.1。 例: 制御は国がない決定を獲得します。 . 28 3.2.2. 例: 巡査を監督して、決定を取り替えてください。 29 3.3. 政策的措置. . . . . . . . . . . . . . 29 3.3.1に食糧を供給します。 入場動作: Policersと整形器. . . . . . . . . . . . . . . . . . . . 29 3.3.2を制御します。 マーカー. . . . . . . . . . . . . . 32 3.3.3を制御します。 縁の方針を制御します--例。 . . . . . 33 3.4. 1ホップあたりの振舞い動作。 . . . . . . . . . . . . . . . 34 3.4.1. 帯域幅と遅れ. . . . . . . . 35 3.4.2を制御します。 輻輳制御動作。 . . . . . . . . . . 35 3.4.3. 階層的な方針を使用します: PHB動作. . . . . . . . . . . . . . . . . . . . 36 4のための例。 交通プロフィール。 . . . . . . . . . . . . . . . . . . . . . . 38 4.1. 交通プロフィール. . . . . . . . . . . . . 38に食糧を供給します。
Snir, et al. Standards Track [Page 2] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[2ページ]。
4.2. RSVP Traffic Profiles . . . . . . . . . . . . . . . . . 39
5. Pre-Defined QoS-Related Variables . . . . . . . . . . . . . . 40
6. QoS Related Values. . . . . . . . . . . . . . . . . . . . . . 42
7. Class Definitions: Association Hierarchy. . . . . . . . . . . 44
7.1. The Association "QoSPolicyTrfcProfInAdmissionAction". . 44
7.1.1. The Reference "Antecedent". . . . . . . . . . . 44
7.1.2. The Reference "Dependent" . . . . . . . . . . . 44
7.2. The Association "PolicyConformAction" . . . . . . . . . 44
7.2.1. The Reference "Antecedent". . . . . . . . . . . 45
7.2.2. The Reference "Dependent" . . . . . . . . . . . 45
7.3. The Association "QoSPolicyExceedAction" . . . . . . . . 45
7.3.1. The Reference "Antecedent". . . . . . . . . . . 46
7.3.2. The Reference "Dependent" . . . . . . . . . . . 46
7.4. The Association "PolicyViolateAction" . . . . . . . . . 46
7.4.1. The Reference "Antecedent". . . . . . . . . . . 46
7.4.2. The Reference "Dependent" . . . . . . . . . . . 47
7.5 The Aggregation
"QoSPolicyRSVPVariableInRSVPSimplePolicyAction" . . . . 47
7.5.1. The Reference "GroupComponent". . . . . . . . . 47
7.5.2. The Reference "PartComponent" . . . . . . . . . 47
8. Class Definitions: Inheritance Hierarchy. . . . . . . . . . . 48
8.1. The Class QoSPolicyDiscardAction. . . . . . . . . . . . 48
8.2. The Class QoSPolicyAdmissionAction. . . . . . . . . . . 48
8.2.1. The Property qpAdmissionScope . . . . . . . . . 48
8.3. The Class QoSPolicyPoliceAction . . . . . . . . . . . . 49
8.4. The Class QoSPolicyShapeAction. . . . . . . . . . . . . 49
8.5. The Class QoSPolicyRSVPAdmissionAction. . . . . . . . . 50
8.5.1. The Property qpRSVPWarnOnly . . . . . . . . . . 50
8.5.2. The Property qpRSVPMaxSessions. . . . . . . . . 51
8.6. The Class QoSPolicyPHBAction. . . . . . . . . . . . . . 51
8.6.1. The Property qpMaxPacketSize. . . . . . . . . . 51
8.7. The Class QoSPolicyBandwidthAction. . . . . . . . . . . 52
8.7.1. The Property qpForwardingPriority . . . . . . . 52
8.7.2. The Property qpBandwidthUnits . . . . . . . . . 52
8.7.3. The Property qpMinBandwidth . . . . . . . . . . 53
8.7.4. The Property qpMaxBandwidth . . . . . . . . . . 53
8.7.5. The Property qpMaxDelay . . . . . . . . . . . . 53
8.7.6. The Property qpMaxJitter. . . . . . . . . . . . 53
8.7.7. The Property qpFairness . . . . . . . . . . . . 54
8.8. The Class QoSPolicyCongestionControlAction. . . . . . . 54
8.8.1. The Property qpQueueSizeUnits . . . . . . . . . 54
8.8.2. The Property qpQueueSize. . . . . . . . . . . . 55
8.8.3. The Property qpDropMethod . . . . . . . . . . . 55
8.8.4. The Property qpDropThresholdUnits . . . . . . . 55
8.8.5. The Property qpDropMinThresholdValue. . . . . . 55
8.8.6. The Property qpDropMaxThresholdValue. . . . . . 56
8.9. The Class QoSPolicyTrfcProf . . . . . . . . . . . . . . 56
8.10. The Class QoSPolicyTokenBucketTrfcProf. . . . . . . . . 57
4.2. RSVP交通は.395の輪郭を描きます。 QoS関連の変数. . . . . . . . . . . . . . 40 6を事前に定義しました。 QoSは値を関係づけました。 . . . . . . . . . . . . . . . . . . . . . 42 7. クラス定義: 協会階層構造。 . . . . . . . . . . 44 7.1. 協会"QoSPolicyTrfcProfInAdmissionAction"。 . 44 7.1.1. 「前例」という参照。 . . . . . . . . . . 44 7.1.2. 参照「依存する」. . . . . . . . . . . 44 7.2。 協会"PolicyConformAction". . . . . . . . . 44 7.2.1。 「前例」という参照。 . . . . . . . . . . 45 7.2.2. 参照「依存する」. . . . . . . . . . . 45 7.3。 協会"QoSPolicyExceedAction". . . . . . . . 45 7.3.1。 「前例」という参照。 . . . . . . . . . . 46 7.3.2. 参照「依存する」. . . . . . . . . . . 46 7.4。 協会"PolicyViolateAction". . . . . . . . . 46 7.4.1。 「前例」という参照。 . . . . . . . . . . 46 7.4.2. 参照「依存する」. . . . . . . . . . . 47 7.5集合"QoSPolicyRSVPVariableInRSVPSimplePolicyAction". . . . 47 7.5.1。 参照"GroupComponent"。 . . . . . . . . 47 7.5.2. "PartComponent". . . . . . . . . 47 8という参照。 クラス定義: 遺産階層構造。 . . . . . . . . . . 48 8.1. クラスQoSPolicyDiscardAction。 . . . . . . . . . . . 48 8.2. クラスQoSPolicyAdmissionAction。 . . . . . . . . . . 48 8.2.1. 特性qpAdmissionScope. . . . . . . . . 48 8.3。 クラスQoSPolicyPoliceAction. . . . . . . . . . . . 49 8.4。 クラスQoSPolicyShapeAction。 . . . . . . . . . . . . 49 8.5. クラスQoSPolicyRSVPAdmissionAction。 . . . . . . . . 50 8.5.1. 特性のqpRSVPWarnOnly. . . . . . . . . . 50 8.5.2。 特性のqpRSVPMaxSessions。 . . . . . . . . 51 8.6. クラスQoSPolicyPHBAction。 . . . . . . . . . . . . . 51 8.6.1. 特性のqpMaxPacketSize。 . . . . . . . . . 51 8.7. クラスQoSPolicyBandwidthAction。 . . . . . . . . . . 52 8.7.1. 特性のqpForwardingPriority. . . . . . . 52 8.7.2。 特性のqpBandwidthUnits. . . . . . . . . 52 8.7.3。 特性のqpMinBandwidth. . . . . . . . . . 53 8.7.4。 特性のqpMaxBandwidth. . . . . . . . . . 53 8.7.5。 特性のqpMaxDelay. . . . . . . . . . . . 53 8.7.6。 特性のqpMaxJitter。 . . . . . . . . . . . 53 8.7.7. 特性qpFairness. . . . . . . . . . . . 54 8.8。 クラスQoSPolicyCongestionControlAction。 . . . . . . 54 8.8.1. 特性のqpQueueSizeUnits. . . . . . . . . 54 8.8.2。 特性のqpQueueSize。 . . . . . . . . . . . 55 8.8.3. 特性のqpDropMethod. . . . . . . . . . . 55 8.8.4。 特性のqpDropThresholdUnits. . . . . . . 55 8.8.5。 特性のqpDropMinThresholdValue。 . . . . . 55 8.8.6. 特性のqpDropMaxThresholdValue。 . . . . . 56 8.9. クラスQoSPolicyTrfcProf. . . . . . . . . . . . . . 56 8.10。 クラスQoSPolicyTokenBucketTrfcProf… 57
Snir, et al. Standards Track [Page 3] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[3ページ]。
8.10.1. The Property qpTBRate . . . . . . . . . . . . . 57
8.10.2. The Property qpTBNormalBurst. . . . . . . . . . 57
8.10.3. The Property qpTBExcessBurst. . . . . . . . . . 57
8.11. The Class QoSPolicyIntServTrfcProf. . . . . . . . . . . 57
8.11.1. The Property qpISTokenRate. . . . . . . . . . . 58
8.11.2. The Property qpISPeakRate . . . . . . . . . . . 58
8.11.3. The Property qpISBucketSize . . . . . . . . . . 58
8.11.4. The Property qpISResvRate . . . . . . . . . . . 58
8.11.5. The Property qpISResvSlack. . . . . . . . . . . 59
8.11.6. The Property qpISMinPolicedUnit . . . . . . . . 59
8.11.7. The Property qpISMaxPktSize . . . . . . . . . . 59
8.12. The Class QoSPolicyAttributeValue . . . . . . . . . . . 59
8.12.1. The Property qpAttributeName. . . . . . . . . . 60
8.12.2. The Property qpAttributeValueList . . . . . . . 60
8.13. The Class QoSPolicyRSVPVariable . . . . . . . . . . . . 60
8.14. The Class QoSPolicyRSVPSourceIPv4Variable . . . . . . . 61
8.15. The Class QoSPolicyRSVPDestinationIPv4Variable. . . . . 61
8.16. The Class QoSPolicyRSVPSourceIPv6Variable . . . . . . . 62
8.17. The Class QoSPolicyRSVPDestinationIPv6Variable. . . . . 62
8.18. The Class QoSPolicyRSVPSourcePortVariable . . . . . . . 62
8.19. The Class QoSPolicyRSVPDestinationPortVariable. . . . . 63
8.20. The Class QoSPolicyRSVPIPProtocolVariable . . . . . . . 63
8.21. The Class QoSPolicyRSVPIPVersionVariable. . . . . . . . 63
8.22. The Class QoSPolicyRSVPDCLASSVariable . . . . . . . . . 64
8.23. The Class QoSPolicyRSVPStyleVariable. . . . . . . . . . 64
8.24. The Class QoSPolicyRSVPIntServVariable. . . . . . . . . 65
8.25. The Class QoSPolicyRSVPMessageTypeVariable. . . . . . . 65
8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable . . . 65
8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable. . 66
8.28. The Class QoSPolicyRSVPUserVariable . . . . . . . . . . 66
8.29. The Class QoSPolicyRSVPApplicationVariable. . . . . . . 66
8.30. The Class QoSPolicyRSVPAuthMethodVariable . . . . . . . 67
8.31. The Class QosPolicyDNValue. . . . . . . . . . . . . . . 67
8.31.1. The Property qpDNList . . . . . . . . . . . . . 68
8.32. The Class QoSPolicyRSVPSimpleAction . . . . . . . . . . 68
8.32.1. The Property qpRSVPActionType . . . . . . . . . 68
9. Intellectual Property Rights Statement. . . . . . . . . . . . 69
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 69
11. Security Considerations . . . . . . . . . . . . . . . . . . . 69
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.1. Normative References . . . . . . . . . . . . . . . . . 70
12.2. Informative References . . . . . . . . . . . . . . . . 70
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 72
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 73
8.10.1. 特性のqpTBRate. . . . . . . . . . . . . 57 8.10.2。 特性のqpTBNormalBurst。 . . . . . . . . . 57 8.10.3. 特性のqpTBExcessBurst。 . . . . . . . . . 57 8.11. クラスQoSPolicyIntServTrfcProf… 57 8.11 .1。 特性のqpISTokenRate。 . . . . . . . . . . 58 8.11.2. 特性のqpISPeakRate. . . . . . . . . . . 58 8.11.3。 特性のqpISBucketSize. . . . . . . . . . 58 8.11.4。 特性のqpISResvRate. . . . . . . . . . . 58 8.11.5。 特性のqpISResvSlack。 . . . . . . . . . . 59 8.11.6. 特性のqpISMinPolicedUnit. . . . . . . . 59 8.11.7。 特性qpISMaxPktSize. . . . . . . . . . 59 8.12。 クラスQoSPolicyAttributeValue. . . . . . . . . . . 59 8.12.1。 特性のqpAttributeName。 . . . . . . . . . 60 8.12.2. 特性qpAttributeValueList. . . . . . . 60 8.13。 クラスQoSPolicyRSVPVariable. . . . . . . . . . . . 60 8.14。 クラスQoSPolicyRSVPSourceIPv4Variable. . . . . . . 61 8.15。 クラスQoSPolicyRSVPDestinationIPv4Variable。 . . . . 61 8.16. クラスQoSPolicyRSVPSourceIPv6Variable. . . . . . . 62 8.17。 クラスQoSPolicyRSVPDestinationIPv6Variable。 . . . . 62 8.18. クラスQoSPolicyRSVPSourcePortVariable. . . . . . . 62 8.19。 クラスQoSPolicyRSVPDestinationPortVariable。 . . . . 63 8.20. クラスQoSPolicyRSVPIPProtocolVariable. . . . . . . 63 8.21。 クラスQoSPolicyRSVPIPVersionVariable。 . . . . . . . 63 8.22. クラスQoSPolicyRSVPDCLASSVariable. . . . . . . . . 64 8.23。 クラスQoSPolicyRSVPStyleVariable。 . . . . . . . . . 64 8.24. クラスQoSPolicyRSVPIntServVariable。 . . . . . . . . 65 8.25. クラスQoSPolicyRSVPMessageTypeVariable。 . . . . . . 65 8.26. クラスQoSPolicyRSVPPreemptionPriorityVariable. . . 65 8.27。 クラスQoSPolicyRSVPPreemptionDefPriorityVariable。 . 66 8.28. クラスQoSPolicyRSVPUserVariable. . . . . . . . . . 66 8.29。 クラスQoSPolicyRSVPApplicationVariable。 . . . . . . 66 8.30. クラスQoSPolicyRSVPAuthMethodVariable. . . . . . . 67 8.31。 クラスQosPolicyDNValue。 . . . . . . . . . . . . . . 67 8.31.1. 特性qpDNList. . . . . . . . . . . . . 68 8.32。 クラスQoSPolicyRSVPSimpleAction. . . . . . . . . . 68 8.32.1。 特性qpRSVPActionType. . . . . . . . . 68 9。 知的所有権は声明を正します。 . . . . . . . . . . . 69 10. 承認。 . . . . . . . . . . . . . . . . . . . . . . 69 11. セキュリティ問題. . . . . . . . . . . . . . . . . . . 69 12。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 70 12.1. 引用規格. . . . . . . . . . . . . . . . . 70 12.2。 有益な参照. . . . . . . . . . . . . . . . 70 13。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 72 14. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 73
Snir, et al. Standards Track [Page 4] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[4ページ]。
1. Introduction
1. 序論
The QoS Policy Information Model (QPIM) establishes a standard framework and constructs for specifying and representing policies that administer, manage, and control access to network QoS resources. Such policies will be referred to as "QoS policies" in this document. The framework consists of a set of classes and relationships that are organized in an object-oriented information model. It is agnostic of any specific Policy Decision Point (PDP) or Policy Enforcement Point (PEP) (see [TERMS] for definitions) implementation, and independent of any particular QoS implementation mechanism.
QoS Policy情報Model(QPIM)は、QoSリソースをネットワークでつなぐためにアクセスを管理して、管理して、制御する方針を指定して、表すために標準の枠組みと構造物を確立します。 そのような方針は本書では「QoS方針」と呼ばれるでしょう。 枠組みはオブジェクト指向情報モデルで組織化される1セットのクラスと関係から成ります。 それは、どんな特定のPolicy Decision Point(PDP)かPolicy Enforcement Point(PEP)(定義に関して[TERMS]を見る)実現の不可知論者と、どんな特定のQoS実現メカニズムの独立者です。
QPIM is designed to represent QoS policy information for large-scale policy domains (the term "policy domain" is defined in [TERMS]). A primary goal of this information model is to assist human administrators in their definition of policies to control QoS resources (as opposed to individual network element configuration). The process of creating QPIM data instances is fed by business rules, network topology and QoS methodology (e.g., Differentiated Services).
QPIMは、大規模な方針ドメインのためのQoS方針情報を表すように設計されています(「方針ドメイン」という用語は[TERMS]で定義されます)。 この情報モデルの第一の目標はQoSリソース(個々のネットワーク要素構成と対照的に)を制御するために彼らの方針の定義に人間の管理者を助けることです。 ビジネス規則、ネットワーク形態、およびQoS方法論(例えば、Differentiated Services)でQPIMデータ例を作成する過程を与えます。
This document is based on the IETF Policy Core Information Model and its extensions as specified by [PCIM] and [PCIMe]. QPIM builds upon these two documents to define an information model for QoS enforcement for differentiated and integrated services ([DIFFSERV] and [INTSERV], respectively) using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. This enables various data models (e.g., directory schemata, relational database schemata, and SNMP MIBs) to be designed and implemented according to a single uniform model.
このドキュメントは[PCIM]と[PCIMe]によるIETF Policy Core情報Modelと指定されるとしてのその拡大に基づいています。 QPIMは、微分されて統合しているサービス(それぞれ[DIFFSERV]と[INTSERV])のためのQoS実施のために方針を使用することで情報モデルを定義するためにこれらの2通のドキュメントを当てにします。 このドキュメントが定義上どんな特定のデータ保存メカニズムとアクセス・プロトコルからも独立している情報モデルを定義することに注意するのは重要です。 これは、単独の一定のモデルに従って、様々なデータモデル(例えば、ディレクトリ概要、関係型データベース概要、およびSNMP MIBs)が設計されていて、実行されるのを可能にします。
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 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。
1.1. The Process of QoS Policy Definition
1.1. QoS方針定義の過程
This section describes the process of using QPIM for the definition QoS policy for a policy domain. Figure 1 illustrates information flow and not the actual procedure, which has several loops and feedback not depicted.
このセクションは定義QoS方針に方針ドメインにQPIMを使用する過程について説明します。 図1は数個の輪とフィードバックを持っている実際の手順ではなく、流れが表現しなかった情報を例証します。
Snir, et al. Standards Track [Page 5] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[5ページ]。
---------- ---------- -----------
| Business | | Topology | | QoS |
| Policy | | | |Methodology|
---------- ---------- -----------
| | |
| | |
------------------------------------
|
V
---------------
| QPIM/PCIM(e) |
| modeling |
---------------
|
| --------------
|<----------| Device info, |
| | capabilities |
| --------------
V
(---------------)
( device )---)
( configuration ) )---)
(---------------) ) )
(--------------) )
(-------------)
---------- ---------- ----------- | ビジネス| | トポロジー| | QoS| | 方針| | | |方法論| ---------- ---------- ----------- | | | | | | ------------------------------------ | V--------------- | QPIM/PCIM(e)| | モデル| --------------- | | -------------- | <、-、-、-、-、-、-、-、-、--、| 装置インフォメーション| | | 能力| | -------------- V(---------------)(装置)---) (構成) )---) (---------------) ) ) (--------------) ) (-------------)
Figure 1: The QoS definition information flow
図1: QoS定義情報流動
The process of QoS policy definition is dependent on three types of information: the topology of the network devices under management, the particular type of QoS methodology used (e.g., DiffServ) and the business rules and requirements for specifying service(s) [TERMS] delivered by the network. Both topology and business rules are outside the scope of QPIM. However, important facets of both must be known and understood for correctly specifying the QoS policy.
QoS方針定義の過程は情報の3つのタイプに依存しています: 管理中のネットワーク装置のトポロジー、特定のタイプのQoS方法論はサービス[TERMS]を指定するための規則と要件がネットワークから渡した(例えば、DiffServ)とビジネスを使用しました。 QPIMの範囲の外にトポロジーとビジネス規則の両方があります。 しかしながら、正しくQoS方針を指定するために両方の重要な一面を知られていて、理解しなければなりません。
Typically, the process of QoS policy definition relies on a methodology based on one or more QoS methodologies. For example, the DiffServ methodology may be employed in the QoS policy definition process.
通常、QoS方針定義の過程は1つ以上のQoS方法論に基づく方法論を当てにします。 例えば、DiffServ方法論はQoS方針定義の過程で使われるかもしれません。
The topology of the network consists of an inventory of the network elements that make up the network and the set of paths that traffic may take through the network. For example, a network administrator may decide to use the DiffServ architectural model [DIFFSERV] and classify network devices using the roles "boundary" and "core" (see [TERMS] for a definition of role, and [PCIM] for an explanation of
ネットワークのトポロジーはネットワークを構成しているネットワーク要素の目録と交通がネットワークを通して取るかもしれない経路のセットから成ります。 例えば、ネットワーク管理者がDiffServの建築モデル[DIFFSERV]を使用して、役割の「境界」と「コア」を使用することでネットワーク装置を分類すると決めるかもしれない、(役割のa定義のための[TERMS]、および説明のための[PCIM]を見ます。
Snir, et al. Standards Track [Page 6] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[6ページ]。
how they are used in the policy framework). While this is not a complete topological view of the network, many times it may suffice for the purpose of QoS policy definition.
それらは方針枠組みにどう使用されるか) これはネットワークの完全な位相的な視点ではありませんが、何回も、それはQoS方針定義の目的に十分であるかもしれません。
Business rules are informal sets of requirements for specifying the behavior of various types of traffic that may traverse the network. For example, the administrator may be instructed to implement policy such that VoIP traffic manifests behavior that is similar to legacy voice traffic over telephone networks. Note that this business rule (indirectly) prescribes specific behavior for this traffic type (VoIP), for example in terms of minimal delay, jitter and loss. Other traffic types, such as WEB buying transactions, system backup traffic, video streaming, etc., will express their traffic conditioning requirements in different terms. Again, this information is required not by QPIM itself, but by the overall policy management system that uses QPIM. QPIM is used to help map the business rules into a form that defines the requirements for conditioning different types of traffic in the network.
ビジネス規則は、ネットワークを横断するかもしれない様々なタイプの交通の振舞いを指定するための非公式のセットの要件です。 例えば、管理者が政策を実施するよう命令されるかもしれないので、VoIP交通は電話網の上の遺産音声トラヒックと同様の振舞いを表します。 このビジネス規則が(間接的に)この交通タイプ(VoIP)に特異的行動を定めることに例えば、最小量の遅れ、ジター、および損失で注意してください。 WEB購入取引、システム・バックアップ交通、ビデオ・ストリーミングなどの他の交通タイプは異なった用語によるそれらの交通調節要件を言い表すでしょう。一方、この情報はQPIM自身ではなく、QPIMを使用する総合的な政策管理システムによって必要とされます。 QPIMは、ネットワークの異なったタイプの交通を条件とさせるための要件を定義するフォームにビジネス規則を写像するのを助けるのに使用されます。
The topology, QoS methodology, and business rules are necessary prerequisites for defining traffic conditioning. QPIM enables a set of tools for specifying traffic conditioning policy in a standard manner. Using a standard QoS policy information model such as QPIM is needed also because different devices can have markedly different capabilities. Even the same model of equipment can have different functionality if the network operating system and software running in those devices is different. Therefore, a means is required to specify functionality in a standard way that is independent of the capabilities of different vendors' devices. This is the role of QPIM.
トポロジー、QoS方法論、およびビジネス規則は、交通調節を定義するための必要な前提条件です。 QPIMは標準の方法で交通調節方針を指定するための1セットのツールを可能にします。 また、異なった装置には著しく異なる機能があることができるので、QPIMなどの標準のQoS方針情報モデルを使用するのが必要です。 それらの装置へ駆け込むネットワークOSとソフトウェアが異なるなら、設備の同じモデルさえ異なった機能性を持つことができます。 したがって、手段が、異なった業者の装置の能力から独立している標準の方法で機能性を指定するのに必要です。 これはQPIMの役割です。
In a typical scenario, the administrator would first determine the role(s) that each interface of each network element plays in the overall network topology. These roles define the functions supplied by a given network element independent of vendor and device type. The [PCIM] and [PCIMe] documents define the concept of a role. Roles can be used to identify what parts of the network need which type of traffic conditioning. For example, network interface cards that are categorized as "core" interfaces can be assigned the role name "core-interface". This enables the administrator to design policies to configure all interfaces having the role "core-interface" independent of the actual physical devices themselves. QPIM uses roles to help the administrator map a given set of devices or interfaces to a given set of policy constructs.
典型的なシナリオでは、管理者は、最初に、それぞれ連結するそれぞれのネットワーク要素の役割が総合的なネットワーク形態で果たされると決心しているでしょう。 これらの役割は業者と装置タイプの如何にかかわらず与えられたネットワーク要素によって供給された機能を定義します。 [PCIM]と[PCIMe]ドキュメントは役割の概念を定義します。 ネットワークのどんな部分がどのタイプの交通調節を必要とするかを特定するのに役割を使用できます。 例えば、役割の名前「コアインタフェース」を「コア」インタフェースに割り当てることができるように分類されるインタフェースカードをネットワークでつないでください。 これは、管理者が実際のフィジカル・デバイス自体の如何にかかわらず役割の「コアインタフェース」を持っているすべてのインタフェースを構成するように方針を設計するのを可能にします。 QPIMは、管理者が与えられたセットの装置かインタフェースを与えられたセットの方針構造物に写像するのを助けるのに役割を使用します。
Snir, et al. Standards Track [Page 7] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[7ページ]。
The policy constructs define the functionality required to perform the desired traffic conditioning for particular traffic type(s). The functions themselves depend on the particular type of networking technologies chosen. For example, the DiffServ methodology encourages us to aggregate similar types of traffic by assigning to each traffic class a particular per-hop forwarding behavior on each node. RSVP enables bandwidth to be reserved. These two methodologies can be used separately or in conjunction, as defined by the appropriate business policy. QPIM provides specific classes to enable DiffServ and RSVP conditioning to be modeled.
方針構造物は特定の交通タイプのために必要な交通調節を実行するのに必要である機能性を定義します。 機能自体は選ばれたネットワーク・テクノロジーの特定のタイプに頼っています。 例えば、DiffServ方法論は、私たちが各ノードの上で1ホップあたり1つの特定の推進の振舞いをそれぞれの交通のクラスに配属することによって同様のタイプの交通に集めるよう奨励します。 RSVPは、帯域幅が控えられるのを可能にします。 適切な営業方針によって定義されるように別々にか接続詞にこれらの2つの方法論を使用できます。 QPIMは、DiffServとRSVP調節がモデル化されるのを可能にするために特定のクラスを提供します。
The QPIM class definitions are used to create instances of various policy constructs such as QoS actions and conditions that may be hierarchically organized in rules and groups (PolicyGroup and PolicyRule as defined in [PCIM] and [PCIMe]). Examples of policy actions are rate limiting, jitter control and bandwidth allocation. Policy conditions are constructs that can select traffic according to a complex Boolean expression.
QPIMクラス定義は、階層的で規則とグループ([PCIM]と[PCIMe]で定義されるPolicyGroupとPolicyRule)で組織化されるかもしれないQoS動作や状態などの様々な方針構造物の例を作成するのに使用されます。 政策的措置に関する例は、レート制限と、ジターコントロールと帯域幅配分です。 保険約款は複雑な論理式に従って交通を選択できる構造物です。
A hierarchical organization was chosen for two reasons. First, it best reflects the way humans tend to think about complex policy. Second, it enables policy to be easily mapped onto administrative organizations, as the hierarchical organization of policy mirrors most administrative organizations. It is important to note that the policy definition process described here is done independent of any specific device capabilities and configuration options. The policy definition is completely independent from the details of the implementation and the configuration interface of individual network elements, as well as of the mechanisms that a network element can use to condition traffic.
階層的な組織は2つの理由に選ばれました。 まず最初に、それは人間が、複雑な方針について考える傾向がある方法を最もよく反映します。 2番目に、方針が容易に管理編成に写像されるのを可能にします、方針の階層的な組織がほとんどの管理編成を反映するとき。 どんな特定の装置能力と設定オプションの如何にかかわらずここで説明された方針定義の過程をすることに注意するのは重要です。 方針定義は実現の詳細と個々のネットワーク要素の構成インタフェースから完全に独立しています、よくネットワーク要素が状態交通に使用できるメカニズムのように。
1.2. Design Goals and Their Ramifications
1.2. デザイン目標と彼らの分岐
This section explains the QPIM design goals and how these goals are addressed in this document. This section also describes the ramifications of the design goals and the design decisions made in developing QPIM.
このセクションはQPIMデザイン目標とこれらの目標がどう本書では記述されるかを説明します。 また、このセクションは展開しているQPIMでされたデザイン目標とデザイン決定の分岐について説明します。
1.2.1. Policy-Definition Oriented
1.2.1. 適応する方針定義
The primary design goal of QPIM is to model policies controlling QoS behavior in a way that as closely as possible reflects the way humans tend to think about policy. Therefore, QPIM is designed to address the needs of policy definition and management, and not device/network configuration.
QPIMの第一のデザイン目標は人間が方針について考える傾向がある方法である意味でそれに密接同じくらい可能な振舞いが反映するQoSを制御する方針をモデル化することです。 したがって、QPIMは、装置/ネットワーク・コンフィギュレーションではなく、方針定義と管理の必要性を記述するように設計されています。
Snir, et al. Standards Track [Page 8] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[8ページ]。
There are several ramifications of this design goal. First, QPIM uses rules to define policies, based on [PCIM] and [PCIMe]. Second, QPIM uses hierarchical organizations of policies and policy information extensively. Third, QPIM does not force the policy writer to specify all implementation details; rather, it assumes that configuration agents (PDPs) interpret the policies and match them to suit the needs of device-specific configurations.
このデザイン目標のいくつかの分岐があります。 まず最初に、QPIMは、[PCIM]と[PCIMe]に基づいて方針を定義するのに規則を使用します。 2番目に、QPIMは手広く方針と方針情報の階層的な組織を使用します。 3番目に、方針作家はQPIMによってやむを得ずすべての実現の詳細を指定するというわけではありません。 むしろ、それは、構成エージェント(PDPs)が装置特有の構成の必要性に合うように方針を解釈して、それらに合っていると仮定します。
1.2.1.1. Rule-based Modeling
1.2.1.1. 規則ベースのモデル
Policy is best described using rule-based modeling as explained and described in [PCIM] and [PCIMe]. A QoS policy rule is structured as a condition clause and an action clause. The semantics are simple: if the condition clause evaluates to TRUE, then a set of QoS actions (specified in the action clause) can be executed. For example, the rule:
方針は、説明されるように規則ベースのモデルを使用することで説明するのが最も良く、[PCIM]と[PCIMe]で説明されます。 QoS政策ルールは基本定款と動作節として構造化されます。 意味論は簡単です: 基本定款がTRUE、当時のaセットのQoS機能(動作節では、指定される)に缶を評価するなら、実行されてください。 例えば、規則:
"WEB traffic should receive at least 50% of the available
bandwidth resources or more, when more is available"
「以上が利用可能であるときに、WEB交通は少なくとも50%の利用可能な帯域幅リソースか以上を受け取るべきです」
can be formalized as:
以下として正式にすることができます。
"<If protocol == HTTP> then <minimum BW = 50%>"
「<はプロトコル=HTTP>当時の<最小のBWであるなら50%の>と等しいです」
where the first angle bracketed clause is a traffic condition and the second angle bracketed clause is a QoS action.
最初の角度がどこに節に腕木を付けたかは、交通状態です、そして、2番目の角度の腕木を付けられた節はQoS動作です。
This approach differs from data path modeling that describes the mechanisms that operates on the packet flows to achieve the desired effect.
このアプローチはそれが期待される効果を発揮するためにパケット流れで操作するメカニズムについて説明するデータ経路モデルと異なっています。
Note that the approach taken in QPIM specifically did NOT subclass the PolicyRule class. Rather, it uses the SimplePolicyCondition, CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction classes defined in [PCIMe], as well as defining subclasses of the following classes: Policy, PolicyAction, SimplePolicyAction, PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule class would have made it more difficult to combine actions and conditions defined within different functional domains [PCIMe] within the same rules.
Note that the approach taken in QPIM specifically did NOT subclass the PolicyRule class. Rather, it uses the SimplePolicyCondition, CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction classes defined in [PCIMe], as well as defining subclasses of the following classes: Policy, PolicyAction, SimplePolicyAction, PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule class would have made it more difficult to combine actions and conditions defined within different functional domains [PCIMe] within the same rules.
1.2.1.2. Organize Information Hierarchically
1.2.1.2. Organize Information Hierarchically
The organization of the information represented by QPIM is designed to be hierarchical. To do this, QPIM utilizes the PolicySetComponent aggregation [PCIMe] to provide an arbitrarily nested organization of policy information. A policy group functions as a container of
The organization of the information represented by QPIM is designed to be hierarchical. To do this, QPIM utilizes the PolicySetComponent aggregation [PCIMe] to provide an arbitrarily nested organization of policy information. A policy group functions as a container of
Snir, et al. Standards Track [Page 9] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 9] RFC 3644 Policy QoS Information Model November 2003
policy rules and/or policy groups. A policy rule can also contain policy rules and/or groups, enabling a rule/sub-rule relationship to be realized.
policy rules and/or policy groups. A policy rule can also contain policy rules and/or groups, enabling a rule/sub-rule relationship to be realized.
The hierarchical design decision is based on the realization that it is natural for humans to organize policy rules in groups. Breaking down a complex policy into a set of simple rules is a process that follows the way people tend to think and analyze systems. The complexity of the abstract, business-oriented policy is simplified and made into a hierarchy of simple rules and grouping of simple rules.
The hierarchical design decision is based on the realization that it is natural for humans to organize policy rules in groups. Breaking down a complex policy into a set of simple rules is a process that follows the way people tend to think and analyze systems. The complexity of the abstract, business-oriented policy is simplified and made into a hierarchy of simple rules and grouping of simple rules.
The hierarchical information organization helps to simplify the definition and readability of data instances based on QPIM. Hierarchies can also serve to carry additional semantics for QoS actions in a given context. An example, detailed in section 2.3, demonstrates how hierarchical bandwidth allocation policies can be specified in an intuitive form, without the need to specify complex scheduler structures.
The hierarchical information organization helps to simplify the definition and readability of data instances based on QPIM. Hierarchies can also serve to carry additional semantics for QoS actions in a given context. An example, detailed in section 2.3, demonstrates how hierarchical bandwidth allocation policies can be specified in an intuitive form, without the need to specify complex scheduler structures.
1.2.1.3. Goal-Oriented Policy Definition
1.2.1.3. Goal-Oriented Policy Definition
QPIM facilitates goal-oriented QoS policy definition. This means that the process of defining QoS policy is focused on the desired effect of policies, as opposed to the means of implementing the policy on network elements.
QPIM facilitates goal-oriented QoS policy definition. This means that the process of defining QoS policy is focused on the desired effect of policies, as opposed to the means of implementing the policy on network elements.
QPIM is intended to define a minimal specification of desired network behavior. It is the role of device-specific configuration agents to interpret policy expressed in a standard way and fill in the necessary configuration details that are required for their particular application. The benefit of using QPIM is that it provides a common lingua franca that each of the device- and/or vendor-specific configuration agents can use. This helps ensure a common interpretation of the general policy as well as aid the administrator in specifying a common policy to be implemented across different devices. This is analogous to the fundamental object- oriented paradigm of separating specification from implementation. Using QPIM, traffic conditioning can be specified in a general manner that can help different implementations satisfy a common goal.
QPIM is intended to define a minimal specification of desired network behavior. It is the role of device-specific configuration agents to interpret policy expressed in a standard way and fill in the necessary configuration details that are required for their particular application. The benefit of using QPIM is that it provides a common lingua franca that each of the device- and/or vendor-specific configuration agents can use. This helps ensure a common interpretation of the general policy as well as aid the administrator in specifying a common policy to be implemented across different devices. This is analogous to the fundamental object- oriented paradigm of separating specification from implementation. Using QPIM, traffic conditioning can be specified in a general manner that can help different implementations satisfy a common goal.
For example, a valid policy may include only a single rule that specifies that bandwidth should be reserved for a given set of traffic flows. The rule does not need to include any of the various other details that may be needed for implementing a scheduler that supports this bandwidth allocation (e.g., the queue length required). It is assumed that a PDP or the PEPs would fill in these details using (for example) their default queue length settings. The policy
For example, a valid policy may include only a single rule that specifies that bandwidth should be reserved for a given set of traffic flows. The rule does not need to include any of the various other details that may be needed for implementing a scheduler that supports this bandwidth allocation (e.g., the queue length required). It is assumed that a PDP or the PEPs would fill in these details using (for example) their default queue length settings. The policy
Snir, et al. Standards Track [Page 10] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 10] RFC 3644 Policy QoS Information Model November 2003
writer need only specify the main goal of the policy, making sure that the preferred application receives enough bandwidth to operate adequately.
writer need only specify the main goal of the policy, making sure that the preferred application receives enough bandwidth to operate adequately.
1.2.2. Policy Domain Model
1.2.2. Policy Domain Model
An important design goal of QPIM is to provide a means for defining policies that span numerous devices. This goal differentiates QPIM from device-level information models, which are designed for modeling policy that controls a single device, its mechanisms and capabilities.
An important design goal of QPIM is to provide a means for defining policies that span numerous devices. This goal differentiates QPIM from device-level information models, which are designed for modeling policy that controls a single device, its mechanisms and capabilities.
This design goal has several ramifications. First, roles [PCIM] are used to define policies across multiple devices. Second, the use of abstract policies frees the policy definition process from having to deal with individual device peculiarities, and leaves interpretation and configuration to be modeled by PDPs or other configuration agents. Third, QPIM allows extensive reuse of all policy building blocks in multiple rules used within different devices.
This design goal has several ramifications. First, roles [PCIM] are used to define policies across multiple devices. Second, the use of abstract policies frees the policy definition process from having to deal with individual device peculiarities, and leaves interpretation and configuration to be modeled by PDPs or other configuration agents. Third, QPIM allows extensive reuse of all policy building blocks in multiple rules used within different devices.
1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner
1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner
QPIM models QoS policy in a way designed to be independent of any particular device or vendor. This enables networks made up of different devices that have different capabilities to be managed and controlled using a single standard set of policies. Using such a single set of policies is important because otherwise, the policy will itself reflect the differences between different device implementations.
QPIM models QoS policy in a way designed to be independent of any particular device or vendor. This enables networks made up of different devices that have different capabilities to be managed and controlled using a single standard set of policies. Using such a single set of policies is important because otherwise, the policy will itself reflect the differences between different device implementations.
1.2.2.2. Use Roles for Mapping Policy to Network Devices
1.2.2.2. Use Roles for Mapping Policy to Network Devices
The use of roles enables a policy definition to be targeted to the network function of a network element, rather than to the element's type and capabilities. The use of roles for mapping policy to network elements provides an efficient and simple method for compact and abstract policy definition. A given abstract policy may be mapped to a group of network elements without the need to specify configuration for each of those elements based on the capabilities of any one individual element.
The use of roles enables a policy definition to be targeted to the network function of a network element, rather than to the element's type and capabilities. The use of roles for mapping policy to network elements provides an efficient and simple method for compact and abstract policy definition. A given abstract policy may be mapped to a group of network elements without the need to specify configuration for each of those elements based on the capabilities of any one individual element.
The policy definition is designed to allow aggregating multiple devices within the same role, if desired. For example, if two core network interfaces operate at different rates, one does not have to define two separate policy rules to express the very same abstract policy (e.g., allocating 30% of the interface bandwidth to a given
The policy definition is designed to allow aggregating multiple devices within the same role, if desired. For example, if two core network interfaces operate at different rates, one does not have to define two separate policy rules to express the very same abstract policy (e.g., allocating 30% of the interface bandwidth to a given
Snir, et al. Standards Track [Page 11] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 11] RFC 3644 Policy QoS Information Model November 2003
preferred set of flows). The use of hierarchical context and relative QoS actions in QPIM addresses this and other related problems.
preferred set of flows). The use of hierarchical context and relative QoS actions in QPIM addresses this and other related problems.
1.2.2.3. Reusability
1.2.2.3. Reusability
Reusable objects, as defined by [PCIM] and [PCIMe], are the means for sharing policy building blocks, thus allowing central management of global concepts. QPIM provides the ability to reuse all policy building blocks: variables and values, conditions and actions, traffic profiles, and policy groups and policy rules. This provides the required flexibility to manage large sets of policy rules over large policy domains.
Reusable objects, as defined by [PCIM] and [PCIMe], are the means for sharing policy building blocks, thus allowing central management of global concepts. QPIM provides the ability to reuse all policy building blocks: variables and values, conditions and actions, traffic profiles, and policy groups and policy rules. This provides the required flexibility to manage large sets of policy rules over large policy domains.
For example, the following rule makes use of centrally defined objects being reused (referenced):
For example, the following rule makes use of centrally defined objects being reused (referenced):
If <DestinationAddress == FinanceSubNet> then <DSCP =
MissionCritical>
If <DestinationAddress == FinanceSubNet> then <DSCP = MissionCritical>
In this rule, the condition refers to an object named FinanceSubNet, which is a value (or possibly a set of values) defined and maintained in a reusable objects container. The QoS action makes use of a value named MissionCritical, which is also a reusable object. The advantage of specifying a policy in this way is its inherent flexibility. Given the above policy, whenever business needs require a change in the subnet definition for the organization, all that's required is to change the reusable value FinanceSubNet centrally. All referencing rules are immediately affected, without the need to modify them individually. Without this capability, the repository that is used to store the rules would have to be searched for all rules that refer to the finance subnet, and then each matching rule's condition would have to be individually updated. This is not only much less efficient, but also is more prone to error.
In this rule, the condition refers to an object named FinanceSubNet, which is a value (or possibly a set of values) defined and maintained in a reusable objects container. The QoS action makes use of a value named MissionCritical, which is also a reusable object. The advantage of specifying a policy in this way is its inherent flexibility. Given the above policy, whenever business needs require a change in the subnet definition for the organization, all that's required is to change the reusable value FinanceSubNet centrally. All referencing rules are immediately affected, without the need to modify them individually. Without this capability, the repository that is used to store the rules would have to be searched for all rules that refer to the finance subnet, and then each matching rule's condition would have to be individually updated. This is not only much less efficient, but also is more prone to error.
For a complete description of reusable objects, refer to [PCIM] and [PCIMe].
For a complete description of reusable objects, refer to [PCIM] and [PCIMe].
1.2.3. Enforceable Policy
1.2.3. Enforceable Policy
Policy defined by QPIM should be enforceable. This means that a PDP can use QPIM's policy definition in order to make the necessary decisions and enforce the required policy rules. For example, RSVP admission decisions should be made based on the policy definitions specified by QPIM. A PDP should be able to map QPIM policy definitions into PEP configurations, using either standard or proprietary protocols.
Policy defined by QPIM should be enforceable. This means that a PDP can use QPIM's policy definition in order to make the necessary decisions and enforce the required policy rules. For example, RSVP admission decisions should be made based on the policy definitions specified by QPIM. A PDP should be able to map QPIM policy definitions into PEP configurations, using either standard or proprietary protocols.
Snir, et al. Standards Track [Page 12] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 12] RFC 3644 Policy QoS Information Model November 2003
QPIM is designed to be agnostic of any particular, vendor-dependent technology. However, QPIM's constructs SHOULD always be interpreted so that policy-compliant behavior can be enforced on the network under management. Therefore, there are three fundamental requirements that QPIM must satisfy:
QPIM is designed to be agnostic of any particular, vendor-dependent technology. However, QPIM's constructs SHOULD always be interpreted so that policy-compliant behavior can be enforced on the network under management. Therefore, there are three fundamental requirements that QPIM must satisfy:
1. Policy specified by QPIM must be able to be mapped to actual
network elements.
1. Policy specified by QPIM must be able to be mapped to actual network elements.
2. Policy specified by QPIM must be able to control QoS network
functions without making reference to a specific type of device or
vendor.
2. Policy specified by QPIM must be able to control QoS network functions without making reference to a specific type of device or vendor.
3. Policy specified by QPIM must be able to be translated into
network element configuration.
3. Policy specified by QPIM must be able to be translated into network element configuration.
QPIM satisfies requirements #1 and #2 above by using the concept of roles (specifically, the PolicyRoles property, defined in PCIM). By matching roles assigned to policy groups and to network elements, a PDP (or other enforcement agent) can determine what policy should be applied to a given device or devices.
QPIM satisfies requirements #1 and #2 above by using the concept of roles (specifically, the PolicyRoles property, defined in PCIM). By matching roles assigned to policy groups and to network elements, a PDP (or other enforcement agent) can determine what policy should be applied to a given device or devices.
The use of roles in mapping policy to network elements supports model scalability. QPIM policy can be mapped to large-scale policy domains by assigning a single role to a group of network elements. This can be done even when the policy domain contains heterogeneous devices. So, a small set of policies can be deployed to large networks without having to re-specify the policy for each device separately. This QPIM property is important for QoS policy management applications that strive to ease the task of policy definition for large policy domains.
The use of roles in mapping policy to network elements supports model scalability. QPIM policy can be mapped to large-scale policy domains by assigning a single role to a group of network elements. This can be done even when the policy domain contains heterogeneous devices. So, a small set of policies can be deployed to large networks without having to re-specify the policy for each device separately. This QPIM property is important for QoS policy management applications that strive to ease the task of policy definition for large policy domains.
Requirement #2 is also satisfied by making QPIM domain-oriented (see [TERMS] for a definition of "domain"). In other words, the target of the policy is a domain, as opposed to a specific device or interface.
Requirement #2 is also satisfied by making QPIM domain-oriented (see [TERMS] for a definition of "domain"). In other words, the target of the policy is a domain, as opposed to a specific device or interface.
Requirement #3 is satisfied by modeling QoS conditions and actions that are commonly configured on various devices. However, QPIM is extensible to allow modeling of actions that are not included in QPIM.
Requirement #3 is satisfied by modeling QoS conditions and actions that are commonly configured on various devices. However, QPIM is extensible to allow modeling of actions that are not included in QPIM.
It is important to note that different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy.
It is important to note that different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy.
Snir, et al. Standards Track [Page 13] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 13] RFC 3644 Policy QoS Information Model November 2003
1.2.4. QPIM Covers Both Signaled And Provisioned QoS
1.2.4. QPIM Covers Both Signaled And Provisioned QoS
The two predominant standards-based QoS methodologies developed so far are Differentiated Services (DiffServ) and Integrated Services (IntServ). The DiffServ provides a way to enforce policies that apply to a large number of devices in a scalable manner. QPIM provides actions and conditions that control the classification, policing and shaping done within the differentiated service domain boundaries, as well as actions that control the per-hop behavior within the core of the DiffServ network. QPIM does not mandate the use of DiffServ as a policy methodology.
The two predominant standards-based QoS methodologies developed so far are Differentiated Services (DiffServ) and Integrated Services (IntServ). The DiffServ provides a way to enforce policies that apply to a large number of devices in a scalable manner. QPIM provides actions and conditions that control the classification, policing and shaping done within the differentiated service domain boundaries, as well as actions that control the per-hop behavior within the core of the DiffServ network. QPIM does not mandate the use of DiffServ as a policy methodology.
Integrated services, together with its signaling protocol (RSVP), provides a way for end nodes (and edge nodes) to request QoS from the network. QPIM provides actions that control the reservation of such requests within the network.
Integrated services, together with its signaling protocol (RSVP), provides a way for end nodes (and edge nodes) to request QoS from the network. QPIM provides actions that control the reservation of such requests within the network.
As both methodologies continue to evolve, QPIM does not attempt to provide full coverage of all possible scenarios. Instead, QPIM aims to provide policy control modeling for all major scenarios. QPIM is designed to be extensible to allow for incorporation of control over newly developed QoS mechanisms.
As both methodologies continue to evolve, QPIM does not attempt to provide full coverage of all possible scenarios. Instead, QPIM aims to provide policy control modeling for all major scenarios. QPIM is designed to be extensible to allow for incorporation of control over newly developed QoS mechanisms.
1.2.5. Interoperability for PDPs and Management Applications
1.2.5. Interoperability for PDPs and Management Applications
Another design goal of QPIM is to facilitate interoperability among policy systems such as PDPs and policy management applications. QPIM accomplishes this interoperability goal by standardizing the representation of policy. Producers and consumers of QoS policy need only rely on QPIM-based schemata (and resulting data models) to ensure mutual understanding and agreement on the semantics of QoS policy.
Another design goal of QPIM is to facilitate interoperability among policy systems such as PDPs and policy management applications. QPIM accomplishes this interoperability goal by standardizing the representation of policy. Producers and consumers of QoS policy need only rely on QPIM-based schemata (and resulting data models) to ensure mutual understanding and agreement on the semantics of QoS policy.
For example, suppose that a QoS policy management application, built by vendor A writes its policies based on the LDAP schema that maps from QPIM to a directory implementation using LDAP. Now assume that a separately built PDP from vendor B also relies on this same LDAP schema derived from QPIM. Even though these are two vendors with two different PDPs, each may read the schema of the other and "understand" it. This is because both the management application and the PDP were architected to comply with the QPIM specification. The same is true with two policy management applications. For example, vendor B's policy application may run a validation tool that computes whether there are conflicts within rules specified by the other vendor's policy management application.
For example, suppose that a QoS policy management application, built by vendor A writes its policies based on the LDAP schema that maps from QPIM to a directory implementation using LDAP. Now assume that a separately built PDP from vendor B also relies on this same LDAP schema derived from QPIM. Even though these are two vendors with two different PDPs, each may read the schema of the other and "understand" it. This is because both the management application and the PDP were architected to comply with the QPIM specification. The same is true with two policy management applications. For example, vendor B's policy application may run a validation tool that computes whether there are conflicts within rules specified by the other vendor's policy management application.
Snir, et al. Standards Track [Page 14] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 14] RFC 3644 Policy QoS Information Model November 2003
Interoperability of QPIM producers/consumers is by definition at a high level, and does not guarantee that the same policy will result in the same PEP configuration. First, different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy. Second, different PDPs will also have different capabilities and functions, and may choose to translate the high- level QPIM policy differently depending on the functionality of the PDP, as well as on the capabilities of the PEPs that are being controlled by the PDP. However, the different configurations should still result in the same network behavior as that specified by the policy rules.
Interoperability of QPIM producers/consumers is by definition at a high level, and does not guarantee that the same policy will result in the same PEP configuration. First, different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy. Second, different PDPs will also have different capabilities and functions, and may choose to translate the high- level QPIM policy differently depending on the functionality of the PDP, as well as on the capabilities of the PEPs that are being controlled by the PDP. However, the different configurations should still result in the same network behavior as that specified by the policy rules.
1.3. Modeling Abstract QoS Policies
1.3. Modeling Abstract QoS Policies
This section provides a discussion of QoS policy abstraction and the way QPIM addresses this issue.
This section provides a discussion of QoS policy abstraction and the way QPIM addresses this issue.
As described above, the main goal of the QPIM is to create an information model that can be used to help bridge part of the conceptual gap between a human policy maker and a network element that is configured to enforce the policy. Clearly this wide gap implies several translation levels, from the abstract to the concrete. At the abstract end are the business QoS policy rules. Once the business rules are known, a network administrator must interpret them as network QoS policy and represent this QoS policy by using QPIM constructs. QPIM facilitates a formal representation of QoS rules, thus providing the first concretization level: formally representing humanly expressed QoS policy.
As described above, the main goal of the QPIM is to create an information model that can be used to help bridge part of the conceptual gap between a human policy maker and a network element that is configured to enforce the policy. Clearly this wide gap implies several translation levels, from the abstract to the concrete. At the abstract end are the business QoS policy rules. Once the business rules are known, a network administrator must interpret them as network QoS policy and represent this QoS policy by using QPIM constructs. QPIM facilitates a formal representation of QoS rules, thus providing the first concretization level: formally representing humanly expressed QoS policy.
When a human business executive defines network policy, it is usually done using informal business terms and language. For example, a human may utter a policy statement that reads:
When a human business executive defines network policy, it is usually done using informal business terms and language. For example, a human may utter a policy statement that reads:
"human resources applications should have better QoS than simple
web applications"
"human resources applications should have better QoS than simple web applications"
This might be translated to a slightly more sophisticated form, such as:
This might be translated to a slightly more sophisticated form, such as:
"traffic generated by our human resources applications should have
a higher probability of communicating with its destinations than
traffic generated by people browsing the WEB using non-mission-
critical applications"
"traffic generated by our human resources applications should have a higher probability of communicating with its destinations than traffic generated by people browsing the WEB using non-mission- critical applications"
While this statement clearly defines QoS policy at the business level, it isn't specific enough to be enforceable by network elements. Translation to "network terms and language" is required.
While this statement clearly defines QoS policy at the business level, it isn't specific enough to be enforceable by network elements. Translation to "network terms and language" is required.
Snir, et al. Standards Track [Page 15] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 15] RFC 3644 Policy QoS Information Model November 2003
On the other end of the scale, a network element functioning as a PEP, such as a router, can be configured with specific commands that determine the operational parameters of its inner working QoS mechanisms. For example, the (imaginary) command "output-queue-depth = 100" may be an instruction to a network interface card of a router to allow up to 100 packets to be stored before subsequent packets are discarded (not forwarded). On a different device within the same network, the same instruction may take another form, because a different vendor built that device or it has a different set of functions, and hence implementation, even though it is from the same vendor. In addition, a particular PEP may not have the ability to create queues that are longer than, say, 50 packets, which may result in a different instruction implementing the same QoS policy.
On the other end of the scale, a network element functioning as a PEP, such as a router, can be configured with specific commands that determine the operational parameters of its inner working QoS mechanisms. For example, the (imaginary) command "output-queue-depth = 100" may be an instruction to a network interface card of a router to allow up to 100 packets to be stored before subsequent packets are discarded (not forwarded). On a different device within the same network, the same instruction may take another form, because a different vendor built that device or it has a different set of functions, and hence implementation, even though it is from the same vendor. In addition, a particular PEP may not have the ability to create queues that are longer than, say, 50 packets, which may result in a different instruction implementing the same QoS policy.
The first example illustrates 'abstract policy', while the second illustrates 'concrete configuration'. Furthermore, the first example illustrates end-to-end policy, which covers the conditioning of application traffic throughout the network. The second example illustrates configuration for a particular PEP or a set thereof. While an end-to-end policy statement can only be enforced by configuration of PEPs in various parts of the network, the information model of policy and that of the mechanisms that a PEP uses to implement that policy are vastly different.
The first example illustrates 'abstract policy', while the second illustrates 'concrete configuration'. Furthermore, the first example illustrates end-to-end policy, which covers the conditioning of application traffic throughout the network. The second example illustrates configuration for a particular PEP or a set thereof. While an end-to-end policy statement can only be enforced by configuration of PEPs in various parts of the network, the information model of policy and that of the mechanisms that a PEP uses to implement that policy are vastly different.
The translation process from abstract business policy to concrete PEP configuration is roughly expressed as follows:
The translation process from abstract business policy to concrete PEP configuration is roughly expressed as follows:
1. Informal business QoS policy is expressed by a human policy maker
(e.g., "All executives' WEB requests should be prioritized ahead
of other employees' WEB requests")
1. Informal business QoS policy is expressed by a human policy maker (e.g., "All executives' WEB requests should be prioritized ahead of other employees' WEB requests")
2. A network administrator analyzes the policy domain's topology and
determines the roles of particular device interfaces. A role may
be assigned to a large group of elements, which will result in
mapping a particular policy to a large group of device interfaces.
2. A network administrator analyzes the policy domain's topology and determines the roles of particular device interfaces. A role may be assigned to a large group of elements, which will result in mapping a particular policy to a large group of device interfaces.
3. The network administrator models the informal policy using QPIM
constructs, thus creating a formal representation of the abstract
policy. For example, "If a packet's protocol is HTTP and its
destination is in the 'EXECUTIVES' user group, then assign IPP 7
to the packet header".
3. The network administrator models the informal policy using QPIM constructs, thus creating a formal representation of the abstract policy. For example, "If a packet's protocol is HTTP and its destination is in the 'EXECUTIVES' user group, then assign IPP 7 to the packet header".
4. The network administrator assigns roles to the policy groups
created in the previous step matching the network elements' roles
assigned in step #2 above.
4. The network administrator assigns roles to the policy groups created in the previous step matching the network elements' roles assigned in step #2 above.
Snir, et al. Standards Track [Page 16] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 16] RFC 3644 Policy QoS Information Model November 2003
5. A PDP translates the abstract policy constructs created in step #3
into device-specific configuration commands for all devices
effected by the new policy (i.e., devices that have interfaces
that are assigned a role matching the new policy constructs'
roles). In this process, the PDP consults the particular devices'
capabilities to determine the appropriate configuration commands
implementing the policy.
5. A PDP translates the abstract policy constructs created in step #3 into device-specific configuration commands for all devices effected by the new policy (i.e., devices that have interfaces that are assigned a role matching the new policy constructs' roles). In this process, the PDP consults the particular devices' capabilities to determine the appropriate configuration commands implementing the policy.
6. For each PEP in the network, the PDP (or an agent of the PDP)
issues the appropriate device-specific instructions necessary to
enforce the policy.
6. For each PEP in the network, the PDP (or an agent of the PDP) issues the appropriate device-specific instructions necessary to enforce the policy.
QPIM, PCIM and PCIMe are used in step #3 above.
QPIM, PCIM and PCIMe are used in step #3 above.
1.4. Rule Hierarchy
1.4. Rule Hierarchy
Policy is described by a set of policy rules that may be grouped into subsets [PCIMe]. Policy rules and policy groups can be nested within other policy rules, providing a hierarchical policy definition. Nested rules are also called sub-rules, and we use both terms in this document interchangeably. The aggregation PolicySetComponent (defined in [PCIMe] is used to represent the nesting of a policy rule or group in another policy rule.
Policy is described by a set of policy rules that may be grouped into subsets [PCIMe]. Policy rules and policy groups can be nested within other policy rules, providing a hierarchical policy definition. Nested rules are also called sub-rules, and we use both terms in this document interchangeably. The aggregation PolicySetComponent (defined in [PCIMe] is used to represent the nesting of a policy rule or group in another policy rule.
The hierarchical policy rule definition enhances policy readability and reusability. Within the QoS policy information model, hierarchy is used to model context or scope for the sub-rule actions. Within QPIM, bandwidth allocation policy actions and drop threshold actions use this hierarchal context. First we provide a detailed example of the use of hierarchy in bandwidth allocation policies. The differences between flat and hierarchical policy representation are discussed. The use of hierarchy in drop threshold policies is described in a following subsection. Last but not least, the restrictions on the use of rule hierarchies within QPIM are described.
The hierarchical policy rule definition enhances policy readability and reusability. Within the QoS policy information model, hierarchy is used to model context or scope for the sub-rule actions. Within QPIM, bandwidth allocation policy actions and drop threshold actions use this hierarchal context. First we provide a detailed example of the use of hierarchy in bandwidth allocation policies. The differences between flat and hierarchical policy representation are discussed. The use of hierarchy in drop threshold policies is described in a following subsection. Last but not least, the restrictions on the use of rule hierarchies within QPIM are described.
1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies
1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies
Consider the following example where the informal policy reads:
Consider the following example where the informal policy reads:
On any interface on which these rules apply, guarantee at least
30% of the interface bandwidth to UDP flows, and at least 40% of
the interface bandwidth to TCP flows.
On any interface on which these rules apply, guarantee at least 30% of the interface bandwidth to UDP flows, and at least 40% of the interface bandwidth to TCP flows.
The QoS Policy information model follows the Policy Core information model by using roles as a way to specify the set of interfaces on which this policy applies. The policy does not assume that all interfaces are run at the same speed, or have any other property in
The QoS Policy information model follows the Policy Core information model by using roles as a way to specify the set of interfaces on which this policy applies. The policy does not assume that all interfaces are run at the same speed, or have any other property in
Snir, et al. Standards Track [Page 17] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 17] RFC 3644 Policy QoS Information Model November 2003
common apart from being able to forward packets. Bandwidth is allocated between UDP and TCP flows using percentages of the available interface bandwidth. Assume that we have an available interface bandwidth of 1 Mbits/sec. Then this rule will guarantee 300Kbits/sec to UDP flows. However, if the interface bandwidth was instead only 64kbits/sec, then this rule would correspondingly guarantee 19.2kb/sec.
common apart from being able to forward packets. Bandwidth is allocated between UDP and TCP flows using percentages of the available interface bandwidth. Assume that we have an available interface bandwidth of 1 Mbits/sec. Then this rule will guarantee 300Kbits/sec to UDP flows. However, if the interface bandwidth was instead only 64kbits/sec, then this rule would correspondingly guarantee 19.2kb/sec.
This policy is modeled within QPIM using two policy rules of the form:
This policy is modeled within QPIM using two policy rules of the form:
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1) If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
Assume that these two rules are grouped within a PolicySet [PCIMe] carrying the appropriate role combination. A possible implementation of these rules within a PEP would be to use a Weighted-Round-Robin scheduler with 3 queues. The first queue would be used for UDP traffic, the second queue for TCP traffic and the third queue for the rest of the traffic. The weights of the Weighted-Round-Robin scheduler would be 30% for the first queue, 40% for the second queue and 30% for the last queue.
Assume that these two rules are grouped within a PolicySet [PCIMe] carrying the appropriate role combination. A possible implementation of these rules within a PEP would be to use a Weighted-Round-Robin scheduler with 3 queues. The first queue would be used for UDP traffic, the second queue for TCP traffic and the third queue for the rest of the traffic. The weights of the Weighted-Round-Robin scheduler would be 30% for the first queue, 40% for the second queue and 30% for the last queue.
The actions specifying the bandwidth guarantee implicitly assume that the bandwidth resource being guaranteed is the bandwidth available at the interface level. A PolicyRoleCollection is a class defined in [PCIMe] whose purpose is to identify the set of resources (in this example, interfaces) that are assigned to a particular role. Thus, the type of managed elements aggregated within the PolicyRoleCollection defines the bandwidth resource being controlled. In our example, interfaces are aggregated within the PolicyRoleCollection. Therefore, the rules specify bandwidth allocation to all interfaces that match a given role. Other behavior could be similarly defined by changing what was aggregated within the PolicyRoleCollection.
The actions specifying the bandwidth guarantee implicitly assume that the bandwidth resource being guaranteed is the bandwidth available at the interface level. A PolicyRoleCollection is a class defined in [PCIMe] whose purpose is to identify the set of resources (in this example, interfaces) that are assigned to a particular role. Thus, the type of managed elements aggregated within the PolicyRoleCollection defines the bandwidth resource being controlled. In our example, interfaces are aggregated within the PolicyRoleCollection. Therefore, the rules specify bandwidth allocation to all interfaces that match a given role. Other behavior could be similarly defined by changing what was aggregated within the PolicyRoleCollection.
Normally, a full specification of the rules would require indicating the direction of the traffic for which bandwidth allocation is being made. Using the direction variable defined in [PCIMe], the rules can be specified in the following form:
Normally, a full specification of the rules would require indicating the direction of the traffic for which bandwidth allocation is being made. Using the direction variable defined in [PCIMe], the rules can be specified in the following form:
If (direction is out)
If (IP protocol is UDP) THEN (guarantee 30% of available BW)
If (IP protocol is TCP) THEN (guarantee 40% of available BW)
If (direction is out) If (IP protocol is UDP) THEN (guarantee 30% of available BW) If (IP protocol is TCP) THEN (guarantee 40% of available BW)
where indentation is used to indicate rule nesting. To save space, we omit the direction condition from further discussion.
where indentation is used to indicate rule nesting. To save space, we omit the direction condition from further discussion.
Snir, et al. Standards Track [Page 18] RFC 3644 Policy QoS Information Model November 2003
Snir, et al. Standards Track [Page 18] RFC 3644 Policy QoS Information Model November 2003
Rule nesting provides the ability to further refine the scope of bandwidth allocation within a given traffic class forwarded via these interfaces. The example below adds two nested rules to refine bandwidth allocation for UDP and TCP applications.
Rule nesting provides the ability to further refine the scope of bandwidth allocation within a given traffic class forwarded via these interfaces. The example below adds two nested rules to refine bandwidth allocation for UDP and TCP applications.
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a)
If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)
(IPプロトコル、(プロトコルはTFTPです)THENであるならUDP) THEN(30%の利用可能なBWを保証する)が(1)(10%の利用可能なBWを保証する)である、(1a) If(プロトコルはNFSである)THEN((IPプロトコルはTCPです)THEN(40%の利用可能なBWを保証する)であるなら(2) (プロトコルはHTTPです)THENが20%の利用可能なBWを保証するなら40%の利用可能なBW) (1b)を保証します) (2a) (プロトコルはFTPです) THEN(30%の利用可能なBWを保証します) (2b)
Subrules 1a and 1b specify bandwidth allocation for UDP applications. The total bandwidth resource being partitioned among UDP applications is the bandwidth available for the UDP traffic class (i.e., 30%), not the total bandwidth available at the interface level. Furthermore, TFTP and NFS are guaranteed to get at least 10% and 40% of the total available bandwidth for UDP, while other UDP applications aren't guaranteed to receive anything. Thus, TFTP and NFS are guaranteed to get at least 3% and 12% of the total bandwidth. Similar logic applies to the TCP applications.
Subrules 1aと1bはUDPアプリケーションのための帯域幅配分を指定します。 UDPアプリケーションの中で仕切られる総帯域幅リソースはインタフェースレベルで利用可能な総帯域幅ではなく、UDPトラフィックのクラス(すなわち、30%)に利用可能な帯域幅です。 その上、TFTPとNFSはUDPのために総利用可能な帯域幅の少なくとも10%と40%を得るために保証されます、他のUDPアプリケーションは何も受けるために保証されませんが。 したがって、TFTPとNFSは、総帯域幅の少なくとも3%と12%を得るために保証されます。 同様の論理はTCPアプリケーションに適用されます。
The point of this section will be to show that a hierarchical policy representation enables a finer level of granularity for bandwidth allocation to be specified than is otherwise available using a non- hierarchical policy representation. To see this, let's compare this set of rules with a non-hierarchical (flat) rule representation. In the non-hierarchical representation, the guaranteed bandwidth for TFTP flows is calculated by taking 10% of the bandwidth guaranteed to UDP flows, resulting in 3% of the total interface bandwidth guarantee.
このセクションの先は階層的な方針表現が帯域幅配分が指定されるそうでなければ、非階層的な方針表現を使用することで利用可能であるよりすばらしいレベルの粒状を可能にするのを示すことでしょう。 これを見るために、非階層的な(平坦な)規則表現とこのセットの規則を比べましょう。 非階層的な表現では、TFTPが流れるので、保証された帯域幅はUDP流れに保証された帯域幅の10%取ることによって、計算されます、総インタフェース帯域幅保証の3%をもたらして。
If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a)
If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b)
If (other UDP APPs) THEN (guarantee 15% of available BW) (1c)
If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a)
If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b)
If (other TCP APPs) THEN (guarantee 20% of available BW) (2c)
(UDP AND TFTP)THEN(3%の利用可能なBWを保証する)である、(1a) If(UDP AND NFS)THEN((他のUDP APPs)THEN(15%の利用可能なBWを保証します)(1c)であるなら(TCP AND HTTP)THENが8%の利用可能なBWを保証するなら12%の利用可能なBW) (1b)を保証します) (2a) (TCPとFTP)です。 THEN(12%の利用可能なBWを保証します) (2b) (他のTCPアプリケーション)です。 THEN(20%の利用可能なBWを保証します) (2c)
Are these two representations identical? No, bandwidth allocation is not the same. For example, within the hierarchical representation, UDP applications are guaranteed 30% of the bandwidth. Suppose a single UDP flow of an application different from NFS or TFTP is running. This application would be guaranteed 30% of the interface bandwidth in the hierarchical representation but only 15% of the interface bandwidth in the flat representation.
これらの2つの表現が同じですか? いいえ、帯域幅配分は同じではありません。 例えば、階層的な表現の中では、帯域幅の30%はUDPアプリケーションに保証されます。 独身のUDPがNFSと異なったアプリケーションの流れであると仮定してください。さもないと、TFTPは稼働する予定です。 階層的な表現における、インタフェース帯域幅の30%にもかかわらず、平坦な表現における、インタフェース帯域幅の15%だけがこのアプリケーションに保証されるでしょう。
Snir, et al. Standards Track [Page 19] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[19ページ]。
A two stage scheduler is best modeled by a hierarchical representation whereas a flat representation may be realized by a non-hierarchical scheduler.
階層的な表現で2ステージスケジューラをモデル化するのが最も良いのですが、平坦な表現は非階層的なスケジューラによって実現されるかもしれません。
A schematic hierarchical Weighted-Round-Robin scheduler implementation that supports the hierarchical rule representation is described below.
階層的な規則が表現であるとサポートする概要の階層的なロビンの周りのWeightedスケジューラ実装は以下で説明されます。
--UDP AND TFTP queue--10%
--UDP AND NFS queue--40%-Scheduler-30%--+
--Other UDP queue--50% A1 |
|
--TCP AND HTTP queue--20% |
--TCP AND FTP queue--30%-Scheduler-40%--Scheduler--Interface
--Other TCP queue--50% A2 | B
|
------------Non UDP/TCP traffic-----30%--+
--+--他のUDP待ち行列--UDP AND TFTP待ち行列----UDP AND NFSが列に並ばせる10%--40%からスケジューラ-30%から50%のA1| | --TCP AND HTTP待ち行列--20%| --TCP AND FTPはスケジューラ--インタフェース--他のTCP待ち行列--50%のA2を30%スケジューラ-40%列に並ばせます。| B| ------------非UDP/TCPトラフィック-----30%--+
Scheduler A1 extracts packets from the 3 UDP queues according to the weight specified by the UDP sub-rule policy. Scheduler A2 extracts packets from the 3 TCP queues specified by the TCP sub-rule policy. The second stage scheduler B schedules between UDP, TCP and all other traffic according to the policy specified in the top most rule level.
UDPサブ規則方針で指定された重さに従って、スケジューラA1は3つのUDP待ち行列からパケットを抽出します。 スケジューラA2はTCPサブ規則方針で指定された3つのTCP待ち行列からパケットを抽出します。 UDPと、TCPと方針に従った他のすべてのトラフィックの間の2番目のステージスケジューラBスケジュールは先端でほとんどの規則レベルを指定しました。
Another difference between the flat and hierarchical rule representation is the actual division of bandwidth above the minimal bandwidth guarantee. Suppose two high rate streams are being forwarded via this interface: an HTTP stream and an NFS stream. Suppose that the rate of each flow is far beyond the capacity of the interface. In the flat scheduler implementation, the ratio between the weights is 8:12 (i.e., HTTP:NFS), and therefore HTTP stream would consume 40% of the bandwidth while NFS would consume 60% of the bandwidth. In the hierarchical scheduler implementation the only scheduler that has two queues filled is scheduler B, therefore the ratio between the HTTP (TCP) stream and the NFS (UDP) stream would be 30:40, and therefore the HTTP stream would consume approximately 42% of the interface bandwidth while NFS would consume 58% of the interface bandwidth. In both cases both HTTP and NFS streams got more than the minimal guaranteed bandwidth, but the actual rates forwarded via the interface differ.
平坦で階層的な規則表現の別の違いは最小量の帯域幅保証を超えた帯域幅の実際の分割です。 2つの高い率小川がこのインタフェースを通して進められていると仮定してください: HTTPストリームとNFSは流れます。 それぞれの流れの速度が遠くにインタフェースの容量を超えていると仮定してください。 平坦なスケジューラ実装では、重りの間の比率は8:12(すなわち、HTTP: NFS)です、そして、したがって、NFSが帯域幅の60%を消費しているだろうという間、HTTPストリームは帯域幅の40%を消費するでしょう。 階層的なスケジューラ実装では、2つの待ち行列をいっぱいにする唯一のスケジューラがスケジューラBです、そして、したがって、HTTP(TCP)ストリームとNFS(UDP)ストリームの間の比率は30:40でしょう、そして、したがって、NFSがインタフェース帯域幅の58%を消費しているだろうという間、HTTPストリームはインタフェース帯域幅のおよそ42%を消費するでしょう。 どちらの場合も、HTTPとNFSストリームの両方が最小量の保証された帯域幅以上を得ましたが、インタフェースを通して進められた実際のレートは異なります。
The conclusion is that hierarchical policy representation provides additional structure and context beyond the flat policy representation. Furthermore, policies specifying bandwidth allocation using rule hierarchies should be enforced using hierarchical schedulers where the rule hierarchy level is mapped to the hierarchical scheduler level.
結論は階層的な方針表現が平坦な方針表現を超えて追加構造と文脈を提供するということです。 その上、規則階層構造を使用することで帯域幅配分を指定する方針は、規則階層構造レベルが階層的なスケジューラレベルに写像されるところで階層的なスケジューラを使用することで励行されるべきです。
Snir, et al. Standards Track [Page 20] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[20ページ]。
1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies
1.4.2. 低下敷居方針を説明する規則階層構造の使用
Two major resources govern the per hop behavior in each node. The bandwidth allocation resource governs the forwarding behavior of each traffic class. A scheduler priority and weights are controlled by the bandwidth allocation policies, as well as the (minimal) number of queues needed for traffic separation. A second resource, which is not controlled by bandwidth allocation policies, is the queuing length and drop behavior. For this purpose, queue length and threshold policies are used.
2つの主要なリソースが支配される、各ノードにおけるホップの振舞い単位で。 帯域幅配分リソースはそれぞれのトラフィックのクラスの推進の振舞いを治めます。 スケジューラ優先と重りは帯域幅配分方針で制御されます、トラフィック分離に必要である待ち行列の(最小量)の数と同様に。 2番目のリソース(帯域幅配分方針で制御されない)は、列を作りの長さと低下の振舞いです。 このために、待ち行列の長さと敷居方針は使用されています。
Rule hierarchy is used to describe the context on which thresholds act. The policy rule's condition describes the traffic class and the rule's actions describe the bandwidth allocation, the forwarding priority and the queue length. If the traffic class contains different drop precedence sub-classes that require different thresholds within the same queue, the sub-rules actions describe these thresholds.
規則階層構造は、敷居が行動する文脈について説明するのに使用されます。 政策ルールの状態はトラフィックのクラスについて説明します、そして、規則の動作は帯域幅配分、推進優先権、および待ち行列の長さについて説明します。 トラフィックのクラスが同じ待ち行列の中で異なった敷居を必要とする異なった低下先行サブクラスを含むなら、サブ規則動作はこれらの敷居について説明します。
Below is an example of the use of rule nesting for threshold control purposes. Let's look at the following rules:
以下に、規則巣篭もりの敷居管理目的の使用に関する例があります。 以下の規則を見ましょう:
If (protocol is FTP) THEN (guarantee 10% of available BW)
(queue length equals 40 packets)
(drop technique is random)
(プロトコルはFTPです)THEN(10%の利用可能なBWを保証します)(待ち行列の長さは40のパケットと等しい)です。(低下のテクニックは無作為です)
if (src-ip is from net 2.x.x.x) THEN min threshold = 30%
max threshold = 70%
(src-ipはネットの2.x.x.xから来ています)THEN分敷居が30%の最大敷居と= 70%等しいなら
if (src-ip is from net 3.x.x.x) THEN min threshold = 40%
max threshold = 90%
(src-ipはネットの3.x.x.xから来ています)THEN分敷居が40%の最大敷居と= 90%等しいなら
if (all other) THEN min threshold = 20%
max threshold = 60%
(他の)THEN分敷居が20%の最大敷居と= 60%等しいなら
The rule describes the bandwidth allocation, the queue length and the drop technique assigned to FTP flows. The sub-rules describe the drop threshold priorities within those FTP flows. FTP packets received from all networks apart from networks 2.x.x.x and 3.x.x.x are randomly dropped when the queue threshold for FTP flows accumulates to 20% of the queue length. Once the queue fills to 60%, all these packets are dropped before queuing. The two other sub rules provide other thresholds for FTP packets coming from the specified two subnets. The Assured Forwarding per hop behavior (AF) is another good example of the use of hierarchy to describe the different drop preferences within a traffic class. This example is provided in a later section.
規則はFTP流れに割り当てられた帯域幅配分、待ち行列の長さ、および低下のテクニックについて説明します。 サブ規則はそれらのFTP流れの中で低下敷居プライオリティについて説明します。 FTPが流れるので待ち行列敷居が待ち行列の長さの20%に蓄積するとき、ネットワーク2.x.x.xと3.x.x.xは別としてすべてのネットワークから受け取られたFTPパケットは手当たりしだいに下げられます。 待ち行列がいったん60%までいっぱいになると、これらのすべてのパケットが列を作る前に、下げられます。 他の2つの潜水艦規則が2つの指定されたサブネットから来るFTPパケットに他の敷居を提供します。 ホップの振舞い(AF)あたりのAssured Forwardingはトラフィックのクラスの中で異なった低下好みについて説明する階層構造の使用の別の好例です。 この例を後のセクションに提供します。
Snir, et al. Standards Track [Page 21] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[21ページ]。
1.4.3. Restrictions of the Use of Hierarchy Within QPIM
1.4.3. QPIMの中の階層構造の使用の制限
Rule nesting is used within QPIM for two important purposes:
規則巣篭もりは2つの重要な目的にQPIMの中で使用されます:
1) Enhance clarity, readability and reusability.
1) 明快、読み易さ、およびリユーザビリティを高めてください。
2) Provide hierarchical context for actions.
2) 階層的な関係を動作に提供してください。
The second point captures the ability to specify context for bandwidth allocation, as well as providing context for drop threshold policies.
2番目のポイントは低下敷居方針に文脈を提供することと同様に帯域幅配分に文脈を指定する能力を得ます。
When is a hierarchy level supposed to specify the bandwidth allocation context, when is the hierarchy used for specifying the drop threshold context, and when is it used merely for clarity and reusability? The answer depends entirely on the actions. Bandwidth control actions within a sub-rule specify how the bandwidth allocated to the traffic class determined by the rule's condition clause should be further divided among the sub-rules. Drop threshold actions control the traffic class's queue drop behavior for each of the sub- rules. The bandwidth control actions have an implicit pointer saying: the bandwidth allocation is relative to the bandwidth resources defined by the higher level rule. Drop threshold actions have an implicit pointer saying: the thresholds are taken from the queue resources defined by the higher level rule. Other actions do not have such an implicit pointer, and for these actions hierarchy is used only for reusability and readability purposes.
階層構造レベルはいつ帯域幅配分文脈を指定するべきであるか、そして、階層構造は低下敷居文脈を指定するのにいつ使用されるか、そして、それは単に明快とリユーザビリティにいつ使用されますか? 答えは完全な動作によります。 サブ規則の中の帯域幅コントロール動作は規則の基本定款で決定しているトラフィックのクラスに割り当てられた帯域幅がサブ規則の中でどうさらに分割されるべきであるかを指定します。 低下敷居動作はそれぞれのサブ規則のためのトラフィックのクラスsの待ち行列低下の振舞いを制御します。 帯域幅コントロール動作には、暗黙の指針ことわざがあります: 帯域幅配分は、より高い平らな規則で定義された帯域幅リソースに比例しています。 低下敷居動作には、暗黙の指針ことわざがあります: 敷居は、より高い平らな規則で定義された待ち行列リソースから抜粋されます。 他の動作には、そのような暗黙の指針がありません、そして、これらの動作において、階層構造はリユーザビリティと読み易さ目的にだけ使用されます。
Each rule that includes a bandwidth allocation action implies that a queue should be allocated to the traffic class defined by the rule's condition clause. Therefore, once a bandwidth allocation action exists within the actions of a sub-rule, a threshold action within this sub-rule cannot refer to thresholds of the parent rule's queue. Instead, it must refer to the queue of the sub-rule itself. Therefore, in order to have a clear and unambiguous definition, refinement of thresholds and refinements of bandwidth allocations within sub-rules should be avoided. If both refinements are needed for the same rule, threshold refinements and bandwidth refinements rules should each be aggregated to a separate group, and these groups should be aggregated under the policy rule, using the PolicySetComponent aggregation.
帯域幅配分動作を含んでいる各規則は、待ち行列が規則の基本定款によって定義されたトラフィックのクラスに割り当てられるべきであるのを含意します。 したがって、帯域幅配分動作がサブ規則の動作の中にいったん存在していると、このサブ規則の中の敷居動作は親規則の待ち行列の敷居について言及できません。 代わりに、それはサブ規則自体の待ち行列について言及しなければなりません。 したがって、明確で明白な定義を持つために、サブ規則の中の敷居の気品と帯域幅配分の気品は避けられるべきです。 両方の気品が同じ規則に必要であるなら、敷居気品と帯域幅気品規則はそれぞれ別々のグループに集められるべきです、そして、これらのグループは政策ルールの下で集められるべきです、PolicySetComponent集合を使用して。
Snir, et al. Standards Track [Page 22] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[22ページ]。
1.5. Intended Audiences
1.5. 対象とする訪問者
QPIM is intended for several audiences. The following lists some of the intended audiences and their respective uses:
QPIMは数人の聴衆のために意図します。 以下は対象とする訪問者と彼らのそれぞれの用途のいくつかを記載します:
1. Developers of QoS policy management applications can use this
model as an extensible framework for defining policies to control
PEPs and PDPs in an interoperable manner.
1. QoS政策管理アプリケーションの開発者は、共同利用できる方法でPEPsとPDPsを制御するために方針を定義するのに広げることができるフレームワークとしてこのモデルを使用できます。
2. Developers of Policy Decision Point (PDP) systems built to control
resource allocation signaled by RSVP requests.
2. Policy Decision Point(PDP)システムの開発者は、RSVP要求で合図された資源配分を制御するために建てました。
3. Developers of Policy Decision Points (PDP) systems built to create
QoS configuration for PEPs.
3. Policy Decision Points(PDP)システムの開発者は、PEPsのためのQoS構成を作成するために建てました。
4. Builders of large organization data and knowledge bases who decide
to combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe].
4. すべてのモデルが[PCIM]と[PCIMe]に基づいていると仮定して、他のネットワーク方針情報にQoS方針情報を結合すると決める大きな組織データと知識ベースのビルダー。
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to
map a storage specific technology to QPIM must use this document
as well.
5. 様々な規格の作者は彼らの仕事を機能アップするために本書では導入された構造物を使用するかもしれません。 ストレージ独自技術をQPIMに写像したがっているデータモデルの作者はまた、このドキュメントを使用しなければなりません。
2. Class Hierarchies
2. クラス階層構造
2.1. Inheritance Hierarchy
2.1. 継承階層構造
QPIM's class and association inheritance hierarchies are rooted in [PCIM] and [PCIMe]. Figures 2 and 3 depict these QPIM inheritance hierarchies, while noting their relationships to [PCIM] and [PCIMe]classes. Note that many other classes used to form QPIM policies, such as SimplePolicyCondition, are defined in [PCIM] and [PCIMe]. Thus, the following figures do NOT represent ALL necessary classes and relationships for defining QPIM policies. Rather, the designer using QPIM should use appropriate classes and relationships from [PCIM] and [PCIMe] in conjunction with those defined below.
QPIMのクラスと協会継承階層構造は[PCIM]と[PCIMe]に根づきます。 数字2と3は[PCIM]とのそれらの関係と[PCIMe]のクラスに注意している間、これらのQPIM継承階層構造について表現します。 QPIM方針を形成するのに使用される他の多くのクラスがSimplePolicyConditionなどのように[PCIM]と[PCIMe]で定義されることに注意してください。 したがって、以下の数字は、QPIM方針を定義するためにすべての必要なクラスと関係を表しません。 むしろ、QPIMを使用しているデザイナーは以下で定義されたものに関連して[PCIM]と[PCIMe]から適切なクラスと関係を使用するべきです。
Snir, et al. Standards Track [Page 23] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[23ページ]。
[ManagedElement] (abstract, PCIM) | +--Policy (abstract, PCIM) | | | +---PolicyAction (abstract, PCIM) | | | | | +---SimplePolicyAction (PCIMe) | | | | | | | +---QoSPolicyRSVPSimpleAction (QPIM) | | | | | +---QoSPolicyDiscardAction (QPIM) | | | | | +---QoSPolicyAdmissionAction (abstract, QPIM) | | | | | | | +---QoSPolicyPoliceAction (QPIM) | | | | | | | +---QoSPolicyShapeAction (QPIM) | | | | | | | +---QoSPolicyRSVPAdmissionAction (QPIM) | | | | | +---QoSPolicyPHBAction (abstract, QPIM) | | | | | +---QoSPolicyBandwidthAction (QPIM) | | | | | +---QoSPolicyCongestionControlAction (QPIM) | | | +---QoSPolicyTrfcProf (abstract, QPIM) | | | | | +---QoSPolicyTokenBucketTrfcProf (QPIM) | | | | | +---QoSPolicyIntServTrfcProf (QPIM) | | | | | +---PolicyVariable (abstract, PCIMe) | | | | | +---PolicyImplicitVariable (abstract, PCIMe) | | | | | +---QoSPolicyRSVPVariable (abstract, QPIM) | | | | | +---QoSPolicyRSVPSourceIPv4Variable (QPIM) | | | | | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM) | | | | | +---QoSPolicyRSVPSourceIPv6Variable (QPIM) | | |
[ManagedElement](要約、PCIM)| +--方針(要約、PCIM)| | | +---PolicyAction(要約、PCIM)| | | | | +---SimplePolicyAction(PCIMe)| | | | | | | +---QoSPolicyRSVPSimpleAction(QPIM)| | | | | +---QoSPolicyDiscardAction(QPIM)| | | | | +---QoSPolicyAdmissionAction(要約、QPIM)| | | | | | | +---QoSPolicyPoliceAction(QPIM)| | | | | | | +---QoSPolicyShapeAction(QPIM)| | | | | | | +---QoSPolicyRSVPAdmissionAction(QPIM)| | | | | +---QoSPolicyPHBAction(要約、QPIM)| | | | | +---QoSPolicyBandwidthAction(QPIM)| | | | | +---QoSPolicyCongestionControlAction(QPIM)| | | +---QoSPolicyTrfcProf(要約、QPIM)| | | | | +---QoSPolicyTokenBucketTrfcProf(QPIM)| | | | | +---QoSPolicyIntServTrfcProf(QPIM)| | | | | +---PolicyVariable(要約、PCIMe)| | | | | +---PolicyImplicitVariable(要約、PCIMe)| | | | | +---QoSPolicyRSVPVariable(要約、QPIM)| | | | | +---QoSPolicyRSVPSourceIPv4Variable(QPIM)| | | | | +---QoSPolicyRSVPDestinationIPv4Variable(QPIM)| | | | | +---QoSPolicyRSVPSourceIPv6Variable(QPIM)| | |
(continued on the next page)
(次のページでは、続けられています)
Snir, et al. Standards Track [Page 24] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[24ページ]。
(continued from the previous page)
(前のページから、続けられています)
[ManagedElement] (abstract, PCIM, repeated for convenience) | +--Policy (abstract, PCIM, repeated for convenience) | | | +---PolicyVariable (abstract, PCIMe) | | | | | +---PolicyImplicitVariable (abstract, PCIMe) | | | | | +---QoSPolicyRSVPVariable (abstract, QPIM) | | | | | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM) | | | | | +---QoSPolicyRSVPSourcePortVariable (QPIM) | | | | | +---QoSPolicyRSVPDestinationPortVariable (QPIM) | | | | | +---QoSPolicyRSVPIPProtocolVariable (QPIM) | | | | | +---QoSPolicyRSVPIPVersionVariable (QPIM) | | | | | +---QoSPolicyRSVPDCLASSVariable (QPIM) | | | | | +---QoSPolicyRSVPStyleVariable (QPIM) | | | | | +---QoSPolicyRSVPDIntServVariable (QPIM) | | | | | +---QoSPolicyRSVPMessageTypeVariable (QPIM) | | | | | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM) | | | | | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM) | | | | | +---QoSPolicyRSVPUserVariable (QPIM) | | | | | +---QoSPolicyRSVPApplicationVariable (QPIM) | | | | | +---QoSPolicyRSVPAuthMethodVariable (QPIM) | | | +---PolicyValue (abstract, PCIMe) | | | | | +---QoSPolicyDNValue (QPIM) | | | | | +---QoSPolicyAttributeValue (QPIM)
[ManagedElement](要約(PCIM)は便宜のために繰り返されました)| +--方針(要約(PCIM)は便宜のために繰り返されました)| | | +---PolicyVariable(要約、PCIMe)| | | | | +---PolicyImplicitVariable(要約、PCIMe)| | | | | +---QoSPolicyRSVPVariable(要約、QPIM)| | | | | +---QoSPolicyRSVPDestinationIPv6Variable(QPIM)| | | | | +---QoSPolicyRSVPSourcePortVariable(QPIM)| | | | | +---QoSPolicyRSVPDestinationPortVariable(QPIM)| | | | | +---QoSPolicyRSVPIPProtocolVariable(QPIM)| | | | | +---QoSPolicyRSVPIPVersionVariable(QPIM)| | | | | +---QoSPolicyRSVPDCLASSVariable(QPIM)| | | | | +---QoSPolicyRSVPStyleVariable(QPIM)| | | | | +---QoSPolicyRSVPDIntServVariable(QPIM)| | | | | +---QoSPolicyRSVPMessageTypeVariable(QPIM)| | | | | +---QoSPolicyRSVPPreemptionPriorityVariable(QPIM)| | | | | +---QoSPolicyRSVPPreemptionDefPriorityVariable(QPIM)| | | | | +---QoSPolicyRSVPUserVariable(QPIM)| | | | | +---QoSPolicyRSVPApplicationVariable(QPIM)| | | | | +---QoSPolicyRSVPAuthMethodVariable(QPIM)| | | +---PolicyValue(要約、PCIMe)| | | | | +---QoSPolicyDNValue(QPIM)| | | | | +---QoSPolicyAttributeValue(QPIM)
Figure 2. The QPIM Class Inheritance Hierarchy
図2。 QPIMクラス継承階層構造
Snir, et al. Standards Track [Page 25] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[25ページ]。
2.2. Relationship Hierarchy
2.2. 関係階層構造
Figure 3 shows the QPIM relationship hierarchy.
図3はQPIM関係階層構造を示しています。
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
| |
| +--- QoSPolicyConformAction (QPIM)
| |
| +--- QoSPolicyExceedAction (QPIM)
| |
| +--- QoSPolicyViolateAction (QPIM)
| |
| +--- PolicyVariableInSimplePolicyAction
| | |
| | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction
[「非-根づ」きました] (要約、PCIM)| +---依存(抽象的な)| | | +--- QoSPolicyTrfcProfInAdmissionAction(QPIM)| | | +--- QoSPolicyConformAction(QPIM)| | | +--- QoSPolicyExceedAction(QPIM)| | | +--- QoSPolicyViolateAction(QPIM)| | | +--- PolicyVariableInSimplePolicyAction| | | | | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction
Figure 3. The QPIM Association Class Inheritance Hierarchy
図3。 QPIM協会クラス継承階層構造
3. QoS Actions
3. QoS動作
This section describes the QoS actions that are modeled by QPIM. QoS actions are policy enforced network behaviors that are specified for traffic selected by QoS conditions. QoS actions are modeled using the classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in [PCIMe]) and several QoS actions defined in this document that are derived from both of these classes, which are described below.
このセクションはQPIMによってモデル化されるQoS動作について説明します。 QoS動作はQoS状態によって選択されたトラフィックに指定される方針の実施されたネットワークの振舞いです。 QoS動作は、動作が本書では定義した以下で説明されるこれらのクラスの両方から得られるクラスのPolicyAction([PCIM]では、定義される)、SimplePolicyAction([PCIMe]では、定義される)、および数個のQoSを使用することでモデル化されます。
Note that there is no discussion of PolicyRule, PolicyGroup, or different types of PolicyCondition classes in this document. This is because these classes are fully specified in [PCIM] and [PCIMe].
PolicyRule、PolicyGroup、または異なったタイプのPolicyConditionのクラスの議論が全く本書ではないことに注意してください。 これはこれらのクラスが[PCIM]と[PCIMe]で完全に指定されるからです。
3.1. Overview
3.1. 概要
QoS policy based systems allow the network administrator to specify a set of rules that control both the selection of the flows that need to be provided with a preferred forwarding treatment, as well as specifying the specific set of preferred forwarding behaviors. QPIM provides an information model for specifying such a set of rules.
QoS方針に基づいているシステムで、ネットワーク管理者は都合のよい推進処理が提供される必要がある流れの品揃えと特定が設定した都合のよい推進の振舞いの指定の両方を制御する1セットの規則を指定できます。 QPIMは1セットのそのような規則を指定するのに情報モデルを提供します。
QoS policy rules enable controlling environments in which RSVP signaling is used to request different forwarding treatment for different traffic types from the network, as well as environments where no signaling is used, but preferred treatment is desired for
シグナリングは異なったトラフィックタイプに関するネットワークと異なった推進処理を要求するのに使用されます、合図でないのが使用されていますが、都合のよい処理が望まれている環境と同様にどのRSVPに関して環境を制御する政策ルールが有効にするQoS
Snir, et al. Standards Track [Page 26] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[26ページ]。
some (but not all) traffic types. QoS policy rules also allow controlling environments where strict QoS guarantees are provided to individual flows, as well as environments where QoS is provided to flow aggregates. QoS actions allow a PDP or a PEP to determine which RSVP requests should be admitted before network resources are allocated. QoS actions allow control of the RSVP signaling content itself, as well as differentiation between priorities of RSVP requests. QoS actions allow controlling the Differentiated Service edge enforcement including policing, shaping and marking, as well as the per-hop behaviors used in the network core. Finally, QoS actions can be used to control mapping of RSVP requests at the edge of a differentiated service cloud into per hop behaviors.
何人かの(すべてでない)トラフィックタイプ。 また、QoS政策ルールは、厳しいQoS保証が個々の流れに提供される環境を制御に許容して、QoSが流れるように提供される環境に集合を許容します。 QoS動作で、PDPかPEPが、ネットワーク資源を割り当てる前にどのRSVP要求を認めるべきであるかを決定できます。 QoS動作はRSVPシグナリング内容のコントロール自体、およびRSVP要求のプライオリティの間の分化を許容します。 QoS動作から取り締まって、形成して、マークするのを含むDifferentiated Service縁の実施を、制御します、ネットワークコアで使用される1ホップあたりの振舞いと同様に。 最終的に、差別化されたサービスの縁での要求がホップの振舞い単位で曇るRSVPに関するマッピングを制御するのにQoS動作を使用できます。
Four groups of actions are derived from action classes defined in [PCIM] and [PCIMe]. The first QoS action group contains a single action, QoSPolicyRSVPSimpleAction. This action is used for both RSVP signal control and install actions. The second QoS action group determines whether a flow or class of flows should be admitted. This is done by specifying an appropriate traffic profile using the QoSPolicyTrfcProf class and its subclasses. This set of actions also includes QoS admission control actions, which use the QoSPolicyAdmissionAction class and its subclasses. The third group of actions control bandwidth allocation and congestion control differentiations, which together specify the per-hop behavior forwarding treatment. This group of actions includes the QoSPolicyPHBAction class and its subclasses. The fourth QoS action is an unconditional packet discard action, which uses the QoSPolicyDiscardAction class. This action is used either by itself or as a building block of the QoSPolicyPoliceAction.
[PCIM]と[PCIMe]で定義された動作のクラスから動作の4つのグループを得ます。 QoSPolicyRSVPSimpleAction、最初のQoSアクション・グループはただ一つの動作を含みます。 この動作はRSVPがコントロールに合図する両方に使用されます、そして、動作をインストールしてください。 2番目のQoSアクション・グループは、流れの流れかクラスが認められるべきであるかどうか決定します。 QoSPolicyTrfcProfのクラスとそのサブクラスを使用することで適切なトラフィックプロフィールを指定することによって、これをします。 また、このセットの機能はQoS入場コントロール動作を含んでいます。(動作はQoSPolicyAdmissionActionのクラスとそのサブクラスを使用します)。 動作の3番目のグループは帯域幅配分と輻輳制御分化を制御して、どれが1ホップあたりの振舞い推進処理を一緒に指定しますか? 動作のこのグループはQoSPolicyPHBActionのクラスとそのサブクラスを含んでいます。 4番目のQoS動作は無条件のパケットが動作を捨てるということです。(それは、QoSPolicyDiscardActionのクラスを使用します)。 この動作はそれ自体かQoSPolicyPoliceActionのブロックとして使用されます。
Note that some QoS actions are not directly modeled. Instead, they are modeled by using the class SimplePolicyAction with the appropriate associations. For example, the three marking actions (DSCP, IPP and CoS) are modeled by using the SimplePolicyAction class, and associating that class with variables and values of the appropriate type defined in [PCIMe].
いくつかのQoS動作が直接モデル化されないことに注意してください。 代わりに、それらは、適切な関係と共にクラスSimplePolicyActionを使用することによって、モデル化されます。 例えば、動作が(DSCP、IPP、およびCoS)であるとマークする3は、[PCIMe]で定義される適切なタイプの変数と値にSimplePolicyActionのクラスを使用して、そのクラスを関連づけることによって、モデル化されます。
3.2. RSVP Policy Actions
3.2. RSVP政策的措置
There are three types of decisions a PDP (either remote or within a PEP) can make when it evaluates an RSVP request:
または、決定a PDPの3つのタイプがある、(リモートである、それであるときに、中では、PEP) 缶の造がRSVP要求を評価します:
1. Admit or reject the request 2. Add or modify the request admission parameters 3. Modify the RSVP signaling content
1. 要求2を認めるか、または拒絶してください。 要求入場パラメタ3を加えるか、または変更してください。 RSVPシグナリング内容を変更してください。
Snir, et al. Standards Track [Page 27] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[27ページ]。
The COPS for RSVP [RFC2749] specification uses different Decision object types to model each of these decisions. QPIM follows the COPS for RSVP specification and models each decision using a different action class.
RSVP[RFC2749]仕様のためのCOPSは、それぞれのこれらの決定をモデル化するのに異なったDecisionオブジェクト・タイプを使用します。 QPIMは、RSVP仕様のためのCOPSに続いて、異なった動作のクラスを使用することで各決定をモデル化します。
The QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision Flags objects used within COPS for RSVP. The QoSPolicyRSVPAdmissionAction class, with its associated QoSPolicyIntServTrfcProf class, is used to determine whether to accept or reject a given RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters against the traffic profile specified by the QoSPolicyIntServTrfcProf. For a full description of the comparison method, see section 4. Following the COPS for RSVP specification, the admission decision has an option to both accept the request and send a warning to the requester. The QoSPolicyRSVPAdmissionAction can be used to limit the number of admitted reservations as well.
QoSPolicyRSVPAdmissionActionはオブジェクトがRSVPにCOPSの中で使用したDecision CommandとDecision Flagsを制御します。 QoSPolicyRSVPAdmissionActionのクラスは、QoSPolicyIntServTrfcProfによって指定されたトラフィックプロフィールに対してRSVP要求のTSPECかRSPECパラメタを比較することによって与えられたRSVP要求を受け入れるか、または拒絶するかを決定するのに関連QoSPolicyIntServTrfcProfのクラスと共に使用されます。比較メソッドの余すところのない解説に関して、セクション4を見てください。 RSVP仕様のためのCOPSに続いて、合否判定は、両方へのオプションが要請を受け入れて、警告をリクエスタに送るのをさせます。 また、認められた予約の数を制限するのにQoSPolicyRSVPAdmissionActionを使用できます。
The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to control the two
other COPS RSVP decision types. The property qpRSVPActionType
designates the instance of the class to be either of type 'REPLACE',
'STATELESS', or both ('REPLACEANDSTATELESS'). For instances carrying
a qpRSVPActionType property value of 'REPLACE', the action is
interpreted as a COPS Replace Decision, controlling the contents of
the RSVP message. For instances carrying a qpRSVPActionType property
value of 'STATELESS', the action is interpreted as a COPS Stateless
Decision, controlling the admission parameters. If both of these
actions are required, this can be done by assigning the value
REPLACEANDSTATELESS to the qpRSVPActionType property.
他の2つのCOPS RSVP決定タイプを監督するのに、クラスQoSPolicyRSVPSimpleAction(PolicySimpleActionのクラス[PCIMe]から得られる)を使用できます。 特性のqpRSVPActionTypeは、タイプ'REPLACE'、'STATELESS'、または両方('REPLACEANDSTATELESS')があるようにクラスのインスタンスを指定します。 'REPLACE'のqpRSVPActionType資産価値を運ぶインスタンスにおいて動作はCOPS Replace Decisionとして解釈されます、RSVPメッセージのコンテンツを制御して。 'STATELESS'のqpRSVPActionType資産価値を運ぶインスタンスにおいて動作はCOPS Stateless Decisionとして解釈されます、入場パラメタを制御して。 これらの動作の両方を必要とするなら、値のREPLACEANDSTATELESSをqpRSVPActionTypeの特性に割り当てることによって、これができます。
This class is modeled to represent the COPS for RSVP Replace and Stateless decisions. This similarity allows future use of these COPS decisions to be directly controlled by a QoSPolicySimpleAction. The only required extension might be the definition of a new RSVP variable.
このクラスは、RSVP ReplaceとStateless決定のためにCOPSを表すためにモデル化されます。 この類似性はQoSPolicySimpleActionによって直接制御されるというこれらのCOPS決定の今後の使用を許します。 唯一の必要な拡大は新しいRSVP変数の定義であるかもしれません。
3.2.1. Example: Controlling COPS Stateless Decision
3.2.1. 例: 制御は状態がない決定を獲得します。
The QoSPolicyRSVPSimpleAction allows the specification of admission parameters. It allows specification of the preemption priority [RFC3181] of a given RSVP Reservation request. Using the preemption priority value, the PEP can determine the importance of a Reservation compared with already admitted reservations, and if necessary can preempt lower priority reservations to make room for the higher priority one. This class can also be used to control mapping of RSVP requests to a differentiated services domain by setting the
QoSPolicyRSVPSimpleActionは入場パラメタの仕様を許容します。 それは与えられたRSVP予約要求の先取り優先権[RFC3181]の仕様を許容します。 先取り優先順位の値を使用して、PEPは、既に認められた予約と比べて、予約の重要性を決定できて、必要なら、より高い優先度1に場所を開けるために低優先度の予約を先取りできます。 また、設定のそばで差別化されたサービスドメインにRSVP要求に関するマッピングを制御するのにこのクラスを使用できます。
Snir, et al. Standards Track [Page 28] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[28ページ]。
QoSPolicyRSVPDCLASSVariable to the required value. This instructs the PEP to mark traffic matching the Session and Sender specifications carried in an RSVP request to a given DSCP value.
必要な値へのQoSPolicyRSVPDCLASSVariable。 これは、Sessionに合っているトラフィックとSenderがRSVP要求で与えられたDSCP値まで運ばれた仕様であるとマークするようPEPに命令します。
3.2.2. Example: Controlling the COPS Replace Decision
3.2.2. 例: 巡査を監督して、決定を取り替えてください。
A Policy system should be able to control the information carried in the RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the content of RSVP signaling messages. An RSVP message can carry a preemption policy object [RFC3181] specifying the priority of the reservation request in comparison to other requests. An RSVP message can also carry a policy object for authentication purposes. An RSVP message can carry a DCLASS [DCLASS] object that specifies to the receiver or sender the particular DSCP value that should be set on the data traffic. A COPS for RSVP Replacement Data Decision controls the content of the RSVP message by specifying a set of RSVP objects replacing or removing the existing ones.
PolicyシステムはRSVPメッセージで運ばれた情報を制御するはずであることができます。 QoSPolicyRSVPSimpleActionはRSVPシグナリングメッセージの内容のコントロールを許します。 RSVPメッセージは、比較における、予約の要請の優先権を他の要求に指定しながら、先取り政策目的[RFC3181]を運ぶことができます。 また、RSVPメッセージは認証目的のために政策目的を運ぶことができます。 RSVPメッセージはデータ通信量に設定されるべきである特定のDSCP値を受信機か送付者に指定するDCLASS[DCLASS]オブジェクトを運ぶことができます。 RSVP Replacement Data DecisionのためのCOPSは、既存のものを取り替えるか、または取り除きながら、1セットのRSVPオブジェクトを指定することによって、RSVPメッセージの内容を制御します。
3.3. Provisioning Policy Actions
3.3. 政策的措置に食糧を供給します。
The differentiated Service Architecture [DIFFSERV] was designed to provide a scalable QoS differentiation without requiring any signaling protocols running between the hosts and the network. The QoS actions modeled in QPIM can be used to control all of the building blocks of the Differentiated Service architecture, including per-hop behaviors, edge classification, and policing and shaping, without a need to specify the datapath mechanisms used by PEP implementations. This provides an abstraction level hiding the unnecessary details and allowing the network administrator to write rules that express the network requirements in a more natural form. In this architecture, as no signaling between the end host and the network occurs before the sender starts sending information, the QoS mechanisms should be set up in advance. This usually means that PEPs need to be provisioned with the set of policy rules in advance.
差別化されたService Architecture[DIFFSERV]は、ホストとネットワークの間で稼働するシグナリングプロトコルを必要としないでスケーラブルなQoS分化を提供するように設計されました。 Differentiated Serviceアーキテクチャのブロックのすべてを制御するのにQPIMでモデル化されたQoS動作は使用できます、1ホップあたりの振舞い、縁の分類、取り締まり、および形成を含んでいて、PEP実装によって使用されるdatapathメカニズムを指定する必要性なしで。 これは不要な詳細を隠して、ネットワーク管理者が、より当然のフォームでネットワーク要件を言い表す規則を書くのを許容する抽象度を提供します。 このアーキテクチャでは、送付者が情報を送り始める前に終わりのホストとネットワークの間の合図でないのが起こるとき、QoSメカニズムはあらかじめ、セットアップされるべきです。 通常、これは、PEPsが、あらかじめ政策ルールのセットで食糧を供給される必要を意味します。
Policing and Shaping actions are modeled as subclasses of the QoS admission action. DSCP and CoS marking are modeled by using the SimplePolicyAction ([PCIMe]) class associated with the appropriate variables and values. Bandwidth allocation and congestion control actions are modeled as subclasses of the QpQPolicyPHBAction, which is itself a subclass PolicyAction class ([PCIM])
取り締まりとShaping動作はQoS入場動作のサブクラスとしてモデル化されます。 DSCPとCoSマークは、適切な変数と値に関連しているSimplePolicyAction([PCIMe])のクラスを使用することによって、モデル化されます。 帯域幅配分と輻輳制御動作はQpQPolicyPHBActionのサブクラスとしてモデル化されます。(それ自体で、QpQPolicyPHBActionはサブクラスPolicyActionのクラスです)。([PCIM])
3.3.1. Admission Actions: Controlling Policers and Shapers
3.3.1. 入場動作: Policersとシェーパーズを制御します。
Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used to police and/or shape traffic.
入場Actions(QoSPolicyAdmissionActionとそのサブクラス)は警察、そして/または、形のトラフィックに使用されます。
Snir, et al. Standards Track [Page 29] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[29ページ]。
Each Admission Action is bound to a traffic profile (QoSPolicyTrfcProf) via the QoSPolicyTrfcProfInAdmissionAction association. The traffic profile is used to meter traffic for purposes of policing or shaping.
各Admission ActionはQoSPolicyTrfcProfInAdmissionAction協会を通してトラフィックプロフィール(QoSPolicyTrfcProf)に縛られます。 トラフィックプロフィールは、取り締まりか形成の目的のためにトラフィックを計量するのに使用されます。
An Admission Action carries a scope property (qpAdmissionScope) that is used to determine whether the action controls individual traffic flows or aggregate traffic classes. The concepts of "flow" and "traffic class" are explained in [DIFFSERV] using the terms 'microflow' and 'traffic stream'. Roughly speaking, a flow is a set of packets carrying an IP header that has the same values for source IP, destination IP, protocol and layer 4 source and destination ports. A traffic class is a set of flows. In QPIM, simple and compound conditions can identify flows and/or traffic classes by using Boolean terms over the values of IP header fields, including the value of the ToS byte.
Admission Actionは動作が個々の交通の流れか集合トラフィックのクラスを制御するかどうか決定するのに使用される範囲の特性(qpAdmissionScope)を運びます。 「流れ」と「トラフィックのクラス」の概念は、[DIFFSERV]で用語'microflow'と'トラフィックは流れる'を使用することで説明されます。 大まかに言えば、流れはソースIP、目的地IP、プロトコルと層4のソース、および仕向港まで同じ値を持っているIPヘッダーを運ぶ1セットのパケットです。 トラフィックのクラスは1セットの流れです。 中、QPIMで、簡単である、複合条件は、ToSバイトの値を含むIPヘッダーフィールドの値の上で論理項を使用することによって、流れ、そして/または、トラフィックのクラスを特定できます。
Thus, the interpretation of the scope property is as follows: If the value of the scope property is 0 (per-flow), each (micro) flow that can be positively matched with the rule's condition is metered and policed individually. If the value of the scope property is 1 (per- class), all flows matched with the rule's condition are metered as a single aggregate and policed together.
したがって、範囲の特性の解釈は以下の通りです: 範囲属性の価値が0(流れ)であるなら、明確に規則の状態に合わせることができるそれぞれの(マイクロ)の流れは、個別に計量されて、取り締まられます。 範囲属性の価値が1である、(-、クラス)、規則の状態に合わせられたすべての流れが、ただ一つの集合として計量されて、一緒に取り締まられます。
The following example illustrates the use of the scope property. Using two provisioned policing actions, the following policies can be enforced:
以下の例は範囲の特性の使用を例証します。 動作、以下の方針を取り締まりながら食糧を供給された使用twoは実施できます:
- Make sure that each HTTP flow will not exceed 64kb/s
- それぞれのHTTP流動が64kb/sを超えないのを確実にしてください。
- Make sure that the aggregate rate of all HTTP flows will not
exceed 512Kb/s
- すべてのHTTP流れの集合速度が512KB/sを超えないのを確実にしてください。
Both policies are modeled using the same class QoSPolicyPoliceAction (derived from QoSPolicyAdmissionAction). The first policy has its scope property set to 'flow', while the second policy has its scope property set to 'class'. The two policies are modeled using a rule with two police actions that, in a pseudo-formal definition, looks like the following:
両方の方針は、同じクラスQoSPolicyPoliceAction(QoSPolicyAdmissionActionから、派生する)を使用することでモデル化されます。 最初の方針は範囲の特性が'流れる'ように設定させます、2番目の方針で'クラス'に範囲の特性を設定しますが。 2つの方針が2つの治安活動がある疑似公式の定義で以下に似ている規則を使用することでモデル化されます:
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=class
(HTTP)Action1が警察、トラフィックProfile1=64kb/s流れAction2=Scope1=警察、トラフィックProfile2=512kb/sと等しいなら、Scope2はクラスと等しいです。
The provisioned policing action QoSPolicyPoliceAction has three associations, QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction.
食糧を供給された取り締まり動作QoSPolicyPoliceActionには、3つの協会、QoSPolicyConformAction、QoSPolicyExceedAction、およびQoSPolicyViolateActionがあります。
Snir, et al. Standards Track [Page 30] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[30ページ]。
To accomplish the desired result stated above, two possible modeling techniques may be used: The two actions can be part of a single policy rule using two PolicyActionInPolicyRule [PCIM] associations. In this case the ExecutionStrategy property of the PolicyRule class [PCIMe] SHOULD be set to "Do All" so that both individual flows and aggregate streams are policed.
上に述べられた必要な結果を達成するために、2つの可能なモデリング技法が使用されるかもしれません: 2つの動作が2PolicyActionInPolicyRule[PCIM]協会を使用するただ一つの政策ルールの一部であるかもしれません。 この場合、PolicyRuleのExecutionStrategyの特性はともに個々になるように「すべてをする」セットが流れであったなら[PCIMe]SHOULDを分類します、そして、集合ストリームは取り締まられます。
Alternatively, Action1 and Action2 could be aggregated in a CompundPolicyAction instance using the PolicyActionInPolicyAction aggregations [PCIMe]. In this case, in order for both individual flows and aggregate traffic classes to be policed, the ExecutionStrategy property of the CompoundPolicyAction class [PCIMe] SHOULD be set to "Do All".
あるいはまた、CompundPolicyActionインスタンスでPolicyActionInPolicyAction集合[PCIMe]を使用することでAction1とAction2を集めることができるでしょう。 この場合、個々の流れとトラフィックが取り締まられるために分類する集合、CompoundPolicyActionクラス[PCIMe]SHOULDのExecutionStrategyの特性の両方の注文では、「すべてをします」ように設定されてください。
The policing action is associated with a three-level token bucket traffic profile carrying rate, burst and excess-burst parameters. Traffic measured by a meter can be classified as conforming traffic when the metered rate is below the rate defined by the traffic profile, as excess traffic when the metered traffic is above the normal burst and below the excess burst size, and violating traffic when rate is above the maximum excess burst.
取り締まり動作はレート、炸裂、および余分な炸裂パラメタを載せる3レベルのトークンバケツトラフィックプロフィールに関連しています。 計量されたレートがトラフィックプロフィールによって定義されたレート、計量されたトラフィックが標準を超えているとき、余分なトラフィックがはち切れたおよび余分な放出量を下回っているときトラフィックを従わせるとして1メーターによって測定されたトラフィックは分類できました、そして、レートが最大の過剰を超えているときトラフィックに違反するのははち切れました。
The [DIFF-MIB] defines a two-level meter, and provides a means to combine two-level meters into more complex meters. In this document, a three-level traffic profile is defined. This allows construction of both two-level meters as well as providing an easier definition for three-level meters needed for creating AF [AF] provisioning actions.
[DIFF-MIB]は、2レベルのメーターを定義して、2レベルのメーターをより複雑なメーターに結合する手段を提供します。 本書では、3レベルのトラフィックプロフィールは定義されます。 これは動作に食糧を供給しながらAF[AF]を作成するのに必要である3レベルのメーターのための、より簡単な定義を2レベルのメーターと提供の両方の工事に許します。
A policing action that models three-level policing MUST associate three separate actions with a three-level traffic profile. These actions are a conforming action, an exceeding action and a violating action. A policing action that models two-level policing uses a two-level traffic profile and associates only conforming and exceeding actions. A policing action with a three-level traffic profile that specifies an exceed action but does not specify a violate action implies that the action taken when the traffic is above the maximum excess burst is identical to the action taken when the traffic is above the normal burst. A policer determines whether the profile is being met, while the actions to be performed are determined by the associations QoSPolicyXXXAction.
3レベルの取り締まりをモデル化する取り締まり動作は3レベルのトラフィックプロフィールに3回の別々の動きを関連づけなければなりません。 これらの動作は、従う動作と、上回っている動作と違反動作です。 2レベルの取り締まりをモデル化する取り締まり動作は2レベルのトラフィックプロフィールと動作を従って、超えているだけである仲間を使用します。 aは動作に違反します。指定する3レベルのトラフィックプロフィールによる取り締まり動作、指定しないのを除いて、動作を超えてください、トラフィックが押し破かれた最大の過剰を超えているとき取られた行動が正常な炸裂の上にトラフィックがあるとき取られた行動と同じであることを含意します。 policerは、プロフィールが触れられているかどうか決定します、実行されるべき動作が協会QoSPolicyXXXActionによって決定されますが。
Shapers are used to delay some or all of the packets in a traffic stream, in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-sized buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. Shaping is controlled by the QoSPolicyShapeAction
整形器はトラフィックストリームでパケットのいくつかかすべてを遅らせるのに使用されます、トラフィックプロフィールへの承諾にストリームを運び込むように。 整形器には、通常、有限サイズのバッファがあります、そして、遅れたパケットを保持できるくらいのバッファ領域がなければ、パケットは捨てられるかもしれません。 形成はQoSPolicyShapeActionによって制御されます。
Snir, et al. Standards Track [Page 31] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[31ページ]。
class. The only required association is a traffic profile that specifies the rate and burst parameters that the outgoing flows should conform with.
クラス。 唯一の必要な協会が、レートを指定するトラフィックプロフィールと外向的な流れが従うべきである炸裂パラメタです。
3.3.2. Controlling Markers
3.3.2. マーカーを監督します。
Three types of marking control actions are modeled in QPIM: Differentiated Services Code Point (DSCP) assignment, IP Precedence (IPP) assignment and layer-2 Class of Service (CoS) assignment. These assignment actions themselves are modeled by using the SimplePolicyAction class associated with the appropriate variables and values.
コントロールが動作であるとマークする3つのタイプがQPIMでモデル化されます: Service(CoS)課題のServices Code Point(DSCP)課題、IP Precedence(IPP)課題、および層-2Classを差別化しました。 これらの代入アクション自体は、適切な変数と値に関連しているSimplePolicyActionのクラスを使用することによって、モデル化されます。
DSCP assignment sets ("marks" or "colors") the DS field of a packet
header to a particular DS Code Point (DSCP), adding the marked packet
to a particular DS behavior aggregate.
DSCP課題は特定のDS Code Point(DSCP)にパケットのヘッダーのDS分野を設定します(「マーク」か「色」)、特定のDS振舞い集合に著しいパケットを追加して。
When used in the basic form, "If <condition> then 'DCSP = ds1'", the assignment action assigns a DSCP value (ds1) to all packets that result in the condition being evaluated to true.
基本的なフォーム、「<状態>であるなら、'DCSPはds1と等し'」で使用されると、課題動作が本当に評価される状態をもたらすすべてのパケットにDSCP値(ds1)を割り当てます。
When used in combination with a policing action, a different assignment action can be issued via each of the 'conform', 'exceed' and 'violate' action associations. This way, one may select a PHB in a PHB group according to the state of a meter.
取り締まり動作と組み合わせて使用されると、異なった課題動作は、'従ってください'、それぞれの'超過'を通して発行されて、動作協会に'違反できます'。 このように、1メーターの状態に従って、PHBグループでPHBを選択するかもしれません。
The semantics of the DSCP assignment is encapsulated in the pairing of a DSCP variable and a DSCP value within a single SimplePolicyAction instance via the appropriate associations.
DSCP課題の意味論は適切な協会を通してただ一つのSimplePolicyActionインスタンスの中でDSCP変数とDSCP価値の組み合わせでカプセル化されます。
IPP assignment sets the IPP field of a packet header to a particular IPP value (0 through 7). The semantics of the IPP assignment is encapsulated in the pairing of a ToS variable (PolicyIPTosVariable) and a bit string value () (defined in [PCIMe]) within a single SimplePolicyAction instance via the appropriate associations. The bit string value is used in its masked bit string format. The mask indicates the relevant 3 bits of the IPP sub field within the ToS byte, while the bit string indicates the IPP value to be set.
IPPがさばく特定のIPPへのパケットのヘッダーのIPP課題セットは(0〜7)を評価します。 IPP課題の意味論はToS変数(PolicyIPTosVariable)の組み合わせでカプセル化されます、そして、適切な協会を通してただ一つのSimplePolicyActionインスタンスの中で値()([PCIMe]では、定義されます)を少し結んでください。 ビット列値は仮面のビット列形式に使用されます。 マスクはToSバイトの中にIPP潜水艦分野の関連3ビットを示します、ビット列が設定されるためにIPP値を示しますが。
CoS assignments control the mapping of a per-hop behavior to a layer-2 Class of Service. For example, mapping of a set of DSCP values into a 802.1p user priority value can be specified using a rule with a condition describing the set of DSCP values, and a CoS assignment action that specifies the required mapping to the given user priority value. The semantics of the CoS assignment is encapsulated in the pairing of a CoS variable and a CoS value (integer in the range of 0 through 7) within a single SimplePolicyAction instance via the appropriate associations.
CoS課題はServiceの層-2Classへの1ホップあたり1つの振舞いに関するマッピングを制御します。 例えば、状態がDSCP値のセットについて説明している規則、および与えられたユーザ優先順位の値に必要なマッピングを指定するCoS課題動作を使用することで802.1pユーザ優先順位の値への1セットのDSCP値に関するマッピングを指定できます。 CoS課題の意味論は適切な協会を通してただ一つのSimplePolicyActionインスタンスの中でCoS変数とCoS価値(0〜7の範囲の整数)の組み合わせでカプセル化されます。
Snir, et al. Standards Track [Page 32] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[32ページ]。
3.3.3. Controlling Edge Policies - Examples
3.3.3. 縁の方針を制御します--例
Assuming that the AF1 behavior aggregate is enforced within a DS domain, policy rules on the boundaries of the network should mark packets to one of the AF1x DSCPs, depending on the conformance of the traffic to a predetermined three-parameter traffic profile. QPIM models such AF1 policing action as defined in Figure 4.
AF1振舞い集合がDSドメインの中で励行されると仮定する場合、ネットワークの限界の政策ルールはAF1x DSCPsの1つにパケットをマークするべきです、予定された3パラメタのトラフィックプロフィールへのトラフィックの順応によって。 QPIMは図4で定義されるような動作を取り締まるAF1をモデル化します。
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +--------------------+ +--------------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
* @ +--------------------+ +--------------------------+
* @
* +--------------------+ +---------------------------+
* | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
* +--------------------+ +---------------------------+
*
+--------------------+ +---------------------------+
| SimplePolicyAction |---| PolicyIntegerValue - AF11 |
+--------------------+ +---------------------------+
+-----------------------+ +------------------------------+ | QoSPolicyPoliceAction|====| QoSPolicyTokenBucketTrfcProf| | 範囲はクラスと等しいです。| | =がx、bc=yであると評定してください、そして、=zになってください。| +-----------------------+ +------------------------------+ * @ # * @ # * @ +--------------------+ +--------------------------+ * @ | SimplePolicyAction|---| PolicyIntegerValue -AF13| * @ +--------------------+ +--------------------------+ * @ * +--------------------+ +---------------------------+ * | SimplePolicyAction|---| PolicyIntegerValue--AF12| * +--------------------+ +---------------------------+ * +--------------------+ +---------------------------+ | SimplePolicyAction|---| PolicyIntegerValue--AF11| +--------------------+ +---------------------------+
Association and Aggregation Legend:
協会と集合伝説:
**** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
**** QoSPolicyConformAction@@@@QoSPolicyExceedAction####QoSPolicyViolateAction==== QoSTrfcProfInAdmissionAction---- PolicyValueInSimplePolicyAction、[PCIMe、)、PolicyVariableInSimplePolicyAction[PCIMe]示されないで、
Figure 4. AF Policing and Marking
図4。 AFの取り締まりとマーク
The AF policing action is composed of a police action, a token bucket traffic profile and three instances of the SimplePolicyAction class. Each of the simple policy action instances models a different marking action. Each SimplePolicyAction uses the aggregation PolicyVariableInSimplePolicyAction to specify that the associated PolicyDSCPVariable is set to the appropriate integer value. This is done using the PolicyValueInSimplePolicyAction aggregation. The three PolicyVariableInSimplePolicyAction aggregations which connect the appropriate SimplePolicyActions with the appropriate DSCP
動作を取り締まるAFはSimplePolicyActionのクラスの治安活動、トークンバケツトラフィックプロフィール、および3インスタンスで構成されます。 それぞれの簡単な政策的措置インスタンスは異なったマーク動作をモデル化します。 各SimplePolicyActionは、関連PolicyDSCPVariableが適切な整数値に用意ができていると指定するのに集合PolicyVariableInSimplePolicyActionを使用します。 これはPolicyValueInSimplePolicyAction集合を使用し終わっています。 適切なSimplePolicyActionsを適切なDSCPに接続する3つのPolicyVariableInSimplePolicyAction集合
Snir, et al. Standards Track [Page 33] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[33ページ]。
Variables, are not shown in this figure for simplicity. AF11 is marked on detecting conforming traffic; AF12 is marked on detecting exceeding traffic, and AF13 on detecting violating traffic.
変数は目立たないで、これに簡単さのために計算されるということです。 AF11は検出のときにトラフィックを従わせながら、マークされます。 上回っているトラフィック、およびAF13をトラフィックに違反する検出に検出するとき、AF12はマークされます。
The second example, shown in Figure 5, is the simplest policing action. Traffic below a two-parameter traffic profile is unmodified, while traffic exceeding the traffic profile is discarded.
図5に示される中で2番目の例は動作を取り締まるのにおいて最も簡単です。 2パラメタのトラフィックプロフィールの下のトラフィックは変更されていませんが、トラフィックプロフィールを超えているトラフィックは捨てられます。
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y |
+-----------------------+ +------------------------------+
@
@
+-------------------------+
| QoSPolicyDiscardAction |
+-------------------------+
+-----------------------+ +------------------------------+ | QoSPolicyPoliceAction|====| QoSPolicyTokenBucketTrfcProf| | 範囲はクラスと等しいです。| | レート=x、bc=y| +-----------------------+ +------------------------------+ @ @ +-------------------------+ | QoSPolicyDiscardAction| +-------------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction
協会と集合伝説: **** QoSPolicyConformAction(使用されない)@@@@QoSPolicyExceedAction####QoSPolicyViolateAction(使用されません)==== QoSTrfcProfInAdmissionAction
Figure 5. A Simple Policing Action
図5。 簡単な取り締まり動き
3.4. Per-Hop Behavior Actions
3.4. 1ホップあたりの振舞い動作
A Per-Hop Behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate [DIFFSERV]. The approach taken here is that a PHB action specifies both observable forwarding behavior (e.g., loss, delay, jitter) as well as specifying the buffer and bandwidth resources that need to be allocated to each of the behavior aggregates in order to achieve this behavior. That is, a rule with a set of PHB actions can specify that an EF packet must not be delayed more than 20 msec in each hop. The same rule may also specify that EF packets need to be treated with preemptive forwarding (e.g., with priority queuing), and specify the maximum bandwidth for this class, as well as the maximum buffer resources. PHB actions can therefore be used both to represent the final requirements from PHBs and to provide enough detail to be able to map the PHB actions into a set of configuration parameters to configure queues, schedulers, droppers and other mechanisms.
Per-ホップBehavior(PHB)は特定のDS振舞い集合[DIFFSERV]に適用されたDSノードの外部的に観察可能な推進動きの記述です。 ここに取られたアプローチはPHB動作がこの振舞いを達成するためにそれぞれの振舞い集合に割り当てられる必要がある観察可能な推進の振舞い(例えば、損失、遅れ、ジター)とバッファを指定して、帯域幅リソースの両方を指定するということです。 すなわち、1セットのPHB機能がある規則は、EFパケットが各ホップの遅れた20以上msecであるはずがないと指定できます。 同じ規則は、また、EFパケットが、先買いの推進(例えば、優先権が列を作っている)で扱われる必要であると指定して、このクラスに最大の帯域幅を指定するかもしれません、最大のバッファ資源と同様に。 したがって、PHBsから最終的な要件をともに表して、待ち行列を構成するために1セットの設定パラメータにPHB動作を写像できるためには十分な詳細、スケジューラ、点滴器、および他のメカニズムを提供するのにPHB動作を使用できます。
The QoSPolicyPHBAction abstract class has two subclasses. The QoSPolicyBandwidthAction class is used to control bandwidth, delay and forwarding behavior, while the QoSPolicyCongestionControlAction
QoSPolicyPHBAction抽象クラスには、2つのサブクラスがあります。 QoSPolicyBandwidthActionのクラスは、帯域幅、遅れ、および推進の振舞いを制御するのにQoSPolicyCongestionControlActionである間、使用されます。
Snir, et al. Standards Track [Page 34] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[34ページ]。
class is used to control queue size, thresholds and congestion algorithms. The qpMaxPacketSize property of the QoSPolicyPHBAction class specifies the packet size in bytes, and is needed when translating the bandwidth and congestion control actions into actual implementation configurations. For example, an implementation measuring queue length in bytes will need to use this property to map the qpQueueSize property into the desired queue length in bytes.
クラスは、待ち行列サイズ、敷居、および混雑アルゴリズムを制御するのに使用されます。QoSPolicyPHBActionのクラスのqpMaxPacketSizeの特性が、バイトで表現されるパケットサイズを指定して、帯域幅と輻輳制御動作を実際の実装構成に翻訳するとき、必要です。 例えば、バイトで表現される実装測定待ち行列の長さは、バイトで表現される必要な待ち行列の長さにqpQueueSizeの特性を写像するのにこの特性を使用する必要があるでしょう。
3.4.1. Controlling Bandwidth and Delay
3.4.1. 帯域幅と遅れを制御します。
QoSPolicyBandwidthAction allows specifying the minimal bandwidth that should be reserved for a class of traffic. The property qpMinBandwidth can be specified either in Kb/sec or as a percentage of the total available bandwidth. The property qpBandwidthUnits is used to determine whether percentages or fixed values are used.
QoSPolicyBandwidthActionはトラフィックのクラスのために控えられるべきである最小量の帯域幅を指定させます。 KB/秒か総利用可能な帯域幅の割合として特性のqpMinBandwidthを指定できます。 特性のqpBandwidthUnitsは、割合か一定の価値が使用されているかどうか決定するのに使用されます。
The property qpForwardingPriority is used whenever preemptive forwarding is required. A policy rule that defines the EF PHB should indicate a non-zero forwarding priority. The qpForwardingPriority property holds an integer value to enable multiple levels of preemptive forwarding where higher values are used to specify higher priority.
先買いの推進が必要であるときはいつも、特性のqpForwardingPriorityは使用されています。 EF PHBを定義する政策ルールは非ゼロ推進優先を示すべきです。 qpForwardingPriorityの特性は、より高い値が、より高い優先度を指定するのに使用されるところで複数のレベルの先買いの推進を可能にするために整数値を保持します。
The property qpMaxBandwidth specifies the maximum bandwidth that should be allocated to a class of traffic. This property may be specified in PHB actions with non-zero forwarding priority in order to guard against starvation of other PHBs.
特性のqpMaxBandwidthはトラフィックのクラスに割り当てられるべきである最大の帯域幅を指定します。 この特性は、他のPHBsの飢餓に用心するために非ゼロ推進優先権でPHB動作で指定されるかもしれません。
The properties qpMaxDelay and qpMaxJitter specify limits on the per- hop delay and jitter in milliseconds for any given packet within a traffic class. Enforcement of the maximum delay and jitter may require use of preemptive forwarding as well as minimum and maximum bandwidth controls. Enforcement of low max delay and jitter values may also require fragmentation and interleave mechanisms over low speed links.
特性のqpMaxDelayとqpMaxJitterが限界を指定する、-、トラフィックのクラスの中のあらゆる与えられたパケットのためにミリセカンドで遅れとジターを飛び越してください。 最大の遅れとジターの実施は最小の、そして、最大の帯域幅コントロールと同様に先買いの推進の使用を必要とするかもしれません。 低い最大遅れとジター値の実施は、また、断片化を必要として、低速リンクの上にメカニズムをはさみ込むかもしれません。
The Boolean property qpFairness indicates whether flows should have a fair chance to be forwarded without drop or delay. A way to enforce a bandwidth action with qpFairness set to TRUE would be to build a queue per flow for the class of traffic specified in the rule's filter. In this way, interactive flows like terminal access will not be queued behind a bursty flow (like FTP) and therefore have a reasonable response time.
ブール特性のqpFairnessは、流れには低下も遅れなしで進められるべき十分な機会があるべきであるかどうかを示します。 TRUEに用意ができているqpFairnessとの帯域幅動作を実施する方法は規則のフィルタで指定されたトラフィックのクラスのために1流れあたり1つの待ち行列を組み込むだろうことです。 このように、端末のアクセスがbursty流動(FTPのような)の後ろに列に並ばせられて、したがって、妥当な応答時間を過さないようにインタラクティブは流れます。
3.4.2. Congestion Control Actions
3.4.2. 輻輳制御動作
The QoSPolicyCongestionControlAction class controls queue length, thresholds and congestion control algorithms.
QoSPolicyCongestionControlActionクラスコントロールは長さ、敷居、および輻輳制御アルゴリズムを列に並ばせます。
Snir, et al. Standards Track [Page 35] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[35ページ]。
A PEP should be able to keep in its queues qpQueueSize packets matching the rule's condition. In order to provide a link-speed independent queue size, the qpQueueSize property can also be measured in milliseconds. The time interval specifies the time needed to transmit all packets within the queue if the link speed is dedicated entirely for transmission of packets within this queue. The property qpQueueSizeUnit determines whether queue size is measured in number of packets or in milliseconds. The property qpDropMethod selects either tail-drop, head-drop or random-drop algorithms. The set of maximum and minimum threshold values can be specified as well, using qpDropMinThresholdValue and qpDropMaxThresholdValue properties, either in packets or in percentage of the total available queue size as specified by the qpDropThresholdUnits property.
PEPは待ち行列でqpQueueSizeパケットに規則の状態を合わせ続けるはずであることができます。 また、リンク速度の独立している待ち行列サイズを提供するために、ミリセカンドでqpQueueSizeの特性を測定できます。 リンク速度が完全にパケットのトランスミッションのためにこの待ち行列の中で捧げられるなら待ち行列の中ですべてのパケットを伝えるのが必要であることで、時間間隔は時間を指定します。 特性のqpQueueSizeUnitは、待ち行列サイズがパケットの数かミリセカンドで測定されるかどうか決定します。 特性のqpDropMethodはどちらのテール低下も選択します、落差か無作為の低下アルゴリズム。また、最大の、そして、最小の閾値のセットを指定できます、パケットか指定されるとしてのqpDropThresholdUnitsの特性による総有効な待ち行列サイズの割合にqpDropMinThresholdValueとqpDropMaxThresholdValueの特性を使用して。
3.4.3. Using Hierarchical Policies: Examples for PHB Actions
3.4.3. 階層的な方針を使用します: PHB動作のための例
Hierarchical policy definition is a primary tool in the QoS Policy information model. Rule nesting introduced in [PCIMe] allows specification of hierarchical policies controlling RSVP requests, hierarchical shaping, policing and marking actions, as well as hierarchical schedulers and definition of the differences in PHB groups.
階層的な方針定義はQoS Policy情報モデルのプライマリツールです。 [PCIMe]で導入された規則巣篭もりはRSVP要求、階層的な形成を制御する階層的な方針の仕様を許容します、動作を取り締まって、マークして、PHBグループとの違いの階層的なスケジューラと定義と同様に。
This example provides a set of rules that specify PHBs enforced within a Differentiated Service domain. The network administrator chose to enforce the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not differentiated. The set of rules takes the form:
この例はDifferentiated Serviceドメインの中で実施されたPHBsを指定する1セットの規則を提供します。 ネットワーク管理者は、EF、AF11、AF13、およびBest Effort PHBsを実施するのを選びました。 簡単さにおいて、AF12は差別化されません。 規則のセットは形を取ります:
If (EF) then do EF actions
If (AF1) then do AF1 actions
If (AF11) then do AF11 actions
If (AF12) then do AF12 actions
If (AF13) then do AF13 actions
If (default) then do Default actions.
次に、(EF)が次にIf(AF1)が次に動作If(AF11)が次に動作If(AF12)が次に動作If(AF13)が次に動作If(デフォルト)がするAF13をするAF12をするAF11をするAF1をするEF動作にDefault動作をするなら。
EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic according to DSCP values. The AF1 condition matches the entire AF1 PHB group including the AF11, AF12 and AF13 DSCP values. The default rule specifies the Best Effort rules. The nesting of the AF1x rules within the AF1 rule specifies that there are further refinements on how AF1x traffic should be treated relative to the entire AF1 PHB group. The set of rules reside in a PolicyGroup with a decision strategy property set to 'FirstMatching'.
EF、AF1、AF11、AF12、およびAF13はDSCP値に従ってトラフィックをフィルターにかける状態です。 AF1状態はAF11、AF12、およびAF13 DSCP値を含む全体のAF1 PHBグループに合っています。 省略時の解釈はBest Effort規則を指定します。 AF1規則の中のAF1x規則の巣篭もりは、AF1xトラフィックがどう全体のAF1 PHBグループに比例して扱われるべきであるかにおける気品がさらにあると指定します。 規則のセットはPolicyGroupに決定戦略特性のセットで'FirstMatching'にあります。
The class instances below specify the set of actions used to describe each of the PHBs. Queue sizes are not specified, but can easily be added to the example.
以下のクラスインスタンスはそれぞれのPHBsについて説明するのに使用される動作のセットを指定します。 待ち行列サイズを指定されませんが、容易に例に追加できます。
Snir, et al. Standards Track [Page 36] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[36ページ]。
The actions used to describe the Best Effort PHB are simple. No bandwidth is allocated to Best Effort traffic. The first action specifies that Best Effort traffic class should have fairness.
Best Effort PHBについて説明するのに使用される動きは簡単です。 帯域幅を全くBest Effortトラフィックに割り当てません。 最初の動作は、Best Effortトラフィックのクラスには公正があるべきであると指定します。
QoSPolicyBandwidthAction BE-B:
qpFairness: TRUE
QoSPolicyBandwidthAction、-、B、: qpFairness: 本当
The second action specifies that the congestion algorithm for the Best Effort traffic class should be random, and specifies the thresholds in percentage of the default queue size.
2番目の動作は、Best Effortトラフィックのクラスのための混雑アルゴリズムが無作為であるべきであると指定して、デフォルト待ち行列サイズの割合における敷居を指定します。
QoSPolicyCongestionControlAction BE-C:
qpDropMethod: random
qpDropThresholdUnits %
qpDropMinThreshold: 10%
qpDropMaxThreshold: 70%
QoSPolicyCongestionControlAction、-、C、: qpDropMethod: 無作為のqpDropThresholdUnits%qpDropMinThreshold: 10%のqpDropMaxThreshold: 70%
EF requires preemptive forwarding. The maximum bandwidth is also specified to make sure that the EF class does not starve the other classes. EF PHB uses tail drop as the applications using EF are supposed to be UDP-based and therefore would not benefit from a random dropper.
EFは先買いの推進を必要とします。 また、最大の帯域幅は、EFのクラスが他のクラスを飢えさせないのを確実にするために指定されます。 EF PHBはEFを使用するアプリケーションがUDPベースであるべきであるときにテール低下を使用して、したがって、無作為の点滴器の利益を得ないでしょう。
QoSPolicyBandwidthAction EF-B:
qpForwardingPriority: 1
qpBandwidthUnits: %
qpMaxBandwidth 50%
qpFairness: FALSE
QoSPolicyBandwidthAction EF-B: qpForwardingPriority: 1qpBandwidthUnits: %のqpMaxBandwidthの50%のqpFairness: 誤る
QoSPolicyCongestionControlAction EF-C:
qpDropMethod: tail-drop
qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packets
QoSPolicyCongestionControlAction EF-C: qpDropMethod: テール低下qpDropThresholdUnitsパケットqpDropMaxThreshold: 3つのパケット
The AF1 actions define the bandwidth allocations for the entire PHB group:
AF1動作は全体のPHBグループのために帯域幅配分を定義します:
QoSPolicyBandwidthAction AF1-B:
qpBandwidthUnits: %
qpMinBandwidth: 30%
QoSPolicyBandwidthAction AF1-B: qpBandwidthUnits: %qpMinBandwidth: 30%
The AF1i actions specifies the differentiating refinement for the AF1x PHBs within the AF1 PHB group. The different threshold values provide the difference in discard probability of the AF1x PHBs within the AF1 PHB group.
AF1i動作はAF1 PHBグループの中で差別化気品をAF1x PHBsに指定します。 異なった閾値はAF1 PHBグループの中でAF1x PHBsの確率を破棄の違いに提供します。
Snir, et al. Standards Track [Page 37] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[37ページ]。
QoSPolicyCongestionControlAction AF11-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 6 packets
qpDropMaxThreshold: 16 packets
QoSPolicyCongestionControlAction AF11-C: qpDropMethod: 無作為のqpDropThresholdUnitsパケットqpDropMinThreshold: 6 パケットqpDropMaxThreshold: 16のパケット
QoSPolicyCongestionControlAction AF12-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 13 packets
QoSPolicyCongestionControlAction AF12-C: qpDropMethod: 無作為のqpDropThresholdUnitsパケットqpDropMinThreshold: 4 パケットqpDropMaxThreshold: 13のパケット
QoSPolicyCongestionControlAction AF13-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets
QoSPolicyCongestionControlAction AF13-C: qpDropMethod: 無作為のqpDropThresholdUnitsパケットqpDropMinThreshold: 2 パケットqpDropMaxThreshold: 10のパケット
4. Traffic Profiles
4. トラフィックプロフィール
Meters measure the temporal state of a flow or a set of flows against a traffic profile. In this document, traffic profiles are modeled by the QoSPolicyTrfcProf class. The association QoSPolicyTrfcProf InAdmissionAction binds the traffic profile to the admission action using it. Two traffic profiles are derived from the abstract class QoSPolicyTrfcProf. The first is a Token Bucket provisioning traffic profile carrying rate and burst parameters. The second is an RSVP traffic profile, which enables flows to be compared with RSVP TSPEC and FLOWSPEC parameters.
メーターはトラフィックプロフィールに対して流れの時の状態か1セットの流れを測定します。 本書では、トラフィックプロフィールはQoSPolicyTrfcProfのクラスによってモデル化されます。 協会QoSPolicyTrfcProf InAdmissionActionは、それを使用することで入場動作にトラフィックプロフィールを縛ります。 抽象クラスQoSPolicyTrfcProfから2個のトラフィックプロフィールを得ます。1番目はレートを載せるトラフィックプロフィールと炸裂パラメタに食糧を供給するToken Bucketです。 2番目はRSVPトラフィックプロフィールです。(そのプロフィールは、流れがRSVP TSPECとFLOWSPECパラメタにたとえられるのを可能にします)。
4.1. Provisioning Traffic Profiles
4.1. トラフィックプロフィールに食糧を供給します。
Provisioned Admission Actions, including shaping and policing, are specified using a two- or three-parameter token bucket traffic profile. The QoSPolicyTokenBucketTrfcProf class includes the following properties:
形成して、取り締まるのを含む食糧を供給されたAdmission Actionsが、2か3パラメタのトークンバケツトラフィックプロフィールを使用することで指定されます。 QoSPolicyTokenBucketTrfcProfのクラスは以下の特性を含んでいます:
1. Rate measured in kbits/sec 2. Normal burst measured in bytes 3. Excess burst measured in bytes
1. kbits/秒2で測定されていた状態で、評価してください。 正常な炸裂はバイト3で測定しました。 バイトで測定された余分な炸裂
Rate determines the long-term average transmission rate. Traffic that falls under this rate is conforming, as long as the normal burst is not exceeded at any time. Traffic exceeding the normal burst but still below the excess burst is exceeding the traffic profile. Traffic beyond the excess burst is said to be violating the traffic profile.
レートは長期の平均した通信速度を決定します。 正常な炸裂がいつでも超えられていない限り、このレートの下で下がるトラフィックは従っています。 標準を超えているトラフィックが、はち切れますが、まだ余分な炸裂の下でトラフィックプロフィールを超えています。 余分な炸裂を超えたトラフィックはトラフィックプロフィールに違反していると言われています。
Snir, et al. Standards Track [Page 38] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[38ページ]。
Excess burst size is measured in bytes in addition to the burst size. A zero excess burst size indicates that no excess burst is allowed.
余分な放出量は放出量に加えたバイトで測定されます。 ゼロ余分な放出量は、どんな余分な炸裂も許容されていないのを示します。
4.2. RSVP traffic profiles
4.2. RSVPトラフィックプロフィール
RSVP admission policy can condition the decision whether to accept or deny an RSVP request based on the traffic specification of the flow (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The admission decision can be based on matching individual RSVP requests against a traffic profile or by matching the aggregated sum of all FLOWSPECs (TSPECs) currently admitted, as determined by the qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction.
RSVP入場方針は流れのトラフィック仕様(TSPEC)かリソースが要求したQoSの量(FLOWSPEC)に基づくRSVP要求を受け入れるか、または否定するかという決定を条件とさせることができます。 合否判定がトラフィックプロフィールに対して個々のRSVP要求に合っていることに基づいて現在認められているすべてのFLOWSPECs(TSPECs)の集められた合計に匹敵することによって、あることができます、関連QoSPolicyRSVPAdmissionActionのqpAdmissionScopeの特性で決定するように。
The QoSPolicyIntservTrfcProf class models both such traffic profiles. This class has the following properties:
QoSPolicyIntservTrfcProfのクラスはそのようなプロフィールのトラフィック両方をモデル化します。 このクラスには、以下の特性があります:
1. Token Rate (r) measured in bits/sec
2. Peak Rate (p) measured in bits/sec
3. Bucket Size (b) measured in bytes
4. Min Policed unit (m) measured in bytes
5. Max packet size (M) measured in bytes
6. Resv Rate (R) measured in bits/sec
7. Slack term (s) measured in microseconds
1. トークンRate(r)はビット/秒の2で測定しました。 ピークRate(p)はビット/秒の3で測定しました。 バケツSize(b)はバイト4で測定しました。 Policedユニット(m)がバイト5で測定した分。 バイト6で測定されたマックスパケットサイズ(M)。 Resv Rate(R)はビット/秒の7で測定しました。 マイクロセカンドのときに測定された低調な用語
The first five parameters are the traffic specification parameters used in the Integrated Service architecture ([INTSERV]). These parameters are used to define a sender TSPEC as well as a FLOWSPEC for the Controlled-Load service [CL]. For a definition and full explanation of their meanings, please refer to [RSVP-IS].
最初の5つのパラメタがIntegrated Serviceアーキテクチャ([INTSERV])に使用されるトラフィック仕様パラメタです。 これらのパラメタは、Controlled-負荷サービス[CL]のためのFLOWSPECと同様に送付者TSPECを定義するのに使用されます。 それらの意味に関する定義と詳報について、参照してください、[RSVP存在、]
Parameters 6 and 7 are the additional parameters used for specification of the Guaranteed Service FLOWSPEC [GS].
パラメタ6と7はGuaranteed Service FLOWSPEC[GS]の仕様に使用される追加パラメタです。
A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the same ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) is either smaller or equal to the traffic profile. Only parameters specified in the traffic profile are compared.
部分的なオーダーはTSPECs(そして、FLOWSPECs)の間で定義されます。 そして、TSPEC AがTSPEC Bより大きい、rA>rBと、pA>pBと、bA>bBと、mA<mBとMA>MBである場合にだけ。 トラフィックプロフィールに対して測定されたTSPEC(FLOWSPEC)は同じ注文規則を使用します。 TSPEC(FLOWSPEC)がトラフィックプロフィールと、より小さいか、または等しい場合にだけ、RSVPメッセージを受け入れます。 トラフィックプロフィールで指定されたパラメタだけが比較されます。
The GS FLOWSPEC is compared against the rate R and the slack term s. The term R should not be larger than the traffic profile R parameter, while the FLOWSPEC slack term should not be smaller than that specified in the slack term.
GS FLOWSPECはレートRと低調な用語sに対して比較されます。 用語RはトラフィックプロフィールRパラメタより大きいはずがありません、FLOWSPECの低調な用語がそれが低調な用語で指定したより小さいはずがありませんが。
Snir, et al. Standards Track [Page 39] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[39ページ]。
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is computed by summing the rate r, the peak rate p, the bucket size b, and by taking the minimum value of the minimum policed unit m and the maximum value of the maximum packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules are used to compute the temporal state of admitted RSVP states matching the traffic class defined by the rule condition. This state is compared with the traffic profile to arrive at an admission decision when the scope of the QoSPolicyRSVPAdmissionAction is set to 'class'.
FLOWSPECsと同様にTSPECsを加えることができます。 合計2TSPECsがレートrをまとめることによって、計算されます、ピークレートp、バケツサイズb、そして、最小の取り締まられたユニットmの最小値と最大のパケットサイズの最大値を取ることによって、M.GS FLOWSPECsはResvレートを加えて、低調な用語sを最小にすることによって、まとめられます。 これらの規則は、規則状態によって定義されたトラフィックのクラスに合っている認められたRSVP州の時の状態を計算するのに使用されます。 この状態は、QoSPolicyRSVPAdmissionActionの範囲がいつ'クラス'に設定されるかという合否判定に到達するようにトラフィックプロフィールと比較されます。
5. Pre-Defined QoS-Related Variables
5. 事前に定義されたQoS関連の変数
Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. The purpose of this section is to define frequently used variables in QoS policy domains.
事前に定義された変数が方針サーバと政策管理ツールの中で異なったベンダーから相互運用性を確実にするのに必要です。 このセクションの目的はQoS方針ドメインで頻繁に使用された変数を定義することです。
Notice that this section only adds to the variable classes as defined in [PCIMe] and reuses the mechanism defined there.
このセクションが[PCIMe]で定義されるように可変クラスに加えるだけであり、そこで定義されたメカニズムを再利用するのに注意してください。
The QoS policy information model specifies a set of pre-defined variable classes to support a set of fundamental QoS terms that are commonly used to form conditions and actions and are missing from the [PCIMe]. Examples of these include RSVP related variables. All variable classes defined in this document extend the QoSPolicyRSVPVariable class (defined in this document), which itself extends the PolicyImplictVariable class, defined in [PCIMe]. Subclasses specify the data type and semantics of the policy variables.
QoS方針情報モデルは、状態と動作を形成するのに一般的に使用された、[PCIMe]からなくなった用語の基本的なQoS一式をサポートするために1セットの事前に定義された可変クラスを指定します。 これらに関する例はRSVP関連変数を含んでいます。 本書では定義されたすべての可変クラスがQoSPolicyRSVPVariableのクラス(本書では定義される)を広げます。(それ自体は、[PCIMe]で定義されたPolicyImplictVariableのクラスを広げます)。 サブクラスは政策変数のデータ型と意味論を指定します。
This document defines the following RSVP variable classes; for details, see their class definitions:
このドキュメントは以下のRSVPの可変クラスを定義します。 詳細に関しては、彼らのクラス定義を見てください:
RSVP related Variables:
RSVPはVariablesを関係づけました:
1. QoSPolicyRSVPSourceIPv4Variable - The source IPv4 address of the
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE
and RSVP RESV FILTER_SPEC [RSVP] objects.
1. QoSPolicyRSVPSourceIPv4Variable--RSVPのソースIPv4アドレスは流れを示しました、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。
2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of
the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects (for IPv4 traffic).
2. QoSPolicyRSVPDestinationIPv4Variable--RSVPの仕向港は流れに合図しました、RSVP PATHとRESV SESSION[RSVP]オブジェクト(IPv4トラフィックのための)で定義されるように。
3. QoSPolicyRSVPSourceIPv6Variable - The source IPv6 address of the
RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE
and RSVP RESV FILTER_SPEC [RSVP] objects.
3. QoSPolicyRSVPSourceIPv6Variable--RSVPのソースIPv6アドレスは流れを示しました、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで無視されるように。
Snir, et al. Standards Track [Page 40] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[40ページ]。
4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of
the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects (for IPv6 traffic).
4. QoSPolicyRSVPDestinationIPv6Variable--RSVPの仕向港は流れに合図しました、RSVP PATHとRESV SESSION[RSVP]オブジェクト(IPv6トラフィックのための)で定義されるように。
5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects.
5. QoSPolicyRSVPSourcePortVariable--RSVPのソースポートは流れに合図しました、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。
6. QoSPolicyRSVPDestinationPortVariable - The destination port of
the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects.
6. QoSPolicyRSVPDestinationPortVariable--RSVPの仕向港は流れに合図しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。
7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP
signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
7. QoSPolicyRSVPIPProtocolVariable--RSVPのIPプロトコルは流れを示しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。
8. QoSPolicyRSVPIPVersionVariable - The version of the IP addresses
carrying the RSVP signaled flow, as defined in the RSVP PATH and
RESV SESSION [RSVP] objects.
8. QoSPolicyRSVPIPVersionVariable--RSVPを載せるIPアドレスのバージョンは流れを示しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。
9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the
RSVP DCLASS [DCLASS] object.
9. QoSPolicyRSVPDCLASSVariable--RSVP DCLASS[DCLASS]オブジェクトで定義されるDSCP値。
10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF)
as defined in the RSVP RESV message [RSVP].
10. QoSPolicyRSVPStyleVariable--RSVP RESVメッセージ[RSVP]で定義される予約スタイル(FF、SE、WF)。
11. QoSPolicyRSVPIntServVariable - The type of Integrated Service
(CL, GS, NULL) requested in the RSVP Reservation message, as
defined in the FLOWSPEC RSVP Object [RSVP].
11. QoSPolicyRSVPIntServVariable--FLOWSPEC RSVP Object[RSVP]で定義されるようにRSVP予約メッセージで要求されたIntegrated Service(CL、GS、NULL)のタイプ。
12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
PATH, PATHTEAR, RESV, RESVTEAR, RESVERR, CONF or PATHERR [RSVP].
12. QoSPolicyRSVPMessageTypeVariable--RSVPメッセージタイプ、PATH、PATHTEAR、RESV、RESVTEAR、RESVERR、CONFまたはPATHERR[RSVP]。
13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
priority as defined in [RFC3181].
13. QoSPolicyRSVPPreemptionPriorityVariable--[RFC3181]で定義されるRSVP予約優先権。
14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
reservation defending priority as defined in [RFC3181].
14. QoSPolicyRSVPPreemptionDefPriorityVariable--[RFC3181]で定義されるように優先権を防御するRSVP先取りの予約。
15. QoSPolicyRSVPUserVariable - The ID of the user that initiated
the flow as defined in the User Locator string in the Identity
Policy Object [RFC3182].
15. QoSPolicyRSVPUserVariable--Identity Policy Object[RFC3182]のUser Locatorストリングで定義されるように流れを起こしたユーザのID。
16. QoSPolicyRSVPApplicationVariable - The ID of the application
that generated the flow as defined in the application locator
string in the Application policy object [RFC2872].
16. QoSPolicyRSVPApplicationVariable--それがApplication政策目的[RFC2872]のアプリケーションロケータストリングで定義されるように流れを生成したアプリケーションのID。
Snir, et al. Standards Track [Page 41] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[41ページ]。
17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type
used in the Identity Policy Object [RFC3182].
17. QoSPolicyRSVPAuthMethodVariable--RSVP AuthenticationタイプはIdentity Policy Objectで[RFC3182]を使用しました。
Each class restricts the possible value types associated with a specific variable. For example, the QoSPolicyRSVPSourcePortVariable class is used to define the source port of the RSVP signaled flow. The value associated with this variable is of type PolicyIntegerValue.
各クラスは特定の変数に関連づけられた可能な値のタイプを制限します。 例えば、QoSPolicyRSVPSourcePortVariableのクラスは使用されて、RSVPのソースポートを定義するのが流れに合図したということです。 タイプPolicyIntegerValueにはこの変数に関連している値があります。
6. QoS Related Values
6. QoS関連する値
Values are used in the information model as building blocks for the policy conditions and policy actions, as described in [PCIM] and [PCIMe]. This section defines a set of auxiliary values that are used for QoS policies as well as other policy domains.
値は保険約款と政策的措置にブロックとして情報モデルで使用されます、[PCIM]と[PCIMe]で説明されるように。 このセクションは他の方針ドメインと同様にQoS方針に使用される1セットの補助の値を定義します。
All value classes extend the PolicyValue class [PCIMe]. The subclasses specify specific data/value types that are not defined in [PCIMe].
すべての値のクラスがPolicyValueのクラス[PCIMe]を広げます。 サブクラスは[PCIMe]で定義されない特定のデータ/値のタイプを指定します。
This document defines the following two subclasses of the PolicyValue class:
このドキュメントはPolicyValueのクラスの以下の2つのサブクラスを定義します:
QoSPolicyDNValue This class is used to represent a single or
set of Distinguished Name [DNDEF] values,
including wildcards. A Distinguished Name
is a name that can be used as a key to
retrieve an object from a directory
service. This value can be used in
comparison to reference values carried in
RSVP policy objects, as specified in
[RFC3182]. This class is defined in
Section 8.31.
QoSPolicyDNValue Thisのクラスは、ワイルドカードを含むDistinguished Name[DNDEF]値のシングルかセットを表すのに使用されます。 Distinguished Nameはディレクトリサービスからオブジェクトを検索するのにキーとして使用できる名前です。 比較に[RFC3182]で指定されるようにRSVP政策目的で運ばれた基準値にこの値を使用できます。 このクラスはセクション8.31で定義されます。
QoSPolicyAttributeValue A condition term uses the form "Variable
matches Value", and an action term uses the
form "set Variable to Value" ([PCIMe]).
This class is used to represent a single or
set of property values for the "Value" term
in either a condition or an action. This
value can be used in conjunction with
reference values carried in RSVP objects,
as specified in [RFC3182]. This class is
defined in section 8.12.
QoSPolicyAttributeValue A状態用語はフォーム「可変マッチValue」を使用します、そして、動作用語はフォーム「ValueへのセットVariable」([PCIMe])を使用します。 このクラスは、状態か動作のどちらかで「値」用語のための特性の値のシングルかセットを表すのに使用されます。 [RFC3182]で指定されるようにRSVPオブジェクトで運ばれた基準値に関連してこの値を使用できます。 このクラスはセクション8.12で定義されます。
The property name is used to specify which of the properties in the QoSPolicyAttributeValue class instance is being used in the condition or action term. The value of this property or properties will then
存在という特性についてQoSPolicyAttributeValueクラスインスタンスでどれを指定するかに使用される特性の名は状態か動作用語で使用されています。 この特性か属性の価値はそしてそうするでしょう。
Snir, et al. Standards Track [Page 42] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[42ページ]。
be retrieved. In the case of a condition, a match (which is dependent on the property name) will be used to see if the condition is satisfied or not. In the case of an action, the semantics are instead "set the variable to this value".
検索されてください。 状態が満たされているかどうかわかるのにおいて状態の場合マッチ(特性の名に依存している)は使用するでしょう。 動作の場合では、意味論は代わりに「これへの変数が評価するセット」です。
For example, suppose the "user" objects in the organization include several properties, among them:
例えば、組織における「ユーザ」オブジェクトがそれらの中の数個の特性を含んでいると仮定してください:
- First Name
- Last Name
- Login Name
- Department
- Title
- 名--姓--ログイン名--部--タイトル
A simple condition could be constructed to identify flows by their RSVP user carried policy object. The simple condition: Last Name = "Smith" to identify a user named Bill would be constructed in the following way:
単純条件は組み立てられて、彼らのRSVPユーザで流れを特定するのが政策目的を運んだということであるかもしれません。 単純条件: 最後に、ビルというユーザを特定するName=「スミス」は以下の方法で組み立てられるでしょう:
A SimplePolicyCondition [PCIMe] would aggregate a
QoSPolicyRSVPUserVariable [QPIM] object, via the
PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.
SimplePolicyCondition[PCIMe]はPolicyVariableInSimplePolicyCondition[PCIMe]集合でQoSPolicyRSVPUserVariable[QPIM]オブジェクトに集めるでしょう。
The implicit value associated with this condition is created in the following way:
この状態に関連している暗黙の値は以下の方法で作成されます:
A QoSPolicyAttributeValue object would be aggregated to the simple
condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
The QoSPolicyAttributeValue attribute qpAttributeName would be set
to "last name" and the qpAttributeValueList would be set to
"Smith".
QoSPolicyAttributeValueオブジェクトはPolicyValueInSimplePolicyCondition[PCIMe]を通して単純条件オブジェクトに集められるでしょう。 qpAttributeNameが「最後に命名する」ように用意ができているだろうQoSPolicyAttributeValue属性とqpAttributeValueListは「スミス」に用意ができているでしょう。
Another example is a condition that has to do with the user's organizational department. It can be constructed in the exact same way, by changing the QoSPolicyAttributeValue attribute qpAttributeName to "Department" and the qpAttributeValueList would be set to the particular value that is to be matched (e.g., "engineering" or "customer support"). The logical condition would than be evaluated to true if the user belong to either the engineering department or the customer support.
別の例はユーザの組織的な部と関係がある状態です。 全く同じ方法でそれを組み立てることができて、変化することによって、「部」へのQoSPolicyAttributeValue属性qpAttributeNameとqpAttributeValueListは取り組むことになっている特定の値(例えば、「工学」か「顧客サポート」)に用意ができているでしょう。 ロジック条件はユーザが工学部か顧客サポートのどちらかに属すなら本当に評価されるよりそうするでしょう。
Notice that many multiple-attribute objects require the use of the QoSPolicyAttributeValue class to specify exactly which of its attributes should be used in the condition match operation.
多くの複数の属性目的がちょうど属性のどれが状態マッチ操作に使用されるべきであるかを指定するためにQoSPolicyAttributeValueのクラスの使用を必要とするのに注意してください。
Snir, et al. Standards Track [Page 43] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[43ページ]。
7. Class Definitions: Association Hierarchy
7. クラス定義: 協会階層構造
The following sections define associations that are specified by QPIM.
以下のセクションはQPIMによって指定される協会を定義します。
7.1. The Association "QoSPolicyTrfcProfInAdmissionAction"
7.1. 協会"QoSPolicyTrfcProfInAdmissionAction"
This association links a QoSPolicyTrfcProf object (defined in section 8.9), modeling a specific traffic profile, to a QoSPolicyAdmissionAction object (defined in section 8.2). The class definition for this association is as follows:
この協会はQoSPolicyTrfcProfオブジェクト(セクション8.9で、定義される)をリンクします、特定のトラフィックプロフィールをモデル化して、QoSPolicyAdmissionActionオブジェクト(セクション8.2で、定義される)に。 この協会のためのクラス定義は以下の通りです:
NAME QoSPolicyTrfcProfInAdmissionAction
DESCRIPTION A class representing the association between a
QoS admission action and its traffic profile.
DERIVED FROM Dependency (See [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]]
Dependent[ref QoSPolicyTrfcProf [1..1]]
QoS入場動作とそのトラフィックプロフィールとの協会を代表するNAME QoSPolicyTrfcProfInAdmissionAction記述Aのクラス。 依存から派生している([PCIM]を見る)抽象的な誤った特性の前例[審判QoSPolicyAdmissionAction[0..n]]に依存しています。[審判QoSPolicyTrfcProf[1 .1]]
7.1.1. The Reference "Antecedent"
7.1.1. 「前例」という参照
This property is inherited from the Dependency association, defined in [PCIM]. Its type is overridden to become an object reference to a QoSPolicyAdmissionAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProf.
この特性は[PCIM]で定義されたDependency協会から引き継がれます。 タイプは、QoSPolicyAdmissionActionオブジェクトのオブジェクト参照になるようにくつがえされます。 これは協会の「独立している」部分を表します。 [0..n]基数は、いろいろなQoSPolicyAdmissionActionオブジェクトが与えられたQoSPolicyTrfcProfを使用するかもしれないのを示します。
7.1.2. The Reference "Dependent"
7.1.2. 「扶養家族」という参照
This property is inherited from the Dependency association, and is overridden to become an object reference to a QoSPolicyTrfcProf object. This represents a specific traffic profile that is used by any number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means that exactly one object of the QoSPolicyTrfcProf can be used by a given QoSPolicyAddmissionAction.
この特性は、Dependency協会から引き継がれて、QoSPolicyTrfcProfオブジェクトのオブジェクト参照になるように無視されます。 これはいろいろなQoSPolicyAdmissionActionオブジェクトによって使用される特定のトラフィックプロフィールを表します。 [1 .1]基数は、与えられたQoSPolicyAddmissionActionがちょうどQoSPolicyTrfcProfの1個のオブジェクトを使用できることを意味します。
7.2. The Association "PolicyConformAction"
7.2. 協会"PolicyConformAction"
This association links a policing action with an object defining an action to be applied to conforming traffic relative to the associated traffic profile. The class definition for this association is as follows:
この協会は関連トラフィックプロフィールに比例してトラフィックを従わせるのに適用されるために動作を定義するオブジェクトに取り締まり動作をリンクします。 この協会のためのクラス定義は以下の通りです:
Snir, et al. Standards Track [Page 44] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[44ページ]。
NAME PolicyConformAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic conforming to an associated
traffic profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]
関連トラフィックプロフィールに従うトラフィックに適用されるべきである取り締まり動作と動作との協会を代表するNAME PolicyConformAction記述Aのクラス。 依存から派生している([PCIM]を見る)抽象的な誤った特性の前例[審判QoSPolicyPoliceAction[0..n]]に依存しています。[審判PolicyAction[1 .1]]
7.2.1. The Reference "Antecedent"
7.2.1. 「前例」という参照
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the conforming action.
この特性はDependency協会から引き継がれます。 タイプは、QoSPolicyPoliceActionオブジェクトのオブジェクト参照になるようにくつがえされます。 これは協会の「独立している」部分を表します。 [0..n]基数は、同じ動作が従う動作として実行されるためにいろいろなQoSPolicyPoliceActionオブジェクトに与えられるかもしれないのを示します。
7.2.2. The Reference "Dependent"
7.2.2. 「扶養家族」という参照
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one policy action can be used as the "conform" action for a QoSPolicyPoliceAction. To execute more than one conforming action, use the PolicyCompoundAction class to model the conforming action.
この特性は、Dependency協会から引き継がれて、PolicyActionオブジェクトのオブジェクト参照になるように無視されます。 これは与えられたQoSPolicyPoliceActionによって使用される特定保険証券動作を表します。 [1 .1]基数は、QoSPolicyPoliceActionに「従ってください」という動作としてまさに1つの政策的措置を使用できることを意味します。 1つ以上の従う動作を実行するには、従う動作をモデル化するPolicyCompoundActionのクラスを使用してください。
7.3. The Association "QoSPolicyExceedAction"
7.3. 協会"QoSPolicyExceedAction"
This association links a policing action with an object defining an action to be applied to traffic exceeding the associated traffic profile. The class definition for this association is as follows:
この協会は関連トラフィックプロフィールを超えているトラフィックに適用されるために動作を定義するオブジェクトに取り締まり動作をリンクします。 この協会のためのクラス定義は以下の通りです:
NAME QoSPolicyExceedAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic exceeding an associated traffic
profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]
関連トラフィックプロフィールを超えているトラフィックに適用されるべきである取り締まり動作と動作との協会を代表するNAME QoSPolicyExceedAction記述Aのクラス。 依存から派生している([PCIM]を見る)抽象的な誤った特性の前例[審判QoSPolicePoliceAction[0..n]]に依存しています。[審判PolicyAction[1 .1]]
Snir, et al. Standards Track [Page 45] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[45ページ]。
7.3.1. The Reference "Antecedent"
7.3.1. 「前例」という参照
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the exceeding action.
この特性はDependency協会から引き継がれます。 タイプは、QoSPolicyPoliceActionオブジェクトのオブジェクト参照になるようにくつがえされます。 これは協会の「独立している」部分を表します。 [0..n]基数は、同じ動作が上回っている動作として実行されるためにいろいろなQoSPolicyPoliceActionオブジェクトに与えられるかもしれないのを示します。
7.3.2. The Reference "Dependent"
7.3.2. 「扶養家族」という参照
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that a exactly one policy action can be used as the "exceed" action by a QoSPolicyPoliceAction. To execute more than one conforming action, use the PolicyCompoundAction class to model the exceeding action.
この特性は、Dependency協会から引き継がれて、PolicyActionオブジェクトのオブジェクト参照になるように無視されます。 これは与えられたQoSPolicyPoliceActionによって使用される特定保険証券動作を表します。 [1 .1]基数は、QoSPolicyPoliceActionが「超過」動作としてまさに1つの方針の動作を使用できることを意味します。 1つ以上の従う動作を実行するには、上回っている動作をモデル化するPolicyCompoundActionのクラスを使用してください。
7.4. The Association "PolicyViolateAction"
7.4. 協会"PolicyViolateAction"
This association links a policing action with an object defining an action to be applied to traffic violating the associated traffic profile. The class definition for this association is as follows:
この協会は関連トラフィックプロフィールに違反するトラフィックに適用されるために動作を定義するオブジェクトに取り締まり動作をリンクします。 この協会のためのクラス定義は以下の通りです:
NAME PolicyViolateAction
DESCRIPTION A class representing the association between
a policing action and the action that should be
applied to traffic violating an associated traffic
profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]
関連トラフィックプロフィールに違反するトラフィックに適用されるべきである取り締まり動作と動作との協会を代表するNAME PolicyViolateAction記述Aのクラス。 依存から派生している([PCIM]を見る)抽象的な誤った特性の前例[審判QoSPolicePoliceAction[0..n]]に依存しています。[審判PolicyAction[1 .1]]
7.4.1. The Reference "Antecedent"
7.4.1. 「前例」という参照
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the violating action.
この特性はDependency協会から引き継がれます。 タイプは、QoSPolicyPoliceActionオブジェクトのオブジェクト参照になるようにくつがえされます。 これは協会の「独立している」部分を表します。 [0..n]基数は、同じ動作が違反動作として実行されるためにいろいろなQoSPolicyPoliceActionオブジェクトに与えられるかもしれないのを示します。
Snir, et al. Standards Track [Page 46] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[46ページ]。
7.4.2. The Reference "Dependent"
7.4.2. 「扶養家族」という参照
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one policy action can be used as the "violate" action by a QoSPolicyPoliceAction. To execute more than one violating action, use the PolicyCompoundAction class to model the conforming action.
この特性は、Dependency協会から引き継がれて、PolicyActionオブジェクトのオブジェクト参照になるように無視されます。 これは与えられたQoSPolicyPoliceActionによって使用される特定保険証券動作を表します。 [1 .1]基数は、QoSPolicyPoliceActionが「違反」動作としてまさに1つの政策的措置を使用できることを意味します。 動作に違反する1つ以上を実行するには、従う動作をモデル化するPolicyCompoundActionのクラスを使用してください。
7.5. The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction"
7.5. 集合"QoSPolicyRSVPVariableInRSVPSimplePolicyAction"
A simple RSVP policy action is represented as a pair {variable,
value}. This aggregation provides the linkage between a
QoSPolicyRSVPSimpleAction instance and a single
QoSPolicyRSVPVariable. The aggregation
PolicyValueInSimplePolicyAction links the QoSPolicyRSVPSimpleAction
to a single PolicyValue.
aが変数、値を対にするとき、簡単なRSVP政策的措置は表されます。 この集合はQoSPolicyRSVPSimpleActionインスタンスと独身のQoSPolicyRSVPVariableの間のリンケージを供給します。 集合PolicyValueInSimplePolicyActionは独身のPolicyValueにQoSPolicyRSVPSimpleActionをリンクします。
The class definition for this aggregation is as follows:
この集合のためのクラス定義は以下の通りです:
NAME QoSPolicyRSVPVariableInRSVPSimplePolicyAction
DERIVED FROM PolicyVariableInSimplePolicyAction
ABSTRACT FALSE
PROPERTIES GroupComponent[ref QoSPolicyRSVPSimpleAction
[0..n]]
PartComponent[ref QoSPolicyRSVPVariable [1..1] ]
PolicyVariableInSimplePolicyActionの抽象的な偽の特性のGroupComponent[審判QoSPolicyRSVPSimpleAction[0..n]]PartComponentから得られた名前QoSPolicyRSVPVariableInRSVPSimplePolicyAction[審判QoSPolicyRSVPVariable[1 .1]]
7.5.1. The Reference "GroupComponent"
7.5.1. 参照"GroupComponent"
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a QoSPolicyRSVPSimpleAction that contains exactly one QoSPolicyRSVPVariable. Note that for any single instance of the aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that contain any given RSVP variable object.
参照の特性の"GroupComponent"は、PolicyComponentから引き継がれて、ちょうど1QoSPolicyRSVPVariableを含むQoSPolicyRSVPSimpleActionのオブジェクト参照になるようにくつがえされます。 集合のクラスQoSPolicyRSVPVariableInRSVPSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性が単一に評価されていることに注意してください。 [0..n]基数は0、1以上がどんな与えられたRSVP可変オブジェクトも含むQoSPolicyRSVPSimpleActionオブジェクトであったかもしれないならそこでそれを示します。
7.5.2. The Reference "PartComponent"
7.5.2. 参照"PartComponent"
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a QoSPolicyRSVPVariable that is defined within the scope of a QoSPolicyRSVPSimpleAction. Note that for any single instance of the association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property (like all reference properties) is single-valued. The
参照の特性の"PartComponent"は、PolicyComponentから引き継がれて、QoSPolicyRSVPSimpleActionの範囲の中で定義されるQoSPolicyRSVPVariableのオブジェクト参照になるようにくつがえされます。 協会のクラスQoSPolicyRSVPVariableInRSVPSimplePolicyActionのどんなただ一つのインスタンスにおいても、この特性(すべての参照の特性のような)が単一に評価されていることに注意してください。 The
Snir, et al. Standards Track [Page 47] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[47ページ]。
[1..1] cardinality indicates that a QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP variable defined within its scope in order to be meaningful.
[1 .1] 基数は、QoSPolicyRSVPVariableInRSVPSimplePolicyActionにはまさに重要になるように範囲の中で定義された1つのRSVP変数がなければならないのを示します。
8. Class Definitions: Inheritance Hierarchy
8. クラス定義: 継承階層構造
The following sections define object classes that are specified by QPIM.
以下のセクションはQPIMによって指定されるオブジェクトのクラスを定義します。
8.1. The Class QoSPolicyDiscardAction
8.1. クラスQoSPolicyDiscardAction
This class is used to specify that packets should be discarded. This is the same as stating that packets should be denied forwarding. The class definition is as follows:
このクラスは、パケットが捨てられるべきであると指定するのに使用されます。 これは推進がパケットに対して否定されるべきであると述べるのと同じです。 クラス定義は以下の通りです:
NAME QoSPolicyDiscardAction
DESCRIPTION This action specifies that packets should be
discarded.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT FALSEFALSE
PROPERTIES None
NAME QoSPolicyDiscardAction記述This動作は、パケットが捨てられるべきであると指定します。 PolicyAction([PCIM]では、定義される)の抽象的なFALSEFALSEの特性から、なにもに派生します。
8.2. The Class QoSPolicyAdmissionAction
8.2. クラスQoSPolicyAdmissionAction
This class is the base class for performing admission decisions based on a comparison of a meter measuring the temporal behavior of a flow or a set of flow with a traffic profile. The qpAdmissionScope property controls whether the comparison is done per flow or per class (of flows). Only packets that conform to the traffic profile are admitted for further processing; other packets are discarded. The class definition is as follows:
このクラスは、1メーターの比較に基づいてトラフィックプロフィールで流れの時の振舞いか1セットの流れを測定しながら合否判定を実行するための基底クラスです。 qpAdmissionScopeの特性は、流れかクラス(流れの)単位で比較するかどうかを制御します。 トラフィックプロフィールに従うパケットだけがさらなる処理のために認められます。 他のパケットは捨てられます。 クラス定義は以下の通りです:
NAME QoSPolicyAdmissionAction
DESCRIPTION This action controls admission decisions based on
comparison of a meter to a traffic profile.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT FALSEFALSE
PROPERTIES qpAdmissionScope
NAME QoSPolicyAdmissionAction記述This動作は1メーターの比較に基づく合否判定をトラフィックプロフィールに制御します。 PolicyAction([PCIM]では、定義される)の抽象的なFALSEFALSE特性のqpAdmissionScopeから、派生します。
8.2.1. The Property qpAdmissionScope
8.2.1. 特性のqpAdmissionScope
This attribute specifies whether the admission decision is done per flow or per the entire class of flows defined by the rule condition. If the scope is "flow", the actual or requested rate of each flow is compared against the traffic profile. If the scope is set to "class", the aggregate actual or requested rate of all flows matching the rule condition is measured against the traffic profile. The property is defined as follows:
この属性は、流れか規則状態によって定義された全体のクラスの流れ単位で合否判定をするかどうか指定します。 範囲が「流れ」であるなら、それぞれの流れの実際の、または、要求された速度はトラフィックプロフィールに対して比較されます。 範囲が「クラス」に設定されるなら、規則状態に合っているすべての流れの集合実際の、または、要求された速度はトラフィックプロフィールに対して測定されます。 特性は以下の通り定義されます:
Snir, et al. Standards Track [Page 48] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[48ページ]。
NAME qpAdmissionScope
DESCRIPTION This property specifies whether the admission decision
is done per flow or per the entire class of flows.
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies
that admission is done on a per-flow basis, and a value
of 1 specifies that admission is done on a per-class
basis.
NAME qpAdmissionScope記述Thisの特性は、流れか全体のクラスの流れ単位で合否判定をするかどうか指定します。 SYNTAX Integer VALUE Thisは列挙された整数です。 0の値は、1流れあたり1個のベースで承認すると指定します、そして、1の値は1クラスあたり1個のベースで承認すると指定します。
8.3. The Class QoSPolicyPoliceAction
8.3. クラスQoSPolicyPoliceAction
This is used for defining policing actions (i.e., those actions that restrict traffic based on a comparison with a traffic profile). Using the three associations QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction, it is possible to specify different actions to take based on whether the traffic is conforming, exceeding, or violating a traffic profile. The traffic profile is specified in a subclass of the QoSPolicyTrfcProf class. The class definition is as follows:
これは、定義に動作(すなわち、トラフィックプロフィールとの比較に基づくトラフィックを制限するそれらの動作)を取り締まりながら、使用されます。 QoSPolicyConformAction、QoSPolicyExceedAction、およびQoSPolicyViolateAction、3つの協会を使用して、トラフィックが従っているかどうかに基づいて取るために異なった動作を指定するのは可能です、トラフィックプロフィールに超えているか、または違反して。 トラフィックプロフィールはQoSPolicyTrfcProfのクラスのサブクラスで指定されます。 クラス定義は以下の通りです:
NAME QoSPolicyPoliceAction
DESCRIPTION This action controls the operation of policers. The
rate of flows is measured against a traffic profile.
The actions that need to be performed on conforming,
exceeding and violating traffic are indicated using
the conform, exceed and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES None
NAME QoSPolicyPoliceAction記述This動作はpolicersの操作を制御します。 流れの速度はトラフィックプロフィールに対して測定されます。 トラフィックを従って、超えて、違反するのに実行される必要がある動作が示された使用である、動作協会を従って、超えて、違反してください。 DERIVED FROM QoSPolicyAdmissionAction(本書では定義される)の抽象的なFALSEFALSE PROPERTIES None
8.4. The Class QoSPolicyShapeAction
8.4. クラスQoSPolicyShapeAction
This class is used for defining shaping actions. Shapers are used to delay some or all of the packets in a traffic stream in order to bring a particular traffic stream into compliance with a given traffic profile. The traffic profile is specified in a subclass of the QoSPolicyTrfcProf class. The class definition is as follows:
このクラスは、定義に動作を形成しながら、使用されます。 整形器は、与えられたトラフィックプロフィールへの承諾に特定のトラフィックストリームを運び込むようにトラフィックストリームでパケットのいくつかかすべてを遅らせるのに使用されます。 トラフィックプロフィールはQoSPolicyTrfcProfのクラスのサブクラスで指定されます。 クラス定義は以下の通りです:
NAME QoSPolicyShapeAction
DESCRIPTION This action indicate that traffic should be shaped to be
conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES None
NAME QoSPolicyShapeAction記述This動作は、トラフィックがトラフィックプロフィールに従っているために形成されるべきであるのを示します。 DERIVED FROM QoSPolicyAdmissionAction(本書では定義される)の抽象的なFALSEFALSE PROPERTIES None
Snir, et al. Standards Track [Page 49] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[49ページ]。
8.5. The Class QoSPolicyRSVPAdmissionAction
8.5. クラスQoSPolicyRSVPAdmissionAction
This class determines whether to accept or reject a given RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters against the associated traffic profile and/or by enforcing the pre- set maximum sessions limit. The traffic profile is specified in the QoSPolicyIntServTrfcProf class. This class inherits the qpAdmissionScope property from its superclass. This property specifies whether admission should be done on a per-flow or per-class basis. If the traffic profile is not larger than or equal to the requested reservation, or to the sum of the admitted reservation merged with the requested reservation, the result is a deny decision. If no traffic profile is specified, the assumption is that all traffic can be admitted.
このクラスは、関連トラフィックプロフィールに対してRSVP要求のTSPECかRSPECパラメタを比較するプレセットの最大のセッション限界を実施することによって、与えられたRSVP要求を受け入れるか、または拒絶するかを決定します。 トラフィックプロフィールはQoSPolicyIntServTrfcProfのクラスで指定されます。 このクラスは「スーパー-クラス」からqpAdmissionScopeの特性を引き継ぎます。 この特性は、流れかクラスあたり1個のベースで承認するべきであるかどうか指定します。 トラフィックプロフィールが要求された予約以上でない、要求された予約に合併されていて、結果がaである認められた条件の合計に、決定を否定してください。 トラフィックプロフィールが全く指定されないなら、仮定はすべてのトラフィックを認めることができるということです。
The class definition is as follows:
クラス定義は以下の通りです:
NAME QoSPolicyRSVPAdmissionAction
DESCRIPTION This action controls the admission of RSVP requests.
Depending on the scope, either a single RSVP request or
the total admitted RSVP requests matching the conditions
are compared against a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT FALSEFALSE
PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions
NAME QoSPolicyRSVPAdmissionAction記述This動作はRSVP要求の入場を制御します。 範囲によって、ただ一つのRSVP要求か合計のどちらかが、状態に合っているRSVP要求がトラフィックプロフィールに対して比較されることを認めました。 DERIVED FROM QoSPolicyAdmissionAction(本書では定義される)の抽象的なFALSEFALSE PROPERTIES qpRSVPWarnOnly、qpRSVPMaxSessions
8.5.1. The Property qpRSVPWarnOnly
8.5.1. 特性のqpRSVPWarnOnly
This property is applicable when fulfilling ("admitting") an RSVP
request would violate the policer (traffic profile) limits or when
the maximum number session would be exceeded (or both).
RSVP要求を実現させると(「認める」)policer(トラフィックプロフィール)限界が違反されるだろうか、または最大数セッションが超えられているだろうというとき(ともに)、この特性は適切です。
When this property is set to TRUE, the RSVP request is admitted in spite of the violation, but an RSVP error message carrying a warning is sent to the originator (sender or receiver). When set to FALSE, the request would be denied and an error message would be sent back to the originator. So the meaning of the qpWarnOnly flag is: Based on property's value (TRUE or FALSE), determine whether to admit but warn the originator that the request is in violation or to deny the request altogether (and send back an error).
違反にもかかわらず、この特性をTRUEに設定するとき、RSVP要求を認めますが、創始者(送付者か受信機)に警告を運ぶRSVPエラーメッセージを送ります。 FALSEに設定されると、要求は否定されるでしょう、そして、エラーメッセージは創始者に送り返されるでしょう。 それで、qpWarnOnly旗の意味は以下の通りです。 特性の値(TRUEかFALSE)に基づいて、要求が違反していると創始者に認めますが、警告するか、または全体で要求を否定するか決定してください(誤りを返送してください)。
Specifically, a PATHERR (in response to a Path message) or a RESVERR (in response of a RESV message) will be sent. This follows the COPS for RSVP send error flag in the Decision Flags object. This property is defined as follows:
明確に、PATHERR(Pathメッセージに対応した)かRESVERR(RESVメッセージの応答における)を送るでしょう。 これはDecision FlagsオブジェクトのRSVP送信エラー旗のためのCOPSに続きます。 この特性は以下の通り定義されます:
Snir, et al. Standards Track [Page 50] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[50ページ]。
NAME qpRSVPWarnOnly
SYNTAX Boolean
Default FALSE
VALUE The value TRUE means that the request should be admitted
AND an RSVP warning message should be sent to the
originator. The value of FALSE means that the request
should be not admitted and an appropriate error message
should be sent back to the originator of the request.
NAME qpRSVPWarnOnly SYNTAXのブールDefault FALSE VALUE値のTRUEは、要求が認められるべきであり、RSVP警告メッセージが創始者に送られるべきであることを意味します。 FALSEの値は、要求を認めるべきでなくて、適切なエラーメッセージを要求の創始者に送り返すべきであることを意味します。
8.5.2. The Property qpRSVPMaxSessions
8.5.2. 特性のqpRSVPMaxSessions
This attribute is used to limit the total number of RSVP requests admitted for the specified class of traffic. For this property to be meaningful, the qpAdmissionScope property must be set to class. The definition of this property is as follows:
この属性は、指定されたクラスのトラフィックのために認められたRSVP要求の総数を制限するのに使用されます。 この特性が重要であるように、qpAdmissionScopeの特性をクラスに設定しなければなりません。 この特性の定義は以下の通りです:
NAME qpRSVPMaxSessions SYNTAX Integer VALUE Must be greater than 0.
NAME qpRSVPMaxSessions SYNTAX Integer VALUE Must、0以上になってください。
8.6. The Class QoSPolicyPHBAction
8.6. クラスQoSPolicyPHBAction
This class is a base class that is used to define the per-hop behavior that is to be assigned to behavior aggregates. It defines a common property, qpMaxPacketSize, for use by its subclasses (QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The class definition is as follows:
このクラスは振舞い集合に割り当てられることになっている1ホップあたりの振舞いを定義するのに使用される基底クラスです。 サブクラス(QoSPolicyBandwidthActionとQoSPolicyCongestionControlAction)でそれは使用のために通有性、qpMaxPacketSizeを定義します。 クラス定義は以下の通りです:
NAME QoSPolicyPHBAction
DESCRIPTION This action controls the Per-Hop-Behavior provided to
behavior aggregates.
DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT TRUE
PROPERTIES qpMaxPacketSize
NAME QoSPolicyPHBAction記述This動作は振舞い集合に提供されたPerホップの振舞いを制御します。 PolicyAction([PCIM]では、定義される)の抽象的な本当の特性のqpMaxPacketSizeから、派生します。
8.6.1. The Property qpMaxPacketSize
8.6.1. 特性のqpMaxPacketSize
This property specifies the maximum packet size in bytes, of packets in the designated flow. This attribute is used in translation of QPIM attributes to QoS mechanisms used within a PEP. For example, queue length may be measured in bytes, while the minimum number of packets that should be kept in a PEP is defined within QPIM in number of packets. This property is defined as follows:
この特性は指定された流れでパケットのバイトで表現される最大のパケットサイズを指定します。 この属性はPEPの中で使用されたQoSメカニズムへのQPIM属性に関する翻訳で使用されます。 例えば、待ち行列の長さはバイトで測定されるかもしれません、PEPに保たれるべきであるパケットの最小の数がQPIMの中でパケットの数で定義されますが。 この特性は以下の通り定義されます:
NAME qpMaxPacketSize SYNTAX Integer Value Must be greater than 0
NAME qpMaxPacketSize SYNTAX Integer Value Must、0以上になってください。
Snir, et al. Standards Track [Page 51] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[51ページ]。
8.7. The Class QoSPolicyBandwidthAction
8.7. クラスQoSPolicyBandwidthAction
This class is used to control the bandwidth, delay, and forwarding behavior of a PHB. Its class definition is as follows:
このクラスは、PHBの帯域幅、遅れ、および推進動きを制御するのに使用されます。 クラス定義は以下の通りです:
NAME QoSPolicyBandwidthAction
DESCRIPTION This action controls the bandwidth, delay, and
forwarding characteristics of the PHB.
DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT FALSE
PROPERTIES qpForwardingPriority, qpBandwidthUnits,
qpMinBandwdith, qpMaxBandwidth, qpMaxDelay,
qpMaxJitter, qpFairness
NAME QoSPolicyBandwidthAction記述This動作はPHBの帯域幅、遅れ、および推進の特性を制御します。 DERIVED FROM QoSPolicyPBHAction(本書では定義される)の抽象的なFALSE PROPERTIES qpForwardingPriority、qpBandwidthUnits、qpMinBandwdith、qpMaxBandwidth、qpMaxDelay、qpMaxJitter、qpFairness
8.7.1. The Property qpForwardingPriority
8.7.1. 特性のqpForwardingPriority
This property defines the forwarding priority for this set of flows. A non-zero value indicates that preemptive forwarding is required. Higher values represent higher forwarding priority. This property is defined as follows:
この特性はこのセットの流れのために推進優先権を定義します。 非ゼロ値は、先買いの推進が必要であることを示します。 より高い値は、より高い推進優先度を表します。 この特性は以下の通り定義されます:
NAME qpForwardingPriority
SYNTAX Integer
VALUE Must be non-negative. The value 0 means that preemptive
forwarding is not required. A positive value indicates
the priority that is to be assigned for this (set of)
flow(s). Larger values represent higher priorities.
NAME qpForwardingPriority SYNTAX Integer VALUE Must、非否定的であってください。 値0は、先買いの推進が必要でないことを意味します。 正の数はこの(セットされます)流動のために割り当てられることになっている優先権を示します。 より大きい値は、より高いプライオリティを表します。
8.7.2. The Property qpBandwidthUnits
8.7.2. 特性のqpBandwidthUnits
This property defines the units that the properties qpMinBandwidth and qpMaxBandwidth have. Bandwidth can either be defined in bits/sec or as a percentage of the available bandwidth or scheduler resources. This property is defined as follows:
この特性は特性のqpMinBandwidthとqpMaxBandwidthが持っているユニットを定義します。 ビット/秒か利用可能な帯域幅かスケジューラリソースの割合と帯域幅を定義できます。 この特性は以下の通り定義されます:
NAME qpBandwidthUnits
SYNTAX Integer
VALUE Two values are possible. The value of 0 is used to
specify units of bits/sec, while the value of 1 is used
to specify units as a percentage of the available
bandwidth. If this property indicates that the bandwidth
units are percentages, then each of the bandwidth
properties expresses a whole-number percentage, and hence
its maximum value is 100.
NAME qpBandwidthUnits SYNTAX Integer VALUE Two値は可能です。 0の値はユニットのビット/秒を指定するのに使用されます、1の値が利用可能な帯域幅の割合として装置を指定するのに使用されますが。 この特性が、帯域幅ユニットが割合であることを示すなら、それぞれの帯域幅の特性は整数割合を表します、そして、したがって、最大値は100です。
Snir, et al. Standards Track [Page 52] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[52ページ]。
8.7.3. The Property qpMinBandwidth
8.7.3. 特性のqpMinBandwidth
This property defines the minimum bandwidth that should be reserved for this class of traffic. Both relative (i.e., a percentage of the bandwidth) and absolute (i.e., bits/second) values can be specified according to the value of the qpBandwidthUnits property. This property is defined as follows:
この特性はこのクラスのトラフィックのために控えられるべきである最小の帯域幅を定義します。 qpBandwidthUnits属性の価値に従って、相対的な(すなわち、帯域幅の割合)ものと同様に絶対(すなわち、ビット/秒)の値を指定できます。 この特性は以下の通り定義されます:
NAME qpMinBandwidth
SYNTAX Integer
VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of
qpMinBandwidth must be less than or equal to the value of
qpMaxBandwidth.
NAME qpMinBandwidth SYNTAX Integer VALUE、値は0以上でなければなりません。 特性のqpMaxBandwidthが定義されるなら、qpMinBandwidthの値はqpMaxBandwidthの、より値以下でなければなりません。
8.7.4. The Property qpMaxBandwidth
8.7.4. 特性のqpMaxBandwidth
This property defines the maximum bandwidth that should be allocated to this class of traffic. Both relative (i.e., a percentage of the bandwidth)and absolute (i.e., bits/second) values can be specified according to the value of the qpBandwidthUnits property. This property is defined as follows:
この特性はこのクラスのトラフィックに割り当てられるべきである最大の帯域幅を定義します。 qpBandwidthUnits属性の価値に従って、相対的な(すなわち、帯域幅の割合)ものと同様に絶対(すなわち、ビット/秒)の値を指定できます。 この特性は以下の通り定義されます:
NAME qpMaxBandwidth
SYNTAX Integer
VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of
qpMinBandwidth must be less than or equal to the value of
qpMaxBandwidth.
NAME qpMaxBandwidth SYNTAX Integer VALUE、値は0以上でなければなりません。 特性のqpMaxBandwidthが定義されるなら、qpMinBandwidthの値はqpMaxBandwidthの、より値以下でなければなりません。
8.7.5. The Property qpMaxDelay
8.7.5. 特性のqpMaxDelay
This property defines the maximal per-hop delay that traffic of this class should experience while being forwarded through this hop. The maximum delay is measured in microseconds. This property is defined as follows:
この特性はこのクラスのトラフィックがこのホップを通して進めている間になるべきである1ホップあたりの最大限度の遅れを定義します。 最大の遅れはマイクロセカンドのときに測定されます。 この特性は以下の通り定義されます:
NAME qpMaxDelay SYNTAX Integer (microseconds) VALUE The value must be greater than 0.
NAME qpMaxDelay SYNTAX Integer(マイクロセカンド)VALUE、値は0以上でなければなりません。
8.7.6. The Property qpMaxJitter
8.7.6. 特性のqpMaxJitter
This property defines the maximal per-hop delay variance that traffic of this class should experience while being forwarded through this hop. The maximum jitter is measured in microseconds. This property is defined as follows:
この特性はこのクラスのトラフィックがこのホップを通して進めている間になるべきである1ホップあたりの最大限度の遅れ変化を定義します。 最大のジターはマイクロセカンドのときに測定されます。 この特性は以下の通り定義されます:
Snir, et al. Standards Track [Page 53] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[53ページ]。
NAME qpMaxJitter SYNTAX Integer (microseconds) VALUE The value must be greater than 0.
NAME qpMaxJitter SYNTAX Integer(マイクロセカンド)VALUE、値は0以上でなければなりません。
8.7.7. The Property qpFairness
8.7.7. 特性のqpFairness
This property defines whether fair queuing is required for this class of traffic. This property is defined as follows:
この特性は、公正な列を作りがこのクラスのトラフィックに必要であるかどうかを定義します。 この特性は以下の通り定義されます:
NAME qpFairness
SYNTAX Boolean
VALUE The value of FALSE means that fair queuing is not
required for this class of traffic, while the value of
TRUE means that fair queuing is required for this class
of traffic.
NAME qpFairness SYNTAXのブールVALUE、FALSEの値は、公正な列を作りがこのクラスのトラフィックに必要でないことを意味します、TRUEの値が、公正な列を作りがこのクラスのトラフィックに必要であることを意味しますが。
8.8. The Class QoSPolicyCongestionControlAction
8.8. クラスQoSPolicyCongestionControlAction
This class is used to control the characteristics of the congestion control algorithm being used. The class definition is as follows:
このクラスは、使用される輻輳制御アルゴリズムの特性を制御するのに使用されます。 クラス定義は以下の通りです:
NAME QoSPolicyCongestionControlAction
DESCRIPTION This action control congestion control characteristics
of the PHB.
DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT FALSE
PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropMethod,
qpDropThresholdUnits, qpDropMinThresholdValue,
qpDropMaxThresholdValue
PHBのNAME QoSPolicyCongestionControlAction記述This動作コントロール輻輳制御の特性。 DERIVED FROM QoSPolicyPBHAction(本書では定義される)の抽象的なFALSE PROPERTIES qpQueueSizeUnits、qpQueueSize、qpDropMethod、qpDropThresholdUnits、qpDropMinThresholdValue、qpDropMaxThresholdValue
8.8.1. The property qpQueueSizeUnits
8.8.1. 特性のqpQueueSizeUnits
This property specifies the units in which the qpQueueSize attribute is measured. The queue size is measured either in number of packets or in units of time. The time interval specifies the time needed to transmit all packets within the queue if the link speed is dedicated entirely to transmission of packets within this queue. The property definition is:
この特性はqpQueueSize属性が測定されるユニットを指定します。 待ち行列サイズはパケットの数かユニットの回の間、測定されます。 リンク速度がこの待ち行列の中で完全にパケットのトランスミッションに捧げられるなら待ち行列の中ですべてのパケットを伝えるのが必要であることで、時間間隔は時間を指定します。 特性の定義は以下の通りです。
NAME qpQueueSizeUnits
SYNTAX Integer
VALUE This property can have two values. If the value is set
to 0, then the unit of measurement is number of packets.
If the value is set to 1, then the unit of measurement is
milliseconds.
NAME qpQueueSizeUnits SYNTAX Integer VALUE Thisの特性は2つの値を持つことができます。 値が0に設定されるなら、測定の単位はパケットの数です。 値が1に設定されるなら、測定の単位はミリセカンドです。
Snir, et al. Standards Track [Page 54] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[54ページ]。
8.8.2. The Property qpQueueSize
8.8.2. 特性のqpQueueSize
This property specifies the maximum queue size in packets or in milliseconds, depending on the value of the qpQueueSizeUnits (0 specifies packets, and 1 specifies milliseconds). This property is defined as follows:
この特性はパケットかミリセカンドで最大の待ち行列サイズを指定します、qpQueueSizeUnitsの値によって(0がパケットを指定します、そして、1はミリセカンドを指定します)。 この特性は以下の通り定義されます:
NAME qpQueueSize SYNTAX Integer VALUE This value must be greater than 0.
NAME qpQueueSize SYNTAX Integer VALUE This値は0以上でなければなりません。
8.8.3. The Property qpDropMethod
8.8.3. 特性のqpDropMethod
This property specifies the congestion control drop algorithm that should be used for this type of traffic. This property is defined as follows:
この特性はこのタイプのトラフィックに使用されるべきである輻輳制御低下アルゴリズムを指定します。 この特性は以下の通り定義されます:
NAME qpDropMethod
SYNTAX Integer
VALUES Three values are currently defined. The value 0
specifies a random drop algorithm, the value 1 specifies
a tail drop algorithm, and the value 2 specifies a head
drop algorithm.
NAME qpDropMethod SYNTAX Integer VALUES Three値は現在、定義されます。 値0は無作為の低下アルゴリズムを指定します、そして、値1はテール低下アルゴリズムを指定します、そして、値2は落差アルゴリズムを指定します。
8.8.4. The Property qpDropThresholdUnits
8.8.4. 特性のqpDropThresholdUnits
This property specifies the units in which the two properties qpDropMinThresholdValue and qpDropMaxThresholdValue are measured. Thresholds can be measured either in packets or as a percentage of the available queue sizes. This property is defined as follows:
この特性は2の特性のqpDropMinThresholdValueとqpDropMaxThresholdValueが測定されるユニットを指定します。 パケットか有効な待ち行列サイズの割合として敷居を測定できます。 この特性は以下の通り定義されます:
NAME qpDropThresholdUnits
SYNTAX Integer
VALUES Three values are defined. The value 0 defines the units
as number of packets, the value 1 defines the units as a
percentage of the queue size and the value 2 defines the
units in milliseconds. If this property indicates that
the threshold units are percentages, then each of the
threshold properties expresses a whole-number percentage,
and hence its maximum value is 100.
NAME qpDropThresholdUnits SYNTAX Integer VALUES Three値は定義されます。 値0はパケットの数とユニットを定義します、そして、値1は待ち行列サイズの割合とユニットを定義します、そして、値2はミリセカンドでユニットを定義します。 この特性が、敷居単位が割合であることを示すなら、それぞれの敷居の特性は整数割合を表します、そして、したがって、最大値は100です。
8.8.5. The Property qpDropMinThresholdValue
8.8.5. 特性のqpDropMinThresholdValue
This property specifies the minimum number of queuing and buffer resources that should be reserved for this class of flows. The threshold can be specified as either relative (i.e., a percentage) or absolute (i.e., number of packets or millisecond) value according to the value of the qpDropThresholdUnits property. If this property
この特性はこのクラスの流れのために予約されるべきである列を作りとバッファ資源の最小の数を指定します。 qpDropThresholdUnits属性の価値に従って、敷居は相対的(すなわち、割合)か絶対として指定された(すなわち、パケットかミリセカンドの数)値であるかもしれません。 この特性です。
Snir, et al. Standards Track [Page 55] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[55ページ]。
specifies a value of 5 packets, then enough buffer and queuing resources should be reserved to hold 5 packets before running the specified congestion control drop algorithm. This property is defined as follows:
5のパケットの、そして、次に、十分なバッファの値を指定して、リソースを列に並ばせるのは、指定された輻輳制御低下アルゴリズムを実行する前に5つのパケットを開催するために予約されるべきです。 この特性は以下の通り定義されます:
NAME qpDropMinThresholdValue
SYNTAX Integer
VALUE This value must be greater than or equal to 0. If the
property qpDropMaxThresholdValue is defined, then the
value of the qpDropMinThresholdValue property must be
less than or equal to the value of the
qpDropMaxThresholdValue property.
NAME qpDropMinThresholdValue SYNTAX Integer VALUE This値は0以上でなければなりません。 特性のqpDropMaxThresholdValueが定義されるなら、qpDropMinThresholdValue属性の価値はqpDropMaxThresholdValue属性の、より価値以下であるに違いありません。
8.8.6. The Property qpDropMaxThresholdValue
8.8.6. 特性のqpDropMaxThresholdValue
This property specifies the maximum number of queuing and buffer resources that should be reserved for this class of flows. The threshold can be specified as either relative (i.e., a percentage) or absolute (i.e., number of packets or milliseconds) value according to the value of the qpDropThresholdUnits property. Congestion Control droppers should not keep more packets than the value specified in this property. Note, however, that some droppers may calculate queue occupancy averages, and therefore the actual maximum queue resources should be larger. This property is defined as follows:
この特性はこのクラスの流れのために予約されるべきである列を作りとバッファ資源の最大数を指定します。 qpDropThresholdUnits属性の価値に従って、敷居は相対的(すなわち、割合)か絶対として指定された(すなわち、パケットかミリセカンドの数)値であるかもしれません。 混雑Control点滴器は、この所有地で値より多くのパケットを指定し続けるはずがありません。 しかしながら、いくつかの点滴器が待ち行列占有平均について計算するかもしれないことに注意してください。そうすれば、したがって、実際の最大の待ち行列リソースは、より大きいはずです。 この特性は以下の通り定義されます:
NAME qpDropMaxThresholdValue
SYNTAX Integer
VALUE This value must be greater than or equal to 0. If the
property qpDropMinThresholdValue is defined, then the
value of the qpDropMinThresholdValue property must be
less than or equal to the value of the
qpDropMaxThresholdValue property.
NAME qpDropMaxThresholdValue SYNTAX Integer VALUE This値は0以上でなければなりません。 特性のqpDropMinThresholdValueが定義されるなら、qpDropMinThresholdValue属性の価値はqpDropMaxThresholdValue属性の、より価値以下であるに違いありません。
8.9. Class QoSPolicyTrfcProf
8.9. クラスQoSPolicyTrfcProf
This is an abstract base class that models a traffic profile. Traffic profiles specify the maximum rate parameters used within admission decisions. The association QoSPolicyTrfcProfInAdmissionAction binds the admission decision to the traffic profile. The class definition is as follows:
これはトラフィックプロフィールをモデル化する抽象的な基底クラスです。 トラフィックプロフィールは合否判定の中で使用された最高率パラメタを指定します。 協会QoSPolicyTrfcProfInAdmissionActionはトラフィックプロフィールに合否判定を縛ります。 クラス定義は以下の通りです:
NAME QoSPolicyTrfcProf DERIVED FROM Policy (defined in [PCIM]) ABSTRACT TRUE PROPERTIES None
名前QoSPolicyTrfcProfは方針([PCIM]では、定義される)の抽象的な本当の特性からなにも引き出しませんでした。
Snir, et al. Standards Track [Page 56] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[56ページ]。
8.10. Class QoSPolicyTokenBucketTrfcProf
8.10. クラスQoSPolicyTokenBucketTrfcProf
This class models a two- or three-level Token Bucket traffic profile. Additional profiles can be modeled by cascading multiple instances of this class (e.g., by connecting the output of one instance to the input of another instance). This traffic profile carries the policer or shaper rate values to be enforced on a flow or a set of flows. The class definition is as follows:
このクラスは2か3レベルのToken Bucketトラフィックプロフィールをモデル化します。 このクラス(例えば、1つのインスタンスの出力を別のインスタンスの入力に関連づけるのによる)の複数の滝のインスタンスは追加プロフィールをモデル化できます。 このトラフィックプロフィールは、流れか流れのセットで実施されるためにpolicerか整形器レート値を載せます。 クラス定義は以下の通りです:
NAME QoSPolicyTokenBucketTrfcProf DERIVED FROM QoSPolicyTrfcProf (defined in this document) ABSTRACT FALSE PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst
NAME QoSPolicyTokenBucketTrfcProf DERIVED FROM QoSPolicyTrfcProf(本書では定義される)の抽象的なFALSE PROPERTIES qpTBRate、qpTBNormalBurst、qpTBExcessBurst
8.10.1. The Property qpTBRate
8.10.1. 特性のqpTBRate
This is a non-negative integer that defines the token rate in kilobits per second. A rate of zero means that all packets will be out of profile. This property is defined as follows:
これは1秒あたりのキロビットがトークンレートを定義する非負の整数です。 ゼロのレートは、すべてのパケットがプロフィールを使い果たすつもりであったことを意味します。 この特性は以下の通り定義されます:
NAME qpTBRate SYNTAX Integer VALUE This value must be greater than to 0
NAME qpTBRate SYNTAX Integer VALUE This値は0より大きいに違いありません。
8.10.2. The Property qpTBNormalBurst
8.10.2. 特性のqpTBNormalBurst
This property is an integer that defines the normal size of a burst measured in bytes. This property is defined as follows:
この特性はバイトで測定された炸裂の標準サイズを定義する整数です。 この特性は以下の通り定義されます:
NAME qpTBNormalBurst SYNTAX Integer VALUE This value must be greater than to 0
NAME qpTBNormalBurst SYNTAX Integer VALUE This値は0より大きいに違いありません。
8.10.3. The Property qpTBExcessBurst
8.10.3. 特性のqpTBExcessBurst
This property is an integer that defines the excess burst size measured in bytes. This property is defined as follows:
この特性はバイトで測定された余分な放出量を定義する整数です。 この特性は以下の通り定義されます:
NAME qpTBExcessBurst
SYNTAX Integer
VALUE This value must be greater than or equal to
qpTBNormalBurst
NAME qpTBExcessBurst SYNTAX Integer VALUE This値がそう以上でなければならない、qpTBNormalBurst
8.11. Class QoSPolicyIntServTrfcProf
8.11. クラスQoSPolicyIntServTrfcProf
This class represents an IntServ traffic profile. Values of IntServ traffic profiles are compared against Traffic specification (TSPEC) and QoS Reservation (FLOWSPEC) requests carried in RSVP requests.
このクラスはIntServトラフィックプロフィールを表します。 IntServトラフィックプロフィールの値はRSVP要求で運ばれたTraffic仕様(TSPEC)とQoS予約(FLOWSPEC)要求に対してたとえられます。
Snir, et al. Standards Track [Page 57] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[57ページ]。
The class definition is as follows:
クラス定義は以下の通りです:
NAME QoSPolicyIntServTrfcProf
DERIVED FROM QoSPolicyTrfcProf (defined in this document)
ABSTRACT FALSE
PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize,
qpISResvRate, qpISResvSlack, qpISMinPolicedUnit,
qpISMaxPktSize
NAME QoSPolicyIntServTrfcProf DERIVED FROM QoSPolicyTrfcProf(本書では定義される)の抽象的なFALSE PROPERTIES qpISTokenRate、qpISPeakRate、qpISBucketSize、qpISResvRate、qpISResvSlack、qpISMinPolicedUnit、qpISMaxPktSize
8.11.1. The Property qpISTokenRate
8.11.1. 特性のqpISTokenRate
This property is a non-negative integer that defines the token rate parameter, measured in kilobits per second. This property is defined as follows:
この特性は1秒あたりのキロビットで測定されたトークンレートパラメタを定義する非負の整数です。 この特性は以下の通り定義されます:
NAME qpISTokenRate SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISTokenRate SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.2. The Property qpISPeakRate
8.11.2. 特性のqpISPeakRate
This property is a non-negative integer that defines the peak rate parameter, measured in kilobits per second. This property is defined as follows:
この特性は1秒あたりのキロビットで測定されたピークレートパラメタを定義する非負の整数です。 この特性は以下の通り定義されます:
NAME qpISPeakRate SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISPeakRate SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.3. The Property qpISBucketSize
8.11.3. 特性のqpISBucketSize
This property is a non-negative integer that defines the token bucket size parameter, measured in bytes. This property is defined as follows:
この特性はバイトで測定されたトークンバケツサイズ・パラメータを定義する非負の整数です。 この特性は以下の通り定義されます:
NAME qpISBucketSize SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISBucketSize SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.4. The Property qpISResvRate
8.11.4. 特性のqpISResvRate
This property is a non-negative integer that defines the reservation rate (R-Spec) in the RSVP guaranteed service reservation. It is measured in kilobits per second. This property is defined as follows:
この特性はサービスの予約が保証されたRSVPで予約率(R-仕様)を定義する非負の整数です。 それは1秒あたりのキロビットで測定されます。 この特性は以下の通り定義されます:
Snir, et al. Standards Track [Page 58] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[58ページ]。
NAME qpISResvRate SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISResvRate SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.5. The Property qpISResvSlack
8.11.5. 特性のqpISResvSlack
This property is a non-negative integer that defines the RSVP slack term in the RSVP guaranteed service reservation. It is measured in microseconds. This property is defined as follows:
この特性はサービスの予約が保証されたRSVPでRSVPの低調な用語を定義する非負の整数です。 それはマイクロセカンドのときに測定されます。 この特性は以下の通り定義されます:
NAME qpISResvSlack SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISResvSlack SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.6. The Property qpISMinPolicedUnit
8.11.6. 特性のqpISMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP policed unit, measured in bytes. This property is defined as follows:
この特性はバイトで測定された最小のRSVPを定義する非負の整数に取り締まられたユニットです。 この特性は以下の通り定義されます:
NAME qpISMinPolicedUnit SYNTAX Integer VALUE This value must be greater than or equal to 0
NAME qpISMinPolicedUnit SYNTAX Integer VALUE This値は0以上でなければなりません。
8.11.7. The Property qpISMaxPktSize
8.11.7. 特性のqpISMaxPktSize
This property is a positive integer that defines the maximum allowed packet size for RSVP messages, measured in bytes. This property is defined as follows:
この特性はバイトで測定されたRSVPメッセージのためにパケットサイズが許容された最大を定義する正の整数です。 この特性は以下の通り定義されます:
NAME qpISMaxPktSize
SYNTAX Integer
VALUE This value must be a positive integer, denoting the
number of bytes in the largest payload packet of an RSVP
signaled flow or class.
NAME qpISMaxPktSize SYNTAX Integer VALUE This値が正の整数でなければならない、RSVPの最も大きいペイロードパケットでバイト数を指示すると、流れかクラスが合図されました。
8.12. The Class QoSPolicyAttributeValue
8.12. クラスQoSPolicyAttributeValue
This class can be used for representing an indirection in variable
and value references either in a simple condition ("<x> match <y>")
or a simple action ("<x> = <y>"). In both cases, <x> and <y> are
known as the variable and the value of either the condition or
action. The value of the properties qpAttributeName and
qpAttributeValueList are used to substitute <x> and <y> in the
condition or action respectively.
変数と値の参照における単純条件(「<x>マッチ<y>」)か単純アクションにおける間接指定を表すのにこのクラスを使用できます(「<x>は<y>と等しいです」)。 どちらの場合も、<x>と<y>は状態か動作の変数と値として知られています。 特性のqpAttributeNameとqpAttributeValueListの値は、状態か動作でそれぞれ<x>と<y>を代入するのに使用されます。
Snir, et al. Standards Track [Page 59] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[59ページ]。
The substitution is done as follows: The value of the property qpAttributeName is used to substitute <x> and the value of the property qpAttributeValueList is used to substitute <y>.
代替は以下の通り完了しています: 特性のqpAttributeNameの値は<x>を代入するのに使用されます、そして、特性のqpAttributeValueListの値は、<y>を代入するのに使用されます。
Once the substitution is done, the condition can be evaluated and the action can be performed.
代替がいったん完了していると、状態を評価できます、そして、動作を実行できます。
For example, suppose we want to define a condition over a user name
of the form "user == 'Smith'", using the QoSPolicyRSVPUserVariable
class. The user information in the RSVP message provides a DN. The
DN points to a user objects holding many attributes. If the relevant
attribute is "last name", we would use the QoSPolicyAttributeValue
class with qpAttributeName = "Last Name", qpAttributeValueList =
{"Smith"}.
例えば、フォーム「ユーザ='スミス'」というユーザ名の上で状態を定義したいと思うと仮定してください、QoSPolicyRSVPUserVariableのクラスを使用して。 RSVPメッセージのユーザー情報はDNを提供します。 DNは、多くの属性を保持しながら、ユーザオブジェクトを示します。 関連属性が「姓」であるなら、私たちはqpAttributeName=「姓」があるQoSPolicyAttributeValueのクラスを使用して、qpAttributeValueListは「スミス」と等しいです。
The class definition is as follows:
クラス定義は以下の通りです:
NAME QoSPolicyAttributeValue DERIVED FROM PolicyValue (defined in [PCIMe]) ABSTRACT FALSE PROPERTIES qpAttributeName, qpAttributeValueList
PolicyValue([PCIMe]では、定義される)の抽象的な偽の特性のqpAttributeName、qpAttributeValueListから得られた名前QoSPolicyAttributeValue
8.12.1. The Property qpAttributeName
8.12.1. 特性のqpAttributeName
This property carries the name of the attribute that is to be used to substitute <x> in a simple condition or simple condition of the forms "<x> match <y>" or "<x> = <y>" respectively. This property is defined as follows:
この特性はフォーム「<x>マッチ<y>」か「<x>は<y>と等しい」の単純条件か単純条件でそれぞれ<x>を代入するのに使用されることになっている属性の名前を運びます。 この特性は以下の通り定義されます:
NAME qpAttributeName SYNTAX String
名前qpAttributeName構文ストリング
8.12.2. The Property qpAttributeValueList
8.12.2. 特性のqpAttributeValueList
This property carries a list of values that is to be used to substitute <y> in a simple condition or simple action of the forms "<x> match <y>" or "<x> = <y>" respectively.
この特性はそれぞれ単純条件で<y>を代入するのに使用されることになっている値のリストか形式「<x>マッチ<y>」か「<x>は<y>と等しい」の単純アクションを運びます。
This property is defined as follows:
この特性は以下の通り定義されます:
NAME qpAttributeValueList SYNTAX String
名前qpAttributeValueList構文ストリング
8.13. The Class "QoSPolicyRSVPVariable"
8.13. クラス"QoSPolicyRSVPVariable"
This is an abstract class that serves as the base class for all implicit variables that have to do with RSVP conditioning. The class definition is as follows:
これはRSVP調節と関係があるすべての暗黙の変数のための基底クラスとして機能する抽象クラスです。 クラス定義は以下の通りです:
Snir, et al. Standards Track [Page 60] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[60ページ]。
NAME QoSPolicyRSVPVariable
DESCRIPTION An abstract base class used to build other classes
that specify different attributes of an RSVP request
DERIVED FROM PolicyImplicitVariable (defined in [PCIMe])
ABSTRACT TRUE
PROPERTIES None
NAME QoSPolicyRSVPVariableの記述のAnの抽象的な基底クラスは以前はよくRSVP要求DERIVED FROM PolicyImplicitVariable([PCIMe]では、定義される)の抽象的なTRUE PROPERTIES Noneの異なった属性を指定する他のクラスを造っていました。
8.14. The Class "QoSPolicyRSVPSourceIPv4Variable"
8.14. クラス"QoSPolicyRSVPSourceIPv4Variable"
This is a concrete class that contains the source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
これはRSVPのIPv4アドレスが流れを示したソースを含む具象クラスです、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPSourceIPv4Variable
DESCRIPTION The source IPv4 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ソースIPv4が扱うRSVPのNAME QoSPolicyRSVPSourceIPv4Variable記述は流れを示しました、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
値のタイプは許容しました: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable"
8.15. クラス"QoSPolicyRSVPDestinationIPv4Variable"
This is a concrete class that contains the destination IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
これはRSVPのIPv4アドレスが流れを示した目的地を含む具象クラスです、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the RSVP signaled
flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
目的地IPv4が扱うRSVPのNAME QoSPolicyRSVPDestinationIPv4Variable記述は流れを示しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
値のタイプは許容しました: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
Snir, et al. Standards Track [Page 61] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[61ページ]。
8.16. The Class "QoSPolicyRSVPSourceIPv6Variable"
8.16. クラス"QoSPolicyRSVPSourceIPv6Variable"
This is a concrete class that contains the source IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
これはRSVPのIPv6アドレスが流れを示したソースを含む具象クラスです、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPSourceIPv6Variable
DESCRIPTION The source IPv6 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ソースIPv6が扱うRSVPのNAME QoSPolicyRSVPSourceIPv6Variable記述は流れを示しました、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
値のタイプは許容しました: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable"
8.17. クラス"QoSPolicyRSVPDestinationIPv6Variable"
This is a concrete class that contains the destination IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
これはRSVPのIPv6アドレスが流れを示した目的地を含む具象クラスです、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the RSVP signaled
flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
目的地IPv6が扱うRSVPのNAME QoSPolicyRSVPDestinationIPv6Variable記述は流れを示しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
値のタイプは許容しました: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.18. The Class "QoSPolicyRSVPSourcePortVariable"
8.18. クラス"QoSPolicyRSVPSourcePortVariable"
This class contains the source port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
合図されて、このクラスはRSVPのソースポートを含みます。流れてください、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPSourcePortVariable
DESCRIPTION The source port of the RSVP signaled flow, as defined
in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
_RSVPのソースポートが流れに合図したNAME QoSPolicyRSVPSourcePortVariable記述、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTERで定義されるように、SPEC[RSVP]は反対します。
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
値のタイプは許容しました: PolicyIntegerValue(0..65535)
Snir, et al. Standards Track [Page 62] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[62ページ]。
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.19. The Class "QoSPolicyRSVPDestinationPortVariable"
8.19. クラス"QoSPolicyRSVPDestinationPortVariable"
This is a concrete class that contains the destination port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
これはRSVPのポートが流れに合図した目的地を含む具象クラスです、RSVP PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPDestinationPortVariable
DESCRIPTION The destination port of the RSVP signaled flow, as
defined in the RSVP PATH and RESV SESSION [RSVP]
objects.
RSVPの仕向港が流れに合図したNAME QoSPolicyRSVPDestinationPortVariable記述、RSVP PATHとRESV SESSIONで定義されるように、[RSVP]は反対します。
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
値のタイプは許容しました: PolicyIntegerValue(0..65535)
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.20. The Class "QoSPolicyRSVPIPProtocolVariable"
8.20. クラス"QoSPolicyRSVPIPProtocolVariable"
This is a concrete class that contains the IP Protocol number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. The class definition is as follows:
これはRSVPの数が流れを示したIPプロトコルを含む具象クラスです、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPIPProtocolVariable
DESCRIPTION The IP Protocol number of the RSVP signaled flow, as
defined in the RSVP PATH and RESV SESSION [RSVP]
objects.
RSVPのIPプロトコル番号が流れを示したNAME QoSPolicyRSVPIPProtocolVariable記述、RSVP PATHとRESV SESSIONで定義されるように、[RSVP]は反対します。
ALLOWED VALUE TYPES: PolicyIntegerValue
値のタイプは許容しました: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.21. The Class "QoSPolicyRSVPIPVersionVariable"
8.21. クラス"QoSPolicyRSVPIPVersionVariable"
This is a concrete class that contains the IP Protocol version number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. The well-known version numbers are 4 and 6. This variable allows a policy definition of the type:
これによるRSVPのIPプロトコルバージョン番号を含む具象クラスは流れを示しました、RSVP PATHとRESV SESSION[RSVP]オブジェクトで定義されるようにことです。 よく知られるバージョン番号は、4と6です。 この変数はタイプの方針定義を許します:
"If IP version = IPv4 then ...".
「IPバージョンがその時IPv4と等しいなら」…
Snir, et al. Standards Track [Page 63] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[63ページ]。
The class definition is as follows:
クラス定義は以下の通りです:
NAME QoSPolicyRSVPIPVersionVariable
DESCRIPTION The IP version number of the IP Addresses carried the
RSVP signaled flow, as defined in the RSVP PATH and
RESV SESSION [RSVP] objects.
IPバージョンが付番する運ばれたRSVPがRSVP PATHとRESV SESSION[RSVP]で反対すると定義されるとしての流れに合図されるIP AddressesのNAME QoSPolicyRSVPIPVersionVariable記述。
ALLOWED VALUE TYPES: PolciIntegerValue
値のタイプは許容しました: PolciIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.22. The Class "QoSPolicyRSVPDCLASSVariable"
8.22. クラス"QoSPolicyRSVPDCLASSVariable"
This is a concrete class that contains the DSCP value as defined in the RSVP DCLASS [DCLASS] object. The class definition is as follows:
これはRSVP DCLASS[DCLASS]オブジェクトで定義されるようにDSCP値を含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPDCLASSVariable
DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS]
object.
DSCPがRSVP DCLASS[DCLASS]オブジェクトで定義されるように評価するNAME QoSPolicyRSVPDCLASSVariable記述。
ALLOWED VALUE TYPES: PolicyIntegerValue,
PolicyBitStringValue
値のタイプは許容しました: PolicyIntegerValue、PolicyBitStringValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.23. The Class "QoSPolicyRSVPStyleVariable"
8.23. クラス"QoSPolicyRSVPStyleVariable"
This is a concrete class that contains the reservation style as defined in the RSVP STYLE object in the RESV message [RSVP]. The class definition is as follows:
これはRESVメッセージ[RSVP]のRSVP STYLEオブジェクトで定義されるように予約スタイルを含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPStyleVariable
DESCRIPTION The reservation style as defined in the RSVP STYLE
object in the RESV message [RSVP].
予約がRESVメッセージ[RSVP]のRSVP STYLEオブジェクトで定義されるように流行に合わせるNAME QoSPolicyRSVPStyleVariable記述。
ALLOWED VALUE TYPES: PolicyBitStringValue,
PolicyIntegerValue (Integer has
an enumeration of
{ Fixed-Filter=1,
Shared-Explicit=2,
Wildcard-Filter=3}
値のタイプは許容しました: PolicyBitStringValue、PolicyIntegerValue、(整数には、列挙があります。固定フィルタの=1、共有されて明白な=2、ワイルドカードフィルタ=3
Snir, et al. Standards Track [Page 64] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[64ページ]。
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.24. The Class "QoSPolicyIntServVariable"
8.24. クラス"QoSPolicyIntServVariable"
This is a concrete class that contains the Integrated Service requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP]. The class definition is as follows:
これはRSVP予約メッセージで要求されたIntegrated Serviceを含む具象クラスです、FLOWSPEC RSVP Object[RSVP]で定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPIntServVariable
DESCRIPTION The integrated Service requested in the RSVP
Reservation message, as defined in the FLOWSPEC RSVP
Object [RSVP].
統合ServiceがFLOWSPEC RSVP Object[RSVP]で定義されるようにRSVP予約メッセージで要求したNAME QoSPolicyRSVPIntServVariable記述。
ALLOWED VALUE TYPES: PolicyIntegerValue (An enumerated
value of { CL=1 , GS=2, NULL=3}
値のタイプは許容しました: PolicyIntegerValue、(値を列挙します。Cl=1、GS=2、ヌル=3
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.25. The Class "QoSPolicyRSVPMessageTypeVariable"
8.25. クラス"QoSPolicyRSVPMessageTypeVariable"
This is a concrete class that contains the RSVP message type, as defined in the RSVP message common header [RSVP] object. The class definition is as follows:
これはRSVPメッセージタイプを含む具象クラスです、RSVPのメッセージの一般的なヘッダー[RSVP]オブジェクトで定義されるように。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPMessageTypeVariable
DESCRIPTION The RSVP message type, as defined in the RSVP message
common header [RSVP] object.
RSVPメッセージがRSVPのメッセージの一般的なヘッダー[RSVP]オブジェクトで定義されるようにタイプするNAME QoSPolicyRSVPMessageTypeVariable記述。
ALLOWED VALUE TYPES: Integer (An enumerated value of
{PATH=1 , PATHTEAR=2, RESV=3,
RESVTEAR=4, RESVERR=5, CONF=6,
PATHERR=7}
値のタイプは許容しました: 整数、(値を列挙します。経路は1、PATHTEAR=2、RESV=3、RESVTEAR=4、RESVERR=5、CONF=6、PATHERR=7と等しいです。
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable"
8.26. クラス"QoSPolicyRSVPPreemptionPriorityVariable"
This is a concrete class that contains the RSVP reservation priority, as defined in [RFC3181] object. The class definition is as follows:
これは[RFC3181]オブジェクトで定義されるようにRSVP予約優先権を含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPPreemptionPriorityVariable DESCRIPTION The RSVP reservation priority as defined in [RFC3181].
NAME QoSPolicyRSVPPreemptionPriorityVariable記述、[RFC3181]で定義されるRSVP予約優先権。
Snir, et al. Standards Track [Page 65] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[65ページ]。
ALLOWED VALUE TYPES: PolicyIntegerValue
値のタイプは許容しました: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable"
8.27. クラス"QoSPolicyRSVPPreemptionDefPriorityVariable"
This is a concrete class that contains the RSVP reservation defending priority, as defined in [RFC3181] object. The class definition is as follows:
これは[RFC3181]オブジェクトで定義されるようにRSVPの予約の防御している優先権を含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPPreemptionDefPriorityVariable
DESCRIPTION The RSVP preemption reservation defending priority as
defined in [RFC3181].
NAME QoSPolicyRSVPPreemptionDefPriorityVariable記述、[RFC3181]で定義されるように優先権を防御するRSVP先取りの予約。
ALLOWED VALUE TYPES: PolicyIntegerValue
値のタイプは許容しました: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.28. The Class "QoSPolicyRSVPUserVariable"
8.28. クラス"QoSPolicyRSVPUserVariable"
This is a concrete class that contains the ID of the user that initiated the flow as defined in the User Locator string in the Identity Policy Object [RFC3182]. The class definition is as follows:
これはIdentity Policy Object[RFC3182]にUser Locatorストリングで定義されるように流れを起こしたユーザのIDを含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPUserVariable
DESCRIPTION The ID of the user that initiated the flow as defined
in the User Locator string in the Identity Policy
Object [RFC3182].
Identity Policy Object[RFC3182]のUser Locatorストリングで定義されるように流れを起こしたユーザのNAME QoSPolicyRSVPUserVariable DESCRIPTION ID。
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
値のタイプは許容しました: QoSPolicyDNValue、PolicyStringValue、QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.29. The Class "QoSPolicyRSVPApplicationVariable"
8.29. クラス"QoSPolicyRSVPApplicationVariable"
This is a concrete class that contains the ID of the application that generated the flow as defined in the application locator string in the Application policy object [RFC2872]. The class definition is as follows:
これはApplication政策目的[RFC2872]にアプリケーションロケータストリングで定義されるように流れを生成したアプリケーションのIDを含む具象クラスです。 クラス定義は以下の通りです:
Snir, et al. Standards Track [Page 66] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[66ページ]。
NAME QoSPolicyRSVPApplicationVariable
DESCRIPTION The ID of the application that generated the flow as
defined in the application locator string in the
Application policy object [RFC2872].
それがApplication政策目的[RFC2872]のアプリケーションロケータストリングで定義されるように流れを生成したアプリケーションのNAME QoSPolicyRSVPApplicationVariable DESCRIPTION ID。
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
値のタイプは許容しました: QoSPolicyDNValue、PolicyStringValue、QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.30. The Class "QoSPolicyRSVPAuthMethodVariable"
8.30. クラス"QoSPolicyRSVPAuthMethodVariable"
This is a concrete class that contains the type of authentication used in the Identity Policy Object [RFC3182]. The class definition is as follows:
これはIdentity Policy Object[RFC3182]で使用される認証のタイプを含む具象クラスです。 クラス定義は以下の通りです:
NAME QoSPolicyRSVPAuthMethodVariable
DESCRIPTION The RSVP Authentication type used in the Identity
Policy Object [RFC3182].
RSVP AuthenticationがタイプするNAME QoSPolicyRSVPAuthMethodVariable記述はIdentity Policy Objectで[RFC3182]を使用しました。
ALLOWED VALUE TYPES: PolicyIntegerValue (An enumeration
of { NONE=0, PLAIN-TEXT=1,
DIGITAL-SIG = 2, KERBEROS_TKT=3,
X509_V3_CERT=4, PGP_CERT=5}
値のタイプは許容しました: PolicyIntegerValue、(列挙なにも=0、プレーンテキスト=1、デジタルSIG=2、ケルベロス_TKT=3、X509_V3_本命=4、PGP_本命=5
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
DERIVED FROM QoSPolicyRSVPVariable(本書では定義される)の抽象的なFALSE PROPERTIES None
8.31. The Class QoSPolicyDNValue
8.31. クラスQoSPolicyDNValue
This class is used to represent a single or set of Distinguished Name [DNDEF] values, including wildcards. A Distinguished Name is a name that can be used as a key to retrieve an object from a directory service. This value can be used in comparison to reference values carried in RSVP policy objects, as specified in [RFC3182]. The class definition is as follows:
このクラスは、ワイルドカードを含むDistinguished Name[DNDEF]値のシングルかセットを表すのに使用されます。 Distinguished Nameはディレクトリサービスからオブジェクトを検索するのにキーとして使用できる名前です。 比較に[RFC3182]で指定されるようにRSVP政策目的で運ばれた基準値にこの値を使用できます。 クラス定義は以下の通りです:
NAME QoSPolicyDNValue DERIVED FROM PolicyValue ABSTRACT FALSE PROPERTIES qpDNList
PolicyValueの抽象的な偽の特性のqpDNListから得られた名前QoSPolicyDNValue
Snir, et al. Standards Track [Page 67] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[67ページ]。
8.31.1. The Property qpDNList
8.31.1. 特性のqpDNList
This attribute provides an unordered list of strings, each
representing a Distinguished Name (DN) with wildcards. The format of
a DN is defined in [DNDEF]. The asterisk character ("*") is used as
wildcard for either a single attribute value or a wildcard for an
RDN. The order of RDNs is significant. For example: A qpDNList
attribute carrying the following value:
ワイルドカードでそれぞれ、Distinguished Name(DN)を表して、この属性はストリングの順不同のリストを提供します。 DNの書式は[DNDEF]で定義されます。 アスタリスクキャラクタ(「*」)はRDNのためのただ一つの属性値かワイルドカードのどちらかにワイルドカードとして使用されます。 RDNsの注文は重要です。 例えば: 以下の値を運ぶqpDNList属性:
"CN=*, OU=Sales, O=Widget Inc., *, C=US" matches:
「CN=*(OU=販売、O=ウィジェット株式会社*、C)は米国と等しいこと」は合っています:
"CN=J. Smith, OU=Sales, O=Widget Inc, C=US"
"CN=J"。 「販売、スミス、OU=OはウィジェットInc、C=米国と等しいです」
and also matches:
マッチも:
"CN=J. Smith, OU=Sales, O=Widget Inc, L=CA, C=US".
"CN=J"。 「販売、スミス、OU=OはウィジェットInc、L=カリフォルニア(米国)とC=等しいです。」
The attribute is defined as follows:
属性は以下の通り定義されます:
NAME qpDNList
SYNTAX List of Distinguished Names implemented as strings, each of
which serves as a reference to another object.
それのそれぞれが別のオブジェクトに参考になるストリングとして実装されたDistinguished NamesのNAME qpDNList SYNTAX List。
8.32. The Class QoSPolicyRSVPSimpleAction
8.32. クラスQoSPolicyRSVPSimpleAction
This action controls the content of RSVP messages and the way RSVP requests are admitted. Depending on the value of its qpRSVPActionType property, this action directly translates into either a COPS Replace Decision or a COPS Stateless Decision, or both as defined in COPS for RSVP. Only variables that are subclasses of the QoSPolicyRSVPVariable are allowed to be associated with this action. The property definition is as follows:
この動作はRSVPメッセージの内容とRSVP要求が認められる方法を制御します。 qpRSVPActionType属性の価値によって、この動作はCOPS Replace DecisionかCOPS Stateless Decisionのどちらかの中RSVPのためにCOPSでともに定義されることように直接翻訳されます。 QoSPolicyRSVPVariableのサブクラスである唯一の変数がこの動作に関連させているのが許容されています。 特性の定義は以下の通りです:
NAME QoSPolicyRSVPSimpleAction
DESCRIPTION This action controls the content of RSVP messages and
the way RSVP requests are admitted.
DERIVED FROM SimplePolicyAction (defined in [PCIMe])
ABSTRACT FALSE
PROPERTIES qpRSVPActionType
NAME QoSPolicyRSVPSimpleAction記述This動作はRSVPメッセージの内容とRSVP要求が認められる方法を制御します。 SimplePolicyAction([PCIMe]では、定義される)の抽象的な偽の特性のqpRSVPActionTypeから、派生します。
8.32.1. The Property qpRSVPActionType
8.32.1. 特性のqpRSVPActionType
This property is an enumerated integer denoting the type(s) of RSVP action. The value 'REPLACE' denotes a COPS Replace Decision action. The value 'STATELESS' denotes a COPS Stateless Decision action. The value REPLACEANDSTATELESS denotes both decision actions. Refer to [RFC2749] for details.
この特性はRSVP動作のタイプを指示する列挙された整数です。 値の'REPLACE'はCOPS Replace Decision動作を指示します。 値の'STATELESS'はCOPS Stateless Decision動作を指示します。 値のREPLACEANDSTATELESSは両方の決定動作を指示します。 詳細について[RFC2749]を参照してください。
Snir, et al. Standards Track [Page 68] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[68ページ]。
NAME qpRSVPActionType
DESCRIPTION This property specifies whether the action type is for
COPS Replace, Stateless, or both types of decisions.
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies
a COPS Replace decision. A value of 1 specifies a COPS
Stateless Decision. A value of 2 specifies both COPS
Replace and COPS Stateless decisions.
NAME qpRSVPActionType記述Thisの特性は、動作タイプがCOPS Replace、Stateless、またはタイプの両方の決定に賛成するかを指定します。 SYNTAX Integer VALUE Thisは列挙された整数です。 0の値はCOPS Replace決定を指定します。 1の値はCOPS Stateless Decisionを指定します。 2の値はCOPS ReplaceとCOPS Stateless決定の両方を指定します。
9. Intellectual Property Rights Statement
9. 知的所有権声明
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専務に情報を扱ってください。
10. Acknowledgements
10. 承認
The authors wish to thank the input of the participants of the Policy Framework working group, and especially the combined group of the PCIMe coauthors, Lee Rafalow, Andrea Westerinen, Ritu Chadha and Marcus Brunner. In addition, we'd like to acknowledge the valuable contribution from Ed Ellesson, Joel Halpern and Mircea Pana. Thank you all for your comments, critique, ideas and general contribution.
作者はPolicy Frameworkワーキンググループの関係者の入力、および特にPCIMe共著者、リーRafalow、アンドレアWesterinen、Ritu Chadha、およびMarcusブルンナーの合併しているグループに感謝したがっています。 さらに、エドEllesson、ジョエル・アルペルン、およびミルチア・パーナから有価約因を承諾したいと思います。 コメント、批評、考え、および一般的な貢献すべて、ありがとうございます。
11. Security Considerations
11. セキュリティ問題
The Policy Core Information Model [PCIM] describes the general security considerations related to the general core policy model. The extensions defined in this document do not introduce any additional considerations related to security.
Policy Core情報Model[PCIM]は一般的なコア政策モデルと関係がある総合証券問題について説明します。 本書では定義された拡大はセキュリティに関連するどんな追加問題も紹介しません。
Snir, et al. Standards Track [Page 69] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[69ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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
Extensions", RFC 3460, January 2003.
[PCIMe] ムーア、B.、エド、「方針コア情報モデル拡張子」、RFC3460、1月2003日
12.2. Informative References
12.2. 有益な参照
[TERMS] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and M. Waldbusser, "Terminology for Policy-based
Management", RFC 3198, November 2001.
RFC3198年のWaldbusser、「方針を拠点とする管理のための用語」という[用語。]Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ハーツォグ、S.、Huynh、A.、カールソン、M.、ペリー、J.、およびM.(2001年11月)
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DIFFSERV] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June
1994.
[INTSERV] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2749] Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan,
R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January
2000.
[RFC2749]ハーツォグ、S.(エド)とボイルとJ.とコーエンとR.とダラムとD.とRajanとR.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[RFC3181] ハーツォグ、S.、「合図された先取り優先権方針要素」、RFC3181、2001年10月。
[DIFF-MIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[デフ-MIB] ベイカー、F.、チェン、K.、およびA.スミス(「差別化されたサービスアーキテクチャのための管理情報ベース」、RFC3289)は2002がそうするかもしれません。
[AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[AF] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
Snir, et al. Standards Track [Page 70] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[70ページ]。
[CL] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[Cl] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[RSVP-IS] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RSVP存在、]、Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、9月1997日
[GS] Shenker, S., Partridge, C. and R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC 2212, September
1997.
[GS] ShenkerとS.とヤマウズラとC.とR.ゲラン、「保証されたサービスの質の仕様」、RFC2212、1997年9月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[DCLASS]Bernet、Y.、「RSVP DCLASSオブジェクトの形式」、RFC2996、2000年11月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[RFC3182]YadavとS.とYavatkarとR.とPabbatiとR.とフォードとP.、ムーアとT.とハーツォグとS.とR.ヘス、「RSVPのアイデンティティ表現」RFC3182(2001年10月)。
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
Application Identity Policy Element for Use with RSVP",
RFC 2872, June 2000.
[RFC2872] Bernet、Y.、R.Pabbati、および「RSVPとの使用のためのアプリケーションと潜水艦アプリケーションアイデンティティ方針要素」、RFC2872(2000年6月)
[DNDEF] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[DNDEF] ウォール、M.、Kille、S.、およびT.ハウズ、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。
Snir, et al. Standards Track [Page 71] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[71ページ]。
13. Authors' Addresses
13. 作者のアドレス
Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766
ヨラムランベルクシスコシステムズ4Maskit Pituach、通りヘルズリヤイスラエル46766
Phone: +972-9-970-0081 Fax: +972-9-970-0219 EMail: yramberg@cisco.com
以下に電話をしてください。 +972-9-970-0081 Fax: +972-9-970-0219 メールしてください: yramberg@cisco.com
Yoram Snir Cisco Systems 300 East Tasman Drive San Jose, CA 95134
ヨラムSnirシスコシステムズ300の東タスマン・Driveサンノゼ、カリフォルニア 95134
Phone: +1 408-853-4053 Fax: +1 408 526-7864 EMail: ysnir@cisco.com
以下に電話をしてください。 +1 408-853-4053Fax: +1 408 526-7864 メールしてください: ysnir@cisco.com
John Strassner Intelliden Corporation 90 South Cascade Avenue Colorado Springs, Colorado 80903
ジョンStrassner Intelliden社90の南カスケードアベニューコロラド・スプリングス、コロラド 80903
Phone: +1-719-785-0648 Fax: +1-719-785-0644 EMail: john.strassner@intelliden.com
以下に電話をしてください。 +1-719-785-0648 Fax: +1-719-785-0644 メールしてください: john.strassner@intelliden.com
Ron Cohen Ntear LLC
ロンコーエンNtear LLC
Phone: +972-8-9402586 Fax: +972-9-9717798 EMail: ronc@lyciumnetworks.com
以下に電話をしてください。 +972-8-9402586Fax: +972-9-9717798はメールされます: ronc@lyciumnetworks.com
Bob Moore IBM Corporation P. O. Box 12195, BRQA/501/G206 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195
ボブムーアIBM社のP. O. Box12195、BRQA/501/G206 3039コーンウォリス通り リサーチトライアングル公園、NC27709-2195
Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com
以下に電話をしてください。 +1 919-254-4436Fax: +1 919-254-6243 メールしてください: remoore@us.ibm.com
Snir, et al. Standards Track [Page 72] RFC 3644 Policy QoS Information Model November 2003
Snir、他 規格は方針QoS情報モデル2003年11月にRFC3644を追跡します[72ページ]。
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Snir, et al. Standards Track [Page 73]
Snir、他 標準化過程[73ページ]
一覧
スポンサーリンク
