JP4724636B2

JP4724636B2 - プロトコル処理システム及びプロトコル処理方法

Info

Publication number: JP4724636B2
Application number: JP2006275662A
Authority: JP
Inventors: 和彦森村
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-10-06
Filing date: 2006-10-06
Publication date: 2011-07-13
Anticipated expiration: 2026-10-06
Also published as: JP2008098782A

Description

本発明は、ＩＥＴＦのＲＦＣ７９１に基づくＩＰｖ４又はＲＦＣ２４６０に基づくＩＰｖ６プロトコル処理におけるトンネリングプロトコルにおけるカプセリング及びデカプセリングに好適なプロトコル処理システム及びプロトコル処理方法等に関する。

複数の拠点間を接続するネットワークを構築する場合、近年までは第一種電気通信業者が提供する専用線（Private Network）を拠点間毎に契約して網を構築することが一般的であった。

しかし、インターネットの普及に伴いインターネット網における通信コストが劇的に低下したことにより、専用線サービスがインターネット網の通信コストに対して割高となった。そこで、インターネット網を利用して専用線の代替とするＶＰＮ（Virtual Private Network）技術が登場した。従来の専用線に対して帯域の保証はされないが、通信コストを効果的に削減できる技術として注目されている。

一方、通信サービスを受ける側としても、多くの場合、それぞれのメインフレームに依存した通信プロトコルが使用されていない。パーソナルコンピュータ（ＰＣ）等の多くのコンピュータで使用されているＴＣＰ（ＵＤＰ）／ＩＰが使用される場合、即ちＩＰ網を使用する場合が多い。

これら複数のコンピュータを複数の拠点間に接続する場合、そのままインターネット網に接続してもネットワークが成立するが、多くの企業情報が流れることを考慮すると、少なくともペイロードを暗号化する必要が生じてくる。また、企業ネットワークとして網を構築する場合は拠点間であれ、インターネット網に依存した構造を持たせることは、設計上の制約となるので好ましくない。

そこで、企業内で利用しているＩＰ網を暗号化した上でさらにＩＰでカプセリングすることで、インターネット網を使用しているにもかかわらず専用ＩＰ網のように使用するＶＰＮ、即ちＩＰ−ＶＰＮが使用される。ＩＰｓｅｃ−ＶＰＮを用いたネットワークの構成例を図１２に示す。

図１２では拠点Ｃｌｉｅｎｔ１〜５及び拠点Ｓｅｒｖｅｒ１〜２がＩＰ−ＶＰＮＧａｔｅｗａｙを介してインターネットに接続されている。また、インターネットに接続したリモート端末経由のアクセスや、ＶＰＮＣｌｉｅｎｔ端末からＩｎｔｅｒｎｅｔＳｅｒｖｅｒへのアクセス等があることを示している。図１２においてインターネットに直接接続している機器、即ちＩｎｔｅｒｎｅｔＳｅｒｖｅｒ、ＲｅｍｏｔｅＴｅｒｍｉｎａｌ、ＩＰ−ＶＰＮＧａｔｅｗａｙ１〜４にはインターネットのグローバルＩＰアドレスが割り当てられている。これらの機器間の通信にはこのグローバルＩＰアドレスが使用されている。また、ＶＰＮ−Ｇａｔｅｗａｙを介して接続しているＶＰＮ−Ｓｅｒｖｅｒ１〜２、ＶＰＮ−Ｃｌｉｅｎｔ１〜５は同一のＩＰサブネットが割り当てられており、ＶＰＮを構成することが可能である。更に、ＶＰＮ−Ｇａｔｅｗａｙ２はＰｒｏｘｙＳｅｒｖｅｒも兼ねておりＶＰＮを構成している機器のインターネットへのアクセスを制御している。

このような構成に於いて、ＩＰ−ＶＰＮＧａｔｅｗａｙ１〜４は相互にＩＰＳｅｃＴｕｎｎｅｌｉｎｇプロトコルを用い通信しているが、ＶＰＮ−Ｃｌｉｅｎｔ１〜５は特にＩＰＳｅｃの存在を意識することなくＶＰＮ機器間の通信を行うことができる。

