Netzwerk-Management ist wahrscheinlich die einzige der Kommunikationsdisziplinen mit überragender Bedeutung, die erst jüngst ihre Stellung errungen hat. Den Ton geben gegenwärtig Proprietary-Lösungen - beispielsweise von IBM und DEC - an. Auch die ISO widmet sich dem Thema Netz-Management seit zwei Jahren verstärkt; allerdings mahlen hier die Mühlen noch langsam. Die dritte und letzte Folge dieses Berichts setzt sich mit einzelnen Herstellerkonzepten und deren Offenheit sowie KI-Methoden im Rahmen von Netzwerk-Management-Architekturen auseinander. Außerdem wird darauf hingewiesen, wieweit OSI-basierende Lösungsansätze in der ISO "gediehen" sind.

Designer und Entwickler von Netzwerkmanagement-Systemen müssen ihr Produkt im Zusammenhang und im Vergleich mit den derzeit am Markt befindlichen und mit anderen geplanten Systemen sehen. Es lassen sich dabei im wesentlichen drei teilweise konkurrierende Trends ausmachen:

- "rohe" Entwicklungen, die ausschließlich auf den internationalen (Vor-)Standards basieren und als Referenzimplementation gelten können,

- "Proprietary"-Produkte, die den anbieterspezifischen Kommunikationssystemen angepaßt sind und daher den dabei zugrundeliegenden Anforderungen entsprechen (zum Beispiel IBMs Netview, Decnet-Management, etc.) sowie

- Spezialsysteme für große und mittlere Anwendernetze, die entsprechend den Betreiberanforderungen und -aufgaben strukturiert sind und dabei mehr und mehr die normierten OSI-Schnittstellen zur Grundlage ihrer Komponenten machen.

Die Konformität mit der OSI-Netzwerkmanagement-Architektur wird auch von einem großen Teil der führenden Hersteller als ein Ziel ihrer laufenden Entwicklungen benannt. Die Standardisierungsgremien der ISO arbeiten seit etwa zwei Jahren wieder an der Problematik; allerdings läßt der Fortschritt der Normierungsarbeiten noch zu wünschen übrig. Mit voll verabschiedeten internationalen Standards ist nicht vor 1990 zu rechnen, bei der Management Information Base und den funktionalen Managementberichten nicht vor 1991.

Frühzeitige Reaktion in den Reihen der IBM

Auf die zunehmende Bedeutung des Netzwerk-Managements hat aber auch IBM frühzeitig reagiert. Im ersten Schritt kündigte sie im Mai 1986 das Produkt Netview an. Es faßt ältere Produkte wie NCCF, NPDA und NLDM zusammen und erweitert ihre Funktionalität. Schließlich verkündete IBM im September 1986 die Open Network Management Architecture (ONMA) und führte das Produkt Netview /PC ein.

ONMA bietet - basierend auf der Tool-Familie Netview - einen konsolidierten Blick auf das (SNA-)Netzwerk von zentralen Operator-Arbeitsplätzen aus. Die Netzwerkkomponenten spielen darin die Rolle von Lieferanten oder von Empfängern der Management-Informationen. Demzufolge werden sie auch als Focal Point, Entry Point oder Service Point klassifiziert.

Focal Points stellen die Hostsysteme der Netview-Programme dar. Sie verwalten und überwachen das Netz beziehungsweise definierte Teile davon, nehmen Fehler- und sonstige Alarmmeldungen entgegen und reagieren darauf. Entry Points dagegen sind adressierbare SNA-Ressourcen und tauschen mit einem zugeordneten Focal Point Management-Daten - im wesentlichen reagierend - aus. Focal und Entry Points bedienen sich der üblichen SNA-Protokolle; die Manager-Software der Focal Points besteht aus neuen Versionen bekannter IBM-Operating-Tools: Netview, Performance-Monitor und Distribution-Manager.

Netview/PC bietet die Möglichkeit, Nicht-SNA-Komponenten als Service Points in das Netview-Management einzubinden. Dies geschieht durch Implementierung eines Gateways auf eine offengelegte Schnittstelle API. Trotz der vorhandenen technischen Umsetzungsprobleme und dem begründeten Zweifel an der Funktionalität bei der Integration offener Komponenten unterstützen viele Hersteller von Netzwerk-Management-Produkten diese Lösung, so daß die Netview-Architektur vielfach als "De-facto"-Standard bezeichnet wird.

Digital Equipment spezifiziert in ihrer acht Schichte umfassenden Kommunikationsarchitektur DNA eine dedizierte Managementschicht für die Steuerung und Überwachung des Netzes (Decnet Phase 3 beziehungsweise Phase 4), DECs Managementwerkzeuge unterstützen folgende Aufgaben:

- Generierung von Netzsoftware zur Anpassung an die spezifischen Eigenschaften eines Knotens. Das schließt den Aufbau einer Konfigurationsdatenbasis pro Knoten ein.

- Setzen von Anfangswerten und Änderung statischer und dynamischer Netzparameter wie Knotennamen und -adressen, Paßwörter, Parameter zur Beschreibung von Netzsoftwaremodulen und Nutzerprogrammen.

- Knotenoperating, zum Beispiel Inbetriebnahme und Abschalten von Knoten und physischen Leitungen sowie Überwachung von Knoten-, Leitungs- und Verbindungszuständen. Für Testzwecke enthält Decnet auch eine Anzahl integrierter Werkzeuge, die Tests zur Isolierung von Fehlern in einer Verbindung gestatten; Traceunterstützung zur Identifizierung von Protokollfehlern, ferner Möglichkeiten zum Erzeugen entfernter Hauptspeicherabzüge.

- Überwachung der Knotenaktivitäten im gesamten Netz, so Anzeige von Informationen über den Zustand lokaler und entfernter Knoten und automatisches Aufzeichnen von Ablaufereignissen an der Bedienerkonsole sowie in einer Datei.

- Fernladen, besonders von unbedienten Knoten. Das Fernladen wird von einem "command node" durch Übergabe eines Kommandos an das Netzsteuerprogramm ausgelöst.

Um diese Managementfunktionen auszufahren, gibt es in DNA eine Anzahl spezifischer Softwarekomponenten. Die meisten davon sind in der bereits erwähnten Netzmanagementschicht enthalten.

So trivial die Aussage klingt und trotz aller scheinbaren Öffnungsbestrebungen haben alle Netzwerk-Managementsysteme der großen Rechnerhersteller immer die hauseigene Netzwerkarchitektur im Blick. Fremdprodukte müssen sich daran immer anpassen, ob durch Integration an die Hausstandards der großen Hersteller oder über Umwege durch die Anpassung an offengelegte Schnittstellen wie den Netview-Service-Points. Letzteres hat oft Informationsdefizite oder gar -verluste zur Folge, was den Fremdprodukten in ihrer Konkurrenz zu den Produkten der Großen nicht gerade hilft.

Diese Vorgehensweise ist gar nicht so sehr "böse" Absicht eines Herstellers von Computer-Netzwerken und zugehörigen Administrationstools, sondern hängt auch damit zusammen, daß die Anforderungen der Netzwerkbetreiber möglichst umfassend befriedigt werden sollen. IBM bietet ihre Netview-Familie unter dem Begriff "Rechenzentrums-Automatisierung" an und will die Menge an rechnergestützten Managementsystemen plus den zugehörigen Dienstleistungen entsprechend mächtig ausstatten. Die internationale Standardisierung hinkt diesen Ansprüchen vor allem bei der Definition der Funktionalität um Jahre hinterher, wird sich ihnen aber letztendlich stellen müssen.

Diese Herausforderung läßt eine Antwort auf die Frage "Was ist der Stand der OSI-Normen bezüglich Netzwerk-Management?" wichtiger denn je erscheinen. Der ratsuchende Anwender wird jedoch gleich mit einem paradoxen Bild konfrontiert. Einerseits wird vielfach mit Recht behauptet, daß OSI-Normen zu Netzwerk-Management in weiter Ferne liegen; andererseits häufen sich Ankündigungen von "OSI-basierenden" Lösungen (AT&Ts Unified Network Management Architecture, Codex 9800 Integrated Network Management, Decnet Phase V, MAP/TOP 3.0, etc.)

Im Spannungsfeld zwischen instabilem Entwicklungsstatus der Normierung des OSI-Managements, Herausforderung der Anbieter offener Systemkomponenten durch die umfangreiche Funktionalität von Proprietary-Lösungen (symbolisiert durch den Quasistandard Netview)

und der geplanten Realisierung von Übergangslösungen nach Maßgabe von Vorstandards tauchen eine Reihe von Fragen auf, deren Beantwortung für das Design von künftigen Standardprodukten zur Administration heterogener Netzwerke von entscheidender Bedeutung ist:

1. Werden Produkte nach den internationalen Standards oder nach dem "Industriestandard" in Zukunft den Markt dominieren?

2. In welcher Weise kann ein Anbieter auf die eine oder andere Marktdominanz reagieren? Wie sind NM-Standardprodukte in die Gesamtproduktstrategie einzuordnen und können Konzepte anderer Hersteller in die eigenen Marketing-Strategien integriert werden?

3. Welche Möglichkeiten ergeben sich generell für ein Zusammenwirken von OSI-normierten NM-Produkten und den Produkten des Marktführers?

4. Welcher Grad an Konformität ist in den verschiedenen Funktionsbereichen von Netzwerkmanagement derzeit erreichbar beziehungsweise wie müssen künftige Migrationskonzepte in Richtung voller OSI-Konformität aussehen?

Mehr Kommunikation zwischen OSI und SNA

Ohne große Sterndeuterei kann heute wohl behauptet werden, daß die Zukunft im wesentlichen von zwei Netzwerkarchitekturen beherrscht sein wird: OSI und SNA. Entsprechend werden die Administrations-Tools entweder OSI- oder SNA-orientierte Komponenten überwachen und die zugehörigen Techniken einsetzen. Insbesondere die Frage nach Kommunikation und Kooperation zwischen den beiden Welten wird an Bedeutung zunehmen. IBM hat mit seinen Service Points bereits einen ersten Schritt getan; eine Aussage des Marktführers zum OSI-Management existiert dagegen nicht, und es muß wohl nicht bezweifelt werden, daß in naher Zukunft eine erfolgen wird.

Wenn man den Themen Managementstrategien und funktionale Bereiche bei den OSI-basierenden Lösungen nachgeht, so findet man drei unterschiedliche Vorgehensweisen:

1. Der SMAP (System Management Application Process) wird inklusive der Standard-Schnittstelle CMIS realisiert; die Management-Applikation beschränkt sich auf die Benutzung dieser Schnittstelle. Dabei werden die gesammelten Daten nur dazu verwendet, in mehr oder weniger "schöner" Darstellung dem Benutzer präsentiert zu werden (als Beispiel kann die NM-Applikation der großen MAP-3.0-Demonstration auf der ENE '88 in Baltimore auf einer Sun-Workstation herangezogen werden).

Eine Weiterverarbeitung der Daten im Sinne von

Managementstrategien ist weder realisiert noch impliziert. Im

Zusammenhang mit der NM-Implementierung des Industrial Technologies Institutes (ITI) für die ENE '88 soll jedoch erwähnt werden, daß die Autoren des Systems bereits für die Inter-Plausibilitätsprüfungen der Netzwerkeinstellungen (Ressourcenparameter) im Rahmen des Konfigurationsmanagements den Einsatz von wissensbasierten Systemen planen.

2. Die Schnittstelle CMIS und das zugehörige Protokoll CMIP wird als Basis für ein eigenes Protokoll oberhalb des SMAP verwendet (zum Beispiel das Network Management Protocol - NMP - von AT&T). Die Folge davon sind eigene Protokollmaschinen in den verschiedenen Stationen mit asymetrischem Manager-Agent-Verhalten, wodurch einzelne funktionale Bereiche abgedeckt werden können.

Die Mechanismen dieser Protokolle sind allerdings nicht eindeutig einzuordnen, insbesondere fehlen die Beziehungen zwischen den funktionalen Bereichen. Das NMP zum Beispiel ist bisher nur als genetisches Protokoll oberhalb des CMIP formuliert. Detaillierte Hinweise auf die konkrete Implementierung funktionaler NM-Bereiche ergeben sich bisher nicht.

Auch DEC will offensichtlich mit seiner kürzlich angekündigten "Enterprise Management Architektur EMA" diesen Weg gehen. Die bisherigen Decnet-Protokolle werden durch das offizielle CMIP ersetzt, auf dem wiederum eigene Protokollschichten aufsetzen, um die Funktionalität des DNA-Managements zu erhalten. Wie allerdings die Netzwerkobjekte beschrieben werden, welche Funktionen darauf angewendet werden können und welche Funktionalität den fünf OSI-Managementbereichen hinzugefügt wird, ist den DEC-Ankündigungen derzeit nicht zu entnehmen.

3. Die CMIS wird als Schnittstelle zur Abfrage der Agentensysteme verwendet. Alle darüber hinausgehenden Mechanismen sind Aufgabe des zentralen Managementsystems. Diese Vorgehensweise liegt zum Beispiel dem Codex-System (Codex 9800 Integrated Network Management) zugrunde; darüber hinaus hat Codex eigene Beschreibungsmechanismen der Betriebsmittel festgelegt. Übrigens ist dies auch das Grundprinzip von IBMs Netview, wobei natürlich eine eigene SNA-Schnittstelle Basis der Implementierung ist.

Aus der möglichen, sehr hohen Komplexität von heutigen Netzwerken und der daraus resultierenden Anforderung an die administrierenden Systeme folgt sehr schnell eine verteilte Struktur der Netzwerk-Managementsysteme. Dies gilt zunächst hierarchisch in dem Sinne, daß die Sammlung der Informationen über eine Netzwerk-Komponente und deren Beobachtung möglichst lokal in der Ressource selbst erfolgen sollte. Diese Informationen über den Komponentenzustand werden an eine zentralisierte Managementinstanz übermittelt, wobei Zustandsdaten ausgewertet und eventuell nötige Reaktionen eingeleitet werden können.

In der Regel werden die Aufgaben des Netzwerk-Managements auf drei Grundelemente verteilt:

- dem Netzwerk-Administrator, einem menschlichen Bediener, der ein Managementsystem nutzt, um seine Arbeit durchzuführen;

- einer Netzwerk-Manager-Applikation, einem automatisierten Tool mit einer speziellen Bedienerführung zur Unterstützung des Administrators. Solche Systeme können im Netz mehrfach installiert werden, wobei dann die Eingriffe koordiniert werden müssen, und

- Management-Agenten im Netz, die in den verschiedenen Komponenten residieren und lokal in der Lage sind, zum einen Aufträge der Manager-Applikation auszuführen und zum anderen die eigene Station zu überwachen und außergewöhnliche Ereignisse an den Manager zu melden.

Natürlich spiegelt sich diese Verteilung der Aufgaben in einer Verteilung der Daten. Der Beschreibung des Netzes und seines Verhaltens durch diese verteilte Datenbank kommt natürlich die entscheidende Bedeutung zu. Jede Manager-Applikation kann selbstverständlich nur so gut sein, wie die Basisinformation, aufgrund welcher der Manager agieren muß. Diese unterstreicht die Wichtigkeit der Standardisierung der sogenannten "Management Information Base" durch die

Normierungsgremien.

Andererseits spiegeln auch die Bewertung und die Auswertungsstrategien der Datenbasis eine große Rolle für die Qualität der Management-Applikation. So kann zum Beispiel der einheitliche Zeitbezug von Zahlenständen zur kritischen Größe für Auswertungen werden. Welche Aussagekraft hat in einem Ethernet der Zählerwert "100 Kollisionen", wenn unbekannt bleibt, ob diese einhundert Ereignisse in der letzten Minute, in der letzten Stunde oder vielleicht nur in der letzten Woche aufgetreten sind?

Leider macht die internationale Standardisierung keinerlei Vorgaben zu diesem Thema und wird es in absehbarer Zukunft auch nicht tun. Es gibt sogar sehr ernstzunehmende Stimmen, die sagen, daß es gar nicht sinnvoll sein kann, diese strategischen Aspekte des Netzwerk-Managements zu standardisieren, da hierdurch nur unnötige Einschränkungen auftreten würden. Dieser Einwand hat sehr großes Gewicht, läßt aber außer acht, daß ohne Überlegungen zu den Managementstrategien ebenfalls Einschränkungen auftreten. Die Semantik der vorliegenden Protokolle läßt die regelmäßige Überwachung des Netzes nur durch explizites Abfragen der Zustände in den Elementen zu. Ein selbständiges Melden ("I am alive") der Netzwerk-Komponenten in regelmäßigen Abständen ist nicht möglich, da dies derzeit nur beim Erreichen definierter Zählerschwellwerte geschehen darf.

Jede Manager-Applikation in allen Netzwerkkarten hat eine Reihe von Aufgaben durchzuführen, die oft parallel ausgeführt werden können. Dies führt im allgemeinen zu einem geschichteten Software-Design, häufig gepaart mit der Aufteilung der Aufgaben auf mehrere Workstations und Server.

Aufbau verteilter Künstlicher Intelligenz

Die wesentlichen Komponenten einer Manager-Applikation lassen sich grundsätzlich in zwei Ebenen unterteilen:

- die Administrationsebene, die dem menschlichen Benutzer des Systems den Eingriff in die Netzwerk-Komponenten gestattet, aber gleichzeitig auch die automatische Überwachung des Netzes durchführt; und

- die Kommunikationsebene, die die Basisinformation für die Administrationsebene beschafft, also Daten sammelt, Befehle übermittelt und ihre Ausführung überwacht, die Meldungen über auffällige Ereignisse abfängt und Reaktionen einleitet sowie den Netzwerkkomponenten automatisierte Dienste zur Verfügung stellt. Die Kommunikationsebene bedient sich dazu einer Protokollmaschine, die zum Beispiel das durch OSI standardisierte CMIP-Protokoll durchführt.

Die Schnittstelle zwischen der Administrations- und der Kommunikationsebene stellt die Netzwerk-Datenbank dar, die aufgrund ihres Aufbaus in der Lage sein sollte, den aktuellen Status des Netzes abzubilden. Natürlich tritt hier sofort die Leistungs- und Durchsatzproblematik von Datenbank-Managementsystemen ein. Um einen möglichst korrekten Informationsstand über den Netzstatus zu erhalten, muß dieser möglichst häufig abgefragt oder berichtet werden. Relationale Datenbanken sind hierin natürlich ein Flaschenhals, da beim Aktualisieren eines Datensatzes durch die zahlreichen Konsistenzüberprüfungen erhebliche Verarbeitungszeiten entstehen können. Dem Entwurf der Netzwerk-Datenbank kommt also sehr große Bedeutung zu, da dadurch die Leistungsfähigkeit des Systems ganz wesentlich mitbestimmt wird. Aber auch durch eine adäquate Rechnerauswahl beziehungsweise durch die geschickte Verteilung der Aufgaben auf mehrere Rechner kann das Manager-System weiter optimiert werden.

Ein wichtiger Gesichtspunkt beim Entwurf einer Netzwerk-Manager-Applikation ist die Sicherheit des Systems selbst. Die Manager-Sicherheit muß genau vom Sicherheitsmanagement unterschieden werden, welches sich um die Zugangs- und Zugriffssicherung der verschiedenen Netzwerk-Ressourcen kümmert. Die Manager-Sicherung dagegen hat die

Sicherheit des Netzwerk-Managersystems im Auge, wieder in der dreifachen Bedeutung Betriebssicherheit, Datensicherheit und

Zugriffssicherheit.

Ein Managementsystem ist für sich ein idealer Angriffspunkt, wenn ein Netzwerk geschädigt werden soll. Hier müssen daher besondere Vorkehrungen getroffen werden, um einerseits den unbefugten Zugriff auf das Netz zu verhindern, um andererseits aber auch den ungestörten Betrieb und die Integrität der Daten sicherzustellen. In naher Zukunft werden immer häufiger die Methoden der künstlichen Intelligenz Eingang in das Design von Netzwerk-Managementsystemen finden.

Ein vollkommen neuer Ansatz für die Lösung und Bearbeitung von Netzwerkproblemen besteht dabei im Aufbau von verteilter, künstlicher Intelligenz (DAI - distributed artificial intelligence), um die Administration von Kommunikationsnetzen zu unterstützen. Die Vorteile, Probleme in einer verteilten Umgebung zu lösen, entsprechen den Vorteilen der verteilten Verarbeitung im allgemeinen:

- die Rechnerleistung von kleinen, relativ billigen Prozessoren kann ausgeschöpft werden;

- lokale Verarbeitungskapazität kann für lokale Probleme verwendet werden; und

- die Verfügbarkeit wird erhöht, wenn ein einzelner, zentralisierter Rechner für die Problemlösung vermieden wird, da dessen Ausfall den Ausfall des ganzen Netzes zur Folge hat.

Selbstheilendes Netz zum Ziel gesetzt

Die Anwendung von verteilten Expertensystemen kann die Automatisierbarkeit der Netzwerk-Managementsysteme wesentlich verbessern, da viele Probleme im Netz standardisierte Reaktionen erwarten. Durch verschiedene, der Situation angepaßte Modifikationen der Komponenten-Konfiguration läßt sich bereits angemessen reagieren und es können Gegenmaßnahmen zur Verbesserung der Betriebssicherheit ergriffen werden. Das Ziel der Anstrengungen ist sicherlich ein autonomes, selbstheilendes Netzwerk, in dem Probleme vielleicht einen Rückgang des Übertragungsdurchsatzes verursachen, sicher aber keinen Gesamtausfall mehr.

Solche Systeme sind jedoch für die nahe Zukunft nicht zu erwarten, und zwar aus folgenden Gründen: Erstens sind die Arbeiten daran noch reine Forschungstätigkeiten, und Produkte in diese Richtung werden lange nicht auszumachen sein. Es kann darüber hinaus auch noch gar nicht damit gerechnet werden, daß diese Forschungstätigkeit bereits Früchte trägt, da das Gebiet und alle Methoden des Netzwerk-Managements zu unerforscht sind und daher von formalisierbarem Expertenwissen derzeit wenig ausgegangen werden kann. Drittens sind die Forschungsarbeiten hierzu mit konkreten Projekten verbunden, die Verallgemeinerbarkeit in standardisierte Produkte steht damit in den Sternen.

Vor dieser Vision kann heute bereits eine Reihe von wissensbasierten Systemen ausgemacht werden, die die Aufgabengebiete des Netzwerk-Managements unterstütze können:

- Ermittlung der günstigsten Übertragungstarife bei bestmöglicher Leistungsqualität: Diese Aufgabe wird in Europa erst mit wachsender Auflockerung der Postmonopole eine Rolle spielen. In den USA ist sie durch die Vielfalt der Netz- und Dienstanbieter schon heute von großer Bedeutung.

- Fehler- und Leistungsdiagnose: Jede Netzwerk-Komponente könnte eine eigene, wissensbasierte Überwachungseinrichtung besitzen, damit die erkannten Zustandsänderungen und Alarme einer zentralisierten Diagnoseinstanz gemeldet werden können.

- Wartungsunterstützung: Ein wissensbasiertes Wartungssystem unterscheidet sich von einem Diagnosesystern dadurch, daß es weniger nach Fehlerzuständen fragt, sondern sich um die Behebungsstrategien kümmert und Vorgehensweise dazu vorschlägt.

- Verkehrsüberwachung: Expertensysteme in diesem Bereich können das konventionelle statische Routing durch ein dynamisches ersetzen, das die Belegung einer Leitungsverbindung anhand der aktuellen Auslastung vornimmt.

Expertensysteme dieser Art sind dazu vorgesehen, lokale Probleme zu lösen, wie individuelle Überlastung, einzelner Verbindungen oder regionale Ausfälle und Anforderungen. Sie können damit aus der verteilten Lokation Vorteile ziehen. Allerdings erwachsen aus der verteilten Intelligenz auch Risiken, insbesondere jenes, das als "globale Kohärenz" bezeichnet wird: Verteilte Instanzen zur Problemlösung müssen effizient zusammenarbeiten und gemeinsam einer globalen Optimierung entsprechen. Dies allerdings ohne sich gegenseitig zu duplizieren oder zu stark beziehungsweise zu wenig genutzt zu werden. Im Gegenteil, Expertensysteme der geforderten Art sollten auch noch die Fähigkeit besitzen, zu entscheiden, ob sie einander zur Problemlösung benötigen oder nicht.

Gleichartig bedeutend ist es zu entscheiden, wie die verschiedenen Expertensysteme organisiert sein müssen, um die Probleme effizient zu lösen. Diese Entscheidung wird konventionell bei der Installation des Systems getroffen, dieses organisatorische Design kann danach umkonfiguriert und verwaltet werden. Es wächst daraus allerdings sofort eine neue, letzte Forderung nach problemlösenden DAI-Instanzen, die auch diese Aufgabe dynamisch angreifen und die Expertensysteme in die Lage versetzen, sich selbst anhand ihres Problemverständnisses zu organisieren.

Als Beispiel für die Nutzung von KI soll der "Net-Handler" von SCS dienen, ein Fehlerdiagnose-Instrument, das die Überwachung komplexen Kommunikationsnetzwerke mit einem wissensbasierten SW-System unterstützt. Der Net-Handler dient dabei als Basissystem, das komfortable Werkzeuge bereithält, um an die speziellen Eigenschaften eines konkreten Netzes und an seine besondere Betriebsstrategie angepaßt werden zu können. Das System kann abhängig von der Umgebung, in die es integriert werden soll, auf vorhandene konventionelle Netzwerksysteme aufgesetzt werden oder über eine entsprechende Schnittstelle direkt mit dem Kommunikationssystem verbunden werden.

Es interpretiert daraufhin die auftretenden Meldungen und informiert das Bedienerpersonal über den Zustand des gesamten Netzes wie auch einzelner Komponenten. Anhand der Wissensbasis werden Instruktionen zur Behebung der Auswirkungen der Fehlersituation als Sofortmaßnahme generiert, wie zum Beispiel Vorschläge zur Rekonfiguration des Netzes. Gleichzeitig wird der Fehler diagnostiziert und ein Vorgehen zu seiner Behebung empfohlen. Dies erfolgt mittels einer Mensch-Maschine-Schnittstelle zur Erfassung komplexer Zusammenhänge.

Glossar

MIB - Management Information Base: Die - zwischen den offenen Systemen verteilte - konzeptionelle Datenbank, deren Inhalt die Grundlage aller Managementaktivitäten ist. Sie besteht im wesentlichen aus Variablen Aktionsbezeichnungen, Ereigniszählern und -schwellenwerten.

SMAE - System Management Application Entity: Die Instanz innerhalb der OSI-Anwendungsschicht, die für die Ausführung von Managementfunktionen in einem offenen Kommunikations-system zuständig ist. Umstritten ist derzeit ob Directory-Dienste Bestandteil einer SMAE sind oder nicht.

LME - Layer Management Entity: Eine Instanz innerhalb einer OSI-Schicht unterhalb der Anwendungsschicht, die die Überwachung, Steuerung und Koordination dieser Schicht in einer Station übernimmt und dazu mit anderen Stationen kommuniziert. Sie verwendet dafür entweder eine stationsinterne Schnittstelle, ein spezielles Schichtenmanagement-Protokoll oder die üblichen Protokolle dieser Schicht.

OSI-Management-Schnittstellen und -Protokolle

- CMIS/CMIP - Common Management Information Service/

Protocol: Allgemeine Dienstschnittstelle beziehungsweise Protokoll für OSI-Management; unterstützt die Manipulation von Variablen und das Auslösen von Aktionen und Ereignisberichten. In ISO 9595 und ISO 9596 vorgeschlagen (zur Zeit DIS).

- SMIS - Specific Management Information Service: Einem bestimmten funktionalen Bereich zugeordnete Dienstschnittstelle. In den Anhängen 3 bis 7 von ISO 9595/96 normiert (im Status WD oder DP).

- ACSE - Association Control Service Element: Allgemeiner Anwendungsdienst zur Verbindungssteuerung (ISO DIS 8649)

- ROSE - Remote Operations Service Element:

Anwendungsdienst zum Ausführen entfernter Prozeduren und Funktionen ISO DIS 9072)

Directory-Dienstschnittstellen und -protokolle

- DASE/DAP - Directory Access Service Element/Protocol: Einrichtungen zum entfernten Zugriff auf Namens- und Adreßauskünfte

- DSSE/DSP - Directory Service Element/Protocol: Einrichtung zur Manipulation des Directory-Dienstes