JPH09506752A - ネットワーク層経路指定用分散型自律オブジェクト・アーキテクチャ - Google Patents

Abstract

(57)【要約】 機能及びシステム動作を自律ルータ・オブジェクトに分散するネットワーク層経路指定用オブジェクト指向型アーキテクチャが供給される。これらの機能性を各オブジェクトに分散することによって、オブジェクトに対して通常外部のサービス及びデータは、組み込まれるかまたはオブジェクトそれ自体内でアクセス可能である。別の意味において、あるオブジェクトは、ネットワークにわたり分散される；例えば、個別フォワーディング・エンジンが各ネットワーク・インターフェイスに設けられる。好ましい実施例では、各オブジェクトは、次のものを有する：（１）その分類の全てのオブジェクトによって共有される共通の、プロトコル独立機能；（２）それら自体の構成情報；（３）インスタンス生成及び制御のためのルータ資源オブジェクトを通すアクセス可能性；（４）ＮＶＲＡＭにおける自動パーシステンス；（５）遠隔管理ケイパビリティ；及び（６）ファイル・システムとしての資源トゥリーのナビゲーションに対するテキスト名。これらのケイパビリティは、指定プロトコルまたはアプリケーションに係わりなく全てのオブジェクトにある。これは、多くの異なるシステム／ルータ・コンポーネントの間中の共通アーキテクチャ、内部的制御の共通方法、インスタンス生成の一定の順序、及び共通機能動作を確実にする。

Description

【発明の詳細な説明】 ネットワーク層経路指定用分散型 自律オブジェクト・アーキテクチャ 発明の分野 本発明は、通信ネットワーク上のパケットを経路指定する装置及び方法に関し 、特に、プロトコル指定オブジェクトをインスタンス生成するために共通プロト コル独立ベース・オブジェクトを用いかつ重要機能及びシステム動作を自律オブ ジェクトに分散するオブジェクト指向型システムに関する。システムは、多重ネ ットワーク及び経路指定プロトコルを支持し、管理可能であり、かつ新しいプラ ットフォーム、アーキテクチャ及び媒体技術に容易にスケールする。 発明の背景 インテリジェント・ハブは、装置をアクセスするためにネットワーク連結性を 供給すべくネットワークに広く配備されるようになってきた。ネットワークへの アクセスを供給するハブは、アクセス政策の分散及び連結性をエンド・システム ・アタッチメントに密に発生させる。 同時に、ネットワーク・レベル・ルータは、分散型ハブを互いに連結するため に大規模に配備される。過去において、このネットワーク・サービスは、図１Ａ に示すような、集中ルータ装置によって供給されていた。しかしながら、集中ル ータの帯域幅及び物理ネットワーク・インターフェイスの数が飽和すると、増分 分散型サービスを加えることは、高くつく。容量で一度、拡張が取り付けられる べき一つの新しいＬＡＮだけを必要としても別の集中多重ポート・ルータを加え ることは、必要である−−即ち、ＬＡＮアクセス・ポートへの増分は、大きなス テップ機能で行われる。 更なるスケーラビリティを許容するために、ルータ機能は、分散型ハブの中に 統合される。図１Ｂに示すように、これは、ユーザがネットワークの中に物理連 結性を得る点まで経路指定機能性を実質的に“プッシュ”アウトする。更に、こ れらの分散型ルータは、経路指定機能をオフ・ローディングすることによって集 中ルータの中により大きなネットワーク・アクセスを許容する（図１Ｃ）。 経路指定機能性がプッシュ・アウトされかつより広く配備されると、それは、 これら分散型装置の構成及び制御に強大なひずみ(tremendous strain)を設置す る。また、ハブが、大くのＬＡＮ技術によるアクセスを供給するので、ハブのル ータは、同じシャーシで広範囲のネットワーク連結性に対する支持を有さなけれ ばならない。更に、アクセス・ポートの数は、これらのポートがネットワークの エンド・ユーザに連結性を供給するので、１または２から数百まで変化すること ができる。 これらの分散型ハブ及びネットワーク装置において経路指定サービスをインプ リメントすることができるためには、アーキテクチャは、かなりフレキシブルで あり、スケーラブルであり、かつ異なるハブ構成及びシャーシに適応可能であり 、かつ種々の現在及び将来のプロトコルを支持することができる。また、アーキ テクチャは、これらの分散型ハブにおける経路指定の動作及び制御がネットワー クにおけるこれらの装置のシーヤ・ナンバー(sheer number)により及びハブ／ル ータに統合された技術の変化により実質的に更に難しいので、高度の従順性(hig h degree of manageability)を供給することが必要である。 発明の目的及び概要 本発明は、サービスの高い可用性、遠隔管理及び監視、及び相互運用性を供給 する通信ネットワーク上の情報を経路指定する装置及び方法である。 システムは、アンダーライイング・メディア並びにプロトコルの両方における 、変化する技術に対して開放的でありネットワークの大きさを拡張することに対 して開放的であるということを意味する、拡張可能アーキテクチャを有する。 本発明によれば、重要機能及びシステム動作を自律ルータ・オブジェクトに分 散するオブジェクト指向型アーキテクチャが供給される。全てのルータ・オブジ ェクトは、自動的に組み込まれた３つの型の埋め込まれた機能性を含む： １．経路指定機能（例えば、フォワーディング情報ベース、ＦＩＢ）またはシ ステム機能（例えば、事象またはタイマ）でありうる、オブジェクトの共通プロ トコル独立機能。例えば、全てのフォワーディング・エンジンは、特定のプロト コルに関係なくフォワード方法並びにサービス方法を有する； ２．構成及び制御に対する方法及びデータを画定する基礎資源オブジェクト分 類によって供給される機能。例えば、ネットワーク・インターフェイス分類のあ らゆるオブジェクトは、自動的にその内部にネットワーク・インターフェイス− 構成を有する； 及び ３．ネットワーク管理に対する方法及びデータを画定する管理オブジェクト分 類によって供給される機能。 これらの機能を各オブジェクトの中に分散することによって、各オブジェクト は、自律する、即ち、オブジェクトに対して通常外部にあるサービス及びデータ は、オブジェクト自体内に埋め込まれるかまたはアクセス可能である。 別の意味では、あるオブジェクトは、“ネットワークを渡って”分散される、 即ち、一つの中央フォワーディング・エンジンを供給するのとは反対に、本発明 では個別フォワーディング・エンジン・オブジェクトが各ネットワーク・インタ ーフェイスで供給される。 全てのオブジェクトは、バインディング（結び付け）及び順序付けられたスタ ート・アップを許容すべく順序立って全てのオブジェクトをインスタンス生成す る、ルータ資源オブジェクトを通して連結される。一度オブジェクトが存在する と、それらは、それぞれがそれ自体のバインディング及び基本分類において画定 されたオブジェクト動作を知ることにおいて自律する。また、オブジェクトは、 管理に対する管理オブジェクト・フレームワークを通して連結される。 それゆえに、好ましい実施例では、各オブジェクトは、次のものを有する： １．その分類の全てのオブジェクトによって共有される共通、プロトコル独立機 能； ２．それら自体の構成情報； ３．インスタンス生成及び制御（イネーブル、ディスエーブル等）に対するルー タ資源オブジェクトを通すアクセス可能性； ４．要求されたならばＮＶＲＡＭにおける自動パーシステンス(automatic persi stence）； ５．遠隔管理ケイパビリティ（能力）； ６．ファイル・システムとしての資源トゥリーの移動（ナビゲーション）のため のテキスト（例えば、ＡＳＣＩＩ）名。 これらのケイパビリティは、特定のプロトコルまたはアプリケーションに関係 なく全てのオブジェクトに存在する。これは、多くの異なるシステム／ルータ・ コンポーネントの間の共通アーキテクチャ、内部的制御の共通方法、インスタン ス生成の一定順序、共通機能動作（ネットワーキング・セマンティックスにおい て、完全に無関係である、異なるプロトコル・スウィーツにおいても）を確実に する。 ルータは、ネットワーク・レベルでパケットを処理するので、それは、種々の ネットワーク・レベル・パケットを理解しかつ復号することが必要である。最も 普及しているネットワーク・プロトコルのあるものは次の通りである： ・ ＩＰ （ＴＣＰ／ＩＰプロトコル・スウィートに対するインターネット・プ ロトコル） ・ Ｎｏｖｅｌｌ ＩＰＸ ・ Ｘｅｒｏｘ ＸＮＳ ・ Ｂａｎｙａｎ Ｖｉｎｅｓ ＩＰ ・ ＩＳＯ ＣＬＮＳ ・ ＤＥＣＮＥＴ ・ ＡｐｐｌｅＴａｌｋ ルータは、全ての可能なネットワーク・プロトコルをインプリメントしえない 間に、最小の符号化変更で追加のプロトコルを加えることが可能である。 更に、ルータは、多数の異なる経路指定プロトコルを支持することができる。 インターネット・コミュニティ内では、次のものが一般的に用いられる： ・ ＲＩＰ（経路指定情報プロトコル） ・ ＯＳＰＦ（開放最短経路ファースト） ・ Ｄｕａｌ ＩＳ−ＩＳ（中間対中間システム） また、ルータは、種々の通信媒体を支持し、かつ媒体ドライバにネットワーク ・プロトコルをインターフェイスすることができる。 本発明の他の態様は、以下の図面及び詳細の説明においてより完全に説明され る。 図面の簡単な説明 図１Ａは、集中ルータを用いているネットワークの概略図である； 図１Ｂは、分散型ハブ・ルータを用いているネットワークの概略図である； 図１Ｃは、集中ルータ及び分散型ハブ・ルータの両方を用いているネットワー クの概略図である； 図２Ａは、本発明の一実施例による複数の分散型ルータを用いているネットワ ークの概略図である； 図２Ｂは、本発明の一実施例による複数のハブ・ルータを用いているネットワ ークの概略図である； 図３は、個々の“平面”上の各機能サブシステムを示している本発明のルータ の三次元システム・アーキテクチャ・ビューである； 図３Ｂは、“平坦”システムとしてのシステム・アーキテクチャの代替ビュー である； 図３Ｃは、ＲＩＰのような距離ベクトル・プロトコルに対する、経路指定プロ トコル・オブジェクトの概略図である； 図３Ｄは、“ホスト”フォワーディング・エンジン・オブジェクトの概略図で ある； 図３Ｅは、“プロトコル”フォワーディング・エンジン・オブジェクトの概略 図である； 図４は、分散型自律フォワーディング・エンジンのサービス及びフォワード方 法を示しているフロー図である； 図５は、ネットワーク層及びフレーミング・オブジェクト・コンポーネント関 係の概略図である； 図６は、分散型経路指定事象タイマのフロー図である； 図７は、管理オブジェクト・フレームワークの構造の概略図である； 図８は、管理オブジェクトＭＩＢトゥリーの構造の概略図である； 図９は、不揮発性メモリにおけるパーシステント・オブジェクトの記憶を示し ているフロー図である； 図１０は、基本管理モードの概略図である； 図１１は、経路指定サービスに対する共通ＭＩＢテンプレートの概略図である ； 図１２は、基本資源、資源表、及び資源エントリ間の関係の概略図である； 図１３は、基本資源分類階層の概略図である； 図１４は、基本資源分類階層の一例である； 図１５は、基本資源のサービス、コンポーネント及びインターフェイス・レベ ルでの表における登録の概略図である； 図１６は、ルータ・サービスの場合及びルータ・コンポーネントの場合の一例 を示している概略図である； 図１７は、サービス、コンポーネント、及びインターフェイスのルータ資源階 層の概略図である； 図１８は、従来のＳＮＭＰ方法でオブジェクトをアクセスする方法の概略図で ある；及び 図１９は、ＭＩＢナビゲータを用いてオブジェクトをアクセスする新しい方法 の概略図である。 実施例 図２Ａは、本発明の経路指定装置及び方法を用いているネットワークの一実施 例を示す。ネットワーク１００は、それぞれが４つのルータ１０５、１０６、１ ０７、１０８に各々連結される４つのサブネット１０１、１０２、１０３、１０ ４として概略的に示される。各サブネットは、例えば、それぞれがその関連マル チポート・ルータのポートに連結される複数のＬＡＮｓを含みうる。４つのルー タは、リンク１０９によって連結される。この実施例では、ルータは、（中央ル ータ・バックボーンとは反対に）ネットワークにおいて外側に向かってプッシュ されかつネットワーク・アクセス地点として役立つ。これは、ネットワークが別 のルータ及び関連サブネットを加えることによって容易に拡張することができる ようにスケーラビリティを供給する。各ルータは、適用可能なアーキテクチャを 有するので、多重（複数）のプロトコルを処理することができかつ遠隔管理を条 件としており、従って、ネットワーク全体を“全体として”管理することができ る。 図２Ｂは、図２Ａのネットワークに使用するインテリジェント・ハブ・ルータ ル３１２を示す。ハブ・ルータは、複数の差し込みモジュール３１４〜３２１を 伴うシャーシ３１３を有する。ハブは、チャネルＡ，Ｂ及びＣの各々の３つの個 別サブネット３２２、３２３、３２４をそれぞれアクセスする。各チャネルは、 ネットワーク・インターフェイスに等しい。それゆえに、モジュール３１４〜３ １５は、第１のサブネット３２２へのチャネルＡ上のアクセスを供給する；モジ ュール３１６〜３１８は、第２のサブネット３２３へのチャネルＢ上のアクセス を供給する；及びモジュール３１８〜３２０は、第３のサブネット３２４へのチ ャネルＣ上のアクセスを供給する。次いでモジュール３２１は、ネットワーク・ バックボーン、即ち、図２Ａのネットワークにおける他のルータへのチャネルＤ 上のアクセスを供給する。 本発明は、その全体が参考文献としてここに組み込まれる、Grady Booch，“O bject-Oriented Analysis And Design，With Applications”,Second Edition， Benjamin Cummins Publishing，1994に画定されるような“Object-oriented pro gramming”を用いる。データ及び動作は、分類及びオブジェクトの基本論理構築 ブロックの中に統一される。オブジェクト指向型プログラミングは、各々がある 分類の一例を表し、かつその分類が継承関係を介して統一された分類の階層のメ ンバーである、オブジェクトの協調収集(cooperative collections)としてプロ グラムが編成されるようなインプリメントの方法として画定されうる。Booch の 第２章を参照。よく知られたオブジェクト指向型言語は、Ｃ＋＋、SmallTalki、 Object Pascal、CLOS、及びEffifelを含む。ここに記載された実施例では、Ｃ＋ ＋言語が用いられる。 用語“ルータ”及び“経路指定装置”は、ネットワーク層でパケットを前に進 めることができかつ種々の交換プロトコールに用いられるネットワーク・トポロ ジー情報を交換することができるソフトウェア及びハードウェアを含むべくこの 明細書の中で広く用いられる。 この明細書において、“ネットワーク”は、ローカル・エリア・ネットワーク 、ワイド・エリア・ネットワーク、及びインターネットとして知られる、ゲート ウェイ（またはルータ）によって一緒に連結された複数のネットワークを含むべ く一般的に用いられる。 本発明のルータは、次のサブセクションにおいてここでより特定的に説明され る： Ａ．フレームワーク Ｂ．フォワーディング・エンジン Ｂ．１ フォワード及びサービス Ｂ．２ キャッシュ Ｂ．３ アクセス・リスト Ｂ．４ フレーミング Ｂ．５ 事象ファネル Ｃ．経路指定プロトコール Ｄ．管理オブジェクト Ｅ．共通ＭＩＢテンプレート Ｆ．共通ベース・ルータ資源 Ｇ．ＭＩＢナビゲータ Ａ．フレームワーク インターネットワーキング及び通信システムは、離散的サブシステムのセット を中核にして一般に作られる。これらの離散的サブシステムが高度に統合されう ると同時に、それらは、機能的に個別の部分として動作する。例えば、処理機能 は、構成データ及びネットワーク管理から分離して存在する。更に、多重通信プ ロトコル・スタックが支持され、それぞれが、全体的に個別の構成、制御、監視 、ネットワーク管理、及びプロトコル−指定の行動／機能性を有する、完全に異 なる“垂直”スタック、例えば、ＩＰ Ｓｔａｃｋ、ＩＰＸ Ｓｔａｃｋ、ＤＥ Ｃｎｅｔ Ｓｔａｃｋとして存在する。インプリメントされうる他のスタックと は独立に存在することができるアプリケーションとして各通信スタックを考える 。 本発明の分散型オブジェクト・アーキテクチャは、インスタンス生成により全 てのプロトコル指定オブジェクトによって承継される、汎用の、共通プロトコル 独立フレームワークをインプリメントすべく機能態様の全てを画定する。システ ム・スタートアップ／初期化で、Ｒｏｕｔｅｒ Ｒｅｓｏｕｒｃｅ（ルータ資源 ）オブジェクトは、バインディング及び順序付けされたスタート・アップを許容 すべく順序立って全てのオブジェクトをインスタンス生成する。一度オブジェク トが存在したならば、それらは、それぞれが、基本分類において画定されたそれ 自体のバインディング及びオブジェクト動作を知るように自律する。 図３Ａは、オブジェクト間の論理関係を示している本発明によるシステム・ア ーキテクチャの三次元ビューであり、ここでは各機能サブシステムが個別“平面 ”として示される。それゆえに、システム・アーキテクチャ２００は、４つの水 平に配置された平面を含む：経路指定アプリケーション２０１；ホスト通信２０ ２；フォワーディング２０３；及びネットワーク・インターフェイス２０４。タ イルされた(tiled)”オブジェクトは、多重インスタンス生成が存在することが できるということを示す；例えば、平面２０３におけるフォワーディング及び経 路指定プロトコル・オブジェクト２３４は、各個々のプロトコルに対してインス タンス生成される。後方に向けて指図された破線矢印２０６は、追加の例が存在 することができることを示す。異なる平面間の連結は、破線２０５によって示さ れる。これらの論理連結は、資源オブジェクト及び名前付けトゥリーを介して行 われる。 また、図３Ａは、全てのオブジェクトが垂直ルータ資源オブジェクト平面２０ ７を通して連結されるということも示す。同時に、管理されるべき全てのオブジ ェクトは、垂直管理オブジェクト平面２０８を通して連結される。 システム・アーキテクチャは、“平坦”システムとして図３Ｂにより把握する こともでき、ここで、対応要素は、主指定(prime designation)で識別される。 再び、全ての管理可能なオブジェクトは、ＭＩＢオブジェクト２０９’、ＭＩＢ トゥリー２１０’、パーシステント・オブジェクト２１１’、ＮＶＲＡＭ管理オ ブジェクト２１２’、ＮＶＲＡＭ２１３’、及びＭＩＢナビゲータ２３１’を含 む、管理オブジェクト２０８’に連結される。同様に、全てのオブジェクトは、 ルータ・サービス２１４’、ルータ・コンポーネント２１５’、ルータ・インタ ーフェイス２１６’、ルータ構成２１７’、及び事象（イベント）２１８’を含 んでいる、ルータ資源オブジェクト２０７’に連結される。 図３Ｂは、経路指定アプリケーション２０１’、ホスト通信２０２’、フォワ ーディング・サービス２０３’、及びネットワーク・インターフェイス・サービ ス２０４’間の連結をより明確に示す。トップからスタートして、経路指定プロ トコル・オブジェクト２１９’は、ＲＩＰ距離ベクトル・プロトコルのような、 各経路指定プロトコルに対してインスタンス生成される。経路指定プロトコル・ オブジェクト２１９’は、事象オブジェクト２２１’、経路指定表オブジェクト ２２３’、ネットワーク・インターフェイス・オブジェクト２２４’、及び近隣 一覧表オブジェクト２２５’のそれぞれに連結される、経路指定プロトコル・ス レッド・オブジェクト２２０’を含むべく更に図３Ｃに示される。事象オブジェ クト２２１’は、タイマ・オブジェクト２２２’及びソケット・オブジェクト２ ２６’に更に連結され、後者は、ホスト通信２０２’のソケット２２７’に線２ ０５’（図３Ｂ参照）を介して連結される。図３Ｂに戻ると、ホスト通信２０２ ’は、ＳＮＭＰエージェント２２８’、タイマ２２９’及びホスト通信スタック ２３０’を更に含み、それらの全ては、ソケット２２７’に連結される。 ホスト通信スタック２３０’は、図３Ｄにより完全に示される、ホスト・フォ ワーディング・エンジン２３２’に共有メモリ・キュー２３６’を介して連結さ れる。エンジン２３２’は、ホスト通信２０２’とフォワーディング・サービス ２０３’との間で共有される、ホスト・メッセージ・キュー・オブジェクト２３ ６’を介してホスト・メモリをアクセスするフォワード及びサービス・オブジェ クト２３５’を含む。また、フォワード及びサービス・オブジェクト２３５’は 、フォワーディング情報ベース（ＦＩＢ）としても知られる、ネットワーク・フ ォワーディング表オブジェクト２３３’もアクセスする。 図３Ｂに戻ると、フォワーディング情報ベース２３３’は、図３Ｅに更に示さ れる複数の“プロトコル”フォワーディング・エンジン２３４’のそれぞれに連 結される。プロトコル・フォワーディング・エンジン２３４’は、アクセス一覧 表オブジェクト２４０’、次のホップ(next-hop)キャッシュ・オブジェクト２４ １’、及びフレーミング・オブジェクト２４２’のそれぞれに連結されるフォワ ード及びサービス・オブジェクト２３９’を含む。フレーミング・オブジェクト ２４２’は、アドレス・キャッシュ・オブジェクト２４３’及びネットワーク・ インターフェイス・オブジェクト２３７’のそれぞれに連結される。次のホップ ・キャッシュ・オブジェクト２４１’は、ネットワーク・フォワーディング表オ ブジェクト２３３’、または図３ＢのＦＩＢに連結される。図３Ｂに戻ると、各 ネットワーク・インターフェイス・オブジェクト２３７’は、ネットワーク媒体 装置ドライバ２３８’の下に連結される。 纏めると、アーキテクチャは、次のサブシステムのそれぞれを含む： １． 管理オブジェクトは、ルータ・オブジェクトに遠隔構成、監視、及び制御 に対するネットワーク管理を埋め込ませる。このフレームワークは、データ素子 またはオブジェクトに、固有のオブジェクト識別子及び名前を含む“管理”可視 性（視認性）を与えさせる。ルータ・オブジェクトの値がシステム・リセット及 び再スタート（パワー・サイクル）を通して維持されかつ復元されることが必要 である場合には、フレームワークは、オブジェクトに、（ＮＶＲＡＭファイル・ システムを用いて）それ自体を節約しかつ復元することによってそれ自体をパー システントさせる。この機能性は、実際のオブジェクトに対して透過である。 ２． 資源オブジェクトは、プロトコル指定オブジェクトに関係なく、共通シス テム・テンプレート（ボイラープレート）を供給する。また、それらは、システ ムにおける全てのルータ・アプリケーションを同じように見せてかつ制御させる 共通ＭＩＢ（管理情報ベース）構造及び内容を実施する。これは、基本的に異な りうるプロトコル・スイート（protocol suites）に供給される。 ３． フォワーディング・オブジェクトは、新しいネットワーク・インターフェ イス及び媒体型にスケールする分散型フォワーディング・アーキテクチャを供給 する。それは、ネットワーク・パケットを切替えると同様に、上層プロトコル・ アプリケーションへ内部的にパケットを送付するためのプロトコル独立フレーム ワークを供給する。各オブジェクトが特定のネットワーク・インターフェイスに バウンド（束縛）されるので、異なる媒体型間のリフレーミング(reframing)も 供給される。 ４． 経路指定プロトコル・オブジェクト(Routing Protocol Objects)は、ネッ トワーク・トポロジー情報を交換しかつパケット・ネットワーク・フォワーディ ングに用いる次のホップ・ルーツを決定する可能性を供給する。これらのオブジ ェクトは、以下のサブセクションで更に説明される。 Ｂ．フォワーディング・エンジン Ｂ．１ フォワード及びサービス 従来の通信アーキテクチャは、送信及び受信のサービスを供給している各層を 有する層状モデルを用いる。一般にパケットは、あるネットワーク・インターフ ェイス上の装置にエンターしかつインターフェイスの上に置かれているプロトコ ル層に手渡される。このプロトコル層は、次にパケットを処理しかつ上記次の層 にそれを手渡す。ルータの場合には、ネットワーク層は、パケットを最終的には 処理し、それがフォワードされなければならないインターフェイスを決定し、か つそれが最終的にフォワーディング・インターフェイスを送り出すまで各層に逐 次パケットを送り返す。 この従来のモデルでは、各プロトコルは、パケットを常に得てそしてそれがイ ンターフェイスに対して適当であったかどうかを決定する。それは、パケットが やってくるインターフェイスに係わりなくシステムに入りかつ出てゆく全てのパ ケットに対してファネルであるプロトコル層を有する集中モデルである。また、 それが集中されるので、各層は、全ての指定インターフェイスについての知識を 持たなければならない。例えば、ＭＴＵサイズ、フォワーディング・イネーブル ド／ディスエーブルド状態、構成ネットワーク・アドレス及びマスク、データ・ リンク・フレーミング・オプション、フィルタ・アクセス・リスト、等のような 全ての構成インターフェイス情報は、それがパケットを処理／フォワードすると きに各層によってアクセスされなければならない。このモデルは、各層の中にオ ーバーヘッドを置き、かつ各層が変更されなければならないときに新しいインタ ーフェイス、媒体、及びプロトコルを支持することを非常に制限している。オー バーヘッドの一例は、イネーブルされないプロトコルに対してパケットが受信さ れたならば、それは、それが正しいプロトコル層にパス・アップされるまで落さ れない(not dropped)ということである。 対照的に、本発明は、図４に示すように分散型自律フォワーディング・エンジ ンを用いる。単一集中フォワーディング・エンジンを有する代わりに、分散型モ デルでは、各インターフェイス１１、１４、１７は、その上に置かれているフォ ワーディング・エンジン１２、１５、１８を有し、かつ各フォワーディング・エ ンジンは、それ自体のインターフェイス上のパケットを受信しかつ送信する方法 を知っている。また、各エンジンは、それ自体の構成情報及びだけを知っており かつそれが関連付けられる一つのインターフェイス上のパケットを受信しかつ送 信する方法だけを知っている。各フォワーディング・エンジンは、共通フォワー ディング表２０をアクセスする。 付記： 図４のインターフェイス・オブジェクト１１、１４は、オブジェクト ２３９’（図３Ｂ及び３Ｅ）に対応しているＦＡＳオブジェクト１２、１５（図 ４）を有する、図３Ｂ及び３Ｅのネットワーク・インターフェイス・オブジェク ト２３７’と同じである。ホスト・インターフェイス・オブジェクト１７（図４ ）は、ＦＡＳオブジェクト２３５’（図３Ｂ）に対応しているホストＦＡＳオブ ジェクト１８（図４）を有する、ホスト・メッセージ・キュー２３６’（図３Ｂ 及び３Ｄ）に対応する。フォワーディング表２０（図４）は、ＦＩＢ２３３’（ 図３Ｂ）に対応する。 “ホスト”ＣＰＵに“ローカル”送付向けパケットのための一定フォワーディ ング・モデルを供給するために、ホストは、宛先アドレスを有する内部インター フェイスとして処理される。ホスト宛先パケットの送付は、フォワーディング機 能に対してバンドのまま残る。 フォワーディング・エンジンの動作は、図４に関してここに説明することがで きる。インターフェイス・オブジェクト−１（１１）上のデータ・パケットの受 け取りに応じて、インターフェイス・オブジェクト１１は、そのバウンドされた フォワーディング・エンジン・オブジェクト１２におけるサービス方法を呼び出 す。サービス方法は、ネットワーク・パケット上のサブレイヤ（副層）フレーミ ングを除去しかつネットワーク・パケットからの宛先ネットワーク・アドレスの 確認及び抽出を実行する。次いでサービス方法は、宛先フォワーディング・エン ジン・オブジェクト処理を決定すべくアクティブ・アドレスのキャッシュ・メモ リにおける宛先ネットワーク・アドレスをルックアップすることによって次のホ ップ決定を供給し、かつ宛先ネットワーク・アドレスがキャッシュ・メモリにお いて位置決めされない（捜し出されない）ならば、宛先ネットワーク・アドレス へのベスト・ルートに対してフォワード・ルックアップ表２０へアクセスし、そ してそのキャッシュを更新する。次いで方法は、宛先フォワーディング・エンジ ン・オブジェクト処理をリターンする。 宛先がインターフェイスＮであると想定すると、宛先フォワーディング・エン ジン・オブジェクト処理の受け取りにより、サービス方法は、宛先フォワーディ ング・エンジン・オブジェクト１５に呼び出される。サービス方法は、宛先アド レスを確認し、宛先の媒体指定アドレスを得るためにアドレス・キャッシュにお いてルックアップを実行し、次いでサービス方法は、パケットをリフレーム(ref rame)しかつそれを宛先インターフェイス１４に転送する。 代替的に、ホストＣＰＵへのローカル送付が要求されるならば、ホストＦＡＳ オブジェクト１８が呼び出されかつパケットがホスト・インターフェイス１７上 に送り出される。 このモデルでは、各フォワーディング・エンジンは、パケットを処理するため に独立して作動するが、それらは、プロトコル独立、インターフェイス独立、か つ非常にスケーラブル（１からｎまでのインターフェイスを支持する）であるシ ステム全体のフォワーディング・サブシステムを一括して供給すべくそれぞれ知 らないで相互に干渉し合う。 本発明のフォワーディング・エンジンは、オブジェクト指向型方法体系を用い てインプリメントされかつ言語Ｃ＋＋で書かれている。Ｃ＋＋オブジェクトを有 することによって、各フォワーディング・エンジンは、例えば、インターフェイ ス及び媒体情報、アドレス分解表、構成情報、等の、それ自体に対して固有なそ れ自体のデータ部分１３、１６、１９を有する。しかしながら、各エンジンの方 法部分１２、１５、１８は、共通でありかつ全ての同様なエンジンによって共有 される。 各フォワーディング・エンジンの特定の目標は、ネットワーク層パケットの受 け取り、処理、及びフォワーディングを供給することである。非常に高いレベル で、全てのフォワーディング・エンジンは、プロトコルまたは媒体に係わりなく これらの同じ基本的タスクを実行する。 全てのエンジンが同じ基本タスクを実行するので、各プロトコル・エンジンは 、共通の基本分類(Base Class)から導き出される。これは、プロトコルに係わり なく各エンジンに対する包括的及び共通(generic and common)インターフェイス を許容する。特に、このBase Classは、当該Base Classから導き出される各プロ トコル・エンジンによって次いで過負荷状態にされる次の仮想方法を画定する： サービス機能は、次のものを含むネットワーク層パケットの実際のイン・バウ ンド処理を参照する： ・ データ・リンク層からのパケットの受け取り ・ 確認及びエラー処理 ・ フィルタ処理 ・ 次のホップを決定するためのルート・ルックアップ処理 フォワード機能は、次のものを含むネットワーク層パケットの実際のアウト・ バウンド処理を参照する： ・ フィルタ処理 ・ ネットワーク層アドレスを物理アドレスに変換する ・ 送信のためにアウトバウンド・インターフェイスのデータ・リンク層にパ ケットをパスする。 共通基本分類から導き出されたプロトコル指定フォワーディング及びサービス （ＦＡＳ）エンジンを有することによって、各プロトコル・フォワーディング・ エンジンは、特定のプロトコル型に係わりなく、パケット・サービシング及びフ ォワーディングのための包括的インターフェイスを有する。これは、各プロトコ ルＦＡＳレジスタに、それがインスタンス生成される各インターフェイスに対す るデータ・リンク・レベルでパケット・ディスパッチャを有するその基本分類へ のポインタを持たせることによってサービス側で行われる。これは、パケット・ ディスパッチャに、プロトコルＦＡＳ指定を知ることなく過負荷状態の仮想サー ビス方法を呼び出させる、即ち、 特定インターフェイスの指定プロトコルＦＡＳに対するサービス機能は、その プロトコルに対するネットワーク層パケットがそのインターフェイスで受け取ら れるときにだけ呼び出される。 同じ概念は、フォワーディング側にも当てはまる。各プロトコルＦＡＳは、そ のプロトコルに対するフォワーディング表でそれ自体を登録する。これは、その ネットワーク・アドレス及びマスクを、内部フォワーディング表を有するその基 本分類へのポインタと一緒に登録することによって行われる。この表は、どのＦ ＡＳがパケットをフォワードするために呼び出されるべきかを決定すべく各プロ トコルＦＡＳのサービス方法によって用いられる、即ち、 これは、パケットが受け取られたインターフェイスでインスタンス生成された ＦＡＳのサービス部分に、パケットが送り出されるべきインターフェイスでイン スタンス生成されたＦＡＳへパケットをフォワードさせる。バインディングがフ ォワーディング表ルックアップを介して動的に行われので、これは、事実上イン ターフェイス独立であり、かつそれ自体を登録している既存の各ＦＡＳ（１から ｎ）及びフォワーディング表でそれがインスタンス生成されるネットワークに基 づく。 Ｂ．２ キャッシュ 性能に敏感なコードは、性能をスピードアップするためにキャッシングをしば しば採り入れる。一般に、キャッシュされたデータの検索を速めるためにハッシ ュ・コードが用いられる。例えば、ＵＮＩＸオペレーティング・システムは、内 部的にそのようなキャッシュの数を保持する。 ルータは、どのインターフェイス及び次のホップ・ゲートウェイにフォワード すべきかについて受け取った全てのパケットに対してフォワーディング決定を行 わなければならない。多数の競合している経路選択がフォワーディング情報ベー ス（ＦＩＢ）に存在し、かつベスト経路がアドレス・マッチ、マトリックス、サ ービスの品質、経路型または分類、ネットワーク対サブネット細分性、等に基づ いて選択されなければならないので、決定は、面倒である。一度、経路決定が行 われたならば、同じ宛先を有している後のパケットに対する決定をスピードアッ プするためにその選択をキャッシュすることは、ルータ・アプリケーションでは 一般的である。どのようにこのキャッシングがインプリメントされるかは、大幅 に変化するが、小さな固定された大きさに一般に保持されかつ特徴不足(feature poor)である。 本発明は、同じ資源及び宛先アドレスで受け取った後のパケットに対する手っ 取り早い処理(short-cut handling)を供給するオブジェクト指向型かつ特徴豊富 (feature-rich)キャッシングを有する。個別キャッシュは、各フォワーディング ・エンジンにキャッシュ・オブジェクトを含むことにより各ネットワーク・イン ターフェイスに対して存在する（例えば、図３Ｅの次のホップ・キャッシュ・オ ブジェクト２４１’及びアドレス・キャッシュ・オブジェクト２４３’を参照） 。 Ｂ．２．１ 基本分類 本発明は、プロトコル独立である基本分類ＡＣａｃｈｅを供給する。アドレス は、符号なし倍長整数(unsigned long integers)として保持される。ＡＣａｃｈ ｅは、管理セット静的エントリを支持しない；それは厳密に動的(dynamic)であ る。ＡＣａｃｈｅは、次のものを支持する： ・ キャッシュ・サイズにおける動的成長または縮減 ・ キャッシュ・サイズを下方に保持するためのキャッシュ・エントリのエー ジング・アウト ・ 外部管理事象が発生したときにエントリをフラッシュする ・ 発生源／宛先をハッシュする(hashing)ことによってキー入力にされた動 的エントリを設定する ＡＣａｃｈｅは、それ自体のスレッド・コンテキストを有する。エントリは、 割込みサービス・コンテキストにおいてキャッシュに設定される。それがキャッ シュ・サイズの高レベル・マークに達したならば、ＡＣａｃｈｅ設定エントリ手 順は、スレッド・コンテキストにおけるＡＣａｃｈｅバックアップをウェイクす るために内部事象をヒットする。それは次いでキャッシュに対して更なるメモリ を割り当てる。同様に、そのエージング・タイマが期限切れになったときに、Ａ Ｃａｃｈｅは、そのエージング手順においてスレッド・コンテキストでウェイク ・アップし（目覚め）かつ低レベル・マークに到達したならばそのときにキャッ シュを縮減すべく選択しうる。 キャッシュ全体をフラッシュすることは、ある一定の外部管理事象が発生した ときにキャッシュ・カレントを保持するための速い方法(fast way)である；代替 は、外部管理影響エントリがそのキャッシュにあるかどうかをチェックするため に全てのインターフェイス上のキャッシュをウォークする(walk)ことである。 エントリを設定することは、発生源及び宛先アドレスを１バイト・ハッシュ・ コードにハッシュしかつそのコードによって素早くアクセス可能な“バケット” (bucket)にエントリをリンクすることによって行われる。エントリそれ自体は、 ＡＣａｃｈｅによって見られるときに包括的基本分類を有するが、実際に記憶さ れているものは、プロトコル指定データを含みうる導出されたエントリである。 これは、特定プロトコル導出分類に係わりなく各キャッシュをまったく同様に機 能させる。 Ｂ．２．２ プロトコル指定導出分類 個別のネットワーク・プロトコルは、（１）エントリにプロトコル指定データ を付加しかつ（２）プロトコル指定ルックアップ・ルーチンを供給するためにＡ Ｃａｃｈｅから導出された分類を供給しうる。例えば、ＩＰ導出分類は、ＩＰＡ Ｃａｃｈｅである。 フォワーディング・パケットの部分として、ＩＰフォワーディング・エンジン 方法は、（１）パケット・アドレスを確認し、（２）アクセス一覧表に対してフ ィルタし、かつ（３）ＦＩＢから次のホップを検索する。これらの手順は、本質 的にスローであり、アドレス有効性（妥当性）のような、一度得られたこれら手 順の結果は、キャッシュされ、かつ対応手順は、素早く同じ結果をルックアップ するためにＩＰＡＣａｃｈｅに供給される。 ＩＰＡＣａｃｈｅは、それゆえに３つのキャッシュ・ルックアップ手順を支持 する： ・ 火星人(Martian)（無効）アドレス ・ アクセス制御一覧表フィルタリング ・ 次のホップ これら手順のそれぞれは、パケットから発生源及び宛先アドレスをパスされ、 それらをハッシュしかつそのハッシュ・コードに対する“バケット”においてリ ンクされたエントリをルックアップする。それは、それが発生源及び宛先の両方 と正確にマッチするかどうかを見るために各リンクされたエントリをチェックす る。それがマッチであることを見出したならば、それは、その機能に対してエン トリ・データをリターンする。火星人ルックアップに対して、アドレス有効性、 イエスまたはノー、がリターンされる。アクセス制御ルックアップ（図３Ｅのア クセス一覧表オブジェクト２４０’を参照）に対して、追加プロトコル及びポー ト・パラメータがマッチされなければならず、かつ許可、認可または否認、がリ ターンされる。次のホップに対して、サービス・パラメータの品質がマッチされ なければならずかつ次のホップがリターンされる。 これらのルックアップ手順は、パケットをフォワードすることを試みる割込み サービス・ルーチンのコンテキストにおいてコールされる；それらは、高速であ るべくコード化される。しかしながら、キャッシュは、一時的に不活性（インア クティブ）でありうる − 例えばそれは、アクセス一覧表エントリの削除のよ うな、外部管理事象によるスレッド・コンテキストにおいてフラッシュされる。 この場合には、キャッシュ・ルックアップ・ルーチンは、エントリがキャッシュ されたときに決定を行った最初の、スロー手順の上に単に後退して(fall back) 、実質的にキャッシュをバイパスする。 Ｂ．２．３ ネットワーク管理可視性 共通ベース・ルータ資源分類の使用を通して、各プロトコルは、そのプロトコ ル指定ＭＩＢのフォワーディング部分にインターフェイス番号によってキー入力 されたエントリの表を含む。エントリの葉(leaves)のあるものは、このパケット ・キャッシングに関連付けられる。各インターフェイスは、それ自体のキャッシ ュを維持する。キャッシュにおける個別のエントリは、ＭＩＢ可視ではない；こ れらの葉は、全体としてキャッシュを考慮する： ・ それがイネーブルされるか否か、 ・ それが成長することを許される最大サイズ、 ・ どのくらいのエントリがそのキャッシュに現在あるか、 ・ キャッシュがイネーブルされてからのキャッシュ・ヒットの数 ・ キャッシュがイネーブルされてからキャッシュ・ミスの数。 Ｂ．３ アクセス一覧表 一般に、経路指定アプリケーションは、宛先アドレス、または宛先及び発生源 アドレスの組合せに基づきネットワーク管理にパケットをフィルタさせる。ルー タの各インターフェイスがフィルタ例(filter instances)の個々のセット−アク セス一覧表を維持することができるということが望ましい。ほとんどのベンダー (vendors)は、線形機構を用いるしかつ一覧表がフォワードされる各パケットに 対してチェックされなければならないので、スループットは、一覧表が大きくな るにしたがって線形的に減速する。 本発明は、それによってネットワーク・パケットのフォワーディングがネット ワーク管理によって設定されたアクセス制御の対象になる機構を提供する。 オブジェクト指向型、強力かつ非常に有効なアクセス制御機構を供給するため に、基本分類ＦＡＣ（フォワーディング・アクセス）が発明された。効率のため に、ＦＡＣは、ＡＶＬトゥリーのノード（節）としてアクセス一覧表エントリを 保持する。トゥリーは、所定の大きさを有ず、かつ自由に成長しうる。管理ルー チンは、ネットワーク管理にエントリを設定しかつシリアル順序でそれらを検索 させるために設けられる。これらのルーチンは、ＡＶＬトゥリーをウォーク(wal k)するために書き込まれたイテレータ分類(iterator classes)によって支持され る。 各アクセス一覧表内で、有効エントリが、また、フィルタリング中の高速スキ ャンに対してそれらのシーケンス順序でトゥリーにわたってリンクされるので、 効率は、更に最大化される。各インターフェイスは、エントリのＩＤによって識 別されたときに唯一のアクセス一覧表に関連しうる。この関連付けは、フィルタ リングをイネーブルまたはディスエーブルすべくＩＤリーフ（葉）及び制御リー フを介してプロトコルのＭＩＢのフォワーディング部分において行われる。 Ｂ．３．１ 基本分類ＦＡＣ ＦＡＣは、ＩＰ、ＩＰＸ、ＤＥＣｎｅｔ、Ａｐｐｌｅｔａｌｋを含んでいる全 てのプロトコルのアクセス制御に対する基本分類でありかつＲＩＰのような経路 指定プロトコルをフィルタするためのものである。各個々のプロトコルは、ＦＡ Ｃからそのアクセス一覧表分類を導き出す。プロトコル指定ＭＩＢｓでは、アク セス制御は、エントリの表を含む。エントリは、ＦＡＣで管理される４つの共通 リーブで始まる： ＩＤ、シーケンス(Sequence)、マッチ(Matches)及び許可(Pe rmission)。最初の２つは、エントリ例をインデックスしかつそのエントリに固 有である。 ＩＤ：ＩＤは、特定の一覧表にエントリをグループ分けする識別子である。全 ての一覧表は、そのプロトコルに対する同じ単一トゥリーに存在する。 シーケンス：シーケンス番号は、所与のアクセス一覧表におけるエントリの順 番をキー入力する。パケットをフィルタするときには、第１のマッチング・エン トリは、フィルタ・チェックを出てかつパケットは、多重エントリにマッチして 、順序が重要である。 マッチ：これは、エントリが生成されてからのフィルタ（）コールの間にエン トリがマッチした回数の読取り専用カウンタである。 許可：これは、数え上げられかつ値を含む： ・ 無効（エントリを除去するための管理に対して） ・ 許可（発生源から宛先へのパケット・フォワーディングを許容する） ・ 否定（発生源から宛先へのパケット・フォワーディングを否定する） ・ 双方向許可（発生源から宛先へまたは宛先から発生源へのパケット・フ ォワーディングを許可する） ・ 双方向否定（発生源から宛先へまたは宛先から発生源へのパケット・フ ォワーディングを否定する） Ｂ．３．２ 一覧表及びインターフェイスの分裂 これは、より少数のアクセス一覧表エントリが生成される必要があるように同 じ一覧表を多重インターフェイス（全てのインターフェイスである必要はない） に関連付けさせる。 Ｂ．３．３ ワイルド・カード・アドレス指定 アドレス指定は、アクセス一覧表エントリのプロトコル指定部分であるけれど も、全てのプロトコルＦＡＣ導出分類は、アドレスの範囲を表わすスペシャル・ ケース・アドレス値を支持する。例えば、ＩＰではアドレスは、マスクとペアに されかつマスクのＯ’ｓは、アドレスの対応部分のものとマッチしているワイル ド・カードである。それゆえに、全てのＯ’ｓのマスクとペアのアドレスは、す ベてのものとマッチする。これは、強力である−−発生源からサーバに宛てられ た全てのパケットをフィルタ・アウトするために、サーバの宛先アドレス及び全 て１’ｓのマスクにアクセス一覧表エントリを設定するが、発生源アドレス及び Ｏ’ｓのマスクを用いる。 Ｂ．３．４ シーケンス・キー入力 これは、何をフィルタするかを指定することにおける使いやすさを供給する。 例えば、一つのサブネットから通ってくる全てのパケットを許容しかつ同じネッ トワークの他のサブネットからの全てのパケットを否定するために、たった二つ のエントリを必要とする。アドレスのサブネット及びホスト部分に対するワイル ド・カードを用いて良好なサブセットを許容するために第１のエントリをかつそ のネットワークの全てのサブネットを否定するために第２のエントリを設定する 。 Ｂ．３．５ 双方向許可 また、これは、仕様の容易性を許容する−−（発生源から宛先への要求に対し て一つ及び宛先から発生源へ戻す応答に対して一つの、二つのエントリを指定し なければならない代わりに）二つのエンド・ノード間の要求及び応答の両方を停 止するための一つのエントリ。 Ｂ．３．６ サービス並びにフォワーディング・インターフェイスのアクセス ・チェッキング 双方向許可と一緒に、これは、（一つのインターフェイス及び発生源及び宛先 上の一つのエントリが他のエントリ及びインターフェイスに対して逆にされるよ りも）同じエントリを両方のインターフェイスに対して画定させる仕様の容易性 を許容する。 また、これは、アドレスだけではなく、インターフェイスに基づく区別を許容 する−−例えば、宛先Ｂへの全ての発生源Ａがインターフェイス１で許可される が、インターフェイス２では許可されない。（インターフェイスが、管理するの が更にやっかいである、エントリの一部を形成しないならば）フィルタリングが フォワーディング側でだけチェックされたならば、これは、可能でない。 Ｂ．４ フレーミング 図５に示すように、ＯＳＩ基準モデルの第１の三つの層は、物理４７、データ ・リンク４６、及びネットワーク４５層を表わす。多重プロトコル・ルータは、 異なるデータ・リンク及び物理的層結合の間にネットワーク層パケットをスイッ チするためにこの層状モデルを用いて、ネットワーク層プロトコルに種々の通信 施設にわたりランさせる。 本発明によれば、フレーミング・オブジェクトは、標準データ・リンク及び物 理媒体構成とネットワーク層プロトコル・コンポーネントとの間に共通インター フェイスを与えるために設けられる。図５は、ＯＳＩ層モデルに対抗するネット ワーク層及びフレーミング・オブジェクト・コンポーネント関係を示す。フレー ミング・オブジェクト・コンポーネントは、フレーミング・オブジェクト資源分 類５０及び指定フレーミング・オブジェクト５１を含む。 フレーミング・オブジェクト資源分類５０は、それがシステム上に見出された 媒体及びインターフェイスに関係するときにプラットフォーム指定構成情報を決 定することにおいて、かつ各ネットワーク・インターフェイス上でネットワーク 層プロトコル・データ・ユニットを受信しかつ送信するためにネットワーク層プ ロトコル５２によって採り入れられるべき指定フレーミング・オブジェクト５１ の割り当てにおいて、ネットワーク層を支援する。フレーミング・オブジェクト は、エンジン支持をフレーミングしているプロトコルをフレーミングする各型に 対してインスタンス生成されかつフォワーディング・エンジンが取り付けられる インターフェイス・オブジェクトにバウンド（束縛）される。 フレーミング・オブジェクトは、基本フレーミング・オブジェクト分類からデ ータ・リンク及び媒体指定フレーミング・オブジェクトを導き出すことによって 認識される。基本フレーミング・オブジェクト分類は、：ネットワーク層プロト コルにネットワーク層パケット・マッチング・フレーミング及びプロトコル識別 子基準を受け取るためにレジスタさせる方法；ネットワーク層プロトコル・デー タ・ユニットを送信する方法；かつ関連データ・リンク及び物理層についての情 報を取得する方法を提供する。 ＩＥＥＥ、ＩＥＴＦのような、標準化委員会によって画定されるような、標準 データ・リンク・フレーミング・フォーマット及びプロトコル識別子は、特定の フレーミング・オブジェクトを通して認識される。データ・リンク・フレーミン グ及び媒体細部は、この知識からネットワーク層を解放するためにフレーミング ・オブジェクトに埋め込まれる。必要なところでは、方法は、例えば、データ・ リンク物理アドレスの長さ及び値をリターンし、データ・リンク・ヘッダの長さ を取得し、または媒体ＭＴＵを取得するために、包括的にデータ・リンク・フレ ーミング及び媒体情報を取得するためにフレーミング・オブジェクトによって供 給される。 フレーミング・オブジェクトは、ネットワーク層プロトコル・コンポーネント が、ネットワーク層パケットをサービスしかつフォワードするためにシステム・ インターフェイスにわたりインスタンス生成されるときにフレーミング・オブジ ェクト資源分類から要求される（図３Ｅのフォワーディング・エンジン２３４’ におけるフレーミング・オブジェクト２４２’参照）。ネットワーク層プロトコ ルは、システム・インターフェイスに関連付けられた媒体の性質について何も想 定しないし、プロトコルによって支持されるフレーミング・フォーマットのそれ ぞれに対するフレーミング・オブジェクトを要求する。フレーミング・オブジェ クト資源分類は、要求されたインターフェイスに関連付けられた媒体によって決 定されたような有効フレーミング・フォーマットだけを構築しかつリターンする 。フレーミング・オブジェクトは、それらが構築されるときにインターフェイス 及び媒体ドライバにバウンド（束縛）される。 例えば、図５は、ＩＰネットワーク層プロトコル５２が、媒体ドライバ５３を 介して、イーサネット５５及びトークン・リング５４媒体にわたる動作に対する フレーミング標準を支持する方法を示す。これらの媒体に対するフレーミングの 観点から、ＩＰは、イーサネット・バージョン２及びＳＮＡＰフレーミングを有 する８０２．２ＬＬＣを支持する。インターフェイス上でインスタンス生成され たときに、ＩＰネットワーク層は、これらのフレーミング標準の両方に対してフ レーミング・オブジェクトを要求する。イーサネット・インターフェイス上でイ ンスタンス生成されたときに、二つのフレーミング・オブジェクトが割り当てら れる：イーサネット・バージョン２フレーミング・オブジェクト及びＳＮＡＰフ レーミング・オブジェクトを有する８０２．２ＬＬＣ；トークン・リング・イン ターフェイス上でインスタンス生成されたときに、ＳＮＡＰフレーミング・オブ ジェクトを有する８０２．２ＬＬＣだけが割り当てられる。ＳＮＡＰフレーミン グ・オブジェクトを有するイーサネット８０２．２ＬＬＣは、８０２．３ＭＡＣ 層でフレームされ、ＳＮＡＰフレーミング・オブジェクトを有するトークン・リ ング８０２．２ＬＬＣは、８０２．５ＭＡＣ層でフレームされる。一度リターン されると、ネットワーク層プロトコルは、ネットワーク層パケットを受信しかつ 送信すべくレジスタするために割り当てられたフレーミング・オブジェクトのい ずれかを選択しかつ用いることができる。 フレーミング・オブジェクト資源分類からリターンされたフレーミング・オブ ジェクト例は、特定の媒体に対する全ての有効フレーミング・フォーマットを同 時に支持するためにネットワーク層プロトコルによって用いることができる。ネ ットワーク・ステーションのダイナミック・ティーミング及び関連フレーミング ・フォーマットが、達成されることができる。例えば、ＩＰネットワーク層プロ トコルは、一つのＩＰステーションに対してイーサネット・バージョン２フレー ミングかつ他のものに対してＳＮＡＰフレーミングを有する８０２．２ＬＬＣを 用いて直接連結されたイーサネット・セグメントで二つのＩＰステーションと通 信しうる。フレーミング・オブジェクトは、ＩＰネットワーク層にフレーミング ・フォーマットをマップさせ、並びに、物理アドレスをＩＰステーションにマッ プさせるためにＭＡＣ層物理アドレスと一緒にＡＲＰキャッシュに保持される。 Ｂ．５ 事象ファネル 制御の多重タスクまたはスレッドからなる経路指定のようなアプリケーション は、事象(events)によって駆動され、かつ制御のスレッドの間でプロセッサを効 果的に分配するためにスケジューリング機構を必要とする−−即ち、ネットワー クのパケットの到着またはタイマの期限切れのような実行スレッドに対して非同 期な事象に基づいてスレッドを動的にリスケジュールするために。このスレッド の事象ベース・リスケジューリングに対する支持は、オペレーティング・システ ムによって供給される。 スレッドにわたるこの分配を越えて、個々のスレッドそれ自体は、それがサー ビスを提供する競合事象(competing events)の間でそのアテンションを分割する ことが必要でありうる。一つの場所において同時に多重事象をスレッドに給仕(w ait)させる事象ファネルは、スレッド・コードのアーキテクチャをかなり簡略化 する。ＵＮＩＸのような主要オペレーティング・システムに書き込まれるアプリ ケーションは、そのような支持、例えば、４．３ＢＳＤ ＵＮＩＸの選択（）シ ステム・コールまたはシステムＶのポール（）システム・コールを有する。 Ｂ．５．１ ＲｔｒＥｖｅｎｔ及びＲｔｒＳｌｉｃｅ 本発明は、事象の要約を基本分類ＲｔｒＥｖｅｎｔの中に組織（編成）するこ とによりオブジェクト指向型事象ファネルを供給する。パケット到着またはタイ マ期限切れのような種々の事象型は、ＲｔｒＥｖｅｎｔから導出された分類とし て次いで画定されうる。例えば、パケット到着は、ＲｔｒＥｖｅｎｔから導出さ れるソケット分類を通してモデル化される−−図６参照。 ＲｔｒＥｖｅｎｔは、スレッドをブロックするパブリック手順待ち（）及び関 連スレッドをリスケジュールするためにオペレーティング・システムにフラグを たてる手順ヒット（）を有する。所与のＲｔｒＥｖｅｎｔに給仕されるブロック されたスレッドをウェイク・アップするために、そのＲｔｒＥｖｅｎｔは、異な る実行スレッドまたは割込みサービス・ルーチンによってヒットされなければな らない。生ＲｔｒＥｖｅｎｔは、ＩＰＣ（プロセス間通信）に用いることができ る。各ＲｔｒＥｖｅｎｔは、構築されたときに固有の識別子が割り当てられかつ 事象を通してユーザ・データを運ぶためにボイド・ポインタを含む。 スレッド３５は、単一ＲｔｒＥｖｅｎｔを直接給仕するかまたは一組のＲｔｒ Ｅｖｅｎｔを事象ファネルに関連付けかつ正確に給仕しうる。ファネルは、分類 ＲｔｒＭｕｌｔｉＷａｉｔである。ＲｔｒＭｕｌｔｉＷａｉｔ３６は、それにＲ ｔｒＥｖｅｎｔを加えるために加算（）手順を供給しかつリンクされた一覧表に ＲｔｒＥｖｅｎｔ３７ａ−ｄを保持する。それは、ＲｔｒＥｖｅｎｔを解除すべ く除去（）を同様に供給する。 スレッドは、ＲｔｒＭｕｌｔｉＷａｉｔを例に挙げかつ一つの場所で多重Ｒｔ ｒＥｖｅｎｔを給仕しうる。これらは、生ＲｔｒＥｖｅｎｔまたはあらゆる組合 せの導出オブジェクトでありうる。ＲｔｒＭｕｌｔｉＷａｉｔそれ自体は、それ 自体の事象を含みかつその事象のそのスレッドをブロックするｍｗａｉｔ（）手 順を有する。関連ＲｔｒＥｖｅｎｔがヒットされたときに、それは、同様にＲｔ ｒＭｕｌｔｉＷａｉｔをヒットする。制御がｍｗａｉｔ（）コールからリターン するスレッドにおいて再開されたときに、ヒットＲｔｒＥｖｅｎｔは、リターン される。 オペレーティング・システム・スケジューラーがファネルのスレッドを実行す る前に多重事象が発生した（多重ＲｔｒＥｖｅｎｔがヒットされた）ならば、ｍ ｗａｉｔ（）は、最優先ＲｔｒＥｖｅｎｔを与える。次のｍｗａｉｔ（）コール は、ブロックしないが次の最優先ＲｔｒＥｖｅｎｔですぐにリターンする。同じ 優先順位内で、ｍｗａｉｔ（）は、発生させるためにそれらをリターンする。 実際にはｍｗａｉｔ（）は、それがヒット状態に一つ以上のＲｔｒＥｖｅｎｔ を有していても常にすぐにリターンしない。これは、ファネルのスレッドが、例 えば、０．４秒にデフォルトされた構成可能タイム・クォンタムを越えないこと を確実にすべく、別の分類、ＲｔｒＳｌｉｃｅでリターンする前にそれがチェッ クするからである。越えたならば、ＲｔｒＳｌｉｃｅは、スレッドをリスケジュ ールするためにオペレーティング・システム・スケジューラーに制御をリターン する。ＲｔｒＳｌｉｃｅなしで、スレッドは、強制排除されずかつそれら自体の 間で公平にプロセッサを共有しなければならない。ＲｔｒＳｌｉｃｅは、それが 呼出しスレッドにペナルティを課すことなく自由に呼び出すことができるのでこ の点において支援する。クォンタムが越えないならば、ＲｔｒＳｌｉｃｅは、何 も行わないでリターンする。多くのスレッドがｍｗａｉｔ（）コールについて構 築されるので、多数の共有問題がＲｔｒＳｌｉｃｅのこの単一使用によって解決 される。 Ｂ．５．２ ＲＴｉｍｅｒ 本発明は、タイマの効率的キューイングを更に供給する。タイマは、事象の重 要な型であり、かつＲｔｒＥｖｅｎｔから導出された分類、ＲＴｉｍｅｒによっ て実施される。通信装置の個々のコンポーネントは、ＲＴｉｍｅｒからコンポー ネント指定タイマを更に導きうる。タイマの細分性は、例えば、０．１秒である 。 ＲＴｉｍｅｒのスタート（）手順は、期限切れまで所与の遅延でタイマ・キュ ーにそれを挿入する。時間が期限切れになったときに、タイマ・キューは、ＲＴ ｉｍｅｒの基本分類ＲｔｒＥｖｅｎｔヒット（）が呼び出されることを意味する 警報を発する。ＲＴｉｍｅｒは、ワン・ショット・タイマまたはその警報が発せ られた後にタイマ・キューに自動的に再装備されるサイクリック・タイマとして 構築（構成）されうる。パラメータ“カウント”は、タイマが再スタートされる 前にパスした回数の記録を取る。サイクリック・タイマの周期は、初期警報時間 と異なりうる。 タイマを効率的にティック・ダウン(tick down)しかつそれらの警報を発する ために、分類ＲＴｉｍｅｒＱが供給される。図６に示す実施例は、ＲＴｉｍｅｒ Ｑ３９の単一オブジェクト例を用いる。ＲＴｉｍｅｒ３８ａ、３８ｂは、スター トしたときにそれに関連付けられる。ＲＴｉｍｅｒＱは、タイマが期限切れにな ったかどうかを調べるためにキューのヘッドを見ることだけが必要であるように 警報時間のためにそれにＲＴｉｍｅｒをリンクする。ＲＴｉｍｅｒＱは、例えば 、０．０１秒毎にクロック割込みサービス・ルーチンをティックする単一のオペ レーティング・システム・プリミティブを流出または排出(run off)する。それ は、キューのヘッドをチェックしかつ行うべきワークが存在するならば、それは 、スレッド・コンテキストにおいて再覚醒し(reawaken)かつキューを処理するた めにそれ自体の事象をヒットする。それゆえに、それは、時間臨界割込みコンテ キストにおいてではなく、（非常に高い優先順位の）スレッド・コンテキストに おける期限切れタイマをヒットする。 ＲＴｉｍｅｒは、それをＲＴｉｍｅｒＱキューに挿入するためのスタート（） 手順並びにそれを除去するためのストップ（）を有する。効率のためかつ本実施 例のスレッド・コードが再入可能(reentrant)でないので、ＲＴｉｍｅｒは、ま た、割込みサービス・コードからタイマを開始しかつ停止するためにスタートｘ （）及びストップｘ（）を供給する。これらのルーチンは、単にタイマを重要経 路リンク一覧表に置きかつＲＴｉｍｅｒＱに関連した事象をヒットする。ＲＴｉ ｍｅｒＱがスレッド・コンテキストにおいて目覚めるときに、それは、重要経路 リンク一覧表をはずし、かつ各ＲＴｉｍｅｒを警報一時間順序のキューの中に挿 入する。 Ｃ．経路指定プロトコル 経路指定プロトコル・オブジェクトは、機能すべきトポロジー交換プロトコル に必要な自律機能性を供給する。トポロジー交換プロトコルは、隣接（近隣）を 発見し、ネットワーク到達可能性を宣伝し、それらのデータベースを同期し、か つ最適経路決定を実行する。基本オブジェクト分類は、プロトコル独立であるサ ービスの共通セットを供給する。特別経路指定プロトコル導出分類は、あらゆる プロトコルに対して同じ行動及び制御を自動的に得る。経路指定プロトコル・オ ブジェクト・フレームワークは、要求オブジェクトを経路指定プロトコル・オブ ジェクト自体の中に埋め込む（または分配する）。このようにして、経路指定プ ロトコルは、それがそれ自体の構成、及びシステム・サービス、並びにそのオブ ジェクト機能性（例えば、経路を宣伝すること、分割−水平を印加(apply)する こと、ＦＩＢを更新すること、等）を有することにおいて自給自足(self-suffic ient)である。特に、埋め込まれたオブジェクトは、次のものである（図３Ｃ参 照）： 経路指定プロトコル・スレッド２２０’− このオブジェクトは、その下でトポ ロジー交換機能を実行するための処理コンテキストを与える。 経路指定表２２３’− このオブジェクトは、ネットワーク・マップを維持する ためのＡＶＬ−トゥリー表を与える。この表は、大きさを任意に成長することが できる。 近隣一覧表（隣接）２２５’− このオブジェクトは、ルータ隣接を発見しかつ 維持する手段を供給する。これらの隣接は、次のホップ・ルータでありかつトポ ロジー交換において共有である。 ネットワーク・インターフェイス表２２４’− このオブジェクトは、各付加ネ ットワーク・インターフェイスに対するプロトコル指定構成情報を供給する。 事象オブジェクト２２１’− これは、経路指定プロトコル・オブジェクト内に それ自身の事象画定ケイパビリティを供給する。経路指定プロトコル・スレッド は、宣伝を処理しかつネットワーク・マップを維持するために事象に依存する。 タイマ・オブジェクト２２２’− これは、経路指定プロトコル・オブジェクト 内にそれ自身のタイマ導出オブジェクトを供給する。共通時間は、周期的宣伝及 びリンク状態更新に対して画定される。 この経路指定プロトコル・オブジェクトは、距離ベクトル・プロトコルを供給 する；しかしながら、リンク状態プロトコルを支持するオブジェクトも同様に供 給されうる。 Ｄ．管理オブジェクト 本発明の別の態様は、局所及び遠隔装置管理に対するコンピュータ・コードの オブジェクト指向型システムの使用である。このシステムは、既存及び将来の装 置管理機能性のインプリメントを簡略化するモジュラ分解の利点を有する。特に 、それは、次のものを供給する： ・ 先に書き込まれたコードの複製をほとんど必要としない管理情報ベースに おける管理オブジェクトに対する標準インターフェイス。 ・ それらの規定が一致することを確実にする付加オーバーヘッドなしに標準 表規定を用いてＳＭＩ表をユーザにインプリメントさせる管理オブジェクト表に 対する標準インターフェイス。 ・ 不揮発性メモリにインターフェイスするために追加のコードを書込むこと を必要としないでオブジェクトが不揮発性であることを示すための管理オブジェ クト・インターフェイスにおけるプロビジョン。これらは、“パーシステント・ オブジェクト”と呼ばれる。 ・ 管理プロトコルまたはＳＮＭＰ、ＳＮＭＰｖ２、ＤＭＰ、局所装置管理、 及び他の管理オブジェクトを含んでいる他のエンティティによるオブジェクト・ アクセス用管理情報ベースに対する標準インターフェイス。 ・ これらの型の基本特性を取り囲むことに加えて、更なる目的に対してそれ らの基本特性を増補する標準方法を許容する、ＳＭＩに画定された９つの基本デ ータ型を表している一組のオブジェクト。これらは、管理プロトコル・パケット の符号化及び復号かつ管理オブジェクト自体としての型の使用を含む。 次の定義が用いられる： 基本分類(Base Class) 別の分類がそれから導きだされる分類（分類、導出を 参照）。 分類(Class) それらで動作するデータ及び機能の論理的にグループ分けされ たセット。 導出(Derivation) 分類を変えることなく、導出は、追加または異なる機能 性を実行するためにこの分類を加え及び／又は増補する。コードの最初のセット は、それが増補されうる機能または拡張を限定しうる（分類を参照）。 ＩＳＯ 国際標準編成委員。 管理オブジェクト 管理情報ベースにおけるデータの一片又は表。 ＭＯＦ 管理オブジェクト・フレームワーク；通信装置管理の基礎をな すシステム。 ＭＩＢ 管理情報ベース；装置についての管理可能情報のデータベース 。それは、ＲＦＣ１１５６に記載されている。 オブジェクト識別子 管理情報ベース一片またはグループのデータを独自に 識別する一連の数字。しばしばＯＩＤと略語される。 ＲＦＣ コメントに対する要求；標準のインターネット・エンジニアリ ング・タスクフォース（ＩＥＴＦ）システムの文書。ＲＦＣ（コメントに対する 要求）は、4676 Admiral Chief Way，Marina Del Rey,California 90292-6695,U SAのUSC／情報科学学会におけるＲＦＣエディタとコンタクトすることによって 得ることができる出版文書である。 ＳＭＩ 管理情報の構造；情報編成規定のシステム。それは、ＲＦＣ１ １５５に画定されている。 ＭＯＦの図式的表現は、図７に示されている。ＭＯＦ６０は、５つの個別のコ ンポーネントに分解されている： ・ ＳＭＩ型オブジェクト６３及び表オブジェクト６４を含んでいる、コア・ オブジェクト６１ ・ 管理オブジェクト基本分類６２ ・ ＭＩＢオブジェクト６５ ・ 指定管理オブジェクト６６ ＭＩＢオブジェクト６５は、特定の管理オブジェクトを有する（管理情報ベー スにおける一片のデータを独自に識別する）オブジェクト識別子のマッピングを 供給する。次いでそれは、管理オブジェクトに保持される実際のデータを検索す るために管理オブジェクト基本分類標準インターフェイスを利用する。 コア・オブジェクト６１は、ＭＯＦ全体により用いられる一組のオブジェクト を表わす。これらは、ＳＭＩで画定された９つの基本型のそれぞれに対して一つ のオブジェクトを含む：ＩＮＴＥＧＥＲ６７、ＯＣＴＥＴ ＳＴＲＩＮＧ６８、 ＮＵＬＬ６９、ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ７０、ＩＰＡｄｄｒｅｓｓ ７１、カウンタ７２、ゲージ７３、タイムティックス７４、及びオペーク７５。 これらのオブジェクトのそれぞれは、ＳＭＩに記載された機能性及び有効情報、 並びにこれらの型を用いるコアに有用な追加機能性を取り囲む。他のコア・オブ ジェクトは、管理オブジェクト表に対するデータを保持する表オブジェクト６４ を含む。 管理オブジェクト基本分類６２は、特定管理オブジェクト６６へのアクセスの 標準方法を供給する。この基本分類から導出されるオブジェクトは、ＭＩＢが次 いでオブジェクトのデータを獲得することを利用する、この標準アクセスを許容 するために少量のコードをカストマイズすることのみを必要とする。 指定管理オブジェクト６６は、それぞれの機能性を取り囲むためにコア・オブ ジェクト６１及び管理オブジェクト基本分類６２から倍増導出されるデータ型で ある。例えば、整数管理オブジェクトは、ＩＮＴＥＧＥＲコア・オブジェクト６ ７から導出された整数機能性、並びに管理オブジェクト基本分類６２から導出さ れた管理可能性を含む。新しい整数管理オブジェクトが必要なときに、設計者は 整数の値（または値を得る方法の情報）及び固有のオブジェクト識別子を供給す ることが単に必要である。これは、達成すべき新しいコードを相対的にほとんど 必要としない。ＭＩＢオブジェクト６５は、次いで標準的な方法で管理オブジェ クトをアクセスすることができる。また、管理オブジェクト表もこの方法で生成 される。次のものは、指定管理オブジェクトの列挙である： 名前 導出元 整数管理オブジェクト コアＩＮＴＥＧＥＲ、管理オブジェクト 基本分類 ストリング管理オブジェクト コアＯＣＴＥＴ ＳＴＲＩＮＧ、管理オ ブジェクト基本分類 ＯＩＤ管理オブジェクト コアＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥ Ｒ、管理オブジェクト基本分類 ヌル管理オブジェクト コアＮＵＬＬ、管理オブジェクト基本分 類 ＩＰアドレス管理オブジェクト コアＩＰアドレス、管理オブジェクト基 本分類 カウンタ管理オブジェクト コア・カウンタ、管理オブジェクト基本 分類 ゲージ管理オブジェクト コア・ゲージ、管理オブジェクト基本分 類 タイム・ティックス コア、タイム・ティックス、管理オブジ 管理オブジェクト ェクト基本分類 静的表管理オブジェクト コア静的表、管理オブジェクト基本分類 動的表管理オブジェクト コア動的表、管理オブジェクト基本分類 Ｄ．１ ＭＩＢアクセス ＭＩＢは、４つの方法でアクセスされうる：Ｇｅｔ、Ｇｅｔ−Ｎｅｘｔ、Ｓｅ ｔ、Ｓｅｔ−Ｖａｌｉｄａｔｅ。Ｇｅｔ動作は、完全オブジェクト識別子を必要 とする。ＭＩＢは、オブジェクト識別子を管理オブジェクトにマップ（もしその 識別子で一つが存在するならば）しかつ情報を検索するためにそのオブジェクト のＧｅｔ指令を呼び出す。その識別子を有する管理オブジェクト存在しないなら ばエラーがリターンされる。Ｇｅｔ−Ｎｅｘｔ動作は、非存在、完全、または部 分的オブジェクト識別子を取りうるしかつＭＩＢに存在する次の数値的に高い完 全オブジェクト識別子にそれをマップする。再び、ＭＩＢは、次いでこのオブジ ェクトのＧｅｔ指令を呼び出す。指定したものよりも数値的に高い管理オブジェ クトが存在しないならばエラーがリターンされる。ＳｅｔまたはＳｅｔ−Ｖａｌ ｉｄａｔｉｏｎ動作は、完全オブジェクト識別子、型及び値を必要とする。それ らは、Ｇｅｔ動作と同じ方法で識別子をマップする。Ｓｅｔ動作では、管理オブ ジェクトは、それが“書込み可能”であり型が正しくかつ供給された値がそのオ ブジェクトに対して有効であるならば、設定される。Ｓｅｔ−Ｖａｌｉｄａｔｉ ｏｎ動作は、Ｓｅｔと同じチェックを行うが、管理オブジェクトの値を実際には 変えない。その識別子を有する管理オブジェクトが存在せず、型が不正確または 値が不正確かまたは範囲外であるならばエラーがリターンされる。 また、ＭＩＢは、確認サービスを供給する。許可情報オブジェクトは、各ＭＩ Ｂアクセス指令で送られる。一度ＭＩＢが確認されると、管理オブジェクトは、 特定のオブジェクト識別子に対して存在し、確認マネージャは、確認情報オブジ ェクトと一緒にオブジェクト識別子が送られる。確認マネージャは、装置にその 確認の方法を指定させるアプリケーション指定である。 管理オブジェクトは、Ｇｅｔ指令によってアクセスされうるし、かつオブジェ クトが書込み可能であるならば、Ｓｅｔ及びＳｅｔ−Ｖａｌｉｄａｔｅ指令によ ってアクセスされうる。指定管理オブジェクトをインプリメントすることにおい て、オブジェクトが読取り専用または読取り−書込みであるかどうかを指定しな ければならないし、ユーザは、型をチェックし、値をチェックし、かつオブジェ クトの値を設定する方法を供給しなければならない。これは、管理オブジェクト に対して供給しなければならない最小の機能性である。更なる機能性は、新しい 値が不揮発性メモリに記憶されかつ装置実行の開始で検索されるべきであるとい うことを（Ｓｅｔ指令で）指定することを含む。これは、Ｓｅｔ指令からのリタ ーンにより指定される。 管理オブジェクト基本分類が不揮発性記憶装置に値を記憶する要求を受け取っ たときに、それは、オブジェクト識別子、型及び値を有する装置不揮発性メモリ ・マネージャを呼出す（図９及び以下のセクションＤ．３参照）。装置実行の開 始では、全管理オブジェクト値は、あたかもＳｅｔ指令がそれらのオブジェクト に対して呼び出されたかのようにＭＩＢへの呼出しを通して記憶される。 管理オブジェクト表は、情報の順序付けられたセットを供給すべくコア表オブ ジェクトと相互作用（対話）する。表の各エントリの各値は、特定の表インデッ クスに対する管理オブジェクトの値として考慮されうる。インデックスは、（指 定管理オブジェクトで指定された方法で）オブジェクト識別子から抽出され、コ ア表オブジェクトは、このキーでエントリをルックアップするように要求され、 かつ値は、抽出されかつエントリからリターンされる。Ｓｅｔ指令は、エントリ 管理オブジェクト表もそれらがＳｅｔ指令の後で不揮発性メモリにセーブされる べきであるということを指定しうることを除き、同じ方法で動作する。非表(non -tabular)オブジェクトとは対照的に、表エントリ全体は、コア表オブジェクト 追加指令を用いて装置実行の開始で記憶される。 管理オブジェクト表の第２の型は、表エントリを追加させかつ削除させる。こ れは、エントリ制御として一つのインデックスされた管理オブジェクトを指定す る規則を通して達成される。このエントリ制御オブジェクトを異なる値に設定す ることは、エントリをコア表オブジェクトに追加させるかまたはそれから除去さ せる。不揮発性メモリへのこの種のエントリのセービングは、エントリがコア表 オブジェクトから除去されるときにエントリに不揮発性メモリから除去させるこ との追加で、上述した表オブジェクトと同じように動作する。 上記指定管理オブジェクトの表から推測されうるように、静的及び動的表の両 方は、使用するメモリ・モデルにより、コア・オブジェクトにおいて利用可能で ある。追加コア・オブジェクトが必要に応じて表及び非表管理オブジェクトの両 方に追加機能性を供給すべく追加されうるということに注目することも有用であ る。 図８に示すように、ＭＩＢは、各ノードがオブジェクト識別子（ＯＩＤ）の識 別子を表している、ＭＩＢノード８２−８９のトゥリー８０として構成される。 管理オブジェクト８４、８６、８９は、リーフ・ノードに配置される。“ＯＩＤ Ａ”により名前を付けられた管理オブジェクトを得るためにＭＩＢをアクセスす ることを望むならば、“ＯＩＤ Ａ”は、正確に指定されなければならない。ま た、“ＯＩＤ Ｄ”上のＧｅｔ−Ｎｅｘｔは、“ＯＩＤ Ａ”に対する情報も得 る、なぜならば、Ｇｅｔ−Ｎｅｘｔは、ＯＩＤが指定された後に次の管理オブジ ェクト・リーフをリターンするからである。“ＯＩＤ Ａ”により名前を付けら れた管理オブジェクト上のＧｅｔ−Ｎｅｘｔを行うならば、情報は、“ＯＩＤ Ｂ”により指定された管理オブジェクトからリターンされる、等。また、ＭＩＢ がその情報に対するリーフ管理オブジェクトを求める前に、アクセス確認が行わ れるということにも注目すべきである。動作に対するアクセスが無効であったな らば、Ｇｅｔ、ｓｅｔ、またはＳｅｔ−Ｖａｌｉｄａｔｅは、非存在ＯＩＤエラ ーをリターンし、Ｇｅｔ−Ｎｅｘｔは、リーフ管理オブジェクトを通り越してト ゥリーの次に移動する。 Ｄ．２ 内部(Internals) 管理オブジェクト基本分類は、（Ｃ＋＋コードで）次のインターフェイスを供 給する： ＧＥＴ、ＧＥＴＮＥＸＴ、ＳＥＴ、及びＳＥＴＶＡＬＩＤＡＴＥは、上述した アクセス方法を表しているファンクション（関数・機能）である。ｍｏ ｇｅｔ ファンクションは、ＭＩＢトゥリーの指定リーフに対する情報をリターンするた めにＧＥＴ及びＧＥＴＮＥＸＴアクセス・ファンクションによって呼び出される 。ｇｅｔ ｉｎｓｔａｎｃｅファンクションは、ＧＥＴ及びＧＥＴＮＥＸＴファ ンクションに対するオブジェクト識別子を確認する。一つ以上のＭＩＢリーフが この管理オブジェクトによって表されるならば、ｇｅｔ ｉｎｓｔａｎｃｅは、 また、ＧＥＴＮＥＸＴによって呼び出されたときに“次の”(next)リーフを表わ すためにオブジェクト識別子を更新する。ｍｏ ｓｅｔファンクションは、特定 のリーフに対する新しい情報を記憶するためにＳＥＴによって呼び出され、かつ リターン値により新しい情報を不揮発性記憶装置にセーブする。ｓｅｔ ｖａｌ ｉｄａｔｅファンクションは、値のオブジェクト識別子、型及び値を確認するた めにＳＥＴＶＡＬＩＤＡＴＥ及びＳＥＴの両方によって呼び出される。ｇｅｔ ｓｔａｔｕｓは、管理オブジェクトが読取り専用でないことを確実にするために ＳＥＴＶＡＬＩＤＡＴＥ及びＳＥＴの両方によって呼び出される。各指定管理オ ブジェクトは、その特定リーブ及び読取り−書込み状態に必要なルーチンを供給 する。これら５つの標準ルーチンは、指定管理オブジェクトのインプリメントを フ レキシブルにさせ、共通ＧＥＴ、ＧＥＴＮＥＸＴ、ＳＥＴ、及びＳＥＴＶＡＬＩ ＤＡＴＥルーチンにおける全管理オブジェクトに対して共通に動作を維持する。 管理オブジェクトは、多くの型及び値のリーブを表しうるし、より簡単な管理オ ブジェクトに対して数ラインのコードだけを必要とする。 Ｄ．３ パーシステンス 上記したように、ＳＥＴは、指定管理オブジェクトのｍｏ ｓｅｔファンクシ ョンを呼び出し、かつリターン値により、それを不揮発性メモリにセーブする。 ＳＥＴファンクションは、パーシステント・オブジェクト・マネージャと呼ばれ るシステムと相互作用する。 図９に示すように、装置が動作を開始するときにパーシステント・オブジェク ト・マネージャ７７が生成され、かつパーシステント・オブジェクトの検索及び 記憶のための“ハンドル”を有する表マッピングオブジェクト識別子を構築する ために不揮発性メモリ・マネージャ７６と相互作用する。パーシステントである 各指定管理オブジェクトは、次いで生成され、かつ標準管理オブジェクト基本分 類を通してその値を復元するためにパーシステント・オブジェクト・マネージャ を呼び出す。パーシステント・オブジェクトが新しい値に設定されたときに、管 理オブジェクトＳＥＴファンクション７８は、値を記憶するためにパーシステン ト・オブジェクト・マネージャ７７を呼び出す。オブジェクトが予め記憶されて いるならば、パーシステント・オブジェクト・マネージャは、不揮発値(non-vol atile value)を更新するためにその確立された“ハンドル”を用いる。オブジェ クトが予め記憶されていないならば、パーシステント・オブジェクト・マネージ ャ７７は、（オブジェクトのオブジェクト識別子によって識別される）新しいハ ンドルに対する不揮発性メモリ・マネージャ７６を求める。 Ｄ．４ ＮＶＲＡＭファイル・システム ＮＶＲＡＭファイル・システムは、簡単なファイル・システム構造を不揮発性 記憶装置の上にオーバーレイ(overlay)する。ファイル・システムは、オブジェ クト識別子によるブロックのタギングを許容する。全てのオブジェクトが、定義 により、グローバルＭＩＢ名前付けトゥリーから割り当てられた異なるオブジェ クト識別子を有するので、これは、全てのオブジェクトをファイル・システム階 層構造の中に自動的にフィットさせる。 Ｅ． 共通ＭＩＢテンプレート ＭＩＢｓは、システム・レベル及びネットワーク・インターフェイス・レベル の両方における経路指定アプリケーションを構成し、監視し、かつ制御する機能 を供給する。システム・レベルは、アプリケーションまたはサービスに対するグ ローバル・パラメータが設定できる装置レベルでの制御を供給する。ネットワー ク・インターフェイス・レベルは、アプリケーションまたはサービスがネットワ ークに付加される制御を供給する。これは、ネットワーク毎に変化しうるネット ワーク指定パラメータに対するキーである。ＭＩＢｓは、装置が動作可能(opera tional）である前に最小量のユーザ構成を許容するためにできるだけ多くのデフ ォルト・パラメータを用いる。 Ｅ．１ ｃｔＲｏｕｔｅｒ−ＭＩＢ 経路指定サービスは、どの経路指定アプリケーション及びコンポーネントが装 置にあるかを“発見する”(discover)ための機能を供給する。装置が種々のネッ トワーク・サービス及びアプリケーションを支持するので、あらゆる装置の特定 ケイパビリティを決定することができることは、管理アプリケーション及びネッ トワーク・ユーザに対して重要である。経路指定サービスを供給する装置は、経 路指定サービスの可用性及びバージョンを示しているそのシャーシＭＩＢにエン トリを含む。これは、経路指定サービスに対して一つのエントリだけを有する、 何のアプリケーションが装置にあるかという基本的に“内容の表”である。エン トリは、どのルータが実際に装置にあるかに係わりなく経路指定サービス全体を 制御するために用いる高レベル・ルータＭＩＢ（“ｃｔＲｏｕｔｅｒ”）を指定 する。ｃｔＲｏｕｔｅｒＭＩＢは、個別のルータＭＩＢｓを使用することなくル ータ及びコンポーネントに対する管理及び動作状態（動作可能時間を含む）を決 定する機能を供給する。しかしながら、指定プロトコルまたは構成制御に対して 、 個別ルータＭＩＢｓが用いられなればならない。 図１０は、ｃｔＲｏｕｔｅｒＭＩＢ１１１の上にシャーシＭＩＢ１１０、かつ 個別経路指定プロトコルＭＩＢｓ１１２−１１５のそれぞれを下に有する、基本 管理モデルを示す。 Ｅ．２ 共通ＭＩＢテンプレート 経路指定サービス内のルータ・アプリケーションの一定管理及制御を供給する ために、各ＭＩＢは、共通ＭＩＢテンプレートを用いる。各個別ルータＭＩＢは 、同じセットの管理オブジェクトで画定される。これは、各個別ルータ・アプリ ケーションの一定外部ビューを供給する。共通オブジェクト・モデルなので、あ る管理オブジェクトは、特定ルータ・プロトコル構成において意味または直接ア プリケーションを有さない。これが生ずる場合には、オブジェクトは、完全に可 視可能かつ管理可能であるが、ルータまたは特定プロトコルの動作に影響を及ぼ さない。 図１１は、個別ルータＭＩＢｓの全てに共通な機能グループを示す。“ルート ”プロトコルは、例えば、ＩＰのような、管理されているネットワーク・プロト コル・ルータを画定する。“ＭＩＢ”は、ルータＭＩＢのバージョンを画定する 。“コンポーネント”は、以下のルータ・グループを含む一組のコンポーネント ・グループを画定する、即ち、； ・ ルータ・システム・グループ−−グローバルな、装置全体レベルでの経路 指定サービスに関係するオブジェクトを含む。 ・ フォワーディング・グループ−−パケット・フォワーディングに対するネ ットワーク・プロトコルのルータ・ポート並びに集約及びインターフェイス毎Ｉ Ｐパケット・フォワーディング・カウンタをセットアップしかつ構成するために 用いる管理オブジェクトを含む。 ・ トポロジー・グループ−−ルータの経路指定及びサービス宣伝に対する管 理オブジェクトを含む。これらの管理オブジェクトは、経路指定エージェント及 びサービス・エージェントに、システム全体並びにルータ・ポートに基づき制御 されかつ監視されることを許容する。ＤｉｓｔａｎｔＶｅｃｔｏｒｅｄ及びＬｉ ｎｋＳｔａｔｅは、画定されたトポロジー・グループの型である。 ・ フォワーディング情報ベース（ＦＩＢ）・グループ−−フォワーディング 表に対する管理オブジェクトを含む。この表は、ネットワーク・プロトコルの経 路指定表におけるエントリから構築されかつフォワーディングに対して最良のル ーツである考えられるルーツを反映する。 ・ エンド・システム・グループ−−各ルータ・ポートに対する物理アドレス にホスト・アドレスをマップするアドレス分解プロトコル（ＡＲＰ）を制御する 管理オブジェクトを含む。 ・ アクセス制御グループ−−ネットワーク・プロトコルのトラフィックに対 するアクセス制御一覧表を確立することに関係する管理オブジェクトを含む。 ・ フィルタ・グループ−−フィルタのセットアップ及び構成に関係する管理 オブジェクトを含む。 ・ 転送グループ−−ネットワーク・プロトコルのトラフィックの指定転送の セットアップ及び構成に関係している管理オブジェクトを含む。 ・ 事象グループ−−事象ロギングに関係している管理オブジェクトを含む。 ・ ワークグループ・グループ−−ワークグループ経路指定に関係している管 理オブジェクトを含む。 Ｅ．３ コンポーネントＭＩＢグループ 共通ＭＩＢテンプレートを通じてコンポーネント・グループの多くは、類似な 構造を共有する。コンポーネントＭＩＢビューは、管理される実際のコンポーネ ントにより変化する。各部分（枝）は、表１に示すような共通管理ビューを有す る。 システム 共通システム構成ビュー 共通システム構成のオブジェクトは、コンポーネントをグローバルに制御する 。 ・ AdminStatus(1)−−このコンポーネントがイネーブルされるかディスエー ブルにされるかを制御する。 ・ OperationalStatus(2)−−コンポーネントの動作状態を示す。 ・ AdminReset(3)− コンポーネントをリセットする。 ・ OperationalTime(4)−−コンポーネントがその現行動作状態になっている 時間量を表わす。 ・ Version(5)−−このコンポーネントのファームウェア・バージョンを表示 する。 共通システム集約カウンタ 共通システム集約(Aggregate)カウンタは、受け取り、送り、廃棄し、かつフ ィルタしたパケットの全てのルータ・ポートの合計バイト及びパケット計数を示 す。グループのあるものは、追加カウンタを有する。全てのシステム・カウンタ ・グループは、全てのポートのカウンタをイネーブル／ディスエーブルしかつカ ウンタをゼロにリセットする機能を有する。 インターフェイス 共通構成インターフェイス表 全てのインターフェイス構成表は、装置のＭＩＢ−ＩＩインターフェイスの数 に一致するデフォルト・エントリで初期化される。インターフェイス表の開始リ ーブは、次の形を有する： ・ IfIndex(1)−−ＭＩＢ−ＩＩインターフェイスまたはポート数。 ・ AdminStatus(2) − このコンポーネントのインターフェイスがイネーブ ルされるかまたはディスエーブルされるかを制御する。 ・ OperationalStatus(3)−−このコンポーネントのインターフェイスの実際 の状態を示す。 ・ OperationalTime(4)−−このコンポーネントのインターフェイスが現行動 作状態にあった時間量を表わす。あるコンポーネント・グループは、追加構成リ ーブを有する。 共通カウンタ・インターフェイス表 共通カウンタ・インターフェイス表のオブジェクトは、受け取り、送り、廃棄 し、かつフィルタしたルータ・ポートの合計バイト及びパケット計数を示す。グ ループのあるものは、追加カウンタを有する。全てのインターフェイス・カウン タ・グループは、カウンタをイネーブル／ディスエーブルしかつカウンタをゼロ にリセットするポート毎の機能を有する。 Ｅ．４ 共通フォワーディング・グループＭＩＢ 共通フォワーディング・グループＭＩＢは、アドレス表を除き共通コンポーネ ント・ビューに従う（表２参照）。必要ならば、各プロトコルは、アドレス表を 特に画定する。例えば、ＤＥＣｎｅｔは、ポート毎にアドレスを構成することを 必要としないのでアドレス表グループは、存在しない。 システム 集約カウンタ フォワーディング・グループに対する集約カウンタ及びカウンタ・インターフ ェイス表は、ホスト・イン／アウト、エラー、及び数フォワード・カウンタの追 加を有する基本カウンタ・グループの構造に従う。 インターフェイス 構成インターフェイス表 フォワーディング・グループに対する構成インターフェイス表は、次の追加リ ーブを有する全ての他のインターフェイス表の基本構造に従う。 ・ Control(5)−−追加／削除エントリ。 ・ MTU(6)−−送られるパケットの大きさを決定する。 ・ Forwarding(7)−−パケットのイネーブル／ディスエーブル・フォワーデ ィング。 ・ FramingType(8)−−用いられるフレーミングの型を識別する。 ・ AclId(9)−−用いられるＡＣＬ−覧表ＩＤを割り当てる。 ・ AclStatus(10)− イネーブル／ディスエーブル・アクセス制御。 ・ CacheControl(11)−−イネーブル／ディスエーブル・キャッシング。 ・ CacheEntries(12)−−キャッシュ表のエントリの現行数。 ・ CacheHits(12) − キャッシュ・ヒットの数。 ・ CacheMisses(13)−−キャッシュ・ミスの数。 カウンタ・インターフェイス表 フォワーディング・グループに対する集約カウンタ及びカウンタ・インターフ ェイス表は、ホスト・イン／アウト、エラー、及び数フォワード・カウンタの追 加を有する基本カウンタ・グループの構造に従う。 Ｅ．５ 共通トポロジー・グループＭＩＢ 共通トポロジー・グループＭＩＢは、表３に示すように、共通コンポーネント ・ビューに一般に従う。 システム システム構成 トポロジー、ＤｉｓｔａｎｔＶｅｃｔｏｒｅｄグループに対するシステム構成 ブランチは、次の追加リーブを有する共通システム構成ビューを維持する： ・ Stacksize（6）−−経路指定プロトコル・エージェントに必要なスタック の量を制御する。 ・ Thread Priority（7）−−この経路指定プロトコル・エージェントの実行 優先順位走行時間を指定する。 ・ Threshold（8）−−経路指定プロトコルのルート表に保持することができ るＲＩＰエントリの数を指定する。 ・ AgeOut（9） − 経路指定表に残っている時間インアクティブ・ルート を指定する。 ・ HoldDown（10）−−ルート表にインアクティブ・ルートを保持するための 追加時間を指定する。 インターフェイス 構成インターフェイス表 トポロジー、ＤｉｓｔａｎｔＶｅｃｔｏｒｅｄグループに対する構成インター フェイス表は、次の追加リーブを有する共通構成インターフェイス表の基本構造 に従う。 ・ Version（5）−−プロトコル改訂レベル。 ・ Advertisement（6）−−経路指定宣伝更新を送る周期速度。 ・ FloodDelay（7） − ルータ発見変更遅延。 ・ RequestDelay（8） − 要求を受け取った後に応答を送るための遅延時 間。 ・ Priority（9） − このインターフェイスのプロトコルの優先順位。 ・ HelloTimer（10） − ハロー・メッセージを送る周期速度。 ・ SplitHorizon（11） − イネーブル／ディスエーブル分割水平。 ・ PoisonReverse（12） − イネーブル／ディスエーブル・ポイゾン反転 。 ・ Snooping（13） − イネーブル／ディスエーブル・スヌーピング。 ・ Type（14） − 媒体アクセスの型。 ・ XmitCost（15） − 送信費用。 ・ AclId（16） − 用いられるＡＣＬ一覧表ＩＤを割り当てる。 ・ AclStatus（17） − イネーブル／ディスエーブル・アクセス制御。 カウンタ・インターフェイス表 トポロジー・グループに対するカウンタ・インターフェイス表は、ホスト・イ ン／アウト、エラー、及び数フォワード・カウンタの追加を有する共通カウンタ ・グループの構造に従う。 Ｆ．共通基本ルータ資源 このセクションは、ルータ・サービス内の資源が管理されるような一定の方法 を説明する。共通資源モデルの目的は、経路指定プロトコルの容易なインプリメ ントを許容しかつ経路指定サービスのスケーラブル及びポータブルなインプリメ ントを供給することである。 ルータ・サービスに対する共通機能及びＭＩＢテンプレートを理解するために 、２〜３の基本概念が説明されなければならない。これらの概念は、図１２に示 される。ＢａｓｅＲｅｓｏｕｒｃｅ（基本資源）１１６は、ルータ資源の最も基 本的なコンポーネントである。組込みの管理機能及び状態を有するのは、基本分 類オブジェクトである。共通ＭＩＢルータ・テンプレートは、一定かつ正規の方 法でレイアウトされたＢａｓｅＲｅｓｏｕｒｃｅコンポーネントのコレクション である。ＲｅｓｏｕｒｃｅＴａｂｌｅ１１７は、ＢａｓｅＲｅｓｏｕｒｃｅオブ ジェクトのＭＩＢ管理可能表である。各ＢａｓｅＲｅｓｏｕｒｃｅオブジェクト は、サービス、コンポーネント、またはインターフェイス・オブジェクトを表わ す。ほとんど全てのＢａｓｅＲｅｓｏｕｒｃｅｓは、管理目的でこれら表の一つ の中に登録される。ＲｓｃＥｎｔｒｙ１１８は、ＲｅｓｏｕｒｃｅＴａｂｌｅ、 例えば、ハンドルまたはインターフェイス数、インデックス、フラグ、管理状態 、ＢａｓｅＲｅｓｏｕｒｃｅポインタのエントリを画定する。 Ｆ．１ ＢａｓｅＲｅｓｏｕｒｃｅ記述 ＢａｓｅＲｅｓｏｕｒｃｅは、共通ルータ・オブジェクト・モデルの基本構成 要素である。それは、コンポーネントの基本管理及び動作状態を維持する責任を 負う。このコンポーネントによってインスタンス生成されたＢａｓｅＲｅｓｏｕ ｒｃｅコンポーネントは、これらの状態が変化したならば適切に処理される。即 ち、管理状態がイネーブルからディスエーブルに変わったならば、コンポーネン トは、ディアクティベートしかつこの資源によって生成された全てのＢａｓｅＲ ｅｓｏｕｒｃｅコンポーネントも同様にディアクティベートされる。これは、管 理をあらゆるレベルで行わせかつ最低資源まで浸透させる。全ての資源がＭＩＢ を通して管理可能ではない。この資源の実際の管理可能性は、共通ＭＩＢテンプ レート内で画定されうる。また、状態変化は、内部事象からも生ずるし或いはペ アレント資源状態が変化したときに間接的に生ずる。 ＢａｓｅＲｅｓｏｕｒｃｅは、ほとんどのルータ・コンポーネントが導出され るような分類オブジェクトである。図１３に示すように、それは、次に示すこれ らのアトリビュートから構成される： 資源の分類： ルート分類１１９ ペアレントをもたずかつ特定資源表に登録してい ない資源。資源トゥリー全体の開始点。 サービス分類１２０ ホスト−配送のようなシステム全体サービスまた はＩＰ及びＩＰＸのようなネットワーク・プロト コルを供 給する資源。これらの資源は、サービス 資源表に登録しかつあるル ート資源に対する子供 である。ネットワーク・サービスは、画定さ れた 組合せＭＩＢテンプレートを有する。 コンポーネント分類１２１ サービス資源のコンポーネントでありかつコ ンポ ーネント資源表の中に登録する資源。ルータ内の ほとんどのコンポーネント分類資源は、画定され た共通ＭＩＢテン プレートを有する。 インターフェイス分類１２２ 装置が有する各インターフェイス上で生成される 資源。ルータ装置で画定された各ＭＩＢ−ＩＩイ ンターフェイスに対して、インターフェイス資源 がこのコンポーネ ントに対して存在する。この資 源は、インターフェイス資源表の中 に登録する。 ＩＰ及びＩＰＸプロトコルに対するＢａｓｅＲｅｓｏｕｒｃｅ階層構造の一例 は、図１４に示される；資源オブジェクトは、ＩＰ Ｒｅｓｏｕｒｃｅｓに対し て接尾部“ａ”、ＩＰＸ Ｒｅｓｏｕｒｃｅｓに対して“ｂ”を有して図１３に おけるのと同様な方法で番号付けされる。 Ｆ．２ ＢａｓｅＲｅｓｏｕｒｃｅ機能状態 管理状態 enum（列挙）：（１）Other（他のもの）、（２）Enabled（イネーブル）、（ ３）Disabled（ディスエーブル） この項目は、資源の構築の間中にあるデフォルト状態に初期化されかつＭＩＢ テンプレートが存在するならば、管理によって変更することができる。 動作状態 enum（列挙）：（１）Other（他のもの）、（２）Enabled（イネーブル）、（３ ）Disabled（ディスエーブル）、（４）Pending Enabled（保留イネーブル）、 （５）Pending Disabled（保留ディスエーブル）、（６）Invalid Config（無効 構成） この項目は、資源の現行動作状態を反映する。これは、管理状態または発生し えたある他の内部事象に対する管理変更の結果である。 Ｆ．３ 状態変更 ルート(root)分類が状態を変えるとき、それは、主要分枝をもたらす。アンダ ーライング・サービス、コンポーネント、及びインターフェイス資源も同様に変 えなければならない。インターフェイス分類が状態を変えるとき、ほとんどの場 合にそれはそのコンポーネントのインターフェイス・オブジェクトに影響を及ぼ すだけである。状態が変わるときにコンポーネントまたはインターフェイス資源 が他の資源と協同しなければならない場合がある。これは、構成事象を通して処 理される。ＢａｓｅＲｅｓｏｕｒｃｅが状態を変えるときに、Ｏｐｅｒａｔｉｏ ｎａｌ−Ｔｉｍｅ（動作時間）は、この資源に対してリセットされる。 Ｆ．４ ＢａｓｅＲｅｓｏｕｒｃｅ ＢａｓｅＴａｂｌｅ及びペアレント資源ポ インタ及び処理 ＢａｓｅＲｅｓｏｕｒｃｅコンポーネントは、それらのペアレント資源及びそ れらの対応コンポーネント表及びインターフェイス表（もしそれらが有するなら ば）へのポインタを含む。これらのポインタを用いることによって、資源は、ペ アレント及び同胞資源からの有用な情報を検索すると同様にインターフェイス資 源表からのインターフェイス資源を制御することができる。また、維持されるの は、コンポーネント処理番号である。ＢａｓｅＲｅｓｏｕｒｃｅが他のＢａｓｅ Ｒｅｓｏｕｒｃｅをインスタンス生成するときに、この処理は、増分されかつ検 索され、そして子供ＢａｓｅＲｅｓｏｕｒｃｅがそれらの適切資源表に登録する ときに、ペアレントの現行処理番号が処理ｉｄ（ＩＤ）またはコンポーネント・ インデックスとして用いられる。 Ｆ．５ 資源の型 ・ Null Type（ヌル型）は、特定の識別を持たずかつ表に登録しない。 ・ Network Protocol Type（ネットワーク・プロトコル型）は、ＩＰ、ＩＰ Ｘ、及びＤＥＣｎｅｔのようなルート可能なプロトコルである。この型は、画定 された共通ＭＩＢテンプレートを有する。 ・ コンポーネント資源をアドレス指定しているConfig Type（構成型）は、 プロトコルのネットワーク・アドレス表またはシステム全体ネットワーク・アド レスから構成される。 ・ FIB Type（ＦＩＢ型）−−この資源は、フォワーディング情報ベースであ る。ほとんどのネットワーク・プロトコルは、それらを有しかつ所与のネットワ ーク・アドレスの次のホップ・インターフェイスをルックアップするためにフォ ワーディング・エンジンによって用いられる。経路指定プロトコルは、所与のネ ットワーク・アドレスのそれらの最良の次のホップ・インターフェイスを配置す るためにＦＩＢを用いる。これらのアドレスは、プロトコルを通して動的に学習 される。この型に対する共通ＭＩＢテンプレートは、存在しない。 ・ FAS Type（ＦＡＳ型）−−この資源は、フォワーディング・エンジン（サ ービス及びフォワード）である。プロトコルは、それが構成される各インターフ ェイスに対するＦＡＳオブジェクトを生成する。ＦＡＳは、インターフェイスか らパケットを受け取り、その内容を確認し、そしてそれを 送り出すために次のホップ・インターフェイスを分解すべくＦＩＢを呼び出す。 分類インターフェイスであるＦＡＳオブジェクトは、それもまた型ＦＡＳのペア レントによって生成されかつ管理される。この型は、画定された共通ＭＩＢテン プレートを有する。 ・ ARPType（ＡＲＰ型）−−これは、ＡＲＰ資源（ＡＲＰ＝アドレス指定分 解プロトコル）である。この資源は、分類インターフェイス及びコンポーネント 資源である。ＡＲＰは、所与のネットワーク・アドレスの物理インターフェイス ・アドレスを分解するために用いられる。この型は、画定された共通ＭＩＢテン プレートを有する。 ・ Routing Protocol Type（経路指定プロトコル型）−−この経路指定プロ トコル資源は、スレッド・コンテキストにおいて走行する資源である。それは、 経路指定プロトコル、距離ベクトル、かつリンク状態基本分類において画定され た経路指定プロトコル・アトリビュートを取る。それらは、同じ型の経路指定プ ロトコル・オブジェクトのインターフェイス表並びにトポロジー・データベース 、及びカウンタを含む。 ・ System Wide Type（システム全体型）−−この資源は、システム全体レベ ル上にある。起動されかつ停止されることが必要なのでそれらは、ＢａｓｅＲｅ ｓｏｕｒｃｅである。 ・ Component Specific Type（コンポーネント指定型）−−ＢａｓｅＲｅｓ ｏｕｒｃｅが十分に一般化することができないならばこの資源型が用いられる。 これは、適当な一般資源型が発見されるまで用いることができる。 Ｆ．６ 他の資源情報 次の情報は、Root（ルート）、Service（サービス）、及びComponent（コンポ ーネント）分類資源に対して有用である。これらの資源項目は、管理が共通ＭＩ Ｂテンプレートに対してこの情報を得ることが必要であるときに必要とされる。 ・ Operational Time（動作時間）−−資源がその現行動作状態に存在してい る時間を維持する。 ・ Version Number（バージョン番号）−−サービスまたはコンポーネント 分類資源の現行バージョン番号。 ・ Resource Name（資源名）−−資源がそのサービスまたはコンポーネント を命名することができる。 ・ Enterprise MIB Id（エンタプライズＭＩＢ ＩＤ）−−このサービスま たはコンポーネント分類資源に対するオブジェクト識別子は、画定されたＭＩＢ テンプレートが存在しなくても構築においてパラメータとしてパスされる。資源 は、次いで必要なところに追加ｉｄｓを追加することができる。 ・ Naming Tree Identifier（命名トゥリー識別子）−−このサービスまたは コンポーネント分類資源に対する命名トゥリー・オブジェクト識別子。 Ｆ．７ アクセス機能 一度ＢａｓｅＲｅｓｏｕｒｃｅポインタが位置決めされたならば、上述した全 ての情報は、公衆方法を通して管理に対してアクセス可能である。 ＢａｓｅＲｅｓｏｕｒｃｅの主要アクセス機能は、ペアレントＢａｓｅＲｅｓ ｏｕｒｃｅによって呼び出される。これらの機能は、次のものである： ・ Construction（構築）： ＢａｓｅＲｅｓｏｕｒｃｅは、ＭＩＢエンタプ ライズｉｄ、デフォルト管理状態、資源の分類、資源の型、及びそのペアレント ＢａｓｅＲｅｓｏｕｒｃｅへのポインタで構築される。 ・ Initialization（初期化）： これは、ポスト構築初期化を発生させるス タートアップ機能である。 ・ Activation（起動）： これは、コンポーネントの管理状態が管理を通し てイネーブルされ、かつまたコンポーネントがイネーブルにデフォルトされるな らばスタートアップ時間で、呼び出される。スタートアップ時間起動は、全ての 他の資源が装置において生成された後で資源に資源起動を実行させる。起動が生 ずるときには、資源は、それ自身の起動をまず許容し、次いで、それは、それが 含む全ての資源表にTableActivate を実行することによって起動を子供Ｂａｓｅ Ｒｅｓｏｕｒｃｅに伝える。 ・ Deactivation（停止）： これは、コンポーネントの管理状態が管理を通 してまたはある内部事象を介してディスエーブルされるときに呼び出される。停 止が生じるときには、資源は、それ自体の停止をまず許容し、次いで、それは、 それが含む全ての資源表にTableDeactivate を実行することによって停止を子供 ＢａｓｅＲｅｓｏｕｒｃｅに伝える。 ・ Reconfiguration（再構成）： これは、内部資源事象がルート、サービ スまたはコンポーネント・レベル内で生じたときに呼び出される。再構成が生じ たときには、資源は、それ自体の再構成をまず許容し、次いで、それは、それが 含む全ての資源に再構成を実行する。 ・ Destruction（破壊）： これは、資源オブジェクトが再初期化フェーズ の間中に破壊されるときに呼び出される。 Ｆ．８ ＢａｓｅＲｅｓｏｕｒｃｅ−Ｒｅｓｏｕｒｃｅ Ｔａｂｌｅ関係 ＢａｓｅＲｅｓｏｕｒｃｅの種々のレベルとＲｅｓｏｕｒｃｅ Ｔａｂｌｅｓ （資源表）との間の関係は、図１５に示されている。 サービスＲｅｓｏｕｒｃｅ Ｔａｂｌｅ（サービス資源表）１２３は、ｃｔＲ ｏｕｔｅｒ−ＭＩＢ下で管理可能な、読取り専用表である。サービスＢａｓｅＲ ｅｓｏｕｒｃｅｓ１２０が生成されるときには、それらは、それらの適切なサー ビスＲｅｓｏｕｒｃｅＴａｂｌｅでそれらの資源ポインタ及び処理ｉｄを登録す る。 コンポーネントＲｅｓｏｕｒｃｅ Ｔａｂｌｅ１２４は、ｃｔＲｏｕｔｅｒ− ＭＩＢ下で管理可能な、読取り専用表である。コンポーネントＢａｓｅＲｅｓｏ ｕｒｃｅｓ１２１がそれらのペアレントＳｅｒｖｉｃｅ資源によって生成される ときには、それらは、それらの適切なコンポーネントＲｅｓｏｕｒｃｅＴａｂｌ ｅ、及びまたインターフェイスＲｅｓｏｕｒｃｅＴａｂｌｅで、それらの資源ポ インタ、処理ｉｄ、及びコンポーネント・インデックスを登録する。 インターフェイスＲｅｓｏｕｒｃｅ Ｔａｂｌｅ１２５は、Ｓｅｒｖｉｃｅの ＭＩＢ下で管理可能な表である。インターフェイスＢａｓｅＲｅｓｏｕｒｃｅｓ １２２が生成されるときには、それらは、それらのペアレントのコンポーネント Ｉｎｔｅｒｆａｃｅ ＲｅｓｏｕｒｃｅＴａｂｌｅの中にそれらの資源ポインタ 及びインターフェイス番号を登録する。Ｓｅｒｖｉｃｅ及びＣｏｍｐｏｎｅｎｔ ＲｅｓｏｕｒｃｅＴａｂｌｅｓは、Ｒｏｏｔ（ルート）レベルＢａｓｅＲｅｓ ｏｕｒｃｅによって生成される表である。Ｉｎｔｅｒｆａｃｅ Ｒｅｓｏｕｒｃ ｅ Ｔａｂｌｅｓは、必要なときにコンポーネント資源によって生成される。 Ｆ．９ 資源表説明 ＲｅｓｏｕｒｃｅＴａｂｌｅは、二つの目的を提供する：（１）それは、それ らが一定の方法で初期化され、起動され、停止され、再構成され、かつ破壊され るように同じ分類のＢａｓｅＲｅｓｏｕｒｃｅの順序付けられた一覧表を供給す る；及び（２）それらは、Ｃｏｍｐｏｎｅｎｔ（コンポーネント）及びＳｅｒｖ ｉｃｅ（サービス）型表に対してｃｔＲｏｕｔｅｒ−ＭＩＢによって、またはイ ンターフェイス表に対してネットワーク・プロトコルＭＩＢによって管理可能で ある。 Ｆ．１０ Ｒｅｓｏｕｒｃｅ Ｔａｂｌｅｓの分類 Service Class（サービス分類）−−ルート・レベルＢａｓｅＲｅｓｏｕｒｃ ｅによって割り当てられる処理ｉｄによって例に挙げられるネットワーク・プロ トコル表またはシステム・サービス表のいずれか。この例は、プロトコルのコン ポーネント資源に対する処理として用いられる。この表は、読取り専用ＭＩＢと して画定される。 Component Class（コンポーネント分類）−−ペアレントのサービス処理ｉｄ 及びコンポーネント・インデックスによって例に挙げられた、サービス下の、コ ンポーネント資源表。インデックスは、サービス資源によって割り当てられたコ ンポーネント資源の処理ｉｄである。この表は、読取り専用ＭＩＢとして画定さ れる。 Interface Class（インターフェイス分類）−−ＭＩＢ−ＩＩによって画定さ れたように論理インターフェイス番号によって例に挙げられたインターフェイス 表。一つのＲｓｃＥｎｔｒｙは、インターフェイス毎に生成されかつ表に加えら れる。表サイズは、装置のインターフェイスの数に等しい。この表は、ＭＩＢ管 理可能でありかつプロトコル・サービスＭＩＢで画定される。これへの新しいエ ントリは、ＭＩＢを通して追加することができない。インターフェイス表エント リは、資源の型に特定的な追加パラメータを管理するために拡張することができ る。共通ＭＩＢテンプレートは、それらのインターフェイス表及びそれらの追加 リーブを画定する。 Ｆ．１１ ＲｅｓｏｕｒｃｅＴａｂｌｅエントリ画定 ＲｓｃＥｎｔｒｙ−−ＲｅｓｏｕｒｃｅＴａｂｌｅの基本エントリを画定する 、例えば、 ・ 処理またはインターフェイス番号 ・ インデックス・フラグ ・ 管理状態 ・ ＢａｓｅＲｅｓｏｕｒｃｅポインタ 表がインターフェイス表であるならば、追加フィールドが追加される。 Ｆ．１２ ｃｔＲｏｕｔｅｒ Ｈｉｇｈ−Ｌｅｖｅｌ ＭＩＢとＲｏｕｔｅｒ Ｒｅｓｏｕｒｃｅ Ｃｏｍｐｏｎｅｎｔ Ｒｅｌａｔｉｏｎｓｈｉｐ ｓ（ｃｔルータ高レベルＭＩＢとルータ資源コンポーネントの間の関 係） ctRouter High-Level MIB（ｃｔルータ高レベルＭＩＢ）とRouter Resource C omponents（ルータ資源コンポーネント）の間の関係は、図１６に示されている 。 Router Service Table（ルータ・サービス表）１２６は、ｃｔＲｏｕｔｅｒＭ ＩＢ下の読取り専用ＲｅｓｏｕｒｃｅＴａｂｌｅである。ＩＰ、ＩＰＸ及びＤＥ Ｃｎｅｔのようなネットワーク・プロトコル・サービスが生成されるときに、そ れらは、それらの資源ポインタ及び処理ｉｄをこの表の中に登録する。 Router Component Resource Table（ルータ・コンポーネント資源表）１２７ は、ｃｔＲｏｕｔｅｒ−ＭＩＢ下の管理可能、読取り専用である。コンポーネン トＢａｓｅＲｅｓｏｕｒｃｅｓがそれらのペアレントＳｅｒｖｉｃｅ資源によっ て生成されるときに、それらは、それらの資源ポインタ、サービス処理ｉｄ、及 びコンポーネント処理ｉｄをＲｏｕｔｅｒ Ｃｏｍｐｏｎｅｎｔ Ｒｅｓｏｕｒ ｃｅＴａｂｌｅに登録する。 Ｆ．１３ Ｒｏｕｔｅｒ Ｔｅｍｐｌａｔｅｓ（ルータ・テンプレート） ルータ・テンプレートは、ルータ・プロトコルに対する基本フレームワークを 画定する。実質的にルータ・テンプレートは、ネットワーク・プロトコルがそれ らのプロトコルをインプリメントするために従う一組の機能モデルを含む。各テ ンプレートは、機能インプリメント及び共通ＭＩＢテンプレートも同様に画定す る。図１７に示されかつ以下に説明される全てのテンプレートは、ＢａｓｅＲｅ ｓｏｕｒｃｅから導出されるオブジェクト指向型Ｃ＋＋分類である。 Network Protocol Template Class（ネットワーク・プロトコル・テンプレー ト分類） ProtocolResource（プロトコル資源）は、ネットワーク・プロトコルの機能イ ンプリメンテーションを画定する基本分類である。この資源は、順序立ってコン ポーネント・テンプレート分類の生成を協調させかつネットワーク・プロトコル が管理できるようにSystem Admin MIB（システム管理ＭＩＢ）をインプリメント する。また、それは、再構成事象を容易にする（促進する）ことができる中心点 である。 Component Template Classes（コンポーネント・テンプレート分類） Component Resources（コンポーネント資源）は、コンポーネント・オブジェ クトの機能インプリメンテーションを画定する基本分類である。例えば、Base C onfig（基本構成）は、インターフェース毎のネットワーク・アドレスを構成し かつアクセスするために機能インプリメンテーションを画定する。 Interface Template Classes（インターフェイス・テンプレート分類） Interface Resources（インターフェイス資源）は、インターフェイス・オブ ジェクトの機能インプリメンテーションを画定する基本分類である。パケット・ イン／アウト及びバイト・イン／アウトの性能カウンタは、この資源に維持され る。インターフェイス番号及びある一定のインターフェイス状態（経路指定オン ／オフのような）へのアクセスは、ここでアクセスされる。 Ｇ． ＭＩＢ Ｎａｖｉｇａｔｏｒ（ＭＩＢナビテータ） この視覚表示機構は、ファイル・システムのセマンティクスを有するルータ資 源トゥリー（全ルータ・オブジェクト）をユーザに見させかつ制御させる。オブ ジェクト・コンテナーは、ディレクトリとして処理され、個別オブジェクトは、 ファイルとして処理される。これは、通信／ネットワーキング・コンポーネント の明確な知識なしで通信システムの中への完全なアクセスを許容する。ユーザは 、例えばルート(root)をスタートしかつ正しいオブジェクト（ファイル）が供給 されるまで読むことができる。注：これは、ファイル・システムを持たない組込 みシステムの内側である。 ＭＩＢナビゲータは、ネットワーク管理者がネットワーキング装置を管理する 方法を簡略化する。それは、ユーザに装置の現行構成を素早く走査検索(browse) させると共によりフレキシブルでかつ操作するのに使いやすいインターフェイス をユーザに与える回線指向型指令回線インターフェイスを供給する。このインタ ーフェイスは、装置の内部構成データベースのテキスト表現を供給し、ほんの少 しの文書またはそれなしでユーザに装置の構成を読取りまたは変更できるように させる。 ＭＩＢナビゲータは、Simple Network Management Protocol（簡略ネットワー ク管理プロトコル（ＳＮＭＰ））の上の概念レベルを動作（操作）することによ ってその指令回線インターフェイスを供給する。ＳＮＭＰは、要求を装置の内部 データベース、Management Information Base（管理情報ベース（ＭＩＢ））に パスすることにより動作する。これらの要求の形は、データベース内のそのオブ ジェクトに対して固有である、オブジェクトの識別子（ＯＩＤ）を用いて、その データベース内のオブジェクトに対する照会（問合せ）から構成されている。し かしながら、これらのＯＩＤは、数のストリング（即ち、１．３．６．１．２． １．１．１．０）から構成されており、ユーザの観点から理解または作業するこ とを難しくさせている。 ＭＩＢナビゲータは、数のストリングよりも消化することがユーザに対して容 易である、これらＯＩＤに対するテキスト表現を供給することによってこれらの 要求のフォーマットを簡略化する。ＭＩＢ内のオブジェクトにＡＳＣＩＩ名をマ ッピングするのと一緒に、ＭＩＢナビゲータは、また、ＭＩＢの上に“ファイル ・システム”型の階層を配置する。ちょうどユーザがコンピュータのファイル・ システムにおいて回りをナビゲートするときに、この階層インターフェイスは、 装置のルータ・オブジェクトを読まさせる。あたかもコンピュータ・ファイル・ システムのように、ここでユーザは、ＭＩＢの回りをローム(roam)し、一部のデ ータをチェックし、かつオブジェクトの識別子を知ることを要求されることもな く必要なところで変更を行うことができる。ユーザは、ユーザの現行位置（ファ イル・システムの“ディレクトリ”）を変更することができるかまたはユーザは 、オブジェクトの内容（ファイル・システムの“ファイル”）を検査することが できる。ユーザは、その数字識別子の代わりに、そのテキスト説明を用いて所望 のオブジェクトをアクセスしうる。 ＭＩＢ内のオブジェクトのテキスト表現は、装置内の各オブジェクトに対して 、他のデータと一緒に、テキスト・ストリングスを記憶することによって達成さ れる。オブジェクトがアクセスされるときに、その対応テキスト・ストリングは 、オブジェクトに対してシームレス・インターフェイスを供給するために、その 数字識別子に取って代わられる。ユーザがＭＩＢのオブジェクトに対して数字識 別子を使用することの要求は、取り除かれて、その代わりにそのユーザにより有 益(informative)かつ直観的(intuitive)なテキスト・ストリングスを使用させる 。 図１８には、装置の構成名(configured name)を介して一部のデータをアクセ スする従来のＳＮＭＰ方法体系が示されている。このデータをアクセスするため に、ユーザは、ＭＩＢの要求を行ないかつオブジェクトの識別子（即ち、１．３ ．６．１．２．１．１．１．０）を与えなければならない。ユーザが上記と同様 に、複数のアクセスまたは変更を行わなければならないと想定する。ユーザは、 それぞれが莫大な長さの識別子を有することができる、各オブジェクトの識別子 を知ることをここで要求される。これは、非常に退屈な仕事になる。 図１９には、同じ一部のデータをアクセスする新しい方法体系が示されている 。データをアクセスするために、階層の各オブジェクトがそのテキスト名で用い ら れる。各オブジェクトに対するテキスト・ストリング名を用いることは、“get/ iso/org...．”をもたらす。“ｍｉｂ−２”が使用するための非常に一般的なオ ブジェクトなので、ユーザは、更なるアクセスを短縮するために、それにユーザ の現行位置を変更することができる。そのようにしたならば、上記のアクセスは 、ここで“get system/sysDescr.”に短縮される。 本発明の多数の実施例が示されかつ説明されたが、種々の変形及び変更が添付 した請求の範囲によって画定された本発明の範疇から逸脱することなくその中で 行われうるということは、当業者に自明であろう。

【手続補正書】特許法第１８４条の８ 【提出日】１９９６年３月１４日 【補正内容】 即ち、ＬＡＮアクセス・ポートへの増分は、大きなステップ機能で行われる。 更なるスケーラビリティを許容するために、ルータ機能は、分散型ハブの中に 統合される。図１Ｂに示すように、これは、ユーザがネットワークの中に物理連 結性を得る点まで経路指定機能性を実質的に“プッシュ”アウトする。更に、こ れらの分散型ルータは、経路指定機能をオフ・ローディングすることによって集 中ルータの中により大きなネットワーク・アクセスを許容する（図１Ｃ）。 経路指定機能性がプッシュ・アウトされかつより広く配備されると、それは、 これら分散型装置の構成及び制御に強大なひずみ(tremendous strain)を設置す る。また、ハブが、大くのＬＡＮ技術によるアクセスを供給するので、ハブのル ータは、同じシャーシで広範囲のネットワーク連結性に対する支持を有さなけれ ばならない。更に、アクセス・ポートの数は、これらのポートがネットワークの エンド・ユーザに連結性を供給するので、１または２から数百まで変化すること ができる。 これらの分散型ハブ及びネットワーク装置において経路指定サービスをインプ リメントすることができるためには、アーキテクチャは、かなり可撓性であり、 スケーラブルであり、かつ異なるハブ構成及びシャーシに適応可能であり、かつ 種々の現在及び将来のプロトコルを支持することができる。また、アーキテクチ ャは、これらの分散型ハブにおける経路指定の動作及び制御がネットワークにお けるこれらの装置のシーヤ・ナンバー(sheer number)により及びハブ／ルータに 統合された技術の変化により実質的に更に難しいので、高度の従順性(high degr ee of manageability)を供給することが必要である。 大きな通信ネットワークは、多数の異なるプロトコル及び媒体技術に基づいて メッセージを送ることができなければならない。従来の通信システムは、一組の 離散型サブシステムのまわりに一般に構築される。これらの離散型サブシステム は、かなり統合されうるが、それらは、機能的に個別部分として動作する。例え ば、多重通信プロトコル・スタック(stacks)が支持されるときに、それぞれは、 完全個別構成、制御、監視、ネットワーク管理、及びプロトコル指定動作／機能 性を有する、例えば、ＩＰスタック、ＩＰＸスタック、ＤＥＣｎｅｔスタックの ような、完全に異なる“垂直”スタックとして存在する。そのようなシステムは 、 管理するのが難しくかつインプリメントするのに費用が掛かる。 従来のシステムの別の問題は、各データ・パケットによって生成される大きな オーバーヘッドである。従来の通信アーキテクチャは、送信及び受信のサービス を供給している各層を有する層状モデルを用いる。一般に、パケットは、あるネ ットワーク・インターフェイス上に装置を入力しかつインターフェイスの上に置 かれているプロトコル層に手渡される。このプロトコル層は、次に、パケットを 処理しかつそれを上の次の層へ手渡す。ルータの場合には、ネットワーク層は、 パケットを結果的に処理し、それがフォワードされなければならないインターフ ェイスを決定し、かつそれがフォワーディング・インターフェイスから最終的に 送信されるまでパケットを各層へ下方に送り戻す。 この従来システムでは、各プロトコルは、パケットを得てそれがインターフェ イスに対して適切であるかどうかを決定する。それは、パケットが入ってくるイ ンターフェイスに係わりなくシステムに入力しかつそれから出て行く全てのパケ ットに対するファンネル(funnel)であるプロトコル層を有する集中モデルである 。また、それが集中化されるので、各層は、全ての指定インターフェイスについ ての知識をもたなければならない。例えば、ＭＴＵサイズ、フォワーディング・ イネーブル／ディスエーブル状態、構成ネットワーク・アドレス及びマスク、デ ータ・リンク・フレーミング・オプション、フィルタ・アクセス一覧表、等のよ うな全ての構成インターフェイス情報は、それがパケットを処理／フォワードす るときに各層によってアクセスされなければならない。このモデルは、オーバー ヘッドを各層の中に置き、かつ各層が変更されなければならないときに新しいイ ンターフェイス、媒体及びプロトコルを支持することにおいてかなり制限する。 オーバーヘッドの一例は、パケットがイネーブルされていないプロトコルに対し て受信されたならば、それが正しいプロトコル層に渡されるまでそれは降下され ないということである。 複合マルチプロトコル経路指定ネットワークの一例は、コールオン等(Callon et al.）による米国特許第 5,251,205号公報に記載されている。コールオンでは 、個別垂直スタックは、ＩＰプロトコル及びＯＳＩプロトコルのそれぞれに対し て設けられている。これらプロトコルの両方に通信することの試みにおいて、第 ３ の所有権を主張できるプロトコル（ＤＵＡＬ）が設けられている。再度、この多 重プロトコル経路指定システムのオーバーヘッド、複雑性及び費用は、法外であ る。 オブジェクト指向型アーキテクチャは、例えば、フィンケル(Finkel)による欧 州特許第 054950482号公報、及びアーノルド(Arnold)による欧州特許第 0405829 82号公報に示されているように、通信ネットワーク及び切替式通信ネットワーク における呼出し処理を管理するために提案されている。しかしながら、これらの 参考文献のいずれも、従来技術の欠点、即ち、費用、複雑性、及びスケール不能 を克服する多重プロトコル経路指定システムをインプリメントしていない。 発明の概要 本発明は、サービスの高い可用性、遠隔管理及び監視、及び相互運用性を供給 する通信ネットワーク上の情報を経路指定する装置及び方法である。 システムは、アンダーライイング・メディア並びにプロトコルの両方における 、変化する技術に対して開放的でありネットワークの大きさを拡張することに対 して開放的であるということを意味する、拡張可能アーキテクチャを有する。 本発明によれば、ネットワーク経路指定サービスを供給する装置及び方法は、 複数の相互接続多重プロトコル・ルータを含んでいる通信ネットワークにおいて 供給される。ルータ資源オブジェクト分類は、各ネットワーク・インターフェイ ス上の自律ルータ・オブジェクトをインスタンス生成するために供給される。ル ータ・オブジェクトは、（ａ）データ・パケットをフォワードしかつサービスす るための経路指定及びシステム機能；（ｂ）ネットワーク・インターフェイスの 構成及び制御；及び（ｃ）経路指定及びシステム機能の管理に対するデータ及び 方法を含む。方法によれば、各ルータ・オブジェクトは、多数の相互接続性プロ トコル及び媒休技術に共通な複数の基本オブジェクトをインスタンス生成するこ とによって初期化される。これら基本オブジェクトのそれぞれは、プロトコル指 定バウンド・オブジェクトを供給するために一つ以上のプロトコルまたはネット ワーク・インターフェイスにバウンド(bound)される。次いで、ネットワーク・ インターフェイスの一つにおけるデータ・パケットの到着に応答して、プロトコ ル指定バウンド・オブジェクトの一つは、データ・パケットをサービスまたはフ ォワードするために呼び出される。 これらの機能を各オブジェクトの中に分散することによって、各オブジェクト は、自律する、即ち、オブジェクトに対して通常外部にあるサービス及びデータ は、オブジェクト自体内に埋め込まれるかまたはアクセス可能である。 別の意味では、あるオブジェクトは、“ネットワークを渡って”分散される、 即ち、一つの中央フォワーディング・エンジンを供給するのとは反対に、本発明 では個別フォワーディング・エンジン・オブジェクトが各ネットワーク・インタ ーフェイスで供給される。 全てのオブジェクトは、バインディング及び順序付けられたスタート・アップ を許容すべく順序立って全てのオブジェクトをインスタンス生成する、ルータ資 源オブジェクトを通して連結される。一度オブジェクトが存在すると、それらは 、それぞれがそれ自体の．．．．を知ることにおいて自律する。 請求の範囲 １．複数の相互接続された多重プロトコル・ルータを含んでいる通信ネットワー クにおいて、データ・パケットをサービスしかつフォワードすることを含んでい る、ネットワーク経路指定サービスを供給する方法であって、 各ネットワーク・インターフェイス（１１；１４）上の自律ルータ・オブジェ クト（１２，１３；１５，１６）をインスタンス生成するためにルータ資源オブ ジェクト分類（２０７）を供給し、該ルータ・オブジェクトは、 ａ）データ・パケットをフォワードしかつサービスする経路指定及びシステム 機能（２０３）； ｂ）ネットワーク・インターフェイスの構成及び制御（２０４）； ｃ）経路指定及びシステム機能の管理（２０２）；に対するデータ及び方法を 含んでおり； 多数の相互接続性プロトコル及び媒体技術に共通な複数の基本オブジェクト（ １１１）をインスタンス生成することによって各ルータ・オブジェクトを初期化 し； プロトコル指定バウンド・オブジェクト（１１２，１１３，１１４，１１５） を供給するために一つ以上のプロトコルまたはネットワーク・インターフェイス に基本オブジェクトのそれぞれをバインドし；かつ ネットワーク・インターフェイス（１１，１４）の一つにおけるデータ・パケ ットの到着に応答して、データ・パケットをサービスまたはフォワードするため にプロトコル指定バウンド・オブジェクトの一つを呼び出す段階を具備すること を特徴とする方法。 ２．前記ルータ・オブジェクトの経路指定及びシステム機能を遠隔的に管理する （２２８）を含んでいることを特徴とする請求項１に記載の方法。 ３．前記ルータ・オブジェクトを不揮発性メモリに記憶する（２１１）ことを含 んでいることを特徴とする請求項１または２に記載の方法。 ４．前記基本オブジェクトは、共通管理情報ベース（ＭＩＢ）構造（２０９）を 有することを特徴とする請求項１から３のいずれか一項に記載の方法。 ５．前記データは、ネットワーク・トポロジー情報及び前記ルータ・オブジェク ト交換ネットワーク・トポロジー情報（２１９）を含むことを特徴とする請求項 １から４のいずれか一項に記載の方法。 ６．前記ルータ（１０５，１０６，１０７，１０８）は、前記ネットワークにわ たり分散されかつエンド・システム（１０１，１０２，１０３，１０４）にアク セス点を供給し、各該ルータは、他のルータ及びエンド・システムへの連結のた めの複数のネットワーク・インターフェイスを有していることを特徴とする請求 項１から５のいずれか一項に記載の方法。 ７．前記初期化段階は、各個別プロトコルに対する経路指定アプリケーション・ オブジェクト（２１９）の多重インスタンス生成（２０６）を有する前記ルータ ・オブジェクトを供給することを特徴とする請求項１に記載の方法。 ８．前記初期化段階は、各個別プロトコルに対するフォワーディング・オブジェ クト（２３４）の多重インスタンス生成（２０６）を有する前記ルータ・オブジ ェクトを供給することを特徴とする請求項１に記載の方法。 ９．前記基本オブジェクトは、ルータ・サービス（２１４）、ルータ・コンポー ネント（２１５）、ルータ・インターフェイス（２１６）、ルータ構成（２１７ ）、及び事象（２１８）の少なくとも一つを含むことを特徴とする請求項１に記 載の方法。 １０．フレーミング及びプロトコル識別子基準にマッチしているネットワーク層 データ・パケットを受信するためにネットワーク層プロトコルを登録すること （２０）を更に含んでいることを特徴とする請求項１に記載の方法。 １１．ネットワーク層アドレスをフレーミング・フォーマットにマップし、かつ 物理層アドレスをネットワーク層アドレスにマップすることを更に含んでいるこ とを特徴とする請求項１０に記載の方法。 １２．前記基本オブジェクトは、アプリケーション・スレッドに多重事象を同時 に給仕させるルータ事象基本分類（３６）を含むことを特徴とする請求項１に記 載の方法。 １３．前記基本オブジェクトは、キャッシュ基本分類を含むことを特徴とする請 求項１に記載の方法。 １４．前記基本オブジェクトは、アクセス制御基本分類を含むことを特徴とする 請求項１に記載の方法。 １５．各基本オブジェクトにタイマ（３８）を供給することを更に含んでいるこ とを特徴とする請求項１に記載の方法。 １６．各オブジェクトに対するテキスト名を供給しかつ階層トリーに前記オブジ ェクトを配列することを更に含み、各オブジェクトは、そのテキスト名により前 記トリーにおいてアクセスされることを特徴とする請求項１に記載の方法。 １７．オブジェクト名のマッピングに対する処理を供給することを更に含んでい ることを特徴とする請求項１に記載の方法。 １８．複数の相互接続された多重プロトコル・ルータを含んでいる通信ネットワ ークにおいて、データ・パケットをサービスしかつフォワードすることを含んで いる、ネットワーク経路指定サービスを供給する装置であり、プロセッサ及び命 令のプログラムを有するメモリを備えている装置であって、 各ネットワーク・インターフェイス（１１；１４）上の自律ルータ・オブジェ クト（１２，１３；１５，１６）をインスタンス生成するためにルータ資源オブ ジェクト分類（２０７）を画定する手段と、 多数の相互接続性プロトコル及び媒体技術に共通な複数の基本オブジェクトを インスタンス生成する手段と、 プロトコル指定バウンド・オブジェクトを供給するため一又は一以上のプロト コルまたはネットワーク・インターフェイスに前記基本オブジェクトのそれぞれ をバインドする手段と、 前記ルータの一つにおけるデータ・パケットの到着に応答して、前記データ・ パケットをサービスまたはフォワードするためにプロトコル指定バウンド・オブ ジェクトの一つを呼び出す手段とを備え、 上記ルータ・オブジェクトは、 ａ）データ・パケットをフォワードしかつサービスする経路指定及びシステム 機能（２０３）； ｂ）ネットワーク・インターフェイスの構成及び制御（２０４）； ｃ）経路指定及びシステム機能の管理（２０２）；に対するデータ及び方法を 含んでいることを特徴とする装置。 １９．前記メモリは、前記オブジェクトを記憶する不揮発性メモリ（２１１）を 含むことを特徴とする請求項１８に記載の装置。 ２０．前記オブジェクトの遠隔管理ケイパビリティのためのネットワーク管理シ ステム（２２８）を更に含んでいることを特徴とする請求項１８または１９に記 載の装置。 ２１．各ルータ（１０５，１０６，１０７，１０８）は、前記ネットワーク層に おいてデータ・パケットをフォワードしかつネットワーク・トポロジー情報を交 換するためのソフトウェア及びハードウェアを含むことを特徴とする請求項１８ から２０のいずれか一項に記載の装置。 ２２．前記ルータ・オブジェクトは、各個別プロトコルに対する経路指定アプリ ケーション・オブジェクト（２１９）の多重インスタンス生成（２０６）を含む ことを特徴とする請求項１８に記載の装置。 ２３．前記ルータ・オブジェクトは、各個別プロトコルに対するフォワーディン グ・オブジェクト（２３４）の多重インスタンス生成（２０６）を含むことを特 徴とする請求項１８に記載の装置。 ２４．前記基本オブジェクトは、ルータ・サービス（２１４）、ルータ・コンポ ーネント（２１５）、ルータ・インターフェイス（２１６）、ルータ構成（２１ ７）、及び事象（２１８）の少なくとも一つを含むことを特徴とする請求項１８ に記載の装置。 ２５．前記基本オブジェクトは、経路指定アプリケーションの共通制御をイネー ブルする共通管理情報ベース（ＭＩＢ）構造及び内容を有することを特徴とする 請求項１８から２１のいずれか一項に記載の装置。 ２６．前記自律ルータ・オブジェクトは、ネットワーク・トポロジー情報を交換 する手段（２１９）及び次のホップ・パスを決定する手段を含むことを特徴とす る請求項１８に記載の装置。 ２７．フレーミング及びプロトコル識別子基準にマッチしているネットワーク層 データ・パケットを受信することをネットワーク層プロトコルに登録させる手段 （２０）を更に含んでいることを特徴とする請求項１８に記載の装置。 ２８．ネットワーク層アドレスをフレーミング・フォーマットにマップする手段 、及び物理層アドレスをネットワーク層アドレスにマップする手段を更に含んで い ることを特徴とする請求項１８に記載の装置。 ２９．前記基本オブジェクトは、アプリケーション・スレッドに多重事象を同時 に給仕させるルータ事象基本分類（３６）を含むことを特徴とする請求項１８に 記載の装置。 ３０．前記基本オブジェクトは、キャッシュ基本分類を含むことを特徴とする請 求項１８に記載の装置。 ３１．前記基本オブジェクトは、アクセス制御基本分類を含むことを特徴とする 請求項１８に記載の装置。 ３２．前記ルータ（１０５，１０６，１０７，１０８）は、前記ネットワークに わたり分散されかつエンド・システム（１０１，１０２，１０３，１０４）にア クセス点を供給し、各ルータは、他のルータ及びエンド・システムへの連結に対 する複数のネットワーク・インターフェイスを有していることを特徴とする請求 項１８に記載の装置。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ダビンス・クリス アメリカ合衆国 ニューハンプシャー州 03045，ゴッフズタウン，アップルトゥリ ー・ドライブ 22ｂ番 (72)発明者 コーマイヤ・レン アメリカ合衆国 マサチューセッツ州 01453，レオミンスター，ビスケーン・ス トリート 132番 (72)発明者 ヨー・ケビン アメリカ合衆国 ニューハンプシャー州 03060，ナシュア，エドウィン・ストリー ト 16番 (72)発明者 ハガティ・ウィリアム アメリカ合衆国 マサチューセッツ州 01827，ダンステイブル，ポンド・ストリ ート 244番 (72)発明者 シモヌウ・ポール アメリカ合衆国 ニューハンプシャー州 03053，ロンドンデリー，ハイ・レンジ・ ロード 160番 (72)発明者 ソクゼウィンスキー・リッチ アメリカ合衆国 ニューハンプシャー州 03087，ウィンダム，ナシュア・ロード 78番 【要約の続き】 にある。これは、多くの異なるシステム／ルータ・コン ポーネントの間中の共通アーキテクチャ、内部的制御の 共通方法、インスタンス生成の一定の順序、及び共通機 能動作を確実にする。

Claims (1)

1. 【特許請求の範囲】 １．複数の相互接続多重プロトコル・ルータを含んでいる通信ネットワークに おいてネットワーク経路指定サービスを供給する方法であり、データ及びそのよ うなサービスを供給する方法が分類及びオブジェクトの基本論理構成要素に統合 される方法であって、 多数の相互接続性プロトコル及び技術に共通な複数の基本オブジェクトをイン スタンス生成することによって各ルータを初期化し； プロトコル指定バウンド・オブジェクトを供給するために一つ以上のプロトコ ルまたはネットワーク・インターフェイスに基本オブジェクトのそれぞれをバイ ンディングし；かつ ルータの一つにおけるデータ・パケットの到着に応答して、データ・パケット をサービスまたはフォワードするためにプロトコル指定バウンド・オブジェクト の一つを呼び出す段階を具備する方法。 ２．複数の相互接続型多重プロトコル・ルータを含んでいる通信ネットワーク においてネットワーク経路指定サービスを供給する装置であって、 各ルータは、プロセッサ及びネットワーク層データ・パケットのフォワーディ ング及びネットワーク・トポロジー情報の交換を含んでいるサービスを供給する ための命令のプログラムを有するメモリを含み、データ及びそのようなネットワ ーク経路指定サービスを供給する方法が分類及びオブジェクトの基本論理構成要 素に統合されるようなオブジェクト指向型プログラムを含んでおり： 多数の相互接続性プロトコル及び技術に共通な複数の基本オブジェクトをイン スタンス生成する手段と； プロトコル指定バウンド・オブジェクトを供給するために基本オブジェクトの それぞれを一つ以上のプロトコルまたはネットワーク・インターフェイスにバイ ンディングする手段と； ルータの一つにおけるデータ・パケットの到着に応答して、データ・パケット をサービスまたはフォワードするためにプロトコル指定バウンド・オブジェクト の一つを呼び出す手段とを含む装置。 ３．ａ）処理手段； ｂ）複数の相互接続性プロトコル及び技術に共通な複数の基本オブジェクトと 、 プロトコル指定ネットワーク層経路指定サービスを供給するために基本オブジ ェクトの機能性を拡張する複数のプロトコル指定オブジェクトを記憶する手段； ｃ）通信ネットワークに経路指定装置を接続する手段；及び ｄ）処理及び記憶手段を制御する手段を備え、前記処理手段は、ネットワーク 経路指定サービスを供給するためにオブジェクトをインスタンス生成しかつ実行 するネットワーク経路指定装置。 ４．ネットワーク・アクセス点で ネットワークにわたり分散された複数の経路指定装置を含んでいるネットワー クを備え、 各経路指定装置は、ネットワーク層経路指定サービスを供給し、装置は、オブ ジェクト指向型プログラムを含み、データ及び動作は、分類及びオブジェクトの 基本論理構成要素に統合され、オブジェクトは、多数の異なる相互接続性プロト コル及び技術に共通な基本オブジェクトを含み、基本オブジェクトから導出され た複数のプロトコル指定オブジェクトは、プロトコル指定ネットワーク層経路指 定サービスを供給する分散型ネットワーク経路指定システム。 ５．フォワーディング及びサービス・エンジンは、発生源から宛先までのパス において次のホップを決定するために用いられる、ネットワーク層経路指定サー ビスを供給する経路指定装置であって、改良は、 データ及びそのようなネットワーク経路指定サービスを供給する方法が分類及 びオブジェクトの基本論理構成要素に統合されるようなオブジェクト指向型プロ グラム； 経路指定装置の各インターフェイスにおいて各媒体装置ドライバに対してイン スタンス生成されたインターフェイス・オブジェクト；及び、 それぞれがインターフェイス・オブジェクトの一つにバウンドされる、インス タンス生成された複数の個別フォワーディング及びサービス・エンジン・オブジ ェクトを含む経路指定装置。 ６．前記インターフェイス・オブジェクトは、 ネットワーク・パケットの登録及び伝達に対する複数の基本インターフェイス ・オブジェクトと、 基本オブジェクトから導出されかつ特定の媒体装置ドライバに固有な複数のプ ログラム指定インターフェイス・オブジェクトとを含む請求項５に記載の装置。 ７．前記フォワーディング及びサービス・エンジン・オブジェクトは、 ａ．ネットワークへのインターフェイス； ｂ．各サブネットへのネットワーク・パケットの固有フレーミング； ｃ．符号化及び復号を含んでいる各ネットワーク・プログラムに対してパケッ トを処理すること； ｄ．次のホップの決定を含んでいる、パケットをフォワードすること； ｅ．サービスが利用不能かまたは否定されたならばパケットを廃棄することを 含んでいる、パケットをフィルタリングすること； ｆ．アクティブな次のホップのデータ・キャッシュを利用すること；及び ｇ．ネットワーク・アドレスを媒体アドレスにマップするために最後のホップ においてアドレス分解を供給する請求項５に記載のシステム。 ８．ネットワーク層経路指定サービスを供給する方法において、改良は、 経路指定装置の各インターフェイスの各媒体装置ドライバに対するインターフ ェイス・オブジェクトをインスタンス生成し； 個別フォワーディング・エンジン・オブジェクトを各個別インターフェイス・ オブジェクトにインスタンス生成しかつバインドし； 経路指定装置の受信インターフェイスのデータ・パケットの受取りに応答して 、受信インターフェイスに対するインターフェイス・オブジェクトは、そのバウ ン ド・フォワーディング・エンジン・オブジェクトのサービス方法を呼出し； サービス方法は、ネットワーク・パケットのサブレイヤ・フレーミングを取り 除き； サービス方法は、ネットワーク・パケットからの宛先ネットワーク・アドレス の確認及び抽出を実行し； サービス方法は、宛先フォワーディング・エンジン・オブジェクト処理を決定 するためにアクティブ・アドレスのキャッシュ・メモリにおいて宛先ネットワー ク・アドレスをルックアップすることにより次のホップ決定を供給し、かつ宛先 ネットワーク・アドレスがキャッシュ・メモリに位置決めされていないならば、 宛先ネットワーク・アドレスへの最も良いルートに対してフォワーディング・ル ックアップ表をアクセスしかつキャッシュを更新し；かつ 宛先フォワーディング・エンジン・オブジェクト処理をリターンする段階を具 備する方法。 ９．宛先フォワーディング・エンジン・オブジェクト処理の受取りにより、宛 先フォワーディング・エンジン・オブジェクトにおけるサービス方法を呼出し、 サービス方法は、宛先アドレスを確認し； サービス方法は、宛先の媒体指定アドレスを得るためにアドレス・キャッシュ においてルックアップし；かつ サービス方法は、パケットをリフレームしかつそれを宛先インターフェイスに 転送する段階を更に具備する請求項８に記載の方法。 １０．経路指定装置のサービス、コンポーネント及びインターフェイスを構成 しかつ制御する方法であって、 経路指定装置の各サービス、コンポーネント及びインターフェイスに対して複 数のオブジェクトをインスタンス生成し、該オブジェクトは、各機能的に類似な サービス、コンポーネントまたはインターフェイスが分類階層トゥリーの同じレ ベルに位置決めされるように分類階層によって関係付けられ、かつ 前記階層トゥリーの指定レベルにおける全てのオブジェクトで動作すべく命令 をインプリメントする段階を具備する方法。 １１．各オブジェクトは、分類階層トゥリーのユーザの視覚ナビゲーションを 容易にするためにテキスト名が付与される請求項１０に記載の方法。 １２．タイマ、データ到着、または構成の変化のような、事象が動作の開始を もたらすような非同期経路指定装置において、改良は、 経路指定装置の各サービス、コンポーネント及びインターフェイスに対してオ ブジェクトを供給し；かつ 各オブジェクト内にタイマを含む装置。 １３．所定期間後に処理スレッド時間スライスを終了する手段を供給すること を更に含む請求項１２に記載の装置。 １４．ネットワーク経路指定サービスを供給する方法であって、改良は、 ネットワーク経路指定サービスに対してオブジェクト指向型システムを供給し 、複数のルータ・オブジェクトは、インスタンス生成され、かつ １．経路指定及びシステム機能を含んでいる、オブジェクトの共通プログラム 独立機能； ２．構成及び制御に対する方法及びデータを画定する基本資源オブジェクト分 類によって供給される機能；及び ３．ネットワーク管理に対する方法及びデータを画定する管理オブジェクト分 類によって供給される機能に自動的に組込まれる方法。 １５．ネットワーク経路指定サービスを供給するシステムであって、改良は、 複数のルータ・オブジェクトを含んでいる、ネットワーク経路指定サービスに 対してオブジェクト指向型システムを供給し、各ルータ・オブジェクトは、 １．同じ分類の全オブジェクトによって共有される共通プログラム独立機能； ２．関連ルータ・インターフェイスに固有な構成情報； ３．インスタンス生成及び制御に対するルータ資源オブジェクトを通るアクセ ス可能性； ４．自動パーシステンス； ５．遠隔管理ケイパビリティを有しているシステム。 １６．ネットワーク経路指定サービスを供給するシステムであって、改良は、 複数のルータ・オブジェクトを含んでいる、ネットワーク経路指定サービスに 対するオブジェクト指向型プログラムを供給することを含み、各ルータ・オブジ ェクトは、それ自体を管理するためのデータ及び方法を有しているシステム。 １７．各オブジェクトは、それ自体を制御しかつ構成するためのデータ及び方 法を更に含む請求項１６に記載のシステム。 １８．各オブジェクトは、自動パーシステンスのためのデータ及び方法を更に 含む請求項１６に記載のシステム。 １９．オブジェクト名のマッピングのための処理を更に含む請求項１６に記載 のシステム。 ２０．発生源から宛先までデータを経路指定するネットワークであって、 それぞれが他のルータ及びエンド・システムへの連結のために複数のネットワ ーク・インターフェイスを有しており、エンド・システムにアクセス点を供給し かつ多重経路指定プロトコルを支持している複数の分散型ルータを備え、 各ルータは、フォワーディング・エンジンの一つがネットワーク・インターフ ェイスの異なるものに関連付けられるような複数のフォワーディング・エンジン を含んでおり、 各フォワーディング・エンジンは、その関連インターフェイスに固有でありか つそのインターフェイス及び次のホップ・アドレスのキャッシュに対してのみ構 成情報を含むデータ部分を有し、 各フォワーディング・エンジンは、その関連キャッシュ内でない次のホップ・ アドレスに対して共通フォワーディング表へのアクセスを有し、かつ 各フォワーディング・エンジンは、全てのインターフェイスに共通な方法部分 を有する特徴とするネットワーク。 ２１．各フォワーディング・エンジンのデータ及び方法部分は、関連インター フェイス・オブジェクトにバウンドされたフォワーディング・エンジン・オブジ ェクトを含む請求項２０に記載のネットワーク。 ２２．各フォワーディング・エンジンの方法部分は、ネットワーク層データ・ パケットのイン・バウンド処理手段と、ネットワーク層データ・パケットのアウ ト・バウンド処理手段とを含む請求項２０に記載のネットワーク。 ２３．指定ネットワーク・インターフェイスでネットワーク層パケットを受信 しかつ送信するためにネットワーク層プロトコルを登録する手段を更に含む請求 項２０に記載のネットワーク。 ２４．データ・パケット・ディスパッチャと、該ディスパッチャに各フォワー ディング・エンジンを登録する手段を更に含む請求項２０に記載のネットワーク 。 ２５．前記フォワーディング表に各フォワーディング・エンジンを登録する手 段を更に含む請求項２０に記載のネットワーク。 ２６．各データ部分は、アクセス一覧表を含む請求項２０に記載のネットワー ク。 ２７．各データ部分は、フレーミング情報を含む請求項２０に記載のネットワ ーク。 ２８．キャッシュ・エントリは、フレーミング情報及びＭＡＣ層物理アドレス を 含む請求項２０に記載のネットワーク。 ２９．各ルータは、宛先アドレスを有する内部インターフェイスを有している ホストＣＰＵを含む請求項２０に記載のネットワーク。 ３０．発生源から宛先までデータを経路指定するネットワークであって、 それぞれが他のルータ及びエンド・システムへの接続に対して複数のネットワ ーク・インターフェイスを有しており、エンド・システムにアクセス点を供給し かつ多重経路指定プロトコルを支持している複数の分散型ルータ； 各ルータは、経路指定、構成及びネットワーク管理機能のためのデータ及び方 法を含んでいる複数の自律ルータ・オブジェクトを有し；かつ プロトコル独立基本資源オブジェクトと、基本資源オブジェクトへの自律オブ ジェクトのバインディングにより自律オブジェクトをインスタンス生成する手段 とを含んでいる基本資源オブジェクト分類を備えているネットワーク。 ３１．プロトコル独立基本管理オブジェクトと、基本管理オブジェクトにバイ ンドすることにより管理オブジェクトをインスタンス生成する手段とを含んでい る基本管理オブジェクト分類を更に含んでいる請求項３０に記載のネットワーク 。 ３２．自律ルータ・オブジェクトは、フォワーディング情報ベースを含む請求 項３０に記載のネットワーク。 ３３．自律ルータ・オブジェクトは、事象またはタイマを含む請求項３０に記 載のネットワーク。 ３４．オブジェクトを記憶するための不揮発性メモリを更に含む請求項３０に 記載のネットワーク。 ３５．管理オブジェクトの遠隔管理ケイパビリティのためのネットワーク管理 システムを更に含む請求項３１に記載のネットワーク。 ３６．各ルータは、ネットワーク層におけるデータ・パケットをフォワードし かつネットワーク・トポロジー情報を交換するためのソフトウェア及びハードウ ェアを含む請求項３０に記載のネットワーク。 ３７．自律ルータ・オブジェクトは、経路指定アプリケーション、ホスト通信 、フォワーディング、及びネットワーク・インターフェイスを含む請求項３０に 記載のネットワーク。 ３８．各個別プロトコルに対する経路指定アプリケーション・オブジェクトの 多重インスタンス生成が存在する請求項３７に記載のネットワーク。 ３９．各個別プロトコルに対するフォワーディング・オブジェクトの多重イン スタンス生成が存在する請求項３７に記載のネットワーク。 ４０．自律ルータ・オブジェクトは、各個別プロトコルに対してインスタンス 生成される請求項３０に記載のネットワーク。 ４１．基本資源オブジェクトは、ルータ・サービス、ルータ・コンポーネント 、ルータ・インターフェイス、ルータ構成、及び事象の少なくとも一つを含む請 求項３０に記載のネットワーク。 ４２．基本資源オブジェクトは、経路指定アプリケーションの共通制御をイネ ーブルする共通管理情報ベース（ＭＩＢ）構造及び内容を有する請求項３０に記 載のネットワーク。 ４３．自律ルータ・オブジェクトは、ネットワーク・トポロジー情報を交換す る手段と、次のホップ・パスを決定する手段とを含む請求項３０に記載のネット ワーク。 ４４．フレーミング及びプロトコル識別子基準にマッチしているネットワーク 層データ・パケットを受信することをネットワーク層プロトコルに登録させる手 段を含んでいる請求項３０に記載のネットワーク。 ４５．ネットワーク層アドレスをフレーミング・フォーマットにマップする手 段と、物理層アドレスをネットワーク層アドレスにマップする手段とを含んでい る請求項３０に記載のネットワーク。 ４６．基本資源オブジェクトは、アプリケーション・スレッドに多重事象を同 時に給仕させるルータ事象基本分類を含む請求項３０に記載のネットワーク。 ４７．基本資源オブジェクトは、キャッシュ基本分類を含む請求項３０に記載 のネットワーク。 ４８．前記基本資源オブジェクトは、アクセス制御基本分類を含む請求項３０ に記載のネットワーク。