ここで、ＩＰ−ＶＰＮＧａｔｅｗａｙ２からＩＰ−ＶＰＮＧａｔｅｗａｙ３へのＶＰＮ−Ｔｕｎｎｅｌ１を経由した通信について詳細を述べる。ＶＰＮ−Ｔｕｎｎｅｌ１のケースではＶＰＮ−Ｃｌｉｅｎｔ２→ＩＰ−ＶＰＮＧａｔｅｗａｙ２→インターネット→ＩＰ−ＶＰＮＧａｔｅｗａｙ→ＶＰＮＣｌｉｅｎｔ３の経路でアクセスしている。

ＶＰＮ−Ｔｕｎｎｅｌ１の場合のアクセス経路中のパケットフォーマットを図１３に示す。ＶＰＮ−Ｃｌｉｅｎｔ２→ＶＰＮ−Ｇａｔｅｗａｙ２間のアクセスに於いてはＩＰヘッダとペイロードから構成される（Ｌ２のＥｔｈｅｒヘッダは省略。以下同じ）最も単純なＩＰフォーマットで通信が行われている。ここで付与されるＩＰＨｅａｄｅｒ１のＩＰアドレスにはＩＰ−ＶＰＮＧａｔｅｗａｙ２内部のローカルなＩＰアドレスが割り当てられる。最も単純なＩＰトンネリングプロトコルの場合、最初に割り当てられたＩＰＨｅａｄｅｒ１の外側にインターネットで使用されるＩＰアドレスが割り当てられたＩＰＨｅａｄｅｒ２を更に付与することで実現される。

この場合、インターネット上での経路上においてＩＰＨｅａｄｅｒ１やＰａｙｌｏａｄの詳細を観察することが可能で、しかも経路上で偽のパケットで通信を試みることも容易である。そこで、盗聴を防ぐ意味で暗号技術が、偽造を防ぐ意味で認証技術が用いられる。ＩＰＳｅｃを処理するＩＰ−ＶＰＮＧａｔｅｗａｙではどの宛先のＩＰパケットにどのような暗号−認証アルゴリズムを適用するかが定義されている。認証＋暗号を用いるトンネリングモードのＩＰＳｅｃヘッダフォーマットを図１３に示す。元のＩＰヘッダとペイロードはＥＳＰＴｒａｉｌｅｒと併せて暗号化されるため、復号鍵がない限りインターネット上では元のＩＰパケットを類推することが困難となる。また、新たに作成されたＩＰヘッダとＡＨヘッダ、ＥＳＰヘッダが認証されるために、インターネット上でのパケットの改竄が困難となる。

このように、インターネット上でのパケットの安全性を高めた上でＩＰ−ＶＰＮＧａｔｅｗａｙ間の通信が行われるため、高度な攻撃が行われたとしても、その攻撃に見合った暗号−認証アルゴリズムを用いることで専用線と同等の安全性が提供できる。

パケット受信側のＩＰ−ＶＰＮＧａｔｅｗａｙ３では、ＩＰ−ＶＰＮＧａｔｅｗａｙ２で付与されたＩＰヘッダ、ＡＨ、ＥＳＰヘッダ及びＥＳＰＴｒａｉｌｅｒ、認証データが取り除かれる。そして、元のＩＰヘッダとペイロードが復号された上でＶＰＮ−Ｃｌｉｅｎｔ３に渡される。

このように通信することでＶＰＮ−Ｃｌｉｅｎｔ２とＶＰＮ−Ｃｌｉｅｎｔ３間におけるＩＰ通信はＩＰ−ＶＰＮＧａｔｅｗａｙやインターネットの存在を意識することが無く同じサブネット上のコンピュータとして扱うことが可能となる。

このようなアクセスはＳｅｒｖｅｒ−Ｃｌｉｅｎｔ間も同様でＶＰＮ−Ｔｕｎｎｅｌ２に於けるＶＰＮ−Ｃｌｉｅｎｔ５→ＶＰＮ−Ｓｅｒｖｅｒ１のＶＰＮ−Ｇａｔｅｗａｙも同様の働きをする。

