METHOD FOR SUBSCRIBING TO MULTIBREADS IN A LOCAL AREA NETWORK MESH COMMUNICATION NETWORK

Abstract

In a mesh communication network, bridge devices use two parallel configurations: a first logical network configuration to route data packets point-to-point, using dynamic routing between the bridge devices; and a second logical network configuration to route data packets broadcast, using a spanning tree that eliminates potential loops. Upon receiving a subscription request (410) from a station device, each bridge device is instructed (414) to initiate a source search for the multicast data stream. When the multicast data stream is received via an input port of a bridge device, the bridge device is configured to switch the multicast data stream from the input port to an output port toward the station device, according to the first configuration. Figure to be published with the abbreviation: Fig. 4

Description

Title of the invention: METHOD FOR SUBSCRIBING TO MULTIBREADS IN A LOCAL AREA NETWORK MESH COMMUNICATION NETWORK technical field

[0001] The present invention relates to multicasting of data packets in a mesh communication network of the local area network type in which bridge devices are interconnected. STATE OF PRIOR ART

[0002] Several solutions exist for creating a mesh communication network of the local network type, for example to interconnect wireless network extenders (e.g., WiFi) to a home gateway, and in particular bridge device technologies (“bridge device” in English).

[0003] However, within the framework of these solutions, a spanning tree is defined for broadcast and multicast transmissions in order to connect all the bridge devices, eliminating any loops in the mesh communication network. The loops in the mesh communication network then introduce redundancies that are used as backup paths if a primary path in the spanning tree fails. The spanning tree is then redefined to use such backup paths rather than the failed primary paths that were previously used. Nevertheless, at any given time, only the primary paths are used for all communications in the mesh communication network, thus preventing specific routing of data packets.Such a topology only allows for the optimization of communications to and from the root of said spanning tree.

[0004] For "multicast" type transmissions, there are two modes:

[0005] - a dense mode, in which each bridge device It constructs a spanning tree of which it is itself the root. It can then flood this spanning tree with a multicast data stream and then prune the branches where there are bridge devices not interested in the multicast data stream in question.

[0006] -a sparse-mode, in which a multicast data stream source registers with a central point, sometimes called a Rendez-Vous Point (or RVP), which is the root of the tree covering and from which the multicast data stream, provided by the source, floods the spanning tree.

[0007] It follows that, in the case of mesh communication networks, multicast transmissions can be improved. Description of the invention

[0008] It is desirable to overcome the aforementioned drawbacks of the prior art. In particular, it is desirable to provide a solution that improves the routing of data packets in multicast transmissions within such mesh communication networks, in order to better benefit from the redundancy offered by their mesh structure rather than relying on a spanning tree for the routing of these data packets.

[0009] A method for transmitting data packets in a mesh communication network of the local area network type is proposed here, which interconnects bridge devices, each bridge device using in parallel: a first logical network configuration, which is used to route data packets in point-to-point mode, and which is defined by dynamic routing between the bridge devices; and a second logical network configuration, which is used to route data packets in broadcast mode, and which is defined according to a spanning tree by blocking one or more ports of the bridge devices to eliminate one or more loops of the mesh communication network.The process involves: following a first subscription request received from a station device connected to the local network, instructing each bridge device to initiate a search for the source of the multicast data stream so that each bridge device transmits a second subscription request to the multicast data stream on each of its ports and ignores any such second subscription request to the multicast data stream originating from any other said bridge device. And when the multicast data stream is received via an input port of said bridge device, configuring said bridge device to switch the multicast data stream from the input port to an output port towards the station device according to the first logical network configuration.

[0010] Thus, the routing of data packets in multicast transmissions relies on the first configuration of the first logical network, and not on the second configuration of the second logical network, which makes it possible to optimize the routing of multicast transmissions in the mesh communication network of the local network type (lower routing cost compared to a solution where the spanning tree used for broadcasts is also followed for multicasts).

[0011] In a particular embodiment, the first subscription request is received from the station device by a said bridge device which relays the first subscription request to a centralizing bridge device which then sends each bridge device an instruction to start the search for the source of the multicast data stream.

[0012] In a particular embodiment, the subscription request received from the station device is received by a said bridge device which then sends to each bridge device an instruction to start the search for the source of the multicast data stream.

[0013] In a particular embodiment, each second subscription request is transmitted on behalf of the bridge device in question, although it is made on behalf of the station device in question.

[0014] In a particular embodiment, each bridge device implements a multicast data stream orientation table containing, for each multicast data stream passing through said bridge device: a Layer 3 address of the OSI (Open Systems Interconnection) model for said multicast data stream; a Layer 2 address of the multicast data stream, obtained by applying a conversion rule from said Layer 3 address of said multicast data stream; an identification of the input port of said bridge device for said multicast data stream; and an identification of each output port of said bridge device for said multicast data stream. Furthermore, each bridge device translates its multicast data stream orientation table into a Layer 2 OSI multicast data stream switching table.

[0015] Also proposed here is a computer program product comprising instructions that cause an implementation of the above process according to any one of the embodiments described, when the instructions are executed by a processor. Also proposed here is an information storage medium comprising instructions that cause an implementation of the above process according to any one of the embodiments described, when the instructions are read from the information storage medium and executed by a processor.

[0016] A bridge device is also proposed for use in a mesh communication network of the local area network type, the bridge device using in parallel: a first logical network configuration, which is used to route data packets in point-to-point mode, and which is defined by dynamic routing between bridge devices of the mesh communication network; and a second logical network configuration, which is used to route data packets in broadcast mode, and which is defined according to a covering tree by blocking one or more ports of the bridge devices of the mesh communication network to eliminate one or more loops.The bridge device includes electronic circuitry configured to: following a first subscription request received from a station device connected to the local network, instruct each bridge device in the mesh communication network to initiate a source search for the multicast data stream so that each bridge device in the mesh communication network transmits on each of its ports a second subscription request to the multicast data stream and ignores any such second subscription request to the multicast data stream from any other said bridge device in the mesh communication network; and when the multicast data stream is received via an input port of said bridge device, configure said bridge device to switch the multicast data stream from the input port to an output port towards the station device according to the first logical network configuration.. Brief description of the drawings

[0017] The features of the invention mentioned above, as well as others, will become clearer upon reading the following description of at least one exemplary embodiment, said description being made in relation to the accompanying drawings, among which:

[0018] [Fig-1] schematically illustrates a mesh communication network;

[0019] [Fig.2] schematically illustrates an example of a suitable hardware arrangement for implementing a mesh communication network device;

[0020] [Fig.3] schematically illustrates a flowchart of an algorithm for processing a subscription request to a multicast data stream, received from a station device by a bridge device;

[0021] [Fig.4] schematically illustrates a flowchart of a processing algorithm, by the centralizing bridge device, of a subscription request to a multicast data stream, relayed by a bridge device;

[0022] [Fig.5] schematically illustrates a flowchart of an algorithm for processing, by a bridge device, an instruction to launch a search for a source of a multicast data stream on behalf of a station device;

[0023] [Fig.6] schematically illustrates a flowchart of an algorithm for processing, by a bridge device, a subscription request to a multicast data stream, received from another bridge device;

[0024] [Fig.7] schematically illustrates a flowchart of a reaction algorithm, via a bridge device, to the reception of a multicast data stream for which a subscription request was previously made on behalf of a station device;

[0025] [Fig.8] schematically illustrates a multicast data flow orientation table;

[0026] [Fig.9A] schematically illustrates a first part of an example of setting up transmission of a multicast data stream in the mesh communication network;

[0027] [Fig.9B] schematically illustrates a second part of the example of setting up multicast data stream transmission in the mesh communication network;

[0028] [Fig.9C] schematically illustrates a third part of the example of setting up multicast data stream transmission in the mesh communication network;

[0029] [Fig.9D] schematically illustrates a fourth part of the example of setting up multicast data stream transmission in the mesh communication network;

[0030] [Fig.9E] schematically illustrates a fifth part of the example of setting up multicast data stream transmission in the mesh communication network;

[0031] [Fig.9F] schematically illustrates a sixth part of the example of setting up multicast data stream transmission in the mesh communication network;

[0032] [Fig.9G] schematically illustrates a seventh part of the example of setting up multicast data stream transmission in the mesh communication network;

[0033] [Fig.9H] schematically illustrates an eighth part of the example of setting up multicast data stream transmission in the mesh communication network;

[0034] [Fig. 10] schematically illustrates a flowchart of an alternative algorithm for processing a subscription request to a multicast data stream, received from a station device by a bridge device;

[0035] [Fig. 11] schematically illustrates a flowchart of an algorithm for processing an unsubscribe request from a multicast data stream, received from a station device by a bridge device; and

[0036] [Fig. 12] schematically illustrates an example of unsubscribing from a multicast data stream in the mesh communication network.

[0037] DETAILED DESCRIPTION OF IMPROVEMENTS

[0038] Fig. 1 thus schematically illustrates a 100 mesh communication network of the local area network (LAN) type which interconnects bridge devices B0 120, B1 121, B2 122, B3 123.

[0039] The bridge devices B0 120, B1 121, B2 122, B3 123 jointly implement routing mechanisms to transport data packets in the mesh communication network 100. The mesh communication network 100 is adapted and configured to accommodate station devices STA1 141, STA2 142 and allow them to communicate through the mesh communication network 100. For example, the station devices STA1 141, STA2 142 can communicate with each other and / or communicate with a functionality of a device in which a said bridge device is included, such as a gateway functionality to access a WAN (Wide Area Network) 150, e.g., to access the Internet.

[0040] The station devices STA1 141, STA2 142 are, for example, computers, electronic tablets or multifunction mobile phones, or any type of communicating electronic equipment (TV, audiovisual decoder, etc.). Equivalently, they are referred to as terminal devices.

[0041] Bridge devices are typically included in devices offering additional functionality. Thus, in [Fig. 1], bridge device B0 120 is included in a DEV0 110 device, bridge device B1 121 is included in a DEV1 111 device, bridge device B2 122 is included in a DEV2 112 device, and bridge device B3 123 is included in a DEV3 113 device. Thus, in one embodiment, a bridge device (bridge device B0 120 in [Fig. 1]) is included in a home gateway, and the other bridge devices (bridge devices B1 121, B2 122, and B3 123 in [Fig. 1]) are respectively included in wireless LAN extenders, such as Wi-Fi extenders that extend the Wi-Fi coverage of a local area network.

[0042] More specifically, to route data packets in the mesh communication network 100, each of the bridge devices B0 120, B1 121, B2 122 uses in parallel:

[0043] - a first logical network configuration, which is used for to route data packets in point-to-point mode ("unicast"), and which is defined by dynamic routing (also called adaptive routing), which optimizes the route costs between the bridge devices B0 120, B1 121, B2 122; and

[0044] - a second logical second network configuration, which is used for to route data packets in broadcast mode, and which is defined according to a spanning tree by blocking one or more ports of the bridge devices B0 120, B1 121, B2 122 to eliminate one or more loops of the mesh communication network 100.

[0045] The routing of data packets in multicast mode (also called "point-to-multipoint mode, or "multicast" in English) is based on the first configuration, as described below.

[0046] For the sake of simplicity, [Fig. 1] shows a mesh communication network comprising only four bridge devices. However, it is understood that what is described here applies to mesh communication networks with much more complex meshes and a greater number of bridge devices.

[0047] Fig. 2 schematically illustrates an example of a suitable hardware arrangement for implementing a DEV 200 device of the mesh communication network 100, such as the DEV0 110, DEV1 111, DEV2 112 and DEV3 113 devices.

[0048] The hardware arrangement shown comprises, connected by a communication bus 210: a processor or CPU (Central Processing Unit) 201; a random-access memory (RAM) 202; a non-volatile memory, for example of type ROM (Read Only Memory) 203 or EEPROM (Electrically-Erasable Programmable ROM), or of type Flash; a storage unit, such as a storage medium SM 204, for example a hard disk drive (HDD), or a storage medium reader, such as an SD card reader (Secure Digital); and a communication interface manager COM 205.

[0049] The COM 205 communication interface manager allows the presented hardware arrangement to interact with other devices in the 100 mesh communication network or that are connected to the 100 mesh communication network. The communication interfaces are, for example, Wi-Fi interfaces on different frequency bands (2.4 GHz, 5 GHz, 6 GHz), Ethernet interfaces... Note that several bridge device ports can be virtualized on the same physical communication interface.

[0050] The processor or CPU 201 is capable of executing instructions loaded into the random access memory 202, in particular from the non-volatile memory 203 or the SM storage medium (such as an SD card) 204. When the hardware arrangement shown is powered on, the processor or CPU 201 is thus able to read instructions from the RAM 202 and execute them. These instructions form a computer program causing, in particular, the implementation by the processor or CPU 201 of the steps, processes, and behaviors described herein in relation to the device to which the DEV 200 device corresponds.

[0051] All or part of the steps, processes and behaviors described herein can thus be implemented in software form by executing a set of instructions by a programmable machine, for example a DSP (“Digital SP”) processor Signal Processor (in English) or a microcontroller, or be implemented in hardware form by a dedicated machine or electronic component (chip) or a dedicated set of electronic components (chipset), for example, an FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit). Generally speaking, the devices of the 100 mesh communication network, such as the DEVO 110, DEV1111, DEV2 112, and DEV3 113 devices (and consequently the B0 120, B1 121, B2 122, and B3 123 bridge devices), include electronic circuitry adapted and configured to implement the steps, processes, and behaviors described herein.

[0052] Fig. 3 schematically illustrates a flowchart of an algorithm for processing a subscription request to a multicast data stream, received from a station device by a bridge device.

[0053] In step 310, the bridge device in question receives the request to subscribe to the multicast data stream. The multicast data stream is typically identified by a Layer 3 (Network Layer) address of the OSI (Open Systems Interconnection) model, e.g., an IP (Internet Protocol) address. The request to subscribe to the multicast data stream is, for example, a JOIN message of the IGMP (Internet Group Management Protocol).

[0054] In a step 312, the bridge device in question checks whether the multicast data stream is known to said bridge device, that is, whether the multicast data stream already passes through said bridge device. A multicast data stream orientation table, described below in relation to [Fig. 8], can be used for this purpose. If so, a step 316 is performed; otherwise, a step 314 is performed.

[0055] In step 314, the bridge device in question relays the request to subscribe to the multicast data stream to a centralizing bridge device. For example, under the PIM (Protocol Independent Multicast) protocol in sparse-mode, the centralizing bridge device is called the Rendez-Vous Point (RVP). The centralizing bridge device is designated by preconfiguring the bridge devices B0 120, B1 121, B2 122, and B3 123 (for example, during installation or by election). The relaying of the request to subscribe to the multicast data stream is carried out with a dedicated message, transmitted in point-to-point mode. For example, a PIM JOIN message from the PIM protocol can be used to notify the centralizing bridge device (Rendez-Vous Point) that a station device wishes to subscribe to a multicast data stream.The relay message provides at least one identification of the multicast data stream in question (typically its layer 3 address (layer 1). network) of the OSI model, such as its IP address) and an identification of the device station in question (typically its layer 3 (network layer) address of the OSI model, such as its IP address).

[0056] In step 316, the bridge device in question adds an additional subscription to the multicast data stream in question. This may result in the implementation of a supplementary multicast switching configuration within the bridge device in question. Indeed, it is possible that the multicast data stream in question has not yet been propagated to the port of the bridge device through which the subscription request from the station device in question was received in step 310. The bridge device in question then configures itself to propagate the multicast data stream in question to this port as well. The multicast data stream in question is then transmitted to the station device in question. The bridge device in question may inform the central bridge device. The bridge device in question may inform the other bridge devices on the local network.

[0057] In the case of a supplementary multicast switching configuration within the bridge device, as in step 316, the multicast switching configuration is updated by adding an output port for the multicast data stream. This output port is maintained in the supplementary multicast switching configuration for the multicast data stream in question until no more station devices accessible via that port are subscribed to the multicast data stream in question.

[0058] To this end, the bridge device in question keeps track of each multicast data stream subscription request that said bridge device has received from a station device, as well as the port of said bridge device through which said multicast data stream subscription request was received. With regard to the algorithm in [Fig. 3] (or that of [Fig. 10] below), each multicast data stream subscription request that has been received in this way (from said station device, as in step 310) originates from a station device that is connected to the bridge device in question (i.e., that accesses the mesh communication network 100 through said bridge device in question).This trace is kept in memory by the bridge device in question until the bridge device requests to unsubscribe from the multicast data stream in question (for example via a LEAVE message of the IGMP protocol).

[0059] Figure 3 shows a centralized arrangement. An alternative distributed arrangement is shown below in relation to Figure 10.

[0060] Figure 4 schematically illustrates a flowchart of an algorithm for processing, by the centralizing bridge device, a subscription request to a multicast data stream, relayed by a bridge device. The algorithm in Figure 4 is This also applies when the centralizing bridge device directly receives a subscription request to a multicast data stream from a station device that is connected to one of its ports.

[0061] In a step 410, the centralizing bridge device receives the subscription request to a multicast data stream, which has been relayed by a bridge device as described above in relation to [Fig. 3]. For example, the subscription request to a multicast data stream is written in a PIM JOIN message.

[0062] In step 412, the central bridge device checks whether the multicast data stream is known to said central bridge device, that is, whether the central bridge device has already been requested for the multicast data stream in question. If so, step 418 is performed; otherwise, step 414 is performed.

[0063] In step 414, the central bridge device sends an instruction to each bridge device B0 120 B1 121, B2 122 and B3 123 on the local network (i.e., including itself) to initiate a search for the source of the multicast data stream in question. For example, the PIM protocol can be enhanced for this purpose with a PIM JOINREQUEST message intended to instruct a bridge device to which the PIM JOINREQUEST message is addressed to initiate a search by issuing a subscription request on each of its ports. This instruction is preferably sent in point-to-point mode by the central bridge device to each other bridge device B0 120 B1 121, B2 122 and B3 123.The instruction indicates that the request is made on behalf of the station device in question (typically its OSI model layer 3 (network layer) address, such as its IP address) and therefore identifies the station device in question, as well as the multicast data stream in question (typically its OSI model layer 3 (network layer) address, such as its IP address).

[0064] In a particular embodiment as illustrated in [Fig. 1] where the local network is connected to a wide area network (WAN) via a gateway incorporating a router (here, router B0 120), the source of the multicast data stream may be located within the local network perimeter or accessible via the WAN. The search must then be performed on both the local network and the WAN.

[0065] Then, in step 416, the centralizing bridge device itself applies the instruction to initiate the search for the source of the multicast data stream in question (local search initiation). To do this, the centralizing bridge device transmits a subscription request to the multicast data stream in question on each of its ports. The request takes, for example, the form of a JOIN message of the IGMP protocol. The subscription request is The application was transmitted on behalf of the central bridge system, even though it was made on behalf of the station system in question. The central bridge system maintains that the subscription request was actually transmitted on behalf of the station system in question and not on its own behalf.

[0066] In step 418, the centralizing bridge device instructs a supplementary multicast routing configuration within the bridge device in question. Indeed, at this stage, the multicast data stream in question has not yet been propagated to the port of the bridge device through which the subscription request from the station device in question was received in step 310 (otherwise, the subscription would have been taken into account as soon as [Fig.3] was executed).

[0067] For example, the centralizing bridge device, by virtue of its knowledge of the topology of the mesh communication network 100 and the link costs thanks to adaptive routing, is able to know which bridge device(s) the multicast data stream in question is already passing through in the mesh communication network. For example, the centralizing bridge device sends a message to the bridge device from which the multicast data stream must have a new branch to reach the station device in question. This bridge device, from which the multicast data stream must have a new branch, detects that the multicast data stream in question is already passing through it, and updates its local multicast transmission configuration so as to allow the multicast data stream in question to propagate to the station device concerned.As described below in relation to [Fig. 7], the bridge device in question populates its multicast data flow orientation table (adding an output port) and then transcribes it into its multicast data flow switching table. And so on, the centralizing bridge device sends such a message to all bridge devices on the branch, according to the first logical network configuration, which are to be configured to reach the station device in question.

[0068] Fig. 5 schematically illustrates a flowchart of an algorithm for processing, by a bridge device, an instruction to launch a search for a source of a multicast data stream on behalf of a station device.

[0069] In a step 510, the bridge device in question receives the instruction to initiate the search for the source of a multicast data stream. The instruction indicates that the request is made on behalf of the station device in question (typically its OSI model layer 3 (network layer) address, such as its IP address) and therefore identifies the station device in question, as well as the multicast data stream in question (typically its OSI model layer 3 (network layer) address, such as its IP address).

[0070] In step 512, the bridge device in question transmits a subscription request to the multicast data stream in question on each of its ports. The request takes, for example, the form of an IGMP JOIN message. The subscription request is transmitted on behalf of the bridge device in question, even though it is made on behalf of the station device in question. The bridge device in question retains that the subscription request is actually transmitted on behalf of the station device in question and not on its own behalf. This makes it possible to find, when the desired multicast data stream enters the mesh formed by the interconnection of the bridge devices, the best route (according to the first logical network configuration) to the station device in question.

[0071] Figure 6 schematically illustrates a flowchart of an algorithm for processing, by a bridge device, a subscription request to a multicast data stream, received from another bridge device.

[0072] The request to subscribe to a multicast data stream originates from a search for the source of the multicast data stream, as initiated by said other bridge device in step 416 or 512.

[0073] In step 610, the bridge device in question receives a request to subscribe to a multicast data stream from said other bridge device. Since it has itself been instructed to initiate the search for the source of the multicast data stream in question, this request to subscribe to the multicast data stream does not need to be processed or relayed by the bridge device in question.

[0074] Thus, in a step 612, the bridge device in question throws (or rejects) the request to subscribe to the multicast data stream that was received from said other bridge device.

[0075] For example, the bridge device in question can recognize the origin (station device or bridge device) of the request to subscribe to the multicast data stream thanks to source address information (of layer 3 (network layer) and / or layer 2 (link layer) of the OSI model, e.g., respectively IP address and / or MAC address).

[0076] Figure 7 schematically illustrates a flowchart of a reaction algorithm, by a bridge device, to a reception of multicast data streams for which a subscription request has previously been made on behalf of a station device.

[0077] In step 710, the bridge device in question receives the multicast data stream in question. The bridge device in question retrieves a trace indicating that this multicast data stream has been subscribed to under a source search initiation instruction (step 416 or 512).

[0078] In a step 712, the bridge device in question performs a local multicast transmission configuration so as to allow the multicast data stream in question to propagate through the local network to the station device in question. To do this, the bridge device in question notes through which port (first port) the multicast data stream is received, and determines through which port (second port) the station device in question is accessible according to the first configuration (that for point-to-point transmissions), so as to optimize the route to the station device in question. The bridge device configures itself to allow switching from the first port to the second port of the multicast data stream in question.

[0079] In a particular embodiment, the bridge device populates a multicast data stream orientation table, as described below in relation to [Fig. 8], and then translates it into a multicast data stream switching table (at layer 2 (data link layer) of the OSI model). This avoids using the second logical network configuration (the one for data broadcasts) for multicast transmissions and thus optimizes network utilization.

[0080] As an alternative to the algorithm in [Fig.7], the bridge device in question performs the local multicast transmission configuration (so as to allow the multicast data stream in question to be propagated in the local network to the station device concerned) upon receipt of a confirmation message of the consideration of said subscription request to the multicast data stream which was transmitted by said bridge device during the search for the source of said multicast data stream.

[0081] In another embodiment, the confirmation message that a subscription request to the multicast data stream, transmitted by the bridge device during the search for the source of said multicast data stream, has been received is relayed to the centralizing bridge device. The local multicast transmission configuration (enabling the propagation of the multicast data stream in question throughout the local network to the relevant station device) is then applied upon instruction from the centralizing bridge device.

[0082] Figure 8 schematically illustrates a multicast data flow orientation table.

[0083] Each bridge device B0 120, B1 121, B2 122 and B3 123 of the local network implements its own multicast data stream orientation table.

[0084] This multicast data flow orientation table is built and updated by the relevant B0 120, B1 121, B2 122 and B3 123 bridge device to facilitate the implementation of multicast data flow switching within the local network according to the subscriptions required.

[0085] The multicast data stream orientation table contains a correspondence between:

[0086] - a layer 3 (network layer) address of the OSI model of the data stream multicast, denoted @IP_M, typically its IP address;

[0087] - a layer 2 (data link layer) address of the OSI model of the data stream multicast, noted @MAC_M, typically its MAC address;

[0088] - an identification, denoted IN_P, of the input port of the bridge device considered, by which the multicast data stream between; and

[0089] - an identification, denoted OUT_P, of the output port(s) of the bridge device considered, through which or through which the multicast data stream exits.

[0090] By way of illustration, [Fig. 8] thus shows, for a given bridge device, a multicast data stream orientation table content including:

[0091] - a first multicast data stream, having a layer 3 address (layer network) of the OSI model denoted @IP1 and a layer 2 (link layer) address of the OSI model denoted @MAC1, and for which the input port is a port denoted PI and two output ports denoted P2 and P3 are declared;

[0092] - a second multicast data stream, having a layer 3 address (layer network) of the OSI model denoted @IP2 and a layer 2 (link layer) address of the OSI model denoted @MAC2, and for which the input port is port P2 and the only output port is port P3.

[0093] In the situation described by the multicast data flow orientation table of [Fig.8], the first multicast data flow enters through the PI port of the bridge device in question and is switched to ports P2 and P3, while the second multicast data flow enters through the P2 port of the bridge device in question and is switched only to port P3.

[0094] Note that the correspondence between a Layer 3 (Network Layer) address of the OSI model of a multicast data stream and a Layer 2 (Link Layer) address of the OSI model of the multicast data stream can be conventionally obtained by applying a conversion rule. For example, in the case of an IPv6 address of a multicast data stream, the corresponding MAC address is obtained by prefixing the last 4 octets of said IPv6 address with the value 0x3333, as defined in the normative document RFC 4291; and in the case of an IPv4 address of a multicast data stream, the corresponding MAC address can be obtained by prefixing the last 23 bits of said IPv4 address with the value 0x01005E followed by a bit set to 0.

[0095] In a particular embodiment, each time a bridge device updates the multicast data flow routing table, that bridge device informs the central bridge device. Thus, the central bridge device is aware of the multicast data flow routings in the mesh communication network 100. Alternatively, each bridge device is informed of the updates to the multicast data flow routing tables, and thus each central bridge device is aware of the multicast data flow routings in the mesh communication network 100.

[0096] Figs. 9A to 9H illustrate an example of the application of the algorithms described above in relation to Figs. 3 to 7. Figs. 9A to 9H thus schematically illustrate an example of the implementation of multicast data stream transmission in the mesh communication network 100.

[0097] It is considered in the context of the example illustrated in Figs. 9A to 9H that the centralizing bridge device is the B0 120 bridge device.

[0098] In [Fig. 9A], the station device STA1 141 transmits a 901 request to subscribe to a multicast data stream. For example, the 901 request is an IGMP JOIN message. This 901 request is received by the bridge device B3 123, for example, via its port "2". For illustrative purposes, consider that the source of the multicast data stream in question is accessible via the WAN 150 and that no station device is yet subscribed to this multicast data stream.

[0099] In [Fig. 9B], by executing the algorithm of [Fig. 3], the bridge device B3 123 transmits, to the bridge device B0 120 as a centralizing bridge device, a 902 relay message of the subscription request to the multicast data stream. For example, message 902 is a PIM JOIN message.

[0100] In [Fig. 9C], by executing the algorithm of [Fig. 4], the bridge device B0 120, acting as the centralizing bridge device, transmits to each other bridge device B1 121, B2 122, and B3 123 an instruction message 903 to initiate a search for the source of the multicast data stream in question. For example, the instruction message is a PIM JOINREQUEST message as mentioned above.

[0101] In [Fig. 9D], by executing the algorithm in [Fig. 5] (step 416 for bridge device B0 120), each bridge device transmits, in its own name but on behalf of the station device concerned, a 904 request to subscribe to a multicast data stream on each of its ports. For example, the 904 request is an IGMP JOIN message. Such a 904 request is notably transmitted over the WAN 150.

[0102] In [Fig.9E], the multicast data stream 905 is received from the WAN 150 by the bridge device B0 120, for example via its port “0”.

[0103] Considering that the route to the STA1 141 station device exits the B0 120 bridge device via its port "1" to the B1 121 bridge device, the B0 120 bridge device establishes a switching rule (layer 2 (data link layer) of the OSI model) so that the 905 multicast data stream arriving via its port "0" is propagated via its port "1", as illustrated in [Fig. 9F]. The 905 multicast data stream is then received from the B0 120 bridge device by the B1 121 bridge device, for example via its port "0".

[0104] Considering that the route to the STA1 141 station device exits the B1 121 bridge device via its port "2" to the B3 123 bridge device, the B1 121 bridge device establishes a switching rule (OSI model layer 2 (data link layer)) so that the 905 multicast data stream arriving via its port "0" is propagated via its port "2", as illustrated in [Fig. 9G]. The 905 multicast data stream is then received from the B1 121 bridge device by the B3 123 bridge device, for example via its port "0".

[0105] The bridge device B3 123 then establishes a switching rule (OSI model layer 2 (data link layer)) so that the 905 multicast data stream arriving through its port "0" is propagated through its port "2", as illustrated in [Fig. 9H]. The station device STA1 141 then receives the 905 multicast data stream, and the routing of the 905 multicast data stream is optimized in the mesh communication network 100.

[0106] Figure 10 schematically illustrates a flowchart of an alternative algorithm for processing a subscription request to a multicast data stream, received from a station device by a bridge device.

[0107] In a step 1010, the bridge device in question receives the request to subscribe to the multicast data stream, as in step 310.

[0108] In a step 1012, the bridge device in question checks whether the multicast data stream is known to said bridge device, that is, whether the multicast data stream already passes through said bridge device. The multicast data stream orientation table, described above in relation to [Fig. 8], can be used for this purpose. If so, a step 1018 is performed; otherwise, a step 1014 is performed.

[0109] In step 1014, the bridge device in question sends an instruction to each bridge device B0 120 B1 121, B2 122 and B3 123 on the local network (i.e., therefore, itself included) to initiate a search for the source of the multicast data stream in question. For example, the aforementioned PIM JOINREQUEST message is used. This instruction is preferably sent in mode point-to-point. The instruction indicates that the request is made on behalf of the station device in question (typically its OSI model layer 3 (network layer) address, such as its IP address) and therefore identifies the station device in question, as well as the multicast data stream in question (typically its OSI model layer 3 (network layer) address, such as its IP address). This triggers the algorithm in [Fig. 5] by the bridge devices BO 120 B1 121, B2 122 and B3 123.

[0110] In step 1016, the bridge device itself executes the instruction to initiate the search for the source of the multicast data stream in question (local search initiation). To do this, the bridge device transmits a subscription request to the multicast data stream in question on each of its ports. The request takes, for example, the form of an IGMP JOIN message, as already described. The subscription request is transmitted on behalf of the bridge device in question, even though it is made on behalf of the station device in question. The bridge device in question retains that the subscription request is actually transmitted on behalf of the station device in question and not on its own behalf.

[0111] In step 1018, the bridge device in question adds an additional subscription to the multicast data stream in question. This may result in the implementation of a supplementary multicast switching configuration within the bridge device in question. Indeed, it is possible that the multicast data stream in question has not yet been propagated to the port of the bridge device through which the subscription request from the station device in question was received in step 1010. The bridge device in question then configures itself to propagate the multicast data stream in question to this port as well. The multicast data stream in question is then transmitted to the station device in question.

[0112] In the case of a supplementary multicast switching configuration within the bridge device, as in step 316, the multicast switching configuration is updated by adding an output port for the multicast data stream. This output port is maintained in the supplementary multicast switching configuration for the multicast data stream in question until no more station devices accessible via that port are subscribed to the multicast data stream in question.

[0113] For example, the bridge device in question, by virtue of its knowledge of the topology of the mesh communication network 100 and of the link costs thanks to adaptive routing, is able to know through which bridge device(s) the multicast data stream in question is already passing in the mesh communication network. For example, the bridge device in question sends a message to the bridge device from which theThe multicast data stream needs a new branch to reach the station device in question. This bridge device, from which the multicast data stream needs a new branch, detects that the multicast data stream is already passing through it and updates its local multicast transmission configuration to allow the multicast data stream to propagate to the station device. As described below in relation to [Fig. 7], the bridge device populates its multicast data stream routing table (adding an output port) and then transfers this information to its multicast data stream switching table.And so on, the bridge device in question sends such a message to all other bridge devices on the branch, according to the first logical network configuration, which are to be configured to reach the station device in question.

[0114] Fig. 11 schematically illustrates a flowchart of an algorithm for processing a request to unsubscribe from a multicast data stream, received from a station device by a bridge device.

[0115] In step 1110, the bridge device in question receives a request to unsubscribe from the multicast data stream from a station device. The unsubscribe request marks the end of the subscription that had been requested by the station device in step 310 or 1010.

[0116] The bridge device in question takes into account, in a step 1114, the unsubscription of the station device in question from the multicast data stream concerned,

[0117] The bridge device examines whether a multicast switching reconfiguration within the bridge device is necessary. This is because the multicast data stream in question may no longer need to be propagated to the bridge device port through which the unsubscribe request from the station device in question was received in step 1110. For example, considering the example in [Fig. 8], the unsubscription of the station device makes propagation of the multicast data stream identified by IP address @IP1 to port P3 unnecessary. In this case, a multicast switching reconfiguration (possibly via a corresponding update of the multicast data stream orientation table) is performed to remove the propagation to port P3.

[0118] The bridge device also examines, in a step 1112, whether a multicast switching reconfiguration within the bridge device results in the multicast data stream in question no longer needing to be propagated to any port within the bridge device in question. For example, considering the example in [Fig. 8], unsubscribing from the station device makes propagation of the stream unnecessary. Multicast data identified by IP address @IP2 is sent to port P3. In this case, a multicast switching reconfiguration (possibly by deleting the corresponding row in the multicast data flow direction table) is performed to remove the propagation of the multicast data flow within the bridge device in question; but furthermore, the unsubscribe request must travel up the relevant branch in the mesh communication network. Thus, in step 1116, the bridge device transmits an unsubscribe request for the multicast data flow in question to the upstream bridge device on the branch, that is, the bridge device connected to it via the ingress port of the relevant multicast data flow.

[0119] In a particular embodiment, the bridge device in question informs the concentrating bridge device of any multicast switching reconfiguration thus performed, so that the centralizing bridge device can know at any time which multicast data stream is propagated in the 100 mesh communication network by which routes / branches.

[0120] Fig. 12 schematically illustrates an example of unsubscribing from a multicast data stream in the mesh communication network.

[0121] The STA1 141 station device transmits a 1201 unsubscribe request to a multicast data stream. For example, the 1201 request is an IGMP LEAVE message that corresponds to the same multicast data stream as the IGMP JOIN message in [Fig. 9A]. This 1201 request is received by the B3 123 bridge device, for example, via its port '2'.

[0122] The bridge device B3 123 realizes that no station device is now subscribed to the multicast data stream through it, and stops the propagation of the multicast data stream. The bridge device B3 123 informs the bridge device B1 121 by means of a request 1202 to unsubscribe from the multicast data stream. For example, the request 1202 is an IGMP LEAVE message.

[0123] Upon receiving request 1202, bridge device B1 121 realizes that it is no longer necessary to propagate the multicast data stream through it and stops propagating the multicast data stream. Bridge device B1 121 informs bridge device B0 120 of this by means of a request 1203 to unsubscribe from the multicast data stream. For example, request 1202 is an IGMP LEAVE message.

[0124] Upon receiving request 1203, the bridge device B0 120 realizes that it is no longer necessary to propagate the multicast data stream through it, and stops the propagation of the multicast data stream. The bridge device B0 120 transmits a dissubscribe request 1204 to the multicast data stream's source. By For example, request 1203 is an IGMP LEAVE message which is consistent with the IGMP JOIN 904 message transmitted towards the WAN 150 on [Fig.9D],

[0125] If, upon receiving request 1203, the bridge device B0 120 had realized that the multicast data stream was also propagated through its port "2" (for example, to allow the station device STA2 142 to receive the multicast data stream in question), then the bridge device B0 120 would have stopped the propagation of the multicast data stream in question to its port "1" but would have maintained the propagation of the multicast data stream in question to its port "2".

Claims

Demands

1. A method for transmitting data packets in a mesh communication network (100) of the local area network type which interconnects bridge devices (120, 121, 122, 123), each bridge device (120, 121, 122, 123) using in parallel: - a first logical network configuration, which is used to route data packets in point-to-point mode, and which is defined by dynamic routing between the bridge devices (120, 121, 122, 123);and - a second logical network configuration, which is used to route data packets in broadcast mode, and which is defined according to a tree covering by blocking one or more ports of the bridge devices (120, 121, 122, 123) to eliminate one or more loops of the mesh communication network (100), the method comprising: - following a first subscription request received from a station device (141, 142) connected to the local network, instructing (414, 1014) each bridge device (120, 121, 122, 123) to initiate a source search for the multicast data stream so that each bridge device (120, 121, 122, 123) transmits (416, 512) on each of its ports a second subscription request to the multicast data stream and ignores any such second subscription request to the multicast data stream originating from any another said bridge device (120, 121, 122, 123);- when the multicast data stream is received (710) via an input port of said bridge device (120, 121, 122, 123), configure (712) said bridge device to switch the multicast data stream from the input port to an output port towards the station device (141, 142) according to the first logical network configuration.

2. The method according to claim 1, wherein the first subscription request is received from the station device (141, 142) by said bridge device (120, 121, 122, 123) which relays the first subscription request to a centralizing bridge device (120) which then sends (414) to each bridge device (120, 121, 122, 123) an instruction to start the search for the source of the multicast data stream.

3. The method according to claim 1, wherein the subscription request received from the station device (141, 142) is received by said bridge device (120, 121, 122, 123) which then sends (1014) to each bridge device (120, 121, 122, 123) an instruction to start the search for the source of the multicast data stream.

4. The method according to any one of claims 1 to 3, wherein each second subscription request is transmitted (416, 512) on behalf of the bridge device (120, 121, 122, 123) in question although it is made on behalf of the station device (141, 142) in question.

5. The method according to any one of claims 1 to 4, wherein each bridge device (120, 121, 122, 123) implements a multicast data stream orientation table containing, for each multicast data stream passing through said bridge device (120, 121, 122, 123): - a Layer 3 address of the OSI model of said multicast data stream; - a Layer 2 address of the OSI model of the multicast data stream, which was obtained by applying a conversion rule from said Layer 3 address of the OSI model of said multicast data stream; - an identification of the input port of said bridge device (120, 121, 122, 123) for said multicast data stream; and - an identification of each output port of said bridge device (120, 121, 122, 123) for said multicast data stream;and in which each bridge device (120, 121, 122, 123) transcribes its multicast data stream orientation table into a multicast data stream switching table at OSI model layer 2.

6. A computer program product comprising instructions causing an implementation of the method according to any one of claims 1 to 5, when the instructions are executed by a processor.

7. An information storage medium containing instructions causing an implementation of the method according to any one of claims 1 to 5, when the instructions are read from the information storage medium and executed by a processor.

8. A bridge device (120, 121, 122, 123) intended for use in a mesh communication network (100) of the local network type, the bridge device (120, 121, 122, 123) using in parallel: - a first configuration of the first logical network, which is used to route data packets in point-to-point mode, and which is defined by dynamic routing between bridge devices (120, 121, 122, 123) of the mesh communication network (100); and - a second logical network configuration, which is used to route data packets in broadcast mode, and which is defined according to a tree covering by blocking one or more ports of the bridge devices (120, 121, 122, 123) of the mesh communication network (100) to eliminate one or more loops, the bridge device (120, 121, 122,123) comprising electronic circuitry configured to: - following a first subscription request received from a station device (141, 142) connected to the local network, instruct (414, 1014) each bridge device of the mesh communication network (100) to initiate a search for the source of the multicast data stream so that each bridge device (120, 121, 122, 123) of the mesh communication network (100) transmits (416, 512) on each of its ports a second subscription request to the multicast data stream and does not take into account any such second subscription request to the multicast data stream from any other said bridge device (120, 121, 122, 123) of the mesh communication network (100); - when the multicast data stream is received via an input port of said bridge device (120, 121, 122, 123), configure said bridge device (120, 121, 122,123) to switch the multicast data stream from the input port to an output port towards the station device (141, 142) according to the first logical network configuration.

Images