RFC 3270 - マルチプロトコルラベルスイッチング (MPLS) による差別化サービスのサポート

Network Working Group F. Le Faucheur, Editor Request for Comments: 3270 L. Wu Category: Standards Track B. Davie Cisco Systems S. Davari PMC-Sierra Inc. P. Vaananen Nokia R. Krishnan Axiowave Networks P. Cheval Alcatel J. Heinanen Song Networks May 2002

             Multi-Protocol Label Switching (MPLS)
               Support of Differentiated Services

             マルチプロトコルラベルスイッチング (MPLS)
               による差別化サービスのサポート

本文書の位置付け (Status of this Memo)

本文書は、インターネットコミュニティのための標準化過程にあるプロトコルを 規定し、その改善に向けた議論と提案を求めるものである。本プロトコルの 標準化段階および状態については、最新版の「Internet Official Protocol Standards」(STD 1) を参照されたい。本文書の配布に制限はない。

著作権表示 (Copyright Notice)

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

要旨 (Abstract)

本文書は、マルチプロトコルラベルスイッチング (MPLS) ネットワーク上で 差別化サービス (Diff-Serv) をサポートするための柔軟なソリューションを 定義する。

このソリューションにより、MPLS ネットワーク管理者は、Diff-Serv ビヘイビアアグリゲート (BA) をラベルスイッチパス (LSP) にどのように マッピングするかを選択でき、自身の特定のネットワークにおける Diff-Serv、 トラフィックエンジニアリング、および保護の目標を最適に満たすことができる。 たとえば、このソリューションにより、ネットワーク管理者は、異なる BA の 集合を同じ LSP にマッピングするか、別々の LSP にマッピングするかを 決定できる。

目次 (Table of Contents)

1. はじめに (Introduction) . . . . . . . . . . . . . . . . . . . . 3 1.1 用語 (Terminology). . . . . . . . . . . . . . . . . . . . . . 5 1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . 6 1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . 7 1.4 全体的な運用 (Overall Operations). . . . . . . . . . . . . . . 7 1.5 ラベルと FEC の関係 (Relationship between Label and FEC) . . . 8 1.6 E-LSP および L-LSP の帯域予約 . . . . . . . . . . . . . . . . 8
2. Diff-Serv LSR のラベル転送モデルとトンネリングモデル . . . . . 9 2.1 Diff-Serv LSR のラベル転送モデル . . . . . . . . . . . . . . . 9 2.2 入力 PHB の決定 (Incoming PHB Determination). . . . . . . . .10 2.3 オプションのトラフィック調整を伴う出力 PHB の決定 . . . . . .11 2.4 ラベル転送 (Label Forwarding). . . . . . . . . . . . . . . .11 2.5 カプセル化層への Diff-Serv 情報のエンコーディング . . . . . .13 2.6 MPLS 上の Diff-Serv トンネリングモデル . . . . . . . . . . .13
3. E-LSP の詳細な運用 . . . . . . . . . . . . . . . . . . . . . .22 3.1 E-LSP の定義 . . . . . . . . . . . . . . . . . . . . . . . .22 3.2 入力 E-LSP の Encaps-->PHB mapping' の設定 . . . . . . . . .23 3.3 入力 E-LSP 上での入力 PHB の決定 . . . . . . . . . . . . . .23 3.4 出力 E-LSP の Set of PHB-->Encaps mappings' の設定 . . . . .24 3.5 出力 E-LSP 上でのカプセル化層への Diff-Serv 情報の エンコーディング . . . . . . . . . . . . . . . . . . . . . .26 3.6 E-LSP のマージ (E-LSP Merging) . . . . . . . . . . . . . . .27
4. L-LSP の詳細な運用 . . . . . . . . . . . . . . . . . . . . .28 4.1 L-LSP の定義 . . . . . . . . . . . . . . . . . . . . . . . .28 4.2 入力 L-LSP の Encaps-->PHB mapping' の設定 . . . . . . . . .28 4.3 入力 L-LSP 上での入力 PHB の決定 . . . . . . . . . . . . . .30 4.4 出力 L-LSP の Set of PHB-->Encaps mappings' の設定 . . . . .31 4.5 出力 L-LSP 上でのカプセル化層への Diff-Serv 情報の エンコーディング . . . . . . . . . . . . . . . . . . . . . .33 4.6 L-LSP のマージ (L-LSP Merging) . . . . . . . . . . . . . . .34
5. Diff-Serv サポートのための RSVP 拡張 . . . . . . . . . . . . .34 5.1 Diff-Serv 関連 RSVP メッセージ形式 . . . . . . . . . . . . .34 5.2 DIFFSERV オブジェクト . . . . . . . . . . . . . . . . . . . .35 5.3 DIFFSERV オブジェクトの処理 . . . . . . . . . . . . . . . . .37 5.4 DIFFSERV オブジェクトの非サポート . . . . . . . . . . . . . .40 5.5 Diff-Serv のためのエラーコード . . . . . . . . . . . . . . .40 5.6 Intserv サービスタイプ . . . . . . . . . . . . . . . . . . .41
6. Diff-Serv サポートのための LDP 拡張 . . . . . . . . . . . . .41 6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . .42 6.2 Diff-Serv ステータスコード値 . . . . . . . . . . . . . . . .44 6.3 Diff-Serv 関連 LDP メッセージ . . . . . . . . . . . . . . . .44 6.4 Diff-Serv TLV の処理 . . . . . . . . . . . . . . . . . . . .46 6.5 Diff-Serv TLV の非処理 . . . . . . . . . . . . . . . . . . .49 6.6 帯域情報 (Bandwidth Information) . . . . . . . . . . . . . .49
7. PPP、LAN、Non-LC-ATM および Non-LC-FR インタフェース上での Diff-Serv の MPLS サポート . . . . . . . . . . . . . . . . . .49
8. LC-ATM インタフェース上での Diff-Serv の MPLS サポート . . . .50 8.1 ATM トラフィッククラスおよびトラフィック管理機構の使用 . . .50 8.2 LC-ATM インタフェースを持つ LSR 実装 . . . . . . . . . . . .50
9. LC-FR インタフェース上での Diff-Serv の MPLS サポート . . . .51 9.1 フレームリレートラフィックパラメータおよびトラフィック管理 機構の使用 . . . . . . . . . . . . . . . . . . . . . . . . .51 9.2 LC-FR インタフェースを持つ LSR 実装 . . . . . . . . . . . . .51
10. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . . .52
11. セキュリティに関する考慮事項 . . . . . . . . . . . . . . . .52
12. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 付録 A. 展開シナリオの例 . . . . . . . . . . . . . . . . . . . .53 付録 B. 帯域予約シナリオの例 . . . . . . . . . . . . . . . . . .58 参考文献 (References). . . . . . . . . . . . . . . . . . . . . .60 著者のアドレス (Authors' Addresses). . . . . . . . . . . . . . .62 完全な著作権表示 (Full Copyright Statement). . . . . . . . . . .64

1. はじめに (Introduction)

MPLS ドメイン [MPLS_ARCH] では、データのストリームが共通のパスを通過 するとき、MPLS シグナリングプロトコルを使用してラベルスイッチパス (LSP) を確立できる。入力ラベルスイッチルータ (LSR) では、各パケット にラベルが割り当てられ、ダウンストリームに送信される。LSP 沿いの各 LSR では、ラベルを使用してパケットを次のホップに転送する。

差別化サービス (Diff-Serv) ドメイン [DIFF_ARCH] では、リンクを通過し、 同じ Diff-Serv 動作を必要とするすべての IP パケットは、ビヘイビア アグリゲート (BA) を構成すると言われる。Diff-Serv ドメインの入力ノード では、パケットは分類され、そのビヘイビアアグリゲートに対応する Diff-Serv コードポイント (DSCP) でマークされる。各中継ノードでは、 DSCP を使用して、各パケットのスケジューリング処理、および場合によって は廃棄確率を決定する Per Hop Behavior (PHB) を選択する。

本文書は、対応する PHB が現在 [DIFF_HEADER]、[DIFF_AF]、[DIFF_EF] で 定義されている Diff-Serv ビヘイビアアグリゲートを MPLS ネットワーク上 でサポートするためのソリューションを規定する。このソリューションは、 将来定義される可能性のある PHB を容易にサポートするための柔軟性も 提供する。

このソリューションは、次の 2 種類の LSP の組み合わせ使用に依存する。

• 複数の順序付きアグリゲート (Ordered Aggregate) を転送できる LSP。 これにより、MPLS シムヘッダの EXP フィールドが、パケットに適用 すべき PHB を LSR に伝達する（パケットのスケジューリング処理と その廃棄優先順位の両方の情報を含む）。

• 単一の順序付きアグリゲートのみを転送する LSP。これにより、 パケットのスケジューリング処理は LSR によってパケットのラベル値 のみから推測され、パケットの廃棄優先順位は MPLS シムヘッダの EXP フィールド、またはカプセル化リンク層固有の選択的廃棄機構 （ATM、フレームリレー、802.1）で伝達される。

[DIFF_HEADER] で述べられているように、「サービスプロバイダは、ネット ワーク内でサービス差別化を可能にするために同じノード機構または設定を 使用することを要求されず、サービス提供およびトラフィックエンジニア リングの目標に適した方法でノードパラメータを自由に設定できる」。 したがって、本文書で定義するソリューションは、サービスプロバイダが Diff-Serv サービスクラスを自身のドメイン内でどのようにルーティング またはトラフィックエンジニアリングするかを選択する柔軟性を与える （たとえば、別々のサービスクラスを別々の LSP でサポートして別々に ルーティングする、すべてのサービスクラスを同じ LSP でサポートして 一緒にルーティングする、など）。

MPLS はパス指向であるため、トポロジ変更に直面した場合、従来のホップ バイホップルーティング IP システムよりも高速で予測可能な保護および 復旧能力を提供できる可能性がある。本文書では、このような能力を 「MPLS 保護」と呼ぶ。このような能力および関連する機構は本仕様の 範囲外であるが、それらは異なる LSP に対して異なるレベルの保護を 提供し得ることに留意する。ここで提示するソリューションは、サービス プロバイダが Diff-Serv サービスクラスを LSP にどのようにマッピング するかを選択できるようにするため、ソリューションはまた、異なる Diff-Serv サービスクラスに提供される保護のレベルについても柔軟性を 与える（たとえば、一部のサービスクラスは保護された LSP でサポート され、他のサービスクラスは保護されていない LSP でサポートされる、 など）。

さらに、本文書で規定するソリューションは、有用または必要な場合に のみ、所与の転送等価クラス (FEC) [MPLS_ARCH] に対して複数の LSP に 頼ることで、ラベル空間の節約を達成し、ラベルの確立/解除シグナリング の量を削減する。

本仕様は、MPLS ネットワーク上で転送される IPv4 および IPv6 トラフィ ックの両方に対する差別化サービスのサポートを可能にする。本文書は ユニキャストの運用のみを記述する。マルチキャストのサポートは今後の 課題である。

本文書で記述するソリューションは、MPLS 上で Diff-Serv と同時に 明示的輻輳通知 [ECN] をサポートするための EXP ビットのシグナリング または設定による使用を妨げない。ただし、MPLS 環境で ECN をサポート する技術は本文書の範囲外である。

1.1 用語 (Terminology)

本文書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 に記述されているとおりに解釈される。

読者は [MPLS_ARCH]、[MPLS_ENCAPS]、[MPLS_ATM]、[MPLS_FR] の用語に 精通しているものと仮定する。これには以下が含まれる。

  FEC        Forwarding Equivalency Class
             （転送等価クラス）

  FTN        FEC-To-NHLFE Map
             （FEC 対 NHLFE マップ）

  ILM        Incoming Label Map
             （入力ラベルマップ）

  LC-ATM     Label Switching Controlled-ATM (interface)
             （ラベルスイッチ制御 ATM インタフェース）

  LC-FR      Label Switching Controlled-Frame Relay (interface)
             （ラベルスイッチ制御フレームリレーインタフェース）

  LSP        Label Switched Path
             （ラベルスイッチパス）

  LSR        Label Switch Router
             （ラベルスイッチルータ）

  MPLS       Multi-Protocol Label Switching
             （マルチプロトコルラベルスイッチング）

  NHLFE      Next Hop Label Forwarding Entry
             （ネクストホップラベル転送エントリ）

読者は [DIFF_ARCH]、[DIFF_HEADER]、[DIFF_AF]、[DIFF_EF] の用語に 精通しているものと仮定する。これには以下が含まれる。

  AF         Assured Forwarding
             （保証転送）

  BA         Behavior Aggregate
             （ビヘイビアアグリゲート）

  CS         Class Selector
             （クラスセレクタ）

  DF         Default Forwarding
             （デフォルト転送）

  DSCP       Differentiated Services Code Point
             （差別化サービスコードポイント）

  EF         Expedited Forwarding
             （即時転送）

  PHB        Per Hop Behavior
             （パーホップビヘイビア）

読者は [DIFF_NEW] の用語に精通しているものと仮定する。これには 以下が含まれる。

  OA        Ordered Aggregate（順序付きアグリゲート）。
            順序付け制約を共有するビヘイビアアグリゲートの集合。

  PSC       PHB Scheduling Class（PHB スケジューリングクラス）。
            所与の OA に属するビヘイビアアグリゲートに適用される
            1 つ以上の PHB の集合。たとえば、AF1x は AF11、AF12、
            AF13 の PHB からなる PSC である。EF は単一の PHB
            （EF PHB）からなる PSC の例である。

次の頭字語も使用される。

  CLP        Cell Loss Priority
             （セル廃棄優先度）

  DE         Discard Eligibility
             （廃棄適格性）

  SNMP       Simple Network Management Protocol
             （簡易ネットワーク管理プロトコル）

最後に、本仕様で次の頭字語を定義する。

  E-LSP      EXP-Inferred-PSC LSP
             （EXP 推測 PSC LSP）

  L-LSP      Label-Only-Inferred-PSC LSP
             （ラベルのみ推測 PSC LSP）

1.2 EXP-Inferred-PSC LSPs (E-LSP)

単一の LSP を使用して、1 つ以上の OA をサポートできる。このような LSP は、これらの BA がいくつの OA にまたがるかに関係なく、所与の FEC の最大 8 つの BA をサポートできる。このような LSP では、MPLS シムヘッダの EXP フィールドが LSR によって使用され、パケットに 適用される PHB が決定される。これには PSC と廃棄優先順位の両方が 含まれる。

このような LSP を「EXP-Inferred-PSC LSP」(E-LSP) と呼ぶ。なぜなら、 この LSP 上で転送されるパケットの PSC は、そのパケットの EXP フィールド値に依存するからである。

所与のこのような LSP に対する EXP フィールドから PHB（すなわち PSC と廃棄優先順位）へのマッピングは、ラベル確立時に明示的にシグナリング されるか、または事前設定されたマッピングに依存する。

E-LSP の詳細な運用は、以下の第 3 節で規定する。

1.3 Label-Only-Inferred-PSC LSPs (L-LSP)

単一の <FEC, OA> ペアに対して別の LSP を確立できる。このような LSP では、PSC はラベル確立時に明示的にシグナリングされるため、ラベル 確立後、LSR はラベル値のみからラベル付きパケットに適用される PSC を推測できる。シムヘッダが使用される場合、LSR がラベル付きパケット に適用する廃棄優先順位は、EXP フィールドを使用してラベル付き パケットの MPLS シムヘッダ内で伝達される。シムヘッダが使用されない 場合（たとえば MPLS Over ATM）、LSR がラベル付きパケットに適用する 廃棄優先順位は、リンク層固有の廃棄優先順位フィールド（たとえば ATM CLP）を使用してリンク層ヘッダカプセル化内で伝達される。

このような LSP を「Label-Only-Inferred-PSC LSP」(L-LSP) と呼ぶ。 なぜなら、PSC は他の情報なしで（たとえば EXP フィールド値に関係 なく）ラベルから完全に推測できるからである。L-LSP の詳細な運用は、 以下の第 4 節で規定する。

1.4 全体的な運用 (Overall Operations)

所与の FEC について、以下の第 7、8、9 節で識別されるメディア固有の 制限が適用されない限り、本仕様は MPLS Diff-Serv ドメイン内で次の いずれかの組み合わせを許可する。

  -  ゼロ個または任意の数の E-LSP、および

  -  ゼロ個または任意の数の L-LSP。

ネットワーク管理者は、許可された組み合わせの集合から実際の LSP の 組み合わせを選択し、ビヘイビアアグリゲートがこの LSP の組み合わせ 上で実際にどのように転送されるかを選択し、Diff-Serv サポート、 トラフィックエンジニアリング、および MPLS 保護の観点から自身の 環境と目標に最も適合させる。このような組み合わせを選択するための 基準は本仕様の範囲外である。

所与の FEC について、同じ OA を運ぶ LSP が複数存在し得る。たとえば OA の負荷分散のためである。ただし、順序付け制約を尊重するために、 所与の順序付きアグリゲートの複数の BA にまたがる可能性のある所与の マイクロフローのすべてのパケットは、同じ LSP 上で転送されなければ ならない (MUST)。逆に、各 LSP は所与の OA のすべての（アクティブな） BA をサポートできなければならない (MUST)。

展開シナリオの例は、情報として付録 A に提供する。

1.5 ラベルと FEC の関係 (Relationship between Label and FEC)

[MPLS_ARCH] は「2.1. Overview」節で次のように述べている。「一部の ルータは、パケットのネクストホップを選択するためだけでなく、 パケットの「優先順位」または「サービスクラス」を決定するためにも パケットのネットワーク層ヘッダを分析する。その後、異なるパケットに 異なる廃棄しきい値またはスケジューリング規律を適用し得る。MPLS は、 優先順位またはサービスクラスをラベルから完全または部分的に推測 することを許可する（ただし要求はしない）。この場合、ラベルは FEC と 優先順位またはサービスクラスの組み合わせを表すと言うことができる。」

これに沿って、次のことを観察する。

• E-LSP では、ラベルは FEC と E-LSP 上で転送される BA の集合の 組み合わせを表す。サポートされるすべての BA が E-LSP 上で転送 される場合、ラベルは完全な FEC を表す。

• L-LSP では、ラベルは FEC と OA の組み合わせを表す。

1.6 E-LSP および L-LSP の帯域予約 (Bandwidth Reservation for E-LSPs and L-LSPs)

どのラベルバインディングプロトコルが使用されるかに関係なく、E-LSP および L-LSP は帯域予約ありまたはなしで確立できる。

帯域予約ありで E-LSP または L-LSP を確立するとは、LSP の帯域要件が LSP 確立時にシグナリングされることを意味する。このようなシグナリング された帯域要件は、LSR が確立時に、関連する PSC のためにプロビジョ ニングされた（たとえば設定、SNMP、またはポリシープロトコル経由） Diff-Serv リソース上でシグナリングされた LSP のアドミッション 制御を実行するために使用し得る。このようなシグナリングされた帯域 要件はまた、LSR が確立時に、関連する PSC に関連付けられた Diff-Serv リソースの調整（たとえば PSC スケジューリング重みの調整）を実行 するために使用し得る。

帯域予約ありで E-LSP または L-LSP を確立することは、LSP ごとの スケジューリングが必要であることを意味しないことに留意する。E-LSP および L-LSP は本文書で差別化サービスのサポートのために規定されて いるため、必要な転送処理（スケジューリングおよび廃棄ポリシー）は 適切な Diff-Serv PHB によって定義される。この転送処理は、LSR に よって BA の粒度で適用されなければならず (MUST)、関連する PHB 仕様に準拠していなければならない (MUST)。

L-LSP の確立時に帯域要件がシグナリングされる場合、シグナリング された帯域は明らかに L-LSP の PSC に関連付けられる。したがって、 シグナリングされた帯域を使用してアドミッション制御を実行する LSR は、PSC に専用の Diff-Serv リソース上で（たとえばそのスケジュー リング重みによって PSC に保証された帯域上で）アドミッション制御を 実行し得る。

E-LSP の確立時に帯域要件がシグナリングされる場合、シグナリング された帯域は LSP 全体、したがって転送される PSC の集合に集合的に 関連付けられる。したがって、シグナリングされた帯域を使用して アドミッション制御を実行する LSR は、PSC の集合によって共有される グローバルリソース上で（たとえばリンクの総帯域上で）アドミッション 制御を実行し得る。

帯域予約が使用されないシナリオおよび帯域予約が使用されるシナリオ の例は、情報として付録 B に提供する。

2. Diff-Serv LSR のラベル転送モデルとトンネリングモデル (Label Forwarding Model for Diff-Serv LSRs and Tunneling Models)

2.1 Diff-Serv LSR のラベル転送モデル (Label Forwarding Model for Diff-Serv LSRs)

所与の FEC の異なる順序付きアグリゲートが異なる LSP 上で転送され得る ため、Diff-Serv LSR のラベルスワッピング決定は、転送されるパケットの ビヘイビアアグリゲートに明確に依存する。また、転送されるパケットの IP DS フィールドが LSR に直接可視でない場合があるため、受信パケット に適用する PHB を決定し、送信パケットに PHB をエンコードする方法は、 非 MPLS Diff-Serv ルータとは異なる。

したがって、Diff-Serv LSR によるラベル転送を記述するために、次の 4 つの段階からなる LSR Diff-Serv ラベルスイッチング動作をモデル化 する。

• 入力 PHB の決定 (Incoming PHB Determination) (A)

• オプションのトラフィック調整を伴う出力 PHB の決定 (Outgoing PHB Determination with Optional Traffic Conditioning) (B)

• ラベル転送 (Label Forwarding) (C)

• カプセル化層への Diff-Serv 情報のエンコーディング (Encoding of Diff-Serv information into Encapsulation Layer) (EXP、CLP、DE、User_Priority) (D)

各段階は、以下の節でより詳細に記述する。

当然ながら、Diff-Serv のサービス差別化を実施するために、LSR は 出力 PHB に対応する転送処理も適用しなければならない (MUST)。

このモデルを以下に図示する。

--Inc_label(s)()------------------------>I===I--Outg_label(s)(&)--> \ I I
---->I===I I C I -->I===I--Encaps-> I A I I===I--Outg_PHB->I===I I D I (&) -Encaps->I===I--Inc_PHB->I B I \ /->I===I () I===I --------+ ----Forwarding--> Treatment (PHB)

"Encaps" は、MPLS カプセル化層にエンコードされた Diff-Serv 関連情報 （たとえば EXP フィールド、ATM CLP、フレームリレー DE、802.1 User_Priority）を示す。

(*) LSR が MPLS 入力ノードとして動作する場合、入力パケットは ラベルなしで受信され得る。

(&) LSR が MPLS 出力ノードとして動作する場合、出力パケットは ラベルなしで送信され得る。

このモデルは、Diff-Serv LSR の機能的な運用を記述するためにここに 提示するものであり、実際の実装を制約するものではない。

2.2 入力 PHB の決定 (Incoming PHB Determination)

この段階は、受信したパケットがどのビヘイビアアグリゲートに属するかを 決定する。

2.2.1 ラベルスタックエントリを考慮した入力 PHB の決定 (Incoming PHB Determination Considering a Label Stack Entry)

第 3.3 節および第 4.3 節は、入力 LSP タイプおよび入力 MPLS カプセル 化に応じて、所与の受信ラベルスタックエントリおよび/または受信入力 MPLS カプセル化情報を考慮して入力 PHB の決定を実行する方法の詳細を 提供する。

第 2.6 節は、サポートされる Diff-Serv トンネリングモードに応じて、 入力 PHB の決定のためにどのラベルスタックエントリを考慮するかの 詳細を提供する。

2.2.2 IP ヘッダを考慮した入力 PHB の決定 (Incoming PHB Determination Considering IP Header)

第 2.6 節は、サポートされる Diff-Serv トンネリングモデルに応じて、 入力 PHB の決定のために IP ヘッダをいつ考慮するかの詳細を提供する。 IP ヘッダを使用する場合、この段階は非 MPLS IP Diff-Serv ルータと 全く同様に動作し、DS フィールドを使用して入力 PHB を決定する。

2.3 オプションのトラフィック調整を伴う出力 PHB の決定 (Outgoing PHB Determination With Optional Traffic Conditioning)

トラフィック調整段階はオプションであり、LSR 上でビヘイビア アグリゲートの降格 (demotion) または昇格 (promotion) を含む トラフィック調整を実行するために使用し得る。これは本仕様の範囲外 である。MPLS 上の Diff-Serv 転送を規定する目的のために、LSR に よって実際に実施され、ダウンストリーム LSR に伝達される PHB （「出力 PHB」と呼ぶ）は、前の LSR によってパケットに関連付けられて いた PHB（「入力 PHB」と呼ぶ）と異なる場合があることに単純に留意 する。

トラフィック調整段階が存在しない場合、「出力 PHB」は「入力 PHB」と 単純に同一である。

2.4 ラベル転送 (Label Forwarding)

[MPLS_ARCH] は、各入力ラベルが 1 つまたは複数の NHLFE にマップ される入力ラベルマップ (ILM) を使用して、LSR が入力ラベル付き パケットに対してラベルスワッピングをどのように実行するかを記述 している。[MPLS_ARCH] はまた、各入力 FEC が 1 つまたは複数の NHLFE にマップされる FEC-to-NHLFEs マップ (FTN) を使用して、LSR が入力 ラベルなしパケットに対してラベル付加をどのように実行するかも記述 している。

ラベルの Diff-Serv コンテキストは、次から構成される。

• `LSP type (i.e., E-LSP or L-LSP)' （LSP タイプ、すなわち E-LSP または L-LSP）

• `supported PHBs' （サポートされる PHB）

• 入力ラベルの `Encaps-->PHB mapping'

• 出力ラベルの `Set of PHB-->Encaps mappings'

本仕様は、各入力ラベルについて Diff-Serv コンテキストが ILM に 格納されることを定義する。

[MPLS_ARCH] は、「NHLFE はまた、パケットを適切に処理するために 必要な他の任意の情報を含み得る」と述べている。これに従って、本仕様 は、スワップまたはプッシュされる各出力ラベルについて Diff-Serv コンテキストが NHLFE に格納されることを定義する。

この Diff-Serv コンテキスト情報は、ラベル確立時に ILM および FTN に設定される。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされていない E-LSP に対応する場合、supported PHBs' は、以下の第 3.2.1 節で議論する事前設定 `EXP<-->PHB mapping' の PHB の集合で設定される。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされた E-LSP に対応する場合、supported PHBs' は、 シグナリングされた `EXP<-->PHB mapping' の PHB の集合で設定される。

ラベルが L-LSP に対応する場合、`supported PHBs' は、LSP セットアップ 時にシグナリングされる PSC を形成する PHB の集合で設定される。

Encaps-->PHB mapping' または Set of PHB-->Encaps mappings' が どのように設定されるかの詳細は、以下の第 3 節および第 4 節で定義 する。

[MPLS_ARCH] はまた次のように述べている。

「ILM [それぞれ FTN] が特定のラベルを 2 つ以上の要素を含む NHLFE の集合にマップする場合、パケットが転送される前に集合のちょうど 1 つ の要素が選択されなければならない。集合から要素を選択する手順は 本文書の範囲外である。ILM [それぞれ FTN] がラベル [それぞれ FEC] を 2 つ以上の NHLFE を含む集合にマップすることは、たとえば複数の 等コストパス上で負荷分散を行うことが望ましい場合に有用であり得る。」

これに従って、本仕様は、入力ラベル [それぞれ FEC] が Diff-Serv の 目的で複数の NHLFE にマップされ得ることを許可する（たとえば、異なる NHLFE が異なる PHB の集合をサポートする出力ラベルに対応する場合）。 ラベル [それぞれ FEC] が複数の NHLFE にマップする場合、Diff-Serv LSR は、その Diff-Serv コンテキストが転送されるパケットの出力 PHB をサポートすることを示す NHLFE の 1 つを選択しなければならない (MUST)。

ラベル [それぞれ FEC] が出力 PHB をサポートする複数の NHLFE に マップする場合、それらの中から 1 つを選択する手順は本文書の範囲外 である。この状況は、ビヘイビアアグリゲートを複数の LSP 上で負荷分散 することが望ましい場合に遭遇し得る。そのような状況では、順序付け 制約を尊重するために、所与のマイクロフローのすべてのパケットは 同じ LSP 上で転送されなければならない (MUST)。

2.5 カプセル化層への Diff-Serv 情報のエンコーディング (Encoding Diff-Serv Information Into Encapsulation Layer)

この段階は、送信パケット内で Diff-Serv 情報を伝達するフィールド （たとえば MPLS シム EXP、ATM CLP、フレームリレー DE、802.1 User_Priority）をどのようにエンコードするかを決定する。

2.5.1 送信ラベルエントリへの Diff-Serv 情報のエンコーディング (Encoding Diff-Serv Information Into Transmitted Label Entry)

第 3.5 節および第 4.5 節は、対応する出力 LSP タイプおよび MPLS カプセル化に応じて、所与の送信ラベルスタックエントリおよび/または 送信 MPLS カプセル化情報への Diff-Serv 情報エンコーディングを 実行する方法の詳細を提供する。

第 2.6 節は、サポートされる Diff-Serv トンネリングモードに応じて、 どのラベルスタックエントリで Diff-Serv 情報エンコーディングを 実行するかの詳細を提供する。

2.5.2 送信 IP ヘッダへの Diff-Serv 情報のエンコーディング (Encoding Diff-Serv Information Into Transmitted IP Header)

送信パケットの IP ヘッダへの Diff-Serv 情報エンコーディングを 実行するために、この段階は非 MPLS IP Diff-Serv ルータと全く同様に 動作し、出力 PHB の DSCP を DS フィールドにエンコードする。

第 2.6 節は、サポートされる Diff-Serv トンネリングモードに応じて、 Diff-Serv 情報エンコーディングが送信 IP ヘッダに対していつ実行 されるかの詳細を提供する。

2.6 MPLS 上の Diff-Serv トンネリングモデル (Diff-Serv Tunneling Models over MPLS)

2.6.1 Diff-Serv トンネリングモデル (Diff-Serv Tunneling Models)

[DIFF_TUNNEL] は、差別化サービスとさまざまな形式の IP トンネルとの 相互作用について考察している。MPLS カプセル化ヘッダに IP ヘッダが 含まれていないため、MPLS LSP は「IP トンネル」の一種ではなく、 したがって MPLS LSP は [DIFF_TUNNEL] では考慮されていない。ただし、 MPLS LSP は「IP トンネル」の一種ではないが、「トンネル」の一種で ある。

Diff-Serv の観点から、LSP は IP トンネルと多くの共通の特性を共有 する。

• 中間ノード（すなわち LSP スパンのどこかにあるノード）は、「外側」 の Diff-Serv 情報のみを見て操作する。

• LSP は単方向である。

• 「外側」の Diff-Serv 情報は、中間ノードのいずれでも変更できる。

ただし、Diff-Serv の観点から、LSP は IP トンネルと比較して際立った 特性も持つ。

• 一般に、IP トンネルで使用される最終ホップポップ (PHP) に類似 した動作はない。さらに、PHP の結果、LSP に関連付けられた 「外側」の Diff-Serv 情報が LSP 出力に可視でなくなる。この情報が LSP 出力で意味を持たない状況では、これは明らかに全く問題では ない。この情報が LSP 出力で意味を持つ状況では、それは何らかの 他の手段で運ばれなければならない。

[DIFF_TUNNEL] で定義された IP トンネル上の Diff-Serv トンネリング の 2 つの概念モデルは、MPLS 上の Diff-Serv にも適用可能で有用で あるが、それぞれの詳細な運用は MPLS 上ではやや異なる。これら 2 つの モデルはパイプモデル (Pipe Model) とユニフォームモデル (Uniform Model) である。MPLS 上でのそれらの運用は、以下の節で規定する。 代替トンネリングモデルの議論および定義は本仕様の範囲外である。

2.6.2 パイプモデル (Pipe Model)

パイプモデルでは、MPLS トンネル（すなわち LSP）を使用して、 Diff-Serv の観点から LSP 入力と出力の間の中間 MPLS ノードを隠す。

このモデルでは、トンネル化されたパケットは 2 つの意味のある Diff-Serv 情報を伝達しなければならない。

• LSP 出力を含む LSP スパン上の中間ノードにとって意味のある Diff-Serv 情報（これを「LSP Diff-Serv 情報」と呼ぶ）。この LSP Diff-Serv 情報は LSP 出力を越えて意味を持たない。LSP スパン上の中間ノードでのトラフィック調整が LSP Diff-Serv 情報に影響するかどうかにかかわらず、この更新された Diff-Serv 情報は LSP 出力を越えて意味があるとは見なされず、無視される。

• LSP 出力を越えて意味のある Diff-Serv 情報（これを「トンネル Diff-Serv 情報」と呼ぶ）。この情報は LSP 入力から LSP 出力へ 伝達される。この Diff-Serv 情報は LSP スパン上の中間ノードに とっては意味を持たない。

PHP なしのパイプモデルの運用を以下に図示する。

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E (M*)

(M) は「LSP Diff-Serv 情報」を表す (m) は「トンネル Diff-Serv 情報」を表す (*) LSP 出力は、その Diff-Serv 転送処理（すなわち実際の PHB）を 適用するために、外側ヘッダで受信した LSP Diff-Serv 情報 （すなわちポップの前）を考慮する I は LSP 入力ノードを表す E は LSP 出力ノードを表す

パイプモデルでは、「LSP Diff-Serv 情報」は、LSP 出力がそれに基づいて 転送処理を適用するために、LSP 出力に伝達される必要がある。「トンネル Diff-Serv 情報」もまた、さらにダウンストリームに伝達できるように LSP 出力に伝達される必要がある。

両方が Diff-Serv 情報が LSP 出力に伝達されることを要求するため、 パイプモデルは PHP なしでのみ動作する。

パイプモデルは、次のような環境に特に適している。

• LSP 入力の入力インタフェースの上流のクラウドと LSP 出力の出力 インタフェースの下流のクラウドが、共通の Diff-Serv サービス プロビジョニングポリシーおよび PHB 定義の集合を使用する Diff-Serv ドメインにあり、一方 LSP は異なる Diff-Serv サービス プロビジョニングポリシーおよび PHB 定義の集合を使用する 1 つ （または複数）の Diff-Serv ドメインにまたがる

• LSP 出力の出力インタフェースが、LSP がまたがる（最後の） Diff-Serv ドメインにある。

例として、サービスプロバイダが Diff-Serv 差別化を含む MPLS VPN サービスを提供している場合を考える（MPLS VPN アーキテクチャの例に ついては [MPLS_VPN] を参照）。そのような MPLS VPN サービス経由で サイトの集合が相互接続されているとする。このサイトの集合が共通の 管理下で管理され、Diff-Serv サービス差別化もサポートしているとする。 VPN サイト管理とサービスプロバイダが全く同じ Diff-Serv ポリシーを 共有していない場合（たとえば同じ数の PHB をサポートしていない場合）、 MPLS VPN サービス上でのパイプモデルでの Diff-Serv の運用により、 VPN サイトの Diff-Serv ポリシーが入力 VPN サイトおよび出力 VPN サイト全体で一貫して動作し、サービスプロバイダの Diff-Serv ドメイン 上で透過的に動作することを可能にする。そのような LSP は、物理的に 中間ネットワークノードによって分離されていてもエンドポイントを 事実上隣接させることにより、エンドポイントの Diff-Serv ドメインを 単一の Diff-Serv リージョンにリンクするものと見なすと有用であり 得る。

パイプモデルはサポートされなければならない (MUST)。

所与の LSP 上で PHP なしのパイプモデルをサポートするために、LSR は 次の方法で入力 PHB の決定および Diff-Serv 情報のエンコーディングを 実行する。

• ラベルなしパケットを受信する場合、LSR は受信した IP ヘッダを 考慮して入力 PHB の決定を実行する。

• ラベル付きパケットを受信する場合、LSR は受信したラベルスタック 内の外側ラベルエントリを考慮して入力 PHB の決定を実行する。 特に、対象の LSP に対してポップ操作が実行される場合、LSR は ポップの前に入力 PHB の決定を実行する。

• 対象の LSP に対してプッシュ操作を実行する場合、LSR は次を行う。

  o プッシュされたラベルに対応する送信ラベルエントリに、出力 PHB に対応する Diff-Serv 情報をエンコードする。

  o カプセル化されたヘッダ（スワップされたラベルエントリまたは IP ヘッダ）に、入力 PHB に対応する Diff-Serv 情報を エンコードする。

• 対象の LSP に対してスワップのみの操作を実行する場合、LSR は スワップされたラベルを含む送信ラベルエントリに Diff-Serv 情報 をエンコードする。

• 対象の LSP に対してポップ操作を実行する場合、LSR はポップ操作 によって露出したヘッダへの Diff-Serv 情報のエンコーディングを 実行しない（すなわち LSR は露出したヘッダを「そのまま」残す）。

2.6.2.1 ショートパイプモデル (Short Pipe Model)

ショートパイプモデルは、上記で記述したパイプモデルのオプションの 変形である。唯一の違いは、ショートパイプモデルでは、LSP 出力での Diff-Serv 転送処理が、「LSP Diff-Serv 情報」（すなわちカプセル化 ヘッダで伝達される Diff-Serv 情報）ではなく「トンネル Diff-Serv 情報」（すなわちカプセル化されたヘッダで伝達される Diff-Serv 情報） に基づいて適用されることである。

PHP なしのショートパイプモデルの運用を以下に図示する。

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E

(M) は「LSP Diff-Serv 情報」を表す (m) は「トンネル Diff-Serv 情報」を表す I は LSP 入力ノードを表す E は LSP 出力ノードを表す

LSP 出力は「トンネル Diff-Serv 情報」に基づいて転送処理を適用する ため、「LSP Diff-Serv 情報」は最終ノードから LSP 出力に伝達される 必要がない。したがって、ショートパイプモデルは PHP でも動作できる。

PHP ありのショートパイプモデルの運用を以下に図示する。

       =========== LSP ============================>

            ---Swap--(M)--...--Swap------
           /       (outer header)        \
         (M)                             (M)
         /                                 \

--(m)-Push.................(m).............Pop-(m)--E--(m)--> I (inner header) P (M*)

(M) は「LSP Diff-Serv 情報」を表す (m) は「トンネル Diff-Serv 情報」を表す (*) 最終 LSR は、その Diff-Serv 転送処理（すなわち実際の PHB）を 適用するために、外側ヘッダで受信した LSP Diff-Serv 情報 （すなわちポップの前）を考慮する I は LSP 入力ノードを表す P は LSP 最終ノードを表す E は LSP 出力ノードを表す

ショートパイプモデルは、次のような環境に特に適している。

• LSP 入力の入力インタフェースの上流のクラウドと LSP 出力の出力 インタフェースの下流のクラウドが、共通の Diff-Serv サービス プロビジョニングポリシーおよび PHB 定義の集合を使用する Diff-Serv ドメインにあり、一方 LSP は異なる Diff-Serv サービス プロビジョニングポリシーおよび PHB 定義の集合を使用する 1 つ （または複数）の Diff-Serv ドメインにまたがる

• LSP 出力の出力インタフェースが、その下流のクラウドと同じ Diff-Serv ドメインにある。

LSP 出力の各出力インタフェースは、その下流のクラウドと同じ Diff-Serv ドメインにあるため、各出力インタフェースは潜在的に異なる Diff-Serv ドメインにあり得、LSP 出力は対応するすべての Diff-Serv ポリシーを認識して設定される必要がある。この運用上のオーバーヘッド は、LSP スパン上で使用される共通の Diff-Serv ポリシーよりも、各 出力インタフェース上でのサービス差別化を提供するのにそれぞれの 下流 Diff-Serv ポリシーの方が適している状況で正当化される。その ような状況の例は、サービスプロバイダが MPLS VPN サービスを提供し、 一部の VPN ユーザが、サービスプロバイダの Diff-Serv ポリシーでは なく、自身の VPN Diff-Serv ポリシーを、LSP 出力から宛先 VPN サイトへの専用リンク上でのサービス差別化の制御に適用することを 要求する場合である。

ショートパイプモデルはサポートされ得る (MAY)。

所与の LSP 上で PHP なしのショートパイプモデルをサポートするために、 LSR は、次の例外を除き、パイプモデルと同じ方法で入力 PHB の決定 および Diff-Serv 情報のエンコーディングを実行する。

• ラベル付きパケットを受信する場合、LSR は実際の転送に使用される ヘッダ（ラベルエントリまたは IP ヘッダ）を考慮して入力 PHB の 決定を実行する。特に、対象の LSP に対してポップ操作が実行される 場合、LSR はポップの後に入力 PHB の決定を実行する。

所与の LSP 上で PHP ありのショートパイプモデルをサポートするために、 LSR は、次の例外を除き、PHP なしの場合と同じ方法で入力 PHB の決定 および Diff-Serv 情報のエンコーディングを実行する。

• 最終 LSR は、受信したラベルスタック内の外側ラベルエントリを 考慮して入力 PHB の決定を実行する。言い換えれば、対象の LSP に対してポップ操作が実行される場合、最終 LSR はポップの前に 入力 PHB の決定を実行する。

ショートパイプモードで PHP ありの最終 LSR の動作は、パイプモード （必然的に PHP なし）の LSP 出力の動作と同一であることに留意する。

2.6.3 ユニフォームモデル (Uniform Model)

ユニフォームモデルでは、MPLS トンネル（すなわち LSP）は Diff-Serv の観点からエンドツーエンドパスのアーティファクトと見なされる。 MPLS トンネルは転送目的で使用され得るが、Diff-Serv に重大な影響を 与えない。このモデルでは、任意のパケットはちょうど 1 つの意味の ある Diff-Serv 情報を含み、それは常に最も外側のラベルエントリに （または、たとえば LSP の出力で IP パケットがラベルなしで送信 される場合は IP DSCP に）エンコードされる。他のどこか（たとえば より深いラベルエントリ）にエンコードされた Diff-Serv 情報は、 中間ノードまたはトンネル出力にとって意味がなく、無視される。LSP スパン上の中間ノードでのトラフィック調整が「外側」の Diff-Serv 情報に影響する場合、更新された Diff-Serv 情報が LSP の出力で 意味があるものと見なされる。

PHP なしのユニフォームモデルの運用を以下に図示する。

         ========== LSP =============================>

             ---Swap--(M)--...-Swap--(M)--Swap----
            /         (outer header)              \
          (M)                                     (M)
          /                                         \

--(M)--Push...............(x).......................Pop--(M)-> I (inner header) E

(M) は対応するヘッダにエンコードされた意味のある Diff-Serv 情報 を表す。 (x) は意味のない Diff-Serv 情報を表す。 I は LSP 入力ノードを表す E は LSP 出力ノードを表す

PHP ありのユニフォームモデルの運用を以下に図示する。

         ========== LSP =========================>

             ---Swap-(M)-...-Swap------
            /        (outer header)    \
          (M)                          (M)
          /                              \

--(M)--Push..............(x)............Pop-(M)--E--(M)-> I (inner header) P

(M) は対応するヘッダにエンコードされた意味のある Diff-Serv 情報 を表す。 (x) は意味のない Diff-Serv 情報を表す。 I は LSP 入力ノードを表す P は LSP 最終ノードを表す E は LSP 出力ノードを表す

MPLS 上の Diff-Serv のユニフォームモデルは、Diff-Serv の観点から、 運用が MPLS が使用されなかった場合の運用と全く同一になるような ものである。言い換えれば、MPLS は Diff-Serv 運用に対して完全に 透過的である。

ユニフォームモデルの使用により、意味のある Diff-Serv 情報が常に 最も外側のラベルエントリで可視かつ変更可能であるため、Diff-Serv ドメイン境界の物理的境界における「外側」ヘッダのみで動作する ドメイン間トラフィック調整合意以外の措置なしに、LSP が Diff-Serv ドメイン境界にまたがることを可能にする。

ユニフォームモデルはサポートされ得る (MAY)。

所与の LSP 上でユニフォームモデルをサポートするために、LSR は 次の方法で入力 PHB の決定および Diff-Serv 情報のエンコーディング を実行する。

• ラベルなしパケットを受信する場合、LSR は受信した IP ヘッダを 考慮して入力 PHB の決定を実行する。

• ラベル付きパケットを受信する場合、LSR は受信したラベルスタック 内の外側ラベルエントリを考慮して入力 PHB の決定を実行する。 特に、対象の LSP に対してポップ操作が実行される場合、LSR は ポップの前に入力 PHB の決定を実行する。

• 対象の LSP に対してプッシュ操作を実行する場合、LSR はプッシュ されたラベルに対応する送信ラベルエントリに Diff-Serv 情報を エンコードする。カプセル化されたヘッダ（スワップされたラベル エントリまたは IP ヘッダ）にエンコードされた Diff-Serv 情報は 重要ではない。

• 対象の LSP に対してスワップのみの操作を実行する場合、LSR は スワップされたラベルを含む送信ラベルエントリに Diff-Serv 情報 をエンコードする。

• PHP が使用される場合、最終 LSR は Diff-Serv 情報エンコーディング を実行するために、露出したヘッダに対応するラベルの「Set of PHB-->Encaps mappings」（または `PHB-->DSCP mapping'）を認識 する必要がある。このマッピング認識を提供する方法は本仕様の 範囲外である。例として、「PHB-->DSCP mapping」はローカルに 設定され得る。別の例として、一部の環境では、最終 LSR が、露出 したヘッダ内の出力ラベルに使用される「Set of PHB-->Encaps mappings」が、LSR が PHP を行わなかった場合に LSR が使用する であろう「Set of PHB-->Encaps mappings」であると仮定することが 適切であり得る。また、本仕様は、最終 LSR がポップ操作によって 露出したラベルエントリ上でラベルスワッピングを実行しない （実際には露出したラベルを見ることさえしない）と仮定することに も留意する。その結果、最終 LSR が実行できる Diff-Serv 情報 エンコーディングに制限が適用され得る。たとえば、本仕様は、 最終 LSR が 2 つの PSC をサポートする E-LSP に対応するラベル をポップし、ポップによって露出したヘッダがそれぞれ 1 つの PSC をサポートする 2 つの L-LSP のラベル値を含む状況を許可 しない。なぜなら、Diff-Serv 情報エンコーディングは一方または 他方のラベルを選択することを要求するからである。

パイプ、ショートパイプ、およびユニフォームモデルの LSR 動作は、 プッシュまたはポップを行う場合にのみ異なることに留意する。したがっ て、LSP に対してスワップのみの操作を実行する中間 LSR は、パイプ、 ショートパイプ、またはユニフォームモデルのいずれで動作しているか に関係なく、全く同じ方法で動作する。複数のトンネリングモデルを サポートする Diff-Serv 実装では、LSP 入力、最終 LSR、または LSP 出力として動作する LSR のみが、特定のモデルで動作するように設定 される必要がある。LSP ごとに Diff-Serv トンネリングモデルを関連 付けるシグナリングは本仕様の範囲内ではない。

2.6.4 階層 (Hierarchy)

ラベルスタック機構により、MPLS は LSP トンネリングを任意の深さに ネストすることを可能にする。このようなネストでは、レベル N+1 の プッシュはレベル N のプッシュを行う LSR の後続の（または同じ） LSR で行われ、レベル N+1 のポップはレベル N のポップを行う LSR の前の（または同じ）LSR で行われることを観察する。所与のレベル N の LSP について、プッシュを行う入力 LSR とポップを行う LSR （最終 LSR または LSP 出力）は同じトンネリングモデル（すなわち パイプ、ショートパイプ、またはユニフォーム）で動作しなければ ならない。ただし、レベル間で一貫したトンネリングモデルの要件は なく、異なるレベルの LSP は異なるトンネリングモデルで動作し得る。

2 レベルのトンネルの場合の階層的運用を以下に図示する。

           +--------Swap--...---+
          /    (outmost header)  \
         /                        \
       Push(2).................(2)Pop
       / (outer header)             \
      /                              \

---Push(1)........................(1)Pop-->> (inner header)

(1) トンネリングモデル 1 (2) トンネリングモデル 2

トンネリングモデル 2 はトンネリングモデル 1 と同じであるか、または 異なり得る。

所与のレベル N の LSP について、LSR は、このレベル N の LSP の トンネリングモデルに従って、他のレベルの LSP のトンネリングモデル とは独立に、第 2.6.2、2.6.2.1、および 2.6.3 節で規定されている とおりに入力 PHB の決定および Diff-Serv 情報のエンコーディングを 実行しなければならない。

3. E-LSP の詳細な運用 (Detailed Operations of E-LSPs)

3.1 E-LSP の定義 (E-LSP Definition)

E-LSP は第 1.2 節で定義されている。

所与の MPLS Diff-Serv ドメイン内で、事前設定マッピングに依存する すべての E-LSP は、同じ共通の 8 個以下の BA の集合を転送できる。 これらの E-LSP のそれぞれは、実際にこの BA の完全な集合、または その任意の部分集合を転送し得る。

所与の FEC について、シグナリングされた `EXP<-->PHB mapping' を 使用する 2 つの所与の E-LSP は、同じまたは異なる順序付きアグリ ゲートの集合をサポートできる。

3.2 入力 E-LSP の Encaps-->PHB mapping' の設定 (Populating the Encaps-->PHB mapping' for an incoming E-LSP)

本節は、入力 PHB の決定を可能にするために、入力 E-LSP について Diff-Serv コンテキストの `Encaps-->PHB mapping' がどのように設定 されるかを定義する。

E-LSP の Encaps-->PHB mapping' は常に EXP-->PHB mapping' の形式 である。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされていない E-LSP に対応する場合、EXP-->PHB mapping' は、以下の第 3.2.1 節で議論する事前設定 `EXP<-->PHB mapping' に基づいて設定される。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされた E-LSP に対応する場合、EXP-->PHB mapping' は シグナリングされた `EXP<-->PHB mapping' に従って設定される。

3.2.1 事前設定 EXP<-->PHB mapping' (Preconfigured EXP<-->PHB mapping')

事前設定 EXP<-->PHB mapping' を使用する E-LSP をサポートする LSR は、この EXP<-->PHB mapping' のローカル設定を許可しなければ ならない。このマッピングは、セットアップ時にマッピングが明示的に シグナリングされずにこの LSR 上で確立されたすべての E-LSP に 適用される。

事前設定 `EXP<-->PHB mapping' は、LSP がまたがる MPLS Diff-Serv ドメイン全体のすべての E-LSP ホップで一貫していなければならないか、 または入力および出力インタフェースで異なる事前設定マッピングが 使用される場合は常に、LSR によって EXP フィールドの適切な再マー キングが実行されなければならない。

事前設定 EXP<-->PHB mapping' が実際にネットワーク管理者によって 設定されていない場合、LSR はすべての EXP 値をデフォルト PHB に マップするデフォルトの事前設定 EXP<-->PHB mapping' を使用する べきである (should)。

3.3 入力 E-LSP 上での入力 PHB の決定 (Incoming PHB Determination On Incoming E-LSP)

本節は、受信したラベルスタック内の対象ラベルエントリが E-LSP に 対応する場合に、入力 PHB の決定がどのように実行されるかを定義する。 これには、`Encaps-->PHB mapping' が第 3.2 節で定義されているとおり に設定されていることが必要である。

入力 PHB の決定のために入力 E-LSP に対応するラベルエントリを考慮 する場合、LSR は次を行う。

• 対象の入力 E-LSP ラベルに ILM で関連付けられた Diff-Serv コンテキストの Encaps-->PHB mapping' をルックアップすること により、EXP-->PHB mapping' を決定する。

• `EXP-->PHB mapping' テーブル内で対象ラベルエントリの EXP フィールドをルックアップすることにより、入力 PHB を決定する。

3.4 出力 E-LSP の Set of PHB-->Encaps mappings' の設定 (Populating the Set of PHB-->Encaps mappings' for an outgoing E-LSP)

本節は、カプセル化層への Diff-Serv 情報のエンコーディングを可能に するために、出力 E-LSP についてラベルセットアップ時に Diff-Serv コンテキストの `Set of PHB-->Encaps mappings' がどのように設定 されるかを定義する。

3.4.1 `PHB-->EXP mapping'

出力 E-LSP は、その Diff-Serv コンテキストの Set of PHB-->Encaps mappings' の一部として、常に PHB-->EXP mapping' を持たなければ ならない。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされていない E-LSP に対応する場合、この PHB-->EXP mapping' は、上記の第 3.2.1 節で議論した事前設定 `EXP<-->PHB mapping' に基づいて設定される。

ラベルが、LSP セットアップ時に EXP<-->PHB mapping' が明示的に シグナリングされた E-LSP に対応する場合、PHB-->EXP mapping' は シグナリングされた `EXP<-->PHB mapping' に従って設定される。

3.4.2 `PHB-->CLP mapping'

LSP がラベルスイッチ制御されていない ATM インタフェース上で出力 する場合、この出力 LSP の Set of PHB-->Encaps mappings' に 1 つ の PHB-->CLP mapping' が追加される。この `PHB-->CLP mapping' は 次の方法で設定される。

• それはこの LSP 上でサポートされる PHB の関数であり、第 3.4.2.1 節で定義されるデフォルト `PHB-->CLP mapping' からのこれらの PHB に対する関連マッピングエントリを使用し得る。第 3.4.2.1 節 で定義されたもの以外のマッピングが使用され得る。特に、ATM 上 での Diff-Serv の運用のために PHB から CLP へのマッピングが 将来標準化される場合、そのような標準化されたマッピングが その後使用され得る。

たとえば、出力ラベルが AF1 PSC をサポートする LSP に対応する場合、 `PHB-->CLP mapping' は次のように設定され得る。

     PHB                CLP Field

     AF11       ---->      0
     AF12       ---->      1
     AF13       ---->      1
     EF         ---->      0

この場合、Set of PHB-->Encaps mappings' は PHB-->EXP mapping' と `PHB-->CLP mapping' の両方を含むことに留意する。

3.4.2.1 デフォルト PHB-->CLP mapping' (Default PHB-->CLP mapping')

     PHB                CLP Bit

     DF         ---->      0
     CSn        ---->      0
     AFn1       ---->      0
     AFn2       ---->      1
     AFn3       ---->      1
     EF         ---->      0

3.4.3 `PHB-->DE mapping'

LSP がラベルスイッチ制御されていないフレームリレーインタフェース 上で出力する場合、この出力 LSP の Set of PHB-->Encaps mappings' に 1 つの PHB-->DE mapping' が追加され、次の方法で設定される。

• それはこの LSP 上でサポートされる PHB の関数であり、第 3.4.3.1 節で定義されるデフォルト `PHB-->DE mapping' からのこれらの PHB に対する関連マッピングエントリを使用し得る。第 3.4.3.1 節 で定義されたもの以外のマッピングが使用され得る。特に、フレーム リレー上での Diff-Serv の運用のために PHB から DE への マッピングが将来標準化される場合、そのような標準化された マッピングがその後使用され得る。

この場合、Set of PHB-->Encaps mappings' は PHB-->EXP mapping' と `PHB-->DE mapping' の両方を含むことに留意する。

3.4.3.1 デフォルト PHB-->DE mapping' (Default PHB-->DE mapping')

     PHB                 DE Bit

      DF       ---->       0
      CSn      ---->       0
      AFn1     ---->       0
      AFn2     ---->       1
      AFn3     ---->       1
      EF       ---->       0

3.4.4 `PHB-->802.1 mapping'

LSP が [IEEE_802.1] に従って複数の 802.1 トラフィッククラスが サポートされる LAN インタフェース上で出力する場合、この出力 LSP の Set of PHB-->Encaps mappings' に 1 つの PHB-->802.1 mapping' が追加される。この `PHB-->802.1 mapping' は次の方法で設定される。

• それはこの LSP 上でサポートされる PHB の関数であり、第 3.4.4.1 節で定義される事前設定 `PHB-->802.1 mapping' からのこれらの PHB に対する関連マッピングエントリを使用する。

Set of PHB-->Encaps mappings' は、その後 PHB-->EXP mapping' と `PHB-->802.1 mapping' の両方を含むことに留意する。

3.4.4.1 事前設定 PHB-->802.1 Mapping' (Preconfigured PHB-->802.1 Mapping')

本仕様の作成時点では、PHB から 802.1 トラフィッククラスへの標準化 されたマッピングはない。したがって、LAN インタフェース上で複数の 802.1 トラフィッククラスをサポートする LSR は、`PHB-->802.1 mapping' のローカル設定を許可しなければならない。このマッピング は、LSR がそのような LAN インタフェース上で確立したすべての出力 LSP に適用される。

3.5 出力 E-LSP 上でのカプセル化層への Diff-Serv 情報のエンコーディング (Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP)

本節は、出力 E-LSP に対応する所与の送信ラベルエントリについて、 MPLS カプセル化層への Diff-Serv 情報のエンコーディング方法を定義 する。これには、`Set of PHB-->Encaps mappings' が第 3.4 節で定義 されているとおりに設定されていることが必要である。

LSR はまず、NHLFE 内の対応するラベルに関連付けられた Diff-Serv コンテキストの `Set of PHB-->Encaps mappings' を決定する。

3.5.1 `PHB-->EXP mapping'

Set of PHB-->Encaps mappings' が PHB-->EXP mapping' の形式の マッピングを含む場合、LSR は次を行う。

• この `PHB-->EXP mapping' テーブル内で「出力 PHB」をルックアップ することにより、対応するレベルのラベルエントリの EXP フィールド に書き込む値を決定する。

3.5.2 `PHB-->CLP mapping'

Set of PHB-->Encaps mappings' が PHB-->CLP mapping' の形式の マッピングを含む場合、LSR は次を行う。

• この `PHB-->CLP mapping' テーブル内で「出力 PHB」をルックアップ することにより、ATM カプセル化ヘッダの CLP フィールドに書き込む 値を決定する。

3.5.3 `PHB-->DE mapping'

Set of PHB-->Encaps mappings' が PHB-->DE mapping' の形式の マッピングを含む場合、LSR は次を行う。

• この `PHB-->DE mapping' テーブル内で「出力 PHB」をルックアップ することにより、フレームリレーカプセル化ヘッダの DE フィールド に書き込む値を決定する。

3.5.4 `PHB-->802.1 mapping'

Set of PHB-->Encaps mappings' が PHB-->802.1 mapping' の形式の マッピングを含む場合、LSR は次を行う。

• この `PHB-->802.1 mapping' テーブル内で「出力 PHB」をルック アップすることにより、802.1 カプセル化ヘッダ [IEEE_802.1] の Tag Control Information の User_Priority フィールドに書き込む 値を決定する。

3.6 E-LSP のマージ (E-LSP Merging)

MPLS ドメインでは、2 つ以上の LSP を 1 つの LSR で 1 つの LSP に マージできる。E-LSP は、次の条件下で LSP マージと互換性がある。

  E-LSP は、正確に同じ BA の集合をサポートする場合にのみ、1 つの
  LSP にマージできる。

シグナリングされた `EXP<-->PHB mapping' を使用する E-LSP について、 上記のマージ条件は、マージされる LSP 上で正確に同じ PHB の集合が サポートされることをラベルセットアップ時に明示的にチェックする ことにより、LSR によって強制されなければならない (MUST)。

事前設定 EXP<-->PHB mapping' を使用する E-LSP について、E-LSP 上でサポートされる PHB は確立時にシグナリングされないため、LSR は上記のマージを強制するためにシグナリング情報に頼ることができない。 ただし、事前設定 EXP<-->PHB mapping' を使用するすべての E-LSP は、 所与の MPLS Diff-Serv ドメイン内で同じビヘイビアアグリゲートの 集合をサポートすることが要求される。したがって、事前設定 `EXP<-->PHB mapping' を使用する E-LSP のマージは、所与の MPLS Diff-Serv ドメイン内で許可される。

4. L-LSP の詳細な運用 (Detailed Operation of L-LSPs)

4.1 L-LSP の定義 (L-LSP Definition)

L-LSP は第 1.3 節で定義されている。

4.2 入力 L-LSP の Encaps-->PHB mapping' の設定 (Populating the Encaps-->PHB mapping' for an incoming L-LSP)

本節は、入力 PHB の決定を可能にするために、入力 L-LSP について ラベルセットアップ時に Diff-Serv コンテキストの `Encaps-->PHB mapping' がどのように設定されるかを定義する。

4.2.1 `EXP-->PHB mapping'

LSR がこの入力 L-LSP 上で MPLS シム層を終端し、L-LSP が ATM でも フレームリレーでもないインタフェース上で入力する場合、 `Encaps-->PHB mapping' は次の方法で設定される。

• それは実際には `EXP-->PHB mapping' である

• このマッピングは、この LSP 上で運ばれる PSC の関数であり、 第 4.2.1.1 節で定義される必須 `EXP/PSC-->PHB mapping' からの この PSC に対する関連マッピングエントリを使用しなければ ならない。

たとえば、入力ラベルが AF1 PSC をサポートする L-LSP に対応する 場合、`Encaps-->PHB mapping' は次のように設定される。

  EXP Field              PHB

    001        ---->    AF11
    010        ---->    AF12
    011        ---->    AF13

PPP インタフェースおよび LAN インタフェース上で L-LSP をサポート する LSR は、ATM でもフレームリレーでもない入力インタフェース上 でシム層を終端する LSR の例である。

LSR がこの入力 L-LSP 上で MPLS シム層を終端し、L-LSP が ATM または フレームリレーインタフェース上で入力する場合、`Encaps-->PHB mapping' は次の方法で設定される。

• それは実際には EXP-->PHB mapping' であるべきである。 Encaps-->PHB mapping' を設定する代替のオプションの方法が 将来定義される可能性がある（たとえば 'CLP/EXP--> PHB mapping' または 'DE/EXP-->PHB mapping' を使用する）が、本文書の範囲外 である。

• Encaps-->PHB mapping' が EXP-->PHB mapping' である場合、 この EXP-->PHB mapping' マッピングは L-LSP 上で運ばれる PSC の関数であり、第 4.2.1.1 節で定義される必須 EXP/PSC-->PHB mapping' からのこの PSC に対する関連マッピングエントリを使用 しなければならない。

ATM-MPLS ドメインまたは FR-MPLS ドメインのエッジ LSR は、入力 ATM/FR インタフェース上でシム層を終端する LSR の例である。

4.2.1.1 必須 EXP/PSC --> PHB mapping' (Mandatory EXP/PSC --> PHB mapping')

  EXP Field      PSC             PHB

    000          DF    ---->    DF
    000          CSn   ---->    CSn
    001          AFn   ---->    AFn1
    010          AFn   ---->    AFn2
    011          AFn   ---->    AFn3
    000          EF    ---->    EF

4.2.2 `CLP-->PHB mapping'

LSR がこの入力ラベル上で MPLS シム層を終端せず、ATM カプセル化を 使用する場合（すなわち ATM-LSR である場合）、この入力 L-LSP の `Encaps-->PHB mapping' は次の方法で設定される。

• それは実際には `CLP-->PHB mapping' である

• マッピングは、この LSP 上で運ばれる PSC の関数であり、第 4.2.2.1 節で定義されるデフォルト `CLP/PSC-->PHB mapping' からのこの PSC に対する関連マッピングエントリを使用するべきである。

たとえば、入力ラベルが AF1 PSC をサポートする L-LSP に対応する 場合、`Encaps-->PHB mapping' は次のように設定されるべきである。

  CLP Field              PHB

    0          ---->    AF11
    1          ---->    AF12

4.2.2.1 デフォルト CLP/PSC --> PHB mapping' (Default CLP/PSC --> PHB mapping')

  CLP Bit      PSC             PHB

     0          DF    ---->    DF
     0          CSn   ---->    CSn
     0          AFn   ---->    AFn1
     1          AFn   ---->    AFn2
     0          EF    ---->    EF

4.2.3 `DE-->PHB mapping'

LSR がこの入力ラベル上で MPLS シム層を終端せず、フレームリレー カプセル化を使用する場合（すなわち FR-LSR である場合）、この入力 L-LSP の `Encaps-->PHB mapping' は次の方法で設定される。

• それは実際には `DE-->PHB mapping' である

• マッピングは、この LSP 上で運ばれる PSC の関数であり、第 4.2.3.1 節で定義されるデフォルト `DE/PSC-->PHB mapping' からのこの PSC に対する関連マッピングエントリを使用するべきである。

4.2.3.1 デフォルト DE/PSC --> PHB mapping' (Default DE/PSC --> PHB mapping')

  DE Bit      PSC             PHB

     0          DF    ---->    DF
     0          CSn   ---->    CSn
     0          AFn   ---->    AFn1
     1          AFn   ---->    AFn2
     0          EF    ---->    EF

4.3 入力 L-LSP 上での入力 PHB の決定 (Incoming PHB Determination On Incoming L-LSP)

本節は、受信したラベルスタック内の対象ラベルエントリが L-LSP に 対応する場合に、入力 PHB の決定がどのように実行されるかを定義する。 これには、`Encaps-->PHB mapping' が第 4.2 節で定義されているとおり に設定されていることが必要である。

入力 PHB の決定のために入力 L-LSP に対応するラベルエントリを考慮 する場合、LSR はまず対応するラベルに関連付けられた `Encaps-->PHB mapping' を決定する。

4.3.1 `EXP-->PHB mapping'

Encaps-->PHB mapping' が EXP-->PHB mapping' の形式である場合、 LSR は次を行う。

• 対象ラベルエントリの EXP フィールドを見て `EXP-->PHB mapping' を使用することにより、入力 PHB を決定する。

4.3.2 `CLP-->PHB mapping'

Encaps-->PHB mapping' が CLP-->PHB mapping' の形式である場合、 LSR は次を行う。

• ATM 層カプセル化の CLP フィールドを見て `CLP-->PHB mapping' を 使用することにより、入力 PHB を決定する。

4.3.3 `DE-->PHB mapping'

Encaps-->PHB mapping' が DE-->PHB mapping' の形式である場合、 LSR は次を行う。

• フレームリレーカプセル化の DE フィールドを見て `DE-->PHB mapping' を使用することにより、入力 PHB を決定する。

4.4 出力 L-LSP の Set of PHB-->Encaps mappings' の設定 (Populating the Set of PHB-->Encaps mappings' for an outgoing L-LSP)

本節は、Diff-Serv 情報のエンコーディングを可能にするために、出力 L-LSP についてラベルセットアップ時に Diff-Serv コンテキストの `Set of PHB-->Encaps mappings' がどのように設定されるかを定義する。

4.4.1 `PHB-->EXP mapping'

LSR がこの出力 L-LSP 上で MPLS シム層を使用する場合、この出力 L-LSP の Set of PHB-->Encaps mappings' に 1 つの PHB-->EXP mapping' が追加される。この `PHB-->EXP mapping' は次の方法で 設定される。

• それはこの LSP 上でサポートされる PSC の関数であり、第 4.4.1.1 節で定義される必須 `PHB-->EXP mapping' からのこの PSC に関連 するマッピングエントリを使用しなければならない。

たとえば、出力ラベルが AF1 PSC をサポートする L-LSP に対応する 場合、次の PHB-->EXP mapping' が Set of PHB-->Encaps mappings' に追加される。

     PHB                EXP Field

     AF11       ---->      001
     AF12       ---->      010
     AF13       ---->      011

4.4.1.1 必須 PHB-->EXP mapping' (Mandatory PHB-->EXP mapping')

     PHB                EXP Field

     DF         ---->      000
     CSn        ---->      000
     AFn1       ---->      001
     AFn2       ---->      010
     AFn3       ---->      011
     EF         ---->      000

4.4.2 `PHB-->CLP mapping'

L-LSP が ATM インタフェース上で出力する場合（すなわち ATM-LSR で あるか、または LC-ATM インタフェース上、もしくはラベルスイッチ 制御されていない ATM インタフェース上でパケットを送信する フレームベース LSR である場合）、この出力 L-LSP の Set of PHB-->Encaps mappings' に 1 つの PHB-->CLP mapping' が追加される。

L-LSP がラベル制御されていない ATM インタフェース上で出力する 場合、`PHB-->CLP mapping' は第 3.4.2 節に従って設定される。

L-LSP が LC-ATM インタフェース上で出力する場合、`PHB-->CLP mapping' は次の方法で設定される。

• それはこの LSP 上でサポートされる PSC の関数であり、第 3.4.2.1 節で定義されるデフォルト `PHB-->CLP mapping' からのこの PSC に対する関連マッピングエントリを使用するべきである。

LSR が ATM インタフェース上で出力する L-LSP をサポートする フレームベース LSR である場合、Set of PHB-->Encaps mappings' は PHB-->EXP mapping' と PHB-->CLP mapping' の両方を含むことに 留意する。LSR が L-LSP をサポートする ATM-LSR である場合、 Set of PHB-->Encaps mappings' は `PHB-->CLP mapping' のみを 含む。

4.4.3 `PHB-->DE mapping'

L-LSP がフレームリレーインタフェース上で出力する場合（すなわち LC-FR インタフェース上、またはラベルスイッチ制御されていない フレームリレーインタフェース上でパケットを送信する LSR である 場合）、この出力 L-LSP の Set of PHB-->Encaps mappings' に 1 つ の PHB-->DE mapping' が追加される。

L-LSP がラベルスイッチ制御されていない FR インタフェース上で 出力する場合、`PHB-->DE mapping' は第 3.4.3 節に従って設定される。

L-LSP が LC-FR インタフェース上で出力する場合、`PHB-->DE mapping' は次の方法で設定される。

• それはこの LSP 上でサポートされる PSC の関数であり、第 3.4.3.1 節で定義されるデフォルト `PHB-->DE mapping' からのこの PSC に対する関連マッピングエントリを使用するべきである。

LSR が LC-FR インタフェース上で出力する L-LSP をサポートする エッジ LSR である場合、Set of PHB-->Encaps mappings' は PHB-->EXP mapping' と PHB-->DE mapping' の両方を含むことに 留意する。LSR が L-LSP をサポートする FR-LSR である場合、 Set of PHB-->Encaps mappings' は `PHB-->DE mapping' のみを 含む。

4.4.4 `PHB-->802.1 mapping'

LSP が [IEEE_802.1] で定義されているとおりに複数の 802.1 トラフィッククラスがサポートされる LAN インタフェース上で出力 する場合、第 3.4.4 節に従って 1 つの `PHB-->802.1 mapping' が 追加される。

4.5 出力 L-LSP 上でのカプセル化層への Diff-Serv 情報のエンコーディング (Encoding Diff-Serv Information into Encapsulation Layer on Outgoing L-LSP)

本節は、出力 L-LSP に対応する送信ラベルエントリについて、MPLS カプセル化層への Diff-Serv 情報のエンコーディング方法を定義する。 これには、`Set of PHB-->Encaps mappings' が第 4.4 節で定義されて いるとおりに設定されていることが必要である。

LSR はまず、NHLFE 内の対応するラベルに関連付けられた Diff-Serv コンテキストの `Set of PHB-->Encaps mappings' を決定し、その後 第 3.5.1、3.5.2、3.5.3、および 3.5.4 節で規定されているとおりに 対応するエンコーディングを実行する。

4.6 L-LSP のマージ (L-LSP Merging)

MPLS ドメインでは、2 つ以上の LSP を 1 つの LSR で 1 つの LSP に マージできる。L-LSP は、次の条件下で LSP マージと互換性がある。

  L-LSP は、同じ PSC をサポートする場合にのみ、1 つの L-LSP に
  マージできる。

上記のマージ条件は、マージされる LSP 上で同じ PSC がサポートされる ことをラベルセットアップ時に明示的にチェックすることにより、LSR によって強制されなければならない (MUST)。

L-LSP がマージする場合、マージポイントの下流で PSC に利用可能な 帯域は、マージされたトラフィックの合計を運ぶのに十分でなければ ならないことに留意する。これは特に EF トラフィックの場合に重要 である。これは複数の方法で保証できる（たとえばプロビジョニング、 または帯域シグナリングおよび明示的アドミッション制御経由）。

5. Diff-Serv サポートのための RSVP 拡張 (RSVP Extension for Diff-Serv Support)

MPLS アーキテクチャは、単一のラベル配布プロトコルを仮定しない。 [RSVP_MPLS_TE] は、MPLS ネットワークで LSP を確立するための RSVP への拡張を定義する。本節は、MPLS ネットワークで差別化サービスを サポートする LSP を確立するために、[RSVP_MPLS_TE] で定義された ものを超える RSVP への拡張を規定する。

5.1 Diff-Serv 関連 RSVP メッセージ形式 (Diff-Serv related RSVP Messages Format)

本文書で 1 つの新しい RSVP オブジェクトが定義される。DIFFSERV オブジェクトである。このオブジェクトの詳細な記述は以下で提供する。 この新しいオブジェクトは Path メッセージに適用可能である。本仕様 は、[RSVP_MPLS_TE] に従って LSP トンネルを確立するために使用され、 したがって C-Type が LSP_TUNNEL_IPv4 に等しい Session オブジェクト を含み、LABEL_REQUEST オブジェクトを含む Path メッセージにおける DIFFSERV オブジェクトの使用のみを定義する。

RSVP 経由での LSP トンネルの確立のサポートのために [RSVP_MPLS_TE] で定義された制限は、Diff-Serv をサポートする LSP トンネルの確立 にも適用可能である。たとえば、ユニキャスト LSP のみがサポートされ、 マルチキャスト LSP は今後の課題である。

この新しい DIFFSERV オブジェクトは RSVP に関してオプションで あるため、MPLS LSP セットアップに関係しない一般的な RSVP 実装は このオブジェクトをサポートする必要はない。

DIFFSERV オブジェクトは、[RSVP_MPLS_TE] で定義された LSP トンネル のサポートに関してオプションである。本仕様に準拠して事前設定 EXP<-->PHB mapping' を使用する E-LSP をサポートする Diff-Serv 対応 LSR は、DIFFSERV オブジェクトをサポートし得る (MAY)。本仕様 に準拠してシグナリングされた EXP<-->PHB mapping' を使用する E-LSP をサポートする Diff-Serv 対応 LSR は、DIFFSERV オブジェクト をサポートしなければならない (MUST)。本仕様に準拠して L-LSP を サポートする Diff-Serv 対応 LSR は、DIFFSERV オブジェクトを サポートしなければならない (MUST)。

5.1.1 Path メッセージ形式 (Path Message Format)

Path メッセージの形式は次のとおりである。

     <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                              <SESSION> <RSVP_HOP>
                              <TIME_VALUES>
                              [ <EXPLICIT_ROUTE> ]
                              <LABEL_REQUEST>
                              [ <SESSION_ATTRIBUTE> ]
                              [ <DIFFSERV> ]
                              [ <POLICY_DATA> ... ]
                              [ <sender descriptor> ]

     <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                              [ <ADSPEC> ]
                              [ <RECORD_ROUTE> ]

5.2 DIFFSERV オブジェクト (DIFFSERV Object)

DIFFSERV オブジェクトの形式を以下に示す。現在 2 つの可能な C_Type がある。タイプ 1 は E-LSP 用の DIFFSERV オブジェクトで ある。タイプ 2 は L-LSP 用の DIFFSERV オブジェクトである。

5.2.1. E-LSP 用の DIFFSERV オブジェクト (DIFFSERV object for an E-LSP):

class = 65, C_Type = 1

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved                                       | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                               ...                            //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 28 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  MAPnb : 4 bits
     DIFFSERV オブジェクトに含まれる MAP エントリの数を示す。
     これは 0 から 8 までの任意の値に設定できる。

  MAP : 32 bits
     各 MAP エントリは、1 つの EXP フィールド値と 1 つの PHB の
     間のマッピングを定義する。MAP エントリは次の形式を持つ。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  EXP : 3 bits
     このフィールドは、この MAP エントリで定義される
     `EXP<-->PHB mapping' のための EXP フィールドの値を含む。

  PHBID : 16 bits
     このフィールドは、この MAP エントリで定義される
     `EXP<-->PHB mapping' のための PHB の PHBID を含む。
     PHBID は [PHBID] で規定されているとおりにエンコードされる。

5.2.2 L-LSP 用の DIFFSERV オブジェクト (DIFFSERV object for an L-LSP):

class = 65, C_Type = 2

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved               |             PSC               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 16 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  PSC : 16 bits
     PSC は、LSP によってサポートされる PHB スケジューリング
     クラスを示す。PSC は [PHBID] で規定されているとおりに
     エンコードされる。

5.3 DIFFSERV オブジェクトの処理 (Handling DIFFSERV Object)

RSVP で LSP トンネルを確立するために、送信側は [RSVP_MPLS_TE] に 従って、セッションタイプが LSP_Tunnel_IPv4 で、LABEL_REQUEST オブジェクトを持つ Path メッセージを作成する。

事前設定 `EXP<-->PHB mapping' を使用する E-LSP トンネルを RSVP で確立するために、送信側は次の Path メッセージを作成する。

• セッションタイプが LSP_Tunnel_IPv4 で、

• LABEL_REQUEST オブジェクトを持ち、

• DIFFSERV オブジェクトを持たない。

事前設定 `EXP<-->PHB mapping' を使用する E-LSP トンネルを RSVP で確立するために、送信側は代替として次の Path メッセージを作成 し得る (MAY)。

• セッションタイプが LSP_Tunnel_IPv4 で、

• LABEL_REQUEST オブジェクトを持ち、

• MAP エントリを含まない E-LSP 用の DIFFSERV オブジェクトを 持つ。

シグナリングされた `EXP<-->PHB mapping' を使用する E-LSP トンネル を RSVP で確立するために、送信側は次の Path メッセージを作成する。

• セッションタイプが LSP_Tunnel_IPv4 で、

• LABEL_REQUEST オブジェクトを持ち、

• この E-LSP 上でサポートされる各 EXP 値について 1 つの MAP エントリを含む E-LSP 用の DIFFSERV オブジェクトを持つ。

L-LSP トンネルを RSVP で確立するために、送信側は次の Path メッセージを作成する。

• セッションタイプが LSP_Tunnel_IPv4 で、

• LABEL_REQUEST オブジェクトを持ち、

• この L-LSP 上でサポートされる PHB スケジューリングクラス (PSC) を含む L-LSP 用の DIFFSERV オブジェクトを持つ。

Path メッセージが複数の DIFFSERV オブジェクトを含む場合、最初の 1 つのみ意味があり、後続の DIFFSERV オブジェクトは無視され、 転送されてはならない。

パス沿いの各 LSR は、存在するとき、DIFFSERV オブジェクトをその path state block に記録する。

DIFFSERV オブジェクトが Path メッセージに存在しない場合、LSR は これを事前設定 `EXP<-->PHB mapping' を使用する E-LSP の要求と 解釈するべきである (SHOULD)。ただし、後方互換性のために、 Integrated Services Controlled Load または Guaranteed Services など [RSVP_MPLS_TE] で許可される他の非 Diff-Serv サービス品質 オプションとの互換性のために、LSR は設定可能な「オーバーライド オプション」をサポートし得る (MAY)。この「オーバーライドオプション」 が設定されている場合、LSR は Diff-Serv オブジェクトのない Path メッセージを、そのような非 Diff-Serv サービス品質を持つ LSP の 要求と解釈する。

MAP エントリを含まない E-LSP 用の DIFFSERV オブジェクトが Path メッセージに存在する場合、LSR はこれを事前設定 EXP<-->PHB mapping' を使用する E-LSP の要求と解釈しなければならない (MUST)。 特に、これにより、「オーバーライドオプション」が設定された LSR が、 非 Diff-Serv サービス品質を持つ LSP と同時に、事前設定 EXP<-->PHB mapping' を持つ E-LSP をサポートすることを可能にする。

少なくとも 1 つの MAP エントリを含む E-LSP 用の DIFFSERV オブジェクトが Path メッセージに存在する場合、LSR はこれを シグナリングされた `EXP<-->PHB mapping' を持つ E-LSP の要求と 解釈しなければならない (MUST)。

L-LSP 用の DIFFSERV オブジェクトが Path メッセージに存在する場合、 LSR はこれを L-LSP の要求と解釈しなければならない (MUST)。

E-LSP または L-LSP の宛先 LSR は、LABEL_REQUEST オブジェクトを 含む Path メッセージに応答して、次の Resv メッセージを送信する。

• LABEL オブジェクトを持ち、

• DIFFSERV オブジェクトを持たない。

ラベル要求が受け入れられ、ラベルが割り当てられたと仮定すると、 Diff-Serv LSR（送信側、宛先、中間ノード）は次を行わなければ ならない。

• 前の節で規定されているとおりに、確立された LSP に関連付け られた Diff-Serv コンテキストを ILM/FTN で更新する（入力および 出力ラベル）、

• この NHLFE（出力ラベル）に対して必要な Diff-Serv 転送処理 （スケジューリングおよび廃棄動作）をインストールする。

DIFFSERV オブジェクトを認識し、DIFFSERV オブジェクトを含むが LABEL_REQUEST オブジェクトを含まない、またはセッションタイプが LSP_Tunnel_IPv4 でない Path メッセージを受信する LSR は、エラー コード Diff-Serv Error' およびエラー値 Unexpected DIFFSERV object' を持つ PathErr を送信側に向けて送信する。これらは以下の 第 5.5 節で定義する。

E-LSP 用の DIFFSERV オブジェクトを持つ Path メッセージを受信し、 DIFFSERV オブジェクトを認識するが、MAP エントリの 1 つまたは 複数にエンコードされた特定の PHB をサポートしない LSR は、エラー コード Diff-Serv Error' およびエラー値 Unsupported PHB' を 持つ PathErr を送信側に向けて送信する。これらは以下の第 5.5 節 で定義する。

E-LSP 用の DIFFSERV オブジェクトを持つ Path メッセージを受信し、 DIFFSERV オブジェクトを認識するが、シグナリングされた EXP<-->PHB mapping' が無効であると判断する LSR は、エラーコード Diff-Serv Error' およびエラー値 Invalid EXP<-->PHB mapping' を持つ PathErr を送信側に向けて送信する。これらは以下の第 5.5 節 で定義する。E-LSP 用の DIFFSERV オブジェクトでシグナリングされた EXP<-->PHB mapping' は、次の場合に無効である。

• MAPnb フィールドが 0 から 8 の範囲にない、または

• 所与の EXP 値が複数の MAP エントリに現れる、または

• PHBID エンコーディングが無効である。

L-LSP 用の DIFFSERV オブジェクトを持つ Path メッセージを受信し、 DIFFSERV オブジェクトを認識するが、PSC フィールドにエンコード された特定の PSC をサポートしない LSR は、エラーコード Diff-Serv Error' およびエラー値 Unsupported PSC' を持つ PathErr を送信側に向けて送信する。これらは以下の第 5.5 節で 定義する。

DIFFSERV オブジェクトを持つ Path メッセージを受信し、DIFFSERV オブジェクトを認識するが、必要な LSP ごとの Diff-Serv コンテキストを割り当てることができない LSR は、エラーコード "Diff-Serv Error" およびエラー値 "Per-LSP context allocation failure" を持つ PathErr を送信する。これらは以下の第 5.5 節で 定義する。

Diff-Serv LSR は、本節ですでに議論した理由以外の理由でラベル 要求が受け入れられない状況を、[RSVP_MPLS_TE] に従って処理しな ければならない (MUST)（たとえば、アドミッション制御によって予約 が拒否された、ラベルを関連付けられない、など）。

5.4 DIFFSERV オブジェクトの非サポート (Non-support of the DIFFSERV Object)

DIFFSERV オブジェクトの Class-Num を認識しない LSR は、形式が 0bbbbbbb である未知の Class-Num について [RSVP] で規定された 手順に従って動作しなければならない (MUST)。すなわち、エラー コード `Unknown object class' を持つ PathErr を送信側に向けて 送信しなければならない。

DIFFSERV オブジェクトの Class-Num を認識するが DIFFSERV オブジェクトの C-Type を認識しない LSR は、未知の C-type について [RSVP] で規定された手順に従って動作しなければならない。すなわち、 エラーコード `Unknown object C-Type' を持つ PathErr を送信側に 向けて送信しなければならない。

どちらの状況でも、これによりパスセットアップは失敗する。送信側は、 L-LSP を確立できないことを管理に通知するべきであり、DIFFSERV オブジェクトなしで LSP 確立を再試行するアクションを取る可能性が ある（たとえば、フォールバック戦略として事前設定 `EXP<-->PHB mapping' を持つ E-LSP の使用を試みる）。

5.5 Diff-Serv のためのエラーコード (Error Codes For Diff-Serv)

上記の手順では、特定のエラーは Diff-Serv Error' として報告され なければならない。Diff-Serv Error' エラーコードの値は 27 である。

次は Diff-Serv Error のエラー値を定義する。

  Value    Error

   1       Unexpected DIFFSERV object
   2       Unsupported PHB
   3       Invalid `EXP<-->PHB mapping'
   4       Unsupported PSC
   5       Per-LSP context allocation failure

5.6 Intserv サービスタイプ (Intserv Service Type)

E-LSP および L-LSP の両方は、帯域予約ありまたはなしで確立できる。

[RSVP_MPLS_TE] で規定されているとおり、帯域予約ありで E-LSP または L-LSP を確立するために、Int-Serv の Controlled Load サービス （または場合によっては Guaranteed Service）が使用され、帯域は path（それぞれ Resv）メッセージの SENDER_TSPEC（それぞれ FLOWSPEC） でシグナリングされる。

[RSVP_MPLS_TE] で規定されているとおり、帯域予約なしで E-LSP または L-LSP を確立するために、[NULL] で規定された Null Service が使用 される。

本仕様は、Diff-Serv サービスのみのサポートのための E-LSP および L-LSP の使用を定義することに留意する。Intserv サービス （Controlled Load、Null Service、Guaranteed Service、...）に 関係なく、また予約が帯域予約ありであるかなしであるかに関係なく、 E-LSP および L-LSP はここで Diff-Serv サービスのサポートのために 定義される。MPLS Diff-Serv バックボーン上での Int-Serv サービスの サポートは本仕様の範囲外である。

また、本仕様は [DCLASS] で定義された DCLASS オブジェクトには関与 しないことにも留意する。なぜなら、このオブジェクトは MPLS ネットワーク内では関連のない DSCP 値に関する情報を伝達するから である。

6. Diff-Serv サポートのための LDP 拡張 (LDP Extensions for Diff-Serv Support)

MPLS アーキテクチャは、単一のラベル配布プロトコルを仮定しない。 [LDP] は、ラベル配布プロトコルおよび MPLS ネットワークにおける ラベルスイッチパス (LSP) の確立のためのその使用を定義する。本節は、 MPLS ネットワークで差別化サービスをサポートする LSP を確立する ための LDP への拡張を規定する。

本文書で 1 つの新しい LDP TLV が定義される。

• Diff-Serv TLV

この TLV の詳細な記述は以下で提供する。

新しい Diff-Serv TLV は LDP に関してオプションである。本仕様に 準拠して事前設定 EXP<-->PHB mapping' を使用する E-LSP をサポート する Diff-Serv 対応 LSR は、Diff-Serv TLV をサポートし得る (MAY)。 本仕様に準拠してシグナリングされた EXP<-->PHB mapping' を使用 する E-LSP をサポートする Diff-Serv 対応 LSR は、Diff-Serv TLV をサポートしなければならない (MUST)。本仕様に準拠して L-LSP を サポートする Diff-Serv 対応 LSR は、Diff-Serv TLV をサポートし なければならない (MUST)。

6.1 Diff-Serv TLV

Diff-Serv TLV は次の形式を持つ。

E-LSP 用の Diff-Serv TLV:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F|  Diff-Serv (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved                                     | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     LSP タイプ。これは E-LSP に対して 0 に設定される

  Reserved : 27 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  MAPnb : 4 bits
     DIFFSERV オブジェクトに含まれる MAP エントリの数を示す。
     これは 1 から 8 までの任意の値に設定できる。

  MAP : 32 bits
     各 MAP エントリは、1 つの EXP フィールド値と 1 つの PHB の
     間のマッピングを定義する。MAP エントリは次の形式を持つ。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  EXP : 3 bits
     このフィールドは、この MAP エントリで定義される
     `EXP<-->PHB mapping' のための EXP フィールドの値を含む。

  PHBID : 16 bits
     このフィールドは、この MAP エントリで定義される
     `EXP<-->PHB mapping' のための PHB の PHBID を含む。
     PHBID は [PHBID] で規定されているとおりにエンコードされる。

L-LSP 用の Diff-Serv TLV:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F| Type = PSC (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved             |              PSC              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     LSP タイプ。これは L-LSP に対して 1 に設定される

  Reserved : 15 bits
     このフィールドは予約されている。送信時にゼロに設定しなければ
     ならず、受信時には無視しなければならない。

  PSC : 16 bits
     PSC は、LSP によってサポートされる PHB スケジューリング
     クラスを示す。PSC は [PHBID] で規定されているとおりに
     エンコードされる。

6.2 Diff-Serv ステータスコード値 (Diff-Serv Status Code Values)

Status TLV の Status Code フィールドに対して次の値が定義される。

     Status Code                             E   Status Data

     Unexpected Diff-Serv TLV                0   0x01000001
     Unsupported PHB                         0   0x01000002
     Invalid `EXP<-->PHB mapping'            0   0x01000003
     Unsupported PSC                         0   0x01000004
     Per-LSP context allocation failure      0   0x01000005

6.3 Diff-Serv 関連 LDP メッセージ (Diff-Serv Related LDP Messages)

6.3.1 Label Request メッセージ (Label Request Message)

Label Request メッセージの形式は、Diff-Serv TLV をオプションで 含むように次のとおり拡張される。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.2 Label Mapping メッセージ (Label Mapping Message)

Label Mapping メッセージの形式は、Diff-Serv TLV をオプションで 含むように次のとおり拡張される。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Label Release メッセージ (Label Release Message)

Label Release メッセージの形式は、Status TLV をオプションで含む ように次のとおり拡張される。

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|   Label Release (0x0403)   |      Message Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Message ID                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     FEC TLV                                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Label TLV (optional)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Status TLV (optional)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.4 Notification メッセージ (Notification Message)

Notification メッセージの形式は、Diff-Serv TLV をオプションで 含むように次のとおり拡張される。

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Diff-Serv TLV の処理 (Handling of the Diff-Serv TLV)

6.4.1 Downstream Unsolicited モードでの Diff-Serv TLV の処理 (Handling of the Diff-Serv TLV in Downstream Unsolicited Mode)

本節は、Downstream Unsolicited モードが使用される場合の運用を 記述する。

事前設定 `EXP<-->PHB mapping' を使用する E-LSP のためにラベルを 割り当てる場合、下流の Diff-Serv LSR は Diff-Serv TLV なしの Label Mapping メッセージを発行する。

シグナリングされた `EXP<-->PHB mapping' を使用する E-LSP の ためにラベルを割り当てる場合、下流の Diff-Serv LSR は、この E-LSP 上でサポートされる各 EXP 値について 1 つの MAP エントリを 含む E-LSP 用の Diff-Serv TLV を持つ Label Mapping メッセージを 発行する。

L-LSP のためにラベルを割り当てる場合、下流の Diff-Serv LSR は、 この L-LSP 上でサポートされる PHB スケジューリングクラス (PSC) を含む L-LSP 用の Diff-Serv TLV を持つ Label Mapping メッセージ を発行する。

ラベルセットアップが成功したと仮定すると、下流および上流の LSR は次を行わなければならない。

• 前の節で規定されているとおりに、確立された LSP に関連付け られた Diff-Serv コンテキストを ILM/FTN で更新する（入力および 出力ラベル）、

• この NHLFE（出力ラベル）に対して必要な Diff-Serv 転送処理 （スケジューリングおよび廃棄動作）をインストールする。

複数の Diff-Serv TLV を持つ Label Mapping メッセージを受信する 上流の Diff-Serv LSR は、最初の 1 つのみ意味があるものと見なす。 LSR は後続の Diff-Serv TLV を無視し、転送してはならない。

E-LSP 用の Diff-Serv TLV を持つ Label Mapping メッセージを受信し、 MAP エントリの 1 つまたは複数にエンコードされた特定の PHB を サポートしない上流の Diff-Serv LSR は、Label TLV および Status Code が `Unsupported PHB' の Status TLV を含む Label Release メッセージを送信することにより、マッピングを拒否しなければ ならない。

E-LSP 用の Diff-Serv TLV を持つ Label Mapping メッセージを受信し、 シグナリングされた EXP<-->PHB mapping' が無効であると判断する 上流の Diff-Serv LSR は、Label TLV および Status Code が Invalid EXP<-->PHB mapping' の Status TLV を含む Label Release メッセージを送信することにより、マッピングを拒否しなければ ならない。E-LSP 用の DIFFSERV オブジェクトでシグナリングされた `EXP<-->PHB mapping' は、次の場合に無効である。

• MAPnb フィールドが 1 から 8 の範囲にない、または

• 所与の EXP 値が複数の MAP エントリに現れる、または

• PHBID エンコーディングが無効である

サポートされない PSC 値を含む L-LSP 用の Diff-Serv TLV を持つ Label Mapping メッセージを受信する上流の Diff-Serv LSR は、 Label TLV および Status Code が `Unsupported PSC' の Status TLV を含む Label Release メッセージを送信することにより、マッピング を拒否しなければならない。

6.4.2 Downstream on Demand モードでの Diff-Serv TLV の処理 (Handling of the Diff-Serv TLV in Downstream on Demand Mode)

本節は、Downstream on Demand モードが使用される場合の運用を 記述する。

事前設定 `EXP<-->PHB mapping' を使用する E-LSP のためにラベルを 要求する場合、上流の Diff-Serv LSR は Diff-Serv TLV なしの Label Request メッセージを送信する。

シグナリングされた `EXP<-->PHB mapping' を使用する E-LSP の ためにラベルを要求する場合、上流の Diff-Serv LSR は、この E-LSP 上でサポートされる各 EXP 値について 1 つの MAP エントリを含む E-LSP 用の Diff-Serv TLV を持つ Label Request メッセージを送信 する。

L-LSP のためにラベルを要求する場合、上流の Diff-Serv LSR は、 この L-LSP 上でサポートされる PSC を含む L-LSP 用の Diff-Serv TLV を持つ Label Request メッセージを送信する。

E-LSP または L-LSP のための Label Request メッセージに応答して Label Mapping メッセージを送信する下流の Diff-Serv LSR は、この Label Mapping メッセージに Diff-Serv TLV を含めてはならない。 ラベルセットアップが成功したと仮定すると、下流および上流の LSR は次を行わなければならない。

• 前の節で規定されているとおりに、確立された LSP に関連付け られた Diff-Serv コンテキストを ILM/FTN で更新する（入力および 出力ラベル）、

• この NHLFE（出力ラベル）に対して必要な Diff-Serv 転送処理 （スケジューリングおよび廃棄動作）をインストールする。

その Label Request メッセージに応答して Diff-Serv TLV を含む Label Mapping メッセージを受信する上流の Diff-Serv LSR は、 Label TLV および Status Code が `Unexpected Diff-Serv TLV' の Status TLV を含む Label Release メッセージを送信することにより、 ラベルマッピングを拒否しなければならない。

複数の Diff-Serv TLV を持つ Label Request メッセージを受信する 下流の Diff-Serv LSR は、最初の 1 つのみ意味があるものと見なす。 LSR は後続の Diff-Serv TLV を無視し、転送してはならない。

E-LSP 用の Diff-Serv TLV を持つ Label Request メッセージを受信し、 MAP エントリの 1 つ（または複数）にエンコードされた特定の PHB を サポートしない下流の Diff-Serv LSR は、Status Code が `Unsupported PHB' の Status TLV を含む Notification メッセージを 送信することにより、要求を拒否しなければならない。

E-LSP 用の Diff-Serv TLV を持つ Label Request メッセージを受信し、 シグナリングされた EXP<-->PHB mapping' が無効であると判断する 下流の Diff-Serv LSR は、Status Code が Invalid EXP<-->PHB mapping' の Status TLV を含む Notification メッセージを送信する ことにより、要求を拒否しなければならない。E-LSP 用の DIFFSERV TLV でシグナリングされた `EXP<-->PHB mapping' は、次の場合に 無効である。

• MAPnb フィールドが 1 から 8 の範囲にない、または

• 所与の EXP 値が複数の MAP エントリに現れる、または

• PHBID エンコーディングが無効である

サポートされない PSC 値を含む L-LSP 用の Diff-Serv TLV を持つ Label Request メッセージを受信する下流の Diff-Serv LSR は、 Status Code が `Unsupported PSC' の Status TLV を含む Notification メッセージを送信することにより、要求を拒否しな ければならない。

Label Request メッセージ内の Diff-Serv TLV タイプを認識するが、 必要な LSP ごとのコンテキスト情報を割り当てることができない 下流の Diff-Serv LSR は、Status Code が `Per-LSP context allocation failure' の Status TLV を含む Notification メッセージを送信することにより、要求を拒否しなければならない。

Label Request メッセージ内の Diff-Serv TLV タイプを認識し、要求 された PSC をサポートするが、他の理由で（たとえば利用可能な ラベルがない）ラベル要求を満たせない下流の Diff-Serv LSR は、 既存の LDP 手順 [LDP] に従って Notification メッセージを送信 しなければならない（たとえば `No Label Resource' Status Code を持つ）。この Notification メッセージは、要求された Diff-Serv TLV を含まなければならない。

6.5 Diff-Serv TLV の非処理 (Non-Handling of the Diff-Serv TLV)

Diff-Serv TLV タイプを認識しない LSR は、Diff-Serv TLV を含む Label Request メッセージまたは Label Mapping メッセージの受信時 に、U ビットおよび F ビットが 0 に設定された未知の TLV について [LDP] で規定された手順に従って動作しなければならない。すなわち、 メッセージを無視し、`Unknown TLV' Status を持つ Notification メッセージを返さなければならない。

6.6 帯域情報 (Bandwidth Information)

帯域情報はまた、たとえばトラフィックエンジニアリングの目的で、 E-LSP および L-LSP の確立時に、[MPLS CR LDP] で記述されている Traffic Parameters TLV を使用してシグナリングされ得る。

7. PPP、LAN、Non-LC-ATM および Non-LC-FR インタフェース上での Diff-Serv の MPLS サポート (MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces)

Diff-Serv の MPLS サポートのための一般的な運用（ラベル転送および LSP セットアップ運用を含む）は、前の節で規定されている。本節は、 PPP インタフェース、LAN インタフェース、ラベル制御されていない ATM インタフェース、およびラベル制御されていないフレームリレー インタフェース上での Diff-Serv の MPLS サポートに必要な特定の 運用を記述する。

これらのインタフェース上で、本仕様は FEC ごとに次の LSP の組み 合わせを許可する。

• ゼロ個または任意の数の E-LSP、および

• ゼロ個または任意の数の L-LSP。

Diff-Serv 対応 LSR は、これらのインタフェース上で事前設定 `EXP<-->PHB mapping' を使用する E-LSP をサポートしなければ ならない (MUST)。

Diff-Serv 対応 LSR は、これらのインタフェース上でシグナリング された `EXP<-->PHB mapping' を使用する E-LSP および L-LSP を サポートし得る (MAY)。

8. LC-ATM インタフェース上での Diff-Serv の MPLS サポート (MPLS Support of Diff-Serv over LC-ATM Interfaces)

本節は、ラベルスイッチ制御 ATM (LC-ATM) インタフェース上での Diff-Serv の MPLS サポートに必要な特定の運用を記述する。

本文書は、MPLS ATM Diff-Serv ドメイン内で FEC ごとに任意の数の L-LSP を許可する。E-LSP は LC-ATM インタフェース上ではサポート されない。

8.1 ATM トラフィッククラスおよびトラフィック管理機構の使用 (Use of ATM Traffic Classes and Traffic Management mechanisms)

ATM フォーラムによって規定された「ATM サービスカテゴリ」、ITU-T によって規定された「ATM 転送能力」、またはベンダー固有の ATM トラフィッククラスの使用は、本仕様の範囲外である。準拠実装の 唯一の要件は、ATM LSR によって L-LSP 上で転送されるビヘイビア アグリゲートが経験する転送動作が、対応する Diff-Serv PHB 仕様に 準拠していなければならない (MUST) ことである。

ATM リンク上で PHB 廃棄優先順位値をエンコードするためのビットは 1 つ（CLP）のみであるため、ATM LSR では 2 つの異なる廃棄優先順位 レベルのみがサポートされる。第 4.2.2 節および第 4.4.2 節は、 AFn 順序付きアグリゲートの 3 つの廃棄優先順位レベルがこれら 2 つ の ATM 廃棄優先順位レベルにどのようにマップされるかを定義する。 このマッピングは、2 つの廃棄優先順位レベルのみがサポートされる 場合について [DIFF_AF] で規定された要件に従っている。

パケットの一部が廃棄されることを避けるために、Early Packet Discard (EPD) などのフレーム廃棄機構（[ATMF_TM] を参照）は、 本文書で記述されるすべての PHB について ATM-LSR で有効にされる べきである (SHOULD)。

8.2 LC-ATM インタフェースを持つ LSR 実装 (LSR Implementation With LC-ATM Interfaces)

Diff-Serv 対応 LSR は、LC-ATM インタフェース上で L-LSP をサポート しなければならない (MUST)。本仕様は、ATM-LSR ドメインのエッジ LSR が [MPLS_ATM] で定義された「シムヘッダ」カプセル化方法を使用 すると仮定する。「シムヘッダ」カプセル化なしの運用は本仕様の 範囲外である。

9. LC-FR インタフェース上での Diff-Serv の MPLS サポート (MPLS Support of Diff-Serv over LC-FR Interfaces)

本節は、ラベルスイッチ制御フレームリレー (LC-FR) インタフェース 上での Diff-Serv の MPLS サポートに必要な特定の運用を記述する。

本文書は、MPLS フレームリレー Diff-Serv ドメイン内で FEC ごとに 任意の数の L-LSP を許可する。E-LSP は LC-FR インタフェース上では サポートされない。

9.1 フレームリレートラフィックパラメータおよびトラフィック管理機構の使用 (Use of Frame Relay Traffic parameters and Traffic Management mechanisms)

ITU-T およびフレームリレーフォーラムによって規定されたフレーム リレートラフィックパラメータ、またはベンダー固有のフレームリレー トラフィック管理機構の使用は、本仕様の範囲外である。準拠実装の 唯一の要件は、フレームリレー LSR によって L-LSP 上で転送される ビヘイビアアグリゲートが経験する転送動作が、対応する Diff-Serv PHB 仕様に準拠していなければならない (MUST) ことである。

フレームリレーリンク上で PHB 廃棄優先順位値をエンコードするための ビットは 1 つ（DE）のみであるため、フレームリレー LSR では 2 つの 異なる廃棄優先順位レベルのみがサポートされる。第 4.2.3 節および 第 4.4.3 節は、AFn 順序付きアグリゲートの 3 つの廃棄優先順位 レベルがこれら 2 つのフレームリレー廃棄優先順位レベルにどのように マップされるかを定義する。このマッピングは、2 つの廃棄優先順位 レベルのみがサポートされる場合について [DIFF_AF] で規定された 要件に従っている。

9.2 LC-FR インタフェースを持つ LSR 実装 (LSR Implementation With LC-FR Interfaces)

Diff-Serv 対応 LSR は、LC-Frame Relay インタフェース上で L-LSP をサポートしなければならない (MUST)。

本仕様は、FR-LSR ドメインのエッジ LSR が [MPLS_FR] で推奨される 「ジェネリックカプセル化」方法を使用すると仮定する。「ジェネリック カプセル化」なしの運用は本仕様の範囲外である。

10. IANA に関する考慮事項 (IANA Considerations)

本文書は、IANA への影響を持ついくつかのオブジェクトを定義する。

本文書は第 5.2 節で新しい RSVP オブジェクト、DIFFSERV オブジェクト を定義する。このオブジェクトは、理解されない場合にエラーコード "Unknown Object Class" で RSVP メッセージ全体が拒否される原因と なるオブジェクトについて [RSVP] で定義された空間からの番号を必要 とした。そのようなオブジェクトは、クラス番号の最上位ビットのゼロ によって識別される。その空間内で、このオブジェクトは "IETF Consensus" 空間からの番号を必要とした。DIFFSERV オブジェクトに 対して "65" が IANA によって割り当てられた。

本文書は第 5.5 節で新しい RSVP エラーコード "Diffserv Error" を 定義する。エラーコード "27" が "Diffserv Error" に対して IANA によって割り当てられた。本文書は、このエラーコードに対して ERROR_SPEC オブジェクト内で使用される値フィールドの値 1 から 5 を定義する。この空間における将来の値の割り当ては、[IANA] で定義 された First Come First Served ポリシーを使用して IANA によって 処理されるべきである。

本文書は第 6.1 節で新しい LDP TLV、Diffserv TLV を定義する。この TLV の番号は、[LDP] で定義されたポリシーに従ってワーキング グループのコンセンサスによって割り当てられた。

本文書は第 6.2 節で Diffserv 関連のエラー条件のための 5 つの 新しい LDP Status Code 値を定義する。Status Code の値は、[LDP] で定義されたポリシーに従ってワーキンググループのコンセンサスに よって割り当てられた。

11. セキュリティに関する考慮事項 (Security Considerations)

本文書は、Diff-Serv、MPLS、および RSVP に固有のものを超える新しい セキュリティ問題を導入せず、それらの技術に対して提案された同じ 機構を使用し得る。

12. 謝辞 (Acknowledgments)

本文書は、Eric Rosen、Angela Chiu、および Carol Iturralde との 議論から恩恵を受けた。また、Diff-Serv と IP トンネルの相互作用に 関する D. Black の作業からも借用している。

付録 A. 展開シナリオの例 (APPENDIX A. Example Deployment Scenarios)

本節は追加の仕様を提供するものではなく、MPLS 上での Diff-Serv サポートのためのこの柔軟なアプローチがどのように展開され得るかの 例を提供するためにのみここに存在する。特定の環境におけるさまざまな 展開オプションの長所と短所は、本文書の範囲外である。

A.1 シナリオ 1: 8 個（以下）の BA、トラフィックエンジニアリングなし、MPLS 保護なし (Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection)

MPLS 上で 8 個（以下）の BA を実行し、トラフィックエンジニアリング を実行せず、MPLS 保護を使用せず、ネットワーク内で MPLS シムヘッダ カプセル化を使用するサービスプロバイダは、LDP 経由で確立された FEC ごとに単一の E-LSP を使用して MPLS 上で Diff-Serv を実行する ことを選択し得る。さらに、サービスプロバイダは事前設定 `EXP<-->PHB mapping' を使用することを選択し得る。

運用は次のように要約できる。

• サービスプロバイダは、すべての LSR で、各 PHB と EXP フィールドの値の間の双方向マッピングを設定する （たとえば 000<-->AF11、001<-->AF12、010<-->AF13）

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、各 PSC のスケジューリング動作（たとえば AF1 に割り当てられた 帯域）および各 PHB の廃棄動作（たとえば AF11、AF12、AF13 の ドロッププロファイル）を設定する

• LSR は、上記の仕様に従って LDP を使用して FEC ごとに単一の E-LSP の確立をシグナリングする（すなわち、LSP が E-LSP であり 事前設定マッピングを使用することを暗黙的に示すために、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を 含めない）

A.2 シナリオ 2: 8 個を超える BA、トラフィックエンジニアリングなし、MPLS 保護なし (Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection)

MPLS 上で 8 個を超える BA を実行し、トラフィックエンジニアリング を実行せず、MPLS 保護を使用せず、ネットワーク内で MPLS シム カプセル化を使用するサービスプロバイダは、各 FEC について次を 使用して MPLS 上で Diff-Serv を実行することを選択し得る。

• LDP 経由で確立され、8 個（以下）の BA の集合をサポートする ために事前設定マッピングを使用する 1 つの E-LSP、および

• 他の BA のサポートのために LDP 経由で確立された <FEC,OA> ごとの 1 つの L-LSP。

運用は次のように要約できる。

• サービスプロバイダは、E-LSP 上で転送される BA について、 すべての LSR で各 PHB と EXP フィールドの値の間の双方向 マッピングを設定する

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、E-LSP 上でサポートされる各 PSC のスケジューリング動作および 対応する各 PHB の廃棄動作を設定する

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、L-LSP 上でサポートされる各 PSC のスケジューリング動作および 対応する各 PHB の廃棄動作を設定する

• LSR は、上記で規定されているとおりに LDP を使用して、E-LSP で 転送される BA の集合のために FEC ごとに単一の E-LSP の確立を シグナリングする（すなわち、LSP が E-LSP であり事前設定 マッピングを使用することを暗黙的に示すために、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含めない）

• LSR は、上記で規定されているとおりに LDP を使用して、他の BA のために <FEC,OA> ごとに 1 つの L-LSP の確立をシグナリングする （すなわち、L-LSP の PSC を示すために LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含める）。

A.3 シナリオ 3: 8 個（以下）の BA、集約トラフィックエンジニアリング、集約 MPLS 保護 (Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection)

MPLS 上で 8 個（以下）の BA を実行し、集約トラフィックエンジニア リングを実行し（すなわちすべての BA に対して単一の共通パス選択を 実行し）、集約 MPLS 保護を使用し（すなわちすべての PSC に対して 共同でサービスを復旧し）、ネットワーク内で MPLS シムヘッダ カプセル化を使用するサービスプロバイダは、RSVP [RSVP_MPLS_TE] または CR-LDP [CR-LDP_MPLS_TE] 経由で確立され、事前設定 マッピングを使用する FEC ごとに単一の E-LSP を使用して MPLS 上 で Diff-Serv を実行することを選択し得る。

運用は次のように要約できる。

• サービスプロバイダは、すべての LSR で、各 PHB と EXP フィールドの値の間の双方向マッピングを設定する （たとえば 000<-->AF11、001<-->AF12、010<-->AF13）

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、各 PSC のスケジューリング動作（たとえば AF1 に割り当てられた 帯域）および各 PHB の廃棄動作（たとえば AF11、AF12、AF13 の ドロッププロファイル）を設定する

• LSR は、事前設定マッピングを使用する FEC ごとに単一の E-LSP の確立をシグナリングする。

  • 上記で規定されているとおりに RSVP プロトコルを使用する （すなわち、LABEL_REQUEST オブジェクトを含む PATH メッセージ に DIFFSERV RSVP オブジェクトを含めない）、または

  • 上記で規定されているとおりに CR-LDP プロトコルを使用する （すなわち、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含めない）。

• 本文書の範囲外の機構経由で MPLS 保護を達成するために、すべての E-LSP で保護がアクティブ化される。

A.4 シナリオ 4: OA ごとのトラフィックエンジニアリング/MPLS 保護 (Scenario 4: per-OA Traffic Engineering/MPLS Protection)

MPLS 上で任意の数の BA を実行し、OA ごとのトラフィックエンジニア リングを実行し（すなわち各 OA に対して別々のパス選択を実行し）、 ネットワーク内で OA ごとの MPLS 保護を実行する（すなわち異なる OA に対して潜在的に異なる保護レベルで保護を実行する）サービス プロバイダは、RSVP または CR-LDP 経由で確立された <FEC,OA> ペア ごとに 1 つの L-LSP を使用して MPLS 上で Diff-Serv を実行する ことを選択し得る。

運用は次のように要約できる。

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、各 PSC のスケジューリング動作（たとえば AF1 に割り当てられた 帯域）および各 PHB の廃棄動作（たとえば AF11、AF12、AF13 の ドロッププロファイル）を設定する

• LSR は <FEC,OA> ごとに 1 つの L-LSP の確立をシグナリングする。

  • 上記で規定されているとおりに RSVP を使用して L-LSP の PSC をシグナリングする（すなわち、LABEL_REQUEST を含む PATH メッセージに DIFFSERV RSVP オブジェクトを含める）、または

  • 上記で規定されているとおりに CR-LDP プロトコルを使用して L-LSP PSC をシグナリングする（すなわち、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含める）。

• 本文書の範囲外の機構経由で、異なる L-LSP 上で適切なレベルの 保護がアクティブ化される（各 PSC に対して潜在的に異なる保護 レベルで）。

A.5 シナリオ 5: 8 個（以下）の BA、OA ごとのトラフィックエンジニアリング/MPLS 保護 (Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS Protection)

MPLS 上で 8 個（以下）の BA を実行し、OA ごとのトラフィック エンジニアリングを実行し（すなわち各 OA に対して別々のパス選択を 実行し）、ネットワーク内で OA ごとの MPLS 保護を実行する（すなわち 異なる OA に対して潜在的に異なる保護レベルで保護を実行する） サービスプロバイダは、RSVP または CR-LDP 経由で確立された <FEC,OA> ペアごとに 1 つの E-LSP を使用して MPLS 上で Diff-Serv を実行することを選択し得る。さらに、サービスプロバイダはすべての E-LSP 上で事前設定マッピングを使用することを選択し得る。

運用は次のように要約できる。

• サービスプロバイダは、すべての LSR で、各 PHB と EXP フィールドの値の間の双方向マッピングを設定する （たとえば 000<-->AF11、001<-->AF12、010<-->AF13）

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、各 PSC のスケジューリング動作（たとえば AF1 に割り当てられた 帯域）および各 PHB の廃棄動作（たとえば AF11、AF12、AF13 の ドロッププロファイル）を設定する

• LSR は <FEC,OA> ごとに 1 つの E-LSP の確立をシグナリングする。

  • 上記で規定されているとおりに RSVP プロトコルを使用して、 LSP が事前設定マッピングを使用する E-LSP であることを シグナリングする（すなわち、LABEL_REQUEST を含む PATH メッセージに DIFFSERV RSVP オブジェクトを含めない）、または

  • 上記で規定されているとおりに CR-LDP プロトコルを使用して、 LSP が事前設定マッピングを使用する E-LSP であることを シグナリングする（すなわち、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含めない）

• サービスプロバイダは、各 E-LSP について、その E-LSP のヘッドエンド で、所与の OA に属するパケットのみが対応する FEC および対応する OA のために確立された E-LSP 上で転送されるように、フィルタリング /転送基準を設定する。

• 本文書の範囲外の機構経由で、異なる E-LSP 上で適切なレベルの保護が アクティブ化される（各 E-LSP 上で実際に転送される PSC に応じて 潜在的に異なる保護レベルで）。

A.6 シナリオ 6: 8 個の BA 上でトラフィックエンジニアリング/MPLS 保護なし、他の BA 上で OA ごとのトラフィックエンジニアリング/MPLS 保護 (Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs)

8 個（以下）の BA 上でトラフィックエンジニアリング/MPLS 保護を 実行せず、他の BA 上で OA ごとのトラフィックエンジニアリング/MPLS 保護を実行し（すなわち他の BA に対応する各 OA に対して別々のパス 選択を実行し、これらの OA のそれぞれに対して潜在的に異なるポリシー で MPLS 保護を実行し）、ネットワーク内で MPLS シムカプセル化を使用 するサービスプロバイダは、各 FEC について次を使用して MPLS 上で Diff-Serv を実行することを選択し得る。

• 8 個（以下）の非トラフィックエンジニアリング/非保護 BA の集合 をサポートするために LDP 経由で確立された事前設定マッピングを 使用する 1 つの E-LSP、および

• 他の BA のサポートのために RSVP または CR-LDP 経由で確立された <FEC,OA> ペアごとに 1 つの L-LSP。

運用は次のように要約できる。

• サービスプロバイダは、E-LSP 上でサポートされる BA について、 すべての LSR で各 PHB と EXP フィールドの値の間の双方向 マッピングを設定する

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、E-LSP 上でサポートされる各 PSC のスケジューリング動作および 対応する各 PHB の廃棄動作を設定する

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、L-LSP 上でサポートされる各 PSC のスケジューリング動作および 対応する各 PHB の廃棄動作を設定する

• LSR は、上記で規定されているとおりに LDP を使用して、非 トラフィックエンジニアリング BA のために FEC ごとに単一の E-LSP の確立をシグナリングする（すなわち、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含めない）

• LSR は、他の BA のために <FEC,OA> ごとに 1 つの L-LSP の確立を シグナリングする。

  • 上記で規定されているとおりに RSVP プロトコルを使用して L-LSP PSC をシグナリングする（すなわち、LABEL_REQUEST オブジェクトを含む PATH メッセージに DIFFSERV RSVP オブジェクトを含める）、または

  • 上記で規定されているとおりに CR-LDP プロトコルを使用して L-LSP PSC をシグナリングする（すなわち、LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含める）。

• E-LSP 上では保護はアクティブ化されない。

• 本文書の範囲外の機構経由で、異なる L-LSP 上で適切なレベルの 保護がアクティブ化される（L-LSP の PSC に応じて潜在的に異なる 保護レベルで）。

A.7 シナリオ 7: 8 個を超える BA、トラフィックエンジニアリングなし、MPLS 保護なし (Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS Protection)

MPLS 上で 8 個を超える BA を実行し、トラフィックエンジニアリング を実行せず、MPLS 保護を実行せず、ネットワーク内で MPLS シムヘッダ カプセル化を使用するサービスプロバイダは、LDP 経由で確立され、 シグナリングされた `EXP<-->PHB mapping' を使用する FEC ごとに 2 つの E-LSP を使用して MPLS 上で Diff-Serv を実行することを 選択し得る。

運用は次のように要約できる。

• サービスプロバイダは、すべての LSR およびすべてのインタフェース で、各 PSC のスケジューリング動作（たとえば AF1 に割り当てられた 帯域）および各 PHB の廃棄動作（たとえば AF11、AF12、AF13 の ドロッププロファイル）を設定する

• LSR は、上記の仕様に従って LDP を使用して FEC ごとに 2 つの E-LSP の確立をシグナリングする（すなわち、LSP が E-LSP であり その `EXP<-->PHB mapping' であることを明示的に示すために、 LDP Label Request/Label Mapping メッセージに Diff-Serv TLV を含める）。シグナリングされたマッピングは、各 E-LSP 上で 転送される 8 個（以下）の BA の部分集合、および各 E-LSP 上で どの EXP 値が各 BA にマップされるかを示す。

付録 B. 帯域予約シナリオの例 (APPENDIX B. Example Bandwidth Reservation Scenarios)

B.1 シナリオ 1: 帯域予約なし (Scenario 1: No Bandwidth Reservation)

ネットワーク管理者が次を選択する場合を考える。

• Diff-Serv リソースを完全にオフラインでプロビジョニングする （たとえば Command Line Interface、SNMP、COPS 経由、...）

• すべての Diff-Serv トラフィックに対して最短パスルーティングを 使用する。

これは、非 MPLS IP 上のプロビジョニングされた Diff-Serv に最も 近いモデルである。その場合、E-LSP および/または L-LSP は シグナリングされた帯域なしで確立される。

B.2 シナリオ 2: PSC ごとのアドミッション制御のための帯域予約 (Scenario 2: Bandwidth Reservation for per-PSC Admission Control)

ネットワーク管理者が次を選択する場合を考える。

• Diff-Serv リソースを完全にオフラインでプロビジョニングする （たとえば Command Line Interface、SNMP、COPS 経由、...）

• L-LSP を使用する

• 各 PSC に対して別々に制約ベースルーティングを実行する。ここで 制約の 1 つは、関連する PSC に割り当てられた帯域からの帯域の 可用性である。

その場合、L-LSP はシグナリングされた帯域で確立される。L-LSP 確立時にシグナリングされた帯域は、LSR がすべてのホップで アドミッション制御を実行し、関連する PSC の帯域可用性の制約が 満たされることを保証するために使用される。

B.3 シナリオ 3: PSC ごとのアドミッション制御および PSC ごとのリソース調整のための帯域予約 (Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment)

ネットワーク管理者が次を選択する場合を考える。

• L-LSP を使用する

• 各 PSC に対して別々に制約ベースルーティングを実行する。ここで 制約の 1 つは、関連する PSC に割り当てられた帯域からの帯域の 可用性である。

• Diff-Serv リソースを動的に調整する

その場合、L-LSP はシグナリングされた帯域で確立される。L-LSP 確立時にシグナリングされた帯域は、LSR が関連する PSC に割り当て られたリソース（たとえばスケジューリング重み）を調整しようと 試み、その後調整後に関連する PSC の帯域可用性の制約が満たされる ことを保証するためにアドミッション制御を実行するために使用される。

参考文献 (References)

[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e).

[ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999.

[CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.

[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.

[DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.

[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

[DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[DIFF_NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

[DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.

[ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.

[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98.

[LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.

[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.

[MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

[MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.

[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.

[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.

[PHBID] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 2001.

[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

著者のアドレス (Authors' Addresses)

Francois Le Faucheur Cisco Systems Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France

Phone: +33 4 97 23 26 19 EMail: [email protected]

Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA

Phone: +1 (408) 853-4065 EMail: [email protected]

Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA

Phone: +1 (978) 244-8000 EMail: [email protected]

Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada

Phone: +1 (613) 271-4018 EMail: [email protected]

Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA

Phone +1 (781) 993-4900 EMail: [email protected]

Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752

EMail: [email protected]

Pierrick Cheval Alcatel 5 rue Noel-Pons 92737 Nanterre Cedex France EMail: [email protected]

Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland

EMail: [email protected]

完全な著作権表示 (Full Copyright Statement)

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

本文書およびその翻訳は、他者に複製および提供することができ、それ についてコメントする、あるいは説明するか、その実装を支援する派生 作業物は、上記の著作権表示およびこの段落がすべてのそのような複製 および派生作業物に含まれることを条件として、いかなる種類の制限も なく、全体または一部を準備、複製、公開、および配布できる。ただし、 本文書自体は、著作権表示または Internet Society もしくは他の インターネット組織への参照を削除するなど、いかなる方法でも変更 してはならない。ただし、インターネット標準の開発のために必要な 場合は、インターネット標準プロセスで定義された著作権の手順に従う か、または英語以外の言語に翻訳するために必要な場合を除く。

上記で付与された限定的な許可は永続的であり、Internet Society または その後継者もしくは譲受人によって取り消されることはない。

本文書およびここに含まれる情報は「現状のまま (AS IS)」で提供され、 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE は、明示または黙示を問わず、ここに含まれる情報の使用がいかなる 権利も侵害しないこと、あるいは商品性または特定目的への適合性に 関する黙示の保証を含むがこれらに限定されない、すべての保証を 否認する。

謝辞 (Acknowledgement)

RFC 編集機能のための資金は現在 Internet Society によって提供されて いる。