JP6248018B2 - Ｌａｃ装置及びフェイルオーバ方法 - Google Patents

Description

本発明は、インターネット通信等に利用されるＬＡＣ装置及びフェイルオーバ方法に関する。

現在、通信事業者はＬ２ＴＰ（Ｌａｙｅｒ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）によるトンネリング方式を用いて、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）やＦＴＴＨ（Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）によるブロードバンドインターネット接続サービスを加入者に提供している。 従来、Ｌ２ＴＰなどのプロトコル処理を行う制御部を冗長化しているＬＡＣ（Ｌ２ＴＰ Ａｃｃｅｓｓ Ｃｏｎｃｅｎｔｒａｔｏｒ）装置において、運用系制御部で障害が発生した場合、旧運用系制御部から新運用系制御部への切替並びにサービスを継続する技術（以下、フェイルオーバと称する）について、Ｌ２ＴＰの拡張プロトコルで定義される復旧連絡のためのパケットを用いてフェイルオーバを行う技術が非特許文献１に開示されている。

ＲＦＣ４９５１、Ｆａｉｌ Ｏｖｅｒ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｌａｙｅｒ ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ （Ｌ２ＴＰ）、"ｆａｉｌｏｖｅｒ"

Ｌ２ＴＰはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上で動作するプロトコルであり、メッセージの順序性・信頼性は、ＬＡＣ−ＬＮＳ（Ｌ２ＴＰ Ｎｅｔｗｏｒｋ Ｓｅｒｖｅｒ）間におけるトンネルの確立、セッションの確立、定期的な生死確認において使用されるコントロールメッセージに含まれるシーケンス番号（Ｎｓ）と受信確認応答番号（Ｎｒ）を用いて実現されている。 ここで、ＮｓもしくはＮｒが期待する番号でなかった場合、例えば、ネットワーク上で障害が発生し、ＬＡＣ−ＬＮＳ間で疎通ができなくなった場合、ＬＡＣ−ＬＮＳ間のＬ２ＴＰトンネルを切断する仕様になっている。

このため、従来形式で二重化されたＬＡＣ装置において、運用系制御部で故障等が発生し、運用系制御部と待機系制御部でコントロールメッセージに含まれるＮｓ、Ｎｒの同期に失敗した状態で系切り替えが発生した場合、新運用系制御部においてＬ２ＴＰトンネルは切断されてしまい、加入者のインターネット接続による通信は一旦停止してしまう。

上記状態を回避するために非特許文献１ではＬ２ＴＰプロトコルに拡張を行い、この拡張メッセージを用いて、装置復旧時にはＬＡＣ装置からＬＮＳ装置へ復旧したことを伝えるメッセージを送信し、ＬＮＳ装置から通信に必要な情報を再学習することで、通信の継続を実現している。

そして、ＬＡＣ−ＬＮＳ間でコントロールメッセージに含まれるＮｓ、Ｎｒの同期ができていない状態では、Ｌ２ＴＰトンネルは切断されてしまい、加入者のインターネット接続による通信は一旦停止してしまうため、Ｌ２ＴＰトンネルが復旧するまでは、新規セッション接続要求が受け付けられない。Ｌ２ＴＰトンネルの復旧には、Ｌ２ＴＰトンネル数に比例して時間がかかるため、加入者によっては（使用するＬ２ＴＰトンネルによっては）長時間、新規セッション接続要求が受け付けられない。特に大容量装置の場合、長時間新規セッション接続ができない加入者がでる可能性がある。例えば、１つのＬ２ＴＰトンネル当りの復旧時間を１０ミリ秒、確立済みＬ２ＴＰトンネル数が１０，０００と仮定した場合、１００秒間、新規セッション接続要求が受け付けられない。そのため、１０，０００番目のＬ２ＴＰトンネルを使用している加入者は、１００秒間、インターネット接続をすることができない。

本発明は、以上の点に鑑み、ＬＡＣ装置またはＬＮＳ装置の改良でフェイルオーバ時間を短縮するＬＡＣ装置またはＬＮＳ装置及びフェイルオーバ方法を提供することを目的とする。

上記課題を解決するため、本発明に係るＬＡＣ装置は、第１の制御部と、第１の制御部が機能しないときに代わりに動作する第２の制御部と、を有し、第２の制御部は、第１の制御部がＬＮＳ装置との間で確立している複数のトンネルそれぞれに関するトンネル情報を保持する記憶部を有し、第１の制御部に代わって第２の制御部が動作するときに、第２の制御部は、トンネル情報を参照して、第１の制御部がトンネルを確立していたＬＮＳ装置に対し生死確認のメッセージを送信する。そして第２の制御部は、生死確認のメッセージに対する応答メッセージを正常に受信できなかったＬＮＳ装置との間で、トンネルを復旧するための処理を行ない、応答メッセージを正常に受信できたＬＮＳ装置との間ではトンネルを復旧するための処理を行なわない。

本発明によれば、ＬＡＣ装置またはＬＮＳ装置の改良でフェイルオーバ時間の短縮を可能とするＬＡＣ装置またはＬＮＳ装置及びフェイルオーバ方法を提供することができる。

本実施形態のネットワーク構成図である 本実施形態上で使用されるプロトコルのシーケンス図である 本実施形態のＬＡＣ装置の構成図である 本実施形態のトンネル・セッション情報データベースのデータ構造である 本実施形態１のフェイルオーバのフロー図である 本実施形態２のフェイルオーバのフロー図である 本実施形態３のフェイルオーバのフロー図である

以下、実施例を図面を用いて説明する。

図１は、本発明の１つの実施形態におけるネットワークの構成図である。加入者端末１００は、アクセス網１０１、ＬＡＣ装置１０２、Ｌ２ＴＰトンネル１０６、ＬＮＳ装置１０７、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）網１０８を介してインターネット１０９に接続する。ＬＡＣ装置１０２は、加入者端末１００を収容するサーバであり、Ｌ２ＴＰを用いてＬＮＳ装置１０７と連携動作し、加入者端末１００に対しインターネット接続サービスを提供する。加入者端末１００はＬＡＣ装置１０２−ＬＮＳ装置１０７間で構築されたＬ２ＴＰトンネル１０６を用いてインターネット接続サービスを利用する。ＬＡＣ装置１０２は、正常時に動作する運用系制御部１０３と、運用系制御部１０３が動作できなくなったときに代わりに動作する待機系制御部１０４とを備える。

図２は、加入者端末１００からのインターネット１０９への接続要求を受け付けて、ＬＡＣ装置１０２とＬＮＳ装置１０７との間で取りかわされるメッセージの通信シーケンスを説明する図である。まず、加入者端末１００とＬＡＣ装置１０２との間で、ＰＡＤI２０１からＰＡＤＳ２０４までのＰＰＰｏＥ（ＰＰＰ Ｏｖｅｒ Ｅｔｈｅｒｎｅｔ：Ｅｔｈｅｒｎｅｔは登録商標）に従ったメッセージがやり取りされる。このやり取りにより、加入者端末１００とＬＡＣ装置１０２との間でＰＰＰ ＬＣＰ／ＣＨＡＰ２０５のリンク確立ならびに認証が行なわれる。

そしてＬＡＣ装置１０２はＬＮＳ装置１０７との間で、ＳＣＣＲＱ２０６からＺＬＢ−ＡＣＫ２０９までのメッセージをやり取りし、ＬＡＣ装置１０２とＬＮＳ装置１０７との間でトンネルを確立する（２１６）。さらにＬＡＣ装置１０２はＬＮＳ装置１０７との間でＩＣＲＱ２１０からＺＬＢ−ＡＣＫ２１３までのメッセージをやり取りすることで、ＬＡＣ装置１０２とＬＮＳ装置１０７との間でセッションを確立する（２１７）。このセッション確立後、ＬＡＣ装置１０２はＬＮＳ装置１０７へ、定期的にＨｅｌlｏ２１４メッセージを送信しＬＮＳ装置１０７からＺＬＢ−ＡＣＫ２１５メッセージを受信することで、生死確認を行なう（２１８）。

ここでＮｓ番号は、送信する側の装置が、図２中のＺＬＢ−ＡＣＫ（確認応答メッセージ）以外のメッセージを送信する際に、メッセージを一意にするために付与するシーケンス番号である。Ｎｓ番号は、メッセージを一意に識別するために、送信メッセージ毎に１ずつ増加される。なお、ＺＬＢ−ＡＣＫ送信後のメッセージについては例外的に増加されない。数字の範囲は例えば０〜６５５３５で、６５５３５に達した場合は０に戻る。

Ｎｒ番号は、受信側する側の装置が、送信する側の装置に対し次に受信を期待するメッセージのＮｓ番号を通知するために使われる番号である。逆に言うと、Ｎｒ番号−１のメッセージを受信したことを送信側の装置に通知するために使用される確認応答番号である。数字の範囲は例えば０〜６５５３５で、６５５３５に達した場合は０に戻る。

図３は、本実施の形態の中継システム３００を示す図であり、加入者端末１００、ＬＡＣ装置１０２、ＬＮＳ装置１０７の接続関係を図示している。特に、ＬＡＣ装置１０２については機能ブロックにより詳細な構成を図示している。

中継システム３００は、ＬＡＣ装置（アクセス装置）１０２と、ＬＡＣ装置１０２と通信可能な複数の加入者端末１００と、ＬＡＣ装置１０２と通信可能な複数のＬＮＳ装置（ネットワークサーバ）１０７と、を有する。ＬＡＣ装置１０２は、複数の加入者端末１００と通信を行う複数の送信部及び受信部３０１と、複数のＬＮＳ装置１０７と通信を行う複数の送信部・受信部３０１と、送信部・受信部３０１へパケット転送処理を行うパケット転送部３０２と、ホットスタンバイ形式で二重化された制御部（運用系制御部１０３と待機系制御部１０４）とを備える。

加入者端末１００は、ＬＡＣ装置１０２に接続されたパーソナルコンピュータ等の情報処理装置である。例えば、加入者端末１００は、一般家庭等においてユーザが使用するパーソナルコンピュータやブロードバンドルータである。加入者端末１００は、ＬＡＣ装置１０２の送信部・受信部３０１と、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）やＦＴＴＨ（Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）などの通信回線を介してＰＰＰｏＥプロトコルを用いて接続される。加入者端末１００は、ＬＡＣ装置１０２を介してＬＮＳ装置１０７と接続することで、ＬＮＳ装置１０７に接続されたＩＳＰ網１０８との接続を確立し、インターネットに接続する。

ＬＡＣ装置１０２やＬＮＳ装置１０７は、ＩＳＰ網１０８への接続サービスを提供するサーバ装置であり、例えば通信事業者等が準備するサーバ装置である。複数の送信部・受信部３０１は、加入者端末１００とＬＡＣ装置１０２と、ＬＡＣ装置１０２とＬＮＳ装置１０７をそれぞれ接続し通信を行うためのインタフェースである。パケット通信は送信部・受信部３０１を介して行われる。パケット転送部３０２は、受信部から受信したパケットを運用系制御部１０３、待機系制御部１０４へ転送し、また、運用系制御部１０３、待機系制御部１０４から送信されたパケットをそれら制御部の指示に従い適切な送信部に転送する。

運用系制御部１０３並びに待機系制御部１０４はそれぞれ、プロトコル処理部３０３と、トンネル・セッション情報データベース３０４と、トンネル・セッション情報管理部３０５と、監視部３０６と、同期制御部３０７と、を有する。

プロトコル処理部３０３は、加入者端末１００とＬＡＣ装置１０２間で交換されるパケットの処理を行い、加入者端末１００とＰＰＰｏＥセッションを確立する。またプロトコル処理部３０３は、ＬＡＣ装置１０２とＬＮＳ装置１０７間で交換されるパケットの処理を行いＬＮＳ装置１０７とＬ２ＴＰトンネル・セッションを確立する。さらにプロトコル処理部３０３は、確立したセッションに対応するデータ通信に対しては、トンネル・セッション情報データベース３０４に基づき加入者端末１００とＬＮＳ装置１０７間でＩＰ通信を行うためのパケットのエンカプセリング・デカプセリング処理を行う。

トンネル・セッション情報管理部３０５は、系切替時に、トンネル・セッション情報データベース３０４を利用してトンネル・セッションを復旧する管理を行う。監視部３０６はホットスタンバイ形式の二重化を実現するために運用系制御部１０３と待機系制御部１０４で運用系制御部１０３・待機系制御部１０４の制御を行う。例えば監視部３０６は、運用系・待機系の生存確認を行う。なお、監視部３０６は各制御部にあってもよいし、制御部とは別の構成でもよい。

同期制御部３０７は、運用系制御部１０３と待機系制御部１０４の間でホットスタンバイ形式の二重化を実現するために、これら制御部間でのトンネル・セッション情報データベース３０４の同期処理を行う。同期処理は、例えば一方のトンネル・セッション情報データベース３０４のレコードが追加・削除されたタイミングで、他方のトンネル・セッション情報データベース３０４を更新するなどにより実施される。

図４に、トンネル・セッション情報データベース３０４のデータ構造を示す。トンネル・セッション情報データベース３０４は、プロトコル処理部３０３で処理されたトンネル情報４００とセッション情報４１１との組み合わせで構成される。トンネル情報４００はＬ２ＴＰトンネル１０６に関する情報を保持するものであり、複数のトンネル情報４００の中で各々のトンネル情報を識別するための番号等の識別情報（Ｌ２ＴＰ Ｋｅｙ）４０１と、ＬＮＳ装置１０７毎のトンネル情報（ＩＤ）４０２、４０４と、ＩＰアドレス情報４０３、４０５と、Ｎｓ情報（シーケンス番号情報）４０６とＮｒ情報（確認応答番号情報）４０７と、当該トンネルに属するセッション情報４１１を示すＳｅｓｓｉｏｎ Ｉｎｆｏ４０８と、トンネル・セッション復旧有無を管理するＲｅｃｏｖｅｒｙ Ｆｌａｇ ４０９とを有する。

トンネル情報（ＩＤ）は、Ｌ２ＴＰトンネル１０６の生成時、自装置（本実施の形態ではＬＡＣ装置１０２）で個別に使用するＬｏｃａｌ Ｔｕｎｎｅｌ ＩＤ４０２と対向装置（本実施の形態ではＬＮＳ装置１０７）から通知されるＲｅｍｏｔｅ Ｔｕｎｎｅｌ ＩＤ４０４との組み合わせに対して運用系制御部１０３が付与するＩＤであり、Ｌ２ＴＰトンネル１０６を特定するために使用する。ＩＰアドレス情報は、自装置（ＬＡＣ装置１０２）が使用するＬｏｃａｌ ＩＰ Ａｄｄｒｅｓｓ４０３と、対向装置（ＬＮＳ装置１０７）が使用するＲｅｍｏｔｅ ＩＰ Ａｄｄｒｅｓｓ４０５である。運用系制御部１０３は、例えばＬＮＳ装置１０７とＬ２ＴＰトンネル１０６を確立したタイミング(図２の２１６)で新たなトンネル情報４００をトンネル・セッション情報データベース３０４に追加し、またＬ２ＴＰトンネル１０６を切断したタイミングで削除する。運用系制御部１０３は、Ｌ２ＴＰ制御パケットの送受信（図２：２０６〜２１５）によりＮｓとＮｒが更新される度に、Ｌ２ＴＰ Ｎｓ４０６とＬ２ＴＰ Ｎｒ４０７とを更新する。これにより、ＬＡＣ装置１０２は現状使用しているＮｓとＮｒの値を保持し、ＬＮＳ装置１０７から受信したメッセージに含まれるＮｓやＮｒの値と比較して、メッセージの順序性を確認することができる。Ｒｅｃｏｖｅｒｙ Ｆｌａｇ４０９は本実施例では運用系制御部１０３から待機系制御部１０４への系切り替え時に使用される情報であり、このＲｅｃｏｖｅｒｙＦｌａｇ４０９がＯｆｆのトンネルは本実施例によるトンネル・セッション復旧処理が未実行であり、Ｏｎのものは復旧処理が実行済みであることを表す。

セッション情報４１１は、複数のセッション情報４１１の中で各々のセッション情報を識別するための番号等の識別情報（Ｓｅｓｓｉｏｎ Ｋｅｙ）４１２と、ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ） ＩＤ４１３とプロトコル処理部３０３で処理された加入者端末１００毎のＰＰＰｏＥセッション情報（ＩＤ）４１４とＬ２ＴＰセッション情報（ＩＤ）４１５とＬ２ＴＰ Ｋｅｙ４０１とを有する。セッション情報４１１が有するＬ２ＴＰ Ｋｅｙ４０１は、セッション情報４１１から当該セッションが属するトンネル情報４００を特定するために使用される。運用系制御部１０３は、例えばＬＮＳ装置１０７とセッションを確立したタイミング（図２の２１７）で新たなセッション情報４１１をトンネル・セッション情報データベース３０４に追加し、をまたセッションを切断したタイミングで削除する。

図５に本実施形態１のフェイルオーバ処理のフロー図を示す。運用系制御部１０３と待機系制御部１０４との間で、確立済みのトンネル・セッションのトンネル・セッション情報データベース３０４が同期状態となっており、さらにＬＡＣ装置１０２とＬＮＳ装置１０７との間でもトンネル・セッション情報データベース３０４の情報について同期状態となっており、ＬＮＳ装置１０７にもＬＡＣ装置１０２が保持するのと同じトンネル情報４００やセッション情報４１１が保持されている状態で、ＬＡＣ装置１０２の運用系制御部１０３において故障が発生すると、運用系の切替（フェイルオーバ）が発生する。

運用系の切替によりＬＡＣ装置１０２の待機系制御部１０４が新たな運用系の制御となり、フェイルオーバ処理５０１を開始する。まず、プロトコル処理部３０３が、加入者端末１００からの新規セッション受付接続要求受付を抑止し（ステップ５０２）、トンネル・セッション情報管理部３０５が、トンネル・セッション情報データベース３０４が保持する確立済みの全トンネル情報４００のＲｅｃｏｖｅｒｙ Ｆｌａg４０９をＯｆｆにする（ステップ５０３）とともに該当全トンネルに対し（ステップ５０４）、トンネル・セッション復旧処理（５０５）を開始する。

該トンネル・セッション復旧処理（ステップ５０５）では、トンネル・セッション情報データベース３０４にトンネル情報４００が保持されている全てのトンネルについて、当該トンネルを形成しているＬＮＳ装置１０７に対し、トンネル・セッション情報管理部３０５が、プロセス処理部３０３経由でＬ２ＴＰの定期的な生死確認メッセージであるＨｅｌｌｏ２１４を送信する（ステップ５０６）。そしてトンネル・セッション情報管理部３０５は、ＬＮＳ装置１０７からの該当Ｈｅｌｌｏの応答（ＺＬＢ−ＡＣＫ２１５）により、それぞれのＬ２ＴＰトンネル１０６について、非特許文献１によるトンネル・セッション復旧処理を実施するか否かを判断（ステップ５０７）する。

トンネル・セッション情報管理部３０５は、ＬＮＳ装置１０７からのＺＬＢ−ＡＣＫ２０５に含まれるＮｓ、Ｎｒをトンネル・セッション情報データベース３０４で保持しているトンネル・セッション復旧チェック対象のトンネル情報４００内のＬ２ＴＰ Ｎｓ４０６、Ｌ２ＴＰ Ｎｒ４０７と比較する。受信したＺＬＢ−ＡＣＫ２１５のＮｓ、Ｎｒが、データベースに保持している期待値と一致している場合、ＬＡＣ装置１０２とＬＮＳ装置１０７の間のメッセージの一意性は保たれているため、トンネル・セッション情報管理部３０５は、非特許文献１によるトンネル・セッション復旧処理は必要ないと判断し、当該トンネルに対する新規セッション接続要求受付抑止を解除（ステップ５０８）するとともにトンネル・セッション情報データベース３０４内の該当トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａｇ４０６をＯｎにし（ステップ５０９）、トンネル・セッション復旧処理は完了したと判断する。

一方、ＬＮＳ装置１０７からのＺＬＢ−ＡＣＫ２０５のＮｓ、Ｎｒをトンネル・セッション情報データベース３０４で保持しているトンネル・セッション復旧チェック対象のトンネル情報４００内のＬ２ＴＰ Ｎｓ４０６、Ｌ２ＴＰ Ｎｒ４０７と比較し、期待値と一致していない場合（異常応答）やＺＬＢ−ＡＣＫ２０５が受信できない場合（応答タイムアウト）、トンネル・セッション情報管理部３０５は、ＬＡＣ装置１０２とＬＮＳ装置１０７の間のメッセージの一意性は保たれていないと判断し、非特許文献１によりＮｓとＮｒの補正を行うことでトンネル・セッション復旧処理（ステップ５１０）を実施する。そしてトンネル・セッション情報管理部３０５は、トンネル・セッション復旧処理を完了したトンネルに対する新規セッション接続要求受付抑止を解除（ステップ５１１）するとともにトンネル・セッション情報データベース３０４内の該当トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａg４０６をＯｎにする（ステップ５０９）。

上述のように、本実施例のＬＡＣ装置１０２は、非特許文献１のトンネル・セッション復旧処理（ステップ５１０）を実施する前に、トンネルを形成する他端のＬＮＳ装置１０７にＨｅｌｌｏ２１４メッセージを送信してＮｓやＮｒの順序が保たれているか、もしくは応答メッセージを受信することができるか、を確認する。この確認により、ＮｓやＮｒの順序が保たれているＬＮＳ装置１０７との間のトンネルやセッションはそのまま通信を継続することができるため、非特許文献１によるトンネル・セッション復旧処理（ステップ５１０）を実施せずに済む。これにより本実施例では、非特許文献１のトンネル・セッション復旧処理（ステップ５１０）を実施するトンネル数を少なくし、フェイルオーバ時間を短縮することができる。

本実施例では、加入者端末１００より受け付けた新規セッション接続要求が属するＬ２ＴＰトンネル１０６を優先して復旧させるＬＡＣ装置１０２の例を説明する。ＬＡＣ装置の構成は図３と同様であるが、実施例１と異なり実施例２では新規セッション接続要求保留部３０８が機能する。この新規セッション接続要求保留部３０８とは、ＬＡＣ装置１０２が実施例１における既設Ｌ２ＴＰトンネル１０６の導通確認又は復旧処理を行なっている最中に加入者端末１００からＬ２ＴＰトンネル１０６を介した新規セッションの確立要求を受信した場合に、当該要求されたセッションに必要なＬ２ＴＰトンネル１０６の情報を保持するものである。

図６に、本実施の形態のフェイルオーバ処理時のトンネル・セッション復旧処理において、ＬＡＣ装置１０２が加入者端末１００より受け付けた新規セッション接続要求の属するＬ２ＴＰトンネル１０６を優先して復旧させる処理のフロー図を示す。

運用系制御部１０３と待機系制御部１０４で確立済みのトンネル・セッションのトンネル・セッション情報データベース３０４が同期状態となっており、同じ情報がＬＮＳ装置１０７にある状態で、運用系制御部１０３において故障が発生し、フェイルオーバ処理５０１が動作し、プロトコル処理部３０３が、加入者端末１００からの新規セッション接続要求受付を抑止し（ステップ５０２）、トンネル・セッション情報管理部３０５が、トンネル・セッション情報データベース３０４が保持する確立済みの全トンネル情報４００のＲｅｃｏｖｅｒｙ Ｆｌａg４０９をＯｆｆにする（ステップ５０３）までは、図５と同様のフローであり、上述の通りである。

本実施例では、新規セッション接続要求受付抑止（ステップ５０２）後の新規セッション接続要求は、プロトコル処理部３０３が新規セッション接続要求保留部３０８に保留し、その状態で、トンネル・セッション情報管理部３０５が、トンネル・セッション情報データベース３０４が保持する全確立済みＬ２ＴＰトンネル１０６に対し（ステップ５０４）、トンネル・セッション復旧処理を開始する。

該トンネル・セッション復旧処理では、トンネル・セッション復旧処理を実施する前にトンネル・セッション情報管理部３０５が新規セッション接続要求保留部３０８に新規セッション接続要求の有無を確認する。（ステップ６０１）新規セッション接続要求が無い場合、トンネル・セッション情報管理部３０５は、現在のループ処理で対象となるＬ２ＴＰトンネル１０６に対応するトンネル情報４００をトンネル・セッション情報データベース３０４から取得し、当該Ｌ２ＴＰトンネル１０６の復旧状態を、取得したトンネル情報４００のＲｅｃｏｖｅｒｙ Ｆｌａｇ４０９を参照して確認する（ステップ６０２）。何故この処理が必要かと言うと、ループの順番でＬ２ＴＰトンネル１０６の復旧がなされる前に、加入者端末１００からの新規セッション接続要求によってＬ２ＴＰトンネルの復旧処理がされている場合があるためである。つまり、新規セッション接続要求によって復旧処理がなされたトンネルであっても、トンネル・セッション情報管理部３０５はトンネル・セッション情報データベース３０４に格納されたトンネル情報４００について所定の順番で復旧処理を行っていくため、既に復旧がなされたＬ２ＴＰトンネル１０６についてはこのステップ６０２の処理にて復旧処理をスキップすることができる。

ステップ６０２で当該Ｌ２ＴＰトンネル１０６のＲｅｃｏｖｅｒｙ Ｆｌａｇ４０９がＯｆｆとなっておりまだ復旧処理がなされていない場合は、非特許文献１によるトンネル・セッション復旧処理（ステップ６０３）を実施し、トンネル・セッション復旧処理を完了したトンネルに対する新規セッション接続要求受付抑止を解除（ステップ６０４）するとともにトンネル・セッション情報データベース３０４内の該当トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａg４０６をＯｎにする（ステップ６０５）。

一方、トンネル・セッション情報管理部３０５が新規セッション接続要求保留部３０８に新規セッション接続要求の有無を確認し（ステップ６０１）、新規セッション接続要求が有る場合は、新規セッション接続要求に含まれているトンネルＩＤよりトンネル・セッション情報データベース３０４内のトンネル情報４００を検索する。新規セッション接続要求から得られるトンネルＩＤとトンネル情報４００内のトンネルＩＤ（４０２、４０４）が一致したトンネル情報４００が見つからなかった場合（該当トンネル情報なし）は、当該Ｌ２ＴＰトンネル１０６は既設のトンネルではなく新しく作成すべきトンネルでありトンネル・セッション復旧処理は不要のため、プロトコル処理部３０３は新規セッション接続要求を受付けて（ステップ６０７）、新たなＬ２ＴＰトンネル１０６を対向のＬＮＳ装置１０７との間で形成し(図２の２１６の処理)、さらにセッションを確立する（図２の２１７の処理）。

新規セッション接続要求から得られるトンネルＩＤとトンネル情報４００内のトンネルＩＤ（４０２、４０４）が一致したトンネル情報４００が見つかった場合、本実施例ではそのＬ２ＴＰトンネル１０６の復旧処理を他のＬ２ＴＰトンネル１０６よりも優先して実行する。トンネル・セッション情報管理部３０５は当該トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａｇ４０９を確認する。Ｒｅｃｏｖｅｒｙ Ｆｌａｇ４０９がＯｎの場合（トンネル復旧済）、該当トンネルは、トンネル・セッション復旧処理済みのため、トンネル・セッション復旧処理は不要であり、そのトンネル上で設定されるセッションの新規セッション接続要求を受付ける（ステップ６０７）。これは、もともとのループの順番でＬ２ＴＰトンネル１０６の復旧処理をしている間に、既に当該Ｌ２ＴＰトンネル１０６の復旧処理がなされた後で、当該トンネルを用いた新規のセッション確立要求が生じた場合である。

当該トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａｇ４０９がＯｆｆ（トンネル未復旧）の場合、該当トンネルはまだ復旧されていないため、セッション接続の前にＬ２ＴＰトンネル１０６の復旧処理が必要である。トンネル・セッション情報管理部３０５は、該当トンネルをトンネル・セッション復旧処理の順番に関わらず、優先して非特許文献１によるトンネル・セッション復旧処理を実施し（ステップ６０８）、トンネル・セッション復旧処理を完了したトンネルに対する新規セッション接続要求受付抑止を解除（ステップ６０９）するとともにトンネル・セッション情報データベース３０４内の該当トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａg４０６をＯｎにする（ステップ６１０）。そして、プロトコル処理部３０３は復旧したＬ２ＴＰトンネル１０６を使用する新規セッション接続要求を受け付ける（ステップ６０７）。

なお、トンネル・セッション情報管理部３０５が全確立済みトンネルを順番にトンネル・セッション復旧処理を実施している間に、新規セッション接続要求に伴うトンネル・セッション復旧処理を実施した場合、優先してトンネル・セッション復旧処理を実施したＬ２ＴＰトンネル１０６に対してトンネル・セッション復旧処理を実施する順番となる。その際、再度、トンネル・セッション情報管理部３０５がトンネル・セッション復旧処理を実施しないように、前述のとおり、トンネル・セッション情報管理部３０５がループ上での処理順番が回ってきたＬ２ＴＰトンネル１０６のトンネル復旧処理を実施したかどうかを判断する（ステップ６０２）。ステップ６０２の判断は、トンネル・セッション情報管理部３０５がトンネル・セッション復旧対象のトンネルに関するトンネル・セッション情報データベース３０４内のトンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａg４０９を確認することで実施する。該Ｒｅｃｏｖｅｒｙ Ｆｌａg４０９がＯｎの場合は、トンネル・セッション情報管理部３０５は新規セッション接続要求に伴うトンネル復旧が実施済みと判断し、何もせずに次のＬ２ＴＰトンネル１０６のトンネル・セッションの復旧処理を実施する。該Ｒｅｃｏｖｅｒｙ Ｆｌａg４０９がＯｆｆの場合は、新規セッション接続要求に伴うトンネル復旧が未実施と判断し、上述したステップ６０３〜６０５の処理を実施する。

上述のように、全確立済みトンネルを順番にトンネル・セッション復旧処理を実施する際に、新規セッション接続要求の有無を確認し、新規セッション接続要求に伴うトンネル・セッション復旧処理を優先的に実施することで、インターネット接続サービスを停止することなく継続することができる。

本実施例では、フェイルオーバ時間を短縮し、かつ、加入者より受け付けた新規セッション接続要求が属するＬ２ＴＰトンネルを優先して復旧させるＬＡＣ装置１０２の例を説明する。

本実施例は、実施例１と実施例２の組み合わせによる形態であり、本実施形態のフェイルオーバのフロー図は、図７の通りになる。本実施例では、実施例２における非特許文献１によるトンネル・セッション復旧処理からトンネル・セッション情報データベース３０４内の該当トンネル情報４００内のＲｅｃｏｖｅｒｙ Ｆｌａg４０６をＯｎにする一連の処理（ステップ６０３からステップ６０５までの一連の処理、およびステップ６０８からステップ６１０までの一連の処理）を、実施例１におけるトンネル・セッション復旧処理（ステップ５０５）に置き換えて実施するフェイルオーバ方法である。

上述のように本実施例では、全確立済みトンネルを順番にトンネル・セッション復旧処理を実施する際に、新規セッション接続要求の有無を確認し、新規セッション接続要求に伴うトンネル・セッション復旧処理を優先的に実施し、かつ、ＮｓとＮｒを補正するトンネル・セッション復旧処理を実施する前にＨｅｌｌｏ送信２１４を実施することで、フェイルオーバ時間を短縮し、かつ、インターネット接続サービスを停止することなく継続することができる。

本実施例では、フェイルオーバ時間を短縮するＬＮＳ装置１０７の例を説明する。本実施形態のＬＮＳ装置１０７の構成は、ＬＡＣ装置１０２とほぼ同じであり、違いは、通信送受信相手が、ＬＡＣ装置１０２では加入者端末１００であったのがＬＮＳ装置１０７ではＬＡＣ装置１０２となり、もう一方の通信送受信相手が、ＬＡＣ装置１０２ではＬＮＳ装置１０７であったのがＬＮＳ装置１０７ではＩＳＰ網１０８となることである。この他の違いは、ＬＮＳ装置１０７ではＬＡＣ装置１０２のように加入者端末１００からの新規セッション接続要求は受けないため、新規セッション接続要求保留部３０８は必要ないことが異なる。

また、ＬＮＳ装置１０７におけるフェイルオーバ方法は、ＬＡＣ装置１０２における実施例１のフェイルオーバ方法（図５）とほぼ同じであり、違いは、ＬＮＳ装置１０７では加入者端末１００からの新規セッション接続要求は受けないため、新規セッション接続要求受付を抑止する処理（ステップ５０２）と新規セッション接続要求受付抑止を解除する処理（ステップ５０８、５１１）が必要ないこと、ＬＮＳ装置１０７のプロトコル処理部３０３が送受信する定期的な生死確認２１８の通信先がＬＡＣ装置１０２になることである。

このように、実施例１〜実施例３では本発明をＬＡＣ装置１０２で実施した場合の実施例を説明したが、本発明はＬＮＳ装置１０７でも実施することができる。上述のように、非特許文献１のトンネル・セッション復旧処理（ステップ５１０）を実施する前にＨｅｌｌｏ送信２１４を実施することで、非特許文献１のトンネル・セッション復旧処理（ステップ５１０）を実施するトンネル数を少なくし、フェイルオーバ時間を短縮することができる。

このように実施例１では、ＬＡＣ装置１０２またはＬＮＳ装置１０７の運用系制御部の故障等が発生し、系切替えが発生した場合、定期的な生死確認において使用されるコントロールメッセージを送信することで復旧が必要なＬ２ＴＰトンネルを選別し、選別したＬ２ＴＰトンネルに上記非特許文献１を適用することで、フェイルオーバ時間を短縮し、インターネット接続サービスを停止することなく継続することができる場合がある。

また、実施例２によると、上記非特許文献１によるＬ２ＴＰトンネル復旧中に復旧対象のＬ２ＴＰトンネルを使用する加入者より新規セッション接続要求を受け付けた場合、該当のＬ２ＴＰトンネルの復旧を優先して復旧させることにより、Ｌ２ＴＰトンネルの切断をなくし、インターネット接続サービスを停止することなく継続することができる場合がある。

本実施例に係るＬＡＣ装置１０２またはＬＮＳ装置１０７は、ＬＡＣ装置またはＬＮＳ装置における運用系制御部の切替が故障等により発生した場合は、運用系制御部と待機系制御部でコントロールメッセージに含まれるＮｓ、Ｎｒの同期が保証されないため、切替後に定期的な生死確認において使用されるコントロールメッセージをＬＮＳ装置またはＬＡＣ装置へ送信し、ＬＮＳ装置またはＬＡＣ装置からの応答の有無により、復旧が必要なＬ２ＴＰトンネルを選別し、復旧するＬ２ＴＰトンネル数を減少させることでフェイルオーバ時間を短縮する。また、ＬＡＣ装置１０２においてＬ２ＴＰトンネル復旧中に復旧対象のＬ２ＴＰトンネルを使用する加入者より新規セッション接続要求を受け付けた場合、該当のＬ２ＴＰトンネルの復旧を優先して復旧させることでＬ２ＴＰトンネル切断によるインターネット接続サービス停止を回避する。

