JP3275664B2 - 受信パケット情報管理システム - Google Patents
受信パケット情報管理システムInfo
- Publication number
- JP3275664B2 JP3275664B2 JP28961795A JP28961795A JP3275664B2 JP 3275664 B2 JP3275664 B2 JP 3275664B2 JP 28961795 A JP28961795 A JP 28961795A JP 28961795 A JP28961795 A JP 28961795A JP 3275664 B2 JP3275664 B2 JP 3275664B2
- Authority
- JP
- Japan
- Prior art keywords
- received packet
- length
- buffer
- trailer
- received
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、Ｂ−ＩＳＤＮ（Ｂ
チャネル−サービス総合デジタル通信網）におけるＡＴ
Ｍ（非同期転送モード）等に新たに適用されたＩＴＵ−
Ｔ勧告Ｑ．２１１０のプロトコルによるパケット伝送技
術に係り、特に、受信パケットの管理を効率良く行なう
のに好適な受信パケット情報管理システムに関するもの
である。
チャネル−サービス総合デジタル通信網）におけるＡＴ
Ｍ（非同期転送モード）等に新たに適用されたＩＴＵ−
Ｔ勧告Ｑ．２１１０のプロトコルによるパケット伝送技
術に係り、特に、受信パケットの管理を効率良く行なう
のに好適な受信パケット情報管理システムに関するもの
である。
【０００２】
【従来の技術】従来、パケット伝送技術においては、パ
ケットのヘッダに、パケット種別やシーケンス番号等、
パケットの制御情報が格納されているが、ＩＴＵ−Ｔ勧
告Ｑ．２１１０のプロトコルにおいては、図３に示すよ
うに、ヘッダが無く、情報部の後のトレイラ（最後尾に
あるフィールド）に、パケットタイプやシーケンサ番号
等のパケットの制御情報を格納する。従来も、パケット
のビットエラーのチェックのため、ＣＲＣ（Cyclic Red
undancy Check、巡回冗長検査）をトレイラに格納する
プロトコルはあったが、この場合、ＣＲＣのサイズが固
定なため、この部分の判別が容易であり、この部分だけ
をバッファに格納しないとの制御が可能であった。
ケットのヘッダに、パケット種別やシーケンス番号等、
パケットの制御情報が格納されているが、ＩＴＵ−Ｔ勧
告Ｑ．２１１０のプロトコルにおいては、図３に示すよ
うに、ヘッダが無く、情報部の後のトレイラ（最後尾に
あるフィールド）に、パケットタイプやシーケンサ番号
等のパケットの制御情報を格納する。従来も、パケット
のビットエラーのチェックのため、ＣＲＣ（Cyclic Red
undancy Check、巡回冗長検査）をトレイラに格納する
プロトコルはあったが、この場合、ＣＲＣのサイズが固
定なため、この部分の判別が容易であり、この部分だけ
をバッファに格納しないとの制御が可能であった。
【０００３】しかし、ＩＴＵ−Ｔ勧告Ｑ．２１１０のプ
ロトコルにおいては、トレイラにパケットの制御情報を
格納しており、さらに、トレイラは、パケットの種別に
より長さが異なる。そのため、受信時には、受信したパ
ケットを、一旦、全てバッファに格納し、その後、バッ
ファの最後からトレイラを読み出してプロトコル処理を
行なう必要がある。
ロトコルにおいては、トレイラにパケットの制御情報を
格納しており、さらに、トレイラは、パケットの種別に
より長さが異なる。そのため、受信時には、受信したパ
ケットを、一旦、全てバッファに格納し、その後、バッ
ファの最後からトレイラを読み出してプロトコル処理を
行なう必要がある。
【０００４】図４は、ＩＴＵ−Ｔ勧告Ｑ．２１１０のプ
ロトコルにより受信したパケットを格納するチェーン状
バッファの構成例を示す説明図である。本図４に示すよ
うに、受信パケットは、バッファの先頭から格納されて
いき、もし、受信パケットの長さがバッファ一つのサイ
ズより長い場合、パケットの残りの部分は、二つ目のバ
ッファに格納され、それぞれの（二つの）バッファは、
ポインタにより、チェーン状に連結される。そして、受
信したパケットに対するプロトコル処理が終了すると、
パケットの受信通知を、連結状態を示す情報等からなる
バッファ情報と共に、上位のレイヤに通知する。
ロトコルにより受信したパケットを格納するチェーン状
バッファの構成例を示す説明図である。本図４に示すよ
うに、受信パケットは、バッファの先頭から格納されて
いき、もし、受信パケットの長さがバッファ一つのサイ
ズより長い場合、パケットの残りの部分は、二つ目のバ
ッファに格納され、それぞれの（二つの）バッファは、
ポインタにより、チェーン状に連結される。そして、受
信したパケットに対するプロトコル処理が終了すると、
パケットの受信通知を、連結状態を示す情報等からなる
バッファ情報と共に、上位のレイヤに通知する。
【０００５】しかし、このようなＩＴＵ−Ｔ勧告Ｑ．２
１１０のプロトコルでは、例えば、図５に示すように、
パケットの情報部がちょうどバッファ一つのサイズに等
しい場合、二つ目のバッファ（図５中の下側のバッフ
ァ）には、トレイラのみが格納される。その結果、この
二つ目のバッファには、上位レイヤにとって必要な情報
は存在しない。このように最後のバッファには有効情報
が無いことを、上位レイヤに受信報告を通知する時に、
合わせて示す必要がある。
１１０のプロトコルでは、例えば、図５に示すように、
パケットの情報部がちょうどバッファ一つのサイズに等
しい場合、二つ目のバッファ（図５中の下側のバッフ
ァ）には、トレイラのみが格納される。その結果、この
二つ目のバッファには、上位レイヤにとって必要な情報
は存在しない。このように最後のバッファには有効情報
が無いことを、上位レイヤに受信報告を通知する時に、
合わせて示す必要がある。
【０００６】
【発明が解決しようとする課題】解決しようとする問題
点は、従来の技術では、ＩＴＵ−Ｔ勧告Ｑ．２１１０の
プロトコルで受信したパケットを格納したチェーン状の
バッファに、トレイラのみを格納した状態を判断するこ
とができない点である。本発明の目的は、これら従来技
術の課題を解決し、上位レイヤに、最後のバッファには
有効情報が無いことを通知することを可能とする受信パ
ケット情報管理システムを提供することである。
点は、従来の技術では、ＩＴＵ−Ｔ勧告Ｑ．２１１０の
プロトコルで受信したパケットを格納したチェーン状の
バッファに、トレイラのみを格納した状態を判断するこ
とができない点である。本発明の目的は、これら従来技
術の課題を解決し、上位レイヤに、最後のバッファには
有効情報が無いことを通知することを可能とする受信パ
ケット情報管理システムを提供することである。
【０００７】
【課題を解決するための手段】上記目的を達成するた
め、本発明の受信パケット情報管理システムは、（１）
ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルに基づき送ら
れてきた受信パケットを、チェーン状のバッファ（バッ
ファメモリ１）に格納するシステムであって、受信パケ
ットの長さをカウントする手段（受信パケット長カウン
タ８）と、受信パケットのトレイラの長さを読み出す手
段（トレイラ読み出し部２）と、受信パケット長カウン
タ８でカウントした受信パケットの長さと、トレイラ読
み出し部２で読み出したトレイラの長さ、および、予め
決まっているバッファメモリ１の一つのバッファのサイ
ズに基づき、バッファメモリ１の最終バッファに、受信
パケットの情報フィールドがあるか否かを判断する手段
（データ有無判断部５）と、このデータ有無判断部５の
判断結果を付与して上位レイヤに対する受信報告を作成
する手段（報告作成部６）とを少なくとも有し、作成し
た受信報告を、上位インタフェース部７を介して上位レ
イヤに送出することを特徴とする。また、（２）上記
（１）に記載の受信パケット情報管理システムにおい
て、トレイラ読み出し部２は、受信パケットの種別を判
別し、この種別に対応するトレイラ長を探索して、トレ
イラの長さの読み出しを行なうことを特徴とする。ま
た、（３）上記（１）もしくは（２）のいずれかに記載
の受信パケット情報管理システムにおいて、データ有無
判断部５は、受信パケットの長さをバッファ一つのサイ
ズで割算し、この割算の余りが、トレイラ読み出し部２
で読み出したトレイラ長と等しい場合、バッファメモリ
１の最終バッファに情報フィールドはないと判断するこ
とを特徴とする。また、（４）上記（１）から（３）の
いずれかに記載の受信パケット情報管理システムにおい
て、受信パケット長カウンタ８は、受信パケットの長さ
をワード単位でカウントすることを特徴とする。
め、本発明の受信パケット情報管理システムは、（１）
ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルに基づき送ら
れてきた受信パケットを、チェーン状のバッファ（バッ
ファメモリ１）に格納するシステムであって、受信パケ
ットの長さをカウントする手段（受信パケット長カウン
タ８）と、受信パケットのトレイラの長さを読み出す手
段（トレイラ読み出し部２）と、受信パケット長カウン
タ８でカウントした受信パケットの長さと、トレイラ読
み出し部２で読み出したトレイラの長さ、および、予め
決まっているバッファメモリ１の一つのバッファのサイ
ズに基づき、バッファメモリ１の最終バッファに、受信
パケットの情報フィールドがあるか否かを判断する手段
（データ有無判断部５）と、このデータ有無判断部５の
判断結果を付与して上位レイヤに対する受信報告を作成
する手段（報告作成部６）とを少なくとも有し、作成し
た受信報告を、上位インタフェース部７を介して上位レ
イヤに送出することを特徴とする。また、（２）上記
（１）に記載の受信パケット情報管理システムにおい
て、トレイラ読み出し部２は、受信パケットの種別を判
別し、この種別に対応するトレイラ長を探索して、トレ
イラの長さの読み出しを行なうことを特徴とする。ま
た、（３）上記（１）もしくは（２）のいずれかに記載
の受信パケット情報管理システムにおいて、データ有無
判断部５は、受信パケットの長さをバッファ一つのサイ
ズで割算し、この割算の余りが、トレイラ読み出し部２
で読み出したトレイラ長と等しい場合、バッファメモリ
１の最終バッファに情報フィールドはないと判断するこ
とを特徴とする。また、（４）上記（１）から（３）の
いずれかに記載の受信パケット情報管理システムにおい
て、受信パケット長カウンタ８は、受信パケットの長さ
をワード単位でカウントすることを特徴とする。
【０００８】
【発明の実施の形態】本発明においては、ＩＴＵ−Ｔ勧
告Ｑ．２１１０のプロトコルに基づき送られてきたパケ
ットが到着すると、受信パケット長カウンタ８は、受信
したパケットのパケット長のカウントを始め、パケット
受信が完了すると、その長さをプロトコル処理部３に通
知する。また、バッファ管理部４も、受信の終了と、受
信パケットを格納したバッファのアドレス、および、バ
ッファの個数を、プロトコル処理部３に通知する。これ
らの通知に基づき、プロトコル処理部３は、トレイラ読
み出し部２に、トレイラの読み出しを指示し、トレイラ
読み出し部２は、バッファから、受信パケットの最後尾
の一ワードの内容を読み出し、プロトコル処理部３に渡
す。
告Ｑ．２１１０のプロトコルに基づき送られてきたパケ
ットが到着すると、受信パケット長カウンタ８は、受信
したパケットのパケット長のカウントを始め、パケット
受信が完了すると、その長さをプロトコル処理部３に通
知する。また、バッファ管理部４も、受信の終了と、受
信パケットを格納したバッファのアドレス、および、バ
ッファの個数を、プロトコル処理部３に通知する。これ
らの通知に基づき、プロトコル処理部３は、トレイラ読
み出し部２に、トレイラの読み出しを指示し、トレイラ
読み出し部２は、バッファから、受信パケットの最後尾
の一ワードの内容を読み出し、プロトコル処理部３に渡
す。
【０００９】この受信パケットの最後尾の一ワード部分
には、パケットの種別を示すコード等が格納されている
ので、プロトコル処理部３は、まず、このコードから、
パケットの種別を判別する。トレイラの長さはパケット
種別ごとに決まっているため、プロトコル処理部３は、
判別したパケット種別に対応するトレイラ長を読み取
り、そして、読み取ったトレイラ長に基づき、残りのト
レイラをバッファメモリ１から読み出す。さらに、プロ
トコル処理部３は、プロトコル処理後、データ有無判断
部５に、受信パケット長とトレイラ長を通知する。
には、パケットの種別を示すコード等が格納されている
ので、プロトコル処理部３は、まず、このコードから、
パケットの種別を判別する。トレイラの長さはパケット
種別ごとに決まっているため、プロトコル処理部３は、
判別したパケット種別に対応するトレイラ長を読み取
り、そして、読み取ったトレイラ長に基づき、残りのト
レイラをバッファメモリ１から読み出す。さらに、プロ
トコル処理部３は、プロトコル処理後、データ有無判断
部５に、受信パケット長とトレイラ長を通知する。
【００１０】これらの受信パケット長とトレイラ長など
を基に、データ有無判断部５は、最終バッファに情報部
があるか否かを判断する。すなわち、バッファメモリ１
を構成する一つのバッファのサイズは予め決められてい
るので、データ有無判断部５は、受信パケット長を、バ
ッファ一つのサイズで割算し、その余りがトレイラ長よ
り大きければ、最終バッファに情報部があると判断でき
る。また、余りがトレイラ長と等しければ、最終バッフ
ァに情報部は無いと判断できる。データ有無判断部５
が、この判断結果を報告作成部６に通知し、報告作成部
６は、上位レイヤへの受信報告に、最終バッファ中の情
報部の有無を含める。このようにして、上位レイヤに、
最終バッファ中の情報部の有無を通知することができ
る。
を基に、データ有無判断部５は、最終バッファに情報部
があるか否かを判断する。すなわち、バッファメモリ１
を構成する一つのバッファのサイズは予め決められてい
るので、データ有無判断部５は、受信パケット長を、バ
ッファ一つのサイズで割算し、その余りがトレイラ長よ
り大きければ、最終バッファに情報部があると判断でき
る。また、余りがトレイラ長と等しければ、最終バッフ
ァに情報部は無いと判断できる。データ有無判断部５
が、この判断結果を報告作成部６に通知し、報告作成部
６は、上位レイヤへの受信報告に、最終バッファ中の情
報部の有無を含める。このようにして、上位レイヤに、
最終バッファ中の情報部の有無を通知することができ
る。
【００１１】
【実施例】以下、本発明の実施例を、図面により詳細に
説明する。図１は、本発明の受信パケット情報管理シス
テムの本発明に係る構成の一実施例を示すブロック図で
ある。本図１において、１は受信したパケットを格納す
るチェーン状のバッファ構成のバッファメモリ、２は受
信したパケットのトレイラを読み出すトレイラ読み出し
部、３はトレイラに基づきプロトコル処理を行なうプロ
トコル処理部、４は受信したパケットのバッファメモリ
１への転送やバッファメモリ１の空き領域／格納済み領
域などの情報およびバッファメモリ１の一つのバッファ
のサイズ等を管理するバッファ管理部、５は受信したパ
ケットの長（パケット長）とバッファのサイズおよびト
レイラの長さから最終バッファに情報部があるか否かを
判断するデータ有無判断部、６はプロトコル処理部３の
処理結果に基づき上位レイヤに対する報告を作成する報
告作成部、７は報告作成部６で作成した報告の上位レイ
ヤへの通知を含む上位レイヤとのコマンド・報告をやり
取りする上位インタフェース部、８は受信したパケット
の長さをカウントする受信パケット長カウンタ、９は受
信パケットが伝送されてくる回線である。
説明する。図１は、本発明の受信パケット情報管理シス
テムの本発明に係る構成の一実施例を示すブロック図で
ある。本図１において、１は受信したパケットを格納す
るチェーン状のバッファ構成のバッファメモリ、２は受
信したパケットのトレイラを読み出すトレイラ読み出し
部、３はトレイラに基づきプロトコル処理を行なうプロ
トコル処理部、４は受信したパケットのバッファメモリ
１への転送やバッファメモリ１の空き領域／格納済み領
域などの情報およびバッファメモリ１の一つのバッファ
のサイズ等を管理するバッファ管理部、５は受信したパ
ケットの長（パケット長）とバッファのサイズおよびト
レイラの長さから最終バッファに情報部があるか否かを
判断するデータ有無判断部、６はプロトコル処理部３の
処理結果に基づき上位レイヤに対する報告を作成する報
告作成部、７は報告作成部６で作成した報告の上位レイ
ヤへの通知を含む上位レイヤとのコマンド・報告をやり
取りする上位インタフェース部、８は受信したパケット
の長さをカウントする受信パケット長カウンタ、９は受
信パケットが伝送されてくる回線である。
【００１２】このような構成により、本実施例の受信パ
ケット情報管理システムでは、ＩＴＵ−Ｔ勧告Ｑ．２１
１０のプロトコルに基づくパケットの受信、および、受
信したパケットの管理動作を行なう。以下、その動作の
説明を行なう。まず、回線９からパケットが到着する
と、バッファ管理部４は、受信したパケットをバッファ
メモリ１に転送する。この時、従来技術の説明で用いた
図４に示すように、バッファメモリ１の内部はチェーン
状に管理されており、このチェーンの先頭から受信パケ
ットは格納されていく。同時に、受信パケット長カウン
タ８は、受信パケットの長さをワード単位でカウントす
る。
ケット情報管理システムでは、ＩＴＵ−Ｔ勧告Ｑ．２１
１０のプロトコルに基づくパケットの受信、および、受
信したパケットの管理動作を行なう。以下、その動作の
説明を行なう。まず、回線９からパケットが到着する
と、バッファ管理部４は、受信したパケットをバッファ
メモリ１に転送する。この時、従来技術の説明で用いた
図４に示すように、バッファメモリ１の内部はチェーン
状に管理されており、このチェーンの先頭から受信パケ
ットは格納されていく。同時に、受信パケット長カウン
タ８は、受信パケットの長さをワード単位でカウントす
る。
【００１３】パケットが最後まで到着し、バッファメモ
リ１への格納が終了すると、バッファ管理部４は、プロ
トコル処理部３に受信の終了と、受信パケットを格納し
たバッファのアドレスおよびバッファの個数を通知す
る。また、受信パケット長カウンタ８は、プロトコル処
理部３に、カウント結果である受信したパケットの長さ
（パケット長）を通知する。プロトコル処理部３は、バ
ッファ管理部４から受け取ったバッファアドレスとバッ
ファの個数から、トレイラが格納されているバッファメ
モリ１内のアドレスを計算し、読み出しの指示を、トレ
イラ読み出し部２に送出する。
リ１への格納が終了すると、バッファ管理部４は、プロ
トコル処理部３に受信の終了と、受信パケットを格納し
たバッファのアドレスおよびバッファの個数を通知す
る。また、受信パケット長カウンタ８は、プロトコル処
理部３に、カウント結果である受信したパケットの長さ
（パケット長）を通知する。プロトコル処理部３は、バ
ッファ管理部４から受け取ったバッファアドレスとバッ
ファの個数から、トレイラが格納されているバッファメ
モリ１内のアドレスを計算し、読み出しの指示を、トレ
イラ読み出し部２に送出する。
【００１４】この指示に基づき、トレイラ読み出し部２
は、トレイラを、まず一ワード読みだし、プロトコル処
理部３に渡す。プロトコル処理部３は、渡されたトレイ
ラから、パケット種別を判別し、トレイラの長さを求め
る。これを、再度、トレイラ読み出し部２に通知する。
この通知に基づき、トレイラ読み出し部２は、残りのト
レイラを読みだし、プロトコル処理部３に渡す。プロト
コル処理部３は、トレイラの内容からプロトコル処理を
行なう。そして、プロトコル処理が終了し、受信したパ
ケットが上位レイヤに渡すべき情報パケットであれば、
バッファアドレスとバッファの個数を報告作成部６に渡
す。同時に、データ有無判断部５に、受信パケット長、
およびトレイラ長を渡す。
は、トレイラを、まず一ワード読みだし、プロトコル処
理部３に渡す。プロトコル処理部３は、渡されたトレイ
ラから、パケット種別を判別し、トレイラの長さを求め
る。これを、再度、トレイラ読み出し部２に通知する。
この通知に基づき、トレイラ読み出し部２は、残りのト
レイラを読みだし、プロトコル処理部３に渡す。プロト
コル処理部３は、トレイラの内容からプロトコル処理を
行なう。そして、プロトコル処理が終了し、受信したパ
ケットが上位レイヤに渡すべき情報パケットであれば、
バッファアドレスとバッファの個数を報告作成部６に渡
す。同時に、データ有無判断部５に、受信パケット長、
およびトレイラ長を渡す。
【００１５】データ有無判断部５は、渡されたパケット
長を、バッファメモリ１を構成しているバッファ一つの
サイズで割算し、その余りが、渡されたトレイラ長より
長ければ、最終バッファに情報部があると判断する。ま
た、余りがトレイラ長と等しければ、情報部は無いと判
断する。そして、データ有無判断部５は、この結果を、
報告作成部６に通知する。このデータ有無判断部５から
の通知に基づき、報告作成部６は、上位レイヤへの報告
を、図２に示すフォーマットで、すなわち、「報告種
別」、「リンク番号」、「バッファ情報（ポインタのア
ドレス）」の各情報と共に、「最終バッファの情報の有
無」を示す情報を付与して作成し、これを上位レイヤイ
ンタフェース部７に渡す。そして、インタフェース部７
は、この報告を上位レイヤに渡す。
長を、バッファメモリ１を構成しているバッファ一つの
サイズで割算し、その余りが、渡されたトレイラ長より
長ければ、最終バッファに情報部があると判断する。ま
た、余りがトレイラ長と等しければ、情報部は無いと判
断する。そして、データ有無判断部５は、この結果を、
報告作成部６に通知する。このデータ有無判断部５から
の通知に基づき、報告作成部６は、上位レイヤへの報告
を、図２に示すフォーマットで、すなわち、「報告種
別」、「リンク番号」、「バッファ情報（ポインタのア
ドレス）」の各情報と共に、「最終バッファの情報の有
無」を示す情報を付与して作成し、これを上位レイヤイ
ンタフェース部７に渡す。そして、インタフェース部７
は、この報告を上位レイヤに渡す。
【００１６】以上、図１、および、図２を用いて説明し
たように、本実施例の受信パケット情報管理システムで
は、ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルに基づき
送られてきたパケットの長さ、および、トレイラ長を求
め、パケット長をバッファサイズで割算して、その余り
が、トレイラ長に等しいか否かにより、最終バッファ中
における有効情報の有無を判断することができる。尚、
本発明は、図１、および、図２を用いて説明した実施例
に限定されるものではなく、その要旨を逸脱しない範囲
において種々変更可能である。
たように、本実施例の受信パケット情報管理システムで
は、ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルに基づき
送られてきたパケットの長さ、および、トレイラ長を求
め、パケット長をバッファサイズで割算して、その余り
が、トレイラ長に等しいか否かにより、最終バッファ中
における有効情報の有無を判断することができる。尚、
本発明は、図１、および、図２を用いて説明した実施例
に限定されるものではなく、その要旨を逸脱しない範囲
において種々変更可能である。
【００１７】
【発明の効果】本発明によれば、ＩＴＵ−Ｔ勧告Ｑ．２
１１０のプロトコルで受信したパケットを格納したチェ
ーン状のバッファに、トレイラのみを格納した状態を判
断することができ、上位レイヤに、最後のバッファには
有効情報が無いことを通知することが可能であり、受信
パケットの管理を効率良く行なうことができる。
１１０のプロトコルで受信したパケットを格納したチェ
ーン状のバッファに、トレイラのみを格納した状態を判
断することができ、上位レイヤに、最後のバッファには
有効情報が無いことを通知することが可能であり、受信
パケットの管理を効率良く行なうことができる。
【図１】本発明の受信パケット情報管理システムの本発
明に係る構成の一実施例を示すブロック図である。
明に係る構成の一実施例を示すブロック図である。
【図２】図１における報告作成部で作成される上位レイ
ヤへの報告のフォーマット例を示す説明図である。
ヤへの報告のフォーマット例を示す説明図である。
【図３】ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルにお
けるフォーマット例を示す説明図である。
けるフォーマット例を示す説明図である。
【図４】ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコルで受
信したパケットのチェーン状バッファへの格納状態を示
す説明図である。
信したパケットのチェーン状バッファへの格納状態を示
す説明図である。
【図５】受信パケットのトレイラのみが２番目のバッフ
ァに格納された状態を示す説明図である。
ァに格納された状態を示す説明図である。
１：バッファメモリ、２：トレイラ読み出し部、３：プ
ロトコル処理部、４：バッファ管理部、５：データ有無
判断部、６：報告作成部、７：上位インタフェース部、
８：受信パケット長カウンタ、９：回線。
ロトコル処理部、４：バッファ管理部、５：データ有無
判断部、６：報告作成部、７：上位インタフェース部、
８：受信パケット長カウンタ、９：回線。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 増田 孝文 東京都港区芝五丁目７番１号 日本電気 株式会社内 (56)参考文献 特開 昭60−91745（ＪＰ，Ａ) 特開 平７−135511（ＪＰ，Ａ) 特開 平７−336408（ＪＰ，Ａ) 1995年信学通信大会，Ｂ−521 情処研報，1995年７月13日，ＤＰＳ− 71−13 (58)調査した分野(Int.Cl.7，ＤＢ名) H04L 12/56 H04L 29/10
Claims (4)
- 【請求項１】 ＩＴＵ−Ｔ勧告Ｑ．２１１０のプロトコ
ルに基づき送られてきた受信パケットを、チェーン状の
バッファに格納するシステムであって、上記受信パケッ
トの長さをカウントする手段と、上記受信パケットのト
レイラの長さを読み出す手段と、上記カウントした受信
パケットの長さと、上記読み出したトレイラの長さおよ
び上記チェーン状のバッファの一つのバッファのサイズ
に基づき、上記チェーン状のバッファの最終バッファ
に、上記受信パケットの情報フィールドがあるか否かを
判断する手段と、該判断結果を付与して上位レイヤに対
する受信報告を作成する手段とを少なくとも有すること
を特徴とする受信パケット情報管理システム。 - 【請求項２】 請求項１に記載の受信パケット情報管理
システムにおいて、上記トレイラの長さを読み出す手段
は、上記受信パケットの種別を判別し、該種別に対応し
て予め決められたトレイラ長を探索して、上記トレイラ
の長さの読み出しを行なうことを特徴とする受信パケッ
ト情報管理システム。 - 【請求項３】 請求項１、もしくは、請求項２のいずれ
かに記載の受信パケット情報管理システムにおいて、上
記判断手段は、上記受信パケットの長さを上記一つのバ
ッファのサイズで割算し、該割算の余りが上記トレイラ
長と等しい場合、上記最終バッファに上記情報フィール
ドはないと判断することを特徴とする受信パケット情報
管理システム。 - 【請求項４】 請求項１から請求項３のいずれかに記載
の受信パケット情報管理システムにおいて、上記受信パ
ケットの長さをカウントする手段は、上記受信パケット
の長さをワード単位でカウントすることを特徴とする受
信パケット情報管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28961795A JP3275664B2 (ja) | 1995-11-08 | 1995-11-08 | 受信パケット情報管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28961795A JP3275664B2 (ja) | 1995-11-08 | 1995-11-08 | 受信パケット情報管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09135269A JPH09135269A (ja) | 1997-05-20 |
| JP3275664B2 true JP3275664B2 (ja) | 2002-04-15 |
Family
ID=17745563
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP28961795A Expired - Fee Related JP3275664B2 (ja) | 1995-11-08 | 1995-11-08 | 受信パケット情報管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3275664B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3324568B2 (ja) * | 1999-06-10 | 2002-09-17 | 日本電気株式会社 | 通信制御装置 |
| EP1091114B1 (en) | 1999-10-07 | 2005-05-25 | Siemens VDO Automotive Inc. | Intake manifold with purge valve mounted thereon |
-
1995
- 1995-11-08 JP JP28961795A patent/JP3275664B2/ja not_active Expired - Fee Related
Non-Patent Citations (2)
| Title |
|---|
| １９９５年信学通信大会，Ｂ−５２１ |
| 情処研報，１９９５年７月１３日，ＤＰＳ−７１−１３ |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09135269A (ja) | 1997-05-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| USRE39454E1 (en) | Transfer of messages in a multiplexed system | |
| RU2178623C2 (ru) | Способ указания размера мини-ячейки | |
| EP0914749B1 (en) | Method and apparatus for reassembly of data packets into messages in an asynchronous transfer mode communications system | |
| US5751951A (en) | Network interface | |
| JP3188732B2 (ja) | Ｉｅｅｅ８０２．３構内通信網を非同期時分割多重通信網に接続するためのブリッジ | |
| JP3819484B2 (ja) | Ｍｐｅｇパケットをパケット化およびセグメント化する装置および方法 | |
| US5828903A (en) | System for performing DMA transfer with a pipeline control switching such that the first storage area contains location of a buffer for subsequent transfer | |
| US5400326A (en) | Network bridge | |
| US5930265A (en) | Data processing method for efficiently transporting multimedia packets over a conventional digital packet switching network | |
| JPS63237637A (ja) | ローカルエリアネットワークとバックボーンネットワークを接続するネットワークインターフェイスモジュール及び接続方法 | |
| US5740373A (en) | Packet switching system having communication control unit for sending acknowledgment to the source upon receiving the receive response data associated with the last cell | |
| JPH07273799A (ja) | パケットスイッチングネットワークにおけるパケット処理のための装置および方法ならびにフレームリレーネットワークのためのフレーム処理システム | |
| JP2873044B2 (ja) | 非同期時分割通信網における信号メッセージの処理装置 | |
| JPH10224380A (ja) | アドレスを備えたヘッダと音声またはビデオなどのストリーミングデータを構成するペイロードとを有するセルを非同期転送モード（ａｔｍ）で転送するための電気通信システムおよび方法 | |
| US7054962B2 (en) | Embedded system having broadcast data storing controller | |
| JP3275664B2 (ja) | 受信パケット情報管理システム | |
| US7042881B1 (en) | Asynchronous transfer mode system and method to verify a connection | |
| US7009981B1 (en) | Asynchronous transfer mode system for, and method of, writing a cell payload between a control queue on one side of a system bus and a status queue on the other side of the system bus | |
| JP2002024145A (ja) | 電子メール通信端末装置 | |
| JP3221407B2 (ja) | Ａｔｍセル多重化方法及びその装置 | |
| US6301259B1 (en) | Switch and switching method | |
| US20030172176A1 (en) | Embedded system having multiple data receiving channels | |
| KR20040039433A (ko) | 설정된 연결을 통해 전송될 데이터 패킷을 버퍼에저장하기 위한 방법 및 장치 | |
| JP2803648B2 (ja) | Ａｔｍデータ伝送装置間における再送処理方式 | |
| JPH1093580A (ja) | データ処理装置の制御方法およびデータ処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090208 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090208 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100208 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110208 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110208 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120208 Year of fee payment: 10 |
|
| LAPS | Cancellation because of no payment of annual fees |