RFC2751 日本語訳

Network Working Group                                           S. Herzog
Request for Comments: 2751                                      IPHighway
Category: Standards Track                                    January 2000

コメントを求めるワーキンググループS.ハーツォグ要求をネットワークでつないでください: 2751年のIPHighwayカテゴリ: 標準化過程2000年1月

              Signaled Preemption Priority Policy Element

合図された先取り優先権方針要素

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This document describes a preemption priority policy element for use
   by signaled policy based admission protocols (such as [RSVP] and
   [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.

ネットワークに認められるのを競争しながら、先取り優先権は流れのセットの中で相対的な重要性(ランク)を定義します。 到着(最初に、Come First Admitted)ネットワーク・ノードの注文による流れが、より新しくて、高い優先度に場所を開けるためにプライオリティがいくつかの以前に認められた低い優先権流れを先取りすると考えるかもしれないことを認めるよりむしろ、流れてください。

Herzog                      Standards Track                     [Page 1]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[1ページ]RFC2751

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 Information .............................................9
   Appendix A: Example ...............................................10
   A.1  Computing Merged Priority ....................................10
   A.2  Translation (Compression) of Priority Elements ...............11
   Full Copyright Statement ..........................................12

1つの序論…2 2の範囲と適用性…3 3の国がない方針…3 4方針要素形式…問題を合併する4 5優先権…5 戦略を合併する5.1優先権…6 5.1 .1 最も高いQoSの優先権を取ってください…6 5.1 .2 最優先を取ってください…7 5.1 .3 異種のマージに誤りを押しつけてください…7 5.2 Priority Elementsを変更します…7 6エラー処理…8 7のIANA問題…8 8のセキュリティ問題…8 9の参照箇所…9 10 情報を書いてください…9 付録A: 例…10 A.1コンピューティングは優先権を合併しました…10 Priority ElementsのA.2翻訳(圧縮)…11 完全な著作権宣言文…12

1  Introduction

1つの序論

   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.

容量が疲れ果てるまで(最初に、Come First Admitted)、伝統的なCapacityベースのAdmission Control(CAC)は無差別に新しい流れを認めます。 方針はAdmission Control(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つは他のものに比例した流れがネットワーク・ノードに入場を競争する重要性のランクです。 ノードを通して入場を試みる1セットの流れが或るものがCACに基づいて拒絶されなければならないようにリソースのオーバーブッキングを表す場合にだけ、先取りPriorityは効きます。 先取り優先権評価基準は、ノードが入場のために低い優先権方を拒絶している間、最も重要な流れ(最優先)を選択するのを助けます。

   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]の方針要素として表された先取り優先権の形式と適用性について説明します。

Herzog                      Standards Track                     [Page 2]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[2ページ]RFC2751

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]のためのFrameworkドキュメントは(すなわち、PDP、PEP、および自由民主党)を作る政策決定に参加する様々なコンポーネントについて説明します。 PREEMPTION_PRI要素の強調は、ノードの自由民主党(地方のDecision Point)の中で内部的にそれらを実行できるくらい簡単で、国がなく、軽量であることです。

   Certain base assumptions are made in the usage model for
   PREEMPTION_PRI elements:

あるベース仮定はPREEMPTION_PRI要素のために用法モデルでされます:

   - They are created by PDPs

- それらは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.

PDPsが方針ドメイン(例えば、境界ルータにおける)の周辺でPEPsを制御するモデルでは、PDPsは関連政策ルールのセットをただ一つの優先権評価基準に減少させます。 そしてときにPREEMPTION_PRI要素で言い表されるこの優先権はLDPsを持っている同じ方針ドメインの川下のPEPsとコミュニケートしていますが、制御していない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物のPDPsによってコード化された合併している戦略に従わなければなりません。 (明確に、自由民主党のスーパーセットでありPDPはまた、自由民主党として機能するかもしれません。)

   - 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 [COSP, COPS-RSVP]).

合図されたPreemption Priorityは国がないです(歴史か外部の情報が解釈されるのが過ぎて必要ではありません)。 したがって、政策決定のアウトソーシングへのCOPSメッセージで運ばれると、COPS Stateless Policy Data Decisionが反対するように([COSP、COPS-RSVP]を見てください)これらの物は含まれています。

Herzog                      Standards Track                     [Page 3]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[3ページ]RFC2751

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.