また、ＬＡＣ装置１０２またはＬＮＳ装置１０７は、例えば、ホットスタンバイ形式で二重化された制御部を有し、制御部内には、トンネル・セッション情報を保持するデータベースと、運用状態を監視する監視部と、制御部間で情報を同期するための同期制御部と、制御部の系切り替えが発生した場合は、ＬＮＳ装置またはＬＡＣ装置へ送信したコントロールメッセージの応答の有無によりフェイルオーバ時間を短縮する制御を行うトンネル・セッション管理部を具備する。

また、ＬＡＣ装置１０２は、例えば、ホットスタンバイ形式で二重化された制御部を有し、制御部内には、トンネル・セッション情報を保持するデータベースと、運用状態を監視する監視部と、制御部間で情報を同期するための同期制御部と、制御部の系切り替えが発生した場合のトンネル・セッション情報を復旧している場合に、加入者端末からの新規セッション接続要求は優先的に処理をするトンネル・セッション管理部を具備する。

また、ＬＡＣ装置１０２は、ホットスタンンバイ形式で二重化された制御部を有し、制御部内には、トンネル・セッション情報を保持するデータベースと、運用状態を監視する監視部と、制御部間で情報を同期するための同期制御部と、制御部の系切り替えが発生した場合は、ＬＮＳ装置へ送信したコントロールメッセージの応答の有無によりフェイルオーバ時間を短縮する制御を行うとともに、トンネル・セッション情報を復旧している際に、加入者端末からの新規セッション接続要求は優先的に処理をするトンネル・セッション管理部を具備する。

第１の実施例では、ＬＮＳ装置１０７とＬ２ＴＰトンネル１０６を確立して通信するＬＡＣ装置１０２で、ＬＡＣ装置１０２はＬＮＳ装置１０７と定期的な生死確認において使用されるコントロールメッセージを送受信して非特許文献１のトンネル復旧を実施するか否かを判断するトンネル・セッション情報管理部３０５を内包する第一制御部として運用系制御部１０３を有し、この第一制御部の障害が検出されると現用系に切り替わる待機系の第二制御部として待機系制御部１０４を有し、少なくとも第１制御部の障害を検出する監視部３０６を具備し、運用系制御部１０３が障害を検出し、待機系制御部１０４へ切り替わった後、定期的な生死確認において使用されるコントロールメッセージをＬＮＳ装置１０７に対し全確立済みＬ２ＴＰトンネル１０６毎に送信し、各々の確認応答メッセージの受信を待ち、ＬＮＳ装置１０７からの確認応答メッセージがＬＡＣ装置１０２で受信できなかったり、ＬＮＳ装置１０７からの確認応答メッセージに含まれるシーケンス番号がＬＡＣ装置１０２が期待するシーケンス番号でないＬ２ＴＰトンネル１０６に対してのみ、非特許文献１によるトンネル復旧を実施するＬＡＣ装置１０２を説明した。

第２の実施例では、ＬＮＳ装置１０７とＬ２ＴＰトンネル１０６を確立して通信するＬＡＣ装置１０２で、非特許文献１によるＬ２ＴＰトンネル１０６復旧中に加入者端末１００からの新規セッション接続要求を受け付けた際、使用される当該セッションに必要なＬ２ＴＰトンネル１０６を優先的に復旧するか否かを判断するトンネル・セッション情報管理部３０５を内包する第一制御部として運用系制御部１０３を、第１制御部の障害が検出されると現用系に切り替わる待機系の第２制御部として待機系制御部１０４を、それぞれ備え、さらに、少なくとも第１制御部の障害を検出する監視部３０６を具備し、運用系制御部１０３が障害を検出し、待機系制御部１０４へ切り替わった後、非特許文献１によるＬ２ＴＰトンネル１０６の復旧中に加入者端末１００からの新規セッション接続要求を受け付けた際、新規セッション接続要求が属するＬ２ＴＰトンネル１０６が未復旧の場合、該当Ｌ２ＴＰトンネル１０６を優先的に復旧するＬＡＣ装置１０２を説明した。

第３の実施例では、ＬＮＳ装置１０７とＬ２ＴＰトンネル１０６を確立して通信するＬＡＣ装置１０２において、ＬＡＣ装置１０２はＬＮＳ装置１０７と定期的な生死確認において使用されるコントロールメッセージを送受信して非特許文献１のトンネル復旧を実施するか否かを判断するとともに、非特許文献１によるトンネル復旧中に加入者端末１００からの新規セッション接続要求を受け付けた際、新規セッション接続要求が属するトンネルを優先的に復旧するか否かを判断するトンネル・セッション情報管理部３０５を内包する第一制御部として運用系制御部３０５と、第１制御部の障害が検出されると現用系に切り替わる待機系の第２制御部として待機系制御部１０４と、少なくとも第１制御部の障害を検出する監視部３０６とを具備し、運用系制御部１０３が障害を検出し、待機系制御部１０４へ切り替わった後、定期的な生死確認において使用されるコントロールメッセージをＬＮＳ装置１０７に対し全確立済みトンネル毎に送信し、各々の確認応答メッセージの受信を待ち、ＬＮＳ装置１０７からの確認応答メッセージがＬＡＣ装置１０２で受信できなかったり、ＬＮＳ装置１０７からの確認応答メッセージに含まれるシーケンス番号がＬＡＣ装置１０２が期待するシーケンス番号でないトンネルに対してのみ、非特許文献１によるトンネル復旧を実施するとともに、非特許文献１によるトンネル復旧中に加入者端末１００からの新規セッション接続要求を受け付けた際、新規セッション接続要求が属するトンネルが復旧対象かつ未復旧の場合、該当トンネルを優先的に復旧するＬＡＣ装置を説明した。

