JP2011170591A - 情報システム、装置および方法 - Google Patents

情報システム、装置および方法 Download PDF

Info

Publication number
JP2011170591A
JP2011170591A JP2010033375A JP2010033375A JP2011170591A JP 2011170591 A JP2011170591 A JP 2011170591A JP 2010033375 A JP2010033375 A JP 2010033375A JP 2010033375 A JP2010033375 A JP 2010033375A JP 2011170591 A JP2011170591 A JP 2011170591A
Authority
JP
Japan
Prior art keywords
information processing
flow
destination
node
information
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.)
Granted
Application number
JP2010033375A
Other languages
English (en)
Other versions
JP5506444B2 (ja
Inventor
Michitaka Okuno
通貴 奥野
Takemi Yazaki
武己 矢崎
Yuji Tsushima
雄次 對馬
Hideki Aoki
秀貴 青木
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.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2010033375A priority Critical patent/JP5506444B2/ja
Priority to EP20110154553 priority patent/EP2362606A1/en
Priority to US13/028,282 priority patent/US8782239B2/en
Publication of JP2011170591A publication Critical patent/JP2011170591A/ja
Application granted granted Critical
Publication of JP5506444B2 publication Critical patent/JP5506444B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0823—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/0833—Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for reduction of network energy consumption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

【課題】既存情報システムを利用している環境に対し、新たな情報処理位置を追加した場合、構成変更等を極力抑えながら情報処理位置を変更することが可能なシステムを提供する。
【解決手段】情報処理機能と任意の宛先変更機能を備えたインテリジェントノード100をパケットの通り道となるようにネットワークの境界上に配置する。このインテリジェントノード100は、各ユーザ端末340から送信されるパケット群をフローとして識別するためのフローテーブルと、各フローの接続状態（パケット通信のコネクション状態）と次の宛先、または、最終的な宛先を決定するフロー状態テーブルと、自身の情報処理機能の負荷状況観測機能を備える。そして、フロー状態テーブルで接続状態にないフローに関して、自身の情報処理機能部のうち負荷状況の少ない情報処理機能部か、外部の情報処理装置であるデータセンタ(DC)300等に宛先を書き換える。
【選択図】図１３

Description

本発明は、情報システム、特にデータセンタ集約型情報システムでの遅延時間・信頼性・エネルギー効率の諸問題を解決可能な情報処理と情報伝達の融合技術に関する。
情報システムの肥大化・複雑化を受けて「所有から利用」の流れが加速し、データセンタを利用するクラウド・コンピューティングの台頭、普及が進んでいる。
このデータセンタを利用する際、ネットワークを経由するため、遅延時間が生じる。特にデータセンタが遠方にある場合、公衆網を経由しての長距離伝送となるため遅延時間の他にも、信頼性の低下や、エネルギー効率の低下を招く可能性が高い。こうした問題に対し、情報処理位置をユーザ近傍に変更して情報処理を行う新情報通信技術(Information and Communication Technology: ICT)プラットフォームが解決策のひとつと考えられるが、情報システムは既に企業や社会の一部と化しているため、従来の情報システムを新ITCプラットフォームへ一度に移行することは困難である。
そこで、既存のデータセンタなどの情報システムとの整合性を取りながらシームレスに移行できる仕組みを持つ新ICTプラットフォームが必要となる。すなわち、情報伝達時のアドレスを既存体系のまま、新規設置される情報処理装置、情報処理位置へ伝達する技術が必要となる。従来、この情報処理位置を変えることで低遅延化を図る技術として以下の技術があった。
例えば、特許文献１において、ユーザLANに配置されたローカルサーバなどの情報処理装置に対して、ユーザが明示的にアプリケーション実行処理を依頼した場合、ローカルサーバに該当するアプリケーションが存在しなければ、ネットワーク外におかれるデータセンタなどの情報処理装置宛にパケットを流し、アプリケーション実行処理を依頼する構成が開示されている。
また、特許文献２においては、世界各地に分散配置された多数のサイトが存在する状況にあって、情報処理要求発行元の地域に応じて近接するサイトのアドレスを応答するように、DNS(Domain Name System)によって宛先アドレスを付与し、情報処理要求元が適切なサイトを参照するためのシステムを開示している。
特開２００２−３１２３１２号公報 特表２００２−５２０７３５号公報
本明細書において、ノード装置であるネットワークノードであって情報処理機能と宛先変更機能を有するものを、インテリジェントノード(Intelligent Node: IN)と呼ぶ。ここで、情報処理機能とはサーバなどの通常のコンピュータ（情報処理装置）などによるアプリケーションの実行や各種データを処理する機能を、宛先変更機能とはネットワーク上で転送されるパケットの宛先、または、出力先を変更する機能を言う。本明細書においては、このインテリジェントノード(IN)において、その内部のサーバによる情報処理する部位を情報処理機能部と呼び、当該インテリジェントノード(IN)外部のデータセンタや他のインテリジェントノード(IN)内のサーバ等を情報処理装置と呼ぶ。
また、センサからの情報を集約し、情報のフィルタリングを行うと共に、アクチュエータなどの制御対象などへの指示を伝達する機能を有する情報処理装置をエッジノードと呼ぶ。
新規に情報処理位置を設置した場合、データセンタなどの既存の情報システムとの整合性を取るためには、次の二つの課題をクリアする必要があると考えられる。
まず、課題１として、利用者側の設定の手間を省く必要があるため、新規提供するインテリジェントノードやエントランスノードを追加した場合でも、利用者側の設定を変更しないか、変更しても変更量を最小限に抑えて、情報伝達の流れを変更できなければならない。
次に、課題２として、通常、新規提供のノード単体はデータセンタより小型となるため、情報処理の負荷が高くなった場合、他のノードや、最悪の場合にデータセンタで当該情報処理を行った方が良い可能性がある。この場合、実行位置は比較的短時間で動的に変更させることになり、かつ、アプリケーション実行の不整合を起こさないように、アプリケーションの実行の切れ目で正しく実行位置を変えることが出来なければならない。
第一の従来技術では、利用者に対してローカルサーバへアクセスさせるための設定が必要であるが、この設定は全アプリケーションで共通化できるため、課題１は問題にならない可能性がある。しかしながら、ローカルサーバの処理負荷に応じて実行位置を変えることは言及しておらず、また、単純な拡張では対応できないので、課題２をクリアできない。
第二の従来技術では、利用者が目的の宛先を直接指定する場合には対応できないが、URL(Uniform Resource Locator)指定する場合は、利用者側の設定が不要であり、課題１をクリアできる。しかしながら、ユーザを誘導したサイトの負荷が増加してレスポンスが悪化する場合にDNSに新しい宛先を設定するまで、及びそれをユーザに反映するまでには時間がかかり、課題２をクリアできない。
本発明の目的は、既存の情報システムを利用している環境に対し、新たな情報処理位置を追加した場合に、利用者やデータセンタの設定や構成変更を極力抑えることを可能とし、更に、アプリケーション実行の切れ目を正しく認識して、その実行位置を動的に変更可能にする情報処理・伝達融合システム、ノード装置、及び方法を提供することにある。
上記の目的を達成するため、本発明においては、ネットワーク上に情報処理装置と、情報処理装置に処理を要求する端末とが配置される情報システムであって、ネットワークの境界位置（エッジルータ位置）またはゲートウェイ位置に配置される複数のネットワークノードと、複数のネットワークノードを管理する管理ノードとを備え、ネットワークノードは、任意のアプリケーションを実行するための情報処理機能部と、設定したルールに基づいて同一のヘッダ情報を持つパケット群をフローとして識別し、各フローの情報処理機能部または情報処理装置に対する接続状態、及び出力先を記録するためのテーブルに合致するフローの宛先、または出力先を、前記テーブルに記載の出力先に基づき変更する通信機能部を備え、管理ノードは、ネットワークノードの情報処理機能部に、情報処理装置で実施するアプリケーションを複製する要求と、テーブルの書換え要求を生成して、ネットワークノードに送信し、ネットワークノードは、管理ノードからの要求に従って、情報処理機能部にアプリケーションを複製し、書換え要求に基づきテーブルの出力先を書換える構成の情報システムを提供する。
また、本発明においては、上記の目的を達成するため、ネットワークを介して情報処理装置と接続されるノード装置であって、任意のアプリケーションを実行するための情報処理機能部と、受信したパケットを任意の宛先、または出力先に転送するための通信機能部を備え、通信機能部は、複数のパケットからなるフロー各々の、情報処理機能部または情報処理装置に対する接続状態及び出力先を記録するためテーブルと、テーブルに合致するフローの宛先、または出力先を、テーブルの出力先に基づき変更する出力先決定部を備え、出力先決定部は、接続状態が未接続状態にあるフローのテーブルの出力先を書換える構成のノード装置を提供する。
更に、本発明においては、上記の目的を達成するため、ネットワーク上に情報処理機能部を有するネットワークノードと情報処理装置とが配置される情報システムのネットワークノードにおける宛先変更方法として、ネットワークノードは、
受信したパケットを、複数のパケットからなるフロー各々の、情報処理機能部または情報処理装置に対する接続状態及び出力先を記録するテーブルを用いて、テーブルに合致するフローの宛先、または出力先を、テーブルの出力先に基づき変更し、パケットの情報に基づき、テーブルの出力先を書換える宛先変更方法を提供する。
また更に、本発明の好適な態様においては、情報処理機能部と宛先変更機能部を備えたノード装置であるインテリジェントノード（IN）をパケットの通り道となるようにネットワークの境界（エッジルータ位置）上に配置する。このインテリジェントノード（IN）は、テーブルとして、各ユーザ端末から送信されるパケット群をフローとして識別するためのフローテーブルと、各フローの接続状態（パケット通信のコネクション状態）と次の宛先、または、最終的な宛先を決定するフロー状態テーブルと、自身の情報処理機能部の負荷状況観測機能を備える。そして、フロー状態テーブルで接続状態にないフローに関して、自身の情報処理機能部のうち負荷状況の少ない情報処理機能部か、外部の情報処理装置宛に宛先を書き換える。
この「接続状態にないフローの宛先を書き換える」ことで、アプリケーションの実行の切れ目で、実行位置を変更可能にする。また、本操作は、利用者の設定を変更する必要がない。
本発明は、インテリジェントノード(IN)をエッジルータ位置、または、デフォルトゲートウェイ位置とするか、インテリジェントノード(IN)周囲の通信機器の特定方向のパケットの次宛先を当該インテリジェントノード（IN）とするネットワーク構成においてより好適に適用される。
本発明によれば、データセンタ集約型情報システムでの遅延時間・信頼性・エネルギー効率の諸問題を解決可能なシステムを提供できる。
また、新規提供するインテリジェントノードやエントランスノードを追加した場合でも、情報伝達時のアドレスを既存体系のまま、利用者側の設定の変更をしないか、変更しても変更量を最小限にして、情報伝達の流れを変更可能なシステムを提供することができる。
第１の実施例に係る、インテリジェントノードの装置構成を示す図である。 第１の実施例に係る、通信機能部の一構成を示すブロック図である。 第１の実施例に係る、フロー検出部とフローテーブルの一例を示す図である。 第１の実施例に係る、出力先決定部とフロー状態テーブルの一例を示す図である。 第１の実施例に係る、出力先決定部とフロー状態テーブルの他の例を示す図である。 第１の実施例に係る、パケットフォーマットの一例を示す図である。 第１の実施例に係る、フローテーブル及びフロー状態テーブルの式登録を説明するフローチャート図である。 第１の実施例に係る、フロー状態テーブルの書換えを説明するフローチャート図である。 第１の実施例に係る、フロー状態テーブルの状態遷移のための信号関係を示す図である。 第１の実施例に係る、フロー状態テーブルの状態遷移のフローチャートを示す図である。 従来のネットワーク構成を示す図である。 データセンタの一構成を示すブロック図である。 第１の実施例に係る、ネットワークの一構成を示す図である。 第１の実施例に係る、ネットワークの他の構成を示す図である。 第１の実施例に係る、ＷＡＮ内にインテリジェントノードを配置する場合の一構成例を示す図である。 第１の実施例に係る、フロー状態テーブルの遷移例（１）を示す図である。 第１の実施例に係る、フロー状態テーブルの遷移例（２）を示す図である。 第１の実施例に係る、フロー状態テーブルの遷移例（３）を示す図である。 第１の実施例に係る、フロー状態テーブルの遷移例（４）を示す図である。
以下、図面に従い、本発明の情報処理・伝達融合システム、並びにノード装置の好適な一実施例を説明する。
まず、第１の実施例である情報処理・伝達融合装置としてのインテリジェントノード(IN)の基本構成とネットワーク上での配置位置を図１、図１３〜図１５を用いて説明する。本実施例のインテリジェントノード（IN）は、サーバによる情報処理機能（サーバ処理機能）と宛先変更機能を備えている。後で詳述するように、この宛先変更機能により、例えば宛先、または出力先を自ノードに変えることで、本来、遠方のデータセンタ（Data Center: DC）等で行っていたアプリケーション処理を端末近傍のネットワークノードで実行でき、端末側から見た処理遅延を小さくする効果を得ることができる。更に、副次的にネットワーク中を流れるデータ量を抑えることができ、システム全体で見て省電力化の効果を得ることができる。
図１は第１の実施例のインテリジェントノード(IN)の構成の一例を示す図である。このインテリジェントノード100は、少なくとも一個のサーバによるサーバ処理機能と、通信機能部による宛先変更機能を備えている。
図１において、インテリジェントノード100は、複数のサーバ110-1〜110-4と、スイッチ120と、通信機能部130と、複数のネットワークインタフェース140-1〜140-4と、管理用ポート150とから構成される。サーバは通常のコンピュータ構成を有し、処理部である中央処理部(Central Processing Unit: CPU)と、CPUが実行する各種のプログラムやデータを記憶する記憶部としてのメモリや記憶装置を備えていることは言うまでもない。なお、具体的なサーバの内部構成は、図１２の際に言及することとする。
図１のインテリジェントノード100のネットワークインタフェース140-1〜140-4には、MAC(Media Access Control)アドレスeth3、eth2、eth1、eth0が与えられ、サーバ110-1〜110-4にはそれぞれIPアドレスIP B1〜IP B4、MACアドレスeth4〜eth7が与えられる。スイッチ120と、複数のサーバ110-1〜110-4、複数のネットワークインタフェース140-1〜140-4間は、イーサネット（登録商標）等を用いて接続する。なお、これらのイーサネットとしては、例えば１０ギガビットイーサネット（10Gigabit Ethernet）などが使用できる。
本実施例のインテリジェントノード(IN)が配置されるネットワーク構成は種々考えられるが、代表的な例を図１３〜図１５で説明する。
図１３は、好適なネットワーク構成の一例を示し、図１に示したインテリジェントノード100が複数、広域網(Wide Area Network: WAN)310と構内通信網(Local Area Network: LAN)330との間に配置されている。LAN340にはそれぞれ、ユーザのパーソナルコンピュータ(Personal Computer: PC)などの端末340が接続されている。一方、WAN310には少なくとも一個のインテリジェントノード100と、少なくとも一個の情報処理装置を備えたデータセンタ(DC)300と、管理ノード400が接続されている。
管理ノード400は、後で説明するように、アプリケーションを実行可能なインテリジェントノード100、及びデータセンタ(DC)300の性能情報、位置情報を収集し、アプリケーションの配置、インテリジェントノード(IN)の設定、ネットワーク間のネットワーク装置の設定等を行う。性能情報とは、装置が備えているCPUの種別や動作周波数、搭載数、メモリ容量、ディスク容量、OS種類、専用ハードウェア種別などである。位置情報とは、インテリジェントノードとデータセンタ(DC)300、情報処理を要求する端末やセンサなどとの間のネットワーク上の接続関係や通信遅延情報である。
この構成にあっては、情報処理位置は複数のインテリジェントノード100と複数のデータセンタ(DC)300となる。すなわち、情報処理位置が、データセンタ(DC)300のみならず、ユーザ近傍のインテリジェントノード100となる。このシステム構成をクラウド二層モデルと称する。なお、データセンタ(DC)300の内部構成は後で説明する。
図１４は、ネットワーク構成の他の例を示し、図１３のネットワーク構成との差分は、LAN330に複数の端末340の他に、エッジノード(EN)350が接続されていることにある。このエッジノード(EN)350には、各種のセンサ351や制御対象352が接続される。エッジノード(EN)350はLAN330と、センサ351、アクチュエータ等の制御対象352間に配置する。すなわち、エッジノード(EN)350はセンサ351からの情報を集約し、情報のフィルタリングを行うと共に、アクチュエータなどの制御対象352などへの指示を伝達する機能を有する。
これは、PCやモバイル端末などに代表される端末340の他に、大量のセンサ351や制御対象352をネットワーク接続する場合に、大量のセンサ情報がネットワークに流れ込み続けてネットワーク帯域を圧迫することを防ぐためである。エッジノード(EN)350は予め定めたルールに従ってセンサ情報をフィルタリングする。この構成において、エッジノード(EN)350も管理ノード400の管理対象である。なお、このエッジノード(EN)350にPC等のユーザ端末が接続されていても良い。本システム構成においても、情報処理位置は複数のデータセンタ(DC)300と複数のインテリジェントノード100となる。図１４のシステム構成はクラウド三層モデルと称する。
図１５は、ネットワーク構成の第三の例として、図１３や図１４のWAN310の中でインテリジェントノード100を配置するネットワーク構成を示す。同図において、WANとしてのネットワークA460-1では、WANの中でインターネットサービスプロバイダ(Internet Services Provider: ISP)などが管理する当該ネットワークの末端（ゲートウェイが置かれる位置、または、エッジルータが置かれる位置）にインテリジェントノード100を配置する方法を示す。450-1〜450-3は通信装置を示す。
この場合、ネットワークA460-1に流入するパケットは必ずインテリジェントノード100を通過するため、後述の宛先変更機能により、インテリジェントノード100において流入するパケットを自身のサーバに取り込んで情報処理したり、そのままデータセンタ(DC)等に転送したりすることができる。
一方、ネットワークB460-2では、ネットワークの末端の通信装置450-4、450-6、450-9に隣接する位置にインテリジェントノード100を配置する方法を示す。この場合、インテリジェントノード100に隣接する通信装置450-4、450-6、450-9がネットワークB460-2に流入してくるパケットをインテリジェントノード100へ転送する設定をしておくことで、ネットワークB460-2に流入する情報であるパケットのインテリジェントノード100での情報処理が可能になる。なお、450-5、450-7、450-8も通信装置を示す。
図１３〜図１５のネットワーク構成において、インテリジェントノード(IN)300は、後述する管理ノード400の指示に基づき配置されるアプリケーションを複製（コピー）し、その内部のサーバ処理機能によって実行する。
また、インテリジェントノード(IN)は、後で詳述するように、その宛先変更機能を利用し、特定の条件、すなわち、送信元IP(Internet Protocol)アドレス（SIP）、宛先IPアドレス(DIP)、送信元ポート番号(SP)、宛先ポート番号(DP)の組合せのみ、または、更にセッション識別子(ID)などに合致するパケットの宛先を、自ノード管理のサーバ110のいずれか、もしくは外部のインテリジェントノード(IN)、もしくはデータセンタ(DC）へ変更する機能を持つ。この際、後で詳述するように、インテリジェントノード(IN)内の宛先変更機能、もしくは、サーバ処理機能は、データセンタ(DC)300のIPアドレスを、自身のIPアドレスとしても利用する機能を持つ。
この宛先変更機能に基づく操作により、データセンタ(DC)300行きのパケットをインテリジェントノード(IN)に取り込むことを可能にする。自ノードのサーバ処理機能の負荷が高ければ宛先変更機能へ通知し、新規の優先度の低いユーザのパケットを外部へ転送する。また、自ノードのアプリケーションと連動するデータセンタ(DC)部分のアプリケーションに対し、一部のパケットを送信することも可能となる。更に、データセンタ（DC）は、インテリジェントノード(IN)から転送されるデータを蓄積、処理し、新規のパラメータやアクションをインテリジェントノード(IN)に通知する。
図１２に、図１３、図１４に示したデータセンタ(DC)300の一構成例を示す。同図に示すように、データセンタ(DC)300は、入り口に配置された代表サーバ301、内部でネットワーク接続された複数のサーバ302-1、302-2…、ディスク群303からなる。サーバ302-1で例示するように、各サーバは、通常のコンピュータであり、ネットワークインタフェース111、記憶部であるメモリ113とハードディスクドライブ(HDD)、マウスやディスプレイなどの入出力部(I/O)、処理部であるCPU112が内部バスで接続されている。
複数のサーバ302-1、302-2…は、CPU112上で種々のアプリケーションを実行する。ここで入り口に設置された代表サーバ301はWANに接続され、データセンタ300のロードバランサとして機能する。なお、本明細書において、このデータセンタ(DC)のサーバによる情報処理機能を纏めて情報処理装置と呼ぶことは上述した通りである。また、先に説明した図１のサーバ110-1〜110-4の内部構成は、上述のサーバと同様の構成を備えることは言うまでもない。
次に、図１３、図１４に示した管理ノード400の機能・役割について説明する。なお、管理ノード400の機能中、各種テーブルの設定管理については、図２〜図１１を用いた通信機能部130の説明中に行うものとする。
ユーザの要求するアプリケーション処理の結果を可能な限り速くユーザに返すためには、ネットワークの通信遅延とサーバ処理遅延の和が小さくなるように制御する必要がある。このために、図１３、図１４に示したように、ユーザ近傍のネットワークで従来ゲートウェイ(図１１のgateway320)装置が置かれる位置にインテリジェントノード100を配置し、複数のインテリジェントノードを管理するための管理ノード400をネットワーク上に配置する。なお、詳細な説明は省略するが、図１１は比較のために従来のネットワーク構成の一例を図示したものである。図１１のネットワーク構成の場合、情報処理位置はデータセンタ(DC)300のみである。
本実施例における管理ノード400の役割は、データセンタ(DC)300で実行している各種アプリケーションなどのサービスと対応するデータの一部、特にデータセンタ(DC)300内のアプリケーションサーバが実行中のものをインテリジェントノード(IN)に配置するなどの制御を行うことにある。
インテリジェントノード(IN)への各種の設定も、管理ノード400によって行われる。インテリジェントノード(IN)は、上述のとおりネットワーク中に複数存在し、それぞれが自身を通過するパケットフローの情報や、自身の各種の装置情報、例えば情報処理機能部を構成するサーバの数、それらのCPU性能、現在備えているアプリケーション、通信負荷状況や情報処理負荷状況、消費電力情報、などを通知する。管理ノード400はこれらの情報を鑑みて、上述のように、データセンタ(DC)300で稼動中のアプリケーションのうち、インテリジェントノード(IN)に配置したほうが良いものを選択し、インテリジェントノード(IN)へ複製して実行できる種類のアプリケーションであれば、指定のインテリジェントノード(IN)に当該アプリケーション、及び実行に必要な最小限のデータを転送する。
各インテリジェントノード(IN)は、これを受信し、管理ノード400から割り当てられたポリシーに従って、自身の情報処理機能部の一部もしくは複数に、当該アプリケーションとデータを複製する。ついでインテリジェントノード(IN)は、管理ノードからの宛先変更許可の指示を受けて、後で詳述する自身のフロー状態テーブル内の情報を観測しながら、未接続状況となった当該フローの宛先、または出力先を書換え、以後、当該フローから新規通信があると、当該フローの宛先、または出力先を替えることができる。
更に、管理ノード400は、データセンタ(DC)300と端末340等間の通信遅延を情報として含む全インテリジェントノード100、全エッジノード(EN)350のネットワーク上での配置関係、インテリジェントノード100上の情報処理資源、データセンタ(DC)300での情報処理内容をモニタする。このモニタは、インテリジェントノード100、エッジノード(EN)350、データセンタ(DC)300では、モニタ用プログラムを動作させておき、管理ノード400と各モニタ用プログラムの間でパケットベースの情報交換を行うことで実現可能である。
なお、管理ノード400は、管理対象の数が膨大になりうるため、階層的に管理ノードとして構成しても良い。例えば、複数のエッジノード(EN)を管理する孫管理ノードをインテリジェントノード100内のサーバの一つ（110−4）に割当て、複数のインテリジェントノード(IN)を管理する子管理ノードと、複数の子管理ノードを管理することで全体を管理する親管理ノードをWAN310上に配置し、相互に情報交換しながら管理を行うなどである。
階層的な場合においても、管理ノード400は、モニタした情報に基づき、データセンタ(DC)300に代わって、インテリジェントノード100が情報処理するためのアプリケーションを配布する役割を持つ。具体的には、管理ノード400は、インテリジェントノード100の中で孫管理ノードとして割り当てた管理用サーバ110-4に対して、アプリケーションを配布し、管理用サーバ110-4内の管理プログラムが所定のポリシーに基づき、アプリケーションをインテリジェントノード100内部のいずれかのサーバ110に適用する。
このポリシーとしては、例えば、当該アプリケーションで要求されるCPU能力、メモリ容量を満たしているサーバのうち稼働率の低い一つ、または複数のサーバに割り当てる方法がある。そのほか、アプリケーション毎に優先度を決めて、優先度の高いアプリケーションは稼働率の低い一つ、または複数のサーバに割り当て、優先度の低いアプリケーションは稼働率の高い一つ、または複数のサーバに割り当てる方法もある。尚、アプリケーションは配布した時点ではアイドル状態にあり、実際に、端末からのアプリケーション実行用のデータなどのパケット群が到着した時点で、実稼動することになる。
以上、本実施例における情報処理・情報伝達融合装置としてのインテリジェントノード(IN)の基本構成と、ネットワーク上での位置付け等を説明した。続いて、図２〜図６を用いてインテリジェントノード100の各種の機能・動作を説明する。
図２は、図１のインテリジェントノード100中の通信機能部130の一構成例を示す機能ブロック図である。同図から明らかなように、通信機能部130は、ネットワークインタフェース集約部131、パケット解析部132、フローテーブルを備えたフロー検出部133、フロー状態テーブルを備えた出力先決定部134、ネットワークインタフェース出力部135、テーブル更新部136の各機能ブロックから構成される。これらの各種機能ブロックはソフトウェアのみならずハードウェアとして構成しても良い。ソフトウェアとして構成する場合、通信機能部は、CPUとメモリを使い、そのCPUがメモリ上のプログラムを実行することにより実現することができる。
まず、ネットワークインタフェース集約部131は、図１の複数のネットワークインタフェース140-1〜140-4から流入するパケットを集約する機能を持つ。ここで集約されたパケットはパケット解析部132に送られ解析される。
図６に、本実施例で使用されるパケットのパケットフォーマットの一例を示す。なお図６のフォーマットにおいては、本実施例のシステム、装置と関係する部分のみを図示し、他は省略した。図６に示すとおり、データリンク層であるレイヤ２（L2）ヘッダ（一部抜粋）には、宛先MACアドレス10と、送信元MACアドレス11が配置されている。L2ヘッダは、装置Aから装置Bに対してパケットを転送する場合に、送信元MACアドレス11を装置Aの装置Bに接続されているネットワークインタフェースのMACアドレス（例えば、図１のeth1）、宛先MACアドレス１０を装置Bの装置Aに接続されているネットワークインタフェースのMACアドレスに設定する。
本実施例のシステムでは、インテリジェントノード100の通信機能部130のテーブル更新部136により、後で詳述するフロー状態テーブル中のインタフェース(interface)を書き換えることによって、パケットに付与するL2ヘッダのMACアドレスを変更する。例えば、インテリジェントノード100自身のサーバ110-1にパケットの宛先を強制的に変更する場合、送信元MACアドレス11を図１のeth0、宛先MACアドレス10をサーバ110-1のMACアドレスであるeth4と書き換えることによって、パケットをサーバ110-1に送信することができる。
このとき、前記パケットの宛先MACアドレスはサーバ110-1宛になっているが、宛先IPアドレスは元のままである。すなわち、自ノードのサーバ110は、自身のIPアドレス宛ではないパケットを受信することになる。通常は、サーバ110は、このパケットを受信することができないため、事前の設定、すなわち、フロー状態テーブル210で自身宛に設定するより前のタイミングで、当該フローの宛先IPアドレスを受信できるように設定しておく。また、当該フローに対してパケット返信する場合には、送信元IPアドレスを、本来の自身のIPアドレスではなく、上記の当該フローの宛先IPアドレスとする。この操作により、端末340側では、本来の宛先IPアドレス宛にパケットを送信しながら、実態として、本実施例のインテリジェントノード100の複数のサーバからなる情報処理機能部上で、不整合を起こすことなくアプリケーションの実行を行うことができる。
また、図６のパケットフォーマットにおいて、ネットワーク層であるレイヤ３(L3)ヘッダ（一部抜粋）には送信元IP(Internet Protocol)アドレス(SIP)12、宛先IPアドレス(DIP)13、プロトコル(Protocol)番号14が配置されている。このL3ヘッダは、IP通信をする場合に、送信元IPアドレス12から宛先IPアドレス13に対してパケットをルーティングするのに用いる。また、プロトコル番号14によって、L4のプロトコル種別を区別する。本実施例においては、これらは、フローを検出するための条件として利用する。
更に、トランスポート層であるレイヤ４(L4)ヘッダには、送信元ポート番号(SP)15、宛先ポート番号(DP)16が配置されている。L4ヘッダは、通信するアプリケーションなどを示すために用いられるが、これらも、フローを検出するための条件として利用する。
最後に、アプリケーション層であるレイヤ７(L7)ヘッダ、もしくはL7ペイロード（一部抜粋）にはセッション識別子(ID)17とその他のペイロードが配置されている。
このセッションID１７は、特定のユーザや情報発信元からのアクセスを認識するための識別子である。例えば、webデータのやりとりにはhttp（HyperText Transfer Protocol）というプロトコルがwebブラウザとwebサーバ間で利用されるが、httpには状態を保持する機能がなく、ユーザが連続的に複数回のアクセス(webページの表示)をしても、サーバ側はそれを特定のユーザのアクセスとは認識できず、複数のユーザによるアクセスと看做してしまう。これは、あるサイトにログインして買い物などをする場合に不都合であり、特定ユーザを認識する必要がある。セッションID17は、このような場合に特定ユーザを識別するために用いることができる。
通常、ユーザを特定するための仕組みとして、初回アクセス時のユーザに対して、サーバ側からユーザに対して自動的に識別コードを割り振り、その識別コードを使用してユーザを特定する。この識別コードが上述のセッションIDである。ユーザ（ブラウザ）は、そのWebサイトにアクセスする度に、毎回必ずセッションIDを送信する必要がある。セッションIDは、通常クッキーとしてブラウザに記憶され、Webサイトにアクセスするときにはブラウザが自動的に送信する。セッションIDを使用してユーザを識別できるようになれば、そのセッションIDをキーにして、サーバ側で情報を保存する場所を用意できる。この説明では、webデータのやりとりのクッキーを例にしたが、ユーザや情報発信元を特定する情報をセッションID１７と定義することができ、本実施例においてもその役割を利用する。
このセッションID１７は、各パケットのL7ヘッダかL7ペイロードに含まれる場合と、複数のパケットのL7ペイロードに跨って含まれる場合がある。前者の場合は、各パケットの中身を検査することでセッションIDを特定できる。後者の場合は、一旦、パケットのL7までのヘッダを外し、正しい順番でL7ペイロードを組み合わせ、アプリケーションのデータとして復元してそのデータを調べることでセッションIDを特定できる。
図２のインテリジェントノード(IN)の通信機能部130の説明に戻り、パケット解析部132は、順次流入する各パケットを解析し、必要な情報をテーブル更新部136に送信すると、テーブル更新部136は、受信した情報に基づき、記憶部に記憶されたテーブルの内容を更新する。すなわち、テーブル更新部136は、フローテーブル、フロー状態テーブルの更新を行う。
ここで図１に戻り、インテリジェントノード100内部の各サーバ110-1〜110-4の負荷情報の通知機能について説明する。サーバ110の処理部であるCPUは、サーバ自身の負荷情報をつめた制御パケットを定期的に通信機能部130に転送する。転送の時間間隔は、上述の管理ノード400からの指示によるが、例えば、10ms間隔、50ms間隔、1s間隔などに設定される。言うまでもなく、各サーバ110上には負荷情報をモニタし、一定間隔で指示された宛先にパケットとして通知するための上記のプログラムを稼動させておく。
各サーバ110-1〜110-4が負荷情報通知機能で通知する負荷情報は、例えば、CPUの利用率の平均値（定期通知するまでの期間の平均値）、メモリ利用率（または、搭載メモリ容量に対するメモリ利用量）の平均値を通知する。CPU利用率、および、記憶部であるメモリ利用率の片方、または、双方が予め定めた閾値を超えていれば負荷が高いと判断できる。負荷の高低の判断は、送信元のインテリジェントノード(IN)で行っても良いし、受信側のインテリジェントノード(IN)で行っても良い。いずれの場合でも、最終的には、受信側のインテリジェントノード(IN)のテーブル更新部136が判断結果としての負荷情報を利用して、各テーブルの更新を行う。
インテリジェントノード(IN)の通信機能部130でパケットを受信すると、パケット解析部132で、宛先MACアドレスと宛先IPアドレスを検査することにより、当該インテリジェントノード(IN)自身宛の制御パケットか、それ以外の宛先のパケットか調べる。自身宛の制御パケットであり、負荷情報が記載されていれば、該当する負荷情報をテーブル更新部136へ転送し、次回のフロー情報テーブル210の更新時に利用する。例えば、テーブル更新部136は、各更新時において、到着している負荷情報を検査する。そこに該当サーバのCPUの負荷が80%となっており、閾値が70%に設定してあった場合、処理負荷が閾値を超えたと判断することができる。
なお、負荷情報を通知するパケットの形式は、例えば、図６のパケットフォーマットでL7ペイロード18部分に負荷情報を記載したものとなる。送信元IPアドレス12はサーバ自身のIPアドレスとし、宛先IPアドレス13を指定するインテリジェントノードとする。
図３に示すよう、フロー検出部133は、フローテーブル200を用いて、フロー検出、フロー番号の特定を行う。図３のフローテーブル200に明らかなように、フロー検出に使用するサーチキー（search key）201は、パケットを解析して得た各種レイヤの情報に対応することは言うまでもない。そして、該当するフロー検出結果(result #)202が出力先決定部134に出力される。
図４に示すように、出力先決定部134は、フロー状態テーブル210を用いて、フロー検出部133の検出結果に基づき、該当パケットを出力するネットワークを決定し、ネットワークインタフェース出力部135に出力する。図４に明らかなように、フロー状態テーブル210は、フロー(flow)番号211に対応して、状態(status)212、次ホップ(next hop)213、及びインタフェース(interface)214についての情報を蓄積、更新している。
このフロー状態テーブル210の次ホップ(next hop)213とは、「次に中継する必要のある装置のIPアドレス（L3論理情報）」を、インタフェース(interface)214とは、「next hop213に接続されている当該装置のインタフェース名称（送信元MACアドレス相当）（L2物理情報）」である。宛先MACアドレスは、next hop213のIPアドレスに対してアドレス解決プロトコル(Address Resolution Protocol: ARP）処理することで求まり、その結果は、一般に、ARPテーブルと呼ばれる情報リストに記録される。本実施例では、このARPテーブルの説明は省略する。
図４のフロー状態テーブル210に見るように、フロー211中のflow#0〜flow#3には、それぞれ状態(status)212として「接続開始中」、「接続中」、「接続終了中」、「未接続」が対応している。
図５に出力先決定部134が利用するフロー状態テーブルの他の構成を示す。図５に示すフロー状態テーブル210Bでは、図４のフロー状態テーブル210の構成に加え、更に、新宛先(new destination)215欄を備えている。この新宛先215は、例えば、flow#3のように状態212が「未接続」の場合、新宛先の装置のIPアドレス（IP D）が、当該フローの最終宛先として設定されたことを示している。
図３にその一例を示したフローテーブル200の設定は、先に説明した管理ノード400が行う。具体的には、フローとして定義したいフィールドの組合せ、例えば上述の宛先IPアドレス(DIP)、送信元IPアドレス(SIP)、宛先ポート番号(DP)、送信元ポート番号(SP)などの組合せを列挙した情報を、フロー番号(flow#)と一緒に各インテリジェントノード(IN)に通知する。これを受信したインテリジェントノード100の通信機能部130が、テーブル更新部136を利用してフローテーブル200の設定更新を行う。尚、フロー番号と一緒に通知するフィールド組合せの情報と共に、各フローの優先度を定義して通知しても良い。フロー状態テーブル210は専用のハードウェア回路、もしくは、ソフトウェアにより作成することができる。
さて、インテリジェントノード100自身宛以外のすべてパケットは、パケット解析部132でパケット内の各種のヘッダ情報、必要ならペイロード情報の解析をして、フローテーブル200が管理する要素を抽出したのち、フロー検出部133へ渡され、フロー検出部133が当該パケットのフロー番号(flow#)を特定する。インテリジェントノード100自身宛のパケットは、制御パケットであり、制御パケットの中身がフロー更新情報であれば、テーブル更新部136がフローテーブル200を更新する。また、制御パケットの中身が、後述する負荷情報であれば、フロー状態テーブル210の更新に利用される。
フロー状態テーブル210の初期設定、および、フロー状態テーブル210の更新のためのポリシー定義は上述の通り、管理ノード400が行う。具体的には、管理ノード400は、初期設定として、対応するフローの次ホップ(next hop)、及びインタフェース(interface)の初期値を予め準備する。最初にデータセンタ(DC)300上で動作しているアプリケーションであれば、次ホップ(next hop)はデータセンタ(DC)300へパケットを転送するための次転送先の通信装置のIPアドレス、インタフェース(interface)は、その通信装置が接続されているインテリジェントノード100の物理ポートとする。
フロー状態テーブル210は専用のハードウェア回路、もしくは、ソフトウェアにより作成する。例えば、図１の通信機能部130の中の出力先決定部134にフロー状態テーブル210を配置する。ソフトウェアで作成する場合、上述したメモリ上にテーブルが作成される。なお、出力先決定部134には、通常のルーティングテーブルも置かれている。そして、本実施例において、フロー状態テーブル210に登録があるフローに関しては、ルーティングテーブルによるルーティングではなく、フロー状態テーブル210に記載のルーティングを優先することで、パケットの宛先変更を可能にする。
変形例としてフロー状態テーブル210を図１のサーバ110部分に備えても良い。この場合、通信機能部130では、宛先、または出力先を変更する可能性のあるものは出力先決定部134で、通常のポリシーベースルーティングの機能を用い、アプリケーションの切れ目に関係なく、該当するフローに属するパケットを該当するサーバ110に転送する。サーバ110は、ソフトウェア的、論理的にフロー状態テーブルを備え、そこでパケットを当該フロー状態テーブルの記載通りに転送する。サーバ110はCPUによるソフトウェアプログラムベースで動作するため速度的に問題があれば、サーバ110部分に専用のハードウェア回路を用いることもできる。
さて、図５のフロー状態テーブル210Bに示す新宛先(new destination)215のフィールドを設ける場合、出力先決定部134において、入力パケットの宛先IPアドレスを新宛先(new destination)215に記載のIPアドレスに変更することになる。この場合、出力先決定部134は、一旦、通信の終端を行い、新たに、新宛先(new destination)215に対して通信を開始することになる。フロー状態テーブル210Bの新宛先(new destination)215を用いる方法は、端末に対し一旦通信を終端し、新規の通信を新宛先に対して行い、結果として端末が新宛先と通信しているのと同等の効果が得られる。
なお、上述した通り、本実施例においても、パケットのインテリジェントノード(IN)からの出力先を決定するために、図示を省略したルーティングテーブルを併用する。より具体的には、フロー情報テーブル210、210Ｂを検索した結果、登録がないことが判明すれば、その後に従来どおりルーティングテーブルを検索して出力先を示す次ホップ(next hop)とインタフェース(interface）を決定する。なお実装上は、フロー情報テーブルとルーティングテーブルを同時に検索しておいても良い。この場合、フロー情報テーブル210、210Bに登録があればフロー情報テーブルで出力先を決定する。
フロー情報テーブルもルーティングテーブルも、インテリジェントノード(IN)からの出力先を決定するという基本機能は同一である。しかしながら、ルーティングテーブルが、OSPF(Open Shortest Path First)やBGP(Border Gateway Protocol)等のルーティングプロトコルにしたがって宛先IPアドレスに対する出力先を決定するのに対し、本実施例におけるフロー状態テーブルは、管理ノード400の指示、および、サーバ110の負荷状況によってパケット内の複数のフィールドに対応する出力先を決定する点において、その機能構成は全く異なっている。すなわち、本実施例におけるフロー状態テーブルを用いることによって、フローの状態に応じて出力先を変更するため、アプリケーションを実行するサーバ位置、すなわち情報処理位置の動的な変更が可能になる。
次に、図７〜図９を用いて、本実施例における各テーブルの初期登録、およじその書換え処理フローについて説明する。
まず、フローテーブル200自体の登録は、上述したとおり、図１３、図１４に示した外部の管理ノード400または、管理者が行う。前者の場合は、先に説明したとおりフローテーブル200を更新するためのフロー更新情報を含むパケットを管理ノード400が生成し、該当のインテリジェントノード100宛に送信する。インテリジェントノード100内部での具体的処理は後に述べる後者の場合は、図１に示した管理用ポート150経由で通信機能部130内のテーブル更新部136へ指示する。尚、前者の場合に、管理ノード400からの通信用のネットワークを管理用ポート150に接続するよう構成しても良い。
図７にフローテーブル200とフロー状態テーブル210の初期登録フローチャートを示した。同図において、テーブル更新部136において初期登録が開始されると（S400）、まず自ノード通過パケットの有無が判断され（S401）、通過パケット有りの場合、フローテーブル200に登録有か否かが判断される（S402）。フローテーブル200に登録が有る場合、フロー状態テーブル210の状態(status)212を更新する。
次に、図８にフロー状態テーブルの書換えフローチャートを示した。テーブル更新部136において、書換えフォローチャートが開始されると(S500)、まずフロー状態テーブル登録フローに対し、自ノードサーバで実行要求があるか否かがチェックされる(S501)。実行要求が有り(yes)の場合、当該フローの状態(status)212が「未接続」か否かがチェックされる（S502）。ここで「未接続」と判断(yes)された場合、フロー状態テーブル210の該当エントリの次ホップ(next hop)213、インタフェース(interface)214、更には新宛先(new destination)215を自ノードの指定宛先に書換える。
自ノードサーバで実行要求がない場合(S501でno)、先に例示して説明したように、フロー状態テーブルと登録フローが利用するサーバの処理負荷が閾値を超えたか否かを判断する(S504)。超えたと判断(yes)された場合、該当フローで未接続状態のものが有るか否かを判断し(S505)、有り(yes)の場合、フロー状態テーブル210の該当エントリの次ホップ(next hop)213、インタフェース(interface)214、更には新宛先(new destination)215を、現在とは別の指定先に書換えを行う（S506）。ステップS503、S506終了後、あるいはステップS502、S504、S505で否(no)と判断された場合、ステップS501に戻る。
図９に、伝送制御プロトコル(Transmission Control Protocol: TCP)接続の場合を例にとり、フロー状態テーブル210の状態(status)遷移のための信号関係の一例を示した。同図において、端末Ａとは、図１３、図１４の端末340の何れか一つを示し、本装置は、本実施例のインテリジェントノード(IN)、外部サーバとは、後で説明するデータセンタ(DC)300内のサーバ、あるいはネットワーク上の他のインテリジェントノード(IN)内のサーバを意味する。
同図から明らかなように、通常のTCP接続同様、未接続状態において、端末Ａから、同期（syn）パケットが送信(S600）されると、インテリジェントノード(IN)である本装置から、所定の外部サーバに対して同期(syn)パケットが送信され(S601)をステップS602〜S605で接続開始中の状態に移る。接続中、端末Ａから本装置を介して外部サーバにデータ等の情報パケットが送信される（S606）。送信終了後、ステップS607〜S614で接続終了処理がなされ、処理完了後、未接続状態に戻る。以上の接続開始中、接続中、接続終了中、未接続は、図４、図５中の状態(status)に対応することは言うまでもない。
図１０に、所定のフローが未接続または不明状態の場合の状態(status)遷移のフローチャートを示す。図９の本装置であるインテリジェントノード100が同期（syn）パケットを受信(S601)し、ステップS602〜S604を経て、フローの状態を接続中に遷移する(S605)。その後、図９で説明したように、接続中の状態で情報パケットが送なされた後（S606）、ステップS607〜S613を経て、接続終了処理がなされ、未接続状態に遷移する（S614）。
さて、本実施例における管理ノード400は、あるフローに属するアプリケーションは、所定のインテリジェントノード(IN)上で実行したほうが良いと判断した場合、当該インテリジェントノード(IN)に対して実行指示を出す。この実行指示が記載された制御パケットは、当該インテリジェントノード(IN)のテーブル更新部136に到達し、上述した図８のフローチャートでS501からS502状態へ遷移する。
ここで、フロー情報テーブル210の状態（status）フィールド212の初期値は、タイミングによって変わってしまうので、最初は不明の状態である。不明状態の場合、当該フローの状態遷移自体は図１０のフローチャートどおりであるが、図８のステップS502の判断で未接続とならないため、ステップS503の状態に遷移はできない。しかし、当該フローの観測を続けることで、不明状態からやがて接続開始中状態（S601→S602）に遷移でき、この遷移を続けるとやがて、必ず未接続状態に遷移できる。この未接続状態に遷移した後、図８のフローチャートでS502からS503の状態に遷移し、フロー状態テーブル210の宛先情報を変更し、管理ノード400の指示等に従い、パケットの転送先をデータセンタ(DC)からインテリジェントノード100の中のサーバ110に変えることで情報処理位置を変更することができる。
上述の通り、管理ノード400は、フロー状態テーブル210更新のポリシー定義も制御パケットを通じてインテリジェントノード100のテーブル更新部136へ通知する。ポリシー定義の例としては、優先度の高いフローは、インテリジェントノード100内部の極力同じサーバ110に割当続け、優先度の中くらいのフローは、インテリジェントノード100内部の優先度の高いフローとは別のサーバ110に割り当て直す、優先度の低いフローは、別のインテリジェントノード(IN)か、データセンタ(DC)に割り当てなおす、というものがあげられる。このポリシーは、図８のフローチャートのS504状態において観測するサーバの処理負荷の閾値を優先度毎にわける、例えば高優先のフローは閾値を高くし、低優先のフローは閾値を低くすることなどで実現できる。
尚、情報処理機能を別のインテリジェントノード(IN)に割り当てる場合は、当該インテリジェントノード100でパケットを、別のインテリジェントノード(IN)宛のIPアドレスを含むL3ヘッダでカプセル化するか、IPアドレス自体を書き換えてしまう方法がある。このほかにも、データセンタ(DC)までの経路上に別のインテリジェントノード100が存在することを期待して、データセンタ(DC)に通じる出口インタフェースからパケットをそのまま出力してしまう変形もある。
更に、本実施例においては、管理ノード400からの指定があれば、インテリジェントノード100は自身の各サーバ110の負荷情報をまとめた情報を、定期的に他のインテリジェントノード100の通信機能部130へ通知する。全てのインテリジェントノード同士が通知しあうと、オーバーヘッドが大きくなってしまう場合や、そもそも、元のデータセンタ(DC)で実施したほうが小さい遅延になる場合があるので、当該ユーザ用の情報処理を実施する可能性のあるインテリジェントノード(IN)同士で通知しあう。また、可能であれば、管理ノード400はデータセンタ(DC)の負荷情報を集約し、これを、関係するインテリジェントノード(IN)へ通知するようにしてもよい。
続いて、図１６〜図１９の具体例を用いて、本実施例の宛先変更機能の理解のため、フロー状態テーブルの遷移の一例を説明する。本例は未接続のフローに対して、次ホップ(next hop)、インタフェース(interface)を書換える場合の例である。
図１６において、フロー状態テーブル210は、初期状態S1において、全フローともにノード外部宛に設定されている。すなわち、全てのフロー(flow#0〜flow#3)に対し、次ホップ(next hop)213、インタフェース(interface)214がIPアドレスIP A、MACアドレスeth1に設定されている。次に状態S2では、flow#0が接続中、flow#2が未接続となったことを検出する。そして、状態S3において、未接続のflow#2の次宛先をIPアドレスIP B1の自ノードサーバ110-1、出力インタフェース(interface)をサーバ110-1が接続されるMACアドレスeth0に変更する。その後、状態S4では、flow#2が接続開始中となり、宛先はIPアドレスB1のサーバ110-1に変更されている。また、flow#3の次宛先をIPアドレスB1の自ノードサーバ110-1、出力インタフェース(interface)をMACアドレスeth0に変更する。
図１７において、状態S4に続き、状態S5では、flow#2が接続中となり、flow#0、flow#1が接続終了中に遷移し、flow#3が接続開始中に遷移する。同様に、状態S6では、flow#0、flow#1が未接続に遷移し、flow#3が接続中に遷移する。更に、状態S7では、未接続状態のflow#0、flow#1の次宛先をそれぞれIPアドレスがIP B1、IP B2の自ノードサーバ110-1、110-2、出力インタフェース(interface)をMACアドレスethoに変更する。
図１８において、状態S7に引き続き、状態S8では、flow#0、flow#1が接続中に遷移し、flow#3が接続終了中に遷移する。そして、状態S9では、flow#3が未接続に遷移すると、状態S10において、当該ノードの処理負荷が高くなったと判断し、未接続状態のflow#3の次宛先をIPアドレスIP Aの当該ノードに接続される次の装置とし、出力インタフェース(interface)をMACアドレスeth1に変更する。
図１９において、状態S10に引続く状態S11では、flow#3が自ノード外で接続開始中に遷移していることを検出する。この後、fflow#3に対しては、未接続状態になるまで次ホップ(next hop)213とインタフェース(interface)214の変更は禁止される。最後に、状態S12では、flow#3が自ノード外で接続中に遷移する。
上述した第１の実施例の構成により、遠方のデータセンタの処理を、端末近傍のネットワークノードで実行できるようになる。通常は、この宛先変更機能により、端末から見た処理遅延Z（通信距離の遅延Aとアプリケーション実行時間の遅延Bの和）が小さくなる。ただし、ネットワークノードのサーバによる情報処理機能の負荷が高くなってくると、アプリケーション実効時間の遅延Bが大きくなって、結果として端末から見た処理遅延Zが当初の目論見より大きな値になりうる。その際には、インテリジェントノード(IN)が現状を管理ノードへ報告し、管理ノードから新規の宛先変更指示を待つよう構成することもできる。あるいは、予め、宛先変更ポリシーを管理ノードから貰っておいて、そのポリシーが適用される状況（ここでは、当初目論見より大きな遅延になってしまった状況）になったら、各インテリジェントノードが自律的に宛先変更を行うよう構成してもよい。
新規の宛先は、次ホップ（next hop）とインタフェース(interface)を書き換えるだけであれば、自インテリジェントノードに直結される次の装置（多くの場合は通信装置）に転送され、その後は、通常のルーティングに従う。この際、データセンタまでの経路上の別のインテリジェントノードがあり、そのインテリジェントノードでフロー状態テーブルが同様に記載されていればそのインテリジェントノードにパケットが取り込まれ、そこでアプリケーションが実行される。経路上にインテリジェントノードがなければ、データセンタに到達し、当初どおり、データセンタで処理が行われる。また、次宛先（next destination）を変えれば、明示的に最終的な宛先を変更することができる。つまり、明示的に次の近傍に存在するインテリジェントノードを指定しても良いし、最終的なデータセンタを指定しても良い。
以上詳述してきた本発明によれば、本来、遠方のデータセンタで行っていたアプリ処理を端末近傍のネットワークノードで実行でき、端末側から見た処理遅延を小さくすることができる。また、ネットワーク中を流れるデータ量を抑えられ、システム全体で見て省電力化が図れる。
本発明は、情報システム、特にデータセンタ集約型情報システムでの遅延時間・信頼性・エネルギー効率の諸問題を解決可能な情報伝達と情報処理の融合技術として極めて有用である。
100…インテリジェントノード
110…サーバ
120…スイッチ
130…通信機能部
131…ネットワークインタフェース集約部
132…パケット解析部
133…フロー検出部
134…出力先決定部
135…ネットワークインタフェース出力部
140…ネットワークインタフェース
150…管理用ポート
200…フローテーブル
210、210B…フロー状態テーブル
300…データセンタ(DC)
301…代表サーバ
302…サーバ
303…ディスク群
310…WAN
320…ゲートウェイ
330…LAN
340…端末
350…エッジノード
351…センサ
352…制御対象。

Claims (20)

  1. ネットワーク上に、情報処理装置と、前記情報処理装置に処理を要求する端末とが配置される情報システムであって、
    前記ネットワークの境界位置またはゲートウェイ位置に配置される複数のネットワークノードと、複数の前記ネットワークノードを管理する管理ノードとを更に備え、
    前記ネットワークノードは、
    任意のアプリケーションを実行するための情報処理機能部と、
    受信したパケットを任意の宛先に転送するため、前記パケットに関して設定したルールに基づいて同一のヘッダ情報を持つ前記パケット群をフローとして識別し、
    前記フロー各々の、前記情報処理機能部または前記情報処理装置に対する接続状態、及び出力先を記録するためのテーブルに合致する前記フローの宛先、または出力先を、前記出力先に基づき変更する通信機能部を備え、
    前記管理ノードは、前記ネットワークノードの前記情報処理機能部に、前記情報処理装置で実施するアプリケーションを複製する要求と、前記テーブルの書換え要求を生成して、前記ネットワークノードに送信し、
    前記ネットワークノードは、前記管理ノードからの要求に従って、前記情報処理機能部にアプリケーションを複製し、前記書換え要求に基づき前記テーブルの指定の前記フローに属する前記パケットの出力先を書換える、
    ことを特徴とする情報システム。
  2. 請求項１に記載の情報システムであって、
    前記ネットワークノードは、前記書換え要求に基づき、前記接続状態が未接続状態にある前記フローの前記テーブルの前記出力先を書換えする、
    ことを特徴とする情報システム。
  3. 請求項１に記載の情報システムであって、
    前記ネットワークノードは、
    前記情報処理機能部の負荷情報に基づき、前記テーブルの前記出力先を書換える、
    ことを特徴とする情報システム。
  4. 請求項１に記載の情報システムであって、
    前記テーブルは、指定の条件に従って、複数の前記パケットをフローとして認識して記録する第一のテーブルと、前記フロー各々の前記接続状態及び前記出力先を記録するための第二のテーブルと、
    からなることを特徴とする情報システム。
  5. 請求項４に記載の情報システムであって、
    前記第二のテーブルは、前記フロー各々の最終宛先を更に記録する、
    ことを特徴とする情報システム。
  6. 請求項１に記載の情報システムであって、
    前記ネットワークノードの前記情報処理機能部は、前記情報処理装置が実行するアプリケーションを前記ネットワーク経由でダウンロードし、当該アプリケーションを実行する、
    ことを特徴とする情報システム。
  7. 請求項６に記載の情報システムであって、
    前記ネットワークノードの前記通信機能部は、前記アプリケーションを実行するため、当該アプリケーションに関係する前記フローの前記テーブルの前記出力先を当該ネットワークノードの前記情報処理機能部に変更する、
    ことを特徴とする情報システム。
  8. ネットワークを介して情報処理装置と接続されるノード装置であって、
    任意のアプリケーションを実行するための情報処理機能部と、
    受信したパケットを任意の宛先に転送するための通信機能部を備え、
    前記通信機能部は、複数の前記パケットからなるフロー各々の、前記情報処理機能部または前記情報処理装置に対する接続状態及び出力先を記録するためテーブルと、前記テーブルに合致する前記フローの宛先、または出力先を、前記テーブルの前記出力先に基づき変更する出力先決定部を備え、
    前記出力先決定部は、前記接続状態が未接続状態にある前記フローの前記テーブルの前記出力先を書換える、
    ことを特徴とするノード装置。
  9. 請求項８に記載のノード装置であって、
    前記通信機能部は、前記情報処理機能部の負荷情報に基づき、前記テーブルの前記出力先を書換える、
    ことを特徴とするノード装置。
  10. 請求項９に記載のノード装置であって、
    前記テーブルの内容に優先度を設け、前記書換えの候補が複数ある際に、前記優先度の低い前記フローの前記テーブルの前記出力先を前記情報処理機能部以外に書換える、
    ことを特徴とするノード装置。
  11. 請求項８に記載のノード装置であって、
    前記情報処理機能部は、当該情報処理機能部のIPアドレスと、当該IPアドレス以外の指定されたIPアドレスを、当該情報処理機能部宛と認識し、前記指定されたIPアドレスに基づく処理の結果を出力する際に、送信元IPアドレスとして前記指定されたIPアドレスを用いる、
    ことを特徴とするノード装置。
  12. 請求項８に記載のノード装置であって、
    前記情報処理機能部で実行する前記アプリケーションを、前記情報処理装置から前記ネットワーク経由でダウンロードする、
    ことを特徴とするノード装置。
  13. 請求項８に記載のノード装置であって、
    前記テーブルは、
    指定の条件に従って、複数の前記パケットをフローとして認識して記録する第一のテーブルと、
    前記フロー各々の前記接続状態及び前記出力先を記録するための第二のテーブルと、
    からなることを特徴とするノード装置。
  14. 請求項１３に記載のノード装置であって、
    前記第二のテーブルは、更に前記フロー各々の最終宛先を更に記録する、
    ことを特徴とするノード装置。
  15. ネットワーク上に、情報処理機能部を有するネットワークノードと、情報処理装置とが配置される情報システムの前記ネットワークノードにおける宛先変更方法であって、
    前記ネットワークノードは、
    受信したパケットを、複数の前記パケットからなるフロー各々の、前記情報処理機能部または前記情報処理装置に対する接続状態及び出力先を記録するテーブルを用いて、前記テーブルに合致する前記フローの宛先、または出力先を、前記テーブルの前記出力先に基づき変更し、更に
    前記パケットの情報に基づき、前記テーブルの前記出力先を書換える、
    ことを特徴とする宛先変更方法。
  16. 請求項１５に記載の宛先変更方法であって、
    前記ネットワークノードは、前記パケットの情報である、前記ネットワークに接続された管理ノードからの書換え要求に基づき、前記接続状態が未接続状態にある前記フローの前記テーブルの前記出力先を書換える、
    ことを特徴とする宛先変更方法。
  17. 請求項１５に記載の宛先変更方法であって、
    前記ネットワークノードは、
    前記情報処理機能部の負荷情報に基づき、前記テーブルの前記出力先を書換える、
    ことを特徴とする宛先変更方法。
  18. 請求項１５に記載の宛先変更方法であって、
    前記ネットワークノードは、アプリケーションを前記ネットワーク経由でダウンロードし、前記アプリケーションに関係する前記フローの前記テーブルの出力先を前記ネットワークノードの前記情報処理機能部に書換えし、
    前記情報処理部で前記アプリケーションを実行する、
    ことを特徴とする宛先変更方法。
  19. 請求項１６に記載の宛先変更方法であって、
    前記ネットワークノードは、前記管理ノードからの要求に従って、前記情報処理装置が実行するアプリケーションをダウンロードし、前記情報処理部が前記アプリケーションを実行させる、
    ことを特徴とする宛先変更方法。
  20. 請求項１９に記載の宛先変更方法であって、
    前記ネットワークノードは、前記管理ノードからの前記書換え要求に従って、当該アプリケーションに関係する前記フローの前記テーブルの出力先を当該ネットワークノードの前記情報処理機能部に書換えする、
    ことを特徴とする宛先変更方法。
JP2010033375A 2010-02-18 2010-02-18 情報システム、装置および方法 Expired - Fee Related JP5506444B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2010033375A JP5506444B2 (ja) 2010-02-18 2010-02-18 情報システム、装置および方法
EP20110154553 EP2362606A1 (en) 2010-02-18 2011-02-15 Information system, apparatus and method
US13/028,282 US8782239B2 (en) 2010-02-18 2011-02-16 Distributed router computing at network nodes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010033375A JP5506444B2 (ja) 2010-02-18 2010-02-18 情報システム、装置および方法

Publications (2)

Publication Number Publication Date
JP2011170591A true JP2011170591A (ja) 2011-09-01
JP5506444B2 JP5506444B2 (ja) 2014-05-28

Family

ID=43920133

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010033375A Expired - Fee Related JP5506444B2 (ja) 2010-02-18 2010-02-18 情報システム、装置および方法

Country Status (3)

Country Link
US (1) US8782239B2 (ja)
EP (1) EP2362606A1 (ja)
JP (1) JP5506444B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017500771A (ja) * 2013-10-22 2017-01-05 ランディス・ギア イノベーションズ インコーポレイテッドＬａｎｄｉｓ＋Ｇｙｒ Ｉｎｎｏｖａｔｉｏｎｓ， Ｉｎｃ． データ・ネットワークにおける分散データ送信
JP2017111505A (ja) * 2015-12-14 2017-06-22 三菱重工業株式会社 計算機リソースの最適化システム、および、計算機リソースの最適化方法
US10009314B2 (en) 2013-09-12 2018-06-26 Mitsubishi Electric Corporation IP address distribution system, switch apparatus, and IP address distribution method

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102770852B (zh) 2010-02-18 2015-07-29 株式会社日立制作所 信息通信处理系统、方法和网络节点
JP5506444B2 (ja) * 2010-02-18 2014-05-28 株式会社日立製作所 情報システム、装置および方法
EP2759104B1 (en) * 2011-09-21 2017-06-21 Nec Corporation Communication apparatus, communication system, communication control method, and program
CN103139071B (zh) 2011-11-29 2016-07-13 华为技术有限公司 报文转发方法、装置和系统
US9654415B2 (en) 2012-04-20 2017-05-16 Hitachi, Ltd. Information processing system, management server group, and server management program
CN105264869B (zh) * 2013-06-26 2019-05-03 华为技术有限公司 一种ip地址分配的系统和方法
CN114205926B (zh) * 2015-09-29 2024-01-16 株式会社宙连 控制装置和存储介质
WO2018183526A1 (en) 2017-03-29 2018-10-04 Fungible, Inc. Non-blocking, full-mesh data center network having optical permutors
CN110710172A (zh) 2017-03-29 2020-01-17 芬基波尔有限责任公司 在接入节点组内多路复用分组喷射的无阻塞的任意到任意数据中心网络
WO2018183542A1 (en) 2017-03-29 2018-10-04 Fungible, Inc. Non-blocking any-to-any data center network with packet spraying over multiple alternate data paths
CN117971715A (zh) 2017-04-10 2024-05-03 微软技术许可有限责任公司 多处理器系统中的中继一致存储器管理
WO2019014265A1 (en) * 2017-07-10 2019-01-17 Fungible, Inc. DATA PROCESSING UNIT FOR CALCULATION NODES AND STORAGE NODES
US10725825B2 (en) 2017-07-10 2020-07-28 Fungible, Inc. Data processing unit for stream processing
WO2019068013A1 (en) 2017-09-29 2019-04-04 Fungible, Inc. FABRIC CONTROL PROTOCOL FOR DATA CENTER NETWORKS WITH PACKAGING OF PACKETS ON MULTIPLE ALTERNATIVE DATA PATHWAYS
US10965586B2 (en) 2017-09-29 2021-03-30 Fungible, Inc. Resilient network communication using selective multipath packet flow spraying
WO2019104090A1 (en) 2017-11-21 2019-05-31 Fungible, Inc. Work unit stack data structures in multiple core processor system for stream data processing
WO2019152063A1 (en) 2018-02-02 2019-08-08 Fungible, Inc. Efficient work unit processing in a multicore system
WO2019215308A1 (en) * 2018-05-09 2019-11-14 NEC Laboratories Europe GmbH Leveraging data analytics for resources optimisation in a cloud-native 5g system architecture which uses service-based interfaces
US10929175B2 (en) 2018-11-21 2021-02-23 Fungible, Inc. Service chaining hardware accelerators within a data stream processing integrated circuit

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008072655A (ja) * 2006-09-15 2008-03-27 Fujitsu Ltd サービス通信制御方法、サービス中継装置およびサービス通信制御システム

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054935B2 (en) 1998-02-10 2006-05-30 Savvis Communications Corporation Internet content delivery network
US6108703A (en) 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
JP3994614B2 (ja) * 2000-03-13 2007-10-24 株式会社日立製作所 パケット交換機、ネットワーク監視システム及びネットワーク監視方法
US7139242B2 (en) * 2001-03-28 2006-11-21 Proficient Networks, Inc. Methods, apparatuses and systems facilitating deployment, support and configuration of network routing policies
JP2002312312A (ja) 2001-04-13 2002-10-25 Kit Asp:Kk 論理的階層構造のネットワーク構成を用いたアプリケーションサービス方法及びアプリケーションサーバシステム
US20030033467A1 (en) * 2001-08-08 2003-02-13 Satoshi Yoshizawa Method and apparatus for resource allocation in network router and switch
US20080008202A1 (en) * 2002-10-31 2008-01-10 Terrell William C Router with routing processors and methods for virtualization
US7483374B2 (en) * 2003-08-05 2009-01-27 Scalent Systems, Inc. Method and apparatus for achieving dynamic capacity and high availability in multi-stage data networks using adaptive flow-based routing
JP2005277804A (ja) * 2004-03-25 2005-10-06 Hitachi Ltd 情報中継装置
US20060155862A1 (en) * 2005-01-06 2006-07-13 Hari Kathi Data traffic load balancing based on application layer messages
JP4457058B2 (ja) * 2005-08-26 2010-04-28 アラクサラネットワークス株式会社 フィルタリングを備えるパケット転送装置
US8145732B2 (en) * 2005-11-21 2012-03-27 Intel Corporation Live network configuration within a link based computing system
DE602006012968D1 (de) * 2006-08-09 2010-04-29 Hitachi Ltd Anordnung zur Flußsteuerung von Datenpaketen
JP5156332B2 (ja) * 2007-10-30 2013-03-06 アラクサラネットワークス株式会社 パケット転送装置
US8565218B2 (en) * 2008-06-05 2013-10-22 Hewlett-Packard Development Company, L.P. Flow path discovery in network to guarantee multiple metric QoS constraints
WO2009155574A1 (en) * 2008-06-19 2009-12-23 Servicemesh, Inc. Cloud computing gateway, cloud computing hypervisor, and methods for implementing same
US8442048B2 (en) * 2009-11-04 2013-05-14 Juniper Networks, Inc. Methods and apparatus for configuring a virtual network switch
US8170016B2 (en) * 2009-11-30 2012-05-01 At&T Intellectual Property I, Lp Packet flow offload to remote destination with routing bypass
JP5506444B2 (ja) * 2010-02-18 2014-05-28 株式会社日立製作所 情報システム、装置および方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008072655A (ja) * 2006-09-15 2008-03-27 Fujitsu Ltd サービス通信制御方法、サービス中継装置およびサービス通信制御システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10009314B2 (en) 2013-09-12 2018-06-26 Mitsubishi Electric Corporation IP address distribution system, switch apparatus, and IP address distribution method
JP2017500771A (ja) * 2013-10-22 2017-01-05 ランディス・ギア イノベーションズ インコーポレイテッドＬａｎｄｉｓ＋Ｇｙｒ Ｉｎｎｏｖａｔｉｏｎｓ， Ｉｎｃ． データ・ネットワークにおける分散データ送信
JP2017111505A (ja) * 2015-12-14 2017-06-22 三菱重工業株式会社 計算機リソースの最適化システム、および、計算機リソースの最適化方法

Also Published As

Publication number Publication date
EP2362606A1 (en) 2011-08-31
US8782239B2 (en) 2014-07-15
US20110202658A1 (en) 2011-08-18
JP5506444B2 (ja) 2014-05-28

Similar Documents

Publication Publication Date Title
JP5506444B2 (ja) 情報システム、装置および方法
JP6721166B2 (ja) 仮想ネットワークにおける分散型フロー状態ｐ２ｐ設定のためのシステムおよび方法
US9647954B2 (en) Method and system for optimizing a network by independently scaling control segments and data flow
Scharf et al. Multipath TCP (MPTCP) application interface considerations
JP6080313B2 (ja) 仮想ネットワークを実装及び管理するシステム及び方法
US11303553B1 (en) Return path trace
JP5846221B2 (ja) ネットワークシステム、及びトポロジー管理方法
EP2157746B1 (en) Routing control system for L3VPN service network
TW202026896A (zh) 在網路路由環境中的非同步物件管理機制
JP5610247B2 (ja) ネットワークシステム、及びポリシー経路設定方法
TWI531908B (zh) A method of supporting virtual machine migration with Software Defined Network (SDN)
WO2021135420A1 (zh) 业务链的故障保护方法、装置、设备、系统及存储介质
JP5861772B2 (ja) ネットワークアプライアンス冗長化システム、制御装置、ネットワークアプライアンス冗長化方法及びプログラム
US10447652B2 (en) High availability bridging between layer 2 networks
US20110173344A1 (en) System and method of reducing intranet traffic on bottleneck links in a telecommunications network
JP2012533129A (ja) 仮想ネットワークの高性能で自動化された管理方法及びシステム
JP2006262193A (ja) 制御装置、パケット転送方法およびパケット処理装置
JP2008225644A (ja) ゲートウェイ装置、ゲートウェイ装置の負荷分散方法及びゲートウェイ装置の負荷分散プログラム
US20030229713A1 (en) Server network controller including server-directed packet forwarding and method therefor
JP2011159247A (ja) ネットワークシステム、コントローラ、ネットワーク制御方法
JP5966488B2 (ja) ネットワークシステム、スイッチ、及び通信遅延短縮方法
JP4619943B2 (ja) パケット通信方法、パケット通信システム
JP6510217B2 (ja) ネットワーク制御システム
JP5169988B2 (ja) ネットワーク装置
JP2012160926A (ja) 有害サイトフィルタリングシステム及びフィルタリング方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121011

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20131118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131217

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140210

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: 20140225

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140318

R150 Certificate of patent or registration of utility model

Ref document number: 5506444

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees