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
Policy Quality of Service (QoS) Information Model
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
このドキュメントでは、サービス品質（QoS）のネットワーク管理ポリシーを表現するためのオブジェクト指向の情報モデルを提示します。この文書は、IETF方針コア情報モデルとその拡張機能に基づいています。これは、ポリシーを使用して差別化し、統合されたサービスのためのQoSの施行のための情報モデルを定義します。なお、このドキュメントは、定義により、任意の特定のデータ記憶機構とアクセス・プロトコルとは独立している情報モデルを定義することに留意することが重要です。
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
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
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
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ポリシーの情報モデル（QPIM）は、標準的なフレームワークを確立し、管理するポリシーを指定し、表現するための構築、管理、およびネットワークのQoSリソースへのアクセスを制御します。このような政策は、このドキュメントの「QoSポリシー」と呼ぶことにします。フレームワークは、オブジェクト指向の情報モデルに編成されたクラスと関係のセットで構成されています。これは、任意の特定のポリシー決定ポイント（PDP）又はポリシー施行点（PEP）のとらわれない（定義については[用語]を参照）の実装、および任意の特定の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ポリシー情報を表すように設計されている（[用語]で定義されている用語「ポリシー・ドメイン」）。この情報モデルの主な目的は、（個々のネットワーク要素のコンフィギュレーションではなく）QoSリソースを制御するための政策の彼らの定義の中で人間の管理者を支援することです。 QPIMデータインスタンスを作成するプロセスは、ビジネス・ルール、ネットワークトポロジーおよびQoSの方法論（例えば、差別化サービス）によって供給されます。
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.
この文書は、IETF方針コア情報モデルと[PCIM]と[PCIMe]で指定したように、その拡張子に基づいています。 QPIMポリシーを使用して（それぞれ、[のIntServ] [DIFFSERV]と）差別と統合サービスのQoS実施のための情報モデルを定義するために、これら二つの文書の上に構築します。なお、このドキュメントは、定義により、任意の特定のデータ記憶機構とアクセス・プロトコルとは独立している情報モデルを定義することに留意することが重要です。これは、（例えば、ディレクトリスキーマ、リレーショナルデータベーススキーマ、およびSNMP MIBの）さまざまなデータモデルは、単一の均一なモデルに従って設計され、実施されることを可能にします。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [KEYWORDS]で説明されるように解釈されます。
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は、情報の流れとしないではない描写いくつかのループおよびフィードバックを有する実際の手順を示す図です。
---------- ---------- -----------
| Business | | Topology | | QoS |
| Policy | | | |Methodology|
---------- ---------- -----------
| | |
| | |
------------------------------------
|
V
---------------
| QPIM/PCIM(e) |
| modeling |
---------------
|
| --------------
|<----------| Device info, |
| | capabilities |
| --------------
V
(---------------)
( device )---)
( configuration ) )---)
(---------------) ) )
(--------------) )
(-------------)
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の方法（例えば、DiffServの）特定のタイプのサービス（複数可）を指定するためのビジネスルールと要件[TERMS]ネットワークで配信。どちらのトポロジやビジネスルールは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]を使用して分類するために決定することができる（の説明のための役割の定義、および[PCIM]は[用語を参照してください
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は、標準的な方法でトラフィック調整ポリシーを指定するためのツールのセットを可能にします。異なるデバイスが著しく異なる機能を持つことができるので、そのようなQPIMなどの標準のQoSポリシー情報モデルを使用することも必要とされています。それらのデバイスで実行されているネットワーク・オペレーティング・システムおよびソフトウェアが異なる場合の機器であっても同じモデルは、異なる機能を持つことができます。したがって、手段は、異なるベンダーのデバイスの機能とは独立した標準的な方法で機能を指定する必要があります。これは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は、管理者がポリシー構築物の特定のセットにデバイスまたはインターフェイスの特定のセットをマッピングを支援する役割を使用しています。
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の方法論は、各トラフィッククラスに、各ノード上の特定のホップごとの転送動作を割り当てることにより、トラフィックの同様のタイプを集約するために私達を奨励します。 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つの理由のために選択しました。まず、それは最高の人間が複雑な政策を考える傾向にある道を反映しています。第二に、それは政策の階層的な組織が最も行政組織を反映してポリシーを簡単に、行政組織上にマッピングすることができます。ここで説明するポリシー定義プロセスは、特定のデバイスの機能と設定オプションとは無関係に行われていることに注意することが重要です。ポリシー定義は、実装の詳細および個々のネットワーク要素の設定インターフェースから、ならびにネットワーク要素がトラフィックを調整するために使用できる機構の完全に独立しています。
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の開発で行われた設計上の決定の波及効果を説明します。
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は、ポリシーの定義と管理、およびいないデバイス/ネットワーク構成のニーズに対応するように設計されています。
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は[PCIMe] [PCIM]に基づいて、ポリシーを定義するルールを使用して。第二に、QPIMは広範囲にポリシーとポリシー情報の階層的な組織を使用しています。第三に、QPIMは、すべての実装の詳細を指定するには、ポリシーライターを強制するものではありません。むしろ、それは、コンフィギュレーションエージェント（プラズマディスプレイパネル）は、ポリシーを解釈し、デバイス固有の構成のニーズに合わせて、それらを一致していることを前提としています。
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と評価された場合、（アクション句で指定）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.
どこ第一の角度括弧句は、交通状況であり、第二の角度括弧句は、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.
QPIMで撮影したアプローチは、具体的PolicyRuleのクラスをサブクラス化しなかったことに注意してください。ポリシー、PolicyAction、SimplePolicyAction、PolicyImplicitVariable、及びPolicyValue：むしろ、それは同様に、以下のクラスのサブクラスを定義するように、[PCIMe]で定義SimplePolicyCondition、CompoundPolicyCondition、SimplePolicyAction、及びCompoundPolicyActionクラスを使用します。 PolicyRuleのクラスをサブクラス化することは、より困難アクションと同じルール内の異なる機能ドメイン[PCIMe]内で定義された条件を組み合わせて作られているだろう。
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 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.
QPIMによって表される情報の組織は、階層的になるように設計されています。これを行うには、QPIMは、ポリシー情報の任意のネストされた組織を提供するために、[PCIMe] PolicySetComponent集約を利用しています。ポリシールールおよび/またはポリシーグループのコンテナとしてポリシーグループ機能します。ポリシールールも実現するルール/サブ規則関係を可能にする、ポリシールール及び/又は基を含むことができます。
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.
階層的な情報組織はQPIMに基づいてデータ・インスタンスの定義と読みやすさを簡素化するのに役立ちます。階層はまた、与えられた文脈でのQoSアクションのための追加的な意味を運ぶのに役立つことができます。例では、セクション2.3で詳細な、帯域幅の割り当てポリシーは、複雑なスケジューラ構造を指定することなく、直感的な形式で指定する方法階層を示しています。
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はゴール指向のQoSポリシーの定義を容易にします。これは、ネットワーク要素上のポリシーを実装するための手段とは対照的に、QoSポリシーを定義するプロセスは、政策の所望の効果に焦点を当てていることを意味しています。
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は、所望のネットワーク動作の最小の仕様を定義することを意図しています。これは、標準的な方法で発現ポリシーを解釈し、その特定の用途に必要とされる必要な構成の詳細を入力するために、デバイス固有の構成エージェントの役割です。 QPIMを使用することの利点は、デバイスに、および/またはベンダー固有の構成エージェントのそれぞれが使用できる共通の共通語を提供することです。これは、一般的なポリシーの一般的な解釈を確保するだけでなく、異なるデバイス間で実施される共通のポリシーを指定することで、管理者を支援することができます。これは、実装から仕様を分離する基本的なオブジェクト指向のパラダイムに似ています。 QPIMを使用して、トラフィック調整は、異なる実装が共通の目標を満たすことができ、一般的な方法で指定することができます。
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 writer need only specify the main goal of the policy, making sure that the preferred application receives enough bandwidth to operate adequately.
例えば、有効なポリシーは、帯域幅は、トラフィックフローの特定のセットのために確保する必要があることを指定のみ単一のルールを含むことができます。ルールは、この帯域幅割り当てをサポートするスケジューラを実装するために必要とされるかもしれない種々のその他の詳細のいずれかを含む必要はない（例えば、キュー長が必要）。 PDPやPEPには、（例えば）を使用して、これらの詳細はデフォルトキューの長さの設定を記入すると仮定されます。ポリシーライタは単に好ましいアプリケーションが適切に動作するために十分な帯域幅を受け取ることを確認し、政策の主な目標を指定する必要が。
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.
QPIMの重要な設計目標は、多くのデバイスにまたがるポリシーを定義するための手段を提供することです。この目標は、単一のデバイス、そのメカニズムと機能を制御モデリングポリシーのために設計されているデバイスレベルの情報モデルからQPIMを区別します。
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.
この設計目標は、いくつかの波及効果を持っています。まず、役割[PCIM]は、複数のデバイス間でポリシーを定義するために使用されています。第二に、抽象的な政策の使用は、個々のデバイスの特殊性に対処することから、ポリシー定義プロセスを解放し、プラズマディスプレイパネル、または他の構成物質によってモデル化する解釈と設定を残します。第三に、QPIMは異なるデバイス内で使用される複数のルールでのすべてのポリシーのビルディングブロックの大規模な再利用を可能にします。
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モデルのQoSポリシー。これは、ポリシーの単一の標準セットを使用して管理および制御するさまざまな機能を持っているさまざまなデバイスで構成されたネットワークを可能にします。それ以外の場合は、ポリシー自体が異なるデバイスの実装の違いを反映するための政策のように単一のセットを使用することが重要です。
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 preferred set of flows). The use of hierarchical context and relative QoS actions in QPIM addresses this and other related problems.
所望であれば、ポリシー定義は、同じロール内の複数のデバイスを集約できるように設計されています。 2つのコア・ネットワーク・インタフェースが異なるレートで動作する場合、例えば、一方は非常に同じ抽象ポリシーを表現するために2つの別々のポリシールールを定義する必要はありません（例えば、フローの所定の好ましいセットにインターフェイス帯域幅の30％を割り当てます）。 QPIMにおける階層的コンテキストと相対的なQoSアクションの使用は、このおよびその他の関連する問題に対処します。
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.
再利用可能なオブジェクトは、[PCIM]及び[PCIMe]によって定義されるように、このようにグローバルな概念の集中管理を可能にする、ポリシービルディングブロックを共有するための手段です。変数と値、条件とアクション、トラフィックプロファイル、およびポリシーグループとポリシールール：QPIMは、すべてのポリシーのビルディングブロックを再利用する機能を提供します。これは、大きなポリシー・ドメイン上のポリシールールの大きなセットを管理するために必要な柔軟性を提供します。
For example, the following rule makes use of centrally defined objects being reused (referenced):
例えば、次のルールは再利用される集中定義されたオブジェクト（参照）を利用します。
If <DestinationAddress == FinanceSubNet> then <DSCP = MissionCritical>
もし<宛先アドレス== FinanceSubNet>そして<DSCP =ミッションクリティカル>
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.
この規則では、条件は、値（あるいは値のセット）であるFinanceSubNet名前付きオブジェクト、再利用可能なオブジェクトのコンテナで定義され、維持を指します。 QoSアクションも、再利用可能なオブジェクトであるミッションクリティカルという名前の値を利用します。このようにポリシーを指定することの利点は、その固有の柔軟性です。ビジネスニーズは、組織のサブネット定義の変更を必要とするたびに上記の方針を考えると、必要だとすべてが再利用可能な値FinanceSubNet集中を変更することです。すべての参照のルールはすぐにそれらを個別に変更することなく、影響を受けています。この能力がなければ、ルールを格納するために使用されているリポジトリは金融サブネットを参照するすべてのルールを検索しなければならず、その後、それぞれのマッチングルールの条件を個別に更新する必要があります。これは、だけでなく、あまり効率的ではなく、エラーを起こしやすいです。
For a complete description of reusable objects, refer to [PCIM] and [PCIMe].
再利用可能なオブジェクトの完全な説明については、[PCIM]及び[PCIMe]を指します。
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.
QPIMによって定義されたポリシーが強制力でなければなりません。これは、PDPは、必要な意思決定を行い、必要なポリシールールを適用するためにQPIMのポリシー定義を使用できることを意味します。例えば、RSVPアドミッション決定はQPIMで指定されたポリシー定義に基づいてなされるべきです。 PDPは、標準または独自のどちらかのプロトコルを使用して、PEP構成にQPIMポリシー定義をマッピングすることができなければなりません。
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は、任意の特定のベンダーに依存する技術のとらわれないように設計されています。ポリシー準拠の動作は、管理下のネットワーク上で実施することができるようにしかし、QPIMの構築物は常に解釈されるべきです。したがって、QPIMが満たさなければならない3つの基本的な要件があります。
1. Policy specified by QPIM must be able to be mapped to actual network elements.
QPIMによって指定1.ポリシーは、実際のネットワーク要素にマッピングすることができなければなりません。
2. Policy specified by QPIM must be able to control QoS network functions without making reference to a specific type of device or vendor.
QPIMによって指定された前記ポリシーは、デバイスまたはベンダーの特定のタイプを参照することなくQoSのネットワーク機能を制御することができなければなりません。
3. Policy specified by QPIM must be able to be translated into network element configuration.
QPIMによって指定3.ポリシーは、ネットワーク要素の設定に変換することができなければなりません。
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満たす要件＃1及び役割の概念を使用して、上記＃2（具体的には、PCIMで定義さPolicyRolesプロパティ）。ポリシー・グループに割り当てられている役割と一致するとする要素をネットワークすることにより、PDP（または他の執行エージェント）が特定のデバイスまたはデバイスに適用されるべきポリシーを決定することができます。
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.
ネットワーク要素へのマッピング政策における役割を使用すると、モデルのスケーラビリティをサポートしています。 QPIMポリシーは、ネットワーク要素のグループに単一の役割を割り当てることにより、大規模なポリシー・ドメインにマッピングすることができます。これは、ポリシー・ドメインは、異種デバイスが含まれている場合でも行うことができます。だから、政策の小さなセットを個別に各デバイスのポリシーを再指定することなく、大規模なネットワークに展開することができます。このQPIMプロパティは、大規模なポリシー・ドメインのポリシー定義のタスクを容易にするために努力するQoSポリシー管理アプリケーションのために重要です。
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.
要件＃2は、（「ドメイン」の定義を参照[TERMS]）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.
要件＃3は、一般的に、様々なデバイス上で設定されたQoS条件とアクションをモデル化することによって満たされます。しかし、QPIMは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.
異なるのPEPが異なるのPEPは、同じポリシーで制御されている場合でも、異なる個々の構成を必要と異なる能力と機能を、持っていることに注意することが重要です。
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.
2主な標準ベースのQoSの方法論は、これまでに区別されているサービス（DiffServの）および統合サービス（IntServの）を開発しました。 DiffServは、スケーラブルな方法で、多数のデバイスに適用されるポリシーを強制する方法を提供します。 QPIMは、分類、ポリシングを制御したDiffServネットワークのコア内のホップ単位動作を制御差別化サービスドメインの境界、ならびにアクション内で行わシェーピングアクション及び条件を提供します。 QPIMは、政策手法としてのDiffServの使用を強制しません。
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.
ネットワークからQoSを要求するエンドノード（エッジノード）のための方法は、一緒にそのシグナリング・プロトコル（RSVP）と、サービスを提供する統合します。 QPIMは、ネットワーク内でこのような要求の予約を制御するアクションを提供します。
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.
両方の方法論は進化し続けている、QPIMは、すべての可能なシナリオの完全なカバレッジを提供しようとしません。その代わり、QPIMは、すべての主要なシナリオのためのポリシー制御モデルを提供することを目的とします。 QPIMは、新たに開発されたQoSメカニズムを制御の取り込みを可能にするために拡張できるように設計されています。
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.
QPIMの別の設計目標は、このようなPDPのとポリシー管理アプリケーションなどの政策・システム間の相互運用性を促進することです。 QPIMは、ポリシーの表現を標準化することによって、この相互運用性の目標を達成します。 QoSポリシーの生産者と消費者は相互理解とQoSポリシーのセマンティクスに関する合意を確保するためにQPIMベースのスキーマ（および結果のデータモデル）に依存している必要があります。
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.
例えば、ベンダーAによって建てられたQoSポリシー管理アプリケーションは、LDAPディレクトリを使用して実装にQPIMからマップするLDAPスキーマに基づいて政策を書き込むとします。今、ベンダーBとは別に構築されたPDPもQPIM由来この同じLDAPスキーマに依存していることを前提としています。これら2つの異なる型PDPを持つ2つのベンダーであっても、それぞれが他のスキーマを読み取ることができて、それを「理解します」。管理アプリケーション及びPDPの両方がQPIM仕様に準拠するように設計されたためです。同じことは、2つのポリシー管理アプリケーションと同様です。例えば、ベンダーBのポリシーの適用は、他のベンダーのポリシー管理アプリケーションによって指定されたルール内の競合があるかどうかを計算する検証ツールを実行してもよいです。
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.
QPIM生産/消費者の相互運用性は、高レベルの定義によるもので、同じポリシーが同じPEP構成になりますことを保証するものではありません。まず、異なるのPEPは異なるのPEPは、同じポリシーで制御されている場合でも、異なる個々の構成を必要と異なる能力と機能を持っています。第二に、異なるPDPは、異なる能力と機能を持つことになり、高レベルのQPIMポリシーは異なりPDPの機能に応じて、だけでなく、PDPによって制御されているのPEPの機能に変換することもできます。しかし、異なる構成は、まだポリシールールで指定されたものと同じネットワークの動作になるはずです。
This section provides a discussion of QoS policy abstraction and the way QPIM addresses this issue.
このセクションでは、QoSポリシーの抽象化とQPIMは、この問題を解決する方法の説明を提供します。
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.
上述したように、QPIMの主な目標は、人間のポリシーメーカーとポリシーを実施するように構成されたネットワーク要素との間の概念的なギャップのブリッジ部分を助けるために使用することができる情報のモデルを作成することです。明らかに、このワイドギャップは、抽象から具象に、いくつかの翻訳レベルを意味します。抽象的な終わりにビジネスのQoSポリシールールがあります。ビジネスルールを知られたら、ネットワーク管理者は、ネットワークのQoSポリシーとしてそれらを解釈し、QPIMの構文を使用してこのQoSポリシーを表している必要があります。正式に人間発現QoSポリシーを表す：QPIMは、このように最初の具体化のレベルを提供する、QoSのルールの形式的な表現を容易にします。
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"
「人事アプリケーションは、単純なWebアプリケーションよりも優れたQoSを持つべきです」
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"
「人材のアプリケーションによって生成されるトラフィックは、非ミッションクリティカルなアプリケーションを使用してWebを閲覧する人によって生成されたトラフィックよりもその目的地との通信のより高い確率を持っている必要があります」
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.
この文は明らかにビジネスレベルでのQoSポリシーを定義しますが、ネットワーク要素によって執行可能に十分具体的ではありません。 「ネットワーク用語と言語」への翻訳が必要とされます。
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.
スケールの他方の端部には、PEPとして機能するネットワーク要素は、ルータなどの、その内の作業QoSメカニズムの動作パラメータを決定する特定のコマンドを使用して構成することができます。例えば、（仮想）コマンド「出力キュー深度= 100」（転送しない）後続のパケットが破棄される前に格納される100個のパケットまで可能にするルータのネットワーク・インターフェース・カードに指示してもよいです。異なるベンダーがその装置を内蔵、あるいはそれが同じベンダーからのものであっても、異なる機能のセット、ひいては実装を持っているので、同じネットワーク内の異なる装置上で、同じ命令は、別の形態をとることができます。また、特定のPEPは、同じQoSポリシーを実装する別の命令をもたらすことができる、より長いと言うキュー、50個のパケットを、作成する能力を持っていないかもしれません。
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.
第二は、「具体的な構成」を示しつつ、第1の例では、「抽象ポリシー」を示します。また、最初の例では、ネットワーク全体のアプリケーショントラフィックのコンディショニングをカバーするエンドツーエンドのポリシーを示します。第二の例は、特定のPEPまたはそのセットの構成を示す図です。唯一のネットワークの様々な部分でのPEPの構成によって実施することができるエンドツーエンドのポリシーステートメントが、情報政策のモデルとPEPは、そのポリシーを実装するために使用するメカニズムとは大きく異なっています。
The translation process from abstract business policy to concrete PEP configuration is roughly expressed as follows:
次のように抽象的経営方針から具体的なPEP構成への変換プロセスが大まかに表されます。
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.非公式ビジネスQoSポリシーが（例えば、「すべての役員WEB要求のWeb要求が先に他の従業員の優先順位付けされなければならない」）は、ヒトポリシーメーカーで表現されます
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.ネットワーク管理者は、ポリシー・ドメインのトポロジーを解析し、特定のデバイス・インターフェースの役割を決定します。役割は、デバイスインターフェイスの大きなグループに特定のポリシーをマッピングすることになる要素の大きなグループに割り当てることができます。
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.ネットワーク管理者モデルので、抽象的な政策の正式な表現を作成し、QPIMの構築物を用いて非公式の方針。例えば、「パケットのプロトコルがHTTPであり、その先は「幹部ユーザグループにある場合、パケットヘッダにIPP 7を割り当てます」。
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.ネットワーク管理者は、上記ステップ＃2に割り当てられたネットワーク要素の役割と一致する前のステップで作成したポリシーグループに役割を割り当てます。
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は、新しいポリシー（新しいポリシー構築の役割と一致する役割を割り当てられたインターフェースを持っている、すなわち、デバイス）によって行わすべてのデバイスのデバイス固有の設定コマンドにステップ＃3で作成した抽象ポリシー構築を変換します。このプロセスでは、PDPはポリシーを実装する適切なコンフィギュレーションコマンドを決定するために、特定のデバイスの能力を調べます。
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.
ネットワーク内の各PEP 6.、PDP（またはPDPの剤）ポリシーを適用するために必要な適切なデバイス固有の命令を発行します。
QPIM, PCIM and PCIMe are used in step #3 above.
QPIM、PCIMとPCIMeは、上記ステップ＃3で使用されています。
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.
ポリシーは、サブセット[PCIMe]にグループ分けすることができるポリシールールのセットによって記述されます。ポリシールールとポリシー・グループは、階層型ポリシー定義を提供し、他のポリシールール内でネストすることができます。ネストされたルールは、サブルールと呼ばれ、我々は、交換可能に、本書では両方の用語を使用します。 【PCIMe]で定義された集約PolicySetComponentは、（別のポリシールールにポリシールールまたはグループの入れ子を表すために使用されます。
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.
階層型ポリシールールの定義は、ポリシーの可読性と再利用性を高めます。 QoSポリシー情報モデル内で、階層がサブ規則アクションのコンテキストまたは範囲をモデル化するために使用されます。 QPIM内では、帯域幅の割り当てポリシーのアクションおよびドロップしきい値のアクションは、この階層のコンテキストを使用しています。まず、帯域幅の割り当て方針の階層の使用の詳細な例を提供します。フラットと階層ポリシー表現の違いが議論されています。ドロップしきい値方針の階層を使用するには、以下のサブセクションで説明されています。最後になりましたが、QPIM内のルールの階層の使用上の制限が説明されています。
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.
これらのルールは適用されているすべてのインターフェイス上で、UDPフローへのインターフェイス帯域幅の少なくとも30％を保証、およびTCPへのインターフェイスの帯域幅の少なくとも40％が流れます。
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 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.
QoSポリシーの情報モデルは、このポリシーが適用されるインターフェイスのセットを指定する方法としての役割を使用して、ポリシーのコア情報モデルに従います。ポリシーは、すべてのインターフェイスが同じ速度で走行していると仮定し、または離れてパケットを転送することができることから、一般的に他のプロパティを持っていません。帯域幅は、UDPおよびTCPの間に割り当てられている利用可能なインターフェイス帯域幅の割合を使用して流れます。我々は1Mビット/秒の利用可能インターフェイスの帯域幅を持っていることを前提としています。そして、このルールはUDPフローに300Kbits /秒を保証します。インターフェイスの帯域幅ではなく、唯一ある64k / secであった場合は、このルールは、対応19.2キロバイト/秒を保証します。
This policy is modeled within QPIM using two policy rules of the form:
このポリシーは、フォームの2つのポリシールールを使用してQPIM内でモデル化されています。
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1) If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
（IPプロトコルがUDPである）場合（保証利用可能なBWの30％）の（1）（2）（利用可能なBWの40％を保証する）THEN（IPプロトコルがTCPである）場合
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.
これらの二つのルールがPOLICYSET [PCIMe】搬送適切な役割の組み合わせ内でグループ化されているものとします。 PEP内のこれらの規則の可能な実装は、3つのキューで重み付けラウンドロビン・スケジューラを使用することです。最初のキューは、UDPトラフィック、TCPトラフィックとトラフィックの残りのための第三キューの2番目のキューのために使用されます。加重ラウンドロビン・スケジューラの重みは、最初のキュー30％、第2の待ち行列のための40％および最後のキューは30％となります。
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.
帯域幅保証を指定するアクションは、暗黙的に保証されている帯域幅リソースはインターフェイスレベルで利用可能な帯域幅であることを前提としています。 PolicyRoleCollectionは、その目的は、特定のロールに割り当てられたリソース（この例では、インターフェイス）のセットを識別することである[PCIMe]で定義されたクラスです。したがって、PolicyRoleCollection内集約管理対象要素のタイプが制御される帯域幅リソースを定義します。この例では、インターフェイスはPolicyRoleCollection内に集約されています。したがって、ルールは、与えられた役割に一致するすべてのインターフェイスに帯域幅割り当てを指定します。その他の動作は同様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:
通常、ルールの完全な仕様は、帯域幅の割り当てが行われているトラフィックの方向を示す必要があろう。 【PCIMe]で定義された方向変数を使用して、ルールは、以下の形式で指定することができます。
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)
（IPプロトコルがUDPである）場合（IPプロトコルがTCPである）場合ならば、（保証可能なBWの40％）THEN（利用可能なBWの保証30％）（方向が出ています）
where indentation is used to indicate rule nesting. To save space, we omit the direction condition from further discussion.
インデントは、ルールのネストを示すために使用されます。スペースを節約するために、我々はさらに議論から方向条件を省略します。
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.
ルールのネストは、さらに、これらのインタフェースを介して転送された所定のトラフィック・クラス内の帯域幅割当の範囲を改良する能力を提供します。以下の例は、UDPおよびTCPアプリケーションのための帯域幅割り当てを洗練するために2つのネストされたルールを追加します。
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)
IF（IPプロトコルがUDPである）THEN（保証は利用可能なBWの30％）（1）と（プロトコルがTFTPである）THEN（保証利用可能なBWの10％）（1A）（プロトコルがNFSである）場合に利用できるのTHEN（保証40％ BW）（図1b）の場合（IPプロトコルがTCPである）THEN（保証可能なBWの40％）（2）の場合は、（プロトコルがHTTPである）THEN可能なBWの20％を保証）（2A）の場合（プロトコルがFTPである）THEN（保証利用可能なBWの30％）（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.
サブルール1aおよび1bは、UDPアプリケーションのための帯域幅の割り当てを指定します。 UDPアプリケーション間で分配される総帯域幅リソースがUDPトラフィッククラス（すなわち、30％）のために利用可能な帯域幅ではなく、インターフェイスレベルで利用可能な全帯域幅です。他のUDPアプリケーションが何かを受け取ることが保証されていない間、さらに、TFTPおよびNFSは、少なくとも10％、およびUDPのために利用可能な合計帯域幅の40％を取得することが保証されています。したがって、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フロー保証帯域幅は合計インターフェイス帯域幅保証の3％で得られた、UDPフローに保証された帯域幅の10％を取ることによって計算されます。
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およびTFTP）を（保証利用可能なBWの3％）（1A）（UDPおよびNFS）場合（保証利用可能なBWの12％）、（1B）（他のUDPのAPP）場合、（利用可能なBWの15％を保証している場合）（1C）（TCPおよびHTTP）は、利用可能なBWの8％を保証している場合）（2A）の場合（TCPおよびFTP）THEN（保証利用可能なBWの12％）（2B）の場合（他のTCPのAPP）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つの表現は同じではありますか？いいえ、帯域幅の割り当ては同じではありません。例えば、階層表現内、UDPアプリケーションは、帯域幅の30％を保証しています。 NFSまたはTFTP異なるアプリケーションの単一UDPフローが実行されているとします。このアプリケーションは、階層表現におけるインターフェイス帯域幅の30％が、フラット表現におけるインターフェイス帯域幅の15％のみが保証されることになります。
A two stage scheduler is best modeled by a hierarchical representation whereas a flat representation may be realized by a non-hierarchical scheduler.
フラット表現は、非階層型スケジューラによって実現することができるのに対し、二段階スケジューラは、最良の階層表現によってモデル化されます。
A schematic hierarchical Weighted-Round-Robin scheduler implementation that supports the hierarchical rule representation is described below.
階層的なルール表現をサポートしている模式的な階層的加重ラウンドロビンスケジューラの実装は以下の通りです。
--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%--+
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.
スケジューラA1はUDPサブ規則ポリシーで指定された量に応じて3つのUDPキューからパケットを抽出します。スケジューラA2は、TCPサブルールポリシーで指定された3つのTCPキューからパケットを抽出します。一番上のルールレベルで指定されたポリシーに従って、UDP、TCPおよび他のすべてのトラフィックの間に第二段階のスケジューラ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.
フラットと階層ルール表現との間の別の差異は、最小帯域保証上記帯域幅の実際の分割です。 HTTPストリームとNFSストリームの2つの高レートのストリームは、このインタフェースを介して転送されていると仮定する。各フローの速度がはるかインタフェースの容量を超えていると仮定します。フラットスケジューラの実装では、重みとの間の比は、8：12（即ち、HTTP：NFS）であり、NFSは帯域幅の60％を消費しつつHTTPストリームは帯域幅の40％を消費することになります。階層スケジューラの実装に充填された2つの待ち行列を有する唯一のスケジューラは、約42％を消費するスケジューラHTTP（TCP）ストリームとNFS（UDP）ストリーム間従って比B、30:40になり、したがって、HTTPストリームでありますインターフェイスの帯域幅のNFSは、インターフェイス帯域幅の58％を消費するでしょうが。どちらの場合も、両方の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.
結論は、階層ポリシー表現はフラットポリシー表現を超えて追加の構造およびコンテキストを提供することです。また、ルールの階層を使用して帯域幅割り当てを指定するポリシーは、ルールの階層が階層スケジューラレベルにマッピングされる階層スケジューラを使用して実施されるべきです。
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のリソースは、待ち行列の長さおよびドロップ動作です。この目的のために、待ち行列の長さとしきい値ポリシーが使用されています。
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)
（ドロップ技術がランダムである）THEN（プロトコルはFTPである）場合には（利用可能なBWの10％を保証）（キュー長が40のパケットに等しいです）
if (src-ip is from net 2.x.x.x) THEN min threshold = 30% max threshold = 70%
（SRC-IPはネット2.x.x.xからである）場合、最小しきい値= 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からである）場合、最小しきい値= 40％の最大しきい値= 90％
if (all other) THEN min threshold = 20% max threshold = 60%
（他のすべて）場合、最小閾値= 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パケットは、ネットワーク2.x.x.xと3.x.x.x別にすべてのネットワークから受信したランダムにFTPのキューしきい値は、キューの長さの20％まで蓄積して流れるときにドロップされます。キューが60％に埋めたら、これらすべてのパケットをキューイングする前に削除されます。他の二つのサブ規則は、指定された2つのサブネットからのFTPパケットの他の閾値を提供します。ホップ挙動につき保証転送（AF）は、トラフィッククラス内の異なるドロップ・プリファレンスを記述する階層の使用の別の良い例です。この例では、後のセクションで提供されます。
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.
第二点は、ドロップしきい値ポリシーのコンテキストを提供するだけでなく、帯域幅割り当てのためのコンテキストを指定する機能を捕捉します。
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.
場合階層レベルは、階層がドロップしきい値コンテキストを指定するために使用される場合、それが明瞭と再利用のために単に使用される場合、帯域割当コンテキストを指定することになっていますか？答えは、行動に完全に依存します。サブルール内の帯域幅制御アクションは、ルールの条件節で決まるトラフィッククラスに割り当てられる帯域幅はさらにサブルール間で分割する方法を指定します。ドロップしきい値アクションは、サブ規則のそれぞれのトラフィッククラスのキュードロップ動作を制御します。帯域制御アクションは暗黙のポインタのことわざがあります：帯域幅の割り当ては、より高いレベルのルールで定義された帯域幅のリソースを基準にしています。しきい値は、より高いレベルのルールによって定義されたキューリソースから取得されます：ドロップしきい値アクションは言っ暗黙のポインタを持っています。他のアクションは、このような暗黙のポインタを持っていない、そしてこれらのアクションのための階層にのみ再利用性と読みやすさの目的のために使用されます。
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集約を使用して、ポリシールールの下で凝集されるべきです。
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.
QoSのポリシー管理アプリケーションの1開発者は、相互運用可能な方法でのPEPとPDPのを制御するためのポリシーを定義するための拡張可能なフレームワークとして、このモデルを使用することができます。
2. Developers of Policy Decision Point (PDP) systems built to control resource allocation signaled by RSVP requests.
ポリシー決定ポイントの2開発RSVP要求によってシグナリングリソース割り当てを制御するために構築された（PDP）システム。
3. Developers of Policy Decision Points (PDP) systems built to create QoS configuration for PEPs.
ポリシー決定ポイント（PDP）のPEPのためのQoSの設定を作成するために構築されたシステムの開発3.。
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.他のネットワークポリシー情報とQoSポリシー情報を組み合わせることが決定し大規模な組織のデータと知識ベースのビルダー、すべてのモデルが[PCIM]に基づいていると仮定して、[PCIMe]。
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へのストレージの特定の技術をマッピングしたいデータモデルの作成者は、同様に、この文書を使用する必要があります。
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のクラスとの関連の継承階層は、[PCIMe] [PCIM]に根ざしたとされています。 [PCIM]にそれらの関係に着目し、[PCIMe]クラスながら、図2及び図3は、これらQPIM継承階層を示しています。例えばSimplePolicyConditionとしてQPIMポリシーを形成するのに使用される多くの他のクラスは、[PCIMe] [PCIM]で定義されていることに留意されたいです。したがって、次の図は、QPIMポリシーを定義するために必要なすべてのクラスとの関係を表すものではありません。むしろ、QPIMを用いて設計者が[PCIM]から適切なクラスおよび関係を使用して[PCIMe]以下に定義されるものと一緒にすべきです。
[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)
| | |
(continued on the next page) (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)
Figure 2. The QPIM Class Inheritance Hierarchy
図2. QPIMクラスの継承階層
Figure 3 shows the QPIM relationship hierarchy.
図3は、QPIM関係階層を示します。
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
| |
| +--- QoSPolicyConformAction (QPIM)
| |
| +--- QoSPolicyExceedAction (QPIM)
| |
| +--- QoSPolicyViolateAction (QPIM)
| |
| +--- PolicyVariableInSimplePolicyAction
| | |
| | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction
Figure 3. The QPIM Association Class Inheritance Hierarchy
図3. QPIM関連クラス継承階層
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アクションは、（[PCIM]で定義された）クラスPolicyActionを用い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]です。
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ポリシーベースのシステムでは、ネットワーク管理者が優先転送処理、ならびに好適な転送動作の特定のセットを指定して提供される必要があるフローの選択の両方を制御するルールのセットを指定することを可能にします。 QPIMは、ルールのようなセットを特定するための情報モデルを提供します。
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 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ポリシールールは、RSVPシグナリングが異なるトラフィック・ネットワークからのタイプ、ならびにいかなるシグナリングを使用しない環境に異なる転送処理を要求するために使用される制御環境を有効にするが、好ましい治療は、いくつかの（すべてではない）トラフィックタイプのために所望されます。 QoSポリシールールも厳格なQoS保証をQoSが凝集体を流すために設けられている個々のフロー、ならびに環境に提供される環境を制御することを可能にします。 QoSアクションは、PDPやPEPが、ネットワークリソースが割り当てられる前に入院すべきRSVP要求を決定することができます。 QoSアクションは、RSVPシグナリングコンテンツ自体の制御だけでなく、RSVP要求の優先順位との差別化を可能にします。 QoSアクションは差別化されたサービス・エッジ・執行、ポリシングを含む形作るとマーキングだけでなく、ネットワークコアで使用されるホップごとの挙動を制御することを可能。最後に、QoSアクションは、ホップの行動ごとに差別化されたサービスのクラウドのエッジでRSVP要求のマッピングを制御するために使用することができます。
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.
アクションの4つのグループは、[PCIMe]アクション[PCIM]で定義されたクラスから派生されます。第1のQoSアクション・グループはQoSPolicyRSVPSimpleAction、単一のアクションが含まれています。このアクションは、両方のRSVP信号制御に使用してアクションをインストールしています。第2のQoSアクション・グループは、流れの流量またはクラスが許可されるべきか否かを判断します。これはQoSPolicyTrfcProfクラスとそのサブクラスを使用して、適切なトラフィックプロファイルを指定することによって行われます。アクションのこのセットはまた、QoSPolicyAdmissionActionクラスとそのサブクラスを使用したQoSアドミッション制御動作を、含まれています。アクションの第3のグループは一緒にホップごとの挙動の転送処理を指定した帯域幅割当および輻輳制御の分化を制御します。アクションのこのグループはQoSPolicyPHBActionクラスとそのサブクラスが含まれています。第四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を使用してモデル化されています。例えば、3つのマーキングアクション（DSCP、IPPおよびCoS）はSimplePolicyActionクラスを使用して、[PCIMe]で定義された適切なタイプの変数と値をそのクラスを関連付けることによってモデル化されます。
There are three types of decisions a PDP (either remote or within a PEP) can make when it evaluates an RSVP request:
意思決定の3種類のPDP（リモートまたはPEP内のいずれか）それはRSVP要求を評価する際に行うことができますがあります。
1. Admit or reject the request 2. Add or modify the request admission parameters 3. Modify the RSVP signaling content
1. 2.コンテンツをRSVPシグナリングを変更要求の入場パラメータ3を追加または変更要求を認めるか拒否
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.
COPS RSVPのための[RFC2749]仕様は、これらの決定の各々をモデル化するために異なるデシジョン・オブジェクト・タイプを使用します。 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内で使用される決定コマンドと意思決定のフラグオブジェクトを制御します。その関連QoSPolicyIntServTrfcProfクラスでQoSPolicyRSVPAdmissionActionクラスは、QoSPolicyIntServTrfcProfによって指定されたトラフィックプロファイルに対してRSVP要求のTSPEC又はRSPECパラメータを比較することにより、所与のRSVP要求を受け入れるか拒否するかどうかを決定するために使用されます。比較方法の詳細については、RSVP仕様のCOPS次のセクション4を参照して、入場料の決定は、両方の要求を受け入れ、要求者に警告を送信するオプションがあります。 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.
PolicySimpleActionクラスから派生したクラスQoSPolicyRSVPSimpleActionは、[PCIMe]、二つの他のCOPS RSVP決定種類を制御するために使用することができます。プロパティqpRSVPActionType型のいずれかで、「REPLACE「STATELESS」、またはその両方（「REPLACEANDSTATELESS」）であることがクラスのインスタンスを指定します。 COPSは、RSVPメッセージの内容を制御し、決定を交換したように「REPLACE」のqpRSVPActionTypeプロパティ値を担持するインスタンスに対して、アクションが解釈されます。 「STATELESS」のqpRSVPActionTypeプロパティ値を担持するインスタンスについて、動作はアドミッションパラメータを制御する、COPSステートレス決定として解釈されます。これらのアクションの両方が必要な場合、これはqpRSVPActionTypeプロパティに値REPLACEANDSTATELESSを割り当てることによって行うことができます。
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用COPS交換し、ステートレスな決定を表現するためにモデル化されています。この類似性は、これらのCOPS決定の将来の使用が直接QoSPolicySimpleActionによって制御することができます。唯一必要な拡張機能は、新しいRSVP変数の定義であるかもしれません。
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は既に認め予約と比較予約の重要度を決定することができ、そして必要に応じて、より高い優先度のための余地を作るために、より低い優先度の予約を先取りすることができます。また、このクラスは設定することで、差別化されたサービスドメインにRSVP要求のマッピングを制御するために使用することができます
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。これは、与えられたDSCP値へのRSVP要求で運ばセッションおよび送信者の仕様に一致するトラフィックをマークするためにPEPに指示します。
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.
ポリシーシステムは、RSVPメッセージで運ばれた情報を制御することができるはずです。 QoSPolicyRSVPSimpleActionは、RSVPシグナリングメッセージの内容を制御することができます。 RSVPメッセージは、他の要求と比較して予約要求の優先順位を指定プリエンプションポリシーオブジェクト[RFC3181]を運ぶことができます。 RSVPメッセージはまた、認証目的のポリシーオブジェクトを運ぶことができます。 RSVPメッセージは、受信または送信側にデータトラフィックに設定されるべき特定のDSCP値を指定DCLASS [DCLASS]オブジェクトを運ぶことができます。 RSVPの置換データ決定のCOPSは、既存のものを置換または削除RSVPオブジェクトのセットを指定することによって、RSVPメッセージの内容を制御します。
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.
差別化サービスアーキテクチャ[DIFFSERV]はホストとネットワークとの間で実行されている任意のシグナリングプロトコルを必要とせず、スケーラブルなQoS差別化を提供するように設計しました。 QPIMにモデル化されたQoSアクションは、PEP実装によって使用されるデータパスメカニズムを指定することなく、ホップごとの振舞い、エッジの分類、およびポリシング及びシェーピングを含む差別化サービスアーキテクチャの構成要素の全てを制御するために使用することができます。これは、抽象化レベルの不要な詳細を隠蔽し、ネットワーク管理者は、より自然な形でネットワーク要件を発現するルールを記述することを可能にするを提供します。送信者が情報の送信を開始する前に、エンドホストとネットワーク間のシグナリングが発生しないように、このアーキテクチャでは、QoSメカニズムは、予め設定されるべきです。これは通常のPEPは、事前にポリシールールのセットでプロビジョニングする必要があることを意味します。
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])
ポリシングとシェーピングの行動は、QoS入場アクションのサブクラスとしてモデル化されています。マーキングDSCPおよびCoSは、適切な変数および値と関連SimplePolicyAction（[PCIMe]）クラスを使用してモデル化されます。帯域幅割り当て及び輻輳制御アクションは、それ自体でQpQPolicyPHBActionのサブクラスとしてモデル化されるサブクラスPolicyActionクラス（[PCIM]）
Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used to police and/or shape traffic.
入場アクション（QoSPolicyAdmissionActionとそのサブクラス）は、警察および/または形状トラフィックに使用されています。
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.
各入場アクションは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.
入場アクションは、アクションは、個々のトラフィックフローまたは集約トラフィッククラスを制御するかどうかを決定するために使用されるスコーププロパティ（qpAdmissionScope）を運びます。 「フロー」と「トラフィッククラス」の概念は、用語「マイクロフロー」と「トラフィックストリーム」を使用して、[DIFFSERV]で説明されています。大まかに言えば、フローは、送信元IP、宛先IP、プロトコル及びレイヤ4送信元ポートと宛先ポートに対して同じ値を持つIPヘッダを搬送するパケットのセットです。トラフィッククラスは、フローのセットです。 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:
次の例では、スコーププロパティの使用を示します。 2つのプロビジョニングポリシングアクションを使用して、以下のポリシーを施行することができます。
- Make sure that each HTTP flow will not exceed 64kb/s
- 各HTTPフローは64キロバイト/秒を超えないことを確認します
- Make sure that the aggregate rate of all HTTP flows will not exceed 512Kb/s
- すべてのHTTPフローの集約レートが512KB /秒を超えないことを確認します
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:
どちらのポリシーは（QoSPolicyAdmissionAction由来）同じクラスQoSPolicyPoliceActionを使用してモデル化されています。第二のポリシーが「クラス」に設定し、その範囲の特性を有しながら、最初のポリシーは、「フロー」に設定し、その範囲の特性を有しています。 2つのポリシーは、擬似正式な定義では、次のようになり、2人の警察アクションとルールを使用してモデル化されています。
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow Action2=police, Traffic Profile2=512kb/s, Scope2=class
もし（HTTP）アクション1 =警察、交通というプロファイル= 64キロバイト/秒、SCOPE1 =流れアクション2 =警察、交通プロファイル2 = 512キロバイト/秒、Scope2 =クラス
The provisioned policing action QoSPolicyPoliceAction has three associations, QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction.
プロビジョニングされたポリシングアクションQoSPolicyPoliceActionは3つの団体、QoSPolicyConformAction、QoSPolicyExceedActionとQoSPolicyViolateActionを持っています。
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つのアクションは、二つPolicyActionInPolicyRule [PCIM]アソシエーションを使用して、単一のポリシールールの一部であってもよいです。この場合、PolicyRuleのクラスのExecutionStrategyプロパティは、[PCIMe]の両方の個々のフローおよび集約ストリームがポリシングされているように、「すべてを行う」に設定する必要があります。
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".
あるいは、アクション1とアクション2はPolicyActionInPolicyAction集計[PCIMe]を用いCompundPolicyActionインスタンスに集約することができます。この場合は、[PCIMe] CompoundPolicyActionクラスの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レベルトークンバケットトラフィックプロファイルに関連付けられています。計で測定したトラフィックは、計量されたレートは、トラフィックプロファイルによって定義されたレートを下回る場合計量トラフィックが超過バーストサイズノーマルバーストの上方及び下方にある場合、過剰なトラフィックとして、トラフィックの適合、及び速度である場合、トラフィックを違反として分類することができます最大超過バースト上記。
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つのレベルメーターを定義し、より複雑メートルに二レベルメーターを結合するための手段を提供します。この文書では、3レベルのトラフィックプロファイルが定義されています。これは、両方の二レベルメーターの構築を可能にするだけでなく、AF [AF]プロビジョニングアクションを作成するために必要な3つのレベルメータ用の簡単な定義を提供します。
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レベルのトラフィックプロファイルや仲間を使用してポリシングアクション。アクションを超えて指定するが、違反アクションを指定していない3レベルのトラフィックプロファイルとポリシングアクションは、トラフィックが最大超過バーストを超えるときに実行するアクションは、トラフィックが通常のバーストを超えている場合に実行するアクションと同じであることを意味します。ポリサーは、実行されるアクションはアソシエーション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 class. The only required association is a traffic profile that specifies the rate and burst parameters that the outgoing flows should conform with.
シェイパーは、トラフィックプロファイルに準拠さストリームをもたらすために、トラフィックストリーム内のパケットの一部または全部を遅延させるために使用されています。シェーパは、通常、有限サイズのバッファを有しており、遅延パケットを保持するのに十分なバッファスペースがない場合、パケットは廃棄されてもよいです。シェーピングはQoSPolicyShapeActionクラスによって制御されています。唯一必要な関連付けは、発信フローがで従うべき速度とバーストパラメータを指定するトラフィックプロファイルです。
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でモデル化されている：差別化サービスコードポイント（DSCP）割り当て、IP優先順位（IPP）の割り当てとサービスのレイヤ2クラス（CoS）の割り当て。これらの割り当てアクション自体は、適切な変数と値に関連付けられている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.
特定のDS行動集合にマークされたパケットを追加DSCP割り当てセット（「マーク」または「色」）は、特定のDSコードポイント（DSCP）へのパケットヘッダの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.
ポリシングアクションと組み合わせて使用される場合、異なる割当動作は、「適合」のそれぞれを介して発行することができ、「上回る」とアクションの関連付けを「違反」。このように、一つメートルの状態に応じて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の割り当てのセマンティクスは、DSCP変数と適切な関連付けを介して単一SimplePolicyActionインスタンス内の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の値（0〜7）へのパケットヘッダのIPPフィールドを設定します。 IPPの割り当てのセマンティクスは、適切な関連付けを介して単一SimplePolicyActionインスタンス内のToS変数（PolicyIPTosVariable）のペアと（[PCIMe]で定義された）ビット列の値（）内にカプセル化されています。ビット列の値は、そのマスクされたビット列の形式で使用されています。ビット列が設定されるIPPの値を示しているマスクは、ToSバイト内IPPサブフィールドの関連する3ビットを示します。
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の割り当ては、サービスのレイヤ2クラスにホップ単位動作のマッピングを制御します。例えば、の802.1pユーザプライオリティ値にDSCP値のセットのマッピングは、DSCP値のセット、及び所与のユーザ優先度値に必要なマッピングを指定したCoS割当動作を説明する条件付きルールを使用して指定することができます。 CoSの割り当てのセマンティクスは、適切な関連付けを介して単一SimplePolicyActionインスタンス内のCoS変数のペアリングおよびCoS値（0〜7の範囲の整数）に封入されています。
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ドメイン内に施行されたと仮定すると、ネットワークの境界上のポリシールールは、所定の3パラメータトラフィックプロファイルへのトラフィックの適合性に応じて、AF1xのDSCPのいずれかにパケットをマークする必要があります。 QPIMモデル図4に定義されたようなAF1ポリシングアクション。
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +--------------------+ +--------------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
* @ +--------------------+ +--------------------------+
* @
* +--------------------+ +---------------------------+
* | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
* +--------------------+ +---------------------------+
*
+--------------------+ +---------------------------+
| SimplePolicyAction |---| PolicyIntegerValue - AF11 |
+--------------------+ +---------------------------+
Association and Aggregation Legend:
協会および集約凡例：
**** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
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集約を使用して行われます。適切なDSCPとの適切なSimplePolicyActionsを接続する3件のPolicyVariableInSimplePolicyAction集計
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は検出トラフィックを準拠にマークされています。 AF12は、交通違反の検出に超過トラフィック、およびAF13の検出にマークされています。
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 |
+-------------------------+
Association and Aggregation Legend: **** QoSPolicyConformAction (not used) @@@@ QoSPolicyExceedAction #### QoSPolicyViolateAction (not used) ==== QoSTrfcProfInAdmissionAction
協会と集計凡例：**** QoSPolicyConformAction（未使用）（未使用）@@@@ QoSPolicyExceedAction #### QoSPolicyViolateAction ==== QoSTrfcProfInAdmissionAction
Figure 5. A Simple Policing Action
図5.シンプルポリシングアクション
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.
ホップ単位動作（PHB）は、特定のDSの動作集約[DIFFSERV]に適用DSノードの外部から観察可能な転送動作について説明します。ここで採用したアプローチは、PHBアクションが観察転送動作（例えば、損失、遅延、ジッタ）ならびにこの動作を実現するために挙動集合体の各々に割り当てられる必要があるバッファと帯域幅リソースを指定の両方を指定していることです。これは、PHBのアクションのセットを持つルールがEFパケットが各ホップで20以上のミリ秒を遅らせてはならないことを指定することができ、あります。同じルールはまた、EFパケットが（プライオリティキューイングと、例えば、）プリエンプティブ転送で処理する必要があることを指定し、このクラスの最大帯域幅、ならびに最大バッファ・リソースを指定することができます。 PHBアクションは、したがってのPHBから最終的な要件を表すためとキュー、スケジューラ、ドロッパ及び他のメカニズムを設定するための設定パラメータのセットにPHBアクションをマッピングすることができるように十分な詳細を提供するための両方に使用することができます。
The QoSPolicyPHBAction abstract class has two subclasses. The QoSPolicyBandwidthAction class is used to control bandwidth, delay and forwarding behavior, while the QoSPolicyCongestionControlAction 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抽象クラスは、2つのサブクラスがあります。 QoSPolicyCongestionControlActionクラスはキューサイズ、閾値及び輻輳アルゴリズムを制御するために使用されている間QoSPolicyBandwidthActionクラスは、帯域幅、遅延及び転送動作を制御するために使用されます。 QoSPolicyPHBActionクラスのqpMaxPacketSizeプロパティは、バイト単位でパケットサイズを指定し、実際の実装構成に帯域幅と輻輳制御動作を翻訳する際に必要とされます。例えば、バイト単位で実装測定キューの長さがバイト単位で所望のキューの長さにqpQueueSizeプロパティをマッピングするために、このプロパティを使用する必要があります。
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は、トラフィックのクラスに割り当てられるべきで最大帯域幅を指定します。このプロパティは、他のPHBの飢餓を防ぐために、非ゼロの転送優先度の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が設定された帯域幅のアクションを強制する方法は、ルールのフィルタで指定されたトラフィックのクラスにフローごとのキューを構築することです。このように、端末アクセスのような対話型のフローは（FTPなど）バースト的な流れの後ろにキューイングされ、したがって、合理的な応答時間を持つことはありません。
The QoSPolicyCongestionControlAction class controls queue length, thresholds and congestion control algorithms.
QoSPolicyCongestionControlActionクラスコントロールは、長さ、しきい値と輻輳制御アルゴリズムをキューに入れます。
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プロパティを使用して、同様に指定することができます。
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ポリシー情報モデルの主要なツールです。 [PCIMe]で導入されたルールのネストがPHBグループの違いのRSVP要求、階層型シェーピング、ポリシングおよびマーキングアクションだけでなく、階層的なスケジューラと定義を制御する階層型ポリシーを指定できます。
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:
この例では、差別化されたサービスのドメイン内の強制のPHBを指定するルールのセットを提供します。ネットワーク管理者は、EF、AF11とAF13とベストエフォートのPHBを施行することにしました。簡単にするために、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.
（AF1は）その後、AF1のアクションを行う場合（AF11）を次にAF11アクションを行う場合（AF12）を次にAF12のアクションを行うとした場合（AF13）は、その後（デフォルト）AF13アクションを行う場合（EF）は、その後EFアクションを行うと、その後のアクションをデフォルト行います。
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グループと一致します。デフォルトのルールは、ベストエフォートルールを指定します。 AF1ルール内AF1xルールのネストがAF1xトラフィックが全体AF1 PHBグループに対する扱われるべきである方法に関するさらなる改良があることを指定します。ルールのセットは、「FirstMatching」に設定意思決定戦略プロパティでのPolicyGroup内に存在します。
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.
クラスのインスタンスは、以下のPHBのそれぞれを記述するために使用される一連のアクションを指定します。キューのサイズが指定されていませんが、簡単に例を追加することができます。
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.
ベストエフォートPHBを記述するために使用されるアクションは簡単です。いいえ帯域幅は、ベストエフォートトラフィックに割り当てられていません。最初のアクションは、ベストエフォートトラフィッククラスは、公平性を持っている必要があることを指定します。
QoSPolicyBandwidthAction BE-B: qpFairness: TRUE
BE-B QoSPolicyBandwidthAction：qpFairness：TRUE
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番目のアクションは、ベストエフォートトラフィッククラスの輻輳アルゴリズムがランダムであることを指定し、デフォルトのキューサイズの割合でしきい値を指定します。
QoSPolicyCongestionControlAction BE-C: qpDropMethod: random qpDropThresholdUnits % qpDropMinThreshold: 10% qpDropMaxThreshold: 70%
-C BE QoSPolicyCongestionControlAction：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
Khvaspholisaibandvidtaksan F-B：kppharvardingpriyariti：1 kpbandvidtunits：％50％khpropheyirnes khpmaksabandviddh：フォールズ
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のPHBのための差別化洗練を指定します。異なる閾値は、AF1 PHBグループ内AF1xのPHBの廃棄確率の差を提供します。
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個のパケット
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.
メータは、フローまたはトラフィックプロファイルに対するフローのセットの時間的状態を測定します。この文書では、トラフィックプロファイルはQoSPolicyTrfcProfクラスによってモデル化されています。関連QoSPolicyTrfcProf InAdmissionActionは、それを使って入場アクションにトラフィックプロファイルをバインドします。 2つのトラフィックプロファイルは、抽象クラスQoSPolicyTrfcProfから派生しています。最初は速度とバーストパラメータを搬送するトラフィックプロファイルをプロビジョニングトークンバケットです。第二は、RSVP TSPECとFLOWSPECパラメータと比較される流れを可能RSVPトラフィックプロファイルです。
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:
シェーピングとポリシングを含むプロビジョニング入場アクションは、2次元または3パラメータトークンバケットトラフィックプロファイルを使用して指定されています。 QoSPolicyTokenBucketTrfcProfクラスには、次のプロパティが含まれています。
1. Rate measured in kbits/sec 2. Normal burst measured in bytes 3. Excess burst measured in bytes
キロビット/秒で測定1.レート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.
レートは長期的な平均伝送速度を決定します。このレートに該当するトラフィックは限り通常のバーストはいつでも超えないよう、適合しています。それでも超過バースト下記の通常のバーストを超えるトラフィックは、トラフィックプロファイルを超えています。超過バーストを超えたトラフィックはトラフィックプロファイルに違反していると言われています。
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.
超過バーストサイズ、バーストサイズに加えて、バイト単位で測定されます。ゼロ超過バーストサイズは、余分なバーストが許可されていないことを示しています。
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要求に一致または関連QoSPolicyRSVPAdmissionActionにqpAdmissionScopeプロパティによって決定されるように、全てのフロースペック（のTSpec）現在入院の集合和を照合することによって基づくことができます。
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
バイト前記最大パケットサイズで測定されたビット/秒3.バケットサイズで測定されたビット/秒2ピークレート（P）で測定1.トークンレート（R）（B）バイト4.最小ポリシング単位（M）で測定（M）ビット/秒でマイクロ秒で測定された7スラックの用語（類）を測定バイト6のResvレート（R）で測定
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つのパラメータは、統合サービスアーキテクチャ（[のIntServ]）に使用されるトラフィック仕様パラメータです。これらのパラメータは、送信者TSPECならびに制御負荷サービスのFLOWSPEC [CL]を定義するために使用されます。定義とその意味の完全な説明については、[RSVP-IS]を参照してください。
Parameters 6 and 7 are the additional parameters used for specification of the Guaranteed Service FLOWSPEC [GS].
パラメータ6および図7は、保証されたサービス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.
半順序は、のTSpec（及びフロースペック）との間に画定されます。 TSPEC AはTSPEC B場合に限りのrA> rBのペンシルバニア州>たpB、BA> BB、ミリアンペア<ヘクトパスカルとMA> MBよりも大きくなっています。トラフィックプロファイルに対して測定TSPEC（FLOWSPECは）同じ順序付け規則を使用しています。 RSVPメッセージは、そのTSPEC（FLOWSPEC）はトラフィックプロファイルのいずれかが以下である場合にのみ受け入れられます。トラフィックプロファイルに指定されたパラメータのみが比較されます。
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と比較されます。 FLOWSPECスラック用語はスラック用語に指定されたよりも小さくてはならないしながら長期Rは、トラフィックプロファイルRパラメータよりも大きくすべきではありません。
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'.
TSpecだけでなく、フロースペックを追加することができます。 2つのTSpecの和が加算されるレートr、ピークレートP、バケットサイズBを加算することにより、最小ポリシングユニットMの最小値と最大パケットサイズM. GSフロースペックの最大値をとることによって計算されます。 Resv率を追加し、たるみ項Sを最小化することもできます。これらのルールは、ルールの条件によって定義されたトラフィッククラスと一致認めRSVP状態の時間的な状態を計算するために使用されます。この状態は、QoSPolicyRSVPAdmissionActionの範囲は、「クラス」に設定されるアドミッション決定に到達するトラフィックプロファイルと比較されます。
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用語のセットをサポートするために、事前に定義された変数クラスのセットを指定します。これらの例としては、RSVP関連の変数を含みます。この文書で定義されたすべての変数のクラスは、それ自体が[PCIMe]で定義され、PolicyImplictVariableクラスを拡張する（本書で定義された）QoSPolicyRSVPVariableクラスを拡張します。サブクラスは、政策変数のデータ型とセマンティクスを指定します。
This document defines the following RSVP variable classes; for details, see their class definitions:
このドキュメントでは、次のRSVP変数のクラスを定義します。詳細については、そのクラス定義を参照してください。
RSVP related Variables:
RSVP関連の変数：
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの送信元IPv4アドレスは、流れを合図しました。
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 PATH及びRESV SESSION [RSVP]オブジェクト（IPv4トラフィック用）で定義されているRSVPの宛先ポートは、流れを合図しました。
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトに反抗としてRSVPの送信元IPv6アドレスは、流れを合図しました。
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 PATH及びRESV SESSION [RSVP]オブジェクト（IPv6トラフィック用）で定義されているRSVPの宛先ポートは、流れを合図しました。
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるように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 PATH及びRESV SESSION [RSVP]オブジェクトで定義されるように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 PATH及びRESV SESSION [RSVP]オブジェクトで定義されるようにRSVPのIPプロトコルは、フローを合図しました。
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 PATH及びRESV SESSION [RSVP]オブジェクトで定義されるようにRSVPを運ぶIPアドレスのバージョンでは、流れを合図しました。
9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the RSVP DCLASS [DCLASS] object.
9. QoSPolicyRSVPDCLASSVariable - DSCP値RSVP DCLASS [DCLASS]オブジェクトで定義されています。
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オブジェクト[RSVP]で定義されるように、RSVP予約メッセージで要求された統合サービス（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 - アイデンティティポリシーオブジェクト[RFC3182]でユーザロケータ文字列で定義されるように流れを開始したユーザーの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 - アプリケーションポリシーオブジェクト[RFC2872]におけるアプリケーションロケータ文字列で定義されるようにフローを生成したアプリケーションのID。
17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type used in the Identity Policy Object [RFC3182].
17. QoSPolicyRSVPAuthMethodVariable - アイデンティティポリシーオブジェクトで使用されるRSVP認証タイプ[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です。
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.
[PCIMe] [PCIM]に記載されたような値は、ポリシーの条件とポリシー・アクションのためのビルディングブロックとして情報モデルで使用されています。このセクションでは、QoSポリシー、ならびに他のポリシー・ドメインに使用される補助値のセットを定義します。
All value classes extend the PolicyValue class [PCIMe]. The subclasses specify specific data/value types that are not defined in [PCIMe].
すべての値クラスは、[PCIMe] PolicyValueクラスを拡張します。サブクラスは[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このクラスは、単一またはワイルドカードを含む識別名[DNDEF]値のセットを表すために使用されます。識別名は、ディレクトリサービスからオブジェクトを取得するためのキーとして使用できる名前です。 [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条件という用語は、フォーム「可変値に一致」を使用し、アクション用語は、（[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 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".
プロパティ名は、条件またはアクション用語で使用されているQoSPolicyAttributeValueクラスのインスタンスのプロパティのかを指定するために使用されます。このプロパティまたはプロパティの値が取得されます。条件の場合には、（プロパティ名に依存して）一致条件が満たされたかどうかを確認するために使用されます。アクションの場合、セマンティクスは「この値に変数を設定する」代わりにしています。
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ユーザ運ばポリシーオブジェクトによってフローを識別するように構成することができます。簡単な条件：姓は=「スミス」ビルという名前のユーザを識別するためには、以下のように構築することになります。
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]を介して単純な条件オブジェクトに集約されることになります。 QoSPolicyAttributeValueはqpAttributeNameは「姓」に設定されますと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.
別の例は、ユーザーの組織部門と関係している状態です。これは、「部門」とqpAttributeValueListが（例えば、「工学」や「顧客サポート」）に一致する特定の値に設定されるだろうしqpAttributeName属性QoSPolicyAttributeValueを変更することで、正確に同じ方法で構築することができます。ユーザーは、エンジニアリング部門や顧客サポートのいずれかに属している場合、論理条件がよりtrueと評価されるだろう。
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クラスを使用する必要があることに注意してください。
The following sections define associations that are specified by QPIM.
次のセクションでは、QPIMによって指定されている関連付けを定義します。
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:
この関連付けは、（セクション8.2で定義された）QoSPolicyAdmissionActionオブジェクトに、特定のトラフィックプロファイルをモデル化する、（セクション8.9で定義された）QoSPolicyTrfcProfオブジェクトをリンクします。次のようにこの関連付けのためのクラス定義は以下のとおりです。
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]]
QoSPolicyTrfcProfInAdmissionAction説明をQoS受付アクションと、そのトラフィックプロファイルとの関連付けを表すクラスに名前を付けます。依存（参照[PCIM]）要旨FALSE PROPERTIES前例から、派生依存[QoSPolicyAdmissionAction [0..N]参考文献] [REF QoSPolicyTrfcProf [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]で定義され、依存関係の関連付けから継承されています。その型はQoSPolicyAdmissionActionオブジェクトへのオブジェクト参照になるように上書きされます。これは協会の「独立」の部分を表しています。 [0..N]基数は、QoSPolicyAdmissionActionオブジェクト（複数可）の任意の数が所定QoSPolicyTrfcProfを使用することができることを示しています。
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.
このプロパティは、依存関係の関連付けから継承され、そしてQoSPolicyTrfcProfオブジェクトへのオブジェクト参照になるように上書きされます。これはQoSPolicyAdmissionActionオブジェクトの任意の数で使用されている特定のトラフィックプロファイルを表します。 [1..1]基数は、QoSPolicyTrfcProfの正確に1つの目的は、所与QoSPolicyAddmissionActionで使用することができることを意味します。
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:
この関連付けは、関連するトラフィックプロファイルにトラフィックに対して適合に適用されるアクションを定義するオブジェクトにポリシングアクションをリンクします。次のようにこの関連付けのためのクラス定義は以下のとおりです。
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 DESCRIPTIONポリシングアクションと関連付けられたトラフィック・プロファイルに適合するトラフィックに適用されるべきアクションとの間の関連付けを表すクラス。依存（参照[PCIM]）要旨FALSE PROPERTIES前例から、派生[REF QoSPolicyPoliceAction [0..N]従属[REF PolicyAction [1..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.
このプロパティは、依存関係協会から継承されます。その型はQoSPolicyPoliceActionオブジェクトへのオブジェクト参照になるように上書きされます。これは協会の「独立」の部分を表しています。 [0..N]基数は、QoSPolicyPoliceActionオブジェクトの任意の数の適合アクションとして実行される同様の作用を与えることができることを示しています。
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.
このプロパティは、依存アソシエーションから継承され、そしてPolicyActionオブジェクトへのオブジェクト参照になるように上書きされます。これは、与えられたQoSPolicyPoliceActionで使用される特定のポリシーアクションを表します。 [1..1]基数は、1つのポリシー・アクションがQoSPolicyPoliceActionための「適合」アクションとして使用することができることを意味します。複数の準拠アクションを実行するには、準拠した行動をモデル化するためにPolicyCompoundActionクラスを使用します。
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]]
ポリシングアクションと関連付けられたトラフィックプロファイルを超えるトラフィックに適用されるべきアクションとの間の関連付けを表す名前QoSPolicyExceedAction説明Aクラス。依存（参照[PCIM]）要旨FALSE PROPERTIES前例から、派生[REF QoSPolicePoliceAction [0..N]従属[REF PolicyAction [1..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.
このプロパティは、依存関係協会から継承されます。その型はQoSPolicyPoliceActionオブジェクトへのオブジェクト参照になるように上書きされます。これは協会の「独立」の部分を表しています。 [0..N]基数は、QoSPolicyPoliceActionオブジェクトの任意の数が超過アクションとして実行される同様の作用を与えることができることを示しています。
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.
このプロパティは、依存アソシエーションから継承され、そしてPolicyActionオブジェクトへのオブジェクト参照になるように上書きされます。これは、与えられたQoSPolicyPoliceActionで使用される特定のポリシーアクションを表します。 [1..1]基数は、1つのポリシー・アクションがQoSPolicyPoliceActionによって「超過」アクションとして使用することができることを意味します。複数の準拠アクションを実行するには、超えた行動をモデル化するためにPolicyCompoundActionクラスを使用します。
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 DESCRIPTIONポリシングアクションと関連付けられたトラフィックプロファイルに違反するトラフィックに適用されるべきアクションとの間の関連付けを表すクラス。依存（参照[PCIM]）要旨FALSE PROPERTIES前例から、派生[REF QoSPolicePoliceAction [0..N]従属[REF PolicyAction [1..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.
このプロパティは、依存関係協会から継承されます。その型はQoSPolicyPoliceActionオブジェクトへのオブジェクト参照になるように上書きされます。これは協会の「独立」の部分を表しています。 [0..N]基数は、QoSPolicyPoliceActionオブジェクトの任意の数の違反アクションとして実行される同様の作用を与えることができることを示しています。
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.
このプロパティは、依存アソシエーションから継承され、そしてPolicyActionオブジェクトへのオブジェクト参照になるように上書きされます。これは、与えられたQoSPolicyPoliceActionで使用される特定のポリシーアクションを表します。 [1..1]基数は、1つのポリシーアクションがQoSPolicyPoliceActionによる「違反」アクションとして使用することができることを意味します。複数の違反アクションを実行するには、適合する行動をモデル化するためにPolicyCompoundActionクラスを使用します。
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.
単純な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] ]
NAME QoSPolicyRSVPVariableInRSVPSimplePolicyActionはPolicyVariableInSimplePolicyAction ABSTRACT FALSE施設から派生GroupComponent PartComponent [QoSPolicyRSVPSimpleAction [0..N]参考文献] [QoSPolicyRSVPVariable [1..1]参考文献]
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から継承し、かつ正確に一つQoSPolicyRSVPVariableが含まれていQoSPolicyRSVPSimpleActionへのオブジェクト参照になるように上書きされます。集約クラスQoSPolicyRSVPVariableInRSVPSimplePolicyActionの任意の単一のインスタンスに対して、このプロパティは単一値であることに留意されたいです。 [0..N]基数は、任意の所与のRSVPオブジェクト変数を含む0,1、又はそれ以上のQoSPolicyRSVPSimpleActionオブジェクトが存在する可能性があることを示しています。
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の任意の単一のインスタンスに対して、（すべての参照プロパティのような）このプロパティは単一値であることに留意されたいです。ザ・
[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は有意義であるために、その範囲内に定義された正確に一つのRSVP変数を有していなければならないことを示しています。
The following sections define object classes that are specified by QPIM.
次のセクションでは、QPIMによって指定されたオブジェクトのクラスを定義します。
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説明このアクションは、パケットが破棄されることを指定します。 PolicyAction（[PCIM]で定義される）に由来しないABSTRACT FALSEFALSE PROPERTIESなし
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:
このクラスは、フローまたはトラフィックプロファイルを持つフローのセットの時間的挙動を測定器の比較に基づいて入学決定を実行するための基本クラスです。 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説明このアクションは、トラフィックプロファイルメートルの比較に基づいて入学決定を制御します。 PolicyActionから派生してABSTRACT FALSEFALSE PROPERTIES qpAdmissionScope（[PCIM]で定義されます）
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:
この属性は、入場料の決定は、フローごとまたはルール条件によって定義されたフローの全体クラスごとに行われているかどうかを指定します。範囲は、「フロー」である場合、各流れの実際のまたは要求されたレートは、トラフィックプロファイルと比較されます。範囲は、「クラス」に設定されている場合は、ルール条件に一致するすべてのフローの集約実際の、または要求されたレートは、トラフィックプロファイルに対して測定されます。次のようにプロパティが定義されています。
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.
このプロパティは、入場料の決定は、フローごとまたは流れの全体のクラスごとに行われているかどうかを指定qpAdmissionScope説明に名前を付けます。 SYNTAX整数VALUEこれは、列挙された整数です。 0の値は入院がフロー単位で行われ、1の値は入院がクラス単位で行われることを指定することを指定します。
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:
これは、ポリシングアクションを定義するために使用される（すなわち、トラフィックプロファイルとの比較に基づいてトラフィックを制限するこれらのアクション）。 3つの団体QoSPolicyConformAction、QoSPolicyExceedActionとQoSPolicyViolateActionを使用して、トラフィックは、適合、超過、またはトラフィックプロファイルに違反しているかどうかに基づいて取るために異なるアクションを指定することが可能です。トラフィックプロファイルは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説明このアクションは、ポリサーの動作を制御します。フローのレートは、トラフィックプロファイルに対して測定されます。 、適合、超過および違反トラフィックに対して実行する必要のあるアクションは、準拠超えると違反行為の関連付けを使用して示されています。 QoSPolicyAdmissionAction（このドキュメントで定義された）ABSTRACT FALSEFALSE PROPERTIESなしから、派生
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説明このアクションは、トラフィックはトラフィックプロファイルに準拠するように成形されるべきであることを示しています。 QoSPolicyAdmissionAction（このドキュメントで定義された）ABSTRACT FALSEFALSE PROPERTIESなしから、派生
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プロパティを継承します。このプロパティは、入場料は、フロー単位またはクラス単位で行われるべきであるかどうかを指定します。トラフィックプロファイルがより大きくまたは要求された予約に等しくない場合、または入院予約の合計に要求された予約と合併し、結果は拒否決定です。トラフィックプロファイルが指定されていない場合、仮定はすべてのトラフィックが入院することができるということです。
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説明このアクションは、RSVP要求の入場を制御します。スコープに応じて、単一のRSVP要求または条件に合致総入院RSVP要求のいずれかがトラフィックプロファイルと比較されます。 （この文書で定義された）QoSPolicyAdmissionAction ABSTRACT FALSEFALSE PROPERTIES qpRSVPWarnOnly、qpRSVPMaxSessionsから、派生
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要求を満たすことはポリサー（トラフィックプロファイル）制限時または最大数のセッションを超えて（あるいはその両方）されるに違反する場合にも適用可能です。
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:
具体的には、（Pathメッセージに応答して）のPathErr又は（RESVメッセージの応答で）RESVERRが送信されます。これは、RSVP用COPSはFlagsオブジェクト意思決定にエラーフラグを送信従います。このプロパティーは、次のように定義されています。
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ブールデフォルトFALSE値はtrue値は、要求が認められるべきで、RSVPの警告メッセージが発信者に送信されなければならないことを意味します。 FALSEの値は、要求が認められないし、適切なエラーメッセージが要求の発信元に返送されなければならないことを意味します。
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整数値は0より大きくなければなりません。
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:
このクラスは、行動集合体に割り当てられるホップごとの振舞いを定義するために使用される基本クラスです。それは、そのサブクラス（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説明このアクションは、行動集合体に提供パーホップ-動作を制御します。 PolicyActionから派生してABSTRACT TRUE PROPERTIES qpMaxPacketSize（[PCIM]で定義されます）
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:
このプロパティは、指定されたフロー内のパケットのバイト単位の最大パケットサイズを指定します。この属性はQPIMの翻訳に使用されているPEP内で使用されるQoSメカニズムに属性。 PEPに維持されるべきパケットの最小数はパケットの数にQPIM内で定義されている間、例えば、キュー長は、バイト単位で測定することができます。このプロパティーは、次のように定義されています。
NAME qpMaxPacketSize SYNTAX Integer Value Must be greater than 0
NAME qpMaxPacketSize SYNTAX整数値は0より大きくなければなりません
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説明このアクションは、PHBの帯域幅、遅延、および転送特性を制御します。 QoSPolicyPBHActionから、派生（本書で定義）ABSTRACT FALSE PROPERTIES qpForwardingPriority、qpBandwidthUnits、qpMinBandwdith、qpMaxBandwidth、qpMaxDelay、qpMaxJitter、qpFairness
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値は非負でなければなりません。値0は、先制転送が必要とされていないことを意味します。正の値は流れ（S）この（のセット）のために割り当てられる優先度を示します。値が大きいほど、高い優先順位を表します。
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整数値は、2つの値が可能です。 1の値は、利用可能な帯域幅のパーセンテージとして単位を指定するために使用される0の値は、ビット/秒の単位を指定するために使用されます。このプロパティは、帯域幅の単位は％であることを示す場合、その後、帯域幅特性の各々は、全体数の割合を表し、従って、その最大値は100です。
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整数値は、プロパティqpMaxBandwidthが定義されている場合、次いでqpMinBandwidthの値がqpMaxBandwidthの値以下でなければならない0より大きいしなければなりません。
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整数値は、プロパティqpMaxBandwidthが定義されている場合、次いでqpMinBandwidthの値がqpMaxBandwidthの値以下でなければならない0より大きいしなければなりません。
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:
このプロパティは、このクラスのトラフィックはこのホップを介して転送されながら経験する必要があることを最大のホップ単位の遅延を定義します。最大遅延はマイクロ秒で測定されます。このプロパティーは、次のように定義されています。
NAME qpMaxDelay SYNTAX Integer (microseconds) VALUE The value must be greater than 0.
qpMaxDelay SYNTAX INTEGER（マイクロ秒）の値が0よりも大きくなければならない値の名前。
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:
このプロパティは、このクラスのトラフィックはこのホップを介して転送されながら経験する必要があることを最大のホップごとの遅延変動を定義します。最大ジッタをマイクロ秒で測定されます。このプロパティーは、次のように定義されています。
NAME qpMaxJitter SYNTAX Integer (microseconds) VALUE The value must be greater than 0.
qpMaxJitter SYNTAX INTEGER（マイクロ秒）の値が0よりも大きくなければならない値の名前。
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ブール値はfalseの値がTRUEの値は公平キューイングは、トラフィックのこのクラスのために必要とされることを意味している間公平キューイングは、トラフィックのこのクラスのために必要とされていないことを意味します。
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
NAME QoSPolicyCongestionControlAction説明PHBのこの動作制御、輻輳制御特性。 QoSPolicyPBHAction（本書で定義された）ABSTRACT FALSE PROPERTIESのqpQueueSizeUnits、qpQueueSize、qpDropMethod、qpDropThresholdUnits、qpDropMinThresholdValue、qpDropMaxThresholdValueから、派生
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値このプロパティは、2つの値を持つことができます。値が0に設定されている場合、測定の単位はパケットの数です。値が1に設定されている場合、測定値の単位はミリ秒です。
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.
この値は0より大きくなければなりませんqpQueueSize SYNTAX INTEGER値に名前を付けます。
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は、3つの値が現在定義されている値。値0は、値1は、テールドロップ・アルゴリズムを指定し、値2は、ヘッドドロップアルゴリズムを指定し、ランダムドロップ・アルゴリズムを指定します。
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:
このプロパティは、二つのプロパティ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は、3つの値が定義されている値。パケットの数は、値1がキューサイズのパーセンテージとして単位を定義し、値2は、ミリ秒単位での単位を定義するように値0は単位を定義します。このプロパティは、閾値ユニットは、パーセントであることを示す場合、閾値特性の各々は、全体数の割合を表し、従って、その最大値は100です。
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 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:
このプロパティは、フローのこのクラスのために確保されなければならないキューイングおよびバッファリソースの最小数を指定します。閾値はqpDropThresholdUnitsプロパティの値に応じて（すなわち、パーセンテージ）相対的または絶対的（すなわち、パケットまたはミリ秒数）値のいずれかとして指定することができます。このプロパティは、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整数値は、この値は、プロパティqpDropMaxThresholdValueが定義されている場合、次いでqpDropMinThresholdValueプロパティの値が以下qpDropMaxThresholdValueプロパティの値に等しくなければならない0以上でなければなりません。
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プロパティの値に応じて（すなわち、パーセンテージ）相対的または絶対的（すなわち、パケットまたはミリ秒数）値のいずれかとして指定することができます。輻輳制御ドロッパーは、このプロパティで指定した値よりも多くのパケットを維持するべきではありません。いくつかのドロッパがキュー占有率平均値を計算することができるので、実際の最大キューリソースは大きくなければならないこと、しかし、注意してください。このプロパティーは、次のように定義されています。
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整数値は、この値は、プロパティqpDropMinThresholdValueが定義されている場合、次いでqpDropMinThresholdValueプロパティの値が以下qpDropMaxThresholdValueプロパティの値に等しくなければならない0以上でなければなりません。
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
（[PCIM]で定義された）ポリシーから派生名称QoSPolicyTrfcProf ABSTRACT TRUE PROPERTIESなし
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レベルのトークンバケットトラフィックプロファイル。追加のプロファイル（例えば、別のインスタンスの入力、1つのインスタンスの出力を接続することによって）このクラスの複数のインスタンスをカスケード接続することによってモデル化することができます。このトラフィックプロファイルは、フローまたはフローの集合に適用されるポリサーまたはシェーパーレート値を運びます。次のようにクラス定義は次のとおりです。
NAME QoSPolicyTokenBucketTrfcProf DERIVED FROM QoSPolicyTrfcProf (defined in this document) ABSTRACT FALSE PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst
NAME QoSPolicyTokenBucketTrfcProfはQoSPolicyTrfcProf（本書で定義された）ABSTRACT FALSE PROPERTIES qpTBRate、qpTBNormalBurst、qpTBExcessBurstから、派生します
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:
これは、毎秒キロビットでトークンレートを定義する正の整数です。ゼロのレートは、すべてのパケットが不適合であることを意味します。このプロパティーは、次のように定義されています。
NAME qpTBRate SYNTAX Integer VALUE This value must be greater than to 0
qpTBRate SYNTAX整数値をnameこの値は0より大きくなければなりません
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
qpTBNormalBurst SYNTAX整数値をnameこの値は0より大きくなければなりません
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
この値は以上qpTBNormalBurstに等しくなければならないqpTBExcessBurst SYNTAX整数値の名前
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.
このクラスは、イントサーブのトラフィックプロファイルを表します。イントサーブのトラフィックプロファイルの値は、トラフィック仕様（TSPEC）とRSVPのリクエストで運ばれたQoS予約（FLOWSPEC）の要求と比較されています。
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
QoSPolicyTrfcProf（本書で定義された）ABSTRACT FALSE PROPERTIES qpISTokenRate、qpISPeakRate、qpISBucketSize、qpISResvRate、qpISResvSlack、qpISMinPolicedUnit、qpISMaxPktSizeから、派生名称QoSPolicyIntServTrfcProf
This property is a non-negative integer that defines the token rate parameter, measured in kilobits per second. This property is defined as follows:
このプロパティは、毎秒キロビットで測定されたトークンレートのパラメータを定義する非負の整数です。このプロパティーは、次のように定義されています。
NAME qpISTokenRate SYNTAX Integer VALUE This value must be greater than or equal to 0
qpISTokenRate SYNTAX整数値をnameこの値は0以上でなければなりません
This property is a non-negative integer that defines the peak rate parameter, measured in kilobits per second. This property is defined as follows:
このプロパティは、毎秒キロビットで測定されたピーク速度パラメータを定義する非負の整数です。このプロパティーは、次のように定義されています。
NAME qpISPeakRate SYNTAX Integer VALUE This value must be greater than or equal to 0
qpISPeakRate SYNTAX整数値をnameこの値は0以上でなければなりません
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
qpISBucketSize SYNTAX整数値をnameこの値は0以上でなければなりません
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-仕様）を定義する正の整数です。これは、秒あたりのキロビットで測定されます。このプロパティーは、次のように定義されています。
NAME qpISResvRate SYNTAX Integer VALUE This value must be greater than or equal to 0
qpISResvRate SYNTAX整数値をnameこの値は0以上でなければなりません
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
qpISResvSlack SYNTAX整数値をnameこの値は0以上でなければなりません
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
qpISMinPolicedUnit SYNTAX整数値をnameこの値は0以上でなければなりません
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整数値この値は、RSVPの最大ペイロードパケットのバイト数を表す正の整数でなければならないが流れるまたはクラス合図しました。
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>を置換するために使用されます。
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 =「姓」、qpAttributeValueList = {「スミス」}とQoSPolicyAttributeValueクラスを使用します。
The class definition is as follows:
次のようにクラス定義は次のとおりです。
NAME QoSPolicyAttributeValue DERIVED FROM PolicyValue (defined in [PCIMe]) ABSTRACT FALSE PROPERTIES qpAttributeName, qpAttributeValueList
PolicyValueから、派生NAME QoSPolicyAttributeValueは、抽象FALSE PROPERTIES qpAttributeName、qpAttributeValueList（[PCIMe]で定義されます）
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 SYNTAX文字列NAME
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.
このプロパティは、「<X>マッチ<Y>」単純状態又は形態の簡単なアクションで<Y>を置換するために使用される値のリストを搬送または「<X> = <Y>」は、それぞれ。
This property is defined as follows:
このプロパティーは、次のように定義されています。
NAME qpAttributeValueList SYNTAX String
qpAttributeValueList SYNTAX文字列NAME
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コンディショナーを持つしなければならないすべての暗黙的な変数のための基本クラスとして機能する抽象クラスです。次のようにクラス定義は次のとおりです。
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説明抽象基底クラスはPolicyImplicitVariableから、派生RSVP要求の異なる属性を指定する他のクラスを構築するために使用される（[PCIMe]で定義される）ABSTRACT TRUE PROPERTIESなし
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの送信元IPv4アドレスが含まれている具体的なクラスは、フローシグナリングされます。次のようにクラス定義は次のとおりです。
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.
RSVPパスSENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPSourceIPv4Variable説明は、RSVPの送信元IPv4アドレスは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
許容値の種類：PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの宛先IPv4アドレスが含まれている具体的なクラスは、フローシグナリングされます。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPDestinationIPv4Variable DESCRIPTION The destination IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
RSVPパスとRESV SESSION [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPDestinationIPv4Variable説明は、RSVPの宛先IPv4アドレスは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
許容値の種類：PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの送信元IPv6アドレスが含まれている具体的なクラスは、フローシグナリングされます。次のようにクラス定義は次のとおりです。
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.
RSVPパスSENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPSourceIPv6Variable説明は、RSVPの送信元IPv6アドレスは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
許容値の種類：PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの宛先IPv6アドレスが含まれている具体的なクラスは、フローシグナリングされます。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPDestinationIPv6Variable DESCRIPTION The destination IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
RSVPパスとRESV SESSION [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPDestinationIPv6Variable説明は、RSVPの宛先IPv6アドレスは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
許容値の種類：PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるように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パスSENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPSourcePortVariable説明は、RSVPの送信元ポートは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
許容値の種類：PolicyIntegerValue（0 65535）
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH SENDER_TEMPLATEとRSVP RESV FILTER_SPEC [RSVP]オブジェクトで定義されるようにRSVPの宛先ポートは、流れをシグナリング含ま具象クラスです。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPDestinationPortVariable DESCRIPTION The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
RSVPパスとRESV SESSION [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPDestinationPortVariable説明は、RSVPの宛先ポートは、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
許容値の種類：PolicyIntegerValue（0 65535）
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH及びRESV SESSION [RSVP]オブジェクトで定義されるようにRSVPのIPプロトコル番号は、フローシグナリング含ま具象クラスです。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPIPProtocolVariable DESCRIPTION The IP Protocol number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
RSVPパスとRESV SESSION [RSVP]オブジェクトで定義されるようにNAME QoSPolicyRSVPIPProtocolVariable説明は、RSVPのIPプロトコル番号は、流れを合図しました。
ALLOWED VALUE TYPES: PolicyIntegerValue
許容値の種類：PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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 PATH及びRESV SESSION [RSVP]オブジェクトで定義されるようにRSVPのIPプロトコルバージョン番号は、フローシグナリング含ま具象クラスです。よく知られているバージョン番号は、この変数は4,6であるタイプのポリシー定義を可能にします。
"If IP version = IPv4 then ...".
"その後、IPバージョン= IPv4の場合は..."。
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.
NAME QoSPolicyRSVPIPVersionVariable説明は、IPアドレスのIPバージョン番号は、RSVP PATH及びRESV SESSION [RSVP]オブジェクトで定義されるようにRSVPは、フローを合図行います。
ALLOWED VALUE TYPES: PolciIntegerValue
許容値の種類：PolciIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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.
RSVP DCLASS [DCLASS]オブジェクトで定義されるようQoSPolicyRSVPDCLASSVariable説明をDSCP値に名前を付けます。
ALLOWED VALUE TYPES: PolicyIntegerValue,
PolicyBitStringValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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スタイルオブジェクトで定義された予約スタイルを含有する具象クラスです。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPStyleVariable DESCRIPTION The reservation style as defined in the RSVP STYLE object in the RESV message [RSVP].
RESVメッセージ[RSVP]でRSVPスタイルオブジェクトで定義されQoSPolicyRSVPStyleVariable説明を予約スタイルに名前を付けます。
ALLOWED VALUE TYPES: PolicyBitStringValue,
PolicyIntegerValue (Integer has
an enumeration of
{ Fixed-Filter=1,
Shared-Explicit=2,
Wildcard-Filter=3}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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:
これは、FLOWSPECのRSVPオブジェクト[RSVP]で定義されている統合サービスは、RSVP予約メッセージで要求が含まれ、具体的なクラスです。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPIntServVariable DESCRIPTION The integrated Service requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP].
NAME QoSPolicyRSVPIntServVariable説明FLOWSPECのRSVPオブジェクト[RSVP]で定義されるようにRSVP予約メッセージで要求された統合サービス、。
ALLOWED VALUE TYPES: PolicyIntegerValue (An enumerated
value of { CL=1 , GS=2, NULL=3}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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.
NAME QoSPolicyRSVPMessageTypeVariable説明RSVPメッセージタイプ、RSVPメッセージ共通ヘッダ[RSVP]オブジェクトに定義された通りです。
ALLOWED VALUE TYPES: Integer (An enumerated value of
{PATH=1 , PATHTEAR=2, RESV=3,
RESVTEAR=4, RESVERR=5, CONF=6,
PATHERR=7}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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].
[RFC3181]で定義されるようQoSPolicyRSVPPreemptionPriorityVariable DESCRIPTIONにRSVP予約優先名前を付けます。
ALLOWED VALUE TYPES: PolicyIntegerValue
許容値の種類：PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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:
これは、アイデンティティポリシーオブジェクト[RFC3182]でのユーザーロケータ文字列で定義されたフローを開始したユーザーの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].
NAME QoSPolicyRSVPUserVariable説明Identityポリシーオブジェクト[RFC3182]でユーザロケータ文字列で定義されるように流れを開始したユーザーのID。
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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:
これは、アプリケーションポリシーオブジェクト[RFC2872]におけるアプリケーションロケータ文字列で定義されるように流れを生成したアプリケーションのIDが含まれている具象クラスです。次のようにクラス定義は次のとおりです。
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].
QoSPolicyRSVPApplicationVariable DESCRIPTIONにアプリケーションポリシーオブジェクト[RFC2872]におけるアプリケーションロケータ文字列で定義されるように流れを生成したアプリケーションのIDと名前を付けます。
ALLOWED VALUE TYPES: QoSPolicyDNValue,
PolicyStringValue,
QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
This is a concrete class that contains the type of authentication used in the Identity Policy Object [RFC3182]. The class definition is as follows:
これは、アイデンティティポリシーオブジェクト[RFC3182]で使用する認証の種類が含まれている具体的なクラスです。次のようにクラス定義は次のとおりです。
NAME QoSPolicyRSVPAuthMethodVariable DESCRIPTION The RSVP Authentication type used in the Identity Policy Object [RFC3182].
NAME QoSPolicyRSVPAuthMethodVariable説明Identityポリシーオブジェクト[RFC3182]で使用されるRSVP認証タイプ。
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}
DERIVED FROM QoSPolicyRSVPVariable (defined in this document) ABSTRACT FALSE PROPERTIES None
QoSPolicyRSVPVariable（このドキュメントで定義された）ABSTRACT FALSE PROPERTIESなしから、派生
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:
このクラスは、単一またはワイルドカードを含む識別名[DNDEF]値のセットを表すために使用されます。識別名は、ディレクトリサービスからオブジェクトを取得するためのキーとして使用できる名前です。 [RFC3182]で指定されるように、この値は、RSVPポリシーオブジェクトで運ば値を参照するのに比べて、使用することができます。次のようにクラス定義は次のとおりです。
NAME QoSPolicyDNValue DERIVED FROM PolicyValue ABSTRACT FALSE PROPERTIES qpDNList
PolicyValue ABSTRACT FALSEの施設から派生NAME QoSPolicyDNValue 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:
この属性は、文字列、ワイルドカードと識別名（DN）を表すそれぞれの順不同のリストを提供します。 DNのフォーマットは、[DNDEF]で定義されています。アスタリスク文字（「*」）は、単一の属性値やRDNのためのワイルドカードのいずれかのためのワイルドカードとして使用されています。 RDNの順序は重要です。たとえば、次の値を運ぶ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 =ウィジェット社、C = US"
and also matches:
とにも一致します。
"CN=J. Smith, OU=Sales, O=Widget Inc, L=CA, C=US".
"CN = J。スミス、OU =販売、O =ウィジェット社、L = CA、C = US"。
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.
別のオブジェクトへの参照として役立つそれぞれが文字列として実装識別名のNAME qpDNList SYNTAX一覧。
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プロパティの値に応じて、このアクションは、直接RSVP用COPSで定義されるように決定またはCOPSステートレス決定、あるいはその両方を交換していずれかの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説明このアクションは、RSVPメッセージの内容やRSVP要求が入院されている方法を制御します。 SimplePolicyActionから派生してABSTRACT FALSE PROPERTIES（[PCIMe]で定義される）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が決定アクションを交換して示しています。値「STATELESSは」COPSステートレス決定アクションを示しています。値REPLACEANDSTATELESSは、両方の意思決定行動を示しています。詳細については、[RFC2749]を参照してください。
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説明このプロパティは、アクションの種類がCOPSは、ステートレス、または意思決定の両方のタイプを交換するためにあるかどうかを指定します。 SYNTAX整数VALUEこれは、列挙された整数です。 0の値は、COPSは決定を交換して指定します。 1の値は、COPSステートレス決定を指定します。 2の値は、両方のCOPSを元に戻して、ステートレス決定をCOPS指定します。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。
Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The authors wish to thank the 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.
著者はPCIMeの共著者、リーRafalow、アンドレアWesterinen、Ritu Chadhaとマーカス・ブルナーのポリシーフレームワークワーキンググループの参加者の入力、および特に複合グループに感謝したいです。また、当社はエドEllesson、ジョエル・ハルパーンとミルチャパナからの貴重な貢献を認めるしたいと思います。ご意見、批評、アイデアや一般拠出ありがとうございました。
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.
方針コア情報モデル[PCIM]は、一般的なコアポリシーモデルに関連する一般的なセキュリティの考慮事項について説明します。この文書で定義された拡張は、セキュリティに関連する追加の考慮事項を導入しません。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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つの仕"、RFC 3060、2001年2月。
[PCIMe] Moore, B., Ed., "Policy Core Information Model Extensions", RFC 3460, January 2003.
[PCIMe]ムーア、B.、エド。、 "方針コア情報モデルの拡張"、RFC 3460、2003年1月。
[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.
[用語] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.とM. Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、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.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[イントサーブ]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、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の機能的な仕様"。、RFC 2205、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.、ラジャン、R.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.
[RFC3181]ヘルツォーク、S.、RFC 3181 2001年10月、 "先取り優先権方針要素が通知さ"。
[DIFF-MIB] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[DIFF-MIB]ベイカー、F.、チャン、K.とA.スミス、 "差別化サービスアーキテクチャのための管理情報ベース"、RFC 3289、2002年5月。
[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グループ"、RFC 2597、1999年6月。
[CL] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[CL] Wroclawski、J.、 "制御負荷ネットワーク要素サービスの仕様"、RFC 2211、1997年9月。
[RSVP-IS] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RSVP-IS] Wroclawski、J.、RFC 2210 "IETF統合サービスとRSVPの使用"、1997年9月。
[GS] Shenker, S., Partridge, C. and R. Guerin, "Specification of the Guaranteed Quality of Service", RFC 2212, September 1997.
[GS] Shenker、S.、ヤマウズラ、C.とR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DCLASS] Bernet、Y.、 "RSVP DCLASSオブジェクトのフォーマット"、RFC 2996、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のID表現"、RFC 3182、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で使用するアプリケーションおよびサブアプリケーションIDポリシー要素"、RFC 2872、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文字列表現"、RFC 2253、1997年12月。
Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766
Yoram Rambergシスコシステムズ4 MaskitストリートヘルズリヤPituach、イスラエル46766
Phone: +972-9-970-0081 Fax: +972-9-970-0219 EMail: yramberg@cisco.com
電話：+ 972-9-970-0081ファックス：+ 972-9-970-0219 Eメール：yramberg@cisco.com
Yoram Snir Cisco Systems 300 East Tasman Drive San Jose, CA 95134
Yoram SNIRシスコシステムズ300東タスマン・ドライブサンノゼ、CA 95134
Phone: +1 408-853-4053 Fax: +1 408 526-7864 EMail: ysnir@cisco.com
電話：+1 408-853-4053ファックス：+1 408 526-7864 Eメール：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ファックス：+ 1-719-785-0644 Eメール：john.strassner@intelliden.com
Ron Cohen Ntear LLC
ロン・コーエンNtear LLC
Phone: +972-8-9402586 Fax: +972-9-9717798 EMail: ronc@lyciumnetworks.com
電話：+ 972-8-9402586ファックス：+ 972-9-9717798 Eメール：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.ボックス12195、BRQA / 501 / G206 3039コーンウォリスRdを。リサーチトライアングルパーク、NC 27709-2195
Phone: +1 919-254-4436 Fax: +1 919-254-6243 EMail: remoore@us.ibm.com
電話：+1 919-254-4436ファックス：+1 919-254-6243電子メール：remoore@us.ibm.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。