WO2009037067A1 - 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
WO2009037067A1
WO2009037067A1 PCT/EP2008/060995 EP2008060995W WO2009037067A1 WO 2009037067 A1 WO2009037067 A1 WO 2009037067A1 EP 2008060995 W EP2008060995 W EP 2008060995W WO 2009037067 A1 WO2009037067 A1 WO 2009037067A1
Authority
WO
WIPO (PCT)
Prior art keywords
destination
node
nodes
multicast
alias
Prior art date
Application number
PCT/EP2008/060995
Other languages
English (en)
French (fr)
Inventor
Karl Weber
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2009037067A1 publication Critical patent/WO2009037067A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/351—Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches

Definitions

  • Ethernet networks which are increasingly being used also in the area of automation of technical processes
  • the network participants covered by the respective network ie automation devices and the like, communicate e.g. based on point-to-point connections involving exactly two network subscribers or "nodes" for short (sender and receiver or source and destination) or based on broadcast or multicast connections in which a plurality of nodes are involved on the receiver side is.
  • point-to-point connection has become widely used to classify communications in networks.
  • direct connections between two nodes that is to say without an intermediary intermediate station, are referred to as point-to-point connections.
  • point-to-point connections direct connections between two nodes, that is to say without an intermediary intermediate station.
  • unicast is used in such a way that so-called end-to-end connections are also included in which a communication also takes place between only two nodes, but in which the forwarding by intermediate stations, switches and the like takes place on the communication path , is being used.
  • broadcast and multicast are communications in which a message is sent to all nodes or a specified set of nodes. While basically all nodes are addressed during the broadcast, a multicast is directed only to specific destinations or nodes. In the following, the nodes which are intended to receive a multicast are referred to as "customers.”
  • Each multicast just like a unicast, is addressed to one of the destination nodes as the primary destination. cast is determined by the address specified as the primary destination, even if an address of the customer and an address of the node specified as the primary destination do not match.
  • IGMP group management
  • Each customer thus recognizes whether he belongs to the group specified by the destination and in this way likewise becomes a recipient or destination of the multicast.
  • each customer is referred to as a secondary target to distinguish it from the primary target.
  • a method as defined in claim 1 is provided.
  • a set is defined in advance.
  • Hierarchically organized rules is provided, by means of which in the Ethernet network, a data flow from a node as a source to one or more other nodes as the destination is directed and that the rules are directed to a topology of the Ethernet network, such that each node An alias is assigned which gives information about a topological-hierarchical position of the node in the Ethernet network, resulting in a deterministic, rule-based data flow in the Ethernet network with a reduced multicast load.
  • Alias to each network node is further provided that one of the nodes is assigned according to its topological hierarchical position an alias, which identifies him as a root node.
  • the or each rule then complements a forwarding strategy that is focused on the topology and each alias derived from it, which will be mentioned separately below.
  • the application of a first rule is made, which states that the multicast transmission with the primary destination is given as destination in the Ethernet network and for all nodes between source and primary goal can be tapped.
  • each node comprises at least a first, second and third input and output port, two of which are part of the line of a multicast transmission to a primary destination, that if at least one secondary destination is not is on the line, a hierarchical subordinate rule is applied, which states that the multicast transmission from each node along the line is also forwarded via its second port.
  • a hierarchical subordinate rule is applied, which states that the multicast transmission from each node along the line is also forwarded via its second port.
  • a further hierarchically subordinate rule is used, which states that the multicast transmission from each node along the line is also used via its third port is forwarded. In this way, previously unreachable nodes for multicast broadcasts can be reached.
  • the invention also relates to an implementation of the above outlined and subsequently described method or its embodiments and software, hardware and / or software and hardware, ie in particular a computer program with which such a method is implemented.
  • the invention also relates to a data carrier with such a computer program and a computer system, in particular a network participant - in particular a network participant in an embodiment as an automation device - on which such a computer program is loaded.
  • FIGS. 2 and 3 show different communication scenarios in which the approach according to the invention can be used.
  • FIG. 1 shows an Ethernet network (network) 10 with a plurality of network subscribers, which are referred to below as nodes 12 in the following, although not all nodes 12 are identified by the corresponding reference symbol in the illustration for reasons of clarity.
  • automation devices are considered as nodes 12, ie devices or systems, in addition to e.g. Controls, such as programmable logic controllers, process computers, (industrial) computers, and the like, also drive controllers, frequency converters, and the like, as used to control, regulate, and / or monitor technological processes, e.g. be used or be used for forming or transporting material, energy or information, etc., in particular by means of suitable technical devices, such. Sensors or actuators, energy is spent or converted.
  • Controls such as programmable logic controllers, process computers, (industrial) computers, and the like
  • controllers frequency converters, and the like
  • Each node 12 includes, as shown in Figure 1 bottom right, at least a first, second and third input and output port (port) 14, 16, 18. Via the first and second ports 14, 16 can connect to other nodes 12th within a hierarchically same line of topology of the network 10. A connection to other nodes 12 in a hierarchically subordinate line of the network topology may exist via the third and optionally further ports 18, wherein a connection of a node 12 to a third or further port 18 of a preceding node 12 takes place via its first port 14.
  • the at least three ports 12-16 of a node 12 are thus assigned exclusively to individual hierarchy levels within the Ethernet network 10. For nodes 12 that are part of the network 10, al- at least the first port 14 is used for integration into the network 10.
  • Nodes 12 using only the first port 14 are referred to as "leaves.”
  • Nodes using only the first and second ports 14, 16 are referred to as intermediate nodes or “intermediate” nodes 12 where the first, second and third ports 14-18 are used, referred to as a branching node or, for short, as a branching.
  • the first port 14 is further referred to as a primary port 14 for distinction.
  • the primary port 14 is at each node 12 that port which faces a root node 20 in the network topology.
  • Each node 12 is assigned a unique alias, which results from the following formation scheme: Starting from the root node 20, in a first allocation section, for all nodes 12 connected to the root node 20 in a hierarchically same line, a first level of Communication links in the network 10 signifying part of the respective alias increases with increasing distance from the root node 20. So if, for example, for the
  • Root node 20 is aliased with the digit or string "1", resulting in an alias 12 adjacent to root node 20 which is increased compared to the alias of root node 20, e.g., "2".
  • an alias is obtained which in each case is increased in comparison to the alias of the node 12 which precedes along the same line.
  • Increasing the numerical value of the alias does not necessarily take place in increments of one, but may also reflect the actual spatial distance.
  • an alias is assigned for all connected nodes 12 for all nodes 12 reached in this way, with which at least one further node 12 is directly or indirectly connected via their third port 18.
  • This becomes hierarchical from the alias of the parent hierarchical node 12 by adding a formed subordinate level of the communication links in the network 10 indicative component, ie, for example, for a node 12, which immediately follows a node 12 with the alias "3", the alias "3.1".
  • the first and second allocation sections are repeated in a third allocation section, with the respective node 12 replacing the root node 20 and the respective hierarchical level replacing the node first level of communication links occurs.
  • it is therefore a recursive formation scheme that has detected all nodes 12 at the end of the recursion, so that in the network 10 each node 12 is assigned a unique alias which gives information about a topological-hierarchical position of the node 12 and which makes it possible to forward telegrams in the special form as multicast transmissions in the manner described here in an efficient manner.
  • nodes 12 with aliases “2.2.2”, “3.4.2” and “3.6” leaves.Nodes 12 with the aliases “2.1”, “3.2.1” and “4.2.2” are intermediates or intermediate nodes and the nodes with alias "3", "3.3”, and "4.2" are branches.
  • the network 10 as a whole can be regarded as a "tree" with the root node 20.
  • each node 12 with any successors connected to its second and third ports 16, 18 can be regarded as a sub-tree Subtree is that node 12 which has no connection within the sub-tree via its primary port 14 to another node 12 of the subtree, the root node of the subtree
  • the subtree of the node 12 with the alias "2" that entire network 10 without the root node 20.
  • the subtree of the node 12 with the alias "3" is the entire network 10 without the root node 20 and without the node 12 with the alias "2" and its successors connected to its third port 18, etc.
  • a separate alias is compared with an alias of a destination node - destination alias encompassed by the received message and, depending on the result of the comparison, the message is forwarded via the first, second or third port 14-18.
  • the telegram is forwarded via the primary port 14 if one of the own level of the respective node 12 constituent part of its own alias - relevant own alias section - and a corresponding part of the target alias - relevant Zielaliasabêt - meet in this order of a "less than equal" relation.
  • Telegram in a form that allows its receipt at each destined node 12, so a shipment as a multicast transmission.
  • the term telegram is used here and below as a generic term for all common names in the art for transmissions to be transmitted in a network 10. In that regard, the term telegram also includes terms such as frame, datagram, data packet, etc.
  • the invention proposes that a set of predefined, hierarchically organized rules is provided, by means of which in the respective network 10 a data flow from a network participant /
  • Node 12 is routed as a source to one or more other network participants / node 12 as a destination (primary destination, secondary destination (s)), the rules being geared to the particular network topology in which each node 12 is assigned an alias or which gives information about its topological-hierarchical position in the network 10, so that a deterministic, rule-based data flow in the network 12 results with reduced multicast load.
  • functional units are involved on a hierarchically comparatively low level, which are normally encompassed by each node 12 and which allow their actual integration into the network 10.
  • switches These functional units are usually referred to as "switches.”
  • switches these functional units are usually referred to as "switches.”
  • switches a distinction is not made between the respective network subscriber and the switch comprising it, since it depends on the specific functionality of the network subscriber / node, eg as a programmable logic controller, distributed peripheral device, etc.
  • node 12 every use of the term "node” 12 here and in the following includes the reference also to such functional units, that is to say in particular switches.
  • a multicast address is a unicast address, which may contain information, e.g. a flag is added, at which the switches recognize that it is a multicast transmission, which is thus not only intended for the node 12 coded by the address.
  • nodes 12 In practice, there is often the need to address a plurality of nodes 12 that are in close proximity to one another at a particular time as a multicast transmitter acting node 12 are located. Only in exceptional cases is a transmission also required to "further away" nodes 12.
  • Nodes 12 in spatial proximity to the transmitter are those nodes 12 which are located with the transmitter in a comparatively small sub-tree of the network 10, ie a subtree. which includes only a few nodes 12.
  • the inclusion of more distant nodes 12 results in more extensive subtrees, which, especially when it becomes necessary to use links on an uppermost hierarchical level, that is to say the level comprising the root node 20, quickly take on dimensions. which correspond to those of the entire network 10.
  • the invention is based on the finding that with topological addresses and the forwarding scheme based thereon, a set of nodes 12 can be achieved in a simple manner.
  • a node 12 is addressed as destination and all nodes 12 or stations on the way between source and destination can access the data. That would be if the shortest path between source and the or each destination, denoted as line 22 (FIG. 2), does not include branches, especially if source and all destinations belong to the same hierarchical level, already the solution for multicast. In such a scenario, an area between the source and the last destination is always affected. The respective multicast transmission can thus be directed to the last destination (a multicast to the corresponding address of the last node 12 with group address and Locally administered to "1".) FIG 2 illustrates this scenario and the boundaries.
  • a particularly simple scenario is that the node 12 with the alias "2.4" has to send identical messages to the nodes 12 with the aliases "2.4.1” and “2.4.2” .
  • This can be in a multicast transmission
  • the respective alias of the destination node can be used, which, according to the prerequisite, "gives information on a topological-hierarchical position of the respective node 12 in the network 10."
  • the node 12 with the alias "2.4.2” can be seen.
  • the last node that is the primary target. Its address (or its alias) is used as the address of the multicast transmission.
  • the above-mentioned forwarding strategy causes the forwarding to occur exactly along the line 22 drawn to this scenario. All nodes 12 between source and last node 12 can pick up the multicast transmission. The multicast transmission can therefore also be accessed by the customer "2.4.1" as a secondary destination.
  • a method in which, in the case of a plurality of nodes 12 as destination, ie as primary or secondary destination, identical messages are combined to the primary destination and each secondary destination to form a multicast program, wherein when the primary destination and each secondary destination are on a source node 20 side of the source, that node 12 is used as the primary destination for the multicast transmission having the hierarchically smallest alias, or if the primary destination and each secondary destination are remote from the root node 20 Side of the source, that node 12 is used as a primary destination for the multicast transmission, which has the hierarchically largest alias, and as the line 22 for the multicast transmission along the existing connections between the nodes 12 shortest connection between source and primary destination is used.
  • Ethernet network 10 is given and can be tapped for all nodes 12 between source and primary destination.
  • this rule will be referred to as “MCL” for "multicast, along the line”.
  • no branch-free line 22 is possible, that is, for example, if from node 12 with the alias "3.4.2” transmissions to the nodes 12 with the alias "3.2.2” and “3.3.1” are to be addressed.
  • the secondary destination (the node “3.3.1") is then not on a line 22 between the transmitter (node “3.4.2”) and the primary destination (node "3.2.2").
  • the o.g. first rule that is not sufficient, because at a fork and the multicasts would have to diverge, which is not provided on the basis of the forwarding strategy and only with application of the first rule.
  • the resulting problem can be solved by adding a second rule stating that "branches" may also be "flooded" along line 22.
  • node 12 has the alias Although "3.4" with its third port 18 basically represents a branching, this third port 18 is not used according to the forwarding strategy, and thus the relevant node 12 does not appear as a branching for this line 22 in total.
  • the alias "3.2.” For every other node 12 lying on the line 22, in which all three
  • Ports 14-18 Links to other nodes 12 exist (in the case shown only for the node 12 with the alias "3.3"), according to the second rule and in addition to the routing strategy that the message forming the multicast transmission over the second port 16 of which is forwarded to node 12 directly or indirectly connected thereto, and to distinguish it from the line 22, links and nodes 12 which adjoin the respective second port 16 after such a branch are referred to as path or branch 24
  • the second rule which is hierarchically subordinate to the first rule, thus supplements the forwarding strategy in such a way that the multicast transmission is forwarded by each node 12 along the line 22 via its second port 16, ie branches 24 are also used second rule a forwarding of a telegram is considered only if the relevant alias section one along the line 22 lie node 12 and the relevant target alias section of the primary objective If a node 12 in this sequence satisfies a "greater than" relation, the telegram is always flagged as a multicast transmission as well as when the second rule is
  • the node 12 with the alias "3.2.1” results as the primary destination
  • the application of the second rule causes the subsegment to be flooded with the node "3.4.2", so that the intended customer can pick up the multicast transmission.
  • the sub-segment emanating from the node "3.3" via its second port 16, in which no subscribers are located is flooded, but because sub-segments are generally less loaded than main segments, this overhead is frequently acceptable.
  • FIG. 3 An example of such a situation is shown in FIG. 3, whereby, as already mentioned above for FIG. 2, it is also true for FIG. 3 that not all nodes 12 are marked with the corresponding reference number for reasons of clarity. 3 assumes the alias "3.4.2" as the sender of the node 12. Subscribers of a multicast transmission to be deducted from this are the nodes 12 with the alias "3.2.2", “3.3.1” and "3.5.1". Among these customers, the node 12 with the alias "3.2.2" as the primary destination results in.
  • the line 22 connects the sender and the primary destination, and the line does not include the secondary destination "3.3.1", which floats when the second rule (MCB) is applied the branch 24 existing along the line 22 is reached, and not the secondary target "3.5.1” achieved by using the third rule (MCBS) by flooding the secondary paths 24 along the line 22.
  • MBB second rule
  • MCBS third rule
  • the methods of flooding are only problematic if the multicast transmission passes through heavily frequented sections. These are almost always the main segments of the network (“Level 1”), ie links in the same plane as the root node 20. In a constellation in which, for example, the root node 20 and a subtree are affected in a remote segment, the Even at a first sublevel of the network 10 ("Level 2") there is still a certain risk of flooding, if many stations / nodes 12 are arranged here.
  • MCL, MCB, MCBS three rules explained above (MCL, MCB, MCBS)
  • one finding that has led the inventor to an advantageous embodiment of the invention is that with a set of seven different rules, the multicast traffic is very well steered. The rules are quite simple, they can also be correspondingly little effort in the node 12, more precisely in the included switches implement.
  • MCL remains if the or each secondary target is on line 22 to the primary target or in its extension, otherwise MCB if the secondary target is on one is not reached from line 22 in the respective subtree or in its extension, otherwise MCBS
  • this selection procedure can also include the multicast rules on the main segment. All nodes to be reached must be in one of three subtrees:
  • the MCBxI or MCBSxI rule can be applied.
  • An algorithm with which the method described here, possibly including preferred embodiments described here, is implemented, can be used either offline during the configuration or online when registering a node 12 as a multicast consumer or as a multicast subscriber.
  • a particular achievement of the invention is that a method is specified which automatically structures address spaces and attempts to reach a defined number of stations with an address.
  • the multicast address contains information that allows or prevents some propagation (activation of one of the rules 2 to 7). It is assumed that the multicast relationships usually take place in a local environment. In this way, it is no longer necessary to plan the forwarding explicitly or to secure it via complex protocols.
  • the suitable range can be defined, which in turn is found with justifiable expenditure. Because the multicast address is not a selection criterion for the receiver station, the range can also be adjusted dynamically.
  • the method described here can be carried out with other topology-based addresses instead of Ethernet addresses.
  • a method is provided in which a set of predefined hierarchical rules is provided, by means of which a data flow is conducted from a source to a destination in the Ethernet network,
  • the rules are derived from a topology of the Ethernet network, resulting in a deterministic, rule-based data flow in the Ethernet network with minimization of the multicast load.

Landscapes

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

Abstract

Bei einem erfindungsgemäßen Verfahren wird ein Satz von vorab definierten hierarchischen Regeln bereitgestellt, 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.

Description

Beschreibung
Verfahren zur Begrenzung der Multicast-Last bei einem Ether- net-Netzwerk, Computerprogramm zur Implementierung des Ver- fahrens und Computersystem mit einem solchen Computerprogramm
In Ethernet-Netzwerken, die mehr und mehr auch im Bereich einer Automatisierung technischer Prozesse Verwendung finden, kommunizieren die von dem jeweiligen Netzwerk umfassten Netz- werkteilnehmer, 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än- gerseite 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 zwi- sehen 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 de- nen 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 Kno- ten, 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 Multi- cast 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 un- ten 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 MuI- ticast-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 Multis- castfilter 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 Kommunikationsvor- gangen übermittelten Daten.
Negativ wirkt sich zudem aus, dass Suchfunktionen in Multi- cast-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 for- warding", 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.
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 un- vermeidlich 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 An- spruch 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 definier- ter, 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 reduzier- ter 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 Weiterleitungs- strategie, 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 selb- stä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 nachge- ordneten Anspruch davon auszugehen, dass eine derartige Be- schrä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 Pri- mä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 Aus- gangsport (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 „Überflutung 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 nach wie vor nicht erreicht wird, 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 Kombina- tionen, 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
FIG 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, FIG 2 und 3 unterschiedliche Kommunikationsszenarien, bei denen der Ansatz gemäß der Erfindung zum Einsatz kommen kann.
FIG 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. Steue- rungen, 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 FIG 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 12- 16 eines Knotens 12 werden also exklusiv einzelnen Hierarchieebenen innerhalb des Ethernet-Netzwerks 10 zugeordnet. Bei Knoten 12, die Bestandteil des Netzwerks 10 sind, ist al- so 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, wer- den als Zwischenknoten oder „Intermediate" und Knoten 12, bei denen erster, zweiter und dritter Port 14-18 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 Netzwerktopo- logie einem Wurzelknoten 20 zugewandt ist.
Jedem Knoten 12 ist ein eindeutiger Alias zugewiesen, der sich aus folgendem Bildungsschema ergibt: Ausgehend vom Wur- zelknoten 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 Kno- ten 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 In- termediates 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 FIG 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 ge- samte 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 14- 18 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 Ziel aliasabschnitt einer „ist gleich" Relation genügen. Für wei- tere 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 Netz- werkkomponente sowie korrespondierendes Computerprogramm und Computerprogrammprodukt" verwiesen (amtliches Aktenzeichen wird nachgereicht) , auf die im Folgenden als Weiterleitungs- strategie 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 FIG 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 Netzwerkto- pologie abgestellt sind, in der jedem Knoten 12 ein Alias zu- geordnet ist oder wird, welcher Aufschluss über dessen topo- logisch-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 er- lauben. Diese Funktionseinheiten werden üblicherweise als „Switch" bezeichnet. Hier und im Folgenden wird nicht zwischen dem jeweiligen Netzwerkteilnehmer und dem davon umfass- ten Switch unterschieden, da es auf die konkrete Funktionalität des Netzwerkteilnehmers/Knotens, z.B. als speicherpro- grammierbare 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 je- weiligem Ziel. Um die Optimierung zur Begrenzung der Multi- cast-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 ver- gleichsweise kleinen Teilbaum des Netzwerks 10 befinden, also einem Teilbaum, der nur wenige Knoten 12 umfasst. Beim Ein- schluss 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 topolo- gischen Adressen und dem darauf basierenden Weiterleitungs- Schema 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 (FIG 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") . FIG 2 illustriert dieses Szenario und die Grenzen.
In FIG 2 sind zur Verbesserung der Übersichtlichkeit nur einzelne Bezugszeichen eingezeichnet. Insoweit wird auf FIG 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 Be- Schreibung durch den dem jeweiligen Knoten 12 zugeordneten Alias referenziert .
Ein besonders einfaches Szenario besteht darin, dass der Kno- ten 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 „Auf- Schluss ü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 - an- ders 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 MuI- ticast-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 Weiterleitungs- strategie und nur mit Anwendung der ersten Regel nicht vorgesehen ist. Das sich dadurch ergebende Problem kann aber ge- lö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 dar- stellt, dass dieser dritte Port 18 aber entsprechend der Wei- terleitungsstrategie 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 14-18 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 Wei- terleitungsstrategie, 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 nachge- ordnete 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ärziel angegebe- nen 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 Mar- kierung) 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 Se- kundä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 FIG 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 befinden) 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 (FIG 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 FIG 3 dargestellt, wobei auch für FIG 3, ähnlich wie oben bereits für FIG 2 erwähnt, gilt, dass aus Gründen der Übersichtlichkeit nicht alle Knoten 12 mit dem entsprechenden Bezugszeichen gekennzeichnet sind. Das in FIG 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 Netz- werks („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"
MCBxI Vierte Regel - "Use all Branches between Source and Destination (not at Level 1)"
MCBSxI Fünfte Regel - "Use all Branches and Secondary between Source and Destination (not at Level 1)" MCBxl2 Sechste Regel - "Use all Branches between Source and
Destination (not at Level 1 and 2)" MCBSxl2 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 vorgenann- ten 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 MCBxI oder MCBSxI Regel angewandt werden .
Ein Algorithmus, mit dem das hier beschriebene Verfahren, evtl. inklusive hier ebenfalls beschriebener bevorzugter Aus- fü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 vor- gestellen 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 vorgeschlage- nen 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 enthal- ten 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 untersetz- te 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 Weiterlei- tungskriterium (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 Positionier- aufgäbe 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 bereitge- stellt wird, mittels welcher im Ethernet-Netzwerk ein Daten- fluss 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 Da- tenfluss im Ethernet-Netzwerk unter Minimierung der Multi- cast-Last ergibt.

Claims

Patentansprüche
1. Verfahren zur Begrenzung einer Multicast-Last bei einem Ethernet-Netzwerk (10) mit einer Mehrzahl von Knoten (12) als Netzwerkteilnehmer, 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 to- pologisch-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.
2. Verfahren nach Anspruch 1, wobei bei einer Mehrzahl von Knoten (12) als Ziel - Primärziel, Sekundärziele - gleiche Telegramme an das Primärziel und jedes Sekundärziel zu einer Multicast-Sendung zusammenge- fasst 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 ei- ner 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.
3. Verfahren nach Anspruch 2, 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 Ether- net-Netzwerk (10) gegeben wird und für alle Knoten (12) zwischen Quelle und Primärziel abgreifbar ist.
4. Verfahren nach Anspruch 3, wobei jeder Knoten (12) zumindest einen ersten, zweiten und dritten Ein- und Ausgangsport - Port (14, 16, 18) - um- fasst, von denen zwei Bestandteil der Linie (22) sind, und 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.
5. Verfahren nach Anspruch 4, 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.
6. Computerprogramm zur Ausführung eines Verfahrens gemäß einem der Ansprüche 1 bis 5.
7. Datenträger mit einem Computerprogramm nach Anspruch 6.
8. Computersystem, insbesondere Netzwerkteilnehmer - insbesondere Netzwerkteilnehmer in einer Ausführung als Automatisierungsgerät -, auf dem ein Computerprogramm nach Anspruch 6 geladen ist.
PCT/EP2008/060995 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 WO2009037067A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102007044081.4 2007-09-14
DE102007044081 2007-09-14
DE102007062739.6 2007-12-27
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 (1)

Publication Number Publication Date
WO2009037067A1 true WO2009037067A1 (de) 2009-03-26

Family

ID=40348696

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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 (4)

* Cited by examiner, † Cited by third party
Title
BAKKER E M ET AL: "Prefix routing schemes in dynamic networks", COMPUTER NETWORKS AND ISDN SYSTEMS, NORTH HOLLAND PUBLISHING. AMSTERDAM, NL, vol. 26, no. 4, 1 December 1993 (1993-12-01), pages 403 - 421, XP024235575, ISSN: 0169-7552, [retrieved on 19931201] *
JIE WU ET AL: "Deadlock-Free Multicasting in Irregular Networks Using Prefix Routing", THE JOURNAL OF SUPERCOMPUTING, KLUWER ACADEMIC PUBLISHERS, BO, vol. 31, no. 1, 1 January 2005 (2005-01-01), pages 63 - 78, XP019215713, ISSN: 1573-0484 *
RICH SEIFERT: "The switch book: Multicast pruning", THE SWITCH BOOK, 2000, NEW YORK : JOHN WILEY & SONS, US, pages 409 - 417, XP002506567, ISBN: 0-471-34586-5 *
ROGER BUTENUTH, HANS-ULRICH HEISS: "Skalierbare Gruppenkommunikation in Netzen mit beliebiger Topologie", TAGUNGSBAND EMVA (ENTWICKLUNG UND MANAGEMENT VERTEILTER ANWENDUNGSSYSTEME), October 1995 (1995-10-01), Dortmund, XP002506566, Retrieved from the Internet <URL:http://www.kbs.cs.tu-berlin.de/publications/fulltext/BH95.pdf> [retrieved on 20081202] *

Also Published As

Publication number Publication date
DE102007062739B4 (de) 2013-01-17
DE102007062739A1 (de) 2009-03-19

Similar Documents

Publication Publication Date Title
DE3888818T2 (de) Aufgeteilte Lastverteilung.
EP2676409A2 (de) Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze
EP3522477A1 (de) Verfahren zur daten-kommunikation in einem insbesondere industriellen netzwerk, vorrichtung zur durchführung des verfahrens, computerprogramm sowie computerlesbares medium
EP2413538B1 (de) Vermeidung von Sendeschleifen in einem redundanten Ringnetzwerk
EP0700224A2 (de) Verfahren zur adaptiven Wegesuche in einem Kommunikationsnetz
EP0784894A1 (de) Verfahren und anordnung zur adressierung von teilnehmern in einem aus mindestens zwei segmenten bestehenden netzwerk
EP2955904B1 (de) Vergabe von netzwerkadressen für netzteilnehmer
WO2018162071A1 (de) Verfahren und vorrichtung zur modularen lenkung eines avb-streams
EP3095173A1 (de) Verfahren zum übertragen von nachrichten in einem energieautomatisierungs-netzwerk, energieautomatisierungskomponente und umspannstation
EP2127241B1 (de) Zielportsuche in netzwerken aus gekoppelten teilnetzen
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
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
DE69930495T2 (de) Verfahren zur Unterstützung von Abkürzungen in der Netzwerkebene
DE102008017192A1 (de) Verfahren zum Aufbau eines Netzwerks
DE102014226994A1 (de) Kommunikationssystem zum Betreiben eines Datennetzwerks
EP3716537A1 (de) Verfahren zur datenkommunikation, netzwerkknoten, computerprogramm und computerlesbares medium
WO2020151814A1 (de) Verfahren zur ausfallsicheren datenübertragung, netzwerk-knoten, computerprogramm und computerlesbares medium
EP3590235B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
WO2008015035A1 (de) Verfahren zur paketvermittelten datenübertragung in einem kommunikationsnetz
EP2074843A1 (de) Verfahren zur vernetzung einer mehrzahl von konvergenten messaging systemen und entsprechendes netzsystem
DE10340120B4 (de) Verfahren und System zur Weiterleitung von Informationen in einem verteilten Netzwerk
EP2129048B1 (de) Verfahren zur Datenübertragung in einem Automatisierungssystem
EP2475150B1 (de) Verfahren zur Konfiguration eines Empfängers zum Empfang von mittels eines Kommunikationsnetzwerks verteilten breitbandigen Multicast-Signalen, sowie Empfänger und System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08803160

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08803160

Country of ref document: EP

Kind code of ref document: A1