(57)【要約】現存する多種多様なプロトコルに対して、それら一つ一つのパッケージを用意することなく、単一の装置でプロトコル変換を実現することのできる通信装置を実現するため、受信パケットに含まれるプロトコルの属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成し、該プロトコル処理順序データに基づき受信パケット中の複数のプロトコルを処理する。
2003075537.tif 000002
【特許請求の範囲】
【請求項１】
受信パケットに含まれるプロトコル属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、
該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを個別に処理するプロトコル変換部と、
を備えたことを特徴とする通信装置。
【請求項２】
請求の範囲１において、
該プロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を該プロトコル処理順序データとして生成し、プロトコル変換部は、該プロトコル総処理回数分だけ該受信パケット中に設定された複数のプロトコルを先頭から順次処理することを特徴とした通信装置。
【請求項３】
請求の範囲１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
【請求項４】
請求の範囲１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ処理部と、該ヘッダ識別部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
【請求項５】
請求の範囲１において、
該プロトコル処理順序データがプロトコル総処理回数を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該プロトコル処理部で先頭から順次処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
【請求項６】
請求の範囲２から５のいずれか一つにおいて、
該プロトコル属性が、該複数のプロトコルを先頭から順次処理するのではなく、該プロトコル属性に対応した所定の処理順序を必要としていることを示しているとき、該プロトコル処理順序データ生成部は、該プロトコル総処理回数に該所定の処理順序を付加した該プロトコル処理順序データを生成し、該プロトコル変換部は、該所定の処理順序に従って該複数のプロトコルを該プロトコル総処理回数分だけ処理することを特徴とした通信装置。
【請求項７】
請求の範囲１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
【請求項８】
請求の範囲１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ処理部と、該ヘッダ処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
【請求項９】
請求の範囲１において、
該プロトコル処理順序データが該プロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
【請求項１０】
請求の範囲６から９のいずれか一つにおいて、
該プロトコル属性がセキュリティ・ゲートウェイを示しているとき、該所定の処理順序に暗号化処理を含むことを特徴とした通信装置。
【請求項１１】
請求の範囲３又は７において、
該ヘッダ識別部が、対応するプロトコルを識別して対応する個々のプロトコル処理部に処理させることを特徴とした通信装置。
【請求項１２】
請求の範囲４又は８において、
該ヘッダ処理部が、各プロトコル毎にヘッダ識別部を有し、各ヘッダ識別部が、対応するプロトコルを識別して対応するプロトコル処理部に処理させることを特徴とした通信装置。
【請求項１３】
請求の範囲１から１２のいずれか一つにおいて、
該プロトコル属性が、送信元又は送信先のＩＰアドレスであることを特徴とした通信装置。
【請求項１４】
請求の範囲１から１３のいずれか一つにおいて、
該プロトコル処理順序データ生成部が、該プロトコル属性と該プロトコル処理順序データとを対応させたテーブルを有していることを特徴とした通信装置。
【請求項１５】
請求の範囲１から１４のいずれか一つにおいて、
該プロトコル変換部は、プロトコル処理後は該プロトコル処理順序データを除去する除去部を有することを特徴とした通信装置。
【発明の詳細な説明】
技術分野
本発明は通信装置に関し、特に通信プロトコルを用いてデータの送受信を行う通信装置に関するものである。
プロトコルとは通信方法を定めた規約のことであり、全７層のＯＳＩ参照モデルによって構成されている。各層は、上位層から受け取った送信データに対して、各プロトコルに従った処理情報をヘッダとして付加して下位層に渡す。また、下位層から受け取った受信データに対して、付加されているヘッダを抜き取り、その処理情報に従った処理を実行して上位層に渡す。
個々の通信装置は、それぞれ単独のプロトコルにしか対応していない。様々なプロトコルを実現する必要があるならば、それら個々のプロトコルに対応した通信装置を用意する必要がある。しかしながら、この方法では手間とコストが大幅にかかってしまう。従って、より容易にあらゆる種類のプロトコルを実現する手段が求められている。
背景技術
図１８（１）は、従来からよく知られているインターネット網を介して接続される通信システムを示している。図中、１０はパーソナルコンピュータ（以下、ＰＣと略称する。）、１１はＬ２ＴＰ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（以下、ＬＡＣと略称する。）、１２はＬ２ＴＰ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｅｒ（以下、ＬＮＳと略称する。）であり、１３は企業内網としてのＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）である。そして、ＬＡＮ１３には、ＰＣ１４およびメールサーバとしてのＰＣ１５が設置されている。
このような通信システムにおいて、ＰＣ１０は、パケットＰ１をＬＡＮ１３内のＰＣ１４に送るとき、まずＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）が提供するＬＡＣ１１との間にコネクションを確立するため、ペイロードに送信元であるＰＣ１０のＩＰアドレス（ａ）、及び送信先であるＰＣ１４のＩＰアドレス（ｂ）を付加したＩＰ（ａ→ｂ）フレームを生成し、これをＰＰＰ（Ｐｏｉｎｔ  Ｔｏ  Ｐｏｉｎｔ）プロトコルでカプセル化したパケットＰ１を送出する。
ＬＡＣ１１では、このコネクションから受信したＰＰＰプロトコルパケットをさらにＬＮＳ１２に送信するため、送信元であるＬＡＣ１１のＩＰアドレス（ｘ）及び送信先であるＬＮＳ１２のＩＰアドレス（ｙ）をパケットＰ１に付加した（ＩＰ（ｘ→ｙ）プロトコルでカプセル化した）パケットＰ２を宛先ネットワーク上のＬＮＳ１２に対してインターネット網ＩＮＥＴのトンネルを経由して送出する。
このパケットＰ２を受信したＬＮＳ１２は、パケットＰ２からＬＡＣ１１及びＬＮＳ１２のＩＰアドレスを除去するデカプセル化を行ったパケットＰ３をＬＡＮ１３へ送る。
そしてパケットＰ３は、ＬＡＮ１３を経由してメールサーバＰＣ１５に送られ、ＰＣ１５はパケットＰ３を宛先であるＰＣ１４に転送してデータの送信が完了する。
従って、ＬＮＳ１２は、同図（２）に示すように、ＩＰ（ｘ→ｙ）終端処理（ステップＳ２１）と、ＰＰＰ終端処理（ステップＳ２２）と、ＩＰ（ａ→ｂ）終端処理（ステップＳ２３）が必要となる。
この場合のＰＣ１０→ＬＮＳ１２のＰＰＰプロトコルセッション▲１▼では、ＰＣ１０のユーザーはＩＳＰが提供するＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｓｅｒｖｅｒ）（図示せず）との間にダイヤルアップなどの手段でコネクションを張っていた。この場合、例えば海外などの遠隔地からＬＡＮ１３にアクセスするときには、ＬＡＮ１３内のＰＰＰサーバにダイヤルアップしなければならずコストが嵩むことになる。
図１９は、図１８におけるＬＡＣやＬＮＳの代わりにセキュリティ・ゲートウェイＳＧ１，ＳＧ２を用いて企業内網のＬＡＮ１３ａと１３ｂとを接続したものである。この接続を行うためには、図１９（１）に示すトンネルモードと、同図（２）に示すトランスポートモードとが考えられる。
まず、トンネルモード（１）の場合には、ＬＡＮ１３ａにおけるアドレス（ａ）のＰＣ１６から、パケットＰ１がセキュリティ・ゲートウェイＳＧ１に対してＩＰ（ａ→ｂ）プロトコルにより送られる。そして、セキュリティ・ゲートウェイＳＧ１は、この受信したパケットＰ１に網掛で示すように暗号化を施すとともに、ＩＰ（ｘ→ｙ）プロトコルでカプセル化し、インターネット網ＩＮＥＴ上のセキュリティ・アソシエーションＳＡ１のトンネルを経由してセキュリティ・ゲートウェイＳＧ２に送る。
このセキュリティ・ゲートウェイＳＧ２では、同図（３）に示すようにまずＩＰ（ｘ→ｙ）終端処理（ステップＳ３１）を行い、さらに暗号化処理（ステップＳ３２）を行った後、ＩＰ（ｘ→ｙ）プロトコルを除去した（デカプセル化した）パケットＰ３をＬＡＮ１３ｂに送る。ＬＡＮ１３ｂでは、このパケットＰ３におけるＩＰ（ａ→ｂ）終端処理プロトコルに従い、アドレス（ｂ）のＰＣ１４にパケットＰ３が送られることとなる。
また、トランスポートモード（２）の場合には、ＰＣ１６から対向するＬＡＮ１３ｂにおけるＰＣ１４に対してパケットＰ４が送信される。このパケットＰ２はセキュリティ・ゲートウェイＳＧ１においてペイロードが暗号化処理された後、インターネットＩＮＥＴ及びセキュリティ・ゲートウェイＳＧ２を経由してＬＡＮ１３ｂにおけるアドレス（ｂ）のＰＣ１４に送られることとなる（セキュリティ・アソシエーションＳＡ２）。
このような図１９に示したセキュリティ・ゲートウェイを用いた通信システムにおいて、同図（３）に示したような処理を行うセキュリティ・アソシエーション（トンネルモード）ＳＡ１及びセキュリティ・アソシエーション（トランスポートモード）ＳＡ２に対してはこのセキュリティ・ゲートウェイＳＧ２は対応可能であるが、その他のモードには対応することはできない。
これを示したのが図２０である。すなわち、セキュリティ・ゲートウェイＳＧ２に対して、図１８に示したようなＰＣ１０及びＬＡＣ１１をＰＰＰセッション▲１▼またはＬ２ＰＰセッション▲２▼でも接続するような場合、ＬＡＣ１１から来たパケットは図１８に示したようにＬＮＳとして処理する必要があり、セキュリティ・ゲートウェイＳＧ１から来たものはセキュリティ・ゲートウェイとしてＩＰｓｅｃ（ＩＰ  ｓｅｃｕｒｉｔｙ）プロトコル処理する必要がある。
ＬＮＳの処理としては、ＩＰ，ＵＤＰ，Ｌ２ＴＰ，ＰＰＰ，ＩＰのプロトコル処理順序が必要になり（図３参照）、セキュリティ・ゲートウェイＳＧ２では、ＥＳＰ暗号解読やＩＰの処理順序が必要になる（同図参照）ので、固定したプロトコルしか備わっていない通信装置の場合には、これらの処理を実行することができない。
上記の場合には、ＰＰＰセッションやＬ２ＴＰセッション並びにセキュリティ・アソシエーションモードを例に取って説明したが、カプセル化はこの他にも種々存在する。
図２１はこのような種々のカプセル化例を示したものである。同図（１）は標準的なイーサネットのプロトコル、同（２）はモバイル端末や基地局などにおけるイーサネットのプロトコル、同（３）はＰＰＰｏＥ（ＡＤＳＬ等）に用いるプロトコル、同（４）及び（５）はＬ２．５のイーサネットにＭＰＬＳ（Ｍｕｌｔｉｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）を組み合わせたプロトコルである。
さらに同図（６）は、ＭＡＣレイヤでのトンネリングを行うためのプロトコル、同（７）はＬ２ＴＰプロトコル、同（８）は認証化（トンネルモード）を行うためのプロトコル、同（９）は認証化（トランスポートモード）を行うためのプロトコル、同（１０）は暗号化（トンネルモード）を行うためのプロトコル、同（１１）は暗号化（トランスポートモード）を行うためのプロトコル、同（１２）は鍵交換を示すプロトコル、同（１３）はＩＰレイヤでのトンネリングを行うためのプロトコル、同（１４）はＩＰｖ４網でのＩＰｖ６でのトンネリングを行うためのプロトコル、同（１５）は、ＩＰｖ６拡張ヘッダなどのプロトコル、同（１６）はグローバルアドレス／プライベートアドレスのトンネリングを行うためのプロトコル、そして、同（１７）はＩＰｖ６網でのＩＰｖ４のトンネリングを行うためのプロトコルである。
このような種々のカプセル化されたパケットが入力された従来の通信装置においては、固定したプロトコルしか備えていないので、フレキシブルに対応することができないこととなる。
また、図２２（３）に示すように、従来のＩＰｖ４及びＩＰｖ６処理においては、同図（１）及び（２）に示す如く、Ｌ２，Ｌ３，Ｌ４の処理順序又はこの逆でＩＰ処理を行っており、この順序のカプセル化しか処理できず（プロトコル変換ができず）、別の順序の処理がある場合には予め用意しておかなければならないか、あるいは別のハードウェアを用意する必要が生じてしまう。
さらに、この例ではＬ３処理が２回行われるが、予めハードウェア的なプロトコルの処理順序を確定していないと設計ができなかったし、また考えられる限りのプロトコルの処理順序を組み込んでおくとしても、使わないプロトコルの処理順序をも設計しておかなければならないという問題があった。
従って本発明は、現存する多種多様なプロトコルに対して、それら一つ一つのパッケージを用意することなく、単体でプロトコル変換を実現することのできる通信装置を提供することを目的とする。
発明の開示
上記の目的を達成するため、本発明に係る通信装置は、受信パケットに含まれるプロトコル属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを個別に処理するプロトコル変換部と、を備えたことを特徴としている（請求の範囲１）。
すなわち、本発明に係る通信装置は、プロトコル処理順序データ生成部が、受信したパケットからプロトコル属性を検出する。このプロトコル属性は、例えば送信元のＩＰアドレス又は送信先のＩＰアドレスである（請求の範囲１３）。そして、プロトコル処理順序データ生成部は、そのプロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成する。
プロトコル変換部は、プロトコル処理順序データ生成部から受けたプロトコル処理順序データに基づいて受信パケット中に設定されている複数のプロトコルの処理を行う。
このように、受信パケットに含まれるプロトコル属性がどのようなものであるかが判別できるので、このプロトコル属性に対応したプロトコルを用意しておけば、どのような受信パケットに対してもプロトコル処理順序データを生成することができ、このプロトコル処理順序データに基づいて受信したパケット中の複数のプロトコルを個別に処理することが可能となるので、単一の装置で複数のプロトコル変換を実現することができる。
従って、例えばＩＰｖ６のプロトコルで送信されたパケットを、ＩＰｖ４のプロトコル上で送受信することができるなど、複数のプロトコル変換を必要とする通信装置を容易に実現することができる。
また本発明では、上記のプロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を該プロトコル処理順序データとして生成し、プロトコル変換部は、該プロトコル総処理回数分だけ該受信パケット中に設定された複数のプロトコルを先頭から順次処理することができる（請求の範囲２）。
すなわち、プロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を上記のプロトコル処理順序データとして生成し、このプロトコル総処理回数に基づいてプロトコル変換部が受信パッケト中に設定された複数のプロトコルを先頭から順次実行する。
従って、プロトコル属性が受信パケット中の複数のプロトコルを先頭から順次処理することを示している場合において、そのプロトコル属性に対応したプロトコル総処理回数分だけ受信パッケト中のプロトコルを先頭から順次処理して行けば全てのプロトコルを正常に処理することが可能となる。
また本発明では、上記のプロトコル処理順序データ生成部は、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することができる（請求の範囲３）。
すなわち、この場合には、プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを受信パケットに付加してプロトコル変換部に送る。プロトコル変換部は、ヘッダ識別部でそのヘッダを識別して受信パケット中のプロトコルを先頭から順次プロトコル処理部で処理させ、このときのプロトコル処理回数をカウンタがカウントする。
そして、ヘッダ識別部は、カウンタによるプロトコル処理回数が上記のプロトコル総処理回数に達したときにプロトコル処理を終了するようにしている。
また本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ処理部と、該ヘッダ識別部でのプロトコル処理結果を識別し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えることできる（請求の範囲４）。
この場合には、上記と同様にプロトコル総処理回数を含んだヘッダを受信パケットに付加してプロトコル変換部に与えるが、このプロトコル変換部では、ヘッダ処理部が上記のヘッダを識別して受信パケット中のプロトコルを先頭から順次プロトコル処理部で処理させるときのプロトコル処理回数を処理完了部で蓄積し、プロトコル処理回数が上記のプロトコル総処理回数に達したときに処理完了部がプロトコル処理を終了させる点が異なっている。
また、本発明では、該プロトコル処理順序データがプロトコル総処理回数を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における該受信パケット中のプロトコルを該プロトコル処理部で先頭から順次処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えることができる（請求の範囲５）。
すなわち、この場合には、プロトコル変換部において、プロトコル処理順序データとしてのプロトコル総処理回数に基づいてデータ待機部で待機させた受信パケット中のプロトコルを、処理順序制御部がプロトコル処理部で先頭から順次処理させる。
そして、処理順序制御部は、プロトコル処理部でのプロトコル処理回数を蓄積し、このプロトコル処理回数が上記のプロトコル総処理回数に達したときプロトコル処理を終了させるようにしている。
また本発明では、該プロトコル属性が、該複数のプロトコルを先頭から順次処理するのではなく、該プロトコル属性に対応した所定の処理順序を必要としていることを示しているとき、該プロトコル処理順序データ生成部は、該プロトコル総処理回数に該所定の処理順序を付加した該プロトコル処理順序データを生成し、該プロトコル変換部は、該所定の処理順序に従って該複数のプロトコルを該プロトコル総処理回数分だけ処理することができる（請求の範囲６）。
すなわち、この場合には、プロトコル属性が上記とは異なり、複数のプロトコルを先頭から順次処理するのではなく、プロトコル属性に対応した所定の処理順序を必要としていることを示している場合、プロトコル総処理回数だけではプロトコル処理順序データとして不足している。
そこで、プロトコル処理順序データ生成部では、プロトコル総処理回数に、上記の所定の処理順序を付加したプロトコル処理順序データを生成する。この所定の処理順序に従ってプロトコル変換部は受信パケット中の複数のプロトコルをそのプロトコル総処理回数分だけ実行する。
これにより、受信したパケットに含まれる複数のプロトコルが先頭から順次処理するようなものではない場合でも、そのプロトコル属性に対応した所定の処理順序を予め用意しておけば、その所定の処理順序に従ってプロトコル総処理回数分だけ実行することでプロトコル変換を実現することが可能となる。
また本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することができる（請求の範囲７）。
すなわち、この場合には、上記の請求の範囲３において、プロトコル総処理回数だけでなくプロトコル属性に対応した所定の処理順序を含んだヘッダを受信パケットに付加する。プロトコル変換部では、請求の範囲３のように受信パケット中のプロトコルを先頭から順次処理するのではなく、上記の所定の処理順序に従ってプロトコル処理部で処理させる。
そして、このプロトコル処理部でのプロトコル処理回数をカウンタでカウントし、カウントしたプロトコル処理回数と上記のプロトコル総処理回数とを比較し、両者が一致したときにヘッダ識別部がプロトコル処理を終了するようにしている。
また、本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ処理部と、該ヘッダ処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えることができる（請求の範囲８）。
すなわち、この場合には、プロトコル属性に対応した所定の実行順序を必要としていることを前提して、この所定の処理順序とプロトコル総処理回数とを含んだヘッダを受信パケットに付加してプロトコル変換部に送る。
プロトコル変換部では、ヘッダ処理部が受信パケット中のプロトコルを所定の処理順序で個々のプロトコル処理部により実行させ、このときのプロトコル処理回数を処理完了部が蓄積し、且つプロトコル処理回数が上記のプロトコル総処理回数に達したとき処理完了部がプロトコル処理を終了させるようにしている。
また、本発明では、該プロトコル処理順序データが該プロトコル処理回数及び該プロトコル属性に対応した所定の処理順序を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることができる（請求の範囲９）。
すなわち、この場合には、やはりプロトコル属性に対応した所定の処理順序を必要としていることを前提として、プロトコル変換部では、そのプロトコル処理順序データに基づいてデータ待機部に待機させていた受信パケット中のプロトコルを、該処理順序制御部が該所定の処理順序でプロトコル処理部に実行させる。
そして、処理順序制御部は、プロトコル処理部でのプロトコル処理回数を蓄積し、このプロトコル処理回数が上記のプロトコル総処理回数に達したとき該プロトコル処理を終了させるようにしている。
なお、上記のプロトコル属性がセキュリティ・ゲートウェイを示しているとき、該所定の処理順序に暗号化処理を含ませることができる（請求の範囲１０）。
さらに、上記のヘッダ識別部は、対応するプロトコルを識別して対応する個々のプロトコル処理部に処理させることができる（請求の範囲１１）。
また、上記のヘッダ処理部は、各プロトコル処理部毎にヘッダ識別部を有し、各ヘッダ識別部が、対応するプロトコルを識別して対応するプロトコル処理部に処理させることができる（請求の範囲１２）。
さらに、上記のプロトコル処理順序データ生成部は、該プロトコル属性と該プロトコル処理順序データとを対応させたテーブルを備えることができる（請求の範囲１４）。
さらに、上記のプロトコル変換部は、プロトコル処理後は該プロトコル処理順序データを除去する除去部を有することができる（請求の範囲１５）。
発明を実施するための最良の形態
実施例（１）
図１は、図１８に示したＬＮＳ１２や、図１９に示したセキュリティ・ゲートウェイＳＧ２などに適用される本発明に係る通信装置の実施例（１）を示したものである。この通信装置は、インターネット網などからの受信パケットをラッチするＦｉＦｏ２１と、このＦｉＦｏ２１から出力された受信パケットにヘッダを付加するヘッダ付加部２２と、このヘッダ付加部２２から出力されたヘッダ付の受信パケットを入力してそのヘッダを識別するヘッダ識別部２３と、このヘッダ識別部２３で識別されたプロトコルに対応する個別プロトコル処理部２４ａ〜２４ｘを有するプロトコル処理部２４と、このプロトコル処理部２４でプロトコル処理されたときの処理回数をカウントする処理回数カウンタ２５と、このカウンタ２５が処理回数をヘッダ識別部２３に与えた結果、ヘッダ識別部２３が受信パケットの処理を完了したと判定したことを知らされる処理完了部２６と、処理完了時に受信パケットからヘッダを除去するヘッダ除去部２７とを備え、処理完了部２６からはデータ送出許可信号ＤＴＥがＦｉＦｏ２１に与えられるようになっている。
図２は、図１に示したヘッダ付加部２２の実施例（１）を示したものである。このヘッダ付加部２２は、ＦｉＦｏ２１からのパケットＰ２（図１８，１９のパケットＰ２参照）を格納するバッファ３１と、このバッファ３１に格納されたパケットＰ２における送信元ＩＰアドレスを抽出する送信元ＩＰアドレス抽出部３２と、送信元ＩＰアドレス抽出部３２で抽出された送信元ＩＰアドレスを元に処理順序ヘッダ情報を出力するプロトコル属性テーブル３３と、テーブル３３からの処理順序ヘッダ情報に基づいてヘッダを作成するヘッダ作成部３４、バッファ３１からパケットＰ２を入力してヘッダ作成部３４からのヘッダを組み込むヘッダ組込部３５とで構成されている。
図２に示したプロトコル属性テーブル３４の一実施例が図３に示されている。図示のように、このテーブルは、送信元ＩＰアドレス（３２ビット）とプロトコル属性と処理順序ヘッダ情報とで構成されており、送信元ＩＰアドレスから、処理順序ヘッダ情報としてのプロトコル処理回数とプロトコル総処理回数とプロトコルの処理順序とが読み出されるようになっている。
なお、送信元ＩＰアドレスの代わりに送信先ＩＰアドレスを用いても同様のテーブルとなる。
図４は、図１に示したヘッダ識別部２３の一実施例を示している。この実施例では、ヘッダ付加部２２からのヘッダが付加された受信パケットがバッファ４１に格納され、その中のヘッダのみがデコーダ４２に与えられるようになっている。デコーダ４２はＮ個のセレクタ４３＿１〜４４＿Ｎで構成されたセレクタ部４３に接続されており、これらＮ個のセレクタ４３＿１〜４３＿Ｎは同じＮ個のバッファ４４＿１〜４４＿Ｎで構成されたバッファ部４４に個々に接続されている。
そしてこれらのバッファ４４＿１〜４４＿Ｎはそれぞれプロトコル処理部２４を構成する個別プロトコル処理部２４ａ〜２４ｘ（図１参照）に接続されており、バッファ部４４の各出力はＮ：１セレクタ４５に接続され、その内の一つの出力がデコーダ４２の制御により、選択されて処理回数カウンタ２５をカウントアップし、その結果（ヘッダ）がバッファ４１に戻されるようになっている。
また、受信パケットはバッファ４１から、デコーダ４２の制御を受けるセレクタ４６を経由してバッファ４７に送られ、このバッファ４７から処理完了部２６を経由してヘッダ除去部２７に送られるようになっている。
図５は、図２に示したヘッダ作成部３６で作成されるヘッダの一実施例を示したものであり、図３に示した属性テーブルにおける「プロトコル現処理回数」と「プロトコル総処理回数」とＮ個の「処理プロトコル番号」が直列配置されて可変長ヘッダを構成している。
図６は、図１８に示したようなＬＮＳに図１の実施例を組み込んだ場合のプロトコル変換処理をシーケンスで示したものである。以下、この図６を参照して図１から図５に示した実施例（１）の動作を説明する。
まず、インターネット網等から図６（１）に示すパケットをＦｉＦｏ２１で受信し、さらにこの受信パケットをヘッダ付加部２２に送る。ヘッダ付加部２２では、図２に示すように、バッファ３１を経由して送信元ＩＰアドレス抽出部３２で受信パケットの送信元ＩＰアドレスを抽出する。
今、この受信パケットの送信元ＩＰアドレスが図３に示すように「２５５．２５５．２５５．０」である場合、この属性テーブル３３に示すようにプロトコル属性はＬＮＳ（Ｌ２ＴＰ）であることが分かる。
従って、この送信元ＩＰアドレスに基づいて属性テーブル３３からはプロトコル総処理回数“５”と現在のプロトコル処理回数“０”から成るヘッダがヘッダ作成部３４で作成され、ヘッダ組込部３５で受信パケットに組み込まれて、図６（２）に示すようなヘッダが付加された受信パケットとなる。
この受信パケットのペイロードには、図示の如く、ＩＰ（ｘ→ｙ），ＵＤＰ，Ｌ２ＴＰ，ＰＰＰ，ＩＰ（ａ→ｂ）の各プロトコルが付加設定されている。これは図３に示すプロトコル属性がＬＮＳの場合において、処理順序ヘッダ情報として示される“１”（ＩＰｖ４処理），“６”（ＵＤＰ処理），“７”（Ｌ２ＴＰ処理），“３”（ＰＰＰ処理），“１”（ＩＰｖ４処理）に対応している。
但し、この実施例ではこの受信パケットにはプロトコル総処理回数とプロトコル現処理回数が付加されるだけである。従って、この場合には、図５に示したヘッダでは第１〜Ｎ処理プロトコル番号は不用となる。
このようにしてヘッダが付加された受信パケットは、ヘッダ識別部２３に送られる。ヘッダ識別部２３では、まずバッファ４１に格納された後、その内のヘッダのみが図６（５）に示すように取り出されてデコーダ４２に与えられる。
デコーダ４２は、セレクタ部４３及び４６を制御するようにこれらと接続されており、入力したヘッダに基づき、最初はプロトコル総処理回数が“５”であり、現在のプロトコル処理回数“０”とは一致しないので、プロトコル処理を実行する必要があり、このためセレクタ部４３を制御してバッファ４１の受信パケットをバッファ部４４に転送する。
すなわち、デコーダ４２はプロトコル総処理回数のみを見ているので、例えばセレクタ部４３を図４における上から順々に指定して行くことが可能である。従って、まずセレクタ部４３の一番上側のセレクタ４３＿１が指定されたとすると、バッファ４１からの受信パケットはセレクタ４３＿１を経由してバッファ部４４のバッファ４４＿１に格納される。
バッファ４４＿１に格納された受信パケットは、図１に示すプロトコル処理部２４における個別プロトコル処理部２４ａ〜２４ｘのいずれかにより処理される。例えば、バッファ４４＿１には個別プロトコル処理部２４ａが対応しているとすると、受信パケットはこの個別プロトコル処理部２４ａによってプロトコル処理が実行される。
図６に示したＬＮＳ処理の例では、まずＩＰ終端処理が実行されることとなり（同図（３））、終端後は、同図（４）に示すように一つのプロトコル、すなわちＩＰ（ｘ→ｙ）プロトコル処理が完了したことになる。
このＩＰ処理後の受信パケットはバッファ４４＿１から、やはりデコーダ４２の制御下にあるセレクタ４５を経由して処理回数カウンタ２５に与えられ、カウンタ２５の値が“１”だけインクリメントされて、バッファ４１に戻される。
この結果、同図（５）に示すようにプロトコル総処理回数が“５”で、現在のプロトコル処理回数が“１”となったヘッダがバッファ４１において受信パケットに付加される。
この後、デコーダ４２は次にセレクタ４３＿２を指定し、このセレクタ４３＿２を経由してバッファ４１の受信パケットがバッファ４４＿２に送られ、同図（６）の状態から同図（７）に示すようにＵＤＰプロトコル処理部２４ｂによる終端処理が行われて、同図（８）に示すようなＵＤＰプロトコルが取り除かれた受信パケットとなる。
そして、この結果、やはり処理回数カウンタ２５が“１”だけインクリメントされてバッファ４１にヘッダ（同図（８）参照）として戻されるので、デコーダ４２のヘッダは同図（９）に示すようにプロトコル処理回数が“２”に更新される。
以下同様にして、ＬＮＳ処理における「Ｌ２ＴＰ処理」と「ＰＰＰ処理」と「ＩＰ（ａ→ｂ）処理」とが同図（１０）〜（２０）に示すとおり実行される。そして、同図（２０）に示すようにプロトコル総実行回数と現在のプロトコル処理回数とが共に“５”となって等しくなった時、プロトコル処理は完了したことを示している。
そこで、デコーダ４２は今度は、セレクタ４６を制御することによりバッファ４１の受信パケットをバッファ４７に送り、そこからさらに処理完了部２６に送る。処理完了部２６は次のデータ送出許可信号ＤＴＥをＦｉＦｏ２１に送ると共に、同図（２０）に示したパケットをヘッダ除去部２７に送ると、ヘッダ除去部２７では、同図（２１）に示すようなヘッダ除去後のパケットを出力することになる。
なお、この実施例では、データ送出許可信号ＤＴＥをＦｉＦｏ２１に送って次の受信パケットの取込を行っているが、これに限らず、ヘッダ識別部２３自身でパケットの取込を逐次行ってもよい。
図７に示すシーケンス図は、図６に示したＬＮＳ処理ではなく、図１８に示したようなＬＡＣに図１の実施例を組み込んだ場合のプロトコル総処理回数制御を示したものである。
この図７の処理例と図６の処理例は、図３の属性テーブルから分かるように、ＬＡＣ処理の場合にはプロトコル総処理回数が“４”であり、ＬＮＳより“１”だけ少ないことが異なっている。従って、ヘッダの生成においては、図７（２）に示すように総実行回数を“４”として現在のプロトコル処理回数が“４”になるまで実行すると、処理後のパケットは同図（１９）に示すようになる。すなわち、最後のＩＰ（ａ→ｂ）のプロトコル処理が実行されないことになる。
その他の処理は、図６と同様である。
この実施例（１）において、図６及び図７に例示したように受信パケットに付加するヘッダがプロトコル総処理回数と現在のプロトコル処理回数のみから成る場合は、前述の如くプロトコル処理を受信パケットの先頭から順次実行すれば良いことを前提にしている。
しかしながら、図８及び図９に示すように単にプロトコル総処理回数分だけ実行したのでは処理ができない場合が存在する。
まず、図８の例においては、同図（１）の受信パケットに対してヘッダ（図示せず）を同図（２）に示すように生成したとすると、同図（３）に示すＩＰ（ｘ→ｙ）の終端処理プロトコルを実行した後、同図（４）のパケットを同図（５）に示す状態からＵＤＰ終端処理を行おうとした場合、ペイロードが暗号化されているためこのＵＤＰ終端処理が行えないことになる。
また、図９の例に示すように、同図（１）の受信パケットに対して同図（２）のヘッダを生成し、これに対して同図（３）において暗号解読処理を実行しようとすると、今度はペイロードが暗号化されていないため暗号解読処理後のパケットは処理できないことになる。
そこで、上記のようにプロトコル総処理回数だけではなく、暗号化処理などを考慮して所定の順序で処理を行う場合の順序処理データをヘッダに付加する必要がある。この場合の実施例が図１０に示されている。なお、この図１０の動作実施例の場合も上記の図１〜図５に示した構成は同様に適用できる。
まず、図１０（１）に示す受信パケットに対して、ヘッダ付加部２２では同図（２）に示すようにプロトコル総処理回数及びプロトコル処理回数に加えて、ペイロードが暗号化されていることに伴い、まず暗号化処理（図２１（１０）〜（１２）参照）のプロトコルを加えるとともにＩＰ（ｘ→ｙ）の処理プロトコルを加えたヘッダをヘッダ識別部２３に与える。
ヘッダ識別部２３では、ヘッダを識別してまず暗号解読処理を行うため、受信パケットを図１に示した例えばプロトコル処理部２４ｘに与えることにより同図（３）に示す受信パケットから同図（４）に示す暗号解読処理後のパケットが得られる。
このときのヘッダは、同図（５）に示すようにプロトコル処理回数が“１”にインクリメントされた形になる。
同図（６）に示すようにヘッダと受信パケットとがバッファ４１で組み合わされて、さらに同図（６）に示すように次の処理へ進むと、今度はプロトコル処理部２４の図示しない別の個別プロトコル処理部において、同図（７）に示す受信パケットがＩＰ（ｘ→ｙ）の終端処理を受けることにより同図（８）に示す受信パケットにデカプセル化される。
このときヘッダは、同図（９）に示すようにプロトコル処理回数が“２”となり、プロトコル総処理回数“２”と一致するので、ヘッダと受信パケットが合わされたパケットは処理完了部２６において処理終了とされ、さらにヘッダ除去部２７でヘッダが除去されて、同図（１１）に示す処理後のパケットが得られることになる。
図１１（１）は、ＩＰｖ４とＩＰｖ６のトンネル接続におけるヘッダ付加部の実施例を示したものである。すなわち、この実施例の場合には図２に示したような属性テーブルは必要なく、その代わりに、バッファ３１で受信した受信パケットにおけるバージョン情報を確認して処理ヘッダ情報を作成する処理ヘッダ情報作成部３６をヘッダ作成部３４の前に設けた点が異なっている。
すなわち、図１１（２）に示すようにＩＰｖ４とＩＰｖ６のトンネルは４つのパターンしかないので、処理順序ヘッダ情報作成部３６に予めこのバージョン情報を与えておけば、ヘッダ作成部３４は属性テーブルがなくてもヘッダを作成することができる。（但し、このようなＩＰｖ４／ｖ６処理専用のパケットにのみ適用されることは言うまでもない。）
このときのアルゴリズムを示したのが図１２である。すなわち、例えば図１１（２）の一番上の例の場合では、まずＭＡＣヘッダの識別を行い（ステップＳ１）、ＩＰヘッダの識別、バージョン（ｖ４／ｖ６）の確認、ヘッダ長の確認、パケット長の確認、ヘッダチェックサムなどを実行し（ステップＳ２）、ヘッダがＯＫかどうかを判定する（ステップＳ３）。
ステップＳ２の実行により、ヘッダがＯＫであれば、ＩＰｖ４か否かを判定し（ステップＳ４）、ＩＰｖ４のときには、プロトコル総処理回数を“１”だけインクリメントして処理プロトコルをＩＰｖ４とし、ＩＰｖ４でない場合には、プロトコル総処理回数を“１”だけインクリメントすると共に処理プロトコルをＩＰｖ６に設定する。
ヘッダがＯＫでないとき、すなわちヘッダが全てチェックが終わってペイロードが検出されたときにはヘッダ作成部３４に対して、プロトコルの種類とその現処理回数及び総処理回数を与える。このようにしてプロトコル総処理回数と現処理回数と実行すべき処理プロトコルをヘッダに組み込むことが可能となる。
実施例（２）
図１３は、本発明に係る通信装置の実施例（２）を示したものである。図１の実施例（１）では、プロトコル処理部２４が個別プロトコル処理部２４ａ〜２４ｘを並列した形で備えており、ヘッダ処理部２３でのヘッダ識別により、対応する個別プロトコル処理部２４ａ〜２４ｘを選択してプロトコル処理を実行しているが、図１３の実施例（２）の場合には、ヘッダ識別部７４ａ〜７４ｘを直列接続したヘッダ処理部７４を設け、各ヘッダ識別部７４ａ〜７４ｘに対して、プロトコル処理部７５を構成する個別プロトコル処理部７５ａ〜７５ｘを個々に相互接続させている点が主に異なった点である。
具体的には、受信パケットにヘッダを付加するヘッダ付加部７１と、このヘッダ付加部７１からＦｉＦｏ７３への入力を制御するＦｉＦｏ入力制御部７２と、ＦｉＦｏ７３から出力された受信パケットをヘッダ処理部７４を経由して入力しパケットが処理完了しているか否かを識別する処理完了部７６と、この処理完了部７６で完了識別された受信パケットのヘッダを除去するヘッダ除去部７７とを備え、処理完了部７６からＦｉＦｏ入力制御部７２へ処理経過の信号が与えられている。
図１４には、図１３に示した各ヘッダ識別部７４ａ〜７４ｘの具体的な実施例が示されている。すなわち、受信パケットはまずバッファ４１に入力され、その内のヘッダがデコーダ４２に与えられる点は図４の実施例と同様である。また、この場合、２つセレクタ４３と４６のみが設けてあり、それぞれデコーダ４２から制御を受けるようになっており且つバッファ４１から受信パケットを入力するようになっている。
そして、自分がヘッダ識別を行う場合には、デコーダ４２からセレクタ４３が選択されるため、バッファ４１の受信パケットはセレクタ４３を介してバッファ４４に送られる。そしてこのバッファ４４はプロトコル処理部７５における図示しない対応した個別プロトコル処理部に送られてプロトコル処理を行った後、再びバッファ４４に戻され、さらにセレクタ４８に送られる。
セレクタ４８はデコーダ４２から同様に制御を受け、この場合にはバッファ４４とセレクタ４６のうち、自分がヘッダ識別を行ったのであるからバッファ４４が選択され、受信パケットは次段のヘッダ識別部のバッファ４１に送られることとなる。
これを繰り返して行くことにより、全てのヘッダ識別を行い且つそれに対応した個別のプロトコル処理が実行されることとなる。
通常は、ヘッダ処理部７４は必要なヘッダ識別部を有し、各ヘッダ識別部は対応する個別プロトコル処理部に接続されているので、このヘッダ処理部７４を通過した受信パケットは処理完了部７６で処理完了したことが判明することとなり、その場合には次のパケットがＦｉＦｏ７３に入力されるようにＦｉＦｏ入力制御部７２で制御する。
これと共に、処理完了した受信パケットはヘッダ除去部７７でヘッダが除去されて出力されることとなる。
なお、この場合も、処理完了部７６からＦｉＦｏ入力制御部７２へ次のパケットを入力するための信号を与えなくてもヘッダ処理部７４は順次プロトコル処理を実行してもよい。
上記のような動作は、図６及び図７に示したプロトコル総処理回数に基づくプロトコル変換だけでなく、図１０に示したプロトコル総処理回数並びにプロトコル属性に対応した所定の処理順序をヘッダに付加して行う場合も同様に適用できる。
すなわち、図６の例では、ヘッダ付加部７１において同図（２）に示すようなヘッダが付加された受信パケットがＦｉＦｏ入力制御部７２及びＦｉＦｏ７３を経由してヘッダ処理部７４に送られる。
ヘッダ処理部７４では、ヘッダ識別部７４ａ〜７４ｘがそれぞれ、ＩＰ（ｘ→ｙ），ＵＤＰ，Ｌ２ＴＰ，ＰＰＰ，ＩＰ（ａ→ｂ）のプロトコル処理を行うように順次並べられているとすると、これに対してプロトコル処理部７５における個別プロトコル処理部７５ａ〜７５ｘも対応したプロトコル処理プログラムが格納されていることとなり、同図（３）以降に示す手順を、ヘッダ識別部７４ａ→７４ｘにおいて順次実行して行けばよい。
そして、このヘッダ処理部７４を通過した後は処理完了部７６で処理完了が検出され、ヘッダ除去部７７でヘッダが除去されたものが図６（２１）に示す処理後のパケットとなる。
これは、図７の例も同様である。
さらに、このような処理は、図１０に示した所定の処理順序をヘッダに加えた場合も同様である。
すなわち、同図（２）に示すようにヘッダにプロトコル総処理回数だけでなく、このときのプロトコル属性に対応した暗号処理及びＩＰ処理をヘッダに付加した受信パケットがヘッダ付加部７１からＦｉＦｏ入力制御部７２及びＦｉＦｏ７３を経由してヘッダ処理部７４に送られる。
このヘッダ処理部７４における各ヘッダ識別部７４ａ〜７４ｘは、暗号化処理のプロトコル又はＩＰ処理のプロトコルであるか否かを識別し、例えばヘッダ識別部７４ｘがそのプロトコルをデコーダ４２で例えば暗号処理であると識別した場合には、対応する個別プロトコル処理部７５ｘにその受信パケットを処理させ、その処理した受信パケットを入力してさらに次のヘッダ識別部に渡す。
これを順に繰り返すことにより、処理完了部７６では図１０（１１）に示す受信パケットが得られ、これをヘッダ除去部７７でヘッダを除去することにより処理後のパケットが得られることになる。
実施例（３）
図１５は本発明に係る通信装置の実施例（３）を示したものである。上記の実施例（１）及び（２）では、ヘッダ付加部を用いてプロトコル処理順序データとしてのヘッダを生成し且つ受信パケットに付加しているが、この実施例（３）では受信パケットにヘッダという形で付加するのではなく、プロトコル処理順序データとして処理順序データ生成部９２がこれを別個に生成し、且つ処理順序制御部９３に処理順序データＰＤとして与える。
また処理順序データ生成部９２からはパケットがデータ待機部９４に与えられ、処理順序制御部９３はプロトコル指示信号ＤＳをデータ待機部９４に与えることにより、データ待機部９４は対応するプロトコル処理部９５の個別プロトコル処理部９５ａ〜９５ｘに受信パケットを送って処理を行わせる。
その実行の終了信号ＦＳをプロトコル処理部９５が処理順序制御部９３に送ると共に、処理し終わった受信パケットはデータ待機部９４に保持しておく。
さらに次の処理プロトコルによってプロトコル処理部９５に処理を行わせるようにし、最終的に処理が終わった段階でデータ待機部９４から処理完了部９６を経由して処理パケットを得ようとするものである。
この場合の主にデータ待機部９４の構成例を示したものが図１６に示されている。
すなわち、ＦｉＦｏ９１より処理順序データ生成部９２を経由して送られて来たパケットはバッファ９４＿０に格納される。
一方、処理順序データ生成部９２は、処理順序制御部９３からの処理順序データ要求ＤＲを受けて処理順序データＰＤを与えるようになっており、処理順序制御部９３はセレクタ９４＿１〜９４＿ｙを制御してバッファ９４＿０に格納されている受信パケットを対応する個別プロトコル処理部９５ａ〜９５ｘに与えて処理を行わせ、この処理結果を同じセレクタを経由してバッファ９４＿０に戻すようにしている。
このような制御を繰り返すことにより、処理順序データＰＤに基づいて処理が終了した（プロトコル現処理回数＝プロトコル総処理回数）と判断した処理順序制御部９３はセレクタ９４＿ｙを経由してバッファ９４＿０から、処理が完了したパケットを処理完了部９６に与え、完了処理されたパケットを出力するようにしている。
図１７（１）には、図１６に示した処理順序制御部９３の処理アルゴリズムが示されており、これはセレクタ９４＿１〜９４＿ｘ及び９４＿ｙをどのように制御するかを示したものである。
すなわち、図１７（２）に例示した処理順序データＰＤを処理順序データ生成部９２から入力すると（ステップＳ１１）、プロトコル処理回数をｉ、プロトコル総処理回数をＮとして（ステップＳ１２）、プロトコル（ｉ）の処理を対応するセレクタ９４＿１〜９４＿ｘ（ｘ≧Ｎ）に指示する（ステップＳ１３）。
そして、プロトコル（ｉ）が終了したか否かを判定し、終了していないときはステップＳ１３に戻るが、プロトコル（ｉ）が終了したときにはｉ＝Ｎであるか否かを判定し、両者が不一致の場合にはｉを“１”だけインクリメントしてステップＳ１３に戻るが、ｉ＝Ｎであることが分かったときには処理完了として、セレクタ９４＿ｙを制御することによりバッファ９４＿０から受信パケットを処理完了部９６に与えることができる。
このように実施例（３）においても、図１７（２）に示すように処理順序データＰＤはプロトコル処理回数とプロトコル総処理回数並びに必要に応じて所定の順序に従ったプロトコルが格納されているので、上記の実施例（１）及び（２）でそれぞれ説明したのと同様のプロトコル処理を実行することができる。
すなわち、例えば図６のＬＮＳ処理の場合には図１７（２）に示す処理順序データＰＤはプロトコル処理回数とプロトコル総処理回数しか含まれていないが、プロトコル処理部９５における個別プロトコル処理部９５ａ〜９５ｘに対応したセレクタ９４＿１〜９４＿ｘにプロトコル実行指示ＤＳを順次与えれば、図６（３）から同図（２０）に示すプロトコル処理を順次実行することができる。
この処理の終了によりセレクタ９４＿ｙを介して最終的なパケットを９４＿０からヘッダ除去された形で処理完了部９６から得られることになる。
また、図１０に示す所定の処理順序データを用いる場合は、図１７（２）に示す処理順序データＰＤそのものであるので、これが適用できることは言うまでもない。
以上説明したように本発明に係る通信装置によれば、受信パケットに含まれヘッダ識別部７４ａ〜７４ｘを直列接続したるプロトコルの属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを処理するプロトコル変換部とを備えたので、例えば図２０に示したような例において、従来であればセキュリティ・ゲートウェイＳＧ２にＬＮＳも配備し、いずれのモードまたはセッションにも対応できるようにしなければならないが、一つの装置においてあらゆるプロトコルに対応することができ、考えられる全てのパケットの受信に一つの装置で対応することが可能となる。
【図面の簡単な説明】
図１は、本発明に係る通信装置の実施例（１）を示したブロック図である。
図２は、本発明に係る通信装置に用いられるヘッダ付加部の実施例（１）を示したブロック図である。
図３は、図２に示したヘッダ付加部におけるプロトコル属性テーブルを示した図である。
図４は、本発明に係る通信装置の実施例（１）に用いられるヘッダ識別部の実施例を示したブロック図である。
図５は、本発明に係る通信装置に用いられるプロトコル処理順序データとして受信パケットに付加されるヘッダの実施例を示した図である。
図６は、本発明に係る通信装置の各実施例において、プロトコル処理回数制御のみを実行するＬＮＳの処理シーケンスを示した図である。
図７は、本発明に係る通信装置の各実施例において、プロトコル処理回数制御のみを実行するＬＡＣの処理シーケンスを示した図である。
図８は、図６及び図７に示すようなプロトコル総処理回数のみでプロトコル変換を行った場合の問題点を説明するためのシーケンス図（１）である。
図９は、図６及び図７に示すようなプロトコル総処理回数のみでプロトコル変換を行った場合の問題点を説明するためのシーケンス図（２）である。
図１０は、本発明に係る通信装置の各実施例において、上記のようにプロトコル総処理回数に加えて所定の処理順序をヘッダに付加した場合の実施例を示したシーケンス図である。
図１１は、本発明に係る通信装置の実施例に用いられるヘッダ付加部の実施例（２）を説明するためのブロック図である。
図１２は、図１１に示した処理順序ヘッダ情報作成部の動作フローチャート図である。
図１３は、本発明に係る通信装置の実施例（２）を示したブロック図である。
図１４は、図１３に示したヘッダ処理部における各ヘッダ識別部の実施例を示したブロック図である。
図１５は、本発明に係る通信装置の実施例（３）を示したブロック図である。
図１６は、図１５に示したデータ待機部を特に具体的に示したブロック図である。
図１７は、図１５及び１６に示した処理順序制御部の動作フローチャート図である。
図１８は、一般的に知られているインターネット網を経由したＰＰＰセッションとＬ２ＴＰセッションを示した通信システム図である。
図１９は、インターネット網を介してＩＰｓｅｃパケットを送る場合のトンネルモードとトランスポートモードを示した通信システム図である。
図２０は、図１９に加えて図１８に示したＰＰＰセッション及びＬ２ＴＰセッションを加えた場合の問題点を指摘するための図である。
図２１は、従来より知られているカプセル化したパケットの例を示した図である。
図２２は、ＩＰｖ４及びＩＰｖ６を処理する場合の従来から知られている方式を説明するためのブロック図である。
符号の説明
１０，１４，１５，１６，１７  ＰＣ
１１  ＬＡＣ（Ｌ２ＴＰ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）
１２  ＬＮＳ（Ｌ２ＴＰ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｅｒ）
１３，１３ａ，１３ｂ  ＬＡＮ
２１，７３，９１  ＦｉＦｏ
２２，７１  ヘッダ付加部
２３，７４ａ〜７４ｘ  ヘッダ識別部
２４，７５，９５  プロトコル処理部
２４ａ〜２４ｘ，７５ａ〜７５ｘ，９５ａ〜９５ｘ  個別プロトコル処理部
２５  処理回数カウンタ
２６，７６，９６  処理完了部
２７，７７  ヘッダ除去部
３１  バッファ
３２  送信元ＩＰアドレス抽出部
３３  属性テーブル
３４  ヘッダ作成部
３５  ヘッダ組込部
３６  処理順序ヘッダ情報作成部
７２  ＦｉＦｏ入力制御部
７４  ヘッダ処理部
９２  処理順序データ生成部
９３  処理順序制御部
９４  データ待機部
図中、同一符号は同一又は相当部分を示す。
【図１】
2003075537.tif 000003
【図２】
2003075537.tif 000004
【図３】
2003075537.tif 000005
【図４】
2003075537.tif 000006
【図５】
2003075537.tif 000007
【図６】
2003075537.tif 000008
【図７】
2003075537.tif 000009
【図８】
2003075537.tif 000010
【図９】
2003075537.tif 000011
【図１０】
2003075537.tif 000012
【図１１】
2003075537.tif 000013
【図１２】
2003075537.tif 000014
【図１３】
2003075537.tif 000015
【図１４】
2003075537.tif 000016
【図１５】
2003075537.tif 000017
【図１６】
2003075537.tif 000018
【図１７】
2003075537.tif 000019
【図１８】
2003075537.tif 000020
【図１９】
2003075537.tif 000021
【図２０】
2003075537.tif 000022
【図２１】
2003075537.tif 000023
【図２２】
2003075537.tif 000024
【手続補正書】
【提出日】平成16年6月14日(2004.6.14)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】受信パケットに含まれるプロトコル属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、
該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを個別に処理するプロトコル変換部と、
を備えたことを特徴とする通信装置。
【請求項２】請求項１において、
該プロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を該プロトコル処理順序データとして生成し、プロトコル変換部は、該プロトコル総処理回数分だけ該受信パケット中に設定された複数のプロトコルを先頭から順次処理することを特徴とした通信装置。
【請求項３】請求項１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
【請求項４】請求項１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ処理部と、該ヘッダ識別部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
【請求項５】請求項１において、
該プロトコル処理順序データがプロトコル総処理回数を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該プロトコル処理部で先頭から順次処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
【請求項６】請求項１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
【請求項７】請求項１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ処理部と、該ヘッダ処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
【請求項８】請求項１において、
該プロトコル処理順序データが該プロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
【請求項９】請求項１から８のいずれか一つにおいて、
該プロトコル属性が、送信元又は送信先のIPアドレスであることを特徴とした通信装置。
【請求項１０】請求項１から９のいずれか一つにおいて、
該プロトコル処理順序データ生成部が、該プロトコル属性と該プロトコル処理順序データとを対応させたテーブルを有していることを特徴とした通信装置。
【請求項１１】請求項１から１０のいずれか一つにおいて、
該プロトコル変換部は、プロトコル処理後は該プロトコル処理順序データを除去する除去部を有することを特徴とした通信装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】発明の詳細な説明
【補正方法】変更
【補正の内容】
【発明の詳細な説明】                                                    
【技術分野】
本発明は通信装置に関し、特に通信プロトコルを用いてデータの送受信を行う通信装置に関するものである。
プロトコルとは通信方法を定めた規約のことであり、全7層のOSI参照モデルによって構成されている。各層は、上位層から受け取った送信データに対して、各プロトコルに従った処理情報をヘッダとして付加して下位層に渡す。また、下位層から受け取った受信データに対して、付加されているヘッダを抜き取り、その処理情報に従った処理を実行して上位層に渡す。
個々の通信装置は、それぞれ単独のプロトコルにしか対応していない。様々なプロトコルを実現する必要があるならば、それら個々のプロトコルに対応した通信装置を用意する必要がある。しかしながら、この方法では手間とコストが大幅にかかってしまう。従って、より容易にあらゆる種類のプロトコルを実現する手段が求められている。
【背景技術】
図18(1)は、従来からよく知られているインターネット網を介して接続される通信システムを示している。図中、10はパーソナルコンピュータ（以下、PCと略称する。）、11はL2TP Access Control（以下、LACと略称する。）、12はL2TP Network Server（以下、LNSと略称する。）であり、13は企業内網としてのLAN（Local Area Network）である。そして、LAN13には、PC14およびメールサーバとしてのPC15が設置されている。
このような通信システムにおいて、PC10は、パケットP1をLAN13内のPC14に送るとき、まずISP(Internet Service Provider)が提供するLAC11との間にコネクションを確立するため、ペイロードに送信元であるPC10のIPアドレス(a)、及び送信先であるPC14のIPアドレス(b)を付加したIP(a→b)フレームを生成し、これをPPP(Point To Point)プロトコルでカプセル化したパケットP1を送出する。
LAC11では、このコネクションから受信したPPPプロトコルパケットをさらにLNS12に送信するため、送信元であるLAC11のIPアドレス(x)及び送信先であるLNS12のIPアドレス(y)をパケットP1に付加した（IP(x→y)プロトコルでカプセル化した）パケットP2を宛先ネットワーク上のLNS12に対してインターネット網INETのトンネルを経由して送出する。
このパケットP2を受信したLNS12は、パケットP2からLAC11及びLNS12のIPアドレスを除去するデカプセル化を行ったパケットP3をLAN13へ送る。
そしてパケットP3は、LAN13を経由してメールサーバPC15に送られ、PC15はパケットP3を宛先であるPC14に転送してデータの送信が完了する。
従って、LNS12は、同図(2)に示すように、IP(x→y)終端処理（ステップS21）と、PPP終端処理（ステップS22）と、IP(a→b)終端処理（ステップS23）が必要となる。
この場合のPC10→LNS12のPPPプロトコルセッション(1)では、PC10のユーザーはISPが提供するNAS（Network Access Server）（図示せず）との間にダイヤルアップなどの手段でコネクションを張っていた。この場合、例えば海外などの遠隔地からLAN13にアクセスするときには、LAN13内のPPPサーバにダイヤルアップしなければならずコストが嵩むことになる。
図19は、図18におけるLACやLNSの代わりにセキュリティ・ゲートウェイSG1,SG2を用いて企業内網のLAN13aと13bとを接続したものである。この接続を行うためには、図19(1)に示すトンネルモードと、同図(2)に示すトランスポートモードとが考えられる。
まず、トンネルモード(1)の場合には、LAN13aにおけるアドレス(a)のPC16から、パケットP1がセキュリティ・ゲートウェイSG1に対してIP(a→b)プロトコルにより送られる。そして、セキュリティ・ゲートウェイSG1は、この受信したパケットP1に網掛で示すように暗号化を施すとともに、IP(x→y)プロトコルでカプセル化し、インターネット網INET上のセキュリティ・アソシエーションSA1のトンネルを経由してセキュリティ・ゲートウェイSG2に送る。
このセキュリティ・ゲートウェイSG2では、同図(3)に示すようにまずIP(x→y)終端処理（ステップS31）を行い、さらに暗号化処理（ステップS32）を行った後、IP(x→y)プロトコルを除去した（デカプセル化した）パケットP3をLAN13bに送る。LAN13bでは、このパケットP3におけるIP(a→b)終端処理プロトコルに従い、アドレス(b)のPC14にパケットP3が送られることとなる。
また、トランスポートモード(2)の場合には、PC16から対向するLAN13ｂにおけるPC14に対してパケットP4が送信される。このパケットP2はセキュリティ・ゲートウェイSG1においてペイロードが暗号化処理された後、インターネットINET及びセキュリティ・ゲートウェイSG2を経由してLAN13ｂにおけるアドレス(b)のPC14に送られることとなる（セキュリティ・アソシエーションSA2）。
このような図19に示したセキュリティ・ゲートウェイを用いた通信システムにおいて、同図(3)に示したような処理を行うセキュリティ・アソシエーション（トンネルモード）SA1及びセキュリティ・アソシエーション（トランスポートモード）SA2に対してはこのセキュリティ・ゲートウェイSG2は対応可能であるが、その他のモードには対応することはできない。
これを示したのが図20である。すなわち、セキュリティ・ゲートウェイSG2に対して、図18に示したようなPC10及びLAC11をPPPセッション(1)またはL2PPセッション(2)でも接続するような場合、LAC11から来たパケットは図18に示したようにLNSとして処理する必要があり、セキュリティ・ゲートウェイSG1から来たものはセキュリティ・ゲートウェイとしてIPsec(IP security)プロトコル処理する必要がある。
LNSの処理としては、IP,UDP,L2TP,PPP,IPのプロトコル処理順序が必要になり（図3参照）、セキュリティ・ゲートウェイSG2では、ESP暗号解読やIPの処理順序が必要になる（同図参照）ので、固定したプロトコルしか備わっていない通信装置の場合には、これらの処理を実行することができない。
上記の場合には、PPPセッションやL2TPセッション並びにセキュリティ・アソシエーションモードを例に取って説明したが、カプセル化はこの他にも種々存在する。
図21はこのような種々のカプセル化例を示したものである。同図(1)は標準的なイーサネットのプロトコル、同(2)はモバイル端末や基地局などにおけるイーサネットのプロトコル、同(3)はPPPoE(ADSL等)に用いるプロトコル、同(4)及び(5)はL2.5のイーサネットにMPLS(Multiprotocol Label Switching)を組み合わせたプロトコルである。
さらに同図(6)は、MACレイヤでのトンネリングを行うためのプロトコル、同(7)はL2TPプロトコル、同(8)は認証化（トンネルモード）を行うためのプロトコル、同(9)は認証化（トランスポートモード）を行うためのプロトコル、同(10)は暗号化（トンネルモード）を行うためのプロトコル、同(11)は暗号化（トランスポートモード）を行うためのプロトコル、同(12)は鍵交換を示すプロトコル、同(13)はIPレイヤでのトンネリングを行うためのプロトコル、同(14)はIPv4網でのIPv6でのトンネリングを行うためのプロトコル、同(15)は、IPv6拡張ヘッダなどのプロトコル、同(16)はグローバルアドレス/プライベートアドレスのトンネリングを行うためのプロトコル、そして、同(17)はIPv6網でのIPv4のトンネリングを行うためのプロトコルである。
このような種々のカプセル化されたパケットが入力された従来の通信装置においては、固定したプロトコルしか備えていないので、フレキシブルに対応することができないこととなる。
また、図22(3)に示すように、従来のIPv4及びIPv6処理においては、同図(1)及び(2)に示す如く、L2,L3,L4の処理順序又はこの逆でIP処理を行っており、この順序のカプセル化しか処理できず（プロトコル変換ができず）、別の順序の処理がある場合には予め用意しておかなければならないか、あるいは別のハードウェアを用意する必要が生じてしまう。
さらに、この例ではL3処理が2回行われるが、予めハードウェア的なプロトコルの処理順序を確定していないと設計ができなかったし、また考えられる限りのプロトコルの処理順序を組み込んでおくとしても、使わないプロトコルの処理順序をも設計しておかなければならないという問題があった。
従って本発明は、現存する多種多様なプロトコルに対して、それら一つ一つのパッケージを用意することなく、単体でプロトコル変換を実現することのできる通信装置を提供することを目的とする。
【発明の開示】
上記の目的を達成するため、本発明に係る通信装置は、受信パケットに含まれるプロトコル属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを個別に処理するプロトコル変換部と、を備えたことを特徴としている（請求項1/付記1）。
すなわち、本発明に係る通信装置は、プロトコル処理順序データ生成部が、受信したパケットからプロトコル属性を検出する。このプロトコル属性は、例えば送信元のIPアドレス又は送信先のIPアドレスである（請求項9/付記13）。そして、プロトコル処理順序データ生成部は、そのプロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成する。
プロトコル変換部は、プロトコル処理順序データ生成部から受けたプロトコル処理順序データに基づいて受信パケット中に設定されている複数のプロトコルの処理を行う。
このように、受信パケットに含まれるプロトコル属性がどのようなものであるかが判別できるので、このプロトコル属性に対応したプロトコルを用意しておけば、どのような受信パケットに対してもプロトコル処理順序データを生成することができ、このプロトコル処理順序データに基づいて受信したパケット中の複数のプロトコルを個別に処理することが可能となるので、単一の装置で複数のプロトコル変換を実現することができる。
従って、例えばIPv6のプロトコルで送信されたパケットを、IPv4のプロトコル上で送受信することができるなど、複数のプロトコル変換を必要とする通信装置を容易に実現することができる。
また本発明では、上記のプロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を該プロトコル処理順序データとして生成し、プロトコル変換部は、該プロトコル総処理回数分だけ該受信パケット中に設定された複数のプロトコルを先頭から順次処理することができる（請求項2/付記2）。
すなわち、プロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を上記のプロトコル処理順序データとして生成し、このプロトコル総処理回数に基づいてプロトコル変換部が受信パッケト中に設定された複数のプロトコルを先頭から順次実行する。
従って、プロトコル属性が受信パケット中の複数のプロトコルを先頭から順次処理することを示している場合において、そのプロトコル属性に対応したプロトコル総処理回数分だけ受信パッケト中のプロトコルを先頭から順次処理して行けば全てのプロトコルを正常に処理することが可能となる。
また本発明では、上記のプロトコル処理順序データ生成部は、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することができる（請求項3/付記3）。
すなわち、この場合には、プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを受信パケットに付加してプロトコル変換部に送る。プロトコル変換部は、ヘッダ識別部でそのヘッダを識別して受信パケット中のプロトコルを先頭から順次プロトコル処理部で処理させ、このときのプロトコル処理回数をカウンタがカウントする。
そして、ヘッダ識別部は、カウンタによるプロトコル処理回数が上記のプロトコル総処理回数に達したときにプロトコル処理を終了するようにしている。
また本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ処理部と、該ヘッダ識別部でのプロトコル処理結果を識別し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えることできる（請求項4/付記4）。
この場合には、上記と同様にプロトコル総処理回数を含んだヘッダを受信パケットに付加してプロトコル変換部に与えるが、このプロトコル変換部では、ヘッダ処理部が上記のヘッダを識別して受信パケット中のプロトコルを先頭から順次プロトコル処理部で処理させるときのプロトコル処理回数を処理完了部で蓄積し、プロトコル処理回数が上記のプロトコル総処理回数に達したときに処理完了部がプロトコル処理を終了させる点が異なっている。
また、本発明では、該プロトコル処理順序データがプロトコル総処理回数を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における該受信パケット中のプロトコルを該プロトコル処理部で先頭から順次処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えることができる（請求項5/付記5）。
すなわち、この場合には、プロトコル変換部において、プロトコル処理順序データとしてのプロトコル総処理回数に基づいてデータ待機部で待機させた受信パケット中のプロトコルを、処理順序制御部がプロトコル処理部で先頭から順次処理させる。
そして、処理順序制御部は、プロトコル処理部でのプロトコル処理回数を蓄積し、このプロトコル処理回数が上記のプロトコル総処理回数に達したときプロトコル処理を終了させるようにしている。
また本発明では、該プロトコル属性が、該複数のプロトコルを先頭から順次処理するのではなく、該プロトコル属性に対応した所定の処理順序を必要としていることを示しているとき、該プロトコル処理順序データ生成部は、該プロトコル総処理回数に該所定の処理順序を付加した該プロトコル処理順序データを生成し、該プロトコル変換部は、該所定の処理順序に従って該複数のプロトコルを該プロトコル総処理回数分だけ処理することができる（付記6）。
すなわち、この場合には、プロトコル属性が上記とは異なり、複数のプロトコルを先頭から順次処理するのではなく、プロトコル属性に対応した所定の処理順序を必要としていることを示している場合、プロトコル総処理回数だけではプロトコル処理順序データとして不足している。
そこで、プロトコル処理順序データ生成部では、プロトコル総処理回数に、上記の所定の処理順序を付加したプロトコル処理順序データを生成する。この所定の処理順序に従ってプロトコル変換部は受信パケット中の複数のプロトコルをそのプロトコル総処理回数分だけ実行する。
これにより、受信したパケットに含まれる複数のプロトコルが先頭から順次処理するようなものではない場合でも、そのプロトコル属性に対応した所定の処理順序を予め用意しておけば、その所定の処理順序に従ってプロトコル総処理回数分だけ実行することでプロトコル変換を実現することが可能となる。
また本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することができる（請求項6/付記7）。
すなわち、この場合には、上記の請求項3において、プロトコル総処理回数だけでなくプロトコル属性に対応した所定の処理順序を含んだヘッダを受信パケットに付加する。プロトコル変換部では、請求項3のように受信パケット中のプロトコルを先頭から順次処理するのではなく、上記の所定の処理順序に従ってプロトコル処理部で処理させる。
そして、このプロトコル処理部でのプロトコル処理回数をカウンタでカウントし、カウントしたプロトコル処理回数と上記のプロトコル総処理回数とを比較し、両者が一致したときにヘッダ識別部がプロトコル処理を終了するようにしている。
また、本発明では、該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ処理部と、該ヘッダ処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えることができる（請求項7/付記8）。
すなわち、この場合には、プロトコル属性に対応した所定の実行順序を必要としていることを前提して、この所定の処理順序とプロトコル総処理回数とを含んだヘッダを受信パケットに付加してプロトコル変換部に送る。
プロトコル変換部では、ヘッダ処理部が受信パケット中のプロトコルを所定の処理順序で個々のプロトコル処理部により実行させ、このときのプロトコル処理回数を処理完了部が蓄積し、且つプロトコル処理回数が上記のプロトコル総処理回数に達したとき処理完了部がプロトコル処理を終了させるようにしている。
また、本発明では、該プロトコル処理順序データが該プロトコル処理回数及び該プロトコル属性に対応した所定の処理順序を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることができる（請求項8/付記9）。
すなわち、この場合には、やはりプロトコル属性に対応した所定の処理順序を必要としていることを前提として、プロトコル変換部では、そのプロトコル処理順序データに基づいてデータ待機部に待機させていた受信パケット中のプロトコルを、該処理順序制御部が該所定の処理順序でプロトコル処理部に実行させる。
そして、処理順序制御部は、プロトコル処理部でのプロトコル処理回数を蓄積し、このプロトコル処理回数が上記のプロトコル総処理回数に達したとき該プロトコル処理を終了させるようにしている。
なお、上記のプロトコル属性がセキュリティ・ゲートウェイを示しているとき、該所定の処理順序に暗号化処理を含ませることができる（付記10）。
さらに、上記のヘッダ識別部は、対応するプロトコルを識別して対応する個々のプロトコル処理部に処理させることができる（付記11）。
また、上記のヘッダ処理部は、各プロトコル処理部毎にヘッダ識別部を有し、各ヘッダ識別部が、対応するプロトコルを識別して対応するプロトコル処理部に処理させることができる（付記12）。
さらに、上記のプロトコル処理順序データ生成部は、該プロトコル属性と該プロトコル処理順序データとを対応させたテーブルを備えることができる（請求項10/付記14）。
さらに、上記のプロトコル変換部は、プロトコル処理後は該プロトコル処理順序データを除去する除去部を有することができる（請求項11/付記15）。
【発明を実施するための最良の形態】
実施例(1)
図1は、図18に示したLNS12や、図19に示したセキュリティ・ゲートウェイSG2などに適用される本発明に係る通信装置の実施例(1)を示したものである。この通信装置は、インターネット網などからの受信パケットをラッチするFiFo21と、このFiFo21から出力された受信パケットにヘッダを付加するヘッダ付加部22と、このヘッダ付加部22から出力されたヘッダ付の受信パケットを入力してそのヘッダを識別するヘッダ識別部23と、このヘッダ識別部23で識別されたプロトコルに対応する個別プロトコル処理部24a〜24xを有するプロトコル処理部24と、このプロトコル処理部24でプロトコル処理されたときの処理回数をカウントする処理回数カウンタ25と、このカウンタ25が処理回数をヘッダ識別部23に与えた結果、ヘッダ識別部23が受信パケットの処理を完了したと判定したことを知らされる処理完了部26と、処理完了時に受信パケットからヘッダを除去するヘッダ除去部27とを備え、処理完了部26からはデータ送出許可信号DTEがFiFo21に与えられるようになっている。
図2は、図1に示したヘッダ付加部22の実施例(1)を示したものである。
このヘッダ付加部22は、FiFo21からのパケットP2（図18,19のパケットP2参照）を格納するバッファ31と、このバッファ31に格納されたパケットP2における送信元IPアドレスを抽出する送信元IPアドレス抽出部32と、送信元IPアドレス抽出部32で抽出された送信元IPアドレスを元に処理順序ヘッダ情報を出力するプロトコル属性テーブル33と、テーブル33からの処理順序ヘッダ情報に基づいてヘッダを作成するヘッダ作成部34、バッファ31からパケットP2を入力してヘッダ作成部34からのヘッダを組み込むヘッダ組込部35とで構成されている。
図2に示したプロトコル属性テーブル34の一実施例が図3に示されている。図示のように、このテーブルは、送信元IPアドレス（32ビット）とプロトコル属性と処理順序ヘッダ情報とで構成されており、送信元IPアドレスから、処理順序ヘッダ情報としてのプロトコル処理回数とプロトコル総処理回数とプロトコルの処理順序とが読み出されるようになっている。
なお、送信元IPアドレスの代わりに送信先IPアドレスを用いても同様のテーブルとなる。
図4は、図1に示したヘッダ識別部23の一実施例を示している。この実施例では、ヘッダ付加部22からのヘッダが付加された受信パケットがバッファ41に格納され、その中のヘッダのみがデコーダ42に与えられるようになっている。デコーダ42はN個のセレクタ43_1〜44_Nで構成されたセレクタ部43に接続されており、これらN個のセレクタ43_1〜43_Nは同じN個のバッファ44_1〜44_Nで構成されたバッファ部44に個々に接続されている。
そしてこれらのバッファ44_1〜44_Nはそれぞれプロトコル処理部24を構成する個別プロトコル処理部24a〜24x（図1参照）に接続されており、バッファ部44の各出力はN：1セレクタ45に接続され、その内の一つの出力がデコーダ42の制御により、選択されて処理回数カウンタ25をカウントアップし、その結果（ヘッダ）がバッファ41に戻されるようになっている。
また、受信パケットはバッファ41から、デコーダ42の制御を受けるセレクタ46を経由してバッファ47に送られ、このバッファ47から処理完了部26を経由してヘッダ除去部27に送られるようになっている。
図5は、図2に示したヘッダ作成部36で作成されるヘッダの一実施例を示したものであり、図3に示した属性テーブルにおける「プロトコル現処理回数」と「プロトコル総処理回数」とN個の「処理プロトコル番号」が直列配置されて可変長ヘッダを構成している。
図6は、図18に示したようなLNSに図1の実施例を組み込んだ場合のプロトコル変換処理をシーケンスで示したものである。以下、この図6を参照して図1から図5に示した実施例(1)の動作を説明する。
まず、インターネット網等から図6(1)に示すパケットをFiFo21で受信し、さらにこの受信パケットをヘッダ付加部22に送る。ヘッダ付加部22では、図2に示すように、バッファ31を経由して送信元IPアドレス抽出部32で受信パケットの送信元IPアドレスを抽出する。
今、この受信パケットの送信元IPアドレスが図3に示すように「255.255.255.0」である場合、この属性テーブル33に示すようにプロトコル属性はLNS(L2TP)であることが分かる。
従って、この送信元IPアドレスに基づいて属性テーブル33からはプロトコル総処理回数“5”と現在のプロトコル処理回数“0”から成るヘッダがヘッダ作成部34で作成され、ヘッダ組込部35で受信パケットに組み込まれて、図6(2)に示すようなヘッダが付加された受信パケットとなる。
この受信パケットのペイロードには、図示の如く、IP(x→y),UDP,L2TP,PPP,IP(a→b)の各プロトコルが付加設定されている。これは図3に示すプロトコル属性がLNSの場合において、処理順序ヘッダ情報として示される“1”（IPv4処理）,“6”（UDP処理）,“7”（L2TP処理）,“3”（PPP処理）,“1”（IPv4処理）に対応している。
但し、この実施例ではこの受信パケットにはプロトコル総処理回数とプロトコル現処理回数が付加されるだけである。従って、この場合には、図5に示したヘッダでは第1〜N処理プロトコル番号は不用となる。
このようにしてヘッダが付加された受信パケットは、ヘッダ識別部23に送られる。ヘッダ識別部23では、まずバッファ41に格納された後、その内のヘッダのみが図6(5)に示すように取り出されてデコーダ42に与えられる。
デコーダ42は、セレクタ部43及び46を制御するようにこれらと接続されており、入力したヘッダに基づき、最初はプロトコル総処理回数が“5”であり、現在のプロトコル処理回数“0”とは一致しないので、プロトコル処理を実行する必要があり、このためセレクタ部43を制御してバッファ41の受信パケットをバッファ部44に転送する。
すなわち、デコーダ42はプロトコル総処理回数のみを見ているので、例えばセレクタ部43を図4における上から順々に指定して行くことが可能である。従って、まずセレクタ部43の一番上側のセレクタ43_1が指定されたとすると、バッファ41からの受信パケットはセレクタ43_1を経由してバッファ部44のバッファ44_1に格納される。
バッファ44_1に格納された受信パケットは、図1に示すプロトコル処理部24における個別プロトコル処理部24a〜24xのいずれかにより処理される。例えば、バッファ44_1には個別プロトコル処理部24aが対応しているとすると、受信パケットはこの個別プロトコル処理部24ａによってプロトコル処理が実行される。
図6に示したLNS処理の例では、まずIP終端処理が実行されることとなり（同図(3)）、終端後は、同図(4)に示すように一つのプロトコル、すなわちIP(x→y)プロトコル処理が完了したことになる。
このIP処理後の受信パケットはバッファ44_1から、やはりデコーダ42の制御下にあるセレクタ45を経由して処理回数カウンタ25に与えられ、カウンタ25の値が“1”だけインクリメントされて、バッファ41に戻される。
この結果、同図(5)に示すようにプロトコル総処理回数が“5”で、現在のプロトコル処理回数が“1”となったヘッダがバッファ41において受信パケットに付加される。
この後、デコーダ42は次にセレクタ43_2を指定し、このセレクタ43_2を経由してバッファ41の受信パケットがバッファ44_2に送られ、同図(6)の状態から同図(7)に示すようにUDPプロトコル処理部24bによる終端処理が行われて、同図(8)に示すようなUDPプロトコルが取り除かれた受信パケットとなる。
そして、この結果、やはり処理回数カウンタ25が“1”だけインクリメントされてバッファ41にヘッダ（同図(8)参照）として戻されるので、デコーダ42のヘッダは同図(9)に示すようにプロトコル処理回数が“2”に更新される。
以下同様にして、LNS処理における「L2TP処理」と「PPP処理」と「IP(a→b)処理」とが同図(10)〜(20)に示すとおり実行される。そして、同図(20)に示すようにプロトコル総実行回数と現在のプロトコル処理回数とが共に“5”となって等しくなった時、プロトコル処理は完了したことを示している。
そこで、デコーダ42は今度は、セレクタ46を制御することによりバッファ41の受信パケットをバッファ47に送り、そこからさらに処理完了部26に送る。処理完了部26は次のデータ送出許可信号DTEをFiFo21に送ると共に、同図(20)に示したパケットをヘッダ除去部27に送ると、ヘッダ除去部27では、同図(21)に示すようなヘッダ除去後のパケットを出力することになる。
なお、この実施例では、データ送出許可信号DTEをFiFo21に送って次の受信パケットの取込を行っているが、これに限らず、ヘッダ識別部23自身でパケットの取込を逐次行ってもよい。
図7に示すシーケンス図は、図6に示したLNS処理ではなく、図18に示したようなLACに図1の実施例を組み込んだ場合のプロトコル総処理回数制御を示したものである。
この図7の処理例と図6の処理例は、図3の属性テーブルから分かるように、LAC処理の場合にはプロトコル総処理回数が“4”であり、LNSより“1”だけ少ないことが異なっている。従って、ヘッダの生成においては、図7(2)に示すように総実行回数を“4”として現在のプロトコル処理回数が“4”になるまで実行すると、処理後のパケットは同図(19)に示すようになる。すなわち、最後のIP(a→b)のプロトコル処理が実行されないことになる。
その他の処理は、図6と同様である。
この実施例(1)において、図6及び図7に例示したように受信パケットに付加するヘッダがプロトコル総処理回数と現在のプロトコル処理回数のみから成る場合は、前述の如くプロトコル処理を受信パケットの先頭から順次実行すれば良いことを前提にしている。
しかしながら、図8及び図9に示すように単にプロトコル総処理回数分だけ実行したのでは処理ができない場合が存在する。
まず、図8の例においては、同図(1)の受信パケットに対してヘッダ（図示せず）を同図(2)に示すように生成したとすると、同図(3)に示すIP(x→y)の終端処理プロトコルを実行した後、同図(4)のパケットを同図(5)に示す状態からUDP終端処理を行おうとした場合、ペイロードが暗号化されているためこのUDP終端処理が行えないことになる。
また、図9の例に示すように、同図(1)の受信パケットに対して同図(2)のヘッダを生成し、これに対して同図(3)において暗号解読処理を実行しようとすると、今度はペイロードが暗号化されていないため暗号解読処理後のパケットは処理できないことになる。
そこで、上記のようにプロトコル総処理回数だけではなく、暗号化処理などを考慮して所定の順序で処理を行う場合の順序処理データをヘッダに付加する必要がある。この場合の実施例が図10に示されている。なお、この図10の動作実施例の場合も上記の図1〜図5に示した構成は同様に適用できる。
まず、図10(1)に示す受信パケットに対して、ヘッダ付加部22では同図(2)に示すようにプロトコル総処理回数及びプロトコル処理回数に加えて、ペイロードが暗号化されていることに伴い、まず暗号化処理（図21(10)〜(12)参照）のプロトコルを加えるとともにIP(x→y)の処理プロトコルを加えたヘッダをヘッダ識別部23に与える。
ヘッダ識別部23では、ヘッダを識別してまず暗号解読処理を行うため、受信パケットを図1に示した例えばプロトコル処理部24xに与えることにより同図(3)に示す受信パケットから同図(4)に示す暗号解読処理後のパケットが得られる。
このときのヘッダは、同図(5)に示すようにプロトコル処理回数が“1”にインクリメントされた形になる。
同図(6)に示すようにヘッダと受信パケットとがバッファ41で組み合わされて、さらに同図(6)に示すように次の処理へ進むと、今度はプロトコル処理部24の図示しない別の個別プロトコル処理部において、同図(7)に示す受信パケットがIP(x→y)の終端処理を受けることにより同図(8)に示す受信パケットにデカプセル化される。
このときヘッダは、同図(9)に示すようにプロトコル処理回数が“2”となり、プロトコル総処理回数“2”と一致するので、ヘッダと受信パケットが合わされたパケットは処理完了部26において処理終了とされ、さらにヘッダ除去部27でヘッダが除去されて、同図(11)に示す処理後のパケットが得られることになる。
図11(1)は、IPv4とIPv6のトンネル接続におけるヘッダ付加部の実施例を示したものである。すなわち、この実施例の場合には図2に示したような属性テーブルは必要なく、その代わりに、バッファ31で受信した受信パケットにおけるバージョン情報を確認して処理ヘッダ情報を作成する処理ヘッダ情報作成部36をヘッダ作成部34の前に設けた点が異なっている。
すなわち、図11(2)に示すようにIPv4とIPv6のトンネルは4つのパターンしかないので、処理順序ヘッダ情報作成部36に予めこのバージョン情報を与えておけば、ヘッダ作成部34は属性テーブルがなくてもヘッダを作成することができる。（但し、このようなIPv4/v6処理専用のパケットにのみ適用されることは言うまでもない。）
このときのアルゴリズムを示したのが図12である。すなわち、例えば図11(2)の一番上の例の場合では、まずMACヘッダの識別を行い(ステップS1)、IPヘッダの識別、バージョン(v4/v6)の確認、ヘッダ長の確認、パケット長の確認、ヘッダチェックサムなどを実行し(ステップS2)、ヘッダがOKかどうかを判定する（ステップS3）。
ステップS2の実行により、ヘッダがOKであれば、IPv4か否かを判定し（ステップS4）、IPv4のときには、プロトコル総処理回数を“1”だけインクリメントして処理プロトコルをIPv4とし、IPv4でない場合には、プロトコル総処理回数を“1”だけインクリメントすると共に処理プロトコルをIPv6に設定する。
ヘッダがOKでないとき、すなわちヘッダが全てチェックが終わってペイロードが検出されたときにはヘッダ作成部34に対して、プロトコルの種類とその現処理回数及び総処理回数を与える。このようにしてプロトコル総処理回数と現処理回数と実行すべき処理プロトコルをヘッダに組み込むことが可能となる。
実施例(2)
図13は、本発明に係る通信装置の実施例(2)を示したものである。図1の実施例(1)では、プロトコル処理部24が個別プロトコル処理部24a〜24xを並列した形で備えており、ヘッダ処理部23でのヘッダ識別により、対応する個別プロトコル処理部24a〜24xを選択してプロトコル処理を実行しているが、図13の実施例(2)の場合には、ヘッダ識別部74a〜74xを直列接続したヘッダ処理部74を設け、各ヘッダ識別部74a〜74xに対して、プロトコル処理部75を構成する個別プロトコル処理部75a〜75xを個々に相互接続させている点が主に異なった点である。
具体的には、受信パケットにヘッダを付加するヘッダ付加部71と、このヘッダ付加部71からFiFo73への入力を制御するFiFo入力制御部72と、FiFo73から出力された受信パケットをヘッダ処理部74を経由して入力しパケットが処理完了しているか否かを識別する処理完了部76と、この処理完了部76で完了識別された受信パケットのヘッダを除去するヘッダ除去部77とを備え、処理完了部76からFiFo入力制御部72へ処理経過の信号が与えられている。
図14には、図13に示した各ヘッダ識別部74a〜74xの具体的な実施例が示されている。すなわち、受信パケットはまずバッファ41に入力され、その内のヘッダがデコーダ42に与えられる点は図4の実施例と同様である。また、この場合、2つセレクタ43と46のみが設けてあり、それぞれデコーダ42から制御を受けるようになっており且つバッファ41から受信パケットを入力するようになっている。
そして、自分がヘッダ識別を行う場合には、デコーダ42からセレクタ43が選択されるため、バッファ41の受信パケットはセレクタ43を介してバッファ44に送られる。そしてこのバッファ44はプロトコル処理部75における図示しない対応した個別プロトコル処理部に送られてプロトコル処理を行った後、再びバッファ44に戻され、さらにセレクタ48に送られる。
セレクタ48はデコーダ42から同様に制御を受け、この場合にはバッファ44とセレクタ46のうち、自分がヘッダ識別を行ったのであるからバッファ44が選択され、受信パケットは次段のヘッダ識別部のバッファ41に送られることとなる。
これを繰り返して行くことにより、全てのヘッダ識別を行い且つそれに対応した個別のプロトコル処理が実行されることとなる。
通常は、ヘッダ処理部74は必要なヘッダ識別部を有し、各ヘッダ識別部は対応する個別プロトコル処理部に接続されているので、このヘッダ処理部74を通過した受信パケットは処理完了部76で処理完了したことが判明することとなり、その場合には次のパケットがFiFo73に入力されるようにFiFo入力制御部72で制御する。
これと共に、処理完了した受信パケットはヘッダ除去部77でヘッダが除去されて出力されることとなる。
なお、この場合も、処理完了部76からFiFo入力制御部72へ次のパケットを入力するための信号を与えなくてもヘッダ処理部74は順次プロトコル処理を実行してもよい。
上記のような動作は、図6及び図7に示したプロトコル総処理回数に基づくプロトコル変換だけでなく、図10に示したプロトコル総処理回数並びにプロトコル属性に対応した所定の処理順序をヘッダに付加して行う場合も同様に適用できる。
すなわち、図6の例では、ヘッダ付加部71において同図(2)に示すようなヘッダが付加された受信パケットがFiFo入力制御部72及びFiFo73を経由してヘッダ処理部74に送られる。
ヘッダ処理部74では、ヘッダ識別部74a〜74xがそれぞれ、IP(x→y),UDP,L2TP,PPP,IP(a→b)のプロトコル処理を行うように順次並べられているとすると、これに対してプロトコル処理部75における個別プロトコル処理部75a〜75xも対応したプロトコル処理プログラムが格納されていることとなり、同図(3)以降に示す手順を、ヘッダ識別部74a→74xにおいて順次実行して行けばよい。
そして、このヘッダ処理部74を通過した後は処理完了部76で処理完了が検出され、ヘッダ除去部77でヘッダが除去されたものが図6(21)に示す処理後のパケットとなる。
これは、図7の例も同様である。
さらに、このような処理は、図10に示した所定の処理順序をヘッダに加えた場合も同様である。
すなわち、同図(2)に示すようにヘッダにプロトコル総処理回数だけでなく、このときのプロトコル属性に対応した暗号処理及びIP処理をヘッダに付加した受信パケットがヘッダ付加部71からFiFo入力制御部72及びFiFo73を経由してヘッダ処理部74に送られる。
このヘッダ処理部74における各ヘッダ識別部74a〜74xは、暗号化処理のプロトコル又はIP処理のプロトコルであるか否かを識別し、例えばヘッダ識別部74xがそのプロトコルをデコーダ42で例えば暗号処理であると識別した場合には、対応する個別プロトコル処理部75xにその受信パケットを処理させ、その処理した受信パケットを入力してさらに次のヘッダ識別部に渡す。
これを順に繰り返すことにより、処理完了部76では図10(11)に示す受信パケットが得られ、これをヘッダ除去部77でヘッダを除去することにより処理後のパケットが得られることになる。
実施例(3)
図15は本発明に係る通信装置の実施例(3)を示したものである。上記の実施例(1)及び(2)では、ヘッダ付加部を用いてプロトコル処理順序データとしてのヘッダを生成し且つ受信パケットに付加しているが、この実施例(3)では受信パケットにヘッダという形で付加するのではなく、プロトコル処理順序データとして処理順序データ生成部92がこれを別個に生成し、且つ処理順序制御部93に処理順序データPDとして与える。
また処理順序データ生成部92からはパケットがデータ待機部94に与えられ、処理順序制御部93はプロトコル指示信号DSをデータ待機部94に与えることにより、データ待機部94は対応するプロトコル処理部95の個別プロトコル処理部95a〜95xに受信パケットを送って処理を行わせる。
その実行の終了信号FSをプロトコル処理部95が処理順序制御部93に送ると共に、処理し終わった受信パケットはデータ待機部94に保持しておく。
さらに次の処理プロトコルによってプロトコル処理部95に処理を行わせるようにし、最終的に処理が終わった段階でデータ待機部94から処理完了部96を経由して処理パケットを得ようとするものである。
この場合の主にデータ待機部94の構成例を示したものが図16に示されている。
すなわち、FiFo91より処理順序データ生成部92を経由して送られて来たパケットはバッファ94_0に格納される。
一方、処理順序データ生成部92は、処理順序制御部93からの処理順序データ要求DRを受けて処理順序データPDを与えるようになっており、処理順序制御部93はセレクタ94_1〜94_yを制御してバッファ94_0に格納されている受信パケットを対応する個別プロトコル処理部95a〜95xに与えて処理を行わせ、この処理結果を同じセレクタを経由してバッファ94_0に戻すようにしている。
このような制御を繰り返すことにより、処理順序データPDに基づいて処理が終了した（プロトコル現処理回数＝プロトコル総処理回数）と判断した処理順序制御部93はセレクタ94_yを経由してバッファ94_0から、処理が完了したパケットを処理完了部96に与え、完了処理されたパケットを出力するようにしている。
図17(1)には、図16に示した処理順序制御部93の処理アルゴリズムが示されており、これはセレクタ94_1〜94_x及び94_yをどのように制御するかを示したものである。
すなわち、図17(2)に例示した処理順序データPDを処理順序データ生成部92から入力すると（ステップS11）、プロトコル処理回数をi、プロトコル総処理回数をNとして（ステップS12）、プロトコル(i)の処理を対応するセレクタ94_1〜94_x(x≧N)に指示する（ステップS13）。
そして、プロトコル(i)が終了したか否かを判定し、終了していないときはステップS13に戻るが、プロトコル(i)が終了したときにはi=Nであるか否かを判定し、両者が不一致の場合にはiを“1”だけインクリメントしてステップS13に戻るが、i=Nであることが分かったときには処理完了として、セレクタ94_yを制御することによりバッファ94_0から受信パケットを処理完了部96に与えることができる。
このように実施例(3)においても、図17(2)に示すように処理順序データPDはプロトコル処理回数とプロトコル総処理回数並びに必要に応じて所定の順序に従ったプロトコルが格納されているので、上記の実施例(1)及び(2)でそれぞれ説明したのと同様のプロトコル処理を実行することができる。
すなわち、例えば図6のLNS処理の場合には図17(2)に示す処理順序データPDはプロトコル処理回数とプロトコル総処理回数しか含まれていないが、プロトコル処理部95における個別プロトコル処理部95a〜95xに対応したセレクタ94_1〜94_xにプロトコル実行指示DSを順次与えれば、図6(3)から同図(20)に示すプロトコル処理を順次実行することができる。
この処理の終了によりセレクタ94_yを介して最終的なパケットを94_0からヘッダ除去された形で処理完了部96から得られることになる。
また、図10に示す所定の処理順序データを用いる場合は、図17(2)に示す処理順序データPDそのものであるので、これが適用できることは言うまでもない。
以上説明したように本発明に係る通信装置によれば、受信パケットに含まれヘッダ識別部74a〜74xを直列接続したるプロトコルの属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを処理するプロトコル変換部とを備えたので、例えば図20に示したような例において、従来であればセキュリティ・ゲートウェイSG2にLNSも配備し、いずれのモードまたはセッションにも対応できるようにしなければならないが、一つの装置においてあらゆるプロトコルに対応することができ、考えられる全てのパケットの受信に一つの装置で対応することが可能となる。
（付記）
１．受信パケットに含まれるプロトコル属性を検出し、該プロトコル属性に基づいてプロトコル処理順序を示すプロトコル処理順序データを生成するプロトコル処理順序データ生成部と、
該プロトコル処理順序データに基づき該受信パケット中の複数のプロトコルを個別に処理するプロトコル変換部と、
を備えたことを特徴とする通信装置。
２．付記１において、
該プロトコル処理順序データ生成部は、該プロトコル属性に対応したプロトコル総処理回数を該プロトコル処理順序データとして生成し、プロトコル変換部は、該プロトコル総処理回数分だけ該受信パケット中に設定された複数のプロトコルを先頭から順次処理することを特徴とした通信装置。
３．付記１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
４．付記１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを先頭から順次該プロトコル処理部で処理させるヘッダ処理部と、該ヘッダ識別部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
５．付記１において、
該プロトコル処理順序データがプロトコル総処理回数を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該プロトコル処理部で先頭から順次処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
６．付記２から５のいずれか一つにおいて、
該プロトコル属性が、該複数のプロトコルを先頭から順次処理するのではなく、該プロトコル属性に対応した所定の処理順序を必要としていることを示しているとき、該プロトコル処理順序データ生成部は、該プロトコル総処理回数に該所定の処理順序を付加した該プロトコル処理順序データを生成し、該プロトコル変換部は、該所定の処理順序に従って該複数のプロトコルを該プロトコル総処理回数分だけ処理することを特徴とした通信装置。
７．付記１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ識別部と、該プロトコル処理部でのプロトコル処理回数をカウントするカウンタとを備え、該ヘッダ識別部は、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了することを特徴とした通信装置。
８．付記１において、
該プロトコル処理順序データ生成部が、該プロトコル処理順序データとしてプロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んだヘッダを該受信パケットに付加するヘッダ付加部であり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該ヘッダを識別して該受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させるヘッダ処理部と、該ヘッダ処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が、該プロトコル総処理回数に達したときプロトコル処理を終了させる処理完了部とを備えていることを特徴とした通信装置。
９．付記１において、
該プロトコル処理順序データが該プロトコル総処理回数及び該プロトコル属性に対応した所定の処理順序を含んでおり、該プロトコル変換部が、該複数のプロトコルを個別に処理するプロトコル処理部と、該受信パケットを待機させるデータ待機部と、該プロトコル処理順序データに基づいて該データ待機部における受信パケット中のプロトコルを該所定の処理順序で該プロトコル処理部により処理させると共に、該プロトコル処理部でのプロトコル処理回数を蓄積し、該プロトコル処理回数が該プロトコル総処理回数に達したときプロトコル処理を終了させる処理順序制御部とを備えていることを特徴とした通信装置。
１０．付記６から９のいずれか一つにおいて、
該プロトコル属性がセキュリティ・ゲートウェイを示しているとき、該所定の処理順序に暗号化処理を含むことを特徴とした通信装置。
１１．付記３又は７において、
該ヘッダ識別部が、対応するプロトコルを識別して対応する個々のプロトコル処理部に処理させることを特徴とした通信装置。
１２．付記４又は８において、
該ヘッダ処理部が、各プロトコル毎にヘッダ識別部を有し、各ヘッダ識別部が、対応するプロトコルを識別して対応するプロトコル処理部に処理させることを特徴とした通信装置。
１３．付記１から１２のいずれか一つにおいて、
該プロトコル属性が、送信元又は送信先のIPアドレスであることを特徴とした通信装置。
１４．付記１から１３のいずれか一つにおいて、
該プロトコル処理順序データ生成部が、該プロトコル属性と該プロトコル処理順序データとを対応させたテーブルを有していることを特徴とした通信装置。
１５．付記１から１４のいずれか一つにおいて、
該プロトコル変換部は、プロトコル処理後は該プロトコル処理順序データを除去する除去部を有することを特徴とした通信装置。
【国際調査報告】
2003075537.tif 000025
2003075537.tif 000026