1. はじめに (Introduction)

差分化サービス (Differentiated Services) は、インターネットにおけるスケーラブルなサービス識別の展開を可能にするためのフレームワークと構成要素を提供することを目的としています。差分化サービスアプローチは、アーキテクチャを2つの主要コンポーネントに分離することで展開を加速することを目指しており、一方はかなりよく理解されており、もう一方は理解され始めたばかりです。この点において、我々はインターネットの元々の設計に導かれています。そこでは、転送コンポーネントとルーティングコンポーネントを分離するという決定が下されました。パケット転送は、パケットごとにできるだけ迅速に実行する必要がある比較的単純なタスクです。転送は、パケットヘッダーを使用してルーティングテーブル内のエントリを見つけ、そのエントリがパケットの出力インターフェースを決定します。ルーティングはそのテーブル内のエントリを設定し、さまざまなトランジットポリシーやその他のポリシーを反映する必要があり、また経路障害を追跡する必要があります。ルーティングテーブルは、転送タスクのバックグラウンドプロセスとして維持されます。さらに、ルーティングはより複雑なタスクであり、過去20年間にわたって進化し続けています。

同様に、差分化サービスアーキテクチャには2つの主要コンポーネントが含まれています。1つは転送パスにおけるかなりよく理解された動作であり、もう1つはより複雑でまだ新しく出現している、転送パスで使用されるパラメータを設定するバックグラウンドポリシーと割り当てコンポーネントです。転送パスの動作には、キューサービス規律 (Queue Service Disciplines) および/またはキュー管理規律 (Queue Management Disciplines) によって実装される、個々のパケットが受ける差別的な処理が含まれます。これらのホップごとの動作 (Per-Hop Behaviors) は、エンドツーエンドまたはドメイン内サービスをどのように構築するかに関係なく、パケットの差別化された処理を提供するためにネットワークノードで有用かつ必要です。我々の焦点は、これらの動作を実装するために使用される特定のメカニズムではなく、動作の一般的なセマンティクスにあります。なぜなら、これらの動作はメカニズムよりも緩やかに進化するからです。

ホップごとの動作とパケットごとにそれらを選択するメカニズムは、今日のネットワークノードに展開でき、差分化サービスアーキテクチャのこの側面が最初に取り組まれています。さらに、転送パスでは、特別な処理の提供に関連する要件を実施するために、「特別な」処理用に指定されたネットワークトラフィックに対して、監視、ポリシング、およびシェーピングが行われる必要がある場合があります。この種のトラフィック条件付け (Traffic Conditioning) のメカニズムもかなりよく理解されています。このようなトラフィックコンディショナーの広範な展開は、サービスの構築を可能にするためにも重要ですが、サービスの構築におけるそれらの実際の使用は時間とともに進化する可能性があります。

どのパケットが特別な処理を受けるか、およびリソースの使用にどのような種類のルールを適用するかに関するネットワーク要素の設定は、はるかに理解されていません。それにもかかわらず、単純なポリシーと静的な設定を使用することで、ネットワークに有用な差分化サービスを展開することは可能です。[ARCH] で説明されているように、ホップごとの動作とトラフィックコンディショナーを組み合わせてサービスを作成する方法はいくつかあります。このプロセスで、より複雑なポリシーと割り当てを導く追加の経験が得られます。転送パスの基本動作は、アーキテクチャのこのコンポーネントが進化する間も同じままでいられます。このようなサービスの構築に関する経験はしばらく続くため、それが時期尚早であるため、我々はこの構築の標準化を避けています。さらに、サービス構築の詳細の多くは、異なるビジネスエンティティ間の法的合意によってカバーされており、これは IETF の範囲外であるため、我々はこれを避けています。

本文書は転送パスコンポーネントに焦点を当てています。パケット転送パスでは、差分化サービスは、IPパケットヘッダー内のフィールドに含まれるコードポイント (Codepoint) を、そのパス上の各ネットワークノードにおける特定の転送処理、またはホップごとの動作 (PHB, Per-Hop Behavior) にマッピングすることによって実現されます。コードポイントは、本文書で後で定義される一連の必須値、将来の文書で定義される一連の推奨値から選択されるか、または純粋にローカルな意味を持つ可能性があります。PHB は、ネットワークノードの出力インターフェースキューにさまざまなキューサービスおよび/またはキュー管理規律を使用して実装されることが期待されています。たとえば、重み付けラウンドロビン (WRR, Weighted Round-Robin) キューサービスまたはドロップ優先度キュー管理などです。

マーキングは、ネットワークの端（ファーストホップルーターまたはソースホスト）および管理境界を含む、ネットワーク境界のトラフィックコンディショナーによって実行されます。トラフィックコンディショナーには、マーキング、メータリング、ポリシング、およびシェーピングのプリミティブが含まれる場合があります（これらのメカニズムは [ARCH] で説明されています）。サービスは、境界での特定のパケット分類およびトラフィック条件付けメカニズムの使用と、トラフィックの伝送パスに沿ったホップごとの動作の連結によって実現されます。差分化サービスアーキテクチャの目標は、構成要素の数と種類、およびそれらから構築されるサービスの両方について、将来の拡張性のためにこれらの構成要素を指定することです。

本メモで使用される用語は第2節で定義されています。差分化サービスフィールド定義 (DS Field) は第3節で示されています。第4節では、IPv4 優先度 (Precedence) フィールドの現在の使用との部分的な下位互換性の要望について説明します。解決策として、クラスセレクタコードポイント (Class Selector Codepoints) とクラスセレクタ準拠 PHB (Class Selector Compliant PHBs) を導入します。第5節では、ホップごとの動作の標準化のためのガイドラインを示します。第6節では、コードポイントの割り当てのためのガイドラインについて説明します。第7節では、セキュリティに関する考慮事項を扱います。

本文書は、DS フィールドとその使用法の簡潔な説明です。差分化サービスアーキテクチャ [ARCH] と合わせて読むことを意図しています。

本文書におけるキーワード「しなければならない (MUST)」、「してはならない (MUST NOT)」、「必須である (REQUIRED)」、「しなければならない (SHALL)」、「してはならない (SHALL NOT)」、「すべきである (SHOULD)」、「すべきでない (SHOULD NOT)」、「推奨される (RECOMMENDED)」、「してもよい (MAY)」、および「任意である (OPTIONAL)」は、[RFC2119] で説明されているように解釈されるものとします。