Beschreibung
Verfahren zur Ressourcen-Reservierung für ein Inter-Domain- Routing mit Dienstgütemerkmalen
Die Erfindung betrifft ein Verfahren zur Bereitstellung von Ressourcen für ein Inter-Domänen-Routing, einen Randknoten mit Mitteln zur Durchführung des Verfahrens und einen Server zur Unterstützung des Verfahrens.
Die Erfindung liegt auf dem Gebiet der Kommunikationsnetze und liefert einen Beitrag zur Weiterentwicklung von Datennetzen für eine Übertragung von Echtzeitverkehr unter Einhaltung von Dienstgütemerkmalen.
Das derzeit wichtigste Datennetz, das Internet, ist genau genommen ein Netzverbund, welcher aus einer großen Anzahl (aktuell über 1.7000) von Netzen besteht. Diese Netze werden in der Nomenklatur der Internetexperten üblicherweise als auto- nome Systeme (autonomous System, abgekürzt AS) oder Routing- Domänen (routing do ain) bezeichnet. Innerhalb dieser Routing-Domänen sind Protokolle für das Routing bzw. den Transport von Datenpaketen definiert (z.B. open shortest path first (OSPF) Protokoll) .
Das Zusammenspiel autonomer Systeme im Internet, d.h. die„ netzübergreifende Weiterleitung von Datenpaketen bzw. IP- Paketen (IP: Internet Protokoll) über die Grenzen einzelner IP—Netze hinweg, wird mit dem Inter-Domänen-Routing Protokoll (inter domain routing protocol) BGP (BGP: border gateway pro- tocol) geregelt, welches in dem RFC1771 (RFC: request for comments) beschrieben ist. Im Rahmen dieses Protokolls bauen benachbarte Randrouter oder Randknoten sogenannte BGP- Peering-Sessions auf und tauschen über UPDATE Nachrichten Routing-Informationen aus. Mittels BGP lernt eine Routing-
Domäne_ welche IP-Adressen über welche Routen erreichbar sind. Dabei sind Routen hier als netzübergreifende Routen auf der
Ebene autonomer Systeme zu verstehen und werden als Sequenzen von AS—Nummern kodiert : Für diesen Zweck sind autonomen Systemen eindeutige AS-Nummern zugeordnet. Soll Verkehr auf eine neue Route umgelegt werden, dann gibt ein Randrouter mittels einer UPDATE Nachrichte eine Routenänderung bekannt (Bekanntgabe einer neue Route, Zurücknahme einer bestehenden Route, oder beides) . Ein solche Routenänderung breitet sich im allgemeinen über weitere UPDATE Nachrichten von Netz zu Netz über weite Teile des Internets hinweg aus. Weiter entfernte Netze erhalten im allgemeinen über mehrere Wege mehrere
UPDATE Nachrichten und sehen verschiedenen Routen, aus denen sie die aus ihrer Sicht beste Route auswählen. Da UPDATE Nachrichten über verschiedene Wegen im allgemeinen mit deutlich unterschiedlichen Laufzeiten eintreffen, lernt ein Netz die alternativ verfügbaren Routen erst nach und nach. Während dieses Lernprozesses wird ein Netz den betroffenen Verkehr im allgemeinen mehrfach auf alternative Routen verschieben bzw. umlenken. Eine Verschiebung erfolgt immer dann, wenn mit Eintreffen einer weiteren UPDATE Nachricht eine bessere Route bekannt wird. Das heißt, mit dem ersten UPDATE wird ein Kon- vergenzprozess gestartet, der nach Messungen durchschnittlich etwa drei Minuten dauert. Während der Konvergenzzeit wird der betroffene Verkehr im allgemeinen mehrfach auf wechselnde Routen umgelegt bzw. umgeleitet und es muss mit erheblichen Verzögerungen von IP-Paketen und hohen Paketverlustraten gerechnet werden. ..3
Herkömmliche Datennetze bieten daher bzgl. der Übertragungsqualität eine sogenannte „best effort" Übertragung, d.h. eine Übertragung, welche keine Einhaltung von Qualitätsmerkmalen oder Dienstgütemerkmalen (z.B. Maximale Verzögerung, maximale Verlustrate, ... ) garantiert.
Zukünftig sollen IP-Netze auch Anwendungen unterstützen, bei denen Echtzeitverkehr, d.h. Sprach—, Video— und Datenströme, übertragen werden. Für diesen Echtzeitverkehr wird ein schneller und zuverlässiger Transport von IP-Paketen benö-
tigt, d.h. Transportdienste die die Einhaltung von Dienstmerkmalen oder Quality of Service (QoS) Parametern garantieren. Dafür sollen zukünftige IP-Netze, neben den traditionellen "best effort" Diensten, neue Übertragungsdienste bereit- 5 stellen, die dem Verkehr die benötigten Bandbreiten durchgängig verfügbar machen und IP-Pakete mit geringen, kaum schwankenden Verzögerung und sehr geringen Paketverlustraten zuverlässig zum Empfänger übertragenen. Diese neuen Dienste werden im Folgenden auch QoS-Dienste und der von ihnen transportier-
10 te Verkehr QoS-Verkehr genannt. Innerhalb von einzelnen Routing-Domänen gibt es teilweise schon standardisierte Ansätze für die Übertragung von QoS-Verkehr innerhalb von Routingdomänen, welche in der Regel eine Kennzeichnung des QoS- Verkehrs und die Reservierung von Bandbreite beinhalten. Bei-
15. spiele sind die Verwendung des DiffServ (Differentiated Services) Konzeptes (standardisiert von der IETF in RFC2474 und RFC2475) oder des MPLS Protokolls (MPLS: multi-protocol label switchung) in Verbindung mit RSVP (ressource reservation pro- tocol) .
20 Da das Internet ein Zusammenschluss einer wachsenden Anzahl einzelner IP-Netze bzw. autonomer Systeme (AS) ist, die von unterschiedlichen Organisationen verwaltet und gesteuert werden, müssen QoS-Dienste in diesem Verbund netzübergreifend
25 zur Verfügung gestellt werden. Es ist beabsichtigt, dafür Ressourcenmanagementsysteme eingesetzt, die dem QoS-Verkehr die für zugesicherte Dienstgüten erforderlichen Ressourcen netzübergreifend bereitstellen. Ein Ansatz ist durch das BGRP (border gateway reservation protocol) gegeben.
30 Die Erfindung hat zur Aufgabe, die Ressourcen-Reservierungen für Inter-Domänen-Routing zu optimieren.
Die Erfindung beruht auf der Erkenntnis, dass durch eine Ko- 35 ordinierung von Ressourcen-Reservierungen und Routen- Änderungen beim Inter-Domänen-Routing die Übertragungsqualität verbessert werden kann.
Er indungsgemaß wird vorgesehen, vor oder gleichzeitig zu einer Routenänderung einer Inter-Domanen-Route, d.h. vor oder gleichzeitig zu dem umlenken oder Umlegen (rerouting) von Verkehr auf eine neu kommunizierte Inter-Domanen-Route eine Nachricht zu einem Ressourcenmanagement zwecks einer Ressourcen-Reservierung für die neue Route gesendet wird. Auf djese Weise wird frühzeitig ein Reservierungsprozess in Gange gesetzt. Die Umlenkung von Verkehr kann bis zu dem Zeitpunkt verzögert werden, bis eine Bestatigungsnachricht von dem Ressourcenmanagement erhalten wird. Der Verkehr kann dann solange über die alte Route gelenkt werden. Wenn das Ressourcenmanagement die Bestatigungsnachricht erst nach Reservierung der Ressourcen sendet, ist sichergestellt, dass die für die Uber- tragung benotigte Bandbreite zu Verfugung steht. Ist die Ressourcenreservierung nicht erfolgreich, so kann diese Tatsache von dem Ressourcenmanagement zwecks Beeinflussung der Routenauswahl kommuniziert werden. Ein weniger konservatives Vorgehen, welches m der Regel eine schnellere Umlenkung von ver- kehr auf die neue mitgeteilte Route erlaubt, ist z.B. die Umlenkung schon vor dem Erhalt der Bestatigungsnachricht zu starten oder durch das Ressourcenmanagement schon den Erhalt der Nachricht (und nicht erst die abgeschlossene Reservierung) bestätigen zu lassen. Dabei wird davon ausgegangen, dass die Reservierung in der Regel erfolgreich sein wird.
Es ist sinnvoll, das Vorgehen davon abhangig zu machen, ob QoS-Verkehr durch die Umlenkung betroff n st . Für sogenannten "best effort" Verkehr ist e ne erfolgreiche Bandbreiten- reserv erung nicht unbedingt erforderlich. Diese kann berücksichtigt werden, indem das Netzwerkmanagement die Reservierung vor der Bestätigung abschließt, wenn QoS-Verkehr von der Umlenkung betroffen ist, und anderenfalls die Bestätigung gleich nach Erhalt der Anforderung sendet. Möglich ist auch, e ne Nachricht zur Ressourcen-Reservierung an das Ressourcenmanagement nur dann zu senden, wenn QoS-Verkehr betroffen ist. Bei einer Umlenkung eines Teilstromes kann e ne anfang-
liehe Reservierung für den Gesamtstrom vorgenommen werden und diese Reservierung dann mittels eines Erneuerungs- oder Refresh-Mechanismus angepasst werden.
Durch die Erfindung wird sichergestellt, dass QoS-Verkehr mit minimalen Störungen der zugesicherten Dienstgüten umgelenkt werden kann, da zum Zeitpunkt des Umlenkens des Verkehrs die benötigten Ressourcen schon bereitgestellt sind bzw. die für das Umlenken oder Umrouten und Reservieren von Ressourcen notwendigen Prozesse frühestmöglich parallel ablaufen. Die Erfindung erhöht so die Verfügbarkeit von QoS-Diensten und vereinfacht das Ressourcemanagement, welches bei einer Routenänderungen nach olgenden Reservierung Routing—Aktivitäten aufspüren müsste und erst zeitverzögert reagieren könnte.
Die Erfindung kann besonders vorteilhaft im Internet eingesetzt werden, wo das Inter-Dömänen-Routing mittels dem BGP Protokoll gesteuert wird. Aus verschiedenen Gründen, wie Ver- bindungs- und Knotenausfälle, Traffic-Engineering und Verän- derungen der AS-Topologie und Geschäftsbeziehungen, wird netzübergreifender Verkehr häufig auf neue netzübergreifende Routen umgelegt. Wenn eine Routing-Dom ne über BGP mittels UPDATE-Nachrichten eine neue Route bekannt gibt, wird ein Konvergenzprozess eingeleitet, während dem alle betroffenen Routing-Domänen nach neuen stabilen netzübergreifenden Routen suchen. ährend dieser Konvergenzzeit in der Größenordnung von Minuten muss mit mehrfachen Routenwechseln gerechnet werden. Herkömmlich wird betroffener Verkehr während dieses Zeitraums durch große, stark schwankenden Verzögerungen und hohen Paketverlustraten beeinträchtigt. Durch die vorangehende oder gleichzeitige Ressourcen-Reservierung stellt die Erfindung die Dienstgüte von QoS-Diensten beim Umrouten netzübergreifender Verkehrsströme in einem Maß sicher, wie sie mit einer loseren Kopplung von Routenänderung und Ressourcen- Reservierung nicht gewährleistet werden könnte.
Das Ressourcenmanagement kann durch einen Prozess gegeben sein, welcher auf einem Rechner läuft. Wenn Ressourcenmanagement und Routing durch Prozesse auf einem Rechner gegeben sind, ist es sinnvoll, sie beide auf demselben Rechner (in der Regel ein Randknoten oder Randrouter einer Domäne) ablaufen zu lassen. Dadurch ist es möglich, eine lokale (d.h. rechnerinterne) Schnittstelle für den Austausch von Nachrichten zwischen den Prozessen vorzusehen.
Bei dem Ablauf von Ressourcenmanagementprozessen auf Randknoten einer Domäne kann sich die Situation ergeben, dass eine geänderte Route, welche einem ersten Randknoten der Domäne kommuniziert wird, über einen zweiten Randknoten führt und dass daher eine Ressourcenreservierung durch einen Ressour- cenmanagementprozesse auf dem zweiten Randknoten erforderlich ist. Für diesen Fall ist es sinnvoll, dass ein Ressourcenmanagementprozess auf den ersten Randknoten, welchem die Nachricht zur Ressourcen-Reservierung gesendet wird, mit dem Res- sourcenmanagementprozess auf dem zweiten Randknoten zwecks Ressourcen-Reservierung kommuniziert.
Für die Kommunikation zwischen verschiedenen Ressourcenmanagementprozessen ist es hilfreich, eine Zuordnung von Ressour- cenmanagementprozess und zugehörigen Randrouter zu haben, auf welche zwecks Adressierung anderer Ressourcenmanagementprozesse zugegriffen werden kann. Diese Zuordnung ist. vorzugsweise auf einem zentralen Server der Domäne zugänglich.
Die Erfindung wird im Folgenden anhand einer Figur näher er- läutert.
Die Figur zeigt 5 autonome Systeme AS1, AS2, ..., AS5. An AS1 ist das Netz Nl angeschlossen, in dem die Endsysteme mit den IP-Adressen mit dem Prefix 10.10.10.0/24, d.h. 10.10.10.0 bis 10.10.10.255 erreichbar sind. Dabei besteht der Prefix
10.10.10.0/24 aus einer IP-Adresse: 10.10.10.0, und einen Maskenlänge: 24, und steht für alle IP-Adressen, die in den
ersten 24 Bit (Maskenlänge) mit der angegebene Adresse 10.10.10.0 übereinstimmen, d.h. 10.10.10.0 bis 10.10.11.255. Die Figur zeigt nur einen Teil der beteiligten Router, nämlich die Randrouter, über die die autonomen Systeme miteinan- der verbunden sind: R12, R13, R21, ... , R53. Ebenfalls nur teilweise dargestellt sind die Ressourcenmanagement- und Routing-Prozesse auf den Routern. Wie mit den Ressourcenmanagern RM42, RM43, und RM45 angedeutet, ist jedem Randrouter ein Ressourcenmanager zugeordnet. Die Bezugszeichen IDR42, IDR43, und IDR45 stehen für Routingprozesse. Wie durch die Notation angedeutet, soll jedem Randrouter auch ein Routingprozess zugeordnet sein. Routen werden in diesem Beispiel in der Form (P, al, a2, ..., aN) dargestellt. Dabei beschreibt der Prefix P den Adressblock mit den erreichbaren Zieladressen und die folgende Sequenz von AS-Nummern al, a2, ..., aN die Sequenz der zu durchlaufenden autonomen Systeme über die der Verkehr die Zieladressen aus dem Adressblock mit dem Prefix P erreicht. Zum Beispiel ist (10.10.10.0/24, 2, 1) eine Route von AS4 nach Nl . Angenommen, Router R45 nutzt diese Route, d.h. (10.10.10.0/24, 2, 1), für den Verkehr zum Netz Nl . Zur Beschreibung einer erfindungsgemäßen Routenänderung nehmen wir zusätzlich an, dass Router R45 die Route (10.10.10.0/24, 3, 1) über R43 lernt und sich entscheidet, zukünftig diese Route als beste Route für den Prefix 10.10.10.0/24 zu verwenden.
Erfindungsgemäß unterbricht Randrouter R45 nach der Mitteilung der neuen Route und der Entscheidung die neue Route zukünftig zu nutzen die weitere Bearbeitung dieser Route (Ändern der FIB (forwarding Information base) und Weitergabe der neuen Route an R53 im Nachbarnetz AS5) und informiert den
Ressourcemanager RM45 auf dem selben Router R45 über den bevorstehenden Routenwechsel. Weiter teilt der Prozess IDR45 dem Ressourcemanager RM45 eine IP-Adresse des neuen Ausgangsknotens R43 mit. Der Ressourcemanager RM45 prüft, ob er für den Prefix 10.10.10.0/24 eine Reservierung besitzt und bestimmt gegebenenfalls die auf der neuen Route benötigten Ressourcen. Falls kein QoS-Verkehr betroffen ist, sendet RM45
sofort eine Nachricht an IDR45, die diesen veranlasst, mit der Bearbeitung der neuen Route (10.10.10.0/24, 3, 1) fortzufahren. Falls QoS-verkehr betroffen ist, sendet der Ressourcemanager RM45 eine Reservierungsnachricht an den Ressource- manager RM43, um entlang der neuen Route die erforderlichen Ressourcen zu reservieren (möglicherweise müssen erforderlichen Ressourcen zusätzlich innerhalb von AS4, zwischen R45 und R43, reserviert werden) . Nachdem der Ressourcemanager RM45 eine Antwort mit einer positiven Reservierungsbestäti- gung von dem Ressourcemanager RM43 (und einem möglicherweise zusätzlich zuzustimmenden intra-domain Ressourcemanager) erhalten hat, sendet Ressourcenmanager RM45 eine Nachricht an den Prozess IDR45, die diesen veranlasst, mit der Bearbeitung der neuen Route (10.10.10.0/24, 3, 1) fortzufahren. Daraufhin aktiviert Routing-Prozess IDR45 die neue Route durch eine entsprechende Änderung seiner Routingtabelle (FIB (forwarding Information base) ) . Ab diesem Zeitpunkt fließt der betroffene Verkehr über die neue Route. Weiter gibt der Routing-Prozeß IDR45 die neue Route, d.h. (10.10.10.0/24, 4, 3, 1), mit ei- ner UPDATE Nachricht an R53 weiter (gemäß seiner Routing- Policy) .
Alternativ kann der Ressourcenmanager RM45 die Mitteilung der bevorstehenden Routenänderung auch sofort beantworten und pa- rallel zu den weiteren Aktivitäten des Routing-Prozesses
IDR45 die Reservierung vornehmen, wobei beide Vorgänge idealerweise nahezu zeitgleich ablaufen. Eine andere Möglichkeit ist, dass der Routing-Prozess IDR45 ohne auf eine Antwort von RM45 zu warten an der Routenänderung weiterarbeitet, um den Prozess zu beschleunigen.
Möglicherweise ist die Reservierung von des Ressourcenmanagers RM45 entlang der neuen Route nicht erfolgreich. Dann könnte der Ressourcenmanager RM45 diese Information an den Prozess IDR45 zurückgeben, um die Routenauswahl des Prozesses IDR45 zu beeinflussen.
Da die neue Route, ausgehend vom Router R45 auf dem sich RM45 befindet, zunächst durch eigene Netz AS4 zu einem Randrouter bzw. Ausgangsrouter (egress router) R43 läuft, liegt der Ressourcemanager RM43 von R43 nicht auf der ursprünglichen Route von RM45 zum Zielnetz Nl und der Ressourcenmanager RM45 muss den Ressourcenmanager RM43 direkt adressieren. Dazu kann der Routing-Prozess IDR45 eine Router-ID des Ausgangsrouters R43, auf dem sich der Ressourcenmanager RM43 befindet, an den Ressourcenmanager RM45 weitergeben, z.B. eine iP-Adresse von Router R43. Damit Ressourcenmanager RM45 mittels dieser Information den Ressourcenmanager RM43 findet, muss der Ressourcenmanager RM54 Zugang zu einer Zuordnung von Router-IDs zu Adressen von Ressourcemanagementprozessen haben. Das kann durch einen zentralen Server realisiert werden, auf dem sich alle Ressourcemanagementprozesse anmelden, oder mit Hilfe von an den Ausgangsrouter R43 adressierten IP-Paketen, die eine Kennzeichnung tragen, wie zum Beispiel eine spezielle Proto- kol-ID. ird ein kompletter Verkehrsstrom umgelegt, dann ist der Ressourcenbedarf in der Regel unmittelbar bekannt . Werden nur Teile davon umgelegt, dann sollte die Größe des Teilstroms geschätzt werden. Ein einfacher Weg wäre, auch bei einer Umlenkung eines Teils des Verkehrs zunächst für eine komplette Umlegung zu reservieren und die Reservierung anhand des
Refresh-Mechanismus des Ressourcemanagements zügig anzupassen. Dabei wird vorteilhaft bekannt gegeben, dass es sich um eine Verkehrsumlenkung handelt und welche bestehende Reservierungen oder welcher Verkehr betroffen ist (Reservierungs- oder Verkehrs-ID) , um Doppelreservierungen auf gemeinsamen Wegabschnitten zu vermeiden.
Im Rahmen des Ausführungsbeispiels wurde die Erfindung für einen Anwendungsfall mit dezentralen Ressourcenmanagern RM42, RM43 und RM45 beschrieben. Dem Fachmann ist unmittelbar einsichtig, dass die Erfindung nicht auf diesem Fall beschränkt
ist. Insbesondere ist die Erfindung auch bei einem zentralen Ressourcenmanagement problemlos realisierbar.