Method for automatically detecting physical connections of ethernet bridges connected to a root bridge

A method of detecting physical connections between a root bridge node and layer-2 bridge nodes organised in a layer-2 cloud. The method comprises sending a query message from a sending port of the root bridge node and starting a timer set to a waiting interval. After the timer expired, if a response message to the query message is not received or is received at the sending port then only the sending port is associated with said layer-2 cloud. Alternatively, if a response message is received at a port other than the sending port then the sending port and the receiving port are associated with said layer-2 cloud. A bridge node and a layer-2 communications network are also disclosed.

TECHNICAL FIELD

The present invention relates to layer-2 communications networks, in general, and in particular to detecting physical connections in layer-2 networks organised in groups known as layer-2 clouds.

BACKGROUND

An Ethernet network is typically defined on layer 2 in the Open Systems 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 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 node as illustrated inFIG. 1. 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 called Spanning Tree Protocol (STP) or be manually configured to act as the root bridge node.

STP is a network protocol that ensures a loop-free topology for an Ethernet network. 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.1D 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.

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.

Ethernet switches residing in one of these layer-2 clouds can be variously connected to each other, letting to the RSTP protocol the task to remove any loop between them.

Although a number of layer-2 clouds (e.g. Ethernet networks) may be connected to the same root bridge node these layer-2 clouds have no relationship with each other. The root bridge node, in turn, does not know details of the number, the consistency and the connectivity of the layer-2 clouds connected to it. In known solutions information about layer-2 clouds (consistency, connectivity, etc) has to be manually entered in the root bridge node and it is assumed to be static. This means that the view of Ethernet network form the root bridge node must be statically configured by the operator, which, in turn, means that the operator has to associate each port of root bridge node to a specific layer-2 cloud, subjected to possible errors.

SUMMARY

It is the object of the present invention to obviate at least some of the above disadvantages and provide an improved method and device to automatically detect physical connections of layer-2 bridges connected to the root bridge node.

According to a first aspect of the present invention there is provided a method of detecting physical connections between a root bridge node and layer-2 bridge nodes, the layer-2 bridge nodes being organised in a layer-2 cloud. The method comprises steps of sending a query message from a sending port of the root bridge node and starting a timer set to a waiting interval. After the timer expired the method comprises associating a port of the root bridge node with a layer-2 cloud. The association depends on if and on which port a response message to said query is received. If the response message is not received or is received only at the sending port then only the sending port is associated with said layer-2 cloud. If the response message is received at a port other than the sending port then the sending port and the receiving port are associated with said layer-2 cloud.

According to a second aspect of the present invention there is provided a bridge node adapted to operate as a root bridge node in a layer-2 communications network. The bridge node comprises a plurality of ports for connecting layer-2 clouds, wherein a layer-2 cloud being a network comprising a plurality of layer-2 bridges. The bridge node further comprises a transmitter adapted to send a query message from a sending port, a receiver adapted to receive a response message from a port, a processor and a timer. The processor is adapted to set the timer to a waiting interval after a query message had been sent from the sending port.

The processor is further adapted to associate a port of the root bridge node with a layer-2 cloud after said timer expires, wherein the association depends on if and on which port a response message to said query is received. If a response message to the query message is not received or is received only at the sending port then only the sending port is associated with said layer-2 cloud. If a response message is received at a port other than the sending port then the sending port and the receiving port are associated with said layer-2 cloud.

According to a third aspect of the present invention there is provided a layer-2 communications network comprising a bridge node as defined above.

Further features of the present invention are as claimed in the dependent claims.

The present invention provides the benefit of automated configuration of a root bridge nodes, which in turn prevents possible configuration errors caused manual configuration. Additionally, the present solution allows for a quick reaction and configuration update in case of change in topology of the layer-2 clouds connected to the root bridge node. The present invention allows avoiding possible manual misconfiguration that could happen in the prior solutions where the root bridge node has to be manually configured with a static association between their ports and the subtended layer 2 clouds.

DETAILED DESCRIPTION

The mechanism described in embodiments of this invention is based on a protocol having the main goal to automatically detect physical connections of layer-2 bridges connected to a root bridge node. This protocol is implemented in the root bridge node and in the layer-2 bridge nodes in the layer 2 cloud(s). This protocol does not follow the port role status created by RSTP protocol in layer-2 cloud, but is propagated on ports of layer-2 bridge nodes, travelling across either Discarding, Learning or Forwarding port states. Discarding port state prevents the forwarding of data frames. Learning port state accepts data frames to populate the MAC address table, but without forwarding. Forwarding port state forwards data frames, assuring the learning phase as well.

