5. ホップごとの動作の標準化ガイドライン

PHB の動作特性 (behavioral characteristics) は標準化されるべきであり, それらを実装するために使用される特定のアルゴリズムやメカニズムではありません。ノードには, パケットを出力インターフェースにスケジュールする方法を制御するために使用できる (おそらく大きな) パラメータのセットがある場合があります (たとえば, 設定可能な優先度, キュー長, ラウンドロビン重み, ドロップアルゴリズム, ドロップ優先度の重みとしきい値などを持つN個の個別のキュー)。PHB とメカニズムの違いを説明するために, クラスセレクタ準拠PHB (Class Selector Compliant PHB) は, 厳密優先度キューイング, WFQ, WRR, またはバリアント [HPFQA, RPS, DRR], または CBQ [CBQ] を含むいくつかのメカニズムによって, 単独または組み合わせて実装される可能性があることを指摘します。

PHB は個別に, またはグループ (group) として指定される場合があります (単一の PHB は PHB グループの特殊なケースです)。PHB グループは通常, キューサービスまたはキュー管理ポリシーなど, グループ内の各 PHB に適用される共通の制約 (common constraint) のために, 同時に意味のある指定と実装のみが可能な2つ以上の PHB のセットで構成されます。PHB グループ仕様は, パケットがグループ内の別の PHB を選択するために再マークされる可能性がある条件を記述すべきです (SHOULD)。PHB 実装はマイクロフロー (microflow) 内でパケットの再順序付けを導入しないことが推奨されます (RECOMMENDED)。PHB グループ仕様は, 各個別の PHB に対して発生する可能性のあるパケット再順序付けの影響 (packet re-ordering implications), およびマイクロフロー内の異なるパケットがグループ内の異なる PHB に対してマークされている場合に発生する可能性のある影響を識別しなければなりません (MUST)。

既存の PHB 標準によって記述されておらず, 実装, 展開され, 有用であることが示されたホップごとの動作のみが標準化されるべきです (SHOULD)。差別化サービスの現在の経験はかなり限られているため, これらのホップごとの動作の正確な仕様を仮定することは時期尚早です。

各標準化された PHB には, 32コードポイントのスペースから割り当てられた推奨 (RECOMMENDED) コードポイントが関連付けられている必要があります (MUST) (第6節を参照)。この仕様では, 進化の余地を残すためにコードポイントスペースに余裕を残しているため, 定義されたスペース ('xxx000') は意図的に疎 (intentionally sparse) です。

ネットワーク機器ベンダーは, 有用またはマーケット性があると見なされるパラメータと機能を自由に提供できます。特定の標準化された PHB がノードに実装される場合, ベンダーは標準に従って PHB の定義を満たす任意のアルゴリズムを使用できます (MAY)。ノードの機能とその特定の構成によって, パケットを処理できるさまざまな方法が決まります。

サービスプロバイダーは, ネットワーク内でサービスの差別化を可能にするために同じノードメカニズムまたは構成を使用する必要はなく, サービス提供とトラフィックエンジニアリングの目標に適した方法でノードパラメータを自由に構成できます。時間の経過とともに, 特定の一般的なホップごとの動作が進化する可能性があります (つまり, エンドツーエンドサービスの実装に特に有用なもの), これらは DSフィールドの特定の EXP/LU PHB コードポイントに関連付けられ (MAY), ドメイン境界を越えて使用できるようになります (第6節を参照)。これらの PHB は将来の標準化の候補です。

標準化された PHB は, [ARCH] に示されているガイドラインに従って指定されることが推奨されます (RECOMMENDED)。