2. Diff-Serv LSR のラベル転送モデルとトンネリングモデル

2.1. Diff-Serv LSR のラベル転送モデル

所与の 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 の決定

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

2.2.1. ラベルスタックエントリを考慮した入力 PHB の決定

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

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

2.2.2. IP ヘッダを考慮した入力 PHB の決定

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

2.3. オプションのトラフィック調整を伴う出力 PHB の決定

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

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

2.4. ラベル転送

• [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 情報のエンコーディング

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

2.5.1. 送信ラベルエントリへの Diff-Serv 情報のエンコーディング

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

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

2.5.2. 送信 IP ヘッダへの Diff-Serv 情報のエンコーディング

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

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

2.6. MPLS 上の Diff-Serv トンネリングモデル

2.6.1. Diff-Serv トンネリングモデル

• [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. パイプモデル

パイプモデルでは、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 は次を行う。

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

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

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

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

2.6.2.1. ショートパイプモデル

ショートパイプモデルは、上記で記述したパイプモデルのオプションの変形である。唯一の違いは、ショートパイプモデルでは、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. ユニフォームモデル

ユニフォームモデルでは、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. 階層

ラベルスタック機構により、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 情報のエンコーディングを実行しなければならない。