WO2013100839A1

WO2013100839A1 - A root bridge node and a method in a root bridge node for handling topology changes in an ethernet network

Info

Publication number: WO2013100839A1
Application number: PCT/SE2012/050212
Authority: WO
Inventors: Sabrina LETTERE; Roberto Gallino; Fabio POGGI
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2011-12-30
Filing date: 2012-02-27
Publication date: 2013-07-04

Abstract

A method in a root bridge node for handling topology changes in an Ethernet network is provided. The Ethernet network comprises groups of bridge nodes that are only connected to each other via the root bridge node. The root bridge node and the bridge nodes may be configured to run a Spanning Tree Protocol, xSTP, to prevent ring loops among the bridge nodes in the groups of bridge nodes. The root bridge node comprises a number of ports, which number of ports is associated in the root bridge node with physical addresses of user equipments connected to the bridge nodes in the groups of bridge nodes. The number of ports is configured by the xSTP to have the role of designated ports. The method comprise: associating each port of the number of ports with one of the groups of bridge nodes; receiving a Topology Change Notification, TCN, on at least one port of the number of ports from a bridge node in one of the group of bridge nodes; identifying which group of bridge nodes that the at least one port which received the TCN is associated with; removing in the root bridge node, at least partly the associations between port or ports which are associated with the identified group of bridge nodes, and the physical addresses of the user equipments connected to the bridge nodes; and sending the TCN out on the port or ports of the number of ports which are associated with the identified group of bridge nodes. A root bridge node is also provided.

Description

A ROOT BRfDGE NODE AND A METHOD IN A ROOT BRIDGE NODE FOR HANDLING TOPOLOGY CHANGES IN AN ETHERNET NETWORK

TECHNICAL FIELD

5 Embodiments herein relate to a root bridge node, and a method therein. In

particular, it relates to handling topology changes in an Ethernet network.

BACKGROUND

An Ethernet network is typically defined on Layer 2 in the Open Systems

10 Interconnection model (OSI) provided by International Organization for Standardization (ISO). Layer 2 is also commonly referred to as the Data Link Layer in the OSI-model.

An Ethernet network may typically comprise a large number of Layer 2 switch or bridge devices, hereinafter referred to as bridge nodes. These bridge nodes may be interconnected and grouped in a large number of different ways in order to form different

15 sub-networks or groups of bridge nodes. These groups of bridge nodes may commonly be referred to as Layer 2 cloud networks or Ethernet networks, that is, networks of Layer 2 network devices (such as, switches or bridges) which are connected together via a ring or a meshed network. These groups of bridge nodes may also be connected to each other through a single common bridge node, which is commonly referred to as a root bridge

20 node. The root bridge node may be a bridge node that is configured to act as a root bridge node. The root bridge node may be elected by a network protocol or be manually configured to act as the root bridge node.

The Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for an Ethernet network, such as, the groups of bridge nodes described above.

25 STP may be employed to prevent loops in the groups of bridge nodes and the broadcast messaging resulting from such loops. STP is also standardized in the IEEE 802.1 D standard. Hereinafter, xSTP is used to denote the different variations of STP that may be employed for the groups of bridge nodes, such as, for example, Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP) or any other variation of STP.

30 When implemented in a group of bridge nodes, xSTP creates a spanning tree within the meshed or ringed network of bridge nodes, and disables those links that are not part of the spanning tree, leaving a single active path between any two bridge nodes.

Figure 1 shows an example of Ethernet network 1 comprising a root bridge node 35 1 1 which comprises a number of ports 12. The ports 12 are connected to a series of groups of bridge nodes 11 A, 1 1 B, ... , 1 1 N. Each group of bridge nodes 11A, 1 B, ... ,

11 may comprise any number of bridge nodes A-K.

According to the IEEE 802.1 D standard, when implementing the xSTP in the

Ethernet network 1 , one instance of xSTP is created and managed for all groups of bridge nodes 11 A, 1 1 B, ... , 11 N. Thus, when a topology change occurs, such as, for example, a link failure between two bridge nodes F and G in the group of bridge nodes 1 1 B as shown in Figure 2, the bridge nodes F and G detects the change and starts to send a Topology

Change Notification (TCN) to notify the change to their neighbouring bridge nodes E and

H. The TCN may here be a Bridge Protocoi Data Unit (BPDU) with the TCN flag set.

Upon receiving the TCN from the forwarding neighbouring bridge nodes E-H, the root bridge node 1 1 forwards the TCN to the other groups of bridge nodes 11 A, 11 C, ... ,

1 1 N. In other words, all bridge nodes A-K in all groups of bridge nodes 1 1A, 1 1 B, ... , 11 N will receive the TCN and react accordingly.

A bridge node typically comprises a database which stores physical addresses to users connected to it and physical addresses to users connected to other bridge nodes.

The database is commonly referred to as a Filtering Database (FDB) and the physical addresses are Ethernet Media Access Control (MAC) addresses.

As a bridge node receives the TCN, the bridge node will flush the MAC entries in its FDB database, that is, it will remove all MAC entries except the MAC addresses learnt on the port through which the TCN was received. Then, the bridge node will forward the

TCN in order to force the same flushing operation in the other neighbouring bridge nodes until a stable network situation is achieved again.

SUMMARY

It is an object of embodiments herein to provide a way of improving the handling of topology changes in an Ethernet network.

According to a first aspect of embodiments herein, the object is achieved by a method in a root bridge node for handling topology changes in an Ethernet network. The Ethernet network comprises groups of bridge nodes that are only connected to each other via the root bridge node. The root bridge node and the bridge nodes may be configured to run a Spanning Tree Protocol, xSTP, to prevent ring loops among the bridge nodes in the groups of bridge nodes. The root bridge node comprises a number of ports, which number of ports is associated in the root bridge node with physical addresses of user equipments connected to the bridge nodes in the groups of bridge nodes. The number of ports is configured by the xSTP to have the role of designated ports. The method comprise: associating each port of the number of ports with one of the groups of bridge nodes; receiving a Topo!ogy Change Notification, TCN, on at ieast one port of the number of ports from a bridge node in one of the group of bridge nodes; identifying which group of bridge nodes that the at Ieast one port which received the TCN is associated with;

removing in the root bridge node, at least partly the associations between port or ports which are associated with the identified group of bridge nodes, and the physical addresses of the user equipments connected to the bridge nodes; and sending the TCN out on the port or ports of the number of ports which are associated with the identified group of bridge nodes.

According to a second aspect of embodiments herein, the object is achieved by a root bridge node for handling topology changes in an Ethernet network. The Ethernet network comprises groups of bridge nodes that are only connected to each other via the root bridge node. The root bridge node and the bridge nodes may be configured to run a Spanning Tree Protocol, xSTP, to prevent ring loops among the bridge nodes in the groups of bridge nodes. The root bridge node comprises a number of ports, which ports are associated in the root bridge node with physical addresses of user equipments connected to the bridge nodes in the groups of bridge nodes. These ports may be configured by the xSTP to have the role of designated ports. The root bridge node comprises an association circuit configured to associate each port of the number of ports with one of the groups of bridge nodes, a receiving circuit configured to receive a

Topology Change Notification, TCN, on at ieast one port of the number of ports from a bridge node in one of the group of bridge nodes, an identification circuit configured to identify which group of bridge nodes that the at feast one port which received the TCN is associated with, a removing circuit configured to remove at ieast partly the associations between port or ports which are associated with the identified group of bridge nodes, and the physical addresses of the user equipments connected to the bridge nodes, and a sending unit configured to send the TCN out on the port or ports of the number of ports that are associated with the indicated group of bridge nodes.

A topology change occurring in a group of bridge nodes (such as, for example, a link failure between two bridge nodes in the group of bridge nodes, or insertion of a new bridge node in the group of bridge nodes) which causes a TCN being sent to a root bridge node will according to standard xSTP behaviour cause the root bridge node to forward the TCN to ali groups of bridge nodes being connected thereto. However, when the groups of bridge nodes are only connected to each other via the root bridge node, that is, there is no other physical connection between the groups of bridge nodes, the forwarding of the TCN to the other groups of bridge nodes than to the group of bridge nodes in which the topology change occurred will be unnecessary from a topological point of view. This is because the TCN will spread among the bridge nodes in these other groups of bridge nodes and initiate converging attempts to the new topology therein, but no real change will effectively be the result of these attempts. This is because the topology change will only cause a reai change in the group of bridge nodes in which the topology change actually occurred. A real change here meaning that physical addresses associated with the ports in the root bridge before the converging attempts will be different from the physical addresses associated with the ports in the root bridge after the converging attempts. By associating each port in the root bridge node with a group of bridge nodes, a method and a root bridge node according to the first and second aspects above are able to prevent a TCN from being forwarded to the other groups of bridge nodes than the group of bridge nodes in which the topology change actually occurred. Thus, unnecessary TCN propagation and subsequent forwarding of the TCN among the bridge nodes in the other groups of bridge nodes are avoided. Hence, a way of improving the handling of topology changes in an Ethernet network is provided.

It is also an important advantage of some embodiments herein that the

computational load on the processing circuits of the root bridge node and the bridge nodes in the other groups of bridge nodes than the group of bridge nodes in which the topology change occurred, will be reduced.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features and advantages of the present invention will become readily apparent to those skilled in the art by the following detailed description of exemplary embodiments thereof with reference to the accompanying drawings, wherein:

Figure 1 is a schematic block diagram illustrating an Ethernet network comprising a root bridge node according to prior art, Figure 2 is a schematic block diagram illustrating a link failure in an Ethernet network as shown in Figs. 1-2 according to prior art,

Figure 3 is a schematic block diagram illustrating embodiments in an Ethernet

network,

Figure 4 is a flowchart depicting embodiments of a method in a root bridge node,

Figure 5 is a schematic block diagram illustrating embodiments of a root bridge node.

DETAILED DESCRIPTION

The figures are schematic and simplified for clarity, and they merely show details which are essential to the understanding of the invention, while other details have been left out. Throughout, the same reference numerals are used for identical or corresponding parts or steps.

Embodiments of a root bridge node will now be described with reference to the schematic block diagram depicted in Figure 3.

Figure 3 shows an example of Ethernet network 3 comprising a root bridge node 31. The root bridge node 31 comprises a number of ports 32. The ports 32 are connected to a series of groups of bridge nodes 31A, 31 B, ... , 31 N. Any N number of groups of bridge nodes suitable to be handled by a single root bridge node 31 may be implemented. Each group of bridge nodes 31 A, 31 B, ... , 31 N may comprise any number of bridge nodes A-K. Each bridge node A-K may be connected to any number of users. The users may be any equipment or device configured to be connected to an Ethernet network and a bridge node A-K.

In Figure 3, it should be noted that the topology of the bridge nodes within each group of bridge nodes, such as, for example, the simple ring topology of the bridge nodes A-D within the group of bridge nodes 31A, are purely made for illustrative purposes, but may be any suitable topology wherein the bridge nodes in each group of bridge nodes are connected to each other via a ring or a meshed type network. The root bridge node 31 and the bridge nodes A-K may be configured to establish and run an xSTP based on to the IEEE 802.1 D standard. Thus, one instance of xSTP is created and managed for all groups of bridge nodes 31 A, 31 B, ... , 31 . When a topology change occurs, such as, for example, a link failure between two bridge nodes F and G in the group of bridge nodes 31 B as shown in Figure 3, the bridge nodes F and G will detect the change and will start to send a Topology Change Notification (TCN) to notify the change to its neighbouring bridge nodes E and H. The TCN, also referred to as a TCN message, may here be a Bridge Protocol Data Unit (BPDU) with the TCN flag set. According to some embodiments, all the ports 32 of the root bridge node 31 have the role of "Designated Ports" (DP). In any bridge node implementing xSTP, each port in the bridge node may assume different roles based on their communication path towards the root bridge node 31. However, port ro!es which are different from the "Designated PortVo!e (DP) are not relevant to the embodiments presented herein and thus will not be discussed further.

According to some embodiments, the root bridge node 31 is configured to associate each designated port 32 with one of the groups of bridge nodes 31 A, 31 B, 31 N. For example, the designated ports connected to bridge nodes A and D will be associated to the group of bridge nodes 31 A, the designated ports 321 32M connected to bridge nodes E and H will be associated to the group of bridge nodes 31 B, and the designated ports connected to bridge nodes I and L will be associated to the group of bridge nodes 31 N.

Hence, upon for example receiving a TCN via a designated port 321 connected to bridge node E as shown in Figure 3, the root bridge node 31 may retrieve an indication of which group of bridge nodes 31 A, 31 B, ... , 31 N that the receiving designated port 321 is associated with. In this case, the group of bridge nodes 31 B will be indicated.

Thus, the root bridge node 31 may remove or "flush" at least partly the

associations between physical addresses of the users connected to the bridge nodes E-H and the designated ports 321 32M associated with the indicated group of bridge nodes 31 B, which the root bridge node 31 has stored in a Filtering Database (FDB). That is an FDB associated with the indicated group of bridge nodes 3 B. At least partly removing the associations may, for example, be performed by removing all port-to- physical-addresses associations in the FDB entries except port-to-physical-addresses associations learnt on the designated port 321 through which the TCN was received. Removing port-to-physical-addresses associations in the FDB may, for example, be performed by deleting MAC addresses in the FDB.

Then, instead of forwarding the TCN to the other groups of bridge nodes, such as, for example, the groups of bridge nodes 31 A and 31 N as is described in the IEEE 802.1 D standard, the root bridge node 31 may now send the TCN strictly out on the designated ports 321 32M that are associated with the indicated group of bridge nodes 31 B.

How this may be performed by the root bridge node 31 is described in more detail below in reference to the embodiments shown in Figures 4-5. One advantage of this implementation is that, by being able to refrain from forwarding the TCN to the groups of bridge nodes, such as, for example, the groups of bridge nodes 31 A and 31 N as is described in the standard, the bridge nodes A-D in the group of bridge nodes 31 A and the bridge nodes l-L in the group of bridge nodes 31 N will not forward any TCNs within their group of bridge nodes 31 A and 31 N, respectively, and thus also not flush their FDB databases. Thus, unnecessary TCN propagation and subsequent forwarding of TCNs in the other groups of bridge nodes 31 A and 31 N may be avoided when a topoiogy change occurs in the group of bridge node 31 B. Hence, a way of improving the handling of topoiogy changes in an Ethernet network is provided. Embodiments of a method in a root bridge node when being a root bridge node such as root bridge node 31 , for sending a Topology Change Notification (TCN), will now be described with reference to the flowchart depicted in Figure 4. As mentioned above the root bridge node 31 is comprised in an Ethernet network 3.

The method comprises the following actions.

Action 41

The root bridge node 31 associates each designated port 32 with one of the groups of bridge nodes 31 A, 31 B, 31 . This may be performed by the root bridge node 31 by receiving a port-to-group list 34B, shown in Figure 5, from an operator of the root bridge node 31. The port-to-group list 34B may comprise a list of entries associating each designated port 32 with the group of bridge nodes 31 A, 31 B, 31 N to which each of the designated ports 32 is or is to be respectively connected to. Alternatively or additionally, the operator may enter or program entries in an existing port-to-group list 34B. This may be performed by the operator, for example, upon configuration of the root bridge node 31 and/or upon configuration of the network 3. The port-to-group list 34B may be located in a memory circuit 34 in the root bridge node 31.

In the port-to-group list 34B, each group of bridge nodes 31A, 31 B, 31 N may be identified by an individual indicator or a specific configurable parameter, and each 5 designated port 32 may be identified by a port number. The individual indicator or specific configurable parameter may, for example, be denoted by using an INTEGER syntax. In this case, the value of the individual indicator or specific configurable parameter contains an integer which defines which group of bridge nodes 31 A, 3 B, 31 each of the designated ports 32 are respectively associated to.

10

Action 42

The root bridge node 31 receives a TCN from a bridge node A-K in one of the groups of bridge nodes 31 A, 31 B, 31 N through one of the designated ports 32. This may occur as a consequence of an event or detected topology change by one or more of 15 the bridge nodes A-K. The event or detected topology change may, for example, be a link failure between two bridge nodes A-K in one of the groups of bridge nodes 31 A, 31 B, 31 N, or insertion of a new bridge node A-K in one of the group of bridge nodes 31 A, 31 B, 31 N. According to the example shown in Figure 3, the TCN may be received from the bridge node E in the group of bridge nodes 31 B through the designated port 321 .

20

Action 43

The root bridge node 31 retrieves an indication of which group of bridge nodes 31 A, 31 B, 31 that the designated port 32 through which the TCN was received in Action 42, is associated with. According to the example shown in Figure 3, the root bridge node 25 31 may retrieve an indication of the group of bridge nodes 31 B that was received via the designated port 321. This may be performed by the root bridge node 31 by checking the entries in the port-to-group list 34B.

For example, the root bridge node 31 may check the port number of the designated port 321 through which the TCN was received, and identify an individual indicator or a 30 specific configurable parameter associated with the port number. This provides the root bridge node 31 with an indication of which group of bridge nodes 31 A, 31 B, 31 N that the designated port 321 through which the TCN was received, is associated with.

Thus, the root bridge node 31 is made aware of the group of bridge nodes 31 B that the designated port 321 , through which the TCN was received, is associated with.

35 Action 44

The root bridge node 31 removes at least partly the associations between physical addresses of users connected to the bridge nodes and the designated ports 32 associated with the indicated group of bridge nodes 31 A, 31 B, 31 C, that is, the designated ports 32 associated with the group indicated by the retrieved indication in Action 43. According to the example shown in Figure 3, the root bridge node 31 may at least partly remove the associations between the designated ports 321 , 32M associated with the indicated group of bridge nodes 31 B and physical addresses of users connected to the bridge nodes E-H.

This may be performed by the root bridge node 31 by, for example, removing all entries in its Filtering Database (FDB) 34A except the entries associating the designated port 321 , through which the TCN was received, with physical addresses of the users connected to the bridge node E-H from which the TCN was sent to the root bridge node 31. This removal procedure is commonly referred as a FDB flush procedure, since it flushes away all entries, except for the entries !earnt on the designated port 321 through which the TCN was received, in its Filtering Database (FDB) 34A.

Action 45

The root bridge node 31 sends the Topology Change Notification (TCN) out on only the designated ports 32 that are associated with the group of bridge nodes 31 A, 31 B, 31 N indicated in Action 43. According to the example shown in Figure 3, the root bridge node 31 may here send the TCN out on only the designated ports 321 , ... , 32M that are associated with the group of bridge nodes 31 B.

This may, for example, be performed by the root bridge node 31 by checking the entries in the port-to-group list 34B, This is performed in order to find which one or more port numbers that is associated with the same individual indicator or a specific configurable parameter as identified for the designated port 321 through which the TCN was received. Thus, the root bridge node 31 may restrict the sending of the TCN to the designated ports 321 , ... , 32M that are associated with the indicated group of bridge nodes 31 B.

For example, the root bridge node 31 may send the TCN out on the designated ports 321 , 32M to the indicated group of bridge nodes 31 B by using the standard multicast physical address defined in the IEEE 802.1 D standard. However, the designated port 321 through which the TCN was received, may here be excluded. Embodiments of a root bridge node when being a root bridge node such as root bridge node 31 , for sending a Topology Change Notification (TCN), will now be described with reference to the schematic block diagram depicted in Figure 5.

The root bridge node 31 comprises any number of ports 32. The ports 32 may be connected via a communication link to another bridge node, such as, the bridge nodes A- K in Figure 3. The communication link may be a duplex communication link. Each of the ports 32 may be configured to send and receive data streams to/from the bridge node to which it is connected. Each of the ports 32 may be configured to send and receive data streams to/from one or more processing circuit.

The root bridge node 31 may further comprise one or more processing circuit(s) 33 in the form of an association circuit 33A, a receiving circuit 33B, an identification circuit 33C, a removal circuit 33D and a sending circuit 33E. The association circuit 33A may be configured to retrieve an indication of which group of bridge nodes 31A, 31 B, 31 N that the designated port 32 which received the TCN is associated with. This may be performed by the association circuit 33A by receiving a port-to-group list 34B from an operator configuring the root bridge node 31 and store the port-to-group list 34B in a memory circuit 34. Alternatively or additionally, the association circuit 33A may be configured to receive commands from an operator of the root bridge node 31 to create or add a port-to-group list 34B or entries in an existing port-to-group list 34B. The port-to-group list 34B may be stored in the memory circuit 34.

The receiving circuit 33B is configured to receive a TCN via one of the designated ports 32 from a bridge node A-K in one of the groups of bridge nodes 31 A, 31 B, 31 N in an Ethernet network 3. According to the example shown in Figure 3, the receiving circuit 33B may receive a TCN via the designated port 321 from the bridge node E in the group of bridge nodes 3 B. Upon receiving the TCN in the receiving circuit 33B, the identification circuit 33C is configured to retrieve an indication of which group of bridge nodes 31 A, 31 B, 31 N that the designated port 32 which received the TCN is associated with. According to the example shown in Figure 3, the identification circuit 33C may retrieve an identification of the group of bridge nodes 31 B from the TCN received via the designated port 321. This may be performed by the identification circuit 33C by checking, in the port-to- group list 34B, the port number of the designated port 321 through which the TCN was received, and identify an individual indicator or a specific configurable parameter associated with the port number.

5

Upon identifying the group of bridge nodes 31 A, 31 B, .... 31 N in the identification circuit 33C, the removal circuit 33D is configured to remove at least partly the associations between physical addresses of the users connected to the bridge nodes and the designated ports 32 associated with the identified and indicated group of bridge nodes

10 31A, 31 B, 31 N. According to the example shown in Figure 3, the removal circuit 33D may remove at least partly the associations between the designated ports 321 , 32M associated with the indicated group of bridge nodes 31 B and physical addresses of users connected to the bridge nodes E-H.

This may be performed by the removal circuit 33D by, for example, flushing entries

15 in the Filtering Database (FDB) 34A in the memory circuit 34. Note that the entries

associating the designated port 321 through which the TCN was received, with physical addresses of the users connected to the bridge node E-H from which the TCN was sent to the root bridge node 31 may here be excluded. 0 Upon flushing the Filtering Database (FDB) 34A in the removal circuit 33D, the sending circuit 33E is configured to send the TCN out on the designated ports 32 that are associated with the identified and indicated group of bridge nodes 31A, 31 B, 31 N. According to the example shown in Figure 3, the sending circuit 33E may send the TCN out on only the designated ports 321 , 32M that are associated with the group of bridge 5 nodes 31 B.

This may be performed by the sending circuit 33E by sending the TCN out on the designated ports 32 by, for example, using the standard multicast physical address defined in the IEEE 802.1 D standard. However, the designated port 32 through which the TCN was received, may here be excluded.

0

As mentioned above, the embodiments of the root bridge node 31 herein for sending a TCN may be implemented through one or more processors, such as a processing circuit(s) 33 in the root bridge node 31 depicted in Figure 6, together with computer program code for performing the functions and actions of the embodiments 5 herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the root bridge node 31. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the root bridge node 31.

As stated above, the root bridge node 31 may further comprise the memory circuit 34. The memory circuit 34 may comprise one or more memory units. The memory circuit 34 is configured to be used to store data, in particular the Filtering Database (FDB) 34A and the port-to-group association !ist 34B, which may be retrieved by the processing circuit 33 to perform the methods herein when being executed in the root bridge node 31. The Filtering Database (FDB) is used to associate incoming and outgoing frames to a specific port 32 on the basis of their destination, that is, the physical destination address or destination MAC address that is comprised in the frame.

Those skilled in the art will also appreciate that the association circuit 33A, the receiving circuit 33B, the identification circuit 33C, the removal circuit 33D and the sending circuit 33E described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory (internal or external to the one or more processors), that when executed by the one or more processors such as the processor circuit 33 perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single application-specific integrated circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC).

When using the word "comprise" or "comprising" it shall be interpreted as non- limiting, i.e. meaning "consist at least of. The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

Therefore, the above embodiments should not be taken as limiting the scope of the invention. Abbreviations

BPDU Bridge Protocol Data Units

CPU Central Processing Unit

DP Designated port

FDB Filtering Database

IEEE The Institute of Electrical and Electronics Engineers

ISO International Organization for Standardization

MAC Media Access Control

MSTP Multiple Spanning Tree Protocol

OS! Open Systems Interconnection

RSTP Rapid Spanning Tree Protocol

STP Spanning Tree Protocol

TCN Topology Change Notification

Claims

A method in a root bridge node (31 ) for handling topology changes in an Ethernet network (3), in which the Ethernet network (3) comprises groups of bridge nodes (31 A, 31 B, ... , 31 N) that are only connected to each other via the root bridge node (31 ), wherein the root bridge node (31 ) and the bridge nodes (A-K) in the groups of bridge nodes (31 A, 31 B, ... , 31 N) are configured to run a Spanning Tree Protocol, xSTP, to prevent ring ioops among the bridge nodes (A-K) in the groups of bridge nodes (31A, 31 B, ... , 31 N), in which the root bridge node (31 ) comprises a number of ports (32), which number of ports (32) are configured by the xSTP to have the role of designated ports and which number of ports (32) are associated in the root bridge node (31 ) with physica! addresses of user equipments connected to the bridge nodes (A-K) in the groups of bridge nodes (31 A, 31 B, ... , 31 N), the method comprising

- associating (41 ) each port of the number of ports (32) with one of the groups of bridge nodes (31 A, 31 B, ... , 31 N);

- receiving (42) a Topology Change Notification, TCN, on at least one port (321 ) of the number of ports (32) from one of the bridge nodes (E) in one of the group of bridge nodes (31 B);

identifying (43) which group of bridge nodes (31 B) that the at least one port (321 ) which received the TCN is associated with;

- removing (44) in the root bridge node (31 ), at least partly the associations

between port or ports (321 , 32M) which are associated with the identified group of bridge nodes (31 B), and the physical addresses of the user equipments connected to the bridge nodes (E-H); and

sending (45) the TCN out on the port or ports (321 , ... , 32M) of the number of ports (32) which are associated with the identified group of bridge nodes (31 B).

A method in a root bridge node (31 ) according to claim 1 , which associating (41 ) comprises

- storing a port-to-group list (34B) comprising a list of entries associating each port of the number of ports (32) with one of the groups of bridge nodes (31 A, 31 B 31 N).

A method in a root bridge node (31 ) according to claim 2, which identifying (43) comprises - retrieving an indication of which group of bridge nodes (31B) that the port (321 ) which received the TCN is associated with, by checking the entries in the stored port-to-group list (34B).

A method in a root bridge node (31 ) according to any of claims 1-3, wherein the associations between the port or ports (321 , ... , 32M) and physical addresses of the user equipments connected to the bridge nodes (E-H) are comprised in a Filtering Database, FDB, in which removing (44) comprises

- flushing all entries in the FDB, except for the entries !earnt on the port (321 ) through which the TCN was received.

A method in a root bridge node (31 ) according to any of claims 2-4, which sending (45) comprises

- finding the port or ports (321 , ... , 32M) of the number of ports (32) that are associated with the indicated group of bridge nodes (31 B) by checking entries in the port-to-group list (34B).

A method in a root bridge node (31 ) according to any of claims 1 -5, wherein the TCN is sent using a standard multicast physical address defined in the IEEE 802.1 D standard.

A root bridge node (31 ) for handling topology changes in an Ethernet network (3), in which the Ethernet network (3) comprises groups of bridge nodes (31 A, 31 B, ... , 31 N) that are only connected to each other via the root bridge node (31 ), wherein the root bridge node (31 ) and the bridge nodes (A-K) in the groups of bridge nodes (31 A, 31 B, ... , 31 N) are configured to run a Spanning Tree Protocol, xSTP, to prevent ring loops among the bridge nodes (A-K) in the groups of bridge nodes (31A, 31 B, ... , 31 N), in which the root bridge node (31 ) comprises a number of ports (32), which number of ports (32) are configured by the xSTP to have the role of designated ports and which number of ports (32) are associated in the root bridge node (31 ) with physical addresses of user equipments connected to the bridge nodes (A-K) in the groups of bridge nodes (31 A, 31 B 3 ), the root bridge node (31 ) comprising

an association circuit (33A) configured to associate each port of the number of ports (32) with one of the groups of bridge nodes (31 A, 31 B, ... , 31 N), a receiving circuit (33B) configured to receive a Topology Change

Notification, TCN, on at least one port (321 ) of the number of ports (32) from a bridge node (E) in one of the group of bridge nodes (31 B),

an identification circuit (33C) configured to identify which group of bridge nodes (31 B) that the at least one port (321 ) which received the TCN is associated with,

a removing circuit (33D) configured to remove at least partly the associations between port or ports (321 , ... , 32M) which are associated with the identified group of bridge nodes (31 B), and the physical addresses of the user equipments connected to the bridge nodes (E-H), and

a sending unit (33E) configured to send the TCN out on the port or ports

(321 32M) of the number of ports (32) that are associated with the indicated group of bridge nodes (31 B).

A root bridge node (31 ) according to claim 7, wherein the association circuit (33A) is configured to store a port-to-group list (34B) comprising a list of entries associating each port (32) with one of the groups of bridge nodes (31 A, 31 B_t ... , 31 N).

A root bridge node (31 ) according to claim 8, wherein the identification circuit (33C) is configured to retrieve an indication of which group of bridge nodes (31 B) that the port (321 ) which received the TCN is associated with, by checking the entries in the stored port-to-group list (34B). 10. A root bridge node (31 ) according to any of claims 7-9, wherein the associations between the port or ports (321 , ... , 32M) and physical addresses of the user equipments connected to the bridge nodes (E-H) are comprised in a Filtering Database, FDB, and in which the removing circuit (33D) is configured to flush all entries in the FDB, except for the entries learnt on the port (321 ) through which the TCN was received.

1 . A root bridge node (31 ) according to any of claims 8-10, wherein the sending unit (33E) is configured to find the port or ports (321 , .... 32M) of the number of ports (32) that are associated with the indicated group of bridge nodes (31 B) by checking entries in the port-to-group list (34B).

12. A root bridge node (31 ) according to any of claims 7-11 , wherein the sending unit (33E) is configured to send the TCN using a standard multicast physical address defined in the IEEE 802.1 D standard.