DE102007015539B4 - Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks - Google Patents

Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks Download PDF

Info

Publication number
DE102007015539B4
DE102007015539B4 DE102007015539A DE102007015539A DE102007015539B4 DE 102007015539 B4 DE102007015539 B4 DE 102007015539B4 DE 102007015539 A DE102007015539 A DE 102007015539A DE 102007015539 A DE102007015539 A DE 102007015539A DE 102007015539 B4 DE102007015539 B4 DE 102007015539B4
Authority
DE
Germany
Prior art keywords
bridge
slave
master
data link
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE102007015539A
Other languages
English (en)
Other versions
DE102007015539A1 (de
Inventor
Vivek Kulkarni
Martin Nathansen
Elie Sfeir
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.)
Siemens AG
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 DE102007015539A priority Critical patent/DE102007015539B4/de
Priority to CA002682425A priority patent/CA2682425A1/en
Priority to EP08717849A priority patent/EP2130329A1/de
Priority to CN2008800111666A priority patent/CN101652963B/zh
Priority to PCT/EP2008/053108 priority patent/WO2008119649A1/de
Priority to US12/593,972 priority patent/US8284658B2/en
Publication of DE102007015539A1 publication Critical patent/DE102007015539A1/de
Application granted granted Critical
Publication of DE102007015539B4 publication Critical patent/DE102007015539B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • H04L12/4625Single bridge functionality, e.g. connection of two networks over a single bridge
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/48Routing tree calculation

Abstract

Verfahren zum Rekonfigurieren eines paketvermittelten Kommunikationsnetzwerks (1) mit einem ein erstes Netzwerkprotokoll einsetzenden ersten Netzwerk (2) und einem ein von dem ersten Netzwerkprotokoll verschiedenes zweites Netzwerkprotokoll einsetzenden zweiten Netzwerk (3), in welchem die beiden Netzwerke durch wenigstens drei redundante Datenlinks (14, 15, 16) miteinander verbunden sind, von denen jeweils nur einer zum Nutzdatenaustausch aktiviert ist, wobei ein Master-Datenlink (14) voreingestellt aktiviert ist und wenigstens zwei Slave-Datenlinks (15, 16) voreingestellt inaktiviert sind, bei welchem nach Erfassen eines Ausfalls des Master-Datenlinks (14) oder eines Ausfalls eines aktivierten Slave-Datenlinks (15, 16) durch eine mit dem Master-Datenlink (14) verbundene Master-Brücke (8) des zweiten Netzwerks (3) die folgenden Schritte ausgeführt werden: – Generieren eines ersten Datenpakets (N1) durch die Master-Brücke (8) und Übertragen des ersten Datenpakets (N1) an eine mit einem Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks, wobei die Slave-Brücke gemäß einer vorgebbaren Auswahlregel von der Master-Brücke gewählt wird; – Empfangen und Verarbeiten...

Description

  • Die Erfindung liegt auf dem technischen Gebiet der paketvermittelten Kommunikationsnetzwerke und betrifft ein Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks, in dem LANs, die verschiedene Netzwerkprotokolle einsetzen, miteinander verbunden sind.
  • Paketvermittelte Ethernet-Netzwerke (LAN = Local Area Network) werden sowohl im industriellen Umfeld als auch in Büroumgebung eingesetzt, wobei die hierbei an die Netzwerke gestellten Anforderungen sehr verschieden sind. Im Unterschied zur Büroumgebung müssen LANs im industriellen Alltag unter extremen Bedingungen, wie elektromagnetischen Störfeldern, hohen Betriebstemperaturen und mechanischen Beanspruchungen zuverlässig arbeiten. Da der Ausfall einer Produktionsanlage und die damit verbundenen Stillstandszeiten in der Regel mit hohen Kosten verbunden sind, kommt hinzu, dass in der industriellen Anwendung die Anforderungen an die Ausfallsicherheit höher sind als in Büroumgebung.
  • Für industrielle LANs werden aus diesem Grund robuste Komponenten eingesetzt, die schnelle Redundanzmechanismen ermöglichen, um so die Kosten im Fehlerfall möglichst gering zu halten. Zudem wird meist eine Ringtopologie für das Netzwerk gewählt, da diese bei einem Ausfall eines Datenlinks oder einer Brücke eine schnelle Rekonfigurationszeit von weniger als 500 ms ermöglicht. Als Netzwerkprotokolle werden für industrielle LANs gewöhnlich auf dem Ethernet-Standard basierende Standard- oder proprietäre Netzwerkprotokolle eingesetzt.
  • Demgegenüber sind LANs in Büroumgebung meist in Stern- oder Maschentopologie aufgebaut und setzen als Netzwerkprotokoll heutzutage in der Regel RSTP (RSTP = Rapid Spanning Tree Protocol) gemäß IEEE-Norm 802.1w ein.
  • In der praktischen Anwendung werden ringförmige Industrie-LANs mit maschenförmigen Office-LANs über Datenlinks miteinander verbunden. Um die Ausfallsicherheit derart verbundener Netzwerke zu erhöhen, ist es bekannt, zwei redundante Datenlinks zwischen den beiden Netzwerken einzurichten, von denen lediglich ein erster redundanter Datenlink zum Datenaustausch zwischen den beiden Netzwerken aktiviert ist, während der zweite redundante Datenlink blockiert ist und als Backup-Datenlink lediglich im Versagensfall anstelle des aktivierten ersten Datenlinks aktiviert wird. Nachteilig hierbei ist die Tatsache, dass der Umschaltvorgang zur Aktivierung des blockierten zweiten Datenlinks vergleichsweise viel Zeit in Anspruch nimmt und bei Einsatz der standardisierten Routinen von RSTP im Office-LAN ca. 30 Sekunden dauert.
  • Aus diesem Grund wäre es wünschenswert über ein Verfahren zur Rekonfiguration eines zwei LANs verbindenden Kommunikationsnetzwerks zu verfügen, das gegenüber den herkömmlichen Verfahren eine schnellere Rekonfiguration bei Ausfall eines die beiden LANs verbindenden Datenlinks ermöglicht.
  • Ein Dokument DE 10 2005 017 021 A1 offenbart ein Verfahren und eine Vorrichtung zur Kommunikation zwischen Netzwerkknoten, bei denen die Knoten untereinander in einem Verbindungszustandsprotokoll kommunizieren.
  • Eine Publikation einer US Patentanmeldung US 2006/0047851 A1 beschreibt ein Computernetzwerk mit einer Punkt-zu-Punkt Pseudodraht Redundanz.
  • Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zum Rekonfigurieren eines paketvermittelten Kommunikationsnetzwerks mit den Merkmalen von Patentanspruch 1 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind durch die Merkmale der Unteransprüche angegeben.
  • Zur Lösung der Aufgabe ist erfindungsgemäß ein Verfahren zum Rekonfigurieren eines paketvermittelten Kommunikationsnetzwerks gezeigt, welches ein (durch Brücken geswitchtes) erstes Netzwerk und ein (durch Brücken geswitchtes) zweites Netzwerk umfasst, die über wenigstens drei redundante Datenlinks miteinander verbunden sind, von denen jeweils nur einer für den Nutzdatenaustausch aktiviert ist. Hier und im Weiteren werden als ”redundante Datenlinks” lediglich die die beiden Netzwerke des Kommunikationsnetzwerks verbindenden Datenlinks bezeichnet. Die Netzknoten des Kommunikationsnetzwerks werden hier als ”Brücken” bezeichnet. Gleichwohl kann es sich im Sinne der Erfindung auch um Schalter (Switches = Multiport-Brücken) oder andere zur Vermittlung geeignete Netzknoten handeln.
  • Bei den wenigstens drei redundanten Datenlinks handelt es sich um einen voreinstellbar aktivierbaren bzw. aktivierten und für den Nutzdatenaustausch eingesetzten Master-Datenlink und um wenigstens zwei voreinstellbar inaktivierbare bzw. inaktivierte Slave-Datenlinks, die bei Ausfall des Master-Datenlinks für den Nutzdatenaustausch eingesetzt werden können.
  • Die redundanten Datenlinks verbinden jeweils eine Brücke des ersten Netzwerks und eine Brücke des zweiten Netzwerks datentechnisch miteinander. Jede Brücke des zweiten Netzwerks kann hierbei jeweils mit einer separaten Brücke des ersten Netzwerks verbunden sein. Gleichermaßen ist es möglich, dass mehrere Brücken des zweiten Netzwerks mit verschiedenen Ports einer selben Brücke des ersten Netzwerks verbunden sind.
  • Die mit dem Master-Datenlink verbundene Brücke des zweiten Netzwerks wird hier und im Weiteren als Master-Brücke bezeichnet. Die jeweils mit einem Slave-Datenlink verbundenen Brücken des zweiten Netzwerks werden hier und im Weiteren als Slave-Brücken bezeichnet. Master- und Slave-Brücken des zweiten Netzwerks können jeweils individuelle Pfadkosten zugewiesen sein, wobei der Master-Brücke die niedrigsten Pfadkosten aller mit einem redundanten Datenlink des zweiten Netzwerks verbundenen Brücken zugewiesen sind. Die den Master- und Slave-Brücken des zweiten Netzwerks zugewiesenen Pfadkosten können in der Master-Brücke in einer entsprechenden Datenspeichereinrichtung abgelegt sein. Die den Master- und Slave-Brücken des zweiten Netzwerks zugewiesenen Pfadkosten können insbesondere mittels Signale von den Slave-Brücken an die Master-Brücke insbesondere auf Basis des zweiten Netzwerkprotokolls übertragen werden.
  • Das erste Netzwerk des Kommunikationsnetzwerks kann insbesondere als Office-LAN in einer Büroumgebung installiert sein. Für das erste Netzwerk ist ein erstes Netzwerkprotokoll für den Datenaustausch eingerichtet. Als erstes Netzwerkprotokoll wird im ersten Netzwerk vorzugsweise RSTP gemäß IEEE-Norm 802.1w eingesetzt, welches eine logische Topologie in Form eines Spannbaums auf der physischen Topologie des ersten Netzwerks ausbildet. Das erste Netzwerk weist vorzugsweise eine vermaschte oder sternförmige physische Topologie auf.
  • Das zweite Netzwerk des Kommunikationsnetzwerks kann insbesondere als Industrie-LAN in einer industriellen Umgebung installiert sein und setzt für den Datenaustausch ein insbesondere auf dem Ethernet-Standard basierendes zweites Netzwerkprotokoll ein, welches ein Standard- oder proprietäres Netzwerkprotokoll sein kann. Das Netzwerkprotokoll des zweiten Netzwerks ist von dem ersten Netzwerkprotokoll, insbesondere RSTP, verschieden. Das zweite Netzwerk weist vorzugsweise eine ringförmige Topologie auf.
  • Das erfindungsgemäße Verfahren zur Rekonfiguration des Kommunikationsnetzwerks umfasst die folgenden Schritte:
    Erfassen eines Ausfalls des (voreingestellt) aktivierten Master-Datenlinks durch die mit dem Masten-Datenlink verbundene Master-Brücke des zweiten Netzwerks. Der Ausfall des Master-Datenlinks kann beispielsweise durch einen fehlenden Empfang eines von der mit dem Master-Datenlink verbundenen Brücke des ersten Netzwerks gesendeten Signals durch die Master-Brücke erfasst werden (”Loss-of-Signal”). Die Master-Brücke ist zu diesem Zweck mit einer Einrichtung zur Erfassung eines Signalausfalls (Hardware-Detektor) des Datenlinks versehen. Hierdurch kann insbesondere ein so genannter Hardware-Alarm der Master-Brücke ausgelöst werden.
  • Nach Erfassen des Ausfalls des Master-Datenlinks durch die Master-Brücke: Generieren eines ersten Datenpakets (N1) durch die Master-Brücke und übertragen des ersten Datenpakets (N1) an eine mit einem Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks. Die Master-Brücke wählt die Slave-Brücke des zweiten Netzwerks zur Übertragung des ersten Datenpakets gemäß einer vorgebbaren Auswahlregel aus. Vorteilhaft wird das erste Datenpaket (N1) mittels des zweiten Netzwerkprotokolls von der Master-Brücke des zweiten Netzwerks an die Slave-Brücke des zweiten Netzwerks übertragen.
  • Nach Aussenden des ersten Datenpakets durch die Master-Brücke: Empfangen und Verarbeiten des ersten Datenpakets durch die Slave-Brücke, wobei das erste Datenpaket logische Informationen enthält, durch welche die wenigstens teilweise Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf einem mit dem Slave-Datenlink verbundenen Port der Slave-Brücke ausgelöst wird.
  • Nach Aktivierung des ersten Netzwerkprotokolls für den mit dem Slave-Datenlink verbundenen Port der Slave-Brücke: Aktivierung des Slave-Datenlinks durch das auf dem Port der Slave-Brücke ausgeführte erste Netwerkprotokoll. Eine Aktivierung des Slave-Datenlinks erfolgt vorzugsweise durch Ausführen eines in RSTP festgelegten Handshake-Mechanismus zwischen dem RSTP-Port der mit dem inaktivierten Slave-Datenlink verbundenen Slave-Brücke des zweiten Netzwerks und einer mit dem inaktivierten Slave-Datenlink verbundenen Brücke des ersten Netzwerks. Eine Aktivierung des inaktivierten Slave-Datenlinks erfolgt hierbei mittels in RSTP standardisierter Routinen.
  • Durch das erfindungsgemäße Verfahren kann in vorteilhafter Weise eine schnelle Rekonfiguration der logischen Topologie bei Ausfall eines die beiden LANs verbindenden Datenlinks (Master-Datenlink) erreicht werden.
  • Bei einem Ausfall eines nach Ausfall des Master-Datenlinks aktivierten Slave-Datenlinks umfasst das erfindungsgemäße Verfahren vorteilhaft die weiteren Schritte:
    Erfassen des Ausfalls des aktivierten Slave-Datenlinks durch eine mit dem Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks. Der Ausfall des aktivierten Slave-Datenlinks kann beispielsweise auf Basis eines fehlenden Empfangs eines von der mit dem Slave-Datenlink verbundenen Brücke des ersten Netzwerks gesendeten Signals durch die Slave-Brücke des zweiten Netzwerks erfasst werden. Die Slave-Brücke ist zu diesem Zweck mit einer Einrichtung zur Erfassung eines fehlenden Signalempfangs (Hardware-Detektor) ausgerüstet. Hierdurch kann insbesondere ein Hardware-Alarm der Slave-Brücke ausgelöst werden.
  • Nach Erfassen des Ausfalls des Slave-Datenlinks durch die Slave-Brücke: Generieren eines zweiten Datenpakets (N2) durch die Slave-Brücke und Übertragen des zweiten Datenpakets (N2) an die Master-Brücke. Vorteilhaft erfolgt eine Übertragung des zweiten Datenpakets von der Slave-Brücke des zweiten Netzwerks zur Master-Brücke des zweiten Netzwerks mittels des zweiten Netzwerkprotokolls.
  • Nach Aussenden des zweiten Datenpakets durch die Slave-Brücke: Empfangen und Verarbeiten des zweiten Datenpakets (N2) durch die Master-Brücke, wobei das zweite Datenpaket logische Informationen enthält, durch welche die Master-Brücke über den Ausfall des Slave-Datenlinks informiert wird.
  • Nach Erfassen des Ausfalls des Slave-Datenlinks durch die Master-Brücke werden vorzugsweise die folgenden Schritte durchgeführt:
    Erneutes Generieren eines ersten Datenpakets (N1) durch die Master-Brücke und Übertragen des ersten Datenpakets (N1) an eine mit einem (nicht ausgefallenen) Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks. Die Master-Brücke wählt hierbei die Slave-Brücke des zweiten Netzwerks zur Übertragung des ersten Datenpakets gemäß der vorgebbaren Auswahlregel aus. Vorteilhaft wird das erste Datenpaket (N1) mittels des zweiten Netzwerkprotokolls von der Master-Brücke des zweiten Netzwerks an die Slave-Brücke des zweiten Netzwerks übertragen.
  • Empfangen und Verarbeiten des ersten Datenpakets durch die gewählte Slave-Brücke, wobei das erste Datenpaket logische Informationen enthält, durch welche die wenigstens teilweise Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf einem mit dem Slave-Datenlink verbundenen Port der Slave-Brücke ausgelöst wird.
  • Nach Aktivierung des ersten Netzwerkprotokolls auf dem mit dem Slave-Datenlink verbundenen Port der Slave-Brücke: Aktivierung des Slave-Datenlinks durch das auf dem Port der Slave-Brücke ausgeführte erste Netwerkprotokoll. Eine Aktivierung des Slave-Datenlinks erfolgt vorzugsweise durch Ausführen eines in RSTP festgelegten Handshake-Mechanismus zwischen dem RSTP-Port der mit dem inaktivierten Slave-Datenlink verbundenen Slave-Brücke des zweiten Netzwerks und einer mit dem inaktivierten Slave-Datenlink verbundenen Brücke des ersten Netzwerks. Eine Aktivierung des inaktivierten Slave-Datenlinks erfolgt hierbei mittels in RSTP standardisierter Routinen.
  • Das Verfahren zur Aktivierung eines weiteren inaktivierten Slave-Datenlinks bei Ausfall eines nach Ausfall des Master-Datenlinks aktivierten Slave-Datenlinks kann für alle Slave-Datenlinks des Kommunikationsnetzwerks wiederholt werden.
  • Durch obiges Verfahren kann in vorteilhafter Weise eine schnelle Rekonfiguration der logischen Topologie bei Ausfall eines die beiden LANs verbindenden Datenlinks (Slave-Datenlink) erreicht werden.
  • In besonders vorteilhafter Weise erfolgt eine Auswahl der Slave-Brücken zur Aktivierung der mit den Slave-Brücken verbundenen Slave-Datenlinks gemäß den Slave-Brücken jeweils zugewiesenen Pfadkosten. Zu diesem Zweck sind der Master-Brücke und den Slave-Brücken des zweiten Netzwerks jeweils Pfadkosten, insbesondere RSTP-Pfadkosten, beispielsweise durch das Netzwerkprotokoll zugewiesen. Besonders vorteilhaft sind der Master-Brücke hierbei die niedrigsten Pfadkosten zugewiesen.
  • Nach Ausfall des Master-Datenlinks wählt die Master-Brücke zur Aktivierung eines Slave-Datenlinks vorteilhaft jene Slave-Brücke, der in Bezug auf die Master-Brücke die nächstniedrigen Pfadkosten zugewiesen sind. Bei einem Ausfall eines aktivierten Slave-Datenlinks wählt die Master-Brücke vorteilhaft jene Slave-Brücke die bezüglich der Slave-Brücke des ausgefalllenen Slave-Datenlinks die nächstniedrigen Pfadkosten aufweist. Auf diese Weise kann sichergestellt werden, dass die Datenverbindung zwischen den beiden Netzwerken stets die niedrigst möglichen Pfadkosten hat.
  • Bei einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens umfasst dieses die folgenden weiteren Schritte:
    Erfassen der Wiederherstellung des ausgefallenen Master-Datenlinks durch die Master-Brücke des zweiten Netzwerks. Die Erfassung erfolgt beispielsweise durch ein wiedereinsetzendes Empfangen von Signalen, wie RSTP-Konfigurationsrahmen, durch die Master-Brücke des zweiten Netzwerks.
  • Nach Erfassen der Wiederherstellung des Master-Datenlinks durch die Master-Brücke: Generieren eines dritten Datenpakets (N3) durch die Master-Brücke und Übertragen des dritten Datenpakets an die Slave-Brücke des aktivierten Slave-Datenlinks. Vorteilhaft wird das dritte Datenpaket an alle Slave-Brücken übertragen. Hierdurch werden die Slave-Brücken der aktivierten und inaktivierten Slave-Datenlinks über die Wiederherstellung des Master-Datenlinks informiert.
  • Nach Aussenden des dritten Datenpakets: Empfangen und Verarbeiten des dritten Datenpakets durch die Slave-Brücke(n), wobei das dritte Datenpaket logische Informationen enthält, durch welche eine Beendigung der Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf der Slave-Brücke oder eine Beendigung des Aussendens von RSTP-Konfigurationsrahmen durch die Slave-Brücke bewirkt wird.
  • Anschließend: Aktivierung des Master-Datenlinks und Inaktivierung des aktivierten Slave-Datenlinks.
  • Hierdurch kann in vorteilhafter Weise eine schnelle Rekonfiguration der logischen Topologie bei Wiederherstellung des Master-Datenlinks erreicht werden.
  • Bei einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens werden zur Aktivierung des wiederhergestellten Master-Datenlinks und zur Inaktivierung des zweiten Slave-Datenlinks nach Erfassen der Wiederherstellung des Master-Datenlinks durch die Master-Brücke die folgenden Schritte durchgeführt:
    Wenigstens teilweise Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf einem mit dem Master-Datenlink verbundenen Port der Master-Brücke.
  • Vorzugsweise erfolgt die Aktivierung des Master-Datenlinks durch Ausführen eines in RSTP implementierten Handshake-Mechanismus zwischen den mit dem Master-Datenlink direkt verbundenen Brücken des ersten und zweiten Netzwerks. Zudem erfolgt ein Weiterleiten eines während des Handshake-Mechanismus zur Aktivierung des Master-Datenlinks erzeugten RSTP-Konfigurationsrahmens durch die Master-Brücke an die mit dem aktivierten Slave-Datenlink verbundene Brücke des ersten Netzwerks, wodurch der aktivierte Slave-Datenlink inaktiviert wird.
  • Beendigung der Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf dem mit dem Master-Datenlink verbundenen Port der Master-Brücke.
  • Hierdurch kann in vorteilhafter Weise eine besonders schnelle Rekonfiguration der logischen Topologie bei Wiederherstellung des Master-Datenlinks insbesondere unter Nutzung von in RSTP implementierter Routinen erreicht werden.
  • Die Erfindung erstreckt sich ferner auf ein wie oben beschriebenes paketvermitteltes Kommunikationsnetzwerk mit einem ein erstes Netzwerkprotokoll einsetzenden ersten Netzwerk und einem ein von dem ersten Netzwerkprotokoll verschiedenes zweites Netzwerkprotokoll einsetzenden zweiten Netzwerk, in welchem die beiden Netzwerke durch wenigstens drei redundante Datenlinks miteinander verbunden sind, von denen jeweils nur einer zum Nutzdatenaustausch aktiviert ist, wobei ein Master-Datenlink voreingestellt aktiviert ist und wenigstens zwei Slave-Datenlinks voreingestellt inaktiviert sind. In dem Kommunikationsnetzwerk sind die Brücken, insbesondere die mit einem Slave-Datenlink verbundenen Brücken, jeweils so eingerichtet, dass ein wie oben beschriebenes Verfahren ausführbar ist.
  • Des Weiteren erstreckt sich die Erfindung auf eine Master-Brücke eines wie oben beschriebenen paketvermittelten Kommunikationsnetzwerks. Darüber hinaus erstreckt sich die Erfindung auf eine Slave-Brücke eines wie oben beschriebenen paketvermittelten Kommunikationsnetzwerks.
  • Die Erfindung wird nun anhand eines Ausführungsbeispiels näher erläutert, wobei Bezug auf die beigefügten Zeichnungen genommen wird. Es zeigen:
  • 1A–1D schematische Darstellungen zur Veranschaulichung eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens zur Rekonfiguration eines Kommunikationsnetzwerks.
  • In den 1A1D ist in schematischer Weise ein Ausführungsbeispiel des erfindungsgemäßen Kommunikationsnetzwerks gezeigt. Das insgesamt mit der Bezugszahl 1 bezeichnete Kommunikationsnetzwerk umfasst ein in einer Büroumgebung installiertes, maschenförmiges, durch Brücken geswitchtes Office-LAN 2 und ein in einer industriellen Umgebung installiertes, ringförmiges, durch Brücken geswitchtes Industrie-LAN 3.
  • Die physische Topologie des Office-LAN 2 umfasst vier Brücken 47, die über jeweilige Punkt-zu-Punkt Verbindungsleitungen (Datenlinks) in maschiger Form miteinander vernetzt sind. In den Figuren sind die Datenlinks mittels durchgezogener Linien dargestellt und ansonsten nicht näher bezeichnet.
  • In dem Office-LAN 2 wird das gemäß IEEE-Norm 802.1w standardisierte Netzwerkprotokoll RSTP ausgeführt. Mittels des in dem Office-LAN 2 eingesetzten Netzwerkprotokolls RSTP ist auf der durch die Brücken und Datenlinks vorgegebenen physischen Topologie des Office-LAN 2 eine logische Topologie in Form eines Spannbaums ausgebildet, welche ausschließlich für den Austausch von Nutzdatenpaketen eingesetzt wird. In den Figuren ist der Spannbaum nicht näher gekennzeichnet.
  • Das Netzwerkprotokoll RSTP weist allen RSTP-Brücken und RSTP-Ports des Office-LAN 2 eindeutige Kennungen (IDs) und Pfadkosten zu. In RSTP umfassen die Brücken die logische Topologie des Netzwerks mittels der durch sie hindurchgehenden Datenpakete (Datenrahmen) selbsttätig, indem sie die Schicht-2-Adressen des Netzwerks (MAC-Adressen, MAC = Medium Access Control) der Brücken nutzen.
  • In RSTP können die Ports der Brücken verschiedene Zustände annehmen, insbesondere einen Zustand ”Blocking”, in dem nur Konfigurationsrahmen, sogenannte BPDUs (BPDU = Bridge Protocol Data Unit), von den Brücken akzeptiert werden, einen Zustand ”Listening”, während dem die aktive logische Topologie in Form eines Spannbaums gebildet wird, einen Zustand ”Learning”, während dessen eine Bridging-Tabelle aus den gelesenen MAC-Adressen zusammengestellt wird, einen Zustand ”Forwarding”, in dem die Ports Nutzdaten weiterleiten, und einen Zustand ”Disabled”, in dem Ports weder Nutzdaten noch BPDUs empfangen oder weiterleiten. Mit Hilfe der in den BPDUs enthaltenen Informationen können die Brücken die Zustände ihrer Ports ändern.
  • Jeder Konfigurationsrahmen (BPDU) enthält eine Reihe Felder, wie ein Flagfeld zum Anzeigen oder Bestätigen einer Topologieänderung, ein Rootbrücken-ID-Feld zur Identifizierung der Rootbrücke mit Angabe von Priorität und ID, ein Pfadkostenfeld zur Angabe der Pfadkosten der die BPDU sendenden Rootbrücke, ein Meldungsalterfeld (MessAge) zur Angabe des Zeitraums seit Aussenden der BPDU, ein MaxAge-Feld zur Angabe einer Zeitspanne nach deren Ablauf die Meldung gelöscht werden soll, ein Hello-Zeit-Feld zur Angabe der Zeitspanne zwischen regelmäßigen Konfigurationsmeldungen (Hello-Signale) der Rootbrücke, und ein Vorwärtsverzögerungsfeld, das die Wartezeit nach einer Änderung der Topologie angibt.
  • Um eine schleifenfreie logische Topologie zu bilden, werden in RSTP vier Kriterien zur Bestimmung der höchsten Prioritäten der Brücken beziehungsweise deren Ports verwendet. Dies sind: die kleinste Rootbrücken-ID, die geringsten Pfadkosten zur Rootbrücke, die kleinste Sendebrücken-ID und die kleinste Port-ID.
  • Um eine Rootbrücke zu ermitteln, gehen in RSTP alle Ports der Brücken nach der Initialisierung (beispielsweise nach einem Neustart des Netzwerks) zunächst in den Zustand ”Blocking”, wobei jede Brücke annimmt, dass sie selbst eine Rootbrücke ist und eine entsprechende BPDU mit ihrer eigenen ID als Rootbrücken-ID an die anderen Brücken sendet. Anschließend wird die Brücke mit der niedrigsten Rootbrücken-ID zur Rootbrücke gewählt. Bei identischer Rootbrücken-ID wird als ergänzendes Kriterium die niedrigste MAC-Adresse heran gezogen.
  • Von der gewählten Rootbrücke aus werden anschließend alle Netzwerkpfade des Spannbaums festgelegt, über den ein Datenaustausch zwischen den Brücken im Kommunikationsnetzwerk erfolgen soll. Hierzu sendet die Rootbrücke zunächst BPDUs an die anderen Brücken. Jede Brücke bestimmt daraufhin als Root-Port einen Port, der die geringsten Pfadkosten zur Rootbrücke hat. Im Falle gleicher Pfadkosten wird als ergänzendes Kriterium die Port-ID heran gezogen. Anschließend werden auf Basis der Pfadkosten Designate-Ports bestimmt und die designierten Brücken des Spannbaums bestimmt.
  • In RSTP teilt die Rootbrücke allen Brücken im Spannbaum in regelmäßigen Abständen über eine entsprechende BPDU (Hello-Signal) mit, dass sie noch da ist. Falls ein solches Hello-Signal ausbleibt, etwa aufgrund des Ausfalls eines Links oder der Rootbrücke selbst, ist eine Neukonfiguration (Rekonvergenz) des Kommunikationsnetzwerks zur Ermittlung eines neuen Spannbaums erforderlich. Da in dieser Zeit lediglich BPDUs, d. h. Datenpakete zur Ermittlung eines neuen Spannbaums übermittelt werden, ist das Kommunikationsnetzwerk für diese Zeitspanne für einen Nutzdatenaustausch nicht verwendbar.
  • In RSTP werden zudem alternative Ports ermittelt, welche BPDUs von anderen Brücken blockieren und einen alternativen Weg zur Rootbrücke bieten, falls der Root-Port ausfällt.
  • Ferner ist in RSTP ein Proposal/Agreement Handshake-Mechanismus zwischen direkt verbundenen Brücken implementiert. Über den Proposal/Agreement Handshake-Mechanismus senden RSTP-Brücken von sich aus in vorgebbaren zeitlichen Abständen BPDUs an die benachbarten Brücken. In RSTP ist festgelegt, dass eine Brücke ihren Link zu einer Nachbarbrücke verliert, wenn sie innerhalb einer vorgebbaren Zeitspanne BPDUs nicht empfangen kann. Auf diese Weise kann ein Ausfall eines Links schnell erkannt werden.
  • Die Topologie des Industrie-LAN 3 umfasst sechs Brücken 813, die über jeweilige Punkt-zu-Punkt Datenlinks ringförmig miteinander verbunden sind. In den Figuren sind die Datenlinks zwischen den Brücken mittels einer durchgezogenen Linie dargestellt und ansonsten nicht näher bezeichnet.
  • In dem Industrie-LAN 3 wird ein auf dem Ethernet-Standard basierendes proprietäres Netzwerkprotokoll ausgeführt, welches von dem Netzwerkprotokoll RSTP des Office-LAN 2 verschieden ist. Die Brücken 813 werden deshalb im Unterschied zu den RSTP-Brücken des Office-LAN 2 hier und im Weiteren als ”proprietäre Brücken” des Industrie-LAN 3 bezeichnet.
  • Das Office-LAN 2 und das Industrie-LAN 3 sind über drei redundante Datenlinks 1416 datentechnisch miteinander verbunden. Dies sind ein für den Nutzdatenaustausch voreingestellt aktivierter Master-Datenlink 14 und zwei für den Nutzdatenaustausch voreingestellt inaktivierte Slave-Datenlinks 15, 16.
  • In 1A ist eine Ausgangssituation zur Ausführung des erfindungsgemäßen Verfahrens dargestellt, in dem der Master-Datenlink 14 aktiviert und die beiden Slave-Datenlinks 15, 16 inaktiviert sind. In 1A ist der aktivierte Master-Datenlink 14 deshalb mittels einer durchgezogenen Linie dargestellt, während die beiden inaktivierten Slave-Datenlinks 15, 16 mittels unterbrochener Linien dargestellt sind. Die beiden Slave-Datenlinks 15, 16 dienen als aktivierbare redundante Verbindungen (Back-up-Datenlinks) zwischen den beiden Netzwerken 2, 3.
  • Der Master-Datenlink 14 ist mit einem RSTP ausführenden RSTP-Port der RSTP-Brücke 6 des Office-LAN 2 und einem das proprietäre Netzwerkprotokoll einsetzenden proprietären Port der proprietären Brücke 8 (”Master-Brücke”) des Industrie-LAN 3 verbunden. Ein erster Slave-Datenlink 15 ist mit einem RSTP ausführenden RSTP-Port der RSTP-Brücke 7 des Office-LAN 2 und einem proprietären Port der proprietären Brücke 9 des Industrie-LAN 3 verbunden. Ein zweiter Slave-Datenlink 16 ist mit einem RSTP ausführenden RSTP-Port der RSTP-Brücke 5 des Office-LAN 2 und einem proprietären Port der proprietären Brücke 13 des Industrie-LAN 3 verbunden. Insofern verbindet jeder Datenlink zwischen den beiden Netzwerken 2, 3 eine Brücke des einen Netzwerks mit einer separaten Brücke des anderen Netzwerks.
  • Beide mit dem Master-Datenlink 14 verbundene Ports sind aktiviert, wobei sich insbesondere der RSTP-Port der RSTP-Brücke 6 des Office-LAN 2 in seinem Zustand ”Forwarding” befindet. Zur Blockierung des ersten Slave-Datenlinks 15 ist der mit dem ersten Slave-Datenlink 15 verbundene RSTP-Port der RSTP-Brücke 7 des Office-LAN 2 in seinen Zustand ”Blocking” versetzt. Zur Blockierung des zweiten Slave-Datenlinks 16 ist der mit dem zweiten Slave-Datenlink 16 verbundene RSTP-Port der RSTP-Brücke 5 des Office-LAN 2 in seinen Zustand ”Blocking” versetzt.
  • In dem in den Figuren dargestellten Kommunikationsnetzwerk 1 sind den RSTP-Brücken des Office-LAN 2 und den mit dem Office-LAN 2 über die Datenlinks 1416 unmittelbar verbundenen Brücken 8, 9, 13 des Industrie-LAN 3 RSTP-Pfadkosten zugewiesen. In der mit dem Master-Datenlink 14 verbundenen Master-Brücke 8 des Industrie-LAN 3 sind die Pfadkosten aller mit dem Office-LAN 2 direkt verbundenen Brücken des Industrie-LAN 3 in einer Datenspeichereinrichtung abgelegt. Alternativ können die Pfadkosten der mit dem Office-LAN 2 direkt verbundenen Slave-Brücken des Industrie-LAN 3 über von den Slave-Brücken generierte Meldungen (Datenpakete) insbesondere auf Basis des proprietären Netzwerkprotokolls des Industrie-LAN 3 an die Master-Brücke 8 gesendet werden.
  • In 1B ist eine Situation dargestellt, in der, ausgehend von der in 1A dargestellten Situation mit aktiviertem Master-Datenlink 14 dieser für die Nutzdatenübertragung ausgefallen ist. In 1B ist der ausgefallene Master-Datenlink 14 mittels eine unterbrochenen Linie dargestellt. Der Ausfall des aktivierten Master-Datenlinks 14 wird von den beiden durch den Master-Datenlink 14 verbundenen Brücken durch einen fehlenden Signalempfang (”Loss of Signal”) durch eine entsprechende Einrichtung zur Erfassung eines fehlenden Signalempfangs (Hardware-Detektor) erfasst. In der Master-Brücke 8 des Industrie-LAN 3 löst dies einen Hardware-Alarm aus, in dessen Folge ein erstes Datenpaket N1 von der Master-Brücke 8 generiert wird.
  • Dann wählt die Master-Brücke 8 unter den beiden Slave-Brücken 9, 13, jene aus, welcher die kleineren RSTP-Pfadkosten zugewiesen sind. In dem Ausführungsbeispiel von 1B ist dies die Slave-Brücke 9 des ersten Slave-Datenlinks 15.
  • Anschließend sendet die Master-Brücke 8 unter Nutzung des proprietären Netzwerkprotokolls des Industrie-LAN das erste Datenpaket N1 über den entsprechenden Datenlink des ringförmigen Industrie-LAN 3 an die mit dem ersten Slave-Datenlink 15 verbundene Slave-Brücke 9. Das erste Datenpaket N1 enthält logische Informationen, durch welche die Slave-Brücke 9 informiert wird, dass der Master-Link 14 für den Nutzdatenaustausch ausgefallen ist. Zu diesem Zweck ist in dem ersten Datenpaket N1 beispielsweise ein Flag ”Ausgefallener-Master-Datenlink” gesetzt.
  • Durch Empfang und Verarbeitung des ersten Datenpakets N1 durch die Slave-Brücke 9 wird eine teilweise oder vollständige Ausführung des Netzwerkprotokolls RSTP gemäß IEEE-Norm 802.1w auf jenem Port der Slave-Brücke 9 ausgelöst, der mit dem ersten Slave-Datenlink 15 verbunden ist. Hierdurch erscheint die Slave-Brücke 9 des Industrie-LAN 3 dem Office-LAN 2 gegenüber als RSTP-Brücke.
  • Der Slave-Brücke 9 des Industrie-LAN 3 ist hierbei eine höchste Brücken-ID, das heißt niedrigste Priorität, aller RSTP-Brücken des Office-LAN 2 zugewiesen, wodurch sichergestellt werden kann, dass die Slave-Brücke 9 bei der Bildung eines Spannbaums des Office-LAN 2 nicht in unerwünschter Weise als neue Root-Brücke gewählt wird.
  • Anschließend generiert die nun mit einem RSTP-Port versehene Slave-Brücke 9 des Industrie-LAN 3 einen ersten RSTP-Konfigurationsrahmen (RSTP-BPDU1) und sendet den ersten RSTP-Konfigurationsrahmen durch ihren RSTP-Port über den ersten Slave-Datenlink 15 an die mit dem ersten Slave-Datenlink verbundene RSTP-Brücke 7 des Office-LAN 2. Der RSTP-Konfigurationsrahmen RSTP-BPDU1 ist im Rahmen des in RSTP implementierten Handshake-Mechanismus eine Vorschlagsmeldung (Proposal) zur Aktivierung des mit dem ersten Slave-Datenlink 15 verbundenen (blockierten) RSTP-Ports der RSTP-Brücke 7 des Office-LAN 2.
  • Nach Empfang und Verarbeitung des ersten RSTP-Konfigurationsrahmens durch die RSTP-Brücke 7 des Office-LAN 2 generiert die RSTP-Brücke 7 einen zweiten RSTP-Konfigurationsrahmen (RSTP-BPDU2) und sendet den zweiten RSTP-Konfigurationsrahmen an die Slave-Brücke 9 des Industrie-LAN 3. Der zweite RSTP-Konfigurationsrahmen ist eine weitere Vorschlagsmeldung (Proposal).
  • Nach Empfang und Verarbeitung des zweiten RSTP-Konfigurationsrahmens durch die Slave-Brücke 9 generiert diese einen dritten RSTP-Konfigurationsrahmen (RSTP-BPDU3) und sendet den dritten RSTP-Konfigurationsrahmen an die RSTP-Brücke 7 des Industrie-LAN 3. Der dritte RSTP-Konfigurationsrahmen ist eine Einverständnismeldung (Agreement). Nach Empfang der Einverständnismeldung wird der RSTP-Port der RSTP-Brücke 7 des ersten Slave-Datenlinks 15 in seinen Zustand ”Forwarding” versetzt, wodurch der blockierte erste Slave-Datenlink 15 in seinen aktiven Zustand versetzt wird, der einen Nutzdatenaustausch zwischen den beiden Netzwerken ermöglicht. Dies ist in 1B mittels einer durchgezogenen Linie für den ersten Slave-Datenlink 15 veranschaulicht. Der Handshake-Mechanismus zur Aktivierung des mit dem ersten Slave-Datenlink 15 verbundenen blockierten RSTP-Ports entspricht den gemäß IEEE-Norm 802.1w standardisierten Routinen.
  • In 1C ist eine weitere Situation dargestellt, in der der zur Nutzdatenübertragung aktivierte erste Slave-Datenlink 15 ausgefallen ist. Der Ausfall des ersten Slave-Datenlinks 15 wird durch die mit dem ersten Slave-Datenlink 15 verbundene Slave-Brücke 9 erfasst, beispielsweise durch einen Hardware-Detektor, der den fehlenden Empfang von Konfigurations-BPDUs, die von der Brücke 7 des Office-LAN 2 ausgesendet werden, erfassen kann. In der Slave-Brücke 9 des Industrie-LAN 3 löst dies einen Hardware-Alarm aus, in dessen Folge ein zweites Datenpaket N2 von der Slave-Brücke 9 generiert wird.
  • Anschließend sendet die Slave-Brücke 9 unter Nutzung des proprietären Netzwerkprotokolls des Industrie-LAN 3 das zweite Datenpaket N2 über den entsprechenden Datenlink des ringförmigen Industrie-LAN 3 an die mit dem Master-Datenlink 14 verbundene Master-Brücke 8. Das zweite Datenpaket N2 enthält logische Informationen, durch welche die Master-Brücke 8 informiert wird, dass der erste Slave-Datenlink 15 für den Nutzdatenaustausch ausgefallen ist. Zu diesem Zweck ist in dem zweiten Datenpaket N2 beispielsweise ein Flag ”Ausgefallener-Slave-Datenlink” gesetzt.
  • In der Master-Brücke 8 des Industrie-LAN 3 löst die Erfassung des Ausfalls des ersten Slave-Datenlinks 15 mittels des zweiten Datenpakets einen Hardware-Alarm aus, in dessen Folge erneut ein erstes Datenpaket N1 von der Master-Brücke 8 generiert wird.
  • Dann wählt die Master-Brücke 8 die nächste Slave-Brücke 13 zur Übertragung des generierten ersten Datenpakets N1 aus. Die Master-Brücke 8 wählt eine solche Slave-Brücke, der bezüglich der mit dem ausgefallenen ersten Slave-Datenlink 15 verbundenen Slave-Brücke 9 die nächstniedrigen RSTP-Pfadkosten zugewiesen sind, hier die Slave-Brücke 13.
  • Anschließend sendet die Master-Brücke 8 unter Nutzung des proprietären Netzwerkprotokolls des Industrie-LAN das erste Datenpaket N1 über den entsprechenden Datenlink des ringförmigen Industrie-LAN 3 an die mit dem zweiten Slave-Datenlink 16 verbundene Slave-Brücke 13. Das erste Datenpaket N1 enthält logische Informationen, durch welche die Slave-Brücke 13 informiert wird, dass der Master-Datenlink 14 für den Nutzdatenaustausch ausgefallen ist. Zu diesem Zweck ist in dem ersten Datenpaket N1 beispielsweise ein Flag ”Ausgefallener-Master-Datenlink” gesetzt.
  • Durch Empfang und Verarbeitung des ersten Datenpakets N1 durch die Slave-Brücke 13 des zweiten Slave-Datenlinks 16 wird eine teilweise oder vollständige Ausführung des Netzwerkprotokolls RSTP gemäß IEEE-Norm 802.1w auf jenem Port der Slave-Brücke 13 ausgelöst, der mit dem zweiten Slave-Datenlink 16 verbunden ist. Hierdurch erscheint die Slave-Brücke 13 des Industrie-LAN 3 dem Office-LAN 2 gegenüber als RSTP-Brücke.
  • Anschließend generiert die nun mit einem RSTP-Port versehene Slave-Brücke 13 des Industrie-LAN 3 einen ersten RSTP-Konfigurationsrahmen (RSTP-BPDU1) und sendet den ersten RSTP-Konfigurationsrahmen durch ihren RSTP-Port über den zweiten Slave-Datenlink 16 an die mit dem zweiten Slave-Datenlink verbundene RSTP-Brücke 5 des Office-LAN 2. Der RSTP-Konfigurationsrahmen RSTP-BPDU1 ist im Rahmen des in RSTP implementierten Handshake-Mechanismus eine Vorschlagsmeldung (Proposal) zur Aktivierung des mit dem zweiten Slave-Datenlink 16 verbundenen (blockierten) RSTP-Ports der Brücke 5 des Office-LAN 2.
  • Nach Empfang und Verarbeitung des ersten RSTP-Konfigurationsrahmens durch die RSTP-Brücke 5 des Office-LAN 2 generiert die RSTP-Brücke 5 einen zweiten RSTP-Konfigurationsrahmen (RSTP-BPDU2) und sendet den zweiten RSTP-Konfigurationsrahmen an die Slave-Brücke 13 des Industrie-LAN 3. Der zweite RSTP-Konfigurationsrahmen ist eine weitere Vorschlagsmeldung (Proposal).
  • Nach Empfang und Verarbeitung des zweiten RSTP-Konfigurationsrahmens durch die Slave-Brücke 13 generiert diese einen dritten RSTP-Konfigurationsrahmen (RSTP-BPDU3) und sendet den dritten RSTP-Konfigurationsrahmen an die Brücke 5 des Industrie-LAN 3. Der dritte RSTP-Konfigurationsrahmen ist eine Einverständnismeldung (Agreement). Nach Empfang der Einverständnismeldung wird der RSTP-Port der Brücke 5 des zweiten Slave-Datenlinks 16 in seinen Zustand ”Forwarding” versetzt, wodurch der blockierte zweite Slave-Datenlink 16 in seinen aktiven Zustand versetzt wird, in dem ein Nutzdatenaustausch zwischen den beiden Netzwerken ermöglicht ist. Dies ist in 1C mittels einer durchgezogenen Linie für den zweiten Slave-Datenlink 16 veranschaulicht. Der Handshake-Mechanismus zur Aktivierung des mit dem zweiten Slave-Datenlink 16 verbundenen blockierten RSTP-Ports entspricht den gemäß IEEE-Norm 802.1w standardisierten Routinen.
  • In 1D ist eine weitere Situation dargestellt, in der der Master-Datenlink 14 nach seinem Ausfall wiederhergestellt ist. Die mit dem Master-Datenlink 14 verbundene Master-Brücke 8 des Industrie-LAN 3 erkennt über wieder eintreffende Signale, welche von der mit dem Master-Datenlink 14 verbundenen Brücke 6 des Office-LAN 2 ausgesendet werden, den wiederherstellten Master-Datenlink 14. Die Erfassung der Signale erfolgt durch den Hardware-Detektor, welcher auch das Fehlen von Signalen erfasst hat. Dies triggert die Generierung eines dritten Datenpakets N3 durch die Master-Brücke 8.
  • Das dritte Datenpaket N3 wird anschließend mittels des proprietären Netzwerkprotokolls des Industrie-LAN 3 über die entsprechenden Datenlinks des Industrie-LAN 3 an die Slave-Brücken 9, 13 gesendet. Durch das dritte Datenpaket N3 werden die Slave-Brücken 9, 13 darüber informiert, dass der Master-Datenlink 14 wiederhergestellt ist. Zu diesem Zwecke ist in dem dritten Datenpaket N3 beispielsweise ein Flag ”Ausgefallener-Master-Datenlink” gelöscht.
  • Durch den Empfang und die Verarbeitung des dritten Datenpakets N3 durch die Slave-Brücken 9, 13 wird jeweils eine Beendigung der Ausführung des Netzwerkprotokolls RSTP für den jeweils mit dem Slave-Datenlink verbundenen Port der Slave-Brücken ausgelöst. Die mit den Slave-Datenlinks verbundenen Ports der Slave-Brücken 9, 13 werden somit jeweils von einem RSTP-Port wieder zu einem von dem proprietären Netzwerkprotokoll des Industrie-LAN 3 gesteuerten Port geändert. Die Slave-Brücken 9, 13 erscheinen dem Office-LAN 2 gegenüber nicht mehr als RSTP-Brücken.
  • Die Erfassung des wiederhergestellten Master-Datenlinks 14 durch die Master-Brücke 8 triggert weiterhin die teilweise oder vollständige Ausführung des Netzwerkprotokolls RSTP gemäß IEEE-Norm 802.1w (nur) auf jenem Port der Master-Brücke 8, der mit dem blockierten Master-Datenlink 14 verbunden ist. Hierdurch erscheint die Master-Brücke 8 dem Office-LAN 2 gegenüber als RSTP-Brücke.
  • Daraufhin generiert die nun mit einem RSTP-Port versehene Master-Brücke 8 des Industrie-LAN 3 einen ersten RSTP-Konfigurationsrahmen (RSTP-BPDU1) und sendet den ersten RSTP-Konfigurationsrahmen durch ihren mit dem Master-Datenlink 14 verbundenen RSTP-Port an die mit dem Master-Datenlink 14 verbundene RSTP-Brücke 6 des Office-LAN 2. Dies ist in 1D durch einen Pfeil veranschaulicht. Der Konfigurationsrahmen RSTP-BPDU1 ist im Rahmen des in RSTP implementierten Handshake-Mechanismus eine Vorschlagsmeldung (Proposal).
  • Nach Empfang und Verarbeitung des ersten RSTP-Konfigurationsrahmens durch die RSTP-Brücke 6 des Office-LAN 2 generiert die RSTP-Brücke 6 einen zweiten RSTP-Konfigurationsrahmen (RSTP-BPDU2) und sendet den zweiten RSTP-Konfigurationsrahmen an die Master-Brücke 8. Dies ist in 1D ebenso durch einen Pfeil veranschaulicht. Der zweite RSTP-Konfigurationsrahmen ist eine Vorschlagsmeldung (Proposal) zur Aktivierung des mit dem Master-Datenlink 14 verbundenen, blockierten RSTP-Ports der Brücke 6 des Office-LAN 2.
  • Nach Empfang und Verarbeitung des zweiten RSTP-Konfigurationsrahmens generiert die Master-Brücke 8 des Industrie-LAN 3 einen dritten RSTP-Konfigurationsrahmen (RSTP-BPDU3) und sendet den dritten RSTP-Konfigurationsrahmen durch ihren mit dem Master-Datenlink 14 verbundenen RSTP-Port an die mit dem Master-Datenlink 14 verbundene RSTP-Brücke 6 des Office-LAN 2. Dies ist in 1D durch einen Pfeil veranschaulicht.
  • Der dritte RSTP-Konfigurationsrahmen ist eine Einverständnismeldung (Agreement) zur Aktivierung des mit dem Master-Datenlink 14 verbundenen, blockierten RSTP-Ports der Brücke 6 des Office-LAN 2.
  • Daraufhin wird der blockierte RSTP-Port der mit dem Master-Datenlink 14 verbundenen RSTP-Brücke 6 des Office-LAN 2 in seinen Zustand ”Forwarding” versetzt. Hierdurch wird der blockierte Master-Datenlink 14 in seinen aktiven Zustand versetzt, so dass ein Nutzdatenaustausch zwischen den beiden Netzwerken 2, 3 über den Master-Datenlink 14 ermöglicht ist.
  • Der oben aufgezeigte Handshake-Mechanismus zur Aktivierung des mit dem Master-Datenlink 14 verbundenen, blockierten RSTP-Ports der RSTP-Brücke 6 des Office-LAN 2 erfolgt durch Routinen, die in der IEEE-Norm 802.1w standardisiert sind.
  • Weiterhin wird der von Master-Brücke 8 des Industrie-LAN 3 empfangene zweite RSTP-Konfigurationsrahmen (RSTP-BPDU2) unverändert an die mit dem zweiten Slave-Datenlink 16 verbundene Slave-Brücke 13 weitergeleitet. Eine Weiterleitung erfolgt hierbei durch das proprietäre Netzwerkprotokoll des Industrie-LAN 3. Nach Empfang leitet die mit dem zweiten Slave-Datenlink 16 verbundene Slave-Brücke 13 den zweiten RSTP-Konfigurationsrahmen (RSTP-BPDU2) unverändert an die mit dem zweiten Slave-Datenlink 16 verbundene RSTP-Brücke 5 des Office-LAN 2 weiter. Daraufhin wird der sich im Zustand ”Forwarding” befindliche RSTP-Port der mit dem zweiten Slave-Datenlink 16 verbundenen RSTP-Brücke 5 des Office-LAN 2 in seinen Zustand ”Blocking” versetzt, so dass der zweite Slave-Datenlink 16 inaktiviert wird.
  • Anschließend, nach Aktivierung des Master-Datenlinks 14 und nach Weiterleitung des zweiten RSTP-Konfigurationsrahmens (RSTP-BPDU2) durch die Master-Brücke 8 des Industrie-LAN 3, wird eine Beendigung der Ausführung des Netzwerkprotokolls RSTP für den mit dem Master-Datenlink 14 verbundenen Port der Master-Brücke 8 ausgelöst. Der mit dem Master-Datenlink 14 verbundene Port der Master-Brücke 8 wird somit von einem RSTP-Port wieder zu einem von dem proprietären Netzwerkprotokoll des Industrie-LAN 3 gesteuerten Port geändert. Die Master-Brücke 8 erscheint dann dem Office-LAN 2 gegenüber nicht mehr als eine RSTP-Brücke.
  • Durch das erfindungsgemäße Verfahren kann in einfacher Weise eine Rekonfiguration einer mehrfach-redundanten Datenverbindung zweier verschiedene Netzwerkprotokolle einsetzender Netzwerke erreicht werden. Insbesondere kann ein RSTP-Netzwerk mit einem weiteren Netzwerk in Ringtopologie mehrfach-redundant verbunden werden, wobei die Rekonfigurationszeiten zur Rekonfiguration eines die beiden Netzwerke verbindenden Datenlinks sehr kurz sind. Eine Einschränkung auf einen einzigen redundanten Backup-Datenlink ist nicht notwendig. Auf diese Weise kann eine Datenverbindung zwischen den beiden Netzwerken sogar bei Mehrfach-Ausfällen von die beiden Netzwerke verbindenden Datenlinks aufrechterhalten werden. Der Aufwand zur Konfiguration eines solchen Kommunikationsnetzwerks ist niedrig.

Claims (19)

  1. Verfahren zum Rekonfigurieren eines paketvermittelten Kommunikationsnetzwerks (1) mit einem ein erstes Netzwerkprotokoll einsetzenden ersten Netzwerk (2) und einem ein von dem ersten Netzwerkprotokoll verschiedenes zweites Netzwerkprotokoll einsetzenden zweiten Netzwerk (3), in welchem die beiden Netzwerke durch wenigstens drei redundante Datenlinks (14, 15, 16) miteinander verbunden sind, von denen jeweils nur einer zum Nutzdatenaustausch aktiviert ist, wobei ein Master-Datenlink (14) voreingestellt aktiviert ist und wenigstens zwei Slave-Datenlinks (15, 16) voreingestellt inaktiviert sind, bei welchem nach Erfassen eines Ausfalls des Master-Datenlinks (14) oder eines Ausfalls eines aktivierten Slave-Datenlinks (15, 16) durch eine mit dem Master-Datenlink (14) verbundene Master-Brücke (8) des zweiten Netzwerks (3) die folgenden Schritte ausgeführt werden: – Generieren eines ersten Datenpakets (N1) durch die Master-Brücke (8) und Übertragen des ersten Datenpakets (N1) an eine mit einem Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks, wobei die Slave-Brücke gemäß einer vorgebbaren Auswahlregel von der Master-Brücke gewählt wird; – Empfangen und Verarbeiten des ersten Datenpakets (N1) durch die gewählte Slave-Brücke, wobei das erste Datenpaket logische Informationen enthält, durch welche anstelle des zweiten Netzwerkprotokolls die wenigstens teilweise Ausführung des ersten Netzwerkprotokolls auf einem mit dem Slave-Datenlink verbundenen Port der Slave-Brücke und eine Aktivierung des Slave-Datenlinks durch das auf dem Port der Slave-Brücke ausgeführte erste Netzwerkprotokoll ausgelöst wird.
  2. Verfahren nach Anspruch 1, bei welchem das erste Datenpaket (N1) mittels des zweiten Netzwerkprotokolls von der Master-Brücke (8) des zweiten Netzwerks (3) zu einer Slave-Brücke des zweiten Netzwerks übertragen wird.
  3. Verfahren nach einem der Ansprüche 1 bis 2, bei welchem eine Erfassung des Ausfalls des Master-Datenlinks (14) durch die mit dem Master-Datenlink verbundene Master-Brücke (8) aufgrund eines von der Master-Brücke (8) nicht mehr empfangenen Signals von der mit der Master-Datenlink (14) verbundenen Brücke (6) des ersten Netzwerks (2) erfolgt.
  4. Verfahren nach einem der Ansprüche 1 bis 3, bei welchem nach Erfassen eines Ausfalls eines aktivierten Slave-Datenlinks durch eine mit dem Slave-Datenlink verbundene Slave-Brücke des zweiten Netzwerks die folgenden Schritte ausgeführt werden: – Generieren eines zweiten Datenpakets (N2) durch die Slave-Brücke und Übertragen des zweiten Datenpakets (N2) an die Master-Brücke; – Empfangen und Verarbeiten des zweiten Datenpakets (N2) durch die Master-Brücke, wobei das zweite Datenpaket logische Informationen enthält, durch welche die Master-Brücke über den Ausfall des aktivierten Slave-Datenlinks (15) informiert wird.
  5. Verfahren nach Anspruch 4, bei welchem das zweite Datenpaket (N2) mittels des zweiten Netzwerkprotokolls von der Slave-Brücke des zweiten Netzwerks zur Master-Brücke des zweiten Netzwerks übertragen wird.
  6. Verfahren nach einem der Ansprüche 1 bis 5, bei welchem die von der Master-Brücke (8) gewählte Slave-Brücke zur Übertragung des ersten Datenpakets (N1) gemäß den Slave-Brücken jeweils zugewiesenen Pfadkosten gewählt wird.
  7. Verfahren nach Anspruch 6, bei welchem von der Master-Brücke (8) bei Ausfall des Master-Datenlinks (14) zur Aktivierung eines Slave-Datenlinks Slave-Brücken mit den jeweils niedrigsten Pfadkosten gewählt werden.
  8. Verfahren nach einem der Ansprüche 1 bis 7, bei welchem das erste Netzwerkprotokoll RSTP gemäß IEEE-Norm 802.1w ist.
  9. Verfahren nach Anspruch 8, bei welchem die Aktivierung eines Slave-Datenlinks durch Ausführen eines in RSTP implementierten Handshake-Mechanismus zwischen den mit dem Slave-Datenlink unmittelbar verbundenen Brücken erfolgt.
  10. Verfahren nach einem der Ansprüche 1 bis 9, bei welchem nach Erfassen der Wiederherstellung des ausgefallenen Master-Datenlinks (14) durch die Master-Brücke (8) die folgenden Schritte ausgeführt werden: – Generieren eines dritten Datenpakets (N3) durch die Master-Brücke (8) und Übertragen des dritten Datenpakets (N3) wenigstens an die mit einem aktivierten Slave-Datenlink verbundene Slave-Brücke; – Empfangen und Verarbeiten des dritten Datenpakets (N3) durch die Slave-Brücke (13), wobei das dritte Datenpaket logische Informationen enthält, durch welche eine wenigstens teilweise Beendigung der Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf der Slave-Brücke oder eine Beendigung des Aussendens von RSTP-Konfigurationsrahmen durch die Slave-Brücke bewirkt wird, – Aktivierung des Master-Datenlinks (14), – Inaktivierung des aktivierten Slave-Datenlinks.
  11. Verfahren nach Anspruch 10, bei welchem das dritte Datenpaket (N3) mittels des zweiten Netzwerkprotokolls von der Master-Brücke des zweiten Netzwerks zu einer Slave-Brücke (8) des zweiten Netzwerks (3) übertragen wird.
  12. Verfahren nach einem der Ansprüche 10 bis 11, bei welchem das dritte Datenpaket (N3) an alle jeweils mit einem Slave-Datenlink verbundenen Slave-Brücken übertragen wird.
  13. Verfahren nach einem der Ansprüche 10 bis 12, bei welchem nach Erfassen der Wiederherstellung des Master-Datenlinks (16) eine wenigstens teilweise Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf einem mit dem Master-Datenlink (14) verbundenen Port der Master-Brücke (8) erfolgt.
  14. Verfahren nach Anspruch 13, bei welchem eine Aktivierung des Master-Datenlinks (14) durch Ausführen eines in RSTP implementierten Handshake-Mechanismus zwischen den mit dem Master-Datenlink (14) direkt verbundenen Brücken (6, 8) erfolgt.
  15. Verfahren nach Anspruch 14, bei welchem zur Inaktivierung des Slave-Datenlinks (16) eine Weiterleitung eines während des Handshake-Mechanismus erzeugten Konfigurationsrahmens durch die Master-Brücke (8) an die mit dem aktivierten Slave-Datenlink (16) verbundene Brücke (5) des ersten Netzwerks (2) erfolgt.
  16. Verfahren nach einem der Ansprüche 13 bis 15, bei welchem nach Aktivierung des Master-Datenlinks (14) eine Beendigung der Ausführung des ersten Netzwerkprotokolls, insbesondere RSTP, auf dem mit dem Master-Datenlink (14) verbundenen Port der Master-Brücke (8) erfolgt.
  17. Paketvermitteltes Kommunikationsnetzwerk (1), mit einem ein erstes Netzwerkprotokoll einsetzenden ersten Netzwerk (2) und einem ein von dem ersten Netzwerkprotokoll verschiedenes zweites Netzwerkprotokoll einsetzenden zweiten Netzwerk (3), in welchem die beiden Netzwerke durch wenigstens drei redundante Datenlinks miteinander verbunden sind, von denen jeweils nur einer zum Nutzdatenaustausch aktiviert ist, wobei ein Master-Datenlink (14) voreingestellt aktiviert ist und wenigstens zwei Slave-Datenlinks (15, 16) voreingestellt inaktiviert sind, in dem eine mit dem Master-Datenlink (14) verbundene Master-Brücke (8) und eine mit dem Slave-Datenlink verbundene Slave-Brücke jeweils so eingerichtet sind, dass ein Verfahren nach einem der Ansprüche 1 bis 16 ausführbar ist.
  18. Master-Brücke eines paketvermittelten Kommunikationsnetzwerks gemäß einem der Ansprüche 1 bis 16.
  19. Slave-Brücke eines paketvermittelten Kommunikationsnetzwerks gemäß einem der Ansprüche 1 bis 16.
DE102007015539A 2007-03-30 2007-03-30 Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks Expired - Fee Related DE102007015539B4 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE102007015539A DE102007015539B4 (de) 2007-03-30 2007-03-30 Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks
CA002682425A CA2682425A1 (en) 2007-03-30 2008-03-14 Method for reconfiguring a communications network
EP08717849A EP2130329A1 (de) 2007-03-30 2008-03-14 Verfahren zum rekonfigurieren eines kommunikationsnetzwerks
CN2008800111666A CN101652963B (zh) 2007-03-30 2008-03-14 重配通信网络的方法
PCT/EP2008/053108 WO2008119649A1 (de) 2007-03-30 2008-03-14 Verfahren zum rekonfigurieren eines kommunikationsnetzwerks
US12/593,972 US8284658B2 (en) 2007-03-30 2008-03-14 Method for reconfiguring a communications network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102007015539A DE102007015539B4 (de) 2007-03-30 2007-03-30 Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks

Publications (2)

Publication Number Publication Date
DE102007015539A1 DE102007015539A1 (de) 2008-10-09
DE102007015539B4 true DE102007015539B4 (de) 2012-01-05

Family

ID=39469348

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007015539A Expired - Fee Related DE102007015539B4 (de) 2007-03-30 2007-03-30 Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks

Country Status (6)

Country Link
US (1) US8284658B2 (de)
EP (1) EP2130329A1 (de)
CN (1) CN101652963B (de)
CA (1) CA2682425A1 (de)
DE (1) DE102007015539B4 (de)
WO (1) WO2008119649A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2409458B1 (de) * 2009-03-18 2013-01-09 Hirschmann Automation and Control GmbH Parallelbetrieb von rstp (rapid spanning tree protocol) und mrp (media redundancy protocol) und segmentierung/kopplung
ES2656433T3 (es) * 2010-01-08 2018-02-27 Siemens Aktiengesellschaft Nodo de red para una red de comunicaciones
FR2978281B1 (fr) * 2011-07-20 2013-09-27 Airbus Operations Sas Procede de reconfiguration d'un dispositif de surveillance de l'environnement d'un aeronef
US9100210B2 (en) * 2011-11-15 2015-08-04 Rockwell Automation Technologies, Inc. Redundant gateway system for device level ring networks
ES2579603T3 (es) 2012-07-20 2016-08-12 Siemens Aktiengesellschaft Procedimiento para la transmisión de mensajes en una red de comunicaciones industrial que puede funcionar de forma redundante y aparato de comunicaciones para una red de comunicaciones industrial que puede funcionar de forma redundante
ES2534377T3 (es) 2012-07-31 2015-04-22 Siemens Aktiengesellschaft Procedimiento para transmitir mensajes en una red de comunicación industrial que puede hacerse funcionar de forma redundante y aparato de comunicación para una red de comunicación industrial que puede hacerse funcionar de forma redundante
EP2704370B1 (de) 2012-08-31 2018-02-07 Siemens Aktiengesellschaft Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Kommunikationsgerät für ein redundant betreibbares industrielles Kommunikationsnetz
WO2014072374A1 (en) 2012-11-09 2014-05-15 Siemens Aktiengesellschaft Method for transmitting messages in an industrial communication network of an industrial automation system and communication device for an industrial communication network
EP2750340A1 (de) 2012-12-28 2014-07-02 Siemens Aktiengesellschaft Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Netzinfrastrukturgerät
EP2750310A1 (de) 2012-12-28 2014-07-02 Siemens Aktiengesellschaft Verfahren zur Synchronisierung lokaler Uhren in einem Kommunikationsnetz eines industriellen Automatisierungssystems und Netzinfrastrukturgerät
ES2659773T3 (es) * 2013-03-15 2018-03-19 Vivint, Inc Uso de un panel de control como un punto de acceso inalámbrico
DE102019114307A1 (de) * 2019-05-28 2020-12-03 Beckhoff Automation Gmbh Automatisierungsnetzwerk, Netzwerkverteiler und Verfahren zur Datenübertragung
CN111478778B (zh) * 2020-04-03 2021-11-02 中电科航空电子有限公司 一种降低rstp环网功耗方法及其应用
US11496418B1 (en) * 2020-08-25 2022-11-08 Xilinx, Inc. Packet-based and time-multiplexed network-on-chip
CN114162067B (zh) * 2021-12-16 2024-03-15 深圳市优必选科技股份有限公司 一种四足机器人及其总线模块

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6222855B1 (en) * 1998-02-19 2001-04-24 Lucent Technologies, Inc. Method and apparatus for converting between differing data and command exchange protocols
WO2003024029A2 (en) * 2001-09-12 2003-03-20 Onfiber Communications, Inc. Metropolitan area local access service system
US20050138008A1 (en) * 2002-12-20 2005-06-23 Tsillas Demetrios J. Method and apparatus for determining a spanning tree
US20060047851A1 (en) * 2004-08-25 2006-03-02 Cisco Technoloy, Inc. Computer network with point-to-point pseudowire redundancy
DE102005017021A1 (de) * 2005-04-13 2006-10-19 Siemens Ag Verfahren und Vorrichtung zur Kommunikation zwischen Netzknotenelementen

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6262977B1 (en) * 1998-08-28 2001-07-17 3Com Corporation High availability spanning tree with rapid reconfiguration
US7107358B2 (en) * 2001-09-12 2006-09-12 Rockwell Automation Technologies, Inc. Bridge for an industrial control system using data manipulation techniques
US6917986B2 (en) * 2002-01-07 2005-07-12 Corrigent Systems Ltd. Fast failure protection using redundant network edge ports
JP2005269059A (ja) * 2004-03-17 2005-09-29 Fujitsu Ltd データ中継装置、データ中継方法およびデータ中継プログラム
US7983173B2 (en) * 2004-05-10 2011-07-19 Cisco Technology, Inc. System and method for detecting link failures
US7916668B2 (en) * 2004-12-30 2011-03-29 Alcatel Lucent Spanning tree protocol with burst avoidance
US7719957B2 (en) * 2005-08-29 2010-05-18 Alcatel Lucent Resiliency in minimum cost tree-based VPLS architecture
CN1941730A (zh) 2005-09-26 2007-04-04 华为技术有限公司 实现rpr桥冗余保护的方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6222855B1 (en) * 1998-02-19 2001-04-24 Lucent Technologies, Inc. Method and apparatus for converting between differing data and command exchange protocols
WO2003024029A2 (en) * 2001-09-12 2003-03-20 Onfiber Communications, Inc. Metropolitan area local access service system
US20050138008A1 (en) * 2002-12-20 2005-06-23 Tsillas Demetrios J. Method and apparatus for determining a spanning tree
US20060047851A1 (en) * 2004-08-25 2006-03-02 Cisco Technoloy, Inc. Computer network with point-to-point pseudowire redundancy
DE102005017021A1 (de) * 2005-04-13 2006-10-19 Siemens Ag Verfahren und Vorrichtung zur Kommunikation zwischen Netzknotenelementen

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
IEEE Standard for local and metropolitan area networks. Part 3: Media access control (MAC) bridges – amendment 2: rapid reconfiguration. IEEE 802.1w-2001
IEEE Standard for local and metropolitan area networks. Part 3: Media access control (MAC) bridges - amendment 2: rapid reconfiguration. IEEE 802.1w-2001 *

Also Published As

Publication number Publication date
CN101652963B (zh) 2012-08-08
US20100110884A1 (en) 2010-05-06
US8284658B2 (en) 2012-10-09
EP2130329A1 (de) 2009-12-09
CN101652963A (zh) 2010-02-17
CA2682425A1 (en) 2008-10-09
DE102007015539A1 (de) 2008-10-09
WO2008119649A1 (de) 2008-10-09

Similar Documents

Publication Publication Date Title
DE102007015539B4 (de) Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks
EP2070256B1 (de) Verfahren zum rekonfigurieren eines kommunikationsnetzwerks
EP2343857B1 (de) Netzwerkknoten für ein Kommunikationsnetzwerk
EP2721784B1 (de) Verfahren zum betreiben einer netzwerkanordnung und netzwerkanordnung
EP2688249B1 (de) Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Kommunikationsgerät für ein redundant betreibbares industrielles Kommunikationsnetz
EP2838220B1 (de) Verfahren zur redundanten Nachrichtenübermittlung in einem industriellen Kommunikationsnetz und Kommunikationsgerät
EP2693700B1 (de) Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Kommunikationsgerät für ein redundant betreibbares industrielles Kommunikationsnetz
EP1532771B1 (de) Testverfahren f r nachrichtenpfade in kommunikationsnetzen s owie netzelement
EP2130331B1 (de) Verfahren zum rekonfigurieren eines kommunikationsnetzwerks
WO2007063045A1 (de) Netzwerk mit redundanzeigenschaften, ethernet-switch für ein derartiges netzwerk sowie verfahren zur konfiguration eines derartigen netzwerks
EP2652917B1 (de) Zwischennetzwerk in ringtopologie und verfahren zum herstellen einer netzwerkverbindung zwischen zwei netzwerkdomänen
EP2127241B1 (de) Zielportsuche in netzwerken aus gekoppelten teilnetzen
EP2704370B1 (de) Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Kommunikationsgerät für ein redundant betreibbares industrielles Kommunikationsnetz
DE102007021922B4 (de) Paketvermitteltes Kommunikationsnetzwerk und Verfahren zum Rekonfigurieren des Kommunikationsnetzwerks
EP2750310A1 (de) Verfahren zur Synchronisierung lokaler Uhren in einem Kommunikationsnetz eines industriellen Automatisierungssystems und Netzinfrastrukturgerät
DE102008017192A1 (de) Verfahren zum Aufbau eines Netzwerks
WO2005027435A1 (de) Verfahren zur optimierten deaktivierung von inter-domain routen
EP2182680B1 (de) Verfahren zum Betrieb eines Kommunikationsnetzwerkes und Kommunikationskomponente
EP2290882B1 (de) Verfahren zur mehrfachen Fehlerredundanz in Netzwerken mit Ringtopologien
EP2817923B1 (de) Rechnernetzwerk mit einer ringförmigen busverbindung
EP2750340A1 (de) Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Netzinfrastrukturgerät
EP1394987A1 (de) Redundante Netzwerkanordnung
EP0512140A1 (de) Verfahren zum Konfigurieren eines aus zwei Ringnetzen gebildeten Kommunikationsnetzes

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee
R020 Patent grant now final

Effective date: 20120406

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