3.3 Anforderungen an die Protokolle

Nicht alle Bedingungen, die ein Managementsystem erfüllen soll, kann man immer auf niederen Ebenen durch einfache Manipulation der physikalischen Datentransportwege und Aufsetzen passender Filter erreichen. Manchmal ist dies nicht möglich oder die Anforderungen sind zu kompliziert. Für solche Fälle muß man in höheren Schichten (meist Schicht 7) passende Maßnahmen ergreifen. Diese dürfen die Anforderungen an die Infrastruktur ergänzen oder auch ersetzen. Ist zum Beispiel kein Tunneling über eine Blackbox-Lösung möglich, so müssen die dazugehörigen Voraussetzungen künstlich geschaffen werden und eine andere (Software)Komponente diese Aufgabe übernehmen.

Als Softwarekomponente kommt im Fall von Dienstvermittlung nur die Implementierung der Protokolle, bzw. Plattformen für diesen Zweck in Frage. Man kann also eine Reihe Anforderungen stellen, welche man an ein Managementsystem im Gesamten stellt, die aber von Softwarekomponenten realisiert werden können oder beachtet werden müssen.

Verschlüsselung:

Einzelne Komponenten des Managementsystems müssen sicher und 'ungestört' miteinander kommunizieren können. Um dies gewährleisten zu können, wird die managementsysteminterne Kommunikation verschlüsselt und signiert. Dadurch kann man gewährleisten, daß die Daten 'unterwegs' nicht verändert wurden und daß sie von keiner gefälschten Komponente gesendet wurden. Es kann zum Beispiel der Teil des IP-Paketes, der konkrete Nutzdaten (außer Absender- und Zieladresse) enthält verschlüsselt werden. Dieses Problem kann man auf Ebene der Hardware und Infrastruktur lösen oder aber auch, in dem das Programm selbst bereits verschlüsselte Informationen sendet. Mögliche Zusatzprotokolle sind: IPSec  und SSL (Secure Socket Layer) .

Proxyfähigkeit:

Ein Proxy ist eine Art Strohmann, der Anfragen eines Clients an den Server weiterleitet, die Antwort vom Server empfängt und sie an den Client zurücksendet. Solche Mechanismen sind nötig, wenn man Protokolle in andere Protokolle umsetzen muß, weil dieser Typ Protokoll zum Beispiel nicht weiter unterstützt wird, man aber die Clientsoftware deswegen nicht verändern kann oder will. Proxies findet man, wenn es darum geht, Daten zu cachen. Häufige Anwendungsgebiete sind Web (Proxy/Cache) und DHCP (Proxy). Allgemein sollten für jeden Service des Managementsystems Proxy-Mechanismen vorgesehen sein. Oft ist das Netzwerk nicht entsprechend anpassbar, so daß man für viele Dienste auf Proxies angewiesen ist (zum Beispiel beim Einsatz einer Firewall).

Bei der Verwendung von Proxies wird ein Teil der Kommunikation zwischen Client und Server leicht modifiziert.

Bei Web-Proxies ist es die Client-Seite, auf der sich das Protokoll leicht verändert. Der Client spricht den Proxy gezielt an.

Bei DHCP ist es die Strecke zwischen DHCP-Relay (so nennt man den DHCP-Proxy) und Server, die entsprechend abgewandelt wird. Für den Client ist die Verwendung des Relays transparent.

An- und Abmeldung bei einem Directory Service:

Manche Ansätze für Dienstvermittlung in einem Computernetz gehen davon aus, daß ein Service, der seine Dienste im Netz zur Verfügung stellt und an Clients vermittelt werden soll, sich aktiv bei einem zentralen Vermittlungs-Service anmelden muß. Nur dann wird er auch an anfragende Clients vermittelt. Diese Information kann man beispielsweise auch nutzen um Ausfälle von Services rechtzeitig zu registrieren und automatisch eingreifen zu können. Jeder Service sollte sich außerdem explizit abmelden können um anzuzeigen, daß es sich um einen beabsichtigten 'Dienstausfall' handelt.

Policy-Fähigkeit:

Ausnahmen bestätigen die Regel. Deshalb ist es möglich jeder Instanz in einem Managementsystem eigene, individuelle Policy-Regeln zu geben. Diese Regeln können unter Umständen globalere Regeln verletzen. Allerdings möchte man nicht immer und überall mit allen eventuell benötigten Regeln arbeiten, sondern das gerade aktuelle Set an Policies dynamisch erweitern können. Deshalb ist es von Vorteil, wenn der sich anmeldende Service eigene Policy-Regeln mit einbringen darf. Diese könnten der Art sein, daß zum Beispiel das allgemeine Nacht-Nutzungsverbot bei diesem sich anmeldenden Drucker-Service nicht gilt, da der hier verwendete Drucker von einer neuen, geräuschlosen Drucker-Generation ist.

Kommunikation mit einem Abrechnungs-Service:

Nicht nur im Kommerziellen Umfeld besteht die Forderung, daß genutzte Dienstleistungen abgerechnet werden können müssen. Dazu muß vom Service, der die Leistung erbringt, mitgeteilt werden, wer gerade wieviel Service-Gut verbraucht hat. Es gibt zwei grundlegende Strategien: entweder der Service selbst meldet einem externen Dienst seine abzurechnenden Beträge oder der externe Dienst befragt in regelmäßigen Abständen den Service. Beide Ansätze sind bereits verbreitet: Um Accountingdaten bei Internet-Providern zu erheben, werden üblicher Weise in regelmäßigen Abständen die Logfiles der Außenrouter abgerufen und ausgewertet. Beim Telephonieren erzeugt die Vermittlungsstelle sogenannte CDRs (Call Data Record) . Diese werden dann an einen Accountingserver geschickt (siehe dazu auch [Hei99]).

Flexible Reaktion auf neue Protokolle:

Das zugrunde liegende Protokoll bzw. die zugrunde liegende Managementplattform darf nicht auf einige bekannte Protokolle beschränkt sein, vielmehr muß es möglich sein, neue Protokolle zu integrieren. Daher ist die Entwicklung eines modularen Ansatzes nötig, der es erlaubt neue Protokolle beliebig zu integrieren. Dies ist möglich, indem man eine zusätzliche Einheit baut, die 'nach außen hin das fremde Protokoll 'spricht' und nach innen, zum Management-System, das interne Protokoll (siehe Abb. 3.2)

  

Abbildung 3.2: modulare Komponente im Managementsystem