JP2013009406A - インターネットにアクセスする加入者への所望のサービス・ポリシーの提供 - Google Patents

Abstract

【課題】所望のサービス・ポリシーをそれぞれの加入者に提供することを可能にするインターネット・サービス・ノード（ＩＳＮ）を提供する。
【解決手段】ＩＳＮ２５０は、複数のプロセッサ・グループを備えることができ、それぞれの加入者は、プロセッサ・グループに割り当てられる。割り当てられたプロセッサ・グループは、加入者が所望するサービス・ポリシーを提供する処理規則で構成される。ポートは、受信データが転送される先の特定のプロセッサ・グループを決定することができる。連想記憶装置（ＣＡＭ）を用いて、受信データが割り当てられるべきプロセッサ・グループを迅速に決定することができる。ＩＳＮは、多数の加入者に効率的にサービスを行うことができ、アクセス・ネットワークのエッジ・デバイスとなる。
【選択図】図２

Description

本発明は、一般にデジタル通信ネットワークに関し、より具体的には、所望のサービス・ポリシーを、インターネットにアクセスする加入者に提供するためのシステムおよび方法に関する。

ユーザはしばしばローカル・システムを使用してリモート・システムにアクセスする。典型的なシナリオでは、ユーザがコンピュータ・システム（一般にすぐそばに位置する）を使用して、リモート・システム（一般に離れた位置にある）にアクセスすることができる。このアクセスは、関連技術分野で周知のように、ｗｅｂブラウジング、電子メールおよびデータベース・アクセスなど、いくつかの有用なアプリケーションの基礎としての機能を果たすことができる。

リモート・アクセス・デバイスは、しばしばローカル・システムおよびリモート・システムの間に存在する。リモート・アクセス・デバイスは一般に、ユーザから発信する物理接続（たとえば、大規模グループからの加入者回線および専用Ｔ１回線を介したダイアル接続）の集約装置（aggregator, または、集信装置ともいう）またはマルチプレクサとして動作する。リモート・アクセス・デバイスは一般に、ユーザ宛てのデジタル・データ・ビット（「ビット・グループ」）を送信し、ユーザから発信するビット・グループを受信するように動作する。インターネット・サービス・プロバイダ（ＩＳＰ）が提供するリモート・アクセス・サーバ（デジタルおよび／またはデジタル・モデムをサポートする）、地域交換キャリア（従来の競合ＬＥＣ）が提供するデジタル加入者線アクセス・マルチプレクサ（ＤＳＬＡＭ）、およびケーブル・テレビ・プロバイダが提供するケーブル・モデムが、このようなリモート・アクセス・デバイスの例である。

リモート・アクセス・デバイスは一般にデータ・スイッチとインタフェースを取り、これにより、選択的に各受信ビット・グループを、典型的にはビット・グループ内で符号化されたアドレス情報に基づいて、対応する宛先へ転送する。一般的な実施では、データ・スイッチがインターネット・プロトコル（ＩＰ）ルータに相当し、これは、ＩＰパケットの宛先アドレスを検査して、このＩＰパケットを送信する次のポイント（典型的には、別のルータまたはコンピュータ・システム）を決定する。

従来の実施では、ルータおよびリモート・アクセス・デバイスの組み合わせでは、ユーザの特殊な要件（または所望のサービス・ポリシー）についてサービスを行うことができないことがある。特定のサービス・ポリシー要件を有するユーザのグループ（単一ユーザの場合を含む）を、ここでの適用例では「加入者」と呼ぶ。加入者の特殊な要件の例を最初に言及する。次いで、ユーザの要件を満たす際の従来のルータおよびリモート・アクセス・デバイスの不十分さを記載する。

加入者は、いくつかの理由によって特殊な要件を有することがある。たとえば、ビジネスなど大規模なグループを含む加入者、およびそのビジネスは、一部またはすべてのユーザが使用する集約帯域幅（aggregate bandwidth）を制限することを望むことがある。いくつかの他のビジネスは、おそらくすべてではないが一部のユーザ向けに、異なる遠隔地の間で専用の安全リンクを有する仮想専用ネットワーク（ＶＰＮ）を望むことがある。さらに別のビジネスでは、あるタイプのアプリケーション（たとえばｗｅｂアクセスのみについて、ファイル転送またはテレネットではない）へ入ってくるアクセスを制限すること、または異なるアプリケーションについて異なるサービス・クラス（ＣＯＳ）を有することを望むことがある。

このような大規模グループの要件に加えて、個人ユーザ（加入者）が異なる要件を有することがある。これらの個人は、大規模ビジネスの一部または家庭内ユーザである可能性がある。ユーザは、あるピーク時間（たとえば、ネットワークが通常より輻輳するビジネス時間）中に５６Ｋｂｐｓのみの割り振りを望み、他の時間中にははるかに高い帯域幅の割り振りを望むことがある。ＩＳＰは、このようなユーザにより低い料金を課金することを望む場合がある。一般に、ユーザまたは加入者は、変動する特殊なサービス・ポリシー要件を有する可能性があることを理解されたい。

従来のデータ・スイッチおよびリモート・アクセス・デバイスの組み合わせでは、いくつかの理由によりこのような要件の組み合わせについてサービスを行うには不十分なことがある。たとえば、データ・スイッチは、優先順位付けおよびアクセス制御方式に制限があるにも関わらず、主として高速パケット転送デバイスとして実現されることがある。サービス品質（ＱｏＳ）およびトラフィック・パラメータに基づいてトラフィックの優先順位付けを切り替える非同期転送モード（ＡＴＭ）、およびいくつかのアプリケーションのみのデータをフィルタリングするＩＰルータが例示的な例である。

しかし、従来のデータ・スイッチおよび／またはリモート・アクセス・デバイス向けに選択されるアーキテクチャは、個人ユーザ／加入者向けのサービス・ポリシーのカスタマイズを提供することができない。たとえば、セルを転送するＡＴＭスイッチは、１つのセルを検査することにより、個人ユーザ間を区別する能力を有していない。より高い層で動作するデータ・スイッチ（たとえば、ＩＰルータ）は、通常は速度を獲得するために、パケットを一様に処理するよう設計されことがあり、したがってカスタマイズしたサービス・ポリシーを個人加入者へ提供するように設計されることができない。

上述のように、このようなカスタマイズがいくつかの例で必要になることがある。したがって、カスタマイズされた異なるサービス・ポリシーを異なる加入者に提供することが可能となる、柔軟性のあるアーキテクチャが必要とされている。

カスタマイズに加えて、一般に、多数の加入者にサービスを行うために、アーキテクチャを拡張できることが必要である。したがって、多数の加入者にサービスを行うために十分拡張することのできる、柔軟性のあるアーキテクチャも必要とされている。

本発明は、所望のサービス・ポリシーのセットを加入者のそれぞれに提供するインターネット・サービス・ノード（ＩＳＮ）に関する。ＩＳＮは特に、ＩＳＰおよびＬＥＣ（incumbentＬＥＣ（米国の既存のローカルキャリアで、ＬＬＥＣという）およびcompetitiveＬＥＣ（米国の新規のローカルキャリアでＣＬＥＣという）を共に含む）などのリモート・アクセス・プロバイダに有効である。アクセス・プロバイダはＩＳＮを、アクセス・ネットワークのエッジ・デバイスとして使用し、カスタマイズしたサービス・ポリシーを各加入者に提供することができる。

本発明によるＩＳＮは、複数のプロセッサ・グループを備えることができ、それぞれの加入者は、プロセッサ・グループに割り当てられる。プロセッサ・グループは、たとえばパケット・サービス・カードとして提供されることができる。プロセッサ・グループを、割り当てられた加入者のすべての処理規則で構成し、プロセッサ・グループが、割り当てられた加入者の任意の者が所望するカスタム・サービス・ポリシーを提供できるようにすることができる。

ＩＳＮのポートは、受信データが転送される先の特定のプロセッサ・グループを、受信データが関係する特定の加入者に基づいて決定するよう設計されることができる。その後、スイッチ・ファブリックが、このデータを、ポートの決定に基づいて、決定されたプロセッサ・グループに転送することができる。プロセッサ・グループは、加入者に関係する処理規則を適用して、加入者が所望するサービス・ポリシーを提供することができる。

それぞれのプロセッサ・グループは、加入者のサブセット（ＩＳＮによって供給される）のみにサービスを行うように設計される必要があるので、本発明は、大規模および／または複合ネットワーキング環境に応じて十分拡張されることができる。

本発明をアクセス・ネットワークのエッジで使用して、それぞれの加入者が所望するカスタム・サービス・ポリシーを提供することができる。一実施形態では、所望のサービス・ポリシーを、構成マネージャを使用して指定することができる。構成マネージャを、ＩＳＮに統合することができ、または異なるユニットとすることができる。

構成マネージャは、サービス・ポリシーを一組の処理規則に変換することができ、それぞれの処理規則は、分類子および関連するアクションを含む。分類子は一般に、データ・フロー、および、そのデータ・フローで転送される一組のデータ・ビットにアクションを適用することができる任意の条件を指定する。一般に、インターネット・プロトコル（ＩＰ）環境では、ソース／宛先ＩＰアドレス、ソース／宛先ポートおよびプロトコル・タイプ・フィールドが共に、特定のリモート・アクセス・アプリケーションをサポートするＩＰデータ・フローを定義する。

条件には、サービス・ポリシーを定義する特定の変数の合致を含めることができる。たとえば、サービス・ポリシーは、午前９時から午後５時の間に特定の方法でデータ・ビットが処理されるように指定することができ、この場合はＴＩＭＥが変数で、条件はＴＩＭＥ＝午前９時から午後５時である。別の例としては、加入者が使用する集約帯域幅がＴ１より大きい場合、加入者用のデータ・ビットにより低い優先順位を与えることができ、この場合はＢＡＮＤＷＩＤＴＨが変数で、条件がＢＡＮＤＷＩＤＴＨ＞Ｔ１である。

典型的には、大部分の処理規則を、指定したサービス・ポリシーから静的に構築することができる。しかし、いくつかの処理規則は、特定のイベントの発生に応じて動的にインスタンス化する必要がある。たとえば、ＩＰアドレスの割り振りのためにアクセス・ネットワークにダイヤルインして依拠する加入者のＩＰアドレスは、事前に入手可能でないことがある。したがって、ＩＳＮは、加入者がうまくダイヤルインした後でＩＰアドレスが割り振られたときに、処理規則を構築する。

このように、動的に処理規則をインスタンス化する本発明の能力によって、ＩＳＮは、アクセス・ネットワークに非同期アクセスすることがある加入者にサービスを行うことが可能となり、カスタマイズしたサービス・ポリシーをこのような加入者にも提供する能力をＩＳＮに提供する。また、非アクティブな（すなわち、ログオンしていない）加入者の処理規則でＩＳＮを構成する必要がないので、ＩＳＮを使用して多数の加入者にサービスを行うことができる。

処理規則の動的インスタンス化の別の例としては、ＲｅａｌＡｕｄｉｏタイプのアプリケーションにおいて、新規のＴＣＰ（またはＵＤＰ）接続がアプリケーション・セッションの途中で起動されることができ、この新規接続は、事前に決定されることのできないポート番号を有することがある。ポート番号は、典型的には制御フローを使用してネゴシエート（交渉）され、このことは関連技術分野では周知である。ＩＳＮは、制御フローのパケットを検査して必要な情報を求め、この情報が利用可能になった時点で新規の処理規則を構築するよう設計されることができる。

ＩＳＮの一実施形態は、複数のプロセッサ・グループを備え、それぞれのプロセッサ・グループは、複数のプロセッサを備える。加入者のすべてのフローを、プロセッサ・グループの１つによる初期処理に専用とすることができる。ＡＴＭセルをデータ・ビット・グループとして使用するとき、チャネル識別子を使用して、個々のプロセッサ・グループへの割り当てを行うことができる。グループ内の個々のプロセッサに、パケットを、負荷分散のために重み付けラウンド・ロビン方式で割り当てることができる。他のリソース割り振り方式または管理ポリシーを使用してもよい。

パケットを処理する（所望のサービスを提供するため）プロセッサを、アクセスおよびトランク・ポートとは分離した物理ユニットとして提供することができる。物理的な分離によって、プロセッサおよびポートの数を互いに関係なく変更（増加または減少）することが可能となる。その結果生じる柔軟性によって、本発明によるアーキテクチャを、多数の加入者をサポートするのに十分拡張することが可能となる。

上述のように、それぞれの加入者に関係するデータを、プロセッサ・グループに割り当てることができる。本発明の一態様では、データをプロセッサ・グループに割り当てるための効率的な手法を提供する。この割り当てを、ＡＴＭセルのシーケンスとして受信されたＩＰパケットを参照して記載する。

ＩＰパケットの転送先である特定のプロセッサ・グループの決定には、ＩＰパケットのヘッダ・データの検査が必要となることがある。このような状況とは、少なくとも、複数の加入者宛てのセル・データが、共有ＡＴＭ仮想接続上で受信されたときであり、これは、すべてのセルが同じＶＰＩ／ＶＣＩデータを含むことがあるためである。このシナリオは、一般に、加入者宛てのデータがトランク・ポートで受信されたときに直面する。このようなシナリオでは、ＩＰヘッダに位置するＩＰ宛先アドレスを検査することによって、プロセッサ・グループを決定することができる。

しかし、状況によっては、さらにＩＰパケット内部のデータを検査して加入者を決定する必要がある。たとえば、加入者に関係するデータを、Ｌ２ＴＰトンネルの特定のコール(call)で受信することができる。このような状況では、受信パケットのＵＤＰプロトコル・タイプ、Ｌ２ＴＰプロトコルを指定するＵＤＰポート番号、加入者に特有のトンネルＩＤおよびコールＩＤを検査する必要がある。

本発明では、それぞれのＣＡＭ位置の探索フィールド、マスク、および出力フィールドを有する連想記憶装置（ＣＡＭ）を使用することによって、このような検査を効率的に実行することが可能となる。それぞれの位置の探索フィールドは、加入者を識別するデータを格納するよう構成されることができ、出力フィールドは、所望のサービス・ポリシーを、ＣＡＭエントリに関係する加入者に提供することができるプロセッサまたはプロセッサのグループを識別するデータを格納するよう構成されることができる。

また、それぞれのＣＡＭ位置のマスクを、加入者を識別するビットを検査するよう設定することができる。例示として、複数の加入者のデータが共有ＡＴＭ接続上で受信されたとき、宛先ＩＰアドレスのみを検査するようＣＡＭ位置を設計することができる。他方では、ある加入者のデータがＬ２ＴＰトンネル上で受信されたとき、いくつかのより多くのバイトのデータを検査するよう、対応するＣＡＭ位置のマスク・フィールドを設定することができる。

こうして、ＩＰパケットの第１の（「ヘッダ」）セルが受信されたとき、ヘッダ・データが入力としてＣＡＭへ提供され、出力データは、適切なプロセッサを識別する。異なるＣＡＭエントリは異なるマスクを有することができるので、合致するエントリを１つのＣＡＭアクセスで発見することができる。合致するエントリの出力は、プロセッサ（グループ）識別子を表現することができ、またはプロセッサを決定するためのさらなるアクセスに導くことができる。

