[go: up one dir, main page]

JP6076569B2 - コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム - Google Patents

コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム Download PDF

Info

Publication number
JP6076569B2
JP6076569B2 JP2016557335A JP2016557335A JP6076569B2 JP 6076569 B2 JP6076569 B2 JP 6076569B2 JP 2016557335 A JP2016557335 A JP 2016557335A JP 2016557335 A JP2016557335 A JP 2016557335A JP 6076569 B2 JP6076569 B2 JP 6076569B2
Authority
JP
Japan
Prior art keywords
connection
packet
interface
connection path
input
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2016557335A
Other languages
English (en)
Other versions
JPWO2016098261A1 (ja
Inventor
古谷 信司
信司 古谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Application granted granted Critical
Publication of JP6076569B2 publication Critical patent/JP6076569B2/ja
Publication of JPWO2016098261A1 publication Critical patent/JPWO2016098261A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラムに関するものである。
従来、Openflow(登録商標)を始めとする、通信を行うにはフローを確立する必要があり、フロー制御はネットワークシステムを担当するコントローラが行うシステムがある(例えば、非特許文献1参照)。このシステムは、近年ではSDN(Software・Defined・Network)と呼ばれるアーキテクチャにおいて利用されている。
インタフェースを介して受信したデータフレーム内のフロー識別子に基づきフローを識別し、該フローと、該インタフェースで本来受信するはずのフローが一致しない場合、既定外のインタフェースでデータフレームを受信したと判断するシステムがある(例えば、特許文献1参照)。
特開2013−115695号公報
"OpenFlow Switch Specification Version 1.0.0", OPEN NETWORKING FOUNDATION, December 31, 2009
従来のシステムでは、端末間の1つのコネクションに対して、往路及び復路で別々のフローが設定されることを防止できない。1つのコネクションに対しては、双方向の1つのフローが設定されれば足りる。双方向の2つのフローが設定された場合、ネットワークのリソースが2倍消費されることになり、無駄が生じる。片方向の2つのフローが設定された場合、管理負荷が増すことになる。
本発明は、ネットワークのリソースの消費量を削減することを目的とする。
本発明の一の態様に係るコネクションパス管理システムは、
端末間のコネクションを識別する情報を含むパケット群が入出力されるネットワークのインタフェース間に、当該パケット群を転送するための双方向のコネクションパスを、当該コネクションに対応付けて設定する設定部と、
1つのコネクションを識別する情報を含む第1パケットが入力されたインタフェースである第1入力インタフェースと、前記第1パケットが出力されたインタフェースである第1出力インタフェースとの間のコネクションパスが前記1つのコネクションに対応付けて前記設定部により設定された後、前記1つのコネクションを識別する情報を含み前記第1パケットと逆方向に送信された第2パケットが前記第1出力インタフェースと異なるインタフェースである第2入力インタフェースに入力された場合、前記第1入力インタフェースと前記第2入力インタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除する集約部とを備える。
本発明では、端末間の1つのコネクションに対して複数のコネクションパスが設定されるような状況が発生したときに、それら複数のコネクションパスが1つに集約される。このため、本発明によれば、ネットワークのリソースの消費量を削減することが可能となる。なお、「コネクションパス」は、前述したフローと同じものである。
一般的なネットワーク構成例を示す図。 実施の形態1との比較のためのネットワーク構成例を示す図。 実施の形態1との比較のためのネットワーク構成例を示す図。 実施の形態1との比較のためのネットワーク構成例を示す図。 実施の形態1に係るコネクションパス管理システムの構成を示すブロック図。 実施の形態1に係るコネクションパス管理システムの動作を示すフローチャート。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1の変形例に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 実施の形態1に係るネットワーク構成例を示す図。 本発明の実施の形態に係るネットワーク制御装置のハードウェア構成例を示す図。
以下、本発明の実施の形態について、図を用いて説明する。なお、各図中、同一又は相当する部分には、同一符号を付している。実施の形態の説明において、同一又は相当する部分については、その説明を適宜省略又は簡略化する。
実施の形態1.
本実施の形態は、詳細なコネクションのパケット識別情報に基づくコネクションパスを確立可能なネットワークシステムと、冗長関係にある複数の機器が稼働していてコネクションの通信経路が往路と復路とで異なる可能性のあるネットワークシステムとが、複数の冗長なインタフェースや機器で接続されたときのコネクションパス制御に関するものである。「経路が同じ」又は「同経路」とは、通信方向に関係なく、パケットが同じノード又は機器を通って送受信されることである。「経路が異なる」又は「異経路」とは、「経路が同じ」又は「同経路」の反対である。
まず、冗長構成をとるネットワークにおいて、往路と復路とが異なる経路を通る現象について示す。図1を参照して、その現象が生じるネットワーク構成を説明する。図1の例は、一般的な例である。
Router−A、Router−B、Router−E、Router−Fは、ルータである。Switch−C、Switch−D、Switch−G、Switch−Hは、レイヤ2スイッチである。Subnet−Zは、IP(Internet・Protocol)サブネットである。
IP−1は、Switch−Cに接続された、Router−Eのインタフェースである。IP−2は、Switch−Dに接続された、Router−Fのインタフェースである。IP−3は、Switch−Dに接続された、Router−Eのインタフェースである。IP−4は、Switch−Cに接続された、Router−Fのインタフェースである。「インタフェース」とは、パケットが入出力されるポートのことである。
Path−1は、パケットがRouter−B、Switch−C、Router−E、Switch−Gを順番に通ってSubnet−Zに到達する経路である。Path−2は、パケットがSubnet−Zから送出され、Switch−H、Router−F、Switch−C、Router−Bを順番に通る経路である。
ここではRouter−A及びRouter−Bが、それぞれ正常に稼働していながら互いに冗長の関係にある。つまり、共に正常稼働している期間はパケット転送負荷を分け合い、一方が故障した場合はここを通過するパケットの転送を稼働している方が全て請け負う。Switch−C及びSwitch−D、Router−E及びRouter−F、Switch−G及びSwitch−Hも互いに同様の関係である。
IPでは、次の宛先を自動で探索する動的ルーティングを適用すると、経路の障害を自動で認識して障害のある宛先を選択しないようにすることが可能である。その場合、正常な状態では複数の宛先が並立することが可能となる。敢えて「コスト値」というものを設定することで、複数の宛先に差をつけ、最優先のものが常に選択されるようにすることもできる。ただし、図1に示すような対等な冗長構成の場合には、コスト値に差をつけずに、正常時は負荷分散されるように構成する。その場合、例としてRouter−A及びRouter−Bでは、Subnet−ZへのIPルートエントリとして、以下のように、4つの対等な宛先が登録される。
(宛先1)Subnet−Z NextHop: IP−1
(宛先2)Subnet−Z NextHop: IP−2
(宛先3)Subnet−Z NextHop: IP−3
(宛先4)Subnet−Z NextHop: IP−4
Router−A及びRouter−Bは、通常はベンダが独自に実装するアルゴリズムに従って、上記4つの宛先に均等にパケットが振り分けられるようにパケットを転送する。通常は、送受IPアドレス、プロトコル、TCP(Transmission・Control・Protocol)ポート番号といった、IPコネクションを特定するコネクション識別情報を基に宛先が計算される。こうすることで、パケット単位で宛先が分かれるのではなく、コネクション単位となり、同一のコネクションのパケットの順番がここで入れ替わることはない。ただし、IPルータは転送の際にコネクションを意識するわけではない。IPルータは、どのインタフェースから入力したパケットも、ルーティングテーブルに従って転送するだけである。よって、IPルータは、1つのコネクションの双方向のパケットを認識し、互いに同一のインタフェースを通過するようにパケットを転送するといったことはしない。複数の転送先がある場合にそのような状況があったとしても、それは偶然に過ぎない。したがって、例えば往路としてPath−2を通ったパケットの応答が、RouterーBに転送されてきたとき、Router−Bは宛先としてIP−4を選択し、Router−Fを通すことが逆方向であることなど意識しない。Router−Bは、上記(宛先1)〜(宛先4)という4つの宛先に均等にパケットが振り分けられるように計算して宛先を決定するだけである。図1ではIP−1が選択されている。応答は、Path−1に沿って結果的にRouter−Eを通る。つまり、往路及び復路で経路が異なる結果となっている。さらに言えば、ここに示した例では復路のパケットがRouter−Bに到着しているが、これ自体偶然である。
次に、上記のような冗長構成をとるネットワークと、パケット転送のためのコネクションパスを設定するネットワーク機器とそれらのコネクションパスの制御を行う制御装置によって構成されるネットワークシステムとが、冗長の複数のインタフェースで接続された構成について示す。図2を参照して、その構成例を説明する。図2の例は、本実施の形態との比較のための例である。
Router−1、Router−2は、ルータである。SDN−SW1、SDN−SW2、SDN−SW3、SDN−SW4は、SDNスイッチである。Term−0、Term−1、Term−2、Term−3は、端末である。端末は、クライアントコンピュータに限らず、サーバ機であってもよい。Term−0は、ネットワーク121に接続された、端末であるTerm−0のインタフェースも示す。Term−2−1は、SDN−SW3に接続された、Term−2のインタフェースである。Term−2−2は、SDN−SW4に接続された、Term−2のインタフェースである。Term−3は、SDN−SW4に接続された、端末であるTerm−3のインタフェースの束も示す。
ここでは、コネクションパスが設定される機器であるSDNスイッチから構成されるネットワーク110をSDNと称することとする。LAN(Local・Area・Network)やWAN(Wide・Area・Network)といったネットワーク121、及び、ネットワーク121に接続されるか又はネットワーク121に含まれる、図1に示したルータやレイヤ2スイッチ等から構成される他のネットワーク120を既存ネットワークと称することとする。SDNには、SDNコントローラであるネットワーク制御装置150が接続される。
既存ネットワークとSDNとを接続する複数のインタフェースは冗長関係にある。パケットがルータに入力される際、及び、パケットがルータからSDNへ転送される際は、パケットが均等に振り分けられる。したがって、往路及び復路が異経路となり、既存ネットワークからSDNへ入力されるパケットと、SDNから既存ネットワークに出力されるパケットの通るインタフェースが異なる事象が発生し得る。SDNの既存ネットワークと反対側は端末に接続される。既存ネットワークのSDNと反対側の先にも端末が存在する。図2では、端末として、1つのインタフェースを有するTerm−0及びTerm−1、対等冗長の2つのインタフェースを有するTerm−2、複数のリンクを1つのリンクであるかのように見せるリンクアグリゲーションが適用されたTerm−3を示している。ここで、対等冗長及びリンクアグリゲーションのどちらも、1つのコネクションの往復パケットが同じインタフェースを通過するとは限らない。
上記のように、SDNと2つ以上のインタフェースで接続された既存ネットワーク或いは端末が存在する場合、往復が異経路となる状況が生じ得る。Term−1のコネクションも、既存ネットワーク側で異なるインタフェースを通過する異経路になることがある。
以下の4つの種別の通信リクエストについて考える。
(種別1)Term−0からTerm−1への通信リクエスト
(種別2)Term−1からTerm−0への通信リクエスト
(種別3)Term−0からTerm−2への通信リクエスト
(種別4)Term−2からTerm−0への通信リクエスト
Term−2とTerm−3は、対等な複数のインタフェースでSDNと接続されているという意味で同じ位置づけであるため、分類は同じである。既存ネットワークの代わりにTerm−2或いはTerm−3と同様の接続があったとしても、結果的に対等の位置づけのインタフェースで接続されたネットワーク或いは端末ということで、位置づけは同じである。上記4つの種別のそれぞれについて、往復が異経路となる状況を見ていく。
なお、ここでは、Router−1、Router−2といったルータ、及び、Term−2、Term−3といった端末が、送信先が同じパケットを同じインタフェースから出力する動作を行うことを前提としている。この動作は、一般的に、パケットの順序を維持するために行われる。
(種別1)では、Term−0からTerm−1にリクエストパケットが送信される。SDNが双方向のコネクションパスを構築するのであれば、Term−1からの応答パケットは、逆方向のコネクションパスにヒットして問題なく既存ネットワーク側へ転送される。よって、異経路の問題は、通信リクエストが来たときに双方向のコネクションを確立するという基本的な動作によって解決される。
(種別2)では、Term−1からTerm−0にリクエストパケットが送信される。Term−0からの応答パケットは、SDNに対して直前にあるルータが転送するため、異経路を通り得る。図3に示すように、CP−1が確立された後、CP−2が確立されるといった場合がある。この場合、リクエストパケットは、Path−1を通る。応答パケットは、Path−2を通る。
図3の例において、CP−1は、SDN−SW3とSDN−SW2との間のコネクションパスである。CP−2は、SDN−SW1とSDN−SW3との間のコネクションパスである。Path−1は、パケットがTerm−1から送出され、CP−1、Router−2、ネットワーク121を順番に通ってTerm−0に到達する経路である。Path−2は、パケットがTerm−0から送出され、ネットワーク121、Router−2、CP−2を通ってTerm−1に到達する経路である。
(種別3)では、Term−0からTerm−2にリクエストパケットが送信される際、Term−2−1を通ったとしても、Term−2からの応答パケットがTerm−2−2を通ってしまうこと、或いは、その逆があり得る。既存ネットワーク側では、Term−2側でインタフェースが同じであれば(種別1)と同じ理由で問題は発生しない。しかし、Term−2でインタフェースが異なると、既存ネットワーク側でも異なるインタフェースをパケットが通る場合がある。図4に示すように、CP−1とCP−2という2つのコネクションパスが構築され、これら2つのコネクションパスの両端のどちらも同じにならない場合がある。この場合、リクエストパケットは、Path−2を通る。応答パケットは、Path−1を通る。
図4の例において、CP−1は、SDN−SW4とSDN−SW2との間のコネクションパスである。CP−2は、SDN−SW1とSDN−SW3との間のコネクションパスである。Path−1は、パケットがTerm−2−2から送出され、CP−1、Router−2、ネットワーク121を順番に通ってTerm−0に到達する経路である。Path−2は、パケットがTerm−0から送出され、ネットワーク121、Router−2、CP−2を通ってTerm−2−1に到達する経路である。
(種別4)では、Term−2からTerm−0にリクエストパケットが送信される。Term−0からの応答パケットは、(種別2)と同様の理由で、異経路を通り得る。応答パケットが既存ネットワークから異なるインタフェースに入力されると、Term−2との接続においても、応答パケットがTerm−2−1を通るかTerm−2−2を通るかは、ネットワーク制御装置150のコネクションパス制御次第である。
往路と復路が異経路になることによって、SDNの基本的な実装では、SDNにおいて往路と復路で別々のコネクションパスが構築される。ネットワーク制御装置150の管理上も2つのコネクションパスを取り扱うことになってしまう。
SDNスイッチは、インタフェースにパケットが入力されると、そのパケットが同じインタフェースに設定されたコネクションパスに対応するパケットかどうかを判定する。そのパケットが、設定されたコネクションパスに対応しない新規のものであれば、SDNスイッチは、ネットワーク制御装置150へ新規コネクションリクエストを送る。ネットワーク制御装置150は、新規コネクションリクエストに応じて、新規コネクションパスを設定する。異経路の問題への対応として、ネットワーク制御装置150が、異経路が明確になった時点で新規に構築されるコネクションパスを残し、古いコネクションパスを削除するという動作が考えられる。
(種別2)では、コネクションパスの両端のうち一方のインタフェースが共通である。そのため、共通になっていない方でのみ新規コネクションリクエストが発生する。したがって、ネットワーク制御装置150が一度新規コネクションパスを残して他を削除する対応をとれば、他の条件の変化等がない限りその後さらに新規コネクションリクエストが発生することはない。
しかし、(種別3)においては以下に示す問題がある。
図4に示したように、コネクションパスの両端共にインタフェースが異なる場合がある。即ち、まず往路のPath−2のためのコネクションパスとしてCP−2が構築される。その後復路のPath−1のためのコネクションパスとしてCP−1が構築される。上記の動作ではCP−2が削除されることになる。しかし、既存ネットワークは、Path−2を維持しようとする。そのため、Term−0からパケットが送信されればSDNへの入力はSDN−SW1となる。再びCP−2が構築されれば、上記の動作ではCP−1が削除されることになる。その後SDNの状態が変化して、Term−2−1に接続されるCP−2の代わりに、Term−2−2に接続されるコネクションパスが構築されるまで、CP−2とCP−1の構築及び削除の処理が繰り返される。これにより、ネットワーク制御装置150の負荷状態によっては通信が困難となる。
(種別4)においても、(種別3)と同じ問題がある。
そこで本実施の形態では、(a)同一のテナント内で、(b)識別可能な最も高位のレイヤで判定される同一のコネクションであるという条件が成立する複数のコネクションパスが検出された場合、コネクションパスを確立する要因となったパケットが入力されたインタフェース間で新たにコネクションパスを構築し、古いコネクションパスを削除する手順をとる。
「同一のテナント」とは、同一のサービス単位のネットワークのことである。SDNでは、ネットワーク仮想化によって、物理構成とは関係なく、論理的に独立したネットワークを構成可能である。独立したネットワーク間ではIPアドレスの重複が許される。各独立したネットワーク内で複数のVLAN(Virtual・Local・Area・Network)を構築することも可能である。したがって、(a)の条件は、論理的に独立した1つのネットワークの中で、(b)の条件が成立する必要があることを示すものである。
「識別可能な最も高位のレイヤで判定される同一のコネクション」とは、TCP/IPであれば、送受IPアドレス及び送受ポート番号のペアが一致するコネクションのことである。SDNコントローラであるネットワーク制御装置150のコネクションパスエントリテーブルには、各コネクションパスを構築するきっかけとなったパケットの方向を示す情報と入力インタフェースとが所定のフィールドに記載がされるものとする。パケットの方向を示す情報としては、送受IPアドレスを用いることができる。
以下、本実施の形態に係るシステムの構成、本実施の形態に係るシステムの動作、本実施の形態の効果を順番に説明する。
***構成の説明***
図5を参照して、本実施の形態に係るシステムであるコネクションパス管理システム100の構成を説明する。
コネクションパス管理システム100は、ネットワーク110と、設定部151と、集約部152とを備える。本実施の形態では、設定部151及び集約部152がネットワーク制御装置150に含まれるが、後述する変形例のように、設定部151と集約部152が別々の装置に分けられてもよい。
ネットワーク110は、端末間のコネクションを識別する情報を含むパケット群がネットワーク110の外部から入力されたり、ネットワーク110の外部に出力されたりするインタフェース群を有する。「コネクションを識別する情報」とは、具体的には、前述したIPコネクションを特定するコネクション識別情報のことである。ネットワーク110には、他のネットワーク120,130が接続されている。各端末は、他のネットワーク120,130のいずれかに接続されている。本実施の形態では、ネットワーク110の方式として、SDNが用いられるが、コネクションパス或いはフローを設定するものであれば、どのような方式が用いられてもよい。
設定部151は、端末間のコネクションを識別する情報を含むパケット群が入出力されるネットワーク110のインタフェース間に、当該パケット群を転送するための双方向のコネクションパスを、当該コネクションに対応付けて設定する。ここで、1つのコネクションC1を識別する情報を含む第1パケットがネットワーク110の1つのインタフェースに入力されたとする。この場合、設定部151は、第1パケットが入力されたインタフェースである第1入力インタフェースと、第1パケットが出力されたインタフェースである第1出力インタフェースとの間のコネクションパスをコネクションC1に対応付けて設定する。
集約部152は、第1入力インタフェースと第1出力インタフェースとの間のコネクションパスがコネクションC1に対応付けて設定部151により設定された後、コネクションC1を識別する情報を含み第1パケットと逆方向に送信された第2パケットが第1出力インタフェースと異なるインタフェースである第2入力インタフェースに入力された場合、第1入力インタフェースと第2入力インタフェースとの間のコネクションパスをコネクションC1に対応付けて設定する。集約部152は、コネクションC1に対応する他のコネクションパスを削除する。これにより、集約部152は、コネクションC1で第1パケットが送信される往路と第2パケットが送信される復路とが異経路になるか、或いは、異経路になったという問題が発生した場合に、問題に対処することができる。本実施の形態では、集約部152は、第2パケットが第2入力インタフェースに入力されたタイミングで問題の発生を検知する。そのため、集約部152は、事前に問題に対処することができる。「事前」とは、異経路を生じさせるコネクションパスの設定前ということである。「問題に対処する」とは、コネクションパスを1つに集約してリソースの無駄を生じさせないということである。後述するように、集約部152は、第2パケットが第2入力インタフェースに入力されたタイミングで動作する代わりに、任意のタイミングで動作して事後的に問題に対処してもよい。「事後」とは、異経路を生じさせるコネクションパスの設定後ということである。
本実施の形態では、集約部152は、設定部151にコネクションパスの設定及び削除を行わせるが、集約部152は、自らコネクションパスの設定及び削除を行ってもよい。いずれの場合も、集約部152が実質的にコネクションパスの設定及び削除を行っていることになる。
本実施の形態では、コネクションC1の確立を要求するパケットが第1パケットに該当し、第1パケットに応答するパケットが第2パケットに該当する。具体的には、TCP−SYNパケットが第1パケットに該当し、TCP−SYN−ACKパケットが第2パケットに該当する。「TCP−SYNパケット」は、TCPヘッダのSYNフラグが「1」、ACKフラグが「0」のパケットである。「TCP−SYN−ACKパケット」は、TCPヘッダのSYNフラグ及びACKフラグの両方が「1」のパケットである。
集約部152は、コネクションC1を識別する情報を含み設定条件D1を満たすパケットがコネクションC1に対応付けて既に設定部151により設定されたコネクションパスの両端のインタフェースIF−A,IF−Bと異なるインタフェースIF−Xに入力される度に、インタフェースIF−XとインタフェースIF−A,IF−Bのうち一方のインタフェースとの間のコネクションパスをコネクションC1に対応付けて設定し、コネクションC1に対応する他のコネクションパスを削除してもよい。これにより、集約部152は、コネクションC1で往路及び復路が異経路になるという問題が発生する度に、問題に対処することができる。具体的には、集約部152は、コネクションC1でTCP−SYNパケットの送信経路とTCP−SYN−ACKパケットの送信経路とが異経路になるという問題だけでなく、TCPコネクションであるコネクションC1の確立後に往路及び復路が異経路になるという問題にも対処することができる。
設定条件D1は、常に真という条件であってもよい。即ち、コネクションC1を識別する情報を含むパケットの全てが設定条件D1を満たすパケットに該当するようにしてもよい。
処理の効率化、及び、セキュリティの強化の観点からは、ネットワーク110に接続された他のネットワーク120,130の状態変化が検知されてから一定期間内にインタフェースIF−Xに入力されたパケットが設定条件D1を満たすパケットに該当することが望ましい。
他のネットワーク120,130におけるルーティングテーブルの変更が上記状態変化に該当する。他のネットワーク120,130におけるリンクの障害又は回復も上記状態変化に該当する。
本実施の形態の変形例として、集約部152が任意のタイミングで動作する場合、設定部151は、コネクションC1を識別する情報を含むパケットがコネクションC1に対応付けて既に設定したコネクションパスの両端のインタフェースIF−A,IF−Bと異なるインタフェースIF−Xに入力される度に、インタフェースIF−Xとネットワーク110の他のインタフェースとの間のコネクションパスをコネクションC1に対応付けて追加設定する。集約部152は、複数のコネクションパスがコネクションC1に対応付けて設定部151により設定されたかどうか判定する。集約部152は、複数のコネクションパスがコネクションC1に対応付けて設定部151により設定されたと判定した場合、第1入力インタフェースと第2入力インタフェースとの間のコネクションパスをコネクションC1に対応付けて設定する。集約部152は、コネクションC1に対応する他のコネクションパスを削除する。前述したように、第1入力インタフェースは、第1パケットが入力されたインタフェースである。第2入力インタフェースは、第2パケットが入力されたインタフェースである。この変形例では、上記複数のコネクションパスのうち、最新のコネクションパスが設定部151により設定される要因となったパケットが第2パケットに該当する。第2パケットと逆方向に送信され上記複数のコネクションパスのいずれかが設定部151により設定される要因となったパケットのうち、最後に入力されたパケットが第1パケットに該当する。よって、コネクションC1の確立を要求するパケットが第1パケットに該当するとは限らず、第1パケットに応答するパケットが第2パケットに該当するとも限らない。
***動作の説明***
図6を参照して、コネクションパス管理システム100の動作を説明する。コネクションパス管理システム100の動作は、本実施の形態に係るコネクションパス管理方法に相当する。コネクションパス管理システム100の動作は、本実施の形態に係るコネクションパス管理プログラムの処理手順に相当する。
S11において、1つのコネクションC1を識別する情報を含むパケットがネットワーク110の1つのインタフェースにネットワーク110の外部から入力される。
S12において、S11で入力されたパケットに含まれる情報によって識別されるコネクションC1に対応するコネクションパスが既に設定部151により設定されているかどうかが判定される。設定されていなければ、フローはS13に進む。既に設定されていれば、フローはS17に進む。本実施の形態では、S11でパケットが入力されたインタフェースを有する、ネットワーク110の機器がS12の処理を行うが、設定部151又は集約部152がS12の処理を行ってもよい。
S13において、集約部152は、S11で入力されたパケットがコネクションC1の確立を要求するパケットであるかどうかを判定する。コネクションC1の確立を要求するパケットでなければ、フローはS14に進む。コネクションC1の確立を要求するパケットであれば、フローはS15に進む。なお、設定部151又はS11でパケットが入力されたインタフェースを有する、ネットワーク110の機器がS13の処理を行ってもよい。
S14において、集約部152は、S11で入力されたパケットに含まれる情報によって識別されるコネクションC1に対応するコネクションパスが既に設定部151により設定されているかどうかを判定する。設定されていなければ、フローはS15に進む。設定されていれば、フローはS16に進む。
S15において、設定部151は、S11でパケットが入力されたインタフェースとネットワーク110の他の1つのインタフェースとの間の双方向のコネクションパスを、S11で入力されたパケットに含まれる情報によって識別されるコネクションC1に対応するコネクションパスとして設定する。ネットワーク110のインタフェース群のうち、どのインタフェースを上記他の1つのインタフェースとするかは、主に、S11で入力されたパケットの送信先から判断される。
S16において、集約部152は、ネットワーク110のインタフェース群のうち、コネクションC1に対応する設定済のコネクションパスが設定部151により設定される要因となったパケットがネットワーク110の外部から入力されたインタフェースと、S11でパケットがネットワーク110の外部から入力されたインタフェースとの間の双方向のコネクションパスを、S11で入力されたパケットに含まれる情報によって識別されるコネクションC1に対応するコネクションパスとして設定する。そして、集約部152は、コネクションC1に対応する他のコネクションパスを削除する。これにより、コネクションパスが1つに集約される。なお、他のネットワーク120,130の状態変化が発生したことにより、コネクションC1に対応する設定済のコネクションパスが設定部151により設定される要因となったパケットと同じ方向に送信されるパケットがS11で入力される場合がある。その場合、集約部152は、設定済のコネクションパスを単純に削除し、設定部151にS15の処理を行わせる。よって、設定部151が、S11でパケットが入力されたインタフェースとネットワーク110の他の1つのインタフェースとの間の双方向のコネクションパスを、コネクションC1に対応するコネクションパスとして設定する。
S17において、S11で入力されたパケットは、そのパケットに含まれる情報によって識別されるコネクションC1に対応するコネクションパスに沿ってネットワーク110の内部で転送される。そのパケットは、そのコネクションパスの両端のインタフェースのうち、S11でパケットが入力されたパケットと反対側のインタフェースからネットワーク110の外部に出力される。そして、フローは終了する。
図7を参照して、図2の例に対応する、本実施の形態に係るネットワーク構成例を説明する。
Router−1、Router−2は、図2の例と同じルータである。Router−3、Router−4も、ルータである。SDN−SW1、SDN−SW2、SDN−SW3、SDN−SW4は、図2の例と同じSDNスイッチである。Term−0、Term−1は、端末である。Term−0は、ネットワーク121に接続された、端末であるTerm−0のインタフェースも示す。Term−1は、ネットワーク131に接続された、端末であるTerm−1のインタフェースも示す。
ここでも、SDNスイッチから構成されるネットワーク110をSDNと称することとする。ネットワーク121、及び、ネットワーク121に接続されるか又はネットワーク121に含まれるルータやレイヤ2スイッチ等から構成される他のネットワーク120を既存ネットワークと称することとする。ネットワーク121と同様のネットワーク131、及び、ネットワーク131に接続されるか又はネットワーク131に含まれるルータやレイヤ2スイッチ等から構成される他のネットワーク130も既存ネットワークと称することとする。SDNには、図6に示した動作を行うネットワーク制御装置150が接続される。
ネットワーク制御装置150は、設定部151と、集約部152とを備える。設定部151は、SDNコントローラ又はその一部として機能する。集約部152は、1つ或いは複数のソフトウエアプロセスとしてコネクションパス再構築及びコネクションパス集約機能を実装するものである。一般に基本機能を提供するベンダ又はオープンソースのSDNコントローラについては、機能追加のためのAPI(Application・Programming・Interface)が公開されている。そのようなAPIを利用して集約部152の機能を追加することが考えられる。
ここで、本実施の形態の変形例を図8に示す。
ネットワーク制御装置150がベンダ製品で、アプライアンスとして提供される場合等は、別途、集約部152を備える管理装置160が、ネットワーク制御装置150のAPIへのアクセスが可能な環境に設置される。この変形例において、管理装置160は、PC(Personal・Computer)である。APIがHTTP(HyperText・Transfer・Protocol)等のTCP/IP通信を前提とした形式で提供される場合、ソフトウエア作成上は物理的な位置関係を意識する必要はない。よって、図7及び図8のどちらの構成でも実現機能は同じである。
図9から図13を参照して、図7に示した構成で、Term−1からTerm−0へ通信リクエストが送信される際のコネクションパス管理システム100の動作例を説明する。
図7に示した構成において、SDNに接続された、Router−3及びRouter−4のインタフェースは、図2の例のTerm−2−1、Term−2−2のような端末の複数のインタフェースに相当すると捉えることができる。
まず、図9に示すように、以下の処理が行われる。
(処理1−1)Term−1が送信したコネクションの最初のパケットであるリクエストパケットがSDNに到達したとき、リクエストパケットは、SDN−SW4のインタフェースであるIF−4−2へ入力される。なお、SDN−SW4及びIF−4−2が選択されたのは既存ネットワークのルータの振り分けによるものである。SDNは選択に関わっていない。リクエストパケットは、SDN−SW3に入力される場合もある。
(処理1−2)SDN−SW4は、リクエストパケットのコネクション識別情報が、既にSDN−SW4に設定されているコネクションパスに対応しているかどうかを判定する。対応するコネクションパスがあれば、SDN−SW4は、そのコネクションパスに従ってリクエストパケットを転送する。対応するコネクションパスがなければ、SDN−SW4は、リクエストパケットを含むコネクションリクエスト201をネットワーク制御装置150に送信する。
(処理1−3)ネットワーク制御装置150において、設定部151はコネクションリクエスト201を受信すると、集約部152に問い合わせを行う。集約部152では、受信したコネクションリクエスト201に含まれるリクエストパケットのコネクション識別情報に対応するコネクションパスを前述した条件(a)及び(b)に従って既存のコネクションパスから検索する。ここでは一致するものがない。そのため、集約部152はその後の処理を通常通り進めるよう設定部151に通知する。なお、ここでの検索は、実装によってはAPIを介して設定部151の基本機能で実施され、結果を集約部152が受け取ってもよい。
続いて、図10に示すように、以下の処理が行われる。
(処理1−4)ネットワーク制御装置150において、設定部151はSDNコントローラとしての基本的な処理を実施する。まず、設定部151は、コネクションパスを計算する。その結果、出力先がSDN−SW1のインタフェースであるIF−1−2に決定される。コネクションリクエスト201に含まれていたリクエストパケットは、転送パケット202として、SDNからの出口となったSDN−SW1へ転送される。一方、経路上の各SDNスイッチには、コネクションパス設定指示203によって、コネクションパスの設定が指示される。SDN−SW1は、ネットワーク制御装置150より受信したリクエストパケットを出力先のIF−1−2から出力する。
(処理1−5)リクエストパケットは、Path−1を通ってTerm−0により受信される。Path−1は、SDN−SW1、Router−2を通る経路になっている。
(処理1−4)の結果、図11に示すように、CP−1が構築される。これにより、SDNを通過するTerm−0からTerm−1への通信が可能となる。逆方向の通信も同じ経路では可能となる。コネクションパスは、双方向であり、SDNの出入り口となるインタフェース間で構築される。CP−1は、IF−4−2とIF−1−2との間で設定されている。
次に、図12に示すように、以下の処理が行われる。
(処理2−1)Term−0が返信したコネクションの最初のパケットである応答パケットは、Term−0から送信される。応答パケットは、Path−2を通ってSDNに入力される。Path−2は、Router−2、SDN−SW2を通る経路になっている。応答パケットは、SDN−SW2のインタフェースであるIF−2−1へ入力される。なお、SDN−SW2及びIF−2−1が選択されたのは既存ネットワークのルータの振り分けによるものである。SDNは選択に関わっていない。応答パケットは、SDN−SW1に入力される場合もある。その場合、CP−1を利用することができる。
(処理2−2)SDN−SW2は、応答パケットのコネクション識別情報が、既にSDN−SW2に設定されているコネクションパスに対応しているかどうかを判定する。対応するコネクションパスがあれば、SDN−SW2は、そのコネクションパスに従って応答パケットを転送する。対応するコネクションパスがなければ、SDN−SW2は、応答パケットを含むコネクションリクエスト204をネットワーク制御装置150に送信する。ここでの判定には入力インタフェースも条件に含まれるため、仮にIF−1−1にTerm−0からの応答パケットが入力された場合も、対応するコネクションパスがないという結果になる。
(処理2−3)ネットワーク制御装置150において、設定部151はコネクションリクエスト204を受信すると、集約部152に問い合わせを行う。集約部152では、受信したコネクションリクエスト204に含まれる応答パケットのコネクション識別情報に対応するコネクションパスを前述した条件(a)及び(b)に従って既存のコネクションパスから検索する。ここでは一致するものとしてCP−1が発見される。
続いて、図13に示すように、以下の処理が行われる。
(処理2−4)ネットワーク制御装置150において、集約部152はCP−1の情報を参照して、CP−1を構築するきっかけとなったパケットの入力インタフェースがIF−4−2であり、IF−4−2がコネクションリクエスト204に含まれる応答パケットの宛先になり得ることを確認する。そして、集約部152は、(i)応答パケットの入力インタフェースであるIF−2−1とSDN−SW4のインタフェースであるIF−4−2との間で新規コネクションパスを構築するとともに、(ii)検索して一致したコネクションパスを削除するように設定部151に通知する。
(処理2−5)ネットワーク制御装置150において、設定部151は、IF−2−1及びIF−4−2間のコネクションパスを計算する。SDN内の経路は、予め設定された各種条件に従って決定される。コネクションリクエスト204に含まれていた応答パケットは、転送パケット205として、SDNからの出口となったSDN−SW4へ転送される。一方、経路上の各SDNスイッチには、コネクションパス設定及び削除指示206によって、コネクションパスの設定及び削除が指示される。SDN−SW4は、ネットワーク制御装置150より受信した応答パケットを出力先のIF−4−2から出力する。
(処理2−5)の結果、CP−2が構築され、CP−1が削除される。これにより、SDNを通過するTerm−0及びTerm−1間の双方向の通信が可能となる。CP−2は、IF−4−2とIF−2−1との間で設定されている。
上記のような処理によって、往路及び復路をそれぞれ通る最初のパケットで、往復が異経路になる場合のコネクションパスを最適な状態に再構築することが可能となる。
図9から図13の動作において、リクエストパケットは第1パケットに該当し、応答パケットは第2パケットに該当する。IF−4−2は第1入力インタフェース、IF−1−2は第1出力インタフェース、IF−2−1は第2入力インタフェースに該当する。
ここで説明したネットワーク構成とコネクション確立のパタンは、前述した(種別1)〜(種別4)のうち(種別3)及び(種別4)に相当する。
(種別3)及び(種別4)に関して示した例では、Term−2が2つのインタフェースでSDNと接続されている。当該2つのインタフェースは同等の扱いであり、Term−2の中に論理的にスイッチ、或いは、振り分けを行うルータがいるのと同様である。図2の例と同様の構成を本実施の形態に適用した場合、図14に示すように、Term−2が、論理的なネットワーク301と、ネットワーク301に接続された仮想PC又はブレードPC302とで構成されていると捉えることができる。即ち、SDNから見れば、冗長構成をとる既存ネットワークが接続されているのと同じであり、図14の構成は図7の構成と同等であると考えることができる。なお、ここでの接続インタフェース数は2つに限定されるわけではない。
また、Term−3は、SDN−SW4とリンクアグリゲーションによって接続されている。SDNからTerm−3へパケットが転送されるとき、及び、Term−3からSDNへパケットが転送されるときは、送信先が同じパケットを同じインタフェースで転送することが保証される。これは、前述したように、パケット順を保持するための一般的な動作である。しかし、あるインタフェースで受信されたパケットに対応した逆方向のパケットを当該インタフェースで転送することまでは保証されない。リンクアグリゲーションは複数のインタフェースを利用して仮想的に広帯域の回線に見せる技術であり、対向の装置それぞれが振り分けを行えばよい。そのため、コネクションの双方向のパケットが同一インタフェースを通過する必要はなく、そのような実装は多くの処理やリソースを必要とするため行われていない。イーサネット(登録商標)は元々半二重の回線である。半二重であれば、より効率的なリンクアグリゲーションを行うには対向からの送信状況を意識する必要があるかもしれない。しかし、近年一般に広く利用されるようになった、UTP(Unshielded・Twisted・Pair)、STP(Shielded・Twisted・Pair)といったツイストペアケーブルを利用するイーサネットでは全二重通信が可能である。特に、ギガビットイーサネットは全二重通信が前提である。よって、1つのコネクションの往復パケットの通過インタフェースが異なり、Term−2や既存ネットワークを接続した状況と同じになり得る。よってリンクアグリゲーションにおいても異経路が生じ、その構成は図7の構成と同等であると考えることができる。
以上のことから、(種別3)及び(種別4)は、図9から図13の動作で対応可能である。
(種別2)については、Term−1からコネクションリクエストが送信され、Term−0からの応答が異経路となってTerm−1の唯一のインタフェースに到着する動作となる。したがって、図9から図13の動作におけるTerm−1側のSDNへの入力インタフェースであるIF−4−2が常に固定になっているということに他ならない。固定かどうかに関係なく、最初に入力したインタフェースを保存する動作を行っているので、(種別2)のパタンも、図9から図13の動作で対応可能である。
以上に示した通り、各種ネットワーク構成に対しても上記の動作によって本実施の形態の目的を果たすことが可能である。以下に、付加的な機能について示す。
前述した通り、TCPのコネクションが通信の大半を占め、TCPは明確なコネクション確立手順がある。よって、当該確立手順を認識し、処理実施の要不要を判断することで、ネットワーク制御装置150の負荷を抑制することが期待できる。
TCP−SYNパケットの場合は、基本的に新規コネクションであるため、集約部152に情報が送られてきても検索は行わず、通常通り処理するように即時応答する。TCPのコネクションが何らかの理由で切断され、すぐに張り直す場合等も、同じポート番号が適用されて全く同じコネクションとして認識できることはまれであり、コネクションパスの再利用は反って処理を重くしかねない。
TCP−SYN−ACKパケットの場合は、異経路となっている可能性が非常に高いため、集約部152の処理を適用する。なお、TCP−SYN−ACKパケットの場合に限らず、TCP−SYNパケット及びTCP−SYN−ACKパケットのいずれでもないパケット、即ち、TCPのSYNフラグの立っていないパケットについても、集約部152の処理を適用してよい。具体的には以下の2つの状況等が考えられ、結果的にTCPのSYNフラグの立っていないパケットでも新規コネクションリクエストが発生し得るためである。
(状況1)SDNに接続された既存ネットワークのルータの対等なインタフェースへの振り分けルールは、ルータに直結していない箇所で障害があり、ルートテーブルの変更があった場合等、エントリとして変化がなくても、内部テーブル上の順番が変わる等して振り分けが変わる可能性がある。
(状況2)リンクアグリゲーションの振り分けルールはリンク障害が発生すれば変化する。
ただし、全てのTCPパケットに対応すると、コネクションパス管理システム100が攻撃の対象になりやすくなったり、コネクションパス管理システム100に障害が発生しやすくなったりする可能性がある。そこで、TCPのSYNフラグの立っていないパケットへの対応は、通常は不許可の状態で、いくつかのトリガを認識して許可状態に入る対応が考えられる。そのトリガとしては、動的ルーティングテーブルの変化の通知を利用することができる。リンクアグリゲーション等を含めた、端末や外部ネットワークとの接続リンク障害或いはリンク回復を利用することもできる。どれだけの時間許可するかはTCPのキープアライブのタイマとの関係等、ネットワーク設計とも関係する。SDNのコネクションパスの保持時間の設定とも関係する。よって、各設計者に委ねられる。
ここで、本実施の形態と片方向コネクションパスとの関係について説明する。
近年のIPネットワークにおける通信の大半がTCPであり、双方向の通信が必然であるため、最初のパケットの入力があり、そのパスを決定した時点で双方向のパスを構築する方が、片方向ずつコネクションパスの受付処理をするよりも制御装置としては効率が良い。それは、片方向の場合は各要求に対して経路計算を行い、経路上のSDNスイッチの入出力インタフェースを算出する必要があるが、逆方向のコネクションパスを同時に設定する場合には、各スイッチの入出力インタフェースを逆に辿るだけでよいため、経路計算は実質的に不要だからである。また双方向の1つのコネクションパスを扱うことで、(i)削除する際に双方向を一回の処理で実施可能、(ii)TCP−RSTによる削除でも双方向の削除が即時可能、(iii)TCP−FINの双方向の通過を各スイッチで認識可能で、削除処理を効率化しやすい、(iv)障害時におけるフローの振り替え処理も、1つのコネクションパスとして処理可能である等、各種管理上も都合が良い。これにより、(種別1)〜(種別4)のうち、(種別1)は追加の処理はなくても対応が可能である。また双方向に設定することで、本実施の形態の効果も大きく発揮される。
コネクションパスを片方向ずつ扱うことで、異経路の場合でも各スイッチのパス設定リソースを余計に消費することはなくなるが、別のパスとして扱うことになる。そのため、SDNコントローラの検索等の計算リソース及びエントリテーブルリソース、並びに、SDNスイッチのハードウェア処理用エントリリソースが最大で2倍近く消費され、SDNとしてのパフォーマンスに大きく影響する。大量に新規コネクションが発生したり、障害が発生してコネクションを振り変える際等に、時間がかかったり、場合によっては処理できなくなったりする可能性がある。また管理上の不便さを解決するため、双方向の対応を取って管理画面に表示する等、計算処理を増加させる。
片方向のコネクションパスエントリテーブルとは別に、双方向のコネクションパスエントリテーブルを用意し、片方向のエントリと対応付けを行っておき、SDNコントローラにおける検索等は双方向のテーブルを利用することで計算リソースの使用を抑えることができると考えられる。しかし一方で、コネクションパスの受付処理負荷は双方向の場合の2倍であることは変わらず、対応付けのための計算が付加され、コネクションパスの変更や削除、障害による振り替え等においても、追加のテーブルのための処理が発生するため、計算リソースは多く消費される。
したがって、ネットワーク構成において、SDNの各種リソースの使用を最小限にし、運用管理上も複雑化することを防いて負担がかからない状態を実現するには、コネクションパスを1つに集約し、当該コネクションパスに対してスイッチには双方向のパス設定を行う状態であり、既存の冗長化されたネットワークや端末とSDNを接続するとき、本実施の形態を適用することで、リソースの消費を効果的に抑えることが可能となる。
現在では、SDNを適用するのはデータセンタで、端末からコネクションリクエストが発行されるのが一般的である。それでも近年のデータセンタにある端末、即ちサーバはブレードや仮想化対応のために物理的或いは論理的なスイッチ等を経由して冗長のインタフェースを用意していることが多く、その場合、(種別3)又は(種別4)に該当し、異経路が発生する。しかしサーバが1つのインタフェースで接続されていると、端末からのアクセスは(種別1)に該当し、双方向の設定をすれば大半が解決となる。ただし、近年では端末のシンクライアント化が進んでいるため、(種別1)に該当するのはシンクライアントとシンクライアントサーバとの間のコネクションが中心となりつつある。シンクライアント化以前のコネクションは、ほぼそのままシンクライアントサーバから他のサーバに対して行われるという形で残るため、同じデータセンタ内にあっても、大規模であったり、フロアが分かれていることで既存ネットワークを通過したり、WANに出て行く等して既存ネットワークに対するアクセスの方が多くなり、(種別2)に該当するコネクションの方が多くなる傾向にあるため、本実施の形態が有効である。
4つの対等な冗長インタフェースでSDNと既存ネットワークが接続されていて、異経路の原因となっている場合、往路及び復路が同じインタフェースを通過する確率は4分の1である。したがって、(種別2)、(種別3)、(種別4)の状況にあるコネクションは、75%が異経路となる。インタフェースが2つであれば2分の1となり、50%が異経路となる。こうした環境には本実施の形態が有効である。
本実施の形態では、コネクションパスの集約の際に、最新のコネクションパスを優先して残すことが望ましい。そのため、確立済のコネクションパスの情報として、各コネクションパスを確立した順番を示すのに十分な精度の時刻或いは順番を示す番号を合わせて保存しておくことが望ましい。
コネクションパス管理システム100の運用中に管理者が手作業で或いは自動で定期的にコネクションパス情報の整理を行ってもよい。同一のコネクション識別情報を持つ複数のコネクションパスがあった場合には、当該複数のコネクションパスの、SDNの両端のインタフェースと、それらの両端のインタフェースとそれぞれ冗長関係にあるインタフェース群を特定し、一方のインタフェース群から入力したパケットによって確立されたコネクションパスのうち最新のもの、及び、もう一方のインタフェース群から入力したパケットによって確立されたコネクションパスのうち最新のものを特定して最終的に2つのコネクションパスを選択し、選択したコネクションパスの入力したパケットのインタフェースを両端とするコネクションパスを設定して、他のコネクションパスを削除する。
***効果の説明***
本実施の形態では、端末間の1つのコネクションに対して複数のコネクションパスが設定されるような状況が発生したときに、それら複数のコネクションパスが1つに集約される。このため、本実施の形態によれば、ネットワークのリソースの消費量を削減することが可能となる。
本実施の形態によれば、冗長構成をとる既存ネットワークと複数インタフェースで接続することによって往路及び復路の経路が異経路になり、SDNの各種リソースが余計に消費されるのを防ぐことが可能となる。
本実施の形態によれば、コネクションパス情報をSDNコントローラで2つ登録するところを1つに集約することが可能となる。SDNコントローラのテーブルリソースの消費抑制と、新たなリクエストに対する検索等の処理における計算負荷の軽減が可能となる。
本実施の形態によれば、TCP−RSTパケットが通過した場合、コネクションパスを削除することができるが、片方向のみの対応となり、さらに検索してもう一方を処理する負荷が省かれる。
本実施の形態によれば、TCP−FINパケットを検出してコネクションパスを削除する場合は、TCP−FIN自体が異なるコネクションパスを通過し、さらにそれらのACKがそれぞれ異なるコネクションパスを通過するため、それぞれのコネクションパスで検出した情報を集約しないと、効率的な削除ができないことを防ぐことができる。
本実施の形態によれば、障害等によってコネクションパスを振り替える場合も、コネクションパスエントリが集約されていることで計算負荷を軽減することが可能となる。
本実施の形態によれば、SDNを適用する際、SDN関連機器のリソースを少なめに設計でき、コスト削減になるとともにスロースタートでSDNを導入しやすくなる。
以下では、図15を参照して、本発明の実施の形態に係るネットワーク制御装置150のハードウェア構成例を説明する。
ネットワーク制御装置150は、コンピュータである。ネットワーク制御装置150は、プロセッサ901、補助記憶装置902、メモリ903、通信装置904、入力インタフェース905、ディスプレイインタフェース906といったハードウェアを備える。プロセッサ901は、信号線910を介して他のハードウェアと接続され、これら他のハードウェアを制御する。入力インタフェース905は、入力装置907に接続されている。ディスプレイインタフェース906は、ディスプレイ908に接続されている。
プロセッサ901は、プロセッシングを行うIC(Integrated・Circuit)である。プロセッサ901は、例えば、CPU(Central・Processing・Unit)、DSP(Digital・Signal・Processor)、又は、GPU(Graphics・Processing・Unit)である。
補助記憶装置902は、例えば、ROM(Read・Only・Memory)、フラッシュメモリ、又は、HDD(Hard・Disk・Drive)である。
メモリ903は、例えば、RAM(Random・Access・Memory)である。
通信装置904は、データを受信するレシーバ921及びデータを送信するトランスミッタ922を含む。通信装置904は、例えば、通信チップ又はNIC(Network・Interface・Card)である。
入力インタフェース905は、入力装置907のケーブル911が接続されるポートである。入力インタフェース905は、例えば、USB(Universal・Serial・Bus)端子である。
ディスプレイインタフェース906は、ディスプレイ908のケーブル912が接続されるポートである。ディスプレイインタフェース906は、例えば、USB端子又はHDMI(登録商標)(High・Definition・Multimedia・Interface)端子である。
入力装置907は、例えば、マウス、スタイラスペン、キーボード、又は、タッチパネルである。
ディスプレイ908は、例えば、LCD(Liquid・Crystal・Display)である。
補助記憶装置902には、設定部151、集約部152といった「部」の機能を実現するプログラムが記憶されている。このプログラムは、メモリ903にロードされ、プロセッサ901に読み込まれ、プロセッサ901によって実行される。補助記憶装置902には、OS(Operating・System)も記憶されている。OSの少なくとも一部がメモリ903にロードされ、プロセッサ901はOSを実行しながら、「部」の機能を実現するプログラムを実行する。
図15では、1つのプロセッサ901が示されているが、ネットワーク制御装置150が複数のプロセッサ901を備えていてもよい。そして、複数のプロセッサ901が「部」の機能を実現するプログラムを連携して実行してもよい。
「部」の処理の結果を示す情報やデータや信号値や変数値は、補助記憶装置902、メモリ903、又は、プロセッサ901内のレジスタ又はキャッシュメモリに記憶される。
「部」を「サーキットリ」で提供してもよい。また、「部」を「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。「回路」及び「サーキットリ」は、プロセッサ901だけでなく、ロジックIC、GA(Gate・Array)、ASIC(Application・Specific・Integrated・Circuit)、FPGA(Field−Programmable・Gate・Array)といった他の種類の処理回路をも包含する概念である。
管理装置160にも、図15の例と同じハードウェア構成を適用することができる。
以上、本発明の実施の形態について説明したが、この実施の形態を部分的に実施しても構わない。例えば、この実施の形態の説明において「部」として説明するもののうち、いずれか1つのみを採用してもよいし、いくつかの任意の組み合わせを採用してもよい。なお、本発明は、この実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
100 コネクションパス管理システム、110 ネットワーク、120 他のネットワーク、121 ネットワーク、130 他のネットワーク、131 ネットワーク、150 ネットワーク制御装置、151 設定部、152 集約部、160 管理装置、201 コネクションリクエスト、202 転送パケット、203 コネクションパス設定指示、204 コネクションリクエスト、205 転送パケット、206 コネクションパス設定及び削除指示、301 ネットワーク、302 仮想PC又はブレードPC、901 プロセッサ、902 補助記憶装置、903 メモリ、904 通信装置、905 入力インタフェース、906 ディスプレイインタフェース、907 入力装置、908 ディスプレイ、910 信号線、911 ケーブル、912 ケーブル、921 レシーバ、922 トランスミッタ。

Claims (11)

  1. 端末間のコネクションを識別する情報を含むパケット群が入出力されるネットワークのインタフェース間に、当該パケット群を転送するための双方向のコネクションパスを、当該コネクションに対応付けて設定する設定部と、
    1つのコネクションを識別する情報を含む第1パケットが入力されたインタフェースである第1入力インタフェースと、前記第1パケットが出力されたインタフェースである第1出力インタフェースとの間のコネクションパスが前記1つのコネクションに対応付けて前記設定部により設定された後、前記1つのコネクションを識別する情報を含み前記第1パケットと逆方向に送信された第2パケットが前記第1出力インタフェースと異なるインタフェースである第2入力インタフェースに入力された場合、前記第1入力インタフェースと前記第2入力インタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除する集約部と
    を備えるコネクションパス管理システム。
  2. 前記1つのコネクションの確立を要求するパケットが前記第1パケットに該当し、
    前記第1パケットに応答するパケットが前記第2パケットに該当する、請求項1に記載のコネクションパス管理システム。
  3. 前記集約部は、前記1つのコネクションを識別する情報を含むパケットが前記1つのコネクションに対応付けて既に前記設定部により設定されたコネクションパスの両端のインタフェースと異なるインタフェースに入力される度に、前記異なるインタフェースと前記両端のインタフェースのうち一方のインタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除する、請求項1又は2に記載のコネクションパス管理システム。
  4. 前記集約部は、前記1つのコネクションを識別する情報を含み設定条件を満たすパケットが前記1つのコネクションに対応付けて既に前記設定部により設定されたコネクションパスの両端のインタフェースと異なるインタフェースに入力される度に、前記異なるインタフェースと前記両端のインタフェースのうち一方のインタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除する、請求項1又は2に記載のコネクションパス管理システム。
  5. 前記ネットワークに接続された他のネットワークの状態変化が検知されてから一定期間内に前記異なるインタフェースに入力されたパケットが前記設定条件を満たすパケットに該当する、請求項4に記載のコネクションパス管理システム。
  6. 前記他のネットワークにおけるルーティングテーブルの変更が前記状態変化に該当する、請求項5に記載のコネクションパス管理システム。
  7. 前記他のネットワークにおけるリンクの障害又は回復が前記状態変化に該当する、請求項5に記載のコネクションパス管理システム。
  8. 前記設定部は、前記1つのコネクションを識別する情報を含むパケットが前記1つのコネクションに対応付けて既に設定したコネクションパスの両端のインタフェースと異なるインタフェースに入力される度に、当該異なるインタフェースと前記ネットワークの他のインタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて追加設定し、
    前記集約部は、複数のコネクションパスが前記1つのコネクションに対応付けて前記設定部により設定されたかどうか判定し、前記複数のコネクションパスが設定されたと判定した場合、前記第1入力インタフェースと前記第2入力インタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除し、
    前記複数のコネクションパスのうち、最新のコネクションパスが前記設定部により設定される要因となったパケットが前記第2パケットに該当し、
    前記第2パケットと逆方向に送信され前記複数のコネクションパスのいずれかが前記設定部により設定される要因となったパケットのうち、最後に入力されたパケットが前記第1パケットに該当する、請求項1に記載のコネクションパス管理システム。
  9. 前記ネットワークをさらに備える、請求項1から8のいずれか1項に記載のコネクションパス管理システム。
  10. 設定部が、端末間のコネクションを識別する情報を含むパケット群が入出力されるネットワークのインタフェース間に、当該パケット群を転送するための双方向のコネクションパスを、当該コネクションに対応付けて設定し、
    集約部が、1つのコネクションを識別する情報を含む第1パケットが入力されたインタフェースである第1入力インタフェースと、前記第1パケットが出力されたインタフェースである第1出力インタフェースとの間のコネクションパスが前記1つのコネクションに対応付けて前記設定部により設定された後、前記1つのコネクションを識別する情報を含み前記第1パケットと逆方向に送信された第2パケットが前記第1出力インタフェースと異なるインタフェースである第2入力インタフェースに入力された場合、前記第1入力インタフェースと前記第2入力インタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除するコネクションパス管理方法。
  11. コンピュータに、
    端末間のコネクションを識別する情報を含むパケット群が入出力されるネットワークのインタフェース間に、当該パケット群を転送するための双方向のコネクションパスを、当該コネクションに対応付けて設定する処理と、
    1つのコネクションを識別する情報を含む第1パケットが入力されたインタフェースである第1入力インタフェースと、前記第1パケットが出力されたインタフェースである第1出力インタフェースとの間のコネクションパスが前記1つのコネクションに対応付けて設定された後、前記1つのコネクションを識別する情報を含み前記第1パケットと逆方向に送信された第2パケットが前記第1出力インタフェースと異なるインタフェースである第2入力インタフェースに入力された場合、前記第1入力インタフェースと前記第2入力インタフェースとの間のコネクションパスを前記1つのコネクションに対応付けて設定し、前記1つのコネクションに対応する他のコネクションパスを削除する処理と
    を実行させるコネクションパス管理プログラム。
JP2016557335A 2014-12-19 2014-12-19 コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム Expired - Fee Related JP6076569B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/083790 WO2016098261A1 (ja) 2014-12-19 2014-12-19 コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム

Publications (2)

Publication Number Publication Date
JP6076569B2 true JP6076569B2 (ja) 2017-02-08
JPWO2016098261A1 JPWO2016098261A1 (ja) 2017-04-27

Family

ID=56126178

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016557335A Expired - Fee Related JP6076569B2 (ja) 2014-12-19 2014-12-19 コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム

Country Status (3)

Country Link
JP (1) JP6076569B2 (ja)
SG (1) SG11201701212PA (ja)
WO (1) WO2016098261A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10242971A (ja) * 1997-03-03 1998-09-11 Nippon Telegr & Teleph Corp <Ntt> ネットワーク障害区間特定方法
JP2004343213A (ja) * 2003-05-13 2004-12-02 Nippon Telegr & Teleph Corp <Ntt> 冗長パス確立システムおよびユーザノード装置およびノード装置
JP2013545320A (ja) * 2010-12-01 2013-12-19 日本電気株式会社 通信システム、制御装置、通信方法及びプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3555342B2 (ja) * 1996-07-10 2004-08-18 松下電器産業株式会社 アルカリイオン整水器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10242971A (ja) * 1997-03-03 1998-09-11 Nippon Telegr & Teleph Corp <Ntt> ネットワーク障害区間特定方法
JP2004343213A (ja) * 2003-05-13 2004-12-02 Nippon Telegr & Teleph Corp <Ntt> 冗長パス確立システムおよびユーザノード装置およびノード装置
JP2013545320A (ja) * 2010-12-01 2013-12-19 日本電気株式会社 通信システム、制御装置、通信方法及びプログラム

Also Published As

Publication number Publication date
JPWO2016098261A1 (ja) 2017-04-27
SG11201701212PA (en) 2017-07-28
WO2016098261A1 (ja) 2016-06-23

Similar Documents

Publication Publication Date Title
CN107360092B (zh) 用于数据网络中的平衡负载的系统和方法
US9736263B2 (en) Temporal caching for ICN
US10257066B2 (en) Interconnect congestion control in a storage grid
US9609549B2 (en) Dynamic network load rebalancing
US8913613B2 (en) Method and system for classification and management of inter-blade network traffic in a blade server
CN104683257B (zh) 对进入流量执行流量负载平衡的方法和装置
CN109995653A (zh) 跨节点的数据传输方法、装置、系统及可读存储介质
US9455916B2 (en) Method and system for changing path and controller thereof
KR101724552B1 (ko) 네트워크 흐름을 처리 리소스로 정렬하는 기술
US11632288B2 (en) Determining the impact of network events on network applications
US11425030B2 (en) Equal cost multi-path (ECMP) failover within an automated system (AS)
US9800508B2 (en) System and method of flow shaping to reduce impact of incast communications
CN112311674B (zh) 报文发送方法、装置及存储介质
JP2017143344A (ja) パケット伝送装置,制御装置,及びパケット伝送制御方法
JP2017059885A (ja) コントローラ及び経路再設定方法
CN105207908B (zh) 一种报文处理方法及系统
CN106302006B (zh) 一种基于sdn的ip欺骗数据包的动态溯源方法
JP6076569B2 (ja) コネクションパス管理システム及びコネクションパス管理方法及びコネクションパス管理プログラム
US9699072B2 (en) Packet handling in information centric networking networks
JP6287443B2 (ja) 制御装置、及びそのテーブル作成方法
JP6363965B2 (ja) 帯域制御装置、帯域制御方法及び帯域制御プログラム
KR101707073B1 (ko) Sdn 기반의 에러 탐색 네트워크 시스템
JP2017130840A (ja) ネットワークスイッチ、ネットワーク制御装置、及び、ネットワークシステム
CN107113244B (zh) 一种数据转发的方法、装置和系统
JP2020136742A (ja) 通信制御方法

Legal Events

Date Code Title Description
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20161031

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20161213

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170110

R150 Certificate of patent or registration of utility model

Ref document number: 6076569

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees