(57)【要約】【課題】加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型の通信ネットワークを実現する。【解決手段】加入者ユーザ収容ノード１〜４で、単位時間当たりに各転送経路へ出力される転送フレーム数を観測し、任意の転送経路で転送フレーム数がしきい値を超えた際に、転送テーブルを制御して、当該転送経路を使用する宛先ユーザアドレスの任意のエントリに対して、当該転送経路の経路識別子以外の経路識別子を割り当てる。【選択図】  図１
2006005629.tif 000002
【特許請求の範囲】
【請求項１】
複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、前記加入者ユーザ間でユーザデータを格納したフレームを転送する際、前記加入者ユーザ収容ノードで前記経路識別子を用いて前記フレームの転送経路を明示する通信ネットワークであって、
前記加入者ユーザ収容ノードは、
宛先ユーザアドレスに対する宛先加入者ユーザ収容ノードおよび出力先転送経路の経路識別子を導く転送テーブルと、
加入者ユーザから受信したフレームを自身とは異なる加入者ユーザ収容ノードへ送信する際に、当該フレームの宛先ユーザアドレスに応じて前記転送テーブルから得られた経路識別子に基づき出力先転送経路を決定する転送制御部と、
宛先ユーザアドレスと宛先加入者ユーザ収容ノードと経路識別子が同一である各フレームの単位時間当たりに転送した転送フレーム数と、加入者ユーザ収容ノードと経路識別子の対ごとに前記転送フレーム数を合計して得られた合計値とを管理するカウンタテーブルと、
フレーム転送の際、当該フレームから抽出した宛先ユーザアドレス、宛先加入者ユーザ収容ノード、および経路識別子に基づいて、前記カウンタテーブルの該当エントリの前記転送フレーム数および前記合計値をそれぞれ更新するフレームカウント部と、
前記カウンタテーブルにおいて任意の加入者ユーザ収容ノードと経路識別子の対に対する転送フレーム数の合計値がしきい値を超えた場合、当該経路識別子を除く当該加入者ユーザ収容ノード宛の経路識別子のいずれかを前記カウンタテーブルから選択するフィードバック制御部とを備え、
前記転送制御部は、前記転送テーブルのうち、前記合計値がしきい値を超えた前記経路識別子が割り当てられている宛先ユーザアドレスの任意のエントリに対して、前記フィードバック制御部で選択された経路識別子を割り当てることを特徴とする通信ネットワーク。
【請求項２】
請求項１に記載の通信ネットワークにおいて、
前記バックボーンネットワーク内に設けられて前記転送経路間でフレームの転送を行うフレーム転送ノードから、前記転送経路ごとに単位時間当たりに転送したフレームの転送フレーム数を収集し、前記転送経路間で転送フレーム数に差がある場合は、この差が小さくなるよう当該加入者ユーザ収容ノード内の転送テーブルを変更制御するネットワーク制御サーバをさらに備えることを特徴とする通信ネットワーク。
【請求項３】
請求項１または請求項２に記載の通信ネットワークにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いることを特徴とする通信ネットワーク。
【請求項４】
請求項１または請求項２に記載の通信ネットワークにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いることを特徴とする通信ネットワーク。
【請求項５】
請求項１に記載の通信ネットワークにおいて、
前記フィードバック制御部は、前記経路識別子を選択する際、前記カウンタテーブルで管理されている前記加入者ユーザ収容ノードと経路識別子との対のうち当該転送フレーム数の合計値が最小である対の経路識別子を選択することを特徴とする通信ネットワーク。
【請求項６】
請求項１に記載の通信ネットワークにおいて、
前記バックボーンネットワーク内の故障を監視するとともに、故障を検出した場合にその故障の影響を受ける転送経路を特定して前記加入者ユーザ収容ノードへ通知するネットワーク制御サーバをさらに備えることを特徴とする通信ネットワーク。
【請求項７】
請求項６に記載の通信ネットワークにおいて、
前記転送制御部は、フレーム転送の際、当該フレームの転送に用いる転送経路として、前記ネットワーク制御サーバから通知された故障の影響を受ける転送経路とは異なる転送経路を選択することを特徴とする通信ネットワーク。
【請求項８】
請求項１に記載の通信ネットワークにおいて、
前記バックボーンネットワークは、前記各加入者ユーザ収容ノードを接続する仮想プライベートネットワークを複数有し、これら仮想プライベートネットワークごとに物理的に異なる転送経路を設定することを特徴とする通信ネットワーク。
【請求項９】
請求項８に記載の通信ネットワークにおいて、
前記バックボーンネットワークの物理的構造と前記仮想プライベートネットワークの数とに基づいて、前記仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この計算結果に応じてバックボーンネットワーク内に設けられて前記転送経路間でフレームの転送を行うフレーム転送ノードに対し、当該フレーム転送ノードの有する転送テーブルを遠隔設定することにより前記仮想プライベートネットワークごとに物理的に異なる転送経路を設定するネットワーク制御サーバをさらに備えることを特徴とする通信ネットワーク。
【請求項１０】
請求項１に記載の通信ネットワークにおいて、
前記転送制御部は、収容する加入者ユーザから受信したユーザネットワーク形式のフレームを前記バックボーンネットワークへ送信する際、当該フレームを所定のバックボーンネットワーク形式のフレームにカプセル化することを特徴とする通信ネットワーク。
【請求項１１】
複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、前記加入者ユーザ間でユーザデータを格納したフレームを転送する際、前記加入者ユーザ収容ノードで前記経路識別子を用いて前記フレームの転送経路を明示する通信ネットワークで用いられる加入者ユーザ収容ノードであって、
宛先ユーザアドレスに対する宛先加入者ユーザ収容ノードおよび出力先転送経路の経路識別子を導く転送テーブルと、
加入者ユーザから受信したフレームを自身とは異なる加入者ユーザ収容ノードへ送信する際に、当該フレームの宛先ユーザアドレスに応じて前記転送テーブルから得られた経路識別子に基づき出力先転送経路を決定する転送制御部と、
宛先ユーザアドレスと宛先加入者ユーザ収容ノードと経路識別子が同一である各フレームの単位時間当たりに転送した転送フレーム数と、加入者ユーザ収容ノードと経路識別子の対ごとに前記転送フレーム数を合計して得られた合計値とを管理するカウンタテーブルと、
フレーム転送の際、当該フレームから抽出した宛先ユーザアドレス、宛先加入者ユーザ収容ノード、および経路識別子に基づいて、前記カウンタテーブルの該当エントリの前記転送フレーム数および前記合計値をそれぞれ更新するフレームカウント部と、
前記カウンタテーブルにおいて任意の加入者ユーザ収容ノードと経路識別子の対に対する転送フレーム数の合計値がしきい値を超えた場合、当該経路識別子を除く当該加入者ユーザ収容ノード宛の経路識別子のいずれかを前記カウンタテーブルから選択するフィードバック制御部とを備え、
前記転送制御部は、前記転送テーブルのうち、前記合計値がしきい値を超えた前記経路識別子が割り当てられている宛先ユーザアドレスの任意のエントリに対して、前記フィードバック制御部で選択された経路識別子を割り当てることを特徴とする加入者ユーザ収容ノード。
【請求項１２】
請求項１１に記載の加入者ユーザ収容ノードにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いることを特徴とする加入者ユーザ収容ノード。
【請求項１３】
請求項１１に記載の加入者ユーザ収容ノードにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いることを特徴とする加入者ユーザ収容ノード。
【請求項１４】
請求項１１に記載の加入者ユーザ収容ノードにおいて、
前記フィードバック制御部は、前記経路識別子を選択する際、前記カウンタテーブルで管理されている前記加入者ユーザ収容ノードと経路識別子との対のうち当該転送フレーム数の合計値が最小である対の経路識別子を選択することを特徴とする加入者ユーザ収容ノード。
【請求項１５】
請求項１１に記載の加入者ユーザ収容ノードにおいて、
前記転送制御部は、収容する加入者ユーザから受信したユーザネットワーク形式のフレームを前記バックボーンネットワークへ送信する際、当該フレームを所定のバックボーンネットワーク形式のフレームにカプセル化することを特徴とする加入者ユーザ収容ノード。
【請求項１６】
複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、前記加入者ユーザ間でユーザデータを格納したフレームを転送する際、前記加入者ユーザ収容ノードで前記経路識別子を用いて前記フレームの転送経路を明示する通信ネットワークで用いられ、前記加入者ユーザノードでの経路選択を制御するネットワーク制御サーバであって、
前記バックボーンネットワーク内に設けられて前記転送経路間でフレームの転送を行うフレーム転送ノードから、前記転送経路ごとに単位時間当たりに転送したフレームの転送フレーム数を収集するトラヒック情報授受部と、
前記転送経路間で転送フレーム数に差がある場合は、この差が小さくなるよう当該加入者ユーザ収容ノード内の転送テーブルを変更制御する負荷分散計算部とを備えることを特徴とするネットワーク制御サーバ。
【請求項１７】
請求項１６に記載のネットワーク制御サーバにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いることを特徴とするネットワーク制御サーバ。
【請求項１８】
請求項１６に記載のネットワーク制御サーバにおいて、
前記転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いることを特徴とするネットワーク制御サーバ。
【請求項１９】
請求項１６に記載のネットワーク制御サーバにおいて、
前記負荷分散計算部は、前記バックボーンネットワーク内の故障を監視するとともに、故障を検出した場合にその故障の影響を受ける転送経路を特定して前記加入者ユーザ収容ノードへ通知することを特徴とするネットワーク制御サーバ。
【請求項２０】
請求項１６に記載のネットワーク制御サーバにおいて、
前記負荷分散計算部は、前記バックボーンネットワークの物理的構造と前記仮想プライベートネットワークの数とに基づいて、前記仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この計算結果に応じてバックボーンネットワーク内に設けられて前記転送経路間でフレームの転送を行うフレーム転送ノードに対し、当該フレーム転送ノードの有する転送テーブルを遠隔設定することにより前記仮想プライベートネットワークごとに物理的に異なる転送経路を設定することを特徴とするネットワーク制御サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信ネットワークの経路制御技術に関し、特にネットワーク内のトラヒックの流れを制御することによりネットワークの高信頼化および最適化を実現するトラヒックエンジニアリングに関する。
【背景技術】
【０００２】
インターネットに代表されるＩＰネットワークでは、従来より、加入者ユーザ間のデータ通信サービスとして、当該加入者ユーザ間を最短経路でルーチングし、ネットワークの混雑時にはスループットを保証しないベストエフォート型の通信サービスが提供されている。
ベストエフォート型の通信サービスでは、最短経路ベースのルーチングで、加入者ユーザ間を結ぶ経路として必要最低限の最短経路を選択することにより、ネットワーク資源の消費を抑制しつつ到達性を確保している。
【０００３】
しかし、このような最短経路ベースのルーチングでは、経路選択の際にトラヒックを考慮していないため、例えば多数のユーザＩＰフローが任意の経路に集中して輻輳が発生する可能性があるなど、データ通信に対する信頼性や通信品質は低いものであった。
この問題を解決するための技術として、ネットワーク内のトラヒックの流れを制御することによりネットワークの高信頼化および最適化を実現するトラヒックエンジニアリングが検討されている。
【０００４】
このようなトラヒックエンジニアリングを採用したＩＰネットワークでは、加入者ユーザ間のデータ通信に対し、その使用帯域に応じて転送経路を割り当てるものとなっている。すなわち、ＩＰネットワーク上の各フレーム転送ノードにおいて、同一宛先に対して複数の転送方路を予め用意しておき、特定の転送方路で輻輳および故障を検出した際は、該当経路の代替経路へユーザデータを格納したフレームを転送するものである。
この技術により、トラヒックを各経路に分散させることが可能となり、データ通信に対する信頼性や通信品質を向上させることが可能となる。
【０００５】
なお、出願人は、本明細書に記載した先行技術文献情報で特定される先行技術文献以外には、本発明に関連する先行技術文献を出願時までに発見するには至らなかった。
【非特許文献１】Yuuichi Naruse et,al.「IP-in-IPv6 0verlay Networking Technology for a Terabit Class Super-network」,NTT Technical Review,VOL.2,NO.3 Mar.2004 2003
【非特許文献２】Kenichi Matsui et,al.「Cut through Optical Path Control Technology for a Terabit Class Super-network」,NTT Technical Review,VOL.2,NO.3 Mar.2004 2003
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、このような従来のトラヒックエンジニアリングでは、加入者ユーザ間のデータ通信に対して転送経路を割り当てる際に、それぞれのデータ通信の使用帯域しか考慮していないため、場合によっては所望の信頼性が得られないという問題点があった。
例えば、複数ユーザが複数アプリケーションを同時に使用したことに起因して、ＶｏＩＰ（Voice over IP）のようなフレーム長が比較的短いＩＰフローと比較的フレーム長の長いＩＰフローとが混在する状況で、従来のトラヒックエンジニアリングにより、複数の経路に均一にトラヒック量を割り振った場合、いずれかの経路にフレーム長が短いユーザフレームが集中するという偏りが生じる。
【０００７】
この際、フレーム転送装置のプロセッサでの処理負荷は、トラヒック量だけでなくフレーム数の増減にも影響を受けるため、当該経路上に設置されたフレーム転送装置では、他の経路と比較して多数のフレームを処理しなければならなくなり、プロセッサの処理能力を超過するフレーム数を受信する可能性がある。したがって、処理負荷がプロセッサの処理能力より大きくなった場合は、フレームが廃棄されてしまい、その結果、ユーザ間の通信に影響を与えてしまうという問題があった。
【０００８】
本発明はこのような課題を解決するためのものであり、加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型通信ネットワーク、加入者ユーザ収容ノード、およびネットワーク制御サーバを提供することを目的としている。
【課題を解決するための手段】
【０００９】
このような目的を達成するために、本発明にかかる通信ネットワークは、複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、加入者ユーザ間でユーザデータを格納したフレームを転送する際、加入者ユーザ収容ノードで経路識別子を用いてフレームの転送経路を明示する通信ネットワークであって、加入者ユーザ収容ノードに、宛先ユーザアドレスに対する宛先加入者ユーザ収容ノードおよび出力先転送経路の経路識別子を導く転送テーブルと、加入者ユーザから受信したフレームを自身とは異なる加入者ユーザ収容ノードへ送信する際に、当該フレームの宛先ユーザアドレスに応じて転送テーブルから得られた経路識別子に基づき出力先転送経路を決定する転送制御部とを備えるものである。
【００１０】
そして、宛先ユーザアドレスと宛先加入者ユーザ収容ノードと経路識別子が同一である各フレームの単位時間当たりに転送した転送フレーム数と、加入者ユーザ収容ノードと経路識別子の対ごとに転送フレーム数を合計して得られた合計値とを管理するカウンタテーブルと、フレーム転送の際、当該フレームから抽出した宛先ユーザアドレス、宛先加入者ユーザ収容ノード、および経路識別子に基づいて、カウンタテーブルの該当エントリの転送フレーム数および合計値をそれぞれ更新するフレームカウント部と、カウンタテーブルにおいて任意の加入者ユーザ収容ノードと経路識別子の対に対する転送フレーム数の合計値がしきい値を超えた場合、当該経路識別子を除く当該加入者ユーザ収容ノード宛の経路識別子のいずれかをカウンタテーブルから選択するフィードバック制御部とを設け、転送制御部で、転送テーブルのうち、合計値がしきい値を超えた経路識別子が割り当てられている宛先ユーザアドレスの任意のエントリに対して、フィードバック制御部で選択された経路識別子を割り当てるようにしたものである。
【００１１】
この際、バックボーンネットワーク内に設けられて転送経路間でフレームの転送を行うフレーム転送ノードから、転送経路ごとに単位時間当たりに転送したフレームの転送フレーム数を収集し、転送経路間で転送フレーム数に差がある場合は、この差が小さくなるよう当該加入者ユーザ収容ノード内の転送テーブルを変更制御するネットワーク制御サーバをさらに設けてもよい。
【００１２】
また、転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いてもよく、あるいは転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いてもよい。
【００１３】
また、フィードバック制御部で、経路識別子を選択する際、カウンタテーブルで管理されている加入者ユーザ収容ノードと経路識別子との対のうち当該転送フレーム数の合計値が最小である対の経路識別子を選択するようにしてもよい。
【００１４】
また、バックボーンネットワーク内の故障を監視するとともに、故障を検出した場合にその故障の影響を受ける転送経路を特定して加入者ユーザ収容ノードへ通知するネットワーク制御サーバをさらに設けてもよい。
【００１５】
この際、転送制御部で、フレーム転送の際、当該フレームの転送に用いる転送経路として、ネットワーク制御サーバから通知された故障の影響を受ける転送経路とは異なる転送経路を選択するようにしてもよい。
【００１６】
また、バックボーンネットワークに、各加入者ユーザ収容ノードを接続する仮想プライベートネットワークを複数設け、これら仮想プライベートネットワークごとに物理的に異なる転送経路を設定するようにしてもよい。
【００１７】
また、バックボーンネットワークの物理的構造と仮想プライベートネットワークの数とに基づいて、仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この計算結果に応じてバックボーンネットワーク内に設けられて転送経路間でフレームの転送を行うフレーム転送ノードに対し、当該フレーム転送ノードの有する転送テーブルを遠隔設定することにより仮想プライベートネットワークごとに物理的に異なる転送経路を設定するネットワーク制御サーバをさらに設けてもよい。
【００１８】
また、転送制御部で、収容する加入者ユーザから受信したユーザネットワーク形式のフレームをバックボーンネットワークへ送信する際、当該フレームを所定のバックボーンネットワーク形式のフレームにカプセル化するようにしてもよい。
【００１９】
また、本発明にかかる加入者ユーザ収容ノードは、複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、加入者ユーザ間でユーザデータを格納したフレームを転送する際、加入者ユーザ収容ノードで経路識別子を用いてフレームの転送経路を明示する通信ネットワークで用いられる加入者ユーザ収容ノードであって、宛先ユーザアドレスに対する宛先加入者ユーザ収容ノードおよび出力先転送経路の経路識別子を導く転送テーブルと、加入者ユーザから受信したフレームを自身とは異なる加入者ユーザ収容ノードへ送信する際に、当該フレームの宛先ユーザアドレスに応じて転送テーブルから得られた経路識別子に基づき出力先転送経路を決定する転送制御部とを備えるものである。
【００２０】
そして、宛先ユーザアドレスと宛先加入者ユーザ収容ノードと経路識別子が同一である各フレームの単位時間当たりに転送した転送フレーム数と、加入者ユーザ収容ノードと経路識別子の対ごとに転送フレーム数を合計して得られた合計値とを管理するカウンタテーブルと、フレーム転送の際、当該フレームから抽出した宛先ユーザアドレス、宛先加入者ユーザ収容ノード、および経路識別子に基づいて、カウンタテーブルの該当エントリの転送フレーム数および合計値をそれぞれ更新するフレームカウント部と、カウンタテーブルにおいて任意の加入者ユーザ収容ノードと経路識別子の対に対する転送フレーム数の合計値がしきい値を超えた場合、当該経路識別子を除く当該加入者ユーザ収容ノード宛の経路識別子のいずれかをカウンタテーブルから選択するフィードバック制御部とを設け、転送制御部で、転送テーブルのうち、合計値がしきい値を超えた経路識別子が割り当てられている宛先ユーザアドレスの任意のエントリに対して、フィードバック制御部で選択された経路識別子を割り当てるようにしてもよい。
【００２１】
この際、転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いてもよく、あるいは、転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いてもよい。
【００２２】
また、フィードバック制御部で、経路識別子を選択する際、カウンタテーブルで管理されている加入者ユーザ収容ノードと経路識別子との対のうち当該転送フレーム数の合計値が最小である対の経路識別子を選択するようにしてもよい。
【００２３】
また、転送制御部で、収容する加入者ユーザから受信したユーザネットワーク形式のフレームをバックボーンネットワークへ送信する際、当該フレームを所定のバックボーンネットワーク形式のフレームにカプセル化するようにしてもよい。
【００２４】
また、本発明にかかるネットワーク制御サーバは、複数の加入者ユーザを収容する加入者ユーザ収容ノード間を、それぞれ固有の経路識別子が付与されている複数の転送経路を用いて網状に接続することによりバックボーンネットワークを構成し、加入者ユーザ間でユーザデータを格納したフレームを転送する際、加入者ユーザ収容ノードで経路識別子を用いてフレームの転送経路を明示する通信ネットワークで用いられ、加入者ユーザノードでの経路選択を制御するネットワーク制御サーバであって、バックボーンネットワーク内に設けられて転送経路間でフレームの転送を行うフレーム転送ノードから、転送経路ごとに単位時間当たりに転送したフレームの転送フレーム数を収集するトラヒック情報授受部と、転送経路間で転送フレーム数に差がある場合は、この差が小さくなるよう当該加入者ユーザ収容ノード内の転送テーブルを変更制御する負荷分散計算部とを設けたものである。
【００２５】
この際、転送フレーム数に代えて、単位時間当たりに転送したフレームの長さを示す総フレーム長を用いてもよく、あるいは、転送フレーム数に代えて、単位時間当たりに転送した転送フレーム数と単位時間当たりに転送した総フレーム長とを合成して得られる負荷値を用いるようにしてもよい。
【００２６】
また、負荷分散計算部で、バックボーンネットワーク内の故障を監視するとともに、故障を検出した場合にその故障の影響を受ける転送経路を特定して加入者ユーザ収容ノードへ通知するようにしてもよい。
【００２７】
また、負荷分散計算部で、バックボーンネットワークの物理的構造と仮想プライベートネットワークの数とに基づいて、仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この計算結果に応じてバックボーンネットワーク内に設けられて転送経路間でフレームの転送を行うフレーム転送ノードに対し、当該フレーム転送ノードの有する転送テーブルを遠隔設定することにより仮想プライベートネットワークごとに物理的に異なる転送経路を設定するようにしてもよい。
【発明の効果】
【００２８】
本発明によれば、任意の転送経路で転送フレーム数がしきい値を超えた際に、転送テーブルが制御されて、当該転送経路を利用する宛先ユーザアドレスの任意のエントリに対して、当該転送経路の経路識別子以外の経路識別子が割り当てられるため、単位時間当たりに転送した転送フレーム数を考慮したトラヒックエンジニアリングを実現できる。
【００２９】
これにより、例えば複数ユーザが複数アプリケーションを同時に使用したことに起因して、ＶｏＩＰのようなフレーム長が比較的短いＩＰフローと比較的フレーム長の長いＩＰフローとが混在する状況では、従来のトラヒックエンジニアリングのように使用帯域に基づき複数の経路に均一にトラヒック量を割り振った場合、いずれかの経路にフレーム長が短いフレームが集中するという偏りを生じる可能性があるが、本実施の形態によれば、各経路上に位置するフレーム転送ノードのプロセッサでの処理負荷を正確に把握でき、このような偏り発生を確実に回避することができる。
【００３０】
したがって、各フレーム転送ノードのプロセッサでの処理負荷をより正確に均一化することができ、さらには輻輳時や故障時の経路切替を迅速に行うことができるため、結果として、加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型の通信ネットワークを実現できる。
【発明を実施するための最良の形態】
【００３１】
次に、本発明の実施の形態について図面を参照して説明する。
［第１の実施の形態］
まず、図１を参照して、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークについて説明する。図１は本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークのネットワークモデルを示すブロック図である。
この通信ネットワークは、加入者ユーザ収容ノード１〜４、フレーム転送装置６〜９、およびこれらを制御するネットワーク制御サーバ５から構成されている。
【００３２】
各端末１０〜１７は、各ユーザ網１８〜２１を経由して加入者ユーザ収容ノード１〜４に収容されている。加入者ユーザ収容ノード１〜４間は、フレーム転送装置６〜９によって接続されている。
これら加入者ユーザ収容ノード１〜４とフレーム転送装置６〜９から構成されるバックボーンネットワークをコアネットワーク２２とし、端末１０〜１７を含むネットワークをユーザネットワーク２３とする。
【００３３】
［物理モデル］
次に、図２を参照して、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの物理モデルについて説明する。図２は、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの物理モデル例である。
【００３４】
図２の物理モデル例に示すように、加入者ユーザ収容ノード１〜４間は、複数の転送経路を用いて接続されている。
例えば、加入者ユーザ収容ノード１と加入者ユーザ収容ノード３は、リンク１０１−フレーム転送装置６−リンク１０９からなる転送経路と、リンク１０２−フレーム転送装置７−リンク１１０からなる転送経路と、リンク１０３−フレーム転送装置８−リンク１１１からなる転送経路と、リンク１０４−フレーム転送装置９−リンク１１２からなる転送経路により、並列的に接続されている。
【００３５】
この際、それぞれの経路には、その経路を識別するための経路識別子が予め付与される。
例えば、本実施の形態では、リンク１０１−フレーム転送装置６−リンク１０９からなる転送経路には経路識別子Ｒ１を付与することとする。同様にして、リンク１０２−フレーム転送装置７−リンク１１０からなる転送経路には経路識別子Ｒ２を付与し、リンク１０３−フレーム転送装置８−リンク１１１からなる転送経路には経路識別子Ｒ３を付与し、リンク１０４−フレーム転送装置９−リンク１１２からなる転送経路には経路識別子Ｒ４を付与することとする。
【００３６】
ネットワーク制御サーバ５は、リンク１１７〜１２４を介して当該コアネットワーク２２内の各ノードや各装置と接続されている。
すなわち、ネットワーク制御サーバ５は、リンク１１７〜１２０を介してそれぞれ加入者ユーザ収容ノード１〜４と接続され、リンク１２１〜１２４を介してそれぞれフレーム転送装置６〜９と接続されている。
【００３７】
本実施の形態では、これらリンク１１７〜１２４により、各装置との接続性を確保している。これにより、リンク断や装置輻輳などの物理的な原因による輻輳および故障を・出力先の転送経路を切り替えることによって回避することが可能となる。また、ネットワーク制御サーバ５による集中管理型および集中制御型のトラヒックエンジニアリングが実現可能となる。さらに、ネットワーク制御サーバ５によるネットワーク状態の集中管理を実現でき、その結果、故障検出および故障に影響を受ける全経路を特定することが可能となる。
【００３８】
［論理モデル］
次に、図３を参照して、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの論理モデルについて説明する。図３は、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの論理モデル例である。
【００３９】
本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークでは、バックボーンネットワーク内に、すべての加入者ユーザ収容ノードを接続する仮想プライベートネットワークを複数構築し、仮想プライベートネットワークごとに、物理的に異なる転送経路を設定することが考えられる。
【００４０】
図３の論理モデル例では、フレーム転送装置６経由の転送経路を仮想プライベートネットワークＶＰＮ＃１で構成し、フレーム転送装置７経由の転送経路を仮想プライベートネットワークＶＰＮ＃２で構成し、フレーム転送装置８経由の転送経路を仮想プライベートネットワークＶＰＮ＃３で構成し、フレーム転送装置９経由の転送経路を仮想プライベートネットワークＶＰＮ＃４で構成している。
これにより、リンク断や装置輻輳などの物理的な原因による輻輳および故障が発生した場合でも、出力先の仮想プライベートネットワークを切り替えることによって上記障害を回避することが可能となる。
【００４１】
［加入者ユーザ収容ノード］
次に、図４を参照して、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークで用いられる加入者ユーザ収容ノードについて詳細に説明する。図４は、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークで用いられる加入者ユーザ収容ノードの構成を示すブロック図である。
【００４２】
加入者ユーザ収容ノード１〜４は、入力インターフェース部（以下、入力ＩＦ部という）２５、転送制御部２６、負荷観測部２７、出力インターフェース部（以下、出力ＩＦ部という）２８、およびサーバインターフェース部（以下、サーバＩＦ部という）２９で構成されている。
【００４３】
［入力ＩＦ部］
入力ＩＦ部２５は、生存性応答部３０を有している。この生存性応答部３０は、他の加入者ユーザ収容ノードからＩＣＭＰ（Internet Control Message Protocol）のＰｉｎｇ応答要求パケットを受信した際に、送信元に対してＰｉｎｇ応答を返信する機能を有している。
【００４４】
入力ＩＦ部２５は、受信したフレームのヘッダ領域がコアアドレスであった場合、そのフレームをコアネットワーク２２上でやり取りされるコアフレームであると判断し、デカプセル化してユーザフレームを抽出し、そのユーザフレームを転送制御部２６へ転送する機能と、受信したフレームのヘッダ領域がユーザアドレスであった場合、そのフレームをユーザ網でやり取りされるユーザフレームであると判断し、転送制御部２６へ転送する機能と、生存性応答部３０を用いて他加入者収容ノードからのＰｉｎｇ応答要求に対してＰｉｎｇ応答を返信する機能とを有している。
【００４５】
［転送制御部］
転送制御部２６は、転送テーブル３１を有している。この転送テーブル３１は、宛先特定テーブル３２、経路特定テーブル３３を有している。
宛先特定テーブル３２は、フレームの宛先ユーザアドレスから、宛先ユーザを収容している加入者ユーザ収容ノードを特定する機能を有している。
経路特定テーブル３３は、フレームの宛先ユーザアドレスから、出力先の経路識別子を導く機能を有している。
【００４６】
コアネットワーク２２内では、宛先加入者ユーザ収容ノードのアドレスと、経路識別子とからなるコアアドレスを用いて転送が行われる。
転送制御部２６は、受信したユーザフレームの宛先ユーザアドレスから、宛先ユーザを収容している加入者ユーザ収容ノードのアドレスを特定する。一方、特定した加入者ユーザ収容ノードのアドレスが自身の有するアドレスでなかった際は、受信したユーザフレームの宛先ユーザアドレスから、出力先の経路識別子を決定し、特定した加入者ユーザ収容ノードのアドレスおよび経路識別子から宛先コアアドレスを決定し、自身が有するアドレスを送信元アドレスとしてコアヘッダを生成し、そのコアヘッダをユーザフレームに付与することでユーザフレームをコアフレームにカプセル化した後、負荷観測部２７に送信する。
【００４７】
一方、転送制御部２６は、特定した加入者ユーザ収容ノードが自身であった際は、そのユーザフレームを出力ＩＦ部２８に送信する。
また、転送制御部２６は、経路特定テーブル３３に記述されている、任意の宛先ユーザアドレスに対する経路識別子を変更するよう、後に説明する負荷観測部２７のフィードバック制御部３７から指示された際、指示された宛先ユーザアドレスを検索キーとして経路特定テーブル３３を検索し、ヒットしたエントリの経路識別子を、フィードバック制御部３７から指定された経路識別子に書き換える。この書き換えは、エントリの追加および削除により実現することが可能である。
【００４８】
また、転送制御部２６は、ネットワーク制御サーバ５から、宛先特定テーブル３２、経路特定テーブル３３のＳＮＭＰ（Simple Network Management Protocol）参照要求を受信した際に、ＳＮＭＰ参照応答を返信する機能を有している。
また、転送制御部２６は、ネットワーク制御サーバ５から、宛先特定テーブル３２に記述された宛先加入者ユーザ収容ノードのアドレスを変更するためのＳＮＭＰ設定要求を受信した際、その要求に従って、該当エントリの宛先加入者ユーザ収容ノードのアドレスを追加および削除する。同様に、ネットワーク制御サーバ５から、経路特定テーブル３３に記述された経路識別子を変更するためのＳＮＭＰ設定要求を受信した際には、その要求に従って、該当エントリの経路識別子を追加および削除する。
【００４９】
［負荷観測部］
負荷観測部２７は、フレームカウント部３４、総フレーム長観測部３５、負荷値計算部３６およびフィードバック制御部３７を有している。
フレームカウント部３４は、カウンタテーブル３８を有している。
カウンタテーブル３８は、宛先ユーザアドレスおよび宛先コアアドレスに対する通過フレーム数を導く機能と、宛先コアアドレスに対する通過フレーム総数を導く機能とを有している。
【００５０】
フレームカウント部３４は、宛先ユーザアドレスおよび宛先コアアドレスに対する通過フレーム数をカウントすると同時に、宛先コアアドレスに対する通過フレーム総数をカウントする。そして、任意の宛先コアアドレスに対する通過フレーム総数がしきい値を超えた際に、カウント値がしきい値を超えた宛先コアアドレスに記述された宛先加入者ユーザ収容ノードのアドレスが同一で経路識別子のみが異なる各宛先コアアドレス、それらとともにカウンタテーブル３８に記述されていた宛先ユーザアドレス、およびそれらの対に対するカウント値をフィードバック制御部に送信する。なお、しきい値はエントリごとに個別に設けられている。
【００５１】
総フレーム長観測部３５は、帯域観測テーブル３９を有している。
この帯域観測テーブル３９は、宛先ユーザアドレスおよび宛先コアアドレスに対する通過フレームのフレーム長の合計値を導く機能と、宛先コアアドレスに対する総フレーム長の合計値を導く機能とを有している。
【００５２】
総フレーム長観測部３５は、宛先ユーザアドレスおよび宛先コアアドレスに対する通過フレームのフレーム長の合計値をカウントすると同時に、宛先コアアドレスに対する総フレーム長の合計値をカウントする。そして、任意の宛先コアアドレスに対する総フレーム長の合計値がしきい値を超えた際は、カウント値がしきい値を超えた宛先コアアドレスに記述された宛先加入者ユーザ収容ノードのアドレスが同一で経路識別子のみが異なる各宛先コアアドレス、これら宛先コアアドレスとともに帯域観測テーブル３９に記述されていた宛先ユーザアドレス、およびこれらの対に対するフレーム長の合計値をフィードバック制御部に送信する。なお、しきい値はエントリごとに個別に設けられている。
【００５３】
負荷値計算部３６は、負荷値管理テーブル４０を有している。
負荷値管理テーブル４０は、宛先ユーザアドレスおよび宛先コアアドレスに対する負荷値を導く機能と、宛先コアアドレスに対する合計負荷値を導く機能とを有している。
【００５４】
負荷値計算部３６は、フレームカウント部３４および総フレーム長観測部３５を定期的に参照し、宛先ユーザアドレスおよび宛先コアアドレスに対する通過フレーム数および通過フレームのフレーム長の合計値を獲得し、それらを入力として演算処理を施し、出力値を負荷値と定義することにより、宛先ユーザアドレスおよび宛先コアアドレスに対する負荷値を算出して負荷値管理テーブル４０に記述する機能と、宛先コアアドレスごとに負荷値を合計し、負荷値管理テーブル４０に記述する機能とを有している。
【００５５】
また、任意の宛先コアアドレスに対する合計負荷値がしきい値を超えた際、負荷値がしきい値を超えた宛先コアアドレスに記述された宛先加入者ユーザ収容ノードのアドレスが同一で経路識別子のみが異なる各宛先コアアドレス、それらともに負荷値管理テーブル４０に記述されていた宛先ユーザアドレス、およびそれらの対に対する負荷値をフィードバック制御部に送信する機能を有している。なお、しきい値はエントリごとに個別に設けられている。
【００５６】
フィードバック制御部３７は、フレームカウント部３４、総フレーム長観測部３５、負荷値計算部３６から、カウント値、フレーム長の合計値、負荷値がしきい値を超えた宛先コアアドレスに記述された宛先加入者ユーザ収容ノードのアドレスが同一で経路識別子のみが異なる各宛先コアアドレス、これら宛先コアアドレスとともに各テーブルに記述されていた宛先ユーザアドレス、および、これらの対に対するカウント値、フレーム長の合計値、負荷値を通知された際に、カウント値、フレーム長の合計値、負荷値が最小である宛先コアアドレスと宛先ユーザアドレスの対を抽出し、その宛先コアアドレスに記述されている宛先加入者ユーザ収容ノードのアドレスと経路識別子を抽出する。
【００５７】
そして、転送制御部２６に対して、カウント値、フレーム長の合計値、負荷値がしきい値を超えた宛先ユーザアドレスと宛先加入者ユーザ収容ノードの対に割り当てる経路識別子を、同一の宛先ユーザアドレスと宛先加入者ユーザ収容ノードの対を持ち、かつカウント値、フレーム長の合計値、負荷値が最小であった経路識別子に変更するよう指示する。これと同時に、カウンタテーブル３８、帯域観測テーブル３９、負荷値管理テーブル４０において、カウント値、フレーム長の合計値、負荷値がしきい値を超えた宛先ユーザアドレスと宛先加入者ユーザ収容ノードの対に付与されている経路識別子を、変更後のものに再設定する。
【００５８】
負荷観測部２７は、フィードバック制御部３７に入力すべきデータとして、フレームカウント部３４のデータか、総フレーム長観測部３５のデータか、負荷値計算部３６のデータかのいずれか一つを有効化させ、他のデータをフィードバック制御部３７に入力させない機能を有している。
また、ネットワーク制御サーバ５から、カウンタテーブル３８、帯域観測テーブル３９および負荷値管理テーブル４０のＳＮＭＰ参照要求を受信した際に、ＳＮＭＰ参照応答を返信すると同時に各テーブルのカウンタ値をリセットする機能を有している。
【００５９】
［出力ＩＦ部］
出力ＩＦ部２８は、出力リンク特定テーブル４１および生存性確認部４２を有している。出力リンク特定テーブル４１は、フレームのヘッダ領域に記述された宛先アドレスから、出力リンクを特定する機能を有している。
【００６０】
ヘッダ領域がコアヘッダである場合、フレームはコアネットワークへ出力される。ヘッダ領域がユーザヘッダである場合、フレームはユーザネットワークへ出力される。
生存性確認部４２は、生存性確認テーブル４３を有している。生存性確認テーブル４３は、各加入者ユーザ収容ノードのアドレスと経路識別子から、タイマーおよび生存性確認を示すフラグを導く機能を有する。
【００６１】
生存性確認部４２は、各加入者ユーザ収容ノードに対し、各転送経路を使用して、定期的にＰｉｎｇ応答要求を送信し、定期的にＰｉｎｇ応答を受信しているか否かを管理する機能と、定期的なＰｉｎｇ応答が確認できなかった際に、該当加入者ユーザ収容ノードおよび経路識別子をネットワーク制御サーバ５に故障通知として通知する機能とを有している。
出力ＩＦ部２８は、パケットを各リンクへ出力する機能と、各転送経路の経路到達性を定期的に確認する機能とを有している。
【００６２】
［サーバＩＦ部］
サーバＩＦ部２９は、ネットワーク制御サーバ５からＳＮＭＰ参照要求およびＳＮＭＰ設定要求を受信した際に、その要求の送信先が転送制御部２６であるか負荷観測部２７であるかを識別し、該当部にその要求を転送する機能と、転送制御部２６および負荷観測部２７からＳＮＭＰ要求応答を受信した際に、その応答をネットワーク制御サーバ５に転送する機能とを有している。
【００６３】
［第１の実施の形態の動作］
次に、本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの動作について説明する。以下では、加入者ユーザ収容ノード１と加入者ユーザ収容ノード３との間のデータ通信を例として説明する。
【００６４】
この動作例における通信ネットワークでは、図５に示すように、各端末および加入者ユーザ収容ノードにそれぞれ固有のアドレスが割り当てられているものとする。図５は、動作例で用いる通信ネットワークの物理モデル例である。
端末１０〜端末１７には、それぞれユーザ＃１〜ユーザ＃８というアドレスが割り当てられており、加入者ユーザ収容ノード１〜加入者ユーザ収容ノード４には、それぞれコア＃１〜コア＃４が割り当てられている。
また、加入者ユーザ収容ノード３には、ユーザ網２０を介して端末５０が収容されており、この端末５０にはユーザ＃９というアドレスが割り当てられている。
【００６５】
また、加入者ユーザ収容ノード１〜４間を結ぶ経路には、図６に示すように、それぞれ固有の経路識別子が割り当てられているものとする。図６は、動作例で用いる通信ネットワークの論理モデル例である。
フレーム転送装置６経由の経路に経路識別子Ｒ１が割り当てられており、フレーム転送装置７経由の経路に経路識別子Ｒ２が割り当てられている。また、フレーム転送装置８経由の経路には経路識別子Ｒ３が割り当てられており、フレーム転送装置９経由の経路には経路識別子Ｒ４が割り当てられている。
【００６６】
［加入者ユーザ収容ノードの動作］
図７を参照して、加入者ユーザ収容ノード１の動作について説明する。図７は、加入者ユーザ収容ノード１の動作を示す説明図である。以下では、端末１０と端末１４の間で通信が開始された場合を例として説明する。
端末１０と端末１４との間の通信をユーザフローＡとし、図８に示すユーザフレーム２０１が用いられる。図８は、ユーザフレームおよびコアフレームの構成例である。
ユーザフレーム２０１は、図８に示すように、ユーザヘッドとペイロードとから構成されており、ユーザフローＡで用いる際は、そのユーザヘッドには、送信元ユーザアドレスを示すユーザ＃１と宛先ユーザアドレスを示すユーザ＃５が格納される。
【００６７】
加入者ユーザ収容ノード１は、端末１０からのユーザフレーム２０１を、入力ＩＦ部２５で受信して、そのフレームがユーザフレーム２０１であると判断し、転送制御部２６へ転送する。
転送制御部２６は、図９に示す宛先特定テーブル３２を参照し、ユーザフレーム２０１の宛先ユーザアドレスであるユーザ＃５から、転送先である加入者ユーザ収容ノード３を識別するコア＃３を特定する。図９は、宛先特定テーブル３２の構成例であり、各宛先ユーザアドレスにそれぞれの宛先加入者ユーザ収容ノードが対応付けられている。
【００６８】
その後、図１０に示す経路特定テーブル３３を参照し、ユーザフレーム２０１の宛先ユーザアドレスであるユーザ＃５から、そのユーザフレーム２０１の転送に用いる経路の経路識別子Ｒ１を導く。図１０は、経路特定テーブル３３の構成例であり、各宛先ユーザアドレスにそれぞれの経路識別子が対応付けられて管理されている。
これにより、結果的にユーザフレーム２０１に対して、宛先コアアドレスコア＃３＿Ｒ１が算出され、この宛先コアアドレスコア＃３＿Ｒ１と送信元コアアドレス＃１から構成されるコアヘッダがユーザフレーム２０１に付与され、前述の図８に示したコアフレーム２０２が生成される。
【００６９】
コアフレーム２０２は、図８に示すように、コアヘッダとユーザフレーム２０１とから構成されており、この場合、コアヘッダには、送信元コアアドレスを示すコア＃１と宛先コアアドレスを示すコア＃３＿Ｒ１とが格納されている。
このようにして生成されたコアフレーム２０２は負荷観測部２７に転送される。
なお、経路特定テーブル３３において、自身のコアアドレスコア＃１が算出された場合、転送制御部２６は、該当ユーザフレーム２０１を出力ＩＦ部２８へ転送する。
【００７０】
負荷観測部２７は、コアフレーム２０２を受信した際、そのコアフレーム２０２から宛先ユーザアドレスユーザ＃５および宛先コアアドレスコア＃３＿Ｒ１を抽出し、図１１に示すカウンタテーブル３８のうち該当エントリのカウンタ値を「１」増やして「１００」から「１０１」に増加させる。図１１は、カウンタテーブル３８の構成例であり、宛先ユーザアドレスと宛先コアアドレスとの対ごとに、転送したフレーム数とそのしきい値とが対応付けられて管理されている。
【００７１】
さらに、負荷観測部２７は、コアフレーム２０２のフレーム長を計測し、１０００ｂｙｔｅと計測した際、図１２に示す帯域観測テーブル３９のうち該当エントリの総フレーム長を１０００ｂｙｔｅ増やして「２１２」から「２１３」に増加させる。図１２は、帯域観測テーブル３９の構成例であり、宛先ユーザアドレスと宛先コアアドレスとの対ごとに、転送したフレームの総フレーム長の合計値とそのしきい値とが対応付けて管理されている。
【００７２】
そして、負荷観測部２７は、フレームカウント部３４のカウンタテーブル３８で管理されている該当エントリのカウンタ値と、総フレーム長観測部３５の帯域観測テーブル３９で管理されている該当エントリの総フレーム長とを、例えば両者の合計値を求めることにより合成し、宛先ユーザアドレスと宛先コアアドレスとの対に対する負荷値を算出して、図１３に示す負荷値管理テーブル４０に記述する。図１３は、負荷値管理テーブル４０の構成例であり、宛先ユーザアドレスと宛先コアアドレスとの対ごとに、負荷値とそのしきい値とが対応付けられて管理されている。
【００７３】
本動作例では、カウンタ値と総フレーム長との合計値を負荷値としている。図１３に示すように、転送処理前において、宛先ユーザアドレスユーザ＃５および宛先コアアドレスコア＃３＿Ｒ１の対に対する負荷値は「３１２」であったが、当該カウンタ値「１００」および総フレーム長「２１２」がそれぞれ「１」ずつ加算されるため、転送処理後の負荷値は「３１４」となる。
負荷観測部２７は、前述した一連の制御を完了した後、コアフレーム２０２を出力ＩＦ部２８へ転送する。
【００７４】
出力ＩＦ部２８では、負荷観測部２７からコアフレーム２０２を受け取って、図１４に示す出力リンク特定テーブル４１を参照し、その宛先アドレスに対応する出力リンクを特定し、特定した出力リンクへコアフレーム２０２を出力する。図１４は、出力リンク特定テーブル４１の構成例であり、宛先アドレスごとにその出力リンクが対応付けて管理されている。図１４の例では、コアフレーム２０２の宛先アドレスであるコア＃３＿Ｒ１に対応する出力リンクとして出力リンク１０１が特定され、その出力リンク１０１へコアフレーム２０２が出力される。
【００７５】
ここで、負荷観測部２７は、フレームカウント部３４のカウンタテーブル３８を検査し、そのデータを有効化する。前述した図１１のカウンタテーブル３８において、コア＃３＿Ｒ１の総転送フレーム数が「５０００」であり、その後該当フレームが転送されると、しきい値「５０００」を超過する。
このような場合、負荷観測部２７は、カウンタテーブル３８内の各エントリのうち、コア＃３を有するエントリを抽出する。この例では、コア＃３＿Ｒ２およびそのカウント値「１２０３」と、コア＃３＿Ｒ３およびそのカウント値「３２５４」と、コア＃３＿Ｒ４およびそのカウント値「２７８２」とが抽出される。そして、これらエントリとカウンタ値とをフィードバック制御部３７に通知する。
【００７６】
フィードバック制御部３７は、負荷観測部２７から通知された各エントリのうちからそれぞれのカウント値に基づき任意のエントリすなわち異なる転送経路を示す新たな宛先ユーザアドレスを選択し、コア＃３＿Ｒ１に割り当てられている宛先ユーザアドレスを、選択した新たな宛先ユーザアドレスに割り当てるよう、転送制御部２６へ指示する。
この際の新たな宛先ユーザアドレスの選択方法としては、任意で選択する方法や、カウンタテーブル３８においてカウンタ値が最小のエントリを有する宛先ユーザアドレスを選択する方法がある。後者の場合、カウンタ値が最も小さい「１２０３」のコア＃３＿Ｒ２が選択されて、転送制御部２６へ通知される。
【００７７】
これに応じて、転送制御部２６は、フィードバック制御部３７から指示された宛先ユーザアドレスを検索キーとして宛先特定テーブル３２と経路特定テーブル３３を検索し、ヒットしたエントリの経路識別子を、フィードバック制御部３７から指定された経路識別子に書き換える。図９および図１０の例では、宛先ユーザアドレスとしてユーザ＃５が検索され、経路特定テーブル３３において、このユーザ＃５に対応する転送経路がＲ１からＲ２に書き換えられる。
【００７８】
これにより、その後、各端末からユーザ＃５を宛先ユーザアドレスとするフレームが加入者ユーザ収容ノード１に到着した場合、転送制御部２６では、宛先特定テーブル３２および経路特定テーブル３３が参照されて、宛先加入者ユーザ収容ノード３への経路として転送経路Ｒ２を特定する宛先コアアドレスとしてコア＃３＿Ｒ２が生成される。したがって、これ以降、加入者ユーザ収容ノード１に到着したユーザ＃５宛のフレームについては、比較的負荷の高い転送経路Ｒ１を回避し、比較的負荷の低い転送経路Ｒ２を経由して宛先加入者ユーザ収容ノード３へ転送されることになる。
【００７９】
なお、各加入者ユーザ収容ノード１〜４のカウンタテーブル３８、帯域観測テーブル３９、および負荷値管理テーブル４０については、ネットワーク制御サーバ５から定期的に参照されており、これら各テーブルが参照された際、各テーブルのカウント値、総パケット長、負荷値はすべて０（ゼロ）にリセットされる。これらテーブルの値については、加入者ユーザ収容ノード１〜４で自律的に初期化を行ってもよい。
【００８０】
このように、本実施の形態にかかる通信ネットワークでは、単位時間当たりに各転送経路へ出力される転送フレーム数を観測し、任意の転送経路で転送フレーム数がしきい値を超えた際に、転送テーブルを制御して、当該転送経路を利用する宛先ユーザアドレスの任意のエントリに対して、当該転送経路の経路識別子以外の経路識別子を割り当てるようにしたので、単位時間当たりに転送した転送フレーム数を考慮したトラヒックエンジニアリングを実現できる。
【００８１】
これにより、例えば複数ユーザが複数アプリケーションを同時に使用したことに起因して、ＶｏＩＰのようなフレーム長が比較的短いＩＰフローと比較的フレーム長の長いＩＰフローとが混在する状況では、従来のトラヒックエンジニアリングのように使用帯域に基づき複数の経路に均一にトラヒック量を割り振った場合、いずれかの経路でＶｏＩＰのようなフレーム長が短いフレームが集中するという偏りが生じる可能性があるが、本実施の形態によれば、各経路上に位置するフレーム転送ノードにおけるプロセッサでの処理負荷を正確に把握でき、このような偏り発生を確実に回避することができる。
【００８２】
したがって、各フレーム転送ノードにおけるプロセッサでの処理負荷をより正確に均一化することができ、結果として、加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型の通信ネットワークを実現できる。
【００８３】
この際、上記転送フレーム数に代えて、宛先ユーザアドレスと宛先加入者ユーザ収容ノードと経路識別子が同一である各フレームの、単位時間当たりに転送した総フレーム長を用いてもよく、単位時間当たりに転送した総フレーム長を考慮したトラヒックエンジニアリングを実現できる。
したがって、各経路でのリンク使用効率をより正確に均一化することができ、結果として、加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型の通信ネットワークを実現できる。
【００８４】
また、上記転送フレーム数に代えて、フレーム数および総フレーム長を合成して得られる負荷値を用いてもよく、これら両方のパラメータを考慮したトラヒックエンジニアリングを実現できる。
したがって、各経路上に配置されているフレーム転送ノードのプロセッサでの処理負荷と、各経路でのリンク使用効率とを均一化することができ、結果として、各加入者ユーザ間のデータ通信に対して高い信頼性が得られる負荷分散型の通信ネットワークを実現できる。
【００８５】
また、加入者ユーザ収容ノードで、加入者ユーザから受信したフレームをバックボーンネットワークへ送信する場合に、ユーザネットワーク形式のフレームをバックボーンネットワーク形式のフレームにカプセル化するようにしたので、このカプセル化技術の併用により、制御対象となる通信を、ユーザ単位から加入者ユーザ収容ノード単位に集約することが可能となる。
【００８６】
［第２の実施の形態］
次に、図１５を参照して、本発明の第２の実施の形態にかかる負荷分散型の通信ネットワークについて説明する。図１５は、本発明の第２の実施の形態にかかる負荷分散型の通信ネットワークで用いられるネットワーク制御サーバの構成を示すブロック図である。なお、第２の実施の形態にかかる負荷分散型の通信ネットワークのネットワークモデル、物理モデル、論理モデル、および加入者ユーザ収容ノードについては、前述した第１の実施の形態（図１〜図４）と同様であり、ここでの詳細な説明は省略する。
【００８７】
図１５に示すように、このネットワーク制御サーバ５は、トラヒック情報授受部４４および負荷分散計算部４５を有している。
トラヒック情報授受部４４は、トラヒック情報授受テーブル４６を有している。トラヒック情報授受テーブル４６は、ネットワーク内の各装置のアドレスから出力リンクおよびタイマーを導く機能を有している。タイマーは、トラヒック情報授受部４４により初期値が設定され、時間に従ってカウントダウンされ、０（ゼロ）となった際に再度初期値に再設定される。
【００８８】
トラヒック情報授受部４４は、ＳＮＭＰを実装し、ＳＮＭＰ参照要求により、トラヒック情報授受テーブル４６のタイマーが０（ゼロ）になったエントリの加入者ユーザ収容ノードの、宛先特定テーブル３２、経路特定テーブル３３、カウンタテーブル３８、帯域観測テーブル３９、負荷値管理テーブル４０、および出力リンク特定テーブル４１を参照する機能と、参照したトラヒック情報が記述されたＳＮＭＰ参照応答を受信した際に、トラヒック情報を抽出して負荷分散計算部４５に通知する機能とを有している。
【００８９】
さらに、出力ＩＦ部２８の生存性確認テーブル４３から故障通知を受信した際に故障情報を後に記述する負荷分散計算部４５に通知する機能と、後に記述する負荷分散計算部４５から通知される経路情報に基づき加入者ユーザ収容ノードの宛先特定テーブル３２、経路特定テーブル３３、出力リンク特定テーブル４１のテーブルのエントリを追加および削除する際に、負荷分散計算部４５から通知されるエントリをＳＮＭＰ設定要求として加入者ユーザ収容ノードに送信する機能とを有している。
【００９０】
負荷分散計算部４５は、トラヒック情報保持部４７，経路最適化処理部４８および更新経路情報保持部４９を有している。
トラヒック情報保持部４７は、トラヒック情報授受部４４から通知されたトラヒック情報および故障経路情報を保持する機能を有している。
経路最適化処理部４８は、トラヒック情報保持部４７に保存されたトラヒック情報および故障経路情報を用いてネットワーク内の負荷分散計算を実行する機能と、負荷分散計算により算出されたエントリおよびそのエントリを設定すべき加入者ユーザ収容ノードとテーブルを更新経路情報保持部４９に通知する機能とを有している。
【００９１】
更新経路情報保持部４９は、ネットワーク内のトポロジ情報を有し、経路最適化処理部４８から通知されたエントリおよびそのエントリを設定すべき加入者ユーザ収容ノードとテーブルに基づき、自身の有するトポロジ情報を更新する機能と、経路最適化処理部４８から通知されたエントリおよびそのエントリを設定すべき加入者ユーザ収容ノードとテーブルを、経路情報としてトラヒック情報授受部４４に通知する機能とを有している。
【００９２】
負荷分散計算部４５は、バックボーンネットワークの物理的な構造と、仮想プライベートネットワーク数を入力として、仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この結果に基づいて、バックボーンネットワーク内のフレーム転送ノードの有する転送テーブルを遠隔設定する。これにより、サーバによる集中管理型および集中制御型のトラヒックエンジニアリングが実現可能となる。
【００９３】
本実施の形態では、このような構成のネットワーク制御サーバを設け、仮想プライベートネットワークの技術をバックボーンネットワーク向けに適用して、バックボーンネットワークを構築するコアネットワーク上で、物理的に異なる転送経路ごとに仮想プライベートネットワークを設定するようにしたので、リンク断や装置輻輳などの物理的な原因による輻輳および故障を回避することができる。
【００９４】
［第２の実施の形態の動作］
次に、図１６〜図１８を参照して、本発明の第２の実施の形態にかかる負荷分散型の通信ネットワークの動作について説明する。図１６は、本発明の第２の実施の形態にかかる負荷分散型の通信ネットワークで用いられるネットワーク制御サーバ５の動作を示す説明図である。図１７は、動作例の通信ネットワークにおけるフレーム分散前の状態を示す説明図である。図１８は、動作例の通信ネットワークにおけるフレーム分散後の状態を示す説明図である。ここでは、転送フレーム数に着目した経路最適化処理による経路変更例について説明する。
【００９５】
図１７に示すように、フレーム分散前の状態において、動作例の通信ネットワークでは、フレーム転送装置６経由の経路識別子Ｒ１で示される経路は、ユーザフローＡとユーザフローＢが利用しており、この経路が比較的混雑しているのに対し、フレーム転送装置８経由の経路識別子Ｒ３で示される経路は、ユーザフローＥしか利用しておらず、比較的余裕がある。
【００９６】
ネットワーク制御サーバ５は、この通信ネットワーク内の各装置の転送負荷を監視しており、具体的にはネットワーク内の装置のモニタリング情報を定期的に参照する。このモニタリング情報とは、各装置において観測される、加入者ユーザ収容ノード間の転送フレーム数、総フレーム長、および負荷値を示す。
【００９７】
前述した定期的な参照については、トラヒック情報授受部４４により実現する。トラヒック情報授受部４４は、図１９に示すトラヒック情報授受テーブル４６を有する。図１９は、トラヒック情報授受テーブル４６の構成例であり、宛先アドレスごとにタイマーと出力リンクとが対応付けて管理されている。本動作例ではタイマーは「６００」を初期値としており、トラヒック情報授受部４４は、６００秒ごとに各装置のモニタリング情報を参照する。
【００９８】
ネットワーク制御サーバ５は、負荷分散計算部４５のトラヒック情報保持部４７において、トラヒック情報授受部４４で収集したモニタリング情報を分析する。そして、任意の経路の輻輳を検知した場合、負荷分散計算部４５の経路最適化処理部４８によってネットワーク内の経路最適化を行う。
【００９９】
この経路最適化により、ネットワーク内の各装置の転送テーブルを変更する必要が生じた場合、更新経路情報保持部４９が有するトポロジデータに変更内容を反映し、ネットワーク内の各装置に、転送テーブルエントリを変更するよう記述したＳＮＭＰ設定要求を送信する。
【０１００】
例えば、転送フレーム数に着目して経路の最適化を行った場合、加入者ユーザ収容ノード１のカウンタテーブル３８から得られたカウンタ値に基づき、フレーム転送装置６での混雑が検知されて、ユーザフローＢが比較的混雑していないフレーム転送装置７の経路を用いるよう経路変更される。これにより結果的に、図１８に示すように、各経路の転送フレーム数が均等になるように、加入者ユーザ収容ノードの転送テーブルエントリが変更される。
【０１０１】
次に、図２０および図２１を参照して、ネットワーク制御サーバ５の他の動作例について説明する。図２０は、動作例の通信ネットワークにおけるフレーム分散後の故障発生状態を示す説明図である。図２１は、動作例の通信ネットワークにおける故障迂回後の状態を示す説明図である。ここでは、転送フレーム数および故障検知に基づく経路最適化処理による経路迂回例について説明する。
【０１０２】
図２０では、フレーム分散後の状態において、フレーム転送装置８経由の経路識別子Ｒ３で示される経路において故障が発生している。
ネットワーク制御サーバ５は、通信ネットワーク内の各装置の生存性を監視しており、具体的には、ネットワーク内の装置のモニタリング情報を定期的に参照することにより、各装置の生存性を確認できる。また、加入者ユーザ収容ノード１から４においても、各加入者ユーザ収容ノード間でＰｉｎｇパケットを送受信することにより、定期的に各経路の生存性を確認している。
【０１０３】
加入者ユーザ収容ノード１〜４は、出力ＩＦ部２８により、図２２に示す生存性確認テーブル４３を参照し、各加入者ユーザ収容ノードに対し、各転送経路を使用してＰｉｎｇ応答要求を送信する。図２２は、生存性確認テーブル４３の構成例であり、各宛先コアアドレスに対して、定期的にＰｉｎｇ応答要求を送信するためのタイマーと生存性確認のためのフラグとが対応付けて管理されている。
【０１０４】
このタイマーは、初期値を「１００」とし、１秒ごとに１カウントダウンされるとする。タイマーが２０カウントダウンされるごとに、Ｐｉｎｇ応答要求を送信する。タイマーは１００秒後に０（ゼロ）となるが、１００秒間でＰｉｎｇ応答を受信した際はフラグをたてる。
また、タイマーが０（ゼロ）となった際でもフラグがたっていなければ、経路に故障が発生したと判断し、ネットワーク制御サーバ５に対し、その宛先コアアドレスが示す経路が故障したという情報を記した故障通知を送信する。
【０１０５】
ネットワーク制御サーバ５は、負荷分散計算部４５のトラヒック情報保持部４７において、トラヒック情報授受部４４で収集したモニタリング情報を分析する。そして、任意の経路の故障を検知した場合、モニタリング情報の収集が不可能となって任意の装置の故障を検知した場合、または加入者ユーザ収容ノードから各経路の故障に関する通知を受信した場合、負荷分散計算部４５の経路最適化処理部４８によって通信ネットワーク内の経路最適化を行う。
【０１０６】
この際、故障している経路および装置は、経路割り当ての対象外とする。経路最適化により、ネットワーク内の各装置の転送テーブルを変更する必要が生じるため、更新経路情報保持部が有するトポロジデータに変更内容を反映し、ネットワーク内の各装置に、転送テーブルエントリを変更するよう記述したＳＮＭＰ設定要求を送信する。
【０１０７】
例えば、転送フレーム数に着目して最適化を行った場合、フレーム転送装置８からモニタリング情報の収集不可能に基づき、フレーム転送装置８での故障が検知されて、湯サーフローＢおよびユーザフローＥが、比較的混雑していないフレーム転送装置６およびフレーム転送装置９の経路をそれぞれ用いるよう経路迂回される。結果的に、図２０に示すように、フレーム転送装置８以外の各経路の転送フレーム数が均等になるように、加入者ユーザ収容ノードの転送テーブルエントリが変更される。
【０１０８】
このように、ネットワーク制御サーバとして前述した構成を有することにより、集中管理型および集中制御型のトラヒックエンジニアリングが実現可能となる。
【０１０９】
また、仮想プライベートネットワークの技術をバックボーンネットワーク向けに適用して、バックボーンネットワークを構築するコアネットワーク上で、物理的に異なる転送経路ごとに仮想プライベートネットワークを設定するようにしたので、リンク断や装置輻輳などの物理的な原因による輻輳および故障を回避することができる。
これにより、例えば単位時間当たりにネットワーク中の各転送経路上で転送されるフレーム数を均一化する、単位時間当たりにネットワーク中の各転送経路上で転送されるフレームの総フレーム長を均一化する、もしくは、単位時間当たりにネットワーク中の各転送系路上でフレームを転送する際の総負荷を均一化することが可能となる。
【０１１０】
また、ネットワーク制御サーバにおいて、バックボーンネットワークの物理的な構造と、仮想プライベートネットワーク数を入力として、仮想プライベートネットワークごとに物理的に異なる転送経路を割り当てる計算を行い、この結果に基づいて、バックボーンネットワーク内のフレーム転送ノードの有する転送テーブルを遠隔設定するようにしたので、サーバによる集中管理型および集中制御型のトラヒックエンジニアリングが実現可能となる。
【０１１１】
また、ネットワーク制御サーバで、バックボーンネットワーク内のフレーム転送ノードから、転送経路ごとの転送フレーム数を収集し、転送経路間で転送フレーム数に差がある場合に、この差が小さくなるように、加入者ユーザ収容ノード内の転送テーブルを制御するようにしたので、単位時間当たりにネットワーク中の各転送経路上で転送されるフレーム数を均一化することが可能となる。
【０１１２】
この際、ネットワーク制御サーバで、転送フレーム数に代えて転送経路ごとの総フレーム長を収集し、転送経路間で総フレーム長に差がある場合に、この差が小さくなるように、加入者ユーザ収容ノード内の転送テーブルを制御してもよい。これにより、単位時間当たりにネットワーク中の各転送経路上で転送される総フレーム長を均一化することが可能となる。
【０１１３】
あるいは、ネットワーク制御サーバで、転送経路ごとに転送フレーム数と総フレーム長からなる負荷値を収集し、転送経路間で負荷値に差がある場合に、この差が小さくなるように加入者ユーザ収容ノード内の転送テーブルを制御してもよい。これにより、単位時間当たりにネットワーク中の各転送経路上で転送される総負荷を均一化することが可能となる。
【０１１４】
また、ネットワーク制御サーバで、バックボーンネットワーク内の故障を監視し、故障を検出した場合にその故障の影響を受ける転送経路を特定し、この特定された情報を全加入者ユーザ収容ノードに通知するようにしてもよく、サーバによるネットワーク状態の集中管理を実現でき、その結果、故障検出および故障に影響を受ける全経路を特定することが可能となる。
【０１１５】
また、加入者ユーザ収容ノードで、ネットワーク制御サーバから故障に関わる転送経路の通知された場合、フレーム転送時に選択された転送経路が通知された転送経路と同じ場合には、これとは異なる転送経路を再選択するようにしてもよく、トラヒックエンジニアリングにおいて故障迂回を実現できる。
【０１１６】
なお、ここで示されるトラヒックエンジニアリングとは、単位時間当たりにネットワーク中の各転送経路上で転送されるフレーム数を均一化する技術を示す場合や、単位時間当たりにネットワーク中の各転送経路上で転送されるフレームの総フレーム長を均一化する技術を示す場合や、単位時間当たりにネットワーク中の各転送系路上でフレームを転送する際の総負荷を均一化する技術を示す場合があり、これらは、加入者ユーザ収容ノードの負荷観測部で設定されているポリシに基づいて定義される。
【０１１７】
例えば、負荷観測部がフレームカウント部のしきい値を有効にしている場合、ネットワーク制御サーバは、単位時間当たりにネットワーク中の各転送経路上で転送されるフレーム数を均一化する。
また、このようなトラヒックエンジニアリングに加え、ネットワーク制御サーバによるネットワーク状態の集中管理が実現でき、その結果、故障検出および故障に影響を受ける全経路を特定することが可能となる。
【図面の簡単な説明】
【０１１８】
【図１】本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークのネットワークモデルを示すブロック図である。
【図２】本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの物理モデル例である。
【図３】本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークの論理モデル例である。
【図４】本発明の第１の実施の形態にかかる負荷分散型の通信ネットワークで用いられる加入者ユーザ収容ノードの構成を示すブロック図である。
【図５】動作例で用いる通信ネットワークの物理モデル例である。
【図６】動作例で用いる通信ネットワークの論理モデル例である。
【図７】加入者ユーザ収容ノードの動作を示す説明図である。
【図８】ユーザフレームおよびコアフレームの構成例である。
【図９】加入者ユーザ収容ノードの転送制御部で用いられる宛先特定テーブルの構成例である。
【図１０】加入者ユーザ収容ノードの転送制御部で用いられる経路特定テーブルの構成例である。
【図１１】加入者ユーザ収容ノードの負荷観測部で用いられるカウンタテーブルの構成例である。
【図１２】加入者ユーザ収容ノードの負荷観測部で用いられる帯域観測テーブルの構成例である。
【図１３】加入者ユーザ収容ノードの負荷観測部で用いられる負荷値管理テーブルの構成例である。
【図１４】加入者ユーザ収容ノードの出力ＩＦ部で用いられる出力リンク特定テーブルの構成例である。
【図１５】本発明の第２の実施の形態にかかる負荷分散型の通信ネットワークで用いられるネットワーク制御サーバの構成を示すブロック図である。
【図１６】ネットワーク制御サーバの動作を示す説明図である。
【図１７】動作例の通信ネットワークにおけるフレーム分散前の状態を示す説明図である。
【図１８】動作例の通信ネットワークにおけるフレーム分散後の状態を示す説明図である。
【図１９】ネットワーク制御サーバのトラヒック情報授受部で用いられるトラヒック情報授受テーブルの構成例である。
【図２０】動作例の通信ネットワークにおけるフレーム分散後の故障発生状態を示す説明図である。
【図２１】動作例の通信ネットワークにおける故障迂回後の状態を示す説明図である。
【図２２】加入者ユーザ収容ノードの出力ＩＦ部で用いられる生存性確認テーブルの構成例である。
【符号の説明】
【０１１９】
１〜４…加入者ユーザ収容ノード、５…ネットワーク制御サーバ、６〜９…フレーム転送装置、１０〜１７，５０…端末、１８〜２１…ユーザ網、２２…コアネットワーク、２３…ユーザネットワーク、２５…入力ＩＦ部、２６…転送制御部、２７…負荷観測部、２８…出力ＩＦ部、２９…サーバＩＦ部、３０…生存性応答部、３１…転送テーブル、３２…宛先特定テーブル、３３…経路特定テーブル、３４…フレームカウント部、３５…総フレーム長観測部、３６…負荷値計算部、３７…フィードバック制御部、３８…カウンタテーブル、３９…帯域観測テーブル、４０…負荷値管理テーブル、４１…出力リンク特定テーブル、４２…生存性確認部、４３…生存性確認テーブル、４４…トラヒック情報授受部、４５…負荷分散計算部、４６…トラヒック情報授受テーブル、４７…トラヒック情報保持部、４８…経路最適化処理部、４９…更新経路情報保持部、１０１〜１２４…リンク、２０１…ユーザフレーム、２０２…コアフレーム。
【図１】
2006005629.tif 000003
【図２】
2006005629.tif 000004
【図３】
2006005629.tif 000005
【図４】
2006005629.tif 000006
【図５】
2006005629.tif 000007
【図６】
2006005629.tif 000008
【図７】
2006005629.tif 000009
【図８】
2006005629.tif 000010
【図９】
2006005629.tif 000011
【図１０】
2006005629.tif 000012
【図１１】
2006005629.tif 000013
【図１２】
2006005629.tif 000014
【図１３】
2006005629.tif 000015
【図１４】
2006005629.tif 000016
【図１５】
2006005629.tif 000017
【図１６】
2006005629.tif 000018
【図１７】
2006005629.tif 000019
【図１８】
2006005629.tif 000020
【図１９】
2006005629.tif 000021
【図２０】
2006005629.tif 000022
【図２１】
2006005629.tif 000023
【図２２】
2006005629.tif 000024