JP2000307625A - 通信方法及び通信装置 - Google Patents

Abstract

(57)【要約】 【課題】 ブリッジタイプのフィードを使用して双方向
通信を実現できるようにする。また、ＵＤＬネットワー
クに接続されたレシーバの様な機器の負荷を軽減する。 【解決手段】 片方向の通信回線を利用したインターネ
ットの通信を行う場合に、その通信回線へのデータの送
出側で、通信回線に送出すべきＩＰデータグラムを受信
するインターフェース５ｂを備えると共に、ＵＤＬＲと
しての双方向通信を行うための、通信回線の受信側から
送出側への仮想的な通信経路を実現するためのインター
フェース１２を備えるようにした。また、フィードに所
定のインターフェースから入力されたパケットの宛先を
判断し、その判断したパケットの宛先からそのパケット
がどのインターフェースの先にあるネットワークに送ら
れるべきかを判断し、転送が必要な場合のみに所定のイ
ンターフェースから転送を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えば衛星回線な
どの片方向の通信回線を使用して、インターネットの通
信を行う通信方法及びその通信方法に適用される通信装
置に関する。

【０００２】

【従来の技術】ある通信回線を流れるＩＰデータグラム
（ＩＰ ｄａｔａｇｒａｍ）を、衛星回線のような片方
向の通信回線に対して転送する通信機器（送出機）を、
フィード（Ｆｅｅｄ）と呼ぶ。フィードは、転送の際
に、ある通信回線を流れてきたデータを片方向の通信回
線に流すためのメディア変換（エンコード）を行う。フ
ィードには、ルータとしての実装と、ブリッジとしての
実装が考えられている。ルータとしてのフィードには、
片方向の通信回線を双方向の通信回線に見せかけるため
の技術であるＵＤＬＲ（Ｕｎｉ−Ｄｉｒｅｃｔｉｏｎａ
ｌ Ｌｉｎｋ Ｒｏｕｔｉｎｇ）を実装しているものが
ある（ＵＤＬＲについては、Ｉｎｔｅｒｎｅｔ−Ｄｒａ
ｆｔ：ｄｒａｆｔ−ｉｅｔｆ−ｕｄｌｒ−ｌｌｔｕｎｎ
ｅｌ−０１．ｔｘｔを参照）。

【０００３】フィードがルータである場合を図２３に示
す。この場合は、双方向の通信回線３を流れるＩＰデー
タグラムを、そのＩＰデータグラムの宛先アドレスによ
ってフィード１ａが選択的にエンコードし、片方向の通
信回線２に対して転送する。この場合、フィード１ａは
片方向の通信回線２に対するインターフェース４ａと、
双方向の通信回線３に対するインターフェース５ａの２
つのインターフェースを持つが、その２つのインターフ
ェースは異なるネットワークに属することになる。

【０００４】一方、フィードがブリッジである場合を図
２４に示す。この場合は、ルータの機能を実現する部分
をフィードから取り除いて汎用のルータ６に任せ、エン
コードのための装置としてフィード１ｂを用いることが
できる。この場合、フィード１ｂは片方向の通信回線に
対するインターフェース４ｂと、ルータ６に対するイン
ターフェース５ｂの２つのインターフェースを持つが、
その２つのインターフェースは同一のネットワークに属
することになる。

【０００５】また、ＵＤＬＲとしての双方向通信をサポ
ートした、ブリッジタイプのフィードの別の構成を図２
５に示す。フィード１０１は少なくとも３つのネットワ
ークインターフェースを持つ。それらのインターフェー
スを、ここではローカルＩ／Ｆ１０２，ＵＤＬ Ｉ／Ｆ
１０３，トンネルＩ／Ｆ１０４と呼ぶことにする。ロー
カルＩ／Ｆ１０２は、双方向のネットワークインターフ
ェースで、このＩ／Ｆが接続されているネットワーク
を、ローカルネットワーク１０５と呼ぶ。ＵＤＬＩ／Ｆ
１０３は、送信専用の片方向のネットワークインターフ
ェースで、このＩ／Ｆが接続されているネットワーク
を、ＵＤＬネットワーク１０６と呼ぶ。トンネルＩ／Ｆ
１０４は、双方向のネットワークインターフェースで、
このＩ／Ｆが接続されているネットワークを、トンネル
（Ｔｕｎｎｅｌ）ネットワーク１０７と呼ぶ。ここで、
ローカルネットワーク１０５と、ＵＤＬネットワーク１
０６は、同じネットワークアドレス１０８を持つ。ま
た、トンネルネットワーク１０７は、ローカルネットワ
ーク１０５や、ＵＤＬネットワーク１０６とは、異なる
ネットワークアドレス１０９を持つ。

【０００６】フィード１０１の主要な機能は、図２６の
フローチャートに示すように、ローカルネットワーク１
０５を流れるパケットを全て受信し（Ｓ２０１）、その
パケットをＵＤＬＩ／Ｆ１０３からＵＤＬネットワーク
１０６へ転送することである（Ｓ２０２）。これをパケ
ット転送機能１１０と呼ぶ。

【０００７】またフィード１０１の他の機能として、Ｕ
ＤＬＲとしての双方向通信を実現するために、図２８に
示すように、トンネルＩ／Ｆ１０４からＧＲＥパケット
１１１（ＲＦＣ１７０１参照）と呼ばれる、他のパケッ
ト１１２をＩＰデータグラム内にカプセル化したパケッ
トを受信し（Ｓ４０１）、ＧＲＥパケット１１１がフラ
グメントされているかどうかを調べる（Ｓ４０２）、も
しＧＲＥパケット１１１がフラグメント化されていたら
再生構築の処理を行い（Ｓ４０３）、その後にＧＲＥパ
ケット１１１にカプセル化されていたパケット１１２を
取り出し（Ｓ４０４）、その取り出したパケット１１２
のコピーを２つ作成し（Ｓ４０５）、１つをローカルＩ
／Ｆ１０２からローカルネットワーク１０５へ、もう１
つをＵＤＬ Ｉ／Ｆ１０３からＬＤＬネットワーク１０
６へと送出する（Ｓ４０６）という機能がある。これを
ＵＤＬＲ機能１１３と呼ぶ。このＵＤＬＲ機能１１３が
実行される構成を図２７に示す。

【０００８】

【発明が解決しようとする課題】フィードをルータから
ブリッジにすると、フィードの機能を減らし、実装を簡
単にすることができるが、その反面、片方向の通信回線
を双方向の通信回線に見せかけるための技術であるＵＤ
ＬＲを実現できなくなる。これは、図２９を参照して説
明すると、片方向の通信回線における受信側のルータ７
ａから、片方向の通信回線における送信側のルータ８
や、片方向の通信回線における他の受信側のルータ７ｂ
への、仮想的に片方向の通信回線を逆方向に用いたＩＰ
データグラムの送信（９ａや９ｂ）ができなくなるから
である。その理由を以下に説明する。

【０００９】片方向の通信回線における受信側のルータ
７ａから、片方向の通信回線における送信側のルータ８
や、片方向の通信回線における他の受信側のルータ７ｂ
へ、仮想的に片方向の通信回線を逆方向に用いてＩＰデ
ータグラムを送信する時は、送信したいＩＰデータグラ
ムをＧＲＥ（ＲＦＣ１７０１参照）を用いて他のＩＰデ
ータグラム内にカプセル化して、主に地上回線などの双
方向の通信回線を用いて送信する。その際、図３０のよ
うに、送信したいＩＰデータグラム１６を新たなＩＰデ
ータグラム１５のデータ部分として埋め込んで送信する
のだが、その新たなＩＰデータグラムの宛先アドレス２
６には、送信側でＵＤＬＲを実現する機器（つまりフィ
ード）のＩＰアドレスが入る。

【００１０】フィードがこのカプセル化されたＩＰデー
タグラム１５を受信するには、フィードのＩＰアドレス
を宛先アドレス２６として持つＩＰデータグラムが、地
上回線などの双方向の通信回線を経由してフィードに送
られるようにルーティングされる必要がある。図３１の
ように、フィードがルータの場合は、フィード１ａにお
ける双方向の回線側のインターフェース５ａのＩＰアド
レスを宛先アドレスにしておけば、ＧＲＥパケットは問
題なくルーティングされて、経路１０ａを通ってフィー
ドに届く。この場合、片方向の通信回線における受信側
のルータ７ａから、片方向の通信回線における送信側の
ルータ８への、仮想的に片方向の通信回線を逆方向に用
いたＩＰデータグラムの送信９ａは、実際には図３２の
経路１１ａを経由して行われる。また、片方向の通信回
線における受信側のルータ７ａから、片方向の通信回線
における他の受信側のルータ７ｂへの、仮想的に片方向
の通信回線を逆方向に用いたＩＰデータグラムの送信９
ｂは、実際には図３３に示す経路１１ｂを経由して行わ
れる。

【００１１】しかし、図３４に示すように、フィードが
ブリッジの場合は、フィード１ｂは片方向の通信回線に
おける送信側のルータ７ａから見て片方向の通信回線２
側に位置するため、フィード１ｂのインターフェース
（４ｂと５ｂ）は片方向の通信回線２に与えられたネッ
トワークアドレスに属するＩＰアドレスを持つことにな
る。すると、片方向の通信回線における受信側のルータ
７ａからこのＩＰアドレスに向けてＩＰデータグラムを
送信すると、地上回線などの双方向の通信回線３に向け
てではなく、片方向の通信回線２に向けて送信するよう
にルーティングされてしまう（１０ｂ）。片方向の回線
の性質上、この経路１０ｂは実現しないのでＩＰデータ
グラムは送信されることはなく、その結果、ＵＤＬＲを
実現することはできなくなってしまう。

【００１２】次に、フィードと他の機器との接続に関す
る問題について説明する。フィードと他の機器との接続
形態の一例を図３５に示す。ローカルネットワーク１０
５には、フィード１０１以外に、ルータ１１４や、ホス
ト１１５が繋がっている。ＵＤＬネットワーク１０６に
は、受信専用のインターフェース１１６を持つ受信装置
であるレシーバ１１７が繋がっている。トンネルネット
ワーク１０７には、ルータ１１８が繋がっている。ルー
タ１１８はルータ１１４と同一のルータでも構わない
が、その場合はローカルネットワーク１０５とトンネル
ネットワーク１０７とは異なるインターフェースを用い
て接続されているものとする。従来では、図３６に示す
ように、ローカルネットワーク１０５を経由してルータ
１１４とホスト１１５の間の通信を行うと、その送信に
より伝送されるパケット１１９は、フィード１０１のパ
ケット転送機能１１０により、ＵＤＬネットワーク１０
６にも伝送される。ここでＵＤＬネットワーク１０６に
転送されたパケットをパケット１２０とする。しかし、
パケット１２０は、受け取る機器が存在しないパケット
である。このようなパケットがＵＤＬネットワーク１０
６を流れることは、ＵＤＬネットワーク１０６の帯域を
無駄遣いすることになる。また、ＵＤＬネットワーク１
０６を接続されたレシーバ１１７のような機器では、こ
の不要なパケット１２０をフィルタリングによって破棄
するといった作業を行うことになり、ＣＰＵなどの資源
を無駄に使うことになってしまう。

【００１３】また、図３７に示すように、トンネルネッ
トワーク１０７から受け取ったＧＲＥパケット１１１に
カプセル化されていたパケット１１２が、ルータ１１４
やホスト１１５などのローカルネットワーク１０５に接
続されている機器宛のものであった場合も、フィード１
０１のＵＤＬＲ機器１１３により、パケット１１２のコ
ピーがＵＤＬネットワーク１０６に伝送されてしまう。
このＵＤＬネットワーク１０６を流れるパケット１１２
のコピーを、パケット１２１とする。パケット１２１も
パケット１２０と同様に受け取る機器が存在しないパケ
ットであり、このようなパケットがＵＤＬネットワーク
１０６を流れることは、ＵＤＬネットワーク１０６の帯
域を無駄遣いすることになる。また、ＵＤＬネットワー
ク１０６に接続されたレシーバ１１７のような機器で
は、この不要なパケット１２１をフィルタリングによっ
て破棄するといった作業を行うことになり、ＣＰＵなど
の資源を無駄に使うことになってしまう。

【００１４】本発明の第１の目的は、ブリッジタイプの
フィードを使用して双方向通信を実現できるようにする
ことにある。

【００１５】本発明の第２の目的は、上述したパケット
１２０やパケット１２１のような不要なパケットを、フ
ィードができるだけ生成しないようにし、ＵＤＬネット
ワークの帯域を有効に利用できるようにし、また、ＵＤ
Ｌネットワークに接続されたレシーバの様な機器の負荷
を軽減することにある。

【００１６】

【課題を解決するための手段】第１の発明は、片方向の
通信回線を利用したインターネットの通信を行う場合
に、上記通信回線へのデータの送出側で、上記通信回線
に送出すべきＩＰデータグラムを受信する経路を設定す
ると共に、ＵＤＬＲとしての双方向通信を行うための、
上記通信回線の受信側から上記送出側への仮想的な通信
経路を実現するための経路を別に設定するようにしたも
のである。

【００１７】第１の発明によると、ブリッジタイプのフ
ィードで、ＵＤＬＲとしての双方向通信を実現すること
ができるようになる。

【００１８】第２の発明は、片方向の第１の通信回線に
データを送出するブリッジタイプの送出手段に、双方向
通信が可能な第２の通信回線を接続して第１の通信回線
で仮想的に双方向通信を行う場合に、送信手段に所定の
インターフェースから入力されたパケットの宛先を判断
し、その判断したパケットの宛先からそのパケットかど
のインターフェースの先にあるネットワークに送られる
べきかを判断し、転送が必要な場合のみに所定のインタ
ーフェースから転送を行うようにしたものである。

【００１９】第２の発明によると、ＵＤＬＲのような双
方向通信をサポートしたブリッジタイプのフィードが、
そのフィードに繋がる双方向の通信回線を流れるパケッ
トのうち、片方向の通信回線へ転送する必要のないパケ
ットを、片方向の通信回線へ転送してしまう回数を減ら
すことができる。

【００２０】

【発明の実施の形態】以下、本発明の第１の実施の形態
を、図１〜図１１を参照して説明する。この第１の実施
の形態で説明する図１〜図１１において、従来例として
説明した図２３，図２４，図２９〜図３４に対応する部
分には同一符号を付し、その詳細説明は省略する。

【００２１】第１の実施の形態における基本的な処理と
しては、図１に示すように、ブリッジタイプのフィード
に新たに第３のインターフェース１２を追加し、３つの
インターフェースを持つフィード１ｃにするというもの
である。この新たなインターフェース１２は、ＧＲＥパ
ケットを受け取るために利用する双方向のインターフェ
ースである。インターフェース１２は、図２に示すよう
に、インターフェース５ｂが繋がっているルータ６のイ
ンターフェースのうち、フィード１ｃのインターフェー
ス５ｂが繋がっているインターフェース１３ａとは別の
インターフェース１３ｂに繋げても良い。また、図３に
示すように、ルータ６とは別のルータ１４に繋げても良
い。いずれの場合も、インターフェース１２は、インタ
ーフェース４ｂやインターフェース５ｂとは異なるネッ
トワークアドレスに属するＩＰアドレスを持つ。

【００２２】このようにフィードを構成すると、図４に
示すように、片方向の通信回線における受信側のルータ
７ａから、フィード１ｃへＧＲＥパケットの送信を行う
と、宛先アドレス２６にインターフェース１２のＩＰア
ドレスを指定することで、そのＧＲＥパケットはルータ
６（または図３に示す構成の場合はルータ１４）を経由
して、経路１０ｃを通って、インターフェース１２から
フィード１ｃに届くようになる。

【００２３】ＧＲＥパケットを受け取った後は、フィー
ド１ｃは図５に示すような動作をするものとする。即
ち、フィード１ｃは、インターフェース１２に届いたＧ
ＲＥパケット１５からカプセル化されたＩＰデータグラ
ム１６を取り出し、その取り出したＩＰデータグラム１
６のコピーを２つ作成し、１つはインターフェース４ｂ
から片方向の通信回線２へ、もう１つのコピーはインタ
ーフェース５ｂからルータ６への通信経路１７へと送出
する。

【００２４】これにより、ブリッジタイプのフィードで
も仮想的に片方向の通信経路に逆方向にＩＰデータグラ
ムを送信することが出来るようになり、ＵＤＬＲとして
の双方向通信が実現できるようになる。

【００２５】例えば、片方向の通信回線における受信側
のルータ７ａから、片方向の通信回線における送信側の
ルータ６への、仮想的に片方向の通信回線を逆方向に用
いたＩＰデータグラムの送信（９ａ）は、実際には図６
に示す経路１８ａを経由して行われる。また、片方向の
通信回線における受信側のルータ７ａから、片方向の通
信回線における他の受信側のルータ７ｂへの、仮想的に
片方向の通信回線を逆方向に用いたＩＰデータグラムの
送信（９ｂ）は、実際には図７に示す経路１８ｂを経由
して行われる。

【００２６】以下に、本実施の形態における片方向の通
信回線として、衛星回線を用いた通信システムの構成を
説明する。図８は、本実施の形態によるフィードを用い
た実際のシステム構成を示すものである。これは、片方
向の通信回線２を衛星回線１９にし、双方向の通信回線
３を、地上回線を用いたインターネットやイントラネッ
ト２０としたものである。ここでは、フィード１ｃは図
２に示した例と同様に、２つのインターフェース（５ｂ
と１２）が同一のルータ６につながる構成になってい
る。

【００２７】図８の例では、片方向の通信回線２へのイ
ンターフェース４ｂは、ＤＶＩ−ＡＳＩのようなＭＰＥ
Ｇ２トランスポートストリームを出力するインターフェ
ースである。フィード１ｃは、ＩＰデータグラムをＤＶ
Ｂ及びＤＡＶＩＣで標準化されているフォーマット（Ｍ
ｕｌｔｉｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｉｏ
ｎフォーマットなど）を用いてＭＰＥＧ２トランスポー
トストリームにエンコードし、インターフェース４ｂか
らマルチプレクサ２１に対して出力する。また、インタ
ーフェース５ｂやインターフェース１２は、１０ｂａｓ
ｅＴや１００ｂａｓｅＴＸなどのイーサネットインター
フェースであり、イーサネットでルータ６と接続されて
いる。

【００２８】図８に示す構成のシステムにおいて、フィ
ード１ｃを図３のように異なるルータ（６と１４）に接
続する構成に変更したものが、図９に示した例のシステ
ムである。

【００２９】図８や図９に示した例では、衛星回線の受
信機であるレシーバ２２はルータとなっているが、フィ
ードがルータとブリッジの両方の実装方法があるのと同
様に、レシーバも、ルータではなくブリッジとして実装
することができる。図１０に示した例は、図８に示した
構成のシステムから、レシーバをルータ２２からブリッ
ジ２３に変更したものである。

【００３０】フィードは、ネットワーク機器であり、Ｉ
Ｐアドレスなどの設定を適切に行う必要がある。フィー
ドの設定は、テレネット（ｔｅｌｎｅｔ）などを用いて
ネットワーク経由で行うことができれば便利である。本
実施の形態におけるＵＤＬＲとしての双方向通信が可能
なブリッジタイプのフィード１ｃには、３つのインター
フェース（４ｂ，５ｂ，１２）が存在するが、これはい
ずれもフィードとしての機能を実現するためのものであ
り、このいずれかをフィードの設定用に用いると、フィ
ードの本来の機能に悪影響を与えることも考えられる。
そのような場合の為に、図１１のように、フィード設定
用の第４のインターフェース２４を別に持つと安全であ
る。インターフェース２４は、１０ｂａｓｅＴや１００
ｂａｓｅＴＸなどのイーサネットのインターフェース
や、ＲＳ２３２Ｃなどのシリアル通信のインターフェー
スなどで、パソコンなどの設定端末２５と接続されてい
る。設定端末２５からテレネットなどによる接続を行
い、フィードの設定を行う。

【００３１】次に、本発明の第２の実施の形態を、図１
２〜図２２を参照して説明する。この第２の実施の形態
を説明する図１２〜図２２において、従来例で説明した
図２５〜図２８，図３５〜図３７に対応する部分には同
一符号を付し、その詳細説明は省略する。

【００３２】第２の実施の形態による基本的な処理は、
ローカルネットワーク１０５に接続されたノード（ルー
タ１１４やホスト１１５などの通信機器）のアドレスを
フィード１０１が記憶しておくことで、ローカルネット
ワーク１０５に接続されたノード宛のパケットをＵＤＬ
ネットワーク１０６に転送しないようにするというもの
である。

【００３３】これを実現するために、まず、フィード１
０１がローカルネットワーク１０５に接続されたノード
のアドレスを学習する処理について説明する。次に、そ
の学習したアドレスを利用して、フィード１０１がどの
ようにＵＤＬネットワーク１０６に無駄なパケットを転
送しないようにするかを説明する。続いて、フィード１
０１が学習したアドレスを自動的に更新する方法につい
て説明し、最後に、実装上の工夫について説明する。説
明をする上で、ローカルネットワーク１０５やトンネル
ネットワーク１０７は、１０ｂａｓｅＴや１００ｂａｓ
ｅＴＸなどのイーサネット（Ｅｔｈｅｒｎｅｔ）である
ことを想定して説明を進めていくが、イーサネットでな
くても、データフォーマットにおいて宛先アドレスと送
信元アドレスを持つ処理ならばどのようなものでも構わ
ない。

【００３４】では、フィード１０１がローカルネットワ
ーク１０５に接続されたノードのアドレスを学習する処
理について説明するが、基本的なアイデアは、フィード
１０１はパケット転送機能１１０のためにローカルネッ
トワーク１０５を流れるパケットを全て取り込むのだ
か、その際に取り込んだパケットの送信元アドレスを学
習するという処理である。これを図１２のフローチャー
トを用いて説明する。

【００３５】まず、フィード１０１は、ローカルネット
ワーク１０５に流れるパケットを監視している（Ｓ８０
１）。そこで、ローカルネットワーク１０５に接続され
たノードが、パケット１２２を送出する（Ｓ８０２）。
このパケット１２２は、ＩＰデータグラムや、ＩＣＭ
Ｐ、ＡＲＰなどの任意のパケットで、いずれもイーサネ
ットフレームの状態でローカルネットワーク１０５を流
れている。また、パケット１２２の宛先は任意であり、
ローカルネットワーク１０５のノードに限らず、他のネ
ットワーク上のノードでも良いし、マルチキャストやブ
ロードキャストでも構わない。

【００３６】すると、フィード１０１は、ローカルＩ／
Ｆ１０２からこのパケット１２２をフィード１０１の内
部に取り込む（Ｓ８０３）。フィード１０１のローカル
Ｉ／Ｆ１０２は、パケット転送機能１１０の実現のため
に、自分宛のパケットに限らずローカルネットワーク１
０５を流れるパケットは全て取得できるようになってい
るので、パケット１２２を取り込むことが可能なのであ
る。

【００３７】次に、フィード１０１は、パケット１２２
からイーサネットフレームの送信元アドレス１２３を取
り出す（Ｓ８０４）。パケット１２２のデータフォーマ
ットは、例えば図１３に示すように構成される。そし
て、フィード１０１はローカルネットワーク１０５に接
続されたノードのアドレスのリスト１２４からパケット
１２２の送信元アドレス１２３を検索する（ステップＳ
８０５）。リスト１２４の構造は、例えば図１４に示す
ようになっており、各行は、ローカルネットワーク１０
５に接続されたノードのアドレスを入れる列１２５と、
そのアドレスを最後に学習した時間を入れる列１２６か
ら構成されている。

【００３８】フィード１０１は、リスト１２４のアドレ
スの列１２５にアドレス１２３が存在するかどうかを調
べ（Ｓ８０６）、存在する場合は、そのアドレスが存在
する行の、時間を入れる列１２６の値を、現在の時間に
更新する（Ｓ８０７）。一方、リスト１２４のアドレス
の列１２５にアドレス１２３が存在しない場合は、新た
な行を作成し、そこの列、１２５にアドレス１２３を入
れ、列１２６には、現在の時間を入れる（Ｓ８０８）。

【００３９】これでパケット１２２からのアドレスの学
習を終え、フィード１０１は、ステップＳ８０１に戻っ
て、ローカルネットワーク１０５を流れる次のパケット
からのアドレスの学習に備える。以上の方法により、フ
ィード１０１はローカルネットワーク１０５に接続され
たノードのアドレスを学習する。

【００４０】では次に、学習したアドレスを利用して、
フィード１０１がどのようにＵＤＬネットワーク１０６
に無駄なパケットを転送しないようにするかを説明す
る。これは、フィード１０１の機能毎にフローチャート
を用いて説明する。最初に、パケット転送機能１１０の
場合について説明し、次に、ＵＤＬＲ機能１１３の場合
について説明する。

【００４１】まず、フィード１０１がパケット転送機能
１１０を行う際には、図１５のフローチャートに示すよ
うにして無駄なパケットの転送を防ぐ。最初は図１２の
処理と同じである。まず、フィード１０１は、ローカル
ネットワーク１０５に流れるパケットを監視している
（Ｓ１１０１）。そこで、ローカルネットワーク１０５
に接続されたノードが、パケット１２２を送出する（Ｓ
１１０２）。このパケット１２２は、ＩＰデータグラム
や、ＩＣＭＰ、ＡＲＰなどの任意のパケットで、いずれ
もイーサネットフレームの状態でローカルネットワーク
１０５を流れている。また、パケット１２２の宛先は任
意であり、ローカルネットワーク１０５上のノードに限
らず、他のネットワークのノードでも良いし、マルチキ
ャストやブロードキャストでも構わない。

【００４２】すると、フィード１０１は、ローカルＩ／
Ｆ１０２からこのパケット１２２をフィード１０１の内
部に取り込む（Ｓ１１０３）。次に、フィード１０１
は、パケット１２２からイーサネットフレームの宛先ア
ドレス１２７を取り出す（Ｓ１１０４）。そして、リス
ト１２４のアドレスの列１２５に取り出した宛先アドレ
ス１２７が存在するかを検索する（Ｓ１１０５）。フィ
ード１０１は、検索の結果、宛先アドレス１２７がリス
ト１２４に存在するかどうかでパケット１２２を転送す
るかどうかを決める（Ｓ１１０６）。存在した場合は、
そのパケットはローカルネットワーク１０５上のノード
宛のものであり、ＵＤＬネットワーク１０６に転送する
必要がないので、破棄する（Ｓ１１０７）。一方、リス
ト１２４のアドレスの列１２５に取り出した宛先アドレ
ス１２７が存在しない場合は、そのパケットはローカル
ネットワーク１０５上には存在しないノード宛のもので
あるとみなして、ＵＤＬネットワーク１０６へ転送する
（Ｓ１１０８）。

【００４３】これでパケット転送機能１１０におけるパ
ケット１２２の処理を終え、フィード１０１は、Ｓ１１
０１に戻って、ローカルネットワーク１０５を流れる次
のパケットの処理に備える。以上の処理により、フィー
ド１０１はローカルネットワーク１０５に流れるパケッ
トを無駄にＵＤＬネットワーク１０６に転送するのを防
ぐ。

【００４４】次に、ＵＤＬＲ機能１１３の場合について
説明する。フィード１０１がＵＤＬＲ機能１１３を行う
際には、図１６のフローチャートに示すように処理して
無駄なパケットの転送を防ぐ。まず、フィード１０１
は、トンネルネットワーク１０７に流れるパケットを監
視している（Ｓ１２０１）。そこで、トンネルネットワ
ーク１０７に接続されたノードが、ＧＲＥパケット１１
１を送出する（Ｓ１２０２）。このＧＲＥパケット１１
１には、図１７に示すように、ＩＰデータグラムや、Ｉ
ＣＭＰ、ＡＲＰなどの任意のパケット１１２がイーサネ
ットフレームの形でＩＰデータグラムのデータ部分にカ
プセル化されており、そのＩＰデータグラムがさらにイ
ーサネットフレームに入った状態でトンネルネットワー
ク１０７を流れている。フィード１０１は、このＧＲＥ
パケット１１１の宛先ＩＰアドレス１２８がフィード１
０１のトンネルＩ／Ｆ１０４のＩＰアドレスであり、か
つＩＰヘッダ１２９のプロトコルフィールド１３０の値
が所定値（ここではＧＲＥパケットであることを示す値
である１４７）であるかを調べ（Ｓ１２０３）、そうで
ある場合は、次のステップＳ１２０４に進み、そうでな
い場合は、ＵＤＬＲに関係ない通常のパケットとみなし
て、通常のパケット用の処理Ｓ１２０５を行い、その後
待機状態のステップＳ１２０１に戻る。

【００４５】ステップＳ１２０４では、フィード１０１
はＧＲＥパケット１１１がフラグメント化されているか
どうかを調べる。フラグメント化されている場合は、再
構築の処理（Ｓ１２０６）を行うのだが、ここでは再構
築の処理に関する詳細な説明は省き、フィード１０１は
ステップＳ１２０６からステップＳ１２０７に進んで、
再構築の処理が終わった完全なＧＲＥパケット１３１を
取り込むものとする。ＧＲＥパケット１１１がフラグメ
ント化されていない場合は、ＧＲＥパケット１１１をそ
のまま完全なＧＲＥパケット１３１としてフィード１０
１に取り込み、ステップＳ１２０７に進む。

【００４６】次に、フィード１０１は、ＧＲＥパケット
１３１からイーサネットフレーム１３２を取り出す（Ｓ
１２０７）。さらに、そのイーサネットフレーム１３２
から、イーサネットの宛先アドレス１３３を取り出す
（Ｓ１２０８）。そして、リスト１２４のアドレスの列
１２５に取り出した宛先アドレス１３３が存在するかを
検索する（Ｓ１２０９）。存在した場合は、そのパケッ
トはローカルネットワーク１０５上のノード宛のもので
あり、ＵＤＬネットワーク１０６に転送する必要がない
ので、イーサネットフレーム１３２をローカルＩ／Ｆ１
０２から出力し、ローカルネットワーク１０５上へと転
送する（Ｓ１２１０）。一方、リスト１２４のアドレス
の列１２５に取り出した宛先アドレス１３３が存在しな
い場合は、そのイーサネットフレーム１３２はローカル
ネットワーク１０５上には存在しないノード宛のもの
か、ローカルネットワーク１０５上にあるノードだがま
だそのアドレスをフィード１０１が学習していないノー
ド宛のものであるか、またはブロードキャストやマルチ
キャストであるとみなして、そのイーサネットフレーム
１３２のコピーを２つ作成し、１つをローカルＩ／Ｆ１
０２からローカルネットワーク１０５へ、もう１つをＵ
ＤＬ Ｉ／Ｆ１０３からＵＤＬネットワーク１０６へと
転送する（Ｓ１２１１）。

【００４７】これでＵＤＬＲ機能１１３におけるＧＲＥ
パケット１１１の処理を終え、フィード１０１は、ステ
ップＳ１２０１に戻って、トンネルネットワーク１０７
を流れる次のパケットの処理に備える。以上の方法によ
り、フィード１０１はトンネルネットワーク１０７から
入力されたＧＲＥパケットの中身を無駄にＵＤＬネット
ワーク１０６に転送するのを防ぐ。

【００４８】では、次に、フィード１０１が学習したア
ドレスを自動的に更新する処理について説明する。フィ
ード１０１が、学習したアドレスを削除することなく永
遠に保持しつづけると、問題が発生することがある。そ
れは、図１８に示すように、ローカルネットワーク１０
５に接続されたノード１３４が、ローカルネットワーク
１０５から取り外されて、ＵＤＬネットワーク１０６な
ど他のネットワークに接続された場合に発生する。問題
の詳細は次のようになっている。まず、ノード１３４が
ローカルエリアネットワーク１０５に接続されている状
態でフィード１０１がノード１３４のアドレスを学習す
る。次に、ノード１３４をローカルネットワーク１０５
から取り外し、ＵＤＬネットワーク１０６の受信側に接
続する。その状態でローカルネットワーク１０５上のノ
ード１３５からＵＤＬネットワーク１０６の上ノード１
３４にパケットを送ろうとしても、ノード１３４のアド
レスがリスト１２４に残っているために、フィード１０
１はそのパケットを破棄してしまう。そのため、パケッ
トはＵＤＬネットワーク１０６には転送されず、従って
ノード１３５からノード１３４への通信を行うことは出
来なくなってしまう。

【００４９】この問題を解決するために、フィード１０
１は、リスト１２４にあるアドレスを永遠に保持するの
ではなく、定期的にリスト１２４を更新し、不要なアド
レスを削除するようにする。削除を行う場合には、例え
ば一定時間以上ローカルネットワーク１０５にパケット
を送出しないノードのアドレスを削除するものとする。
一定時間というのは、ローカルネットワーク１０５上の
ノード１３４がローカルネットワーク１０５から取り外
され、他のネットワークに繋がるのにかかる時間より短
い時間を目安とする。具体的には、例えば３分程度にし
ておけば問題ないと思われる。

【００５０】削除の流れを図１９のフローチャートを参
照して説明する。フィード１０１は、タイマを用いて、
一定時間毎にリスト１２４の全ての行を検索する。まず
タイマから通知があるまで待機し（Ｓ１５０１）、通知
が来て検索の時間が訪れると（Ｓ１５０２）、リスト１
２４の最初の最初の行を取り出し（Ｓ１５０３）、その
行の時間が入った列１２６の値を読み込む（Ｓ１５０
４）。この値（時間）を現在の時間から引き、その差が
あらかじめ指定された時間（例えば３分）より大きいか
どうかを比較する（Ｓ１５０５）。大きい場合は、リス
ト１２４のこの行のアドレスが示すノードは、指定され
た時間以上の間、ローカルネットワーク１０５にパケッ
トを送出していないことになるので、この行を削除する
（Ｓ１５０６）。差が指定された時間より大きくない場
合は、この行はそのままにしておく。いずれの場合も、
この処理を次の行以降も繰り返す。つまり、次の行が存
在するかを調べ（Ｓ１５０７）、存在すればその行を読
み込む（Ｓ１５０８）、ステップＳ１５０４に戻る。次
の行が存在しなければ、そこでまた待機状態（ステップ
Ｓ１５０１）に入る。

【００５１】以上が、フィード１０１が学習したアドレ
スを自動的に更新する処理の説明である。

【００５２】最後に、実装上の処理と、その他の注意点
について説明する。

【００５３】まず、フィード１０１がローカルネットワ
ーク１０５を流れるフィード１０１自身宛のパケット１
３６をどう処理するかについてである。パケット１３６
がローカルネットワーク１０５を流れてきた場合は、こ
れはＵＤＬネットワークに転送すべきものではないの
で、図１５のステップＳ１１０５の段階で、パケット１
３６のイーサネットフレームの宛先アドレスが自分宛で
あることを検出し、ＵＤＬネットワーク１０６に転送せ
ずに、自分自身が取り込めば良い。また、実装上の工夫
として、フィード１０１は、ローカルＩ／Ｆ１０２以外
からも自分宛のパケットを受け取ることが可能なので、
実装を簡単にするため、ローカルＩ／Ｆ１０２からは自
分宛のパケット１３６を受け取らずに破棄してしまうも
のとすると、リスト１２４にフィード１０１自身のロー
カルＩ／Ｆ１０２のイーサネットアドレスを最初から入
れておき、さらにそのアドレスの行をフィード１０１が
定期的にリスト１２４を更新する際の対象外にしておく
と、図１５のステップＳ１１０５からステップＳ１１０
６に処理が移り、自動的にパケット１３６は破棄され
る。

【００５４】一方、パケット１３６が、ＧＥＲパケット
１１１にカプセル化されてトンネルＩ／Ｆ１０４から入
ってきた場合は、これはローカルネットワーク１０５に
もＵＤＬネットワーク１０６にも転送すべきではないの
で、図１６のステップＳ１２０８の段階で、パケット１
３６のイーサネットフレームの宛先アドレスが自分宛で
あることを検出し、他のネットワークには転送せずに、
自分自身が取り込めば良い。この場合も、実装を簡単に
するために、トンネルＩ／Ｆ１０４からは自分自身宛の
ＧＲＥにカプセル化されたパケット１３６を受け取らず
に破棄してしまう実装も考えられるが、この場合は、リ
スト１２４にフィード１０１自身のイーサネットアドレ
スを入れておくと、図１６のステップＳ１２０８からス
テップＳ１２０９に移ってそのパケット１３６を破棄せ
ずにローカルネットワークに転送してしまう。従って、
単純にリスト１２４にフィード１０１自身のイーサネッ
トアドレスを入れておくだけでは対応できないので、注
意が必要である。

【００５５】次に、リスト１２４の実装処理について説
明する。リスト１２４を実装する際には、フィード１０
１はハードウェアまたはソフトウェアの制約により、リ
スト１２４を有限の長さにしか持てない。また、リスト
１２４が長くなると、検索に時間がかかるようになり、
高速に大量のパケットを転送するのが難しくなる。そこ
で、リスト１２４の長さを有限にし、検索にかかる時間
を短くする。また、リスト１２４の長さが有限になる
と、リスト１２４の全ての行が埋まってしまった際に、
新しくアドレスを追加することができなくなるので、そ
の場合は、リスト１２４に入っているアドレスの中か
ら、最も更新時間が古いアドレスを削除して、空いた行
に新しいアドレスを追加するようにする。

【００５６】具体的には、図２０に示すように、検索に
かかる時間が問題にならない程度の長さが固定長のリス
ト１３７を持っておく。リスト１３７には、アドレスが
入る列１２５と更新時間が入る列１２６の他に、各行が
有効な行かどうかを示す列１３８がある。リスト１３７
に新しいアドレスを加える場合は、図２１に示す手順で
行う。まず、リスト１３７の列１３８を調べ、無効な行
があるかを調べる（Ｓ１７０１）。無効な行があった場
合は、その行に新しいアドレスと更新時間を入れ、その
行の列１３８を有効に変更する（Ｓ１７０２）。無効な
行がなかった場合は、リスト１３７の列１２６を調べ、
最も更新時間の古い行を調べる（Ｓ１７０３）。そして
その行に新しいアドレスと更新時間を入れる（Ｓ１７０
４）。これで追加は完了である。

【００５７】このデータ構造でアドレスの検索を行う場
合は、列１３８が有効で、かつ列１２５に該当するアド
レスが入っている行を探せばよい。また、アドレスの削
除を行う場合は、削除したいアドレスを前記の手順で検
索し、その行の列１３８を有効から無効に変更するだけ
で良い。更新時間の変更をする場合は、前記の手順で更
新したアドレスを検索し、その行の列１２６を更新すれ
ば良い。

【００５８】以上、フィード１０１がＵＤＬネットワー
ク１０６に無駄なパケットを流さないための方法につい
て説明したが、具体的なフィード１０１の使用例として
は、例えば図２２のようになる。ＵＤＬネットワーク１
０６としては、衛星回線１３９を使うことが考えられ
る。衛星回線１３９は大容量であるが、高価であるた
め、本実施の形態のように無駄なパケットを流さないよ
うにするのは有効な技術である。ルータ１４０は、図１
６に示したルータ１１４とルータ１１８を同一のルータ
にまとめたものである。ここでは、レシーバ１１７はル
ータとして描かれているが、レシーバ１１７をブリッジ
としても、フィード１０１の機能は全く問題なく動作す
る。このようなシステム以外でも、ＵＤＬネットワーク
１０６としてケーブルを利用した場合や、ローカルネッ
トワーク１０５やトンネルネットワーク１０７としてイ
ーサネットではないネットワークを利用した場合も、本
発明は有効に作用する。

【００５９】なお、ここまで説明した各実施の形態で
は、片方向の通信回線として衛星回線を使用した例につ
いて説明したが、同様に片方向の通信が可能な各種通信
回線を使用した場合にも本発明は適用できるものであ
る。

【００６０】

【発明の効果】第１の発明によると、ブリッジタイプの
フィードで、ＵＤＬＲとしての双方向通信を実現するこ
とができる。これにより、既存のルータの機能に変更を
加えることなく、ブリッジを加えるだけで、片方向の通
信回線があたかも双方向の通信回線であるかのように、
既存のルーティングを動作させることができるようにな
る。

【００６１】また、見方を変えると、今まではＵＤＬＲ
としての双方向通信を実現可能な通信機器はルータだけ
であったのが、比較的実装が容易で安価に作成できるブ
リッジでもＵＤＬＲとしての双方向通信が実現可能にな
ることで、ＵＤＬＲとしての双方向通信の実現を従来と
比べて容易に、また安価に行うことができるようにな
る。

【００６２】第２の発明によると、ＵＤＬＲのような双
方向通信をサポートしたブリッジタイプのフィードが、
フィードに繋がる双方向の通信回線を流れるパケットの
うち、片方向の通信回線へ転送する必要のないパケット
を、片方向の通信回線へ転送してしまう回数を減らすこ
とができる。

【００６３】これにより、片方向の通信回線の帯域を有
効にできるようにし、また、片方向の通信回線に接続さ
れたレシーバの様な通信機器の負荷を軽減することがで
きる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態による構成の例を示
すブロック図である。

【図２】本発明の第１の実施の形態による構成の例（フ
ィードの２つのインターフェースを同じルータに繋げる
例）を示すブロック図である。

【図３】本発明の第１の実施の形態による構成の例（フ
ィードのインターフェースを全て異なるルータに繋げる
例）を示すブロック図である。

【図４】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードへのＧＲＥパ
ケットの伝送構成例）を示すブロック図である。

【図５】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードがＧＲＥパケ
ットの中身を転送する状態の例）を示すブロック図であ
る。

【図６】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードでの受信側か
ら送信側への経路構成例）を示すブロック図である。

【図７】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードでの受信側か
ら他の受信側への経路構成例）を示すブロック図であ
る。

【図８】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードを衛星回線に
用いた例）を示すブロック図である。

【図９】本発明の第１の実施の形態による構成の例（Ｕ
ＤＬＲが可能なブリッジタイプのフィードを衛星回線に
用いた別の例）を示すブロック図である。

【図１０】本発明の第１の実施の形態による構成の例
（レシーバがブリッジの例）を示すブロック図である。

【図１１】本発明の第１の実施の形態による構成の例
（設定用のインターフェースを追加したフィードの例）
を示すブロック図である。

【図１２】本発明の第２の実施の形態によるアドレス学
習処理例を示すフローチャートである。

【図１３】本発明の第２の実施の形態によるフォーマッ
トの例を示す説明図である。

【図１４】本発明の第２の実施の形態によるアドレスの
リストの例を示す説明図である。

【図１５】本発明の第２の実施の形態によるパケット転
送機能の流れを示すフローチャートである。

【図１６】本発明の第２の実施の形態によるＵＤＬＲ機
能の流れを示すフローチャートである。

【図１７】本発明の第２の実施の形態によるＧＲＥパケ
ットのフォーマットを示す説明図である。

【図１８】本発明の第２の実施の形態による構成の例
（学習したアドレスを削除する必要がある例）を示すブ
ロック図である。

【図１９】本発明の第２の実施の形態による学習したア
ドレスを削除する処理を示すフローチャートである。

【図２０】本発明の第２の実施の形態によるローカルネ
ットワーク上のノードが持つアドレスのリストの実装例
を示す説明図である。

【図２１】本発明の第２の実施の形態によるリストへの
新しいアドレスの追加処理の例を示すフローチャートで
ある。

【図２２】本発明の第２の実施の形態を衛星回線とイン
ターネット（又はイントラネット）を用いたシステムへ
の適用例を示すブロック図である。

【図２３】従来のルータとしてのフィードの構成の例を
示すブロック図である。

【図２４】従来のブリッジとしてのフィードの構成の例
を示すブロック図である。

【図２５】従来のＵＤＬＲをサポートしたブリッジタイ
プのフィードの構成の例を示すブロック図である。

【図２６】従来のパケット転送機能の例を示すフローチ
ャートである。

【図２７】従来のＵＤＬＲ機能を説明するためのブロッ
ク図である。

【図２８】従来のＵＤＬＲ機能の流れを示すフローチャ
ートである。

【図２９】従来のＵＤＬＲを用いた双方向通信の実現構
成の例を示すブロック図である。

【図３０】ＧＲＥによるＩＰデータグラムのカプセル化
の例を示す説明図である。

【図３１】フィードがルータの場合のＵＤＬＲを用いた
双方向通信の処理を示すブロック図である。

【図３２】従来の受信側から送信側への経路の例を示す
ブロック図である。

【図３３】従来の受信側から他の受信側への経路の例を
示すブロック図である。

【図３４】従来のフィードがブリッジの場合のＵＤＬＲ
を用いた双方向通信の例を示すブロック図である。

【図３５】従来のフィードと他の機器との接続形態の例
を示すブロック図である。

【図３６】従来のフィードにおけるパケット転送機能を
説明するためのブロック図である。

【図３７】従来のフィードにおけるＵＤＬＲ機能を説明
するためのブロック図である。

【符号の説明】

１ａ，１ｂ，１ｃ…フィード、２…片方向の通信回線、
３…双方向の通信回線、４ａ，４ｂ，５ａ，５ｂ…イン
ターフェース、６，７ａ，７ｂ，８，１４…ルータ、９
ａ，９ｂ…仮想的な通信回線、１０ａ，１０ｂ，１０
ｃ，１１ａ，１１ｂ，１７…伝送経路、１２，１３ａ，
１３ｂ…インターフェース、２０…インターネット（又
はイントラネット）、２１…マルチプレクサ、２２，２
３…レシーバ、１０１…フィード、１０２…ローカルＩ
／Ｆ、１０３…ＵＤＬ Ｉ／Ｆ、１０４…トンネルＩ／
Ｆ、１０５…ローカルネットワーク、１０６…ＵＤＬネ
ットワーク、１０７…トンネルネットワーク、１１７…
レシーバ

Claims (12)

【特許請求の範囲】
1. 【請求項１】 片方向の通信回線を利用したインターネ
   ットの通信方法において、 上記通信回線へのデータの送出側で、上記通信回線に送
   出すべきＩＰデータグラムを受信する経路を設定すると
   共に、 双方向通信を行うための、上記通信回線の受信側から上
   記送出側への仮想的な通信経路を実現するための経路を
   別に設定する、 通信方法。
2. 【請求項２】 請求項１記載の通信方法において、 上記通信回線は、衛星を経由した通信回線である通信方
   法。
3. 【請求項３】 片方向の通信回線を使用してＩＰプロト
   コルを用いた通信を行うブリッジタイプの通信装置にお
   いて、 上記片方向の通信回線へ送出すべきＩＰデータグラムを
   受信する第１のインターフェースと、 双方向通信を行うための上記片方向の通信回線の受信側
   から当該通信装置への仮想的な通信経路を実現するため
   の第２のインターフェースとを備える、 通信装置。
4. 【請求項４】 請求項３記載の通信装置において、 上記通信回線は、衛星を経由した通信回線である、通信
   装置。
5. 【請求項５】 片方向の第１の通信回線にデータを送出
   するブリッジタイプの送出手段に、双方向通信が可能な
   第２の通信回線を接続して第１の通信回線で仮想的に双
   方向通信を行う通信方法において、 上記送信手段に所定のインターフェースから入力された
   パケットの宛先を判断し、その判断したパケットの宛先
   からそのパケットかどのインターフェースの先にあるネ
   ットワークに送られるべきかを判断し、転送が必要な場
   合のみに所定のインターフェースから転送を行う通信方
   法。
6. 【請求項６】 請求項５に記載した通信方法において、 送信側のネットワークに接続されているノードのアドレ
   スを自動的に上記送信手段が検出することを特徴とする
   通信方法。
7. 【請求項７】 請求項６に記載した通信方法において、 自動的に検出した送信側のネットワークに接続されてい
   るノードのアドレスをリストにして上記送信手段が保持
   し、そのリストを基にしてパケットの転送の判断を行う
   ことを特徴とした通信方法。
8. 【請求項８】 請求項７に記載した通信方法において、 自動的に検出した送信側のネットワークに接続されてい
   るノードのアドレスのリストを上記送信手段が定期的に
   更新し、一定時間以上の間パケットのやり取りが行われ
   ていないノードのアドレスをリストから削除することを
   特徴とした通信方法。
9. 【請求項９】 片方向の第１の通信回線にデータを送出
   するブリッジタイプの送出手段として構成される通信装
   置において、 双方向通信が可能な第２の通信回線を接続するインター
   フェースを備えると共に、 所定のインターフェースから入力されたパケットの宛先
   を判断し、その宛先からそのパケットがどのインターフ
   ェースの先にあるネットワークに送られるかを判断し、
   転送が必要であると判断したときのみに転送処理を実行
   させる制御手段を備えた通信装置。
10. 【請求項１０】 請求項９に記載した通信装置におい
    て、 上記制御手段は、インターフェースに接続されたネット
    ワークに接続されているノードのアドレスを自動的に検
    出する検出手段を備えたことを特徴とする通信装置。
11. 【請求項１１】 請求項１０に記載した通信装置におい
    て、 上記検出手段が自動的に検出したノードのアドレスをリ
    ストにして保持するアドレス記憶手段を備え、 上記制御手段は、上記アドレス記憶手段に記憶されたリ
    ストを基にしてパケットの転送の判断を行うことを特徴
    とした通信装置。
12. 【請求項１２】 請求項１１に記載した通信装置におい
    て、 上記制御手段は、上記アドレス記憶手段に記憶されたリ
    ストを定期的に更新し、一定時間以上の間パケットのや
    り取りが行われていないノードのアドレスをリストから
    削除することを特徴とした通信装置。