JP2002354066A - 通信プロトコル並列処理方式及び通信プロトコル並列処理装置 - Google Patents

Abstract

(57)【要約】 【課題】本発明は、オーバヘッドを極力削減し、実効的
な処理能力を向上させることができる通信プロトコル並
列処理装置を提供する。 【解決手段】本発明は、通信プロトコルを処理する通信
プロトコル並列処理装置１において、プログラマブルに
通信プロトコルを処理可能な同一のプロセッサ部２−２
−１、２−２−２を並列的に配置した通信プロトコル処
理部２と、前記プロセッサ部２−２−１、２−２−２間
に配置され、前段のプロセッサ部２−２−１から処理を
実行すべき処理の処理種別コード、優先順位を含む処理
情報を受け取り、優先順位に応じて次段のプロセッサ部
２−２−２に対して処理を実行させる順序並びに処理種
別コードを含む処理情報の通知を行う処理順序決定・伝
達部２−３とを有するものである。

Description

【発明の詳細な説明】

【発明の属する技術分野】本発明は、通信プロトコル並
列処理方式及び通信プロトコル並列処理装置に関し、通
信プロトコルを高速に処理する技術に関するものであ
り、詳しくは交換機多重化装置、ルータ等通信ネットワ
ークを構成する装置に適用でき、特に通信プロトコル処
理量が大きいパケット通信、ネットワーク通信に適用し
て好適な通信プロトコル並列処理方式及び通信プロトコ
ル並列処理装置に関する。

【従来の技術】通信ネットワークにおいては、通信プロ
トコルをベースに通信が行われている。この通信プロト
コルは、ネットワーク種別、インタフェースにより異な
っていて、特にＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃ
ｏｌ）を中心にしたパケット通信網では種々の通信プロ
トコルが使用されている。しかし、これらの通信プロト
コルは、その提供する通信サービスから処理が重いこと
がボトルネックとなり、伝送路（通信回線）の伝送速度
に比べてパケット処理速度が遅いため、通信サービスの
低下が問題になっている。従来の技術では、パケット処
理は多目的用途を狙った汎用プロセッサを用いて、プロ
トコル処理をソフトウェア（プログラム）で実行するこ
とが主流になっている。添付する図９は従来例の１つを
示すものであって、通信回線に接続された回線インタフ
ェース制御部２１と、この回線インタフェース制御部２
１に汎用バス３０を介して接続された他ブロックインタ
ーフェース制御部２２と、前記汎用バス３０に接続され
た多段構成のプロセッサ部（汎用プロセッサ）２３と、
各汎用プロセッサに対応するプログラムメモリ部（制御
プログラム及びＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅ
ｍ）を内蔵）２４と、前記汎用バス３０に接続されたデ
ータメモリ２５とを有している。この図９に示す従来の
方式では、通信プロトコルの改良、追加に対し柔軟に対
応できる反面、各汎用プロセッサの処理能力を十分発揮
できず、処理性能のボトルネックになっている。また、
汎用プロセッサを複数用いているが、並列処理並びに汎
用プロセッサのＯＳにおけるオーバヘッドが大きく、必
ずしも並列化による処理能力向上が十分図れないという
問題がある。また、部品点数増加に伴う価格上昇が生
じ、コストパーフォーマンスが良くないという問題も生
じている。更にまた、従来技術を用いた一部の通信プロ
トコル処理装置では、処理能力向上のため、専用のハー
ドウェア（例えば、専用ＬＳＩ）を開発し、それを用い
て高速化を実現している。しかし、この方式では、通信
プロトコルの変更、追加に追随し難く、変更、追加内容
によっては対応できなくなる場合が生じている。特に、
上述したＩＰ通信では、通信プロトコルの変更、追加が
頻繁であり、専用ハードウェアによる方式では、対応し
難くなっているのが実状である。

【発明が解決しようとする課題】上述した従来技術によ
る諸問題は、下記のような課題として要約できる。すな
わち、 （１）処理要素（プロセッサ）内のプログラム制御にお
けるＯＳのオーバヘッドを削減すること。 （２）並列処理における処理要素間の通信方法を簡略化
して、同様にＯＳのオーバーヘッドを削減すること。 （３）高速処理化を実現しつつ、通信プロトコルの変
更、追加を容易にすること。 本発明は、上述した従来の事情に鑑み開発されたもので
あり、パイプライン形の並列処理方式を採用し、オーバ
ヘッドを極力削減し、実効的な処理能力を向上させるこ
とができる通信プロトコル並列処理方式及び通信プロト
コル並列処理装置を提供することを目的とするものであ
る。

【課題を解決するための手段】請求項１記載の通信プロ
トコル並列処理方式は、通信プロトコルを処理する通信
プロトコル並列処理方式において、プログラマブルに処
理可能な同一処理要素を並列的に配置し、処理要素間に
配置した処理順序決定・伝達部によって前段の処理要素
の処理結果を基に後段の処理要素に対して処理を実行さ
せる順序並びに処理種別を決定することで、各処理要素
における通信プロトコルの並列処理を実行することを特
徴とするものである。請求項２記載の通信プロトコル並
列処理方式は、請求項１記載の通信プロトコル並列処理
方式において、前記処理順序決定・伝達部によって処理
順位、処理種別コードを決定された処理を処理要素が前
回の処理が終了した時点又は処理待ち時点で認識し、処
理要素が処理種別コードから所定の処理を認識してそれ
を実行し、処理の後に次に実行すべき処理種別コード並
びに処理優先順位を決定し、次段の処理順序決定・伝達
部に通知することを特徴とするものである。請求項３記
載の通信プロトコル並列処理方式は、請求項１又は２記
載の通信プロトコル並列処理方式において、前記処理順
序決定・伝達部において、処理要素から通知された処理
優先順位を有する処要要求を所定の処理優先毎のキュー
に登録し、次段の処理要素に対しては前回処理要求を通
知した直後から次に通知すべき処理要求を前記処理優先
キューから選択し、次段の処理要素に対し選択した処理
要求を通知することを特徴とするものである。請求項４
記載の通信プロトコル並列処理装置は、通信プロトコル
を処理する通信プロトコル並列処理装置において、プロ
グラマブルに通信プロトコルを処理可能な同一のプロセ
ッサ部を並列的に配置した通信プロトコル処理部と、前
記プロセッサ部間に配置され、前段のプロセッサ部から
処理を実行すべき処理の処理種別コード、優先順位を含
む処理情報を受け取り、優先順位に応じて次段のプロセ
ッサ部に対して処理を実行させる順序並びに処理種別コ
ードを含む処理情報の通知を行う処理順序決定・伝達部
とを有するものである。請求項１乃至４記載の各発明に
よれば、プロセッサ部はプロトコルに必要な処理のみに
専念でき、通常、汎用プロセッサで行われているような
割込み処理、処理のスケジューリングから解放されプロ
セッサ部の持つ汎用性の高い処理を、処理上のオーバヘ
ッドを伴うことなく、且つ、プロセッサ数分の処理能力
を十分に発揮させつつ実行することが可能な通信プロト
コル並列処理方式及び通信プロトコル並列処理装置を実
現でき、また、プロセッサ自体の制御は従来通りプログ
ラムで実行できるため、通信プロトコルの変更に際して
柔軟に対応できる。

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を説明する。図１は本発明の実施の形態の前提
を示す構成概念図であって、複数のプロセッサ１０を直
列形に接続した構成として並列処理を実行する（以下、
「パイプライン形」と称す）ものである。プロセッサ１
０を並列処理させる他の方式として、図２に示すように
プロセッサ１０を並列に結合させる方式（以下、「並行
処理形」と称す）がある。通信プロトコル処理では、以
下の理由から前記「パイプライン形」を採用するのが適
当である。通信プロトコル処理のうち、例えば通信回線
からのフレーム／パケットを入力した際の処理に着目す
ると、そのフレーム／パケットの種別に応じて多種類の
処理を実行する必要がある。これらの処理は、処理量
（処理時間）で見ると、当然それぞれ異なっていること
が一般的である。通信プロトコルを処理する条件とし
て、最初に入力されたフレーム／パケットの順序性を確
保しておくことが、特に会話音声、動画又はデータファ
イル等の多種類のメディア（実時間性の強弱を伴う）を
扱う通信において通信品質確保上必要になってくる。言
いかえれば、同じ通信回線から入力されたフレーム／パ
ケットを順序を入れ替えることなく出力していくことが
重要となる。前記「パイプライン形」では、処理の構成
から必然的にその条件を満足させることができる。一
方、前記「並行処理形」では、それを満足させるための
順序制御機構が必要となる。この順序制御機構による処
理への影響を考察すると、以下のようになる。今、入力
フレーム／パケットがランダムな到着、内部での処理時
間（サービス時間）が同じくランダムな条件で、両方式
をリリース使用率、平均内部処理時間について、シミュ
レーションによって比較すると、以下のような結果が得
られる。図３に示すように、並行処理のリリース（＝プ
ロセッサ）数を増やしていっても、順序性の確保による
出力持ち時間の影響で実効的な使用率はかなり悪くな
り、並列化したことによる処理能力の向上効果はあるが
必ずしも並列数に比較して効果が向上できないことを示
唆している。これに対し、「パイプライン形」は、ほぼ
実効的な使用率が段数に関係なく向上していく。また、
一層具体的な効果をみるため、内部の平均処理時間（平
均システム内時間）の観点から考察すると、図４に示す
ような結果が得られる。この結果から、並行処理方式で
はサービス時間を増加させると、急激にシステム内時間
が増加してしまい、例えば４プロセッサで構成したとし
ても、ほぼ１／２の能力しか発揮できないことになる。
これに対して、「パイプライン形」は、４プロセッサの
条件でも４プロセッサの能力を引き出し得る可能性を有
していることが解る。但し、「パイプライン形」では、
通常のプロセッサ内部で行なわれているように固定され
た時間（タイムスロット）内に処理が終了することが保
証されないため、プロセッサ間でのその時間差を吸収す
る機構（待ち行列）が必要になる。当該機構については
後述する。図５は本実施の形態に係る「パイプライン
形」のプロセッサ群による通信プロトコル処理装置を示
すブロック図である。図５において、符号１は通信プロ
トコル処理装置であり、交換機、多重化装置、ルータ等
が代表例である。通信プロトコル処理装置１は、通信プ
ロトコル上の規約にしたがいながら相手通信プロトコル
処理装置との間でのデータの送受信フレーム又はパケッ
ト等の分解／組み立て等を行う２つの通信プロトコル処
理部２と、各通信プロトコル処理装置１に接続され、例
えば、フレーム又はパケットを単位として通信データが
伝送される通信回線３と、２つの通信プロトコル処理部
２間に配置され、通信回線３から受信したフレーム又は
パケットが通信プロトコル処理部２で処理された後、そ
の通信データを所定の宛て先に転送するスイッチング部
４と、通信プロトコル処理部２とスイッチング部４を接
続する通信線５とを有している。前記通信線５は、通
常、前記通信プロトコル処理部２で収容される回線数分
の通信トラヒックを伝送するため、前記通信回線３より
も高速な伝送速度を有する。このような通信プロトコル
処理装置１の構成において、前記通信プロトコル処理部
２は複雑、且つ、処理量の多い通信プロトコルを処理す
るため、スイッチング部４に比べて処理能力上のボトル
ネックになっていて、通信プロトコル処理装置１の性能
を決定する要因になることが多い。図６は前記通信プロ
トコル処理部２の具体的構成を示すものであり、以下に
その構成を詳細に説明する。この通信プロトコル処理部
２は、回線対応部２−１と、プログラム制御のプロセッ
サ部２−２と、処理順序決定・伝達部２−３と、スイッ
チインタフェース制御部２−４と、データバッファメモ
リ２−５とを有している。回線対応部２−１は、通信回
線を収容するとともに、伝送網の終端とともにフレーム
又はパケットの組み立て／分解、正常性検査／検査用符
号の付加等を行うようになっている。プロセッサ部２−
２は、フレーム又はパケットの通信プロトコルの手順処
理のために制御符号（ヘッダ情報）を見て、所定の通信
プロトコル処理を行うようになっている。プロセッサ部
２−２は、図６からも明らかなように、多段の接続形態
（「パイプライン形」）をとり、全体で通信プロトコル
処理の負荷分散をさせて処理能力を向上させる役割を果
たしている。処理順序決定・伝達部２−３は、プロセッ
サ部２−２間を接続し、プロセッサ部２−２が通信すべ
き他のプロセッサ部２−２に対して通信のためのオーバ
ヘッドを殆ど無くすため、各プロセッサ部２−２間のメ
ッセージの蓄積並びに渡すべきメッセージの順序を制御
する。すなわち、ある一つのプロセッサ部２−２から見
れば、あたかも「郵便箱」のようなものに相当し、ある
プロセッサ部２−２で処理が終了すれば、次のプロセッ
サ部２−２での処理順序（スケジューリング）を意識す
ることなく、その処理を渡せば良いことになる。スイッ
チインタフェース制御部２−４は、前記スイッチング部
４と、インタフェースを有し、前記回線対応部２−１と
同レベルの位置付けである。但し、前記スイッチング部
４とのインタフェースでは回線対応部２−１に比べて伝
送距離が極端に短く、高速伝送を行ってもほとんど伝送
誤りなく伝送できるため、その処理は回線対応部２−１
に比べて極端に簡易化されるのが一般的である。データ
バッファメモリ２−５は、各プロセッサ部２−２に接続
され、回線対応部２−１並びにスイッチインタフェース
制御部２−４から入力されるフレーム又はパケットのヘ
ッダ情報、データバッファの制御情報が格納される。こ
れらのフレーム又はパケットは、複数のプロセッサ部２
−２によって所定の通信プロトコル上の処理が終了する
と、回線対応部２−１又はスイッチインタフェース制御
部２−４から出力される。図７は本実施の形態の主要な
部分を示すものであり、図６で説明したプロセッサ部２
−２と処理順序決定・伝達部２−３間の通信方法の具体
例を示すものである。また、図８はプロセッサ部２−２
間の通信において伝達される処理情報２−３−１の構成
例を示すものである。処理情報２−３−１は、次段のプ
ロセッサ部２−２−２での処理において処理事項を判断
することなく実行できるように、「処理種別コード」、
「処理の優先順位」、処理すべきフレーム又はパケット
データが格納されている「対応データバッファ先頭アド
レス」、その他の制御事項等が付与されていて、プロセ
ッサ部２−２が処理情報を受信するとすぐに必要な処理
を実行できるような内容から構成されている。次に、本
実施の形態の処理の流れについて説明する。まず、図７
に示すように、前段のプロセッサ部２−２−１から処理
順序決定・伝達部２−３へのメッセージ通知方法を説明
する。前段のプロセッサ部２−２−１が担当する通信プ
ロトコル処理が一連の処理を終了すると、次段のプロセ
ッサ部２−２−２に次の処理を行わせるため、処理情報
に書き込むべき内容、すなわち、処理種別コード、優先
順位、その他の制御情報等を用意しておく。この後、前
段のプロセッサ部２−２−１は、処理順序決定・伝達部
２−３からの信号線２−３−３のデータを読み出す
（１）。上記信号線２−３−３のデータは、書き込むメ
モリエリアがビジー（Ｂｕｓｙ）状態／レディ（Ｒｅａ
ｄｙ）状態かを表示するのものであり、書き込むメモリ
エリアが、もし、レディ状態（処理順序決定・伝達部２
−３内のバッファエリアが空いている状態）であれば、
前段のプロセッサ部２−２−１は、書き込みアドレス
（ＡＤｘ）を処理順序決定・伝達部２−３に信号線２−
３−４を介して通知し（２）、予め用意した処理情報の
内容を前記処理情報２−３−１として処理順序決定・伝
達部２−３の該当エリア（先頭アドレスＡＤｘ）に書き
込む（３）。書き込みアドレス（ＷＰ：ライトポイン
タ）は前段のプロセッサ部２−２−１が管理し、処理順
序決定・伝達部２−３が読み込みアドレス（ＲＰ：リー
ドポインタ）とエリア内に接続された処理情報２−３−
１の情報を管理するリングバッファキューによって実現
できる。なお、上述したレディ状態／ビジー状態の表示
は、リングバッファキューの空・塞状態を判断した結果
になる。次に、処理順序決定・伝達部２−３における動
作を説明する。処理順序決定・伝達部２−３では、処理
情報２−３−１の先頭アドレスＡＤｘを受信すると、該
当する処理情報２−３−１が次段のプロセッサ部２−２
−２で優先的に処理すべきかを判断するため、受信した
処理情報２−３−１から「優先順位」情報を読み出し、
その優先情報に基づいて処理順序決定・伝達部２−３の
内部にある該当優先順位キュー２−３−２の最後尾にそ
の処理情報２−３−１を登録する（４）。図７に示す例
では、処理情報２−３−１の「優先順位」が最高位に位
置していることを認識し、優先順位キュー２−３−２の
最高位であるクラスＡのキューに登録することを示して
いる。処理順序決定・伝達部２−３は、並行して次段の
プロセッサ部２−２−２の処理が終了した際に優先順位
に応じて処理情報２−３−１を引き渡すため、優先順位
キュー２−３−２に登録されている処理情報２−３−１
から最も優先順位の高い処理情報を選択する（５）。こ
の場合の選択アルゴリズムは、通常のＯＳ等で行われて
いるように，例えば、「固定優先」で十分である。この
ような動作により、次段のプロセッサ部２−２−２は現
在行われている処理が終了した後、すぐに次の通信プロ
トコル処理に移行できる。すなわち、オーバヘッドのな
い動作が実現できることを意味している。次に、処理順
序決定・伝達部２−３から上述した動作によって選択さ
れた処理情報２−３−１を、次段のプロセッサ部２−２
−２へ渡す処理について説明する。次段のプロセッサ部
２−２−２では、処理情報２−３−１の受信が終了する
と、処理順序決定・伝達部２−３に対して次の処理情報
２−３−１を受信する準備を促すために、信号線２−３
−５を通じて「レディ（Ｒｅａｄｙ）」を表示する
（６）。この状態において処理順序決定・伝達部２−３
では、このレディ表示を確認し、別の信号線から先に決
定した処理情報２−３−１の処理情報先頭アドレス（Ａ
Ｄｙ）を次段のプロセッサ部２−２−２に信号線２−３
−６を介して通知しておく（専用レジスタに書き込む）
（７）。この通知を受けとると、次段のプロセッサ部２
−２−２では信号線２−３−５のデータを「レディ」か
ら「ビジー（Ｂｕｓｙ）」に変更し、処理順序決定・伝
達部２−３が次段のプロセッサ部２−２−２に対してそ
れ以降の動作を動作を禁止させるようにする（専用レジ
スタヘの処理情報先頭アドレスの上書きを禁止する）。
次段のプロセッサ部２−２−２では、現在行っている処
理が終了すると、すぐにこの通知がされたアドレス（Ａ
Ｄｙ）を読み出し、それに該当する処理情報２−３−１
内の「処理情報コ−ド」並びに「データバッフア先頭ア
ドレス」を読み込む（８）。この読み込みを完了する
と、次段のプロセッサ部２−２−２は、すぐに信号線２
−３−５を介して処理順序決定・伝達部２−３に対して
「ヒジー」から「レディ」に変更する通知をしておくと
ともに、次の処理情報先頭アドレスを読み込めるように
し、更に、処理情報２−３−１内の「処理種別コード」
並びに「データバッファ先頭アドレス」を参照してフレ
ーム又はパケットの必要情報を読み出し、該当するプロ
トコル処理を実行する。本実施の形態では、上述したよ
うに、「パイプライン形」の並列処理方式を採用し、前
述した従来例のようなオーバヘッドを極力削減し、実効
的な処理能力を向上させるため、従来のＯＳ等が処理し
ている処理のスケジユーリングを別機能で実現でき、プ
ロセッサ部は単に必要な処理に専念できるように改善し
たものである。また、プロセッサ部自体の制御は従来通
りプログラムで実現しているため、通信プロトコルの変
更に際して柔軟に対応できる。

【発明の効果】本発明によれば、プロセッサ部はプロト
コルに必要な処理のみに専念でき、通常、汎用プロセッ
サで行われているような割込み処理、処理のスケジュー
リングから解放されプロセッサ部の持つ汎用性の高い処
理を、処理上のオーバヘッドを伴うことなく、且つ、プ
ロセッサ数分の処理能力を十分に発揮させつつ実行する
ことが可能な通信プロトコル並列処理方式及び通信プロ
トコル並列処理装置を提供することができる。また、プ
ロセッサ自体の制御は従来通りプログラムで実行できる
ため、通信プロトコルの変更に際して柔軟に対応できる
効果も奏する。

【図面の簡単な説明】

【図１】本発明の実施の形態に係る通信プロトコル並列
処理方式の概念の基本構成を示す説明図である。

【図２】本発明の実施の形態と対比するプロセッサを並
列結合した構成の概念説明図である。

【図３】リリース使用率と実効リリース使用率の関係を
示すシミュレーション結果例を示すグラフである。

【図４】リリース使用率に対する平均システム内時間を
示すシミュレーション結果例を示すグラフである。

【図５】本発明の実施の形態の通信プロトコル処理装置
のブロック図である。

【図６】本発明の実施の形態の通信プロトコル処理部の
ブロック図である。

