JP4612820B2 - 通信制御装置及び方法 - Google Patents

Description

本発明は、通信制御装置及び方法に関するものである。

パーソナルコンピュータ等でなくとも、機器を直接ネットワークに接続する機会や需要が高まっている。例として携帯端末、プリンタ、カメラ、コピー機、ディスプレイ、ビデオ機器、音響装置などが挙げられる。これらの機器は比較的低価格・低処理能力のＣＰＵを搭載、又は全く搭載していない場合もあり、その様な機器資源を利用しネットワークにおいて標準的に使用されているＴＣＰ／ＵＤＰ／ＩＰといったインターネット標準プロトコルを実現しようとすれば、ＴＣＰ／ＵＤＰ／ＩＰのプロトコルスタックを低処理能力ＣＰＵで低ビットレート（帯域）ではあるが実現するか、又はＴＯＥ（ＴＣＰ／ＩＰオフロードエンジン）といったプロトコル処理に特化した補助的デバイスを利用する事で比較的広帯域なネットワーク通信を実現するか、の方法しかない。とはいったものの機器が扱う情報の量は写真、動画、音楽、いずれにおいても大きくなる一方で、機器のコストを低価格に抑える必要がある、といった背景においてはＴＯＥによるネットワーク通信機能実現のアプローチが今後増加してくることは想像に難くない。

ＴＯＥ実現（ＴＣＰ／ＩＰプロトコルスタックのハードウェアによる実現）において、最も簡単にこれを実現する為には、ただ単に今迄ソフトウェアで実現していた方法をそのままハードウェア化すればよいと言う考え方がある。ソフトウェアで実現されているＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックは充分に枯れた方法により実現されており、この考え方は１つの妥当な考え方ではある。しかしソフトウェア（ＣＰＵ向け）に考案された方法をそのままハードウェア化したときに、それがゲートやレジスタ（フリップフロップ）やメモリといったプリミティブなデバイスで実現される事を考えるとソフトウェアの実現方法がそのままハードウェアの適切な実現方法であるかといえば、違うと言わざるを得ない。ハードウェアは複雑なポインタ処理や、変数の動的生成や消滅、再帰処理、多くのプロセス生成、といった処理方法は苦手であり、ソフトウェアで実現されたＴＣＰ／ＩＰプロトコルスタックは複雑なポインタ処理と変数やメモリ領域の動的生成や消滅といった手順が到るところに存在している。

従来手順をそのままハードウェアで実現すると大きく以下の流れになる。（１）アプリケーションデバイスから送信指示された一連の送信データを一時的に連続した共有メモリ領域に保存する。（２）共有メモリに保存された一連の送信データを、最も上位のプロトコル制御ブロックが参照、分割、ヘッダ追加を行い、次のプロトコル制御ブロックに共有メモリのアクセス権利と共に制御を移す。各プロトコル制御ブロックは順次、各々共有メモリの参照、分割、ヘッダ追加を行う。（３）ヘッダとペイロードを連続したメモリ空間に隣接して配置する。ペイロードの全てを連続したメモリ空間に配置できない場合は別のメモリ空間にペイロードのみを配置する。（４）ヘッダと隣接したペイロードや隣接しないペイロード、フレームの連続関係はメモリ制御情報として必要な数だけメモリ内に保存される（一般にｍｂｕｆと呼ばれる）。

即ち、複雑なペイロード分割とペイロードやヘッダの管理情報（ｍｂｕｆ）の生成後にヘッダが生成され、この処理は各プロトコルスタックで各々順次実行される。

また、下記の特許文献１には、ＴＣＰ／ＩＰをハードウェア的に処理する装置及びその動作方法が記載されている。

特開２００１−２６８１５９号公報

しかし、上記のような手順を踏むと、アプリケーションの転送単位によるＴＣＰセグメント化やＩＰフラグメント化が必要な場合は、１つ１つのフレームに対する全てのヘッダをメモリに書き込まなければならない。すなわちリンク層に依存するＭＴＵに対して、アプリケーションの転送単位が大きくなるにつれて、分割後に発生するフレームが増加し、そのフレームに付加しなければならないヘッダを書き込むために確保しなければならないメモリ領域が増大するという課題がある。

一般的には、メモリ内でヘッダとペイロードをフレーム化して出力する。しかし、アプリケーションの転送単位によりＴＣＰのセグメント化やＩＰのフラグメント化が必要な場合は、一つ一つのフレームに対するヘッダ全てをメモリに書き込まなければならない。

本発明の目的は、アプリケーションの転送単位が大きくなることにより送信するフレーム数が増加する場合であっても、ヘッダを書き込むために確保しなければならないメモリ領域の増大を抑止することである。

本発明の通信制御装置は、複数レイヤのプロトコルのヘッダ生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力するプロトコル制御手段と、前記プロトコル制御手段から前記ヘッダ生成指示及び前記ヘッダ生成情報が入力されると、複数レイヤのプロトコルのヘッダを並列して１ヘッダ毎に生成し、ヘッダ生成完了通知を出力するヘッダ生成手段と、前記ヘッダ生成手段から前記ヘッダ生成完了通知が入力されると、前記生成された複数レイヤのプロトコルのヘッダ及びフレーム単位のペイロードをフレームとして合成するヘッダ／ペイロード合成手段とを有することを特徴とする。

また、本発明の通信制御方法は、複数レイヤのプロトコルのヘッダ生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力するプロトコル制御ステップと、前記ヘッダ生成指示及び前記ヘッダ生成情報が入力されると、複数レイヤのプロトコルのヘッダを並列して１ヘッダ毎に生成し、ヘッダ生成完了通知を出力するヘッダ生成ステップと、前記ヘッダ生成完了通知が入力されると、前記生成された複数レイヤのプロトコルのヘッダ及びフレーム単位のペイロードをフレームとして合成するヘッダ／ペイロード合成ステップとを有することを特徴とする。

本発明によれば、フレーム単位で複数レイヤのプロトコルのヘッダを並列して生成し、フレーム単位のペイロードと合成するので、アプリケーションの転送単位が大きくなることにより送信フレーム数が増加する場合であっても、フレームに付加しなければならないヘッダを書き込むために確保しなければならないメモリ領域の増大を抑止することができる。

図１は、本発明の実施形態による通信制御装置の構成例を示すブロック図である。以下、図１を用いてその構成を説明する。

［アプリケーションデバイス］
アプリケーションデバイス（１０１）は、送信要求（１０６）と送信データ長（１０７）をフレーム個数フレーム長算出部（１０２）に出力し、送信データ（１１０）をペイロード分割部（１０３）に出力する。アプリケーションデバイス（１０１）には、２つの種類が想定される。１つ目はコンスタントビットレート（単位時間あたりの情報量が一定）のデバイスである。２つ目はバリアブルビットレートのデバイス（単位時間あたりの情報量が一定ではないが、単位時間辺りの情報量は明示される）である。その他にバリアブルビットレートのデバイスからの情報を一時的にバッファし定期的に一定量の情報を出力する様シェーピングするデバイスである場合も想定されるがこれは１つ目の種類のデバイスと同じと見なせる。また、サンプリング周波数で予め規定された量子化ビットレートでＲＡＷ情報を出力してくるデバイスも想定できるが、これは１つ目の種類のデバイスと同様に見なすことが出来る。これら全てのアプリケーションデバイス（１０１）に接続される本実施形態による通信制御装置は、アプリケーションデバイス（１０１）とのインタフェースにおいて、送信要求（１０６）、送信データ長（１０７）、送信データ（１１０）、を受ける事とする。

［フレーム個数フレーム長算出部］
フレーム個数フレーム長算出部（１０２）は、アプリケーションデバイス（１０１）から入力された送信要求（１０６）をトリガに、同じく入力された送信データ長（１０７）を基に送信データを幾つのフレームに分割して出力すべきかを算出する。

図２のフローチャートを用いて、ペイロード長とヘッダ数算出の流れについて詳説する。フレーム個数フレーム長算出部（１０２）は、アプリケーションデバイス（１０１）からの送信要求（１０６）を受信すると併せて、その一度の送信要求で送信したいデータの長さを送信データ長（１０７）として受け取る（ステップ３０１、３０２）。するとフレーム個数フレーム算出部（以後ＦＦＣと呼ぶ）はフレーム数（ＦＬＭ＿ＣＯＵＮＴ）、先頭フレームペイロード長（ＨＥＡＤ＿ＰＡＹ＿ＬＥＮ）、中間フレームペイロード長（ＭＩＤ＿ＰＡＹ＿ＬＥＮ）、最終フレームペイロード長（ＦＩＮ＿ＰＡＹ＿ＬＥＮ）を算出する必要があるが、これらをまず初期化する（ステップ３０３）。フレームをどの様な長さの単位で送信するかについてはＴＣＰ／ＵＤＰを想定した場合、インタフェースのＭＴＵ又はＴＣＰのＭＳＳが想定されるが、ここではまずインタフェースのＭＴＵを取得する（ステップ３０４）。また、ＴＣＰ／ＵＤＰ／ＩＰから形成されるフレームを扱う場合にフレームのペイロード長を算出する為には各々のプロトコルヘッダの長さを鑑みる必要があるのでＩＰＨＬ（ＩＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）及びＵＤＰＨＬ（ＵＤＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）及びＴＣＰＨＬ（ＴＣＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）を規定する（ステップ３０５）。このステップ３０５では、それぞれ基本のヘッダ長を示してあるが各プロトコルにおいてオプションヘッダを想定する場合はこの場でオプションヘッダ長まで加味したヘッダ長を規定する。次にコネクションの種別についてＴＣＰかＵＤＰか又はＲＡＷであるか、を識別する。コネクション種別は予めＦＦＣ（１０２）にて保持しておく方法とコネクション識別子を基に導出する方法が考えられる（ステップ３０６）。

ＵＤＰの場合は送信データ長がインタフェース層ＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬ以下であるかを確認する（ステップ３１１）。そうである場合は１つのフレームに与えられた送信データが全て格納可能であるのでフレーム数１、先頭フレームペイロード長＝送信データ長である、とする（ステップ３０８）。そうでない場合は送信データを複数のフレームに分割する必要がある。この分割数や各ペイロード長を算出する作業は仮にフレームを送信していった場合にどうなるかという事を想定しながら分割作業を進めていく。まず仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）を０とする（ステップ３１２）。次に未送信データ長がフラグメントペイロード長以下であるかを確認する。これは最終フラグメントであるかという判断をおこなっており、未送信データ長は送信データ長から仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）を減算して求め、これとＭＴＵ−ＩＰＨＬの長さを比較する等という方法が想定できる（ステップ３１３）。ここまでの事前チェックの流れにおいては、初めての比較では未送信データ長がフラグメントペイロード長以下であるということは起き得ない。次にフレーム数（ＦＬＭ＿ＣＯＵＮＴ）をインクリメントする（ステップ３１４）。送信済みデータ長が０であれば（ステップ３１５）、先頭フレームであると判断されるので先頭フレームのペイロード長はＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬであり、仮の送信済みデータ長はＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬであると決定される（ステップ３１７）。先頭フレームではない場合は中間フレームであるから中間フレーム長をＭＴＵ−ＩＰＨＬ、仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）をＤＯＮＥ＿ＬＥＮ＋（ＭＴＵ−ＩＰＨＬ）とする。これらの後再び未送信データ長がフラグメントペイロード長以下であるか、即ち最終フラグメントであるかを判断し（ステップ３１３）、もし最終フラグメントであれば最終フレームは送信データ長からＤＯＮＥ＿ＬＥＮを減算する事で求められる（ステップ３１８）。その後最終フラグメントフレームの分のフレーム数をカウントアップ（ＦＬＭ＿ＣＯＵＮＴ＋＋）し（ステップ３１９）、フレーム数、先頭フレームペイロード長、中間フレームペイロード長、最終フレームペイロード長が決定出力される（ステップ３１０）。

コネクション種別がＲＡＷの場合はフレーム数は１つで、フレームペイロード長はＭＴＵ−ＩＰＨＬの範囲内に収まるべきであり、もしそうでないとしてもその様に送信データを切り落として送信する事を想定している。又はアプリケーションデバイス（１０１）にエラーとして応答を送るという方法も考えられる（ステップ３０８、３０９）。

コネクション種別がＴＣＰの場合はフレーム長はＭＳＳ（マキシマムセグメントサイズ）が基本となるので取得する（ステップ３２０）。次に仮の送信済みデータサイズ（ＤＯＮＥ＿ＬＥＮ）をゼロに初期化し（ステップ３２１）、（仮の）未送信データ長がＭＳＳ以下であるかをチェックする（ステップ３２２）。もしＭＳＳ以下であれば与えられた送信データは次の１セグメントで送信完了できる事が判断できる。もしＭＳＳより大きければフレーム数をインクリメント（ステップ３２３）し、先頭セグメントであれば（この判断はＤＯＮＥ＿ＬＥＮが０であるか否かで行う）（ステップ３２４）、先頭フレーム長はＭＳＳであり、ＤＯＮＥ＿ＬＥＮはＭＳＳとなる（ステップ３２６）。再び仮の未送信データ長がＭＳＳ以下であるかを確認し、まだＭＳＳより大きい場合はフレーム数をカウントアップし今度は中間フレームペイロード長をＭＳＳとし送信済みデータ長ＤＯＮＥ＿ＬＥＮ＝ＤＯＮＥ＿ＬＥＮ＋ＭＳＳとする（ステップ３２５）。再び未送信データ長がＭＳＳ以下であるかを確認し、もし最終セグメントであると判断されれば最終フレームとして最終フレーム長を送信データ長からＤＯＮＥ＿ＬＥＮを減算した値とし（ステップ３２７）、最終フレームを送信フレーム数としてカウントする（ステップ３２８）。

上述の様にフレーム数、先頭フレームペイロード長、中間フレームペイロード長、最終フレームペイロード長が決定出力される（ステップ３１０）。これら４つの値をフレーム個数とフレーム長に関する値とし、ペイロード分割部（１０３）とプロトコル制御部（１１５）及びヘッダ／ペイロード合成部（１２０）に出力する。

［ペイロード分割部の分割］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）。ペイロード分割部（１０３）は、フレームペイロード書き込みが完了したらプロトコル制御部（１１５）に対しフレームペイロードの送信準備が出来た事を通知する（１３６）。

［ペイロード分割部のチェックサム］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）際、フレームペイロードのチェックサムをフレーム毎に求め、ＵＤＰヘッダ生成部（１１７）及び、ＴＣＰヘッダ生成部（１１６）にチェックサム値を伝える（１３５）。

［ＴＸメモリ］
ＴＸメモリ（１０４）では１つの送信要求に伴う一連の送信データを、送信要求毎、フレームペイロードＦＩＦＯにフレームペイロードの列として保存している。図３に示す様にＴＸメモリ（１０４）内部には１つの送信要求に伴い１つのＦＩＦＯが割り当てられ（３４０）、例えばここでは１つの送信要求による送信データが５つのフレームペイロードから成ることを示している。本図ではフレームペイロード１（先頭フレーム）からフレームペイロード５（最後尾フレーム）がＦＩＦＯに蓄えられているがフレーム単位での送信が行われる場合はこの様に５つのフレームが溜まることはない。各々のフレームペイロードはＦＩＦＯに挿入された直後にペイロード読み出し部（１０５）により抜き出され送信される事も考えられる。

［ペイロード読み出し部］
ペイロード読み出し部（１０５）ではヘッダ／ペイロード合成部（１２０）からの、１つのペイロード読み出し指示（１１４）に対し、送信すべきフレームペイロードを１つ取り出し、ヘッダ／ペイロード合成部（１２０）へ出力する（１１３）。

［プロトコル制御部］
プロトコル制御部（１１５）ではフレーム個数フレーム長算出部（１０２）からの指示により、フレームごとに必要なヘッダを特定してヘッダに必要な情報を収集し、各プロトコルヘッダ生成部（１１６〜１１９）にヘッダ生成指示及びヘッダ生成情報を通知する（１２２〜１２５）。図４にプロトコル制御部（１１５）のフローチャートを示す。ステップＳ１２０１においてフレーム個数フレーム長算出部（１０２）よりフレーム個数、先頭フレームのペイロード長、中間フレームのペイロード長、最終フレームのペイロード長の４つの値（１０８）を受信したかの判断を行う。もし受信すれば（ステップＳ１２０１：Ｙｅｓ）、ステップＳ１２０２において送信フレームがＴＣＰなのかＵＤＰなのかを判断し、フレーム送信に必要なプロトコルヘッダを生成するための情報を収集する（ステップＳ１２０３）。この時、収集する情報は１つのフレームに付加されるヘッダについてのみ行われる。つまり最初は先頭フレームに付加されるヘッダのみの情報収集を行う。また、収集する各種情報は静的に設定されている場合と動的にテーブル検索を行う場合がある。動的なテーブルとしては、コネクションに付随する宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート、送信元ポートを割り出すアドレステーブルや、ＩＰのルーティングテーブルなどが挙げられる。次にペイロード分割部（１０３）からフレームペイロード送信準備完了通知を受信したかの判断を行う（ステップＳ１２０４：Ｙｅｓ）。もし、フレームペイロード送信準備完了通知を受信したら、ステップＳ１２０５にてヘッダ情報の収集が終了しているかの判断を行う。ヘッダ情報の収集が終了した場合（ステップＳ１２０５：Ｙｅｓ）は、ステップＳ１２０６にて送信フレームに必要なヘッダを生成するヘッダ生成部にヘッダ生成指示及びヘッダ生成情報を出力する。ヘッダ生成指示を出力後はステップＳ１２０７においてフレーム個数分のヘッダ生成指示を行ったかの判断を行う。もし、フレーム個数分のヘッダ生成指示を行った（ステップＳ１２０７：Ｙｅｓ）のなら、ステップＳ１２０８においてステップＳ１２０６で作成を指示したヘッダのヘッダ送信完了通知をヘッダ／ペイロード合成部（１２０）から受信するのを待ち、ヘッダ送信完了通知を受信したら１つのデータグラムに対する全てのフレームのヘッダが送信されたとしてプロトコル制御を終了する。ステップＳ１２０７においてもしフレーム個数分のヘッダ生成指示を行っていないのならば（Ｓ１２０７：Ｎｏ）、まだ送信すべきフレームを生成しなければならないとして、ステップＳ１２０９においてステップＳ１２０６で作成を指示したヘッダのヘッダ送信完了通知をヘッダ／ペイロード合成部（１２０）から受信するのを待ち、ヘッダ送信完了通知を受信したら次のフレームのヘッダ作成を開始する（ステップＳ１２１０）。そしてステップＳ１２０３に戻る。

［ＴＣＰヘッダ生成部］
ＴＣＰヘッダ生成部（１１６）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知（１２６）を行う。ＴＣＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＴＣＰヘッダ情報を取得する。ＴＣＰヘッダ情報は送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、ヘッダ長、フラグビット、ウィンドウサイズ、緊急ポインタ及び擬似ヘッダ用の宛先ＩＰアドレス、送信元ＩＰアドレス、セグメント長（ＴＣＰヘッダ長＋ペイロード長）である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＴＣＰヘッダを作成する。次にフレームごとのペイロードサムをペイロード分割部（１０３）より受信し、擬似ヘッダとチェックサム以外のＴＣＰヘッダとペイロードサムからＴＣＰのチェックサムを算出し、チェックサムをＴＣＰヘッダのチェックサムフィールドに設定し、ＴＣＰヘッダの生成を完了する。ＴＣＰヘッダの生成が完了すると、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知を行い、ＴＣＰヘッダ生成を終了し、プロトコル制御部（１１５）より次のヘッダ生成指示があるまで待機する。ＴＣＰヘッダ生成部（１１６）で作成するヘッダのフォーマットを図６に、擬似ヘッダフォーマットを図７に示す。

また、ＴＣＰヘッダ生成部（１１６）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２６）を受信すると、生成したＴＣＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３０）する。

［ＵＤＰヘッダ生成部］
ＵＤＰヘッダ生成部（１１７）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知（１２７）を行う。ＵＤＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＵＤＰヘッダ情報を取得する。ＵＤＰヘッダ情報は、送信元ポート番号、宛先ポート番号、ＵＤＰデータ長である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＵＤＰヘッダを作成する。次にペイロードサムをペイロード分割部（１０３）より受信したかの判断を行い、もし受信していれば擬似ヘッダとチェックサム以外のＵＤＰヘッダとペイロードサムの合計からＵＤＰチェックサムを算出し、チェックサムをＵＤＰヘッダのチェックサムフィールドに設定し、ＵＤＰヘッダの生成を完了する。ＵＤＰヘッダの生成が完了すると、ヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知を行い、ＵＤＰヘッダ生成を終了する。

ただし、ＵＤＰヘッダのチェックサムはオプションでの対応となっているため、ＵＤＰチェックサムを行わない設定にした場合は、プロトコル制御部（１１５）よりＵＤＰヘッダ情報（送信元ポート番号、宛先ポート番号、ＵＤＰデータ長）を取得した時点で、ＵＤＰチェックサムフィールドに０を設定し、ＵＤＰヘッダ生成完了通知をヘッダ／ペイロード合成部（１２０）に出力する。

ＵＤＰヘッダ生成部で作成するヘッダのフォーマットを図８に、擬似ヘッダフォーマットを図９に示す。

また、ＵＤＰヘッダ生成部（１１７）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２７）を受信すると、生成したＵＤＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３１）する。

［ＩＰヘッダ生成部］
ＩＰヘッダ生成部（１１８）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知（１２８）を行う。ＩＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＩＰヘッダ情報を取得する。ＩＰヘッダ情報はバージョン、ヘッダ長、ＴＯＳ、全長、識別子、フラグ、フラグメントオフセット、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスである。これらの情報からＩＰヘッダのヘッダチェックサムを算出してＩＰヘッダを完成させ、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知を行う。ＩＰヘッダ生成部で作成するヘッダのフォーマットを図１０に示す。

また、ＩＰヘッダ生成部（１１８）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２８）を受信すると、生成した順番にＩＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３２）する。

［ＭＡＣヘッダ生成部］
ＭＡＣヘッダ生成部（１１９）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了通知（１２９）を行う。ＭＡＣヘッダ生成部（１１９）はプロトコル制御部（１１５）からＭＡＣヘッダ生成指示を受信したら、ＭＡＣヘッダ情報を取得する。ＭＡＣヘッダ生成情報は、ヘッダ生成数、送信元ＭＡＣアドレス、宛先ＭＡＣアドレス、タイプレングスである。これらの情報からＭＡＣヘッダを完成させ、ヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了通知を行う。ＭＡＣヘッダ生成部で作成するＭＡＣヘッダのフォーマットを図１１に示す。

また、ＭＡＣヘッダ生成部（１１９）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２９）を受信すると、生成したＭＡＣヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３３）する。

［ヘッダ／ペイロード合成部］
ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）からのフレーム個数から生成すべきヘッダの種類とその個数を割り出す。次に、各プロトコルヘッダ生成部からのヘッダ完了通知により、送信フレームに必要なヘッダが完了していることを認識し、ＴＣＰ／ＩＰの場合はＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＴＣＰヘッダ生成部（１１６）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成し、フレーム送出部（１２１）に出力する。ＵＤＰ／ＩＰの場合は先頭フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＵＤＰヘッダ生成部（１１７）、ペイロード読み出し部（１０５）の順に出力要求を行い、中間、最終フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成しフレーム送出部（１２１）に出力する。ペイロードを持たないフレームを送信する場合はヘッダのみ読み出して、フレームとして合成し、フレーム送出部（１２１）に出力する。ヘッダ／ペイロード合成部（１２０）は、ヘッダをフレーム送出部（１２１）に出力した時点で、プロトコル制御部（１１５）にヘッダ送信完了（１３７）を出力する。

［フレーム送出部］
フレーム送出（送信）部（１２１）では、ヘッダ／ペイロード合成部（１２０）から出力されるフレームを通信制御装置外に送信する機能を有する。ＩＥＥＥ８０２．３に準拠し、プリアンブルの付加、フレームパディング、ＣＲＣの生成等を行う。

＜ＴＣＰセグメントの送信例＞
ＴＣＰ／ＩＰのフレーム送信時に送信データグラムが３つのセグメントに分割された場合の例を図５に示す。アプリケーションデバイス（１０１）からの送信指示及び送信データ長（１３０１）を受けてフレーム個数フレーム長算出部（１０２）は、フレーム個数（３個）、先頭フレームのペイロード長（ＰＬ０の長さ）、中間フレームのペイロード長（ＰＬ１の長さ）、最終フレームのペイロード長（ＰＬ２の長さ）をプロトコル制御部（１１５）及びヘッダ／ペイロード合成部（１２０）に出力（１３０２）する。プロトコル制御部（１１５）ではプロトコルタイプをＴＣＰであると判断し、ＴＣＰ、ＩＰ、ＭＡＣのヘッダ情報の収集を行う。またペイロード分割部（１０３）においてペイロードをＴＸメモリ（１０４）に書き込んでいき、１フレーム分（１ＴＣＰセグメント分）書き込みが完了すると、プロトコル制御部（１１５）に対してフレームペイロード送信準備完了（１３０３）を出力する。プロトコル制御部（１１５）はフレームペイロード送信準備完了（１３０３）を受信するとデータグラムをセグメント化した先頭フレームのＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了しているかを判断し、終了していればＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３０４）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３０５）を、ＭＡＣヘッダ生成部（１１９）にヘッダ生成指示及びヘッダ情報（１３０６）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３０７）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３０８）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３０９）を出力する。ヘッダ生成指示を受信したＭＡＣヘッダ生成部（１１９）はプロトコル制御部（１１５）からのヘッダ情報からＭＡＣヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了（１３１０）をフレーム個数分出力する。ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの先頭フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３０８）、ＩＰヘッダ生成完了（１３０９）、ＭＡＣヘッダ生成完了（１３１０）の全てを受信するとフレームを送信可能な状態であると判断する。ヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に先頭フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部（１２１）に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３１１）を出力する。

プロトコル制御部（１１５）はヘッダ送信完了（１３１１）を受信すると次のフレーム、つまりここでは３つにセグメント化されたフレームの中間フレームのヘッダ情報収集を行う。中間フレームに必要なヘッダは先頭と同様にＴＣＰ、ＩＰ、ＭＡＣヘッダの情報収集を行う。ペイロード分割部（１０３）からの次のフレームペイロード送信準備完了（１３１２）を受信すると、中間フレームのＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了しているかを判断し、終了していればＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３１３）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３１４）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３１５）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３１６）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部（１１８）はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３１７）を出力する。

ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの中間フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３１６）、ＩＰヘッダ生成完了（１３１７）を受信するとフレームを送信可能な状態であると判断する。ＭＡＣヘッダ生成完了については先頭フレームの時にフレーム個数分出力されているため、ヘッダ／ペイロード合成部（１２０）はこの時点で中間フレームのＭＡＣヘッダ生成が完了していると判断している。フレームが送信可能な状態であると判断したヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に中間フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３２０）を出力する。

プロトコル制御部（１１５）はヘッダ送信完了（１３２０）を受信すると次のフレーム、つまりここでは３つにセグメント化されたフレームの最終フレームのヘッダ情報収集を行う。最終フレームに必要なヘッダは先頭、中間と同様にＴＣＰ、ＩＰ、ＭＡＣヘッダの情報収集を行う。ペイロード分割部（１０３）からの次のフレームペイロード送信準備完了（１３１８）をすでに受信しているので、ＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了し次第、ＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３２１）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３２２）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３１９）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３２３）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部（１１８）はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３２４）を出力する。

ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの最終フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３２３）、ＩＰヘッダ生成完了（１３２４）を受信するとフレームを送信可能な状態であると判断する。ＭＡＣヘッダ生成完了については先頭フレームの時にフレーム個数分出力されているため、ヘッダ／ペイロード合成部（１２０）はこの時点で中間フレームのＭＡＣヘッダ生成が完了していると判断している。フレームが送信可能な状態であると判断したヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に最終フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３２５）を出力する。

以上のように、本実施形態によれば、アプリケーションデバイス（１０１）から任意の長さの送信データを受信し、サポートするデータリンク層に適切なフレームサイズでフレーム出力する通信制御装置が提供される。プロトコル制御部（１０１）は、フレーム生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力する。ヘッダ生成手段（１１６〜１１９）は、プロトコル制御部（１１５）からヘッダ生成指示及びヘッダ生成情報を入力すると、ヘッダを１ヘッダ毎に生成し、ヘッダ生成完了通知を出力する。ヘッダ／ペイロード合成部（１２０）は、ヘッダ生成部（１１６〜１１９）からヘッダ生成完了通知を入力すると、生成されたヘッダ及びフレーム単位のペイロードをフレームとして合成する。プロトコル制御部（１１５）は、所望のヘッダの生成指示をヘッダ生成部（１１６〜１１９）に出力することができる。

ＴＸメモリ（１０４）は、フレーム単位のペイロードを記憶するためのメモリである。プロトコル制御部（１１５）は、ヘッダ／ペイロード合成部（１２０）が１つ前のフレームとして合成したヘッダを出力した後、かつ次のペイロードがＴＸメモリ（１０４）に書き込まれた後に、次のフレームのヘッダ生成指示をヘッダ生成部（１１６〜１１９）に出力する。

本実施形態によれば、リンク層に依存するＭＴＵに対して、アプリケーションの転送単位が大きくなるにつれて分割後に発生するフレームが増加しても、フレーム単位でヘッダを生成し送信することで、フレームに付加しなければならないヘッダを書き込むためのメモリ領域を確保する必要がなくなる。

なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の実施形態による通信制御装置の構成図である。 ペイロード長とヘッダ数算出の流れを示すフローチャートである。 ＴＸメモリを示す図である。 プロトコル制御部のフローチャートである。 シーケンス１を示す図である。 ＴＣＰヘッダフォーマットを示す図である。 ＴＣＰ擬似ヘッダフォーマットを示す図である。 ＵＤＰヘッダフォーマットを示す図である。 ＵＤＰ擬似ヘッダフォーマットを示す図である。 ＩＰヘッダフォーマットを示す図である。 ＭＡＣヘッダフォーマットを示す図である。

符号の説明

