JP2002057698A

JP2002057698A - パケットデータ処理装置

Info

Publication number: JP2002057698A
Application number: JP2000240829A
Authority: JP
Inventors: Satoshi Soejima; 聡史副島; Yuji Kojima; 祐治小島; Yasuyuki Umezaki; 康之梅崎; Yoshitomo Shimozono; 善知下園; Tetsuaki Tsuruoka; 哲明鶴岡
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-08-09
Filing date: 2000-08-09
Publication date: 2002-02-22
Also published as: US20020019882A1; US6654823B2

Abstract

(57)【要約】【課題】速度が低下することなくパケットを処理する
ことのできるパケットデータ処理装置を提供する。【解決手段】入力されるパケットのパケットデータに
対して演算処理をするパケットデータ装置において、演
算処理回数に係わる演算情報を算出する第１データ処理
部と、メモリと、パケットデータに対して演算処理をし
て第１演算結果をメモリに書き込む第２データ処理部
と、読み出し要求に基づいてメモリに最も以前に書き込
まれた第１演算結果を読み出し、読み出した第１演算結
果をメモリから削除するアクセス機構部と、パケットが
入力されると読み出し要求を行い、第１演算結果及びパ
ケットに基づいて処理をする第３データ処理部と、最大
パケットが第３データ処理部に入力されたとき、このパ
ケットについてのメモリへの書き込みが終了しているよ
うに遅延させる遅延部とを具備して構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、パケットデータ処
理装置に関し、特に、可変長のパケットのパイプライン
演算処理による高速化に関する。

【０００２】

【従来の技術】ＩＰ(Internet Protocol)ネットワーク
間の中継を行うネットワークノードでは、パケット内の
ヘッダ書き換え処理や装置内に具備する宛先テーブルを
検索しルーディングを行うといったようなパケット処理
を行っている。近年のインターネットの高速化に伴い、
パケットの中継を行うネットワークノードではパケット
処理を高速に行うことが必要となっている。そのため、
このようなネットワークノードでは、パケット処理を専
用のハードウェアで行うことによりパケット処理の高速
化を図っている。

【０００３】従来のパケット処理にはストアアンドフォ
ワードによる構成がある。この構成では、パケット処理
部（プロセッサ又は専用ハードウェア）とメモリをバス
によって接続し、パケット処理部がパケット処理を行
う。具体的には、受信パケットを一時的にメモリへ格納
し、パケット処理部によってパケット処理を受信パケッ
トに対して行った後に、決定した宛先情報等の情報と共
にスイッチ・ファブリックへパケットを送信するといっ
た処理を行う。スイッチ・ファブリックによって宛先情
報から宛先テーブルが参照されて、宛先情報に該当する
出方路に送出される。

【０００４】また、ネットワークノードがＩＰ及びその
下位層のプロトコルを処理するにあたっては各プロトコ
ルヘッダ内のある情報を元に処理を行い、ＩＰのデータ
部にある情報を必要とすることは殆どない。そこで、高
速処理のため、処理対象が各プロトコルのヘッダだけで
あるといった局所性に注目して固定の処理数で演算を行
うようなプロセッサ構成をもったパケットデータ処理プ
ロセッサも考えられる。このような処理系でパケットを
処理することは処理がＩＰ層までしか及ばない等、パケ
ット処理に局所性があるときは高速に処理を行うことが
できる。

【０００５】一方、ネットワークノードにおける処理の
多機能化の必要性が高まっており、そのような処理によ
ってはＩＰ層より上位のプロトコルを処理しなければな
らない処理も存在する。例えば、インターネットなどの
共有ネットワークをプライベートなネットワークとして
利用者が共有ネットワークを意識しないで利用できるＶ
ＰＮ(Virtual Private Network)と呼ばれる技術が浸透
してきているが、このようなＶＰＮの技術の中にはトン
ネリング処理を行うプロトコルがある。

【０００６】トリンネリング処理とは、遠隔地にある２
つのプライベートなネットワーク間の通信をインターネ
ットなどの共有ネットワークを経由して使用する時に使
われる。具体的には、プライベートなネットワークから
送信されたパケットがＶＰＮ対応のネットワークノード
によって共有ネットワーク用のヘッダを付加され（カプ
セル化処理）、インターネットなどの共有ネットワーク
を使用して相手のＶＰＮ対応のネットワークノードまで
送信する。そして、そのパケットを受信するもう１つの
プライベートネットワークにあるＶＰＮ対応のネットワ
ークノードはカプセル化の時に付加されたヘッダを削除
し（デカプセル処理）、カプセル化される前のパケット
をもう１つのプライベートなネットワークに送信すると
いった動作を行う。

【０００７】例えば、トンネリング処理の必要なプロト
コルであるＬ２ＴＰでは、ＰＰＰパケットをＬ２ＴＰ、
ＵＤＰ、ＩＰの各ヘッダを付加・削除することによりト
ンネリング処理を行っている。そのため、Ｌ２ＴＰのカ
プセル処理・デカプセル処理を行うＶＰＮ対応のネット
ワークノードではこれらのヘッダの付加・削除操作が行
われないといけない。

【０００８】

【発明が解決しようとする課題】しかしながら、従来の
ストアアンドフォワードによるパケット処理では、パケ
ットデータを一時的に格納するメモリへの読み込み・書
き込み処理が必要なため、パケット処理の高速化が難し
いという問題点があった。パケット全体を一度メモリに
蓄積するストアアンドフォワード処理では、パケット全
体を処理対象とすることができるので、どのような処理
にも対応することができる。しかし、プロセッサはプロ
セッサが書き込むメモリのアドレスをメモリに与えてか
ら、メモリからデータを読み込み、同様にプロセッサは
プロセッサが書き込むメモリのアドトレスをメモリに与
えてから、メモリへ書き込むという処理を行うことにな
る。

【０００９】このとき、プロセッサがアドレスをメモリ
へ与えてから、プロセッサがデータをメモリから読み込
み・書き込みを行う時間はプロセッサのサイクルタイム
よりも大きい。これは、プロセッサだけでなく専用のパ
ケット処理ハードウェアで実行しても同様である。この
メモリへの読み込み・書き込み処理のオーバヘッドが問
題となり、パケット処理を高速に行うことができなくな
る。

【００１０】パケット処理の局所性に注目して処理を行
うパケットデータ処理方式では、ＩＰ層以下の処理を高
速に行うことができた。しかし、この処理方式では、パ
ケット処理プロセッサが繰り返し同じ命令を実行するこ
とが可能で繰り返し加算を行えたとしても、ＵＤＰのチ
ェックサム計算結果をヘッダに格納するのは困難であ
る。ＵＤＰのチェックサムの計算はＵＤＰデータ部の値
の全てを使用するので計算終了までの回数がパケット長
に依存することになるからである。

【００１１】故に、チェックサムの計算結果をＵＤＰヘ
ッダに格納しようとした場合、チェックサム計算に要す
る時間がパケット長により異なるため、チェックサム計
算が終わったときのＵＤＰチェックサムを格納すべきレ
ジスタはパケット毎に変わってしまい、それに対応する
ようなパケットデータ処理プロセッサ用の命令を記述す
ることは不可能である。

【００１２】また、計算結果をパイプライン結合された
各パケット処理プロセッサが共通にアクセスすることの
できるレジスタに保存し、これを後段のパケット処理プ
ロセッサが取り出す方法を取ったとする。このレジスタ
の値を取り出すことのできるパケット処理プロセッサは
サポートしているパケットの中で最も長いパケットの処
理が終わったときにＵＤＰヘッダのチェックサムを格納
するフィールドが存在する先頭のパケットデータ処理プ
ロセッサ以降である。しかし、このレジスタの値は次に
入ってくるパケットの処理結果が書き込まれるまでしか
存在できず、そのためパケットデータ処理プロセッサが
データを受け取ろうとした場合、上書きされた他のパケ
ットの計算結果をレジスタから受け取ってしまう可能性
がある。

【００１３】従って、ＵＤＰチェックサムの計算結果が
必要なパケット処理をパケットデータプロセッサを用い
て行うときには、パケットデータ処理プロセッサの処理
が終了後に一般的なプロセッサにパケットを渡してソフ
トウェアににるＵＤＰチェックサムの計算を行わなけれ
ばならない。このようにソフトウェアによるＵＤＰチェ
ックサムの計算を行わざるを得ない処理はＵＤＰのヘッ
ダのチェックサムに限らず、パケット長によって存在フ
ィールドが変動するようなデータを演算対象に指定した
いときは一般的なプロセッサによるソフトウェア処理で
対処するしかなかった。しかし、この方法では、パケッ
トデータ処理プロセッサで処理をした後、さらに一般的
なプロセッサで処理を行うためどうしても余計な時間が
かかってしまい、パケット処理を高速に行うことができ
なくなる。

【００１４】本発明の目的は、速度が低下することなく
パケットを処理することのできるパケットデータ処理装
置を提供することである。

【００１５】

【課題を解決するための手段】本発明の一側面によれ
ば、入力されるパケットのパケットデータに対して演算
処理をするパケットデータ装置であって、前記パケット
のパケット長に基づいて演算処理回数に係わる演算情報
を算出し、該演算情報を出力する第１データ処理部と、
メモリと、前記演算情報に従って順次入力される前記パ
ケットのパケットデータに対して演算処理をして、前記
パケットについてのパケットデータに対する演算が終了
すると第１演算結果を前記メモリに書き込む第２データ
処理部と、読み出し要求に基づいて前記メモリに最も以
前に書き込まれた演算結果を読み出し、読み出した第１
演算結果を前記メモリから削除するアクセス機構部と、
前記パケットが入力されると前記読み出し要求を行い、
前記アクセス機構部より読み出された第１演算結果及び
前記パケットに基づいて処理をする第３データ処理部
と、最大パケット長のパケットの所定位置のパケットデ
ータが前記第３データ処理部に入力されたとき、該パケ
ットについてのパケットデータに対する第１演算結果の
前記メモリへの書き込みが終了しているように前記パケ
ットの前記第３データ処理部への入力を遅延させる遅延
部とを具備する。そして、前記メモリは、前記第３デー
タ処理部にパケットの前記所定位置のパケットデータが
入力されたとき、該パケットに対する第１演算結果を保
持する容量を有することを特徴とするパケットデータ処
理装置が提供される。

【００１６】好ましくは、前記遅延部は前記第２〜第４
データ処理部にそれぞれ対応して設けられたシフトレジ
スタが縦続されたシフトレジスタ群で構成され、前記各
第２〜４データ処理部は、それぞれ対応して設けられた
前記シフトレジスタに格納される前記パケットに基づい
て処理をする。更に好ましくは、前記シフトレジスタ群
と並列に配置され、前記パケットに係る中間データを格
納する第２シフトレジスタ群を具備して構成する。

【００１７】

【発明の実施の形態】本発明の実施形態を説明する前に
本発明の原理を説明する。図１は本発明の原理図であ
る。図１に示すように、パケットデータ処理装置は、第
１データ処理部２、メモリ４、第２データ処理部６、ア
クセス機構部８、第３データ処理部１０及び遅延部１２
を具備する。

【００１８】第１データ処理部２は、パケットのパケッ
ト長に基づいて演算処理回数に係わる演算情報を算出し
て、該演算情報を出力する。第２データ処理部６は、演
算情報に従って、順次入力されるパケットのパケットデ
ータに対して演算処理をする。そして、パケットについ
てのパケットデータに対する演算が終了すると第１演算
結果をメモリ４に書き込む。第３データ処理部１０は、
パケットが入力されると、メモリ４からの読み出し要求
をアクセス機構部８に行う。

【００１９】アクセス機構部８は、読み出し要求に従っ
て、メモリ４から最も以前に書き込まれた第１演算結果
を読み出して、読み出した第１演算結果を第３データ処
理部１０に出力する。この第１演算結果が第３データ処
理部１０に入力されたパケットに対するものであること
が必要とされるが、最も以前にメモリ４に書き込まれた
パケットが読み出されること、読み出されたパケットが
メモリ４から削除されること、パケットに対する第１演
算結果がメモリ４から読み出されるまでは上書きされな
いこと、遅延部１２により最大パケット長のパケットが
第３データ処理部１０に入力されたとき、該パケットに
ついてのパケットデータに対する第１演算結果のメモリ
４への書き込みが終了しているようにパケットの第３デ
ータ処理部１０への入力を遅延させていることより、そ
のことが保証される。

【００２０】第３データ処理部１０は、アクセス機構部
８より読み出された第１演算結果及びパケットに基づい
て処理をする。このように可変長のパケットを演算対象
とするような場合において、パイプライン処理によりパ
ケットデータに対する演算処理を行うことができるの
で、高速にパケットを処理することができる。

【００２１】第１実施形態図２は本発明の第１実施形態によるＬ２ＴＰプロトコル
を使用したＶＰＮネットワークの構成及びパケットフォ
ーマットを示す図である。図２に示すように、ＶＰＮネ
ットワークは、リモートユーザ３０、ＬＡＣ(L2TP Acce
ss Concentrator)３２、インターネット網３４、ＬＮＳ
(L2TP Network Server)３６及プライベートネットワー
ク３８を含む。リモートユーザ３０は、ＩＰデータにＰ
ＰＰヘッダを付加（ＰＰＰカプセル化）して、ＬＡＣ３
２との間でＰＰＰセクションでパケットの送受信を行
う。

【００２２】ＬＡＣ３２は、複数のリモートユーザ３０
を収容し、以下の機能を有する。

【００２３】(1) リモートユーザ３０から送信された
ＰＰＰセクションのパケットを受信すると、Ｌ２ＴＰヘ
ッダ、ＵＤＰヘッダ、ＩＰヘッダ及びイーサネット（登
録商標）ヘッダを付加して（Ｌ２ＴＰカプセル化）、Ｉ
Ｐヘッダに設定したＩＰアドレスに該当する出方路のイ
ンターネット網３４に送信する。

【００２４】(2) インターネット網３４よりＬ２ＴＰ
カプセルパケットデータを受信すると、パケットデータ
に設定されている、ＩＰアドレスが自装置のＩＰアドレ
スであるか否かをチェックする。

【００２５】i) ＩＰアドレスが自装置のアドレスであ
れば、イーサネットヘッダ、ＩＰヘッダ、Ｌ２ＴＰヘッ
ダ及びＵＤＰヘッダを削除（Ｌ２ＴＰデカプセル化）し
て、ＩＰデータをそのＩＰアドレスに該当するリモート
ユーザ３０に送信する。

【００２６】ii) ＩＰアドレスが自装置のアドレスで
なければ、ＩＰアドレスに該当する出方路のインターネ
ット網３４に中継する。

【００２７】インターネット網３４は、ＴＣＰ／ＩＰプ
ロトコルに従って、ＩＰパケットを中継するネットワー
クである。ＬＮＳ３６は、複数のプライベートネットワ
ーク３８を収容し、以下の機能を有する。

【００２８】(1) プライベートネットワーク３８に収
容される端末から送信されたパケット（ＩＰデータにイ
ーサネットヘッダが付加されたパケット）を受信する
と、Ｌ２ＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダ及びＰ
ＰＰヘッダを付加して（Ｌ２ＴＰカプセル化）、イーサ
ネットヘッダに設定されたＭＡＣアドレスに該当する出
方路のインターネット網３４に送信する。

【００２９】(2) インターネット網３４よりパケット
データを受信すると、パケットデータに設定されている
ＩＰアドレスが自装置のＩＰアドレスであるか否かをチ
ェックする。

【００３０】i) ＩＰアドレスが自装置のアドレスであ
れば、ＩＰヘッダ、Ｌ２ＴＰヘッダ、ＵＤＰヘッダ及び
ＰＰＰヘッダを削除（Ｌ２ＴＰデカプセル化）して、送
信先アドレスに該当するプライベートネットワーク３８
に送信する。

【００３１】ii) ＩＰアドレスが自装置のアドレスで
なければ、ＩＰアドレスに該当する出方路のインターネ
ット網３４にパケットを中継する。

【００３２】本発明は、可変長データに対して、チェッ
クサム演算等の演算処理を実行する場合に適用可能であ
り、例えば、ＬＡＣ３２やＬＮＳ３６における、Ｌ２Ｔ
Ｐカプセル化でのＵＤＰヘッダに設定するチェックサム
の計算及びデカプセル化でのＵＤＰヘッダに設定された
Ｌ２ＴＰチェックサムの正当性チェックに適用可能であ
る。本実施形態では、ＬＮＳ３６のＬ２ＴＰカプセル化
及びＬ２ＴＰデカプセル化に適用した場合を例に説明す
る。

【００３３】図３は図２中のＬＮＳ３６の構成図であ
る。図３に示すように、ＬＮＳ３６は、複数の受信ＩＦ
部４２＃ｉ（ｉ＝１〜ｎ）、スイッチ・ファブリック５
０及び複数の送信ＩＦ部５２＃ｉ（ｉ＝１〜ｎ）を含
む。各受信ＩＦ部４２＃ｉは、伝送路よりパケットを受
信すると、Ｌ２ＴＰカプセル化又はＬ２ＴＰデカプセル
化をして、カプセル化又はデカプセル化したパケットを
ルーティング情報と共にスイッチ・ファブリック５０に
送信する。

【００３４】本実施形態では、受信ＩＦ部４２＃１がパ
ケットのカプセル化、受信ＩＦ部４２＃ｎがパケットの
デカプセル化を行う。その他の受信ＩＦ部４２＃ｉ（ｉ
＝２〜（ｎ−１））はＬ２ＴＰカプセル化又はＬ２ＴＰ
デカプセル化を行う。受信ＩＦ部４２＃ｉは、受信イン
タフェース部４４＃ｉ、前段処理部４６＃ｉ及びパケッ
ト処理部４８＃ｉを含む。受信インタフェース部４４＃
ｉは、伝送路からパケットを所定の物理インタフェース
に従って受信して、装置内の物理インタフェースに従っ
た信号に変換して、前段処理部４６＃ｉに出力する。

【００３５】図４はプライベートネットワーク３８との
間で送受信するパケットフォーマットを示す図である。
受信インタフェース部４４＃１が受信するパケットは、
図４に示すように、ＩＰデータにイサーネットヘッダが
付加されたものである。

【００３６】図５はインターネット網３４との間で送受
信するＬ２ＴＰカプセル化したパケットフォーマットを
示す図である。受信インタフェース部４４＃ｎが受信す
るパケットは、図５に示すようにＩＰデータ及びイーサ
ネットヘッダにＩＰヘッダ、ＵＤＰヘッダ、Ｌ２ＴＰヘ
ッダ及びＰＰＰヘッダが付加されたものである。

【００３７】前段処理部４６＃ｉは、図示しないクロッ
クに同期してパケットを受信すると、パケットの先頭を
示すフラグの生成、パケットのシリアル／パラレル変
換、例えば、３２ビットパラレルデータに変換する。そ
して、フラグ及びシリアル／パラレル変換したパケット
をパケット処理部４８＃ｉに出力する。

【００３８】図６は図３中のパケット処理部（Ｌ２ＴＰ
カプセル化部）４８＃１の構成図である。図６に示すよ
うに、Ｌ２ＴＰカプセル化部４８＃１は、前段のパケッ
トデータ処理プロセッサ６２＃１ｊ（ｊ＝１，…，
Ａ）、抽出加算器６４、中段のパケットデータ処理プロ
セッサ６６＃１ｊ（ｊ＝１，…，Ｃ，Ｂ）、後段のパケ
ットデータ処理プロセッサ６８＃１ｊ（ｊ＝１〜ｍ）、
ＦＩＦＯ７０及びアクセス機構部７２を含む。前段のパ
ケットデータ処理プロセッサ６２＃１ｊ（ｊ＝１，…，
Ａ）、抽出加算器６４、中段のパケットデータ処理プロ
セッサ６６＃１ｊ（ｊ＝１，…，Ｃ，Ｂ）及び後段のパ
ケットデータ処理プロセッサ６８＃１ｊ（ｊ＝１〜ｍ）
は、バス６３によりパイプライン構成されている。

【００３９】図７は図６中のパケットデータ処理プロセ
ッサの構成図である。パケットデータ処理プロセッサ６
２＃１ｊ（ｊ＝１，…，Ａ），６６＃１ｊ（ｊ＝１，
…，Ｃ，Ｂ）及び６８＃１ｊ（ｊ＝１〜ｍ）は、概略同
一構成である。図７に示すように、パケットデータ処理
プロセッサ６２＃１ｊ…は、パケットアクセスレジスタ
８０、中間データレジスタ８２、汎用レジスタ８４及び
演算器８６を有する。

【００４０】パケットアクセスレジスタ８０は図５に示
すＬ２ＴＰカプセル化パケットを格納するシフトレジス
タ（ｐ０〜ｐ１５）である。パケットアクセスレジスタ
８０の段数は、例えば、最小パケット長のパケットが格
納できるものとしている。パケット長に関係なく最小パ
ケット長までの固定長パケットデータをパケットアクセ
スレジスタ８０に格納して、パケットデータ処理プロセ
ッサ６２＃１ｊ等が処理可能とするためである。最小パ
ケット長を６４バイトとすると、パケットアクセスレジ
スタ８０の３２ビットレジスタの段数は１６（＝６４÷
４）段となる。

【００４１】中間データレジスタ８２は、パケットデー
タ処理プロセッサ６２＃１ｊ…で算出した中間データを
格納するシフトレジスタ（ｅ０〜ｅ１５）であり、パケ
ットアクセスレジスタ８０と同様の構成としている。パ
ケットアクセスレジスタ８０により転送されるパケット
データと中間データレジスタ８２により転送される中間
データとの同期を取るためである。汎用レジスタ８４
は、演算器８６が処理をするための汎用レジスタ（ｒ０
〜ｒ７）である。例えば、３２ビット長の８個のレジス
タから成る。演算器８６は、プログラムを実行すること
により処理をするプロセッサである。パケットアクセス
レジスタ８０及び中間レジスタ８２に格納されるパケッ
ト及び中間データは図示しない装置内クロックに同期し
てシフトされ、バス６３により転送される。

【００４２】前段のパケットデータ処理プロセッサ６２
＃１ｊ（ｊ＝１，…，Ａ）は、前段処理部４６＃１より
出力されるパケットからＬ２ＴＰカプセル化を行うため
のパケットの生成及び抽出加算器６４等が必要とする中
間データの生成等をするプロセッサである。そのプロセ
ッサの段数は後段の抽出加算器６４等が必要とする中間
データの種類等により決定される。その機能には、例え
ば、以下のものがある。

【００４３】(1) 図４に示すフォーマットのパケット
をクロックに同期して受信すると、パケットの送信先ア
ドレスよりＬ２ＴＰカプセル化に必要なパケットである
か否かを判断する。Ｌ２ＴＰカプセル化に必要なパケッ
トであるか否かは、例えば、プライベートネットワーク
３８から受信したパケットの送信先ＩＰアドレスが、テ
ーブルに登録されているＬ２ＴＰカプセル化が必要なＩ
Ｐアドレスだった場合、カプセル化処理を行うものと判
断する。

【００４４】i) Ｌ２ＴＰカプセル化に必要なパケット
のときａ）Ｌ２ＴＰカプセル化に必要なパケットであることを
示すフラグを中間データとして中間レジスタ８２により
転送する。

