Bridge device, method of controlling bridge device, and control program

The bridge device is connected to a layer-2 network. The Query message distribution unit discriminates, distributes, and outputs the normal Query messages and abnormal Query messages among the received Query messages. The abnormal message processing unit counts the number of received abnormal Query messages, and the normal message processing unit counts the number of normal Query messages. The router connection state judgment unit judges that the bridge device is a bridge device that is adjacent to the router when only the number of normal Query messages is counted and outputs an instruction to change the bridge ID to the STP processing unit. The STP processing unit establishes the bridge ID as a minimum value and renders the bridge device a root bridge.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from the prior Japanese Patent Application No. 2006-97544, filed on Mar. 31, 2006, the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to each of bridge devices in a layer-2 network, a method of controlling the bridge devices, and a control program, and, more particularly, to a bridge device or the like of a layer-2 network that permits the efficient transfer of multicast data.

2. Description of the Related Art

Conventionally, there is a technology that data are distributed by multicasting such as the distribution of moving images to a fixed user terminal connected to a network.

In order to efficiently construct such a network, a multicast routing protocol such as MLD (Multicast Listener Discovery Protocol) that corresponds with IPv6 (Internet Protocol Version 6) and IGMP (Internet Group Management Protocol) that corresponds with IPv4 (Internet Protocol Version 4) is used between the router and host.

In IGMP and MLD, a router sends a Query message at regular intervals and, when a terminal that has received this message wishes to receive multicast data, the terminal sends a Report message to the router. Thereafter, the router confirms the existence of a subordinate multicast reception terminal from the existence of the Report message. The router transfers multicast data of the interface to which the multicast reception terminal is connected only when the multicast reception terminal exists. As a result, an effective application of network resources can be attempted.

Meanwhile, when the network that connects the router and host is a so-called layer-2 network constituted by a plurality of bridge devices, redundant control by a protocol known as STP (Spanning Tree Protocol) is performed within the network.

STP is a protocol standardized by the IEEE (Institute of Electrical and Electronic Engineers) 802.1D. STP is a protocol that uniquely determines a path between bridge devices by suppressing a data frame relay via a predetermined port when a physical redundant path is held between optional bridge devices on the network

More precisely, the path is determined as follows. That is, a control packet known as a BPDU (Bridge Protocol Data Unit) is sent and received between bridge devices and the bridge device having the smallest bridge ID is determined as a root bridge device.

Further, the route is set in a tree shape from the root bridge device to the respective bridge devices and the transfer of data to a path (links) other than this path is broken. As a result, the path between optional bridge devices connected to the network is uniquely determined.

When two or more routes exist between optional bridge devices, the path is determined by selecting the path with the smallest cost (value corresponding with the bandwidth of the network) and breaking the other path.

FIG. 10shows a constitutional example of a layer-2 network and shows an aspect in which the path is determined by the STP above and multicast data is transferred.

Each of the bridge devices210to250are mutually connected to a network100and the respective bridge devices210to250are each connected to their respective hosts110to150. A router170is connected between the host110, which is a multicast transmission terminal, and the bridge device210.

In the case of this example, the bridge230is set as a root bridge and a path X between the bridge device210and bridge device250is broken. Further, because path X is broken when multicast data are transferred from the host110to the host150, data are transferred from the bridge device210via the bridge device220and so forth.

Conventional technology relating to the transfer of such multicast data includes technology in which two ports connected to either the router or the adjacent switch are set as uplink paths whereby multicast data are always transmitted, and a transmission route between ports is controlled on the basis of a multicast filter table created on the basis of the port receiving a participation message (Japanese Patent Application Laid Open No. 2004-112724, for example).

However, STP determines the root bridge and the break point without conscious of which path the multicast data is communicated, especially conscious of where the router is disposed on the network.

Therefore, when the path shown inFIG. 10is determined, data is transferred to the bridge device220or the like without path X being used. Hence, the usage efficiency of the network100becomes very poor. In the case of large-capacity data, such a moving image and so on, the transfer of data to and from another host is sometimes also delayed.

Further, when the path shown inFIG. 10, for example, is also determined by using the multicast filter table created on the basis of participation messages as per Japanese Patent Application Laid Open No. 2004-112724 above, the exact same problems exist.

SUMMARY OF THE INVENTION

Therefore, the present invention is conceived in view of these problems and an object thereof is to provide a bridge device that generates an efficient transfer route in a layer-2 network and increases the usage efficiency, a method of controlling the bridge device, and a control program.

In order to achieve the above object, a first embodiment of the present invention is a bridge device in a layer-2 network, having: a setting unit which sets the bridge device as a root bridge by making a bridge ID of the bridge device smaller than the bridge IDs of other bridge devices when the bridge device is adjacent to a router connected to the layer-2 network.

Further, an another embodiment of the present invention is the bridge device, further having: a message transmission unit which transmits an abnormal Query message together with a normal Query message to the other bridge devices, with respect to the Query message representing a message for confirming whether or not there is participation in a multicast group that is sent by the router,

Further, an another embodiment of the present invention is the bridge device, wherein the message transmission unit transmits a control message that is used in order to judge whether or not the bridge device is adjacent to the router, instead of the abnormal Query message.

Further, an another embodiment of the present invention is the bridge device, further having: a router connection state judgment unit which judges whether or not the bridge device is adjacent to the router by comparing, with respect to a Query message representing a message for confirming whether or not there is participation in a multicast group that is sent by the router, a first reception number indicating the number of normal Query messages received and a second reception number indicating the number of abnormal Query messages received, and which outputs an instruction to change the bridge ID when judged that the bridge device is adjacent to the router.

Further, an another embodiment of the present invention is the bridge device, wherein the router connection state judgment unit judges that the bridge device is adjacent to the router when only the first reception number is counted.

Further, an another embodiment of the present invention is the bridge device, wherein the router connection state judgment unit judges that the bridge device is not adjacent to the router when the first reception number and the second reception number are counted as having substantially the same count number.

Further, an another embodiment of the present invention is the bridge device, further having: a router connection state judgment unit that judges whether or not the bridge device is adjacent to the router on the basis of the reception history of a BPDU which is transferred between the bridge devices and represents a control packet that stores data including the bridge ID.

Further, an another embodiment of the present invention is the bridge device, wherein the router connection state judgment unit receives only a Query message representing a message for confirming whether or not there is participation in a multicast group that is sent from the router and judges that the bridge device is adjacent to the router when the BPDU is not received from the reception history.

Further, an another embodiment of the present invention is the bridge device, wherein the router connection state judgment unit judges that the bridge device is not adjacent to the router when both a Query message and the BPDU are received.

Further, in order to achieve the above object, an another embodiment of the present invention is a method of controlling a bridge device in a layer-2 network, having a step of setting the bridge device as a root bridge by making a bridge ID of the bridge device smaller than the bridge IDs of other bridge devices when the bridge device is adjacent to a router that is connected to the layer-2 network.

Further, in order to achieve the above object, an another embodiment of the present invention is a control program that causes a computer to execute a setting processing which sets a bridge device as a root bridge by making a bridge ID of the bridge device smaller than the bridge IDs of other bridge devices when the bridge device in a layer-2 network is adjacent to a router connected to the layer-2 network.

Further, in order to achieve the above object, an another embodiment of the present invention is a layer-2 network, having: a router and a plurality of bridge devices, wherein the bridge device that is adjacent to the router among the plurality of bridge devices is set as a root bridge by making a bridge ID of the bridge device smaller than the bridge IDs of other bridge devices.

Further, in order to achieve the above object, an another embodiment of the present invention is a bridge device in a layer-2 network, having: a setting unit which sets the bridge device as a root bridge by storing an ID that is smaller than the bridge IDs of other bridge devices in a region where a root ID of a BPDU is stored when the bridge device is adjacent to a router connected to the layer-2 network.

Further, an another embodiment of the present invention is the bridge device, further having: a router connection state judgment unit which judges whether or not the bridge device is adjacent to the router by comparing, with respect to a Query message that represents a message for confirming whether or not there is participation in a multicast group that is sent by the router, a first reception number indicating the number of normal Query messages received and a second reception number indicating the number of abnormal Query messages received.

Further, in order to achieve the above object, an another embodiment of the present invention is a method of controlling a bridge device in a layer-2 network, having a step of setting the bridge device as a root bridge by storing an ID that is smaller than the bridge IDs of other bridge devices in a region where a root ID of a BPDU is stored when the bridge device is adjacent to a router connected to the layer-2 network.

