4.3 Abbildung der Kommunikationsmodelle

Nachdem im vorigen Abschnitt beschrieben wurde, wie die Managementinformation bei der Integration des Internet-Managements in die OSI-Architektur abgebildet werden soll, folgt in diesem Kapitel eine Diskussion, wie diese Managementinformation ausgetauscht werden kann. Dazu müssen die Kommunikationsmodelle aufeinander abgebildet werden. Die Aufgabe eines Gateways, es einem OSI-Manager zu ermöglichen, SNMP-Agenten zu managen, kann erst erfüllt werden, wenn beide Abbildungen spezifiziert und ausgeführt wurden.
Im Internet-Kommunikationsmodell wird das SNMP-Protokoll definiert. Es existieren dabei die PDUs GetRequest, GetNextRequest, GetBulk und SetRequest für die Kommunikation eines SNMP-Managers mit einem SNMP-Agenten. Der Agent empfängt diese PDUs, bearbeitet sie und schickt eine GetResponse-PDU zurück. Weiterhin kann der Agent Ereignisse mittels Traps unaufgefordert dem Manager mitteilen. Da SNMP auf dem Internet-Protokoll UDP (datagramm-orientiert) basiert, handelt es sich um eine unbestätigte Kommunikation.
Dagegen basiert das Kommunikationsmodell für das schichtenübergreifende Management der OSI-Architektur auf dem CMIP-Protokoll. Einem OSI-Manager stehen für die Kommunikation mit einem OSI-Agenten folgende PDUs zur Verfügung: m-Get, m-Set, m-Create, m-Delete, m-Action und m-GetCancel. Eine Instanz einer Managementobjekt-Klasse in einer MIB eines OSI-Agenten kann Ereignisse mit Hilfe von m-EventReport PDUs an den OSI-Manager schicken.
Die Kommunikation kann dabei allgemein sowohl bestätigt, als auch unbestätigt erfolgen. Einige dieser PDUs erlauben zusätzlich das Übertragen von Scopes und Filtern (m-Get, m-Set, m-Action, m-Delete). Auch kann in diesen PDUs eine Synchronisationsbedingung übermittelt werden.
Für den Austausch von Managementinformation zwischen diesen beiden Architekturen bedarf es einer Protokollkonvertierung, die vom Gateway durchzuführen ist. Diese Übersetzung beruht auf folgenden Schritten:

• Die vom OSI-Manager abgeschickten PDUs müssen empfangen, entschlüsselt und verarbeitet werden.
• Diese Verarbeitung der CMIP-Requests kann einerseits dadurch erfolgen, daß im Gateway selbst Aktionen ausgeführt bzw. Informationen gelesen werden. Andererseits kann ein CMIP-Request auch SNMP-PDUs auslösen, um vom SNMP-Agenten Informationen zu erhalten bzw. Aktionen im Agenten auszulösen. Es sind sicherlich auch CMIP-Requests denkbar, zu deren Bearbeitung beides notwendig ist.
• Bei der Bearbeitung müssen eventuell vorhandene Scopes, Filter oder Synchronisationsbedingungen beachtet und ausgeführt werden.
• Nach der Bearbeitung eines CMIP-Requests werden die Ergebnisse in Response-PDUs verpackt und zum Manager zurückgeschickt.
• Die vom SNMP-Agenten ausgelösten Ereignismeldungen (Traps) müssen vom Gateway in OSI-Notifikationen übersetzt und zu den entsprechenden EFDs (Event Forwarding Discriminator) weitergeleitet werden. Diese übernehmen schließlich den Transport zu den jeweiligen OSI-Managern.

Diese Bearbeitungsschritte lassen eine weitere Hierarchie erkennen, die in [AbClHo93] ,,Management-Informationshierarchie`` genannt wird. In dieser Management-Informationshierarchie wird die Managementinformation in den Blättern der Hierarchie gesammelt und zu einem gewissen Grad an die höheren Hierarchiestufen weitergeleitet. Auf diese, hier existierende Management-Hierarchie mit dem OSI-Manager, dem Gateway und dem SNMP-Agent können zwei verschiedene Management-Informationshierarchien gefunden werden, je nachdem, wie das Gateway die Managementinformationen verwaltet:

• Zustandslose (stateless) Komponenten speichern keine Managementinformationen. Es werden stattdessen alle von einer höheren Informationshierarchiestufe angeforderten Informationen direkt aus einer darunterliegenden Informationshierarchiestufe abgefragt. Für ein stateless CMIP/SNMP Gateway bedeuted dies, daß jede ankommende CMIP-PDU auf eine oder mehrere SNMP-PDU(s) abgebildet wird. Die SNMP-Response(s) wird (werden) anschließend mittels einer oder mehrerer CMIP-Response-PDU(s) zurückgeschickt. Ebenso werden SNMP-Traps auf EventReport von speziellen Instanzen von Managementobjekten abgebildet. Das Gateway speichert keine Managementinformationen aus den MIBs der SNMP-Agenten.
• Zustandsbehaftete (stateful) Komponenten speichern die Informationen einer unteren Informationshierarchie. Für ein stateful CMIP/SNMP Gateway bedeutet dies, daß die Internet-MIBs der SNMP-Agenten komplett oder nur teilweise in einer lokalen Gateway-MIB repliziert werden müssen. Die ankommenden CMIP-PDUs werden nun direkt auf der lokalen Gateway-MIB bearbeitet. Die Informationen in dieser replizierten Gateway-MIB sollen möglichst aktuell sein, wobei temporäre Inkonsistenzen aber unvermeidbar sind. SNMP-Operationen werden nur zur Konsistenzsicherung der lokalen Gateway-MIB benötigt.

Die Vor- und Nachteile der beiden Lösungen in Bezug auf die Performance sind offensichtlich : Je mehr statisch die Managementinformation ist, um so besser ist das stateful Gateway geeignet, denn die Konsistenzsicherung bedarf keiner oder nur weniger Kosten. Ist dagegen die Information dynamisch, wird ein stateless Gateway vorzuziehen sein.
Die Vorteile eines stateful Gateways liegen unter anderem darin, daß Scoping und Filtering direkt in der lokalen MIB ausgeführt werden können und nicht simuliert werden müssen, so wie bei einem stateless Gateway. Dort werden alle ankommenden CMIP-Request direkt in SNMP-PDUs umgewandelt, unter Berücksichtigung und Auflösung von Scopes und Filtern (siehe 4.4.1). Der Preis für diese Vereinfachung im stateful Gateway (siehe 4.4.2) wird aber mit hohen Kosten bezahlt, denn es werden komplexe Algorithmen für das Replizieren der SNMP-MIBs notwendig. Dazu muß ein Caching-Mechanismus implementiert werden, der sicherstellt, daß die Informationen in der lokalen Gateway-MIB möglichst konsistent mit den realen Ressourcen in den SNMP-Agenten sind, die sie ja repräsentieren.
Ein optimales, idealisiertes Gateway würde ein Kompromiß eingehen, der die Vorteile jeder Lösung integriert und die Nachteile vermeidet: für dynamische Managementinformation würde es sich wie ein stateless Gateway, für statische Managementinformation würde es sich wie ein stateful Gateway verhalten. Dazu ist es aber notwendig, daß das Gateway Wissen über das Verhalten der Managementinformation besitzt. Dieses Wissen ist aber nicht in der MIB gespeichert, muß also auf andere Weise beschafft werden.