JPH08503349A

JPH08503349A - Method and apparatus for extracting connection information from protocol header

Info

Publication number: JPH08503349A
Application number: JP6520550A
Authority: JP
Inventors: カイザースヴェルス、マティアス; リュッツエ、エーリヒ
Original assignee: インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン
Priority date: 1993-03-20
Filing date: 1993-03-20
Publication date: 1996-04-09
Anticipated expiration: 2013-03-30
Also published as: JP2732549B2

Abstract

(57)【要約】本明細書は、たとえば通信ネットワークのトークンリング・アダプタ内で、データ・ストリームを処理するための独自の接続識別子を提供するために前記データ・ストリームの前にあるプロトコル・ヘッダのさまざまなフィールドを処理するための方法および装置に関する。関連プロトコル情報のすべてが、連想記憶（８０）での表引きのために前記プロトコル・ヘッダから抽出される。前記ＣＡＭ（８０）内の項目が、ＣＡＭの入力（８４）に印加されたプロトコル情報と一致するたびに、この記憶部分のＣＡＭアドレスすなわち、前記ＣＡＭ（８０）の行のアドレスが、その出力（８２）に供給される。前記プロトコル・ヘッダから得られたＣＡＭアドレスを、接続番号構築機構（ＣＮＢ９５）によって連結して、前記データ・ストリームの処理のために使用される、プロトコル・フィルタの出力（９６）に供給される独自の接続識別子をもたらす。 (57) Summary This specification describes a protocol header that precedes a data stream to provide a unique connection identifier for processing the data stream, for example, in a token ring adapter of a communication network. Method and apparatus for processing various fields of a. All relevant protocol information is extracted from the protocol header for lookup in associative memory (80). Each time an item in the CAM (80) matches the protocol information applied to the input (84) of the CAM, the CAM address of this stored portion, i.e. the address of the row of the CAM (80), is returned in its output ( 82). A unique CAM address obtained from the protocol header, concatenated by the connection number builder (CNB95), and supplied to the output (96) of the protocol filter used for processing the data stream. Yields the connection identifier of.

Description

