(57)【特許請求の範囲】
【請求項１】
制御信号と情報信号とを混在させて伝送できる通信制御バスによって複数の電子機器が接続され、該電子機器間でＡＲＰ（Address Resolution Protocol）通信する通信方法において、
一の電子機器から他の電子機器に上記制御信号を送信し、
上記制御信号は、上記一の電子機器を固有に識別可能な電子機器識別情報と、上記一の電子機器を特定するＩＰアドレス情報と、上記他の電子機器を特定するＩＰアドレス情報と、上記一の電子機器内のメモリにおいてＩＰ通信に利用されるオフセット情報とが含まれていることを特徴とする通信方法。
【請求項２】
上記通信制御バスは、ＩＥＥＥ１３９４シリアルバスであることを特徴とする請求項１記載の通信方法。
【請求項３】
制御信号と情報信号とを混在させて伝送できる通信制御バスによって複数台接続され、ＡＲＰ（Address Resolution Protocol）通信する電子機器において、
上記通信制御バス上に接続されている一の電子機器は、
上記一の電子機器を固有に識別可能な電子機器識別情報と、上記一の電子機器を特定するＩＰアドレス情報と、上記通信制御バス上に接続されている他の電子機器を特定するＩＰアドレス情報と、上記一の電子機器内のメモリにおいてＩＰ通信に利用されるオフセット情報とが含まれている上記制御信号を生成する生成手段と、
上記生成手段で生成した上記制御信号を上記通信制御バスを介して上記他の電子機器に送信する送信手段とを備えることを特徴とする電子装置。
【請求項４】
上記通信制御バスは、ＩＥＥＥ１３９４シリアルバスであることを特徴とする請求項３記載の電子機器。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばＩＥＥＥ−１３９４シリアルバス（以下１３９４バスという。）で複数の電子機器を接続し、これらの電子機器（以下ノードという。）間で通信を行う通信方法に関し、詳細にはＡＲＰ（Address Resolution Protocol）及びＲＡＲＰ（Reverse Address Resolution Protocol）に関する。
【０００２】
【従来の技術】
ＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）とは、図７に示す通信を行うものである。つまり、制御側のノードがブロードキャストでバス上にＡＲＰパケットを送信し、指定のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを所有するノードに、その物理アドレスを知らせるようにリクエストを送る。バスに接続されたノードは、自分が指定のＩＰアドレスを所有していない場合はそのリクエストを無視し（図７−［１］）、自分が指定のＩＰアドレスを所有するノードであれば自らの物理ノードアドレスを返信する（図７−［２］）。
【０００３】
また、ＲＡＲＰにおいては、ＩＰアドレスを知りたいノードの物理アドレスをブロードキャストとしてＲＡＲＰサーバからＩＰアドレスを知らせてもらう（図８）。特に自らのＩＰアドレスを知りたい場合には、自らの物理ノードアドレスをブロードキャストとしてＲＡＲＰサーバーからＩＰアドレスを知らせてもらう
。
【０００４】
【発明が解決しようとする課題】
従来のＡＲＰで制御側のノードが得られる情報は制御対象であるノードの物理ノードアドレスに止まっていた。このため、ＡＲＰで物理ノードアドレスが判明した後、制御側のノードは制御対象となるノードの物理ノードアドレスに向けて通信データを発信するが、制御対象のノードに備わったＣＰＵは通信データの内容によって判断した結果、そのプロトコルを処理できる適切なアプリケーションに通信データを分配する必要があった。また、この分配作業の際に、通信可能なパケットの最大長について制限されることがあった。
【０００５】
また、従来のＲＡＲＰにおいては、通信中にバスリセットが起きた場合、ＩＰアドレスの要求を出したノードの物理ノードアドレスが変わってしまうため、ＲＡＲＰサーバーはＩＰアドレスを知らせる相手を物理ノードアドレスによって知ることができなくなってしまう。
【０００６】
本発明はこのような問題点に鑑みてなされたものであって、下記（１）〜（４）を実現する通信制御方法及びノードを提供することを目的とする。
【０００７】
（１）制御対象のノードにおいてＣＰＵによるデータ分配作業のオーバーヘッドをなくす。
（２）通信時のパケット長についての制限をフレキシブルにする。
（３）バスリセット時の物理ノードアドレス変化に適切に対応する。
（４）バスリセット時に物理ノードアドレスが変化してしまうネットワークにおいてＲＡＲＰを可能とする。
【０００８】
【課題を解決するための手段】
前記課題を解決するために、本発明は、制御信号と情報信号とを混在させて伝送できる通信制御バスによって複数の電子機器が接続され、該電子機器間でＡＲＰ（Address Resolution Protocol）通信する通信方法において、一の電子機器から他の電子機器に上記制御信号を送信し、上記制御信号は、上記一の電子機器を固有に識別可能な電子機器識別情報と、上記一の電子機器を特定するＩＰアドレス情報と、上記他の電子機器を特定するＩＰアドレス情報と、上記一の電子機器内のメモリにおいてＩＰ通信に利用されるオフセット情報とが含まれていることを特徴とするものである。
また、前記課題を解決するために、本発明は、制御信号と情報信号とを混在させて伝送できる通信制御バスによって複数台接続され、ＡＲＰ（Address Resolution Protocol）通信する電子機器において、上記通信制御バス上に接続されている一の電子機器は、上記一の電子機器を固有に識別可能な電子機器識別情報と、上記一の電子機器を特定するＩＰアドレス情報と、上記通信制御バス上に接続されている他の電子機器を特定するＩＰアドレス情報と、上記一の電子機器内のメモリにおいてＩＰ通信に利用されるオフセット情報とが含まれている上記制御信号を生成する生成手段と、上記生成手段で生成した上記制御信号を上記通信制御バスを介して上記他の電子機器に送信する送信手段とを備えることを特徴とするものである。
【０００９】
また、ノードユニークＩＤを同時に通信することによってバスリセット時の適切な対応を実現する。
【００１０】
本発明によれば、通信するノードは物理ノードアドレスに加えて各ノードのアプリケーション毎のオフセットをアドレスを情報として扱うことが可能になる。そして、これにより、以降の通信においては、ＣＰＵを介することなく直接制御対象のアプリケーションに通信データを転送できるとともに、バスリセット時にもノードユニークＩＤによって確実に通信相手を特定することができる。
【００１１】
さらに、ＡＲＰに関しては、バスリセットが起きた時に  ＡＲＰキャッシュテーブル内の対応するバスＩＤのエントリーをフラッシュすることにより、通信の信頼性を高めることができる。
【００１２】
【発明の実施の形態】
以下本発明の実施の形態について図面を参照しながら詳細に説明する。
図１に本発明を適用する通信ネットワークシステムの構成を示す。この通信ネットワークシステムは、第１の１３９４バス１とそれに接続された複数のノード（ノードＩＤ０，１，２，・・・）からなるネットワークと、第２の１３９４バス２とそれに接続された複数のノード（ノードＩＤ０，１，２，３，・・・）からなるネットワークとを有する。第１の１３９４バス１のバスＩＤは０であり、第２の１３９４バス２のバスＩＤは１である。これらのネットワークは１３９４ブリッジ３を介して接続されている。なお、ここにはバスＩＤが０と１の２個のネットワークを図示したが、これ以外にも１３９４ブリッジにより多数のネットワークが接続されている。
【００１３】
図１においてバスＩＤは各バス毎に付けられている。また、ノードＩＤ（物理ノードアドレス）はバス内の各ノードに付けられている。このノードＩＤはバスリセットが起こる毎に自動的に付けられるが、バスリセット毎に異なる値になる可能性がある。さらに、各ノードはＩＥＥＥ−１３９４で規定されたノードユニークＩＤをＲＯＭに保持している。ノードユニークＩＤは各ノード固有のＩＤであって、バスリセットが起こっても不変である。また、各ノードは前述したＩＰアドレスを持っている。
【００１４】
図２に各ノードが備えているアドレスキャッシュテーブルの内容の一例を示す。各ノードは他のノードとの通信の必要性が生ずる度にＡＲＰを用いてアドレスキャッシュテーブルを作成する。
【００１５】
図３及び図４に、１３９４バスにのせて実行するＡＲＰ通信で使われるＡＲＰパケットの例を示す。ここで、図３はＡＲＰリクエストパケットの例であり、図４はＡＲＰレスポンスパケットの例である。これらの図に示すように、ＡＲＰリクエストパケット及びＡＲＰレスポンスパケットは、１３９４アシンクロナスパケットヘッダーと、ＳＴ（ストリームタイプ）と、ＬＬＣ／ＳＮＡＰヘッダーと、ＡＲＰパケットから構成されている。そして、ＡＲＰパケットは、ＡＲＰヘッダーとＡＲＰデータから構成されている。以下ＡＲＰリクエストパケットとＡＲＰレスポンスパケットの内容について順に説明する。
【００１６】
ＡＲＰリクエストパケットにおける１３９４アシンクロナスパケットヘッダーの先頭の１０ビットには、このパケットが全てのバスに対して送られることを示すブロードキャストバスＩＤ（０ｘ３ＦＥ）が入っている。そして、次の６ビットにはこのパケットが各バス内の全てのノードに対して送られることを示す値（０ｘ３Ｆ）が入っている。先頭から５〜６バイトには、このパケットを送信したノードのノードＩＤであるソースＩＤが入っている。さらに次の６バイトには、このパケットを受け取るノードの内部のメモリ空間の所定のアドレスを示すデスティネーションオフセット（０ｘＦＦＦＦ  ＦＦＦＦ  ＦＦＦＦ）が入っている。
【００１７】
ＳＴフィールドの０ｘ００は、このパケットがＬＬＣ（Ｌｏｇｉｃａｌ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）通信（ＡＲＰ／ＲＡＲＰ／ＩＰ等の通信を含む）に関するパケットであることを意味する。
【００１８】
ＡＲＰヘッダーのプロトコルタイプフィールドにはこのパケットがＩＰプロトコルに関するものであることを示す値（０ｘ０８００）が入っており、オペレーションフィールドにはＡＲＰリクエストであることを示す値が入っている。
【００１９】
ＡＲＰデータの先頭の８バイトには、ＡＲＰリクエストパケットを送信したノードの６４ビットアドレスが入っている。この６４ビットのうち１６ビットはノードＩＤ（＝ソースＩＤ）であり、残りの４８ビットはノードの内部のメモリ空間のオフセットアドレスである。このオフセットアドレスは、ＩＰプロトコルを処理するアプリケーションが管理するメモリ空間の先頭アドレス（以下単にアプリケーションのオフセットアドレスという）である。
【００２０】
ＡＲＰデータの次の８バイトには、このパケットを送信したノードのノードユニークＩＤが入っている。そして、次の４バイトにはこのノードのＩＰアドレスが入っている。
【００２１】
さらに、次の８バイトはこのパケットの送信先ノードの６４ビットアドレスを入れるフィールドであるが、ＡＲＰリクエストパケットの場合には、パケットを全てのノードにブロードキャストするので、ここは不確定である（全て１を入れる）。これに続く８バイトのノードユニークＩＤについても同様である。
【００２２】
ＡＲＰレスポンスパケットにおける１３９４アシンクロナスパケットヘッダーの先頭の２バイトであるデスティネーションＩＤには、このパケットの送信先のノードＩＤ、すなわちＡＲＰリクエストパケットを送信したノードのノードＩＤが入っている。次の２バイトのソースＩＤには、ＡＲＰレスポンスパケットを送信したノードのノードＩＤが入っており、その次の６バイトには、このパケットの受信の際のノードの内部のメモリ空間のオフセットアドレスであるデスティネーションオフセットの値が入っている。このオフセットアドレスは、ＩＰプロトコルを処理するアプリケーションのオフセットアドレスである。ＡＲＰリクエストパケット内の“送信元ノードの６４ビットアドレス”フィールドの値が入れられる。
【００２３】
ＡＲＰデータの先頭の８バイトには、ＡＲＰレスポンスパケットを送信したノードの６４ビットアドレスが入っている。この６４ビットのうち１６ビットはノードＩＤ（＝ソースＩＤ）であり、残りの４８ビットはノードの内部でＩＰプロトコルを処理するアプリケーションのオフセットアドレスである。
【００２４】
ＡＲＰデータの次の８バイトには、このパケットを送信したノードのノードユニークＩＤが入っている。そして、次の４バイトにはこのノードのＩＰアドレスが入っている。
【００２５】
さらに、次の８バイトには、このＡＲＰレスポンスパケットの送信先のノード（＝ＡＲＰリクエストパケットの送信元のノード）の６４ビットアドレスが入っている。次の８バイトにはＡＲＰレスポンスパケットの送信先のノードユニークＩＤが入っている。さらに、次の４バイトにはこのノードのＩＰアドレスが入っている。つまり、この２０バイトはＡＲＰリクエストパケットのＡＲＰデータの先頭の２０バイトをスワップしたものである。
【００２６】
次に図１〜図４を参照しながらＡＲＰ通信について説明する。
制御側のノード、例えば第１の１３９４バス１におけるノード０がＩＰアドレスが３のノードの物理アドレスを知りたい場合に、図３に示したフォーマットのＡＲＰリクエストパケットを第１の１３９４バス１に送出する。このパケットは第１の１３９４バス１内の他の全てのノード及び１３９４ブリッジを介して接続された他の１３９４バス内の全てのノードで受信される。
【００２７】
ＡＲＰリクエストパケットを受信したノードは、このパケットのデータ（ＳＴ以降）をデスティネーションオフセットが示すアドレスに送り、データの内容を見る。そして、ＡＲＰデータにおける送信先のＩＰアドレスが自分が所有するＩＰアドレスと一致しなければそのリクエストを無視し、一致する場合には図４に示したＡＲＰレスポンスパケットを返信する。図１及び図２の場合、ＩＰアドレスが３のノードは、第２の１３９４バス２内におけるノードＩＤが１のノードであるから、このノードがＡＲＰレスポンスパケットを返信する。
【００２８】
ＡＲＰレスポンスパケットを返信するノードは、ＡＲＰリクエストパケットのＡＲＰヘッダーに書いてあるプロトコルタイプがＩＰなので、ＡＲＰレスポンスパケットの１３９４アシンクロナスパケットヘッダーのデスティネーションオフセット、及びＡＲＰデータの送信元ノードの６４ビットアドレスのうちノードＩＤを除く４８ビットには、ＩＰプロトコルを処理するアプリケーションのオフセットアドレスを書く。
【００２９】
以上の通信によって、制御側のノードは、指定のＩＰアドレスのノードについて物理的なノードＩＤだけでなく、そのノードが備えているアプリケーション（ネットワークプロトコル）のオフセットアドレスについても知ることができる。したがって、上記の通信により以降に制御対象を指定する際、ノードＩＤに加えて制御対象のノードにおけるアプリケーションのオフセットアドレスを直接指定して送信することができる。制御対象となったノードは、その通信データを受信した際に通信データをオフセットアドレスに転送すればよいので、特にノードが複数のアプリケーションに対応している場合に、ＣＰＵがＡＲＰヘッダーのプロトコルタイプを見てデータの配分を行うというオーバーヘッドをなくすことができる。
【００３０】
また、どんなパケットもＣＰＵを介して固定のオフセットアドレスに配られるようにすると、ＣＰＵが通信のために用意する一定の大きさのバッファによって、どんなアプリケーションの通信パケットでも最大長が一定に制限されてしまう。本実施の形態では、こういった問題点に関しても、アプリケーション毎のオフセットアドレスをノードが自由にセットすることで通信データの最大長をフレキシブルに設定することができる。
【００３１】
次にバスリセット時の動作について説明する。１３９４バスにおいては、ノードの電源をオン／オフしたり、バスにノードを接続したり、バスからノードを抜いたりした場合にはバスリセットが起こる。バスリセットが起こると、バスリセットが起きたバス内では自動的にノードＩＤの割り付けが行われるが、新たに割り付けられたノードＩＤはバスリセット前のノードＩＤと異なってしまう可能性がある。また、バスリセットが起きたことは、１３９４ブリッジを通して他の１３９４バスに伝達される。したがって、ＡＲＰキャッシュテーブルにおいて、バスリセットが起こったバス内のノードに関するデータをエントリー別にフラッシュする。この場合、全てのエントリーをフラッシュしてもよいが、ノードユニークＩＤはバスリセット後も変化しないので、フラッシュしなくてもよい。ノードユニークＩＤをフラッシュしない場合には、ノードユニークＩＤを使用したコマンドセットであれば、アドレス情報が失われても支障なく通信を継続することが可能である。
【００３２】
以上ＡＲＰ通信について説明した。次にＲＡＲＰ通信について説明する。図５及び図６に、１３９４バスにのせて実行するＲＡＲＰ通信で使われるＲＡＲＰパケットの例を示す。ここで、図５はＲＡＲＰリクエストパケットの例であり、図６はＲＡＲＰレスポンスパケットの例である。ＲＡＲＰパケットの内容はＡＲＰパケットの内容と共通する部分が多いので、ここでは異なる部分について説明する。
【００３３】
ＲＡＲＰリクエストパケットにおけるＬＬＣ／ＳＮＡＰヘッダーのイーサタイプフィールドには、ＲＡＲＰを示す０Ｘ８０３５を入れる。また、ＲＡＲＰヘッダーのオペレーションフィールドには、ＲＡＲＰリクエストであることを示す値を入れる。ＲＡＲＰデータの送信元ノード（ＩＰアドレスを要請するノード）のＩＰアドレスを入れるフィールドは不確定であるため全て０を入れる。問合せノードのアドレスはノードユニークＩＤを用いる。自分のＩＰアドレスを問合せたい場合は、自分のノードユニークＩＤを用いる。そして、問合せノードのＩＰアドレスは不確定であるため全て０にする。
【００３４】
ＲＡＲＰレスポンスパケットでは、ＲＡＲＰヘッダーのオペレーションフィールドには、ＲＡＲＰレスポンスであることを示す値を入れる。ＲＡＲＰデータにおける送信元ノードのＩＰアドレスを入れるフィールドには、サーバーのＩＰアドレスを入れる。そして、送信先ノードのＩＰアドレスにはＩＰアドレスを要請したノードのＩＰアドレスを入れる。
【００３５】
ＲＡＲＰ通信では、図５に示したＲＡＲＰリクエストパケットを１３９４トランザクションによって１３９４バス上にブロードキャストで送信し、ＩＰアドレスを知りたいノードのアドレス情報やノードユニークＩＤを提示してＩＰアドレスの割当を要請する。サーバーは要請のあったノードにＩＰアドレスを割り当て、図６に示したＲＡＲＰレスポンスパケットにのせて返信する。サーバーは、図２と同様のＩＰアドレスと物理アドレス及びノードユニークＩＤとの対応テーブルを持っているので、ノードＩＤだけではなく、ノードユニークＩＤについても知っている。したがって、バスリセット等が原因で物理的なノードアドレスが不明になった場合でも、確実にＩＰアドレスを供給することができる。
【００３６】
以上、１３９４バスによるＩＰ通信システムを例にあげて説明をしたが、本発明はＩＰＸ通信システムやアップルトーク（Ａｐｐｌｅ  Ｔａｌｋ）等についても適用できる。また、アドレス長が１６バイトのＩＰバージョン６にも適用できる。
【００３７】
【発明の効果】
以上詳細に説明したように、本発明によれば、下記（１）〜（４）の効果を奏する。
【００３８】
（１）制御対象のノードにおいてＣＰＵによるデータ分配作業のオーバーヘッドをなくす。
（２）通信時のパケット長についての制限をフレキシブルにする。
（３）バスリセット時の物理ノードアドレス変化に適切に対応する。
（４）バスリセット時に物理ノードアドレスが変化してしまうネットワークにおいてＲＡＲＰ，ＢＣＯＴＰ（Ｂｃｏｔ  Ｐｒｏｔｏｃｏｌ），ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等を可能とする。
【図面の簡単な説明】
【図１】本発明を適用する通信ネットワークシステムの構成を示す図である。
【図２】アドレスキャッシュテーブルの内容の一例を示す図である。
【図３】ＡＲＰリクエストパケットの構成の一例を示す図である。
【図４】ＡＲＰレスポンスパケットの構成の一例を示す図である。
【図５】ＲＡＲＰリクエストパケットの構成の一例を示す図である。
【図６】ＲＡＲＰレスポンスパケットの構成の一例を示す図である。
【図７】ＡＲＰ通信を説明する図である。
【図８】ＲＡＲＰ通信を説明する図である。
【符号の説明】
１，２…１３９４バス、３…１３９４ブリッジ
【図１】
0003731263.tif 000002
【図２】
0003731263.tif 000003
【図３】
0003731263.tif 000004
【図４】
0003731263.tif 000005
【図５】
0003731263.tif 000006
【図６】
0003731263.tif 000007
【図７】
0003731263.tif 000008
【図８】
0003731263.tif 000009