Das Event Channel-Modell

  Der allgemeine Aufbau eines Structured Events wurde bereits in Kapitel 2.3.2 beschrieben. Im weiteren soll geschildert werden, wie sich der Event Service in das vorhandenen Managementmodell einfügt, und wie ein Structured Event für das bestehende Einsatzszenario aussehen muß.

Der Switch-Agent muß einen eigenen Event Channel kreieren, an den sich die Managementanwendung und der Agent binden. Der Switch-Agent benutzt den Event Channel, um Zustandsänderungen des Switch in Form von Notifikationen an den Manager zu senden. Die gesendeten Notifikationen sind dabei jeweils im Rahmen eines structured events verpackt, wie er in Abbildung 2.14 dargestellt ist.

Für die Managementsoftware von Bedeutung ist die Information über neu angeschlossene Systeme an den Switch. Die Zustandsänderung äußert sich somit durch das Hinzufügen oder Entfernen einer DTE an einen Port des Switch. Problematisch ist dabei nur das Entfernen einer DTE, da der Switch davon nicht explizit benachrichtigt wird. Stattdessen sorgt ein Timeout-Parameter dafür, daß DTE's, die eine gewisse Zeit keine Frames verschickt haben, aus der Switchingtabelle entfernt werden. Für das Modell des Switch-Agent bedeutet dies, daß nur das Hinzufügen eines neuen Systems angezeigt wird. Diese Vorgehensweise ist nicht unbedingt eine Einschränkung, da aus Sicht des zugrundeliegenden Einsatzszenarios die Managementsoftware für die VLAN-Einteilung neu angeschlossener Systeme zuständig ist. Unterliegt ein angeschlossenes System einem Timeout, so stuft der Switch dieses System als neu ein, sobald er wieder ein Frame von diesem erhält.

Der Switch-Agent sendet beim Hoch- und Herunterfahren ein festgelegtes Datenpaket in Form eines structured events an den sogenannten wellknown event channel des Managementsystems, der im folgenden als AgentInitChannel bezeichnet wird. Dadurch erfährt dieses, daß ein neuer Agent gestartet oder dieser beendet wurde.

Der Aufbau der vom Switch Agent gesendeten Structured Events in den wellknown event channel wird in Abbildung 4.3 dargestellt. Bezüglich der Notation wurden unter Berücksichtigung von [Kem98], [Rad98] und [Dem98] folgende Festlegungen vereinbart:

1.

Der Event Header besteht lediglich aus dem Fixed Header. Es gibt keinen Variable Header. Die Feldbelegungen sehen wie folgt aus:

domain_type

wird mit dem Wert Systemmanagement belegt.

event_type

bezeichnet die Aktion: agentUp, falls der Agent hochgefahren wird und agentDown, falls er heruntergefahren wird.

event_name

ist nicht von Bedeutung und wird deswegen freigelassen.

2.

Der Event Body enthält folgende Felder:

agent_type

zeigt den Typ des Agenten an. Im Falle des PC-basierten Switch ist der Wert des Feldes PCSwitchAgent.

agent_name

gibt den compound name des Agenten in Form des erweiterten Domänenbezeichners ([Rad98]) als String an. Da sich an den AgentInitChannel mehrere Agenten anbinden, soll dieses Feld helfen, die Quelle des erhaltenen Events festzustellen. Der Switch-Agent übergibt den Wert mnm.domain/PCSwitch.motype/pcswitch_1.agent.

event_channel_name

bezeichnet den compound name des Event Channels, an den sich der Agent gebunden hat. Dieser kann zuvor vom Agenten kreiert worden sein. Die Wertbelegung für den Switch-Agent ist PCSwitch.

Zusätzlich zu diesen drei Feldern können im Filterable Body noch zusätzliche Felder definiert werden. Zu beachten ist lediglich, daß die Belegung des Wertefeldes auf die Datentypen string, int und boolean eingeschränkt ist.

Der Remaining Body wird nicht benötigt und bleibt daher leer.

  

Abbildung: Event-Struktur für das An- und Abmelden des Agenten