【００４５】ｂ）ＰＰＰヘッダの付加、Ｌ２ＴＰヘッダ
の付加、ＵＤＰヘッダの付加、ＩＰヘッダの付加及びイ
ーサネットヘッダの付加をして、図５に示すフォーマッ
トのパケットを生成する。付加するＩＰヘッダ等に設定
する送信先アドレスは、図４に示すパケットのイーサネ
ットヘッダ又はＩＰヘッダに設定されているアドレスに
該当する端末を収容するＬＡＣ等のＩＰアドレス等であ
り、送信先の端末のアドレス及びその端末を収容するＬ
ＡＣ等のパケット中継装置のＩＰアドレスを図示しない
テーブルに予め登録しておき、このテーブルを検索する
ことによりアドレスを取得する。

【００４６】また、ＵＤＰヘッダのチェックサムのフィ
ールドに０を補充する。パケットが処理単位バウンダリ
にならないときは、０を補充して処理単位バウンダリに
する。例えば、４バイトバウンダでなければ、パケット
の最後尾に０を補充して４バイトバウンダリにする。但
し、ＵＤＰヘッダのｌｅｎｇｔｈフィールドは、バウン
ダリ調整を行う前のパケット長とする。０を補充するの
は、０を加算してもチェックサムの計算結果に影響が無
いので、このチェックサムフィールドの値も加算するこ
とができ、チェックサムフィールドを判断して加算対象
から除外する必要がなく、チェックサム演算が複雑にな
らないからである。

【００４７】ｃ）パケットの所定位置（例えば、ＵＤＰ
ヘッダの先頭位置）を示すフラグを中間データとして中
間レジスタ８２により転送する。

【００４８】ii) Ｌ２ＴＰカプセル化が不要なパケッ
トのときａ）Ｌ２ＴＰカプセル化が不要なパケットであることを
示すフラグを中間データとして中間レジスタ８２により
転送する。

【００４９】ｂ）図４に示すパケットの所定位置（例え
ば、イーサネットヘッダの先頭位置）を示すフラグを中
間データとして中間レジスタ８２により転送する。尚、
このフラグが示すパケットの所定位置は、パケットデー
タ処理プロセッサ６２＃１ｊ（ｊ＝１，…，Ａ）、抽出
加算器６４等により、それを参照して処理をする後段に
位置するパケットデータ処理プロセッサ６６＃１ｊ等の
処理に合わせて、変更しても良い。

【００５０】(2) Ｌ２ＴＰカプセル化が必要なとき、
抽出加算器６４がチェックサムの計算を行うための計算
回数を算出する。例えば、計算回数は以下の様にして求
める。ＵＤＰヘッダのｌｅｎｇｔｈフィールドからＵＤ
Ｐデータ長を得る。その値はＵＤＰヘッダとＵＤＰデー
タ部を合わせたパケットの長さをバイト単位で表したも
のである。ＵＤＰデータ長にＩＰヘッダ長とイーサネッ
トヘッダ長を加算した値を抽出加算器５４の処理単位バ
イト数で乗算して、乗算結果に余りがあれば、乗算結果
に１加算する。例えば、処理単位バイト数を４バイトと
すると、ＵＤＰデータ長をレジスタに格納してから、２
ビット右にシフトさせて、キャリが生じたならばシフト
した結果に１加算する。尚、計算回数は、例えば、（Ｕ
ＤＰヘッダのｌｅｎｇｔｈフィールドの値÷４＋１（余
りがある場合））等の他の値であっても良く、抽出加算
器６４が累積演算できるものであれば良い。

【００５１】中間レジスタ８２に設定されるフラグによ
り、Ｌ２ＴＰカプセル化に必要なパケットであるか否か
を判断して、図５に示すパケットを生成する処理(1)
は、例えば、先頭のパケットデータ処理プロセッサ６２
＃１１が行う。抽出加算器６４が必要とする計算回数の
算出処理(2)は、例えば、パケットデータ処理プロセッ
サ６２＃１Ａが行って、抽出加算器用レジスタ（ＡＲレ
ジスタ）に格納する。ＡＲレジスタは、パケットデータ
処理プロセッサ６２＃１Ａに特別に設けられたレジスタ
であり、抽出加算器６４がよりアクセスが可能となって
いる。

【００５２】図８は図６中の抽出加算器６４の構成図で
ある。図８に示す抽出加算器６４は、専用ハードウェア
の構成を示す図であり、レジスタ９０、レジスタ９２、
制御部９４、カウンタ９６、累積加算器９７を有する。
レジスタ９０は、クロックに同期して、Ｌ２ＴＰカプセ
ル化の必要の有無を示すフラグ及びパケットの所定位置
を示すフラグ等の中間データを格納して、制御部９４及
びバス６３を通して次段のパケットデータ処理プロセッ
サ６６＃１１に出力する３２ビットレジスタである。レ
ジスタ９２は、クロックに同期してパケットを格納し
て、加算器１００及び次段のパケットデータ処理プロセ
ッサ６６＃１１に接続されるバス６３に出力する３２ビ
ットレジスタである。ここでは、レジスタ９０，９２は
１段構成としている。抽出加算器６４は、３２ビットを
処理単位として、１の補数の累積演算するからである。
抽出加算器６４は、図８の様に専用のハードウェアで実
現しても、プロセッサで実現してもよい。

【００５３】図９は抽出加算器６４の計算対象領域を示
す図である。チェックサムの計算対象領域は、ＵＤＰヘ
ッダの先頭からＩＰデータの最後までであるが、抽出加
算器６４は４バイトを処理単位とするので、図９に示す
ように、計算対象は４バイトバウンダリの先頭領域、即
ち、ＵＤＰヘッダの先頭から２バイト目（イーサネット
ヘッダの先頭から９バウンダ目）からＩＰデータを含む
４バイトデータまでとしている。制御部９４は、以下の
機能を有する。

【００５４】(1) レジスタ９０に格納されるＬ２ＴＰ
カプセル化の必要の有無を示すフラグを参照して、Ｌ２
ＴＰカプセル化が必要であるか否かを判断する。Ｌ２Ｔ
Ｐカプセル化の必要があれば、以下の処理(2)〜(7)を行
う。Ｌ２ＴＰカプセル化の必要が無ければ、当該パケッ
トに対する以下の処理(2)〜(7)をスキップする。

【００５５】(2) パケットの先頭が入力されると、計
算回数をパケットデータ処理プロセッサ６２＃１ＡのＡ
Ｒレジスタより読み出して、カウンタ９６に設定する。

【００５６】(3) 図示しないクロックに同期して、カ
ウンタ９６をデクリメントする。

【００５７】(4) パケットの先頭が入力されてから抽
出加算器６４の計算対象領域のデータが入力されるまで
は、加算結果格納レジスタ１０４をディセーブルにす
る。即ち、図９に示すように、パケットの先頭から９個
のデータが入力されている間は、加算結果格納レジスタ
１０４をディセーブルにする。

【００５８】(5) 抽出加算器６４の計算対象領域の先
頭データが入力されたとき、セレクタ９８に”０”を選
択するよう指示する選択信号を出力すると共に加算結果
格納レジスタ１０４をイネーブルにする。即ち、図９に
示すように、パケットの先頭から１０番目のデータが入
力されると、加算結果格納レジスタ１０４をイネーブル
にする。

【００５９】(6) 抽出加算器６４の計算対象領域の先
頭データ以降のデータが入力されると、セレクタ９８に
加算結果格納レジスタ１０４の出力を選択するよう指示
する選択信号を生成する。

【００６０】(7) 抽出加算器６４の計算対象領域の最
後のデータが入力されたとき、即ち、カウンタ９６が”
０”になると、ＦＩＦＯ７０に書き込みアドレスを出力
すると共に書き込み制御信号をイネーブルにして、加算
器１０２の出力をＦＩＦＯ７０に書き込む。

【００６１】カウンタ９６は、レジスタ９０，９２と同
一の装置内クロックに同期して、デクリメントする。累
積加算器９７は、セレクタ９８、加算器１００、加算器
１０２、加算結果格納レジスタ１０４を有する。加算器
１００，１０２は、１の補数和を算出するための演算回
路である。加算器１００は、レジスタ９２から４バイト
単位で出力されるパケットデータとセレクタ９８の出力
データを加算して、キャリ及び加算結果を加算器１０２
に出力する。加算器１０２は、加算器１００の加算結果
とキャリを加算して、ＦＩＦＯ７０及び加算結果格納レ
ジスタ１０４に出力する。加算結果格納レジスタ１０４
は、加算器１０２の加算結果を制御部９４から出力され
るイネーブル信号に従って格納して、セレクタ９８に出
力する。

