(57)【要約】      （修正有）【課題】近隣ノード探索方法において、ＳＴＡＬＥ状態で送信する前に送信先ノードのＭＡＣアドレスが変更されると、古いアドレスで送信を行うためにパケットが損失することの回避、また近隣到達不能検出に時間がかかることの回避を行う。【解決手段】ＳＴＡＬＥ状態に滞在する時間に上限を設け、この上限を経過するとＰＲＯＢＥに移行するようにした。また、近隣到達不能検出で送信する近隣要請メッセージをマルチキャストで送信するようにした。ＳＴＡＬＥに滞在する時間が制限されるのでＭＡＣアドレスの変更を検知できる契機が多くなり、パケット損失を回避できる。また、近隣要請メッセージをマルチキャストで送信するので、ＭＡＣアドレスが変更されてもこのメッセージを受信できる。【選択図】図１
2010258972.tif 000002
【特許請求の範囲】
【請求項１】
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記送信の必要性が発生するまで待機する時間に上限ＳｔａｌｅＴｉｍｅを設け、この上限ＳｔａｌｅＴｉｍｅが経過すると、送信の必要性が発生しなくても近隣要請メッセージを送信して近隣到達不能検出を行うようにしたことを特徴とする近隣ノード探索方法。
【請求項２】
前記上限ＳｔａｌｅＴｉｍｅを０としたことを特徴とする請求項１記載の近隣ノード探索方法。
【請求項３】
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記送信の必要性が発生するまで待機する時間に上限ＳｔａｌｅＴｉｍｅを設け、この上限ＳｔａｌｅＴｉｍｅを経過すると近隣到達性に関する情報が格納されている近隣キャッシュをクリアするようにしたことを特徴とする近隣ノード探索方法。
【請求項４】
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記近隣到達不能検出で送信する近隣要請メッセージを、マルチキャストで送信するようにしたことを特徴とする近隣ノード探索方法。
【請求項５】
前記近隣不到達検出で送信する近隣要請メッセージを、マルチキャストで送信するようにしたことを特徴とする請求項１乃至請求項３いずれかに記載の近隣ノード探索方法。
【請求項６】
近隣要請メッセージを送信してアドレス解決を行う近隣ノード探索方法において、
近隣通知メッセージを受信してから所定時間経過後、近隣到達性に関する情報が格納されている近隣キャッシュをクリアするようにしたことを特徴とする近隣ノード探索方法。
【請求項７】
近隣要請メッセージを送信してアドレス解決を行い、アドレス解決に成功すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索装置において、
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する第１の近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力する第１のタイマと、
起動信号によって動作を開始し、上限時間ＳｔａｌｅＴｉｍｅが経過するか、あるいは送信が必要になったことを表す要送信信号が入力されてから一定時間後に停止信号を出力する第２のタイマと、
近隣要請メッセージを送信して近隣到達不能検出を行う第２の近隣探索部と、
送信が必要になると前記第１の近隣探索部を起動させてアドレス解決を行い、この第１の近隣探索部が近隣ノードの探索に成功すると前記第１のタイマを起動させ、この第１のタイマの停止後前記第２のタイマを起動させて、この第２のタイマの停止後に前記第２の近隣探索部を起動して近隣到達不能検出を行う制御部と、
を具備したことを特徴とする近隣ノード探索装置。
【請求項８】
近隣要請メッセージを送信してアドレス解決を行い、アドレス解決に成功すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索装置において、
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する第１の近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力する第１のタイマと、
近隣要請メッセージを送信して近隣到達不能検出を行う第２の近隣探索部と、
送信が必要になると前記第１の近隣探索部を起動させ、この第１の近隣探索部がアドレス解決に成功すると前記第１のタイマを起動させ、この第１のタイマの停止後に前記第２の近隣探索部を起動して近隣到達不能検出を行う制御部と、
を具備したことを特徴とする近隣ノード探索装置。
【請求項９】
前記第２の近隣探索部は、ユニキャストで近隣要請メッセージを送信するようにしたことを特徴とする請求項７若しくは請求項８記載の近隣ノード探索装置。
【請求項１０】
前記第２の近隣探索部は、マルチキャストで近隣要請メッセージを送信するようにしたことを特徴とする請求項７若しくは請求項８記載の近隣ノード探索装置。
【請求項１１】
前記第１の近隣探索部と前記第２の近隣探索部を共用するようにしたことを特徴とする請求項１０記載の近隣ノード探索装置。
【請求項１２】
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力するタイマと、
送信が必要になると前記近隣探索部を起動させ、この近隣探索部がアドレス解決に成功すると前記タイマを起動させ、このタイマが停止すると近隣ノードの情報を格納した近隣キャッシュをクリアする制御部と、
を具備したことを特徴とする近隣ノード探索装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、近隣ノード到達性情報の更新停滞時間を制限し、かつパケット損失を回避することができる近隣ノード探索方法およびその装置に関し、特にＩＰｖ６を用いたフィールドデバイスに用いて好適な近隣ノード探索方法およびその装置に関するものである。
【背景技術】
【０００２】
ＩＰｖ６(Internet Protocol version 6)は従来のインターネットプロトコルＩＰｖ４に対し管理できるアドレス空間を大幅に増大し、かつセキュリティ機能の追加、優先度に応じたデータの送受信などの改良を施した次世代のインターネットプロトコルである。
【０００３】
ＩＰｖ６は、ネットワークのパラメータを自動的に検出して設定するプラグ＆プレイを特徴とし、アドレス解決および近隣到達不能検出を行なう近隣探索はプラグ＆プレイを構成するための主要な機能である。このようなノードは、図１２に示すように、インターフェイス毎に近隣ノードの到達性を管理する近隣キャッシュを具備している。
【０００４】
図１２において、ノード１０にはインターフェイス１１ａ〜１１ｃが配置されている。ノード１０にはこれらインターフェイス１１ａ〜１１ｃのそれぞれに対応する、近隣ノードの到達性を管理する近隣キャッシュ１２ａ〜１２ｃが配置されている。
【０００５】
近隣キャッシュ１２ａ〜１２ｃは近隣ノード毎にエントリを持ち、少なくともノードを識別するノード名と近隣到達性情報が格納されている。近隣到達性情報は当該ノードに送信できるかどうかを表す情報であり、ＩＮＣＯＭＰＬＥＴＥ（情報が不完全）、ＲＥＡＣＨＡＢＬＥ（情報が完全）、ＳＴＡＬＥ（情報が古く不明）、ＤＥＬＡＹ（遅延処理中）、ＰＲＯＢＥ（近隣到達不能検出中）の５種類がある。
【０００６】
次に、図１３のトロポジを有するネットワークを用いて、近隣ノード探索について説明する。図１３はノード２０と２１が同じリンク２２に接続された、最も簡単なネットワークを表している。このネットワークで、ノード２０がノード２１に送信する場合を考える。以下、近隣到達性情報はノード２０が保持する、ノード２１に対する到達性情報である。
【０００７】
図１４は、図１３に示すネットワークにおいて、近隣到達性情報の典型的な遷移を表したフローチャートである。なお、このフローチャートでは、近隣到達性情報のエントリがない状態を「ＮＯＮＥ」で表している。
【０００８】
図１４において、最初はエントリがないので、近隣到達性情報は「ＮＯＮＥ」である（工程（Ｐ１４−１））。工程（Ｐ１４−２）で他のノードへの送信が必要になるまで待機する。すなわち、送信が必要ない（ＮＯ）間は自身でループを形成し、送信が必要になる（ＹＥＳ）と、このループから脱出する。
【０００９】
送信が必要になると、工程（Ｐ１４−３）で近隣到達性情報を「ＩＮＣＯＭＰＬＥＴＥ」にセットし、工程（Ｐ１４−４）で近隣要請メッセージをマルチキャストで送信して、他のノードから近隣通知メッセージが送られてくるのを待つ（工程（Ｐ１４−５））。ノード２０がノード２１に送信するためには、ノード２０はノード２１のＭＡＣ(Media Access Control)アドレスを知る必要がある。そのため、近隣要請メッセージをマルチキャストで送信し、近隣通知メッセージと共にＭＡＣアドレスが返信されるのを待つ。
【００１０】
工程（Ｐ１４−５）で一定時間内に近隣通知メッセージを受信すると（ＹＥＳ）、工程（Ｐ１４−６）で近隣到達性情報を「ＲＥＡＣＨＡＢＬＥ」に遷移させる。ノード２０は近隣通知メッセージと共に送られてきたＭＡＣアドレスを用いて、ノード２１と通信することができる。一定時間内に近隣通知メッセージが返信されないと、工程（Ｐ１４−１６）に移行する。
【００１１】
ＲＥＡＣＨＡＢＬＥ状態には有効期限であるライフタイムが規定されている。このライフタイムをReachableTimeで表す。ReachableTimeは変数であるが、ＲＦＣ(Request for Comments)４８６１では、初期値を１５秒から４５秒までのランダムな値とすることが規定されている。
【００１２】
工程（Ｐ１４−７）でこのReachableTime内であるかどうかを監視し、ReachableTimeが過ぎると、工程（Ｐ１４−８）で近隣到達性情報を「ＳＴＡＬＥ」に遷移させる。「ＳＴＡＬＥ」は、ノード２１の情報が古くなったものであることを表している。
【００１３】
一旦ＳＴＡＬＥ状態に遷移すると、送信の必要が生じるまでこの状態を持続する。工程（Ｐ１４−９）は、送信の必要性が生じるまで待機することを表している。
【００１４】
ノード２１への送信が必要になるとノード２１にメッセージを送信した後、工程（Ｐ１４−１０）で近隣到達性情報を「ＤＥＬＡＹ」に遷移させ、工程（Ｐ１４−１１）で５秒経過するまで待つ。５秒待つのは、上位層のプロトコルが到達性の確認を行う時間を確保するためである。５秒経過すると、工程（Ｐ１４−１２）で近隣到達性情報を「ＰＲＯＢＥ」に遷移させ、近隣到達性を確認する近隣到達不能検出を行う。
【００１５】
近隣到達不能検出を行うため、工程（Ｐ１４−１３）で近隣要請メッセージをユニキャストで送信し、工程（Ｐ１４−１４）で近隣通知メッセージを待つ。工程（Ｐ１４−１３）では対象ノードが判っているので、マルチキャストではなく対象ノードであるノード２１に宛ててユニキャストで近隣要請メッセージを送信する。
【００１６】
工程（Ｐ１４−１４）で一定時間内に近隣通知メッセージを受信すると（ＹＥＳ）、工程（Ｐ１４−６）に移行して近隣到達性情報を「ＲＥＡＣＨＡＢＬＥ」に遷移させる。一定時間内に近隣通知メッセージを受け取らないと工程（Ｐ１４−１５）に遷移し、工程（Ｐ１４−１３）で近隣要請メッセージを送信した回数が３回以上であるかをチェックする。送信回数が３回未満であると（ＮＯ）工程（Ｐ１４−１３）に移行して再度近隣要請メッセージを送信し、３回になる（ＹＥＳ）と近隣到達不能と見なして工程（Ｐ１４−１７）に移行して近隣キャッシュをクリアし、工程（Ｐ１４−１）に戻る。
【００１７】
工程（Ｐ１４−５）で近隣通知メッセージを受信しないときも、同様の操作を行う。近隣通知メッセージを受信しないと工程（Ｐ１４−１６）で近隣要請メッセージの送信回数が３回であるかをチェックし、３回未満（ＮＯ）であると工程（Ｐ１４−４）に戻って再度近隣要請メッセージを送信し、３回に達すると工程（Ｐ１４−１７）に移行し、近隣キャッシュをクリアする。
【００１８】
なお、通信に用いるプロトコルによっては上位層プロトコルで到達性を確認し状態遷移の最適化ができる場合、近隣探索で用いられるメッセージのオプションが異なる場合、近隣通知メッセージのフラグによって状態遷移のパスを異ならせる場合もあるが、近隣到達性情報の各々の状態で行われる挙動は変わらないので、説明を省略する。
【先行技術文献】
【非特許文献】
【００１９】
【非特許文献１】" Neighbor Discovery for IP version 6 (IPv6)", [online] Internet URL: http://tools.ietf.org/html/rfc4861, 2007
【発明の概要】
【発明が解決しようとする課題】
【００２０】
しかしながら、このような近隣ノード探索方法は、送信先ノードのＭＡＣアドレスが変更された時、近隣不能検出の契機が遅れ、近隣不能検出からの復帰の遅れによる送信パケットの損失が生じるという課題があった。
【００２１】
ＩＰｖ６のノードでは、ユニキャストアドレスを設定する際に、通常はＭＡＣアドレスに基づいたアドレスを自身で生成し、自身のインターフェイスに自動的に割り当てるステートアドレスの自動設定が行われる。しかし、ＤＨＣＰｖ６(Dynamic Host Configuration Protocol Version 6)を使用し、また手動設定によって任意のアドレスを割り当てることも可能である。例えば、ネットワーク管理者はノードのハードウエアを交換する際に、ＭＡＣアドレスが変更されるにも拘わらず、特定のユニキャストアドレスを使用し続けることもできる。
【００２２】
前述したように、ノード２０におけるノード２１の近隣到達性情報がＲＥＡＣＨＡＢＬＥになると、ノード２０がＳＴＡＬＥ状態に遷移した後に送信の必要性が生じるまで到達性の確認を行わない。また、ＳＴＡＬＥ状態では、その滞在時間に上限がないのにも拘わらず、メッセージの送信を行った後に到達性の確認を行う。このため、ノード２１のハードウエアが交換されてＭＡＣアドレスが変わった後にノード２０からノード２１への送信が必要になったときは、古いＭＡＣアドレスを用いて送信を行うため、この送信パケットは損失してしまう。
【００２３】
図１５はこのような状態を表した遷移図である。なお、横軸は時間であり、四角で囲まれた文字は近隣到達性情報である。時刻ｔ１で近隣到達性情報がＲＥＡＣＨＡＢＬＥになり、時刻ｔ２でＳＴＡＬＥに遷移した後、時刻ｔ３で送信先のＭＡＣアドレスが変更されたとする。この後、時刻ｔ４で送信が必要になり送信するが、この送信は変更前のＭＡＣアドレスを用いて行われるので、送信パケットは損失する。送信を行った後に近隣到達性情報はＤＥＬＡＹに遷移する。
【００２４】
ノード２０がフィールドデバイスでノード２１がＨＭＩ(Human Machine Interface)であり、ノード２０がノード２１にユニキャストで非定常通信を行っていたとする。このとき、ノード２１のハードウエアが交換されてＭＡＣアドレスが変更された後にノード２１にパケットを送信すると、ノード２０は到達性の確認を行わないで送信するので、この送信パケットは宛先不明で損失する。このパケットが警報のような重要な情報を含むものであった場合、システムの安全性を損なう原因となる可能性がある。
【００２５】
このようなパケットの損失は、図１６に示すような非同一リンクトポロジを有するネットワークでも生じる。図１６は、リンク２４と２６がルータ２５を介して接続され、線路２４にノード２３がリンク２６にノード２７が接続されているネットワークの例である。
【００２６】
ノード２３がノード２７と通信する場合、ルータ２５への到達性を管理する必要がある。ルータ２５のユニキャストアドレスはリンクローカルアドレスであり、ステートレスアドレス自動設定を用いる場合も多いが、手動で任意のアドレスを設定することもある。
【００２７】
通常、ルータ２５はルータ通知メッセージを定期的に送信しているので、ノード２３がホストであればこの通知メッセージを処理することができる。ノード２３は、ルータ通知メッセージに始点リンク層アドレスオプションが含まれているときはこのルータ通知メッセージからルータ２５のＭＡＣアドレスを知ることができるが、始点リンク層アドレスオプションが含まれていないとき、あるいはルータ２５のアドレスが手動で設定されているときはＭＡＣアドレスが得られず、ノード２３が送信したパケットは損失する可能性がある。
【００２８】
また、管理ポリシーによってはルータ通知メッセージの送信を抑制しているネットワークもある。この場合はノード２３がＭＡＣアドレスを学習することができないので、やはりパケットが損失する可能性がある。
【００２９】
すなわち、近隣到達性情報がＲＥＡＣＨＡＢＬＥに遷移した後に到達先までの経路上に位置する近隣ノードのＭＡＣアドレスが変更されたときは、パケットの損失が生じてしまうという課題があった。
【００３０】
図１７は、近隣到達不能検出からの復帰が遅れることを説明した遷移図である。なお、横軸は時間であり、四角で囲まれた文字は近隣到達性情報を表している。また、図１３のネットワークを前提にしている。
【００３１】
図１７において、時刻ｔ５で近隣到達性情報がＳＴＡＬＥになり、その後の時刻ｔ６でノード２１のＭＡＣアドレスが変更されたとする。時刻ｔ７でノード２１に送信する必要性が発生し、ノード２０はパケットを送信する。時刻ｔ６でノード２１のＭＡＣアドレスが変更されているので、このパケットは損失する。
【００３２】
時刻ｔ７でパケットを送信したので、近隣到達性情報はＤＥＬＡＹになり、５秒経過した時刻ｔ８でＰＲＯＢＥに遷移する。ＰＲＯＢＥに遷移すると、ノード２０は古いＭＡＣアドレスを用いて１秒おきに３回近隣要請メッセージを送信する。ノード２１のＭＡＣアドレスが変更されているのでこの近隣要請メッセージはノード２１に届かず、近隣通知メッセージは送信されない。そのため、時刻ｔ９で近隣到達性情報がＮＯＮＥになり、図１４のフローに従って新しい近隣到達性情報を取得する。
【００３３】
近隣要請メッセージはRetransTimerの間隔で送信される。RetransTimer自体は変数であるが、ＲＦＣ４８６１では１秒と規定されている。そのため、送信の必要性が発生してから少なくとも８秒間は古いＭＡＣアドレスで送信するため、ノード２１と通信することができないという課題もあった。
【００３４】
本発明の目的は、送信パケットの損失が生ぜず、かつ近隣到達の不能検出から速やかに復帰できる近隣ノード探索方法およびその装置を実現することにある。
【課題を解決するための手段】
【００３５】
このような課題を達成するために、本発明のうち請求項１記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記送信の必要性が発生するまで待機する時間に上限ＳｔａｌｅＴｉｍｅを設け、この上限ＳｔａｌｅＴｉｍｅが経過すると、送信の必要性が発生しなくても近隣要請メッセージを送信して近隣到達不能検出を行うようにしたものである。ＳＴＡＬＥに滞在する時間が制限されるのでＭＡＣアドレスの変更を検知できる契機が多くなり、パケット損失を回避できる。
【００３６】
請求項２記載の発明は。請求項１記載の発明において、
前記上限ＳｔａｌｅＴｉｍｅを０としたものである。ＭＡＣアドレスの変更を検知できる契機がさらに多くなる。
【００３７】
請求項３記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記送信の必要性が発生するまで待機する時間に上限ＳｔａｌｅＴｉｍｅを設け、この上限ＳｔａｌｅＴｉｍｅを経過すると近隣到達性に関する情報が格納されている近隣キャッシュをクリアするようにしたものである。ＳＴＡＬＥ期間終了後送信の必要性に応じてすぐにアドレス解決を行うので、古いＭＡＣアドレスでパケットを送信することがなくなる。
【００３８】
請求項４記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索方法において、
前記近隣到達不能検出で送信する近隣要請メッセージを、マルチキャストで送信するようにしたものである。ＭＡＣアドレスが変更されていても近隣要請メッセージを受信できるので、近隣到達不能検出の時間を短くすることができる。
【００３９】
請求項５記載の発明は、請求項１乃至請求項３いずれかに記載の発明において、
前記近隣不到達検出で送信する近隣要請メッセージを、マルチキャストで送信するようにしたものである。パケット損失を回避でき、かつ近隣到達不能検出の時間を短くできる。
【００４０】
請求項６記載の発明は、
近隣要請メッセージを送信してアドレス解決を行う近隣ノード探索方法において、
近隣通知メッセージを受信してから所定時間経過後、近隣到達性に関する情報が格納されている近隣キャッシュをクリアするようにしたものである。近隣キャッシュの内容の有効期限が切れると送信の必要性に応じてすぐに新たなアドレス解決を行うので、古いＭＡＣアドレスで送信してパケットが損失することがなくなる。
【００４１】
請求項７記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、アドレス解決に成功すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索装置において、
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する第１の近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力する第１のタイマと、
起動信号によって動作を開始し、上限時間ＳｔａｌｅＴｉｍｅが経過するか、あるいは送信が必要になったことを表す要送信信号が入力されてから一定時間後に停止信号を出力する第２のタイマと、
近隣要請メッセージを送信して近隣到達不能検出を行う第２の近隣探索部と、
送信が必要になると前記第１の近隣探索部を起動させてアドレス解決を行い、この第１の近隣探索部が近隣ノードの探索に成功すると前記第１のタイマを起動させ、この第１のタイマの停止後前記第２のタイマを起動させて、この第２のタイマの停止後に前記第２の近隣探索部を起動して近隣到達不能検出を行う制御部と、
を具備したものである。ＳＴＡＬＥに滞在する時間が制限されるのでＭＡＣアドレスの変更を検知できる契機が多くなり、パケット損失を回避できる。
【００４２】
請求項８記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、アドレス解決に成功すると、所定時間経過後送信の必要性が発生するまで待機し、その後近隣要請メッセージを送信して近隣到達不能検出を行う近隣ノード探索装置において、
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する第１の近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力する第１のタイマと、
近隣要請メッセージを送信して近隣到達不能検出を行う第２の近隣探索部と、
送信が必要になると前記第１の近隣探索部を起動させ、この第１の近隣探索部がアドレス解決に成功すると前記第１のタイマを起動させ、この第１のタイマの停止後に前記第２の近隣探索部を起動して近隣到達不能検出を行う制御部と、
を具備したものである。近隣キャッシュの有効期限が切れるとすぐに近隣到達不能検出を行うので、ＭＡＣアドレスの変更を検知できる契機が多くなり、パケット損失を回避できる。
【００４３】
請求項９記載の発明は、請求項７若しくは請求項８記載の発明において、
前記第２の近隣探索部は、ユニキャストで近隣要請メッセージを送信するようにしたものである。マルチキャストで送信する回数が少なくなるので、ネットワークの負荷を小さくできる。
【００４４】
請求項１０記載の発明は、請求項７若しくは請求項８記載の発明において、
前記第２の近隣探索部は、マルチキャストで近隣要請メッセージを送信するようにしたものである。ＭＡＣアドレスが変更されても、近隣要請メッセージを受信できる。
【００４５】
請求項１１記載の発明は、請求項１０記載の発明において、
前記第１の近隣探索部と前記第２の近隣探索部を共用するようにしたものである。装置の構成を簡単にできる。
【００４６】
請求項１２記載の発明は、
近隣要請メッセージを送信してアドレス解決を行い、その結果を出力する近隣探索部と、
起動信号によって動作を開始し、所定時間が経過すると停止信号を出力するタイマと、
送信が必要になると前記近隣探索部を起動させ、この近隣探索部がアドレス解決に成功すると前記タイマを起動させ、このタイマが停止すると近隣ノードの情報を格納した近隣キャッシュをクリアする制御部と、
を具備したものである。近隣キャッシュの内容の有効期限が切れると送信の必要性に応じてすぐに新たなアドレス解決を行うので、古いＭＡＣアドレスで送信してパケットが損失することがなくなる。
【発明の効果】
【００４７】
本発明によれば以下のような効果がある。
請求項１、２、３、４、５、６、７，８、９、１０、１１、１２の発明によれば、近隣要請メッセージを送信してアドレス解決を行い、近隣通知メッセージを受信すると、近隣キャッシュの情報の有効期限が切れた後、送信の必要性がなくても一定時間後に近隣到達不能検出を行うようにした。また近隣到達不能検出で送信する近隣要請メッセージをマルチキャストで送信するようにした。
【００４８】
送信の必要性が来るまで待つ時間に上限を設けることにより、送信先のＭＡＣアドレスが変更されても、古いＭＡＣアドレスでパケットを送信する可能性を少なくすることができる。そのため、パケット損失を回避することができるという効果がある。
【００４９】
また、長時間送信の必要性を待つことがないので、比較的短い周期でアドレス解決を行うことができる。そのため、送信先のＭＡＣアドレスが変更されてもすぐに新しいＭＡＣアドレスを取得でき、古いＭＡＣアドレスでパケットを送信することがなくなるので、パケット損失を回避できる。送信の必要性があるまで待つ時間の上限を０にすることにより、パケット損失の可能性を更に小さくすることができるという効果がある。
【００５０】
また、送信の必要性が生じるまで待つ時間の上限が経過した後、あるいは近隣キャッシュの内容の有効期限が切れた後近隣キャッシュをクリアすることにより、近隣到達不能検出をスキップすることができる。このため、新しいＭＡＣアドレスをより速やかに取得できるという効果もある。
【００５１】
さらに、近隣到達不能検出で送信する近隣要請メッセージをマルチキャストで送信すると、送信先のＭＡＣアドレスが変更されていてもこのメッセージを受信できるので、近隣到達不能検出に要する時間を短くでき、より速やかに新しいＭＡＣアドレスを得ることができるという効果もある。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施例を示したフローチャートである。
【図２】ユニキャストアドレスから要請ノードマルチキャストアドレスを生成する手順を示した図である。
【図３】マルチキャストアドレスからＭＡＣアドレスを生成する手順を示した図である。
【図４】本発明の効果を説明するための図である。
【図５】本発明の効果を説明するための図である。
【図６】本発明の他の実施例を示したフローチャートである。
【図７】本発明の他の実施例を示したフローチャートである。
【図８】本発明の他の実施例を示したフローチャートである。
【図９】本発明の他の実施例を示した構成図である。
【図１０】本発明の他の実施例を示した構成図である。
【図１１】本発明の他の実施例を示した構成図である。
【図１２】近隣キャッシュを説明するための図である。
【図１３】ネットワークの構成図である。
【図１４】従来の近隣ノード探索方法を示すフローチャートである。
【図１５】従来の課題を説明するための図である。
【図１６】ネットワークの構成図である。
【図１７】従来の課題を説明するための図である。
【発明を実施するための形態】
【００５３】
以下本発明を、図面を用いて詳細に説明する。図１は本発明に係る近隣ノード探索方法の一実施例を示したフローチャートである。この実施例はＳＴＡＬＥ状態にライフタイムを設けることにより、必要以上にＳＴＡＬＥ状態に止まることがないようにし、かつ近隣到達不能検出で送信する近隣要請メッセージをマルチキャストで送信するようにしたものである。
【００５４】
図１において、初期状態（工程（Ｐ１−１））では近隣到達性情報はＮＯＮＥである。工程（Ｐ１−２）で送信の必要性が生じるまで待機し、送信が必要になると、工程（Ｐ１−３）で近隣到達性情報をＩＮＣＯＭＰＬＥＴＥに遷移させ、工程（Ｐ１−４）で近隣要請メッセージをマルチキャストで送信する。
【００５５】
工程（Ｐ１−５）で近隣通知メッセージが送られてくるのを待ち、一定時間内に近隣通知メッセージが送られてこないと工程（Ｐ１−１６）で近隣要請メッセージを３回送信したかをチェックする。
【００５６】
送信回数が３回未満だと工程（Ｐ１−４）に戻って再度近隣要請メッセージを送信する。３回送信しても近隣通知メッセージを受信しないと、工程（Ｐ１−１７）で近隣キャッシュをクリアし、工程（Ｐ１−１）に戻る。工程（Ｐ１−４）、（Ｐ１−５）、（Ｐ１−１６）で近隣探索を行っている。
【００５７】
工程（Ｐ１−５）で近隣通知メッセージを受信すると、工程（Ｐ１−６）で近隣到達性情報をＲＥＡＣＨＡＢＬＥに遷移させる。そして、工程（Ｐ１−７）でReachableTimeが経過するまで待って、工程（Ｐ１−８）で近隣到達性情報をＳＴＡＬＥに遷移させる。
【００５８】
工程（Ｐ１−９）で送信が必要になるのを待ち、送信が必要になると工程（Ｐ１−１０）で近隣到達性情報をＤＥＬＡＹに遷移させる。工程（１−１１）で５秒間待ってから、工程（Ｐ１−１２）で近隣到達性情報をＰＲＯＢＥに遷移させる。ここまでの工程は図１４の従来例と同じである。
【００５９】
この実施例ではStaleTimeを設け、このStaleTimeの間ＳＴＡＬＥ状態に止まっていると、強制的に近隣到達性情報をＰＲＯＢＥに遷移させる。
【００６０】
そのために、工程（Ｐ１−９）で送信が必要でないと判断する（ＮＯ）と、工程（Ｐ１−１８）でＳＴＡＬＥに遷移してからStaleTime時間経過したかをチェックする。StaleTime時間経過していない（ＮＯ）と工程（Ｐ１−９）に戻り、StaleTime時間経過する（ＹＥＳ）と、工程（Ｐ１−１２）にジャンプして近隣到達性情報をＰＲＯＢＥに遷移させる。
【００６１】
工程（Ｐ１−１３）で近隣要請メッセージをマルチキャストで送信して近隣到達不能検出を行う。工程（Ｐ１−１４）で近隣通知メッセージを受信したかをチェックする。近隣通知メッセージを受信する（ＹＥＳ）と工程（Ｐ１−６）に戻り、一定時間内に受信しないと工程（Ｐ１−１５）で近隣要請メッセージを送信した回数をチェックする。
【００６２】
送信回数が３回未満（ＮＯ）だと工程（Ｐ１−１３）に戻って再度近隣要請メッセージを送信し、送信回数が３回になる（ＹＥＳ）と工程（Ｐ１−１７）で近隣キャッシュをクリアして工程（Ｐ１−１）に戻る。工程（Ｐ１−１３）〜（Ｐ１−１５）で近隣到達不能検出を行っている。
【００６３】
従来は送信が必要になるまでＳＴＡＬＥ状態に止まり、送信が必要になると、まず送信を行った後に５秒間待って近隣要請メッセージを送信していた。このため、長時間ＳＴＡＬＥ状態が継続し、その間に送信対象機器のＭＡＣアドレスが変更されると、宛先のないメッセージを送信してしまっていた。
【００６４】
本実施例ではＳＴＡＬＥ状態がStaleTime時間継続すると強制的に近隣到達性情報をＰＲＯＢＥに遷移させて近隣要請メッセージを送信し、近隣到達不能検出を行うようにした。長時間ＳＴＡＬＥ状態に止まることがないので、その間にＭＡＣアドレスが変更される可能性は低い。従って、パケットの損失が生じる危険性を小さくすることができる。
【００６５】
また、従来は近隣要請メッセージをユニキャストで送信していたが、本実施例ではマルチキャストで送信するようにした。そのため、ＭＡＣアドレスが変更されていても近隣要請メッセージを受信できるので、近隣通知メッセージを送信できる。その結果、近隣到達不能検出を短時間で終わらせることができ、かつ新しいＭＡＣアドレスを得ることができる。
【００６６】
なお、マルチキャストで送信するとは、予め決められた複数のノードに対して同時に送信することを言い、ユニキャストで送信するとは、ノードを指定して送信することを言う。
【００６７】
近隣要請メッセージを送信する近隣探索では、近隣到達不能検出だけでなく、アドレス解決にも近隣要請メッセージを使用する。アドレス解決時の送信先マルチキャストアドレスは要請ノードマルチキャストアドレスと呼ばれ、アドレス解決に用いる要請ノードユニキャストアドレスから作成する。
【００６８】
図２に、ユニキャストアドレスから要請ノードマルチキャストアドレスを作成する過程を示す。（Ａ）は元になるユニキャストアドレスであり、１２８ビットの長さを有している。（Ｂ）に示すように、このユニキャストアドレスを上位１０４ビットと下位２４ビットに分割し、（Ｃ）に示すように上位１０４ビットを下記のプリフィックスに置き換えると、（Ｄ）のように要請ノードマルチキャストアドレスが得られる。
プリフィックス：ＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４
【００６９】
例えば、ユニキャストアドレスが、
２００１：ｄｂ８：ｆｆｆｆ：１：２００：２ｆｆ：ｆｅ００：２７ｃｄ
である場合は、要請ノードマルチキャストアドレスは、
ｆｆ０２：：１：ｆｆ００：２７ｃｄ
になる。
【００７０】
マルチキャストによる通信では複数のノードが受信できる必要があるので、受信ノードのＭＡＣアドレスとは異なったアドレスが用いられる。図３にこのアドレスの作成過程を示す。
【００７１】
図３において、（Ａ）のマルチキャストアドレスを（Ｂ）のように上位ビットと下位３２ビットに分割する。そして、（Ｃ）に示すように先頭２バイトが３３：３３であるＭＡＣアドレスに、（Ｂ）で分割した下位３２ビットを加えたものをアドレスとする。
【００７２】
例えば、マルチキャストアドレスが、
ｆｆ０２：：１：ｆｆ００：２７ｃｄ
であると、ＭＡＣアドレスは、
３３：３３：ｆｆ：００：２７：ｃｄ
になる。このようにすることにより、受信ノードの実際のＭＡＣアドレスに依存しないＭＡＣアドレスを生成して用いることができる。
【００７３】
図１３のネットワークにおいて、ノード２１のＭＡＣアドレスが変更された後の近隣到達不検出を行う場合を考える。ＩＰｖ６ノードは、設定されたユニキャストアドレスに対応した要請ノードマルチキャストアドレス宛の通信を必ず聴取している。そのため、ノード２０が要請ノードマルチキャストアドレス宛に近隣要請メッセージを送信すると、ノード２１のＭＡＣアドレスが変更されていても、ノード２０からの近隣要請メッセージを受信することができる。
【００７４】
StaleTimeを設けることによる効果とマルチキャストアドレスを用いた効果を図４に示す。なお、四角で囲んだ文字は近隣到達性情報を表し、横軸は時間である。また、近隣到達性情報がＳＴＡＬＥになるまでの過程は従来と同じなので、記載を省略している。さらに、図１３のネットワークを前提にしている。
【００７５】
図４（Ａ）はStaleTimeを設けることによる効果を説明した図である。なお、近隣到達不能検出では近隣要請メッセージをユニキャストで送信する。時刻ｔ１０で近隣到達性情報がＳＴＡＬＥになり、時刻ｔ１１でノード２１のＭＡＣアドレスが変更されたとする。送信の必要性が発生しないと、時刻ｔ１０からStaleTime経過した時刻ｔ１２で、近隣到達性情報はＰＲＯＢＥに遷移する。
【００７６】
ノード２１のＭＡＣアドレスが変更されているので、近隣通知メッセージは送信されない。近隣到達性情報はＮＯＮＥになり、送信の必要性が発生するとＩＮＣＯＭＰＬＥＴＥに遷移する。ノード２０は近隣要請メッセージを送信し、ノード２１の新しいＭＡＣアドレスを得てＲＥＡＣＨＡＢＬＥに遷移し、メッセージが送信される。ＲＥＡＣＨＡＢＬＥに遷移するまでノード２１を宛先としたパケットは送信されないので、パケットの損失が発生する。
【００７７】
近隣到達性情報がＰＲＯＢＥのときに送信する近隣要請メッセージをマルチキャストで送信するときの効果を図４（Ｂ）に示す。時刻ｔ１３で近隣到達性情報がＳＴＡＬＥに遷移し、その後の時刻ｔ１４でノード２１のＭＡＣアドレスが変更されたとする。送信の必要性が発生しなかったために時刻ｔ１５で近隣到達性情報がＤＥＬＡＹに遷移し、その５秒後の時刻ｔ１６でＰＲＯＢＥに遷移する。
【００７８】
ＰＲＯＢＥに遷移すると近隣要請メッセージが送信されるが、このメッセージはマルチキャストアドレスで送信されるので、ＭＡＣアドレスが変更されているノード２１で受信できる。そのため、ノード２１は近隣通知メッセージを送信するので、近隣到達性情報はすぐにＲＥＡＣＨＡＢＬＥに遷移する。また、このときノード２１の新しいＭＡＣアドレスを知ることができる。
【００７９】
図５に、StaleTimeを設け、かつ近隣要請メッセージをマルチキャストアドレスで送信したときの効果を示す。時刻ｔ１７で近隣到達性情報がＳＴＡＬＥに遷移し、その後のｔ１８でノード２１のＭＡＣアドレスが変更されるとする。
【００８０】
StaleTimeが設定されているので、時刻ｔ１７からStaleTime後の時刻ｔ１９で近隣到達性情報がＰＲＯＢＥになり、近隣要請メッセージがマルチキャストアドレスで送信される。ノード２１のＭＡＣアドレスは変更されているが、マルチキャストで送信されるので、ノード２１は近隣要請メッセージを受信でき、近隣通知メッセージを送信する。このため、近隣到達性情報はすぐにＲＥＡＣＨＡＢＬＥに遷移する。
【００８１】
すなわち、近隣到達性情報がＳＴＡＬＥになってからStaleTime後には新しいＭＡＣアドレスを得て、近隣到達性情報が再びＲＥＡＣＨＡＢＬＥに遷移する。時刻ｔ２０で送信の必要性が発生すると、新しいＭＡＣアドレスでパケットを送信できる。この実施例ではＳＴＡＬＥで停滞して送信が遅れることがなく、かつ古いＭＡＣアドレスは使用しないので、パケットが損失することもない。
【００８２】
図６は、図１実施例でStaleTimeを０にしたときのフローチャートである。なお、図１に対応する工程には同じ符号を付し、説明を省略する。
【００８３】
StaleTimeが０なので、近隣到達性情報は実質的にＳＴＡＬＥにならず、かつＤＥＬＡＹ状態もスキップされる。ReachableTimeが経過するとすぐに近隣到達性情報がＰＲＯＢＥになり、近隣到達不能検出が開始される。近隣要請メッセージはマルチキャストで送信されるので、ＭＡＣアドレスが変更されていても近隣要請メッセージを受信できるので、すぐに近隣通知メッセージが送信され、新しいＭＡＣアドレスを得ることができる。当然のことながら、パケット損失は発生しない。
【００８４】
図７に本発明の他の実施例を示す。この実施例はStaleTimeが経過すると近隣キャッシュをクリアするようにしたものである。なお、図１と同じ要素には同一符号を付し、説明を省略する。
【００８５】
図７において、工程（Ｐ７−１）は、図１の工程（Ｐ１−１８）の代わりに用いられる。工程（Ｐ７−１）は、工程（Ｐ１−９）で送信が必要にならないときに実行される。工程（Ｐ７−１）では、近隣到達性情報がＳＴＡＬＥに遷移してからStaleTime経過したかどうかをチェックし、経過していないと工程（Ｐ１−９）に戻り、経過すると工程（Ｐ１−１７）に移行して近隣キャッシュをクリアする。
【００８６】
このようにすると、ＳＴＡＬＥ状態において、StaleTimeの間送信の必要性が発生しないとＰＲＯＢＥに遷移しないで近隣キャッシュをクリアするので、パケット損失を回避することができる。
【００８７】
図８は、図７実施例においてStaleTimeを０にしたときのフローチャートである。なお、図７と同じ要素には同一符号を付し、説明を省略する。
【００８８】
StaleTimeが０なので、図７の工程（Ｐ７−１）はすぐにＹＥＳになる。このため、工程（Ｐ１−８）〜（Ｐ１−１５）、および工程（Ｐ７−１）は実質的に実行されない。ReachableTimeが経過すると直ちに工程（Ｐ１−１７）に移行し、近隣キャッシュがクリアされる。このようにすると、パケット損失の危険性を更に小さくすることができる。この実施例は近隣到達性情報がＰＲＯＢＥに遷移する経路がないので、近隣到達不能検出は実行されない。
【００８９】
なお、図１実施例ではＳＴＡＬＥでStaleTimeを設け、かつ近隣到達不能検出では近隣要請メッセージをマルチキャストで送信するようにしたが、どちらか一方のみ用いてもよい。すなわち、StaleTimeを設けて近隣到達不能検出で近隣要請メッセージをユニキャストで送信し、StaleTimeを設けないでマルチキャストで送信するようにしてもよい。
【００９０】
また、これらの実施例では近隣到達性情報をＮＯＮＥ、ＩＮＣＯＭＰＬＥＴＥ、ＲＥＡＣＨＡＢＬＥ、ＳＴＡＬＥ、ＤＥＬＡＹ、ＰＲＯＢＥと遷移させて管理するようにしたが、必ずしもこの方法を用いる必要はない。近隣ノードに送信できる可能性を管理できるのであれば、他の方法を用いてもよい。
【００９１】
図９は本発明に係る近隣ノード探索装置の一実施例を示す構成図である。この実施例は図１フローチャートに対応するものである。
【００９２】
図９において、近隣ノード探索装置は制御部３０、近隣探索部３１および３４、タイマ３２および３３で構成される。近隣探索部３１、３４はそれぞれ第１、第２の近隣探索部に相当し、タイマ３２、３３はそれぞれ第１、第２のタイマに相当する。
【００９３】
近隣探索部３１は、制御部３０が出力する送信指示が入力されると図１フローチャートの工程（Ｐ１−４）、（Ｐ１−５）、（Ｐ１−１６）を実行し、その結果を制御部３０に出力する。工程（Ｐ１−４）、（Ｐ１−５）、（Ｐ１−１６）は近隣探索を行う工程である。
【００９４】
制御部３０から起動信号が入力されると、近隣探索部３１は近隣要請メッセージをマルチキャストで送信して、一定時間近隣通知メッセージが送られてくるのを待つ動作を繰り返す。近隣通知メッセージを受信すると、この受信した近隣通知メッセージを制御部３０に出力して動作を停止する。一定回数（例えば３回）近隣要請メッセージを送信しても近隣通知メッセージを受信しないと、その旨を制御部３０に出力して動作を停止する。
【００９５】
タイマ３２は、図１フローチャートの工程（Ｐ１−７）でReachableTime経過したかどうかを計測するタイマである。タイマ３２は制御部３０の起動信号によって動作を開始し、タイムアップすると停止信号を制御部３０に出力する。
【００９６】
タイマ３３は、図１フローチャートの工程（Ｐ１−９）、（Ｐ１−１１）および（Ｐ１−１８）を実行する。制御部３０からの起動信号が入力されると、タイマ３３は動作を開始する。制御部３０から送信が必要になったことを表す要送信信号が入力されると、（たとえば５秒待機した後）停止信号を制御部３０に出力して動作を停止する。要送信信号の入力がなく、StaleTimeが経過すると、制御部３０に停止信号を出力して動作を停止する。
【００９７】
近隣探索部３４は、図１フローチャートの工程（Ｐ１−１３）〜（Ｐ１−１５）を実行し、その結果を制御部３０に出力する。工程（Ｐ１−１３）〜（Ｐ１−１５）は近隣到達不能検出を行う工程である。
【００９８】
制御部３０から起動信号が入力されると、近隣探索部３４は近隣要請メッセージをマルチキャストで送信して、一定時間近隣通知メッセージが送られてくるのを待つ動作を繰り返す。近隣通知メッセージを受信すると、この受信した近隣通知メッセージを制御部３０に出力して動作を停止する。一定回数（例えば３回）近隣要請メッセージを送信しても近隣通知メッセージを受信しないと、その旨を制御部３０に出力して動作を停止する。
【００９９】
制御部３０はその内部に近隣キャッシュを具備し、近隣探索部３１および３４、タイマ３２および３３を制御して、図１のフローを実現する。
【０１００】
最初に、近隣到達性情報をＮＯＮＥにして（工程（Ｐ１−１））、送信が必要になるまで待機する（工程（Ｐ１−２））。送信が必要になると近隣到達性情報をＩＮＣＯＭＰＬＥＴＥに遷移させ（工程（Ｐ１−３））、近隣探索部３１に起動信号を出力する。
【０１０１】
近隣探索部３１から近隣通知メッセージを受信したとの通知を受けると、近隣到達性情報をＲＥＡＣＨＡＢＬＥに遷移させ（工程（Ｐ１−６））、タイマ３２を起動する。近隣通知メッセージを受信しなかったとの通知を受けると近隣キャッシュをクリアし（工程（Ｐ１−１７））、近隣到達性情報をＮＯＮＥに遷移させる（工程（Ｐ１−１）に戻る）。
【０１０２】
タイマ３２から停止信号を受けると、近隣到達性情報をＳＴＡＬＥに遷移させ（工程（Ｐ１−８））、タイマ３３を起動する。タイマ３３から停止通知を受ける前に送信の必要性が発生すると近隣到達性情報をＤＥＬＡＹに遷移させ（工程（Ｐ１−１０））、タイマ３３に要送信信号を出力する。
【０１０３】
タイマ３３から停止信号を受けると、近隣到達性情報をＰＲＯＢＥに遷移させて（工程（Ｐ１−１２））、近隣探索部３４に起動信号を出力する。
【０１０４】
近隣探索部３４から近隣通知メッセージを受信したとの通知を受けると、近隣到達性情報をＲＥＡＣＨＡＢＬＥに遷移させてタイマ３２を起動する（工程（Ｐ１−６）に戻る）。近隣通知メッセージを受信しなかったとの通知を受けると近隣キャッシュをクリアし（工程（Ｐ１−１７））、近隣到達性情報をＮＯＮＥに遷移させる（工程（Ｐ１−１）に戻る）。
【０１０５】
なお、タイマ３３がStaleTime経過したことを通知してきたときに、近隣キャッシュをクリアして、近隣到達性情報をＮＯＮＥにするようにしてもよい。このようにすると、図７フローチャートに対応する動作を実現できる。
【０１０６】
また、近隣探索部３４は、近隣要請メッセージをユニキャストで送信するようにしてもよい。近隣要請メッセージをマルチキャストで送信するときは、近隣探索部３１と３４を共用することもできる。
【０１０７】
図１０に、本発明に係る近隣ノード探索装置の他の実施例の構成を示す。この実施例は図６フローチャートに対応するものである。なお、図９と同じ要素には同一符号を付し、説明を省略する。図１０において、４０は近隣探索部３１および３４、タイマ３２を制御する制御部である。
【０１０８】
前述したように、図６フローチャートは図１フローチャートでStaleTimeを０にしたものである。このため、近隣到達性情報がＳＴＡＢＬＥになることはないので、タイマ３３は用いない。
【０１０９】
送信の必要性が発生すると、制御部４０は近隣到達性情報をＩＮＣＯＭＰＬＥＴＥにして近隣探索部３１に起動信号を出力する。近隣通知メッセージを受信したとの通知があると近隣到達性情報をＲＥＡＣＨＡＢＬＥに遷移させ、タイマ３２を起動する。タイマ３２から停止通知を受けると、近隣探索部３４を起動させる。
【０１１０】
この実施例でも近隣探索部３４は、近隣要請メッセージをユニキャストで送信するようにしてもよい。近隣要請メッセージをマルチキャストで送信するときは、近隣探索部３１と３４を共用することもできる。
【０１１１】
図１１に、本発明に係る近隣ノード探索装置の他の実施例を示す。この実施例は、図８フローチャートに対応するものである。なお、図９と同じ要素には同一符号を付し、説明を省略する。図１１において、５０は制御部であり、近隣探索部３１とタイマ３２を制御する。
【０１１２】
前述したように、図８フローチャートはReachableTimeが経過すると近隣キャッシュをクリアするようにしたものである。従って、近隣到達性情報はＳＴＡＬＥ、ＤＥＬＡＹ、ＰＲＯＢＥのいずれにも遷移しない。このため、タイマ３３と近隣探索部３４は使用しない。
【０１１３】
送信の必要性が発生すると、制御部５０は近隣到達性情報をＩＮＣＯＭＰＬＥＴＥにして近隣探索部部３１を起動する。近隣通知メッセージを受信したとの通知があると近隣到達性情報をＲＥＡＣＨＡＢＬＥに遷移させ、タイマ３２を起動する。タイマ３２からの停止信号が入力されると、近隣キャッシュをクリアし、近隣到達性情報をＮＯＮＥに遷移させる。
【０１１４】
なお、これらの実施例では制御システムに用いるとして説明したが、その他のネットワークシステムに適用してもよい。
【０１１５】
また、ReachableTime、StaleTime、ＤＥＬＡＹ状態で待機する時間は、これらの実施例に限られることはなく、任意に設定できる。
【符号の説明】
【０１１６】
１０、２０、２１、２３、２７  ノード
１１ａ〜１１ｃ  インターフェイス
１２ａ〜１２ｃ  近隣キャッシュ
２２、２４、２６  リンク
２５  ルータ
３０、４０、５０  制御部
３１、３４  近隣探索部
３２、３３  タイマ
ｔ１０〜ｔ２０  時刻
【図１】
2010258972.tif 000003
【図２】
2010258972.tif 000004
【図３】
2010258972.tif 000005
【図４】
2010258972.tif 000006
【図５】
2010258972.tif 000007
【図６】
2010258972.tif 000008
【図７】
2010258972.tif 000009
【図８】
2010258972.tif 000010
【図９】
2010258972.tif 000011
【図１０】
2010258972.tif 000012
【図１１】
2010258972.tif 000013
【図１２】
2010258972.tif 000014
【図１３】
2010258972.tif 000015
【図１４】
2010258972.tif 000016
【図１５】
2010258972.tif 000017
【図１６】
2010258972.tif 000018
【図１７】
2010258972.tif 000019