１００ 加入者端末
１０１ アクセス網
１０２ ＬＡＣ（Ｌ２ＴＰ Ａｃｃｅｓｓ Ｃｏｎｃｅｎｔｒａｔｏｒ）装置
１０３ 運用系制御部
１０４ 待機系制御部
１０５ 通信事業者ＩＰネットワーク
１０６ Ｌ２ＴＰ（Ｌａｙｅｒ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）トンネル
１０７ ＬＮＳ（Ｌ２ＴＰ Ｎｅｔｗｏｒｋ Ｓｅｒｖｅｒ）装置
１０８ ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｏｒ）網
１０９ インターネット
２０６ ＳＣＣＲＱ（Ｓｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔｉｏｎ−Ｒｅｑｕｅｓｔ）
２０７ ＳＣＣＲＰ（Ｓｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔｉｏｎ−Ｒｅｐｌｙ）
２０８ ＳＣＣＣＮ（Ｓｔａｒｔ−Ｃｏｎｔｒｏｌ−Ｃｏｎｎｅｃｔｉｏｎ−Ｃｏｎｎｅｃｔｅｄ）
２０９、２１３、２１５ ＺＬＢ−ＡＣＫ（Ｚｅｒｏ Ｌｅｎｇｔｈ Ｂｙｔｅ ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）
２１０ ＩＣＲＱ（Ｉｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｒｅｑｕｅｓｔ）
２１１ ＩＣＲＰ（Ｉｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｒｅｐｌｙ）
２１２ ＩＣＣＮ（Ｉｎｃｏｍｉｎｇ−Ｃａｌｌ−Ｃｏｎｎｅｃｔｅｄ）
２１４ Ｈｅｌｌｏ
３００ 中継システム
３０１ 加入者端末１００とＬＡＣ装置１０２、ＬＡＣ装置１０２とＬＮＳ装置１０７のインタフェース送信部・受信部
３０２ ＬＡＣ装置のパケット転送部
３０３ ＬＡＣ装置のプロトコル処理部
３０４ ＬＡＣ装置のトンネル・セッション情報データベース
３０５ ＬＡＣ装置のトンネル・セッション情報管理部
３０６ ＬＡＣ装置の監視部
３０７ ＬＡＣ装置の同期制御部
３０８ ＬＣＡ装置の新規セッション接続要求保留部

Claims (5)

1. 第１の制御部と、前記第１の制御部が機能しないときに代わりに動作する第２の制御部と、を有し、
   前記第２の制御部は、前記第１の制御部がＬＮＳ装置との間で確立している複数のトンネルそれぞれに関するトンネル情報を保持する記憶部を有し、
   前記第１の制御部に代わって前記第２の制御部が動作するときに、前記第２の制御部は、
   前記トンネル情報を参照して、前記第１の制御部が前記トンネルを確立していた前記ＬＮＳ装置に対し生死確認のメッセージを送信し、
   前記生死確認のメッセージに対する応答メッセージを正常に受信できなかった前記ＬＮＳ装置との間で、前記トンネルを復旧するための処理を行ない、
   前記応答メッセージを正常に受信できた前記ＬＮＳ装置との間では前記トンネルを復旧するための処理を行なわないことを特徴とするＬＡＣ装置。
2. 請求項１に記載のＬＡＣ装置であって、
   前記第２の制御部は、前記生死確認のメッセージに自らが付与するシーケンス番号（Ｎｓ）および確認応答番号（Ｎｒ）と、前記ＬＮＳ装置により前記応答メッセージに付与される前記シーケンス番号（Ｎｓ）および前記確認応答番号（Ｎｒ）の値を使用して、前記応答メッセージが正常に受信できたか否かを確認することを特徴とするＬＡＣ装置。
3. 請求項１に記載のＬＡＣ装置であって、
   前記第２の制御部は、前記生死確認のメッセージの送信もしくは前記トンネルの復旧処理をしている間、または前記応答メッセージの受信を待っている間に新たなセッション接続要求を受信すると、
   当該新たなセッション接続要求にかかる前記トンネルの復旧処理が終わっているか否かを確認し、
   当該トンネルの復旧処理が終わっていない場合は、当該トンネルを確立していた前記ＬＮＳ装置に対し生死確認のメッセージを送信し、前記生死確認のメッセージに対する応答メッセージを正常に受信できなかった場合は前記ＬＮＳ装置との間で、当該トンネルを復旧するための処理を行ない、前記応答メッセージを正常に受信できた場合は前記ＬＮＳ装置との間では当該トンネルを復旧するための処理を行なわないことを特徴とするＬＡＣ装置。
4. ＬＡＣ装置に異常もしくは障害が発生して前記ＬＡＣ装置の内部で運用系から待機系への系切り替えが発生したときに、前記ＬＡＣ装置により、前記ＬＡＣ装置との間でＬ２ＴＰトンネルを形成していたＬＮＳ装置へ、生死確認のメッセージを送信し、
   前記ＬＡＣ装置により、前記ＬＮＳ装置から前記生死確認のメッセージに対する応答メッセージを正常に受信できたか否かを確認し、
   前記応答メッセージを正常に受信できなかった場合は前記ＬＮＳ装置との間で前記Ｌ２ＴＰトンネルの復旧処理を前記ＬＡＣ装置により実行し、前記応答メッセージを正常に受信できた場合は前記ＬＡＣ装置による前記復旧処理を実行しないことを特徴とするフェイルオーバ方法。
5. 請求項４に記載のフェイルオーバ方法であって、
   前記ＬＡＣ装置により、前記生死確認のメッセージの送信もしくは前記トンネルの復旧処理をしている間、または前記応答メッセージの受信を待っている間に、新たなセッション接続要求を受信すると
   前記ＬＡＣ装置により、当該新たなセッション接続要求にかかる前記トンネルの復旧処理が終わっているかを確認し、
   当該トンネルの復旧処理が終わっていない場合は、前記ＬＡＣ装置により、当該トンネルを確立していた前記ＬＮＳ装置に対し生死確認のメッセージを送信し、
   前記生死確認のメッセージに対する応答メッセージを正常に受信できなかった場合は、前記ＬＡＣ装置により前記ＬＮＳ装置との間で当該トンネルを復旧するための処理を行ない、前記応答メッセージを正常に受信できた場合は、前記ＬＡＣ装置と前記ＬＮＳ装置との間では当該トンネルを復旧するための処理を行なわないことを特徴とするフェイルオーバ方法。

Images