Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.10.1990 - 

Managed Objects als Hard- und Software-Einrichtungen

ISO schaffte neue Facetten für ein offenes Netz-Management

Zur Harmonisierung der Bereiche System-Management und Netzwerk-Komponenten wurden von ISO-Normierern mit "Managed Objects" (MO) und "Strukture of Management Information" (SMI) zwei neue Oberbegriffe geschaffen. Das von Wolfgang Gäßlein in Teil 1 des folgenden Artikels beschriebene Konzept zielt unter anderem darauf, eine Kernfunktionalität der am Netzwerk-Management beteiligten Anwendungsprozesse zu definieren.

Im Management Framework, einem Zusatz zum OSI-Basisreferenzmodell, hat die ISO die Grundprinzipien für das Netzwerk-Management (NM) von OSI-konformen Systemen, kurz OSI-Management, niedergeschrieben. Danach wird das OSI-Management in folgende drei Kategorien eingeteilt:

- System-Management (Systems Management) zur übergreifenden Steuerung und Überwachung der Komponenten eines OSI-konformen offenen Systems,

- Schichten-Management((n)-Layer-Management), ein Oberbegriff für das Management auf den einzelnen OSI-Schichten,

- Protokoll-Management((n)-Layer Operation), das Management einer einzelnen Protokollinstanz.

Neben dem System-Management ist auch das Schichten-Management ein funktional kompletter Teilbereich mit eigenen aktiven Einheiten (Layer Management Entities), kurz: LME) und Peer-to-Peer-Kommunikation mittels schichtenspezifischer NM-Protokolle. Funktionen des Schichten-Managements sind unter anderem Software-Download, Fehlerbehandlung oder Routing auf Schicht 3. Gegenüber diesem ursprünglichen Ansatz sind im Laufe der Zeit einige Änderungen eingetreten. Als gravierende Probleme erwiesen sich zum Beispiel:

- Die Architektur war sehr komplex mit einer Vielzahl von NM-Instanzen und Protokollen.

- System-, Schichten- und Protokoll-Management lassen sich nicht klar voneinander trennen. Um flexible Systemkonfigurationen zu ermöglichen, sollen die NM-Instanzen auf den einzelnen Ebenen möglichst unabhängig voneinander agieren können, auf der anderen Seite ist Koordination zwischen dem mit übergeordneten Aufgaben betreuten System-Management und den NM-Aktivitäten auf den einzelnen Schichten erforderlich. Zudem ergeben sich "unschöne" funktionale Abhängigkeiten. Der Austausch von NM-Informationen erfordert Protokollfunktionen höherer Schichten (beispielsweise Hardware-unabhängige Datendarstellung, eine Funktion der Schicht 6), welche für das Schichten-Management der unteren Ebenen nicht ummittelbar zur Verfügung stehen.

- Durch die Abgrenzung des System-Managements vom Schichten-Management sowie sonstigen Überwachungs- und Steuerungsfunktionen ("Normal Operation") waren die Standardisierungsaktivitäten der für System-Management zuständigen ISO-Arbeitsgruppe WG4 unter dem Subkomitee SC21 sehr abgehoben von den Standardisierungen bei den Netzwerk-Komponenten (Modems, LANs, X.25 DTEs etc.), aber auch bezüglich der OSI-Protokolle und -Dienste auf den einzelnen Schichten.

NM kann nur in konsistenter Interaktion mit den Netzwerk-Ressourcen funktionieren. Wegen der Notwendigkeit, die generischen NM-Spezifikationen von WG4 in Konvergenz zu den komponentenspezifischen Standards anderer Arbeitsgruppen in ISO und CCITT zu bringen, wurde eine architektonische Schnittstelle konzipiert, das sogenannte Managed Object (MO).

Ein Managed Object beschreibt eine Netzwerk-Ressource aus Sicht des NM, in seinen statischen und dynamischen Eigenschaften. Mit diesem auf objektorientierten Prinzipien basierenden Ansatz wurde ein sehr modernes und flexibles Konzept in das OSI-Management eingebracht. Ein Managed Object ist charakterisiert durch:

- seine Attribute, die seinen Zustand bestimmen und vom NM abgefragt und gesetzt werden können,

- die NM-spezifischen Operationen, welche auf dem Managed Object ausgeführt werden können, und die NM-Funktionen, die es unterstützt, wie Verkehrsstatistiken, Fehlerreports/Diagnosetests,

- die Ereignisse, die mit ihm assoziiert sind und die von ihm gemeldet werden können, wie Überschreiten von Schwellwerten und Zustandsänderungen.

Managed Objects können Hardware-Einrichtungen (unter anderem Kommunikationsrechner, Gateways, Modems, Endgeräte), Softwarekomponenten wie Protokolltreiber, logische Kommunikationsentitäten (zum Beispiel eine Kommunikationsverbindung) oder Software-Objekte, welche zur Steuerung des NM selbst dienen (Support Managed Objects), sein.

Die grundlegende NM-Architektur ist in der Abbildung dargestellt. Das System B soll von System A aus administriert werden. Zu diesem Zweck sind auf beiden Systemen spezielle Anwendungsprozesse, Systems Management Application Processes (SMAPs) genannt, vorhanden. In System A läuft ein Manager-Prozeß (Managing Process), welcher über die NM-Kommunikationsdienste mit einem Agentenprozeß (Agent Process) in System B kommuniziert. Dem Agentenprozeß sind ein oder mehrere Managed Objects zugeordnet. Seine Aufgabe ist es:

- Kommandos des Managers in entsprechende Operationen auf den Managed Objects beziehungsweise in interne Aktionen (zum Beispiel Führen eines Protokolls) umzusetzen und

- Managed Objects auf bestimmte Ereignisse hin zu überwachen und daraus entsprechende Ereignismeldungen (zum Beispiel Alarme) für den Manager-Prozeß zu generieren.

System A wird in diesem Zusammenhang als Managing System und System B als Managed System bezeichnet. Grundsätzlich ist die OSI-NM-Struktur aber symmetrisch. Ein System, sogar ein einzelner Prozeß kann sowohl Manager- als auch Agentenfunktionen ausüben.

Manager- und Agentenprozesse, ihre Struktur, Anwendungsfunktionen oder Benutzerschnittstellen liegen per Definition außerhalb des OSI-7-Schichtenmodells und sind somit nicht Gegenstand der OSI-Management-Standards. Diese definieren Dienste (Management Information Services, MIS) zum Austausch von NM-Informationen, die Struktur und Semantik der Informationen sowie mögliche Rollenverteilungen der NMÖ-Anwendungsprozesse beim Informationsaustausch.

Durch das Konzept des Managed Objects wirkt das OSI-Management effektiv aber auch in die Anwendungsfunktionen hinein, zumindest im Sinne einer Kernfunktionalität. Ein Agentenprozeß, welcher ein Managed Object nach Anforderung eines Managers erzeugt, ist gehalten, die damit verbundenen Verhaltensweisen zu generieren. Dies kann unter anderem das Durchführen gewisser statistischer Auswertungen und die regelmäßige Übertragung von Ergebnissen zum Manager-Prozeß sein.

Für die Menge aller Managed Objects im System prägte das Framework den Begriff Management Information Base (MIB). Der Begriff wird in letzter Zeit allerdings immer weniger verwendet, wohl weil er die neuen Konzepte nicht in adäquater Weise wiedergibt, wobei hier zwei Aspekte zu beachten sind:

- Das OSI-Management beschreibt Typen von Managed Objects, es legt nicht fest, welche davon in einem konkreten System vorhanden sein müssen, und wie sie dort repräsentiert und gespeichert sind.

- Managed Objects sind - anders als Informationen in Datenbasen - auch aktive Entitäten und können Quelle von Informationsflüssen sein.

Der aktuelle (und auch geeignetere) Oberbegriff für die MO-spezifischen Definitionen ist die Structure of Management Information (SMI).

ISO-Schritt für OSI-Schritt

Flickschusterei ist in den Gremien für die Netz-Management-Standardisierung nicht mehr gefragt. Nolens volens legte man hier einige sicher mühsam erarbeitete Ordnungskriterien wie der ad acta, da sich die bisher durchgehende Einteilung sämtlicher Management-Funktionen in fünf funktionale Bereiche schlichtweg nicht bewährt hatte.

Unerwünschte Zugzwänge und eine mangelnde Transparenz in Hinblick auf Netzwerk-Komponenten und Anwendungsfunktionen waren die Folge.

Nachdem die ISO-Arbeitsgruppen WG4 und SC21 zeitweilig abzudriften drohten, eröffnet der gemeinsame Nenner SMI den Softwerkern nun endlich die Möglichkeit, Produkte für unterschiedliche Umgebungen zu konzipieren.

Ohne diese transparenten Grundlagen ist es aus der Sicht des SCS-Spezialisten Wolfgang Gäßlein überhaupt fraglich, von einem Markt der offenen Netz-Management-Systeme zu reden.

Im übrigen hat auch die CCITT die Zeichen der Zeit erkannt und greift, um die Verwaltung großen Telecom-Netze in den Griff zu bekommen, gerne auf die ISO-Textvorgaben zurück.

Auf einem anderen Blatt steht, daß nach wie vor ein Mangel an Programmschnittstellen und fertigen Netz-Management-Produkten besteht. So lautet die Devise auch weiterhin "Eile mit Weile". sch

Wolfgang Gäßlein ist Consultant im Bereich Telecom bei der SCS Informationstechnik GmbH in München.