JP2004515179A - 分散されたネットワークアクセスシステムのためのプログラム可能なアクセス装置 - Google Patents

Abstract

ネットワークアクセスシステムにおいて使用されるプログラム可能なアクセス装置は、パケットがネットワークと通信するための第一および第二ネットワークインターフェイスと、第一および第二ネットワークインターフェイス間で通信されるパケットの経路を選択するために使用する転送テーブルと、パケットヘッダーフィルタとを含む。パケットヘッダーフィルタは、ポリシーに基づくサービスが実行される、第一および第二ネットワークインターフェイスの一方で受信したメッセージを特定し、特定されたメッセージをメッセージインターフェイスを介して処理のために外部プロセッサに渡す。好ましい実施例において、パケットヘッダーフィルタは、レイヤ３よりも高いプロトコルレイヤに関連するプロトコル情報に基づいてサービス処理のためのパケットのフィルタ処理が可能である。好ましい実施例においては、プログラム可能なアクセス装置は、セッション活性レベルのようなイベントを外部プロセッサに報告する使用モニタ、プログラムされたトラフィックパラメータを参照してパケットを取り締まるポリサおよびサービスクラスの複数の質をサポートするために発信パケットの送信を予定するスケジューラを含んでもよい。

Description

【０００１】
【発明の背景】
【０００２】
【技術分野】
この発明は一般に通信ネットワークに関し、特に、ＩＰを中心にした通信ネットワークに関する。より特定的には、この発明は分散され、分離されたルーティング（ｒｏｕｔｉｎｇ）、信号送信、サービス制御、フィルタ処理、ポリシー制御およびＩＰ転送からの他の機能を有するネットワークアクセスシステムを有するＩＰに基づく通信ネットワークに関する。
【０００３】
【関連技術の説明】
インターネットは、起点と１またはそれ以上の目的地の間でデータパケットが通信するために、全てがＴＣＰ／ＩＰ（Ｔｒａｎｓｐｏｒｔ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）の組を用いている、異質な通信ネットワーク、関連するゲートウエイ、ブリッジおよびルータの世界的規模の収集物であると一般に定義される。当業者によく知られているように、ＴＣＰ／ＩＰプロトコルの組は国際標準化機関の開放型システム間結合（ＩＳＯ／ＯＳＩ）の参照モデルのレイヤ３および４（ネットワーク層およびトランスポートレイヤ層）に対応する。ＯＳＩ参照レベルは通信プロトコルを明確にするための便利なフレームワークを提供している。ＩＳＯ／ＯＳＩ参照モデルはさらに、ネットワークおよびトランスポート層の下に物理層およびリンク層（それぞれレイヤ１および２）を、またネットワークおよびトランスポート層の上にセッション層、プレゼンテーション層およびアプリケーション層（それぞれレイヤ５から７）を含む。
【０００４】
図１Ａは顧客がインターネットにアクセスすることができる、インターネットサービスプロバイダ（ＩＳＰ）ネットワーク１０の都市レベルの一覧を例示する。左手側から始まって、多くの顧客のローカルエリアネットワーク（ＬＡＮ）１４が各種の都市アクセスネットワーク１６を介してＩＳＰネットワーク１０にインターフェイスされている。都市規模のアクセスネットワーク１６は多数のリングを有する任意の多くのネットワーク技術を採用している。例えば、時分割多重方式（ＴＤＭ）、非同時転送モード（ＡＴＭ）およびイーサネットである。さらに、大きな都市規模のエリアにおいて典型的であるが、都市規模のアクセスネットワーク１６には多数のリングを有する多数の階層のレベルがあり、多数のリングは各顧客を集合サイトおよび多数の最も低いレベルの集合サイトに接続して、高いレベルの集合サイトに供給する。典型的には、都市エリアにおいて集合ルータ１２が配置された集合サイトはほんの少数かもしれない。図１Ａはただひとつのそのような集合サイト１７を示している。ＬＡＮ１４からのすべてのトラフィックはこれらの集合ネットワークを介してこの集合サイト１７へ逆送され、この集合サイト１７では、集合ルータ１２が取り締まり、マーク付けおよび許可制御のようなポリシー主導処理を適用している。集合ルータはそれからトラフィックを別の顧客ＬＡＮ１４に戻すかまたはあるより遠い目的地へ向けてコア２０を通って送信するためにコアルータ１８に経路を選択する。
【０００５】
図１Ａに示すように、ルータデザインにおける最新技術がだいたいにおいてネットワークデザインに影響を与える。というのは、ルータは高価であり、高度に集合したトラフィックフロー状態で動作されなければならないからである。そのようなネットワークの設計における主な考慮は、ルーティングプロトコルが効率的に拡張するようにルータの数を最小にする点に払われる。これは、ルーティング、データベース格納およびポリシーの執行等の多くの機能がこれらのルータに集中されることを意味する。
【０００６】
先行技術において、ルータの構造は一般に融通がきかず、独自性が強いものであった。結局基本的なパケットルーティングに加えてサービスプロバイダが提供できるデータサービスの範囲はルータ供給メーカによって提供された制御ソフトウエアによって限定される。加えて、ルータのパケット処理能力はもともとインストールされた処理ハードウエアによって一般に限定され、ルータ全体を交換することなく拡張または拡大されることはなかった。従来のルータの融通のきかなさおよび独自性の強さがこの発明によって手当てされる多くの問題を提起している。
【０００７】
第一に、ルータは伝統的にすべてのメッセージタイプのためにすべてのサービスを提供する単一のコントローラを有しているため、エッジルータコントローラは非常に複雑になる傾向があり、現存のサービスに対して新しいサービスを加えたり修正したりすることが困難でかつ高価である。その結果、新しいルータに基づくサービスを市場に出すまでの時間が長くかかり、かつサービスプロバイダの要求に応答する供給メーカに依存して、メーカの独自性の強いルータ構造内で新しいサービスを実行するのが常であった。
【０００８】
第二に、従来の融通のきかないルータ構造は拡張性が十分でなく、サービスプロバイダに対して重要な問題を提起していた。特に、インターネットトラフィックの驚異的な成長に照らして重要な問題を提起していた。その結果、配備されたルータの処理能力は増加するトラフィックに対応して容易に拡張できない。代わりに、サービスプロバイダは増加するトラフィックの要求に合わせるために追加のルータを購入したり、ルータを交換しなければならなかった。
【０００９】
第三に、従来の融通の利かないルータ設計は柔軟性および拡張性に限界があった。例えば、この発明はインターネットトラフィックの急速な成長にかんがみて、ＩＰベースのサービスに対してアクセス能力をダイナミックに提供し、改造しおよび／またはアクセス能力を再割り当てすることが望ましいと認識する。アクセス能力は必然的に限定され、追加のアクセス能力を提供することはネットワークの大きなコスト要素であるため、インテリジェントな許可制御ポリシーの執行および質を変えたサービスの提供は利用可能なアクセス能力の効率のよい使用のためにはきわめて重要である。しかしながら、従来のエッジルータはポリシー制御を執行しながらトラフィック形式の幅広い種類の分類ができず、能力に対するダイナミックな要求に答えることもできず、この機能性は現在採用されている融通のきかないエッジルータ内に組み込むことが困難である。従って、この発明は商品化されたハードウエアの下で、上記および追加のポリシー制御、ネットワークモニタ、診断およびセキュリテイサービスを提供し、一方でこれらのサービスを個々の顧客およびサービスプロバイダのニーズに合うように調整することを許容することが望ましいということを認識する。
【００１０】
第四に、ルータ構造およびサービスの独自性の強さのために、もしサービスプロバイダが通信ネットワークにおいて複数の供給メーカからルータを配備すると、異なるルータ供給者によって実行される独自性の強いサービスは必ずしも相互間で動作しない。その結果、サービスプロバイダは一つの供給者からルータおよびスイッチを購入することができず、サービス制御ソフトウエアを他の供給者から購入する。さらに、サービスプロバイダは既存のベースネットワーク能力を利用して付加価値データサービスを提供するために大規模なプロバイダに対してその通信ネットワークを提供できない。
【００１１】
先行技術における、上記および追加の欠点にかんがみて、この発明は従来の融通のきかないルータ構造の限界に対処しかつ克服する新しいネットワークアクセスを導入することが望ましいということを認識する。
【００１２】
【発明の要約】
この発明はプログラム可能なアクセス装置を含む分散されたネットワークアクセスシステム構造を導入する。
【００１３】
プログラム可能なアクセス装置はパケットがネットワークと通信するための第一および第二のネットワークインターフェイスと、第一および第二のネットワークインターフェイス間で通信されるパケットのルーティングに使用する転送テーブルとパケットヘッダーフィルタとを含む。パケットヘッダーフィルタは規格に基づいたサービスが実行される第一および第二ネットワークインターフェイスの一つで受け取ったメッセージを特定し、特定されたメッセージをメッセージインターフェイスを介して処理のために外部プロセッサに渡す。好ましい実施例では、パケットヘッダーフィルタはレイヤ（ｌａｙｅｒ）３よりも高いプロトコルレイヤに関連するプロトコル情報に基づいてサービス処理のためのパケットをフィルタ処理することができる。好ましい実施例では、プログラム可能なアクセス装置は、セッション活動レベルのようなイベントを外部プロセッサに報告する使用モニタと、プログラムされたトラフィックパラメータを参照することによってパケットを取り締まるポリサ（ｐｏｌｉｃｅｒ）と、サービスクラスの複数の質をサポートするために、発信パケットの送信を予定するスケジューラとを含んでもよい。
【００１４】
プログラム可能なアクセス装置に加えて、分散されたネットワークアクセスシステム構造は、好ましくは外部プロセッサとアクセスルータとを含む。このように、この発明によれば、従来の融通のきかない、独自性の強いエッジルータは３つの論理モジュール、すなわちプログラム可能なアクセス装置、外部プロセッサおよびアクセスルータの間で、（追加の機能性に加えて）従来のエッジルータの機能性を割り当てる、分散されたネットワークアクセスシステムと置き換えられる。この発明の好ましい実施例によれば、アクセスネットワークの入出力ポート間のパケットの基本的なルーティングはアクセスルータのよって実行される。しかしながら、転送および、マーク付け（ｍａｒｋｉｎｇ）、取り締まり（ｐｏｌｉｃｉｎｇ）、モニタ（ｍｏｎｉｔｏｒｉｎｇ）、シェイピング（ｓｈａｐｉｎｇ）およびフィルタ処理（ｆｉｌｔｅｒｉｎｇ）のような一般のトラフィック調整機能は、プログラム可能なアクセス装置において実行され、メッセージ解釈、信号送信、許可制御およびポリシー実施のようなサービス機能は外部プロセッサにおいて実行される。以下に詳細を示すように、この機能性の分散は、改良された拡張性、柔軟性、拡大性、相互操作性、セキュリテイおよびサービス提供を含む多くの利点を結果としてもたらす。
【００１５】
この発明の追加の目的、特徴、利点は以下の詳細な記載から明らかになるであろう。
【００１６】
【好ましい実施例の詳細な説明】
発明の特徴であると考えられる新規な特徴は添付のクレームにおいて述べられる。しかしながら、発明自身、および使用の好ましいモード、さらなる目的およびその利点は、添付された図面と共に読まれたとき例示的な実施例の以下の詳細な記述を参照して最もよく理解されるであろう。
【００１７】
分散されたネットワークアクセスシステム構造
図面を再び参照して、特に図２を参照して、この発明に従う分散されたネットワークアクセスシステム３１を有する通信ネットワーク３０の一部の高レベルのブロック図が示されている。例示されているように、通信ネットワーク３０はアクセスライン３４によって（顧客ルータ３２によってその一つが表わされる）多くの顧客の装置に接続されてもよい。図１にあるように、アクセスライン３４は、イーサネット、ＳＯＮＥＴ、ＡＴＭおよびフレームリレー（ｆｒａｍｅ ｒｅｌａｙ）のような一般に使用される転送ネットワークの多くの任意のものを使用してもよく、例示されていない集合体ハードウエアをさらに含んでもよい。
【００１８】
従来のネットワークと同様に、通信ネットワーク３０は１またはそれ以上のコアルータ３６に接続された１またはそれ以上のコア通信リンク３８（例えばトランクリンク）を含む。しかしながら、図１に例示されているような従来の通信ネットワークと対照的に、顧客ルータ３２は融通のきかない、独自性の強いエッジルータを介して通信ネットワーク３０にインターフェイスを介して接続していない。代わりに、顧客ルータ３２のような顧客装置は、プログラム可能なアクセス装置（ＰＡＤ）４０、外部プロセッサ４２およびアクセスルータ４４からなる、３つの論理モジュール間で（追加の機能性のみならず）、従来のエッジルータの機能を分散するネットワークアクセスシステム３１を介し、通信ネットワーク３０にインターフェイスを介して接続されている。この発明の好ましい実施例によれば、アクセスネットワークの入出力ポート間のパケットの基本的なルーティングは外部ゲートウエイプロトコル（Ｅｘｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）（ＥＧＰ）および内部ゲートウエイプロトコル（Ｉｎｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ）（ＩＧＰ）ルーティングテーブル５２および５４によって決定され、転送テーブル５０を参照することによってアクセスルータ４４によって実行される。しかしながら、転送および、マーク付け、取り締まり、モニタ、シェイピングおよびフィルタ処理のような一般的トラフィック調整機能は、ＰＡＤ４０によって実行され、メッセージ解釈、信号送信、許可制御および取り締まり実施のようなサービス機能は外部プロセッサ４２によって実行される。この機能の分散が与えられると、着信および発信パケットは、ＰＡＤ４０、アクセスルータ４４およびコアルータ３６（および、ＡＴＭまたはＭＰＬＳスイッチ６０のような選択的に追加されるアクセスネットワークのスイッチ）を介してコア通信リンク３８と顧客ルータ３２との間で典型的に通信が行われる。しかしながら、もし、ＰＡＤ４０のフィルタ処理機能が追加のサービスを要求しているパケットの流れを検出したとき、ＰＡＤ４０は適切なメッセージをメッセージ報告およびコントロールインターフェイス（Ｍｅｓｓａｇｅ Ｒｅｐｏｒｔｉｎｇ， ａｎｄ Ｃｏｎｔｒｏｌ Ｉｎｔｅｒｆａｃｅ）（ＭＣＲＩ）５８を介してサービス処理のために、外部プロセッサ４２に送り、これはＰＡＤ４０と外部プロセッサ４２上でアプリケーションプログラミングインターフェイス（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）（ＡＰＩ）を介してアクセスされうる。アクセスルータ４４、ＰＡＤ４０および外部プロセッサ４２間の分散機能性はこのようにして、サービスプロバイダ（または第三者）に、ＰＡＤ４０の転送動作やアクセスルータ４４のルーティング動作または機能性に影響を与えることなく、既存のサービスを拡張および修正し、新しいサービスを創造し、または外部プロセッサ４２により大きな処理能力を加える自由を提供する。
【００１９】
ＰＡＤ４０および外部プロセッサ４２のための所望の機能性を実行するために、サービスプロバイダ（または顧客または第三者）は１またはそれ以上のポリシーサーバ４８（またポリシー決定点（ＰＤＰ）として呼ばれる）のポリシーデータベース４６内にポリシー規則を定義することができる。ポリシーサーバ４８はそれからポリシーデータベース４６内に格納されたポリシー規則を参照して、ＰＡＤ４０および外部プロセッサ４２の機能性および動作を制御するポリシー決定を行う。ポリシーサーバ４８は外部プロセッサ４２および／またはＰＡＤ４０のためのポリシー決定および関連した設定パラメータをサービスポリシーインターフェイス（Ｓｅｒｖｉｃｅ Ｐｏｌｉｃｙ Ｉｎｔｅｒｆａｃｅ）（ＳＰＩ）５６を介して外部プロセッサ４２に連絡する。サービスポリシーインターフェイス（ＳＰＩ）５６は例えばポリシーサーバ４８および外部プロセッサ４２上のＡＰＩを介してアクセスされうる。ＳＰＩ５６を介した通信は共通オープンポリシーサービス（Ｃｏｍｍｏｎ Ｏｐｅｎ Ｐｏｌｉｃｙ Ｓｅｒｖｉｃｅ）（ＣＯＰＳ）およびライトウエイトディレクトリアクセスプロトコル（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（ＬＤＡＰ）を含む多くのポリシー問い合わせプロトコルの任意のものを使用できる。これらはそれぞれインターネットエンジニアリングタスクフォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）（ＩＥＴＦ）ＲＦＣｓ２７４８および２２５１によって定義されており、ここに参照により引用する。外部プロセッサ４２はもしあれば、ＰＡＤ４０のための設定パラメータをＭＣＲＩ５８を介してＰＡＤ４０に伝達する。
【００２０】
以下にさらに述べるように、ネットワークアクセスシステム３１は、サービスプロバイダ（または第三者であっても）に、機能性をサポートするためにサービスコントローラを開発し、外部プロセッサ４２にサービスコントローラをインストールすることによって外部プロセッサ４２に追加の機能性を持たせることを許可する。追加の機能性はＮＭＳ（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）（ネットワーク管理システム）７２を使用してネットワークアクセスシステム３１で実行されうる。ネットワーク管理システムははＯＳＳ（Ｏｐｅｒａｔｉｏｎ ａｎｄ Ｓｕｐｐｏｒｔ Ｓｙｓｔｅｍ）（オペレーションおよびサポートシステム）とも呼ばれる。ＮＭＳ７２はインターフェイス７３−７７を介してネットワークアクセスシステム３１の要素の各々をモニタし、制御し、アラームを報告しかつ設定する（例えばＩＰアドレスを割り当てる）。ＮＭＳ７２は、例えば、外部プロセッサ４２におけるサービスコントローラからのメッセージに応答して、適切な顧客に対するサービスコストを割り当てる、請求書作成および経理装置を好ましくは含む。
【００２１】
図２にさらに例示するように、この発明のネットワークアクセスシステム３１は、ネットワークスイッチの配置および実行において柔軟性を許容する。例えば、ＡＴＭまたはＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）（マルチプロトコルラベルスイッチング）ネットワークは、１またはそれ以上のＰＡＤ４０をＡＴＭまたはＭＰＬＳスイッチ６０を介して、アクセスルータ４４のポートに接続するために使用され、それによってアクセスルータ４４とは別に機能ブロック６２および６４の信号送信および取り締まりの実行が許容される。しかしながら、もしアクセスルータ４４によって信号送信が実行されたなら、スイッチ６０は除去されうる。スイッチ６０はアクセスルータ４４とコアルータ３６集合スイッチとの間に代案として置かれうる。さらに、アクセスルータ４４は大きなＰＡＤ４０を制御するルーティングソフトウエアを実行する外部プロセッサ４２によって実現されてもよい。
【００２２】
プログラム可能なアクセスデバイス（ＰＡＤ）
図３を参照して、この発明に従うＰＡＤ４０の模範的な実施例を含む論理要素のハイレベルブロック図が例示されている。上記したように、ＰＡＤ４０はプログラム可能なアクセス装置であって、マーキング、取り締まり、モニタリング、および受信および発信パケットのシェイピング（ｓｈａｐｉｎｇ）の任意の所望の組み合わせを実行する、他のトラフィック調整機能モジュールと共に、要求された転送およびパケット分類機能を含む。典型的な実施例においては、ＰＡＤ４０は例示されたモジュールの機能性を提供するために協同するソフトウエアと従来のルータの組み合わせとして実行される。（図３において、点線の例示は選択的な機能モジュールを示すために使用される）。
【００２３】
一般的に言って、ＰＡＤ４０の機能モジュールは着信（例えば顧客ルータ３２から）および発信（例えば顧客ルータ３２へ）トラフィック経路において論理的に配置される。着信経路は、パケットヘッダーフィルタ８０と、マーカー／ポリサ８２とモニタ８４と、転送テーブル８６および出力バッファおよびスケジューラ８８を含む。出力経路は同様にパケットヘッダーフィルタ９０と、転送テーブル８６と、モニタ９２と、マーカー／シェイパ（ｍａｒｋｅｒ／ｓｈａｐｅｒ）９４と、出力バッファおよびスケジューラ９６とを含む。これらの機能モジュールのすべての機能はＭＣＲＩ５８を介して外部プロセッサ４２によって独立して設定されるかまたはプログラムされうる。
【００２４】
ＰＡＤ４０の外部インターフェイスで顧客ルータ３４から受け取った着信パケットは、パケットヘッダーフィルタ８０によってまず処理される。パケットヘッダーフィルタ８０はソース（ｓｏｕｒｃｅ）アドレス（ＳＡ）、目的地（Ｄｅｓｔｉｎａｔｉｏｎ）アドレス（ＤＡ）、サービスのタイプ（ＴＯＳ）、ディフサーブコードポイント（Ｄｉｆｆｓｅｒｖ Ｃｏｄｅｐｏｉｎｔ）（ＤＳＣＰ）、ソースポイント（ＳＰ）、目的地ポート（ＤＰ）、のプロトコルタイプの任意の一つまたは組み合わせを使用して、各種メッセージタイプとパケットの他のフィールド（例えば、ＳＹＮ、ＡＣＫ、ＲＳＴおよびＦＩＮ　ＴＣＰフラグのようなレイヤ４およびより高いフィールド）とを区別する。パケットヘッダーフィルタ８０はパケットの他のフィールドにおいてフィルタ処理するように設定される。重要なことは、レイヤ３情報でフィルタ処理するのに加えて、パケットヘッダーフィルタ８０はより高いレイヤ（すなわちレイヤ４−７）メッセージタイプ、または特定のフィールドであるかを特定する能力を有し、これらのメッセージを設定されたフィルタパラメータに基づいて外部プロセッサ４２から／へ転送する。このように、そのフィルタ設定および着信パケットのフィールドに基づいて、パケットヘッダーフィルタ８０はパケットをメッセージインターフェイス１００を介して外部プロセッサ４２へ、または特定のマーカー／ポリサ８２へ導く。メッセージインターフェイス１００は外部プロセッサ４２によって特定されたパケットをパケットヘッダーフィルタ８０および９０のいずれかに注入してもよいということに注意のこと。
【００２５】
パケットヘッダーフィルタ８０からのパケットの流れの受信に応答して、マーカー／ポリサ８２は、パケットの流れが制御インターフェイス１０４によって確立されたトラフィックパラメータに適合しているかどうかを決定するために、１またはそれ以上のトークンまたはもれやすいパケットアルゴリスムを適用することによってパケットの流れを取り締まる。取り締まり機能の結果、マーカー／ポリサ８２は適合しないパケットを捨て、適合しないパケットにマークを付け（例えばより高いまたはより低い優先度で持って）、および／またはその設定に応じて、不適合なパケットをカウントしてもよい。マーク付けが要求されるならば、マーカー／ポリサ８２は、特定のパケットの流れのために制御インターフェイス１０４によって設定されたように、ＩＰパケットヘッダ、および／または３ビットＭＰＬＳ実験フィールドおよび／または２０ビットＭＰＬＳラベルフィールドおよび／または他のフィールドの区別されたサービス（Ｄｉｆｆｓｅｒｖｅ）／ＴＯＳバイトにビットを設定してもよい。
【００２６】
着信経路内において、異なる機能を有する１またはそれ以上のモニタ８４が選択的に含まれてもよい。例えば、これらのモニタ８４は、異なるレイヤ２、レイヤ３、レイヤ４およびより高いレイヤのトラフィックタイプ（例えばサービスレベルアグリーメント（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）（ＳＬＡ）をモニタするために）のための、統計を追跡する使用モニタを組んでもよい。モニタ８４は報告インターフェイス１０２およびＭＣＲＩ５８を介して外部プロセッサ４２にメモリダンプや他の関連した情報をセーブおよび報告することによって、標準に適合することを実証しかつコードデバッグおよび障害診断を援助する障害／トラブルシューティング／デバッキングモニタをまた含んでもよい。報告メッセージを調整するために、しきい値および他の基準を報告イベントを実施するために設定してもよい。モニタ８４によって送られる報告メッセージは特定の規格に対して使用情報を要約し、高い優先度を有するトラフィックの流れの発生を報告し、帯域外トラフィックの大きな量に対して外部プロセッサ４２に警告を発し、モニタされた流れの不活性を報告等をしてもよい。
【００２７】
パケットヘッダーフィルタ８０（および選択的にマーカー／ポリサ８２およびモニタ８４）によって処理された後、着信パケットは転送テーブル８６によって処理される。転送テーブル８６は各転送経路のための入力を維持し、各転送経路は、ＤＡ、ＳＡ、ＴＯＳ、ＰＴ、ＳＰ、ＤＰ、着信ポートおよび、ＰＡＤ４０がアクセスネットワークを介してアクセスルータ４４へパケットを転送する、対応する出力ポートのような、パケットフロー属性によって表わされる。これらの転送テーブル入力を利用して、転送テーブル８６はパケットを適切な出力ポートに転送し、パケットを出力バッファおよびスケジューラ８８に渡す。
【００２８】
出力バッファおよびスケジューラ８８は、通信ネットワーク３０を介して送信する準備のできたパケットをバッファし、そのようなパケットの送信を予定する。出力バッファおよびスケジューラ８８内でのバッファは単一のバッファまたは好ましくは複数のバッファを含むことができ、複数のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）クラス、または各個々のフローに対するＱｏＳさえもサポートするよう好ましくは設定される。例えば、バッファスペースの割合または固定された量は、トラフィックの一般的クラスまたはＤＡ、ＳＡ、ＴＯＳ、ＰＴ、ＳＰおよび／またはＤＰによって分類される特定のトラフィックの流れの役に立つ待ち行列に割り当てられる。その後、パケットスケジューラは加重されたラウンドロビン（ｒｏｕｎｄ ｒｏｂｉｎ）および／または他のアルゴリスムを、異なるトラフィックフローを多重化した複数の待ち行列に適応する。バッファリングおよびスケジューリング機構の組み合わせはパケットをＰＡＤ４０を介して送信するために、待ち行列の遅れの上で限度を設けることができ、このようにして、選択されたトラフィックフローに対してＱｏＳジッターパラメータのための境界値を保証する。バッファおよびスケジューラ８８は、通信を最適化するために、ＣＢＱ（Ｃｌａｓｓ−Ｂａｓｅｄ Ｑｕｅｕｉｎｇ）（クラスに基づく待ち行列）、ＷＦＱ（Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ）（加重された公平行列）、ＷＲＲ（Ｗｅｉｇｈｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎ）（加重されたラウンドロビン）または他のリンクを共有するアルゴリスムを適用することができる。
【００２９】
ＰＡＤ４０を介した発信経路は、マーカー／ポリサ８２の代わりにマーカー／シェイパ９４を含む点を除いて、着信経路と似ている。当業者にとって理解されるように、マーカー／シェイパ９４は、発信パケットフローの遅延、ジッタおよび紛失を制御するために、出力バッファおよびスケジューラ９６内で個々のフローのための異なるＱｏＳクラスに役立つ各種待ち行列のために、不適合なパケットを廃棄し、適切な出力バッファへのマークされたパケットを送信し、または単に不適合なパケットを数える。
【００３０】
この発明に従うＰＡＤ４０はトラフィック管理およびポリシー制御を行うためにネットワークにおいて多くの位置に配置される。例えば、ＰＡＤ４０は顧客装置を局地的に配置された外部プロセッサ４２によって制御されるプロバイダのネットワークに接続する、顧客アクセスネットワーク（例えば、ファイバ、ｘＤＳＬ、ケーブルモデム、ＷＡＰ（無線アクセスプロトコル）など）に配置されうる。代わりに、ＰＡＤ４０は顧客のサイトと専用回線、ＦＲ、ＡＴＭ、ＭＰＬＳまたはイーサネットアクセスネットワークで接続されたサービスプロバイダのポイントオブプレゼンス（ＰＯＰ）に配置されうる。この発明に従うＰＡＤ４０はプロバイダのＰＯＰまたは顧客のサイトにあるサーバファーム（ｓｅｒｖｅｒ ｆａｒｍ）に対面してＰＡＤ４０に配置されうる。そのようなＰＡＤ４０の分散されたネットワークがアクセスルータ４４にパケットを転送する方法は制御インターフェイス１０４を用いて外部プロセッサ４２によって転送テーブル８６に設定される。
【００３１】
外部プロセッサ
図４を参照して、この発明に従う外部プロセッサ４２の好ましい実施例を含む論理要素がハイレベルなブロック図で例示されている。外部プロセッサ４２はソフトウエアおよびハードウエアの両方またはその一方を用いて実現され、ハードウエアは汎用のコンピュータハードウエアまたは特定目的のハードウエアを含みうる。ＰＡＤ４０をハードウエア上で実行する外部プロセッサ４２のソフトウエアのみでの実施も可能ではあるが、外部プロセッサ４２は、追加のおよび／またはより高い性能の外部プロセッサハードウエアによって容易に拡張される外部プロセッサ４２によって実行されるサービス処理を許容するためにスタンドアロンのハードウエアで好ましくは実施される。ＰＡＤ４０によって実行される転送機能からの外部プロセッサ４２を分離したため、ＰＡＤ４０の転送性能を悪化させることなく、アクセストラフィックパターンに応答して外部プロセッサ４２内でリソース（ｒｅｓｏｕｒｃｅ）の処理をダイナミックに割り当てることが可能となる。さらに、図４に示すように、ＰＡＤ４０から分離して外部プロセッサ４２を実行することによって、外部プロセッサ４２は複数のＰＡＤ４０ａおよび４０ｂに役立つか、代わりに、複数の外部プロセッサ４２が単一のＰＡＤ４０に役立つようになった。単一のＰＡＤ４０を複数の外部プロセッサ４２と関連付けることにより、障害時の許容範囲が向上する。
【００３２】
好ましい実施例において、外部プロセッサ４２はまず３つの処理のタイプを実行する。これは、ポリシーサービスの実行、アクセスネットワーク接続のセットアップおよびテアダウン（ｔｅａｒ ｄｏｗｎ）のための信号送信、および１またはそれ以上の関連したＰＡＤ４０の設定である。これらの異なる処理機能を調整するために外部プロセッサ４２は１またはそれ以上のサービスコントローラ１２０を含む。サービスコントローラ１２０は、それぞれがそれぞれのサービスのタイプに応じてこれら３つの機能を好ましくは制御する。例えば、サービスコントローラ１２０は会議呼び出しサービスコントローラ（Ｃｏｎｆｅｒｅｎｃｅ Ｃａｌｌ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌｌｅｒ）（ＣＣＳＣ）、イーコマースサービスコントローラ（Ｅ−Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌｌｅｒ）（ＥＣＳＣ）、ＩＰ電話サービスコントローラ（ＩＰ Ｔｅｌｅｐｈｏｎｙ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌｌｅｒ）（ＩＰＴＥＬＳＣ）、リザーブド帯域幅サービスコントローラ（Ｒｅｓｅｒｖｅｄ Ｂａｎｄｗｉｄｔｈ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌｌｅｒ）（ＲＢＳＣ）、マルチキャストサービスコントローラ（Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ Ｃｏｎｔｒｏｌｌｅｒ）（ＭＳＣ）の任意のものおよびすべてを含んでもよい。そのようなサービスに特有の制御は専用のサービスコントローラと共に、または各々がサービス特有のＡＰＩをサポートする一般のコントローラと共に実行されうる。各サービスコントローラは、ＰＡＤ４０と共に活性化されたセッションのすべてを記録するセッションテーブルを好ましくは維持する。
【００３３】
図４にさらに示すように、外部プロセッサ４２は各関連したＰＡＤ４０に対して、それぞれのＰＡＤコントローラ１２４を含む。サービスコントローラ１２０の指示の下で、コントロールインターフェイス１０４によって理解されるコマンドまたはスクリプトを実行することによって各ＰＡＤコントローラ１２４は転送テーブル８６、パケットヘッダーフィルタ８０および９０、マーカー／ポリサ８２、マーカー／シェイパ９４、モニタ８４および９２、関連したＰＡＤ４０のスケジューラ８８および９６を設定する。外部プロセッサ４２はまた各関連したＰＡＤ４０のためのそれぞれのメッセージプロセッサ１２２を含む。メッセージプロセッサ１２２は、各々が関連したＰＡＤ４０のメッセージインターフェイス１００へおよびそこからメッセージを通信する。ＰＡＤ４０からのメッセージを受けると、これは通常は顧客ルータ３２から受けたメッセージであるが、メッセージプロセッサ１２２はメッセージを解析し、（サービスのタイプによって決定されるように）適切なサービスコントローラにその内容を知らせる。図４に示されているように、所与の時間において、必ずしもすべてのＰＡＤ４０がすべてのサービスのタイプを処理するよう構成されていない。このように、特定のサービスコントローラ１２０はすべてのＰＡＤ４０よりも少ないメッセージを通信してもよい。
【００３４】
点線で例示したように、外部プロセッサ４２は、選択的なモニタ８４または９２および報告インターフェイス１０２を含む、各ＰＡＤ（例えばＰＡＤ４０ａ）のための報告プロセッサ１２６をさらに含んでもよい。報告プロセッサ１２６は対応するＰＡＤの報告インターフェイス１０２から報告メッセージを受け取り、適切な報告メッセージを１またはそれ以上のサービスコントローラ１２０に転送する。報告プロセッサ１２６は、報告メッセージの受け入れ可能なタイプ、報告メッセージの内容、報告イベントなどを特定するために、ＰＡＤ４０の報告インターフェイス１０２を設定できる。
【００３５】
報告プロセッサ１２６からの報告メッセージまたはメッセージプロセッサ１２２からの別のメッセージタイプを受けると、サービスコントローラ１２０はメッセージを１またはそれ以上のポリシー問い合わせに変換し、ポリシー問い合わせをＳＰＩ５６を介してポリシーサーバ４８に送信する。例えば、ＳＰＩ５６がＣＯＰＳを採用するなら、サービスコントローラ１２０はＲＳＶＰおよびＳＩＰメッセージをＣＯＰＳ（ＲＳＶＰ）およびＣＯＰＳ（ＳＩＰ）メッセージにそれぞれ変換する。サービスコントローラ１２０は、インターフェイス１２１を介して追加のサービスを得るために、別のサービスコントローラ１２０に渡してもよい。
【００３６】
ポリシーサーバ４８からポリシー決定の受け取りに応答して、サービスコントローラ１２０は１またはそれ以上のパケットをメッセージプロセッサ１２２を介してトラフィックフローに注入し、ＰＡＤコントローラ１２４を介してＰＡＤ４０を構成するか、または信号送信コントローラ１２８ａおよび１２８ｂを介して通信ネットワーク３０の内部または外部で信号送信を制御してもよい。信号送信コントローラ１２８はネットワークを介してバーチャルコネクション（Ｖｉｒｔｕａｌ Ｃｏｎｎｅｃｔｉｏｎ）（ＶＣ）またはラベルスイッチパス（Ｌａｂｅｌ ｓｗｉｔｃｈｅｄ Ｐａｔｈ）（ＬＳＰ）をセットアップまたは取り外すために信号送信プロトコルを（例えばＲＳＶＰ、ラベル分散プロトコル（Ｌａｂｅｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＬＤＰ）、専用線ネットワーク−ネットワークインターフェイス（Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）（ＰＮＮＩ）、フレームリレーまたはＡＴＭユーザネットワークインターフェイス（Ｕｓｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）（ＵＮＩ）など）をサポートする。信号送信コントローラ１２８によってセットアップされたＶＣまたはＬＳＰは特定されたＱｏＳを有してよい。
【００３７】
ＳＰＩ５６を介してサービスコントローラ１２０とポリシーサーバ４８との間で通信されるメッセージの数を減らすために、サービスコントローラ１２０の各々は、それぞれのポリシーキャッシュ１３０内に頻繁に使用されるポリシー規則を好ましくはキャッシュする。従って、もし着信メッセージから生じるポリシー問い合わせのためのポリシー情報が既にキャッシュされていれば、サービスコントローラ１２０は問い合わせをポリシーサーバ４８に先立って送信し、そのポリシーキャッシュ１３０内にキャッシュされたポリシー規則を参照することによってポリシー決定を行うことができる。加えて、サービスコントローラ１２０が新しいサービス要求についてポリシーサーバ４８に問い合わせたとき、サービスコントローラ１２０はポリシーサーバ４８に対して、ポリシーデータベース４６からそのポリシーキャッシュ１３０にすべての関連したポリシー情報をダンプするよう要求してもよい。しかしながら、ポリシー問い合わせの数とキャッシュリフレッシュの頻度と各リフレッシュ時のポリシーサーバ４８からダウンロードされたポリシー情報の量との間には、取引が成立する。目的は、ＳＩＰコールのような、集中的なポリシー問い合わせを要求するＩＰサービスのためのポリシーをキャッシュし、一方で、ライフタイムにおいて、ただ一つのポリシー問い合わせのみを一般に発生するような別のセッション（例えばＴＣＰセッション）のためのポリシーの検査のキャッシングを避けることである。
【００３８】
ネットワークアクセスシステムインターフェイス
上記したように、この発明のネットワークアクセスシステムは、少なくとも２つのインターフェイスをサポートをする。ＳＰＩ５６およびＭＣＲＩ５８である。これらのインターフェイスの各々は、以下に述べるように順に検査される。
【００３９】
以下の表１に要約されているように、ＳＰＩ５６は好ましくは外部プロセッサ４２のサービスコントローラ１２０からポリシーサーバ４８へ送信される少なくとも一つのメッセージ、すなわち、ポリシー要求に関する問い合わせの少なくとも一つのメッセージタイプを好ましくはサポートする。そのようなポリシー問い合わせは、ポリシーサーバ４８が要求しているサービスコントローラ１２０のポリシーキャッシュ１３０に対して問い合わせに対するポリシー規則をダンプするように要求するよう設定されうるフラグを好ましくは含む。
【００４０】
ＳＰＩ５６はポリシーサーバ４８からサービスコントローラ１２０へ送信される少なくとも５つのメッセージタイプを好ましくはサポートする。ポリシーサーバ４８からサービスコントローラ１２０へＳＰＩ５６を介して送信されたメッセージタイプは、表１にまた要約されているが、取引承認および拒否メッセージ、設定パラメータを特定するメッセージ、ポリシーキャッシュ１３０内にキャッシュされるべきポリシー情報を含むメッセージを含む。加えて、ポリシーサーバ４８は、ＰＡＤ４０におけるセッションレベルパラメータに対して設定したことを指示するメッセージを外部プロセッサ４２に送信できる。当業者によって理解されるように、一つの重要なセッションレベルパラメータはパケットが活性化されたセッションにおいて受けられてから経過した時間を数得る不活性化タイマであり、特定された量の時間が経過したとき、セッションは活性されていないため終了されるべきであるという旨の信号出力する。
【００４１】
【表１】

ＳＰＩ５６上でのポリシーサーバ４８と外部プロセッサ４２との間の通信は応答型（ｓｏｌｉｃｉｔｅｄ）でもよいし任意型（ｕｎｓｏｌｉｃｉｔｅｄ）でもよい。任意型のモードにおける動作においては、ポリシーサーバ４８は外部プロセッサ４２およびＰＡＤ４０のためにポリシー要求がないとき外部プロセッサ４２に対し、設定パラメータを送信する。代わりに、応答型通信モードにおいては、ポリシーサーバ４８はポリシー決定および設定パラメータをポリシー要求に応答して送信する。図２に示すように、ポリシー要求は外部プロセッサ４２によって送信されてもよいし、ＳＰＩ５６はオープンポリシー問い合わせプロトコルを好ましくは採用するため、第３者（例えば顧客のポリシーサーバ）によって送信されうる。いずれの場合においても、ポリシーサーバ４８はＳＰＩ５６を介してポリシー要求を受ける。ポリシー要求は要求されたサービスを典型的には固定し、サービスのパラメータが与えられると、要求されたサービスが提供されるかどうかを示す応答を要求する（例えば要求者の同一性、要求されたサービスのタイプおよび量など）、そしてもしそうであれば、サービスのための適当な設定を送信される。ポリシー要求の受信に応答して、ポリシーサーバ４８はポリシー要求において提供されたパラメータが与えられると、適切なポリシー規則にアクセスするためにポリシーデータベース４６に問い合わせる。ポリシーサーバ４８はそれからアクセスされたポリシー規則および使用情報を使用したポリシー要求のためのポリシー決定を行う。例えば、ポリシーサーバ４８は、使用されている、残っている予約された帯域幅の量（使用情報）を、要求されたサービスを提供するために必要な帯域幅の量とを比較することによって、特定の顧客（ポリシー規則）によって予約された帯域幅を追跡し、新しいサービスの要求を承認または拒否してもよい。ポリシーサーバ４８はそれから、「承認」、「拒否」でありうる、結果となるポリシー決定および／または外部プロセッサ４２およびＰＡＤ４０のためのセッションレベルパラメータの設定を外部プロセッサ４２にＳＰＩ５６を介して提供する。
【００４２】
ＭＣＲＩインターフェイス５８に戻って、以下に示す表３はＰＡＤ４０によって外部プロセッサ４２に送信されるメッセージのタイプを要約する。示されているように、これらのメッセージタイプはメッセージインターフェイス１００、報告インターフェイス１０２および制御インターフェイス１０４のどれがメッセージのソースであるかを参照することによって都合よく分類されうる。
【００４３】
上記したように、ＰＡＤのメッセージインターフェイス１００はパケットヘッダーフィルタ８０および９０によって捕獲されたメッセージを外部プロセッサ４２のメッセージプロセッサ１２２に渡す。メッセージプロセッサ１２２に渡されたメッセージは、レイヤ４−７メッセージタイプおよびフィールドのような他のパケットフィールドに加えて、ＳＡ、ＤＡ、ＰＴ、ＳＰ、ＤＰおよび／またはＴＣＰフラグ（例えばＳＹＮ、ＡＣＫ、ＲＳＴ、ＦＩＮなど）のような他のパケットフィールドに基づいて受信および発信パケットフローがフィルタ処理される。
【００４４】
制御インターフェイス１０４は、制御コマンドメッセージの受信に応答して、制御応答メッセージをＰＡＤコントローラ１２４に送信する。コマンドがうまく完了したら（例えばモニタ８４の設定がうまく更新されたなら）、制御インターフェイス１０４はＰＡＤコントローラ１２４にコマンド確認応答を返す。しかしながら、もしコマンドが不適切な構文のために完了できなかったり、要求されたリソースが利用できない等のときは、制御インターフェイス１０４はＰＡＤコントローラ１２４にコマンド障害を示すコマンド障害を通知する。
【００４５】
ＰＡＤ４０の報告インターフェイス１０２は報告メッセージを外部プロセッサ４２の報告プロセッサ１２６に送信する。表ＩＩにまとめられた報告メッセージはモニタされたセッションについての情報を提供するメッセージ、ＰＡＤ４０と外部プロセッサ４２のサービスコントローラ１２０との間の通信に関係したメッセージおよびモニタ８４および９２によって収集された統計を含むメッセージを含む。ＴＣＰおよびＳＩＰのようなあるプロトコルに対して、ＰＡＤ４０は各活性化されたセッションに対する状態機械（ｓｔａｔｅ ｍａｃｈｉｎｅ）を実行する。もしＴＣＰ状態機械が、特定の活性化されたＴＣＰセッションが確立された再送信しきい値を超える多数の再送信を有しているときは、報告インターフェイス１０２はＴＣＰ再送信しきい値が超えたということを外部プロセッサ４２のメッセージプロセッサ１２２に通知するメッセージを送信し、このように、ＴＣＰセッションが故障したことを示す。報告プロセッサ１２６は、ＴＣＰおよびＳＩＰのようなあるＩＰプロトコルセッションにおいて不活性タイマが満了したような、他のセッションの故障を同様に報告する。信頼性を確実にするための、関連する状態機械を有さない他のデータフロー（例えばＵＤＰセッション）に対しては、ＰＡＤ４０の報告インターフェイス１０２は、活性化がセッションにおいて検出されたとき「活性化検出」報告メッセージを送信する。
【００４６】
表２によって表されるこの発明の好ましい実施例においては、ＰＡＤ４０と外部プロセッサ４２との間の接続は各ＰＡＤ４０および関連する外部プロセッサ４２との間で定期的に交換されるキープアライブ（ｋｅｅｐａｌｉｖｅ）メッセージによって示される。ＰＡＤ４０からキープアライブメッセージがなくなると、ＰＡＤ４０と外部プロセッサ４２との間の接続の故障および／またはＰＡＤ４０自体の故障を示す。そのようなキープアライブメッセージは報告インターフェイス１０２と報告プロセッサ１２６との間で好ましくは送信される。しかしながら、もし報告インターフェイスが実行されなかったときは、キープアライブメッセージは代わりにメッセージインターフェイス１００によって提供されうる。
【００４７】
外部プロセッサ４２内のサービスコントローラ１２０はまた故障するかまたは異なるサービスに動的に再割当てされる（例えば負荷バランスのために）。複数のサービスコントローラ１２０をサポートしている外部プロセッサ４２の故障またはサービスコントローラ１２０間のサービス責任が再配分されたときは、セッションに対する責任が転送される新しいサービスコントローラ１２０が古いサービスコントローラ１２０の活性化されたセッションのすべてに関する状態情報を受信しなければならない。従って、ＰＡＤ４０を好ましい外部プロセッサ４２に割り当てるいわゆる切り替えが生じたとき、ＰＡＤ４０は活性化されたセッションに対する状態情報を状態同期メッセージにおいて外部プロセッサ１２０の報告プロセッサ１２６に好ましくは報告する。このように、新しいサービスコントローラ１２０にセッション状態情報を提供する責任をＰＡＤ４０に持たせることによって、サービスコントローラ１２０ａおよび１２０ｂから同期セッション状態に維持するための責任を有利に軽減し、これが通常の動作において、サービスコントローラの性能を低下させるメッセージの集中した処理になる。設計のこの局面がハードウエア、ソフトウエアおよびネットワークの故障に対する故障許容量範囲を達成する。
【００４８】
表２は選択的なモニタ８４および９２によって実行されるモニタによって始められる２つの模範的な報告メッセージを最終的にリスト化する。まず、報告インターフェイス１０２は各顧客ごとに一般的な使用統計を提供できる。外部プロセッサ４２のサービスコントローラ１２０はＳＬＡに対する適合性を測定するための統計情報を使用し、興味のある、あるイベントを検出する。第２に、報告インターフェイス１０２は顧客のあらかじめ定められたトラフィックしきい値が超えたということを報告メッセージ内で特に示す。外部プロセッサ４２のサービスコントローラ１２０は追加のリソースを顧客のトラフィックに割り当てるためにこの情報を使用することができる（例えば、ＳＬＡに対する適合性を確実にするために）または顧客への請求書発行において調整がされなければならないということを請求書作成サーバ７２に通知することができる（例えばもし請求書作成が使用に基づいて行われるならば）。もちろん、追加の報告メッセージもまたポリシーできる。
【００４９】
【表２】

表３を参照して、ＭＣＲＩ５８を介してメッセージプロセッサ１２２から、ＰＡＤコントローラ１２４および外部プロセッサ４２の報告プロセッサ１２６からＰＡＤ４２へ送信されるメッセージのタイプが要約されている。表３に示されたインターフェイスの実施例のおいては、メッセージプロセッサ１２２はメッセージインターフェイス１００に対して少なくとも２つのメッセージのタイプを送信できる。まず、メッセージプロセッサ１２２はメッセージインターフェイス１００に対して着信または発信パケットフローのいずれかに注入される１またはそれ以上のパケットを送信してもよい。第二に、メッセージプロセッサ１２２は、メッセージインターフェイス１００がＳＡ、ＤＡ、ＰＴ、ＳＰ、ＤＰなどのような各種のパケットフィールドの内容に基づいてメッセージプロセッサ１２２に特定のメッセージを送信する、または、送信するのを妨げるよう動作するよう、メッセージインターフェイス１００内のパケットフィールドフラグを設定またはリセットすることを示すメッセージをメッセージインターフェイス１００に送信してもよい。
【００５０】
表３に示されているように、ＭＣＲＩ５８を介してインターフェイス１０４を制御するためのＰＡＤコントローラ１２４から送信された制御メッセージは、多数の設定メッセージを含み、この設定メッセージはＰＡＤコントローラ１２４が制御インターフェイス１０４を介して任意のフィルタ処理、マーキング、取り締まり、モニタ、バッファ、スケジューリング、シェイピングおよびＰＡＤ４０の機能モジュール８０−９６を転送するといった任意のものを設定することを可能にする。特に、出力バッファおよびスケジューラ８８および９６は、多くのバッファ、トラフィッククラスあたりのバッファのサイズまたはトラフィックフローの多くを割り当てる、または、ＣＢＱ、ＷＦＱ、ＷＲＲまたは他のバッファスケジューリングアルゴリスムを実行するよう設定されうる。ＰＡＤコントローラ１２４は、静的または適応性のあるシェイピングアルゴリスムを採用するために、マーカー／シェイパ９４を設定することができ、トラフィッククラスベースごとまたはトラフィックフローごとにシェイピングを実行するためにマーカー／シェイパ９４を設定することができる。ＰＡＤコントローラ１２４は、サービスコントローラ１２０がデータフローをＡＴＭＳＶＣまたはＭＰＬＳＬＳＰと関連づけうるように、サービスコントローラ１２０による要求に応答して転送テーブル８６をさらに設定することができる。
【００５１】
機能モジュール８０−９６を設定するために使用される一般の制御メッセージに加えて、ＭＣＲＩ５８はＰＡＤ４０の機能モジュールの特定の特徴を設定するために使用される各種の制御メッセージをサポートする。例えば、パケットヘッダーフィルタ８０および９０はデータフローに対するソース経路を許容するかまたは否定するために、または特定のソースアドレスを有するパケットのみを許容するために、権限のないソースからのマルチキャストパケットを落とすよう設定されうる。加えて、ＰＡＤコントローラ１２４は信号送信コントローラ１２８を使用して、サービスコントローラ１２２によって設定されたＳＶＣおよびＬＳＰ経路を有する転送テーブル８６を更新できる。報告インターフェイス１０２はイベントに対応した報告フラグを設定またはリセットすることによって、選択されたイベントの報告を可能または不能にするための「報告フラグ設定」制御メッセージを介して設定される。ＰＡＤ４０はＭＣＲＩコントロールメッセージを介してＴＣＰ再送信通知しきい値、不活性タイマ、活性タイマおよび上記したトラフィックしきい値を設定するよう特定される。最後に、ＰＡＤ４０と出力バッファとスケジューラ８８、９６の処理リソースは、帯域幅、待ち行列および処理時間スライス（ｓｌｉｃｅ）のようなリソースを動的に割り当てるために、ＭＣＲＩ５８および制御インターフェイス１０４を介して、顧客インターフェイス、パケットフロー、クラスまたはマルチキャストグループに送信された「割り当てリソース」制御メッセージによって設定されうる。
【００５２】
外部プロセッサ４２の報告プロセッサ１２６からＰＡＤ４０へ送信される報告メッセージは、報告インターフェイス１０２付きのキープアライブメッセージの交換に一般的には限られる。キープアライブメッセージの連続した交換はＰＡＤ４０に、関連したサービスコントローラ１２０が動作中であるということを知らせる。もしＰＡＤ４０がサービスコントローラ１２０からキープアライブメッセージを受け取れなかったら、ＰＡＤ４０は、以下にさらに述べるように、サービスを第二のサービスコントローラ１２０へ切り替え始める。
【００５３】
【表３】

故障許容範囲
サービスコントローラが故障のときにサービスの中断を防ぐために、各サービスは、通常サービスを提供する一次サービスコントローラと、もし一次サービスコントローラが故障またはＰＡＤと一次サービスコントローラとの間の接続が失われたときには、サービスを提供することができる二次サービスコントローラと、の両方によって好ましくはサポートされる。この発明の好ましい実施例においては、一次および二次サービスコントローラはアクセスネットワークを介して、種々に接続された別の外部プロセッサ４２に存在する。一次サービスコントローラとの通信の障害を検出したことに応答して、ＰＡＤ４０は二次サービスコントローラへの切り替えを実行する。
【００５４】
図５Ａを参照して、この発明に従う、故障した一次サービスコントローラから二次サービスコントローラへのサービスの提供を置き換える模範的なネットワークアクセスシステムの信号を示す、時間−空間ダイアグラムが描かれている。図５Ａにおいて、例示のために、サービスコントローラ１２０ａは一次サービスコントローラで、サービスコントローラ１２０ｂは二次サービスコントローラである。
【００５５】
通常の動作の間、ＰＡＤ４０は関連した外部プロセッサ４２のサービスコントローラ１２０ａおよび１２０ｂと情報を交換するために信頼性のある通信プロトコル（例えばＴＣＰ）を採用している。上で述べたように、キープアライブメッセージはＴＣＰセッションの活性化が続くように、外部プロセッサ４２とＰＡＤ４０との間で定期的に交換される。ＰＡＤ４０がキープアライブメッセージのタイムアウトを検出すると、これは一次サービスプロセッサ１２０ａへの接続が失われたことを意味するが、図５Ａに示されているように、ＰＡＤ４０は、二次サービスコントローラ１２０ｂへ同期セグメント（ＳＹＮ）をＰＡＤ４０が送信することによって、二次サービスコントローラ１２０ｂとＴＣＰセッションを設立するよう試みる。もしＰＡＤ４０が二次サービスコントローラ１２０ｂとの接続に失敗したら（例えば、二次サービスコントローラ１２０ｂからＳＹＮ　ＡＣＫを受け取らなければ）、一次サービスコントローラ１２０ａとの通信が回復するまで、ＰＡＤ４０は新しいセッションを受け入れるのを停止し、その状態および全ての現在活性中のセッションに対するサービスを維持する。
【００５６】
しかしながら、もしＰＡＤ４０が二次サービスコントローラ１２０ｂとＴＣＰセッションをうまく確立したときは（例えば、ＳＹＮ　ＡＣＫ、およびＡＣＫの返信を受けることによって示されるように）、ＰＡＤ４０は、各活性化されたセッションに対する状態機械を維持し、故障した一次サービスコントローラ１２０ａによって制御された活性化されたセッションのすべてに対する状態情報を二次サービスコントローラ１２０ｂにアップロードする。二次サービスコントローラ１２０ｂによる状態情報の受信がＡＣＫメッセージによって確認されると、ＰＡＤ４０はキープアライブメッセージの対応を二次サービスコントローラ１２０ｂと開始する。このように、サービスは単一のサービスコントローラ１２０の故障によって中断されず、サービスコントローラ１２０ａおよび１２０ｂ間の同期も必要とされない。
【００５７】
もし非復帰行動が望まれるのであれば、ＰＡＤ４０と二次サービスコントローラ１２０ｂ間の通信が続き、一次サービスコントローラ１２０ａに戻らない。しかしながら、もし可能であれば、分散されたＰＡＤのサービスコントローラ処理の負荷バランスを維持するために、通信は一次サービスコントローラ１２０ａに戻るほうが現在のところ好ましい。
【００５８】
図５Ｂを参照して、一次サービスコントローラの回復に続いて、二次サービスコントローラから一次サービスコントローラへの切り替えの間の、プログラム可能なアクセス装置と外部プロセッサ間の模範的な信号送信を示した時間−空間図が描かれている。復帰処理はＴＣＰセッションを再確立するために、一次サービスコントローラ１２０ａがＳＹＮセグメントをＰＡＤ４０に送信することによって始まる。ＰＡＤ４０は一次サービスコントローラ１２０ａがＡＣＫによって確認する、ＳＹＮ　ＡＣＫを有するＳＹＮの受信に応答する。ＴＣＰセッションが開始されると、ＰＡＤ４０は活性化されたセッションの状態を一次サービスコントローラ１２０ａにアップロードし、サービスコントローラ１２０ａはＡＣＫでセッション状態の受信を確認する。
【００５９】
セッション状態がうまく一次サービスコントローラ１２０ａに復帰された後、ＰＡＤ４０は二次サービスコントローラ１２０ｂに、一次サービスコントローラ１２０ａが「シャットダウンのための準備」メッセージを介して回復したということを通知する。ＰＡＤ４０はそれからＦＩＮ（すなわち終了）およびＡＣＫのハンドシェイクの対を介して二次サービスコントローラ１２０ｂとのＴＣＰセッションを閉じる。この対の前半はＰＡＤ４０によって開始され、後半は二次サービスコントローラ１２０ｂによって開始される。ＴＣＰ接続が閉じられた後、二次サービスコントローラ１２０ｂは一次サービスコントローラ１２０ａに転送されたセッションにすべての状態情報を削除する。ＰＡＤ４０はその後一次サービスコントローラ１２０ａとのキープアライブ交換を開始する。
【００６０】
都市における実施
図１Ｂを参照して、この発明に従う分散されたネットワークアクセスシステムを含むインターネットサービスプロバイダ（ＩＳＰ）ネットワークの模範的な都市における実施が示される。図１Ｂは図２に示すような、論理（例えばネットワーク）接続というよりは、要素の物理的な相互接続を例示する。
【００６１】
左手側から始まって、顧客ＬＡＮ１４は都市アクセスネットワーク１６’の中で最も低いレベルのアクセスネットワーク（例えばＴＤＭ、ＡＴＭ、またはイーサネット）かまたは直接ＰＡＤ４０に相互接続する。示されているように、ＰＡＤ４０は集合ネットワーク階層においてより高いレベルに位置してもよい。エンジニアリング経済および／または性能を考慮することによって、ＰＡＤ４０の位置が決定する。例えば、トラフィックの最小量の集計または低速アクセスリンクへのアクセスの必要性によってＰＡＤ４０の位置がそれぞれより高いまたはより低いアクセスネットワークレベルに移動されてもよい。
【００６２】
上で議論したように、ＰＡＤ４０はポリシーの強制を行い、それによって集合ルータ（すなわちアクセスルータ４４）からある作業負荷を軽減する。ポリシーの決定は集合ルータからまた除去され、代わりに、冗長な外部プロセッサ４２およびＰＤＰ４６に位置される。ほとんどの実施において、外部プロセッサ４２は各都市領域に分散された方法で典型的には配置され、一方、ＰＤＰ４６は地域ベースでよりまばらに配置される。集合ルータから作業負荷のいくらかを軽減した結果、アクセスルータ４４は、アクセスルータがより単純ではあるが、必須の基本的なインターネットルーティングの仕事を処理するよう最適化されるため、より大きなトラフィック能力を処理するよう拡張されうる。ＩＳＰネットワークの能力は、ＰＡＤ４０、外部プロセッサ４２およびＰＤＰ４６が最新技術のエッジルータの機能だけでなく、融通のきかないルータデザインにおいて現在は入手できないような多くの機能をも実行するため、また拡大される。
【００６３】
この発明の局面をさらに例示するために、各種の動作シナリオのためのネットワークアクセスシステムの信号送信およびメッセージ作成の例を一般的な空間ー時間図を参照して以下に述べる。例は、ネットワークレベル信号送信、接続優先およびコネクションレス転送プロトコル、アプリケーションレベル通信およびポリシーベースのマルチキャストサービス管理の模範的な実施例を例示する。
【００６４】
ネットワークレベル信号送信の例
図６を参照して、リソースリザベーションプロトコル（ＲＳＶＰ）の使用を介したサービス予約を得るために使用される模範的なネットワークレベル信号送信を示す時間−空間図を例示する。例示された例においては、顧客のアプリケーションがＲＳＶＰＰＡＴＨメッセージをＰＡＤ４０に送ることによって予約処理を開始する。例えば、顧客のアプリケーションは特定の時間における特定の帯域幅の経路を要求してもよい。図６に示すように、ＰＡＤ４０のパケットヘッダーフィルタ８０は、ＲＳＶＰプロトコルタイプ（すなわちＰＴ＝４６）に基づいてＲＳＶＰ　ＰＡＴＨメッセージを捕獲し、それを外部プロセッサ４０内の適切なサービスコントローラ１２０（この例においては、予約された帯域幅サービスコントローラ（ＲＢＳＣ）と呼ばれる）に転送する。
【００６５】
経路メッセージの受信に応答して、ＲＢＳＣ１２０は予約サービスがこの顧客に認められているかどうかを判定するため、ＳＰＩ５６（この場合にはＣＯＰＳを実行するとみなされる）を介してポリシーサーバ４８に適切なポリシー問い合わせを送信する。ポリシーサーバ４８がこの顧客に対して予約サービスを認めるポリシーの決定をＲＢＳＣ１２０に戻すと、ＲＢＳＣ１２０はＲＳＶＰＰＡＴＨメッセージをＰＡＤ４０に戻す。ＰＡＤ４０はＰＡＴＨメッセージの下流（ｄｏｗｎ ｓｔｒｅａｍ）をネットワークの出口点へ送信する。
【００６６】
もしネットワークのずっと離れた端部のレシーバが予約を認めたときは、レシーバは、ＰＡＤ４０に予約（ＲＥＳＶ）メッセージを送信することによって応答し、ＰＡＤ４０は、ＲＥＳＶメッセージをＲＢＳＣ１２０に送る。ＲＥＳＶメッセージに応答して、ＲＢＳＣ１２０は、ＲＥＳＶメッセージによって特定された帯域幅の要求がこの顧客に認められているかどうかを確認するために、別のポリシー問い合わせをポリシーサーバ４８に行う。この２番目の問い合わせに応答して、各顧客に対して割り当てられた帯域幅を追跡するポリシーサーバ４８が現在割り当てられている帯域幅に要求された帯域幅を加えたものがこの顧客のための最大の認められた帯域幅よりも小さいかどうかを判定する。もしそうであれば、ポリシーサーバ４８は承認を示すポリシー決定と共にＲＢＳＣ１２０に通知する。ＲＢＳＣ１２０はそれから１またはそれ以上の信号コントローラ１２８を使用してＲＶＣまたはＬＳＰを設立するために適切なＡＴＭまたはＭＰＬＳ信号送信を開始する。ＲＢＳＣ１２０がネットワークから要求された経路の確認を受信した後、ＲＢＳＣ１２０は確立されたＳＶＣまたはＬＳＰを介して顧客のフローにパケットを送信するために、ＰＡＤ４０のパケットヘッダーフィルタ８０および転送テーブル８６を設定する。加えて、ＲＢＳＣ１２０はＲＥＳＶメッセージをメッセージインターフェイス１００を用いてＰＡＤ４０の戻す。メッセージインターフェイス１００はＲＥＳＶメッセージの上流（ｕｐｓｔｒｅａｍ）を顧客アプリケーションに送信する。ＲＢＳＣ１２０はＣＯＮＦＩＲＭメッセージの下流をＳＶＣまたはＬＳＰを設立するために使用されるハンドシェイクを完成するためにＰＡＤ４０を介してレシーバに送信する。
【００６７】
コネクション型の送信の例
図７Ａ−７Ｇを参照して、この発明に従うネットワークアクセスシステムによる接続優先の転送プロトコルの処理を例示する各種ＴＣＰイベントの時間−空間図とＴＣＰ状態機械が描かれている。まず図７Ａを参照して、ＰＡＤ４０上でのＴＣＰセッションのために維持された状態機械の好ましい実施例が描かれている。示されているように、ＴＣＰ状態機械１４０は２つの状態を含む。活性化されたＴＣＰセッションが存在しないアイドルステート１４２と活性化されたＴＣＰセッションが存在する活性化状態１４４である。状態機械１４０の動作は、（１）同期セグメント（ＳＹＮ）に応答したＴＣＰセッションの開始、（２）終了（ＦＩＮ）メッセージに応答したＴＣＰセッションの終了、（３）時間切れによるＴＣＰセッションの終了および（４）リセット（ＲＳＴ）メッセージに応答したＴＣＰセッションの終了を含む、４つのＴＣＰ処理の間にＴＣＰセッション状態を維持する。図７Ａにおいて、これらの動作の各々に関連したメッセージは、対応する凡例（例えば、ＴＣＰセッション開始のための「１．ｘ」、ＦＩＮメッセージに応答してＴＣＰセッションを終了する「２．ｘ」、等）によって特定され、ある英字指定（例えば「１．ａ」は「１．ｂ」の前など）によってさらに時間の順序付けが行われる。
【００６８】
例示されているように、ＴＣＰセッションの開始は状態機械１４０がアイドル状態１４２にあり、ＰＡＤ４０がＳＹＮセグメントを受け取ったときに始まる。参照番号１５０で例示されているように、パケットヘッダーフィルタ８０は顧客から受け取った最初のＳＹＮメッセージを捕獲し、それをＴＣＰサービスを処理するよう指定された外部プロセッサ４２内のサービスコントローラ１２０に渡す。ＳＹＮメッセージの受け取りに応答して、サービスコントローラ１２０はこの顧客に対するＴＣＰセッションに関してポリシーサーバ４８に問い合わせを行う。サービスコントローラ１２０がＴＣＰセッションの承認を示す決定を受け取ると、サービスコントローラ１２０はＳＹＮセグメントを参照番号１５２で示されているようにＰＡＤ４０に戻す。サービスコントローラ１２０からのＳＹＮメッセージの受け取りに応答して、状態機械１４０は状態をアイドル状態１４２から活性化状態１４４に変更する。ＰＡＤ４０はＳＹＮセグメントを目的地アドレスによって特定されたレシーバに転送し、参照番号１５４で示されているように、レシーバからＳＹＮ、ＡＣＫセグメントを受信する。送信者は、参照番号１５６で示されているように、ＡＣＫメッセージで応答することによってＴＣＰセッションを開始するのに必要な３方向のハンドシェイクを完了する。ＰＡＤ４０はハンドシェイクの成功を表すＡＣＫメッセージを参照番号１５８で示すようにサービスコントローラ１２０に渡す。ＡＣＫメッセージの受信よってＴＣＰセッションが開始されたことをサービスコントローラ１２０に通知し、サービスコントローラ１２０はその活性化セッションテーブルにＴＣＰセッションを加える。サービスコントローラ１２０はそれからＰＡＤ４０内でこのＴＣＰセッションの不活性タイマおよび他のパラメータを設定し、参照番号１５８で示されているように、ＡＣＫメッセージをＰＡＤ４０に戻す。その後、データは参照番号１５９で示されているように、活性化されたＴＣＰセッションを介して顧客とレシーバとの間で送信される。
【００６９】
活性化されたＴＣＰセッションを終了するために、顧客またはレシーバのいずれかがＰＡＤ４０にＦＩＮメッセージを送信することができる。ＦＩＮメッセージの受信に応答して、ＰＡＤ４０は参照番号１６０で示すように、ＴＣＰ状態機械１４０をアイドル状態にリセットする。ＰＡＤ４０は参照番号１６２で示すようにＦＩＮメッセージをサービスコントローラ１２０に渡す。ＦＩＮメッセージはサービスコントローラ１２０に、ＴＣＰ接続が不活性であることを知らせ、サービスコントローラ１２０にその活性セッションテーブルからＴＣＰセッションを削除させる。例示されているように、ＰＡＤ４０はＦＩＮメッセージをその目的地（すなわち顧客またはレシーバ）へ転送する。これはＡＣＫメッセージとＦＩＮメッセージ共に応答する。ソースはそれからＡＣＫメッセージ１６６と共に最後のＦＩＮメッセージを応答する。最後のＡＣＫメッセージの受信に応答して、ＰＡＤ４０はＴＣＰセッションのための状態機械１４０を削除する。
【００７０】
図７Ａにさらに例示されているように、ＰＡＤ４０はＴＣＰセッションの不活性タイマが終了したとき活性化されたＴＣＰセッションを終了する。活性化されたＴＣＰセッション用の不活性タイマ満了に応答して、参照番号１７０で例示されているように、ＰＡＤ４０は状態機械１４０を活性化状態１４４からアイドル状態１４２に移行する。ＰＡＤ４０は、タイムアウトエラーをサービスコントローラ１２０に報告する。タイムアウトエラーメッセージ受信に応答して、サービスコントローラ１２０は活性セッションテーブルからＴＣＰセッションを削除し、ＴＣＰセッションに関連した、不活性タイマおよび他の設定情報を除去するために、ＰＡＤ４０の設定を更新する。ＰＡＤ４０はそれからＴＣＰセッションのための状態機械１４０を削除する。
【００７１】
ＰＡＤ４０はいずれかの当事者からＴＣＰ接続のリセット（ＲＳＴ）メッセージの受信に応答して活性化ＴＣＰセッションを終了する。ＲＳＴメッセージの受信に応答して、参照番号１８０で示されているように、ＰＡＤ４０は状態機械１４０を活性化状態１４４からアイドル状態１４２に遷移させる。ＰＡＤ４０はまた参照番号１８２で示されているように、ＲＳＴメッセージをサービスコントローラ１２０に渡す。ＲＳＴメッセージの受信に応答して、サービスコントローラ１２０は、参照番号１８２で示されているように、ＲＳＴおよびＴＣＰセッションの削除の成功の受信の確認応答をするためにＲＳＴメッセージをＰＡＤ４０に戻す。ＰＡＤ４０はそれからＴＣＰセッションの状態機械１４０を削除し、ＲＳＴメッセージをＴＣＰセッションの他の当事者に転送する。
【００７２】
ＰＡＤ４０およびサービスコントローラ１２０の効率的な動作を促進するために、それらの間のメッセージの量を最小にすることが望ましい。従って、もしＴＣＰセッションの開始が要求されたら、ＰＡＤ４０はサービスコントローラ１２０に最後のＡＣＫメッセージを転送するだけである。加えて、ＰＡＤ４０はセッションにおいて受け取った第一ＳＹＮ、ＦＩＮセグメントをサービスコントローラ１２０に渡すだけである。このようにして、ＰＡＤ４０とサービスコントローラ１２０の機能がたとえ分散されているとしても、過度のメッセージは避けられる。
【００７３】
好ましい実施例において、ＰＡＤ４０はサービスコントローラ１２０が付加価値のあるサービスを設定するＴＣＰセッションのための活性化された状態情報を単に維持する必要がある。言い換えると、ＰＡＤ４０はＴＣＰセッションに対する最善の努力のための状態情報を維持しない。これはＴＣＰ状態情報を維持するためにＰＡＤ４０に要求されるメモリサイズを大幅に減らす（例えば、パケットヘッダーフィルタ８０および９０ならびにモニタ８４および９２の状態情報）。また、多数の活性化したＴＣＰセッションがありうるため、表３で与えられたＴＣＰセッションメッセージの削除によって、サービスコントローラ１２０は、ＴＣＰセッション状態メモリが一杯になったときにどのＴＣＰセッションが付加価値のあるサービスを受けるのかということを決定することができる。
【００７４】
図７Ｂに例示されているように、ＰＡＤ４０はＴＣＰ状態メモリが一杯であるというメッセージ１８６を、ＴＣＰ状態メモリフルイベント１８４の検出に応答して、報告インターフェイス１０２を介してサービスコントローラ１２０に送信する。状態メモリフルイベント１８４はパケットヘッダーフィルタ状態変数のためのストレージまたはモニタ状態変数のためのストレージのいずれかの枯渇によって生じる。ＴＣＰ状態メモリフルメッセージ１８６に応答して、サービスコントローラ１２０はＰＡＤ４０のＴＣＰ状態メモリ状態を記録する。
【００７５】
顧客ルータ３２がＳＹＮメッセージ１８８を送信することによって別の付加価値のあるＴＣＰセッションを開始したとき、参照番号１９０で示すように、ＰＡＤ４０はメッセージインターフェイス１００を介してＳＹＮメッセージをサービスコントローラ１２０に渡す。ＳＹＮメッセージの受信に応答して、サービスコントローラ１２０はＰＡＤ４０のＴＣＰ状態メモリ現状をチェックする。ＴＣＰ現状状態メモリが一杯であるため、サービスコントローラ１２０は、何らかのあらかじめインストールされたポリシーに基づいて既存の付加価値のあるＴＣＰセッションに新しいＴＣＰセッションを上書きすることを許容するか否かを決定する。例えば、サービスコントローラ１２０は各付加価値のあるサービスに優先度を割り当て、より低い優先度のＴＣＰセッションにより高い優先度のセッションを上書きすることを許容するようにしてもよい。代わりに、または追加して、サービスコントローラ１２０は、最も長い不活性期間を有するＴＣＰセッションに新しいＴＣＰセッションを上書きするよう許可してもよい。
【００７６】
もし新しいＴＣＰセッションを任意の既存のＴＣＰセッションに上書きすることが許可されないときは、サービスコントローラ１２０はＳＹＮメッセージを無視する。その結果、ＰＡＤ４０は新しいＴＣＰセッションのための状態情報をインストールせず、ＰＡＤ４０は新しいＴＣＰセッションに対して最善努力のサービスを提供する。しかしながら、もしサービスコントローラ１２０が、新しいＴＣＰセッションが別のＴＣＰセッションに上書きできると決定すると、サービスコントローラ１２０はコントロールインターフェイス１０２を介してＰＡＤ４０に対してＤｅｌｅｔｅ（削除）ＴＣＰセッションメッセージを送信する。ＰＡＤ４０は参照番号１９４によって示されているように、そのＴＣＰ状態メモリから既存のＴＣＰセッションを削除することによって応答する。参照番号１５０−１５９で図７Ａに例示されている処理はそれから、ＰＡＤ４０の状態メモリに新しいＴＣＰセッションをインストールするため実行される。
【００７７】
図７Ａに描かれている模範的なＴＣＰ状態機械が与えられたとして、図７Ｃ−７Ｇを参照してＴＣＰ信号送信のいくつかの例を以下に述べる。まず図７Ｃを参照して、この発明に従うネットワークアクセスシステムを介したＴＣＰセッションを確立するために使用される模範的な信号送信が示される。
【００７８】
例示されているように、ＴＣＰセッションを開始するために、顧客のアプリケーションはまず、アプリケーションが特定のポートおよびＩＰアドレス（例えば、ウエブページにアクセスするとき）でサーバに対する接続の開始を希望するということをプロトコルスタック（ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）に知らせる開始コマンドを発行する。顧客サイトのＴＣＰエージェント（ａｇｅｎｔ）はそれから最初のシーケンス番号（この例では８００）を選択し、選択されたシーケンス番号を有する同期セグメント（ＳＹＮ）を送信する。ＳＹＮセグメントが到着すると、ＰＡＤ４０のパケットヘッダーフィルタ８０は、特定された目的地ＩＰアドレスおよびポート番号（ＰＴ＝６、ポート＝８０）に基づいて、ＳＹＮセグメントが必須のイーコマースＴＣＰセッションの開始を意図している、ということを検出する。従って、パケットヘッダーフィルタ８０はＳＹＮセグメントをイーコマースサービスコントローラ（ＥＣＳＣ）１２０に渡す。ＥＣＳＣ１２０は、たとえば、ＬＤＡＰ要求を使用してポリシーサーバ４８に問い合わせることによってＳＹＮセグメントに応答する。
【００７９】
例えば、ＬＤＡＰ　ＡＰＰＲＯＶＥメッセージを介してＴＣＰセッションの承認を示すポリシーサーバ４８に応答して、ＥＣＳＣ１２０はＰＡＤ４０にＳＹＮセグメントを戻す。ＰＡＤ４０がＥＣＳＣ１２０からＳＹＮセグメントを受け取ると、ＰＡＤ４０は新しいＴＣＰ状態機械を発生し、それを活性状態１４４に設定する。ＰＡＤ４０はそれからＳＹＮセグメントにおいて特定されたサーバにＳＹＮセグメントの下流を送信する。
【００８０】
ＳＹＮセグメントがサーバで受信されると、サーバのＴＣＰエージェントは最初のシーケンス番号（この場合４００）を取り、選択された開始シーケンス番号およびＡＣＫを含むＳＹＮセグメントをＰＡＤ４０に送信する。ＡＣＫメッセージは、顧客によって送信された最初のデータバイトは８０１という番号であるべきであると特定する。サーバによって送信されたＳＹＮおよびＡＣＫメッセージはＰＡＤ４０によって顧客アプリケーションに転送をされるが、これらのメッセージはＥＣＳＣ１２０には転送される必要がないということに注意のこと。
【００８１】
顧客のＴＣＰエージェントがＳＹＮ／ＡＣＫメッセージを受け取ったとき、サーバによって送信された最初のデータバイトは４０１という番号であるべきであるということを意味する、ＡＣＫメッセージ４０１をＴＣＰエージェントが戻す。このＡＣＫメッセージは、３方向のハンドシェイクが成功し、ＴＣＰセッションが開始されたということをＥＣＳＣ１２０に通知するために、ＰＡＤ４０によってＥＣＳＣ１２０に渡される。ＥＣＳＣ１２０はそれからＴＣＰセッションをその活性セッションテーブルに加え、ＴＣＰ再送信の許可された番号および適切な不活性タイマ設定をＰＡＤ４０に設定する。ＥＣＳＣ１２０はこのＴＣＰセッションに属しているパケットを高い優先度であるとマークするためにマーカー／ポリサ８２を設定してもよい。ＥＣＳＣ１２０はＡＣＫセグメントをＰＡＤ４０に戻す。ＰＡＤ４０はＴＣＰセッションが開始されたということをレシーバに知らせるために、ＡＣＫセグメントを目的地サーバに送信する。ひとたび顧客のＴＣＰエージェントがクライアントアプリケーションに、ＴＣＰ接続が開始されたということを知らせると、クライアントとサーバはＴＣＰセッションにおいてデータの交換を始めることができる。
【００８２】
図７Ｄを参照して、この発明に従うＴＣＰ接続を終了するための模範的なネットワークアクセスシステムの信号送信を例示した時間−空間図が示されている。図７Ｄに示された例においては、ＴＣＰ接続の両側がＴＣＰセッションの切断を始めることができるが、サーバアプリケーションが接続を終了するために、そのＴＣＰエージェントに指示することによって、ＴＣＰセッションの終了を開始する。従って、サーバのＴＣＰエージェントは、それ以上データを送信しないということをクライアントアプリケーションに知らせる、ＦＩＮセグメントを送信する。ＦＩＮセグメントの受信に応答して、ＰＡＤ４０はアイドル状態１４２に接続するためにＴＣＰ状態機械をリセットし、ＦＩＮセグメントをＥＣＳＣ１２０に渡す。ＥＣＳＣ１２０はその活性化セッションテーブルからＴＣＰセッションを削除し、このＴＣＰセッションのためのパケットをマーキングするのを止め、セッションの不活性タイマおよび再送信設定を除去するようＰＡＤ４０を設定することによって応答する。ＰＡＤ４０はまたＦＩＮセグメントをクライアントに転送する。クライアントはＰＡＤ４０によってサーバに対して渡されるＡＣＫと共にＦＩＮセグメントの受信を確認する。クライアントアプリケーションはそれからそのＴＣＰエージェントに対してセッションを終了するよう命令する。クライアントのＴＣＰエージェントはそれゆえＰＡＤ４０を介してサーバのＴＣＰエージェントに対してＦＩＮメッセージを送信する。サーバのＴＣＰエージェントはクライアントのＦＩＮメッセージに対して、ＴＣＰセッションを閉じるための３方向のハンドシェイクがうまくといったということをＰＡＤ４０に示すＡＣＫで応答する。ＰＡＤ４０は従って、ＴＣＰセッションのための状態機械を削除し、ＡＣＫメッセージを顧客に転送する。一方、サーバのＴＣＰエージェントはサーバアプリケーションに接続が終了したことを通知する。
【００８３】
次に図７Ｅを参照して、権限のないＴＣＰセッションのための要求に応答してこの発明に従う模範的なネットワークアクセスシステムの信号送信を示す時間−空間図が例示されている。図７Ｅと図７Ｃとを比較してわかるように、処理はポリシーサーバ４８がＥＣＳＣ１２０にＴＣＰセッションを拒絶するＬＤＡＰポリシー決定を戻す点まで同じである。ポリシーサーバ４８は例えば、ネットワークが要求されたセッションをサポートするための十分なリソースが無いとか、クライアントが要求された高い優先度のイーコマースサービスを予約していないためといった理由でＴＣＰセッションを拒絶してもよい。ＴＣＰセッションの拒絶に引き続いて、ＥＣＳＣ１２０はＰＡＤ４０にリセット（ＲＳＴ）セグメントを発行し、ＰＡＤ４０はクライアントのＴＣＰエージェントにＲＳＴセグメントの上流を送信する。クライアントのＴＣＰエージェントがＲＳＴセグメントを受けると、顧客のＴＣＰエージェントはセッションを終了する。ＰＡＤ４０はＥＣＳＣ１２０からＳＹＮセグメントを受信しないため、ＰＡＤ４０はＴＣＰセッションのための状態機械を生成しないということに注意のこと。
【００８４】
図７Ｆを参照して、過度のＴＣＰ再送信が検出されたときの、模範的なネットワークアクセスシステムの信号送信を示す時間−空間図を例示する。わかるように、ＴＣＰセッションは図７Ｄに例示されているように、適切な切断を通じて通常は終了する。しかしながら、ネットワークまたはサーバ故障の場合はＴＣＰセッションはホストにおけるタイムアウトとなり、通常の切断は生じない。従って、ＴＣＰセッションが切断されたときに、何らかの機構がＥＣＳＣ１２０およびＰＡＤ４０を更新するために実行されねばならない。
【００８５】
図７Ｆにおいて示されている例においては、顧客とサーバの間の経路はネットワークリンクまたはノードの故障によって中断される。この故障はＴＣＰエージェントおよびクライアントに再送信のしきい値の数になるまでデータの再送信を行わせる。クライアントのＴＣＰエージェントは、それからＴＣＰ接続を中断する。続いて、ＰＡＤ４０におけるＴＣＰセッションのための不活性タイマが満了する。不活性タイマの満了に応答して、ＰＡＤ４０はＴＣＰセッションの状態機械をアイドル状態１４２に更新し、ＴＣＰセッションタイムアウトエラーをＥＣＳＣ１２０に報告する。ＥＣＳＣ１２０はその活性化セッションテーブルからＴＣＰセッションを削除することによってタイムアウトエラーの報告に応答し、ＰＡＤ４０に対してＴＣＰセッションに対するパケットのマーク付けを停止し、このＴＣＰセッションのための設定を削除するよう指示する。ＰＡＤ４０はそれからＴＣＰセッションのための状態機械を削除する。
【００８６】
次に図７Ｇを参照して、ＴＣＰセッションの参加者がＴＣＰセッションに対して急な終了を要求したときの模範的なネットワークアクセスシステムの信号送信を例示する時間−空間図を示す。例示されているように、アプリケーションは、この場合はアプリケーションはサーバアプリケーションであるが、リセット（ＲＳＴ）セグメントを送信することによって突然の終了を知らせる。アプリケーションは、例えば、アプリケーションが接続を中断したいと望んだためとか、ＴＣＰエージェントが解決できない重大な通信障害を検出したといった多くの理由で突然の終了を送り出しうる。ＲＳＴセグメントの受信に応答して、ＰＡＤ４０はそのセッションのためのＴＣＰ状態機械１４０をアイドル状態１４２にリセットし、ＲＳＴセグメントをＥＣＳＣ１２０に渡す。ＲＳＴセグメントの受信に応答して、ＥＣＳＣ１２０はその活性化セッションテーブルからＴＣＰセッションを削除し、ＰＡＤ４０をこのＴＣＰセッションのためのパケットに対して、マーキングするのを止めるよう設定する。ＰＡＤ４０はそれからセッションのためにＴＣＰ状態機械１４０を削除し、クライアントに対してＲＳＴセグメントを送信する。クライアントはそれからＲＳＴセグメントの受信に応答してＴＣＰセッションを終了する。
【００８７】
ＵＤＰ報告機能を用いたコネクションレス転送例
図８Ａ−図８Ｃを参照して、コネクションレス転送プロトコルのためのネットワークアクセスシステム信号送信の３つの例を例示する。各例において、アンリライアブルデータグラムプロトコル（ＵＮＲＥＬＩＡＢＬＥ ＤＡＴＡＧＲＡＭ ＰＲＯＴＯＣＯＬ）（ＵＤＰ）が採用されている。
【００８８】
図８Ａをまず参照して、ＩＰテレフォニー（ｔｅｌｅｐｈｏｎｙ）セッションの音声データの転送としてＵＤＰが使用されているネットワークアクセスシステム信号送信の時間−空間図を示す。図８Ａに例示された例においては、顧客は自分のＩＰテレフォニー（ＩＰＴＥＬ）呼び出しのための保証されたサービスを注文するが、クライアントはＩＰＴＥＬ呼び出しのための保証されたサービスを予約するためにＲＳＶＰの使用をサポートしていない。それにもかかわらず、顧客は以下に記すように、メッセージの交換を介してＩＰＴＥＬ呼び出しのための保証されたサービスを得ることができる。
【００８９】
処理は、顧客が顧客サイトにおいてＩＰＴＥＬ呼び出しを行うクライアントアプリケーションを実行したときに開始する。クライアントアプリケーションはそれから音声データ送信のために割り当てられた利用可能な予備のポートから使用されていないＵＤＰポートを得る。クライアントのアプリケーションはそれからＵＤＰパケットによってカプセル化された音声データを最善努力のトラフィックとしてネットワークを介して送信を開始する。ＰＡＤ４０は音声ポート範囲内でＵＤＰ（すなわちプロトコルタイプ（ＰＴ）＝１７）パケットの流れを検出するよう設定され、ＵＤＰの流れを検出し、それを外部プロセッサ４２内のＩＰ電話サービスコントローラ（ＩＰＴＥＬＳＣ）１２０に報告する。ＩＰＴＥＬＳＣ１２０はポリシーサーバ４８に対してＳＰＩ５６を介したポリシー決定を問い合わせる。ＳＰＩ５６はこの例においてはＣＯＰＳを採用している。ポリシーデータベース４６を参照することによって、ポリシーサーバ４８は顧客が自分のＩＰＴＥＬ呼び出しに対して保証されたサービスを要求していることを判断し、ＩＰＴＥＬＳＣ１２０にＳＡ、ＤＡ、ＰＴ＝１７、ＳＰおよびＤＰによってポリシーされているように、このＩＰＴＥＬセッションのために保証されたサービスを提供するようＩＰＴＥＬＳＣ１２０に指示するポリシー決定を戻す。
【００９０】
ＩＰＴＥＬＳＣ１２０は従って、そのセッションのための不活性タイマを有するようＰＡＤ４０を設定し、ＰＡＤ４０に対してこのＩＰＴＥＬセッションの発生の報告を停止するよう指示する。ＩＰＴＥＬＳＣ１２０はまた、顧客のクライアントアプリケーションがそうすることができないため、ＩＰＴＥＬ呼び出しに対して予約された帯域幅の経路の設定を開始する。予約された帯域幅の経路を設定するために、ＩＰＴＥＬＳＣ１２０はＲＳＶＰ　ＰＡＴＨ　ＭＥＳＳＡＧＥをＰＡＤ４０に送信する。ＰＡＤ４０はＰＡＴＨ　ＭＥＳＳＡＧＥの下流をレシーバに送信する。予約された帯域幅の量と共に予約の承認を指示するために、レシーバはＲＥＳＶメッセージをＰＡＤ４０に送信し、ＰＡＤ４０はＲＥＳＶメッセージをＩＰＴＥＬＳＣ１２０に転送する。それから特定された帯域幅の予約が承認されるか否かが判断される。もしＩＰＴＥＬＳＣ１２０が以前のポリシーサーバ４８の問い合わせに続く十分なポリシー情報をキャッシュしているのであれば、ＩＰＴＥＬＳＣ１２０は帯域幅に関してポリシーサーバ４８に問い合わせる必要はない。しかしながら、もし不十分なポリシー情報をＩＰＴＥＬＳＣ１２０のポリシーキャッシュ１３０に格納（ｃａｃｈｅ）しているときは、ポリシーサーバ４８は特定された帯域幅が予約可能かどうかを再び問い合わせる。もし特定された帯域幅がこの顧客によって予約できるのであれば、ＩＰＴＥＬＳＣ１２０はＩＰＴＥＬセッションのためにＳＶＣまたはＬＳＰのいずれかを設定するように信号送信コントローラ１２８を介して信号送信を開始する。ＡＴＭコアのために両方向のＳＶＣが設定される。代わりに、ＭＰＬＳコアのために二つの単向性のＬＳＰが設定される。このＵＤＰセッションに対するＱｏＳを提供する別の方法はＰＡＤ４０内のマーカー８２に対してＩＰヘッダ内の差別化されたサービス（ＤｉｆｆＳｅｒｖ）を修正するよう指示することを含む。ひとたびＩＰＴＥＬＳＣ１２０がＱｏＳ経路が確立されたということを示すメッセージをネットワークから確認するか接続を受けると、ＩＰＴＥＬＳＣ１２０はＵＤＰパケットのフローをＱｏＳ経路に関連づけるためにＰＡＤ４０を更新する。加えて、ＩＰＴＥＬＳＣ１２０は、ＰＡＤ４０に対して確認メッセージを渡すことによって、ＱｏＳ経路が設定され、予約されたということを確認する。ＰＡＤ４０は確認メッセージをレシーバに渡す。その後、ＵＤＰパケットにカプセル化された音声データは顧客のアプリケーションからＱｏＳ経路を介してレシーバに送信される。
【００９１】
図８Ｂに示すように、ポリシーサーバ４８の問い合わせによって、ＩＰＴＥＬ呼び出しに対するＱｏＳ要求を顧客が有していないということを示すポリシー決定が得られたときは、ＩＰＴＥＬＳＣ１２０は、ＰＡＤ４０がＩＰＴＥＬ呼び出しを再び報告しないようＰＡＤ４０を設定する。加えて、ＩＰＴＥＬＳＣ１２０は、不活性タイマが満了したときには呼び出し報告の禁止が削除されるように、ＩＰＴＥＬ呼び出しに対する不活性タイマを設定する。どのＱｏＳ経路も承認されていないため、ＵＤＰパケットによってカプセル化された音声データは最善の努力をトラフィックとしてネットワーク上で送信される。
【００９２】
図８Ｃを参照して、ＵＤＰセッション不活性タイマの満了に応答してＱｏＳをテアダウン（ｔｅａｒｄｏｗｎ）するために使用されるネットワークアクセスシステムの信号送信を例示する時間−空間ダイアグラムが示されている。ＵＤＰセッション不活性タイマは、図８Ｃに例示されている例においては、ネットワークリンクまたはノードの故障を含む、多くの理由によって満了するが、タイムアウトイベントは顧客サイトにおいて、呼び出しを終え、音声トラフィックの送信を停止する顧客アプリケーションによって引き起こされる。その後、ＵＤＰセッション不活性タイマが満了したとき、ＰＡＤ４０はタイムアウトイベントを検出し、それをＩＰＴＥＬＳＣ１２０に報告する。ＩＰＴＥＬＳＣ１２０はＩＰＴＥＬ呼び出しに対してＳＶＣまたはＬＳＰを解放する（ｒｅｌｅａｓｅ）ための適切な信号送信を開始することによって応答し、解放はＩＰＴＥＬＳＣ１２０へのメッセージによって確認される。ＩＰＴＥＬＳＣ１２０はＩＰＴＥＬ呼び出しに対してＱｏＳ経路を明確にテアダウンするためにパスティア（ｐａｔｈｔｅａｒ）メッセージを実行する。このメッセージはネットワークを介してＰＡＤ４０から渡され、パスティアメッセージはＱｏＳ経路にそってインストールされたＲＳＶＰ状態を除去する。ＩＰＴＥＬＳＣ１２０はそれからその活性化セッションテーブルからＩＰＴＥＬ呼び出しを削除し、ＰＡＤ４０をＩＰＴＥＬ呼び出し用のすべての設定されたパラメータを削除する。
【００９３】
ＳＩＰ信号送信を用いたアプリケーションレベルの例
次に図９Ａ−９Ｅを参照して、この発明に従うネットワークアクセスシステムにおけるアプリケーションレベルＳＩＰ信号送信を示す、時間−空間図の多くを例示する。まず図９Ａを参照して、ＳＩＰ呼び出しの確立の例が示されている。例示された例においては、顧客サイトの呼び出し側は、例えば、マルチメディア会議呼び出しに参加するために呼ばれる側を招待するためにネットワークで呼ばれる側にＳＩＰ　ＩＮＶＩＴＥを発行する。ＰＡＤ４０がＳＩＰに割り当てられたＵＤＰまたはＴＣＰポート範囲によって招待要求を検出したとき、ＰＡＤ４０はＩＮＶＩＴＥ要求を会議呼び出しサービスコントローラ（ＣＣＳＣ）１２０に渡す。ＣＣＳＣ１２０はそれから要求された能力が顧客に対して承認されるかどうかに関してポリシーサーバ４８（例えばＬＤＡＰ要求を使用して）問い合わせる。重要なことは、ＣＣＳＣ１２０とポリシーサーバ４８との間で交換されるメッセージの数を減らすために、ＣＣＳＣ１２０はポリシーサーバ４８がＣＣＳＣ１２０のポリシーキャッシュ１３０内のＳＩＰ要求に対するポリシー検査をダンプ（ｄｕｍｐ）することを要求するための問い合わせにおいてフラグを好ましくは設定する。このようにして、ＣＣＳＣ１２０はその後キャッシュされたポリシーを参照することによってポリシーの決定を行うことができ、ポリシーサーバ４８の不必要な問い合せを避けることができる。
【００９４】
ポリシーサーバ４８がＳＩＰセッションを承認したと仮定して、ポリシーサーバ４８はＣＣＳＣ１２０にＳＩＰセッションの承認を指示するポリシー決定を送信し、ＣＣＳＣ１２０のポリシーキャッシュ１３０にＳＩＰ呼び出しのためのポリシー規則をダンプする。ＳＩＰセッションの承認を受信すると、ＣＣＳＣ１２０はＰＡＤ４０にＩＮＶＩＴＥメッセージを戻す。ＰＡＤ４０はＩＮＶＩＴＥ要求を呼ばれる側へ転送する。
【００９５】
ＩＮＶＩＴＥ要求に応答して、呼ばれる側はＰＡＤ４０にＳＩＰ２００ＯＫメッセージを戻し、それによって特定されたＳＩＰ能力の変更のない呼び出しの承認応答を示す。ＳＩＰ能力における変更がないために、ＰＡＤ４０は呼び出し側に直接ＳＩＰ２００ＯＫメッセージを転送し、ＣＣＳＣ１２０にはメッセージを渡さない。呼び出し側はそれからＡＣＫ要求を介してＳＩＰ２００ＯＫメッセージの受け入れを応答する。これによってＰＡＤ４０はＣＣＳＣ１２０にＳＩＰセッションの確立の成功を知らせる。ＣＣＳＣ１２０はそれからＳＩＰ呼び出しの最終能力セットを承認するために、そのポリシーキャッシュ１３０に問い合わせる。ＣＣＳＣ１２０はその活性化セッションテーブルにＳＩＰセッションを加え、ＳＩＰ呼び出しを容易にするために、ＰＡＤ４０に不活性タイマと他のパラメータを設定する。ＣＣＳＣ１２０はそれからＰＡＤ４０にＡＣＫ要求を戻し、ＰＡＤ４０は順にＳＩＰ呼び出し確立を達成するために呼ばれる側ＡＣＫを送信する。
【００９６】
よりよい性能を得るために、ＰＡＤ４０からＣＣＳＣ１２０へおよびＣＣＳＣ１２０からポリシーサーバ４８へ渡されるメッセージを最小にするのが好ましい。上で議論したように、ＣＣＳＣ１２０でポリシー規則をキャッシュすることによって、要求されるポリシー問い合わせの数を大幅に減らすことができる。ＰＡＤ４０からＣＣＳＣ１２０へ渡されるメッセージはＰＡＤ４０にあるＳＩＰ状態機械の実行を介して減らすのが好ましい。ここで、ＰＡＤ４０は、ＳＩＰセッションの能力の組を確立、終了または変更するだけのためにＣＣＳＣ１２０にＳＩＰメッセージを渡す。
【００９７】
図９Ｂを参照してＳＩＰ呼び出し終了のための模範的なネットワークアクセスシステム信号送信を例示する、時間−空間図が示されている。多数当事者のＳＩＰ会議呼び出しにおいては、各当事者は呼び出しから自分自身を脱落させることだけができ、呼び出しは最後の当事者が呼び出しから去った後で終了する。一方、図９Ｂに例示されているような２当事者のＳＩＰ呼び出しにおいては、呼ばれる側または呼び出し側が呼び出しを終了することができる。図９Ｂに示されているように、顧客サイトの呼び出し側がＰＡＤ４０がＣＣＳＣ１２０に渡すＢＹＥ要求を送信することによって呼び出しの終了を開始する。ＣＣＳＣ１２０はＢＹＥ要求に対して、その活性セッションテーブルからＳＩＰセッションを削除することによっておよびポリシーキャッシュ１３０からＳＩＰセッションに関連するポリシー規則を取り除くことによって応答する。ＣＣＳＣ１２０はそれからＰＡＤ４０が、ＳＩＰ呼び出しからＣＣＳＣ１２０へ、続くＳＩＰメッセージを渡さないよう、また、ＳＩＰ呼び出しに対する全設定を削除するようＰＡＤ４０を設定する。ＣＣＳＣ１２０はまたＢＹＥ要求を呼ばれる側に転送するＰＡＤ４０にＢＹＥ要求を送信する。ＢＹＥ要求の受信に応答して、呼ばれる側はＳＩＰ２００ＯＫメッセージを送信することによってＳＩＰ呼び出しの終了に応答する。ＰＡＤ４０はＳＩＰ２００ＯＫメッセージをＣＣＳＣ１２０に渡すことなく呼び出し側に転送する。
【００９８】
図９Ｃを参照して、許可された期間を超えたＳＩＰ呼び出しを終了するための模範的なネットワークアクセスシステムの信号送信を示す時間−空間を例示する。示された例においては、ＳＩＰ呼び出しの終了はＣＣＳＣ１２０が、ＳＩＰ呼び出しがセッションの終了タイマによってポリシーされた許可された期間を超えたということを検出することによって開始される。呼ばれる側は、それから呼び出しを終了するためにＢＹＥ要求を発行する。ＢＹＥ要求の受信に応答して、ＰＡＤ４０はＢＹＥ要求をＣＣＳＣ１２０に渡す。これによって、ＣＣＳＣ１２０はその活性化セッションテーブルからＳＩＰセッションを削除し、そのポリシーキャッシュ１３０から関連したポリシーを除去する。ＣＣＳＣ１２０はそれからＰＡＤ４０を、ＰＡＤ４０がＳＩＰ呼び出しにおいて、続くＳＩＰメッセージをＣＣＳＣ１２０に渡さないよう設定すると共に、ＰＡＤ４０にＳＩＰ呼び出しに対するすべての設定を削除するよう命令する。ＣＣＳＣ１２０はそれからＢＹＥ要求をＰＡＤ４０に発行する。ＰＡＤ４０はＢＹＥ要求を呼び出し側および呼ばれる側の両方に転送する。呼び出し側および呼ばれる側はそれからＳＩＰ２００ＯＫメッセージを介してＳＩＰセッションの終了に応答する。
【００９９】
図９Ｄはどの当事者も呼び出し要求の終了をしないで、そのかわりに両当事者が単にＳＩＰセッションを単に終了する、第３の呼び出し終了例を例示する。ＳＩＰセッションにおける活性がないときは、ＳＩＰ呼び出しのためのＰＡＤ４０における不活性タイマは終了する。ＰＡＤ４０はそれからＣＣＳＣ１２０にタイムアウトを報告する。ＣＣＳＣ１２０はその活性セッションテーブルからＳＰＩセッションを削除し、そのポリシーキャッシュ１３０から関連したポリシーを除去する。ＣＣＳＣ１２０はそれからＰＡＤ４０に対してＳＩＰ呼び出しのためのすべての設定を削除するよう命令する。
【０１００】
次に図９Ｅを参照して、呼び出し側と呼ばれる側との間のＳＩＰ呼び出し能力要求の交渉における模範的なネットワークアクセスシステム信号送信を示す時間−空間図を例示する。図９Ａに関して上で述べたように、ＳＩＰ呼び出しはＳＩＰ　ＩＮＶＩＴＥ要求を発行する顧客サイトで顧客アプリケーションによって開始される。このＩＮＶＩＴＥ要求はＰＡＤ４０によって捕獲され、ＣＣＳＣ１２０に渡される。ＣＣＳＣ１２０はポリシーサーバ４８に問い合わせを行う。ポリシーサーバ４８はＳＩＰ呼び出しの承認およびこのＳＩＰセッション（ポリシー要求において要求されたように）に対するポリシー規則のダウンロードで応答する。ＣＣＳＣ１２０はそれからＩＮＶＩＴＥ要求を、呼ばれる側へ転送するＰＡＤ４０に戻す。
【０１０１】
しかしながら、図９Ａに例示された例と対照的に、呼ばれる側はＳＩＰ呼び出しを確認するＳＩＰ２００ＯＫメッセージで応答を行わない。代わりに、呼ばれる側はＳＩＰ６０６ＮＯＴ　ＡＣＣＥＰＴＡＢＬＥメッセージと共に応答する。このメッセージは、要求された呼び出し帯域幅は呼ばれる側のアクセスリンクによってサポートされうるものよりも高くかつ、単に５６Ｋｂｐｓ接続が可能であるということを示す。ＩＮＶＩＴＥ要求によって要求されるように、呼ばれる側の応答は、例えば、単にＰＣＭ（パルスコードモジュレーション）または線形予測複合化（ＬＰＣ）オーディオがサポートされうる（その優先順で）メディア符号化の組を表示する。ＳＩＰ６０６ＮＯＴ　ＡＣＣＥＰＴＡＢＬＥメッセージの受信に応答して、ＰＡＤ４０はＣＣＳＣ１２０にメッセージを渡す。ＣＣＳＣ１２０は局所的なポリシーキャッシュ１３０に問い合わせ、新しい可能性の組を承認する。ＣＣＳＣ１２０はそれからＳＩＰ６０６ＮＯＴ　ＡＣＣＥＰＴＡＢＬＥメッセージをＰＡＤ４０に戻し、ＰＡＤ４０はそのメッセージを呼び出し側へ渡す。
【０１０２】
呼び出し側がＳＩＰ６０６ＮＯＴ　ＡＣＣＥＰＴＡＢＬＥ応答を受け取ると、呼び出し側は呼び出し能力要求を調整し、５６Ｋｂｐｓ帯域幅、ＬＰＣオーディオ符号化および満了タイマ１２０分を特定する別のＩＮＶＩＴＥ要求を発行する。前と同様に、新しいＩＮＶＩＴＥ要求はＰＡＤ４０によってＣＣＳＣ１２０に渡される。ＣＣＳＣ１２０はそれからその局地的なポリシーキャッシュ１３０に問い合わせ、リソースの利用可能性に応じて呼び出し期間として１００分を限定する。ＣＣＳＣ１２０はそれからＰＡＤ４０に対して満了タイマに１００分を設定したＩＮＶＩＴＥ要求を戻し、ＰＡＤ４０はＩＮＶＩＴＥ要求を呼ばれる側に送信する。
【０１０３】
この第２ＩＮＶＩＴＥ要求の受信に応答して、呼ばれる側は呼び出し期間として１００分を含むすべての呼び出し要求をサポートできるということを決定する。従って、呼ばれる側は満了タイマとして１００分が設定されたＳＩＰ２００ＯＫメッセージで応答する。ＳＩＰＯＫ応答の受信に応答して、ＰＡＤ４０は応答をＣＣＳＣ１２０に送信し、ＣＣＳＣ１２０はそのポリシーキャッシュ１３０を参照してＳＩＰＯＫ応答に搬送されているＳＩＰ可能セットをチェックしてそれを承認する。ＣＣＳＣ１２０はそれからＰＡＤ４０にＳＩＰＯＫ応答を送信し、ＰＡＤ４０はＳＩＰＯＫ応答を呼び出し側に転送する。呼び出し側がＳＩＰＯＫ応答を受信すると、呼び出し側はその満了タイマを１００分に修正してＡＣＫ要求を介してＳＩＰＯＫを応答する。ＰＡＤ４０はＡＣＫ応答をＣＣＳＣ１２０に渡し、ＣＣＳＣ１２０はＡＣＫ応答に搬送された最終のＳＩＰ能力セットを承認する。この承認に引き続いて、ＣＣＳＣ１２０はＰＡＤ４０に不活性タイマおよびＳＩＰ呼び出しを容易にするための他のパラメータを設定する。ＣＣＳＣ１２０はまたＰＡＤ４０にＡＣＫメッセージを戻し、ＰＡＤ４０はＡＣＫメッセージを呼ばれる側に転送する。呼ばれる側によって、ＡＣＫ応答が受信されたら、ＳＩＰ呼び出しは成功裏に確立される。
【０１０４】
ＩＰマルチキャストの例
現状のネットワークにおいて実施されているように、ＩＰマルチキャスト、すなわち、パケットを２またはそれ以上のレシーバに配送するために通信の「オープングループ」モデルを採用している。この開放グループモデルによれば、ソースはパケットを送信するマルチキャストのアドレスを単に知る必要があるが、マルチキャストセッションに参加している「グループ」の構成員を知る必要はなく、自分たちがマルチキャストパケットを送信しているマルチキャストグループに属している構成員を知る必要もない。さらに、マルチキャストグループメンバーが任意にマルチキャストグループに参加または撤退できるということを意味する、グループメンバーが、登録し、同期しまたは交渉する必要がある中央グループ管理団体はない。
【０１０５】
マルチキャスト通信の現状のオープングループモデルはマルチキャスト通信の管理またはマルチキャスト通信の制御を許容していないが、マルチキャストグループ構成員の管理および制御は送信者および受信者の両方にとって重要である。送信者にとっては、権限のあるソースのみがパケットをマルチキャストグループに送信できるということが重要である。例えば、コンテンツプロバイダはマルチキャストグループに対する唯一のデータソースとしての独占性を保護したいとしばしば望み、権限のないソースによる洪水によるサービス拒否の攻撃を避けたいと望む。マルチキャストグループにおいてレシーバの組に対しても同様にソースによって権限を与えられた当事者に対するパケットの受信が制限されるように制御することも同様に重要である。例として、ソースはビデオ配信およびビデオ会議マルチキャストパケットを受信することのできるレシーバを制限することを望む。従来のＩＰマルチキャストオープングループモデルの問題点は上記した通りであるが、この発明のネットワークアクセスシステムの構成（ａｒｃｈｉｔｅｃｔｕｒｅ）は図１０Ａ−１０Ｈに例示されているようにポリシーに基づくマルチキャストサービス管理を実行する。
【０１０６】
図１０Ａ−１０Ｂをまず参照して、この発明に従う新しいマルチキャストグループの登録を管理するための模範的なネットワークアクセスシステム信号送信を示す時間−空間図が表示される。図１０Ａに示すように、顧客サイトのホストはＰＡＤ４０を介してアクセスルータ４４にインターネットグループマルチキャストプロトコル（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ）（ＩＧＭＰ）ジョイングループレポートメッセージ（Ｊｏｉｎ−Ｇｒｏｕｐ Ｒｅｐｏｒｔ Ｍｅｓｓａｇｅ）を送ることによってマルチキャストグループ（新しいマルチキャストグループであってもよい）に参加を希望する信号を送る。プロトコルタイプ（ＰＴ＝２）を検査することによって、ＩＧＭＰメッセージを捕獲するよう設定されたＰＡＤ４０のパケットヘッダーフィルタ８０はジョイントグループレポートメッセージを外部プロセッサ４２のマルチキャストサービスコントローラ（ＭＳＣ）１２０に転送する。ジョイントグループレポートメッセージの受信に応答して、ＭＳＣ１２０はＳＰＩ５６を介してポリシーサーバ４８に問い合わせる。ＳＰＩ５６はこの場合はＬＤＡＰを採用している。ポリシーサーバ４８はホストのＩＰアドレスがマルチキャストグループのための資格のある構成員リストに属しているかどうかを判定するためにポリシーデータベース４６を調査することによって問い合わせに応答する。
【０１０７】
図１０Ｂに示すように、もしポリシーサーバ４８が、ホストがマルチキャストグループに参加する資格を有さないと判定したときは、ポリシーサーバ４８はジョイングループリクエスト（Ｊｏｉｎ−Ｇｒｏｕｐ ｒｅｑｕｅｓｔ）を拒否するポリシーをＭＳＣ１２０に戻す。ＭＳＣ１２０は、権限を有しないホストが、アクセスルータ４４内で新しいマルチキャストグループを登録するのを防ぐジョイングループメッセージを落とすことによって要求の拒否に応答する。ＭＳＣ１２０は不正な試みを検出したり、サービスアタックを拒否するイベントログに権限のない試みを書き込んでもよい。
【０１０８】
代わりに、図１０Ａに示すように、もしポリシーサーバ４８が特定されたマルチキャストグループに参加するホストの要求を認めたときは、ポリシーサーバ４８はＭＳＣ１２０に承認を示すポリシー決定を送信する。ＭＳＣ１２０はＰＡＤ４０にジョイングループレポートメッセージを戻す。ＰＡＤ４０はそれからアクセスルータ４４にジョイングループレポートメッセージを転送する。もしホストがネットワーク上でのマルチキャストグループの最初の構成員であれば、アクセスルータ４４はジョイングループレポートメッセージにおいて報告されたマルチキャストグループをホストが帰属するネットワーク上のマルチキャストグループ構成員のリストに追加する。
【０１０９】
図１０Ｂおよび図１０Ｃを参照して、マルチキャストグループの構成員を決定しようと努めているホスト構成員の問い合わせを使用した模範的なネットワークアクセスシステム信号送信を例示する時間−空間図を例示する。図１０Ｃに示す例においては、ＰＡＤ４０はアクセスルータ４４からネットワークにおいて発生したＩＧＭＰホスト構成員問い合わせメッセージを受信する。パケットヘッダーフィルタ８０はそのポート番号に基づいてこのＩＧＭＰメッセージを捕獲し、ホスト構成員問い合わせメッセージ（Ｈｏｓｔ Ｍｅｍｂｅｒｓｈｉｐ Ｑｕｅｒｙ ｍｅｓｓａｇｅ）を外部プロセッサ４２のＭＳＣ１２０に渡す。ＭＳＣ１２０はそれからホスト構成員問い合わせメッセージのソースアドレスが権限を有するアクセスルータ４４であるかどうかを確認するためにＳＰＩ５６（この例ではＬＤＡＰを採用している）を介してポリシーサーバ４８に問い合わせる。
【０１１０】
図１０Ｂに示すように、もしポリシーサーバ４８がポリシーデータベース４６を参照して、ホスト構成員問い合わせメッセージが特定されないまたは権限を有さないソースからのものであると判定したときは、ポリシーサーバ４８はホスト構成員問い合わせを拒否するポリシー決定をＭＳＣ１２０に戻す。問い合わせの拒否に応答して、ＭＳＣ１２０はホスト構成員問い合わせメッセージを落とし、権限のないホスト構成員問い合わせメッセージの洪水によってネットワークに向けられたサービス拒絶を示してもよい、イベントログに警告メッセージを書き込む。
【０１１１】
他方、もしポリシーサーバ４８がホスト構成員問い合わせを承認し、図１０Ｃに示すようにＭＳＣ１２０にそのように指示したときは、ホスト構成員問い合わせはＰＡＤ４０に戻され、ＰＡＤ４０はホスト構成員問い合わせを顧客サイトのホストに転送する。このように、この発明のネットワークアクセスシステムはホスト構成員問い合わせのポリシーに基づいた管理をサポートしている。
【０１１２】
図１０Ｅ−図１０Ｆを参照して、ネットワークに対してマルチキャストパケットの送信を管理するために使用された模範的なネットワークアクセスシステム信号送信の時間−空間図が例示されている。図１０Ｅ、１０Ｆの両方に示されている例では、顧客サイトのホストは特定のマルチキャストグループにアドレスされたＩＰマルチキャストパケットを送信する。ＰＡＤ４０が最初のマルチキャストパケットを受信したとき、パケットヘッダーフィルタ８０は、そのマルチキャストアドレスを有するパケットが以前受信されたかどうかを決定するための確認をした後でパケットを捕獲する。ＰＡＤ４０はそれから第一マルチキャストパケットを外部プロセッサ４２のＭＳＣ１２０に渡す。ＭＳＣ１２０は、マルチキャストパケットのソースアドレスがマルチキャストパケットを特定されたマルチキャストグループに送信することを承認されているかをうかを判定するためにＳＰＩ５６（これはこの場合ＬＤＡＰを採用している）を介してポリシーサーバ４８に問い合わせる。
【０１１３】
図１０Ｆに示すように、マルチキャストパケットの送信を拒否するポリシー決定の受信に応答して（例えば、マルチキャストパケットを送信するソースは特定されていないかまたは権限を与えられていないために）、ＭＳＣ１２０はソースとマルチキャストアドレスのこの組み合わせのためのマルチキャストパケットを落とすようＰＡＤ４０を設定し、ネットワーク上で特定のソースのマルチキャストパケットの洪水によってサービスの拒絶を示してもよい警告メッセージをイベントログに書き込む。代わりに、もしＭＳＣ１２０がポリシーサーバ４８から図１０Ｅに示すようにマルチキャストパケットを承認するというポリシー決定を受信すれば、ＭＳＣ１２０はＰＡＤ４０をアクセスルータ４４に対してソースとマルチキャストアドレスのこの組み合わせのためのマルチキャストパケットを直接転送し、最初のマルチキャストパケットをＰＡＤ４０に戻すよう設定する。ＰＡＤ４０はそれから最初のマルチキャストパケットをアクセスルータ４４に転送し、流れの中のすべての続くマルチキャストパケットをＭＳＣ１２０に渡すことなく直接アクセスルータ４４に転送する。このように、この発明のネットワークアクセスシステムは承認されたマルチキャストパケットの入来を許容し、権限を有さないパケットの入来を妨げるポリシーベースの決定を利用している。
【０１１４】
図１０Ｇ−図１０Ｈを参照して、ネットワークからマルチキャストパケットの受信を管理するために使用された模範的なネットワークアクセスシステムの信号送信の時間−空間図を例示する。図１０Ｇおよび図１０Ｈに示された例においては、アクセスルータ４４はネットワークからＩＰマルチキャストパケットを受信し、それらをＰＡＤ４０に転送する。最初のマルチキャストパケットの受信に応答して、ＰＡＤ４０のパケットヘッダーフィルタ９０はそのマルチキャストアドレスを有するパケットが以前受信されたかどうかを判定した後でマルチキャストパケットを捕獲する。パケットヘッダーフィルタ９０はそれから外部プロセッサ４２にあるＭＳＣ１２０に最初のマルチキャストパケットを渡す。外部プロセッサ４２はマルチキャストアドレスのソースアドレスが特定されたマルチキャストグループへマルチキャストパケットを送信してもよいと承認されているかどうかを判定するためにポリシーサーバ４８に問い合わせる。
【０１１５】
図１０Ｈに示すように、もしポリシーサーバ４８が例えば、マルチキャストパケットのソースが特定されていないかまたは権限を有していないという理由で、マルチキャストパケットの受信は権限を有していないと判定したとき、ポリシーサーバ４８はＭＳＣ１２０にマルチキャストパケットの受信を拒否するポリシー決定を送信する。マルチキャストパケットの受信の拒否に応答して、ＭＳＣ１２０はＰＡＤ４０をソースおよびマルチキャストアドレスのこの組み合わせに対してマルチキャストパケットを落とすよう設定し、特定のソースアドレスからの権限を有しないマルチキャストパケットが顧客サイトにおいてサブネットワークをあふれさせるような試みを行っているということを示してもよいイベントログに警告メッセージを書き込む。その結果、ソースとマルチキャストアドレスの同じ組み合わせを含む、続くマルチキャストパケットはＰＡＤ４０によって落とされる。
【０１１６】
図１０Ｇに示すように、代わりに、もしポリシーサーバ４８がマルチキャストパケットの受信を承認すれば、ＭＳＣ１２０はソースとマルチキャストのアドレスの同じ組み合わせを含む、続くパケットを顧客サイトに直接転送するようＰＡＤ４０を設定する。ＭＳＣ１２０は最初のマルチキャストパケットをＰＡＤ４０に戻し、ＰＡＤ４０は最初のマルチキャストパケットおよび続くマルチキャストパケットを顧客サイトに転送する。図１０Ｈに例示するように、流れの中の、続くマルチキャストパケットはＰＡＤ４０によってＭＳＣ１２０に渡すことなく直接顧客サイトに転送される。
【０１１７】
結論
述べてきたように、この発明は分散されたネットワークアクセスシステム構成を導入する。この発明の分散されたネットワークアクセスシステム構成は従来の融通のきかないエッジルータを、少なくともフィルタ処理および転送機能を含むプログラム可能なアクセス装置と、ＰＡＤのポリシーに基づく制御を実行する１またはそれ以上のサービスが特定されたサービスコントローラおよび基本的なルーティングを行うアクセスルータと置き換える。この分散された構成は従来の融通のきかないルータ構成に対して、拡張性、柔軟性、拡大性、相互操作性、セキュリティ、サービス提供性を含む多くの利点を有している。
【０１１８】
この発明のネットワークアクセスシステム構成は３つの論理モード間の機能性の分散のおかげで従来の融通性のないルータと比べて優れた拡張性を達成している。３つの論理モードは、プログラム可能なアクセス装置、サービスコントローラを提供する外部プロセッサおよびアクセスルータである。特に、プログラム可能なアクセス装置と外部プロセッサによって実行される機能性からアクセスルータによって実行されるルーティングを分離することによって、サービス要求および顧客要求に従って、外部プロセッサモジュールとプログラム可能なアクセス装置とを単に加えることによってアクセスルータに過負荷を与えることなく付加的なトラフィックおよびサービスを処理できる。加えて、インターネットトラフィックパターンは地域的に集中されたものからグローバルに分散されたものまで変化を続けており、地域的なルーティングから離れたネットワークアクセスポイントでのサービスおよびポリシー制御を適応する能力のおかげで、離れた目的地に向かうトラフィックの転送のためのより拡張性のあるデザインを提供できる。
【０１１９】
この発明の分散されたネットワークアクセスシステム構成はまた改良された柔軟性を提供する。このような柔軟性はプログラム可能なアクセス装置の機能モジュールのサービス制御およびプログラム性を支配するポリシーをサービスプロバイダおよび／または顧客が実行する能力の自然の成り行きである。例えば、プログラム可能なアクセス装置のパケットヘッダーフィルタは、ＴＣＰ、ＳＩＰおよびＩＧＭＰのような高い層のプロトコル情報とＳＡ、ＤＡ、ＴＯＳ／ＤＳＣＰ、ＰＴ、ＳＰおよびＤＰの任意の組み合わせに基づくパケットフローとを区別するよう設定されうる。加えて、プログラム可能なアクセス装置のモニタは外部プロセッサのサービスコントローラによって、ＳＡ、ＤＡ、ＴＯＳ／ＤＳＣＰ、ＰＴ、ＳＰ、ＤＰまたは他のフィールドの任意の組み合わせに対する統計を収集しかつ収集された統計に基づいてイベント（例えば、過度のＴＣＰ再送信およびＲＴＰ／ＵＤＰ不活性）を報告するよう外部プロセッサのサービスコントローラによってプログラムされうる。そのようなモニタのひとつの特別に有益な応用は、活性化されたＳＬＡがネットワークを通して維持されることを確実にするために異なるレイヤ２、レイヤ３、レイヤ４およびより高いレイヤのトラフィックタイプに対する統計を追跡することである。ネットワークにおける動的ＳＬＡを提供するためのこのポリシーに基づくアプローチはＳＬＡに対する現在のＴＤＭ（時分割多重化）よりもより柔軟性のある解決方法である。
【０１２０】
拡張性の利点は部分的には、外部プロセッサにおけるサービスコントローラによって提供されるサービスに特定された制御によって生じる。そのようなサービスに特定された制御は専用化されたサービスコントローラかまたは各々がサービスに特定されたＡＰＩをサポートする汎用コントローラのいずれかで実行されうる。選択された実施例にかかわらず、新しいサービスが単に新しいサービスコントローラを加えるかまたは既存のサービスコントローラを単に修正するだけで導入しうる。新しいサービスの追加はプログラム可能なアクセス装置、アクセスルータまたは他のサービスコントローラに対して何の変更も要求しない。このように、他のサービスはサービスの向上時に妨げられない。さらに、サービスコントローラはプログラム可能なアクセス装置およびアクセスルータと独立しているため、新しいサービスの発展および既存のサービスの改善は独自性の強いハードウエアの供給メーカに依存しない。このことは、サービスの開発および改善のための時間とコストを大幅に減少させる。
【０１２１】
この発明の拡張性はプログラム可能なアクセス装置において実行されてもよい追加のモニタ機能にまた起因する。これは例えば、メモリダンプおよび他の関連した情報をサービスコントローラにセーブし、報告することによって標準に適合しているかどうかを検証し、コードをデバッグしおよび故障診断を手助けする等を含む。そのような能力は従来のスイッチまたはルータに一体化されず、外部ネットワークモニタ装置を追加することによってのみ通常は達成される。この発明によって提供される向上した使用モニタはサービスプロバイダがネットワークリソース（すなわち能力）を動的に、一方でＳＬＡに適合した状態で販売することを可能にする。これはネットワークの使用を改良するだけでなく、ネットワーク管理費用を減らすトラフィックエンジニアリングを自動化する。
【０１２２】
上記したように、この発明の分散されたネットワークアクセスシステムはプログラム可能なアクセス装置、サービスコントロールを提供する外部プロセッサおよびアクセスルータ間でネットワークアクセス機能を分散する。これらの異なる要素は明確に定義されたインターフェイスを介して通信するため、相互運用性は同じ供給メーカによって開発されるすべてのハードウエアまたはソフトウエア要素に依存しない。
【０１２３】
この発明はサービスの窃盗およびネットワークに対する攻撃に対するセキュリティを向上させている。例えば、プログラム可能なアクセス装置の転送機能はより低い安全環境に置く一方で、外部プロセッサは、安全な環境に維持されてもよい。加えて、安全ソフトウエアおよび／またはハードウエアは、容易に外部プロセッサに一体化される。その結果、（他の権限のない通信と同様に）、そのマスタ外部プロセッサ以外のＩＰアドレスからのプログラム可能なアクセス装置を設定したセッションはネットワークに渡されることなく、プログラム可能なアクセス装置のパケットヘッダーフィルタによって拒絶される。
【０１２４】
この発明はまた向上したサービスを提供できる。プログラム可能なアクセス装置がネットワークを、転送およびアプリケーションレベルをメッセージを遮断し、それによって、アプリケーションとユーザの特定を可能とするため、この発明のネットワークシステムはユーザアプリケーションのデータフローに対して適切な優先権の確立または望ましい帯域幅の提供が可能になる。例えば、ＲＳＶＰおよびＬＡＮサブネット帯域幅マネージャ（ＳＢＭ）を採用することによって、顧客のアプリケーションは保証された帯域幅および局地的および広い領域におけるネットワークにおいて端末相互間で優先権を提供される。重要なことは、利用可能なネットワーク能力に基づいて顧客のアプリケーションに対して帯域幅の予約、許可制御の実行およびトラフィックの流れを優先させることを可能にするポリシーは、サービスプロバイダだけでなく、顧客によってでも決定されうる。このように、顧客のアプリケーションは、動的にサービスを提供し、アプリケーションに保証されたサービスの質を提供するためにサービスプロバイダネットワークのリソースと相互作用できる。ポリシー制御によって実施されるこのネットワークに基づいた提供は、時間のかかるまたエラーの多いＯＳＳ（オペレーションおよびサポートシステム）の提供に取って代わり、それによってＩＰを中心とした顧客アプリケーションのためのネットワーク提供に対する集中とコストを削減する。
【０１２５】
上記利点があるとしても、この発明の分散されたネットワークアクセスシステム構成はコスト的に効率のよいネットワークソリューションを提供できる。現在のところ、サービスプロバイダに対する傾向はより「インテリジェント」でありそれゆえより高価な装置を自分たちのネットワークデザインの端部に設置することが推し進められている。しかしながら、このデザインは顧客に対してインテリジェントでそれゆえ高価なＣＰＥ（顧客施設装置）を購入することを要求する。一方、この発明の分散されたネットワークアクセスシステム構成は比較的安価なＰＡＤをサポートし、このＰＡＤは顧客が不当な出費なしでサービスの配送を提供できるための十分なインテリジェンスを購入することを可能にする。
【０１２６】
発明が好ましい実施例を参照して示しまた述べられたが、当業者にとって発明の精神および範囲から離れることなくその中で形式および詳細において各種の変更がされることが理解される。例えば、この発明の局面はこの発明の機能に向けられたソフトウエアを実行するコンピュータシステムに関して述べられたが、この発明は代わりにデータ処理システムと共に使用されるプログラムプロダクトとして実行されてもよい。この発明の機能をポリシーしたプログラムは各種の信号を担持する媒体を介してデータ処理システムに配送されうる。そのような媒体は、特に限定はないが、再書き込みのできない記録媒体（例えばＣＤ−ＲＯＭ）、再書き込み可能な記録媒体（例えばフロッピーディスクまたはハードディスクドライブ）、およびデジタルおよびアナログネットワークのような通信媒体を含む。それゆえ、そのような信号を担持した媒体は、この発明の機能に向けられたコンピュータ読み取り可能な命令を搬送または符号化したとき、この発明の代わりの実施例に相当するということを理解すべきである。
【図面の簡単な説明】
【図１Ａ】集合体とコアルータを含む、先行技術のインターネットサービスプロバイダネットワークの都市図である。
【図１Ｂ】この発明に従うインターネットサービスプロバイダネットワークの都市図である。
【図２】この発明に従う通信ネットワークの例示的な実施例を示す図である。
【図３】この発明に従うプログラム可能なアクセス装置（ＰＡＤ）の模範的な実施例のより詳細なブロック図である。
【図４】この発明に従う外部プロセッサの模範的な実施例のより詳細なブロック図である。
【図５Ａ】一次サービスコントローラの故障による、二次サービスコントローラへの切り替え時のプログラム可能なアクセス装置と外部プロセッサとの間の模範的な信号送信を例示する図である。
【図５Ｂ】一次サービスコントローラの回復後の、二次サービスコントローラから一次サービスコントローラへの切り替え時のプログラム可能なアクセス装置と外部プロセッサとの間の模範的な信号送信を示す図である。
【図６】リソース予約プロトコル（ＲＳＶＰ）を使用したサービス予約をサポートするための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図７Ａ】ＴＣＰセッション中の模範的なプログラム可能なアクセス装置の動作を例示する状態機械図である。
【図７Ｂ】ＴＣＰ状態メモリが満杯の場合の模範的なプログラム可能なアクセス装置および関連したサービスコントローラの動作を例示する図である。
【図７Ｃ】ＴＣＰセッション確立時の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図７Ｄ】ＴＣＰセッションの切断時の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図７Ｅ】ＴＣＰセッションのための承認された要求に応答して、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図７Ｆ】ＴＣＰセッションタイムアウト時の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図７Ｇ】ＴＣＰセッションが突発的に終了したときの、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図８Ａ】向上したサービスの質（ＱｏＳ）経路を有するＵＤＰ（ユーザデータグラムプロトコル）セッションを確立するための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図８Ｂ】ＵＤＰセッションにおけるパケットが向上されたＱｏＳよりも最善努力型の搬送を受信した場合の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図８Ｃ】タイムアウトしたＵＤＰセッションをテアダウンするための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図９Ａ】セッション開始プロトコル（ＳＩＰ）呼び出しを確立するときの、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図９Ｂ】ＳＩＰ呼び出し終了時の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図９Ｃ】ネットワークによってタイムアウトが検出した後でＳＩＰ呼び出しを終了するための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図９Ｄ】プログラム可能なアクセス装置によるタイムアウトの検出後のＳＩＰ呼び出しを終了するための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図９Ｅ】ＳＩＰ呼び出し交渉時の、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図１０Ａ】マルチキャストグループの登録を認めるための、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図１０Ｂ】マルチキャストグループの登録をするための権限を有さない試みに応答した、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図１０Ｃ】承認されたマルチキャストグループ構成員の問い合わせに応答した、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図１０Ｄ】権限を有さないマルチキャストグループ構成員からの問い合わせに応答した、この発明に従うネットワークアクセスシステムのおける模範的な信号送信を例示する図である。
【図１０Ｅ】ネットワークの外部から承認されたマルチキャストパケットの受信に応答した、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を示す図である。
【図１０Ｆ】ネットワークの外部から権限を有さないマルチキャストパケットの受信に応答した、この発明に従うネットワークアクセスシステムにおける模範的な信号送信を例示する図である。
【図１０Ｇ】ネットワークからの承認されたマルチキャストパケットの受信に応答したこの発明に従うネットワークアクセスシステムおける模範的な信号送信を示す図である。
【図１０Ｈ】ネットワークから受信した権限を有さないマルチキャストパケットを処理するための、この発明に従うネットワークアクセスシステムおける模範的な信号送信を例示する図である。

Claims (49)

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. 特定されたメッセージはインターネットグループマルチキャストプロトコル（ＩＧＭＰ）メッセージである、請求項２６に記載の方法。
45. 特定されたメッセージはリソース予約プロトコル（ＲＳＶＰ）である、請求項２６に記載の方法。
46. 前記プログラム可能なアクセス装置内において、それぞれの複数のプロトコルタイプのための複数のプロトコルに特有の状態機械を維持するステップをさらに含む、請求項２６に記載の方法。
47. 前記複数のプロトコルに特有の状態機械は転送制御プロトコル（ＴＣＰ）状態機械を含み、前記方法はさらに、命令に応答して前記プログラム可能なアクセス装置によって特定のＴＣＰセッションに対して優遇措置を提供するステップをさらに含む、請求項２６に記載の方法。
48. 活性化されたセッションに対して状態情報をプログラム可能なアクセス装置の報告インターフェイスを介して外部のプロセッサへ報告するステップをさらに含む、請求項２６に記載の方法。
49. 報告するステップは、サービスを新しい外部サービスコントローラに割り当てるのに応答して活性化されたセッションに対する状態情報を報告するステップを含む、請求項４８に記載の方法。

Images