DE69427198T2 - Kommunikationssystem mit einem ein verwaltungsmodul einschliessendem netz - Google Patents

Description

• Die vorliegende Erfindung betrifft ein System zur Kommunikation mit einem Netz, das einen Kommunikationscode verwendet, der zu mehreren Modellen zur gegenseitigen Verbindung offener Systeme gehört, wobei das System eine Einheit für das Management der verschiedenen Codeschichten umfaßt. Sie läßt sich auf alle Netztypen, insbesondere vom Typ FDDI, der durch die ANSI unter dem Zeichen X3T9-5 und durch die ISO (Internationale Organisation für Normung) normiert wurde, anwenden.
• Die modernen Netze arbeiten gemäß mehreren Referenzmodellen, die sich bezüglich der Definition ihrer Architektur in Form von normierten Schichten ähnlich sind. Unter diesen Modellen sind die Modelle OSI (angelsächsische Abkürzung, die "offene Kommunikationssysteme" bedeutet), ISO/DSA und IPS die bekanntesten (es sei daran erinnert, daß das Modell IPS (angelsächsische Abkürzung, die "Internet-Protokollfolge" bedeutet) unter derselben Bezeichnung insbesondere die Untermodelle TCP, UDP, IP, ICMP einschließt. So gibt es im Modell OSI sieben verschiedene Aktivitätsschichten, wobei die unterste Schicht (Schicht 1) der physischen Übertragung der Signale entspricht und die oberste Schicht (Schicht 7) den durch die Anwendungsprogramme (einfache Anwendungen genannt) und die Anwender des betreffenden Netzes verwirklichten Funktionen entspricht.
• Systeme zur Kommunikation mit einem Netz sind beispielsweise in IEEE NETWORK: THE MAGAZINE OF COMPUTER COMMUNICATIONS, Bd. 2, Nr. 2, März 1988, NEW YORK US, Seiten 20-29 und im europäischen Patent EP 0463764 A2 beschrieben.
• In der heutigen Praxis sind die Systeme zur Kommunikation mit einem Netz durch die Verbindung eines Rechners, auch Host- System genannt, mit einem Kommunikationsprozessor gebildet. Der Zweck des Kommunikationsprozessors besteht im Ausführen eines Teils der Steuerung der Kommunikation mit den anderen Datenendeinrichtungen des Netzes. Deshalb übernimmt er das Management der unteren Schichten eines jeden Referenzmodells.
• Ein solches Kommunikationssystem ist beispielsweise im französischen Patent FR-A-2 702 578, das am 12.03.93 unter dem Titel "Systéme de communication avec un réseau" von der anmeldenden Gesellschaft eingereicht wurde, oder auch im französischen Patent FR-A-2 708 116, das am 21.07.93 unter dem Titel "systéme de communication avec un reseau et protocole d'accés au fournisseur de transport appartenant à ce systéme" von der anmeldenden Gesellschaft eingereicht wurde, beschrieben. Diese zwei Patentanmeldungen beschreiben insbesondere die Softwarestruktur eines solchen Kommunikationssystems. Eine Beschreibung der Hardwarestruktur eines solchen Systems läßt sich außerdem im französischen Patent FR-A-2 699 706 finden, dessen Titel "systéme de transmission de données entre un bus d'ordinateur et un réseau" lautet und das am 22.12.92 von derselben Anmelderin eingereicht wurde.
• Die stark vereinfachte allgemeine Struktur eines solchen Kommunikationssystems mit wenigstens einem Kommunikationsprozessor (ein solches Kommunikationssystem kann mehrere Kommunikationsprozessoren enthalten, die mit mehreren Netzen unterschiedlichen Typs kommunizieren können) ist in den Fig. 1a und 1b gezeigt.
• Ein solches, hier mit SCI bezeichnetes Kommunikationssystem verwendet mittels des Host-Systems HOST die oberen Schichten CH irgendeines der Referenzmodelle OSI, ISO/DSA, IPS (wobei sich das letztere sowohl im verbindungsorientierten Betrieb als auch im verbindungslosen Betrieb auf einen Netzdienst stützen kann: der verbindungsorientierte Betrieb, der mit der Abkürzung CONS, der angelsächsischen Abkürzung für Connected Oriented Network Service, bezeichnet wird, und der verbindungslose Betrieb, der mit der Abkürzung CNLS, der angelsächsischen Abkürzung für Connection Less Network Service, bezeichnet wird, stützen sich auf die ISO-Normen 9878 und 8202, den ersten betreffend, und 8473 und 9542, den zweiten betreffend, wobei diese Normen die zugeordneten Mechanismen und Protokolle für die Lenkung definieren).
• In den Fig. 1a und 1b sind als Beispiel die drei oberen Schichten C&sub5; bis C&sub7; des Modells OSI gezeigt. Die Schichten CH kommunizieren mit den unteren Schichten CB, also C&sub4; bis C&sub2; derselbigen Modelle. Diese Schichten können von einem oder mehreren Kommunikationsprozessoren verwendet werden. In Fig. 2 wird angenommen, daß SCI aus dem Host HOST gebildet ist, der den Kommunikationsprozessoren PCi, PCj zugeordnet ist, die unterschiedlichen Typs sein können, wobei beiden gemeinsam ist, daß sie die unteren Schichten CB verwenden. Der Prozessor PCi ist mit einem Netz REi verbunden, während PCj mit einem Netz REj verbunden ist, wobei diese beiden letzteren Netze unterschiedlichen Typs sein können. Im übrigen können sowohl PCi als auch PCj Transportschichten verwenden, die sich entweder auf einen Netzdienst im verbindungsorientierten Betrieb RCONS (Modell ISO/DSA oder TCP) oder auf einen Netzdienst im verbindungslosen Betrieb RCLNS (Modell UDP) stützen.
• In Fig. 1b kommunizieren die Schichten CH von MOST mit den unteren Schichten CB, die von mehreren Kommunikationsprozessoren vom Typ NCC, nämlich NCC&sub1;, NCC&sub2;, NCCk verwendet werden, die mit Netzen RE&sub1;, RE&sub2;, Rk verbunden sind, die entweder gleichartig oder verschiedenartig sein können, wobei sich die Transportschichten entweder auf Netzdienste im verbindungsorientierten Betrieb oder auf Netzdienste im verbindungslosen Betrieb stützen können.
• Der Host HOST enthält ein Betriebssystem SE, das die oberen Schichten CH verwendet, während die Kommunikationsprozessoren PCi, PCj in Fig. 1a und NCC&sub1; in Fig. 1b jeweils die Betriebssysteme SEi, SEj, SE&sub1; enthalten. Ein Beispiel für ein Betriebssystem von Kommunikationsprozessoren wie etwa PCi, PCj, NCC&sub1; ist beispielsweise in dem französischen Patent FR-A-2 679 351 beschrieben, das am 15.07.91 unter dem Titel "Systéme d'exploitation pour dispositifuniversel de couplage dun bus d'ordinateur à une liaison spécifique dun réseau" von der Anmelderin eingereicht wurde.
• Das Kommunikationssystem SCI enthält Mittel zum Zugriff auf den Transportleister der Schicht C&sub4;, der dem unteren Abschnitt der oberen Schichten CH, der hier im unteren Abschnitt der Schicht C&sub5; angeordnet ist, die Kommunikation mit dem oberen Abschnitt der Schicht C&sub4; ermöglicht. Diese Zugriffsmittel sind in der oben erwähnten Anmeldung Nr. 93 08968 beschrieben und werden hier nur zusammengefaßt:
• - Host-Seite, ein Modul TPAM, das zu einem Telekommunikationsserver gehört, der als Schnittstelle zwischen der Gesamtheit der oberen Schichten CH und dem Verbindungskanal zwischen dem Host HOST und dem oder den Kommunikationsprozessoren dient,
• - auf seiten der Kommunikationsprozessoren durch eine Schnittstelle HI, die ebenfalls in derselben Anmeldung beschrieben ist, oder durch jegliche Schnittstellen, die eine zu HI gleichwertige Funktion ausüben,
• - Zugriffseinheiten, die insgesamt mit TPA bezeichnet werden und sowohl in Fig. 1a als auch in Fig. 1b durch ein gestricheltes Rechteck angedeutet sind, die den unteren Abschnitt der Schicht C&sub5; und den oberen Abschnitt der Schicht C&sub4; verbinden.
• In Fig. 1a wird angenommen, daß der physische Transport der Daten zwischen dem unteren Abschnitt der oberen Schichten CH und dem oberen Abschnitt der Transportschicht C&sub4; über irgendeinen sicheren Kanal erfolgt, der keinen Nachrichtenverlust zuläßt, während in Fig. 1b dieser Transport beispielsweise über einen Bus vom Typ MULTIBUS II ausgeführt wird, der hier PSB (Norm IEEE 1296) genannt wird.
• In jedem Kommunikationssystem oder genauer in jedem Kommunikationsprozessor muß der Anwender zu jedem Zeitpunkt den Zustand, in dem sich jede der Schichten des Kommunikationscodes und selbst jedes der in den Kommunikationsschichten liegenden Objekte befinden, kennen.
• Es sei daran erinnert, daß ein zu einer Schicht des Kommunikationscodes gehörendes Objekt durch eine Gesamtheit von Funktionalitäten gebildet ist, die dasselbe Ziel verfolgen: so ist beispielsweise die Gesamtheit der Funktionalitäten, die zur Definition einer Verbindung dient, ein Objekt. Physisch besteht ein Objekt aus einer Datentabelle, die sich im Speicher befindet, oder aus einer Gesamtheit von Datentabellen.
• Ein Attribut oder auch ein Parameter definiert ein Merkmal eines Objekts. Ein Objekt könnte folglich durch eine Gesamtheit von Attributen definiert sein. Eine Gesamtheit von Attributen, wovon jedes einen Wert besitzt, wird auch als Objektinstanz bezeichnet. Der Zustand eines Objekts oder einer Schicht eines Kommunikationscodes hängt vom Zeitpunkt, zu dem er betrachtet wird, ab. Die Schicht kann sich im Zustand der Kommunikation mit anderen Schichten befinden oder auch im Zustand der Konfigurierung oder der Initialisierung sein. Um nämlich zu jedem Zeitpunkt zu wissen, wie weit alle Objekte oder alle Kommunikationsschichten sind, enthält jedes Kommunikationssystem im allgemeinen eine Management-Einheit, die ihm die Kenntnis des Zustands ermöglicht, in dem sich alle Schichten oder alle Objekte einer Schicht befinden.
• Dies ist genau der Gegenstand der vorliegenden Erfindung, nämlich die Definition einer solchen Management-Einheit für jedes Kommunikationssystem wie etwa jene, die in den Fig. 1a und 1b gezeigt sind.
• Gemäß der Erfindung ist das Kommunikationssystem mit einem Netz, das einen Kommunikationscode verwendet, der zu mehreren Modellen zur gegenseitigen Verbindung offener Systeme gehört, wobei die Arbeit des Systems durch wenigstens ein Betriebssystem organisiert wird, dem mehrere Anwendungen zugeordnet sind und dessen Ziel es ist, für die Anwendungen notwendige Daten in das Netz zu senden oder vom Netz zu empfangen, wobei das System eine Einheit für das Management der verschiedenen Schichten umfaßt, dadurch gekennzeichnet, daß diese Einheit enthält:
• - einen Konfigurator, der bei der Initialisierung des Systems den Stapel der verschiedenen Schichten durch Verbindungen zwischen ihnen vom Typ STREAMS aufbaut,
• - ein Management-Modul, das den Zugriff auf alle auf das Management bezogenen Informationen in allen Codeschichten ermöglicht,
• - eine erste Management-Schnittstelle zwischen dem Management-Modul und Management-Entitäten der Schichten, die sich in diesen befinden,
• - eine zweite Management-Schnittstelle zwischen dem Konfigurator einerseits und den verschiedenen Entitäten und dem Management-Modul anderseits.
• Weitere Merkmale und Vorteile der vorliegenden Erfindung werden deutlich in der folgenden Beschreibung, die anhand eines nicht beschränkenden Beispiels gegeben wird, und sich auf die beigefügte Zeichnung bezieht.
• In dieser Zeichnung:
• erinnert Fig. 1, die aus den Fig. 1a und 1b zusammengesetzt ist, an die verschiedenen Hauptbestandteile eines Kommunikationssystems, auf das sich die Erfindung anwenden läßt.
• zeigt Fig. 2 die Gesamtheit der im Kommunikationsprozessor enthaltenen Softwaremodule, wobei diese Gesamtheit die Management-Einheit enthält, die für das System gemäß der Erfindung spezifisch ist.
• zeigt Fig. 3 in allgemeinerer Weise die Struktur eines beliebigen Kommunikationssystems gemäß der Erfindung.
• zeigt Fig. 4 die Struktur einer Nachricht, die für die Management-Einheit, die zum Kommunikationssystem gemäß der Erfindung gehört, spezifisch ist.
• zeigt Fig. 5 die interne Struktur aller Management-Module, die zur Management-Einheit des Kommunikationssystems gemäß der Erfindung gehören.
• Es wird Bezug auf Fig. 2 genommen.
• Diese Figur zeigt die bereits in irgendeiner der drei oben zitierten Patentanmeldungen beschriebene Kommunikationssoftwareeinheit ELC, die beispielsweise zu einem der Kommunikationsprozessoren NCC&sub1;, NCC&sub2;, NCC&sub3; gehört. Diese Softwareeinheit ELC bildet einen Teil des erfindungsgemäßen Kommunikationssystems, das in derselben Weise wie in Fig. 1 bezeichnet wird, nämlich mit SCI.
• Die Einheit ELC umfaßt:
• - einen Kommunikationscode CC, der beispielsweise drei Stapel von Kommunikationsschichten umfaßt, die zu den verschiedenen Referenzmodellen, nämlich dem Modell OSI, dem Modell ISO/DSA und dem Modell IPS, gehören. Diese verschiedenen Module werden MOSI, MDIWS bzw. MIPS genannt. Sie beziehen sich genauer auf die Schichten C&sub4; und C&sub3;. Der Kommunikationscode umfaßt außerdem die die Schicht C&sub2;, auch LLC&sub1; genannt, die den drei Modulen MOSI, MDIWS, MIPS gemeinsam ist.
• - die Schnittstelle HI zwischen dem Kommunikationsserver NCCD, der zum Host-System HOST gehört, und den unteren Schichten CB, die hier durch die drei Module MOSI, MDIWS, MIPS repräsentiert werden. Die Funktion von HI und von NCCD ist in den oben erwähnten Anmeldungen 93 02902 und 93 08968 genauer beschrieben.
• - die Schnittstelle HIN, die bereits in irgendeiner der drei oben erwähnten Patentanmeldungen beschrieben ist, ermöglicht die Kommunikation zwischen der Schnittstelle HI und der Schicht C&sub2; mit dem Betriebssystem GPOS des Kommunikationsprozessors, der zum erfindungsgemäßen Kommunikationssystem SCI gehört.
• - das Konfigurationsmodul CONFD, dessen Funktion oben präzisiert wurde,
• - das Management-Modul IMD, dessen Funktion ebenfalls oben präzisiert wurde,
• - eine erste Management-Schnittstelle LMAI&sub1;, die zwischen dem Konfigurator CONFD und jedem der Kommunikationsmodule MOSI, MDIWS, MIPS angeordnet ist,
• - eine zweite Management-Schnittstelle LMAI&sub2;, die eigentlich aus zwei identischen Management-Schnittstellen, nämlich LMAI&sub2;&sub1; und LMAI&sub2;&sub2;, die die Schnittstelle zwischen dem Management-Modul IMD und jedem der drei Kommunikationsmodule MOSI, MDIWS, MIPS einerseits und mit der Schnittstelle HI anderseits wahrnehmen, zusammengesetzt ist.
• Die Verbindung zwischen dem Konfigurator CONFD und der ersten Management-Schnittstelle LMAI&sub1; einerseits und die Verbindungen zwischen der letzteren und jedem der drei Module MOSI, MDIWS und MIPS erfolgt durch Verbindungen vom Typ "STERAMS", die genauer ADM STREAMS genannt werden. Die Verbindungen zwischen dem Management-Modul IMD und jeder der zwei Schnittstellen LMAI&sub2;&sub1;, LMAI&sub2;&sub2; sowie die Verbindungen zwischen den zwei letzteren Schnittstellen und den drei Kommunikationsmodulen MOSI, MDIWS und MIPS einerseits und der Schnittstelle HI anderseits werden durch Verbindungen vom Typ "STREAMS", genauer IM STREAMS, als Verbindungen des Management-Typs ausgeführt.
• Im übrigen sei daran erinnert, daß die Kommunikationsschichten C&sub2;, C&sub3;, C&sub4; mittels primitiver Funktionen, die den Dialog zwischen zwei benachbarten Schichten ermöglichen, paarweise miteinander kommunizieren. So kommunizieren die Schichten C&sub2; und C&sub3; über die Menge ST&sub2; von Funktionen vom Typ STREAM miteinander, während die Schichten C&sub3; und C&sub4; über die Funktionsmenge ST&sub3; miteinander kommunizieren. Ferner kommuniziert C&sub4; mit der Schnittstelle HI über eine Funktionsmenge SH. Diese Funktionsmengen ST&sub2;, ST&sub3;, SH, ADM STREAM und IM STREAMS sind in den folgenden Dokumenten definiert:
• - Unix System V, release 4 - STREAM Programmer guide ATT issue 1,
• - Unix System V, release 3.2 - STREAM Programmer guide ATT (ISBN: 0-13-944810-1): 1989,
• Ferner umfaßt bei den Modellen OSI, ISO/DSA jede Kommunikationsschicht spezifische Management-Entitäten, die dazu dienen, die Management-Arbeit jeder Kommunikationsschicht, die zum Kommunikationscode CC gehört, zu organisieren. So umfaßt das Modul MOSI die Management-Entitäten LME&sub1;&sub1; und LME&sub1;&sub2;, die sich auf die Schichten C&sub4; bzw. C&sub3; beziehen, während das Modul MDIWS die Management-Entitäten LME&sub2;&sub1; und LME&sub2;&sub2; umfaßt, die sich auf die Schichten C&sub4; und C&sub3; beziehen. Das Modul MIPS umfaßt eine einzige, auf C&sub4; und C&sub3; bezogene Management-Schnittstelle IAM (siehe weiter unten). Die OSI und IPS gemeinsame Schicht C&sub2; besitzt die Management-Entität LME&sub4;.
• Fig. 3 zeigt die allgemeinere Struktur eines erfindungsgemäßen Kommunikationssystems SCI&sub1;, bei dem die zwei durch das Host- System HOST und den Kommunikationsprozessor NCC&sub1; gebildeten Entitäten zu einer einzigen Entität zusammengefaßt sind. Aus derselben Figur ist ersichtlich, daß sich ein Konfigurationsmodul CONFD, dessen Funktion jener in Fig. 2 exakt gleicht, ein Management-Modul IMD, dessen Funktion jener in Fig. 2 exakt gleicht, eine erste Management-Schnittstelle LMI&sub1;, deren Funktion mit der Management-Schnittstelle LMAI&sub1; in Fig. 2 übereinstimmt ist und eine zweite Management-Schnittstelle LMI&sub2;, deren Funktion mit jener der Management-Schnittstelle LMAI&sub2; in Fig. 2 streng übereinstimmt ist, wiederfinden lassen.
• So stellt die erste Management-Schnittstelle LMI&sub1; die Verbindung zwischen dem Konfigurationsmodul CONFD und jeder der Management-Entitäten der Schichten C&sub6; bis C&sub2; über Befehls- STREAM vom Typ ADM STREAM her. Die erste Schnittstelle stellt außerdem über einen STREAM, ADM STREAM, die Verbindung mit dem Management-Modul IMD her.
• Die zweite Management-Schnittstelle LMI&sub2; stellt die Verbindung zwischen dem Management-Modul IMD und jeder der Management- Entitäten der Schichten C&sub7; (Darstellungsschicht) bis C&sub2; über Verbindungen vom Typ IM STREAM her. Die Management-Entitäten der Schichten C&sub7; bis C&sub2; sind entsprechend mit ME&sub7; bis ME&sub2; bezeichnet. In Fig. 3 sind als Management-Entitäten der Schichten C&sub3;, die sich auf ein Netz beziehen, das im verbindungsorientierten (Connection Oriented) Modus bzw. im verbindungslosen Modus (Connection Less) Modus arbeitet, die Management-Entitäten ME&sub3;&sub1; und ME&sub3;&sub2; gezeigt. Die Verbindung zwischen ME&sub4; und sowohl ME&sub3;&sub1; als auch ME&sub3;&sub2; werden durch bekannte Verbindungen vom Typ STREAM hergestellt.
• Selbstverständlich ist die Arbeitsweise der Kommunikationssysteme SCI nach Fig. 2 und SCI&sub1; nach Fig. 3 völlig gleich.
• Sowohl in Fig. 2 als auch in Fig. 3 erzeugt jede Schichtmanagement-Entität, sowohl LME&sub1;&sub1; bis LME&sub2;&sub1;, LME&sub4; und IAM als auch die verschiedenen Entitäten ME&sub7; bis ME&sub2;, eine Menge von Objekten, wovon jedes durch mehrere Attribute beschrieben ist. Diese Objektmengen entsprechen den verschiedenen Standards, die die jeweiligen Referenzmodelle beschreiben, soweit es sich um die Modelle OSI, ISO/DSA oder auch IPS handelt. Im Kommunikationsprozessor oder im Kommunikationssystem SCI&sub1; lassen sich außerdem Standard-Steuerungsprotokolle wie etwa die Protokolle SNMP, CNMA oder auch OSI/NMFORUM implementieren.
• Das Modul IMD arbeitet in Verbindung mit dem Betriebssystem entweder des Kommunikationsprozessors oder des Kommunikationssystems SCI&sub1; in seiner Einheit und ist mit der Lenkung der Nachrichten zu oder von den Wartungs-, Konfigurations- und Management-Entitäten und -Werkzeugen betraut, die sich ebenfalls in diesen Schichten befinden. So konnte oben festgestellt werden, daß sich jeglicher Austausch zwischen den Management-Entitäten und dem Modul IMD auf Kommunikationen mittels der STREAM-Funktionen stützt.
• Die ersten und zweiten Management-Schnittstellen, also LMAI&sub1; oder LMAI&sub2; in Fig. 2, LMI&sub1; und LMI&sub2; in Fig. 3, definieren ihrerseits die Dialoge zwischen dem Modul IMD, dem Konfigurator CONFD und den verschiedenen Management-Entitäten der Schichten, die sich innerhalb der Kommunikationscodes befinden.
• Es sei von nun an Fig. 4 betrachtet, die die allgemeine Form einer Nachricht gemäß dem Standard STREAM zeigt, die für den Transport der primitiven Management-Funktionen verwendet werden, wobei eine Primitive die Richtung einer Nachricht definiert.
• Eine Nachricht enthält einen ersten, M-PROTO genannten Block, gegebenenfalls gefolgt von einem M-DATA genannten Block. Jede primitive Funktion ist aus einer spezifischen Datenstruktur, die Struktur C genannt wird, gebildet, gegebenenfalls gefolgt von einer Dateneinheit (angelsächsischer Begriff = buffer), die die ausgetauschten Management-Informationen enthält. Jede Datenstruktur C definiert den globalen Austausch von Informationen zwischen den Entitäten und dem Modul IMD. Diese Datenstruktur C ist im Block M-PROTO enthalten. Die Informationen, die der Primitiven, die die Richtung von dieser definiert, zugeordnet sind, werden in den Block M-DATA übertragen. M-PROTO und M-DATA sind in einem Format vom Typ ASN.1 codiert, um den Erfordernissen des Moduls IMD zu genügen. Der ASN.1- codierte Informationstyp ist folgender:
• - eine Zustandsliste, auch Statuslist genannt: diese Liste liefert die Zustände der verschiedenen Entitäten oder Objekte, die zu managen gewünscht wurde.
• - eine Param-list genannte Liste, die die Liste der verschiedenen Entitäten oder Objekte, die zu managen gewünscht wird, umfaßt.
• - eine Ident-list genannte Liste, die die Liste der Identitäten oder Bezeichner der Objekte umfaßt, von denen die Werte wiederzugewinnen gewünscht wird.
• Es wird nun Bezug auf Fig. 5 genommen, die die Hierarchie der verschiedenen Objekte zeigt. Ein Modulobjekt wie etwa ein Objekt eines Moduls wie etwa MOSI, MDIWS, MIPS enthält Schichtobjekte, d. h. entweder ein Objekt der Schicht 4 oder ein Objekt der Schicht 3, das mehrere Objekte enthält, die entweder Verbindungsobjekte oder Auswahlobjekte oder auch Objekte, die mit IVMO, der englischen Abkürzung für Initial Value Manage Object, bezeichnet werden, und folglich Objekte sind, die die Anfangswerte jedes Schichtenobjekts definieren.
• Ein Management-Modul oder eine Management-Entität wird durch eine ganze Zahl identifiziert, die SUBSYSTEM-id genannt wird. Für die im Betriebssystem enthaltenen Entitäten, ob diese nun im Betriebssystem des Kommunikationsprozessors oder allgemeiner im Betriebssystem eines Kommunikationssystems wie etwa SCI&sub1; existieren, wird die Identität durch den Konfigurator CONFD zum Zeitpunkt der Initialisierung vergeben. Das Modul IMD verwendet diese Identität, um die Nachrichten zum richtigen Modul oder zur Entität in einer Schicht zu senden.
• Ein gemanagtes Objekt wird durch die folgenden drei Felder identifiziert;
• - SUBSYSTEM-id: dieses Feld definiert die Identität des Moduls, das dieses gemanagte Objekt enthält.
• - OBJECT-type: diese Identität definiert den Management- Typ des Objekts.
• - OBJECT-name: Beim Modell OSI handelt es sich hier um eine Identität, die einen internen Namen angibt, der von dem das Objekt enthaltenden Modul vergeben wird, während es sich beim Modell IPS um eine ganze Zahl (0 bis n) handelt, die das Erkennen der (0 bis n) ersten in den Block M-DATA übertragenen Parametern ermöglicht, die besonderen Parametern entsprechen, die für die Ermittlung der Instanz des angeforderten Objekts verwendet werden (falls das Modul nicht benannt werden kann).
• Die Implementierung des Moduls setzt voraus, daß die in ihm enthaltenen gemanagten Objekte vom gleichen Typ verschiedene Namen haben.
• Die Parameter, die den von jeder Management-Schnittstelle (LMAI, LMI in den Fig. 2 und 3) gesendeten Primitiven gemeinsam sind, sind folgende:
• Die mit PRIM-name und PRIM-type bezeichneten Parameter identifizieren eine Anforderung von der Management-Schnittstelle oder eine Antwort.
• Der Parameter IM-userid wird vom Modul IMD geliefert und ermöglicht dem letzteren, eine korrekte Lenkung der Antwort zu derjenigen Entität, die die Anforderung geschickt hat, vorzunehmen. Selbstverständlich hat dieser Parameter unabhängig davon, ob es sich um die Anforderung oder die Antwort dreht, denselben Wert.
• Unter den Parametern, die allen auf die Management-Schnittstellen bezogenen Primitiven gemeinsam sind, finden sich gleichfalls die oben definierten Parameter SUBSYSTEM-id, OBJECT-type und OBJECT-name.
• Es gibt außerdem einen weiteren Parameter, der OBJECT-subtype genannt wird und zur Unterscheidung der Objekte verwendet wird, die vom gleichen Typ sind, jedoch nicht dieselben Management-Anforderungen unterstützen.
• Die Auswahlobjekte, die Verbindungsobjekte und die IVMO-Objekte betreffend repräsentiert das Objekt unmittelbar darüber dasjenige Objekt, das diese enthält. Es wird durch die folgenden drei Felder identifiziert:
• - SUBSYSTEM-upid ist die Identität der Entität, d. h. der Schicht, die das höhere Objekt enthält,
• - OBJECT-uptype ist der Management-Typ des höheren Objekts,
• - OBJECT-upname ist der Name des höheren Objekts.
• Es gibt zwei Arten von Nachrichten, die von den Modulen CONFD, IMD und LMAI&sub1;, LMAI&sub2;, LMI&sub1;, LMI&sub2; verwendet werden, nämlich einerseits die Management-Nachrichten und anderseits die Konfigurationsnachrichten.
• Zuerst seien die verschiedenen Management-Nachrichten betrachtet. Die Liste von diesen ist bezüglich der Management-Nachrichten in Anhang 1 und bezüglich der Konfigurationsnachrichten in Anhang 2 dargestellt. In jedem der beiden Anhänge werden in einer Spalte der Name der Nachricht und in den folgenden Spalten das Referenzmodell, also vom Typ OSI oder IPS oder auch vom Typ FDDI, zu dem die Nachricht gehört, dargestellt. In den beiden letzten Spalten von rechts werden außerdem der Name des Senders der Nachricht und der Name des Empfängers der Nachricht dargestellt.
• Die Management-Nachrichten, die von 1 bis 21 numeriert (vom Typ 1 bis 21) sind, sind folgende:
• 1. Nachricht ADM-BIND-LAYER-REQ:
• Diese Nachricht ist eine Anforderungsnachricht, die vom Modul IMD an eine Management-Entität mit der Absicht, den Dialog zwischen der letzteren und diesem Modul zu initialisieren, gesendet wird. Dies ist die erste vom betreffenden Modul an die Entität gesendete Nachricht. Die Entität antwortet, indem sie eine ADM-BIND-OBJ-IND genannte Nachricht (oder mehrere) sendet, die angibt, welchen Objekttyp die betreffende Entität managt. Sobald die Entität diejenige Menge der Nachrichten ADM-BIND-OBJ-IND, die der Menge der von ihr gesteuerten Objekte entspricht, an IMD geschickt hat, sendet sie ein Nachricht ADM-OK-ACK an IMD, um diesem das Ende ihrer Nachricht anzuzeigen. Vor dem Empfang dieser Quittierungsnachricht kann vom Modul IMD keine weitere Nachricht an eine Management- Entität gesendet werden. Diejenige Entität, die die Anforderungsnachricht empfängt, stellt dann eine Verbindung vom Typ STREAM mit Management-Informationen her.
• 2. Nachricht ADM-BIND-OBJ-IND:
• Diese Nachricht wird von der Management-Entität, an die sich das Modul IMD wendet, als Antwort auf das Vorhergehende zurückgesendet. Sie wird über eine Funktion STREAM vom Typ IM-STREAMS gesendet. Die Management-Entität sendet eine einzige Nachricht dieser Artpro gemanagtem Objekttyp.
• 3. Nachricht ADM-OK-ACK:
• Diese Nachricht beendet den Initialisierungsdialog zwischen dem Modul IMD und der Management-Entität. Sie wird über einen IM-Streams nach einer oder mehreren Nachrichten vom Typ 2 in Antwort auf die Nachricht vom Typ 1 gesendet.
• Diese Nachricht kann außerdem verwendet werden, um dem Modul IMD anzugeben, daß eine zuvor gesendete Nachricht von einer Management-Entität erfolgreich empfangen wurde, sofern für diese keine andere Antwort definiert ist.
• 4. Nachricht ADM-ERROR-ACK:
• Diese Nachricht gibt IMD an, daß eine zuvor gesendete Nachricht von einer Management-Entität nicht erfolgreich empfangen wurde und aufgrund eines Fehlers des Systems nicht bearbeitet werden kann. Diese Nachricht gibt die Fehlerursachen an. Der Empfang dieser Nachricht gibt IMD ferner an, daß bezüglich der Nachricht, die diese negative Antwort hervorgerufen hatte, keine Aktion unternommen wurde.
• 5. Nachricht ADM-LIST-REQ:
• Diese Nachricht wird von dem im Feld OBJECT-type spezifizierten Modul gesendet.
• Für die Verbindungs-, Auswahl- und IVMO-Objekte liefert sie den Namen der Objekte, deren Typ im Feld OBJECT-type spezifiziert ist und die dem durch die Felder OBJECT-uptype und OBJECT-upname, SUBSYSTEM identifizierten Schichtobjekt zugeordnet sind.
• 6. Nachricht ADM-LIST-ACK:
• Diese Nachricht wird von einer PILE-Entität (PILE = Schichtstapel) an das Modul IMD als Antwort auf seine Nachricht vom Typ 5 gesendet. Sie vergibt an die Objektinstanzen für einen gegebenen Objekttyp die Liste der Management- Namen.
• 7. Nachricht ADM-GET-REQ:
• Diese Nachricht wird vom IMD gesendet, um von einer gemanagten Entität das Zurücksenden des Werts der Attribute einer Objektinstanz anzufordern. Wenn eine Attributliste geliefert wird, muß die Liste der Werte der Attribute an den Modul IMD zurückgeschickt werden. Wenn keine Liste geliefert wird, müssen sämtliche Attributwerte zurückgesendet werden. Ein Fehler wird in der von der Management-Entität gelieferten Antwort angegeben, sobald irgendein Attribut nicht gelesen werden kann.
• 8. Nachricht ADM-GET-ACK:
• Diese Nachricht wird von der Management-Entität an IMD als Antwort auch die vorhergehende Nachricht vom Typ 7 gesendet. Sie sendet die angeforderten Attributwerte der Objektinstanz zurück. Ein Fehler wird angezeigt, wenn wenigstens ein Attribut nicht gelesen werden kann.
• 9. Nachricht ADM-GETNEXT-REQ:
• Durch diese Nachricht kann eine Management-Entität Attribute von allen Instanzen eines Objekts erhalten, ohne den Namen dieser Instanzen zu kennen. Es ist also nicht erforderlich, eine Nachricht vom Typ 5 zu senden, um den Namen der Objektinstanz zu erhalten. Die Liste der Objektnamen wird von der Entität in einer beliebigen Reihenfolge gehandhabt, wobei diese Reihenfolge von ihrer Implementierung in der Schicht abhängt.
• 10. Nachricht ADM-GETNEXT-ACK:
• Diese Nachricht wird von einer Management-Entität als Antwort auf die Nachricht vom Typ 9 gesendet. Sie sendet an das Modul den angeforderten Wert der Objektattribute zurück. Ein Fehler wird angezeigt, wenn diese Attribute nicht gelesen werden können.
• 11. Nachrichten ADM-SET-REQ:
• Diese Nachricht wird von IMD an eine Management-Entität über einen IM STREAM gesendet. Sie ermöglicht die Vergabe eines neuen Werts an die Attribute einer Objektinstanz. Diese Operation läßt sich auf Attribute anwenden, die so definiert sind, daß sie geschrieben werden können. Ihre in dem Abschnitt M-DATA gelieferte Liste enthält die Identitäten der Attribute und zugeordneten Werte, die den Attributwerten gegeben werden, die ersetzt werden müssen.
• 12. Nachrichten ADM-SET-ACK:
• Diese Nachricht wird von einer Management-Entität als Antwort auf eine vorhergehende Nachricht vom Typ 11 gesendet. Sie gibt an, ob die von der Nachricht vom Typ 11 angeforderte Operation zur Änderung des Werts der Attribute erfolgreich war oder nicht.
• 13. Nachrichten ADM-TEST-REQ:
• Diese Nachricht wird von IMD an die Management-Entitäten gesendet. Sie ermöglicht die Überprüfung, ob der Wert mehrerer Attribute einer Objektinstanz gleichzeitig modifiziert werden kann, um einen neuen Wert haben. Die Attributwerte werden durch diese Nachricht nicht modifiziert.
• 14. Nachricht ADM-TEST-ACK:
• Diese Nachricht ist eine Quittierungsnachricht, die von einer Management-Entität als Antwort auf eine vorhergehende Nachricht vom Typ 13 gesendet wird.
• 15. Nachricht ADM-ACTION-REQ:
• Diese Nachricht wird von IMD an die Management-Entitäten gesendet. Die Funktionen dieser Nachricht hängen vom Aktionstyp ab, der im Feld PRIM-type angegeben wird.
• 16. Nachricht ADM-ACTION-ACK:
• Diese Nachricht wird von einer Management-Entität als Antwort auf eine vorhergehende Nachricht vom Typ 15 gesendet und gibt den Erfolg oder den Mißerfolg jener Anforderung an.
• 17. Nachricht ADM-ADD-REQ:
• Diese Nachricht fordert von einer Management-Entität die Erzeugung einer neuen Objektinstanz an. Sie ist nicht für alle Objekttypen zugelassen. Für die Erzeugung eines Objekts ist eine bestimmte Anzahl von Attributen des Objekts erforderlich, die in der Anforderung geliefert werden müssen. Der Name des Objekts, das erzeugt werden muß, wird vom Modul, das dieses managt, geliefert. Dieser Name wird in der Antwort auf die durch diese Nachricht gebildete Anforderung geliefert.
• 18. Nachricht ADM-ADD-ACK:
• Diese Nachricht wird von einer Management-Entität als Antwort auf eine vorhergehende Nachricht vom Typ 17 gesendet und ermöglicht die Quittierung im Fall eines Erfolgs der Anforderung.
• 19. Nachricht ADM-REMOVE-REQ:
• Diese Nachricht fordert von einer Management-Entität das Löschen einer Objektinstanz an.
• 20. Nachricht ADM-REMOVE-ACK:
• Diese Nachricht wird von einer Management-Entität als Antwort auf eine vorhergehende Nachricht vom Typ 19 gesendet, um den Erfolg oder den Mißerfolg der Anforderung, die dieser Nachricht vom Typ 19 entspricht, zu quittieren.
• 21. Nachricht ADM-EVENT-IND:
• Diese Nachricht gibt dem Modul IMD an, daß sich in der Schichtentität ein Ereignis abspielt. Das Management-Modul selbst gibt keine Quittierung aus, wenn es den Hinweis empfängt, daß in der besagten Schichtenentität ein Ereignis eingetreten ist.
• Wie im Anhang 1 zu sehen ist, wird die Gesamtheit der Nachrichten vom Typ 1 bis 21 beim Referenzmodell OSI oder ISO/DSA verwendet. Die Gesamtheit dieser Nachrichten wird mit Ausnahme der Nachrichten 5 und 6 auch beim Modell IPS verwendet.
• Beim FDDI-Netz werden ebenfalls die Nachrichten vom Typ 4 und 7 bis 21 verwendet.
• Die Identifikation der Objekte beim Referenzmodell IPS betreffend weist diese im Vergleich zur Identifikation beim Referenzmodell OSI einige besondere Aspekte auf.
• Das Feld OBJECT-type ist eine Klasse von Objekten, die aus Parametern zusammengesetzt ist. Ein IPS-Objekt ist durch sein Feld OBJECT-type und durch eine Instanz dieser Klasse definiert. Wenn es ein einfaches Objekt (Einfachinstanz) ist, ist die Identifikation einfach durch das Feld (OBJECT-type) gegeben. Eine Instanz ist durch die Auswahlparameterwerte definiert. Die letzteren, die eine Identifikation und einen Wert geben, werden in den Nachrichtenblock M-DATA der Anforderung übertragen.
• Das Feld OBJECT-name enthält die Anzahl von Parametern, die für die Auswahl verwendet werden. Falls erforderlich sind somit die ersten Instanzen des Nachrichtenblocks M-DATA Auswahlparameter.
• Die Nachrichtenblöcke M-DATA sind in ASN.1 codiert.
• Nun werden die verschiedenen, von 22 bis 32 numerierten Konfigurationsnachrichten (vom Typ 22 bis 32) betrachtet, die wie folgt lauten und in Anhang 2 erscheinen.
• Die Darstellung in Anhang 2 stimmt mit der Darstellung in Anhang 1 genau überein.
• Die verschiedenen Nachrichten sind folgende:
• 22. Nachricht ADM-SUBSYSTEM-ID:
• Diese Nachricht wird vom Konfigurator CONFD mit dem Öffnen eines jeden Moduls des Kommunikationsprozessors in Fig. 2 oder von einem der Systemmodule SCI&sub1; in Fig. 3, gesendet, wobei diese entweder durch einen ADM STREAM oder durch einen IM STREAM übertragen wird. Jede beliebige Entität, die gemanagt zu werden wünscht, kann diese Nachricht verwerten und muß diese verstehen können.
• 23. Nachricht ADM-STREAM-BIND:
• Diese Nachricht wird von CONFD unmittelbar nach dem Öffnen des Befehls-"stream" eines Moduls gesendet. Dieser "stream" wird anschließend von dem besagten Modul für den Konfigurator CONFD bereitgestellt.
• 24. Nachricht ADM-STREAM-ACK:
• Diese Nachricht wird vom Modul zum Konfigurator geschickt, wenn die Anforderung der vorhergehenden Nachricht vom Typ 23 angenommen wurde.
• 25. Nachricht ADM-STREAM-NACK:
• Diese Nachricht wird vom Modul zum Konfigurator CONFD geschickt, wenn die Anforderung der Nachricht vom Typ 23 abgelehnt wurde.
• 26. Nachricht ADM-STREAM-OPEN:
• Diese Nachricht wird von einem Modul über einen ADM STREAM zum Konfigurator geschickt, um eine neue Verbindung vom Typ "Stream" mit einem anderen Modul anzufordern. Dies ist beispielsweise bei der Herstellung einer "Streams"-Verbindung zwischen der Schicht C&sub4; und der Schicht C&sub3; des Modells OSI der Fall. Diese Verbindung ist dynamisch aufzubauen, wie dies die Normen vorsehen.
• 27. Nachricht ADM-STREAM-CLOSE:
• Diese Nachricht wird von einem Modul zum Konfigurator CONFD geschickt, um das Trennen eines Moduls anzufordern. Dies ist beispielsweise beim Modell OSI der Fall, wenn eine Schicht C&sub4; (COTP genannte Schicht) die Trennung von einer Schicht C&sub3; (CLNP genannte Schicht), d. h. die Unterbrechung der gegenseitigen "Streams"-Verbindung, anfordert.
• 28. Nachricht ADM-STREAM-ERROR:
• Diese Nachricht wird vom Konfigurator CONFD an dasjenige Modul gesendet, an das sich der Konfigurator wandte, wenn sich während des Sendens einer von der Nachricht ADM-STREAM-OPEN (Nachricht vom Typ 26) gelieferten Anforderung ein Fehler ereignete.
• 29. Nachricht M-IOCTLI-LINK:
• Diese Nachricht wird vom Konfigurator als Antwort an dasjenige Modul gesendet, an das sich der Konfigurator wandte, wenn sich während des Sendens der Anforderung, die der Nachricht vom Typ 26 entspricht, kein Fehler ereignete.
• 30. Nachricht M-IOCTLI-UNLINK:
• Diese Nachricht wird vom Konfigurator als Antwort an dasjenige Modul gesendet, an das sich der Konfigurator wandte, wenn während des Sendens der Anforderung, die der Nachricht ADM- STREAM-CLOSE (Nachricht vom Typ 27) entspricht, kein Fehler auftrat.
• 31. Nachricht M-IOCACK:
• Diese Nachricht wird vom Modul nach dem Senden einer Anforderung, die einer der beiden unter 29 und 30 definierten Nachrichten entspricht, zum Konfigurator zurückgeschickt
• 32. Nachricht M-IOCNACK:
• Diese Nachricht wird vom Modul nach dem Senden einer Anforderung, die einer der beiden unter 29 und 30 definierten Nachrichten entspricht, zum Konfigurator zurückgeschickt. Sie entspricht einer negativen Quittierung.
• Bei Betrachtung des Anhangs 2 wird ersichtlich, daß die Gesamtheit von Konfigurationsnachrichten für einen Schichtenstapel vom Typ OSI gültig ist. Für einen Stapel vom Typ IPS wird nur die Nachricht ADM-SUBSYSTEM-ID bei der Initialisierung des Kommunikationsprozessors verwendet.
• Die Nachricht ADM-SUBSYSTEM-ID wird vom Konfigurator CONFD lediglich an IAM (spezifisches internes Modul, das als Management-Schnittstelle zwischen den Schichten C&sub3; und C&sub4; des Stapels vom Typ IPS und den von der Management-Antenne gelieferten Management-Befehlen dient) gesendet.
• Dieses interne Modul repräsentiert konstruktionsbedingt die Management-Schnittstelle sämtlicher Schichten des Moduls MIPS.
• Die Konfiguration für das FDDI-Netz betreffend werden normierte Nachrichten des bekannten Typs SMT verwendet.
• Ferner fassen die Anhänge 3, 4, 5, 6 jenes zusammen, das oben bei der Beschreibung jeglicher Nachrichten gesagt wurde. So lassen sich den Anhang 3 betreffend sämtliche Konfigurationsnachrichten wiederfinden, die oben in Abhängigkeit von den verschiedenen Gegebenheiten definiert wurden. In diesem Anhang ist der Konfigurator CONFD durch eine senkrechte Linie, die sich im mittleren Abschnitt der Figur befindet, angedeutet, während die betrachtete Entität, d. h. beispielsweise eine Management-Entität einer der Schichten C&sub4; oder C&sub3; eines der Moduls MOSI, MIPS, MDIWS durch eine vertikale Linie angedeutet ist, die sich auf der rechten Seite der Figur befindet. Die Nachrichten sind durch Pfeile angedeutet, wobei die Richtung des Pfeils die Richtung angibt, in der die Nachricht gesendet wird. Bei Durchsicht des oberen Abschnitts von Anhang 3 wird beispielsweise ersichtlich, daß für einen Erfolg der Anforderung zur Herstellung einer neuen Verbindung nacheinander die Nachrichten ADM-STREAM-OPEN, die von der Entität an CONFD gesendet werden, die Nachricht M-IOCTLI-LINK, die vom Konfigurator an die Entität gesendet wird, und schließlich die Nachricht M-IOCACK, die von der Entität an den Konfigurator gesendet wird, verwendet werden. Selbstverständlich gilt für das Lesen des Anhangs 3 und der weiteren Anhänge dasselbe, was für den oberen Abschnitt von Anhang 3 angeführt wurde.
• Anhang 4 zeigt den Austausch von Nachrichten zwischen dem Modul IMD und einer beliebigen Entität, wobei sich dort praktisch die Gesamtheit aller obenbeschriebenen Management-Nachrichten wiederfinden.
• Anhang 5 beschreibt die zwei Nachrichten, die zwischen dem Modul IMD und einer beliebigen Entität ausgetauscht werden, wenn eine vom IMD gesendete Nachricht durch die Schichtentität aufgrund eines Fehlers, der die korrekte Verarbeitung der Nachricht verhindert, nicht angenommen wurde.
• Anhang 6 zeigt den Austausch von Nachrichten zwischen CONFD, IMD und einer PILE-Entität in der Initialisierungsphase. ANHANG 1 ADM ANHANG 2 CONFIG ANHANG 3 ANHANG 4 ANHANG 5 ANHANG 6

Claims (7)

1. Verfahren zur Kommunikation mit einem Netz (RE, ...) über ein Kommunikationssystem, das einen Kommunikationscode (CC) verwendet, der zu mehreren Modellen zur gegenseitigen Verbindung offener Systeme (OSI, ISO/DSAC, IPS) gehört, wobei die Arbeit des Systems durch wenigstens ein Betriebssystem (GPOS, SE1) organisiert wird, dem mehrere Anwendungen zugeordnet sind und dessen Ziel es ist, für die Anwendungen notwendige Daten in das Netz zu senden oder vom Netz zu empfangen, wobei das System eine Einheit für das Management der den Code (CC) bildenden verschiedenen Schichten (C&sub4;, C&sub3;, C&sub2;) umfaßt, die mehrere Kommunikationsmodule enthält, die verschiedenen Modellen zugehören, dadurch gekennzeichnet, daß es darin besteht,

- bei der Initialisierung des Systems den Stapel der verschiedenen Schichten durch Verbindungen zwischen ihnen über einen Konfigurator (CONFD) des Systems aufzubauen,

- und über ein Management-Modul (IMD) des Systems auf sämtliche Management-Informationen in jeder der Schichten des Codes zuzugreifen, wobei diese letzteren jeweils wenigstens eine Management-Entität (LME11, LME12, ...) besitzen, wobei eine Management-Entität eine Schnittstelle zwischen mehreren Kommunikationsschichten eines Kommunikationsmoduls bilden kann, wobei das Management-Modul wenigstens mit der Management-Entität in einer Sprache kommuniziert, die allen der wenigstens einen Management-Entität gemeinsam sind,

- wobei eine erste Management-Schnittstelle (LMAI1, LMI1) zwischen dem Konfigurator (CONFD) und den verschiedenen Management-Entitäten sowie zwischen dem Konfigurator (CONFD) und dem Management-Modul angeordnet ist,

- wobei eine zweite Management-Schnittstelle (LMAI2, LMI2) zwischen dem Management-Modul (IMD) und den Management- Entitäten (LME11, LME12, ...) der Schichten angeordnet ist.

2. Kommunikationsverfahren nach Anspruch 1, dadurch gekennzeichnet, daß es darin besteht, die Entitäten (LME11, LME12, ...) in jeder Schicht für das Referenzmodell OSI anzuordnen und daß es darin besteht, eine allen Schichten gemeinsame Entität in der oberen Schicht des Modells IPS anzuordnen, wobei jede Entität die Management-Arbeit jeder der Schichten für das Modell OSI und für die Gesamtheit der Schichten für das Modell IPS organisiert.

3. Kommunikationsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß es darin besteht, eine Gesamtheit von Objekten, die jeweils durch mehrere Attribute beschrieben werden, über jede Management-Entität zu steuern.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Management-Modul (IMD) in Verbindung mit einem Betriebssystem (GPOS, SE1, ...) arbeitet und die Lenkung von Management-Nachrichten (ADM-BIND-LAYER-REQ, ...) zu und von den Entitäten (LME11, ...) und den Wartungs- und Konfigurationswerkzeugen, die in den Schichten angeordnet sind, ausführt, wobei die erste und die zweite Schnittstelle (LMAI1, LMAI2, LMI1, LMI2) die Dialoge zwischen dem Management-Modul (IMD), dem Konfigurator (CONFD) und den verschiedenen Management-Entitäten (LME11, ...) führen.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß es darin besteht, in eine Nachricht einen ersten Block (M-PROTO), dem ein zweiter Block (M-DATA) folgt, einzuschließen, wobei der erste Block eine sogenannte primitive Datenstruktur aufweist, die darin besteht, den Informationsaustausch zwischen den Entitäten und dem Management-Modul (IMD) zu definieren, und der zweite Block Informationen enthält, die darin bestehen, die Signifikanz der primitiven Struktur zu definieren.

6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß es darin besteht, in jedes Objekt eines Moduls Schichtobjekte einzuschließen, wovon jedes entweder Verbindungsobjekte oder Auswahlobjekte oder IVMO-Objekte, die die Anfangswerte jedes Schichtobjekts definieren, enthält.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß es darin besteht, jedes gemanagte Objekt über drei Felder zu identifizieren, wobei das erste Feld (SUBSYSTEM-id) die Identität des Kommunikationsmoduls definiert, das das betreffende Objekt enthält, das zweite Feld (OBJECT-type) den Management-Typ des Objekts definiert und das dritte Feld (OBJECT-name) den internen Namen definiert, der von dem dieses Objekt enthaltenen Kommunikationsmodul vergeben wird.