【図７】本発明の実施の形態のプロッセッサ部、処理順
序決定・伝達部の動作例を示す説明図である。

【図８】本発明の実施の形態のプロセッサ部並びに処理
順序決定・伝達部において伝送される処理情報の構成例
を示す説明図である。

【図９】従来のプロトコル処理装置を示すブロック図で
ある。

【符号の説明】

１ 通信プロトコル処理装置 ２ 通信プロトコル処理部 ２−１ 回線対応部 ２−２ プロセッサ部 ２−２−１ プロセッサ部 ２−２−２ プロセッサ部 ２−３ 処理順序決定・伝達部 ２−３−１ 処理情報 ２−３−２ 優先順位キュー ２−３−３ 信号線 ２−３−４ 信号線 ２−３−５ 信号線 ２−３−６ 信号線 ２−４ スイッチインタフェース制御部 ２−５ データバッファメモリ ３ 通信回線 ４ スイッチング部 １０ プロセッサ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 坂間 元 東京都港区三田３丁目14番10号 ロジック 株式会社内 (72)発明者 青木 誠 東京都港区三田３丁目14番10号 ロジック 株式会社内 Ｆターム(参考） 5B045 BB42 EE03 GG17 5K034 AA02 FF01 FF02 GG02 HH54 MM22 MM37

Claims (4)

【特許請求の範囲】
1. 【請求項１】通信プロトコルを処理する通信プロトコル
   並列処理方式において、 プログラマブルに処理可能な同一処理要素を並列的に配
   置し、処理要素間に配置した処理順序決定・伝達部によ
   って前段の処理要素の処理結果を基に後段の処理要素に
   対して処理を実行させる順序並びに処理種別を決定する
   ことで、各処理要素における通信プロトコルの並列処理
   を実行することを特徴とする通信プロトコル並列処理方
   式。
2. 【請求項２】前記処理順序決定・伝達部によって処理順
   位、処理種別コードを決定された処理を処理要素が前回
   の処理が終了した時点又は処理待ち時点で認識し、 処理要素が処理種別コードから所定の処理を認識してそ
   れを実行し、処理の後に次に実行すべき処理種別コード
   並びに処理優先順位を決定し、次段の処理順序決定・伝
   達部に通知することを特徴とする請求項１記載の通信プ
   ロトコル並列処理方式。
3. 【請求項３】前記処理順序決定・伝達部において、処理
   要素から通知された処理優先順位を有する処理要求を所
   定の処理優先毎のキューに登録し、次段の処理要素に対
   しては前回処理要求を通知した直後から次に通知すべき
   処理要求を前記処理優先キューから選択し、次段の処理
   要素に対し選択した処理要求を通知することを特徴とす
   る請求項１又は２記載の通信プロトコル並列処理方式。
4. 【請求項４】通信プロトコルを処理する通信プロトコル
   並列処理装置において、 プログラマブルに通信プロトコルを処理可能な同一のプ
   ロセッサ部を並列的に配置した通信プロトコル処理部
   と、 前記プロセッサ部間に配置され、前段のプロセッサ部か
   ら処理を実行すべき処理の処理種別コード、優先順位を
   含む処理情報を受け取り、優先順位に応じて次段のプロ
   セッサ部に対して処理を実行させる順序並びに処理種別
   コードを含む処理情報の通知を行う処理順序決定・伝達
   部と、 を有することを特徴とする通信プロトコル並列処理装
   置。