JP5621674B2 - 管理装置、通信システムおよびパケット通信方法 - Google Patents

管理装置、通信システムおよびパケット通信方法 Download PDF

Info

Publication number
JP5621674B2
JP5621674B2 JP2011061778A JP2011061778A JP5621674B2 JP 5621674 B2 JP5621674 B2 JP 5621674B2 JP 2011061778 A JP2011061778 A JP 2011061778A JP 2011061778 A JP2011061778 A JP 2011061778A JP 5621674 B2 JP5621674 B2 JP 5621674B2
Authority
JP
Japan
Prior art keywords
packet
loss
probe
manager
detection
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
JP2011061778A
Other languages
English (en)
Other versions
JP2012199719A (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.)
Fujitsu Ltd
Original Assignee
Fujitsu 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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2011061778A priority Critical patent/JP5621674B2/ja
Priority to US13/418,709 priority patent/US20120236705A1/en
Publication of JP2012199719A publication Critical patent/JP2012199719A/ja
Application granted granted Critical
Publication of JP5621674B2 publication Critical patent/JP5621674B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823Errors, e.g. transmission errors
    • H04L43/0829Packet loss
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0097Relays

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、管理装置、通信システムおよびパケット通信方法に関する。
従来、コネクション型の通信プロトコル(例えば、TCP(Transmission Control Protocol)など)を用いて、送信元ホストから送信先ホストに対してルータ経由でデータを送信するデータ通信が実施されている。例えば、図15に例示するように、送信元ホスト1は、複数のルータ3A〜3Dを経由させて、送信先ホスト2にデータを送信する。図15は、従来のネットワーク構成を示す図である。また、送信元ホスト1と送信先ホスト2との間で正常な通信が行われている間、送信先ホスト2は、通信プロトコルの標準機能により、送信元ホスト1から送信されたデータに対して、応答確認であるACK(Acknowledgement)メッセージを返送する。
一方、ネットワーク上で何らかの障害によりパケットロスが発生した場合に、送信先ホストは、ロスしたパケットに対するACKメッセージを返送しない。ここで、図16を用いて、パケットロスが発生した場合におけるデータ再送処理について説明する。図16は、パケットロスが発生した場合における従来のデータ再送要求処理を説明する図である。図16の例では、通信システムにおけるルータ3Cとルータ3Dとの間でパケットロスが発生した場合について説明する。図16に示すように、送信元ホスト1は、送信したパケットに対するACKメッセージを一定時間以上受信しない場合には、ACKメッセージ未受信のタイムアウトを検出し、パケットの再送信を試みる。その後も、送信元ホスト1は、ACKメッセージが受信できない場合は、送信元ホスト1からのデータ再送信が間隔を変えながら複数回繰り返し、データの再送信を試みる。
このような通信プロトコルの再送機能に任せたデータ復旧を行う場合には、パケットロス発生後、送信元ホストが障害の発生を認識し再送を開始するまでに長時間を要してしまう場合がある。このため、ネットワーク上にTAP(Test Access Point)と呼ばれる信号分岐装置を設置し、TAPにネットワークプローブ(以下、プローブという)を接続してパケットロスを検出し、パケットロス検出後にパケットの再送信を行う方法が知られている。例えば、図17に例示するように、送信元ホスト1と、各ルータ3A〜3Fと、送信先ホスト2との間のリンク上にTAP5をそれぞれ設置し、TAPにプローブ4A〜4Hを接続してパケットロスを検出する。図17は、ネットワーク内のプローブ設置例を示す図である。
このようなプローブ4A〜4Hは、ネットワーク上を流れるパケットを一定期間保持してパケットデータの解析を行い、コネクション型通信プロトコルのシーケンス番号の整合性をチェックすることで、パケットロスを検出する。そして、プローブ4A〜4Hがパケットロスを検出した場合には、送信元ホスト1は、送信先ホスト2に対してパケットの再送を行い、送信先ホスト2が再送パケットを受信するまで、パケットの再送を繰り返し行う。
ところが、送信元ホスト1は、送信先ホスト2に対してパケットの再送を繰り返し行うので、送信先ホスト2が再送パケットを受信するまでに時間がかかる場合がある。また、再送信処理を行う場合には、送信元ホスト1に再送信処理の負荷が集中する場合がある。
このため、図18に例示するように、ネットワーク上における各ルータ3A〜3Fに対して、プローブと同様のパケットロス検出の仕組みを搭載した上で、中継ルートの前段ルータに対してパケットの再送を依頼する方法が知られている。図18は、パケットロスが発生した場合における従来の再送要求処理を説明する図である。この方法では、再送依頼を受けた前段ルータは、中継済みのパケットを一定量保持しているバッファを検索し、再送依頼対象のパケットを見つけた場合には、送信先ホストに向けてパケットの再送を行う。例えば、図18に例示するように、ルータ3Dは、通信システムにおけるルータ3Cとルータ3Dとの間でパケットロスが発生したことを検出した場合には、前段ルータであるルータ3Cに対してパケットの再送を依頼する。ルータ3Cは、自装置のバッファを検索し、再送依頼対象のパケットが見つかった場合は、送信先ホスト2に向けてパケットの再送を行う。
特開2007−67814号公報 特開2003−333577号公報 特開2003−304273号公報
ところで、上記したルータに対してパケットの再送を依頼する技術では、確実かつ迅速にロスパケットを再送することができないという課題があった。つまり、従来の技術では、送信先ホストに向けてパケットの再送を行うので、パケットロスが特定の箇所で頻繁に起こるような状況では、前段ルータから再送を行っても再びパケットロスが発生する可能性が高く、確実かつ迅速にロスパケットを再送することができない。
一つの側面では、確実かつ迅速にロスパケットを再送することを目的とする。
第一の案では、管理装置は、検出装置からパケットの損失の通知を受信した場合に、該パケットの通信経路上で、当該検出装置よりも前記送信元装置の側に位置する他の検出装置から前記損失に係るパケットを収集する収集部と、前記収集部によって収集したパケットを、前記通信経路上で、前記損失を検出した検出装置よりも前記送信先装置の側に位置する他の検出装置に送信する送信部とを有することを特徴とする。
確実かつ迅速にロスパケットを再送することができる。
図1は、実施例1に係る通信システムの構成を示す図である。 図2は、マネージャおよびプローブのハードウェア構成を示す図である。 図3は、実施例1に係るマネージャの構成を示すブロック図である。 図4は、TCPコネクション確立時における統計情報の一例を示す図である。 図5は、経路情報の一例を示す図である。 図6は、送信元ホストと送信先ホストとの間で行われる通信経路の一例を示す図である。 図7は、パケットロス発生時における障害情報の一例を示す図である。 図8は、実施例1に係るプローブの構成を示すブロック図である。 図9は、マネージャおよびプローブのパケットロス復旧処理を説明する図である。 図10は、実施例1に係るマネージャの処理動作を示すフローチャートである。 図11は、実施例1に係るプローブの処理動作を示すフローチャートである。 図12は、実施例2に係るマネージャの処理手順を説明するためのフローチャートである。 図13は、実施例3に係るマネージャの処理手順を説明するためのフローチャートである。 図14は、パケットロス復旧処理を実行するコンピュータを示す図である。 図15は、従来のネットワーク構成を示す図である。 図16は、パケットロスが発生した場合における従来のデータ再送処理を説明する図である。 図17は、ネットワーク内のプローブ設置例を示す図である。 図18は、パケットロスが発生した場合における従来の再送要求処理を説明する図である。
以下に添付図面を参照して、この発明に係る管理装置、通信システムおよびパケット通信方法の実施例を詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
以下の実施例では、実施例1に係る通信システムの構成、実施例1に係るマネージャの構成、実施例1に係るプローブの構成、実施例1に係るマネージャの処理および実施例1に係るプローブの処理の流れを順に説明し、最後に実施例1による効果を説明する。
[通信システムの構成]
最初に、図1を用いて、実施例1に係る通信システム100の構成を説明する。通信システム100は、マネージャ10、複数のプローブ20A〜20H、送信先ホスト40、送信元ホスト50、および、複数のルータ60A〜60Fを有する。
マネージャ10は、ネットワーク全体の状況を管理するためのサーバ装置である。マネージャ10は、各プローブ20A〜20H、各ルータ60A〜60Fと保守リンク70で相互接続されている。また、マネージャ10は、各プローブ20A〜20Hがキャプチャしたパケットの統計情報を保守リンク70を介して定期的に受信する。また、マネージャ10は、ルータ60A〜60FがOSPF(Open Shortest Path First)等のプロトコルで収集した経路情報を保守リンク70を介して定期的に受信する。このように、マネージャ10は、ネットワーク全体の情報を把握することで、ネットワーク内のトラフィック統計やホスト間の経路情報をGUI(Graphical User Interface)を通してユーザ側へディスプレイ表示している。
各プローブ20A〜20Hは、送信先ホスト40と送信元ホスト50との間で通信されるパケットをキャプチャし、キャプチャしたパケットを受信バッファ内に一定期間蓄積する。そして、各プローブ20A〜20Hは、パケット内部のIP(Internet Protocol)やTCP(Transmission Control Protocol)のヘッダ情報を解析し、解析結果を統計情報としてマネージャ10へ保守リンク70を介して定期的に送信する。
各ルータ60A〜60Fは、送信先ホスト40と送信元ホスト50との間で送受信されるネットワーク上のパケットを転送する。また、各ルータ60A〜60Fは、OSPF等のプロトコルで収集した経路情報を保守リンク70を介してマネージャ10へ定期的に送信する。
ここで、図2を用いて、マネージャ10および各プローブ20のハードウェア構成について説明する。図2は、マネージャおよびプローブのハードウェア構成を示す図である。図2に示すように、マネージャ10は、CPU110、メモリ120、ディスク130、データベース131を有する。CPU110は、ディスク130からデータを読み出してメモリ120に格納し、メモリ120に格納されたデータに基づいて処理を実行する。ディスク130は、各種処理に必要なデータおよびプログラムを格納している。データベース131は、後述するパケットの統計情報やパケットの経路情報などのデータを記憶する。
また、プローブ20は、CPU210、メモリ220、ディスク230を有する。CPU210は、ディスク230からデータを読み出してメモリ220に格納し、メモリ220に格納されたデータに基づいて処理を実行する。ディスク230は、キャプチャしたパケットの統計情報などのデータを格納している。また、プローブ20は、TAP(Test Access Point)30と接続され、TAP30が検出したデータ用リンク80上のパケットを受信する。なお、ここでデータ用リンク80とは、送信先ホスト40と送信元ホスト50との間に設置された各ルータ60A〜60F間のパケット通信用のリンクのことをいう。
[マネージャの構成]
次に、図3を用いて、図1に示したマネージャ10の構成を説明する。図3は、実施例1に係るマネージャの構成を示すブロック図である。図3に示すように、このマネージャ10は、通信制御I/F(インターフェース)11、制御部12、記憶部13を有し、保守リンク70を介してプローブ20およびルータ60と接続される。以下にこれらの各部の処理を説明する。
通信制御I/F11は、接続されるプローブ20およびルータ60との間でやり取りする各種情報に関する通信を制御する。例えば、通信制御I/F11は、TCPコネクションにおけるパケットの統計情報をプローブ20から受信する。具体例を挙げて説明すると、通信制御I/F11は、パケットの統計情報として、送信元ポート番号、送信先ホスト名、送信先ホストIPアドレス、送信先ポート番号などをプローブ20から受信する。また、通信制御I/F11は、経路プロトコルの経路情報(例えば、OSPF経路情報等)をルータ60から定期的に受信する。
記憶部13は、制御部12による各種処理に必要なデータおよびプログラムを格納している。また、記憶部13は、統計情報記憶部13aおよび経路情報記憶部13bを有する。なお、記憶部13は、RAM(Random Access Memory)、ROM(Read Only Memory)、フラッシュメモリ(flash memory)などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置であればよい。
統計情報記憶13aは、プローブ20から送信されたパケットの統計情報を記憶する。例えば、統計情報記憶13aは、TCPコネクションにおける統計情報を記憶する。ここで、図4の例を用いて、TCPコネクションにおける統計情報の例について説明する。図4は、TCPコネクション確立時における統計情報の一例を示す図である。図4に示すように、統計情報記憶13aは、統計情報として、送信元ホスト名、送信元ホストIPアドレス、送信元ポート番号、送信先ホスト名、送信先ホストIPアドレス、送信先ポート番号を記憶する。また、統計情報記憶13aは、統計情報として、TCPコネクション上の送信パケット数、TCPコネクション上の送信バイト数を記憶する。
経路情報記憶部13bは、ルータ60から受信された、コネクションごとのパケットの通信経路に関する情報を記憶する。例えば、経路情報記憶部13bは、経路情報として、図5に例示するようなコネクション管理テーブルを記憶する。図5は、経路情報の一例を示す図である。図5に示すように、経路情報記憶部13bは、コネクション管理テーブルとして、送信先と送信元のホストを特定する「ホスト情報」と、送信先と送信元のポート番号を示す「ポート情報」と、送信元から送信先までのホップ数を示す「Hop情報」とを記憶する。図5の例では、送信元ホストαと送信先ホストβの間には、送信元ポート番号500、送信先ポート番号80のコネクションが張られており、その通信に使われる経路上にはA−C−D−E−G−Hの順でプローブ20が設置されていることを示している。
制御部12は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行している。また、制御部12は、管理部12a、受信部12b、収集部12c、送信部12dを有する。
管理部12aは、パケットの経路に関する情報である経路情報およびプローブがキャプチャしたパケットの解析結果である統計情報を管理する。例えば、管理部12aは、TCPコネクションにおける統計情報をプローブ20から定期的に受信し、統計情報記憶部13aに格納する。
また、例えば、管理部12aは、ネットワーク内の各ルータ60間で送受信している経路プロトコルの経路情報(例えば、OSPF経路情報等)をルータ60から定期的に受信し、経路情報記憶部13bに格納している。このように、管理部12aは、ルータから定期的に来て経路に関する情報を受信することで、各ルータ60のリンク接続関係や、ルータ60間の優先経路をリアルタイムに管理している。
ここで、図6の例を用いて管理部12aによる通信経路の管理について説明する。図6は、送信元ホストと送信先ホストとの間で行われる通信経路の一例を示す図である。図6の例では、送信先ホスト40と送信元ホスト50とを接続するルータ60間に着目し、送信先ホスト40と送信元ホスト50との最適経路が太線で示されている。図6に示すように、マネージャ10は、各ルータ60A〜60FからOSPF経路情報を受信し、OSPF経路情報から送信先ホスト40と送信元ホスト50との最適経路であることを把握している。図6の例では、送信元ホスト50、ルータ60A、ルータ60B、ルータ60F、ルータ60C、ルータ60D、送信先ホスト40の順に送信される経路が最適経路であることを示している。
また、管理部12aは、プローブ20がどのリンク上に設置されているかについて、ネットワーク保守者によって事前に設定を受け付けており、Hop情報として経路情報記憶部13bに格納している。例えば、図6に示すように、送信元ホスト50と送信先ホスト40との間の最適経路上には、プローブ20A、20B、20I、20J、20D、20Eが順に設置されている。このような場合には、管理部12aは、送信元ホスト50と送信先ホスト40との最適経路との間において、各プローブ20A、20B、20I、20J、20D、20Eが設置されていることを経路情報記憶部13bにHop情報として格納する。なお、管理部12aは、統計情報記憶13aに記憶された統計情報に含まれるホスト名およびポート番号を読み出して、コネクション管理テーブル内のホスト情報およびポート情報を設定している。
受信部12bは、プローブ20から保守リンク70を介してパケットの損失が発生した旨の通知である障害情報を受信する。例えば、受信部12bは、TCPコネクションを特定するための情報と損失したパケットのシーケンス番号とが含まれた障害情報を受信する。ここで、図7を用いて、障害情報の例について説明する。図7は、パケットロス発生時における障害情報の一例を示す図である。図7に示すように、受信部12bは、障害情報として、送信元ホスト名、送信元ホストIPアドレス、送信元ポート番号、送信先ホスト名、送信先ホストIPアドレス、送信先ポート番号、欠落シーケンス番号などを受信する。
収集部12cは、プローブ20からパケットの損失の通知を受信した場合に、パケットの通信経路上で、当該プローブ20よりも送信元ホスト50の側に位置する他のプローブ20から損失に係るパケットを収集する。例えば、収集部12cは、受信部12bが障害情報を受信した場合には、経路情報記憶部13bに記憶されたコネクション管理テーブルを検索し、損失したパケットが属するTCPコネクションを特定する。
そして、収集部12cは、コネクション管理テーブル内のHop情報より、該当するTCPコネクション上の経路上に存在するプローブ20群を特定する。そして、収集部12cは、経路上のプローブ20群を前段(ロス検出プローブよりも送信元ホスト側)と後段(ロス検出プローブよりも送信先ホスト側)に分類する。例えば、図5の例で説明すると、経路上のプローブDがロスを検出してマネージャへ通知した場合には、前段プローブ群は「A−C」、後段プローブ群は「E−G−H」となる。なお、プローブの前段と後段の分類方法については、これまで述べたOSPFの経路から判断する方法以外でも構わない。例えば、パケット内のIPヘッダに含まれるTTL(Transistor Transistor Logic)情報を比較してプローブの前後関係を抽出するやり方等も考えられる。
その後、収集部12cは、前段プローブ群のうちの一つの前段プローブ20に対して損失したパケットに関する情報を通知して探索を依頼する。ここで、収集部12cは、前段プローブとして、送信元ホスト50に最も近い最前段のプローブ20に送ってもよいし、パケットの損失を通知したプローブに最も近い前段のプローブに送ってもよい。そして、収集部12cは、パケットの探索に失敗した場合には、送信元ホスト50により近い次候補の前段プローブ20に対して損失したパケットの探索を依頼する。なお、収集部12cは、前段プローブ20に対して損失したパケットの探索依頼の通知として、前述した障害情報(図7参照)を前段のプローブ20に転送してもよい。
送信部12dは、収集部12cによって収集したパケットを、通信経路上で、損失を検出したプローブ20よりも送信先ホスト40の側に位置する他のプローブ20に送信する。例えば、送信部12dは、収集部12cで収集したパケットとともに、パケットを送信先ホスト40へ再送する要求を、送信先ホスト40に最も近いプローブ20に保守リンク70を介して送信する。このように、マネージャ10は、保守用リンク70を介して、損失したパケットを送信先ホスト40に対して送信するので、パケットの損失が発生したデータ用リンク80を回避することができ、確実かつ迅速にロスパケットを再送することができる。
[プローブの構成]
次に、図8を用いて、図1に示したプローブ20の構成を説明する。図8は、実施例1に係るプローブの構成を示すブロック図である。図8に示すように、このプローブ20は、マネージャ通信制御I/F21、TAP(Test Access Point)通信制御I/F22、受信バッファ23、制御部24を有し、マネージャ10およびTAP30と接続される。以下にこれらの各部の処理を説明する。
マネージャ通信制御I/F21は、接続されるマネージャ10との間でやり取りする各種情報に関する通信を制御する。例えば、マネージャ通信制御I/F21は、TCPコネクションにおけるパケットの統計情報をマネージャ10に定期的に送信する。また、マネージャ通信制御I/F21は、パケットの損失が発生した場合には、パケットの損失が発生した旨の通知をマネージャ10に送信する。また、マネージャ通信制御I/F21は、損失したパケットの探索の要求をマネージャ10から受信する。
TAP通信制御I/F22は、接続されるTAP30との間でやり取りする各種情報に関する通信を制御する。例えば、TAP通信制御I/F22は、データ用リンク上を流れるパケットをTAP30から受信する。
受信バッファ23は、キャプチャされたパケットを記憶する。受信バッファ23に記憶されたパケットは、後述する検出部24aによって読み出されて解析され、また、後述する再送部24cによって損失したパケットが存在するか検索される。
制御部24は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するまた、制御部24は、検出部24a、通知部24b、再送部24c、および転送部24dを有する。
検出部24aは、パケットをデータ用リンク80から取り込み、パケットの損失を検出する。例えば、検出部24aは、TCPヘッダのシーケンス番号の整合性をチェックして、シーケンス番号に抜けがあるか判定する。この結果、検出部24aは、シーケンス番号に抜けがあると判定した場合には、パケットの損失が発生したことを検出する。
通知部24bは、検出部によってパケットの損失を検出した場合には、保守リンク70を介してパケットの損失が発生した旨をマネージャ10に通知する。例えば、通知部24bは、前述した検出部24aによってパケットのシーケンス番号に抜けがあると判定された場合には、損失したパケットのシーケンス番号などを含む障害情報(前述した図7参照)をマネージャ10に送信する。
再送部24cは、マネージャ10から損失したパケットの情報とともに、損失したパケットの探索依頼を受信し、受信バッファ23に保持されたパケットのなかから、損失したパケット情報に含まれるシーケンス番号と一致するパケットが存在するか検索を行う。この結果、再送部24cは、損失したパケットの情報に含まれるシーケンス番号と一致するパケットが存在する場合には、パケットデータ全体をマネージャ10に送信する。
転送部24dは、マネージャ10からパケットの再送要求を受信した場合には、データ用リンク80を介して送信先ホスト40にパケットを転送する。例えば、転送部24dは、マネージャ10から損失したパケットとともにパケットの再送依頼を受信した場合には、データ用リンク80を介して送信先ホスト40にパケットを転送する。これにより、損失したパケットが送信先ホスト40へ到達し、損失したパケットが復旧することができる。なお、パケットの再送信を行う範囲は、後段プローブから送信先ホストまでの区間に限定されることから、再送信要求がネットワーク帯域に与える影響を低く抑えることができる。
ここで、図9を用いて、マネージャ10とプローブ20のパケットロス復旧処理について説明する。図9は、マネージャおよびプローブのパケットロス復旧処理を説明する図である。なお、図9の例では、パケットの損失を検出したプローブをプローブ20A、パケットの損失を検出したプローブよりも前段側のプローブをプローブ20B、パケットの損失を検出したプローブよりも後段側のプローブをプローブ20Cとする。
図9に示すように、プローブ20Aは、データ用リンク80を流れるパケットをキャプチャし(ステップS1)、受信バッファ23に格納する(ステップS2)。そして、プローブ20Aは、受信バッファ23に格納されたパケットの解析を行い(ステップS3)、解析した結果をパケットの統計情報としてマネージャ10へ保守リンク70を介して定期的に送信する(ステップS4)。また、プローブ20Aは、解析を行った結果、シーケンス番号に抜けがあると判定した場合には、パケットの損失が発生した旨の通知である障害情報をマネージャ10へ保守リンク70を介して送信する(ステップS5)。
そして、マネージャ10は、保守リンク70を介してプローブ20Aから障害情報を受信し(ステップS6)、前段プローブ群のうちの一つの前段プローブ20に対して損失したパケットに関する情報を通知して探索を依頼し、損失したパケットを収集する(ステップS7)。探索を依頼された前段側プローブ20Bは、受信バッファ23から損失したパケットを探索し、損失したパケットを保守リンク70を介してマネージャ10へ送信する(ステップS8)。
そして、マネージャ10は、収集したパケットとともに、送信先ホスト40へのパケット再送要求を、後段側に位置するプローブ20Cへ保守リンク70を介して送信する(ステップS9)。その後、プローブ20Cは、パケット再送要求を受信すると(ステップS10)、送信先ホスト40へパケットを再送する(ステップS11)。
[マネージャによる処理]
次に、図10を用いて、実施例1に係るマネージャ10による処理を説明する。図10は、実施例1に係るマネージャの処理動作を示すフローチャートである。
図10に示すように、マネージャ10は、プローブからパケットの損失を示す障害情報を受信すると(ステップS101肯定)、経路情報記憶部13bのコネクション管理テーブルを検索し(ステップS102)、損失したパケットが属するTCPコネクションを特定する。この検索の結果、マネージャ10は、コネクション管理テーブル内に欠落パケットが属するTCPコネクションがあるか判定し(ステップS103)、コネクション管理テーブル内に損失したパケットが属するTCPコネクションがないと判定した場合には(ステップS103否定)、処理を終了する。
また、マネージャ10は、コネクション管理テーブル内に損失したパケットが属するTCPコネクションがあると判定した場合には(ステップS103肯定)、Hop情報から前段プローブ群を抽出する(ステップS104)。ここで、マネージャ10は、Hop情報に前段プローブ群があるか判定し(ステップS105)、Hop情報に前段プローブ群がない場合には(ステップS105否定)、処理を終了する。また、マネージャ10は、Hop情報に前段プローブ群がある場合には(ステップS105肯定)、前段プローブへパケットの探索要求を送信し(ステップS106)、プローブからのパケット探索応答を待つ(ステップS107)。
その後、マネージャ10は、前段プローブからのパケット探索応答を受信したか判定し(ステップS108)、前段プローブからのパケット探索応答を受信していない場合には(ステップS108否定)、受信するまで待つ。また、マネージャ10は、前段プローブからのパケット探索応答を受信した場合には(ステップS108肯定)、応答結果がパケットの探索成功であるか判定する(ステップS109)。この結果、マネージャ10は、応答結果がパケットの探索成功である場合には(ステップS109肯定)、Hop情報から後段プローブ群を抽出し(ステップS110)、ロスパケットのデータを後段プローブへ送信し(ステップS111)、処理を終了する。
また、マネージャ10は、応答結果がパケットの探索成功でない場合には(ステップS109否定)、前段プローブから次候補を選択する(ステップS112)。例えば、マネージャ10は、送信元ホスト側に近い前段プローブを選択する。そして、マネージャ10は、次候補の前段プローブがHop情報にあるか判定し(ステップS113)、次候補の前段プローブがある場合には(ステップS113肯定)、前段プローブへ損失パケットの探索要求を送信し(ステップS114)、ステップS107に戻る。また、マネージャ10は、次候補の前段プローブがない場合には(ステップS113否定)、処理を終了する。
[プローブによる処理]
次に、図11を用いて、実施例1に係るプローブ20による処理を説明する。図11は、実施例1に係るプローブの処理動作を示すフローチャートである。
図11に示すように、プローブ20は、受信バッファ23からパケットデータを読込むと(ステップS201)、パケットのヘッダ情報を収集する(ステップS202)。例えば、プローブ20は、ヘッダ情報からIPアドレス、ポート番号、パケットのシーケンス番号などを収集する。
そして、プローブ20は、パケットのシーケンス番号の妥当性をチェックし、シーケンス番号の妥当性チェックがOKであるか判定する(ステップS203)。例えば、プローブ20は、パケットのシーケンス番号に抜けがないか判定する。この結果、プローブ20は、パケットのシーケンス番号の妥当性チェックがOKでない場合には(ステップS203否定)、ロス発生と判断したパケット情報をマネージャ10へ送信する(ステップS204)。また、プローブ20は、パケットのシーケンス番号の妥当性チェックがOKである場合には(ステップS203肯定)、ステップS205に進む。
そして、プローブ20は、ヘッダ情報を解析して統計情報へ変換し(ステップS205)、統計情報の送信周期に達したか判定する(ステップS206)。この結果、プローブ20は、統計情報の送信周期に達した場合には(ステップS206肯定)、一定周期内の統計情報をマネージャ10へ送信し(ステップS207)、S201に戻る。また、プローブ20は、統計情報の送信周期に達していない場合には(ステップS206否定)、S201に戻る。
[実施例1の効果]
上述してきたように、プローブ20は、パケットをデータ用リンク80から取り込み、パケットの損失を検出し、パケットの損失を検出した場合には、保守リンク70を介してパケットの損失が発生した旨をマネージャ10に通知する。そして、マネージャ10は、プローブ20から保守リンク70を介してパケットの損失が発生した旨の通知を受信した場合に、該プローブ20よりも送信元ホスト50の側に位置する他のプローブ20から保守リンク70を介して損失に係るパケットを収集する。そして、マネージャ10は、収集したパケットを、損失を検出したプローブ20よりも送信先ホスト40の側に位置する他のプローブ20に保守リンク70を介して送信することで、データ用リンク80を介して送信先ホスト40にパケットを転送させる。その後、プローブ20は、マネージャ10からパケットを受信した場合には、データ用リンク80を介して送信先ホスト40にパケットを転送する。このため、確実性の高い前段側プローブからパケットを探索し、保守用リンク70を介して損失したパケットを送信先ホスト40に対して送信できる。この結果、パケットの損失が発生したデータ用リンク80を回避してロスパケットを送信することができ、確実かつ迅速にロスパケットを再送することが可能である。
ところで、上記の実施例1では、単一のプローブからパケットの損失が発生した旨の通知を受信する場合を説明したが、これに限定されるものではない。例えば、同一コネクションの経路上に設置された複数の検出装置から同一のパケットについて損失の通知をそれぞれ受信した場合も考えられる。このような場合には、最初に受信した損失の通知にのみ応じて、損失に係るパケットを収集するようにしてもよい。
そこで、以下の実施例2では、同一コネクションの経路上に設置された複数の検出装置から同一のパケットについて損失の通知をそれぞれ受信した際に、最初に受信した損失の通知にのみ応じて、損失に係るパケットを収集する場合について図12を用いて説明する。図12は、実施例2に係るマネージャの処理手順を説明するためのフローチャートである。なお、実施例2に係るマネージャの構成は、図3で説明した実施例1のマネージャと同様であるため、図を省略する。
ここで、図12を用いて、実施例2に係るマネージャの処理手順を説明する。図12に示すように、実施例2に係るマネージャは、実施例1と同様に、プローブ20からパケットのロスを示すロス情報を受信すると(ステップS201肯定)、経路情報記憶部13bのコネクション管理テーブルを検索する(ステップS202)。そして、マネージャは、経路情報内に欠落パケットが属するTCPコネクションがあるか判定し(ステップS203)、TCPコネクションがあると判定した場合には(ステップS203肯定)、Hop情報から前段プローブ群を抽出する(ステップS204)。
そして、実施例2に係るマネージャは、既に前段プローブからロス情報を受信済みであるか判定する(ステップS205)。この結果、マネージャは、既に前段プローブからロス情報を受信済みであると判定した場合には(ステップS205肯定)、受信したロス情報を破棄する(ステップS206)。また、マネージャは、既に前段プローブからロス情報を受信済みでないと判定した場合には(ステップS205否定)、Hop情報に前段プローブ群があるか判定する(ステップS207)。
この結果、プローブは、Hop情報に前段プローブ群がない場合には(ステップS207否定)、処理を終了する。また、マネージャは、Hop情報に前段プローブ群がある場合には(ステップS207肯定)、前段プローブへパケットの探索要求を送信し(ステップS208)、プローブからのパケット探索応答を待つ(ステップS209)。
その後、マネージャは、前段プローブからのパケット探索応答を受信したか判定し(ステップS210)、前段プローブからのパケット探索応答を受信していない場合には(ステップS210否定)、受信するまで待つ。また、マネージャは、前段プローブからのパケット探索応答を受信した場合には(ステップS210肯定)、応答結果がパケットの探索成功であるか判定する(ステップS211)。この結果、マネージャは、応答結果がパケットの探索成功である場合には(ステップS211肯定)、Hop情報から後段プローブ群を抽出し(ステップS212)、ロスパケットのデータを後段プローブへ送信する(ステップS213)。
また、マネージャは、応答結果がパケットの探索成功でない場合には(ステップS211否定)、前段プローブから次候補を選択する(ステップS214)。そして、マネージャは、次候補の前段プローブがHop情報にあるか判定し(ステップS215)、次候補の前段プローブがある場合には(ステップS215肯定)、前段プローブへ損失パケットの探索要求を送信する(ステップS216)。また、マネージャ10は、次候補の前段プローブがない場合には(ステップS215否定)、処理を終了する。
つまり、TCPコネクション経路上の1箇所でパケットロスが発生した場合に、それ以降に設置された各プローブでは、パケットロスの発生を検出し、それぞれがマネージャに対して障害情報を送信して来る可能性がある。この場合には、マネージャは、最初に障害情報を通知して来たプローブが、コネクション管理テーブルのHop情報より導き出されたプローブ群のどこに位置するかを認識する。その後、マネージャに対して他のプローブから障害情報が通知された場合に、最初に通知したプローブよりも後段のプローブが通知して来た場合は情報の重複となるため、マネージャは障害通知を破棄する。
また、マネージャは、まだプローブからの探索結果応答が来ていない時に、最初に通知したプローブよりも前段のプローブから障害情報の通知が来た場合は、損失したパケットの探索を要求するプローブの対象からは通知済み前段プローブを外す。例えば、図5の例を用いて説明すると、TCPコネクション上の経路においてプローブDの障害通知がマネージャへ最初に到達し前段プローブへ探索要求を送信済みの場合には、それ以降にプローブGやHから障害情報の通知が来ても破棄し、前段プローブへの探索要求は行わない。
このように、上記の実施例2では、マネージャ10は、同一コネクションの経路上に設置された複数のプローブ20から同一のパケットについて損失の通知をそれぞれ受信した場合には、最初に受信した損失の通知にのみ応じて、損失に係るパケットを収集する。このため、プローブ20とマネージャ10間で送受信される情報量が必要最低限なものに削減されるため、送受信に必要な処理時間の短縮、および保守リンク70上を流れるデータ量を削減することが可能である。
ところで、コネクションの利用者に優先度が設定されていれば、高優先度の契約を結んでいる場合にのみ、損失に係るパケットを収集して送信先装置にパケットを転送させるようにしてもよい。
そこで、以下の実施例3では、パケットの損失が発生した旨の通知を受信した場合に、当該パケットが属するコネクションの利用者の優先度を判定し、優先度が所定の閾値より高い場合にのみ、損失に係るパケットを収集する処理について説明する。図13は、実施例3に係るマネージャの処理手順を説明するためのフローチャートである。
図13に示すように、実施例3に係るマネージャは、実施例1と同様に、プローブ20からパケットのロスを示すロス情報を受信すると(ステップS301肯定)、経路情報記憶部13bのコネクション管理テーブルを検索する(ステップS302)。そして、マネージャは、経路情報内に欠落パケットが属するTCPコネクションがあるか判定し(ステップS303)、TCPコネクションがあると判定した場合には(ステップS303肯定)、Hop情報から前段プローブ群を抽出する(ステップS304)。
そして、実施例3に係るマネージャは、コネクションの使用者の優先度が所定の閾値よりも高いか判定する(ステップS305)。この結果、マネージャは、コネクションの使用者の優先度が所定の閾値よりも高くないと判定した場合には(ステップS305否定)、受信したロス情報を破棄する(ステップS306)。また、マネージャは、コネクションの使用者の優先度が所定の閾値よりも高いと判定した場合には(ステップS305肯定)、Hop情報に前段プローブ群があるか判定する(ステップS307)。
この結果、プローブは、Hop情報に前段プローブ群がない場合には(ステップS307否定)、処理を終了する。また、マネージャは、Hop情報に前段プローブ群がある場合には(ステップS307肯定)、前段プローブへパケットの探索要求を送信し(ステップS308)、プローブからのパケット探索応答を待つ(ステップS309)。
その後、マネージャは、前段プローブからのパケット探索応答を受信したか判定し(ステップS310)、前段プローブからのパケット探索応答を受信していない場合には(ステップS310否定)、受信するまで待つ。また、マネージャは、前段プローブからのパケット探索応答を受信した場合には(ステップS310肯定)、応答結果がパケットの探索成功であるか判定する(ステップS311)。この結果、マネージャは、応答結果がパケットの探索成功である場合には(ステップS311肯定)、Hop情報から後段プローブ群を抽出し(ステップS312)、ロスパケットのデータを後段プローブへ送信する(ステップS313)。
また、マネージャは、応答結果がパケットの探索成功でない場合には(ステップS311否定)、前段プローブから次候補を選択する(ステップS314)。そして、マネージャは、次候補の前段プローブがHop情報にあるか判定し(ステップS315)、次候補の前段プローブがある場合には(ステップS315肯定)、前段プローブへ損失パケットの探索要求を送信する(ステップS316)。また、マネージャ10は、次候補の前段プローブがない場合には(ステップS315否定)、処理を終了する。
つまり、マネージャは、ネットワーク上に存在する各ホストのうち、一部のホストがネットワーク事業者と高優先度の契約を結んでいる場合にのみ、前段プローブへパケットの探索を要求するものとする。また、マネージャは、優先度が低い場合には、前段プローブへパケットの探索を要求せずに、パケットの損失があった旨を利用者に通知する。
このように実施例3によれば、マネージャ10は、パケットの損失が発生した旨の通知を受信した場合に、パケットが属するコネクションの利用者の優先度を判定し、優先度が所定の閾値より高い場合にのみ、損失に係るパケットを収集する。このため、ネットワークの利用者毎にサービスの差別化を行うことが可能である。
さて、これまで本実施例について説明したが、本実施例は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例4として本発明に含まれる他の実施例を説明する。
(1)システム構成等
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、管理部12aおよび受信部12bを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
(2)プログラム
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図14を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図14は、パケットロス復旧処理を実行するコンピュータを示す図である。
同図に示すように、マネージャとしてのコンピュータ600は、HDD610、RAM620、ROM630およびCPU640をバス650で接続して構成される。
そして、ROM630には、上記の実施例と同様の機能を発揮するパケット通信プログラム、つまり、図14に示すように、管理プログラム631、受信プログラム632、収集プログラム633および送信プログラム634が予め記憶されている。なお、プログラム631〜634については、図3に示したマネージャ10の各構成要素と同様、適宜統合または分散してもよい。
そして、CPU640が、これらのプログラム631〜634をROM630から読み出して実行することで、図14に示すように、各プログラム631〜634は、管理プロセス641、受信プロセス642、収集プロセス643および送信プロセス644として機能するようになる。
また、HDD610には、図14に示すように、統計情報管理テーブル611および経路情報管理テーブル612が設けられる。そして、CPU640は、統計情報管理テーブル611および経路情報管理テーブル612に対してデータを登録するとともに、統計情報管理テーブル611および経路情報管理テーブル612からデータを読み出してRAM620に格納し、RAM620に格納されたデータに基づいて処理を実行する。
10 マネージャ
11 通信制御I/F
12 制御部
12a 管理部
12b 受信部
12c 収集部
12d 送信部
13 記憶部
13a 統計情報記憶部
13b 経路情報記憶部
20、20A〜20K プローブ
21 マネージャ通信制御I/F
22 TAP通信制御I/F
23 受信バッファ
24 制御部
24a 検出部
24b 通知部
24c 再送部
24d 転送部
30 TAP
40 送信先ホスト
50 送信元ホスト
60、60A〜60F ルータ
70 保守リンク
80 データ用リンク

