JP2014195185A - 通信装置、通信システム、及び、通信方法 - Google Patents
通信装置、通信システム、及び、通信方法 Download PDFInfo
- Publication number
- JP2014195185A JP2014195185A JP2013070752A JP2013070752A JP2014195185A JP 2014195185 A JP2014195185 A JP 2014195185A JP 2013070752 A JP2013070752 A JP 2013070752A JP 2013070752 A JP2013070752 A JP 2013070752A JP 2014195185 A JP2014195185 A JP 2014195185A
- Authority
- JP
- Japan
- Prior art keywords
- path
- connection
- packet
- predicted value
- communication device
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】過剰な帯域を用いることなく、速やかに輻輳を解消する。
【解決手段】通信装置は、パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持し、前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持し、前記複数のパスの各々におけるトラヒック量の予測値を保持し、パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定し、前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送する。
【選択図】図1
【解決手段】通信装置は、パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持し、前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持し、前記複数のパスの各々におけるトラヒック量の予測値を保持し、パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定し、前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送する。
【選択図】図1
Description
本発明は、通信装置に関する。
企業活動のIT化、及びスマートフォンなどの高速端末の普及に伴い、有線による通信であるか、又は、無線による通信であるかに関わらず、通信によって発生するトラヒックは、急激に増加している。通信キャリアは、そのようなトラヒックの増大に従って、キャリアネットワークの高速化、及び大容量化を余儀なくされている。
通信キャリアが提供するキャリアネットワークは、従来、安定したネットワークサービスの提供が最優先であったため、静的な運用が前提であった。このため、キャリアネットワークにおいて帯域を設計する方法として、変動するトラヒックのピークにあわせて帯域を設計する方法(オーバエンジニアリング)が主流であった。
また、通常のオーバプロビジョニングは、ピークのトラヒック量にあわせるだけでなく、その後数年のトラヒックの伸びも考慮して帯域を設計する方法である。このため、オーバプロビジョニングにより設計された帯域の量には、平均のトラヒック量と比較して、非常に大きな量が確保されていた。
一方、現在、CPU(Central Processing Unit)及びメモリ等の高速化及び低価格化が進んだことで、サーバ等に用いられる計算機は、ソフトウェアを安価に高速に処理することが可能となってきた。そして、サーバが高性能化することに伴い、サーバが、ソフトウェアによってシステムを動的に制御する技術が注目を集めている。
動的にシステムを制御する技術には、Big Data、及び、SDN(Software Defined Network)等がある。Big Dataは、大量のデータを一度に収集し、収集されたデータを分析した結果をシステムの制御に動的にフィードバックする技術である。SDNは、全ての通信装置をソフトウェアによって動的に制御する技術である。
このようなソフトウェアによるシステムの動的な制御により、サーバは、過去のトラヒックの通信状況を収集し、収集されたトラヒックを分析し、分析結果からユーザの使用量を予測し、通信装置の設定を予測に基づいて動的に変更する、などの制御処理が可能となってきた。具体的には、各ユーザの実際のトラヒック量を収集し、トラヒック量をデータとして蓄積し、蓄積されたデータを分析する技術が提案されている(例えば、特許文献1参照)。
その結果、サーバは、ユーザ各々の通信におけるトラヒック量を予測できるため、各リンクの帯域を超過しないような最適なユーザの組み合わせを考慮して通信の経路(パス)を選択できる。例えば、オフィスユーザのように昼間にトラヒックの多いユーザ、及び、ホームユーザのように夜間にトラヒックの多いユーザなど、トラヒック量が多い時間帯が異なるユーザを効率よくネットワークに収容できるように、サーバは、ネットワークを動的に制御することが可能である。これにより、通信キャリアは、従来のオーバプロビジョニングから脱却し、キャリアネットワークの帯域を効率的に利用できる。
さらに、帯域設計されたネットワークにおいて輻輳が発生した場合、制御サーバが、輻輳を検出したユーザのパスを再設定する技術が提案されている(例えば、特許文献2参照)。特許文献2には、「トランスポート制御サーバ100は、パス追加要求を受信すると追加パスを割り当てた後の集約パスのトラフィック帯域が、迂回先経路の空き容量を越えないように追加パスを集約パスに割り当てる。」ことが記載されている。これにより、前述のようなトラヒックの予測が外れた場合でも、輻輳による通信品質の低下を復旧することが可能である。
帯域の予測には一定の不確定性が必ず含まれ、予測精度が100%になることはない。そこで、予測精度を限りなく100%に近づければ近づけようとした場合、オーバプロビジョニングと同様にピークに合わせたマージンの多いプロビジョニングが必要となり、帯域の無駄が大きくなる。
帯域の予測がはずれた場合、特許文献2における制御サーバは、輻輳を解消するため、制御サーバのソフトウェアを用いて、切り替え後のパスにおいて各リンクなどの帯域が不足しないことを確認した後に、パスを切り替える。しかし、特許文献2のように制御サーバがトラヒックの予測値を再度計算し、全ノードへ再設定する場合、そのフィードバックには通常数分以上の長い時間が必要となる。このため、再計算中に状況が変動してしまい、フィードバックが効果的に動作しないという課題があった。
本発明の目的は、ネットワークにおいて発生した輻輳を、過剰な帯域を用意することなく、速やかに解消するシステムの提供である。
本発明の代表的な一例を示せば以下の通りである。すなわち、複数のパスに接続され、受信したパケットを前記複数のパスのうちの一つへ転送する通信装置であって、前記通信装置は、前記パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持するコネクション予測値記憶部と、前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持する設定記憶部と、前記複数のパスの各々におけるトラヒック量の予測値を保持するパス予測値記憶部と、パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定するパケット処理部と、前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送するスイッチ部と、を有する。
本発明の一実施形態によると、過剰な帯域を用いることなく、輻輳を速やかに解消できる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
以下、本発明の実施例について、図面を参照して説明する。
図1は、本実施例1の通信システムの構成と動作との概要を示す説明図である。
本実施例の通信システムは、複数の通信装置10(10A〜10E)、ネットワーク管理システム(NMS)20、中継ネットワーク30、複数のユーザ端末(TE:Terminal Equipment)60(60A〜60C)、及び、サーバ(SN:Server Node)70を有する。
通信装置10の各々は、エッジ装置及び中継装置の機能を有し、物理的な構成が同じである。通信装置10は、あらかじめ設定されるパラメータ、又は、入力されるパケットに従って、エッジ装置又は中継装置として機能する。
通信装置10A及び通信装置10Eは、図1に示す通信システムにおいて、中継ネットワーク30のエッジ装置として機能し、通信装置10B、通信装置10C及び通信装置10Dは、図1に示す通信システムにおいて、中継ネットワーク30の中継装置として機能する。
TE60は、ユーザがSN70からサービス等を受けるため、SN70にパケットを送信する計算機である。SN70は、TE60から送信されたパケットを受信する計算機である。
TE60Aを用いるユーザを、ユーザAと記載し、TE60Bを用いるユーザを、ユーザBと記載し、TE60Cを用いるユーザを、ユーザCと記載する。そして、本実施例において、例えばTE60Aによる通信を、ユーザAによる通信と記載する場合がある。
通信装置10A及び通信装置10Eは、TE60から送信されるパケットの属性に従って、パケットをユーザごとに識別する。実施例1の通信装置10A及び通信装置10Eは、ユーザによる通信をコネクションとして識別する。
中継ネットワーク30は、通信装置10Aと通信装置10Eとが相互に通信するためのネットワークである。図1に示す通信装置10Aと通信装置10Eとは、パス50A(PS1)及びパス50B(PS2)を介して通信する。
図1に示す通信装置10Aは、TE60A、TE60B又はTE60Cからパケット40を受信した場合、受信したパケット40をパケット41に変換し、パス50A(PS1)又はパス50B(PS2)を介してパケット41を通信装置10Eへ転送する。そして、通信装置10Eは、受信したパケット41をパケット40に変換し、パケット40をSN70へ送信する。
NMS20は、プロセッサを有する計算機であり、エッジ装置の間、すなわち、通信装置10Aと通信装置10Eとの間に複数のパス50を設定する(P80)。NMS20は、自らが有するプログラムを実行するサーバである。図1に示すNMS20は、パス50A及びパス50Bを設定する。
パス50Aは、通信装置10A、通信装置10B及び通信装置10Eを通過するパスである。パス50Bは、通信装置10A、通信装置10C、通信装置10D及び通信装置10Eを通過するパスである。本実施例のパス50A及びパス50Bは、送信元が通信装置10Aであるパスであり、かつ、送信先が通信装置10Eであるパスである。
また、図1に示すNMS20は、パス50A及びパス50Bの各々に100Mbpsの帯域を割り当てる。実施例1のNMS20は、TE60の各々に対応するトラヒックの予測値(コネクションにおけるトラヒックの予測値)を算出し、通信装置10A及び通信装置10Eに算出されたトラヒックの予測値を通知する(P81)。ここで、この予測値の具体例を図2に示す。
図2は、本実施例1のユーザの各々に対応するトラヒック量の予測値の一例を示す説明図である。
NMS20は、中継ネットワーク30に流れるトラヒック量を通信装置10を介して取得し、取得されたトラヒック量に基づいて統計情報を生成する。そして、NMS20は、生成された統計情報に基づいて、TE60の各々に対応するトラヒック量の将来の予測値を算出する。NMS20は、例えば、特許文献1に記載の技術を用いることによって、予測値を算出する。
そして、NMS20は、算出されたトラヒック量の予測値を通信装置10に送信し、通信装置10は、NMS20から送信された予測値を自らに設定する(P81)。
実施例1におけるNMS20は、早朝(0〜8時)、昼間(8〜17時)及び夜間(17〜24時)の3期間に、1日における期間を区切り、3期間の各々におけるトラヒック量の予測値を算出する。ただし、NMS20は、一つの予測値を算出してもよく、例えば、1日におけるトラヒックの上限値の平均値を予測値として算出してもよい。
図2(a)は、本実施例1のユーザAに対応するトラヒック量の予測値の一例を示す説明図である。
図2(b)は、本実施例1のユーザBに対応するトラヒック量の予測値の一例を示す説明図である。
図2(c)は、本実施例1のユーザCに対応するトラヒック量の予測値の一例を示す説明図である。
図2(a)及び図2(c)は、TE60A及びTE60Cによるトラヒック量が、早朝及び夜間において、昼間のトラヒック量よりも小さいことを示す。このため、ユーザA及びユーザCは、例えば、企業において昼間TE60を用いるユーザであると想定される。
一方、図2(b)は、TE60Bによるトラヒック量が、早朝と昼間とにおいて、夜間のトラヒック量よりも小さいことを示す。このため、ユーザBは、例えば単身者であり、自宅において夜にTE60を用いるユーザであると想定される。
実施例1の通信装置10は、図2(a)〜図2(c)に示すトラヒックの予測値に基づいて、パス50の各々に割り当てられる帯域100Mbpsを超過しないように、図3に示すように各ユーザによるトラヒックを収容するパス50を決定する。
図3は、本実施例1のトラヒックの各々を収容後の各パスにおける、予測値の積算値を示す説明図である。
図3(a)は、本実施例1のパス50Aに収容されるトラヒックの予測値の積算値を示す説明図である。
通信装置10は、ユーザAのトラヒックの予測値とユーザBのトラヒックの予測値とを3期間の各々において積算した場合、図3(a)に示す積算値を算出する。図3(a)に示す積算値は、すべての期間においてパス50Aに割り当てられた100Mbpsを越えない。このため、実施例1の通信装置10は、パス50Aに収容されるトラヒックとして、ユーザAのトラヒックとユーザBのトラヒックとの組合せを決定する。
図3(b)は、本実施例1のパス50Bに収容されるトラヒックの予測値の積算値を示す説明図である。
さらに、実施例1の通信装置10は、ユーザCのトラヒックの予測値がすべての期間において100Mbpsを超えないため、ユーザCのトラヒックをパス50Bに収容することを決定する。
オーバエンジニアリングを用いる場合、トラヒックの各々は、期間に関係なく各ユーザのトラヒックの最大値の積算値によって、パス50に割り当てられる。図2(a)〜図2(c)によれば、ユーザAの最大値は80Mbpsであり、ユーザBの最大値は70Mbpsであり、ユーザCの最大値は80Mbpsである。このため、仮にNMS20がオーバエンジニアリングを用いてユーザをパスに割り当てる場合、いずれのユーザを組み合わせても、100Mbpsの2つのパス50がユーザのトラヒックを収容することは不可能であると判定する。
一方で、実施例1の図3に示す方法によれば、通信装置10は、予測値が多い期間が異なるユーザのトラヒックを、効率よく一つのパス50に収容させることができる。このため、実施例1の通信システムは、100Mbpsのパス50に全ユーザを収容することが可能になる。
実施例1の通信装置10は、パケットを受信するタイミングにおいて、パス50の各々を通過する帯域を監視する。そして通信装置10は、例えば、受信したパケットをパス50Aに転送した場合、パス50Aを通過する帯域がパス50Aにあらかじめ定められる帯域(閾値)を超過することを検出した場合、受信したパケットが転送されるパスを切り替えることができるか否かを判定する。そして、通信装置10は、受信したパケットが転送されるパスを切り替えることができない場合、パス50Aに収容されるユーザの中から、NMS20から送信されたトラヒックの予測値に基づいて切り替えるべきユーザを決定し、決定されたユーザが収容されるパスを切り替える(図1に示すP82)。
図4は、本実施例1のイーサネットにおけるパケット40のフォーマットを示す説明図である。
パケット40は、通信装置10AがTE60A、TE60B及びTE60Cと、イーサネットを用いて通信するためのパケットであり、また、通信装置10EがSN70と通信するためのパケットである。パケット40は、MACヘッダ、ペイロード部405及びパケットチェックシーケンス(FCS)406を含む。
MACヘッダは、宛先MACアドレス401、送信元MACアドレス402、VLANタグ403及びイーサタイプ値404を含む。宛先MACアドレス401と送信元MACアドレス402とには、TE60A、TE60B、TE60C及びSN70のうちいずれかのMACアドレスが格納される。
VLANタグ403は、TE60又はユーザの各々によるパケットを識別するための値を含み、本実施例においてVLAN ID(VID)を含む。本実施例において、TE60又はユーザによる通信をコネクションと記載し、VIDはコネクションを識別するために用いられる。しかし、TE60又はユーザによる通信を識別することができる方法であれば、いかなる方法が用いられてもよく、VLANタグ403にいかなる識別子が格納されてもよい。
イーサタイプ値404は、後続するヘッダの種類を示す。ペイロード部405は、アプリケーション等によって用いられるデータを含み、FCS406は、パケット40の誤り制御のために用いられる。
図5は、本実施例1のMPLSを用いたパケット41のフォーマットを示す説明図である。
パケット41は、通信装置10A及び通信装置10Eが、中継ネットワーク30内において送受信するパケットである。本実施例のパケット41のフォーマットには、MPLS(Multi−Protocol Label Switching)を用いてイーサネットを収容する際に使用されるPsudo Wire(PW)フォーマットが用いられる。パケット41は、MACヘッダ、MPLSラベル414−1、MPLSラベル414−2、ペイロード部415及びFCS416を含む。
MACヘッダは、宛先MACアドレス411、送信元MACアドレス412、及び、イーサタイプ値413を含む。宛先MACアドレス411と送信元MACアドレス412とには、通信装置10A又は通信装置10BのMACアドレスが格納される。イーサタイプ値413は、後続するヘッダの種類を示す。
実施例1のパケット41は、MPLSラベルとして二段のラベルを有する。MPLSラベル414−1は、1段目のMPLSラベル(LSPラベル)であり、中継ネットワーク30内の転送経路を示す。MPLSラベル414−2は、2段目のMPLSラベル(PWラベル)であり、ユーザ又はサービスを一意に示す。
ペイロード部415は、図4に示すパケット40がカプセル化されて格納される領域である。FCS416は、パケット41の誤り制御に用いられる。
図6は、本実施例1の通信装置10の物理的な構成を示すブロック図である。
通信装置10は、複数のネットワークインタフェースボード(NIF)13(13−1〜13−n)、スイッチ部11、パケット転送テーブル27及び装置管理部12を有する。NIF13は、パケット40又はパケット41を受信し、パケット40又はパケット41を送信するインタフェースである。
スイッチ部11は、NIF13に接続され、パケット転送テーブル27に基づいてパケットの宛先等を検索する。パケット転送テーブル27は、パケット40又はパケット41の送信元と宛先とを示す。
装置管理部12は、通信装置10を管理し、NMS20に接続される。装置管理部12は、ユーザの各々のトラヒックによる予測帯域をNMS20から受信した場合、コネクション予測帯域テーブル25に値を格納する。
NIF13の各々は、複数のイーサネットIF101(101−1〜101−n)、複数のSWインタフェース102(102−1〜102−n)、入力パケット処理部103、出力パケット処理部104、NIF管理部105、設定レジスタ106、コネクションID決定テーブル21、入力ヘッダテーブル22、ラベル設定テーブル23、帯域監視テーブル24、コネクション予測帯域テーブル25及びパス予測帯域テーブル26を有する。
図6に示すNIF13の処理部は、集積回路等の演算装置を有する物理的な装置によって実装され、NIF13が有するテーブルは、CAM(Content−addressable memory)等の物理的な装置によって実装される。しかし、NIF13が有する各処理部は、必要に応じて、論理的なプログラムによって実装されてもよい。また、NIF13が有するテーブルの各々の情報も、一つのメモリの記憶領域に格納されてもよい。
イーサネットIF101は、通信装置10外部からパケットを受信するポートと通信装置10の外部へパケットを送信するポートとを有する。イーサネットIF101は、これらのポートを介して、その他の通信装置10、TE60又はサーバ70と接続される。
実施例1において、イーサネットIF101は、イーサネット用の回線インタフェースであるが、イーサネット用の回線インタフェースに限られず、いかなる方法を用いた回線インタフェースであってもよい。
設定レジスタ106は、処理部の各々において実行される処理に、パラメータ等を提供するレジスタである。NIF管理部105は、コネクションが収容されるパスの割り当てが適当であるか否かを判定する処理部である。
入力パケット処理部103は、イーサネットIF101に接続され、時刻カウンタ1031を有する。時刻カウンタ1031は、入力パケット処理部103が保持する時刻を示し、一定の速度でカウントアップされる。
SWインタフェース102は、スイッチ部11に接続され。出力パケット処理部104は、SWインタフェース102に接続される。
SWインタフェース102の各々は、イーサネットIF101の各々と対応しており、イーサネットIF101−iが受信したパケットは、SWインタフェース102−iを介してスイッチ部11に転送される。また、スイッチ部11からSWインタフェース102−iに振り分けられたパケットは、イーサネットIF101−iを介して、出力回線に出力される。
このため、入力パケット処理部103及び出力パケット処理部104は、パケットを受信した回線、及び、送信した回線毎に独立な構造を有している。そして、入力パケット処理部103及び出力パケット処理部104において各回線のパケットが混ざることはない。
イーサネットIF101は、入力回線からパケット40を受信した場合、受信したパケットに、図7に示す装置内ヘッダ45を付加する。
図7は、本実施例1の装置内ヘッダ45を示す説明図である。
装置内ヘッダ45は、コネクションID451と、受信ポートID452と、受信NIF ID453と、パケット長454とを示す複数のフィールドを含む。装置内ヘッダ45は、通信装置10において用いられるヘッダである。
イーサネットIF101は、受信したパケット40に、装置内ヘッダ45のフィールドを付加する。そして、イーサネットIF101は、設定レジスタ106から、パケット40を受信したポートのIDと自らが属するNIF13のIDとを取得し、取得されたポートのIDを受信ポートID452に格納し、取得されたNIF13のIDを受信NIF ID453に格納する。
一方、イーサネットIF101は、コネクションID451に値を格納しない。コネクションID451には、入力パケット処理部103によって有効な値が設定される。
また、イーサネットIF101は、受信したパケットのパケット長を算出し、算出されたパケット長をパケット長454に格納する。
入力パケット処理部103は、イーサネットIF101から転送されたパケット40に、後述する入力パケット処理(S100)を実行する。入力パケット処理部103は、入力パケット処理(S100)において、NIF13が有するテーブルの各々を参照し、パケットの装置内ヘッダ45のコネクションID451にコネクションIDを格納する。また、入力パケット処理部103は、ヘッダ処理及び帯域監視処理等を必要に応じて、パケット40に実行する。また、入力パケット処理部103は、パケット40をパケット41に変換する。
そして、入力パケット処理(S100)の後、パケット41は、SWインタフェース102に回線毎に振り分けられ、転送される。
図8は、本実施例1のコネクションID決定テーブル21を示す説明図である。
コネクションID決定テーブル21は、NIF ID212と、ポートID213と、VLAN ID214との組合せを検索キーとして、コネクションID211の値を取得するためのテーブルである。コネクションID決定テーブル21の値は、例えばネットワーク管理者等によって、あらかじめ設定される。
コネクションID211は、複数の通信装置10間においてコネクションを一意に特定するためのIDであり、双方向で同じIDが割り当てられる。実施例1のコネクションID211は、TE60の各々によるトラヒックを識別するためのIDである。
NIF ID212は、パケット40を受信したNIF13の識別子を示す。NIF ID212は、装置内ヘッダ45の受信NIF ID453に対応する。
ポートID213は、パケット40を受信したイーサネットIF101のポートの識別子を示す。ポートID213は、装置内ヘッダ45の受信ポートID452に対応する。
VLAN ID214は、パケットに格納されるVLAN IDを示す。VLAN ID214は、パケット40に含まれるVLANタグ403の値に対応する。
図9は、本実施例1の入力ヘッダテーブル22を示す説明図である。
入力ヘッダテーブル22は、コネクションID221、VLANタグ処理222及びVLANタグ223を含む。入力ヘッダテーブル22は、コネクションID221を検索キーとして、VLANタグ処理222とVLANタグ223とを示すエントリを検索するためのテーブルである。入力ヘッダテーブル22の値は、例えばネットワーク管理者等によって、あらかじめ設定される。
コネクションID221は、コネクションID211に対応する。VLANタグ処理222は、パケット40に実行するVLANタグ処理を示す。VLANタグ223は、VLANタグ処理222が示す処理に必要なパラメータを示す。
図10は、本実施例1のラベル設定テーブル23を示す説明図である。
ラベル設定テーブル23は、コネクションID231を検索キーとして、収容回線232、パス233、切替候補パス234、切替フラグ235及び切替失敗フラグ236とを示すエントリを検索するためのテーブルである。
コネクションID231、収容回線232、パス233及び切替候補パス234の値は、例えばネットワーク管理者等によって、あらかじめ設定される。切替フラグ235及び切替失敗フラグ236の値は、後述する処理において更新される。
コネクションID231は、コネクションID211及びコネクションID221に対応する。収容回線232は、パケット41のMPLSラベル414−2に格納される値に対応する。
パス233は、収容されるパス50の識別子を示す。切替候補パス234は、収容されるパス50の候補を示す。パス233及び切替候補パス234は、パケット41のMPLSラベル414−1に格納される値に対応する。
切替フラグ235は、パス233が示すパス50は、切り替え後に収容されたパス50であるか否かを示す。図10に示す切替フラグ235が‘1’である場合、パス233が示すパス50は、切り替え後に収容されたパス50である。
切替失敗フラグ236は、切り替え処理の結果、収容されるパスの切り替えに失敗したか否かを示す。図10に示す切替失敗フラグ236が‘1’であるエントリは、コネクションID231が示すコネクションの切り替え処理が行われたが、その結果切り替えに失敗したことを示す。
図11は、本実施例1の帯域監視テーブル24を示す説明図である。
帯域監視テーブル24は、パス241を検索キーとして、監視帯域242と、バケツの深さ243と、前回のトークン値244と、前回時刻245と、違反バイト数246とを示すエントリを検索するためのテーブルである。
パス241、監視帯域242及びバケツの深さ243は、例えばネットワーク管理者によって、あらかじめ設定される。前回のトークン値244、前回時刻245及び違反バイト数246は、後述する処理によって更新される。
パス241は、パス50の識別子を示し、パス233に対応する。監視帯域242は、パス50の各々を単位時間あたりに通過するパケット41の量に相当する。そして、監視帯域242は、パケット41の量をトークンによって示す。実施例1の監視帯域242には、後述するパス予測帯域テーブル26の確保帯域262と同じ値が設定される。
パケツの深さ243は、パス241が示すパス50に送信可能なトークンの最大量を示す。前回のトークン値244は、パケット41を前回転送した時に用いられたトークンの量を占示す。
前回時刻245は、前回パケット41を転送した際の時刻を示す。違反バイト数246は、転送できなかったパケット41のバイト数を示す。
図12は、本実施例1のコネクション予測帯域テーブル25を示す説明図である。
コネクション予測帯域テーブル25は、コネクションID251を検索キーとして、予測帯域252と、予測帯域253と、予測帯域254とを示すエントリを検索するためのテーブルである。
コネクション予測帯域テーブル25の値は、NMS20から送信される。装置管理部12は、定期的又はネットワーク管理者の任意のタイミングに、コネクション予測帯域テーブル25の値を受信し、受信した値をコネクション予測帯域テーブル25に格納する。
コネクションID251は、コネクションの識別子を示し、コネクションID211に対応する。予測帯域252と、予測帯域253と、予測帯域254とは、1日を3期間に分割する場合、3期間の各々においてコネクションID251が示すコネクションによるトラフィックの予測される帯域量(予測帯域)を示す。
図12に示すコネクション予測帯域テーブル25において、予測帯域252は、0〜8時における予測帯域を示し、予測帯域253は、8〜17時における予測帯域を示し、予測帯域254は、17〜24時における予測帯域を示す。
実施例1におけるNMS20は、早朝(0〜8時)、昼間(8〜17時)及び夜間(17〜24時)の3期間に、1日における期間を区切り、コネクションの各々によるトラヒック量の将来の予測値として、3期間におけるトラヒック量の予測帯域を算出する。
図13は、本実施例1のパス予測帯域テーブル26を示す説明図である。
パス予測帯域テーブル26は、パス261を検索キーとして、パス261が示すパス50の確保帯域262と、積算値263と、積算値264と、積算値265と、収容コネクションID266とを示すエントリを検索するためのテーブルである。
パス261及び確保帯域262は、例えばネットワーク管理者によって、あらかじめ設定される。積算値263と、積算値264と、積算値265と、収容コネクションID266とは、後述する処理によって更新される。
なお、装置管理部12は、コネクション予測帯域テーブル25及びラベル設定テーブル23に基づいて、積算値263と、積算値264と、積算値265と、収容コネクションID266とに、初期値を格納してもよい。具体的には、装置管理部12は、ラベル設定テーブル23のコネクションID231を、パス233とパス261が対応するパス予測帯域テーブル26の収容コネクションID266に、初期値として格納してもよい。
パス261は、パス50の識別子を示し、パス233及びパス241等と対応する。確保帯域262は、パス50に割り当てられた帯域を示す。
積算値263と、積算値264と、積算値265とは、1日を3期間に分割した場合、3期間の各々において予測帯域を積算した値を示す。積算値263は、0〜8時の予測帯域を示し、積算値264は、8〜17時の予測帯域を示し、積算値265は、17〜24時の予約帯域を示す。
収容コネクションID266は、パス261が示すパス50に収容されるコネクションを示し、すなわち、パス261が示すパス50に収容されるTE60(ユーザ)を示す。
スイッチ部11は、各NIF13のSWインタフェース102−1〜102−nからパケット41を受信し、受信したパケット41の出力先の情報(出力NIF ID、出力ポートID及び出力ラベル)を、パケット転送テーブル27から取得する。そして、スイッチ部11は、取得された出力先の情報に対応するSWインタフェース102に、受信したパケット41を転送する。この際、スイッチ部11は、受信したパケット41のMPLSラベル414−1の出力ラベル276を、取得された出力ラベルによって更新する。
図14は、本実施例1のパケット転送テーブル27を示す説明図である。
パケット転送テーブル27は、入力NIF ID271と入力ポートID272とパス273との組合せを検索キーとして、出力NIF ID274と出力ポートID275と出力ラベル276とを示すエントリを検索するためのテーブルである。パケット転送テーブル27の値は、例えばネットワーク管理者等によって、あらかじめ設定される。
入力NIF ID271は、装置内ヘッダ45の受信NIF ID453に対応し、入力ポートID272は、装置内ヘッダ45の受信ポートID452に対応し、パス273は、装置内ヘッダ45のMPLSラベル414−1に対応する。
スイッチ部11は、装置内ヘッダ45の受信NIF ID453の識別子、受信ポートID452の識別子、及び、パケット41のMPLSラベル414−1のLSP IDを用いて、パケット転送テーブル27を検索し、出力先に関する情報(出力NIF ID274と出力ポートID275と出力ラベル276と)を取得する。
SWインタフェース102は、スイッチ部11から受信したパケット41を受信した場合、出力パケット処理部104にパケット41を転送する。
出力パケット処理部104は、自らが属するNIF13の処理モードがイーサネット処理モードであると設定レジスタ106に設定される場合、受信したパケット41の宛先MACアドレス411と、送信元MACアドレス412と、イーサタイプ値413と、MPLSラベル414−1と、MPLSラベル414−2とを削除し、対応するイーサネットIF101にパケットを転送する。
一方、自らが属するNIF13の処理モードがMPLS処理モードであると設定レジスタ106に設定される場合、出力パケット処理部104は、受信したパケット41に処理を行うことなく、対応するイーサネットIF101にパケットをそのまま出力する。
図15は、本実施例1の入力パケット処理S100を示すフローチャートである。
図15は、入力パケット処理部103が入力されたパケットに実行する入力パケット処理S100を示す。
入力パケット処理部103は、自らが属するNIF13の処理モードを設定レジスタ106から取得し、取得された処理モードに従って実行処理を決定する(S111)。取得された処理モードがイーサネット処理モードである場合、入力パケット処理部103は、S112を実行することを決定する。また、取得された処理モードがMPLS処理モードである場合、入力パケット処理部103は、S120を実行することを決定する。
S120を実行することを決定した場合、入力パケット処理部103は、自らが属する通信装置10がパケット41を受信しかつパケット41を転送する中継装置であり、コネクションが収容されるパス50を変更する必要はない。このため、入力パケット処理部103は、パケット41をSWインタフェース102にそのまま転送する。そして、入力パケット処理部103は、S100を終了する。
S112において、入力パケット処理部103は、パケット40の装置内ヘッダ45とVLANタグ403とから各情報(受信ポートID、受信NIF ID及びVID)を抽出し、抽出された情報を用いて、コネクションID決定テーブル21を検索する。そして、S112において、入力パケット処理部103は、抽出された情報に対応するコネクションID211の値を特定する。
S112の後、入力パケット処理部103は、特定されたコネクションID211の値を装置内ヘッダ45のコネクションID451に格納する。そして、入力パケット処理部103は、入力ヘッダテーブル22及びラベル設定テーブル23を、特定されたコネクションID211の値によって検索し、検索されたエントリの内容を取得する(S113)。
S113の後、入力パケット処理部103は、取得された入力ヘッダテーブル22のエントリに従って、パケット40のVLANタグ403を編集する(S114)。
S114の後、入力パケット処理部103は、取得されたラベル設定テーブル23のエントリ等を用いて、後述するパス毎の帯域監視処理を行う(S200)。S200の結果、入力パケット処理部103は、受信したパケット40が通過する予定のパス50において、輻輳が発生するか否か、すなわち、パケット40を正常にパス50へ転送できるか否かを判定する(S115)。
具体的には、入力パケット処理部103は、S115において、受信したパケットが通過する予定のパス50に対応する違反バイト数246が設定レジスタ106に設定されたパラメータよりも多い場合、輻輳が発生し、パケット40を正常にパス50へ転送できないと判定する。
S115において、違反バイト数246が設定レジスタ106に設定されたパラメータ以下であると判定された場合、入力パケット処理部103は、後述する図16のS124を実行する。
S115において、違反バイト数246が設定レジスタ106に設定されたパラメータを超えると判定された場合、入力パケット処理部103は、取得されたラベル設定テーブル23の切替フラグ235が‘0’であるか否かを判定する(S116)。すなわち、入力パケット処理部103は、受信したパケット40のコネクションは、収容されるパスを既に切り替えられたコネクションであるか否かを判定する。
切替フラグ235が‘0’でない場合、入力パケット処理部103は、パケット40のコネクションが収容されるパスは既に切り替えられた後のパスであり、パスを切り替えることができないため、帯域超過をNMS20に通知する(S121)。そして、入力パケット処理部103は、後述する図16に示すS123を実行する。
NMS20は、S121において通信装置10から帯域超過を通知された場合、中継ネットワーク30から収集したトラフィックの帯域量に基づいて、中継ネットワーク30におけるパス50の各々へ、コネクションを割り当てなおしてもよい。そして、NMS20は、新たな割当てを示す情報を通信装置10に送信し、通信装置10の装置管理部12は、受信した情報に基づいて、ラベル設定テーブル23等を更新してもよい。
切替フラグ235が‘0’である場合、入力パケット処理部103は、S112において特定されたコネクションIDによってコネクション予測帯域テーブル25を検索し、エントリの内容を取得する(S117)。
S117の後、入力パケット処理部103は、S113において取得されたラベル設定テーブル23のエントリの切替候補パス234の値によって、パス予測帯域テーブル26を検索し、検索されたエントリの内容を取得する(S118)。
S118の後、入力パケット処理部103は、S117において取得されたエントリの予測帯域252と予測帯域253と予測帯域254とを、S118において取得されたエントリの積算値263と積算値264と積算値265とに、それぞれ期間毎に加算する(S119)。
図16は、本実施例1の入力パケット処理S100のうち、収容されるパス50を切り替える処理を示すフローチャートである。
S119の後、入力パケット処理部103は、S119において算出された加算値の全てが、パス予測帯域テーブル26の確保帯域262以下であるか否かを判定する(S122)。入力パケット処理部103は、加算値が確保帯域262以下であるか否かを判定することによって、パス50を切り替えた後、輻輳が発生する可能性があるか否かを判定することができる。
S119において算出された加算値のうち少なくとも一つが、パス予測帯域テーブル26の確保帯域262よりも大きい場合、いずれかの期間において将来輻輳が発生する可能性がある。このため、入力パケット処理部103は、S113において取得されたラベル設定テーブル23のエントリの切替失敗フラグ236を、切替えが失敗したことを示す‘1’によって更新する。また、入力パケット処理部103は、受信したパケット40が通過する予定のパス50に対応する帯域監視テーブル24のエントリの違反バイト数246をクリア(‘0’によって更新)する(S123)。
S122において、S119において算出された加算値の全てが、パス予測帯域テーブル26の確保帯域262以下である場合、将来輻輳が発生する可能性が低い。このため、入力パケット処理部103は、パケット40が収容されるパス50を切替え可能であるため、パス233に対応するパス予測帯域テーブル26の収容コネクションID266から、パケット40に対応するコネクションID211の値を削除する。
また、入力パケット処理部103は、切替候補パス234に対応するパス予測帯域テーブル26のエントリの、積算値263と積算値264と積算値265とに、パケット40のコネクションID211に対応するコネクション予測帯域テーブル25のエントリの予測帯域252と予測帯域253と予測帯域254とを、それぞれ期間毎に加算する。
さらに、入力パケット処理部103は、切替候補パス234に対応するパス予測帯域テーブル26のエントリの収容コネクションID266に、パケット40に対応するコネクションID211の値を追加する(S127)。
S127の後、入力パケット処理部103は、S113において検索されたラベル設定テーブル23のエントリの切替フラグ235を‘1’(切替え実施済)によって更新し、さらに、切替失敗フラグ236を‘0’(切替え成功)によって更新する。そして、入力パケット処理部103は、パスの切替えが発生したことをNMS20に通知する(S128)。
S123又はS128の後、入力パケット処理部103は、S113において検索されたラベル設定テーブル23のエントリの切替フラグ235が‘0’であるか否かを判定し(S124)、‘0’である場合、S113において検索されたラベル設定テーブル23のエントリのパス233を、付与ラベルとして保持する(S125)。
切替フラグ235が‘0’でない場合、入力パケット処理部103は、パケット40のコネクションID211が収容されるパスは、既に切り替えられた後のパスである。このため、入力パケット処理部103は、S113において検索されたラベル設定テーブル23のエントリの切替候補パス234の値を、付与ラベルとして保持する(S119)。
S125又はS119の後、入力パケット処理部103は、パケット40をパケット41のペイロード部405に格納する。そして、入力パケット処理部103は、パケット41の宛先MACアドレス411と送信元MACアドレス412とに設定レジスタ106から取得された設定値を格納し、イーサタイプ値413にMPLSであることを示す‘8847’(16進数)を格納する。また、入力パケット処理部103は、S125又はS129において保持された付与ラベルをMPLSラベル414−1に格納し、S113において検索されたラベル設定テーブル23のエントリの収容回線232をMPLSラベル414−2に格納する。そして、入力パケット処理部103は、パケット41をSWインタフェース102に転送し(S126)、S100を終了する(S130)。
図17は、本実施例1のパス毎の帯域監視処理S200を示すフローチャートである。
S114の後、入力パケット処理部103は、S113において取得されたラベル設定テーブル23のエントリのパス233を抽出する。そして、入力パケット処理部103は、抽出されたパス233によって帯域監視テーブル24を検索し、検索されたエントリの内容を取得する(S201)。
S201の後、入力パケット処理部103は、S201において取得されたエントリと、時刻カウンタ1031の値と、”現在のトークン値=前回のトークン値244−監視帯域242×(時刻カウンタ1031−前回時刻245)”の計算式とを用いて、現在のトークン値を算出し、保持する(S202)。
S202の後、入力パケット処理部103は、S202において算出された現在のトークン値が‘0’よりも小さいか否かを判定する(S203)。
S202において算出された現在のトークン値が‘0’より小さい場合、通信装置10がパス50(S114において抽出されたパス233に対応する)に送信すべきパケットは残っていないため、入力パケット処理部103は、現在のトークン値として‘0’を保持する(S208)。
S208の後、又は、S202において算出された現在のトークン値が‘0’以上である場合、入力パケット処理部103は、S201において取得されたエントリに基づいて、(保持する現在のトークン値+装置内ヘッダ45のパケット長454)の値を算出する。そして、算出された値がバケツの深さ243よりも大きいか否かを判定する(S204)。
(保持する現在のトークン値+装置内ヘッダ45のパケット長454)の値が、バケツの深さ243以下である場合、入力パケット処理部103は、(保持する現在のトークン値+パケット長454)の値を現在のトークン値として再度保持する。そして、入力パケット処理部103は、S201において取得された帯域監視テーブル24のエントリの違反バイト数246を、違反バイト数として保持する(S205)。
(保持する現在のトークン値+装置内ヘッダ45のパケット長454)の値が、バケツの深さ243よりも大きい場合、パケット40をパス50へ出力した場合、輻輳が発生する。このため、入力パケット処理部103は、S201において取得された帯域監視テーブル24のエントリの違反バイト数246とパケット長454とを加算した結果を、違反バイト数として保持する(S209)。
S205又はS209の後、入力パケット処理部103は、S201において検索された帯域監視テーブル24のエントリの値を更新する。具体的には、入力パケット処理部103は、保持する現在のトークン値によって前回のトークン値244を更新し、現在の時刻カウンタ1031の値によって前回時刻245を更新し、保持する違反バイト数によって違反バイト数246を更新する(S206)。S206の後、入力パケット処理部103は、S200の処理を終了する(S210)。
図17に示す処理によって、入力パケット処理部103は、入力されたパケット40をパス50に送信した場合、輻輳が発生するか否かを判定できる。そして、輻輳が発生する場合、入力パケット処理部103は、図15及び図16に示す処理によって、入力されたパケット40のコネクションが収容されるパスを切り替えるか否かを、パス毎の予測帯域の積算値によって判定する。これによって、適切にパス50にコネクションを割り当てることができ、パス50を有効に活用することができる。
さらに、図15〜図17に示す処理は、NMS20から送信された予測帯域に基づき、通信装置10によって実行されるため、通信装置10は、輻輳が発生した場合、NMS20によるコネクションの再割り当てを待たずに、パケット40が入力された時点で速やかにコネクションを割り当てることができる。
また、入力パケット処理部103は、予測帯域を用いてパス50の切り替えを判定するため、NMS20による帯域の予測が外れた場合においても、最低限のパス50を切り替えることによって、NMS20が過剰な帯域をパス50にあらかじめ割り当てておく必要がなくなる。
また、入力パケット処理部103は、複数の期間における予測帯域を用いてパス50の切り替え可否を判定するため、将来の長期間にわたり輻輳が発生しないように、パス50を切り替えることができる。
図18は、本実施例1のNIF管理部105によるポーリング処理S300を示すフローチャートである。
S300は、装置管理部12から指示されたタイミングにおいて開始され、後述のS301、S302、及び、S317の処理によって、繰り返し実行される。このため、NIF管理部105は、切り替えが失敗したことを速やかに検知することができる。
NIF管理部105は、保持する内部パラメータiを‘0’に初期化し(S301)、保持する内部パラメータiに‘1’を加算する(S302)。
S302の後、NIF管理部105は、保持する内部パラメータiを用いてラベル設定テーブル23を検索し、検索されたエントリの内容を取得する(S303)。例えば、NIF管理部105は、内部パラメータiを用いて、ラベル設定テーブル23の最上段のエントリからi番目のエントリの内容を取得する。
S303の後、NIF管理部105は、取得されたエントリの切替フラグ235が‘0’であり、かつ、切替失敗フラグ236が‘1’であるか否かを判定する(S304)。
切替フラグ235が‘0’ではない、又は、切替失敗フラグ236が‘1’ではない場合、NIF管理部105は、入力パケット処理部103によるパスの切換えは行われていない、又は、失敗していないと判定し、後述する図19のS317を実行する。そして、NIF管理部105がラベル設定テーブル23のエントリに、S304の処理を繰り返し実行することによって、NIF管理部105は、入力パケット処理部103がパスの切替えに失敗したことを速やかに検出することができ、NIF管理部105が速やかに輻輳を解消することができる。
切替フラグ235が‘0’であり、かつ、切替失敗フラグ236が‘1’である場合、NIF管理部105は、入力パケット処理部103によるパスの切替えが失敗したことを検出する。そして、NIF管理部105は、以降の処理によって、輻輳が検出された際に受信したパケット40のコネクション以外のコネクション(候補コネクション)が収容されるパス50を、切り替えるか否かを決定する。NIF管理部105は、取得されたラベル設定テーブル23のエントリのパス233を用いて、パス予測帯域テーブル26を検索し、検索されたエントリの内容を取得する(S305)。
S305において取得されたエントリの収容コネクションID266の中に、S303において取得されたエントリのコネクションID231(内部パラメータiに対応するコネクションID231)以外のコネクションIDが含まれる場合、NIF管理部105は、内部パラメータiに対応するコネクションID231以外の、収容コネクションID266のコネクションIDを、候補コネクショングループとして保持する。
S305において取得されたエントリの収容コネクションID266の中に内部パラメータiに対応するコネクションID231以外のコネクションIDが含まれない場合、NIF管理部105は、候補コネクショングループとしてnullを保持する(S306)。
S306の後、NIF管理部105は、保持する候補コネクショングループがnullであるか否かを判定する(S307)。保持する候補コネクショングループがnullである場合、NIF管理部105は、切り替える候補コネクションがなく、入力パケット処理部103による切替え処理への対応が不可であると判定し、帯域超過をNMS20に通知する(S309)。そして、後述する図19のS317を実行する。
NMS20は、S309において通信装置10から帯域超過を通知された場合、S121と同じく、中継ネットワーク30から収集したトラフィックの帯域量に基づいて、パス50へコネクションの各々を割り当てなおしてもよい。NIF管理部105は、帯域超過をNMS20に通知することによって、中継ネットワーク30における全体的なパス50の割り当てを、NMS20に実行させることができ、適切なパス50の割り当てが実現する。
保持する候補コネクショングループがnullでない場合、保持する候補コネクショングループの中から一つを候補コネクションIDとして選択する。そして、NIF管理部105は、選択された候補コネクションIDによってコネクション予測帯域テーブル25及びラベル設定テーブル23を検索し、検索されたエントリの内容を取得する(S308)。
図19は、本実施例1のポーリング処理S300において収容されるパス50を切り替える処理を示すフローチャートである。
S308の後、NIF管理部105は、S308において取得されたラベル設定テーブル23の切替フラグ235が‘0’であり、かつ、切替失敗フラグ236が‘0’であるか否かを判定する(S310)。
切替フラグ235が‘0’であり、かつ、切替失敗フラグ236が‘1’である場合、NIF管理部105は、S308において取得されたラベル設定テーブル23の切替候補パス234によって、パス予測帯域テーブル26を検索し、検索されたエントリの内容を取得する(S311)。そして、NIF管理部105は、取得されたエントリの積算値263と積算値264と積算値265とに、S308において取得されたコネクション予測帯域テーブル25のエントリの予測帯域252と予測帯域253と予測帯域254とを、それぞれ期間毎に加算する(S312)。
S312の後、NIF管理部105は、S312による複数の加算値の全てが、S311において取得されたパス予測帯域テーブル26の確保帯域262以下であるか否かを判定する(S313)。
S310において切替フラグ235が‘0’でないか、若しくは、切替失敗フラグ236が‘1’でないと判定された場合、又は、S312によって算出された複数の加算値の中に確保帯域262を超える加算値がある場合、NIF管理部105は、候補コネクションを収容するパス50を切り替えることができない。このため、NIF管理部105は、保持する候補コネクショングループの中から、選択された候補コネクションIDを削除する。
削除後、候補コネクショングループにコネクションIDが含まれない場合、NIF管理部105は、候補コネクショングループとしてnullを保持する(S318)。S318の後、NIF管理部105は、S307を実行する。
S312において算出された複数の加算値の全てが、取得された確保帯域262以下である場合、将来の長期間にわたり輻輳が発生しないため、NIF管理部105は、候補コネクションを収容するパス50を切替えることができると判定する。そして、NIF管理部105は、選択された候補コネクションIDのパス233に対応する、パス予測帯域テーブル26の収容コネクションID266の中から、選択された候補コネクションIDを削除する。
そして、NIF管理部105は、選択された候補コネクションIDの切替候補パス234に対応するパス予測帯域テーブル26のエントリの値を更新する。具体的には、NIF管理部105は、S308において選択された候補コネクションIDを、収容コネクションID266に追加し、積算値263と積算値264と積算値265とを、S312において算出された加算値の各々によって更新する(S314)。
S314の後、NIF管理部105は、選択された候補コネクションIDに対応するラベル設定テーブル23の切替フラグ235を‘1’によって更新し、切替失敗フラグ236を‘0’によって更新する(S315)。
S315の後、NIF管理部105は、保持する内部パラメータiに対応するラベル設定テーブル23のエントリの切替フラグ235を‘0’によって更新し、切替失敗フラグ236を‘0’によって更新する。そして、NIF管理部105は、切替えが発生したことをNMS20に通知する(S316)。
S316の後、NIF管理部105は、保持する内部パラメータiがラベル設定テーブル23のエントリの数以上であるか否かを判定する(S317)。保持する内部パラメータiがラベル設定テーブル23のエントリの数以上である場合、NIF管理部105は、S301から処理を継続する。
S317において、保持する内部パラメータiがラベル設定テーブル23のエントリの数より小さい場合、NIF管理部105は、S302から処理を継続する。
図18及び図19に示す処理によれば、NIF管理部105は、輻輳が検出された際に受信したパケットのコネクション以外のコネクションから、収容されるパス50を切り替えるコネクションを抽出することができる。このため、より適切にコネクションをパス50に割り当てることが可能である。
また、図18及び図19に示す処理を、通信装置10が行うことによって、NMS20がパスを割り当てるよりも速やかにパス50を割り当てることができる。
なお、前述の実施例1において、入力パケット処理部103とNIF管理部105とは、異なるタイミングにおいて起動する異なる処理部である。これによって、通信装置10によって受信されたパケット40は、図18及び図19に示す処理を待つことなく、図16に示す処理が終了後、速やかに転送される。
しかし、入力パケット処理部103とNIF管理部105とは一つの処理部(例えば、入力パケット処理部103)によって実装されてもよく、一つの処理部は、図15〜図17に示す処理の後、図18及び図19を実行してもよい。これによって、実施例1の処理を実行する処理部を通信装置10に簡易に実装することができる。
さらに、入力パケット処理部103は、図16に示すS123において、受信したパケット40のコネクションが収容されるパスを切り替えられないと判定した後、図18に示すS303を実行してもよい。これによって、入力パケット処理部103は、受信したパケット40が転送される予定のパスに収容されるコネクションのうち、受信したパケット40のコネクション以外のコネクション(候補コネクション)から、パス50を切り替えることによって輻輳が解消できるコネクションを抽出することができる。
なお、このS303において、パラメータiは、S112において特定されたコネクションIDを含むラベル設定テーブル23のエントリを示す。そして、入力パケット処理部103は、S316又はS309を実行した後、S317を実行せずに、図16に示すS124を実行してもよい。
このように、入力パケット処理部103が、候補コネクションからパス50を切り替えるコネクションを抽出することによって、入力パケット処理部103は、より適切なパスの割り当てによって、パケット40をパケット41として速やかに転送することができる。
実施例1によれば、通信装置10が、各ユーザによるトラヒックの予測帯域を用いてコネクションをパス50に割り当てるため、NMS20による帯域の予測が外れた場合も、最低限のパス50の切替えにより輻輳を解消することができる。そして、NMS20が過剰に多い帯域をパス50に割り当てる必要がなくなり、ネットワークリソースを効率よく利用することができる。
また、この結果、実施例1の通信装置10は、過剰なオーバエンジニアリングを行うことなく、高品質なネットワークサービスを提供できる。
また、NMS20による帯域の予測が外れた場合も、各パスにおいて輻輳が発生したことを通信装置10が検出し、通信装置10が、輻輳が発生したパス50に収容されるコネクションを他のパス50に自律的に切り替える。これによって、輻輳によるサービス品質の低下を高速に復旧することが可能となる。
さらに、通信装置10がパス50の切替え処理において、各ユーザ(コネクション)及び各パス50の期間ごとのトラヒックの予測帯域を用いることにより、ユーザの収容方法を切り替えた瞬間だけでなく、その後のトラヒックの変動によって輻輳が再発することを、長期間防止することが可能となる。また、これによって、通信装置10は、ユーザのトラヒックを高密度にパス50に収容することができる。
なお、NMS20は、主にソフトウェアによって実装され、また、NMS20がパス50を切り替える場合大量のデータを用いることが一般的である。このため、実施例1の通信装置10は、NMS20を用いるよりも迅速に、輻輳に対応することができる。
実施例2と実施例1との相違点は、実施例2の通信装置10が、コネクションの各々にあらかじめ設定されたサービスレベルに従って、コネクションが収容されるパス50を切り替える点である。
図20は、本実施例2の通信装置10の構成を示すブロック図である。
実施例2の通信装置10と実施例1の通信装置10との相違点は、実施例2のコネクション予測帯域テーブル250が、実施例1のコネクション予測帯域テーブル25の内容とコネクション(ユーザ)のサービスレベルとを保持する点である。その他の通信装置10の構成は、実施例1と実施例2とで同じである。
図21は、本実施例2のコネクション予測帯域テーブル250を示す説明図である。
コネクション予測帯域テーブル250は、コネクションID251を検索キーとして、予測帯域252と、予測帯域253と、予測帯域254と、サービスレベル2505とを示すエントリを検索するためのテーブルである。サービスレベル2505は、コネクションID251が示すコネクションにあらかじめ設定されるサービスレベルを示す。
例えば、図1に示すパス50Aとパス50Bとが、通信路の距離などに明確に差があり、パス50Aは遅延が少なく、パス50Bは遅延が大きい場合、コネクションに割り当てられたサービスレベルによっては、パスを切り替える必要がないコネクションが発生する。このため、実施例2の入力パケット処理部103及びNIF管理部105は、サービスレベル2505に従って収容されるパス50を選択する。
具体的には、入力パケット処理部103及びNIF管理部105は、サービスレベル2505が遅延保証などであるコネクションを、遅延が少ないパス50Aのみに収容し、このようなコネクションを遅延が大きいパス50Bに切り替えない。また、入力パケット処理部103及びNIF管理部105は、サービスレベル2505がベストエフォートのコネクションを、パス50Aの帯域が空いている場合にパス50Aに収容し、空いていない場合パス50Bに収容する。
このため、コネクションのパスを切り替える必要が発生した場合、実施例2の入力パケット処理部103及びNIF管理部105は、サービスレベル2505が低い(本実施例では、ベストエフォートサービスが遅延保証よりも低い)コネクションのパスを優先的に切り替える。
図22は、本実施例2の入力パケット処理S100を示すフローチャートである。
実施例2の入力パケット処理S100と実施例1の入力パケット処理S100との相違点は、実施例2の入力パケット処理S100におけるS117の後、S401が実行される点である。実施例2の入力パケット処理S100におけるS401以外の処理は、図15及び図16に示す入力パケット処理S100と同じである。
入力パケット処理部103は、S401において、S117において取得されたエントリのサービスレベル2501が、ベストエフォートを示すか否かを判定する。サービスレベル2501がベストエフォートを示す場合、入力パケット処理部103は、収容されるパス50の切り替え処理を継続するため、S118を実行する。サービスレベル2501がベストエフォートを示さない場合、入力パケット処理部103は、収容されるパス50を切り替えないため、S121を実行する。
図23は、本実施例2のポーリング処理S300において収容されるパス50を切り替える処理を示すフローチャートである。
実施例2のポーリング処理S300と実施例1のポーリング処理S300との相違点は、実施例2のポーリング処理S300におけるS308の後、S501が実行される点である。実施例2のポーリング処理S300におけるS501以外の処理は、図18及び図19に示すポーリング処理S300と同じである。
NIF管理部105は、S501において、S308において取得されたエントリのサービスレベル2501が、ベストエフォートを示すか否かを判定する。サービスレベル2501がベストエフォートを示す場合、NIF管理部105は、候補コネクションが収容されるパス50の切り替え処理を継続するため、S310を実行する。サービスレベル2501がベストエフォートを示さない場合、NIF管理部105は、候補コネクションが収容されるパス50を切り替えないため、S318を実行する。
実施例2によれば、収容されるパス50を切替える処理において、各ユーザのサービスレベルに応じた経路の切替えを適切に行うことができる。これにより、帯域だけでなく遅延などの他のパラメータにおいてもサービスレベルを劣化させることなく、輻輳を解消することができる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての行使を備えるものに限定されるものではない。
また、上記の各構成、機能、処理部、処理手順等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現されてもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現されてもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、若しくはSSD(Solid State Drive)等の記録装置、又は、ICカード、SDカード、若しくはDVD等の記録媒体に置くことができる。
また、制御線及び情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
10 通信装置
20 ネットワーク管理システム(NMS)
50 パス(パス)
60 ユーザ端末(TE)
50 サーバ(SN)
13 ネットワークインタフェースボード(NIF)
11 スイッチ部
27 パケット転送テーブル
12 装置管理部
101 イーサネットIF
102 SWインタフェース
103 入力パケット処理部
104 出力パケット処理部
105 NIF管理部
106 設定レジスタ
21 コネクションID決定テーブル
22 入力ヘッダテーブル
23 ラベル設定テーブル
24 帯域監視テーブル
25 コネクション予測帯域テーブル
26 パス予測帯域テーブル
20 ネットワーク管理システム(NMS)
50 パス(パス)
60 ユーザ端末(TE)
50 サーバ(SN)
13 ネットワークインタフェースボード(NIF)
11 スイッチ部
27 パケット転送テーブル
12 装置管理部
101 イーサネットIF
102 SWインタフェース
103 入力パケット処理部
104 出力パケット処理部
105 NIF管理部
106 設定レジスタ
21 コネクションID決定テーブル
22 入力ヘッダテーブル
23 ラベル設定テーブル
24 帯域監視テーブル
25 コネクション予測帯域テーブル
26 パス予測帯域テーブル
Claims (14)
- 複数のパスに接続され、受信したパケットを前記複数のパスの一つへ転送する通信装置であって、
前記通信装置は、
前記パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持するコネクション予測値記憶部と、
前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持する設定記憶部と、
前記複数のパスの各々におけるトラヒック量の予測値を保持するパス予測値記憶部と、
パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定するパケット処理部と、
前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送するスイッチ部と、を有することを特徴とする通信装置。 - 請求項1に記載の通信装置であって、
前記通信装置は、
前記パスを通過可能なパケットのトラヒック量を保持する帯域監視記憶部を有し、
前記パケット処理部は、
前記パケットを受信した場合、前記第1のパスを通過可能なパケットのトラヒック量と、前記受信したパケット長と、に基づいて、前記受信したパケットが前記第1のパスを通過する際に輻輳が発生するか否かを判定し、
前記受信したパケットが前記第1のパスを通過する際に輻輳が発生すると判定された場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、前記第2のパスにおけるトラヒック量の予測値と、に基づいて、前記第1のパスから前記第2のパスへ切り替えるか否かを決定することを特徴とする通信装置。 - 請求項2に記載の通信装置であって、
前記パス予測値記憶部は、前記複数のパスの各々におけるトラヒック上限量を保持し、
前記パケット処理部は、
前記受信したパケットが属するコネクションにおけるトラヒック量の予測値を、前記第2のパスにおけるトラヒック量の予測値に加算し、
前記加算された結果が、前記第2のパスの上限量を超えない場合、前記第1のパスから前記第2のパスへ切り替えると決定することを特徴とする通信装置。 - 請求項3に記載の通信装置であって、
前記コネクション予測値記憶部は、複数の期間の各々における、前記トラヒック量の予測値を保持し、
前記パス予測値記憶部は、前記複数の期間の各々における、前記トラヒック量の予測値を保持し、
前記パケット処理部は、
前記受信したパケットが属するコネクションにおけるトラヒック量の予測値を、前記第2のパスにおけるトラヒック量の予測値に、前記複数の期間の各々において加算することによって、複数の第1の加算結果を取得し、
前記複数の第1の加算結果の全てが、前記第2のパスの上限量以下である場合、前記第1のパスから前記第2のパスへ切り替えると決定することを特徴とする通信装置。 - 請求項4に記載の通信装置であって、
前記パケット処理部は、
前記複数の第1の加算結果の少なくとも一つが前記第2のパスの上限量を超える場合、前記第1のパスに収容されるパケットのコネクションのうち、前記受信したパケットが属するコネクション以外のコネクションを、候補コネクションとして抽出し、
前記候補コネクションにおけるトラヒック量の予測値と、前記候補コネクションに属するパケットが収容されるパスの代替パスである第3のパスにおけるトラヒック量の予測値と、に基づいて、前記候補コネクションが収容されるパスを、前記第3のパスに切り替えるか否かを決定することを特徴とする通信装置。 - 請求項4又は5に記載の通信装置であって、
前記通信装置は、前記パケットの出力先を管理する管理部を有し、
前記パケット処理部は、前記複数の第1の加算結果の少なくとも一つが前記第2のパスの上限量を超える場合、前記設定記憶部に、前記パスの切替えが失敗したか否かを示すフラグを格納し、
前記管理部は、
前記設定記憶部に前記パスの切替えが失敗したことを示すフラグが格納されている場合、前記第1のパスに収容されるパケットのコネクションのうち、前記受信したパケットが属するコネクション以外の少なくとも一つのコネクションを、候補コネクションとして抽出し、
前記候補コネクションにおけるトラヒック量の予測値と、前記候補コネクションに属するパケットが収容されるパスの代替パスである第3のパスにおけるトラヒック量の予測値と、に基づいて、前記候補コネクションが収容されるパスを前記第3のパスに切り替えるか否かを決定することを特徴とする通信装置。 - 請求項6に記載の通信装置であって、
前記管理部は、
前記設定記憶部を参照し、
前記設定記憶部にパスの切替えが失敗したことを示すフラグが格納されるか否かを判定し、
前記候補コネクションが収容されるパスを第3のパスに切り替えると決定した場合、前記設定記憶部に格納されたフラグを、前記コネクションが収容されるパスの切り替えが成功したことを示すフラグに更新することを特徴とする通信装置。 - 請求項7に記載の通信装置であって、
前記コネクション予測値記憶部は、前記コネクションに提供するサービスレベルを、さらに保持し、
前記パケット処理部は、前記サービスレベルが前記パスの切替えが必要ないことを示す場合、前記第1のパスを前記第2のパスへ切り替えないことを決定することを特徴とする通信装置。 - 請求項8に記載の通信装置であって、
前記サービスレベルが遅延保証を示す場合、前記パケット処理部は、前記第1のパスを前記第2のパスへ切り替えないことを決定し、
前記サービスレベルがベストエフォートを示す場合、受信したパケットが属するコネクションにおけるトラヒック量の予測値と、前記受信したパケットが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、に基づいて、前記第1のパスを前記第2のパスへ切り替えるか否かを決定することを特徴とする通信装置。 - 請求項9に記載の通信装置であって、
前記通信装置は、ネットワーク管理装置に接続され、
前記管理部は、前記複数の第2の加算結果の少なくとも一つが、前記第3のパスの上限量を超える場合、パスの切り替えが不可であることを、前記ネットワーク管理装置に通知することを特徴とする通信装置。 - 複数のパスに接続され、受信したパケットを前記複数のパスの一つへ転送する通信装置と、前記通信装置に接続されるネットワーク管理装置とを有する通信システムであって、
前記通信装置は、
前記ネットワーク管理装置から、前記パケットが属するコネクションにおけるトラヒック量の予測値を受信するインタフェースと、
前記パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持するコネクション予測値記憶部と、
前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持する設定記憶部と、
前記複数のパスの各々におけるトラヒック量の予測値を保持するパス予測値記憶部と、
パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定するパケット処理部と、
前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送するスイッチ部と、を有することを特徴とする通信システム。 - 請求項11に記載の通信システムであって、
前記通信装置は、
前記パスを通過可能なパケットのトラヒック量を保持する帯域監視記憶部を有し、
前記パケット処理部は、
前記パケットを受信した場合、前記第1のパスを通過可能なパケットのトラヒック量と、前記受信したパケット長と、に基づいて、前記受信したパケットが前記第1のパスを通過する際に輻輳が発生するか否かを判定し、
前記受信したパケットが前記第1のパスを通過する際に輻輳が発生すると判定された場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、前記第2のパスにおけるトラヒック量の予測値と、に基づいて、前記第1のパスから前記第2のパスへ切り替えるか否かを決定することを特徴とする通信システム。 - 複数のパスに接続され、受信したパケットを前記複数のパスの一つへ転送する通信装置における通信方法であって、
前記通信装置は、
前記パケットが属するコネクションの識別子と、当該コネクションにおけるトラヒック量の予測値と、を保持するコネクション予測値記憶部と、
前記コネクションが収容されるパスの識別子と、当該パスの代替となるパスの識別子と、を保持する設定記憶部と、
前記複数のパスの各々におけるトラヒック量の予測値を保持するパス予測値記憶部と、
前記パケットを処理するパケット処理部と、を有し、
前記方法は、
前記パケット処理部が、パケットを受信した場合、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、当該コネクションが収容される第1のパスの代替となる第2のパスにおけるトラヒック量の予測値と、前記受信したパケットの量と、に基づいて、前記受信したパケットが属するコネクションが収容されるパスを前記第1のパスから前記第2のパスへ切り替えるか否かを決定する第1の手順と、
前記パケット処理部が、前記決定に従って、前記第1のパス又は前記第2のパスに、前記受信したパケットを転送する第2の手順と、を含むことを特徴とする通信方法。 - 請求項13に記載の通信方法であって、
前記通信装置は、前記パスを通過可能なパケットのトラヒック量を保持する帯域監視記憶部を有し、
前記第1の手順は、
前記パケット処理部が、前記パケットを受信した場合、前記第1のパスを通過可能なパケットのトラヒック量と、前記受信したパケット長と、に基づいて、前記受信したパケットが前記第1のパスを通過する際に輻輳が発生するか否かを判定する手順と、
前記受信したパケットが前記第1のパスを通過する際に輻輳が発生すると判定された場合、前記パケット処理部が、前記受信したパケットが属するコネクションにおけるトラヒック量の予測値と、前記第2のパスにおけるトラヒック量の予測値と、に基づいて、前記第1のパスから前記第2のパスへ切り替えるか否かを決定する手順と、を含むことを特徴とする通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013070752A JP2014195185A (ja) | 2013-03-29 | 2013-03-29 | 通信装置、通信システム、及び、通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013070752A JP2014195185A (ja) | 2013-03-29 | 2013-03-29 | 通信装置、通信システム、及び、通信方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014195185A true JP2014195185A (ja) | 2014-10-09 |
Family
ID=51840150
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013070752A Pending JP2014195185A (ja) | 2013-03-29 | 2013-03-29 | 通信装置、通信システム、及び、通信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2014195185A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024134817A1 (ja) * | 2022-12-22 | 2024-06-27 | 日本電信電話株式会社 | 通信制御装置、通信システム及び通信制御方法 |
-
2013
- 2013-03-29 JP JP2013070752A patent/JP2014195185A/ja active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024134817A1 (ja) * | 2022-12-22 | 2024-06-27 | 日本電信電話株式会社 | 通信制御装置、通信システム及び通信制御方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210218665A1 (en) | Resilient network communication using selective multipath packet flow spraying | |
JP5850131B2 (ja) | ネットワークシステム、リソース使用率改善方法 | |
CN106998302B (zh) | 一种业务流量的分配方法及装置 | |
US8630171B2 (en) | Policing virtual connections | |
US20150372911A1 (en) | Communication path management method | |
US8174980B2 (en) | Methods, systems, and computer readable media for dynamically rate limiting slowpath processing of exception packets | |
US20150334024A1 (en) | Controlling Data Rates of Data Flows Based on Information Indicating Congestion | |
US8954691B2 (en) | Identifying unallocated memory segments | |
US20140098674A1 (en) | Communication system, control device, and processing rule setting method and program | |
US10389636B2 (en) | Technologies for adaptive routing using network traffic characterization | |
WO2016194089A1 (ja) | 通信ネットワーク、通信ネットワークの管理方法および管理システム | |
CN109005126B (zh) | 数据流的处理方法、设备和计算机可读存储介质 | |
JP5968841B2 (ja) | ネットワーク装置及びプロセッサの監視方法 | |
JP2015122680A (ja) | 論理ネットワークの構築方法、および、ネットワークシステム | |
US20210273952A1 (en) | Attack response point selecting apparatus and attack response point selecting method | |
JP2016116184A (ja) | 網監視装置および仮想ネットワーク管理方法 | |
US20140010233A1 (en) | Communication device, method for controlling the communication device, and communication system | |
Rashid | Sorted-GFF: An efficient large flows placing mechanism in software defined network datacenter | |
US8553539B2 (en) | Method and system for packet traffic congestion management | |
JP2020136925A (ja) | ネットワークコントローラ装置、ネットワーク制御システム、通信ネットワークの制御方法及びプログラム | |
JP5951147B2 (ja) | 情報処理装置及び情報処理方法及びプログラム | |
JP2014195185A (ja) | 通信装置、通信システム、及び、通信方法 | |
KR101541168B1 (ko) | 소프트웨어 정의 네트워크 환경에서 컨트롤러의 플로우에 대한 경로 제어방법 | |
JP6829156B2 (ja) | ネットワーク負荷分散装置および方法 | |
US11720387B2 (en) | Managing communication rates between applications in a tiered application computing environment |