JPH09500750A - 管理パッケージを含むネットワークとの通信システム - Google Patents

Abstract

(57)【要約】 異なるモデルに属する通信モジュールを含むコード（ＣＣ）の管理パッケージ（Ｃ４、Ｃ３、Ｃ２）を含む複数の相互接続モデル（ＯＳＩ、ＩＰＳ）に属する通信コード（ＣＣ）を使用するネットワーク（ＲＥ、．．．）との通信システム（ＳＣＩ１）であって、− システムの初期化時、種々のコード層間の重なりを決定するコンフィギュレータ（ＣＯＮＦＤ）と、− 各層の内部で、あらゆる管理情報への接続を可能にする管理モジュール（ＩＭＤ）と、− コンフィギュレータ（ＣＯＮＦＤ）と種々の管理エンティティの間、ならびにコンフィギュレータ（ＣＯＮＦＤ）と管理モジュール（ＩＭＤ）の間に配置された第１管理インタフェース（ＬＭＡＩ１、ＬＭＩ１）と、− 管理モジュール（ＩＭＤ）と管理エンティティＬＭＥ１１、ＬＭＥ１２等）間に配置された第２管理インタフェース（ＬＭＡＩ２、ＬＭＩ２）とを含むことを特徴とする通信システム。通信プロセッサに応用可能。

Description

【発明の詳細な説明】 管理パッケージを含むネットワークとの通信システム 本発明は、複数のオープンシステム相互接続モデルに属する通信コードを使用 し、種々のコード層の管理パッケージを含むネットワークとの通信システムに関 する。本発明は、あらゆる種類のネットワーク、特にＸ３Ｔ９−５という参照番 号でＡＮＳＩで標準化され、またＩ．Ｓ．Ｏ．（国際標準化機構）で標準化され たＦＤＤＩ型に適用可能である。 今日のネットワークは、標準化された層という形のアーキテクチャの定義にお いて、類似した状態を保つ複数の参照モデルに従って動作する。これらモデルの うち最も知られているのが、ＯＳＩ（オープンシステム相互接続の意味の英語の 略語）、ＩＳＯ／ＤＳＡ、ＩＰＳ（インターネットプロトコル列）モデルである 。ＩＰＳモデルは、特にＴＣＰ、ＵＤＰ、ＩＰ、ＩＣＭＰのサブモデルを同じ名 前で含むことに留意されたい。したがってＯＳＩモデルには、活動の異なる七つ の階層があり、最下位層（階層１）は信号の物理的伝送に対応し、上位層（階層 ７）はアプリケーションプログラム（より簡単にはアプリケーションと呼ばれる ）及び想定するネットワークのユーザによ って実行される機能に対応する。 現在は実際には、ネットワークとの通信システムは、ホストシステムとも呼ば れるコンピュータと、通信プロセッサとの結合によって構成される。通信システ ムの目的は、ネットワークの他の端末との通信の管理の一部を実施することであ る。このため通信プロセッサは、各参照モデルの下位層の管理を担当する。 このような通信システムは、例えば、「ネットワークとの通信システム」とい う名称で、出願人である会社が１９９３年３月１２日に出願したフランス特許出 願第９３０２９０２号、あるいは「ネットワークとの通信システム、および該シ ステムに所属するトランスポートサプライヤへの接続プロトコル」という名称で 、出願人である会社が１９９３年７月２１日に出願したフランス特許出願第９３ ０８９６８号に記載されている。これら二つの特許出願は、特にこのような通信 システムのソフトウェア構造についてより詳細に説明している。また。同一の出 願人が１９９２年１２月２２日に出願した、「コンピュータバスとネットワーク の間のデータ伝送システム」という名称のフランス特許出願第９２１５５２１号 には、このようなシステム のハードウェア構造についての記載がある。 少なくとも一つの通信プロセッサを含む、極めて簡略化したこのような通信シ ステムの一般的構造（このような通信システムは、複数の異種ネットワークと通 信が可能な複数の通信プロセッサを含むことができる）を、第１ａ図および第１ ｂ図に示す。 ここではＳＣＩと呼ぶこのような通信システムは、ホストシステムＨＯＳＴに より、参照モデルＯＳＩ、ＩＳＯ／ＤＳＡ、ＩＰＳのいずれか一つの上位階層Ｃ Ｈを利用する。（ＩＰＳは、接続モードネットワークサービスに準拠することも 非接続モードネットワークサービスに準拠することも可能である。英語のConnec ted Oriented Network Serviceの略語であるＣＯＮＳで示す接続モードおよび英 語のConnection Less Network Serviceの略語であるＣＮＬＳで示す非接続モー ドは、前者はＩＳＯ規格の９８７８および８２０８に準拠し、後者は同規格の８ ４７３および９５４２に準拠する。これら規格は、組み合せ経路指定機構および プロトコルを定義する。） 第１ａ図および第１ｂ図に、ＯＳＩモデルの三つの上位層Ｃ５〜Ｃ７を例示し た。ＣＨ層は、これらのモデルのＣ４〜 Ｃ２等、下位層ＣＢと通信する。これら層は、単数または複数の通信プロセッサ が利用することができる。第２図では、ＳＣＩが、種々の種類であることが可能 な通信プロセッサＰＣｉ、ＰＣｊに結合されたホストＨＯＳＴから成ると仮定し た。これらプロセッサの共通点は下位層ＣＢを利用することである。プロセッサ ＰＣｉはネットワークＲＥｉに接続されるが、ＰＣｊはネットワークＲＥｊに接 続され、これら二つのネットワークは異種であってもよい。さらに、ＰＣｉもＰ Ｃｊも、接続モードネットワークサービスＲＣＯＮＳ（ＩＳＯ／ＤＳＡまたはＴ ＣＰモデル）または非接続モードネットワークサービスＲＣＬＮＳ（ＵＤＰモデ ル）に準拠するトランスポート層を利用することができる。 第１ｂ図において、ＨＯＳＴの層ＣＨは、複数のメッセージプロセッサが利用 する下位層ＣＢと通信するが、第１ｂ図では、この転送が、例えば、ここではＰ ＳＢ（ＩＥＥＥ規格１２９６号）と呼ぶＭＵＬＴＩＢＵＳII型のバスにより行わ れる。 あらゆる通信システム、より正確にはあらゆる通信プロセッサにおいて、ユー ザは、通信コードの各階層が存在しさらに通信層の内部にある各オブジェクトが 存在する状態を常時把握す る必要がある。 ある通信コードの一つの層に所属するあるオブジェクトは、同一の目的のため に働く機能パッケージから成る。すなわち、一つの接続を規定するのに用いられ る機能パッケージがオブジェクトである。物理的には、一つのオブジェクトは、 メモリに存在するデータテーブル、またはデータテーブルセットから成る。 属性またはパラメータにより、オブジェクトの特性が定義される。したがって オブジェクトは、一組の属性によって定義することができる。各属性が一つの値 を有する属性のセットは、オブジェクトインスタンスとも呼ばれる。通信コード のあるオブジェクトまたは層の状態は、どの瞬間にオブジェクトインスタンスを 想定するかによって変化する。オブジェクトインスタンスは、別の層との通信状 態、または構成状態または初期化状態にある。各瞬間において、各オブジェクト または各通信層がどこに位置するかを知るため、あらゆる通信システムは通常、 各層または各オブジェクトの現状を知らしめる管理パッケージを含む。 第１ａ図および第１ｂ図に図示するような通信システム用の このような管理パッケージを定義することがまさに本発明の目的である。 本発明によれば、複数のアプリケーションに組み合わされた少なくとも一つの オペレーティングシステムによってオペレーションが組織され、アプリケーショ ンに必要なデータを、コードの種々の層の管理パッケージを含むネットワークに 送信しまたはそのネットワークから受信することを目的とする、複数のオープン システム相互接続モデルに属する通信コードを使用するネットワークとの通信シ ステムは、該パッケージが、 − システムの初期化時、種々の層間のＳＴＲＥＡＭＳ型リンクによりこれら層 のパイルを決定するコンフィギュレータと、 − コードの各層の内部で、管理レベルのあらゆる情報への接続を可能にする管 理モジュールと、 − 管理モジュールと層の内部に位置する層の管理エンティティの間の第１管理 インタフェースと、 − コンフィギュレータと種々のエンティティおよび管理モジュールの間の第２ 管理インタフェースと を含むことを特徴とする。 本発明のその他の特徴および利点は、添付の図面を参照しな がら、非限定的な例として示した以下の説明を読むことにより、理解されよう。 第１図は、第１ａ図および第１ｂ図から成り、本発明が応用される通信システ ムの種々の主要な構成要素を示す図である。 第２図は、本発明によるシステムに固有の管理パッケージを含む通信プロセッ サ内に含まれるソフトウェアモジュールパッケージを示す図である。 第３図は、本発明による任意の通信システムの構造の概略図である。 第４図は、本発明による通信システムに属する管理パッケージに固有なメッセ ージの構造を示す図である。 第５図は、本発明による通信システムの管理パッケージに属する各管理モジュ ールの内部構造を示す図である。 第２図を参照する。 同図は、例えば、前記３件の特許出願のいずれか一つに既に記載されている通 信プロセッサＮＣＣ１、ＮＣＣ２、ＮＣＣ３のうちの一つに属する通信ソフトウ ェアパッケージＥＬＣを示す図である。このソフトウェアパッケージＥＬＣは、 例えばＳＣＩというように第１図と同じ名称で呼ばれる本発明による 通信システムの一部を成す。 パッケージＥＬＣは、以下のものを含む。 − 例えば、ＯＳＩモデル、ＩＳＯ／ＤＳＡモデル、およびＩＰＳモデル等、異 なる参照モデルに固有な通信層の三つのパイルを含む通信コードＣＣ。これら種 々のモジュールは各々、ＭＯＳＩ、ＭＤＩＷＳ、ＭＩＰＳと呼ばれる。より詳細 にはこれらモジュールは層Ｃ４およびＣ３に関する。通信コードはさらに、三つ のモジュールに共通な、ＬＬＣ１とも呼ばれる層Ｃ２を含む。 − ホストシステムＨＯＳＴに属する通信サーバＮＣＣＤと、ここでは三つのモ ジュールＭＯＳＩ、ＭＤＩＷＳ、ＭＩＰＳによって示す下位層ＣＢとの間のイン タフェースＨＩ。ＨＩおよびＮＣＣＤの役割については、前記出願第９３０２９ ０２号および第９３０８９６８号により詳細な記述がある。 − 本発明による通信システムＳＣＩに属する通信プロセッサのオペレーティン グシステムＧＰＯＳにより、インタフェースＨＩと層Ｃ２の間の通信を可能にす る、前記３件の特許出願のいずれか一つに既に記載のインタフェースＨＩＮ。 − 既にその役割を説明したコンフィギュレーションモ ジュールＣＯＮＦＤ。 − 同じく役割を既に説明した管理モジュールＩＭＤ。 − コンフィギュレータＣＯＮＦＤと、各通信モジュールＭＯＳＩ、ＭＤＩＷＳ 、ＭＩＰＳの間に配置された第１管理インタフェースＬＭＡＩ１。 − 管理モジュールＩＭＤと三つの通信モジュールＭＯＳＩ、ＭＤＩＷＳ、ＭＩ ＰＳの間のインタフェースと、管理モジュールＩＭＤとインタフェースＨＩの間 のインタフェースを各々行うＬＭＡＩ２１およびＬＭＡＩ２２等、実際には同一 の二つの管理インタフェースから成る第２管理インタフェースＬＭＡＩ２。 コンフィギュレータＣＯＮＦＤと第１管理インタフェースＬＭＡＩ１の間のリ ンクならびにこの第１インタフェースと三つのモジュールＭＯＳＩ、ＭＤＩＷＳ 、ＭＩＰＳの間のリンクは、ＳＴＲＥＡＭＳ型、より詳細にはＡＤＭ ＳＴＲＥ ＡＭＳと呼ばれるリンクにより行われる。管理モジュールＩＭＤと二つのインタ フェースＬＭＡＩ２１、ＬＭＡＩ２２の間のリンク、ならびにこれら二つインタ フェースと三つの通信モジュールＭＯＳＩ、ＭＤＩＷＳおよびＭＩＰＳの間およ びこれら二つイ ンタフェースとインタフェースＨＩとの間のリンクは、ＳＴＲＥＡＭＳ型、より 詳細には管理型リンクであるＩＭ ＳＴＲＥＡＭＳと呼ばれるリンクにより行わ れる。 さらに、通信層Ｃ２、Ｃ３、Ｃ４は、隣接する二つの層間の対話を可能にする 原始機能を介して、２対２で通信する。従って、層Ｃ２およびＣ３はＳＴＲＥＡ Ｍ ＳＴ２型機能パッケージを介して両者間で通信を行うが、層Ｃ３およびＣ４ はＳＴ３機能パッケージを介して両者間で通信を行う。さらに、Ｃ４はＳＨ機能 パッケージを介してインタフェースＨＩと通信を行う。これらの機能パッケージ はまたＳＴＲＥＡＭ型機能でもある。ＳＴ２、ＳＴ３、ＳＨ、ＡＤＭ ＳＴＲＥ ＡＭおよびＩＭ ＳＴＲＥＡＭＳ機能セットは、 − Unix System V，release 4-STREAM Programmer guide ATT issue 1 − Unix System V，release 3.2-STREAM Programmer guide ATT（ISBN：0-13-9 44810-1）：1989 において定義されている。 さらに、ＯＳＩ、ＩＳＯ／ＤＳＡモデル内では、各通信層が、通信コードＣＣ に属する各通信層の管理業務を組織することを 役割とする特殊管理エンティティを含む。従って、モジュールＭＯＳＩは、各々 層Ｃ４およびＣ３に関する管理エンティティＬＭＥ１１およびＬＭＥ１２を含み 、モジュールＭＤＩＷＳは、層Ｃ４およびＣ３に関する管理エンティティＬＭＥ ２１およびＬＭＥ２２を含む。モジュールＭＩＰＳは、Ｃ４およびＣ３に関する 唯一つの管理インタフェースＩＡＭを含む（後述の説明を参照のこと）。ＯＳＩ およびＩＰＳに共通な層Ｃ２は、管理エンティティＬＭＥ４を有する。 第３図は、ホストシステムＨＯＳＴと通信プロセッサＮＣＣ１から成る二つの エンティティが、ただ一つに一体化された本発明による通信システムＳＣＩ₁の 概略構造を示す図である。同図には、機能が図２のコンフィギュレーションモジ ュールと極めて類似するコンフィギュレーションモジュールＣＯＮＦＤと、機能 が図２の管理モジュールと全く同一の管理モジュールＩＭＤと、機能が図２の管 理インタフェースＬＭＡＩ１と同一の第１管理インタフェースＬＭＩ１と、機能 が図２の管理インタフェースＬＭＡＩ２と全く同一の第２管理インタフェースＬ ＭＩ２が図示されている。 従って、第１管理インタフェースＬＭＩ１により、ＡＤＭ ＳＴＲＥＡＭ型の制御ＳＴＲＥＡＭを介して、コンフィギュレーションモジュー ルＣＯＮＦＤと層Ｃ６〜Ｃ２の各管理エンティティの間のリンクが行われる。ま た第１インタフェースにより、ＳＴＲＥＡＭ、ＡＤＭ ＳＴＲＥＡＭを介して、 管理モジュールＩＭＤとのリンクも行われる。 第２管理インタフェースＬＭＩ２により、ＩＭ ＳＴＲＥＡＭ型のリンクを介 して、管理モジュールＩＭＤと層Ｃ７（プレゼンテーション層）〜Ｃ２の各管理 エンティティの間のリンクが行われる。層Ｃ７〜Ｃ２の管理エンティティをそれ ぞれＭＥ７〜ＭＥ２で示す。第３図に、接続モード（コネクションオリエンティ ド）および非接続モード（コネクションレス）でオペレーションするネットワー クに関する層Ｃ３の管理エンティティである管理エンティティＭＥ３１およびＭ Ｅ３２を示す。ＭＥ４とＭＥ３１およびＭＥ３２の間のリンクは、既知のＳＴＲ ＥＡＭ型リンクによって行われる。 勿論、第２図の通信システムＳＣＩと第３図の通信システムＳＣＩ１の作動形 態は同一である。 第２図、第３図の両図においては、各層管理エンティティＬＭＥ１１〜ＬＭＥ ２１、ＬＭＥ４およびＩＡＭ、ならびに 種々のエンティティＭＥ７〜ＭＥ２によって、複数の属性によって各々が記述さ れるオブジェクトのパッケージが管理される。これらオブジェクトパッケージは 、ＯＳＩモデル、ＩＳＯ／ＤＳＡモデルまたはＩＰＳモデルに関して、各参照モ デルを定義する種々の規格に適合している。また、通信プロセッサまたは通信シ ステムＳＣＩ１内に、ＳＮＭＰ、ＣＮＭＡまたはＯＳＩ／ＮＭＦＯＲＵＭ等の標 準管理プロトコルを実行することも可能である。 モジュールＩＭＤは全体としては、通信プロセッサまたは通信システムＳＣＩ １のオペレーティングシステムとリンクして作動し、同じくこれら層の内部にあ るエンティティおよび、メンテナンス、コンフィギュレーションおよび管理の各 ツールへの、またはこれらエンティティおよびツールからのメッセージの経路指 定を担当する。上記の説明でわかるように、管理エンティティとモジュールＩＭ Ｄの間のやりとりは全て、ＳＴＲＥＡＭ機能を用いた通信に基く。 第２図のＬＭＡＩ１またはＬＭＡＩ２、第３図のＬＭＩ１およびＬＭＩ２等、 第１および第２管理インタフェースに関しては、これらインタフェースにより、 モジュールＩＭＤ、コンフ ィギュレータＣＯＮＦＤ、および通信コードの内部にある種々の層管理エンティ ティの間の対話が定義される。 次に、図４はメッセージの方向を定義するプリミティブである原始管理機能を トランスポートするために使用されるＳＴＲＥＡＭ規格に適合したメッセージの 全体形状を示す図である。 メッセージは、Ｍ−ＰＲＯＴＯで示す第１ブロックを含むが、同ブロックの後 ろにはＭ−ＤＡＴＡと呼ばれるブロックが続く場合と続かない場合とがある。各 原始機能は、Ｃ構造と呼ばれる特殊なデータ構造によって形成され、同構造の後 ろには、やりとりされた管理情報を含むデータ群（英語ではバッファ）が続く場 合と続かない場合とがある。各データ構造Ｃは、エンティティとモジュールＩＭ Ｄの間の情報の全体的なやりとりを定義する。このデータ構造Ｃは、ブロックＭ −ＰＲＯＴＯの内部に含まれる。情報の方向を定義するプリミティブに組み合わ された情報は、ブロックＭ−ＤＡＴＡ内にトランスポートされる。Ｍ−ＰＲＯＴ ＯおよびＭ−ＤＡＴＡは、モジュールＩＭＤの規定に適合するようにするためＡ ＳＮ．１型フォーマットでコード化される。ＡＳＮ．１コード化される情報の種 類としては、 以下のものがある。 − ステータスリスト：このリストは、以前、管理を希望した種々のエンティテ ィまたはオブジェクトの状態を示す。 − 管理しようとする種々のエンティティまたはオブジェクトのリストを含むＰ ａｒａｍ−ｌｉｓｔと呼ばれるリスト。 − 値を求めようとするオブジェクトの識別子のリストを含むＩｄｅｎｔ−ｌｉ ｓｔと呼ばれるリスト。 次に、種々のオブジェクトの階層を示す第５図を参照する。例えば、ＭＯＳＩ 、ＭＤＩＷＳ、ＭＩＰＳ等のモジュールのオブジェクトであるモジュールオブジ ェクトは、層のオブジェクト、すなわち層４のオブジェクトまたは層３のオブジ ェクトを含むが、後者は、接続オブジェクトか、選択オブジェクトか、またはＩ ＶＭＯと呼ばれる初期値管理オブジェクトかであって、層の各オブジェクトの初 期値を定義するオブジェクトである複数のオブジェクトを含む。 管理モジュールまたはエンティティは、ＳＵＢＳＹＳＴＥＭ−ｉｄと呼ばれる 整数で識別される。通信プロセッサのオペレーティングシステムの内部、あるい はより一般的にはＳＣＩ１等の通信システムのオペレーティングシステムの内部 に含まれ るエンティティーの場合、モジュールの識別子は、初期化時、コンフィギュレー タＣＯＮＦＥＤによって与えられる。モジュールＩＭＤは、正しいモジュールま たは層の内部にあるエンティティにメッセージを送信するためにこの識別子を使 用する。 被管理オブジェクトは、以下の三つのフィールドによって識別される。 − ＳＵＢＳＹＳＴＥＭ−ｉｄ：このフィールドは、この被管理オブジェクトを 含むモジュールの識別子を定義する。 − ＯＢＪＥＣＴ−ｔｙｐｅ：この識別子は、オブジェクトの管理タイプを定義 する。 − ＯＢＪＥＣＴ−ｎａｍｅ：これは、ＯＳＩモデルの場合、オブジェクトを含 むモジュールによって与えられる内部名を与える識別子であり、ＩＰＳモデルの 場合、要求されたオブジェクトのインスタンスを探すために使われる個別パラメ ータである、ブロックＭ−ＤＡＴＡ内で伝播される（０〜ｎの）第１パラメータ を認識することを可能にする（モジュールに名称を与えることができない場合） 整数（０〜ｎ）である。 モジュールを実施する場合、モジュール内に含まれる同一タイプの被管理オブ ジェクトは異なる名称を持つことが前提とな る。 あらゆる管理インタフェース（第２図および第３図のＬＭＡＩ、ＬＭＩ）から 発信されるプリミティブに共通なパラメータは、以下の通りである。 ＰＲＩＭ−ｎａｍｅおよびＰＲＩＭ−ｔｙｐｅという名称のパラメータは、管 理インタフェースの要求であるか応答であるかを識別する。 ＩＭ−ｕｓｅｒｉｄパラメータはモジュールＩＭＤによって与えられ、このパ ラメータによりＩＭＤモジュールは、要求を出したエンティティへの返答の正し い経路指定を行うことが可能となる。このパラメータが、要求の場合も応答の場 合も、同じ値を有することは明らかである。 管理インタフェースに関するプリミティブ全てに共通なパラメータの中には、 前記に定めたＳＵＢＳＹＳＴＥＭ−ｉｄ、ＯＢＪＥＣＴ−ｔｙｐｅおよびＯＢＪ ＥＣＴ−ｎａｍｅもある。 また、同じタイプではあるが同一の管理要求をサポートしていないオブジェク トセットを区別するのに使われる、ＯＢＪＥＣＴ−ｓｕｂｔｙｐｅと呼ばれる別 のパラメータもある。 選択オブジェクト、接続オブジェクトおよびＩＶＭＯ型オブジェクトの場合、 これらオジェクトのすぐ上位のオブジェクトが、これらオジェクトを含む層オブ ジェクトを示す。この上位オブジェクトは、以下の三つのフィールドによって識 別される。 − ＳＵＢＳＹＳＴＥＭ−ｕｐｉｄは、エンティティすなわち上位オブジェクト を含む層の識別子である。 − ＯＢＪＥＣＴ−ｕｐｔｙｐｅは、上位オブジェクトの管理タイプである。 − ＯＢＪＥＣＴ−ｕｐｎａｍｅは、上位オブジェクトの名称である。 モジュールＣＯＮＦＤ、ＩＭＤおよびＬＭＡＩ１、ＬＭＡＩ２、ＬＭＩ１、Ｌ ＭＩ２が使用するメッセージは、管理メッセージとコンフィギュレーションメッ セージの２種類がある。 最初に、種々の管理メッセージを想定する。第１付録に管理メッセージのリス トを、第２付録にコンフィギュレーションメッセージのリストを、各々示す。付 録の双方とも、最初の段にメッセージ名を示し、以降の段に、ＯＳＩ型、または ＩＰＳ型、またはＦＤＤＩ型等、メッセージが属する参照モデルを示した。さら に右側二つの段には、メッセージの発信元の名称およびメ ッセージの送信先の名称を示した。 １から２１までの番号を付した（１型から２１型の）管理メッセージは以下の 通りである。 １．ＡＤＭ−ＢＩＮＤ−ＬＡＹＥＲ−ＲＥＱメッセージ： このメッセージは、管理エンティティとモジュールＩＭＤの間の対話を初期化 するため、モジュールＩＭＤが管理エンティティに送る要求メッセージである。 これは、当該モジュールがエンティティに送る最初のメッセージである。エンテ ィティは、当該エンティティが管理するオブジェクトの種類を示すＡＤＭ−ＢＩ ＮＤ−ＯＢＪ−ＩＮＤと呼ばれる一つ（あるいは複数の）メッセージを送って応 答する。エンティティは、ＩＭＤに、自分が管理するオブジェクトパッケージに 対応するＡＤＭ−ＢＩＮＤ−ＯＢＪ−ＩＮＤメッセージパッケージを送り終える と、ＩＭＤに応答の終了を知らせるため、ＡＤＭ−ＯＫ−ＡＣＫメッセージを送 る。この最新の肯定応答が受信されるまでは、モジュールＩＭＤは管理エンティ ティに、別のメッセージを一切送ることができない。エンティティは、要求メッ セージを受信すると、ＳＴＲＥＡＭ型のリンクを管理情報に割り当てる。 ２．ＡＤＭ−ＢＩＮＤ−ＯＢＪ−ＩＮＤメッセージ： このメッセージは、モジュールＩＭＤが問い合わせる管理エンティティが、前 記メッセージに対する応答として返すメッセージである。このメッセージは、Ｉ Ｍ−ＳＴＲＥＡＭＳ型のＳＴＲＥＡＭ機能に送られる。管理エンティティはこの 種のメッセージを、被管理オブジェクト１種類につき一つだけ送る。 ３．ＡＤＭ−ＯＫ−ＡＣＫメッセージ： このメッセージは、モジュールＩＭＤと管理エンティティの間の初期化対話を 終了させるものである。このメッセージは、１型のメッセージに対する応答とし て単数または複数の２型のメッセージが送られた後に、ＩＭ−Ｓｔｒｅａｍｓに 送られる。 このメッセージはまた、管理エンティティに対し別の応答が一切定義されてい ない時に、管理エンティティが、一つ前に送られたメッセージの受信に成功した ことをモジュールＩＭＤに知らせるためにも使用される。 ４．ＡＤＭ−ＥＲＲＯＲ−ＡＣＫメッセージ： このメッセージは、管理エンティティが、一つ前に送られたメッセージの受信 に成功しなかったことと、システムエラーのためメッセージが処理できないこと をＩＭＤに知らせる。不良 の理由もこのメッセージが知らせる。また、このメッセージが受信されたことに より、この否定応答を発生したメッセージに対し何等のアクションもとられなか ったことが、ＩＭＤに示される。 ５．ＡＤＭ−ＬＩＳＴ−ＲＥＱメッセージ： このメッセージは、ＯＢＪＥＣＴ−ｔｙｐｅフィールド内で指定されるモジュ ールによって送られる。 接続、選択およびＩＶＭＯオブジェクトの場合、種類がＯＢＪＥＣＴ−ｔｙｐ ｅフィールド内で指定され、ＯＢＪＥＣＴ−ｕｐｔｙｐｅ、ＯＢＪＥＣＴ−ｕｐ ｎａｍｅ、ＳＵＢＳＹＳＴＥＭフィールドによって識別される層オブジェクトに 組み合わされるオブジェクトの名称を与える。 ６．ＡＤＭ−ＬＩＳＴ−ＡＣＫメッセージ： このメッセージは、５型のメッセージに対する応答として、ＰＩＬＥ（層のパ イル）エンティティによってモジュールＩＭＤに送られる。このメッセージは、 あるオブジェクト種に関するオブジェクトインスタンスの管理名のリストを与え る。 ７．ＡＤＭ−ＧＥＴ−ＲＥＱメッセージ： このメッセージは、被管理エンティティにオブジェクトイン スタンスの属性値を返すよう要求するためにＩＭＤが送るメッセージである。属 性リストが提供された場合には、属性値リストは、モジュールＩＭＤに返さなけ ればならない。リストが提供されなかった場合には、属性値は全て返さなければ ならない。任意の属性の読み取りが不可能な場合には、管理エンティティが与え る応答内にエラーが示される。 ８．ＡＤＭ−ＧＥＴ−ＡＣＫメッセージ： このメッセージは、７型のメッセージに対する応答として、管理エンティティ によってモジュールＩＭＤに送られる。このメッセージは、要求オブジェクトイ ンスタンス属性値を返す。少なくとも一つの属性の読み取りが不可能な場合には エラーが示される。 ９．ＡＤＭ−ＧＥＴＮＥＸＴ−ＲＥＱメッセージ： このメッセージにより、管理エンティティは、あるオブジェクトのインスタン スの名称を知らなくともこのようなインスタンス全てについての属性を取得する ことができる。従って、オブジェクトインスタンス名を取得するのに５型のメッ セージを送る必要はない。オブジェクト名リストは、エンティティによって任意 の順番で管理されるが、その順番は、層の内部のエン ティティのインプリメンテーションに依存する。 １０．ＡＤＭ−ＧＥＴＮＥＸＴ−ＡＣＫメッセージ： このメッセージは、９型のメッセージに対する応答として、管理エンティティ によって送られる。このメッセージは、モジュールＩＭＤに要求オブジェクト属 性値を返す。これら属性の読み取りが不可能な場合にはエラーが示される。 １１．ＡＤＭ−ＳＥＴ−ＲＥＱメッセージ： このメッセージは、ＩＭＤが、ＩＭ−ＳＴＲＥＡＭ上の管理エンティティに送 るメッセージである。このメッセージにより、オブジェクトインスタンスの属性 に新しい値を与えることができる。このオペレーションは、書き込みが可能であ ると定義された属性に対し適用される。Ｍ−ＤＡＴＡ部分に与えられる属性のリ ストは、属性の識別子および、置き換えが必要な属性値に与える結合値を含む。 １２．ＡＤＭ−ＳＥＴ−ＡＣＫメッセージ： このメッセージは、１１型のメッセージに対する応答として、管理エンティテ ィによって送られる。このメッセージは、１１型メッセージによって要求された 属性値変更オペレーションが成功したかどうかを示す。 １３．ＡＤＭ−ＴＥＳＴ−ＲＥＱメッセージ： このメッセージは、ＩＭＤが管理エンティティに送るメッセージである。この メッセージにより、ある一つのオブジェクトインスタンスの複数の属性の値を同 時に変更して新しい値にすることができるかどうかを検証することができる。こ のメッセージでは属性値は変更されない。 １４．ＡＤＭ−ＴＥＳＴ−ＡＣＫメッセージ： このメッセージは、１３型のメッセージに対する応答として、管理エンティテ ィによって送られる肯定応答メッセージである。 １５．ＡＤＭ−ＡＣＴＩＯＮ−ＲＥＱメッセージ： このメッセージは、ＩＭＤが管理エンティティに送るメッセージである。この メッセージの機能は、ＰＲＩＭ−ｔｙｐｅフィールド内に記述されるアクション の種類に依存する。 １６．ＡＤＭ−ＡＣＴＩＯＮ−ＡＣＫメッセージ： このメッセージは、１５型のメッセージに対する応答として、管理エンティテ ィによって送られ、同要求が成功または失敗したことを示す。 １７．ＡＤＭ−ＡＤＤ−ＲＥＱメッセージ： このメッセージは、管理エンティティに新規オブジェクトイ ンスタンスを作成するよう要求するものである。このメッセージは、あらゆる種 類のオブジェクトに対し可能というわけではない。あるオブジェクトを作成する 場合、同オブジェクトについてある数の属性が必須であり、かつそれらを要求内 に与えなければならない。作成しなければならないオブジェクトの名称は、その 後、同名称を管理するモジュールによって与えられる。この名称は、このメッセ ージによって構成される要求に対する応答の中に与えられる。 １８．ＡＤＭ−ＡＤＤ−ＡＣＫメッセージ： このメッセージは、１７型のメッセージに対する応答として、管理エンティテ ィによって送られ、要求の成功時には肯定応答を行う。 １９．ＡＤＭ−ＲＥＭＯＶＥ−ＲＥＱメッセージ： このメッセージは、管理エンティティにオブジェクトインスタンスを削除する よう要求するものである。 ２０．ＡＤＭ−ＲＥＭＯＶＥ−ＡＣＫメッセージ： このメッセージは、１９型のメッセージに対応する要求の成功または失敗を肯 定応答するため、１９型のメッセージに対する応答として、管理エンティティに よって送られる。 ２１．ＡＤＭ−ＥＶＥＮＴ−ＩＮＤメッセージ： このメッセージは、層エンティティ内でイベントが実行されることをモジュー ルＩＭＤに示す。管理モジュールに関しては、該層エンティティ内でイベントが 発生したとの情報を受信する場合には、肯定応答はない。 付録１においてわかるように、１〜２１型のメッセージパッケージはＯＳＩま たはＩＳＯ／ＤＳＡ参照モデル用に使用される。これらのメッセージのパッケー ジは、メッセージ５および６を除き、ＩＰＳモデルにも使用される。 ＦＤＤＩ型ネットワークの場合も、４型および７型から２１型のメッセージを 使用する。 ＩＰＳ参照モデルのオブジェクトの識別に関しては、同識別は、ＯＳＩ参照モ デルの識別と比較して幾つかの異なる側面を有する。 ＯＢＪＥＣＴ−ｔｙｐｅフィールドは、パラメータから成るオブジェクトクラ スである。ＩＰＳオブジェクトは、ＯＢＪＥＣＴ−ｔｙｐｅフィールドおよび上 記クラスのインスタンスによって定義される。それが単純オブジェクト（モノイ ンスタンス）であれば、識別は、単に（ＯＢＪＥＣＴ− ｔｙｐｅ）フィールドによって与えられる。インスタンスは、選択パラメータの 値によって定義される。識別と値を与える選択パラメータは、要求のＭ−ＤＡＴ Ａメッセージブロックに伝送される。 ＯＢＪＥＣＴ−ｎａｍｅフィールドは、選択に使用されるパラメータ数を有す る。従って、必要であれば、Ｍ−ＤＡＴＡメッセージブロックの最初のインスタ ンスが選択パラメータとなる。 Ｍ−ＤＡＴＡメッセージブロックはＡＳＮ．１でコード化される。 次に、以後の文中に示しまた付録２に示す、２２から３２までの番号を付した （２２型から３２型の）種々のコンフィギュレーションメッセージを想定する。 付録２の形態は付録１の形態と全く同一である。 これら種々のコンフィギュレーションメッセージは以下の通りである。 ２２．ＡＤＭ−ＳＵＢＳＹＳＴＥＭ−ＩＤメッセージ： このメッセージは、コンフィギュレータＣＯＮＦＤにより、第２図の通信プロ セッサの各モジュールの開放後直ちに送られ るか、第３図のシステムＳＣＩ１の各モジュールにより送られ、ＡＤＭ ＳＴＲ ＥＡＭまたはＩＭ ＳＴＲＥＡＭにより伝播される。管理されることを希望する エンティティはどれでも、このメッセージを考慮に入れることができるが、同メ ッセージを理解できなければならない。 ２３．ＡＤＭ−ＳＴＲＥＡＭ−ＢＩＮＤメッセージ： このメッセージは、ＣＯＮＦＤにより、あるモジュールの制御ストリームの開 放後直ちに送られる。次にこのストリームは、該モジュールによりコンフィギュ レータＣＯＮＦＤに割り当てられる。 ２４．ＡＤＭ−ＳＴＲＥＡＭ−ＡＣＫメッセージ： このメッセージは、２３型メッセージの要求が受理された場合、モジュールか らコンフィギュレータに返される。 ２５．ＡＤＭ−ＳＴＲＥＡＭ−ＮＡＣＫメッセージ： このメッセージは、２３型メッセージによって示される要求が拒否された場合 、モジュールからコンフィギュレータＣＯＮＦＤに返される。 ２６．ＡＤＭ−ＳＴＲＥＡＭ−ＯＰＥＮメッセージ： このメッセージは、別のモジュールにストリーム型の新規リ ンクを要求するため、モジュールからＡＤＭ ＳＴＲＥＡＭ上のコンフィギュレ ータに送られる。例えば、ＯＳＩモデルの層Ｃ４とＣ３との間にストリームリン クを作る場合がこれに相当する。このリンクは、規格に示すようにダイナミック 方式で作る必要がある。 ２７．ＡＤＭ−ＳＴＲＥＡＭ−ＣＬＯＳＥメッセージ： このメッセージは、あるモジュールの接続解除を要求するため、モジュールか らコンフィギュレータＣＯＮＦＤに送られる。ＯＳＩモデルにおいては、例えば 、層Ｃ３（ＣＬＮＰ層と呼ばれる）の接続解除を要求する、すなわち層間のスト リームリンクの切断を要求する層Ｃ４（ＣＯＴＰ層と呼ばれる）の場合がこれに 相当する。 ２８．ＡＤＭ−ＳＴＲＥＡＭ−ＥＲＲＯＲメッセージ： このメッセージは、ＡＤＭ−ＳＴＲＥＡＭ−ＯＰＥＮメッセージ（２６型メッ セージ）が出す要求の送信中にエラーが発生した場合、コンフィギュレータＣＯ ＮＦＤから、コンフィギュレータの問い合わせ先であるモジュールに送られる。 ２９．Ｍ−ＩＯＣＴＬＩ−ＬＩＮＫメッセージ： このメッセージは、２６型メッセージに対応する要求の送信 中に全くエラーが発生しなかった場合、コンフィギュレータから、コンフィギュ レータの問い合わせ先であるモジュールへの応答として送られる。 ３０．Ｍ−ＩＯＣＴＬＩ−ＵＮＬＩＮＫメッセージ： このメッセージは、ＡＤＭ−ＳＴＲＥＡＭ−ＣＬＯＳＥメッセージ（２７型メ ッセージ）に対応する要求の送信中に全くエラーが発生しなかった場合、コンフ ィギュレータから、コンフィギュレータの問い合わせ先であるモジュールへの応 答として送られる。 ３１．Ｍ−ＩＯＣＡＣＫメッセージ： このメッセージは、２９または３０において定義されるメッセージのいずれか 一つに対応する要求の送信後、モジュールからコンフィギュレータに送られる。 ３２．Ｍ−ＩＯＣＮＡＣＫメッセージ： このメッセージは、２９または３０型メッセージのいずれか一つに対応する要 求の送信後、モジュールからコンフィギュレータに送られる。このメッセージは 否定応答に相当する。 付録２を参照することにより、コンフィギュレーションメッセージパッケージ は、ＯＳＩ型層のパイルに対し有効であるこ とがわかる。ＩＰＳ型パイルの場合、通信プロセッサの初期化の際は、ＡＤＭ− ＳＵＢＳＹＳＴＥＭ−ＩＤメッセージのみが使用される。 ＡＤＭ−ＳＵＢＳＹＳＴＥＭ−ＩＤメッセージは、コンフィギュレータＣＯＮ ＦＤから、ＩＡＭ（ＩＰＳ型パイルの層Ｃ３およびＣ４と管理アンテナが発する 管理コマンドとの間の管理インタフェースの役割を果たす特殊内部モジュール） に送られるだけである。 このモジュールは構造上、モジュールＭＩＰＳの層パッケージの管理インタフ ェースとなっている。 ＦＤＤＩネットワークについてのコンフィギュレーションに関しては、既知の ＳＭＴ型の標準化メッセージを使用する。 また、付録３、４、５、６は、前記の各メッセージの記述において説明したこ との概要を示す。例えば付録３には、前記において種々の状況に応じて定義した コンフィギュレーションメッセージパッケージを示す。図の中央の垂直線でコン フィギュレータＣＯＮＦＤを示し、想定するエンティティ、すなわちＭＯＳＩ、 ＭＩＰＳ、ＭＤＩＷＳうちのいずれかのモジュールの層Ｃ４またはＣ３の管理エ ンティティは、図の右側にある垂 直線で示した。メッセージは矢印で示し、矢印の方向はメッセージが送られる方 向を示す。例えば付録３の上部を読むことにより、新規リンクの作成要求を成功 させるために、エンティティからＣＯＮＦＤに送られるＡＤＭ−ＳＴＲＥＡＭ− ＯＰＥＮメッセージ、コンフィギュレータからエンティティに送られるＭ−ＩＯ ＣＴＬＩ−ＬＩＮＫメッセージ、およびエンティティからコンフィギュレータに 送られるＭ−ＩＯＣＡＣＫメッセージを相次いで使用することがわかる。付録３ およびその他の付録の読み取りは、付録３の上部についての前記説明と全く同一 であることがわかる。 付録４は、モジュールＩＭＤと任意のエンティティの間でのメッセージの交換 を示し、前記に説明した管理メッセージのほぼ全てのパッケージが記載されてい る。 付録５は、ＩＭＤから送られたメッセージが、メッセージの正しい処理を妨げ るエラーのため、層エンティティによって受理されていない時に、モジュールＩ ＭＤと任意のエンティティの間でかわされる二つのメッセージについて説明して いる。 付録６は、初期化の際のＣＯＮＦＤ、ＩＭＤ、およびＰＩＬＥエンティティ間 のメッセージの交換を示す。

Claims (1)

1. 【特許請求の範囲】 １．複数のアプリケーションに結合された少なくとも一つのオペレーティングシ ステム（ＧＰＯＳ、ＳＥ１）によってオペレーションが組織され、アプリケーシ ョンに必要なデータを、異なるモデルに属する複数の通信モジュールを含むコー ド（ＣＣ）を形成する種々の層（Ｃ４、Ｃ３、Ｃ２）の管理パッケージを含むネ ットワークに送信しまたはそのネットワークから受信することを目的とする、複 数のオープンシステム（ＯＳＩ、ＩＳＯ／ＤＳＡ、ＩＰＳ）相互接続モデルに属 する通信コード（ＣＣ）を使用するネットワーク（ＲＥ、．．．）との通信シス テム（ＳＣＩ、ＳＣＩ１）であって、 システムの初期化時、種々の層間のリンクによりこれら層の重なりを決定する コンフィギュレータ（ＣＯＮＦＤ）と、 少なくとも一つの管理エンティティ（ＬＭＥ１１、ＬＭＥ１２、．．．）を含 むコードの各層の内部で、管理レベルのあらゆる情報への接続を可能にする管理 モジュール（ＩＭＤ）と、 コンフィギュレータ（ＣＯＮＦＤ）と種々の管理エンティティとの間、ならび にコンフィギュレータ（ＣＯＮＦＤ）と管理 モジュール（ＩＭＤ）との間に配置される第１管理インタフェース（ＬＭＡＩ１ 、ＬＭＩ１）と、 管理モジュール（ＩＭＤ）と層管理エンティティ（ＬＭＥ１１、ＬＭＥ１２等 ）との間に配置される第２管理インタフェース（ＬＭＡＩ２、ＬＭＩ２）と を含むことを特徴とする通信システム。 ２．ＯＳＩ参照モデルの場合、管理エンティティ（ＬＭＥ１１、ＬＭＥ１２、． ．．）が各層の内部に配置され、且つ全ての層に共通なエンティティがＩＰＳモ デルの上位層内に配置され、ＯＳＩモデルの場合、各エンティティが各層の管理 オペレーションを組織し、ＩＰＳモデルの場合、層パッケージ全体の管理オペレ ーションを組織することとを特徴とする請求の範囲第１項に記載の通信システム 。 ３．各管理エンティティ（ＬＭＥ１１、ＬＭＥ１２、．．．）が、複数の属性に よって各々が記述されるオブジェクトパッケージを管理することを特徴とする請 求の範囲第２項に記載の通信システム。 ４．管理モジュール（ＩＭＤ）がオペレーティングシステム（ＧＰＯＳ、ＳＥ１ 、．．．）とリンクして作動し、層の内部 にあるエンティティ（ＬＭＥ１１、．．．）および、メンテナンス、コンフィギ ュレーションの各ツールへの、またはこれらエンティティおよびツールからの管 理メッセージ（ＡＤＭ−ＢＩＮＤ−ＬＡＹＥＲ−ＲＥＱ、．．．）の経路指定を 行い、第１および第２管理インタフェース（ＬＭＡＩ１、ＬＭＡＩ２、ＬＭＩ１ 、ＬＭＩ２）により、管理モジュール（ＩＭＤ）、コンフィギュレータ（ＣＯＮ ＦＤ）、および種々の管理エンティティ（ＬＭＥ１１、．．）の間の対話が定義 されることを特徴とする請求の範囲第１項に記載の通信システム。 ５．メッセージが、第１ブロック（Ｍ−ＰＲＯＴＯ）とその後に続く第２ブロッ ク（Ｍ−ＤＡＴＡ）を含み、第１ブロックが、プリミティブと呼ばれエンティテ ィと管理モジュール（ＩＭＤ）の間の情報のやりとりを定義するデータ構造を含 み、第２ブロックがプリミティブの意味を定義する情報を含むことを特徴とする 請求の範囲第４項に記載の通信システム。 ６．一つのモジュールの各オブジェクトが、接続オブジェクト、選択オブジェク ト、または各層オブジェクトの初期値を定義するオブジェクトＩＶＭＯのいずれ かを各々が含む層オブジェクトを含むことを特徴とする請求の範囲第３項に記載 の通信シス テム。 ７．各被管理オブジェクトが、当該オブジェクトを含む通信モジュールの識別子 を定義する第１フィールド（ＳＵＢＳＹＳＴＥＭ−ｉｄ）と、オブジェクトの管 理種を定義する第２フィールド（ＯＢＪＥＣＴ−ｔｙｐｅ）と、このオブジェク トを含む通信モジュールによって与えられる内部名称を定義する第３フィールド （ＯＢＪＥＣＴ−ｎａｍｅ）の、三つのフィールドによって識別されることを特 徴とする請求の範囲第６項に記載の通信システム。