DE102007062739B4 - Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm - Google Patents

Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm Download PDF

Info

Publication number
DE102007062739B4
DE102007062739B4 DE102007062739A DE102007062739A DE102007062739B4 DE 102007062739 B4 DE102007062739 B4 DE 102007062739B4 DE 102007062739 A DE102007062739 A DE 102007062739A DE 102007062739 A DE102007062739 A DE 102007062739A DE 102007062739 B4 DE102007062739 B4 DE 102007062739B4
Authority
DE
Germany
Prior art keywords
nodes
node
multicast
destination
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
DE102007062739A
Other languages
English (en)
Other versions
DE102007062739A1 (de
Inventor
Dr. Weber Karl
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 DE102007062739A priority Critical patent/DE102007062739B4/de
Priority to PCT/EP2008/060995 priority patent/WO2009037067A1/de
Publication of DE102007062739A1 publication Critical patent/DE102007062739A1/de
Application granted granted Critical
Publication of DE102007062739B4 publication Critical patent/DE102007062739B4/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
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/20Support for services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/35Switches specially adapted for specific applications
    • H04L49/351Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches

Landscapes

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

Abstract

Verfahren zur Begrenzung einer Multicast-Last bei einem Ethernet-Netzwerk (10) mit einer Mehrzahl von Knoten (12) als Netzwerkteilnehmer, – wobei jeder Knoten (12) zumindest einen ersten, zweiten und dritten Ein- und Ausgangsport – Port (14, 16, 18) – umfasst, – wobei über den ersten, zweiten und dritten Port (14, 16, 18) eine Verbindung zu anderen Knoten (12) bestehen kann und zwar über den ersten und zweiten Port (14, 16) zu anderen Knoten (12) innerhalb einer hierarchisch gleichen Linie des Netzwerks (10) und über den dritten Port (18) zu anderen Knoten (12) in einer hierarchisch untergeordneten Linie des Netzwerks (10), – wobei ein Satz vorab definierter, hierarchisch organisierter Regeln bereitgestellt wird, mittels welcher im Ethernet-Netzwerk (10) ein Datenfluss von einem Knoten (12) als Quelle zu einem oder mehreren anderen Knoten (12) als Ziel geleitet wird, – wobei die Regeln auf eine Topologie des Ethernet-Netzwerks (12) abgestellt sind, derart,...

Description

  • In Ethernet-Netzwerken, die mehr und mehr auch im Bereich einer Automatisierung technischer Prozesse Verwendung finden, kommunizieren die von dem jeweiligen Netzwerk umfassten Netzwerkteilnehmer, also Automatisierungsgeräte und dergleichen, z. B. auf Basis von Punkt-zu-Punkt-Verbindungen, die genau zwei Netzwerkteilnehmer oder kurz „Knoten” (Sender und Empfänger oder Quelle und Ziel) involviert oder auf Basis von Broadcast oder Multicast Verbindungen, bei denen auf Empfängerseite eine Mehrzahl von Knoten involviert ist.
  • Der Begriff Punkt-zu-Punkt-Verbindung (Unicast) hat sich zur Klassifikation von Kommunikationsvorgängen in Netzwerken durchgesetzt. Vornehmlich werden direkte Verbindungen zwischen zwei Knoten, also ohne vermittelnde Zwischenstation, als Punkt-zu-Punkt-Verbindungen bezeichnet. Hier wird der Begriff Unicast jedoch so gebraucht, dass auch so genannte Ende-zu-Ende-Verbindungen umfasst sind, bei denen ebenfalls eine Kommunikation zwischen nur zwei Knoten erfolgt, bei denen jedoch auf dem Kommunikationspfad die Weitervermittlung durch Zwischenstationen, Switches und dergleichen, genutzt wird.
  • Im Unterschied zu Unicast bezeichnen Broadcast und Multicast Kommunikationsvorgänge, bei denen eine Nachricht an alle Knoten bzw. eine bestimmte Menge von Knoten gesendet wird. Während beim Broadcast grundsätzlich alle Knoten adressiert sind, richtet sich ein Multicast nur an bestimmte Ziele oder Knoten. Zur Unterscheidung werden dabei im Folgenden die Knoten, die zum Empfang eines Multicasts vorgesehen sind, als „Abnehmer” bezeichnet. Jeder Multicast wird genau wie ein Unicast an einen der Zielknoten als Primärziel adressiert. Jeder dann noch verbleibende Abnehmer erkennt ob ein Multicast für ihn bestimmt ist, anhand der als Primärziel angegebenen Adresse und zwar auch dann, wenn eine Adresse des Abnehmers und eine Adresse des als Primärziel angegebenen Knotens nicht übereinstimmen. Zu diesem Zweck ist ein weiter unten kurz erläutertes Gruppenmanagement, z. B. nach den für IGMP definierten Grundlagen, vorgesehen. Jeder Abnehmer erkennt also, ob er zu der durch das Ziel vorgegebenen Gruppe gehört und wird auf diese Weise ebenfalls zu einem Empfänger oder Ziel des Multicasts. Hier und im Folgenden wird jeder Abnehmer zur Unterscheidung von dem Primärziel als Sekundärziel bezeichnet.
  • Während bei Unicast die Wegefindung zwischen den zwei Knoten durch die Adressen bestimmt ist, die von Zwischenstationen „gelernt” werden können (oder die Zwischenstation „weiss” aufgrund von topologischen Adressen, wo das Ziel liegt), ist dies bei Multicast nicht möglich, weil immer nur ein Ziel angegeben werden kann, das dann eine Identifikation für die Abnehmer darstellt. Die Zwischenstationen können also die Multicast-Adressen nicht lernen, sondern müssen entsprechend mit speziellen Weiterleitungsinformationen versorgt werden. Dieser Prozess ist aufwändig und wird deshalb nur von wenigen als Zwischenstation fungierenden Switches unterstützt.
  • Das Resultat ist, dass bei Multicast die meisten Switches das Netz fluten und somit eine große Zahl von Kommunikationsverbindungen (Links) zwischen den betroffenen Knoten unnötig belegen. Hinzu kommt, dass auch bei Endknoten ohne Multicastfilter eine Flut von Frames ankommt, die diese mitunter nicht beherrschen. Der für die hier betroffene Technologie gebräuchliche Begriff „Frame” wird hier und im Folgenden synonym mit ansonsten verwendbaren Bezeichnungen wie Telegramm, Nachricht, usw. verwendet und bezeichnet eine entsprechende Zusammenfassung von über das Netzwerk bei Kommunikationsvorgängen übermittelten Daten.
  • Negativ wirkt sich zudem aus, dass Suchfunktionen in Multicast-Filtertabellen eine nicht unerhebliche Zusatzbelastung darstellen und somit die Weiterleitung in der Regel nicht sehr effizient erfolgen kann.
  • Probleme der o. g. Art sind bisher im Wesentlichen ignoriert worden, nachdem die meisten Switches keine Vorkehrungen bieten, die im Hinblick auf eine etwaige Problemlösung verwendbar wären. Bei Netzwerken mit einer begrenzten Knotenanzahl und/oder nur wenig Multicast-Verkehr ist dies auch für die überwiegende Zahl von Anwendungsfällen akzeptabel.
  • Daneben gibt es jedoch auch Problemlösungsansätze, die z. B. auf einem der ISO-Schicht 2 zugeordneten Reservierungsprotokoll GMRP (GARP Multicast Reservation Protocol), basieren, das allerdings nicht von allen Switches unterstützt wird. Für die ISO-Schicht 3 gibt es für IP Multicast-Adressen das so genannten IGMP (IP Group Management Protocol). Des Weiteren gibt es für „PROFINET IRT” ein „Schedule based forwarding”, das auch das o. g. Multicastproblem löst.
  • Diese und evtl. weitere, hier nicht erwähnte Ansätze sind insoweit jedoch nicht optimal, als stets ein Einspeisen von Projektierungsdaten in die Zwischenstationen, also z. B. Switchtes und dergleichen, erforderlich ist.
  • Aus dem Fachartikel „Deadlock-Free Multicasting in Irregular Networks Using Prefix Routing” von Jie Wu und Li Sheng in „The Journal of Supercomputing”, 31, 63–78, 2005, wird ein Verfahren beschrieben, wie anhand von Kennzeichnungen, die einzelnen Netzwerkknoten zugewiesen sind und deren grundsätzliche funktionale Entsprechung im weiteren Verlauf der Anmeldung auch als „Alias” bezeichnet wird, durch Betrachtung von Teilabschnitten solcher Kennzeichnungen, in dem Fachartikel und im Stand der Technik als „Prefix” bezeichnet, evtl. sich ergebende Blockaden im Datenfluss beim Multicast vermeidbar sind. Der Fachartikel befasst sich nur mit der Erreichbarkeit der einzelnen Multicast-Ziele, nicht jedoch mit der Begrenzung der Multicast-Last, wie dies bei der Erfindung im Vordergrund steht. Der Fachartikel „Skalierbare Gruppenkommunikation in Netzen mit beliebiger Topologie” von Butenuth und Heiß im Tagungsband EMVA („Entwicklung und Management verteilter Anwendungssysteme”), Oktober 1995, befasst sich mit Kommunikation zwischen Prozessen in Multirechnersystemen, wobei ein Spanning Tree, wobei ein Spanning Tree zwischen den beteiligten Knoten aufgebaut wird und einem darauf basierenden Algorithmus das unnötige Versenden identischer Nachrichten vermieden werden soll. Der Ansatz befasst sich zwar auch mit einer verbesserten Bandbreitennutzung, indem das Versenden identischer Nachrichten vermieden werden soll, erreicht dadurch aber keine Begrenzung der Multicast-Last wie bei der Erfindung, denn zum Vermeiden des Versendens identischer Nachrichten wird bei der Erfindung die Verwendung von Multicast vorausgesetzt, davon ausgehend eine Kanalisierung des sich ergebenden Datenflusses angestrebt, während der Ansatz in dem Fachartikel darauf abstellt, dass die Netzwerktopologie bekannt ist und anhand der bekannten Topologie ein oder mehrere Pfade für einen optimalen Datenfluss gefunden werden können, während die Erfindung gerade auf solche Projektierungsdaten und dergleichen verzichten will.
  • In dem Fachartikel „Prefix routing schemes in dynamic networks” von Bakker, van Leeuwen und Tan in „Computer Networks and ISDN Systems” (1993) wird das in „Deadlock-Free Multicasting in Irregular Networks Using Prefix Routing” erwähnte Verfahren mit weiteren Details beschrieben. In Rich Seifert: The switch book, 2000, S. 409–417, befasst sich der Autor ebenfalls mit einer Begrenzung der Multicast-Last und verweist dazu auf einen Protokollmechanismus zur Registrierung von Multicast-Adressen. Dies führt im Ergebnis zu Filtertabellen oder sonstigen Projektierungsdaten, die nach dem Ansatz gemäß der Erfindung gerade vermieden werden sollen.
  • Eine Aufgabe der vorliegenden Erfindung besteht entsprechend darin, das bewährte Switching von Ethernet unverändert zu lassen und soweit irgend möglich auf die Projektierung der Switches selbst zu verzichten, obwohl in Ausnahmefällen nach wie vor das Laden von Projektierungsdaten in die Switches unvermeidlich sein wird. Bei bevorzugten Ausführungsformen der Erfindung steht bei der Begrenzung der Multicasts im Vordergrund, stark beanspruchte Wege möglichst wenig zu belasten.
  • Zur Lösung dieser Aufgabe ist ein Verfahren, wie es in Anspruch 1 definiert ist, vorgesehen. Insbesondere ist dabei bei einem Verfahren zur Begrenzung einer Multicast-Last bei einem Ethernet-Netzwerk mit einer Mehrzahl von Knoten als Netwerkteilnehmern vorgesehen, dass ein Satz vorab definierter, hierarchisch organisierter Regeln bereitgestellt wird, mittels welcher im Ethernet-Netzwerk ein Datenfluss von einem Knoten als Quelle zu einem oder mehreren anderen Knoten als Ziel geleitet wird und dass die Regeln auf eine Topologie des Ethernet-Netzwerks abgestellt sind, derart, dass jedem Knoten ein Alias zugeordnet ist oder wird, welcher Aufschluss über eine topologisch-hierarchische Position des Knotens in dem Ethernet-Netzwerk gibt, so dass sich ein deterministischer, regelbasierter Datenfluss im Ethernet-Netzwerk bei reduzierter Multicast-Last ergibt. Bei der Zuweisung jeweils eines Alias an jeden Netzwerkknoten ist ferner vorgesehen, dass einem der Knoten entsprechend seiner topologisch-hierarchischen Position ein Alias zugeordnet ist oder wird, welcher ihn als Wurzelknoten ausweist.
  • Die oder jede Regel ergänzt dann eine auf die Topologie und jeden davon abgeleiteten Alias abgestellte Weiterleitungsstrategie, die weiter unten noch separat erwähnt wird.
  • Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Dabei verwendete Rückbeziehungen weisen auf die weitere Ausbildung des Gegenstandes des Hauptanspruches durch die Merkmale des jeweiligen Unteranspruches hin; sie sind nicht als ein Verzicht auf die Erzielung eines selbständigen, gegenständlichen Schutzes für die Merkmalskombinationen der rückbezogenen Unteransprüche zu verstehen. Des Weiteren ist im Hinblick auf eine Auslegung der Ansprüche bei einer näheren Konkretisierung eines Merkmals in einem nachgeordneten Anspruch davon auszugehen, dass eine derartige Beschränkung in den jeweils vorangehenden Ansprüchen nicht vorhanden ist.
  • Bei einer Anwendung des in Anspruch 1 definierten Verfahrens ist bevorzugt vorgesehen, dass bei einer Mehrzahl von Knoten als Ziel – Primärziel, Sekundärziele – gleiche Telegramme an das Primärziel und jedes Sekundärziel zu einer Multicast-Sendung zusammengefasst werden, dass, wenn das Primärziel und jedes Sekundärziel auf einer dem Wurzelknoten zugewandten Seite der Quelle liegen, derjenige Knoten als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch kleinsten Alias aufweist oder, wenn das Primärziel und jedes Sekundärziel auf einer vom Wurzelknoten abgewandten Seite der Quelle liegen, derjenige Knoten als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch größten Alias aufweist, und dass als Pfad für die Multicast-Sendung eine entlang einer zwischen den Knoten bestehenden Verbindungen kürzesten Verbindung – Linie – zwischen Quelle und Primärziel verwendet wird. Eine Adresse des Primärziels ist also als Adresse für die Multicast-Sendung verwendbar. Aufgrund der auf die Netzwerktopologie abgestellten Bildung von Alias-Adressen ist sichergestellt, dass die Multicast-Sendung neben dem Primärziel auch das oder jedes Sekundärziel erreicht.
  • Besonders bevorzugt ist vorgesehen, dass, wenn das oder jedes Sekundärziel auf der Linie liegt, die Anwendung einer ersten Regel erfolgt, die besagt, dass die Multicast-Sendung mit dem Primärziel als Zielangabe in das Ethernet-Netzwerk gegeben wird und für alle Knoten zwischen Quelle und Primärziel abgreifbar ist.
  • Weiter bevorzugt ist für Netzwerke, bei denen jeder Knoten zumindest einen ersten, zweiten und dritten Ein- und Ausgangsport (Port) umfasst, von denen zwei Bestandteil der Linie einer Multicast-Sendung zu einem Primärziel sind, dass, wenn mindestens ein Sekundärziel nicht auf der Linie liegt, eine hierarchisch nachgeordnete Regel angewendet wird, die besagt, dass die Multicast-Sendung von jedem Knoten entlang der Linie auch über dessen zweiten Port weitergeleitet wird. Auf diese Weise werden ohne unverhältnismässige „Uberflutung des Netzwerks auf Knoten für Multicast-Sendungen erreichbar, die abseits einer Linie vom Sender zum Primärziel liegen.
  • Nochmals weiter bevorzugt ist vorgesehen, wenn mindestens ein Knoten nach wie vor nicht erreicht wird, dass eine nochmals hierarchisch nachgeordnete Regel zur Anwendung kommt, die besagt, dass die Multicast-Sendung von jedem Knoten entlang der Linie auch über dessen dritten Port weitergeleitet wird. Auf diese Weise werden bisher nicht erreichbare Knoten für Multicast-Sendungen erreichbar.
  • Die Erfindung betrifft auch eine Implementation des oben skizzierten und nachfolgend weiter beschriebenen Verfahrens oder seiner Ausgestaltungen und Software, Hardware und/oder Soft- und Hardware, also insbesondere ein Computerprogramm mit dem ein solches Verfahren implementiert wird. In diesem Zusammenhang betrifft die Erfindung auch einen Datenträger mit einem solchen Computerprogramm sowie ein Computersystem, insbesondere einen Netzwerkteilnehmer – insbesondere einen Netzwerkteilnehmer in einer Ausführung als Automatisierungsgerät –, auf dem solches ein Computerprogramm geladen ist.
  • Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnung näher erläutert. Einander entsprechende Gegenstände oder Elemente sind in allen Figuren mit den gleichen Bezugszeichen versehen.
  • Das oder jedes Ausführungsbeispiel ist nicht als Einschränkung der Erfindung zu verstehen. Vielmehr sind im Rahmen der vorliegenden Offenbarung zahlreiche Abänderungen und Modifikationen möglich, insbesondere solche Varianten und Kombinationen, die zum Beispiel durch Kombination oder Abwandlung von einzelnen in Verbindung mit den im allgemeinen oder speziellen Beschreibungsteil beschriebenen sowie in den Ansprüchen und/oder der Zeichnung enthaltenen Merkmalen bzw. Elementen oder Verfahrensschritten für den Fachmann im Hinblick auf die Lösung der Aufgabe entnehmbar sind und durch kombinierbare Merkmale zu einem neuen Gegenstand oder zu neuen Verfahrensschritten bzw. Verfahrensschrittfolgen führen.
  • Darin zeigen
  • 1 eine schematisch vereinfachte Darstellung eines z. B. ein Automatisierungssystem repräsentierenden Netzwerks mit davon als Netzwerkteilnehmern umfassten Knoten und dazwischen als Links bestehenden Kommunikationsverbindungen,
  • 2 und 3 unterschiedliche Kommunikationsszenarien, bei denen der Ansatz gemäß der Erfindung zum Einsatz kommen kann.
  • 1 zeigt ein Ethernet-Netzwerk (Netzwerk) 10 mit einer Mehrzahl von im Folgenden kurz als Knoten 12 bezeichneten Netwerkteilnehmern, wobei in der Darstellung aus Gründen der Übersichtlichkeit nicht alle Knoten 12 mit dem entsprechenden Bezugszeichen gekennzeichnet sind.
  • Als Knoten 12 kommen insbesondere Automatisierungsgeräte in Betracht, also Einrichtungen oder Systeme, neben z. B. Steuerungen, wie speicherprogrammierbaren Steuerungen, Prozessrechnern, (Industrie-)Computern und dergleichen auch Antriebssteuerungen, Frequenzumrichter und Ähnliches, wie sie zur Steuerung, Regelung und/oder Überwachung technologischer Prozesse z. B. zum Umformen oder Transportieren von Material, Energie oder Information etc. eingesetzt werden oder einsetzbar sind, wobei insbesondere über geeignete technische Einrichtungen, wie z. B. Sensoren oder Aktoren, Energie aufgewandt oder gewandelt wird.
  • Jeder Knoten 12 umfasst, wie in 1 rechts unten dargestellt ist, zumindest einen ersten, zweiten und dritten Ein- und Ausgangsport (Port) 14, 16, 18. Über den ersten und zweiten Port 14, 16 kann eine Verbindung zu anderen Knoten 12 innerhalb einer hierarchisch gleichen Linie einer Topologie des Netzwerks 10 bestehen. Über den dritten und ggf. weitere Ports 18 kann eine Anbindung an andere Knoten 12 in einer hierarchisch untergeordneten Linie der Netzwerktopologie bestehen, wobei ein Anschluss eines Knotens 12 an einen dritten oder weiteren Port 18 eines vorangehenden Knotens 12 über dessen ersten Port 14 erfolgt. Die mindestens drei Ports 1216 eines Knotens 12 werden also exklusiv einzelnen Hierarchieebenen innerhalb des Ethernet-Netzwerks 10 zugeordnet. Bei Knoten 12, die Bestandteil des Netzwerks 10 sind, ist also zumindest der erste Port 14 für eine Einbindung in das Netzwerk 10 benutzt. Knoten 12, bei denen nur der erste Port 14 benutzt ist, werden als „Blatt” bezeichnet. Knoten, bei denen nur der erste und zweite Port 14, 16 benutzt ist, werden als Zwischenknoten oder „Intermediate” und Knoten 12, bei denen erster, zweiter und dritter Port 1418 benutzt sind, als Verzweigungsknoten oder kurz als Verzweigung bezeichnet. Im Weiteren wird darüber hinaus der erste Port 14 zur Unterscheidung als Primärport 14 bezeichnet. Der Primärport 14 ist bei jedem Knoten 12 derjenige Port, der in der Netzwerktopologie einem Wurzelknoten 20 zugewandt ist.
  • Jedem Knoten 12 ist ein eindeutiger Alias zugewiesen, der sich aus folgendem Bildungsschema ergibt: Ausgehend vom Wurzelknoten 20 wird in einem ersten Zuweisungsabschnitt für alle Knoten 12, die mit dem Wurzelknoten 20 in einer hierarchisch gleichen Linie verbunden sind, ein eine erste Ebene der Kommunikationsverbindungen in dem Netzwerk 10 bezeichnender Bestandteil des jeweiligen Alias mit einem zunehmenden Abstand vom Wurzelknoten 20 erhöht. Wenn also z. B. für den Wurzelknoten 20 als Alias die Ziffer oder der String „1” vorgesehen ist, ergibt sich für einen dem Wurzelknoten 20 benachbarten Knoten 12 ein Alias, der im Vergleich zu dem Alias des Wurzelknotens 20 erhöht ist, also z. B. „2”. Für weitere nachfolgende Knoten 12, also mit zunehmenden Abstand vom Wurzelknoten 20, ergibt sich jeweils ein Alias der im Vergleich zum Alias des entlang der gleichen Linie vorangehenden Knotens 12 erhöht ist. Die Erhöhung des numerischen Wertes des Alias muss nicht notwendig in Inkrementen von Eins erfolgen, sondern kann auch den tatsächlichen räumlichen Abstand reflektieren.
  • In einem zweiten Zuweisungsabschnitt wird für alle auf diese Weise erreichten Knoten 12, mit denen über deren dritten Port 18 mittel- oder unmittelbar zumindest ein weiterer Knoten 12 verbunden ist, für diesen verbundenen Knoten 12 ein Alias vergeben. Dieser wird aus dem Alias des hierarchisch übergeordneten Knotens 12 durch Hinzufügung eines eine hierarchisch untergeordnete Ebene der Kommunikationsverbindungen in dem Netzwerk 10 bezeichnenden Bestandteils gebildet, also z. B. für einen Knoten 12, der einem Knoten 12 mit dem Alias „3” unmittelbar nachfolgt, der Alias „3.1”.
  • Für alle Knoten 12, denen gemäß dem obigen zweiten Zuweisungsabschnitt ein Alias zugewiesen wurde, werden schließlich in einem dritten Zuweisungsabschnitt der erste und der zweite Zuweisungsabschnitt wiederholt, wobei der jeweilige Knoten 12 an die Stelle des Wurzelknotens 20 und die jeweilige hierarchische Ebene an die Stelle der ersten Ebene der Kommunikationsverbindungen tritt. Insoweit handelt es sich also um ein rekursives Bildungsschema, das am Ende der Rekursion alle Knoten 12 erfasst hat, so dass in dem Netzwerk 10 jedem Knoten 12 ein eindeutiger Alias zugewiesen ist, der Aufschluss über eine topologisch-hierarchische Position des Knotens 12 gibt und der es ermöglicht, Telegramme auch in der Sonderform als Multicast-Sendungen in der hier beschriebenen effizienten Art und Weise weiterzuleiten.
  • Zurückkommend auf die obige Benennung einzelner Knoten 12 entsprechend ihrer Position im Netzwerk 10 sind z. B. die Knoten 12 mit dem Alias „2.2.2”, „3.4.2” und „3.6” Blätter. Die Knoten 12 mit dem Alias „2.1”, „3.2.1” und „4.2.2” sind Intermediates oder Zwischenknoten und die Knoten mit dem Alias „3”, „3.3” und „4.2” sind Verzweigungen.
  • Das Netzwerk 10 kann insgesamt als „Baum” aufgefasst werden mit dem Wurzelknoten 20 als Ursprung. Des Weiteren kann in dem Netzwerk 10 jeder Knoten 12 mit evtl. an dessen zweiten und dritten Port 16, 18 angeschlossenen Nachfolgern als Teilbaum aufgefasst werden. In einem solchen Teilbaum bildet derjenige Knoten 12, der innerhalb des Teilbaums keine Verbindung über dessen Primärport 14 zu einem anderen Knoten 12 des Teilbaums hat, den Wurzelknoten des Teilbaums. In der Darstellung in 1 ist z. B. der Teilbaum des Knotens 12 mit dem Alias „2” das gesamte Netzwerk 10 ohne den Wurzelknoten 20. Der Teilbaum des Knotens 12 mit dem Alias „3” ist das gesamte Netzwerk 10 ohne den Wurzelknoten 20 und ohne den Knoten 12 mit dem Alias „2” sowie dessen an seinem dritten Port 18 angeschlossenen Nachfolgern usw.
  • Beim Empfang eines Telegramms zur Weiterleitung an andere Knoten wird ein eigener Alias mit einem von dem empfangenen Telegramm umfassten Alias eines Zielknotens – Zielalias – verglichen und in Abhängigkeit vom Ergebnis des Vergleichs das Telegramm über den ersten, zweiten oder dritten Port 1418 weitergeleitet. Dabei wird das Telegramm über den Primärport 14 weitergeleitet, wenn ein die eigene Ebene des jeweiligen Knotens 12 bezeichnender Bestandteil des eigenen Alias – relevanter eigener Aliasabschnitt – und ein entsprechender Bestandteil des Zielalias – relevanter Zielaliasabschnitt – in dieser Reihenfolge einer „kleiner gleich” Relation genügen. Ist diese Bedingung nicht erfüllt, besteht noch die Möglichkeit, dass das Telegramm über den zweiten Port 16 weitergeleitet wird, wenn der relevante eigene Aliasabschnitt und der relevante Zielaliasabschnitt in dieser Reihenfolge einer „größer gleich” Relation genügen. Ist auch diese Bedingung nicht erfüllt, besteht abschließend die Möglichkeit, dass das Telegramm über den dritten Port 18 weitergeleitet wird, wenn der relevante eigene Aliasabschnitt und der relevante Zielaliasabschnitt einer „ist gleich” Relation genügen. Für weitere Details wird auf die ältere Anmeldung mit dem Titel „Netzwerkkomponente, Verfahren zum Betrieb einer solchen Netzwerkkomponente, Automatisierungssystem mit einer solchen Netzwerkkomponente, Verfahren zur Datenübermittlung in einem Automatisierungssystem unter Verwendung einer solchen Netzwerkkomponente sowie korrespondierendes Computerprogramm und Computerprogrammprodukt” verwiesen ( WO 2008/092805 A ), auf die im Folgenden als Weiterleitungsstrategie Bezug genommen wird und deren vollständiger Offenbarungsgehalt als in diese Anmeldung einbezogen gelten soll.
  • Wenn von einem Knoten 12 als Quelle ein und dasselbe Telegramm an eine Mehrzahl anderer Knoten 12 als Ziel gesendet werden soll, empfiehlt sich eine einmalige Sendung dieses Telegramms in einer Form, die dessen Empfang bei jedem als Ziel vorgesehenen Knoten 12 erlaubt, also ein Versand als Multicast-Sendung. Der Begriff Telegramm wird hier und im Folgenden als Oberbegriff für alle in der Fachwelt geläufigen Bezeichnungen für in einem Netzwerk 10 zu übermittelnde Sendungen verwendet. Insoweit umfasst der Begriff Telegramm auch Begriffe wie Frame, Datagramm, Datenpaket, usw.
  • Es ist leicht vorstellbar, dass eine triviale Lösung für die Organisation von Multicast-Sendungen darin besteht, dass jede Multicast-Sendung an alle Knoten 12 eines Netzwerks 10 gerichtet wird. Dies führt jedoch zu einer unerwünscht hohen Belastung „zentraler Kommunikationsverbindungen”, z. B. Kommunikationsverbindungen (Links) die zwischen großen Teilbäumen, also Teilbäumen mit einer hohen Knotenzahl, bestehen. In der Darstellung in 1 sind die Links zwischen den Knoten 12 mit dem Alias „2” und „3” oder zwischen dem Wurzelknoten 20 und dem Knoten 12 mit dem Alias „2” solche zentralen Kommunikationsverbindungen. Die Belastung dieser und anderer ähnlich zentraler Links ist vor allem deswegen unerwünscht, weil während der Übermittlung einer Multicast-Sendung die Links nicht für andere Telegramme verwendbar sind, so dass sich pro Zeiteinheit die Menge übermittelbarer Nutzdaten (Telegramminhalte) reduziert.
  • Die Erfindung schlägt zur Vermeidung dieses Problems oder zur Reduzierung der oben oder eingangs skizzierten Nachteile vor, dass ein Satz vorab definierter, hierarchisch organisierter Regeln bereitgestellt wird, mittels welcher in dem jeweiligen Netzwerk 10 ein Datenfluss von einem Netzwerkteilnehmer/Knoten 12 als Quelle zu einem oder mehreren anderen Netzwerkteilnehmern/Knoten 12 als Ziel (Primärziel, Sekundärziel(e)) geleitet wird, wobei die Regeln auf die jeweilige Netzwerktopologie abgestellt sind, in der jedem Knoten 12 ein Alias zugeordnet ist oder wird, welcher Aufschluss über dessen topologisch-hierarchische Position in dem Netzwerk 10 gibt, so dass sich ein deterministischer, regelbasierter Datenfluss im Netzwerk 12 bei reduzierter Multicast-Last ergibt.
  • An einem solchen Datenfluss sind auf einer hierarchisch vergleichsweise niedrigen Ebene Funktionseinheiten beteiligt, die normalerweise von jedem Knoten 12 umfasst sind und die im eigentlichen Sinne dessen Einbindung in das Netzwerk 10 erlauben. Diese Funktionseinheiten werden üblicherweise als „Switch” bezeichnet. Hier und im Folgenden wird nicht zwischen dem jeweiligen Netzwerkteilnehmer und dem davon umfassten Switch unterschieden, da es auf die konkrete Funktionalität des Netzwerkteilnehmers/Knotens, z. B. als speicherprogrammierbare Steuerung, dezentrales Peripheriegerät, usw., nicht ankommt. Insoweit schließt hier und im Folgenden jede Verwendung des Begriffs „Knoten” 12 die Bezugnahme auch auf solche Funktionseinheiten, also insbesondere Switches, ein.
  • Die der Erfindung zugrunde liegende Topologie des Netzwerks 10, also die durch den jedem Knoten 12 zugeordneten Alias zum Ausdruck kommende topologisch-hierarchische Position des Knotens 12 in dem Netzwerk 10, erlaubt ein sehr schnelles Weiterleiten von Telegrammen zwischen jeweiliger Quelle und jeweiligem Ziel. Um die Optimierung zur Begrenzung der Multicast-Last durchzuführen, sollten für Multicast-Sendungen verwendete Adressen (Multicast-Adressen) möglichst keine oder sehr wenig Protokollinformationen enthalten. Im einfachsten Fall ist eine Multicast-Adresse eine Unicast-Adresse, die um eine Information, z. B. ein Flag, ergänzt ist, an der die Switches erkennen, dass es sich um eine Multicast-Sendung handelt, die also nicht nur für den durch die Adresse kodierten Knoten 12 bestimmt ist.
  • Die Optimierungs-Ziele sind:
    • – keine Projektierung der Switches
    • – Nutzung von nicht benötigten Links nur in Ausnahmefällen
    • – wenige angesprochene Knoten, die die Multicast-Sendung nicht benötigen.
  • In der Praxis ergibt sich häufig die Notwendigkeit eine Mehrzahl von Knoten 12 anzusprechen, die sich in räumlicher Nähe zu einem zu einem bestimmten Zeitpunkt als Multicast-Sender fungierenden Knoten 12 befinden. Nur in Ausnahmefällen ist eine Übermittlung auch an „weiter entfernte” Knoten 12 erforderlich. In räumlicher Nähe zum Sender befindliche Knoten 12 sind solche Knoten 12, die sich mit dem Sender in einem vergleichsweise kleinen Teilbaum des Netzwerks 10 befinden, also einem Teilbaum, der nur wenige Knoten 12 umfasst. Beim Einschluss weiter entfernter Knoten 12 ergeben sich umfangreichere Teilbäume, die speziell dann, wenn eine Benutzung von Links auf einer obersten Hierarchieebene notwendig wird, also der Ebene, die den Wurzelknoten 20 umfasst, schnell Ausmaße annehmen, die denen des gesamten Netzwerks 10 entsprechen.
  • Der Erfindung liegt die Erkenntnis zugrunde, dass mit topologischen Adressen und dem darauf basierenden Weiterleitungsschema eine Menge von Knoten 12 auf einfache Weise erreicht werden kann.
  • Im einfachsten Fall wird ein Knoten 12 als Ziel adressiert und alle Knoten 12 oder Stationen auf dem Weg zwischen Quelle und Ziel können die Daten abgreifen. Das wäre, wenn ein als Linie 22 (2) bezeichneter kürzester Weg zwischen Quelle und dem oder jedem Ziel keine Verzweigungen umfasst, insbesondere wenn Quelle und alle Ziele zu der gleichen Hierarchieebene gehören, schon die Lösung für Multicast. Bei einem solchen Szenario ist immer ein Gebiet zwischen Quelle und letztem Ziel betroffen. Die jeweilige Multicast-Sendung kann also an das letzte Ziel gerichtet werden (ein Multicast an die entsprechende Adresse des letzten Knotens 12 mit Group Address und Locally administered auf „1”). 2 illustriert dieses Szenario und die Grenzen.
  • In 2 sind zur Verbesserung der Übersichtlichkeit nur einzelne Bezugszeichen eingezeichnet. Insoweit wird auf 1 verwiesen. Des Weiteren werden als Sender (Quelle) einerseits oder als Empfänger oder Abnehmer (Primärziel bzw. Sekundärziel) andererseits fungierende Knoten 12 mit graphischen Symbolen – Sender: „(*)”; Primärziel: „(x)” und Sekundärziel – bezeichnet und in der nachfolgenden textuellen Beschreibung durch den dem jeweiligen Knoten 12 zugeordneten Alias referenziert.
  • Ein besonders einfaches Szenario besteht darin, dass der Knoten 12 mit dem Alias „2.4” gleiche Telegramme an die Knoten 12 mit dem Alias „2.4.1” und „2.4.2” zu senden hat. Dies kann in einer Multicast-Sendung erfolgen. Dazu wird zunächst das „letzte Ziel” ermittelt. Dazu kann der jeweilige Alias der Zielknoten herangezogen werden, der gemäß Voraussetzung „Aufschluss über eine topologisch-hierarchische Position des jeweiligen Knotens 12 in dem Netzwerk 10 gibt”. Im gewählten Beispielfall ist ersichtlich der Knoten 12 mit dem Alias „2.4.2” der letzte Knoten, also das Primärziel. Dessen Adresse (oder dessen Alias) wird als Adresse der Multicast-Sendung verwendet. Die oben erwähnte Weiterleitungsstrategie bewirkt, dass die Weiterleitung genau entlang der zu diesem Szenario eingezeichneten Linie 22 erfolgt. Alle zwischen Quelle und letztem Knoten 12 liegenden Knoten 12 können die Multicast-Sendung abgreifen. Die Multicast-Sendung ist damit auch für den Abnehmer „2.4.1” als Sekundärziel erreichbar.
  • Ein ähnliches, nicht separat dargestelltes Szenario ergäbe sich bei dem Knoten „4.2.4” als Sender und den Knoten „4.2.2” und „4.2” als Ziel. Hier ist der letzte Knoten, diesmal – anders als im vorangehenden Beispiel – in Richtung auf den Wurzelknoten 20 zu ermitteln, der Knoten 12 mit dem Alias „4.2”. Eine an diesen Knoten 12 als Primärziel adressierte Multicast-Sendung vom Knoten „4.2.4” ist auch für den Abnehmer „4.2.2” als Sekundärziel abgreifbar.
  • Bei einer Sendung, die vom Knoten „4.2.4” an die Knoten „3”, „4.1” und „4.2.2” zu richten ist, gilt grundsätzlich das für das vorangehende, nicht dargestellte Beispiel Gesagte. Die Besonderheit besteht darin, dass Quelle und das oder jedes Ziel (der oder jeder Abnehmer) zwar nicht zu der gleichen Hierarchieebene des Netzwerks 10 gehören, die Linie 22 zum letzten Ziel (Primärziel) aber keine Verzweigungen umfasst (der Knoten „4.2” stellt zwar grundsätzlich eine Verzweigung dar, diese Verzweigung wird aber für die Linie 22 nicht benötigt, so dass es insgesamt berechtigt ist, die Linie 22 als verzweigungsfrei zu bezeichnen).
  • Für solche Szenarien ist zur Begrenzung der Multicast-Last ein Verfahren verwendbar, bei dem bei einer Mehrzahl von Knoten 12 als Ziel, also als Primär- oder Sekundärziel, gleiche Telegramme an das Primärziel und jedes Sekundärziel zu einer Multicast-Sendung zusammengefasst werden, wobei, wenn das Primärziel und jedes Sekundärziel auf einer dem Wurzelknoten 20 zugewandten Seite der Quelle liegen, derjenige Knoten 12 als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch kleinsten Alias aufweist oder, wenn das Primärziel und jedes Sekundärziel auf einer vom Wurzelknoten 20 abgewandten Seite der Quelle liegen, derjenige Knoten 12 als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch größten Alias aufweist, und wobei als Linie 22 für die Multicast-Sendung eine entlang der zwischen den Knoten 12 bestehenden Verbindungen kürzeste Verbindung zwischen Quelle und Primärziel verwendet wird.
  • Als eine erste Regel in einem Satz vorab definierter, hierarchisch organisierter Regeln, mittels welcher im Netzwerk 10 ein Datenfluss von einem Knoten 12 als Quelle zu einem oder mehreren anderen Knoten 12 als Ziel – Primärziel, Sekundärziel(e) – geleitet wird, so dass sich ein deterministischer, regelbasierter Datenfluss im Netzwerk 10 bei reduzierter Multicast-Last ergibt, ist entsprechend vorgesehen, dass, wenn das oder jedes Sekundärziel auf der Linie 22 liegt, die Multicast-Sendung mit dem Primärziel als Zielangabe in das Ethernet-Netzwerk 10 gegeben wird und für alle Knoten 12 zwischen Quelle und Primärziel abgreifbar ist. Kurz wird diese Regel im Folgenden als „MCL” für „Multicast, along the Line” bezeichnet.
  • Ein anderes Szenario ergibt sich, wenn keine verzweigungsfreie Linie 22 möglich ist, also z. B. wenn vom Knoten 12 mit dem Alias „3.4.2” Sendungen an die Knoten 12 mit dem Alias „3.2.2” und „3.3.1” zu richten sind. Das Sekundärziel (der Knoten „3.3.1”) liegt dann nicht auf einer Linie 22 zwischen Sender (Knoten „3.4.2”) und Primärziel (Knoten „3.2.2”).
  • In verzweigten Systemen ist die o. g. erste Regel damit nicht ausreichend, weil bei einer Gabelung auch die Multicasts auseinander laufen müssten, was auf Basis der Weiterleitungsstrategie und nur mit Anwendung der ersten Regel nicht vorgesehen ist. Das sich dadurch ergebende Problem kann aber gelöst werden, indem eine zweite Regel hinzugefügt wird, die besagt, dass auch entlang der Linie 22 befindliche Verzweigungen „geflutet” werden dürfen. Für das angenommene Szenario gilt dabei, dass der Knoten 12 mit dem Alias „3.4” zwar mit dessen drittem Port 18 grundsätzlich eine Verzweigung darstellt, dass dieser dritte Port 18 aber entsprechend der Weiterleitungsstrategie nicht verwendet wird und damit der betreffende Knoten 12 insgesamt für diese Linie 22 nicht als Verzweigung in Erscheinung tritt. Entsprechendes gilt analog für den Knoten 12 mit dem Alias „3.2”. Für jeden anderen auf der Linie 22 liegenden Knoten 12, bei dem über alle drei Ports 1418 Links zu anderen Knoten 12 bestehen (im dargestellten Fall nur für den Knoten 12 mit dem Alias „3.3”), gilt entsprechend der zweiten Regel und in Ergänzung der Weiterleitungsstrategie, dass das die Multicast-Sendung bildende Telegramm auch über dessen zweiten Port 16 und an daran unmittelbar oder mittelbar angeschlossene Knoten 12 weitergeleitet wird. Zur Unterscheidung von der Linie 22 werden Links und Knoten 12, die sich nach einer solchen Verzweigung an den jeweiligen zweiten Port 16 anschließen, als Pfad oder Branch 24 bezeichnet. Die der o. g. ersten Regel hierarchisch nachgeordnete zweite Regel ergänzt also die Weiterleitungsstrategie derart, dass die Multicast-Sendung von jedem Knoten 12 entlang der Linie 22 auch über dessen zweiten Port 16 weitergeleitet wird, dass also auch Branches 24 benutzt werden. Wenn also ohne die zweite Regel eine Weiterleitung eines Telegramms nur in Betracht kommt, wenn der relevante Aliasabschnitt eines entlang der Linie 22 liegenden Knotens 12 und der relevante Zielaliasabschnitt des als Primärziels angegebenen Knotens 12 in dieser Reihenfolge einer „größer gleich” Relation genügen, erfolgt bei einer Markierung des Telegramms sowohl als Multicast-Sendung als auch bei Gültigkeit der zweiten Regel (also einer diesbezüglichen zusätzlichen Markierung) stets auch eine Weiterleitung des Telegramms über jeden von der Linie 22 berührten zweiten Port 18, sofern dieser nicht ohnehin Bestandteil des Pfades ist. Kurz wird diese Regel im Folgenden als „MCB” für „Multicast mit Verwendung aller Branches zwischen Quelle und Primärziel” („Multicast, use all Branches between Source and Destination”) bezeichnet.
  • Dadurch werden alle Knoten 12 erreicht, die an der Linie 22 von der Quelle zum Primärziel liegen, so dass die Multicast-Sendung auch für evtl. hinter Verzweigungen befindliche Sekundärziele abgreifbar ist. Der Effekt der Anwendung der zweiten Regel wird als „Fluten von Subsegmenten” bezeichnet. Allerdings werden bei Anwendung der zweiten Regel auch solche Subsegmente geflutet, in denen sich keine Abnehmer der Multicast-Sendung befinden. Ein Beispiel für ein solches Szenario ist eine Multicast-Sendung, die bei der in 2 dargestellten Netzwerktopologie vom Knoten „3.5.1” als Sender an die Abnehmer „3.2.1” und „3.4.2” gerichtet ist. Der Knoten 12 mit dem Alias „3.2.1” ergibt sich als Primärziel. Die Anwendung der zweiten Regel führt dazu, dass das Subsegment mit dem Knoten „3.4.2” geflutet wird, so dass der vorgesehene Abnehmer die Multicast-Sendung abgreifen kann. Unnötig wird allerdings auch das vom Knoten „3.3” über dessen zweiten Port 16 ausgehende Subsegment geflutet, in dem sich keine Abnehmer befinden. Da aber Subsegmente in der Regel weniger belastet sind als Hauptsegmente, ist dieser Overhead häufig akzeptierbar.
  • Durch die Anwendbarkeit der zweiten Regel ist die Möglichkeit, aus der Mitte eines Teilbaums den gesamten Teilbaum zu erreichen (wenn sich mindestens ein Abnehmer nicht auf dem Hauptsegment des jeweiligen Teilbaumes befindet) noch nicht abgedeckt. Abhilfe für diese Situation ist, dass entsprechend einer dritten Regel auch eine Flutung entlang jedes dritten Ports 18 erlaubt ist. Zur Unterscheidung von Linie 22 und Pfad 24 werden Links und Knoten 12, die sich nach einer Verzweigung an den jeweiligen dritten Port 18 anschließen, als Sekundärpfad 26 (3) oder Secondary 24 bezeichnet. Kurz wird diese Regel im Folgenden als „MCBS” für „Multicast mit Verwendung aller Pfade/Branches und Sekundärpfade zwischen Quelle und Primärziel” („Multicast, use all Branches and Secondary between Source and Destination”) bezeichnet.
  • Ein Beispiel für eine solche Situation ist in 3 dargestellt, wobei auch für 3, ähnlich wie oben bereits für 2 erwähnt, gilt, dass aus Gründen der Übersichtlichkeit nicht alle Knoten 12 mit dem entsprechenden Bezugszeichen gekennzeichnet sind. Das in 3 dargestellte Szenario geht von dem Knoten 12 mit dem Alias „3.4.2” als Sender aus. Abnehmer einer von diesem abzusetzender Multicast-Sendung sind die Knoten 12 mit dem Alias „3.2.2”, „3.3.1” und „3.5.1”. Unter diesen Abnehmern ergibt sich der Knoten 12 mit dem Alias „3.2.2” als Primärziel. Die Linie 22 verbindet Sender und Primärziel. Die Linie umfasst nicht das Sekundärziel „3.3.1”, das bei Anwendung der zweiten Regel (MCB) durch Flutung der entlang der Linie 22 bestehenden Branches 24 erreicht wird, und nicht das Sekundärziel „3.5.1”, das bei Anwendung der dritten Regel (MCBS) durch Flutung der entlang der Linie 22 bestehenden Sekundärpfade 24 erreicht wird.
  • Problematisch sind die Methoden der Flutung (MCB, MCBS) nur, wenn die Multicast-Sendung stark frequentierte Abschnitte durchläuft. Dies sind fast immer die Hauptsegmente des Netzwerks („Level 1”), also Links in der gleichen Ebene wie der Wurzelknoten 20. In einer Konstellation, bei der z. B. der Wurzelknoten 20 und ein Teilbaum in einem abgelegenen Segment betroffen sind, kann die (unkontrollierte) Flutung unerwünscht sein. Auch auf einer ersten Subebene des Netzwerks 10 („Level 2”) besteht noch eine gewisse Gefahr der Überflutung, wenn hier viele Stationen/Knoten 12 angeordnet sind.
  • Ausgehend von den vorangehend erläuterten drei Regeln (MCL, MCB, MCBS) besteht eine Erkenntnis, die den Erfinder zu einer vorteilhaften Ausführungsform der Erfindung geführt hat, darin, dass mit einem Satz von sieben verschiedenen Regeln der Multicastverkehr sehr gut zu lenken ist. Die Regeln sind recht einfach, sie lassen sich auch entsprechend aufwandsarm in den Knoten 12, genauer in den davon umfassten Switches, implementieren.
  • Gemäß dieser vorteilhaften Ausführungsform ist eine Implementierung folgender Regeln in einem topologiebasierten Ansatz vorgesehen:
  • MCL
    Erste Regel – ”Along the line”
    MCB
    Zweite Regel – ”Use all Branches between Source and Destination”
    MCBS
    Dritte Regel – ”Use all Branches and Secondary between Source and Destination”
    MCBx1
    Vierte Regel – ”Use all Branches between Source and Destination (not at Level 1)”
    MCBSx1
    Fünfte Regel – ”Use all Branches and Secondary between Source and Destination (not at Level 1)”
    MCBx12
    Sechste Regel – ”Use all Branches between Source and Destination (not at Level 1 and 2)”
    MCBSx12
    Siebente Regel – ”Use all Branches and Secondary between Source and Destination (not at Level 1 and 2)”
  • In einer weiteren, vorteilhaften Ausführungsform der Erfindung ist dann zur Auswahl jeweils genau einer der vorgenannten sieben Regeln ein inkrementeller Ansatz vorgesehen (hier ohne die Multicast-Optimierung auf den Hauptsegmenten angegeben):
    • – eine erste Verbindung zum Primärziel wird mit Hilfe des Linien-Multicasts (MCL) etabliert
    • – Hinzufügen nach folgender Strategie:
    • • MCL bleibt, wenn das oder jedes Sekundärziel auf der Linie 22 zum Primärziel oder in deren Verlängerung liegt, ansonsten MCB, wenn das Sekundärziel an einer von der Linie 22 nicht erreichten Stelle im jeweiligen Teilbaum oder in dessen Verlängerung liegt, ansonsten MCBS
    • • MCB bleibt, wenn das oder jedes Sekundärziel zu dem durch das Primärziel festgelegten Teilbaum oder dessen Verlängerung gehört, ansonsten MCBS
    • • MCBS bleibt immer unverändert
  • Dieses Auswahlverfahren kann prinzipiell auch die Multicast Regeln auf dem Hauptsegment mit einbeziehen. Dabei müssen alle zu erreichenden Knoten in einem von drei Teilbäumen liegen:
    • • Dem Teilbaum zwischen Quelle und einleitendem Knoten ins Hauptsegment
    • • Der Verbindung zwischen einleitendem und ausleitendem Knoten im Hauptsegment
    • • Dem Teilbaum zwischen ausleitendem Knoten aus dem Hauptsegment und Ziel
  • Wenn alle zu erreichenden Knoten in einem der drei Teilbäume liegen, dann kann die MCBx1 oder MCBSx1 Regel angewandt werden.
  • Ein Algorithmus, mit dem das beschriebene Auswahlverfahren, evtl. inklusive hier ebenfalls beschriebener bevorzugter Ausführungsformen, implementiert wird, kann entweder offline bei der Projektierung oder online bei der Anmeldung eines Knotens 12 als Multicastkonsument oder Multicast-Subscriber zur Anwendung kommen.
  • Auch das Thema Untersetzung von Zyklen kann mit dem hier vorgestellen Verfahren gelöst werden. Wenn ein Teilnehmer z. B. nur in jedem vierten Kommunikationszyklus angesprochen werden soll und sonst nur Nachbarn, dann kann dies dadurch gelöst werden, indem zwei Multicast-Adressen präpariert werden, die entsprechend gewechselt werden. Auf diese Art kann man mit einer einfachen Datenhaltung (die Prozessdaten müssen nur einmal der Kommunikation zur Verfügung gestellt werden) ein sehr flexibles Kommunikationsschema implementieren.
  • Insgesamt ergeben sich mit der Erfindung und ihrer Ausgestaltungen insbesondere die nachfolgend beschriebenen Vorteile: Es gibt bei Multicast-Tabellen generell immer entweder ein Konfigurierungsproblem oder ein Belastungsproblem. Protokolle können helfen, setzen aber sofort eine recht große und vor allem recht unbestimmte Menge an Speicher für die Aufnahme von Multicast-Adressen voraus. Das Suchen in diesen Speichern ist meist sehr aufwändig, so dass das Weiterleiten viel Zeit verschlingt. Ohne eine Strukturierung der hier vorgeschlagenen Art bestehen kaum Möglichkeiten zur Optimierung. Bei dem hier vorgeschlagenen, strukturierten Ansatz lässt sich der Aufwand recht einfach reduzieren, indem Adressen ermittelt werden, die einen bestimmten Nachbarschaftsbereich ansprechen. Bei diesem Verfahren gibt es auch keine Bedenken, dass ab einer bestimmten Größe einer Anlage Anforderungen an eine Mächtigkeit der einzusetzenden Switches immer mehr zunehmen. Somit ist dieses Verfahren auch absolut zukunftssicher. Die Weiterleitungszeit ist zum Einen nicht abhängig von einer Vielzahl von Parametern. Zum Anderen hält sich der Umfang der vorkommenden Flutungen in Grenzen. In letzter Konsequenz kann das hier beschriebene Verfahren immer noch mit einer festen Weiterleitung zusammen genutzt werden, wobei der Aufwand erheblich sinkt, weil man jetzt nur einen ganz geringen Teil planen muss und der Rest automatisch bestimmt wird.
  • Eine besondere Leistung der Erfindung besteht darin, dass ein Verfahren angegeben wird, das Adressräume automatisch strukturiert und versucht, mit einer Adresse eine definierte Menge von Stationen zu erreichen. In der Multicast-Adresse enthalten sind Informationen, die eine gewisse Ausbreitung erlauben oder verhindern (Aktivierung einer der Regeln 2 bis 7). Dabei geht man davon aus, dass die Multicastbeziehungen in der Regel in einem lokalen Umfeld stattfinden. Auf diese Art ist es nicht mehr notwendig, die Weiterleitung explizit zu planen oder über aufwändige Protokolle abzusichern. Bereits durch die richtige Wahl der Zieladresse im jeweiligen Telegramm kann der geeignete Bereich definiert werden, der wiederum mit vertretbarem Aufwand gefunden wird. Da die Multicast-Adresse kein Selektionskriterium für die Empfängerstation ist, kann der Bereich auch dynamisch angepasst werden.
  • Spezialanwendungen, wie zum Beispiel das selektive untersetzte Senden, sind mit den üblichen Mitteln fast nicht zu bewerkstelligen, es sei denn, man installiert eine große Menge von Multicast-Adressen, mit einer entsprechenden Speicherbelastung sowie einem daraus folgenden Zeitaufwand für das Suchen.
  • Wichtig ist bei diesem Verfahren, dass man das Weiterleitungskriterium (Zieladresse) vom Empfangskriterium (Quelladresse und Zusatzinformation) trennt. Das Empfangen selbst kann nebenläufig organisiert werden und ist nicht Gegenstand dieser Abhandlung.
  • Das hier beschriebene Verfahren kann statt mit Ethernet-Adressen auch mit anderen topologie-basierten Adressen durchgeführt werden.
  • Es gibt auch noch Kriterien, die eine Weiterleitung einschränken oder ermöglichen, z. B. einzelne Ebenen von der Weiterleitung ausschließlich oder die Abzweigungen einzuschränken (wenn es beispielsweise rechte und linke Abzweigungen gibt, dann kann man das Fluten auf den rechten Teil einschränken. Das erscheint aus heutiger Sicht allerdings nicht sinnvoll).
  • Als praxisrelevantes Ausführungsbeispiel soll zumindest kurz ein einfaches und häufig anzutreffendes Szenario erwähnt werden, bei dem neben einem übergeordneten Knoten noch ein Nachbar angesprochen werden soll. Hier kann entweder Unicast oder MCL zur Anwendung kommen. Solche Situationen ergeben sich zum Beispiel bei Wicklungsvorgängen oder bei einer Positionieraufgabe im zweidimensionalen Raum mit einer sicherer zu steuernden Größe und einer leichter zu steuernden Größe. Sehr häufig ergeben sich solche Kommunikationsszenarien auch bei einer Schnellabschaltung eines Antriebs. Wenn die Sensoren in Bezug auf die Topologie des (Automatisierungs-)Netzwerks hinter dem Antrieb angeordnet sind, dann ergibt sich hier auch wieder die einfache Methode (wenn der Antrieb am Ende eines Teilbaums angeordnet ist, dann kann man hier fluten, wobei das Fluten auf dem Hauptsegment unterbunden wird).
  • Zusammenfassend lässt sich die Erfindung damit kurz wie folgt beschreiben: Es wird ein Verfahren angegeben, bei dem ein Satz von vorab definierten hierarchischen Regeln bereitgestellt wird, mittels welcher im Ethernet-Netzwerk ein Datenfluss von einer Quelle zu einem Ziel geleitet wird, wobei die Regeln von einer Topologie des Ethernet-Netzwerks abgeleitet sind, so dass sich ein deterministischer, regelbasierter Datenfluss im Ethernet-Netzwerk unter Minimierung der Multicast-Last ergibt.

Claims (6)

  1. Verfahren zur Begrenzung einer Multicast-Last bei einem Ethernet-Netzwerk (10) mit einer Mehrzahl von Knoten (12) als Netzwerkteilnehmer, – wobei jeder Knoten (12) zumindest einen ersten, zweiten und dritten Ein- und Ausgangsport – Port (14, 16, 18) – umfasst, – wobei über den ersten, zweiten und dritten Port (14, 16, 18) eine Verbindung zu anderen Knoten (12) bestehen kann und zwar über den ersten und zweiten Port (14, 16) zu anderen Knoten (12) innerhalb einer hierarchisch gleichen Linie des Netzwerks (10) und über den dritten Port (18) zu anderen Knoten (12) in einer hierarchisch untergeordneten Linie des Netzwerks (10), – wobei ein Satz vorab definierter, hierarchisch organisierter Regeln bereitgestellt wird, mittels welcher im Ethernet-Netzwerk (10) ein Datenfluss von einem Knoten (12) als Quelle zu einem oder mehreren anderen Knoten (12) als Ziel geleitet wird, – wobei die Regeln auf eine Topologie des Ethernet-Netzwerks (12) abgestellt sind, derart, dass jedem Knoten (12) ein Alias zugeordnet ist oder wird, welcher Aufschluss über eine topologisch-hierarchische Position des Knotens (12) in dem Ethernet-Netzwerk (10) gibt und dass einem der Knoten (12) entsprechend seiner topologisch-hierarchischen Position ein Alias zugeordnet ist oder wird, welcher ihn als Wurzelknoten (20) ausweist, so dass sich ein deterministischer, regelbasierter Datenfluss im Ethernet-Netzwerk (10) bei reduzierter Multicast-Last ergibt, – wobei bei einer Mehrzahl von Knoten (12) als Ziel – Primärziel, Sekundärziele – für den Datenfluss zum Primärziel und jedem Sekundärziel eine Multicast-Sendung verwendet wird, – wobei, wenn das Primärziel und jedes Sekundärziel auf einer dem Wurzelknoten (20) zugewandten Seite der Quelle liegen, derjenige Knoten (12) als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch kleinsten Alias aufweist oder wenn das Primärziel und jedes Sekundärziel auf einer vom Wurzelknoten (20) abgewandten Seite der Quelle liegen, derjenige Knoten (12) als Primärziel für die Multicast-Sendung verwendet wird, der den hierarchisch größten Alias aufweist, und – wobei als Pfad für die Multicast-Sendung eine entlang der zwischen den Knoten (12) bestehenden Verbindungen kürzeste Verbindung – Linie (22) – zwischen Quelle und Primärziel verwendet wird, – wobei, wenn das oder jedes Sekundärziel auf der Linie (22) liegt, als erste Regel vorgesehen ist, dass die Multicast-Sendung mit dem Primärziel als Zielangabe in das Ethernet-Netzwerk (10) gegeben wird und für alle Knoten (12) zwischen Quelle und Primärziel abgreifbar ist, – wobei, wenn mindestens ein Sekundärziel nicht auf der Linie (22) liegt, als hierarchisch nachgeordnete Regel vorgesehen ist, dass die Multicast-Sendung von jedem Knoten (12) entlang der Linie (22) auch über dessen zweiten Port (16) weitergeleitet wird, – wobei die Multicast-Sendung zur Anwendung der hierarchisch nachgeordneten Regel durch einzelne Knoten (12) mit einer die Gültigkeit der hierarchisch nachgeordneten Regel kodierenden Markierung versehen ist, – wobei die Verwendung einer hierarchisch nachgeordneten Regel alle Maßnahmen hierarchisch vorangehender Regeln erlaubt.
  2. Verfahren nach Anspruch 1, wobei, wenn mindestens ein Sekundärziel nicht auf der Linie (22) liegt, als hierarchisch nachgeordnete Regel vorgesehen ist, dass die Multicast-Sendung von jedem Knoten (12) entlang der Linie (22) auch über dessen dritten Port (18) weitergeleitet wird.
  3. Computerprogramm zur Ausführung eines Verfahrens gemäß einem der Ansprüche 1 bis 2.
  4. Datenträger mit einem Computerprogramm nach Anspruch 3.
  5. Computersystem auf dem ein Computerprogramm nach Anspruch 3 geladen ist.
  6. Computersystem nach Anspruch 5, welches als Netzwerkteilnehmer fungiert und als Automatisierungsgerät ausgeführt ist.
DE102007062739A 2007-09-14 2007-12-27 Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm Expired - Fee Related DE102007062739B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102007062739A DE102007062739B4 (de) 2007-09-14 2007-12-27 Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm
PCT/EP2008/060995 WO2009037067A1 (de) 2007-09-14 2008-08-22 Verfahren zur begrenzung der multicast-last bei einem ethernet-netzwerk, computerprogramm zur implementierung des verfahrens und computersystem mit einem solchen computerprogramm

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102007044081.4 2007-09-14
DE102007044081 2007-09-14
DE102007062739A DE102007062739B4 (de) 2007-09-14 2007-12-27 Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm

Publications (2)

Publication Number Publication Date
DE102007062739A1 DE102007062739A1 (de) 2009-03-19
DE102007062739B4 true DE102007062739B4 (de) 2013-01-17

Family

ID=40348696

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007062739A Expired - Fee Related DE102007062739B4 (de) 2007-09-14 2007-12-27 Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm

Country Status (2)

Country Link
DE (1) DE102007062739B4 (de)
WO (1) WO2009037067A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2663039B1 (de) * 2012-05-04 2018-06-27 Siemens Aktiengesellschaft Verfahren und vorrichtung zur zielgerichteten übertragung eines datenpakets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WU, Jie et al.: "Deadlock-Free Multicasting in Irregular Networks Using Prefix Routing", The Journal of Supercomputing, Bd. 31, Seiten 63-78, 2005, 2005 Springer Science + Business Media, Inc. Manufactured in The Netherlands *

Also Published As

Publication number Publication date
DE102007062739A1 (de) 2009-03-19
WO2009037067A1 (de) 2009-03-26

Similar Documents

Publication Publication Date Title
DE3888818T2 (de) Aufgeteilte Lastverteilung.
EP3522477B1 (de) Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
DE19833931C2 (de) Verfahren zum Übermitteln von Datenpaketen an mehrere Empfänger in einem heterogenen Kommunikationsnetz
EP2676409B1 (de) Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze
EP0700224A2 (de) Verfahren zur adaptiven Wegesuche in einem Kommunikationsnetz
DE102010011965A1 (de) Parallelbetrieb von RSTP (Rapid Spanning Tree Protocol) und MRP (Media Redundancy Protocol) und Segmentierung/Kopplung
EP0784894A1 (de) Verfahren und anordnung zur adressierung von teilnehmern in einem aus mindestens zwei segmenten bestehenden netzwerk
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
EP2955904B1 (de) Vergabe von netzwerkadressen für netzteilnehmer
WO2018162071A1 (de) Verfahren und vorrichtung zur modularen lenkung eines avb-streams
DE102005057122A1 (de) Netzwerk mit Redundanzeigenschaften, Ethernet-Switch für ein derartiges Netzwerk sowie Verfahren zur Konfiguration eines derartigen Netzwerks
EP2127241B1 (de) Zielportsuche in netzwerken aus gekoppelten teilnetzen
EP3018958A1 (de) Netzwerkanordnung und Verfahren zur Priorisierung von Echtzeittelegrammen in einem konvergenten Netzwerk
DE102014105207B4 (de) Verfahren zum Betreiben eines Kommunikationsnetzwerks und Kommunikationsnetzwerk
EP2119124A2 (de) Netzwerkkomponente, verfahren zum betrieb einer solchen netzwerkkomponente, automatisierungssystem mit einer solchen netzwerkkomponente, verfahren zur datenübermittlung in einem automatisierungssystem unter verwendung einer solchen netz-werkkomponente sowie korrespondierendes computerprogramm und computerprogrammprodukt
DE102004037024A1 (de) Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz
DE102007062739B4 (de) Verfahren zur Begrenzung der Multicast-Last bei einem Ethernet-Netzwerk, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm
DE102021122684A1 (de) Verfahren zum betreiben eines netzwerks
EP2933985B1 (de) Verwendung von Multicast DNS
DE69930495T2 (de) Verfahren zur Unterstützung von Abkürzungen in der Netzwerkebene
DE102008017192A1 (de) Verfahren zum Aufbau eines Netzwerks
DE10308953A1 (de) Kommunikation in einem Datennetz
DE10308954A1 (de) Übertragung von Daten in einem schaltbaren Datennetz
DE102006036565A1 (de) Verfahren zur paketvermittelten Datenübertragung in einem Kommunikationsnetz
EP2129048B1 (de) Verfahren zur Datenübertragung in einem Automatisierungssystem

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20130418

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