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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=46506391

Family Applications (1)

Country Status (4)

Families Citing this family (22)

Family Cites Families (8)

• 2011
  • 2011-07-11 FR FR1156273A patent/FR2978003B1/fr not_active Expired - Fee Related
• 2012
  • 2012-07-09 WO PCT/EP2012/063420 patent/WO2013007699A1/fr active Application Filing
  • 2012-07-09 EP EP12733709.5A patent/EP2732589A1/de not_active Withdrawn
  • 2012-07-09 US US14/129,572 patent/US20140126575A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events