To implement the method in one embodiment of the present invention a root bridge node should be already elected, or the configuration of the network must be such that a node that will assume the role of the root bridge is well known. In embodiments of the present invention a root bridge node is a layer-2 bridge node that has been elected or otherwise configured to perform the role of a root. Procedures for election and/or configuration as a root are well known in the art (described e.g. in IEEE 802.1D) and will not be discussed in this document.

With reference toFIG. 2andFIG. 4an embodiment of the method of detecting physical connections between a root bridge node400and layer-2 bridge nodes402-410organised in a layer-2 cloud484is described below. Two more layer-2 clouds,486and488are shown inFIG. 4. The method starts with sending204a query message from a sending port of the root bridge node and starting206a timer. The timer is set to a waiting interval in which a response is supposed to be received by one or more ports of the root bridge node. A processor implementing the method in the root bridge node waits,208,210, until the timer expires. Once the timer expired208the method comprises associating214,216one or more ports of the root bridge node with a layer-2 cloud.

Only one port is associated,216, with the layer-2 cloud if no response message has been received or if the response message is received at the sending port,212.

More than one port is associated with the layer-2 cloud if the response message is received at a port (or ports) other than the sending port,212. In this situation the sending and the receiving ports are associated214with the layer-2 cloud.

The root bridge node has a plurality of ports and in order to have a full picture of all layer-2 clouds connected to the root bridge node it must be determined to which layer-2 cloud which port is connected. In a preferred embodiment the root bridge node sends a query message from its first port and once the method is completed for this first port the root bridge node repeats the step for its next unassigned port and so on. Unassigned, as used above, means that the port is not associated with (assigned to) any Layer-2 cloud. Deciding which port of a root bridge node is the first one is not the subject matter of this invention and can be done in many various ways. In an alternative embodiment query messages are sent from all ports without waiting for a response message. Sending messages from all ports at the same time can provide the same result, but this implementation has to correlate the received answers in case more than one port belongs to the same layer-2 cloud and has to resolve possible inconsistency. Performing the method for individual ports is more effective than sending query messages from all ports at the same time (or at least without waiting for completing the method for one port before sending another query message) because there may be clouds (e.g. clouds484and486) that are connected to the bridge node400via more than one port. In these situations sending a query message from one port results in assigning more than one port to one layer-2 cloud and this assigned receiving port does not have to be investigated further. Therefore, it is preferred to send the query messages sequentially from the ports and wait for the timer expiration.

In the example illustrated inFIG. 7when a response to a query message sent from port421is received, arrow702, at port422both ports are associated with the same layer-2 cloud and there is no need to send a query message from the port422.

On the other hand, sending query messages from all ports may result in associating the same layer-2 cloud with the same ports multiple times and would require additional processing in order to eliminate these multiple associations of the same cloud.

Layer-2 cloud ID is an identification of a layer-2 cloud defined autonomously by the root bridge node.

In a preferred embodiment the root bridge node400creates a query message (also known as Layer-2 Cloud detection query message) having at least one of the following:a unique Checking Session ID value,1010, that has the goal of uniquely identifying the checking session originated by the Root Bridge and/ora unique Layer 2 Cloud ID value,1012, associated with the port from which the root bridge node starts the Checking Session ID.

In one embodiment, in which only the Checking Session ID is used in the message, the layer-2 bridges do not know the Cloud ID assigned by the root bridge. It is enough if the root bridge node keeps the association between Checking Session ID and the Cloud ID. From a protocol perspective, the Cloud ID value makes sense for root bridge only, while the Checking Session ID value is used by Root Bridge and the layer-2 bridges in order to decide whether to forward the query message or not. If no Cloud ID value is carried inside query message, this forces the Checking Session ID to be always different among every discovery sessions originated by the root bridge.

It is also possible to use only Cloud ID value in the query message. In this embodiment the layer-2 bridges would not be able to distinguish between messages from different sessions and would discard messages if the same cloud ID has already been received to prevent loops. This will work as long as associations between the Cloud ID and the ports on layer-2 bridges have a defined time-to-live parameter. The time-to-live parameter for the association between the Cloud ID and the ports on layer-2 bridges is set based on a value Time-To-Live TLV (type-length-value),1014, carried in the LLDPDU message,1004.

It has to be understood, however, that using only Cloud ID in the query message in order to decide whether to forward or not the query message can be problematic. This is because, after a first period in which all local layer-2 bridge ports are associated with that Cloud ID, the query message will not be more forwarded until the next time-to-live interval is expired. This means that query messages with this Cloud ID value sent during time-to-live interval would be wasted.

Therefore, in a preferred embodiment Checking Session ID,1010, and Layer 2 Cloud ID,1012, values are used in the query messages1006. The advantage of using both ID values is that Cloud ID and Checking Session ID values allow the protocol to vary Checking Session ID independently among various Cloud IDs. Additionally, the use of Cloud ID inside the query message, allows the operator to understand what cloud the layer-2 bridge belong to with a simple SNMP GET.

In one embodiment the query messages1006also comprises L2CD Message Type field,1008, which defines the type of message sent. Initially only Query type message is required. In the future, other message types can be created in order to regulate further specific communication between root bridge node and bridge node.

In a preferred embodiment the root bridge node,400, sends several (i.e. more than one) query messages from the same port, in order to assure that a loss of a single message does not affect the layer-2 cloud detection mechanism. In one embodiment the query message is addressed to a Destination MAC Address belonging to Reserved Group MAC Address pool.

When query messages are sent multiple times they are, preferably, sent periodically with a Query Interval in order to determine or verify the current physical connections in a layer-2 cloud. This embodiment also requires a Waiting Interval in which a response is supposed to be received by one or more of ports of the root bridge (different from the port the query message was sent from) in order to associate the sending port and all ports that received the response to the same layer-2 cloud. In a preferred embodiment the Waiting Interval should be greater than the Query Interval and the Query Interval should be equal or greater then number of ports*Waiting Interval.

In a preferred embodiment the Query Interval is longer than the Waiting Interval because if the root bridge node400receives a response it means that the query had not been lost and then there is no need to send another query. If the root bridge node400does not receive a response it may be that the sending port is the only one port attached to this particular layer-2 cloud or it may be that the query was lost en route. In this situation repeating sending of the query message can clarify this.

Also in a preferred embodiment the Query Interval is long enough to allow the root bridge node400to investigate all its ports according to the configured Waiting Interval for each port, in order to limit the amount of control traffic (i.e. the number of query messages sent). This means that preferably the Query Interval is equal or greater than number of ports*Waiting Interval as explained above.

Also preferably, the Query Interval and the Waiting Interval are configurable in a network management system.

In a preferred embodiment the response message received by the root bridge node,400, is the same as the query message that was sent by said root bridge node,400. This limits processing performed by the layer-2 bridges that receive and forward the query message. It is, however, possible that the response message is different from the query message.

In a preferred embodiment the protocol1002defined in IEEE 802.1AB standard, extended to the needs of this invention is used to carry the query message. The LLDPDU1004message defined in 802.1AB is adopted for all mandatory components defined in the standard like: Chassis ID, Port ID and Time-To-Live TLV,1014. After all protocol specific TLV, the final mandatory End-Of-LLDPDU TLV will be inserted. Each LLDPDU message1004is addressed to the “Nearest Customer Bridge” reserved MAC address defined in 802.1AB. Each LLDPDU message can be encapsulated in a specific and configurable VLAN. The LLDPDU is adapted to create the query message1006in as shown inFIG. 10. This adaptation is obtained via “Organizationally Specific TLVs” foreseen by the 802.1AB.

In the following tables the proposed protocol's details are defined:

The L2CD TLV (Layer-2 Cloud Detection TLV) format is as follow:Type=1 byte; states the L2CD TLV component.Length=1 byte; states the TLV Value length in bytes.Value=variable length; contains the specific type information.

With reference toFIGS. 2, 3 and 5 to 9the method according to embodiments of the present invention will be described in more details below. After sending204a query message502, the root bridge node400arms a timer206to a defined Waiting Interval in which it waits a response from one of its ports. In a preferred embodiment this timer is configurable. The query message502, as shown inFIG. 5, is received at port1of a layer-2 bridge402.

The root bridge node400associates the Layer-2 Cloud ID sent in the query message502with its port421as shown inFIG. 6.

Handling of the query message after it has been sent from the root bridge node will now be described with reference toFIG. 3andFIGS. 6-9.

FIG. 6shows the layer-2 bridge,402, located inside the layer-2 cloud that after receiving,302, the query message at its port1, checks if the Checking Session ID and/or Layer-2 Cloud ID values carried in the query message are already associated with the receiving port,304. If not, then the layer-2 bridge402forwards,308, this message through its ports2and3(arrows602and604), but not through port1where the message was received. The query message is forwarded to layer-2 bridges404and406. The layer-2 bridge associates,310, each egress port (i.e. ports2and3) with this Checking Session ID value and/or Layer-2 Cloud ID value. The association remains valid until the layer-2 bridge402receives a new Checking Session ID or until the time-to-live parameter (associated to Time-To-Live TLV value),1004expires.

FIG. 7shows a layer-2 bridge406forwarding further the query message from its ports1and2, arrows702and704. port2of the layer-2 bridge406sends,704, the query message to port1of a layer-2 bridge408whereas port1of the layer-2 bridge406forwards,702, the query message to the root bridge node400. The same operations of associating the received Layer 2 Cloud ID and/or Checking Session ID with the ports of the layer-2 bridge406are performed as discussed earlier.

In similar fashion the layer-2 bridge404forwards,706, the query message to layer-2 bridge410. This process continues on each Bridge in the Layer 2 Cloud.

When the root bridge node400receives the query message back from another port (or ports),422, different from the sending one421, it associates the port from which the message has been sent,421, and all the ports where the message has been received,422, as belonging to the same Layer-2 Cloud ID. When no query message is received within the Waiting Interval, only the sending port is associated with the Layer-2 Cloud ID.

When a layer-2 bridge located inside the layer-2 cloud receives,302, a query message with a Checking Session ID and/or Layer-2 Cloud ID already associated,304, with the receiving port, it discards,306, this query message avoiding any possible endless loop. This is illustrated inFIG. 8where two copies,802,804, of the same query message are sent in opposite directions between layer-2 bridges408and410.

After expiration of the Waiting Interval for a first Layer 2 Cloud ID and the consequent association between Layer 2 Cloud ID of the layer-2 cloud484and ports421and422, the root bridge node400selects the next available port423(the first not associated port from its port list) and selects a new Layer-2 Cloud ID. Then it starts a new Checking Session by sending a query message, arrow902, with the new Checking Session ID and/or new Layer-2 Cloud ID to layer-2 bridge412and waits for another Waiting Interval as illustrated inFIG. 9.

This process goes on until all the ports in the list, have been verified.

In a preferred embodiment the association between the at least one of the Layer-2 Cloud ID or Checking Session ID values and the ports of the layer-2 bridge402-410has a defined time-to-live value, which means it will not last for ever. Introducing the time-to-live value have the advantageous effects that the table (or any other data structure) storing these associations in the layer-2 bridge will not grow too big because after the TTL expires the corresponding entry is removed from the table. Additionally if the query message contains only the Layer-2 Cloud ID keeping the associations would result in new query messages being discarded, but removing these associations periodically allows for refreshing and updating the associations between layer-2 clouds and the ports of the root bridge node400.

When a topology change notification (TCN) is received202by the root bridge node400from a port the layer-2 cloud information is kept valid, but a new checking session process is started without waiting for the next scheduled checking session time (i.e. without waiting for expiration of the current Query Interval). This reception of TCN202is depicted with a dashed line inFIG. 2to illustrate it as an alternative initiation of the method, the other alternative being the periodic sending of the query messages with a Query Interval.

A bridge node,4000, in one possible embodiment of the present invention is illustrated inFIG. 11. The bridge node,4000, is adapted to operate as a root bridge node400in an Ethernet network450. In alternative embodiments the network450can be Token Ring, Wireless LAN network. A person skilled in the art would also characterise this network as a layer-2 communications network reflecting the OSI (Open Systems Interconnection) level at which the protocols work. The bridge node4000comprises a plurality of n ports1104for connecting a network comprising a plurality of layer-2 bridges. The networks of layer-2 bridges are commonly known as layer-2 clouds. The ports1104have comprises transmitters1102which transmit a query message from their associated ports1104. The bridge node,4000, further comprises receivers1106associated with the ports1104. A receiver receives a response message from a port1104. The bridge node,4000, also comprises a switching matrix (a switch)1114located between a processor1108and the transmitters/receivers1102/1106. A query message is originated by the processor1108and is directly allocated to one of the ports. The processor1108can send a query message through any of the ports1104by sending said query message to the switching matrix1114, which directs the query message to appropriate port1104based on information from the processor1108. In a preferred embodiment the processor1108comprises a timer1110, wherein the processor1108is adapted to set the timer1110to a waiting interval after a query message had been sent from a port1104. The processor1108is adapted to associate the port1104with a layer-2 cloud after said timer1110expires. The bridge node,4000, further comprises a memory1112for storing the associations and other information necessary for the processor1108to operate. As discussed earlier, with regards to the embodiments of the method of the invention if a response message to the query message is not received or is received at the sending port then only the sending port is associated with said layer-2 cloud. However, if a response message is received at a port different than the sending port then the sending port and the receiving port are associated with said layer-2 cloud.

In one embodiment the timer1110is implemented as a software module in the processor1108, as illustrated inFIG. 11. In an alternative embodiment, illustrated inFIG. 12, the timer1110is implemented as a separate hardware module.

The bridge node4000is adapted to operate as a root bridge node in a layer-2 communications network450as described in embodiments of the method of the present invention.

Finally, the present invention can also be implemented as a layer-2 communications network450comprising a bridge node4000operating as a root bridge node400in accordance with embodiments of the method described earlier.