Policy Data物の書式は[RSVP-EXT]で定義されます。 それぞれ異なって(恐らく直交する)の方針を表して、単一のPolicy Data物は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        |
      +------+------+-------------+-------------+-------------+

+-------------+-------------+-------------+-------------+ | 長さ(12)| P-タイプは先取り_PRIと等しいです。| +------+------+-------------+-------------+-------------+ | 旗| M。 戦略| エラーコード| 予約された(0)| +------+------+-------------+-------------+-------------+ | 先取り優先権| 防御している優先権| +------+------+-------------+-------------+-------------+

   Length: 16 bits
      Always 12. The overall length of the policy element, in bytes.

長さ: 16ビットのAlways12。 バイトで表現される方針要素の全長。

   P-Type: 16 bits
      PREEMPTION_PRI  = 3

P-タイプ: 16ビットPREEMPTION_PRI=3

      This value is registered with IANA, see Section 7.

セクション7は、この値がIANAに示されるのを見ます。

   Flags: 8 bits
      Reserved (always 0).

旗: 8ビットのReserved(いつも0)。

   Merge Strategy: 8 bit
      1    Take priority of highest QoS: recommended
      2    Take highest priority: aggressive
      3    Force Error on heterogeneous merge

戦略を合併してください: 8は最も高いQoSの1つのTake優先権に噛み付きました: お勧めの2Take最優先: 異種のマージでの攻撃的な3Force Error

   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ビットのErrorコード: 通常のPREEMPTION_PRI要素1PREEMPTION Thisが、以前に流れが異種で遭遇する先取りされた2HETEROGENEOUS This要素であることを認めたので、0いいえ_ERROR Valueが使用した8ビットは合併します。

   Reserved: 8 bits
      Always 0.

予約される: 8ビットのAlways0。

   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は以前に認められた流れの防御している優先権と比べて新しい流れの優先権に噛み付きました(無記名の)。 より高い値は、より高いPriorityを表します。

Herzog                      Standards Track                     [Page 4]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[4ページ]RFC2751

   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: QoSは高値と等しく、優先権は低いF2と等しいです: QoSは安値、優先権と= 高く等しいです。

   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があるはずであるという合併している条件=Priorityだけを仮定するべきですか? そのような合併に影響するかもしれない数回の否定的副作用が特定されました:

   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が、Priority=が高いと仮定するなら、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が、Priority=が低いと仮定するなら、合併している流れは、先取りされるか、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人の自由な乗り手が、別のもののサービスの否定であると判明します)。

Herzog                      Standards Track                     [Page 5]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[5ページ]RFC2751

   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]は認められた流れの不安定性を増加させるかもしれません。

5.1  Priority Merging Strategies

5.1 戦略を合併する優先権

   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要素で指定されてください。

5.1.1  Take priority of highest QoS

5.1.1 最も高いQoSの優先権を取ってください。

   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要件がするのが部分集合を構成しません。合併しているQoSレベルに貢献した流れに属す場合にだけPREEMPTION_PRI要素が合併している予約に参加するだろう、(別の予約、) 流れが合併している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流動が合併している予約とそういうものとしてその優先権を支配するものであるということであるので、また、推理はそれを支配するべきです。 このアプローチはサービスの無料の乗り手や否定などの優先権ひずみの防止に最も愛想がよいです。

   This is a recommended merging strategy.

これはお勧めの合併している戦略です。

Herzog                      Standards Track                     [Page 6]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[6ページ]RFC2751

5.1.2  Take highest priority

5.1.2 最優先を取ってください。

   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.

これは、お勧めの方法ではありませんが、実行するのは、より簡単であるかもしれません。

5.1.3  Force error on heterogeneous merge

5.1.3 異種のマージに誤りを押しつけてください。

   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).

合併している予約における他のすべての流れに同じQoSレベル(均質の流れ)がある場合にだけ、PREEMPTION_PRI要素は合併している予約に参加するかもしれません。

   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値)だけに申し込んで、地方の(自由民主党)定義のための問題です。 他のタイプの異種の条件(例えば、闘争している予約スタイル)は、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より制限していますが、より実行しやすいです。

5.2  Modifying Priority Elements

5.2 Priority Elementsを変更すること。

   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.

OTHERノードに影響するかもしれない貴重な情報を発射しないで異なった合併している戦略のPREEMPTION_PRI要素を合併するために、知られているアルゴリズムは全くありません。

Herzog                      Standards Track                     [Page 7]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[7ページ]RFC2751

   -  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).

- これにアプローチします。事実上、受信機(Appendix A.2の例を見る)の数にかかわらず進められた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、先取りと先取りされたプライオリティの両方の情報を持っていると、より高い優先権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.

Heterogeneous ErrorがPREEMPTION_PRI要素に設定された戦略を合併している流れF1が異種性に遭遇するとき、PREEMPTION_PRI要素はHeterogeneity誤りコードセットで受信機に向かって返送されます。

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-CONSIDERATIONS]、(P-タイプ値)が[RSVP-EXT]で説明されるようにIETF Consensus動作で割り当てられるStandard RSVP Policy Elementsに概説された方針に従います。

   P-Type PREEMPTION_PRI is assigned the value 3.

値3はP-タイプPREEMPTION_PRIに割り当てられます。

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の保全はいかなる他の方針要素としてもカプセル化によってPolicy Data物[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).

さらなるセキュリティー対策は保証されません、先取り優先権が、信じられたゾーンか少なくともただ一つのゾーンの中のルータに簡単で迅速な指導を提供することを目指すと特に考える場合(どんなゾーン境界も交差していません)。

Herzog                      Standards Track                     [Page 8]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[8ページ]RFC2751

9  References

9つの参照箇所

   [RSVP-EXT]            Herzog, S., "RSVP Extensions for Policy
                         Control", RFC 2750, January 2000.

[RSVP-EXT] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、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.とRajaとR.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。

   [RAP]                 Yavatkar, R., et al., "A Framework for Policy
                         Based Admission Control", RFC 2753, January
                         2000.

[RAP] Yavatkar、R.、他、「方針のベースの入場コントロールのための枠組み」、RFC2753、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.

[巡査]ボイル、J.、コーエン、R.、ダラム、D.、ハーツォグ、S.、王侯、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。

   [RSVP]                Braden, R., ed., et al., "Resource ReSerVation
                         Protocol (RSVP) - Functional Specification",
                         RFC 2205, September 1997.

[RSVP] ブレーデン、R.、教育、他、「資源予約は(RSVP)について議定書の中で述べます--機能的な仕様」、RFC2205、9月1997日

   [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問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。

10 Author Information

10 作者情報

   Shai Herzog
   IPHighway, Inc.
   55 New York Avenue
   Framingham, MA 01701

ShaiハーツォグIPHighway Inc.55ニューヨークAvenueフレイミングハム、MA 01701

   Phone: (508) 620-1141
   EMail: herzog@iphighway.com

以下に電話をしてください。 (508) 620-1141 メールしてください: herzog@iphighway.com

Herzog                      Standards Track                     [Page 9]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[9ページ]RFC2751

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

r1 / QoSはこんにちは、(Pr=3、通り=の最も高いQoS)/s1と等しいです。-----A---------B--------低い(Pr=4、通り=の最も高いPP)r2 QoS=\\\\QoSは低い(Pr=7、通り=の最も高いQoS)r4 r3と等しいです。

           QoS=Low (Pr=9, St=Error)

QoSは安値と等しいです。(Pr=9、通り=誤り)

         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要素定義のときにそれぞれ1人の送付者と4台の受信機でマルチキャストシナリオについて説明します。

   r1, r2 and r3 merge in B. The resulting priority is 4.

B. 結果として起こる優先権におけるr1、r2、およびr3マージは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が合併している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.

再び、A. 結果として起こる優先権におけるr1、r2、r3、およびr4マージは4です: それ自身のQoS=安値が他の(r1)QoSと= 高く両立しないので、r4は関与しません。 PREEMPTION_PRI要素が異種性に遭遇したとそれに言うr4は誤りPREEMPTION_PRIに送り返されるべきです。

Herzog                      Standards Track                    [Page 10]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[10ページ]RFC2751

A.2 Translation (Compression) of Priority Elements

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、通り=の最も高いQoS) (Pr=7、通り=の最も高いQoS) (最も高いPr=4、通り=pp) (最も高いPr=9、通り=pp) (最も高いPr=6、通り=pp) To: (Pr=7、通り=の最も高いQoS) (最も高いPr=9、通り=pp)

Herzog                      Standards Track                    [Page 11]

RFC 2751      Signaled Preemption Priority Policy Element   January 2000

先取り優先権方針要素2000年1月に合図されたハーツォグ標準化過程[11ページ]RFC2751

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。

Herzog                      Standards Track                    [Page 12]

ハーツォグ標準化過程[12ページ]