(57)【要約】【課題】経路途中の中継ノードについては特別な機能を付加することなく、双方向パスを同一経路で１回の操作で確立する。【解決手段】順方向パスのパスメッセージ１０００に含まれるＲＲＯを抽出し、逆方向パスのパスメッセージ１００６にＥＲＯとして挿入する。逆方向パスのパスメッセージ１００６は順方向パスのリザーブ確認メッセージ１００４の受信を契機として送出する。【選択図】図３
2008193395.tif 000002
【特許請求の範囲】
【請求項１】
第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを第１のノードから第２のノードまで転送することを含む第１のパス確立手順により、第１のノードを始点とし第２のノードを終点とする第１のパスを確立し、
第２のパスの確立を要求する第２のパスメッセージであって第２のノードにおいて受信された第１のパスメッセージが有する前記経路の記録に基いて決定された経路指定を含むものを第２のノードから第１のノードまで転送することを含む第２のパス確立手順により、第２のノードを始点とし第１のノードを終点とする第２のパスを第１のパスの経路に沿って逆方向に確立することを含む、双方向パスの確立方法。
【請求項２】
前記第１のパス確立手順は、
第１のパスメッセージの受信に応答して、第１のパスについて割り当てられたラベルを運ぶ第１のリザーブメッセージを第２のノードから第１のノードまで転送し、
第１のリザーブメッセージの受信に応答して、第１のリザーブメッセージが届いたことを確認する第１のリザーブ確認メッセージを第１のノードから第２のノードまで転送することを含み、
前記第２のパス確立手順における前記第２のパスメッセージは、第１のリザーブ確認メッセージの受信に応答して第２のノードから送出される請求項１記載の方法。
【請求項３】
前記第２のパス確立手順における前記第２のパスメッセージは、前記第１のパス確立手順における前記第１のパスメッセージの受信に応答して第２のノードから送出される請求項１記載の方法。
【請求項４】
前記第１のパスメッセージは、確立すべきパスが単方向であるか双方向であるかの指定をさらに有し、前記第２のパスメッセージは、第１のパスメッセージが双方向の指定を有するときのみ第２のノードから送出される請求項１記載の方法。
【請求項５】
第１のノードと第２のノードの間に双方向のパスを確立する際の第２のノードにおける双方向パス確立方法であって、
第１のノードからの、第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを受信し、
第２のパスの確立を要求する第２のパスメッセージであって第２のノードにおいて受信された第１のパスメッセージが有する前記経路の記録に基いて決定された経路指定を含むものを送信することを含む方法。
【請求項６】
前記第２のパスメッセージは、前記第１のパスメッセージに応答して第２のノードから第１のノードまで転送される第１のリザーブメッセージに応答して第１のノードから第２のノードまで転送される、第１のリザーブ確認メッセージの受信に応答して送信される請求項５記載の方法。
【請求項７】
前記第２のパスメッセージは、前記第１のパスメッセージの受信に応答して送信される請求項５記載の方法。
【請求項８】
前記第１のパスメッセージは、確立すべきパスが単方向であるか双方向であるかの指定をさらに有し、前記第２のパスメッセージは第１のパスメッセージが双方向の指定を有するときのみ送信される請求項５記載の方法。
【請求項９】
第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを第１のノードから第２のノードまで転送することを含む第１のパス確立手順により、第１のノードを始点とし第２のノードを終点とする第１のパスを確立する第１のパス確立手段と、
第２のパスの確立を要求する第２のパスメッセージであって第２のノードにおいて受信された第１のパスメッセージが有する前記経路の記録に基いて決定された経路指定を含むものを第２のノードから第１のノードまで転送することを含む第２のパス確立手順により、第２のノードを始点とし第１のノードを終点とする第２のパスを第１のパスの経路に沿って逆方向に確立する第２のパス確立手段とを具備する、通信システム。
【請求項１０】
前記第１のパス確立手段は、
第１のパスメッセージの受信に応答して、第１のパスについて割り当てられたラベルを運ぶ第１のリザーブメッセージを第２のノードから第１のノードまで転送する手段と、
第１のリザーブメッセージの受信に応答して、第１のリザーブメッセージが届いたことを確認する第１のリザーブ確認メッセージを第１のノードから第２のノードまで転送する手段とを含み、
前記第２のパス確立手段における前記第２のパスメッセージは、第１のリザーブ確認メッセージの受信に応答して第２のノードから送出される請求項９記載のシステム。
【請求項１１】
前記第２のパス確立手段における前記第２のパスメッセージは、前記第１のパス確立手段における前記第１のパスメッセージの受信に応答して第２のノードから送出される請求項９記載のシステム。
【請求項１２】
前記第１のパスメッセージは、確立すべきパスが単方向であるか双方向であるかの指定をさらに有し、前記第２のパスメッセージは第１のパスメッセージが双方向の指定を有するときのみ第１のノードから送出される請求項９記載のシステム。
【請求項１３】
第１のノードとの間で双方向パスを確立することの可能なノード装置であって、
第１のノードからの、第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを受信したとき、第１のパスメッセージから経路の記録を抽出する手段と、
第２のパスの確立を要求する第２のパスメッセージであって抽出された前記経路の記録に基いて決定された経路指定を含むものを送信する手段とを含むノード装置。
【請求項１４】
前記第２のパスメッセージは、前記第１のパスメッセージに応答して第２のノードから第１のノードまで転送される第１のリザーブメッセージに応答して第１のノードから第２のノードまで転送される、第１のリザーブ確認メッセージの受信に応答して送信される請求項１３記載のノード装置。
【請求項１５】
前記第２のパスメッセージは、前記第１のパスメッセージの受信に応答して送信される請求項１３記載のノード装置。
【請求項１６】
前記第１のパスメッセージは、確立すべきパスが単方向であるか双方向であるかの指定をさらに有し、前記第２のパスメッセージは第１のパスメッセージが双方向の指定を有するときのみ送信される請求項１３記載のノード装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は双方向パスの設定方法とそれを実現するための通信システムとノード装置、特に、ＭＰＬＳ（Multi Protocol Label Switching）プロトコルをサポートするノードのネットワーク間に双方向パスを設定する方法とそれを実現するための通信システムとノード装置に関する。
【背景技術】
【０００２】
ＭＰＬＳにおいてパス（ＬＳＰ：Label Switch Path）をセットアップ（確立）するために装置間でダイナミックにラベル配布を行うプロトコルとして、ＲＦＣ３２０９で定義されるＲＳＶＰ−ＴＥ（Resouce reSerVation Protocol-Traffic Engineering）がある。このＲＳＶＰ−ＴＥは、図１のようにＩｎｇｒｅｓｓ  ｎｏｄｅ−＞Ｅｇｒｅｓｓ  ｎｏｄｅにＬＳＰセットアップの要求に相当するパスメッセージ（Path）を投げ、その逆方向にリザーブメッセージ（Resv）を用いて転送するためのラベルを返して、ＬＳＰをセットアップする。図１に示す様に、２拠点＃１，＃３間で双方向に通信する場合は、＃１（Ｉｎｇｒｅｓｓ）⇒＃３（Ｅｇｒｅｓｓ）と＃３（Ｉｎｇｒｅｓｓ）⇒＃１（Ｅｇｒｅｓｓ）のそれぞれの方向にシグナリング１０，１２により、それぞれ独立にＬＳＰ１４，１６がセットアップされる。ここで、このＬＳＰ１４，１６のセットアップタイミングは、それぞれ独立であり、経路は必ずしも同一とはならない。これは、帯域の使用状況等により、ｎｏｄｅ＃１，＃２，＃３それぞれがＬＳＰセットアップ時に、独立に経路を選ぶためである。
【０００３】
Ｐｓｅｕｄｏ  Ｗｉｒｅは、このＭＰＬＳを用いて２つの拠点間を疑似的なワイヤで接続するものである。疑似的なワイヤとは、ＳＯＮＥＴ／ＷＤＭ，ＡＴＭ、フレームリレーなど、あらゆるプロトコルのデータを運ぶことのできる双方向に確立されたパスである。この場合に、従来のＳＯＮＥＴ／ＷＤＭの様に、２拠点間を結ぶパスは同一経路を取り、セットアップのタイミングも同時であるほうがネットワーク管理上望ましい。その理由は、別々の経路を通るよりも同じ経路を通る方がオペレータにとってわかり易く把握が容易であり、セットアップのタイミングが同時であれば１回の操作で済むからである。
【０００４】
しかし、このＰｓｅｕｄｏ  ｗｉｒｅを通すＭＰＬＳ  ＬＳＰを張るためのラベル配布プロトコルには一般的にＲＳＶＰ−ＴＥが用いられるので、上記の様に順方向と逆方向のＬＳＰは２拠点間で同一経路を通る保証はなく、ＬＳＰのセットアップタイミングも独立であるので管理が煩雑になってしまうという問題がある。
【０００５】
Ｅｘｐｌｉｃｉｔ  Ｒｏｕｔｅ  Ｏｂｊｅｃｔ（ＥＲＯ）を用いて、明示的に経路指定をすることにより、双方向のＬＳＰを同一経路で張ることは可能である。しかしながら、順方向ＬＳＰと逆方向ＬＳＰは独立であるため、セットアップのタイミングに関連性はない。例えば手動により順方向ＬＳＰをセットアップした後に、逆方向にＬＳＰをセットアップすることは可能であるが、自動的に順方向ＬＳＰそして逆方向ＬＳＰをセットアップすることはできない。また、経路についても、２つのＬＳＰを同一経路にするためには人による管理が必要となる。
【０００６】
ＬＳＰを同一経路で同時にセットアップするための技術として、Ｇ（General）ＭＰＬＳ用に拡張がなされたＲＳＶＰ−ＴＥ（ＲＦＣ３４７３）がある。これは上記ＲＦＣ３２０９のＲＳＶＰ−ＴＥに対して、新たにＵｐｓｔｒｅａｍ  Ｌａｂｅｌ  ｏｂｊｅｃｔ等を付加して拡張したものである。このＧＭＰＬＳ  ＲＳＶＰ−ＴＥでは、図２に示す様にパスメッセージにＵｐｓｔｒｅａｍ  Ｌａｂｅｌ  ｏｂｊｅｃｔ（ＵＬＯ）を付与して、逆方向ＬＳＰのためのラベルをパスメッセージで配布することにより、Ｐａｔｈ／Ｒｅｓｖ  ｍｅｓｓａｇｅを１往復するのみで双方向ＬＳＰをセットアップすることが可能となる。なお、順方向ＬＳＰのためのラベルは従来通りリザーブメッセージで配布される。
【０００７】
しかし、ＭＰＬＳ  ＲＳＶＰ−ＴＥまでをサポートしＧＭＰＬＳ  ＲＳＶＰ−ＴＥをサポートしていないノードがこのＯｂｊｅｃｔを受信した場合、解釈できず廃棄するため、双方向ＬＳＰを実現する場合は、ドメイン内のノードをすべてこのＧＭＰＬＳ  ＲＳＶＰ−ＴＥに拡張しなければならないという問題がある。
【０００８】
【特許文献１】特開２００４−２３３８２号公報
【非特許文献１】ＩＥＴＦ  ＲＦＣ３２０９（http://www.ietf.org/rfc/rfc3209.txtからダウンロード可能）
【非特許文献２】ＩＥＴＦ  ＲＦＣ３４７３（http://www.ietf.org/rfc/rfc3473.txtからダウンロード可能）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって本発明の目的は、経路途中の中継ノードについては特別な機能を付加することなく、双方向パスを同一経路で確立することの可能な双方向パスの確立方法を提供することにある。
【００１０】
本発明のさらなる目的は、経路途中の中継ノードについては特別な機能を付加することなく、１回の操作で双方向パスを確立することの可能な双方向パスの確立方法を提供することにある。
【課題を解決するための手段】
【００１１】
前述の目的は、第１のパスの確立を要求する第１のパスメッセージであってそれが通った経路の記録を有するものを第１のノードから第２のノードまで転送することを含む第１のパス確立手順により、第１のノードを始点とし第２のノードを終点とする第１のパスを確立し、第２のパスの確立を要求する第２のパスメッセージであって第２のノードにおいて受信された第１のパスメッセージが有する前記経路の記録に基いて決定された経路指定を含むものを第２のノードから第１のノードまで転送することを含む第２のパス確立手順により、第２のノードを始点とし第１のノードを終点とする第２のパスを第１のパスの経路に沿って逆方向に確立することを含む、双方向パスの確立方法によって達成される。
【００１２】
前述のさらなる目的は、前記第１のパス確立手順は、第１のパスメッセージの受信に応答して、第１のパスについて割り当てられたラベルを運ぶ第１のリザーブメッセージを第２のノードから第１のノードまで転送し、第１のリザーブメッセージの受信に応答して、第１のリザーブメッセージが届いたことを確認する第１のリザーブ確認メッセージを第１のノードから第２のノードまで転送することを含み、前記第２のパス確立手順における前記第２のパスメッセージは、第１のリザーブ確認メッセージの受信に応答して第２のノードから送出される方法により達成される。
【発明を実施するための最良の形態】
【００１３】
図３は本発明の一実施形態に係り、ノード＃１とノード＃３との間に双方向ＬＳＰを確立するための手順を示すシーケンス図である。図３において、まずノード＃１→ノード＃３の順方向パスを確立するためのパスメッセージ１０００がノード＃１から送出される。このパスメッセージ１０００にはパスの経路を指定するＥＲＯ（Explicit Route Object）の他にパスメッセージが実際に通った経路を記録するためのＲＲＯ（Record Route Object）が含まれている。
【００１４】
パスの経路を指定するＥＲＯには確立すべきパスの経路を例えばノード装置の番号と入力インターフェースの番号とで厳密に指定するＳｔｒｉｃｔ指定と、例えばノード装置の番号のみを指定するＬｏｏｓｅ指定とがある。前者の場合には経路途中のノードに経路選択の余地はないが、後者の場合には指定されたノードまでの経路は各ノードが独立に選択する。いずれの場合にも、ＲＲＯにはパスメッセージが実際に通った経路が蓄積され記録される。
【００１５】
順方向パスの終点ノードであるノード＃３はこのパスメッセージ１０００を受信するとＭＰＬＳ  ＲＳＶＰ−ＴＥに従いリザーブメッセージ１００２を返す。このリザーブメッセージ１００２はＭＰＬＳ  ＲＳＶＰ−ＴＥに従ってパスメッセージ１００６が通った経路に沿って逆方向に転送される。このリザーブメッセージ１００２により順方向パスについてノード間のリンクに割り当てられたラベルが通知される。リザーブメッセージ１００２が順方向パスの始点ノードであるノード＃１に到達することにより、ノード＃１→ノード＃３の順方向ＬＳＰの確立が完了する。
【００１６】
設定すべきパスが双方向パスである場合、ノード＃１はさらに、確立されたパスに沿ってリザーブ確認メッセージ１００４を送出する。このリザーブ確認メッセージはリザーブメッセージが始点ノードに届いてパスが確立されたことを確認するものとしてＲＦＣ２２０５のＲＳＶＰ（Resource reSerVation Protocol）に規定されている。このメッセージの使用はオプションであるが、本発明では双方向パスを一度に確立する場合にこのリザーブ確認メッセージの受信を逆方向パス確立の契機とする。
【００１７】
すなわち、リザーブ確認メッセージ１００４を受信したノード＃３は、ノード＃３→ノード＃１の逆方向パスを確立するためのパスメッセージ１００６を送出する。このパスメッセージ１００６には、順方向パスのパスメッセージ１０００のＲＲＯの内容から決定されたＥＲＯが含まれている。このパスメッセージ１００６は順方向パスに含まれていたＲＲＯが示す経路と同じ経路を指定するＥＲＯが指定されているので、確立済みの順方向パスと同じ経路を逆方向にたどってノード＃１に到達する。ノード＃１はＲＳＶＰ−ＴＥに従いこのパスメッセージ１００６に応答してノード＃３へ向けてリザーブメッセージ１００８を送出する。このリザーブメッセージ１００８により逆方向パスのラベルが配布され、順方向パスと同じ経路で逆方向パスが確立される。ノード＃１では、逆方向パスのパスメッセージ１００６と順方向パスのリザーブメッセージ１００２にＲＲＯが付されていれば、両者を比較することにより順方向パスと逆方向パスが同一の経路上に確立されていることを確認することができる。
【００１８】
最後に、必須ではないが、リザーブ確認メッセージ１０１０がノード＃３からノード＃１へ送られる。
【００１９】
順方向パスのパスメッセージに含まれるＲＲＯとそれから決定される逆方向パスのＥＲＯとの関係をより詳細に説明する。図４に示すように、ノード＃１からノード＃３への順方向パスを確立するためのパスメッセージ１０００に含まれるＲＲＯには、それぞれのリンクで用いられた出力インターフェースの番号がノード番号とともに順次蓄積される。図に示した例では、ノード＃１からノード＃２へ転送されるパスメッセージのＲＲＯには、ノード＃１で用いた出力インターフェースの番号ＩＰ＃１−１が含まれる。ノード＃２からノード＃３へ転送されるパスメッセージのＲＲＯには、ノード＃２で用いた出力インターフェースの番号ＩＰ＃１−１が先頭に追加される。
【００２０】
図５に示すように、ノード＃３からノード＃１への逆方向パスを確立するためのパスメッセージ１００６のＥＲＯには、前述のＲＲＯの内容のコピーがｓｔｒｉｃｔ指定を示すフラグと共に格納される。各ノードではこのＥＲＯの内容を先頭から順に取り出すことによって設定すべきパスの経路を認識する。これにより、逆方向パスを順方向パスと同じ経路上に確立することができる。
【００２１】
ここで、本発明による双方向ＬＳＰと従来の単方向ＬＳＰが混在する運用を行う場合、Ｉｎｇｒｅｓｓ  ｎｏｄｅは双方向ＬＳＰを張る際に、そのＬＳＰを双方向ＬＳＰで張りたいという識別子をパスメッセージに埋め込む必要があり、Ｅｇｒｅｓｓ  ｎｏｄｅはそれを見てどちらのＬＳＰを要求されたかを識別し、動作を変える必要がある。双方向ＬＳＰのセットアップ要求をパスメッセージ内に示すためには、新たなオブジェクトを追加する方法もあり得るが、これでは既存のＲＳＶＰ−ＴＥの規定内で行うことはできない。既存のＲＳＶＰ−ＴＥの規定内で行うためには、Ｓｅｓｓｉｏｎ  Ａｔｔｒｉｂｕｔｅ  ＯｂｊｅｃｔのＳｅｓｓｉｏｎ  ｎａｍｅフィールドを用いるという方法が考えられる。通常このＳｅｓｓｉｏｎ  ｎａｍｅフィールドは管理を容易にするためにＬＳＰの名称を文字列で示すフィールドであり、たとえば“１ｔｏ２”などを与えることができる。このフィールドを利用し、この文字列の最後に“ ｂｉ”（たとえば先の例では“１ｔｏ２ ｂｉ”）となっている場合、双方向ＬＳＰを示すものと管理上決め、双方向ＬＳＰとして処理するようにすれば良い。
【００２２】
前述した例では、順方向パスの終点ノードであるノード＃３は順方向パスのリザーブ確認メッセージ１００４の受信を契機として逆方向パスのパスメッセージ１００６を送出して逆方向パスの確立手順を開始しているが、順方向パスのパスメッセージ１０００の受信を契機として逆方向パスのパスメッセージを送出して逆方向パスの確立手順を開始しても良い。この場合には、順方向パスのリザーブ確認メッセージ１００４も必須ではなくなる。
【００２３】
本発明において、ＭＰＬＳ  ＲＳＶＰ−ＴＥをサポート済みのノード装置に付加すべき機能は以下の様である。
【００２４】
〔順方向パスの始点ノード（ノード＃１）〕
（ｉ）双方向パス／単方向パスの識別をパスメッセージに付加する機能（双方向パスと単方向パスとが混在する場合）
（ii）順方向パスの経路と逆方向パスの経路との一致を確認する機能（経路一致の確認を行う場合）
【００２５】
〔逆方向パスの始点ノード（ノード＃３）〕
（ｉ）順方向パスのリザーブ確認メッセージまたはパスメッセージの受信に応答して逆方向パスのパスメッセージを送出する機能
（ii）順方向パスのパスメッセージに含まれるＲＲＯを抽出して逆方向パスのパスメッセージにｓｔｒｉｃｔ指定のＥＲＯとして挿入する機能
（iii）要求されているパスが双方向パスか単方向パスかを認識する機能（双方向パスと単方向パスとが混在する場合）
【００２６】
〔中継ノード〕
付加すべき機能なし
【００２７】
図６は本発明が適用されるノード装置２０の構成の一例を示す。ノード装置２０において処理されるパケットにはデータを運ぶＤ（データ）−ｐｌａｎｅパケットと、前述のパスメッセージ、リザーブメッセージなどの制御メッセージを運ぶＣ（制御）−ｐｌａｎｅパケットと、オペレータからのパス確立要求などのメッセージを運ぶネットワーク管理のためのＭ（管理）−ｐｌａｎｅパケットとがある。Ｄ−ｐｌａｎｅパケットはＩｎｇｒｅｓｓ側のインターフェース２２からスイッチ２４を経てＥｇｒｅｓｓ側のインターフェース２６へ供給される。Ｃ−ｐｌａｎｅパケットとＭ−ｐｌａｎｅパケットはＩｎｇｒｅｓｓ側のインターフェース２２からＣＰＵボート２８へ供給され、ＣＰＵボード２８からのＣ−ｐｌａｎｅパケットとＭ−ｐｌａｎｅパケットは直接Ｅｇｒｅｓｓ側のインターフェース２６へ供給される。
【００２８】
図７はＣＰＵボード２８の機能ブロック図である。ＣＰＵボード２８の機能は、Ｃ−ｐｌａｎｅパケットを処理するＣ−ｐｌａｎｅ処理部２９とＭ−ｐｌａｎｅパケットを処理するＭ−ｐｌａｎｅ処理部３０とに分けられる。Ｃ−ｐｌａｎｅ処理部２９は、ＯＳＰＦ／ＯＳＰＦ−ＴＥ処理部３２、ＲＳＶＰ処理部３４およびＣＳＰＦ処理部３６を含んでいる。ＯＳＰＦ／ＯＳＰＦ−ＴＥ処理部３２は、トポロジー情報を通知するＯＳＰＦパケットおよび帯域使用量を通知するＯＳＰＦ−ＴＥ（Traffic Engineering）パケットを処理してＣＳＰＦ（Constrained Shortest Path First）処理部３６内に経路選択のためのデータベースを構築する。ＲＳＶＰ処理部３４は前述のパスメッセージ、リザーブメッセージなどを運ぶＲＳＶＰパケットの生成、メッセージ内のオブジェクトの解析、抽出、挿入などを行う。ＣＳＰＦ処理部３６はＲＳＶＰ処理部３４からの依頼に応じてデータベースを参照してＥＲＯに指定された次のノードまでの経路計算（経路の選択）を行い、パスの帯域を確保する。経路計算結果はＲＳＶＰ処理部３４においてパスメッセージのＥＲＯ内に挿入される。ＲＳＶＰ処理部３４はまた、リザーブメッセージで配布されるラベルの管理も行う。
【００２９】
図８は、順方向パスの終点ノード（図１〜５の例ではノード＃３）において、本発明を実現するために新たに追加されるべき機能の詳細を示す。
【００３０】
ＲＳＶＰ処理部３４の双方向パス判定部４０では、自ノードを終点ノードとするパスメッセージを受信したとき、双方向パスの確立が要求されているか否かを判定する。双方向パス判定部４０で双方向パスの確立が要求されていると判定されるとき、ＲＳＶＰ処理部３４は通常のＲＳＶＰ−ＴＥの処理に加えて、双方向パス確立のための処理を実行する。すなわち、パスメッセージからＲＲＯを抽出し（４２）、ＣＳＰＦ処理部３６の経路計算部４４へ通知する。経路計算部４４では通知されたＲＲＯの内容にｓｔｒｉｃｔフラグを付して逆方向パスのＥＲＯとする。ＲＳＶＰ部３４が順方向パスについてのリザーブ確認メッセージを受信したら、逆方向パスメッセージを生成し、経路計算部４４から通知されたＥＲＯを挿入して（４５）送出する。
【図面の簡単な説明】
【００３１】
【図１】従来のＭＰＬＳ  ＲＳＶＰ−ＴＥによる双方向パスの確立手順を説明するシーケンス図である。
【図２】従来のＧＭＰＬＳ  ＲＳＶＰ−ＴＥによる双方向パスの確立手順を説明するシーケンス図である。
【図３】本発明の双方向パスの確立手順を示すシーケンス図である。
【図４】順方向パスのパスメッセージに含まれるＲＲＯの詳細を示す図である。
【図５】逆方向パスのパスメッセージに含まれるＥＲＯの詳細を示す図である。
【図６】本発明が適用されるノード装置の構成の一例を示すブロック図である。
【図７】図６のＣＰＵボードの機能ブロック図である。
【図８】順方向パスの終点ノードにおいて本発明を実現するために追加される機能の詳細を示す機能ブロック図である。
【図１】
2008193395.tif 000003
【図２】
2008193395.tif 000004
【図３】
2008193395.tif 000005
【図４】
2008193395.tif 000006
【図５】
2008193395.tif 000007
【図６】
2008193395.tif 000008
【図７】
2008193395.tif 000009
【図８】
2008193395.tif 000010