出力データがプロセッサ識別子を表さないとき、本明細書に記載する実施形態では、出力データは、ＩＰテーブルへの索引を含み、または、プロセッサ（グループ）識別子を決定するために追加のＣＡＭ探索が必要であることを示す。索引は、ＣＡＭエントリの数を最小にするのに有効である。索引を使用して、高速メモリ（たとえば、ＳＲＡＭ）に格納されたテーブルからエントリを選択することができ、抽出された値は、プロセッサ識別子またはプロセッサ・グループ識別子を表すことができる。例示として、適切なマスクを選択することによって、ＣＡＭエントリは、ＩＰアドレスの最初の３バイトのみを検査することができ、したがって２５５個のＩＰアドレスについて合致するエントリを提示することができる。高速メモリへの追加アクセスは、特定のプロセッサ識別子を提供することができる。

追加のＣＡＭ探索は一般に、ＣＡＭが、加入者を識別するために十分な数のビットを探索フィールド内に含んでいないときに必要となる。たとえば、加入者データがＬ２ＴＰトンネルを使用して受信されたとき、１つのＣＡＭ位置の探索フィールド内で使用可能であるビットよりも多くのビットを検査する必要がある場合がある。このような状況では、いくつかのビットを第１の探索で検査することができ、他のビットを後続の探索で検査することができる。すべての探索について合致が検出された場合にのみ、合致が発生したとみなされる。

本発明で記載する一実施形態では、２つの探索のみを必要とすることができる。しかし、追加の手法を必要とする実施形態は、本発明の範囲および精神内のものであると企図される。プロトコルのフォーマットおよび検査する必要のあるビット数に応じた探索を必要とすることができる。

上述の特徴は、ＩＳＮの一実施形態における、加入者からのセルを受信するアクセス・ポートまたは加入者宛てのセルを受信するトランク・ポートのいずれかで実施することができる。ＩＳＮは、複数のプロセッサ・グループを備えることができ、１つのグループは、典型的には、加入者に関係するＩＰパケットを処理するよう構成される。また、スイッチ・ファブリックは、受信セルのヘッダに基づいて、セルをグループの１つに割り当てるように設計されることができる。具体的には、ＶＰＩ／ＶＣＩフィールドが一意的にプロセッサ・グループを識別し、スイッチ・ファブリックによって受信されたセルを処理することができる。

したがって、本発明の割り当て論理が、ＣＡＭを使用することによってプロセッサ・グループを決定し、ＩＰパケットのすべてのセルのセル・ヘッダの一部（たとえばＶＰＩ）を、プロセッサ・グループ識別子で置換する。その後、スイッチ・ファブリックは、ＩＰパケットに関係するすべてのセルを、セル・ヘッダ（ＶＣＩ／ＶＰＩ）によって識別されたプロセッサ・グループに割り当てることができる。

したがって、本発明では、各加入者向けに異なる処理規則を提供し、この処理規則を使用して、加入者からの異なるデータ・フローで受信されたデータ・ビットを処理することによって、個々の加入者の所望のサービス・ポリシーを可能にする。

本発明によるＩＳＮは、それぞれの加入者をプロセッサ・グループに割り当てて、所望のサービス・ポリシーを提供することができるので、多数の加入者にサービスを行うために十分拡張することができる。

本発明は、ＩＳＮをエッジ・デバイスとして提供することができるので、特にリモート・アクセス・アプリケーションに適しており、このことにより、すべてのアプリケーション・データ・フローを制御して、単一のＩＳＮを使用するそれぞれの加入者に所望のサービス・ポリシーを提供することができる。

本発明は、所望のサービス・ポリシーをリモート・アクセス・サービス・プロバイダが実施することができるので（加入者の構内ではインテリジェント・デバイスは不要）、より容易な管理で、より低いコストの加入者デバイスを提供することができる。

本発明では、一加入者のサービス・ポリシーが一般に他の加入者に影響を及ぼすことがないので、複数の加入者が同じＩＳＮを共有することができるようになる。

本発明は特に、加入者のポリシーを、その加入者のために動的にＩＳＮへ追加することができるので、リモート・アクセス・ネットワークにダイヤルイン（または他の非同期機構）によってアクセスする加入者にサービスを行うリモート・アクセス・プロバイダに有用である。

本発明では、加入者の処理規則を動的にインスタンス化することができ、ＩＳＮを、アクティブな加入者のみの処理規則で構成する必要があるので、多数の加入者がサービスを受けることが可能となる。

本発明では、プロセッサの数を増加することができ、処理パケットの計算負荷をプロセッサ間で分散させることができるので、ＩＳＮが、多数の加入者にサービスを行うために十分拡張することが可能となる。

本発明は、プロセッサが、データの送信および受信に使用されるポートから物理的に分離されるために、プロセッサの数をポートの数とは関係なく変更することができ、またポートの数をプロセッサの数とは関係なく変更することができるので、多数の加入者にサービスを行うための柔軟性のあるアーキテクチャを提供する。

したがって、本発明は、ＣＡＭを、個々の位置のマスクと共に使用することによって、ＩＰパケットを形成するセルを、事前に指定されたプロセッサまたはプロセッサ・グループに割り当てるための迅速で効率的な方法を提供する。

本発明は、（その位置に関係する）加入者を探索する必要があるビットに対応するマスクで、それぞれの位置を構成することができるので、単一のＣＡＭアクセスにおける識別子の決定を提供する。

本発明は、単一のＣＡＭ位置をＩＰアドレスのグループについて使用し、ＣＡＭアクセスの出力を索引として使用してプロセッサまたはプロセッサ・グループ識別子を抽出することにより、必要となるＣＡＭ位置の数を最小にする。

本発明では、セル内のＶＰＩの代りに、決定されたプロセッサ識別子を用いることによって、かつ、スイッチ・ファブリックにＶＰＩを使用させてセルをプロセッサに割り当てることによって、スイッチ・ファブリックが迅速にＩＰパケットを対応するプロセッサへ転送することが可能となる。

本発明のさらなる特徴および利点、ならびに本発明の様々な実施形態の構造および動作を、図面を参照して以下に詳細に記載する。図面において、同様の参照番号は、一般に等しく、機能的に類似の、および／または構造的に類似の要素を示す。要素が最初に現れる図面を、対応する参照番号のもっとも左の数字によって示す。

本発明による方法を示すフローチャート。 本発明を実施することができる環境の一例を示す、遠距離通信システムのブロック図。 本発明による方法であり、サービス・プロバイダが、各加入者が所望する、カスタマイズされたサービス・ポリシーを提供することができる方法を示すフローチャート。 本発明によって提供されるインターネット・サービス・ノード（ＩＳＮ）の一実施形態のブロック図。 本発明によるＩＳＮに提供されるパケット・サービス・カードの一実施形態のブロック図。 加入者向けの所望のサービス・ポリシーを提供する処理規則の例を示す表。 （Ａ）すべての記憶場所についてただ１つの共通マスクを有するＣＡＭの動作を示すブロック図、および（Ｂ）各記憶場所についてマスクを有するＣＡＭの動作を示すブロック図。 本発明の一実施形態における、ＩＰパケットを処理するためのプロセッサを決定する回線を示すブロック図。 本発明の一実施形態における、異なるアプリケーションのプロセッサ識別子を決定するために実行されるステップを示すフローチャート。 図９の方法を使用してセル・ヘッダを修正する割り当て論理の一実施形態の細部を示すブロック図。

１．本発明の概観および説明
本発明により提供されるインターネット・サービス・ノード（ＩＳＮ）では、カスタマイズしたサービス・ポリシーを個々のユーザまたは加入者に提供することが可能となる。ＩＳＮでは、ネットワーク管理者が所望の処理規則のセットをそれぞれの加入者について指定できるようにすることができる。データが受信されたとき、ＩＳＮは最初に、データが関係する特定の加入者を決定し、該加入者に対応する処理規則に従って受信データを処理することができる。

受信データについて関係する加入者が最初に決定され、その加入者に対応する処理規則のみをそのデータに適用することができるので、ＩＳＮがサービスを行う他の加入者の処理規則に関係なく、データを効率的に処理することができる。

本発明の別の態様によれば、それぞれの加入者に対応する処理規則を、事前に指定したプロセッサまたはプロセッサのグループに割り当てることができる。したがって、それぞれの加入者に関係するデータを、対応するプロセッサに転送することができる。

それぞれの加入者を異なるプロセッサ・グループに割り当てることができるので、本発明を、多数の加入者にサービスを行うために十分拡張することができる。すなわち、サービス・プロバイダは、より多くのプロセッサを追加することによって、より多くの加入者にサービスを行うことができる。

本発明を、例示のためにいくつかの例に関して、以下でより詳細に説明する。しかし、本発明をいくつかの他の環境で、潜在的にいくつかの変形形態で実現できることに留意されたい。本発明による方法を最初に説明する。

２．方法
図１は、本発明による方法を示すフローチャートである。ステップ１１０で、それぞれの加入者向けの所望のサービス・ポリシーを提供するのに必要な処理規則を特定することができる。処理規則は一般に、データを処理する方法（たとえば、廃棄、転送、優先順位付け、暗号化など）を指定する。以下に説明する一実施形態では、処理規則は、分類子および関連するアクションを含むことができる。分類子は、アクションが適用される（加入者の）データ・ビットを指定する。

ステップ１２０で、インターネット・サービス・ノードを、幾人かの加入者に対応する処理規則で構成することができる。構成機構は、インターネット・サービス・ノードの実現に依存している。このようないくつかの機構の実現は、関連技術分野の当業者には、少なくとも本明細書で提供される開示に基づいて明らかであろう。

ステップ１３０で、インターネット・サービス・ノードは、データをビット・グループの形式で受信することができる。ステップ１４０で、インターネット・サービス・ノードが、このビット・グループを検査することによって、受信データが関係する加入者を決定することができる。特定の加入者の決定もまた、ビット・グループに使用される特定の形式に依存する。非同期転送モード（ＡＴＭ）に関する実施の一例を、以下でより詳細に説明する。しかし、本発明を他の形式（フレーム・リレー、イーサネットなど）と共に実現できることに留意されたい。これもまた、関連技術分野の当業者には、本明細書の開示に基づいて明らかであろう。

ステップ１５０で、インターネット・サービス・ノードは、ステップ１３０で決定した加入者に対応する処理規則を適用することができる。データは、この処理規則に従って転送（または廃棄）される。処理規則は、加入者が所望するサービス・ポリシーを提供するよう設計されているので、本発明によって、インターネット・サービス・ノードはサービス・ポリシーを提供することができる。また、インターネット・サービス・ノードをそれぞれの加入者に固有の処理規則で構成することができるので、差別化されたサービスをそれぞれの加入者に提供することができる。

本発明を、環境の一例に関して以下により詳細に説明する。しかし、ビット・グループの形式（特にＡＴＭに関して）を理解することが有用であり、このことが、受信データが関係する特定の加入者を決定する際の支援となることがある。

３．ビット・グループ
ビット・グループは、一般に、グループとして識別可能ないくつかのビットを指す。異なるビット・グループ形式をプロトコルに応じて使用して、異なるアクセス方法をサポートすることができる。複数のビット・グループは、事前に指定された規定に従って別のビット・グループを形成することができ、これは関連技術分野では周知である。一例として、いくつかのＡＴＭセルのデータは、ＩＰパケットを形成することができる。

例示のため、本発明を、ＡＴＭセルとして移送されるインターネット・プロトコル（ＩＰ）パケットのコンテキストにおいて実質的に説明する。しかし、本発明を他のプロトコルおよび移送で実現できることを理解されたい。これは、関連技術分野の当業者には明らかであろう。このような他の実施は、本発明の範囲および精神内のものであると企図される。

それぞれのＡＴＭセルは、５３バイトのデータを含み、そのうちの５バイトがヘッダとして使用され、４８バイトがペイロード（ＡＴＭネットワークを使用する実際のアプリケーション・データ）として使用される。ヘッダは、仮想パス識別子（ＶＰＩ）フィールドと、チャネルを定義する仮想チャネル識別子（ＶＣＩ）フィールドを有する。接続パスにおける次のノードは、典型的には、チャネルが適切な信号方式によって設定されたときに定義される。ＡＴＭを詳細に理解するには、Ｄａｖｉｄ Ｅ． ＭｃＤｙｓａｎおよびＤａｒｒｅｎ Ｌ． Ｓｐｏｈｎ著「ＡＴＭ： Ｔｈｅｏｒｙ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ」、（ＩＳＢＮ：００７０６０３６２６、１９９４年９月出版、ＭｃＧｒａｗ−Ｈｉｌｌ Ｓｅｒｉｅｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）という本を参照することができ、ここで、この本全体を参照により取り入れる。

ＡＴＭセルを、ＶＰＩ／ＶＣＩフィールド（およびこのセルが受信されるポート番号）を検査することによって、加入者と結び付けることができる場合がある。しかし、個々のＡＴＭセルは、カスタマイズしたサービス・ポリシーを提供するために、関連する加入者を正確に識別するのに必要な情報を含んでいないことが多い。したがって、理解すべきは、ＩＳＮは、より高いレベルのプロトコルを検査して加入者サービス・ポリシーを決定し、それに従ってセルを処理する必要がある。

したがって、ＡＴＭセルのペイロードを組み立てて、より高いレベルのプロトコル（この例ではＩＰプロトコル）のパケットを形成することができる。その後、組み立てたパケットを検査して、データが関係する加入者を決定することができ、この加入者に固有の処理規則が、このパケットに適用される。より高いプロトコル・パケットの検査において考慮すべき事項を、ＩＰ環境に関して以下で説明する。

４．加入者および関係するプロトコル（ＩＰ）パケットの識別
サービス・ポリシーを、個々の加入者に関係するパケットに関連付けることができる方法は、以下で説明するように、パケットがリモート・アクセス・アプリケーションに関係する方法を理解することによって明らかになるであろう。

典型的な各リモート・アクセス・アプリケーションは、少なくとも二方向のデータ・フローを有する接続を必要とする。データ・フローは一般に、アプリケーションをサポートするための、ソース・システムから宛先システムへのＩＰパケットのシーケンスを指す。ＩＰ環境では、アプリケーションが、典型的にはＴＣＰまたはＵＤＰポートによって識別され、これが一般に事前指定され、またはネゴシエートされて、アプリケーションとの関係を識別する。典型的にはソースおよび宛先ポート番号が使用される。プロトコルのタイプ（ＴＣＰ、ＵＤＰまたはＩＣＭＰ）、ポート番号、ソースおよび宛先ＩＰアドレスは、ＩＰフローを定義する。

いくつかのアプリケーション固有のセッションは、２つより多いフロー、および場合によっては多数の接続を使用する。アプリケーション・セッションに関係するすべてのフローが会話を定義する。ＩＰ環境では、関連技術分野では周知のように、会話が一般に、ＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザ・データグラム・プロトコル）およびＩＣＭＰ（インターネット制御メッセージ・プロトコル）プロトコルで実現される。会話は、アプリケーションに応じて複数のデータ・フローを含むことができる。たとえば、ファイル転送プロトコル（ＦＴＰ）およびＲｅａｌＡｕｄｉｏなどのアプリケーションは、複数のフローを使用し、時にはより高い層の組み合わせ（たとえば、ＩＰフィールドにおけるＴＣＰ対ＵＤＰ）を使用する。

ＴＣＰは、アプリケーションが使用する、最も共通した高レベルの移送である。これは、ＴＣＰが、潜在的に信頼性のないＩＰパケット転送を使用して、信頼性のあるデータのストリームを提供するからである。ＴＣＰ接続は一般に２つのデータ・フローを含み、ポート番号およびＩＰアドレスが逆になる。たとえば、Ｎ１、Ｎ２、Ｎ３およびＮ４がそれぞれ、一方向のデータ・フローのソースＩＰアドレス、ソース・ポート番号、宛先ＩＰアドレスおよび宛先ポート番号を指すと仮定すると、他方向のデータ・フローはそれぞれ同じ変数のＮ２、Ｎ１、Ｎ４およびＮ３を有する。複数のＴＣＰ接続を使用して、アプリケーションを実現することができる。

ＵＤＰの場合、ソース・ポートは、２つのエンド・システム間のパスで検査されるとき、一般に予測不能である。ＩＣＭＰの場合、ポートがタイプおよび識別フィールドによって置き換えられる。

上記から、ＩＰパケットの内容を検査することによって各フローを一意的に識別できることを理解されたい。さらに、多数のタイプのアプリケーションが事前指定のポート番号を使用しており（たとえば、ＳＭＴＰメールはポート２５を使用する）、このことを使用して、処理規則がユーザ・アプリケーション毎に指定されているならば、特定のユーザ・アプリケーションを識別することができる。

いくつかの例では、会話のフローに使用されるポート番号を、一般に事前指定された周知のポートで設定された「制御フロー」上で行われるネゴシエーションに基づいて決定することができる。たとえば、マルチメディア（テキスト、音声およびビデオの組み合わせを含む）アプリケーションでは、複数のフローを使用して、各マルチメディア構成要素に関係するデジタル・データを転送することができる。制御接続が最初に、事前定義されたポート（たとえば、ポート２００）上で起動され、残りのフローのポートは、制御接続上のパケット・フローに基づいて決定される。これらの新規フロー用のポート番号は、関連技術分野で周知のように、事前に指定された規定に従って符号化される。

少なくとも上記で例示した一般の形式およびプロトコルを使用して、ＩＳＮを実現し、所望のサービス・ポリシーを各加入者に提供することができ、これを以下でより詳細に説明する。例示のため、本発明を実施することができる環境の一例を最初に説明する。次いで、本発明の実施形態の例を説明する。

５．環境例
図２は、本発明を実現することができる電気通信環境２００の一例を示す図である。この図は、ＩＳＮ２５０をリモート・アクセス・サービス・プロバイダ（たとえば、インターネット・サービス・プロバイダ）が使用して、差別化されたサービスを加入者に提供することができる方法を示す。ユーザ（加入者）の位置（２１０、２３０−Ａおよび２３０−Ｘ）は、異なるアクセス技術を使用してインターネット・サービス・ノード（ＩＳＮ）２５０とインタフェースを取る。ＩＳＮ２５０は、アクセス・ネットワーク２９０に提供される。本発明によって、ＩＳＮ２５０では、所望の異なるサービス・ポリシーを異なるユーザに提供することが可能となる。

ユーザ・ネットワーク２１０は、ルータ２２０に接続するいくつかのシステムを備えることができる。ユーザ・ネットワーク２１０は、１人の加入者または複数の加入者を含むものとみなすことができる。ルータ２２０は、データをＩＳＮ２５０へＩＰパケットとして、シリアル・ライン・インタフェース・プロトコル（ＳＬＩＰ）またはポイントツーポイント・プロトコル（ＰＰＰ）などのプロトコルを使用して転送することができる。ユーザ位置２３０−Ａおよびユーザ位置２３０−Ｘは、図ではリモート・アクセス・デバイス２４０に接続され、リモート・アクセス・デバイス２４０は、既知の方法で実現されるリモート・アクセス・サーバ（アナログおよび／またはデジタル・モデムをサポートする）またはＤＳＬＡＭに対応することができる。リモート・アクセス・デバイス２４０は、データを、ＡＴＭセルにセグメント化されたＩＰパケットとして転送することができる。それぞれの位置２３０は、以下に説明するように、単一または複数の加入者を有することができる。

図２のインタフェースおよび加入者位置が単なる例でしかないことを理解されたい。ＩＳＮ２５０は、異なる媒体および技術を使用して、本発明の範囲および精神から外れることなく、異なる加入者位置とインタフェースを取ることができ、これは関連技術分野の当業者には明らかであろう。このような他の実施形態は、本発明の範囲および精神内のものであると企図される。

ＩＳＮ２５０は、様々なインタフェースで受信したデータを本発明に従って処理し、所望のサービス・ポリシーを異なる加入者に提供する。図示しないが、リモート・アクセス・デバイス２４０もアクセス・ネットワーク２９０の一部とみなすことができる。ＩＳＮ２５０もまた、データ・スイッチ２８０に依拠する代わりに、直接インターネットとインタフェースを取ることができる。一般に、データ・スイッチ２８０は、ＩＳＮ２５０が経路指定機能を含めて実現されない場合に必要となることがある。

所望のサービス・ポリシーが処理規則によって指定され、または処理規則に変換される。このことは、異なる加入者アプリケーションに対応するデータを処理する必要のある方法を示す。異なるビット・グループを異なるアプリケーションと相互に関係を持たせることを可能にするため、ＩＳＮ２５０は、ビット・グループを、必要な情報を含むパケットに結合することができる。その後、処理規則がパケットに適用され、所望のサービス・ポリシーを提供する。データ・スイッチ２８０はＩＳＮ２５０からビット・グループを受信し、インターネットにおける他の外部システムとインタフェースを取ることができる。データ・スイッチ２８０は、事前に指定された設計に従って、ＩＰルータ、ＡＴＭまたはフレーム・リレー・スイッチに対応することができる。

図２にも示すように、ＩＳＮ２５０は、ＩＳＰおよびＬＥＣ（incumbentまたはcompetitive）などの、リモート・アクセス・サービス・プロバイダ用の特定のアプリケーションを有する。所望のサービス・ポリシーを様々な加入者に提供できる能力があるので、本発明のＩＳＮ２５０を、リモート・アクセス・ネットワーク２９０のエッジに配置する（すなわち、加入者側装置とインタフェースを取る）ことができる。このような場合、ＩＳＮ２５０を、エッジ・デバイス、入口／出口ルータまたはゲートウェイと呼ぶことがある。

以下の説明から明らかになるように、ＩＳＮ２５０をエッジで使用することによって、加入者側装置（たとえば、ルータ２２０）をあまり複雑でなく実現することが可能となり、したがって管理がより容易になり、コストが低くなる。このような特徴は、ＩＳＰおよびＬＥＣには特に重要である。これに応じて、図３は、所望のサービス・ポリシーをそれぞれの加入者に提供することができる方法を示す。

６．エッジ・デバイスを使用した、差別化されたサービスの提供
図３は、本発明による、サービス・プロバイダが、差別化されたサービスを加入者に提供することができる方法を示すフローチャートである。ステップ３１０で、本発明のＩＳＮ２５０が、図２に示すようなアクセス・ネットワークのエッジ・デバイスとして提供される。ＩＳＮ２５０を、ＩＰルータとして実現することができる。これは、ＩＰプロトコルを様々なシステムで幅広く使用できるからである。

ステップ３２０で、異なるサービス・ポリシーをそれぞれの加入者について指定することができる。サービス・ポリシーは、たとえば加入者または加入者が使用するいくつかのシステムが使用することのできる集約帯域幅、ファイアウォール・パラメータ（どのアプリケーション／ＩＰアドレスが入出を許可されるか）、指定された会話のセキュリティ（アンチ・スプーフィング（anti-spoofing）、暗号化、およびトンネリングによる仮想専用ネットワーク）、バッファおよび帯域幅の使用における優先順位（たとえば、テレネットなどの対話形式のアプリケーションにはより高い優先順位を与える）、トラフィック・ステアリング（traffic steering）などを指定することができる。サービス・ポリシーを指定する例を、以下でより詳細に説明する。

ステップ３２５で、サービス・ポリシーに対応する処理規則を生成することができる。それぞれの処理規則は、分類子および関連するアクションを含む。分類子は、すべてのデータ・フロー、および、そのデータ・フロー上のデータに関連するアクションを適用する必要のある条件を指定する。ＩＰ環境では、各データ・フローを一意的に、プロトコル・タイプ、ソース／宛先ＩＰアドレス、および（ＴＣＰ／ＵＤＰ）ソース／宛先ポートによって識別することができる。分類子は複数のデータ・フローを指定することができる。

条件は、実施中のサービス・ポリシーのタイプに固有であることができる。たとえば、加入者に、ビジネス時間外の間により高い帯域幅を許可することができる。別の加入者は、データが一日の指定時間中に特定の加入者に宛てられた場合には、より低い優先順位が与えられているデータを有することができる。条件の例を、図６のＢを参照して、以下でより詳細に説明する。

多数の処理規則を、サービス・ポリシーが指定されたときに事前に生成することができる。しかし、いくつかの処理規則では、必要な情報が事前に入手可能でないことがある。このような状況では、情報が入手可能となったときに規則が動的に生成される。処理規則を動的に生成するためのいくつかのシナリオ例を、以下に記載する。

規則の動的生成を必要とするシナリオの一例は、加入者がアクセス・ネットワーク２９０とのダイヤルアップ接続を使用し、アクセス・ネットワーク２９０に依拠してＩＰアドレスを割り当てるときである。たとえば、図２に関して、ユーザ位置２３０−Ａは、モデムを使用するパーソナル・コンピュータに対応することができる。ユーザ位置２３０−ＡにおけるマシンのＩＰアドレスを、ユーザがダイヤルアップ接続を確立したときに認証許可アクセス（ＡＡＡ：Authentication-Authorization-access）サーバ（図示せず）によって割り当てることができ、これは関連技術分野では周知である。処理規則が、割り振られたＩＰアドレスを必要とすると仮定すると、ＩＰアドレスを割り振った後でのみ、処理規則を生成することができる。

別の例として、いくつかのアプリケーションの場合、データ・フローをアプリケーション・セッションの途中で起動することができ、ポート情報を、対応するデータ・フローが起動された後でのみ入手可能である場合がある。ポート情報は、典型的には、２つのエンド・システム間のネゴシエーション（交渉）中に決定され、ポート情報は一般に、ネゴシエーションの基礎としての機能を果たすパケットに含まれる。

したがって、ＩＳＮ２５０は、いくつかのフロー上のパケットを監視して、他のフローのポート番号を求めなければならないことがある。その後、ＩＳＮ２５０は、求めた情報を使用して、分類子および関連するアクションで処理規則を生成することができる。

ステップ３３０で、ＩＳＮ２５０で処理規則がインスタンス化される。インスタンス化は一般に、ＩＳＮ２５０の適切な構成によって処理規則をアクティブにすることを指す。インスタンス化した後、ＩＳＮ２５０は、対応する加入者データに処理規則を適用し、これを以下でより詳細に説明する。

いくつかの処理規則を、事前に、たとえばＩＳＮ２５０を立ち上げた（ブートした）とき、または所望のサービスが指定されたときより早く、インスタンス化することができることに留意されたい。他のいくつかの処理規則は、上述のようにステップ３２５で生成されたときにインスタンス化されることができる。

ステップ３４０で、ＩＳＮ２５０は、加入者側装置に提供された特定のインタフェースに従って、ビット・グループを受信することができる。ステップ３６０で、ビット・グループが、処理規則を適用するのに適したパケットに変換される。ビット・グループが、処理規則を適用するために十分なデータを含む場合には、ビット・グループ自体をパケットとして、変換なしに取り扱うことができる。たとえば、ビット・グループが断片化のない完全なＩＰパケットに相当し、組み立てを実行する必要のないことがある。ビット・グループがＡＴＭセルである場合には、複数のセルのペイロードを結合（組み立て）してＩＰパケットを形成することができる。

複数のＩＰパケットのデータを、１つのパケットに結合する必要がある場合があり、これは、典型的にはＩＰパケットが断片化されているときである。断片化を実行して、たとえば個々のＩＰパケット・サイズを小さくして、接続パスにおける中間ネットワークによって許可される最大パケット・サイズに従わせるようにすることができる。結合されたパケットもパケットと呼ばれる。一般に、ビット・グループを複数のレベルで組み立てて、加入者データ（ビット・グループの形式で受信された）が分類子に合致するかどうか判断することができる。

ステップ３８０で、パケットが、加入者毎に提供された処理規則に従って処理される。つまり、最初にそれぞれのパケットが加入者に関連付けられ、この加入者に対応する処理規則が適用される。関連技術分野で周知のように、リモート・アクセス中にＩＰアドレスを複数のマシンによって共有することができる。したがって、仮想チャネル番号（たとえば、ＡＴＭおけるＶＣＩ／ＶＰＩの組み合わせ、フレーム・リレーのＤＬＣＩ）が最初に加入者を識別することができ、加入者に関連付けられた処理規則を、そのチャネル上で受信または送信されたパケットに適用することができる。

複数の加入者が、いくつかの状況において、単一のチャネル識別子を共有することができる。たとえば、ネットワーク２１０のサブグループが一人の加入者とみなされるとき、ネットワーク２１０のその加入者らは、１つのチャネルを共有することができる。このような場合、ＩＰアドレスを重複しないよう設計して、異なるフローが一意的に異なる加入者に関連付けられるようにすることができる。類似の方法で、ＩＳＮ２５０は、単一チャネル上の複数の加入者宛てのパケットを受信することができる。このような状況では、ＩＳＮ２５０は、ＩＰアドレスおよび他の情報を検査して、パケットを加入者に関連付ける必要がある。

処理規則を、いくつかの可能な順序のうちの１つに適用して、予測可能かつ所望のサービス・ポリシーを確実にする必要がある。一般に、処理は、パケットを転送するかどうか、どこで／どのように／およびどの優先順位でパケットを転送するか、を決定する。処理規則を実現するため、いくつかの「状態」をＩＳＮ２５０で維持する必要がある。たとえば、事前に決定された集約帯域幅が複数のフローに割り振られた場合、複数のフローについて転送されるビット数を維持して、全体の帯域幅を制限する必要がある場合がある。パケット内のデータは一般に、接続パスにおける次のシステムで提供されるインタフェースに従って転送される必要がある。

このように、処理規則を異なるパケットに適用することによって、所望のサービス機能をそれぞれの加入者に提供することができる。図３の方法は、いくつかのＩＳＮにおいて実現することができる。ＩＳＮ２５０の一実施形態を、以下でより詳細に説明する。

７．インターネット・サービス・ノード
図４は、一実施形態のＩＳＮ２５０の細部を示すブロック図である。ＩＳＮ２５０は、アクセス・ポート（４１０−Ａおよび４１０−Ｂ）、トランク・ポート（４２０−Ａ、４２０−Ｂおよび４２０−Ｃ）、スイッチ・ファブリック４４０、パケット・サービス・カード４５０−Ａおよび４５０−Ｂ、ルート／サービス管理カード（ＲＭＣ）４６０および構成マネージャ４７０を備えることができる。トランク・ポート４２０−Ａ、４２０−Ｂおよび４２０−Ｃは、文脈から明らかとなるように、総称して、または個別に４２０と称する。同様のことを、本発明に記載する他の構成要素に関して使用する。

