JP4660346B2

JP4660346B2 - ブリッジ装置及びブリッジ装置の制御方法

Info

Publication number: JP4660346B2
Application number: JP2005302169A
Authority: JP
Inventors: 直紀江坂; 茂雄松澤; 丈士石原; 泰弘白崎
Original assignee: Toshiba Corp; NTT Docomo Business Inc; NTT Communications Corp
Current assignee: Toshiba Corp; NTT Docomo Business Inc
Priority date: 2005-10-17
Filing date: 2005-10-17
Publication date: 2011-03-30
Anticipated expiration: 2025-10-17
Also published as: JP2007110654A

Description

本発明は、ＩＰネットワークに適用されるブリッジ装置及びブリッジ装置の制御方法に関する。

パケットの送受信によるエンド・ツー・エンド（End-to-End）型の通信を行うインターネットプロトコル（Internet Protocol）では、通信を行っている両端の端末で扱えるパケットサイズは基本的には自由（ただし最大サイズは６５５３５）である。しかし、ＩＰパケットはイーサネット（登録商標）やＰＰＰ（Point-to-Point Protocol）といったデータリンク層の上で交換されることから、必然的に、パケットのサイズをデータリンク層で送信可能なサイズの最大数に合わせておくことがもっとも効率よい転送であるといえる。このパケットのサイズのことをＭＴＵ（Maximum Transfer Unit;最大転送ユニット）という。

通常、イーサネットの場合においてＭＴＵの値は１５００であり、ＩＰ通信を行う場合はこのＭＴＵ１５００で通信が行われる。例えば、イーサネットで接続されたＬＡＮであれば、どの端末もＭＴＵ１５００で通信することがもっとも効率のよい状態である。なお、この１５００という値は通常は変わらないので、イーサネットを延長するために用いられるブリッジやスイッチングハブといった機器はＭＴＵについて特に処理をしない。ＭＴＵを超えるサイズのＩＰパケットはＩＰ層でフラグメント処理されるが、ブリッジやハブといった機器はＩＰの処理を行う機器ではないので、これらの機器が処理可能なサイズ以上のパケットは廃棄されることになる。

宅内やＳＯＨＯ(Small Office Home Office)ならびに一般のオフィスにおけるネットワーク環境の充実と、ブロードバンドネットワーク、公衆の無線インターネット接続のインフラの普及に伴い、外出先から安全にインターネットを通じて、これら宅内やＳＯＨＯならびにオフィスに接続したいという要求が高まっている。通常、ＭＴＵは一律に揃っていることを仮定してもよいが、遠隔のネットワークと同じＩＰセグメントで通信を行うためにトンネリングを行うような場合、ＭＴＵは変わる可能性がある。「トンネリング」とは、一般に、ＩＰパケット（又はイーサネットフレームなど）をさらに別のＩＰパケットに包んで転送する技術の総称であり、Ｌ３ＶＰＮ(Layer 3 Virtual Private Network)，Ｌ２ＶＰＮ(Layer 2 Virtual Private Network)といった技術が知られる。Ｌ２ＶＰＮについては、より具体的な技術としてＬ２ＴＰ(Layer 2 Tunneling Protocol)，ＭＰＬＳ(Multi Protocol Label Switching)などがある。

例えばレイヤー２（Ｌ２）をレイヤー３（Ｌ３）でカプセル化し、これによりレイヤー２をエミュレートする場合を考えると、そのパケットフォーマットにおいて、カプセル化のためのヘッダ分だけ最大ペイロードは削減され、レイヤー２のＭＴＵが削減されることになる。このようにエミュレートされたレイヤー２をＩＥＥＥ８０２．１Ｄに基づいてブリッジする際には、ブリッジ装置はＭＴＵが違うことを意識しなければならない。例えばＭＴＵ１５００とＭＴＵ１４５４との間のＬ２ブリッジを考える。ＭＴＵ１４５５以上のフレームはＬ２ブリッジではフォワードされず破棄される。このとき、フレームが破棄されたことはレイヤー３には通知されない。

この問題は、ブリッジ装置がマルチキャストフレームを転送する場合や、ユニキャストフレームをフラッディング処理する場合においても考慮する必要がある。

そこで本発明は、フレームをマルチキャストし、又はフラッディングする際におけるＭＴＵ不一致の問題に対処することのできるブリッジ装置及びブリッジ装置の制御方法を提供することを目的とする。

本発明の一観点に係るブリッジ装置は、送信元端末からマルチキャストフレームを受信側ネットワークインターフェースにより受信し、複数の送信側ネットワークインターフェースに送信するブリッジ装置において、前記受信側ネットワークインターフェースが有する第一の最大転送ユニットの値を取得するとともに前記複数の送信側ネットワークインターフェースが有する複数の第二の最大転送ユニットの値を取得する手段と、前記複数の第二の最大転送ユニットの値における最小値が前記第一の最大転送ユニットの値よりも小さいならば、該最大転送ユニットの最小値を含んだＩＣＭＰパケットを前記送信元端末に対して送信する手段とを具備する。

本発明によれば、フレームをマルチキャストし、又はフラッディングする際におけるＭＴＵ不一致の問題に対処することのできるブリッジ装置及びブリッジ装置の制御方法を提供することを目的とする。

以下、図面を参照しながら本発明の実施形態を説明する。

図１は本発明の実施形態に係るブリッジ装置が適用されたネットワークを示す図である。同図に示すように、端末Ａに対しブリッジ装置１を介して端末Ｂ〜端末Ｅが接続されている。ブリッジ装置１は、端末Ａから端末Ｂ〜端末Ｅのいずれかに対して送信されたフレームを転送処理し、あるいは逆に、端末Ｂ〜端末Ｅのいずれかから端末Ａに対して送信されたフレームを転送処理する。このようなブリッジとしての基本機能を実現するため、ブリッジ装置１はＭＡＣアドレス学習部２と、Ｌ２ブリッジフレーム転送処理部３とを有する。ＭＡＣアドレス学習部２は、例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習を行う。Ｌ２ブリッジフレーム転送処理部３は、ＩＥＥＥ８０２．１Ｄの仕様に基づいたブリッジフォワーディング処理を行う。

本発明の第一乃至第四の実施形態は、ブリッジ装置１において例えば図１の端末Ａに相当する送信元端末からマルチキャストフレームを受信側ネットワークインターフェースのポートにより受信し、このマルチキャストフレームをすべての送信側ネットワークインターフェースのポートに送信する、いわゆるマルチキャストを行う際の、ＭＴＵ不一致の問題への対処策を講じたブリッジ装置に関する。

また、本発明の第五乃至第七の実施形態は、ブリッジ装置１において例えば図１の端末Ａに相当する送信元端末から受信側ネットワークインターフェースのポートによりユニキャストフレームを受信したときに該ユニキャストフレームの転送先が未解決ならば、すべての送信側ネットワークインターフェースに対してユニキャストフレームを送信する、いわゆるフラッディング処理を行う際の、ＭＴＵ不一致の問題への対処策を講じたブリッジ装置に関する。

（第一の実施形態）
図２は、本発明の第一の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、図１に示した構成要素に加え、ＭＴＵ判定部４０と、ＩＣＭＰ処理部５０と、ＭＴＵ保持部６と、ＩＰ送信元・宛先保持部７とを備える。

ＭＴＵ判定部４０は、マルチキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４１と、この受信ポート以外のすべてのポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４２と、記憶部４１と記憶部４２の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、当該マルチキャストフレームをどのように処理すればよいかを判定する判定部４４とを備える。判定部４４の具体的な処理内容は後述する。

ＭＴＵ判定部４０は、ＭＡＣアドレス学習部２によりＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレスの学習がなされる際に、同時に、当該ネットワークに接続された機器に対応するネットワークインターフェースごとのＭＴＵの値を取得し、ＭＴＵ保持部６に記憶させる。ＭＴＵの値をいかにして取得するかについて本発明は特定の手法に限定されるものではないが、例えば、ＭＴＵ判定部４０がＩＣＭＰ処理部５０内のＭＴＵ値取得部５１に対してＭＴＵの値の取得を指示する。これに応じてＭＴＵ値取得部５１は例えばＩＣＭＰに基づくパスＭＴＵ検出（path MTU discovery）機能によりネットワーク内の各機器のＭＴＵの値を取得する。

Ｌ２ブリッジフレーム転送処理部３は、上述したようにＩＥＥＥ８０２．１Ｄの仕様に基づいたブリッジフォワーディング処理を行うものであるが、このフォワーディング処理を実行すべきか否かは、判定部４４による処理結果に応じて制御される。

ＩＣＭＰ処理部５０はＭＴＵ値取得部５１とＩＣＭＰパケット送信部５２とを備える。

ＭＴＵ値取得部５１は、上述したパスＭＴＵ検出機能を実装している。ＩＣＭＰのパスＭＴＵ検出については、ＩＰｖ４ではＲＦＣ１１９１に定義され、ＩＰｖ６ではＲＦＣ１９８１に定義されている。パスＭＴＵ検出の概略手順としては、ＩＰパケットにＤＦフラグ（フラグメント禁止フラグ）をセットし、ＭＴＵサイズを様々に変化させて該ＩＰパケットを送信する。これに応じて返答されてくるＩＣＭＰ宛先不達（ICMP destination unreachable）メッセージを受信し、該メッセージにセットされているＭＴＵ値を得る。

ＩＣＭＰパケット送信部５２は、ＭＴＵ判定部４０の判定部４４からの制御により、ＩＣＭＰパケットをマルチキャストフレームの送信元端末に対して送信する。

ＩＰ送信元・宛先保持部７は、当該ブリッジ装置１により過去に行われたフレーム転送の際の送信元ＩＰアドレス（レイヤー３アドレス）と宛先ＩＰアドレスとを対応付けて記憶している。ＩＣＭＰパケット送信部５２は、ＩＣＭＰパケットをマルチキャストフレームの送信元端末に対して送信する際に、そのＩＰアドレスをＩＰ送信元・宛先保持部７から求める。

以上のように構成された本実施形態のブリッジ装置１は、マルチキャストフレームを受信して転送する際におけるＭＴＵ不一致の問題に対処するものであるが、ここで、ＭＴＵの動的な変更について説明する。図１のネットワークにおいて、レイヤー２（Ｌ２）をレイヤー３（Ｌ３）でカプセル化し、これによりレイヤー２をエミュレートする場合を考える。図３は、Ｌ２のエミュレートを行う場合のパケットフォーマットを示している。Ｌ２のエミュレートを行う場合、カプセル化のためのヘッダ分Ｈだけ最大ペイロードＰは削減され、レイヤー２のＭＴＵが削減されることになる。このようにエミュレートされたレイヤー２をＩＥＥＥ８０２．１Ｄに基づいてブリッジする際には、ブリッジ装置１はＭＴＵが違うことを意識しなければならない。

例えばＭＴＵ１５００（マルチキャストフレームの受信ポート）とＭＴＵ１４５４、ＭＴＵ１２８０、ＭＴＵ１１２０（送信側の各ポート）の間のＬ２ブリッジを考える。ＭＴＵ１４５５以上のフレームはＬ２ブリッジではフォワードされず破棄される。このとき、仮にＭＴＵ１４５５以上のフレームが破棄されたことを送信元端末に通知できたとしても、送信元端末がＭＴＵ１４５４のフレームを再送したのでは、依然としてＭＴＵ１２８０、ＭＴＵ１１２０の各ポートへはフォワードきないことから問題である。これは、マルチキャストフレームを転送する際に固有の問題である。

そこで本実施形態のブリッジ装置１では、マルチキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４１に記憶するとともにすべての送信側ポートが有するＭＴＵの値をそれぞれ取得して記憶部４２に記憶し、これら記憶部４１、４２に記憶された値の両者を比較器４３により比較する。判定部４４は、送信側ポートのＭＴＵの最小値が受信側ポートのＭＴＵの値よりも小さいか否かを判定し、そうであるならば、該ＭＴＵの最小値を含んだＩＣＭＰパケットを送信元端末に対して送信するようＩＣＭＰパケット送信部５２に対して指示する。

図４は本発明の第一の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットマルチキャストフレームがブリッジ装置１において受信される（ステップＳ１０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、ＭＴＵ値取得部５１は、マルチキャストフレームを受信したポートのＭＴＵの値およびこの受信ポート以外のすべてのポートのＭＴＵの値を取得する（ステップＳ１０２）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもマルチキャストフレームの受信の後に行う必要はなく、ステップＳ１０１とＳ１０２の実行順序を入れ替えてもよい。

次に、マルチキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４１に格納され、他の全てのポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４２に格納される。ここで判定部４４は、マルチキャストフレームを受信したポートよりも小さいＭＴＵを持つポートが存在するか否かを判定する（ステップＳ１０３）。記憶部４１、４２に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、マルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、マルチキャストフレームの受信ポートを除くすべてのポートに対して該マルチキャストフレームをフォワードするように、判定部４４はＬ２ブリッジフレーム転送処理部３に対して指示する。

これに対し、ステップＳ１０３においてマルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在すると判定されたならば、ＩＣＭＰパケット送信部５２は、マルチキャストフレームの送信元について、そのＩＰアドレスをＩＰ送信元・宛先保持部７から取得し、該マルチキャストフレームのプロトコル種別を判別する（ステップＳ１０５）。

例えばマルチキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のマルチキャストフレームを送信しているならば、ＩＣＭＰパケット送信部５２は、この送信元に対してＩＣＭＰｖ６パケットを送信する（ステップＳ１０６）。あるいは、この送信元がＩＰｖ４を用いている場合、この送信元に対してＩＣＭＰｖ４パケットを送信する（ステップＳ１０７）。なお、プロトコル種別に応じたこれらＩＣＭＰパケットには、送信側ポートのＭＴＵの最小値を含めることが好ましい。

ステップＳ１０６又はＳ１０７においてＩＣＭＰパケットを送信した後は、当該マルチキャストフレームを破棄して今回の受信処理を終了する（ステップＳ１０８）。

ＩＣＭＰパケットによる通知を受けた送信元では、ＩＣＭＰパケットのレイヤー３の処理によって再送等の判定を行うことができる。再送時には、マルチキャストフレームを送信する際のＭＴＵを通知された最小値に一致させることが可能になる。したがって、ブリッジ装置１によるマルチキャストフレームの転送処理時におけるＭＴＵの不一致の問題に適切に対処できる。

（第二の実施形態）
図５は、本発明の第二の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、図１に示した構成要素に加え、マルチキャスト情報学習部８と、マルチキャスト情報保持部９と、ＭＴＵ判定部４０と、ＩＣＭＰ処理部５０と、ＭＴＵ保持部６と、ＩＰ送信元・宛先保持部７とを備える。

マルチキャスト情報学習部８は、ＩＧＭＰ／ＭＬＤｓｎｏｏｐ機能（参考ＵＲＬ＜http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-10.txt＞）に基づいたマルチキャスト情報の学習を行ってマルチキャスト情報保持部９に保持させる。マルチキャスト情報によれば、当該マルチキャストグループに参加している端末に向けて、マルチキャストフレームの転送を行うべきポートを特定することができる。

尚、図５において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

ＭＴＵ判定部４０は、マルチキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４１と、マルチキャスト情報学習部８による学習結果により特定されるマルチキャストフレームの送信対象ポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４５と、記憶部４１と記憶部４５の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、当該マルチキャストフレームをどのように処理すればよいかを判定する判定部４４とを備える。判定部４４の具体的な処理内容は後述する。

本実施形態のブリッジ装置１は、第一の実施形態と同様にマルチキャストフレームを受信して転送する際におけるＭＴＵ不一致の問題に対処するものであるが、マルチキャストフレームのマルチキャストアドレスと該マルチキャストフレームを送信すべきポートとを関連付けるマルチキャスト情報をマルチキャスト情報学習部８により学習し、該マルチキャスト情報に基づいて限定されたポートについてＭＴＵの判定を行う点で第一の実施形態のもとは異なる。

本実施形態のブリッジ装置１では、マルチキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４１に記憶するとともにマルチキャスト情報学習部８による学習結果により特定されるマルチキャストフレームの送信対象ポートのＭＴＵの値をそれぞれ取得して記憶部４５に記憶し、これら記憶部４１、４５に記憶された値の両者を比較器４３により比較する。判定部４４は、送信側ポートのＭＴＵの最小値が受信側ポートのＭＴＵの値よりも小さいか否かを判定し、そうであるならば、該ＭＴＵの最小値を含んだＩＣＭＰパケットを送信元端末に対して送信するようＩＣＭＰパケット送信部５２に対して指示する。

図６は本発明の第二の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットマルチキャストフレームがブリッジ装置１において受信される（ステップＳ２０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、マルチキャスト情報学習部８はＩＧＭＰ／ＭＬＤｓｎｏｏｐ機能によりマルチキャストフレームの送信対象（転送先）ポートを絞り込む（ステップＳ２０２）。

次に、ＭＴＵ値取得部５１は、マルチキャストフレームを受信したポートのＭＴＵの値および転送先ポートのＭＴＵの値を取得する（ステップＳ２０３）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもマルチキャストフレームの受信の後に行う必要はなく、ステップＳ２０１とＳ２０３の実行順序を入れ替えてもよい。

次に、マルチキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４１に格納され、転送先ポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４５に格納される。ここで判定部４４は、マルチキャストフレームを受信したポートよりも小さいＭＴＵを持つポートが存在するか否かを判定する（ステップＳ２０４）。記憶部４１、４５に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、マルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、既に特定されている転送先ポートのすべてに対して該マルチキャストフレームをフォワードするように、判定部４４はＬ２ブリッジフレーム転送処理部３に対して指示する。

これに対し、ステップＳ２０４においてマルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在すると判定されたならば、ＩＣＭＰパケット送信部５２は、マルチキャストフレームの送信元について、そのＩＰアドレスをＩＰ送信元・宛先保持部７から取得し、該マルチキャストフレームのプロトコル種別を判別する（ステップＳ２０６）。

例えばマルチキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のマルチキャストフレームを送信しているならば、ＩＣＭＰパケット送信部５２は、この送信元に対してＩＣＭＰｖ６パケットを送信する（ステップＳ２０７）。あるいは、この送信元がＩＰｖ４を用いている場合、この送信元に対してＩＣＭＰｖ４パケットを送信する（ステップＳ２０８）。なお、プロトコル種別に応じたこれらＩＣＭＰパケットには、転送先ポートのＭＴＵの最小値を含めることが好ましい。

ステップＳ２０７又はＳ２０８においてＩＣＭＰパケットを送信した後は、当該マルチキャストフレームを破棄して今回の受信処理を終了する（ステップＳ２０９）。

ＩＣＭＰパケットによる通知を受けた送信元では、第一の実施形態と同様に、ＩＣＭＰパケットのレイヤー３の処理によって再送等の判定を行うことができる。再送時には、マルチキャストフレームを送信する際のＭＴＵを通知された最小値に一致させることが可能になる。したがって、ブリッジ装置１によるマルチキャストフレームの転送処理時におけるＭＴＵの不一致の問題に適切に対処できる。

（第三の実施形態）
図７は、本発明の第三の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、図１に示した構成要素に加え、ＭＴＵ判定部４０と、ＭＴＵ値取得部５１と、ＭＴＵ保持部６と、フラグメント処理部１００とを備える。

フラグメント処理部１００は、フレームをＩＰプロトコルのバージョン及びＰＷｆｒａｇｍｅｎｔａｔｉｏｎ（参考ＵＲＬ＜http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-05.txt＞）の手順に従った適切なフラグメント処理を行うための、ＩＰフラグメント処理部１０１及びＰＷフラグメント処理部１０２を備える。

尚、図７において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

本実施形態のブリッジ装置１は、第一の実施形態と同様にマルチキャストフレームを受信して転送する際におけるＭＴＵ不一致の問題に対処するものであるが、複数の送信側ポートにおいて、受信側ポートと同一又はそれ以上のＭＴＵの値を有する送信側ポートに対してはマルチキャストフレームをそのまま送信し、受信側ポートよりもＭＴＵの値が小さい送信側ポートに対してはマルチキャストフレームにフラグメント処理を施して送信する点で第一の実施形態のもとは異なる。

本実施形態のブリッジ装置１では、マルチキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４１に記憶するとともにすべての送信側ポートが有するＭＴＵの値をそれぞれ取得して記憶部４２に記憶し、これら記憶部４１、４２に記憶された値の両者を比較器４３により比較する。判定部４４は、複数の送信側ポートにおいて、受信側ポートと同一又はそれ以上のＭＴＵの値を有する送信側ポートに対してはマルチキャストフレームをそのまま送信し、受信側ポートよりもＭＴＵの値が小さい送信側ポートに対してはマルチキャストフレームにフラグメント処理を施して送信するようＬ２ブリッジフレーム転送処理部３又はフラグメント処理部１００に対して指示する。

図８は本発明の第三の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットマルチキャストフレームがブリッジ装置１において受信される（ステップＳ３０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、ＭＴＵ値取得部５１は、マルチキャストフレームを受信したポートを含むすべてのポートのＭＴＵの値を取得する（ステップＳ３０２）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもマルチキャストフレームの受信の後に行う必要はなく、ステップＳ３０１とＳ３０２の実行順序を入れ替えてもよい。

次に、マルチキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４１に格納され、該受信ポートを除く他のすべてのポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４２に格納される。ここで判定部４４は、マルチキャストフレームを受信したポートよりも小さいＭＴＵを持つポートが存在するか否かを判定する（ステップＳ３０３）。記憶部４１、４２に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、マルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、受信ポートを除く他のポートのすべてに対して該マルチキャストフレームをフォワードするように、判定部４４はＬ２ブリッジフレーム転送処理部３に対して指示する（ステップＳ３０４）。

これに対し、ステップＳ３０３においてマルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在すると判定されたならば、マルチキャストフレームの受信ポートを除く全てのポートのそれぞれについて、ＭＴＵの値の比較判定を行うことにより、そのポートについてマルチキャストフレームをフラグメント処理するか、これをそのままフォワードするかを判定する（ステップＳ３０５）。すなわち、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上であるならば、そのポートに対してマルチキャストフレームをそのままフォワードする（ステップＳ３０６）。一方、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上でない場合（ステップＳ３０５＝ＮＯ）、まずフラグメント処理部１００は、マルチキャストフレームのプロトコル種別を判別する（ステップＳ３０７）。例えばマルチキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のマルチキャストフレームを送信しているならば、フラグメント処理部１００は、マルチキャストフレームにＩＰｖ６のフラグメント処理を施して当該ポートに送出する（ステップＳ３０８）。一方、送信元がＩＰｖ４を用いている場合、フラグメント処理部１００は、マルチキャストフレームにＩＰｖ４のフラグメント処理を施して当該ポートに送出する（ステップＳ３０９）。なお、マルチキャストフレームの種別が上記ＩＰｖ６でもＩＰｖ４でもない場合には、マルチキャストフレームを破棄して処理を終了する（ステップＳ３１０）。

本実施形態のように、ＭＴＵの値の大小比較に基づき特定のポートに対してマルチキャストフレームをフラグメント処理することにより、ＭＴＵの値の不一致に起因するフレーム破棄を防止できる。

（第四の実施形態）
図９は、本発明の第四の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、図１に示した構成要素に加え、マルチキャスト情報学習部８と、マルチキャスト情報保持部９と、ＭＴＵ判定部４０と、ＭＴＵ値取得部５１と、ＭＴＵ保持部６と、フラグメント処理部１００とを備える。

フラグメント処理部１００は、フレームをＰＷｆｒａｇｍｅｎｔａｔｉｏｎ（参考ＵＲＬ＜http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-05.txt＞）の手順に従った適切なフラグメント処理を行うための、ＩＰフラグメント処理部１０１及びＰＷフラグメント処理部１０２を備える。

尚、図９において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

ＭＴＵ判定部４０はマルチキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４１と、マルチキャスト情報学習部８による学習結果により特定されるマルチキャストフレームの送信対象ポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４５と、記憶部４１と記憶部４５の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、当該マルチキャストフレームをどのように処理すればよいかを判定する判定部４４とを備える。判定部４４の具体的な処理内容は後述する。

本実施形態のブリッジ装置１は、第三の実施形態と同様に特定のポートに対してはフラグメント処理を施してマルチキャストフレームを転送処理するものであるが、マルチキャストフレームのマルチキャストアドレスと該マルチキャストフレームを送信すべきポートとを関連付けるマルチキャスト情報をマルチキャスト情報学習部８により学習し、該マルチキャスト情報に基づいて限定されたポートについてＭＴＵの判定を行う点で点で第三の実施形態のもとは異なる。

本実施形態のブリッジ装置１では、マルチキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４１に記憶するとともにマルチキャスト情報学習部８による学習結果により特定されるマルチキャストフレームの送信対象ポートのＭＴＵの値をそれぞれ取得して記憶部４５に記憶し、これら記憶部４１、４５に記憶された値の両者を比較器４３により比較する。判定部４４は、複数の送信側ポートにおいて、受信側ポートと同一又はそれ以上のＭＴＵの値を有する送信側ポートに対してはマルチキャストフレームをそのまま送信し、受信側ポートよりもＭＴＵの値が小さい送信側ポートに対してはマルチキャストフレームにフラグメント処理を施して送信するようＬ２ブリッジフレーム転送処理部３又はフラグメント処理部１００に対して指示する。

図９は本発明の第四の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットマルチキャストフレームがブリッジ装置１において受信される（ステップＳ４０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、マルチキャスト情報学習部８はＩＧＭＰ／ＭＬＤｓｎｏｏｐ機能によりマルチキャストフレームの送信対象（転送先）ポートを絞り込む（ステップＳ４０２）。

次に、ＭＴＵ値取得部５１は、マルチキャストフレームを受信したポートを含むすべてのポートのＭＴＵの値を取得する（ステップＳ４０３）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもマルチキャストフレームの受信の後に行う必要はなく、ステップＳ３０１とＳ３０２の実行順序を入れ替えてもよい。

次に、マルチキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４１に格納され、転送先ポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４５に格納される。ここで判定部４４は、マルチキャストフレームを受信したポートよりも小さいＭＴＵを持つポートが存在するか否かを判定する（ステップＳ４０４）。記憶部４１、４５に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、マルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、受信ポートを除く他のポートのすべてに対して該マルチキャストフレームをフォワードするように、判定部４４はＬ２ブリッジフレーム転送処理部３に対して指示する（ステップＳ４０５）。

これに対し、ステップＳ４０４においてマルチキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在すると判定されたならば、転送先ポートのそれぞれについて、ＭＴＵの値の比較判定を行うことにより、そのポートについてマルチキャストフレームをフラグメント処理するか、これをそのままフォワードするかを判定する（ステップＳ４０６）。すなわち、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上であるならば、そのポートに対してマルチキャストフレームをそのままフォワードする（ステップＳ４０７）。一方、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上でない場合（ステップＳ４０６＝ＮＯ）、まずフラグメント処理部１００は、マルチキャストフレームのプロトコル種別を判別する（ステップＳ４０８）。例えばマルチキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のマルチキャストフレームを送信しているならば、フラグメント処理部１００は、マルチキャストフレームにＩＰｖ６のフラグメント処理を施して当該ポートに送出する（ステップＳ４０９）。一方、送信元がＩＰｖ４を用いている場合、フラグメント処理部１００は、マルチキャストフレームにＩＰｖ４のフラグメント処理を施して当該ポートに送出する（ステップＳ４１０）。なお、マルチキャストフレームの種別が上記ＩＰｖ６でもＩＰｖ４でもない場合には、マルチキャストフレームを破棄して処理を終了する（ステップＳ４１１）。

本実施形態によれば、ＩＧＭＰ／ＭＬＤｓｎｏｏｐ機能により絞り込まれたポート（転送先ポート）における特定のポートに対してマルチキャストフレームをフラグメント処理することにより、ＭＴＵの値の不一致に起因するフレーム破棄を防止できる。

（第五の実施形態）
図１１は、本発明の第五の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、ユニキャストフレームのフラッディング処理を行うものであり、Ｌ２ブリッジフレーム転送処理部３がアドレス解決処理部３１を備える。

ＭＴＵ判定部４０は、ユニキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４６と、この受信ポート以外のすべてのポート、すなわちフラッディング対象のポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４７と、記憶部４６と記憶部４７の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、当該ユニキャストフレームをどのように処理すればよいかを判定する判定部４４とを備える。判定部４４の具体的な処理内容は後述する。

尚、図１１において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

本実施形態のブリッジ装置１は、ユニキャストフレームを受信してフラッディング処理する際におけるＭＴＵ不一致の問題に対処するものである。

本実施形態のブリッジ装置１では、ユニキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４６に記憶するとともにフラッディング対象であるすべての送信側ポートが有するＭＴＵの値をそれぞれ取得して記憶部４７に記憶し、これら記憶部４６、４７に記憶された値の両者を比較器４３により比較する。判定部４４は、送信側ポートのＭＴＵのいずれかの値が受信側ポートのＭＴＵの値よりも小さいか否かを判定し、そうであるならばＩＣＭＰパケットを送信元端末に対して送信するようＩＣＭＰパケット送信部５２に対して指示する。

図１２は本発明の第五の実施形態に係るブリッジ装置がユニキャストフレームをフラッディング処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットユニキャストフレームがブリッジ装置１において受信される（ステップＳ５０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、Ｌ２ブリッジフレーム転送処理部３は、受信したユニキャストフレームを転送すべきポートについて、フォワーディングデータベース３２にエントリがあるか否かを調べる。エントリがある場合は、フラッディング処理は不要であり、このエントリにより特定されるポートに対してユニキャストフレームを転送処理して終了する（ステップＳ５０３）。

フォワーディングデータベース３２にエントリがない場合、ＭＴＵ値取得部５１は、ユニキャストフレームを受信したポートのＭＴＵの値およびこの受信ポート以外のすべてのポートのＭＴＵの値を取得する（ステップＳ５０４）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもユニキャストフレームの受信の後に行う必要はなく、ステップＳ５０１とＳ５０４の実行順序を入れ替えてもよい。

次に、ユニキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４６に格納され、他の全てのポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４７に格納される。ここで判定部４４は、ユニキャストフレームを受信したポートよりも小さいＭＴＵを持つフラッディング対象のポートが存在するか否かを判定する（ステップＳ５０５）。記憶部４６、４７に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、このユニキャストフレームをフラッディング処理して処理を終える（ステップＳ５０６）。

ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在するならば、フラッディング処理は禁止される（ステップＳ５０５＝ＹＥＳ）。ＩＣＭＰパケット送信部５２は、ユニキャストフレームの送信元について、そのＩＰアドレスをＩＰ送信元・宛先保持部７から取得し、該ユニキャストフレームのプロトコル種別を判別する（ステップＳ５０７）。

例えばユニキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のユニキャストフレームを送信しているならば、ＩＣＭＰパケット送信部５２は、この送信元に対してＩＣＭＰｖ６パケットを送信する（ステップＳ５０８）。あるいは、この送信元がＩＰｖ４を用いている場合、この送信元に対してＩＣＭＰｖ４パケットを送信する（ステップＳ５０９）。なお、プロトコル種別に応じたこれらＩＣＭＰパケットには、送信側ポートのＭＴＵの最小値を含めることが好ましい。

ステップＳ５０８又はＳ５０９においてＩＣＭＰパケットを送信した後は、当該ユニキャストフレームを破棄して今回の受信処理を終了する（ステップＳ５１０）。

ＩＣＭＰパケットによる通知を受けた送信元では、ＩＣＭＰパケットのレイヤー３の処理によって再送等の判定を行うことができる。再送時には、ユニキャストフレームを送信する際のＭＴＵを通知された最小値に一致させることが可能になる。したがって、ブリッジ装置１によるユニキャストフレームの転送処理時におけるＭＴＵの不一致の問題に適切に対処できる。

（第六の実施形態）
図１３は、本発明の第六の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、ユニキャストフレームのフラッディング処理を行うものであり、Ｌ２ブリッジフレーム転送処理部３がアドレス解決処理部３１を備える。

ＭＴＵ判定部４０は、ユニキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４６と、この受信ポート以外のすべてのポート、すなわちフラッディング対象のポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４７と、記憶部４６と記憶部４７の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、アドレス解決処理を制御するアドレス解決処理制御部４８とを備える。アドレス解決処理制御部４８の具体的な処理内容は後述する。

尚、図１３において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

本実施形態のブリッジ装置１は、第五の実施形態と同様にユニキャストフレームを受信してフラッディング処理する際におけるＭＴＵ不一致の問題に対処するものである。

本実施形態のブリッジ装置１では、ユニキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４６に記憶するとともにフラッディング対象であるすべての送信側ポートが有するＭＴＵの値をそれぞれ取得して記憶部４７に記憶し、これら記憶部４６、４７に記憶された値の両者を比較器４３により比較する。アドレス解決処理制御部４８は、フラッディング対象である送信ポートのＭＴＵの値のいずれかの値が受信ポートのＭＴＵの値よりも小さいならば、フラッディング処理を禁止するとともに送信元端末を送信元とするアドレス解決手順を実行するようＬ２ブリッジフレーム転送処理部３のアドレス解決処理部３１を制御する。そして、アドレス解決処理部３１のアドレス解決手順により解決された転送先に対してユニキャストフレームを送信するようにする。

図１４は本発明の第六の実施形態に係るブリッジ装置がユニキャストフレームをフラッディング処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットユニキャストフレームがブリッジ装置１において受信される（ステップＳ６０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、Ｌ２ブリッジフレーム転送処理部３は、受信したユニキャストフレームを転送すべきポートについて、フォワーディングデータベース３２にエントリがあるか否かを調べる（Ｓ６０２）。エントリがある場合は、フラッディング処理は不要であり、このエントリにより特定されるポートに対してユニキャストフレームを転送処理して終了する（ステップＳ６０３）。

フォワーディングデータベース３２にエントリがない場合、ＭＴＵ値取得部５１は、ユニキャストフレームを受信したポートのＭＴＵの値およびこの受信ポート以外のすべてのポートのＭＴＵの値を取得する（ステップＳ６０４）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもユニキャストフレームの受信の後に行う必要はなく、ステップＳ６０１とＳ６０４の実行順序を入れ替えてもよい。