１０１ アプリケーションデバイス
１０２ フレーム個数フレーム長算出部
１０３ ペイロード分割部
１０４ ＴＸメモリ
１０５ ペイロード読み出し部
１１５ プロトコル制御部
１１６ ＴＣＰヘッダ生成部
１１７ ＵＤＰヘッダ生成部
１１８ ＩＰヘッダ生成部
１１９ ＭＡＣヘッダ生成部
１２０ ヘッダ／ペイロード合成部
１２１ フレーム送出部

Claims (11)

1. 複数レイヤのプロトコルのヘッダ生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力するプロトコル制御手段と、
   前記プロトコル制御手段から前記ヘッダ生成指示及び前記ヘッダ生成情報が入力されると、複数レイヤのプロトコルのヘッダを並列して１ヘッダ毎に生成し、ヘッダ生成完了通知を出力するヘッダ生成手段と、
   前記ヘッダ生成手段から前記ヘッダ生成完了通知が入力されると、前記生成された複数レイヤのプロトコルのヘッダ及びフレーム単位のペイロードをフレームとして合成するヘッダ／ペイロード合成手段と
   を有することを特徴とする通信制御装置。
2. 前記ヘッダ生成手段は、
   ＴＣＰヘッダを１ヘッダ毎に生成するＴＣＰヘッダ生成手段と、
   ＵＤＰヘッダを１ヘッダ毎に生成するＵＤＰヘッダ生成手段と、
   ＩＰヘッダを１ヘッダ毎に生成するＩＰヘッダ生成手段と、
   ＭＡＣヘッダを１ヘッダ毎に生成するＭＡＣヘッダ生成手段とを有し、
   前記プロトコル制御手段は、前記ＴＣＰヘッダ生成手段、前記ＵＤＰヘッダ生成手段、前記ＩＰヘッダ生成手段及び前記ＭＡＣヘッダ生成手段にヘッダの生成指示を出力することができることを特徴とする請求項１記載の通信制御装置。
3. 前記プロトコル制御手段は、前記ヘッダ／ペイロード合成手段が１つ前のフレームとして合成したヘッダを出力した後に、次のフレームのヘッダ生成指示を前記ヘッダ生成手段に出力することを特徴とする請求項１又は２記載の通信制御装置。
4. さらに、フレーム単位のペイロードを記憶するためのメモリを有し、
   前記プロトコル制御手段は、ペイロードが前記メモリに書き込まれた後に、そのペイロードに対応するヘッダ生成指示を前記ヘッダ生成手段に出力することを特徴とする請求項１又は２記載の通信制御装置。
5. さらに、フレーム単位のペイロードを記憶するためのメモリを有し、
   前記プロトコル制御手段は、前記ヘッダ／ペイロード合成手段が１つ前のフレームとして合成したヘッダを出力した後、かつ次のペイロードが前記メモリに書き込まれた後に、次のフレームのヘッダ生成指示を前記ヘッダ生成手段に出力することを特徴とする請求項１又は２記載の通信制御装置。
6. さらに、前記ヘッダ／ペイロード合成手段により合成されたフレームを送信するフレーム送信手段を有することを特徴とする請求項１〜５のいずれか１項に記載の通信制御装置。
7. さらに、送信データをフレーム単位のペイロードに分割するペイロード分割手段を有することを特徴とする請求項１〜６のいずれか１項に記載の通信制御装置。
8. さらに、前記ペイロード分割手段により分割されたフレーム単位のペイロードを記憶するためのメモリを有することを特徴とする請求項７記載の通信制御装置。
9. さらに、前記メモリからフレーム単位のペイロードを読み出して前記ヘッダ／ペイロード合成手段に出力するペイロード読み出し手段を有することを特徴とする請求項８記載の通信制御装置。
10. さらに、送信データ長を基にフレーム個数及びフレーム長を算出するフレーム個数フレーム長算出手段を有し、
    前記ペイロード分割手段は、前記算出されたフレーム個数及びフレーム長を基にペイロードの分割を行うことを特徴とする請求項７〜９のいずれか１項に記載の通信制御装置。
11. 通信制御装置が行う通信制御方法であって、
    複数レイヤのプロトコルのヘッダ生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力するプロトコル制御ステップと、
    前記ヘッダ生成指示及び前記ヘッダ生成情報が入力されると、複数レイヤのプロトコルのヘッダを並列して１ヘッダ毎に生成し、ヘッダ生成完了通知を出力するヘッダ生成ステップと、
    前記ヘッダ生成完了通知が入力されると、前記生成された複数レイヤのプロトコルのヘッダ及びフレーム単位のペイロードをフレームとして合成するヘッダ／ペイロード合成ステップと
    を有することを特徴とする通信制御方法。

Images