パケット・サービス・カード４５０が物理的にポート４１０および４２０から分離されていることに留意されたい。物理的な分離によって、パケット・サービス・カード４５０の数を、ポート４１０および４２０の数に関係なく変更することが可能となり、ポート４１０および４２０の数を、パケット・サービス・カード４５０の数に関係なく変更することが可能となる。このような柔軟性によって、ＩＳＮ２５０は、多数の加入者にサービスを行うために十分拡張することが可能となる。

アクセス・ポート４１０は、事前に指定されたフォーマットでセルを送受信するのに必要な物理インタフェースを提供する。Ｓｏｎｅｔなどのプロトコルを、より高速のインタフェースに使用することができる。例示のため、アクセス・ポート４１０は、データを、ＡＴＭセルの形式で送受信すると仮定する。各加入者ポート４１０は、ＡＴＭセルを、スイッチ・ファブリック４４０に転送する。

トランク・ポート４２０は、インターネットアクセス用の高速アクセス・ラインを加入者に提供する。トランク・ポート４２０は、ＡＴＭセル（または他のビット・グループ）をスイッチ・ファブリック４４０から受信し、このセルを、チャネル識別子（または他の宛先アドレス）によって指定された対応するライン上に転送する。類似の方法で、トランク・ポート４２０は、データ・ビット・グループをＡＴＭセルまたはＩＰパケットの形式でインターネットから受信し、このデータ・ビット・グループをスイッチ・ファブリック４４０に送信することができる。この受信シナリオでは、より高いレベルのプロトコル情報（たとえば、ＩＰヘッダ）を検査して、データを転送する先の特定のプロセッサ・グループを決定する必要がある場合がある。対応するプロセッサ・グループがデータを受信した後、データは検査され、このデータが関係する特定の加入者を決定し、対応する処理規則が適用される。

一実施形態では、複数のポートがライン・カード上に提供され、それぞれのポートをトランク・ポートまたはアクセス・ポートのいずれかとして構成することができる。ライン・カードは、フレーム・リレー、ＡＴＭ、Ｓｏｎｅｔを介したパケット、高速イーサネット、ギガビット・イーサネットなど、異なるアクセス技術をサポートすることができる。

構成マネージャ４７０は、好都合なユーザ・インタフェースを提供して、異なるサービス・ポリシーを異なる加入者について指定できるようにする。サービス・ポリシーは、異なる加入者に提供されるサービスを決定する。構成マネージャ４７０は、様々な構成パラメータ（サービス・ポリシーによって決定される）をＲＭＣ４６０に送ることができ、ＲＭＣ４６０は、異なる構成要素を構成してサービス・ポリシーを提供することができる。一実施形態では、構成マネージャ４７０は、分離したコンピュータ・システムとして実現され、これは事前に指定されたプロトコルに従ってＩＳＮ２５０と対話する。代替の実施形態では、構成マネージャ４７０をＩＳＮ２５０に統合することができる。

構成マネージャ４７０は、情報が入手可能であるときにはサービス・ポリシーを処理規則に変換することができ、該処理規則を、対応するパケット・サービス・カード４５０に提供することができる。パケット・サービス・カード４５０は、対応する加入者向けの処理規則をインスタンス化することができる。たとえば、構成マネージャ４７０は、認証許可アクセス（ＡＡＡ）サーバと対話して、いつＩＰアドレスを、ダイヤルイン接続によってアクセス・ネットワークにアクセスする加入者に割り振るかを決定することができ、該加入者に対応する処理規則をパケット・サービス・カード４５０のうちの１つに提供する。

ルート／サービス管理カード（ＲＭＣ）４６０は、Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ（ＯＳＰＦ）、ＲＩＰまたはＢＧＰなどの経路指定プロトコルを実行して、各ＩＰパケットの次のホップ（または一般に転送情報）を決定する。経路指定プロトコルは、既知の方法で実行することができる。ＲＭＣ４６０は、転送情報をＶＣＩ／ＶＰＩ情報の形式で提供して、ＩＰパケットの次のホップを特定することができる。

さらに、ＲＭＣ４６０は、ＩＳＮ２５０の異なる構成要素を構成して、本発明の異なる特徴をイネーブルすることができる。Ｌ２ＴＰに関して、Ｌ２ＴＰトンネルを設定して該トンネル内にコールを設定する要求を処理するよう、ＲＭＣ４６０を設計することができる。ＲＭＣ４６０は、コールＩＤ、トンネルＩＤ、および他のいかなる必要な情報を、このトンネルに関係するデータを受信する対応するアクセス／トランク・ポートに提供することができる。その後、アクセス・ポートは、この情報を使用して、トンネル内で受信されるＩＰパケットを、特定のパケット・サービス・カード４５０に割り当てることができる。

スイッチ・ファブリック４４０は、ビット・グループをアクセス・ポート４１０から受信し、パケット全体についてのデータを受信したときに、受信したビット・グループをパケット・サービス・カード４５０へ転送する。データ・ビットがＡＴＭセルとして受信された場合、パケットの最後のセルを、関連技術分野で周知のＡＡＬ５プロトコルに従って求めることができる。こうして、フレームを形成するすべてのセルを、パケットのデータが入手可能になった後に、適切なパケット・サービス・カード４５０に送信することができる。異なるサービス・ポリシー・タイプを、異なるパケット・サービス・カード４５０で実現することができる。それに応じて、（接続または加入者識別子を使用して）それぞれの加入者を、所望のサービス・ポリシー・タイプを提供するパケット・サービス・カードに割り当てることができる。

適切なパケット・サービス・カードを決定するため、スイッチ・ファブリック４４０は、ビット・グループが受信される各チャネルに関連付けられたチャネル識別子を維持することができる。ＡＴＭセルの場合、ビット・グループにおけるＶＣＩ／ＶＰＩ情報が、一意的にこのようなチャネルを定義する。（データが受信される）物理ポート番号およびチャネル識別子は、データが直接加入者から受信されてインターネットに向かうことになっているとき、一意的にそれぞれの加入者（または、ＩＰアドレスが重複しない加入者のグループ）を識別することができる。他方では、データがインターネットから受信されるとき、関連する加入者の決定にＩＰヘッダの検査が必要になることがある。一般に、スイッチ・ファブリック４４０は、パケットの最後のセルが受信されるまでセルをバッファに入れることができ、このパケットのすべてのセルを、個々の加入者に割り振られたパケット・サービス・カードに転送する。

スイッチ・ファブリック４４０は、アクセス・ポート４１０およびトランク・ポート４２０からセルを受信し、このセルをパケット・サービス・カード４５０の１つに転送する。スイッチ・ファブリック４４０は、パケット全体のデータを受信したときに、受信したセルをパケット・サービス・カード４５０に転送することができる。スイッチ・ファブリック４４０は、最後のセルの到着の待機中にセルをバッファに入れるために、高速ランダム・アクセス・メモリ（図示せず）を使用することができる。パケットの最後のセルを、関連技術分野に周知のＡＡＬ５プロトコルに従って求めることができる。こうして、パケットのデータが入手可能になった後に、フレームを形成するすべてのセルを適切なパケット・サービス・カード４５０に送信することができる。

スイッチ・ファブリック４４０は、サービス処理規則に従って処理した後にパケット・サービス・カード４５０からパケットを受信し、受信したパケットをトランク・ポート４２０の１つに送信することができる。特定のトランク・ライン・カード４２０をそれぞれのチャネルについて関連付けることによって、特定のトランク・ポート４２０を求めることができ、これは、パケット・サービス・カード４５０によって提供されるチャネル識別子によっても識別することができる。スイッチ・ファブリック４４０は、トランク・ライン・カード４２０で伝送する前に、このパケットをセルに変換することができる。

パケット・サービス・カード４５０を、それぞれの加入者向けの多数の処理規則で構成することができ、それぞれの処理規則は、分類子および関連するアクションを含む。分類子は一般に、データ・フロー、および、このデータ・フロー上で転送される１組のデータ・ビットにこのアクションを適用することができる条件を指定して、各加入者に所望のサービス・ポリシーを提供する。一般に、インターネット・プロトコル（ＩＰ）環境では、ソース／宛先ＩＰアドレス、ソース／宛先ポートおよびプロトコル・タイプ・フィールドが共に、特定のリモート・アクセス・アプリケーションをサポートするＩＰデータ・フローを定義する。

それぞれのパケット・サービス・カード４５０は、いくつかの理由の１つにより、加入者に対応する処理規則で構成することができる。たとえば、それぞれの加入者のために処理するデータを特定のパケット・サービス・カード４５０に割り当てることによって、それぞれのパケット・サービス・カード４５０を、それに割り当てられた加入者に対応する処理規則のみで構成する必要がある場合がある。

複数のパケット・サービス・カード４５０を使用して、大規模で複雑な大規模環境に応じて十分拡張することができる。さらに、いくつかのパケット・サービス・カード４５０は、いくつかのタイプの加入者データを処理するのに専用の機能性を有することができる。

パケット・サービス・カード４５０は、最初にセル・データをパケットに組み立てることができ、このパケットを加入者と結び付けることができる。加入者が決定された後、パケットが関係するフローが決定され、対応する処理規則が適用される。このプロセスでは、パケット・サービス・カード４５０が、パケットを廃棄するか転送するかを決定することができる。パケット・サービス・カード４５０は、受信したセルを加入者向けの処理規則に従って処理し、所望のサービス・ポリシーを特定の加入者のそれぞれに提供することができる。

パケット・サービス・カード４５０は、パケットの次のホップを、経路指定管理カード４６０が提供する経路指定情報、または、入ってくるセル内に関連付けられたセル・ヘッダに基づいて、判断することができる。処理パケットからすべてのセルを生成するために、新規のＶＣＩ／ＶＰＩ番号が、次のホップに従って生成される。パケット・サービス・カード４５０は、新規ＶＣＩ／ＶＰＩ番号を有するセルを、適切なトランク・ポート４２０上に転送するために、スイッチ・ファブリック４４０へ送信する。

それぞれの加入者を１つのパケット・サービス・カード４５０に割り当てられるものとして記載したが、複数のパケット・サービス・カードが、単一の加入者に関係するデータを処理できることを理解されたい。このような状況は、典型的には、パケット・サービス・カードの１つが、特定の専用サービスをすべての／複数の加入者に提供するよう設計され、他のパケット・サービス・カードが、加入者が所望する残りのサービスを提供するよう設計されたときに、存在する。このような状況では、サービス・カードの１つによって処理されたデータを、スイッチ・ファブリックを使用して、事前に決定されたシーケンスに従って、別のパケット・サービス・カードに転送することができる。このようなすべてのパケット・サービス・カードにおけるプロセッサもまた、プロセッサ・グループと呼ぶことができる。

処理規則をそれぞれのパケットに適用することによって、パケット・サービス・カード４５０において、ＩＳＮ２５０は、本発明によるいくつかの特徴を提供できるようにすることが可能となる。パケット・サービス・カード４５０のいくつかの実施形態は、本発明の範囲および精神から外れることなく実現することができる。実施の一例を、以下で説明する。

８．パケット・サービス・カード
図５は、一実施形態のパケット・サービス・カード４５０の細部を示すブロック図である。パケット・サービス・カード４５０は、４つのプロセッサ・グループ（５５０−Ａから５５０−Ｄ）、プロセッサ・インタフェース（ＰＩＦ）５３０、および制御論理５２０を備えることができる。各ブロックの動作を、以下でより詳細に説明する。

制御論理５２０は、パケット・サービス・カード４５０の他の構成要素の動作を調整し、制御する。制御論理５２０は、プロセッサ・グループのどのプロセッサがそのパケットを処理できるかを判断することができる。一実施形態では、パケットが、ラウンド・ロビン・ベースで４つのプロセッサの間で割り当てられる。制御論理５２０は構成マネージャ４７０と共に動作して、プロセッサ・グループ５５０を、割り当てられた加入者に関係する処理規則でインスタンス化（構成）することができる。

サービス・ポリシーの実現に、データ・フローで転送されたデータの検査に基づく処理規則の動的なインスタンス化が必要であるとき、制御論理５２０は、データ・フローを検査し、新規の処理規則を生成することができる。図示のように、Ｈ．３２３、ｖｏｉｃｅ−ｏｖｅｒ−ＩＰ、またはストリーミング・アプリケーションでは、新規の接続またはデータ・フローを、制御フローで実施されたネゴシエーションに基づいて動的に作成することができる。制御論理５２０は、制御フローを検査して、いずれかの必要な情報（たとえば、ポート番号）を求め、この検査に基づいて処理規則を作成することができる。制御論理５２０は、プロセッサ・グループ５５０が処理規則によって指定された動作を実行することを保証するよう、プロセッサ・グループ５５０を構成することができる。制御論理５２０を、構成マネージャ４７０を使用して指定されたサービス・ポリシーに起因して制御することができる。

ＰＩＦ（プロセッサ・インタフェース）５３０は、セルをスイッチ・ファブリック４４０から受信し、（ＩＰパケットを形成する）このセルを４つのプロセッサ・グループ５５０のうちの１つに転送することができる。一実施形態では、ＰＩＦ５３０は、４つのプロセッサ・グループに対応する４つの入力ポートを備えることができ、スイッチ・ファブリック４４０は、ＶＣＩヘッダ情報によって決定されるように、このセルを４つのポートのうちの１つ（したがって、特定のプロセッサ・グループに）に送信することができる。すなわち、ＶＣＩヘッダは、パケット・サービス・カードだけを決定できるのではなく、受信したセルを処理する特定のプロセッサ・グループをも決定することができる。

幾人かの加入者を、一意的にプロセッサ・グループ５５０のそれぞれに割り当てることができる。ＲＭＣ４６０は、それぞれのプロセッサ・グループ５５０を、割り当てられた加入者に関連付けられた処理規則で構成するのに必要なコマンドを生成することができる。ＲＭＣ４６０は、どの特定のプロセッサ・グループ５５０が加入者のそれぞれに関係するデータを処理するかを決定することができ、対応するプロセッサ・グループを、割り当てられた加入者に関連付けられた処理規則で構成する。構成コマンドは、プロセッサ・インタフェース５３０を介して発行することができる。

それぞれのプロセッサ・グループ５５０は、いくつかのプロセッサおよびＳＲＡＭ（図示せず）を備えて、パケットに関係するセルを格納することができる。ＳＲＡＭを、プロセッサ・グループ５５０に含まれるすべてのプロセッサによって共有することができる。プロセッサ・グループ５５０のすべてのプロセッサは、割り当てられたすべての加入者に関係するデータを処理可能にすることができる。プロセッサ・グループを、セルに関連付けられたチャネル識別子によって決定することができるが、パケットを処理する特定のプロセッサは、制御論理５２０によって決定されることができる。

それぞれの加入者をプロセッサ・グループ５５０に割り当てることができるので、サービス・プロバイダは、追加のプロセッサ・グループを追加することによって、より多くの加入者にサービスを行うことができる。したがって、本発明によって提供される解決策は、大規模ネットワークに応じて十分拡張することができる。さらに、プロセッサ・グループを、加入者の特定のポリシー要件についてサービスを行うよう設計することができる。たとえば、プロセッサ・グループ５５０−Ｂのみを、仮想専用ネットワーク（ＶＰＮ）を提供するよう設計することができ、ＶＰＮを必要とするすべての加入者をプロセッサ・グループ５５０−Ｂに割り当てることができる。サービス・ポリシーのいくつかの例を、図６のＡおよびＢを参照して、以下でより詳細に説明する。

９．サービス・ポリシーの例
図６のＡおよびＢは共に、加入者向けの加入者ポリシーの例を示す図である。例示のため、パケットを、第１のマッチ・ポリシー（match policy）に従って処理されるものとして説明する。しかし、関連技術分野の当業者には明らかであるように、「ベスト・マッチ（best match）」などの他のマッチ・ポリシーを使用することもできる。

図６のＡは、セキュリティを実現するのにどれほど異なるポリシー規則を指定できるかを示す。最初に、セキュリティ・ポリシーの分類子が、フローを識別するのに必要なデータのみ（条件なし）を含むよう選択されることに留意されたい。サービス規則６１０は、ＩＰアドレスの分類子＝ＳｕｂｓＡまたはＯｆｆｉｃｅ１、宛先ＩＰアドレス＝ＳｕｂｓＡまたはＯｆｆｉｃｅ１、サービス＝ＩＭＡＰ、および３ｘＤＥＳ暗号化プロトコルを使用して合致するデータを暗号化するアクションを指定する。すなわち、ＳｕｂｓＡおよびＯｆｆｉｃｅ１の間のメール交換は、指定したプロトコルを使用して暗号化される。

２つの処理規則を、サービス規則６１０を実現するよう生成することができ、それぞれの規則は、１つのフローを指定する分類子を持つ。一般に、それぞれの処理規則は、ソースＩＰアドレス、宛先ＩＰアドレス、プロトコル・フィールド（たとえば、ＴＣＰまたはＵＤＰ）、ソース・ポート番号、および宛先ポート番号の５組として生成することができる。

少なくともいくつかのサービス規則のパラメータは、容易に事前入手可能であり、したがって対応する処理規則パラメータに静的に変換することができる。こうして、サービス規則６１０のＩＰアドレスＳｕｂｓＡおよびＯｆｆｉｃｅ１が事前に既知であると仮定すると、２つの処理規則をサービス規則から生成することができる。これは、ＩＭＡＰ用のＴＣＰポート番号が事前に指定されているからである。

しかし、ＩＰアドレスの１つ（たとえば、ＳｕｂｓＡ）を動的に生成する場合、たとえば、ユーザ・システムがダイヤルイン接続を確立する必要があるとき、ユーザ・インタフェース４７０は、ユーザにＩＰアドレスが割り当てられた後に、動的に処理規則を生成することができる。処理規則を動的にインスタンス化することもできる。

サービス規則６２０は、ＳｕｂｓＡから、およびＳｕｂｓＡへの、すべてのＨＴＴＰ、ＳＭＴＰおよびＴＥＬＮＥＴトラフィックを受け入れて暗号化するよう試みる。処理規則を、ＨＴＴＰ、ＳＭＴＰおよびＴＥＬＮＥＴのそれぞれについて生成することができる。これらの３つのアプリケーションのプロトコル・タイプおよびポート番号が事前に指定され、ＩＰアドレス（ＳｕｂｓＡおよび他のＯｆｆｉｃｅｓ）も既知であると仮定すると、それに応じて処理規則を静的に生成することができる。

サービス規則６３０は、ＳｕｂｓＡ−Ｗｅｂ−ＳｒｖｒへのすべてのＨＴＴＰトラフィックを受け取る。サービス規則６４０は、ＳｕｂｓＡ−Ｍａｉｌ−Ｓｒｖｒとのすべてのｓｍｔｐトラフィックを受け入れる。サービス規則６５０は、ＳｕｂｓＡ−Ｓｕｂｓｅｔｓからのすべてのトラフィックを受け入れる。サービス規則６６０は、すべての他のデータを落とし（ドロップし）、落としたデータのログを、後に計算および分析するために作成する。容易に理解可能であるように、図６のＡの手法を使用して、加入者に固有のセキュリティ要件を実現することができる。異なる加入者は、個々のニーズに合わせて異なるポリシー規則を有することができる。

図６のＡの手法では、それぞれの分類子が一般に、フローを識別するのに必要な情報を含む。図６のＢを参照して例示するように、分類子は、サービス・ポリシーに固有の条件を含むことができる。図６のＢは、一実施形態における、「ポリーシング（policing）のためのサービス・ポリシー規則を示す図である。ここで、「ポリーシング」は、一般に、使用可能な帯域幅を共有する異なる接続への帯域幅の優先順位付けおよび割り振りを指す。

サービス規則６８０は、ＳｕｂｓＡｌｉｎｋ−Ｉｎにおいて、１Ｍｂｐｓ未満の集約帯域幅、および５００Ｋｂｐｓ未満の持続される帯域幅でデータを受信中の場合、このデータにサービス・タイプ（ＴＯＳ）を再送信しなければならないと指定する。持続帯域幅および集約帯域幅は、いくつかの既知の方法の１つに従って計測することができる。分類子は、この規則が、一日のどの時間においてもすべてのＴＯＳに適用可能であると指定する。ＴＯＳ、時間（Ｔｉｍｅ）、場所（Ｗｈｅｒｅ）およびライン条件（ＬｉｎｅＣｏｎｄ）は、ポリーシングのサービス・ポリシーの条件例である。

サービス規則６８０は、サービス規則６８０のライン条件（ＬｉｎｅＣｏｎｄ）が違反された場合に、データの優先順位を低くする。上述の実施形態のＩＳＮ２５０は、トランク・ポート４２０で送信する前にデータ・ビット・グループを再生成するので、ＴＯＳ値を既知の方法でデクリメント（decrement）することができる。

少なくとも上述の実施形態を用いて、特殊化されたサービス・ポリシーをＩＳＰによってそれぞれの加入者に提供することができる。上述のように、本発明は、リモート・アクセス・アプリケーションについて特定の適用例を有する。

さらに、ＩＳＮ２５０をエッジ・ルータとして実現することによって、簡素なデバイスを加入者の構内で配備することが可能となる。例示として、本発明を用いなければ、図２のネットワーク２１０の加入者は、異なるサービス・ポリシーを提供するために複合ルータ２２０を実現する必要のある場合がある。管理にかかる間接費は、容認できないほど高くなることがある。逆に、本発明を用いることによって、ＩＳＮ２５０の適切な構成を使用する中央リモート・アクセス・プロバイダにより、所望のサービス・ポリシーを提供することができ、それによって加入者の構内のデバイスの構成および管理が簡素化される。

しかし、インターネット・サービス・ノードに伴う１つの要件は、加入者に関係するデータが迅速かつ効率的に特定のプロセッサへ処理のために割り当てられ、本発明による解決策を、多数の加入者を有する環境で使用できるようにすることである。本発明によるこのような割り当ておよび解決策に伴ういくつかの問題を、以下で説明する。

１０．プロセッサへの割り当てに伴う問題
上記の説明から留意できるように、スイッチ・ファブリック４４０は、ＩＰパケットのセルを特定のプロセッサ・グループ４５０に割り当てる必要がある。スイッチ・ファブリック４４０が異なるアクセス・ポートおよびトランク・ポートでセルを受信することができるので、特定のプロセッサ・グループ４５０への割り当てが迅速に（短期間で）起こる必要がある。

迅速にするため、この割り当てを、セル・ヘッダの検査に基づかせることができる。以下のさらなる説明では、この割り当てをＶＰＩのみに基づくものとして仮定する。しかし、本発明の範囲および精神から外れることなく、セル・ヘッダの他の部分をセルの割り当てに使用することができる。セルがアクセス・ポート４１０で受信されたとき、セルが受信される際の接続のＶＰＩ番号を、特定のプロセッサ・グループ４５０の識別子に対応するよう制御することができ、これは関連技術分野の当業者には明らかであろう。

しかし、セルがトランク・ポート４２０で受信されたとき、複数の加入者が、典型的には同じＡＴＭ仮想接続を共有する。同じＡＴＭ接続で受信された異なる加入者の加入者データを、異なるプロセッサに割り当てる必要がある。このような状況では、ＡＴＭセルのデータを検査し、このＡＴＭセルを処理するための特定のプロセッサを決定する必要がある。

ＩＰネットワークの場合、ＩＰパケットの第１のＡＴＭセルのペイロードに含まれるＩＰ宛先アドレスを検査して、ＩＰパケットを割り当てる（加入者）プロセッサを決定する必要がある。関連技術分野で周知のように、セルのシーケンスはＩＰパケットを表し、典型的には、第１のセルがＩＰ宛先アドレスを含む。それに応じて、セル・データがトランク・ポート４２０で受信されたとき、少なくともＩＰヘッダ情報を検査する必要がある。

セル・データを検査する必要性は、セルがトランク・ポート４２０で受信された場合に限定されない。セルがアクセス・ポート４１０で受信されたときにも、セル・データを検査する必要がある場合がある。たとえば、セルがトンネリング（たとえば、Ｌ２ＴＰおよびＬ２Ｆ）およびＩＰセキュリティ（典型的には、同じ仮想回線上の複数の加入者に関係するデータを含む）などのアプリケーションに関係するとき、より高い層のヘッダ・データ（たとえば、ＵＤＰ、ＴＣＰ）をさらに検査して、セルを処理する特定のプロセッサを決定する必要がある。

このような要件を、簡潔にするためＬ２ＴＰを参照して例示する。しかし、本発明を他のいくつかのアプリケーションに適用できることを理解されたい。本発明をこのようなアプリケーションに関連して用いることは、本発明の範囲および精神内のものであると企図される。

Ｌ２ＴＰにおいて、トンネルを使用するすべてのＩＰパケットは、同じＩＰ宛先アドレス、すなわちＩＳＮ２５０に割り当てられたＩＰアドレスの１つを共有する。しかし、Ｌ２ＴＰは一般に、ＵＤＰプロトコル・タイプの上で実現され、ＵＤＰポート番号は、ＩＰパケットがＬ２ＴＰトンネルに関係することを識別する。さらに、ＵＤＰパケットのトンネルＩＤおよびコールＩＤフィールドが、ＩＰパケットが関係する可能性のある特定の加入者を識別することができる。処理用のプロセッサは、加入者の識別に基づいて決定されることができる。これに応じて、より高い層のプロトコル（ＵＤＰ）ヘッダまたはパケット内のさらなる情報を検査して、加入者情報を決定する必要のある場合がある。

スイッチ・ファブリック４４０が、セルを、セル・ヘッダの検査に基づいてパケット・サービス・カード４５０の１つに割り当てることを可能にするため、異なるセル・ヘッダ（または他の識別データ）を置換して、スイッチ・ファブリック４４０が、セルを、セル・ヘッダによって識別されたパケット・サービス・カード４５０に割り当て可能とすることが望ましいことがある。このような置換は、上記の例の両方で必要となることがある。より高い層のプロトコルの検査および置換をリアルタイムで実行して、大量のバッファリングを避ける必要がある。

本発明によって、個々の記憶場所のマスクを有するＣＡＭを使用した、セル・ヘッダの検査および置換が可能となる。個々の記憶場所のマスクを有するＣＡＭの動作を、概して最初に説明する。次いで、本発明を例と共に説明する。

１１．個々の記憶場所のマスクを有するＣＡＭ
個々の記憶場所のマスクを有するＣＡＭによって達成される効率を理解するため、最初に、従来のＣＡＭの動作を図７のＡを参照して説明する。図７のＡはＣＡＭ７１０を含み、これは、一般にはアクセスのためにただ１つのマスクを提供する。ＣＡＭ７１０は、図では、７２０−Ａ、７２０−ＢなどのそれぞれのＣＡＭ位置について、探索フィールド７１１および出力データ・フィールド７１５を有する。

動作する際には、入力値およびマスクがそれぞれ値バス７０１およびマスク・バス７０２で受信される。入力値およびマスクのそれぞれは、探索フィールドの長さ（探索フィールド７１１のビット数）に等しいビット数を有する。マスク・バス７０２によって指定されたビット位置における入力値が、探索フィールド７１１の対応するビットに合致した（あるいは等しい）場合、出力フィールド７１５に格納されたデータが、出力として出力バス７４９上に生成される。すなわち、マスク７０２によって指定されたビット位置におけるビットのみを比較することができる。

このように、異なるビット位置を、ＣＡＭ７１０の異なる記憶場所７２０で突き合わせる必要がある場合、複数のアクセス（それぞれが異なるマスクを有する）の対応する数だけ、実行される必要がある。

それぞれの加入者を識別するＩＰヘッダ（ＵＤＰ／ＴＣＰ／ＩＣＭＰ情報を含む）のデータを、それぞれの位置７２０に格納することができ、受信されたＩＰパケットの第１のセルのＩＰヘッダ・データを値７０１として提供できることを理解されたい。しかし、検査されるべきビット位置が、状況が異なると異なるので（たとえば、区別がＩＰ宛先アドレスのみに基づくときは、ＩＰ宛先アドレスを検査する必要があり、Ｌ２ＴＰでは、ＩＰ宛先アドレス、プロトコル・タイプ、ＵＤＰポート番号、トンネルＩＤおよびポートＩＤを検査する必要がある）、異なるマスク値を、マスク・バス７０２に提供する必要がある。

すなわち、複数のＣＡＭアクセスを実行する必要があり、各アクセスは、加入者の合致について検査されるべきビット位置を表す対応マスクを有する。このような複数のＣＡＭアクセスには、望ましくないほどの長い時間がかかることがあり、よって望ましくない。

代替の実施形態は、複数のユニットのＣＡＭ７１０を使用することができ、それぞれのＣＡＭが、加入者に特定のマスクを供給する。しかし、複数のＣＡＭは、少なくともコストを考慮すると望ましくないことがある。個々のＣＡＭ位置のマスクを有する単一のＣＡＭを使用することができ、これによって、以下に記載するように、複数のアクセスの必要性が避けられる。

図７のＢは、複数の位置（７７０−Ａ、７７０−Ｂおよび７７０−Ｃ）を有するＣＡＭ７５０のブロック図である。ＣＡＭ７５０は、入力バス７５１、探索フィールド７６１、出力フィールド７６５および出力バス７９９を含むことができ、それぞれは、図７のＡの入力バス７０１、探索フィールド７１１、出力フィールド７１５および出力バス７４９と同様のものである。さらに、ＣＡＭ７５０はマスク・フィールド７６４を有し、これは、個々の位置７７０に関連付けられたマスクを格納する。したがって、すべてのＣＡＭ位置に共通のマスクの代りに、個々のマスクを、ＣＡＭ７５０のそれぞれの位置に関連付けることができる。

動作する際には、入力値（入力ビット）が入力バス７５１に提供されるとき、対応するマスクによって指定された各ＣＡＭ位置のビット位置のみが入力ビットと比較され、合致したＣＡＭ位置の出力フィールド７６５の出力値が、出力バス７９９に提供される。出力値は、セル（またはパケット）をさらに処理するために割り当てることができるプロセッサを（直接的あるいは間接的のいずれかで）識別することができる。

こうして、異なるマスクを異なるＣＡＭ位置に使用することができる。それぞれのマスクは、比較されるべきビット位置を指定する。ビット位置は、以下で例示するように、セルを処理するプロセッサの決定において比較されるべき特定のフィールドによって決定される。

１２．ＩＰ環境に関する例示
このセクションでは、加入者（および、したがって処理用のプロセッサ）の決定に関する例示を、２つのシナリオ例において提供する。すなわち、（１）ＩＰ宛先アドレスが一意的に加入者を識別するとき、および（２）Ｌ２ＴＰの場合である。このセクションの説明では、ＩＰパケットを、対応する加入者に結びつけることができる方法を、最初に説明する。次いで、一例の実施形態においてこのような識別をセルの割り当てに使用することができる方法を説明する。

一般に、識別されるべきビット位置は、プロトコルが使用する特定のフォーマットに依存することを理解されたい。ＩＰおよびＬ２ＴＰの情報は、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）７６８、７９１および１４８３で見つけることができ、これら全体を、ここで参照により取り入れる。

シナリオ１の例に関して、合致する宛先ＩＰアドレスを、インターネット・プロトコルのバージョン４．０で求めるために、以下のビット位置（バイト境界で表し、それぞれのバイトは８ビットを有する）を検査して、以下の関係を求める必要がある。

バイト１：ＩＰバージョン番号＝４、およびヘッダ長＝２０バイト、および
バイト１７〜２０：受信パケットの宛先ＩＰアドレス＝特定の加入者に割り当てられたＩＰアドレス。

同様に、加入者データを、Ｌ２ＴＰを使用して受信したとき、以下のビット位置を検査して（すなわち、マスクにおいてアンマスクされる）、（ＩＰパケットが関係する）加入者（よって、プロセッサ）を識別する必要がある。

バイト１：上記と同じ目的
バイト１０：プロトコル・タイプ＝ＵＤＰ
バイト１７〜２０：受信パケットの宛先ＩＰアドレス＝ＩＳＮ２５０のインタフェースのＩＰアドレス

ＩＰヘッダ長が２０バイトであると仮定すると、以下のバイトが検査される。 バイト２３〜２４：宛先ＵＤＰポート番号＝Ｌ２ＴＰプロトコルのポート番号
バイト２９〜３０：Ｌ２ＴＰバージョン、長さおよびヘッダ情報
バイト３１〜３２：長さがない場合、加入者に割り当てられたトンネルＩＤ＝受信ＩＰパケットによって指定されたトンネルＩＤ
バイト３３〜３４：長さがある場合、加入者に割り当てられたトンネルＩＤ＝受信ＩＰパケットによって指定されたトンネルＩＤ
バイト３５〜３６：受信パケットのコールＩＤ＝特定の加入者に割り当てられたコールＩＤ。

こうして、一般には、それぞれの探索は、パケット・フォーマット、バージョン番号およびアプリケーション・タイプ（たとえば、Ｌ２ＴＰ）を識別するいくつかのビット位置、および、加入者に固有の他のいくつかのビット位置（たとえば、Ｌ２ＴＰの場合のコールＩＤおよび／またはトンネルＩＤ、および上記の最初の例の宛先ＩＰアドレス）の検査を必要とすることがある。すべてのビット位置が合致したとき、受信ＩＰパケットは、合致した位置に関連付けられた加入者に対応することができる。

図７のＢを参照して続けると、１つのＣＡＭ位置を各探索に割り振ることができる。たとえば、ＣＡＭ位置７７０−Ａを上記の例１のタイプの探索に割り振ることができ、ＣＡＭ位置７７０−Ｂを上記の例２のタイプの探索に割り振ることができる。ＣＡＭ位置７７０−Ａのマスク・フィールド７６４は、アンマスク（０に設定）されたバイト１、１７および１８に対応するビット位置を有することができ、残りのビットをマスク（１に設定）することができる。ＣＡＭ位置７７０−Ａの探索フィールド７６１は、ＩＰプロトコル・バージョン番号、長さを識別するデータ、および、対応するビット位置の加入者システムを識別するＩＰアドレスを含むことができる。

ＣＡＭ位置７７０−Ｂの内容を同様に説明することができる。上述のバイトに従うビット位置をアンマスクすることができる。探索フィールド７６１は、対応する位置において適切な値で設定されることができ、ここでトンネルＩＤおよび／またはコールＩＤは、一意的に加入者を識別する。

複数のプロトコル・フォーマットをサポートする必要がある場合、加入者を決定するために複数のエントリが必要になることがある。たとえば、上記の例２では、長さフィールドがない場合には、バイト３１および３２を検査するために、あるエントリを実現する必要があり、長さフィールドがある場合には、バイト３３および３４を検査するために、別のエントリを実現する必要がある。同様に、異なるバージョンのＩＰプロトコル（たとえば、ＩＰバージョン６）を加入者が潜在的に使用できる場合、より多くのエントリを実現する必要がある。一般に、ＣＡＭ７５０のエントリは探索ツリーを規定し、それぞれの葉（リーフ）によって加入者が識別される。複数の葉が、同じ加入者を識別することがある。

（ＩＰおよびより高いプロトコル・データの）ヘッダ・データが入力として入力バス７５１に提供された後、出力フィールド７６５に格納されたデータが出力として出力バス７９９に提供される。理解されるべきは、複数の加入者を識別するデータを位置７７０に格納することができ、こうして合致が１つのアクセスで検出される。

しかし、探索フィールドの幅（したがって、マスクおよび入力の幅）を少なくとも４０バイト（３２０ビット）にして、ＩＰヘッダおよびより高い層の情報を完全に検査する必要がある場合がある。個々の位置のマスクを有するＣＡＭの商用的な実施形態は、しばしば幅がこれより小さい。少なくとも幅の問題に対処するため、以下に記載するいくつかの最適化を使用することができる。

１３．最適化
一実施形態では、ＩＰヘッダが２０バイトであり、バージョン４のＩＰであると仮定すると、ＩＰパケットのバイト１、７、８、１０、１３〜１５、１７〜２０、２３、２４、および２７〜３６のみが検査される。しかし、特定のアプリケーションに応じて異なるビット位置を探索することができる。これは、関連技術分野の当業者には、本明細書で提供する説明に基づいて明らかであろう。このような探索も、本発明の範囲および精神内のものであると企図される。

上述のバイトは、関連技術分野で周知のＬ２ＴＰ、Ｌ２Ｆ、ＩＰＳＥＣなどのアプリケーションの情報を含む。探索プロセスで他のバイトを避けることによって、必要なＣＡＭ幅が２４バイト（１９２ビット）に最小化される。しかし、より小さい幅のＣＡＭで動作することが要件となることがある。以下に記載する一実施形態では、探索フィールド７６１において１１２ビット（１４バイト）のみを備えるＣＡＭを提供することができる。

このような場合、探索を、探索シーケンスに分割することができ、このシーケンスにおいて、後続の探索は、前の探索が合致したときのみ実行される。シーケンスにおいてすべての探索が合致することは、受信ＩＰパケットが、探索シーケンスが関係する加入者に関係し、ＣＡＭ出力によって指定されたプロセッサが、このＩＰパケットを処理するために使用されることを示す。

不適切な幅のＣＡＭによる動作を、Ｌ２ＴＰに関して以下で説明する。ＣＡＭは、アクセス・ポート４１０およびトランク・ポート４２０で実現することができる。例示のため、トランク・ポート４２０における実施を以下で説明する。

１４．トランク・ポート
図８は、本発明による回線の実現および動作を示すブロック図である。フレーマ（Flamer）８１０は、加入者データを受信するときに電気インタフェースを提供することができる。フレーマ８１０は、受信ビットからバイトを組み立て、組み立てたバイトを割り当て論理８５０へ提供することができる。このバイトがセル・データを構成する。スイッチ・インタフェース８８０は、セル・データを割り当て論理８５０から受信し、受信データをパケット・サービス・カード４５０へ転送する。フレーマ８１０およびスイッチ・インタフェース８８０は、既知の方法で実現されることができる。

ＩＰテーブル８６０によって、ＩＰパケットを、ソースまたは宛先ＩＰアドレスに基づいてプロセッサへ割り当てることが可能となる。具体的には、ＩＰテーブル８６０を使用することによって、本発明は、複数の加入者をサポートするのに必要なＣＡＭ位置の数を最小にすることができる。ＣＡＭのルックアップ（参照）を使用して、最初に索引を生成し、その後テーブル８６０のデータを使用して、ＩＰパケットを割り当てる特定のプロセッサ・グループをさらに決定することができる。

本発明によれば、プロセッサ・インタフェース８３０は、ＲＭＣ４６０とインタフェースを取り、それぞれの加入者に関係するデータを特定のプロセッサ・グループに割り当てることを可能にするようＣＡＭ８２０を構成することができる。プロセッサ・インタフェース８３０はさらに、ＩＰテーブル８６０およびＶＣテーブル８７０を、ＲＭＣ４６０の制御下で構成することができる。Ｌ２ＴＰタイプのプロトコルに関係するので、プロセッサ・インタフェース８３０がトンネル関係のデータ（たとえば、コールＩＤ、トンネルＩＤおよび対応するプロセッサ情報）をＲＭＣ４６０から受信し、加入者に関係するＩＰパケットを特定のプロセッサ・グループに割り当てるようＣＡＭ８２０を構成することができる。ＣＡＭ８２０、ＶＣテーブル８７０およびＩＰテーブル８６０は、ＩＳＮ２５０におけるすべてのアクセス・ポートおよびトランク・ポートによって共有されることができる。

ＶＣテーブル８７０は、ＡＴＭセルのＶＰＩ／ＶＣＩヘッダ情報の、一意的な接続識別子へのマッピングを表すデータを格納することができる。こうして、ＶＣテーブル８７０は、ＶＰＩ／ＶＣＩヘッダ・データを受信することに応答して、接続識別子を返す。ＩＰテーブル８６０およびＶＣテーブル８７０は、ＳＲＡＭなどの高速メモリを使用して実現されることができる。

ＣＡＭ８２０は、図７のＢのＣＡＭ７５０と同様のものであることができ、ＣＡＭ位置毎にマスクを有する。マスクおよび探索フィールドは、合致するエントリを迅速に識別できるよう構成される。ＣＡＭ８２０を構成する必要のある方法は、以下の説明からより明らかになるであろう。

ＣＡＭ８２０の出力は、識別子を表すことができる。識別子は、直接にプロセッサまたはプロセッサ・グループを表すことができ、またはさらなる探索のための索引としての機能を果たすことができる。本明細書に記載する実施形態では、識別子は、プロセッサ・グループまたはＩＰテーブル８６０への索引を表す。ＣＡＭ８２０の出力は、出力を索引として解釈するか、またはさらなる探索のための索引として解釈するかを指定することもできる。

割り当て論理８５０は、それぞれのＩＰパケットを、セルのシーケンスの形式で受信し、ＩＰパケットを処理するプロセッサ・グループを決定する。このような決定を行うために、割り当て論理８５０は、ヘッダの関連バイト（ＩＰヘッダ、および必要に応じて上位プロトコルのヘッダ）を、典型的には、ＩＰパケットを形成するセルのシーケンスの第１のセルから選択する。選択されたバイトは、入力としてＣＡＭ８２０へ提供される。ＣＡＭ８２０の出力は、上述のように識別子を表す。

一実施形態では、ＩＰパケットを形成するセルのすべてのシーケンスについてセル・ヘッダが修正され、修正されたヘッダは、このＩＰパケットを処理するプロセッサ（グループ）を識別する。修正されたセル・ヘッダを使用して、識別されたプロセッサ（グループ）に割り当てるパケット・サービス・カード４５０の実施形態の一例を、図９および図１０を参照して以下でより詳細に説明する。これらの図はさらに、ＣＡＭの探索フィールドの長さが十分長くないときの複数のＣＡＭ探索の使用を図示する。

１５．方法
図９は、本発明による、加入者に関係するＩＰパケットをプロセッサに割り当てることができる方法を示すフローチャートである。ステップ９１０で、それぞれのＣＡＭ位置のマスクおよび探索フィールドが構成され、マスクは、検査されるべきビット位置を指定し、探索フィールドは、加入者を識別する特定の値を（パケット・ヘッダから）指定する。上述のように、ＲＭＣ４６０およびプロセッサ・インタフェース８３０は、一実施形態においてこのような構成を実行することができる。いくつかのシナリオ例における典型的な考慮すべき事柄を、以下で説明する。

ＣＡＭ８２０のいくつかのエントリを、ＩＳＮ２５０が動作中で加入者データを処理中であるときに、動的に構成することができる。たとえば、加入者が電話線を介してダイヤルインによって接続を確立し、新規のＩＰアドレスを割り当てられたとき、ＩＰ宛先アドレスに基づいてエントリを確立することができる。

ＣＡＭ８２０の他のいくつかのエントリは、静的に構成されることができる。たとえば、複数の加入者が同じＡＴＭ仮想接続を共有し、同じアクセス・ポートに接続されているとき、それぞれの加入者が使用するＩＰアドレスが既知であるならば、ＣＡＭエントリを、ソースＩＰアドレスの検査用に構成することができる。

一実施形態では、単一のエントリは、それぞれの加入者について使用されることができ、単一の（ソースまたは宛先）ＩＰアドレスによって一意的に識別可能である。このようなそれぞれの加入者についてエントリを使用する際の１つの問題は、過度に多数の位置がＣＡＭ８２０において必要となることがある、ということである。位置の要件が大きいと、少なくともＩＳＰ環境で問題となることがある。すなわちこの場合、ＩＳＰネットワークにダイヤルインしたとき、それぞれの加入者に一意のアドレスが割り当てられることがある。本発明を用いて、ＣＡＭ８２０で必要となる位置の数を、以下でより詳細に説明するように最小にすることができる。

１つの位置を各ＩＰアドレスに割り当てる代りに、１つの位置をＩＰアドレスのグループに割り振ることができる。ＩＰパケットを処理するプロセッサを、ＩＰテーブル８６０に格納されたエントリと組み合わせて決定することができる。たとえば、ＩＰアドレスの最初の３バイトはグループを識別することができ、ＣＡＭ８２０の出力は、ＩＰテーブル８６０の基底アドレスへの索引としての機能を果たすことができる。ＩＰアドレスの最後のバイトは、基底アドレスからのオフセットとしての機能を果たすことができ、ＩＰテーブル８６０内のオフセットの位置がプロセッサ番号を含むことができる。

１つのＣＡＭ位置が、ＩＰアドレスのグループの索引を含むとき、ＣＡＭ位置のマスクを、グループ化を反映するよう選択することができる。たとえば、ＩＰアドレスの最初の３バイトはグループを表すことができ、００．００．００．ｆｆのマスクを選択することができる。したがって、ＣＡＭ探索によって、２５６個（または、サブネット・ブロードキャストのアカウントに対して２５４個）のアドレスの最初への索引が得られ、ＩＰテーブル８６０をアクセスして、受信ＩＰパケットを処理するプロセッサを求めることができる。ＩＰテーブル８６０からのプロセッサ識別子の抽出を、（ステップ９６０および９６１を参照して）以下でより詳細に説明する。