しかし、インターネット上の端末であるＲｅｍｏｔｅＣｌｉｅｎｔからＶＰＮ内にアクセスするためにはＲｅｍｏｔｅＣｌｉｅｎｔ側にＶＰＮ−Ｇａｔｅｗａｙと同等の動作を行わせる必要がある。そのため、このような端末ではＶＰＮ内のネットワーク情報とインターネット上でのネットワーク情報の２つの情報を管理し、それぞれのＩＰヘッダを作成してカプセリングする必要がある。

また、ＲＦＣ２６６１ではデータリンク層に於けるＴｕｎｎｅｌｉｎｇプロトコルとしてＬ２ＴＰが提案されている。このプロトコルはＰＰＴＰプロトコルとＬ２Ｆプロトコルを基にしてＩＥＴＦが統合・策定したプロトコルでＩｎｔｅｒｎｅｔへのアクセスに対してＩＰアドレスの割り当てやユーザの認証を行いＶＰＮを構築するためのプロトコルである。Ｌ２ＴＰでは送信しようとする基のＩＰデータグラムの前にＰＰＰ（ＰｏｉｎｔｔｏＰｏｉｎｔＰｒｏｔｏｃｏｌ）ヘッダが付与される。このＰＰＰは元となるＩＰデータグラムのカプセリング、リンク制御（ＬＣＰ：ＬｉｎｋＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）、ネットワーク制御（ＮＣＰ：ＮｅｔｗｏｒｋＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌｓ）から構成されている。リンク制御には、データリンク層接続の確立、設定、検査等が含まれ、ネットワーク制御には、ネットワーク層プロトコル接続の確立や設定等が含まれる。更に、ＰＰＰヘッダの前にはＬ２ＴＰヘッダが付与される。Ｌ２ＴＰヘッダはセッションＩＤ、トンネルＩＤ、送受信シーケンス番号などが記述されており、複数のＶＰＮ経路を持つことが可能となっている。最後に元の送信フレームとＰＰＰヘッダ、Ｌ２ＴＰヘッダをＵＤＰ（Ｐｏｒｔ：１７０１）でカプセリングしてトンネリング用のＩＰヘッダをつける。

このようにしてユーザ認証と組み合わせることによってリモートクライアントからのアクセスに対してもＶＰＮを提供することが可能となる。

Ｌ２ＴＰとしては暗号化機能が提供されていないため、通常はＬ２ＴＰにＩＰＳｅｃのトランスポートモードを用いることによってトンネルの秘匿性を確保する。Ｌ２ＴＰで用いられるフォーマットを図１４に示す。

以上のようなトンネリングプロトコルを典型的な従来に於けるプロトコル処理システム（図１５）で実現するためには一番外側のＴＣＰ（ＵＤＰ）／ＩＰヘッダの作成は可能である。しかし、トンネリングされたプロトコルのハードウェア化は困難である。また、プロトコルプロセッサをシーケンシャルに接続してトンネリングプロトコルに対応することは可能ではあるがプロトコルフォーマットを動的に変えることは難しく、柔軟性に欠けるシステムといえる。

図１６にＩＰＳｅｃトンネリングプロトコルに対応したプロトコル処理システムの例を示す。ここではＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサとＭＡＣ装置の間にＩＰ／ＩＰＳｅｃプロトコルプロセッサを挿入し、ＩＰＳｅｃのトンネリングプロトコルを実現している。

特開２００４−１５５０４号公報

上記従来例に見られるプロトコル処理システムまたは方法では以下のような問題点がある。即ち、ＩＰＳｅｃトンネリングモードやＬ２ＴＰでは、プロトコルのトンネリング又はカプセリングのためにＩＰ層等、同じレイヤが多重化される場合、これらの様々なプロトコルフォーマットに対応するハードウェアを構成することが困難である。つまり、このような構成をしようとすると、ハード規模が増大し、柔軟性に乏しいシステムになってしまう。

本発明は上記問題点を解決するためになされたもので、ＴＣＰ（ＵＤＰ）／ＩＰプロトコルの生成および解析を行うＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサと、プロトコルプロセッサが作成したパケットを一時的に保持し、保持したパケットを予め指示された宛先デバイスへ転送することが出来る通信バッファと、前記予め指示された宛先デバイスに対応したプロトコル情報を格納した複数のプロトコルデータベースと、リンク層の処理を行うＭＡＣ装置と、ペイロードやヘッダ情報の伝送を行うＤＭＡ制御装置と、上位アプリケーションやプロトコル制御プログラムを実行させるためのＣＰＵと、前記ＣＰＵのプログラムの実体や、パケット情報を格納するためのシステムメモリから構成されるプロトコル処理システムであって、前記プロトコルプロセッサに各レイヤのヘッダ作成指示を与える際に作成済みパケットの宛先指示を与えることによって、プロトコルプロセッサは宛先に応じたプロトルコデータベースへの検索を行ってヘッダを作成すると共に、作成終了したパケット情報を宛先指示に基づきＭＡＣ出力するか、又はシステムメモリ中の任意のアドレスへ書き戻すことを特徴とするプロトコル処理システム等、を提供する。

本発明によれば、プロトコル処理システムに於いてメディアに出力する前段に通信バッファを設け、通信バッファから他の装置への出力手段、他の装置からの入力手段を設けることでＩＰトンネリングプロトコルに柔軟に対応することが可能となる。
このことからＩＰＳｅｃにおけるトランスポートモードなどにおけるプロトコルフォーマットなど様々なトンネリングプロトコルの処理が可能となる。

以下、添付図面を参照して、本発明の実施形態について詳細に説明する。

（第１の実施形態）
先ず、本発明の第１の実施形態について説明する。図１は本発明の概念に基づく一実施形態を示すプロトコル処理システムを含むプロトコル処理装置送受信部の構成例を示したものである。

図１において、１０１はＴＣＰ（ＵＤＰ）／ＩＰのプロトコルプロセッサである。１０２は１０１で作成したパケットを位置に保存し、任意の宛先へ送信することができ、又はＭＡＣが受信したパケットを一次保存し、１０１のプロトコルプロセッサに伝送するための通信バッファである。１０３はパケットの送信元、宛先もしくはレイヤに応じたプロトコルのための各種データベース、１０４はリンク層の処理を行うＭＡＣ装置、１０５はヘッダやペイロードの転送を行うためのＤＭＡＣ装置である。１０６は上位層のアプリケーションプログラムの実行や各層のプロトコル制御を行うためのＣＰＵである。１０７は前記ＣＰＵのアプリケーションの実体やプロトコル制御プログラムが格納されるシステムメモリ、１０８は各種デバイスが相互に接続されるための共有バスである。

図３は本発明の請求項１の概念に基づく一実施形態を示すプロトコル処理システムに用いられる送信パケットディスクリプタである。送信パケットディスクリプタはシステムメモリ内に蓄積されているパケットの一部、又は全部を構成するものを示すもので、データの先頭アドレス、データ長、送信先、送信パケットディスクリプタの連結情報等から構成される。

プロトコル処理システムにおける解析情報やパケット情報等が格納されるもので、格納先の先頭アドレス、データ長の他、使用プロトコル等から構成される。

さて、上記プロトコル処理システムにおいてペイロードを送信、受信する場合についてそれぞれ説明する。先ず、送信したいペイロードがシステムメモリ上に存在したとする。

図４に示すようにシステムメモリ上に送信したいペイロード（ｐａｙｌｏａｄ１、ｐａｙｌｏａｄ２、ｐａｙｌｏａｄ３）が夫々ＡｄｄｒｅｓｓＡ、ＡｄｄｒｅｓｓＢ、ＡｄｄｒｅｓｓＣを先頭とするアドレスに断片化して配置されていたとする。この条件下で、これらのペイロードをひとまとめにしてパケットとして送信する場合、送信パケットディスクリプタにそれぞれの断片領域の送信アドレス、データ長、宛先、リンク情報を一連の送信パケットディスクリプタとして記述する。

送信アドレスフィールドにはシステムメモリが管理しているアドレス情報が、断片化されたパケットの先頭アドレスが記述される。続いてその先頭アドレスからの長さがデータ長フィールドに、宛先フィールドにはプロトコルプロセッサで生成したパケットが通信バッファを経て送られるデバイス名を記述する。

リンク情報にはそのディスクリプタに続くディスクリプタが存在する場合には“Ｎｅｘｔ”、存在しない場合には“Ｅｎｄ”を記述する。即ち、先頭又は“Ｅｎｄ”が記述された次のディスクリプタから、次の“Ｅｎｄ”が記述されたディスクリプタまでがひとつのパケットを構成する送信パケットディスクリプタとなる。

メモリマップと、送信されるパケット、送信パケットディスクリプタテーブルの対応を図５に示す。

パケットとして構成するために先頭のディスクリプタにはヘッダ領域を記述する。但し、１０１プロトコルプロセッサで全てのヘッダを作成する場合にはヘッダ領域は省略される場合がある。続いて、送信されるパケットのペイロードが分割して記述する。分割されていない場合はひとつのディスクリプタを記述するのみで充分である。このようにして送信パケットディスクリプタテーブルを１０６ＣＰＵが読み取り、それぞれのディスクリプタに対して１０７システムメモリから１０１プロトコルプロセッサにＤＭＡを行うように１０５ＤＭＡＣを１０６ＣＰＵが制御する。

その際、システムメモリ上のヘッダ又はペイロードと共に、ディスクリプタの構成要件である宛先フィールドも併せてプロトコルプロセッサ１０１に送信する。リンク情報“Ｅｎｄ”のディスクリプタまで送信が終了すると、プロトコルプロセッサ１０１は宛先に合わせたプロトコルデータベース１０３を参照しながらヘッダを作成してゆく。ヘッダの作成が終了すると、通信バッファ１０２にパケットとして送信し、予め決められた宛先へ送信する。図１に示した例では、リンク層制御装置であるＭＡＣ１０４又はシステムメモリ上の領域へと転送される。

この最初にプロトコルプロセッサを経由したパケットは図６に示すように一連のＩＰＨｅａｄｅｒ−ＴＣＰ（ＵＤＰ）Ｈｅａｄｅｒ及びｐａｙｌｏａｄから構成される単純なＩＰＰａｃｋｅｔである。

続いてカプセリングプロトコルを適用する場合の送信パケットディスクリプタの記述方式について説明する。ＩＰカプセリングプロトコルを適用したパケットを作成するためのメモリマップ、パケットフォーマットおよび送信パケットディスクリプタテーブルに付いて説明した図７を示す。この例ではすでにＨｅａｄｅｄとｐａｙｌｏａｄからなるパケットがメモリマップ上にイメージされている。４行目までの送信パケットディスクリプタテーブルから分かるように、図５で示したパケット作成事例では４行目までの宛先がＭＡＣになっているが、図７の例ではＡｄｒｓＥとなっている。

図７のディスクリプタの４行目までの実行が終了すると、同図のメモリマップで示したＡｄｄｒｅｓｓＥ上にプロトコルプロセッサで作成されたＨｅａｄｅｒとＰａｙｌｏａｄ１〜３から構成されるＩＰＰａｃｋｅｔが転送される。次にディスクリプタの５行目と６行目で新たなＨｅａｄｅｒ’とｐａｙｌｏａｄとしてパケットの作成対象としている。

これらを再度、プロトコルプロセッサ１０１に転送し、通信バッファ上に展開されたパケットフォーマットが図８に示すカプセリングパケットフォーマットとなる。このようにして送信パケットディスクリプタの記述のみでカプセリングの有無などのパケットフォーマットが定義することが可能である。

次に受信時の振る舞いについて詳細に記述する。ＰＨＹ（不図示）がメディアからパケットを受信すると、ＭＡＣ１０４に転送され、リンク層に於ける処理を行った後に通信バッファ１０２に転送される。通信バッファ１０２では受信したパケット情報と受信元のデバイス情報と共にプロトコルプロセッサ１０１に転送される。プロトコルプロセッサ１０１では受信元のデバイス情報があるためにメディアからのパケットであるということが認識されるために、それに適合したプロトコルデータベース１０３を参照することができる。プロトコルの解析が終了すると、プロトコルプロセッサ１０１はＣＰＵ１０６に対して割り込みをかけて通知するか、又はＣＰＵ１０６からの問い合わせに対して受信パケットが到着したことを通知する。ＣＰＵ１０６は、通知を受けると、プロトコルプロセッサ１０１に到着したパケット長やプロトコル情報を受け取り、受信パケットディスクリプタに記述する。