【発明の詳細な説明】プロトコル・ヘッダから接続情報を抽出するための方法および装置［技術分野］本発明は、通信ネットワーク内のデータ・ストリームを走査し、独自のプロトコル接続識別子を提供するために接続情報を抽出する方法および装置に関する。［背景技術］コンピュータと通信ネットワークの技術的融合ならびにこれら２つの領域での迅速な発展のため、情報処理と通信の緊密な混合が生じ、データ、音声、画像などの伝送と交換がますます複雑になってきている。情報（さまざまな種類のデータ、サービスおよび通信の同義語として使用する）のそれぞれの伝送または交換は、必然的に手順規則によって管理しなければならない。異なる装置たとえば２台の遠隔コンピュータ端末、または２つの手順が、インターフェース（ハードウェア・インターフェースである必要はない）を介して対話している時には、それぞれのプロトコルが使用される。ネットワークに応じて、さまざまなプロトコルが階層的に並べられ、各プロトコルがそれぞれ隣接するプロトコルと対話するプロトコルの垂直スタックがもたらされる。ホスト・コンピュータなどの遠隔システム間の情報交換と伝送を編成するための基本トランスポート・プロトコルが知られている。典型的な例が、ＡＲＰＡ(Advanced Research Projects Agency）ホスト間プロトコルである。このような基本プロトコルを用いると、垂直プロトコル・スタックの上位プロトコルが、その動作のすべてを基本プロトコル機構に基づくものとすることが可能になる。ネットワーク環境に応じて、複数の上位プロトコルが基本プロトコル上にセットアップされる。ＣＣＩＴＴ（国際電信電話諮問委員会）アプリケーション用のＯＳＩ（オープン・システム相互接続）参照モデルと称する典型的な垂直プロトコル・スタックの概略表現が、ＣＣＩＴＴ勧告Ｘ．２００、”Reference Model of Open Systems Interconnection for CCITT Applications”，Blue Book，Fas cicle VIII．４、ジュネーブ、１９８９年で定義されている。前記ＯＳＩ参照モデルでは、レイヤと称する７つのレベルを使用する。各レイヤは、それ自体の固有機能を有し、下のレイヤによって提供されるサービスを使用して上のレイヤに定義済みサービスを提供する。たとえば、第１のシステムで走行するアプリケーシヨン・プログラムが第２の遠隔システムに保持されているデータの使用を要求する場合、情報の交換が行われる。前記第２のシステムが特定のデータ・パケットの送信を求める要求を受け取る時に、このデータ・パケットは、物理リンクを介して送信される前に、アプリケーション・レイヤなどの最上位プロトコル・レベルから、すべての下位プロトコル・レベルを介して下に伝送されなければならない。これらのプロトコル・レイヤのそれぞれが、上位レイヤから受け取ったデータ・パケットに、そのレイヤに固有の接続情報を追加する。したがって、２つのシステムの間の通信接続は、垂直プロトコル・スタックの接続情報を担持するフィールドの集合によって、パケット・ヘッダ（以下、プロトコル・ヘッダと呼称する）内で定義される。レシーバ・サイトでデータ・パケットからなるデータ・ストリームを受信する時には、経路指定、多重化または圧縮の前に、前記プロトコル・ヘッダを走査して、次の処理のために接続情報を含むそれぞれのワードを抽出しなければならない。今日まで、プロトコル接続の大半は、ソフトウェアでプロトコル・ヘッダを逐次処理することによって識別されている。この動作は、たとえばサーバ内などの多数の接続を処理する時やマルチメディア・データ・ストリームを処理する時には特に、プロトコル処理のかなりの時間を消費する。プロトコル・ヘッダのプロトコル・タイプを認識し、プロトコル固有データ・フィールドを抽出するのに使用されるマイクロプログラム式コントローラが、H. W.チン（Chin）他著、”Implementing PE-1000 Based Internetworking Nodes” ,Part ３ of ３，Transfer，Vol．５，No．３，１９９２年５〜６月、５〜８ページに記載されている。パケット識別子を適切な物理出力リンクへ変換するための経路指定テーブルのハードウェア実施態様が、T.B.ペイ (Pei)およびC.ツコウスキ(Zukowski)著，” Putting RoutingTables in Silicon”，IEEE Network Magazine，１９９２年１月、４２〜５０ページに記載されている。この手法は、主に、連想記憶（ＣＡＭ）を使用して、単一プコトコルのヘッダ内の接続情報を突き合わせることを特徴とする。さらに、経路指定情報の記憶に使用される、ＣＡＭ対通常のランダム・アクセス・メモリ（ＲＡＭ）の長所と短所が、ペイとツコウスキによって評価された。上記の２つのシステムは、どちらもが副次的な問題の解決に関連するが、このどちらも、また他の既知のソフトウェア手法のいずれもが、インターネット・プロトコル（ＩＰ、”Internet Protocol； DARPA Internet Program Protocol Sp ecification”，RFC 791，DARPA（米国国防高等研究計画庁）、１９８１年９月）上で構築されるＴＣＰ（送信制御プロトコル、"Transmission Control Protoc ol； DARPA Internet Program Protocol Specification”，RFC 793，DARPA) １９８１年９月）およびＸＴＰ (Express Transport Protocol、”XTPProtocol D efinition”，Protocol Engines Incorporated，Revisjon 3.6.，edited by Pro tocol Engines，Mountain View，米国カリフォルニア州、１９９２年１月１１日）または、ＣＬＮＰ（Connectionless Network Protocol、”Protocol f or Providing the Connectionless-Mode Network Service”,ISO ISO/IEC 8473 ）上で構築されるＴＰ４（トランスポート．プロトコル、タイプ４、”Connecti on Oriented TransportProtocol Specification”，ISO/IEC JTCI Draft Intern ational Standard ISO/IEC DIS 8073)などの複数のトランスポート・プロトコルの高速処理を可能にするものではない。本明細書で使用する略語ＲＦＣは、用語 Request for Comments（コメント要求）の頭字語である。さらに、本発明は、たとえばＳＴ−ＩＩ（ストリーム・プロトコル、バージョン２、C．トボルチツク(Topolcic)編、”Experimental Internet Stream Protocol； Version ２ (ST -II)”，RFC119O、１９９０年１０月）などのマルチメディア・トラフィックの処理に十分に適している。リアルタイムでのプロトコル・ヘッダの処理および異なるプロトコル・タイプの認識は、非常に複雑で困難な作業である。ほとんどすべてのネットワーク・システムで、ヘッダ処理は、いまだに主要なＣＰＵ（中央処理装置）サイクル消費活動である。本発明は、プロトコル・データ・フィールドを抽出する（チン他参照）だけではなく、これらのフィールドを使用して、独自の接続識別子を抽出する。この動作は、リアルタイムで実行される。さらに、本発明の方法および装置は、プロトコル・スタックを処理するように設計されている。本発明の目的は、さまざまなプロトコルのトラフィックを担持するネットワーク内での改良されたヘッダ処理のための方法を提供することである。本発明のもう１つの目的は、マルチ・プロトコル・データ・ストリームの情報の、高速で信頼性のあるアドレッシングの処理すなわち接続のための方法を提供することである。本発明のもう１つの目的は、マルチメディア・データを含むマルチ・プロトコル・データ・ストリームの高速で信頼性のある処理の方法を提供することである。本発明のもう１つの目的は、複合プロトコル・ヘッダの情報のリアルタイムのアドレッシングの処理すなわち接続を可能にする方法を提供することである。本発明のもう１つの目的は、前記方法のハードウェア実施態様を提供することである。［発明の摘要］上記の目的は、請求項９に従う方法と、請求項１に従う前記方法の、プロトコル・フィルタと称するハードウェア実施態様とを提供することによって達成された。この方法および装置は、第１のプロトコルのプロトコル・タイプ情報が抽出され、前記第１プロトコル上で構築されたプコトコルのプロトコル情報が逐次読み取られることを特徴とする。プロトコル・タイプ情報と前記プロトコル情報を、ＣＡＭの入力に印加して、この入力に印加される情報が前記ＣＡＭに記憶された情報と一致するたびにＣＡＭの出力にアドレスを供給する。この出力に供給されたアドレスを連結して、独自の接続識別子にする。［図面の説明］第１図は、本発明の第１の実施例によるプロトコル・フィルタの概略ブムック図である。第２図は、２つの異なるプロトコルのヘッダ・フィールドを含むプロトコル・ヘッダが先頭にあるデータ・ストリームを示す図である。第３図は、ＬＬＣ（論理リンク制御）フレームを示す図である。第４図は、ＩＰ（インターネット・プロトコル）上で構築されるＴＣＰ（送信制御プロトコル）と、ＩＰ上で構築されるＳＴ−ＩＩプロトコルの階層構造を示す図である。第５図は、ＣＬＮＰ (Connection Less Network Protocol)上で構築されるＴＰ４（トランスポート・プロトコル、タイプ４）の階層構造を示す図である。第６Ａ図は、ＩＰヘッダ上で構築されるＴＣＰヘッダの諸フィールドを示す図である。第６Ｂ図は、ＳＴ−ＩＩヘッダの諸フィールドを示す図である。第７図は、ＣＬＮＰヘッダ上で構築されるＴＰ４ヘッダの諸フィールドを示す図である。第８図は、第１実施例のプロトコル・フィルタで使用される連想記憶（ＣＡＭ）を示す図である。第９図は、本発明の第１実施例によるプロトコル・フィルタのブロック図である。第１０Ａ図は、本発明のプロトコル・フイルタによって区別される接続識別子を示す図である。第１０Ｂ図は、本発明のプロトコル・フイルタによって区別される接続識別子を示す図である。第１１図は、本発明のプロトコル・フィルタによって区別される接続指標を示す図である。第１２図は、本発明の第２実施例による、マルチプロトコル・フィルタの一部としてのプロトコル・フィルタのブロック図である。第１３図は、マルチメディア・ワークステーションの一部としてのプロトコル・フィルタの概略ブロック図である。第１４図は、サーバの一部としてのプコトコル・フィルタの概略ブロック図である。［全般的説明］データ・パケットやマルチメディア・データ・ストリームなどの情報をネットワーク内またはネットワークに沿って交換または送信する時には、その交換または送信は、複数のプロトコル・タイプの上で構築される。異なるプロトコル・タイプのプロトコル情報は、送信されるデータ・パケットまたはデータ・ストリームのプロトコル・ヘッダに挿入される。このプロトコル・ヘッダの受信と処理は、交換機またはネットワークを介する添付データ・ストリームの経路指定の前、着信トラフィックの圧縮の前、またはその多重化の前に、行わなければならない。ヘッダの処理、具体的には、ヘッダ内のプロトコル関連ワードの処理は、想像できる環境のいくつかを挙げると、通常はネットワーク・ノード、アダプタ、ブリッジ、マルチプレクサ、コンプレッサ、プロトコル・アナライザおよび交換機で行われるが、サーバでも行われる。第１の環境に関連して、本発明の基本概念を説明する。本発明のプロトコル・フィルタ（以下、ＰＦと呼称する）１０を、第１図に示す。ＰＦＩ０によって、プロトコルの処理がはるかに単純になる。というのは、レイヤ化されたプロトコル・ヘッダの接続識別子（本発明の方法による）が、ハードウェアで実施される時に、はるかに高速になるからである。ＰＦＩ０の機能は、受信したデータ・ストリームまたはパケットのプロトコル・ヘッダから関連情報を抽出し、この情報を記憶された接続情報と比較し、２つのデータが等しい場合に関連する接続識別子を提供することである。この実施例では、ＰＦＩ０を、トークン・リング・ネットフーク・アダプタ１４内で使用して、第２図に概略的に示されるように、バス１１を介して受信するデータ・ストリーム２１に先行するプロトコル・ヘッダ２０のフィールド２２ないし２７から関連ワードのすべてを抽出する。出力ポート１２に、接続識別子が供給され、これを別の処理に使用することができる。この別の処理は、ＰＦ１０を使用する環境に依存する。第２図に概略的に示されるように、データ・ストリーム２１の前に、前記プロトコル・ヘッダ２０がある。この簡略化された図では、プロトコル・ヘッダ２０に、第１プロトコルに属するフィールド２２、２３および２４と、前記第１プロトコル上で構築される第２プロトコルに属するフィールド２５ないし２７が含まれる。この図では、それぞれのデータ・ストリーム２１の処理に関連するプロトコル情報を含むフィールドに、斜線が書き込まれている。第１実施例の、前記トークン・リング・ネットワーク・アダプタ１４の一部としてのＰＦ１０は、ＴＣＰ／ＩＰ、ＳＴ−ＩＩおよびＩＳＯＣＬＮＰ／ＴＰ４トラフィックを担持するトークン・リング・ネットワーク内で使用される。前記ネットワークの詳細は、”IBM Token-Ring Network：Architec ture Reference ”，SC30-3374-02，third edition) 1989年９月に記載されている。トークン・リング・ネットワーク・アダプタ１４は、その有限状態機械で媒体アクセス制御（ＭＡＣ）を処理する。トークン・リング・ネットワーク・アダプタ１４が受信し、ＰＦ１０によって処理される、ＬＰＤＵ（リンク・プロトコル・データ・ユニット）フォーマットのＬＬＣ（論理リンク制御）フレームを、第３図に示す。ＤＳＡＰ（宛先サービス・アクセス・ポイント）フイールド３０は、前記ＬＰＤＵが意図されたアクセス・ポイントを識別する。ＤＳＡＰフィールド３０の典型的な値は、上述の”IBM Token-Ring Network： Architecture Reference"， SC3 0-3 374-02に記載されている。ＤＳＡＰ値すなわち、プロトコル・タイプ情報は、異なるプロトコル・アドレスの中での探索の際にＰＦ１０によって開始点として使用される。これらのプロトコル・アドレスは、本発明によって、ツリーに配置される。第１実施例では、ＴＣＰ／ＩＰおよびＳＴ−ＩＩアドレスが、第４図に示されれる第１ツリーの一部であり、ＣＬＮＰ／ＴＰ４プロトコルに対応するアドレスが、第５図に示される第２ツリーに配置される。インターネット・プロトコル（ＩＰ）のさまざまなレイヤで使用されるアドレスおよびプロトコル固有情報が、第４図に示されるツリーを形成する。インターネット・プロトコル上で構築される第１プロトコルすなわちＴＣＰ／ＩＰは、第４図の左側に配置され、ツリーの４レベルからなる。ＴＣＰ／ＩＰ接続は、ＴＣＰが構築されるプロトコル・タイプ（＝インターネット）の特徴を表すツリーの根４０から始まる前記ツリーを介する経路（短破線）によって定義される。第１レベルは、プロトコル・バージョン（Ｖｅｒ．Ｐｒｏｔ．）４１を定義し、第２レベルはソース・アドレス（Ｓ．Ａｄｄｒ．）４３、第３レベルはデスティネーション・アドレス（Ｄ．Λｄｄｒ．）４４、第４レベルはソース／デスティネーション・ポート（Ｓ．Ｄ．Ｐ．）４５を定義する。このＴＣＰ／ＩＰ接続を定義する第１経路は、後で説明するようにＰＦ１０の連想記憶に記憶される。第２経路（破線）は、ＳＴ−ＩＩ接続を定義する。この第２経路は、同じツリーの根４０から始まり、第１レベルの符号４２で終わる。この第２接続は、この例ではプロトコル・タイプ（＝インターネット）とプロトコル・バージョン（＝＃００５２ＨＩＤ）だけによって定義される。この第２経路も、ＰＦ１０に記憶される。本明細書では、記号＃を使用して、１６進数表記を表す。第６Ａ図は、ＴＣＰ／ＩＰヘッダを示す図である。第６Ａ図の上側に、インターネット・プロトコル・ヘッダを示す。ＩＰヘッダ・フィールドに使用される略語の意味を、下の表１にリストする。ＰＦ１０での処理を必要とする、すなわち、プロトコル情報からなるワードを担持するＩＰヘッダ・フィールド６０ないし６５の略語は、末尾に記号＊を付す。プロトコル・ヘッダのＴＣＰ部分も、第６Ａ図に示す。このＴＣＰヘッダのフィールドに使用される略語を、表２にリストする。ＴＣＰヘッダの関連フィールド６６、６７の略字の末尾に、記号＊を付す。ＩＰヘッダのヘッダ・フィールドの内容は、C．トポルチック(Topolcic)編、 ”Experimental Internet Strealn Protocol； Version ２ (ST-II）”，RFC 11 90、１９９０年１０月に定義されタイル（具体的には、その第７５ページ）。ＩＰバージョン番号の値（Ｖｅｒ；６０）は、＃４であり、インターネット・ヘッダの正常なヘッダ長（ＩＨＬ６１）は、＃５であり、サービス・タイプ・フィールド（ＴＯＳ６２）は、＃００であり、これらの値は、すべて１６進数表記である。ＩＰのプロトコル・フィールド（ＰＲＯＴＯ６３）は、Ｊ．パステル(Postel)著、”Ass igned Numbers”，RFC 790) １９８１年９月で定義された８ビット数を保持する。このプロトコル・フィールド（ＰＲＯＴＯ６３）の８ビット数は、＃０６である。本発明によって、これら４つのＩＰヘッダ・フィールド６０ないし６３を連結し、パディングして、ＰＦ１０に記憶される３２ビット・ワードを得る。これは、現在の例では、Ｖｅｒ．Ｐｒｏｔ．フィールド４１（第４図のツリーの第１レベル）と称するプロトコル・バージョンを定義する３２ビット・ワード、＃００４５０００６をもたらす。前記ＩＰヘッダのソース・アドレス（ＳＡ６４）とデスティネーション・アドレス（ＤＡ６５）は、このツリーの符号４３（Ｓ．Ａｄｄｒ．）と４４（Ｄ．Ａｄｄｒ．）にあるアドレスと等しい。これら２つのフィールドに保持されるアドレスのフォーマットも、Ｊ．パステル（Postel）著、”Assigned Numbers”，RFC 790、１９８１年９月に定義されている。ツリーのソース／デスティネーション・ポート（Ｓ．Ｄ．Ｐ．）アドレス４５は、第６Ａ図のＴＣＰヘッダのソース・ポート（ＳＰ６６）フィールドとデスティネーション・フィールド（ＤＰ６７）から導出される。ＴＣＰの詳細は、前述のプロトコル仕様書、"Transmission Control Prot ocol； DARPA Internet Program Protocol Specification”，RFC 793，DARPA、１９８１年９月に記載されている。第４図に示されたッリーのＴＣＰ／ＩＰ部分の４つのレベルがプロトコル・フィルタにどのように記憶されるかを、第８図に示す。インターネット・プロトコルから導出された、第２のプロトコルであるＳＴ− ＩＩプロトコルのへッダを第６Ｂ図に示す。略語を、表３で解説する。フィールド６８ないし７０は、関連するプロトコル情報を担持する。ＳＴは、ＳＴパケットに割り当てられたＩＰバージョン番号であり、Ｖｅｒフィールド６９に、ＳＴバージョン番号が含まれる。ＳＴの値は、＃５であり、Ｖｅｒの値は、C．トポルチック（Topolcic）編、"Experimental Internet Stream Protocol；Version ２(ST-II)”，RFC 1190、１９９０年１０月の定義によれば、ＳＴ−ＩＩの場合には＃２である。ＳＴ−ＩＩの場合、ＳＴ）ＶｅｒおよびＨＩＤフィールド６８ないし７０の内容を、ヘッダから抽出し、連結して、３２ビット・ワード＃００５２ＨＩＤにし、これを本発明のＰＦ１０に記憶する。ＣＬＮＰ上で構築されるＴＰ４のそれぞれのフレームならびに、ＣＬＮＰに対応するフレームを、第７図に示す。ＣＬＮＰパケット・ヘッダのそれぞれのフレームに割り当てられた略語を、表４で説明する。次に、ＣＬＮＰヘッダのフィールド７１ないし７４の典型的な値を示す。ＮＬＰＩ＝＃８１は、それぞれのプロトコルのバージヨン１を使用することを示す。Ｖ／ＰＩＥの値は、＃０１である。値１１１００は、ＤＴＰＤＵの場合にＴｙｐｅフレーム７４に割り当てられる。ＣＬＮＰヘッダの後続フィールド、ＮＬＰＩ＝＃８１、Ｖ／ＰＩＥ＝＃０１、Ｆ＝ＸおよびＴｙｐｅ＝Ｙを連結し、パディングして、３２ビット・ワード＃００８１０１ＸＹにする。このワードを、本明細書ではＣＬＮＰＨｄｒ５１（第５図）と称する。ＴＰ４ヘッダ・フィールドに使用される略語の意味を、表５に示す。前記ＴＰ４ヘッダのＤａｔａフィールド（ＤＴ７５）の値は、１１１１００００であり、これは、１６進数表記を使用すると＃Ｆ０に等しい。Ｄｅｓｔｉｎａｔｉｏｎｒｅｆｅｒｅｎｃｅ（ＤＲ７６）は、ＸＸＸＸであり、ＴＰ４へッダ（ＴＰ４Ｈｄｒ５２）と称する３２ビット・ワード＃Ｆ０００ＸＸＸＸをもたらす。この独特の３２ビット・ワードＣＬＮＰＨｄｒ５１とＴＰ４Ｈｄｒ５２は、下で説明するように本発明のＰＦ１０に記憶される。ここで第８図を参照すると、連想記憶（ＣＡＭ）８０が示されており、これは、ＰＦ１０の一部である。このＣＡＭ８０は、その入力８４のプロトコル情報、たとえばワード８３が、ある行に記憶されたワードと一致するたびに、そのワードを含む行のアドレスが出力８２に提示されることを特徴とする。たとえば、ワード＃１０００４５０００６がＣＡＭの入力８４に印加される場合、ＣＡＭは、入力８４のワードが記憶されたワードと一致すると同時に、その出力８２に対応する行のＣＡＭアドレスを提供する。この実施例のＣＡＭ８０は、２５６行を有するＣＡＭであるから、２⁸ビットを有するＣＡＭアドレスまたは２桁の１６進アドレスが必要である。所与の例では、行８１に対応する２桁アドレス＃０１が、出力８２に送られるはずである。ＣＡＭは、L．チスビム( Chisvim）他著、”Content-Addressable and Associative Memory”，IEEE Comp uter、１９８９年７月、５１〜６３ページに記載されている。第８図からわかるように、異なる経路がＣＡＭに記憶され、ＣＡＭでは、１行に１ツリー・レベルの情報（Ｔａｇ）、プロトコル・タイプ情報（ＰＴｙｐｅ）およびアドレス情報（ＨＩｄ）が含まれる。プロトコル・フィルタ内では、プロトコル情報とＣＡＭ内容を比較するのに２つの可能性がある。最も単純な方法は、このＣＡＭの行の幅である幅ｗの連結された情報ワードにヘッダ情報を連結し、これを１つの演算でＣＡＭの行と比較することである。この手法は、実施が簡単であるという長所を有する。ＣＡＭの幅は、可能な最大の数のヘッダ情報を連結した時に必要になるビット数によって決定される。第１の実施例で提示されたタグ付きのＣＡＭ８０は、通常のＣＡＭより少ないメモリ空間を消費する。操作する必要のあるヘッダ・ワードの数は、たとえばＸＴＰなどのプロトコルが媒体アクセス制御（ＭＡＣ）上に直接に構築される場合には１つであり、たとえば第４図の左側では多くとも５つである。タグ付きＣＡＭを使用することによって、プロトコルとプロトコル・アドレスの階層構造を利用できる。第８図では、例のＣＡＭの行８３が示されている。この行８３の最初の部分に、レベル番号とも称するタグが含まれ、これは、第４図および第５図のプロトコル・ツリーのうちの１つのそれぞれのレベルに等しい。タグ・フィールドの右の次のフィールドには、それぞれのプロトコル・タイプ情報（ＰＴｙｐｅ）が記憶され、その右に、たとえば３２ビット・ワードなどのアドレスＶｅｒ．Ｐｒｏｔ、Ｄ．Ａｄｄｒ．などが記憶される。前記タグ付きＣＡＭ８０を有する本発明のＰＰ１０のさまざまなユニットの相互作用を、第９図に関連してこれから説明する。ＰＦ１０には、次の４つのユニットが含まれる。すなわち、前述のＣＡＭ８０，プロトコル・タイプ検出機構（ＰＴＤ）９０、マスク生成機構（ＭＧ）９１および接続番号構築機構（ＣＮＢ）９５である。ＰＴＤ９０は、たとえばトークン・リングのバス９７上のヘッダ・プロトコル・タイプ情報を読み取り、着信プロトコル・ヘッダからプロトコル・タイプ情報を抽出する状態機械である。次に、ＰＴＤ９０は、このプロトコル・タイプ情報を、ＭＧ９１に転送する。ＬＬＣヘッダの場合、第３図に示されるように、ＰＴＤ９０は、テーブル内でＤＳＡＰを表引きすることによって、ＤＳＡＰフィールド３０からプロトコル・タイプ情報を抽出する。このテーブルは、図示されていないが、２５６×ｔのサイズのメモリであり、このｔは、ＭＧ９１のマスク・レジスタ（ＭＲ）９３内のプロトコル・タイプ・フィールド９９のサイズと等しい。ＤＳＡＰは、このテーブル内でプロトコル・タイプ情報を読み取るためのアドレスとして使用される。ＭＧ９１は、ヘッダ状態機械（ＨＳＭ）９４とタグ・カウンタ（ＴＣ）９２からなる。ＨＳＭ９４は、ＰＴＤプロトコル・タイプ情報によって起動され、ＨＳＭ９４は、バス９７を介して供給されるヘッダ・ファイルを順次読み取る。接続検出すなわちデータ・ストリームの処理に関連する情報を含むヘッダ・フィールドに達した楊合、そのヘッダ・フィールドが、ＭＲ９３のフィールド１００に書き込まれる。上で述べたように、タグによって、ヘッダ・ワードが有効であるツリー・レベルが決定される。ＴＣ９２は、ｃビット・カウンタであり、比較される関連フィールドごとに増分され、ＰＴＤ９０によってリセットされる。ＴＣＰ／ＩＰと他のほとんどのトランスポート・プロトコル・スタックの場合、２ビット・カウンタで十分である。ＩＰヘッダの場合（第６Ａ図参照）、１つの動作で、プロトコル情報であるＩＰヘッダ・フィールド６０ないし６３が、連結情報ワードと呼ばれる１つの３２ビット・ワード（＃００４５０００６）に連結され、ＣＡＭ８０の行と比較される。タグ・カウンタとＰＴＤタイプは、ＭＲ９３内でプロトコル情報と連結される。タグ・カウンタは、ＭＲ９３のタグ・フィールド９８に記憶される。前記ＭＲ９３のプロトコル・タイプ・フィールド９９のサイズｔは、処理しなければならない異なるプロトコルの数に依存する。６ビットあれば、現在のプロトコルのほとんどをカバーできる。第１の実施例によるＰＦ１０を用いると、第４図および第５図に示された２つの異なるプロトコル・タイプの処理が可能である。この具体的な例では、プロトコル・タイプ・フィールド９９の長さｔは、１ビットにすぎない。ＣＡＭ８０は、ＭＲ９３と同一の幅（ｗ＝ｃ＋ｔ＋３２ビット）を有する。一致の場合、そのデータのＣＡＭアドレスが出力される。ワード＃１０００５２ＨＩＤが前記ＭＲ９３に置かれる場合、ＭＲ９３の内容は、ＣＡＭアドレスＡ＝＃０５（＝０００００１０１）に記憶される行の内容と一致し、ＣＡＭアドレスＡ＝＃０５が、ＣＡＭの出力８２に供給される。プロトコル・タイプ情報とタグが、ＭＲ９３に含まれるので、出力８２でのＣＡＭ出力は、特定のプロトコル情報、プロトコル・タイプ情報およびツリー・レベルに関して独自である。ＣＡＭ８０は、外部から書き込むことができる。ＣＮＢ９５は、ＣＡＭ８０の出力でのＣＡＭアドレスを読み取り、プロトコル・ツリーのうちの１つを通る現経路のＣＡＭアドレスを連結することによって、独自の接続識別子を生成する。ＣＮＢ９５は、ＭＧ９１によってトリガされて、ＣＡＭの出力８２を読み取る。ＣＡＭ８０が一致を発見しない場合、ＣＮＢ９５がリセットされ、プロトコル情報は、現在のＰＦ１０に未知であり、ソフトウェアで処理しなければならない。このＣＮＢ９５は、第１０Ａ図および第１０Ｂ図に関連して示すように、ＬＬＣ／ＩＰ／ＴＣＰのスタック式プロトコル・ヘッダ（第４図のＩＰツリー内の短破線経路参照）から、独自の接続識別子すなわち独自の数を生成する。Ｖｅｒ．Ｐｒｏｔ．１０１、Ｓ．Ａｄｄｒ．１０２、Ｄ．Ａｄｄｒ．１０３およびＳ．Ｄ．Ｐ．１０４と称する８ビットＣＡＭアドレスを連結して、１つの連結された情報ワード１０５を形成する。ＬＬＣ／ＩＰ／ＴＣＰ経路の場合、このワードの値は、第１０Ｂ図に示されるように、１６進表記で＃０１０２０３０４である。プロトコル・タイプ情報、たとえば、この楊合ではＰＴｙｐｅ＝＃００がこのフードの前にある時には、独自の接続識別子＃０００１０２０３０４が、現在のプロトコル・スタックに割り当てられる。ＳＴ−ＩＩプロトコル・スタックの特徴を表す値＃００５２ＨＩＤが記憶されているＣＡＭ行のＣＡＭアドレスを連結する時には、接続番号＃０００５が得られる（Ａ＝＃０５の前にＰＴｙｐｅ＝＃００がある）。ＣＬＮＰの特徴を表す３２ビット・ワード＃００８１０１ＸＹ、ヘッダ、およびＴＰ４ヘッダに割り当てられた３２ビット・ワードが、ＣＡＭ８０のアドレス＃０７および＃０８に記憶される。独自の接続識別子は、プコトコル・タイプの特徴を表す数（ＰＴｙｐｅ）が前にあるこれら２つの８ビット幅１６進数を連結する時に、ＣＮＢ９５によって生成される。この、プロトコル・タイプ情報と称する、プロトコル・タイプの特徴を表す数は、現在の例では＃０１である。接続識別子の値は、＃０１０７０８になる。ＴＣＰ／ＩＰプロトコル・スタックの場合、Ｖｅｒ．ｐｒｏｔ．フィールドの値が、それぞれのプロトコル・スタックを識別する。ソース・アドレス（Ｓ．Ａｄｄｒ．）、デスティネーション・アドレス（Ｄ．Ａｄｄｒ．）およびソース／デスティネーション・ボート（Ｓ．Ｄ．Ｐ．）のそれぞれが、２５６個までのアドレスを識別できる。接続制御ブロックの配列内のポインタとして接続識別子を使用するためには、３２ビット接続識別子が、接続指標までカバーされなければならない。これは、下記の例の方法で行うことができる。Ｖｅｒ．Ｐｒｏｔ．フィールド１０１内で与えられる第１バイトを、特定のプロトコル・バージヨンの制御ブロック、この例ではＴＣＰ／ＩＰ制御ブロックの配列を指すポインタとして使用する。８ビット・アドレスは、各アドレスが別のツリー・レベルでの識別子を符号化するので、異なる。したがって、ツリー・レベルｉで２のｂ₁乗個のアドレスを区別するには、８ビットのうちのｂ₁ビットだけが必要である。接続指標は、各アドレスのｂ₁ビットを抽出し、これらを連結することによって生成される。ＣＡＭには、同一プロトコル・タイプでツリー・レベルｉのすべてのアドレスが、下位ｂ₁ビットで異なるように書き込まなければならない。たとえば、８個のソースＩＰアドレス、４個のデスティネーション・アドレスおよび８個のソース／デスティネーシヨン・アドレスを予約して接続指標を生成する場合、これらは、それぞれ３ビット、２ビットおよび３ビットで符号化できる。８ビット幅のワード１１０ないし１１２の２ビットおよび３ビットの識別子を連結して、第１１図に示される８ビットの連結された接続指標１１３にする。この例では、ＣＡＭ８０内の２０項目がＴＣＰ／ＩＰのために使用され、残りの２３６項目は、他のプロトコルのために空いている。レベルｉでのアドレス項目の最大個数が、動的な増大を許可され、レベルｉの２のｂ₁₊₁乗個のアドレスを区別しなければならない場合、ツリー・レベルｉのために使用されるすべてのアドレスを試験して、それらが下位ｂ₁₊₁ビットで異なっていることを保証しなければならない。接続指標１１３のサイズは、１ビットだけ増やされる。したがって、経路指定テーブルと称する、制御ブロックを指すポインタを保持するテーブルを作成しなければならず、接続指標は、このテーブルを指すポインタとして使用される。接続指標の生成とＣＡＭの管理は、アーキテクチャの柔軟性を保つために、プコトコル・プロセッサによって実行される。多くのプロトコル接続が、４未満のツリー・レベルを使用する。たとえば、ＳＴ−１１は、第４図のツリーの根４０と符号４２で与えられるプロトコル・タイプとストリーム識別子だけを使用する。結果の接続識別子は、１６個の優位なビットを有し、トークン・リング・ネットワーク・アダプタ１４によって、マルチメディア・データの検出とこれらのデータを専用装置で処理するのに直接に使用することができる。本発明の他の実施例を説明する前に、通常のＣＡＭに関するタグ付きＣＡＭの長所を指摘する。プロトコル・フィル夕では、必要なプロトコル情報をＣＡＭ内容と比較するのに３つの可能性がある。最も単純な方法は、第１の実施例に関連して説明したように、プロトコル情報、プロトコル・タイプ情報を含むワードおよびタグ（レベル番号）を連結して、幅ｗの連結された情報ワードにすることである。この手法は、「プロトコル・ツリー」の階層構造を利用している。実施が簡単な第２の手法は、あるプロトコル・ヘッダの関連プロトコル情報のすべてを連結して、幅ｋの１フードを形成することを特徴とする。ＣＡＭの幅ｋは、ヘッダ情報の可能な最大の個数を連結する時に必要なビット数によって決定される。必要なビット数は、第６Ａ図に示される、ＬＬＣ−Ｔｙｐｅ１を介するＴＣＰ／ＩＰでは、表６に示されるように１２８である。２５６接続をサポートするためには、２５６ＣＡＭ行、合計３２７６８ビットが必要である。ヘッダ情報は、プロトコル・タイプ検出機構（ＰＴＤ）およびマスク生成機構（ＭＧ）と同様の形で抽出される。第３の手法は、プロトコル・ヘッダからＣＡＭの入力へ読み取られる、それぞれがアドレス情報を担持するワードを、１ワードずつ順次印加することである。この手法によれば、ヘッダ・ワードをＣＡＭに印加する前にこれらを連結する必要も、「プロトコル・ツリー」の階層構造を反映して前記ＣＡＭに情報を記憶する必要もない。第１の実施例に関連して提示されたタグ付きのＣＡＭ８０は、他の２つの手法より少ないメモリ空間を消費する。走査する必要があるヘッダ・フィールドの数は、たとえばＭＡＣ（媒体直接制御）上に直接構築されるＸＴＰの場合には１つ、第４図の例では多くとも５つである。タグ付きの手法を使用することによって、プロトコルとプロトコル・アドレスの階層構造を利用できる。タグ情報がＭＲ９３に一体化されているので、４レベルまでが比較される。この例で２５６個のＴＣＰ／ＩＰ接続のために消費されるメモリ空間は、８００ビットすなわち、４０ビットのＣＡＭ幅の２０倍である。２５６個のＸＴＰ接続のためには、２５６行、合計１０２４０ビットが消費される。本発明の第２の実施例に関して、マルチプロトコル・ルータ１２４の一部であるプロトコル・フィルタ１２０を説明する。このマルチプロトコル・ルータ１２４には、第１２図に示されるように、経路指定テーブル（ＲＴ）１２５と経路指定エンジン１２７が含まれる。単純化のため、第２の実施例は、４つの異なるプロトコルすなわち、インターネット・プロトコル（ＩＰ）、システム・ネットワーク体系（ＳＮＡ）、Ｎｅｔｂｉｏｓ（ローカル・エリア・ネットワーク基本入出力システム）およびＯＳＩ（オープンシステム相互接続）に制限する。データ・ストリームが入力１２１を介して受信される場合、前記プロトコル・フィルタ１２０は、このデータ・ストリームを走査し、そのプロトコル・タイプ情報を抽出する。次に、すべての関連プロトコル・ヘッダ・フィールドを走査し、読み取る。これらのフィールドの情報は、前記プロトコル・タイプ情報の後にあり、タグ・カウンタによって生成されたレベル番号を使用してタグを付けられる。その後、タグ付きＣＡＭの同一項目を探し、ＣＡＭの出力に供給されるそれぞれのＣＡＭアドレスを連結して、独自の接続識別子を形成する。この独自の接続識別子またはその区別された接続指標は、リンク１２２を介して経路指定テーブル１２５に転送される。この経路指定テーブル１２５の経路指定情報の助けを得て、経路指定エンジン１２７は、プコトコル・ヘッダが走査され、同時にプロトコル・フィルタ１２０によって処理されるデータ・ストリームの処理を開始する。本発明の方法および装置の使用は、上で述べた２つの実施例に制限されるものではない。別の応用例を、第１３図および第１４図に示す。第１３図では、プロトコル・フィルタ１３０が、受信したオーディオ・データ、ビデオ・データおよび通常データの分離に使用される、マルチメディア・プロトコル・アダプタの一部として示されている。独自の接続識別子は、異なるデータ・ストリームの分離のために、ストリーム・デマルチプレクサ（ＳＤ）１３１に転送される。第１４図では、プロトコル・フィルタ１４０が、サーバ１４２に接続されている。受信データ並びに独自の接続識別子は、次の処理のためにプロトコル・プロセッサ（ＰＰ）１４１に転送される。プロトコル・フィルタは、軽量マルチメディア・アダプタ内で、等時性データ・ストリームおよび非同期データ・ストリームの分離と、データのチェックサム作成、非暗号化および圧縮解除のためのユニットをトリガするのにも使用できる。このようなマルチメディア・アダプタには、少なくとも、媒体アクセス制御（ＭＡＣ）ユニット、チェックサム・ユニット、直接メモリ・アクセス（ＤＭＡ）ユニットおよびプロトコル・フィルタが含まれる。前述の実施例および応用例のほかに、本発明によるプロトコル・フィルタを、プロトコル・スニッファとも称するプロトコル・アナライザで使用すると有利である。プロトコル・アナライザは、問題が発生した時に、その理由を監視するためにネットワークに挿入することができる。本発明のプロトコル・フィルタの典型的な環境は、ＦＤＤＩ（ファイバ分散データ・インターフェース）、ＡＴＭ（非同期転送モード）およびＦＣＳ（ファイバ・チャネル標準規格）ネットワークである。Description: METHOD AND APPARATUS FOR EXTRACTION OF CONNECTION INFORMATION FROM PROTOCOL HEADER TECHNICAL FIELD The present invention is for scanning a data stream in a communication network and providing a unique protocol connection identifier. A method and apparatus for extracting connection information. [Background Art] Due to the technical fusion of computers and communication networks and the rapid development in these two areas, a close mixture of information processing and communication has arisen, and the transmission and exchange of data, voice, images, etc. have become increasingly complex. Is becoming. Each transmission or exchange of information (used as a synonym for various types of data, services and communications) must necessarily be governed by rules of procedure. When different devices, such as two remote computer terminals, or two procedures, are interacting via an interface (which need not be a hardware interface), the respective protocol is used. Depending on the network, the various protocols are arranged in a hierarchy, resulting in a vertical stack of protocols, with each protocol interacting with its neighbors. Basic transport protocols are known for organizing information exchange and transmission between remote systems such as host computers. A typical example is the ARPA (Advanced Research Projects Agency) host-to-host protocol. Such a basic protocol allows the higher level protocols of the vertical protocol stack to base all of their operations on the basic protocol mechanism. Depending on the network environment, multiple higher level protocols are set up on the basic protocol. A schematic representation of a typical vertical protocol stack called the OSI (Open Systems Interconnection) Reference Model for CCITT (International Telegraph and Telephone Advisory Committee) applications is provided in CCITT Recommendation X. 200, "Reference Model of Open Systems Interconnection for CCITT Applications", Blue Book, Fascicle VIII. 4, Geneva, 1989. The OSI reference model uses seven levels called layers. Each layer has its own unique functionality and uses the services provided by the layers below to provide the defined services to the layers above. For example, if an application program running on the first system requires the use of data held on the second remote system, an exchange of information occurs. When the second system receives a request to send a particular data packet, the data packet is sent from the highest protocol level, such as the application layer, before being sent over the physical link. Must be transmitted down through the lower protocol level of. Each of these protocol layers adds to the data packet received from the higher layers connection information specific to that layer. Thus, the communication connection between two systems is defined in the packet header (hereinafter referred to as the protocol header) by the set of fields that carry the connection information of the vertical protocol stack. When a data stream consisting of data packets is received at the receiver site, before routing, multiplexing or compression, the protocol header is scanned for each word containing connection information for further processing. Must be extracted. To date, most protocol connections have been identified in software by serially processing the protocol header. This operation consumes a significant amount of protocol processing time, especially when processing large numbers of connections, such as in a server, or when processing multimedia data streams. A microprogrammed controller used to recognize the protocol type in the protocol header and extract the protocol-specific data field is described by HW Chin et al., “Implementing PE-1000 Based Internetworking Nodes”, Part 3 of 3, Transfer, Vol. 5, No. 3, May-June 1992, pp. 5-8. A hardware implementation of a routing table for translating packet identifiers into appropriate physical output links is described by TB Pay (Pei) and C. Zukowski, “Putting RoutingTables in Silicon”, IEEE Network Magazine, 1992. January, pages 42-50. This approach is primarily characterized by using associative memory (CAM) to match connection information in the header of a single protocol. In addition, the advantages and disadvantages of CAM versus conventional random access memory (RAM) used to store routing information were evaluated by Pay and Tsukowski. Both of the above two systems are related to solving side problems, but neither of these, nor any of the other known software techniques, is based on the Internet Protocol (IP, "Internet Protocol; DARPA Internet"). Program Protocol Specification ", RFC 791, DARPA (US Defense Advanced Research Projects Agency), September 1981" TCP (Transmission Control Protocol; DARPA Internet Program Protocol Specification ", RFC 793 , DARPA) September 981) and XTP (Express Transport Protocol, "XTPProtocol Definition", Protocol Engines Incorporated, Revisjon 3.6., Edited by Protocol Engines, Mountain View, California, USA, January 11, 1992). Alternatively, it is built on CLNP (Connectionless Network Protocol, "Protocol or Providing the Connectionless-Mode Network Service", ISO ISO / IEC 8473). It does not enable high-speed processing of multiple transport protocols such as P4 (transport protocol, type 4, "Connecti on Oriented Transport Protocol Specification", ISO / IEC JTCI Draft International Standard ISO / IEC DIS 8073). . The abbreviation RFC, as used herein, is an acronym for the term Request for Comments. Further, the present invention is applicable to, for example, ST-II (Stream Protocol, Version 2, edited by C. Topolcic, "Experimental Internet Stream Protocol; Version 2 (ST-II)", RFC119O, October 1990). Well-suited for handling multimedia traffic. Processing protocol headers and recognizing different protocol types in real time is a very complex and difficult task. In almost all network systems, header processing is still a major CPU (Central Processing Unit) cycle consumption activity. The present invention not only extracts the protocol data fields (see Chin et al.), But uses these fields to extract a unique connection identifier. This operation is performed in real time. Further, the method and apparatus of the present invention is designed to handle protocol stacks. It is an object of the present invention to provide a method for improved header processing in networks carrying various protocol traffic. Another object of the present invention is to provide a method for fast and reliable addressing of information in multi-protocol data streams. Another object of the present invention is to provide a method for fast and reliable processing of multi-protocol data streams containing multimedia data. Another object of the present invention is to provide a method that enables real-time addressing of complex protocol header information, ie a connection. Another object of the invention is to provide a hardware implementation of the method. SUMMARY OF THE INVENTION The above objects have been achieved by providing a method according to claim 9 and a hardware implementation of the method according to claim 1 called a protocol filter. The method and the device are characterized in that the protocol type information of the first protocol is extracted and the protocol information of the Pukotocol constructed on the first protocol is read sequentially. The protocol type information and the protocol information are applied to the input of the CAM and an address is provided at the output of the CAM whenever the information applied to this input matches the information stored in the CAM. The address supplied to this output is concatenated into a unique connection identifier. DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic Bumuk diagram of a protocol filter according to a first embodiment of the present invention. FIG. 2 shows a data stream headed by a protocol header containing header fields for two different protocols. FIG. 3 is a diagram showing an LLC (logical link control) frame. FIG. 4 is a diagram showing a hierarchical structure of TCP (transmission control protocol) constructed on IP (Internet Protocol) and ST-II protocol constructed on IP. FIG. 5 is a diagram showing a hierarchical structure of TP4 (transport protocol, type 4) constructed on CLNP (Connection Less Network Protocol). FIG. 6A is a diagram showing various fields of the TCP header constructed on the IP header. FIG. 6B is a diagram showing fields of the ST-II header. FIG. 7 is a diagram showing various fields of the TP4 header constructed on the CLNP header. FIG. 8 is a diagram showing an associative memory (CAM) used in the protocol filter of the first embodiment. FIG. 9 is a block diagram of a protocol filter according to the first embodiment of the present invention. FIG. 10A is a diagram showing connection identifiers distinguished by the protocol filter of the present invention. FIG. 10B is a diagram showing connection identifiers distinguished by the protocol filter of the present invention. FIG. 11 is a diagram showing connection indexes distinguished by the protocol filter of the present invention. FIG. 12 is a block diagram of a protocol filter as part of a multi-protocol filter according to a second embodiment of the present invention. FIG. 13 is a schematic block diagram of a protocol filter as part of a multimedia workstation. FIG. 14 is a schematic block diagram of a Pukotocol filter as part of the server. General Description When exchanging or transmitting information, such as data packets or multimedia data streams, in or along a network, the exchange or transmission is built on multiple protocol types. Protocol information of different protocol types is inserted in the protocol header of the transmitted data packet or data stream. The reception and processing of this protocol header must occur prior to routing the attached data stream through the switch or network, prior to compression of incoming traffic, or prior to its multiplexing. The processing of headers, and in particular the protocol-related words in headers, is usually done in network nodes, adapters, bridges, multiplexers, compressors, protocol analyzers and switches, to name a few. However, it is also done on the server. The basic concept of the present invention will be described with reference to the first environment. A protocol filter (hereinafter referred to as PF) 10 of the present invention is shown in FIG. PFI0 makes the handling of the protocol much simpler. This is because the layered protocol header connection identifier (according to the method of the present invention) is much faster when implemented in hardware. The function of PFI0 is to extract the relevant information from the protocol header of the received data stream or packet, compare this information with the stored connection information and provide the relevant connection identifier if the two data are equal. Is. In this embodiment, PFI0 is used in the token ring nethook adapter 14 to allow the protocol stream preceding the data stream 21 received over the bus 11, as schematically illustrated in FIG. Extract all relevant words from fields 22 to 27 of header 20. The output port 12 is provided with a connection identifier, which can be used for further processing. This other process depends on the environment in which the PF 10 is used. Before the data stream 21, there is the protocol header 20, as shown schematically in FIG. In this simplified diagram, the protocol header 20 comprises fields 22, 23 and 24 belonging to the first protocol and fields 25 to 27 belonging to the second protocol built on said first protocol. In this figure, the fields containing protocol information related to the processing of each data stream 21 are shaded. The PF 10 as part of the token ring network adapter 14 of the first embodiment is used in a token ring network carrying TCP / IP, ST-II and ISO CLNP / TP4 traffic. Details of the network are described in "IBM Token-Ring Network: Architecture Reference", SC30-3374-02, third edition) September 1989. The token ring network adapter 14 handles media access control (MAC) in its finite state machine. An LLC (Logical Link Control) frame in LPDU (Link Protocol Data Unit) format received by the token ring network adapter 14 and processed by the PF 10 is shown in FIG. A DSAP (Destination Service Access Point) field 30 identifies the access point for which the LPDU was intended. Typical values for the DSAP field 30 are described in "IBM Token-Ring Network: Architecture Reference", SC3 0-3 374-02, above. The DSAP value, or protocol type information, is used by the PF 10 as a starting point when searching in different protocol addresses. These protocol addresses are arranged in a tree according to the invention. In the first embodiment, the TCP / IP and ST-II addresses are part of the first tree shown in FIG. 4, and the address corresponding to the CLNP / TP4 protocol is the second shown in FIG. It is placed in a tree. The addresses and protocol-specific information used at the various layers of the Internet Protocol (IP) form the tree shown in FIG. The first protocol, TCP / IP, built on the Internet Protocol, is located on the left side of FIG. 4 and consists of four levels of tree. A TCP / IP connection is defined by a path (short dashed line) through the tree, starting from the root 40 of the tree, which represents the characteristics of the protocol type (= Internet) on which the TCP is built. The first level defines the protocol version (Ver.Prot.) 41, the second level is the source address (S.Addr.) 43, the third level is the destination address (D.Λddr.) 44, The fourth level defines the source / destination port (SDP) 45. The first path that defines this TCP / IP connection is stored in the associative memory of the PF 10, as will be described later. The second path (dashed line) defines the ST-II connection. This second path starts at the root 40 of the same tree and ends at the first level code 42. This second connection is defined in this example only by the protocol type (= Internet) and the protocol version (= # 00 52HID). This second route is also stored in the PF 10. The symbol # is used herein to represent hexadecimal notation. FIG. 6A is a diagram showing a TCP / IP header. At the top of Figure 6A, the Internet Protocol header is shown. The meanings of the abbreviations used for the IP header fields are listed in Table 1 below. The abbreviations of the IP header fields 60-65 that require processing at the PF 10, that is, which carry words of protocol information, are suffixed with the symbol *. The TCP portion of the protocol header is also shown in Figure 6A. The abbreviations used in the fields of this TCP header are listed in Table 2. The symbol * is added to the end of the abbreviations of the related fields 66 and 67 of the TCP header. The contents of the header field of the IP header are The tiles defined in "Experimental Internet Strealn Protocol; Version 2 (ST-II)", RFC 1190, October 1990, edited by Topolcic (specifically, page 75). The IP version number value (Ver; 60) is # 4, the normal header length of the Internet header (IHL 61) is # 5, and the service type field (TOS 62) is # 00. Yes, these values are all in hexadecimal notation. The protocol field (PROTO 63) of IP is based on J. Postel, "Assigned Numbers", RFC 790, holds an 8-bit number defined in September 1981. The 8-bit number of this protocol field (PROTO 63) is # 06. In accordance with the present invention, these four IP header fields 60-63 are concatenated and padded to obtain the 32 bit word stored in PF 10. In the current example, this is Ver. Prot. It results in a 32-bit word, # 00450006, which defines a protocol version called field 41 (first level of the tree in FIG. 4). The source address (SA 64) and destination address (DA 65) of the IP header are equal to the addresses at 43 (S. Addr.) And 44 (D. Addr.) In this tree. The format of the address held in these two fields is also described in J. Defined by Postel, "Assigned Numbers", RFC 790, September 1981. The source / destination port (SD) address 45 of the tree is derived from the source port (SP 66) and destination fields (DP 67) of the TCP header of Figure 6A. Details of TCP are described in the aforementioned protocol specification, "Transmission Control Protocol; DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. FIG. 8 shows how the four levels of the TCP / IP portion of the Dolly shown in FIG. 4 are stored in the protocol filter. A second protocol, the ST-II protocol header, derived from the Internet Protocol, is shown in FIG. 6B. Abbreviations are explained in Table 3. Fields 68-70 carry relevant protocol information. ST is an IP version number assigned to the ST packet, and the Ver field 69 includes the ST version number. The value of ST is # 5 and the value of Ver is C.I. According to the definition of "Experimental Internet Stream Protocol; Version 2 (ST-II)", edited by Topolcic, RFC 1190, October 1990, it is # 2 in the case of ST-II. For ST-II, the contents of the ST) Ver and HID fields 68-70 are extracted from the header and concatenated into the 32-bit word # 0052HID, which is stored in the PF 10 of the present invention. Each frame of TP4 constructed on CLNP and the frame corresponding to CLNP are shown in FIG. The abbreviations assigned to each frame of the CLNP packet header are described in Table 4. Next, typical values of the fields 71 to 74 of the CLNP header are shown. NL PI = # 81 indicates that version 1 of each protocol is used. The value of V / PIE is # 01. The value 11100 is assigned to the Type frame 74 for DT PDUs. The subsequent fields of the CLNP header, NLP I = # 81, V / PIE = # 01, F = X and Type = Y are concatenated and padded into the 32-bit word # 008101XY. This word is referred to herein as CLNP Hdr51 (FIG. 5). The meanings of the abbreviations used in the TP4 header field are shown in Table 5. The value of the Data field (DT 75) of the TP4 header is 11110000, which is equivalent to # F0 using hexadecimal notation. Destination reference (DR 76) is XXXX, which results in a 32-bit word # F000XXXX called TP4 header (TP4 Hdr 52). The unique 32-bit words CLNP Hdr 51 and TP4 Hdr 52 are stored in the PF 10 of the present invention as described below. Referring now to FIG. 8, an associative memory (CAM) 80 is shown, which is part of the PF 10. The CAM 80 is characterized in that whenever the protocol information of its input 84, for example the word 83, matches the word stored in a row, the address of the row containing that word is presented at the output 82. For example, if word # 1000450006 is applied to the input 84 of the CAM, the CAM provides the CAM address of the row corresponding to its output 82 at the same time that the word at input 84 matches the stored word. Since CAM80 of this embodiment is a CAM having 256 rows, 2 ⁸ A CAM address with bits or a two digit hexadecimal address is required. In the given example, the two digit address # 01 corresponding to row 81 would be sent to output 82. CAM is based on L.L. Chisvim et al., "Content-Addressable and Associative Memory", IEEE Computer, July 1989, pages 51-63. As can be seen from FIG. 8, different routes are stored in the CAM, where each row contains one tree level of information (Tag), protocol type information (PType) and address information (HId). Within the protocol filter, there are two possibilities to compare the protocol information with the CAM content. The simplest way is to concatenate the header information into a concatenated information word of width w which is the width of this CAM row and compare it with the CAM row in one operation. This approach has the advantage of being simple to implement. The width of the CAM is determined by the number of bits required when concatenating the maximum possible number of header information. The tagged CAM 80 presented in the first embodiment consumes less memory space than a normal CAM. The number of header words that need to be manipulated is one if the protocol, eg XTP, is built directly on the medium access control (MAC), eg at most 5 on the left side of FIG. Is one. By using tagged CAM, a hierarchical structure of protocols and protocol addresses can be utilized. In FIG. 8, an example CAM row 83 is shown. The first part of this line 83 contains a tag, also referred to as a level number, which is equal to the respective level of one of the protocol trees of FIGS. 4 and 5. The next field to the right of the tag field stores the protocol type information (PType) for each, and to the right of it is the address Ver. Prot, D.I. Addr. Are remembered. The interaction of the various units of the PP10 of the invention with the tagged CAM 80 will now be described with reference to FIG. The PF 10 includes the following four units. That is, the CAM 80, the protocol type detection mechanism (PTD) 90, the mask generation mechanism (MG) 91 and the connection number construction mechanism (CNB) 95 described above. The PTD 90 is, for example, a state machine that reads header protocol type information on the token ring bus 97 and extracts the protocol type information from the incoming protocol header. The PTD 90 then transfers this protocol type information to the MG 91. For the LLC header, the PTD 90 extracts the protocol type information from the DSAP field 30 by looking up the DSAP in the table, as shown in FIG. Although not shown, this table is a memory of size 256 × t, where t is equal to the size of the protocol type field 99 in the mask register (MR) 93 of MG 91. DSAP is used as the address to read the protocol type information in this table. MG 91 consists of a header state machine (HSM) 94 and a tag counter (TC) 92. The HSM94 is activated by the PTD protocol type information and the HSM94 sequentially reads the header files provided via the bus 97. When a header field is reached that contains information related to connection detection or data stream processing, that header field is written to field 100 of MR 93. As mentioned above, the tag determines which tree level the header word is valid. The TC92 is a c-bit counter that is incremented and reset by the PTD 90 for each relevant field that is compared. For TCP / IP and most other transport protocol stacks, a 2-bit counter is sufficient. In the case of the IP header (see FIG. 6A), in one operation, the protocol header IP header fields 60 to 63 are concatenated into one 32-bit word (# 00450006) called concatenation information word, and the CAM 80 Compared to the row. The tag counter and PTD type are concatenated with the protocol information in MR 93. The tag counter is stored in the tag field 98 of MR 93. The size t of the protocol type field 99 of the MR 93 depends on the number of different protocols that have to be processed. With 6 bits, most current protocols can be covered. With PF10 according to the first embodiment, it is possible to process two different protocol types shown in FIGS. 4 and 5. In this particular example, the length t of the protocol type field 99 is only 1 bit. The CAM 80 has the same width as the MR 93 (w = c + t + 32 bits). If they match, the CAM address of the data is output. When the word # 100052H ID is placed in the MR 93, the contents of the MR 93 match the contents of the row stored in the CAM address A = # 05 (= 0000 0101), and the CAM address A = # 05 outputs the CAM output. 82. Since the protocol type information and tags are included in the MR 93, the CAM output at output 82 is unique with respect to the particular protocol information, protocol type information and tree level. The CAM 80 can be written externally. The CNB 95 reads the CAM address at the output of the CAM 80 and concatenates the CAM address of the current path through one of the protocol trees to generate a unique connection identifier. The CNB 95 is triggered by MG 91 to read the output 82 of the CAM. If the CAM 80 does not find a match, the CNB 95 is reset and the protocol information is unknown to the current PF 10 and must be processed by software. The CNB 95, as shown in connection with FIGS. 10A and 10B, uses the unique connection identifier from the LLC / IP / TCP stack protocol header (see short dashed path in the IP tree of FIG. 4). That is, it creates its own number. Ver. Prot. 101, S.I. Addr. 102, D.I. A ddr. 103 and S. D. P. The 8-bit CAM addresses, called 104, are concatenated to form one concatenated information word 105. For the LLC / IP / TCP path, the value of this word is # 01020304 in hexadecimal notation, as shown in Figure 10B. A unique connection identifier # 0001 020304 is assigned to the current protocol stack when protocol type information, eg, P Type = # 00 in this case, is in front of this hood. When concatenating the CAM address of the CAM row in which the value # 0052HID representing the characteristics of the ST-II protocol stack is stored, the connection number # 0005 is obtained (PType = # 00 before A = # 05). . The 32-bit word # 008101XY representing CLNP features, the header, and the 32-bit word assigned to the TP4 header are stored at addresses # 07 and # 08 of the CAM 80. The unique connection identifier is generated by the CNB 95 when concatenating these two 8-bit wide hexadecimal numbers preceded by a number (PType) that is characteristic of the Pcotocol type. The number indicating the characteristic of the protocol type, which is called protocol type information, is # 01 in the present example. The value of the connection identifier is # 010708. For the TCP / IP protocol stack, Ver. prot. The value of the field identifies each protocol stack. Each of the source address (S. A. Drdr), destination address (D. Addr.) And source / destination port (S. D.P.) can identify up to 256 addresses. To use the connection identifier as a pointer in the array of connection control blocks, the 32-bit connection identifier must be covered up to the connection index. This can be done by the method of the example below. Ver. Prot. The first byte provided in field 101 is used as a pointer to the control block for the particular protocol version, in this example the array of TCP / IP control blocks. 8-bit addresses are different because each address encodes an identifier at a different tree level. Therefore, b at 2 at tree level i ₁ To distinguish the exponentiated addresses, b out of 8 bits is used. ₁ Only a bit is needed. The connection index is b for each address ₁ It is generated by extracting bits and concatenating them. In the CAM, all addresses at the tree level i with the same protocol type are ₁ Must be written differently in bits. For example, if you reserve 8 source IP addresses, 4 destination addresses and 8 source / destination addresses to generate a connection indicator, these are 3 bits, 2 bits and 3 bits respectively. Can be encoded with. The 2-bit and 3-bit identifiers of 8-bit wide words 110-112 are concatenated into the 8-bit concatenated connection index 113 shown in FIG. In this example, 20 items in CAM 80 are used for TCP / IP and the remaining 236 items are free for other protocols. The maximum number of address items at level i is allowed to grow dynamically, level 2 b of level i. _{1 + 1} If we have to distinguish the exponentiated addresses, we test all the addresses used for tree level i so that _{1 + 1} You have to ensure that they are bit different. The size of the connection index 113 is increased by 1 bit. Therefore, a table, called a routing table, must be created to hold a pointer to the control block, the connection index being used as a pointer to this table. Connection index generation and CAM management are performed by the Pukotocol processor to maintain architectural flexibility. Many protocol connections use tree levels below 4. For example, ST-11 uses only the protocol type and stream identifier given by the root 40 and 42 of the tree of FIG. The resulting connection identifier has 16 dominant bits and can be directly used by the token ring network adapter 14 to detect multimedia data and process these data on dedicated devices. it can. Before explaining another embodiment of the present invention, the advantages of the tagged CAM with respect to a normal CAM will be pointed out. In the protocol filter, there are three possibilities to compare the required protocol information with the CAM content. The simplest method is to concatenate a word containing protocol information, protocol type information and a tag (level number), as described in connection with the first embodiment, into a concatenated information word of width w. It is to be. This approach utilizes a hierarchical structure of "protocol trees". A second approach, which is simple to implement, is characterized by concatenating all the relevant protocol information in a protocol header to form a hood of width k. The width k of the CAM is determined by the number of bits required when concatenating the maximum possible number of header information. The required number of bits is 128 as shown in Table 6 for TCP / IP over LLC-Type 1 shown in FIG. 6A. To support 256 connections, 256 CAM rows, 32768 total bits are required. The header information is extracted in the same manner as the protocol type detection mechanism (PTD) and mask generation mechanism (MG). A third approach is to sequentially apply the words, each carrying address information, read word by word from the protocol header to the input of the CAM. According to this approach, it is not necessary to concatenate the header words before applying them to the CAM or to store information in said CAM reflecting the hierarchical structure of the "protocol tree". The tagged CAM 80 presented in connection with the first embodiment consumes less memory space than the other two approaches. The number of header fields that need to be scanned is, for example, one for XTP built directly on the MAC (Media Direct Control) and at most five in the example of FIG. By using the tagged approach, you can take advantage of the hierarchical structure of protocols and protocol addresses. Since tag information is integrated in the MR 93, up to 4 levels are compared. The memory space consumed for 256 TCP / IP connections in this example is 20 times the CAM width of 800 bits or 40 bits. For 256 XTP connections, 256 rows are consumed, for a total of 10240 bits. With respect to the second embodiment of the present invention, the protocol filter 120 that is part of the multi-protocol router 124 is described. The multi-protocol router 124 includes a routing table (RT) 125 and a routing engine 127, as shown in FIG. For simplicity, the second embodiment has four different protocols: Internet Protocol (IP), Systems Network Architecture (SNA), Netbios (Local Area Network Basic Input / Output System) and OSI (Open System). Mutual interconnection). When a data stream is received via input 121, the protocol filter 120 scans this data stream and extracts its protocol type information. It then scans and reads all relevant protocol header fields. The information in these fields follows the protocol type information and is tagged using the level number generated by the tag counter. It then looks for the same item in the tagged CAM and concatenates each CAM address provided at the output of the CAM to form a unique connection identifier. This unique connection identifier or its distinguished connection indicator is transferred to the routing table 125 via the link 122. With the help of the routing information in this routing table 125, the routing engine 127 begins processing the data stream being scanned by the protocol header and simultaneously processed by the protocol filter 120. Use of the method and apparatus of the present invention is not limited to the two embodiments described above. Another application example is shown in FIGS. 13 and 14. In FIG. 13, protocol filter 130 is shown as part of a multimedia protocol adapter used to separate received audio data, video data and normal data. The unique connection identifier is transferred to the stream demultiplexer (SD) 131 for the separation of different data streams. In FIG. 14, the protocol filter 140 is connected to the server 142. The received data as well as the unique connection identifier are transferred to the Protocol Processor (PP) 141 for further processing. Protocol filters also trigger separation of isochronous and asynchronous data streams and trigger units for checksumming, decrypting and decompressing data within the lightweight multimedia adapter. Can be used. Such multimedia adapters include at least a media access control (MAC) unit, a checksum unit, a direct memory access (DMA) unit and a protocol filter. In addition to the embodiments and applications described above, it is advantageous to use the protocol filter according to the invention in a protocol analyzer, also called protocol sniffer. When a problem occurs, a protocol analyzer can be inserted in the network to monitor the reason. Typical environments for the protocol filter of the present invention are FDDI (Fiber Distributed Data Interface), ATM (Asynchronous Transfer Mode) and FCS (Fibre Channel Standard) networks.

Claims

[Claims] 1. A data stream protocol for processing the data stream. In an apparatus for providing a connection identifier extracted from a header (20), said The protocol header (20) includes a field of the first protocol and the first protocol. The second protocol fields (22-24, 2 and 2) constructed based on Tocol 5 to 27), Protocol tie of the first protocol in the protocol header (20) Means for scanning the data stream to detect and read the group information (protocol). Coll type detection mechanism 90), The first protocol field and the second protocol of the protocol header (20) Data field of the field (22-24, 25-27) of Rotocol Means for reading protocol information related to the processing of the stream (mask generation mechanism 91 )When, In the input (84) of the associative memory (CAM80), the protocol type information and the Means for applying protocol information and The protocol type information and the protocol applied to the input (84) The Col information is compared with the information stored in the CAM (80) and the CAM (80 ) Output (82) providing a CAM address containing the same information, The CAM address supplied to the output (82) of the CAM (80). Means for generating the connection identifier by connecting the dresses (connection number construction machine Structure 95) A device that includes. 2. Further, each of the protocol information, preferably in word units, Concatenated with protocol type information and input the concatenated information to CAM input (84) Means for Forming One Said Concatenated Information Before Applying (Mask Regis Device according to claim 1, including a switch 93). 3. Further, the following protocol is applied by the reading means (mask generation mechanism 91). A counter (tag counter 92 that increments the level number each time information is read. ), The output of the counter (92) is at the beginning of the concatenated information word. Means for concatenating (mask to insert the generated level number) A register 93) connected to the counter (92) for the related protocol information. It is reset when everything is read, and the next protocol's 3. The apparatus according to claim 2, wherein the increment is initiated again by each. 4. Further, by connecting only the upper bits of the CAM address, the connection identifier From the CAM supplied to the output (82) of the CAM (80) before forming The apparatus of claim 1 including means for extracting only the high order bits. 5. Further, in the CAM (80), information applied to the input (84) of the CAM. If no information matches The device of claim 1, including means for processing the protocol header by Place. 6. The connection identifier contains all the information needed to process the data stream. Specially used as a pointer to the provided routing table (125). The device of claim 1, which is a signature. 7. The first protocol is Internet Protocol (IP) or ST- Device according to claim 1, characterized in that it is an 11 multimedia protocol. Place. 8. Part of a multimedia protocol adapter or a multiprotocol router (124), concentrator, part of a bridge or switch, or protocol analyzer The device of claim 1 which is part of an Iser. 9. A data stream protocol for processing the data stream. In a method of supplying the required connection identifier extracted from a header (20) , The protocol header (20) includes a first protocol field, The fields of the second protocol constructed on one protocol (22 to 24, 25 to 27), a) In order to read the protocol type information of the first protocol, Scanning the Tokol header (20), b) providing protocol information related to the processing of the data stream to the protocol. Col header (20) first protocol Field and the second protocol field (22 to 24, 25 to 27) the step of reading in c) Read in associative memory (CAM80) input (84) in steps a) and b) Applying the captured protocol type information and the protocol information. Tep, d) Information stored in the CAM (80) and the protocol type information and And the protocol information are compared, and the same information is output to the output (82) of the CAM (80). Providing a CAM address including e) Concatenate the CAM address supplied to the output (82) of the CAM (80) Generating the connection identifier by Including the method. 10. The third protocol in which the protocol header is built on the second protocol. Including the field of Tocol, the method is f) A protocol related to the processing of the data stream of the third protocol. Read the information, g) to carry out step d) of claim 9 so that the Applying protocol information to the input (84) of the CAM (80); 10. The method of claim 9, comprising: 11. Further builds on top of said third protocol and beyond The steps are performed in a similar fashion for each of the Claim 1 The method described in 0. 12. h) Each of said protocol information, preferably in word units, Concatenating with the protocol information to form a concatenated information word, i) applying the concatenated information word to the input (84) of the CAM (80) , Performing step d) of claim 9, 10. The method of claim 9, comprising: 13. j) Each time the protocol information is read from the protocol header, the level The step of incrementing the k) prior to performing step d) of claim 9, the linked information of step h) The step of inserting the level number at the beginning of the information word 13. The method of claim 12, comprising: