JP2732549B2 - プロトコル・ヘッダから接続情報を抽出するための方法および装置 - Google Patents
プロトコル・ヘッダから接続情報を抽出するための方法および装置Info
- Publication number
- JP2732549B2 JP2732549B2 JP6520550A JP52055094A JP2732549B2 JP 2732549 B2 JP2732549 B2 JP 2732549B2 JP 6520550 A JP6520550 A JP 6520550A JP 52055094 A JP52055094 A JP 52055094A JP 2732549 B2 JP2732549 B2 JP 2732549B2
- Authority
- JP
- Japan
- Prior art keywords
- protocol
- information
- cam
- header
- data stream
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
- H04L45/7453—Address table lookup; Address filtering using hashing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
Description
【発明の詳細な説明】 ［技術分野］ 本発明は、通信ネットワーク内のデータ・ストリーム
を走査し、独自のプロトコル接続識別子を提供するため
に接続情報を抽出する方法および装置に関する。
を走査し、独自のプロトコル接続識別子を提供するため
に接続情報を抽出する方法および装置に関する。
［背景技術］ コンピュータと通信ネットワークの技術的融合ならび
にこれら２つの領域での迅速な発展のため、情報処理と
通信の緊密な混合が生じ、データ、音声、画像などの伝
送と交換がますます複雑になってきている。情報（さま
ざまな種類のデータ、サービスおよび通信の同義語とし
て使用する）のそれぞれの伝送または交換は、必然的に
手順規則によって管理しなければならない。
にこれら２つの領域での迅速な発展のため、情報処理と
通信の緊密な混合が生じ、データ、音声、画像などの伝
送と交換がますます複雑になってきている。情報（さま
ざまな種類のデータ、サービスおよび通信の同義語とし
て使用する）のそれぞれの伝送または交換は、必然的に
手順規則によって管理しなければならない。
異なる装置たとえば２台の遠隔コンピュータ端末、ま
たは２つの手順が、インターフェース（ハードウェア・
インターフェースである必要はない）を介して対話して
いる時には、それぞれのプロトコルが使用される。ネッ
トワークに応じて、さまざまなプロトコルが階層的に並
べられ、各プロトコルがそれぞれ隣接するプロトコルと
対話するプロトコルの垂直スタックがもたらされる。ホ
スト・コンピュータなどの遠隔システム間の情報交換と
伝送を編成するための基本トランスポート・プロトコル
が知られている。典型的な例が、ARPA（Advanced Resea
rch Projects Agency）ホスト間プロトコルである。こ
のような基本プロトコルを用いると、垂直プロトコル・
スタックの上位プロトコルが、その動作のすべてを基本
プロトコル機構に基づくものとすることが可能になる。
たは２つの手順が、インターフェース（ハードウェア・
インターフェースである必要はない）を介して対話して
いる時には、それぞれのプロトコルが使用される。ネッ
トワークに応じて、さまざまなプロトコルが階層的に並
べられ、各プロトコルがそれぞれ隣接するプロトコルと
対話するプロトコルの垂直スタックがもたらされる。ホ
スト・コンピュータなどの遠隔システム間の情報交換と
伝送を編成するための基本トランスポート・プロトコル
が知られている。典型的な例が、ARPA（Advanced Resea
rch Projects Agency）ホスト間プロトコルである。こ
のような基本プロトコルを用いると、垂直プロトコル・
スタックの上位プロトコルが、その動作のすべてを基本
プロトコル機構に基づくものとすることが可能になる。
ネットワーク環境に応じて、複数の上位プロトコルが
基本プロトコル上にセットアップされる。CCITT（国際
電信電話諮問委員会）アプリケーション用のOSI（オー
プン・システム相互接続）参照モデルと称する典型的な
垂直プロトコル・スタックの概略表現が、CCITT勧告X.2
00、“Reference Model of Open Systems Interconnect
ion for CCITT Applications",Blue Book,Fascicle VII
I.4、ジュネーブ、1989年で定義されている。前記OSI参
照モデルでは、レイヤと称する７つのレベルを使用す
る。各レイヤは、それ自体の固有機能を有し、下のレイ
ヤによって提供されるサービスを使用して上のレイヤに
定義済みサービスを提供する。
基本プロトコル上にセットアップされる。CCITT（国際
電信電話諮問委員会）アプリケーション用のOSI（オー
プン・システム相互接続）参照モデルと称する典型的な
垂直プロトコル・スタックの概略表現が、CCITT勧告X.2
00、“Reference Model of Open Systems Interconnect
ion for CCITT Applications",Blue Book,Fascicle VII
I.4、ジュネーブ、1989年で定義されている。前記OSI参
照モデルでは、レイヤと称する７つのレベルを使用す
る。各レイヤは、それ自体の固有機能を有し、下のレイ
ヤによって提供されるサービスを使用して上のレイヤに
定義済みサービスを提供する。
たとえば、第１のシステムで走行するアプリケーショ
ン・プログラムが第２の遠隔システムに保持されている
データの使用を要求する場合、情報の交換が行われる。
前記第２のシステムが特定のデータ・パケットの送信を
求める要求を受け取る時に、このデータ・パケットは、
物理リンクを介して送信される前に、アプリケーション
・レイヤなどの最上位プロトコル・レベルから、すべて
の下位プロトコル・レベルを介して下に伝送されなけれ
ばならない。これらのプロトコル・レイヤのそれぞれ
が、上位レイヤから受け取ったデータ・パケットに、そ
のレイヤに固有の接続情報を追加する。したがって、２
つのシステムの間の通信接続は、垂直プロトコル・スタ
ックの接続情報を担持するフィールドの集合によって、
パケット・ヘッダ（以下、プロトコル・ヘッダと呼称す
る）内で定義される。
ン・プログラムが第２の遠隔システムに保持されている
データの使用を要求する場合、情報の交換が行われる。
前記第２のシステムが特定のデータ・パケットの送信を
求める要求を受け取る時に、このデータ・パケットは、
物理リンクを介して送信される前に、アプリケーション
・レイヤなどの最上位プロトコル・レベルから、すべて
の下位プロトコル・レベルを介して下に伝送されなけれ
ばならない。これらのプロトコル・レイヤのそれぞれ
が、上位レイヤから受け取ったデータ・パケットに、そ
のレイヤに固有の接続情報を追加する。したがって、２
つのシステムの間の通信接続は、垂直プロトコル・スタ
ックの接続情報を担持するフィールドの集合によって、
パケット・ヘッダ（以下、プロトコル・ヘッダと呼称す
る）内で定義される。
レシーバ・サイトでデータ・パケットからなるデータ
・ストリームを受信する時には、経路指定、多重化また
は圧縮の前に、前記プロトコル・ヘッダを走査して、次
の処理のために接続情報を含むそれぞれのワードを抽出
しなければならない。
・ストリームを受信する時には、経路指定、多重化また
は圧縮の前に、前記プロトコル・ヘッダを走査して、次
の処理のために接続情報を含むそれぞれのワードを抽出
しなければならない。
今日まで、プロトコル接続の大半は、ソフトウェアで
プロトコル・ヘッダを逐次処理することによって識別さ
れている。この動作は、たとえばサーバ内などの多数の
接続を処理する時やマルチメディア・データ・ストリー
ムを処理する時には特に、プロトコル処理のかなりの時
間を消費する。
プロトコル・ヘッダを逐次処理することによって識別さ
れている。この動作は、たとえばサーバ内などの多数の
接続を処理する時やマルチメディア・データ・ストリー
ムを処理する時には特に、プロトコル処理のかなりの時
間を消費する。
プロトコル・ヘッダのプロトコル・タイプを認識し、
プロトコル固有データ・フィールドを抽出するのに使用
されるマイクロプログラム式コントローラが、H.W.チン
（Chin）他著、“Implementing PE−1000 Based Intern
etworking Nodes",Part 3 of 3,Transfer,Vol.5,No.3,1
992年５月〜６月、５〜８ページに記載されている。
プロトコル固有データ・フィールドを抽出するのに使用
されるマイクロプログラム式コントローラが、H.W.チン
（Chin）他著、“Implementing PE−1000 Based Intern
etworking Nodes",Part 3 of 3,Transfer,Vol.5,No.3,1
992年５月〜６月、５〜８ページに記載されている。
パケット識別子を適切な物理出力リンクへ変換するた
めの経理指定テーブルのハードウェア実施態様が、T.B.
ペイ（Pei）およびC.ツコウスキ（Zukowski）著，“Put
ting Routing Tables in Silicon",IEEE Network Magaz
ine,1992年１月、42〜50ページに記載されている。この
手法は、主に、連想記憶（CAM）を使用して、単一プロ
トコルのヘッダ内の接続情報を突き合わせることを特徴
とする。さらに、経路指定情報の記憶に使用される、CA
M対通常のランダム・アクセス・メモリ（RAM）の長所と
短所が、ペイとツコウスキによって評価された。
めの経理指定テーブルのハードウェア実施態様が、T.B.
ペイ（Pei）およびC.ツコウスキ（Zukowski）著，“Put
ting Routing Tables in Silicon",IEEE Network Magaz
ine,1992年１月、42〜50ページに記載されている。この
手法は、主に、連想記憶（CAM）を使用して、単一プロ
トコルのヘッダ内の接続情報を突き合わせることを特徴
とする。さらに、経路指定情報の記憶に使用される、CA
M対通常のランダム・アクセス・メモリ（RAM）の長所と
短所が、ペイとツコウスキによって評価された。
上記の２つのシステムは、どちらもが副次的な問題の
解決に関連するが、このどちらも、また他の既知のソフ
トウェア手法のいずれもが、インターネット・プロトコ
ル（IP、“Internet Protocol;DARPA Internet Program
Protocol Specification",RFC 791,DARPA（米国国防高
等研究計画庁）、1981年９月）上で構築されるTCP（送
信制御プロトコル、“Transmission Control Protocol;
DARPA Internet Program Protocol Specification",RFC
793,DARPA、1981年９月）およびXTP（Express Transpo
rt Protocol、“XTP Protocol Definition",Protocol E
ngines Incorporated,Revision 3.6.,edited by Protoc
ol Engines,Mountain View,米国カリフォルニア州、199
2年１月11日）または、CLNP（Connectionless Network
Protocol、“Protocol for Providing the Connectionl
ess−Mode Network Service",ISO ISO/IEC 8473）上で
構築されるTP4（トランスポート・プロトコル、タイプ
４、“Connection Oriented Transport Protocol Speci
fication",ISO/IEC JTC1 Draft International Standar
d ISO/IEC DIS 8073）などの複数のトランスポート・プ
ロトコルの高速処理を可能にするものではない。本明細
書で使用する略語RFCは、用語Request for Comments
（コメント要求）の頭字語である。さらに、本発明は、
たとえばST−II（ストリーム・プロトコル、バージョン
２、C.トポルチック（Topolcic）編、“Experimental I
nternet Stream Protocol;Version 2（ST−II）",RFC 1
190、1990年10月）などのマルチメディア・トラフィッ
クの処理に十分に適している。リアルタイムでのプロト
コル・ヘッダの処理および異なるプロトコル・タイプの
認識は、非常に複雑で困難な作業である。ほとんどすべ
てのネットワーク・システムで、ヘッダ処理は、いまだ
に主要なCPU（中央処理装置）サイクル消費活動であ
る。本発明は、プロトコル・データ・フィールドを抽出
する（チン他参照）だけではなく、これらのフィールド
を使用して、独自の接続識別子を抽出する。この動作
は、リアルタイムで実行される。さらに、本発明の方法
および装置は、プロトコル・スタックを処理するように
設計されている。
解決に関連するが、このどちらも、また他の既知のソフ
トウェア手法のいずれもが、インターネット・プロトコ
ル（IP、“Internet Protocol;DARPA Internet Program
Protocol Specification",RFC 791,DARPA（米国国防高
等研究計画庁）、1981年９月）上で構築されるTCP（送
信制御プロトコル、“Transmission Control Protocol;
DARPA Internet Program Protocol Specification",RFC
793,DARPA、1981年９月）およびXTP（Express Transpo
rt Protocol、“XTP Protocol Definition",Protocol E
ngines Incorporated,Revision 3.6.,edited by Protoc
ol Engines,Mountain View,米国カリフォルニア州、199
2年１月11日）または、CLNP（Connectionless Network
Protocol、“Protocol for Providing the Connectionl
ess−Mode Network Service",ISO ISO/IEC 8473）上で
構築されるTP4（トランスポート・プロトコル、タイプ
４、“Connection Oriented Transport Protocol Speci
fication",ISO/IEC JTC1 Draft International Standar
d ISO/IEC DIS 8073）などの複数のトランスポート・プ
ロトコルの高速処理を可能にするものではない。本明細
書で使用する略語RFCは、用語Request for Comments
（コメント要求）の頭字語である。さらに、本発明は、
たとえばST−II（ストリーム・プロトコル、バージョン
２、C.トポルチック（Topolcic）編、“Experimental I
nternet Stream Protocol;Version 2（ST−II）",RFC 1
190、1990年10月）などのマルチメディア・トラフィッ
クの処理に十分に適している。リアルタイムでのプロト
コル・ヘッダの処理および異なるプロトコル・タイプの
認識は、非常に複雑で困難な作業である。ほとんどすべ
てのネットワーク・システムで、ヘッダ処理は、いまだ
に主要なCPU（中央処理装置）サイクル消費活動であ
る。本発明は、プロトコル・データ・フィールドを抽出
する（チン他参照）だけではなく、これらのフィールド
を使用して、独自の接続識別子を抽出する。この動作
は、リアルタイムで実行される。さらに、本発明の方法
および装置は、プロトコル・スタックを処理するように
設計されている。
本発明の目的は、さまざまなプロトコルのトラフィッ
クを担持するネットワーク内での改良されたヘッダ処理
のための方法を提供することである。
クを担持するネットワーク内での改良されたヘッダ処理
のための方法を提供することである。
本発明のもう１つの目的は、マルチ・プロトコル・デ
ータ・ストリームの情報の、高速で信頼性のあるアドレ
ッシングの処理すなわち接続のための方法を提供するこ
とである。
ータ・ストリームの情報の、高速で信頼性のあるアドレ
ッシングの処理すなわち接続のための方法を提供するこ
とである。
本発明のもう１つの目的は、マルチメディア・データ
を含むマルチ・プロトコル・データ・ストリームの高速
で信頼性のある処理の方法を提供することである。
を含むマルチ・プロトコル・データ・ストリームの高速
で信頼性のある処理の方法を提供することである。
本発明のもう１つの目的は、複合プロトコル・ヘッダ
の情報のリアルタイムのアドレッシングの処理すなわち
接続を可能にする方法を提供することである。
の情報のリアルタイムのアドレッシングの処理すなわち
接続を可能にする方法を提供することである。
本発明のもう１つの目的は、前記方法のハードウェア
実施態様を提供することである。
実施態様を提供することである。
［発明の摘要］ 上記の目的は、請求項９に従う方法と、請求項１に従
う前記方法の、プロトコル・フィルタと称するハードウ
ェア実施態様とを提供することによって達成された。こ
の方法および装置は、第１のプロトコルのプロトコル・
タイプ情報が抽出され、前記第１プロトコル上で構築さ
れたプロトコルのプロトコル情報が逐次読み取られるこ
とを特徴とする。プロトコル・タイプ情報と前記プロト
コル情報を、CAMの入力に印加して、この入力に印加さ
れる情報が前記CAMに記憶された情報と一致するたびにC
AMの出力にアドレスを供給する。この出力に供給された
アドレスを連結して、独自の接続識別子にする。
う前記方法の、プロトコル・フィルタと称するハードウ
ェア実施態様とを提供することによって達成された。こ
の方法および装置は、第１のプロトコルのプロトコル・
タイプ情報が抽出され、前記第１プロトコル上で構築さ
れたプロトコルのプロトコル情報が逐次読み取られるこ
とを特徴とする。プロトコル・タイプ情報と前記プロト
コル情報を、CAMの入力に印加して、この入力に印加さ
れる情報が前記CAMに記憶された情報と一致するたびにC
AMの出力にアドレスを供給する。この出力に供給された
アドレスを連結して、独自の接続識別子にする。
［図面の説明］ 第１図は、本発明の第１の実施例によるプロトコル・
フィルタの概略ブロック図である。
フィルタの概略ブロック図である。
第２図は、２つの異なるプロトコルのヘッダ・フィー
ルドを含むプロトコル・ヘッダが先頭にあるデータ・ス
トリームを示す図である。
ルドを含むプロトコル・ヘッダが先頭にあるデータ・ス
トリームを示す図である。
第３図は、LLC（論理リンク制御）フレームを示す図
である。
である。
第４図は、IP（インターネット・プロトコル）上で構
築されるTCP（送信制御プロトコル）と、IP上で構築さ
れるST−IIプロトコルの階層構造を示す図である。
築されるTCP（送信制御プロトコル）と、IP上で構築さ
れるST−IIプロトコルの階層構造を示す図である。
第５図は、CLNP（Connection Less Network Protoco
l）上で構築されるTP4（トランスポート・プロトコル、
タイプ４）の階層構造を示す図である。
l）上で構築されるTP4（トランスポート・プロトコル、
タイプ４）の階層構造を示す図である。
第6A図は、IPヘッダ上で構築されるTCPヘッダの諸フ
ィールドを示す図である。
ィールドを示す図である。
第6B図は、ST−11ヘッダの諸フィールドを示す図であ
る。
る。
第７図は、CLNPヘッダ上で構築されるTP4ヘッダの諸
フィールドを示す図である。
フィールドを示す図である。
第８図は、第１実施例のプロトコル・フィルタで使用
される連想記憶（CAM）を示す図である。
される連想記憶（CAM）を示す図である。
第９図は、本発明の第１実施例によるプロトコル・フ
ィルタのブロック図である。
ィルタのブロック図である。
第10A図は、本発明のプロトコル・フィルタによって
区別される接続識別子を示す図である。
区別される接続識別子を示す図である。
第10B図は、本発明のプロトコル・フィルタによって
区別される接続識別子を示す図である。
区別される接続識別子を示す図である。
第11図は、本発明のプロトコル・フィルタによって区
別される接続指標を示す図である。
別される接続指標を示す図である。
第12図は、本発明の第２実施例による、マルチプロト
コル・フィルタの一部としてのプロトコル・フィルタの
ブロック図である。
コル・フィルタの一部としてのプロトコル・フィルタの
ブロック図である。
第13図は、マルチメディア・ワークステーションの一
部としてのプロトコル・フィルタの概略ブロック図であ
る。
部としてのプロトコル・フィルタの概略ブロック図であ
る。
第14図は、サーバの一部としてのプロトコル・フィル
タの概略ブロック図である。
タの概略ブロック図である。
［全般的説明］ データ・パケットやマルチメディア・データ・ストリ
ームなどの情報をネットワーク内またはネットワークに
沿って交換または送信する時には、その交換または送信
は、複数のプロトコル・タイプの上で構築される。異な
るプロトコル・タイプのプロトコル情報は、送信される
データ・パケットまたはデータ・ストリームのプロトコ
ル・ヘッダに挿入される。
ームなどの情報をネットワーク内またはネットワークに
沿って交換または送信する時には、その交換または送信
は、複数のプロトコル・タイプの上で構築される。異な
るプロトコル・タイプのプロトコル情報は、送信される
データ・パケットまたはデータ・ストリームのプロトコ
ル・ヘッダに挿入される。
このプロトコル・ヘッダの受信と処理は、交換機また
はネットワークを介する添付データ・ストリームの経路
指定の前、着信トラフィックの圧縮の前、またはその多
重化の前に、行わなければならない。ヘッダの処理、具
体的には、ヘッダ内のプロトコル関連ワードの処理は、
想像できる環境のいくつかを挙げると、通常はネットワ
ーク・ノード、アダプタ、ブリッジ、マルチプレクサ、
コンプレッサ、プロトコル・アナライザおよび交換機で
行われるが、サーバでも行われる。
はネットワークを介する添付データ・ストリームの経路
指定の前、着信トラフィックの圧縮の前、またはその多
重化の前に、行わなければならない。ヘッダの処理、具
体的には、ヘッダ内のプロトコル関連ワードの処理は、
想像できる環境のいくつかを挙げると、通常はネットワ
ーク・ノード、アダプタ、ブリッジ、マルチプレクサ、
コンプレッサ、プロトコル・アナライザおよび交換機で
行われるが、サーバでも行われる。
第１の環境に関連して、本発明の基本概念を説明す
る。本発明のプロトコル・フィルタ（以下、PFと呼称す
る）10を、第１図に示す。PF10によって、プロトコルの
処理がはるかに単純になる。というのは、レイヤ化され
たプロトコル・ヘッダの接続識別子（本発明の方法によ
る）が、ハードウェアで実施される時に、はるかに高速
になるからである。PF10の機能は、受信したデータ・ス
トリームまたはパケットのプロトコル・ヘッダから関連
情報を抽出し、この情報を記憶された接続情報と比較
し、２つのデータが等しい場合に関連する接続識別子を
提供することである。この実施例では、PF10を、トーク
ン・リング・ネットワーク・アダプタ14内で使用して、
第２図に概略的に示されるように、バス11を介して受信
するデータ・ストリーム21に先行するプロトコル・ヘッ
ダ20のフィールド22ないし27から関連ワードのすべてを
抽出する。出力ポート12に、接続識別子が供給され、こ
れを別の処理に使用することができる。この別の処理
は、PF10を使用する環境に依存する。
る。本発明のプロトコル・フィルタ（以下、PFと呼称す
る）10を、第１図に示す。PF10によって、プロトコルの
処理がはるかに単純になる。というのは、レイヤ化され
たプロトコル・ヘッダの接続識別子（本発明の方法によ
る）が、ハードウェアで実施される時に、はるかに高速
になるからである。PF10の機能は、受信したデータ・ス
トリームまたはパケットのプロトコル・ヘッダから関連
情報を抽出し、この情報を記憶された接続情報と比較
し、２つのデータが等しい場合に関連する接続識別子を
提供することである。この実施例では、PF10を、トーク
ン・リング・ネットワーク・アダプタ14内で使用して、
第２図に概略的に示されるように、バス11を介して受信
するデータ・ストリーム21に先行するプロトコル・ヘッ
ダ20のフィールド22ないし27から関連ワードのすべてを
抽出する。出力ポート12に、接続識別子が供給され、こ
れを別の処理に使用することができる。この別の処理
は、PF10を使用する環境に依存する。
第２図に概略的に示されるように、データ・ストリー
ム21の前に、前記プロトコル・ヘッダ20がある。この簡
略化された図では、プロトコル・ヘッダ20に、第１プロ
トコルに属するフィールド22、23および24と、前記第１
プロトコル上で構築される第２プロトコルに属するフィ
ールド25ないし27が含まれる。この図では、それぞれの
データ・ストリーム21の処理に関連するプロトコル情報
を含むフィールドに、斜線が書き込まれている。
ム21の前に、前記プロトコル・ヘッダ20がある。この簡
略化された図では、プロトコル・ヘッダ20に、第１プロ
トコルに属するフィールド22、23および24と、前記第１
プロトコル上で構築される第２プロトコルに属するフィ
ールド25ないし27が含まれる。この図では、それぞれの
データ・ストリーム21の処理に関連するプロトコル情報
を含むフィールドに、斜線が書き込まれている。
第１実施例の、前記トークン・リング・ネットワーク
・アダプタ14の一部としてのPF10は、TCP/IP、ST−IIお
よびISO CLNP/TP4トラフィックを担持するトークン・
リング・ネットワーク内で使用される。前記ネットワー
クの詳細は、“IBM Token−Ring Network:Architecture
Reference",SC30−3374−02,third edition 、1989年
９月に記載されている。トークン・リング・ネットワー
ク・アダプタ14は、その有限状態機械で媒体アクセス制
御（MAC）を処理する。トークン・リング・ネットワー
ク・アダプタ14が受信し、PF10によって処理される、LP
DU（リンク・プロトコル・データ・ユニット）フォーマ
ットのLLC（論理リンク制御）フレームを、第３図に示
す。DSAP（宛先サービス・アクセス・ポイント）フィー
ルド30は、前記LPDUが意図されたアクセス・ポイントを
識別する。DSAPフィールド30の典型的な値は、上述の
“IBM Token−Ring Network:Architecture Reference",
SC30−3374−02に記載されている。DSAP値すなわち、プ
ロトコル・タイプ情報は、異なるプロトコル・アドレス
の中での探索の際にPE10によって開始点として使用され
る。これらのプロトコル・アドレスは、本発明によっ
て、ツリーに配置される。第１実施例では、TCP/IPおよ
びST−IIアドレスが、第４図に示されれる第１ツリーの
一部であり、CLNP/TP4プロトコルに対応するアドレス
が、第５図に示される第２ツリーに配置される。
・アダプタ14の一部としてのPF10は、TCP/IP、ST−IIお
よびISO CLNP/TP4トラフィックを担持するトークン・
リング・ネットワーク内で使用される。前記ネットワー
クの詳細は、“IBM Token−Ring Network:Architecture
Reference",SC30−3374−02,third edition 、1989年
９月に記載されている。トークン・リング・ネットワー
ク・アダプタ14は、その有限状態機械で媒体アクセス制
御（MAC）を処理する。トークン・リング・ネットワー
ク・アダプタ14が受信し、PF10によって処理される、LP
DU（リンク・プロトコル・データ・ユニット）フォーマ
ットのLLC（論理リンク制御）フレームを、第３図に示
す。DSAP（宛先サービス・アクセス・ポイント）フィー
ルド30は、前記LPDUが意図されたアクセス・ポイントを
識別する。DSAPフィールド30の典型的な値は、上述の
“IBM Token−Ring Network:Architecture Reference",
SC30−3374−02に記載されている。DSAP値すなわち、プ
ロトコル・タイプ情報は、異なるプロトコル・アドレス
の中での探索の際にPE10によって開始点として使用され
る。これらのプロトコル・アドレスは、本発明によっ
て、ツリーに配置される。第１実施例では、TCP/IPおよ
びST−IIアドレスが、第４図に示されれる第１ツリーの
一部であり、CLNP/TP4プロトコルに対応するアドレス
が、第５図に示される第２ツリーに配置される。
インターネット・プロトコル（IP）のさまざまなレイ
ヤで使用されるアドレスおよびプロトコル固有情報が、
第４図に示されるツリーを形成する。インターネット・
プロトコル上で構築される第１プロトコルすなわちTCP/
IPは、第４図の左側に配置され、ツリーの４レベルから
なる。TCP/IP接続は、TCPが構築されるプロトコル・タ
イプ（＝インターネット）の特徴を表すツリーの根40か
ら始まる前記ツリーを介する経路（短破線）によって定
義される。第１レベルは、プロトコル・バージョン（Ve
r.Prot.）41を定義し、第２レベルはソース・アドレス
（S.Addr.）43、第３レベルはデスティネーション・ア
ドレス（D.Addr.）44、第４レベルはソース／デスティ
ネーション・ポート（S.D.P）45を定義する。このTCP/I
P接続を定義する第１経路は、後で説明するようにPF10
の連想記憶に記憶される。第２経路（破線）は、ST−II
接続を定義する。この第２経路は、同じツリーの根40か
ら始まり、第１レベルの符号42で終わる。この第２接続
は、この例ではプロトコル・タイプ（＝インターネッ
ト）とプロトコル・バージョン（＝＃0052HID）だけに
よって定義される。この第２経路も、PF10に記憶され
る。本明細書では、記号＃を使用して、16進数表記を表
す。
ヤで使用されるアドレスおよびプロトコル固有情報が、
第４図に示されるツリーを形成する。インターネット・
プロトコル上で構築される第１プロトコルすなわちTCP/
IPは、第４図の左側に配置され、ツリーの４レベルから
なる。TCP/IP接続は、TCPが構築されるプロトコル・タ
イプ（＝インターネット）の特徴を表すツリーの根40か
ら始まる前記ツリーを介する経路（短破線）によって定
義される。第１レベルは、プロトコル・バージョン（Ve
r.Prot.）41を定義し、第２レベルはソース・アドレス
（S.Addr.）43、第３レベルはデスティネーション・ア
ドレス（D.Addr.）44、第４レベルはソース／デスティ
ネーション・ポート（S.D.P）45を定義する。このTCP/I
P接続を定義する第１経路は、後で説明するようにPF10
の連想記憶に記憶される。第２経路（破線）は、ST−II
接続を定義する。この第２経路は、同じツリーの根40か
ら始まり、第１レベルの符号42で終わる。この第２接続
は、この例ではプロトコル・タイプ（＝インターネッ
ト）とプロトコル・バージョン（＝＃0052HID）だけに
よって定義される。この第２経路も、PF10に記憶され
る。本明細書では、記号＃を使用して、16進数表記を表
す。
第6A図は、TCP/IPヘッダを示す図である。第6A図の上
側に、インターネット・プロトコル・ヘッダを示す。IP
ヘッダ・フィールドに使用される略語の意味を、下の表
１にリストする。PF10での処理を必要とする、すなわ
ち、プロトコル情報からなるワードを担持するIPヘッダ
・フィールド60ないし65の略語は、末尾に記号＊を付
す。
側に、インターネット・プロトコル・ヘッダを示す。IP
ヘッダ・フィールドに使用される略語の意味を、下の表
１にリストする。PF10での処理を必要とする、すなわ
ち、プロトコル情報からなるワードを担持するIPヘッダ
・フィールド60ないし65の略語は、末尾に記号＊を付
す。
プロトコル・ヘッダのTCP部分も、第6A図に示す。こ
のTCPヘッダのフィールドに使用される略語を、表２に
リストする。TCPヘッダの関連フィールド66、67の略字
の末尾に、記号＊を付す。
のTCPヘッダのフィールドに使用される略語を、表２に
リストする。TCPヘッダの関連フィールド66、67の略字
の末尾に、記号＊を付す。
IPヘッダのヘッダ・フィールドの内容は、C.トポルチ
ック（Topolcic）編、“Experimental internet Stream
Protocol;Version 2（ST−II）",RFC 1190、1990年10
月に定義されている（具体的には、その第75ページ）。
IPバージョン番号の値（Ver;60）は、＃４であり、イン
ターネット・ヘッダの正常なヘッダ長（IHL 61）は、＃
５であり、サービス・タイプ・フィールド（TOS 62）
は、＃00であり、これらの値は、すべて16進数表記であ
る。IPのプロトコル・フィールド（PROTO 63）は、J.パ
ステル（Postel）著、“Assigned Numbers",RFC 790、1
981年９月で定義された８ビット数を保持する。このプ
ロトコル・フィールド（PROTO 63）の８ビット数は、＃
06である。本発明によって、これら４つのIPヘッダ・フ
ィールド60ないし63を連結し、パディングして、PF10に
記憶される32ビット・ワードを得る。これは、現在の例
では、Ver.Prot.フィールド41（第４図のツリーの第１
レベル）と称するプロトコル・バージョンを定義する32
ビット・ワード、＃00450006をもたらす。前記IPヘッダ
のソース・アドレス（SA 64）とデスティネーション・
アドレス（DA 65）は、このツリーの符号43（S.Addr.）
と44（D.Addr.）にあるアドレスと等しい。これら２つ
のフィールドに保持されるアドレスのフォーマットも、
J.パステル（Postel）著、“Assigned Numbers",RFC 79
0、1981年９月に定義されている。ツリーのソース／デ
スティネーション・ポート（S.D.P.）アドレス45は、第
6A図のTCPヘッダのソース・ポート（SP 66）フィールド
とデスティネーション・フィールド（DP 67）から導出
される。TCPの詳細は、前述のプロトコル仕様書、“Tra
nsmission Control Protocol;DARPA Internet Program
Protocol Specification",RFC 793,DARPA、1981年９月
に記載されている。第４図に示されたツリーのTCP/IP部
分の４つのレベルがプロトコル・フィルタにどのように
記憶されるかを、第８図に示す。
ック（Topolcic）編、“Experimental internet Stream
Protocol;Version 2（ST−II）",RFC 1190、1990年10
月に定義されている（具体的には、その第75ページ）。
IPバージョン番号の値（Ver;60）は、＃４であり、イン
ターネット・ヘッダの正常なヘッダ長（IHL 61）は、＃
５であり、サービス・タイプ・フィールド（TOS 62）
は、＃00であり、これらの値は、すべて16進数表記であ
る。IPのプロトコル・フィールド（PROTO 63）は、J.パ
ステル（Postel）著、“Assigned Numbers",RFC 790、1
981年９月で定義された８ビット数を保持する。このプ
ロトコル・フィールド（PROTO 63）の８ビット数は、＃
06である。本発明によって、これら４つのIPヘッダ・フ
ィールド60ないし63を連結し、パディングして、PF10に
記憶される32ビット・ワードを得る。これは、現在の例
では、Ver.Prot.フィールド41（第４図のツリーの第１
レベル）と称するプロトコル・バージョンを定義する32
ビット・ワード、＃00450006をもたらす。前記IPヘッダ
のソース・アドレス（SA 64）とデスティネーション・
アドレス（DA 65）は、このツリーの符号43（S.Addr.）
と44（D.Addr.）にあるアドレスと等しい。これら２つ
のフィールドに保持されるアドレスのフォーマットも、
J.パステル（Postel）著、“Assigned Numbers",RFC 79
0、1981年９月に定義されている。ツリーのソース／デ
スティネーション・ポート（S.D.P.）アドレス45は、第
6A図のTCPヘッダのソース・ポート（SP 66）フィールド
とデスティネーション・フィールド（DP 67）から導出
される。TCPの詳細は、前述のプロトコル仕様書、“Tra
nsmission Control Protocol;DARPA Internet Program
Protocol Specification",RFC 793,DARPA、1981年９月
に記載されている。第４図に示されたツリーのTCP/IP部
分の４つのレベルがプロトコル・フィルタにどのように
記憶されるかを、第８図に示す。
インターネット・プロトコルから導出された、第２の
プロトコルであるST−IIプロトコルのヘッダを第6B図に
示す。略語を、表３で解説する。フィールド68ないし70
は、関連するプロトコル情報を担持する。
プロトコルであるST−IIプロトコルのヘッダを第6B図に
示す。略語を、表３で解説する。フィールド68ないし70
は、関連するプロトコル情報を担持する。
STは、STパケットに割り当てられたIPバージョン番号
であり、Verフィールド69に、STバージョン番号が含ま
れる。STの値は、＃５であり、Verの値は、C.トポルチ
ック（Topolcic）編、“Experimental Internet Stream
Protocol;Version 2（ST−II）",RFC 1190、1990年10
月の定義によれば、ST−11の場合には＃２である。ST−
IIの場合、ST、VerおよびHIDフィールド68ないし70の内
容を、ヘッダから抽出し、連結して、32ビット・ワード
＃0052HIDにし、これを本発明のPF10に記憶する。
であり、Verフィールド69に、STバージョン番号が含ま
れる。STの値は、＃５であり、Verの値は、C.トポルチ
ック（Topolcic）編、“Experimental Internet Stream
Protocol;Version 2（ST−II）",RFC 1190、1990年10
月の定義によれば、ST−11の場合には＃２である。ST−
IIの場合、ST、VerおよびHIDフィールド68ないし70の内
容を、ヘッダから抽出し、連結して、32ビット・ワード
＃0052HIDにし、これを本発明のPF10に記憶する。
CLNP上で構築されるTP4のそれぞれのフレームならび
に、CLNPに対応するフレームを、第７図に示す。CLNPパ
ケット・ヘッダのそれぞれのフレームに割り当てられた
略語を、表４で説明する。
に、CLNPに対応するフレームを、第７図に示す。CLNPパ
ケット・ヘッダのそれぞれのフレームに割り当てられた
略語を、表４で説明する。
次に、CLNPヘッダのフィールド71ないし74の典型的な
値を示す。NLPI＝＃81は、それぞれのプロトコルのバー
ジョン１を使用することを示す。V/PIEの値は、＃01で
ある。値11100は、DT PDUの場合にTypeフレーム74に割
り当てられる。CLNPヘッダの後続フィールド、NLPI＝＃
81、V/PIE＝＃01、Ｆ＝ＸおよびType＝Ｙを連結し、パ
ディングして、32ビット・ワード＃008101XYにする。こ
のワードを、本明細書ではCLNP Hdr51（第５図）と称
する。TP4ヘッダ・フィールドに使用される略語の意味
を、表５に示す。
値を示す。NLPI＝＃81は、それぞれのプロトコルのバー
ジョン１を使用することを示す。V/PIEの値は、＃01で
ある。値11100は、DT PDUの場合にTypeフレーム74に割
り当てられる。CLNPヘッダの後続フィールド、NLPI＝＃
81、V/PIE＝＃01、Ｆ＝ＸおよびType＝Ｙを連結し、パ
ディングして、32ビット・ワード＃008101XYにする。こ
のワードを、本明細書ではCLNP Hdr51（第５図）と称
する。TP4ヘッダ・フィールドに使用される略語の意味
を、表５に示す。
前記TP4ヘッダのDataフィールド（DT 75）の値は、1
111 0000であり、これは、16進数表記を使用すると＃F
0に等しい。Destinationreference（DR 76）は、XXXX
であり、TP4ヘッダ（TP4 Hdr 52）と称する32ビット
・ワード＃F000XXXXをもたらす。この独特の32ビット・
ワードCLNP Hdr 51とTP4 Hdr 52は、下で説明するよう
に本発明のPF10に記憶される。
111 0000であり、これは、16進数表記を使用すると＃F
0に等しい。Destinationreference（DR 76）は、XXXX
であり、TP4ヘッダ（TP4 Hdr 52）と称する32ビット
・ワード＃F000XXXXをもたらす。この独特の32ビット・
ワードCLNP Hdr 51とTP4 Hdr 52は、下で説明するよう
に本発明のPF10に記憶される。
ここで第８図を参照すると、連想記憶（CAM）80が示
されており、これは、PF10の一部である。このCAM80
は、その入力84のプロトコル情報、たとえばワード83
が、ある行に記憶されたワードと一致するたびに、その
ワードを含む行のアドレスが出力82に提示されることを
特徴とする。たとえば、ワード＃1000450006がCAMの入
力84に印加される場合、CAMは、入力84のワードが記憶
されたワードと一致すると同時に、その出力82に対応す
る行のCAMアドレスを提供する。この実施例のCAM80は、
256行を有するCAMであるから、28ビットを有するCAMア
ドレスまたは２桁の16進アドレスが必要である。所与の
例では、行81に対応する２桁アドレス＃01が、出力82に
送られるはずである。CAMは、L.チスビム（Chisvim）他
著、“Content−Addressable and Associative Memor
y",IEEE Computer、1989年７月、51〜63ページに記載さ
れている。
されており、これは、PF10の一部である。このCAM80
は、その入力84のプロトコル情報、たとえばワード83
が、ある行に記憶されたワードと一致するたびに、その
ワードを含む行のアドレスが出力82に提示されることを
特徴とする。たとえば、ワード＃1000450006がCAMの入
力84に印加される場合、CAMは、入力84のワードが記憶
されたワードと一致すると同時に、その出力82に対応す
る行のCAMアドレスを提供する。この実施例のCAM80は、
256行を有するCAMであるから、28ビットを有するCAMア
ドレスまたは２桁の16進アドレスが必要である。所与の
例では、行81に対応する２桁アドレス＃01が、出力82に
送られるはずである。CAMは、L.チスビム（Chisvim）他
著、“Content−Addressable and Associative Memor
y",IEEE Computer、1989年７月、51〜63ページに記載さ
れている。
第８図からわかるように、異なる経路がCAMに記憶さ
れ、CAMでは、１行に１ツリー・レベルの情報（Tag）、
プロトコル・タイプ情報（PType）およびアドレス情報
（HId）が含まれる。プロトコル・フィルタ内では、プ
ロトコル情報とCAM内容を比較するのに２つの可能性が
ある。最も単純な方法は、このCAMの行の幅である幅ｗ
の連結された情報ワードにヘッダ情報を連結し、これを
１つの演算でCAMの行と比較することである。この手法
は、実施が簡単であるという長所を有する。CAMの幅
は、可能な最大の数のヘッダ情報を連結した時に必要に
なるビット数によって決定される。
れ、CAMでは、１行に１ツリー・レベルの情報（Tag）、
プロトコル・タイプ情報（PType）およびアドレス情報
（HId）が含まれる。プロトコル・フィルタ内では、プ
ロトコル情報とCAM内容を比較するのに２つの可能性が
ある。最も単純な方法は、このCAMの行の幅である幅ｗ
の連結された情報ワードにヘッダ情報を連結し、これを
１つの演算でCAMの行と比較することである。この手法
は、実施が簡単であるという長所を有する。CAMの幅
は、可能な最大の数のヘッダ情報を連結した時に必要に
なるビット数によって決定される。
第１の実施例で提示されたタグ付きのCAM80は、通常
のCAMより少ないメモリ空間を消費する。操作する必要
のあるヘッダ・ワードの数は、たとえばXTPなどのプロ
トコルが媒体アクセス制御（MAC）上に直接に構築され
る場合には１つであり、たとえば第４図の左側では多く
とも５つである。タグ付きCAMを使用することによっ
て、プロトコルとプロトコル・アドレスの階層構造を利
用できる。第８図では、例のCAMの行83が示されてい
る。この行83の最初の部分に、レベル番号とも称するタ
グが含まれ、これは、第４図および第５図のプロトコル
・ツリーのうちの１つのそれぞれのレベルに等しい。タ
グ・フィールドの右の次のフィールドには、それぞれの
プロトコル・タイプ情報（PType）が記憶され、その右
に、たとえば32ビット・ワードなどのアドレスVer.Pro
t、D.Addr.などが記憶される。
のCAMより少ないメモリ空間を消費する。操作する必要
のあるヘッダ・ワードの数は、たとえばXTPなどのプロ
トコルが媒体アクセス制御（MAC）上に直接に構築され
る場合には１つであり、たとえば第４図の左側では多く
とも５つである。タグ付きCAMを使用することによっ
て、プロトコルとプロトコル・アドレスの階層構造を利
用できる。第８図では、例のCAMの行83が示されてい
る。この行83の最初の部分に、レベル番号とも称するタ
グが含まれ、これは、第４図および第５図のプロトコル
・ツリーのうちの１つのそれぞれのレベルに等しい。タ
グ・フィールドの右の次のフィールドには、それぞれの
プロトコル・タイプ情報（PType）が記憶され、その右
に、たとえば32ビット・ワードなどのアドレスVer.Pro
t、D.Addr.などが記憶される。
前記タグ付きCAM80を有する本発明のPF10のさまざま
なユニットの相互作用を、第９図に関連してこれから説
明する。PF10には、次の４つのユニットが含まれる。す
なわち、前述のCAM80,プロトコル・タイプ検出機構（PT
D）90、マスク生成機構（MG）91および接続番号構築機
構（CNB）95である。
なユニットの相互作用を、第９図に関連してこれから説
明する。PF10には、次の４つのユニットが含まれる。す
なわち、前述のCAM80,プロトコル・タイプ検出機構（PT
D）90、マスク生成機構（MG）91および接続番号構築機
構（CNB）95である。
PTD90は、たとえばトークン・リングのバス97上のヘ
ッダ・プロトコル・タイプ情報を読み取り、着信プロト
コル・ヘッダからプロトコル・タイプ情報を抽出する状
態機械である。次に、PTD90は、このプロトコル・タイ
プ情報を、MG91に転送する。LLCヘッダの場合、第３図
に示されるように、PTD90は、テーブル内でDSAPを表引
きすることによって、DSAPフィールド30からプロトコル
・タイプ情報を抽出する。このテーブルは、図示されて
いないが、256×ｔのサイズのメモリであり、このｔ
は、MG91のマスク・レジスタ（MR）93内のプロトコル・
タイプ・フィールド99のサイズと等しい。DSAPは、この
テーブル内でプロトコル・タイプ情報を読み取るための
アドレスとして使用される。
ッダ・プロトコル・タイプ情報を読み取り、着信プロト
コル・ヘッダからプロトコル・タイプ情報を抽出する状
態機械である。次に、PTD90は、このプロトコル・タイ
プ情報を、MG91に転送する。LLCヘッダの場合、第３図
に示されるように、PTD90は、テーブル内でDSAPを表引
きすることによって、DSAPフィールド30からプロトコル
・タイプ情報を抽出する。このテーブルは、図示されて
いないが、256×ｔのサイズのメモリであり、このｔ
は、MG91のマスク・レジスタ（MR）93内のプロトコル・
タイプ・フィールド99のサイズと等しい。DSAPは、この
テーブル内でプロトコル・タイプ情報を読み取るための
アドレスとして使用される。
MG91は、ヘッダ状態機械（HSM）94とタグ・カウンタ
（TC）92からなる。HSM94は、PTDプロトコル・タイプ情
報によって起動され、HSM94は、バス97を介して供給さ
れるヘッダ・ファイルを順次読み取る。接続検出すなわ
ちデータ・ストリームの処理に関連する情報を含むヘッ
ダ・フィールドに達した場合、そのヘッダ・フィールド
が、MR93のフィールド100に書き込まれる。上で述べた
ように、タグによって、ヘッダ・ワードが有効であるツ
リー・レベルが決定される。TC92は、ｃビット・カウン
タであり、比較される関連フィールドごとに増分され、
PTD90によってリセットされる。TCP/IPと他のほとんど
のトランスポート・プロトコル・スタックの場合、２ビ
ット・カウンタで十分である。IPヘッダの場合（第6A図
参照）、１つの動作で、プロトコル情報であるIPヘッダ
・フィールド60ないし63が、連結情報ワードと呼ばれる
１つの32ビット・ワード（＃00450006）に連結され、CA
M80の行と比較される。タグ・カウンタとPTDタイプは、
MR93内でプロトコル情報と連結される。タグ、カウンタ
は、MR93のタグ・フィールド98に記憶される。前記MR93
のプロトコル・タイプ・フィールド99のサイズｔは、処
理しなければならない異なるプロトコルの数に依存す
る。６ビットあれば、現在のプロトコルのほとんどをカ
バーできる。第１の実施例によるPF10を用いると、第４
図および第５図に示された２つの異なるプロトコル・タ
イプの処理が可能である。この具体的な例では、プロト
コル・タイプ・フィールド99の長さｔは、１ビットにす
ぎない。
（TC）92からなる。HSM94は、PTDプロトコル・タイプ情
報によって起動され、HSM94は、バス97を介して供給さ
れるヘッダ・ファイルを順次読み取る。接続検出すなわ
ちデータ・ストリームの処理に関連する情報を含むヘッ
ダ・フィールドに達した場合、そのヘッダ・フィールド
が、MR93のフィールド100に書き込まれる。上で述べた
ように、タグによって、ヘッダ・ワードが有効であるツ
リー・レベルが決定される。TC92は、ｃビット・カウン
タであり、比較される関連フィールドごとに増分され、
PTD90によってリセットされる。TCP/IPと他のほとんど
のトランスポート・プロトコル・スタックの場合、２ビ
ット・カウンタで十分である。IPヘッダの場合（第6A図
参照）、１つの動作で、プロトコル情報であるIPヘッダ
・フィールド60ないし63が、連結情報ワードと呼ばれる
１つの32ビット・ワード（＃00450006）に連結され、CA
M80の行と比較される。タグ・カウンタとPTDタイプは、
MR93内でプロトコル情報と連結される。タグ、カウンタ
は、MR93のタグ・フィールド98に記憶される。前記MR93
のプロトコル・タイプ・フィールド99のサイズｔは、処
理しなければならない異なるプロトコルの数に依存す
る。６ビットあれば、現在のプロトコルのほとんどをカ
バーできる。第１の実施例によるPF10を用いると、第４
図および第５図に示された２つの異なるプロトコル・タ
イプの処理が可能である。この具体的な例では、プロト
コル・タイプ・フィールド99の長さｔは、１ビットにす
ぎない。
CAM80は、MR93と同一の幅（ｗ＝ｃ＋ｔ＋32ビット）
を有する。一致の場合、そのデータのCAMアドレスが出
力される。ワード＃100052HIDが前記MR93に置かれる場
合、MR93の内容は、CAMアドレスＡ＝＃05（＝0000 010
1）に記憶される行の内容と一致し、CAMアドレスＡ＝＃
05が、CAMの出力82に供給される。プロトコル・タイプ
情報とタグが、MR93に含まれるので、出力82でのCAM出
力は、特定のプロトコル情報、プロトコル・タイプ情報
およびツリー・レベルに関して独自である。CAM80は、
外部から書き込むことができる。
を有する。一致の場合、そのデータのCAMアドレスが出
力される。ワード＃100052HIDが前記MR93に置かれる場
合、MR93の内容は、CAMアドレスＡ＝＃05（＝0000 010
1）に記憶される行の内容と一致し、CAMアドレスＡ＝＃
05が、CAMの出力82に供給される。プロトコル・タイプ
情報とタグが、MR93に含まれるので、出力82でのCAM出
力は、特定のプロトコル情報、プロトコル・タイプ情報
およびツリー・レベルに関して独自である。CAM80は、
外部から書き込むことができる。
CNB95は、CAM80の出力でのCAMアドレスを読み取り、
プロトコル・ツリーのうちの１つを通る現経路のCAMア
ドレスを連結することによって、独自の接続識別子を生
成する。CNB95は、MG91によってトリガされて、CAMの出
力82を読み取る。CAM80が一致を発見しない場合、CNB95
がリセットされ、プロトコル情報は、現在のPF10に未知
であり、ソフトウェアで処理しなければならない。この
CNB95は、第10A図および第10B図に関連して示すよう
に、LLC/IP/TCPのスタック式プロトコル・ヘッダ（第４
図のIPツリー内の短破線経路参照）から、独自の接続識
別子すなわち独自の数を生成する。Ver.Prot.101、S.Ad
dr.102、D.Addr.103およびS.D.P.104と称する８ビットC
AMアドレスを連結して、１つの連結された情報ワード10
5を形成する。LLC/IP/TCP経路の場合、このワードの値
は、第10B図に示されるように、16進表記で＃01020304
である。プロトコル・タイプ情報、たとえば、この場合
ではPType＝＃00がこのワードの前にある時には、独自
の接続識別子＃0001020304が、現在のプロトコル・スタ
ックに割り当てられる。
プロトコル・ツリーのうちの１つを通る現経路のCAMア
ドレスを連結することによって、独自の接続識別子を生
成する。CNB95は、MG91によってトリガされて、CAMの出
力82を読み取る。CAM80が一致を発見しない場合、CNB95
がリセットされ、プロトコル情報は、現在のPF10に未知
であり、ソフトウェアで処理しなければならない。この
CNB95は、第10A図および第10B図に関連して示すよう
に、LLC/IP/TCPのスタック式プロトコル・ヘッダ（第４
図のIPツリー内の短破線経路参照）から、独自の接続識
別子すなわち独自の数を生成する。Ver.Prot.101、S.Ad
dr.102、D.Addr.103およびS.D.P.104と称する８ビットC
AMアドレスを連結して、１つの連結された情報ワード10
5を形成する。LLC/IP/TCP経路の場合、このワードの値
は、第10B図に示されるように、16進表記で＃01020304
である。プロトコル・タイプ情報、たとえば、この場合
ではPType＝＃00がこのワードの前にある時には、独自
の接続識別子＃0001020304が、現在のプロトコル・スタ
ックに割り当てられる。
ST−IIプロトコル・スタックの特徴を表す値＃0052HI
Dが記憶されているCAM行のCAMアドレスを連結する時に
は、接続番号＃0005が得られる（Ａ＝＃05の前にPType
＝＃00がある）。
Dが記憶されているCAM行のCAMアドレスを連結する時に
は、接続番号＃0005が得られる（Ａ＝＃05の前にPType
＝＃00がある）。
CLNPの特徴を表す32ビット・ワード＃008101XY、ヘッ
ダ、およびTP4ヘッダに割り当てられた32ビット・ワー
ドが、CAM80のアドレス＃07および＃08に記憶される。
独自の接続識別子は、プロトコル・タイプの特徴を表す
数（PType）が前にあるこれら２つの８ビット幅16進数
を連結する時に、CNB95によって生成される。この、プ
ロトコル・タイプ情報と称するが、プロトコル・タイプ
の特徴を表す数は、現在の例では＃01である。接続識別
子の値は、＃010708になる。
ダ、およびTP4ヘッダに割り当てられた32ビット・ワー
ドが、CAM80のアドレス＃07および＃08に記憶される。
独自の接続識別子は、プロトコル・タイプの特徴を表す
数（PType）が前にあるこれら２つの８ビット幅16進数
を連結する時に、CNB95によって生成される。この、プ
ロトコル・タイプ情報と称するが、プロトコル・タイプ
の特徴を表す数は、現在の例では＃01である。接続識別
子の値は、＃010708になる。
TCP/IPプロトコル・スタックの場合、Ver.Prot.フィ
ールドの値が、それぞれのプロトコル・スタックを識別
する。ソース・アドレス（S.Addr.）、デスティネーシ
ョン・アドレス（D.Addr.）およびソース／デスティネ
ーション・ポート（S.D.P.）のそれぞれが、256個まで
のアドレスを識別できる。接続制御ブロックの配列内の
ポインタとして接続識別子を使用するためには、32ビッ
ト接続識別子が、接続指標までカバーされなければなら
ない。これは、下記の例の方法で行うことができる。Ve
r.Prot.フィールド101内で与えられる第１バイトを、特
定のプロトコル・バージョンの制御ブロック、この例で
はTCP/IP制御ブロックの配列を指すポインタとして使用
する。８ビット・アドレスは、各アドレスが別のツリー
・レベルでの識別子を符号化するので、異なる。したが
って、ツリー・レベルｉで２のbi乗個のアドレスを区別
するには、８ビットのうちのbiビットだけが必要であ
る。接続指標は、各アドレスのbiビットを抽出し、これ
らを連結することによって生成される。CAMには、同一
プロトコル・タイプでツリー・レベルｉのすべてのアド
レスが、下位biビットで異なるように書き込まなければ
ならない。
ールドの値が、それぞれのプロトコル・スタックを識別
する。ソース・アドレス（S.Addr.）、デスティネーシ
ョン・アドレス（D.Addr.）およびソース／デスティネ
ーション・ポート（S.D.P.）のそれぞれが、256個まで
のアドレスを識別できる。接続制御ブロックの配列内の
ポインタとして接続識別子を使用するためには、32ビッ
ト接続識別子が、接続指標までカバーされなければなら
ない。これは、下記の例の方法で行うことができる。Ve
r.Prot.フィールド101内で与えられる第１バイトを、特
定のプロトコル・バージョンの制御ブロック、この例で
はTCP/IP制御ブロックの配列を指すポインタとして使用
する。８ビット・アドレスは、各アドレスが別のツリー
・レベルでの識別子を符号化するので、異なる。したが
って、ツリー・レベルｉで２のbi乗個のアドレスを区別
するには、８ビットのうちのbiビットだけが必要であ
る。接続指標は、各アドレスのbiビットを抽出し、これ
らを連結することによって生成される。CAMには、同一
プロトコル・タイプでツリー・レベルｉのすべてのアド
レスが、下位biビットで異なるように書き込まなければ
ならない。
たとえば、８個のソースIPアドレス、４個のデスティ
ネーション・アドレスおよび８個のソース／デスティネ
ーション・アドレスを予約して接続指標を生成する場
合、これらは、それぞれ３ビット、２ビットおよび３ビ
ットで符号化できる。８ビット幅のワード110ないし112
の２ビットおよび３ビットの識別子を連結して、第11図
に示される８ビットの連結された接続指標113にする。
この例では、CAM80内の20項目がTCP/IPのために使用さ
れ、残りの236項目は、他のプロトコルのために空いて
いる。レベルｉでのアドレス項目の最大個数が、動的な
増大を許可され、レベルｉの２のbi+1乗個のアドレスを
区別しなければならない場合、ツリー・レベルｉのため
に使用されるすべてのアドレスを試験して、それらが下
位bi+1ビットで異なっていることを保証しなければなら
ない。接続指標113のサイズは、１ビットだけ増やされ
る。したがって、経路指定テーブルと称する、制御ブロ
ックを指すポインタを保持するテーブルを作成しなけれ
ばならず、接続指標は、このテーブルを指すポインタと
して使用される。接続指標の生成とCAMの管理は、アー
キテクチャの柔軟性を保つために、プロトコル・プロセ
ッサによって実行される。
ネーション・アドレスおよび８個のソース／デスティネ
ーション・アドレスを予約して接続指標を生成する場
合、これらは、それぞれ３ビット、２ビットおよび３ビ
ットで符号化できる。８ビット幅のワード110ないし112
の２ビットおよび３ビットの識別子を連結して、第11図
に示される８ビットの連結された接続指標113にする。
この例では、CAM80内の20項目がTCP/IPのために使用さ
れ、残りの236項目は、他のプロトコルのために空いて
いる。レベルｉでのアドレス項目の最大個数が、動的な
増大を許可され、レベルｉの２のbi+1乗個のアドレスを
区別しなければならない場合、ツリー・レベルｉのため
に使用されるすべてのアドレスを試験して、それらが下
位bi+1ビットで異なっていることを保証しなければなら
ない。接続指標113のサイズは、１ビットだけ増やされ
る。したがって、経路指定テーブルと称する、制御ブロ
ックを指すポインタを保持するテーブルを作成しなけれ
ばならず、接続指標は、このテーブルを指すポインタと
して使用される。接続指標の生成とCAMの管理は、アー
キテクチャの柔軟性を保つために、プロトコル・プロセ
ッサによって実行される。
多くのプロトコル接続が、４未満のツリー・レベルを
使用する。たとえば、ST−IIは、第４図のツリーの根40
と符号42で与えられるプロトコル・タイプとストリーム
識別子だけを使用する。結果の接続識別子は、16個の優
位なビットを有し、トークン・リング・ネットワーク・
アダプタ14によって、マルチメディア・データの検出と
これらのデータを専用装置で処理するのに直接に使用す
ることができる。
使用する。たとえば、ST−IIは、第４図のツリーの根40
と符号42で与えられるプロトコル・タイプとストリーム
識別子だけを使用する。結果の接続識別子は、16個の優
位なビットを有し、トークン・リング・ネットワーク・
アダプタ14によって、マルチメディア・データの検出と
これらのデータを専用装置で処理するのに直接に使用す
ることができる。
本発明の他の実施例を説明する前に、通常のCAMに関
するタグ付きCAMの長所を指摘する。プロトコル・フィ
ルタでは、必要なプロトコル情報をCAM内容と比較する
のに３つの可能性がある。最も単純な方法は、第１の実
施例に関連して説明したように、プロトコル情報、プロ
トコル・タイプ情報を含むワードおよびタグ（レベル番
号）を連結して、幅ｗの連結された情報ワードにするこ
とである。この手法は、「プロトコル・ツリー」の階層
構造を利用している。実施が簡単な第２の手法は、ある
プロトコル・ヘッダの関連プロトコル情報のすべてを連
結して、幅ｋの１ワードを形成することを特徴とする。
CAMの幅ｋは、ヘッダ情報の可能な最大の個数を連結す
る時に必要なビット数によって決定される。必要なビッ
ト数は、第6A図に示される、LLC−Type1を介するTCP/IP
では、表６に示されるように128である。
するタグ付きCAMの長所を指摘する。プロトコル・フィ
ルタでは、必要なプロトコル情報をCAM内容と比較する
のに３つの可能性がある。最も単純な方法は、第１の実
施例に関連して説明したように、プロトコル情報、プロ
トコル・タイプ情報を含むワードおよびタグ（レベル番
号）を連結して、幅ｗの連結された情報ワードにするこ
とである。この手法は、「プロトコル・ツリー」の階層
構造を利用している。実施が簡単な第２の手法は、ある
プロトコル・ヘッダの関連プロトコル情報のすべてを連
結して、幅ｋの１ワードを形成することを特徴とする。
CAMの幅ｋは、ヘッダ情報の可能な最大の個数を連結す
る時に必要なビット数によって決定される。必要なビッ
ト数は、第6A図に示される、LLC−Type1を介するTCP/IP
では、表６に示されるように128である。
256接続をサポートするためには、256CAM行、合計327
68ビットが必要である。ヘッダ情報は、プロトコル・タ
イプ検出機構（PTD）およびマスク生成機構（MG）と同
様の形で抽出される。
68ビットが必要である。ヘッダ情報は、プロトコル・タ
イプ検出機構（PTD）およびマスク生成機構（MG）と同
様の形で抽出される。
第３の手法は、プロトコル・ヘッダからCAMの入力へ
読み取られる、それぞれがアドレス情報を担持するワー
ドを、１ワードずつ順次印加することである。この手法
によれば、ヘッダ・ワードをCAMに印加する前にこれら
を連結する必要も、「プロトコル・ツリー」の階層構造
を反映して前記CAMに情報を記憶する必要もない。
読み取られる、それぞれがアドレス情報を担持するワー
ドを、１ワードずつ順次印加することである。この手法
によれば、ヘッダ・ワードをCAMに印加する前にこれら
を連結する必要も、「プロトコル・ツリー」の階層構造
を反映して前記CAMに情報を記憶する必要もない。
第１の実施例に関連して提示されたタグ付きのCAM80
は、他の２つの手法より少ないメモリ空間を消費する。
走査する必要があるヘッダ・フィールドの数は、たとえ
ばMAC（媒体直接制御）上に直接構築されるXTPの場合に
は１つ、第４図の例では多くとも５つである。タグ付き
の手法を使用することによって、プロトコルとプロトコ
ル・アドレスの階層構造を利用できる。タグ情報がMR93
に一体化されているので、４レベルまでが比較される。
この例で256個のTCP/IP接続のために消費されるメモリ
空間は、800ビットすなわち、40ビットのCAM幅の20倍で
ある。256個のXTP接続のためには、256行、合計10240ビ
ットが消費される。
は、他の２つの手法より少ないメモリ空間を消費する。
走査する必要があるヘッダ・フィールドの数は、たとえ
ばMAC（媒体直接制御）上に直接構築されるXTPの場合に
は１つ、第４図の例では多くとも５つである。タグ付き
の手法を使用することによって、プロトコルとプロトコ
ル・アドレスの階層構造を利用できる。タグ情報がMR93
に一体化されているので、４レベルまでが比較される。
この例で256個のTCP/IP接続のために消費されるメモリ
空間は、800ビットすなわち、40ビットのCAM幅の20倍で
ある。256個のXTP接続のためには、256行、合計10240ビ
ットが消費される。
本発明の第２の実施例に関して、マルチプロトコル・
ルータ124の一部であるプロトコル・フィルタ120を説明
する。このマルチプロトコル・ルータ124には、第12図
に示されるように、経路指定テーブル（RT）125と経路
指定エンジン127が含まれる。単純化のため、第２の実
施例は、４つの異なるプロトコルすなわち、インターネ
ット・プロトコル（IP）、システム・ネットワーク体系
（SNA）、Netbios（ローカル・エリア・ネットワーク基
本入出力システム）およびOSI（オープンシステム相互
接続）に制限する。データ・ストリームが入力121を介
して受信される場合、前記プロトコル・フィルタ120
は、このデータ・ストリームを走査し、そのプロトコル
・タイプ情報を抽出する。次に、すべての関連プロトコ
ル・ヘッダ・フィールドを走査し、読み取る。これらの
フィールドの情報は、前記プロトコル・タイプ情報の後
にあり、タグ・カウンタによって生成されたレベル番号
を使用してタグを付けられる。その後、タグ付きCAMの
同一項目を探し、CAMの出力に供給されるそれぞれのCAM
アドレスを連結して、独自の接続識別子を形成する。こ
の独自の接続識別子またはその区別された接続指標は、
リンク122を介して経路指定テーブル125に転送される。
この経路指定テーブル125の経路指定情報の助けを得
て、経路指定エンジン127は、プロトコル・ヘッダが走
査され、同時にプロトコル・フィルタ120によって処理
されるデータ・ストリームの処理を開始する。
ルータ124の一部であるプロトコル・フィルタ120を説明
する。このマルチプロトコル・ルータ124には、第12図
に示されるように、経路指定テーブル（RT）125と経路
指定エンジン127が含まれる。単純化のため、第２の実
施例は、４つの異なるプロトコルすなわち、インターネ
ット・プロトコル（IP）、システム・ネットワーク体系
（SNA）、Netbios（ローカル・エリア・ネットワーク基
本入出力システム）およびOSI（オープンシステム相互
接続）に制限する。データ・ストリームが入力121を介
して受信される場合、前記プロトコル・フィルタ120
は、このデータ・ストリームを走査し、そのプロトコル
・タイプ情報を抽出する。次に、すべての関連プロトコ
ル・ヘッダ・フィールドを走査し、読み取る。これらの
フィールドの情報は、前記プロトコル・タイプ情報の後
にあり、タグ・カウンタによって生成されたレベル番号
を使用してタグを付けられる。その後、タグ付きCAMの
同一項目を探し、CAMの出力に供給されるそれぞれのCAM
アドレスを連結して、独自の接続識別子を形成する。こ
の独自の接続識別子またはその区別された接続指標は、
リンク122を介して経路指定テーブル125に転送される。
この経路指定テーブル125の経路指定情報の助けを得
て、経路指定エンジン127は、プロトコル・ヘッダが走
査され、同時にプロトコル・フィルタ120によって処理
されるデータ・ストリームの処理を開始する。
本発明の方法および装置の使用は、上で述べた２つの
実施例に制限されるものではない。別の応用例を、第13
図および第14図に示す。第13図では、プロトコル・フィ
ルタ130が、受信したオーディオ・データ、ビデオ・デ
ータおよび通常データの分離に使用される、マルチメデ
ィア・プロトコル・アダプタの一部として示されてい
る。独自の接続識別子は、異なるデータ・ストリームの
分離のために、ストリーム・デマルチプレクサ（SD）13
1に転送される。第14図では、プロトコル・フィルタ140
が、サーバ142に接続されている。受信データ並びに独
自の接続識別子は、次の処理のためにプロトコル・プロ
セッサ（PP）141に転送される。
実施例に制限されるものではない。別の応用例を、第13
図および第14図に示す。第13図では、プロトコル・フィ
ルタ130が、受信したオーディオ・データ、ビデオ・デ
ータおよび通常データの分離に使用される、マルチメデ
ィア・プロトコル・アダプタの一部として示されてい
る。独自の接続識別子は、異なるデータ・ストリームの
分離のために、ストリーム・デマルチプレクサ（SD）13
1に転送される。第14図では、プロトコル・フィルタ140
が、サーバ142に接続されている。受信データ並びに独
自の接続識別子は、次の処理のためにプロトコル・プロ
セッサ（PP）141に転送される。
プロトコル・フィルタは、軽量マルチメディア・アダ
プタ内で、等時性データ・ストリームおよび非同期デー
タ・ストリームの分離と、データのチェックサム作成、
非暗号化および圧縮解除のためのユニットをトリガする
のにも使用できる。このようなマルチメディア・アダプ
タには、少なくとも、媒体アクセス制御（MAC）ユニッ
ト、チェックサム・ユニット、直接メモリ・アクセス
（DMA）ユニットおよびプロトコル・フィルタが含まれ
る。
プタ内で、等時性データ・ストリームおよび非同期デー
タ・ストリームの分離と、データのチェックサム作成、
非暗号化および圧縮解除のためのユニットをトリガする
のにも使用できる。このようなマルチメディア・アダプ
タには、少なくとも、媒体アクセス制御（MAC）ユニッ
ト、チェックサム・ユニット、直接メモリ・アクセス
（DMA）ユニットおよびプロトコル・フィルタが含まれ
る。
前述の実施例および応用例のほかに、本発明によるプ
ロトコル・フィルタを、プロトコル・スニッファとも称
するプロトコル・アナライザで使用すると有利である。
プロトコル・アナライザは、問題が発生した時に、その
理由を監視するためにネットワークに挿入することがで
きる。
ロトコル・フィルタを、プロトコル・スニッファとも称
するプロトコル・アナライザで使用すると有利である。
プロトコル・アナライザは、問題が発生した時に、その
理由を監視するためにネットワークに挿入することがで
きる。
本発明のプロトコル・フィルタの典型的な環境は、FD
DI（ファイバ分散データ・インターフェース）、ATM
（非同期転送モード）およびFCS（ファイバ・チャネル
標準規格）ネットワークである。
DI（ファイバ分散データ・インターフェース）、ATM
（非同期転送モード）およびFCS（ファイバ・チャネル
標準規格）ネットワークである。
Claims (13)
- 【請求項１】データ・ストリームの処理のため、前記デ
ータ・ストリームのプロトコル・ヘッダ（20）から抽出
される接続識別子を提供するための装置において、前記
プロトコル・ヘッダ（20）が、第１のプロトコルのフィ
ールドと、前記第１プロトコルに基づいて構築される第
２プロトコルのフィールド（22ないし24、25ないし27）
とを含み、 前記プロトコル・ヘッダ（20）内の前記第１プロトコル
のプロトコル・タイプ情報を検出し、読み取るために前
記データ・ストリームを走査する手段（プロトコル・タ
イプ検出機構90）と、 前記プロトコル・ヘッダ（20）の第１プロトコルのフィ
ールドおよび第２プロトコルのフィールド（22ないし2
4、25ないし27）の、前記データ・ストリームの処理に
関連するプロトコル情報を読み取る手段（マスク生成機
構91）と、 連想記憶（CAM80）の入力（84）に前記プロトコル・タ
イプ情報と前記プロトコル情報とを印加する手段と、 前記入力（84）に印加された前記プロトコル・タイプ情
報および前記プロトコル情報を、前記CAM（80）に記憶
された情報と比較し、前記CAM（80）の出力（82）に同
一の情報を含むCAMアドレスを供給する手段と、 CAM（80）の前記出力（82）に供給されたCAMアドレスを
連結することによって前記接続識別子を生成する手段
（接続番号構築機構95）と を含む装置。 - 【請求項２】さらに、前記プロトコル情報のそれぞれ
を、好ましくはワード単位で、前記プロトコル・タイプ
情報と連結して、連結された情報をCAMの入力（84）に
適用する前に１つの前記連結された情報を形成するため
の手段（マスク・レジスタ93）を含む、請求項１に記載
の装置。 - 【請求項３】さらに、前記読み取る手段（マスク生成機
構91）によって次のプロトコル情報が読み取られるたび
にレベル番号を増分するカウンタ（タグ・カウンタ92）
を含み、前記カウンタ（92）の出力が、前記連結された
情報ワードの先頭に生成された前記レベル番号を挿入す
るために、前記連結するための手段（マスク・レジスタ
93）に接続され、前記カウンタ（92）が、関連プロトコ
ル情報のすべてが読み取られたときにリセットされ、次
のプロトコルのプロトコル情報のそれぞれによって再び
増分を開始する、請求項２に記載の装置。 - 【請求項４】さらに、前記CAMアドレスの上位ビット群
だけを連結して前記接続識別子を形成する前に、CAM（8
0）の前記出力（82）に供給されるCAMからの上位ビット
群だけを抽出する手段を含む、請求項１に記載の装置。 - 【請求項５】さらに、前記CAM（80）内に、CAMの入力
（84）に印加された情報と一致する情報がない場合に、
ソフトウェアによって前記プロトコル・ヘッダを処理す
る手段を含む、請求項１に記載の装置。 - 【請求項６】前記接続識別子が、前記データ・ストリー
ムの処理に必要なすべての情報を提供する経路指定テー
ブル（125）を指すポインタとして使用されることを特
徴とする、請求項１に記載の装置。 - 【請求項７】前記第１プロトコルが、インターネット・
プロトコル（IP）またはST−IIマルチメディア・プロト
コルであることを特徴とする、請求項１に記載の装置。 - 【請求項８】マルチメディア・プロトコル・アダプタの
一部か、マルチプロトコル・ルータ（124）、集線装
置、ブリッジまたは交換機の一部か、プロトコル・アナ
ライザの一部である、請求項１に記載の装置。 - 【請求項９】データ・ストリームの処理のため、前記デ
ータ・ストリームのプロトコル・ヘッダ（20）から抽出
される、必要な前記接続識別子を供給する方法におい
て、前記プロトコル・ヘッダ（20）が、第１プロトコル
のフィールドと、前記第１プロトコル上で構築される第
２プロトコルのフィールドと（22ないし24、25ないし2
7）を含み、 ａ）前記第１プロトコルのプロトコル・タイプ情報を読
み取るために前記プロトコル・ヘッダ（20）を走査する
ステップと、 ｂ）前記データ・ストリームの処理に関連するプロトコ
ル情報を、前記プロトコル・ヘッダ（20）の第１プロト
コルのフィールドおよび第２プロトコルのフィールド
（22ないし24、25ないし27）内で読み取るステップと、 ｃ）連想記憶（CAM80）の入力（84）に、ステップａ）
およびｂ）で読み取られた前記プロトコル・タイプ情報
および前記プロトコル情報を印加するステップと、 ｄ）前記CAM（80）に記憶された情報と前記プロトコル
・タイプ情報および前記プロトコル情報を比較し、前記
CAM（80）の出力（82）に同一情報を含むCAMアドレスを
提供するステップと、 ｅ）CAM（80）の前記出力（82）に供給されたCAMアドレ
スを連結することによって前記接続識別子を生成するス
テップと を含む方法。 - 【請求項１０】前記プロトコル・ヘッダが、前記第２プ
ロトコル上で構築される第３プロトコルのフィールドを
含み、前記方法が、 ｆ）前記第３プロトコルの、前記データ・ストリームの
処理に関連するプロトコル情報を読み取るステップと、 ｇ）請求項９のステップｄ）を実行するため、ステップ
ｆ）で読み取られた前記プロトコル情報を、CAM（80）
の前記入力（84）に印加するステップと を含む、請求項９に記載の方法。 - 【請求項１１】前記第３プロトコルおよびそれ以降のプ
ロトコルの上で構築されるさらなるプロトコルのそれぞ
れについて、諸ステップが同様の形で実行されることを
特徴とする、請求項10に記載の方法。 - 【請求項１２】ｈ）前記プロトコル情報のそれぞれを、
好ましくはワード単位で、前記プロトコル情報と連結し
て、１つの連結された情報ワードを形成するステップ
と、 ｉ）前記連結された情報ワードを前記CAM（80）の入力
（84）に印加して、請求項９のステップｄ）を実行する
ステップと を含む、請求項９に記載の方法。 - 【請求項１３】ｊ）前記プロトコル・ヘッダからプロト
コル情報を読み取るたびに、レベル番号を増分するステ
ップと、 ｋ）請求項９のステップｄ）を実行する前に、ステップ
ｈ）の前記連結された情報ワードの先頭に、前記レベル
番号を挿入するステップと を含む、請求項12に記載の方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6520550A JP2732549B2 (ja) | 1993-03-20 | 1993-03-20 | プロトコル・ヘッダから接続情報を抽出するための方法および装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP6520550A JP2732549B2 (ja) | 1993-03-20 | 1993-03-20 | プロトコル・ヘッダから接続情報を抽出するための方法および装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08503349A JPH08503349A (ja) | 1996-04-09 |
| JP2732549B2 true JP2732549B2 (ja) | 1998-03-30 |
Family
ID=18527614
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP6520550A Expired - Fee Related JP2732549B2 (ja) | 1993-03-20 | 1993-03-20 | プロトコル・ヘッダから接続情報を抽出するための方法および装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2732549B2 (ja) |
-
1993
- 1993-03-20 JP JP6520550A patent/JP2732549B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH08503349A (ja) | 1996-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0689748B1 (en) | Method and apparatus for extracting connection information from protocol headers | |
| US7218632B1 (en) | Packet processing engine architecture | |
| US5978378A (en) | Method and apparatus for VLAN support | |
| JP4999957B2 (ja) | ネットワークスイッチング装置におけるコンテントベースの転送／フィルタリング方法 | |
| US6424650B1 (en) | Network address filter device | |
| US6678269B1 (en) | Network switching device with disparate database formats | |
| US6650642B1 (en) | Network relaying apparatus and network relaying method capable of high-speed routing and packet transfer | |
| US7835375B2 (en) | Method and apparatus for providing multi-protocol, multi-stage, real-time frame classification | |
| US7379454B2 (en) | Packet routing apparatus and routing controller | |
| JP3574184B2 (ja) | データ構造に含まれる情報の分析のための方法および装置 | |
| US5406555A (en) | Charging in LAN for only packets used by subscribers | |
| KR20060024337A (ko) | 사용자 ｍａｃ 프레임 전송방법, 에지 브리지 및 프로그램 | |
| JPH09505697A (ja) | セル切換通信制御装置における柔軟な宛先アドレスマッピング機構 | |
| US7269661B2 (en) | Method using receive and transmit protocol aware logic modules for confirming checksum values stored in network packet | |
| US6658003B1 (en) | Network relaying apparatus and network relaying method capable of high-speed flow detection | |
| CN108075949B (zh) | 一种vpws环境实现rfc2544的方法及设备 | |
| CN1736076A (zh) | 数据包分类的装置及方法 | |
| US7145911B2 (en) | Method and system for parallel hash transformation for an address input | |
| JP2732549B2 (ja) | プロトコル・ヘッダから接続情報を抽出するための方法および装置 | |
| JP2003069640A (ja) | イーサネット（登録商標）上における明示的マルチキャストサービス方法及び装置 | |
| US6639915B1 (en) | Method and apparatus for transmission of voice data in a network structure | |
| US6671277B1 (en) | Network relaying apparatus and network relaying method capable of high quality transfer of packets under stable service quality control | |
| CA2158013A1 (en) | Method and apparatus for extracting connection information from protocol headers | |
| JP2000049791A (ja) | Ｉｐデータグラムカプセル化方法及びｉｐ処理装置 | |
| JP3028414B1 (ja) | パケットフィルタ回路 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |