-
Feld der Offenbarung
-
Die
vorliegende Erfindung betrifft allgemein Netzwerkkommunikation und
insbesondere Synchronisation von redundanten Kommunikationsaufgaben.
-
Hintergrund
-
Datenkommunikationsprotokolle
dienen zur Erleichterung von Übertragung
und Empfang von Daten über
Kommunikationsnetzwerke. Z.B. erleichtern Transmission Control Protocol
(TCP), Internet Protocol (IP), Border Gateway Protocol (BGP), Asynchronous
Transfer Mode (ATM) und diverse andere Protokolle die Kommunikation
von Daten zwischen zwei oder mehr Stellen in einem Kommunikationsnetzwerk.
Durch die Verwendung solcher Protokolle kann die Datenkommunikation über mehrere
Kommunikationsnetzwerke vereinfacht werden, auch wenn zwei oder
mehrere dieser Netzwerke unterschiedliche Betriebssysteme und Architekturen
aufweisen.
-
Das
von der International Standards Organisation (ISO) entwickelte Open
Systems Interconnect-(OSI)-Referenzmodell wird im allgemeinen verwendet,
um die Struktur und Funktion von Datenkommunikationen zu beschreiben.
Das OSI-Referenzmodell
umfasst sieben Schichten, oft als Stapel oder Protokollstapel bezeichnet,
die die Funktionen von Datenkommunikationsprotokollen definieren.
Der Protokollstapel umfasst eine physikalische Schicht, eine Datenverbindungsschicht,
eine Netzwerkschicht, eine Transportschicht, eine Sitzungsschicht, eine
Präsentationsschicht
und eine Anwendungsschicht. Eine Schicht definiert nicht ein einzelnes
Protokoll, sondern eher eine Datenkommunikationsfunktion, die durch
eine beliebige Zahl von Protokollen, die für die Funktion dieser Schicht
geeignet sind, ausgeführt
werden kann. Z.B. bieten ein Dateitransferprotokoll und ein E-Mail-Protokoll
Benutzerdienste und sind somit Teil der Anwendungsschicht. Jedes Protokoll
kommuniziert mit einem ranggleichen Protokoll, das eine standardisierte
Implementierung des gleichen Protokolls in der äquivalenten Schicht eines entfernten
Systems darstellt. Z.B. ist ein lokales E-Mail-Protokoll ranggleich
mit einem entfernten E-Mail-Protokoll. Als anderes Beispiel tauscht
BGP auf einem lokalen Router Routinginformation mit BGP auf einem
benachbarten Router aus.
-
Anwendungen
wie etwa BGP, die ein Transportprotokoll erfordern, um zuverlässige Datenzustellung
zu gewährleisten,
verwenden oft TCP, weil TCP überprüft, dass
die Daten über
ein Netzwerk (zwischen getrennten Endsystemen) exakt und in der richtigen
Reihenfolge übertragen
werden. TCP gewährleistet
Zuverlässigkeit
mit einem Mechanismus, der als positive Bestätigung mit Neuübertragung
(Positive Acknowledgement with Retransmission, PAR) bezeichnet wird.
Einfach gesagt überträgt ein System mit
PAR diejenigen Daten neu, für
die es von einem entfernten Knoten keine Bestätigungsnachricht empfangen
hat. Information wird zwischen zusammenarbeitenden TCP-Modulen in
Segmenten übertragen. Ein
Segment ist ein Datagramm, das einen TCP-Header und evtl. Daten
enthält.
Der TCP-Header enthält
Sequenznummern. Steuerinformation, als Handshake bezeichnet, wird
zwischen den zwei Endpunkten ausgetauscht, um einen Dialog einzurichten, bevor
Daten übertragen
werden.
-
Wie
zuvor diskutiert, läuft
das Border Gateway Protocol (BGP) typischerweise über TCP
(z.B. Port 179). BGP Version 4 (BGP4) ist das gegenwärtige externe
De-facto-Routingprotokoll für
Inter-Domain-Routing (autonome Systeme). BGP ist ein Protokoll,
das verwendet wird, um Routen zwischen Netzwerken von Routern, z.B.
zwischen dem Netzwerk eines Dienstanbieters und dem eines Betreibers,
bekannt zu machen. Router an den Rändern dieser Netzwerke tauschen
BGP-Meldungen aus, die Hunderttausende von Routen beeinflussen könnten. Wenn
der BGP-Prozess
an einem dieser Randrouter terminiert (z.B. wegen eines Neustarts,
Hardwarestörung,
Softwareaktualisierung etc.), wird der Dienst auf den Routen zwischen
den Netzwerken üblicherweise
beeinträchtigt.
Die Terminierung bewirkt auch den Austausch zusätzlicher BGP-Nachrichten zwischen
anderen Randroutern, um Information über verfügbare Routen zu aktualisieren.
Folglich führt
die Terminierung zu einem Zeitraum von Routeninstabilität und Unverfügbarkeit
des betroffenen Routers, wobei es wünschenswert ist, diese Folgen
zu vermeiden. Außerdem
führt die
Beendigung häufig
dazu, dass eine Flut von Reroutingnachrichten in das Netzwerk gesendet
wird, was die Leistungsfähigkeit
des Netzwerks beeinträchtigt.
-
Eine
herkömmliche
BGP-Redundanztechnik für
den Umgang mit BGP-Prozessstörungen beinhaltet
das parallele Konfigurieren von zwei oder mehr Routern unterschiedlicher
Verkäufer.
Das Ziel einer solchen Technik ist, das Potenzial für BGP-Prozessstörungen zu
verringern, indem man sich auf die Annahme verlässt, dass einer der Router
wenigstens manchmal einen bestimmten Satz von Umständen überstehen
wird, der zum Versagen eines anderen Routers führen könnte. Z.B. könnte wenigstens
einer der Router idealerweise Immunität gegen eine Störung aufweisen,
die etwa durch eine unzulässige Nachricht,
einen Hardwarefehler oder einen Softwarefehler verursacht werden
könnte.
D.h. es wird angenommen, dass Router von unterschiedlichen Verkäufern empfindlich
gegen unterschiedliche Typen von Störungen sind. Aufgrund der inhärenten Kosten mehrerer
Router und weil die Verwendung von Geräten unterschiedlicher Verkäufer zusätzlichen
Aufwand, Unterstützung,
Netzwerkverwaltung und Trainingskosten verursacht, ist diese Art
von herkömmlicher
BGP-Redundanztechnik
im allgemeinen kostspielig. Außerdem
erfordert diese Art von herkömmlicher
BGP-Redundanztechnik den Austausch von zusätzlichen BGP-Nachrichten, um
die Routen auf den Tandem-Router zu verschieben, wodurch sich Kosten, Komplexität und Netzwerkverkehr
vermehren. Die angeschlossenen Routen bemerken immer noch, dass
der erste Router verschwunden ist, und routen dann um diesen herum.
Folglich ist es wünschenswert,
die mit einer solchen herkömmlichen
BGP-Redundanztechnik
zusammenhängenden
Nachteile zu vermeiden.
-
Ein „schöner" Neustartmechanismus
für einen
Router ist eine andere herkömmliche
Technik zum Umgang mit BGP-Prozessstörungen. Ein solcher „schöner" Neustartmechanismus
wird in einem Entwurf der Internet Engineering Taskforce (IETF) mit
dem Titel „Graceful
Restart Mechanism for BGP" vorgeschlagen.
In diesem Vorschlag hat ein Router die Fähigkeit, seinen Weiterleitungsstatus
(Routen) über
einen BGP-Neustart hinweg aufrecht zu erhalten, die Fähigkeit,
gleichrangige Router über
diese Fähigkeit
zu benachrichtigen, und die Fähigkeit, gleichrangige
Router über
eine geschätzte
Zeit für die
Beendigung des Neustarts zu informieren, bevor er einen solchen
Neustart beginnt. Wenn erfasst wird, dass der BGP-Prozess des Routers
terminiert ist (d.h. ein Router gestört ist), und in Reaktion auf den
Empfang einer entsprechenden Benachrichtigung senden die gleichrangigen
Router keine neuen besten Routen, um den gestörten Router abzufangen, es
sei denn, dieser startet in der angegebenen Zeitspanne nicht neu.
-
Ein
solcher „schöner" Neustartmechanismus erfordert,
dass die gleichrangigen Router in der Lage sind, die Neustartbenachrichtigung
zu interpretieren und zu beantworten. Außerdem kann der gestörte Router
während
des Neustarts Routing-Aktualisierungen, die normalerweise empfangen
würden,
nicht bearbeiten. Somit verliert er während des Zeitraums der Nichtverfügbarkeit
seine Aktualität,
worauf ein Schwall von Aktualisierungen folgt, sobald er wieder in
Betrieb ist. Diese Aktualisierungen führen zu erhöhter Unordnung in den Routingtabellen
anderer Router, was die Leistungsfähigkeit des Netzwerks beeinträchtigt und
deshalb vermieden werden sollte. Schlimmer noch, Routingschleifen
oder „schwarze Löcher" können sich
in diesem Nichtverfügbarkeitszeitraum
bilden. Solche „schwarzen
Löcher" treten auf, wenn
eine Route als verfügbar
bekannt gemacht wird, der entsprechende Router aber tatsächlich nicht
konfiguriert ist, um eine solche Route zu unterstützen, was
zum Verlust von Paketen führt,
die über diese
Route übertragen
werden sollten. Außerdem kann
es vorkommen, dass der Router nicht wieder in Betrieb geht. Da außerdem der „schöne" Neustartmechanismus
es erlaubt, den Zeitraum für
den Neustart von Routern zu spezifizieren, kann ein Abwarten über diese
Zeitspanne die Zeit verlängern,
die erforderlich ist, um eine Störung
zu erfassen und um den gestörten
Router herum zu routen. Zusätzlich
erfordert die Implementierung eines solchen „schönen" Neustartmechanismus Protokollerweiterungen
des BGP, an die sich alle Router, die die Störung wahrnehmen, halten müssen, um
den „schönen" Neustartmechanismus
zu unterstützen.
Folglich ist es wünschenswert,
die mit dem „schönen" Neustartmechanismus
verbundenen Nachteile zu vermeiden.
-
Daher
ist es nützlich,
die Synchronisierung von Protokollaufgaben und darauf bezogener
Information an redundanten Routingmodulen eines Netzwerkelements
auf eine Weise zu erleichtern, die es erlaubt, Begrenzungen zu überwinden,
die mit herkömmlichen
Redundanztechniken verbunden sind.
-
Das
Patentdokument WO-A-02 01413 offenbart eine Technik zum Synchronisieren
und Verbreiten von Routing-Datenbanken. Das Datenbankverwaltungssystem
wird auf mehreren Prozessoren betrieben, die mit unterschiedlichen
Protokollen arbeiten und die mit der Datenbank wechselwirken können. Fehlertolerante
Redundanz wird erreicht, indem sich Klienten bei mehreren Servern
registrieren, um Redundanz zu schaffen, insbesondere durch Aktivieren
eines sekundären
Servers im Falle einer Störung des
primären
Servers.
-
Einem
ersten Aspekt zufolge wird durch die Erfindung ein Verfahren zum
Ermöglichen
von Routingprotokollredundanz an einem Netzwerkelement geschaffen,
wie in Anspruch 1 definiert. Es wird auch eine Vorrichtung zum Erleichtern
von Routingprotokollredundanz in einem Netzwerkelement wie in Anspruch
11 definiert geschaffen.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Flussdiagramm, das ein Verfahren zum Synchronisieren von TCP-Tasks
darstellt, die auf redundanten Routingmodulen eines Netzwerkelements
gemäß einer
Ausgestaltung der hier gelieferten Offenbarung laufen.
-
2 ist
ein Flussdiagramm, das ein Verfahren zum Erleichtern einer Aktivitätsumschaltung
gemäß einer
Ausgestaltung der hier gelieferten Offenbarung zeigt.
-
3 ist
ein Flussdiagramm, das ein Verfahren zum Synchronisieren von Routingprotokoll-Information
in Verbindung mit einem Netzwerk von Routingmodulen eines Netzwerkelements
gemäß einer Ausgestaltung
der hier gelieferten Offenbarung zeigt.
-
4 ist
ein Blockdiagramm, das ein Netzwerkelement 400 zeigt, das
in der Lage ist, Verfahren gemäß den Ausgestaltungen
der hier gelieferten Offenbarung auszuführen.
-
Detaillierte
Beschreibung der Figuren
-
Eine
Ausgestaltung eines Verfahrens und einer Vorrichtung zum Synchronisieren
von Routingprotokoll-Information in Verbindung mit einer Mehrzahl
von Routingmodulen eines Netzwerkelements wird hier offenbart. Das
Verfahren umfasst eine Operation zum Hinzufügen eines zusätzlichen
Routingmoduls zu einem Netzwerkelement. Das Netzwerkelement umfasst
ein bestehendes Routingmodul und eine diesem zugeordnete bestehende
Sammlung von Routingprotokoll-Informationen. In Reaktion auf die
Hinzufügung
des zusätzlichen
Routingmoduls zu dem Netzwerkelement wird eine Operation durchgeführt, um
das zusätzliche
Routingmodul mit der bestehenden Sammlung von Routingprotokoll-Information
auszustatten. Nach dem Aktualisieren des bestehenden Routingmoduls
mit solcher neuer Routingprotokoll-Information wird eine Operation
durchgeführt,
um das zusätzliche
Routingmodul mit solcher neuer Routingprotokoll-Information zu aktualisieren.
-
Die
hier gelieferte Offenbarung betrifft diverse Aspekte des Erleichterns
von Synchronisation von redundanten Routingmodulen in einem Netzwerkelement.
Gemäß Ausgestaltungen
der hier gelieferten Offenbarung werden Aufgaben einer niedrigeren Protokollschicht
(z.B. Transmission Control Protocol (TCP)) und einer höheren Protokollschicht
(z.B. Border Gateway Protocol (BGP)) eines ersten Routingmoduls
synchronisiert mit entsprechenden Tasks der niedrigeren Protokollschicht
(z.B. TCP) und der höheren
Protokollschicht (BGP) eines zweiten Routingmoduls. Das erste und
das zweite Routingmodul sind redundante Routingmodule in einem Netzwerkelement.
Protokollinformation (z.B. TCP-Pakte, BGP-Pakete etc.) die in dem ersten Routingmodul (z.B.
einem aktiven Modul aus einer Mehrzahl von redundanten Routingmodulen)
verarbeitet wird, wird entsprechend auf dem zweiten Routingmodul
(z.B. einem inaktiven Modul aus der Mehrzahl von redundanten Routingmodulen)
verarbeitet. Dementsprechend umfasst ein solches Netzwerkelement
gemäß einer
Ausgestaltung der hier gelieferten Offenbarung vorteilhafterweise
redundante synchronisierte Routingmodule, die in der Lage sind,
Betreiber-Dienstqualität über Netzwerke
mit diversen Kommunikationsprotokollen (z.B. Internet-Protokoll etc.) hinweg bereitzustellen.
Ein Paket einer niedrigeren Protokollschicht (z.B. TCP) (das als
ein Segment bezeichnet werden kann), ist nicht notwendigerweise
kongruent mit einem Paket einer höheren Protokollschicht (z.B. BGP).
Z.B. ist es nicht notwendigerweise wahr, dass ein TCP-Paket ein
BGP-Paket enthält.
Beispielsweise möge
ein Knoten zwei BGP-Pakete A und B übertragen, wobei jedes Paket
1.000 Byte enthält.
Eine TCP-Task wird höchstwahrscheinlich
Abschnitte dieser BGP-Pakete in getrennten TCP-Paketen übertragen.
Z.B. kann ein erstes TCP-Segment 512 Datenbytes (die ersten 512
Bytes des BGP-Pakets A) enthalten, und ein zweites TCP-Segment kann
512 Datenbytes enthalten (die restlichen 488 Bytes des BGP-Pakets
A zusammen mit den ersten 24 Bytes des BGP-Pakets B), ein drittes
TCP-Segment kann 512 Datenbytes (die nächsten 512 Bytes des BGP-Pakets
B) enthalten, und schließlich
kann ein viertes TCP-Segment 464 Datenbytes (die restlichen 464
Bytes des BGP-Pakets B) enthalten. Das oben Gesagte ist lediglich
ein Beispiel, und andere Beziehungen zwischen Paketen niedrigerer
Protokollschicht und Paketen höherer
Protokollschicht sind absolut möglich.
-
Ausgestaltungen
der hier gelieferten Offenbarung sind in der Lage, redundante Tasks
niedrigerer Protokollschicht (z.B. TCP-Tasks) und Tasks höherer Protokollschicht (z.B.
BGP-Tasks) zu ermöglichen
und so eine Aktivitätsumschaltung
zu erlauben, ohne den Dienst zu beeinträchtigen. Wenn in solchen Ausgestaltungen
ein Aktivitätsschalter
implementiert wird, wird eine Dienstunterbrechung auf von solchen Protokollen
höherer
und niedrigerer Schicht verteilten Routen begrenzt, wenn nicht beseitigt.
Z.B. verarbeitet nach einer solchen Aktivitätsumschaltung ein neu aktiviertes
Routingmodul (d.h. das zuvor inaktive Routingmodul) Routingaktualisierungen,
die normalerweise von einem neu inaktivierten Routingmodul (d.h.
dem zuvor aktiven Routingmodul) empfangen würden. Außerdem verliert das neu aktivierte
Routingmodul nicht seine Aktualität in Bezug auf auf den anderen
Netzwerkelementen gehaltene Routinginformation. Auf diese Weise
wird das Netzwerk nicht durch einen Schwall von Aktualisierungen
in Reaktion auf die Aktivitätsumschaltung
belastet. Indem die Last eines solchen Schwalls von Aktualisierungen begrenzt
wird, wird die „Unordnung" in den Routingtabellen
von Netzwerkelementen beseitigt und somit die Leistungsfähigkeit des
Netzwerks verbessert. Wichtig ist, dass der Dienst auf bestehenden
Routen erhalten bleibt, und dass ein Übergang auf bestehende Routen,
ein Löschen
von Routen und ein Hinzufügen
von Routen unterbrechungslos weitergehen können; die Umschaltung ist für benachbarte
Router transparent. Indem sie für
benachbarte Router transparent ist, benötigt eine hier offenbarte Technik
keine Kooperation von benachbarten Routern, um eine Aktivitätsumschaltung
zu ermöglichen.
Daher müssen die
benachbarten Router weder auf eine solche Aktivitätsumschaltung
hingewiesen werden, noch müssen
sie Protokollerweiterungen unterstützen, um eine solche Aktivitätsumschaltung
zu ermöglichen.
-
Solche
Ausgestaltungen sind insofern vorteilhaft, als ein unzulässiges Informationspaket,
das zum Versagen einer Task einer höheren Protokollschicht eines
ersten Routingmoduls führt,
nicht notwendigerweise zum Versagen der gleichen Task höherer Protokollschicht
eines zweiten Routingmoduls führt,
das redundant und mit dem ersten Routingmodul synchronisiert ist.
Eine Ausgestaltung einer Technik zum Begrenzen des Störungspotenzials
des zweiten Routingmoduls durch das unzulässige Informationspaket ist,
eine Task höherer
Protokollschicht (z.B. eine BGP-Task) eines inaktiven Moduls aus
einer Mehrzahl von synchronisierten Routingmodulen (d.h. ein inaktives
Routingmodul) um wenigstens ein Paket der höheren Protokollschicht (z.B.
ein BGP-Paket) gegen die gleiche Task höherer Protokollschicht eines
aktiven Moduls aus der Mehrzahl von synchronisierten Routingmodulen
(dem aktiven Routingmodul) verzögert
zu halten. Auf diese Weise wird das unzulässige Paket als solches erkannt,
bevor es von der Task höherer
Protokollschicht des inaktiven Routingmoduls verarbeitet wird, wodurch
die Störung
der Task höherer
Protokollschicht des inaktiven Routingmoduls, die anderenfalls resultieren
würde,
vermieden wird.
-
Ein
anderer vorteilhafter Effekt der hier gelieferten Offenbarung ist,
dass die Verarbeitungsleistung eines Netzwerkelements nicht beeinträchtigt wird.
Genauer gesagt werden Synchronisation und Redundanz gemäß Ausgestaltungen
der hier gelieferten Offenbarung in effizienter und wirksamer Weise
erleichtert. Entsprechend ist ein überwiegender Teil der Verarbeitungsleistung
des Netzwerkelement verfügbar,
um primäre
Aufgaben des Netzwerkelements (z.B. Vermitteln, Routen etc.) zu
erledigen.
-
Ein
weiterer vorteilhafter Aspekt der hier gelieferten Offenbarung ist,
dass solche Ausgestaltungen preiswerter zu implementieren und zu
warten sind als herkömmliche
Lösungen.
Solche Ausgestaltungen erfordern keine redundanten Netzwerkelemente,
sondern statt dessen redundante Routingmodule in einem bestimmten
Netzwerkelement. Bei manchen Ausgestaltungen werden die redundanten Routingmodule
identisch implementiert, wodurch Kosten reduziert werden. Z.B. kann
gleiche Software in jedem der redundanten Routingmodule ausgeführt werden.
In anderen Ausgestaltungen können
unterschiedlich implementierte redundante Routingmodule verwendet
werden.
-
Es
versteht sich, dass Ausgestaltungen der vorliegenden Erfindung mit
diversen Protokollen höherer
Schicht praktiziert werden können.
Es werden hier zwar an verschiedenen Stellen BGP-Pakete erwähnt, doch
versteht sich, dass Routen auch von anderen Protokollen (z.B. Open
Shortest Path First (OSPF)) oder durch Konfigurationsänderungen
(z.B. statische Routen) eintreffen können. Nicht nur die Routen,
sondern auch die Konfiguration wird zwischen einem aktiven Routingmodul
und einem inaktiven Routingmodul synchronisiert gehalten. Die Konfiguration
kann sich auch im Betrieb ändern
(z.B. kann ein gleichrangiger BGP-Knoten jederzeit hinzugefügt oder
entfernt werden). Zu beachten ist, dass eine höhere Protokollschicht zum Bekanntmachen von
Routen verwendet werden kann, aber auch zum Entfernen von Routen
(z.B. kann ein BGP-Paket auch eine zu entfernende Route spezifizieren).
-
Bezogen
auf die Figuren ist ein Verfahren 100 zum Synchronisieren
von TCP-Tasks, die auf redundanten Routingmodulen eines Netzwerkelements gemäß einer
Ausgestaltung der Erfindung laufen, in 1 abgebildet.
Das Verfahren wird durchgeführt von
einem Netzwerkelement, das vorzugsweise eine Leitungskarte (line
card) 134, ein aktives Routingmodul 136 und ein
inaktives Routingmodul 138 umfasst. Diverse Schritte des
Verfahrens werden dargestellt als durchgeführt von der Leitungskarte 134,
von dem aktiven Routingmodul 136 und von dem inaktiven Routingmodul 138.
Das Verfahren 100 beginnt mit einer Operation 102,
wo eine Leitungskarte eines Netzwerkelements eine Protokolldateneinheit
(PDU) oder eine Kopie davon zum Empfang durch ein aktives Routingmodul
und ein inaktives Routingmodul des Netzwerkelements weiterleitet.
Ein Internetprotokoll-Routingmodul
ist ein Beispiel sowohl für
das aktive als auch das inaktive Routingmodul. Eine Vorrichtung,
die in der Lage ist, Routingfunktionalität bereitzustellen, (d.h. ein
Router) ist ein Beispiel für
das Netzwerkelement. Bei anderen Ausgestaltungen muss das Netzwerkelement
nicht auf einem Router implementiert sein, sondern kann auf einer
oder mehreren Netzwerkvorrichtungen implementiert sein. Beispielsweise
kann bei Ausgestaltungen, wo die Protokollpakete höherer Ebene
Multiprotokoll-Labelswitching-Pakete
sind, das Netzwerkelement so implementiert sein. Entsprechend können das
aktive Routingmodul und das inaktive Routingmodul allgemein einfach
als ein aktives Modul und ein inaktives Modul angenommen werden.
Das aktive Routingmodul führt
eine Operation 104 zum Empfang der PDU durch, während das
inaktive Routingmodul in der Operation 140 die PDU ignoriert
(d.h. sie empfängt aber
nicht verarbeitet).
-
Nach
Empfang der PDU führt
das aktive Routingmodul eine Operation 106 zum Extrahieren eines
in der PDU verkapselten TCP-Pakets aus. Das aus der PDU extrahierte
TCP-Paket wird im Folgenden als einwärts gerichtetes TCP-Paket bezeichnet. Die
TCP-Task des aktiven Routingmoduls führt eine Operation 110 zum
Empfang der ersten Kopie des einwärts gerichteten TCP-Pakets aus.
-
Nachdem
das aktive Routingmodul die erste Kopie des einwärts gerichteten TCP-Pakets
empfangen hat, führt
die aktive Routingmodul-TCP-Task eine Operation 114 zum
Speichern der ersten Kopie des einwärts gerichteten TCP-Pakets
in einer Empfangswarteschlange aus, die der aktiven Routingmodul-TCP-Task zugeordnet ist.
Nach der Operation 114 führt das aktive Routingmodul
eine Operation 142 aus, um festzulegen, ob das einwärts gerichtete TCP-Paket
an das inaktive Routingmodul 138 weitergeleitet werden
sollte oder nicht. Wenn festgestellt wird, dass das einwärts gerichtete
TCP-Paket nicht weitergeleitet werden sollte, geht der Prozess weiter zur
Operation 144, in der das einwärts gerichtete TCP-Paket nicht
weitergeleitet wird. Wenn festgestellt wird, dass das TCP-Paket weitergeleitet
werden sollte, geht der Prozess weiter mit Operationen 108 und 120.
In Operation 108 leitet das aktive Routingmodul eine erste
Kopie des einwärts
gerichteten TCP-Pakets zum Empfang durch eine TCP-Task des aktiven
Routingmoduls (d.h. die aktive Routingmodul-TCP-Task) und eine zweite
Kopie des einwärts gerichteten
TCP-Pakets zum Empfang durch eine TCP-Task des inaktiven Routingmoduls
(d.h. die inaktive Routingmodul-TCP-Task) weiter. In wenigstens
einer Ausgestaltung wird die Operation 114 vor der Operation 108 ausgeführt, während in
wenigstens einer Ausgestaltung Operation 108 vor Operation 114 ausgeführt wird.
Es ist wichtig zu beachten, dass das aktive Routingmodul das eintreffende TCP-Paket
verarbeitet und dann ggf. das eintreffende TCP-Paket (zusammen mit
anderer Information) an das inaktive Routingmodul weiterleitet.
Manche eintreffenden TCP-Pakete, z.B. Bestätigungen, die keine Daten enthalten,
müssen
nicht an das inaktive Routingmodul weitergeleitet werden. Die inaktive Routingmodul-TCP-Task
führt eine
Operation 112 zum Empfang der zweiten Kopie des einwärts gerichteten
TCP-Pakets aus. Entsprechend führt
die inaktive Routingmodul-TCP-Task, nachdem das inaktive Routingmodul
die zweite Kopie des einwärts
gerichteten TCP-Pakets empfangen hat, eine Operation 116 zum
Speichern der zweiten Kopie des einwärts gerichteten TCP-Pakets
in einer Empfangswarteschlange aus, die der inaktiven Routingmodul-TCP-Task
zugeordnet ist. Die Operation 116 zum Speichern der zweiten
Kopie des einwärts
gerichteten TCP-Pakets in einer der inaktiven Routingmodul-TCP-Task zugeordneten
Warteschlange umfasst ein anfängliches
Speichern der zweiten Kopie des einwärts gerichteten TCP-Pakets in einem Anhängig-Abschnitt
der der inaktiven Routingmodul-TCP-Task zugeordneten Empfangswarteschlange
(d.h. im Anhängig-Abschnitt
der inaktiven Routingmodul-Empfangswarteschlange).
-
In
Operation 120 erleichtert eine BGP-Task des aktiven Routingmoduls
(d.h. die aktive Routingmodul-BGP-Task) die Aufzeichnung des ranggleichen
Netzwerkelements, von dem her das einwärts gerichtete TCP-Paket empfangen
wurde. Wie im Folgenden genauer mit Bezug auf 2 diskutiert,
wird eine solche Aufzeichnung des ranggleichen Netzwerkelements,
von dem das einwärts
gerichtete TCP-Paket empfangen wurde, verwendet, um eine Aktivitätsumschaltung
von dem aktiven Routingmodul auf das inaktive Routingmodul zu erleichtern, wenn
eine Störung
während
der Verarbeitung des BGP-Pakets auftritt. Nach der Operation 120 führt die aktive
Routingmodul-BGP-Task eine Operation 118 zur Verarbeitung
der BGP-Nachricht aus.
-
Nach
der Operation 118 wird eine Operation 121 durchgeführt, um
zu bestimmen, ob die Verarbeitung der in der ersten Kopie des einwärts gerichteten TCP-Pakets
enthaltenen BGP-Nachricht erfolgreich durchgeführt ist. Wenn die Operation 118 zum
Verarbeiten einer in der ersten Kopie des einwärts gerichteten TCP-Pakets
enthaltenen BGP-Nachricht erfolgreich durchgeführt ist, führt die inaktive Routingmodul-TCP-Task
eine Operation 122 zum Speichern der zweiten Kopie des
einwärts
gerichteten TCP-Pakets in einem Fertig-Abschnitt der Empfangswarteschlange
aus, die der inaktiven Routingmodul-TCP-Task zugeordnet ist (d.h.
in dem Fertig-Abschnitt der inaktiven Modulempfangswarteschlange).
In wenigstens einer Ausgestaltung der Operation 122 umfasst
die Operation 122 zum Speichern der zweiten Kopie des einwärts gerichteten
TCP-Pakets im Fertig-Abschnitt der
inaktiven Routingmodul-Empfangswarteschlange das Weiterleiten der
zweiten Kopie des einwärts gerichteten
TCP-Pakets von dem
Anhängig-Abschnitt
zum Fertig-Abschnitt der inaktiven Routingmodul-Empfangswarteschlange.
Wenn in Operation 121 festgestellt wird, dass die Verarbeitung
der in der ersten Kopie des einwärts
gerichteten TCP-Pakets enthaltenen BGP-Nachricht erfolgreich durchgeführt wurde,
kann die zweite Kopie des einwärts
gerichteten TCP-Pakets sofort aus dem Anhängig-Abschnitt in den Fertig-Abschnitt
der inaktiven Routingmodul-Empfangswarteschlange bewegt werden,
doch ist es in wenigstens einer Ausgestaltung vorteilhaft, aus Leistungsgründen eine
solche Aktion zu einem späteren
Zeitpunkt auszulösen.
Z.B. kann eine Anweisung an das inaktive Routingmodul, die Operation 122 auszuführen, anderer
für das
inaktive Routingmodul bestimmter Information beigeschlossen sein, um
die Notwendigkeit zu vermeiden, die Anweisung getrennt zu senden
und die Menge an an das inaktive Routingmodul gesendeter Information
und die Menge der für
das inaktive Routingmodul benötigten
Verarbeitung zu minimieren.
-
Nachdem
und nur nachdem die zweite Kopie des einwärts gerichteten TCP-Pakets
im Fertig-Abschnitt der inaktiven Routingmodul-Empfangswarteschlange
gespeichert ist, führt
die inaktive Routingmodul-BGP-Task eine Operation 124 zum
verarbeiten der in der zweiten Kopie des einwärts gerichteten TCP-Pakets
enthaltenen BGP-Nachricht aus. Das aktive Routingmodul führt eine
Operation 126 zum Ausgeben einer Bestätigungsnachricht zum Anzeigen,
dass das einwärts
gerichtete TCP-Paket empfangen worden ist, aus. In wenigstens einer
Ausgestaltung wird Operation 126 nach Operation 122 ausgeführt, während in
wenigstens einer anderen Ausgestaltung Operation 126 vor
Operation 122 ausgeführt
wird, sofern sie nach Operation 116 ausgeführt wird.
Die Operation zum anfänglichen
Speichern der zweiten Kopie des einwärts gerichteten TCP-Pakets in
dem Anhängig-Abschnitt
der inaktiven Routingmodul-Empfangswarteschlange und dann im Fertig-Abschnitt der inaktiven
Routingmodul-Empfangswarteschlange ermöglicht es der zweiten Kopie
des einwärts
gerichteten TCP-Pakets,
von der inaktiven Routingmodul-BGP-Task unverarbeitet zu bleiben, bis
der Inhalt des einwärts
gerichteten TCP-Pakets als harmlos (d.h. keine BGP-Task-Störung verursachend)
festgestellt worden ist, indem die aktive Routingmodul-BGP-Task die erste Kopie
des einwärts gerichteten
TCP-Pakets erfolgreich verarbeitet hat. Auf diese Weise verarbeitet
die inaktive Routingmodul-BGP-Task eine bestimmte BGP-Nachricht,
nachdem die aktive Routingmodul-BGP-Task diese bestimmte BGP-Nachricht verarbeitet
hat.
-
Bei
wenigstens einer Ausgestaltung der aktiven und inaktiven Routingmodul-BGP-Tasks
sind diese BGP-Tasks ausgeschlossen vom Empfang partieller TCP-Pakete
von der TCP-Task. Solche partiellen Pakete können partielle BGP-Nachrichten
enthalten, die möglicherweise
Synchronisationsprobleme verursachen, wenn ein Aktivitätsumschalter
implementiert ist. Es wird hier davon ausgegangen, dass eine TCP-Task
so konfiguriert sein kann, dass sie eine zugeordnete BGP-Task daran
hindert, zu erkennen, dass Information eines Pakets empfangen wird, bis
die Information ein vollständiges
Paket umfasst. Eine Socket-Option
zum Ermöglichen
einer solchen Funktionalität
existiert.
-
Durch
Ermöglichen
der Verarbeitung der in der zweiten Kopie des einwärts gerichteten
TCP-Pakets enthaltenen BGP-Nachricht nur nachdem die zweite Kopie
des TCP-Pakets in dem Fertig-Abschnitt
der inaktiven Routingmodul-Empfangswarteschlange gespeichert ist,
wird sichergestellt, dass eine solche Verarbeitung der in der zweiten
Kopie des TCP-Pakets enthaltenen BGP-Nachricht nur stattfindet,
nachdem die in der ersten Kopie des TCP-Pakets enthaltene BGP-Nachricht
von der aktiven Routingmodul-BGP-Task erfolgreich verarbeitet ist.
Es versteht sich, dass die in der ersten Kopie und der zweiten Kopie
des einwärts
gerichteten TCP-Pakets enthaltenen BGP- Nachrichten im wesentlichen identisch
(d.h. die gleiche BGP-Nachricht)
sind. Folglich ist das Potenzial für ein Versagen von aktiver
und inaktiver Routingmodul-BGP-Task aufgrund der gleichen BGP-Nachricht
wesentlich reduziert, wenn nicht beseitigt.
-
Indem
die Bestätigungsnachricht,
die angibt, dass das einwärts
gerichtete TCP-Paket empfangen worden ist (z.B. Operation 126)
nur ausgegeben wird, nachdem die zweite Kopie des TCP-Pakets in
dem Anhängig-Abschnitt
der inaktiven Routingmodul-Empfangswarteschlange
gespeichert worden ist, wird sichergestellt, dass auch im Falle
einer Aktivitätsumschaltung
das inaktive Routingmodul keine TCP-Pakete versäumt. Wenn eine solche Aktivitätsumschaltung
nicht auftritt, wird die BGP-Nachricht,
die in der ersten Kopie des TCP-Pakets enthalten ist, von der aktiven
Routingmodul-BGP-Task erfolgreich verarbeitet. Außerdem wird
bei einer Aktivitätsumschaltung
die TCP-Kommunikation mit dem ranggleichen Netzwerkelement, das
ein TCP-Paket mit einer unzulässigen
BGP-Nachricht gesendet hat, abgebrochen. Diese Operationsfolge gewährleistet, dass
ein TCP-Paket, das eine unzulässige BGP-Nachricht
enthält,
nicht verarbeitet wird, nachdem eine solche Nachricht zum Versagen
der aktiven Routingmodul-BGP-Task geführt hat. So wird die Redundanz-Robustheit
verbessert.
-
Mit
Bezug auf Aktualisierungsnachrichten, die von dem Netzwerkelement
zum Empfang durch dessen ranggleiche Netzwerkelemente ausgesandt werden,
erkennt man, dass Redundanz auch im Hinblick auf solche auswärts gerichteten
Aktualisierungsnachrichten erzielt werden kann. Z.B. wird in Reaktion
auf den Empfang einer BGP-Nachricht, die eine neue Route bezeichnet,
eine Routenaktualisierungsnachricht von dem Netzwerkelement zum
Empfang durch eines oder mehrere seiner ranggleichen Netzwerkelemente
ausgesendet, um diese ranggleichen Netzwerkelemente über die
neue Route zu informieren.
-
Folglich
wird in Reaktion auf den Empfang solcher Typen von BGP-Nachrichten,
die eine auswärts
gerichtete Aktualisierungsnachricht erforderlich machen, oder den
Empfang einer Route von einem anderen Protokoll (z.B. OSPF oder
ISIS) oder in Reaktion auf ein internes Ereignis (z.B. eine Konfigurationsänderung
wie etwa die Hinzufügung
eines statischen Routers, für
die eine Aktualisierungsnachricht erzeugt werden sollte, eine Operation 128, 1, zum
Speichern einer ersten Kopie eines auswärts gerichteten BGP-Pakets verkapselt
in ein oder mehrere TCP-Pakete in einer Sendewarteschlange des aktiven
Routingmoduls (d.h. der aktiven Routingmodul-Sendewarteschlange)
durchgeführt.
Die Operation 128 geschieht nach Operation 118.
Außerdem wird
in Reaktion auf den Empfang solcher Typen von BGP-Nachrichten, die
mit einer auswärts
gerichteten Aktualisierungsnachricht zusammenhängen, durch das aktive Routingmodul
eine Operation 130 durchgeführt, um eine zweite Kopie des
auswärts
gerichteten BGP-Pakets verkapselt in ein oder mehrere TCP-Pakete in einer Sendewarteschlange
des inaktiven Routingmoduls (d.h. der inaktiven Routingmodul-Sendewarteschlange)
zu speichern. Genauso wie bei der hier offenbarten Empfangswarteschlangenfunktionalität sind bei
wenigstens einer Ausgestaltung der Sendewarteschlangen des aktiven
Routingmoduls und des inaktiven Routingmoduls diese Sendewarteschlangen
ausgeschlossen von der Speicherung partieller BGP-Pakete. Eine Operation 132 wird
durchgeführt,
um die erste Kopie des auswärts
gerichteten BGP-Pakets verkapselt in ein oder mehrere TCP-Pakete
von der aktiven Routingmodul-Sendewarteschlange zum Empfang durch
ein oder mehrere ranggleiche Netzwerkelemente weiterzuleiten, nachdem
die zweite Kopie des in ein oder mehrere TCP-Pakete verkapselten
auswärts
gerichteten BGP-Pakets in der inaktiven Routingmodul-Sendewarteschlange
gespeichert ist. Auf diese Weise werden Neuübertragung und Paketsequenzierungsfunktionalität nach einer
Aktivitätsumschaltung vom
aktiven Routingmodul auf das inaktive Routingmodul aufrecht erhalten.
-
Wieder
bezogen auf Operation 121 ist diese Operation in der Lage
zu bestimmen, ob die Verarbeitung der in der ersten Kopie des einwärts gerichteten TCP-Pakets
enthaltenen BGP-Nachricht nicht erfolgreich durchgeführt ist.
In Reaktion auf die nicht erfolgreiche Verarbeitung der in der ersten
Kopie des einwärts
gerichteten TCP-Pakets enthaltenen BGP-Nachricht durch die aktive
Routingmodul-BGP-Task wird eine Aktivitätsumschaltung ermöglicht und
der Prozess zu einem Eingangspunkt „A" geleitet. Die Aktivitätsumschaltung überträgt Online-Operationen des Netzwerkelements
vom zuvor aktiven Routingmodul (jetzt das inaktive Routingmodul)
auf ein neu aktiviertes Routingmodul (zuvor das inaktive Routingmodul).
-
2 zeigt
ein Verfahren 200 zum Erleichtern einer Aktivitätsumschaltung
gemäß einer
Ausgestaltung der hier gegebenen Offenbarung. Das Verfahren 200 betrifft
eine Aktivitätsumschaltung,
die aus einem unzulässigen
einwärts
gerichteten TCP-Paket resultiert. Ein TCP-Paket, das eine unzulässige BGP-Nachricht
enthält,
ist ein Beispiel für
das unzulässige
TCP-Paket.
-
An
einem Eingangspunkt „A", der der Verarbeitung
eines fehlerhaften BGP-Pakets eines einwärts gerichteten TCP-Pakets
(d.h. eines Pakets, für das
eine befriedigende Fehlerbehandlung nicht in anderer Weise vorgesehen
ist) entspricht, beginnt das Verfahren 200 mit einer von
einem Systemcontroller aufgerufenen Fehlerbehandlungsroutine, implementiert
eine Operation 202 zum Identifizieren eines ranggleichen
Netzwerkelements, von dem das unzulässige einwärts gerichtete BGP-Paket empfangen wurde.
Eine Ausgestaltung der Identifikation des identifizierten ranggleichen
Netzwerkelements umfasst das Lesen/Zugreifen auf eine in Reaktion
auf die Operation 120, 1, zum Erleichtern
des Aufzeichnens des ranggleichen Netzwerkelements, von dem das
unzulässige
TCP-Paket empfangen wurde, erzeugten Aufzeichnung. Zu beachten ist,
dass bei wenigstens einer Ausgestaltung, wenn das Netzwerkelement,
von dem ein Paket empfangen wurde, aufgezeichnet wird, das ranggleiche
Netzwerkelement des BGP-Pakets aufgezeichnet wird und nicht das des
TCP-Segments. Es ist möglich,
dass das ranggleiche BGP-Netzwerkelement und das ranggleiche TCP-Netzwerkelement verschieden
sind. BGP kann eine Sitzung mit einem Nachbarn haben, den zu erreichen
mehrere TCP-Sprünge
erforderlich sind. Als solches wird das identifizierte ranggleiche
Netzwerkelement mit Bezug auf das Protokollpaket höherer Ebene
(z.B. das BGP-Paket) identifiziert.
-
Der
Controller kann z.B. ein Steuerelement wie etwa ein Prozessor sein,
das an das Netzwerkelement gekoppelt oder darin einbezogen ist.
Z.B. kann der Systemcontroller als ein Prozess implementiert sein,
der die Aufzeichnung liest, um das ranggleiche Netzwerkelement festzustellen,
von dem aus das Paket empfangen wurde, und die Terminierung der zugeordneten
BGP-Sitzung auf dem inaktiven Routingmodul in Gang zu setzen. Bei
wenigstens einer Ausgestaltung ist dieser Prozess in dem aktiven
Routingmodul enthalten. Wenn es erforderlich ist, eine Sitzung zu
terminieren, kommuniziert das aktive Routingmodul (z.B. der im aktiven
Routingmodul enthaltene Systemcontroller) mit dem inaktiven Routingmodul
darüber,
welche ranggleiche Sitzung terminiert werden soll.
-
Nach
dem Identifizieren des ranggleichen Netzwerkelements, von dem aus
das unzulässige einwärts gerichtete
BGP-Paket empfangen wurde (d.h. des identifizierten ranggleichen
Netzwerkelements), führt
die Fehlerbehandlungsroutine eine Operation 204 durch,
um die Terminierung einer BGP-Sitzung in Gang zu setzen, die dem
identifizierten ranggleichen Netzwerkelement zugeordnet ist, und
eine Operation 206 zum Ingangsetzen der Terminierung einer
dem identifizierten ranggleichen Netzwerkelement zugeordneten TCP-Sitzung.
Da bei wenigstens einer Ausgestaltung das Ingangsetzen der Terminierung
einer BGP-Sitzung inhärent
auch die Terminierung einer TCP-Sitzung in Gang setzt, können optional
die Operationen 204 und 206 als eine einzige Operation
durchgeführt
werden. Genauso kann eine solche einzelne Operation zur Durchführung der
Operation 208 führen,
die wiederum inhärent
zur Durchführung
der Operation 210 führen kann.
Nach Ingangsetzen der Terminierung der dem identifizierten ranggleichen
Netzwerkelement zugeordneten BGP- und
TCP-Sitzungen führt
die neu aktivierte Routingmodul-TCP-Task eine Operation 210 zum
Abbrechen der dem identifizierten ranggleichen Netzwerkelement zugeordneten
TCP-Sitzung durch, und die demnächst
zu aktivierende Routingmodul-BGP-Task führt eine Operation 208 zum
Terminieren der dem identifizierten ranggleichen Netzwerkelement
zugeordneten BGP-Sitzung durch. In Reaktion auf die Ermöglichung
der Terminierung der dem identifizierten ranggleichen Netzwerkelement zugeordneten
TCP-Sitzung führt die
neu aktivierte Routingmodul-TCP-Task eine Operation 212 zum
Löschen
des unzulässigen
TCP-Pakets aus der Empfangswarteschlange des neu aktivierten Routingmoduls
aus. Die tatsächliche
Umschaltung der funktionellen Operationen ist erleichtert, nachdem
die TCP- und BGP-Sitzungen terminiert sind und das unzulässige einwärts gerichtete
TCP-Paket aus der Empfangswarteschlange des neu aktivierten Routingmoduls
gelöscht
ist. Da die TCP-Sitzung terminiert worden ist, wird das unzulässige einwärts gerichtete TCP-Paket
nicht neu gesendet, auch wenn es nicht bestätigt worden ist, wodurch ein
Versagen des neu aktivierten Routingmoduls vermieden wird.
-
Als
zusätzliche
Vorsichtsmaßnahme
werden TCP- und BGP-Task-Sitzungen
mit dem identifizierten ranggleichen Netzwerkelement wiederhergestellt,
nachdem eine Operation 214 zum Neustarten des neu inaktivierten
Moduls und eine Operation 216 zum Synchronisieren von bestehender
Routing-bezogener Information des neu inaktivierten Routingmoduls
mit dem neu aktivierten Routingmodul durchgeführt worden sind. Solche Routing-bezogene
Information kann Information umfassen, die in einer Routinginformationsdatenbank
gespeichert ist, sowie andere Information wie etwa Konfigurationsinformation (z.B.
statische Konfigurationsinformation) und Zustandsinformation (z.B. dynamische
Zustandsinformation). In Reaktion auf die Synchronisierung solcher
bestehender Routing-bezogener Information führt die neu aktivierte Routingmodul-BGP-Task
eine Operation 220 aus, um eine BGP-Sitzung mit dem identifizierten
ranggleichen Netzwerkelement wieder herzustellen. Um eine BGP-Sitzung
gemäß Operation 220 wieder
herzustellen, führt
die neu aktivierte Routingmodul-TCP-Task eine Operation 218 zum Wiederherstellen
einer TCP-Sitzung mit dem identifizierten ranggleichen Netzwerkelement
aus. Auf diese Weise wird das Risiko, das mit der Wiederherstellung
solcher Task-Sitzungen mit dem identifizierten Netzwerkelement ohne
Vorhandensein eines redundanten Routingmoduls verbunden ist, verringert, wenn
nicht beseitigt. Optionsweise werden in wenigstens einer Ausgestaltung
BGP- und TCP-Task-Sitzungen mit anderen ranggleichen Netzwerkelementen
neben dem identifizierten ranggleichen Netzwerkelement aufrecht
erhalten.
-
3 zeigt
ein Verfahren 300 zum Synchronisieren von Routingprotokoll-Information,
die einer Mehrzahl von Routingmodulen eines Netzwerkelements zugeordnet
ist, gemäß einer
Ausgestaltung der hier gegebenen Offenbarung. Durch Synchronisieren
solcher Routingprotokoll-Information kann Redundanz gemäß der hier
gegebenen Offenbarung implementiert werden. Eine solche Synchronisation trägt dazu
bei, eine Aktivitätsumschaltung
von einem ersten Routingmodul des Netzwerkelements zu einem zweiten
Routingmodul des Netzwerkelements in im Wesentlichen transparenter
Weise bezüglich ranggleicher
Netzwerkelemente durchzuführen.
-
Das
Verfahren 300 beginnt damit, dass ein inaktives Routingmodul
eine Operation 302 zum Empfangen einer Kopie bestehender
Routingprotokoll-Information von einem aktiven Routingmodul ausführt. Die
Operation 302 wird ausgeführt in Reaktion darauf, dass
das inaktive Routingmodul ein zusätzliches Routingmodul ist,
das zu einem Netzwerkelement, welches das aktive Routingmodul enthält, hinzugefügt wird.
Da das aktive Routingmodul ein bestehendes, in Gebrauch befindliches
Modul des Netzwerkelements ist, ist dem aktiven Routingmodul solche
bestehende Routingprotokoll-Information vor der Hinzufügung des
inaktiven Routingmoduls zugeordnet. Z.B. kann der Fall auftreten,
dass wenigstens ein Teil der Routingprotokoll-Information in dem
bestehenden Routingmodul über
einen Zeitraum vor der Hinzufügung
des zusätzlichen
Routingmoduls zu dem Netzwerkelement dynamisch erstellt wurde. Beispiele
von Routingprotokoll-Information umfassen TCP-bezogene Zustandsinformation, BGP-Konfiguration,
BGP-Routingtabellen
und Routenzustandsinformation (z.B. die Angabe, dass eine Route
ranggleichen Netzwerkelementen bekannt gemacht worden ist).
-
In
Reaktion auf den Empfang solcher bestehender Routinginformation
durch das inaktive Routingmodul wird eine Operation 304 durchgeführt, um solcher
Routingprotokoll-Information
zugeordnete Aufzeichnungen des inaktiven Routingmoduls zu aktualisieren.
Eine Ausgestaltung zum Aktualisieren solcher inaktiver Routingmodulaufzeichnungen,
die solcher bestehender Routingprotokoll-Information zugeordnet
sind, umfasst das Aktualisieren einer Routinginformationsdatenbank
des inaktiven Routingmoduls. Bei einer Ausgestaltung des inaktiven Routingmoduls
umfasst das inaktive Routingmodul keine bestehende Routingprotokoll-Information (z.B. ist
das inaktive Routingmodul ein neues Routingmodul, das in Betrieb
genommen wird). Bei einer anderen Ausgestaltung des inaktiven Routingmoduls
umfasst das inaktive Routingmodul bestehende Routingprotokoll-Information,
die aktualisiert wird.
-
Zu
einem Zeitpunkt, nachdem das inaktive Routingmodul zum Netzwerkelement
hinzugefügt worden
ist, und während
des normalen Betriebsablauf des aktiven Routingmoduls führt das
aktive Routingmodul eine Operation 306 zum Empfang einer ersten
Kopie von neuer Routingprotokoll-Information (von neu empfangener
Routingprotokoll-Information) von einem oder mehreren ranggleichen
Netzwerkelementen aus. In Reaktion auf den Empfang solcher neu empfangener
Routingprotokoll-Information
führt das
aktive Routingmodul eine Operation 308 zum Aktualisieren
von solcher neu empfangener Routingprotokoll-Information zugeordneter
Routingmodulaufzeichnungen, eine Operation 312 zum Weiterleiten einer
zweiten Kopie solcher neu empfangener Routingprotokoll-Information
zum Empfang durch das inaktive Routingmodul und eine Operation 310 zum Bestätigen des
Empfangs solcher neu empfangener Routingprotokoll-Information durch.
Die Bestätigung wird
somit den ein oder mehreren ranggleichen Netzwerkelementen erteilt,
von denen die neue Routingprotokoll-Information empfangen wurde,
nachdem eine Kopie dieser neuen Routingprotokoll-Information (oder
des Abschnitts derselben, für
den die Bestätigung
gegeben wird) an das inaktive Routingmodul (d.h. das zusätzliche
Routingmodul) weitergegeben worden ist. Nachdem das aktive Routingmodul
solche neu empfangene Routingprotokoll-Information zum Empfang durch
das inaktive Routingmodul weitergeleitet hat, führt das inaktive Routingprotokoll eine
Operation 314 zum Empfang solcher neu empfangener Routingprotokoll-Information
und eine Operation 316 zum Aktualisieren von solcher Routingprotokoll-Information zugeordneten
inaktiven Routingmodulaufzeichnungen durch. Zu beachten ist, dass die
Operationen 304 und 316 als getrennte Operationen
oder in einer einzelnen Operation kombiniert durchgeführt werden
können.
Ein TCP-Paket, das eine BGP-Nachricht enthält, ist ein Beispiel solcher neu
empfangener Routingprotokoll-Information während des normalen Operationsablaufs
des aktiven Routingmoduls.
-
Bezogen
auf 4 ist ein Netzwerkelement 400 abgebildet,
das in der Lage ist, Verfahren gemäß den Ausgestaltungen der hier
gegebenen Offenbarung auszuführen.
Genauer gesagt ist das Netzwerkelement 400 in der Lage,
gemäß der hier
gegebenen Offenbarung Redundanz- und Synchronisationsfunktionalität auszuführen. Z.B.
ist das Netzwerkelement 400 in der Lage, die hier offenbarten
Verfahren (z.B. die Verfahren 100, 200 und 300)
auszuführen.
Eine Vorrichtung, die in der Lage ist, Routingfunktionalität bereitzustellen
(z.B. ein Router) ist ein Beispiel des Netzwerkelements 400.
-
Das
Netzwerkelement 400 umfasst ein aktives Routingmodul 402 (d.h.
das erste Routingmodul), ein inaktives Routingmodul 404 (d.h.
das zweite Routingmodul) und eine Leitungskarte 405, die
zwischen aktivem und inaktivem Routingmodul (402, 404)
angeschlossen ist. Die Leitungskarte erleichtert das Routen einer
Kopie jedes einwärts
gerichteten TCP-Pakets (z.B. über
Weiterleitung entsprechender Protokolldateneinheiten (PDUs)). Die
TCP-Task des inaktiven Routingmoduls 402 ignoriert jedoch
solche TCP-Pakete (d.h. verarbeitet die PDUs nicht), während die
TCP-Task des aktiven Routingmoduls 402 solche TCP-Pakete
verarbeitet.
-
Das
aktive Routingmodul 402 und das inaktive Routingmodul 404 sind
in der Lage, redundante Funktionalität gemäß der hier gegebenen Offenbarung
zu erleichtern. Das aktive Routingmodul 402 und das inaktive
Routingmodul 404 umfassen jeweils TCP-Tasks (406, 408),
BGP-Tasks (410, 412) und Routinginformationsdatenbanken
(414, 416). Die TCP-Tasks (406, 408)
sind jeweils Beispiele von Tasks niedrigerer Protokollebene. Die
BGP-Tasks (410, 412) sind jeweils Beispiele von
Tasks höherer Protokollebene.
Es wird in Betracht gezogen, dass die BGP-Tasks (410, 412)
durch andere Protokolle ersetzt werden können, die TCP zum Austausch
von Nachrichten verwenden (z.B. Multiprotocol-Label-Switching (MPLS)).
-
Die
TCP-Task 406 des aktiven Routingmoduls umfasst eine Empfangswarteschlange 418 und eine
Sendewarteschlange 420. Die TCP-Task 408 des inaktiven
Routingmoduls 404 umfasst eine Empfangswarteschlange 422 und
eine Sendewarteschlange 424. Die Empfangswarteschlange 422 umfasst
einen Anhängig-Abschnitt 426 und
einen Fertig-Abschnit 428. Der Anhängig-Abschnitt 426 und der
Fertig-Abschnitt 428 der inaktiven Routingmodul-Empfangs warteschlange 422 erleichtern
die Funktionalität
wie in 1 abgebildet. Genauer gesagt ermöglichen
der Anhängig-Abschnitt 426 und der
Fertig-Abschnitt 428 der inaktiven Routingmodul-Warteschlange 422,
dass eine bestimmte Kopie eines TCP-Pakets von der inaktiven Routingmodul-BGP-Task 412 unverarbeitet
bleibt, bis der Inhalt eines solchen TCP-Pakets durch die BGP-Task 410 des
aktiven Routingmoduls 402 als nicht unzulässig (d.h.
nicht zu einer BGP-Task-Störung
führend)
erkannt worden ist. D.h. die inaktive Routingmodul-BGP-Task 412 bearbeitet
eine bestimmte BGP-Nachricht, nachdem die aktive Routingmodul-BGP-Task 410 diese
bestimmte BGP-Nachricht bearbeitet hat.
-
Bei
manchen Ausgestaltungen des inaktiven Routingmoduls empfängt das
inaktive Routingmodul 404 keine Steueraktualisierungen
vom aktiven Routingmodul 402. So ist es theoretisch möglich, dass die
inaktive Routingmodul-Empfangswarteschlange 422 überläuft. Um
diese Möglichkeit
zu verringern, ist in solchen Ausgestaltungen die inaktive Routingmodul-Empfangswarteschlange 422 vorzugsweise
wesentlich größer als
die aktive Routingmodul-Empfangswarteschlange 418. Man
sollte jedoch verstehen, dass das inaktive Routingmodul 404 weniger
Arbeit als das aktive Routingmodul 402 leistet (z.B. sind die
Flooding-Verantwortlichkeiten stark reduziert, der TCP/IP-Stack überträgt keine
Daten, etc.). Daher sollte keine Möglichkeit eines stationären Zustandes bestehen,
in welchem die inaktive Routingmodul-Warteschlange 422 über alle
Grenzen weiterwächst.
-
Zu
beachten ist, dass das aktive Routingmodul 402 in der Lage
ist, eine hier in Verbindung mit dem inaktiven Routingmodul 404 offenbarte
Funktionalität
zu unterstützen,
und dass das inaktive Routingmodul 404 in der Lage ist,
eine hier in Verbindung mit dem aktiven Routingmodul 402 offenbarte
Funktionalität
zu unterstützen.
Folglich liefert im Falle einer Aktivitätsumschaltung gemäß der hier
gegebenen Offenbarung das aktive Routingmodul 402 (d.h.
das neu inaktivierte Routingmodul) die zuvor vom inaktiven Routingmodul 404 (d.h.
dem neu aktivierten Routingmodul) gelieferte Funktionalität, und das
inaktive Routingmodul 404 liefert eine zuvor vom aktiven Routingmodul 402 gelieferte
Funktionalität.
Z.B. liefert nach einer Aktivitätsumschaltung
das aktive Routingmodul 402 eine der Anhängig-Warteschlange 426 und
der Fertig-Warteschlange 428 des inaktiven Routingmoduls 404 zugeordnete
Funktionalität.
-
Gemäß wenigstens
einer Ausgestaltung der hier gegebenen Offenbarung halten die BGP-Tasks des
aktiven Routingmoduls 402 und des inaktiven Routingmoduls 404 keine
Sendedaten auf Netzknoten-weiser (d.h. Socket-weiser) Grundlage
in der Warteschlange. Ein Grund dafür, dass die BGP-Tasks keine
Warteschlange Netzknoten-weise führen,
ist, dass eine Zustellung von Daten in der Warteschlange der BGP-Task
nach einer Aktivitätsumschaltung
nicht gewährleistet
wäre. Ein
anderer Grund ist, dass eine Synchronisation von Listen von Routen,
die bekannt gemacht oder zurückgezogen
werden müssen,
zu intensiv wäre,
wenn BGP-Task-Sendewarteschlangen durchsucht werden müssten.
-
Es
wird hier in Betracht gezogen, dass die aktive Routingmodul-Sendewarteschlange 420 vergrößert ist,
um eine Sendewarteschlange der aktiven Routingmodul-BGP-Task weglassen
zu können. D.h.,
die Warteschlange 420 der aktiven Routingmodul-TCP-Task 406 muss
groß genug
sein, um sicherzustellen, dass Übertragungen
nach aufeinander folgenden Zeiträumen
der Verarbeitung von bekannt gemachten oder zurückgezogenen Routen weitergehen.
-
Da
die BGP-Tasks (410, 412) des aktiven und des inaktiven
Routingmoduls (402, 404) Sendedaten nicht in eine
Warteschlange stellen können, muss
eine Operation zum Senden von Daten an die aktive Routingmodul-TCP-Task 406 erfolgreich
sein. Anderenfalls müsste
die aktive Routingmodul-BGP-Task 410 solche Sendedaten
in eine Warteschlange stellen können,
was sie vorzugsweise nicht tut. Um sicherzustellen, dass die Operation
zum Senden von Daten an die aktive Routingmodul-TCP-Task 406 erfolgreich
ist, stellt die aktive Routingmodul-BGP-Task 410 zunächst sicher,
dass in der der aktiven Routingmodul-TCP-Task 406 zugeordneten Sendewarteschlange 420 genügend Platz
vorhanden ist. Bei einer Ausgestaltung wird die Sicherstellung, dass
dieser ausreichende Platz vorhanden ist, über ein Lesen in einem gemeinsam
benutzten Speicher bewerkstelligt. Zu diesem Zweck führt die
TCP-Task 406 des aktiven Routingmoduls 402 eine
Tabelle des freien Platzes in der aktiven Routingmodul-Sendewarteschlange 420.
In anderen Ausgestaltungen können
jedoch andere Techniken verwendet werden, um sicherzustellen, dass
solch ausreichender Platz vorhanden ist.
-
Mit
Bezug auf Datenprozessorprogramme gemäß einer Ausgestaltung der hier
gegebenen Offenbarung steuert ein Datenprozessorprogramm wenigstens
einen Teil der Operationen, die mit dem Synchronisieren von Protokolltasks
höherer
Ebene (z.B. BGP) und Protokolltasks niedrigerer Ebene (z.B. TCP),
die auf redundanten Routingmodulen eines Netzwerkelements laufen,
zusammenhängen.
Auf diese Weise steuert das Datenprozessorprogramm wenigstens einen
Teil der Operationen, die notwendig sind, um eine Routingmodul-Synchronisationsfunktionalität zu erleichtern,
in einer mit der hier gegebenen Offenbarung konsistenten Weise.
Der Ausdruck Datenprozessorprogramm ist hier definiert als Computersoftware,
Datenprozessoralgorithmen oder ein beliebiger anderer Typ von Anweisungscode,
der in der Lage ist, mit einem Datenprozessor zusammenhängende Operationen
zu steuern. Ein Mikroprozessor, Mikrocontroller, Mikrocomputer,
digitaler Signalprozessor, Zustandsmaschine, logische Schaltungen
und/oder eine beliebige Vorrichtung, die basierend auf Operationsanweisung
oder in vordefinierter Weise digitale Information handhabt, sind
Beispiele eines Datenprozessors.
-
Ein
Datenprozessorprogramm gemäß einer Ausgestaltung
der hier gegebenen Offenbarung ist ausführbar durch einen Datenprozessor
eines aktiven und/oder inaktiven Routingmoduls eines Netzwerkelements.
Eine Kopie des Datenprozessorprogramms kann auf jedem der Routingelemente
in einem Netzwerkelement vorhanden sein. Ferner kann jede Kopie
des Datenprozessorprogramms für
einen Datenprozessor des jeweiligen Routingmoduls in einer Speichervorrichtung
des jeweiligen Routingmoduls (z.B. RAM, ROM, virtueller Speicher,
Festplattenspeicher, etc.) oder von einem Peripheriegerät wie einer
Diskette, einer Compactdisc, einer externen Speichervorrichtung
und dgl. aus zugänglich sein.
-
Ein
von einer Vorrichtung aus durch einen Datenprozessor zugängliches
Datenprozessorprogramm ist hier definiert als ein Datenprozessorprogrammerzeugnis.
Es wird in Betracht gezogen, dass das Datenprozessorprogrammerzeugnis
mehr als ein Datenprozessorprogramm umfassen kann, das von jeweiligen
Vorrichtungen aus zugänglich
ist. Ferner wird hier in Betracht gezogen, dass jedes einzelne aus
einem Netzwerk von Datenprozessorprogrammen für einen jeweils anderen aus
einer Mehrzahl von Datenprozessoren zugänglich sein kann. Z.B. können ein
erster Datenprozessor und ein zweiter Datenprozessor (z.B. eines
Blattknotens und eines Wurzelknotens) jeweils auf ein erstes Datenprozessorprogramm
und ein zweites Datenprozessorprogramm von einer ersten Vorrichtung
bzw. einer zweiten Vorrichtung (z.B. einer ersten Speichervorrichtung
und einer zweiten Speichervorrichtung) zugreifen.
-
In
der vorhergehenden detaillierten Beschreibung wurde Bezug genommen
auf die beigefügten
Zeichnungen, die einen Teil von dieser bilden und die zur Veranschaulichung
spezieller Ausgestaltungen gezeigt werden, durch die die Erfindung
ausgeführt
werden kann. Diese Ausgestaltungen sind genau genug beschrieben
worden, um Fachleuten zu ermöglichen,
die Erfindung auszuführen,
und es versteht sich, dass andere Ausgestaltungen verwendet werden
können,
und dass logische, mechanische, chemische und elektrische Änderungen
vorgenommen werden können,
ohne den Umfang der Erfindung zu verlassen. Um Details zu vermeiden,
die von Fachleuten nicht benötigt
werden, um die Erfindung auszuführen,
ist in der Beschreibung bestimmte, Fachleuten bekannte Information
weggelassen. Die obige detaillierte Beschreibung ist daher nicht
als einschränkend
aufzufassen, und der Umfang der vorliegenden Erfindung ist ausschließlich durch
die beigefügten
Ansprüche
definiert.