Die Einbettung des Gateways in die Architektur
Die Einbettung des Gateways in die Agentenarchitektur der IBM TMN WorkBench for AIX

Das Ziel dieses Abschnittes ist die Architektur eines CMIP/SNMP Gateways. Die Aufgabe dabei besteht darin, zu prüfen, inwieweit dieses Ziel (Top-Down Sichtweise aus Kapitel 4) mit den vorhandenen Werkzeugen (Bottom-Up Sichtweise aus Kapitel 3) realisierbar ist.
Mit der Überlegung, daß ein stateless Gateway eine einfachere Implementierung verspricht, sollte die erste Architektur des Gateways auf der Grundlage einer stateless Komponente beruhen. Da sehr schnell gezeigt werden kann (siehe unten), daß ein reines stateless Gateway nicht auf die Agentenarchitektur der IBM TMN WorkBench for AIX abgebildet werden kann, wird schließlich die Architektur eines CMIP/SNMP Gateways vorgestellt, welches sowohl stateless als auch stateful Ansätze integriert.

Es soll zuerst der Versuch gemacht werden, ein stateless Gateway in die Agentenarchitektur der IBM TMN WorkBench for AIX einzubetten (siehe auch Abbildung 5.1).

 

Abbildung 5.1:   Die Einbettung eines stateless Gateways in die Agentenarchitektur

33#33

Dazu wird es nötig sein, Name Mapping und Service Mapping (siehe 4.4.1) in diese Agentenarchitektur einzubinden. Das heißt, für einen am Infratop ankommenden CMIS-Request, der ein oder mehrere ,,remote Object(s)`` enthält, muß für diese(s) das Name Mapping und Service Mapping durchgeführt werden. Es müssen zuerst die Instanzen der Managementobjekte bestimmt werden, die im Scope und Filter ausgewählt werden, um anschließend diesen CMIS-Request auf diesen selektierten Instanzen auszuführen.

Das Ausführen von Scopes und die Replikation des Requests übernimmt aber in der IBM-Agentenarchitektur schon die Naming and Replication-Komponente. Diese speichert und verwaltet dazu alle existierenden Instanzen von Managementobjekten in der Containment-Hierarchie. Das bedeutet aber auch, daß jede Instanz eines Managementobjekts im OSI-Agenten zuerst kreiert werden muß, bevor auf sie, mit Hilfe eines CMIS-Requests, zugegriffen werden kann, siehe 3.2.4. Speziell für Klassen, die aus der Übersetzung der Internet-MIBs in GDMO-MIBs entstanden sind und damit SNMP-Ressourcen repräsentieren, heißt das:
Es müssen zuerst Instanzen dieser Klassen kreiert und damit (unter anderen) die Containment-Hierarchie im Infratop aufgebaut werden, bevor auf diese ,,remote Objects`` zugegriffen werden kann. Diese ,,remote Objects`` repräsentieren definitionsgemäß SNMP-Gruppen und SNMP-Tabellenzeilen (siehe ,,direkte Übersetzung``, 4.2.1).
Es müssen für alle existierenden SNMP-Gruppen entsprechende Instanzen kreiert werden, die diese im Gateway repräsentieren.
Die Existenz von Tabellenzeilen und damit die Möglichkeit, eine entsprechende Instanz zu kreieren, kann nur dadurch bestimmt werden, daß mittels einer oder mehrerer SNMP-PDU(s) der Index dieser Tabellenzeile herausgefunden wird. Dieser Index wird definitionsgemäß zu dem Relative Distinguished Name der Instanz. Damit wird aber Managementinformation aus der MIB des SNMP-Agenten im Gateway gespeichert. Da eine Tabellenzeile auch von dem SNMP-Agenten gelöscht bzw. eine neue erstellt werden kann, muß das Gateway zusätzlich diese Tabelle regelmäßig auf neue bzw. veraltete Zeilen hin überprüfen (siehe 5.2.2).
Dies steht aber im Widerspruch zu dem stateless Ansatz, welcher ja besagt, daß keine Managementinformation aus dem SNMP-Agent gespeichert werden soll/darf, damit auch nicht die Existenz von Instanzen von Managementobjekten, die SNMP-Tabellenzeilen repräsentieren. Es soll jede Anforderung von einer höheren Hierarchiestufe (=OSI-Manager) auf die darunterliegende Hierarchiestufe und damit auf den SNMP-Agenten abgebildet werden. Aus diesen Gründen folgt, daß ein reines stateless Gateway wegen der Repräsentation der SNMP-Tabellenzeilen durch Instanzen von Managementobjekten und damit dem Speichern von Managementinformation aus der MIB des SNMP-Agenten, nicht auf die Agentenarchitektur der IBM TMN WorkBench for AIX abgebildet werden kann.

Fazit: Das Kreieren von Instanzen, die SNMP-Ressourcen repräsentieren, steht im Widerspruch zum stateless Ansatz. Speziell wird bei der Repräsentation von SNMP-Tabellenzeilen in der Gateway-MIB durch Instanzen Managementinformation gespeichert (der Index der jeweiligen Zeile wird zum Relative Distinguished Name). Die Besonderheit von SNMP-Gruppen, daß sie in einem SNMP-Agenten für die gesamte Lebensdauer existieren, ermöglicht es, die Informationen für das Kreieren von Instanzen der Klassen, die diese SNMP-Gruppen repräsentieren, direkt aus der MIB-Definiton (und diese ist in der Metadata Database gespeichert) zu lesen. Dadurch kann es vermieden werden, Managementinformation vom SNMP-Agenten abzufragen und im Gateway zwischenzuspeichern, siehe 5.2.1.
Der Zugriff auf die Attribute in den Instanzen, die die SNMP-Variablen repräsentieren, kann aber schließlich nach dem stateless Ansatz erfolgen, das heißt, bei einem lesenden Zugriff soll der Wert mittels einer SNMP-GetRequest-PDU bzw. bei einem schreibenden Zugriff soll der Wert mittels einer SNMP-SetRequest-PDU, direkt von bzw. in dem SNMP-Agenten gelesen bzw. geschrieben werden.
Die Agentenarchitektur der IBM TMN WorkBench for AIX verlangt, daß eine vollständige Containment-Hierarchie existiert, das heißt, jede im SNMP-Agenten gerade vorhandene Ressource muß aktuell in der Gateway-MIB durch Instanzen und deren Attribute repräsentiert werden.
Um nicht von einem reinen stateless Gateway zu einem reinen stateful Gateway überzugehen, liegt eine Gatewayarchitektur nahe, die sowohl stateless als auch stateful Ansätze integriert: All jene SNMP-Ressourcen, welche aufgrund der Einschränkungen der IBM TMN WorkBench for AIX nicht direkt auf SNMP-PDUs abgebildet werden können (dem entsprechen SNMP-Gruppen und SNMP-Tabellenzeilen), weil sie durch Instanzen im Gateway repräsentiert werden müssen (und somit die Containment-Hierarchie aufbauen), sollen nach dem stateful Ansatz implementiert werden. Alle anderen SNMP-Ressourcen (dem entsprechen alle SNMP-Variablen, sie werden durch Attribute in den OSI-Klassen dargestellt) sollen nach dem stateless Ansatz realisiert werden, das heißt, der Wert eines OSI-Attributs soll direkt aus dem SNMP-Agenten gelesen werden. Diese Gatewayarchitektur stellt Abbildung 5.2 dar.

 

Abbildung:   Die vorläufige Architektur des Gateways

34#34

Die Abbildung zeigt, daß im Gateway Instanzen für SNMP-Gruppen und SNMP-Tabellenzeilen existieren. Die SNMP-Tabelle wird regelmäßig überprüft (1), ob die in der MIB durch Instanzen repräsentierten Tabellenzeilen aktuell sind bzw. ob neue Tabellenzeilen entstanden sind und damit neue Instanzen kreiert werden müssen (2). Die Attributwerte werden bei jedem Zugriff direkt mittels SNMP-GetRequest-PDUs aus den entsprechenden SNMP-Variablen im SNMP-Agenten gelesen (3).
Lösungsmöglichkeiten für die Repräsentation von SNMP-Gruppen bzw. -Tabellenzeilen im Gateway wurden bereits in der Begründung, daß ein reines stateless Gateway nicht in die Agentenarchitektur eingebettet werden kann, angesprochen. Dies soll aber in den nächsten beiden Abschnitten detailliert vertieft werden: