[要約] RFC 3181は、サインアルドプリエンプション優先ポリシーエレメントに関する規格であり、通信ネットワークにおける優先順位付けのための仕組みを提供します。このRFCの目的は、ネットワークリソースの効率的な利用と、リアルタイム通信の品質向上を実現することです。
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.
Copyright（c）The Internet Society（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.
このメモは、RSVP Policy_Data P-Type CodePoint割り当てエラーをRFC 2751で修正します。
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]や[COP]など）によって使用するための先制優先ポリシー要素について説明します。
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つは、ネットワークノードへの入場を競う他の人に対するフローの重要性のランクです。プリエンプションの優先順位は、ノードを介して入場を試みる一連のフローがリソースのオーバーブッキングを表している場合にのみ有効になります。プリエンプションの優先順位基準は、低優先度のものを拒否しながら、入場のためにノードが最も重要なフロー（最優先事項）を選択するのに役立ちます。
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
- それらはPDPによって作成されます
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要素で表されるこの優先順位は、LDPを持つがPDPを制御しない同じポリシードメインの下流のPEPに通知できます。
- They can be processed by LDPs
- それらはLDPによって処理できます
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を持たないノードのLDPによって処理されます。LDPは、これらのオブジェクトを解釈したり、そのままそれらを転送したり、ローカルマージを実行して同等の合併Preemption_priポリシー要素を転送します。LDPは、Preemption_PriオブジェクトのPDPによってエンコードされたマージ戦略に従う必要があります。（明らかに、LDPのスーパーセットであるPDPもLDPとして機能する可能性があります）。
- They are enforced by PEPs
- それらはPEPSによって施行されています
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
マージ戦略：8ビット1最高のQoSの優先度：推奨2は最優先事項を取ります：不均一なマージの攻撃的な3力誤差
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ビットエラーコード：8ビット0 NO_ERROR値が通常のPreemption_pri要素に使用されます1プリエンプション以前に認められたフローが先制しました2不均一なこの要素は不均一なマージに遭遇しました
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=???
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 = hiが必要ですが、どのような優先順位を想定する必要がありますか？このような合併に影響を与える可能性のあるいくつかの負の副作用が特定されています。
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にのみ意図されている優先度が高いと仮定して、フリーライドを得ました。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:
マージの状況では、LDPは複数の先制要素を受け取る場合があり、次のルールに従ってマージされたフローの優先度を計算する必要があります。
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).
Preemption_Pri要素は、マージされたQoSレベルに寄与するフローに属している場合にのみ、マージされた予約に参加します（つまり、そのQoS要件はサブセットの別の予約を構成しないということです。マージされたQoS結果は、マージされたQOをそれを使用したり使用せずに計算し、結果を比較することです（ただし、これは明らかに最も効率的な方法ではありません）。
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フローがマージされた予約を支配するものであり、そのため、その優先事項もそれを支配する必要があるからです。このアプローチは、フリーライダーやサービス拒否などの優先段階の歪みの防止にとって最も魅力的です。
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オブジェクトが整合性によって保護されている場合、LDPはそれらを変更しようとしてはなりません。それらはそのまま転送されなければなりません。さもなければ、彼らのセキュリティエンベロープは無効になります。それ以外の場合、LDPは、次のルールに従って、入っている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).
- このアプローチは、受信機の数に関係なく、転送されたPreemption_pri要素の数をせいぜい、さまざまなマージ戦略の数に効果的に圧縮します（付録A.2の例を参照）。
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.
以前に認められたフローが先制されると、Preempting FlowのPreemption_Pri要素のコピーが、Preempted Preemption_Priオブジェクトを発信するPDPに向かって送り返されます。このPDPは、先制および先制優先度の両方に関する情報を持っている可能性があるため、先制されたフローを再設計するために、より高い優先順位の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.
Flow 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].
[IANA分類]で概説されているポリシーに続いて、[RSVP-Ext]で説明されているように、標準のRSVPポリシー要素（Pタイプ値）がIETFコンセンサスアクションによって割り当てられます。
P-Type PREEMPTION_PRI is assigned the value 1.
p-type 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] Herzog、S。、「シグナル前の先制優先政策要素」、RFC 2751、2000年1月。
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-Ext] Herzog、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。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[Rap] Yavatkar、R.、Pendarakis、D。and R. Guerin、「政策ベースの入場管理の枠組み」、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] Boyle、J.、Cohen、R.、Durham、D.、Herzog、S.、Raja、R。and A. Sastry、「The Cops（Common Open Policy Service）Protocol」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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-Considerations] 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
Shai Herzog PolicyConsulting.com 200 Clove Rd。ニューロシェル、ニューヨーク10801
EMail: 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要素の翻訳（圧縮）について説明します。
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)
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つは、1つの送信者とそれぞれ4つのレシーバーを使用したマルチキャストシナリオについて説明します。
r1, r2 and r3 merge in B. The resulting priority is 4.
R1、R2、およびR3はBでマージします。結果として得られる優先度は4です。
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はマージされたQOに寄与していないため）。優先度は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.
AのR1、R2、R3、R4のマージは、結果として得られる優先度は再び4：R4が関与しません。独自のQOS =低は他の（R1）QOS = Highと互換性がないためです。エラーpreemption_priをR4に送り返し、そのpreemption_pri要素が不均一性に遭遇したことを示します。
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)
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。