Claims (6)

  1. パケットの送信元装置と送信先装置との通信経路上に配置された、前記パケットの損失を検出する検出装置と通信可能で、
    前記検出装置から前記パケットの損失の通知を受信した場合に、該パケットの通信経路上で、当該検出装置よりも前記送信元装置の側に位置する他の検出装置から前記損失に係るパケットを収集する収集部と、
    前記収集部によって収集したパケットを、前記通信経路上で、前記損失を検出した検出装置よりも前記送信先装置の側に位置する他の検出装置に送信する送信部と
    を有することを特徴とする管理装置。
  2. 前記収集部は、前記送信元装置と前記送信先装置との間における接続関係であるコネクションが同一であって、該同一コネクションの経路上に設置された複数の検出装置から同一のパケットについて損失の通知をそれぞれ受信した場合には、最初に受信した損失の通知にのみ応じて、前記損失に係るパケットを収集することを特徴とする請求項1に記載の管理装置。
  3. 前記収集部は、前記パケットの損失が発生した旨の通知を受信した場合に、当該パケットが属するコネクションの利用者の優先度を判定し、当該優先度が所定の閾値より高い場合にのみ、前記損失に係るパケットを収集することを特徴とする請求項1または2に記載の管理装置。
  4. 前記検出装置がパケットの通信を行う送信元装置および送信先装置が接続される第一のネットワーク上に配置され、前記管理装置が前記検出装置と第二のネットワークを介して接続されることを特徴とする請求項1〜3のいずれか一つに記載の管理装置。
  5. 複数の検出装置と管理装置とを含む通信システムであって、
    前記複数の検出装置は、
    パケットを取り込み、該パケットの損失を検出する検出部と、
    前記検出部によって前記パケットの損失を検出した場合には、前記パケットの損失が発生した旨を前記管理装置に通知する通知部と、
    前記管理装置からパケットを受信した場合には、前記送信先装置に前記パケットを転送する転送部と、
    を有し、
    前記管理装置は、
    前記検出装置から前記パケットの損失の通知を受信した場合に、該パケットの通信経路上で、当該検出装置よりも前記送信元装置の側に位置する他の検出装置から前記損失に係るパケットを収集する収集部と、
    前記収集部によって収集したパケットを、前記通信経路上で、前記損失を検出した検出装置よりも前記送信先装置の側に位置する他の検出装置に送信する送信部と
    を有することを特徴とする通信システム。
  6. 複数の検出装置および管理装置による通信方法であって、
    前記検出装置は、
    パケットを取り込み、該パケットの損失を検出し、
    前記パケットの損失を検出した場合には、前記パケットの損失が発生した旨を前記管理装置に通知し、
    前記管理装置からパケットを受信した場合には、前記送信先装置に前記パケットを転送し、
    前記管理装置は、
    前記検出装置から前記パケットの損失の通知を受信した場合に、該パケットの通信経路上で、当該検出装置よりも前記送信元装置の側に位置する他の検出装置から前記損失に係るパケットを収集し、
    収集したパケットを、前記通信経路上で、前記損失を検出した検出装置よりも前記送信先装置の側に位置する他の検出装置に送信する
    ことを特徴とするパケット通信方法。
JP2011061778A 2011-03-18 2011-03-18 管理装置、通信システムおよびパケット通信方法 Expired - Fee Related JP5621674B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011061778A JP5621674B2 (ja) 2011-03-18 2011-03-18 管理装置、通信システムおよびパケット通信方法
US13/418,709 US20120236705A1 (en) 2011-03-18 2012-03-13 Management apparatus, communication system, and communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011061778A JP5621674B2 (ja) 2011-03-18 2011-03-18 管理装置、通信システムおよびパケット通信方法

Publications (2)

Publication Number Publication Date
JP2012199719A JP2012199719A (ja) 2012-10-18
JP5621674B2 true JP5621674B2 (ja) 2014-11-12

Family

ID=46828367

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011061778A Expired - Fee Related JP5621674B2 (ja) 2011-03-18 2011-03-18 管理装置、通信システムおよびパケット通信方法

Country Status (2)

Country Link
US (1) US20120236705A1 (ja)
JP (1) JP5621674B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8948020B2 (en) 2012-12-11 2015-02-03 International Business Machines Corporation Detecting and isolating dropped or out-of-order packets in communication networks
EP3413514B1 (en) * 2016-03-02 2020-02-26 Huawei Technologies Co., Ltd. Method and device for managing network apparatus
ES2963210T3 (es) * 2017-06-16 2024-03-25 Beijing Xiaomi Mobile Software Co Ltd Método y dispositivo de realimentación HARQ, equipo de usuario y estación base
US10491719B2 (en) * 2017-07-24 2019-11-26 Cisco Technology, Inc. Insertion of management packet into a wired deterministic path
CN113364681B (zh) * 2021-06-02 2022-05-27 中国工商银行股份有限公司 网络路径确定方法、装置、电子设备、介质和程序产品
CN117240612B (zh) * 2023-11-10 2024-01-26 杭州海康威视数字技术股份有限公司 基于多模过滤的失陷物联网设备安全检测方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002190825A (ja) * 2000-12-21 2002-07-05 Fujitsu Ltd トラフィックエンジニアリング方法及びそれを用いたノード装置
US7013342B2 (en) * 2001-12-10 2006-03-14 Packeteer, Inc. Dynamic tunnel probing in a communications network
KR100705566B1 (ko) * 2004-12-23 2007-04-10 삼성전자주식회사 Mpls 네트워크의 성능 관리 장치 및 방법
US7701856B2 (en) * 2006-12-14 2010-04-20 Oracle America, Inc. Method and system for bi-level congestion control for multipath transport
JP2009089197A (ja) * 2007-10-01 2009-04-23 Fujitsu Ltd 中継装置
EP2413546B1 (en) * 2009-03-23 2014-07-30 Nec Corporation Path setting server, path setting method, and path setting program

Also Published As

Publication number Publication date
JP2012199719A (ja) 2012-10-18
US20120236705A1 (en) 2012-09-20

Similar Documents

Publication Publication Date Title
JP5621674B2 (ja) 管理装置、通信システムおよびパケット通信方法
CN113315682B (zh) 生成信息传输性能警告的方法、系统和装置
JP4759389B2 (ja) パケット通信装置
KR101746629B1 (ko) 통신 장치 및 통신 방법
CN104506482B (zh) 网络攻击检测方法及装置
US7636305B1 (en) Method and apparatus for monitoring network traffic
JP6015509B2 (ja) パケット解析プログラム、パケット解析方法、パケット解析装置、およびパケット解析システム
US8005012B1 (en) Traffic analysis of data flows
JP5884892B2 (ja) ネットワークシステム、コントローラ、及び負荷分散方法
US9137305B2 (en) Information processing device, computer-readable recording medium, and control method
JP2007215182A (ja) ネットワークにおける輻輳発生予告システム及びその方法
JPWO2011102312A1 (ja) パケット転送装置、通信システム、処理規則の更新方法およびプログラム
JP2014168283A (ja) 通信システム、ネットワーク監視装置、及びネットワーク監視方法
KR100865722B1 (ko) 유비쿼터스 센서 네트워크에서 이씨엔 비트를 이용한혼잡제어 방법
JP4532253B2 (ja) フレーム転送装置及びフレームのループ抑止方法
US20170064489A1 (en) Network system, method for determining communication quality, and analysis apparatus
JP5440200B2 (ja) 中継装置及び帯域制御方法
US7535916B2 (en) Method for sharing a transport connection across a multi-processor platform with limited inter-processor communications
US7385930B2 (en) Packet discard point probing method and device
CN109672701B (zh) 一种差异化tcp链接管理方法及设备
JP5024027B2 (ja) 通信品質監視装置、通信品質監視システム、通信品質監視方法及びそのプログラム
JP5925287B1 (ja) 情報処理装置、方法およびプログラム
CN110337115B (zh) 一种基于tcp协议判断微信支付感知的方法
US20110216673A1 (en) Topology detection method and topology detection apparatus
JP2001067291A (ja) ネットワーク監視方式

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140716

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140908

R150 Certificate of patent or registration of utility model

Ref document number: 5621674

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees