(57)【要約】【課題】  プロトコル処理コア部の接続形態に係る制約を緩和する。【解決手段】  プロトコル処理部（５）は、ユーザデバイス（１１）及びプロトコル処理部（５）間におけるデータの入出力処理を行うプロトコル入出力処理部（３）と、プロトコル入出力処理部（３）によるデータの入出力処理に係る前後処理を行うプロトコル前後処理部（２）とを有し、少なくともプロトコル入出力処理部（３）を一つのハードウェアによって構成される。【選択図】  図２
2006081031.tif 000002
【特許請求の範囲】
【請求項１】
外部装置及び当該通信制御装置間におけるデータの入出力処理を行うデータ入出力手段と、
前記データ入出力手段によるデータの入出力処理に係る前後処理を行う前後処理手段とを有し、
少なくとも前記データ入出力手段は、一つのハードウェアによって構成されることを特徴とする通信制御装置。
【請求項２】
前記データ入出力手段と前記前後処理手段とは異なるハードウェアによって構成されることを特徴とする請求項１に記載の通信制御装置。
【請求項３】
前記データ入出力手段は、前記外部装置と直接接続されることを特徴とする請求項１又は２に記載の通信制御装置。
【請求項４】
前記前後処理手段は、前記データ出力手段によるデータの入出力処理に係る各種パラメータを記憶するパラメータ記憶部を含むことを特徴とする請求項１乃至３の何れか１項に記載の通信制御装置。
【請求項５】
前記データ入出力手段は、ＴＣＰ／ＩＰ及びＵＤＰ／ＩＰの少なくとも何れか一方によるデータの入出力処理を行うことを特徴とする請求項１乃至４の何れか１項に記載の通信制御装置。
【請求項６】
前記データ入出力手段と直接接続するデバイスであって、前記データ入出力手段とのデータ入出力に前後してデータ通信のためのコネクション設定を前記データ入出力手段に依頼するデバイスの制御を行う制御部から隠蔽された状態で、前記前後処理部は、前記データ入出力手段による処理の一部を制御することを特徴とする請求項１乃至５の何れか１項に記載の通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばユーザデバイスをネットワーク接続する際に用いられる通信制御装置に関するものである。
【背景技術】
【０００２】
パーソナルコンピュータ等でなくとも、機器を直接ネットワークに接続する機会や需要が高まっている。例として携帯端末、プリンタ、カメラ、コピー機、ディスプレイ、ビデオ機器、音響装置などが挙げられる。これらの機器は比較的低価格・低処理能力のＣＰＵを搭載、又は全く搭載していない場合もあり、その様な機器資源を利用しネットワークにおいて標準的に使用されているＴＣＰ／ＵＤＰ／ＩＰといったインターネット標準プロトコルを実現しようとすれば、ＴＣＰ／ＵＤＰ／ＩＰのプロトコルスタックを低処理能力ＣＰＵで低ビットレート（帯域）ではあるが実現するか、又はＴＯＥ（ＴＣＰ／ＩＰオフロードエンジン）といったプロトコル処理に特化した補助的デバイスを利用する事で比較的広帯域なネットワーク通信を実現するか、の方法しかない。とはいったものの機器が扱う情報の量は写真、動画、音楽、いずれにおいても大きくなる一方で、機器のコストを低価格に抑える必要がある、といった背景においてはＴＯＥによるネットワーク通信機能実現のアプローチが今後増加してくることは想像に難くない。
【０００３】
ＴＯＥ実現（ＴＣＰ／ＩＰプロトコルスタックのハードウェアによる実現）において、最も簡単にこれを実現する為には、ただ単に今迄ソフトウェアで実現していた方法をそのままハードウェア化すればよいと言う考え方がある。ソフトウェアで実現されているＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックは充分に枯れた方法により実現されており、この考え方は１つの妥当な考え方ではある。しかしソフト（ＣＰＵ向け）に考案された方法をそのままハードウェア化したときに、それがゲートやレジスタ(フリップフロップ)やメモリといったプリミティブなデバイスで実現される事を考えるとソフトの実現方法がそのままハードの適切な実現方法であるかといえば、違うと言わざるを得ない。ハードは複雑なポインタ処理や、変数の動的生成や消滅、再帰処理、多くのプロセス生成、といった処理方法は苦手であり、ソフトウェアで実現されたＴＣＰ／ＩＰプロトコルスタックは複雑なポインタ処理と変数やメモリ領域の動的生成や消滅といった手順が到るところに存在している。
【０００４】
ソフトウェアで実現されている方法を比較的そのままハードウェアとして実現した場合のＴＣＰ／ＩＰプロトコル処理装置について図７を用いて説明する。
【０００５】
図７は、従来のプロトコル処理装置における処理の流れの概念を示している。なお、以下の説明において特別な断りがない限りユーザデバイスとはプロトコル処理装置を使用する他のデバイスを意味する。ユーザデバイス（１５０）は映像のエンコーダやデコーダ等のストリームを発生又は消費するデバイスとそのデバイスとプロトコル処理部（１３０）を連結しストリームをＴＣＰ／ＩＰパケットとして入出力する為に機器全体を制御するストリームデバイス制御部を含むものとする。ストリームデバイス制御部としては一般にはＣＰＵや、ＡＳＩＣ又はＦＰＧＡ等が考えられる。
【０００６】
このユーザデバイス（１５０）は実際のストリームパケットの入出力に先立ちプロトコル処理部（１３０）に対しＴＣＰ（ＵＤＰ）／ＩＰコネクションのSourceAddressやDestinationAddressの指定を行う必要がある。このアドレス指定は一般にはＩＰアドレスやポート番号によって行われる（１５１）。
【０００７】
次にコネクション確立指示を行う必要がある（１５２）。コネクション確立指示は具体的にはＴＣＰ／ＩＰであればＳＹＮセグメントを送信する、又はＳＹＮセグメントの受信待ちを行う等の処理を意味する。その後、ユーザデバイス（１５０）は、映像や音声等のエンコーダであればストリーム又はデータグラムを出力（１５３）し、又は映像や音声等のデコーダであればストリームやデータグラムを受信（１５４）する。これらユーザデバイス（１５０）からの（あるいはユーザデバイス（１５０）への）データ入出力や指示（１５１）、（１５２）、（１５３）、（１５４）（以下、ユーザリクエストと称す）はプロトコル処理部（１３０）内部においてソケット処理部（１５５）にて処理される。
【０００８】
ソケットとは一般にSourceAddress/DestinationAddress/SroucePort/DestinationPortの４つの値の組で表される通信チャネルを意味する。ソケット処理部（１５５）においてはプロトコル処理部（１３０）が扱う複数の通信チャネル（ソケット）各々に対し、そのSourceAddress/DestinationAddress/SroucePort/DestinationPortや通信パラメータや扱うプロトコルとそのプロトコルに付随するＰＣＢ（ProtocolControlBlock：通信状態を保存するテーブル）への参照情報をソケットテーブルと呼ばれる記憶媒体に管理し、ユーザデバイス（１５０）からのユーザリクエストに基づき、ソケットテーブルの設定・更新・参照を統括し、必要ならソケット下層の各プロトコル処理層（ＴＣＰ処理部、ＵＤＰ処理部、ＩＰ処理部、ＭＡＣ処理部）に処理を依頼する。
【０００９】
図７では、ソケット下層の各プロトコル処理部であるＴＣＰ処理部やＵＤＰ処理部やＩＰ処理部やＭＡＣ処理部における処理の流れを、一つのモデルとして概念的に説明する為に、これらの処理部を抽象化し各プロトコル処理部（１７０）として示している。即ち各プロトコル処理部（１７０）の処理の流れとしては、ＴＣＰ処理部、ＵＤＰ処理部又はＩＰ処理部を示していると考えてよい。
【００１０】
ソケット処理部（１５５）はユーザリクエストがコネクションＳＡ／ＤＡ設定（１５１）の類であればテーブルの確保と設定・更新を行う。ユーザリクエストがコネクション確立やコネクション消去の指示（１５２）であれば各プロトコル処理部（１７０）にコネクション確立又は消去に伴う処理の実行依頼を行う（１６０）。ユーザリクエストがストリームの入出力に関わることであれば各プロトコル処理部（１７０）の入出力部に対し入出力の処理依頼（１５６）（１５９）を行う。
【００１１】
各プロトコル処理部（１７０）は、ストリームパケットや制御パケットの出力要求に伴いメッセージ（パケット）出力を行う出力部（１６１）と、各プロトコル処理を行う為に必要なパラメータの集合体である制御テーブル（１６２）と、コネクションの確立やコネクションの消去といったユーザリクエストや入力メッセージの処理を行う入力部（１６３）とから構成される。
【００１２】
各プロトコル処理部（１７０）にとっては、下層インタフェースからのメッセージ（パケット又はフレーム）入力と上位インタフェースからのユーザリクエストはそのプロトコル処理部に対する受信イベントという意味では同じと見なされるため、ユーザリクエストもメッセージ（パケット又はフレーム）入力も入力部（１６３）にて処理される。即ち入力部（１６３）が主要なプロトコル制御を行っていると見なしてよい。繰り返しになるが概念的には各プロトコル処理部における出力部（１６１）や制御テーブル（１６２）は各プロトコル処理部（１７０）の手足の様な存在であり入力部（１６３）が頭脳の様な役割を持っていると考えても良い。このことから一般にＴＣＰ処理部やＵＤＰ処理部やＩＰ処理部では入力部（１６３）に該当する部分の実装が大きくなる傾向にある。
【００１３】
図８では、図７のプロトコル処理の流れを念頭において、ＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理に必要とされる機能のブロックを図示している。ＴＣＰ／ＩＰプロトコル処理部（１）は（ＵＤＰプロトコル処理も包含しているものとする）、ソケット処理部（１７１）、ＴＣＰ処理部（１７２）、ＵＤＰ処理部（１７３）、ＩＰ処理部（１７４）、ＭＡＣ処理部（１７５）からなる。
【００１４】
ソケット処理部（１７１）は、ユーザからのストリーム出力指示を下位プロトコル処理部に中継するソケット出力部（１１４）、ユーザからのストリーム受信指示とストリーム受信を中継するソケット入力部（１１６）、先述の通信チャネルに関する情報を保持するソケットテーブル（１１５）、そのソケットテーブルの確保・更新・設定・参照及びコネクション確立指示やコネクション消去指示を中継するソケット設定部（１１３）から構成される。
【００１５】
ＴＣＰ処理部（１７２）は、ＴＣＰセグメントを出力するＴＣＰ出力部（１１７）、各ＴＣＰチャネルにおけるＴＣＰプロトコル制御の為の情報を管理するテーブルであるＴＣＰＰＣＢ(TCP Protocol Control Block)（１１８）、ＴＣＰ層へのユーザリクエストと下層インタフェースからのセグメント入力を処理するＴＣＰ入力及び主要制御部（１７６）からなる。
【００１６】
ＵＤＰ処理部（１７３）は、ＵＤＰデータグラムを出力するＵＤＰ出力部（１２０）、ＵＤＰデータグラムの入力を処理するＵＤＰ入力部（１２１）からなる。ＵＤＰは一般にそれ程複雑なプロトコル制御の必要がないためProtocol Control Blockを持たない。
【００１７】
ＩＰ処理部（１７４）は、ＩＰパケットを出力するＩＰ出力部（１２２）、ＩＰプロトコル制御の為の情報を管理するテーブルであるＩＮＰＣＢ(Internet Protocol Control Block)（１２３）、ＩＰパケットの入力とＩＰ層へのユーザリクエストを処理するＩＰ入力及び主要制御部（１７７）からなる。
【００１８】
ＭＡＣ処理部（１７５）はＭＡＣフレームの出力を行うＭＡＣ出力部（１２５）とＭＡＣフレームの入力を処理するＭＡＣ入力部（１２６）からなる。
【００１９】
図９では、従来のプロトコル処理装置におけるプロトコル処理コア部の１つについて示している。従来プロトコル処理コア部１（２４０）はここまで述べてきたＴＣＰ（ＵＤＰ）／ＩＰに関する全ての処理をそのままハードウェア化した形で実現され、その内部には図８で示したソケット処理部（１７１）とＴＣＰ処理部（１７２）とＵＤＰ処理部（１７３）とＩＰ処理部（１７４）とＭＡＣ処理部（１７５）を全て包含している。
【００２０】
図１１では、この従来プロトコル処理コア部（２４０）がソケット処理部（１７１）やＴＣＰ処理部（１７２）やＩＰ処理部（１７４）の全てを包含するにあたり各プロトコル処理部が持つプロトコル制御用テーブル（ソケットテーブル（１１５）、ＴＣＰＰＣＢ（１１８）、ＩＮＰＣＢ（１２３））を含有する事を示し、これらのテーブルはメモリ内に保存されるデータとして実現される事になり、即ち従来プロトコル処理コア部（２４０）がＦＰＧＡやＡＳＩＣで実現される場合はテーブルの為のメモリ媒体をそのＬＳＩ内部に実装する必要がある事を示している。
【００２１】
この従来プロトコル処理コア部（２４０）の機器内における使用方法を、図１０（ａ）、（ｂ）、（ｃ）に示す。
【００２２】
図１０（ａ）は、ストリームデバイス（２０２）と従来プロトコル処理コア部（２４０）をストリームデバイス制御部（２０３）を介して直接接続している。この場合、ストリームデバイス制御部（２０３）はストリームデバイス（２０２）の制御と従来プロトコル処理コア部（２４０）の制御（２２０）、そしてストリームデバイス（２０２）とプロトコル処理コア部（２４０）間のストリームの中継処理（２２１）を行う。このストリームデバイス制御部（２０３）は、ストリームの帯域を高速に保ちたい場合は特に、ＦＰＧＡやＡＳＩＣによって実現される事が想定される。
【００２３】
図１０（ｂ）は、従来プロトコル処理コア部（２４０）とストリームデバイス（２０２）（２０５）及びＣＰＵ（２０６）をバス（２０７）を介して接続する形態を示している。ここではＣＰＵ（２０６）が従来プロトコル処理コア部（２４０）に対し前後処理（２２３）等の複雑なシーケンス制御を行った後にストリームデバイス（２０２）（２０５）とプロトコル処理コア部（２４０）が実際のストリーム（２２２）の交換を行う事を想定している。
【００２４】
図１０（ｃ）は、従来プロトコル処理コア部（２４０）とストリームデバイス（２０２）（２０５）及びＣＰＵ（２０６）をバス（２０７）を介して接続する形態という意味では図１０の（ｂ）と同じではあるがＣＰＵ（２０６）はメモリ（２１２）と接続されており、ＣＰＵ（２０６）がプロトコル処理コア部（２４０）に対し前後処理（２２５）等の複雑なシーケンス制御を行った後に、ＣＰＵ（２０６）がストリームデバイス（２０２）（２０３）からのストリームを一旦メモリ（２１２）に格納しその後にメモリ（２１２）からプロトコル処理コア部（２４０）にＤＭＡ等によりストリームを転送する（２２４）流れを想定している。また、ＴＣＰ／ＩＰの処理がハードウェア的に行われるように構成した装置が開示されている。
【００２５】
【特許文献１】特開２００１−２６８１５９号公報
【発明の開示】
【発明が解決しようとする課題】
【００２６】
しかしながら、図７に示した従来のプロトコル処理コア部を用いたＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理では以下の問題がある。
【００２７】
（１）プロトコル処理コア部の接続形態に関する制約
プロトコル処理コア部にてデータストリームパケット入出力を行う為には、その前後に複雑な制御処理（ＳＡ／ＤＡ設定や通信確立処理や通信削除処理）をプロトコル処理コア部に指示する必要があり、この前後処理を指示する機器制御体（ＣＰＵやＡＳＩＣやＦＰＧＡ）とプロトコル処理コア部を接続する必要がある。更にプロトコル処理コア部はストリームパケットの入出力を行う事が主目的であるからストリームデバイスとも接続できる必要がある。即ちプロトコル処理コア部を機器制御体とストリームデバイスの２つのデバイスと接続する必要がある。これを実現する為のプロトコル処理コア部の使用方法は大きく分ければ、従来例に図１０（ａ）、（ｂ）、（ｃ）として示した３通りの方法しかない。
【００２８】
（２）ストリームの帯域を確保しにくい
従来例に述べた図１０（ａ）の様な接続形態はストリームデバイス制御部（２０３）をハードウェアで実現すれば高速なストリーム（２２１）の帯域を確保できる可能性はあるが、前後処理（２２０）等の複雑なシーケンス処理までハードウェア化する必要があるためストリームデバイス制御部（２０３）の実装が複雑になったり、ゲート規模が大きくなる場合がある。従って前後処理（２２０）等の複雑なシーケンス処理をＣＰＵで実現するというアプローチが自然ではあるが、この場合は従来例に述べた図１０（ｂ）、（ｃ）の様なプロトコル処理コア部を機器制御体（例えばＣＰＵ）とストリームデバイスといった２つのデバイスとをバス接続する形態となる。この接続形態の場合、ストリームデバイスとプロトコル処理コア部との接続がバスに依存している為、バス帯域がボトルネックになり十分なストリーム帯域を確保しにくい場合も多い。
【００２９】
（３）プロトコル処理コア部適用機器のコネクション規模を予め想定する必要がある
従来プロトコル処理コア部（２４０）は、内部にいくつかのテーブルが必要なことは従来技術の図１１の説明に述べた通りだが、プロトコル処理コア部をハードウェアで実現する場合このテーブルのサイズ等を予め規定しないかぎりハードウェアとしてユーザに提供できない。しかしその段階でテーブルサイズを規定する必要があるということは、プロトコル処理コア部がサポートするコネクション規模がユーザ提供時には決定済みであるということであり、そのプロトコル処理コア部の機器適用範囲（ユーザ）を狭める場合もある。
【００３０】
即ち、従来のプロトコル処理コア部は接続形態、ストリーム帯域、コネクション規模に関する汎用性確保が難しいと言える。
【００３１】
そこで、本発明の目的は、例えばプロトコル処理コア部の接続形態に係る制約を緩和することにある。
【００３２】
また本発明の目的は、例えばプロトコル処理コア部とユーザデバイス間のストリーム帯域を確保することにある。
【００３３】
さらに本発明の目的は、例えばプロトコル処理コア部を適用する機器のコネクション規模を予め想定する必要をなくすことにある。
【課題を解決するための手段】
【００３４】
本発明の通信制御装置は、外部装置及び当該通信制御装置間におけるデータの入出力処理を行うデータ入出力手段と、前記データ入出力手段によるデータの入出力処理に係る前後処理を行う前後処理手段とを有し、少なくとも前記データ入出力手段は、一つのハードウェアによって構成されることを特徴とする。
【発明の効果】
【００３５】
本発明によれば、外部装置との間におけるデータの入出力処理を行うデータ入出力手段と、当該データ入出力処理に係る前後処理を行う前後処理手段とを有する通信制御装置にあって、少なくともデータ入出力手段を一つのハードウェアによって構成したことにより、データ入出力手段の接続形態に係る制約を緩和することができる。
【００３６】
また本発明によれば、データ入出力手段と外部装置とを直接接続したことにより、データ入出力手段と外部装置間のストリーム帯域を確保することが可能となる。
【００３７】
さらに本発明によれば、データの入出力処理に係る各種パラメータを前後処理手段において記憶させるように構成したので、例えばデータ入出力手段を適用する機器のコネクション規模を予め想定する必要がない。
【発明を実施するための最良の形態】
【００３８】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００３９】
図１は、ＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理（１）を本発明の一実施形態におけるプロトコル入出力処理部（プロトコル処理コア部）（３）とプロトコル前後処理部（２）により実現している事を示している。プロトコル入出力処理部（３）はＡＳＩＣやＦＰＧＡ等ハードウェアやゲート回路で実現される可能性が高い。プロトコル前後処理部（２）は同じくＡＳＩＣやＦＰＧＡ等ハードウェアやゲート回路で実現される場合もあるがＣＰＵとメモリにより実現される場合もあるかも知れない。
【００４０】
図２は、図１のプロトコル前後処理部（２）やプロトコル入出力処理部（３）の構成と処理の流れについて示している。なお、プロトコル処理部（５）の処理範疇は図１のＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理部（１）と同じである。
【００４１】
図３は、図２の出力部（２８）と入力部（２９）と制御部（３６）と前後処理部（２）に含まれる、より詳細な機能のブロックが挙げられている。
【００４２】
出力部（２８）は、ユーザからのストリーム出力を適正な通信チャネルから出力する為のソケット出力部（１１４）、ユーザからのストリームにＴＣＰヘッダを付けて下層であるＩＰ出力部（１２２）にセグメントを出力するＴＣＰ出力部（１１７）、ユーザからのストリーム出力のソケットがＵＤＰソケットの場合はストリームにＵＤＰヘッダを付けて下層であるＩＰ出力部（１２２）にデータグラムを出力するＵＤＰ出力部（１２０）、トランスポート層（ＴＣＰ出力部（１１７）やＵＤＰ出力部（１２０））からのセグメントやデータグラムを受信してＩＰパケットとして構成しＩＰヘッダを付加するＩＰ出力部（１２２）、ＩＰ層からのＩＰパケットにＭＡＣヘッダを付加してインタフェースにフレーム出力するＭＡＣ出力部（１２５）から成る。
【００４３】
入力部（２９）は、インタフェースから受けたフレームのＭＡＣヘッダの妥当性を検証しＭＡＣヘッダを除去するＭＡＣ入力部（１２６）、ＭＡＣ入力部（１２６）から受けたＩＰパケットの妥当性を検証し必要ならＩＰフラグメントの再構成等を行いＩＰパケットをトランスポート層より上位に解釈可能な形に整形しＩＰヘッダを除去した上で適切なトランスポート（ＵＤＰまたはＴＣＰ）層にそのＩＰパケットのペイロードを出力するＩＰ入力部（１２４）、ＩＰ入力部（１２４）から受けたＵＤＰデータグラムのヘッダの妥当性を検証しＵＤＰヘッダを除去しソケット入力部（１１６）にデータグラムペイロードを出力するＵＤＰ入力部（１２１）、ＩＰ入力部（１２４）から受けたＴＣＰセグメントのヘッダの妥当性を検証しＴＣＰヘッダを除去しセグメントのペイロードをストリームとしてソケット入力部（１１６）に出力するＴＣＰ入力部（１１９）、トランスポート層入力部（ＵＤＰ入力部又はＴＣＰ入力部）から受けたストリーム又はデータグラムをその通信チャネル（ソケット）から判断して適切なアプリケーション（ユーザデバイス）に出力するソケット入力部（１１６）からなる。
【００４４】
制御部（３６）は、ＴＣＰ入力部（１１９）が検出したフラグセグメント受信や内部に持つタイマーイベントやソケット設定部からのコネクション確立・消去指示を元にソケット毎のＴＣＰ状態制御等を行いＴＣＰ出力部（１１７）にセグメント出力の指示を行うＴＣＰ制御部（１２７）、ＩＰ入力部（１２４）からのＩＰパケット受信イベントを元に受信ＩＰパケット受信可否判断依頼やＩＰ出力部（１２２）からのストリーム出力時のルーティング問い合わせ依頼の処理を行うＩＰ制御部（１２８）からなる。
【００４５】
前後処理部（２０）は、ユーザデバイス（１１）からのＳＡ／ＤＡ設定（１４）やコネクション確立/消去指示（１５）を受信しソケットテーブル（１１５）の確保・更新・消去を行いプロトコル入出力処理部（３）にコネクション確立・消去に伴うフレーム出力を依頼するソケット設定部（２６）、複数の通信チャネル（ソケット）各々に対しそのSourceAddress/DestinationAddress/SroucePort/DestinationPort（厳密にはSAAddr/DAAddr/SAPort/DAPortは後述のＩＮＰＣＢに保存される。この場合はソケットテーブルには該当するソケットがどのＩＮＰＣＢレコードを参照すべきかの参照情報を保持する事になる）や通信パラメータや扱うプロトコルとそのプロトコルに付随するＰＣＢ（ProtocolControlBlock：通信状態を保存するテーブル）への参照情報やトランスポート層のプロトコル種別（ＵＤＰ／ＴＣＰ等）を保持するソケットテーブル（１１５）、ＴＣＰを制御する為に各通信チャネル（ソケット）毎にＴＣＰコネクションの状態や必要なパラメータを保存するＴＣＰＰＣＢ(TCP Protocol Control Block)（１１８）、ＩＰを制御する為に各通信チャネル（ソケット）毎にSAAddr/DAAddr/SAPort/DAPortやＴＴＬ／ＴＯＳやオプション等を保存するＩＮＰＣＢ(Internet Protocol Control Block)（１２３）からなる。なお、図２のプロトコル前後処理部（２）に示されるテーブル＆ＰＣＢ（２２）は図３のソケットテーブル（１１５）とＴＣＰＰＣＢ（１１８）とＩＮＰＣＢ（１２３）が含まれる。
【００４６】
以下に図２を用いてその構成要素には図３に示した機能ブロックが含まれる事を前提に、プロトコル前後処理部（２）とプロトコル入出力処理部（３）について説明する。
【００４７】
ユーザデバイス（ストリームデバイスとそれを制御するストリームデバイス制御部からなる場合が多い）（１１）はストリーム入出力に前後しコネクションＤＡ及びコネクションＳＡの設定（１４）をプロトコル処理部（５）に依頼する。プロトコル処理部（５）ではこの依頼をプロトコル前後処理部（２）にて受信しプロトコル前後処理部の中でもその依頼はソケット設定部（２６）にて処理される。ソケット設定部（２６）ではコネクションのＳＡやＤＡに関する設定はソケットテーブルに保存すべきものと判断しテーブル＆ＰＣＢ（２２）のソケットテーブル（１１５）にコネクションＤＡ／ＳＡ設定（２１）を行う。
【００４８】
次にユーザデバイス（１１）はコネクションの確立指示（１５）を行う。プロトコル処理部（５）ではこの指示についてもプロトコル前後処理部（２）にてソケット設定部（２６）が受信し処理を判断する。ソケット設定部（２６）ではコネクション確立指示に起因する制御フレームの送信指示をプロトコル入出力処理部（３）に対し行う。プロトコル入出力処理部（３）ではこのコネクション確立指示（２７）は制御部（３６）にて処理される。制御部（３６）ではコネクション確立においてどの様な制御フレームを送信すべきか判断しまたその制御フレームを送信することによりプロトコル状態がどのように変化するかを判断しこれをテーブル＆ＰＣＢ（２２）にパラメータとして設定する（２５）。この行為は具体的には例えばＴＣＰであればＳＹＮセグメントの送信判断とＳＹＮセグメントを送信した場合の状態遷移による状態変数の変更をＴＣＰＰＣＢに設定する行為に該当する。制御部（３６）ではコネクション確立に伴う制御フレーム送信の判断とテーブル＆ＰＣＢ（２２）の設定は行うが実際のフレーム送信作業は出力部（２８）にて行われる。この為に制御部（３６）は制御フレームを送信する必要性を判断すれば制御メッセージ出力要求（３１）を出力部（２８）に送信する。出力部（２８）では（他の）ストリーム送信の合間をみてこれらの、例えばコネクション確立時に必要な制御フレーム送信を行う（３３）。
【００４９】
ユーザデバイス（１１）はＳＡ／ＤＡ設定（１４）とコネクション確立指示（１５）が終了すればストリームを出力（１２）することができる。ストリーム出力指示（１２）はプロトコル処理部（５）の中でもプロトコル入出力処理部（３）の内の出力部（２８）が直接受け取る。出力部（２８）の内部でもストリーム出力指示はソケット出力部（１１４）、ＴＣＰ出力部（１１７）又はＵＤＰ出力部（１２０）、ＩＰ出力部（１２２）、ＭＡＣ出力部（１２５）にて処理され、この際必要ならばテーブル＆ＰＣＢ（２２）を参照（２３）しながら、実際のフレームが作成され出力（３２）される。
【００５０】
ネットワークインタフェースからストリームフレームを受信した場合（３４）は入力部（２９）がこれを受け、入力部（２９）内ではＭＡＣ入力部（１２６）、ＩＰ入力部（１２４）、ＵＤＰ入力部（１２１）又はＴＣＰ入力部（１１９）、ソケット入力部（１１６）にてその受信ストリームフレームを処理し、ユーザデバイス（１１）にストリーム入力を行う（１３）。この際特にそのストリームがどの通信チャネル（ソケット）に属するものであるか判断するためにテーブル＆ＰＣＢ（２２）を参照（２４）する。
【００５１】
ストリーム入出力中にはプロトコル制御のためのフレームをインタフェースから受信（３５）する可能性があるが、これは入力部ではそのヘッダ解析を行う程度にとどめ、プロトコル制御の為の実際の処理は制御部（３６）にて行う。このため入力部（２９）はプロトコル制御関連フレームを受信（３５）すると制御部（３６）に対して制御メッセージを受信した旨とその種別と解析の結果得られた必要なデータを送信する（３７）。制御部ではこの制御メッセージ受信（３７）のイベントをトリガにテーブル＆ＰＣＢ（２２）を操作（２５）した上で、再び出力部（２８）に対してプロトコル制御の為の制御メッセージ出力を依頼（３１）する場合もある。
【００５２】
ユーザデバイス（１１）によるストリーム入出力が終了すれば、ユーザデバイス（１１）はコネクション消去指示（１５）を行うがその基本的な処理の流れはコネクション確立指示と同じである。
【００５３】
図４を用いて、ストリームを扱う機器を上述した様にプロトコル処理をプロトコル前後処理部（２）とプロトコル入出力処理部（プロトコル処理コア部）（３）により実現する場合のプロトコル処理コア部の用い方について説明する。
【００５４】
図４（ｄ）は本プロトコル処理コア部（３）を単なるＩＯデバイスと見なしストリームデバイス（２０２）と直結している。これによりストリームデバイス（２０２）と本プロトコル処理コア部（３）との間に流れるストリーム（２４６）はバス等のボトルネックの影響を受けずに充分な帯域を確保しながら入出力が可能となる。その一方でストリーム伝送に前後するシーケンス処理（ＳＡ／ＤＡ設定,コネクション確立/消去等）はＣＰＵ（２０６）によりバス（２０７）を介して接続された前後処理部（２）を制御する事により行われる。この処理は図中では前後処理（２４７）として示されている。この接続方法はストリーム（２４６）の帯域を充分に確保しながら、複雑な前後処理シーケンスはＣＰＵ（２０６）により肩代わりして実行できるという利点がある。なお、ＣＰＵ（２０６）はストリームデバイス（２０２）の制御も多少は行う必要があることが想定される。
【００５５】
図４（ｅ）はＣＰＵ（２０６）とストリームデバイス（２０２）及び前後処理部（２）を直結し、本プロトコル処理コア部（３）はストリームデバイス（２０２）及び前後処理部（２）と接続されている例を示している。この接続方法でもストリーム（２５０）の流れは充分な帯域を維持でき、複雑な前後処理シーケンスはＣＰＵ（２０６）により肩代わりして実行できる。なお、ＣＰＵ（２０６）はストリームデバイス（２０２）の制御も多少は行う必要があることが想定される。
【００５６】
図４（ｆ）は、ＣＰＵ（２０６）はストリームデバイス（２０２）に対する多少の制御以外は何もしていない。ストリーム（２４８）はストリームデバイス（２０２）から本プロトコル処理コア部（３）に対し充分な帯域を持って伝送される。ストリーム入出力に前後する複雑なシーケンス処理は前後処理部（２１０）にてＣＰＵ（２０６）とは独立して、つまり、ＣＰＵ（２０６）から隠蔽して実行される事を想定している。この方法は、対向する機器のアドレスやポートが予め決め打ちの数本であると予め決まっている場合にそのアドレスやポートは半静的に前後処理部のＲＯＭやフラッシュメモリに書き込まれている事を想定している。
【００５７】
図４（ａ）の直結タイプは従来プロトコル処理コア部（２４０）の図１０（ａ）の直結タイプと同様の接続形態を本プロトコル処理コア部（３）でも取り得る事を示している。図４（ａ）のバス接続直接転送タイプは従来プロトコル処理コア部（２４０）の図１０（ｂ）のバス接続直接転送タイプと同様の接続形態を本プロトコル処理コア部（３）も取り得る事を示している。図４（ｃ）のバス接続ＤＭＡ転送タイプは従来プロトコル処理コア部（２４０）の図１０（ｃ）のバス接続ＤＭＡ転送タイプと同様の接続形態を本プロトコル処理コア部（３）も取り得ることを示している。但し図４（ａ）、（ｂ）、（ｃ）いずれの場合も、ユーザから見て本プロトコル処理コア部（３）を従来プロトコル処理コア部（２４０）と同じ使用感にするための互換隠蔽層（２１１）が必要になる。
【００５８】
図５では、プロトコル処理入出力処理部、即ちプロトコル処理コア部（３）がソケットテーブル（１１５）やＴＣＰＰＣＢ（１１８）やＩＮＰＣＢ（１２３）を含まずに構成され、これらのテーブルはプロトコル前後処理部（２）に含まれていることを示している（斜線で示したものがこれらのテーブルを保持するメモリ体を現す）。このプロトコル前後処理部（２）の物理的な構成はプロトコル処理コア部（３）が用いられる機器の性質により様々に変更されることを想定している。このバリエーションについて図６に示している。
【００５９】
例えば機器が比較的多くのコネクションをサポートする必要がある場合はそのテーブル保持媒体としてはメモリ（３１３）を用い、その読み書き制御を行うＤＢ読み書き制御部（３０６）ではハッシュテーブル（３１１）を用いてメモリにおけるテーブルを管理する方法が考えられる（３０５）。機器が比較的少ないコネクションをサポートする場合はハッシュテーブル等のテーブル管理は必要ないかも知れない（３０４）。さらに機器が予め決められた数本のコネクションのみをサポートする場合はメモリもフラッシュメモリの様な不揮発性のメモリを用意しそこに予めコネクション相手に対応するアドレスやポートを設定しておく事で前後処理部を構成できる（３０２）。逆に非常に多くのコネクションを高速にテーブル参照・更新する必要がある場合はＣＡＭ(Contents Access Memory)等を用いたＤＢ読み書き制御部（３１０）を内蔵した前後処理部（３０１）を用意する必要があるかも知れない。
【００６０】
本実施形態によれば、プロトコル処理コア部の接続形態に関する選択肢を増やすことができる。図１０に示した通り従来プロトコル処理コア部（２４０）は（ａ）（ｂ）（ｃ）の３つの使用方法が想定されることに対し、プロトコル処理コア部（３）は図４（ａ）（ｂ）（ｃ）（ｄ）（ｅ）（ｆ）に想定される６通りの使用方法を想定、選択することができる。
【００６１】
また、本実施形態によればストリームの帯域を確保できる。図１０に示した通り従来のプロトコル処理コア部（２４０）のストリーム（２２１）（２２２）（２２４）は、ストリームデバイス（２０２）とプロトコル処理コア部（２４０）の間にストリームを仲介する為の存在が必要でありそのストリーム帯域を確保することが難しいが、プロトコル処理コア部（３）は（２４６）（２５０）（２４８）に示した様にストリームがストリームデバイス（２０２）から本プロトコル処理コア部（３）まで直接伝送されるためその帯域を確保することができる。
【００６２】
本実施形態によれば、プロトコル処理コア部適用機器のコネクション規模を予め想定する必要がなくなる。図１１に示した通り、従来プロトコル処理コア部（２４０）はそのプロトコル制御のためのデータベースをコア内部に持つ為コア部のゲート回路を実装するときにはそのコネクション規模を想定した上でないとチップやゲート回路を実装できないが、本プロトコル入出力処理部（本プロトコル処理コア部（３））はデータベースをコア内部に含まない為、プロトコル処理を使用する機器のコネクション規模を想定しなくともゲート回路として実装可能である。
【図面の簡単な説明】
【００６３】
【図１】ＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理を本発明の一実施形態におけるプロトコル入出力処理部（プロトコル処理コア部）とプロトコル前後処理部により実現している事を示す図である。
【図２】図１のプロトコル前後処理部やプロトコル入出力処理部の構成と処理の流れについて示す図である。
【図３】図２の出力部と入力部と制御部と前後処理部に含まれる、より詳細な機能のブロック図である。
【図４】プロトコル処理をプロトコル前後処理部とプロトコル入出力処理部（プロトコル処理コア部）により実現する場合のプロトコル処理コア部の用い方について説明するための図である。
【図５】プロトコル処理コア部がソケットテーブルやＴＣＰＰＣＢやＩＮＰＣＢを含まずに構成され、これらのテーブルがプロトコル前後処理部に含まれていることを示す図である。
【図６】プロトコル前後処理部の物理的な構成のバリエーションを示す図である。
【図７】従来のプロトコル処理装置における処理の流れの概念を示す図である。
【図８】図７のプロトコル処理の流れを念頭において、ＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理に必要とされる機能ブロックを示す図である。
【図９】従来のプロトコル処理装置におけるプロトコル処理コア部の１つについて示す図である。
【図１０】従来プロトコル処理コア部の機器内における使用方法を示す図である。
【図１１】従来プロトコル処理コア部がソケット処理部やＴＣＰ処理部やＩＰ処理部の全てを包含するにあたり各プロトコル処理部が持つプロトコル制御用テーブル（ソケットテーブル、ＴＣＰＰＣＢ、ＩＮＰＣＢ）を含有する事を示す図である。
【符号の説明】
【００６４】
１  ＴＣＰ（ＵＤＰ）／ＩＰプロトコル処理
２  プロトコル前後処理部
３  プロトコル入出力処理部
５  プロトコル処理部
１１  ユーザデバイス
２２  テーブル＆ＰＣＢ
２６  ソケット設定部
２８  出力部
２９  入力部
３６  制御部
１１４  ソケット出力部
１１５  ソケットテーブル
１１６  ソケット入力部
１１７  ＴＣＰ出力部
１１８  ＴＣＰＰＣＢ
１１９  ＴＣＰ入力部
１２０  ＵＤＰ出力部
１２１  ＵＤＰ入力部
１２２  ＩＰ出力部
１２３  ＩＮＰＣＢ
１２４  ＩＰ入力部
１２５  ＭＡＣ出力部
１２６  ＭＡＣ入力部
１２７  ＴＣＰ制御部
１２８  ＩＰ制御部
２０２、２０５  ストリームデバイス
２０３  ストリームデバイス制御部
２０６  ＣＰＵ
２０７  バス
２１０  前後処理部
２１１  互換隠蔽層
２１２  メモリ
【図１】
2006081031.tif 000003
【図２】
2006081031.tif 000004
【図３】
2006081031.tif 000005
【図４】
2006081031.tif 000006
【図５】
2006081031.tif 000007
【図６】
2006081031.tif 000008
【図７】
2006081031.tif 000009
【図８】
2006081031.tif 000010
【図９】
2006081031.tif 000011
【図１０】
2006081031.tif 000012
【図１１】
2006081031.tif 000013