トンネリングの場合、上述のように、ＩＰバージョン番号、ヘッダの長さ、ＩＰプロトコル・タイプ（すなわち、ＵＤＰについて）、ＩＰ宛先アドレス、ＵＤＰ宛先ポート番号、Ｌ２ＴＰバージョン番号、トンネルＩＤおよびコールＩＤを検査して、ＩＰパケットを処理するプロセッサを決定することができる。トンネルおよびコールの設定中に生成された必要な情報は、ＲＭＣ４６０によって上述のように提供されることができ、適切なマスクおよび探索フィールドでＣＡＭ８２０を構成することができる。

いくつかの状況では、複数の加入者が同じトンネルを共有することがある。このような状況では、それぞれの加入者を、ＩＰアドレスによって一意的に識別することができる。ＣＡＭルックアップを最小にするため、トンネルのすべてのパケットを、単一のパケット・サービス・カード４５０に割り当てることができ、割り当てられたパケット・サービス・カード４５０のプロセッサは、トンネル・データ内で符号化されたＩＰアドレスを検査することによって、異なる加入者間を区別することができる。

ステップ９２０で、ＩＰパケットを形成するセルのシーケンスの第１のセル（「ヘッダ・セル」）を受信することができる。ＩＰパケットの最後のセルは、関連技術分野で周知のＡＡＬ５ ＡＴＭ規格にしたがって求めることができ、よって後続のセルをＩＰパケットの第１のセルとみなすことができる。

ステップ９３０で、割り当て論理８５０が、セルが受信されたポート番号、受信セルのＶＰＩおよびＶＣＩを、ＶＣテーブル８７０に送信し、接続識別子、および、さらに探索が必要かどうかを示すデータを受信することができる。さらなる探索は、典型的には、プロセッサ（グループ）への割り当ての際に、セルによって形成されたＩＰパケットをさらに検査する必要がある場合に、必要となる。

典型的には、ＶＣテーブル８７０から抽出されたデータ・ビットが、さらなる探索が必要かどうかを示す。探索が必要でない場合、ＩＰパケットのセルのヘッダを修正してスイッチ・インタフェース８８０へ渡さなくてもよい。その後、制御は、さらに探索が必要でない場合はステップ９２０へ、さらに探索が必要な場合はステップ９５０へ移る。

ステップ９５０で、割り当て論理８５０が、ＩＰパケットを形成するセルからいくつかのバイトを選択することによって、ＣＡＭ８２０の第１の入力値を構築することができる。このバイトは、ステップ９１０で格納に使用された探索フィールドおよびマスクに適合するよう選択される必要がある。典型的には、第一のセルが、入力値を構築するのに必要なすべてのデータを含む。

一実施形態では、ＩＳＮ２５０は、ＬＬＣ／ＳＮＡＰおよびＶＣ Ｍｕｘを共にサポートすることができる。一般には、ＶＣ Ｍｕｘは、単一のプロトコル（この例ではＩＰバージョン４）について設定されることができ、ＬＬＣ／ＳＮＡＰは、Ｅｔｈｅｒｔｙｐｅフィールドを指定するバイトを含む。Ｅｔｈｅｒｔｙｐｅフィールドは、ＩＰバージョン４または６、または、イーサネット・タイプの環境に共通な他のプロトコルを指定することができる。ＬＬＣ／ＳＮＡＰおよびＶＣ Ｍｕｘの本発明に適用可能な細部のみを、本明細書で提供する。２つのプロトコルのさらなる説明については、ＲＦＣ１４８３を参照することができ、これ全体をここで参照により取り入れる。

ＬＬＣ／ＳＮＡＰおよびＶＣ Ｍｕｘプロトコルに共に対応するため、一実施形態の割り当て論理８５０は、以下のバイトを第１の入力値に含めることができる。

（第１の入力値の）バイト１および２：ＬＬＣ／ＳＮＡＰのＥｔｈｅｒｔｙｐｅフィールド、またはＶＣ Ｍｕｘの場合は配慮不要
バイト３：ＩＰヘッダのバイト１
バイト４〜５：ＩＰヘッダのバイト７および８
バイト６：ＩＰヘッダのバイト１０
バイト７〜９：ＩＰヘッダのバイト１３〜１５
バイト１０〜１３：ＩＰヘッダのバイト１７〜２０
バイト１４：以下に記載の探索タイプ・フィールド

探索タイプ・フィールドは、ＣＡＭ８２０で実行中の異なるタイプの探索を指定することができる。たとえば、このフィールドは、これが第１の探索（すなわち、ステップ９５０）か第２の探索（すなわち、以下に記載するステップ９７０）かを指定することができる。このフィールドはさらに、入力ＩＰパケットがＬＬＣ／ＳＮＡＰタイプの仮想接続で受信されるか、ＶＣ Ｍｕｘタイプの仮想接続で受信されるかを指定することができる。再度、それぞれのＣＡＭ位置の探索フィールドを、入力値のフォーマットに適合するよう格納する必要があることに留意されたい。典型的には、先の第２の探索のタイプ・フィールドを、前の探索の出力から形成することができる。

再度、探索フィールド７６１のデータを、入力値のフォーマット（すなわち、選択されたバイト、およびＣＡＭに提示されるシーケンス）に適合するように格納する必要がある。シナリオの一例における入力フィールドのフォーマットは、上述の通りである。

ＣＡＭ８２０の出力をステップ９５５で検査して、合致するエントリが存在するかどうかを判断することができる。合致が検出されなかった場合、制御はステップ９５５へ移り、そこでデフォルト（省略時値）のプロセッサ・グループを選択してＩＰパケットを処理することができる。合致があった場合、制御は、以下で説明するように、ＣＡＭ８２０の出力に応じてステップ９６０、９６１、９７０および９８０の１つへ移る。

ＣＡＭ８２０の出力データは、プロセッサ（グループ）を直接的または間接的のいずれかで識別する。直接的に識別する場合は、データ自体がプロセッサ識別子を含むことができる。間接的に識別する場合は、典型的には追加の探索が必要である。ＣＡＭ出力がプロセッサ識別子を含むかどうかを指定するために、フラグを出力に含めることができる。フラグは、プロセッサをさらに決定することができる方法を特定する。

フラグが第１の値（たとえば、１）を有する場合、合致したエントリの探索は加入者のグループに対応し、これは宛先ＩＰアドレスによって識別される。したがって、ステップ９６０で、ＩＰテーブル８６０において［抽出された索引によって特定された事前指定の基底アドレス＋受信ＩＰパケットのＩＰ宛先アドレスの最後のバイト］のアドレスを有するエントリを抽出することができる。抽出されたエントリは、プロセッサ（グループ）識別子を含むことができる。

フラグが第２の値を有する場合、合致したエントリの探索は加入者のグループに対応し、これはソースＩＰアドレスによって識別される。その後、制御はステップ９６１に移る。ステップ９６１は、ステップ９６０と同様の方法で実行されるが、ソースＩＰアドレスの最後のバイト（すなわち、ビット１２０：１２７）が、抽出された索引によって識別された基底アドレスからのオフセットとして使用される。制御は、ステップ９６０および９６１からステップ９８０に移り、そこでプロセッサ識別子が、ＩＰテーブル８６０へのアクセスの結果から選択される。

フラグが第３の値を有する場合、ステップ９５０のＣＡＭ探索の探索結果が、プロセッサ識別子を含む。この可能性があるのは、たとえば、特定の専用サービスを必要とするＩＰパケットを専用プロセッサに割り当てなければならないときである。別の例は、受信ＩＰパケットがＯＳＰＦなどの経路指定プロトコルに関係するときである。ＣＡＭエントリは、ステップ９１０でこのような合致要件に適合するよう構成される必要がある。

フラグが第４の値を有する場合、制御がステップ９７５へ移り、この場合はさらにＣＡＭ８２０を探索して、プロセッサ（グループ）識別子を決定する必要がある。このさらなる探索は、Ｌ２ＴＰ、Ｌ２Ｆ、ＩＰ Ｓｅｃなどの場合に必要になることがあり、これは関連技術分野の当業者には明らかであろう。上述のように、マスクを有するＣＡＭの探索フィールドで使用可能なビット数（たとえば、１１２）が制限されているため、第２レベルの探索が必要になることがある。ＣＡＭが十分な数のビットを探索フィールドに含む場合には、スループット性能を向上させるために、複数のレベルを避けることができる。

一実施形態では、２０バイトのＩＰヘッダを仮定すると、ＣＡＭ８２０の第２の入力値が以下のフォーマットを有することがある。
（第２の入力値の）バイト１〜２：ＵＤＰ宛先ポート番号を表すバイト２３および２４
バイト３〜１３：受信セルのバイト２７〜３７
バイト１４：探索タイプ

上記探索タイプは、現在の探索が第２の探索を表すことを指定することができ、これにより、任意の不注意による合致を避けることができる。一実施形態では、第２の探索の探索タイプを、第１の探索の出力のビットから形成することができる。上で選択したフォーマットおよびバイトはＩＰ Ｓｅｃ、Ｌ２ＴＰ、Ｌ２Ｆおよび他の多数のプロトコルを探索するのに十分であり、これは関連技術分野の当業者には、本発明で提供した開示に基づいて明らかであろう。

合致するエントリがあった場合、ＣＡＭ出力がプロセッサ・グループ識別子を含むことができ、制御はステップ９８０に移る。ステップ９８０で、出力内の適切なビットを、プロセッサ・グループ識別子について選択することができる。合致するエントリが存在しなかった場合、制御はステップ９９５に移り、そこでデフォルトのプロセッサ識別子が選択される。合致しなかったＩＰパケットをすべて、デフォルトのプロセッサに送信することができる。

こうして、プロセッサ・グループ識別子は、ステップ９８０および９９５の最後に決定される。その後、制御はステップ９９０に移り、ステップ９９０は、識別されたプロセッサ・グループが、複数のＡＴＭセルの形式で受信されたＩＰパケットを実行することを保証するための手法の一例を例示する。

ステップ９９０で、ＩＰパケットを形成するすべてのＡＴＭセルのＶＣＩおよびＶＰＩフィールドが、それぞれ、接続識別子およびプロセッサ識別子によって置き換えられる。ＩＰパケットの最後のセルは、関連技術分野で周知のように、ＡＴＭ規格のＡＡＬ５に従って求めることができる。ステップ９９０で最後のセルが処理された後、制御はステップ９２０に移り、そこで後続のＩＰパケットの第１のセルが検査される。

このように、図９の方法は、効率的にＩＰパケットを事前指定のプロセッサ・グループに割り当てる手法の一例を示す。プロセッサ・グループは、ステップ９９０で上述したように、ＶＰＩフィールドによって識別することができる。上述のように、スイッチ・ファブリック４４０は、セルを、ＶＰＩフィールドによって識別されたプロセッサ・グループに転送することができる。プロセッサ・グループは、セルが関係する加入者向けの処理規則を有するので、対応する処理規則を、セル（またはセルから形成されたＩＰパケット）を処理する際に適用することができる。

こうして、ＡＴＭヘッダのＶＰＩ／ＶＣＩフィールドを置換することによって、割り当て論理８５０は、ＡＴＭセルの形式で受信されたパケットが、適切なプロセッサ・グループに送信されることを保証する。一実施形態の割り当て論理８５０を、以下でより詳細に説明する。

１６．割り当て論理
図１０は、一実施形態における割り当て論理８５０の細部を示すブロック図である。フレーマ・インタフェース１０１０は、フレーマ８１０からバイトを受信し、受信バイトをセル・メモリ１０２０に格納する。接続識別ブロック１０３０はヘッダ・バイトを受信し、ＶＰＩ／ＶＣＩデータおよびポート番号をＶＣテーブル８７０に送信する。接続識別ブロック１０３０は、ＶＣテーブル８７０が接続用のデータで事前に構成されている場合、接続識別子をＶＣテーブル８７０から受信する。接続データが事前に指定されていない場合、セルを専用の事前指定されたプロセッサ・グループに送信することができる。接続識別ブロック１０３０は、ＳＲＡＭインタフェース１０４０を使用して、ＶＣテーブル８７０とインタフェースを取ることができる。

パーサ(Parser)１０６０は、図９のフローチャートのステップ９１０を除くすべてのステップを、他の構成要素とインタフェースを取ることによって実行することができる。パーサ１０６０は、接続識別子を接続識別ブロック１０３０から受信し、ＩＰパケットのヘッダ・データをセル・メモリ１０２０から受信して、プロセッサ・グループ識別子を決定する。パーサ１０６０は、ＣＡＭインタフェース１０８０を通じてＣＡＭ８２０とインタフェースを取ることができ、ＳＲＡＭインタフェース１０４０を通じてＩＰテーブル８６０とインタフェースを取ることができる。

抽出されたデータを使用し、置換が必要なときには、パーサ１０６０は、セルのＶＰＩ／ＶＣＩを決定することができる。パーサ１０６０は、新規の値をセル・メモリ１０２０に格納して、新規のＶＰＩ／ＶＣＩ値を置換することができる。セル・メモリ１０２０は、パーサ１０６０が新規のＶＰＩ／ＶＣＩデータを決定する間の十分な時間中にセルをバッファに入れるために、十分な格納スペースを含む必要がある。セル・メモリ１０２０からのデータは、スイッチ・インタフェース８８０に送信される。

こうして、セルのＶＣＩフィールドをプロセッサ識別子と置換することによって、パーサ１０６０で、スイッチ・ファブリック４４０が、ＩＰパケットを処理するのに適切なプロセッサ・グループに、セルを迅速に転送可能にすることが可能となる。すなわち、スイッチ・ファブリック４４０は、加入者データを特定のプロセッサ（グループ）に割り当てるために、セル・ヘッダ（少数のビット）を検査するだけでよい。プロセッサ・グループは、対応する加入者に固有のサービス・ポリシーを提供するよう構成されることができる。

本発明を、異なるサービス・ポリシーを提供するために、データを異なるプロセッサ・グループに割り当てることとして説明したが、本発明を他のいくつかの実施形態で実現されることは明らかであろう。これは、関連技術分野の当業者には、本明細書で提供した開示に基づいて明らかであろう。このような他の実施形態は、本発明の範囲および精神内のものであると企図される。

上述の図８〜図１０の実施形態が、図１のステップ１４０および１５０を実現するための手法例のみを例示することに留意されたい。他のいくつかの実施形態を、本発明の範囲および精神から外れることなく実現することができ、これは、関連技術分野の当業者には、本明細書で提供した開示に基づいて明らかであろう。このような他の実施形態も、本発明の範囲および精神内のものであると企図される。

１７．結論
本発明の様々な実施形態を以上で説明したが、これらは例としてのみ提示されたものであり、限定するものではないことを理解されたい。したがって、本発明の範囲は、上述の実施形態のいずれによっても限定されるべきではなく、特許請求の範囲およびそれらの均等物に従ってのみ定義されるべきである。

Claims (44)

1. 所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法であって、
   それぞれの加入者が所望するサービス・ポリシーのセットを提供する複数の処理規則を識別するステップと、
   前記それぞれの加入者に対応する前記処理規則を持ち、該処理規則が前記アクセス・ネットワークの一つのエッジから制御されるアクセス・ネットワークのエッジ装置として一つのインターネット・サービス・ノードを構成するステップと、
   前記インターネット・サービス・ノードでデータを受信するステップと、
   前記インターネット・サービス・ノードにおいて前記受信データが関係する特定の加入者を判定するステップと、
   前記インターネット・サービス・ノードにおいて、前記判定した特定の加入者に関係する前記複数の処理規則を適用するステップと、を含み、
   前記適用するステップが、前記決定するステップの後に実行される、前記方法。
2. 所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法であって、
   それぞれの加入者が所望するサービス・ポリシーのセットを提供する複数の処理規則を識別するステップと、
   前記それぞれの加入者に対応する前記処理規則を持つインターネット・サービス・ノードをエッジ装置として構成するステップと、
   前記インターネット・サービス・ノードでデータを受信するステップと、
   前記インターネット・サービス・ノードにおいて前記受信データが関係する特定の加入者を判定するステップと、
   前記インターネット・サービス・ノードにおいて、前記判定した特定の加入者に関係する前記複数の処理規則を適用するステップと、
   を含む、前記方法。
3. 前記複数の処理規則を適用するステップが、前記決定するステップの後に実行される、請求項２に記載の方法。
4. 所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法であって、
   それぞれの加入者が所望するサービス・ポリシーのセットを提供する複数の処理規則を識別するステップと、
   前記それぞれの加入者に対応する前記処理規則を持つインターネット・サービス・ノードを、複数のプロセッサで構成するステップと、
   前記インターネット・サービス・ノードでデータを受信するステップと、
   前記インターネット・サービス・ノードにおいて前記受信データが関係する特定の加入者を判定するステップと、
   前記インターネット・サービス・ノードにおいて、前記判定した特定の加入者に関係する前記複数の処理規則を適用するステップと、を含み、該適用するステップは、
   前記複数の加入者のそれぞれをプロセッサ・グループに割り当てるステップであって、各プロセッサ・グループは、割り当てられた加入者に対応する前記処理規則で構成されているステップと、
   各加入者に関係するデータを、特定の加入者の前記判定の後に、対応するプロセッサ・グループに送るステップと、を含む、
   前記方法。
5. それぞれのプロセッサ・グループが、複数のプロセッサを備える請求項４に記載の方法。
6. 前記プロセッサ・グループに割り当てられた加入者に関係するデータが、前記複数のプロセッサの間でラウンド・ロビン方式で割り当てられる請求項４に記載の方法。
7. 前記複数の加入者のエンド・システムが、インターネット・プロトコル（ＩＰ）を使用してデータを生成する請求項４に記載の方法。
8. 前記データがＡＴＭセルを含む、請求項７に記載の方法。
9. 前記判定するステップが、前記ＡＴＭセルに含まれるデータを検査するステップを含み、
   前記特定の加入者の判定が、前記検査の結果と、前記ＡＴＭセルが受信されるポートとに基づいて行われ、
   前記ポートが、前記インターネット・サービス・ノードに含まれる請求項８に記載の方法。
10. 前記適用するステップが、
    前記ポートにおいて、前記データを転送すべき特定のプロセッサ・グループを決定するステップであって、該特定のプロセッサ・グループを、前記受信データが関係する前記特定の加入者に基づいて決定するステップと、
    前記ＡＴＭセルが、そのヘッダの検査に基づいて適切なプロセッサ・グループに転送されるように、前記決定されたプロセッサ・グループを示すよう前記ＡＴＭセルのヘッダを修正するステップを含み、
    前記適切なプロセッサ・グループが、前記特定の加入者に関係する前記処理規則で構成されている、請求項９に記載の方法。
11. 前記決定するステップは、連想記憶装置（ＣＡＭ）を使用して実行され、
    前記ＣＡＭは複数の位置を含み、該複数の位置のそれぞれは、マスク、探索フィールドおよび出力フィールドを有しており、
    前記ＣＡＭは、入力値を受信して、該入力値を、前記複数の位置のそれぞれの前記マスクによって指定されたビット位置での前記探索フィールド内のデータと比較するよう設計されており、
    前記ＣＡＭは、対応する位置で合致があるならば、前記出力フィールドに格納されたデータを出力として生成するよう設計されている、請求項１０に記載の方法。
12. 前記ＣＡＭの出力フィールドに格納されたデータが、プロセッサ・グループの識別子を直接的または間接的に特定し、該出力フィールドに格納されたデータを使用して前記識別子を求めることができるように、前記マスクおよび探索フィールドのそれぞれの入力が、加入者を識別するデータを格納するよう行われる、請求項１１に記載の方法。
13. 前記ＡＴＭセルを、前記ヘッダを検査することによって前記加入者に関係するデータを処理するように設計されたプロセッサ・グループに割り当てることができるように、前記ＡＴＭセルのヘッダの一部が、前記識別子と置換される請求項１２に記載の方法。
14. 前記識別子が、前記ヘッダの仮想パス識別子（ＶＰＩ）または仮想チャネル識別子（ＶＣＩ）フィールドに格納される請求項１３に記載の方法。
15. 前記ＡＴＭセルの前記ヘッダの検査に基づいて、スイッチ・ファブリックが前記データを前記プロセッサ・グループに送る、請求項１３に記載の方法。
16. 仮想パス識別子／仮想チャネル識別子（ＶＰＩ／ＶＣＩ）およびポート番号の接続識別子へのマッピングを、仮想チャネル（ＶＣ）テーブルに格納するステップを含み、前記ＶＣテーブルのそれぞれのエントリは、受信セルのＶＰＩ／ＶＣＩを置換する必要があるかどうかを示しており、
    前記受信データ内に構成されている受信セルに対応する前記ＶＣテーブルのエントリにアクセスするステップを含み、
    前記エントリ内のデータが、前記ＶＰＩ／ＶＣＩフィールドが置換される必要があることを示していれば、前記受信セルの前記ヘッダが修正される、請求項１３に記載の方法。
17. 前記受信データを形成するＶＣＩセルを、前記接続識別子に設定するステップと、
    前記ＣＡＭの前記出力を使用して、プロセッサ識別子またはプロセッサ・グループ識別子を生成するステップと、
    前記ＡＴＭセルのシーケンスの前記ＶＰＩを、前記プロセッサ識別子または前記プロセッサ・グループ識別子に設定するステップと、を含み、
    前記スイッチ・ファブリックが前記ＶＰＩを使用して、前記ＡＴＭセルのシーケンスを前記プロセッサの１つに転送する請求項１６に記載の方法。
18. ＩＰヘッダのバイト１、７、８、１０、および１３〜２０が、前記入力として前記ＣＡＭに提供される請求項１２に記載の方法。
19. ＩＰアドレスに対応する少なくともいくつかのビット位置を検査するため、前記位置のマスクを設定し、前記位置の探索フィールドを前記マスクと組み合わせて複数のＩＰアドレスに設定するステップを含み、
    少なくともいくつかの前記ＩＰアドレスが前記加入者に関連付けられる、請求項１２に記載の方法。
20. 前記ＩＰアドレスのそれぞれが、ＩＰソース・アドレスを含む請求項１９に記載の所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法。
21. 前記ＩＰアドレスのそれぞれが、ＩＰ宛先アドレスを含む請求項１９に記載の所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法。
22. 前記複数のＩＰアドレスのそれぞれを、プロセッサ識別子またはプロセッサ・グループ識別子にマッピングするＩＰテーブルを維持するステップと、
    前記ＩＰパケットのＩＰアドレスのマスクされたビット位置のビット、および前記ＣＡＭの出力を使用して、前記プロセッサ識別子または前記プロセッサ・グループ識別子を抽出するステップと、を含み、
    前記ＡＴＭセルのシーケンスが、前記プロセッサ識別子によって識別されたプロセッサ、または前記プロセッサ・グループ識別子によって識別された前記プロセッサ・グループに割り当てられる請求項１９に記載の方法。
23. 前記探索フィールドが、前記加入者を識別するデータを格納するのに十分な数のビットを含んでおらず、前記方法が、
    前記ＣＡＭの複数のエントリに前記加入者を識別するデータを格納するステップを含み、
    前記複数のエントリの出力が、前記プロセッサ識別子またはプロセッサ・グループ識別子を判定するときに検査される、請求項１２に記載の方法。
24. 前記複数のエントリの１つの出力が、前記ＣＡＭの複数のエントリの他の１つの入力として使用され、前記複数のエントリの該他の１つの出力が、前記プロセッサ識別子またはプロセッサ・グループ識別子を識別する請求項２３に記載の所望の方法。
25. 前記加入者に関係する受信データが、Ｌ２ＴＰトンネルを使用して受信される請求項２３に記載の方法。
26. 前記受信データの第１のセルに含まれるＩＰパケットのバイト１、７、８、１０、１３〜１５、および１７〜２０を、第１の入力として提供するステップと、
    前記第１のセルに含まれるＩＰパケットのバイト２３、２４、および２７〜３７を、第２の入力として提供するステップを含む、請求項２５に記載の方法。
27. 所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供する方法であって、
    （ａ）インターネット・サービス・ノード（ＩＳＮ）をエッジ・ルータとして提供するステップと、
    （ｂ）前記複数の加入者のそれぞれについて所望のサービス・ポリシーのセットを指定するステップと、
    （ｃ）前記所望のサービス・ポリシーのそれぞれを処理規則に変換するステップであって、前記処理規則は、分類子および関連するアクションを含み、該分類子は、該関連するアクションを適用するデータ・フローを識別する、ステップと、
    （ｄ）前記ＩＳＮを前記処理規則で構成するステップと、
    （ｅ）複数のビット・グループを、前記複数の加入者に含まれる加入者から受信するステップと、
    （ｆ）複数のパケットを、前記複数のビット・グループに含まれるデータから生成するステップであって、前記複数のパケットのそれぞれは、前記加入者のアプリケーションによって生成されたデータ・フローに関連付けられることができる、ステップと、
    （ｇ）前記複数のパケットのそれぞれが関係するデータ・フローを求めるステップと、
    （ｈ）前記ステップ（ｇ）において求められたデータ・フローに合致する分類子に関連付けられた前記アクションを適用するステップと、を含み、
    前記複数の加入者のそれぞれに、前記対応する所望のサービス・ポリシーのセットが提供されるようにする、方法。
28. 前記複数の加入者のエンド・システムが、インターネット・プロトコル（ＩＰ）を使用してデータを生成し、前記ステップ（ｆ）が、複数のＩＰパケットを生成することを含む、請求項２７に記載の方法。
29. 前記ビット・グループがＡＴＭセルを含み、前記複数のパケットが、該ＡＴＭセルから生成される請求項２８に記載の方法。
30. 前記複数のサービス・ポリシーの１つの状態を維持するステップを含み、前記状態によって複数のデータ・フローを前記サービスを満たすように処理することができる、請求項２８に記載の方法。
31. 前記データ・フローのそれぞれの状態を維持するステップを含み、それぞれのフローのパケットに適用されるべき処理規則が、前記状態で維持される、請求項２８に記載の方法。
32. （ｉ）アプリケーションの制御データ・フローを監視して、アプリケーションによって起動された新規のデータ・フローのポート番号を求めるステップと、
    （ｊ）新規の処理規則を、前記求めたポート番号を使用して生成するステップと、を含む、
    請求項２８に記載の方法。
33. （ｋ）それぞれが複数のプロセッサを含む複数のプロセッサ・グループを提供するステップと、
    （ｌ）前記パケットのそれぞれを前記複数のプロセッサ・グループの１つに割り当てるステップと、を含み、
    前記割り当てられたグループの前記複数のプロセッサの１つが、前記割り当てられたパケットを処理する、請求項２７に記載の方法。
34. 加入者に関係するすべてのパケットが、１つのプロセッサ・グループに割り当てられる請求項３３に記載の方法。
35. パケットを、個々のプロセッサにラウンド・ロビン方式で割り当てるステップを含む請求項３４に記載の方法。
36. 所望のサービス・ポリシーのセットを複数の加入者のそれぞれに提供するインターネット・サービス・ノード（ＩＳＮ）であって、
    それぞれの加入者が所望するサービス・ポリシーのセットを提供する複数の処理規則を識別する識別手段と、
    インターネット・サービス・ノードを、前記加入者のそれぞれに対応する処理規則で構成する構成手段であって、該インターネット・サービス・ノードが、アクセス・ネットワークのエッジ装置として提供され、前記サービス規則の呼び出しが前記アクセス・ネットワークのエッジから制御される、構成手段と、
    前記インターネット・サービス・ノードでデータを受信する受信手段と、
    前記インターネット・サービス・ノードで、前記受信データが関係する特定の加入者を判定する判定手段と、
    前記インターネット・サービス・ノードで、前記判定した特定の加入者に関係する前記複数の処理規則を適用する適用手段と、を備え、
    前記適用が前記判定の後に実行されるようにしたインターネット・サービス・ノード。
37. 前記ＩＳＮが複数のプロセッサを備え、前記判定手段および適用手段が共に、
    前記加入者のそれぞれをプロセッサ・グループに割り当て、それぞれのプロセッサ・グループは、割り当てられた加入者に対応する処理規則で構成される、割り当て手段と、
    それぞれの加入者に関係するデータを、前記特定の加入者の判定の後に、対応するプロセッサ・グループに転送する転送手段と、
    を備える、請求項３６に記載のインターネット・サービス・ノード。
38. 前記複数の加入者のエンド・システムが、インターネット・プロトコル（ＩＰ）を使用してデータを生成する、請求項３７に記載のインターネット・サービス・ノード。
39. 前記データがＡＴＭセルからなる、請求項３８に記載のインターネット・サービス・ノード。
40. 前記割り当て手段が、前記ＡＴＭセルに含まれるデータを検査する検査手段を備え、前記特定の加入者の判定が、前記検査の結果、および前記ＡＴＭセルが受信されるポートに基づいて行われ、前記ポートが、前記インターネット・サービス・ノードに含まれる請求項３９に記載のインターネット・サービス・ノード。
41. 前記割り当て手段は、セル・ヘッダの検査に基づいて前記セルを適切なプロセッサ・グループに転送できるように、前記セルのヘッダを修正して前記決定したプロセッサ・グループを示すようにする修正手段を備えており、 前記適切なプロセッサ・グループが、前記特定の加入者に関係する処理規則で構成される、請求項４０に記載のインターネット・サービス・ノード。
42. 加入者のためのサービス・ポリシーを指定するステップと、
    前記サービス・ポリシーを処理規則に変換するステップであって、該処理規則のそれぞれが分類法およびアクションを含み、該分類法はデータ・フローを識別し、該アクションはポリーシング・サービス・ポリシーを実行し、該分類法はポリーシング・サービス・ポリシーが適用される１日の時間を示すフィールドを持つ、ステップと、
    前記処理規則に従って入ってくるデータを処理するステップと、
    を含む、方法。
43. 前記変換するステップは、前記処理規則のそれぞれのポリーシング・サービス・ポリシーの一部として、利用可能な帯域幅に優先順位をつけることを含む、請求項４２に記載の方法。
44. 前記変換するステップは、前記処理規則のそれぞれのポリーシング・サービス・ポリシーの一部として、利用可能な帯域幅を割り当てるための割り当てポリシーを指定することを含む、請求項４２に記載の方法。

Images