EP2732589A1 - Procede de routage d'un flux multicast en mode non-stockage - Google Patents

Procede de routage d'un flux multicast en mode non-stockage

Info

Publication number
EP2732589A1
EP2732589A1 EP12733709.5A EP12733709A EP2732589A1 EP 2732589 A1 EP2732589 A1 EP 2732589A1 EP 12733709 A EP12733709 A EP 12733709A EP 2732589 A1 EP2732589 A1 EP 2732589A1
Authority
EP
European Patent Office
Prior art keywords
multicast
address
root node
packet
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12733709.5A
Other languages
German (de)
English (en)
Inventor
Christophe Janneteau
Mounir Kellil
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Publication of EP2732589A1 publication Critical patent/EP2732589A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing

Definitions

  • the invention is in the field of telecommunication networks and more particularly relates to a method for non-storage mode routing of a message flow exchanged between a source and at least one receiver identified by a unicast address, and having previously subscribed at least one multicast group in a LLN (Lower Power and Lossy Channel Network) network comprising a set of non-storage nodes and a root node, also called root, capable of storing routing information.
  • LLN Lower Power and Lossy Channel Network
  • a non-storing mode in a network such as an LLN type network is a network context in which the nodes of the network have very little memory, or no memory at all.
  • the invention is particularly but not exclusively applicable to performing multicast operations via computer networks with high constraints in terms of available resources (batteries, memories, computing capabilities, links available, etc.).
  • Such networks are often known as the LLN (Lower Power and Lossy Channel Network).
  • An example of such an LLN network is the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) in so-called non-storage mode.
  • the invention combines the context of low resource computer / telecommunication networks (LLNs), for example wireless sensor networks (Wireless Sensor Networks), as well as multicast IP communications.
  • LLCs low resource computer / telecommunication networks
  • wireless sensor networks Wireless Sensor Networks
  • multicast IP communications for example wireless sensor networks (Wireless Sensor Networks)
  • a technical problem of the prior art stems from the fact that multicast routing support has not been satisfactorily handled in the context of very low-resource networks, i.e. LLNs networks.
  • LLNs networks the lack or absence of memory at the level of the routing nodes in the LLN context makes the conventional multicast routing solutions in the Internet (eg MOSPF, PIM-SM, etc.), inoperable in the network.
  • LLN context because these require storage of states such as routing tables, and so on.
  • This problem is all the more complicated that, in the case of a RPL network specifically, the unicast routing technique for the non-storage mode, known as source routing, does not allow use of multicast addresses in routable packets to avoid network flooding or denial of service (DoS) attacks.
  • DoS denial of service
  • a multicast source generates the description code of the multicast tree and includes it as a header in the data packets.
  • the generated code contains the IP addresses of all the receivers as well as those of a set of tree-specific routers called BPs (Branching Points).
  • the source collects the description of the multicast tree from the membership requests of the members of the multicast group.
  • BP router receives a packet of data, it decodes the code of the tree to determine the next BP and / or receiver (s). Then, the current BP generates the necessary copies of the packet and transmits them to the IP addresses determined from the code.
  • An object of the invention is to overcome the disadvantages of the prior art described above.
  • An object of the invention is to route packets for a multicast group without the routing information, multicast or unicast, being present at the routing nodes.
  • the process according to the invention comprises the following steps:
  • the root node upon receipt of the packet from the multicast stream, the root node generates a copy of said packet, adds to the generated copy a routing header having a list of intermediate nodes on the path between the root node and said receiver Hi, and transmits said copy from the multicast packet to the receiver Hi via said list of intermediate nodes.
  • the multicast routing table managed by the root node further comprises a list of intermediate nodes for retransmitting the packets from the root node to the receiver.
  • the receiver sends the root node a subscription request containing its unicast address and the multicast address of the group via a Destination Protocol Object (RPC) DAO (Routing Protocol for Low Power) message. and Lossy Networks) or via a Multicast Listener Discovery (MLD) report.
  • RPC Destination Protocol Object
  • MLD Multicast Listener Discovery
  • the receiver sends said subscription request with a local multicast (link-local multicast) or, in unicast, directly to the root node, and upon receipt of the request, the root node registers the receiver in the multicast routing table.
  • FIG. 1 schematically represents the architecture of an exemplary LLN type network
  • FIG. 2 schematically illustrates a procedure for subscribing a receiver to a multicast group in a network according to the invention
  • FIG. 3 is a flowchart illustrating the processing, by the root node, of the adhesion requests of a receiver to a multicast group according to the invention
  • FIG. 4 schematically illustrates the transfer of packets from a stream from a source to a root node according to the invention
  • FIG. 5 schematically illustrates the transfer of packets from the stream of the root node to a receiver of a multicast group according to the invention
  • FIG. 6 diagrammatically illustrates the successive addressing for transmitting a multicast packet from the root node to a receiver belonging to a multicast group according to the invention
  • FIG. 7 is a flowchart illustrating the processing, by the root node, of a received data packet according to the invention
  • FIG. 8 is a flowchart illustrating the processing, by the root node, of a request to remove a receiver from a multicast group
  • FIG. 9 schematically illustrates a variant of a routing tree defined by the root node according to the invention.
  • FIG. 10 schematically illustrates a generic format of a multicast packet at the output of the root node according to the invention
  • FIGS. 11 and 12 schematically illustrate the evolution of the generic format of FIG. 10 during the transmission of the packet from the root node to a receiver according to the invention
  • FIG. 13 diagrammatically illustrates a second variant according to the invention of the transfer of packets from the root node to a receiver of a multicast group.
  • the invention will be described, with reference to FIG. 1, for the routing of packets of a stream transmitted from a source 2 to several receivers H1, H2, H3 and H4 called hosts in an LLN network.
  • the LLN network consists of a set of non-storage nodes N1, N2, N3, N4 and N5 and a special node called root node 4 capable of storing routing information.
  • a typical example of this configuration is the non-storage mode of Routing Protocol for Low Power and Lossy Networks (RPL). Recall that in the non-storage mode, the flow of information is first sent to the root node 4 which then builds the routing header necessary for the subsequent sending of the packet. step by step towards the final destination.
  • the other nodes N1, N2, N3, N4 and N5 of the network can not do this kind of operation because they have very little memory, or no memory at all.
  • the host Hi sends a multicast subscription request via a RPC Destination Warning Object (DAO) message or a Multicast Listener Discovery (MLD) message, for example.
  • DAO RPC Destination Warning Object
  • MLD Multicast Listener Discovery
  • the subscription request contains the unicast address of the host as well as the multicast address of the group to which the host wishes to join.
  • the host sends its subscription request with a local link multicast [link-local multicast] or unicast directly to the root node 4 for example, that is to say, when the destination address mentioned in the request for Subscription is the address of the root node 4.
  • the membership request may pass through intermediate router nodes if the root 4 is at several hops (for example, is not in the radio range) of the host.
  • the subscription request will arrive at the root node 4 which then proceeds to register the new host in a specific routing table.
  • This routing table contains, in particular, the unicast address of the host, the multicast address associated with it, and the list of intermediate nodes that allow packets from the root node 4 to reach the host.
  • An example of such a table of Routing is shown below for a number of hosts and 3 multicast groups, where @_X is the IP address of the X node, and T_xy is the lifetime of the Hx host subscription to the MCy group.
  • the host H2 sends a DAO message destined for the root via the node N2.
  • the RPL protocol DAO message can be used with two "target” type options and at least one "transit information” option per option "target” (to comply with the specification of the RPL protocol).
  • Each "transit information” option indicates the address of a host node of the host. However, both "transit” options may indicate the address of the same parent node of the host.
  • the host H2 will send a DAO request in the following format:
  • the two target options contain successively the host address (@ _H2) and the multicast address of the group (@ _MC3) to which the host wants to subscribe.
  • the life of the subscription is recorded in one of the two "transit information” options; preferably in the "transit information” option associated with the "target” option indicating the multicast subscription address.
  • step 12 the node N2 transmits the message DAO to the intermediate node N4.
  • the latter transfers the message DAO to the next intermediate node N5 (step 14) which transmits it to the root node 4 (step 16).
  • the subscription request may include just the "target” option containing the multicast address with the "transit information” option including the parent node and the life of the subscription. This is true if the unicast address of the host is mentioned as the source address of the IP header of the DAO message arriving at the root node 4. In this case, as in the case of the previous DAO message, the host directly sends the DAO message to the root node 4 via the intermediate router nodes.
  • the root node 4 When the root node 4 receives the DAO message, it checks in particular the target options. The existence of a multicast address in a target option means that the root node 4 is a request to join a multicast group. If the association (host address, multicast address) does not exist in the routing table, the root node 4 adds an entry corresponding to the new host. If the entry already exists, the lifetime corresponding to the association (host address, multicast address) will be reset to a maximum value, ie. the subscription of the host to the associated group will be renewed. Note that the lifetime of a first subscription is copied by the root node 4 in the corresponding entry of the routing table.
  • the root node 4 can fully establish a lifetime of a subscription by internal decision, for example if this duration is not specified in the subscription message. For example, following step 16 of FIG. 2, the root 4 receives from the node N5 the message DAO sent by the host H2. At this stage, the root is the multicast routing table, adds the address @ H2 if it is not there yet, and updates the subscription duration of the H2 host multicast group @ MC3.
  • subscribing the H2 host to an identified multicast group by a multicast address @ MC3 is performed by issuing an MLD request.
  • the subscription request message will be intercepted by a router RPL node which transfers it to the root node 4. Indeed, in the storage mode of the protocol RPL, as soon as a router receives an MLD report message, it transforms it into a DAO message which will be transmitted step by step to the root node 4.
  • the invention thus makes it possible to transform the MLD report message into a DAO message in the non-storage mode. Then, once the DAO message has been created, it will be transmitted directly to the root node 4.
  • the format of the DAO message is the one described above.
  • FIG. 3 is a flowchart illustrating the processing by the root node 4 of membership requests from a host receiver to a multicast group according to the invention.
  • step 30 the root node 4 receives the DAO message from the host node.
  • step 31 the root node 4 checks whether or not an @ mcast address (eg @_mcast_j) is present in a target option and whether an @ unicast address (eg @ _host_i) is present or not. in another target option.
  • an @ mcast address eg @_mcast_j
  • an @ unicast address eg @ _host_i
  • the root node 4 proceeds to step 32. If no multicast address is present in a target option, the message processing is interrupted.
  • step 32 the root node 4 checks whether the transit info option is present or not in the message in DAO.
  • the root node 4 checks, in step 33, whether the subscription life Tij of the host to the multicast group is zero.
  • the root node 4 processes, in step 34, the DAO message as a removal request from the multicast group.
  • the root node 4 checks, in step 35, if the association (@ _host_i, @_mcast_j) exists in the routing table.
  • the root node 4 renews, at step 36, the subscription of the host to the multicast group.
  • the root node 4 adds, at step 38, the association of addresses (@ _host_i, @_mcast_j) in the routing table and copies the lifetime (T_ij) for (@ _host_i, @_mcast_j).
  • the transfer of data packets from source 2 to these hosts is made in two phases: a first phase in which packets are first transmitted from source 2 to root node 4, and a second phase in which packets are transmitted from root node 4 to the host receptors.
  • FIG. 4 schematically illustrates the transfer of the multicast packets from the source 2 to the root node 4.
  • the source 2 sends (step 40) the packets to one or more neighboring router nodes that are within range.
  • This sending can be carried out both in multicast (basic / preferred mode) and multicast tunnels (multicast in unicast.
  • the neighbor node of the source 2 receives a multicast packet, it transmits it (step 42) as it is on its output interface to the next intermediate node which transmits it to the root node 4 (step 44).
  • a node that receives a multicast packet from a so-called child node, that is to say, leading to the source 2 transfers this packet to its so-called node. parent, that is, a node leading to the root node 4.
  • the source can not send multicast packets natively / directly, it sends its multicast packets in a unicast tunnel either to its neighbor RPL node or directly to the root node 4. This is the case, for example, where the source is in a network that does not support multicast.
  • the intermediate RPL node near the source 2 receives a tunneled packet from it, it checks whether the destination address of the tunnel belongs to him. If this is the case, the intermediate node decapsulates the received packet by deleting the external IP header and transmits the uncapsed multicast packet as it is on its output interface to the next intermediate node in the direction of the root node 4. Thus, each intermediate node receiving a multicast packet from a child node (node leading to the source) transfers this packet to its parent node (node leading to the root node 4).
  • the destination address of the packet does not belong to the intermediate RPL node adjacent to the source 2, then it is normally the address of the root node 4.
  • the intermediate RPL node transmits the packet. as such on its output interface to the next intermediate RPL node towards the root node 4.
  • This transfer phase to the root node 4 can be performed according to the default unicast routing strategy of the RPL network (generally, each node sends the packet to a node discovered in advance through an announcement message (such as the message DIO (DODAG Information Object) RPL protocol).
  • DIO DODAG Information Object
  • the root node 4 Upon receipt of the packet, the root node 4 checks whether the packet has a multicast destination address or a destination address that belongs to the root node 4. Therefore, two cases are to be distinguished, the first case where the packets carry an address multicast destination, and the second case where the packets carry a unicast destination address that belongs to the root node 4.
  • the root node 4 checks whether this address is registered in its routing table (for example if there is at least one entry indicating this multicast address). If the multicast address exists, the root node 4 proceeds to construct a set of routing headers. There will be a routing header per host. For each host of a given multicast group, the root node 4 generates a copy of the received packet and adds thereto the routing header corresponding to said host.
  • the routing header for a host host_i belonging to a multicast group mcast_j is constructed from the input of the routing table corresponding to the combination (host_i @, mcast_j @).
  • the header contains the IP address of the host and the IP address of each node on the host's path.
  • a multicast packet for group @ _MC2 received by the root node 4 will have the following form:
  • the root node 4 will generate two copies of the packets to be transmitted. Each copy will be associated with a different routing header; one corresponding to the host H3, the other corresponding to the host H4. Each resulting packet will then be tunneled to the N5 node using an external IP header having as source address that of the root node 4, and as the destination address that of N5.
  • the two final packets destined for H3 and H4 will have the following format:
  • the processing of the packet received at this node is identical to the processing of the packet with IPv6 routing header in RPL.
  • the node will swap the value indicated in the destination address of the external IP header (the value being the address of the current node) with the address of the next node indicated in the routing header (the position of the next node in the routing header is calculated according to the operation indicated for the IPv6 routing headers in the RPL protocol that the position is equal to the number of addresses in the routing header minus the number of remaining segments; two known from specific fields of the IPv6 routing header in RPL).
  • the packet is then sent to the next node.
  • the process (reception, address swapping, transfer) is thus repeated by each node appearing in the routing header (apart from the host).
  • Figure 5 illustrates the steps of transferring packets from the root node 4 to the host H2.
  • step 50 the root node 4 transmits the multicast packets to the first intermediate node on the path to the host. This intermediate node transfers said packets to the next intermediate node (step 52) which transfers it to the host node H2 (step 54).
  • the node N5 when transferring a packet from the root node 4 to the host H3, the node N5 will swap the destination address of the external IP header (@ _N5) with the address of the next node (@ _N4) and transfer the resulting packet to node N4. Then, node N4 will in turn swap the address of destination of the external IP header (@ _N4) with the address of the next node (@ _H3) and transfer the resulting packet to host H3.
  • Fig. 7 is a flowchart illustrating the processing of a data packet received by the root node 4.
  • step 70 the root node 4 receives the data packet, and checks, in step 71, whether the destination address (@_dest) is either that of the root node 4 or multicast type.
  • the data packet is then routed according to the basic unicast mode of the RPL protocol (step 71a).
  • the root node 4 checks, in step 72, if the address (@_dest) is of multicast type.
  • step 73 the root node 4 traverses the routing table on the input (*, @_dest), and checks, in step 74, if this address (@_dest) is present in the table of routing.
  • the processing of the packet is interrupted. If however the root node 4 has a connection to an external network (typically through a network interface other than that used to connect to the LLN network) it can transmit the multicast packet to this external network.
  • an external network typically through a network interface other than that used to connect to the LLN network
  • the root node 4 retrieves the address of the host @_Hi from the input of the routing table where the destination address @_dest was found and adds, at the routing header, all the nodes on the path of the flow to the @_Hi address, with the exception of the first node on this path.
  • step 76 the root node 4 generates a tunnel to transmit the resulting packet to the first node on the path of the stream to the @_Hi address.
  • the root node 4 checks, in step 77, if the received packet is tunneled.
  • the root node 4 decapsulates the packet in step 78 and checks, in step 79, whether the destination address of the internal packet (@_dest) is of multicast type.
  • step 73 If yes, the processing of the packet continues from step 73.
  • the received packet is then routed according to the basic unicast mode of the RPL protocol.
  • the root node 4 has a connection to an external network (typically through a network interface other than that used to connect to the LLN network) it can transmit the multicast packet to this external network.
  • an external network typically through a network interface other than that used to connect to the LLN network
  • a host receiver receives a tunneled multicast packet with a routing header from the root node 4, it removes the external IP header corresponding to the tunnel as well as the routing header to retrieve the data.
  • a request to unsubscribe a multicast group can be sent either via messages using the IPv6 "Multicast Listener Discovery (MLD) protocol or messages specific to LLN networks such as, for example, RPL protocol DAO messages (RPL).
  • MLD Multicast Listener Discovery
  • RPL RPL protocol DAO messages
  • An MLD request will be sent by a non-RPL node in the sense of the RPL protocol, which according to the MLD standard, is sent in multicast with local scope / link (link-local multicast).
  • the host message will be intercepted by a RPL router node.
  • this RPL router receives said MLD request, it transforms it into a DAO message that will be transmitted to the root node 4.
  • This DAO message will include two "target" options. The first option will contain the unicast address of the host. The second option "target" will contain the multicast address of the group from which the host wishes to unsubscribe.
  • This DAO message will also contain two "Transit Information” options (one per "target”option); one of them containing a field "lifetime” zero.
  • the format of the DAO message for a given non-RPL host for example the H2 host (H2 is considered here as a non-RPL node), is described below: Header @ _H2 @ N_2 @ _MC3 0x00000000, @ N_2
  • the invention proposes that said host (RPL host) sends a DAO message instead of a message MLD report.
  • the DAO message in this case, has a format identical to that described for the case of a non-RPL host. This DAO message will be sent directly to the root.
  • the removal request can include (either for the case of a RPL or non-RPL host) just the target option containing the multicast address with the "transit information" option associated with a null lifetime , if the unicast address of the host is mentioned as the source address of the IP header of the DAO message arriving at the root node 4.
  • Fig. 8 is a flowchart illustrating the processing, by the root node 4, of multicast group removal requests issued by a host.
  • the root node 4 receives a DAO message from a host wishing to unsubscribe from a multicast group and checks, in step 81, whether the multicast group address j (mcast_j) is present in a multicast group. target option and if the unicast address of the Hi host (@_Hi) is present in another target option.
  • the root node 4 proceeds to step 82.
  • the root node 4 uses the source address of the DAO message as said unicast address (eg @_Hi) and proceeds to step 82.
  • step 82 the root node 4 checks whether the association (@ _host_i, @_mcast_j) exists in the routing table.
  • the root node 4 checks, in step 83, if the "transit information" option is present in the DAO message.
  • the root node 4 checks, in step 84, whether the subscription duration Tij of the host Hi multicast group mcast_j is zero.
  • the root node 4 renews, in step 85, the subscription of the host (@ _host_i) by an update of the duration Tij.
  • the root node 4 deletes in step 86, the entry (@ _host_i, @_mcast_j) from the routing table.
  • the routing header describes the multicast tree from the root node 4 to all the multicast receivers. This reduces the number of copies sent to the recipients of a multicast group and thus optimizes bandwidth.
  • this variant defines a new type of IPv6 routing header for the RPL protocol.
  • Figure 9 schematically illustrates an example in which the source 2 sends the multicast packet address @ _MC1 to the root node 4. Subsequently, this root node 4 builds the routing header and sends a single packet to the destinations @ _H1, @ _H2, and @ _H3, members of the MCI group.
  • the root node 4 When the root node 4 receives a packet from a multicast source 2, it checks whether the packet has a multicast destination address or a destination address that belongs to the root node 4. Two cases are then distinguished depending on whether the destination address is a multicast or unicast address.
  • the root node 4 checks whether this address is registered in its routing table (for example if there is at least one entry indicating this multicast address). If the multicast address does not exist, the processing is interrupted. If however the root node 4 has a connection to an external network (typically through a network interface other than that used to connect to the LLN network) it can transmit the multicast packet to this external network. If the multicast address exists, the root node 4 proceeds to construct a unique routing header for each of its subtrees.
  • a subtree of a root node represents the tree from a child (or a next node to a jump from the root node 4) to the hosts served by this sub-node. tree.
  • the root node 4 has a single subtree which starts from the node N1 to the hosts H1, H2, and H3.
  • the routing header described in this variant of the invention is new because its format is different from that of the routing header IPv6 for RPL [J. Hui et al. "An IPv6 Routing Header for Source Roads with RPL", Internet Draft, (Work in Progress), 2011]).
  • This routing header will contain the IP addresses of all nodes (so-called multicast routers) of the subtree, with the exception of the vertex node of the subtree, as well as the addresses of all the hosts of this subtree.
  • the root node 4 will generate as many copies of the received multicast packet as there are subtrees (or generated headers). Each of these copies of the multicast packet will be added to a routing header associated with a distinct subtree of the root node 4. The resulting packet from each association (packet copy and routing header) will then be tunneled to a child node (from root node 4) associated with the header. A new IP header is inserted into the resulting packet to indicate as the source address that of the root node 4 and as the destination address that of the next node).
  • Figure 10 illustrates the generic format of a multicast packet at the output of the root node 4 to the hosts H1, H2, and H3.
  • each set of nodes of the same position in the routing header ( nodes @ _N2 and @ _N3 in Figure 9) will be considered a logical node.
  • the number of child nodes of a current node is deduced from a specific field of the routing header which will be associated with each logical node of the routing header. .
  • the number of child nodes of the current node is indicated just before the list of these next nodes.
  • the operations at the different nodes of a sub-tree of the root node 4 will be denoted “level 1 operations”, and the operations at the intermediate nodes of the subtree of the root node 4 will be noted as “level 2 operations”.
  • level 1 operations the operations at the child node of the root node 4
  • level 2 operations the operations at the intermediate nodes of the subtree of the root node 4
  • the operations at the level of the hosts will be noted “operations of level 3”. Operations at a multicast router node (non-root node 4)
  • a multicast router node When a multicast router node receives a multicast packet from a parent node (the parent node is the root node 4 or another multicast router node) the processing of the received packet at that node depends on the number of child nodes of that node. current node (next nodes to a jump from the current node) that appear in the routing header.
  • the position of the next child nodes of a current node is calculated by considering all these nodes as a logical node in the routing header. This will make it possible to apply the position calculation method described in [J. Hui et al. "An IPv6 Routing Header for Source Roads with RPL", Internet Draft, (Work in Progress), 2011]).
  • the position sought is equal to the number of logical nodes in the routing header minus the number of remaining segments; both can be known using the same fields as the IPv6 routing header for RPL If the number of child nodes of the current node is equal to a 1, the processing of the packet received by the current node is identical to the basic approach described above comprising the reception of the packets, the address swapping and the transfer.
  • the current node If the number of child nodes of the current node is greater than 1, the current node generates as many copies of the internal packet (an internal packet is delimited by the internal IP header and the data as illustrated by FIG. of son. Then, the current node generates for each of these child nodes a new header that will include all the nodes of the subtree going from the child node of the current node (without including the child node) to the hosts associated with this subtree.
  • the current node For each generated routing header, the current node replaces the value indicated in the destination address of the external IP header of the received packet (the value being the address of the current node) by the address of its child node. The current node then puts the replaced address (the address of the current node) in the first position of the generated header and finally copies, from the received header, all the nodes going from the first node of this header (first node visited by the received packet) to the parent node of the current node.
  • the current node will associate the new external IP header with the generated routing header, as well as a copy of the internal packet and send the resulting packet to its child.
  • This procedure (association and sending) is repeated for each child node of the current node.
  • the process (receiving a multicast packet by a node multicast router, processing the packet according to the number of child nodes of this router) is thus repeated by each node appearing in the routing header (apart from the host).
  • FIG. 11 schematically illustrates the generic format of a multicast packet at the output of the node N1 (child node of the root node 4) and to its child nodes N2 and N3 of FIG. 9.
  • FIG. 12 schematically illustrates the generic format of a multicast packet at the output respectively of the nodes N2 and N3 and to the nodes N4, N5 and N6 of FIG. 9.
  • the number of next nodes at a jump of each of the nodes N4, N5, N6 is equal to one 1. Therefore, the processing of the packet received by each of these nodes is identical to the basic approach comprising, receiving packets, address swapping, and transferring said packets. Data transfer in the case of a unicast destination address (root node address)
  • the destination address of the packet received by the root node 4 is a unicast address
  • the latter verifies if this address belongs to it. If it does not, it transfers the packet to its specified destination using the standard unicast routing of the RPL protocol. If the unicast address belongs to the root node 4, it is in this case a multicast-in-unicast tunnel. The root node 4 then decapsulates the packet to cover the internal multicast packet which will be treated in the same way as in the case of the transfer of the data packets with a multicast destination address.
  • this variant does not require significant constraints at the routers of the multicast tree, namely: a global view of the network (and therefore important routing tables) and a calculation of routes at the intermediate nodes.
  • the end-to-end routes are indicated in the routing header.
  • the support for the multicast routing in the non-storage mode RPL protocol is modified in such a way proposing that the root node 4 generates a copy of the multicast packet and a copy of the routing header by last RPL multicast router on the path of the receiver rather than generating such copies per receiver, as proposed in the basic approach.
  • This approach is an optimization of the approach described in the first variant.
  • the routing header generated by the root node 4 will not include the address of the receiver, because there is no longer any need for such an address at the last router RPL multicast to this receiver.
  • this last router will transmit the multicast packets natively to the receiver (ie without tunneling, at protocol stack level 2, this results in a broadcast frame).
  • a RPL router noted Nx, receives a tunneled multicast packet and with a routing header, it checks if it is the last node of the routing header. If this is the case, it decapsulates the received packet (deletes the external header), deletes the routing header, and then transmits the internal packet natively to the receiver (s).
  • Figure 13 shows the example of Table 1 where the multicast packet address @ _MC3 is sent to the host @ _H2. If Nx is not the last node of the routing header, the processing of the packet at the Nx level will follow the operations indicated in the basic approach (reception, address swapping, transfer) or variant 1 (reception a multicast packet by a multicast router node, processing the packet according to the number of child nodes of this router).
  • This approach is simple in that it does not require any modification of the routing header format if it is applied to the basic approach or variant 1. In addition, it requires only simple operations (described in above) to define / implement at the levels of the root node 4 and the RPL routers.
  • the routing header in the data transfer procedure contains the multicast address of the group as the final destination.
  • the internal header of the basic approach header with multicast destination address
  • this variant requires the modification of the specification of the routing header in the context RPL which prohibits the use of a multicast address in the routing header.
  • the receiver sends a request for MLD Report Multicast Subscription Tunneled to Root Node 4. This is useful in the case where RPL (non-root) routers do not have the MLD router feature.
  • the root node 4 is assumed to be a MLD (MLD Querier) router.
  • MLD MLD Querier
  • the root node 4 deletes the internal IP header of the multicast packet (header whose destination is the multicast address of the group) before sending it with the appropriate routing header to the (basic approach) or the (variant 1) receiver (s).
  • This variant assumes that the receiver has associated (before its subscription request) its unicast address indicated in the routing header to the multicast address of the group to which it has subscribed.
  • the unicast address of the host may be, for example a virtual address.
  • the receiver will extract its unicast address from the routing header and internally recover the associated multicast address.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de routage en mode non-stockage d'un flux échangé entre une source et au moins un récepteur identifié par une adresse unicast, et ayant préalablement souscrit à au moins un groupe multicast dans un réseau de type LLN comportant un ensemble de nœuds de non-stockage et un nœud racine, capable de mémoriser des informations de routage, comportant les étapes suivantes: - associer dans une table de routage multicast gérée par le nœud racine (4) l'adresse unicast du récepteur et l'adresse multicast du groupe auquel a souscrit le récepteur, - transmettre le flux de la source vers le nœud racine, et à la réception du flux, le nœud racine (4) génère une copie dudit flux, insère dans les paquets de la copie du flux générée un entête de routage comportant l'adresse unicast du récepteur destinataire du flux, et transmet ledit flux au récepteur.

Description

PROCEDE DE ROUTAGE D'UN FLUX MULTICAST EN MODE NON-STOCKAGE
DESCRIPTION
DOMAINE TECHNIQUE
L' invention se situe dans le domaine des réseaux de télécommunication et concerne plus particulièrement un procédé de routage en mode non- stockage d'un flux de messages échangés entre une source et au moins un récepteur identifié par une adresse unicast, et ayant préalablement souscrit à au moins un groupe multicast dans un réseau de type LLN (Lower power and Lossy channel Network) comportant un ensemble de nœuds de non-stockage et un nœud racine, appelé également root, capable de mémoriser des informations de routage.
Un mode de non-stockage (non storing mode en anglais) dans un réseau tel qu'un réseau de type LLN est un contexte réseau dans lequel les nœuds du réseau ont très peu de mémoire, voire pas de mémoire du tout.
L'invention s'applique particulièrement mais non exclusivement pour réaliser des opérations de multidiffusion (multicast) via des réseaux informatiques à fortes contraintes en termes de ressources disponibles (batteries, mémoires, capacités de calculs, liens disponibles, etc.) . De tels réseaux sont souvent connus sous le terme LLN (Lower power and Lossy channel Network) . Un exemple d'un tel réseau LLN est le réseau RPL (IPv6 Routing Protocol for Low power and Lossy Networks) en mode dit de non-stockage .
L' invention combine à la fois le contexte des réseaux informatiques/télécom à faible ressources (LLNs) , par exemple les réseaux de capteurs sans fils (Wireless Sensor Networks) , ainsi que les communications IP multicast .
ÉTAT DE LA TECHNIQUE ANTÉRIEURE
Un problème technique de l'art antérieur provient du fait que le support du routage multicast n'a pas été traité de manière satisfaisante dans le contexte des réseaux à très faibles ressources, c.à.d. les réseaux LLNs . En particulier, le manque, voire l'absence, de mémoire au niveau des nœuds de routage dans le contexte LLN rend les solutions conventionnelles de routage multicast dans l'Internet (ex. MOSPF, PIM-SM, etc.), inopérables dans le contexte LLN, car celles-ci exigent un stockage des états tels que les tables de routage, etc. Ce problème est d'autant plus compliqué que, dans le cas d'un réseau RPL spécifiquement, la technique de routage unicast pour le mode non-stockage, dite de routage par la source (source routing en anglais) , n'autorise pas l'utilisation des adresses multicast dans les paquets routables en vue d'éviter des attaques par inondation du réseau (network flooding en anglais) ou par déni de service (DoS) .
Par conséquent, une nouvelle technique de routage multicast pour le mode non-stockage doit être définie .
Le document ["S. Peng et al. "SenCast : Scalable Multicast in Wireless Sensor Networks", IEEE IPDPS Conférence, 2008] décrit une solution multicast pour les réseaux de capteurs dans laquelle un nœud spécial appelé « sink » collecte l'information de voisinage de chaque capteur. La topologie globale du réseau est constituée au niveau du « sink ». Cette topologie contient la position de chaque capteur, l'identifiant de chaque capteur, et la relation de voisinage entre capteurs. Le « sink » construit l'arbre multicast en se basant sur un algorithme dit d'approximation de l'arbre de Steiner (Steiner tree approximation algorithm) qui calcule l'arbre multicast minimal/optimal sur un ensemble de capteurs. Bien que cette solution mentionne l'utilisation d'un entête de routage pour la transmission des paquets multicast à partir du « sink », une fois l'arbre construit, elle ne décrit aucun mécanisme pour la construction de l'entête de routage ni pour la gestion de la table de routage associée.
Le document [M. Bag-Mohammadi et al. "On the efficiency of explicit multicast routing protocols", IEEE ISCC Conférence, 2005] décrit une solution dans laquelle une source multicast génère le code de description de l'arbre multicast et l'inclut comme entête dans les paquets de données. Le code généré contient les adresses IP de tous les récepteurs ainsi que celles d'un ensemble de routeurs spécifiques de l'arbre appelés BPs (Branching Points) . La source collecte la description de l'arbre multicast à partir des requêtes d'adhésion des membres du groupe multicast. Lorsqu'un router BP reçoit un paquet de données, il décode le code de l'arbre afin de déterminer le (s) prochain (s) BPs et/ou récepteur ( s ) . Ensuite, le BP courant génère les copies nécessaires du paquet et les transmets vers les adresses IP déterminées à partir du code .
Cette solution ne supporte pas le transfert des paquets de type IP multicast au niveau des routeurs. De plus, elle ne décrit aucune opération de gestion de table de routage multicast. Enfin, cette solution n'est pas adaptée pour des réseaux impliquant des nœuds dépourvus de capacité de traitement et de stockage, et par conséquent, incapables de générer des copies des paquets à router . Un but de l'invention est de pallier les inconvénients de l'art antérieur décrit ci-dessus.
EXPOSÉ DE L' INVENTION
Un but de l'invention est de router les paquets pour un groupe multicast sans que l'information de routage, multicast ou unicast, soit présente au niveau des nœuds de routage.
Un autre but de l'invention est de réaliser un routage multicast de bout-en-bout, dans le mode non- stockage, de manière transparente par rapport à d'éventuels nœuds de routage intermédiaires entre la source et le récepteur destinataire du flux. Ceci est obtenu par procédé de routage en mode non-stockage de paquets d'un flux échangés entre une source et au moins un récepteur Hi (i =1, 2, 3,...) identifié par une adresse unicast, et ayant préalablement souscrit à au moins un groupe multicast MCj (j =1, 2, 3,...) dans un réseau de type LLN comportant un ensemble de nœuds Ni (i =1, 2, 3,...) de non-stockage et un nœud racine, capable de mémoriser des informations de routage.
Le procédé selon l'invention comporte les étapes suivantes:
- envoyer par le récepteur Hi au nœud racine une demande de souscription à un groupe multicast MCj (j=l, 2, 3, ...) contenant l'adresse unicast du récepteur Hi et l'adresse multicast dudit groupe multicast, associer dans une table de routage multicast gérée par le nœud racine l'adresse multicast MCj à l'adresse unicast du récepteur Hi ayant souscrit au groupe multicast MCj ainsi qu'à la liste des nœuds intermédiaires sur le chemin entre le nœud racine et ledit récepteur Hi;
- transmettre un paquet d'un flux multicast de la source vers le nœud racine;
et à la réception du paquet du flux multicast, le nœud racine génère une copie dudit paquet, ajoute à la copie générée un entête de routage comportant une liste de nœuds intermédiaires sur le chemin entre le nœud racine et ledit récepteur Hi, et transmet ladite copie du paquet multicast au récepteur Hi via ladite liste de nœuds intermédiaires .
Dans une variante de réalisation du procédé selon l'invention, la table de routage multicast gérée par le nœud racine comporte en outre une liste des nœuds intermédiaires destinés à retransmettre les paquets provenant du nœud racine au récepteur.
Selon l'invention, pour souscrire au groupe multicast, le récepteur envoie au nœud racine une demande de souscription contenant son adresse unicast et l'adresse multicast du groupe via un message DAO (Destination Avertissement Object) du protocole RPL (Routing Protocol for Low power and Lossy Networks) ou via un message MLD ('Multicast Listener Discovery) report . Le récepteur envoie ladite demande de souscription avec une portée locale multicast (link-local multicast) ou, en unicast, directement au nœud racine, et à la réception de la demande, le nœud racine enregistre le récepteur dans la table de routage multicast. BRÈVE DESCRIPTION DES DESSINS
D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles :
la figure 1, représente schématiquement l'architecture d'un exemple de réseau de type LLN, la figure 2 illustre schématiquement une procédure de souscription d'un récepteur à un groupe multicast dans un réseau selon l'invention,
la figure 3 est un organigramme illustrant le traitement, par le nœud racine, des requêtes d'adhésion d'un récepteur à un groupe multicast selon l'invention ;
la figure 4 illustre schématiquement le transfert de paquets d'un flux d'une source vers un nœud racine selon l'invention,
la figure 5 illustre schématiquement le transfert de paquets du flux du nœud racine vers un récepteur d'un groupe multicast selon l'invention;
la figure 6 illustre schématiquement l'adressage successif pour transmettre un paquet multicast du nœud racine vers un récepteur appartenant à un groupe multicast selon l'invention;
la figure 7 est un organigramme illustrant le traitement, par le nœud racine, d'un paquet de données reçu selon l'invention ; la figure 8 est un organigramme illustrant le traitement, par le nœud racine, d'une requête de retrait d'un récepteur d'un groupe multicast,
la figure 9 illustre schématiquement une variante d'un arbre de routage défini par le nœud racine selon 1 ' invention .
La figure 10 illustre schématiquement un format générique d'un paquet multicast à la sortie du nœud racine selon l'invention,
Les figures 11 et 12 illustrent schématiquement l'évolution du format générique de la figure 10 lors de la transmission du paquet du nœud racine à un récepteur selon l'invention ;
La figure 13 illustre schématiquement une deuxième variante selon l'invention du transfert des paquets du nœud racine vers un récepteur d'un groupe multicast .
EXPOSE DETAILLE DE MODES DE REALISATION PARTICULIERS
L'invention sera décrite, par référence à la figure 1, pour le routage des paquets d'un flux transmis d'une source 2 à plusieurs récepteurs Hl, H2, H3 et H4 appelés hôtes dans un réseau LLN.
Comme cela est illustré par la figure 1, le réseau LLN est constitué d'un ensemble de nœuds NI, N2, N3, N4 et N5 de non-stockage et d'un nœud spécial appelée nœud racine 4 capable de stocker des informations de routage. Un exemple type de cette configuration est le mode non-stockage du protocole RPL (Routing Protocol for Low power and Lossy Networks) . Rappelons que dans le mode de non-stockage, le flux d' information est tout d' abord envoyé de proche en proche vers le nœud racine 4 qui construit, par la suite, l'entête de routage nécessaire à l'envoi ultérieur du paquet de proche en proche vers la destination finale. Les autres nœuds NI, N2, N3, N4 et N5 du réseau ne peuvent faire ce genre d'opération car ils ont très peu de mémoire, voire pas de mémoire du tout.
L' invention introduit les aspects suivants qui seront décrits en détail dans la suite de la description :
• Définition d'un message de signalisation spécifique pour le protocole RPL, permettant à un hôte de souscrire à un groupe multicast. Le message associe l'adresse unicast de l'hôte à l'adresse multicast du groupe .
• Définition d'un message de signalisation spécifique pour le protocole RPL, permettant à un hôte de se désinscrire d'un groupe multicast. Le message associe l'adresse unicast de l'hôte à l'adresse multicast du groupe .
• Définition d'une table de routage multicast au niveau du nœud racine 4; la table de routage associant une adresse multicast d'un groupe à une liste d'adresses unicast d'hôtes.
• Définition d'un mécanisme de construction, à partir de la dite table de routage multicast, d'un entête de routage associé à un groupe multicast après réception du paquet multicast émis par la source. L'entête de routage est construit par le nœud racine 4.
• Définition d'un mécanisme de suppression d'entrées de la table de routage multicast lorsqu'un hôte quitte le groupe multicast ou lorsque la durée d'adhésion d'un hôte à un groupe multicast expire.
Préalablement à la transmission du flux multicast par la source 2, chaque hôte Hx, (x=l, 2, 3, 4...) s'inscrit à un groupe multicast identifié par une adresse multicast @MCj susceptible de recevoir ce flux. A cet effet, l'hôte Hi envoie une demande de souscription multicast via un message DAO (Destination Avertissement Object) de RPL ou un message MLD ('Multicast Listener Discovery) report, par exemple. La demande de souscription contient l'adresse unicast de l'hôte ainsi que l'adresse multicast du groupe auquel l'hôte souhaite adhérer. L'hôte envoie sa demande de souscription avec une portée locale multicast [link-local multicast) ou en unicast directement vers le nœud racine 4 par exemple, c'est-à-dire, lorsque l'adresse de destination mentionnée dans la demande de souscription est l'adresse du nœud racine 4. Dans ce dernier cas, la requête d'adhésion peut transiter par des nœuds routeurs intermédiaires si la racine 4 se trouve à plusieurs sauts (par exemple, n'est pas dans la portée radio) de l'hôte.
Dans tous les cas, la demande de souscription arrivera au nœud racine 4 qui procède alors à l'enregistrement du nouvel hôte dans une table de routage spécifique. Cette table de routage contient, notamment, l'adresse unicast de l'hôte, l'adresse multicast qui lui est associée, et la liste des nœuds intermédiaires qui permettent aux paquets provenant du nœud racine 4 d'atteindre l'hôte. Un exemple d'une telle table de routage est illustré ci-après pour un nombre n d'hôtes et 3 groupes multicast, où @_X signifie l'adresse IP du nœud X, et T_xy signifie la durée de vie de la souscription du hôte Hx au groupe MCy.
Tableau 1
L'échange d'un message DAO pour procéder à la 0 souscription du hôte H2 à un groupe multicast identifié par une adresse multicast @MC3 est illustrée par les flèches sur les figures 1 et 2.
A l'étape 10, l'hôte H2 envoie un message DAO destiné à la racine via le nœud N2. Si l'hôte H2 supporte 5 des messages de signalisation spécifiques aux réseaux LLNs tel que dans un réseau RPL, le message DAO du protocole RPL peut être utilisé avec deux options de type " target" et au moins une option "transit information" par option "target" (pour être conforme à la spécification du protocole RPL) . Chaque option "transit information" indique l'adresse d'un nœud parent de l'hôte. Toutefois, les deux options "transit" peuvent indiquer l'adresse d'un même nœud parent de l'hôte. Dans l'exemple de la figure 2, l'hôte H2 enverra une requête DAO au format suivant :
Les deux options target contiennent successivement l'adresse du hôte (@_H2) et l'adresse multicast du groupe (@_MC3) auquel le hôte veut souscrire. La durée de vie de la souscription, est inscrite dans l'une des deux options "transit information"; de préférence dans l'option "transit information" associée à l'option "target" indiquant l'adresse multicast de souscription.
Notons que l'ordre de l'adresse du hôte (@_H2) et de l'adresse multicast du groupe (@_MC3) dans le message DAO est indifférent.
A l'étape 12, le nœud N2 transmet le message DAO au nœud intermédiaire N4. Ce dernier transfère le message DAO au nœud intermédiaire suivant N5 (étape 14) qui le transmet au nœud racine 4 (étape 16) .
Dans une autre variante, la requête de souscription peut comporter juste l'option "target" contenant l'adresse multicast avec l'option "transit information" incluant le nœud parent et la durée de vie de la souscription. Ceci est vrai si l'adresse unicast de l'hôte est mentionnée comme adresse source de l'entête IP du message DAO arrivant au nœud racine 4. Dans ce cas, comme dans le cas du message DAO précédent, l'hôte envoie directement le message DAO vers le nœud racine 4 via les nœuds routeurs intermédiaires .
Lorsque le nœud racine 4 reçoit le message DAO, il vérifie notamment les options target. L'existence d'une adresse multicast dans une option target signifie au nœud racine 4 qu'il s'agit d'une requête d'adhésion à un groupe multicast. Si l'association (adresse hôte, adresse multicast) n'existe pas dans la table de routage, le nœud racine 4 y ajoute une entrée correspondant au nouvel hôte. Si l'entrée existe déjà, la durée de vie correspondant à l'association (adresse hôte, adresse multicast) sera remise à une valeur maximale, c.à.d. la souscription de l'hôte au groupe associé sera renouvelée. A noter que la durée de vie d'une première souscription est recopiée par le nœud racine 4 dans l'entrée correspondante de la table de routage. Toutefois, le nœud racine 4 peut tout à fait établir une durée de vie d'une souscription par décision interne, par exemple si cette durée n'est pas précisée dans le message de souscription. Par exemple, suite à l'étape 16 de la figure 2, la racine 4 reçoit du nœud N5 le message DAO envoyé par l'hôte H2. A cette étape, la racine constitue la table de routage multicast, y ajoute l'adresse @H2 si ce dernier n'y figure pas encore, et effectue une mise à jour de la durée de souscription du hôte H2 au groupe multicast @MC3.
Dans un autre mode de réalisation, la souscription du hôte H2 à un groupe multicast identifié par une adresse multicast @MC3 est réalisée par émission d'une requête MLD.
Notons que si l'hôte H2 veut souscrire à un groupe multicast en envoyant un MLD report, alors le message de demande de souscription sera intercepté par un nœud RPL routeur qui le transfère au nœud racine 4. En effet, dans le mode stockage du protocole RPL, dès qu'un router reçoit un message MLD report, il le transforme en message DAO qui sera transmis de proche en proche vers le nœud racine 4.
L' invention permet donc de transformer le message MLD report en un message DAO dans le mode non- stockage. Ensuite, une fois le message DAO créé, il sera transmis directement vers le nœud racine 4.
Le format du message DAO est celui qui est décrit précédemment.
La figure 3 est un organigramme illustrant le traitement par le nœud racine 4, des requêtes d'adhésion d'un récepteur hôte à un groupe multicast selon 1 ' invention .
A l'étape 30, le nœud racine 4 reçoit le message DAO du nœud hôte.
A l'étape 31, le nœud racine 4 vérifie si une adresse @ mcast (p.ex. @_mcast_j ) est présente ou non dans une option target et si une adresse @ unicast (p.ex. @_hôte_i) est présente ou non dans une autre option target .
Si ces deux adresses sont présentes dans des options target le nœud racine 4 procède à l'étape 32. Si aucune adresse multicast n'est présente dans une option target, le traitement du message est interrompu .
Si une adresse multicast est présente dans une option target mais aucune adresse unicast n'est présente dans une option target, le nœud racine 4 utilise alors l'adresse source du message DAO comme étant ladite adresse unicast (p. ex. = 0_hôte_i) et procède à l'étape 32.
A l'étape 32, le nœud racine 4 vérifie si l'option transit info est présente ou non dans le message dans DAO.
Si l'option transit info n'est pas présente le message dans le message DAO, le traitement du message est interrompue .
Sinon, le nœud racine 4 vérifie, à l'étape 33, si la durée de vie Tij de souscription de l'hôte au groupe multicast est nulle.
Si oui, le nœud racine 4 traite, à l'étape 34, le message DAO comme une requête de retrait du groupe multicast.
Sinon, le nœud racine 4 vérifie, à l'étape 35, si l'association (@_hôte_i, @_mcast_j ) existe dans la table de routage .
Si oui, le nœud racine 4 renouvelle, à l'étape 36, la souscription de l'hôte au groupe multicast.
Sinon, le nœud racine 4 ajoute, à l'étape 38, l'association d'adresses (@_hôte_i, @_mcast_j) dans la table de routage et copie la durée de vie (T_ij) pour (@_hôte_i, @_mcast_j ) .
Après souscription des récepteurs hôtes au groupe multicast, le transfert des paquets de données de la source 2 vers ces hôtes s'effectue en deux phases: une première phase au cours de laquelle les paquets sont d'abord transmis de la source 2 vers le nœud racine 4, et une deuxième phase au cours de laquelle les paquets sont transmis du nœud racine 4 vers les récepteurs hôtes.
La figure 4 illustre schématiquement le transfert des paquets multicast de la source 2 vers le nœud racine 4.
Lors de la première phase, la source 2 envoie (étape 40) les paquets vers un ou plusieurs nœuds routeurs de son voisinage qui sont à sa portée. Cet envoi peut être effectué aussi bien en multicast (mode de base/préféré) qu'en multicast tunnelé (multicast dans unicast .
Si le nœud du voisinage de la source 2 reçoit un paquet multicast, il le transmet (étape 42) tel quel sur son interface de sortie au prochain nœud intermédiaire qui le transmet au nœud racine 4 (étape 44) .
Selon une caractéristique de l'invention, dans le mode non-stockage, un nœud qui reçoit un paquet multicast d'un nœud dit fils, c'est-à-dire, menant vers la source 2, transfert ce paquet vers son nœud dit parent, c'est-à-dire un nœud menant vers le nœud racine 4.
Dans le cas où la source ne peut pas envoyer ses paquets en multicast nativement/directement , elle envoie ses paquets multicast dans un tunnel unicast soit vers son nœud RPL voisin soit directement vers le nœud racine 4. C'est le cas, par exemple, où la source se trouve dans un réseau qui ne supporte pas le multicast.
Ainsi, lorsque le nœud RPL intermédiaire voisin de la source 2 reçoit un paquet tunnelé provenant de celle-ci, il vérifie si l'adresse de destination du tunnel lui appartient. Si c'est le cas, le nœud intermédiaire décapsule le paquet reçu en supprimant l'entête IP externe et transmet le paquet multicast décapsulé tel quel sur son interface de sortie au prochain nœud intermédiaire en direction du nœud racine 4. Ainsi, chaque nœud intermédiaire recevant un paquet multicast d'un nœud fils (nœud menant vers la source) transfert ce paquet vers son nœud parent (nœud menant vers le nœud racine 4 ) .
Si par contre l'adresse de destination du paquet n'appartient pas au nœud RPL intermédiaire voisin de la source 2, il s'agit alors normalement de l'adresse du nœud racine 4. Dans ce cas, le nœud RPL intermédiaire transmet le paquet tel quel sur son interface de sortie au prochain nœud RPL intermédiaire en direction du nœud racine 4. Cette phase de transfert vers le nœud racine 4 peut s'effectuer suivant la stratégie de routage unicast par défaut du réseau RPL (en général, chaque nœud envoie le paquet à un nœud découvert à priori à travers un message d'annonce (tel que le message DIO (DODAG Information Object) du protocole RPL) .
A la réception du paquet, le nœud racine 4 vérifie si le paquet a une adresse de destination multicast ou une adresse de destination qui appartient au nœud racine 4. Par conséquent, deux cas sont à distinguer, le premier cas où les paquets portent une adresse de destination multicast, et le deuxième cas où les paquets portent une adresse de destination unicast qui appartient au nœud racine 4.
S'il s'agit d'une adresse multicast, le nœud racine 4 vérifie si cette adresse est enregistrée dans sa table de routage (par exemple s'il existe au moins une entrée indiquant cette adresse multicast) . Si l'adresse multicast existe, le nœud racine 4 procède alors à la construction d'un ensemble d'entêtés de routage. Il y aura ainsi un entête de routage par hôte. Pour chaque hôte d'un groupe multicast donné, le nœud racine 4 génère une copie du paquet reçu et y ajoute l'entête de routage correspondant audit hôte.
L'entête de routage pour un hôte hôte_i appartenant un groupe multicast mcast_j est construit à partir de l'entrée de la table de routage correspondant à la combinaison (hôte_i@, mcast_j@). L'entête contient l'adresse IP de l'hôte ainsi que l'adresse IP de chaque nœud sur le chemin de l'hôte.
Une fois l'entête construit, il est ajouté à une copie du paquet reçu par le nœud racine 4. Le paquet résultant est ensuite tunnelé vers le premier nœud sur le chemin vers l'hôte. Un nouvel entête IP est inséré dans le paquet résultant pour indiquer comme adresse source celle du nœud racine 4 et comme adresse de destination celle du prochain nœud. Ce processus, au niveau du nœud racine 4, de construction de l'entête de routage à partir de la table de routage, de génération d'une copie du paquet reçu, d'ajout de l'entête de routage à la copie du paquet reçu, et de tunneling en unicast du paquet résultant vers le premier nœud sur le chemin du hôte est répété pour chaque hôte ayant souscrit au groupe multicast. Par conséquent, toutes les entrées de la table de routage dans lesquelles l'adresse multicast du paquet est mentionnée seront utilisées. Par exemple suivant la table 1 ci-dessus, un paquet multicast destiné au group @_MC2, reçu par le nœud racine 4 aura la forme suivante :
@ source : source @ @ dest : @ MC2 Données (ex.1234567)
Pour ce même paquet, le nœud racine 4 générera deux copies des paquets à transmettre. Chaque copie sera associée à un entête de routage différent ; l'un correspondant à l'hôte H3, l'autre correspondant à l'hôte H4. Chaque paquet résultant sera ensuite tunnelé vers le nœud N5 en utilisant un entête IP externe ayant comme adresse source celle du nœud racine 4, et comme adresse de destination celle de N5. Ainsi, les deux paquets finaux à destination de H3 et H4 auront le format suivant :
Entête IP externe Entête de routage Entête IP interne r .Λ r A r Λ_
H3
Entête IP externe Entête de routage Entête IP interne
Quand le nœud indiqué dans la destination de l'entête IP externe reçoit le paquet, le traitement du paquet reçu au niveau de ce nœud est identique au traitement du paquet avec entête de routage IPv6 dans RPL . En particulier, le nœud permutera la valeur indiquée dans l'adresse de destination de l'entête IP externe (la valeur étant l'adresse du nœud courant) avec l'adresse du prochain nœud indiquée dans l'entête de routage (la position du prochain nœud dans l'entête de routage est calculée suivant l'opération indiquée pour les entêtes de routage IPv6 dans le protocole RPL selon lequel la position est égale au nombre d'adresses dans l'entête de routage moins le nombre de segments restants ; tous deux connus d' après des champs spécifiques de l'entête de routage IPv6 dans RPL) . Le paquet est ensuite envoyé au prochain nœud. Le processus (réception, permutation d'adresse, transfert) est ainsi répété par chaque nœud figurant dans l'entête de routage (mis à part l'hôte) .
La figure 5 illustre les étapes de transfert des paquets du nœud racine 4 vers l'hôte H2.
A l'étape 50, le nœud racine 4 transmet les paquets multicast au premier nœud intermédiaire sur le chemin vers l'hôte. Ce nœud intermédiaire transfère lesdits paquets vers le nœud intermédiaire suivant (étape 52) qui le transfère au nœud hôte H2 (étape 54) .
Par exemple, comme illustré par la figure 6, lors du transfert d'un paquet du nœud racine 4 à destination de l'hôte H3, le nœud N5 permutera l'adresse de destination de l'entête IP externe (@_N5) avec l'adresse du prochain nœud (@_N4) et transférera le paquet résultant au nœud N4. Ensuite, le nœud N4 permutera à son tour l'adresse de destination de l'entête IP externe (@_N4) avec l'adresse du prochain nœud (@_H3) et transférera le paquet résultant à l'hôte H3.
La figure 7 est un organigramme illustrant le traitement d'un paquet de données reçu par le nœud racine 4.
A l'étape 70, le nœud racine 4 reçoit le paquet de données, et vérifie, à l'étape 71, si l'adresse de destination (@_dest) est soit celle du nœud racine 4 soit de type multicast.
Si l'adresse de destination (@_dest) n'est ni celle du nœud racine 4 ni une adresse multicast, le paquet de donnée est alors routé selon le mode unicast de base du protocole RPL (étape 71a) .
Si c'est le cas, le nœud racine 4 vérifie, à l'étape 72, si l'adresse (@_dest) est de type multicast.
Si oui, à l'étape 73 le nœud racine 4 parcourt la table de routage sur l'entrée (*, @_dest) , et vérifie, à l'étape 74, si cette adresse (@_dest) est présente dans la table de routage.
Si la table de routage ne contient pas ladite adresse, le traitement du paquet est interrompu. Si toutefois le nœud racine 4 possède une connexion vers un réseau externe (typiquement grâce à une interface réseau autre que celle utilisée pour se connecter au réseau LLN) il peut transmettre le paquet multicast vers ce réseau externe .
Si la table de routage contient ladite adresse, à l'étape 75, le nœud racine 4 récupère l'adresse du hôte @_Hi de l'entrée de la table de routage où l'adresse de destination @_dest a été trouvée et ajoute, à l'entête de routage, tous les nœuds sur le chemin du flux à destination de l'adresse @_Hi, à l'exception du premier nœud sur ce chemin.
A l'étape 76, le nœud racine 4 génère un tunnel pour transmettre le paquet résultant vers le premier nœud situé sur le chemin du flux à destination de l'adresse @_Hi .
Le processus reprend à partir de l'étape 73 pour le paquet de donnée suivant.
Si par contre l'adresse (@_dest) n'est pas de type mcast, le nœud racine 4 vérifie, à l'étape 77, si le paquet reçu est tunnelé.
Si non, le traitement du paquet est interrompu .
Si oui, le nœud racine 4 décapsule le paquet à l'étape 78 et vérifie, à l'étape 79, si l'adresse de destination du paquet interne (@_dest) est de type multicast .
Si non, le traitement du paquet est interrompu.
Si oui, le traitement du paquet se poursuit à partir de l'étape 73.
Si l'adresse de destination du paquet reçu par le nœud racine 4 est une adresse unicast mais n'appartient pas au nœud racine 4 le paquet reçu est alors routé selon le mode unicast de base du protocole RPL.
A noter que si le nœud racine 4 possède une connexion vers un réseau externe (typiquement grâce à une interface réseau autre que celle utilisée pour se connecter au réseau LLN) il peut transmettre le paquet multicast vers ce réseau externe. Lorsqu'un récepteur hôte reçoit un paquet multicast tunnelé avec entête de routage et provenant du nœud racine 4, il enlève l'entête IP externe correspondant au tunnel ainsi que l'entête de routage afin de récupérer les données.
Une requête de désinscription d'un groupe multicast peut être émise soit via des messages utilisant le protocole MLD (Multicast Listener Discovery) de IPv6", soit des messages un protocole spécifique aux réseaux LLN tel que par exemple des messages DAO du protocole RPL (RPL DAO contenant une option "Transit Information" avec une durée de vie nulle) . Ainsi deux cas sont donc à distinguer, soit émission d'une requête MLD (MLD Report), soit émission d'une requête spécifique au LLN (ex. RPL DAO) .
Une requête MLD sera émise par un nœud non-RPL au sens du protocole RPL, qui selon le standard MLD, est envoyé en multicast avec portée locale/lien (link-local multicast) . Dans ce cas, le message de l'hôte sera intercepté par un nœud routeur RPL. Dès que ce router RPL reçoit ladite requête MLD, il la transforme en message DAO qui sera transmis vers le nœud racine 4. Ce message DAO inclura deux options "target" . La première option contiendra l'adresse unicast de l'hôte. La deuxième option "target" contiendra l'adresse multicast du groupe duquel l'hôte souhaite se désinscrire. Ce message DAO contiendra aussi deux options "Transit Information" (une par option "target"); l'une d'elle contenant un champ "durée de vie" nul. Ainsi, le format du message DAO pour un hôte non-RPL donné, soit le hôte H2 par exemple (H2 est considéré ici comme un nœud non-RPL) , est décrit ci-après : Entête @_H2 @N_2 @_MC3 0x00000000, @N_2
DAO
Target Transi t Target Transit opt2
optl optl opt2
Par ailleurs, pour à un hôte supportant les messages spécifiques aux réseaux LLNs tel qu'un réseau RPL, l'invention propose que ledit hôte (hôte RPL) envoie un message DAO au lieu d'un message MLD report. Le message DAO, dans ce cas, a un format identique à celui décrit pour le cas d'un hôte non-RPL. Ce message DAO sera directement envoyé au root.
Toutefois, la requête de retrait peut comporter (que ce soit pour le cas d'un hôte RPL ou non- RPL) juste l'option target contenant l'adresse multicast avec l'option "transit information" associée avec une durée de vie nulle, si l'adresse unicast de l'hôte est mentionnée comme adresse source de l'entête IP du message DAO arrivant au nœud racine 4.
L'existence d'une adresse multicast dans une option target ainsi qu'un champ "durée de vie" nul dans l'option "Transit Information" associée (que ce soit pour le cas d'un hôte RPL ou non-RPL) signifiera au nœud racine 4 qu'il s'agit d'une requête de retrait d'un groupe multicast. Dans ce cas, si l'association (adresse hôte, adresse multicast) existe dans la table de routage, l'entrée correspondante est alors supprimée de la table de routage. Si l'entrée n'existe pas, la requête de l'hôte sera ignorée par le nœud racine 4. La figure 8 est un organigramme illustrant le traitement, par le nœud racine 4, des requêtes de retrait d'un groupe multicast émises par un hôte.
A l'étape 80, le nœud racine 4 reçoit un message DAO d'un hôte souhaitant se désinscrire d'un groupe multicast et vérifie, à l'étape 81, si l'adresse du groupe multicast j (mcast_j ) est présente dans une option target et si l'adresse unicast du hôte Hi (@_Hi) est présente dans une autre option target.
Si ces deux adresses sont présentes dans des options target le nœud racine 4 procède à l'étape 82.
Si aucune adresse multicast n'est présente dans une option target, le traitement du message est interrompu .
Si une adresse multicast est présente dans une option target mais aucune adresse unicast n'est présente dans une option target, le nœud racine 4 utilise alors l'adresse source du message DAO comme étant ladite adresse unicast (p. ex. @_Hi) et procède à l'étape 82.
A l'étape 82, le nœud racine 4 vérifie si l'association (@_hôte_i, @_mcast_j) existe dans la table de routage.
Si non, le traitement du message DAO est interrompu .
Si oui, le nœud racine 4 vérifie, à l'étape 83, si l'option "transit information" est présente dans le message DAO.
Si non, le traitement du message DAO est interrompu . Si oui, le nœud racine 4 vérifie, à l'étape 84, si la durée Tij de souscription de l'hôte Hi au groupe multicast mcast_j est nulle.
Si non, le nœud racine 4 renouvelle, à l'étape 85, la souscription du hôte (@_hôte_i) par une mise à jour de la durée Tij .
Si oui, le nœud racine 4 supprime à l'étape 86, l'entrée (@_hôte_i, @_mcast_j ) de la table de routage.
Dans une première variante de réalisation de l'invention, l'entête de routage décrit l'arbre multicast allant du nœud racine 4 vers l'ensemble des récepteurs multicast. Cela permet de réduire le nombre de copies envoyés vers les destinataires d'un groupe multicast et d'optimiser ainsi la bande passante. D'autre part, cette variante définit un nouveau type d' entête de routage IPv6 pour le protocole RPL .
La Figure 9 illustre schématiquement un exemple dans lequel la source 2 envoie le paquet multicast d'adresse @_MC1 vers le nœud racine 4. Par la suite, ce nœud racine 4 construit l'entête de routage et envoie un seul paquet vers les destinations @_H1, @_H2, et @_H3, membres du groupe MCI .
Dans cette variante, les procédures d'adhésion et de retrait du groupe multicast sont identiques à celles décrite précédemment par référence aux figures 2, 3 et 8.
Quant à la phase de transfert de données, elle se déroule comme suit:
Lorsque le nœud racine 4 reçoit un paquet provenant d'une source multicast 2, il vérifie si le paquet a une adresse de destination multicast ou une adresse de destination qui appartient au nœud racine 4. Deux cas sont alors à distinguer selon que l'adresse de destination est une adresse multicast ou unicast.
Transfert des données dans le cas d'une adresse de destination multicast
Opérations au niveau du nœud racine 4
Si le paquet a une adresse de destination multicast, le nœud racine 4 vérifie si cette adresse est enregistrée dans sa table de routage (par exemple s'il existe au moins une entrée indiquant cette adresse multicast). Si l'adresse multicast n'existe pas, le traitement est interrompu. Si toutefois le nœud racine 4 possède une connexion vers un réseau externe (typiquement grâce à une interface réseau autre que celle utilisée pour se connecter au réseau LLN) il peut transmettre le paquet multicast vers ce réseau externe. Si l'adresse multicast existe, le nœud racine 4 procède alors à la construction d'un entête de routage unique pour chacun de ses sous arbres .
Dans cette variante de l'invention, un sous- arbre d'un nœud racine représente l'arbre allant d'un fils (ou d'un prochain nœud à un saut du nœud racine 4) jusqu'aux hôtes servis par ce sous-arbre. Ainsi, dans l'exemple de la figure 9, le nœud racine 4 a un seul sous- arbre qui part du nœud NI jusqu'aux hôtes Hl, H2, et H3.
L'entête de routage décrit dans cette variante de l'invention est de nouveau type car son format est diffèrent de celui de l'entête de routage IPv6 pour RPL [J. Hui et al. "An IPv6 Routing Header for Source Routes with RPL", Internet draft, (Work in Progress) , 2011]). Cet entête de routage contiendra les adresses IP de tous les nœuds (dits routeurs multicast) du sous-arbre, à l'exception du nœud sommet du sous-arbre, ainsi que les adresses de l'ensemble des hôtes de ce sous-arbre.
Le nœud racine 4 générera autant de copies du paquet multicast reçu qu'il y a de sous-arbres (ou d'entêtés générés) . Chacune de ces copies du paquet multicast sera ajoutée à un entête de routage associé à un sous-arbre distinct du nœud racine 4. Le paquet résultant de chaque association (copie de paquet et entête de routage) sera ensuite tunnelé vers un nœud fils (du nœud racine 4) associé à l'entête. Un nouvel entête IP est inséré dans le paquet résultant pour indiquer comme adresse source celle du nœud racine 4 et comme adresse de destination celle du prochain nœud) .
La figure 10, illustre le format générique d'un paquet multicast à la sortie du nœud racine 4 à destination des hôtes Hl, H2, et H3.
Comme le nombre de nœuds fils d'un nœud courant (prochains nœuds à un saut du nœud courant) peut être supérieur ou égale à 1, et dans un souci de clarté, chaque ensemble de nœuds de même position dans l'entête de routage (ex. nœuds @_N2 et @_N3 de la Figure 9) sera considéré comme un nœud logique .
D'autre part, selon la présente variante de l'invention, le nombre de nœuds fils d'un nœud courant est déduit d'un champ spécifique de l'entête de routage qui sera associé à chaque nœud logique de l'entête de routage.
Comme illustré par la figure 10, à titre d'exemple, le nombre de nœuds fils du nœud courant est indiqué juste avant la liste de ces prochains nœuds. Par ailleurs, afin d'expliquer de manière claire les opérations au niveau des différents nœuds d'un sous-arbre du nœud racine 4, les opérations au niveau du nœud fils du nœud racine 4 seront notées « opérations de niveau 1 », et les opérations au niveau des nœuds intermédiaires du sous- arbre du nœud racine 4 seront notées « opérations de niveau 2 ». Enfin les opérations au niveau des hôtes seront notées « opérations de niveau 3 ». Opérations au niveau d'un nœud routeur multicast (non-nœud racine 4)
Lorsqu'un nœud routeur multicast reçoit un paquet multicast provenant d'un nœud parent (le nœud parent étant le nœud racine 4 ou un autre nœud routeur multicast) le traitement du paquet reçu au niveau de ce nœud dépend du nombre de nœuds fils de ce nœud courant (prochains nœuds à un saut du nœud courant) qui figurent dans l'entête de routage.
Dans la présente variante, la position des prochains nœuds fils d'un nœud courant est calculée en considérant l'ensemble de ces nœuds comme un nœud logique dans l'entête de routage. Ceci permettra d'appliquer la méthode de calcul de position décrite dans [J. Hui et al. "An IPv6 Routing Header for Source Routes with RPL", Internet draft, (Work in Progress) , 2011]). En d'autres termes, la position recherchée est égale au nombre de nœuds logiques dans l'entête de routage moins le nombre de segments restants; tous deux pouvant être connus en utilisant les même champs que ceux de l'entête de routage IPv6 pour RPL Si le nombre de nœuds fils du nœud courant est égal à un 1, le traitement du paquet reçu par le nœud courant est identique à l'approche de base décrite précédemment comportant la réception des paquets, la permutation d'adresse et le transfert.
Si le nombre de nœuds fils du nœud courant est supérieur à 1, le nœud courant génère autant de copies du paquet interne (un paquet interne est délimité par l'entête IP interne et les données comme illustré par la figure 10) qu'il a y de fils. Ensuite, le nœud courant génère pour chacun de ces nœuds fils un nouvel entête qui inclura tous les nœuds du sous-arbre allant du nœud fils du nœud courant (sans inclure le nœud fils) jusqu'aux hôtes associés à ce sous-arbre.
Pour chaque entête de routage généré, le nœud courant remplace la valeur indiquée dans l'adresse de destination de l'entête IP externe du paquet reçu (la valeur étant l'adresse du nœud courant) par l'adresse de son nœud fils. Le nœud courant met ensuite l'adresse remplacée (l'adresse du nœud courant) en première position de l'entête générée et y copie enfin, à partir de l'entête reçu, tous les nœuds allant du premier nœud de cet entête (premier nœud visité par le paquet reçu) jusqu'au nœud parent du nœud courant .
Ensuite, le nœud courant associera le nouvel entête IP externe à l'entête de routage généré, ainsi qu'à une copie du paquet interne et envoie le paquet résultant à son fils.
Cette procédure (association et envoi) est répétée pour chaque nœud fils du nœud courant. Le processus (réception d'un paquet multicast par un nœud routeur multicast, traitement du paquet en fonction du nombre de nœuds fils de ce routeur) est ainsi répété par chaque nœud figurant dans l'entête de routage (mis à part l'hôte) .
La figure 11 illustre schématiquement le format générique d'un paquet multicast à la sortie du nœud NI (nœud fils du nœud racine 4) et à destination de ses nœuds fils N2 et N3 de la figure 9.
La figure 12 illustre schématiquement le format générique d'un paquet multicast à la sortie respectivement des nœuds N2 et N3 et à destination des nœuds N4, N5 et N6 de la figure 9.
Comme illustré par cette figure 12, le nombre de nœuds prochains à un saut de chacun des nœuds N4, N5, N6 est égal à un 1. Donc, le traitement du paquet reçu par chacun de ces nœuds est identique à l'approche de base comportant, la réception des paquets, la permutation d'adresse, et le transfert desdits paquets. Transfert des données dans le cas d'une adresse de destination unicast (adresse du nœud racine)
Si l'adresse de destination du paquet reçu par le nœud racine 4 est une adresse unicast, ce dernier vérifie si cette adresse lui appartient. Si ce n'est pas le cas, il transfère le paquet vers sa destination indiquée en utilisant le routage unicast classique du protocole RPL . Si l'adresse unicast appartient au nœud racine 4, il s'agit dans ce cas d'un tunnel multicast- dans-unicast . Le nœud racine 4 décapsule alors le paquet pour recouvrir le paquet multicast interne qui sera traité de la même manière que dans le cas du transfert des paquets de données avec une adresse de destination multicast .
A noter que cette variante n'exige pas de contraintes importants au niveau des routeurs de l'arbre multicast, à savoir : une vision globale du réseau (et donc des tables de routages importantes) et un calcul des routes au niveau des nœuds intermédiaires. Dans la variante proposée, les routes de bout-en-bout sont indiquées dans l'entête de routage.
Selon une deuxième variante de réalisation de l'invention, pour réduire le nombre de copies envoyés vers les destinataires d'un group multicast et optimiser la bande passante, le support du routage multicast dans le protocole RPL en mode non-stockage est modifié de manière à proposer que le nœud racine 4 génère une copie du paquet multicast et une copie de l'entête de routage par dernier routeur RPL multicast sur le chemin du récepteur plutôt que générer de telles copies par récepteur, comme le propose l'approche de base.
Cette approche est une optimisation de l'approche décrite dans la première variante.
Dans cette approche, l'entête de routage généré par le nœud racine 4 n'inclura pas l'adresse du récepteur, car il n'y a plus besoin d'une telle adresse au niveau du dernier routeur RPL multicast vers ce récepteur.
En effet, ce dernier routeur transmettra les paquets multicast nativement vers le récepteur (c.à.d. sans tunneling. Au niveau 2 de pile protocolaire, cela se traduit par une trame broadcast) . Pour ce faire, chaque fois qu'un routeur RPL, noté Nx, reçoit un paquet multicast tunnelé et avec entête de routage, il vérifie s'il est le dernier nœud de l'entête de routage. Si c'est le cas, il décapsule le paquet reçu (supprime l'entête externe), supprime l'entête de routage, puis transmet le paquet interne nativement vers le (s) récepteur ( s ) .
La figure 13 reprend l'exemple de la table 1 où le paquet multicast d'adresse @_MC3 est envoyé à l'hôte @_H2. Si Nx n'est pas le dernier nœud de l'entête de routage, le traitement du paquet au niveau Nx suivra les opérations indiquées dans l'approche de base (réception, permutation d'adresse, transfert) ou de la variante 1 (réception d'un paquet multicast par un nœud routeur multicast, traitement du paquet en fonction du nombre de nœuds fils de ce routeur) .
Cette approche est simple en ce sens qu'elle ne nécessite aucune modification du format de l'entête de routage si elle est appliquée à l'approche de base ou à la variante 1. De plus, elle nécessite que de simples opérations (décrites ci-dessus) à définir/implémenter aux niveaux du nœud racine 4 et des routeurs RPL .
Dans une troisième variante de réalisation de l'invention, l'entête de routage dans la procédure de transfert des données contient l'adresse multicast du groupe en tant que destination finale. Ainsi, l'entête interne de l'approche de base (entête avec adresse de destination multicast) n'est plus nécessaire. Cependant, cette variante nécessite la modification de la spécification de l'entête de routage dans le contexte RPL qui interdit l'utilisation d'une adresse multicast dans l'entête de routage.
Dans une quatrième variante de réalisation de l'invention, le récepteur envoie une demande de souscription multicast de type MLD Report tunnelé vers le nœud racine 4. Ceci est utile dans le cas ou les routeurs RPL (non-racine) n'ont pas la fonctionnalité de routeur MLD.
Dans ce cas précis, le nœud racine 4 est supposé être un routeur MLD (MLD Querier) . Le reste du processus (stockage des souscriptions, mise à jour de la table de routage multicast, et construction des entêtes de routage) est identique à celui de la solution de base.
Dans une cinquième variante de réalisation de l'invention, le nœud racine 4 supprime l'entête IP interne du paquet multicast (entête dont la destination est l'adresse multicast du groupe) avant de l'envoyer avec l'entête de routage approprié vers le (approche de base) ou les (variante 1) récepteur ( s ) . Cette variante suppose que le récepteur a associé (avant sa demande de souscription) son adresse unicast indiquée dans l'entête de routage à l'adresse multicast du groupe auquel il a souscrit. L'adresse unicast de l'hôte peut être, par exemple une adresse virtuelle. Ainsi, lors de la réception d'un paquet avec entête de routage, le récepteur extraira son adresse unicast de l'entête de routage et recouvrera en interne l'adresse multicast associée.

Claims

REVENDICATIONS
1. Procédé de routage en mode non-stockage de paquets d'un flux échangés entre une source (2) et au moins un récepteur Hi (i =1, 2, 3,...) identifié par une adresse unicast, et ayant préalablement souscrit à au moins un groupe multicast MCj (j =1, 2, 3,...) dans un réseau de type LLN comportant un ensemble de nœuds Ni (i =1, 2, 3,...) de non-stockage et un nœud racine (4), capable de mémoriser des informations de routage, procédé caractérisé en ce qu' il comporte les étapes suivantes :
- envoyer par le récepteur Hi au nœud racine (4) une demande de souscription à un groupe multicast MCj (j=l/ 2, 3, ...) contenant l'adresse unicast du récepteur Hi et l'adresse multicast dudit groupe multicast,
associer (38) dans une table de routage multicast gérée par le nœud racine (4) l'adresse multicast MCj à l'adresse unicast du récepteur Hi ayant souscrit au groupe multicast MCj ainsi qu'à la liste des nœuds intermédiaires sur le chemin entre le nœud racine (4) et ledit récepteur Hi;
- transmettre un paquet d'un flux multicast de la source (2) vers le nœud racine (4);
et à la réception du paquet du flux multicast, le nœud racine (4) génère une copie dudit paquet, ajoute à la copie générée un entête de routage comportant une liste de nœuds intermédiaires sur le chemin entre le nœud racine (4) et ledit récepteur Hi, et transmet ladite copie du paquet multicast au récepteur Hi via ladite liste de nœuds intermédiaires .
2. Procédé selon la revendication 1 dans lequel, le récepteur Hi envoie au nœud racine (4) la demande de souscription via un message DAO (Destination Avertissement Object) du protocole RPL (Routing Protocol for Low power and Lossy Networks) ou via un message MLD (Multicast Listener Discovery) report
3. Procédé selon la revendication 1 dans lequel, le récepteur Hi envoie ladite demande de souscription avec une portée locale multicast (link-local multicast) ou en unicast directement au nœud racine (4), et à la réception de la demande, le nœud racine (4) enregistre le récepteur Hi dans la table de routage multicast .
4. Procédé selon la revendication 1 dans lequel, ladite table de routage multicast comporte en outre une liste des nœuds intermédiaires destinés à transférer les paquets provenant du nœud racine (4) au récepteur Hi .
5. Procédé selon la revendication 1 dans lequel, l'adresse unicast du récepteur Hi est soit son adresse unicast réelle, soit une adresse virtuelle interne au récepteur Hi .
6. Procédé selon la revendication 4 dans lequel, lorsqu'un nœud intermédiaire Ni reçoit un paquet multicast, si l'adresse de destination du tunnel appartient audit nœud Ni, ce dernier supprime l'entête IP externe du paquet reçu et transmet le paquet multicast tel quel sur son interface de sortie au prochain nœud intermédiaire en direction du nœud racine (4) .
7. Procédé selon la revendication 4 dans lequel, lorsqu'un nœud intermédiaire Ni reçoit un paquet multicast, si l'adresse de destination du paquet n'appartient pas audit nœud Ni, ce dernier transmet le paquet tel quel sur son interface de sortie au prochain nœud intermédiaire en direction du nœud racine (4) .
8. Procédé selon la revendication 1 dans lequel, lorsque le nœud racine (4) reçoit un paquet, il vérifie si le paquet a une adresse de destination multicast ou une adresse de destination qui lui appartient, et,
- dans le cas où le paquet a une adresse multicast, le nœud racine (4) vérifie si cette adresse est enregistrée dans sa table de routage,
- dans le cas où l'adresse multicast existe dans la table de routage, le nœud racine (4) construit un ensemble d'entêtés de routage, et transmet le paquet multicast vers les nœuds destinataires en utilisant lesdits entêtes de routages.
9. Procédé selon la revendication 1 dans lequel, si l'adresse de destination du paquet reçu par le nœud racine (4) est une adresse unicast, le nœud racine (4) vérifie si cette adresse lui appartient et,
si oui, le nœud racine (4) décapsule le paquet reçu, et, si le paquet a une adresse multicast, le nœud racine (4) vérifie si cette adresse est enregistrée dans la table de routage,
• si l'adresse multicast existe dans la table de routage, le nœud racine (4) construit un ensemble d'entêtés de routage, et transmet le paquet multicast vers les nœuds destinataires en utilisant lesdits entêtes de routages ,
• si non, le paquet reçu est alors routé selon le mode unicast du protocole RPL.
10. Programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour réaliser, lorsqu' il est exécuté par un ordinateur, les étapes du procédé selon l'une des revendications 1 à
EP12733709.5A 2011-07-11 2012-07-09 Procede de routage d'un flux multicast en mode non-stockage Withdrawn EP2732589A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1156273A FR2978003B1 (fr) 2011-07-11 2011-07-11 Procede de routage d'un flux en mode non-stockage
PCT/EP2012/063420 WO2013007699A1 (fr) 2011-07-11 2012-07-09 Procede de routage d'un flux multicast en mode non-stockage

Publications (1)

Publication Number Publication Date
EP2732589A1 true EP2732589A1 (fr) 2014-05-21

Family

ID=46506391

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12733709.5A Withdrawn EP2732589A1 (fr) 2011-07-11 2012-07-09 Procede de routage d'un flux multicast en mode non-stockage

Country Status (4)

Country Link
US (1) US20140126575A1 (fr)
EP (1) EP2732589A1 (fr)
FR (1) FR2978003B1 (fr)
WO (1) WO2013007699A1 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015019233A (ja) * 2013-07-10 2015-01-29 株式会社東芝 通信ノード装置、通信システム、通信制御方法およびプログラム
US9942053B2 (en) 2013-09-17 2018-04-10 Cisco Technology, Inc. Bit indexed explicit replication using internet protocol version 6
US10461946B2 (en) 2013-09-17 2019-10-29 Cisco Technology, Inc. Overlay signaling for bit indexed explicit replication
US11451474B2 (en) 2013-09-17 2022-09-20 Cisco Technology, Inc. Equal cost multi-path with bit indexed explicit replication
US9806897B2 (en) 2013-09-17 2017-10-31 Cisco Technology, Inc. Bit indexed explicit replication forwarding optimization
US10218524B2 (en) 2013-09-17 2019-02-26 Cisco Technology, Inc. Bit indexed explicit replication for layer 2 networking
US10003494B2 (en) 2013-09-17 2018-06-19 Cisco Technology, Inc. Per-prefix LFA FRR with bit indexed explicit replication
US9510347B2 (en) 2014-05-08 2016-11-29 Cisco Technology, Inc. Timeslot distribution in a distributed routing protocol for deterministic wireless networks
CN104023317B (zh) * 2014-06-17 2019-02-01 中国科学院计算技术研究所 一种低功耗多播路由网络及其多播路由方法
US9763061B2 (en) 2015-01-22 2017-09-12 Gainspan Corporation Multicast packet delivery in a wireless network operating in storing mode
US9716984B2 (en) 2015-01-22 2017-07-25 Gainspan Corporation Multicast packet delivery in a wireless network operating in non-storing mode
US9906378B2 (en) 2015-01-27 2018-02-27 Cisco Technology, Inc. Capability aware routing
US10341221B2 (en) 2015-02-26 2019-07-02 Cisco Technology, Inc. Traffic engineering for bit indexed explicit replication
US20170195218A1 (en) * 2015-12-30 2017-07-06 Qualcomm Incorporated Routing in a hybrid network
US10516549B2 (en) * 2016-08-02 2019-12-24 Cisco Technology, Inc. Multicast service with is-is spine-leaf extension in a fabric network
US10630743B2 (en) 2016-09-23 2020-04-21 Cisco Technology, Inc. Unicast media replication fabric using bit indexed explicit replication
US10637675B2 (en) 2016-11-09 2020-04-28 Cisco Technology, Inc. Area-specific broadcasting using bit indexed explicit replication
US10447496B2 (en) * 2017-03-30 2019-10-15 Cisco Technology, Inc. Multicast traffic steering using tree identity in bit indexed explicit replication (BIER)
US10164794B2 (en) 2017-04-28 2018-12-25 Cisco Technology, Inc. Bridging of non-capable subnetworks in bit indexed explicit replication
US10652036B2 (en) 2017-11-28 2020-05-12 Itron, Inc. Multi-network operation with member node for multicast groups
US10958460B2 (en) * 2018-09-26 2021-03-23 Itron, Inc. Connecting multiple networks for multicast groups
US11032094B2 (en) 2019-08-15 2021-06-08 Itron, Inc. Optimized multicast group forwarding

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2856050B2 (ja) * 1993-11-30 1999-02-10 日本電気株式会社 ルーティング制御方法
US6684331B1 (en) * 1999-12-22 2004-01-27 Cisco Technology, Inc. Method and apparatus for distributing and updating group controllers over a wide area network using a tree structure
TWI265697B (en) * 2002-06-06 2006-11-01 Ibm Digital contents distribution system, digital contents distribution method, computer readable recording medium storing the program therein, and server and client therefor
US7646739B2 (en) * 2005-04-05 2010-01-12 Cisco Technology, Inc. Multicast routing over unidirectional links
US20090040957A1 (en) * 2007-08-10 2009-02-12 Thomas Anschutz Prepositioning Data For Wireless Applications
US20120155463A1 (en) * 2010-12-17 2012-06-21 Cisco Technology Inc. Increased Communication Opportunities with Low-Contact Nodes in a Computer Network
US8756449B2 (en) * 2011-03-08 2014-06-17 Cisco Technology, Inc. Phase-based operation of devices on a polyphase electric distribution system
US8824471B2 (en) * 2011-06-01 2014-09-02 Cisco Technology, Inc. Maintained message delivery during routing domain migration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2013007699A1 *

Also Published As

Publication number Publication date
FR2978003A1 (fr) 2013-01-18
US20140126575A1 (en) 2014-05-08
FR2978003B1 (fr) 2014-07-04
WO2013007699A1 (fr) 2013-01-17

Similar Documents

Publication Publication Date Title
WO2013007699A1 (fr) Procede de routage d'un flux multicast en mode non-stockage
EP3602979B1 (fr) Système et procédé visant à faciliter un réacheminement de contenu en utilisant une réplication explicite d'indice binaire (bier) dans un environnement de réseautage centré sur des informations (icn)
US11303470B2 (en) Bridging of non-capable subnetworks in bit indexed explicit replication
EP3583756B1 (fr) Système et procédé permettant de faciliter la distribution d'un contenu à des destinataires multiples dans un environnement de réseau
US7675912B1 (en) Method and apparatus for border gateway protocol (BGP) auto discovery
US7529199B1 (en) System and method for resolving conflicts in proxy routing information associated with multicast distribution trees
US9660825B2 (en) System and method for multi-source multicasting in content-centric networks
EP2232390B1 (fr) Procédé d'acheminement de messages sur un réseau et système de mise en oeuvre du procédé
US9143431B2 (en) Hiding a service node in a network from a network routing topology
EP2823609A1 (fr) Procede de préselection d'un routeur dans un reseau rpl
CN106688209B (zh) 用于传输广播数据的方法和系统
EP2436155B1 (fr) Procédé de gestion de chemins entre un noeud source et un noeud destinataire au niveau de la couche de liaison, noeud source et table correspondants
US20210152617A1 (en) Multicast support
EP2823608B1 (fr) Procédé, dispositif et programme d'ordinateur pour sélectionner un noeud routeur dans un réseau lln
FR3005546A1 (fr) Procede et dispositif de selection d'interface de communication
WO2004084495A1 (fr) Procede pour l’interconnexion de reseaux prives virtuels en mode non connecte
EP2835954B1 (fr) Procédé de traitement, dans un réseau ad hoc de radiocommunication, stations de radiocommunication et programmes d'ordinateur correspondants
WO2005025146A1 (fr) Transmission de trafic multipoint au sein d’un reseau de communication

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140113

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20150227

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/18 20060101ALI20150213BHEP

Ipc: H04L 12/721 20130101AFI20150213BHEP

Ipc: H04L 12/761 20130101ALI20150213BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150710