-
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 17000)
von Netzen besteht. Diese Netze werden in der Nomenklatur der Internetexperten üblicherweise
als autonome Systeme (autonomous system, abgekürzt AS) oder Routing-Domänen (routing
domain) 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 protocol)
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 Konvergenzprozess 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.
-
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
bereitstellen, 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
transportierte 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. Beispiele 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 protocol).
-
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
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.
-
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 Koordinierung
von Ressourcen-Reservierungen und Routen-Änderungen
beim Inter-Domänen-Routing
die Übertragungsqualität verbessert
werden kann.
-
Erfindungsgemäß wird vorgesehen,
vor oder gleichzeitig zu einer Routenänderung einer Inter-Dömänen-Route,
d.h. vor oder gleichzeitig zu dem Umlenken oder Umlegen (rerouting)
von Verkehr auf eine neu kommunizierte Inter-Domänen-Route eine Nachricht zu
einem Ressourcenmanagement zwecks einer Ressourcen-Reservierung
für die
neue Route gesendet wird. Auf diese Weise wird frühzeitig ein
Reservierungsprozess in Gange gesetzt. Die Umlenkung von Verkehr
kann bis zu dem Zeitpunkt verzögert
werden, bis eine Bestätigungsnachricht
von dem Ressourcenmanagement erhalten wird. Der Verkehr kann dann
solange über
die alte Route gelenkt werden. Wenn das Ressourcenmanagement die
Bestätigungsnachricht
erst nach Reservierung der Ressourcen sendet, ist sichergestellt,
dass die für die Übertragung
benötigte
Bandbreite zu Verfügung steht.
Ist die Ressourcenreservierung nicht erfolgreich, so kann diese
Tatsache von dem Ressourcenmanagement zwecks Beeinflussung der Routenauswahl
kommuniziert werden. Ein weniger konservatives Vorgehen, welches
in der Regel eine schnellere Umlenkung von Verkehr auf die neue
mitgeteilte Route erlaubt, ist z.B. die Umlenkung schon vor dem
Erhalt der Bestätigungsnachricht
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 abhängig zu machen, ob QoS-Verkehr
durch die Umlenkung betroffen ist. Für sogenannten "best effort" Verkehr ist eine
erfolgreiche Bandbreitenreservierung 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, eine Nachricht zur
Ressourcen-Reservierung an das Ressourcenmanagement nur dann zu
senden, wenn QoS-Verkehr betroffen ist. Bei einer Umlenkung eines
Teilstromes kann eine anfäng liche
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
nachfolgenden 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
Verbindungs- und Knotenausfälle,
Traffic-Engineering und Veränderungen
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. Wä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 Ressourcenmanagementprozesse
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 Ressourcenmanagementprozess auf dem zweiten Randknoten zwecks
Ressourcen-Reservierung kommuniziert.
-
Für die Kommunikation
zwischen verschiedenen Ressourcenmanagementprozessen ist es hilfreich,
eine Zuordnung von Ressourcenmanagementprozess 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 erläutert.
-
Die
Figur zeigt 5 autonome Systeme AS1, AS2, ..., AS5. An AS1 ist das
Netz N1 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 miteinander 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, a1, a2, ..., aN) dargestellt. Dabei beschreibt der
Prefix P den Adressblock mit den erreichbaren Zieladressen und die
folgende Sequenz von AS-Nummern a1, 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 N1. Angenommen, Router R45 nutzt diese
Route, d.h. (10.10.10.0/24, 2, 1), für den Verkehr zum Netz N1. 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 Ressourcemanager 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ätigung 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 einer UPDATE Nachricht an R53 weiter (gemäß seiner
Routing-Policy).
-
Alternativ
kann der Ressourcenmanager RM45 die Mitteilung der bevorstehenden
Routenänderung
auch sofort beantworten und parallel 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 N1 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 Protokol-ID.
-
Wird
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.