(57)【特許請求の範囲】
【請求項１】
ネットワークから受信したパケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報を選択的に分離するためのシステムであって、
前記パケットを受信し、そこから、前記パケットに関して使用したサブプロトコルを識別するサブプロトコル検出装置と、
前記サブプロトコル検出装置に接続していて、前記サブプロトコルの識別に基づいて、前記パケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報の少なくとも一部を選択的に分離して、前記パケットの全体のサイズを小さくするヘッダ分離装置とを備えるシステム。
【請求項２】
請求項１に記載のシステムにおいて、前記ヘッダ分離装置が、前記パケットが正常であると判断された場合だけ、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を分離するシステム。
【請求項３】
請求項１に記載のシステムにおいて、前記ヘッダ分離装置が、前記サブプロトコルの前記識別に基づいて、前記パケットからそのエラー・チェック・ビットを含む前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報全体を分離するシステム。
【請求項４】
請求項１に記載のシステムにおいて、前記ヘッダ分離装置が、前記サブプロトコルの前記識別とは無関係に、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を保持するために、選択的にオーバライドすることができるシステム。
【請求項５】
請求項１に記載のシステムにおいて、前記サブプロトコル検出装置および前記ヘッダ分離装置が、多重パケット受信機の一つのチャネルに対応するシステム。
【請求項６】
請求項１に記載のシステムにおいて、前記ヘッダ分離装置が、ペイロード制御レジスタに基づいて、前記パケットから前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を、別の方法により、分離するシステム。
【請求項７】
請求項１に記載のシステムにおいて、前記システムが、デジタル・ロジックおよび集積回路の一部として実行されるシステム。
【請求項８】
ネットワークから受信したパケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報を選択的に分離するための方法であって、前記パケットに関して使用したサブプロトコルを識別するステップと、
前記サブプロトコルの識別に基づいて、前記パケットから前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の少なくとも一部を選択的に分離して、前記パケットの全体のサイズを小さくするステップとを含む方法。
【請求項９】
請求項８に記載の方法において、前記分離が、前記パケットが正常であると判断された場合だけ、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を分離するステップを含む方法。
【請求項１０】
請求項８に記載の方法において、前記分離が、前記サブプロトコルの前記識別に基づいて、前記パケットからそのエラー・チェック・ビットを含む前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報全体を分離するステップを含む方法。
【請求項１１】
請求項８に記載の方法において、さらに、前記サブプロトコルの前記識別とは無関係に、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を保持するために、前記分離ステップを選択的に飛び越すステップを含む方法。
【請求項１２】
請求項８に記載の方法において、前記識別および前記分離が、多重パケット受信機の一つのチャネルに関して行われる方法。
【請求項１３】
請求項８に記載の方法において、前記分離が、ペイロード制御レジスタに基づいて、前記パケットから前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を、別の方法により、分離するステップを含む方法。
【請求項１４】
請求項８に記載の方法において、前記方法が、集積回路の一部であるデジタル・ロジック内で実行される方法。
【請求項１５】
ネットワーク・アダプタであって、
バス・インターフェースと、
ネットワーク・インターフェースと、
前記バス・インターフェースと、前記ネットワーク・インターフェースとの間に設置されていて、前記バス・インターフェースと、前記ネットワーク・インターフェースとの間で通信されるパケットを受信し、記憶するバッファと、
前記バッファに接続していて、前記アダプタを通して前記パケットの通信を管理し、データ・レジスタと、前記パケットを前記バス・インターフェースから前記ネットワーク・インターフェースへ運ぶパケット伝送経路と、前記パケットを前記ネットワーク・インターフェースから前記バス・インターフェースに運び、前記パケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報を選択的に分離するためのシステムを有するパケット受信経路とを有するプロセッサ制御データ・エンジンとを備え、
該プロセッサ制御データ・エンジンが、
前記パケットを受信し、そこから、前記パケットに関して使用したサブプロトコルを識別するサブプロトコル検出装置と、
前記サブプロトコル検出装置に接続していて、前記サブプロトコルの識別に基づいて、前記パケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報の少なくとも一部を選択的に分離して、前記パケットの全体のサイズを小さくするヘッダ分離装置とを含む、ネットワーク・アダプタ。
【請求項１６】
請求項１５に記載のアダプタにおいて、前記ヘッダ分離装置が、前記パケットが正常であると判断された場合だけ、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を分離するアダプタ。
【請求項１７】
請求項１５に記載のアダプタにおいて、前記ヘッダ分離装置が、前記サブプロトコルの前記識別に基づいて、前記パケットから、そのエラー・チェック・ビットを含む前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報全体を分離するアダプタ。
【請求項１８】
請求項１５に記載のアダプタにおいて、前記ヘッダ分離装置が、前記サブプロトコルの前記識別とは無関係に、前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を保持するために、選択的にオーバライドすることができるアダプタ。
【請求項１９】
請求項１５に記載のアダプタにおいて、前記サブプロトコル検出装置および前記ヘッダ分離装置が、多重パケット受信機の一つのチャネルに対応するアダプタ。
【請求項２０】
請求項１５に記載のアダプタにおいて、前記ヘッダ分離装置が、ペイロード制御レジスタに基づいて、前記パケットから前記ポイント・ツー・ポイント・プロトコル・ヘッダ情報の前記少なくとも一部を、別の方法により分離するアダプタ。
【請求項２１】
請求項１５に記載のアダプタにおいて、前記システムが、デジタル・ロジックおよび集積回路の一部として実行されるアダプタ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、概して、ネットワーク・プロトコルおよびアダプタに関し、特にネットワークから受信したパケットからポイント・ツー・ポイント・プロトコル（ＰＰＰ）ヘッダ情報を選択的に分離するためのシステムおよび方法に関する。
【０００２】
【従来の技術、及び、発明が解決しようとする課題】
＜関連出願への相互参照＞
本正規出願は、１９９９年７月１日付の、本出願と共通に譲渡された「ＴＤＡＴ０４２Ｇ５  改訂２．０  ＰＰＰ分離設計」という名称の仮出願第６０／１４２，０２１号に基づくものであり、その優先権を主張する。上記出願は、引用によって本明細書の記載に援用する。
【０００３】
ネットワーク・アダプタは、コンピュータ・ネットワークと、このネットワーク内に位置する種々の個人コンピュータ・システム（「ステーション」）との間で、インターフェースとして機能する。ネットワーク・アダプタは、多くの場合、コンピュータ・システム自身のシャーシ内に位置する、取り外すことができるカードの形をしている。
【０００４】
ネットワーク・アダプタは、ネットワークを通してデータを伝送する物理搬送媒体に接続するネットワーク・インターフェースを持つ。今日の共通の物理搬送媒体としては、アナログ電話線（この場合には、ネットワーク・アダプタは、「モデム」と呼ばれる）、デジタル総合サービス網（「ＩＳＤＮ］）ライン、高水準データリンク制御（「ＨＤＬＣ］）ビット直列ライン、国際規格（「ＩＳＯ」）Ｘ．２５信号法ライン、イーサネット（登録商標）ライン、および同期光通信ネットワーク／同期式デジタル階層（「ＳＯＮＥＴ／ＳＤＨ」）光ファイバ等がある。
【０００５】
ネットワーク・アダプタは、また、コンピュータ・システムのバスに接続しているバス・インターフェースを有する。多くのバス規格が、現在使用されている。しかし、もっと一般的に使用されているものとしては、周辺カード相互接続（「ＰＣＩ」）、小型コンピュータ・システム・インターフェース（「ＳＣＳＩ」）およびユニバーサル・シリアル・バス（「ＵＳＢ」）等がある。
【０００６】
ネットワーク・インターフェースと、バス・インターフェースとの間には、バッファが設置されている。希にではあるが、コンピュータ・ネットワークと、コンピュータ・システムは、同じ速度で通信することができる。バッファは、ネットワーク・インターフェースと、バス・インターフェースとの間で、データが移動する際に、データを一時的に保持する。その目的は、両者の中の低速の方が、両者の中の高速の方に追いつくまで、高速の方が、そのデータを確実に伝送することができるようにすることである。
【０００７】
最後に、ネットワーク・アダプタは、ネットワーク・インターフェース、バッファおよびバス・インターフェースとの間のデータの流れを制御するプロセッサを含む。このプロセッサは、さらに、バッファ内でデータを操作するが、その目的は、データをその次の宛先に送信するために、確実に正しい形にすることである。
【０００８】
コンピュータ・ネットワークの場合には、（以後、わかりやすくするために「ペイロード」と呼ぶ）データの「形式」が、その内部で、ペイロードがカプセル内に収容されるプロトコル・スタックの用語で定義される。スタック形成とは、コンピュータ・ネットワークを通してペイロードを送信するために実行しなければならない種々のタスクを、スタックを構成する異なる層の間に広げることができるようにする組織上の概念である。オープン・システム相互接続（「ＯＳＩ」）基準モデルは、理想的な７層からなるプロトコル・スタックを規定している。このモデルは、（１）物理層（イーサネット（登録商標）のようなペイロードを伝送する実際の物理的媒体）、（２）データ・リンク層（物理的媒体を通して送信されている間に、ペイロードが、絶対に、意味のないものに変化しないように責任を持つ）、（３）ネットワーク層（確実に、ペイロードが、コンピュータ・ネットワークを通してソースから宛先に正しく転送されることに責任を持つ）、（４）搬送層（その宛先で、再構成できるように、ペイロードを元の状態に維持する）、（５）セッション層（二つのコンピュータ・システムの間での、同じリソースの競合を管理するために、ほとんどの場合、ローカル・エリア・ネットワーク内で使用される）、（６）提示層（ペイロードの提示方法を制御する）、（７）アプリケーション層（ファイル転送、電子メールおよびハイパーテキスト、ワールド・ワイド・ウエブのステープルのような高いレベルのタスクを処理する）からなる。
【０００９】
ポイント・ツー・ポイント・プロトコル（ＰＰＰ）は、インターネットにダイヤルアップ・アクセスを行うために、広く使用されているデータ・リンク層プロトコル規格であり、電気および電子エンジニア（「ＩＥＥＥ」）協会、コメント要求（「ＲＦＣ」）１６６１、１６６２に定義されていて、ＲＦＣ１５９８（Ｘ．２５）、１６１８（ＩＳＤＮ）および１６１９（ＳＯＮＥＴ／ＳＤＨ）内の特定の物理層に適用される。これらすべてのＲＦＣは、引用によって本明細書の記載に援用する。ＰＰＰは、ペイロードを受渡しできるサイズのパケットに分割する、モデム、ＨＤＬＤビット直列ライン、ＳＯＮＥＴ／ＳＤＨ、および他の物理層上で使用するのに適している多重プロトコル・フレーム形成機構である。ビット指向のＨＤＬＣとは異なり、ＰＰＰは文字指向である。
【００１０】
プロトコルは、情報をペイロードに「添付」し、コンピュータ・ネットワークを通して送信し、宛先でペイロードから「分離」することを要求する。そのため、ペイロードの通信に必ずオーバーヘッドが追加されるし、通信速度がコンピュータ・ネットワークの最大の関心事であるので、ペイロードの完全性を維持しながら、プロトコルのオーバーヘッドを最も少なくすることが、プロトコル設計オーバーヘッド管理における一番重要な目標である。
【００１１】
この目標は、さらに、ＰＰＰを最適化することができるネットワーク・アダプタの分野においても同様に重要なことである。従って、この技術分野では、ＰＰＰによるコンピュータ・ネットワークへのオーバーヘッドを軽減するための方法が求められている。
【００１２】
【課題を解決するための手段】
本発明は、サブプロトコル（より高度の層のサブプロトコル）の識別により、ＰＰＰ情報を分離し、それにより、オーバーヘッドから除去することを認識する。この認識に応じて、本発明は、（コンピュータ・ネットワークのような）ネットワークから受信したパケットから、ＰＰＰヘッダ情報を選択的に分離するためのシステムおよび方法、並びに、上記システムまたは方法を使用しているネットワーク・アダプタを提供する。ある実施形態の場合には、上記システムは、（１）パケットを受信し、そのパケットから、そのパケットに対して使用したサブプロトコルを識別するサブプロトコル検出装置、（２）上記サブプロトコル検出装置に接続していて、サブプロトコルの識別に基づいて、パケットから、ＰＰＰヘッダ情報の少なくとも一部を分離し、そうすることにより、パケット全体のサイズを小さくするヘッダ分離装置を含む。
【００１３】
それ故、本発明は、パケット内のサブプロトコルが、パケットを、その宛先に間違いなく送信することができるだけの十分な情報を含んでいる場合に、ＰＰＰ情報を分離する広義の概念を紹介する。本発明は、本質的な有用性を持つ。何故なら、上記状況において、ＰＰＰ情報が過剰になり、そうでない場合には、ペイロードを搬送するのに使用することができる帯域幅を全部使用するからである。
【００１４】
本発明のある実施形態の場合には、パケットが正常であると判断した場合には、ヘッダ分離装置は、ＰＰＰヘッダ情報の少なくとも一部を分離する。ＰＰＰ情報それ自身は、パケット全体が正常であるか、または異常であるかを判断するために分析することができる。
【００１５】
本発明のある実施形態の場合には、ヘッダ分離装置は、サブプロトコルの識別に基づいて、パケットからそのエラー・チェック・ビットを含むＰＰＰヘッダ情報全体を分離する。このことは、図に示し、説明する実施形態に適用されるもので、本発明の広い範囲に適用されるものではない。
【００１６】
本発明のある実施形態の場合には、ヘッダ分離装置は、サブプロトコルの識別とは無関係に、ＰＰＰヘッダ情報の少なくとも一部を保持するために、選択的にオーバーライドすることができる。本発明の場合には必要ないけれども、この機能により逆方向互換性を実行することができる。
【００１７】
本発明のある実施形態の場合には、サブプロトコル検出装置およびヘッダ分離装置は、多重チャネルパケット受信機の一つのチャネルに対応する。本発明の一つの実施形態に過ぎないけれども、これから図示し、説明する実施形態は、四つのチャネルを持ち、その各チャネルは、これらのチャネルにより送られるパケットからＰＰＰヘッダ情報を選択的に分離するための独立のシステムを持つ。
【００１８】
本発明のある実施形態の場合には、ヘッダ分離装置は、ペイロード制御レジスタに基づいて、パケットから、別の方法で、ＰＰＰヘッダ情報の少なくとも一部を分離する。ある状況の場合には、ペイロード制御レジスタは、ヘッダ分離を制御しなければならない。そのような場合、上記ペイロード制御レジスタに任せたたほうが有利な場合がある。
【００１９】
本発明のある実施形態の場合には、システムは、デジタル・ロジックに集積回路の一部として埋設される。しかし、当業者であれば、本発明の原理は、デジタルまたは集積回路に制限されるものではなく、任意のタイプのソフトウェアまたはハードウェアでも実行することができることを理解することができるだろう。
【００２０】
今まで、本発明の好適なそしていくつかの機能を概略説明してきたが、当業者であれば、以下の詳細な説明をよりよく理解することができるだろう。本発明の特許請求の範囲の主題である、本発明の他の機能について以下に説明する。当業者であれば、開示のコンセプトおよび特定の実施形態を、本発明の同じ目的を達成するために、他の構造体を設計し、修正するためのベースとして、容易に使用することができることを理解されたい。当業者であれば、上記の同等の構造体も、広義に解釈すれば、本発明の精神および範囲内に含まれることを理解されたい。
【００２１】
【発明の実施の形態】
本発明をさらによく理解してもらうために、添付の図面を参照しながら本発明について以下に説明する。
【００２２】
最初に、図１について説明すると、この図は、本発明のシステムまたは方法を内蔵することができる、全体を参照番号１００で示すネットワーク・アダプタの非常に簡単なブロック図である。
【００２３】
図に示すように、アダプタ１００は、それによりアダプタ１００を、（本発明の環境である）特定のコンピュータ・システム１２０のバスに接続することができるバス・インターフェース１１０を含む。この図の場合には、コンピュータ・システム１２０は、パソコン（ＰＣ）であり、アダプタ１００は、そのＰＣＩバス１２５に接続しているが、本発明は、特定のタイプ、アーキテクチャまたはクラスのコンピュータ・システム１２０またはバス１２５に限定されるものではない。さらに、コンピュータ・システム１２０は、クライアントまたはサーバとして動作することができるが、必ずしもそうする必要はない。コンピュータ・システム１２０としては、ルータ、ゲートウェイ、またはコンピュータ・ネットワークに有利に接続することができる任意の他のシステムを使用することができる。もちろん、本発明は、コンピュータ・ネットワークに限定されない。任意のネットワークは、本発明の原理を実行するのに適している環境を形成することができる。
【００２４】
図に示すように、アダプタ１００は、さらに、それによりアダプタ１００が、（本発明の環境である）コンピュータ・ネットワーク１４０の物理搬送媒体に接続することができるネットワーク・インターフェース１３０を含む。図に示すように、コンピュータ・ネットワーク１４０は、インターネットであり、アダプタ１００は、ＳＯＮＥＴ／ＳＤＨの物理搬送媒体１４５に接続しているが、本発明は、特定のタイプまたはアーキテクチャのコンピュータ・ネットワーク１４０、または物理搬送媒体１４５に限定されない。アダプタ１００は、四つの論理ポート（図示せず）を通して、コンピュータ・ネットワーク１４０と通信するが、本発明はそれに限定されない。
【００２５】
アダプタ１００は、バス・インターフェース１１０と、ネットワーク・インターフェース１３０との間に設置されているバッファ１５０を含む。バッファ１５０は、データがバス・インターフェース１１０と、ネットワーク・インターフェース１３０との間で伝送されると、（パッケージの形の）データを受信し、一時的に保持（記憶）する。その目的は、両者の中の低速の方が、両者の中の高速の方に追いつくまで、確実に、両者の中の高速の方がデータを伝送することができるようにするためである。バッファ１５０は、通常、アダプタ１００が動作するのに必要な速度、および恐らく、アダプタ１００がサポートするチャネルの数により一つまたはそれ以上の読出ポート、および一つまたはそれ以上の書込みポートを持つランダム・アクセス・メモリ（ＲＡＭ）の形をしている。
【００２６】
アダプタ１００は、また、プロセッサ１６０を含む。プロセッサ１６０は、バス・インターフェース１１０、バッファ１５０とネットワーク・インターフェース１３０との間のデータの流れを制御する。プロセッサ１６０は、さらに、バッファ１５０内でデータを操作するが、その目的は、データをその次の宛先に送信するために、確実に正しい形にすることである。図に示すように、バッファ１５０は、データ・エンジン１７０に接続している。
【００２７】
図２について説明すると、この図は、図１のデータ・エンジン１７０のブロック図である。データ・エンジン１７０は、バッファ１５０およびプロセッサ１６０のハイブリッド拡張部と見なすことができる。データ・エンジン１７０は、（以下に説明するように、制御データを含むことができる、高速の、特殊用途のメモリである）レジスタ２１０、およびデータ・エンジン１７０を通して移動するペイロードへプロトコル情報を導入し、ペイロードからプロトコル情報を分離するためのパイプラインを含む。図２に示すように、これらのパイプラインは、それぞれ、送信パイプライン２２０、および受信パイプライン２３０である。送信パイプライン２２０は、ネットワーク・インターフェース１３０に送信されるバス・インターフェース１１０から受信したパケットを処理する（図１に両方を示す）。送信パイプライン２２０の構造および機能は、本発明の目的のための従来のもであるとみなすことができる。しかし、本発明は、従来の送信パイプラインに限定されない。
【００２８】
受信パイプライン２３０は、バス・インターフェース１１０に送信されるネットワーク・インターフェース１３０から受信したパケットを処理する。受信パイプラインは、送信パイプライン２２０より詳細に図示されている。パケットの流れの方向に移動しながら、ＰＰＰ分離ブロック２３１は、最初、パケットを受信し、処理する。本発明のシステムおよび方法は、都合のよいことに、ＰＰＰ分離ブロック２３１内に位置しているか、設置されている。
【００２９】
次に、巡回冗長検査（「ＣＲＣ」）モジュール２３２が、ペイロードがエラーを含んでいるかいないかを判断するために、ＣＲＣコードをチェックする。
【００３０】
次に、プリアンスクランブラ２３３が、アンスクランブルおよびフレーム形成を行う目的で、パケットを形成するために、周知のＩＳＯＸ．４３規格に従って動作する。この時点で、コンピュータ・システム（図１の１２０）で使用しているプロトコルに従って、別のフレーム形成装置が使用される。図に示すのは、ルーセント社の簡単なデータ・リンク（ＳＤＬフレーム形成装置２３４）、非同期転送モード（ＡＴＭフレーム形成装置２３５）およびＨＤＬＣ（ＨＤＬＣフレーム形成装置２３６）用の独立フレーム形成装置である。
【００３１】
次に、ポストアンスクランブラ２３７が、適当なフレーム形成により、パケットをフォーマットする。ラウンドロビン・バッファ２３８が、パケットがコンピュータ・システム（図１の１２０）に同期できるまで、パケットを一時的に保持する。同期は、クロック・クロッサ２３９内で行われる。最後に、受信シーケンサ２４０が、パケットをコンピュータ・システムのバス（図１の１２５）上に置く。
【００３２】
図１および図２のデータ・エンジン１７０は、好適には、集積回路にデジタルの形で実行することが好ましい。しかし、関連技術の当業者であれば、データ・エンジン１７０を、特定のアプリケーションに適している任意の形で実施することができることを理解することができるだろう。
【００３３】
図３について説明すると、この図は、ＲＦＣ１６６１および１６６２に規定されているＰＰＰ規格に従ってフォーマットされたパケット（または「フレーム」）の図面である。全体を参照番号３００で示すＰＰＰパケットは、フラグ・フィールド３１０（４バイト）、アドレス・フィールド３２０（４バイト）、制御フィールド３３０（４バイト）、プロトコル・フィールド３４０（１または２バイト）、ペイロード・フィールド３５０（任意の長さ、しかし、多くの場合、１５００バイト）、およびチェックサム・フィールド３６０（多くの場合、２バイト、しかし、場合によっては４バイト）を含む。
【００３４】
フラグ・フィールド３１０は、単に、パケット３００の頭の部分を示す。アドレス・フィールド３２０は、そのパケットの宛先ステーションのアドレスを示す。ＰＰＰはデータ・リンク層プロトコルであり、宛先ステーションの識別とは無関係であるので、アドレス・フィールド３２０は、コンピュータ・ネットワーク上のすべてのステーションがパケット３００をことを示す数値を含む。
【００３５】
制御フィールド３３０は、パケット３００の数を示す。ＰＰＰはデータ・リンク層プロトコルであり、信頼性が高くなくてもよいので、制御フィールド３３０は、数えられていないパケット３００の示す数値を含む。
【００３６】
プロトコル・フィールド３４０は、（リンク制御プロトコル、すなわち、「ＬＣＰ」；ネットウエア制御プロトコル、すなわち、「ＮＣＰ」；インターネット・プロトコル、すなわち、「ＩＰ」；ノベルのインターネットワーク・パケット交換、すなわち、「ＩＰＸ」；またはアップルトーク（登録商標）のような）パケット３００に対して使用されるプロトコルの識別を含む。関連技術の当業者なら気がつくように、各プロトコルは、それに関連し、特定のプロトコルと一緒に使用することができる、より高度のレベルのプロトコルに関連する（実施形態に示す）三つのサブプロトコルを持つ。各サブプロトコルは、プロトコル・フィールド３４０に示すそれ自身のコードを持つ。例えば、プロトコルがＩＰである場合には、サブプロトコルとしては、（０ｘ００２１のコードを持つ）ＩＰデータ、（０ｘ８０２１のコードを持つ）ＩＰネットワーク、または（０ｘＣ０２１のコードを持つ）ＩＰリンク層制御を使用することができる。
【００３７】
ペイロード・フィールド３５０は、パケット３００が運ぶペイロードを含むが、それが含むことができるものに限定されない。最後に、チェックサム・フィールド３６０は、識別するために、そしてできればその中に含まれているエラーを修正するために、パケット３００の残りの部分について使用することができるエラー・チェック・ビットを含む。
【００３８】
図４について説明すると、この図は、図２のＰＰＰ分離ブロック２３１のより詳細なブロック図である。この場合も、また、パケットの流れの方向に進むに従って、入力ラッチ４１０は、クロック信号４１１の立ち上がりの縁部上で、受信した文字をラッチする。第一のロジック回路４２０は、上記文字を直列に受信し、フラグ・フィールド（図３の３１０）を識別することにより、（図３のパケット３００のような）所与のＰＰＰパケットのスタート部分を発見する。
【００３９】
第一のロジック回路４２０によりトリガされると、第二のロジック回路４３０が、パケットのＰＰＰヘッダが、圧縮されていない形で、または圧縮された形で表現されているかどうかを判断する。全アドレス、制御フィールドおよびプロトコル・フィールドを含むＰＰＰヘッダは、圧縮されていないと見なされる。（プロトコル・フィールドだけというように）三つすべてのフィールドより少ないフィールドを含むＰＰＰヘッダは、圧縮されていると見なされる。
【００４０】
本発明のサブプロトコル検出装置を含んでいると見なすことができる第三のロジック回路４４０は、パケットのどの部分を分離したらよいのかを、また、サブプロトコルの識別に基づいて、どの部分を送ったら（送信したら）よいのかを判断する。第三のロジック回路４４０が送ることを決定した文字は、本発明のヘッダ分離装置を含んでいると見なすことができる第四ロジック回路４５０で処理され、ＰＰＰ分離ブロック２３１から送信するために、出力ラッチ４６０に送られる。メモリ４７０は、レジスタ内に、前の状態、前のデータ、および前のペイロード・マーカのような記録を保持する。出力ラッチ４６０およびメモリ４７０は、両方とも、クロック信号４１１の立ち上がり縁部上で動作する。
【００４１】
図６について説明すると、この図は、本発明の原理により構成されたコンピュータ・ネットワークから受信した、（図３のパケット３００のような）パケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報を選択的に分離するための、全体を参照番号５００で示す方法のフローチャートである。
【００４２】
処理は、スタート・ブロック５１０でスタートする。このブロックにおいては、サブプロトコル検出装置により分析されるパケットが、上記検出装置により受信される。サブプロトコル検出装置は、パケットのプロトコル・フィールドを読むことにより、ステップ５２０において、パケットについて使用したサブプロトコルを識別する。
【００４３】
この時点において、パケットからＰＰＰヘッダ情報の少なくとも一部を分離し、そうしたい場合には、チェックサム・フィールド内のエラー・チェック・ビットの少なくとも一部を分離するかどうかを決定しなければならない。従って、方法５００は、決定ステップ５３０で、さらに決定を続行し、このステップにおいて、パケットが正常であるかどうかを判断するために、チェックサム・フィールドを参照しながら、パケットを試験する。パケットが正常でないと判断された場合には、ペイロード制御レジスタの設定に基づいて、ＰＰＰパケット全体を放棄するか、パケットに異常とマークすることができる。
【００４４】
パケットが正常と判断された場合には（これがより普通の結果であるが）、判断ステップ５５０で処理が続行される。このステップにおいては、ヘッダ分離を行うことができるかどうかを判断するために、サブプロトコルの試験が行われる。上記試験を行うために、ステップ５２０で識別されたサブプロトコルは、図に示す実施形態の場合、記憶しているサブプロトコル・コードと比較される。特定の例の場合には、サブプロトコル値が、０ｘ００２１（ＩＰデータ）である場合には、（アドレス・フィールド、制御フィールドおよびプロトコル・フィールドを含む）ＰＰＰヘッダ情報、および（エラー・チェック・ビットを含む）チェックサム・フィールドを分離することができる。そうでない場合で、サブプロトコル値が０ｘ８０２１（ＩＰネットワーク）、または０ｘＣ０２１（ＩＰリンク層）である場合には、ＰＰＰヘッダ情報およびチェックサム・フィールドを保持し、分離してはならない。（何故なら、それらは、以降のネットワーク交渉、転送およびリンクの設定に役に立つからである。）
【００４５】
サブプロトコル・フィールドの数値が、ＰＰＰヘッダ情報およびチェックサム・フィールドを分離してはならないことを示している場合には、方法５００は、ステップ５４０の終わりの時点で、受信パイプライン（図２の２３０）内で、さらに処理を行うためにパケットを送信し、分離を行わないことを決定する。そうでない場合で、サブプロトコル・フィールドの数値が、ＰＰＰヘッダ情報およびチェックサム・フィールドを分離すべきであることを示している場合には、方法５００は、ステップ５６０へ進み、そこで、ＰＰＰヘッダ情報、およびチェックサム・フィールドが分離される。その後で、方法５００は、ステップ５４０の終わりの時点で、受信パイプライン（図２の２３０）内で、さらに処理を行うために、ＰＰＰヘッダ情報およびチェックサム・フィールドを分離しないで、パケットを送信することを決定する。それ故、上記パケットの全体のサイズが小さくなり、そのオーバーヘッドが小さくなり、コンピュータ・システム・バス（図１の１２５）の有効帯域幅が広くなる。
【００４６】
実際、ＰＰＰヘッダ情報が圧縮されていないで、プロトコル・フィールドの長さが２バイトであり、ペイロード・フィールドの長さが１５００バイトであり、チェックサム・フィールドの長さが２バイトであると仮定した場合、パケットのサイズは１％以上小さくなり、搬送の信頼性は低下しない。パケットがもっと小さなペイロードを含む場合には、サイズはもっと劇的に小さくなる。
【００４７】
図６について説明すると、この図は、全体を参照番号６００で表わす４チャネルＰＰＰ分離ブロック内でＰＰＰ情報の分離を制御するのに使用することができるレジスタのマップである。レジスタ６１０、６２０、６３０、６４０は、そこを通してデータ・エンジンがコンピュータ・ネットワーク（図１の１４０）と通信することができ、図２のレジスタ２１０の一部とすることができる四つの論理チャネルに対応する。
【００４８】
レジスタ６１０は、図に示すように、「ＰＰＰ−ｒｘ−ｈｄｒ−ｓｔｒｉｐｏｆｆ０」という名前がつけられていて、論理チャネル０に対応し、０ｘ００００のリセット・デフォールト値を持つ。レジスタ６２０は、図に示すように、「ＰＰＰ−ｒｘ−ｈｄｒ−ｓｔｒｉｐｏｆｆ１」という名前がつけられていて、論理チャネル１に対応し、０ｘ００００のリセット・デフォールト値を持つ。レジスタ６３０は、図に示すように、「ＰＰＰ−ｒｘ−ｈｄｒ−ｓｔｒｉｐｏｆｆ２」という名前がつけられていて、論理チャネル２に対応し、０ｘ００００のリセット・デフォールトを持つ。レジスタ６４０は、図に示すように、「ＰＰＰ−ｒｘ−ｈｄｒ−ｓｔｒｉｐｏｆｆ３」という名前がつけられていて、論理チャネル３に対応し、０ｘ００００のリセット・デフォールト値を持つ。
【００４９】
各レジスタ６１０、６２０、６３０、６４０は、下記の方法で、分離（「剥奪」）を制御する働きをする。（図５の例のところで説明したように）、特定のサブプロトコルに遭遇した場合には、ＰＰＰヘッダ情報およびチェックサム・フィールドは分離される。そうでない場合には、分離されない。所与のレジスタ６１０、６２０、６３０、６４０が設定されていない場合には（０ｘ００００のリセット・デフォールト値を含んでいない場合には）、そのレジスタはオーバーライドされる。分離は、もはや、サブプロトコル識別に依存しないで、ＰＰＰヘッダ情報およびチェックサム・フィールドは、図示していないが、０に設定された場合には、ＰＰＰヘッダ情報およびチェックサム・フィールドを分離するように要求し、１に設定された場合には、ＰＰＰヘッダ情報およびチェックサム・フィールドを保持するように要求する、一つのビットを含む）ペイロード制御レジスタの内容に基づいて、選択的に分離されない。それ故、分離は行われないで、サブプロトコルの識別とは無関係に、ＰＰＰヘッダ情報の少なくとも一部およびチェックサム・フィールドが保持される。
【００５０】
今まで本発明を詳細に説明してきたが、当業者であれば、広義の本発明の精神および範囲から逸脱することなしに、本発明の範囲内で、種々の変更、置換えおよび改変を行うことができることを理解されたい。
【図面の簡単な説明】
【図１】本発明のシステムまたは方法を使用することができるネットワーク・アダプタおよびその周囲環境の極めて簡単なブロック図である。
【図２】図１のネットワーク・アダプタ内に設置することができ、本発明の原理に従って構成したコンピュータ・ネットワークから受信したパケットからＰＰＰヘッダ情報を選択的に分離するためのシステムを含むデータ・エンジンのブロック図である。
【図３】ＲＦＣ１６６１および１６６２に規定されているＰＰＰ規格によりフォーマットしたパケットの図面である。
【図４】図２のＰＰＰ分離ブロックの、より詳細なブロック図である。
【図５】本発明の原理により構成されたコンピュータ・ネットワークから受信したパケットからポイント・ツー・ポイント・プロトコル・ヘッダ情報を選択的に分離する方法のフローチャートである。
【図６】４チャネルＰＰＰ分離ブロック内でＰＰＰ情報の分離を制御するために使用することができるレジスタのマップである。
【図１】
0003605005.tif 000002
【図２】
0003605005.tif 000003
【図３】
0003605005.tif 000004
【図４】
0003605005.tif 000005
【図５】
0003605005.tif 000006
【図６】
0003605005.tif 000007