Network Working Group S. Herzog
Request for Comments: 3181 PolicyConsulting.Com
Obsoletes: 2751 October 2001
Category: Standards Track
Signaled Preemption Priority Policy Element
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS).
この文書では、合図ポリシーベースなリソース予約プロトコルとして入場プロトコル（（RSVP）と共通オープンポリシーサービス（COPS）で使用するために先取り優先ポリシー要素について説明します。
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high-priority flow.
先取り優先順位は、ネットワークに導入される競合フローのセット内の相対的な重要性（ランク）を定義します。むしろ到着順によって流れを認めるよりも（最初最初入所）来るネットワークノードは、いくつかの以前に認め低い優先順位の方が新しい、高優先フローのための余地を作るために流れる先取りする優先度を考慮してもよいです。
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751.
このメモはRFC 2751でRSVP POLICY_DATA P型コードポイントの割り当てエラーを訂正します。
Table of Contents
目次
1 Introduction .....................................................2
2 Scope and Applicability ..........................................3
3 Stateless Policy .................................................3
4 Policy Element Format ............................................4
5 Priority Merging Issues ..........................................5
5.1 Priority Merging Strategies ...................................6
5.1.1 Take priority of highest QoS .................................6
5.1.2 Take highest priority ........................................7
5.1.3 Force error on heterogeneous merge ...........................7
5.2 Modifying Priority Elements ...................................7
6 Error Processing .................................................8
7 IANA Considerations ..............................................8
8 Security Considerations ..........................................8
9 References .......................................................9
10 Author's Address ...............................................9
Appendix A: Example ...............................................10
A.1 Computing Merged Priority ....................................10
A.2 Translation (Compression) of Priority Elements ...............11
Full Copyright Statement ..........................................12
1 Introduction
1はじめに
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]).
この文書は、（[RSVP]と[COPS]など）シグナリングポリシーベースのアドミッションプロトコルによって使用するための先取優先ポリシー要素を記述する。
Traditional Capacity based Admission Control (CAC) indiscriminately admits new flows until capacity is exhausted (First Come First Admitted). Policy based Admission Control (PAC) on the other hand attempts to minimize the significance of order of arrival and use policy based admission criteria instead.
容量は（最初に入所最初に来る）なくなるまでの伝統的な容量ベースのアドミッション制御（CAC）が無差別に新しいフローを認めています。一方、ポリシーベースのアドミッション制御（PAC）は、到着順の重要性を最小限にし、代わりにポリシーベースの入学基準を使用しようとします。
One of the more popular policy criteria is the rank of importance of a flow relative to the others competing for admission into a network node. Preemption Priority takes effect only when a set of flows attempting admission through a node represents overbooking of resources such that based on CAC some would have to be rejected. Preemption priority criteria help the node select the most important flows (highest priority) for admission, while rejecting the low priority ones.
より人気のポリシー基準のうちの1つは、ネットワークのノードへの入学のために競合する他の人への流れの相対的な重要性のランクです。先取り優先権は、ノードを介して入場しようとする流れのセットはCACに基づいて、いくつかが拒否されなければならないことを、このようなリソースのオーバーブッキングを示した場合にのみ有効になります。優先度の低いものを排除しながら先取り優先基準は、ノードが入場のために最も重要なフロー（最優先）を選択できます。
Network nodes which support preemption should consider priorities to preempt some previously admitted low-priority flows in order to make room for a newer, high-priority flow.
プリエンプションをサポートするネットワーク・ノードは、新しい、優先度の高いフローのための部屋を作るためにいくつかの以前に入院優先度の低いフローを先取りするために優先順位を検討すべきです。
This document describes the format and applicability of the preemption priority represented as a policy element in [RSVP-EXT].
この文書では、[RSVP-EXT]のポリシー要素として表さ先取り優先順位の形式と適用性を説明しています。
2 Scope and Applicability
2範囲と適用
The Framework document for policy-based admission control [RAP] describes the various components that participate in policy decision making (i.e., PDP, PEP and LDP). The emphasis of PREEMPTION_PRI elements is to be simple, stateless, and light-weight such that they could be implemented internally within a node's LDP (Local Decision Point).
ポリシーベースのアドミッション制御のためのフレームワークドキュメント[RAP]はポリシーの意思決定（即ち、PDP、PEPおよびLDP）に関与する様々な構成要素を説明しています。 PREEMPTION_PRI要素の重点は、単純なステートレス、それらはノードのLDP（ローカル決定点）の内部で実施することができるように軽量であることです。
Certain base assumptions are made in the usage model for PREEMPTION_PRI elements:
特定の基本仮定はPREEMPTION_PRI要素のための使用モデルに作られています：
- They are created by PDPs
- これらは、プラズマディスプレイパネルによって作成されます
In a model where PDPs control PEPs at the periphery of the policy domain (e.g., in border routers), PDPs reduce sets of relevant policy rules into a single priority criterion. This priority as expressed in the PREEMPTION_PRI element can then be communicated to downstream PEPs of the same policy domain, which have LDPs but no controlling PDP.
（例えば、境界ルータで）ポリシー・ドメインの周辺のPDPの制御のPEPモデルにおいて、PDPは、単一の優先度基準に関連するポリシールールのセットを減らします。 PREEMPTION_PRI要素で表されるこの優先順位は、次にLDPsを有する同一のポリシー・ドメインの下流のPEPが、無制御PDPに伝達することができます。
- They can be processed by LDPs
- 彼らはLDPsによって処理することができます
PREEMPTION_PRI elements are processed by LDPs of nodes that do not have a controlling PDP. LDPs may interpret these objects, forward them as is, or perform local merging to forward an equivalent merged PREEMPTION_PRI policy element. LDPs must follow the merging strategy that was encoded by PDPs in the PREEMPTION_PRI objects. (Clearly, a PDP, being a superset of LDP, may act as an LDP as well).
PREEMPTION_PRI要素を制御するPDPを持たないノードのLDPsによって処理されています。 LDPsは、これらのオブジェクトを解釈しているとして、それらを転送する、または同等のものを転送するために地元のマージを行うことができるPREEMPTION_PRIポリシー要素を統合しました。 LDPsはPREEMPTION_PRIオブジェクト内のPDPでエンコードされた併合戦略に従わなければなりません。 （明らかに、PDPは、LDPのスーパーセットであること、ならびにLDPとして作用することができます）。
- They are enforced by PEPs
- これらはのPEPによって強制されています
PREEMPTION_PRI elements interact with a node's traffic control module (and capacity admission control) to enforce priorities, and preempt previously admitted flows when the need arises.
PREEMPTION_PRI要素は、優先順位を適用し、必要が生じたとき、以前に許可されたフローを先取りするノードのトラフィック制御モジュール（および容量アドミッション制御）と相互作用します。
3 Stateless Policy
3ステートレスポリシー
Signaled Preemption Priority is stateless (does not require past history or external information to be interpreted). Therefore, when carried in COPS messages for the outsourcing of policy decisions, these objects are included as COPS Stateless Policy Data Decision objects (see [COPS, COPS-RSVP]).
合図を先取り優先権は、（解釈されるように、過去の歴史や外部情報を必要としない）ステートレスです。政策決定のアウトソーシングのためのCOPSメッセージで運ばれたときにそのため、これらのオブジェクトはCOPSステートレスポリシーデータ判定オブジェクトとして含まれている（参照[COPS、COPS-RSVP]）。
4 Policy Element Format
4ポリシー要素のフォーマット
The format of Policy Data objects is defined in [RSVP-EXT]. A single Policy Data object may contain one or more policy elements, each representing a different (and perhaps orthogonal) policy.
ポリシーデータオブジェクトのフォーマットは、[RSVP-EXT]で定義されています。単一ポリシーデータオブジェクトは、1つまたは複数のポリシーエレメント、異なる（そしておそらく直交）ポリシーを表すそれぞれを含んでいてもよいです。
The format of preemption priority policy element is as follows:
次のように先取り優先ポリシー要素の形式は次のとおりです。
+-------------+-------------+-------------+-------------+
| Length (12) | P-Type = PREEMPTION_PRI |
+------+------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved(0) |
+------+------+-------------+-------------+-------------+
| Preemption Priority | Defending Priority |
+------+------+-------------+-------------+-------------+
Length: 16 bits Always 12. The overall length of the policy element, in bytes.
長さ：16ビットは、常に12バイトのポリシー要素の全体の長さ、。
P-Type: 16 bits PREEMPTION_PRI = 1
p型：16ビットPREEMPTION_PRI = 1
This value is registered with IANA, see Section 7.
この値は、IANAに登録されている、セクション7を参照してください。
Flags: 8 bits Reserved (always 0).
フラグ：予約8ビット（常に0）。
Merge Strategy: 8 bit 1 Take priority of highest QoS: recommended 2 Take highest priority: aggressive 3 Force Error on heterogeneous merge
最高のQoSの8ビット1テイクの優先順位：戦略をマージ異種マージに積極的な3フォースエラー：2が最も高い優先順位を取るお勧めします
Reserved: 8 bits Error code: 8 bits 0 NO_ERROR Value used for regular PREEMPTION_PRI elements 1 PREEMPTION This previously admitted flow was preempted 2 HETEROGENEOUS This element encountered heterogeneous merge
予約：8ビットエラーコード：これ以前に認め流れは2 HETEROGENEOUSを横取りした正規PREEMPTION_PRI素子1つのプリエンプションに使用される8ビット0 NO_ERROR値この要素は、異種マージに遭遇
Reserved: 8 bits Always 0.
予約：8ビット常に0。
Preemption Priority: 16 bit (unsigned) The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher Priority.
プリエンプションの優先度：16ビット（符号なし）以前に許可されたフローの防御優先順位と比較し、新しいフローの優先順位。より高い値は高い優先度を表します。
Defending Priority: 16 bits (unsigned) Once a flow was admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.
優先防御：流れが認められた後16ビット（符号なし）を、先取り優先順位は無関係となります。代わりに、その防御の優先順位は、新しいフローの先取優先順位を比較するために使用されます。
For any specific flow, its preemption priority must always be less than or equal to the defending priority. A wide gap between preemption and defending priority provides added stability: moderate preemption priority makes it harder for a flow to preempt others, but once it succeeded, the higher defending priority makes it easier for the flow to avoid preemption itself. This provides a mechanism for balancing between order dependency and priority.
任意の特定のフローのために、その先取り優先順位は常に防御優先度以下でなければなりません。プリエンプションと防御優先間の広い隙間が追加安定性を提供する：中程度の先取り優先順位は、他を先取りするためのフローのためにそれが困難になり、それが成功した後、より高い防御優先順位は、それが簡単に流れのためプリエンプション自体を回避することができます。これは、順序依存性や優先順位の間でバランスをとるためのメカニズムを提供します。
5 Priority Merging Issues
5つの重点課題のマージ
Consider the case where two RSVP reservations merge:
2件のRSVP予約が合併する場合を考えてみましょう：
F1: QoS=High, Priority=Low
F2: QoS=Low, Priority=High
F1+F2= F3: QoS=High, Priority=???
F1 + F2 = F3：QoSの=ハイ、優先順位= ???
The merged reservation F3 should have QoS=Hi, but what Priority should it assume? Several negative side-effects have been identified that may affect such a merger:
マージされた予約F3こんにちは= QoSを持っている必要がありますが、それはどのような優先順位を想定する必要がありますか？いくつかの負の副作用には、このような合併に影響を与える可能性が同定されています。
Free-Riders:
フリーライダー：
If F3 assumes Priority=High, then F1 got a free ride, assuming high priority that was only intended to the low QoS F2. If one associates costs as a function of QoS and priority, F1 receives an "expensive" priority without having to "pay" for it.
F3は、優先順位=ハイを前提とした場合、F1が低いだけのQoS F2に意図された高い優先度を想定し、フリーライドを得ました。 1は、QoSと優先度の関数としてのコストを関連付けた場合、F1はそれを「支払う」ことなく、「高価な」優先順位を受け取ります。
Denial of Service:
サービス拒否：
If F3 assumes Priority=Low, the merged flow could be preempted or fail even though F2 presented high priority.
F3は、優先順位=ローを前提とした場合、マージされたフローはF2が高い優先順位を提示していても先取りするか失敗することがあります。
Denial of service is virtually the inverse of the free-rider problem. When flows compete for resources, if one flow receives undeserving high priority it may be able to preempt another deserving flow (hence one free-rider turns out to be another's denial of service).
サービス拒否は事実上フリーライダー問題の逆です。フローはリソースの競合すると1つのフローは値しない、高い優先順位を受信した場合、別のに値するの流れを先取りすることができるかもしれ（したがって1フリーライダーは、サービスの他の否定であることが判明します）。
Instability:
不安定：
The combination of preemption priority, killer reservation and blockade state [RSVP] may increase the instability of admitted flows where a reservation may be preempted, reinstated, and preempted again periodically.
先取り優先順位、キラー予約と遮断状態[RSVP]の組み合わせは、予約は、プリエンプト回復、及び定期的再び先行され得る、許可されたフローの不安定性を増加させることができます。
In merging situations LDPs may receive multiple preemption elements and must compute the priority of the merged flow according to the following rules:
マージ状況でLDPsは、複数のプリエンプション要素を受信し、次のルールに従ってマージされたフローの優先度を計算しなければなりません。
a. Preemption priority and defending priority are merged and computed separately, irrespective of each other.
A。先取り優先順位と防御優先度にかかわらず、互いの、マージと別々に計算されます。
b. Participating priority elements are selected.
B。参加優先要素が選択されています。
All priority elements are examined according to their merging strategy to decide whether they should participate in the merged result (as specified bellow).
すべての優先度の要素は、それらが（指定怒鳴るとして）マージ結果に参加すべきかどうかを決定するために彼らの合併の戦略に応じて検討されています。
c. The highest priority of all participating priority elements is computed.
C。すべての参加優先要素の優先順位が最も高いが計算されます。
The remainder of this section describes the different merging strategies the can be specified in the PREEMPTION_PRI element.
このセクションの残りの部分は、ザがPREEMPTION_PRI要素で指定することができる異なるマージ戦略を記載しています。
The PREEMPTION_PRI element would participate in the merged reservation only if it belongs to a flow that contributed to the merged QoS level (i.e., that its QoS requirement does not constitute a subset another reservation.) A simple way to determine whether a flow contributed to the merged QoS result is to compute the merged QoS with and without it and to compare the results (although this is clearly not the most efficient method).
それがマージされたQoSレベルに寄与フローに属している場合にのみPREEMPTION_PRI要素がマージされた予約に参加する（すなわち、そのQoS要件は、サブセットに別の予約を構成しないこと。）流れがに寄与するかどうかを決定するための簡単な方法をマージされたQoSは、結果とし、それなしでマージされたQoSを計算すると、（これは明らかに、最も効率的な方法ではありませんが）の結果を比較することです。
The reasoning for this approach is that the highest QoS flow is the one dominating the merged reservation and as such its priority should dominate it as well. This approach is the most amiable to the prevention of priority distortions such as free-riders and denial of service.
このアプローチの理由は、最も高いQoSフローがマージされた予約を支配1であることであり、そのようなとしての優先順位は同様にそれを支配する必要があります。このアプローチは、そのようなフリーライダーやサービス拒否など優先順位の歪みの防止に最も愛想です。
This is a recommended merging strategy.
これは推奨マージ戦略です。
All PREEMPTION_PRI elements participate in the merged reservation.
すべてのPREEMPTION_PRI要素がマージされた予約に参加しています。
This strategy disassociates priority and QoS level, and therefore is highly subject to free-riders and its inverse image, denial of service.
この戦略は、優先順位とQoSレベルを解離するため、フリーライダーとその反転画像、サービス拒否攻撃に非常に受けやすいです。
This is not a recommended method, but may be simpler to implement.
これは推奨される方法ではありませんが、実装が簡単かもしれません。
A PREEMPTION_PRI element may participate in a merged reservation only if all other flows in the merged reservation have the same QoS level (homogeneous flows).
PREEMPTION_PRI要素は、マージされた予約内の他のすべてのフローが同一のQoSレベル（均質フロー）を持つ場合にのみ、マージされた予約に参加することができます。
The reasoning for this approach assumes that the heterogeneous case is relatively rare and too complicated to deal with, thus it better be prohibited.
このアプローチの理由は、異種の場合は、これそれは良く禁止することは比較的まれとに対処するにはあまりにも複雑であることを前提としています。
This strategy lends itself to denial of service, when a single receiver specifying a non-compatible QoS level may cause denial of service for all other receivers of the merged reservation.
この戦略は、非互換のQoSレベルを指定する単一の受信機がマージされた予約の他のすべての受信機のためサービス拒否を引き起こす可能性がある場合は、サービス拒否に向いています。
Note: The determination of heterogeneous flows applies to QoS level only (FLOWSPEC values), and is a matter for local (LDP) definition. Other types of heterogeneous reservations (e.g., conflicting reservation styles) are handled by RSVP and are unrelated to this PREEMPTION_PRI element.
注：異種フローの決意がQoSに適用される（FLOWSPEC値）だけレベル、および局所（LDP）の定義のために問題です。異種予約（例えば、予約スタイルを競合する）他のタイプのRSVPによって処理し、このPREEMPTION_PRI要素とは無関係されています。
This is a recommended merging strategy when reservation homogeneity is coordinated and enforced for the entire multicast tree. It is more restrictive than Section 5.1.1, but is easier to implement.
これは、予約の均一性が全体のマルチキャストツリーのために協調して実施され、推奨マージ戦略です。これは、5.1.1項より制限ですが、実装が簡単です。
When POLICY_DATA objects are protected by integrity, LDPs should not attempt to modify them. They must be forwarded as-is or else their security envelope would be invalidated. In other cases, LDPs may modify and merge incoming PREEMPTION_PRI elements to reduce their size and number according to the following rule:
POLICY_DATAオブジェクトが整合性によって保護されている場合は、LDPsは、それらを変更しようとするべきではありません。そのまままたは他の彼らのセキュリティエンベロープが無効にされるだろう彼らは転送されなければなりません。他の場合には、LDPsは、以下のルールに従ってそれらのサイズおよび数を減らすために、着信PREEMPTION_PRI要素を変更し、マージすることができます。
Merging is performed for each merging strategy separately.
マージは別に、各マージ戦略のために行われます。
There is no known algorithm to merge PREEMPTION_PRI element of different merging strategies without loosing valuable information that may affect OTHER nodes.
他のノードに影響を与える可能性があり、貴重な情報を失うことなく、異なるマージ戦略のPREEMPTION_PRI要素をマージする既知のアルゴリズムではありません。
- For each merging strategy, the highest QoS of all participating PREEMPTION_PRI elements is taken and is placed in an outgoing PREEMPTION_PRI element of this merging strategy.
- 各マージ戦略について、すべての参加PREEMPTION_PRI要素の最も高いQoSが取られ、このマージ戦略の発信PREEMPTION_PRI要素内に配置されます。
- This approach effectively compresses the number of forwarded PREEMPTION_PRI elements to at most to the number of different merging strategies, regardless of the number of receivers (See the example in Appendix A.2).
- この手法は効果的にかかわらず、受信機の数（付録A.2の例を参照）、異なるマージ戦略の数に最もATに転送PREEMPTION_PRI要素の数を圧縮します。
6 Error Processing
6エラー処理
A PREEMPTION_PRI error object is sent back toward the appropriate receivers when an error involving PREEMPTION_PRI elements occur.
PREEMPTION_PRI要素を伴うエラーが発生したときPREEMPTION_PRIエラーオブジェクトは、適切な受信機に向けて返送されます。
PREEMPTION
プリエンプション
When a previously admitted flow is preempted, a copy of the preempting flow's PREEMPTION_PRI element is sent back toward the PDP that originated the preempted PREEMPTION_PRI object. This PDP, having information on both the preempting and the preempted priorities may construct a higher priority PREEMPTION_PRI element in an effort to re-instate the preempted flow.
以前入院の流れを先取りした場合、プリエンプトフローのPREEMPTION_PRI要素のコピーがプリエンプトPREEMPTION_PRIオブジェクトを発したPDPに向かって送り返されます。このPDPは、先取りおよびプリエンプト優先度の両方の情報を有するプリエンプト流れを再instateする目的で、より高い優先PREEMPTION_PRI要素を構築することができます。
Heterogeneity
異質
When a flow F1 with Heterogeneous Error merging strategy set in its PREEMPTION_PRI element encounters heterogeneity the PREEMPTION_PRI element is sent back toward receivers with the Heterogeneity error code set.
そのPREEMPTION_PRI要素に設定異種エラーマージ戦略と流れF1が不均一に遭遇したときPREEMPTION_PRI要素が不均一エラーコードが設定された受信機に向けて返送されます。
7 IANA Considerations
7つのIANAの考慮事項
Following the policies outlined in [IANA-CONSIDERATIONS], Standard RSVP Policy Elements (P-type values) are assigned by IETF Consensus action as described in [RSVP-EXT].
[RSVP-EXT]に記載されているように[IANA-考察]に概説された方針に従う、標準RSVPポリシー素子（P型値）IETF Consensus動作によって割り当てられます。
P-Type PREEMPTION_PRI is assigned the value 1.
p型PREEMPTION_PRIは値1が割り当てられます。
8 Security Considerations
8セキュリティについての考慮事項
The integrity of PREEMPTION_PRI is guaranteed, as any other policy element, by the encapsulation into a Policy Data object [RSVP-EXT].
PREEMPTION_PRIの完全性は、ポリシーデータオブジェクト[RSVP-EXT]にカプセル化することによって、他のポリシー要素として、保証されています。
Further security mechanisms are not warranted, especially considering that preemption priority aims to provide simple and quick guidance to routers within a trusted zone or at least a single zone (no zone boundaries are crossed).
また、セキュリティメカニズムは、特に（ないゾーン境界が交差されていない）プリエンプションの優先度が信頼ゾーンまたは少なくとも一つのゾーン内のルータに簡単かつ迅速に指針を提供することを目指していることを考慮すると、保証されていません。
9 References
9つの参考文献
[RFC2751] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[RFC2751]ヘルツォーク、S.、RFC 2751 2000年1月、 "先取り優先権方針要素が通知さ"。
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-EXT]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[COPS-RSVP]ボイル、J.、コーエン、R.、ダラム、D.、ヘルツォーク、S.、ラージャ、R.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[RAP] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[COPS]ボイル、J.、コーエン、R.、ダーラム、D.、ヘルツォーク、S.、ラジャ、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - 機能的な仕様"、RFC 2205、1997年9月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-考察] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
10 Author's Address
10著者のアドレス
Shai Herzog PolicyConsulting.Com 200 Clove Rd. New Rochelle, NY 10801
シャイヘルツォークPolicyConsulting.Com 200クローブRdを。ニューロシェル、NY 10801
EMail: herzog@policyconsulting.com
メールアドレス：herzog@policyconsulting.com
Appendix A: Example
付録A：例
The following examples describe the computation of merged priority elements as well as the translation (compression) of PREEMPTION_PRI elements.
以下の実施例は、マージされた優先順位要素の計算ならびにPREEMPTION_PRI要素の変換（圧縮）を記述する。
A.1 Computing Merged Priority
A.1コンピューティングマージされた優先順位
r1
/ QoS=Hi (Pr=3, St=Highest QoS)
/
s1-----A---------B--------r2 QoS=Low (Pr=4, St=Highest PP)
\ \
\ \ QoS=Low (Pr=7, St=Highest QoS)
r4 r3
QoS=Low (Pr=9, St=Error)
QoSの=ロー（= 9、サン=エラーPR）
Example 1: Merging preemption priority elements
実施例1：マージ先取り優先順位要素
Example one describes a multicast scenario with one sender and four receivers each with each own PREEMPTION_PRI element definition.
実施例1は、一つの送信者とそれぞれ独自PREEMPTION_PRI要素の定義を持つ4つの受信機それぞれにマルチキャストシナリオを記述する。
r1, r2 and r3 merge in B. The resulting priority is 4.
R 1、R 2およびR 3は、得られた優先度が4であるBで合流します。
Reason: The PREEMPTION_PRI of r3 doesn't participate (since r3 is not contributing to the merged QoS) and the priority is the highest of the PREEMPTION_PRI from r1 and r2.
理由：R3のPREEMPTION_PRIは（R3がマージされたQoSに貢献されていないため）参加しないと優先順位はR1とR2からPREEMPTION_PRIの最高です。
r1, r2, r3 and r4 merge in A. The resulting priority is again 4: r4 doesn't participate because its own QoS=Low is incompatible with the other (r1) QoS=High. An error PREEMPTION_PRI should be sent back to r4 telling it that its PREEMPTION_PRI element encountered heterogeneity.
R1、R2、R3及びR4は、Aにマージ結果の優先順位は、再び4：独自のQoS =ローがHigh他の（R1）のQoS =と互換性がないためR4は関与しません。エラーPREEMPTION_PRIは、そのPREEMPTION_PRI要素が不均一に遭遇したことを通知R4に戻って送信する必要があります。
A.2 Translation (Compression) of Priority Elements
優先要素のA.2変換（圧縮）
Given this set of participating PREEMPTION_PRI elements, the following compression can take place at the merging node:
参加PREEMPTION_PRI要素のセットを考えると、以下の圧縮がマージノードで行うことができます。
From: (Pr=3, St=Highest QoS) (Pr=7, St=Highest QoS) (Pr=4, St=Highest PP) (Pr=9, St=Highest PP) (Pr=6, St=Highest PP) To: (Pr=7, St=Highest QoS) (Pr=9, St=Highest PP)
From：（PR = 3、Stは=最高QoS）の（PR = 7、セント=最高QoS）の（PR = 4、セント=最高PP）（PR = 9、セント=最高PP）（PR = 6、セント=最高PP）：（PR = 7、Stは=最高QoS）の（PR = 9、セント=最高PP）
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。