DE102004037024B4 - Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz - Google Patents

Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz Download PDF

Info

Publication number
DE102004037024B4
DE102004037024B4 DE102004037024A DE102004037024A DE102004037024B4 DE 102004037024 B4 DE102004037024 B4 DE 102004037024B4 DE 102004037024 A DE102004037024 A DE 102004037024A DE 102004037024 A DE102004037024 A DE 102004037024A DE 102004037024 B4 DE102004037024 B4 DE 102004037024B4
Authority
DE
Germany
Prior art keywords
route
message
traffic
announcement
network element
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE102004037024A
Other languages
English (en)
Other versions
DE102004037024A1 (de
Inventor
Thomas Engel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE102004037024A priority Critical patent/DE102004037024B4/de
Priority to CNA2005800259284A priority patent/CN1993942A/zh
Priority to EP05777989A priority patent/EP1774730A1/de
Priority to US11/632,903 priority patent/US20080098127A1/en
Priority to PCT/EP2005/053718 priority patent/WO2006013191A1/de
Publication of DE102004037024A1 publication Critical patent/DE102004037024A1/de
Application granted granted Critical
Publication of DE102004037024B4 publication Critical patent/DE102004037024B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/805QOS or priority aware
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/023Delayed use of routing table updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/033Topology update or discovery by updating distance vector protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/302Route determination based on requested QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation
    • H04L47/783Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/826Involving periods of time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/83Admission control; Resource allocation based on usage prediction

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren zur Festsetzung einer Route für das Routen von Verkehr, bei dem
– an ein Netzelement (R62) eines Netzes (AS6) eine Routenankündigungsnachricht zur Ankündigung einer Route gesendet wird,
– zeitverzögert zu der Routenankündigungsnachricht das Netzelement (R62) durch ein Ereignis veranlasst wird, Verkehr nach Maßgabe der angekündigten Route zu routen, und
– das Ereignis in dem Senden einer Routenaktivierungsnachricht oder dem Ablauf eines Timers besteht.

Description

  • Die Erfindung betrifft ein Verfahren zur Festsetzung einer Route für das Routen von Verkehr und ein Netzelement mit Mitteln zur Durchführung eines derartigen Verfahrens.
  • Ein derzeit sehr aktuelles Arbeitsfeld auf dem Gebiet der Netze und Netztechnologien ist die Weiterentwicklung von Datennetzen für die Übertragung von Echtzeitverkehr unter Einhaltung von Dienstgütemerkmalen.
  • Zukünftig sollen Datennetze, deren wichtigste Vertreter die sogenannten IP-Netze (IP: Internent Protocol) sind, Anwendungen unterstützen, die die Übertragung von Sprach-, Video- und Datenströmen in Echtzeit beinhalten. Für diese Anwendungen muss ein schneller und zuverlässiger Transport von Datenpaketen bzw. IP-Paketen gewährleistet werden. Dafür sollen zukünftige IP-Netze – neben den traditionellen "best effort" Diensten für Datenübertragung – neue Übertragungsdienste anbieten, die dem Verkehr die benötigten Bandbreiten durchgängig bereitstellen und IP-Pakete mit geringen, kaum schwankenden Verzögerung und sehr geringen Paketverlustraten (d.h. unter Einhaltung von Dienstgütemerkmalen) zuverlässig zum Empfänger übertragen. Diese neuen Dienste werden im Folgenden QoS-Dienste (QoS: Quality of Service) und der von ihnen transportierte Verkehr QoS-Verkehr genannt.
  • Da das Internet ein Zusammenschluss einer wachsenden Anzahl einzelner IP-Netze, sogenannter autonomer Systeme (AS), ist, die von unterschiedlichen Organisationen verwaltet und gesteuert werden, müssen QoS-Dienste in diesem Netzverbund netzübergreifend realisiert und zur Verfügung gestellt werden. Dafür werden in der Regel Ressourcenmanagementsysteme eingesetzt, die dem QoS-Verkehr die für die zugesicherte Dienstgüte erforderlichen Ressourcen netzübergreifend bereitstellen. Aus verschiedenen Gründen, wie Traffic-Engineering und Veränderungen von Netzen und Geschäftsbeziehungen, wird netzübergreifender Verkehr häufig auf neue netzübergreifende Routen umgelegt. Das netzübergreifende Routen entlang von einzelnen Netzen oder autonomen Systemen wird häufig auch als Inter-Domänen Routing oder Zwischen-Domänen Routing (vom engl. Inter-domain routing) bezeichnet.
  • Das Zusammenspiel autonomer System im Internet, d.h. die netzübergreifende Weiterleitung von IP-Paketen über die Grenzen einzelner IP-Netze hinweg, wird mit dem inter-domain Routing-Protokoll BGP (BGP: boder gateway protocol) geregelt (beschrieben im RFC1771). Dazu bauen benachbarte Border-, Router oder Randrouter sogenannte BGP-Peering-Sessions auf und tauschen über sogenannte UPDATE-Nachrichten Routing-Informationen aus. Mittels BGP lernt ein Netz, welche IP-Adressen über welche Routen erreichbar sind. Routen sind hier netzübergreifende Routen auf der Ebene autonomer Systeme und werden als Sequenzen von AS-Nummern (AS: autonomes System) kodiert. Für diesen Zweck sind autonomen Systemen eindeutige AS-Nummern zugeordnet. Soll Verkehr auf eine neue Route umgelegt werden, dann gibt ein Border-Router mittels einer UPDATE-Nachricht eine Routenänderung bekannt (Bekanntgabe einer neuen Route, Zurücknahme einer bestehenden Route, oder beides). Eine derartige Routenänderung breitet sich im Allgemeinen über weitere UPDATE-Nachrichten von Netz zu Netz über viele Netze 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. 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 in der Regel mehrfach auf wechselnde Routen umgelegt, weshalb mit erheblichen Verzögerungen von IP-Paketen und hohen Paketverlustraten gerechnet werden muss.
  • Für die Bereitstellung und Verwaltung der für QoS-Dienste benötigten Ressourcen werden Ressourcemanagementsysteme und Signalisierungsprotokolle wie zum Beispiel BGRP (BGRP: Border Gateway Reservation Protocol) verwendet. Das Ressourcemanagement reserviert entlang der durch das BGP-Protokoll bereitgestellten Routen die benötigten Ressourcen. Eine Ressourcenreservierung muss den durch das BGP-Protokoll initiierten Routenänderungen folgen, d.h. bei Änderung einer Route eine entsprechend geänderte Reservierung vornehmen. Das macht vor allem während der Konvergenzzeit, in der sich ein Netz über mehrere Routen hinweg eine neue stabile Route sucht, große Probleme. Zwischenzeitlich gewählte Routen sind nicht unmittelbar als Zwischenlösungen erkennbar. Folgt das Ressourcemanagement den Routenänderungen schnell, so werden für denselben Verkehr mehrfach Ressourcen reserviert. Wartet das Ressourcemanagement auf Konvergenz, kann über längere Zeit die zugesicherte Dienstgüte des QoS-Verkehrs verletzt sein.
  • Aus der WO 2004/045169A2 ist ein Routingsystem mit einer Ausfallsicherung offenbart. Für das Routing wird eine Tabelle mit Prefixen für das Routing vorgehalten, auf welche außer einem primären Routingprozessor auch ein Ersatz-Routingprozessor zugreifen kann. Bei einer Störung werden durch den Ersatz-Routingprozessor die Prefixe in der Tabelle entsprechend angepasst.
  • Die Erfindung hat zur Aufgabe, ein bezüglich der Einhaltung von Dienstgütemerkmalen optimiertes Verfahren zum Festlegen von Routen anzugeben.
  • Die Aufgabe wird durch ein Verfahren nach Anspruch 1 und ein Netzelement nach Anspruch 18 gelöst.
  • Die Erfindung basiert auf dem Gedanken, bei der Festsetzung einer Route, z.B. im Rahmen einer Routenänderung oder einer Bekanntgabe einer neuen Route, diese Route erst einmal anzu kündigen, bevor sie zeitverzögert in Betrieb genommen bzw. aktiviert wird, z.B. indem ein entsprechender Eintrag in einer Routingtabelle vorgenommen wird. Dabei besteht die Ankündigung der Route vorzugsweise aus der Mitteilung der zukünftigen Route. Es ist aber z.B. auch möglich, im Rahmen der Ankündigung eine bereits als Alternative vorgehaltene Route zu referenzieren, um so eine Aktivierung der Route zu bewirken.
  • Die Erfindung ist primär gedacht, um bei der Festsetzung von Interdomain-Routen, z.B. mittels des BGP-Protokolls, Probleme durch die vergleichsweise langsame Konvergenz bei der Bestimmung bzw. Festsetzung von neuen oder geänderten Routen zu überwinden. Diese langsamen Konvergenzzeiten sind vor allem ein Problem bei der Übertragung von Echtzeitverkehr. Im Rahmen des erfindungsgemäßen Vorgehens erfolgt zuerst eine Ankündigung und später zeitversetzt eine Aktivierung der Route. In der Zwischenzeit kann eine Konvergenz bezüglich der neuen oder geänderten Route stattfinden, d.h. unter mehreren angekündigten Routen zu demselben Ziel wird die optimale im Sinne einer Metrik ausgewählt und eine Ressourcenreservierung entlang dieser optimalen Route kann vorgenommen werden. Auf diese Weise stehen bei der Aktivierung der Route die erforderlichen Ressourcen zur Verfügung. Der zu befördernde Verkehr, insbesondere QoS-Verkehr, kann ohne Beeinträchtigungen umgelenkt werden. Es ist denkbar, das erfindungsgemäße Verfahren und die herkömmliche Vorgehensweise parallel zu verwenden, wobei das erfindungsgemäße Verfahren dann angewendet wird, wenn QoS-Verkehr betroffen ist.
  • Geplante Routenänderungen, d.h. nicht durch Leitungs- und Knotenausfall bedingtes Umrouten, können mit dem erfindungsgemäßen Verfahren ohne Störung der dem QoS-Verkehr zugesicherten Dienstgüte durchgeführt werden. Das Verfahren erhöht so die Verfügbarkeit von QoS-Diensten und vereinfacht das Ressourcemanagement. Die Dienstgüte von QoS-Diensten beim geplanten Umrouten netzübergreifender Verkehrsströme kann so sichergestellt werden. Insbesondere wird damit Traffic-Engineering von netzübergreifendem Verkehr unterstützt, was Netzbetreiber schon heute mit wachsender Bedeutung praktizieren.
  • Auch wenn die Erfindung primär auf eine Behebung der beim Interdomain-Routing in Datennetzen auftretenden Probleme abstellt, ist die erfinderische Idee nicht auf diesen Fall be schränkt. Dem Fachmann ist unmittelbar einsichtig, dass die erfinderische Vorgehensweise in beliebigen Kommunikationsnetzen angewandt werden kann, in welchen problematische Verzögerungen bei der Festlegung neuer oder geänderter Routen auftreten. Insbesondere könnte das erfindungsgemäße Verfahren auch bei einem Intradomain-Routing zur Anwendung kommen, wenn bei dem Intradomain-Routing ähnlich gelagerte Schwierigkeiten bezüglich Konvergenzzeiten auftreten.
  • Das Ereignis, welches die Inbetriebnahme der neuen Route veranlasst, bzw. die neue Route aktiviert, ist vorzugsweise durch das Senden einer Routenaktivierungsnachricht gegeben, welche im Folgenden auch kurz als Aktivierung bezeichnet wird. Ein Netzelement, welches eine neue Route in Betrieb nimmt, erhält dann zwei verschiedene zeitlich gegeneinander verzögerte Nachrichten; eine um eine Routenänderung anzukündigen, die zweite, um diese Routenänderung zu aktivieren. Das Ereignis, dass die Inbetriebnahme veranlasst, könnte aber auch eine andere Form haben, beispielsweise ist denkbar, dass ein Netzelement nach Erhalten einer Routenänderungsnachricht einen Timer beziehungsweise Zeitgeber startet und die Inbetriebnahme durch den Ablauf dieses Timers veranlasst wird. Eine Routenaktivierungsnachricht kann z.B. durch eine UPDATE-Nachricht des BGP-Protokolls gegeben sein.
  • Zwischen dem Erhalt der Routenankündigungsnachricht und der Aktivierung der Route findet vorzugsweise eine Ressourcenreservierung statt. Dieser Ressourcenreservierung geht eventuell eine Auswahl einer optimalen Route voraus. Die Ressourcenreservierung für die neue (eventuell als optimal identifizierte) Route kann beispielsweise mit Hilfe einer Ressourcenreservierungsnachricht realisiert werden, die an eine Ressourcenmanagementinstanz gesendet wird. Die Adresse dieser Ressourcenmanagementinstanz kann mittels der Routenankündigungsnachricht dem für die Routenfestsetzung verantwortlichen Netzelement mitgeteilt worden sein. Die von der Ressourcenreservierung betroffenen Ressourcenmanagementinstanzen sind in einer bevorzugten Ausführung entlang der festzulegenden Route lokalisiert. In diesem Fall wird eine Ressourcenreservierungsnachricht von dem Netzelement entlang einer Route übertragen, die mit der Verarbeitung der Routenankündigungsnachricht aufgebaut wurde, die in ihrem Verlauf der neuen Route entspricht und das Versenden von Reservierungsnachrichten gestattet ohne bestehenden Verkehr zu beeinflussen. Dazu wird mit der Verarbeitung der Routenankündigungsnachricht vorzugsweise eine Route mit einem Prefix eingerichtet, der mit der Routenankündigungsnachricht bekannt gegeben wird und eine Adresse eines Ressourcenmanagers in dem System enthält, dass die Routenankündigung ursprünglich veranlasst hat. Eine Nachricht kann so entlang der gesamten Route propagiert werden, alternativ senden die auf der neuen Route gelegene Routinginstanzen ihrerseits Ressourcenreservierungsnachrichten an zugeordnete Ressourcenmanagementinstanzen, um eine Ressourcenreservierung entlang des gesamten Weges zu gewährleisten. Da Ressourcenreservierungsnachrichten auf dem Weg von Routenankündigungsnachrichten in umgekehrter Richtung laufen, kann die Zuordnung einer Ressourcenmanagementinstanz leicht aus der Routenankündigungsnachricht abgeleitet werden.
  • Entsprechend einer Weiterbildung des Anmeldegegenstands kann eine erfolgreiche Ressourcenreservierung dem für die Routenfestsetzung verantwortlichen Netzelement bestätigt werden. Die Aktivierung der Route kann von dem vorhergehenden Erhalt einer Bestätigung der Reservierung abhängig gemacht werden, d.h. die Aktivierung wird nicht vorgenommen, wenn keine Bestätigung für die Ressourcenreservierung vorliegt. Alternativ kann bei fehlgeschlagener Ressourcenreservierung das Eintreten der Aktivierung verhindert werden, z.B. in dem keine Routenaktivierungsnachricht an das Netzelement gesendet wird. Weiter kann die Aktivierung davon abhängig gemacht werden das der in den Routenankündigungsnachrichten genannte Ressourcenmanager als Reaktion auf seine Ankündigung Reservierungen erhält, deren Ressourcenbedarf in Summe in einen Zielintervall liegen.
  • Die Routenankündigungsnachricht enthält vorzugsweise ein Kennzeichen oder Attribut, welches sie als Ankündigungsnachricht ausweist. Mit dieser Ankündigungsnachricht kann eine Information über den Zeitpunkt des Eintritts des Ereignisses, z.B. den Zeitpunkt des Sendens einer Routenaktivierungsnachricht übermittelt werden. Diese Information kann sowohl in einer Zeitdifferenz zwischen der Ankündigungsnachricht und dem die Aktivierung auslösenden Ereignis, als auch in einem absoluten Zeitpunkt des geplanten Eintritts des Ereignisses der Aktivierung bestehen. Im letzteren Fall ist eine Synchronisierung der Uhren des Senders der Nachricht und des Empfängers, d.h. des Netzelementes anzustreben, welche beispielsweise mittels des NTP (Network Time Protocol) Protokolls erreicht werden kann (beschrieben in RFC1305). Die Routenankündigungsnachricht kann im Wesentlichen die Form einer BGP-UPDATE-Nachricht haben, wobei sie bezüglich herkömmlichen UPDATE-Nachrichten zumindest insofern verändert ist, als dass sie eine Kennzeichnung als Ankündigungsnachricht umfassen sollte. Sie kann eine Information über den Eintritt des Zeitpunkts und eine Adresse einer zuständigen Ressourcenmanagementinstanz umfassen, was auch einer Erweiterung bezüglich herkömmlicher UPDATE-Nachrichten darstellt.
  • Das erfindungsgemäße Verfahren läuft dann in einer mittels UPDATE-Nachrichten realisierten, bevorzugten Ausführungsform wie folgt ab. Durch Traffic-Engineering und andere geplante Verkehrsumlegen werden Vorankündigungen von Routenänderungen ausgelöst. Soll laufender Verkehr zukünftig, statt über einen bisher verwendeten Border-Router R1, über einen anderen Border-Router R2 in ein autonomes System A gelangen, also über neue Wege geführt werden, dann sendet der zukünftig zu nutzende Border-Router R2 wie herkömmlich eine BGP-UPDATE-Nachricht an die betroffenen Nachbarn. Im Unterschied zum bisherigen Ablauf sendet er jedoch eine UPDATE-Nachricht U1 mit einer Vorankündigung der neuen Route. Später, zu einem angekündigten Zeitpunkt, sendet R2 eine zweite, reguläre UPDATE- Nachricht U2 mit der in U1 angekündigten neuen Route. Die UPDATE-Nachricht U1 kündigt U2 an und gibt den beteiligten Netzen die Gelegenheit, ohne Störung des laufenden Verkehrs den Konvergenzprozess vorab zu durchlaufen, die benötigen Ressourcen auf der neuen konvergenten Route zu reservieren und den betroffenen Verkehr mit der Ausbreitung von U2 störungsfrei in einem Schritt auf eine vorbereitete Route umzulegen. Dazu werden gemäß RFC1771 neue Attribute in UPDATE-Nachrichten eingefügt: für die Kennzeichnung von Ankündigungen, für die Bekanntgabe des Versendezeitpunktes von U2 und für die Bekanntgabe der Adresse eines Ressourcemanagers in A an den Reservierungen für die angekündigte Route zu senden sind. Wie eine reguläre UPDATE-Nachricht enthält auch eine Ankündigung eine Route bestehend aus einem Prefix P, einer Route R kodiert in einer Liste von AS-Nummern und Attributen. Der Prefix P, Route R und Attribute sind identisch mit denen in U2.
  • Mögliche Varianten dieser bevorzugten Ausführungsform sind:
    Der Border-Router R2 könnte eine Ankündigung U1 ohne Angabe des Zeitpunkts des geplanten Versendens der eigentlichen UPDATE-Nachricht U2 verschicken und lediglich eine angemessene Zeitspanne vor dem Versenden von U2 abwarten (Abschätzungen über Verteilung der Routenlängen) und ein reagierendes AS könnte ebenfalls eine geeignete Zeitspanne bis zur Signalisierung zur Ressourcenreservierung abwarten (Abschätzungen über Verteilung der Routenlängen). Alternativ könnte U1 statt einem Zeitpunkt ein Zeitintervall enthalten, dass von Border-Router zu Border-Router angepasst wird (Abzug von Weiterleitungs- und Verarbeitungszeit) und die verbleibende Zeit bis zum Ansenden von U2 anzeigt. Als optionale Verbesserung kann das UPDATE U2 einen Verweis auf U1 enthalten und die Verknüpfung mit der angekündigten Routenänderung erleichtern.
  • Der Gegenstand der Erfindung umfasst auch ein Netzelement mit Mitteln zur Durchführung eines Verfahrens im Sinne der erfindungsgemäßen Vorgehensweise.
  • Die Erfindung wird im Folgenden im Rahmen eines Ausführungsbeispiels anhand von Figuren näher erläutert. Es zeigen:
  • 1: Einen Ausschnitt aus einem Netzverbund, welcher mit Autonomen Systemen (AS) gebildet ist.
  • 2 und 3: Ein Ablaufdiagramm für die Durchführung eines erfindungsgemäßen Verfahrens.
  • Im Rahmen des Ausführungsbeispiels werden Routenänderungen bei dem Inter-Domänen Routing mittels des BGP Protokolls mit einer neuen Form von UPDATE-Nachrichten vorab angekündigt. Wenige Minuten zeitverzögert zu der Ankündigung erfolgt dann die eigentliche Routenänderung, die wie herkömmlich im BGP-Protokoll vorgesehen stattfinden kann. Die Zeitverzögerung wird so gewählt, dass in der Regel vor der Routenänderung die optimale Route bestimmt und eine Ressourcenreservierung vorgenommen werden kann. Da ein durchschnittlicher Konvergenzprozess beim Inter-Domänen Routing ca. 3 Minuten dauert, ist eine Zeitverzögerung von einigen Minuten sinnvoll. Damit können die Konvergenzphase und die Ressourcereservierung für QoS-Verkehr in die Zeitspanne zwischen der Ankündigung und dem eigentlichen Umrouten vorgezogen werden. Umgeroutet wird zeitversetzt zur Ankündigung erst dann, wenn die konvergente Route schon bekannt ist und die benötigten Ressourcen bereits bereitgestellt wurden. Routenankündigungen werden mittels UPDATE-Nachrichten transportiert und durchlaufen denselben Konvergenzprozess wie reguläre UPDATE-Nachrichten, ändern jedoch den Verkehrsfluss nicht, sondern veranlassen die Ermittlung der später konvergenten Route.
  • Es werden erfindungsgemäß neue Attribute in BGP-UPDATE-Nachrichten verwendet, mit denen eine Routenänderungen vorab mit einer UPDATE-Nachricht U1 angekündigt werden kann (im Folgenden wird diese Routenankündigungsnachricht auch als Ankündigung bezeichnet). D.h. die Attribute weisen die UPDATE-Nach richt als Ankündigung einer Routenänderung aus. Zu einem in der Ankündigung U1 genannten Zeitpunkt (in der Größenordung von Minuten nach dem Versenden von U1) wird dann wie im Rahmen des BGP-Protokolls vorgesehen mit einer regulären zweiten UPDATE-Nachricht U2 das Umrouten eingeleitet. Die UPDATE-Nachricht U2 enthält in üblicher Weise die erreichbaren Prefixe und den AS-Pfad, d.h. die IP-Adressen der erreichbaren Systeme und die Liste der zum Ziel führenden autonomen Systeme. Die UPDRTE-Nachricht U1, welche als Ankündigung verwendet wird, enthält dieselben Informationen wie U2 und zusätzlich Angaben: ein Kennzeichen, dass es sich um eine Ankündigung einer kommenden neuen Route handelt, den Zeitpunkt, an dem mit der zweiten UPDATE-Nachricht U2 die eigentliche Routenänderung eingeleitet wird, sowie die Adresse eines für Ressourcenreservierungen zuständigen Ressourcenmanagers. Im Beispiel ist dieser Ressourcenmanager in dem autonomen System lokalisiert, dass die Routenänderung mit der UPDATE-Nachricht U1 ursprünglich ankündigt. Diesem Ressourcenmanager ist im Beispiel von 1 am Rand-Router R12 lokalisiert. Ein Ressourcenmanager kann z.B. mit Hilfe von Software durch Prozesse realisiert werden, die auf einem Router oder auf einer unabhängigen Hardwareplattform laufen. Ein zentrales Ressourcen-Management ist ebenfalls möglich.
  • Die Ankündigung U1 und alle im weiteren Verlauf daraus abgeleiteten Ankündigungen durchlaufen auf jedem Rand-Router die üblichen Selektionsprozesse, z.B. Filter für eingehende UPDA-TEs, Auswahl der besten Route ('best path selection') und Filter für ausgehende UPDATEs, die über Routenwahl und – weitergabe entscheiden, ohne jedoch das bestehende Routing des von einer Aktivierung der angekündigten Route betroffen Verkehrs zu ändern. Gemäß dem BGP-Protokoll wird derzeit zu jedem Ziel maximal eine Route – die beste Route – an Nachbarknoten weitergegeben. Diese Einschränkung beeinflusst die Weitergabe von angekündigten Routen nicht. Angekündigte Routen werden, wenn sie die Selektionsprozesse erfolgreich durchlaufen haben und ebenso modifiziert sind wie analoge re guläre Routen, an alle Nachbarn weitergegeben, so wie später auch die von der UPDATE-Nachricht U2 ausgelösten bzw. aktivierten Routen. Ankündigungen beeinflussen dabei aber die fürs Routing verwendete aktuelle beste Route des betroffenen Verkehrs nicht, ändern insbesondere nicht den entsprechenden Eintrag in Routingtabellen (FIB(forwarding information base)) und ersetzen keine über reguläre UPDATE-Nachrichten gelernte Routen. Wie später auch die UPDATE-Nachricht U2 löst damit die Ankündigung U1 Konvergenzprozesse aus. Ein entferntes autonomes System B, das später auf U2 reagieren und QoS-Verkehr umlegen wird, durchläuft einen Konvergenzprozess und lernt bereits jetzt die später verfügbaren Routen und insbesondere die sich später einstellende konvergente Route, auf die der Verkehr dann umgelegt wird. Nach einer angemessenen Zeitspanne und noch vor Ablauf des aus den Ankündigungen bekannten Zeitpunkts des Versendens von U2 reserviert das autonomes System B die für das Umlegen des betroffenen Verkehrs benötigten Ressourcen auf der aus den Ankündigungen gelernten, konvergenten, besten zukünftigen Route. Dafür wird eine entsprechende Signalisierungsnachricht an den in der Ankündigung U1 genannten Ressourcemanager des autonomen Systems A gesandt. Um das zu ermöglichen, haben alle an der Weitergabe von angekündigten Routen beteiligten autonomen Systeme eine Route mit einem geeigneten Prefix der IP-Adresse des Ressourcenmanagers eingerichtet. Das heißt, die Signalisierungsnachricht an den Ressourcenmanager in dem autonomen System A läuft in der Regel bereits über den neuen besten Pfad. Wenn dann zum angekündigten Zeitpunkt die UPDATE-Nachricht U2 gesendet wird, reagieren alle autonomen Systeme wie bisher, d.h. realisieren ein Routing für den betroffenen Verkehr entlang der neuen Route. Diejenigen autonomen Systeme, die aus der Ankündigungsphase schon wissen, dass sie Verkehr auf eine neue Routen umlegen, warten auf das Eintreffen der schon bekannten konvergenten Route. Erst dann ändern sie ihre Routingtabellen (FIBs: forwarding information bases) und geben eine entsprechende UPDATE-Nachricht weiter.
  • 1 zeigt sieben autonome Systeme AS1, AS2, ..., AS7. An AS1 sind zwei Netze angeschlossen, Netz N1 und Netz N2. Im Netz N1 sind die Endsysteme mit den IP-Adressen im Adressblock 10.10.10.0/24, d.h. 10.10.10.0 bis 10.10.10.255 erreichbar, im Netz N2 die Endsysteme mit den Adressen im Adressblock 10.10.11.0/24, d.h. 10.10.11.0 bis 10.10.11.255. Dabei gibt 10.10.10.0/24 eine IP-Adresse, 10.10.10.0, und eine Maskenlänge 24, an und steht für alle IP-Adressen, die in den ersten 24 Bit (Maskenlänge) mit der angegebenen Adresse 10.10.10.0 übereinstimmen, also 10.10.10.0 bis 10.10.10.255. In 1 dargestellt ist nur ein Teil der beteiligten Router, die Border-Router oder Randrouter, über die die autonomen Systeme miteinander verbunden sind: R11, R12, R21, R22, R31, R32, R33, R41, R42, R51, R52, R61, R62, R71 und R72. Ebenfalls nur teilweise dargestellt sind die für das Ressourcenmanagement verantwortlichen Komponenten. Wie mit den Ressourcenmanagern RM11, RM12, RM61 und RM62 beispielhaft angedeutet, ist hier insbesondere jedem Border-Router ein Ressourcenmanager zugeordnet.
  • 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 a1, a2, ..., aN die Sequenz der zu durchlaufenden autonomen Systeme über die der Verkehr die Zieladressen aus P erreicht. Zum Beispiel ist (10.10.10.0/23, 4, 2, 1) eine Route von dem autonomen System AS6. Sie führt mit dem Adressblock 10.10.10.0/23 zu den Netzen N1 und N2. Die Zahlenfolge 4, 2, 1 steht für die Sequenz der autonomen Systeme: AS4, AS2, AS1, die den Verkehr von dem autonomen System AS6 zu den Netzen N1 und N2 weiterleiten.
  • Angenommen, das autonome System AS6 nutzt die Route (10.10.10.0/23, 4, 2, 1) für den Verkehr zu den Zielnetzen N1 und N2, die Auslastung der Verbindung zwischen den Router R21 und R11 nähert sich der Kapazitätsgrenze und das autonome System AS1 möchte ein Teil des Verkehrs auf andere Routen um legen. Weiter wird angenommen, dass das autonome System AS1 sich entscheidet, den Verkehr zum Netz N2 auf Routen über R12 umzulegen.
  • Nach dem bisherigen Verfahren, also im Rahmen des BGP Protokolls ohne das neue erfindungsgemäße Verfahren, würde der Router R11 die über ihn erreichbaren Zieladressen mit einer UPDATE Nachricht auf 10.10.10.0/24 einschränken und der Router R12 mit einer UPDATE Nachricht die Erreichbarkeit von 10.10.11.0/24 bekannt geben. Das würde eine im Allgemeinen durchschnittlich dreiminütigen Konvergenzprozess einleiten, während dem die Dienstqualität für Verkehrsströme von dem autonomen System AS6 zu den Netzen N1 und N2 erheblich leidet und möglicherweise während des Konvergenzprozesses mehrfach Ressourcen auf unterschiedlichen Wegen zwischen den autonomen Systemen AS6 und AS1 reserviert werden.
  • Nach dem neuen erfindungsgemäßen Verfahren sendet der Router R12 eine UPDATE-Nachricht U1 an den Router R31, die eine Ankündigung der Route (10.10.11.0/24, 1) enthält. In U1 könnte stehen, dass diese Route in 10 Minuten mit einer weiteren UPDATE-Nachricht verbindlich mitgeteilt wird. AS3 propagiert die angekündigte Route als (10.10.11.0/24, 3, 1) an die Router R41, R51 und R71. Das autonome System AS4 propagiert die angekündigte Route als (10.10.11.0/24, 4, 3, 1) an das autonome System AS6, obwohl der Router R42 schon (10.10.10.0/23, 4, 3, 1) an den Router R61 weitergegeben hat. Die Konvergenzphase ist in diesem Beispiel abgeschlossen, wenn (10.10.11.0/24, 4, 3, 1) über den Router R42, (10.10.11.0/24, 5, 3, 1) über den Router R52 und (10.10.11.0/24, 7, 3, 1) über den Router R72 bei dem autonomen System AS6 angekommen sind und das autonome System AS6 die aus seiner Sicht beste Route ausgewählt hat. Hier wird angenommen, dass das autonome System AS6 sich für (10.10.11.0/24, 5, 3, 1) entscheidet, z.B. weil es sich im Sinne einer Metrik um die optimale Route handelt. Mit den angekündigten Routen erfährt das autonome System AS6 auch den von dem autonomen System AS1 beabsichtig ten Umschaltzeitpunkt. Unter Berücksichtigung, dass die Uhren der autonomen Systeme AS1 und AS6 nicht synchron laufen, wird das autonome System AS6 sein Ressourcemanagement rechtzeitig über seine Routenwahl informieren und den Ressourcenmanager RM62 veranlassen die benötigten Ressourcen auf der gewählten zukünftigen Route an den Ressourcenmanager RM12 zu signalisieren. Damit liegt die neue Route fest, und die erforderlichen Ressourcen sind schon bereitgestellt, wenn der Router R12 zum angekündigten Zeitpunkt eine weitere UPDATE-Nachricht U2 mit der Route (10.10.11.0/24, 1) an den Router R31 sendet, diesmal als reguläre UPDATE-Nachricht. In einer nicht vorher bestimmbaren Reihenfolge werden ausgelöst durch die U2 UPDATE-Nachrichten mit den Routen (10.10.11.0/24, 4, 3, 1), (10.10.11.0/24, 5, 3, 1) und (10.10.11.0/24, 7, 3, 1) bei dem autonomen System AS6 eintreffen. Das autonome System AS6 kennt die neue konvergente Route schon und wird jetzt solange warten, bis die UPDATE-Nachricht mit der Route (10.10.11.0/24, 5, 3, 1) eintrifft. Dann wird das autonome System AS6 sein Routing anpassen und den Verkehr zu N2 auf den neuen Weg legen, der zu diesem Zeitpunkt schon durchgängig steht, den konvergenten Zustand darstellt und die erforderlichen Ressourcen bereithält. Ohne wesentliche Beeinträchtigung der Dienstgüte wird damit der Verkehr auf die neue Route umgestellt (bis auf mögliche Überschneidungen von Verkehr auf der neuen Strecke und noch auf der alten Strecke laufenden Verkehrs, der zum Zeitpunkt des Umroutens sein Ziel noch nicht erreicht hat). Anschließend wird der Ressourcenmanager RM61 die auf der alten Route über die autonomen Systeme AS4, AS2 und AS1 reservierten Ressourcen anpassen, d.h. die durch die Verkehrsumlegung nicht mehr benötigten Ressourcen freigeben.
  • Das autonome Systeme AS6 verfährt dabei nach dem in 2 und 3 gezeigten Ablaufdiagramm. Zur Vereinfachung ist hier angenommen, dass ein UPDATE nur eine bekannt gegebene Route R mit Prefix P enthält (Schritt 101). Eine Erweiterung für UPDATE-Nachrichten, die mehrere Routen bekannt geben, ist für den Fachmann trivial. Die Schritte 102, 104, 105, 107, 108 und 109 entsprechen der im RFC1771 beschriebenen Verarbeitung bekannt gegebener Routen. Im Schritt 106 werden in diesem Verlauf Routenankündigungen herausgefiltert, die zukünftig beste Route beschreiben, und in einer neuen Datenbank für angekündigte Routen, Pen-RIB (Pen für Pending (englisch für bevorstehend)), gespeichert (Schritt 123). Ist R die erste derartige Routenankündigung für den Prefix P (kein Eintrag in Pen-RIB) wird ein Zeitgeber gestartet (Schritt 121 und 122). Aus der Routenankündigung R wird eine Route R* generiert, die bis auf den Prefix P* mit R identisch ist (Schritt 124). P* ist der mit R gegebene Prefix des zuständigen Ressourcemanagers für Reservierungen auf der angekündigten Route, im Beispiel ein Prefix für eine Adresse von RM12 in AS1. R* wird nun statt der Routenankündigung in Loc-RIB eingetragen und aktiviert (Schritt 125).
  • Angekündigte Routen, die aufgrund der in Pen-RIB eingetragenen Routenankündigungen erwartet werden, werden im Schritt 103 ausgefiltert und gesondert behandelt. Sie werden in die Datenbank Pen-RIB eingetragen (Schritt 131). Mit dem ersten solchen Eintrag wird ein Zeitgeber gestartet (Schritt 132 und 133). Entspricht die Route R der in Pen-RIB enthaltenen neuen besten Route, werden alle in Pen-RIB für den Prefix P zwischengespeicherten Routen verarbeitet und alle Einträge für den Prefix P in Pen-RIB gelöscht (Schritt 134, 135 und 136). Die Verarbeitung im Schritt 135 entspricht der der Schritte 104, 105, 107, 108 und 109.
  • Läuft ein in Schritt 122 aufgezogener Timer aus (Schritt 201) wird das Ressourcenmanagement über die bevorstehende Routenänderung informiert um eine entsprechende Ressourcenreservierung zu veranlassen (Schritt 202).
  • Läuft ein in Schritt 133 aufgezogener Timer aus (Schritt 301), wird davon ausgegangen, dass die in Pen-RIB gespeicherte neue beste Route ihre Gültigkeit verloren hat. Es wird geprüft, ob es Einträge für den Prefix P in Pen-RIB gibt (Schritt 302). Fall ja, werden alle in Pen-RIB zum Prefix P zwischengespeicherten Routen verarbeitet (Schritt 303) und in Pen-RIB gelöscht (Schritt 304). Weiter wird das Ressourcenmanagement über die Änderung informiert (Schritt 305).
  • Ist davon auszugehen, dass von mehreren autonomen Systemen initiierte Routenänderungen für denselben Prefix in Pen-RIB gehalten werden müssen, dann müssen die Eintragungen in Pen-RIB nach Prefix und einer Identifikation des Absenders der ursprünglichen Ankündigung (AS1 oder Router R12 im Beispiel) erfolgen. Dazu muss Routenänderungsnachrichten gegebenenfalls ein geeigneter Wert für diese Identifikation mitgegeben werden, z.B. eine AS-Nummer oder eine IP-Adresse eines Randrouters.

Claims (18)

  1. Verfahren zur Festsetzung einer Route für das Routen von Verkehr, bei dem – an ein Netzelement (R62) eines Netzes (AS6) eine Routenankündigungsnachricht zur Ankündigung einer Route gesendet wird, – zeitverzögert zu der Routenankündigungsnachricht das Netzelement (R62) durch ein Ereignis veranlasst wird, Verkehr nach Maßgabe der angekündigten Route zu routen, und – das Ereignis in dem Senden einer Routenaktivierungsnachricht oder dem Ablauf eines Timers besteht.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Festsetzung der Route für das Routen von Verkehr im Rahmen eines Inter-Domänen-Routings erfolgt.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Festsetzung der Route mit Hilfe des BGP (Border Gateway Protocol)-Protokolls erfolgt.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei Ankündigung von mehreren Routen zu demselben Ziel (N2) vor Eintreten des Ereignisses eine Auswahl einer im Sinne einer Metrik optimalen Route vorgenommen wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass – das Ereignis in dem Senden einer Routenaktivierungsnachricht besteht, und – die Routenaktivierungsnachricht durch eine UPDATE-Nachricht gegeben ist.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach der Ankündigung der Route eine auf die Route bezogene Ressourcenreservierung eingeleitet wird.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass eine Ressourcenreservierungsnachricht durch eine Ressourcenmanagementinstanz (RM62) des Netzelements (R62) zur Ressourcenreservierung entlang der angekündigten Route gesendet wird.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass eine Adresse einer für die Ressourcenreservierung zuständigen Ressourcenmanagementinstanz mittels der Routenankündigungsnachricht dem Netzelement (R62) mitgeteilt wird.
  9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass Ressourcenreservierungsnachrichten entlang der angekündigten Route zwecks Ressourcenreservierung für die Benutzung der Route übertragen werden.
  10. Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass dem Netzelement (R62) eine erfolgreiche Ressourcenreservierung bestätigt wird.
  11. Verfahren nach einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass bei nicht erfolgreicher Ressourcenreservierung trotz Eintreten des Ereignisses keine Festsetzung einer Route für das Routen von Verkehr vorgenommen wird.
  12. Verfahren nach Anspruch 5 und einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass bei nicht erfolgreicher Ressourcenreservierung keine Routenaktivierungsnachricht an das Netzelement (R62) gesendet wird.
  13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht eine Kennzeichnung umfasst, durch welche sie als Routenankündigungsnachricht identifizierbar ist.
  14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht eine Information über den Zeitpunkt des Eintritts des Ereignisses umfasst.
  15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht zumindest eine Adresse einer für die Reservierung einer Ressource zwecks Übertragung entlang der Route zuständigen Ressourcenmanagementinstanz umfasst.
  16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht die Form einer UPDATE-Nachricht hat, welche ein Attribut umfasst, durch welche sie als Routenankündigungsnachricht identifizierbar ist.
  17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der über die angekündigte Route zu übertragende Verkehr zumindest teilweise unter Einhaltung von Dienstgütemerkmalen zu übertragen ist.
  18. Netzelement (R62) mit Mitteln zu Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 17.
DE102004037024A 2004-07-30 2004-07-30 Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz Expired - Fee Related DE102004037024B4 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE102004037024A DE102004037024B4 (de) 2004-07-30 2004-07-30 Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz
CNA2005800259284A CN1993942A (zh) 2004-07-30 2005-07-29 在路由会聚缓慢的网络中保持业务质量的通信路由转换的方法和网络元件
EP05777989A EP1774730A1 (de) 2004-07-30 2005-07-29 Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz
US11/632,903 US20080098127A1 (en) 2004-07-30 2005-07-29 Method and Network Element for Rerouting Traffic, While Maintaining the Quality of Service, in Networks with Slow Route Convergence
PCT/EP2005/053718 WO2006013191A1 (de) 2004-07-30 2005-07-29 Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004037024A DE102004037024B4 (de) 2004-07-30 2004-07-30 Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz

Publications (2)

Publication Number Publication Date
DE102004037024A1 DE102004037024A1 (de) 2006-03-23
DE102004037024B4 true DE102004037024B4 (de) 2006-07-13

Family

ID=35115858

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004037024A Expired - Fee Related DE102004037024B4 (de) 2004-07-30 2004-07-30 Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz

Country Status (5)

Country Link
US (1) US20080098127A1 (de)
EP (1) EP1774730A1 (de)
CN (1) CN1993942A (de)
DE (1) DE102004037024B4 (de)
WO (1) WO2006013191A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8166197B2 (en) 2005-10-25 2012-04-24 Oracle International Corporation Multipath routing process
DE102006015239B3 (de) * 2006-03-30 2007-08-23 Siemens Ag Netzzugangssteuerung mit zusätzlicher Verkehrsklasse in einem Kommunikationsnetz
US20070233885A1 (en) * 2006-03-31 2007-10-04 Buskens Richard W Architectures for assuring the inter-domain transport of QoS sensitive information
EP1940091B1 (de) * 2006-12-27 2009-10-07 Nec Corporation Autonomes Netzwerk, Netzknotenvorrichtung, Netzwerkredundanzverfahren und Aufzeichnungsmittel
US8036141B2 (en) * 2008-08-15 2011-10-11 At&T Intellectual Property I, L.P Apparatus and method for managing a network
US8826271B2 (en) 2010-04-28 2014-09-02 Cavium, Inc. Method and apparatus for a virtual system on chip
US20120124238A1 (en) * 2010-11-12 2012-05-17 Alcatel-Lucent Bell N.V. Prioritization of routing information updates
US9424144B2 (en) * 2011-07-27 2016-08-23 Microsoft Technology Licensing, Llc Virtual machine migration to minimize packet loss in virtualized network
US9699068B1 (en) * 2014-09-30 2017-07-04 Amazon Technologies, Inc. Distributing routing updates according to a decay mode
US9531642B1 (en) 2014-09-30 2016-12-27 Amazon Technologies, Inc. Distributing routing updates according to a synchronous mode
US9806985B2 (en) * 2015-03-02 2017-10-31 Cisco Technology, Inc. Symmetric routing enforcement
CN106603417B (zh) * 2015-10-16 2019-11-29 华为技术有限公司 一种路由处理方法、设备及系统
US10235211B2 (en) * 2016-04-22 2019-03-19 Cavium, Llc Method and apparatus for dynamic virtual system on chip
US11909763B2 (en) * 2021-04-07 2024-02-20 Cisco Technology, Inc. BGP blackhole and hijack mitigation
US11843533B2 (en) * 2022-02-28 2023-12-12 Microsoft Technology Licensing, Llc End-to-end performance aware traffic engineering for internet peering

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004045169A2 (en) * 2002-11-12 2004-05-27 Cisco Technology, Inc. Routing system and method for synchronizing

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658469B1 (en) * 1998-12-18 2003-12-02 Microsoft Corporation Method and system for switching between network transport providers
JP2001217839A (ja) * 2000-01-31 2001-08-10 Fujitsu Ltd ノード装置
US7234001B2 (en) * 2000-12-20 2007-06-19 Nortel Networks Limited Dormant backup link for OSPF network protection
US6792091B2 (en) * 2002-02-22 2004-09-14 Marc S. Lemchen Network-based intercom system and method for simulating a hardware based dedicated intercom system
JP2007525047A (ja) * 2003-03-18 2007-08-30 レネシス コーポレーション ネットワーク経路指定を監視するための方法及びシステム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004045169A2 (en) * 2002-11-12 2004-05-27 Cisco Technology, Inc. Routing system and method for synchronizing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
REKHTER, Y. et al: RFC 1771 - A Border Gateway Protocol (BGP-4), Network Working group, Request for Comments: 1771, March 1995, Kapitel 1-3.1 und 4.3 *

Also Published As

Publication number Publication date
EP1774730A1 (de) 2007-04-18
WO2006013191A1 (de) 2006-02-09
US20080098127A1 (en) 2008-04-24
CN1993942A (zh) 2007-07-04
DE102004037024A1 (de) 2006-03-23

Similar Documents

Publication Publication Date Title
WO2006013191A1 (de) Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE60030122T2 (de) Implementation eines effizienten internetdienstes für verknüpfte satellitnetze
DE60022602T2 (de) Verfahren, Vorrichtung und Computerprogramm um Topologiedaten eines Link State Routing Netzwerkes aktuell zu halten
DE60037368T2 (de) Verfahren und Architektur zur Unterstüzung von mehreren Diensten in einem Etikettvermittlungsnetzwerk
DE19833931A1 (de) Verfahren zum Übermitteln von Datenpaketen an mehrere Empfänger in einem heterogenen Kommunikationsnetz
EP1133112B1 (de) Verfahren zum Verteilen einer Datenverkehrslast eines Kommunikationsnetzes und Kommunikationsnetz zur Realisierung des Verfahrens
EP1405540A1 (de) Verfahren zum durchführen eines qos-orientierten handoffs zwischen einem ersten und einem zweiten ip-basierten, insbesondere mobilen ipv6-basierten kommunikationspfad zwischen einem mobile node (mn) und einem correspondent node (cn)
DE60210574T2 (de) Netzwerkauswahl für eine Verbindung
DE4434952A1 (de) Verfahren und Anordnung zur Adressierung von Teilnehmern in einem aus mindestens zwei Segmenten bestehenden Netzwerk
EP3577871B1 (de) Verfahren und vorrichtung zur modularen lenkung eines avb-streams
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
DE102006027708B3 (de) Verfahren zur Optimierung einer Kommunikationsverbindung in einem paketvermittelten Sprachdatennetzwerk
DE60202454T2 (de) Mechanismus zum Aufbauen einer Verbindung für ATM über MPLS
EP1532780B1 (de) Effizientes intra-domain routing in paketnetzen
EP1842343A1 (de) Verfahren zur bestimmung der weiterleitungsrichtung von ethernet-frames
DE60022057T2 (de) Verfahren um im multi-protocol label switching schleifen zu vermeiden
EP1566039A1 (de) Verfahren zur umleitung von datenpaketen bei lokal erkannten linkausfällen
DE602006000136T2 (de) Vorreservierung von Ressourcen für Verbindungswege in einem Kommunikationsnetz an Kommunikation von Anschriften von Päckchen oder von Etiketten
DE102005005278B4 (de) Verfahren zum Betrieb eines Netzknoten eines Kommunikationsnetzes und Netzknoten eines Kommunikationsnetzes
EP1894363A1 (de) Verfahren und unabhängiges kommunikationsteilnetz zum ermitteln labelvermittelter routen in einem solchen kommunikationsteilnetz
DE102004058927B3 (de) Aggregation der inter-domain Ressourcen-Signalisierung
WO2005125117A1 (de) Verfahren zur ressourcen-reservierung für ein inter-domain-routing mit dienstgütemerkmalen
EP3664510A1 (de) Wechsel des datenübertragungsweges ohne verlust von datenpaketen
WO2005027435A1 (de) Verfahren zur optimierten deaktivierung von inter-domain routen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20120201