JP4780477B2 - トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム - Google Patents
トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム Download PDFInfo
- Publication number
- JP4780477B2 JP4780477B2 JP2007506043A JP2007506043A JP4780477B2 JP 4780477 B2 JP4780477 B2 JP 4780477B2 JP 2007506043 A JP2007506043 A JP 2007506043A JP 2007506043 A JP2007506043 A JP 2007506043A JP 4780477 B2 JP4780477 B2 JP 4780477B2
- Authority
- JP
- Japan
- Prior art keywords
- frame
- physical address
- address
- kernel
- distribution
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
本発明はトンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラムに関し、特にデカプセル化すべきフレームとカプセル化すべきフレームとを同一の物理インタフェース部から入力し、適切にカプセル化またはデカプセル化して物理インタフェース部から出力するトンネリング装置に関する。
従来、企業内の一部門のサブネットや、家庭内ネットワークや、通信業者の地域ネットワーク等のローカルネットワークが相互に接続して構成される、イントラネットやインターネット等の情報通信ネットワークにおいては、あるローカルネットワーク間で送受信されるフレーム（内部フレーム）を別のフレーム（外部フレーム）にカプセル化し、外部フレームが通過するネットワーク上では内部フレームが不透過な状態になるようにするトンネリング技術が知られている（例えば、文献１参照）。
このトンネリング技術を用いることによって、ローカルネットワーク間では論理的な１本のリンクで接続された状態となり、その論理リンク内を流れるフレームが外部から不透過な状態になるので、通過するネットワーク上では利用できない通信プロトコルの利用を可能としたり、暗号化を施してフレームの内容を盗み見できないようにすること等が可能となる。
以下、従来のデータリンク層トンネリング技術について説明する。図３０はイーサネット（登録商標）等のデータリンク層で送受信されているフレームＦ６の内容を示す図である。例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等のアプリケーションで送受信されるデータ系列Ｆ１には、アプリケーションから指定されたＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等のトラフィック制御を行うトランスポート層プロトコルの制御情報を含むトランスポート層ヘッダＦ２が付加される。
さらに、データ系列Ｆ１には、情報通信ネットワーク内で送信先となる端末に割り振られたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等のネットワーク層プロトコルで規定される論理アドレス等を含むネットワーク層ヘッダＦ３が付加され、パケットＦ５となる。
また、ローカルネットワークにおいては、パケットＦ５に対して、ローカルネットワークを構成する端末やスイッチングハブ等の通信機器で認識可能なイーサネット（登録商標）等のデータリンク層プロトコルで規定される物理アドレスを含むデータリンク層ヘッダＦ４が付加され、フレームＦ６となる。ローカルネットワークで実際に送受信されているのは、このフレームＦ６である。
データリンク層トンネリング技術においては、ローカルネットワークで実際に送受信されているフレームＦ６そのものをデータ系列Ｆ１としてみなし、再度、トランスポート層ヘッダ等のヘッダを付加し、別のフレームやパケットを作成する。これをカプセル化といい、その逆の操作を行って元のフレームＦ６を取出すことをデカプセル化という。
従来のデータリンク層トンネリング技術としては、図３１に示すように、ＥｔｈｅｒＩＰのデータ形式（例えば、文献２参照）を用いるものがある。上記の文献２によれば、ＥｔｈｅｒＩＰはデータリンク層プロトコルであるイーサネット（登録商標）のフレームを、ネットワーク層プロトコルであるＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）のパケットにカプセル化するトンネリング技術である。
イーサネット（登録商標）で送受信されるフレームであるイーサネット（登録商標）フレームＦ７に、独自のヘッダであるＥｔｈｅｒＩＰヘッダＦ８と、ネットワーク層ヘッダであるＩＰヘッダＦ９を付加し、ＩＰパケットＦ１０を作成する。
本来、イーサネット（登録商標）フレームＦ７はローカルネットワーク内でのみ有効であり、ルータ等の経路選択装置において別のネットワークヘ転送される時に、データリンク層ヘッダであるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダが破棄されてしまい、元のイーサネット（登録商標）フレームＦ７全体は維持されない。
イーサネット（登録商標）はブロードキャストをサポートしており、ローカルネットワークに接続するすべての端末に同一のイーサネット（登録商標）フレームＦ７を同報送信することが可能であるが、上記の理由によって、別のローカルネットワークへも同時に同報送信をすることができないという問題がある。
さらに、例えば、ネットワーク層プロトコルとしてＩＰｖ４しか転送できないＩＰｖ４ネットワークにおいて、ＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ ｅＸｃｈａｎｇｅ）やＡｐｐｌｅＴａｌｋ（登録商標）等のネットワーク層プロトコルは無効であり、ＩＰｖ４ネットワークを経由して別のローカルネットワークとＩＰＸやＡｐｐｌｅＴａｌｋ（登録商標）等のプロトコルを用いて通信することはできないという問題がある。
しかしながら、ＥｔｈｅｒＩＰを用いれば、ブロードキャストを行うイーサネット（登録商標）フレームや、ＩＰＸやＡｐｐｌｅＴａｌｋ（登録商標）等を含むイーサネット（登録商標）フレームは、すべてカプセル化されてＩＰｖ４のパケットになるので、ＩＰｖ４ネットワークを通過することができ、目的のローカルネットワークでデカプセル化して取出したイーサネット（登録商標）フレームをそのまま目的のローカルネットワークで送信すれば、上記の問題は解決する。
上記のＥｔｈｅｒＩＰによるカプセル化、デカプセル化を行うトンネリング装置を用いて２つのローカルネットワークを接続する情報通信ネットワーク全体の構成を図３２に示す。
トンネリング装置は物理インタフェースを２つ持つのが一般的であり、カプセル化対象のフレームの受信を行う物理インタフェースと、デカプセル化対象のフレームの受信を行う物理インタフェースとを別々に持つ。例えば、図３２を参照すると、トンネリング装置Ｒ５１はローカルネットワークＲ１１に配置され、１つの物理インタフェースはイーサネット（登録商標）フレームが送受信されるサブネットＲ４１に接続され、他方はイーサネット（登録商標）フレームがカプセル化されたＩＰパケットが送受信されるサブネットＲ４５に接続される。
上記のトンネリング装置Ｒ５１と同様に、トンネリング装置Ｒ５２はローカルネットワークＲ１２に配置され、１つの物理インタフェースはイーサネット（登録商標）フレームが送受信されるサブネットＲ４２に接続され、他方はイーサネット（登録商標）フレームがカプセル化されたＩＰパケットが送受信されるサブネットＲ４６に接続される。
ローカルネットワークＲ１１の端末Ｒ１から送信されたイーサネット（登録商標）フレームはサブネットＲ４１を介してトンネリング装置Ｒ５１で受信され、そのイーサネット（登録商標）フレームがローカルネットワークＲ１２で受信されるべきイーサネット（登録商標）フレームであった場合に、インタネットＲ１０を経由可能なＩＰパケットにカプセル化を行い、ローカルネットワークＲ１２のトンネリング装置Ｒ５２の論理アドレスを指定して送信する。トンネリング装置Ｒ５２はそのＩＰパケットを受取ると、デカプセル化を行ってイーサネット（登録商標）フレームを取出し、そのイーサネット（登録商標）フレームをサブネットＲ４２へと送信する。
このようにして、トンネリング装置Ｒ５１，Ｒ５２によって、サブネットＲ４１，Ｒ４２は通信トンネルＲ５０によって論理的に接続された状態になり、イーサネット（登録商標）フレームは端末Ｒ２において直接的に端末Ｒ１から送信されたかのように受信される。端末Ｒ２から端末Ｒ１へのイーサネット（登録商標）フレームの送信も、上記と同様である。すなわち、サブネットＲ４１とサブネットＲ４２とは、データリンク層プロトコルから見て透過的に接続され、あたかも１つのローカルネットワークであるかのように振舞うようになる。
上記の例において、トンネリング技術はＥｔｈｅｒＩＰのほか、Ｅｔｈｅｒｎｅｔ（登録商標） ｏｖｅｒ ＨＴＴＰＳ［ＨＴＴＰ ｏｖｅｒ ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）］（例えば、文献３参照）や、Ｌ２ＴＰｖ３（Ｌａｙｅｒ ｔｗｏ Ｔｕｎｎｅｌｉｎｇ ＰｒｏｔｏｃｏＩ ｖｅｒｓｉｏｎ ３）や、ＥｔｈｅｒＩＰとＩＰｓｅｃ（ＩＰ ｓｅｃｕｒｉｔｙ ｐｒｏｔｏｃｏｌ）とを組み合わせたＥｔｈｅｒｎｅｔ（登録商標） ｏｖｅｒ ＩＰｓｅｃ等の任意のデータリンク層プロトコルのフレームを任意のネットワーク層プロトコルのパケットにカプセル化する技術が適用可能であり、上記と同様の構成となる。
しかしながら、この構成では端末Ｒ１や端末Ｒ２が情報通信ネットワークＲ１０からは分断され、通信することができない状態である。よって、通常、トンネリング装置にはどのフレームをそのまま通過させ、どのフレームをカプセル化するかというポリシーが設定されるか、ファイアウォールとの組み合わせで運用されることが多いが、それでも既存のネットワークを一時切断したり、構成を大幅に変更しなければならないという問題がある。
文献１ ルイジ・ユアン＋Ｗ・ティモシー・ストレイヤー著、“実践ＶＰＮ技術とソリューション”、株式会社ピアソン・エデュケーション、日本、２００１年
文献２ ”ＥｔｈｅｒＩＰ： Ｔｕｎｎｅｌｉｎｇ Ｅｔｈｅｒｎｅｔ（登録商標） Ｆｒａｍｅｓ ｉｎ ＩＰ Ｄａｔａｇｒａｍｓ”＜ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３３７８．ｔｘｔ＞
文献３ ”ＳｏｆｔＥｔｈｅｒ．ｃｏｍ−ＳｏｆｔＥｔｈｅｒ 仮想イーサネット（登録商標）システム−ＳｏｆｔＥｔｈｅｒ ＶＰＮ Ｓｙｓｔｅｍ”＜ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｓｏｆｔｅｔｈｅｒ．ｃｏｍ／ｊｐ／＞
従来のデータリンク層フレームをカプセル化するトンネリング装置には、物理インタフェースが２つ以上あり、カプセル化対象のフレームの受信を行う物理インタフェースと、デカプセル化対象のフレームの受信を行う物理インタフェースとを別々に持っている。よって、設置時にネットワークの切断を余儀なくされ、トンネリング装置を設置したり、取り外したりすることが容易ではないという問題がある。
このトンネリング技術を用いることによって、ローカルネットワーク間では論理的な１本のリンクで接続された状態となり、その論理リンク内を流れるフレームが外部から不透過な状態になるので、通過するネットワーク上では利用できない通信プロトコルの利用を可能としたり、暗号化を施してフレームの内容を盗み見できないようにすること等が可能となる。
以下、従来のデータリンク層トンネリング技術について説明する。図３０はイーサネット（登録商標）等のデータリンク層で送受信されているフレームＦ６の内容を示す図である。例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等のアプリケーションで送受信されるデータ系列Ｆ１には、アプリケーションから指定されたＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等のトラフィック制御を行うトランスポート層プロトコルの制御情報を含むトランスポート層ヘッダＦ２が付加される。
さらに、データ系列Ｆ１には、情報通信ネットワーク内で送信先となる端末に割り振られたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等のネットワーク層プロトコルで規定される論理アドレス等を含むネットワーク層ヘッダＦ３が付加され、パケットＦ５となる。
また、ローカルネットワークにおいては、パケットＦ５に対して、ローカルネットワークを構成する端末やスイッチングハブ等の通信機器で認識可能なイーサネット（登録商標）等のデータリンク層プロトコルで規定される物理アドレスを含むデータリンク層ヘッダＦ４が付加され、フレームＦ６となる。ローカルネットワークで実際に送受信されているのは、このフレームＦ６である。
データリンク層トンネリング技術においては、ローカルネットワークで実際に送受信されているフレームＦ６そのものをデータ系列Ｆ１としてみなし、再度、トランスポート層ヘッダ等のヘッダを付加し、別のフレームやパケットを作成する。これをカプセル化といい、その逆の操作を行って元のフレームＦ６を取出すことをデカプセル化という。
従来のデータリンク層トンネリング技術としては、図３１に示すように、ＥｔｈｅｒＩＰのデータ形式（例えば、文献２参照）を用いるものがある。上記の文献２によれば、ＥｔｈｅｒＩＰはデータリンク層プロトコルであるイーサネット（登録商標）のフレームを、ネットワーク層プロトコルであるＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）のパケットにカプセル化するトンネリング技術である。
イーサネット（登録商標）で送受信されるフレームであるイーサネット（登録商標）フレームＦ７に、独自のヘッダであるＥｔｈｅｒＩＰヘッダＦ８と、ネットワーク層ヘッダであるＩＰヘッダＦ９を付加し、ＩＰパケットＦ１０を作成する。
本来、イーサネット（登録商標）フレームＦ７はローカルネットワーク内でのみ有効であり、ルータ等の経路選択装置において別のネットワークヘ転送される時に、データリンク層ヘッダであるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダが破棄されてしまい、元のイーサネット（登録商標）フレームＦ７全体は維持されない。
イーサネット（登録商標）はブロードキャストをサポートしており、ローカルネットワークに接続するすべての端末に同一のイーサネット（登録商標）フレームＦ７を同報送信することが可能であるが、上記の理由によって、別のローカルネットワークへも同時に同報送信をすることができないという問題がある。
さらに、例えば、ネットワーク層プロトコルとしてＩＰｖ４しか転送できないＩＰｖ４ネットワークにおいて、ＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ ｅＸｃｈａｎｇｅ）やＡｐｐｌｅＴａｌｋ（登録商標）等のネットワーク層プロトコルは無効であり、ＩＰｖ４ネットワークを経由して別のローカルネットワークとＩＰＸやＡｐｐｌｅＴａｌｋ（登録商標）等のプロトコルを用いて通信することはできないという問題がある。
しかしながら、ＥｔｈｅｒＩＰを用いれば、ブロードキャストを行うイーサネット（登録商標）フレームや、ＩＰＸやＡｐｐｌｅＴａｌｋ（登録商標）等を含むイーサネット（登録商標）フレームは、すべてカプセル化されてＩＰｖ４のパケットになるので、ＩＰｖ４ネットワークを通過することができ、目的のローカルネットワークでデカプセル化して取出したイーサネット（登録商標）フレームをそのまま目的のローカルネットワークで送信すれば、上記の問題は解決する。
上記のＥｔｈｅｒＩＰによるカプセル化、デカプセル化を行うトンネリング装置を用いて２つのローカルネットワークを接続する情報通信ネットワーク全体の構成を図３２に示す。
トンネリング装置は物理インタフェースを２つ持つのが一般的であり、カプセル化対象のフレームの受信を行う物理インタフェースと、デカプセル化対象のフレームの受信を行う物理インタフェースとを別々に持つ。例えば、図３２を参照すると、トンネリング装置Ｒ５１はローカルネットワークＲ１１に配置され、１つの物理インタフェースはイーサネット（登録商標）フレームが送受信されるサブネットＲ４１に接続され、他方はイーサネット（登録商標）フレームがカプセル化されたＩＰパケットが送受信されるサブネットＲ４５に接続される。
上記のトンネリング装置Ｒ５１と同様に、トンネリング装置Ｒ５２はローカルネットワークＲ１２に配置され、１つの物理インタフェースはイーサネット（登録商標）フレームが送受信されるサブネットＲ４２に接続され、他方はイーサネット（登録商標）フレームがカプセル化されたＩＰパケットが送受信されるサブネットＲ４６に接続される。
ローカルネットワークＲ１１の端末Ｒ１から送信されたイーサネット（登録商標）フレームはサブネットＲ４１を介してトンネリング装置Ｒ５１で受信され、そのイーサネット（登録商標）フレームがローカルネットワークＲ１２で受信されるべきイーサネット（登録商標）フレームであった場合に、インタネットＲ１０を経由可能なＩＰパケットにカプセル化を行い、ローカルネットワークＲ１２のトンネリング装置Ｒ５２の論理アドレスを指定して送信する。トンネリング装置Ｒ５２はそのＩＰパケットを受取ると、デカプセル化を行ってイーサネット（登録商標）フレームを取出し、そのイーサネット（登録商標）フレームをサブネットＲ４２へと送信する。
このようにして、トンネリング装置Ｒ５１，Ｒ５２によって、サブネットＲ４１，Ｒ４２は通信トンネルＲ５０によって論理的に接続された状態になり、イーサネット（登録商標）フレームは端末Ｒ２において直接的に端末Ｒ１から送信されたかのように受信される。端末Ｒ２から端末Ｒ１へのイーサネット（登録商標）フレームの送信も、上記と同様である。すなわち、サブネットＲ４１とサブネットＲ４２とは、データリンク層プロトコルから見て透過的に接続され、あたかも１つのローカルネットワークであるかのように振舞うようになる。
上記の例において、トンネリング技術はＥｔｈｅｒＩＰのほか、Ｅｔｈｅｒｎｅｔ（登録商標） ｏｖｅｒ ＨＴＴＰＳ［ＨＴＴＰ ｏｖｅｒ ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）］（例えば、文献３参照）や、Ｌ２ＴＰｖ３（Ｌａｙｅｒ ｔｗｏ Ｔｕｎｎｅｌｉｎｇ ＰｒｏｔｏｃｏＩ ｖｅｒｓｉｏｎ ３）や、ＥｔｈｅｒＩＰとＩＰｓｅｃ（ＩＰ ｓｅｃｕｒｉｔｙ ｐｒｏｔｏｃｏｌ）とを組み合わせたＥｔｈｅｒｎｅｔ（登録商標） ｏｖｅｒ ＩＰｓｅｃ等の任意のデータリンク層プロトコルのフレームを任意のネットワーク層プロトコルのパケットにカプセル化する技術が適用可能であり、上記と同様の構成となる。
しかしながら、この構成では端末Ｒ１や端末Ｒ２が情報通信ネットワークＲ１０からは分断され、通信することができない状態である。よって、通常、トンネリング装置にはどのフレームをそのまま通過させ、どのフレームをカプセル化するかというポリシーが設定されるか、ファイアウォールとの組み合わせで運用されることが多いが、それでも既存のネットワークを一時切断したり、構成を大幅に変更しなければならないという問題がある。
文献１ ルイジ・ユアン＋Ｗ・ティモシー・ストレイヤー著、“実践ＶＰＮ技術とソリューション”、株式会社ピアソン・エデュケーション、日本、２００１年
文献２ ”ＥｔｈｅｒＩＰ： Ｔｕｎｎｅｌｉｎｇ Ｅｔｈｅｒｎｅｔ（登録商標） Ｆｒａｍｅｓ ｉｎ ＩＰ Ｄａｔａｇｒａｍｓ”＜ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３３７８．ｔｘｔ＞
文献３ ”ＳｏｆｔＥｔｈｅｒ．ｃｏｍ−ＳｏｆｔＥｔｈｅｒ 仮想イーサネット（登録商標）システム−ＳｏｆｔＥｔｈｅｒ ＶＰＮ Ｓｙｓｔｅｍ”＜ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｓｏｆｔｅｔｈｅｒ．ｃｏｍ／ｊｐ／＞
従来のデータリンク層フレームをカプセル化するトンネリング装置には、物理インタフェースが２つ以上あり、カプセル化対象のフレームの受信を行う物理インタフェースと、デカプセル化対象のフレームの受信を行う物理インタフェースとを別々に持っている。よって、設置時にネットワークの切断を余儀なくされ、トンネリング装置を設置したり、取り外したりすることが容易ではないという問題がある。
そこで、本発明の目的は上記の問題点を解消し、ネットワークを一時停止させず、かつすでに構成されているローカルネットワークに変更を加えることなく、トンネリングを行うことができるトンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラムを提供することにある。
本発明によるトンネリング装置は、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置であって、
前記フレームをカプセル化するカプセル化手段と、前記フレームをデカプセル化するデカプセル化手段とを含むトンネリング手段と、
前記フレームの処理を行うカーネル手段と、
ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング手段と前記カーネル手段と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分手段とを備えている。
本発明によるトンネルフレーム振分方法は、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置に用いられるトンネルフレーム振分方法であって、
前記トンネリング装置が、前記フレームをカプセル化するカプセル化処理と、前記フレームをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング処理と前記カーネル処理と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分処理とを実行している。
本発明によるトンネルフレーム振分方法のプログラムは、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置に用いられるトンネルフレーム振分方法のプログラムであって、コンピュータに、前記フレームをカプセル化するカプセル化処理と、前記フレームをデカプセル化するデカプセル化処理とを含むトンネリング処理と、前記フレームの処理を行うカーネル処理と、ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング処理と前記カーネル処理と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分処理とを実行させている。
すなわち、本発明のトンネリング装置は、伝送媒体を介してデータリンク層フレームの送受信を行う装置において、フレームのカプセル化及びデカプセル化を行うトンネリング部と、自装置の論理アドレスから物理アドレスを検索する物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行う処理部と、入力されたフレームから少なくともカプセル化されているフレームとカプセル化されていないフレームとをトンネリング部や処理部に振り分けるフレーム振分部とを含んでいる。
本発明のトンネリング装置では、上記のような構成を備えることによって、同一のインタフェースから入力されるデータリンク層フレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレームにそれぞれ正しく振り分け、カプセル化やデカプセル化、さらに物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理が可能となり、上記の目的を達成することが可能となる。
つまり、上記の課題は、ローカルネットワークに対して１つの物理インタフェースのみを接続してカプセル化とデカプセル化とを可能とすることができれば解決することができるが、物理アドレス解決要求フレームを含むトンネリング装置へ送られるフレームや、デカプセル化を行うフレームや、カプセル化を行うフレーム等が同一のインタフェースから受信されるため、それらを正しく振り分けなければ、上記の課題の解決を達成することができない。
本発明のトンネリング装置では、上述した構成を備えることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワークに変更を加えることなく、ローカルネットワークに対して１つの物理インタフェースのみを接続して、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行い、同一の物理インタフェースから送信することが可能となる。
本発明は、以下に述べるような構成及び動作とすることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワークに変更を加えることなく、トンネリングを行うことができるという効果が得られる。
本発明によるトンネリング装置は、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置であって、
前記フレームをカプセル化するカプセル化手段と、前記フレームをデカプセル化するデカプセル化手段とを含むトンネリング手段と、
前記フレームの処理を行うカーネル手段と、
ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング手段と前記カーネル手段と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分手段とを備えている。
本発明によるトンネルフレーム振分方法は、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置に用いられるトンネルフレーム振分方法であって、
前記トンネリング装置が、前記フレームをカプセル化するカプセル化処理と、前記フレームをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング処理と前記カーネル処理と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分処理とを実行している。
本発明によるトンネルフレーム振分方法のプログラムは、相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置に用いられるトンネルフレーム振分方法のプログラムであって、コンピュータに、前記フレームをカプセル化するカプセル化処理と、前記フレームをデカプセル化するデカプセル化処理とを含むトンネリング処理と、前記フレームの処理を行うカーネル処理と、ローカルネットワークに接続されかつ前記フレームを入力経路とその内容とに応じて前記トンネリング処理と前記カーネル処理と前記ローカルネットワークとのうちの少なくとも一つへの振分けと当該フレームの破棄とのいずれかを行う振分処理とを実行させている。
すなわち、本発明のトンネリング装置は、伝送媒体を介してデータリンク層フレームの送受信を行う装置において、フレームのカプセル化及びデカプセル化を行うトンネリング部と、自装置の論理アドレスから物理アドレスを検索する物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行う処理部と、入力されたフレームから少なくともカプセル化されているフレームとカプセル化されていないフレームとをトンネリング部や処理部に振り分けるフレーム振分部とを含んでいる。
本発明のトンネリング装置では、上記のような構成を備えることによって、同一のインタフェースから入力されるデータリンク層フレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレームにそれぞれ正しく振り分け、カプセル化やデカプセル化、さらに物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理が可能となり、上記の目的を達成することが可能となる。
つまり、上記の課題は、ローカルネットワークに対して１つの物理インタフェースのみを接続してカプセル化とデカプセル化とを可能とすることができれば解決することができるが、物理アドレス解決要求フレームを含むトンネリング装置へ送られるフレームや、デカプセル化を行うフレームや、カプセル化を行うフレーム等が同一のインタフェースから受信されるため、それらを正しく振り分けなければ、上記の課題の解決を達成することができない。
本発明のトンネリング装置では、上述した構成を備えることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワークに変更を加えることなく、ローカルネットワークに対して１つの物理インタフェースのみを接続して、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行い、同一の物理インタフェースから送信することが可能となる。
本発明は、以下に述べるような構成及び動作とすることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワークに変更を加えることなく、トンネリングを行うことができるという効果が得られる。
図１は、本発明の実施の形態によるネットワークの構成を示すブロック図である。
図２は、図１のトンネリング装置の機能構成を示すブロック図である。
図３は、本発明の第１の実施例によるトンネリング装置の構成を示すブロック図である。
図４は、本発明の第１の実施例によるネットワークの構成においてトンネリング部のカプセル化手段としてＥｔｈｅｒＩＰを用いる時に送受信されるフレームの書式を示す図である。
図５は、本発明の第１の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図６は、本発明の第１の実施例によるネットワークの構成において送受信されるフレームの形式を示す図である。
図７は、本発明の第１の実施例によるネットワークの構成においてトンネリング部のカプセル化手段としてＥｔｈｅｒＩＰを用いる時のフレーム内容の変化とフレームの送受信とを示すシーケンスチャートである。
図８は、本発明の第１の実施例による送受信されるフレームの形式を示す図である。
図９は、図１に示すネットワークの中で送受信されるフレームに対する処理を示すシーケンスチャートである。
図１０は、本発明の第１の実施例によるネットワークの変形例を示すブロック図である。
図１１は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１２は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１３は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１４は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１５は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１６は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１７は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１８は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１９は、本発明の第４の実施例によるトンネリング装置の機能構成を示すブロック図である。
図２０は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２１は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２２は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２３は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２４は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２５は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２６は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２７は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２８は、本発明の第６の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２９は、本発明の第７の実施例によるトンネリング装置の機能構成を示すブロック図である。
図３０は、従来のデータリンク層で送受信されるフレームの形式を表す図である。
図３１は、従来のＥｔｈｅｒＩＰの形式を表す図である。
図３２は、従来の情報通信ネットワーク全体の構成を示すブロック図である。
１ トンネリング装置、２ 従来のトンネリング装置、３−１，３−２ ルータ ４−１〜４−Ｍ，５−１〜５−Ｎ 端末、６ ファイアウォール、１１ フレーム振分部、１２ カーネル部、１２ａ カーネル部（ＡＲＰ）、１３ トンネリング部、１４ ＣＰＵ、１５ メインメモリ、１５ａ 制御プログラム、１６記憶装置、１７ インタフェース部、１００ インタネット、１１１，１１３ フレーム振分手段、１１２ スイッチ手段、１１４ カーネル部（スタック）、１６１〜１６３ 経路（＃１〜＃３）アドレステーブル、２０１，２０２ ローカルネットワーク
図２は、図１のトンネリング装置の機能構成を示すブロック図である。
図３は、本発明の第１の実施例によるトンネリング装置の構成を示すブロック図である。
図４は、本発明の第１の実施例によるネットワークの構成においてトンネリング部のカプセル化手段としてＥｔｈｅｒＩＰを用いる時に送受信されるフレームの書式を示す図である。
図５は、本発明の第１の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図６は、本発明の第１の実施例によるネットワークの構成において送受信されるフレームの形式を示す図である。
図７は、本発明の第１の実施例によるネットワークの構成においてトンネリング部のカプセル化手段としてＥｔｈｅｒＩＰを用いる時のフレーム内容の変化とフレームの送受信とを示すシーケンスチャートである。
図８は、本発明の第１の実施例による送受信されるフレームの形式を示す図である。
図９は、図１に示すネットワークの中で送受信されるフレームに対する処理を示すシーケンスチャートである。
図１０は、本発明の第１の実施例によるネットワークの変形例を示すブロック図である。
図１１は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１２は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１３は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１４は、本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１５は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１６は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１７は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１８は、本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図１９は、本発明の第４の実施例によるトンネリング装置の機能構成を示すブロック図である。
図２０は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２１は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２２は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２３は、本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２４は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２５は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２６は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２７は、本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２８は、本発明の第６の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。
図２９は、本発明の第７の実施例によるトンネリング装置の機能構成を示すブロック図である。
図３０は、従来のデータリンク層で送受信されるフレームの形式を表す図である。
図３１は、従来のＥｔｈｅｒＩＰの形式を表す図である。
図３２は、従来の情報通信ネットワーク全体の構成を示すブロック図である。
１ トンネリング装置、２ 従来のトンネリング装置、３−１，３−２ ルータ ４−１〜４−Ｍ，５−１〜５−Ｎ 端末、６ ファイアウォール、１１ フレーム振分部、１２ カーネル部、１２ａ カーネル部（ＡＲＰ）、１３ トンネリング部、１４ ＣＰＵ、１５ メインメモリ、１５ａ 制御プログラム、１６記憶装置、１７ インタフェース部、１００ インタネット、１１１，１１３ フレーム振分手段、１１２ スイッチ手段、１１４ カーネル部（スタック）、１６１〜１６３ 経路（＃１〜＃３）アドレステーブル、２０１，２０２ ローカルネットワーク
次に、本発明の実施の形態について図面を参照して説明する。図１は本発明の実施の形態によるネットワークの構成を示すブロック図である。図１においては、Ｅｔｈｅｒｎｅｔ（登録商標）ＩＩ規格によって構成されているローカルネットワーク２０１，２０２をトンネリング装置１と従来のトンネリング装置２とを用いて接続する時のネットワークの構成を示している。
図１において、ローカルネットワーク２０１にはトンネリング装置１と、ルータ３−１と、端末４−１〜４−Ｍとが接続され、ローカルネットワーク２０２にはトンネリング装置２と、端末５−１〜５−Ｎとが接続されている。トンネリング装置２はルータ３−２及びインタネット１００を通してルータ３−１に接続されている。
図２は図１のトンネリング装置１の機能構成を示すブロック図である。図２において、トンネリング装置１はフレーム振分部１１と、カーネル部１２と、トンネリング部１３とから構成されている。フレーム振分部１１にはローカルネットワーク２０１に接続される経路＃１と、カーネル部１２に接続される経路＃２と、トンネリング部１３との間で非トンネリングフレーム（カプセル化されていないフレーム）の授受を行うための経路＃３と、トンネリング部１３との間でトンネリングフレーム（カプセル化されているフレーム）の授受を行うための経路＃４とが設けられている。
トンネリング部１３はローカルネットワーク２０１を介してデータリンク層フレームの送受信を行う際に、フレームのカプセル化及びデカプセル化を行う。カーネル部１２は自装置の論理アドレスから物理アドレスを検索する物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行う。フレーム振分部１１は入力されたフレームから少なくともトンネリングフレームと非トンネリングフレームとをトンネリング部１３やカーネル部１２に振り分ける。
本発明の実施の形態では、トンネリング装置１が上記のような構成を備えることによって、同一のインタフェースから入力されるデータリンク層フレームを、自装置で処理すきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレームにそれぞれ正しく振り分け、カプセル化やデカプセル化、さらに物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行うことができるので、ネットワークを一時停止させず、かつすでに構成されているローカルネットワーク２０１に変更を加えることなく、トンネリングを行うことができる。
つまり、本発明の実施の形態によるトンネリング装置１では、上述した構成を備えることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワーク２０１に変更を加えることなく、ローカルネットワーク２０１に対して１つの物理インタフェースのみを接続し、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行い、同一の物理インタフェースから送信することができる。
図１において、ローカルネットワーク２０１にはトンネリング装置１と、ルータ３−１と、端末４−１〜４−Ｍとが接続され、ローカルネットワーク２０２にはトンネリング装置２と、端末５−１〜５−Ｎとが接続されている。トンネリング装置２はルータ３−２及びインタネット１００を通してルータ３−１に接続されている。
図２は図１のトンネリング装置１の機能構成を示すブロック図である。図２において、トンネリング装置１はフレーム振分部１１と、カーネル部１２と、トンネリング部１３とから構成されている。フレーム振分部１１にはローカルネットワーク２０１に接続される経路＃１と、カーネル部１２に接続される経路＃２と、トンネリング部１３との間で非トンネリングフレーム（カプセル化されていないフレーム）の授受を行うための経路＃３と、トンネリング部１３との間でトンネリングフレーム（カプセル化されているフレーム）の授受を行うための経路＃４とが設けられている。
トンネリング部１３はローカルネットワーク２０１を介してデータリンク層フレームの送受信を行う際に、フレームのカプセル化及びデカプセル化を行う。カーネル部１２は自装置の論理アドレスから物理アドレスを検索する物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行う。フレーム振分部１１は入力されたフレームから少なくともトンネリングフレームと非トンネリングフレームとをトンネリング部１３やカーネル部１２に振り分ける。
本発明の実施の形態では、トンネリング装置１が上記のような構成を備えることによって、同一のインタフェースから入力されるデータリンク層フレームを、自装置で処理すきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレームにそれぞれ正しく振り分け、カプセル化やデカプセル化、さらに物理アドレス解決要求フレームを含む自装置で処理すべきフレームの処理を行うことができるので、ネットワークを一時停止させず、かつすでに構成されているローカルネットワーク２０１に変更を加えることなく、トンネリングを行うことができる。
つまり、本発明の実施の形態によるトンネリング装置１では、上述した構成を備えることで、ネットワークを一時停止させず、かつすでに構成されているローカルネットワーク２０１に変更を加えることなく、ローカルネットワーク２０１に対して１つの物理インタフェースのみを接続し、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行い、同一の物理インタフェースから送信することができる。
図３は本発明の第１の実施例によるトンネリング装置の構成を示すブロック図である。本発明の第１の実施例によるネットワークは図１に示す本発明の実施の形態によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は図２に示す本発明の実施の形態によるトンネリング装置と同様の機能を有している。
図３において、本発明の第１の実施例によるトンネリング装置１はＣＰＵ（中央処理装置）１４と、ＣＰＵ１４が実行する制御プログラム１５ａを記憶するメインメモリ１５と、図２に示す経路＃１〜＃３毎に物理アドレスを保持する経路（＃１〜＃３）アドレステーブル１６１〜１６３を備えた記憶装置１６と、ローカルネットワーク２０１に接続される物理インタフェースであるインタフェース部１７とから構成されている。
本発明の第１の実施例によるトンネリング装置１では、ＣＰＵ１４が制御プログラム１５ａを実行し、記憶装置１６の経路（＃１〜＃３）アドレステーブル１６１〜１６３を用いて処理を実行することで、図２に示すフレーム振分部１１、カーネル部１２、トンネリング部１３の各機能の処理を実現している。以下の説明では、これらフレーム振分部１１、カーネル部１２、トンネリング部１３の各機能を用いて説明する。
図４は本発明の第１の実施例によるネットワークの構成においてトンネリング部１３のカプセル化手段としてＥｔｈｅｒＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いる時に送受信されるフレームの書式を示す図である。図５は本発明の第１の実施例によるフレーム振分部１１におけるフレームの振分処理を示すフローチャートである。これら図１〜図５を参照して本発明の第１の実施例によるトンネリング装置１の動作について説明する。尚、図５に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
以下の説明では、ローカルネットワーク２０１，２０２にはＥｔｈｅｒｎｅｔ（登録商標）ＩＩ規格を用い、ローカルネットワーク２０１，２０２間を接続するネットワークはＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）によって接続されるインタネット１００を想定しているが、Ｅｔｈｅｒｎｅｔ（登録商標）ＩＩ規格は任意のデータリンク層プロトコル、ＩＰｖ４は任意のネットワーク層プロトコルでも適用可能である。
まず、図４を参照してインタネットで一般的に用いられているフレームの書式について説明する。図４のＭＡＣヘッダ３０１はデータリンク層フレームのヘッダであり、Ｅｔｈｅｒｎｅｔ（登録商標）ＩＩ規格によって構成されているローカルネットワーク２０１，２０２上で実際に送受信されているすべてのフレームの先頭に共通して存在している領域である。ＭＡＣヘッダ３０１には、主に物理アドレスである「宛先ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス」と「送信元ＭＡＣアドレス」と上位層の種別を表す「タイプ」とが含まれている。
トンネリング装置１，２からローカルネットワーク２０１，２０２に送信されたフレームはすべての端末４−１〜４−Ｍ，５−１〜５−Ｎで受信されるが、効率化のためにフレームを中継する際に「宛先ＭＡＣアドレス」をチェックして不必要なフレームの中継を行わないようにする中継装置もある。ローカルネットワーク２０１，２０２に接続される装置は物理アドレスであるＭＡＣアドレスを保持し、自身の物理インタフェースからフレームを受信した際に、「宛先ＭＡＣアドレス」が自装置であるか、ブロードキャストである場合に受信処理を行う。
この仕組みによって、ローカルネットワーク２０１，２０２に接続する装置は、目的の装置のＭＡＣアドレスをＭＡＣヘッダ３０１の「宛先ＭＡＣアドレス」に指定したフレームを送信することによって、目的の装置にて受信させることが可能となっている。
ＩＰｖ４ヘッダ３０２はネットワーク層パケットのヘッダとしてＭＡＣヘッダ３０１の後ろに続いて設定される領域であり、ＭＡＣヘッダ３０１のタイプには「０ｘ０８００」が指定されることによって、ＩＰｖ４ヘッダ３０２が続いていることが識別される。このＩＰｖ４ヘッダ３０２には、主に上位層の種別を表す「プロトコル」と、論理アドレスである「送信元ＩＰアドレス」と、「宛先ＩＰアドレス」とが含まれている。
インタネット１００はローカルネットワークの集合体であり、ＭＡＣアドレスを指定して送信できる範囲はそれぞれのローカルネットワーク内に限られるため、ローカルネットワーク２０１，２０２同士でＩＰアドレスを用いて通信を行うことができるように、ローカルネットワーク２０１，２０２を接続する経路選択装置であるルータ３−１，３−２が存在している。ルータ３−１，３−２はフレームを受信するたびにＩＰｖ４ヘッダ３０２の宛先ＩＰアドレスをチェックし、最適な次のルータへと送信していく。この時、宛先や送信元となるルータ３−１，３−２のＭＡＣアドレスは毎回異なるので、ＭＡＣヘッダ３０１の内容も変化していく。このようにして、最終的に目的のＩＰアドレスを持つ装置へデータが到着して受信され、ＩＰアドレスを用いて離れたローカルネットワークの装置へとデータを送信することが可能となっている。
ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）３０３はＭＡＣヘッダ３０１に続いて指定されるデータ領域であり、ＭＡＣヘッダ３０１のタイプには「０ｘ０８０６」が指定されることによって、ＡＲＰ３０３が続いていることが識別される。ＡＲＰ３０３は物理アドレス解決要求フレームと、物理アドレス解決応答フレームとの役割をにない、主にこのフレームが要求か応答かを示す「オペレーション」と、「送信元ＭＡＣアドレス」と、「送信元ＩＰアドレス」と、「宛先ＭＡＣアドレス」と、「宛先ＩＰアドレス」とを含んでおり、既知のＩＰアドレスからそのＩＰアドレスを持つ装置のＭＡＣアドレスを知るために用いられる。
尚、ＡＲＰ３０３はＩＰｖ４ヘッダ３０２とは同時に用いられないので、ローカルネットワーク２０１，２０２内でのみ有効なフレームである。ＭＡＣアドレスを知りしたいと思う装置は、自身のＭＡＣアドレスとＩＰアドレスとを送信元ＭＡＣアドレス、送信元ＩＰアドレスとして含め、目的の装置のＩＰアドレスを送信先ＩＰアドレスとして含め、オペレーションを「要求」とするＡＲＰ３０３を作成し、ＭＡＣヘッダ３０１の宛先アドレスはブロードキャストとしてローカルネットワーク２０１，２０２に送信する。
このフレームを受信した各装置は送信先ＩＰアドレスと自身のＩＰアドレスとを比較し、同一でない場合にはそのフレームを破棄する。同一であった場合には、自身のＭＡＣアドレスとＩＰアドレスとを送信元ＭＡＣアドレス、送信元ＩＰアドレスとして含め、受信したＡＲＰ３０３の送信元ＭＡＣアドレス、送信元ＩＰアドレスをそれぞれ宛先ＭＡＣアドレス、宛先ＩＰアドレスとし、オペレーションを「応答」とするＡＲＰ３０３を作成し、ＭＡＣヘッダ３０１の宛先アドレスは受信したＡＲＰ３０３の送信元ＭＡＣアドレスとしてローカルネットワーク２０１，２０２に送信する。これによって、目的のＭＡＣアドレスが返送される形になり、ＭＡＣアドレスを知りしたいと思う装置は、目的のＭＡＣアドレスを得ることができる。
ＥｔｈｅｒＩＰヘッダ３０４は、ＩＰｖ４ヘッダ３０２に続くヘッダであり、ＩＰｖ４ヘッダ３０２のプロトコルに「０ｘ６１」が指定されることによって、ＥｔｈｅｒＩＰヘッダ３０４が続いていることが識別される。ＥｔｈｅｒＩＰヘッダ３０４の内容はバージョン番号のみで、設定すべき部分はない。
ＥｔｈｅｒＩＰヘッダ３０４の後にはＭＡＣヘッダ３０１が続く。すなわち、ＥｔｈｅｒＩＰヘッダ３０４を用いれば、ローカルネットワーク２０１，２０２で送受信されるフレームをそのままデータとして含め、それを指定されたＩＰアドレスへむけてそのまま送信することができるようになる。
これを用いて、受信したフレームをＥｔｈｅｒＩＰヘッダ３０４の後ろに含めて新たにフレームを作成することでフレームのカプセル化を行うことができ、受信したフレームのＥｔｈｅｒＩＰヘッダ３０４以降のフレームを取出すことによってデカプセル化を行うことができる。
フレーム振分部１１はローカルネットワーク２０１に接続され、ローカルネットワーク２０１で送受信されるデータリンク層のデータ系列であるイーサネット（登録商標）フレームを送受信する。フレーム振分部１１では各経路＃１〜＃４からそのイーサネット（登録商標）フレームを含むフレームを受信すると、経路＃１〜＃４のどの経路から入力されたかを判定する（図５ステップＳ１）。
フレーム振分部１１は経路＃２〜＃４の各経路から入力されると、そのフレームを経路＃１へと出力する（図５ステップＳ２）。つまり、フレーム振分部１１はカーネル部１２で処理されて経路＃２から入力されるフレーム、トンネリング部１３でデカプセル化されて経路＃３から入力されるフレーム、トンネリング部１３でカプセル化されて経路＃４から入力されるフレームをそれぞれそのまま経路＃１を介してローカルネットワーク２０１へと出力する。
これに対し、フレーム振分部１１は経路＃１からフレームが入力されると、そのフレームの宛先物理アドレスが同報アドレスであれば（図５ステップＳ３）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃２，＃３へと出力する（図５ステップＳ４）。
フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスで（図５ステップＳ５）、宛先論理アドレスが自装置の論理アドレスで（図５ステップＳ６）、送信元論理アドレスが特定装置の論理アドレスで（図５ステップＳ７）、そのフレームで用いてられているカプセル化方式が自装置で用いているカプセル化方式であれば（図５ステップＳ８）、そのフレームはトンネリング先のトンネリング装置２からのものであるので、そのフレームを経路＃４へと出力する（図５ステップＳ９）。
フレーム振分部１１は宛先物理アドレスが自装置の物理アドレスであっても（図５ステップＳ５）、宛先論理アドレス、送信元論理アドレス、フレームで用いてられているカプセル化方式がそれぞれ上記の条件を満たしていなければ、そのフレームを経路＃２へと出力する（図５ステップＳ１０）。
一方、フレーム振分部１１は宛先物理アドレスが自装置の物理アドレスでなければ（図５ステップＳ５）、経路＃３へと出力し（図５ステップＳ１１）、そのフレームに対してトンネリング部１３にてカプセル化を行う。このカプセル化されたフレームは経路＃４を介してフレーム振分部１１に入力されるので、フレーム振分部１１から経路＃１を通してローカルネットワーク２０１へと出力される。
このような特徴を持つことによって、従来のトンネリング装置２はローカルネットワーク２０２とルータ３−２との間で、一度ネットワークを切断し、その間に挟みこむように接続する必要があるが、本実施例によるトンネリング装置１は、従来のネットワーク構成に変更を加えることなく、単純にローカルネットワーク２０１に接続するだけで動作させることが可能となる。
上述したように、トンネリング装置１はフレーム振分部１１と、１つ以上のトンネリング部１３と、カーネル部１２とを備えている。フレーム振分部１１の物理インタフェースは１つのみであり（図２では経路＃１として図示）、ローカルネットワーク２０１からローカルネットワーク２０２へカプセル化して送信すべきフレーム、トンネリング装置１から送られるカプセル化されたフレーム、トンネリング装置１宛に送られてくるフレームをすべて１つの物理インタフェースにおいて受信し、デカプセル化したフレーム、カプセル化したフレーム、並びにトンネリング装置１自身から送信されるフレームも、同一の物理インタフェースから送信する。
つまり、フレーム振分部１１は物理インタフェースを通してローカルネットワーク２０１からイーサネット（登録商標）フレームを受信し、経路＃２〜＃４から入力したイーサネット（登録商標）フレームをローカルネットワーク２０１へと送信する。
一般的な物理インタフェースは自身の物理アドレスとしてＭＡＣアドレスを保持しており、宛先ＭＡＣアドレスが自機器のＭＡＣアドレスであるか、ブロードキャストアドレスである場合にのみ受信を行うが、トンネリング装置１の物理インタフェースはすべてのイーサネット（登録商標）フレームをそのまま受信し、フレーム振分部１１へと出力する。
フレーム振分部１１は物理インタフェースから入力したイーサネット（登録商標）フレームが、カプセル化されているトンネルフレームであるか否かを判定し、トンネルフレームであるイーサネット（登録商標）フレームを経路＃４を介してトンネリング部１３へ出力し、トンネルフレームではないフレームを経路＃３を介してトンネリング部１３へと出力するとともに、経路＃２を介してカーネル部１２へと出力する。
フレーム振分部１１でトンネルフレームであるか否かを判定する方法としては、そのフレームのトンネリングがどのような技術で実施されているかによって異なるが、ほとんどの場合には、データリンク層ヘッダの宛先アドレスが自装置の物理アドレスであり、ネットワーク層ヘッダの送信元アドレスがトンネリングを行っている相手のトンネリング装置２の論理アドレスであり、かつフレームの種別、すなわちネットワーク層ヘッダ以降の特徴が、トンネリング技術特有のものであるフレームをトンネルフレームであると判断する。
具体的には、例えばＥｔｈｅｒＩＰによってＩＰｖ４パケットにカプセル化を行うトンネリング装置１の場合、フレーム振分部１１は受信したフレームの宛先ＭＡＣアドレスがトンネリング装置１自身のＭＡＣアドレスであり、送信元ＩＰアドレスがトンネリング装置２のＩＰアドレスであり、ＩＰｖ４ヘッダのプロトコル番号が「０ｘ６１」であるフレームをトンネルフレームと判定する。
さらに、イーサネット（登録商標）をＨＴＴＰＳ［ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） ｏｖｅｒ ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）］等の、本来の用途とは異なるプロトコルにカプセル化する場合には、さらに特段の配慮が必要である。ＨＴＴＰＳはＷｅｂサーバとブラウザ等のクライアントとの間でデータを送受信するために使われるプロトコルであるＨＴＴＰプロトコルに暗号化の処理が加わったプロトコルである。
しかしながら、これを用いてイーサネット（登録商標）フレームのカプセル化を行っている場合には、トンネリング装置１とトンネリング装置２との間でＨＴＴＰＳを用いた本来の通信したいと思っても、そのＨＴＴＰＳによる通信に関するフレームもトンネルフレームであると判定されてしまう。
この場合、フレーム振分部１１は一度すべてのＨＴＴＰＳのフレームをトンネリング部１３へ出力し、トンネリング部１３にてデカプセル化を行う際に、デカプセル化ができなかったフレームについて、フレーム振分部１１へと差し戻して経路＃２に出力するか、フレーム振分部１１において、トンネリング部１３で行っているデカプセル化の試行をして判断するか、フレームのカプセル化が行われているＨＴＴＰＳが他のＨＴＴＰＳとは異なる特徴を抽出する等して判定を行う。
また、トンネリング技術としては、タグＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を用いてもよく、その場合には、タグＶＬＡＮ付きのイーサネット（登録商標）フレームをトンネルフレームと判断してよい。
フレーム振分部１１は上述した記憶装置１６の経路（＃１〜＃３）アドレステーブル１６１〜１６３に、各経路＃１〜＃３から入力されるフレームの送信元ＭＡＣアドレスを記憶する。フレーム振分部１１はフレームを出力する前に、これら経路（＃１〜＃３）アドレステーブル１６１〜１６３において宛先ＭＡＣアドレスの検索を行う。
フレーム振分部１１は宛先ＭＡＣアドレスが発見できた場合、発見できた経路（＃１〜＃３）アドレステーブル１６１〜６３に対応する経路＃１〜＃３のいずれかへ向けて出力し、宛先ＭＡＣアドレスを発見できなかった場合（ブロードキャストアドレスを含む）、経路＃１〜＃４すべてへ出力する。但し、そのフレームが入力された経路へは出力しない。
トンネリング部１３が複数存在する場合には、それぞれ別々に扱われ、例えば、第１のトンネリング部から入力したフレームが、第２のトンネリング部へと出力されてもよい。
経路＃２アドレステーブル１６２には予め固定的にトンネリング装置１のＭＡＣアドレスを関連付けて記憶する。こうすることによって、トンネリング装置１宛に送られてきたフレームで、トンネリングフレームでないフレームはカーネル部１２へと出力されることになる。
遠隔地であるローカルネットワーク２０２から発せられたフレームも、上記と同様である。例えば、ローカルネットワーク２０２の端末５−１〜５−Ｎからトンネリング装置１のＭＡＣアドレスを宛先として指定して送信されたフレームは、トンネリング装置２でカプセル化され、トンネリング装置１で受信され、トンネリング部１３でデカプセル化された後、カーネル部１２へと出力されることで処理される。
さらに、カーネル部１２でそのフレームの返信として、宛先ＭＡＣアドレスを先のフレームの送信元ＭＡＣアドレスとするフレームを出力すると、そのＭＡＣアドレスは経路＃３アドレステーブル１６３に記憶されているので、トンネリング部１３（経路＃３）へと出力されてカプセル化され、最終的にローカルネットワーク２０２の目的の端末において受信されることになる。
経路＃３アドレステーブル１６３においては、トンネリング部１３が２つ以上存在する場合、それぞれを区別して異なる出力先として記憶する。同一のＭＡＣアドレスが他の経路アドレステーブルにすでに記憶されている場合には、他の経路アドレステーブルに記憶されたアドレスが削除される。一定期間登録がないものについては削除する。
フレーム振分部１１は上記の経路（＃１〜＃３）アドレステーブル１６１〜１６３との組み合わせで、一般的なスイッチングハブと同様の動作を行うが、カーネル部１２へは宛先ＭＡＣアドレスがトンネリング装置１のＭＡＣアドレスではなく、かつブロードキャストアドレスではないフレームを出力しないことが異なる。これによって、不必要なフレームがカーネル部１２へと出力されることを防ぐ。
トンネリング部１３はカプセル化手段とデカプセル化手段とを備え、フレーム振分部１１から経路＃３を通して入力したフレームをカプセル化手段へと出力し、フレーム振分部１１から経路＃４を通して入力したフレームをデカプセル化手段へと出力する。
カプセル化手段は入力したフレームを、接続先のトンネリング装置２のＩＰアドレスを宛先ＩＰアドレスとするフレームにカプセル化し、経路＃４へと出力する。デカプセル化手段は入力したフレームをデカプセル化し、経路＃３へと出力する。
トンネリング部１３は１つだけではなく、複数存在していても良く、かつ、それぞれのトンネリング技術が異なっていても良い。また、接続先もそれぞれのトンネリング部で異なっていても良い。こうすることによって、複数のトンネリング装置を中継するトンネリング装置や、異なるトンネリング技術を中継するトンネリング装置等を構成することも可能である。
フレーム振分部１１において説明したように、デカプセル化手段はデカプセル化できないフレームを入力した場合、そのフレームをフレーム振分部１１へ差し戻しても良い。
カーネル部１２はトンネリング装置１で処理すべきフレームをフレーム振分部１１から入力して適宜処理をしたり、その処理の結果をフレーム振分部１１へ出力して送信したりする。また、カーネル部１２はトンネリング装置１からエラーやトラフィックの報告等、何らかの通知を出力して送信してもよい。
カーネル部１２で処理する内容としては、ローカルネットワーク２０１，２０２から受信した物理アドレス解決要求フレームへの応答としての物理アドレス解決応答フレームの送信があり、またデフォルトゲートウェイの物理アドレス取得のための物理アドレス解決要求フレームの送信と、その応答としての物理アドレス解決応答フレームの受信とデフォルトゲートウェイのＭＡＣアドレスの記憶装置１６への記憶とがある。
さらに、本実施例では、トンネリング装置１のＩＰアドレス等の各種設定を遠隔で行うためや、エラーやトラフィックの報告等の通知のために、ＨＴＴＰ、ＨＴＴＰＳ、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）等任意のプロトコルを用いて送受信してもよい。また、生存確認のため等に使われるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）の送受信を行っても良い。
記憶装置１６はさらに、自装置の物理アドレスと、自装置の論理アドレスと、１つ以上のトンネリング先の論理アドレスと、デフォルトゲートウェイの論理アドレスと、デフォルトゲートウェイの物理アドレスとを記憶する。トンネリング先の論理アドレスは、タグＶＬＡＮの場合、タグの番号になってもよい。
次に、トンネリング装置１の物理インタフェース部１１で受信されるイーサネット（登録商標）フレームの種類について整理し、それぞれのフレームの送受信のシーケンスについて説明する。
トンネリング装置１にて受信されるフレームの種類は主に以下の４つに分けられる。１つ目は、トンネリング装置１のカーネル部１２に対して送るべきフレームである。カーネル部１２はトンネリング装置１で処理すべきトンネル以外のすべてのフレームであり、これにはＡＲＰ３０３や、トンネリング装置１のＩＰアドレスや接続先のトンネリング装置２のＩＰアドレス、デフォルトゲートウェイのＩＰアドレス等をＷｅｂで設定する場合のＨＴＴＰ等も含まれる。
２つ目は、トンネリング装置２から送られたトンネルフレームである。３つ目はトンネリング装置２へカプセル化して送るべきフレームである。４つ目は破棄すべきフレームである。
以下の説明では、記憶装置１６において、自装置のＭＡＣアドレスとして「ＭＡＣ１２１」、自身のＩＰアドレスとして「ＩＰ２２１」、トンネリング先のＩＰアドレスとして「ＩＰ２２２」、デフォルトゲートウェイのＩＰアドレスとしてルータ３−１の「ＩＰ２１１」が設定されているものとする。
図６は本発明の第１の実施例によるネットワークの構成において送受信されるフレームの形式を示す図であり、図７は本発明の第１の実施例によるネットワークの構成においてトンネリング部１３のカプセル化手段としてＥｔｈｅｒＩＰを用いる時のフレーム内容の変化とフレームの送受信とを示すシーケンスチャートである。これら図１〜図７とを参照してカーネル部１２へ送るべきフレームについて説明する。
カーネル部１２へ送るべきフレームの中で最も重要なフレームは、物理アドレス解決要求フレームである。具体的には、ＡＲＰ３０３のオペレーションが「要求」となっているＡＲＰ要求フレーム３１０（図６参照）である。物理アドレス解決要求フレームはローカルネットワーク２０１またはローカルネットワーク２０２に接続する装置で、トンネリング装置１のＩＰアドレスを指定して送信したいと思う場合に必要となる。
以下では、カーネル部１２へ送るべきフレームの例として、ローカルネットワーク２０１に接続する端末４−Ｍからトンネリング装置１へＩＰパケットを送信する場合を想定し、物理アドレス解決要求フレームであるＡＲＰ要求フレーム３１０を送り、トンネリング装置１から物理アドレス解決応答フレームであるＡＲＰ応答フレーム３１１（図６参照）が返信され、トンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」が判明し、そのＭＡＣアドレスを用いてＩＰパケットを送信するまでの動作について説明する。
端末４−Ｍはトンネリング装置１のＩＰアドレスである「ＩＰ２２１」に向けてＩＰパケットを送信しようとしているが、トンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」が不明なので、フレームを作成することができない。そこで、端末３−ＭはＡＲＰ要求フレーム３１０を作成し、「ＭＡＣ１２１」の取得を試みる。
ＡＲＰ要求フレーム３１０は宛先ＭＡＣアドレスをブロードキャストアドレスとし、送信元ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、タイプを「０ｘ０８０６」とするＭＡＣヘッダ３０１と、それに続くオペレーションを「要求」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３１」とし、送信元ＩＰアドレスを「ＩＰ２３１」とし、宛先ＭＡＣアドレスには何も設定せず、宛先ＩＰアドレスを「ＩＰ２２１」とするＡＲＰ３０３によって構成される。
このＡＲＰ要求フレーム３１０は端末４−Ｍからローカルネットワーク２０１へとブロードキャスト送信される。トンネリング装置１以外の装置は、宛先ＩＰアドレスが自装置のＩＰアドレスではないので、このフレームを無視する。
トンネリング装置１のフレーム振分部１１は物理インタフェースを通してＡＲＰ要求フレーム３１０を受信すると、ＡＲＰ要求フレーム３１０の宛先ＭＡＣアドレスがブロードキャストアドレス（同報アドレス）であるので（図５ステップＳ１，Ｓ３）、経路＃２を通してカーネル部１２へ出力するとともに、経路＃３を通してトンネリング部１３へ出力する（図５ステップＳ４）。
トンネリング部１３へ出力されたＡＲＰ要求フレーム３１０については、ＥｔｈｅｒＩＰによってカプセル化され、経路４を通してフレーム振分部１１に送られ、フレーム振分部１１から経路＃１を通してローカルネットワーク２０１へと送信される（図５ステップＳ２）。このフレームはローカルネットワーク２０１からルータ３−１、インタネット１００、ルータ３−２を通してトンネリング装置２へ到達し、デカプセル化されてローカルネットワーク２０２に送信される。ローカルネットワーク２０２では「ＩＰ２３１」を持つ装置がないため、応答は起こらない。
カーネル部１２へ出力されたＡＲＰ要求フレーム３１０については、ＡＲＰフレームであるかどうかがチェックされた後、ＡＲＰ要求であるかどうかがチェックされる。さらに、ＡＲＰ要求フレーム３１０はＡＲＰ３０３の宛先ＩＰアドレスが記憶装置１６に記憶されている自装置のＩＰアドレスである「ＩＰ２２１」に一致するため、カーネル部１２は物理アドレス解決応答フレームであるＡＲＰ応答フレーム３１１の作成を行う。
ＡＲＰ応答フレーム３１１は宛先ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、送信元ＭＡＣアドレスをトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」とし、タイプを「０ｘ０８０６」とするＭＡＣヘッダ３０１と、それに続くオペレーションを「応答」とし、送信元ＭＡＣアドレスを「ＭＡＣ１２１」とし、送信元ＩＰアドレスを「ＩＰ２２１」とし、宛先ＭＡＣアドレスを「ＭＡＣ１３１」とし、宛先ＩＰアドレスを「ＩＰ２３１」とするＡＲＰ３０３によって構成される。
このＡＲＰ応答フレーム３１１はカーネル部１２から経路＃２を通してフレーム振分部１１へと出力される。フレーム振分部１１は経路＃２を通して入力されたカーネル部１２からのＡＲＰ応答フレーム３１１を、物理インタフェース（経路＃１）を通してローカルネットワーク２０１へと送信する（図５ステップＳ２）。端末４−Ｍはローカルネットワーク２０１からＡＲＰ応答フレーム３１１を受信し、目的のトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」を取得する。
最後に、端末４−Ｍは宛先ＭＡＣアドレスをトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」とし、送信元ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、タイプを「０ｘ０８００」とするＭＡＣヘッダ３０１と、それに続いて、送信しようとしていたＩＰパケットである送信元ＩＰアドレスを「ＩＰ２２１」、宛先ＩＰアドレスを「ＩＰ２３１」とするＩＰｖ４ヘッダ３０２と、それに続いて、上位層データを付加したフレーム３２２をローカルネットワーク２０１へと送信する。
フレーム３２２はトンネリング装置１の物理インタフェースを通してフレーム振分部１１で受信され、フレーム振分部１１はフレーム３２２の宛先ＭＡＣアドレスが自装置のＭＡＣアドレスであり（図５ステップＳ５）、ＩＰｖ４フレームであるが、送信元ＩＰアドレスが特定装置の論理アドレス（接続先のトンネリング装置２のＩＰアドレス）ではないので（図５ステップＳ７）、経路＃２を通してカーネル部１２へ出力する（図５ステップＳ１０）。カーネル部１２ではフレーム３２２がＡＲＰフレームではないので、その他のアプリケーション用のフレームとして扱う。
このようにして、端末４−Ｍから送信しようとしていたＩＰパケットは、正しくカーネル部１２へと到達する。以降、端末４−Ｍはトンネリング装置１のＭＡＣアドレスを記憶しているので、続けてＩＰパケットを送信し続けることができる。
次に、デカプセル化すべきフレームとカプセル化すべきフレームとについて説明する。図８は本発明の第１の実施例による送受信されるフレームの形式を示す図であり、図９は図１に示すネットワークの中で送受信されるフレームに対する処理を示すシーケンスチャートである。
デカプセル化すべきフレームとはトンネリング装置２から送られ、トンネリング装置１にてデカプセル化すべきフレームのことである。カプセル化すべきフレームとはローカルネットワーク２０１で送信され、ローカルネットワーク２０２で受信されるべきフレームのことである。
以下、ローカルネットワーク２０２に接続する端末５−Ｎがローカルネットワーク２０１に接続する端末４−Ｍにフレームを送信し、その応答が端末４−Ｍから端末５−Ｎへと送信され、端末５−Ｎで受信されるまでの動作について説明する。
端末５−Ｎは端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」をすでに知っているものとする。端末５−Ｎは宛先ＭＡＣアドレスを「ＭＡＣ１３１」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３２」とするＭＡＣヘッダ３０１を含むフレーム３２３をローカルネットワーク２０２へ送信する。
トンネリング装置２はフレーム３２３を受信すると、ＥｔｈｅｒＩＰによってカプセル化を行い、宛先ＩＰアドレスをトンネリング装置１のＩＰアドレスである「ＩＰ２２１」とし、送信元ＩＰアドレスをトンネリング装置２のＩＰアドレスである「ＩＰ２２２」とするＩＰｖ４ヘッダ３０２を付加したパケット３２４を作成し、ルータ３−２を通してインタネット１００へ送信する。パケット３２４はイーサネット（登録商標）を含む様々なデータリンク層ヘッダを付け替えながら転送され、最終的にルータ３−１にまで到達する。
ルータ３−１はパケット３２４の宛先ＩＰアドレスが「ＩＰ２２１」になっているので、対応するＭＡＣアドレスである「ＭＡＣ１２１」を宛先ＭＡＣアドレスとし、自装置のＭＡＣアドレスである「ＭＡＣ１１１」を送信元ＭＡＣアドレスとするＭＡＣヘッダ３０１を付加したフレーム３２５を作成し、ローカルネットワーク２０１へ送信する。もし、「ＭＡＣ１２１」が既知ではなかった場合、ルータ３−１はＡＲＰ要求フレームを送信し、目的の「ＭＡＣ１２１」の取得を試み、「ＭＡＣ１２１」を取得してからフレーム３２５を作成する。
ローカルネットワーク２０１へ送信されたフレーム３２５は、トンネリング装置１の物理インタフェース（経路＃１）を通してフレーム振分部１１にて受信される。宛先ＭＡＣアドレスはルータ３−１によってトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」に設定されており（図５ステップＳ５）、ＩＰｖ４フレームであり、送信元ＩＰアドレスがトンネリング装置２で設定されたＩＰアドレスである「ＩＰ２２２」になっており（図５ステップＳ７）、ＩＰｖ４ヘッダ３０２のプロトコルが「０ｘ６１」に指定されている（図５ステップＳ８）。
よって、フレーム振分部１１はフレーム３２５をトンネルフレームであると判定し、経路＃４を通してトンネリング部１３へ出力する（図５ステップＳ９）。トンネリング部１３はフレーム３２５に含まれるカプセル化されたフレーム３２３を取出し、フレーム３２３を経路＃３を通してフレーム振分部１１へ出力する。
フレーム振分部１１は経路＃３から入力されたフレーム３２３を、物理インタフェース（経路＃１）を通してローカルネットワーク２０１へ送信する（図５ステップＳ１，Ｓ２）。端末４−Ｍはローカルネットワーク２０１からフレーム３２３を受信する。こうして、端末５−Ｎから送信されたフレーム３２３は、正しく端末４−Ｍで受信される。
端末４−Ｍは宛先ＭＡＣアドレスを端末５−ＮのＭＡＣアドレスである「ＭＡＣ１３２」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３１」とするＭＡＣヘッダ３０１を含むフレーム３２６をローカルネットワーク２０１へ送信する。トンネリング装置１のフレーム振分部１１は物理インタフェース（経路＃１）を通してフレーム３２６をローカルネットワーク２０１から受信し、フレーム３２６の宛先ＭＡＣアドレスが自装置のＭＡＣアドレスではないので（図５ステップＳ５）、そのフレーム３２６を経路＃３を通してトンネリング部１３へ出力する（図５ステップＳ１１）。
トンネリング部１３はフレーム３２６をＥｔｈｅｒＩＰにてカプセル化し、パケット３２７を作成する。パケット３２７は経路＃４を通してフレーム振分部１１に送られ、フレーム振分部１１から物理インタフェース（経路＃１）を通してローカルネットワーク２０１へと送信される（図５ステップＳ２）。その後、パケット３２７はルータ３−１、インタネット１００、ルータ３−２を介してトンネリング装置２へ到達する。トンネリング装置２は受信したパケット３２７をデカプセル化し、元のフレーム３２６をローカルネットワーク２０２へ送信し、端末５−Ｎはこれを受信する。こうして、端末４−Ｍから送信されたフレーム３２６は端末５−Ｎで正しく受信される。
このように、本実施例では、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行うことができるので、ネットワークを一時停止させず、すでに構成されているローカルネットワーク２０１，２０２に変更を加えることなく、ローカルネットワーク２０１に対してトンネリング装置１の１つの物理インタフェースのみを接続することで、トンネリングを行うことができる。
図１０は本発明の第１の実施例によるネットワークの変形例を示すブロック図である。図１０に示すネットワーク例では、インタネット１００とルータ３−１との間にファイアウォール６を設けた以外は図１に示す本発明の実施の形態によるネットワークと同様の構成となっている。この場合、トンネリング装置２からトンネリング装置１へ送信されるフレームの宛先論理アドレスはファイアウォール６のＩＰアドレス「ＩＰ２４１」となり、ファイアウォール６にて宛先論理アドレスが「ＩＰ２２１」へ付け替えられてトンネリング装置１へと送信される。さらに、送信元論理アドレスが「ＩＰ２４２」へ付け替えられることもあり、この場合にはトンネリング装置１が特定装置の論理アドレスを「ＩＰ２４２」として記憶する。また、ファイアウォールはアドレス変換装置であってもよい。この点以外の動作は上述した本発明の第１の実施例の動作と同様であるので、その説明は省略する。
図３において、本発明の第１の実施例によるトンネリング装置１はＣＰＵ（中央処理装置）１４と、ＣＰＵ１４が実行する制御プログラム１５ａを記憶するメインメモリ１５と、図２に示す経路＃１〜＃３毎に物理アドレスを保持する経路（＃１〜＃３）アドレステーブル１６１〜１６３を備えた記憶装置１６と、ローカルネットワーク２０１に接続される物理インタフェースであるインタフェース部１７とから構成されている。
本発明の第１の実施例によるトンネリング装置１では、ＣＰＵ１４が制御プログラム１５ａを実行し、記憶装置１６の経路（＃１〜＃３）アドレステーブル１６１〜１６３を用いて処理を実行することで、図２に示すフレーム振分部１１、カーネル部１２、トンネリング部１３の各機能の処理を実現している。以下の説明では、これらフレーム振分部１１、カーネル部１２、トンネリング部１３の各機能を用いて説明する。
図４は本発明の第１の実施例によるネットワークの構成においてトンネリング部１３のカプセル化手段としてＥｔｈｅｒＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いる時に送受信されるフレームの書式を示す図である。図５は本発明の第１の実施例によるフレーム振分部１１におけるフレームの振分処理を示すフローチャートである。これら図１〜図５を参照して本発明の第１の実施例によるトンネリング装置１の動作について説明する。尚、図５に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
以下の説明では、ローカルネットワーク２０１，２０２にはＥｔｈｅｒｎｅｔ（登録商標）ＩＩ規格を用い、ローカルネットワーク２０１，２０２間を接続するネットワークはＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ４）によって接続されるインタネット１００を想定しているが、Ｅｔｈｅｒｎｅｔ（登録商標）ＩＩ規格は任意のデータリンク層プロトコル、ＩＰｖ４は任意のネットワーク層プロトコルでも適用可能である。
まず、図４を参照してインタネットで一般的に用いられているフレームの書式について説明する。図４のＭＡＣヘッダ３０１はデータリンク層フレームのヘッダであり、Ｅｔｈｅｒｎｅｔ（登録商標）ＩＩ規格によって構成されているローカルネットワーク２０１，２０２上で実際に送受信されているすべてのフレームの先頭に共通して存在している領域である。ＭＡＣヘッダ３０１には、主に物理アドレスである「宛先ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス」と「送信元ＭＡＣアドレス」と上位層の種別を表す「タイプ」とが含まれている。
トンネリング装置１，２からローカルネットワーク２０１，２０２に送信されたフレームはすべての端末４−１〜４−Ｍ，５−１〜５−Ｎで受信されるが、効率化のためにフレームを中継する際に「宛先ＭＡＣアドレス」をチェックして不必要なフレームの中継を行わないようにする中継装置もある。ローカルネットワーク２０１，２０２に接続される装置は物理アドレスであるＭＡＣアドレスを保持し、自身の物理インタフェースからフレームを受信した際に、「宛先ＭＡＣアドレス」が自装置であるか、ブロードキャストである場合に受信処理を行う。
この仕組みによって、ローカルネットワーク２０１，２０２に接続する装置は、目的の装置のＭＡＣアドレスをＭＡＣヘッダ３０１の「宛先ＭＡＣアドレス」に指定したフレームを送信することによって、目的の装置にて受信させることが可能となっている。
ＩＰｖ４ヘッダ３０２はネットワーク層パケットのヘッダとしてＭＡＣヘッダ３０１の後ろに続いて設定される領域であり、ＭＡＣヘッダ３０１のタイプには「０ｘ０８００」が指定されることによって、ＩＰｖ４ヘッダ３０２が続いていることが識別される。このＩＰｖ４ヘッダ３０２には、主に上位層の種別を表す「プロトコル」と、論理アドレスである「送信元ＩＰアドレス」と、「宛先ＩＰアドレス」とが含まれている。
インタネット１００はローカルネットワークの集合体であり、ＭＡＣアドレスを指定して送信できる範囲はそれぞれのローカルネットワーク内に限られるため、ローカルネットワーク２０１，２０２同士でＩＰアドレスを用いて通信を行うことができるように、ローカルネットワーク２０１，２０２を接続する経路選択装置であるルータ３−１，３−２が存在している。ルータ３−１，３−２はフレームを受信するたびにＩＰｖ４ヘッダ３０２の宛先ＩＰアドレスをチェックし、最適な次のルータへと送信していく。この時、宛先や送信元となるルータ３−１，３−２のＭＡＣアドレスは毎回異なるので、ＭＡＣヘッダ３０１の内容も変化していく。このようにして、最終的に目的のＩＰアドレスを持つ装置へデータが到着して受信され、ＩＰアドレスを用いて離れたローカルネットワークの装置へとデータを送信することが可能となっている。
ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）３０３はＭＡＣヘッダ３０１に続いて指定されるデータ領域であり、ＭＡＣヘッダ３０１のタイプには「０ｘ０８０６」が指定されることによって、ＡＲＰ３０３が続いていることが識別される。ＡＲＰ３０３は物理アドレス解決要求フレームと、物理アドレス解決応答フレームとの役割をにない、主にこのフレームが要求か応答かを示す「オペレーション」と、「送信元ＭＡＣアドレス」と、「送信元ＩＰアドレス」と、「宛先ＭＡＣアドレス」と、「宛先ＩＰアドレス」とを含んでおり、既知のＩＰアドレスからそのＩＰアドレスを持つ装置のＭＡＣアドレスを知るために用いられる。
尚、ＡＲＰ３０３はＩＰｖ４ヘッダ３０２とは同時に用いられないので、ローカルネットワーク２０１，２０２内でのみ有効なフレームである。ＭＡＣアドレスを知りしたいと思う装置は、自身のＭＡＣアドレスとＩＰアドレスとを送信元ＭＡＣアドレス、送信元ＩＰアドレスとして含め、目的の装置のＩＰアドレスを送信先ＩＰアドレスとして含め、オペレーションを「要求」とするＡＲＰ３０３を作成し、ＭＡＣヘッダ３０１の宛先アドレスはブロードキャストとしてローカルネットワーク２０１，２０２に送信する。
このフレームを受信した各装置は送信先ＩＰアドレスと自身のＩＰアドレスとを比較し、同一でない場合にはそのフレームを破棄する。同一であった場合には、自身のＭＡＣアドレスとＩＰアドレスとを送信元ＭＡＣアドレス、送信元ＩＰアドレスとして含め、受信したＡＲＰ３０３の送信元ＭＡＣアドレス、送信元ＩＰアドレスをそれぞれ宛先ＭＡＣアドレス、宛先ＩＰアドレスとし、オペレーションを「応答」とするＡＲＰ３０３を作成し、ＭＡＣヘッダ３０１の宛先アドレスは受信したＡＲＰ３０３の送信元ＭＡＣアドレスとしてローカルネットワーク２０１，２０２に送信する。これによって、目的のＭＡＣアドレスが返送される形になり、ＭＡＣアドレスを知りしたいと思う装置は、目的のＭＡＣアドレスを得ることができる。
ＥｔｈｅｒＩＰヘッダ３０４は、ＩＰｖ４ヘッダ３０２に続くヘッダであり、ＩＰｖ４ヘッダ３０２のプロトコルに「０ｘ６１」が指定されることによって、ＥｔｈｅｒＩＰヘッダ３０４が続いていることが識別される。ＥｔｈｅｒＩＰヘッダ３０４の内容はバージョン番号のみで、設定すべき部分はない。
ＥｔｈｅｒＩＰヘッダ３０４の後にはＭＡＣヘッダ３０１が続く。すなわち、ＥｔｈｅｒＩＰヘッダ３０４を用いれば、ローカルネットワーク２０１，２０２で送受信されるフレームをそのままデータとして含め、それを指定されたＩＰアドレスへむけてそのまま送信することができるようになる。
これを用いて、受信したフレームをＥｔｈｅｒＩＰヘッダ３０４の後ろに含めて新たにフレームを作成することでフレームのカプセル化を行うことができ、受信したフレームのＥｔｈｅｒＩＰヘッダ３０４以降のフレームを取出すことによってデカプセル化を行うことができる。
フレーム振分部１１はローカルネットワーク２０１に接続され、ローカルネットワーク２０１で送受信されるデータリンク層のデータ系列であるイーサネット（登録商標）フレームを送受信する。フレーム振分部１１では各経路＃１〜＃４からそのイーサネット（登録商標）フレームを含むフレームを受信すると、経路＃１〜＃４のどの経路から入力されたかを判定する（図５ステップＳ１）。
フレーム振分部１１は経路＃２〜＃４の各経路から入力されると、そのフレームを経路＃１へと出力する（図５ステップＳ２）。つまり、フレーム振分部１１はカーネル部１２で処理されて経路＃２から入力されるフレーム、トンネリング部１３でデカプセル化されて経路＃３から入力されるフレーム、トンネリング部１３でカプセル化されて経路＃４から入力されるフレームをそれぞれそのまま経路＃１を介してローカルネットワーク２０１へと出力する。
これに対し、フレーム振分部１１は経路＃１からフレームが入力されると、そのフレームの宛先物理アドレスが同報アドレスであれば（図５ステップＳ３）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃２，＃３へと出力する（図５ステップＳ４）。
フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスで（図５ステップＳ５）、宛先論理アドレスが自装置の論理アドレスで（図５ステップＳ６）、送信元論理アドレスが特定装置の論理アドレスで（図５ステップＳ７）、そのフレームで用いてられているカプセル化方式が自装置で用いているカプセル化方式であれば（図５ステップＳ８）、そのフレームはトンネリング先のトンネリング装置２からのものであるので、そのフレームを経路＃４へと出力する（図５ステップＳ９）。
フレーム振分部１１は宛先物理アドレスが自装置の物理アドレスであっても（図５ステップＳ５）、宛先論理アドレス、送信元論理アドレス、フレームで用いてられているカプセル化方式がそれぞれ上記の条件を満たしていなければ、そのフレームを経路＃２へと出力する（図５ステップＳ１０）。
一方、フレーム振分部１１は宛先物理アドレスが自装置の物理アドレスでなければ（図５ステップＳ５）、経路＃３へと出力し（図５ステップＳ１１）、そのフレームに対してトンネリング部１３にてカプセル化を行う。このカプセル化されたフレームは経路＃４を介してフレーム振分部１１に入力されるので、フレーム振分部１１から経路＃１を通してローカルネットワーク２０１へと出力される。
このような特徴を持つことによって、従来のトンネリング装置２はローカルネットワーク２０２とルータ３−２との間で、一度ネットワークを切断し、その間に挟みこむように接続する必要があるが、本実施例によるトンネリング装置１は、従来のネットワーク構成に変更を加えることなく、単純にローカルネットワーク２０１に接続するだけで動作させることが可能となる。
上述したように、トンネリング装置１はフレーム振分部１１と、１つ以上のトンネリング部１３と、カーネル部１２とを備えている。フレーム振分部１１の物理インタフェースは１つのみであり（図２では経路＃１として図示）、ローカルネットワーク２０１からローカルネットワーク２０２へカプセル化して送信すべきフレーム、トンネリング装置１から送られるカプセル化されたフレーム、トンネリング装置１宛に送られてくるフレームをすべて１つの物理インタフェースにおいて受信し、デカプセル化したフレーム、カプセル化したフレーム、並びにトンネリング装置１自身から送信されるフレームも、同一の物理インタフェースから送信する。
つまり、フレーム振分部１１は物理インタフェースを通してローカルネットワーク２０１からイーサネット（登録商標）フレームを受信し、経路＃２〜＃４から入力したイーサネット（登録商標）フレームをローカルネットワーク２０１へと送信する。
一般的な物理インタフェースは自身の物理アドレスとしてＭＡＣアドレスを保持しており、宛先ＭＡＣアドレスが自機器のＭＡＣアドレスであるか、ブロードキャストアドレスである場合にのみ受信を行うが、トンネリング装置１の物理インタフェースはすべてのイーサネット（登録商標）フレームをそのまま受信し、フレーム振分部１１へと出力する。
フレーム振分部１１は物理インタフェースから入力したイーサネット（登録商標）フレームが、カプセル化されているトンネルフレームであるか否かを判定し、トンネルフレームであるイーサネット（登録商標）フレームを経路＃４を介してトンネリング部１３へ出力し、トンネルフレームではないフレームを経路＃３を介してトンネリング部１３へと出力するとともに、経路＃２を介してカーネル部１２へと出力する。
フレーム振分部１１でトンネルフレームであるか否かを判定する方法としては、そのフレームのトンネリングがどのような技術で実施されているかによって異なるが、ほとんどの場合には、データリンク層ヘッダの宛先アドレスが自装置の物理アドレスであり、ネットワーク層ヘッダの送信元アドレスがトンネリングを行っている相手のトンネリング装置２の論理アドレスであり、かつフレームの種別、すなわちネットワーク層ヘッダ以降の特徴が、トンネリング技術特有のものであるフレームをトンネルフレームであると判断する。
具体的には、例えばＥｔｈｅｒＩＰによってＩＰｖ４パケットにカプセル化を行うトンネリング装置１の場合、フレーム振分部１１は受信したフレームの宛先ＭＡＣアドレスがトンネリング装置１自身のＭＡＣアドレスであり、送信元ＩＰアドレスがトンネリング装置２のＩＰアドレスであり、ＩＰｖ４ヘッダのプロトコル番号が「０ｘ６１」であるフレームをトンネルフレームと判定する。
さらに、イーサネット（登録商標）をＨＴＴＰＳ［ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） ｏｖｅｒ ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）］等の、本来の用途とは異なるプロトコルにカプセル化する場合には、さらに特段の配慮が必要である。ＨＴＴＰＳはＷｅｂサーバとブラウザ等のクライアントとの間でデータを送受信するために使われるプロトコルであるＨＴＴＰプロトコルに暗号化の処理が加わったプロトコルである。
しかしながら、これを用いてイーサネット（登録商標）フレームのカプセル化を行っている場合には、トンネリング装置１とトンネリング装置２との間でＨＴＴＰＳを用いた本来の通信したいと思っても、そのＨＴＴＰＳによる通信に関するフレームもトンネルフレームであると判定されてしまう。
この場合、フレーム振分部１１は一度すべてのＨＴＴＰＳのフレームをトンネリング部１３へ出力し、トンネリング部１３にてデカプセル化を行う際に、デカプセル化ができなかったフレームについて、フレーム振分部１１へと差し戻して経路＃２に出力するか、フレーム振分部１１において、トンネリング部１３で行っているデカプセル化の試行をして判断するか、フレームのカプセル化が行われているＨＴＴＰＳが他のＨＴＴＰＳとは異なる特徴を抽出する等して判定を行う。
また、トンネリング技術としては、タグＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を用いてもよく、その場合には、タグＶＬＡＮ付きのイーサネット（登録商標）フレームをトンネルフレームと判断してよい。
フレーム振分部１１は上述した記憶装置１６の経路（＃１〜＃３）アドレステーブル１６１〜１６３に、各経路＃１〜＃３から入力されるフレームの送信元ＭＡＣアドレスを記憶する。フレーム振分部１１はフレームを出力する前に、これら経路（＃１〜＃３）アドレステーブル１６１〜１６３において宛先ＭＡＣアドレスの検索を行う。
フレーム振分部１１は宛先ＭＡＣアドレスが発見できた場合、発見できた経路（＃１〜＃３）アドレステーブル１６１〜６３に対応する経路＃１〜＃３のいずれかへ向けて出力し、宛先ＭＡＣアドレスを発見できなかった場合（ブロードキャストアドレスを含む）、経路＃１〜＃４すべてへ出力する。但し、そのフレームが入力された経路へは出力しない。
トンネリング部１３が複数存在する場合には、それぞれ別々に扱われ、例えば、第１のトンネリング部から入力したフレームが、第２のトンネリング部へと出力されてもよい。
経路＃２アドレステーブル１６２には予め固定的にトンネリング装置１のＭＡＣアドレスを関連付けて記憶する。こうすることによって、トンネリング装置１宛に送られてきたフレームで、トンネリングフレームでないフレームはカーネル部１２へと出力されることになる。
遠隔地であるローカルネットワーク２０２から発せられたフレームも、上記と同様である。例えば、ローカルネットワーク２０２の端末５−１〜５−Ｎからトンネリング装置１のＭＡＣアドレスを宛先として指定して送信されたフレームは、トンネリング装置２でカプセル化され、トンネリング装置１で受信され、トンネリング部１３でデカプセル化された後、カーネル部１２へと出力されることで処理される。
さらに、カーネル部１２でそのフレームの返信として、宛先ＭＡＣアドレスを先のフレームの送信元ＭＡＣアドレスとするフレームを出力すると、そのＭＡＣアドレスは経路＃３アドレステーブル１６３に記憶されているので、トンネリング部１３（経路＃３）へと出力されてカプセル化され、最終的にローカルネットワーク２０２の目的の端末において受信されることになる。
経路＃３アドレステーブル１６３においては、トンネリング部１３が２つ以上存在する場合、それぞれを区別して異なる出力先として記憶する。同一のＭＡＣアドレスが他の経路アドレステーブルにすでに記憶されている場合には、他の経路アドレステーブルに記憶されたアドレスが削除される。一定期間登録がないものについては削除する。
フレーム振分部１１は上記の経路（＃１〜＃３）アドレステーブル１６１〜１６３との組み合わせで、一般的なスイッチングハブと同様の動作を行うが、カーネル部１２へは宛先ＭＡＣアドレスがトンネリング装置１のＭＡＣアドレスではなく、かつブロードキャストアドレスではないフレームを出力しないことが異なる。これによって、不必要なフレームがカーネル部１２へと出力されることを防ぐ。
トンネリング部１３はカプセル化手段とデカプセル化手段とを備え、フレーム振分部１１から経路＃３を通して入力したフレームをカプセル化手段へと出力し、フレーム振分部１１から経路＃４を通して入力したフレームをデカプセル化手段へと出力する。
カプセル化手段は入力したフレームを、接続先のトンネリング装置２のＩＰアドレスを宛先ＩＰアドレスとするフレームにカプセル化し、経路＃４へと出力する。デカプセル化手段は入力したフレームをデカプセル化し、経路＃３へと出力する。
トンネリング部１３は１つだけではなく、複数存在していても良く、かつ、それぞれのトンネリング技術が異なっていても良い。また、接続先もそれぞれのトンネリング部で異なっていても良い。こうすることによって、複数のトンネリング装置を中継するトンネリング装置や、異なるトンネリング技術を中継するトンネリング装置等を構成することも可能である。
フレーム振分部１１において説明したように、デカプセル化手段はデカプセル化できないフレームを入力した場合、そのフレームをフレーム振分部１１へ差し戻しても良い。
カーネル部１２はトンネリング装置１で処理すべきフレームをフレーム振分部１１から入力して適宜処理をしたり、その処理の結果をフレーム振分部１１へ出力して送信したりする。また、カーネル部１２はトンネリング装置１からエラーやトラフィックの報告等、何らかの通知を出力して送信してもよい。
カーネル部１２で処理する内容としては、ローカルネットワーク２０１，２０２から受信した物理アドレス解決要求フレームへの応答としての物理アドレス解決応答フレームの送信があり、またデフォルトゲートウェイの物理アドレス取得のための物理アドレス解決要求フレームの送信と、その応答としての物理アドレス解決応答フレームの受信とデフォルトゲートウェイのＭＡＣアドレスの記憶装置１６への記憶とがある。
さらに、本実施例では、トンネリング装置１のＩＰアドレス等の各種設定を遠隔で行うためや、エラーやトラフィックの報告等の通知のために、ＨＴＴＰ、ＨＴＴＰＳ、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）等任意のプロトコルを用いて送受信してもよい。また、生存確認のため等に使われるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）の送受信を行っても良い。
記憶装置１６はさらに、自装置の物理アドレスと、自装置の論理アドレスと、１つ以上のトンネリング先の論理アドレスと、デフォルトゲートウェイの論理アドレスと、デフォルトゲートウェイの物理アドレスとを記憶する。トンネリング先の論理アドレスは、タグＶＬＡＮの場合、タグの番号になってもよい。
次に、トンネリング装置１の物理インタフェース部１１で受信されるイーサネット（登録商標）フレームの種類について整理し、それぞれのフレームの送受信のシーケンスについて説明する。
トンネリング装置１にて受信されるフレームの種類は主に以下の４つに分けられる。１つ目は、トンネリング装置１のカーネル部１２に対して送るべきフレームである。カーネル部１２はトンネリング装置１で処理すべきトンネル以外のすべてのフレームであり、これにはＡＲＰ３０３や、トンネリング装置１のＩＰアドレスや接続先のトンネリング装置２のＩＰアドレス、デフォルトゲートウェイのＩＰアドレス等をＷｅｂで設定する場合のＨＴＴＰ等も含まれる。
２つ目は、トンネリング装置２から送られたトンネルフレームである。３つ目はトンネリング装置２へカプセル化して送るべきフレームである。４つ目は破棄すべきフレームである。
以下の説明では、記憶装置１６において、自装置のＭＡＣアドレスとして「ＭＡＣ１２１」、自身のＩＰアドレスとして「ＩＰ２２１」、トンネリング先のＩＰアドレスとして「ＩＰ２２２」、デフォルトゲートウェイのＩＰアドレスとしてルータ３−１の「ＩＰ２１１」が設定されているものとする。
図６は本発明の第１の実施例によるネットワークの構成において送受信されるフレームの形式を示す図であり、図７は本発明の第１の実施例によるネットワークの構成においてトンネリング部１３のカプセル化手段としてＥｔｈｅｒＩＰを用いる時のフレーム内容の変化とフレームの送受信とを示すシーケンスチャートである。これら図１〜図７とを参照してカーネル部１２へ送るべきフレームについて説明する。
カーネル部１２へ送るべきフレームの中で最も重要なフレームは、物理アドレス解決要求フレームである。具体的には、ＡＲＰ３０３のオペレーションが「要求」となっているＡＲＰ要求フレーム３１０（図６参照）である。物理アドレス解決要求フレームはローカルネットワーク２０１またはローカルネットワーク２０２に接続する装置で、トンネリング装置１のＩＰアドレスを指定して送信したいと思う場合に必要となる。
以下では、カーネル部１２へ送るべきフレームの例として、ローカルネットワーク２０１に接続する端末４−Ｍからトンネリング装置１へＩＰパケットを送信する場合を想定し、物理アドレス解決要求フレームであるＡＲＰ要求フレーム３１０を送り、トンネリング装置１から物理アドレス解決応答フレームであるＡＲＰ応答フレーム３１１（図６参照）が返信され、トンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」が判明し、そのＭＡＣアドレスを用いてＩＰパケットを送信するまでの動作について説明する。
端末４−Ｍはトンネリング装置１のＩＰアドレスである「ＩＰ２２１」に向けてＩＰパケットを送信しようとしているが、トンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」が不明なので、フレームを作成することができない。そこで、端末３−ＭはＡＲＰ要求フレーム３１０を作成し、「ＭＡＣ１２１」の取得を試みる。
ＡＲＰ要求フレーム３１０は宛先ＭＡＣアドレスをブロードキャストアドレスとし、送信元ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、タイプを「０ｘ０８０６」とするＭＡＣヘッダ３０１と、それに続くオペレーションを「要求」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３１」とし、送信元ＩＰアドレスを「ＩＰ２３１」とし、宛先ＭＡＣアドレスには何も設定せず、宛先ＩＰアドレスを「ＩＰ２２１」とするＡＲＰ３０３によって構成される。
このＡＲＰ要求フレーム３１０は端末４−Ｍからローカルネットワーク２０１へとブロードキャスト送信される。トンネリング装置１以外の装置は、宛先ＩＰアドレスが自装置のＩＰアドレスではないので、このフレームを無視する。
トンネリング装置１のフレーム振分部１１は物理インタフェースを通してＡＲＰ要求フレーム３１０を受信すると、ＡＲＰ要求フレーム３１０の宛先ＭＡＣアドレスがブロードキャストアドレス（同報アドレス）であるので（図５ステップＳ１，Ｓ３）、経路＃２を通してカーネル部１２へ出力するとともに、経路＃３を通してトンネリング部１３へ出力する（図５ステップＳ４）。
トンネリング部１３へ出力されたＡＲＰ要求フレーム３１０については、ＥｔｈｅｒＩＰによってカプセル化され、経路４を通してフレーム振分部１１に送られ、フレーム振分部１１から経路＃１を通してローカルネットワーク２０１へと送信される（図５ステップＳ２）。このフレームはローカルネットワーク２０１からルータ３−１、インタネット１００、ルータ３−２を通してトンネリング装置２へ到達し、デカプセル化されてローカルネットワーク２０２に送信される。ローカルネットワーク２０２では「ＩＰ２３１」を持つ装置がないため、応答は起こらない。
カーネル部１２へ出力されたＡＲＰ要求フレーム３１０については、ＡＲＰフレームであるかどうかがチェックされた後、ＡＲＰ要求であるかどうかがチェックされる。さらに、ＡＲＰ要求フレーム３１０はＡＲＰ３０３の宛先ＩＰアドレスが記憶装置１６に記憶されている自装置のＩＰアドレスである「ＩＰ２２１」に一致するため、カーネル部１２は物理アドレス解決応答フレームであるＡＲＰ応答フレーム３１１の作成を行う。
ＡＲＰ応答フレーム３１１は宛先ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、送信元ＭＡＣアドレスをトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」とし、タイプを「０ｘ０８０６」とするＭＡＣヘッダ３０１と、それに続くオペレーションを「応答」とし、送信元ＭＡＣアドレスを「ＭＡＣ１２１」とし、送信元ＩＰアドレスを「ＩＰ２２１」とし、宛先ＭＡＣアドレスを「ＭＡＣ１３１」とし、宛先ＩＰアドレスを「ＩＰ２３１」とするＡＲＰ３０３によって構成される。
このＡＲＰ応答フレーム３１１はカーネル部１２から経路＃２を通してフレーム振分部１１へと出力される。フレーム振分部１１は経路＃２を通して入力されたカーネル部１２からのＡＲＰ応答フレーム３１１を、物理インタフェース（経路＃１）を通してローカルネットワーク２０１へと送信する（図５ステップＳ２）。端末４−Ｍはローカルネットワーク２０１からＡＲＰ応答フレーム３１１を受信し、目的のトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」を取得する。
最後に、端末４−Ｍは宛先ＭＡＣアドレスをトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」とし、送信元ＭＡＣアドレスを端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」とし、タイプを「０ｘ０８００」とするＭＡＣヘッダ３０１と、それに続いて、送信しようとしていたＩＰパケットである送信元ＩＰアドレスを「ＩＰ２２１」、宛先ＩＰアドレスを「ＩＰ２３１」とするＩＰｖ４ヘッダ３０２と、それに続いて、上位層データを付加したフレーム３２２をローカルネットワーク２０１へと送信する。
フレーム３２２はトンネリング装置１の物理インタフェースを通してフレーム振分部１１で受信され、フレーム振分部１１はフレーム３２２の宛先ＭＡＣアドレスが自装置のＭＡＣアドレスであり（図５ステップＳ５）、ＩＰｖ４フレームであるが、送信元ＩＰアドレスが特定装置の論理アドレス（接続先のトンネリング装置２のＩＰアドレス）ではないので（図５ステップＳ７）、経路＃２を通してカーネル部１２へ出力する（図５ステップＳ１０）。カーネル部１２ではフレーム３２２がＡＲＰフレームではないので、その他のアプリケーション用のフレームとして扱う。
このようにして、端末４−Ｍから送信しようとしていたＩＰパケットは、正しくカーネル部１２へと到達する。以降、端末４−Ｍはトンネリング装置１のＭＡＣアドレスを記憶しているので、続けてＩＰパケットを送信し続けることができる。
次に、デカプセル化すべきフレームとカプセル化すべきフレームとについて説明する。図８は本発明の第１の実施例による送受信されるフレームの形式を示す図であり、図９は図１に示すネットワークの中で送受信されるフレームに対する処理を示すシーケンスチャートである。
デカプセル化すべきフレームとはトンネリング装置２から送られ、トンネリング装置１にてデカプセル化すべきフレームのことである。カプセル化すべきフレームとはローカルネットワーク２０１で送信され、ローカルネットワーク２０２で受信されるべきフレームのことである。
以下、ローカルネットワーク２０２に接続する端末５−Ｎがローカルネットワーク２０１に接続する端末４−Ｍにフレームを送信し、その応答が端末４−Ｍから端末５−Ｎへと送信され、端末５−Ｎで受信されるまでの動作について説明する。
端末５−Ｎは端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」をすでに知っているものとする。端末５−Ｎは宛先ＭＡＣアドレスを「ＭＡＣ１３１」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３２」とするＭＡＣヘッダ３０１を含むフレーム３２３をローカルネットワーク２０２へ送信する。
トンネリング装置２はフレーム３２３を受信すると、ＥｔｈｅｒＩＰによってカプセル化を行い、宛先ＩＰアドレスをトンネリング装置１のＩＰアドレスである「ＩＰ２２１」とし、送信元ＩＰアドレスをトンネリング装置２のＩＰアドレスである「ＩＰ２２２」とするＩＰｖ４ヘッダ３０２を付加したパケット３２４を作成し、ルータ３−２を通してインタネット１００へ送信する。パケット３２４はイーサネット（登録商標）を含む様々なデータリンク層ヘッダを付け替えながら転送され、最終的にルータ３−１にまで到達する。
ルータ３−１はパケット３２４の宛先ＩＰアドレスが「ＩＰ２２１」になっているので、対応するＭＡＣアドレスである「ＭＡＣ１２１」を宛先ＭＡＣアドレスとし、自装置のＭＡＣアドレスである「ＭＡＣ１１１」を送信元ＭＡＣアドレスとするＭＡＣヘッダ３０１を付加したフレーム３２５を作成し、ローカルネットワーク２０１へ送信する。もし、「ＭＡＣ１２１」が既知ではなかった場合、ルータ３−１はＡＲＰ要求フレームを送信し、目的の「ＭＡＣ１２１」の取得を試み、「ＭＡＣ１２１」を取得してからフレーム３２５を作成する。
ローカルネットワーク２０１へ送信されたフレーム３２５は、トンネリング装置１の物理インタフェース（経路＃１）を通してフレーム振分部１１にて受信される。宛先ＭＡＣアドレスはルータ３−１によってトンネリング装置１のＭＡＣアドレスである「ＭＡＣ１２１」に設定されており（図５ステップＳ５）、ＩＰｖ４フレームであり、送信元ＩＰアドレスがトンネリング装置２で設定されたＩＰアドレスである「ＩＰ２２２」になっており（図５ステップＳ７）、ＩＰｖ４ヘッダ３０２のプロトコルが「０ｘ６１」に指定されている（図５ステップＳ８）。
よって、フレーム振分部１１はフレーム３２５をトンネルフレームであると判定し、経路＃４を通してトンネリング部１３へ出力する（図５ステップＳ９）。トンネリング部１３はフレーム３２５に含まれるカプセル化されたフレーム３２３を取出し、フレーム３２３を経路＃３を通してフレーム振分部１１へ出力する。
フレーム振分部１１は経路＃３から入力されたフレーム３２３を、物理インタフェース（経路＃１）を通してローカルネットワーク２０１へ送信する（図５ステップＳ１，Ｓ２）。端末４−Ｍはローカルネットワーク２０１からフレーム３２３を受信する。こうして、端末５−Ｎから送信されたフレーム３２３は、正しく端末４−Ｍで受信される。
端末４−Ｍは宛先ＭＡＣアドレスを端末５−ＮのＭＡＣアドレスである「ＭＡＣ１３２」とし、送信元ＭＡＣアドレスを「ＭＡＣ１３１」とするＭＡＣヘッダ３０１を含むフレーム３２６をローカルネットワーク２０１へ送信する。トンネリング装置１のフレーム振分部１１は物理インタフェース（経路＃１）を通してフレーム３２６をローカルネットワーク２０１から受信し、フレーム３２６の宛先ＭＡＣアドレスが自装置のＭＡＣアドレスではないので（図５ステップＳ５）、そのフレーム３２６を経路＃３を通してトンネリング部１３へ出力する（図５ステップＳ１１）。
トンネリング部１３はフレーム３２６をＥｔｈｅｒＩＰにてカプセル化し、パケット３２７を作成する。パケット３２７は経路＃４を通してフレーム振分部１１に送られ、フレーム振分部１１から物理インタフェース（経路＃１）を通してローカルネットワーク２０１へと送信される（図５ステップＳ２）。その後、パケット３２７はルータ３−１、インタネット１００、ルータ３−２を介してトンネリング装置２へ到達する。トンネリング装置２は受信したパケット３２７をデカプセル化し、元のフレーム３２６をローカルネットワーク２０２へ送信し、端末５−Ｎはこれを受信する。こうして、端末４−Ｍから送信されたフレーム３２６は端末５−Ｎで正しく受信される。
このように、本実施例では、同一の物理インタフェースから受信したフレームを、自装置で処理すべきフレーム、カプセル化して送信すべきフレーム、デカプセル化して送信すべきフレーム等に正しく振り分けて処理を行うことができるので、ネットワークを一時停止させず、すでに構成されているローカルネットワーク２０１，２０２に変更を加えることなく、ローカルネットワーク２０１に対してトンネリング装置１の１つの物理インタフェースのみを接続することで、トンネリングを行うことができる。
図１０は本発明の第１の実施例によるネットワークの変形例を示すブロック図である。図１０に示すネットワーク例では、インタネット１００とルータ３−１との間にファイアウォール６を設けた以外は図１に示す本発明の実施の形態によるネットワークと同様の構成となっている。この場合、トンネリング装置２からトンネリング装置１へ送信されるフレームの宛先論理アドレスはファイアウォール６のＩＰアドレス「ＩＰ２４１」となり、ファイアウォール６にて宛先論理アドレスが「ＩＰ２２１」へ付け替えられてトンネリング装置１へと送信される。さらに、送信元論理アドレスが「ＩＰ２４２」へ付け替えられることもあり、この場合にはトンネリング装置１が特定装置の論理アドレスを「ＩＰ２４２」として記憶する。また、ファイアウォールはアドレス変換装置であってもよい。この点以外の動作は上述した本発明の第１の実施例の動作と同様であるので、その説明は省略する。
次に、本発明の第２の実施例について説明する。本発明の第２の実施例によるネットワークは上述した本発明の第１の実施例によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は上述した本発明の第１の実施例によるトンネリング装置と同様の機能、構成となっているので、それらの説明については省略する。
図１１〜図１４は本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図１１〜図１４とを参照して本発明の第２の実施例によるトンネリング装置１の動作について説明する。尚、図１１〜図１４に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第２の実施例においては、フレーム振分部１１がトンネリング先からカーネル部１２への通信も許容するように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第１の実施例と同様に動作するので、図１１のステップＳ２２〜Ｓ３０の動作は図５のステップＳ３〜Ｓ１１の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はトンネリング先からカーネル部１２への通信も許容するように動作するために、経路＃２から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃３を通してトンネリング部１３に出力する（図１１ステップＳ２１，図１２ステップＳ３１）。同様に、フレーム振分部１１は経路＃３から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃２を通してカーネル部１２に出力する（図１１ステップＳ２１，図１３ステップＳ３２）。
尚、経路＃４から入力されるフレームは、上述した本発明の第１の実施例と同様に、経路＃１を通してローカルネットワーク２０１に出力される（図１１ステップＳ２１，図１３ステップＳ３３）。このように、本実施例では、上述した本発明の第１の実施例の効果のほかに、トンネリング先からカーネル部１２への通信も許容するように動作させることができる。
さらに、本実施例では、トンネリング装置１がカーネル部１２にＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバを持ち、ＩＰアドレスの配布等を行ってもよい。こうすることによって、ＩＰアドレスを持つトンネリング装置１はローカルネットワーク２０１，２０２に存在する端末４−１〜４−Ｍ，５−１〜５−Ｎとの間で、そのＩＰアドレスを用いて通信を行うことが可能となり、各種設定や各種情報の照会等を遠隔で行えるようにしたり、ＩＰアドレスの配布を行ったりすることができるようになる。
図１１〜図１４は本発明の第２の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図１１〜図１４とを参照して本発明の第２の実施例によるトンネリング装置１の動作について説明する。尚、図１１〜図１４に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第２の実施例においては、フレーム振分部１１がトンネリング先からカーネル部１２への通信も許容するように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第１の実施例と同様に動作するので、図１１のステップＳ２２〜Ｓ３０の動作は図５のステップＳ３〜Ｓ１１の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はトンネリング先からカーネル部１２への通信も許容するように動作するために、経路＃２から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃３を通してトンネリング部１３に出力する（図１１ステップＳ２１，図１２ステップＳ３１）。同様に、フレーム振分部１１は経路＃３から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃２を通してカーネル部１２に出力する（図１１ステップＳ２１，図１３ステップＳ３２）。
尚、経路＃４から入力されるフレームは、上述した本発明の第１の実施例と同様に、経路＃１を通してローカルネットワーク２０１に出力される（図１１ステップＳ２１，図１３ステップＳ３３）。このように、本実施例では、上述した本発明の第１の実施例の効果のほかに、トンネリング先からカーネル部１２への通信も許容するように動作させることができる。
さらに、本実施例では、トンネリング装置１がカーネル部１２にＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバを持ち、ＩＰアドレスの配布等を行ってもよい。こうすることによって、ＩＰアドレスを持つトンネリング装置１はローカルネットワーク２０１，２０２に存在する端末４−１〜４−Ｍ，５−１〜５−Ｎとの間で、そのＩＰアドレスを用いて通信を行うことが可能となり、各種設定や各種情報の照会等を遠隔で行えるようにしたり、ＩＰアドレスの配布を行ったりすることができるようになる。
次に、本発明の第３の実施例について説明する。本発明の第３の実施例によるネットワークは上述した本発明の第２の実施例によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は上述した本発明の第２の実施例によるトンネリング装置と同様の機能、構成となっているので、それらの説明については省略する。
図１５〜図１８は本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図１５〜図１８とを参照して本発明の第３の実施例によるトンネリング装置１の動作について説明する。尚、図１５〜図１８に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第３の実施例においては、フレーム振分部１１が上述した本発明の第２の実施例によるトンネリング装置１の動作において不必要な処理が行われないように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第２の実施例と同様に動作するので、図１５のステップＳ４２〜Ｓ５０の動作は図１１のステップＳ２２〜Ｓ３０の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１は経路＃２から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃３を通してトンネリング部１３に出力する（図１５ステップＳ４１，図１６ステップＳ５１）。同様に、フレーム振分部１１は経路＃４から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力する（図１５ステップＳ４１，図１８ステップＳ５７）。
一方、フレーム振分部１１はフレームが経路＃３から入力されると（図１５ステップＳ４１）、そのフレームの宛先物理アドレスが同報アドレスであれば（図１７ステップＳ５２）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、そのフレームを経路＃２を通してカーネル部１２に出力する（図１７ステップＳ５３）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図１７ステップＳ５４）、そのフレームを経路＃２を通してカーネル部１２に出力する（図１７ステップＳ５５）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでも、自装置の物理アドレスでもなければ（図１７ステップＳ５４）、そのフレームを経路＃１を通してローカルネットワーク２０１に出力する（図１７ステップＳ５６）。
このように、本実施例では、上述した本発明の第２の実施例の効果のほかに、トンネリング装置１の動作において不必要なフレームの転送が行われないように動作させることができる。
図１５〜図１８は本発明の第３の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図１５〜図１８とを参照して本発明の第３の実施例によるトンネリング装置１の動作について説明する。尚、図１５〜図１８に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第３の実施例においては、フレーム振分部１１が上述した本発明の第２の実施例によるトンネリング装置１の動作において不必要な処理が行われないように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第２の実施例と同様に動作するので、図１５のステップＳ４２〜Ｓ５０の動作は図１１のステップＳ２２〜Ｓ３０の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１は経路＃２から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、経路＃３を通してトンネリング部１３に出力する（図１５ステップＳ４１，図１６ステップＳ５１）。同様に、フレーム振分部１１は経路＃４から入力されるフレームを経路＃１を通してローカルネットワーク２０１に出力する（図１５ステップＳ４１，図１８ステップＳ５７）。
一方、フレーム振分部１１はフレームが経路＃３から入力されると（図１５ステップＳ４１）、そのフレームの宛先物理アドレスが同報アドレスであれば（図１７ステップＳ５２）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、そのフレームを経路＃２を通してカーネル部１２に出力する（図１７ステップＳ５３）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図１７ステップＳ５４）、そのフレームを経路＃２を通してカーネル部１２に出力する（図１７ステップＳ５５）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでも、自装置の物理アドレスでもなければ（図１７ステップＳ５４）、そのフレームを経路＃１を通してローカルネットワーク２０１に出力する（図１７ステップＳ５６）。
このように、本実施例では、上述した本発明の第２の実施例の効果のほかに、トンネリング装置１の動作において不必要なフレームの転送が行われないように動作させることができる。
次に、本発明の第４の実施例について説明する。本発明の第４の実施例によるネットワークは上述した本発明の第３の実施例によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は上述した本発明の第３の実施例によるトンネリング装置と同様の構成となっているので、それらの説明については省略する。
図１９は本発明の第４の実施例によるトンネリング装置１の機能構成を示すブロック図である。図１９において、トンネリング装置１はフレーム振分部１１と、カーネル部１２と、トンネリング部１３とから構成され、フレーム振分部１１はフレーム振分手段１１１と、スイッチ手段１１２とを備えている。
フレーム振分手段１１１は経路＃１から入力されるフレームをスイッチ手段１１２と経路＃４とにそれぞれ振分け、経路＃４から入力されるフレームをスイッチ手段１１２と経路＃１とにそれぞれ振分け、スイッチ手段１１２から入力されるフレームを経路＃１，＃４にそれぞれ振分ける。スイッチ手段１１２はフレーム振分手段１１１から入力されるフレームを経路＃２，＃３に切替えて出力し、経路＃２から入力されるフレームをフレーム振分手段１１１と経路＃３とにそれぞれ切替えて出力し、経路＃３から入力されるフレームをフレーム振分手段１１１と経路＃２とにそれぞれ切替えて出力する。
図２０〜図２３は本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１と図３と図１９〜図２３とを参照して本発明の第４の実施例によるトンネリング装置１の動作について説明する。尚、図２０〜図２３に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第４の実施例においては、フレーム振分部１１が上述した本発明の第３の実施例においてさらに不必要なフレーム転送処理が行われないように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第２の実施例と同様に動作するので、図２０のステップＳ６２〜Ｓ７０の動作は図１５のステップＳ４２〜Ｓ５０の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はスイッチ手段１１２にフレームが経路＃２から入力されると（図２０ステップＳ６１）、そのフレームの宛先物理アドレスが経路＃１アドレステーブル１６１に格納されたアドレスのいずれかに一致すれば（図２１ステップＳ７１）、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力する（図２１ステップＳ７２）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２１ステップＳ７３）、そのフレームをスイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２１ステップＳ７４）。
フレーム振分部１１は経路＃３アドレステーブル１６３に格納されたアドレスのいずれかに一致すれば（図２１ステップＳ７５）、そのフレームをスイッチ手段１１２から経路＃３を通してトンネリング部１３に出力する（図２１ステップＳ７６）。
フレーム振分部１１はそのフレームの宛先物理アドレスが経路（＃１〜＃３）アドレステーブル１６１〜１６３に格納されたアドレスのいずれにも一致しなければ、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力するとともに、スイッチ手段１１２から経路＃３を通してトンネリング部１３に出力する（図２１ステップＳ７７）。
フレーム振分部１１は経路＃３から入力されると（図２０ステップＳ６１）、入力されるフレームの宛先物理アドレスが同報アドレスであれば（図２２ステップＳ７８）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力するとともに、スイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２２ステップＳ７９）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２２ステップＳ８０）、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力する（図２２ステップＳ８１）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスでもなければ（図２２ステップＳ８０）、そのフレームをスイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２２ステップＳ８２）。
フレーム振分部１１は経路＃４から入力されると（図２０ステップＳ６１）、入力されるフレームをフレーム振分手段１１１から経路＃１を通してローカルネットワーク２０１に出力する（図２３ステップＳ８３）。
このように、本実施例では、上述した本発明の第３の実施例の効果のほかに、トンネリング装置１の動作においてさらに不必要なフレーム転送処理が行われないように動作させることができる。
図１９は本発明の第４の実施例によるトンネリング装置１の機能構成を示すブロック図である。図１９において、トンネリング装置１はフレーム振分部１１と、カーネル部１２と、トンネリング部１３とから構成され、フレーム振分部１１はフレーム振分手段１１１と、スイッチ手段１１２とを備えている。
フレーム振分手段１１１は経路＃１から入力されるフレームをスイッチ手段１１２と経路＃４とにそれぞれ振分け、経路＃４から入力されるフレームをスイッチ手段１１２と経路＃１とにそれぞれ振分け、スイッチ手段１１２から入力されるフレームを経路＃１，＃４にそれぞれ振分ける。スイッチ手段１１２はフレーム振分手段１１１から入力されるフレームを経路＃２，＃３に切替えて出力し、経路＃２から入力されるフレームをフレーム振分手段１１１と経路＃３とにそれぞれ切替えて出力し、経路＃３から入力されるフレームをフレーム振分手段１１１と経路＃２とにそれぞれ切替えて出力する。
図２０〜図２３は本発明の第４の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１と図３と図１９〜図２３とを参照して本発明の第４の実施例によるトンネリング装置１の動作について説明する。尚、図２０〜図２３に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第４の実施例においては、フレーム振分部１１が上述した本発明の第３の実施例においてさらに不必要なフレーム転送処理が行われないように動作している。但し、フレーム振分部１１は経路＃１から入力されるフレームに対しては上述した本発明の第２の実施例と同様に動作するので、図２０のステップＳ６２〜Ｓ７０の動作は図１５のステップＳ４２〜Ｓ５０の動作と同様である。よって、経路＃１から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はスイッチ手段１１２にフレームが経路＃２から入力されると（図２０ステップＳ６１）、そのフレームの宛先物理アドレスが経路＃１アドレステーブル１６１に格納されたアドレスのいずれかに一致すれば（図２１ステップＳ７１）、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力する（図２１ステップＳ７２）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２１ステップＳ７３）、そのフレームをスイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２１ステップＳ７４）。
フレーム振分部１１は経路＃３アドレステーブル１６３に格納されたアドレスのいずれかに一致すれば（図２１ステップＳ７５）、そのフレームをスイッチ手段１１２から経路＃３を通してトンネリング部１３に出力する（図２１ステップＳ７６）。
フレーム振分部１１はそのフレームの宛先物理アドレスが経路（＃１〜＃３）アドレステーブル１６１〜１６３に格納されたアドレスのいずれにも一致しなければ、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力するとともに、スイッチ手段１１２から経路＃３を通してトンネリング部１３に出力する（図２１ステップＳ７７）。
フレーム振分部１１は経路＃３から入力されると（図２０ステップＳ６１）、入力されるフレームの宛先物理アドレスが同報アドレスであれば（図２２ステップＳ７８）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力するとともに、スイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２２ステップＳ７９）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２２ステップＳ８０）、そのフレームをスイッチ手段１１２からフレーム振分手段１１１と経路＃１とを通してローカルネットワーク２０１に出力する（図２２ステップＳ８１）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスでもなければ（図２２ステップＳ８０）、そのフレームをスイッチ手段１１２から経路＃２を通してカーネル部１２に出力する（図２２ステップＳ８２）。
フレーム振分部１１は経路＃４から入力されると（図２０ステップＳ６１）、入力されるフレームをフレーム振分手段１１１から経路＃１を通してローカルネットワーク２０１に出力する（図２３ステップＳ８３）。
このように、本実施例では、上述した本発明の第３の実施例の効果のほかに、トンネリング装置１の動作においてさらに不必要なフレーム転送処理が行われないように動作させることができる。
次に、本発明の第５の実施例について説明する。本発明の第５の実施例によるネットワークは上述した本発明の第３の実施例によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は上述した本発明の第３の実施例によるトンネリング装置と同様の機能、構成となっているので、それらの説明については省略する。
図２４〜図２７は本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図２４〜図２７とを参照して本発明の第５の実施例によるトンネリング装置１の動作について説明する。尚、図２４〜図２７に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第５の実施例においては、フレーム振分部１１が上述した本発明の第３の実施例によるトンネリング装置１の動作において破棄すべきフレームを破棄するようにしている。但し、フレーム振分部１１は経路＃１，＃２，＃４から入力されるフレームに対しては上述した本発明の第３の実施例と同様に動作するので、図２４のステップＳ９２〜Ｓ１００の動作、図２５のステップＳ１０１の動作、図２７のステップＳ１０９の動作はそれぞれ図１５のステップＳ４２〜Ｓ５０の動作、図１６のステップＳ５１の動作、図１８のステップＳ５７の動作と同様である。よって、経路＃１，＃２，＃４から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はフレームが経路＃３から入力されると（図２４ステップＳ９１）、そのフレームの宛先物理アドレスが経路＃３アドレステーブル１６３に格納されたアドレスのいずれかに一致すれば（図２６ステップＳ１０２）、そのフレームを破棄する（図２６ステップＳ１０３）。
フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスであれば（図２６ステップＳ１０４）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、そのフレームを経路＃２を通してカーネル部１２に出力する（図２６ステップＳ１０５）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２６ステップＳ１０６）、そのフレームを経路＃２を通してカーネル部１２に出力する（図２６ステップＳ１０８）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスでもなければ（図２６ステップＳ１０６）、そのフレームを経路＃１を通してローカルネットワーク２０１に出力する（図２６ステップＳ１０７）。
このように、本実施例では、上述した本発明の第３の実施例のように、本発明の第２の実施例の効果のほかに、トンネリング装置１の動作において不必要なフレーム転送処理が行われないように動作させることができるとともに、トンネリング装置１の動作において破棄すべきフレームを破棄することができる。
以下、破棄すべきフレームについて説明する。この種のフレーム３２８は、主に宛先ＭＡＣアドレスがローカルネットワーク２０１に存在する端末のＭＡＣアドレスである場合である。ローカルネットワーク２０１に接続する端末４−３が端末４−Ｍへフレーム３２８を送信する場合について説明する。
フレーム３２８は端末４−Ｍでも受信されるが、同時にトンネリング装置１のフレーム振分部１１でも物理インタフェース（経路＃１）を通して受信され、宛先ＭＡＣアドレスが自装置のＭＡＣアドレスではないので、非トンネルフレームと判定された後、宛先ＭＡＣアドレスがチェックされる。その宛先ＭＡＣアドレスが経路＃１アドレステーブル１６１に記憶されていれば、他の装置宛の非トンネルフレームとフレーム振分部１１で判断されて破棄される。
もし、宛先ＭＡＣアドレスがまだ経路＃１アドレステーブル１６１に記憶されていないアドレスである場合には、破棄されずに、経路＃３に出力される。この動作は正常であり、例えばローカルネットワーク２０１に接続していた端末４−Ｍが、ローカルネットワーク２０２へ移動して接続した場合にでも、経路＃１アドレステーブル１６１において、端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」について一定期間登録がないものについては削除することによって、「ＭＡＣ１３１」を宛先とするフレームのローカルネットワーク２０２への到達性を保証するために必要である。
図２４〜図２７は本発明の第５の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図２４〜図２７とを参照して本発明の第５の実施例によるトンネリング装置１の動作について説明する。尚、図２４〜図２７に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第５の実施例においては、フレーム振分部１１が上述した本発明の第３の実施例によるトンネリング装置１の動作において破棄すべきフレームを破棄するようにしている。但し、フレーム振分部１１は経路＃１，＃２，＃４から入力されるフレームに対しては上述した本発明の第３の実施例と同様に動作するので、図２４のステップＳ９２〜Ｓ１００の動作、図２５のステップＳ１０１の動作、図２７のステップＳ１０９の動作はそれぞれ図１５のステップＳ４２〜Ｓ５０の動作、図１６のステップＳ５１の動作、図１８のステップＳ５７の動作と同様である。よって、経路＃１，＃２，＃４から入力されるフレームに対する処理についての説明は省略する。
フレーム振分部１１はフレームが経路＃３から入力されると（図２４ステップＳ９１）、そのフレームの宛先物理アドレスが経路＃３アドレステーブル１６３に格納されたアドレスのいずれかに一致すれば（図２６ステップＳ１０２）、そのフレームを破棄する（図２６ステップＳ１０３）。
フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスであれば（図２６ステップＳ１０４）、そのフレームがブロードキャストやマルチキャストのフレームであるので、そのフレームを経路＃１を通してローカルネットワーク２０１に出力するとともに、そのフレームを経路＃２を通してカーネル部１２に出力する（図２６ステップＳ１０５）。
フレーム振分部１１はそのフレームの宛先物理アドレスが自装置の物理アドレスであれば（図２６ステップＳ１０６）、そのフレームを経路＃２を通してカーネル部１２に出力する（図２６ステップＳ１０８）。また、フレーム振分部１１はそのフレームの宛先物理アドレスが同報アドレスでなく、宛先物理アドレスが自装置の物理アドレスでもなければ（図２６ステップＳ１０６）、そのフレームを経路＃１を通してローカルネットワーク２０１に出力する（図２６ステップＳ１０７）。
このように、本実施例では、上述した本発明の第３の実施例のように、本発明の第２の実施例の効果のほかに、トンネリング装置１の動作において不必要なフレーム転送処理が行われないように動作させることができるとともに、トンネリング装置１の動作において破棄すべきフレームを破棄することができる。
以下、破棄すべきフレームについて説明する。この種のフレーム３２８は、主に宛先ＭＡＣアドレスがローカルネットワーク２０１に存在する端末のＭＡＣアドレスである場合である。ローカルネットワーク２０１に接続する端末４−３が端末４−Ｍへフレーム３２８を送信する場合について説明する。
フレーム３２８は端末４−Ｍでも受信されるが、同時にトンネリング装置１のフレーム振分部１１でも物理インタフェース（経路＃１）を通して受信され、宛先ＭＡＣアドレスが自装置のＭＡＣアドレスではないので、非トンネルフレームと判定された後、宛先ＭＡＣアドレスがチェックされる。その宛先ＭＡＣアドレスが経路＃１アドレステーブル１６１に記憶されていれば、他の装置宛の非トンネルフレームとフレーム振分部１１で判断されて破棄される。
もし、宛先ＭＡＣアドレスがまだ経路＃１アドレステーブル１６１に記憶されていないアドレスである場合には、破棄されずに、経路＃３に出力される。この動作は正常であり、例えばローカルネットワーク２０１に接続していた端末４−Ｍが、ローカルネットワーク２０２へ移動して接続した場合にでも、経路＃１アドレステーブル１６１において、端末４−ＭのＭＡＣアドレスである「ＭＡＣ１３１」について一定期間登録がないものについては削除することによって、「ＭＡＣ１３１」を宛先とするフレームのローカルネットワーク２０２への到達性を保証するために必要である。
次に、本発明の第６の実施例について説明する。本発明の第６の実施例によるネットワークは上述した本発明の第１の実施例によるネットワークと同様の構成となっており、そのネットワークを構成するトンネリング装置は上述した本発明の第１の実施例によるトンネリング装置と同様の機能、構成となっているので、それらの説明については省略する。
図２８は本発明の第６の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図２８とを参照して本発明の第６の実施例によるトンネリング装置１の動作について説明する。尚、図２８に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第６の実施例においては、フレーム振分部１１が上述した本発明の第１の実施例によるトンネリング装置１の動作において破棄すべきフレームを破棄するようにしている。但し、フレーム振分部１１は経路＃１〜＃４から入力されるフレームに対しては上述した本発明の第３の実施例と同様に動作するので、図２８のステップＳ１１１，Ｓ１１２，Ｓ１１５〜Ｓ１２３の動作は、図５のステップＳ１〜Ｓ１１の動作と同様である。よって、経路＃１〜＃４から入力されるフレームに対する処理についての破棄処理以外の説明は省略する。
フレーム振分部１１はフレームが経路＃１から入力されると（図２８ステップＳ１１１）、そのフレームの宛先物理アドレスが経路＃１アドレステーブル１６１に格納されたアドレスのいずれかに一致すれば（図２８ステップＳ１１３）、そのフレームを破棄する（図２８ステップＳ１１４）。
このように、本実施例では、上述した本発明の第１の実施例の効果のほかに、トンネリング装置１の動作において破棄すべきフレームを破棄することができる。
図２８は本発明の第６の実施例によるフレーム振分部におけるフレームの振分処理を示すフローチャートである。これら図１〜図３と図２８とを参照して本発明の第６の実施例によるトンネリング装置１の動作について説明する。尚、図２８に示す処理は上記のＣＰＵ１４が制御プログラム１５ａを実行することで実現される。
本発明の第６の実施例においては、フレーム振分部１１が上述した本発明の第１の実施例によるトンネリング装置１の動作において破棄すべきフレームを破棄するようにしている。但し、フレーム振分部１１は経路＃１〜＃４から入力されるフレームに対しては上述した本発明の第３の実施例と同様に動作するので、図２８のステップＳ１１１，Ｓ１１２，Ｓ１１５〜Ｓ１２３の動作は、図５のステップＳ１〜Ｓ１１の動作と同様である。よって、経路＃１〜＃４から入力されるフレームに対する処理についての破棄処理以外の説明は省略する。
フレーム振分部１１はフレームが経路＃１から入力されると（図２８ステップＳ１１１）、そのフレームの宛先物理アドレスが経路＃１アドレステーブル１６１に格納されたアドレスのいずれかに一致すれば（図２８ステップＳ１１３）、そのフレームを破棄する（図２８ステップＳ１１４）。
このように、本実施例では、上述した本発明の第１の実施例の効果のほかに、トンネリング装置１の動作において破棄すべきフレームを破棄することができる。
図２９は本発明の第７の実施例によるトンネリング装置の機能構成を示すブロック図である。図２９において、本発明の第７の実施例によるトンネリング装置１はフレーム振分部１１と、カーネル部（ＡＲＰ）１２ａと、トンネリング部１３とから構成され、フレーム振分部１１はフレーム振分手段１１３と、カーネル部（スタック）１１４とを備えている。
フレーム振分手段１１３は経路＃１から入力されるフレームをカーネル部（スタック）１１４と経路＃３とにそれぞれ振分け、経路＃３から入力されるフレームをカーネル部（スタック）１１４と経路＃１とにそれぞれ振分け、カーネル部（スタック）１１４から入力されるフレームを経路＃１，＃３にそれぞれ振分ける。カーネル部（スタック）１１４はフレーム振分手段１１３から入力されるフレームを経路＃２，＃４に切替えて出力し、経路＃２から入力されるフレームをフレーム振分手段１１３と経路＃４とにそれぞれ切替えて出力し、経路＃４から入力されるフレームをフレーム振分手段１１３と経路＃２とにそれぞれ切替えて出力する。
本実施例はフレーム振分部１１の構成が異なる以外は、上述した各実施例と同様の動作を行い、各実施例と同様の効果を得ることができるので、それらについての説明は省略する。
尚、上述した各実施例については相互に組み合わせることが可能であり、各実施例の構成や動作に限定されるものではない。
フレーム振分手段１１３は経路＃１から入力されるフレームをカーネル部（スタック）１１４と経路＃３とにそれぞれ振分け、経路＃３から入力されるフレームをカーネル部（スタック）１１４と経路＃１とにそれぞれ振分け、カーネル部（スタック）１１４から入力されるフレームを経路＃１，＃３にそれぞれ振分ける。カーネル部（スタック）１１４はフレーム振分手段１１３から入力されるフレームを経路＃２，＃４に切替えて出力し、経路＃２から入力されるフレームをフレーム振分手段１１３と経路＃４とにそれぞれ切替えて出力し、経路＃４から入力されるフレームをフレーム振分手段１１３と経路＃２とにそれぞれ切替えて出力する。
本実施例はフレーム振分部１１の構成が異なる以外は、上述した各実施例と同様の動作を行い、各実施例と同様の効果を得ることができるので、それらについての説明は省略する。
尚、上述した各実施例については相互に組み合わせることが可能であり、各実施例の構成や動作に限定されるものではない。
Claims (15)
- 相手先装置とのトンネリングにおいて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置であって、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化するカプセル化手段と、カプセル化されたパケットをデカプセル化するデカプセル化手段とを含むトンネリング手段と、
前記フレームの処理を行うカーネル手段と、
ネットワークからフレームを受信し、宛先物理アドレスが自装置の物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化手段で用いられているカプセル化方法でカプセル化された第１のフレームを前記デカプセル化手段に出力し、
前記第１のフレーム以外のフレームのうち、前記自装置の物理アドレスを宛先物理アドレスとする第２のフレームを前記カーネル手段へ出力し、
前記第１及び第２のフレーム以外のフレームのうち前記自装置の物理アドレス以外のアドレスを宛先物理アドレスとする第３のフレームを前記カプセル化手段へ出力し、
前記カプセル化手段へ出力した前記第３フレームのうち同報アドレスを前記宛先物理アドレスとする第４のフレームを前記カーネル手段へも出力する振分手段と
を有することを特徴とするトンネリング装置。 - 前記振分手段は、前記カーネル手段から受信した第５のフレームを前記ネットワーク及び前記カプセル化手段のうちの少なくとも一方に出力し、前記デカプセル化手段から受信した第６のフレームの宛先物理アドレスが同報アドレスの場合、前記第６のフレームを前記ネットワークと前記カーネル手段とに出力し、前記第６のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第６のフレームを前記カーネル手段に出力し、前記第６のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの場合、前記第６のフレームを前記ネットワークに出力し、前記カプセル化手段から受信した第７のフレームを前記ネットワークに出力することを特徴とする請求項１記載のトンネリング装置。
- 相手先装置とのトンネリングにおいて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置であって、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化手段と、カプセル化されたパケットをデカプセル化するデカプセル化手段とを含むトンネリング手段と、
前記フレームの処理を行うカーネル手段と、
前記フレームの振分けを行う振分手段とを有し、
前記振分手段は、転送フレーム振分手段とカーネル振分手段とを含み、
前記転送フレーム振分手段は、ネットワークから受信したフレームの宛先物理アドレスが前記自装置の物理アドレスである第１のフレームを前記カーネル振分手段へ出力し、前記第１のフレーム以外の第２のフレームを前記カプセル化手段へ出力し、前記第２のフレームのうちの同報アドレスを前記宛先物理アドレスとする第３のフレームを前記カーネル振分手段へも出力し、
前記カーネル振分手段は、前記転送フレーム振分手段から受信した前記第１のフレームのうち送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化手段で用いられているカプセル化方法でカプセル化された第４のフレームを前記デカプセル化手段に出力し、それ以外の第５のフレームと第３のフレームを前記カーネル手段に出力することを特徴とするトンネリング装置。 - 前記カーネル振分手段は、前記カーネル手段から受信した第６のフレームを前記転送フレーム振分手段へ出力し、
前記転送フレーム振分手段は、前記カーネル振分手段より受信した第６のフレームを前記ネットワーク及び前記カプセル化手段のうちの少なくとも一方に出力し、前記デカプセル化手段から受信した第７のフレームの宛先物理アドレスが同報アドレスの場合、前記第７のフレームを前記ネットワークと前記カーネル振分手段とに出力し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第７のフレームを前記カーネル振分手段に出力し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの場合、前記第７のフレームを前記ネットワークに出力し、前記カプセル化手段から受信した第８のフレームを前記ネットワークへ出力し、
前記カーネル振分手段は前記第７のフレームを前記カーネル手段に出力することを特徴とする請求項３記載のトンネリング装置。 - 相手先装置とのトンネリングにおいて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置であって、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化手段と、カプセル化されたパケットをデカプセル化するデカプセル化手段とを含むトンネリング手段と、
前記フレームの処理を行うカーネル手段と、
前記フレームの振分けを行う振分手段とを有し、
前記振分手段は、トンネル振分手段とスイッチ手段を含み、
前記トンネル振分手段は、ネットワークから受信したフレームのうち宛先物理アドレスが前記自装置の物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化手段で用いられているカプセル化方法でカプセル化された第１のフレームを前記デカプセル化手段に出力し、前記第１のフレーム以外の第２のフレームを前記スイッチ手段に出力し、
前記スイッチ手段は、前記トンネル振分手段から受信した第２のフレームの特徴に基づいて前記自装置の物理アドレスを宛先物理アドレスとする第３のフレームを前記カーネル手段に出力し、同報アドレスを前記宛先物理アドレスとする第４のフレームを前記カーネル手段と前記カプセル化手段とに出力し、前記自装置の物理アドレス以外のアドレスを宛先物理アドレスとする第５のフレームを前記カプセル化手段に出力することを特徴とするトンネリング装置。 - 前記スイッチ手段は、前記カーネル手段から受信した第６のフレームを前記トンネル振分手段及び前記カプセル化手段の少なくとも一方に出力し、前記デカプセル化手段から受信した第７のフレームの宛先物理アドレスが同報アドレスの場合、前記第７のフレームを前記カーネル手段と前記トンネル振分手段とに出力し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第７のフレームを前記カーネル手段に出力し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの時に前記第７のフレームを前記トンネル振分手段に出力し、
前記トンネル振分手段は、前記カプセル化手段から受信した第８のフレームと前記スイッチ手段から受信した第９のフレームを前記ネットワークに出力することを特徴とする請求項５記載のトンネリング装置。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置が、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理とを少なくとも実行するトンネルフレーム振分方法であって、
前記振分処理は、
ネットワークから受信したフレームのうち宛先物理アドレスが前記自装置の物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第１のフレームについて前記デカプセル化処理を実行し、
前記第１のフレーム以外のフレームのうちの前記自装置の物理アドレスを宛先物理アドレスとする第２のフレームについて前記カーネル処理を実行し、
前記自装置の物理アドレス以外のアドレスを宛先物理アドレスとする第３のフレームについて前記カプセル化処理を実行し、
前記第３のフレームのうちの同報アドレスを前記宛先物理アドレスとする第４のフレームについて前記カーネル処理を実行することを特徴とするトンネルフレーム振分方法。 - 前記振分処理は、
前記カーネル処理された第５のフレームを前記ネットワークに出力するが、前記カプセル化処理を実行し、
前記デカプセル化処理された第６のフレームの宛先物理アドレスが同報アドレスの場合、前記第６のフレームを前記ネットワーク出力するとともに、前記カーネル処理を実行し、
前記第６のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第６のフレームについて前記カーネル処理を実行し、
前記第６のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの場合、前記第６のフレームを前記ネットワークに出力し、前記カプセル化処理された第７のフレームを前記ネットワークに出力することを特徴とする請求項７記載のトンネルフレーム振分方法。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置が、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理とを少なくとも実行するトンネルフレーム振分方法であって、
前記振分処理は、転送フレーム振分処理とカーネル振分処理とを含み、
前記転送フレーム振分処理は、
ネットワークから受信したフレームの宛先物理アドレスが前記自装置の物理アドレスである第１のフレームについて前記カーネル振分処理を実行し、
前記第１のフレーム以外の第２のフレームについて前記カプセル化処理を実行し、
前記第２のフレームのうちの同報アドレスを前記宛先物理アドレスとする第３のフレームについて前記カーネル振分処理を実行し、
前記カーネル振分処理は、
前記転送フレーム振分処理された前記第１のフレームのうち宛先物理アドレスが前記自装置の物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第４のフレームについて前記デカプセル化処理を実行し、それ以外の第５のフレームと、第３のフレームについて前記カーネル処理を実行することを特徴とするトンネルフレーム振分方法。 - 前記カーネル振分処理は、前記カーネル処理された第６のフレームについて前記転送フレーム振分処理を実行し、
前記転送フレーム振分処理は、
前記カーネル振分処理された第６のフレームを前記ネットワークへ出力するか、前記カプセル化処理を実行し、
前記デカプセル化処理された第７のフレームの宛先物理アドレスが同報アドレスの場合、前記第７のフレームを前記ネットワークへ出力するとともに、前記カーネル振分処理を実行し、
前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第７のフレームについて前記カーネル振分処理を実行し、
前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの場合、前記第７のフレームを前記ネットワークに出力し、前記カプセル化処理された第８のフレームについて前記ネットワークへ出力し、
前記カーネル振分処理は、前記第７のフレームについて前記カーネル処理を実行することを特徴とする請求項９記載のトンネルフレーム振分方法。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネリング装置が、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理と、を少なくとも実行するトンネルフレーム振分方法であって、
前記振分処理は、トンネル振分処理とスイッチ処理を含み、
前記トンネル振分処理は、
ネットワークから受信したフレームのうち宛先物理アドレスが前記自装置の物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第１のフレームについて前記デカプセル化処理を実行し、
前記第１のフレーム以外の第２のフレームについて前記スイッチ処理を実行し、
前記スイッチ処理は、
前記トンネル振分処理された第２のフレームの特徴に基づいて前記自装置の物理アドレスを宛先物理アドレスとする第３のフレームについて前記カーネル処理を実行し、同報アドレスを前記宛先物理アドレスとする第４のフレームについて前記カーネル処理と前記カプセル化処理とを実行し、前記自装置の物理アドレス以外のアドレスを宛先物理アドレスとする第５のフレームについて前記カプセル化処理を実行することを特徴とするトンネルフレーム振分方法。 - 前記スイッチ処理は、
前記カーネル処理された第６のフレームについて前記トンネル振分処理及び前記カプセル化処理の少なくとも一方を実行し、前記デカプセル化処理された第７のフレームの宛先物理アドレスが同報アドレスの場合、前記第７のフレームについて前記カーネル処理と前記トンネル振分処理とを実行し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレスの場合、前記第７のフレームについて前記カーネル処理を実行し、前記第７のフレームの宛先物理アドレスが前記自装置の物理アドレス以外のアドレスの場合、前記第７のフレームについて前記トンネル振分処理を実行し、
前記トンネル振分処理は、
前記カプセル化処理された第８のフレームと前記スイッチ処理された第９のフレームを前記ネットワークに出力することを特徴とする請求項１１記載のトンネルフレーム振分方法。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネルフレーム振分を実現するプログラムであって、
コンピュータに、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理とを少なくとも実行させ、
前記振分処理は、
ネットワークから受信したフレームのうち宛先物理アドレスが前記コンピュータの物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第１のフレームについて前記デカプセル化処理を実行し、
前記第１のフレーム以外のフレームのうちの前記コンピュータの物理アドレスを宛先物理アドレスとする第２のフレームについて前記カーネル処理を実行し、
前記コンピュータの物理アドレス以外のアドレスを宛先物理アドレスとする第３のフレームについて前記カプセル化処理を実行し、
前記第３のフレームのうちの同報アドレスを前記宛先物理アドレスとする第４のフレームについて前記カーネル処理を実行させることを特徴とするプログラム。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネルフレーム振分を実現するプログラムであって、
コンピュータに、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理とを少なくとも実行させ、
前記振分処理は、転送フレーム振分処理とカーネル振分処理とを含み、
前記転送フレーム振分処理は、
ネットワークから受信したフレームの宛先物理アドレスが前記コンピュータの物理アドレスである第１のフレームについて前記カーネル振分処理を実行し、
前記第１のフレーム以外の第２のフレームについて前記カプセル化処理を実行し、
前記第２のフレームのうちの同報アドレスを前記宛先物理アドレスとする第３のフレームについて前記カーネル振分処理を実行し、
前記カーネル振分処理は、
前記転送フレーム振分処理された前記第１のフレームのうち宛先物理アドレスが前記コンピュータの物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第４のフレームについて前記デカプセル化処理を実行し、それ以外の第５のフレームについて前記カーネル処理を実行させることを特徴とするプログラム。 - 相手先装置とのトンネリングにて、データリンク層のデータ系列であるフレームをカプセル化して送受信するトンネルフレーム振分を実現するプログラムであって、
コンピュータに、
前記フレームをネットワーク層のデータ系列であるパケットにカプセル化を行うカプセル化処理と、カプセル化されたパケットをデカプセル化するデカプセル化処理とを含むトンネリング処理と、
前記フレームの処理を行うカーネル処理と、
前記フレームの振分処理と、を少なくとも実行させ、
前記振分処理は、トンネル振分処理とスイッチ処理を含み、
前記トンネル振分処理は、
ネットワークから受信したフレームのうち宛先物理アドレスが前記コンピュータの物理アドレスであり、送信元論理アドレスが前記１つ以上の相手先装置の論理アドレスであり、前記カプセル化処理で用いられているカプセル化方法でカプセル化された第１のフレームについて前記デカプセル化処理を実行し、
前記第１のフレーム以外の第２のフレームについて前記スイッチ処理を実行し、
前記スイッチ処理は、
前記トンネル振分処理された第２のフレームの特徴に基づいて前記コンピュータの物理アドレスを宛先物理アドレスとする第３のフレームについて前記カーネル処理を実行し、同報アドレスを前記宛先物理アドレスとする第４のフレームについて前記カーネル処理と前記カプセル化処理とを実行し、前記コンピュータの物理アドレス以外のアドレスを宛先物理アドレスとする第５のフレームについて前記カプセル化処理を実行させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007506043A JP4780477B2 (ja) | 2005-03-04 | 2006-02-27 | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2005059830 | 2005-03-04 | ||
| JP2005059830 | 2005-03-04 | ||
| JP2007506043A JP4780477B2 (ja) | 2005-03-04 | 2006-02-27 | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム |
| PCT/JP2006/304179 WO2006093299A1 (ja) | 2005-03-04 | 2006-02-27 | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2006093299A1 JPWO2006093299A1 (ja) | 2008-08-07 |
| JP4780477B2 true JP4780477B2 (ja) | 2011-09-28 |
Family
ID=36941329
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007506043A Expired - Fee Related JP4780477B2 (ja) | 2005-03-04 | 2006-02-27 | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7969996B2 (ja) |
| EP (1) | EP1858205A4 (ja) |
| JP (1) | JP4780477B2 (ja) |
| TW (1) | TWI322606B (ja) |
| WO (1) | WO2006093299A1 (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101326770A (zh) * | 2005-12-09 | 2008-12-17 | 日本电气株式会社 | 帧处理方法以及帧处理设备 |
| JP4993202B2 (ja) * | 2007-12-10 | 2012-08-08 | 横河電機株式会社 | フィールドネットワークシステム |
| US8363672B2 (en) * | 2008-05-08 | 2013-01-29 | Gilat Satellite Networks Ltd. | Optimization of internet traffic based on application prioritization |
| CN101616439A (zh) * | 2009-07-28 | 2009-12-30 | 华为技术有限公司 | 演进网络中的无线自回传方法、装置及系统 |
| US8718061B2 (en) | 2010-11-19 | 2014-05-06 | Industrial Technology Research Institute | Data center network system and packet forwarding method thereof |
| EP2547047B1 (en) * | 2011-07-08 | 2016-02-17 | Alcatel Lucent | Centralized system for routing ethernet packets over an internet protocol network |
| US9866475B2 (en) * | 2012-06-15 | 2018-01-09 | Citrix Systems, Inc. | Systems and methods for forwarding traffic in a cluster network |
| EP2907273B1 (en) * | 2012-10-09 | 2018-12-05 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for establishing and using pdn connections |
| JP6123035B1 (ja) * | 2014-05-05 | 2017-04-26 | テレフオンアクチーボラゲット エルエム エリクソン（パブル） | Ｔｗａｇとｕｅとの間でのｗｌｃｐメッセージ交換の保護 |
| JP6536577B2 (ja) * | 2014-07-11 | 2019-07-03 | ソニー株式会社 | 情報処理装置 |
| WO2016013118A1 (ja) * | 2014-07-25 | 2016-01-28 | 株式会社 日立製作所 | 中継装置、ネットワークシステム、及びネットワークシステムの制御方法 |
| US10015287B2 (en) * | 2015-03-04 | 2018-07-03 | Oracle International Corporation | Efficient tunneled streams for real-time communications |
| US10878028B1 (en) * | 2017-11-22 | 2020-12-29 | Amazon Technologies, Inc. | Replicating and indexing fragments of time-associated data streams |
| US11025691B1 (en) | 2017-11-22 | 2021-06-01 | Amazon Technologies, Inc. | Consuming fragments of time-associated data streams |
| US10944804B1 (en) | 2017-11-22 | 2021-03-09 | Amazon Technologies, Inc. | Fragmentation of time-associated data streams |
| US10764347B1 (en) | 2017-11-22 | 2020-09-01 | Amazon Technologies, Inc. | Framework for time-associated data stream storage, processing, and replication |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000232480A (ja) * | 1999-02-10 | 2000-08-22 | Hitachi Ltd | パケットヘッダ変換装置および通信ノード装置 |
| JP2004032004A (ja) * | 2002-06-21 | 2004-01-29 | Nec Corp | 折り返しポートを備えるスイッチ装置およびカプセル化パケットスイッチング方法 |
| JP2004253975A (ja) * | 2003-02-19 | 2004-09-09 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャストデータ通信システム及びその方法 |
| JP2005101715A (ja) * | 2003-09-22 | 2005-04-14 | Nec Corp | 移動通信システム及び方法と、装置と、制御プログラム |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5654531A (en) * | 1995-08-07 | 1997-08-05 | Delaware Capital Formation, Inc. | Redundant multidrop communication system for elevators |
| CN1174585C (zh) * | 2001-03-29 | 2004-11-03 | 三菱电机株式会社 | 系统间连接适配器及终端设备 |
| US7849217B2 (en) * | 2003-04-30 | 2010-12-07 | Cisco Technology, Inc. | Mobile ethernet |
-
2006
- 2006-02-27 EP EP20060715238 patent/EP1858205A4/en not_active Withdrawn
- 2006-02-27 US US11/817,718 patent/US7969996B2/en not_active Expired - Fee Related
- 2006-02-27 JP JP2007506043A patent/JP4780477B2/ja not_active Expired - Fee Related
- 2006-02-27 WO PCT/JP2006/304179 patent/WO2006093299A1/ja active Application Filing
- 2006-03-02 TW TW95106918A patent/TWI322606B/zh not_active IP Right Cessation
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000232480A (ja) * | 1999-02-10 | 2000-08-22 | Hitachi Ltd | パケットヘッダ変換装置および通信ノード装置 |
| JP2004032004A (ja) * | 2002-06-21 | 2004-01-29 | Nec Corp | 折り返しポートを備えるスイッチ装置およびカプセル化パケットスイッチング方法 |
| JP2004253975A (ja) * | 2003-02-19 | 2004-09-09 | Nippon Telegr & Teleph Corp <Ntt> | マルチキャストデータ通信システム及びその方法 |
| JP2005101715A (ja) * | 2003-09-22 | 2005-04-14 | Nec Corp | 移動通信システム及び方法と、装置と、制御プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| TW200642398A (en) | 2006-12-01 |
| EP1858205A1 (en) | 2007-11-21 |
| JPWO2006093299A1 (ja) | 2008-08-07 |
| EP1858205A4 (en) | 2014-06-25 |
| US7969996B2 (en) | 2011-06-28 |
| WO2006093299A1 (ja) | 2006-09-08 |
| US20090080418A1 (en) | 2009-03-26 |
| TWI322606B (en) | 2010-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4780477B2 (ja) | トンネリング装置及びそれに用いるトンネルフレーム振分方法並びにそのプログラム | |
| EP3863237B1 (en) | Packet forwarding method, packet transmission device, and packet reception device | |
| US8774038B2 (en) | Multicast support for dual stack-lite and internet protocol version six rapid deployment on internet protocol version four infrastructures | |
| US8817815B2 (en) | Traffic optimization over network link | |
| Rentschler et al. | The parallel redundancy protocol for industrial IP networks | |
| JP2006526298A (ja) | イーサネットアクセスシステムに関係した装置及び方法 | |
| WO2015074394A1 (zh) | 一种报文转发方法及装置 | |
| JP2005533445A (ja) | 仮想階層ローカルエリアネットワークのための装置及び方法 | |
| EP1859357A2 (en) | System and method for routing isis traffic through unidirectional links of a computer network | |
| WO2007006195A1 (fr) | Dispositif de routage d’un dispositif d’accès et procédé correspondant acceptant une configuration passive d’adresse | |
| WO2004045153A1 (en) | Methods and apparatus for broadcast domain interworking | |
| WO2008085375A2 (en) | Method and apparatus for multicast routing | |
| WO2022021818A1 (zh) | 数据报文的处理方法及装置、存储介质、电子装置 | |
| CN112822097B (zh) | 报文转发的方法、第一网络设备以及第一设备组 | |
| WO2022117018A1 (zh) | 报文传输的方法和装置 | |
| JP4599429B2 (ja) | 通信システム及び通信方法 | |
| JP2017152814A (ja) | ネットワークシステムおよび中継装置 | |
| JP7273125B2 (ja) | ＢＩＥＲｖ６パケットを送信するための方法および第１のネットワークデバイス | |
| CN113542441B (zh) | 一种通信处理方法及装置 | |
| JP4660346B2 (ja) | ブリッジ装置及びブリッジ装置の制御方法 | |
| JP2006514496A (ja) | 非接続モードにおける仮想私設網の相互接続方法 | |
| WO2020179255A1 (ja) | パケットカプセル化方法およびパケットカプセル化装置 | |
| WO2024176344A1 (ja) | カプセル化装置、通信システム、カプセル化方法、および、カプセル化プログラム | |
| GB2418574A (en) | Translating multicast packets to unicast packets and then converting these unicast packets to multicast packets, by rewriting addresses | |
| JP2016149701A (ja) | ネットワークシステムおよびパケット転送方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081212 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110324 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110523 |
|
| 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: 20110610 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110623 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140715 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4780477 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |