JP2929266B2 - 受信フレームに対する高速処理方式 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ゲートウェイ装置
内の受信側ネットワークインタフェース部において、フ
レーム処理の高速化を図るための高速処理方式に関する
ものである。

【０００２】

【従来の技術】複数のネットワークを相互に接続し、ネ
ットワーク間でのフレーム転送を提供するゲートウェイ
装置に対し、伝送路速度の高速化及びマルチメディア通
信の普及に伴って内部処理能力の向上が望まれている。
従来、図８に示すように、ゲートウェイ装置内の受信側
ネットワークインタフェース部において、ネットワーク
コントローラ部５１は、伝送路からの受信フレームの先
頭を検出し、メモリ５２の所定の領域にそのフレームデ
ータを順次書き込むフレーム受信処理を行う。

【０００３】続いて、プロトコル処理部５３は、ネット
ワークコントローラ部５１のフレーム受信処理終了後、
そのフレームをメモリ５２から読み出し、プロトコル処
理を行い、宛先アドレスから送信側ネットワークインタ
フェースを決定する。そして、フレーム転送処理部５４
は、プロトコル処理部５３で決定した転送先情報に従っ
てフレームを送信側ネットワークインタフェース部へ転
送する。

【０００４】

【発明が解決しようとする課題】以上のように従来の受
信側ネットワークインタフェース部では、受信フレーム
に対する各処理をシーケンシャルに行っているため、ネ
ットワークコントローラ部での１フレームの受信が終了
しない限り、そのフレームに対するプロトコル処理を実
行することができず、更にプロトコル処理が終了しない
限り、そのフレームを送信側ネットワークインタフェー
ス部に転送することができず、全体として１フレームに
対する転送処理に時間がかかるという問題点があった。
本発明は、上記課題を解決するためになされたもので、
処理遅延を逓減し、ゲートウェイ装置全体としてのフレ
ーム転送能力の向上を図ることができる高速処理方式を
提供することを目的とする。

【０００５】

【課題を解決するための手段】本発明は、ゲートウェイ
装置の受信側ネットワークインタフェース部において、
ネットワークコントローラ部が受信フレームをメモリに
書き込むフレーム受信処理と平行して、ネットワークコ
ントローラ部から受信フレームを取り込み、受信フレー
ムのプロトコル処理をハードウェアで行い、このプロト
コル処理の結果を受信フレームと対応させて前記メモリ
に書き込むパラレルプロトコル処理部を有するものであ
る。これにより、フレーム受信処理とプロトコル処理と
を同時に行うことができる。また、パラレルプロトコル
処理部は、受信フレームのフレーム種別を識別し、この
識別結果を受信フレームと対応させてメモリに書き込む
ものである。これにより、フレーム受信処理とプロトコ
ル処理におけるフレーム識別処理とを同時に行うことが
できる。

【０００６】また、パラレルプロトコル処理部は、受信
フレームのフレーム種別を識別するヘッダ比較部と、前
記フレーム種別ごとに設けられ、受信フレーム中のネッ
トワークレイヤにおける宛先論理アドレスを基に、これ
に対応した転送先を求めることを前記フレーム種別に応
じて行い、求めた転送先情報を受信フレームと対応させ
てメモリに書き込む１つ又は複数のルーティング処理部
とを備えるものである。これにより、フレーム受信処理
とプロトコル処理におけるフレーム識別処理及びルーテ
ィング処理とを同時に行うことができる。また、パラレ
ルプロトコル処理部は、受信フレーム中の物理伝送路に
応じた宛先物理アドレスをラッチするヘッダラッチ部
と、宛先物理アドレスと転送先との対応関係を格納し、
ヘッダラッチ部によって保持された宛先物理アドレスを
基に、これに対応した転送先を求め、求めた転送先情報
を受信フレームと対応させてメモリに書き込むスイッチ
ングテーブルとを備えるものである。これにより、フレ
ーム受信処理とプロトコル処理におけるスイッチング処
理とを同時に行うことができる。

【０００７】

【発明の実施の形態】

実施の形態の１．図１は本発明の第１の実施の形態とな
る高速処理方式を示す受信側ネットワークインタフェー
ス部のブロック図である。１は物理伝送路５からフレー
ムを受信するネットワークコントローラ部、２はコント
ローラ部１で受信された受信フレームを格納するメモ
リ、３はコントローラ部１が受信フレームをメモリ２に
書き込むフレーム受信処理と平行して、受信フレームの
プロトコル処理を行うパラレルプロトコル処理部、４は
メモリ２に格納された受信フレームを図示しない送信側
ネットワークインタフェース部へ転送するフレーム転送
処理部である。

【０００８】次に、このような受信側ネットワークイン
タフェース部の動作を説明する。ネットワークコントロ
ーラ部１は、物理伝送路５からフレームを受信し、受信
したフレームデータＤ１を所定の書き込みアドレスＡ１
によってメモリ２の所定の領域２ａに書き込む。このよ
うなフレーム受信処理と平行して、パラレルプロトコル
処理部３は、ネットワークコントローラ部１から出力さ
れた書き込みアドレスＡ１及びフレームデータＤ１を取
り込み、受信フレームのフレーム種別を識別して、この
識別結果を受信フレームと対応させてメモリ２に書き込
む。

【０００９】図２はこのパラレルプロトコル処理部３の
ブロック図である。アドレスデコーダ１１は、コントロ
ーラ部１から出力された書き込みアドレスＡ１を取り込
み、このアドレスＡ１を解析することによりコントロー
ラ部１がメモリ２にフレームデータＤ１を書き始めるタ
イミング（以下、フレーム書き込み開始タイミングとす
る）を検出し、これをラッチパルス生成部１２に通知す
る。

【００１０】ラッチパルス生成部１２は、データバス上
を流れているフレームデータＤ１からヘッダ情報を取り
込むためのタイミングパルスを生成する。図３（ａ）
は、ＩＥＥＥ８０２規格のフレームフォーマット及びイ
ーサネット（Ethernet）形式のフレームフォーマットの
うち、ヘッダ情報の部分を示す図であり、縦方向のサイ
ズは３２ビットである。

【００１１】図３（ａ）において、１０１は宛先アドレ
ス（MAC Dest.Add. : Media AccessControl Destinatio
n Address）が格納されるフィールド、１０２は送信元
アドレス（MAC Sour.Add. : Media Access Control Sou
rce Address ）が格納されるフィールド、１０３はフレ
ームタイプ／フレームの長さ（イーサネット形式；Fram
e Type／ＩＥＥＥ８０２規格；Length ）が格納される
フィールドである。

【００１２】また、１０４はＩＥＥＥ８０２規格におけ
る送信元サービス・アクセス・ポイント、宛先サービス
・アクセス・ポイント・フィールド（LLC SSAP DSAP :
Logical Link Control Source Service Access Point D
estination Service AccessPoint ）が格納されるフィ
ールド、１０５はＩＥＥＥ８０２規格における制御デー
タ（LLC Cont. : Logical Link Control Control）が格
納されるフィールド、１０６はＩＥＥＥ８０２規格にお
けるサブネットワーク・アクセス・プロトコル（LLC SN
AP : Logical Link Control Sub-Network Access Proto
col ）が格納されるフィールドである。なお、イーサネ
ット形式においては、１０４〜１０６のフィールドには
上位プロトコルのデータが格納されている。

【００１３】また、図３（ｂ）に示すＴ１は、区間ｔ１
のデータ、すなわちフィールド１０１の上位３２ビット
を取り込むためのタイミングパルスである。同様に、図
３（ｃ）に示すＴ２は、区間ｔ２のデータ、すなわちフ
ィールド１０１の下位１６ビットとフィールド１０２の
上位１６ビットを取り込むためのパルス、Ｔ３はフィー
ルド１０２の下位３２ビットを取り込むためのパルス、
Ｔ４は区間ｔ４のデータを取り込むためのパルス、Ｔ５
は区間ｔ５のデータを取り込むためのパルス、Ｔ６は区
間ｔ６のデータを取り込むためのパルスである。

【００１４】ＩＥＥＥ８０２規格及びイーサネット形式
のフレームフォーマットにおいて、図３（ａ）に示すよ
うなヘッダ情報がどの位置に置かれているかは予め分か
っているので、ラッチパルス生成部１２は、フレーム書
き込みの開始タイミングからタイミングパルスＴ１〜Ｔ
６を生成することができる。次に、ヘッダ比較部１３
は、受信フレームのヘッダ情報を解析してそのフレーム
種別を識別する。図４はヘッダ比較部１３のブロック図
である。

【００１５】ラッチ部２１〜２５は、ネットワークコン
トローラ部１から出力されたフレームデータＤ１をラッ
チパルス生成部１２から出力されたタイミングパルスＴ
１、Ｔ２、Ｔ４〜Ｔ６によってそれぞれラッチする。ア
ドレス比較部２６は、予め自分自身（ここでは、ネット
ワークコントローラ部１）に割り当てられたアドレスを
記憶しており、これをラッチ部２１、２２によって保持
されたフィールド１０１の宛先アドレスと比較し、コン
トローラ部１で受信されたフレームが自分宛のものか否
かを判断する。

