(57)【要約】 【目的】  パケットの受信処理を高速に行えることを課題とする。【構成】  パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割すると共に、受信パケットに対する各レイヤのサブ処理を並列に実行する複数のプロセッサと、各プロセッサによる処理結果の整合性を下位レイヤからの所定のプロトコル手順に従って検査し、該検査をパスしたルートの処理結果を採用する整合性検査手段とを備える。【選択図】  図１
2008187323.tif 000002
【特許請求の範囲】
【請求項１】
パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割しておくと共に、受信パケットに対する各レイヤのサブ処理を複数のプロセッサにより並列に実行して後、各処理結果の整合性を下位レイヤからの所定のプロトコル手順に従って検査し、該検査をパスしたルートの処理結果を採用することを特徴とする受信パケットの処理方法。
【請求項２】
パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割すると共に、受信パケットに対する各レイヤのサブ処理を並列に実行する複数のプロセッサと、
各プロセッサによる処理結果の整合性を下位レイヤからの所定のプロトコル手順に従って検査し、該検査をパスしたルートの処理結果を採用する整合性検査手段とを備えることを特徴とするパケット通信装置。
【請求項３】
複数のプロセッサによりアクセス可能な共有メモリと、
前記共有メモリに記憶された受信パケットについてのポインタ情報を各プロセッサに通知する通知手段とを備えることを特徴とする請求項２記載のパケット通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は受信パケットの処理方法及びパケット通信装置に関し、特に、受信パケットを高速処理する場合に適用して好適である。
【背景技術】
【０００２】
近年の無線通信網、有線通信網の融合や各キャリア間のネットワーク接続に伴い、ネットワークが大変複雑化している。それに伴いネットワーク上を流れるパケットも多くの装置を経由する事で遅延が発生し、リアルタイム性が損なわれる方向にある。
【０００３】
図６にイーサネット（登録商標）のフレームフォーマットを示す。通常、パケットは各レイヤに対応したプロトコルスタックの構成になっており、物理レイヤに近い下位のデータリンク層から処理を開始し、上位のアプリケーション層まで順番に処理を行っていく。図６（Ａ）のデータリンク層ではイーサネット（登録商標）のヘッダ情報に基づき各種ネットタイプ（ＩＰ：Internet Protocol，ＡＲＰ：Address Resolution Protocol等）のデータを転送する。このデータには上位層（ＩＰ，ＡＲＰ等）のヘッダ情報が含まれるが、データリンク層では単にデータとして扱われる。また、図６（Ｂ）のネットワーク層ではＩＰヘッダの情報に基づき各種プロトコルタイプ（ＴＣＰ，ＵＤＰ等）のＩＰデータを転送し、更に、図６（Ｃ）のトランスポート層ではＴＣ／ＵＤＰヘッダの情報に基づきＴＣＰ／ＵＤＰデータを転送する。
【０００４】
図７は従来のパケット受信処理を説明する図で、ＡＲＰサービスや、ルータにおけるＩＰパケットのルーティングサービスをサポートする場合を示している。パケットを受信すると、ステップＳ２０以降のレイヤ２終端処理を開始する。即ち、ステップＳ２１ではＦＣＳ（Frame Check Sequence）検査結果がＯＫか否かを判別し、ＯＫでない場合は当該フレームを破棄する。なお、ＦＣＳ検査はハードウェアで行われる。また、ＦＣＳ検査ＯＫの場合は、ステップＳ２２で送信元ＭＡＣアドレスを解析し、ステップＳ２３では宛先ＭＡＣアドレスを解析する。更に、ステップＳ２４では宛先ＭＡＣアドレスが自局宛か否かを判別し、自局宛でない場合は当該フレームを破棄する。また自局宛の場合は、ステップＳ２５でイーサネット（登録商標）のタイプフィールドの内容を調べ、「ＡＲＰ」の場合はステップＳ３０以降のＡＲＰ応答処理ルーチンにデータを渡し、「ＩＰ」の場合はステップＳ４０以降のレイヤ３終端処理（ＩＰ処理ルーチン）にデータを渡す。また、処理できないプロトコルタイプ値の場合は当該フレームを破棄する。
【０００５】
ステップＳ３０以降のＡＲＰ応答処理において、ステップＳ３１ではＡＲＰ要求パケット中の検索ＩＰアドレスを解析する。ステップＳ３２では検索対象ＩＰアドレスが自局を指しているか否かを判別し、自局を指していない場合は、応答する必要が無いので、当該パケットを破棄する。また、自局を指している場合は、ステップＳ３３で自局のＭＡＣアドレスを抽出する。ステップＳ３４ではＡＲＰ応答パケットを生成し、送信元ＭＡＣアドレスに送信する。
【０００６】
ステップＳ４０以降のレイヤ３終端処理において、ステップＳ４１ではＩＰヘッダのチェックサムを計算する。ステップＳ４２では検査結果がＯＫか否かを判別し、ＯＫでない場合は当該パケットを破棄する。また、検査ＯＫの場合は、ステップＳ４３で送信元ＩＰアドレスを解析し、ステップＳ４４では宛先ＩＰアドレスを解析する。自局がホストの場合は、宛先が自局であるため、レイヤ４終端処理に進み、そのままデータを受信する。この場合は、図示しないが、更に上位プロトコルを調べ、ＴＣＰ（Transmission Control Protocol）の場合はＴＣＰの処理ルーチンに、ＵＤＰ（User Datagram Protocol）の場合
はＵＤＰの処理ルーチンにデータを送る。
【０００７】
また、自局がルータの場合は、宛先が自局以外であるため、引き続きステップＳ５０以降のレイヤ３生成処理を開始する。ステップＳ５１ではＩＰアドレス変換テーブルを検索し、ステップＳ５２では次に送るホストやルータへの宛先ＩＰアドレスの入れ替えを行う。ステップＳ５３ではＩＰヘッダのチェックサムを生成し、ステップＳ６０以降のレイヤ２生成処理に移行する。即ち、ステップＳ６１では、ＭＡＣアドレス変換テーブルを検索する。ステップＳ６２では次に送るホストやルータへのＭＡＣアドレスの入れ替えを行い、こうして宛先変換したパケットを送信する。
【０００８】
この様に従来は、下位プロトコルの処理終了を待って、順次上位プロトコルの処理を行うため、パケット処理に遅延を来していた。
【０００９】
この点、従来は、各レイヤの受信処理を仮処理として並列に行うと共に、その後、下位レイヤの処理結果に基づいて仮処理を有効とするデータ受信並列処理方法にが知られている（特許文献１）。
【特許文献１】特開平６−３５０６７０
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、上記従来方式では、各レイヤの処理を並列に行うが、各レイヤ内の処理はシーケンシャルに行うため、パケット処理の遅延短縮には限界があった。
【００１１】
本発明は上記従来技術の問題点に鑑みなされたものであり、その目的は、パケットの受信処理を高速に行える受信パケットの処理方法及びパケット通信装置を提供することにある。
【課題を解決するための手段】
【００１２】
本発明の第１の態様による受信パケットの処理方法は、パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割しておくと共に、受信パケットに対する各レイヤのサブ処理を複数のプロセッサにより並列に実行して後、各処理結果の整合性を下位レイヤからの所定のプロトコル手順に従って検査し、該検査をパスしたルートの処理結果を採用するものである。
【００１３】
本発明では、パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割しておくと共に、不要となるかも知れないが、全サブ処理を複数のプロセッサを用いて並列処理して後、下位レイヤからの所定のプロトコル手順に従って適正な分岐ルートの処理結果を抜き出す事により、パケット処理時間の大幅な短縮が図れる。
【００１４】
本発明の第２の態様によるパケット通信装置は、パケット通信に係る下位レイヤから上位レイヤに至る複数のプロトコル処理をそれぞれ独立して実行可能な複数のサブ処理に分割すると共に、受信パケットに対する各レイヤのサブ処理を並列に実行する複数のプロセッサと、各プロセッサによる処理結果の整合性を下位レイヤからの所定のプロトコル手順に従って検査し、該検査をパスしたルートの処理結果を採用する整合性検査手段とを備えるものである。
【００１５】
本発明の第３の態様では、複数のプロセッサによりアクセス可能な共有メモリと、前記共有メモリに記憶された受信パケットについてのポインタ情報を各プロセッサに通知する
通知手段とを備える。従って、メモリ容量の節約と、パケットコピーに要する時間を大幅に短縮できる。
【発明の効果】
【００１６】
以上述べた如く本発明によれば、大規模ネットワーク上で、パケットが多くの装置を経由しても、パケットの伝送遅延を最小に抑制でき、パケット通信の高速化に寄与するところが極めて大きい。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。
【００１８】
図１は実施の形態によるパケット通信装置のブロック図で、ＩＰネットワークに接続するルータやホスト装置の一例を示している。図において、１００はＩＰネットワーク、１０ａ，１０ｂはルータ、１１はパケットの受信インタフェース（ＩＦ）、１２は受信パケットを一時的に記憶すると共に、後述の各レイヤのサブ処理を並列に実行するプロセッサがアクセス可能は共有メモリ（メモリスイッチ）、１３はメモリ制御部、１４は受信パケットに対する各レイヤの細分化されたサブ処理を並列に実行するレイヤ処理部、１５はレイヤ処理１４の各種処理結果を格納する処理結果格納テーブル、１６はテーブル１５の処理結果をプロトコル順に検査して正しいプロトコル処理結果を選択する整合性検査部、１７はパケットの送信ＩＦ、２０は通信制御部、２１はパケットの通信ＩＦ、２２はレイヤ２〜４の細分化された各サブ処理を並列に実行する下位レイヤ処理部、２３はレイヤ５以上の細分化された各サブ処理を並列に実行する上位レイヤ処理部、３０はパーソナルコンピュータ等のホスト装置である。
【００１９】
レイヤ処理部１４において、レイヤ２〜４の各プロトコル処理はそれぞれ独立に実行できる大きさの複数のサブ処理に分割されており、各サブ処理は、不図示のＯＳを背景に生成された複数のプロセッサＰＲＣ＃１〜ＰＲＣ＃６等により、見かけ上同時にかつ並列に実行される。
【００２０】
図２，図３は実施の形態によるパケット受信処理のフローチャート（１），（２）であり、ＡＲＰサービスや、ルータにおけるＩＰパケットのルーティングサービスをサポートする場合を示している。図２はレイヤ処理部における各サブ処理の並列処理を示しており、新たなパケットを受信するとこのレイヤ処理が起動される。
【００２１】
ステップＳ１２ではパケット格納場所のポインタ情報を各プロセッサに一斉に通知する。このポインタ情報は、例えば受信フレームの先頭アドレス、又は各レイヤ処理で使用するヘッダ（レイヤ２のヘッダ，ＡＲＰヘッダ，ＩＰヘッダ，ＴＣＰ／ＵＤＰヘッダ等）情報の先頭アドレス、又は各サブ処理で使用するヘッダ情報（送信元アドレス、宛先アドレス，プロトコルタイプ等）の先頭アドレスでよい。
【００２２】
レイヤ２終端処理に関して、サブ処理Ｐ２３では、上記ポインタ情報の通知を契機に、イ−サネットフレームの先頭から６オクテット分の位置に宛先ＭＡＣアドレスが格納されているものとして宛先ＭＡＣアドレスを解析（抽出）し、処理終了フラグ＝１（処理終了）と共に該宛先ＭＡＣアドレスを処理結果格納テーブルの該当番地に格納する。サブ処理Ｐ２２では、同じく上記ポインタ情報の通知を契機に、宛先ＭＡＣアドレスに続く６オクテット分の位置に送信元ＭＡＣアドレスが格納されているものとして送信元ＭＡＣアドレスを解析（抽出）し、処理終了フラグ＝１と共に該送信元ＭＡＣアドレスを処理結果格納テーブルの該当番地に格納する。サブ処理Ｐ４では、同じく送信元ＭＡＣアドレスに続く２オクテット分の位置にイーサネット（登録商標）のタイプ情報（ＡＲＰ，ＩＰ等）が格
納されているものとして該タイプ情報を解析（抽出）し、処理終了フラグ＝１と共に該タイプ情報を処理結果格納テーブルの該当番地に格納する。以上の各サブ処理は実質同時に開始され、並行して実行される。よって、レイヤ２終端の処理時間を大幅に短縮できる。
【００２３】
図４（Ａ）にＩＰヘッダの主要部を示す。レイヤ３終端処理に関して、サブ処理Ｐ４１では、上記ポインタ情報の通知を契機に、ＩＰヘッダのチェックサム領域に２オクテット分のヘッダチェックサムが格納されているものとして、ＩＰヘッダ領域のチェックサム計算を行い、処理終了フラグ＝１と共にその検査結果を処理結果格納テーブルの該当番地に格納する。サブ処理Ｐ４２〜Ｐ４４についても同様である。
【００２４】
図４（Ｂ）にＡＲＰヘッダの主要部を示す。ＡＲＰ処理に関して、サブ処理Ｐ３１では、上記ポインタ情報の通知を契機に、ＡＲＰヘッダにおける検索するＩＰアドレスの領域（４オクテット分）に検索するＩＰアドレスが格納されているものとして、検索するＩＰアドレスの情報を解析（抽出）し、処理終了フラグ＝１と共に該検索するＩＰアドレスの情報を処理結果格納テーブルの該当番地に格納する。
【００２５】
一方、サブ処理Ｐ３３では、自局のＭＡＣアドレス（自局において既知）を抽出し、サブ処理Ｐ３４に渡す。サブ処理３４では、サブ処理Ｐ３３から渡された自局のＭＡＣアドレスを使用して、ＡＲＰ要求パケットの送信元に返送するためのＡＲＰ応答パケットを生成し、処理終了フラグ＝１と共にＡＲＰ応答パケットの格納アドレスを処理結果格納テーブルの該当番地に格納する。この時点では、受信パケットがＡＲＰ要求パケットであるのか否か、またその検索するＩＰアドレスが自局を指しているのか否かは分からないが、そうである場合を仮定して予めＡＲＰ応答パケットを作成しておくものである。これらは無駄な処理になるかも知れないが、もし自局を探すＡＲＰ要求パケットであった場合はＡＲＰ応答パケットを送信するまでの遅延時間を大幅に短縮できる。なお、サブ処理Ｐ３４はサブ処理Ｐ３３に従属しているが、サブ処理Ｐ３３とＰ３４とを合わせて独立に実行可能な一つのサブ処理としても良い。
【００２６】
レイヤ３生成処理に関して、サブ処理Ｐ５１は、上記ポインタ情報の通知を契機に起動されると共に、上記サブ処理Ｐ４３から知らされる宛先ＩＰアドレスを使用してＩＰアドレス変換テーブルを検索し、次に当該パケットを送信すべき方路のＩＰアドレスを取得する。サブ処理Ｐ５２では当該パケットの宛先ＩＰアドレスを前記取得したＩＰアドレスで入れ替えたＩＰヘッダを生成する。サブ処理Ｐ５３では前記宛先ＩＰアドレスを入れ替えたＩＰヘッダについてのＩＰヘッダチェックサムを生成し、当該ＩＰヘッダのチェックサム領域に書き込む。そして、処理終了フラグ＝１と共に前記生成したＩＰヘッダの格納アドレスを処理結果格納テーブルの該当番地に格納する。
【００２７】
こうして別途に生成されたＩＰヘッダは、受信パケットの宛先ＩＰアドレスが自局（ホスト）宛であった場合は無駄になるが、ルータにおけるように他局宛の場合は予め宛先ＩＰアドレスを入れ替えたＩＰヘッダを別途生成しておくことで、レイヤ３処理の大幅な短縮に繋がる。なお、サブ処理Ｐ５１〜Ｐ５３を独立して実行可能な一つのサブ処理としても良い。この場合でも、レイヤ３終端処理とレイヤ３生成処理とが並列に実行されるため、レイヤ３の処理時間を大幅に短縮できる。
【００２８】
レイヤ２生成処理に関して、サブ処理Ｐ６１は、上記ポインタ情報の通知を契機に起動されると共に、上記サブ処理Ｐ５２から知らされる新たな宛先ＩＰアドレスを使用してＭＡＣアドレス変換テーブルを検索し、対応するＭＡＣアドレスを取得する。サブ処理Ｐ６２では当該イーサネット（登録商標）フレームについての宛先ＭＡＣアドレスを入れ替えたイーサネット（登録商標）ヘッダを別途生成し、処理終了フラグ＝１と共に前記生成したヘッダの格納アドレスを処理結果格納テーブルの該当番地に格納する。
【００２９】
図３は整合性検査部１６における検査処理を示し、上記ポインタ情報の通知に同期して起動される。ステップＳ１３では処理結果格納テーブルの処理終了フラグを検査し、ステップＳ１４では全処理終了か否かを判別する。全処理終了でない場合はステップＳ１３に戻り、こうして、やがて全処理終了になると、ステップＳ２０以降のレイヤ２終端検査処理を実行する。ステップＳ２１ではＦＣＳ検査ＯＫか否かを判別し、ＯＫでない場合は当該受信フレームを破棄する。ＦＣＳ検査は受信ＩＦ１１で行われる。また、ＦＣＳ検査ＯＫの場合は、ステップＳ２４で当該受信フレームが自局宛か否かを判別し、自局宛でない場合は当該フレームを破棄する。また自局宛の場合はステップＳ２５でプロトコルタイプに従って処理分岐する。
【００３０】
プロトコルタイプがＡＲＰの場合は、ステップＳ３０以降のＡＲＰ応答処理を実行する。ステップＳ３２では検索するＩＰアドレスが自局を指しているか否かを判別し、自局を指していない場合は、応答する必要が無いので、当該ＡＲＰ要求パケットを廃棄し、また自局を指しているル場合は上記サブ処理Ｐ３４で生成されたＡＲＰ応答パケットを送信する。
【００３１】
また、上記ステップＳ２５の判別でプロトコルタイプがＩＰの場合はステップＳ４０以降のレイヤ３終端処理を実行する。ステップＳ４１では上記サブ処理Ｐ４１で計算されたＩＰヘッダチェックサムの検査結果ＯＫか否かを判別し、検査ＯＫでない場合は当該ＩＰパケットを廃棄する。また検査ＯＫの場合はステップＳ４４で当該ＩＰパケットが自局宛か否か判別する。自局（ホスト３０）宛の場合は、図示しないが、上位のレイヤ４終端処理に進む。図５（Ａ）にＴＣＰパケットのヘッダフォーマットを示し、図５（Ｂ）にＵＤＰパケットのヘッダフォーマットを示す。
【００３２】
また、ルータ１０ａの場合は、通常、自局宛でないため、ステップＳ５０のレイヤ３生成検査処理、ステップＳ６０のレイヤ２生成検査処理を経たものとして、上記サブ処理Ｐ５３，Ｐ６２で宛先変換された宛先変換パケット｛イーサネット（登録商標）フレーム｝を対応方路に送信する。
【００３３】
なお、上記実施の形態ではレイヤ２〜４の並列処理を具体的に述べたが、本発明は更に上位のレイヤの並列処理にも適用できる。
【００３４】
また、上記実施の形態では、受信パケットのレイヤ処理を説明したが、本発明は送信パケットのレイヤ処理にも適用できることは明らかである。
【００３５】
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、処理及びこれらの組合せの様々な変更が行えることは言うまでも無い。
【図面の簡単な説明】
【００３６】
【図１】実施の形態によるパケット通信装置のブロック図である。
【図２】実施の形態によるパケット受信処理のフローチャート（１）である。
【図３】実施の形態によるパケット受信処理のフローチャート（２）である。
【図４】各種パケットのヘッダフォーマットを示す図（１）である。
【図５】各種パケットのヘッダフォーマットを示す図（２）である。
【図６】イーサネット（登録商標）フレームのフレームフォーマットを示す図である。
【図７】従来のパケット受信処理を説明する図である。
【符号の説明】
【００３７】
１０ａ，１０ｂ  ルータ
１１  受信インタフェース（ＩＦ）
１２  バッファメモリ（メモリスイッチ）
１３  メモリ制御部
１４  レイヤ処理部
１５  処理結果格納テーブル
１６  整合性検査部
１７  送信ＩＦ
２０  通信制御部
２１  通信ＩＦ
２２  下位レイヤ処理部
２３  上位レイヤ処理部  
３０  ホスト装置
１００  ＩＰネットワーク
【図１】
2008187323.tif 000003
【図２】
2008187323.tif 000004
【図３】
2008187323.tif 000005
【図４】
2008187323.tif 000006
【図５】
2008187323.tif 000007
【図６】
2008187323.tif 000008
【図７】
2008187323.tif 000009