【００６２】中間段のパケットデータ処理プロセッサ６
６＃１ｊ（ｊ＝１〜Ｃ）は、パケットデータ処理プロセ
ッサ６６＃１Ｂが処理を行うための前処理等を行うプロ
セッサ群である。これらのパケットデータ処理プロセッ
サ６６＃１ｊ（ｊ＝１〜Ｃ）は、パケットデータ処理プ
ロセッサ６６＃１Ｂのための前処理だけでなく、その他
の処理を行うことができる。パケットデータ処理プロセ
ッサ６６＃１Ｂにパケットの先頭が入力されたとき、パ
ケットデータ処理プロセッサ６６＃１Ｂがそのパケット
に対する加算結果をＦＩＦＯ７０より読み出すので、そ
のパケットに対する加算処理が抽出加算器６４で終了
し、その累積加算結果がＦＩＦＯ７０に書き込まれてい
る必要がある。

【００６３】サポートしているパケット（ＵＤＰヘッダ
長＋ＵＤＰデータ長）の最大長が１５１８バイトとする
と、抽出加算器６４が最大パケット長のパケットの演算
を終了するのは、１５１８÷４＝３８０クロックかか
る。そのとき、パケットの先頭にあるのは抽出加算器６
４から３８０÷１６（各パケットデータ処理プロセッサ
６６＃１ｊのパケットアクセスレジスタ８０の段数）＝
２４個先のパケットデータ処理プロセッサ６６＃１ｊ
（ｊ＝２４）である。そのため抽出加算器６４より２５
個以上先のパケットデータ処理プロセッサでしかチェッ
クサム演算の結果を演算に用いることができない。

【００６４】そこで、最も高速に処理可能とするべく、
抽出加算器６４から２５個先のパケットデータ処理プロ
セッサがチェックサム演算結果を使用するとし、このパ
ケットデータ処理プロセッサＢを６６＃１Ｂとしてい
る。従って、中間段のパケットデータ処理プロセッサ６
６＃１ｊ（ｊ＝１〜Ｃ）の段数は２４段である。

【００６５】尚、上記議論より分かるように、３８０段
以上の４バイトシフトレジスタとパケットデータ処理プ
ロセッサ６６＃１Ｂのための前処理等のように必須の処
理を行うパケットデータ処理プロセッサがあれば良く、
必ずしも、２４個以上の中段のパケットデータ処理プロ
セッサ６６＃１ｊ（ｊ＝１…）が必要であるという訳で
はない。しかし、新たな処理が必要となったとき、中段
のパケットデータ処理プロセッサ６６＃１ｊが多いと使
用していないパケットデータ処理プロセッサ６６＃１ｊ
に新たな処理を適宜割り当てることができるのでハード
ウェアを追加する必要が無いという利点がある。

【００６６】中段のパケットデータ処理プロセッサ６６
＃１ｊ（ｊ＝１…）は、パケットデータ処理プロセッサ
６６＃１Ｂでの処理のために以下の前処理を行う。

【００６７】(1) 中間レジスタ８２に格納されるＬ２
ＴＰカプセル化の必要の有無を示すフラグを参照して、
Ｌ２ＴＰカプセル化が必要であるか否かを判断する。Ｌ
２ＴＰカプセル化が必要であれば、以下の処理(2),(3)
を行う。Ｌ２ＴＰカプセル化が必要で無ければ、当該パ
ケットに対する以下の処理(2),(3)をスキップする。

【００６８】(2) 入力されたパケットより擬似ヘッダ
に設定される各フィールドを抽出する。

【００６９】図１０は擬似ヘッダのフォーマットを示す
図である。図１０に示すように、擬似ヘッダは、送信元
ＩＰアドレス、宛先ＩＰアドレス、ＵＤＰＬｅｎｇｔ
ｈ等である。送信元ＩＰアドレス及び宛先ＩＰアドレス
は、図５中のＩＰヘッダに設定されたものであり、送信
元ＩＰアドレスは自装置のＩＰアドレス、宛先ＩＰアド
レスは送信先の端末装置を収容するＬ２ＴＰをサポート
するＬＮＳやＬＡＣ等のパケット中継装置のアドレスで
ある。ＵＤＰＬｅｎｇｔｈは図５中のＵＤＰヘッダに
設定される値である。

【００７０】(3) 抽出加算器６４で演算対象となって
いない、擬似ヘッダとＵＤＰヘッダの最初の１６ビット
のデータに対して、１６ビット単位での１の補数和を求
めて、中間レジスタ８２に格納する。

【００７１】パケットデータ処理プロセッサ６６＃１Ｂ
は、以下の機能を有する。

【００７２】(1) 中間レジスタ８２に格納されるＬ２
ＴＰカプセル化の必要の有無を示すフラグを参照して、
Ｌ２ＴＰカプセル化が必要であるか否かを判断する。Ｌ
２ＴＰカプセル化が必要であれば、以下の処理(2)〜(5)
を行う。Ｌ２ＴＰカプセル化が必要で無ければ、当該パ
ケットに対する以下の処理(2)〜(5)をスキップする。

【００７３】(2) フラグにより指示されるパケットの
先頭（例えば、ＵＤＰヘッダの先頭）が入力されると、
アクセス機構部７２にＦＩＦＯ７０から値の読み出しを
要求する。

【００７４】(3) ＦＩＦＯ７０から得られた抽出加算
器６４での演算結果の上位１６ビットと下位１６ビット
で１６ビット単位で１の補数和を求める。

【００７５】(4) 擬似ヘッダとＵＤＰヘッダの先頭１
６ビットの１の補数和を中間レジスタ８２から取り出
し、(3)で求まった結果との間で１の補数和を求める。

【００７６】(5) (4)で求まった結果が最終的に求めよ
うとしていたＵＤＰチェックサムなので、その値をパケ
ットのＵＤＰヘッダのチェックサムフィールドに格納す
る。

【００７７】後段のパケットデータ処理プロセッサ６８
＃１ｊ（ｊ＝１〜ｍ）は、パケットのルーティング情報
等を求めて、中間レジスタ８２に格納等をする。ＦＩＦ
Ｏ(First In First Out)７０は、抽出加算器６４での計
算結果を蓄積するためのメモリである。尚、ＦＩＦＯ７
０は、抽出加算器６４での加算結果の書き込みとアクセ
ス機構部７２からの読み出しが同時に行うことができる
ようにデュアルポートラムで構成する。上述したように
最大の先頭パケットデータが抽出加算器６４から出力さ
れてからパケットデータ処理プロセッサ６６＃１Ｃに入
力されるまでに、３８０クロック要する。よって、この
３８０クロックの間に、６４バイトの最小のパケット
は、３８０÷１６＝２４個入力されるので、ＦＩＦＯ７
０は少なくとも２４個の計算結果を格納するメモリ領域
が必要となる。アクセス機構部７２は、パケットデータ
処理プロセッサ６６＃１Ｃから読み込み要求を受ける
と、ＦＩＦＯ７０に最も以前に書き込まれた先頭の値を
送信し、その後ＦＩＦＯ７０の中のデータの１つ前に詰
める。

【００７８】図１１は、図３中の受信ＩＦ部４２＃ｎ中
のデカプセル化部４８＃ｎの構成図であり、図４中の構
成要素と実質的に同一の構成要素には同一の符号を附し
ている。デカプセル化部４８＃ｎは、以下の機能を有す
る。

【００７９】(1) 入力されるパケットよりＬ２ＴＰデ
カプセル化が必要であるか否かを判別して、Ｌ２ＴＰデ
カプセル化が必要であるか否かを指示するフラグを中間
レジスタ８２に送信する。例えば、ＩＰ網３４から受信
したパケットの送信先ＩＰアドレスが自装置のアドレス
であり、そのパケットの中身がＬ２ＴＰパケットを含ん
でいた場合にＬ２ＴＰデカプセル化必要有りと判断す
る。この判断の詳しい手順は、１．送信先ＩＰアドレスが自アドレスの時、ＩＰヘッダ
内にある上位プロトコルを示すフィールドがＵＤＰであ
るかどうか判定する。

【００８０】２．ＵＤＰであった場合、ＵＤＰヘッダ内
にある宛先ポート番号がＬ２ＴＰであるかどうかを判断
する。という判定を行う。

【００８１】(2) 中間レジスタ８２に格納されるＬ２
ＴＰデカプセル化の必要の有無を示すフラグを参照し
て、Ｌ２ＴＰデカプセル化が必要であるか否かを判断す
る。Ｌ２ＴＰデカプセル化が必要であれば、以下の処理
(3)〜(7)を行う。Ｌ２ＴＰデカプセル化が必要無けれ
ば、当該パケットに対する以下の処理(2)〜(6)をスキッ
プして、(7)の処理をする。

【００８２】(3) インターネット網３４より受信した
Ｌ２ＴＰパケットのＵＤＰヘッダ、ＵＤＰデータ及び擬
似ヘッダの１の補数和を算出する。

【００８３】(4) (3)で算出した１の補数和がＵＤＰチ
ェックサムフィールドに設定されていた値に等しいか否
かをチェックして、チェックサムフィールド値が正しい
か否かを判定する。

【００８４】(5) チェックサムフィールド値が正しく
なければ、パケットを廃棄する。

【００８５】(6) チェックサムフィールド値が正しけ
れば、パケットをデカプセル化する。

【００８６】(7) ルーティング情報を生成する。

【００８７】(3)については、カプセル化部４８＃１と
実質的に同様であり、抽出加算器６４及びパケットデー
タ処理プロセッサ６６＃ｎｊ（ｊ＝１，…，Ｃ，Ｂ）が
行う。(3)の前処理として、前段のパケットデータ処理
プロセッサ６２＃ｎｊ（ｊ＝１，…，Ａ）が、パケット
データ処理プロセッサ６２＃１Ａの処理（計算回数の算
出処理）に加えて、パケットのＵＤＰチェックサムフィ
ールド値を中間レジスタ８２にセーブする処理とＵＤＰ
チェックサムフィールド値に’０’を補充する処理を行
う。

【００８８】(4)については、パケットデータ処理プロ
セッサ６６＃ｎＣが計算したチェックサムの計算結果を
ＵＤＰヘッダのチェックサムフィールドに書き込む代わ
りに、その計算結果と中間レジスタ８２にセーブされた
チェックサムフィールド値を比較して、値が一致するか
否かを判断する。ＵＤＰヘッダのチェックサムが正しい
か否かを示すフラグを中間レジスタ８２に書き込む。
(5),(6),(7)については、後段のパケットデータ処理プ
ロセッサ６８＃ｎｊ（ｊ＝１〜ｍ）が行う。

【００８９】図３中のスイッチ・ファブリック５０は、
受信ＩＦ部４２＃ｉ（ｉ＝１〜ｎ）から入力されるルー
ティング情報を元に、Ｌ２ＴＰカプセル化／デカプセル
化されたパケットの送信先アドレスに該当する出方路の
送信ＩＦ部５２＃ｉ（ｉ＝１〜ｎ）に出力する。送信Ｉ
Ｆ部５２＃ｉ（ｉ＝１〜ｎ）は、スイッチ・ファブリッ
ク５０より入力されるパケットを物理インタフェースに
従って、送信インタフェース部５４＃ｉを通して、伝送
路に送信する。

【００９０】尚、本実施形態では、ＵＤＰのチェックサ
ムの演算に係る処理を受信ＩＦ部４２＃ｉ（ｉ＝１〜
ｎ）で行う構成としたが、送信ＩＦ部５２＃ｉ（ｉ＝１
〜ｎ）で行うことも可能である。図２中のＬＡＣ３２で
のＰＰＰセクションからＬ２ＴＰのカプセル化及びＬ２
ＴＰからＰＰＰセクションへのデカプセル化処理におい
ても、チェックサムの計算に係る図６及び図１０の構成
と同様の構成とすることができる。更に、可変長のパケ
ットデータを演算対象する他のパケットデータ処理装置
においても適用可能である。

【００９１】以下、図３のＬＮＳ３６の動作説明をす
る。

【００９２】（１）パケットのＬ２ＴＰカプセル化ＬＮＳ３６の受信インタフェース部４４＃１には、図２
中のプライベートネットワーク３８より送信された図５
に示すフォーマットのパケットが入力される。受信イン
タフェース部４４＃１は、伝送路より物理インタフェー
スに従ってパケットを受信する。前処理部４６＃ｉは、
受信されたパケットをシリアル／パラレル変換、パケッ
トヘッダの検出等を行う。パケットはパケットアクセス
レジスタ８０に出力し、パケットヘッダを示すフラグ等
は中間レジスタ８２に出力する。

【００９３】図１２は、図６のタイムチャートである。
パケットデータ処理プロセッサ６２＃１Ａよりも前段の
パケットデータ処理プロセッサ６２＃１１は、例えば、
プライベートネットワーク３８から受信したパケットの
送信先ＩＰアドレスが、テーブルに登録されているＬ２
ＴＰカプセル化が必要なＩＰアドレスだった場合、カプ
セル化処理を行うものと判断する。Ｌ２ＴＰカプセル化
に必要なパケットであるか否かを示すフラグを中間レジ
スタ８２に書き込む。Ｌ２ＴＰ処理が必要なパケットで
あれば、図５及び図１２に示すように、ＰＰＰヘッダの
付加、ＵＤＰヘッダの付加、ＩＰヘッダの付加といった
処理を行って、パケットアクセスレジスタ８０に出力す
る。このとき付加されたＵＤＰヘッダのチェックサムフ
ィールドは０で補充している。

【００９４】パケットデータ処理プロセッサ６２＃１Ａ
は、パケットの先頭が入力されると起動されて、プロセ
ッサ内の命令コードに従って演算を行っていく。最初の
命令手順においてパケットからＵＤＰヘッダのｌｅｎｇ
ｔｈフィールドからＵＤＰデータ長を得る。その値はＵ
ＤＰヘッダとＵＤＰデータ部を合わせたパケットの長さ
をバイト単位で表したものである。このＵＤＰデータ長
にイーサットヘッダ長及びＩＰヘッダ長を加えたパケッ
ト長を求める。次の命令手順でパケット長を４で割り
（２ビット右にシフトさせる）、さらに次の命令手順で
前の命令にキャリが生じたならばシフトした結果に１を
足す。この結果を図１２中の(1)に示すように、加算器
用レジスタ（ＡＲ）に保存する。

【００９５】抽出加算器６４は、中間レジスタ８２に書
き込まれるパケットの先頭を示すフラグによりパケット
の先頭が入力されたことが分かると以下の処理を実行す
る。パケットデータ処理プロセッサ６２＃１Ａの加算器
用レジスタ（ＡＲ）から（加算回数＋９）を得て、カウ
ンタ９６にセットする。そして、パケットの入力後の９
クロックは制御部９４がカウンタ９６値を１減らす以外
は何も行わず、図９に示すように、ＵＤＰヘッダの１６
ビット目が入力される１０クロック目から加算を行う。

【００９６】抽出加算器６４は、３２ビット単位での１
の補数和を求める。最初の加算は０と行い、その結果を
加算結果格納レジスタ１０４に格納する。以降の加算は
このレジスタ１０４の値と入力されるパケットの値とで
行う、結果を加算結果格納レジスタ１０４に格納してゆ
く。制御部９４は、加算を行うたびにカウンタ９６の値
を１減らしていき、カウンタ９６の値が１になった後の
加算が最終的な加算結果なので、図１２中の(2)に示す
ように、これをＦＩＦＯ７０の最後尾に書き込むよう制
御する。

【００９７】中段のパケットデータ処理プロセッサ６６
＃１Ｃは、中間レジスタ８２に書き込まれるパケットの
先頭を示すフラグによりパケットの先頭が入力されたこ
とが分かると以下の処理を実行する。図１０に示す擬似
ヘッダに設定される各値及びＵＤＰヘッダの最初の１６
ビットのパケットデータをパケットアクセスレジスタ８
０より読み出す。そして、擬似ヘッダ及びＵＤＰヘッダ
の最初の１６ビットのデータに対しては、１６ビット単
位で１の補数和を算出して、図１２中の(3)に示すよう
に、中間レジスタ８２に格納する。この結果はパケット
と同期して送信される。

【００９８】パケットデータ処理プロセッサ６６＃１Ｂ
は、中間レジスタ８２に書き込まれるパケットの先頭を
示すフラグによりパケットのＵＤＰヘッダが入力された
ことが分かるとプロセッサ内の命令コードに従って演算
を行ってゆく。パケットデータ処理プロセッサ６６＃１
Ｂは最初の命令手順でＦＩＦＯ７０から値を取り出す命
令を実行する。このとき、ＦＩＦＯ７０を制御するアク
セス機構部７２はパケットデータ処理プロセッサ６６＃
１Ｂからの要求によりＦＩＦＯ７０の先頭の値を送信
し、その後ＦＩＦＯ７０の中のデータを１つ前に詰め
る。

【００９９】上述したように入力されたパケットに対す
る演算処理が抽出加算器６４で終了してＦＩＦＯ７０に
書き込まれているので、ＦＩＦＯ７０より読み出された
値が入力されたパケットに対するものである。パケット
データ処理プロセッサ６６＃１Ｂは次の命令手順でＦＩ
ＦＯ７０から得られた抽出加算器６４での演算結果の上
位１６ビットと下位１６ビットで１６ビット単位の１の
補数和を求める。

【０１００】次の命令手順で、前段のパケットデータ処
理プロセッサ６６＃１Ｃで求まった、擬似ヘッダとＵＤ
Ｐヘッダの先頭１６ビットの１の補数和を中間レジスタ
８２より取り出し、前の命令で求まった結果との間で１
の補数和を求める。以上の動作でＵＤＰチェックサムに
必要なデータの１６ビット単位での１の補数和を求めた
ことになる。そして、次の命令手順でこの値の１の補数
和を求め、これが最終的に求めようとしていたＵＤＰチ
ェックサムなので、図１２中の(4)に示すように、その
値をチェックサムフィールドに格納する。以上の手順で
ＵＤＰヘッダのチェックサムの計算を行い、ＵＤＰヘッ
ダに格納する処理をパイプライン処理することができ
る。

【０１０１】この後パケットは後段のパケットデータ処
理プロセッサ６８＃１ｊ（ｊ＝１〜ｍ）によりルーティ
ング情報が検出されてからスイッチ・ファブリック５０
に渡される。スイッチ・ファブリック５０は、パケット
をルーティング情報に従ってルーティングして、該当す
る送信ＩＦ部５２＃ｉ、例えば、５２＃ｎに渡し、送信
インタフェース部５４＃ｎから伝送路に送信する。この
パケットは、インターネット網３４を経由して、Ｌ２Ｔ
Ｐカプセル化されたパケットの送信先ＩＰアドレスであ
るパケット中継装置まで中継される。Ｌ２ＴＰサポート
のパケット中継装置で受信され、デカプセル化の後、端
末等に送信される。

【０１０２】（２）Ｌ２ＴＰデカプセル化ＬＮＳ３６の受信インタフェース部４４＃ｎには、図２
中のインターネット網３４より送信された図５に示すフ
ォーマットのパケットが入力される。受信インタフェー
ス部４４＃ｎは、伝送路より物理インタフェースに従っ
てパケットを受信する。前処理部４６＃ｎは、受信され
たパケットをシリアル／パラレル変換、パケットヘッダ
の検出等を行う。パケットはパケットアクセスレジスタ
８０に出力し、パケットヘッダを示すフラグ等は中間レ
ジスタ８２に出力する。パケットデータ処理プロセッサ
６２＃ｎ１は、パケットのＵＤＰチェックサムフィール
ドの値を中間レジスタ８２に保存してから、０クリアす
る。

【０１０３】パケットデータ処理プロセッサ６２＃ｎ
Ａ、抽出加算器６４、パケットデータ処理プロセッサ６
６＃ｎＣの処理は、Ｌ２ＴＰカプセル化処理と同様であ
る。パケットデータ処理プロセッサ６６＃ｎＢは、パケ
ットデータ処理プロセッサ６６＃１Ｂと同様に処理をし
て、ＵＤＰチェックサムを算出する。ＵＤＰチェックサ
ムと中間レジスタ８２に保存されたＵＤＰチェックサム
フィールドの値が一致するか否かを判別する。一致しな
ければ、パケットを破棄する。一致すれば、パケット
は、後段のパケットデータ処理プロセッサ６８＃１ｊ
（ｊ＝１〜ｍ）により、ＰＰＰヘッダ削除、ＵＤＰヘッ
ダ削除、ＩＰヘッダ削除が行われた後、ルーティング情
報が検出されてからスイッチ・ファブリック５０に渡さ
れる。

【０１０４】スイッチ・ファブリック５０は、パケット
をルーティング情報に従ってルーティングして、該当す
る送信ＩＦ部５２＃ｉ、例えば、５２＃１に渡し、送信
インタフェース部５４＃１からプライベートネットワー
ク３８に送信する。

【０１０５】以上説明したように、本実施形態によれ
ば、ＵＤＰチェックサムの計算のように演算対象が可変
長データとなる場合にもＦＩＦＯを設け、パイプライン
構成により処理することができるので、パケット処理が
高速になる。尚、上述の構成では、抽出加算器にデータ
を送ることのできるパケットデータ処理プロセッサから
ＦＩＦＯの値を取り出すことのできるパケットデータ処
理プロセッサの間のパケットデータ処理プロセッサは２
４個で固定となるが、この数はＦＩＦＯに格納できる値
の数（段数）を多く取ることにより２４個からＦＩＦＯ
の段数まで取ることができる。そこで、ＦＩＦＯの段数
が多い場合には装置の起動時などにパケットデータ処理
プロセッサの中からパケット処理プロセッサ６２＃ｉＡ
とパケットデータ処理プロセッサ６６＃ｉＢを任意に設
定することができるような構成を取ることもできる。ま
た、上述の構成では、抽出加算器を使用していたが、抽
出加算器以外にも演算結果が求まる処理数がパケット長
に依存しているようなプロセッサを使用するような構成
を取ることもできる。

【０１０６】第２実施形態図１３は、本発明の第２実施形態によるＬ２ＴＰプロト
コルを用いたＶＰＮネットワークの構成及びパケットフ
ォーマットを示す図であり、図２中の構成要素と実質的
に同一の構成要素には同一の符号を附している。

【０１０７】図１４は、図１３中のＬＮＳ１２０の構成
図であり、図３中の構成要素と実質的に同一の構成要素
には同一の符号を附している。

【０１０８】図１５は、図１３中のＬ２ＴＰカプセル化
部１２２＃１の構成図であり、図６中の構成要素と実質
的に同一の構成要素には同一の符号を附している。図１
５に示すように、Ｌ２ＴＰカプセル化部１２２＃１は、
カプセルカブパケットデータ処理プロセッサ６２＃１ｊ
（ｊ＝１，…，Ａ）、抽出加算器６４及びパケットデー
タ処理プロセッサ６６＃１ｊ（ｊ＝１，…，Ｃ，Ｂ）を
パイプライン構成するのではなく、パケットデータ処理
プロセッサ６２＃１ｊ（ｊ＝１，…，Ａ）及びパケット
データ処理プロセッサ６６＃１ｊ（ｊ＝１，…，Ｃ，
Ｂ）で構成されるパイプラインから抽出加算器６４を別
パスとする。即ち、抽出加算器６４は中段のパケットデ
ータ処理プロセッサ部６６＃１ｊ（ｊ＝１，…Ｃ，
Ｂ），６８＃１ｊ（ｊ＝１〜ｍ）と並列に配置されてい
る。

