Method for running a computer network

Abstract

The invention provides for a method for running a computer network and such a computer network. The computer network comprises a number of devices being arranged in a stable daisy-chained loop, wherein each device comprises a bridge having at least three ports, whereby during running the computer network each device can take different states to avoid a loop, and whereby in case of rebooting the ports of at least one of the devices keep their current port states.

Claims

1. A method for running a computer network comprising a first Ethernet bridge, a second Ethernet bridge, and a number of devices being arranged in a stable daisy-chained loop between the first Ethernet bridge and the second Ethernet bridge, wherein each device comprises a bridge having at least three ports, whereby during running the computer network each device can take different states to avoid a loop, and whereby in case of rebooting the ports of at least one of the devices keep their current port states without interrupting the communication path during rebooting, wherein only the first Ethernet bridge and the second Ethernet bridge are configured to be a root bridge.

2. The method according to claim 1, wherein the device is in forwarding state.

3. The method according to claim 1, wherein the device is in discarding state.

4. The method according to claim 1, wherein the device immediately updates the port states after reception of a network topology change message.

5. The method according to claim 1, wherein the devices inform each other of their existence about every z seconds, wherein z corresponds to of their boot time.

6. The method according to claim 1, wherein the devices are configured to have the hello time set to x seconds, where x is calculated from the maximum time y it takes to have RSTP up and running after a soft reboot, whereby x>y/2.

7. The method according to claim 1, wherein the devices are configured to have the hello time set to x seconds, where x is calculated from the maximum time y it takes to have RSTP up and running after a soft reboot, whereby x>y/3.

8. A computer network comprising a first Ethernet bridge, a second Ethernet bridge, and a number of devices being arranged in a stable daisy-chained loop between the first Ethernet bridge and the second Ethernet bridge, each device comprising a bridge having at least three ports, wherein the computer network is configured to change states to avoid a loop, and in case of rebooting the ports of at least one of the devices, maintain their current port states without interrupting the communication path during rebooting, wherein only the first Ethernet bridge and the second Ethernet bridge are configured to be a root bridge.

9. The computer network according to claim 8, wherein the computer network is an Ethernet network.

10. The computer network according to claim 8, wherein the devices are end devices of an audio network.

11. The computer network according to claim 8, wherein each device has a mechanism to make sure to react on any converge to avoid loops.

12. The computer network according to claim 9, wherein the devices are end devices of an audio network.

13. The computer network according to claim 8, wherein the at least one of the devices having the rebooting ports proceeds to send BPDUs in response to a RSTP algorithm is up and running.

14. The computer network according to claim 8, wherein a hello time is increased in response to the ports rebooting to avoid detection of a topology change of the network.

15. The computer network according to claim 14, wherein the hello time is longer when the device having the rebooting ports transmits a BPDU before rebooting than when the device having the rebooting ports fails to transmit a BPDU before rebooting.

16. The method according to claim 1, wherein the at least one of the devices having the rebooting ports proceeds to send BPDUs in response to a RSTP algorithm is up and running.

17. The method according to claim 1, wherein a hello time is increased in response to the ports rebooting to avoid detection of a topology change of the network.

18. The method of claim 17, wherein the hello time is longer when the device having the rebooting ports transmits a BPDU before rebooting than when the device having the rebooting ports fails to transmit a BPDU before rebooting.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is an Ethernet network comprising a number of bridges with redundant loops.

(2) FIG. 2 is a number of audio network devices being arranged in a stable daisy-chained loop.

(3) FIG. 3 is a diagram depicting BPDUs showing hello time timeout.

(4) It will be understood that the features mentioned above and those described hereinafter can be used not only in the combination specified but also in other combinations or on their own, without departing from the scope of the invention.

(5) The invention is diagrammatically illustrated in the drawings by means of embodiments by way of example, and is hereinafter explained in detail with reference to the drawings. It is understood that the description is in no way limiting on the scope of the present invention and is nearly an illustration of embodiments of the invention.

DETAILED DESCRIPTION

(6) FIG. 1 shows an Ethernet network 10 comprising a number of bridges with redundant loops. The Ethernet network 10 comprises a bridge A 12, a bridge B 14, a bridge C 16, a bridge D 18, a bridge E 20, and a bridge F 22 being connected by communication channels 24. The network 10 shown also comprises a number of loops.

(7) It can take some time before loops are detected. To avoid overload of the network by circling packets the default in loop detection protocols is that there is no link. This means there is no communication until the network topology is correctly detected. The most known protocols are Spanning Tree Protocol and Rapid Spanning Tree Protocol. STP takes more than 30 seconds to recreate the network topology where RSTP can do this in less than 2 seconds.

(8) FIG. 2 shows a computer network 30, in this case an audio network, comprising a number of devices 32 being arranged in a daisy-chained loop between a first Ethernet bridge 34 and a second Ethernet switch 36 supporting RSTP. Each device 32 comprises a bridge having three ports.

(9) The bridges within the devices 32 do not have to support RSTP. However, if the devices do not support RSTP it will take dozens of seconds before the network is fully configured. If a cable between any of the devices 32 is interrupted it will again take typically 3hello time before the network is reconfigured. Audio is very sensitive to communication loss since there is not retry mechanism in place. This means the loss of audio is equal to the network reconfiguration time.

(10) Bridges 34 and 36 can be root bridges. The bridges 32 in the devices 32 can not. When a root bridge would fail it can take up to 6 seconds before a new root bridge is elected. Therefore, the bridges within the device 32 should not become a root bridge. The root bridge is always the bridge having the lowest priority. The priority of bridges is explicitly set higher than default to prevent it to become a root bridge.

(11) By running an RSTP algorithm in each device 32, the network reconfiguration time can be reduced to less than a second. This solves most of the problems but sometimes the device reboots or switches to firmware update mode. In these situations, it will take about 16 seconds before the RSTP algorithm is settled again.

(12) In the course of this, the network topology is usually not changed and therefore, the state before the reboot is still valid. This avoids a topology change and therefore, no interruption of audio and data.

(13) To avoid loops the device always starts with the Ethernet ports blocked. Only after communication of the RSTP messages, ports can be placed in the forwarding state. When the device reboots without a power loss, the port state assumably is still correct. Therefore, the state is kept persistently until the RSTP algorithm is full up and running again. The rebooting device will not send BPDUs until the RSTP algorithm is up and running. To avoid that the other devices will detect a topology change during this, the default BPDU hello time is increased from the default 2 seconds to x seconds, e.g. 10 seconds.

(14) If the time it takes to have RSTP up and running is y and the hello time is x, the following contraint must hold: y2x if the device is not forced to send a hello BPDU before being reset, and y3x if the device is forced to send a hello BPDU before being reset. As it takes about 16 seconds for the device to have RSTP up and running a hello time of 9 seconds is currently used.

(15) The devices 32 can inform each other of their existence every z seconds, wherein z corresponds to of their boot time. Furthermore, each device 32 can have a mechanism to make sure to react on any converge to avoid loops.

(16) FIG. 3 shows a diagram for illustrating communication within an Ethernet network. Reference number 50 represents RSTP supporting Ethernet bridges, reference number 52 represents devices supporting the method according to the invention. Thin dash/dotted lines showing the BPDU's exchange. Between the thick double line and double dotted line the device reboots. The solid lines indicate the BPDUs which are not sent out due to the reboot of the devices. The indication 10 on the left side represents 10 seconds. The double arrow 54 represents 15 seconds.

(17) The hello time is the time interval between the BPDU's sent from a bridge. It is used to inform the other bridge hello I am here. If you miss 3 BPDUs, this is 30 seconds with 10 seconds hello time, the other bridge will switch to the discarding mode again. The hello time is only used after the network has converged. Ports in forwarding state will then sent a BPDU every hello time seconds, ports in discarding state will expect an incoming BPDU every hello time seconds. It is meant to indicate the network is still converged.

(18) According to the RSTP specification, a device will issue a topology change when it misses 3 BPDUs. In a worst case scenario, the rebooting device was about to send a BPDU when it reboots. This means that RSTP must be up and running within 2hello time seconds after reboot. Alternatively, the device could send out a BPDU first before it reboots since this reboot is normally planned. This increases the reboot time to 3hello time seconds.

(19) After boot-up of a device the state machines of RSTP are started. Firstly, the state machines will put all ports in discarding state and after this to learning state. If the neighbour devices of the booting device were not reset they will react fast to the BPDU's sent by the booting device. The ports of the booting device will then move to forwarding state quickly.

(20) However, if the neighbour devices are also booting as they are reset too, it may take longer before they respond. This may still cause an interruption of the chain as the ports stay in learning state for a longer period and regular traffic is still not forwarded in learning state. In order to solve this, the ports that were in forwarding state are kept in that state, even if the RSTP algorithm indicates that they should go to discarding or learning state. The only exception to this rule is when a topology change BPDU is received on a port which means that the neighbour device has started a new network convergence. In that case the actual RSTP port state is forced onto the port before the acknowledgement of the topology change is sent back. Therefore, loops are prevented.

(21) In the case that there is a topology change when a device reboots the root bridge will still be able to break the loop. However, this will result in communication loss of dozens of seconds. It is important that the (root) Ethernet bridge is also configured to this x seconds hello time.