受信パケットディスクリプタテーブルの例を図９に示す。受信パケットディスクリプタは受信したパケット毎に処理が実行するためにひとつの受信パケットでひとつの受信パケットディスクリプタで記述される。図９の受信パケットディスクリプタの例ではテーブルの１行目ではカプセリングされていないためにＭＡＣから受信されたパケットはプロトコルプロセッサ１０１の解析結果と共に上位層に渡される。

しかしながら、２行目のディスクリプタで記述された受信パケットは最初に解析されて抽出されたＨｅａｄｅｒを取り除いた上で、再度、プロトコルプロセッサ１０１で解析するために、通信バッファ１０２へ転送される。その際に送信元はＡｄｄｒｅｓｓＨから最初の解析で抽出されたＨｅａｄｅｒを取り除いたＡｄｄｒｅｓｓＨ'として受信元が設定されて通信バッファに転送される。

再びプロトコルプロセッサ１０１にかけられたペイロードは受信元がＭＡＣではなく、ＡｄｄｒｅｓｓＨ’であることから、異なるプロトコルデータベースが選択され、そのデータベースに基づいた処理が行われる。このようにしてカプセリングされた受信パケットに於いても柔軟な解析が可能となる。

（第２の実施形態）
第１の実施形態では単純なカプセリングプロトコルについて説明を行ったが、実際にカプセリングプロトコルが使用されるＶＰＮ等のケースにおいては、従来例で説明したようにＩＰＳｅｃ等のセキュリティプロトコルが適用される場合が多い。

これは、カプセリングされたパケットはインターネット等の公衆ネットワークを使用して伝送するためである。つまり、ネットワーク上に悪意又は偶然によりカプセリングされたパケットを送受信する可能性が否定できないため、パケットを暗号化又は認証することで通信を確実なものとする。

図２にＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサとは別にＩＰＳｅｃプロトコルプロセッサを接続したブロック図を示す。図２の構成では第１の実施形態におけるブロック図から、更にＩＰＳｅｃプロトコルプロセッサ２０９を通信バッファと共有バスの間に接続している。ＩＰＳｅｃプロトコルプロセッサ２０９はＳｅｃｕｒｉｔｙＰｏｌｉｃｙＤａｔａＢａｓｅ２１０を送信相手毎に複数持ち、それぞれに合わせた暗号方式、認証方式をとることができる。

ＩＰＳｅｃでは、ＡＨ（ＡｕｔｈｅｎｔｉｃａｔｉｏｎＨｅａｄｅｒ）ヘッダとＥＳＰ（ＥｎｃｒｙｐｔＳｅｃｕｒｉｔｙＰａｙｌｏａｄ）ヘッダという２種類のヘッダがＩＰパケットに追加される。この２種類のヘッダの適用方法により、ＩＰＳｅｃ（ＡＨ）、ＩＰＳｅｃ（ＥＳＰ）、ＩＰＳｅｃ（ＡＨ＋ＥＳＰ）の３つの動作モードが存在し、それぞれにトランスポートモードとトンネリングモードが存在する。ＡＨヘッダは認証ヘッダともよばれ、ＩＰパケット全体にわたってパケットの確実性を保証する。ＥＳＰヘッダはペイロードの暗号化の他に認証の機能も持っており、暗号化と同時にＥＳＰヘッダ以降の認証が可能である。

ＥＳＰ認証を行った場合は認証データとしてパケット末尾にＥＳＰＡｕｔｈｅｎｔｉｃａｔｉｏｎＤａｔａを付加する。ＡＨ＋ＥＳＰで認証＋暗号化する場合はＥＳＰの認証機能を使用しないのでパケット末尾の認証データ：ＡｕｔｈｅｎｔｉｃａｔｉｏｎＤａｔａは付加しない。ＩＰＳｅｃ（ＥＳＰ）ではペイロード以降の暗号化及び認証であるために、ＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサに処理をかける以前にペイロードの暗号、認証処理を行うため、本実施例における処理フローとは直接に関与しないため省略する。

次に、図２のプロトコル処理システムに於いてＩＰＳｅｃパケットの送信までの手順について説明する。

先ず、ＩＰＳｅｃにおけるトランスポートモードに於けるＡＨヘッダを作成する場合の送信パケットディスクリプタの例を図１０に示す。内容的には第一の実施の形態で述べた図５の例とほぼ同一であるが、生成パケットの宛先がＩＰＳｅｃ（ＡＨ）となっている。この場合、一旦作成したＩＰパケットは全てＩＰＳｅｃプロトコルプロセッサ２０９に転送され、ＡＨヘッダが作成される。既に元となるＩＰパケットは通信バッファ２０２に蓄積されているのでＩＰＳｅｃプロトコルプロセッサ２０９からＡＨヘッダを通信バッファ２０２に転送することでトランスポートモードにおけるＩＰＳｅｃ（ＡＨ）パケットの送出ができる。

トンネリングモード（ＡＨ）の場合はＩＰトンネリングの動作に先のＩＰＳｅｃ（ＡＨ）の作成手順を重ねるだけである。このため、図１１に示した送信パケットディスクリプタのように、先ず、１〜４行目まででトンネリングプロトコルを実行するディスクリプタを記述する。次に、新ＩＰヘッダのディスクリプタ、最後に１〜４行目までのディスクリプタで作成したＩＰパケットをペイロードとしてこれらのカプセリングＩＰパケットをＩＰＳｅｃプロトコルプロセッサに転送する。このため、５、６行目のディスクリプタの宛先をＩＰＳｅｃ（ＡＨ）とする。

これにより、ＩＰＳｅｃプロトコルプロセッサ２０９において、ＩＰＳｅｃ（ＡＨ）の処理が行われる。そして、ＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサで行った処理と同様に宛先ＩＰアドレスに応じたＳｅｃｕｒｉｔｙＰｏｌｉｃｙＤａｔａｂａｓｅを使用して宛先に応じた認証アルゴリズムを使用することができる。その結果、作成されたＡＨヘッダは通信バッファ２０２へ転送され、トンネリングのためのＩＰＨｅａｄｅｒ’、ＡＨヘッダに続いてトンネルされるＩＰＰａｃｋｅｔが出力される。

以上、説明したようにＩＰＳｅｃ（ＡＨ）においてＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサが他のプロトコルプロセッサと協調してトンネリングプロトコルを処理する動作について説明した。本実施形態においても第１の実施形態よりさらに通信バッファにおけるＩＰＰａｃｋｅｔの入出力先をディスクリプタで制御することで柔軟にトンネリングプロトコルに対応できる。

なお、上述した実施の形態以外にもＩＰｖ６やＬ２ＴＰなどの様々なトンネリングプロトコルについて対応プロトコルプロセッサを搭載して実施したものも本発明の範疇に含まれる。

なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。

本発明の第１の実施形態に係るプロトコル処理システムの一例を示す図である。本発明の第２の実施形態に係るプロトコル処理システムの一例を示す図である。本発明の実施の形態に係る送信パケットディスクリプタテーブルの一例を示す図である。断片化された送信ペイロードデータのメモリマップを示す図である。メモリマップと送信パケットディスクリプタとパケットフォーマットの対応を説明した図である。ＴＣＰ（ＵＤＰ）／ＩＰのパケットフォーマットを示す図である。ＩＰカプセリングする場合にメモリマップと送信パケットディスクリプタとパケットフォーマットの対応を説明した図である。ＩＰカプセリングされたＩＰパケットフォーマットを示す図である。受信パケットディスクリプタテーブルとディスクリプタに対応したメモリマップを示す図である。本発明の第二の実施の形態にかかるメモリマップと送信パケットディスクリプタとパケットフォーマットの対応を説明した図である。ＩＰＳｅｃ（ＡＨ）における送信パケットディスクリプタとパケットフォーマットを示す図である。インターネットを介してＶＰＮトンネルを用いたネットワーク図である。ＩＰＳｅｃで使用されるプロトコルフォーマットを示す図である。Ｌ２ＴＰで使用されるプロトコルフォーマットを示す図である。従来例に於けるプロトコル処理システムの一例を示す図である。従来例に於けるＩＰＳｅｃプロトコル処理システムの一例を示す図である。

符号の説明

１０１：ＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサ
１０２：通信バッファ
１０３：プロトコルデータベース
１０４：ＭＡＣ（リンク層制御装置）
１０５：ＤＭＡＣ
１０６：ＣＰＵ
１０７：システムメモリ
１０８：共有バス
２０１：ＴＣＰ（ＵＤＰ）／ＩＰプロトコルプロセッサ
２０２：通信バッファ
２０３：プロトコルデータベース
２０４：ＭＡＣ（リンク層制御装置）
２０５：ＤＭＡＣ
２０６：ＣＰＵ
２０７：システムメモリ
２０８：共有バス
２０９：ＩＰＳｅｃプロトコルプロセッサ
２１０：セキュリティポリシーデータベース

Claims

ＴＣＰ（ＵＤＰ）／ＩＰプロトコルの生成及び解析を行うプロトコルプロセッサと、
前記プロトコルプロセッサが作成したパケットを一時的に保持し、保持したパケットを予め指示された宛先デバイスへ転送することができる通信バッファと、
前記予め指示された宛先デバイスに対応したプロトコル情報を格納した複数のプロトコルデータベースと、
リンク層の処理を行うＭＡＣ装置と、
ヘッダ情報の伝送を行うＤＭＡ制御装置と、
プロトコル制御プログラムを実行させるためのＣＰＵと、
前記ＣＰＵのプログラムの実体及びパケット情報を格納するためのシステムメモリと、
を有するプロトコル処理システムであって、
前記プロトコルプロセッサに各レイヤのヘッダ作成指示を与える際に作成済みパケットの宛先指示を与えることによって、プロトコルプロセッサは宛先に応じたプロトルコデータベースへの検索を行ってヘッダを作成すると共に、作成終了したパケット情報を宛先指示に基づきＭＡＣ出力するか、又はシステムメモリ中の任意のアドレスへ書き戻すことを特徴とするプロトコル処理システム。
トンネリングプロトコルとして、ＩＰＳｅｃの処理を実行することを特徴とする請求項１に記載のプロトコル処理システム。
トンネリングプロトコルとして、ＩＰｖ６の処理を実行することを特徴とする請求項１に記載のプロトコル処理システム。
トンネリングプロトコルとして、Ｌ２ＴＰの処理を実行することを特徴とする請求項１に記載のプロトコル処理システム。
ＴＣＰ（ＵＤＰ）／ＩＰプロトコルの生成及び解析を行うプロトコルプロセッサと、前記プロトコルプロセッサが作成したパケットを一時的に保持し、保持したパケットを予め指示された宛先デバイスへ転送することができる通信バッファと、前記予め指示された宛先デバイスに対応したプロトコル情報を格納した複数のプロトコルデータベースと、リンク層の処理を行うＭＡＣ装置と、ヘッダ情報の伝送を行うＤＭＡ制御装置と、プロトコル制御プログラムを実行させるためのＣＰＵと、前記ＣＰＵのプログラムの実体及びパケット情報を格納するためのシステムメモリと、を有するプロトコル処理システムにおけるプロトコル処理方法であって、
前記プロトコルプロセッサに各レイヤのヘッダ作成指示を与える際に作成済みパケットの宛先指示を与える工程と、
前記プロトコルプロセッサは宛先に応じたプロトルコデータベースへの検索を行ってヘッダを作成する工程と、
作成終了したパケット情報を宛先指示に基づきＭＡＣ出力するか、又はシステムメモリ中の任意のアドレスへ書き戻す工程と、
を有することを特徴とするプロトコル処理方法。
請求項５に記載の方法の各工程をコンピュータに実行させるためのプログラム。