JP2004328221A - 通信制御方式、及び、通信機器、及び、記録媒体 - Google Patents
通信制御方式、及び、通信機器、及び、記録媒体 Download PDFInfo
- Publication number
- JP2004328221A JP2004328221A JP2003118483A JP2003118483A JP2004328221A JP 2004328221 A JP2004328221 A JP 2004328221A JP 2003118483 A JP2003118483 A JP 2003118483A JP 2003118483 A JP2003118483 A JP 2003118483A JP 2004328221 A JP2004328221 A JP 2004328221A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- buffer
- node
- information
- arp request
- 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.)
- Withdrawn
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】バスリセットによって物理アドレスが変化するシリアルバス上でのインターネットプロトコル（ＩＰ通信）において、分割転送中ＩＰパケットのバスリセット時の破棄を回避することによって、オーバヘッドを削減することが可能な通信制御方式と通信機器、および、記録媒体を提供する。
【解決手段】ＩＰ通信に伴うＡＲＰ動作において、自分宛のＡＲＰリクエストを受信したノードは、前記ＡＲＰリクエスト中のユニークＩＤとＩＰパケット再構築バッファ管理情報の送信元ユニークＩＤの値を比較するステップと、前記比較で一致したバッファが存在し、該当バッファの管理情報の送信元ノードＩＤがクリアされていた場合に、前記ＡＲＰリクエストの送信元ノードＩＤをセットするステップを有する。同時に、バスリセット発生時は、上記管理情報の全ての送信元ノードＩＤをクリアするステップを有することを特徴とする。
【選択図】 図１
【解決手段】ＩＰ通信に伴うＡＲＰ動作において、自分宛のＡＲＰリクエストを受信したノードは、前記ＡＲＰリクエスト中のユニークＩＤとＩＰパケット再構築バッファ管理情報の送信元ユニークＩＤの値を比較するステップと、前記比較で一致したバッファが存在し、該当バッファの管理情報の送信元ノードＩＤがクリアされていた場合に、前記ＡＲＰリクエストの送信元ノードＩＤをセットするステップを有する。同時に、バスリセット発生時は、上記管理情報の全ての送信元ノードＩＤをクリアするステップを有することを特徴とする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、例えばＩＥＥＥ１３９４インターフェースに接続された複数の通信機器間で、インターネットプロトコル通信を行うネットワーク上での通信制御方式、及び、通信装置、及び、記録媒体に関するものである。
【０００２】
【従来の技術】
従来、一般家庭やオフィスなどでは、イーサネット（Ｒ）や、ファストイーサネット（Ｒ）（Ｒ）などのインターフェースを用いて、コンピュータや、プリンタ等の通信機能を有した電子機器（以下、ノード）を相互接続し、ネットワークを構築していた。また、これらのネットワークで用いられるプロトコルは、インターネットプロトコル（以下、ＩＰ）が標準となっている。
【０００３】
これに対し、近年、ＩＥＥＥ１３９４ネットワークに接続するためのＩＥＥＥ１３９４インターフェース（以下、ＩＥＥＥ１３９４）を備えるコンピュータやプリンタ等の通信機能を有した電子機器が増加している。ＩＥＥＥ１３９４では、１００Ｍｂｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓの転送速度で通信が可能であり、さらに、８００Ｍｂｐｓや１６００Ｍｂｐｓの転送速度を利用することが可能になる見込みである。このため、今後はイーサネット（Ｒ）（Ｒ）等の従来のインターフェースに代わり、ＩＥＥＥ１３９４で通信機器を相互接続する機会がますます増加すると考えられる。
【０００４】
この様なＩＥＥＥ１３９４により通信機器を相互接続したネットワークでは、当然のことながら、ＩＰによる通信（ＩＰ ｏｖｅｒ １３９４）が求められる。そこで、インターネットの技術標準を定めるＩＥＴＦはＩＰ ｏｖｅｒ １３９４をＲＦＣ２７３４として標準化し、ＩＥＥＥ１３９４で相互接続された通信機器間でのＩＰ通信を可能にした。
【０００５】
ネットワーク上でパケット（例えば、イーサネット（Ｒ）上のイーサネット（Ｒ）フレーム）を送信する際には、送信先のインターフェースの物理的なアドレス（例えば、イーサネット（Ｒ）上ではＭＡＣアドレス）により、送信先を特定する。ＩＥＥＥ１３９４では、アシンクロナスパケットの送信先は、ノードＩＤで特定される。
【０００６】
ＩＰパケットを送信する際には、送信先ＩＰアドレスに対する物理的なアドレスを求める必要があり、求める手順はＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）として、インターフェース毎に定められている。ＩＥＥＥ１３９４に対しては１３９４ＡＲＰとして、ＲＦＣ２７３４中で標準化されている。
【０００７】
物理的なアドレスが不変であれば、ＡＲＰは理論的に各送信先ＩＰアドレスに対して１回だけ行えば良く、好ましい。しかし、ＩＥＥＥ１３９４の様なバスリセットの前後でノードＩＤが変化するインターフェースでは、バスリセット毎にＡＲＰ情報を消去し、必要に応じて再びＡＲＰを行わなければならない。
【０００８】
ＩＥＥＥ１３９４においては、接続されているノードの電源のオン／オフ、バスへのノードの接続、バスからのノードの取り外し等のタイミングでバスリセットは発生する。
【０００９】
また、上位レイヤであるＩＰスタックが送信を要求するＩＰパケットのサイズが、使用するインターフェースの最大パケットサイズより大きい場合は、ＩＰパケットを複数に分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）し、インターフェースに適したパケットに変換（ｅｎｃａｐｓｕｌａｔｉｏｎ）して送信しなければならない。分割されたパケットのカプセル化ヘッダ（ｅｎｃａｐｓｕｌａｔｉｏｎ ｈｅａｄｅｒ）には、再構築（ｒｅａｓｓｅｍｂｌｙ）するための情報として、ＩＰパケットのサイズ（ｄａｔａｇｒａｍ＿ｓｉｚｅ）、分割された部分の位置（ｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔ）、ＩＰパケットを判別するためのラベル値（ｄａｔａ ｇｒａｍ ｌａｂｅｌ，ｄｇｌ）の各フィールドが定義される。受信側のノードは、ｄｇｌの値と送信元ノードの物理アドレス同士が等しいパケットを同一のＩＰパケットから作られたものと判断し、ｄａｔａｇｒａｍ＿ｓｉｚｅとｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔを用いて順次ＩＰパケットを再構築していく。
【００１０】
ところが、上記のＩＥＥＥ１３９４の様にバスリセット時に物理的なアドレスが変化するインターフェースにおいては、ＩＰパケットを分割して作られたパケットをすべて送信し終わらない時点で、バスリセットが発生すると、受信側では送信元の物理的なアドレスが変化した可能性があるため、同一のＩＰパケットから作られたかどうかの判断が不可能となる。
【００１１】
よって、ＲＦＣ２７３４ではバスリセット時に、送信側ノードと受信側ノードともに完全に処理できていないＩＰパケット（一部しか送受信できていないＩＰパケット）がある場合には、破棄しなければならないとしている。
【００１２】
特開平１０−９３５９７号公報では、ノード毎にユニークで不変なノードユニークＩＤ（あるいは、グローバルユニークＩＤ）を用いて通信相手を特定する通信制御法を提案した。しかし、この通信制御法では、ＲＦＣ２７３４と異なるＡＲＰパケットを利用しており、また、バスリセット時のオーバヘッド軽減が可能なのはノードユニークＩＤを使用したコマンドセットのみであることから、ＲＦＣ２７３４に従ったＩＰ ｏｖｅｒ １３９４に適用することはできない。
【００１３】
同様に、特開平１１−２７５１１７号公報および特開平１１−３１７７５１号公報で提案されている手法においても、ノードユニークＩＤを用いる方法であり、ノードＩＤとノードユニークＩＤの対応表を提供する装置と、その装置にアクセスする手段を提案している。これらの手法も上記の通信制御法と同様に、ＲＦＣ２７３４に基づくＩＰ ｏｖｅｒ １３９４に適用できない。
【００１４】
【発明が解決しようとしている課題】
このように、バスリセット時に物理的なアドレスが変化するインターフェースでのＩＰ通信では、
（１）バスリセット時にノードＩＤが変化する点、
（２）分割されたＩＰパケットを送受信している途中でバスリセットが発生した場合に、送信受信ノードの両者で不完全なパケットは破棄しなければならない点、
の２点でバスリセット時にオーバヘッドが生じる。
【００１５】
特開平１０−９３５９７号公報、特開平１１−２７５１１７号公報、特開平１１−３１７７５１号公報のいずれも上記（１）の問題点を解決するために提案されたものであるが、上記のようにＲＦＣ２７３４との互換性が乏しく、また、上記（２）の問題点については考慮されていない。
【００１６】
本発明はこの様な問題点に鑑みてなされたものであって、上記（２）のオーバヘッドの解消を実現する通信制御方式、および、ノード、および、記録媒体を提供することを目的とする。
【００１７】
【課題を解決するための手段】
上記目的を達成するため、本出願に係る第一の発明は、ノードの物理アドレスで送信相手を特定するインターフェース上でのＩＰ通信に伴うＡＲＰ動作において、ＡＲＰリクエストパケットを受信したノードが、前記ＡＲＰリクエストパケットのターゲットとするＩＰアドレスが自分のＩＰアドレスであった場合に、受信したＩＰパケットを再構築するためのバッファの管理情報を全て調査するステップと、前記調査した管理情報の送信元ユニークＩＤ情報と、前記ＡＲＰリクエストパケット中のユニークＩＤとが一致するバッファが存在し、なおかつ、前記バッファの送信元ノードＩＤ情報がクリアされている場合において、前記ＡＲＰリクエストパケットの送信元ノードＩＤを、前記バッファの送信元ノードＩＤ情報の項にセットするステップを有することを特徴とする。また、同時に、バスリセットが発生した場合に、上記再構築バッファの管理情報のうち、送信元ノードＩＤ情報のみを消去するステップを有することを特徴とする。
【００１８】
さらに、好ましくは、上記ノードにパケットを送信するノードは、ＩＰパケットを複数に分割して送信する際に、バスリセットが発生し、分割して作られたパケットをすべて送信していない場合において、未送信のパケットを破棄しないステップと、ＡＲＰリクエストにより再び物理アドレスとオフセットアドレスを求めるステップと、前記ＡＲＰリクエストで求めた物理アドレスとオフセットアドレスを用いて、前記未送信のパケットを送信するステップを有することを特徴とする。
【００１９】
上記構成において、バスリセットに伴いノードＩＤが変化した場合においても、バスリセット後のＡＲＰリクエストパケットに含まれているユニークＩＤの値を元に、再構築用バッファの管理情報を適切に更新し、再び送信元ノードＩＤとｄｇｌという組み合わせで、同じＩＰパケットから分割されたかどうかを特定することができる。
【００２０】
また、上記手段に加え、受信側のノードは、ＩＰパケットを再構築するためのバッファが確保されてからの経過時間などをカウントするステップと、前記時間などが一定値を越えた場合は当該バッファの内容を破棄するステップと、前記バッファを解放するステップを有することを特徴とする。
【００２１】
上記構成において、このノードにＩＰパケットを送信するノードが、本発明の手段を備えず、バスリセット時に未送信のＩＰパケットの断片を破棄する場合においても、受信側では、適当な時間が経過しても再構築が完了しないバッファは破棄するため、不完全なＩＰパケットが再構築用バッファを占拠することがない。このため、上記手段を具備するノードは、具備しない従来のノードとの通信も円滑に行うことができる。
【００２２】
【発明の実施の形態】
以下に、添付図面を参照して本発明の好ましい実施の形態について詳細に説明する。実施例においては、ＩＥＥＥ１３９４を対象とするインターフェースとする。
【００２３】
（第一の実施例）
図２に、本発明を適用する通信ネットワークシステムの構成を示す。この通信ネットワークシステムでは、ＩＥＥＥ１３９４インターフェースを備える通信機器（ノード）１〜４が、ＩＥＥＥ１３９４ネットワーク５を介して接続されている。ＩＥＥＥ１３９４ネットワーク５の接続形態や、接続されているノードの数は、図示している例に制限されず、ＩＥＥＥ１３９４規格に従う。なお、ノードＩＤとはＩＥＥＥ１３９４の物理アドレスである。
【００２４】
図３に、ＩＥＥＥ１３９４上でのＩＰ通信（ＩＰ ｏｖｅｒ １３９４）で用いるＡＲＰリクエストパケットと、ＡＲＰレスポンスパケットに含まれるＡＲＰ情報のフォーマットである。このフォーマットはＲＦＣ２７３４で規定されている。
【００２５】
６のｏｐｃｏｄｅフィールドには、このフォーマットを含むパケットが、ＡＲＰリクエストなのか、ＡＲＰレスポンスなのかを判別する値がセットされる。１の場合がリクエストで、２の場合がレスポンスである。
【００２６】
７のｓｅｎｄｅｒ＿ｕｎｉｑｕｅ＿ＩＤには、送信元ノードのグローバルユニークＩＤ（ＧＵＩＤ）がセットされる。ＩＥＥＥ１３９４の場合は６４ビットの値が用いられる。
【００２７】
８と９のｓｅｎｄｅｒ＿ｕｎｉｃａｓｔ＿ＦＩＦＯフィールドには、ＩＰ ｏｖｅｒ １３９４に利用されるオフセットアドレスの、上位１６ビットと下位３２ビットがセットされる。ＩＥＥＥ１３９４ネットワークでは一つの６４ビットのアドレス空間を共有しており、６４ビットのアドレスの上位１６ビットが、ノードの物理アドレスに割り当てられるため、各ノード内では４８ビットアドレス空間を持つことになる。後述のｓｅｎｄｅｒ＿ＩＰ＿ａｄｄｒｅｓｓフィールドのノードにＩＰデータを含むパケットを送信するときは、オフセットアドレスとしてこのアドレスを指定しなければならない。
【００２８】
１０のｓｅｎｄｅｒ＿ＩＰ＿ａｄｄｒｅｓｓフィールドには、送信元のノードのＩＰアドレスがセットされる。
【００２９】
１１のｔａｒｇｅｔ＿ＩＰ＿ａｄｄｒｅｓｓフィールドには、送信元のノードが、ノードＩＤを知りたいＩＰアドレスがセットされる。ｏｐｃｏｄｅフィールドが１（リクエスト）のとき、このフィールドと同じＩＰアドレスを持つノードは、ＡＲＰレスポンスを返信しなければならない。
【００３０】
図４に、ＡＲＰテーブルの例を示す。ＡＲＰテーブルはＩＰデータを含むパケットを送信する場合に参照され、また、ＡＲＰパケットを受信したときに更新される。この例では、ＩＰアドレスｅ．ｆ．ｇ．ｈに送信する場合には、ノードＩＤ ０ｘＡＡＡＡに対して、オフセット０ｘＡＢＣＤＥＦＧＨＩＪＫＬとして、パケットを送信しなければならない。また、ＩＰアドレスｉ．ｊ．ｋ．ｌに対して送信する場合には、ＡＲＰテーブルからノードＩＤが求められないため、ＡＲＰリクエスト送信する必要がある。また、バスリセットが発生した場合は、ノードＩＤが変化し、ＩＰアドレスとノードＩＤの対応が無効になる可能性があるため、ＡＲＰテーブルはクリアしなければならない。
【００３１】
図５に、再構築用のバッファを管理するための情報の例を示す。ＩＰ ｏｖｅｒ １３９４では、ＩＰパケットを分割した後、ＩＥＥＥ１３９４パケットとして送信する場合がある。そのため、受信側ではＩＰパケットの断片を一時的に格納し、ＩＰパケットを再構築するためのバッファが必要である。再構築用バッファの情報は、バッファを識別するための情報と、バッファのステータスをあらわす情報に別けることができる。ＲＦＣ２７３４によれば、バッファを識別する情報として、送信元ノードＩＤとｄｇｌの値を用いる。さらに、本発明では送信元のＧＵＩＤを識別情報に追加する。また、バッファのステータスを表す情報は、バッファのメモリアドレスや、バッファ長、格納済のデータ長などから成る。バッファにデータが格納されると必要に応じて更新される。
【００３２】
図１では、本発明の手法が効果的に機能する場合の動作の流れを示している。この図では、説明を簡略化するために、説明に直接関係のない動作は省略している。詳細な説明はフローチャートを用いて後述する。
【００３３】
まず、ＩＰパケットを送信する際には、ＩＰパケットの送信先ＩＰアドレスに対応したノードＩＤを知る必要がある（１２，１３）。そこで、送信先ＩＰアドレスをターゲットＩＰアドレスとしたＡＲＰリクエストパケットをブロードキャストする（１４）。なお、送信側のＡＲＰテーブルに、既に必要な情報が存在すればこれらの動作は省略できる。
【００３４】
上記のＡＲＰリクエストパケットを受信したノードのうち、ターゲットＩＰアドレスと自分のＩＰアドレスが一致したノードは、自ノードの情報をセットしたＡＲＰレスポンスパケットを返信する（１５，１６，１８）。１７の動作に関しては３３の動作の時に説明する。
【００３５】
ＩＰパケットを送信するノードは、上記のＡＲＰレスポンスパケットを受信することにより、ノードＩＤ、使用するオフセットアドレス、使用可能な最大転送速度などの情報を手にいれることができ、それらの情報でＡＲＰテーブルを更新する（１９）。ＩＰパケットを送信するに際し、ＩＰパケットのサイズが、最大転送速度から導き出される最大パケットサイズより大きい場合は、ＩＰパケットを分割する必要がある（２０）。また、送信する際にはＩＰパケットを送信できる形（ＩＥＥＥ１３９４のパケット形式）に変換して送信する（２１，２２）。なお、ＩＰパケットを分割して送信する場合には、再構築するために必要な情報を付け加えた後、変換する。
【００３６】
分割されたＩＰパケットを受信した場合は、再構築するためのバッファを用意する。この際、既に同じＩＰパケットから分割されたパケットを受信していないかどうか、再構築バッファ管理情報の送信元ノードＩＤとｄｇｌを利用して調査する（２３）。前記調査の結果、未受信の場合は適切なサイズのバッファを用意し、受信したＩＰパケットの断片を保存する（２４）。また、新たに用意したバッファの情報を再構築バッファ管理情報に追加する。
【００３７】
さて、ここでバスリセットが発生したとする。すると、割り込みが生じ、両ノードともＡＲＰテーブルをクリアする（２５，２６）。従来の手法では、ここで、再構築用バッファと未送信のＩＰパケットの断片を破棄しなければならない。すなわち、図中のＩＰ−１とＩＰ−２は破棄され、ＩＰパケットは消えてしまうことになる。しかし、本発明の手法では、再構築用バッファ管理情報の送信元ノードＩＤの部分だけを消去する（２７）。
【００３８】
本発明による送信側のノードはバスリセット後も送信を継続する（２８）。ところが、バスリセット時の割り込み処理によりＡＲＰテーブルがクリアされているので、送信先ＩＰアドレスに対するノードＩＤが分からないので、再びＡＲＰリクエストパケットをブロードキャストする（２９，３０）。
【００３９】
ＡＲＰリクエストパケットを受信したノードは１６の場合と同様に必要に応じてＡＲＰレスポンスパケットを返信する（３１，３２）。さらに、再構築用バッファの管理情報を調査し、受信したＡＲＰリクエストパケット中の送信元ＧＵＩＤの値と一致するバッファの送信元ノードＩＤ項を、ＡＲＰリクエストパケットの送信元ノードＩＤに更新する（３３）。この操作により、更新されたバッファは有効な送信元ノードＩＤとｄｇｌの組み合わせを持つことになる。
【００４０】
ＡＲＰレスポンスパケットを受信するとＡＲＰテーブルを更新し（３５）、ＩＰパケットの残りの部分（ＩＰ−２）を送信できる形に変換して送信する（３７，３８）。このとき、２１の操作の時に使用したｄｇｌと同じ値を用いなければならない。
【００４１】
上記のパケットを受信すると、再構築用バッファ管理情報を検索し、送信元ノードＩＤとｄｇｌが一致するバッファを求める。すると、バスリセットにより送信元ノードＩＤが変化したとしても、２７および３３の操作で有効な値に更新されているので、２４の動作で確保したバッファを選択することができる（３８）。バッファが選択できれば適切な位置に受信したＩＰパケットの断片を保存し（３９）、バッファの状態などから全ての断片を受信したと判断した場合はＩＰパケットを復元する（４０）。
【００４２】
次に、フローチャートを用い、送信側ノードと受信側ノードの動作の例を、図面を参照しながら説明する。図７は送信側ノードの動作を、図８は受信側ノードの動作を、図９はバスリセット時の割り込み処理を表すフローチャートである。
【００４３】
図６は送信側ノードの動作を表したフローチャートである。ＩＰ以外のプロトコルのパケットは、それぞれのプロトコルに従い適当に処理される。
【００４４】
ステップＦ１−１では、上位レイヤであるＩＰスタックから、ＩＰパケットの送信が要求され、ＩＰパケットを受け取る。
【００４５】
ステップＦ１−２では、上記ステップで受け取ったＩＰパケットの送信先ＩＰアドレスから、送信するノードＩＤを決定する（後述）。なお、この時に使用する転送速度と、それに伴い制限される最大パケットサイズも決定する。
【００４６】
ステップＦ１−３では、上記ステップで求めた最大パケットサイズと、送信するＩＰパケットのサイズから、ＩＰパケットの分割の必要性を判断する。分割が不要であればステップＦ１−４へ、必要であればステップＦ１−６へ進む。
【００４７】
ステップＦ１−４では、ＩＰパケットをＲＦＣ２７３４のフォーマットに従いＩＥＥＥ１３９４パケットに変換する。
【００４８】
ステップＦ１−５では、上記ステップで変換したパケットを送信し、終了する。
【００４９】
一方、ステップＦ１−３で分割が必要と判断された場合は、ステップＦ１−６でＩＰパケットをＩＥＥＥ１３９４で送信できるサイズに分割する。
【００５０】
ステップＦ１−７は、ステップＦ１−２と同様である。
【００５１】
ステップＦ１−８では、ステップＦ１−６で作られたＩＰパケットの断片の中で、未送信の断片の一つを選択し、ＲＦＣ２７３４に従いＩＥＥＥ１３９４パケットに変換する。
【００５２】
ステップＦ１−９では、上記ステップで変換したパケットを送信する。
【００５３】
ステップＦ１−１０では、ステップＦ１−６で作られたＩＰパケットの断片がすべて送信されたことを確認する。未送信の断片が存在する場合は、ステップＦ１−７に戻り、未送信の断片がなくなるまで繰り返す。
【００５４】
ステップＦ１−１１では、ＲＦＣ２７３４で定められている通りに、分割されたＩＰパケットを送信する際に利用する値であるｄｇｌを増加させ、終了する。ただし、６５５３５を越えた場合は０に戻す。
【００５５】
次に、ステップＦ１−２、および、ステップＦ１−７の動作の詳細を、図７中のＡＲＰのフローチャートを参照しながら説明する。
【００５６】
ステップＦ１−１２では、ノードが保持している１３９４ＡＲＰテーブルを検索し、送信先ＩＰアドレスを持つノードのノードＩＤと、ＩＰパケットを含むＩＥＥＥ１３９４パケットを送信する際のオフセットアドレス、転送速度、最大パケットサイズなどの情報の取得を試みる。
【００５７】
ステップＦ１−１３では、上記検索の正否を判定する。検索に成功し、該当する情報を得られた場合は終了するが、検索に失敗した場合はステップＦ１−１４に進む。
【００５８】
ステップＦ１−１４では、ＲＦＣ２７３４に従い、送信先ＩＰアドレスをターゲットとした１３９４ＡＲＰリクエストパケットをブロードキャストし、１３９４ＡＲＰレスポンスパケットが返ってくるのを待つ。
【００５９】
ステップＦ１−１５では、上記ステップの１３９４リクエストパケットに対するレスポンスパケットを受信する。
【００６０】
ステップＦ１−１６では、上記ステップで受信したパケットから得られた情報を用いて、１３９４ＡＲＰテーブルを更新して、終了する。
【００６１】
図７は、受信側ノードの動作を表したフローチャートである。ＩＰ以外のプロトコルのパケット（ＩＰ用以外のオフセットアドレスに送信されたパケット、１３９４ＡＲＰ以外のアシンクロナスストリームパケットなど）は、それぞれのプロトコルによって適当に処理をされる。また、１３９４ＡＲＰレスポンスを受信した場合の動作は、図７のＡＲＰのフローチャート中にすでに示している。
【００６２】
ステップＦ２−１では、ＩＰパケットを含むパケット、１３９４ＡＲＰリクエストパケットを受信する。
【００６３】
ステップＦ２−２では、上記ステップで受信したパケットの種別を判定する。受信したパケットが１３９４ＡＲＰリクエストの場合はステップＦ２−３へ、ＩＰパケットを含んでいる場合はステップＦ２−９へ進む。
【００６４】
ステップＦ２−３では、ステップＦ２−１で受信した１３９４ＡＲＰリクエストパケットのターゲットＩＰアドレスが自分のＩＰアドレスと一致するかどうかを判定する。一致しない場合は自分宛でないので無視して終了するが、一致する場合はステップＦ２−４に進む。
【００６５】
ステップＦ２−４では、再構築用バッファ管理情報の全てのＧＵＩＤを調査する。
【００６６】
ステップＦ２−５では、前記調査の結果、ステップＦ２−１で受信した１３９４ＡＲＰリクエストパケットの送信元ＧＵＩＤと一致するバッファが存在するかどうかを判定する。存在した場合はステップＦ２−６へ、存在しない場合はＦ２−８へ進む。
【００６７】
ステップＦ２０６では、上記ステップで一致したバッファの送信元ノードＩＤの項を調べ、値がセットされていなければステップＦ２−７へ進み、有効な値がセットされていればステップＦ２−８へ進む。
【００６８】
ステップＦ２−７では、上記ステップの送信先ノードＩＤの項にステップＦ２−１で受信した１３９４ＡＲＰパケットの送信元ノードＩＤの値をセットする。
【００６９】
ステップＦ２−８では、適切な値をセットした１３９４ＡＲＰレスポンスパケットを返信する。
【００７０】
一方、ステップＦ２−９では、ステップＦ２−１で受信したパケットに含まれているＩＰパケットの状態を判定する。ＩＰパケットが分割されていない場合は、ステップ２−１７へ進み、分割されている場合はステップＦ２−１０へ進む。
【００７１】
ステップＦ２−１０では、ステップＦ２−１で受信したパケットの送信元ノードＩＤとｄｇｌの値から、図６で示した様な再構築用バッファ管理情報を参照し、再構築バッファが割り当てられているか否かを調べる。
【００７２】
ステップＦ２−１１では、上記ステップの検索で対応する再構築用バッファを得られればステップＦ２−１３へ進み、対応する再構築用バッファが無い場合にはステップＦ２−１２へ進む。
【００７３】
ステップＦ２−１２では、ステップＦ２−１で受信したパケットに含まれるＩＰパケットを再構築する為のバッファを用意する。バッファのサイズはパケット中の情報から決定することができる。その後、再構築用バッファ割り当て情報にオフセットアドレス、ｄｇｌ、再構築用バッファのアドレスなどの情報を付け加える。
【００７４】
ステップＦ２−１３では、上記ステップで用意したバッファ、あるいは、ステップＦ２−１０で検索したバッファの適当な位置にＦ２−１で受信したパケット中のＩＰパケットの部分をコピーする。位置は、パケット中のｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔフィールドの値から決定することができる。
【００７５】
ステップＦ２−１４では、上記ステップでＩＰパケットを完全に再構築できたかどうかを判断する。再構築が完了していない場合は終了するが、完了しＩＰパケットを得ることができた場合はステップＦ２−１５へ進む。
【００７６】
ステップＦ２−１５では、上記ステップで再構築したパケットを上位レイヤであるＩＰスタックに渡す。
【００７７】
ステップＦ２−１６では、再構築が完了したパケットが利用していたバッファを解放し、再構築用バッファ割り当て情報から解放したバッファの情報を削除して終了する。
【００７８】
また、ステップＦ２−１７では、ＩＰパケットは分割されていないので、ステップＦ２−１で受信したパケットからＩＰパケットを取り出す。
【００７９】
ステップＦ２−１８は、ステップＦ２−１２と同様に、ＩＰパケットを上位レイヤのＩＰスタックに渡して終了する。
【００８０】
図８は、バスリセットが発生したときの割り込み処理のフローチャートである。ここで示しているのは、ＩＰ関連の処理のみであり、他のプロトコルの割り込み処理は必要に応じて適当に実行される。
【００８１】
ステップＦ３−１では、１３９４ＡＲＰテーブルをクリアする。これは、バスリセットに伴って、ノードＩＤが変化した可能性があるためである。
【００８２】
ステップＦ３−２では、保持している再構築用バッファ管理情報のうち、全ての送信元ノードＩＤの値をクリアする。その他の値は維持する。
【００８３】
従来の手法では、ステップＦ３−１およびステップＦ３−２のほかに、再構築用バッファの破棄、送信待の分割されたＩＰパケットの破棄などの処理が必要であり、オーバヘッドが大きかったが、提案手法ではそのような処理を行う必要はない。
【００８４】
（第二の実施例）
図９に、本発明を適用する通信ネットワークシステムの構成を示す。全てのノードが本発明の通信制御方法を備えているわけなく、一部のノードは従来の手法（ＲＦＣ２７３４）にのみ対応している点で、図２とは異なっている。図２と同様に、接続形態、ノード数などは図示している例に制限されない。
【００８５】
図１０に、再構築用のバッファを管理するための情報の例を示す。図５に対し、バッファの保持時間を制御するためのフィールドが追加されている。各ノードはこのフィールドを参照して、設定した時間以上経過した場合には、バッファ内容を破棄し、バッファを解放するようにする。例えば、バッファを確保した時に、ある０でない値を書き込み、処理の適当な段階でこのフィールドの値を減少させていき、０になった時点で破棄するというようにする。
【００８６】
次に、フローチャートを用いノードの動作の例を説明する。送信の際の動作、および、バスリセット時の割り込み動作は第一の実施例の場合と同じで良い。
【００８７】
図１２は受信側ノードの動作を表したフローチャートである。図７と同様に、ＩＰ以外のプロトコルのパケット（ＩＰ用以外のオフセットアドレスに送信されたパケット、１３９４ＡＲＰ以外のアシンクロナスストリームパケットなど）は、それぞれのプロトコルによって適当に処理をされる。また、１３９４ＡＲＰレスポンスを受信した場合の動作は、図６のＡＲＰのフローチャート中にすでに示している。
【００８８】
ステップＦ４−１は、図７のフローチャート全体（ステップＦ２−１からステップＦ２−１８まで）である。図１１のフローチャートは、図７のフローチャートにステップＦ４−２からステップＦ４−４を付け加えた形になる。
【００８９】
ステップＦ４−２では、再構築用バッファ割り当て情報の全ての寿命フィールドを減少させる。これは、図１０の説明で述べた動作である。
【００９０】
ステップＦ４−３では、上記ステップの操作により、寿命フィールドが０になったバッファの有無を調査し、存在する場合はステップＦ４−４へ進み、存在しない場合は終了する。
【００９１】
ステップＦ４−４では、寿命フィールドが０になった全てのバッファの内容を破棄し、バッファを解放し、再構築用バッファ割り当て情報から削除し、終了する。
【００９２】
【発明の効果】
以上説明したように、本出願に係る第一の発明によれば、バスリセット時に物理的なアドレスが変化するインターフェースでのＩＰ通信において、分割されたＩＰパケットを送受信している途中でバスリセットが発生した場合においても、送信側、受信側の両ノードとも不完全なパケットを破棄する必要はなく、送信側がＡＲＰを行うだけで通信を継続することができ、オーバヘッドを縮小できるという効果がある。
【００９３】
また、バスリセット時に不完全なＩＰパケットを破棄するような従来の手法を用いるノードが、ネットワーク上に混在した場合においても、受信側のバッファの保持時間に制限をつけることによって、本発明の手段を備えるノードと従来手法のノードが円滑に通信することができる効果もある。
【図面の簡単な説明】
【図１】本発明の効果的な場合の動作を説明する図である。
【図２】本発明の通信制御方法と通信機器を用いた実施例の一つであるネットワークの構成図である。
【図３】ＲＦＣ２７３４で規定されたＡＲＰ情報のフォーマットである。
【図４】既知のＡＲＰ情報を保持するＡＲＰテーブルである。
【図５】再構築用に用いられるバッファの情報をあらわす表である。
【図６】送信時の動作を表すフローチャートである。
【図７】受信時の動作を表すフローチャートである。
【図８】バスリセット時の割り込み動作を表すフローチャートである。
【図９】本発明の通信制御方法と通信機器を用いた実施例の一つであるノードと従来手法のノードが混在するネットワークの構成図である。
【図１０】再構築用に用いられるバッファの情報をあらわす表である。
【図１１】受信時の動作を表すフローチャートである。
【符号の説明】
１〜４ 本発明の通信機器である。
５ ＩＥＥＥ１３９４によるネットワークである。
６ ＡＲＰパケットのリクエスト／レスポンスを区別するフィールドである。
７ 送信元のノードユニークＩＤである。
８，９ 送信元ノードがＩＰパケットを受け付けるオフセットアドレスである。
１０ 送信元のＩＰアドレスである。
１１ ノードＩＤを知りたいＩＰアドレスである。
１２ ＩＰパケットの送信要求の発生を表す。
１３，２９ ＡＲＰリクエストの発生を表す。
１４，３０ ＡＲＰリクエストを表す。
１５，３１ 受信したＡＲＰリクエストの受け入れを表す
１６，１９，３２，３５ ＡＲＰテーブルの更新を表す。
１７，３３ 再構築用バッファ管理情報のＡＲＰリクエストを用いた更新を表す。
１８，３４ ＡＲＰレスポンスを表す。
２０ ＩＰパケットのサイズが大きい場合の分割を表す。
２１，３６ ＩＥＥＥ１３９４パケットに変換する動作を表す。
２２，３７ ＩＰパケットを含んだパケットの転送を表す。
２３，３８ 再構築に使用するためのバッファが確保済みかどうかの調査を表す。
２４ 再構築に使用するバッファの確保と受信データの保存を表す。
３９ 受信データの保存を表す。
４０ ＩＰパケットの再構築の完了を表す。
４１，４４ 本発明の通信機器である
４２，４３ 従来の通信方法に従う通信機器である。
４５ ＩＥＥＥ１３９４によるネットワークである。
【発明の属する技術分野】
本発明は、例えばＩＥＥＥ１３９４インターフェースに接続された複数の通信機器間で、インターネットプロトコル通信を行うネットワーク上での通信制御方式、及び、通信装置、及び、記録媒体に関するものである。
【０００２】
【従来の技術】
従来、一般家庭やオフィスなどでは、イーサネット（Ｒ）や、ファストイーサネット（Ｒ）（Ｒ）などのインターフェースを用いて、コンピュータや、プリンタ等の通信機能を有した電子機器（以下、ノード）を相互接続し、ネットワークを構築していた。また、これらのネットワークで用いられるプロトコルは、インターネットプロトコル（以下、ＩＰ）が標準となっている。
【０００３】
これに対し、近年、ＩＥＥＥ１３９４ネットワークに接続するためのＩＥＥＥ１３９４インターフェース（以下、ＩＥＥＥ１３９４）を備えるコンピュータやプリンタ等の通信機能を有した電子機器が増加している。ＩＥＥＥ１３９４では、１００Ｍｂｐｓ、２００Ｍｂｐｓ、４００Ｍｂｐｓの転送速度で通信が可能であり、さらに、８００Ｍｂｐｓや１６００Ｍｂｐｓの転送速度を利用することが可能になる見込みである。このため、今後はイーサネット（Ｒ）（Ｒ）等の従来のインターフェースに代わり、ＩＥＥＥ１３９４で通信機器を相互接続する機会がますます増加すると考えられる。
【０００４】
この様なＩＥＥＥ１３９４により通信機器を相互接続したネットワークでは、当然のことながら、ＩＰによる通信（ＩＰ ｏｖｅｒ １３９４）が求められる。そこで、インターネットの技術標準を定めるＩＥＴＦはＩＰ ｏｖｅｒ １３９４をＲＦＣ２７３４として標準化し、ＩＥＥＥ１３９４で相互接続された通信機器間でのＩＰ通信を可能にした。
【０００５】
ネットワーク上でパケット（例えば、イーサネット（Ｒ）上のイーサネット（Ｒ）フレーム）を送信する際には、送信先のインターフェースの物理的なアドレス（例えば、イーサネット（Ｒ）上ではＭＡＣアドレス）により、送信先を特定する。ＩＥＥＥ１３９４では、アシンクロナスパケットの送信先は、ノードＩＤで特定される。
【０００６】
ＩＰパケットを送信する際には、送信先ＩＰアドレスに対する物理的なアドレスを求める必要があり、求める手順はＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）として、インターフェース毎に定められている。ＩＥＥＥ１３９４に対しては１３９４ＡＲＰとして、ＲＦＣ２７３４中で標準化されている。
【０００７】
物理的なアドレスが不変であれば、ＡＲＰは理論的に各送信先ＩＰアドレスに対して１回だけ行えば良く、好ましい。しかし、ＩＥＥＥ１３９４の様なバスリセットの前後でノードＩＤが変化するインターフェースでは、バスリセット毎にＡＲＰ情報を消去し、必要に応じて再びＡＲＰを行わなければならない。
【０００８】
ＩＥＥＥ１３９４においては、接続されているノードの電源のオン／オフ、バスへのノードの接続、バスからのノードの取り外し等のタイミングでバスリセットは発生する。
【０００９】
また、上位レイヤであるＩＰスタックが送信を要求するＩＰパケットのサイズが、使用するインターフェースの最大パケットサイズより大きい場合は、ＩＰパケットを複数に分割（ｆｒａｇｍｅｎｔａｔｉｏｎ）し、インターフェースに適したパケットに変換（ｅｎｃａｐｓｕｌａｔｉｏｎ）して送信しなければならない。分割されたパケットのカプセル化ヘッダ（ｅｎｃａｐｓｕｌａｔｉｏｎ ｈｅａｄｅｒ）には、再構築（ｒｅａｓｓｅｍｂｌｙ）するための情報として、ＩＰパケットのサイズ（ｄａｔａｇｒａｍ＿ｓｉｚｅ）、分割された部分の位置（ｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔ）、ＩＰパケットを判別するためのラベル値（ｄａｔａ ｇｒａｍ ｌａｂｅｌ，ｄｇｌ）の各フィールドが定義される。受信側のノードは、ｄｇｌの値と送信元ノードの物理アドレス同士が等しいパケットを同一のＩＰパケットから作られたものと判断し、ｄａｔａｇｒａｍ＿ｓｉｚｅとｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔを用いて順次ＩＰパケットを再構築していく。
【００１０】
ところが、上記のＩＥＥＥ１３９４の様にバスリセット時に物理的なアドレスが変化するインターフェースにおいては、ＩＰパケットを分割して作られたパケットをすべて送信し終わらない時点で、バスリセットが発生すると、受信側では送信元の物理的なアドレスが変化した可能性があるため、同一のＩＰパケットから作られたかどうかの判断が不可能となる。
【００１１】
よって、ＲＦＣ２７３４ではバスリセット時に、送信側ノードと受信側ノードともに完全に処理できていないＩＰパケット（一部しか送受信できていないＩＰパケット）がある場合には、破棄しなければならないとしている。
【００１２】
特開平１０−９３５９７号公報では、ノード毎にユニークで不変なノードユニークＩＤ（あるいは、グローバルユニークＩＤ）を用いて通信相手を特定する通信制御法を提案した。しかし、この通信制御法では、ＲＦＣ２７３４と異なるＡＲＰパケットを利用しており、また、バスリセット時のオーバヘッド軽減が可能なのはノードユニークＩＤを使用したコマンドセットのみであることから、ＲＦＣ２７３４に従ったＩＰ ｏｖｅｒ １３９４に適用することはできない。
【００１３】
同様に、特開平１１−２７５１１７号公報および特開平１１−３１７７５１号公報で提案されている手法においても、ノードユニークＩＤを用いる方法であり、ノードＩＤとノードユニークＩＤの対応表を提供する装置と、その装置にアクセスする手段を提案している。これらの手法も上記の通信制御法と同様に、ＲＦＣ２７３４に基づくＩＰ ｏｖｅｒ １３９４に適用できない。
【００１４】
【発明が解決しようとしている課題】
このように、バスリセット時に物理的なアドレスが変化するインターフェースでのＩＰ通信では、
（１）バスリセット時にノードＩＤが変化する点、
（２）分割されたＩＰパケットを送受信している途中でバスリセットが発生した場合に、送信受信ノードの両者で不完全なパケットは破棄しなければならない点、
の２点でバスリセット時にオーバヘッドが生じる。
【００１５】
特開平１０−９３５９７号公報、特開平１１−２７５１１７号公報、特開平１１−３１７７５１号公報のいずれも上記（１）の問題点を解決するために提案されたものであるが、上記のようにＲＦＣ２７３４との互換性が乏しく、また、上記（２）の問題点については考慮されていない。
【００１６】
本発明はこの様な問題点に鑑みてなされたものであって、上記（２）のオーバヘッドの解消を実現する通信制御方式、および、ノード、および、記録媒体を提供することを目的とする。
【００１７】
【課題を解決するための手段】
上記目的を達成するため、本出願に係る第一の発明は、ノードの物理アドレスで送信相手を特定するインターフェース上でのＩＰ通信に伴うＡＲＰ動作において、ＡＲＰリクエストパケットを受信したノードが、前記ＡＲＰリクエストパケットのターゲットとするＩＰアドレスが自分のＩＰアドレスであった場合に、受信したＩＰパケットを再構築するためのバッファの管理情報を全て調査するステップと、前記調査した管理情報の送信元ユニークＩＤ情報と、前記ＡＲＰリクエストパケット中のユニークＩＤとが一致するバッファが存在し、なおかつ、前記バッファの送信元ノードＩＤ情報がクリアされている場合において、前記ＡＲＰリクエストパケットの送信元ノードＩＤを、前記バッファの送信元ノードＩＤ情報の項にセットするステップを有することを特徴とする。また、同時に、バスリセットが発生した場合に、上記再構築バッファの管理情報のうち、送信元ノードＩＤ情報のみを消去するステップを有することを特徴とする。
【００１８】
さらに、好ましくは、上記ノードにパケットを送信するノードは、ＩＰパケットを複数に分割して送信する際に、バスリセットが発生し、分割して作られたパケットをすべて送信していない場合において、未送信のパケットを破棄しないステップと、ＡＲＰリクエストにより再び物理アドレスとオフセットアドレスを求めるステップと、前記ＡＲＰリクエストで求めた物理アドレスとオフセットアドレスを用いて、前記未送信のパケットを送信するステップを有することを特徴とする。
【００１９】
上記構成において、バスリセットに伴いノードＩＤが変化した場合においても、バスリセット後のＡＲＰリクエストパケットに含まれているユニークＩＤの値を元に、再構築用バッファの管理情報を適切に更新し、再び送信元ノードＩＤとｄｇｌという組み合わせで、同じＩＰパケットから分割されたかどうかを特定することができる。
【００２０】
また、上記手段に加え、受信側のノードは、ＩＰパケットを再構築するためのバッファが確保されてからの経過時間などをカウントするステップと、前記時間などが一定値を越えた場合は当該バッファの内容を破棄するステップと、前記バッファを解放するステップを有することを特徴とする。
【００２１】
上記構成において、このノードにＩＰパケットを送信するノードが、本発明の手段を備えず、バスリセット時に未送信のＩＰパケットの断片を破棄する場合においても、受信側では、適当な時間が経過しても再構築が完了しないバッファは破棄するため、不完全なＩＰパケットが再構築用バッファを占拠することがない。このため、上記手段を具備するノードは、具備しない従来のノードとの通信も円滑に行うことができる。
【００２２】
【発明の実施の形態】
以下に、添付図面を参照して本発明の好ましい実施の形態について詳細に説明する。実施例においては、ＩＥＥＥ１３９４を対象とするインターフェースとする。
【００２３】
（第一の実施例）
図２に、本発明を適用する通信ネットワークシステムの構成を示す。この通信ネットワークシステムでは、ＩＥＥＥ１３９４インターフェースを備える通信機器（ノード）１〜４が、ＩＥＥＥ１３９４ネットワーク５を介して接続されている。ＩＥＥＥ１３９４ネットワーク５の接続形態や、接続されているノードの数は、図示している例に制限されず、ＩＥＥＥ１３９４規格に従う。なお、ノードＩＤとはＩＥＥＥ１３９４の物理アドレスである。
【００２４】
図３に、ＩＥＥＥ１３９４上でのＩＰ通信（ＩＰ ｏｖｅｒ １３９４）で用いるＡＲＰリクエストパケットと、ＡＲＰレスポンスパケットに含まれるＡＲＰ情報のフォーマットである。このフォーマットはＲＦＣ２７３４で規定されている。
【００２５】
６のｏｐｃｏｄｅフィールドには、このフォーマットを含むパケットが、ＡＲＰリクエストなのか、ＡＲＰレスポンスなのかを判別する値がセットされる。１の場合がリクエストで、２の場合がレスポンスである。
【００２６】
７のｓｅｎｄｅｒ＿ｕｎｉｑｕｅ＿ＩＤには、送信元ノードのグローバルユニークＩＤ（ＧＵＩＤ）がセットされる。ＩＥＥＥ１３９４の場合は６４ビットの値が用いられる。
【００２７】
８と９のｓｅｎｄｅｒ＿ｕｎｉｃａｓｔ＿ＦＩＦＯフィールドには、ＩＰ ｏｖｅｒ １３９４に利用されるオフセットアドレスの、上位１６ビットと下位３２ビットがセットされる。ＩＥＥＥ１３９４ネットワークでは一つの６４ビットのアドレス空間を共有しており、６４ビットのアドレスの上位１６ビットが、ノードの物理アドレスに割り当てられるため、各ノード内では４８ビットアドレス空間を持つことになる。後述のｓｅｎｄｅｒ＿ＩＰ＿ａｄｄｒｅｓｓフィールドのノードにＩＰデータを含むパケットを送信するときは、オフセットアドレスとしてこのアドレスを指定しなければならない。
【００２８】
１０のｓｅｎｄｅｒ＿ＩＰ＿ａｄｄｒｅｓｓフィールドには、送信元のノードのＩＰアドレスがセットされる。
【００２９】
１１のｔａｒｇｅｔ＿ＩＰ＿ａｄｄｒｅｓｓフィールドには、送信元のノードが、ノードＩＤを知りたいＩＰアドレスがセットされる。ｏｐｃｏｄｅフィールドが１（リクエスト）のとき、このフィールドと同じＩＰアドレスを持つノードは、ＡＲＰレスポンスを返信しなければならない。
【００３０】
図４に、ＡＲＰテーブルの例を示す。ＡＲＰテーブルはＩＰデータを含むパケットを送信する場合に参照され、また、ＡＲＰパケットを受信したときに更新される。この例では、ＩＰアドレスｅ．ｆ．ｇ．ｈに送信する場合には、ノードＩＤ ０ｘＡＡＡＡに対して、オフセット０ｘＡＢＣＤＥＦＧＨＩＪＫＬとして、パケットを送信しなければならない。また、ＩＰアドレスｉ．ｊ．ｋ．ｌに対して送信する場合には、ＡＲＰテーブルからノードＩＤが求められないため、ＡＲＰリクエスト送信する必要がある。また、バスリセットが発生した場合は、ノードＩＤが変化し、ＩＰアドレスとノードＩＤの対応が無効になる可能性があるため、ＡＲＰテーブルはクリアしなければならない。
【００３１】
図５に、再構築用のバッファを管理するための情報の例を示す。ＩＰ ｏｖｅｒ １３９４では、ＩＰパケットを分割した後、ＩＥＥＥ１３９４パケットとして送信する場合がある。そのため、受信側ではＩＰパケットの断片を一時的に格納し、ＩＰパケットを再構築するためのバッファが必要である。再構築用バッファの情報は、バッファを識別するための情報と、バッファのステータスをあらわす情報に別けることができる。ＲＦＣ２７３４によれば、バッファを識別する情報として、送信元ノードＩＤとｄｇｌの値を用いる。さらに、本発明では送信元のＧＵＩＤを識別情報に追加する。また、バッファのステータスを表す情報は、バッファのメモリアドレスや、バッファ長、格納済のデータ長などから成る。バッファにデータが格納されると必要に応じて更新される。
【００３２】
図１では、本発明の手法が効果的に機能する場合の動作の流れを示している。この図では、説明を簡略化するために、説明に直接関係のない動作は省略している。詳細な説明はフローチャートを用いて後述する。
【００３３】
まず、ＩＰパケットを送信する際には、ＩＰパケットの送信先ＩＰアドレスに対応したノードＩＤを知る必要がある（１２，１３）。そこで、送信先ＩＰアドレスをターゲットＩＰアドレスとしたＡＲＰリクエストパケットをブロードキャストする（１４）。なお、送信側のＡＲＰテーブルに、既に必要な情報が存在すればこれらの動作は省略できる。
【００３４】
上記のＡＲＰリクエストパケットを受信したノードのうち、ターゲットＩＰアドレスと自分のＩＰアドレスが一致したノードは、自ノードの情報をセットしたＡＲＰレスポンスパケットを返信する（１５，１６，１８）。１７の動作に関しては３３の動作の時に説明する。
【００３５】
ＩＰパケットを送信するノードは、上記のＡＲＰレスポンスパケットを受信することにより、ノードＩＤ、使用するオフセットアドレス、使用可能な最大転送速度などの情報を手にいれることができ、それらの情報でＡＲＰテーブルを更新する（１９）。ＩＰパケットを送信するに際し、ＩＰパケットのサイズが、最大転送速度から導き出される最大パケットサイズより大きい場合は、ＩＰパケットを分割する必要がある（２０）。また、送信する際にはＩＰパケットを送信できる形（ＩＥＥＥ１３９４のパケット形式）に変換して送信する（２１，２２）。なお、ＩＰパケットを分割して送信する場合には、再構築するために必要な情報を付け加えた後、変換する。
【００３６】
分割されたＩＰパケットを受信した場合は、再構築するためのバッファを用意する。この際、既に同じＩＰパケットから分割されたパケットを受信していないかどうか、再構築バッファ管理情報の送信元ノードＩＤとｄｇｌを利用して調査する（２３）。前記調査の結果、未受信の場合は適切なサイズのバッファを用意し、受信したＩＰパケットの断片を保存する（２４）。また、新たに用意したバッファの情報を再構築バッファ管理情報に追加する。
【００３７】
さて、ここでバスリセットが発生したとする。すると、割り込みが生じ、両ノードともＡＲＰテーブルをクリアする（２５，２６）。従来の手法では、ここで、再構築用バッファと未送信のＩＰパケットの断片を破棄しなければならない。すなわち、図中のＩＰ−１とＩＰ−２は破棄され、ＩＰパケットは消えてしまうことになる。しかし、本発明の手法では、再構築用バッファ管理情報の送信元ノードＩＤの部分だけを消去する（２７）。
【００３８】
本発明による送信側のノードはバスリセット後も送信を継続する（２８）。ところが、バスリセット時の割り込み処理によりＡＲＰテーブルがクリアされているので、送信先ＩＰアドレスに対するノードＩＤが分からないので、再びＡＲＰリクエストパケットをブロードキャストする（２９，３０）。
【００３９】
ＡＲＰリクエストパケットを受信したノードは１６の場合と同様に必要に応じてＡＲＰレスポンスパケットを返信する（３１，３２）。さらに、再構築用バッファの管理情報を調査し、受信したＡＲＰリクエストパケット中の送信元ＧＵＩＤの値と一致するバッファの送信元ノードＩＤ項を、ＡＲＰリクエストパケットの送信元ノードＩＤに更新する（３３）。この操作により、更新されたバッファは有効な送信元ノードＩＤとｄｇｌの組み合わせを持つことになる。
【００４０】
ＡＲＰレスポンスパケットを受信するとＡＲＰテーブルを更新し（３５）、ＩＰパケットの残りの部分（ＩＰ−２）を送信できる形に変換して送信する（３７，３８）。このとき、２１の操作の時に使用したｄｇｌと同じ値を用いなければならない。
【００４１】
上記のパケットを受信すると、再構築用バッファ管理情報を検索し、送信元ノードＩＤとｄｇｌが一致するバッファを求める。すると、バスリセットにより送信元ノードＩＤが変化したとしても、２７および３３の操作で有効な値に更新されているので、２４の動作で確保したバッファを選択することができる（３８）。バッファが選択できれば適切な位置に受信したＩＰパケットの断片を保存し（３９）、バッファの状態などから全ての断片を受信したと判断した場合はＩＰパケットを復元する（４０）。
【００４２】
次に、フローチャートを用い、送信側ノードと受信側ノードの動作の例を、図面を参照しながら説明する。図７は送信側ノードの動作を、図８は受信側ノードの動作を、図９はバスリセット時の割り込み処理を表すフローチャートである。
【００４３】
図６は送信側ノードの動作を表したフローチャートである。ＩＰ以外のプロトコルのパケットは、それぞれのプロトコルに従い適当に処理される。
【００４４】
ステップＦ１−１では、上位レイヤであるＩＰスタックから、ＩＰパケットの送信が要求され、ＩＰパケットを受け取る。
【００４５】
ステップＦ１−２では、上記ステップで受け取ったＩＰパケットの送信先ＩＰアドレスから、送信するノードＩＤを決定する（後述）。なお、この時に使用する転送速度と、それに伴い制限される最大パケットサイズも決定する。
【００４６】
ステップＦ１−３では、上記ステップで求めた最大パケットサイズと、送信するＩＰパケットのサイズから、ＩＰパケットの分割の必要性を判断する。分割が不要であればステップＦ１−４へ、必要であればステップＦ１−６へ進む。
【００４７】
ステップＦ１−４では、ＩＰパケットをＲＦＣ２７３４のフォーマットに従いＩＥＥＥ１３９４パケットに変換する。
【００４８】
ステップＦ１−５では、上記ステップで変換したパケットを送信し、終了する。
【００４９】
一方、ステップＦ１−３で分割が必要と判断された場合は、ステップＦ１−６でＩＰパケットをＩＥＥＥ１３９４で送信できるサイズに分割する。
【００５０】
ステップＦ１−７は、ステップＦ１−２と同様である。
【００５１】
ステップＦ１−８では、ステップＦ１−６で作られたＩＰパケットの断片の中で、未送信の断片の一つを選択し、ＲＦＣ２７３４に従いＩＥＥＥ１３９４パケットに変換する。
【００５２】
ステップＦ１−９では、上記ステップで変換したパケットを送信する。
【００５３】
ステップＦ１−１０では、ステップＦ１−６で作られたＩＰパケットの断片がすべて送信されたことを確認する。未送信の断片が存在する場合は、ステップＦ１−７に戻り、未送信の断片がなくなるまで繰り返す。
【００５４】
ステップＦ１−１１では、ＲＦＣ２７３４で定められている通りに、分割されたＩＰパケットを送信する際に利用する値であるｄｇｌを増加させ、終了する。ただし、６５５３５を越えた場合は０に戻す。
【００５５】
次に、ステップＦ１−２、および、ステップＦ１−７の動作の詳細を、図７中のＡＲＰのフローチャートを参照しながら説明する。
【００５６】
ステップＦ１−１２では、ノードが保持している１３９４ＡＲＰテーブルを検索し、送信先ＩＰアドレスを持つノードのノードＩＤと、ＩＰパケットを含むＩＥＥＥ１３９４パケットを送信する際のオフセットアドレス、転送速度、最大パケットサイズなどの情報の取得を試みる。
【００５７】
ステップＦ１−１３では、上記検索の正否を判定する。検索に成功し、該当する情報を得られた場合は終了するが、検索に失敗した場合はステップＦ１−１４に進む。
【００５８】
ステップＦ１−１４では、ＲＦＣ２７３４に従い、送信先ＩＰアドレスをターゲットとした１３９４ＡＲＰリクエストパケットをブロードキャストし、１３９４ＡＲＰレスポンスパケットが返ってくるのを待つ。
【００５９】
ステップＦ１−１５では、上記ステップの１３９４リクエストパケットに対するレスポンスパケットを受信する。
【００６０】
ステップＦ１−１６では、上記ステップで受信したパケットから得られた情報を用いて、１３９４ＡＲＰテーブルを更新して、終了する。
【００６１】
図７は、受信側ノードの動作を表したフローチャートである。ＩＰ以外のプロトコルのパケット（ＩＰ用以外のオフセットアドレスに送信されたパケット、１３９４ＡＲＰ以外のアシンクロナスストリームパケットなど）は、それぞれのプロトコルによって適当に処理をされる。また、１３９４ＡＲＰレスポンスを受信した場合の動作は、図７のＡＲＰのフローチャート中にすでに示している。
【００６２】
ステップＦ２−１では、ＩＰパケットを含むパケット、１３９４ＡＲＰリクエストパケットを受信する。
【００６３】
ステップＦ２−２では、上記ステップで受信したパケットの種別を判定する。受信したパケットが１３９４ＡＲＰリクエストの場合はステップＦ２−３へ、ＩＰパケットを含んでいる場合はステップＦ２−９へ進む。
【００６４】
ステップＦ２−３では、ステップＦ２−１で受信した１３９４ＡＲＰリクエストパケットのターゲットＩＰアドレスが自分のＩＰアドレスと一致するかどうかを判定する。一致しない場合は自分宛でないので無視して終了するが、一致する場合はステップＦ２−４に進む。
【００６５】
ステップＦ２−４では、再構築用バッファ管理情報の全てのＧＵＩＤを調査する。
【００６６】
ステップＦ２−５では、前記調査の結果、ステップＦ２−１で受信した１３９４ＡＲＰリクエストパケットの送信元ＧＵＩＤと一致するバッファが存在するかどうかを判定する。存在した場合はステップＦ２−６へ、存在しない場合はＦ２−８へ進む。
【００６７】
ステップＦ２０６では、上記ステップで一致したバッファの送信元ノードＩＤの項を調べ、値がセットされていなければステップＦ２−７へ進み、有効な値がセットされていればステップＦ２−８へ進む。
【００６８】
ステップＦ２−７では、上記ステップの送信先ノードＩＤの項にステップＦ２−１で受信した１３９４ＡＲＰパケットの送信元ノードＩＤの値をセットする。
【００６９】
ステップＦ２−８では、適切な値をセットした１３９４ＡＲＰレスポンスパケットを返信する。
【００７０】
一方、ステップＦ２−９では、ステップＦ２−１で受信したパケットに含まれているＩＰパケットの状態を判定する。ＩＰパケットが分割されていない場合は、ステップ２−１７へ進み、分割されている場合はステップＦ２−１０へ進む。
【００７１】
ステップＦ２−１０では、ステップＦ２−１で受信したパケットの送信元ノードＩＤとｄｇｌの値から、図６で示した様な再構築用バッファ管理情報を参照し、再構築バッファが割り当てられているか否かを調べる。
【００７２】
ステップＦ２−１１では、上記ステップの検索で対応する再構築用バッファを得られればステップＦ２−１３へ進み、対応する再構築用バッファが無い場合にはステップＦ２−１２へ進む。
【００７３】
ステップＦ２−１２では、ステップＦ２−１で受信したパケットに含まれるＩＰパケットを再構築する為のバッファを用意する。バッファのサイズはパケット中の情報から決定することができる。その後、再構築用バッファ割り当て情報にオフセットアドレス、ｄｇｌ、再構築用バッファのアドレスなどの情報を付け加える。
【００７４】
ステップＦ２−１３では、上記ステップで用意したバッファ、あるいは、ステップＦ２−１０で検索したバッファの適当な位置にＦ２−１で受信したパケット中のＩＰパケットの部分をコピーする。位置は、パケット中のｆｒａｇｍｅｎｔ＿ｏｆｆｓｅｔフィールドの値から決定することができる。
【００７５】
ステップＦ２−１４では、上記ステップでＩＰパケットを完全に再構築できたかどうかを判断する。再構築が完了していない場合は終了するが、完了しＩＰパケットを得ることができた場合はステップＦ２−１５へ進む。
【００７６】
ステップＦ２−１５では、上記ステップで再構築したパケットを上位レイヤであるＩＰスタックに渡す。
【００７７】
ステップＦ２−１６では、再構築が完了したパケットが利用していたバッファを解放し、再構築用バッファ割り当て情報から解放したバッファの情報を削除して終了する。
【００７８】
また、ステップＦ２−１７では、ＩＰパケットは分割されていないので、ステップＦ２−１で受信したパケットからＩＰパケットを取り出す。
【００７９】
ステップＦ２−１８は、ステップＦ２−１２と同様に、ＩＰパケットを上位レイヤのＩＰスタックに渡して終了する。
【００８０】
図８は、バスリセットが発生したときの割り込み処理のフローチャートである。ここで示しているのは、ＩＰ関連の処理のみであり、他のプロトコルの割り込み処理は必要に応じて適当に実行される。
【００８１】
ステップＦ３−１では、１３９４ＡＲＰテーブルをクリアする。これは、バスリセットに伴って、ノードＩＤが変化した可能性があるためである。
【００８２】
ステップＦ３−２では、保持している再構築用バッファ管理情報のうち、全ての送信元ノードＩＤの値をクリアする。その他の値は維持する。
【００８３】
従来の手法では、ステップＦ３−１およびステップＦ３−２のほかに、再構築用バッファの破棄、送信待の分割されたＩＰパケットの破棄などの処理が必要であり、オーバヘッドが大きかったが、提案手法ではそのような処理を行う必要はない。
【００８４】
（第二の実施例）
図９に、本発明を適用する通信ネットワークシステムの構成を示す。全てのノードが本発明の通信制御方法を備えているわけなく、一部のノードは従来の手法（ＲＦＣ２７３４）にのみ対応している点で、図２とは異なっている。図２と同様に、接続形態、ノード数などは図示している例に制限されない。
【００８５】
図１０に、再構築用のバッファを管理するための情報の例を示す。図５に対し、バッファの保持時間を制御するためのフィールドが追加されている。各ノードはこのフィールドを参照して、設定した時間以上経過した場合には、バッファ内容を破棄し、バッファを解放するようにする。例えば、バッファを確保した時に、ある０でない値を書き込み、処理の適当な段階でこのフィールドの値を減少させていき、０になった時点で破棄するというようにする。
【００８６】
次に、フローチャートを用いノードの動作の例を説明する。送信の際の動作、および、バスリセット時の割り込み動作は第一の実施例の場合と同じで良い。
【００８７】
図１２は受信側ノードの動作を表したフローチャートである。図７と同様に、ＩＰ以外のプロトコルのパケット（ＩＰ用以外のオフセットアドレスに送信されたパケット、１３９４ＡＲＰ以外のアシンクロナスストリームパケットなど）は、それぞれのプロトコルによって適当に処理をされる。また、１３９４ＡＲＰレスポンスを受信した場合の動作は、図６のＡＲＰのフローチャート中にすでに示している。
【００８８】
ステップＦ４−１は、図７のフローチャート全体（ステップＦ２−１からステップＦ２−１８まで）である。図１１のフローチャートは、図７のフローチャートにステップＦ４−２からステップＦ４−４を付け加えた形になる。
【００８９】
ステップＦ４−２では、再構築用バッファ割り当て情報の全ての寿命フィールドを減少させる。これは、図１０の説明で述べた動作である。
【００９０】
ステップＦ４−３では、上記ステップの操作により、寿命フィールドが０になったバッファの有無を調査し、存在する場合はステップＦ４−４へ進み、存在しない場合は終了する。
【００９１】
ステップＦ４−４では、寿命フィールドが０になった全てのバッファの内容を破棄し、バッファを解放し、再構築用バッファ割り当て情報から削除し、終了する。
【００９２】
【発明の効果】
以上説明したように、本出願に係る第一の発明によれば、バスリセット時に物理的なアドレスが変化するインターフェースでのＩＰ通信において、分割されたＩＰパケットを送受信している途中でバスリセットが発生した場合においても、送信側、受信側の両ノードとも不完全なパケットを破棄する必要はなく、送信側がＡＲＰを行うだけで通信を継続することができ、オーバヘッドを縮小できるという効果がある。
【００９３】
また、バスリセット時に不完全なＩＰパケットを破棄するような従来の手法を用いるノードが、ネットワーク上に混在した場合においても、受信側のバッファの保持時間に制限をつけることによって、本発明の手段を備えるノードと従来手法のノードが円滑に通信することができる効果もある。
【図面の簡単な説明】
【図１】本発明の効果的な場合の動作を説明する図である。
【図２】本発明の通信制御方法と通信機器を用いた実施例の一つであるネットワークの構成図である。
【図３】ＲＦＣ２７３４で規定されたＡＲＰ情報のフォーマットである。
【図４】既知のＡＲＰ情報を保持するＡＲＰテーブルである。
【図５】再構築用に用いられるバッファの情報をあらわす表である。
【図６】送信時の動作を表すフローチャートである。
【図７】受信時の動作を表すフローチャートである。
【図８】バスリセット時の割り込み動作を表すフローチャートである。
【図９】本発明の通信制御方法と通信機器を用いた実施例の一つであるノードと従来手法のノードが混在するネットワークの構成図である。
【図１０】再構築用に用いられるバッファの情報をあらわす表である。
【図１１】受信時の動作を表すフローチャートである。
【符号の説明】
１〜４ 本発明の通信機器である。
５ ＩＥＥＥ１３９４によるネットワークである。
６ ＡＲＰパケットのリクエスト／レスポンスを区別するフィールドである。
７ 送信元のノードユニークＩＤである。
８，９ 送信元ノードがＩＰパケットを受け付けるオフセットアドレスである。
１０ 送信元のＩＰアドレスである。
１１ ノードＩＤを知りたいＩＰアドレスである。
１２ ＩＰパケットの送信要求の発生を表す。
１３，２９ ＡＲＰリクエストの発生を表す。
１４，３０ ＡＲＰリクエストを表す。
１５，３１ 受信したＡＲＰリクエストの受け入れを表す
１６，１９，３２，３５ ＡＲＰテーブルの更新を表す。
１７，３３ 再構築用バッファ管理情報のＡＲＰリクエストを用いた更新を表す。
１８，３４ ＡＲＰレスポンスを表す。
２０ ＩＰパケットのサイズが大きい場合の分割を表す。
２１，３６ ＩＥＥＥ１３９４パケットに変換する動作を表す。
２２，３７ ＩＰパケットを含んだパケットの転送を表す。
２３，３８ 再構築に使用するためのバッファが確保済みかどうかの調査を表す。
２４ 再構築に使用するバッファの確保と受信データの保存を表す。
３９ 受信データの保存を表す。
４０ ＩＰパケットの再構築の完了を表す。
４１，４４ 本発明の通信機器である
４２，４３ 従来の通信方法に従う通信機器である。
４５ ＩＥＥＥ１３９４によるネットワークである。
Claims (12)
- ノードの物理アドレス（ノードＩＤ）で送信先を特定するインターフェースを用いるインターネットプロトコル通信における通信制御方式であって、
ＡＲＰ動作の際に、ＡＲＰリクエストパケットを受信したノードが、前記ＡＲＰリクエストパケットのターゲットとするＩＰアドレスが自分のＩＰアドレスであった場合に、
受信したＩＰパケットを再構築するためのバッファの管理情報を全て調査するステップと、
前記調査した管理情報の送信元ユニークＩＤ情報と、前記ＡＲＰリクエストパケット中のユニークＩＤとが一致するバッファが存在し、なおかつ、前記バッファの送信元ノードＩＤ情報がクリアされている場合において、
前記ＡＲＰリクエストパケットの送信元ノードＩＤを、前記バッファの送信元ノードＩＤ情報の項にセットするステップを有することを特徴とする。
また、同時に、バスリセットが発生した場合に、上記再構築バッファの管理情報のうち、送信元ノードＩＤ情報のみを消去するステップを有することを特徴とする通信制御方式。 - ＩＰパケットを複数に分割して送信する際に、
分割して作られたパケットをすべて送信していない時点でバスリセットが発生した場合において、
未送信のパケットを破棄しないステップと、
ＡＲＰリクエストにより再び物理アドレスなどの情報を求めるステップと、
前記ＡＲＰリクエストで求めた情報を用いて、前記未送信のパケットを送信するステップを有することを特徴とする請求項１記載の通信制御方式。 - 上記インターフェースはＩＥＥＥ１３９４シリアルバスであることを特徴とする請求項１〜２記載の通信制御方式。
- ＩＰパケットを再構築するためのバッファが確保されてからの経過時間などをカウントするステップと、
前記時間などが一定値を越えた場合は当該バッファの内容を破棄するステップを有することを特徴とする請求項１〜３記載の通信制御方式。 - ノードの物理アドレス（ノードＩＤ）で送信先を特定するインターフェースを有する通信機器であって、
インターネットプロトコル通信のＡＲＰ動作に伴うＡＲＰリクエストパケットを受信した際に、
前記ＡＲＰリクエストパケットのターゲットとするＩＰアドレスが自分のＩＰアドレスであった場合に、
受信したＩＰパケットを再構築するためのバッファの管理情報を全て調査する手段と、
前記調査した管理情報の送信元ユニークＩＤ情報と、前記ＡＲＰリクエストパケット中のユニークＩＤとが一致するバッファが存在し、なおかつ、前記バッファの送信元ノードＩＤ情報がクリアされている場合において、
前記ＡＲＰリクエストパケットの送信元ノードＩＤを、前記バッファの送信元ノードＩＤ情報の項にセットする手段を有することを特徴とする。
また、同時に、バスリセットが発生した場合に、上記再構築バッファの管理情報のうち、送信元ノードＩＤ情報のみを消去する手段を有することを特徴とする通信機器。 - ＩＰパケットを複数に分割して送信する際に、
分割して作られたパケットをすべて送信していない時点でバスリセットが発生した場合において、
未送信のパケットを破棄しない手段と、
ＡＲＰリクエストにより再び物理アドレスなどの情報を求める手段と、
前記ＡＲＰリクエストで求めた情報を用いて、前記未送信のパケットを送信する手段を有することを特徴とする請求項５記載の通信装置。 - 上記インターフェースはＩＥＥＥ１３９４シリアルバスであることを特徴とする請求項５〜６記載の通信制御方式。
- ＩＰパケットを再構築するためのバッファが確保されてからの経過時間などをカウントする手段と、
前記時間などが一定値を越えた場合は当該バッファの内容を破棄する手段を有することを特徴とする請求項５〜７記載の通信制御方式。 - ノードの物理アドレス（ノードＩＤ）で送信相手を特定するインターフェースを用いるインターネットプロトコル通信に関するプログラムを記録した記録媒体であって、
ＡＲＰ動作の際に、ＡＲＰリクエストパケットを受信したノードが、前記ＡＲＰリクエストパケットのターゲットとするＩＰアドレスが自分のＩＰアドレスであった場合に、
受信したＩＰパケットを再構築するためのバッファの管理情報を全て調査するステップと、
前記調査した管理情報の送信元ユニークＩＤ情報と、前記ＡＲＰリクエストパケット中のユニークＩＤとが一致するバッファが存在し、なおかつ、前記バッファの送信元ノードＩＤ情報がクリアされている場合において、
前記ＡＲＰリクエストパケットの送信元ノードＩＤを前記バッファの送信元ノードＩＤ情報の項にセットするステップを有するプログラムを記録することを特徴とする。
また、同時に、バスリセットが発生した場合に、上記再構築バッファの管理情報のうち、送信元ノードＩＤ情報のみを消去するステップを有することを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。 - ＩＰパケットを複数に分割して送信する際に、
分割して作られたパケットをすべて送信していない時点でバスリセットが発生した場合において、
未送信のパケットを破棄しないステップと、
ＡＲＰリクエストにより再び物理アドレスなどの情報を求めるステップと、
前記ＡＲＰリクエストで求めた情報を用いて、前記未送信のパケットを送信するステップを有するプログラムを記録したことを特徴とする請求項９記載のコンピュータ読み取り可能な記録媒体。 - 上記インターフェースはＩＥＥＥ１３９４シリアルバスであることを特徴とする請求項９〜１０記載のコンピュータ読み取り可能な記録媒体。
- ＩＰパケットを再構築するためのバッファが確保されてからの経過時間などをカウントするステップと、
前記時間などが一定値を越えた場合は当該バッファの内容を破棄するステップを有するプログラムを記録したことを特徴とする請求項９〜１１記載のコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003118483A JP2004328221A (ja) | 2003-04-23 | 2003-04-23 | 通信制御方式、及び、通信機器、及び、記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003118483A JP2004328221A (ja) | 2003-04-23 | 2003-04-23 | 通信制御方式、及び、通信機器、及び、記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004328221A true JP2004328221A (ja) | 2004-11-18 |
Family
ID=33498010
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003118483A Withdrawn JP2004328221A (ja) | 2003-04-23 | 2003-04-23 | 通信制御方式、及び、通信機器、及び、記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004328221A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006295259A (ja) * | 2005-04-05 | 2006-10-26 | Canon Inc | 通信装置及びその通信制御方法 |
-
2003
- 2003-04-23 JP JP2003118483A patent/JP2004328221A/ja not_active Withdrawn
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006295259A (ja) * | 2005-04-05 | 2006-10-26 | Canon Inc | 通信装置及びその通信制御方法 |
| US8832312B2 (en) | 2005-04-05 | 2014-09-09 | Canon Kabushiki Kaisha | Communication apparatus and communication control method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6977939B2 (en) | Method and apparatus for emulating ethernet functionality over a serial bus | |
| US6728213B1 (en) | Selective admission control in a network device | |
| JP4230663B2 (ja) | 無線通信ネットワークにおけるパケット・ヘッダの削減 | |
| EP1570361B1 (en) | Method and apparatus for performing network processing functions | |
| US7505455B1 (en) | Optimizations for tunneling between a bus and a network | |
| EP0996069B1 (en) | Method of transferring image data using a IEEE 1394 bus | |
| US20090031054A1 (en) | Data processing apparatus and data transfer method | |
| JP2003308262A (ja) | ハードウェアプロトコルプロセシングロジックで実現されたインタネット通信プロトコル装置、及びその装置を用いたデータ並列処理方法 | |
| WO2000023906A1 (en) | System for dynamically binding subobjects into objects to represent devices within ieee 1394 serial bus network | |
| JP5003821B2 (ja) | 試験装置及び方法 | |
| US7009967B1 (en) | Systems and methods for transmitting data packets | |
| KR20010014980A (ko) | 통신 버스를 통해 수신된 버스 인터페이스 유닛 내의데이터 패킷을 미리 처리하는 방법, 상기 방법 내에서사용하기 위한 버스 인터페이스 유닛 및 상기 방법 내에서사용하기 위한 애플리케이션 데이터 프로세싱 유닛 | |
| US7188250B1 (en) | Method and apparatus for performing network processing functions | |
| WO2000025217A1 (fr) | Controleur de transfert de donnees et dispositif electronique | |
| US6909699B2 (en) | Data transfer system, data transfer management apparatus and data transfer method | |
| JP2002111704A (ja) | データ送受信装置及び方法 | |
| EP1156423A2 (en) | Information processing apparatus, information processing method and bridge utilizing the same | |
| EP1648127A1 (en) | Method and apparatus for transmitting isochronous stream | |
| JP3988475B2 (ja) | 送信装置、受信装置およびそれらの方法 | |
| US6961777B1 (en) | Systems and methods for predicting fields in a data packet | |
| JP2004328221A (ja) | 通信制御方式、及び、通信機器、及び、記録媒体 | |
| EP0853398A2 (en) | Communication systems, communication apparatus and communication methods | |
| JP4264924B2 (ja) | データ転送方法 | |
| JP3604032B2 (ja) | ＩＥＥＥ１３９４−Ｅｔｈｅｒｎｅｔ（登録商標）ブリッジノードおよび方法 | |
| JP4261992B2 (ja) | 情報データの送受信装置及び送受信方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060704 |