Die Behandlung von SNMP-Traps  

Als letzte Aufgabe, um damit die Gatewayarchitektur zu vervollständigen, fehlt noch die Eigenschaft, SNMP Traps bzw. InformRequest-PDUs auf OSI-Notifikationen (siehe 3.2.1) abzubilden.
Diese Funktionalität ist aus dem Blickwinkel des TMN-Referenzmodells heraus die Aufgabe der Q Adaptor Function (QAF). Es wird eine Schnittstelle ( m-Interface) zwischen einer Operations Systems Function (OSF) und einer nicht-OSI-Komponente bereitgestellt. In diesem Fall handelt es sich bei dem m-Interface um eine Schnittstelle zwischen CMIP und SNMP, wobei die Kommunikation bei der Bearbeitung von Traps bzw. InformRequest-PDUs nur in eine Richtung abläuft, vom SNMP-Agenten zu dem Gateway (QAF). Das Gateway bildet die empfangenen Traps bzw. InformRequest-PDUs auf die in 3.1.1 vorgestellte generische Notifikation ab und löst deren Weiterleitung als Notifikation einer Instanz eines Managementobjekts aus. Welche Instanz dies im speziellen sein soll, wird in 6.1.2 beschrieben.
Das m-Interface und damit die Möglichkeit, Traps bzw. InformRequest-PDUs zu empfangen kann mit der in 3.2.1 vorgestellten Resource Access-Komponente realisiert werden. Diese wird dazu in einer neuen Gatewaykomponente mit dem Namen TrapController integriert. Diese stellt einen relativ eigenständigen Bereich im Gateway dar, da die Kommunikation nur, von Traps bzw. InformRequest-PDUs ausgelöst, in Richtung spezifischer Agententeil abläuft. Der TrapController bildet zusammen mit der SNMP-API den SNMP-Manager des Gateways und kann mit einer Instanz der Klasse ,,snmpComEntity`` selbst überwacht und gesteuert werden.

Die Abbildung 5.7 zeigt den vollständigen Überblick über die Architektur des CMIP/SNMP Gateways, dessen Implementierung in Kapitel 6 folgt. Die Zahlen in den Klammern entsprechen folgenden Bemerkungen:

 

Abbildung:   Die vollständige Architektur des CMIP/SNMP Gateways

38#38

1.

In der Metadata Database werden alle aus der Übersetzung der Internet-MIBs in OSI-MIBs entstandenen NAME BINDINGs eingetragen.

2.

Sobald ein neuer SNMP-Agent für das OSI-Management bereitgestellt werden soll, werden nach 5.2.1 die Instanzen für alle SNMP-Gruppen kreiert

3.

und die SNMP-Tabellen in der Global Polling-Komponente angemeldet (siehe Algorithmus in Abbildung 5.5).

4.

Damit, durch diese Anmeldung, werden die Instanzen in der Gateway-MIB, die die SNMP-Tabellenzeilen repräsentieren, kreiert.

5.

Die Global Polling-Komponente überprüft schließlich regelmäßig, ob Veränderungen in der SNMP-Tabelle auftreten und damit, ob entsprechend Instanzen gelöscht bzw. kreiert werden müssen.

6.

Der Zugriff auf die Attribute in den Instanzen wird auf Methodenaufrufe in der Komponente SNMP-API abgebildet. Diese Methodenaufrufe lösen schließlich die benötigten SNMP-PDUs aus.

7.

Der relativ eigenständige TrapController hört den Port 162 ständig ab und kann somit Traps bzw. InformRequest-PDUs empfangen.

8.

Diese werden bestimmten Instanzen von Mangementobjekten zugeordnet und auf OSI-Notifikationen abgebildet.