【０１０９】図１６は、図１５中の抽出加算器６４の構
成図であり、図８中の構成要素と実質的に同一の構成要
素には同一の符号を附している。図１６に示すように、
パケットデータ処理プロセッサ６２＃１Ａのパケットア
クセスレジスタの出力側と抽出加算器６４のレジスタ９
０，９２の入力側とをバス１３０により接続するが、レ
ジスタ９０，９２の出力側とパケットデータ処理プロセ
ッサ６６＃１１のパケットアクセスレジスタの入力側を
接続していない。

【０１１０】このように、パケットデータ処理プロセッ
サ６２＃１ｊ（ｊ＝１，…，Ａ），６６＃１ｊ（ｊ＝
１，…，Ｃ，Ｂ），６８＃１ｊ（ｊ＝１〜ｍ）からなる
パイプラインプロセッサのデータパスから抽出加算器６
４を別パスとすることにより、バス１３０を別に設ける
必要があるというデメリットがあるが、抽出加算器６４
のレジスタ９２でのパケットの遅延が無くなり、パケッ
ト処理が高速になること、同種のパケットデータ処理プ
ロセッサのみによりパイプライン構成にすることにより
製造が容易になることのメリットがある。中段のパケッ
トデータ処理プロセッサ６６＃１ｊ（ｊ＝１，…，Ｃ）
の個数は、レジスタ９２が１段構成なので、第１実施形
態と変更なく、２４個となる。Ｌ２ＴＰカプセル化部１
２２＃１の動作は、Ｌ２ＴＰカプセル化部４８＃１の動
作と同様である。

【０１１１】図１７は、図１４中のＬ２ＴＰデカプセル
化部１２２＃ｎの構成図であり、図１１中の構成要素と
実質的に同一の構成要素には同一の符号を附している。
図１７に示すように、Ｌ２ＴＰデカプセル化部１２２＃
ｎは、パケットデータ処理プロセッサ６２＃ｎｊ（ｊ＝
１，…，Ａ）、抽出加算器６４及びパケットデータ処理
プロセッサ６６＃ｎｊ（ｊ＝１，…，Ｃ，Ｂ）をパイプ
ライン構成するのではなく、パケットデータ処理プロセ
ッサ６２＃ｎｊ（ｊ＝１，…，Ａ）及びパケットデータ
処理プロセッサ６６＃ｎｊ（ｊ＝１，…，Ｃ，Ｂ）で構
成されるパイプラインから抽出加算器６４を別パスとす
る。即ち、抽出加算器６４は中段のパケットデータ処理
プロセッサ部６６＃ｎｊ（ｊ＝１，…Ｃ，Ｂ），６８＃
ｎｊ（ｊ＝１〜ｍ）と並列に配置されている。かかる構
成とした趣旨は、Ｌ２ＴＰカプセル化部１２２＃１と同
様である。以上説明したように、第２実施形態によれ
ば、第１実施形態と同様の効果がある。

【０１１２】

【発明の効果】以上説明したように本発明によれば、複
数のデータ処理部と並列にメモリを設置する手法をとる
ことによってパケットデータ処理方式の特徴であるパケ
ットの高速化を損なうことなく、ＵＤＰやＴＣＰヘッダ
のチェックサムの演算のように、パケットによって取り
出すタイミングの異なるデータを取り出して、後段のデ
ータ処理部で使用することが可能となる。

【図面の簡単な説明】

【図１】本発明の原理図である。

【図２】本発明の第１実施形態によるＶＰＮネットワー
ク構成図である。

【図３】図２中のＬＮＳの構成図である。

【図４】プライベートネットワークの構成図である。

【図５】Ｌ２ＴＰカプセル化パケットを示す図である。

【図６】図３中のＬ２ＴＰカプセル化部の構成図であ
る。

【図７】図６中のパケットデータ処理プロセッサの構成
図である。

【図８】図６中の抽出加算器の構成図である。

【図９】抽出加算器の計算対象領域を示す図である。

【図１０】擬似ヘッダを示す図である。

【図１１】図３中のＬ２ＴＰデカプセル化部の構成図で
ある。

【図１２】図６のタイムチャートである。

【図１３】本発明の第２実施形態によるＶＰＮネットワ
ーク構成図である。

【図１４】図１３中のＬＮＳの構成図である。

【図１５】図１４中のＬ２ＴＰカプセル化部の構成図で
ある。

【図１６】図１５中の抽出加算器の構成図である。

【図１７】図１４中のＬ２ＴＰデカプセル化部の構成図
である。

【符号の説明】

２第１データ処理部４メモリ６第２データ処理部８アクセス機構部１０第３データ処理部１２遅延部

───────────────────────────────────────────────────── フロントページの続き (72)発明者梅崎康之福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者下園善知福岡県福岡市博多区博多駅前三丁目22番８号富士通九州ディジタル・テクノロジ株式会社内 (72)発明者鶴岡哲明神奈川県川崎市中原区上小田中４丁目１番１号富士通株式会社内Ｆターム(参考） 5K030 GA03 HA08 HC01 JA05 KA03 KA13 KX13 LC01 MA13

Claims

【特許請求の範囲】

【請求項１】入力されるパケットのパケットデータに
対して演算処理をするパケットデータ装置であって、前記パケットのパケット長に基づいて演算処理回数に係
わる演算情報を算出し、該演算情報を出力する第１デー
タ処理部と、メモリと、前記演算情報に従って、順次入力される前記パケットの
パケットデータに対して演算処理をして、前記パケット
についてのパケットデータに対する演算が終了すると第
１演算結果を前記メモリに書き込む第２データ処理部
と、読み出し要求に基づいて前記メモリに最も以前に書き込
まれた第１演算結果を読み出し、読み出した第１演算結
果を前記メモリから削除するアクセス機構部と、前記パケットの所定位置のパケットデータが入力される
と前記読み出し要求を行い、前記アクセス機構部より読
み出された第１演算結果及び前記パケットに基づいて処
理をする第３データ処理部と、最大パケット長のパケットの前記所定位置のパケットデ
ータが前記第３データ処理部に入力されたとき、該パケ
ットについてのパケットデータに対する第１演算結果の
前記メモリへの書き込みが終了しているように、前記パ
ケットの前記第３データ処理部への入力を遅延させる遅
延部とを具備し、前記メモリは、前記第３データ処理部にパケットが入力
されたとき、該パケットに対する第１演算結果を保持す
る容量を有することを特徴とするパケットデータ処理装
置。
【請求項２】前記パケットの固定長のフィールドに設
定されたパケットデータに基づいて演算処理をして、第
２演算結果を算出する第４データ処理部を更に具備し、
前記第３データ処理部は、前記第１演算結果、前記第２
演算結果及び前記パケットに基づいて処理をすることを
特徴とする請求項１記載のパケットデータ処理装置。
【請求項３】前記遅延部は前記第２〜第４データ処理
部にそれぞれ対応して設けられたシフトレジスタが縦続
されたシフトレジスタ群で構成され、前記各第２〜４デ
ータ処理部は、それぞれ対応して設けられた前記シフト
レジスタに格納される前記パケットに基づいて処理をす
ることを特徴とする請求項２記載のパケットデータ処理
装置。
【請求項４】前記遅延部は前記第３〜第４データ処理
部にそれぞれ対応して設けられたシフトレジスタが縦続
されたシフトレジスタ群で構成され、前記第２データ処
理部は前記シフトレジスタ群と並列に配置され、前記第
３〜第４データ処理部は、それぞれ対応して設けられた
前記シフトレジスタに格納される前記パケットに基づい
て処理をすることを特徴とする請求項２記載のパケット
データ処理装置。
【請求項５】前記シフトレジスタ群と並列に配置さ
れ、前記パケットに係る中間データを格納する第２シフ
トレジスタ群を更に具備したことを特徴とする請求項３
記載のパケットデータ処理装置。