Beispiel 1: Abbildung von Internet-SMI in das OSI-Informationsmodell

Die großen Unterschiede in den Informationsmodellen der OSI- bzw. Internet-Architektur zeigen, daß das Aufgabenspektrum eines Management-Gateways weit über die bloße Umsetzung von Protokolldateneinheiten unterschiedlicher Managementprotolle hinausgeht: Schließlich soll (wie oben gefordert wurde) ein CMIP/SNMP-Gateway einem OSI-Manager den Zugriff auf SNMP-Ressourcen auf vollkommen transparente Weise ermöglichen, d.h. das Managementsystem greift auf SNMP-fähige Ressourcen auf dieselbe Art zu, wie dies beim Abrufen von Informationen aus OSI-Agenten der Fall wäre. Folglich ist es Aufgabe des Gateways, eine OSI-Sicht auf SNMP-basierte Ressourcen herzustellen. Die Abbildung von Internet-SMI in das OSI-Informationsmodell ist hierzu unerläßlich.

Das Ergebnis dieser Abbildung ist eine in GDMO übersetzte Internet-MIB, d.h. sämtliche Internet-MOs werden in OSI-MOs überführt. Diese neuen OSI-MOs haben die Aufgabe, dem Managementsystem gegenüber in der Rolle als Proxy-Objekte für die SNMP-Ressourcen zu agieren. Damit wird dem Managementsystem durch das Gateway eine OSI-Sicht auf die Internet-Managementinformation bereitgestellt.

Bei der Abbildung der Informationsmodelle gibt es zwei prinzipielle Designvarianten, die wir in den folgenden beiden Abschnitten darstellen und bewerten.

1. Alternative: Direkte Übersetzung mit dem IIMC-Algorithmus  

Die sogenannte direkte Übersetzung  transformiert Internet-MIBs unmittelbar in neue GDMO Klassen, wobei folgende einfache Regeln gelten:

• Gruppen einer SNMP-MIB werden zu OSI-MOCs. So werden z.B. die Gruppen interfaces, ip zu entsprechenden gleichlautenden MOCs. Im Fall der system-Gruppe der MIB-II tritt jdeoch das Problem auf, daß eine gleichlautende Umsetzung zu einem Namenskonflikt führt, da die Wurzel des OSI Management Information Tree denselben Namen trägt. Folglich ist für diesen Sonderfall eine geeignete Umbenennung vorzusehen. In unserer Implementierung haben wir für die GDMO-Darstellung der MIB-II den Namen internetSystem eingeführt.
• Tabellenzeilen in Internet-SMI werden ebenfalls auf OSI-MOCs abgebildet. Die Idee beruht auf der Tatsache, daß SNMP-Tabellen grundsätzlich dann gebildet werden, wenn zu einer einer Ressourcenklasse mehrere Instanzen existieren; somit wird beispielsweise die Tabellenzeile ipAddrEntry zu einer gleichlautenden OSI-MOC.
• Alle anderen skalaren MIB-Variablen werden zu Attributen der jeweiligen OSI-MOCs. Die SNMP-Variable sysDescription aus der Gruppe system wird folglich zu einem Attribut der MOC internetSystem, die aus der Gruppe system entstanden ist.
• Die Object Identifier (OID), die eine Internet-MIB-Variable eindeutig referenzieren, werden zum Suffix des Knotens im OSI-Registrierungsbaum, der das OSI-Äquivalent zur Internet-MIB darstellt.
• Die Einträge des Description Feldes jeder MIB-Variable werden in das Behaviour Feld des korrespondierenden OSI-Attributes eingetragen, da in beiden Fällen die Semantik von Managementobjekten lediglich in natürlicher Sprache definiert ist.