【００１６】そして、アドレスが一致せず、自分宛のも
のではないと判断した場合は、比較結果保持レジスタ１
４内の識別情報のうち、下から１２ビット目（図４のＢ
ｒｉｄｇｅ）をビット「１」にセットする。また、アド
レスが一致して、自分宛のものであると判断した場合
は、レジスタ２７〜２９をイネーブル状態にする。

【００１７】レジスタ２７は、ヘッダ情報中の区間ｔ４
（フィールド１０３、１０４）のデータに対応した複数
のデータパターンを各領域に記憶しており、イネーブル
状態になると、ラッチ回路２３によって保持された区間
ｔ４のデータを各領域に格納されたデータパターンと比
較し、一致すればその領域の出力をビット「１」にセッ
トする。ここで、レジスタ２７の領域２７ａには、デー
タパターンとして「８１３７ＸＸＸＸ」が格納されてい
る。なお、以降で説明するデータパターンは全て１６進
表記とし、「Ｘ」は任意のデータ（すなわち、比較の対
象にならない）とする。

【００１８】また、領域２７ｂには「８０３８ＸＸＸＸ
〜８０４２ＸＸＸＸ」が格納され、領域２７ｃには「６
０００ＸＸＸＸ〜６０９９ＸＸＸＸ」、領域２７ｄには
「０８００ＸＸＸＸ」、領域２７ｅには「０８０６ＸＸ
ＸＸ」、領域２７ｆには「０６００ＸＸＸＸ」が格納さ
れている。

【００１９】そして、領域２７ｇの上位１６ビットには
「００００〜０５ＤＣ」、下位１６ビットには「ＦＦＦ
Ｆ」が格納され、領域２７ｈの上位１６ビットには「０
０００〜０５ＤＣ」、下位１６ビットには「ＦＥＦ
Ｅ」、領域２７ｉの上位１６ビットには「００００〜０
５ＤＣ」、下位１６ビットには「Ｅ０Ｅ０」、領域２７
ｊの上位１６ビットには「００００〜０５ＤＣ」、下位
１６ビットには「４２４２」、領域２７ｋの上位１６ビ
ットには「００００〜０５ＤＣ」、下位１６ビットには
「ＡＡＡＡ」が格納されている。

【００２０】また、レジスタ２８は、ヘッダ情報中の区
間ｔ５のデータに対応した複数のデータパターンを記憶
しており、イネーブル状態になると、レジスタ２７と同
様にラッチ回路２４によって保持された区間ｔ５のデー
タを各領域に格納されたデータパターンと比較する。こ
のレジスタ２８の領域２８ａには、「０３ＸＸＸＸＸ
Ｘ」が格納され、領域２８ｂには「０３０００００
０」、領域２８ｃには「ＡＦＸＸＸＸＸＸ」、領域２８
ｄには「ＢＦＸＸＸＸＸＸ」、領域２８ｅには「Ｅ３Ｘ
ＸＸＸＸＸ」、領域２８ｆには「Ｆ３ＸＸＸＸＸＸ」が
格納されている。

【００２１】また、レジスタ２９は、ヘッダ情報中の区
間ｔ６のデータに対応した複数のデータパターンを記憶
しており、イネーブル状態になると、ラッチ回路２５に
て保持された区間ｔ６のデータを各領域に格納されたデ
ータパターンと比較する。このレジスタ２９の領域２９
ａには、「８１３７ＸＸＸＸ」が格納され、領域２９ｂ
には「８０９ＢＸＸＸＸ」、領域２９ｃには「８０Ｆ３
ＸＸＸＸ」が格納されている。

【００２２】このようなレジスタ２７〜２９において、
例えばレジスタ２７は、ラッチ回路２３によって保持さ
れたデータが領域２７ａ又は２７ｇに格納されたデータ
パターンと一致すると、この領域の出力をビット「１」
にセットする。これにより、比較結果保持レジスタ１４
の下から１１ビット目（図４のＩＰＸ）が「１」にセッ
トされる。こうして、コントローラ部１で受信されたフ
レームがＩＰＸ（Internet Packet Exchange）プロトコ
ル形式のフレームであると識別されたことになる。な
お、ＩＰＸについては、別の条件が成立した場合にも
「１」がセットされることがあるが、これについては後
述する。

