JP2010531596A

JP2010531596A - ラベルスイッチネットワークにおけるパス計算

Info

Publication number: JP2010531596A
Application number: JP2010513860A
Authority: JP
Inventors: ドウビル，リシヤール; ル・ソーズ，ニコラ
Original assignee: アルカテル−ルーセント
Priority date: 2007-06-29
Filing date: 2008-06-19
Publication date: 2010-09-24
Also published as: KR101050681B1; WO2009013085A1; ATE448619T1; EP2009848B1; DE602007003208D1; EP2009848A1; KR20100024442A

Abstract

ラベルスイッチネットワークにおけるパス計算のための方法が提案される。ステートフルなパス計算要素は、ラベルスイッチネットワークについてのトポロジーおよびリソース情報をトラフィックエンジニアリングデータベースの中に記憶する。パス計算要素はパス計算クライアントからパス計算要求を受信し、トポロジーおよびリソース情報を使用してこの要求を満たすパスを計算する。次いで、パス計算要素は計算されたパスを含めて、パス計算クライアントにパス計算応答を送信する。次いで、パス計算クライアントはラベルスイッチパスを設定するために提案されたパスを使用したか、しないかを示す肯定応答をパス計算要素に返送する。その後、このリンク状態情報は、今後のパス計算のためにパス計算要素によって使用されることが可能である。

Description

本発明は遠距離通信の分野に関し、より詳細にはラベルスイッチネットワークの中でパスを計算するための方法および装置に関する。

ＩＥＴＦ文書ＲＦＣ４６５５では、大型のマルチドメイン、マルチリージョンまたはマルチレイヤネットワークでのパス計算の問題空間について取り組む、パス計算要素（ＰＣＥ）に基づくモデルのためのアーキテクチャが説明されている。このアーキテクチャは、ステートフルＰＣＥとステートレスＰＣＥを区別する。ＲＦＣ４６５５によれば、前者の場合、ＰＣＥ間には厳格な同期化が存在し、このことは、トポロジーおよびリソース情報に関するネットワーク状態だけでなく、ネットワークの中での計算されたパスと使用中の予約リソースとの組み合わせについても言える。

したがって、効率的なステートフルＰＣＥを持つために、ＰＣＥは計算されたパス、および結果的にはその関連した予約リソースが使用されたか、されないのかを知るべきである。特に、複数のＰＣＥがネットワークの中のパス計算のために使用される場合、各ＰＣＥに記憶された状態間での厳重な同期化が必要とされる。このことは制御プレーンのトラフィックを増加させ、複雑なメカニズムおよび計算リソースを必要とする。

ステートフルＰＣＥのための本解決法は、ネットワークリソースおよびそれらの有効性を集めるためのルーティングプロトコルＯＳＰＦ−ＴＥに基づくものである。しかしながら、提案されるパスの解決策の採用または不採用についての情報とネットワークリソースの有効性の変更を結び付けることは難しいであろう。

ＩＴＦ文書、ＲＦＣ４６５５ＩＴＦ文書、ＰａｔｈＣｏｍｐｕｔａｔｉｏｎＥｌｅｍｅｎｔ（ＰＣＥ）ＣｏｍｍｕｎｉｃａｔｉｏｎＰｒｏｔｏｃｏｌ（ＰＣＥＰ）、ｄｒａｆｔ−ｉｅｔｆ−ｐｃｅ−ｐｃｅｐ−０８．ｔｘｔ

したがって本発明の目的は、知られている解決法よりも効率的でありながら実行が難しくない、ラベルスイッチネットワークの中でパスを計算するための方法および関連した装置を提供することである。

これらの目的およびその他の目的は、請求項１に記載のラベルスイッチネットワークの中でパスを計算する方法、請求項７に記載のパス計算要素、および請求項８に記載のパス計算クライアントによって達成される。

特に本発明によって、ステートフルなパス計算要素は、ラベルスイッチネットワークについてのトポロジーおよびリソース情報をトラフィックエンジニアリングデータベースの中に記憶する。パス計算要素はパス計算クライアントからパス計算要求を受信し、このパス計算要求を満たすパスをトポロジーおよびリソース情報を使用して計算する。次いでパス計算要素は、計算されたパスを含めて、パス計算クライアントにパス計算応答を送信する。次いでパス計算クライアントは、ラベルスイッチパスを設定するために提案されたパスを使用したかどうかを示す肯定応答を、パス計算要素に返送する。その後このリンク状態情報は、今後のパス計算のためにパス計算要素によって使用されることが可能である。

本発明の好ましい実施形態は、ここで添付の図面を参照して説明される。

本発明が適用されるデータネットワークの概略図である。ラベルスイッチパスの設定後の請求項１のデータネットワークを示す図である。本発明による、図１のデータネットワークの中に含まれるパス計算要素（ＰＣＥ）の詳細な概略図である。本発明によるネットワーク要素の概略的なブロック図である。

図１は、遠距離ネットワークＮＥＴの概略図を示す。図１は第１ネットワークノードＮ１、第２ネットワークノードＮ２および複数の中間ネットワークノードｎ１−ｎ９を含む。

本発明の状況では、遠距離ネットワークＮＥＴはマルチプロトコルラベルスイッチング（ＭＰＬＳ）または汎用マルチプロトコルラベルスイッチング（ＧＭＰＬＳ）の原理によって操作されるラベルスイッチパケットデータネットワークと同一であるとみなされることが可能である。ネットワークパスは、当業者に知られているように、適切な信号プロトコルによってラベルスイッチパス（ＬＳＰ）として確立される。本発明の状況の中で適切な一般に知られているプロトコルは、ＯＳＰＦ（オープンショーテストパスファースト）である。ＯＳＰＦは、ルート選択のためにリンク状態データベース（ＬＳＤＢ）またはトラフィックエンジニアリングデータベース（ＴＥＤ）を使用し、この場合そのようなデータベースは、ネットワークトポロジーを反映した情報を含む。

参照により本明細書に組み込まれているＲＦＣ４６５５に従って、パス計算はパス計算要素（ＰＣＥ）によって実行されるが、このＰＣＥはＲＦＣ４６５５のセクション３で詳細に説明されているように、ネットワークトポロジーおよびリソース情報に基づいてネットワークパスまたはルートを計算し、計算制約を適用することができるコンポーネント、アプリケーションまたはネットワークノードなどのエンティティである。

ネットワークノードＮ１は、パス計算クライアント（ＰＣＣ）機能ＰＣＣ１を有し、ＰＣＣ１はパス計算要素ＰＣＥ１に接続されている。ＰＣＥ１はステートフルＰＣＥであり、これは確立されたＬＳＰおよび以前に計算されたパスをメモリ中に保持するということを意味する。ＰＣＥ１は、パス計算のためにＴＥＤを含む。

トポロジーの変更が遠距離ネットワークＮＥＴの要素間でのルート選択情報の交換を必要とする場合、前述のデータベースが構築され、更新される。より一般的には内部ゲートウェイプロトコル（ＩＧＰ）（ＩｎｔｅｒｉｏｒＧａｔｅｗａｙＰｒｏｔｏｃｏｌ）と呼ぶことができるＯＳＰＦプロトコルによって、ルート選択情報は、使用されるＩＧＰ（ＯＳＰＦ、ＩＳ−ＩＳ、ＲＩＰまたはＩＧＲＰなど）により圧縮できない時間間隔に基づいて定期的に生じるフラッディングを通じて提供される。

図１の中で、ＰＣＥ１はネットワークトポロジーおよびリソース使用情報を、その他のネットワークデバイス（図示せず）からプロトコルＩＧＰを介して受信する。トラフィックエンジニアリングデータベース（ＴＥＤ）はＰＣＥ１に実装されており、ＩＧＰを介して受信される情報は、添付の図３を参照して以下で詳細に説明されるように、このデータベースをポピュレートするために使用される。パスの設定およびリソースの予約のために、図１のネットワークノードＮ１、Ｎ２およびｎ１−ｎ９は、添付の図４を参照して以下で詳細に説明されるように、各々の信号エンジン（図１には図示せず）を備える。