次に、ユニキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４６に格納され、他の全てのポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４７に格納される。ここで判定部４４は、ユニキャストフレームを受信したポートよりも小さいＭＴＵを持つフラッディング対象のポートが存在するか否かを判定する（ステップＳ６０５）。記憶部４６、４７に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、このユニキャストフレームをフラッディング処理して処理を終える（ステップＳ６０６）。

ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在するならば、フラッディング処理は禁止される（ステップＳ６０５＝ＹＥＳ）。

ここで、アドレス解決処理制御部４８は、受信したユニキャストフレームのプロトコル種別を判別する（ステップＳ６０７）。例えばユニキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のユニキャストフレームを送信しているならば、アドレス解決処理制御部４８は、アドレス解決処理部３１に対してＲＦＣ２４６１に規定されるＮＤ（ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙ）パケットをすべてのポートに送信するよう指示する（ステップＳ６０８）。あるいは、この送信元がＩＰｖ４を用いている場合、アドレス解決処理制御部４８は、アドレス解決処理部３１に対してＲＦＣ８２６に規定されるＡＲＰ（ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ）の要求パケットをすべてのポートに送信するよう指示する（ステップＳ６０９）。

ステップＳ６０８又はＳ６０９においてＮＤパケット又はＡＲＰ要求パケットを送信した後、一定時間待機し（ステップＳ６１０）、再度、フォワーディングデータベース３２を参照し、エントリが有るか否かを調べる（ステップＳ６１１）。エントリがある場合は、そのポートに対してユニキャストフレームを送信し（ステップＳ６１３）、エントリが無い場合は当該ユニキャストフレームを破棄（ステップＳ６１２）して終了する。

このような本実施形態では、ＭＴＵ判定後のアドレス解決処理により、受信したユニキャストフレームをフラッディングすることなく送信できる可能性があり、アドレス解決できずＭＴＵが不一致の場合はフラッディングを適切に禁止できる。

（第七の実施形態）
図１５は、本発明の第七の実施形態に係わり、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本実施形態に係るブリッジ装置１は、ユニキャストフレームのフラッディング処理を行うものであり、Ｌ２ブリッジフレーム転送処理部３がアドレス解決処理部３１を備える。また、フラグメント処理部１００を備える。フラグメント処理部１００は、フレームをＩＰプロトコルのバージョン及びＰＷｆｒａｇｍｅｎｔａｔｉｏｎ（参考ＵＲＬ＜http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-05.txt＞）の手順に従った適切なフラグメント処理を行うための、ＩＰフラグメント処理部１０１及びＰＷフラグメント処理部１０２を備える。

ＭＴＵ判定部４０は、ユニキャストフレームを受信したポートのＭＴＵ（最大転送ユニット）の値をＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４６と、この受信ポート以外のすべてのポート、すなわちフラッディング対象のポートのＭＴＵの値をそれぞれＭＴＵ保持部６から読み出して記憶する、例えばレジスタ等の記憶部４７と、記憶部４６と記憶部４７の値の大小を比較する比較器（ＣＯＭＰ）４３と、記憶部４６と記憶部４７の値の大小を比較する比較器（ＣＯＭＰ）４３と、比較器４３による比較結果に応じて、当該ユニキャストフレームをどのように処理すればよいかを判定する判定部４４とを備える。判定部４４の具体的な処理内容は後述する。

尚、図１５において、本実施形態のブリッジ装置１において第一の実施形態と実質的に同一の構成要素には第一の実施形態と同一の参照符号が付してあり、その詳細な説明は省略する。

本実施形態のブリッジ装置１では、ユニキャストフレームを受信した際に、その受信ポートが有するＭＴＵの値を取得して記憶部４６に記憶するとともにフラッディング対象であるすべての送信側ポートが有するＭＴＵの値をそれぞれ取得して記憶部４７に記憶し、これら記憶部４６、４７に記憶された値の両者を比較器４３により比較する。判定部４４は、送信側ポートのＭＴＵの最小値が受信側ポートのＭＴＵの値よりも小さいか否かを判定し、そのようなポートについてはフラグメント処理を施す。

図１６は本発明の第七の実施形態に係るブリッジ装置がユニキャストフレームをフラッディング処理する手順を示すフローチャートである。

まず、送信元端末から送信されたイーサネットユニキャストフレームがブリッジ装置１において受信される（ステップＳ７０１）。このとき、ＭＡＣアドレス学習部２により例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習が行われる。

次に、Ｌ２ブリッジフレーム転送処理部３は、受信したユニキャストフレームを転送すべきポートについて、フォワーディングデータベース３２にエントリがあるか否かを調べる（Ｓ７０２）。エントリがある場合は、フラッディング処理は不要であり、このエントリにより特定されるポートに対してユニキャストフレームを転送処理して終了する（ステップＳ７０３）。

フォワーディングデータベース３２にエントリがない場合、ＭＴＵ値取得部５１は、ユニキャストフレームを受信したポートのＭＴＵの値およびこの受信ポート以外のすべてのポートのＭＴＵの値を取得する（ステップＳ７０４）。これらＭＴＵの値はＭＴＵ保持部６に格納される。なお、ＭＴＵの値の取得は必ずしもユニキャストフレームの受信の後に行う必要はなく、ステップＳ７０１とＳ７０４の実行順序を入れ替えてもよい。

次に、ユニキャストフレームの受信ポートのＭＴＵの値がＭＴＵ保持部６から読み出されて記憶部４６に格納され、他の全てのポートのＭＴＵの値が同様にＭＴＵ保持部６から読み出されて記憶部４７に格納される。ここで判定部４４は、ユニキャストフレームを受信したポートよりも小さいＭＴＵを持つフラッディング対象のポートが存在するか否かを判定する（ステップＳ７０５）。記憶部４６、４７に記憶されたＭＴＵの値の大小比較は比較器４３により行われる。そして、ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在しないならば、このユニキャストフレームをフラッディング処理して処理を終える（ステップＳ７０６）。