Further, in order to achieve the above object, an another embodiment of the present invention is a control program that causes a computer to execute: a setting processing which sets a bridge device as a root device by storing an ID that is smaller than the bridge IDs of other bridge devices in a region where a root ID of a BPDU is stored, when the bridge device in a layer-2 network is adjacent to a router connected to the layer-2 network.

Further, in order to achieve the above object, an another embodiment of the present invention is a layer-2 network having: a router, and a plurality of bridge devices, wherein the bridge device that is adjacent to the router among the plurality of bridge devices is set as a root bridge by storing an ID that is smaller than the bridge IDs of other bridge devices in a region where a root ID of a BPDU is stored.

The present invention is capable of providing a bridge device that generates an efficient transfer route in a layer-2 network and increases the usage efficiency, a method of controlling a bridge device, and a control program.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments for the present invention will be described hereinbelow with reference to the drawings.

FIG. 1is a constitutional example of a layer-2 network that has bridge devices10to50to which the present invention is applied.

Each of the bridge devices10to50is connected in a ring shape to the network100. The respective bridge devices10to50are connected to the hosts110to150respectively. Further, a router170is connected between the host110and bridge device10.

Further, the network100connecting the router170to the hosts120to150of this embodiment is a so-called layer-2 network constituted by a plurality of bridge devices10to50.

FIG. 2shows a constitutional example of the bridge device10. The other bridge devices20to50also have the same constitution.

The bridge device10has Query message reception units11-1to11-n, Query message transmission units12-1to12-n, an IGMP snooping processing unit13, and an STP processing unit14.

The Query message reception units11-1to11-n receive Query messages from the adjacent devices (the bridge devices20and50that are adjacent to the bridge device10or the router170that is adjacent to the bridge device10). The Query message reception units11-1to11-n exist for each port of the bridge device10. In the example ofFIG. 2, n (n is an integer of two or more) reception units11-1to11-n exist.

Further, the Query message is transmitted from the router170to each of the bridge devices10to50and is therefore a message for confirming whether each of the hosts110to150is participating in a multicast group.

The Query message transmission units12-1to12-n transmit the Query message to the adjacent devices (the bridge devices20and50). Likewise, there is an equivalent number of ports. n exist in the example inFIG. 2.

The Query message distribution unit131is connected to the message reception units11-1to11-n of the respective ports and judges whether the received Query message is abnormal or normal. Further, the Query message distribution unit131outputs abnormal messages to the abnormal message processing unit132and normal messages to the normal message processing unit133, on the basis of the judgment result.

The Query message distribution unit131judges whether the Query message is a normal message or an abnormal message as follows.

FIG. 3Ashows an example of the IGMP message format. The IGMP message format is constituted by a ‘Type’ field indicating the type of message, a ‘MaxResp (Response) Time’ field indicating the standby time permitted for the transmission of a response report, a ‘Checksum’ indicating one complement of sixteen bits of a total of complements of one of the IGMP message (the total value of the values stored in fields other than the ‘Checksum’ field, for example), and a ‘Group Address’ indicating a group address or the like.

In the case of the normal Query message, as shown inFIG. 3B, a normal calculation value is stored in the ‘Checksum’ field and, in the case of the abnormal Query message, as shown in3C, a calculation value that is not correct is stored in the ‘Checksum’ field.

The Query message distribution unit131calculates the values contained in fields other than the ‘Checksum’ field of the received Query message and judges whether the calculation result matches the value stored in the ‘Checksum’ field. In the event of a match, the Query message is judged to be normal and, in the event of no match, the Query message is judged to be abnormal.

FIG. 4Ashows an example of the MLD message format. An MLD Query message is also similarly judged from the ‘Checksum’ field. An example of a normal Query message and an example of an abnormal Query message are shown inFIGS. 4B and 4Crespectively.

The abnormal message processing unit132counts the number of abnormal messages that are input. The count number is output to the router connection state judgment unit134as the abnormal message number.

The normal message processing unit133counts the number of normal messages that are input and outputs the count number as the normal message number. The normal message processing unit133outputs the normal messages to the message transfer unit135.

The router connection state judgment unit134judges whether the bridge device10is adjacent to the router170from the abnormal message number from the abnormal message processing unit132and the normal message number from the normal message processing unit133. The router connection state judgment unit134outputs a bridge ID change instruction to the STP processing unit14when it is judged that the bridge device10is adjacent to the router170.

Further, in this embodiment, the Query message is output to the adjacent devices from a port other than the port receiving the Query message. For example, when the Query message is received by the Query message reception unit11-1of port ‘1’, the Query message (normal message and abnormal message) is transmitted from the Query message transmission unit12-2of port ‘2’.

That is, the bridge device10inFIG. 1is connected by port ‘1’ to the router170, connected by port ‘2’ to the bridge device20, and connected by port ‘3’ to the bridge device50, and it is assumed at this point that the path X between the bridge device10and bridge device50is broken. Here, when the bridge device10receives the Query message from the router170, the bridge device10transmits the Query message (normal message and abnormal message) from a port other than port ‘1’ that received the Query message and broken port ‘3’, that is, port ‘2’.

The STP processing unit14changes the bridge ID, for example, bridge priority, to ‘0’ on the basis of the bridge ID change instruction from the router connection state judgment unit134. That is, the bridge device10is set as the root bridge.

FIG. 5Ashows the flow of the Query message.

First, the Query message is transferred from the router170to the adjacent bridge device10. The bridge device10of this embodiment transfers the transferred normal Query message and the abnormal Query message to the bridge device20that is adjacent to the bridge device10. The bridge device20receives both the normal Query message and the abnormal Query message. The bridge device20then transfers the normal Query message and abnormal Query message to the adjacent host120.

As shown inFIG. 5A, the router170transfers only the normal Query massage to the adjacent bridge device10. Further, the bridge device10receives only the normal Query message. On the other hand, the bridge device20adjacent to the bridge device10receives the normal Query message and the abnormal Query message.

Because the bridge device10adjacent to the router170receives only the normal Query message, when the number of messages is counted, only the normal Query messages are incremented.

On the other hand, the bridge device20that is not adjacent to the router170but is adjacent to the bridge device10receives both the normal and abnormal Query messages from the bridge device10and, therefore, when the proportions of the normal messages and abnormal messages transferred from the bridge device10are substantially the same, both the normal and abnormal message count numbers are incremented by substantially the same numbers.

Therefore, the router connection state judgment unit134of each bridge device10or similar can judge whether its own bridge device10or similar is adjacent to the router170by comparing the number of normal Query messages with the number of abnormal Query messages.

Some kind of error sometimes arises in the transmission line between the router170and the bridge device10or the like and the Query message is sometimes the abnormal message. In this embodiment, in order to reliably judge whether one's own bridge device10is adjacent to the router170, the number of messages is counted by the router connection state judgment unit134.

Thus, in this embodiment, the bridge device10adjacent to the router170is set as the root bridge. According to the STP routing protocol, the farthest path from the root bridge is normally broken and, as shown inFIG. 1, path Y between the bridge device30and bridge device40is broken.

Therefore, multicast data are transferred from the host110to the host150by using path X. Accordingly, an efficient data transfer route is generated and the usage efficiency of the network100can be improved.

FIG. 6is an example of a flowchart showing the processing operation of the bridge device10. The Query message reception units11-1to11-n of a certain port start processing when the Query message from the adjacent device is received (S10).

Thereafter, the Query massage distribution unit131checks the normality of the Query message (S11).

When the Query message is normal (‘normal’), the normal message processing unit133counts the number of normal Query messages (S12).

Thereafter, the Query message is transferred to the adjacent device by the message transfer unit135and the Query message transmission units12-1to12-n (S13).

The message transfer unit135then generates the abnormal Query message and transmits the abnormal message to the adjacent device via the Query message transmission units12-1to12-n (S14). The serial processing then ends (S15).

Meanwhile, when it is judged that the Query message is abnormal by the Query message normality check (‘abnormal’ in S11), the abnormal message processing unit132counts the abnormal Query messages (S16).

Thereafter, the router connection state is judged (S17) and, when it is judged that one's own bridge device10to50is adjacent to the router170(‘router adjacent’ in S17), the router connection state judgment unit134outputs the bridge ID change instruction.

The STP processing unit14then sets the bridge ID to the minimum value (Bridge Priority is ‘0’, for example) (S18). The serial process then ends (S15).

Further, the processing of the router connection state judgment (S17) is executed after the normal Query messages and abnormal Query messages are counted (S12, S16).

On the other hand, when it is judged by the router connection state judgment that one's own bridge device10to50is not adjacent to the router170(‘router not adjacent’ in S17), the bridge ID is set to the original value (S19).

The processing of S19is processing that is assumed when the router170has moved to another location. That is, a certain bridge device10to50is set as the root bridge and when the router170then moves to another location, the bridge device10to50of the root bridge is no longer the root bridge. In this case, the bridge device10to50is not the root-bridge bridge device and must be restored to the original bridge device ID. In the event of such a situation, the processing of S19is executed.

The serial processing then ends (S15).

In this example, the message transfer unit135transfers the abnormal Query message together with the normal message. However, a newly defined control message other than one's own abnormal Query message may be transferred and it may be judged whether one's own bridge device10to50is adjacent to the router170. This judgment is possible because the bridge device10, which is adjacent to the router170, does not receive the control message but receives the normal Query message.

A further embodiment will be described next. In the previous example, it was judged whether one's own bridge device10to50is adjacent to the router170by using the abnormal Query message. The following example is an example in which it is judged whether one's own bridge device10to50is adjacent to the router170from actual reception results of a BPDU transferred by snooping between the bridge devices10to50. The network constitutional example is the same the example above (SeeFIG. 1).

The BPDU is a control packet that is transferred between the bridge devices10to50for root-bridge selection and path selection and so forth in STP.FIG. 7shows an example of the format of a transferred BPDU.

As a result of the transmission and reception of the BPDU, the ‘bridge ID’ contained in the BPDU is compared with those of the bridge devices10to50and the bridge device10to50having the smallest value becomes the root bridge. The BPDU is transferred at two second intervals, for example.

The BPDU is sent and received between the bridge devices10to50but is not transmitted from the router170to the bridge devices10to50. In this example, the bridge device10is set the rout bridge as the bridge adjacent to the router170by this quality.

FIG. 8shows a constitutional example of the bridge device10of this embodiment. The other bridge devices20to50also have the same constitution.

The bridge device10has Query message reception units11-1to11-n, Query message transmission units12-1to12-n, BPDU reception units15-1to15-n, BPDU transmission units16-1to16-n, an IGMP snooping processing unit13, and an STP processing unit14.

The BPDU reception units15-1to15-n, BPDU transmission units16-1to16-n all serve to receive and send the BPDU respectively and exist in each port as in the same case of the Query message reception units11-1to11-n and so on.

The Query message reception units11-1to11-n and Query message transmission units12-1to12-n are the same as in the example ofFIG. 2.

The IGMP snooping processing unit13has, similarly to the IGMP snooping processing unit13inFIG. 2, a Query message distribution unit131, a normal message processing unit133, a router connection state judgment unit134, and a message transfer unit135. When compared with the example ofFIG. 2, this is a constitution in which there is not abnormal message processing unit132.

The Query message distribution unit131judges whether the received Query message is normal or not, and outputs the normal Query message to the normal message processing unit133. When it is judged that the abnormal Query message has been received, the message is discarded. However, the abnormal Query message of this example differs from that of the previous example in being an abnormal message that is produced as a result of a fault or the like in the transmission line and is not an abnormal message that is intentionally generated.

The normal message processing unit133outputs, to the router connection state judgment unit134, a Query message reception port information indicating the number of the port via which the normal Query message is received.

The STP processing unit14has a BPDU reception processing unit141and a BPDU transmission processing unit142. The BPDU reception processing unit141is connected to the BPDU reception units15-1to15-n of the respective ports, inputs the received BPDUs, and saves the BPDU actual reception result for each port number.

For example, the STP processing unit14saves information such as the fact that the BPDU actual reception result for port number ‘1’ is ‘OFF’ (the BPDU has not yet been received via port number ‘1’) and that the BPDU actual reception result for port number ‘n’ is ‘ON’ (the BPDU has been received via port number ‘n’), and so forth.

The BPDU reception processing unit141outputs information related to the actual reception results as BPDU reception port information to the router connection state judgment unit134.

The BPDU transmission processing unit142generates the BPDU by storing information required for the BPDU, and so forth, and outputs the BPDU to the BPDU transmission units16-1to16-n. The generated BPDU is output from the BPDU transmission units16-1to16-n.

On the other hand, the router connection state judgment unit134of the IGMP snooping processing unit13judges whether its own bridge device10is a bridge device that is adjacent to the router170or not from Query message reception port information from the normal message processing unit133and BPDU port information from the STP processing unit14.

When it is judged that the bridge device10is adjacent to the router170, the outputting of a bridge ID change instruction to the STP processing unit14is the same as that described in the previous example.

FIG. 5Bshows the flow of the normal Query message and the flow of the BPDU. The normal Query message is transmitted from the router170and transferred to the host120via the bridge devices10and20. On the other hand, the BPDU is sent and received between the bridge devices10and20.

Therefore, the bridge device10adjacent to the router170is able to judge the adjacent device is the router170, when it is confirmed that the normal Query message has been received via a certain port but the BPDU has not been received, from the Query message reception port information and BPDU port information.

FIG. 9is an example of a flowchart showing the processing operation of such the bridge device10.

The processing is started when the Query message reception units11-1to11-n receive the Query message from the adjacent device (S30).

Thereafter, the Query massage distribution unit131checks the normality of the received Query messages (S31). When the Query message is abnormal (‘abnormal’ in S31), the massage distribution unit131discards the message.

On the other hand, when the Query message is normal (‘normal’ in S31), the Query message is transferred from the message transfer unit135to the adjacent device via the Query message transmission units12-1to12-n (S32).

Thereafter, the router connection state judgment unit134checks the BPDU actual reception result of the relevant port (S33). When the BPDU actual reception result for this port is that no BPDU has been received (in the case of ‘no BPDU received’), the router connection state judgment unit134judges that one's own bridge device10to50is a bridge device adjacent to the router170and outputs the bridge ID change instruction. The STP processing unit14then minimizes the bridge ID (Bridge Priority is then ‘0’, for example) (S34). The serial processing then ends (S35).

On the other hand, when the BPDU actual reception result for this port is that the BPDU has been received (in the case of ‘BPDU received’ in S33), the router connection state judgment unit134judges whether there is a port adjacent to the router170for another port or not (S36). The BPDU actual reception result is judged for all the ports.

If a port is adjacent to the router170(YES), because the bridge ID has already been minimized in S34, there is no particular processing executed and the serial processing ends (S35).

On the other hand, if a port is adjacent to the router170(NO in S36), the bridge ID is set to the original value (S37). This processing is also processing that considers the movement of the router170as per the previous example (S19inFIG. 6). The serial processing then ends (S35).

So too in this example, the bridge device10adjacent to the router170is set as the root bridge. Further, as shown inFIG. 1, because the longest path Y from the root bridge is broken, an efficient data transfer rate is generated as per the previous example and the usage efficiency of the network100can be improved.

Furthermore, so too in any of the earlier examples, because the bridge device10adjacent to the router170is constituted as the root bridge, a path is formed by a spanning tree algorithm that can be subjected to multicast communications (a topology is formed). A topology that permits efficient multicast communications can be automatically generated in the layer-2 network.

When the bridge device10is made the root bridge in the above example, the minimum value is established for the bridge ID by setting the Bridge Priority at ‘0’. Naturally, if the bridge ID can be minimized, a value other than ‘0’ is possible. For example, the bridge ID (Bridge Priority or the like) of the previously set root bridge is saved in the STP processing unit14of the respective bridge devices10to50and, during the STP processing of this example, the bridge ID can also be minimized by making the bridge ID smaller than the saved bridge ID.

Furthermore, as shown inFIG. 7, the BPDU has the field for storing the ‘root ID’ and normally stores the bridge ID of the root bridge. That is, the same ID is stored for the ‘root ID’ and ‘bridge ID’ of the BPDU transmitted by the root bridge.

For example, implementation can be as per the earlier example by making the ID stored in the ‘bridge ID’ the unaltered ID of one's own bridge device10to50and storing a smaller ID than the bridge ID of all the bridge devices in the ‘root ID’. The Processing is executed by the BPDU transmission processing unit142, for example.

Although a bridge device with the ‘root ID’ does not actually exist, because exactly the same path is generated when the bridge device10is made the root bridge, the same results are obtained when the bridge ID is minimized.

Moreover, in the above example, the transfer of multicast data to the network100was described. Naturally, in this embodiment, data transfers other than multicast transfers, such as unicast transfers, can also be implemented by the bridge devices10to50and afford the same operations and effects as the above example.

Furthermore, in the earlier examples, as the basis for judging whether the Query message is normal or abnormal, the judgment is made from the value stored in the ‘Checksum’ field. For example, a field that indicates whether the Query message is normal or abnormal may otherwise be added additionally by IGMP or MLD. The same operations and effects that can be implemented as per the above example are also afforded in this case.