Von: Michael Pensler
Immer häufiger sehen sich insbesondere große Unternehmen mit der Forderung konfrontiert, bestimmte Applikationen im Netzwerk bevorzugt zu behandeln. Ein Lösungsansatz ist Policy-based Networking, das allerdings einige Anforderungen an das Netzwerk stellt. So benötigen bestimmte Anwendungen mittlere, aber garantierte Bandbreiten, andere eine geringe Verzögerung oder große Burst-Raten der übertragenen Pakete.
Übertragungsqualität steigern
Der Bedarf, IP-Pakete mit intelligenteren Methoden als dem Best-Effort-Ansatz zu übertragen, wurde bereits vor einigen Jahren erkannt. Die Internet Engineering Task Force (IETF) gründete diverse Arbeitsgruppen, um hierfür Lösungen zu erarbeiten. Diese Task Forces haben zwei Techniken entwickelt, um die Transportqualität in IP-Netzwerken zu erhöhen:
- Ressourcenreservierung auf Flow-Basis:
Dabei wird eine Signalisierung und Reservierung der gewünschten Bandbreite durchgeführt, die für die Dauer des jeweiligen Flows bestehen bleibt. Damit ist es möglich, Anwendungen eine Quality of Service (QoS) zuzuweisen. Das standardisierte IETF-Protokoll heißt RSVP/Intserv, RFC 2205.
- Priorisierung von Paketen ausgewählter und zusammengefasster Flows:
Dieses Konzept klassifiziert und markiert Datenpakete eines Flows am Netzwerkrand und leitet sie anhand der Markierung unterschiedlich priorisiert weiter. Es ist im IETF-Standard Diffserv RFC 2475 festgeschrieben.
Da Diffserv Datenströme in verschiedene Klassen einteilt und mehrere Ströme innerhalb dieser Klassen gemeinsam behandelt, bezeichnet man diese Technologie auch als Class of Service (CoS). Der Sprachgebrauch von QoS und CoS ist uneinheitlich. Wir verwenden den Begriff QoS im folgenden für beide Techniken.
Wenn IT-Abteilungen Service-Levels garantieren wollen, stellen sich zwei Probleme: Zum einen müssen alle Geräte im Netz die Dienstgüten unterstützen. Zum anderen ist es notwendig, dass sie die verwendeten Dienstekennungen identisch interpretieren. Die Verbindung zwischen der Dienstekennung und der anzuwendenden Dienstgüte wird durch Regeln bestimmt, die so genannten Policies. Jede Policy besteht aus einer Bedingung und einer daraus folgenden Aktion.
Das COPS-Rahmenwerk
Eine einzelne Policy lässt sich einfach durch manuelle Konfiguration einer Netzkomponente erstellen. In größeren Netzwerken stößt dieses Vorgehen jedoch schnell an Grenzen. Hier sind Verfahren wie Common Open Policy Service (COPS) nötig, die Konfigurationsregeln automatisch an eine große Anzahl von Geräten verteilen.
Die COPS-Protokoll-Suite wurde ursprünglich entwickelt, um beim Resource Reservation Protocol (RSVP) für die Verteilung und Überwachung der Admission-Regeln zu sorgen. Die IETF erkannte jedoch recht bald die Universalität dieses Ansatzes und baute ihn um weitere Komponenten aus.
COPS definiert drei Grundelemente, die ein Policy-Transaktionssystem bilden (siehe Bild 1):
- Der als COPS-Client bezeichnete Policy Enforcement Point (PEP) setzt die Regeln im Netzwerk durch. Es gibt unterschiedliche Clients, die im selben Netzgerät implementiert sein können, zum Beispiel um sowohl DiffServ als auch IPSec zu unterstützen.
- Der Policy Decision Point (PDP) legt die zentralen Regeln fest und unterstützt gleichzeitig unterschiedliche COPS-Client-Typen.
- Das COPS-Protokoll selbst, das die Policies übermittelt.
Ein wichtiges Ziel bei der Entwicklung des COPS-Protokolls war die Erweiterbarkeit. Jeder Client-Typ kann den COPS-Meldungen eine eigene Struktur und eine eigene Bedeutung verleihen.
Neben COPS standardisierte die IETF mit COPS-RSVP einen Client-Typ für die Behandlung von signalisierten QoS-Requests durch RSVP. COPS-PR definiert einen Client-Typ, der sich universell verwenden lässt, insbesondere für die Festlegung von Diffserv Policies. Er erweitert das COPS-Modell um objektorientierte Eigenschaften.
Die Konfigurations-Informationen werden dabei in speziellen Klassen, den sogenannten Provisioning Classes (PRC), definiert. Eine Instanz einer solchen Klasse wird als Provisioning Instance (PRI) bezeichnet. Sie enthält die Konfigurationsdaten für den PEP. Durch diese Erweiterung lassen sich innerhalb der COPS-Standardfamilie Client-Typen definieren, die unterschiedliche QoS-Konzepte verfolgen. Die IETF spezifiziert gerade einen COPS-Client für IPSec, weitere sind in der Diskussion.
Frage- und Antwortspiel
Das COPS-Protokoll folgt einem einfachen Frage-Antwort-Schema, das eine eindeutige Identifizierung des Clients vornimmt und den COPS-Server stets über den Status des Clients informiert. Während des Verbindungsaufbaus tauschen sich beide über die Fähigkeiten und Limitierungen des Clients aus. Anschließend stellt typischerweise der Client eine Konfigurations-Anforderung (Request), die der Server in der Regel mit einer Entscheidung (Decision) beantwortet. Der Server kann Konfigurationen auch proaktiv zum Client senden.
COPS erlaubt es den Netzkomponenten, mehrere Client-Typen zu unterstützen und für jeden eine Verbindung zu einem anderen PDP zu unterhalten. Dadurch lässt sich die Lösung gut skalieren. Pro Client-Typ darf nur jeweils eine aktive Konfigurations-Information vorliegen. Der Client kann jedoch mehrere Konfigurationen vorhalten, die über den COPS-Server aktivierbar sind. Der Standard spezifiziert weder die Darstellung noch die Speicherung der Policies, etwa in einem Directory oder auf dem Client. Die Art der QoS-Signalisierung und der Anwendung der Policies lässt COPS ebenfalls offen.
Katalog für Policies
Die Klassendefinitionen (PRC) für die Konfiguration der Clients werden in einer Policy Information Base (PIB) gespeichert, die sowohl dem COPS-Server wie den Clients bekannt ist. Der IETF-Draft "Structure of Policy Provisioning Information" (SPPI) definiert die Regeln für die Spezifikation einer PIB. Das verwendete Regelwerk ist Teil der Spezifikation von Management Information Bases (MIB). SPPI gibt sogar einen Algorithmus an, wie sich eine PIB- in eine MIB-Definition umwandeln lässt.
Der Draft "Framework Policy Information Base" (FR-PIB) beschreibt ein Klassengerüst für alle Client-Typen von COPS-PR. Diese Klassen regeln die wesentlichen Eigenschaften, über die alle Clients verfügen. Die Entkopplung der zu übertragenden Inhalte von der Übertragungsform minimiert den Aufwand für die Integration neuer Anforderungen deutlich.
Zu den wichtigsten Eigenschaften einer PIB zählen:
- Rollen und Rollenkombinationen:
Konfigurationsregeln lassen sich über Rollen festlegen und sind dadurch vom Interface unabhängig. Die Zuordnung zu einem Interface setzt die Regel in Kraft.
- Multiple PIB-Instanzen:
Sie erlauben es, unterschiedliche Konfigurationsregeln auf den PEP zu übertragen und zu einem späteren Zeitpunkt zu aktivieren.
- Repräsentation der Fähigkeiten:
Jeder PEP hat spezielle Fähigkeiten, die er dem PDP übermittelt.
- Repräsentation der Limitierungen:
Auch die Limitierungen eines PEP werden dem PDP mitgeteilt.
Die Klassen einer PIB bestehen aus drei Gruppen: Basisklassen für grundlegende Funktionen, Klassen für die Gerätecharakteristik sowie Klassifizierer-Klassen mit Filtermöglichkeiten für IP und Ethernet.
Neben den PIBs, die eine neue Art der Kommunikation mit den PEPs definieren, spezifiziert COPS auch herkömmliche Verfahren zur Steuerung von Netzkomponenten wie beispielsweise SNMP (Simple Network Management Protocol). In der COPS-MIB sind weitere Funktionen standardisiert, die ein einfaches Client-Management ermöglichen. Da die meisten Netzgeräte bereits für SNMP konfiguriert sind, lässt sich eine COPS-Konfiguration auf diesem Weg einfach im Netzwerk verbreiten. Zusätzlich stellt die COPS-MIB Status-Monitoring und Statistikfunktionen bereit.
Policies konfigurieren
Die Formulierung von Policies erfolgt auf drei Ebenen (siehe Bild 2):
- Die oberste Ebene definiert High-Level-Anforderungen, die sich aus kritischen Geschäftsprozessen ergeben.
- Die abstraktere zweite Ebene formuliert Policies geräteunabhängig als Service Level Agreements (SLA). Für die Übersetzung der Geschäftsprozess-Policies sorgt der Policy-Administrator.
- Um die Policies auf dem PDP oder PEP zu speichern, werden sie von geräteunabhängigen in gerätenahe umgewandelt, die so genannten Service Level Objectives (SLO).
Ein Beispiel soll den Unterschied zwischen diesen Policy-Arten deutlich machen. Der Manager einer IT-Abteilung möchte sicherstellen, dass VoIP über das Firmennetzwerk mit hoher Sprachqualität funktioniert. Diese Policy auf Geschäftsprozessebene bringt er in eine abstrakte, geräteunabhängige Form, die Delay und Bandbreitenbedarf definiert, und legt sie in einem zentralen Verzeichnis ab. Die Regel könnte zum Beispiel lauten: "Garantiere für VoIP-Verbindung eine geringe Verzögerung und eine Bandbreite von 100 kBit/s." Anschließend übermittelt der PDP diese Vorgabe an die COPS-Clients.
Directory-enabled Networking
In heterogenen IT-Umgebungen lassen sich Service-Levels nur dann erfolgreich implementieren, wenn einheitliche und skalierbare Policies verfügbar sind. Die Policy Working Group der IETF erarbeitet Standards für SLAs. Sie stützen sich auf die Arbeiten der Distributed Management Task Force (DMTF) zum Common Information Model (CIM). Dabei handelt es sich um ein objektorientiertes Modell, das Managementdaten beschreibt.
In intensiver Zusammenarbeit mit der IETF entstand aus CIM das Policy Core Information Model (PCIM), das allgemeine Policy-Informationen definiert. Es basiert auf dem CIM-Schema Version 2.2 und liegt derzeit als Request for Comment (RFC) vor. PCIM beschreibt die Strukturen für Klassengerüste zur Aufnahme von Management-Informationen. QoS-orientierte Policies werden in QPIM definiert, einem Modell, das auf objektorientierter Basis die Repräsentation von QoS-Policies beschreibt. QPLS gibt vor, wie ein mit PCIM formuliertes Klassengerüst LDAP-konform übersetzt und in einem LDAP-Verzeichnis gespeichert wird.
Die Interpretation und Übersetzung der LDAP-Informationen in PIB-konforme Daten wurde explizit dem PDP überlassen. Es ist davon auszugehen, dass die PDPs verschiedener Hersteller diese Informationen unterschiedlich übersetzen. Deshalb sollten nur PDPs desselben Anbieters eingesetzt werden.
Policy-Management
Ein Managementsystem, das Policy-Informationen im Netzwerk mithilfe der beschriebenen Protokolle verteilt, muss sich an die Standards halten. Die High-Level-Business-Policy bringt der Systemverantwortliche mit Hilfe eines Policy-Administrators in eine geräteunabhängige, netzweit gültige Policy und speichert sie in einem LDAP-Verzeichnis. Die Verbindung zwischen QPLS und RAP-FR stellt ein Policy-Server her. Mit QDDIM entwickelt die IETF derzeit ein QPIM ähnelndes Informationsmodell, das beschreibt, wie sich Policy-Informationen in einer QoS-fähigen Netzkomponente auswirken. Allerdings fehlen noch Festlegungen, wie sich die Informationen dieser Klassen beispielsweise in LDAP ablegen lassen und wie ein Policy-Server sie auf eine PIB abbilden kann.
Für die Umwandlung der Netz-Policies in gerätespezifische Policies ist der PDP verantwortlich. Er lädt sich diese Informationen aus der Verzeichnisstruktur und konfiguriert die Netzgeräte. Allerdings existiert noch kein Draft, der diese Umwandlung beschreibt. Die Hersteller implementieren deshalb hierfür eigene Lösungen. Die gerätespezifischen Policies werden als PRIs gespeichert und mithilfe von COPS auf die Clients verteilt. Dazu haben die Clients dem Policy-Server die Rollen mitgeteilt, denen ihre Interfaces zugeordnet sind.
Voraussetzungen und Vorteile
Wer in einem Netzwerk eine Policy-Struktur einführen möchte, sollte zunächst analysieren, ob die Infrastruktur die Voraussetzungen erfüllt. Wichtigstes Kriterium ist, dass die Netzkomponenten QoS-fähig sind, das heißt Diffserv oder Intserv unterstützen. Die Edge-Geräte müssen in der Lage sein, Datenflüsse zu klassifizieren und zu markieren. Der Core-Bereich muss die Markierungen auswerten können.
Das Policy-Deployment beginnt in der Regel dort, wo das größte Einsparpotenzial vermutet wird. Dies ist zweifelsohne bei der Weitverkehrsanbindung der Fall. Hier lassen sich mit Hilfe von QoS-fähigen Netzkomponenten und entsprechenden Policies deutliche Verbesserungen der Netzwerkleistung erzielen. Im firmeninternen LAN liefert COPS das Rüstzeug, um kritische Applikationen unternehmensweit mit der gewünschten Qualität bereitzustellen. (cl)
Zur Person
Michael Pensler
ist als Systems-Engineer bei Nortel Networks tätig.