JP3072728B2 - マルチポイントコネクション障害回復方法及びシステム - Google Patents
マルチポイントコネクション障害回復方法及びシステムInfo
- Publication number
- JP3072728B2 JP3072728B2 JP21852798A JP21852798A JP3072728B2 JP 3072728 B2 JP3072728 B2 JP 3072728B2 JP 21852798 A JP21852798 A JP 21852798A JP 21852798 A JP21852798 A JP 21852798A JP 3072728 B2 JP3072728 B2 JP 3072728B2
- Authority
- JP
- Japan
- Prior art keywords
- connection
- node
- message
- terminal
- failure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/028—Dynamic adaptation of the update intervals, e.g. event-triggered updates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/10—Routing in connection-oriented networks, e.g. X.25 or ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
- H04L45/488—Routing tree calculation using root node determination
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】本発明はコネクションオリエ
ンティッドネットワークの障害回復に係り、特にポイン
ト−マルチポイントコネクションにおいて障害が発生し
たときの障害回復方法及びシステムに関する。
ンティッドネットワークの障害回復に係り、特にポイン
ト−マルチポイントコネクションにおいて障害が発生し
たときの障害回復方法及びシステムに関する。
【０００２】
【従来の技術】ノード間で交換したトポロジ情報に基き
経路計算を行うソースルーティング方式を用いて回線接
続を行うコネクションオリエンティッドな通信網として
は、例えばＡＴＭ（非同期転送モード）ネットワークが
ある。ＡＴＭネットワークでは、一般的にポイント−ポ
イントコネクションのみを考慮した障害回避が行われて
いる。
経路計算を行うソースルーティング方式を用いて回線接
続を行うコネクションオリエンティッドな通信網として
は、例えばＡＴＭ（非同期転送モード）ネットワークが
ある。ＡＴＭネットワークでは、一般的にポイント−ポ
イントコネクションのみを考慮した障害回避が行われて
いる。
【０００３】ＡＴＭ Ｆｏｒｕｍにて行われている標準
化作業において、ポイント−ポイントコネクションにお
ける障害回復の技術は、David M. Kushi 及びEthan
M.Spiegelにより提案されている（ＡＦ／９７−０３９
１Ｒ１“Signalling Procedures for Fault Tolerant C
onnections” ATM Forum、April 27,1997、pp. 13-18、
及び ＡＦ／９７−０６３２“Procedures for Fast Co
nnection Recovery in PNNI Networks” ATM Forum、 J
uly 21,1997 pp. 9-17）。例えば、ネットワークのある
ノードに送信端末が接続され他のノードに着信端末が接
続された構成において、障害発生を示すメッセージがこ
れらノードに到着した時にこれらのノードにて切り替え
を行う方式や、ネットワークを論理的に階層化して管理
を行い、障害の状況に応じて、適切な論理階層の入力ノ
ードと出力ノードにて切り替えを行う方式などが提案さ
れている。
化作業において、ポイント−ポイントコネクションにお
ける障害回復の技術は、David M. Kushi 及びEthan
M.Spiegelにより提案されている（ＡＦ／９７−０３９
１Ｒ１“Signalling Procedures for Fault Tolerant C
onnections” ATM Forum、April 27,1997、pp. 13-18、
及び ＡＦ／９７−０６３２“Procedures for Fast Co
nnection Recovery in PNNI Networks” ATM Forum、 J
uly 21,1997 pp. 9-17）。例えば、ネットワークのある
ノードに送信端末が接続され他のノードに着信端末が接
続された構成において、障害発生を示すメッセージがこ
れらノードに到着した時にこれらのノードにて切り替え
を行う方式や、ネットワークを論理的に階層化して管理
を行い、障害の状況に応じて、適切な論理階層の入力ノ
ードと出力ノードにて切り替えを行う方式などが提案さ
れている。
【０００４】また、ポイント−マルチポイントコネクシ
ョンにおける接続技術については、同じくＡＴＭフォー
ラムにおいて、Ted Tedijanto等が提案している（ＡＦ
／９６−１４０１Ｒ３“Support for Leaf Initiated J
oin in PNNI” ATM Forum July 21,1997 pp. 2-30）。
ポイント−マルチポイントコネクションは、発信元であ
るルート端末から複数のリーフ端末（着信端末）に対し
て同時に送信する接続技術に関するものである。このポ
イント−マルチポイントの技術にはいくつかの方法が提
案されている。
ョンにおける接続技術については、同じくＡＴＭフォー
ラムにおいて、Ted Tedijanto等が提案している（ＡＦ
／９６−１４０１Ｒ３“Support for Leaf Initiated J
oin in PNNI” ATM Forum July 21,1997 pp. 2-30）。
ポイント−マルチポイントコネクションは、発信元であ
るルート端末から複数のリーフ端末（着信端末）に対し
て同時に送信する接続技術に関するものである。このポ
イント−マルチポイントの技術にはいくつかの方法が提
案されている。
【０００５】基本的なものは、ルート端末がマルチポイ
ント設定するすべてのリーフ端末についての設定処理を
行う方式である。具体的には、ルート端末からは最初に
接続するリーフ端末のコネクション設定を行うときにＳ
ＥＴＵＰ（セットアップ）メッセージを送信し、次以降
に接続するリーフ端末のコネクション設定を行うとき
は、ＡＤＤ＿ＰＡＲＴＹ（アド・パーティ）メッセージ
を送信し、経路が分岐するノードからはＳＥＴＵＰメッ
セージとして送信しコネクションの設定を行う。
ント設定するすべてのリーフ端末についての設定処理を
行う方式である。具体的には、ルート端末からは最初に
接続するリーフ端末のコネクション設定を行うときにＳ
ＥＴＵＰ（セットアップ）メッセージを送信し、次以降
に接続するリーフ端末のコネクション設定を行うとき
は、ＡＤＤ＿ＰＡＲＴＹ（アド・パーティ）メッセージ
を送信し、経路が分岐するノードからはＳＥＴＵＰメッ
セージとして送信しコネクションの設定を行う。
【０００６】しかし、このような基本的な設定方法で
は、リーフ端末の数が多くなるほど、ルート端末の処理
負荷や管理情報も大きくなるために、ネットワークＬＩ
Ｊ（Network Leaf Initiated Join）という接続方式が
別に提案されている。このネットワークＬＩＪ方式は、
リーフ端末からマルチポイントコネクション設定の依頼
があった場合に、ルート端末を介することなく接続設定
を行うものである。言い換えれば、ルート端末がコネク
ション設定の管理および接続を行うのではなく、ネット
ワーク内の所定ノード（代理ルートノード）にてマルチ
ポイントコネクションを管理し接続するものである。
は、リーフ端末の数が多くなるほど、ルート端末の処理
負荷や管理情報も大きくなるために、ネットワークＬＩ
Ｊ（Network Leaf Initiated Join）という接続方式が
別に提案されている。このネットワークＬＩＪ方式は、
リーフ端末からマルチポイントコネクション設定の依頼
があった場合に、ルート端末を介することなく接続設定
を行うものである。言い換えれば、ルート端末がコネク
ション設定の管理および接続を行うのではなく、ネット
ワーク内の所定ノード（代理ルートノード）にてマルチ
ポイントコネクションを管理し接続するものである。
【０００７】このネットワークＬＩＪ方式では、ネット
ワークとルート端末とのメッセージのやり取りは最初の
リーフ端末を接続するときのみ行われることになる。そ
して、他のリーフ端末がマルチポイント接続したい場合
には、その旨の要求を示すLEAF SETUP REQUEST（リーフ
・セットアップ・リクエスト）メッセージを送信し、そ
の要求を受けたリーフ端末が接続されているノード（終
端ノード）はルート端末までの経路計算を行い、その経
路に従ってLEAF SETUP REQUESTメッセージを送信する。
そして、ネットワーク内にルート端末が行うコネクショ
ンの管理接続処理を代わりに行う代理ルートノードが割
り当てられており、この代理ルートノードからリーフ端
末に対してＳＥＴＵＰメッセージもしくはＡＤＤ＿ＰＡ
ＲＴＹメッセージを送信してマルチポイントコネクショ
ン処理を行う。もちろん、この代理ルートノードは、既
設定のマルチポイントのコネクション上に存在すること
になる。
ワークとルート端末とのメッセージのやり取りは最初の
リーフ端末を接続するときのみ行われることになる。そ
して、他のリーフ端末がマルチポイント接続したい場合
には、その旨の要求を示すLEAF SETUP REQUEST（リーフ
・セットアップ・リクエスト）メッセージを送信し、そ
の要求を受けたリーフ端末が接続されているノード（終
端ノード）はルート端末までの経路計算を行い、その経
路に従ってLEAF SETUP REQUESTメッセージを送信する。
そして、ネットワーク内にルート端末が行うコネクショ
ンの管理接続処理を代わりに行う代理ルートノードが割
り当てられており、この代理ルートノードからリーフ端
末に対してＳＥＴＵＰメッセージもしくはＡＤＤ＿ＰＡ
ＲＴＹメッセージを送信してマルチポイントコネクショ
ン処理を行う。もちろん、この代理ルートノードは、既
設定のマルチポイントのコネクション上に存在すること
になる。
【０００８】このように、代理ルートノードよりルート
端末に近い方向に対しては、コネクションの設定に関す
るメッセージは送信されない。すなわち、ルート端末は
リーフ端末の管理を行う必要がないので、結果としてル
ート端末の処理負荷が軽減される。
端末に近い方向に対しては、コネクションの設定に関す
るメッセージは送信されない。すなわち、ルート端末は
リーフ端末の管理を行う必要がないので、結果としてル
ート端末の処理負荷が軽減される。
【０００９】
【発明が解決しようとする課題】しかしながら、ＡＴＭ
網における従来の障害回復方法は、ポイント−ポイント
コネクションを対象として切り替えを行っているため
に、上記ネットワークＬＩＪ方式にポイント−ポイント
コネクション用の障害回復方法をそのまま適用すること
ができない。なぜならば、ネットワークＬＩＪ方式の代
理ルートノードは、ルート端末に依存することなくネッ
トワーク内で新規のコネクションを設定しているため
に、その代理ルートノードとルート端末との間で障害が
発生した場合には、その代理ルートノードもルート端末
もいずれも障害発生コネクションの管理を行っていない
ので、復旧させようとしても、復旧できないからであ
る。
網における従来の障害回復方法は、ポイント−ポイント
コネクションを対象として切り替えを行っているため
に、上記ネットワークＬＩＪ方式にポイント−ポイント
コネクション用の障害回復方法をそのまま適用すること
ができない。なぜならば、ネットワークＬＩＪ方式の代
理ルートノードは、ルート端末に依存することなくネッ
トワーク内で新規のコネクションを設定しているため
に、その代理ルートノードとルート端末との間で障害が
発生した場合には、その代理ルートノードもルート端末
もいずれも障害発生コネクションの管理を行っていない
ので、復旧させようとしても、復旧できないからであ
る。
【００１０】また、コネクションを設定するときに、障
害などにより複数のＳＥＴＵＰメッセージが生成され送
信される可能性がある。この場合どのセットアップメッ
セージが正しいものであるかが不明なため、それぞれの
ＳＥＴＵＰメッセージにこのメッセージを送信するノー
ドがシーケンシャルに番号を付与して、一番新しい番号
のコネクション設定通知を利用すればよいことも提案さ
れている。この点は、ポイント−ポイントコネクション
では、このコネクション設定通知を送信する元のノード
において一元的に管理されているので、特に問題は生じ
なかった。しかし、ネットワークＬＩＪによるポイント
−マルチポイント形態のコネクションにおいては、やは
り、ＳＥＴＵＰメッセージを送信する代理ルートノード
を含むルート端末側で障害が発生したときに、この番号
の管理が困難になる。
害などにより複数のＳＥＴＵＰメッセージが生成され送
信される可能性がある。この場合どのセットアップメッ
セージが正しいものであるかが不明なため、それぞれの
ＳＥＴＵＰメッセージにこのメッセージを送信するノー
ドがシーケンシャルに番号を付与して、一番新しい番号
のコネクション設定通知を利用すればよいことも提案さ
れている。この点は、ポイント−ポイントコネクション
では、このコネクション設定通知を送信する元のノード
において一元的に管理されているので、特に問題は生じ
なかった。しかし、ネットワークＬＩＪによるポイント
−マルチポイント形態のコネクションにおいては、やは
り、ＳＥＴＵＰメッセージを送信する代理ルートノード
を含むルート端末側で障害が発生したときに、この番号
の管理が困難になる。
【００１１】本発明の目的は、ポイント−マルチポイン
トコネクションにおける障害発生時のネットワーク内に
おける自動回復方法及びシステムを提供することにあ
る。
トコネクションにおける障害発生時のネットワーク内に
おける自動回復方法及びシステムを提供することにあ
る。
【００１２】本発明の他の目的は、ネットワークＬＩＪ
方式によるポイント−マルチポイントコネクションにお
いて、障害が発生した時に簡単な手順で自律回復可能な
障害回復方法及びシステムを提供することにある。
方式によるポイント−マルチポイントコネクションにお
いて、障害が発生した時に簡単な手順で自律回復可能な
障害回復方法及びシステムを提供することにある。
【００１３】
【課題を解決するための手段】本発明によれば、複数の
ノードを通してコネクションの発信元である端末（以
下、ルート端末という。）と着信先である複数の端末
（以下リーフ端末という。）との間のマルチポイントコ
ネクションが、前記ルート端末の代わりにマルチポイン
トコネクションを管理し接続処理を行うノード（以下、
代理ルートノードという。）を所定の規則に従って決定
し、前記ルート端末に依存することなく網内で設定され
管理される方式のコネクションオリエンティッドな通信
網における障害回復方法において、あるリーフ端末と接
続しているノード（以下、終点ノードという。）では、
リーフ端末からの接続要求メッセージによりコネクショ
ンを設定した後で障害によるコネクション切断メッセー
ジを通信網のルート端末側から受信すると、リーフ端末
とのコネクションを維持したまま通信網へ接続要求メッ
セージを送信し、前記代理ルートノードでは、前記障害
によるコネクション切断メッセージを前記リーフ端末側
より受信すると前記ルート端末側のコネクションを維持
し、前記終点ノードから接続要求メッセージを受信する
と前記障害回復用の接続メッセージを送信し、これに対
応して前記終点ノードでは、通信網から接続要求メッセ
ージに対する障害回復用の接続メッセージを受信すると
当該接続メッセージによるコネクションと維持されたリ
ーフ端末側のコネクションとを接続して迂回経路へ切り
替え、前記代理ルートノードでは、前記障害回復用の接
続メッセージにより前記リーフ端末側とのコネクション
が確立した後で、前記維持されたルート端末側のコネク
ションと接続して迂回経路へ切り替える、ことを特徴と
する。
ノードを通してコネクションの発信元である端末（以
下、ルート端末という。）と着信先である複数の端末
（以下リーフ端末という。）との間のマルチポイントコ
ネクションが、前記ルート端末の代わりにマルチポイン
トコネクションを管理し接続処理を行うノード（以下、
代理ルートノードという。）を所定の規則に従って決定
し、前記ルート端末に依存することなく網内で設定され
管理される方式のコネクションオリエンティッドな通信
網における障害回復方法において、あるリーフ端末と接
続しているノード（以下、終点ノードという。）では、
リーフ端末からの接続要求メッセージによりコネクショ
ンを設定した後で障害によるコネクション切断メッセー
ジを通信網のルート端末側から受信すると、リーフ端末
とのコネクションを維持したまま通信網へ接続要求メッ
セージを送信し、前記代理ルートノードでは、前記障害
によるコネクション切断メッセージを前記リーフ端末側
より受信すると前記ルート端末側のコネクションを維持
し、前記終点ノードから接続要求メッセージを受信する
と前記障害回復用の接続メッセージを送信し、これに対
応して前記終点ノードでは、通信網から接続要求メッセ
ージに対する障害回復用の接続メッセージを受信すると
当該接続メッセージによるコネクションと維持されたリ
ーフ端末側のコネクションとを接続して迂回経路へ切り
替え、前記代理ルートノードでは、前記障害回復用の接
続メッセージにより前記リーフ端末側とのコネクション
が確立した後で、前記維持されたルート端末側のコネク
ションと接続して迂回経路へ切り替える、ことを特徴と
する。
【００１４】更に、終点ノードが送信する接続要求メッ
セージには、通信網から受信した接続要求メッセージが
最終的に採用されるべき否かを判定するための判定番号
と、当該接続要求メッセージで要求するコネクションを
一意に特定できる識別子とが付与されることを特徴とす
る。
セージには、通信網から受信した接続要求メッセージが
最終的に採用されるべき否かを判定するための判定番号
と、当該接続要求メッセージで要求するコネクションを
一意に特定できる識別子とが付与されることを特徴とす
る。
【００１５】更に、前記終点ノードでは、前記障害によ
るコネクション切断メッセージを受信した時は所定時間
に設定された監視タイマを起動し、前記障害回復用の接
続メッセージを受信した時は前記監視タイマを停止する
ことで、障害回復のための迂回処理が正常に行われてい
るかどうかを監視することを特徴とする。
るコネクション切断メッセージを受信した時は所定時間
に設定された監視タイマを起動し、前記障害回復用の接
続メッセージを受信した時は前記監視タイマを停止する
ことで、障害回復のための迂回処理が正常に行われてい
るかどうかを監視することを特徴とする。
【００１６】更に、代理ルートノードが送信する前記障
害回復用の接続メッセージには、終点ノードから受信し
た接続要求メッセージの判定番号より大きい値の番号が
付与される、ことを特徴とする。
害回復用の接続メッセージには、終点ノードから受信し
た接続要求メッセージの判定番号より大きい値の番号が
付与される、ことを特徴とする。
【００１７】以上説明したように、本発明によれば、障
害によるコネクション切断メッセージを通信網のルート
端末側から受信すると、リーフ端末とのコネクションを
維持したまま通信網へ接続要求メッセージを送信し、当
該障害箇所を迂回した別経路のコネクションを設定する
ことができるために、マルチポイントコネクションにお
いて障害が発生しても、自律的に回復することができ
る。
害によるコネクション切断メッセージを通信網のルート
端末側から受信すると、リーフ端末とのコネクションを
維持したまま通信網へ接続要求メッセージを送信し、当
該障害箇所を迂回した別経路のコネクションを設定する
ことができるために、マルチポイントコネクションにお
いて障害が発生しても、自律的に回復することができ
る。
【００１８】
【発明の実施の形態】コネクションオリエンティッドな
通信網の一例として、以下、ＡＴＭフォーラムにより規
定されたＰＮＮＩ（Private Network-Network Interfac
e）プロトコルに基づいたネットワークを示す。ここで
ＰＮＮＩプロトコルは、ネットワークのトポロジ情報
（ネットワークの接続状況やネットワーク資源の利用状
況など）を交換するためのルーティング技術と、コネク
ションを接続するためのシグナリング技術に関するもの
である。まず、ＰＮＮＩプロトコルを利用したネットワ
ークの構成について説明する。
通信網の一例として、以下、ＡＴＭフォーラムにより規
定されたＰＮＮＩ（Private Network-Network Interfac
e）プロトコルに基づいたネットワークを示す。ここで
ＰＮＮＩプロトコルは、ネットワークのトポロジ情報
（ネットワークの接続状況やネットワーク資源の利用状
況など）を交換するためのルーティング技術と、コネク
ションを接続するためのシグナリング技術に関するもの
である。まず、ＰＮＮＩプロトコルを利用したネットワ
ークの構成について説明する。
【００１９】図１は、本発明による障害回復システムの
一実施形態を適用したネットワークにおけるノードの機
能的構成を示すブロック図である。ネットワークを構成
する各ノードには、ルーティング手段１０１、シグナリ
ング手段１０２、及び経路計算手段１０３が設けられて
いるが、これらの機能は、例えばデータ処理部がそれぞ
れ対応するプログラムを実行することで実現することが
できる。
一実施形態を適用したネットワークにおけるノードの機
能的構成を示すブロック図である。ネットワークを構成
する各ノードには、ルーティング手段１０１、シグナリ
ング手段１０２、及び経路計算手段１０３が設けられて
いるが、これらの機能は、例えばデータ処理部がそれぞ
れ対応するプログラムを実行することで実現することが
できる。
【００２０】ルーティング手段１０１は、ＡＴＭフォー
ラムにて規定されたＰＮＮＩルーティングプロトコルと
同じ仕様のプロトコルをもつ。このルーティング手段１
０１は、通常より自ノードと隣接ノード間にてルーティ
ング用メッセージの交換をすることによりトポロジ情報
のやり取りをする。 隣接ノードから受信したトポロジ
情報が自ノードのトポロジ情報データベース１０４に格
納されたトポロジ情報と異なり、規定により更新する必
要があると判断した場合にはトポロジ情報データベース
１０４の内容が更新される。そして、受信したトポロジ
情報を他ノードへ転送する必要がある場合には、これを
送信する。この処理は、フラッディング（Flooding）と
呼ばれている。
ラムにて規定されたＰＮＮＩルーティングプロトコルと
同じ仕様のプロトコルをもつ。このルーティング手段１
０１は、通常より自ノードと隣接ノード間にてルーティ
ング用メッセージの交換をすることによりトポロジ情報
のやり取りをする。 隣接ノードから受信したトポロジ
情報が自ノードのトポロジ情報データベース１０４に格
納されたトポロジ情報と異なり、規定により更新する必
要があると判断した場合にはトポロジ情報データベース
１０４の内容が更新される。そして、受信したトポロジ
情報を他ノードへ転送する必要がある場合には、これを
送信する。この処理は、フラッディング（Flooding）と
呼ばれている。
【００２１】シグナリング手段１０２は大きく分けて２
つの処理を行う。ひとつは、端末からの要求によるコネ
クション設定／切断の処理であり、もうひとつは本発明
に関係するネットワーク内での障害発生によるコネクシ
ョン切断／再設定の処理である。これらの処理は、後述
するように、コネクション経路上の位置におけるノード
の役割、即ちそのノードが始点ノード、終点ノード、中
継ノード、あるいは代理ルートノードのいずれであるか
に依存して機能が異なる。
つの処理を行う。ひとつは、端末からの要求によるコネ
クション設定／切断の処理であり、もうひとつは本発明
に関係するネットワーク内での障害発生によるコネクシ
ョン切断／再設定の処理である。これらの処理は、後述
するように、コネクション経路上の位置におけるノード
の役割、即ちそのノードが始点ノード、終点ノード、中
継ノード、あるいは代理ルートノードのいずれであるか
に依存して機能が異なる。
【００２２】経路計算手段１０３は、後述するように、
リーフ端末のアドレスとトポロジ情報データベース１０
４のトポロジ情報とを用いて経路計算を行う。経路計算
の方法の例としては、最短経路を計算する周知のダイク
ストラ（Dijkstra）アルゴリズムなどの利用があげられ
る。計算結果は経路情報データベース１０５に格納され
る。 また、シグナリング手段１０２にはメッセージ情
報データベース１０６、迂回処理番号管理手段１０７、
パス切替手段１０８、及びタイマ１０９が接続されてい
る。
リーフ端末のアドレスとトポロジ情報データベース１０
４のトポロジ情報とを用いて経路計算を行う。経路計算
の方法の例としては、最短経路を計算する周知のダイク
ストラ（Dijkstra）アルゴリズムなどの利用があげられ
る。計算結果は経路情報データベース１０５に格納され
る。 また、シグナリング手段１０２にはメッセージ情
報データベース１０６、迂回処理番号管理手段１０７、
パス切替手段１０８、及びタイマ１０９が接続されてい
る。
【００２３】迂回処理番号管理手段１０７は、当該ノー
ドが終点ノードである場合に、コネクション単位に迂回
処理番号を管理し、後述するようにLEAF SETUP REQUEST
メッセージを送信する際に迂回処理番号を付与する。ま
た、迂回経路用のSETUPメッセージを受信した時には、
そのメッセージに付与されている迂回処理番号と格納し
ている迂回処理番号とを比較し、受信メッセージの迂回
処理番号が格納番号以上であれば、その受信メッセージ
を有効とし、受信メッセージ中の迂回処理番号に更新す
る。なお、迂回経路を形成するためにLEAF SETUP REQUE
STメッセージを送信する時には、この保持している番号
よりも大きい数を付与して送信する。
ドが終点ノードである場合に、コネクション単位に迂回
処理番号を管理し、後述するようにLEAF SETUP REQUEST
メッセージを送信する際に迂回処理番号を付与する。ま
た、迂回経路用のSETUPメッセージを受信した時には、
そのメッセージに付与されている迂回処理番号と格納し
ている迂回処理番号とを比較し、受信メッセージの迂回
処理番号が格納番号以上であれば、その受信メッセージ
を有効とし、受信メッセージ中の迂回処理番号に更新す
る。なお、迂回経路を形成するためにLEAF SETUP REQUE
STメッセージを送信する時には、この保持している番号
よりも大きい数を付与して送信する。
【００２４】切替手段１０８は、迂回経路を設定するた
めのSETUPメッセージもしくはADD PARTYメッセージにて
確保された経路と、故障が発生していない方向の経路と
を接続する。その際、メッセージ内にあるコネクション
識別子と同じ識別番号をもつコネクションとが接続する
ように制御される。
めのSETUPメッセージもしくはADD PARTYメッセージにて
確保された経路と、故障が発生していない方向の経路と
を接続する。その際、メッセージ内にあるコネクション
識別子と同じ識別番号をもつコネクションとが接続する
ように制御される。
【００２５】タイマ１０９は、障害回復のための迂回経
路処理が正常に行われいるか否かを監視するために設け
られ、後述するように、DROP PARTY/RELEASEメッセージ
を受信した時に起動し、障害回復用のSETUPメッセージ
やLEAF SETUP REQUESTメッセージが受信されたときに停
止する。
路処理が正常に行われいるか否かを監視するために設け
られ、後述するように、DROP PARTY/RELEASEメッセージ
を受信した時に起動し、障害回復用のSETUPメッセージ
やLEAF SETUP REQUESTメッセージが受信されたときに停
止する。
【００２６】図２（Ａ）は本発明が適用されるネットワ
ークの一例を示す構成図であり、図２（Ｂ）はそのピア
グループ内でのフラッディング一例を示す構成図であ
る。ここでは、説明の都合上、３つのピアグループ２５
１、２５２、２５３からなるネットワークが示されてい
る。ピアグループ（Ｐｅｅｒ Ｇｒｏｕｐ）は、ＰＮＮ
Ｉプロトコルにおける論理的な管理単位である。
ークの一例を示す構成図であり、図２（Ｂ）はそのピア
グループ内でのフラッディング一例を示す構成図であ
る。ここでは、説明の都合上、３つのピアグループ２５
１、２５２、２５３からなるネットワークが示されてい
る。ピアグループ（Ｐｅｅｒ Ｇｒｏｕｐ）は、ＰＮＮ
Ｉプロトコルにおける論理的な管理単位である。
【００２７】図２（Ａ）に示すように、ピアグループ２
５１はノード２１１〜２１６からなり、ノード２１１に
は端末２０１が接続され、ノード２１３及び２１６によ
ってそれぞれピアグループ２５３及び２５２に接続され
ている。また、ピアグループ２５２はノード２２１〜２
２６からなり、ノード２２１には端末２０３が接続さ
れ、ノード２２２及び２２３によってそれぞれピアグル
ープ２５１及び２５３に接続されている。ピアグループ
２５３も同様である。各ノードは図１に示す機能を有し
ている。
５１はノード２１１〜２１６からなり、ノード２１１に
は端末２０１が接続され、ノード２１３及び２１６によ
ってそれぞれピアグループ２５３及び２５２に接続され
ている。また、ピアグループ２５２はノード２２１〜２
２６からなり、ノード２２１には端末２０３が接続さ
れ、ノード２２２及び２２３によってそれぞれピアグル
ープ２５１及び２５３に接続されている。ピアグループ
２５３も同様である。各ノードは図１に示す機能を有し
ている。
【００２８】各ノードのルーティング機能によって、上
述したように、トポロジ情報を次々と転送して行くフラ
ッディング処理が行われ、ネットワーク内の各ノードは
すべてのノードがどのようなトポロジになっているかと
いう状況を把握することが可能となる。例えば、図２
（Ｂ）に示すようにノード２３３においてトポロジの変
化が認識された時には、その情報は先ず図中の矢印Ｔ1
で示すようにノード２３２及び２３５に通知され、続い
て矢印Ｔ2で示すようにノード２３１、２３４及び２３
６へ通知される。これによって、ピアグループ２５３の
ネットワーク内の全ノードにトポロジ情報が通知される
ことになる。
述したように、トポロジ情報を次々と転送して行くフラ
ッディング処理が行われ、ネットワーク内の各ノードは
すべてのノードがどのようなトポロジになっているかと
いう状況を把握することが可能となる。例えば、図２
（Ｂ）に示すようにノード２３３においてトポロジの変
化が認識された時には、その情報は先ず図中の矢印Ｔ1
で示すようにノード２３２及び２３５に通知され、続い
て矢印Ｔ2で示すようにノード２３１、２３４及び２３
６へ通知される。これによって、ピアグループ２５３の
ネットワーク内の全ノードにトポロジ情報が通知される
ことになる。
【００２９】また、ネットワークＬＩＪ方式について簡
単に説明するために、図２（Ａ）において端末２０１と
端末２０３及び２０４とがポイント−マルチポイント接
続されているものとする。この場合、端末２０１をルー
ト端末、そのルート端末２０１が接続されたノード２１
１を始点ノード、端末２０３及び２０４をリーフ端末、
リーフ端末２０３及び２０４がそれぞれ接続されたノー
ド２２１及び２２４を終点ノードという。
単に説明するために、図２（Ａ）において端末２０１と
端末２０３及び２０４とがポイント−マルチポイント接
続されているものとする。この場合、端末２０１をルー
ト端末、そのルート端末２０１が接続されたノード２１
１を始点ノード、端末２０３及び２０４をリーフ端末、
リーフ端末２０３及び２０４がそれぞれ接続されたノー
ド２２１及び２２４を終点ノードという。
【００３０】この状態で、他のリーフ端末（ここでは、
端末２０５）がマルチポイント接続を要求する場合に
は、当該リーフ端末２０５がその旨の要求を示すLEAF S
ETUP REQUESTメッセージを自身が接続しているノード
（ここではノード２２６）へ送信する。このノード２２
６は、上述した経路計算手段１０４によってルート端末
２０１までの経路計算を行い、その算出経路に従ってLE
AF SETUP REQUESTメッセージを送信する。このLEAF SET
UP REQUESTメッセージを受信したノードは、後述するア
ルゴリズム（図３）に従って自身が代理ルートノードで
あるか否かを判定し、代理ルートノードであれば、リー
フ端末２０５に対してSETUPメッセージもしくはADD PAR
TYメッセージを送信し、マルチポイントコネクション処
理を行う。即ち、ピアグループ２５２の１つの入口ノー
ドであるノード２２２が代理ルートノードの場合には、
リーフ端末２０５が送信したLEAF SETUP REQUESTメッセ
ージがノード２２２に到着した時、この代理ルートノー
ド２２２がリーフ端末２０５までの経路を計算し、ノー
ド２２２からリーフ端末２０５に対してコネクション設
定処理が行われる。
端末２０５）がマルチポイント接続を要求する場合に
は、当該リーフ端末２０５がその旨の要求を示すLEAF S
ETUP REQUESTメッセージを自身が接続しているノード
（ここではノード２２６）へ送信する。このノード２２
６は、上述した経路計算手段１０４によってルート端末
２０１までの経路計算を行い、その算出経路に従ってLE
AF SETUP REQUESTメッセージを送信する。このLEAF SET
UP REQUESTメッセージを受信したノードは、後述するア
ルゴリズム（図３）に従って自身が代理ルートノードで
あるか否かを判定し、代理ルートノードであれば、リー
フ端末２０５に対してSETUPメッセージもしくはADD PAR
TYメッセージを送信し、マルチポイントコネクション処
理を行う。即ち、ピアグループ２５２の１つの入口ノー
ドであるノード２２２が代理ルートノードの場合には、
リーフ端末２０５が送信したLEAF SETUP REQUESTメッセ
ージがノード２２２に到着した時、この代理ルートノー
ド２２２がリーフ端末２０５までの経路を計算し、ノー
ド２２２からリーフ端末２０５に対してコネクション設
定処理が行われる。
【００３１】具体的には、代理ルートノード２２２から
リーフ端末２０５までの経路が「ノード２２２−ノード
２２４−ノード２２６」であった場合には、ノード２２
２とノード２２４の間はすでにコネクションが設定され
ているので、ADD PARTYメッセージを送信する。ノード
２２４では分岐がおこなわれるので、このノード２２４
からノード２２６に対してはSETUPメッセージが送信さ
れ、リーフ端末２０５までのコネクション設定がなされ
る。
リーフ端末２０５までの経路が「ノード２２２−ノード
２２４−ノード２２６」であった場合には、ノード２２
２とノード２２４の間はすでにコネクションが設定され
ているので、ADD PARTYメッセージを送信する。ノード
２２４では分岐がおこなわれるので、このノード２２４
からノード２２６に対してはSETUPメッセージが送信さ
れ、リーフ端末２０５までのコネクション設定がなされ
る。
【００３２】このように、ネットワークＬＩＪ方式によ
れば、代理ルートノード２２２よりルート端末２０１に
近い方向に対してはコネクションの設定に関するメッセ
ージは送信されない。すなわち、ルート端末２０１はリ
ーフ端末２０５の管理を行う必要がないので、結果とし
てルート端末２０１の処理負荷が軽減される。ルート端
末２０１がネットワークとメッセージのやり取りを行う
のは、最初のリーフ端末２０３を接続するときのみであ
る。
れば、代理ルートノード２２２よりルート端末２０１に
近い方向に対してはコネクションの設定に関するメッセ
ージは送信されない。すなわち、ルート端末２０１はリ
ーフ端末２０５の管理を行う必要がないので、結果とし
てルート端末２０１の処理負荷が軽減される。ルート端
末２０１がネットワークとメッセージのやり取りを行う
のは、最初のリーフ端末２０３を接続するときのみであ
る。
【００３３】（迂回経路切替時のノード動作）上述した
ポイント−マルチポイント接続技術を利用したネットワ
ークＬＩＪ方式において、本発明による障害回復システ
ムは障害発生時の経路切替を可能にするものである。後
述するように、図１に示す各ノードの機能を用いて、代
理ルートノードと終点ノードとが経路切り替えの両端の
ノードとなり障害発生箇所を通らない迂回経路あるいは
代替経路に切り替える。以下、代理ルートノード判定、
LEAF SETUP REQUESTメッセージ受信処理、SETUP/ADD PA
RTYメッセージ受信処理、及びRELEASE/DROP PARTYメッ
セージ受信処理について詳細に説明する。なお、障害が
発生したリンクに接続されているノードは、障害発生を
検出すると、障害発生時のDROP PARTY/RELEASEメッセー
ジを送信し、このメッセージを受信したノードはタイマ
１０９を起動するものとする。
ポイント−マルチポイント接続技術を利用したネットワ
ークＬＩＪ方式において、本発明による障害回復システ
ムは障害発生時の経路切替を可能にするものである。後
述するように、図１に示す各ノードの機能を用いて、代
理ルートノードと終点ノードとが経路切り替えの両端の
ノードとなり障害発生箇所を通らない迂回経路あるいは
代替経路に切り替える。以下、代理ルートノード判定、
LEAF SETUP REQUESTメッセージ受信処理、SETUP/ADD PA
RTYメッセージ受信処理、及びRELEASE/DROP PARTYメッ
セージ受信処理について詳細に説明する。なお、障害が
発生したリンクに接続されているノードは、障害発生を
検出すると、障害発生時のDROP PARTY/RELEASEメッセー
ジを送信し、このメッセージを受信したノードはタイマ
１０９を起動するものとする。
【００３４】（代理ルートノード判定）図３は、本実施
形態における各ノードの代理ルートノード判定手順を示
すフローチャートである。各ノードにおいて、LEAF SET
UP REQUESTメッセージあるいはRELEASE/DROP PARTYメッ
セージを受信した場合、自ノードが代理ルートノードで
あるか否かを次のように判定する。まず、自ノードが始
点ノードであるかどうかを判断し（ステップＳ３０
１）、始点ノードである場合には代理ルートノードであ
ると判定する（ステップＳ３０２）。始点ノードでない
場合は、終点ノードでかつ該当するマルチポイントコネ
クションが自ノードを通過しているかどうかを判断する
（ステップＳ３０３）。ステップＳ３０３の条件を満た
せば、代理ルートノードである（Ｓ３０２）。ステップ
Ｓ３０３の条件を満たさない場合には、更に、該当する
マルチポイントのコネクションにおいて、自分の属する
ピアグループ内で最初のノード（入口ノード）であるか
どうかを判断する（ステップＳ３０４）。
形態における各ノードの代理ルートノード判定手順を示
すフローチャートである。各ノードにおいて、LEAF SET
UP REQUESTメッセージあるいはRELEASE/DROP PARTYメッ
セージを受信した場合、自ノードが代理ルートノードで
あるか否かを次のように判定する。まず、自ノードが始
点ノードであるかどうかを判断し（ステップＳ３０
１）、始点ノードである場合には代理ルートノードであ
ると判定する（ステップＳ３０２）。始点ノードでない
場合は、終点ノードでかつ該当するマルチポイントコネ
クションが自ノードを通過しているかどうかを判断する
（ステップＳ３０３）。ステップＳ３０３の条件を満た
せば、代理ルートノードである（Ｓ３０２）。ステップ
Ｓ３０３の条件を満たさない場合には、更に、該当する
マルチポイントのコネクションにおいて、自分の属する
ピアグループ内で最初のノード（入口ノード）であるか
どうかを判断する（ステップＳ３０４）。
【００３５】ステップＳ３０４の条件を満たす場合に
は、更に、このコネクションを自分の属するピアグルー
プ内で分岐する必要があるかどうかを判断する（ステッ
プＳ３０５）。ステップＳ３０５の条件を満たす場合に
は、代理ルートノードと判断する（ステップＳ３０
２）。ステップＳ３０４又はＳ３０５の条件を満たさな
い場合には、代理ルートノードではないと判定される
（ステップＳ３０６）。例えば、図２（Ａ）において、
リーフ端末２０５が接続要求した場合には、ピアグルー
プ２５２の入口ノードであるノード２２２が代理ルート
ノードとなる。
は、更に、このコネクションを自分の属するピアグルー
プ内で分岐する必要があるかどうかを判断する（ステッ
プＳ３０５）。ステップＳ３０５の条件を満たす場合に
は、代理ルートノードと判断する（ステップＳ３０
２）。ステップＳ３０４又はＳ３０５の条件を満たさな
い場合には、代理ルートノードではないと判定される
（ステップＳ３０６）。例えば、図２（Ａ）において、
リーフ端末２０５が接続要求した場合には、ピアグルー
プ２５２の入口ノードであるノード２２２が代理ルート
ノードとなる。
【００３６】（マルチポイントコネクション設定）次
に、各ノードのシグナリング手段１０２によって実行さ
れる第１の処理であるコネクションの設定について更に
詳細に説明する。
に、各ノードのシグナリング手段１０２によって実行さ
れる第１の処理であるコネクションの設定について更に
詳細に説明する。
【００３７】図４は、本実施形態における各ノードのLE
AF SETUP REQUEST メッセージ受信処理を示すフローチ
ャートである。各ノードにおいて、LEAF SETUP REQUEST
メッセージを受信した場合の処理は、当該ノードのネ
ットワークにおける役割（終点ノード、代理ルートノー
ドなど）によって異なる。
AF SETUP REQUEST メッセージ受信処理を示すフローチ
ャートである。各ノードにおいて、LEAF SETUP REQUEST
メッセージを受信した場合の処理は、当該ノードのネ
ットワークにおける役割（終点ノード、代理ルートノー
ドなど）によって異なる。
【００３８】図４において、リーフ端末からLEAF SETUP
REQUEST メッセージを受信したノードは、自ノードが
当該リーフ端末の終点ノードであるか否かを判定し（ス
テップＳ４０１）、終点端末である場合には、そのメッ
セージの内容をメッセージ情報データベース１０６に保
持しておく（ステップＳ４０２）。続いて、自ノードが
代理ルートノードであるか否かを判断し（ステップＳ４
０３）、代理ルートノードであれば、リーフ端末に対し
てコネクション接続を行い（ステップＳ４０４）、SETU
Pメッセージを送信する（ステップ４０５）。
REQUEST メッセージを受信したノードは、自ノードが
当該リーフ端末の終点ノードであるか否かを判定し（ス
テップＳ４０１）、終点端末である場合には、そのメッ
セージの内容をメッセージ情報データベース１０６に保
持しておく（ステップＳ４０２）。続いて、自ノードが
代理ルートノードであるか否かを判断し（ステップＳ４
０３）、代理ルートノードであれば、リーフ端末に対し
てコネクション接続を行い（ステップＳ４０４）、SETU
Pメッセージを送信する（ステップ４０５）。
【００３９】自ノードが代理ルートノードではないと判
断した場合には（ステップＳ４０３のＮＯ）、シグナリ
ング手段１０２はルート端末までの経路計算が必要な旨
を経路計算手段１０３に通知し、経路計算手段１０３は
受信メッセージの内容とトポロジ情報とに基づいて経路
を計算し、経路情報データベース１０５に格納する（ス
テップＳ４０６）。シグナリング手段１０２は、この算
出経路に基づいて、次の送信先である隣接ノードに対
し、LEAF SETUP REQUESTメッセージを送信する（ステッ
プＳ４０７）。その際、後で迂回経路用SETUPメッセー
ジを複数受信した場合に備えて、どれを選択したらよい
かを判断するための迂回処理番号とネットワーク内で一
意に識別できるコネクション識別子をLEAF SETUP REQUE
STメッセージに付与して送信する。なお、この迂回処理
番号は、コネクション単位で迂回処理番号管理手段１０
７にて管理される。
断した場合には（ステップＳ４０３のＮＯ）、シグナリ
ング手段１０２はルート端末までの経路計算が必要な旨
を経路計算手段１０３に通知し、経路計算手段１０３は
受信メッセージの内容とトポロジ情報とに基づいて経路
を計算し、経路情報データベース１０５に格納する（ス
テップＳ４０６）。シグナリング手段１０２は、この算
出経路に基づいて、次の送信先である隣接ノードに対
し、LEAF SETUP REQUESTメッセージを送信する（ステッ
プＳ４０７）。その際、後で迂回経路用SETUPメッセー
ジを複数受信した場合に備えて、どれを選択したらよい
かを判断するための迂回処理番号とネットワーク内で一
意に識別できるコネクション識別子をLEAF SETUP REQUE
STメッセージに付与して送信する。なお、この迂回処理
番号は、コネクション単位で迂回処理番号管理手段１０
７にて管理される。
【００４０】終点ノード以外のノードである場合には
（ステップＳ４０１のＮＯ）、自ノードが代理ルートノ
ードであるか否かを判断する（ステップＳ４０８）。代
理ルートノードではないと判断した場合には（ステップ
Ｓ４０８のＮＯ）、ルート端末方向に対してLEAF SETUP
REQUESTメッセージを送信する（ステップＳ４０７）。
（ステップＳ４０１のＮＯ）、自ノードが代理ルートノ
ードであるか否かを判断する（ステップＳ４０８）。代
理ルートノードではないと判断した場合には（ステップ
Ｓ４０８のＮＯ）、ルート端末方向に対してLEAF SETUP
REQUESTメッセージを送信する（ステップＳ４０７）。
【００４１】自ノードが代理ルートノードである場合に
は（ステップＳ４０８のＹＥＳ）、先にDROP PARTY/REL
EASEメッセージを受信していてタイマ１０９を起動して
いる場合にはタイマ１０９を停止し（ステップＳ４０
９）、そのメッセージに付与されている迂回処理番号と
コネクション識別子を保持する（ステップＳ４１０）。
そして、要求のあったリーフ端末まで経路計算が必要な
旨を経路計算手段１０３に通知して経路情報を得る（ス
テップＳ４１１）。
は（ステップＳ４０８のＹＥＳ）、先にDROP PARTY/REL
EASEメッセージを受信していてタイマ１０９を起動して
いる場合にはタイマ１０９を停止し（ステップＳ４０
９）、そのメッセージに付与されている迂回処理番号と
コネクション識別子を保持する（ステップＳ４１０）。
そして、要求のあったリーフ端末まで経路計算が必要な
旨を経路計算手段１０３に通知して経路情報を得る（ス
テップＳ４１１）。
【００４２】続いて、算出された経路情報に従い、自ノ
ードがこのコネクションのために新規に分岐する必要が
あるかどうかを判断し（ステップＳ４１２）、分岐する
必要がある場合には、リーフ端末に対してコネクション
を設定し（ステップＳ４１３）、SETUPメッセージを送
信する（ステップＳ４１４）。自ノードが新規に分岐す
る必要がない場合には（ステップＳ４１２のＮＯ）、隣
接ノードへADD PARTYメッセージを送信する（ステップ
Ｓ４１５）。
ードがこのコネクションのために新規に分岐する必要が
あるかどうかを判断し（ステップＳ４１２）、分岐する
必要がある場合には、リーフ端末に対してコネクション
を設定し（ステップＳ４１３）、SETUPメッセージを送
信する（ステップＳ４１４）。自ノードが新規に分岐す
る必要がない場合には（ステップＳ４１２のＮＯ）、隣
接ノードへADD PARTYメッセージを送信する（ステップ
Ｓ４１５）。
【００４３】なお、このSETUPメッセージもしくはADD P
ARTYメッセージによるコネクション設定が失敗した場合
には、再度別経路を計算して、コネクション設定のため
にメッセージを送信してもよい。この時には、迂回処理
番号管理手段１０７にて、前回送信した迂回処理番号よ
りも数の大きい番号を付与する。なお、終点ノードにお
いて代理ルートノードとなる場合には、迂回処理番号お
よびコネクション識別子の保持及び経路計算を行う必要
はない。
ARTYメッセージによるコネクション設定が失敗した場合
には、再度別経路を計算して、コネクション設定のため
にメッセージを送信してもよい。この時には、迂回処理
番号管理手段１０７にて、前回送信した迂回処理番号よ
りも数の大きい番号を付与する。なお、終点ノードにお
いて代理ルートノードとなる場合には、迂回処理番号お
よびコネクション識別子の保持及び経路計算を行う必要
はない。
【００４４】図５は、本実施形態における各ノードのSE
TUP/ADD PARTYメッセージ受信処理を示すフローチャー
トである。上述したSETUPメッセージやADD PARTYメッセ
ージを受信したノードにおいて行われる処理は、前述し
たように、各ノードのネットワークにおける役割（終点
ノード、代理ルートノードなど）によって異なる。
TUP/ADD PARTYメッセージ受信処理を示すフローチャー
トである。上述したSETUPメッセージやADD PARTYメッセ
ージを受信したノードにおいて行われる処理は、前述し
たように、各ノードのネットワークにおける役割（終点
ノード、代理ルートノードなど）によって異なる。
【００４５】各ノードにおいて、SETUP又はADD PARTY
メッセージを受信すると、先ず自ノードが終点ノードで
あるか否かを判断する（ステップＳ５０１）。終点ノー
ドの場合には、この受信メッセージが迂回経路用のSETU
P/ADD PARTYメッセージであるかどうかを判断する（ス
テップＳ５０２）。
メッセージを受信すると、先ず自ノードが終点ノードで
あるか否かを判断する（ステップＳ５０１）。終点ノー
ドの場合には、この受信メッセージが迂回経路用のSETU
P/ADD PARTYメッセージであるかどうかを判断する（ス
テップＳ５０２）。
【００４６】迂回経路用のSETUP/ADD PARTYメッセージ
である場合には（ステップＳ５０２のＹＥＳ）、受信メ
ッセージの迂回処理番号が自ノードで管理している迂回
処理番号以上であるか否かを判定し（ステップＳ５０
３）、受信した迂回処理番号が管理されている番号以上
であれば、その受信メッセージを有効とし、その受信し
た迂回処理番号を迂回処理番号管理手段１０６にて新た
に管理する（ステップＳ５０４）。逆に、受信した迂回
処理番号が管理されている番号未満であれば、その受信
メッセージを破棄する（ステップＳ５０５）。以下同様
に、迂回処理番号を持ったSETUP/ADD PARTYメッセージ
を受信する毎に、管理番号の更新（Ｓ５０４）あるい
は、受信メッセージの廃棄（Ｓ５０５）が行われる。同
時に、迂回経路用のSETUP/ADD PARTYメッセージである
場合には（ステップＳ５０２のＹＥＳ）、起動している
タイマ１０９を停止し（ステップＳ５０６）、シグナリ
ング手段１０２は経路切替を行う旨を切替手段１０８に
通知し、代替経路の切り替えを行う（ステップＳ５０
７）。
である場合には（ステップＳ５０２のＹＥＳ）、受信メ
ッセージの迂回処理番号が自ノードで管理している迂回
処理番号以上であるか否かを判定し（ステップＳ５０
３）、受信した迂回処理番号が管理されている番号以上
であれば、その受信メッセージを有効とし、その受信し
た迂回処理番号を迂回処理番号管理手段１０６にて新た
に管理する（ステップＳ５０４）。逆に、受信した迂回
処理番号が管理されている番号未満であれば、その受信
メッセージを破棄する（ステップＳ５０５）。以下同様
に、迂回処理番号を持ったSETUP/ADD PARTYメッセージ
を受信する毎に、管理番号の更新（Ｓ５０４）あるい
は、受信メッセージの廃棄（Ｓ５０５）が行われる。同
時に、迂回経路用のSETUP/ADD PARTYメッセージである
場合には（ステップＳ５０２のＹＥＳ）、起動している
タイマ１０９を停止し（ステップＳ５０６）、シグナリ
ング手段１０２は経路切替を行う旨を切替手段１０８に
通知し、代替経路の切り替えを行う（ステップＳ５０
７）。
【００４７】他方、迂回経路用でないSETUP/ADD PARTY
メッセージすなわち初期に接続するためのSETUP/ADD PA
RTYメッセージの場合には（ステップＳ５０２のＮ
Ｏ）、マルチポイント接続の要求をしたリーフ端末に対
してコネクション設定を行い（ステップＳ５０８）、SE
TUPメッセージを送信する（ステップＳ５０９）。な
お、図５には示されていないが、コネクション設定（ス
テップＳ５０８）時には、CONNECT/ADD PARTY ACKNOWLE
DGEメッセージがルート端末もしくは代理ルートノード
に送信され、コネクション設定の処理が完了する。
メッセージすなわち初期に接続するためのSETUP/ADD PA
RTYメッセージの場合には（ステップＳ５０２のＮ
Ｏ）、マルチポイント接続の要求をしたリーフ端末に対
してコネクション設定を行い（ステップＳ５０８）、SE
TUPメッセージを送信する（ステップＳ５０９）。な
お、図５には示されていないが、コネクション設定（ス
テップＳ５０８）時には、CONNECT/ADD PARTY ACKNOWLE
DGEメッセージがルート端末もしくは代理ルートノード
に送信され、コネクション設定の処理が完了する。
【００４８】自ノードが終点ノード以外である場合には
（ステップＳ５０１のＮＯ）、受信メッセージがSETUP
メッセージである否かかが判定され（ステップＳ５１
０）、SETUPメッセージであれば、コネクション設定を
行い（ステップＳ５１１）、当該SETUPメッセージ内の
経路情報に基づき次のノードもしくはリーフ端末に対し
てSETUPメッセージを送信する（ステップＳ５１２）。
（ステップＳ５０１のＮＯ）、受信メッセージがSETUP
メッセージである否かかが判定され（ステップＳ５１
０）、SETUPメッセージであれば、コネクション設定を
行い（ステップＳ５１１）、当該SETUPメッセージ内の
経路情報に基づき次のノードもしくはリーフ端末に対し
てSETUPメッセージを送信する（ステップＳ５１２）。
【００４９】他方、SETUPメッセージでない場合、即ちA
DD PARTYメッセージである場合には（ステップＳ５１０
のＮＯ）、このコネクションに関して新規に分岐する必
要があるかどうかを判断し（ステップＳ５１３）、新規
に分岐する必要ある場合には、SETUPメッセージ受信時
の処理と同じく、コネクション設定（Ｓ５１１）及びSE
TUPメッセージ送信（Ｓ５１２）が行われる。新規に分
岐する必要がない場合には（ステップＳ５１３のＮ
Ｏ）、ADD PARTYメッセージを送信する（ステップＳ５
１４）。
DD PARTYメッセージである場合には（ステップＳ５１０
のＮＯ）、このコネクションに関して新規に分岐する必
要があるかどうかを判断し（ステップＳ５１３）、新規
に分岐する必要ある場合には、SETUPメッセージ受信時
の処理と同じく、コネクション設定（Ｓ５１１）及びSE
TUPメッセージ送信（Ｓ５１２）が行われる。新規に分
岐する必要がない場合には（ステップＳ５１３のＮ
Ｏ）、ADD PARTYメッセージを送信する（ステップＳ５
１４）。
【００５０】（マルチポイントコネクション切断）次
に、各ノードのシグナリング手段１０２によって実行さ
れるコネクションの切断について更に詳細に説明する。
に、各ノードのシグナリング手段１０２によって実行さ
れるコネクションの切断について更に詳細に説明する。
【００５１】図６は、本実施形態における各ノードのRE
LEASE/DROP PARTY メッセージ受信処理を示すフローチ
ャートである。RELEASE/DROP PARTY メッセージを受信
すると、先ずシグナリング手段１０２はそのメッセージ
がルート端末側から受信したか否かを判断する（ステッ
プＳ６０１）。ルート端末側からの受信であれば（ステ
ップＳ６０１のＹＥＳ）、続いて、自ノードが当該受信
メッセージの宛先端末の終点ノードであるか否かを判断
する（ステップＳ６０２）。終点ノードであれば、更に
当該受信メッセージがネットワーク障害に起因するもの
か否かを判断する（ステップＳ６０３）。
LEASE/DROP PARTY メッセージ受信処理を示すフローチ
ャートである。RELEASE/DROP PARTY メッセージを受信
すると、先ずシグナリング手段１０２はそのメッセージ
がルート端末側から受信したか否かを判断する（ステッ
プＳ６０１）。ルート端末側からの受信であれば（ステ
ップＳ６０１のＹＥＳ）、続いて、自ノードが当該受信
メッセージの宛先端末の終点ノードであるか否かを判断
する（ステップＳ６０２）。終点ノードであれば、更に
当該受信メッセージがネットワーク障害に起因するもの
か否かを判断する（ステップＳ６０３）。
【００５２】自ノードが終点ノードでない場合、あるい
は終点ノードであっても受信メッセージがネットワーク
障害によるものではない場合には（ステップＳ６０２の
ＮＯ、Ｓ６０３のＮＯ）、受信メッセージがRELEASEメ
ッセージであるか否かを判断する（ステップＳ６０
４）。RELEASEメッセージであれば、それをリーフ端末
側へ送信し（ステップＳ６０５）、コネクションを切断
する（ステップＳ６０６）。従って、ルート端末から経
路切断要求に関するメッセージを受信した場合、すなわ
ち、ネットワーク障害に起因するメッセージではない場
合、すべてのノードにおいては、RELEASEメッセージを
リーフ端末方向へ送信し、コネクション切断を行う。
は終点ノードであっても受信メッセージがネットワーク
障害によるものではない場合には（ステップＳ６０２の
ＮＯ、Ｓ６０３のＮＯ）、受信メッセージがRELEASEメ
ッセージであるか否かを判断する（ステップＳ６０
４）。RELEASEメッセージであれば、それをリーフ端末
側へ送信し（ステップＳ６０５）、コネクションを切断
する（ステップＳ６０６）。従って、ルート端末から経
路切断要求に関するメッセージを受信した場合、すなわ
ち、ネットワーク障害に起因するメッセージではない場
合、すべてのノードにおいては、RELEASEメッセージを
リーフ端末方向へ送信し、コネクション切断を行う。
【００５３】受信メッセージがRELEASEメッセージでな
い場合、即ちDROP PARTYメッセージの場合には（ステッ
プＳ６０４のＮＯ）、自ノードで分岐が行われ、かつ、
枝となっているこのコネクションの経路には当該コネク
ションしか存在しないどうかを判断し（ステップＳ６０
７）、この条件を満足する場合は、RELEASEメッセージ
をリーフ端末側へ送信し（ステップＳ６０５）、コネク
ションを切断する（ステップＳ６０６）。満足しない場
合には（ステップＳ６０７のＮＯ）、リーフ端末方向へ
DROP PARTYメッセージを送信する（ステップＳ６０
８）。
い場合、即ちDROP PARTYメッセージの場合には（ステッ
プＳ６０４のＮＯ）、自ノードで分岐が行われ、かつ、
枝となっているこのコネクションの経路には当該コネク
ションしか存在しないどうかを判断し（ステップＳ６０
７）、この条件を満足する場合は、RELEASEメッセージ
をリーフ端末側へ送信し（ステップＳ６０５）、コネク
ションを切断する（ステップＳ６０６）。満足しない場
合には（ステップＳ６０７のＮＯ）、リーフ端末方向へ
DROP PARTYメッセージを送信する（ステップＳ６０
８）。
【００５４】自ノードが終点ノードで、且つルート端末
側にてコネクションに影響のあるネットワーク障害を検
出するか又はネットワーク障害を示すRELEASE/DROP PAR
TYメッセージを受信した場合には（ステップＳ６０３の
ＹＥＳ）、リーフ端末側のコネクションを維持し（ステ
ップＳ６０９）、タイマ１０９を起動し（ステップＳ６
１０）、LEAF SETUP REQUESTメッセージを再度ルート端
末方向へ送信する（ステップＳ６１１）。その際、最初
に送信したときと同じ情報をメッセージ情報データベー
ス１０６より読み出して付与するが、唯一、迂回処理番
号は迂回処理番号管理手段１０７にて管理している番号
より大きいものを付与して送信する。その後、ルート端
末側のノードから迂回経路設定用のSETUPメッセージも
しくはADDPARTYメッセージの受信を待つ。この迂回経路
設定用のSETUP/ADD PARTYメッセージを受信した時の処
理は、図５で説明した通りである。
側にてコネクションに影響のあるネットワーク障害を検
出するか又はネットワーク障害を示すRELEASE/DROP PAR
TYメッセージを受信した場合には（ステップＳ６０３の
ＹＥＳ）、リーフ端末側のコネクションを維持し（ステ
ップＳ６０９）、タイマ１０９を起動し（ステップＳ６
１０）、LEAF SETUP REQUESTメッセージを再度ルート端
末方向へ送信する（ステップＳ６１１）。その際、最初
に送信したときと同じ情報をメッセージ情報データベー
ス１０６より読み出して付与するが、唯一、迂回処理番
号は迂回処理番号管理手段１０７にて管理している番号
より大きいものを付与して送信する。その後、ルート端
末側のノードから迂回経路設定用のSETUPメッセージも
しくはADDPARTYメッセージの受信を待つ。この迂回経路
設定用のSETUP/ADD PARTYメッセージを受信した時の処
理は、図５で説明した通りである。
【００５５】一方、受信したRELEASE/DROP PARTY メッ
セージがルート端末側からではなくリーフ端末側からの
受信であれば（ステップＳ６０１のＮＯ）、続いて、自
ノードが代理ルートノード又は始点ノードであるか否か
を判断する（ステップＳ６１２）。代理ルートノードあ
るいは始点ノードであれば、更に当該受信メッセージが
ネットワーク障害に起因するものか否かを判断する（ス
テップＳ６１３）。
セージがルート端末側からではなくリーフ端末側からの
受信であれば（ステップＳ６０１のＮＯ）、続いて、自
ノードが代理ルートノード又は始点ノードであるか否か
を判断する（ステップＳ６１２）。代理ルートノードあ
るいは始点ノードであれば、更に当該受信メッセージが
ネットワーク障害に起因するものか否かを判断する（ス
テップＳ６１３）。
【００５６】自ノードが代理ルートノードでも始点ノー
ドでもなく、あるいは代理ルートノード又は始点ノード
であっても受信メッセージがネットワーク障害によるも
のではない場合には（ステップＳ６１２のＮＯ、Ｓ６１
３のＮＯ）、受信メッセージがDROP PARTYメッセージで
あるか否かを判断する（ステップＳ６１４）。DROP PAR
TYメッセージであれば、それをリーフ端末側へ送信する
（ステップＳ６１５）。受信メッセージがDROP PARTYメ
ッセージでない場合、即ちRELEASEメッセージである場
合には（ステップＳ６１４のＮＯ）、更に自ノードで分
岐処理が行われているか否かが判断される（ステップＳ
６１６）。自ノードが分岐ノードであれば、ルート端末
方向へDROP PARTYメッセージを送信し（ステップＳ６１
７）、その後リーフ端末側のコネクションの切断を行う
（ステップＳ６１８）。また、自ノードが分岐していな
い場合には（ステップＳ６１６のＮＯ）、ルート端末方
向へRELEASEメッセージを送信し（ステップＳ６１
９）、コネクションの切断を行う（Ｓ６１８）。
ドでもなく、あるいは代理ルートノード又は始点ノード
であっても受信メッセージがネットワーク障害によるも
のではない場合には（ステップＳ６１２のＮＯ、Ｓ６１
３のＮＯ）、受信メッセージがDROP PARTYメッセージで
あるか否かを判断する（ステップＳ６１４）。DROP PAR
TYメッセージであれば、それをリーフ端末側へ送信する
（ステップＳ６１５）。受信メッセージがDROP PARTYメ
ッセージでない場合、即ちRELEASEメッセージである場
合には（ステップＳ６１４のＮＯ）、更に自ノードで分
岐処理が行われているか否かが判断される（ステップＳ
６１６）。自ノードが分岐ノードであれば、ルート端末
方向へDROP PARTYメッセージを送信し（ステップＳ６１
７）、その後リーフ端末側のコネクションの切断を行う
（ステップＳ６１８）。また、自ノードが分岐していな
い場合には（ステップＳ６１６のＮＯ）、ルート端末方
向へRELEASEメッセージを送信し（ステップＳ６１
９）、コネクションの切断を行う（Ｓ６１８）。
【００５７】自ノードが代理ルートノード又は始点ノー
ドで、且つリーフ端末側にてコネクションに影響のある
ネットワーク障害を検出するか又はネットワーク障害を
示すRELEASE/DROP PARTYメッセージを受信した場合には
（ステップＳ６１３のＹＥＳ）、ルート端末方向のコネ
クションを維持し（ステップＳ６２０）、タイマ１０９
を起動し（ステップＳ６２１）、終点ノードからの再接
続要求であるLEAF SETUP REQUESTメッセージが到着する
のを待つ。これ以外の条件で、切断に関するメッセージ
を受信したときは、端末からの切断処理と同じになる。
ドで、且つリーフ端末側にてコネクションに影響のある
ネットワーク障害を検出するか又はネットワーク障害を
示すRELEASE/DROP PARTYメッセージを受信した場合には
（ステップＳ６１３のＹＥＳ）、ルート端末方向のコネ
クションを維持し（ステップＳ６２０）、タイマ１０９
を起動し（ステップＳ６２１）、終点ノードからの再接
続要求であるLEAF SETUP REQUESTメッセージが到着する
のを待つ。これ以外の条件で、切断に関するメッセージ
を受信したときは、端末からの切断処理と同じになる。
【００５８】（迂回経路の具体例１）図７は、マルチポ
イントコネクションに対し障害が発生したときに、障害
を迂回する代替経路の第１例を示す説明図である。ノー
ド２１１に接続されている端末２０１がルート端末であ
り、ノード２２１に接続している端末２０３とノード２
２４に接続している端末２０４とノード２２６に接続し
ている端末２０５がリーフ端末として、すでにマルチポ
イントコネクションが設定されている。リーフ端末２０
３のみルート端末２０１から接続される。すなわち、リ
ーフ端末２０３において、ノード２１１は代理ルートノ
ードとなる。また、ノード２２２は端末２０４と端末２
０５の代理ルートノードであるとする。すなわち、これ
らのリーフ端末は、ノード２２２より管理接続されてい
る構成となっている。
イントコネクションに対し障害が発生したときに、障害
を迂回する代替経路の第１例を示す説明図である。ノー
ド２１１に接続されている端末２０１がルート端末であ
り、ノード２２１に接続している端末２０３とノード２
２４に接続している端末２０４とノード２２６に接続し
ている端末２０５がリーフ端末として、すでにマルチポ
イントコネクションが設定されている。リーフ端末２０
３のみルート端末２０１から接続される。すなわち、リ
ーフ端末２０３において、ノード２１１は代理ルートノ
ードとなる。また、ノード２２２は端末２０４と端末２
０５の代理ルートノードであるとする。すなわち、これ
らのリーフ端末は、ノード２２２より管理接続されてい
る構成となっている。
【００５９】ここで、ノード２２４とノード２２６との
リンクに障害７０１が発生した場合、代理ルートノード
２２２と終点ノード２２６との間で経路切り換えが実行
され、ノード２２５を経由した代替経路７０２が形成さ
れる。以下、経路切替の詳細を説明する。
リンクに障害７０１が発生した場合、代理ルートノード
２２２と終点ノード２２６との間で経路切り換えが実行
され、ノード２２５を経由した代替経路７０２が形成さ
れる。以下、経路切替の詳細を説明する。
【００６０】図８は、図７の経路切替動作を示すシーケ
ンス図である。ノード２２４とノード２２６とのリンク
に障害７０１が発生した場合、最初にノード２２４とノ
ード２２６が障害発生を認識する（ステップＳ８０１、
Ｓ８０２）。ノード２２６は終点ノードであるから、リ
ーフ端末２０５のコネクションは維持しつつ、タイマを
起動し（ステップＳ８０３）、メッセージ情報データベ
ース１０６に従って迂回処理番号のみ変更されたLEAF S
ETUP REQUESTメッセージを作成する。
ンス図である。ノード２２４とノード２２６とのリンク
に障害７０１が発生した場合、最初にノード２２４とノ
ード２２６が障害発生を認識する（ステップＳ８０１、
Ｓ８０２）。ノード２２６は終点ノードであるから、リ
ーフ端末２０５のコネクションは維持しつつ、タイマを
起動し（ステップＳ８０３）、メッセージ情報データベ
ース１０６に従って迂回処理番号のみ変更されたLEAF S
ETUP REQUESTメッセージを作成する。
【００６１】一方、ノード２２４は、リーフ端末側の障
害で、代理ルートノードではなく、また、このノードに
は端末２０４のコネクションが存在することから、ルー
ト端末方向すなわちノード２２２に対してDROP PARTYメ
ッセージを送信する。
害で、代理ルートノードではなく、また、このノードに
は端末２０４のコネクションが存在することから、ルー
ト端末方向すなわちノード２２２に対してDROP PARTYメ
ッセージを送信する。
【００６２】リーフ端末側からネットワーク障害による
DROP PARTYメッセージを受信したノード２２２は、代理
ルートノードであるから、図６のステップＳ６２０及び
Ｓ６２１に示すように、このコネクションを維持しつ
つ、タイマを起動する（ステップＳ８０４）。そして、
終点ノードからのLEAF SETUP REQUESTメッセージの到着
を待つ。終点ノード２２６からLEAF SETUP REQUESTメッ
セージを受信すると、シグナリング手段１０２はタイマ
１０９を停止させ、LEAF SETUP REQUESTメッセージに付
与されているコネクション識別子と迂回処理番号を保持
した後、その終点ノード２２６までの迂回経路の計算を
行う（ステップＳ８０５：図４のステップＳ４０９〜Ｓ
４１１を参照）。
DROP PARTYメッセージを受信したノード２２２は、代理
ルートノードであるから、図６のステップＳ６２０及び
Ｓ６２１に示すように、このコネクションを維持しつ
つ、タイマを起動する（ステップＳ８０４）。そして、
終点ノードからのLEAF SETUP REQUESTメッセージの到着
を待つ。終点ノード２２６からLEAF SETUP REQUESTメッ
セージを受信すると、シグナリング手段１０２はタイマ
１０９を停止させ、LEAF SETUP REQUESTメッセージに付
与されているコネクション識別子と迂回処理番号を保持
した後、その終点ノード２２６までの迂回経路の計算を
行う（ステップＳ８０５：図４のステップＳ４０９〜Ｓ
４１１を参照）。
【００６３】迂回経路の計算結果が、〔ノード２２２−
ノード２２５−ノード２２６〕になったとすると、ノー
ド２２２のシグナリング手段１０２は、保持したコネク
ション識別子と迂回処理番号とを迂回経路用のSETUPメ
ッセージに付与して隣接のノード２２５へ送信する（図
４のステップＳ４１２〜Ｓ４１４を参照）。ノード２２
５では、この迂回経路用のSETUPメッセージを受信した
場合、コネクション接続の設定を行い、さらに隣接のノ
ード２２６へ迂回経路用のSETUPメッセージを送信する
（図５のステップＳ５１０〜Ｓ５１２を参照）。
ノード２２５−ノード２２６〕になったとすると、ノー
ド２２２のシグナリング手段１０２は、保持したコネク
ション識別子と迂回処理番号とを迂回経路用のSETUPメ
ッセージに付与して隣接のノード２２５へ送信する（図
４のステップＳ４１２〜Ｓ４１４を参照）。ノード２２
５では、この迂回経路用のSETUPメッセージを受信した
場合、コネクション接続の設定を行い、さらに隣接のノ
ード２２６へ迂回経路用のSETUPメッセージを送信する
（図５のステップＳ５１０〜Ｓ５１２を参照）。
【００６４】終点ノード２２６は、同じコネクション識
別子および管理している番号以上の迂回処理番号のメッ
セージを受信したことにより、タイマを停止し、リーフ
端末２０５側のコネクションと接続して切替えを行う
（ステップＳ８０６：図５のステップＳ５０２〜Ｓ５０
７を参照）。その後、同じ経路をルート端末方向へCONN
ECTメッセージを送信し、代理ルートノード２２２の切
り替え処理（ステップＳ８０７）によって、この迂回経
路と維持しておいたコネクションとを接続することによ
り迂回処理が完了する。
別子および管理している番号以上の迂回処理番号のメッ
セージを受信したことにより、タイマを停止し、リーフ
端末２０５側のコネクションと接続して切替えを行う
（ステップＳ８０６：図５のステップＳ５０２〜Ｓ５０
７を参照）。その後、同じ経路をルート端末方向へCONN
ECTメッセージを送信し、代理ルートノード２２２の切
り替え処理（ステップＳ８０７）によって、この迂回経
路と維持しておいたコネクションとを接続することによ
り迂回処理が完了する。
【００６５】（迂回経路の具体例２）図９は、マルチポ
イントコネクションに対し障害が発生したときに、代理
ルートノードにて障害を迂回した代替経路の第２例を示
す説明図である。ここでは、ピアグループ２５１のノー
ド２１６とピアグループ２５２のノード２２２とのリン
クに障害９０１が発生し、ピアグループ２５３を経由す
る迂回経路９０２が形成される場合を説明する。すなわ
ち、リーフ端末２０４及びリーフ端末２０５の代理ルー
トノードよりルート端末側にて障害が発生したときに、
どのように復旧されるかを示す。
イントコネクションに対し障害が発生したときに、代理
ルートノードにて障害を迂回した代替経路の第２例を示
す説明図である。ここでは、ピアグループ２５１のノー
ド２１６とピアグループ２５２のノード２２２とのリン
クに障害９０１が発生し、ピアグループ２５３を経由す
る迂回経路９０２が形成される場合を説明する。すなわ
ち、リーフ端末２０４及びリーフ端末２０５の代理ルー
トノードよりルート端末側にて障害が発生したときに、
どのように復旧されるかを示す。
【００６６】図１０は、図９の経路切替動作を示すシー
ケンス図である。ノード２１６とノード２２２とのリン
クに障害９０１が発生すると、最初にノード２１６及び
２２２で障害が検出される（ステップＳ１００１、Ｓ１
００２）。ノード２２２では、障害によりコネクション
が利用できなくなるので代理ルートノードではなくなる
ので、コネクションの存在するすべてのリーフ端末の方
向に対して、障害によるRELEASEメッセージを送信し、
最終的には、終点ノード２２１、２２４及び２２６にそ
れぞれ通知される。
ケンス図である。ノード２１６とノード２２２とのリン
クに障害９０１が発生すると、最初にノード２１６及び
２２２で障害が検出される（ステップＳ１００１、Ｓ１
００２）。ノード２２２では、障害によりコネクション
が利用できなくなるので代理ルートノードではなくなる
ので、コネクションの存在するすべてのリーフ端末の方
向に対して、障害によるRELEASEメッセージを送信し、
最終的には、終点ノード２２１、２２４及び２２６にそ
れぞれ通知される。
【００６７】これら終点ノード２２１、２２４及び２２
６では、それぞれリーフ端末側のコネクションを維持し
つつ、タイマを起動し（ステップＳ１００５〜Ｓ１００
７）、マルチポイントコネクション識別子と迂回処理番
号管理手段１０７にて管理している迂回処理番号よりも
大きい値とをLEAF SETUP REQUESTメッセージに付与して
送信する（図６のステップＳ６０９〜Ｓ６１１を参
照）。
６では、それぞれリーフ端末側のコネクションを維持し
つつ、タイマを起動し（ステップＳ１００５〜Ｓ１００
７）、マルチポイントコネクション識別子と迂回処理番
号管理手段１０７にて管理している迂回処理番号よりも
大きい値とをLEAF SETUP REQUESTメッセージに付与して
送信する（図６のステップＳ６０９〜Ｓ６１１を参
照）。
【００６８】一方、ノード２１６は自ノードが中継ノー
ドであるので、ルート端末方向へRELEASEメッセージを
送信し、最終的に始点ノード２１１（リーフ端末２０３
にとって代理ルートノード）へ到達する。ノード２１１
では、タイマを起動し（ステップＳ１００４）、コネク
ション管理をしているリーフ端末２０３に関するLEAFSE
TUP REQUESTメッセージの受信を待つ。
ドであるので、ルート端末方向へRELEASEメッセージを
送信し、最終的に始点ノード２１１（リーフ端末２０３
にとって代理ルートノード）へ到達する。ノード２１１
では、タイマを起動し（ステップＳ１００４）、コネク
ション管理をしているリーフ端末２０３に関するLEAFSE
TUP REQUESTメッセージの受信を待つ。
【００６９】始点ノード２１１がリーフ端末２０３用の
LEAF SETUP REQUESTメッセージを受信すると、タイマを
停止し、リーフ端末２０３までの経路計算を行い（ステ
ップＳ１００８）、この経路計算結果に基づきSETUPメ
ッセージを送信する（図４のステップＳ４０８〜Ｓ４１
４を参照）。そして、このSETUPメッセージが順次転送
され（ここではノード２３１、２３４、２２３及び２２
２を通る経路）、最終的に終点ノード２２１まで到達す
る。終点ノード２２１では、受信したSETUPメッセージ
のコネクション識別子及び迂回処理番号から迂回経路用
のSETUPメッセージであることを確認し、問題なけれ
ば、タイマの停止をし、CONNECTメッセージを返送する
（図５のステップＳ５０１〜Ｓ５０７を参照）。
LEAF SETUP REQUESTメッセージを受信すると、タイマを
停止し、リーフ端末２０３までの経路計算を行い（ステ
ップＳ１００８）、この経路計算結果に基づきSETUPメ
ッセージを送信する（図４のステップＳ４０８〜Ｓ４１
４を参照）。そして、このSETUPメッセージが順次転送
され（ここではノード２３１、２３４、２２３及び２２
２を通る経路）、最終的に終点ノード２２１まで到達す
る。終点ノード２２１では、受信したSETUPメッセージ
のコネクション識別子及び迂回処理番号から迂回経路用
のSETUPメッセージであることを確認し、問題なけれ
ば、タイマの停止をし、CONNECTメッセージを返送する
（図５のステップＳ５０１〜Ｓ５０７を参照）。
【００７０】リーフ端末２０４及び２０５に関するLEAF
SETUP REQUESTメッセージも始点ノード２１１に到着す
るが、これらの端末はすでに管理しているリーフ端末２
０３と同じピアグループ２５２に属することから、自分
が属するピアグループ２５１で新規に分岐する必要がな
いと判断し、ノード２１１はリーフ端末２０３と同じ経
路で、リーフ端末２０４及び２０５用のLEAF SETUP REQ
UESTメッセージを順次送信する。
SETUP REQUESTメッセージも始点ノード２１１に到着す
るが、これらの端末はすでに管理しているリーフ端末２
０３と同じピアグループ２５２に属することから、自分
が属するピアグループ２５１で新規に分岐する必要がな
いと判断し、ノード２１１はリーフ端末２０３と同じ経
路で、リーフ端末２０４及び２０５用のLEAF SETUP REQ
UESTメッセージを順次送信する。
【００７１】ピアグループ２５２のエントリノードであ
るノード２２３は、リーフ端末２０４用のLEAF SETUP R
EQUESTメッセージを受信すると、リーフ端末２０４の代
理ルートノードと判断し（ステップＳ１００９）、終点
ノード２２４までの経路計算を行い、この経路計算結果
に基づきSETUPメッセージを送信する（図４のステップ
Ｓ４０８〜Ｓ４１４を参照）。そして、このSETUPメッ
セージがノード２２５を通して順次転送され、終点ノー
ド２２４まで到達する。終点ノード２２４では、受信し
たSETUPメッセージのコネクション識別子及び迂回処理
番号から迂回経路用のSETUPメッセージであることを確
認し、問題なければ、タイマの停止をし、迂回経路への
切り替えを行い、CONNECTメッセージを返送してコネク
ションを設定する（ステップＳ１０１０：図５のステッ
プＳ５０１〜Ｓ５０７を参照）。
るノード２２３は、リーフ端末２０４用のLEAF SETUP R
EQUESTメッセージを受信すると、リーフ端末２０４の代
理ルートノードと判断し（ステップＳ１００９）、終点
ノード２２４までの経路計算を行い、この経路計算結果
に基づきSETUPメッセージを送信する（図４のステップ
Ｓ４０８〜Ｓ４１４を参照）。そして、このSETUPメッ
セージがノード２２５を通して順次転送され、終点ノー
ド２２４まで到達する。終点ノード２２４では、受信し
たSETUPメッセージのコネクション識別子及び迂回処理
番号から迂回経路用のSETUPメッセージであることを確
認し、問題なければ、タイマの停止をし、迂回経路への
切り替えを行い、CONNECTメッセージを返送してコネク
ションを設定する（ステップＳ１０１０：図５のステッ
プＳ５０１〜Ｓ５０７を参照）。
【００７２】同様に、ノード２２３は、リーフ端末２０
５用のLEAF SETUP REQUESTメッセージを受信すると、リ
ーフ端末２０５の代理ルートノードと判断し（ステップ
Ｓ１０１１）、終点ノード２２６までの経路計算を行す
る。この場合、ノード２２３からノード２２５までは既
にコネクションが設定されているから、ノード２２３は
ADD PARTYメッセージをノード２２５へ送信する（図４
のステップＳ４０８〜Ｓ４１２、Ｓ４１５を参照）。
５用のLEAF SETUP REQUESTメッセージを受信すると、リ
ーフ端末２０５の代理ルートノードと判断し（ステップ
Ｓ１０１１）、終点ノード２２６までの経路計算を行す
る。この場合、ノード２２３からノード２２５までは既
にコネクションが設定されているから、ノード２２３は
ADD PARTYメッセージをノード２２５へ送信する（図４
のステップＳ４０８〜Ｓ４１２、Ｓ４１５を参照）。
【００７３】このADD PARTYメッセージを受信したノー
ド２２５は、コネクションの新規分岐が必要であるか
ら、SETUPメッセージを終点ノード２２６へ送信する
（図５のステップＳ５０１、Ｓ５１０、Ｓ５１３及びＳ
５１１〜Ｓ５１２を参照）。終点ノード２２６では、受
信したSETUPメッセージのコネクション識別子及び迂回
処理番号から迂回経路用のSETUPメッセージであること
を確認し、問題なければ、タイマの停止をし、迂回経路
への切り替えを行い、CONNECTメッセージを返送する
（ステップＳ１０１２：図５のステップＳ５０１〜Ｓ５
０７を参照）。CONNECTメッセージを受信したノード２
２５は、ノード２２３へADD PARTY ACKNOWLEDGEメッセ
ージを返送し、これによって入口ノード２２３から終点
ノード２２６までのコネクションが設定される。このよ
うにして、障害９０１が発生した場合でも、迂回経路９
０２に切り替えてリーフ端末２０３、２０４及び２０５
のコネクションを回復することができる。
ド２２５は、コネクションの新規分岐が必要であるか
ら、SETUPメッセージを終点ノード２２６へ送信する
（図５のステップＳ５０１、Ｓ５１０、Ｓ５１３及びＳ
５１１〜Ｓ５１２を参照）。終点ノード２２６では、受
信したSETUPメッセージのコネクション識別子及び迂回
処理番号から迂回経路用のSETUPメッセージであること
を確認し、問題なければ、タイマの停止をし、迂回経路
への切り替えを行い、CONNECTメッセージを返送する
（ステップＳ１０１２：図５のステップＳ５０１〜Ｓ５
０７を参照）。CONNECTメッセージを受信したノード２
２５は、ノード２２３へADD PARTY ACKNOWLEDGEメッセ
ージを返送し、これによって入口ノード２２３から終点
ノード２２６までのコネクションが設定される。このよ
うにして、障害９０１が発生した場合でも、迂回経路９
０２に切り替えてリーフ端末２０３、２０４及び２０５
のコネクションを回復することができる。
【００７４】
【発明の効果】以上説明したように、本発明の障害回復
方法及びシステムは、障害によるコネクション切断メッ
セージを通信網のルート端末側から受信すると、リーフ
端末とのコネクションを維持したまま通信網へ接続要求
メッセージを送信し、当該障害箇所を迂回した別経路の
コネクションを設定することができるために、マルチポ
イントコネクションにおいて障害が発生しても自律的に
回復することが可能となる。
方法及びシステムは、障害によるコネクション切断メッ
セージを通信網のルート端末側から受信すると、リーフ
端末とのコネクションを維持したまま通信網へ接続要求
メッセージを送信し、当該障害箇所を迂回した別経路の
コネクションを設定することができるために、マルチポ
イントコネクションにおいて障害が発生しても自律的に
回復することが可能となる。
【図１】本発明による障害回復システムの一実施形態を
適用したネットワークにおけるノードの機能的構成を示
すブロック図である。
適用したネットワークにおけるノードの機能的構成を示
すブロック図である。
【図２】（Ａ）は本発明が適用されるネットワークの一
例を示す構成図であり、（Ｂ）はそのピアグループ内で
のトポロジ情報のフラッディング動作例を示す説明図で
ある。
例を示す構成図であり、（Ｂ）はそのピアグループ内で
のトポロジ情報のフラッディング動作例を示す説明図で
ある。
【図３】本実施形態における各ノードの代理ルートノー
ド判定手順を示すフローチャートである。
ド判定手順を示すフローチャートである。
【図４】本実施形態における各ノードのLEAF SETUP REQ
UEST メッセージ受信処理を示すフローチャートであ
る。
UEST メッセージ受信処理を示すフローチャートであ
る。
【図５】本実施形態における各ノードのSETUP/ADD PART
Yメッセージ受信処理を示すフローチャートである。
Yメッセージ受信処理を示すフローチャートである。
【図６】本実施形態における各ノードのRELEASE/DROP P
ARTY メッセージ受信処理を示すフローチャートであ
る。
ARTY メッセージ受信処理を示すフローチャートであ
る。
【図７】マルチポイントコネクションに対し障害が発生
したときに、障害を迂回する代替経路の第１例を示す説
明図である。
したときに、障害を迂回する代替経路の第１例を示す説
明図である。
【図８】図７の経路切替動作を示すシーケンス図であ
る。
る。
【図９】マルチポイントコネクションに対し障害が発生
したときに、障害を迂回する代替経路の第２例を示す説
明図である。
したときに、障害を迂回する代替経路の第２例を示す説
明図である。
【図１０】図９の経路切替動作を示すシーケンス図であ
る。
る。
【符号の説明】 １０１ ルーティング手段 １０２ シグナリング手段 １０３ 経路計算手段 １０４ トポロジ情報データベース １０５ 経路情報データベース １０６ メッセージ情報データベース １０７ 迂回処理番号管理手段 １０８ 切替手段 １０９ タイマ ２０１ ルート端末 ５０３〜２０５ リーフ端末 ２１１〜２１６、２２１〜２２６、２３１〜２３６ ノ
ード ２５１〜２５３ ピアグループ ７０１、９０１ 障害 ７０２、９０２ 迂回経路
ード ２５１〜２５３ ピアグループ ７０１、９０１ 障害 ７０２、９０２ 迂回経路
Claims (13)
- 【請求項１】 複数のノードを通してコネクションの発
信元である端末（以下、ルート端末という。）と着信先
である複数の端末（以下リーフ端末という。）との間の
マルチポイントコネクションが、前記ルート端末の代わ
りにマルチポイントコネクションを管理し接続処理を行
うノード（以下、代理ルートノードという。）を所定の
規則に従って決定し、前記ルート端末に依存することな
く網内で設定され管理される方式のコネクションオリエ
ンティッドな通信網における障害回復方法において、 あるリーフ端末と接続しているノード（以下、終点ノー
ドという。）では、 前記リーフ端末側からの接続要求メッセージによりコネ
クションを設定した後で、障害によるコネクション切断
メッセージを前記通信網のルート端末側から受信する
と、前記リーフ端末側のコネクションを維持したまま、
前記通信網へ接続要求メッセージを送信し、前記代理ルートノードでは、 前記障害によるコネクション切断メッセージを前記リー
フ端末側より受信すると前記ルート端末側のコネクショ
ンを維持し、 前記終点ノードから接続要求メッセージを受信すると前
記障害回復用の接続メッセージを送信し、 前記終点ノードでは、 前記通信網から前記接続要求メッセージに対する障害回
復用の接続メッセージを受信すると、当該接続メッセー
ジによるコネクションと前記維持されたリーフ端末側の
コネクションとを接続して迂回経路へ切り替え、前記代理ルートノードでは、 前記障害回復用の接続メッセージにより前記リーフ端末
側とのコネクションが確立した後で、前記維持されたル
ート端末側のコネクションと接続して迂回経路へ切り替
える、 ことを特徴とする障害回復方法。 - 【請求項２】 前記終点ノードが送信する前記接続要求
メッセージには、前記通信網から受信した接続メッセー
ジを最終的に採用するべき否かを判定するための判定番
号と、当該接続要求メッセージで要求するコネクション
を一意に特定できる識別子とが付与されることを特徴と
する請求項１記載の障害回復方法。 - 【請求項３】 前記終点ノードでは、前記障害によるコ
ネクション切断メッセージを受信した時は所定時間に設
定された監視タイマを起動し、前記障害回復用の接続メ
ッセージを受信した時は前記監視タイマを停止すること
で、障害回復のための迂回処理が正常に行われているか
どうかを監視することを特徴とする請求項１又は２記載
の障害回復方法。 - 【請求項４】 前記代理ルートノードでは、前記障害に
よるコネクション切断メッセージを前記リーフ端末側よ
り受信した時は所定時間に設定された監視タイマを起動
し、前記終点ノードから接続要求メッセージを受信した
時には前記監視タイマを停止することで、迂回処理が正
常に行われているかどうかを監視することを特徴とする
請求項１〜３のいずれか１項に記載の障害回復方法。 - 【請求項５】 複数のノードを通してコネクションの発
信元である端末（以下、ルート端末という。）と着信先
である複数の端末（以下リーフ端末という。）との間の
マルチポイントコネクションに対して、当該マルチポイ
ントコネクション内のノードであって前記ルート端末の
代わりに所定規則に従って定められた１以上のノード
（以下、代理ルートノードという。）が設定及び管理を
行う方式のコネクションオリエンティッドな通信網にお
ける障害回復方法において、 前記マルチポイントコネクションに障害が検出される
と、前記障害によって影響を受ける代理ルートノードの
前記ルート端末側のコネクションを維持し、 前記障害によって影響を受けるリーフ端末が接続された
ノート（以下、終点ノードという。）の前記リーフ端末
側のコネクションを維持し、 前記障害によって影響を受けるリーフ端末が接続された
終点ノードからの接続要求に従って、前記障害によって
影響を受ける代理ルートノードと当該終点ノードとの間
で前記障害を迂回する迂回経路を設定し、 前記迂回経路と前記維持されたコネクションとを前記代
理ルートノード及び前記終点ノードにおいて接続する、 ことを特徴とする障害回復方法。 - 【請求項６】 前記終点ノードでは、 前記リーフ端末からの接続要求メッセージによりコネク
ションを設定した後で、障害によるコネクション切断メ
ッセージを前記通信網のルート端末側から受信すると、
前記リーフ端末とのコネクションを維持したまま、前記
通信網へ接続要求メッセージを送信し、 前記通信網から前記接続要求メッセージに対する障害回
復用の接続メッセージを受信すると、当該接続メッセー
ジによるコネクションと前記維持されたリーフ端末側の
コネクションとを接続して迂回経路へ切り替える、 ことを特徴とする請求項５記載の障害回復方法。 - 【請求項７】 前記終点ノードが送信する前記接続要求
メッセージには、前記通信網から受信した接続要求メッ
セージが最終的に採用されるべき否かを判定するための
判定番号と、当該接続要求メッセージで要求するコネク
ションを一意に特定できる識別子とが付与されることを
特徴とする請求項６記載の障害回復方法。 - 【請求項８】 前記代理ルートノードでは、 前記障害によるコネクション切断メッセージを前記リー
フ端末側より受信すると前記ルート端末側のコネクショ
ンを維持し、 前記終点ノードから接続要求メッセージを受信すると前
記障害回復用の接続メッセージを送信し、 前記障害回復用の接続メッセージにより前記リーフ端末
側とのコネクションが確立した後で、前記維持されたル
ート端末側のコネクションと接続して迂回経路へ切り替
える、 ことを特徴とする請求項６又は７記載の障害回復方法。 - 【請求項９】 前記終点ノードが送信する前記接続要求
メッセージには、前記通信網から受信した接続要求メッ
セージが最終的に採用されるべき否かを判定するための
判定番号と、当該接続要求メッセージで要求するコネク
ションを一意に特定できる識別子とが付与される、 ことを特徴とする請求項８記載の障害回復方法。 - 【請求項１０】 複数のノードを通してコネクションの
発信元である端末（以下、ルート端末という。）と着信
先である複数の端末（以下リーフ端末という。）との間
のマルチポイントコネクションが、前記ルート端末の代
わりにマルチポイントコネクションを管理し接続処理を
行うノード（以下、代理ルートノードという。）を所定
の規則に従って決定し、前記ルート端末に依存すること
なく網内で設定され管理される方式のコネクションオリ
エンティッドな通信網における障害回復システムにおい
て、 あるリーフ端末と接続しているノード（以下、終点ノー
ドという。）は、 前記リーフ端末から接続要求メッセージを受信したとき
に、当該接続要求メッセージの内容を格納する格納手段
と、 前記接続要求メッセージによりコネクションを設定した
後で、障害によるコネクション切断メッセージを前記通
信網のルート端末側から受信すると、前記リーフ端末と
のコネクションを維持したまま、前記通信網へ接続要求
メッセージを送信する第１制御手段と、 前記通信網から前記接続要求メッセージに対する障害回
復用の接続メッセージを受信すると、当該接続メッセー
ジによるコネクションと前記維持されたリーフ端末側の
コネクションとを接続して迂回経路へ切り替える第１切
替手段とからなり、前記代理ルートノードは、 前記障害によるコネクション切断メッセージを前記リー
フ端末側より受信すると前記ルート端末側のコネクショ
ンを維持し、前記終点ノードから接続要求メッセージを
受信すると前記障害回復用の接続メッセージを送信する
第２制御手段と、 前記障害回復用の接続メッセージにより前記リーフ端末
側とのコネクションが確立した後で、前記維持されたル
ート端末側のコネクションと接続して迂回経路へ切り替
える第２切替手段と、 からなることを特徴とする障害回復システム。 - 【請求項１１】 前記終点ノードは、更に、 前記終点ノードが送信する前記接続要求メッセージに、
前記通信網から受信した接続要求メッセージが最終的に
採用されるべき否かを判定するための判定番号と、当該
接続要求メッセージで要求するコネクションを一意に特
定できる識別子とを付与し、コネクション毎に前記判定
番号を管理する第１管理手段を有することを特徴とする
請求項１０記載の障害回復システム。 - 【請求項１２】 前記終点ノードは、更に、 前記障害によるコネクション切断メッセージを受信した
時に起動し、前記障害回復用の接続メッセージを受信し
た時に停止する第１監視タイマを有することを特徴とす
る請求項１０又は１１記載の障害回復システム。 - 【請求項１３】 前記代理ルートノードは、更に、 前記障害によるコネクション切断メッセージを前記リー
フ端末側より受信した時に起動し、前記終点ノードから
接続要求メッセージを受信した時に停止する監視タイマ
を有することを特徴とする請求項１０〜１２のいずれか
１項に記載の障害回復システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP21852798A JP3072728B2 (ja) | 1998-07-16 | 1998-07-16 | マルチポイントコネクション障害回復方法及びシステム |
| US09/118,861 US6421316B1 (en) | 1998-07-16 | 1998-07-20 | Point-to-multipoint connection restoration |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP21852798A JP3072728B2 (ja) | 1998-07-16 | 1998-07-16 | マルチポイントコネクション障害回復方法及びシステム |
| US09/118,861 US6421316B1 (en) | 1998-07-16 | 1998-07-20 | Point-to-multipoint connection restoration |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000036818A JP2000036818A (ja) | 2000-02-02 |
| JP3072728B2 true JP3072728B2 (ja) | 2000-08-07 |
Family
ID=26522609
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP21852798A Expired - Fee Related JP3072728B2 (ja) | 1998-07-16 | 1998-07-16 | マルチポイントコネクション障害回復方法及びシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6421316B1 (ja) |
| JP (1) | JP3072728B2 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6714544B1 (en) * | 1999-07-08 | 2004-03-30 | Alcatel Canada Inc. | Method and apparatus for proxied signalling of an end to end connection across a connection oriented network |
| US7437449B1 (en) * | 2000-08-15 | 2008-10-14 | Nortel Networks Limited | System, device, and method for managing service level agreements in an optical communication system |
| US7230924B2 (en) * | 2001-03-28 | 2007-06-12 | At&T Corp. | Method and apparatus for communications traffic engineering |
| US7068595B2 (en) * | 2001-04-13 | 2006-06-27 | Sun Microsystems, Inc. | Method and apparatus for facilitating instant failover during packet routing |
| US20020167896A1 (en) * | 2001-05-11 | 2002-11-14 | Arvind Puntambekar | Methods and apparatus for configuration information recovery |
| DE60335068D1 (de) | 2002-09-30 | 2011-01-05 | Panasonic Corp | Kommunikationssystem und Gerät |
| US7327731B1 (en) * | 2003-04-09 | 2008-02-05 | At&T Corp. | Point-to-multipoint connections for data delivery |
| DE102005025420B4 (de) * | 2005-06-02 | 2008-12-24 | Nokia Siemens Networks Gmbh & Co.Kg | Verfahren zur Bereitstellung von Ersatzwegen als schnelle Reaktion auf den Ausfall eines Links zwischen zwei Routing-Domänen |
| US7668079B2 (en) * | 2005-10-21 | 2010-02-23 | Alcatel Lucent | Multiple endpoint paths for point-to-multipoint (P2MP) SPVC |
| US20070091826A1 (en) * | 2005-10-21 | 2007-04-26 | Alcatel | Tracing SPVC point-to-multipoint (P2MP) paths |
| CN100563203C (zh) * | 2005-11-11 | 2009-11-25 | 华为技术有限公司 | 通信网络中组播树叶子节点网元信号传送的方法 |
| JP5039639B2 (ja) | 2008-06-09 | 2012-10-03 | 株式会社日立製作所 | パスプロテクション機能を有する通信装置及びその通信装置を使用するネットワークシステム |
| US20100157888A1 (en) * | 2008-12-18 | 2010-06-24 | Motorola, Inc. | System and method for improving efficiency and reliability of broadcast communications in a multi-hop wireless mesh network |
| KR20100080740A (ko) * | 2009-01-02 | 2010-07-12 | 엘지전자 주식회사 | 무선통신 시스템에서 펨토 기지국의 운영방법 |
| US8553583B2 (en) * | 2011-02-04 | 2013-10-08 | Verizon Patent And Licensing Inc. | Leaky ethernet trees |
| CN105764106B (zh) * | 2016-02-03 | 2019-06-11 | 宇龙计算机通信科技(深圳)有限公司 | 一种传输路径的更新方法、终端和系统 |
| US10110424B1 (en) * | 2017-06-30 | 2018-10-23 | Bank Of American Corporation | Node failure recovery tool |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5627821A (en) * | 1994-03-15 | 1997-05-06 | Hitachi, Ltd. | Defect notification method in a multipoint ATM network |
| US5805578A (en) * | 1995-10-27 | 1998-09-08 | International Business Machines Corporation | Automatic reconfiguration of multipoint communication channels |
| US5831975A (en) * | 1996-04-04 | 1998-11-03 | Lucent Technologies Inc. | System and method for hierarchical multicast routing in ATM networks |
| JP2985940B2 (ja) * | 1996-11-08 | 1999-12-06 | 日本電気株式会社 | 障害回復装置 |
-
1998
- 1998-07-16 JP JP21852798A patent/JP3072728B2/ja not_active Expired - Fee Related
- 1998-07-20 US US09/118,861 patent/US6421316B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6421316B1 (en) | 2002-07-16 |
| JP2000036818A (ja) | 2000-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3072728B2 (ja) | マルチポイントコネクション障害回復方法及びシステム | |
| US7590053B2 (en) | Multiple endpoint protection using SPVCs | |
| JP2985940B2 (ja) | 障害回復装置 | |
| US7468944B2 (en) | Path fault recovery method, switching-back method after recovery from fault, and node using the same | |
| JPH10190686A (ja) | Ａｔｍ網における現用予備経路設定方式 | |
| US6122753A (en) | Fault recovery system and transmission path autonomic switching system | |
| US5896496A (en) | Permanent connection management method in exchange network | |
| WO2011157130A2 (zh) | 路径建立方法和装置 | |
| JPH088972A (ja) | パス設定制御システム | |
| CN103081406B (zh) | 用于应请求通过提供商网络来恢复连接的方法和设备 | |
| JP3529541B2 (ja) | ルータ装置及びパケット転送方法 | |
| US7668079B2 (en) | Multiple endpoint paths for point-to-multipoint (P2MP) SPVC | |
| JP2998688B2 (ja) | 障害回復システム | |
| JP2001156786A (ja) | コネクション経路変更方法及びその方式 | |
| JP2976421B2 (ja) | 通信網における障害回復システム | |
| JP3235662B2 (ja) | 経路制御方式 | |
| JP3011131B2 (ja) | 伝送経路自律切替えシステム | |
| JP3120770B2 (ja) | コネクション経路変更装置とその変更方法及びノードとコネクション経路変更システム | |
| JPH11284633A (ja) | 通信ネットワークにおける障害復旧方法 | |
| JP2972677B2 (ja) | 非同期転送モード通信ネットワーク | |
| JP2000078155A (ja) | Ａｔｍネットワークにおけるコネクション設定方式 | |
| JPH09266480A (ja) | Ａｔｍスイッチにおける通信コネクション張り替え方法 | |
| JP3102353B2 (ja) | 通信ルート切り戻し制御方式 | |
| JP3077684B2 (ja) | コネクション経路変更装置 | |
| JPH10243096A (ja) | コネクション型通信網での障害回復方式および輻輳回復方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20000502 |
|
| LAPS | Cancellation because of no payment of annual fees |