JP2008263393A

JP2008263393A - ネットワークシステム及びノード装置

Info

Publication number: JP2008263393A
Application number: JP2007104384A
Authority: JP
Inventors: Kazuma Yumoto; 一磨湯本; Hiroshi Masukawa; 博史桝川; Hitoshi Yoshida; 均吉田; Kazuhiro Kusama; 一宏草間; Takuro Mori; 拓郎森
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2007-04-12
Filing date: 2007-04-12
Publication date: 2008-10-30
Anticipated expiration: 2027-04-12
Also published as: US8027246B2; JP4840236B2; US20080253295A1; CN101286899A; CN101286899B

Abstract

【課題】同一の集約リンクに対する障害検知要求がルーティングプロトコル毎に異なる場合にも対応できるように、障害検知プロトコルを適用する。
【解決手段】集約リンクを形成する個々の物理リンクに対して障害検知プロトコルを実行し、集約リンク全体の通信が障害となった場合と、集約リンクを形成する物理リンクの一部が障害となった場合とを区別して、通信路の障害監視要求元である上位アプリケーション（例：ルーティングプロトコル）に対して通知を行う。
【選択図】図２

Description

本発明は、集約リンクに対してトランスポート層の通信プロトコルを用いた障害検知プロトコルを適用する方法に関するものである。

リンク集約化に関する正式な標準として非特許文献１がある。非特許文献１記載の技術を用いることにより、複数の物理リンクの容量を１つの論理リンクとして束ねて帯域幅を増やすことが可能になる。IPv4やIPv6のような、OSI参照モデルのネットワーク層以上に対しては、集約化したリンクが１つのMACであるかのようにみせる。

ネクストホップ間の通信障害を検出するための、ルーティングプロトコルからは独立したプロトコルとして、BFD（Bidirectional Forwarding Detection）の標準化がIETF（Internet Engineering Task Force）で進められている（非特許文献２、３参照）。BFDはUDPを使ってシステム間で定期的なパケットの送受信を行い、一定時間パケットを受信しなかった場合に通信路の障害が発生したものとみなす。BFDは通常ルーティングプロトコルからの要求に基づき通信路の障害監視を実施するが、同一のデータプロトコルパスに対して複数のルーティングプロトコルから障害監視の要求が発生した場合は、単一のBFDセッションで監視を行うことが定められている。

IEEE802.3ad Bidirectional Forwarding Detection, draft-ietf-bfd-base-05, June, 2006 BFD for IPv4 and IPv6 (Single Hop), draft-ietf-bfd-v4v6-1hop-05, June, 2006

BFDのようなレイヤ３以上のプロトコルからみると、集約化されたリンクは１つの通信路として認識される。このように１つの通信路として仮想化されたパスに対してレイヤ３以上の障害検知プロトコルを適用する場合、集約化した全ての物理リンクの通信が障害となった場合には通信不能として検知されるが、集約化した個々の物理リンクの障害を検知することはできない。

BFDに対しては、複数のルーティングプロトコルから同一の集約リンクに対する監視要求が発行される可能性がある。この時、あるルーティングプロトコルは物理リンクが１本でも有効ならば、その通信路を使い続けようとする場合もある。しかし、別のルーティングプロトコルは、集約化された物理リンクの一部に障害が発生し、求める帯域が保証できなくなった場合には、他の帯域が保証される通信経路に切り替えることを望む場合もある。このように、ルーティングプロトコル毎に集約リンクに対する障害検知要求が異なる場合には、現行の仕組みでは対応できないという問題がある。

本発明の一形態では、集約リンクを形成する個々の物理リンクに対して障害検知プロトコルを実行し、集約リンク全体の通信が障害となった場合と、集約リンクを形成する物理リンクの一部が障害となった場合とを区別して、通信路の障害監視要求元である上位アプリケーション（例：ルーティングプロトコル）に対して通知を行う。

本発明の別の形態では、集約リンクを形成する各物理リンクに対し、ラウンドロビンで障害検知プロトコルを流す。本実施形態における障害検知プロトコルとしてBFDを用いる場合は、要求モードまたはエコー機能を使って動作させる。相手システムからの応答が無かった場合は、応答が無かった物理リンクの障害として上位アプリケーションに対して通知を行い、集約リンクを形成する全ての物理リンクが障害となった際に集約リンクの障害として通知を行う。

本発明の集約リンクに対する障害検知プロトコルの適用方式は、集約リンクを形成する各物理リンクを意識して障害検知プロトコルのセッションの確立とパケットの送受信を行うため、通信路の障害を集約リンク全体としてのみならず、集約リンクを形成する各物理リンク単位で識別できるので、集約リンクに対する経路切替条件が異なるルーティングプロトコルからの障害監視要求にも対応できるという利点がある。

図１は、本発明の実施形態であるノード間に集約リンクを適用したシステムの構成例を示す図である。ローカルノード1aとリモートノード1bの間は複数のリンク（図１の例ではリンク１からリンク４の４本のリンク）を集約した集約リンクを通常経路２として設定し運用する。一方、ローカルノード1aとリモートノード1cの間も同じ帯域幅となるように集約リンクを張り、こちらを予備経路３として運用する。

集約リンクを構成するリンクに障害が発生した場合の集約リンクの挙動としては、図16に示すような３通りの挙動が存在する。

図16（a）に示す動作モードでは、集約リンクを構成する全てのリンクが駄目になるまで、その経路（集約リンク）を使い続ける。この場合、通信不能となったリンクを利用していたトラフィックは、有効な残りのリンクに集約される。つまり、集約リンクを構成する物理リンクに障害が発生すると、通信帯域幅は狭まるが、１本でも物理リンクが残っていれば通信経路は変わらずに動作する。

図16（b）に示す動作モードは、集約リンクを構成する物理リンクのうち、設定した数の物理リンクが障害となった場合は、予備経路の集約リンクに通信経路を切り替えるといった挙動を行う。この動作モードでは、最低限維持したい通信帯域を保証するため、最低保証帯域を維持できない数の物理リンクが通信障害となった場合には、通信経路を切り替える。

図16（c）に示す動作モードは、予備の物理リンクを用意しておき、集約リンクを構成する物理リンクに障害が発生した場合には、障害が発生した物理リンクを予備の物理リンクに切り替えて集約リンクを構成し直す。

これら３通りの動作モードは、いずれも経路制御方式（ルーティングプロトコル）の違いに関わらず一律の動作となる。例えばOSPF（Open Shortest Path First）とMPLS（Multi-Protocol Label Switching）では経路の通信帯域に対する要求が異なるケースが想定されるが、従来の方式ではこのような違いにきめ細かく対応することは出来ない。本発明では、集約リンクを構成する物理リンクの障害の度合いに応じて、各ルーティングプロトコルが個別に経路切替の判断をできるようにするための、集約リンクに対する障害検知プロトコルの適用方式を示す。具体的には、図16（a）に示す動作モードのように全ての物理リンクの通信が不能になるまで同じ経路を利用し続けるか、図16（b）に示す動作モードのように最低保証帯域を維持できなくなる数の物理リンクが通信障害となった場合に通信経路を切り替えるかを、各ルーティングプロトコルが判断できるような集約リンクに関する障害通知方法を提供する。

図２は、本発明の実施形態である集約リンクに対する障害検出プロトコル適用方法の一例を示した装置ブロックである。ここでは、ノード装置１の構成要素の中から、本発明と関連する要素のみを抽出して図示している。障害検知プロトコル１０は、ルーティングプロトコル１０など経路制御を行う機能モジュールからの要求により、対象通信路の通信障害を監視する。障害検知プロトコルとしてレイヤ３以上のプロトコルを用いる場合、集約リンクのアグリゲータ15との間には、UDPまたはTCP層12、IP層13、MACクライアント14が介在する。集約リンクはアグリゲータにより仮想化された１つの通信路として認識されるようになるが、実際には複数の物理ポート16により構成される。ここまでの構成は図15に示す従来の構成と変わりは無い。従来の構成では、アグリゲータ15によって集約リンクは上位の通信プロトコル層からは１つの通信路としてみなされるようになるため、障害検知プロトコル11も集約リンクを構成する個々の物理リンクを認識することは出来なかった。本発明では、障害検知プロトコル11の中に新たに集約リンク障害監視通知機能20を設け、集約化システム19の中に新たに物理ポート監視制御機能21を設けることにより、個々の物理リンクを意識した通信路の障害監視が行えるようにする。図２では物理ポート監視制御機能21をアグリゲータ15の中に包含して描いているが、LACP（Link Aggregation Control Protocol）の拡張機能として実装する形でも構わない。

図３は、集約リンク障害監視通知機能20の処理手順の一例を示すフローチャートである。ルーティングプロトコル11から新たな監視要求があった場合（ステップ30）、管理テーブルに当該要求に対する項目を追加する処理を行う（ステップ31）。

ルーティングプロトコル10から障害検知プロトコル11に発行される監視要求命令（ステップ30で障害検知プロトコル11が受け取るメッセージ）の一構成例を図４に示す。また、障害検知プロトコル11の管理テーブルの一構成例を図５と図８に示す。図４、図５、図８に関しては、後に詳細を説明するが、ステップ31で追加する管理テーブルは、図５または図８の（b）に示すテーブルに相当する。

ステップ31で追加する通信経路が集約経路のものである場合が本発明の対象となる。通信経路が集約経路のものであるか否かの検査（ステップ32）は、図５または図８の（a）に示すテーブルを調べる。具体的には、（b）テーブルの宛先論理IPアドレスと合致する値の項目が、（a）テーブルの集約リンク識別子50に存在するか否かを検索する。（b）テーブルはルーティングプロトコルからの要求を管理するテーブルであり、（a）テーブルは集約リンクの構成を管理するテーブルである。（a）テーブルのマスタは集約化システムで持つのが一般的であるため、障害検知プロトコル11では集約化システム内の当該テーブルを参照するか、障害検知プロトコル内に設ける同期されたコピーテーブルを参照する。

ステップ32の検査結果が集約経路のものでは無かった場合は従来どおりの処理を行う（ステップ34）。一方、検査結果が集約経路に該当した場合は、集約リンク管理テーブル（a）の該当するテーブル項目を詳細に調べ（ステップ33）、（b）テーブルの該当テーブル項目を形成する（ステップ35）。具体的には、（a）テーブルの集約リンク検査モード51の値を（b）テーブルの同項目63と同期させる。また、（b）テーブルの物理リンク数65を、（a）テーブルの同項目52と同期させる。集約リンク検査モードは、本発明で拡張する項目であり、コンフィグなどで設定する集約リンク単位での障害検知プロトコルの検査モードを反映する。検査モード（方式）としては、集約リンクを構成する各物理リンクの検査を並列で行うパラレル方式か、集約リンクを構成する各物理リンクの検査を順に行うラウンドロビン方式をとる。パラレル方式は各物理リンクの検査を並列に行うことから、障害検知が早いという利点がある。一方、ラウンドロビン方式はパラレル方式に比べ、集約リンクに対する障害検知のための単位時間当たりの通信量を少なく抑えることが出来るという利点がある。
（b）テーブルの要求元識別子60、宛先論理IPアドレス61、検出モード62は、ルーティングプロトコル10からの監視要求命令の内容から取得する。監視要求命令が図４に示すような構成の場合は、要求元識別子60の値は要求識別子44から、宛先論理IPアドレス61の値はデータ部41内の情報から、検出モード62の値は45から取得する。

ここで図４に示す監視要求命令の構成例を説明しておくと、発信元識別子40は監視要求命令を発行するルーティングプロトコル10の識別子、宛先識別子41は障害検知プロトコル11などルーティングプロトコルからの要求命令の宛先識別子である。ファンクションコード42としては、例えば、監視セッションの確立要求、切断要求、パラメータ変更要求が含まれる。一方、障害検知プロトコル11からルーティングプロトコル10へ通知を行う場合は、発信元識別子40が障害検知プロトコル11の識別子、宛先識別子41がルーティングプロトコル10の識別子となる。この時のファンクションコード42としては、障害通知や監視セッション切断通知などが含まれる。データサイズ43には以降のデータ長を設定する。検出モード45には、全物理ポートが通信障害となった場合に通知を上げるのか、指定した離脱ポート数が通信障害となった場合に通知を上げるのか、集約リンクでは無い通常の監視動作を行うのかといった設定を行う。データ部46は纏めて一括りで示しているが、監視対象となる通信路を特定するための情報（送信元IPアドレス、送信先IPアドレス）や障害検知プロトコルの動作パラメータ（最小送信間隔、最小受信間隔、障害検知乗数）などを設定する。ルーティングプロトコル10と障害検知プロトコル11の間のメッセージ構成で、本発明により拡張される部位は検出モード45である。

再び管理テーブル（b）の説明に戻ると、集約リンクに対する障害検知プロトコルのセッション数64の値は、同テーブルの集約リンク検査モード63の内容に依存する。集約リンク検査モードがパラレル方式の場合のセッション数は物理リンク数65の値と同様になり、ラウンドロビン方式の場合のセッション数は「１」となる。

管理テーブル（c）は障害検知プロトコルの各セッションを管理するテーブルである。管理テーブル（b）のセッション識別子66と状態67は、それぞれ管理テーブル（c）の70と74に相当する。集約リンクの検査モードがパラレル方式の場合の管理テーブル（b）は、図５に示すようにセッション数（64）分のセッション識別子66と状態67の対が並ぶ構成となる。一方、検査モードがラウンドロビン方式の場合は、図８に示すように各物理リンクの状態を示す状態67の項目のみがセッション数（64）分だけ並ぶ構成となる。管理テーブル（c）も従来の構成から拡張することになる。集約リンクを構成する物理リンク数72と物理ポート番号73が本発明により追加される要素である。ここで、パラレル方式の場合は図５に示すように各セッションは物理ポート単位となるが、ラウンドロビン方式の場合の各セッションは集約リンク単位となるため、図８に示すように、セッション毎に物理リンク数（72）分の物理ポート番号73と状態74の対が並ぶ構成となる。セッション関連情報71も纏めて一括りで示しているが、ここには監視要求命令のデータ部46で指定されるようなパラメータが含まれる。

管理テーブルの構成を上記のようにすることにより、検出モード（全ポート／ポート数指定）に応じた通信障害監視を実現する。各物理ポートに通信障害が発生した時の動作を、図１４を用いて説明する。物理ポート監視制御機能21から集約リンク障害監視通知機能20に通知されたメッセージの内容が、通信路の障害通知またはセッション切断通知であった場合（ステップ140）は、管理テーブル（c）の該当セッションおよび該当物理ポート73の状態74を更新する（ステップ141）。管理テーブル（c）の状態74を更新した際は、情報のリンク先である管理テーブル（b）にも通知を行い、該当セッション66の状態67を更新する（ステップ143）。管理テーブル（b）の状態67が更新された時は検出モード62の設定を確認し（ステップ144）、ルーティングプロトコル10に対する障害通知の要否を判定する（ステップ145）。例えば、検出モードの設定が「全ポート」（全物理ポートが通信障害となった場合に通知を上げる）の場合は、全ての状態67項目の内容が「障害」もしくは「切断」となった場合に通知をあげる（ステップ146）。一方、検出モードの設定が「ポート数指定」（指定した離脱ポート数が通信障害となった場合に通知を上げる）の場合は、状態67項目の内容が「障害」もしくは「切断」となった物理ポートの数が、指定されたポート数を超えた場合に通知をあげる（ステップ146）。

再び図３のフローチャートの説明に戻ると、ステップ35でテーブル（特に管理テーブル（b））を構成した後は、対象となる通信路に関する障害検知プロトコルのセッションが既に存在するか否かを判定する（ステップ36）。例えば、対象通信路に関する管理テーブル（c）が既に存在する場合は、セッションが既に存在すると判断することができる。セッションが存在しない場合には新たにセッションを張り、管理テーブル（c）を追加する（ステップ37）。管理テーブル（c）と管理テーブル（b）の間では、相関するセッション情報のリンクをはる（ステップ38）。この後に、要求命令固有の処理を行う（ステップ39）。例えば、コンフィグの設定などが更新された場合などは、監視パラメータの変更などを契機とした要求命令となるが、このような処理はこのタイミングで実施する。

セッションの張り方は、集約リンク検査モードによって異なる。パラレル方式では集約リンクを構成する各物理リンクの検査を並列で行い、ラウンドロビン方式では集約リンクを構成する各物理リンクの検査を順に行う。パラレル方式におけるセッションは各物理リンク単位にはる形となり、ラウンドロビン方式では集約リンクあたり１本のセッションとなる。障害検知プロトコルとしてBFD（Bidirectional Forwarding Detection）を用いる場合のセッション確立手順を図６に、パラレル方式で検査する場合に用いるBFD非同期モードの動作例を図７に、ラウンドロビン方式で検査する場合に用いるBFD要求モードの動作例を図９に示す。 BFDのステートマシンには「Down」「Init」「Up」があり、送信するパケットには自身の状態を含める。自身の状態が「Down」の時に相手の状態が「Down」のパケットを受信（F80）すると、状態は「Init」に遷移する。同様に、自身の状態が「Down」の時に相手の状態が「Init」のパケットを受信（F81）すると、状態は「Up」に遷移する。自身の状態が「Init」の時に相手の状態が「Up」のパケットを受信（F82）すると、状態は「Up」に遷移する。状態が「Up」になった時にセッションは確立される。パラレル方式の場合は各物理リンク単位にセッションをはるため、図６に示すようなセッション確立のための通信は各物理リンク単位に行う。一方、ラウンドロビン方式におけるセッションの確立は集約リンク単位で行う形となるため、F80からF82までの通信は異なる物理リンクで行われることも許容する。

図７では一方向の通信しか図示していないが、実際には反対方向も同様の通信が行われる。セッション確立時に通知し合い調整を行う送信間隔でパケットを送信する（F83、F84、F85）。受信側では、例えば、F83でパケットを受信した後、障害検出時間の間にパケットを受信しなかった場合に通信路の障害とみなす。パラレル方式では、このような監視を物理リンク毎に行う。

図９に示す要求モードの動作では、一方から送ったパケットF86に対して応答F87を返して貰うことを前提として検査を行う。応答F87を受信できなかった場合は、再度送信F88を行っても構わないが、障害検出時間内に応答（F87またはF89）を受信しなかった場合は通信路の障害とみなす。ラウンドロビン方式では、送信パケットに対する応答も同じ物理リンクを使う。応答を受信したら、その物理リンクは正常であると判断し、次の物理リンクの検査に移るという挙動を繰り返す。

図１０は、障害検知プロトコル11からの要求に対する物理ポート監視制御機能21の処理手順の一例を示したフローチャートである。受信命令が障害検知プロトコル11からのものであった場合（ステップ90）は、更に物理ポート番号の指定があるか否かを検査する（ステップ91）。物理ポート番号の指定がある場合は、物理ポートを特定したパケットの送信処理を行い（ステップ92）、物理ポートの指定が無い場合または障害検知プロトコルが発行した命令では無かった場合は、集約リンクを用いた通常のパケット送信処理を行う（ステップ93）。つまり、検査モードに応じてパケットの送出先である物理ポートの指定を行う処理は、障害検知プロトコル11側の集約リンク障害監視通知機能20で行う。

図１１は障害検知プロトコル11とアグリゲータ15の間で用いるメッセージの一構成例を示す図であり、図１２は別の構成例を示す図である。図１１の構成では、送信パケットの構造および内容をデータ部に格納し、これを装置内通信ヘッダでカプセリングする。一方、図１２の構成では、送信パケットの構造で装置内メッセージングも行うモデルとなる。本発明の拡張部位は、物理ポート番号を指定する領域（109または129）と、集約リンク検査モードを指定する領域（118または128）である。100から107の装置内通信ヘッダは、通信路に送り出す際には取り外される。この装置内通信ヘッダは装置内固有のものとなるため、装置内でのメッセージングが成立するならば別の構造をとっても構わない。図１２に示した構成の場合は、送出先の物理ポート番号（129）を送信パケット構造に埋め込んだ形となるが、この情報は装置内でのみ利用する情報となるため、通信路に送り出す際には取り除く。集約リンク検査モード（118または128）は対向装置に対する検査モードの通知として用いるが、装置間で対応する集約リンクの検査モード設定を一致させるならば、省略しても構わない。図１０に示したフローチャートの処理手順のうち、ステップ9１の物理ポート番号指定の検査は、109または129の領域を検査する形となる。ステップ90の要求発行元の検査に関しては、図１１の構成の場合は発信元識別子100を検査し、図１２の構成の場合は宛先ポート124などプロトコル種別を識別できる項目で検査する。

図１３は、リモートノードからパケットを受信した際の物理ポート監視制御機能21の処理手順の一例を示したフローチャートである。集約リンクで受信したパケットの内容が障害検知プロトコルのものであった場合（ステップ130）、受信した物理ポートの情報を付加して（ステップ131）、上位（受信パケットが障害検知プロトコルのパケットであった場合は、障害検知プロトコル11）に通知を行う（ステップ132）。この時の通知命令の構造は、図１１または図１２に示す構造のものを流用すれば良い。

以上のように、本発明では、集約リンク障害監視通知機能20と物理ポート監視制御機能21を新たに設け、管理テーブルの拡張を行うことにより、物理ポートを特定した通信路の障害監視を行うことが出来るようにする。このことにより、集約リンクを構成する物理リンクの一部が通信障害となる場合と、全ての物理リンクが通信障害となる場合とを区別することが出来るようになるため、集約リンクに対する経路切替条件が異なるルーティングプロトコルからの障害監視要求にも対応できるようになる。

本発明の集約リンクに対する障害検知プロトコルの適用方式は、通信路の障害を集約リンク全体としてのみならず、集約リンクを形成する各物理リンク単位で識別できるので、経路切替条件が異なる複数のルーティングプロトコルが集約リンクを使うような運用形態のネットワークシステムおよびネットワーク装置（ノード）の障害検知方式として適用できる。

ノード間に集約リンクを適用したシステムの構成例を示す図である。集約リンクに対する障害検知プロトコルの適用方法の一例を示した装置ブロック図である。ルーティングプロトコルからの要求に対する集約リンク障害監視通知機能の処理手順の一例を示すフローチャートである。ルーティングプロトコルと障害検知プロトコル間で用いるメッセージの一構成例を示す図である。集約リンクを構成する各物理リンクの検査を並列で行う方式における、障害検知プログラムの管理テーブルの一構成例を示す図である。障害検知プロトコルのセッション確立手順の一例を示す図である。全物理リンクを並列で検査する方式で用いる障害検知プロトコルの一動作例を示す図である。集約リンクを構成する各物理リンクの検査をラウンドロビンで行う方式における、障害検知プログラムの管理テーブルの一構成例を示す図である。各物理リンクをラウンドロビンで検査する方式で用いる障害検知プロトコルの一動作例を示す図である。障害検知プロトコルからの要求に対する物理ポート監視制御機能の処理手順の一例を示すフローチャートである。障害検知プロトコルとアグリゲータ間で用いるメッセージの一構成例を示す図である。障害検知プロトコルとアグリゲータ間で用いるメッセージの別の構成例を示す図である。リモートノードからのメッセージを受信した際の物理ポート監視制御機能の処理手順の一例を示すフリーチャートである。物理ポート監視制御機能からのメッセージを受信した際の集約リンク障害監視通知機能の処理手順の一例を示すフローチャートである。集約リンクに対して本発明を適用せずに障害検知プロトコルを実施する場合の装置ブロック構成の一例を示す図である。物理リンクに障害が発生した場合の集約リンクの一般的な挙動例を示す図である。

符号の説明

１ノード装置
１０ルーティングプロトコル
１１障害検知プロトコル
１２ＵＤＰ／ＴＣＰ
１３ＩＰ
１４ＭＡＣクライアント
１５アグリゲータ
１６物理ポート
１９集約化システム
２０集約リンク障害監視通知機能
２１物理ポート監視制御機能。

Claims

集約リンクを形成する複数のノード装置により構成されるネットワークシステムであって、
前記複数のノード装置のうち少なくともいずれか一つは、通信路の障害を監視する障害検知プロトコルを記憶した記憶部と、該障害検知プロトコルを実行する制御部を備え、
前記制御部は、前記障害検知プロトコルを用いて、
前記集約リンクに対する障害監視要求を、該障害監視要求を発行した要求元単位で記憶し、
前記集約リンクに対する障害監視用の通信を、前記集約リンクを構成する複数の物理リンクのそれぞれを特定して行い、
前記集約リンクを構成する物理リンクの通信障害を検知した時は、前記障害監視要求の障害検出通知条件が、前記集約リンクを構成する全物理リンクが通信障害となった時に通知を希望するのか、それとも前記集約リンクを構成する物理リンクのうち指定数の物理リンクが通信障害となった時に通知を希望するのかを判定し、前記障害監視要求に対応する前記障害検出通知条件を満たした時に前記障害監視要求の要求元に障害検出通知を行うことを特徴とするネットワークシステム。
前記集約リンクに対する障害監視用の通信は、前記集約リンクを構成する複数の物理リンクの各々に対して並列に行うことを特徴とする請求項１記載のネットワークシステム。
前記集約リンクに対する障害監視用の通信は、前記集約リンクを構成する複数の物理リンクに対してラウンドロビンで行うことを特徴とする請求項１記載のネットワークシステム。
前記障害検知プロトコルは、トランスポート層の通信プロトコルを利用するプロトコルであることを特徴とする請求項１記載のネットワークシステム。
前記障害検知プロトコルは、BFD（Bidirectional Forwarding Detection）を拡張したものであることを特徴とする請求項１記載のネットワークシステム。
集約リンクを収容するノード装置であって、
通信路の障害を監視する障害検知プロトコルを記憶した記憶部と、該障害検知プロトコルを実行する制御部を備え、
前記制御部は、前記障害検知プロトコルを用いて、
前記集約リンクに対する障害監視要求を、該障害監視要求を発行した要求元単位で記憶し、
前記集約リンクに対する障害監視用の通信を、前記集約リンクを構成する複数の物理リンクのそれぞれを特定して行い、
前記集約リンクを構成する物理リンクの通信障害を検知した時は、前記障害監視要求の障害検出通知条件が、前記集約リンクを構成する全物理リンクが通信障害となった時に通知を希望するのか、それとも前記集約リンクを構成する物理リンクのうち指定数の物理リンクが通信障害となった時に通知を希望するのかを判定し、前記障害監視要求に対応する前記障害検出通知条件を満たした時に前記障害監視要求の要求元に障害検出通知を行うことを特徴とするノード装置。
前記集約リンクに対する障害監視用の通信は、前記集約リンクを構成する複数の物理リンクの各々に対して並列に行うことを特徴とする請求項６記載のノード装置。
前記集約リンクに対する障害監視用の通信は、前記集約リンクを構成する複数の物理リンクに対してラウンドロビンで行うことを特徴とする請求項６記載のノード装置。
前記障害検知プロトコルは、トランスポート層の通信プロトコルを利用するプロトコルであることを特徴とする請求項６記載のノード装置。
前記障害検知プロトコルは、BFD（Bidirectional Forwarding Detection）を拡張したものであることを特徴とする請求項６記載のノード装置。