Die Repräsentation von SNMP-Gruppen im Gateway  

Die SNMP-Gruppen werden in den Internet-MIBs definiert. Sie können nicht kreiert oder gelöscht werden und existieren damit für die gesamte Lebensdauer der jeweiligen SNMP-Agenten.
Die SNMP-Gruppen werden, durch die Übersetzung von Internet-MIBs in GDMO-MIBs, auf OSI-Klassen abgebildet. Dabei werden auch NAME BINDINGs erstellt, die die Lage der Instanzen dieser Klassen in der Containment-Hierarchie festlegen. Aufgrund der fehlenden Enthaltenseinshierarchie im Internet-Informationmodell, wird bei der ,, direkten Übersetzung``, siehe 4.2.1, der Registrierungsbaum der SNMP-Gruppen auf diese NAME BINDINGS und damit auf die OSI-Containment-Hierarchie abgebildet. Anders formuliert heißt das, die NAME BINDINGs der OSI-Klassen, die aus der Übersetzung der SNMP-Gruppen entstanden sind, stellen die Lage dieser SNMP-Gruppen im Internet-Registrierungsbaum dar. Da die SNMP-Gruppen dauerhaft existent sind, ist die Gültigkeit dieser NAME BINDINGs nicht eingeschränkt. Damit können diese NAME BINDINGs direkt nach der Übersetzung in die Metadata Database eingetragen werden, stehen somit dem Gateway und sämtlichen OSI-Managern ständig zur Verfügung und müssen nicht explizit aus den jeweiligen SNMP-Agenten gelesen werden.
Sobald nun ein neuer SNMP-Agent mit Hilfe des Gateways einem OSI-Manager bereitgestellt werden soll, müssen zuerst die Instanzen dieser Klassen, welche die SNMP-Gruppen repräsentieren, kreiert werden (siehe 3.2.4). Dies kann nun rekursiv mit Hilfe der NAME BINDINGs erfolgen: Am Beispiel des Registrierungsbaumes der SNMP-Gruppen der MIB-2 wird ersichtlich, daß die Gruppe ,,mib-2`` allen anderen MIB-2 Gruppen übergeordnet ist, siehe Abbildung 5.3.

 

Abbildung 5.3:   Die Gruppen der MIB-2

16#16

Bei der Übersetzung dieser MIB-2 in eine GDMO-MIB entstehen einerseits für die SNMP-Gruppe ,, mib-2`` ein NAME BINDING mit der SUPERIOR OBJECT CLASS ,,system`` und andererseits für alle anderen SNMP-Gruppen dieser MIB-2 jeweils ein NAME BINDING mit der SUPERIOR OBJECT CLASS ,,mib2``. Als SUBORDINATE OBJECT CLASS erhalten alle NAME BINDINGs den Namen der jeweils aus der Gruppe entstandene OSI-Klasse, siehe Abbildung 5.4.

 

Abbildung:   Einige Klassen und NAME BINDINGs aus der Übersetzung der MIB-2

35#35

Nun können, beginnend bei der Klasse ,,system``, alle NAME BINDINGs aus der Meatdata Database bestimmt werden, welche als SUPERIOR OBJECT CLASS diese Klasse ,,system`` besitzen. Dafür existiert in unserem Beispiel nur ein NAME BINDING: dieses enthält als SUBORDINATE OBJECT CLASS die Klasse ,,mib2``, welche aus der Übersetzung der MIB-2 Gruppe ,,mib-2`` entstanden ist. Es kann nun für diese Klasse eine Instanz kreiert werden. Anschließend werden alle NAME BINDINGs mit dieser Klasse ,,mib2`` als SUPERIOR OBJECT CLASS bestimmt. Diese damit erhaltenen NAME BINDINGs enthalten wiederum jeweils als SUBORDINATE OBJECT CLASS alle Klassen, die die restlichen MIB-2 Gruppen repräsentieren, für die nun entsprechend eine Instanz kreiert werden kann.
An diesem Beispiel wird der angewandte, rekursive Algorithmus für den Aufbau der Containment-Hierarchie für die Klassen, die die SNMP-Gruppen repräsentieren, im Gateway deutlich:
Für eine gegebene Managementobjekt-Klasse bestimme aus der Metadata Database alle NAME BINDINGs mit dieser Klasse als SUPERIOR OBJECT CLASS. Kreiere für jede in diesen NAME BINDINGs enthaltenen SUBORDINATE OBJECT CLASSes eine Instanz und rufe jeweils mit dieser SUBORDINATE OBJECT CLASS die Rekursion erneut auf.
Der Algorithmus beginnt dabei mit der OSI-Klasse ,,system``, da diese als Wurzel in der Enthaltenseinshierarchie dient und daher im IIMC-Übersetzungsalgorithmus (siehe 3.1.1) als ,,Root``-Klasse für die NAME BINDINGs definiert wird [IIMCIMIBTR].

Ergebnis: Für jeden neu zu managenden SNMP-Agenten kann das Gateway anhand der in der Metadata Database gespeicherten NAME BINDINGs sofort seine lokale Gateway-MIB um die Containment-Hierarchie der Instanzen der Klassen, die SNMP-Gruppen repräsentieren, erweitern, ohne auf Informationen aus der MIB dieses SNMP-Agenten zugreifen zu müssen.
Auf die Attribute in diesen Instanzen kann nun beliebig zugegriffen werden, wobei die Werte direkt aus den entsprechenden SNMP-Agenten gelesen werden.