JPH09500750A - Communication system with network including management package - Google Patents
Communication system with network including management packageInfo
- Publication number
- JPH09500750A JPH09500750A JP7513623A JP51362395A JPH09500750A JP H09500750 A JPH09500750 A JP H09500750A JP 7513623 A JP7513623 A JP 7513623A JP 51362395 A JP51362395 A JP 51362395A JP H09500750 A JPH09500750 A JP H09500750A
- Authority
- JP
- Japan
- Prior art keywords
- management
- message
- module
- layer
- communication system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/24—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using dedicated network management hardware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】 異なるモデルに属する通信モジュールを含むコード(CC)の管理パッケージ(C4、C3、C2)を含む複数の相互接続モデル(OSI、IPS)に属する通信コード(CC)を使用するネットワーク(RE、...)との通信システム(SCI1)であって、− システムの初期化時、種々のコード層間の重なりを決定するコンフィギュレータ(CONFD)と、− 各層の内部で、あらゆる管理情報への接続を可能にする管理モジュール(IMD)と、− コンフィギュレータ(CONFD)と種々の管理エンティティの間、ならびにコンフィギュレータ(CONFD)と管理モジュール(IMD)の間に配置された第1管理インタフェース(LMAI1、LMI1)と、− 管理モジュール(IMD)と管理エンティティLME11、LME12等)間に配置された第2管理インタフェース(LMAI2、LMI2)とを含むことを特徴とする通信システム。通信プロセッサに応用可能。 (57) [Summary] Use a communication code (CC) belonging to a plurality of interconnection models (OSI, IPS) including a management package (C4, C3, C2) of a code (CC) including communication modules belonging to different models. A communication system (SCI1) with a network (RE, ...),-a configurator (CONFD) that determines the overlap between various code layers at system initialization, and-any management information inside each layer. A management module (IMD) enabling connection to a first management interface (LMAI1) arranged between the configurator (CONFD) and various management entities, and between the configurator (CONFD) and the management module (IMD). , LMI1),-a management module (IMD) and a management entity LM 11, the communication system characterized in that it comprises a second management interface that is disposed between LME12, etc.) (LMAI2, LMI2). Applicable to communication processor.
Description
【発明の詳細な説明】 管理パッケージを含むネットワークとの通信システム 本発明は、複数のオープンシステム相互接続モデルに属する通信コードを使用 し、種々のコード層の管理パッケージを含むネットワークとの通信システムに関 する。本発明は、あらゆる種類のネットワーク、特にX3T9−5という参照番 号でANSIで標準化され、またI.S.O.(国際標準化機構)で標準化され たFDDI型に適用可能である。 今日のネットワークは、標準化された層という形のアーキテクチャの定義にお いて、類似した状態を保つ複数の参照モデルに従って動作する。これらモデルの うち最も知られているのが、OSI(オープンシステム相互接続の意味の英語の 略語)、ISO/DSA、IPS(インターネットプロトコル列)モデルである 。IPSモデルは、特にTCP、UDP、IP、ICMPのサブモデルを同じ名 前で含むことに留意されたい。したがってOSIモデルには、活動の異なる七つ の階層があり、最下位層(階層1)は信号の物理的伝送に対応し、上位層(階層 7)はアプリケーションプログラム(より簡単にはアプリケーションと呼ばれる )及び想定するネットワークのユーザによ って実行される機能に対応する。 現在は実際には、ネットワークとの通信システムは、ホストシステムとも呼ば れるコンピュータと、通信プロセッサとの結合によって構成される。通信システ ムの目的は、ネットワークの他の端末との通信の管理の一部を実施することであ る。このため通信プロセッサは、各参照モデルの下位層の管理を担当する。 このような通信システムは、例えば、「ネットワークとの通信システム」とい う名称で、出願人である会社が1993年3月12日に出願したフランス特許出 願第9302902号、あるいは「ネットワークとの通信システム、および該シ ステムに所属するトランスポートサプライヤへの接続プロトコル」という名称で 、出願人である会社が1993年7月21日に出願したフランス特許出願第93 08968号に記載されている。これら二つの特許出願は、特にこのような通信 システムのソフトウェア構造についてより詳細に説明している。また。同一の出 願人が1992年12月22日に出願した、「コンピュータバスとネットワーク の間のデータ伝送システム」という名称のフランス特許出願第9215521号 には、このようなシステム のハードウェア構造についての記載がある。 少なくとも一つの通信プロセッサを含む、極めて簡略化したこのような通信シ ステムの一般的構造(このような通信システムは、複数の異種ネットワークと通 信が可能な複数の通信プロセッサを含むことができる)を、第1a図および第1 b図に示す。 ここではSCIと呼ぶこのような通信システムは、ホストシステムHOSTに より、参照モデルOSI、ISO/DSA、IPSのいずれか一つの上位階層C Hを利用する。(IPSは、接続モードネットワークサービスに準拠することも 非接続モードネットワークサービスに準拠することも可能である。英語のConnec ted Oriented Network Serviceの略語であるCONSで示す接続モードおよび英 語のConnection Less Network Serviceの略語であるCNLSで示す非接続モー ドは、前者はISO規格の9878および8208に準拠し、後者は同規格の8 473および9542に準拠する。これら規格は、組み合せ経路指定機構および プロトコルを定義する。) 第1a図および第1b図に、OSIモデルの三つの上位層C5〜C7を例示し た。CH層は、これらのモデルのC4〜 C2等、下位層CBと通信する。これら層は、単数または複数の通信プロセッサ が利用することができる。第2図では、SCIが、種々の種類であることが可能 な通信プロセッサPCi、PCjに結合されたホストHOSTから成ると仮定し た。これらプロセッサの共通点は下位層CBを利用することである。プロセッサ PCiはネットワークREiに接続されるが、PCjはネットワークREjに接 続され、これら二つのネットワークは異種であってもよい。さらに、PCiもP Cjも、接続モードネットワークサービスRCONS(ISO/DSAまたはT CPモデル)または非接続モードネットワークサービスRCLNS(UDPモデ ル)に準拠するトランスポート層を利用することができる。 第1b図において、HOSTの層CHは、複数のメッセージプロセッサが利用 する下位層CBと通信するが、第1b図では、この転送が、例えば、ここではP SB(IEEE規格1296号)と呼ぶMULTIBUSII型のバスにより行わ れる。 あらゆる通信システム、より正確にはあらゆる通信プロセッサにおいて、ユー ザは、通信コードの各階層が存在しさらに通信層の内部にある各オブジェクトが 存在する状態を常時把握す る必要がある。 ある通信コードの一つの層に所属するあるオブジェクトは、同一の目的のため に働く機能パッケージから成る。すなわち、一つの接続を規定するのに用いられ る機能パッケージがオブジェクトである。物理的には、一つのオブジェクトは、 メモリに存在するデータテーブル、またはデータテーブルセットから成る。 属性またはパラメータにより、オブジェクトの特性が定義される。したがって オブジェクトは、一組の属性によって定義することができる。各属性が一つの値 を有する属性のセットは、オブジェクトインスタンスとも呼ばれる。通信コード のあるオブジェクトまたは層の状態は、どの瞬間にオブジェクトインスタンスを 想定するかによって変化する。オブジェクトインスタンスは、別の層との通信状 態、または構成状態または初期化状態にある。各瞬間において、各オブジェクト または各通信層がどこに位置するかを知るため、あらゆる通信システムは通常、 各層または各オブジェクトの現状を知らしめる管理パッケージを含む。 第1a図および第1b図に図示するような通信システム用の このような管理パッケージを定義することがまさに本発明の目的である。 本発明によれば、複数のアプリケーションに組み合わされた少なくとも一つの オペレーティングシステムによってオペレーションが組織され、アプリケーショ ンに必要なデータを、コードの種々の層の管理パッケージを含むネットワークに 送信しまたはそのネットワークから受信することを目的とする、複数のオープン システム相互接続モデルに属する通信コードを使用するネットワークとの通信シ ステムは、該パッケージが、 − システムの初期化時、種々の層間のSTREAMS型リンクによりこれら層 のパイルを決定するコンフィギュレータと、 − コードの各層の内部で、管理レベルのあらゆる情報への接続を可能にする管 理モジュールと、 − 管理モジュールと層の内部に位置する層の管理エンティティの間の第1管理 インタフェースと、 − コンフィギュレータと種々のエンティティおよび管理モジュールの間の第2 管理インタフェースと を含むことを特徴とする。 本発明のその他の特徴および利点は、添付の図面を参照しな がら、非限定的な例として示した以下の説明を読むことにより、理解されよう。 第1図は、第1a図および第1b図から成り、本発明が応用される通信システ ムの種々の主要な構成要素を示す図である。 第2図は、本発明によるシステムに固有の管理パッケージを含む通信プロセッ サ内に含まれるソフトウェアモジュールパッケージを示す図である。 第3図は、本発明による任意の通信システムの構造の概略図である。 第4図は、本発明による通信システムに属する管理パッケージに固有なメッセ ージの構造を示す図である。 第5図は、本発明による通信システムの管理パッケージに属する各管理モジュ ールの内部構造を示す図である。 第2図を参照する。 同図は、例えば、前記3件の特許出願のいずれか一つに既に記載されている通 信プロセッサNCC1、NCC2、NCC3のうちの一つに属する通信ソフトウ ェアパッケージELCを示す図である。このソフトウェアパッケージELCは、 例えばSCIというように第1図と同じ名称で呼ばれる本発明による 通信システムの一部を成す。 パッケージELCは、以下のものを含む。 − 例えば、OSIモデル、ISO/DSAモデル、およびIPSモデル等、異 なる参照モデルに固有な通信層の三つのパイルを含む通信コードCC。これら種 々のモジュールは各々、MOSI、MDIWS、MIPSと呼ばれる。より詳細 にはこれらモジュールは層C4およびC3に関する。通信コードはさらに、三つ のモジュールに共通な、LLC1とも呼ばれる層C2を含む。 − ホストシステムHOSTに属する通信サーバNCCDと、ここでは三つのモ ジュールMOSI、MDIWS、MIPSによって示す下位層CBとの間のイン タフェースHI。HIおよびNCCDの役割については、前記出願第93029 02号および第9308968号により詳細な記述がある。 − 本発明による通信システムSCIに属する通信プロセッサのオペレーティン グシステムGPOSにより、インタフェースHIと層C2の間の通信を可能にす る、前記3件の特許出願のいずれか一つに既に記載のインタフェースHIN。 − 既にその役割を説明したコンフィギュレーションモ ジュールCONFD。 − 同じく役割を既に説明した管理モジュールIMD。 − コンフィギュレータCONFDと、各通信モジュールMOSI、MDIWS 、MIPSの間に配置された第1管理インタフェースLMAI1。 − 管理モジュールIMDと三つの通信モジュールMOSI、MDIWS、MI PSの間のインタフェースと、管理モジュールIMDとインタフェースHIの間 のインタフェースを各々行うLMAI21およびLMAI22等、実際には同一 の二つの管理インタフェースから成る第2管理インタフェースLMAI2。 コンフィギュレータCONFDと第1管理インタフェースLMAI1の間のリ ンクならびにこの第1インタフェースと三つのモジュールMOSI、MDIWS 、MIPSの間のリンクは、STREAMS型、より詳細にはADM STRE AMSと呼ばれるリンクにより行われる。管理モジュールIMDと二つのインタ フェースLMAI21、LMAI22の間のリンク、ならびにこれら二つインタ フェースと三つの通信モジュールMOSI、MDIWSおよびMIPSの間およ びこれら二つイ ンタフェースとインタフェースHIとの間のリンクは、STREAMS型、より 詳細には管理型リンクであるIM STREAMSと呼ばれるリンクにより行わ れる。 さらに、通信層C2、C3、C4は、隣接する二つの層間の対話を可能にする 原始機能を介して、2対2で通信する。従って、層C2およびC3はSTREA M ST2型機能パッケージを介して両者間で通信を行うが、層C3およびC4 はST3機能パッケージを介して両者間で通信を行う。さらに、C4はSH機能 パッケージを介してインタフェースHIと通信を行う。これらの機能パッケージ はまたSTREAM型機能でもある。ST2、ST3、SH、ADM STRE AMおよびIM STREAMS機能セットは、 − 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 において定義されている。 さらに、OSI、ISO/DSAモデル内では、各通信層が、通信コードCC に属する各通信層の管理業務を組織することを 役割とする特殊管理エンティティを含む。従って、モジュールMOSIは、各々 層C4およびC3に関する管理エンティティLME11およびLME12を含み 、モジュールMDIWSは、層C4およびC3に関する管理エンティティLME 21およびLME22を含む。モジュールMIPSは、C4およびC3に関する 唯一つの管理インタフェースIAMを含む(後述の説明を参照のこと)。OSI およびIPSに共通な層C2は、管理エンティティLME4を有する。 第3図は、ホストシステムHOSTと通信プロセッサNCC1から成る二つの エンティティが、ただ一つに一体化された本発明による通信システムSCI1の 概略構造を示す図である。同図には、機能が図2のコンフィギュレーションモジ ュールと極めて類似するコンフィギュレーションモジュールCONFDと、機能 が図2の管理モジュールと全く同一の管理モジュールIMDと、機能が図2の管 理インタフェースLMAI1と同一の第1管理インタフェースLMI1と、機能 が図2の管理インタフェースLMAI2と全く同一の第2管理インタフェースL MI2が図示されている。 従って、第1管理インタフェースLMI1により、ADM STREAM型の制御STREAMを介して、コンフィギュレーションモジュー ルCONFDと層C6〜C2の各管理エンティティの間のリンクが行われる。ま た第1インタフェースにより、STREAM、ADM STREAMを介して、 管理モジュールIMDとのリンクも行われる。 第2管理インタフェースLMI2により、IM STREAM型のリンクを介 して、管理モジュールIMDと層C7(プレゼンテーション層)〜C2の各管理 エンティティの間のリンクが行われる。層C7〜C2の管理エンティティをそれ ぞれME7〜ME2で示す。第3図に、接続モード(コネクションオリエンティ ド)および非接続モード(コネクションレス)でオペレーションするネットワー クに関する層C3の管理エンティティである管理エンティティME31およびM E32を示す。ME4とME31およびME32の間のリンクは、既知のSTR EAM型リンクによって行われる。 勿論、第2図の通信システムSCIと第3図の通信システムSCI1の作動形 態は同一である。 第2図、第3図の両図においては、各層管理エンティティLME11〜LME 21、LME4およびIAM、ならびに 種々のエンティティME7〜ME2によって、複数の属性によって各々が記述さ れるオブジェクトのパッケージが管理される。これらオブジェクトパッケージは 、OSIモデル、ISO/DSAモデルまたはIPSモデルに関して、各参照モ デルを定義する種々の規格に適合している。また、通信プロセッサまたは通信シ ステムSCI1内に、SNMP、CNMAまたはOSI/NMFORUM等の標 準管理プロトコルを実行することも可能である。 モジュールIMDは全体としては、通信プロセッサまたは通信システムSCI 1のオペレーティングシステムとリンクして作動し、同じくこれら層の内部にあ るエンティティおよび、メンテナンス、コンフィギュレーションおよび管理の各 ツールへの、またはこれらエンティティおよびツールからのメッセージの経路指 定を担当する。上記の説明でわかるように、管理エンティティとモジュールIM Dの間のやりとりは全て、STREAM機能を用いた通信に基く。 第2図のLMAI1またはLMAI2、第3図のLMI1およびLMI2等、 第1および第2管理インタフェースに関しては、これらインタフェースにより、 モジュールIMD、コンフ ィギュレータCONFD、および通信コードの内部にある種々の層管理エンティ ティの間の対話が定義される。 次に、図4はメッセージの方向を定義するプリミティブである原始管理機能を トランスポートするために使用されるSTREAM規格に適合したメッセージの 全体形状を示す図である。 メッセージは、M−PROTOで示す第1ブロックを含むが、同ブロックの後 ろにはM−DATAと呼ばれるブロックが続く場合と続かない場合とがある。各 原始機能は、C構造と呼ばれる特殊なデータ構造によって形成され、同構造の後 ろには、やりとりされた管理情報を含むデータ群(英語ではバッファ)が続く場 合と続かない場合とがある。各データ構造Cは、エンティティとモジュールIM Dの間の情報の全体的なやりとりを定義する。このデータ構造Cは、ブロックM −PROTOの内部に含まれる。情報の方向を定義するプリミティブに組み合わ された情報は、ブロックM−DATA内にトランスポートされる。M−PROT OおよびM−DATAは、モジュールIMDの規定に適合するようにするためA SN.1型フォーマットでコード化される。ASN.1コード化される情報の種 類としては、 以下のものがある。 − ステータスリスト:このリストは、以前、管理を希望した種々のエンティテ ィまたはオブジェクトの状態を示す。 − 管理しようとする種々のエンティティまたはオブジェクトのリストを含むP aram−listと呼ばれるリスト。 − 値を求めようとするオブジェクトの識別子のリストを含むIdent−li stと呼ばれるリスト。 次に、種々のオブジェクトの階層を示す第5図を参照する。例えば、MOSI 、MDIWS、MIPS等のモジュールのオブジェクトであるモジュールオブジ ェクトは、層のオブジェクト、すなわち層4のオブジェクトまたは層3のオブジ ェクトを含むが、後者は、接続オブジェクトか、選択オブジェクトか、またはI VMOと呼ばれる初期値管理オブジェクトかであって、層の各オブジェクトの初 期値を定義するオブジェクトである複数のオブジェクトを含む。 管理モジュールまたはエンティティは、SUBSYSTEM−idと呼ばれる 整数で識別される。通信プロセッサのオペレーティングシステムの内部、あるい はより一般的にはSCI1等の通信システムのオペレーティングシステムの内部 に含まれ るエンティティーの場合、モジュールの識別子は、初期化時、コンフィギュレー タCONFEDによって与えられる。モジュールIMDは、正しいモジュールま たは層の内部にあるエンティティにメッセージを送信するためにこの識別子を使 用する。 被管理オブジェクトは、以下の三つのフィールドによって識別される。 − SUBSYSTEM−id:このフィールドは、この被管理オブジェクトを 含むモジュールの識別子を定義する。 − OBJECT−type:この識別子は、オブジェクトの管理タイプを定義 する。 − OBJECT−name:これは、OSIモデルの場合、オブジェクトを含 むモジュールによって与えられる内部名を与える識別子であり、IPSモデルの 場合、要求されたオブジェクトのインスタンスを探すために使われる個別パラメ ータである、ブロックM−DATA内で伝播される(0〜nの)第1パラメータ を認識することを可能にする(モジュールに名称を与えることができない場合) 整数(0〜n)である。 モジュールを実施する場合、モジュール内に含まれる同一タイプの被管理オブ ジェクトは異なる名称を持つことが前提とな る。 あらゆる管理インタフェース(第2図および第3図のLMAI、LMI)から 発信されるプリミティブに共通なパラメータは、以下の通りである。 PRIM−nameおよびPRIM−typeという名称のパラメータは、管 理インタフェースの要求であるか応答であるかを識別する。 IM−useridパラメータはモジュールIMDによって与えられ、このパ ラメータによりIMDモジュールは、要求を出したエンティティへの返答の正し い経路指定を行うことが可能となる。このパラメータが、要求の場合も応答の場 合も、同じ値を有することは明らかである。 管理インタフェースに関するプリミティブ全てに共通なパラメータの中には、 前記に定めたSUBSYSTEM−id、OBJECT−typeおよびOBJ ECT−nameもある。 また、同じタイプではあるが同一の管理要求をサポートしていないオブジェク トセットを区別するのに使われる、OBJECT−subtypeと呼ばれる別 のパラメータもある。 選択オブジェクト、接続オブジェクトおよびIVMO型オブジェクトの場合、 これらオジェクトのすぐ上位のオブジェクトが、これらオジェクトを含む層オブ ジェクトを示す。この上位オブジェクトは、以下の三つのフィールドによって識 別される。 − SUBSYSTEM−upidは、エンティティすなわち上位オブジェクト を含む層の識別子である。 − OBJECT−uptypeは、上位オブジェクトの管理タイプである。 − OBJECT−upnameは、上位オブジェクトの名称である。 モジュールCONFD、IMDおよびLMAI1、LMAI2、LMI1、L MI2が使用するメッセージは、管理メッセージとコンフィギュレーションメッ セージの2種類がある。 最初に、種々の管理メッセージを想定する。第1付録に管理メッセージのリス トを、第2付録にコンフィギュレーションメッセージのリストを、各々示す。付 録の双方とも、最初の段にメッセージ名を示し、以降の段に、OSI型、または IPS型、またはFDDI型等、メッセージが属する参照モデルを示した。さら に右側二つの段には、メッセージの発信元の名称およびメ ッセージの送信先の名称を示した。 1から21までの番号を付した(1型から21型の)管理メッセージは以下の 通りである。 1.ADM−BIND−LAYER−REQメッセージ: このメッセージは、管理エンティティとモジュールIMDの間の対話を初期化 するため、モジュールIMDが管理エンティティに送る要求メッセージである。 これは、当該モジュールがエンティティに送る最初のメッセージである。エンテ ィティは、当該エンティティが管理するオブジェクトの種類を示すADM−BI ND−OBJ−INDと呼ばれる一つ(あるいは複数の)メッセージを送って応 答する。エンティティは、IMDに、自分が管理するオブジェクトパッケージに 対応するADM−BIND−OBJ−INDメッセージパッケージを送り終える と、IMDに応答の終了を知らせるため、ADM−OK−ACKメッセージを送 る。この最新の肯定応答が受信されるまでは、モジュールIMDは管理エンティ ティに、別のメッセージを一切送ることができない。エンティティは、要求メッ セージを受信すると、STREAM型のリンクを管理情報に割り当てる。 2.ADM−BIND−OBJ−INDメッセージ: このメッセージは、モジュールIMDが問い合わせる管理エンティティが、前 記メッセージに対する応答として返すメッセージである。このメッセージは、I M−STREAMS型のSTREAM機能に送られる。管理エンティティはこの 種のメッセージを、被管理オブジェクト1種類につき一つだけ送る。 3.ADM−OK−ACKメッセージ: このメッセージは、モジュールIMDと管理エンティティの間の初期化対話を 終了させるものである。このメッセージは、1型のメッセージに対する応答とし て単数または複数の2型のメッセージが送られた後に、IM−Streamsに 送られる。 このメッセージはまた、管理エンティティに対し別の応答が一切定義されてい ない時に、管理エンティティが、一つ前に送られたメッセージの受信に成功した ことをモジュールIMDに知らせるためにも使用される。 4.ADM−ERROR−ACKメッセージ: このメッセージは、管理エンティティが、一つ前に送られたメッセージの受信 に成功しなかったことと、システムエラーのためメッセージが処理できないこと をIMDに知らせる。不良 の理由もこのメッセージが知らせる。また、このメッセージが受信されたことに より、この否定応答を発生したメッセージに対し何等のアクションもとられなか ったことが、IMDに示される。 5.ADM−LIST−REQメッセージ: このメッセージは、OBJECT−typeフィールド内で指定されるモジュ ールによって送られる。 接続、選択およびIVMOオブジェクトの場合、種類がOBJECT−typ eフィールド内で指定され、OBJECT−uptype、OBJECT−up name、SUBSYSTEMフィールドによって識別される層オブジェクトに 組み合わされるオブジェクトの名称を与える。 6.ADM−LIST−ACKメッセージ: このメッセージは、5型のメッセージに対する応答として、PILE(層のパ イル)エンティティによってモジュールIMDに送られる。このメッセージは、 あるオブジェクト種に関するオブジェクトインスタンスの管理名のリストを与え る。 7.ADM−GET−REQメッセージ: このメッセージは、被管理エンティティにオブジェクトイン スタンスの属性値を返すよう要求するためにIMDが送るメッセージである。属 性リストが提供された場合には、属性値リストは、モジュールIMDに返さなけ ればならない。リストが提供されなかった場合には、属性値は全て返さなければ ならない。任意の属性の読み取りが不可能な場合には、管理エンティティが与え る応答内にエラーが示される。 8.ADM−GET−ACKメッセージ: このメッセージは、7型のメッセージに対する応答として、管理エンティティ によってモジュールIMDに送られる。このメッセージは、要求オブジェクトイ ンスタンス属性値を返す。少なくとも一つの属性の読み取りが不可能な場合には エラーが示される。 9.ADM−GETNEXT−REQメッセージ: このメッセージにより、管理エンティティは、あるオブジェクトのインスタン スの名称を知らなくともこのようなインスタンス全てについての属性を取得する ことができる。従って、オブジェクトインスタンス名を取得するのに5型のメッ セージを送る必要はない。オブジェクト名リストは、エンティティによって任意 の順番で管理されるが、その順番は、層の内部のエン ティティのインプリメンテーションに依存する。 10.ADM−GETNEXT−ACKメッセージ: このメッセージは、9型のメッセージに対する応答として、管理エンティティ によって送られる。このメッセージは、モジュールIMDに要求オブジェクト属 性値を返す。これら属性の読み取りが不可能な場合にはエラーが示される。 11.ADM−SET−REQメッセージ: このメッセージは、IMDが、IM−STREAM上の管理エンティティに送 るメッセージである。このメッセージにより、オブジェクトインスタンスの属性 に新しい値を与えることができる。このオペレーションは、書き込みが可能であ ると定義された属性に対し適用される。M−DATA部分に与えられる属性のリ ストは、属性の識別子および、置き換えが必要な属性値に与える結合値を含む。 12.ADM−SET−ACKメッセージ: このメッセージは、11型のメッセージに対する応答として、管理エンティテ ィによって送られる。このメッセージは、11型メッセージによって要求された 属性値変更オペレーションが成功したかどうかを示す。 13.ADM−TEST−REQメッセージ: このメッセージは、IMDが管理エンティティに送るメッセージである。この メッセージにより、ある一つのオブジェクトインスタンスの複数の属性の値を同 時に変更して新しい値にすることができるかどうかを検証することができる。こ のメッセージでは属性値は変更されない。 14.ADM−TEST−ACKメッセージ: このメッセージは、13型のメッセージに対する応答として、管理エンティテ ィによって送られる肯定応答メッセージである。 15.ADM−ACTION−REQメッセージ: このメッセージは、IMDが管理エンティティに送るメッセージである。この メッセージの機能は、PRIM−typeフィールド内に記述されるアクション の種類に依存する。 16.ADM−ACTION−ACKメッセージ: このメッセージは、15型のメッセージに対する応答として、管理エンティテ ィによって送られ、同要求が成功または失敗したことを示す。 17.ADM−ADD−REQメッセージ: このメッセージは、管理エンティティに新規オブジェクトイ ンスタンスを作成するよう要求するものである。このメッセージは、あらゆる種 類のオブジェクトに対し可能というわけではない。あるオブジェクトを作成する 場合、同オブジェクトについてある数の属性が必須であり、かつそれらを要求内 に与えなければならない。作成しなければならないオブジェクトの名称は、その 後、同名称を管理するモジュールによって与えられる。この名称は、このメッセ ージによって構成される要求に対する応答の中に与えられる。 18.ADM−ADD−ACKメッセージ: このメッセージは、17型のメッセージに対する応答として、管理エンティテ ィによって送られ、要求の成功時には肯定応答を行う。 19.ADM−REMOVE−REQメッセージ: このメッセージは、管理エンティティにオブジェクトインスタンスを削除する よう要求するものである。 20.ADM−REMOVE−ACKメッセージ: このメッセージは、19型のメッセージに対応する要求の成功または失敗を肯 定応答するため、19型のメッセージに対する応答として、管理エンティティに よって送られる。 21.ADM−EVENT−INDメッセージ: このメッセージは、層エンティティ内でイベントが実行されることをモジュー ルIMDに示す。管理モジュールに関しては、該層エンティティ内でイベントが 発生したとの情報を受信する場合には、肯定応答はない。 付録1においてわかるように、1〜21型のメッセージパッケージはOSIま たはISO/DSA参照モデル用に使用される。これらのメッセージのパッケー ジは、メッセージ5および6を除き、IPSモデルにも使用される。 FDDI型ネットワークの場合も、4型および7型から21型のメッセージを 使用する。 IPS参照モデルのオブジェクトの識別に関しては、同識別は、OSI参照モ デルの識別と比較して幾つかの異なる側面を有する。 OBJECT−typeフィールドは、パラメータから成るオブジェクトクラ スである。IPSオブジェクトは、OBJECT−typeフィールドおよび上 記クラスのインスタンスによって定義される。それが単純オブジェクト(モノイ ンスタンス)であれば、識別は、単に(OBJECT− type)フィールドによって与えられる。インスタンスは、選択パラメータの 値によって定義される。識別と値を与える選択パラメータは、要求のM−DAT Aメッセージブロックに伝送される。 OBJECT−nameフィールドは、選択に使用されるパラメータ数を有す る。従って、必要であれば、M−DATAメッセージブロックの最初のインスタ ンスが選択パラメータとなる。 M−DATAメッセージブロックはASN.1でコード化される。 次に、以後の文中に示しまた付録2に示す、22から32までの番号を付した (22型から32型の)種々のコンフィギュレーションメッセージを想定する。 付録2の形態は付録1の形態と全く同一である。 これら種々のコンフィギュレーションメッセージは以下の通りである。 22.ADM−SUBSYSTEM−IDメッセージ: このメッセージは、コンフィギュレータCONFDにより、第2図の通信プロ セッサの各モジュールの開放後直ちに送られ るか、第3図のシステムSCI1の各モジュールにより送られ、ADM STR EAMまたはIM STREAMにより伝播される。管理されることを希望する エンティティはどれでも、このメッセージを考慮に入れることができるが、同メ ッセージを理解できなければならない。 23.ADM−STREAM−BINDメッセージ: このメッセージは、CONFDにより、あるモジュールの制御ストリームの開 放後直ちに送られる。次にこのストリームは、該モジュールによりコンフィギュ レータCONFDに割り当てられる。 24.ADM−STREAM−ACKメッセージ: このメッセージは、23型メッセージの要求が受理された場合、モジュールか らコンフィギュレータに返される。 25.ADM−STREAM−NACKメッセージ: このメッセージは、23型メッセージによって示される要求が拒否された場合 、モジュールからコンフィギュレータCONFDに返される。 26.ADM−STREAM−OPENメッセージ: このメッセージは、別のモジュールにストリーム型の新規リ ンクを要求するため、モジュールからADM STREAM上のコンフィギュレ ータに送られる。例えば、OSIモデルの層C4とC3との間にストリームリン クを作る場合がこれに相当する。このリンクは、規格に示すようにダイナミック 方式で作る必要がある。 27.ADM−STREAM−CLOSEメッセージ: このメッセージは、あるモジュールの接続解除を要求するため、モジュールか らコンフィギュレータCONFDに送られる。OSIモデルにおいては、例えば 、層C3(CLNP層と呼ばれる)の接続解除を要求する、すなわち層間のスト リームリンクの切断を要求する層C4(COTP層と呼ばれる)の場合がこれに 相当する。 28.ADM−STREAM−ERRORメッセージ: このメッセージは、ADM−STREAM−OPENメッセージ(26型メッ セージ)が出す要求の送信中にエラーが発生した場合、コンフィギュレータCO NFDから、コンフィギュレータの問い合わせ先であるモジュールに送られる。 29.M−IOCTLI−LINKメッセージ: このメッセージは、26型メッセージに対応する要求の送信 中に全くエラーが発生しなかった場合、コンフィギュレータから、コンフィギュ レータの問い合わせ先であるモジュールへの応答として送られる。 30.M−IOCTLI−UNLINKメッセージ: このメッセージは、ADM−STREAM−CLOSEメッセージ(27型メ ッセージ)に対応する要求の送信中に全くエラーが発生しなかった場合、コンフ ィギュレータから、コンフィギュレータの問い合わせ先であるモジュールへの応 答として送られる。 31.M−IOCACKメッセージ: このメッセージは、29または30において定義されるメッセージのいずれか 一つに対応する要求の送信後、モジュールからコンフィギュレータに送られる。 32.M−IOCNACKメッセージ: このメッセージは、29または30型メッセージのいずれか一つに対応する要 求の送信後、モジュールからコンフィギュレータに送られる。このメッセージは 否定応答に相当する。 付録2を参照することにより、コンフィギュレーションメッセージパッケージ は、OSI型層のパイルに対し有効であるこ とがわかる。IPS型パイルの場合、通信プロセッサの初期化の際は、ADM− SUBSYSTEM−IDメッセージのみが使用される。 ADM−SUBSYSTEM−IDメッセージは、コンフィギュレータCON FDから、IAM(IPS型パイルの層C3およびC4と管理アンテナが発する 管理コマンドとの間の管理インタフェースの役割を果たす特殊内部モジュール) に送られるだけである。 このモジュールは構造上、モジュールMIPSの層パッケージの管理インタフ ェースとなっている。 FDDIネットワークについてのコンフィギュレーションに関しては、既知の SMT型の標準化メッセージを使用する。 また、付録3、4、5、6は、前記の各メッセージの記述において説明したこ との概要を示す。例えば付録3には、前記において種々の状況に応じて定義した コンフィギュレーションメッセージパッケージを示す。図の中央の垂直線でコン フィギュレータCONFDを示し、想定するエンティティ、すなわちMOSI、 MIPS、MDIWSうちのいずれかのモジュールの層C4またはC3の管理エ ンティティは、図の右側にある垂 直線で示した。メッセージは矢印で示し、矢印の方向はメッセージが送られる方 向を示す。例えば付録3の上部を読むことにより、新規リンクの作成要求を成功 させるために、エンティティからCONFDに送られるADM−STREAM− OPENメッセージ、コンフィギュレータからエンティティに送られるM−IO CTLI−LINKメッセージ、およびエンティティからコンフィギュレータに 送られるM−IOCACKメッセージを相次いで使用することがわかる。付録3 およびその他の付録の読み取りは、付録3の上部についての前記説明と全く同一 であることがわかる。 付録4は、モジュールIMDと任意のエンティティの間でのメッセージの交換 を示し、前記に説明した管理メッセージのほぼ全てのパッケージが記載されてい る。 付録5は、IMDから送られたメッセージが、メッセージの正しい処理を妨げ るエラーのため、層エンティティによって受理されていない時に、モジュールI MDと任意のエンティティの間でかわされる二つのメッセージについて説明して いる。 付録6は、初期化の際のCONFD、IMD、およびPILEエンティティ間 のメッセージの交換を示す。 DETAILED DESCRIPTION OF THE INVENTION Communication system with network including management package The present invention relates to a communication system with a network using communication codes belonging to a plurality of open system interconnection models and including management packages of various code layers. The present invention is standardized in ANSI for all kinds of networks, in particular under the reference number X3T9-5, and I.S. S. O. It is applicable to the FDDI type standardized by (International Organization for Standardization). Today's networks operate according to multiple reference models that remain similar in their definition of an architecture in the form of standardized layers. The best known of these models are the OSI (English abbreviation for open system interconnection), ISO / DSA, and IPS (Internet Protocol Sequence) models. It should be noted that the IPS model contains, among other things, TCP, UDP, IP, ICMP sub-models with the same name. Therefore, the OSI model has seven layers with different activities, the lowest layer (layer 1) corresponds to the physical transmission of signals, and the upper layer (layer 7) is an application program (more simply called an application). And the functions performed by the assumed network users. Presently, a communication system with a network is actually composed of a computer, also called a host system, and a communication processor. The purpose of the communication system is to implement some of the management of communication with other terminals of the network. Therefore, the communication processor is responsible for managing the lower layers of each reference model. Such a communication system is, for example, French patent application No. 9302902 filed by the applicant company on March 12, 1993 under the name "communication system with network", or "communication system with network," And a connection protocol to a transport supplier belonging to the system ", which is described in French patent application No. 93 09868 filed on 21 July 1993 by the applicant company. These two patent applications particularly describe the software structure of such communication systems in more detail. Also. The same applicant filed on Dec. 22, 1992, French patent application No. 9215521 entitled "Data transmission system between computer bus and network" describes the hardware structure of such a system. There is. A highly simplified general structure of such a communication system including at least one communication processor (such a communication system may include a plurality of communication processors capable of communicating with a plurality of heterogeneous networks), Shown in Figures 1a and 1b. Such a communication system, referred to herein as SCI, uses a host system HOST to utilize one of the upper layers CH of the reference models OSI, ISO / DSA, and IPS. (IPS can comply with connected mode network services or non-connected mode network services. Connection mode indicated by CONS, which is an abbreviation for Concentrated Oriented Network Service in English, and Connection Less Network Service in English. The non-connected mode, denoted by CNLS, which is an abbreviation for the above, conforms to the ISO standards 9878 and 8208 and the latter to the same standards 8473 and 9542. These standards define the combination routing mechanism and protocol. 3) The upper layers C5 to C7 of the OSI model are illustrated in FIGS. 1a and 1b. The CH layer communicates with lower layer CBs, such as C4-C2 in these models. These layers can be utilized by one or more communication processors. In FIG. 2 it was assumed that the SCI consists of a host HOST coupled to a communications processor PCi, PCj which may be of various types. The common point of these processors is to utilize the lower layer CB. The processor PCi is connected to the network REi, while the PCj is connected to the network REj, these two networks may be heterogeneous. Furthermore, both PCi and PCj can utilize a transport layer that conforms to the connected mode network service RCONS (ISO / DSA or TCP model) or the unconnected mode network service RCLNS (UDP model). In FIG. 1b, the HOST layer CH communicates with the lower layer CB used by multiple message processors, but in FIG. 1b this transfer is, for example, MULTIBUSII, referred to herein as PSB (IEEE Standard 1296). It is done by a mold bath. In any communication system, or more precisely any communication processor, the user needs to keep track of the existence of each hierarchy of communication code and of each object inside the communication layer. An object belonging to a layer of some communication code consists of functional packages that serve the same purpose. That is, the function package used to define one connection is an object. Physically, an object consists of a data table or a data table set that resides in memory. Attributes or parameters define the characteristics of an object. Thus, an object can be defined by a set of attributes. The set of attributes, where each attribute has one value, is also called an object instance. The state of the object or layer with the communication code changes depending on what moment the object instance is assumed. The object instance is in communication with another layer, or in a configured or initialized state. In order to know where each object or each communication layer is located at each moment, every communication system usually includes a management package that informs the current status of each layer or each object. It is precisely the purpose of the invention to define such a management package for a communication system as illustrated in Figures 1a and 1b. In accordance with the present invention, operations are organized by at least one operating system associated with a plurality of applications to send and receive data required by the applications to and from a network containing management packages of various layers of code. A communication system with a network using communication codes belonging to a plurality of open system interconnection models intended for the purpose of: the package is: -at initialization of the system, the STREAMS type links between the various layers of these layers. A configurator that determines the pile, a management module that enables connection to all information at the management level within each layer of code, and a first between the management module and the management entity of the layer located inside the layer. Management interface When, - characterized in that it comprises a second management interface between the configurator and the various entities and management module. Other features and advantages of the invention will be understood by reading the following description, given by way of non-limiting example, with reference to the accompanying drawings. FIG. 1 is composed of FIGS. 1a and 1b and shows various main components of a communication system to which the present invention is applied. FIG. 2 is a diagram showing a software module package included in a communication processor including a management package specific to the system according to the present invention. FIG. 3 is a schematic diagram of the structure of an arbitrary communication system according to the present invention. FIG. 4 is a diagram showing the structure of a message unique to a management package belonging to the communication system according to the present invention. FIG. 5 is a diagram showing the internal structure of each management module belonging to the management package of the communication system according to the present invention. Please refer to FIG. The figure shows, for example, a communication software package ELC belonging to one of the communication processors NCC1, NCC2, NCC3 already described in any one of the three patent applications. This software package ELC forms part of the communication system according to the invention, which is called by the same name as in FIG. 1, eg SCI. Package ELC includes: A communication code CC comprising three piles of communication layers specific to different reference models, eg OSI model, ISO / DSA model and IPS model. These various modules are called MOSI, MDIWS and MIPS respectively. More specifically, these modules relate to layers C4 and C3. The communication code further comprises a layer C2, also called LLC1, common to the three modules. An interface HI between the communication server NCCD belonging to the host system HOST and the lower layer CB, here indicated by three modules MOSI, MDIWS, MIPS. The roles of HI and NCCD are described in more detail in the above-mentioned application Nos. 9302902 and 9308968. The interface HIN already mentioned in any one of the three patent applications, which enables communication between the interface HI and the layer C2 by means of the operating system GPOS of the communication processor belonging to the communication system SCI according to the invention. A configuration module CONFD whose role has already been described. The management module IMD whose role has already been described above. A first management interface LMAI1 arranged between the configurator CONFD and each communication module MOSI, MDIWS, MIPS. -Actually two identical management interfaces, such as the interface between the management module IMD and the three communication modules MOSI, MDIWS, MIPS, and the LMAI21 and LMAI22 which respectively perform the interface between the management module IMD and the interface HI. Second management interface LMAI2. The link between the configurator CONFD and the first management interface LMAI1 as well as the link between this first interface and the three modules MOSI, MDIWS, MIPS is provided by a link called STREAMS type, more specifically ADM STREAAMS. The links between the management module IMD and the two interfaces LMAI21, LMAI22, and between these two interfaces and the three communication modules MOSI, MDIWS and MIPS and between these two interfaces and the interface HI are STREAMS type, More specifically, it is performed by a link called IM STREAMS which is a managed link. Furthermore, the communication layers C2, C3, C4 communicate two-to-two via a primitive function that allows interaction between two adjacent layers. Thus, layers C2 and C3 communicate between themselves via the STREAM ST2 type functional package, while layers C3 and C4 communicate between them via the ST3 functional package. Further, C4 communicates with the interface HI via the SH function package. These feature packages are also STREAM type features. ST2, ST3, SH, ADM STREAM and IM STREAMS feature sets are: -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. Further, in the OSI and ISO / DSA models, each communication layer includes a special management entity having a role of organizing a management task of each communication layer belonging to the communication code CC 1. Thus, the module MOSI contains the management entities LME11 and LME12 for the layers C4 and C3, respectively, and the module MDIWS contains the management entities LME21 and LME22 for the layers C4 and C3. The module MIPS contains a single management interface IAM for C4 and C3 (see below). The layer C2 common to OSI and IPS has a management entity LME4. FIG. 3 shows a communication system SCI according to the present invention in which two entities consisting of a host system HOST and a communication processor NCC1 are integrated into one entity. 1 It is a figure which shows schematic structure of. In the figure, a configuration module CONFD whose function is very similar to the configuration module of FIG. 2, a management module IMD whose function is exactly the same as the management module of FIG. 2, and a function which is the same as the management interface LMAI1 of FIG. A first management interface LMI1 and a second management interface LMI2 having exactly the same function as the management interface LMAI2 of FIG. 2 are shown. Thus, the first management interface LMI1 provides a link between the configuration module CONFD and each management entity of the layers C6 to C2 via the ADM STREAM type control STREAM. The first interface also links with the management module IMD via STREAM and ADM STREAM. The second management interface LMI2 provides a link between the management module IMD and each management entity of the layers C7 (presentation layer) to C2 via an IM STREAM type link. The management entities of layers C7-C2 are denoted ME7-ME2, respectively. FIG. 3 shows the management entities ME31 and ME32, which are the management entities of layer C3 for networks operating in connected mode (connection oriented) and disconnected mode (connectionless). The links between ME4 and ME31 and ME32 are provided by the known STR EAM type links. Of course, the operation modes of the communication system SCI of FIG. 2 and the communication system SCI1 of FIG. 3 are the same. 2 and 3, each layer management entity LME11 to LME 21, LME4 and IAM, and various entities ME7 to ME2 manage a package of objects each of which is described by a plurality of attributes. . These object packages conform to the various standards that define each reference model with respect to the OSI model, ISO / DSA model or IPS model. It is also possible to execute in the communication processor or the communication system SCI1 a standard management protocol such as SNMP, CNMA or OSI / NMFORUM. The module IMD operates as a whole in connection with the operating system of the communication processor or the communication system SCI 1 and also to the entities also inside these layers and to the maintenance, configuration and management tools or to these entities and Responsible for routing messages from the tool. As can be seen in the above description, all interactions between the management entity and the module IMD are based on communication using the STREAM function. With respect to the first and second management interfaces, such as LMAI1 or LMAI2 in FIG. 2 and LMI1 and LMI2 in FIG. 3, these interfaces allow the module IMD, the configurator CONFD, and various layer management entities inside the communication code. The interaction between is defined. Next, FIG. 4 is a diagram showing the overall shape of a message conforming to the STREAM standard used for transporting a primitive management function that is a primitive that defines the direction of a message. The message includes the first block indicated by M-PROTO, which may or may not be followed by a block called M-DATA. Each primitive function is formed by a special data structure called a C structure, which may or may not be followed by a data group (buffer in English) containing exchanged management information. Each data structure C defines the overall exchange of information between the entity and the module IM D. This data structure C is contained inside the block M-PROTO. The information combined into primitives that define the direction of the information is transported in block M-DATA. M-PROTO and M-DATA are ASN.M in order to comply with the specifications of the module IMD. Encoded in type 1 format. ASN. The types of information coded in one are as follows. -Status List: This list shows the status of various entities or objects that previously wished to be managed. A list called the Param-list, which contains a list of the various entities or objects to be managed. A list called the Identity-list which contains a list of identifiers of the objects for which values are sought. Reference is now made to FIG. 5, which shows the hierarchy of various objects. For example, a module object, which is an object of a module such as MOSI, MDIWS, MIPS, etc., comprises a layer object, ie a layer 4 object or a layer 3 object, while the latter is a connection object, a selection object or an I VMO. Or an initial value management object, which includes a plurality of objects that are objects that define the initial value of each object in the layer. Management modules or entities are identified by an integer called SUBSYSTEM-id. In the case of an entity contained within the operating system of the communication processor, or more generally within the operating system of the communication system such as SCI1, the identifier of the module is given by the configurator CONFIG at initialization. The module IMD uses this identifier to send the message to entities inside the correct module or layer. Managed objects are identified by the following three fields. SUBSYSTEM-id: This field defines the identifier of the module that contains this managed object. -OBJECT-type: This identifier defines the management type of the object. -OBJECT-name: This is an identifier that gives the internal name given by the module containing the object in the case of the OSI model, or an individual parameter used to find the instance of the requested object in the case of the IPS model, An integer (0-n) that allows to recognize the first parameter (0-n) propagated in the block M-DATA (if the module cannot be named). When implementing a module, it is assumed that managed objects of the same type contained in the module have different names. The parameters common to the primitives originating from all management interfaces (LMAI, LMI in FIGS. 2 and 3) are: Parameters named PRIM-name and PRIM-type identify management interface requests or responses. The IM-userid parameter is provided by the module IMD, which allows the IMD module to correctly route the reply to the requesting entity. It is clear that this parameter has the same value in both request and response. Among the parameters common to all the primitives related to the management interface, there are SUBSYSTEM-id, OBJECT-type and OBJ ECT-name defined above. There is also another parameter called OBJECT-subtype, which is used to distinguish between object sets of the same type but that do not support the same management requirements. In the case of selection objects, connection objects and IVMO type objects, the objects immediately above these objects indicate the layer objects containing these objects. This superordinate object is identified by the following three fields. SUBSYSTEM-upid is the identifier of the layer that contains the entity or upper object. -OBJECT-uptype is a management type of a higher-level object. -OBJECT-upname is the name of the higher-level object. There are two types of messages used by the modules CONFD, IMD and LMAI1, LMAI2, LMI1, LMI2: management messages and configuration messages. First, assume various management messages. The first appendix shows a list of management messages, and the second appendix shows a list of configuration messages. In both appendices, the message name is shown in the first row, and the reference model to which the message belongs, such as OSI type, IPS type, or FDDI type, is shown in the subsequent rows. Further, the two columns on the right side show the name of the sender of the message and the name of the destination of the message. The management messages numbered 1 to 21 (types 1 to 21) are as follows. 1. ADM-BIND-LAYER-REQ message: This message is a request message that the module IMD sends to the management entity to initiate the interaction between the management entity and the module IMD. This is the first message the module sends to the entity. An entity responds by sending one (or more) messages called ADM-BIND-OBJ-IND, which indicates the type of object it manages. When the entity finishes sending the ADM-BIND-OBJ-IND message package corresponding to the object package it manages, the entity sends the ADM-OK-ACK message to inform the IMD of the end of the response. Until this latest acknowledgment is received, the module IMD cannot send any other message to the management entity. Upon receipt of the request message, the entity assigns a STREAM type link to the management information. 2. ADM-BIND-OBJ-IND message: This message is a message returned by the management entity queried by the module IMD in response to said message. This message is sent to the STREAM function of the IM-STREAMS type. The management entity sends only one such message for each type of managed object. 3. ADM-OK-ACK message: This message ends the initialization dialogue between the module IMD and the management entity. This message is sent to IM-Streams after one or more type 2 messages are sent in response to the type 1 message. This message is also used to inform the module IMD that the management entity has successfully received the message previously sent when no other response has been defined to the management entity. 4. ADM-ERROR-ACK message: This message informs the IMD that the management entity did not successfully receive the previous message sent and that the message cannot be processed due to a system error. This message will also inform you of the reason for the failure. Also, due to the receipt of this message, the IMD indicates that no action was taken on the message that generated this negative response. 5. ADM-LIST-REQ Message: This message is sent by the module specified in the OBJECT-type field. For Connect, Select and IVMO objects, the type is specified in the OBJECT-type field and gives the name of the object to be combined with the layer object identified by the OBJECT-uptype, OBJECT-up name, SUBSYSTEM field. 6. ADM-LIST-ACK message: This message is sent by the PILE (layer pile) entity to the module IMD in response to a type 5 message. This message gives a list of object instance administrative names for an object type. 7. ADM-GET-REQ Message: This message is a message sent by the IMD to request the managed entity to return the attribute values of the object instance. If the attribute list is provided, the attribute value list must be returned to the module IMD. If no list is provided, all attribute values must be returned. If it is not possible to read any of the attributes, an error will be indicated in the response provided by the management entity. 8. ADM-GET-ACK message: This message is sent by the management entity to the module IMD in response to a type 7 message. This message returns the request object instance attribute value. An error is signaled if at least one attribute cannot be read. 9. ADM-GETNEXT-REQ Message: This message allows the management entity to get the attributes for all such instances of an object without knowing the name of the instance. Therefore, it is not necessary to send a type 5 message to get the object instance name. The object name list is managed by the entities in any order, but that order depends on the implementation of the entities inside the layer. 10. ADM-GETNEXT-ACK message: This message is sent by the management entity in response to a Type 9 message. This message returns the request object attribute value to the module IMD. An error is signaled if these attributes cannot be read. 11. ADM-SET-REQ Message: This message is a message sent by the IMD to the management entity on IM-STREAM. This message allows you to give new values to the attributes of the object instance. This operation applies to attributes defined as writable. The list of attributes provided in the M-DATA part includes the attribute's identifier and the binding value given to the attribute value that needs to be replaced. 12. ADM-SET-ACK message: This message is sent by the management entity in response to a type 11 message. This message indicates whether the attribute value change operation requested by the Type 11 message was successful. 13. ADM-TEST-REQ Message: This message is the message that the IMD sends to the management entity. This message can verify whether the values of multiple attributes of an object instance can be changed to new values at the same time. This message does not change the attribute value. 14. ADM-TEST-ACK message: This message is an acknowledgment message sent by the management entity in response to a Type 13 message. 15. ADM-ACTION-REQ Message: This message is the message that the IMD sends to the management entity. The function of this message depends on the type of action described in the PRIM-type field. 16. ADM-ACTION-ACK message: This message is sent by the management entity in response to a type 15 message to indicate that the request succeeded or failed. 17. ADM-ADD-REQ Message: This message requests the management entity to create a new object instance. This message is not possible for all kinds of objects. When creating an object, a certain number of attributes for the object are mandatory and must be given in the request. The name of the object that has to be created is then given by the module that manages the name. This name is given in the response to the request constructed by this message. 18. ADM-ADD-ACK message: This message is sent by the management entity in response to a Type 17 message and acknowledges on successful request. 19. ADM-REMOVE-REQ Message: This message requests the management entity to delete the object instance. 20. ADM-REMOVE-ACK message: This message is sent by the management entity in response to a 19-type message to acknowledge the success or failure of the request corresponding to the 19-type message. 21. ADM-EVENT-IND message: This message indicates to the module IMD that the event is to be executed in the layer entity. For the management module, there is no acknowledgment when it receives information that an event has occurred within the layer entity. As can be seen in Appendix 1, message packages of types 1-21 are used for the OSI or ISO / DSA reference models. These message packages, with the exception of messages 5 and 6, are also used for the IPS model. For FDDI type networks, type 4 and type 7 to type 21 messages are also used. Regarding identification of objects in the IPS reference model, the identification has several different aspects compared to the identification of the OSI reference model. The OBJECT-type field is an object class consisting of parameters. The IPS object is defined by the OBJECT-type field and an instance of the above class. If it is a simple object (mono-instance), the identification is simply given by the (OBJECT-type) field. The instance is defined by the value of the selection parameter. The selection parameters giving the identification and the value are transmitted in the request M-DATA message block. The OBJECT-name field contains the number of parameters used for selection. Therefore, if necessary, the first instance of the M-DATA message block will be the selection parameter. The M-DATA message block is ASN. Coded with 1. Next, assume various configuration messages (22 to 32 types) numbered 22 to 32, shown in the following text and shown in Appendix 2. The form of Appendix 2 is exactly the same as the form of Appendix 1. These various configuration messages are as follows: 22. ADM-SUBSYSTEM-ID message: This message is sent by the configurator CONFD immediately after the release of each module of the communication processor of FIG. 2 or by each module of the system SCI1 of FIG. 3 and the ADM STR EAM or IM. Propagated by STREAM. Any entity wishing to be managed can take this message into account, but must be able to understand it. 23. ADM-STREAM-BIND Message: This message is sent by CONFD immediately after releasing the control stream of a module. This stream is then assigned by the module to the configurator CONFD. 24. ADM-STREAM-ACK Message: This message is returned from the module to the configurator if the request for type 23 message is accepted. 25. ADM-STREAM-NACK message: This message is returned from the module to the configurator CONFD if the request indicated by the 23-type message is denied. 26. ADM-STREAM-OPEN Message: This message is sent from a module to the configurator on the ADM STREAM to request another module to stream a new link. For example, the case where a stream link is created between the layers C4 and C3 of the OSI model corresponds to this. This link needs to be created dynamically as specified in the standard. 27. ADM-STREAM-CLOSE message: This message is sent from a module to the configurator CONFD to request disconnection of a module. In the OSI model, this corresponds to, for example, the case of the layer C4 (called COTP layer) that requests disconnection of the layer C3 (called CLNP layer), that is, the disconnection of the stream link between the layers. 28. ADM-STREAM-ERROR message: This message is sent from the configurator CONFD to the module to which the configurator is contacted if an error occurs while sending the request issued by the ADM-STREAM-OPEN message (26 type message). . 29. M-IOCTLI-LINK message: This message is sent by the configurator in response to the module to which the configurator is queried if no errors occurred while sending the request corresponding to the type 26 message. 30. M-IOCTLI-UNLINK message: This message is sent from the configurator to the module to which the configurator is inquired when no error occurs while transmitting the request corresponding to the ADM-STREAM-CLOSE message (27-type message). Sent in response. 31. M-IOCACK message: This message is sent from the module to the configurator after sending the request corresponding to any one of the messages defined in 29 or 30. 32. M-IOCNACK message: This message is sent from the module to the configurator after sending the request corresponding to any one of the 29 or 30 type messages. This message corresponds to a negative response. With reference to Appendix 2, it can be seen that the configuration message package is valid for OSI type layer piles. In the case of the IPS type pile, only the ADM-SUBSYSTEM-ID message is used when the communication processor is initialized. The ADM-SUBSYSTEM-ID message is only sent from the configurator CON FD to the IAM (a special internal module which acts as a management interface between the layers C3 and C4 of the IPS type pile and the management commands issued by the management antenna). . This module is structurally the management interface of the layer package of the module MIPS. For the configuration on the FDDI network, we use the known SMT-type standardized messages. In addition, Appendixes 3, 4, 5, and 6 show an outline of what has been described in the description of each message above. For example, Appendix 3 shows a configuration message package defined according to various situations. The vertical line in the middle of the figure shows the configurator CONFD, and the envisaged entities, namely the management entities of layer C4 or C3 of any of the modules of MOSI, MIPS, MDIWS, are shown by the vertical lines on the right side of the figure. The message is indicated by an arrow, and the direction of the arrow indicates the direction in which the message is sent. For example, by reading the top part of Appendix 3, the ADM-STREAM-OPEN message sent from the entity to CONFD, the M-IO CTLI-LINK message sent from the configurator to the entity, and the entity to succeed in the request to create a new link. It can be seen that the M-IOCACK messages sent to the configurator are used one after another. It can be seen that the readings of Appendix 3 and the other appendices are exactly the same as the above description for the top of Appendix 3. Appendix 4 shows the exchange of messages between the module IMD and any entity, and describes almost all packages of management messages described above. Appendix 5 describes two messages that are passed between the module IMD and any entity when the message sent by the IMD is not accepted by the layer entity due to an error that prevents the message from being processed correctly. There is. Appendix 6 shows the exchange of messages between the CONFD, IMD and PILE entities during initialization.
Claims (1)
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR93/13282 | 1993-11-08 | ||
FR9313282A FR2712411B1 (en) | 1993-11-08 | 1993-11-08 | Communication system with a network including a set of administration. |
PCT/FR1994/001275 WO1995013676A1 (en) | 1993-11-08 | 1994-11-04 | Communication system with a network comprising an administrative unit |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH09500750A true JPH09500750A (en) | 1997-01-21 |
JP2888642B2 JP2888642B2 (en) | 1999-05-10 |
Family
ID=9452626
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP7513623A Expired - Lifetime JP2888642B2 (en) | 1993-11-08 | 1994-11-04 | Communication system with network including management package |
Country Status (6)
Country | Link |
---|---|
US (1) | US5793958A (en) |
EP (1) | EP0728392B1 (en) |
JP (1) | JP2888642B2 (en) |
DE (1) | DE69427198T2 (en) |
FR (1) | FR2712411B1 (en) |
WO (1) | WO1995013676A1 (en) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6405254B1 (en) * | 1996-01-03 | 2002-06-11 | Sterling Commerce, Inc. | System and method for protocol conversion using facilities and utilities |
JP3137009B2 (en) * | 1996-10-25 | 2001-02-19 | 日本電気株式会社 | Network multi-tier management system |
US8255680B1 (en) | 1997-06-26 | 2012-08-28 | Oracle America, Inc. | Layer-independent security for communication channels |
GB2332335A (en) * | 1997-12-10 | 1999-06-16 | Northern Telecom Ltd | Network management system |
DE19809398A1 (en) * | 1998-03-05 | 1999-09-09 | Sel Verteidigungssysteme Gmbh | Common operation of a number of military communication systems |
US6976080B1 (en) * | 1998-03-27 | 2005-12-13 | Hewlett-Packard Development Company, L.P. | Multiple-protocol communication subsystem controller |
US6772413B2 (en) | 1999-12-21 | 2004-08-03 | Datapower Technology, Inc. | Method and apparatus of data exchange using runtime code generator and translator |
US6996510B1 (en) * | 2000-01-21 | 2006-02-07 | Metasolv Software, Inc. | System and method for modeling communication networks |
US6671724B1 (en) | 2000-03-21 | 2003-12-30 | Centrisoft Corporation | Software, systems and methods for managing a distributed network |
US7260635B2 (en) * | 2000-03-21 | 2007-08-21 | Centrisoft Corporation | Software, systems and methods for managing a distributed network |
US7738688B2 (en) * | 2000-05-03 | 2010-06-15 | Aperio Technologies, Inc. | System and method for viewing virtual slides |
US20020143969A1 (en) * | 2001-03-30 | 2002-10-03 | Dietmar Loy | System with multiple network protocol support |
US8935739B1 (en) | 2010-01-22 | 2015-01-13 | Gainespeed, Inc. | Distributed CCAP cable modem termination system |
US9584869B2 (en) | 2010-01-22 | 2017-02-28 | Gainspeed, Inc. | Virtual CCAP cable modem termination system with software reconfigurable MAC |
US9887855B2 (en) | 2010-01-22 | 2018-02-06 | Alcatel-Lucent Usa, Inc. | Virtual converged cable access platforms for HFC cable networks |
US8311412B2 (en) * | 2010-01-22 | 2012-11-13 | Selim Shlomo Rakib | Distributed cable modem termination system |
US8644706B2 (en) | 2010-01-22 | 2014-02-04 | Gainspeed, Inc. | Distributed cable modem termination system with software reconfigurable MAC and PHY capability |
CN102845024B (en) * | 2011-03-19 | 2015-06-17 | 加速有限公司 | Distributed cable modem termination system |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0463764A2 (en) * | 1990-06-28 | 1992-01-02 | Digital Equipment Corporation | Common agent computer management system and method |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5613100A (en) * | 1989-09-12 | 1997-03-18 | Nec Corporation | Computer system having an open systems interconnection (OSI) management system for an information conversion for management of non-open systems |
US5317568A (en) * | 1991-04-11 | 1994-05-31 | Galileo International Partnership | Method and apparatus for managing and facilitating communications in a distributed hetergeneous network |
US5491822A (en) * | 1993-12-30 | 1996-02-13 | International Business Machines Corporation | Multi-phase commit processing for creation and deletion of managed objects |
-
1993
- 1993-11-08 FR FR9313282A patent/FR2712411B1/en not_active Expired - Fee Related
-
1994
- 1994-11-04 EP EP95900188A patent/EP0728392B1/en not_active Expired - Lifetime
- 1994-11-04 JP JP7513623A patent/JP2888642B2/en not_active Expired - Lifetime
- 1994-11-04 US US08/624,416 patent/US5793958A/en not_active Expired - Lifetime
- 1994-11-04 WO PCT/FR1994/001275 patent/WO1995013676A1/en active IP Right Grant
- 1994-11-04 DE DE69427198T patent/DE69427198T2/en not_active Expired - Lifetime
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0463764A2 (en) * | 1990-06-28 | 1992-01-02 | Digital Equipment Corporation | Common agent computer management system and method |
Also Published As
Publication number | Publication date |
---|---|
DE69427198D1 (en) | 2001-06-13 |
FR2712411B1 (en) | 1995-12-22 |
FR2712411A1 (en) | 1995-05-19 |
EP0728392B1 (en) | 2001-05-09 |
WO1995013676A1 (en) | 1995-05-18 |
US5793958A (en) | 1998-08-11 |
JP2888642B2 (en) | 1999-05-10 |
DE69427198T2 (en) | 2001-08-23 |
EP0728392A1 (en) | 1996-08-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH09500750A (en) | Communication system with network including management package | |
US5517622A (en) | Method and apparatus for pacing communications in a distributed heterogeneous network | |
Zitterbart et al. | A model for flexible high-performance communication subsystems | |
AU2005307171B2 (en) | Network management apparatus and method based on simple network management protocol | |
US5519875A (en) | Distributed processing system for modules, each having modularized objects | |
US20020198967A1 (en) | Configuration parameter sequencing and sequencer | |
US20020138659A1 (en) | Method and system for application development and a data processing architecture utilizing destinationless messaging | |
EP0648354A1 (en) | System for implementation-independent interface specification | |
CN101466109B (en) | Communication system and method for WiMAX network management | |
US6021430A (en) | Output interface method and system for enhanced data transfers via cooperative service interface | |
US6985921B2 (en) | Reliability and performance of SNMP status through protocol with reliability limitations | |
McClain | Handbook of networking & connectivity | |
JP2673045B2 (en) | Communication system with network | |
Green et al. | A perspective on advanced peer-to-peer networking | |
Kristol et al. | A polynomial algorithm for gateway generation from formal specifications | |
US20030033560A1 (en) | Method for analysing transmitted protocol data units | |
US20070130307A1 (en) | Selective activation of TCP/IP link and traffic | |
KR100281662B1 (en) | Subscriber Address Header Information Management Method in Telecommunication Network Management Element Layer | |
Jasud | The OSI Model: Overview on the Seven Layers of Computer Networks | |
Ryan et al. | Intel local network architecture | |
Petrenko | Evolution of Computer Networks: Theory and Experience. Proceedings of the Meeting, December 10-12, 1979 | |
Liu et al. | OSI remote procedure call: Standardization issues, design and implementation | |
Dinger et al. | ECSE: an efficient environment for layered communication protocols | |
Butrimenko et al. | Protocol Parameters and their Inter-Relations in X. 25. INWG 96.1 Sample Network Architecture | |
JP2002374284A (en) | Distribution transaction processing system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090219 Year of fee payment: 10 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100219 Year of fee payment: 11 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110219 Year of fee payment: 12 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120219 Year of fee payment: 13 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120219 Year of fee payment: 13 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130219 Year of fee payment: 14 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140219 Year of fee payment: 15 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
EXPY | Cancellation because of completion of term |