ユニキャストフレームの受信ポートよりも小さいＭＴＵを持つポートが存在するならば、そのようなポートについてはフレームにフラグメント処理を施す（ステップＳ７０５＝ＹＥＳ）。

ユニキャストフレームの受信ポートを除く全てのポートのそれぞれについて、ＭＴＵの値の比較判定を行うことにより、そのポートについてユニキャストフレームをフラグメント処理するか、これをそのままフォワードするかを判定する（ステップＳ７０７）。すなわち、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上であるならば、そのポートに対してユニキャストフレームをそのままフォワードする（ステップＳ７０８）。一方、当該ポートのＭＴＵの値が受信ポートのＭＴＵの値以上でない場合（ステップＳ７０７＝ＮＯ）、まずフラグメント処理部１００は、ユニキャストフレームのプロトコル種別を判別する（ステップＳ７０９）。例えばユニキャストフレームの送信元がＩＰｖ６を用いており、ＩＰｖ６のユニキャストフレームを送信しているならば、フラグメント処理部１００は、ユニキャストフレームにＩＰｖ６のフラグメント処理を施して当該ポートに送出する（ステップＳ７１０）。一方、送信元がＩＰｖ４を用いている場合、フラグメント処理部１００は、ユニキャストフレームにＩＰｖ４のフラグメント処理を施して当該ポートに送出する（ステップＳ７１１）。なお、ユニキャストフレームの種別が上記ＩＰｖ６でもＩＰｖ４でもない場合には、ユニキャストフレームを破棄して処理を終了する（ステップＳ７１２）。

本実施形態のように、ＭＴＵの値の大小比較に基づき特定のポートに対してユニキャストフレームをフラグメント処理することにより、ＭＴＵの値の不一致に起因するフレーム破棄を防止できる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の実施形態に係るブリッジ装置が適用されたネットワークを示す図本発明の第一の実施形態に係るブリッジ装置の主要部を示すブロック図Ｌ２のエミュレートを行う場合のパケットフォーマットの一例を示す図本発明の第一の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャート本発明の第二の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第二の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャート本発明の第三の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第三の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャート本発明の第四の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第四の実施形態に係るブリッジ装置がマルチキャストフレームを処理する手順を示すフローチャート本発明の第五の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第五の実施形態に係るブリッジ装置がユニキャストフレームのフラッディング処理を行う手順を示すフローチャート本発明の第六の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第六の実施形態に係るブリッジ装置がユニキャストフレームのフラッディング処理を行う手順を示すフローチャート本発明の第七の実施形態に係るブリッジ装置の主要部を示すブロック図本発明の第七の実施形態に係るブリッジ装置がユニキャストフレームのフラッディング処理を行う手順を示すフローチャート

符号の説明

１…ブリッジ装置（Ｌ２ブリッジ）；
２…ＭＡＣアドレス学習部；
３…Ｌ２ブリッジフレーム転送処理部；
４０…ＭＴＵ判定部；
５０…ＩＣＭＰ処理部；
５１…ＭＴＵ値取得部；
５２…ＩＣＭＰパケット送信部；
６…ＭＴＵ保持部；
７…ＩＰ送信元・宛先保持部

Claims

送信元端末から受信側ネットワークインターフェースによりユニキャストフレームを受信したときに該ユニキャストフレームの転送先が未解決ならば、複数の送信側ネットワークインターフェースに対して前記ユニキャストフレームを送信するフラッディング処理を行うブリッジ装置において、
前記受信側ネットワークインターフェースが有する第一の最大転送ユニットの値を取得するとともに前記複数の送信側ネットワークインターフェースが有する複数の第二の最大転送ユニットの値を取得する手段と、
前記複数の第二の最大転送ユニットの値のいずれかの値が前記第一の最大転送ユニットの値よりも小さいならば、前記フラッディング処理を禁止するとともに前記送信元端末を送信元とするアドレス解決手順を実行する手段と、
前記アドレス解決手順により解決された転送先に対して前記ユニキャストフレームを送信する手段とを具備するブリッジ装置。
前記複数の送信側ネットワークインターフェースにおいて、前記第一の最大転送ユニットと同一又はそれ以上の最大転送ユニットの値を有する送信側ネットワークインターフェースに対しては前記ユニキャストフレームをそのまま送信し、前記第一の最大転送ユニットよりも最大転送ユニットの値が小さい送信側ネットワークインターフェースに対しては前記ユニキャストフレームにフラグメント処理を施して送信する手段をさらに具備する請求項１記載のブリッジ装置。
送信元端末から受信側ネットワークインターフェースによりユニキャストフレームを受信したときに該ユニキャストフレームの転送先が未解決ならば、複数の送信側ネットワークインターフェースに対して前記ユニキャストフレームを送信するフラッディング処理を行うブリッジ装置の制御方法において、
前記受信側ネットワークインターフェースが有する第一の最大転送ユニットの値を取得するとともに前記複数の送信側ネットワークインターフェースが有する複数の第二の最大転送ユニットの値を取得するステップと、
前記複数の第二の最大転送ユニットの値のいずれかの値が前記第一の最大転送ユニットの値よりも小さいならば、前記フラッディング処理を禁止するとともに前記送信元端末を送信元とするアドレス解決手順を実行するステップと、
前記アドレス解決手順により解決された転送先に対して前記ユニキャストフレームを送信するステップとを具備するブリッジ装置の制御方法。
前記複数の送信側ネットワークインターフェースにおいて、前記第一の最大転送ユニットと同一又はそれ以上の最大転送ユニットの値を有する送信側ネットワークインターフェースに対しては前記ユニキャストフレームをそのまま送信し、前記第一の最大転送ユニットよりも最大転送ユニットの値が小さい送信側ネットワークインターフェースに対しては前記ユニキャストフレームにフラグメント処理を施して送信するステップをさらに具備する請求項４記載のブリッジ装置の制御方法。