ネットワークノードＮ１は各自のパス計算クライアント機能ＰＣＣ１を備えており、これはパス計算要素ＰＣＥ１にアドレス指定することができる。図１の中で破線の矢印で示されているように、Ｎ１がネットワークノードＮ２へのパスを確立しようとする場合、Ｎ１はそのＰＣＣ１機能から、例えばこの実施形態ではＰＣＥ１であるＰＣＥへ、対応するパス計算要求ＲＥＱを送信する。一般的な場合では、複数のＰＣＥが存在することが可能であり、ＰＣＣ１は要求とともに異なるＰＣＥにアドレス指定することができることに留意されたい。特定の計算要求のためにアドレス指定されるＰＣＥの選択肢は多様であってもよく、例えば構成、ＰＣＥのロード状態、ＰＣＥのネットワーク認識、セキュリティの選択肢、ＰＣＥで利用可能なルート選択最適化アルゴリズムなどによって決まってもよい。

ＰＣＥ１は、そのＴＥＤの中のトポロジーおよびリソース情報を使用してパスＰを計算し、パス計算応答ＰＣＲの中の計算されたパスをＰＣＣ１に返送する。

ＰＣＥ１が計算されたパスＰを返送した後、このパスのために使用されたリソースは、別のパス計算要求のために再び割り当てられるべきではない。一方、利用可能なリソースの変更がＩＧＰを通じて伝達されるまで、しばらく時間がかかる。

図２には、Ｎ１からルート選択ノードｎ１−ｎ８−ｎ５−ｎ６を通って行き先ノードＮ２に続く破線に沿って、計算されたパスＰが例として示されている。パスの設定は、ＲＳＶＰ（リソース予約プロトコル）を使用して、従来の方法でネットワークノードＮ１によって開始される。しかしながら、Ｎ１は計算結果を使用して計算されたパスを確立することを強制されるわけではなく、さもなければこの確立は失敗する可能性がある。したがって本発明の基本的な概念によって、ＰＣＥとＰＣＣとの間の直接通信が導入される。本発明によって、ＰＣＣ１は計算されたパスに使用されたか、されないのかを示す肯定応答ＡＣＫをＰＣＥ１に返送する。

好ましい実施形態では、肯定応答は既存のプロトコルＰＣＥＰ、すなわちＰＣＣとＰＣＥとの間の通信プロトコルに基づく。したがってＰＣＥＰは、ＰＣＣに送信されたパスの結果が使用されたか、されないのかをＰＣＥに知らせるために、通知メッセージ（ＰＣＮｔｆメッセージ）によって強化される。この通知メッセージは、特定のパス計算要求を参照するために要求パラメータ（ＲＰ）オブジェクトを含むことになる。そのようなＲＰオブジェクトは、すでにオプションとしてＰＣＥＰ通知プロトコルメッセージの中に存在している。好ましい実施形態では、新たなＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトが定義される。これは、通知のクラスを特定する新たな通知の型を標準のＮＯＴＩＦＩＣＡＴＩＯＮオブジェクト構造の中で定義することによって行われる。本明細書では、このクラスは「ＥＲＯｐａｔｈｕｓａｇｅ」と呼ばれる。

さらに、２つの通知値もまた、通知の性質に関連した重要な追加情報、すなわち使い方「ＹＥＳ／ＥＲＯａｐｐｌｉｅｄ」または「ＮＯ／ＥＲＯｎｏｔａｐｐｌｉｅｄ」を与えて定義される。

ＲＰオブジェクトはＩＥＴＦ（参照により本明細書に組み込まれているインターネット文書ｄｒａｆｔ−ｉｅｔｆ−ｐｃｅ−ｐｃｅｐ−０８．ｔｘｔ）によって、ＰＣＥＰの状況の中で特定され、パス計算要求の様々な特性を特定するために使用される。

ＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトはもっぱらＰＣＮｔｆメッセージの中で運搬され、ＰＣＣからＰＣＥへ、またはＰＣＥからＰＣＣへ送信されるメッセージの中でイベントの通知のために使用されることができる。言及されたインターネット文書は、そのようなＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトのフォーマットについても説明している。

このフォーマットは、通知のクラスを特定する通知型（ＮＴ）のための８ビット、および通知の性質に関連した追加情報を提供する通知値（ＮＶ）のための８ビットを含み、その後に複数の任意ＴＬＶ（型、長さ、値）フィールドが続く。

好ましい実施形態で、特定の値（「ＥＲＯｐａｔｈｕｓａｇｅ」）は、ＰＣＥ_ｒｅｑの応答の中でＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトがＰＣＥからＰＣＣへのＰＣＥ_ｒｅｐメッセージの中で与えられる１つのＥＲＯの使い方の状態に関連するということを確認するために、通知型（ＮＴ）フィールドのために存在する。ＮＶフィールドの値は、ＥＲＯが使用されるのかどうかを特定する。２つの可能な値は「ＹＥＳ／ＥＲＯａｐｐｌｉｅｄ」または「ＮＯ／ＥＲＯｎｏｔａｐｐｌｉｅｄ」である。したがって、ＥＲＯと名の付くＴＬＶは、関連したパスを特定するＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトの中に含まれる。

任意で、さらなる改良として、ＲＥＡＳＯＮと名の付くＴＬＶは、ＮＶフィールドの値が、提案されたパスが確立されなかった理由を特定する「ＮｏｔＥｓｔａｂｌｉｓｈｅｄ」である場合、ＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトの中に含まれてもよい。

計算されたパスの使い方についての情報を通じて、ＰＣＥはより高い精度でネットワークの状態を改良することができる。したがって、ステートフルなＰＣＥの実装は簡略化される。ブロッキングの可能性は、パスがステートレスなＰＣＥによって計算されるよりも、ステートフルなＰＣＥによって計算される方がより低くなる。

知られているパス計算モデルによって、ＰＣＥは、ネットワークリソースの利用可能性を判定するためのＯＳＰＦ−ＴＥメッセージを分析することによって、パスの設定を知らされる。次いで、ＰＣＥはこの新しい情報を以前に計算され、提案されたルートと比較して、その提案されたルートの「成功の機会」を見つけ出し、また必要であればその動作を変更することができる。

ＰＣＣからＰＣＥへの直接肯定応答の導入は、ＰＣＥでの計算上の労力を減らす。さらに、それが制御プレーンメッセージに影響を与えることはなく、制御プレーンの複雑度を増すことはない。

任意の理由は、この計算をさらに改良することができる。一方、例えばこのＰＣＣが複数のＰＣＥに対して同じパス計算を要求しており、その後信号送信のためのすべての応答パスの中で、それらのうちの１つだけを選択する場合など、単純な「Ｎｏ」値もＰＣＣによって使用されることができる。その後ＰＣＣは、「Ｎｏ」値のＥＲＯｕｓａｇｅオブジェクトを備えた通知メッセージを選ばれていないＰＣＥに送信することができる。このような場合、ＰＣＣはその選択をＰＣＥに対して正当化するための理由を持たない。

図１および図２の例示的な実施形態では、ＰＣＥが１つだけのネットワークアーキテクチャが示されている。当業者には、本発明がそのようなアーキテクチャに決して限定されるわけではないということを理解されたい。ＲＦＣ４６５５のセクション５で詳細に説明されているように、様々なその他のＰＣＥアーキテクチャが考案されることが可能である。

単純化のために、図１および図２には１つのみのノードＮ１がＰＣＣ機能とともに示されているが、これが必ずしもその場合というわけではなく、本発明は複数またはすべてのネットワーク要素がＰＣＣ機能を有するその他のアーキテクチャも包含する。

図３は、本発明による、図１のデータネットワークの中に含まれるパス計算要素（ＰＣＥ）の詳細な概略図を示す。ＰＣＥ３１は、ＯＳＰＦ−ＴＥなどのＩＧＰを使用する制御プレーンメッセージを介してネットワークの中の他のエンティティからリンク状態情報を受信するための制御プレーン信号エンジン３２を有する。ＰＣＥ３１は、リンク状態情報をトラフィックエンジニアリングデータベース（ＴＥＤ）３４の中に記憶する。さらに、ＰＣＥ３１は、ＴＥＤ３４に記憶されたリンク状態情報に基づいてネットワークパスを計算するための処理手段３３を備える。インタフェース３５は、ＰＣＥＰを使用したＰＣＣとの通信のために役立つ。

パス計算要求はインタフェース３５で受信されて、プロセッサ３３に転送され、プロセッサ３３はその要求に対応するパスを計算する。結果は、インタフェース３５によってＰＣＣに戻される。本発明によって、その後ＰＣＣは、提案されたパスが使用されたか、されないのかを示す肯定応答を返送する。この肯定応答もまたインタフェース３５で受信されて、プロセッサ３３に転送され、状態情報としてＴＥＤ３４の中に記憶される。代替として、肯定応答から得られたリンク状態情報は、ＴＥＤではなく増設メモリの中に記憶されることも可能である。

図４は、本発明によるネットワーク要素の概略的なブロック図を示す。すでに上で述べたように、本明細書では一般にネットワーク４０として示されているネットワーク要素Ｎ１は、第１手段４２および第２手段４３を含む信号エンジン４１を備える。この第１手段４２は、特定のリンクが各々の所定の容量（ｆｉｌｌｉｎｇｃａｐａｃｉｔｙ）に達した場合、またはリンクの障害が検出された場合に、データネットワークＮＥＴ（図１）の中のその他のネットワーク要素に通知するメッセージを生成するために考案されている。上述の第１手段４２の機能は、インターネットプロトコルスイートの中でも最も重要な信号プロトコルの１つである標準的なリソース予約プロトコルトラフィックエンジニアリング（ＲＳＶＰ−ＴＥ）の機能に相当するということを当業者には理解されたい。

さらに当業者に知られているように、ＲＳＶＰはデータネットワークの中の送信者から受信者へ特別なメッセージを送信することを含み、このメッセージはＲＳＶＰパスメッセージと呼ばれる。この型のメッセージは、送信者から受信者への可能なパスを検出するために使用される。通過したルータはログされ、受信者に通知される。受信者は、パスに沿ってＲＳＶＰ予約メッセージと呼ばれるさらなるメッセージを送信する。パスに沿ったルータは、ＲＳＶＰ予約メッセージに含まれた仕様によってリソースを予約するか、またはエラーメッセージを返送する。ＲＳＶＰ予約メッセージが送信者に達する場合、後者は予約によって決まり、ＬＳＰを確立してもよい。

第２手段４３は、ＰＣＥとの通信に役立つＰＣＥＰインタフェースである。新たなパスが確立されなければならない場合、ネットワーク要素４０はＰＣＥＰインタフェース４３で、パス計算要求を関連したＰＣＥに送信する。ＰＣＥがパスを計算している場合、パスのための提案はインタフェース４３で受信される。本発明によって、パスが確立される場合、ネットワーク要素４０はインタフェース４３で、ＰＣＥによって提案されたルートをパスが使用するかどうかということ、または任意で提案されたパスが使用されなかった理由を示す肯定応答を送信する。

当業者には理解されるように、本発明は必ずしもＯＳＰＦルート選択プロトコルの使用に限定されるわけではなく、代わりに、ネットワーク情報をＰＣＥのために集めることができる任意のその他の今後の標準プロトコルが使用されることが可能である。さらに、本発明はＰＣＥに通知するための既存のＲＳＶＰメッセージの使用に限定されるわけではない。代替として、（例えばｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｐｃｅ−ｐｃｅｐ−０２．ｔｘｔで開示されているように）パス計算要素（ＰａｔｈＣｏｍｐｕｔａｔｉｏｎＥｌｅｍｅｎｔ）（ＰＣＥ）通信プロトコル（ＣｏｍｍｕｎｉｃａｔｉｏｎＰｒｏｔｏｃｏｌ）（ＰＣＥＰ）が使用されることが可能である。しかしながら、この場合、ＰＣＣは通知を望むノード上に存在すべきである。

Claims

ラベルスイッチネットワーク（ＮＥＴ）の中でパス（Ｐ）を計算する方法であって、
トラフィックエンジニアリングデータベース（３４）の中に、前記ラベルスイッチネットワーク（ＮＥＴ）についてのトポロジーおよびリソース情報を記憶するステップと、
ステートフルなパス計算要素（ＰＣＥ１）で、パス計算クライアント（ＰＣＣ１）からパス計算要求（ＲＥＱ）を受信するステップと、
前記トポロジーおよびリソース情報を使用して、前記パス計算要求（ＲＥＱ）を満たすパス（Ｐ）を計算するステップと、
前記計算されたパス（Ｐ）を含むパス計算応答（ＰＣＲ）を、前記パス計算クライアント（ＰＣＣ１）に送信するステップとを含む方法において、
前記パス計算クライアント（ＰＣＣ１）が、ラベルスイッチパスを設定するために前記計算されたパス（Ｐ）が前記パス計算クライアント（ＰＣＣ１）によって使用されたかどうかを示す肯定応答（ＡＣＫ）を、前記パス計算要素（ＰＣＥ１）に返送することを特徴とする、方法。
肯定応答（ＡＣＫ）が、前記パス計算要素（ＰＣＥ１）と前記パス計算クライアント（ＰＣＣ１）との間の通信のために使用されるパス計算要素通信プロトコルに基づく、請求項１に記載の方法。
前記パス計算要素通信プロトコルが、前記肯定応答（ＡＣＫ）として使用されるために通知メッセージによって強化されている、請求項２に記載の方法。
前記通知メッセージが、特定のパス計算要求（ＲＥＱ）を参照するために要求パラメータオブジェクトを含む、請求項３に記載の方法。
新たなＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトが前記通知のために定義される、請求項３に記載の方法。
新たなＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトが、標準的なＮＯＴＩＦＩＣＡＴＩＯＮオブジェクト構造を使用して定義され、本明細書では「ＥＲＯｐａｔｈｕｓａｇｅ」と呼ばれる通知のクラスを特定する通知型、および「ＹＥＳ／ＥＲＯａｐｐｌｉｅｄ」または「ＮＯ／ＥＲＯｎｏｔａｐｐｌｉｅｄ」の値のうちの１つを使用して通知の性質を示す２つの通知値を定義する、請求項５に記載の方法。
ＮＯＴＩＦＩＣＡＴＩＯＮオブジェクトが、提案されたパスが確立されなかった理由を示すフィールドをさらに含む、請求項６に記載の方法。
ラベルスイッチネットワーク（ＮＥＴ）で使用するためのステートフルなパス計算要素（ＰＣＥ１、３１）であって、
前記ラベルスイッチネットワーク（ＮＥＴ）についてのトポロジーおよびリソース情報を記憶するためのトラフィックエンジニアリングデータベース（３４）と、
少なくとも１つのパス計算クライアント（ＰＣＣ１）と通信するためのインタフェース手段（３５）と、
パス計算クライアント（ＰＣＣ１）からパス計算要求（ＲＥＱ）を受信した上で、前記トポロジーおよびリソース情報を使用して、前記パス計算要求（ＲＥＱ）を満たすパス（Ｐ）を計算するための処理手段（３３）とを備えるステートフルなパス計算要素（ＰＥＣ１、３１）において、
前記インタフェース手段（３５）が、ラベルスイッチパスを設定するために、提案された以前に計算されたパス（Ｐ）が前記パス計算クライアント（ＰＣＣ１）によって使用されたかどうかを示す肯定応答（ＡＣＫ）を前記パス計算クライアント（ＰＣＣ１）から受信するように構成され、前記処理手段（３３）が、前記肯定応答（ＡＣＫ）によって通信されたリンク状態情報を今後のパス計算のために考慮するように構成されることを特徴とする、ステートフルなパス計算要素（ＰＥＣ１、３１）。
ラベルスイッチネットワーク（ＮＥＴ）で使用するためのパス計算クライアント（ＰＣＣ１、４０）であって、ラベルスイッチパスを確立するために前記ネットワーク（ＮＥＴ）でネットワーク要素（ｎ１−ｎ９、Ｎ２）と通信するための第１インタフェース手段（４２）と、パス計算要素（ＰＣＥ１）と通信するための第２インタフェース手段（４３）とを備え、前記第２インタフェース手段（４３）が、前記パス計算要素（ＰＣＥ１）にパス計算要求（ＲＥＱ）を送信するように、および確立されるべきパス（Ｐ）についての提案を含むパス計算応答（ＰＣＲ）を前記パス計算要素（ＰＣＥ１）から受信するように構成されているパス計算クライアント（ＰＣＣ１、４０）において、
前記第２インタフェース手段（４３）が、ラベルスイッチパスを設定するために、前記提案されたパス（Ｐ）が前記パス計算クライアント（ＰＣＣ１）によって使用されたかどうかを示す肯定応答（ＡＣＫ）を前記パス計算要素（ＰＣＥ１）に返送するようにさらに構成されていることを特徴とする、パス計算クライアント（ＰＣＣ１、４０）。