Aus Platzgründen ist es an dieser Stelle nicht möglich, die Details des IIMC-Algorithmus zur Überführung von Internet-MIBs in OSI-MOCs in voller Länge darzustellen. Der interessierte Leser findet diese in Anhang . Der Algorithmus wird dort anhand der MIB-II [#!RFC1213!#] näher erläutert.

Es ist offensichtlich, daß die direkte Übersetzung keine bereits in existierenden MOCs definierten Parameter und Methoden durch Vererbung übernehmen kann, da jegliche in den SNMP-MIBs enthaltene Managementinformation in neue, unmittelbar von ,,top`` abgeleitete Klassen überführt wird. Die Vererbungshierarchie bleibt somit flach und der Grad an generischer Managementinformation entsprechend gering. Vorteilhaft ist, daß die Übersetzung nach einem vom NM-Forum standardisierten Algorithmus [#!nmf26!#] erfolgt. Sie ist somit deterministisch und daher automatisierbar. In der Tat sind die in Abschnitt detailliert vorgestellten Beispiele durch einen Compiler [#!reil93!#] erzeugt worden, dessen momentaner Reifezustand allerdings manuelle Eingriffe durch den Entwickler in den erzeugten Code erforderte. Eine detaillierte Beschreibung dieser Problematik ist in [#!nmf29!#] enthalten.

2. Alternative: Abstrakte Übersetzung:

Die abstrakte Übersetzung  zielt demgegenüber darauf ab, die Semantik einer Internet-MIB möglichst weitgehend zu erhalten. Dies geschieht durch Abbildung der Elemente einer Internet-MIB auf diejenigen OSI-MOCs, die durch geeignete Vererbung aus bereits existierenden GDMO-Klassen entstehen.

Als Basis der Vererbungshierarchie können beispielsweise die Generic Managed Object Classes (GMOC)  [#!iso10165-5!#] für die Modellierung der Internet-Ressourcen benutzt werden. Damit können SNMP-fähige Ressourcen vollständig, d.h. auch in Bezug auf Vererbungseigenschaften in das OSI-Management eingebunden werden. Ein solcher Ansatz findet sich in [#!abch93!#]. Der Einsatz von GMOCs wirft jedoch eine Reihe von Problemen auf, die nicht zuletzt daraus resultieren, daß innerhalb des OSI-Informationsmodells lediglich eine kleine Anzahl generischer und sehr abstrakter MOCs definiert sind. Obwohl es Versuche gab (z.B. [#!beie93!#]), Teile der MIB-II durch abstrakte Übersetzung in die Vererbungshierarchie des OSI-Informationsmodells auf Grundlage der GMOCs einzubinden, hat sich gezeigt, daß diese Art der Übersetzung von Internet-MIBs vor allem für Ressourcen, welche nicht zum OSI-Schichtenmodell konform sind, problematisch ist. Dies äußert sich nicht zuletzt darin, daß sämtliche GMOCs ausschließlich die Elemente des OSI-Referenzmodells beinhalten (z.B. Dienstzugangspunkt, verbindungsorientierte Protokollmaschine usw.) und damit keinerlei Anknüpfungspunkte für generische MOCs bieten, welche die Komponenten einer verteilten Anwendung darstellen. Auch die gegenwärtig in Bearbeitung befindlichen MOCs für Protokollmaschinen des Systems Management Protocols [#!iso10165-9!#] ändern an dieser Situation nichts Grundlegendes, sind jedoch ein erster Schritt in die Richtung eines OSI-basierten Anwendungsmanagements. Das zentrale Problem liegt jedoch darin, daß die abstrakte Übersetzung nichtdeterministisch ist, da unterschiedliche Anordnungen der Vererbungshierarchie denkbar sind. Eine Automatisierung der abstrakten Übersetzung von Internet-MIBs in OSI-MOCs ist daher nicht machbar.

Wir haben uns daher aus diesen Gründen entschlossen, für die Entwicklung unseres Gateway-Prototypen die Direkte Übersetzung zu verwenden, um damit die Offenheit dieser Systeme zu garantieren.