DE10260640A1 - Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring - Google Patents

Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring Download PDF

Info

Publication number
DE10260640A1
DE10260640A1 DE2002160640 DE10260640A DE10260640A1 DE 10260640 A1 DE10260640 A1 DE 10260640A1 DE 2002160640 DE2002160640 DE 2002160640 DE 10260640 A DE10260640 A DE 10260640A DE 10260640 A1 DE10260640 A1 DE 10260640A1
Authority
DE
Germany
Prior art keywords
topology
network node
ring
packet
network nodes
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.)
Withdrawn
Application number
DE2002160640
Other languages
English (en)
Inventor
Stephan Brandenburg
Thomas Treyer
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 DE2002160640 priority Critical patent/DE10260640A1/de
Publication of DE10260640A1 publication Critical patent/DE10260640A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • H04L12/437Ring fault isolation or reconfiguration

Abstract

Die Erfindung betrifft ein Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring. DOLLAR A Der Ring weist mehrere Netzknoten (1-8) auf, bei dem jeder Netzknoten periodisch ein Topologiepaket (TP1, TP4) erzeugt, in das er seinen Betriebszustand und seine Identifizierungsnummer (NKIN) einträgt. Das Topologiepaket (TP1, TP4) wird von einem Netzknoten (4) zum nächsten Netzknoten (5) weitergegeben, der seine Identifizierungsnummer einträgt und es weitersendet bis das vollständige Topologiepaket wieder beim dieses Paket erzeugenden Netzknoten eintrifft. Dort wird es ausgewertet und der Ring durch Halbierung der Anzahl der eingetragenen Netzknoten derart in zwei logische Ringteile geteilt, dass von jedem Netzknoten die Datenpakete über die kleinste Anzahl dazwischenliegender Netzknoten zu ihren jeweiligen Zielnetzknoten weitergeleitet werden.

Description

  • Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring.
  • Die Erfindung betrifft ein Verfahren nach dem Oberbegriff des Anspruchs 1.
  • In paketvermittelnden Netzen werden die Netzknoten oder Netzelemente in unterschiedlichsten Weisen miteinander verbunden bzw. vermascht. Eine mögliche Topologie ist ein bidirektionaler Ring. Die Ringtopologie hat den Vorteil, dass es zwischen zwei beliebigen Netzknoten A und B im Ring immer zwei Wege gibt und somit bei einer einzelne Unterbrechung einer Verbindung bzw, eines Links die Kommunikation aufrecht erhalten werden kann.
  • Um die Kommunikation zwischen Netzknoten im Falle eines Zinkfehlers aufrecht zu erhalten, müssen die Wege der Pakete durch den Ring geändert werden, d.h. es muss auf die Ersatzroute umgeschalten werden. Dazu gibt es prinzipiell zwei Verfahren, nämlich zum einen das sogenannte Wrapping und zum anderen das sogenannte Steering. In der vorliegenden Erfindungsmeldung wird nur das Steering Verfahren betrachtet.
  • Steering bedeutet, dass die Ersatzschaltung beim Absender des Paketes vorgenommen wird. Für Netzknoten A gibt es in einem Ring zwei Wege, um ein Paket an B zu schicken: Links herum und rechts herum. Im Normalfall, wenn alle Verbindungen bzw. Links fehlerfrei sind, wird Netzknoten A das Paket auf dem kürzesten Weg zu Netzknoten B schicken. Tritt eine Störung auf diesem Weg auf, wie eine Verbindungsunterbrechung oder ein Zinkfehler, wird Netzknoten A den Weg ändern und die andere Ringrichtung wählen.
  • Um den kürzesten Pfad zu finden, muss Netzknoten A die Topologie des Ringes kennen. Um einen Verbindungsfehler irgendwo im Ring zu erkennen, muss Netzknoten A entsprechende Alarmmeldungen auswerten.
  • Im Dokument IEEE Draft P802.17/D1.0 Part 17: Resilient Packet Ring Access Method & Physical Layer Specifications wird ein Paket vermittelnder Ring beschrieben. In Chapter 10, Seite 143–154, wird die sogenannte Topology Discovery reppektive Topologie Erkennung und in Chapter 11, Seite 155–186, wird die sogenannte Protection respektive Schutzmechanismen beschrieben. Es sind die zwei Schutz- bzw. Protection-Mechanismen Wrapping und Steering angegeben. Die vorliegende Erfindung bezieht sich, wie bereits erwähnt, auf das Steering.
  • Die Topologie-Erkennung bei diesem Verfahren beruht auf einen sogenannten Handshake zweier benachbarter Netzknoten. Beim Handshake werden Protokoll-Pakete nicht nur zwischen den beiden betroffenen Netzknoten ausgetauscht, sondern sind als sogenannte Broadcasts im ganzen Ring sichtbar. Alle Netzknoten im Ring hören den Handshake mit und werden so über die Nachbarschaftsbeziehung informiert. Ein Netzknoten kann nun über zwei Methoden auf die Topologie des gesamten Ringes schließen:
    • 1. Er wertet die einzelnen Nachbarschaftsbeziehungen aus und setzt sie wie ein Puzzle zusammen.
    • 2. Er wertet die sogenannten „Time to Live – Informationen", kurz TTL Informationen, dieser Broadcast Pakete aus und schließt so auf die Reihenfolge der Netzknoten im Ring.
  • Dieses Protokoll ist relativ langsam, da es nach Änderungen der Topologie erst einschwingen muss, wie auf Seite 147 ab Zeile 27 steht: „Changes in the address of a station a given number of hops away or in the address of a neighboring station of a station a given number of hops away force, for the sake of consistency, the deletion of all entries in the data base corresponding to stations on the ringlet beyond the point of the change." Im weiteren Text wird vorgeschlagen, dass die gelöschten Adressen wieder neu aufgebaut werden müssen ("reconfirm").
  • Im Fehlerfall bedeutet dies bei einem Ring mit n Netzknoten, dass jeder Netzknoten zuerst 2x(n–1) Telegramme auswerten muss, bevor die neue Topologie des Ringes bekannt ist. In der Zwischenzeit können manche Datenpakete bzw. Rahmen respektive Frames nicht weitergeleitet bzw. geroutet werden.
  • Dieses Verfahren der IEEE ist relativ komplex und langsam.
  • Eine andere Klasse von Topologie-Protokollen, wie z.B. RIP, OSPF oder BGP-4, arbeitet nach dem Prinzip, dass jeder Netzknoten seine unmittelbaren Nachbarn lernt und von diesen Nachbarn zusätzlich noch deren gelerntes Wissen kopiert. Dieser Ansatz hat den Vorteil, dass beliebige Topologien möglich sind. Der gravierende Nachteil ist jedoch, dass sich das Wissen um die Topologie nur sehr langsam im Netz ausbreitet. Diese Protokolle sind deshalb nicht geeignet, um ein schnelles Schalten von Ersatzwegen vorzunehmen. In IEEE 802.17 Working Documents: "Alladin" proposal, presented in San Jose, Updated Nov-09-01, wird diese Möglichkeit für einen Paket vermittelnden Ring beschrieben. Da dieses Verfahren für Ersatzschaltungen zu langsam ist, wird ein zusätzlicher sogenannter Broadcast für Link Status Messages beschrieben.
  • Eine weitere Klasse von Topologie-Protokollen für einfache Ringe sind in den Dokumenten RFC 2892: The Cisco SRP MAC Layer Protocol und IEEE 802.17 Working Documents: "Gandalf" proposal, Updated Dec-10-01 beschrieben.
  • Bei diesen Verfahren fügt jeder Netzknoten in ein umlaufendes Protokoll-Paket seine Daten ein. Am Ende des Umlaufs befindet sich die gesamte Topologiedokumentation in diesem Paket. Dabei besteht der Nachteil, dass das Paket eine gewisse Anzahl von „Runden" im Ring kreisen muss, ehe es als gültiges Paket verwendet wird, d.h. das Verfahren arbeitet nicht modalfrei. Das Protokoll kann nicht zur Fehlererkennung und zur Ersatzschaltung verwendet werden. Bei Cisco wird im Störungsfall Wrapping zur Ersatzschaltung eingesetzt. Bei „Gandalf" ist ein zusätzliches Protokoll vorgesehen, welches die Ersatzschaltung durchführt.
  • Aufgabe der vorliegenden Erfindung ist daher, eine einfache Möglichkeit zur Topologie Erkennung und Weglenkung von Datenpaketen in einem paketvermittelnden Ring anzugeben.
  • Diese Aufgabe wird durch die Merkmale des Verfahrens nach Anspruch 1 gelöst.
  • Der Vorteil der Erfindung besteht darin, das eine einfache Möglichkeit zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem paketvermittelnden Ring angegeben ist.
  • Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
  • Das Verfahren ermöglicht eine ökonomische Verwendung der Übertragungskapazität des paketvermittelnden Ringes.
  • Ein weiterer wesentlicher Vorteil besteht darin, dass durch die eine Störmeldung bzw. eine Meldung eines fehlerhaften Betriebszustandes enthaltenden Topologiepakete eine einfache Ersatzschaltung im Ring möglich ist. Dabei werden ungültige Zustände innerhalb der Routing-Tabelle vermieden.
  • Weitere Vorteile der Erfindung sind bei der Beschreibung des Ausführungsbeispiel angegeben.
  • Die Erfindung wird anhand eines Ausführungsbeispieles näher erläutert.
  • Dabei zeigt:
  • 1 einen paketvermittelnden Ring,
  • 2 eine schematische Darstellung eines ersten Topologiepaketes,
  • 3 eine erste Topologietabelle,
  • 4 einem ersten Fehlerzustand des paketvermittelnden Ringes,
  • 5 eine schematische Darstellung eines zweiten Topologiepaketes,
  • 6 eine schematische Darstellung eines dritten Topologiepaketes,
  • 7 eine zweite, dritte und vierte Topologietabelle,
  • 8 eine fünfte Topologietabelle,
  • 9 eine sechste Topologietabelle,
  • 10 einen zweiten Fehlerzustand des paketvermittelnden Ringes,
  • 11 eine schematische Darstellung eines vierten Topologiepaketes,
  • 12 eine schematische Darstellung eines fünften Topologiepaketes,
  • 13 eine siebte Topologietabelle.
  • 1 zeigt einen paketvermittelnden Ring, bestehend aus 8 Netzknoten oder Netzelementen, wie beispielsweise Router, Switches, Gateways, SDH-, SONET- oder OTN-Netzelemente. Diese sind im Ring über bidirektionale Verbindungen oder Links der Reihe nach verbunden. Die Netzknoten sind fortlaufend im Uhrzeigersinn von 1 bis 8 nummeriert. Die Netzknoten weisen nicht dargestellte Ab- und Zugänge, die Tributary Ports, auf, die jeweils mit einem Ziel/Teilnehmer verbunden sind. Die Datenpakete werden von einem Absendernetzknoten über einen Teil des Ringes zu einem Zielnetzknoten übertragen werden, um dort zu einem korrespondierenden Ziel/Teilnehmer zu gelangen.
  • Beim erfindungsgemäßen Verfahren erzeugt jeder Netzknoten periodisch, beispielsweise in einem festen Sekunden- oder Minu tentakt, ein Topologiepaket, das er an einen oder beiden seiner Ausgänge abgibt. In das Topologiepaket trägt er, beispielsweise an oberster Stelle, seine Netzknoten Identifizierungsnummer und seinen Betriebs- bzw. Fehlerzustand ein. Der nächsten Netzknoten trägt ebenfalls seine Netzknoten-Identifizierungsnummer ein und gibt es an seinem Nachbar-Netzknoten weiter, bis es – sämtliche Netzknoten-Identifizierungsnummern enthaltend – beim paketerzeugenden Netzknoten eintrifft.
  • 2 zeigt eine schematische Darstellung eines Teiles des Inhalts eines Topologiepaketes. Dieses ist in Tabellenform dargestellt, bestehend aus zwei Zeilen. In der ersten Zeile sind die Bedeutungen der Felder angegeben und in der zweiten Zeile die zugehörigen Werte. Dabei bedeuten DA, Zieladresse respektive Destination Address, SA, Absenderadresse respektive Source Address, FF, Betriebszustand, NKID, Netzknoten Identifizierungsnummern und CRC, Checksumme.
  • In 2 ist beispielhaft ein Topologiepaket des Netzknoten 4 dargestellt, in welches die Absender- und Zieladresse 4, der Betriebszustand OK, was für in Ordnung steht, und Netzknoten 4 an erster Stelle eingetragen ist. Dieses Paket wurde von Netzknoten 4 im Uhrzeigersinn an Netzknoten 5 abgegeben, der seine Netzknoten Identifizierungsnummer 5 neben der Netzknoten Identifizierungsnummern von Netzknoten 4 eingetragen und wiederum an Netzknoten 6 weitergegeben hat, so dass im Topologie-Paket die Reihenfolge 4, 5, 6, 7, 8, 1, 2, 3 entsteht. Netzknoten 3 gibt das Paket an Netzknoten 4 weiter, der sein eigenes Topologiepaket beispielsweise an der obersten Netzknoten-Identifizierungsnummer oder an einer identischen Ziel- und Absenderadresse des Topologiepaketes erkennt. Netzknoten 4 wertet daraufhin das von ihm generierte Paket aus und teilt durch Halbierung der Anzahl der Netzknoten den Ring derart in zwei logische Ringteile, das Datenpakete vom Netzknoten 4 jeden Netzknoten im Ring über die kleinste Anzahl dazwischenliegender Netzknoten erreichen.
  • Die Netzknoten-Identifizierungsnummern können dazu beispielsweise in eine Topologietabelle gemäß 3 eingetragen werden, die zwei Spalten enthält. In der ersten Spalte NKID wird, beispielsweise fortlaufend, die Netzknoten-Identifizierungsnummer eingetragen und in der zweiten Spalte RI die zugehörige Ringrichtung oder Anschlussnummer am Netzknoten, wie in 3 dargestellt. In der Spalte RI sind im Beispiel die Richtungen R, für rechts oder rechte Verbindungsseite bzw. Port des Netzknoten, L, für links oder linke Verbindungsseite bzw. Port des Netzknoten, und N für nicht erreichbare Netzelemente eingetragen. In der Topologietabelle gemäß 3 ist ein Beispiel für Netzknoten 4 dargestellt. Dabei sind die Netzknoten-Identifizierungsnummern fortlaufend aufgeführt und ihnen ist jeweils eine Richtung bzw. eine Ringseite, bezogen auf den Netzknoten 4, zugeordnet. Die Netzknoten 1 bis 3 sind gemäß den Einträgen, über die rechte Verbindung und die Netzknoten 5 bis 8 über die linke Verbindung erreichbar.
  • Bei einer ungeraden Anzahl Netzknoten, gibt es einen Netzknoten, der über beide Richtungen mit einer gleichen Anzahl dazwischenliegender Netzknoten erreichbar ist. Diesem gegenüberliegenden Netzknoten kann eine Richtung frei zugeordnet werden, gemäß einem Zufallsprinzip, vorher ein fester Wert bestimmt werden, beispielsweise immer links oder rechts herum, oder nach bestimmten Kriterien eine Richtung vergeben werden. Die Zuordnung sollte so erfolgen, dass die Ringteile verkehrsmäßig etwa gleich ausgelastet sind.
  • Eine Möglichkeit besteht darin, in Abhängigkeit von der eigenen oder gegenüberliegenden Netzknoten Identifizierungsnummer die Richtung festzulegen. Beispielsweise bei ungerader eigener oder gegenüberliegender Netzknoten Identifizierungsnummer werden Datenpakete im Uhrzeigersinn bzw. links herum zum Ziel weitergeleitet, bei gerader Netzknoten Identifizierungsnummer werden Datenpakete entgegen dem Uhrzeigersinn bzw. rechts herum zum Ziel weitergeleitet oder umgekehrt.
  • Anhand der Einträge in der Topologietabelle können die Ziele jeweils über den kürzesten Weg erreicht werden. Aus der Topologietabelle gemäß 3 kann auch eine Routing-Tabelle erzeugt werden, die bspw. nur die im Netz enthaltenen Netzknoten Identifizierungsnummer und definierte Richtungen wie links, rechts und nicht erreichbar enthält.
  • 4 zeigt die gleiche Anordnung wie 1, jedoch liegt eine Störung im Ring zwischen den Netzknoten 3 und 4 vor. 5 zeigt ein Topologiepaket TP4 vom Netzknoten 4 und Figur 6 ein Topologiepaket TP3 vom Netzknoten 3, bei dem jeweils ein Fehlerzustand F neben der paketerzeugenden Netzknoten-Identifizierungsnummer 3 und 4 eingetragen ist.
  • Bei einem Störungsfall im Ring, wie einer Ringunterbrechung oder dem Ausfall eines Netzknotens, wird von den Nachbar-Netzknoten ein Topologiepaket erzeugt, in das ein fehlerhafter Betriebszustand, eine Störmeldung eingetragen bzw. ein Fehlerflag gesetzt ist. Dieses Paket wird an die Nachbar-Netzknoten weitergegeben und von jedem Netzknoten ausgewertet. Topologiepakete mit fehlerfreien Betriebszustand müssen normalerweise nicht können aber von jedem Netzknoten ausgewertet werden.
  • Aufgrund der Auswertung des eine Störmeldung enthaltenden Topologiepaketes wird der Ring unter Berücksichtigung des Fehlerzustandes in zwei neue logische Ringteile so geteilt, dass jedes Netzelement über den jeweiligen Ringteil erreichbar ist. Dies kann modalfrei erfolgen.
  • Dies soll an einem Beispiel verdeutlicht werden. In 7 ist unter A eine Topologietabelle für Netzknoten 6 dargestellt. Die Netzknoten 2-5 sind rechts erreichbar und die Netzknoten 1, 7 und 8 sind links erreichbar. Der Ring sei nun zwischen Netzknoten 3 und 4 unterbrochen. Daraufhin senden die Netzknoten 3 und 4 jeweils ein Topologiepaket mit einer Störmeldung. Bezogen auf Netzknoten 6, der als erstes das Paket von Netzknoten 4 erhält, weiß er nun, dass die Störstelle hinter Netzknoten 4 liegt und die Netzknoten 4 und 5 anhand des Paketes über seine rechte Verbindung erreichbar sind. Da Netzknoten 6 von der linken Seite noch kein Paket mit einer Störmeldung vom Netzknoten 3 erhalten hat, nimmt er unter Berücksichtigung der Ringstruktur an, dass Netzknoten 7, 8, 1, 2, und 3 über seine linke Verbindung erreichbar sind. Dies wird in 7, Topologietabelle B berücksichtigt. Dabei wird Netzknoten 2 und 3 mit L, für links, oder AL, für „angenommen links", eingetragen. Dabei werden Pakete für die Netzknoten 2 und 3 in beiden Fällen über die linke Verbindung weitergeleitet.
  • Bei Eintreffen des Topologie-Paketes vom Netzknoten 3 ist bekannt, welche Netzknoten über die linke Verbindung erreichbar sind und das AL, für „angenommen links", kann durch L für links ersetzt werden, gemäß Topologietabelle C in 7.
  • Die Zustände AL, für „angenommen links", bzw. AR, für „angenommen rechts", können verwendet werden, wenn nur ein erstes Topologiepaket mit einer Störmeldung eingetroffen ist und ein zweites aus der entgegengesetzten Richtung noch nicht angekommen ist. Wird die Topologietabelle in eine Routing-Tabelle überführt bzw. aus der Topologietabelle eine Routing-Tabelle erzeugt, so werden in der Routing-Tabelle die Zustände Al zu L und AR zu R.
  • 8 zeigt eine 3 entsprechende Topologietabelle des Netzknotens 4 bei für den Fall einer Unterbrechung zwischen den Netzknoten 3 und 4, und vor dem Empfang des Topologiepaketes mit der Störmeldung von Netzknoten 3. Aufgrund einer eigenen Störmeldung des Netzknotens 4 wird angenommen, dass die rechte Verbindung nicht mehr verwendbar ist und ein Topologiepaket gemäß 5 generiert. Die Netzknoten 5 bis 8 sind weiterhin über die linke Verbindung erreichbar, und es wird angenommen, dass die Netzknoten 1 bis 3 ebenfalls über die linke Verbindung erreichbar sind, was durch die Eintragungen L bzw. AL in der Topologietabelle wiedergegeben wird.
  • 9 zeigt eine Topologietabelle für den Netzknoten 4 nach dem Empfang des Topologiepakets mit Störmeldung von Netzknoten 3. Nun ist klargestellt, dass alle Netzknoten 1 bis 3 und 5 bis 8 nur über die linke Verbindung erreichbar sind, was durch die entsprechende Eintragung L in der Topologietabelle wiedergegeben wird.
  • 10 zeigt eine Anordnung gemäß 4 mit einer weiteren Unterbrechung zwischen den Netzknoten 1 und 2.
  • 11 und 12 zeigen je ein zugehöriges Topologiepaket TP4 und TP1, die von Netzknoten 1 bzw. 4 im Falle einer Störung entsprechend 10 erzeugt wurden.
  • In 13 ist eine Topologietabelle für Netzknoten 4 dargestellt, die durch Auswertung des Topologiepaketes TP1 erstellt wurde.
  • In diesem Fall sind die Netzknoten 2 und 3 nicht mehr erreichbar, was durch ein N für nicht erreichbar in der Topologietabelle gekennzeichnet ist. Bezogen auf Netzknoten 4 sind alle übrigen Netzknoten über die linke Verbindung erreichbar, was durch ein L für links gekennzeichnet ist.
  • In Varianten kann der Ring als SDH-, SONET-, OTN- oder anderer Übertragungsring ausgebildet sein. Dabei werden feste oder variable Transportkapazitäten durch den Ring geschalten, über welche die Datenpakete geroutet/vermittelt werden.
  • Die Datenpakete können dabei Ethernet-Pakete sein, die entweder l0Mbit/s, 100Mbit/s, 1Gbit/s, l0Gbit/s oder andere Datenraten aufweisen.
  • Die Datenpakete von den Tributary-Ports der Netzknoten mit Ethernet MAC Adressen, die Ziel und Absender enthalten, werden in Pulsrahmen des Ringes eingefügt (die gegebenenfalls wiederum in SDH-, oder ähnliche Rahmen eingepackt werden) und zunächst zu allen Netzknoten gesendet, beispielsweise mittels Broadcast-Adressen oder Broadcast-Flags der Ringpakete, die ebenso Ziel und Absender der Ring-Netzknoten, entsprechend den Netzknoten Identifizierungsnummern, enthalten.
  • Ein Netzknoten, der ein Ethernet Paket mit MAC Ziel- und Absenderadresse enthält, ordnet die MAC-Absenderadresse des Datenpakets zunächst seinem Tributary-Port zu. Er sendet das Datenpaket, da er nicht weiß, an welchem Netzknoten das Ziel angeschlossen ist, zunächst an alle Netzknoten. Dies kann durch ein Broadcast Flag oder durch duplizieren des Paketes und senden zu den beiden am weitesten entfernten Netzknoten erfolgen. Ein diese Pakete empfangender Netzknoten, der das Ziel kennt, gibt es an seinem Tributary-Port weiter. Ist das Ziel nicht bekannt und kann es keinem fremden Tributary-Port zugeordnet werden, wird das Paket ebenfalls an den eigenen Tributray-Ports abgegeben, gemäß dem Broadcast-Ethernet-Prinzip. Da der Datenverkehr meist bidirektional verläuft, lernt so jeder Netzknoten die Ethernet MAC Adressen an den jeweiligen Netzknoten und kann Datenpakete anhand der MAC-Adresse direkt zu den entsprechenden Zielnetzknoten im Ring senden.
  • Die generelle Arbeitsweise der Netzknoten ist in den folgenden Schritten zusammengefasst:
    • – Generierung: Alle Netzknoten im Ring generieren neue Topologiepakete und geben sie im Ring in Umlauf.
    • – Transit-Bearbeitung: Jeder Netzknoten gibt Topologiepakete im Ring weiter.
    • – Auswertung: Jeder Netzknoten wertet die eintreffenden Topologiepakete aus, insbesondere die mit Störmeldung.
    • – Terminierung: Jeder Netzknoten terminiert die Topologiepakete, die er selbst generiert hat.
  • Die folgende Punkte werden zur Klarstellung noch einmal näher erläutert:
    • – Jeder Netzknoten generiert Topologiepakete unabhängig von allen anderen Netzknoten. Ein einfacher Timer (z.B. alle fünf Sekunden) genügt. Eine Ausnahme ist lediglich das Auftreten eines Link-Fehlers unmittelbar an einer Ringverbindung des Netzknotens. In diesem Fall wird unabhängig vom Timer sofort ein neues Topologiepaket generiert.
    • – Die Transit-Bearbeitung von Topologiepaketen ist in Hardware, kurz HW, einfach realisierbar. Die ausführende Hardware muss lediglich ein Byte in das Topologiepaket einfügen und gegebenenfalls eine Checksumme, wie CRC, neu berechnen, ohne den bisherigen Inhalt des Topologiepaketes zu interpretieren. Dies bedeutet, dass der Transit eines Topologiepakets innerhalb kurzer Zeit in einem programmierbaren Gate Array FPGA oder ASIC durchgeführt werden kann. Für eine Store&Forward-Architektur liegt die Transitzeit unter der doppelten Rahmendauer, was z.B. bei einer Zinkbandbreite von 10 Gbit und einem Ethernet-Protokoll eine Transitzeit von unter 1 μs ergibt. Für eine Cut-Through-Architektur ergeben sich noch kürzere Transitzeiten. Auch bei Ringen mit einer hohen Netzknotenzahl ist damit die Ringumlaufzeit eines Topologiepakets und die Zeit bis zum Schalten eines Ersatzweges minimal bzw. entsprechend der Faserlaufzeit im Ring.
    • – Die Auswertung der am Netzknoten eintreffenden Topologiepakete ist unproblematisch. Jedes eintreffende Topologiepaket führt anhand einfacher Regeln zu einer neuen, korrekten Version der Topologie-Tabelle. Die Verarbeitung der Topologiepakete ist strikt modalfrei, d.h. ein Algorithmus wertet jedes Topologiepaket für sich aus, ohne sich die Historie der Pakete oder bestimmte Betriebszustände merken zu müssen. Im Gegensatz zu anderen Protokollen gibt es beim erfindungsgemäßen Verfahren bei beliebigen Schaltvorgängen im Ring (Zink defektrepariert) keine illegalen Zwischenzustände.
    • – Die Terminierung eines Topologiepaketes basiert auf zwei einfachen Regeln: Stammt das eintreffende Packet von dem lokalen Netzknoten, wird es terminiert. Ist einer der beiden Ringverbindungen eines Netzknotens gestört, wie bei einem Verbindungs- bzw. Zinkfehler, werden alle vom Ring kommenden Pakete terminiert.
    • – Die Transit-Behandlung des Topologiepaketes wird vorteilhafterweise nicht im Host-Rechner des Netzknotens, also nicht mittels Soft- oder Firmware, durchgeführt, sondern in der Transit-Hardware.
    • – Um die gesamte Topologie neu zu lernen, muss ein Netzknoten lediglich ein Topologiepaket auswerten. Nur wenn der Ring nicht geschlossen ist, müssen zwei Topologiepakete ausgewertet werden.
    • – Im Fehlerfall, bei einem Verbindungs- bzw. Zink- oder Netzknotenfehler irgendwo im Ring, reicht die Auswertung eines Topologiepaketes, um die Datenpakete bzw. Frames neu weiterzuleiten bzw. zu routen (Re-Steering). Nach der Auswertung des zweiten Topologiepaketes wird das Routen so optimiert, dass keine Datenpakete bzw. Frames zu unerreichbaren Netzknoten geschickt werden.
    • – Es gibt keine transienten Zustände, in denen die Topologietabelle bzw. Routing-Tabelle temporär ungültig ist. D.h, die Routing-Tabelle kann immer sofort bei jedem empfangenen Topologiepaket aktualisiert werden. Es sind keine sogenannten State Machine notwendig, dadurch wird eine robuste Implementierung ermöglicht.
    • – Für das Verfahren wird nur ein sogenanntes Topologiepaket verwendet, das sowohl für die Topologieerkennung, als auch für die Störmeldungen verwendet wird, wonach die Ersatzschaltungen durchgeführt werden. Es sind keine weiteren Pakete notwendig.
    • – Datenpakete von Ethernet-Schnittstellen der Tributary-Ports werden in einen Pulsrahmen des Ringes eingepackt, der Zielnetzknoten- und Absendernetzknoten- Identifika tionsnummern enthält und gegebenenfalls weitere Checksummen, und über damit über den Ring übertragen.

Claims (12)

  1. Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring mit mehreren Netzknoten, bei dem jeder Netzknoten periodisch ein Topologiepaket erzeugt, in das er seinen Betriebszustand und seine Identifizierungsnummer einträgt, dann das Topologiepaket zum nächsten Netzknoten weitergibt, der seine Identifizierungsnummer einträgt und es weitersendet bis das vollständige Topologiepaket wieder beim Paket erzeugenden Netzknoten eintrifft, dort ausgewertet wird und anhand der Anzahl der eingetragenen Netzknoten der Ring durch Halbierung dieser Anzahl derart in zwei logische Ringteile geteilt wird, dass von jedem Netzknoten die Datenpakete über die kleinste Anzahl dazwischenliegender Netzknoten zu ihren jeweiligen Zielnetzknoten weitergeleitet werden.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in jedem Paket erzeugenden Netzknoten die Netzknoten-Identifizierungsnummern des vollständigen Topologiepakets in eine Topologietabelle eingetragen werden und dass jeder Identifizierungsnummer eine Ringrichtung zugeordnet wird, die bezogen auf den Paket erzeugenden Netzknoten die Ringrichtung zum jeweiligen durch die Netzknoten-Identifizierungsnummer festgelegten Zielnetzknoten angibt, bei der eine geringere Anzahl von Netzknoten dazwischen liegt.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass bei ungerader Anzahl an Netzknoten die Ringrichtung vom Paket erzeugenden zum jeweils gegenüberliegenden Netzknoten willkürlich festgelegt wird oder in Abhängigkeit von dessen oder der eigenen Netzknoten Identifizierungsnummer ermittelt wird.
  4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass in die Topologietabelle bezüglich der Ringrichtung wenigstens die Zustände links, rechts, angenommen links, angenommen rechts und der Zustand nicht erreichbar eingetragen werden.
  5. Verfahren nach Anspruch 2, 3 oder 4, dadurch gekennzeichnet, dass aus der Topologietabelle eine Routing-Tabelle erzeugt wird mit den Einträgen links, rechts und nicht erreichbar.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von mindestens einem Netzknoten Topologiepakete in beiden Richtungen ausgesendet werden.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass beim Auftreten einer Störung im Ring von wenigstens einem störungserkennenden Netzknoten ein Topologiepaket ausgesendet wird, in dem eine Störmeldung eingetragen wird.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass ein Topologie Paket mit einer Störmeldung von jedem Netzknoten ausgewertet wird.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass jedes Netzelement den Ring derart in zwei logische Ringteile teilt, das jedes Netzelement über den verbleibenden Ringteil oder die verbleibenden Ringteile erreichbar ist.
  10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem Topologiepaket eine identische Ziel- und Absenderadresse verwendet wird.
  11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das der Ring als SDH-, SONET- oder OTN-Ring betrieben wird.
  12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mittels des Ringes Ethernet-Pakete vermittelt werden.
DE2002160640 2002-12-23 2002-12-23 Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring Withdrawn DE10260640A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2002160640 DE10260640A1 (de) 2002-12-23 2002-12-23 Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2002160640 DE10260640A1 (de) 2002-12-23 2002-12-23 Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring

Publications (1)

Publication Number Publication Date
DE10260640A1 true DE10260640A1 (de) 2004-07-15

Family

ID=32519316

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002160640 Withdrawn DE10260640A1 (de) 2002-12-23 2002-12-23 Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring

Country Status (1)

Country Link
DE (1) DE10260640A1 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006039865A1 (fr) 2004-10-12 2006-04-20 Huawei Technologies Co., Ltd. Procede permettant de mettre en oeuvre une decouverte automatique de structure de topologie dans le reseau boucle mpls
WO2007093485A1 (de) * 2006-02-15 2007-08-23 Siemens Aktiengesellschaft Verfahren zur ermittlung von übertragungswegen und netzknoten für ein daten-pakete übertragendes kommunikationsnetz
EP2124392A1 (de) * 2008-05-20 2009-11-25 Hangzhou H3C Technologies Co., Ltd. Ringnetzwerk-Routingverfahren und Ringnetzwerkknoten
US7840713B2 (en) 2006-10-02 2010-11-23 Robert Bosch Gmbh Method for operating a field bus network system having a ring topology and a corresponding field bus network system
EP2983342A3 (de) * 2014-07-30 2016-03-02 Rockwell Automation Technologies, Inc. Internetprotokolladressierung von industriellen steuerungsvorrichtungen mit einer netz-ringtopologie
WO2020020932A1 (en) 2018-07-25 2020-01-30 Continental Automotive Gmbh Topology discovery in an automotive ethernet network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SUWALA,George: Thougts on RPR Protection and Topo- logy Discovery. Presentation at IEEE 802.17, Pre- sentation Number 802-17-01-00014, Portland, Juli 2001
SUWALA,George: Thougts on RPR Protection and Topo-logy Discovery. Presentation at IEEE 802.17, Pre- sentation Number 802-17-01-00014, Portland, Juli 2001 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006039865A1 (fr) 2004-10-12 2006-04-20 Huawei Technologies Co., Ltd. Procede permettant de mettre en oeuvre une decouverte automatique de structure de topologie dans le reseau boucle mpls
EP1802048A1 (de) * 2004-10-12 2007-06-27 Huawei Technologies Co., Ltd. Ein verfahren zur bereitstellung der automatischen erkennung der topologiestruktur des mpls ringnetzwerks
EP1802048A4 (de) * 2004-10-12 2007-10-10 Huawei Tech Co Ltd Ein verfahren zur bereitstellung der automatischen erkennung der topologiestruktur des mpls ringnetzwerks
US7697461B2 (en) 2004-10-12 2010-04-13 Hua Wei Technologies Co., Ltd. Method and node for discovering topology structure in multiprotocol label switching ring network
WO2007093485A1 (de) * 2006-02-15 2007-08-23 Siemens Aktiengesellschaft Verfahren zur ermittlung von übertragungswegen und netzknoten für ein daten-pakete übertragendes kommunikationsnetz
US7840713B2 (en) 2006-10-02 2010-11-23 Robert Bosch Gmbh Method for operating a field bus network system having a ring topology and a corresponding field bus network system
EP2124392A1 (de) * 2008-05-20 2009-11-25 Hangzhou H3C Technologies Co., Ltd. Ringnetzwerk-Routingverfahren und Ringnetzwerkknoten
US8004967B2 (en) 2008-05-20 2011-08-23 Hangzhou H3C Technologies Co., Ltd. Ring network routing method and ring network node
EP2983342A3 (de) * 2014-07-30 2016-03-02 Rockwell Automation Technologies, Inc. Internetprotokolladressierung von industriellen steuerungsvorrichtungen mit einer netz-ringtopologie
US9413552B2 (en) 2014-07-30 2016-08-09 Rockwell Automation Technologies, Inc. Internet protocol addressing of devices employing the network ring topology
WO2020020932A1 (en) 2018-07-25 2020-01-30 Continental Automotive Gmbh Topology discovery in an automotive ethernet network
US11316604B2 (en) 2018-07-25 2022-04-26 Continental Automotive Gmbh Topology discovery in an automotive ethernet network

Similar Documents

Publication Publication Date Title
EP2676409B1 (de) Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze
EP1584161A1 (de) Verfahren und anordnung zum routing von datenpaketen in einem paketvermittelnden datennetz
EP2127329B1 (de) Filterung von redundanten frames in einem netzwerkknoten
EP1532771A1 (de) Testverfahren f r nachrichtenpfade in kommunikationsnetzen s owie netzelement
DE60133175T2 (de) Kommunikationsnetz
EP1842343A1 (de) Verfahren zur bestimmung der weiterleitungsrichtung von ethernet-frames
WO2004051957A1 (de) Verfahren zur umleitung von datenpaketen bei lokal erkannten linkausfällen
EP2775677B1 (de) Verfahren zur Übertragung von Datenpaketen in einem Datennetz aus einer Vielzahl von Netzknoten
WO2001058114A1 (de) Netzwerk mit redumdanz-eigenschaften sowie netzwerkteilnehmer, insbesondere feldgerät, für ein derartiges netzwerk
DE102018129813A1 (de) Datenübertragungsverfahren und Automatisierungskommunikationsnetzwerk
DE10260640A1 (de) Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring
DE102019131823B4 (de) Automatisierungsnetzwerk und Verfahren zur Datenübertragung in einem Automatisierungsnetzwerk
EP1894363B1 (de) Verfahren und unabhängiges kommunikationsteilnetz zum ermitteln labelvermittelter routen in einem solchen kommunikationsteilnetz
DE10334104A1 (de) Verfahren und Netzknoten zur Meldung mindestens eines ausgefallenen Verbindungsweges innerhalb eines Kommunikationsnetzes
DE10337465B4 (de) Verfahren zum Routing von Datenpaketen in einem mehrere Netzknoten aufweisenden paketvermittelnden Kommunikationsnetz
DE60027423T2 (de) Kommunikationseinrichtungen
DE10308614A1 (de) Verfahren und Anordnung zum Routing von Datenpaketen in einem paketvermittelnden Datennetz
EP1627505B1 (de) Netzknoten eines paketvermittelnden kommunikationsnetzes und verfahren zur verkehrsverteilung von datenverkehr in einem paketvermittelnden kommunikationsnetz
DE102008017192A1 (de) Verfahren zum Aufbau eines Netzwerks
DE102006036565A1 (de) Verfahren zur paketvermittelten Datenübertragung in einem Kommunikationsnetz
DE10308954A1 (de) Übertragung von Daten in einem schaltbaren Datennetz
WO2008138714A1 (de) Paketvermitteltes kommunikationsnetzwerk und verfahren zum rekonfigurieren des kommunikationsnetzwerks
DE102022206121A1 (de) Deadlock-freies lokales umleiten zur behandlung mehrerer lokaler verbindungsausfälle in hierarchischen netztopologien
WO2001001640A1 (de) Verfahren zum leitwegaufbau für ein kommunikationsnetz
DE102004028815A1 (de) Verfahren zur Ressourcen-Reservierung für ein Inter-Domain-Routing mit Dienstgütemerkmalen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

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

8130 Withdrawal