【００２３】また、ラッチ回路２３のデータが領域２７
ｂ又は２７ｃのデータと一致すると、レジスタ１４の１
０ビット目（ＤＥＣｎｅｔ）が「１」にセットされる。
こうして、受信フレームがディジタルイクイップメント
（ＤＥＣ）社のネットワーク形式のフレームであると識
別されたことになる。また、ラッチ回路２３のデータが
領域２７ｄのデータと一致すると、レジスタ１４の９ビ
ット目（ＩＰ：Internet Protocol ）が「１」にセット
される。これは、受信フレームがＩＰ形式のフレームで
あると識別されたことを意味する。

【００２４】また、ラッチ回路２３のデータが領域２７
ｅのデータと一致すると、レジスタ１４の８ビット目
（ＡＲＰ：Address Resolusion Protocol ）が「１」に
セットされる。これは、受信フレームがＡＲＰ形式のフ
レームであると識別されたことを意味する。また、ラッ
チ回路２３のデータが領域２７ｆのデータと一致する
と、レジスタ１４の７ビット目（ＸＮＳ：Xerox Networ
k System）が「１」にセットされる。これは、受信フレ
ームがゼロックス社のネットワーク形式のフレームであ
ると識別されたことを意味する。

【００２５】次に、レジスタ２７は、ラッチ回路２３の
データが領域２７ｈのデータと一致すると、領域２７ｈ
の出力を「１」にセットするが、このときレジスタ１４
の６ビット目（ＯＳＩ：Open Systems Interconnectio
n）が「１」にセットされるのは、バッファ３０がイネ
ーブル状態になったときである。バッファ３０がイネー
ブル状態になるためには、ラッチ回路２４で保持された
データがレジスタ２８の領域２８ａに格納されたデータ
パターンと一致することが必要となる。このような一致
が成立すれば、イネーブル信号（「１」）がレジスタ２
８から出力され、バッファ３０がイネーブル状態とな
る。

【００２６】よって、以上の２つの条件が成立すれば、
レジスタ１４の６ビット目が「１」にセットされ、受信
フレームがＯＳＩプロトコル形式のフレームであると識
別されたことになる。

【００２７】また、ラッチ回路２３のデータが領域２７
ｉのデータと一致すると、領域２７ｉの出力が「１」に
セットされるが、このときレジスタ１４の１１ビット目
（ＩＰＸ）が「１」にセットされるのは、上記と同条件
の成立によりバッファ３１がイネーブル状態になったと
きである。以上の２つの条件が成立すれば、レジスタ１
４の１１ビット目が「１」にセットされ、受信フレーム
がＩＰＸプロトコル形式のフレームであると識別された
ことになる。

【００２８】また、ラッチ回路２３のデータが領域２７
ｊのデータと一致すると、領域２７ｊの出力が「１」に
セットされるが、このときレジスタ１４の５ビット目
（ＳＴＰ：Spanning Tree Protocol）が「１」にセット
されるのは、上記と同条件の成立によりバッファ３２が
イネーブル状態になったときである。以上の２つの条件
が成立すれば、レジスタ１４の５ビット目が「１」にセ
ットされる。これは、受信フレームがＳＴＰ形式のフレ
ームであると識別されたことを意味する。

【００２９】そして、レジスタ２８は、ラッチ回路２４
のデータが領域２８ｃ又は２８ｄのデータと一致する
と、レジスタ１４の４ビット目（ＸＩＤ：Exchange Ide
ntification ）を「１」にセットする。これは、受信フ
レームがＬＬＣ形式のフレームであると識別されたこと
を意味する。同様に、ラッチ回路２４のデータが領域２
８ｅ又は２８ｆのデータと一致すると、レジスタ１４の
３ビット目（ＴＥＳＴ）を「１」にセットする。これ
は、受信フレームがＬＬＣ形式のフレームであると識別
されたことを意味する。

【００３０】次に、レジスタ２９は、ラッチ回路２５に
よって保持されたデータが領域２９ａに格納されたデー
タと一致すると、領域２９ａの出力を「１」にセットす
るが、このときレジスタ１４の１１ビット目（ＩＰＸ）
が「１」にセットされるのは、バッファ３３がイネーブ
ル状態になったときである。

【００３１】バッファ３３がイネーブル状態になるため
には、ラッチ回路２３のデータがレジスタ２７の領域２
７ｋのデータと一致し、かつラッチ回路２４のデータが
レジスタ２８の領域２８ｂのデータと一致することが必
要となる。このような一致により、イネーブル信号がレ
ジスタ２７と２８から出力され、アンド回路３６の出力
が「１」となり、バッファ３３がイネーブル状態とな
る。よって、以上の条件が成立すれば、レジスタ１４の
１１ビット目が「１」にセットされ、受信フレームがＩ
ＰＸプロトコル形式のフレームであると識別されたこと
になる。

【００３２】また、ラッチ回路２５のデータが領域２９
ｂのデータと一致すると、領域２９ｂの出力が「１」に
セットされるが、このときレジスタ１４の２ビット目
（Ａｐｐｌｅ）が「１」にセットされるのは、上記と同
条件の成立によりバッファ３４がイネーブル状態になっ
たときである。以上の２つの条件が成立すれば、レジス
タ１４の２ビット目が「１」にセットされ、受信フレー
ムがアップル社のネットワーク形式のフレームであると
識別されたことになる。

【００３３】同様に、ラッチ回路２５のデータが領域２
９ｃのデータと一致すると、領域２９ｃの出力が「１」
にセットされるが、このときレジスタ１４の１ビット目
（Ａｐｐｌｅ ＡＲＰ）が「１」にセットされるのは、
上記と同条件の成立によりバッファ３５がイネーブル状
態になったときである。以上の２つの条件が成立すれ
ば、レジスタ１４の１ビット目が「１」にセットされ、
受信フレームがアップル社のネットワーク形式のフレー
ムであると識別されたことになる。

【００３４】以上で説明したフレーム種別の識別は、各
プロトコル形式に予め割り当てられたヘッダ情報中のデ
ータパターンをレジスタ２７〜２９に記憶させて、これ
を受信フレームのヘッダ情報と比較することにより、識
別を行うものである。このような識別により、レジスタ
１４の各ビットのうち、該当するビットが「１」にセッ
トされる。

【００３５】次に、アドレスジェネレータ１５は、レジ
スタ１４の情報をメモリ２に書き込まれるフレームデー
タＤ１と対応づけてメモリ２に書き込めるように、書き
込みアドレスＡ１に応じた書き込みアドレスＡ２を生成
する。こうして、比較結果保持レジスタ１４に保持され
た１６ビットの識別情報Ｄ２（有意ビットは下位１２ビ
ット）が書き込みアドレスＡ２によってメモリ２の所定
の領域２ｂに書き込まれる。

【００３６】このように受信フレームの種別が得られる
と、図示しないファームウエアがこれを基にメモリ２に
格納されたフレームを処理することが可能になる。例え
ば、ファームウェアがフレーム種別を基に、この受信フ
レームの転送先を求め、これをフレーム転送処理部４に
渡す、これにより、フレーム転送処理部４は、この転送
先情報に従ってメモリ２に格納された受信フレームを該
当する送信側ネットワークインタフェース部へ転送す
る。

【００３７】実施の形態の２．次に、ネットワークレイ
ヤにおける宛先論理アドレスを用いて、宛先論理アドレ
スから転送先を検索するプロトコル処理（ルーティング
処理）の場合について説明する。本実施の形態において
も、受信側ネットワークインタフェース部全体の構成
は、実施の形態の１とほぼ同様であり、異なるのはパラ
レルプロトコル処理部なので、このパラレルプロトコル
処理部の構成、動作を説明する。

【００３８】図５は本発明の他の実施の形態となる高速
処理方式を示すパラレルプロトコル処理部のブロック図
であり、図２と同様の構成には同一の符号を付してあ
る。まず、アドレスデコーダ１１は、実施の形態の１と
同様にフレーム書き込み開始タイミングを検出し、ラッ
チパルス生成部１２ａは、ラッチパルス生成部１２と同
様にしてタイミングパルスＴ１〜Ｔ６を生成する。

【００３９】次に、ヘッダ比較部１３ａの内部構成は、
ヘッダ比較部１３と同様であるが、実施の形態１ではレ
ジスタ１４に書き込まれていた１１個の出力（Ｂｒｉｄ
ｇｅは使用せず）は、ネットワークレイヤの各プロトコ
ルごとに独立して処理を行う後述するルーティング処理
部のイネーブル信号として使用される。

【００４０】ルーティング処理部１６−１〜１６−ｎ
は、各プロトコル形式ごとに設けられるものである。し
たがって、実施の形態の１のようにフレーム種別がＩＰ
ＸからＡｐｐｌｅ ＡＲＰまでの１１種類あって、これ
に対して１つずつ設けるとすれば、その個数は１１個と
なる。そして、ヘッダ比較部１３ａからの各イネーブル
信号は、そのフレームプロトコルに対応するルーティン
グ処理部に接続されており、イネーブル信号が「１」に
なるとルーティング処理部が起動される。

【００４１】ここでは、ネットワークレイヤにおける宛
先論理アドレスの１例としてＩＰアドレスにおけるネッ
トワークアドレスを用いたＩＰルーティング処理につい
て説明する。図６はルーティング処理部１６−１〜１６
−ｎ中のフレーム種別（プロトコル）ＩＰに対応したル
ーティング処理部のブロック図である。

【００４２】シフトレジスタ３１は、ラッチパルス生成
部１２ａより出力されたフレーム書き込み開始タイミン
グから所定の時間だけフレームデータＤ１を遅らせて、
これをフレームデータＤ３として出力する。この所定の
時間は、ヘッダ比較部１３ａにフレームデータＤ１の先
頭が入力されてからビット「１」のイネーブル信号ＩＰ
ｅｎａ（図４のＩＰ）が出力されるまでの時間である。

【００４３】こうして、フレームデータＤ３の先頭とイ
ネーブル信号ＩＰｅｎａのタイミングが一致することに
なる。そして、バッファ３２は、受信フレームがＩＰ形
式のフレームと判断されてイネーブル信号ＩＰｅｎａが
「１」になると、イネーブル状態となり、入力されたフ
レームデータＤ３とこのデータＤ３に同期したクロック
信号ＣＬＫをヘッダラッチ部３３に出力する。

【００４４】次に、ヘッダラッチ部３３は、クロック信
号ＣＬＫに基づいてフレームデータＤ３中の宛先ＩＰア
ドレスをラッチする。宛先ＩＰアドレスがフレームデー
タＤ３中のどの位置に格納されているかは予め分かって
おり、これにより宛先ＩＰアドレスを取り出すことがで
きる。

【００４５】続いて、アドレスクラス識別部３４は、ヘ
ッダラッチ部３３で保持された宛先ＩＰアドレスの上位
２ビットからネットワーククラス（Ａ、ＢあるいはＣ）
を調べ、そのクラスに応じてアドレスマスクレジスタ３
５の値をアサートする。すなわち、クラスＡであれば、
ＩＰアドレスの上位８ビットがネットワークアドレスな
ので、宛先ＩＰアドレスのうちのこの部分をビット
「１」にセットし、その他の部分は「０」とする。

【００４６】また、クラスＢであれば、上位１６ビット
がネットワークアドレスであり、クラスＣであれば、上
位２４ビットがネットワークアドレスなので、同様にこ
の部分をビット「１」にセットする。そして、ＡＮＤ回
路３６は、このようなアドレスマスクレジスタ３５の出
力値とヘッダラッチ部３３で保持された宛先ＩＰアドレ
スの論理積をとる。こうして、宛先ＩＰアドレスにおけ
るネットワークアドレスが得られる。

【００４７】次に、ＩＰルーティングテーブル３７に
は、ネットワークアドレスＩＰ１〜ＩＰｎと、そのネッ
トワークアドレスに対応した送信側ネットワークインタ
フェース部（図８の５５ａ〜５５ｃに相当）の番号Ｎ１
〜Ｎｎとの対応関係が格納されている。このＩＰルーテ
ィングテーブル３７は、ＡＮＤ回路３６で得られたネッ
トワークアドレスをキーとして検索を行う。

【００４８】そして、ネットワークアドレスＩＰ１〜Ｉ
Ｐｎ中にキーと一致するアドレスがあれば、それに対応
する送信側ネットワークインタフェース部の番号を出力
する。これが、転送先情報Ｄ４である。一方、アドレス
ジェネレータ３８は、アドレスジェネレータ１５と同様
に書き込みアドレスＡ１に応じた書き込みアドレスＡ２
を生成する。

【００４９】こうして、本実施の形態のパラレルプロト
コル処理部から出力された転送先情報Ｄ４が書き込みア
ドレスＡ２によってメモリの所定の領域（図１の領域２
ｂに相当）に書き込まれる。そして、フレーム転送処理
部（図１の処理部４）は、この転送先情報Ｄ４に従って
メモリに格納された受信フレームを該当する送信側ネッ
トワークインタフェース部へ転送する。

【００５０】実施の形態の３．次に、物理伝送路に対応
した宛先物理アドレスを用いて、このアドレスから転送
先を検索するプロトコル処理（スイッチング処理）の場
合について説明する。本実施の形態においても、受信側
ネットワークインタフェース部全体の構成は、実施の形
態の１とほぼ同様であり、異なるのはパラレルプロトコ
ル処理部なので、このパラレルプロトコル処理部の構
成、動作を説明する。図７は本発明の他の実施の形態と
なる高速処理方式を示すパラレルプロトコル処理部のブ
ロック図であり、図２と同様の構成には同一の符号を付
してある。

【００５１】そして、ここでは宛先物理アドレスとして
宛先ＭＡＣアドレスを対象にしたものを説明する。ま
ず、アドレスデコーダ１１は、実施の形態の１と同様に
フレーム書き込み開始タイミングを検出し、ラッチパル
ス生成部１２ｂは、上述したタイミングパルスＴ１〜Ｔ
６のうち、パルスＴ１、Ｔ２を生成する。

【００５２】ヘッダラッチ部１７は、タイミングパルス
Ｔ１、Ｔ２によってフレームデータＤ１中の宛先ＭＡＣ
アドレス（図３の１０１）をラッチする。次に、スイッ
チングテーブル１８には、宛先ＭＡＣアドレスＭＡ１〜
ＭＡｎと、そのＭＡＣアドレスをもった端末が存在する
物理伝送路に接続された送信側ネットワークインタフェ
ース部の番号Ｎ１〜Ｎｎとの対応関係が格納されてい
る。

【００５３】このスイッチングテーブル１８は、ヘッダ
ラッチ部１７によって保持された宛先ＭＡＣアドレスを
キーとして検索を行う。そして、宛先ＭＡＣアドレスＭ
Ａ１〜ＭＡｎ中にキーと一致するアドレスがあれば、そ
れに対応する送信側ネットワークインタフェース部の番
号を出力する。これが、転送先情報Ｄ５である。

【００５４】一方、アドレスジェネレータ１９は、アド
レスジェネレータ１５と同様に書き込みアドレスＡ１に
応じた書き込みアドレスＡ２を生成する。こうして、本
実施の形態のパラレルプロトコル処理部から出力された
転送先情報Ｄ５が書き込みアドレスＡ２によってメモリ
の所定の領域（図１の領域２ｂに相当）に書き込まれ
る。そして、フレーム転送処理部（図１の処理部４）
は、この転送先情報Ｄ５に従ってメモリに格納された受
信フレームを該当する送信側ネットワークインタフェー
ス部へ転送する。

【００５５】なお、フレーム変換やセキュリティー機
能、あるいは課金処理などトランスポート層（第４層）
以上の機能を有する中継装置のみをゲートウェイ装置
（ここでは、狭義のゲートウェイ装置とする）と呼ぶ場
合もあるが、本発明は、ネットワーク間を接続する広義
のゲートウェイ装置に適用することができる。すなわ
ち、データリンク層（第２層）で動作するブリッジ（実
施の形態の３におけるゲートウェイ装置に相当）、ネッ
トワーク層（第３層）以下で動作するルータ（実施の形
態の１、２におけるゲートウェイ装置に相当）、あるい
はこれらを合わせたブルータ等のネットワーク中継装置
に適用でき、上述した狭義のゲートウェイ装置に限らな
いことは言うまでもない。

【００５６】

【発明の効果】本発明によれば、ネットワークコントロ
ーラ部が受信フレームをメモリに書き込むフレーム受信
処理と平行してプロトコル処理を行うことにより、メモ
リへの受信フレームの書き込み終了を待たずにプロトコ
ル処理を起動することができ、パラレルプロトコル処理
部（ハードウェア）でプロトコル処理を行うことによ
り、メモリへの受信フレームの書き込み終了時にはプロ
トコル処理が終了しているため、すぐにフレーム転送を
実行することができる。これにより、受信側ネットワー
クインタフェース部における全体の処理時間を短縮し、
フレーム転送処理の高速化を図ることができる。

【００５７】また、パラレルプロトコル処理部が、受信
フレームのフレーム種別を識別し、この識別結果をメモ
リに書き込むことにより、フレーム受信処理とプロトコ
ル処理におけるフレーム識別処理とを同時に行うことが
でき、フレーム種別に応じた転送先の決定など次の処理
を行う手段へのフレーム転送をすぐに実行することがで
きる。

【００５８】また、パラレルプロトコル処理部が、受信
フレームのフレーム種別を識別し、宛先論理アドレスに
対応した転送先を求め、求めた転送先情報をメモリに書
き込むことにより、フレーム受信処理とプロトコル処理
におけるフレーム識別処理及びルーティング処理とを同
時に行うことができ、メモリへの受信フレームの書き込
み終了時には転送先が決定しているため、送信側ネット
ワークインタフェース部へのフレーム転送をすぐに実行
することができる。

【００５９】また、パラレルプロトコル処理部が、宛先
物理アドレスに対応した転送先を求め、求めた転送先情
報をメモリに書き込むことにより、フレーム受信処理と
プロトコル処理におけるスイッチング処理とを同時に行
うことができ、メモリへの受信フレームの書き込み終了
時には転送先が決定しているため、送信側ネットワーク
インタフェース部へのフレーム転送をすぐに実行するこ
とができる。

【図面の簡単な説明】

【図１】 本発明の第１の実施の形態となる高速処理方
式を示す受信側ネットワークインタフェース部のブロッ
ク図である。

【図２】 図１のパラレルプロトコル処理部のブロック
図である。

【図３】 図２のラッチパルス生成部が生成するタイミ
ングパルスとヘッダ情報の関係を示すタイミングチャー
ト図である。

【図４】 図２のヘッダ比較部のブロック図である。

【図５】 本発明の他の実施の形態となる高速処理方式
を示すパラレルプロトコル処理部のブロック図である。

【図６】 フレーム種別ＩＰに対応したルーティング処
理部のブロック図である。

【図７】 本発明の他の実施の形態となる高速処理方式
を示すパラレルプロトコル処理部のブロック図である。

【図８】 従来の受信側ネットワークインタフェース部
のブロック図である。

【符号の説明】

１…ネットワークコントローラ部、２…メモリ、３…パ
ラレルプロトコル処理部、４…フレーム転送処理部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 黒川 康司 東京都港区虎ノ門５丁目２番６号 株式 会社超高速ネットワーク・コンピュータ 技術研究所内 (56)参考文献 特開 昭62−164335（ＪＰ，Ａ) 特開 平１−101752（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁶，ＤＢ名) H01L 12/28 H01L 29/06

Claims (4)

(57)【特許請求の範囲】
1. 【請求項１】 物理伝送路からフレームを受信するネッ
   トワークコントローラ部と、このコントローラ部で受信
   された受信フレームを格納するメモリとを有するゲート
   ウェイ装置の受信側ネットワークインタフェース部にお
   いて、 ネットワークコントローラ部が受信フレームをメモリに
   書き込むフレーム受信処理と平行して、ネットワークコ
   ントローラ部から受信フレームを取り込み、受信フレー
   ムのプロトコル処理をハードウェアで行い、このプロト
   コル処理の結果を受信フレームと対応させて前記メモリ
   に書き込むパラレルプロトコル処理部を有することを特
   徴とする受信フレームに対する高速処理方式。
2. 【請求項２】 請求項１に記載の受信フレームに対する
   高速処理方式において、 前記パラレルプロトコル処理部は、受信フレームのフレ
   ーム種別を識別し、この識別結果を受信フレームと対応
   させてメモリに書き込むものであり、フレーム受信処理
   とプロトコル処理におけるフレーム識別処理とを同時に
   行うことを特徴とする受信フレームに対する高速処理方
   式。
3. 【請求項３】 請求項１に記載の受信フレームに対する
   高速処理方式において、 前記パラレルプロトコル処理部は、受信フレームのフレ
   ーム種別を識別するヘッダ比較部と、前記フレーム種別
   ごとに設けられ、受信フレーム中のネットワークレイヤ
   における宛先論理アドレスを基に、これに対応した転送
   先を求めることを前記フレーム種別に応じて行い、求め
   た転送先情報を受信フレームと対応させてメモリに書き
   込む１つ又は複数のルーティング処理部とを備えるもの
   であり、フレーム受信処理とプロトコル処理におけるフ
   レーム識別処理及びルーティング処理とを同時に行うこ
   とを特徴とする受信フレームに対する高速処理方式。
4. 【請求項４】 請求項１に記載の受信フレームに対する
   高速処理方式において、 前記パラレルプロトコル処理部は、受信フレーム中の物
   理伝送路に応じた宛先物理アドレスをラッチするヘッダ
   ラッチ部と、宛先物理アドレスと転送先との対応関係を
   格納し、ヘッダラッチ部によって保持された宛先物理ア
   ドレスを基に、これに対応した転送先を求め、求めた転
   送先情報を受信フレームと対応させてメモリに書き込む
   スイッチングテーブルとを備えるものであり、フレーム
   受信処理とプロトコル処理におけるスイッチング処理と
   を同時に行うことを特徴とする受信フレームに対する高
   速処理方式。