JP4109692B2 - ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード - Google Patents

Description

本発明は、ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノードに関し、特に、ＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）やこれを拡張したプロトコルを採用するネットワークやノードに用いて好適な技術に関する。

従来、限定された地域内での高品質な映像の実時間性を満たした通信並びに大容量データの高速転送を可能にする技術として、例えば、特開２０００−２３２４５４号公報（以下、特許文献１という）により提案されているもの（地域限定型高速通信システム及びサービス実現方法）がある。この特許文献１の技術は、ギガビットＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の周知の高速ＬＡＮ技術を用いた地域限定型高速通信システムであり、通信フレームに限定された地域を特定する地域ＩＤ情報及びユーザの業種を特定する業界ＩＤ情報並びにユーザを特定するユーザＩＤ情報を含む通信フレームを用いてデータ転送を行なうことにより、高品質な映像を使用するユーザを対象とした限定された地域内のユーザ間で高速なデータ通信を行なうものである。
これに対し、近年、従来のルータでは実現が困難であったパケット転送経路の明示的な指定を可能とし、経路の偏りを防いでリンクの使用効率を高めたり、インターネット上でＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）を実現したりするために、ＭＰＬＳが利用されるようになってきており、その研究・開発・改良（拡張）等も盛んに行なわれている。
ここで、ＭＰＬＳは、ＩＰパケットのルーティングをＩＰヘッダの代わりに「ラベル」と呼ばれる短い固定長の経路識別情報を利用して行なう技術であり、ＭＰＬＳをサポートするルータ〔一般に、ＬＳＲ（Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ Ｒｏｕｔｅｒ）と呼ばれる〕同士が所定のラベル配付プロトコル（ＬＤＰ：Ｌａｂｅｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）により、必要な「ラベル」を交換することが行なわれる。
また、近年では、当該ＭＰＬＳの拡張版として、「ラベル」にＴＤＭ（Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）のタイムスロットやフォトニックネットワークの光波長（λ）を用いるＧ（Ｇｅｎｅｒａｌｉｚｅｄ）ＭＰＬＳ〔ＭＰ（λ）Ｓとも呼ばれる〕を実装する装置（パケット中継装置，ＴＤＭ中継装置，光波長中継装置等）や、これを用いて構成したネットワークやアプリケーション〔ＭＰＬＳ Ｌ２（Ｌａｙｅｒ ２）ＶＰＮ，ＭＰＬＳ Ｌ３（Ｌａｙｅｒ ３）ＶＰＮ，ＭＰＬＳ−ＴＥ（Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ），ＧＭＰＬＳ等〕も開発されている。以下、ＭＰＬＳ技術の概要について説明する。
〔１〕ラベル配付プロトコル（ＬＤＰ：Ｌａｂｅｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の識別
ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）３０３６（ＬＤＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）（非特許文献１）の２．２．２項に記述されているように、ＬＤＰ識別子は、全体がＬＳＲ（Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ Ｒｏｕｔｅｒ）識別子（ＬＳＲ ＩＤ）（４オクテット）及びラベル空間識別子（Ｌａｂｅｌ ｓｐａｃｅ ＩＤ）（２オクテット）の計６オクテットで構成され、隣接ＬＳＲ間のＬＤＰセッションを識別するとともに、そのＬＳＲが送信するラベル空間を識別するものである。ここで、「ＬＳＲ識別子」は、ＬＳＲを識別するグローバルな値で、通常は、ルータＩＤを使用することが推奨されている。また、「ラベル空間識別子」は、ＬＳＲ内で使用されるラベル空間を識別する値である。
そして、「ラベル空間（Ｌａｂｅｌ ｓｐａｃｅ）」としては、「ｐｅｒ ｉｎｔｅｒｆａｃｅ」と「ｐｌａｔｆｏｒｍ−ｗｉｄｅ」とが規定されており、後者の「ｐｌａｔｆｏｒｍ−ｗｉｄｅ」を使用する場合はラベル空間識別子＝０とすることが規定されている。
したがって、同一隣接ＬＳＲ間で同一ラベル空間を使用したＬＤＰセッションを複数設定することはできない（ＬＳＲ識別子を変更すれば可能ではあるが、この場合は論理的にＬＳＲを分けなければならないことになる）。
〔２〕基本ディスカバリメカニズムと拡張ディスカバリメカニズム
次に、基本ディスカバリメカニズムと拡張ディスカバリメカニズムの用途と概要について説明する。
まず、前者の「基本ディスカバリメカニズム」は、直接（物理的に）接続された隣接ＬＳＲを自動検出し、ハロー（Ｈｅｌｌｏ）隣接を確立するために用いられるものであり、後者の「拡張ディスカバリメカニズム」は、直接接続されていない隣接ＬＳＲを検出し、ハロー隣接を確立するために用いられるものである。
そして、「基本ディスカバリメカニズム」では、宛先ＩＰアドレスをマルチキャストアドレス（２２４．０．０．２）としたハローメッセージ（Ｈｅｌｌｏ Ｍｅｓｓａｇｅ）をＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）パケットにて送信することにより、Ｈｅｌｌｏ隣接を自動検出する（隣接ＬＳＲからのＨｅｌｌｏ Ｍｅｓｓａｇｅの受信により検出する）。したがって、「基本ディスカバリメカニズム」では、ハロー隣接確立のためのプロビジョニング（事前設定）が不要である。なお、ハローメッセージの送信元ＩＰアドレスには、自インタフェースのＩＰアドレスを用いるが、具体的に何を使うかは、実装事項である（例えば、当該インタフェースアドレスやループバックアドレス、ＬＤＰセッション専用アドレス等を用いることができる）。
これに対し、「拡張ディスカバリメカニズム」では、宛先ＩＰアドレスを特定のユニキャストＩＰアドレスとしたハローメッセージをＵＤＰパケットにて送信することにより、直接接続されていない隣接ＬＳＲを検出して、ハロー隣接を確立する。したがって、「拡張ディスカバリメカニズム」では、ハロー隣接確立のためのプロビジョニングが必要となる。なお、この場合も、送信元ＩＰアドレスには、自装置のＩＰアドレス（具体的に何を使うかは、実装事項）を用いる。
〔３〕ＬＤＰセッション確立シーケンス
次に、ＬＤＰセッションの確立手順について、図１６を参照しながら説明する。この図１６に示すように、ＬＤＰでは、隣接ＬＳＲ＃１−ＬＳＲ＃２間において、まず、ハローメッセージを送受信して（ステップＡ１）、Ｈｅｌｌｏ隣接を確立した後（ステップＡ２）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）メッセージの送受信を行なう（ステップＡ３，Ａ４，Ａ５）ことで、トランスポートコネクション（ＴＣＰ）を確立し（ステップＡ６）、さらに、イニシャライゼーションメッセージ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｍｅｓｓａｇｅ）を送受信して互いに所定のセッションパラメータを許容した後、定期的にキープアライブメッセージ（Ｋｅｅｐ Ａｌｉｖｅ Ｍｅｓｓａｇｅ）を送受信する（ステップＡ７〜Ａ１２）ことによって、ＬＤＰセッションを確立する（ステップＡ１３）。
ＬＤＰセッションが確立した後は、ＬＳＲ＃１−ＬＳＲ＃２間において、さらにＭＰＬＳパケット（ラベル付きパケット）のフォワーディングデシジョンに使用するＬＤＰピアのアドレスをアドレスメッセージ（Ａｄｄｒｅｓｓ Ｍｅｓｓａｇｅ）によって交換し、当該アドレスメッセージに基づいてラベルマッピングメッセージ（Ｌａｂｅｌ Ｍａｐｐｉｎｇ Ｍｅｓｓａｇｅ）を送受してラベル配付（ラベルマッピング）を行なう（ステップＡ１４〜Ａ１６）ことにより、各ＬＳＲ＃１，ＬＳＲ＃２において、配付されたラベルを付加されたＭＰＬＳパケットのフォワーディングが可能となる。
なお、現状では、後述するラベル広告モードのアンマッチは、上記イニシャライゼーションの交換まで分からない（検出できない）。
〔４〕「Ｍａｒｔｉｎｉ」方式のＭＰＬＳ Ｌ２ ＶＰＮ
次に、ＭＰＬＳ Ｌ２ ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）の１つである「Ｍａｒｔｉｎｉ」方式〔ＭＰＬＳを使用しＬ２（Ｌａｙｅｒ ２）で仮想専用線（ＰＷ：ｐｓｅｕｄｏ ｗｉｒｅ）を提供する方式〕では、新しく「Ｆｏｒｗａｒｄｉｎｇ Ｅｑｕｉｖａｌｅｎｃｅ Ｃｌａｓｓ（ＦＥＣ）」タイプとして「ＰＷ ＦＥＣ ｅｌｅｍｅｎｔ」とそれに対応するＰＷ〔旧名称はＶＣ（Ｖｉｒｔｕａｌ Ｃｈａｎｎｅｌ）〕ＴＬＶ（Ｔｙｐｅ／Ｌｅｎｇｔｈ／Ｖａｌｕｅ）を追加定義しているが、その他は基本的にＬＤＰを使用する。具体的には、「ｄｏｗｎｓｔｒｅａｍ ｕｎｓｏｌｉｃｉｔｅｄ」モードと拡張ディスカバリメカニズムを使用する。なお、「Ｍａｒｔｉｎｉ」方式の最新版は、後記の非特許文献２及び３等としてＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のｐｗｅ３ ＷＧ（Ｐｓｅｕｄｏ Ｗｉｒｅ Ｅｍｕｌａｔｉｏｎ Ｅｄｇｅ ｔｏ Ｅｄｇｅ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ）のＷＧドラフトとなっており、標準化予定である。
以下、「Ｍａｒｔｉｎｉ」方式の概要をＬＤＰセッションの確立及びＬＳＰ（Ｌａｂｅｌ Ｓｗｉｔｃｈｅｄ Ｐａｔｈ）の確立という観点から図１７に示すネットワーク構成例を用いて説明する。なお、この図１７において、ＰＥ＃１，ＰＥ＃２，ＰＥ＃３はそれぞれ他ネットワークと接続するプロバイダエッジ（Ｐｒｏｖｉｄｅｒ Ｅｄｇｅ）と呼ばれるＬＳＲ、コア（Ｃｏｒｅ）ＬＳＲはそれ以外のＬＳＲを表し、ＰＥ＃１はコアＬＳＲと、ＰＥ＃２はコアＬＳＲ及びＰＥ＃３と、ＰＥ＃３はコアＬＳＲとＰＥ＃２とそれぞれ物理的に接続（実線表示）されている。
［ＬＤＰセッションの確立］
（１）制御メッセージの通信経路の確立
下記の項目（２）以降で示されるＬＤＰセッションの確立及びＬＳＰの確立のためには、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ），ＬＤＰ等の制御メッセージが全てのＬＳＲ〔ＰＥ，コアＬＳＲ〕で送受信できる必要がある。
ここで、「Ｍａｒｔｉｎｉ」ドラフトでは、その制御メッセージのカプセリングを特に規定していない。したがって、制御メッセージには、▲１▼ＴＣＰ／ＩＰそのまま〔カプセル化なし：ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆａｓｔ）−ＩＰ，ＬＤＰ−ＴＣＰ〕の場合、▲２▼ラベル（前もって設定されたＬＳＰ中を通る）でカプセル化されている場合、▲３▼その他〔Ｌ２ＴＰ（Ｌａｙｅｒ２ ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ），ＧＲＥ（Ｇｅｎｅｒｉｃ Ｒｏｕｔｉｎｇ Ｅｎｃａｐｓｕｌａｔｉｏｎ）等〕の場合が考えられる。
上記▲２▼の場合には、何らかの方法〔スタティック，ＬＤＰ，ＣＲ（Ｃｏｎｓｔｒａｉｎｔ Ｒｏｕｔｅｄ）−ＬＤＰ，ＲＳＶＰ−ＴＥ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒ Ｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｆｏｒ ｔｒａｆｆｉｃ ｅｎｇｉｎｅｅｒｉｎｇ）等〕でＬＳＰを確立する必要がある。
（２）通常のＬＤＰセッションの確立
図１８に実線矢印１００，２００，３００，４００で示すように、全ての隣接ＬＳＲ（ＰＥ，コアＬＳＲ）間で通常のＬＤＰセッションが前記の「基本ディスカバリメカニズム」を使用して確立される。
（３）ＰＥ間のＬＤＰセッションの確立
図１８に点線矢印５００，６００，７００で示すように、全てのＰＥ（ＰＥ＃１−ＰＥ＃２，ＰＥ＃１−ＰＥ＃３，ＰＥ＃２−ＰＥ＃３）間にフルメッシュで、「拡張ディスカバリメカニズム」を使用してＬＤＰセッションを確立する。この時、それぞれのＰＥ＃１，ＰＥ＃２，ＰＥ＃３には、接続先（リモート側）のＬＳＲのＩＰアドレスが全てプロビジョニングされている必要がある。
ただし、この図１８中に示す通り、ＰＥ＃２−ＰＥ＃３間は直接接続されており、ＬＤＰセッション４００が上記「（１）制御メッセージの通信経路の確立」により既に確立しており、ＬＤＰセッション７００は新たに設定する必要がない。また、ＲＦＣ３０３６の規定では、厳密には設定できない。しかし、ＰＥ＃２，ＰＥ＃３それぞれが互いに隣接していることを知っていなければ、このセッションを設定しようとする。これに対しては、以下▲１▼〜▲３▼の実装が考えられる。
▲１▼プロビジョニングにより、隣接していることを明示し、当該セッション７００の設定を行なわない。
▲２▼ＰＥ＃２−ＰＥ＃３間の通常のＬＤＰセッション４００が既に設定されていることをチェックし、当該セッション７００の設定を行なわない。
▲３▼何もチェックせずに、当該セッション７００の設定をしようとするが、通常のＬＤＰセッション４００と同一セッションということで、結果として設定できない。
ところが、図１９において、例えばＰＥ＃２−ＰＥ＃３間のリンクが何らかの理由で使用不可となった場合は、当該ＰＥ＃２−ＰＥ＃３間で「拡張ディスカバリメカニズム」を使用してＬＤＰセッションを設定する必要がある。したがって、選択枝は、上記の▲２▼又は▲３▼となる。
上述の通り、「Ｍａｒｔｉｎｉ」方式は、制御メッセージのカプセリングを規定していないので、もし、例えば図２０に示すように、通常のＬＳＰ５００Ａ，５００Ｂ，６００Ａ，６００Ｂ，７００Ａ，７００Ｂが既に設定されている場合は、当該セッション５００，６００，７００は、そのＬＳＰ５００Ａ，５００Ｂ，６００Ａ，６００Ｂ，７００Ａ，７００Ｂ中で設定される（ＬＳＰを通してＬＤＰセッションが確立される）可能性がある（ネットワーク及び装置の実装／運用ポリシに依存する）。
なお、ＬＳＰは片方向の属性をもつので、この図２０において、ＬＳＰ５００Ａ及び５００Ｂの組がＰＥ＃１−ＰＥ＃２間の通常のＬＤＰセッション５００、ＬＳＰ６００Ａ及び６００Ｂの組がＰＥ＃１−ＰＥ＃３間の通常のＬＤＰセッション６００、ＬＳＰ７００Ａ及び７００Ｂの組がＰＥ＃２−ＰＥ＃３間の通常のＬＤＰセッション７００をそれぞれ示している。
［ＬＳＰの設定例］
（１）通常のＬＳＰの確立
ＩＰ経路に基づき、通常のＬＳＰが図２１に太実線矢印５００Ａ，５００Ｂ，６００Ａ，６００Ｂ，７００Ａ，７００Ｂで示すように確立される。ここで、ＰＥ＃２及びＰＥ＃３からＰＥ＃１に向かうＬＳＰ５００Ｂ，６００Ｂは、コアＬＳＲでマージされる。
（２）ＰＷ用のＬＳＰの確立
ＰＷ用のＬＳＰは、上述のＰＥ間に設定されたＬＤＰセッション５００，６００，７００上で、上述のＰＷ用ＦＥＣを付加した「Ｌａｂｅｌ Ｍａｐｐｉｎｇ」メッセージでラベルを配付することにより確立される。ここで、ＰＷは、同一ＰＥ間の互いに逆向きのＰＷ用ＬＳＰのペア（図２１に示すＰＷ ＬＳＰ５００ａ及び５００ｂ又はＰＷ用ＬＳＰ６００ａ及び６００ｂ又はＰＷ用ＬＳＰ７００ａ及び７００ｂ）からなり、ＰＷ用ＦＥＣ中のＰＷ ＩＤによって対応付けられる。このＰＷ ＩＤは、双方のＰＥで予めプロビジョニングしておく必要がある。なお、図２１において、ＰＥ＃２−ＰＥ＃３間のＰＷ用ＬＳＰ７００ａ，７００ｂは、図示の通りトンネルＬＳＰ７００Ａ，７００Ｂ中を通してもよいし、トンネルＬＳＰ７００Ａ，７００Ｂとは独立して設定してもよい。もっとも、トンネルＬＳＰ７００Ａ，７００Ｂ中を通すことにしても、ＰＨＰを使用すればトンネルラベルは付加されない。
また、「Ｍａｒｔｉｎｉ」方式では、ＰＷ用のＬＳＰのトンネリングに関しても規定していない。そこで、管理／運用上（例えば、制御メッセージとユーザデータを分離し管理を容易にする）又はサービス上〔例えば、ユーザデータに関するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）／ＣｏＳ（Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ）の提供〕の理由からトンネルＬＳＰに関して様々なバリエーションが考えられる。以下にそのバリエーションを示す。なお、ここでは、詳しく述べないが、トンネルはＬＳＰ以外を用いて設定しても良い。
▲１▼通常のＬＳＰ中での確立
ＰＥ間のＬＤＰセッションを使用して、ＰＷ用ＬＳＰを確立する。ここで、ＰＥ＃１−ＰＥ＃２間及びＰＥ＃１−ＰＥ＃３間の直接の経路は、図２１の通常のＬＳＰ５００Ａ，５００Ｂ，６００Ａ，６００Ｂ（５００Ｂ及び６００ＢはコアＬＳＲでマージされている）しか存在しないので、必然的に、これらのＬＳＰ５００Ａ，５００Ｂ，６００Ａ，６００ＢをトンネルＬＳＰとして使用することになる。
一方、ＰＥ＃２−ＰＥ＃３間については、直接の経路として、ＩＰの経路と通常のＬＳＰ７００Ａ，７００Ｂとが存在するので、どちらを使用するかをそのネットワークまたは装置の選択ポリシにより決定する必要がある。以下にその特徴を示す。
・容易にＬＳＰの設定が可能（特別なトンネルＬＳＰの設定の必要がない）。
・制御メッセージとユーザデータが同一トンネル中で混在する可能性がある。
・当該トンネルＬＳＰは、ベストエフォートサービスしか実現できない。
▲２▼ＰＷ専用ＬＳＰ中での確立（その１：スタティック設定したトンネルＬＳＰで設定）
上述した通常のＬＳＰと同等のＬＳＰをスタティックに設定する。この場合、以下の特徴がある。
・トンネルＬＳＰの設定のために全てのＰＥ及びＬＳＲにプロビジョニングが必要）。
・制御メッセージとユーザデータの分離が可能。
・経路をＩＰ経路と独立に設定できる。
・ＱｏＳ／ＣｏＳの適用が可能。
▲３▼ＰＷ専用ＬＳＰ中での確立（その２：ＣＲ−ＬＤＰ／ＲＳＶＰ−ＴＥで設定したトンネルＬＳＰで設定）
上述した通常のＬＳＰと同等のＬＳＰをＣＲ−ＬＤＰ／ＲＳＶＰ−ＴＥで設定する。この場合、以下の特徴がある。
・トンネルＬＳＰの設定のために全てのＰＥにプロビジョニングが必要となる。
・制御メッセージとユーザデータの分離が可能。
・経路をＩＰ経路と独立に設定できる。
・ＱｏＳ／ＣｏＳの適用が可能。
▲４▼ＰＷ専用ＬＳＰ中での確立（その３：ＬＤＰで設定したトンネルＬＳＰで設定）
通常に設定されたＬＳＰがＰＥ間に複数存在する場合に、その中で、使用されないＬＳＰをＰＷ専用ＬＳＰとして使用する。この場合、以下の特徴がある。
・プロビジョニングが不要。
・一般的には使用できない（上記のＰＥ＃１−ＰＥ＃２，ＰＥ＃１−ＰＥ＃３のようにＩＰ経路（または物理的経路）が１つしか存在しない場合、同一ＦＥＣに対しては複数のＬＳＰを設定できないため：逆にいえば、ＦＥＣを分ければ可能）。
・制御メッセージとユーザデータの分離が可能。
・経路をＩＰ経路と独立に選択できない。
・ベストエフォートサービスしか実現できない。
以上から、既存のＭＰＬＳやその拡張方式には、次のような特徴がある。
（１）制御メッセージの経路／カプセリングに様々なバリエーションが存在する（場合によっては何らかのプロビジョニングが必要）。
（２）ＰＷが通るトンネル（ＬＳＰ）にも様々なバリエーションがある（場合によっては何らかのプロビジョニングが必要）。
（３）リモート側のＬＤＰセッション用のアドレスをプロビジョニングする必要がある（リモート側と直接接続していないため）。
（４）リモート側のアドレスとして、誤って「Ｍａｒｔｉｎｉ」を実装しないＬＤＰエンティティをプロビジョニングしてしまえば、ラベルマッピングメッセージを送受信するまでリモート側のＬＤＰエンティティが「ＰＷ ＦＥＣ ｅｌｅｍｅｎｔ」を処理できるかどうかが分からない（または、処理するようにプロビジョニングされているかどうか分からない）。
（５）ＰＷ ＩＤは、関係ＰＥ双方でプロビジョニングされ、ラベルマッピングメッセージで通知される。したがって、このプロビジョニングの誤りもラベルマッピングメッセージを送受信するまで分からない（検出できない）。
ところで、主に、キャリアネットワークで普及しているＭＰＬＳのシグナリングプロトコル（Ｓｉｇｎａｌｉｎｇ ｐｒｏｔｏｃｏｌ）として最も普及しているＬＤＰ（Ｌａｂｅｌ ｄｉｓｔｒｉｂｕｔｉｏｎ ｐｒｏｔｏｃｏｌ）のセッションは、同一隣接ＬＳＲとの間で複数設定することはできない（同じラベル空間を使用している場合）し、同一隣接ＬＳＲ間で設定されたＬＤＰセッションを使用するアプリケーション又はその用途を明示的に識別することもできない。
したがって、そのセッションの両端のＬＤＰエンティティが、「Ｍａｒｔｉｎｉ」方式の拡張を実装しているかどうか、または、実装していてもそれを使用するようにプロビジョニングされているかどうかが、ラベルマッピングのフェーズまで分からない。また、双方が、「Ｍａｒｔｉｎｉ」方式を実装し、使用するように設定されていたとしても、上記の（１）〜（５）に示す、「Ｍａｒｔｉｎｉ」方式のＭＰＬＳ Ｌ２ ＶＰＮでの各種プロビジョニング情報が誤っていた場合、それをプロトコル上で検出できず、誤動作するか、または、検出できてもＬＤＰセッションの確立時に確実に検出することはできない。
以下に、具体例を図１７に示すネットワーク構成を参照しながら説明する。
（１）前提条件
▲１▼ＰＥ＃１は、ＩＰパケット（制御メッセージ）をそのまま送受信できない装置であり、ＭＰＬＳでカプセル化したＩＰパケットしか送受信できない装置である（ブリッジベースの装置に「Ｍａｒｔｉｎｉ」方式を実装した場合、ハードウェアの制約及び又は実装コスト面からこのような実装が考えられる）。また、この装置は、上記ＬＳＰ以外については、ＬＤＰによって動的にＬＳＰを設定できる能力をもつものとする。
▲２▼ＰＥ＃２，ＰＥ＃３，コアＬＳＲは、ＩＰパケットをそのまま送受信可能であり、ＭＰＬＳでカプセル化したＩＰパケットも送受信可能である。
▲３▼ネットワークの運用ポリシとして、制御メッセージは、ＬＳＰ中で送受信し、さらに、ＰＷ用トンネルＬＳＰと前記制御メッセージ用ＬＳＰを分離する。
（２）上記の前提条件▲１▼，▲２▼より、ＰＥ＃１とコアＬＳＲとの間には制御メッセージ用のＬＳＰがスタティックに設定される必要がある。また、ＰＥ＃２，ＰＥ＃３，コアＬＳＲには、制御メッセージをＬＳＰ中で送受信するという運用ポリシの設定が必要となる。この時、明示的なプロビジョニング、または、ＩＰ経路とＬＳＰ経路の優先度の設定などが考えられる。
（３）上記の前提条件▲３▼より、制御メッセージ用ＬＳＰとは別にＰＥ＃１，ＰＥ＃２，ＰＥ＃３間にフルメッシュで、ＰＷ用のトンネルＬＳＰを設定する必要がある。
（４）ＰＥ＃１，ＰＥ＃２，ＰＥ＃３は、上記（３）項で設定したＬＳＰ中には制御メッセージを送信してはいけない。
以上のようなネットワーク条件において、以下の課題がある。
▲１▼ＰＥ＃２，ＰＥ＃３，コアＬＳＲに関して、制御メッセージをＬＳＰ中で送受信するという運用ポリシの設定が誤っていると、ＰＥ＃２−ＰＥ＃３間のＬＤＰセッションは確立されるが、ＰＥ＃１−ＰＥ＃２，ＰＥ＃１−ＰＥ＃３，ＰＥ＃２−ＰＥ＃３間の全て、又はいずれかのＬＤＰセッションが確立されない。
▲２▼ＰＥ＃１，ＰＥ＃２，ＰＥ＃３に関して、ＰＷ用トンネルＬＳＰと制御メッセージ用ＬＳＰを分離するというポリシの設定が誤っていると、ＰＷ用トンネルＬＳＰが設定できなかったり、ＰＷ用トンネルＬＳＰが設定できても、その両端で認識がずれて、一方は制御メッセージ用のＬＳＰを使用してＰＷ用ＬＳＰを設定し、他方はＰＷ用トンネルＬＳＰを使用してＰＷ用ＬＳＰを設定してしまい、結果として、正常にＰＷ中のフレームが処理されなかったりする場合がある。
▲３▼ＰＥ＃１−ＰＥ＃２，ＰＥ＃１−ＰＥ＃３，ＰＥ＃２−ＰＥ＃３間のＬＤＰセッション設定時にリモート側のアドレスのプロビジョニングが誤っていると、当該ＬＤＰセッションが設定されない。または、実装によっては、ＬＤＰセッション自体は設定されるが、当該セッションを使用してＰＷ ＬＳＰが設定されない。
▲４▼ＰＥ＃１−ＰＥ＃２，ＰＥ＃１−ＰＥ＃３，ＰＥ＃２−ＰＥ＃３間それぞれのＰＷ ＩＤのプロビジョニングに誤りがあれば、ＰＷが正しく設定されない。そして、それは、ＬＤＰではラベルマッピングのフェーズまで分からない。
一方、ＭＰＬＳのアプリケーションはＬＤＰを拡張し、または、そのまま使用し、続々と標準化され、また、独自に開発されている。ここで、そのアプリケーションによっては、同一ＬＤＰセッションを利用することができないものがある。例えば、ＬＤＰのラベル広告モードが「Ｄｏｗｎｓｔｒｅａｍ Ｕｎｓｏｌｉｃｉｔｅｄ」モードと「Ｄｏｗｎｓｔｒｅａｍ ｏｎ Ｄｅｍａｎｄ」では互換性がないので、アプリケーションがそれぞれ別のモードを使用する場合は同一ＬＤＰセッションを使用することができないし、プロトコルとしては、同一ＬＤＰセッションを利用することができても、管理，運用，保守の側面から、アプリケーション及び／又はその用途毎にＬＤＰセッションを分離することが望まれることがある。
例えば、トラヒックエンジニアリングと「Ｍａｒｔｉｎｉ」方式とをそれぞれ実装しようとしても、トラヒックエンジニアリングは通常「Ｄｏｗｎｓｔｒｅａｍ ｏｎ Ｄｅｍａｎｄ」を使用し、「Ｍａｒｔｉｎｉ」方式は、「Ｄｏｗｎｓｔｒｅａｍ Ｕｎｓｏｌｉｃｉｔｅｄ」モードを使用するので、実装できない。また、例えば「Ｍａｒｔｉｎｉ」方式の実装において、管理，運用，保守の側面から制御メッセージ用のＬＳＰトンネルとＰＷ用のＬＳＰトンネルを、ＬＤＰを使用して独立に設定しようとしてもできない。
特開２０００−２３２４５４号 Ｌ．Ａｎｄｅｒｓｓｏｎ ｅｔ ａｌ．，"ＬＤＰ ｓｐｅｃｉｆｉｃａｔｉｏｎ"（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ），［ｏｎｌｉｎｅ］，Ｊａｎｕａｒｙ ２００３，Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｏｆ ＩＥＴＦ［平成１５年６月１６日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３０３６．ｔｘｔ＞． Ｌｕｃａ Ｍａｒｔｉｎｉ ｅｔ ａｌ．，"Ｔｒａｎｓｐｏｒｔ ｏｆ Ｌａｙｅｒ ２ Ｆｒａｍｅｓ Ｏｖｅｒ ＭＰＬＳ"（ｄｒａｆｔ−ｉｅｔｆ−ｐｗｅ３−ｃｏｎｔｒｏｌ−ｐｒｏｔｏｃｏｌ−０１．ｔｘｔ），Ｎｏｖｅｍｂｅｒ ２００２，Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｏｆ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）． Ｌｕｃａ Ｍａｒｔｉｎｉ ｅｔ ａｌ．，"Ｅｎｃａｐｓｕｌａｔｉｏｎ Ｍｅｔｈｏｄｓ ｆｏｒ Ｔｒａｎｓｐｏｒｔ ｏｆ Ｅｔｈｅｒｎｅｔ Ｆｒａｍｅｓ Ｏｖｅｒ ＩＰ／ＭＰＬＳ Ｎｅｔｗｏｒｋｓ"（ｄｒａｆｔ−ｉｅｔｆ−ｐｗｅ３−ｅｔｈｅｒｎｅｔ−ｅｎｃａｐ−０２．ｔｘｔ），［ｏｎｌｉｎｅ］，Ｆｅｂｒｕａｒｙ ２００３，Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ｏｆ ＩＥＴＦ［平成１５年６月１６日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｐｗｅ３−ｅｔｈｅｒｎｅｔ−ｅｎｃａｐ−０２．ｔｘｔ＞．

本発明は、以上のような課題に鑑み創案されたもので、同一隣接ＬＳＲ間で、同じラベル空間を使用したＬＤＰセッションを複数設定することを可能とし、また、そのセッションを使用するアプリケーション及び／又はその用途を明示的に示すことを可能とし、ＬＤＰセッションを誤りなく接続することにより、誤プロビジョニング及び／又はこれによるセッションの誤接続をセッション確立時に早期に検出できるようにすることを目的とする。
また、プロビジョニングの誤りによるＭＰＬＳ及びアプリケーションの誤動作を防止し、さらに、リモート側ＬＳＲに関するプロビジョニング情報を自動検出し、リモート側情報のプロビジョニングを無くし（あるいは減らし）て、プロビジョニングミスによる誤接続又は誤動作を削減することも目的とする。

上記の目的を達成するために、本発明のラベルスイッチネットワークにおけるセッション確立方法は、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報を付加して該メッセージの送受を行ない、同一隣接ラベルスイッチノードが、それぞれ、該セッション識別情報に基づいて、該同一隣接ラベルスイッチノード間に同一ラベル空間で使用する複数のセッションを確立することを特徴としている。
また、本発明のラベルスイッチネットワークにおけるセッション確立方法は、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、該隣接ラベルスイッチノード間で確立すべきセッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報を付加して該メッセージの送受を行ない、該隣接ラベルスイッチノードが、それぞれ、該セッションタイプ情報に基づいて、該隣接ラベルスイッチノード間に該セッションタイプ情報に応じた該セッションを確立することを特徴としている。
さらに、本発明のラベルスイッチネットワークにおけるセッション確立方法は、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報と、当該セッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して該メッセージの送受を行ない、該同一隣接ラベルスイッチノードが、それぞれ、該セッション識別情報及び該セッションタイプ情報に基づいて、該同一隣接ラベルスイッチノード間に同一ラベル空間で使用する、該セッションタイプ情報に応じた複数のセッションを確立することを特徴としている。
ここで、該メッセージとしてのハローメッセージに該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノード間のハロー隣接確立時に該セッションタイプ情報を該隣接ラベルスイッチノード間で交換するようにしてもよいし、該メッセージとしてのイニシャライゼーションメッセージに、該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノード間のセッション確立時に該セッションタイプ情報を該隣接ラベルスイッチノード間で交換するようにしてもよい。
また、隣接ラベルスイッチノード間で該セッションを確立する際に、該ラベル配付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに付加して交換するようにしてもよい。
さらに、本発明のラベルスイッチノードは、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するものであって、該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報を付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッション識別情報に基づいて、該隣接ラベルスイッチノードとの間に同一ラベル空間で使用する複数セッションの確立を制御するセッション確立制御部とをそなえたことを特徴としている。
また、本発明のラベルスイッチノードは、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するものであって、該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、該隣接ラベルスイッチノードとの間で確立すべきセッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報を付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッションタイプ情報に基づいて、該隣接ラベルスイッチノードとの間に該セッションタイプ情報に応じた該セッションの確立を制御するセッション確立制御部とをそなえたことを特徴としている。
さらに、本発明のラベルスイッチノードは、所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するものであって、該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、該隣接ラベルスイッチノードとの間に確立すべきセッションを識別するセッション識別情報と、当該セッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッション識別情報及びセッションタイプ情報に基づいて、該隣接ラベルスイッチノードとの間に同一ラベル空間で使用する、該セッションタイプ情報に応じた複数セッションの確立を制御するセッション確立制御部とをそなえたことを特徴としている。
ここで、該ラベル配付プロトコル処理部は、該ラベル配付プロトコルの該メッセージとしてのハローメッセージに該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノードとの間のハロー隣接確立時に該セッションタイプ情報を該隣接ラベルスイッチノードとの間で交換するハローメッセージ処理部をそなえて構成してもよい。
また、該ラベル配付プロトコル処理部は、該ラベル配付プロトコルの該メッセージとしてのイニシャライゼーションメッセージに、該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノードとの間のセッション確立時に該セッションタイプ情報を該隣接ラベルスイッチノードとの間で交換するイニシャライゼーションメッセージ処理部をそなえて構成してもよい。
さらに、該ラベル配付プロトコル処理部は、該ラベル配付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに付加して交換するプロビジョニング情報交換処理部をそなえて構成してもよい。
また、該ラベル配付プロトコル処理部は、該隣接ラベルスイッチノードとの間で該セッション確立制御部により該セッションを確立する際に、予め当該隣接ラベルスイッチノードとの間にトンネルラベルスイッチパスを設定するトンネルラベルスイッチパス設定部をそなえていてもよく、この場合、該プロビジョニング情報交換処理部は、該トンネルラベルスイッチパス設定部により設定された該トンネルラベルスイッチパスを通じて該プロビジョニング情報の付加された該メッセージを交換するように構成してもよい。
さらに、該プロビジョニング情報交換処理部は、該隣接ラベルスイッチノード間で該ラベル配付プロトコルに従って送受するイニシャライゼーションメッセージ及びアドレスメッセージのいずれか一方又は双方に、該プロビジョニング情報を転送するＴＬＶを追加するように構成してもよい。
また、該プロビジョニング情報交換処理部は、該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の転送用のメッセージを生成するように構成してもよいし、該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の撤回用のメッセージを生成するように構成してもよい。

図１は本発明の一実施形態としてのＭＰＬＳ網（ラベルスイッチネットワーク）の構成を示す図である。
図２は本実施形態のＬＳＲの構成を示す機能ブロック図である。
図３は本実施形態のＬＤＰ ＰＤＵの拡張例を説明するための図である。
図４は本実施形態のセッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）ＴＬＶの新規定義例を説明するためのフォーマット図である。
図５は本実施形態のアプリケーションタイプ（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ）ＴＬＶの新規定義例を説明するためのフォーマット図である。
図６は本実施形態のセッション名（Ｓｅｓｓｉｏｎ Ｎａｍｅ）ＴＬＶの新規定義例を説明するためのフォーマット図である。
図７は本実施形態のハローメッセージ（Ｈｅｌｌｏ Ｍｅｓｓａｇｅ）の拡張例を説明するためのフォーマット図である。
図８は本実施形態の共通ハローパラメータ（Ｃｏｍｍｏｎ Ｈｅｌｌｏ Ｐａｒａｍｅｔｅｒｓ）ＴＬＶを説明するためのフォーマット図である。
図９は本実施形態のイニシャライゼーションメッセージ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｍｅｓｓａｇｅ）の拡張例１を説明するためのフォーマット図である。
図１０は本実施形態の共通セッションパラメータ（Ｃｏｍｍｏｎ Ｓｅｓｓｉｏｎ Ｐａｒａｍｅｔｅｒｓ）ＴＬＶを説明するためのフォーマット図である。
図１１は本実施形態のプロビジョニング情報（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）ＴＬＶの新規定義例を説明するためのフォーマット図である。
図１２は本実施形態のＰＷパラメータ（Ｐｓｅｕｄｏ Ｗｉｒｅ ｐａｒａｍｅｔｅｒ）ＴＬＶを説明するためのフォーマット図である。
図１３は本実施形態のプロビジョニングメッセージ（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｍｅｓｓａｇｅ）の新規追加例を説明するためのフォーマット図である。
図１４は本実施形態のアドレスメッセージ（Ａｄｄｒｅｓｓ Ｍｅｓｓａｇｅ）の拡張例を説明するためのフォーマット図である。
図１５は本実施形態のＭＰＬＳ網におけるＬＤＰセッション確立手順を説明するためのシーケンス図である。
図１６は従来のＭＰＬＳ網におけるＬＤＰセッション確立手順を説明するためのシーケンス図である。
図１７〜図２１はそれぞれ従来の「Ｍａｒｔｉｎｉ」方式のＬＤＰセッション及びＬＳＰの確立を説明するためのネットワーク構成例を示す図である。

以下、本発明の実施の形態について、図面を用いて説明する。
図１は本発明の一実施形態としてのＭＰＬＳ網（ラベルスイッチネットワーク）の構成を示す図で、この図１に示すＭＰＬＳ網１は、ＭＰＬＳ機能をサポートする複数のラベルスイッチノードとしてのＬＳＲ１１がメッシュ状に相互に接続されて構築されている。そして、このＭＰＬＳ網１には、外部網２，３，４を構成する通常のルータ（又は、ブリッジ）２１，３１，４１を介して当該外部網２，３，４と接続されている。なお、外部網２，３，４〔ルータ（又は、ブリッジ）２１，３１，４１〕との接続部分に位置するＬＳＲ１１は特にＬＥＲ（Ｌａｂｅｌ Ｅｄｇｅ Ｒｏｕｔｅｒ）（ＩＰ−ＶＰＮでのＰＥに相当する）と呼ばれ、それ以外のＬＳＲ１１がコアＬＳＲと呼ばれる。
このようなネットワーク構成において、本実施形態では、（１）同一隣接ＬＳＲ１１間で複数のＬＤＰセッションの確立を可能とするとともに、（２）ＬＤＰセッションのアプリケーション及び／又は用途を明確に識別できるようにし、また、（３）ＬＳＲ１１のプロビジョニング情報の自動検出を可能とし、プロビジョニング情報の誤りによる誤配線（誤接続）及び／又はプロビジョニング情報の設定ミスを検出できるようになっている。
このため、本実施形態のＬＳＲ１１は、それぞれ、その要部に着目すると、例えば図２に示すように、ＭＰＬＳ Ｌ２ ＶＰＮアプリケーション部１１１，トラヒックエンジニアリングアプリケーション部１１２，ＣＬ／ＮＭＳインタフェース部１１３，プロビジョニング情報管理部１１４，ＭＰＬＳ処理部１１５，ＩＰルーティング処理部１１６，トポロジー情報管理部１１７，ラベル配付用シグナリング処理部１１８，ラベル管理部１１９，ＭＡＣフィルタリングデータベース処理部１２０，ラベルスイッチング処理部１２１，スイッチ制御部１２２及び回線インタフェース部１２３などをそなえて構成されている。なお、この図２において、実線で示すラインはこれらの機能ブロック間のインタフェースを表し、点線矢印で示すラインは当該機能ブロック間のデータ参照（アクセス）経路を表している。
ここで、ＭＰＬＳ Ｌ２ ＶＰＮアプリケーション部１１１は、プロビジョニング情報管理部１１４が管理するプロビジョニング情報（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）に従って、ＭＰＬＳ処理部１１５に対して、必要に応じてラベル配付用シグナリングのセッションの確立／解放、トンネルＬＳＰの確立／解放、ＰＷ ＬＳＰの確立／解放及び当該トンネルＬＳＰとＰＷ ＬＳＰとのマッピング及び／又は当該ＰＷ ＬＳＰとアタッチメントサーキットとのマッピング等を指示するためのもので、本実施形態では、以下のような機能拡張を行なっている。
（１）ラベル配付用シグナリング（ＬＤＰ）のセッションの確立指示時に当該セッションを識別するためのセッション識別情報（セッションＩＤ）を付加する。本セッションＩＤは当該アプリケーション部１１１で自動生成しても良いし、プロビジョニング（プロビジョニング情報管理部１１４で管理）しても良い。
（２）ラベル配付用シグナリングのセッションの確立指示時にリモート側のプロビジョニング情報の取得指示を追加する。
（３）ラベル配付用シグナリングのセッションの確立指示時にリモート側装置のプロビジョニング情報と当該装置のプロビジョニング情報のチェック指示を追加する。さらに、チェック結果にしたがって、当該セッションの確立／解放を判断する。
また、トラヒックエンジニアリングアプリケーション部１１２は、プロビジョニング情報管理部１１４が管理するプロビジョニング情報に従って、ＭＰＬＳ処理部１１５に対して、必要に応じてラベル配付用シグナリングのセッションの確立／解放、負荷分散用ＬＳＰの確立／解放、負荷分散パラメータの指示（マッピングする複数のＬＳＰ，負荷分散上限閾値，負荷分散上限閾値等）を行なうためのもので、本実施形態では、ラベル配付用シグナリングのセッションの確立指示時にセッションＩＤを付加できるよう機能拡張している。なお、本セッションＩＤも当該アプリケーション部１１２で自動生成しても良いし、プロビジョニングしても良い。
さらに、ＣＬ／ＮＭＳインタフェース部１１３は、ＣＬ（コマンドライン）及び／又はＮＭＳ（ネットワーク管理システム）とのインタフェースを司るもので、ここでは、プロビジョニング情報管理部１１４と連携して、管理情報の設定及び表示等を行なう機能を有している。また、プロビジョニング情報管理部１１４は、このＣＬ／ＮＭＳインタフェース部１１３からの指示に従い、プロビジョニング情報を設定／表示すると共に当該プロビジョニング情報を各機能ブロックに対して参照可能とするものである。なお、リモート側プロビジョニング情報に関しては、対応機能ブロックからの設定も可能としても良い（管理対象としても良い）。
ＭＰＬＳ処理部１１５は、各種アプリケーション（ここでは、ＭＰＬＳ Ｌ２ ＶＰＮアプリケーション部１１１及びトラヒックエンジニアリングアプリケーション部１１２）からの指示に従い、ラベル配付用シグナリングのセッションの確立／解放、各種ＬＳＰの確立／解放をラベル配付用シグナリング処理部１１８に指示し、又は、リモート側ＬＳＲからのラベル配付用シグナリングのセッションの確立／解放、各種ＬＳＰの確立／解放要求を、ラベル配付用シグナリング処理部１１８を経由して受信するものである。また、当該ＬＳＰの確立／解放及びアプリケーションからの指示パラメータに従って、ラベルスイッチング処理部１２１に対して、ラベルフォワーディングテーブルの設定／変更／解放等を指示する機能も有する。
つまり、このＭＰＬＳ処理部１１５は、後述するラベル配付用シグナリング処理部１１８経由で隣接ＬＳＲから受信するラベル配付用シグナリングメッセージ（ＬＤＰメッセージ）に応じて必要なＬＤＰセッションの確立を制御するセッション確立制御部としての機能を果たすものである。ただし、本実施形態においては、下記のような機能拡張も行なっている。
（１）ラベル配付用シグナリングのセッションの確立指示時にセッションＩＤを付加する。
（２）ラベル配付用シグナリングのセッションの確立指示時にリモート（相手）側装置（ＬＳＲ）のプロビジョニング情報の取得指示を追加する。
（３）上記リモート側装置のプロビジョニング情報を必要に応じてチェックし、その結果を指定アプリケーションに通知し、その後の指示を仰ぐ。
次に、ＩＰルーティング処理部１１６は、トポロジー情報管理部１１７と連携して、ＩＰルーティングプロトコルを実行することにより、ネットワーク１の動的なトポロジー情報を維持するものであり、トポロジー情報管理部１１７は、当該ＩＰルーチング処理部１１６と連携して、ネットワークの動的なトポロジー情報を維持・管理するとともに、当該トポロジー情報及びその変化を必要な機能ブロックに対して提供するものである。
ラベル配付用シグナリング処理部（ラベル配付プロトコル処理部）１１８は、ＭＰＬＳ処理部１１５からの指示により、ラベル配付用シグナリングのセッションの確立／解放、各種ＬＳＰの確立／解放を実施するとともに、リモート側装置からのラベル配付用シグナリングのセッションの確立／解放、各種ＬＳＰの確立／解放要求をＭＰＬＳ処理部１１５に通知し、その後の処理の指示を仰ぐもので、ここでは、ＬＤＰメッセージを拡張して、上記セッションＩＤや、確立するＬＤＰセッションのアプリケーション及びその用途のいずれか一方又は双方を明示する情報（セッションタイプ情報）、プロビジョニング情報等を付与・交換できるように種々の機能拡張（ＬＤＰの拡張：詳細は後述）を行なっている。
ラベル管理部１１９は、上記ラベル配付用シグナリング処理部１１８に対して自装置が割り当てるラベルの空塞管理機能を提供するものであり、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）フィルタリングデータベース処理部１２０は、プロビジョニング情報管理部１１４及び回線インタフェース処理部１２３（＃１〜＃ｍ：ｍは自然数）と連携して、ＭＡＣフィルタリングデータベースの原本を管理し、各回線インタフェース処理部１２３に対して、必要なＭＡＣフィルタリングデータベースを提供するとともにスイッチ制御部１２２に対して、必要なスイッチングを指示するためのものである。
ラベルスイッチング処理部１２１は、ＭＰＬＳ処理部１１５からの指示に従い、ラベルフォワーディングテーブルの原本を管理し、各回線インタフェース処理部１２３に対して、必要なラベルフォワーディングテーブルを提供するとともにスイッチ制御部１２２に対して、必要なスイッチングを指示するためのものである。
スイッチ制御部１２２は、ＭＡＣフィルタリングデータベース処理部１２０及びラベルスイッチング処理部１２１からの指示に従い、各回線インタフェース処理部１２３及び自装置内の必要な機能ブロックとのスイッチングを行なうためのものであり、回線インタフェース処理部１２３は、それぞれ、１以上の回線（＃１〜＃ｎ）を収容し、ＭＡＣフィルタリングデータベース処理部１２０及びラベルスイッチング処理部１２１からの指示に従い、ＭＡＣフィルタリングデータベース／ラベルフォワーディングテーブル（図示省略）を参照することによるフレームの送受信を行なうものである。
次に、以下では、上述した各種機能拡張の具体例について詳述する。
▲１▼まず、同一隣接ＬＳＲ１１間で複数のＬＤＰセッションの確立を可能とするために、ＬＤＰ（ＲＦＣ３０３６）を拡張する。その具体例としては、以下の＜１＞及び＜２＞に示す方式が考えられる。
＜１＞ＬＤＰ識別子の拡張（変更）
ＬＤＰ ＰＤＵのフォーマットは変えずに、ＬＤＰ識別子を拡張（変更）し、セッション識別情報（セッションＩＤ）により同一隣接ＬＳＲ１１間の複数のＬＤＰセッションを識別可能とする。
この場合、ＬＤＰ識別子は、ＲＦＣ３０３６では、「ＬＳＲ ＩＤ」（４オクテットで構成されるＬＳＲを識別するグローバルな値）と、「Ｌａｂｅｌ ｓｐａｃｅ ＩＤ」（２ビットで構成されるラベル空間を識別するための値で、“０”で「ｐｌａｔｆｏｒｍ−ｗｉｄｅ」ラベル空間、“１”で「ｐｅｒ ｉｎｔｅｒｆａｃｅ」ラベル空間を表し、“３”，“４”はリザーブを表す）とで構成されるが、１４ビットで構成される「Ｓｅｓｓｉｏｎ ＩＤ」を新たに定義し、「ｐｌａｔｆｏｒｍ−ｗｉｄｅ」ラベル空間ではセッション番号、「ｐｅｒ ｉｎｔｅｒｆａｃｅ」ラベル空間では最初の１０ビットを「Ｉｎｔｅｒｆａｃｅ ＩＤ」、残りをセッション番号として表示する。
＜２＞ＬＤＰ ＰＤＵの拡張
例えば図３に示すように、ＬＤＰ ＰＤＵのフォーマットにセッション（Ｓｅｓｓｉｏｎ）ＩＤフィールド１２を新たに追加定義する。
▲２▼また、確立するＬＤＰセッションのアプリケーション及びその用途のいずれか一方又は双方を明示するＴＬＶをＬＤＰメッセージ（例えば、ハローメッセージ）に追加することにより、ハロー隣接確立時にそのセッションのアプリケーション及び／又は用途を隣接ＬＳＲ１１間で交換して、正しくセッションを確立し、誤接続を防止する（なお、当該ＴＬＶはイニシャライゼーションメッセージに追加しても良い）。
具体的には、セッションのタイプ又は用途を示す「セッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）ＴＬＶ」及び／又はこのセッションを使用するアプリケーションのタイプを示す「アプリケーションタイプ（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ）ＴＬＶ」及び／又はこのセッションの名前を示す「セッション名（Ｓｅｓｓｉｏｎ ｎａｍｅ）ＴＬＶ」を新しく定義し（これらのＴＬＶを「セッションタイプ情報」と総称する）、例えば、ハローメッセージ又はイニシャライゼーションメッセージにより当該ＴＬＶを（ラベル配付用シグナリング処理部１１８を通じて）送受信し、一致する場合だけハロー隣接又はＬＤＰセッションを確立する。ただし、「Ｓｅｓｓｉｏｎ ｎａｍｅ ＴＬＶ」については、これを保守運用面でだけで使用する場合は、この限りではない。
つまり、本実施形態のラベル配付用シグナリング処理部１１８は、ＬＤＰメッセージとしてのハローメッセージに「セッションタイプ情報」を付加することにより、隣接ＬＳＲとの間のハロー隣接確立時に当該情報を交換するハローメッセージ処理部としての機能を有していることになる。
また、イニシャライゼーションメッセージの共通パラメータＴＬＶ（Ｃｏｍｍｏｎ Ｓｅｓｓｉｏｎ Ｐａｒａｍｅｔｅｒｓ ＴＬＶ）でセッションのタイプ又は用途を示す「セッションタイプ」及び／又は当該セッションを使用するアプリケーションのタイプを示す「Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ」及び／又は当該セッションの名前を示す「Ｓｅｓｓｉｏｎ ｎａｍｅ」パラメータを新しく定義して、上記パラメータを送受信し、一致する場合だけハロー隣接又はＬＤＰセッションを確立するようにすることもできる。ただし、「Ｓｅｓｓｉｏｎ ｎａｍｅ ＴＬＶ」については、これを保守運用面でだけで使用する場合は、この限りではない。
つまり、この場合、ラベル配付用シグナリング処理部１１８は、ＬＤＰメッセージとしてのイニシャライゼーションメッセージに「セッションタイプ情報」を付加することにより、隣接ＬＳＲとの間のハロー隣接確立時に当該情報を交換するイニシャライゼーションメッセージ処理部としての機能を有していることになる。
なお、以上のメッセージはトンネルＬＳＰ中で送受信しても良いし、ＩＰ経路で送受信しても良い。
以下に、上記メッセージ、ＴＬＶ、パラメータの追加、変更例を示す。
＜３＞「セッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）ＴＬＶ」の新規定義例
図４に「セッションタイプＴＬＶ」の新規定義例を示す。この図４に示すように、「セッションタイプＴＬＶ」には、ＴＬＶの種別を表示する「ＴＬＶ種別」フィールド２１，「長さ（Ｌｅｎｇｔｈ）」フィールド２２及び「セッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）」フィールド２３を用意し、「ＴＬＶ種別」フィールド２１には当該ＴＬＶの種別（この場合は「セッションタイプＴＹＰＥ」）タイプを示す情報、「長さ（Ｌｅｎｇｔｈ）」フィールド２２には当該ＴＬＶの長さを示す情報、「セッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）」フィールド２３には、設定するセッションのタイプを示す情報をそれぞれ設定する。
例えば、“０”で通常のＬＤＰセッション（ｂａｓｉｃ ｌｄｐ ｓｅｓｓｉｏｎ）、“１”で制御メッセージ交換用のＬＳＰのためのＬＤＰセッション（ｌｄｐ ｓｅｓｓｉｏｎ ｆｏｒ ｃｏｎｔｒｏｌ ｍｅｓｓａｇｅ）、“２”でデータ交換用のＬＳＰのためのＬＤＰセッション（ｌｄｐ ｓｅｓｓｉｏｎ ｆｏｒ ｄａｔａ ｐｌａｎｅ ｍｅｓｓａｇｅ）を表すものとする（他はリザーブとする）。なお、「Ｓｅｓｓｉｏｎ ＴＹＰＥ」は図４に示すようにサポートするタイプを複数設定することが可能である。
＜４＞「アプリケーションタイプ（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ）ＴＬＶ」の新規定義例
次に、図５に「アプリケーションタイプＴＬＶ」の新規定義例を示す。この図５に示すように、「アプリケーションＴＬＶ」には、「ＴＬＶ種別」フィールド３１，「長さ（Ｌｅｎｇｔｈ）」フィールド３２及び「アプリケーションタイプ」フィールド３３を用意し、「ＴＬＶ種別」フィールド３１には当該ＴＬＶの種別（この場合は「アプリケーション」）を示す情報、「長さ（Ｌｅｎｇｔｈ）」フィールド３２には当該ＴＬＶの長さを示す情報、「アプリケーションタイプ」フィールド３３には、設定するセッションのタイプを示す情報をそれぞれ設定する。
例えば、“０”で“ｕｎｋｎｏｗｎ”、“１”でトラフィックエンジニアリングセッション、“２”で「Ｍａｒｔｉｎｉ Ｌ２ ＶＰＮ」セッションをそれぞれ表すものとする（他はリザーブとする）。なお、本「Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ」も図５に示すようにサポートするタイプを複数設定することが可能である。
＜５＞「セッション名（Ｓｅｓｓｉｏｎ Ｎａｍｅ）ＴＬＶ」の新規定義例
図６は「セッション名ＴＬＶ」の新規定義例を示す図で、この図６に示すように、「セッション名ＴＬＶ」には、ＴＬＶ種別フィールド４１，「長さ（Ｌｅｎｇｔｈ）」フィールド４２及び「Ｓｅｓｓｉｏｎ Ｎａｍｅ」フィールド４３を用意し、「Ｓｅｓｓｉｏｎ Ｎａｍｅ ＴＬＶ」フィールド４１には当該ＴＬＶのタイプ（この場合は「Ｓｅｓｓｉｏｎ Ｎａｍｅ」）を示す「ＴＬＶ種別」）を示す情報、「長さ（Ｌｅｎｇｔｈ）」フィールド４２には設定するセッションを示す情報（キャラクタ列）を設定する。
＜６＞「ハローメッセージ」の拡張例
次に、図７及び図８に「ハローメッセージ（Ｈｅｌｌｏ Ｍｅｓｓａｇｅ）」の拡張例を示す。これらの図７及び図８に示すように、「ハローメッセージ」には、メッセージ種別〔この場合はＨｅｌｌｏ（０ｘ０１００）〕を示すメッセージ種別フィールド５１，当該メッセージの長さ（Ｍｅｓｓａｇｅ Ｌｅｎｇｔｈ）を示すメッセージ長フィールド５２，メッセージＩＤフィールド５３，共通ハローパラメータ（Ｃｏｍｍｏｎ Ｈｅｌｌｏ Ｐａｒａｍｅｔｅｒｓ）ＴＬＶフィールド５４及びオプショナルパラメータフィールド５５が用意されており、さらに、共通ハローパラメータＴＬＶフィールド５４には、パラメータ種別（共通ハローパラメータ）を示すフィールド５４１，当該共通ハローパラメータＴＬＶフィールド５４の長さ（フィールド長）を設定する長さフィールド５４２及び保持時間（Ｈｏｌｄ Ｔｉｍｅ）フィールド５４３等が用意されている。
そして、本実施形態では、上記のオプショナルパラメータフィールド５５に設定する情報（オプショナルパラメータ）を拡張し、既存のパラメータ（「ＩＰｖ４ Ｔｒａｎｓｐｏｒｔ Ａｄｄｒｅｓｓ（０ｘ０４０１）」，「Ｃｏｎｆｉｇｕｒａｔｉｏｎ（０ｘ０４０２）」，「ＩＰｖ６ Ｔｒａｎｓｐｏｒｔ Ａｄｄｒｅｓｓ（０ｘ０４０３）」）に加えて、「Ｓｅｓｓｉｏｎ ＴＹＰＥ」（Ｓｅｓｓｉｏｎ ＴＹＰＥ ＴＬＶ），「Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ」（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ ＴＬＶ），「Ｓｅｓｓｉｏｎ Ｎａｍｅ」（Ｓｅｓｓｉｏｎ Ｎａｍｅ ＴＬＶ）の各情報を設定可能としている。
このような拡張オプショナルパラメータをもつハローパケットを隣接ＬＳＲ１１間で交換することによって、確立するＬＤＰセッションのアプリケーション及び／又は用途をハロー隣接確立時に明示的に指定することが可能となる。
＜７＞「イニシャライゼーション（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｍｅｓｓａｇｅ）」の拡張例１
次に、図９に「イニシャライゼーションメッセージ」の拡張例１を示す。この図９に示すように、「イニシャライゼーション」には、メッセージ種別〔この場合は“Ｉｎｉｔｉａｌｉｚａｔｉｏｎ（０ｘ０２００）”〕を示すメッセージ種別フィールド６１，当該メッセージの長さ（Ｍｅｓｓａｇｅ Ｌｅｎｇｔｈ）を示すメッセージ長フィールド６２，メッセージＩＤフィールド６３，共通セッションパラメータ（Ｃｏｍｍｏｎ Ｓｅｓｓｉｏｎ Ｐａｒａｍｅｔｅｒｓ）ＴＬＶフィールド６４及びオプショナルパラメータフィールド６５が用意されている。
また、図１０に示すように、上記共通セッションパラメータＴＬＶフィールド６４には、さらに、パラメータ種別（共通セッションパラメータ）を示すフィールド６４１，当該共通セッションパラメータＴＬＶフィールド６４の長さ（フィールド長）を設定する長さフィールド６４２，プロトコルバージョンフィールド６４３，キープアライブタイム（Ｋｅｅｐ Ａｌｉｖｅ Ｔｉｍｅ）フィールド６４４及び受信側ＬＤＰ識別子（Ｒｅｃｅｉｖｅｒ ＬＤＰ Ｉｄｅｎｔｉｆｉｅｒ）フィールド６４５が用意されている。
そして、本実施形態では、この図１０に示すように、当該共通セッションパラメータＴＬＶフィールド６４に、「セッションタイプ（Ｓｅｓｓｉｏｎ ＴＹＰＥ）」フィールド６４６，「アプリケーションタイプ（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ）」フィールド６４７及び「セッション名（Ｓｅｓｓｉｏｎ Ｎａｍｅ）」フィールド６４８を追加定義し、「セッションタイプ」，「アプリケーションタイプ」，「セッション名」の各情報を設定可能としている。
このような拡張コモンセッションパラメータをもつイニシャライゼーションメッセージを隣接ＬＳＲ１１間で交換することによって、確立するＬＤＰセッションのアプリケーション及び／又は用途をＬＤＰセッション確立時に明示的に指定することが可能となる。
＜８＞「イニシャライゼーションメッセージ」の拡張例２
なお、確立するＬＤＰセッションのアプリケーション及び又は用途を明示的に指定するのにイニシャライゼーションメッセージを用いる場合、そのオプショナルパラメータを拡張してもよい。即ち、オプショナルパラメータとして、既存のパラメータ（「ＡＴＭ Ｓｅｓｓｉｏｎ Ｐａｒａｍｅｔｅｒｓ（０ｘ０５０１）」，「Ｆｒａｍｅ Ｒｅｌａｙ Ｓｅｓｓｉｏｎ（０ｘ０５０２）」等）に加えて、前記の「Ｓｅｓｓｉｏｎ ＴＹＰＥ」（Ｓｅｓｓｉｏｎ ＴＹＰＥ ＴＬＶ），「Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ」（Ａｐｐｌｉｃａｔｉｏｎ ＴＹＰＥ ＴＬＶ），「Ｓｅｓｓｉｏｎ Ｎａｍｅ」（Ｓｅｓｓｉｏｎ Ｎａｍｅ ＴＬＶ）の各情報を設定可能とする。
このようにしても、確立するＬＤＰセッションのアプリケーション及び／又は用途をＬＤＰセッション確立時に明示的に指定することが可能となる。
以上のようにして、同一隣接ＬＳＲ１１間で、同じラベル空間を使用したＬＤＰセッションを複数設定することを可能となるとともに、そのＬＤＰセッションの用途及び／又はアプリケーションを明示的に指定（識別）することが可能となる。
▲３▼次に、本実施形態では、プロビジョニング情報（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）をＬＤＰメッセージで送受信することにより、リモート側の情報を自動的に入手〔又は削除（撤回）〕するとともに、誤配線及び／又はプロビジョニング情報の設定ミスを検出できるようにもなっている。ここで、当該プロビジョニング情報は、既存メッセージ（例えば、イニシャライゼーションメッセージ）に新規ＴＬＶとして追加しても良いし、メッセージ自体を新しく定義しても良い。ただし、追加／変更の可能性が高い情報については、新規メッセージ又はアドレスメッセージを用いるのが望ましい。これにより、プロビジョニングの誤りによるＭＰＬＳ及びアプリケーションの誤動作を事前にチェックでき、防止することができる。
その具体例を以下の＜９＞，＜１０＞，＜１１＞，＜１２＞に示す。なお、かかる機能も、ラベル配付用シグナリング処理部１１８の機能拡張によって実現されている。
＜９＞「プロビジョニング情報（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）ＴＬＶ」の新規定義例
図１１に、「プロビジョニング情報ＴＬＶ」の新規定義例を示す。この図１１に示すように、「プロビジョニング情報ＴＬＶ」には、ＴＬＶ種別（この場合は「プロビジョニング情報」）を示すＴＬＶ種別フィールド７１，本「プロビジョニング情報ＴＬＶ」の長さを示すＴＬＶ長（Ｌｅｎｇｔｈ）フィールド７２，プロビジョニングパラメータ（Ｐｒｏｖｉｓｉｏｎｉｎｇ Ｐａｒａｍｅｔｅｒ）フィールド７３が用意され、プロビジョニングパラメータとして、図１２に示すようなフォーマットを有する「ＰＷパラメータ（Ｐｓｅｕｄｏ Ｗｉｒｅ Ｐａｒａｍｅｔｅｒ）ＴＬＶ」を複数設定できるようになっている。
なお、この図１２に示すように、「ＰＷパラメータＴＬＶ」には、さらに、ＴＬＶ種別（この場合は「ＰＷパラメータ」）を示すＴＬＶ種別フィールド７３１，当該ＴＬＶ長を示すＴＬＶ長フィールド７３２及び「ＰＷ ＦＥＣ ＴＬＶ」フィールド７３３を用意し、複数の「ＰＷ ＦＥＣ ＴＬＶ」（前述した「Ｍａｒｔｉｎｉ」ドラフトで定義されている）の設定が可能になっている。
このような「プロビジョニング情報ＴＬＶ」を隣接ＬＳＲ１１間で交換することにより、ＰＷ単位で、相手（リモート）側のプロビジョニング情報を自動的に入手〔又は削除（撤回）〕するとともに、誤配線及び／又はプロビジョニング情報の設定ミスを検出することが可能となる。つまり、本実施形態のラベル配付用シグナリング処理部１１８は、ＬＤＰのエンティティに関するプロビジョニング情報をＬＤＰメッセージに付加して隣接ＬＳＲとの間で交換するプロビジョニング情報交換処理部としての機能も果たしていることになる。
＜１０＞「イニシャライゼーションメッセージ」の拡張例
なお、プロビジョニング情報の交換にイニシャライゼーションメッセージを用いる場合には、例えば、そのオプショナルパラメータ（図９参照）を拡張して、既存のパラメータ（「ＡＴＭ Ｓｅｓｓｉｏｎ Ｐａｒａｍｅｔｅｒｓ（０ｘ０５０１）」，「Ｆｒａｍｅ Ｒｅｌａｙ Ｓｅｓｓｉｏｎ（０ｘ０５０２）」等）及び前記の「セッションタイプ」（セッションタイプＴＬＶ），「アプリケーションタイプ」（アプリケーションタイプＴＬＶ），「セッション名」（セッション名ＴＬＶ）に加えて、さらに「プロビジョニング情報」（「プロビジョニング情報ＴＬＶ」の各情報を設定可能とする。
このような拡張オプショナルパラメータをもつイニシャライゼーションメッセージを隣接ＬＳＲ１１間で交換することによって、ＬＤＰセッション確立の際に事前に、相手（リモート）側のプロビジョニング情報を自動的に入手〔又は削除（撤回）〕するとともに、誤配線及び／又はプロビジョニング情報の設定ミスを検出することが可能となる。
＜１１＞「プロビジョニングメッセージ」の新規追加例
次に、プロビジョニング情報を交換するための専用のメッセージ（プロビジョニングメッセージ）を新規に追加定義する（ラベル配付用シグナリング処理部１１８で生成する）場合は、例えば図１３に示すようなフォーマットとする。即ち、このプロビジョニングメッセージには、メッセージ種別（この場合は「プロビジョニング」）を示すメッセージ種別フィールド８１，当該メッセージの長さを示すメッセージ長フィールド８２，メッセージＩＤフィールド８３及びプロビジョニング情報ＴＬＶフィールド８４を用意し、当該フィールド８４に自ＬＳＲ１１のプロビジョニング情報（プロビジョニング情報ＴＬＶ）を設定することにより、隣接ＬＳＲ１１間でのプロビジョニング情報を交換することが可能となる。
＜１２＞「アドレスメッセージ（Ａｄｄｒｅｓｓ Ｍｅｓｓａｇｅ）」の拡張例
次に、ＬＤＰのアドレスメッセージ（ＬＤＰ確立後に交換されるメッセージ）を用いてプロビジョニング情報の交換を行なう場合は、例えば図１４に示すように、メッセージ種別（この場合は「アドレス（Ａｄｄｒｅｓｓ）」を表示）を示すメッセージ種別フィールド９１，当該メッセージの長さを示すメッセージ長フィールド９２，メッセージＩＤフィールド９３，アドレスリスト（Ａｄｄｒｅｓｓ Ｌｉｓｔ）ＴＬＶフィールド９４，オプショナルパラメータフィールド９５を有するアドレスメッセージの当該オプショナルパラメータフィールド９５に設定すべきパラメータを拡張し、プロビジョニング情報として「プロビジョニング情報ＴＬＶ」を設定可能とする。
これにより、ＬＤＰセッション確立後においても、適宜に、相手（リモート）側のプロビジョニング情報を自動的に入手〔又は削除（撤回）〕するとともに、誤配線及び／又はプロビジョニング情報の設定ミスを検出することが可能となる。なお、上記プロビジョニング情報の交換はイニシャライゼーションメッセージ及びアドレスメッセージのいずれか一方を用いて行なっても良いし、双方を用いて行なっても良い。
▲４▼次に、上記の項目▲１▼及び▲２▼により前述したように追加定義したＴＬＶを使用して、隣接ＬＳＲ１１の該当するアプリケーション及び／又は用途に対するＬＤＰセッションを明示的に正しく設定するとともに、リモート側のプロビジョニング情報を自動入手〔又は削除（撤回）〕することにより、当該情報のプロビジョニングを不要とする手法について、図１５に示すシーケンス図を参照しながら説明する。なお、ここでは、「Ｍａｒｔｉｎｉ」ドラフトに対する拡張を例にして、ハロー隣接の自動検出の方法を説明する。
図１５に示すように、まず、ＭＰＬＳ網１に接続する「Ｍａｒｔｉｎｉ」ドラフトによるＭＰＬＳ Ｌ２ ＶＰＮを実装した隣接ＰＥ１１間〔ＬＳＲ＃１（能動）、ＬＳＲ＃２（受動）とする〕で、互いのラベル配付用シグナリング処理部１１８の機能により、ハローメッセージを交換する（ステップＳ１）。その際、項目＜１＞，＜２＞により前述したように当該ハローメッセージのＬＤＰ識別子又はＬＤＰ ＰＤＵを拡張してセッションＩＤを付与しておくことで、ＬＳＲ＃１−ＬＳＲ＃２間で複数のＬＤＰセッションを明示的に指定・識別することが可能となる。なお、当該セッションＩＤは、隣接ＬＳＲ＃１，ＬＳＲ＃２において、図１５中に示す全てのメッセージに付与しておくことで、同一ラベル空間を使用する複数のＬＤＰセッションの確立が可能となる。
また、項目＜３＞，＜４＞，＜５＞，＜６＞により前述したように、上記ハローメッセージに、「セッションタイプＴＬＶ」及び／又は「アプリケーションタイプＴＬＶ」及び／又は「セッション名ＴＬＶ」を付与しておくことにより、確立するＬＤＰセッションを使用するアプリケーション及び／又はその用途を明示的に指定・識別することが可能となり、アプリケーション及び／又はその用途を明示したハロー隣接を正しく確立することが可能となる（ステップＳ２）。
さらには、上記ハローメッセージ交換前に、ラベル配付用シグナリング処理部１１８の機能（予め隣接ＬＳＲとの間にトンネルＬＳＰを設定するトンネルＬＳＰ設定部としての機能）により、隣接ＬＳＲ（ＰＥ）１１間でフルメッシュのＬＳＰ（トンネルＬＳＰ）を通常のＬＳＰで設定して隣接ＬＳＲ１１間を論理的に直接接続し（これにより、トンネルＬＳＰを使用して基本ディスカバリメカニズムを使用することが可能となる）、上記ハローメッセージに、項目＜３＞，＜４＞，＜５＞により前述した「セッションタイプＴＬＶ」及び／又は「アプリケーションタイプＴＬＶ」及び／又は「セッション名ＴＬＶ」を付与し、宛先アドレスをマルチキャスト（２２４．０．０．２）としたハローメッセージを互いに送信（基本ディスカバリ）することにより、リモート側の「Ｍａｒｔｉｎｉ」方式を処理するＬＤＰエンティティのアドレスを自動検出することが可能となる。
さて、上述のごとくハロー隣接が確立すると、隣接ＬＳＲ＃１−ＬＳＲ＃２間では、次に、ＴＣＰメッセージの交換（ステップＳ３〜Ｓ５）により、トランスポートコネクションを確立し（ステップＳ６）、互いのラベル配付用シグナリング処理部１１８の機能により、イニシャライゼーションメッセージの交換を行なう（ステップＳ７，Ｓ８）。その際、当該イニシャライゼーションメッセージを、項目＜３＞，＜４＞，＜５＞，＜７＞，＜８＞により前述したように拡張しておくことで、当該フェーズにおいても、当該ＬＤＰセッションを使用するアプリケーション及び／又はその用途を明示的に指定・識別することが可能となる。
また、上記イニシャライゼーションメッセージに、項目＜９＞，＜１０＞により前述したように、「プロビジョニングＴＬＶ」を追加してプロビジョニング情報を交換することにより、ＭＰＬＳ処理部１１５において、リモート側のプロビジョニング情報を入手〔又は削除（撤回）〕するとともに、プロビジョニング情報のアンマッチをチェックアウトして保守者等に通知することが可能となる。また、リモート側のアドレス設定も不要となる。なお、ＭＰＬＳ処理部１１５において、プロビジョニング情報のアンマッチが検出された場合、その後の処理は続行しても良いし、中止しても良い。また、交換する情報によっては、アドレスメッセージに新ＴＬＶを追加することで対応しても良い。
さらに、項目＜１１＞にて前述したようにプロビジョニングメッセージを新たに追加定義して「プロビジョニング情報ＴＬＶ」を追加した当該プロビジョニングメッセージをＬＤＰセッション確立後に隣接ＬＳＲ＃１−ＬＳＲ＃２間で交換することにより、ＬＤＰセッション確立後にも、リモート側のプロビジョニング情報を入手〔又は削除（撤回）〕するとともに、プロビジョニング情報のアンマッチをチェックアウトして保守者等に通知することが可能となる。なお、この場合も、その後の処理は続行しても良いし、中止しても良い。
さて、上記イニシャライゼーションメッセージの交換により、隣接ＬＳＲ＃１−ＬＳＲ２が、それぞれ、当該イニシャライゼーションメッセージのセッションパラメータを許容すると、以後、キープアライブメッセージを定期的に発行して自己が正常に動作していることをリモート側に通知する（ステップＳ１１，Ｓ１２）。以上により、隣接ＬＳＲ＃１−ＬＳＲ＃２間で、同一ラベル空間を使用した複数のＬＤＰセッションが、当該セッションを使用するアプリケーション及び／又はその用途で正しく確立される。
その後、隣接ＬＳＲ＃１−ＬＳＲ＃２は、ＭＰＬＳパケット（ラベル付きパケット）のフォワーディンングデシジョンに使用するＬＤＰピアのアドレスをアドレスメッセージによって交換する（ステップＳ１４）が、その際、項目＜１２＞にて前述したようにアドレスメッセージを拡張して新ＴＬＶを追加することで、イニシャライゼーションメッセージを利用した場合と同様に、リモート側のプロビジョニング情報を入手〔又は削除（撤回）〕するとともに、プロビジョニング情報のアンマッチをチェックアウトして保守者等に通知することが可能となる。なお、この場合も、アンマッチが検出された後の処理は続行しても良いし、中止しても良い。また、当該セッション中で変更されない情報については、イニシャライゼーションメッセージに「プロビジョニング情報ＴＬＶ」を追加して対応しても良い。
そして、隣接ＬＳＲ＃１−ＬＳＲ＃２は、互いに受信したアドレスメッセージの情報内容に基づいてラベルマッピングメッセージを送受してラベル配付（ラベルマッピング）を行なう（ステップＳ１５，Ｓ１６）。これにより、以降、各ＬＳＲ＃１，ＬＳＲ＃２において、配付されたラベルを付加されたＭＰＬＳパケットのフォワーディングが可能となる。
以上のように、本実施形態によれば、同一隣接ＬＳＲ間で、同じラベル空間を使用したＬＤＰセッションを複数設定することが可能となり、また、その用途（アプリケーション）を明示的に示すことが可能となるので、ＬＤＰセッションを誤りなく接続して、誤プロビジョニング及びそれによるセッションの誤接続をセッション確立時に早期に検出することができる。
また、プロビジョニングの誤りによるＭＰＬＳ及びアプリケーションの誤動作を防止し、さらに、リモート側ＬＳＲに関するプロビジョニング情報を自動検出し、リモート側情報のプロビジョニングを無くし（あるいは減らし）て、プロビジョニングミスによる誤接続または誤動作を削減することもできる。
したがって、ＭＰＬＳ及び／又はＧＭＰＬＳ及び／又は前者を拡張したプロトコルを実装した装置（パケット中継装置／ＴＤＭ中継装置／光波長中継装置等）で構成したネットワークにおいて、ＭＰＬＳ及び／又はＧＭＰＬＳ及び／又は前者を拡張したプロトコルを使用したアプリケーションを実現する場合のネットワーク設計の容易化，柔軟性向上及び保守／運用／管理効率などの向上が期待できる。
また、ブリッジをベースとした装置にＭＰＬＳ（例えば、「Ｍａｒｔｉｎｉ」方式）を実装する場合など、実装コストやハードウェアの制約等の面から、機能的に制限をもつ装置同士または機能的に制限をもつ装置と汎用的に機能を装備した装置との間の相互接続性の向上に効果が大きい。

以上のように、本発明によれば、ラベルスイッチネットワークの設計の容易化，柔軟性向上及び保守／運用／管理効率などの向上が期待できるとともに、機能的に制限をもつ装置同士または機能的に制限をもつ装置と汎用的に機能を装備した装置との間の相互接続性の向上が期待できるので、ネットワーク通信分野において極めて有用であると考えられる。

Claims (16)

1. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、
   該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報を付加して該メッセージの送受を行ない、
   同一隣接ラベルスイッチノードが、それぞれ、該セッション識別情報に基づいて、該同一隣接ラベルスイッチノード間に同一ラベル空間で使用する複数セッションを確立することを特徴とする、ラベルスイッチネットワークにおけるセッション確立方法。
2. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、
   該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、該隣接ラベルスイッチノード間で確立すべきセッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報を付加して該メッセージの送受を行ない、
   該隣接ラベルスイッチノードが、それぞれ、該セッションタイプ情報に基づいて、該隣接ラベルスイッチノード間に該セッションタイプ情報に応じた該セッションを確立することを特徴とする、ラベルスイッチネットワークにおけるセッション確立方法。
3. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有する複数のラベルスイッチノードをそなえて成るラベルスイッチネットワークにおいて、
   該ラベル配付プロトコルにより隣接ラベルスイッチノード間で送受されるメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報と、当該セッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して該メッセージの送受を行ない、
   該同一隣接ラベルスイッチノードが、それぞれ、該セッション識別情報及び該セッションタイプ情報に基づいて、該同一隣接ラベルスイッチノード間に同一ラベル空間で使用する、該セッションタイプ情報に応じた複数のセッションを確立することを特徴とする、ラベルスイッチネットワークにおけるセッション確立方法。
4. 該メッセージとしてのハローメッセージに該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノード間のハロー隣接確立時に該セッションタイプ情報を該隣接ラベルスイッチノード間で交換することを特徴とする、請求の範囲第２項又は第３項に記載のラベルスイッチネットワークにおけるセッション確立方法。
5. 該メッセージとしてのイニシャライゼーションメッセージに、該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノード間のセッション確立時に該セッションタイプ情報を該隣接ラベルスイッチノード間で交換することを特徴とする、請求の範囲第２項又は第３項に記載のラベルスイッチネットワークにおけるセッション確立方法。
6. 隣接ラベルスイッチノード間で該セッションを確立する際に、該ラベル配付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに付加して交換することを特徴とする、請求の範囲第１項〜第３項のいずれか１項に記載のラベルスイッチネットワークにおけるセッション確立方法。
7. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するラベルスイッチノードであって、
   該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、同一隣接ラベルスイッチノード間に確立すべきセッションを識別するセッション識別情報を付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、
   該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッション識別情報に基づいて、該隣接ラベルスイッチノードとの間に同一ラベル空間で使用する複数セッションの確立を制御するセッション確立制御部とをそなえたことを特徴とする、ラベルスイッチノード。
8. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するラベルスイッチノードであって、
   該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、該隣接ラベルスイッチノードとの間で確立すべきセッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報を付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、
   該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッションタイプ情報に基づいて、該隣接ラベルスイッチノードとの間に該セッションタイプ情報に応じた該セッションの確立を制御するセッション確立制御部とをそなえたことを特徴とする、ラベルスイッチノード。
9. 所定のラベル配付プロトコルにより配付されたラベル情報に従って受信パケットをルーティングする機能を有するラベルスイッチノードであって、
   該ラベル配付プロトコルにより隣接ラベルスイッチノードとの間で送受すべきメッセージに、該隣接ラベルスイッチノードとの間に確立すべきセッションを識別するセッション識別情報と、当該セッションを使用するアプリケーション及びその用途のいずれか一方又は双方を明示するセッションタイプ情報とを付加して該メッセージの送受を行なうラベル配付プロトコル処理部と、
   該ラベル配付プロトコル処理部で該隣接ラベルスイッチノードから受信した該ラベル配付プロトコルのメッセージに付加されたセッション識別情報及びセッションタイプ情報に基づいて、該隣接ラベルスイッチノードとの間に同一ラベル空間で使用する、該セッションタイプ情報に応じた複数セッションの確立を制御するセッション確立制御部とをそなえたことを特徴とする、ラベルスイッチノード。
10. 該ラベル配付プロトコル処理部が、
    該ラベル配付プロトコルの該メッセージとしてのハローメッセージに該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノードとの間のハロー隣接確立時に該セッションタイプ情報を該隣接ラベルスイッチノードとの間で交換するハローメッセージ処理部をそなえて構成されたことを特徴とする、請求の範囲第８項又は第９項に記載のラベルスイッチノード。
11. 該ラベル配付プロトコル処理部が、
    該ラベル配付プロトコルの該メッセージとしてのイニシャライゼーションメッセージに、該セッションタイプ情報を付加することにより、該隣接ラベルスイッチノードとの間のセッション確立時に該セッションタイプ情報を該隣接ラベルスイッチノードとの間で交換するイニシャライゼーションメッセージ処理部をそなえて構成されたことを特徴とする、請求の範囲第８項又は第９項に記載のラベルスイッチノード。
12. 該ラベル配付プロトコル処理部が、
    該ラベル配付プロトコルのエンティティに関するプロビジョニング情報を該メッセージに付加して交換するプロビジョニング情報交換処理部をそなえて構成されたことを特徴とする、請求の範囲第７項〜第９項のいずれか１項に記載のラベルスイッチノード。
13. 該ラベル配付プロトコル処理部が、
    該隣接ラベルスイッチノードとの間で該セッション確立制御部により該セッションを確立する際に、予め当該隣接ラベルスイッチノードとの間にトンネルラベルスイッチパスを設定するトンネルラベルスイッチパス設定部をそなえ、
    該プロビジョニング情報交換処理部が、
    該トンネルラベルスイッチパス設定部により設定された該トンネルラベルスイッチパスを通じて該プロビジョニング情報の付加された該メッセージを交換するように構成されたことを特徴とする、請求の範囲第１２項に記載のラベルスイッチノード。
14. 該プロビジョニング情報交換処理部が、
    該隣接ラベルスイッチノード間で該ラベル配付プロトコルに従って送受するイニシャライゼーションメッセージ及びアドレスメッセージのいずれか一方又は双方に、該プロビジョニング情報を転送するＴＬＶ（Ｔｙｐｅ／Ｌｅｎｇｔｈ／Ｖａｌｕｅ）を追加するように構成されたことを特徴とする、請求の範囲第１２項又は第１３項に記載のラベルスイッチノード。
15. 該プロビジョニング情報交換処理部が、
    該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の転送用のメッセージを交換するように構成されたことを特徴とする、請求の範囲第１２項又は第１３項に記載のラベルスイッチノード。
16. 該プロビジョニング情報交換処理部が、
    該ラベル配付プロトコルにおいて新規に定義した該プロビジョニング情報の撤回用のメッセージを交換するように構成されたことを特徴とする、請求の範囲第１２項又は第１３項に記載のラベルスイッチノード。

Images