EP2823609A1 - Procede de préselection d'un routeur dans un reseau rpl - Google Patents

Procede de préselection d'un routeur dans un reseau rpl

Info

Publication number
EP2823609A1
EP2823609A1 EP13707177.5A EP13707177A EP2823609A1 EP 2823609 A1 EP2823609 A1 EP 2823609A1 EP 13707177 A EP13707177 A EP 13707177A EP 2823609 A1 EP2823609 A1 EP 2823609A1
Authority
EP
European Patent Office
Prior art keywords
node
router
mer
host
status
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
EP13707177.5A
Other languages
German (de)
English (en)
Inventor
Christophe Janneteau
Mounir Kellil
Nicolas RIOU
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 EP2823609A1 publication Critical patent/EP2823609A1/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
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • 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/02—Topology update or discovery
    • 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
    • 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/18—Loop-free operations
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the invention is in the context of multicast multicasts in computer networks with high constraints in terms of available resources (batteries, memories, computing capacities, links available, etc.) and more specifically concerns a method for preselecting a router in a LLN (Lower Power and Lossy Network) network among a plurality of nodes that can act as data packet routers exchanged between a plurality of host nodes, said LLN network having a root node responsible for managing a first data table; an association containing a list of router nodes authorized to transfer multicast packets from the LLN network to a given host node or from a given host node to the LLN network, each router node having a status from one of the following statuses:
  • LLN Lower Power and Lossy Network
  • the invention also relates to a device for implementing the method according to the invention and a program stored on a recording medium and comprising instructions for implementing the steps of the method when it is exercised on a computer.
  • LLN Lower Power and Lossy Network
  • Duplication of data packets exchanged during multicast communications in LLN (Lower Power and Lossy Network) type networks has the effect of wasting resources such as bandwidth, computing capacity, space memory and the energy reserve which are very limited in this type of networks. This waste can cause a major network malfunction, premature aging or even complete blockage.
  • This problem occurs when a multicast packet is transmitted / broadcast in a level 2 frame corresponding to the logical link control sublayer of the Open System Interconnection (OSI) model; for example broadcast-type Media Access Control (MAC), which is often the case in computer networks including LLNs networks.
  • OSI Open System Interconnection
  • MAC Media Access Control
  • the duplicate packets may come from a node that broadcasts multicast data packets without respecting the transfer logic of a RPL node. that is, without transferring the multicast packet in a unicast (level 2) frame to one or more neighboring node (s) determined.
  • RPL Routing Protocol for Low Power and Lossy Networks
  • the node in question is in radio range of a network RPL but is not part of the network itself. This situation corresponds to the case where the node has no information on the nodes of the RPL network, or does not use the functionalities of this type of network.
  • Such a node may be, for example, a node without battery recovering the energy necessary for the transmission of a message, for example a command, through an external physical action undergone by the node such as a ZigBee type node GreenPower (wireless switch and without battery).
  • a ZigBee type node GreenPower wireless switch and without battery.
  • a multicast source In the case of a multicast source, it can send a multicast IP packet on a Broadcast level 2 frame that will be received by all RPL routers in direct radio range of this source. If it is a multi-hop multicast packet, close-to-near transmission will be performed until the packet reaches its final destination. However, if the IP multicast packet sent by the source is received by several RPL routers in direct radio range of said source, each of these routers will transmit in the network a copy of said packet. This situation is then at the origin of duplication of said packet in the RPL network since this same packet is injected simultaneously and independently into the RPL routing tree by several nodes.
  • a node on the path of the packets which may be either an intermediate router or the final destination of the packets, may receive several copies of the same multicast packets, which can cause a number of problems such as for example over-consumption of the band passing through the network or its premature aging.
  • a packet destination node is similar to that of the source in terms of effects on the network, except that the purpose of the destination node is to receive multicast packets and not to transmit them.
  • the destination node transmits in broadcast (level 2) its membership request to an IP multicast group in an RPL network, for example an MLD report type request ([R. Vida et al., Multicast Listener Discovery "Version 2 (MLDv2) for IPv6", RFC 3610, June 2004]).
  • MLDv2 Multicast Listener Discovery "Version 2 (MLDv2) for IPv6", RFC 3610, June 2004]
  • any RPL router having received said request will initiate the construction of a routing path consisting of a branch of a multicast tree from the RPL network to the destination node.
  • the receiving node may receive as many copies of the same multicast IP packet as there are RPL routers within its direct reach. Again this duplication of traffic in the RPL network can cause many problems such as over-consumption of network bandwidth or premature aging.
  • multiple nodes may simultaneously apply to act as a multicast router for a given host node. This results in a large number of requests for applications sent to the root node for this purpose. This also results in over-consumption of the bandwidth and a large processing load of the requests by the root node.
  • the object of the invention is to overcome the disadvantages of the prior art described above by means of a so-called "local" election method concerning the RPL router nodes in direct radio range of a source or a a receiver allowing these RPL router nodes to decide which will transmit to the root node a MER_Request message to serve as a single multicast router for a host node, source or multicast data receiver, and possibly for a given multicast group.
  • This method aims to reduce the number of RPL nodes that will be candidates for the election of a multicast router for a given host node in the RPL network.
  • Another objective of the invention is to define a local procedure, called the application selection procedure, which makes it possible to automatically choose the candidate nodes to send a MER_Request request to the root node, these candidates possibly being nodes that are not in direct range of a host (source or receiver).
  • This object is achieved by means of a method of preselecting a router in a LLN (Lower Power and Lossy Network) network among a plurality of nodes that can act as routers of data packets exchanged between a network.
  • LLN Lower Power and Lossy Network
  • plurality of host nodes said LLN network having a root node responsible for managing a first association table containing a list of router nodes authorized to transfer multicast packets from the LLN to a given host node or from a given host node to the host node.
  • LLN network each router node having a status of one of the following statuses:
  • CANDI DAT_MER Multicast Edge Router
  • NON_MER indicating that said router node is configured not to be a multicast router for said host node.
  • the process according to the invention comprises the following steps:
  • said router node upon receipt by a given router node of a multicast data packet or subscription request to a multicast group (eg, Multicast Listener Discovery Report (MLD) message) from a node given host, said router node transmits to the other router nodes of the LLN network its direct radio range an announcement message including its status vis-à-vis the host node and the address of said host node.
  • MLD Multicast Listener Discovery Report
  • each of said other router nodes compares its current status with respect to said host node to the status indicated in the announcement message, and configures its status according to said compa reason so that a single node among the LLN network nodes in direct radio range of said router node transmits to the root node a configuration MER_Request request as a multicast router for the data from or to said given host node, and
  • the root node upon reception of said MER_Request, grants the MER status for said host node to the first router node that has transmitted a MER_Request.
  • each router node stores routing information in a second association table in the following fields:
  • a "host address” field to contain the address of the host node
  • An optional "host type” field intended to contain the type of said host node from one of the following two types, source or receiver;
  • An optional "multicast IP address” field to contain the address of a multicast group to which the host node belongs;
  • a "status” field intended to contain the status of the router node vis-à-vis said host node, and can take one of four values: CANDIDATJV1ER, PENDING, MER and NON_MER;
  • a "Lifetime_table_entry" field intended to contain a lifetime of the input associated with the host node in said second association table, i.e. a lifetime of the status of the router node vis-à-vis said host node;
  • any optional field of the MER_Request / MER_Reply messages and association tables will be designated by [X], where X represents the name of the optional field.
  • These optional fields are: host node type and multicast IP address.
  • a router node when a router node receives said announcement message, it first checks in said second association table if one of its entries corresponds to the address fields of the host, [host type], and [multicast IP address] of the received announcement message, and if the check returns no input, said router node will ignore the received advertisement message.
  • the router node compares its address to that of the router node sending the announcement message, and, keeps its status CANDIDAT_MER if its address is lower than that of the sending router node of the announcement message, or sets the status associated with the entry found to NON_MER if its address is greater than the address of the sending router node of the message of ad.
  • the advertisement message contains a CANDI status DAT_MER and said second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type] , and [multicast IP address] contained in the received announcement message, and if such an entry has a PENDING status or a NON_MER status, or an MER status for said router node vis-à-vis the host node identified in the announcement message, the latter ignores the received announcement message.
  • said router node can respond to the router node that sent said announcement message by another advertisement message containing a MER status associated with the address fields of the host, [type of the host], and [multicast IP address] of said input.
  • announcement message contains a MER status and the second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type], and [address IP multicast] contained in the received announcement message, and,
  • said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message so as to synchronize the value of the field [lifetime_table_entry] at all the routers nodes having the entry found,
  • said router node replaces the value of the field lifetime_table_entry associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
  • said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
  • said router node may ignore the received message.
  • the announcement message contains a NON_MER status and the second association table of the router node that received the announcement message contains an entry corresponding to the host address fields, [host type], and [address IP multicast] contained in the received announcement message, and if such an entry indicates a MER status, said router node ignores the received message,
  • said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message,
  • said router node replaces the value of the field lifetime_table_entry associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER.
  • said router node replaces the value of the lifetime_table_entry field associated with the entry found by that indicated in the received message and changes the status of the entry to NON_MER. Alternatively, said router node may ignore the received message.
  • the router node that has received the request to subscribe to a multicast group (eg the MLD Report message) checks whether exists in said second association table a host node concerned by the message of MER_Reply response received, and, if so, sets its status to the relevant host node to NON_MER, and replaces the value of the lifetime_table_entry field with the one specified in the received MER_Reply message
  • the router node In the case where the router node receives a MER_Reply response message from the root node having an MER status, said router node checks whether there exists in the second association table a host node concerned by the received MER_Reply message, if it is the case, it puts its status vis-à-vis the relevant host node to MER, and, replaces the lifetime of its status vis-à-vis said host node by that indicated in the MER_Reply message received (ie. d replaces the value of the lifetime_table_entry field with the value specified in the received MER_Reply message), establishes a multicast branch in the network going to the host node, and broadcasts in multicast with local scope an advertisement message with the MER status.
  • a host node concerned by the received MER_Reply message if it is the case, it puts its status vis-à-vis the relevant host node to MER, and, replaces the lifetime of its status vis-à-vis said host node by that
  • the advertisement transmitted by the router node is implemented through a DIO type message of the RPL (DODAG Information Object) protocol.
  • RPL DODAG Information Object
  • said router node stores the multicast data packet received if its memory allows it.
  • the router node transfers the received packet to the multicast tree; and, if said status is NON_MER, the router node ignores the received multicast packet.
  • said router node also stores the multicast data packet received if the memory allows it.
  • said node router checks whether there exists in its association table a host node concerned by the received MER_Reply response message.
  • said router node sets its status to the relevant host node to NON_MER, replaces the value of the lifetime_table_entry field with the one specified in the received MER_Reply message, and removes from its memory any multicast data packet. associated with said previously stored entry.
  • the router node which has received the MER_Reply message configuring it with the MER status for said entry in its second association table can transmit into the network any multicast data packet associated with said previously stored entry as well as any packet of received future multicast data corresponding to said input.
  • LLN Lower Power and Lossy Network
  • LLN Lower Power and Lossy Network
  • ⁇ CANDIDAT_MER Multicast Edge Router
  • each router node transmits to the other nodes of the LLN network in direct radio range of said host node an announcement message comprising information having a value on the basis of which will be conducted the configuration of the router nodes as CANDI DAT_MER or N 0 N_C AN DID AT_M ER, said information being able to be contained in the data field of the announcement message (eg a given value) or else in a header of the announcement message (e.g. MAC address or the source IP address of the router node issuing the announcement).
  • each of said other router nodes compares the value of its own information (eg MAC address or IP address or other information used for the configuration of the states C AN DID AT_M ER / N 0 N_CAN DID AT_M ER of a router node) to that contained in the announcement message, and, if the value of the information contained in the announcement message is less than the value of the information of the router node having received said announcement message, then the latter goes into the state NON_CANDIDAT_MER, otherwise, the router node that received said announcement message remains in the state CANDIDAT_MER.
  • its own information eg MAC address or IP address or other information used for the configuration of the states C AN DID AT_M ER / N 0 N_CAN DID AT_M ER of a router node
  • this pre-selection is not necessarily conditioned on the reception by a router node of a request to subscribe to a multicast group (for example an MLD Report message) or a multicast message from a node. given host (receiver or source).
  • the pre-sectioned MER candidate ie in the CANDIDAT_MER state
  • the source address (eg MAC address or IP address) of the announcement messages (eg DIOs of the RPL protocol) exchanged between the RPL routers is used to allow each RPL router to decide whether it has the right to be a candidate router (ie in the CANDIDAT_MER state), and therefore to later contact the root node via MER_Request messages to determine if it will be configured by the latter as a single multicast router (ie with MER status) to a given host node.
  • each router node having a status NON_CANDIDAT_MER comprises a transfer table for managing the exchanges of multicast packets between a router node and a host node, said transfer table comprising the following fields :
  • the host address field to contain the host node address
  • MAC_x address intended to contain the MAC address of the node from which the multicast packet was received or the MLD Report message
  • the "MAC_y address” field intended to contain the MAC address of the CANDIDAT_MER (not applicable if the current RPL router is itself CANDI DAT_MER) ⁇
  • the Lifetime_table_entry field intended to contain a lifetime of the input associated with the host node in said transfer table;
  • any optional field of the transfer table will be designated by [X] where X represents the name of the optional field.
  • These optional fields are: host node type and multicast IP address.
  • each router node comprises an announcements table containing neighboring routers from which it has received an announcement message, so that each time a router node NON_CANDIDAT_MER receives an announcement message of a new router node that is not already listed in its advertisement table, said router NON_CANDIDAT_MER adds the MAC address of said new router node to its advertisement table, compares the MAC address of the new router node to the address MAC of the current router node CANDIDAT_MER indicated in its table of announcements, and if the IP address of the new router node is lower than that of the current node CANDIDAT_MER, said router node NON_CANDIDAT_MER considers that it is the new node router which is its new CANDIDAT_MER and update its table of announcements accordingly.
  • a router node when a router node receives a subscription request to a multicast group (for example a message of the MLD Report type) from a receiver-type host node, it consults its second table. association to check if it has already received the same subscription request and, ⁇ If it is, the request (eg the message MLD report) is ignored,
  • ⁇ stores the message received in the subscription request if it is in the CANDIDAT_MER state and if memory allows it, translates this message into a MER_Request message, then transmits said MER_Request message to the root node; on the other hand, if it is in the state NON_CANDIDAT_MER, it transfers said message to the node CANDIDAT_MER indicated in its table of announcements.
  • the first variant of the method according to the invention is implemented by a device in which each router node is adapted to transmit to the other router nodes of the LLN network in direct radio range of said host node an announcement message including its status vis-à-vis -vis a host node and the address of said given host node and each of said other router nodes is adapted to compare its status vis-à-vis said given host node to the status indicated in the announcement message, and to configure its status according to said comparison so that a single node among the LLN network nodes in direct radio range of said host node transmits to the root node a configuration MER_Request request as a multicast router for said given host node; said root node being adapted to grant the MER status for the given host node to the first router node that has sent it a MER_Request.
  • each router node is adapted to transmit to the other router nodes of the LLN network in its direct radio range an announcement message comprising information (e.g. the MAC address or the source IP address of the router node transmitting the advertisement or any other information) having a value on the basis of which the configuration of the router nodes will be conducted as CANDIDAT_MER or NON_CANDIDAT_MER, and each of the other nodes routers is adapted to compare the value of its own information (eg MAC address or IP address or any other information used for the configuration of the C AN DID AT_M ER / N 0 N_CAN DID AT_M ER states of a router node) to that contained in the announcement message, so that if the value of the information contained in the announcement message is less than the value of the information of the router node having received said announcement message, then it goes into the state NOT_CAN DIDAT_MER, otherwise, it remains in the state CANDI DAT
  • the method according to the invention is implemented by a computer program stored on a recording medium and having instructions for carrying out the steps of the first variant or the second variant when it is executed on a computer.
  • FIG. 1 illustrates the message exchange sequence between RPL nodes, data packet source host nodes, and the root node for the selection of a multicast router in an RPL network according to the invention
  • FIG. 2 illustrates the message exchange sequence between RPL nodes, host nodes receiving data packets, and the root node for selecting a multicast router in an RPL network according to the invention.
  • FIG. 3 schematically illustrates the preselection steps of a router node in a particular variant of the method according to the invention.
  • the root node 4 includes a first table, called association table, for storing associations between at least one of the host nodes respectively referenced 6 and 8 of a multicast group and one of the RPL nodes.
  • a host node that can be either the source or the recipient of the data packets exchanged across the network. In the rest of the description, identical references will designate elements fulfilling identical functions in the different figures.
  • a source host node of data packets will be designated by the source term 6, and a receiving host node of data packets by the term receiver 8.
  • the LLN network to which reference will be made later in this description comprises only two router nodes 2 and 3 in direct range of the host nodes 6 and 8.
  • the method according to the invention also applies in the where the network has more than two RPL nodes.
  • the configuration of an RPL node is performed by exchanging MER_Request / MER_Reply configuration messages between the root node 4 and each RPL node that has requested to serve as a multicast router vis-à-vis a given host node.
  • the elected RPL node is referred to as the Multicast Edge Router or Multicast Edge Router for a source or receiver.
  • the MER will be in charge of intercepting multicast packets from the source and transmitting them in the RPL multicast broadcast tree.
  • the MER will be in charge of intercepting the multicast membership requests of this receiver, such as for example a request of the type MLD report (for Multicast Listener Discovery described in
  • MLDv2 Multicast Listener Discovery Version 2
  • the exchange of MER_Request / MER_Reply messages is implemented through an extension of the exchange.
  • DAO / DAO_ACK of the RPL protocol.
  • the RPC Protocol's Destination Warning Object (DAO) message is traditionally used by RPL nodes to add or remove a branch (an IP path) from the RPL network.
  • the message DAO_ACK is sent from the root node 4 to the RPL node 8 in response to a DAO message.
  • DAO Destination Warning Object
  • each RPL node can have one of the following statuses: ⁇ CANDIDAT_MER (Multicast Edge Router), indicating that the router node is a candidate to act as a single multicast router for a given host node;
  • ⁇ CANDIDAT_MER Multicast Edge Router
  • ⁇ MER indicating that said router node is configured as a single multicast router for said host node
  • ⁇ Host Address The IP address of a multicast source or receiver
  • Host type optional field specifying the type of the host, or the type can be "source” or “receiver”;
  • ⁇ Multicast address optional field specifying the multicast group address associated with the source or receiver
  • Lifetime / lifetime the lifetime of the host-associated input
  • FIG. 1 illustrates the message exchanges between the root node 4 and two RPL nodes 2 and 3 for the election of an MER from these two nodes for the source 6.
  • step 20 the source 6 broadcasts a multicast data packet comprising, in addition to the payload data, a header indicating the address of the source @S and the multicast address mcast @ of the group to which the destination node of the packet of data.
  • each of the RPL nodes 2 and 3 Upon reception of the broadcast packet, each of the RPL nodes 2 and 3 determines that it has no entry in its said second association table corresponding to the received message and thus generates a new entry for said host node (indicating the host address and optionally the host type and multicast address), assign the CANDIDAT_MER status to this entry, assign non-zero values Lifetime_statut and Lifetime_table_entry fields respectively, and stores the received multicast packet if its available memory allows it. Each of the RPL nodes 2 and 3 also generates an announcement message including its status vis-à-vis the source 6 and the address of said host node (ie CANDI DAT_MER).
  • step 22 the RPL node 2 (respectively 3) transmits the generated advertisement message to the node RPL 3 (respectively 2).
  • step 26 the RPL node 2 verifies that the status of the RPL node 3 indicated in the announcement message is CANDIDAT_MER, compares its address to that of the RPL node 3, and keeps its CANDI DAT_MER status if its address is lower. to that of RPL node 3.
  • step 27 the RPL node 3 verifies that the status of the RPL node 2 indicated in the announcement message is CANDIDAT_MER, compares its address to that of the RPL node 2, and changes its status to NON_MER, and empty of its memory the stored multicast data packet (s), if its address is greater than that of the RPL node 2.
  • step 28 the Lifetime_statut field of said RPL 2 association table entry expires and the RPL node 2 sets a PENDING value to its status for said entry.
  • step 36 the elected node RPL 2 puts its status vis-à-vis the source at MER, and replaces the value of the field lifetime_table_entry with that indicated in FIG. received MER_Reply message, transfers the multicast data packet (s) received from the source 6 to the multicast tree, and then empties its memory.
  • step 40 the RPL node 3 updates the value of the field [lifetime_table_entry].
  • the RPL node 2 Upon receiving a new multicast data packet from the source 6 (step 42) the RPL node 2 automatically transfers (step 44) the data packet to the multicast tree, while the RPL node 3 ignores this new packet (step 46).
  • FIG. 2 illustrates the message exchanges between the root node 4 and two RPL nodes 2 and 3 for the election of a MER from these two nodes for the receiver 8.
  • the receiver 8 broadcasts an adhesion message to a multicast group (eg a message of the MLD Report type) comprising the address of the receiver 8 and the IP address mcast @ of the multicast group to which belongs the recipient 8.
  • a multicast group eg a message of the MLD Report type
  • the RPL node 2 Upon receipt of the multicast group membership message (eg, an MLD message), the RPL node 2 (respectively RPL 3) determines (step 52) (respectively 54) that it has no entry in the multicast group. its so-called second association table corresponding to the received message and thus generates a new entry for said host node (by indicating the address of the host and optionally the type of the host (receiver) and the multicast address), assigns the CANDIDAT_MER status to this entry, assigns non-zero values to the Lifetime_statut and Lifetime_table_entry fields respectively, and stores the received membership message if available memory permits.
  • the multicast group membership message eg, an MLD message
  • Each of the RPL nodes 2 and 3 also generates an announcement message including its status vis-à-vis the addressee 8 and the address of said host node 8 (ie CANDI DAT_MER).
  • the RPL node 2 (respectively RPL 3) transmits the generated advertisement message to the node RPL 3 (respectively 2).
  • step 60 the RPL node 2 (respectively RPL 3) checks the status of the RPL node 3 (respectively RPL 2) indicated in the announcement message, compares its address to that of the RPL node 3 (respectively RPL 2) and, keep its status CANDI DAT_MER if its address is lower than that of the node RPL 3 (respectively RPL 2) and if the status of the node RPL 3 is CANDIDAT_MER.
  • the @ R1 address of the RPL node 2 is less than that of the RPL node 3. In this case, the latter sets its status to NON_MER, whereas the RPL node 2 retains its CANDIDAT_MER status. .
  • step 64 the Lifetime_statut field of said RPL 2 association table entry expires and the RPL node 2 sets a PENDING value to its status for said entry.
  • step 66 the RPL node 2 transmits to the root node 4 a MER_Request request including the address of the recipient 8, and optionally the type of this recipient and the address of the multicast group to which this recipient belongs.
  • the root node checks whether the node RPL 2 is the first node having transmitted a request MER_Request, and if it is the case, grants the status MER to this node and transmits it (step 70) a response MER_Reply having said MER status, the recipient address 8, and optionally the type of this recipient 8 and the address of the multicast group to which this recipient belongs, and a non-zero value for the Lifetime_table_entry field of the RPL node 2 vis-à-vis -vis the recipient 8.
  • step 72 the elected RPL node 2 sets its MER status to replace the value of the lifetime_table_entry field by the one specified in the received MER_Reply message, and creates a branch of the multicast tree, and then empties its memory.
  • the RPL node 2 broadcasts, in multicast with local scope, an advertisement message including the MER status, the address of the recipient 8, and optionally the type of the recipient 8 and the multicast IP address of the group. to which this recipient 8 belongs, as well as the lifetime of the entry (lifetime_table_entry) so that the RPL 3 node can update the value of the field lifetime_table_entry based on the one indicated in the announcement message sent by the RPL node 2.
  • the RPL node 3 updates the value of the lifetime_table_entry field.
  • FIG. 3 illustrates the steps of a second variant of the invention making it possible to preselect a subset of router nodes among a set of nodes having a status among one of the following statuses, CANDIDAT_MER or NON_CANDIDAT_MER.
  • any RPL node (CANDIDAT_MER or NON_CANDIDAT_MER) stores in its memory the MAC address of the node from which it has received a new multicast packet or a new MLD Report.
  • any router NON_CANDIDAT_MER stores in its memory the MAC address of its router CANDIDAT_MER.
  • each router RPL NON_CANDIDAT_MER is supposed to manage a specific table, called transfer table for transferring the multicast packets from the MER to the receiver and to filter and transfer the multicast packets from the source to the MER.
  • the transfer table at an RPL router contains the following elements:
  • Host type optional field specifying the type of the host, or the type can be "source” or “receiver”,
  • ⁇ Multicast address optional field specifying the multicast group address associated with the source or receiver
  • ⁇ MAC_x address MAC address of the node from which the multicast packet or the MLD Report was received
  • each RPL node has an announcement table containing neighboring routers from which it has received an announcement message so that each time a NON_CANDIDAT_MER router receives an announcement message from a new router that does not is not in its announcement table, said router NON_CANDIDAT_MER adds the MAC address of said new router in said announcement table.
  • RPL node called A when initialized, it sets its status to "CANDI DAT_MER" (step 80) and remains in this state until its status is obsolete by certain conditions mentioned below.
  • the RPL node A When the RPL node A then receives (step 82) an announcement message such as, for example, a DIO message of the RPL protocol sent in multicast with a local scope by another router RPL called router B, said router A compares (step 84) its address. @A to RPL router B. @B address
  • router "A" goes into the NON_CANDIDAT_MER state (step 86) and adds the @B address in its announcements table indicating that the router B is CANDI DAT_MER from the point of view of the router A (step 87). Otherwise, router A remains in the CANDIDAT_MER state.
  • router A checks if @B already exists in its announcement table.
  • router A ignores the announcement sent by Router B (step 90).
  • router A adds the @B address in its ads table
  • each router in the RPL network can decide whether it has the right to be a candidate router (and therefore to contact the root node for this purpose via MER_Request messages).
  • the CANDI router DAT_MER is not always in direct radio range of the source.
  • the method according to the invention is applicable both in the context of low power / lossy networks (LLNs), for example wireless sensor networks, as well as in multicast IP telecommunications networks thanks to: "the definition of a mechanism for exchanging messages in the network
  • RPL between a set of routers and a root node; the exchange allowing the root node to designate a multicast router to serve a multicast source or a multicast receiver (ie accept / forward a multicast packet from a multicast source or send a multicast packet to a multicast receiver) ;
  • Feature definition specifying the conditions for selecting a multicast router (MER) at the root node
  • the present invention applies regardless of the routing mode of the multicast traffic used in the RPL network; that it is in particular the so-called mode “multicast storing” as defined by the specification RPL or the mode called “multicast non-storing” defined in [CJanneteau, M. Kellil, BD12830 "Method of routing a flow in non-storage mode ", French patent application filed on July 11, 2011 under No. 11 56273].

Landscapes

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

Abstract

L'invention concerne un procédé de présélection d'un routeur dans un réseau LLN (Lower power and Lossy Network) parmi une pluralité de nœuds dans lequel chaque nœud routeur transmet aux autres nœuds routeurs (2,3) du réseau LLN en portée radio directe dudit nœud routeur un message d'annonce, et, à la réception dudit message d'annonce, chacun desdits autres nœuds routeurs compare son statut courant vis-à-vis d'un nœuds routeurs (2,3) au statut indiqué dans le message d'annonce, et configure son statut en fonction de ladite comparaison de sorte qu'un seul nœud parmi les nœuds du réseau LLN en portée radio directe dudit nœud routeur transmette au nœud racine une requête MER_Request de configuration en tant que routeur multicast pour les données en provenance ou à destination dudit nœud hôte.

Description

PROCEDE DE PRÉSÉLECTION D'UN ROUTEUR DANS UN RESEAU RPL
DESCRIPTION
DOMAINE TECHNIQUE
L'invention se situe dans le contexte des multidiffusions (multicast) dans des réseaux informatiques à fortes contraintes en termes de ressources disponibles (batteries, mémoires, capacités de calcul, liens disponibles, etc.) et concerne plus spécifiquement un procédé de présélection d'un routeur dans un réseau LLN (Lower power and Lossy Network) parmi une pluralité de nœuds susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes, ledit réseau LLN comportant un nœud racine chargé de gérer une première table d'association contenant une liste de nœuds routeurs autorisés à transférer des paquets multicast du réseau LLN vers un nœud hôte donné ou d'un nœud hôte donnée vers le réseau LLN, chaque nœud routeur ayant un statut parmi l'un des statuts suiva nts :
■ CANDI DAT_M ER (M ulticast Edge Router), indiquant que le nœud routeur est candidat pour agir comme unique routeur multicast pour un nœud hôte donné;
■ PEN DI NG indiquant que le nœud routeur est en attente d'être sélectionné comme unique routeur multicast pour un nœud hôte donné,
■ M ER, indiquant que le nœud routeur est configuré en tant qu'unique routeur multicast pour un nœud hôte donné.
■ NON_M ER, indiquant que ledit nœud routeur est configuré pour ne pas être routeur multicast pour ledit nœud hôte.
L'invention concerne également un dispositif pour mettre en œuvre le procédé selon l'invention et un programme mémorisé sur un support d'enregistrement et comportant des instructions pour mettre en œuvre les étapes du procédé lorsqu'il est exercé sur un ordinateur. ÉTAT DE LA TECHNIQUE ANTÉRIEURE
La duplication des paquets de données échangés lors des communications de type multicast dans des réseaux de type LLN (Lower power and Lossy Network) a pour effet d'engendrer un gaspillage des ressources telles que la bande passante, la capacité de calcul, l'espace mémoire et la réserve d'énergie qui sont, très limitées dans ce type de réseaux. Ce gaspillage peut provoquer un dysfonctionnement important du réseau, son vieillissement prématuré, voire son blocage complet.
Ce problème survient lorsqu'un paquet multicast est transmis/diffusé dans une trame niveau 2 correspondant à la sous-couche du contrôle de liaison logique du modèle OSI (pour Open System Interconnection); par exemple niveau MAC (pour Media Access Control) de type broadcast, ce qui est souvent le cas dans les résea ux informatiques y compris dans les réseaux LLNs.
Dans le contexte d'un réseau de type RPL (Routing Protocol for Low power and Lossy Networks) par exemple, les paquets dupliqués peuvent provenir d'un nœud qui diffuse des paquets de données multicast sans respecter la logique de transfert d'un nœud RPL, c'est à dire, sans transférer le paquet multicast dans une trame unicast (de niveau 2) vers un, voire plusieurs nœud(s) voisin(s) déterminé(s). Ceci arrive si, par exemple, le nœud en question est à portée radio d'un réseau RPL mais ne fait pas partie à proprement parler de ce réseau. Cette situation correspond au cas où le nœud n'a pas d'information sur les nœuds du réseau RPL, ou n'utilise pas les fonctionnalités de ce type de réseau. Un tel nœud peut être, par exemple, un nœud sans batterie récupérant l'énergie nécessaire à la transmission d'un message, d'une commande par exemple, à travers une action physique extérieure subie par le nœud tel un nœud de type ZigBee GreenPower (interrupteur sans-fil et sans batterie).
Dans le cas d'une source multicast, celle-ci peut envoyer un paquet I P multicast sur une trame niveau 2 de type Broadcast qui sera reçu par tous les routeurs RPL en portée radio directe de cette source. S'il s'agit d'un paquet multicast de type multi-sauts, une transmission de proche-en-proche sera effectuée jusqu'à ce que le paquet atteigne sa destination finale. Cependant, si le paquet IP multicast émis par la source est reçu par plusieurs routeurs RPL en portée radio directe de ladite source, chacun de ces routeurs transmettra dans le réseau une copie dudit paquet. Cette situation est alors à l'origine de duplication dudit paquet dans le réseau RPL puisque ce même paquet est injecté simultanément et de manière indépendante dans l'arbre de routage RPL par plusieurs nœuds. Ainsi, un nœud sur le trajet des paquets, qui peut être soit un routeur intermédiaire soit la destination finale des paquets, risque de recevoir plusieurs copies des mêmes paquets multicast, ce qui peut engendrer nombre de problèmes tels que par exemple la surconsommation de la bande passante du réseau ou encore son vieillissement prématuré.
Le cas d'un nœud destinataire des paquets est similaire à celui de la source en termes d'effets sur le réseau, sauf que le but du nœud destinataire est de recevoir des paquets multicast et non pas d'en émettre. Pour ce faire, le nœud destinataire transmet en broadcast (de niveau 2) sa requête d'adhésion à un groupe multicast IP dans un réseau RPL, par exemple une requête de type MLD report ([R. Vida et al. « Multicast Listener Discovery » Version 2 (MLDv2) for IPv6 », RFC 3610, June 2004]). Dans ce cas, même si la requête du nœud destinataire a une portée locale au sens IP (linkjocal scope), elle peut être prise en compte par plusieurs routeurs RPL en portée radio directe du nœud destinataire. Dans ce cas, tout routeur RPL ayant reçu ladite requête, initiera la construction d'un chemin de routage consistant en une branche d'un arbre multicast allant du réseau RPL vers le nœud destinataire. Par conséquent le nœud destinataire risque de recevoir autant de copies d'un même paquet IP multicast qu'il y a de routeurs RPL à sa portée directe. Là encore cette duplication du trafic dans le réseau RPL peut engendrer nombre de problèmes tels que par exemple la surconsommation de la bande passante du réseau ou son vieillissement prématuré.
Par ailleurs, dans des réseaux denses, ou la source ou le récepteur multicast sont en portée radio directe de plusieurs routeurs RPL, plusieurs nœuds peuvent se porter candidats simultanément pour agir en tant que routeur multicast pour un nœud hôte donné. Ceci se traduit par un nombre important de requêtes de candidatures transmises au nœud racine à cet effet. Il en résulte également une surconsommation de la bande passante et une charge de traitement importante des requêtes par le nœud racine. Le but de l'invention est de pallier les inconvénients de l'art antérieur décrit ci-dessus à l'aide d'une méthode d'élection dite « locale » concernant les nœuds routeurs RPL en portée radio directe d'une source ou d'un récepteur permettant à ces nœuds routeurs RPL de décider qui transmettra au nœud racine un message MER_Request afin de servir d'unique routeur multicast pour un nœud hôte, source ou récepteur de données multicast, et éventuellement pour un groupe multicast donné. Cette méthode vise à réduire le nombre de nœuds RPL qui seront candidats à l'élection d'un routeur multicast pour un nœud hôte donné dans le réseau RPL.
Un autre objectif de l'invention est de définir une procédure locale, appelée procédure d'élection à la candidature, permettant de choisir automatiquement les nœuds candidats à envoyer une requête MER_Request vers le nœud racine, ces candidats pouvant être des nœuds qui ne sont pas en portée directe d'un hôte (source ou récepteur).
EXPOSÉ DE L'INVENTION Ce but est atteint au moyen d'un procédé de présélection d'un routeur dans un réseau LLN (Lower power and Lossy Network) parmi une pluralité de nœuds susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes, ledit réseau LLN comportant un nœud racine chargé de gérer une première table d'association contenant une liste de nœuds routeurs autorisés à transférer des paquets multicast du réseau LLN vers un nœud hôte donné ou d'un nœud hôte donnée vers le réseau LLN, chaque nœud routeur ayant un statut parmi l'un des statuts suivants:
CANDI DAT_MER (Multicast Edge Router), indiquant que le dit nœud routeur est candidat pour agir comme unique routeur multicast pour un nœud hôte donné;
PENDING indiquant que le nœud routeur est en attente d'être sélectionné par le nœud racine comme unique routeur multicast pour ledit nœud hôte,
MER, indiquant que ledit nœud routeur est configuré en tant qu'unique routeur multicast pour ledit nœud hôte ; NON_MER, indiquant que ledit nœud routeur est configuré pour ne pas être routeur multicast pour ledit nœud hôte.
Le procédé selon l'invention comporte les étapes suivantes:
- à la réception par un nœud routeur donné d'un paquet multicast de données ou d'une requête de souscription à un groupe multicast (p. ex. un message de type MLD (pour Multicast Listener Discovery) Report) provenant d'un nœud hôte donné, ledit nœud routeur transmet aux autres nœuds routeurs du réseau LLN sa portée radio directe un message d'annonce comportant son statut vis-à-vis du nœud hôte et l'adresse dudit nœud hôte.
- à la réception dudit message d'annonce, chacun desdits autres nœuds routeurs compare son statut courant vis-à-vis dudit nœud hôte au statut indiqué dans le message d'annonce, et configure son statut en fonction de ladite compa raison de sorte qu'un seul nœud parmi les nœuds du réseau LLN en portée radio directe dudit nœud routeur transmette au nœud racine une requête MER_Request de configuration en tant que routeur multicast pour les données en provenance ou à destination dudit nœud hôte donné, et,
- à la réception de ladite requête MER_Request, le nœud racine accorde le statut MER pour ledit nœud hôte au premier nœud routeur ayant transmis une requête MER_Request.
Selon une autre caractéristique du procédé de l'invention, chaque nœud routeur mémorise dans une deuxième table d'association des informations de routage dans les champs suivants:
■ Un champ « adresse de l'hôte » destiné à contenir l'adresse du nœud hôte ;
" Un champ optionnel « type de l'hôte » destiné à contenir le type dudit nœud hôte parmi l'un des deux types suivants, source ou récepteur ;
■ Un champ optionnel « adresse IP multicast » destiné à contenir l'adresse d'un groupe multicast auquel appartient le nœud hôte; ■ Un champ « statut » destiné à contenir le statut du nœud routeur vis-à-vis dudit nœud hôte, et pouvant prendre l'une des quatre valeurs suivantes : CANDIDATJV1ER, PENDING, MER et NON_MER ;
■ Un champ « Lifetime_table_entry » destiné à contenir une durée de vie de l'entrée associée au nœud hôte dans ladite deuxième table d'association c.à.d. une durée de vie du statut du nœud routeur vis-à-vis dudit nœud hôte;
■ Un champ « Lifetime_statut » destiné à contenir un temps d'attente d'un routeur en mode CANDIDAT_MER avant de passer en mode PENDING et envoyer un message MER_Request au nœud racine.
Dans la suite de la description, on désignera tout champ optionnel des messages MER_Request/MER_Reply et des tables des associations par [X], où X représente le nom du champ optionnel. Ces champs optionnels sont: le type du nœud hôte et l'adresse IP multicast.
Selon une autre caractéristique de l'invention, lorsqu'un nœud routeur reçoit ledit message d'annonce, il vérifie tout d'abord dans ladite deuxième table d'association si l'une de ses entrées correspond aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] du message d'annonce reçu, et si la vérification ne retourne aucune entrée, ledit nœud routeur ignorera le message d'annonce reçu.
Si une entrée correspondant au critère de vérification précédemment mentionné a été trouvée, alors la suite des opérations au niveau dudit nœud routeur se déroulera en fonction de la valeur du statut de l'entrée trouvée (CANDIDAT_MER, PENDING, MER, NON_MER) et de la valeur du statut indiqué dans ledit message d'annonce.
Ainsi, si le message d'annonce contient un statut CANDIDAT_MER et si l'entrée trouvée dans ladite deuxième table d'association a un statut CANDIDAT_MER, le nœud routeur compare son adresse à celle du nœud routeur émetteur du message d'annonce, et, garde son statut CANDIDAT_MER si son adresse est inférieure à celle du nœud routeur émetteur du message d'annonce, ou met le statut associé à l'entrée trouvée à NON_MER si son adresse est supérieure à l'adresse du nœud routeur émetteur du message d'annonce. En outre, si le message d'annonce contient un statut CANDI DAT_MER et ladite deuxième table d'association du nœud routeur ayant reçu le message d'annonce contient une entrée correspondant aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] contenus dans le message d'annonce reçu, et, si une telle entrée comporte un statut PENDING ou un statut NON_MER, ou un statut MER pour ledit nœud routeur vis-à-vis du nœud hôte identifié dans le message d'annonce, ce dernier ignore le message d'annonce reçu.
Notons que, optionnellement, si ladite entrée comporte un statut MER ledit nœud routeur peut répondre au nœud routeur ayant envoyé ledit message d'annonce par un autre message d'annonce contenant un statut MER associé aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] de ladite entrée.
Si le message d'annonce contient un statut MER et la deuxième table d'association du nœud routeur ayant reçu le message d'annonce contient une entrée correspondant aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] contenus dans le message d'annonce reçu, et,
- si une telle entrée indique un statut NON_MER, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu de manière à synchroniser la valeur du champ [lifetime_table_entry] au niveau de tous les nœuds routeurs disposant de l'entrée trouvée,
- si une telle entrée indique un statut CANDIDAT_MER, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NON_MER.
- si une telle entrée indique un statut PENDING, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NON_MER.
Alternativement ledit nœud routeur peut ignorer le message reçu.
Si le message d'annonce contient un statut NON_MER et la deuxième table d'association du nœud routeur ayant reçu le message d'annonce contient une entrée correspondant aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] contenus dans le message d'annonce reçu, et, si une telle entrée indique un statut MER, ledit nœud routeur ignore le message reçu,
- si une telle entrée indique un statut NON_MER, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu,
- si une telle entrée indique un statut CANDIDAT_MER, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NON_MER.
- si une telle entrée indique un statut PENDING, ledit nœud routeur remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NON_MER. Alternativement ledit nœud routeur peut ignorer le message reçu.
Selon une autre caractéristique du procédé de l'invention, lorsqu'un nœud routeur reçoit une requête de souscription à un groupe multicast (p. ex. un message de type MLD Report) d'un nœud hôte de type récepteur, ledit nœud routeur consulte ladite deuxième table d'association pour vérifier s'il a déjà reçu une même requête de souscription (p. ex. un même message MLD Report); et, si c'est le cas, le message de requête de souscription (p. ex. le message MLD report) est ignoré par ledit nœud routeur, sinon, le nœud routeur génère une nouvelle entrée dans sa deuxième table d'association contenant les champs adresse IP de l'hôte, [type de l'hôte =récepteur], [adresse IP multicast] déduits de la requête de souscription (p. ex. du message MLD Report) reçue, met son statut correspondant à l'entrée ajoutée à CANDIDAT_MER, associe ce statut à un champ lifetime_statut et à un champ lifetime_table_entry contenant chacun une valeur non nulle, puis, diffuse, en multicast avec portée locale, un message d'annonce comportant le statut CANDIDAT_MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = récepteur], [adresse IP multicast].
Et, à la réception d'un message de réponse MER_Reply transmis par le nœud racine et comportant un statut NON_MER, le nœud routeur ayant reçu la requête de souscription à un groupe multicast (p. ex. le message MLD Report) vérifie s'il existe dans ladite deuxième table d'association un nœud hôte concerné par le message de réponse MER_Reply reçu, et, si c'est le cas, met son statut vis-à-vis du nœud hôte concerné à NON_MER, et remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu, notons qu'optionnellement le nœud routeur ayant reçu le message MER_Reply transmis par le nœud racine et comportant un statut NON_MER peut aussi diffuser, en multicast avec portée locale, un message d'annonce comportant le statut NON_MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = récepteur], [adresse IP multicast] de manière à permettre aux nœuds routeurs en portée radio directe et ayant une entrée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =récepteur] et [adresse IP multicast] marquée avec le statut NON_MER, CANDIDAT_MER ou PENDING de mettre à jour la valeur du champ lifetime_table_entry de cette entrée sur la base de celle qui est indiquée dans le message d'annonce et de mettre le statut de cette entrée à NON_MER.
Dans le cas où le nœud routeur reçoit un message de réponse MER_Reply du nœud racine comportant un statut MER, ledit nœud routeur vérifie s'il existe dans la deuxième table d'association un nœud hôte concerné par le message MER_Reply reçu, si c'est le cas, il met son statut vis-à-vis du nœud hôte concerné à MER, et, remplace la durée de vie de son statut vis-à-vis dudit nœud hôte par celle indiquée dans le message MER_Reply reçu (c.à.d. remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu), établit une branche multicast dans le réseau allant vers ledit nœud hôte, et, diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = récepteur], [adresse IP multicast] de manière à permettre aux nœuds routeurs en portée radio directe et ayant une entrée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =récepteur] et [adresse IP multicast] marquée avec le statut NON_MER, CANDIDAT_MER ou PENDING de mettre à jour la valeur du champ lifetime_table_entry de cette entrée sur la base de celle qui est indiquée dans le message d'annonce et de mettre le statut de cette entrée à NON_MER. Dans un exemple de réalisation, l'annonce transmise par le nœud routeur est implémentée à travers un message de type DIO du protocole RPL (DODAG Information Object).
Dans le cas où un nœud routeur reçoit un paquet de données multicast émis par un nœud routeur de type source, il consulte ladite deuxième table d'association pour vérifier si l'une de ses entrées correspond aux champs adresse de l'hôte, [type de l'hôte=source], et [adresse IP multicast] déduits du paquet multicast reçu, et, si c'est le cas, le nœud routeur vérifie le statut associé à l'entrée trouvée. Si ce statut est CANDIDAT_MER le nœud routeur ayant reçu le paquet de données multicast diffuse en multicast avec portée locale un message d'annonce comprenant le statut CANDIDAT_MER ainsi que les champs [adresse IP de l'hôte], [type de l'hôte = source], [adresse IP multicast].
Si ledit statut est PENDING, ledit nœud routeur mémorise le paquet de données multicast reçu si sa mémoire le lui permet.
Si le statut associé à l'entrée trouvée est MER, le nœud routeur transfère le paquet reçu dans l'arbre multicast; et, si ledit statut est NON_MER, le nœud routeur ignore le paquet multicast reçu.
Dans le cas où aucune entrée de la deuxième table d'association ne correspond aux champs adresse de l'hôte, [type de l'hôte=source], et [adresse IP multicast] déduits du paquet multicast reçu, le nœud routeur génère une nouvelle entrée dans sa deuxième table d'association contenant lesdits champs adresse IP de l'hôte, [type de l'hôte =source], [adresse IP multicast], met son statut correspondant à l'entrée ajoutée à CANDIDAT_MER, associe ce statut à un champ [lifetime_statut] et à un champ lifetime_table_entry contenant chacun une valeur non nulle, puis, diffuse, en multicast avec portée locale, un message d'annonce comportant le statut CANDIDAT_MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = source], [adresse IP multicast].
Notons que ledit nœud routeur mémorise aussi le paquet de données multicast reçu si sa mémoire le lui permet.
Et, à la réception par le nœud routeur d'un message de réponse MER_Reply transmis par le nœud racine comportant un statut NON_MER, ledit nœud routeur vérifie s'il existe dans sa table d'association un nœud hôte concerné par le message de réponse MER_Reply reçu.
Si c'est le cas, ledit nœud routeur met son statut vis-à-vis du nœud hôte concerné à NON_MER, remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu et supprime de sa mémoire tout packet de données multicast, associé à ladite entrée précédemment stocké.
Notons qu'optionnellement le nœud routeur qui vient de recevoir le message MER_Reply transmis par le nœud racine et comportant un statut NON_MER peut aussi diffuser, en multicast avec portée locale, un message d'annonce comportant le statut NON_MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = source], [adresse IP multicast] de manière à permettre aux nœuds routeurs en portée radio directe et ayant une entrée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =source] et [adresse IP multicast] marquée avec le statut NON_MER, CANDIDAT_MER ou PENDING de mettre à jour la valeur du champ lifetime_table_entry de cette entrée sur la base de celle qui est indiquée dans le message d'annonce et de mettre le statut de cette entrée à NON_MER.
Par contre, à la réception par le nœud routeur d'un message de réponse MER_Reply transmis par le nœud racine comportant un statut MER, ledit nœud routeur vérifie s'il existe dans la deuxième table d'association un nœud hôte concerné par le MER_Reply reçu.
Si c'est le cas, ledit nœud routeur met son statut vis-à-vis du nœud hôte concerné à MER, remplace la durée de vie de son statut vis-à-vis du nœud hôte concerné par celle indiquée dans le message MER_Reply reçu, et, diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = source], [adresse IP multicast] de manière à permettre aux nœuds routeurs en portée radio directe et ayant une entrée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =source] et [adresse IP multicast] marquée avec le statut NON_MER, CANDIDAT_MER ou PENDING de manière mettre à jour la valeur du champ lifetime_table_entry de cette entrée sur la base de celle qui est indiquée dans le message d'annonce et de mettre le statut de cette entrée à NON_MER.
De plus, Le nœud routeur ayant reçu le message MER_Reply le configurant avec le statut MER pour ladite entrée dans sa deuxième table d'association peut transmette dans le réseau tout packet de données multicast, associé à ladite entrée, précédemment stocké ainsi que tout packet de données multicast futur reçu correspondant à ladite entrée.
De manière générale, si au niveau du nœud routeur le statut associée à une entrée donnée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =source], [adresse IP multicast] est CANDIDAT_MER et si la durée indiquée dans le champ lifetime_statut associé à cette entrée expire, ledit nœud routeur passe en statut PENDING pour ladite entrée et transmet au nœud racine un message MER_Request.
Notons que si la valeur du champ lifetime_table_entry associée à l'entrée donnée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =source], [adresse IP multicast] expire, ledit routeur supprime ladite entrée de sa table d'association.
Dans une deuxième variante, il est possible d'effectuer une présélection d'un sous-ensemble de nœuds routeurs dans le réseau LLN (Lower power and Lossy Network) parmi un ensemble de nœuds susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes, ledit réseau LLN comportant un nœud racine chargé de gérer une première table contenant une liste de nœuds routeurs autorisés à transférer des paquets multicast du réseau LLN vers un nœud hôte donné ou d'un nœud hôte donnée vers le réseau LLN.
Dans ce cas deux états sont associés à un nœud routeur : ■ CANDIDAT_MER (Multicast Edge Router), indiquant que ledit nœud routeur est candidat pour agir comme unique routeur pour un nœud hôte donné;
N 0 N_C AN D I D AT_M E R (Multicast Edge Router), indiquant que ledit nœud routeur n'est pas candidat pour agir comme unique routeur pour un nœud hôte donné. Dans cette variante, chaque nœud routeur transmet aux autres nœuds routeurs du réseau LLN en portée radio directe dudit nœud hôte un message d'annonce comportant une information ayant une valeur sur la base de laquelle sera conduite la configuration des nœuds routeurs en tant que CANDI DAT_MER ou N 0 N_C AN D I D AT_M E R, ladite information pouvant être contenue dans le champ de données du message d'annonce (p. ex. une valeur donnée) ou bien dans un entête du message d'annonce (p. ex. l'adresse MAC ou l'adresse IP source du nœud routeur émettant l'annonce).
A la réception dudit message d'annonce, chacun desdits autres nœuds routeurs compare la valeur de sa propre information (p. ex. adresse MAC ou adresse IP ou toute autre information utilisée pour la configuration des états C AN D I D AT_M E R/N 0 N_CAN D I D AT_M E R d'un nœud routeur) à celle contenue dans le message d'annonce , et, si la valeur de l'information contenue dans le message d'annonce est inférieure à la valeur de l'information du nœud routeur ayant reçu ledit message d'annonce, alors ce dernier se met dans l'état NON_CANDIDAT_MER, sinon, le nœud routeur ayant reçu ledit message d'annonce reste dans l'état CANDIDAT_MER.
Il est à noter que cette présélection n'est pas forcement conditionnée à la réception par un nœud routeur d'une requête de souscription à un groupe multicast (p. ex. un message MLD Report) ou d'un message multicast d'un nœud hôte donné (récepteur ou source). En particulier selon cette deuxième variante, le candidat MER pré- sectionné (c.à.d. dans l'état CANDIDAT_MER) peut potentiellement ne pas être en portée directe du nœud hôte (source ou récepteur) qu'il servira.
Dans cette deuxième variante on utilise l'adresse source (p. ex. adresse MAC ou adresse IP) des messages d'annonce (par ex. messages DIO du protocole RPL) échangés entre les routeurs RPL pour permettre à chaque routeur du réseau RPL de décider s'il a le droit d'être un routeur candidat (c.à.d. dans l'état CANDIDAT_MER), et donc de contacter ultérieurement le nœud racine via des messages MER_Request pour déterminer s'il sera configuré par ce dernier en tant qu'unique routeur multicast (c.à.d. avec le statut MER) vis-à-vis d'un nœud hôte donné. Selon une première caractéristique de la deuxième variante de l'invention, chaque nœud routeur ayant un statut NON_CANDIDAT_MER comporte une table de transfert permettant de gérer les échanges des paquets multicast entre un nœud routeur et un nœud hôte, ladite table de transfert comportant les champs suivants:
" Le champ « adresse de l'hôte » destiné à contenir l'adresse du nœud hôte;
■ le champ optionnel [type de l'hôte] destiné à contenir le type dudit nœud hôte parmi l'un des deux types suivants, source ou récepteur;
■ le champ optionnel [adresse IP multicast] destiné à contenir l'adresse d'un groupe multicast auquel appartient le nœud hôte;
■ le champ « Adresse MAC_x » : destiné à contenir l'adresse MAC du nœud duquel a été reçu le paquet multicast ou le message MLD Report
■ le champ « Adresse MAC_y » : destiné à contenir l'adresse MAC du CANDIDAT_MER (non-applicable si le routeur RPL courant est lui-même CANDI DAT_MER) ■ Le champ Lifetime_table_entry destiné à contenir une durée de vie de l'entrée associée au nœud hôte dans ladite table de transfert;
Dans la suite de la description on désignera tout champ optionnel de la table de transfert par [X] où X représente le nom du champ optionnel. Ces champs optionnels sont : le type du nœud hôte et l'adresse IP multicast.
Selon une autre caractéristique de la deuxième variante, chaque nœud routeur comporte une table des annonces contenant les routeurs voisins desquels il a reçu un message d'annonce, de sorte qu' à chaque fois qu'un nœud routeur NON_CANDIDAT_MER reçoit un message d'annonce d'un nouveau nœud routeur qui n'est pas déjà répertorié dans sa table des annonces, ledit routeur NON_CANDIDAT_MER ajoute l'adresse MAC dudit nouveau nœud routeur dans sa table des annonces, compare l'adresse MAC du nouveau nœud routeur à l'adresse MAC du nœud routeur CANDIDAT_MER courant indiquée dans sa table des annonces, et si l'adresse IP du nouveau nœud routeur est inférieure à celle du nœud CANDIDAT_MER courant, ledit nœud routeur NON_CANDIDAT_MER considère que c'est le nouveau nœud routeur qui est son nouveau CANDIDAT_MER et met sa table des annonces à jour en conséquence. Selon une autre caractéristique de cette deuxième variante, lorsqu'un nœud routeur reçoit une requête de souscription à un groupe multicast (p. ex. un message de type MLD Report) d'un nœud hôte de type récepteur, il consulte sa deuxième table d'association pour vérifier s'il a déjà reçu une même requête de souscription et, ■ Si c'est le cas, la requête (p. ex. le message MLD report) est ignorée,
■ Sinon, ledit nœud routeur :
• génère une nouvelle entrée dans sa table de transfert contenant les champs adresse IP de l'hôte, [type de l'hôte =récepteur], [adresse IP multicast] déduits de la requête de souscription (p. ex. du message MLD Report) reçue,
• associe à cette entrée le champ « Adresse MAC_x » qui contient l'adresse MAC du nœud duquel a été reçue la requête de souscription (p. ex. le message MLD Report)
• associe à cette entrée un champ lifetime_table_entry contenant une valeur non nulle, et,
■ mémorise le message reçu dans de la requête de souscription s'il est dans l'état CANDIDAT_MER et si sa mémoire le lui permet, traduit ce message en un message MER_Request, puis transmet ledit message MER_Request au nœud racine; par contre, s'il est dans l'état NON_CANDIDAT_MER, il transfère ledit message au nœud CANDIDAT_MER indiqué dans sa table des annonces.
Lorsqu'un nœud routeur reçoit un paquet de données multicast émis par un nœud hôte de type source, il consulte sa table de transfert pour vérifier si l'une de ses entrées correspond aux champs adresse de l'hôte, [type de l'hôte=source], et [adresse IP multicast] déduits du paquet multicast reçu, et,
- Si ce n'est pas le cas, ledit nœud routeur:
- génère une nouvelle entrée dans sa table de transfert contenant les champs adresse IP de l'hôte, [type de l'hôte =source], [adresse IP multicast] déduits du paquet multicast reçu, associe à l'entrée ajoutée un champ « Adresse MAC_x » qui contient l'adresse MAC du nœud duquel a été reçu le paquet multicast et un champ lifetime_table_entry contenant une valeur non nulle, et, mémorise le paquet de données reçu, s'il est type CANDI DAT_MER et si sa mémoire le lui permet, et transmet un message MER_Request au nœud racine;
- ou, transfère le paquet multicast reçu au nœud routeur CANDI DAT_MER indiqué dans sa table des annonces s'il est de type NON_CANDIDAT_MER.
La première variante du procédé selon l'invention est mis en œuvre par un dispositif dans lequel chaque nœud routeur est adapté pour transmettre aux autres nœuds routeurs du réseau LLN en portée radio directe dudit nœud hôte un message d'annonce comportant son statut vis-à-vis d'un nœud hôte et l'adresse dudit nœud hôte donnée et, chacun desdits autres nœuds routeurs est adapté pour comparer son statut vis-à-vis dudit nœud hôte donnée au statut indiqué dans le message d'annonce, et pour configurer son statut en fonction de ladite comparaison de sorte qu'un seul nœud parmi les nœuds du réseau LLN en portée radio directe dudit nœud hôte transmette au nœud racine une requête MER_Request de configuration en tant que routeur multicast pour ledit nœud hôte donné; ledit nœud racine étant adapté pour accorder le statut MER pour le nœud hôte donné au premier nœud routeur lui ayant transmis une requête MER_Request.
La deuxième variante du procédé selon l'invention est mise en œuvre par un dispositif dans lequel chaque nœud routeur est adapté pour transmettre aux autres nœuds routeurs du réseau LLN en sa portée radio directe un message d'annonce comportant une information (p. ex. l'adresse MAC ou l'adresse IP source du nœud routeur émettant l'annonce ou toute autre information) ayant une valeur sur la base de laquelle sera conduite la configuration des nœuds routeurs en tant que CANDIDAT_MER ou NON_CANDIDAT_MER, et, chacun desdits autres nœuds routeurs est adapté pour comparer la valeur de sa propre information (p. ex. adresse MAC ou adresse IP ou toute autre information utilisée pour la configuration des états C AN D I D AT_M E R/N 0 N_CAN D I D AT_M E R d'un nœud routeur) à celle contenue dans le message d'annonce , de sorte que si la valeur de l'information contenue dans le message d'annonce est inférieure à la valeur de l'information du nœud routeur ayant reçu ledit message d'annonce, alors ce dernier se met dans l'état NON_CAN DIDAT_MER, sinon, il reste dans l'état CANDI DAT_MER.
Le procédé selon l'invention est implémenté par un programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour réaliser les étapes de la première variante ou de la deuxième variante lorsqu'il est exécuté sur un ordinateur.
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 illustre la séquence d'échange de messages entre des nœuds RPL, des nœuds hôtes sources de paquets de données, et le nœud racine pour la sélection d'un routeur multicast dans un réseau RPL selon l'invention;
- la figure 2 illustre la séquence d'échange de messages entre des nœuds RPL, des nœuds hôtes destinataires de paquets de données, et le nœud racine pour la sélection d'un routeur multicast dans un réseau RPL selon l'invention.
- la figure 3 illustre schématiquement les étapes de présélection d'un nœud routeur dans une variante particulière du procédé selon l'invention.
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'invention sera décrite lorsqu'elle est appliquée dans un réseau LLN
(pour Lower power and Lossy Network) comportant une pluralité de nœuds RPL (pour Routing Protocol for LLN) portant respectivement les référence 2 et 3 et un nœud racine 4 ayant une vue globale sur ces nœuds RPL. Le nœud racine 4 comporte une première table, dite table d'association, destinée à mémoriser des associations entre au moins un des nœuds hôtes portant respectivement les référence 6 et 8 d'un groupe multicast et un des nœuds RPL. Un nœud hôte pouvant être soit la source soit le destinataire des paquets de données échangés à travers le réseau. Dans la suite de la description, des références identiques désigneront des éléments remplissant des fonctions identiques dans les différentes figures. On désignera un nœud hôte source de paquets de données par le terme source 6, et un nœud hôte destinataire de paquets de données par le terme récepteur 8.
Pour plus de clarté, le réseau LLN auquel il sera fait référence dans la suite de cette description comporte seulement deux nœuds routeurs 2 et 3 en portée directe des nœuds hôtes 6 et 8. Cependant le procédé selon l'invention s'applique également dans le cas où le réseau comporte plus que deux nœuds RPL.
La configuration d'un nœud RPL est réalisée par échange de messages de configuration MER_Request/MER_Reply entre le nœud racine 4 et chaque nœud RPL ayant demandé de servir de routeur multicast vis-à-vis d'un nœud hôte donné.
Le nœud RPL élu est appelée routeur multicast du bord du réseau ou MER (Multicast Edge Routeur en anglais) pour une source ou un récepteur.
Dans le cas où le nœud hôte est une source, le MER sera en charge d'intercepter des paquets multicast de la source et de les transmettre dans l'arbre de diffusion multicast RPL.
Dans le cas où le nœud hôte est un récepteur, le MER sera en charge d'intercepter les requêtes d'adhésion multicast de ce récepteur, telle que par exemple une requête de type MLD report (pour Multicast Listener Discovery décrite dans | R. Vida et al. « Multicast Listener Discovery Version 2 (MLDv2) for IPv6 », RFC 3610, June 2004]) et de déclencher la création d'une branche de routage multicast dans le réseau RPL pour ce groupe, et de transmettre les paquets multicast reçu via ladite branche de routage multicast au nœud hôte récepteur.
Dans un mode particulier de réalisation de l'invention, l'échange des messages MER_Request/MER_Reply est implémenté à travers une extension de l'échange
DAO/DAO_ACK du protocole RPL. Le message DAO (Destination Avertissement Object) du protocole RPL est traditionnellement utilisé par les nœuds RPL pour ajouter ou supprimer une branche (un chemin IP) du réseau RPL. Le message DAO_ACK est envoyé du nœud racine 4 vers le nœud RPL 8 en réponse à un message DAO.
Notons que chaque nœud RPL peut avoir l'un des statuts suivants: ■ CANDIDAT_MER (Multicast Edge Router), indiquant que le nœud routeur est candidat pour agir comme unique routeur multicast pour un nœud hôte donné;
■ PENDING indiquant que le nœud routeur (2, 3) est en attente d'être sélectionné par le nœud racine comme unique routeur multicast pour ledit nœud hôte,
■ MER, indiquant que ledit nœud routeur est configuré en tant qu'unique routeur multicast pour ledit nœud hôte;
■ NON_MER, indiquant que ledit nœud routeur est configuré pour ne pas être routeur multicast pour ledit nœud hôte.
Le statut d'un nœud RPL est inscrit dans une deuxième table d'association qui contiendra en outre les champs suivants:
■ Adresse de l'hôte: adresse IP d'une source ou d'un récepteur multicast ;
■ Type de l'hôte: champ optionnel spécifiant le type de l'hôte, ou le type peut être « source » ou « récepteur » ;
■ Adresse Multicast: champ optionnel spécifiant l'adresse du groupe multicast associé à la source ou au récepteur ;
■ Lifetime/durée de vie: durée de vie de l'entrée associée à l'hôte;
■ Statut: CANDIDAT_MER, PENDING, MER, ou NON_MER,
La figure 1 illustre les échanges de messages entre le nœud racine 4 et deux nœuds RPL 2 et 3 pour l'élection d'un MER parmi ces deux nœuds pour la source 6.
A l'étape 20, la source 6 diffuse un paquet de données multicast comportant, outre les données utiles, un entête indiquant l'adresse de la source @S et l'adresse multicast mcast@ du groupe auquel appartient le nœud destinataire du paquet de données.
A la réception du paquet diffusé, chacun des nœuds RPL 2 et 3 détermine qu'il ne possède pas d'entrée dans sa dite deuxième table d'association correspondant au message reçu et génère ainsi une nouvelle entrée pour ledit nœud hôte (en y indiquant l'adresse de l'hôte et optionnellement le type de l'hôte et l'adresse multicast), affecte le statut CANDIDAT_MER à cette entrée, affecte des valeurs non nulles respectivement aux champs Lifetime_statut et Lifetime_table_entry, et stocke le paquet multicast reçu si sa mémoire disponible le lui permet. Chacun des nœuds RPL 2 et 3 génère aussi un message d'annonce comportant son statut vis-à-vis de la source 6 et l'adresse dudit nœud hôte (c.à.d. CANDI DAT_MER).
A l'étape 22 (respectivement 24), le nœud RPL 2 (respectivement 3) transmet le message d'annonce généré au nœud RPL 3 (respectivement 2).
A l'étape 26, le nœud RPL 2 vérifie que le statut du nœud RPL 3 indiqué dans le message d'annonce est CANDIDAT_MER, compare son adresse à celle du nœud RPL 3, et, garde son statut CANDI DAT_MER si son adresse est inférieure à celle du nœud RPL 3.
A l'étape 27, le nœud RPL 3 vérifie que le statut du nœud RPL 2 indiqué dans le message d'annonce est CANDIDAT_MER, compare son adresse à celle du nœud RPL 2, et, change son statut à NON_MER, et vide de sa mémoire le(s) paquet(s) de donnée(s) multicast stockés, si son adresse est supérieure à celle du nœud RPL 2.
A l'étape 28, le champ Lifetime_statut de ladite entrée de la table d'association du nœud RPL 2 expire et le nœud RPL 2 affecte une valeur PENDING à son statut pour ladite entrée.
A l'étape 30, le nœud RPL 2 transmet au nœud racine une requête MER_Request comportant l'adresse de la source 6 S@, et optionnellement le type de la source 6([type= source]) et l'adresse du groupe multicast du nœud destinataire du paquet de données ([mcast@]).
A l'étape 32, le nœud racine 4 vérifie si le nœud RPL 2 est le premier nœud ayant transmis une requête MER_Request, et dans l'affirmative, accorde le statut MER à ce nœud et lui transmet (étape 34) une réponse MER_Reply comportant ledit statut MER, l'adresse de la source 6 S@, et optionnellement le type de la source 6([type= source]) et l'adresse du groupe multicast du nœud destinataire du paquet de données([mcast@]), ainsi qu'une valeur non nulle pour le champ Lifetime_table_entry du nœud RPL 2 vis-à-vis de la source 6.
A l'étape 36, le nœud RPL 2 élu met son statut vis-à-vis de la source à MER, et, remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu, transfère le(s) paquet(s) de données multicast reçu(s) de la source 6 vers l'arbre multicast, puis vide sa mémoire.
A l'étape 38, le nœud RPL 2 diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER ainsi que le champ adresse IP de l'hôte, et optionnellement les champs [type de l'hôte = source] et [adresse IP multicast], de manière à permettre au nœud RPL 3 de mettre à jour la valeur du champ [lifetime_table_entry] de cette entrée sur la base de celle qui est indiquée dans le message d'annonce.
A l'étape 40, le nœud RPL 3 effectue la mise à jour de la valeur du champ [lifetime_table_entry].
A la réception d'un nouveau paquet de données multicast de la source 6 (étape 42) le nœud RPL 2 transfère (étape 44) automatiquement le paquet de données vers l'arbre multicast, tandis que le nœud RPL 3 ignore ce nouveau paquet (étape 46).
La figure 2 illustre les échanges de messages entre le nœud racine 4 et deux nœuds RPL 2 et 3 pour l'élection d'un MER parmi ces deux nœuds pour le récepteur 8.
A l'étape 50, le récepteur 8 diffuse un message d'adhésion à un groupe multicast (p. ex. un message de type MLD Report) comportant l'adresse du récepteur 8 et l'adresse IP mcast@ du groupe multicast auquel appartient le destinataire 8.
A la réception du message d'adhésion à un groupe multicast (p. ex. un message MLD), le nœud RPL 2 (respectivement RPL 3) détermine (étape 52) (respectivement 54) qu'il ne possède pas d'entrée dans sa dite deuxième table d'association correspondant au message reçu et génère ainsi une nouvelle entrée pour ledit nœud hôte (en y indiquant l'adresse de l'hôte et optionnellement le type de l'hôte (récepteur) et l'adresse multicast), affecte le statut CANDIDAT_MER à cette entrée, affecte des valeurs non nulles respectivement aux champs Lifetime_statut et Lifetime_table_entry, et stocke le message d'adhésion reçu si sa mémoire disponible le lui permet. Chacun des nœuds RPL 2 et 3 génère aussi un message d'annonce comportant son statut vis-à-vis du destinataire 8 et l'adresse dudit nœud hôte 8 (c.à.d. CANDI DAT_MER). A l'étape 56 (respectivement 58), le nœud RPL 2 (respectivement RPL 3) transmet le message d'annonce généré au nœud RPL 3 (respectivement 2).
A l'étape 60 (respectivement 62), le nœud RPL 2 (respectivement RPL 3) vérifie le statut du nœud RPL 3 (respectivement RPL 2) indiqué dans le message d'annonce, compare son adresse à celle du nœud RPL 3 (respectivement RPL 2) et, garde son statut CANDI DAT_MER si son adresse est inférieure à celle du nœud RPL 3(respectivement RPL 2) et si le statut du nœud RPL 3 est CANDIDAT_MER.
Dans l'exemple illustré par la figure 2, l'adresse @R1 du nœud RPL 2 est inférieure à celle du nœud RPL 3. Dans ce cas, ce dernier met son statut à NON_MER, tandis que le nœud RPL 2 garde son statut CANDIDAT_MER.
A l'étape 64 le champ Lifetime_statut de ladite entrée de la table d'association du nœud RPL 2 expire et le nœud RPL 2 affecte une valeur PENDING à son statut pour ladite entrée.
A l'étape 66, le nœud RPL 2 transmet au nœud racine 4 une requête MER_Request comportant l'adresse du destinataire 8, et optionnellement le type de ce destinataire et l'adresse du groupe multicast auquel appartient ce destinataire.
A l'étape 68, le nœud racine vérifie si le nœud RPL 2 est le premier nœud ayant transmis une requête MER_Request, et si c'est le cas, accorde le statut MER à ce nœud et lui transmet (étape 70) une réponse MER_Reply comportant ledit statut MER, l'adresse du destinataire 8, et optionnellement le type de ce destinataire 8 et l'adresse du groupe multicast auquel appartient ce destinataire, ainsi qu'une valeur non nulle pour le champ Lifetime_table_entry du nœud RPL 2 vis-à-vis du destinataire 8.
A l'étape 72, le nœud RPL 2 élu met son statut à MER remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu, et crée une branche de l'arbre multicast, puis vide sa mémoire.
A l'étape 74, le nœud RPL 2 diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER, l'adresse du destinataire 8, et optionnellement le type du destinataire 8 et l'adresse IP multicast du groupe auquel appartient ce destinataire 8, ainsi que la durée de vie de l'entrée (lifetime_table_entry) de manière à permettre au nœud RPL 3 de mettre à jour la valeur du champ lifetime_table_entry sur la base de celle qui est indiquée dans le message d'annonce transmis par le nœud RPL 2. A l'étape 76, le nœud RPL 3 effectue la mise à jour de la valeur du champ lifetime_table_entry.
La figure 3 illustre les étapes d'une deuxième variante de l'invention permettant d'effectuer une présélection d'un sous-ensemble de nœuds routeurs parmi un ensemble de nœuds ayant un statut parmi l'un des statuts suivants, CANDIDAT_MER ou NON_CANDIDAT_MER. Dans cette variante, tout nœud RPL (CANDIDAT_MER ou NON_CANDIDAT_MER) stocke dans sa mémoire l'adresse MAC du nœud duquel il a reçu un nouveau paquet multicast ou un nouveau MLD Report. De plus, tout routeur NON_CANDIDAT_MER stocke dans sa mémoire l'adresse MAC de son routeur CANDIDAT_MER. Ce stockage d'adresse MAC permet de transférer les paquets multicast, en unicast niveau 2, de la source vers le CANDIDAT_MER et du CANDIDAT_MER vers le récepteur sans risque de duplication des paquets multicast. De plus chaque routeur RPL NON_CANDIDAT_MER est supposé gérer une table spécifique, appelée table de transfert permettant de transférer les paquets multicast du MER vers le récepteur et de filtrer et transférer les paquets multicast allant de la source vers le MER. La table de transfert au niveau d'un routeur RPL contient les éléments suivants :
■ Adresse de l'hôte : adresse IP d'une source ou d'un récepteur multicast,
■ Type de l'hôte: champ optionnel spécifiant le type de l'hôte, ou le type peut être « source » ou « récepteur »,
■ Adresse Multicast : champ optionnel spécifiant l'adresse du groupe multicast associé à la source ou au récepteur,
■ Adresse MAC_x : adresse MAC du nœud duquel a été reçu le paquet multicast ou le MLD Report,
■ Adress MAC_y : adresse MAC du CANDIDAT _MER (non-applicable si le routeur RPL courant est lui-même CANDIDAT_MER),
■ Lifetime/durée de vie : durée de vie de l'entrée associée à l'hôte (ex. instant d'expiration de l'entrée). En outre, chaque nœud RPL comporte une table des annonces contenant les routeurs voisins desquels il a reçu un message d'annonce de sorte qu' à chaque fois qu'un routeur NON_CANDIDAT_MER reçoit un message d'annonce d'un nouveau routeur qui n'est pas dans sa table des annonces, ledit routeur NON_CANDIDAT_MER ajoute l'adresse MAC dudit nouveau routeur dans ladite table des annonces.
Ainsi, lorsqu'un nœud RPL appelé A est initialisé, il met son statut à « CANDI DAT_MER » (étape 80) et reste dans cet état jusqu'à ce que son statut soit obsolète par certaines conditions mentionnées ci-après.
Quand le nœud RPL A reçoit ensuite (étape 82) un message d'annonce tel que par exemple un message DIO du protocole RPL émis en multicast avec portée locale par un autre routeur RPL appelé routeur B ledit routeur A compare (étape 84) son adresse @A à l'adresse @B du routeur RPL B.
Si @B < @A, alors le routeur «A» se met dans l'état NON_CANDIDAT_MER (étape 86) et ajoute l'adresse @B dans sa table des annonces en indiquant que le routeur B est CANDI DAT_MER du point de vue du routeur A (étape 87). Dans le cas contraire le routeur A reste dans l'état CANDIDAT_MER.
Si @A < @B, à l'étape 88, le routeur A vérifie si @B existe déjà dans sa table des annonce.
Si oui, le routeur A ignore l'annonce émise par le routeur B (l'étape 90).
Sinon, le routeur A ajoute l'adresse @B dans sa table des annonces
(étape 92).
Ainsi, grâce à l'utilisation de l'adresse source des messages d'annonce échangés entre les routeurs RPL, chaque routeur du réseau RPL peut décider s'il a le droit d'être un routeur candidat (et donc de contacter le nœud racine à cet effet via des messages MER_Request).
Il est à noter que dans cette variante, le routeur CANDI DAT_MER n'est pas toujours en portée radio directe de la source. Le procédé selon l'invention s'applique à la fois dans le contexte des réseaux informatiques/télécom à faible ressources (Lower power and Lossy Networks : LLNs), par exemple les réseaux de capteurs sans fils (Wireless Sensor Networks), ainsi que dans les réseaux de télécommunications IP multicast grâce à : « la définition d'un mécanisme d'échange de messages dans le réseau
RPL entre un ensemble de routeurs et un nœud racine ; l'échange permettant au nœud racine de désigner un routeur multicast pour servir une source multicast ou un récepteur multicast (c.à.d. accepter/transférer un paquet multicast venant d'une source multicast ou envoyer un paquet multicast vers un récepteur multicast);
« La définition d'une première table d'association dans le nœud racine et d'une deuxième table d'association dans chaque nœud RPL, des tables de transfert et d'annonce qui associent un routeur multicast sélectionné (MER) avec un ou plusieurs groupes multicast ainsi qu'un ou plusieurs sources et/ou récepteurs, et
• La définition de fonctionnalités de gestion desdites tables d'association (ajout/suppression d'entrées dans la table d'association) au niveau du nœud racine.
• La définition des fonctionnalités spécifiant les conditions de sélection d'un routeur multicast (MER) au niveau du nœud racine;
• La définition des fonctionnalités spécifiant les conditions de sélection d'un routeur multicast (MER) au niveau des routeurs multicast.
Il est important de noter que la présente invention s'applique quel que soit le mode de routage du trafic multicast utilisé dans le réseau RPL ; qu'il s'agisse en particulier du mode dit « multicast storing» tel que défini par la spécification RPL ou encore du mode dit « multicast non-storing » défini dans [CJanneteau, M. Kellil, BD12830 « Procédé de routage d'un flux en mode non-stockage », demande de brevet français déposée le 11 juillet 2011 sous le n° 11 56273].

Claims

REVENDICATIONS
1. Procédé de présélection d'un routeur dans un réseau LLN (Lower power and Lossy channel Network) parmi une pluralité de nœuds (2,3) susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes (6,8), ledit réseau LLN comportant un nœud racine (4) chargé de gérer une première table d'association contenant une liste de nœuds routeurs (2,3) autorisés à transférer des paquets multicast du réseau LLN vers un nœud hôte donné ou d'un nœud hôte donnée vers le réseau LLN, chaque nœud routeur (2,3) ayant un statut parmi l'un des statuts suivants :
CANDI DAT_M ER (M ulticast Edge Router), indiquant que le dit nœud routeur (2, 3) est candidat pour agir comme unique routeur multicast pour un nœud hôte donné (6,8);
PENDI NG indiquant que le nœud routeur (2, 3) est en attente d'être sélectionné par le nœud racine (4) comme unique routeur multicast pour ledit nœud hôte (6,8),
M ER, indiquant que ledit nœud routeur (2, 3) est configuré en tant qu'unique routeur multicast pour ledit nœud hôte (6,8) ;
NON_M ER, indiquant que ledit nœud routeur (2, 3) est configuré pour ne pas être routeur multicast pour ledit nœud hôte (6,8).
Procédé caractérisé par les étapes suivantes:
- à la réception par un nœud routeur donné (2,3) d'un paquet multicast ou d'une requête de souscription à un groupe multicast provenant d'un nœud hôte (6, 8) donné, ledit nœud routeur (2,3) transmet aux autres nœuds routeurs du réseau LLN à sa portée radio directe un message d'annonce comportant son statut vis-à-vis du nœud hôte (6,8) et l'adresse dudit nœud hôte, et,
- à la réception dudit message d'annonce, chacun desdits autres nœuds routeurs (2,3) compare son statut courant vis-à-vis dudit nœud hôte (6,8) au statut indiqué dans le message d'annonce, et configure son statut en fonction de ladite comparaison de sorte qu'un seul nœud en portée radio directe dudit nœud routeur (2,3) parmi les nœuds du réseau LLN transmette au nœud racine une requête MER_Request de configuration en tant que routeur multicast pour les données en provenance ou à destination dudit nœuds hôte (6,8) donné,
- à la réception de ladite requête MER_Request, le nœud racine (4) accorde le statut MER pour ledit nœud routeur (2,3) au premier nœud routeur (2,3) ayant transmis une requête MER_Request.
2. Procédé selon la revendication 1 comportant en outre une étape consistant à mémoriser dans chaque nœud routeur une deuxième table d'association des informations de routage dans les champs suivants:
■ Un champ « adresse de l'hôte » destiné à contenir l'adresse du nœud hôte (6,8);
■ Un champ optionnel « type de l'hôte » destiné à contenir le type dudit nœuds hôte (6,8) parmi l'un des deux types suivants, source ou récepteur ;
■ Un champ optionnel « adresse IP multicast » destiné à contenir l'adresse d'un groupe multicast auquel appartient le nœud hôte;
■ Un champ « statut » destiné à contenir le statut du nœud routeur vis-à-vis dudit nœud hôte, et pouvant prendre l'une des quatre valeurs suivantes : CANDIDAT_MER, PENDING, MER et NON_MER ;
■ Un champ « Lifetime_table_entry » destiné à contenir une durée de vie du statut du nœud routeur (2,3) vis-à-vis dudit nœud hôte (6,8);
■ Un champ « Lifetime_statut » destiné à contenir un temps d'attente d'un routeur en mode CANDIDAT_MER avant de passer en mode PENDING et envoyer un message MER_Request au nœud racine.
3. Procédé selon la revendication 2 dans lequel, lorsqu'un nœud routeur reçoit ledit message d'annonce, il vérifie d'abord dans ladite deuxième table d'association si l'une de ses entrées correspond aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] du message d'annonce reçu, et, si aucune entrée ne correspond aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] du message d'annonce reçu, ledit nœud routeur ignore le message d'annonce reçu.
4. Procédé selon la revendication 2 dans lequel, lorsqu'un nœud routeur reçoit ledit message d'annonce, il vérifie d'abord dans ladite deuxième table d'association si l'une de ses entrées correspond aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] du message d'annonce reçu, et, si une entrée correspond aux champs adresse de l'hôte, [type de l'hôte], et [adresse IP multicast] du message d'annonce reçu, alors,
- si le message d'annonce contient un statut CANDI DAT_MER et si l'entrée trouvée dans ladite deuxième table d'association a un statut CANDIDAT_MER, le nœud routeur (2,3) compare son adresse à celle du nœud routeur émetteur du message d'annonce et garde son statut CANDIDAT_MER si son adresse est inférieure à celle du nœud routeur émetteur du message d'annonce, ou met le statut associé à l'entrée trouvée à NON_MER si son adresse est supérieure à l'adresse du nœud routeur émetteur du message d'annonce ;
- si le message d'annonce contient un statut CANDI DAT_MER et si une entrée dans ladite deuxième table d'association a un statut PENDING, un statut NON_MER, ou un statut MER pour ledit nœud routeur vis-à-vis du nœud routeurs (2,3) identifié dans le message d'annonce, ce dernier ignore le message d'annonce reçu,
- si le message d'annonce contient un statut MER et si une entrée dans ladite deuxième table d'association a un statut NON_MER, ledit nœud routeur (2,3) remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu de manière à synchroniser la valeur du champ [lifetime_table_entry] au niveau de tous les nœuds routeurs (2,3) disposant de l'entrée trouvée,
- Si le message d'annonce contient un statut MER et si une entrée dans ladite deuxième table d'association a un statut CANDIDAT_MER ou un statut PENDING, ledit nœud routeur (2,3) remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NONJV1ER,
- Si le message d'annonce contient un statut NON_MER, alors,
• si une entrée de ladite deuxième table d'association a un statut MER, ledit nœud routeur (2,3) ignore le message reçu,
• si une entrée de ladite deuxième table d'association a un statut NON_MER, ledit nœud routeur (2,3) remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu,
• si une entrée de ladite deuxième table d'association a un statut CANDIDAT_MER ou un statut PENDING, ledit nœud routeur (2,3) remplace la valeur du champ lifetime_table_entry associée à l'entrée trouvée par celle indiquée dans le message reçu et change le statut de l'entrée à NON_MER.
5. Procédé selon la revendication 3 dans lequel, lorsqu'un nœud routeur (2,3) reçoit une requête de souscription à un groupe multicast d'un nœuds routeurs (2,3) de type récepteur, ledit nœud routeur consulte ladite deuxième table d'association pour vérifier s'il a déjà reçu une même requête de souscription et,
• si c'est le cas, le message de requête de souscription est ignoré par ledit nœud routeur (2,3),
• sinon, le nœud routeur génère une nouvelle entrée dans sa deuxième table d'association contenant les champs adresse IP de l'hôte, [type de l'hôte =récepteur], [adresse IP multicast] déduits de la requête de souscription reçue, met son statut correspondant à l'entrée ajoutée à CANDI DAT_MER, associe ce statut à un champ lifetime_statut et à un champ lifetime_table_entry contenant chacun une valeur non nulle, puis, diffuse, en multicast avec portée locale, un message d'annonce comportant le statut CANDIDAT_MER ainsi que les champs adresse IP de l'hôte, [type de l'hôte = récepteur], [adresse IP multicast].
6. Procédé selon la revendication 5 dans lequel, à la réception d'un message de réponse MER_Reply transmis par le nœud racine et comportant un statut NON_MER, le nœud routeur ayant reçu la requête de souscription à un groupe multicast vérifie s'il existe dans ladite deuxième table d'association un nœuds routeurs (2,3) concerné par le message de réponse MER_Reply reçu, et, si c'est le cas, met son statut vis-à-vis du nœuds routeurs (2,3) concerné à NON_MER, et remplace la valeur du champ lifetime_table_entry par celle indiquée dans le message MER_Reply reçu.
7. Procédé selon la revendication 5 dans lequel, à la réception par un nœud routeur (2,3) d'un message de réponse MER_Reply transmis par le nœud racine (4) et comportant un statut MER, ledit nœud routeur (2,3): - vérifie s'il existe dans la deuxième table d'association un nœud hôte
(6,8) concerné par le MER_Reply reçu,
- Si oui, ledit nœud routeur (2,3) met son statut vis-à-vis du nœud hôte (6,8) concerné à MER, et,
- remplace la durée de vie de son statut vis-à-vis du nœud hôte (6,8) concerné par celle indiquée dans le message MER_Reply reçu ;
- établit une branche multicast allant vers ledit nœud hôte (8), et,
- diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER ainsi que les champs [adresse IP de l'hôte], [type de l'hôte = récepteur], [adresse IP multicast] de manière à permettre aux nœuds routeurs (2,3) en portée radio directe et ayant une entrée correspondant aux champs adresse IP de l'hôte, [type de l'hôte =récepteur] et [adresse IP multicast] marquée avec le statut NON_MER ou PENDING de mettre à jour la valeur du champ [lifetime_table_entry] de cette entrée sur la base de celle qui est indiquée dans le message d'annonce.
8. Procédé selon la revendication 1 dans lequel, l'annonce transmise par le nœud routeur (2, 3) est implémentée à travers un message de type DIO du protocole RPL (DODAG Information Object).
9. Procédé selon la revendication 3 dans lequel, lorsqu'un nœud routeur
(2,3) reçoit un paquet de données multicast émis par un nœud routeur (2, 3) de type source, il consulte sa deuxième table d'association pour vérifier si l'une de ses entrées correspond aux champs [adresse de l'hôte], [type de l'hôte=source], et [adresse IP multicast] déduits du paquet multicast reçu, et,
« Si c'est le cas, le nœud routeur vérifie le statut associé à l'entrée trouvée,
- si le statut associé à l'entrée trouvée est CANDI DAT_MER le nœud routeur (2,3) diffuse en multicast avec portée locale un message d'annonce comprenant le statut CANDIDAT_MER ainsi que les champs [adresse IP de l'hôte], [type de l'hôte =source], [adresse IP multicast],
- si le statut associé à l'entrée trouvée est PENDING, le nœud routeur (2,3) mémorise le paquet multicast reçu,
- si le statut associé à l'entrée trouvée est MER, le nœud routeur (2,3) transfère le paquet reçu dans l'arbre multicast,
- si le statut associé à l'entrée trouvée est NON_MER, le nœud routeur
(2,3) ignore le paquet multicast reçu.
• Si ce n'est pas le cas, le nœud routeur (2,3):
- génère une nouvelle entrée dans sa deuxième table d'association contenant les champs [adresse IP de l'hôte], [type de l'hôte =source], [adresse IP multicast] déduits du paquet multicast reçu,
- met son statut correspondant à l'entrée ajoutée à CANDIDAT_MER, et,
- associe ce statut à un champ [lifetime_statut] et à un champ [lifetime_table_entry] contenant chacun une valeur non nulle, puis, - diffuse, en multicast avec portée locale, un message d'annonce comportant le statut CANDIDAT_MER ainsi que les champs [adresse IP de l'hôte], [type de l'hôte = récepteur], [adresse IP multicast].
10. Procédé selon la revendication 9 dans lequel, à la réception par un nœud routeur (2,3) d'un message de réponse MER_Reply transmis par le nœud racine (4) et comportant un statut NON_MER, ledit nœud routeur (2,3):
- vérifie s'il existe dans la deuxième table d'association un nœud hôte (6,8) concerné par le message de réponse MER_Reply reçu;
- Si oui, le nœud routeur (2,3) met son statut vis-à-vis du nœud hôte concerné à NON_MER, et,
- remplace la valeur du champ [lifetime_table_entry] par celle indiquée dans le message MER_Reply reçu.
- Supprime de sa mémoire tout le packet de données multicast associé à ladite entrée.
11. Procédé selon la revendication 9 dans lequel, à la réception par un nœud routeur (2,3) d'un message de réponse MER_Reply transmis par le nœud racine (4) et comportant un statut MER, ledit nœud routeur (2,3): - vérifie s'il existe dans la deuxième table d'association un nœud hôte
(6,8) concerné par le MER_Reply reçu,
- Si oui, ledit nœud routeur (2,3) met son statut vis-à-vis du nœud hôte concerné à MER, et,
- remplace la durée de vie de son statut vis-à-vis du nœud hôte (6,8) concerné par celle indiquée dans le message MER_Reply reçu, et,
- diffuse, en multicast avec portée locale, un message d'annonce comportant le statut MER ainsi que les champs [adresse IP de l'hôte], [type de l'hôte = récepteur], [adresse IP multicast] de manière à permettre aux nœuds routeurs (2,3) en portée radio directe et ayant une entrée correspondant aux champs [adresse IP de l'hôte], [type de l'hôte =source] et [adresse IP multicast]" marquée avec le statut NON_MER de mettre à jour la valeur du champ [lifetime_table_entry] de cette entrée sur la base de celle qui est indiquée dans le message d'annonce.
12. Procédé selon la revendication 9 dans lequel, si au niveau d'un nœud routeur (2,3) donné le statut associée à une entrée donnée correspondant aux champs [adresse IP de l'hôte], [type de l'hôte =source], [adresse IP multicast] est CANDIDAT_MER et si la durée indiquée dans le champ [lifetime_statut] associé à cette entrée expire, ledit nœud routeur (2,3) passe en statut PENDING pour ladite entrée et transmet au nœud racine (4) un message MER_Request.
13. Procédé selon la revendication 9 dans lequel, si au niveau d'un nœud routeur (2,3) donné, la valeur du champ [lifetime_table_entry] associée à une entrée donnée correspondant aux champs [adresse IP de l'hôte], [type de l'hôte =source], [adresse IP multicast] déduits du paquet de données reçu expire, ledit routeur supprime ladite entrée de sa table d'association.
14. Procédé de présélection d'un sous-ensemble de nœuds routeurs
(2,3) dans un réseau LLN (Lower power and Lossy channel Network) parmi un ensemble de nœuds susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes (6,8), ledit réseau LLN comportant un nœud racine (4) chargé de gérer une première table contenant une liste de nœuds routeurs (2,3) autorisés à transférer des paquets multicast du réseau LLN vers un nœuds routeurs (2,3) donné ou d'un nœuds routeurs (2,3) donnée vers le réseau LLN, chaque nœud routeur ayant un statut parmi l'un des statuts suivants :
■ Candidat_Mer (Multicast Edge Router), indiquant que ledit nœud routeur est candidat pour agir comme unique routeur pour un nœud hôte (6,8) donné; ■ NON_Candidat_Mer (M ulticast Edge Router), indiquant que ledit nœud routeur n'est pas candidat pour agir comme unique routeur pour un nœud hôte (6,8) donné;
Procédé caractérisé en ce que chaque nœud routeur (2,3) transmet aux autres nœuds routeurs du réseau LLN en sa portée radio directe un message d'annonce comportant une information ayant une valeur sur la base de laquelle sera conduite la configuration des autres nœuds routeurs (2,3) en tant que CANDI DAT_M ER ou NON_CAN DI DAT_M ER, et, à la réception dudit message d'annonce, chacun desdits autres nœuds routeurs compare la valeur de sa propre information à celle contenue dans le message d'annonce, et, si la valeur de l'information contenue dans le message d'annonce est inférieure à la valeur de l'information du nœud routeur ayant reçu ledit message d'annonce, alors ce dernier se met dans l'état NON_CANDIDAT_M ER, sinon, le nœud routeur ayant reçu ledit message d'annonce reste dans l'état CANDI DAT_M ER.
15. Procédé selon la revendication 14 dans lequel, chaque nœud routeur ayant un statut NON_CANDIDAT M ER comporte une table de transfert permettant de gérer les échanges des paquets multicast entre un nœud routeur (2,3) et un nœud (6,8) hôte ladite, table de transfert comportant les champs suivants:
■ Le champ « adresse de l'hôte » destiné à contenir l'adresse du nœud hôte;
■ le champ optionnel [type de l'hôte] destiné à contenir le type dudit nœud hôte (6,8) parmi l'un des deux types suivants, source ou récepteur;
■ le champ optionnel [adresse IP multicast] destiné à contenir l'adresse d'un groupe multicast auquel appartient le nœud hôte;
■ le champ « Adresse MAC_x » : destiné à contenir l'adresse MAC du nœud duquel a été reçu le paquet multicast ou le message M LD Report
■ Le champ Lifetime_table_entry destiné à contenir une durée de vie de l'entrée associée au nœud hôte (6,8) dans ladite table de transfert;
16. Procédé selon la revendication 14 dans lequel, chaque nœud routeur (2,3) comporte une table des annonces contenant les routeurs voisins desquels il a reçu un message d'annonce, de sorte qu'à chaque fois qu'un nœud routeur NON_CANDIDAT_MER reçoit un message d'annonce d'un nouveau nœud routeur qui n'est pas répertorié dans sa table des annonces, ledit routeur NON_CANDIDAT_MER ajoute l'adresse MAC dudit nouveau nœud routeur dans ladite table des annonces, compare l'adresse MAC du nouveau nœud routeur à l'adresse MAC du nœud routeur CANDIDAT_MER courant indiquée dans sa table des annonces, et si l'adresse IP du nouveau nœud routeur est inférieure à celle du nœud routeur CANDIDAT_MER courant, ledit nœud routeur NON_CANDIDAT_MER considère que c'est le nouveau nœud routeur qui est nouveau CANDIDAT_MER et met sa table des annonces à jour en conséquence.
17. Procédé selon la revendication 16 dans lequel, lorsqu'un nœud routeur (2,3) reçoit une requête de souscription à un groupe multicast d'un nœuds hôte (8) de type récepteur, il consulte sa deuxième table d'association pour vérifier s'il a déjà reçu une même requête de souscription et,
■ Si c'est le cas, la requête est ignoré,
■ Sinon, le nœud routeur (2,3):
• génère une nouvelle entrée dans sa table de transfert contenant les champs adresse IP de l'hôte, [type de l'hôte =récepteur], [adresse IP multicast] déduits de la requête de souscription reçue,
• associe à cette entrée le champ « Adresse MAC_x » qui contient l'adresse MAC du nœud duquel a été reçue la requête de souscription,
• associe à cette entrée un champ lifetime_table_entry contenant une valeur non nulle, et,
si ledit nœud routeur (2,3) est dans l'état CANDIDAT_MER, il mémorise le message reçu dans de la requête de souscription et, traduit ce message en un message MER_Request, puis transmet ledit message MER_Request au nœud racine;
■ Si le ledit nœud routeur (2,3) est dans l'état NON_CANDIDAT_MER, il transfère ledit message au nœud CANDI DAT_MER indiqué dans sa table des annonces.
18. Procédé selon la revendication 16 dans lequel, lorsqu'un nœud routeur (2,3) reçoit un paquet de données multicast émis par un nœud hôte (6) de type source, il consulte sa table de transfert pour vérifier si l'une de ses entrées correspond aux champs [adresse de l'hôte], [type de l'hôte=source], et [adresse IP multicast] déduits du paquet multicast reçu, et,
- Si ce n'est pas le cas, le nœud routeur (2,3):
- génère une nouvelle entrée dans sa table de transfert contenant les champs adresse IP de l'hôte, [type de l'hôte =source], [adresse IP multicast] déduits du paquet multicast reçu,
- associe à l'entrée ajoutée un champ « Adresse MAC_x » contenant l'adresse MAC du nœud duquel a été reçu le paquet multicast et un champ lifetime_table_entry contenant une valeur non nulle, et,
si ledit nœud routeur (2,3) est de type CANDI DAT_MER, il mémorise le paquet de données reçu, et transmet un message MER_Request au nœud racine;
■ si ledit nœud routeur (2,3) est de type NON_CANDIDAT_MER, il transfère le paquet multicast reçu à son routeur CANDIDAT_MER indiqué dans sa table des annonces.
19. Dispositif de présélection d'un routeur dans un réseau LLN (Lower power and Lossy channel Network) parmi une pluralité de nœuds (2,3) susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes (6,8), ledit réseau LLN comportant un nœud racine (4) chargé de gérer une première table destinée à mémoriser pour chaque nœud routeur (2,3) un statut parmi l'un des statuts suivants :
■ Candidat_Mer (M ulticast Edge Router), indiquant que le dit nœud routeur (2, 3) est candidat pour agir comme unique routeur pour un nœud hôte (6,8) donné;
■ PEN DI NG indiquant que le nœud routeur (2, 3) est en attente d'être sélectionné comme unique routeur pour ledit nœud hôte,
■ M ER, indiquant que ledit nœud routeur est configuré en tant qu'unique routeur pour ledit nœud hôte,
dispositif caractérisé en ce que :
- ledit nœud routeur (2,3) est adapté pour transmettre aux autres nœuds routeurs (2,3) du réseau LLN en portée radio directe dudit nœuds routeurs (2,3) un message d'annonce comportant son statut vis-à-vis du nœud hôte (6,8) et l'adresse dudit nœuds routeurs (2,3) à la réception par d'un paquet de données ou d'un message de type M LD (pour M ulticast Listener Discovery) Report provenant d'un nœud hôte (6, 8) donné, et, chacun desdits autres nœuds routeurs (2,3) est adapté pour comparer son statut courant vis-à-vis dudit nœud hôte (6,8) au statut indiqué dans le message d'annonce, et pour configurer son statut en fonction de ladite comparaison de sorte qu'un seul nœud parmi les nœuds du réseau LLN en portée radio directe dudit nœuds routeurs (2,3) transmette au nœud racine une requête M ER_Request de configuration en tant que routeur multicast pour les données en provenance ou à destination dudit nœuds routeurs (2,3) donné, et en ce que, le nœud racine (4) est adapté pour accorder le statut M ER pour ledit nœuds routeurs (2,3) au premier nœud routeur (2,3) lui ayant transmis une requête M ER_Request en réponse audit message d'annonce.
20. Dispositif de présélection d'un sous-ensemble de nœuds routeurs (2,3) dans un réseau LLN (Lower power and Lossy channel Network) parmi un ensemble de nœuds susceptibles d'agir comme routeurs de paquets de données échangés entre une pluralité de nœuds hôtes (6,8), ledit réseau LLN comportant un nœud racine (4) chargé de gérer une première table destinée à mémoriser pour chaque nœud routeur un statut parmi l'un des statuts suivants :
■ Candidat_Mer (Multicast Edge Router), indiquant que ledit nœud routeur est candidat pour agir comme unique routeur pour un nœud hôte (6,8) donné;
■ NON_Candidat_Mer (Multicast Edge Router), indiquant que ledit nœud routeur n'est pas candidat pour agir comme unique routeur pour un nœud hôte (6,8);
dispositif caractérisé en ce que chaque nœud routeur est adapté pour transmettre aux autres nœuds routeurs (2,3) du réseau LLN en sa portée radio directe un message d'annonce comportant une information ayant une valeur sur la base de laquelle sera conduite la configuration des nœuds routeurs (2,3) en tant que CANDIDAT_MER ou NON_CANDIDAT_MER, et, chacun desdits autres nœuds routeurs (2,3) est adapté pour comparer la valeur de sa propre information à celle contenue dans le message d'annonce, de sorte que si la valeur de l'information contenue dans le message d'annonce est inférieure à la valeur de l'information du nœud routeur ayant reçu ledit message d'annonce, alors ce dernier se met dans l'état NON_CANDIDAT_MER, sinon, il reste dans l'état CANDIDAT_MER.
21. Programme d'ordinateur mémorisé sur un support d'enregistrement et comportant des instructions pour réaliser les étapes du procédé selon l'une des revendications 1 à 18 et les étapes du procédé selon l'une des revendications 14 à 18 lorsqu'il est exécuté sur un ordinateur.
EP13707177.5A 2012-03-07 2013-03-05 Procede de préselection d'un routeur dans un reseau rpl Withdrawn EP2823609A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1252077A FR2987964B1 (fr) 2012-03-07 2012-03-07 Procede de preselection d'un routeur dans un reseau rpl
PCT/EP2013/054316 WO2013131867A1 (fr) 2012-03-07 2013-03-05 Procede de préselection d'un routeur dans un reseau rpl

Publications (1)

Publication Number Publication Date
EP2823609A1 true EP2823609A1 (fr) 2015-01-14

Family

ID=47780076

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13707177.5A Withdrawn EP2823609A1 (fr) 2012-03-07 2013-03-05 Procede de préselection d'un routeur dans un reseau rpl

Country Status (4)

Country Link
US (1) US20150304118A1 (fr)
EP (1) EP2823609A1 (fr)
FR (1) FR2987964B1 (fr)
WO (1) WO2013131867A1 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104023317B (zh) * 2014-06-17 2019-02-01 中国科学院计算技术研究所 一种低功耗多播路由网络及其多播路由方法
US20160021515A1 (en) * 2014-07-18 2016-01-21 Samsung Electro-Mechanics Co., Ltd. Electronic shelf label gateway, electronic shelf label system and communications method thereof
US10277686B2 (en) * 2015-07-29 2019-04-30 Cisco Technology, Inc. Service discovery optimization in a network based on bloom filter
CN113365294A (zh) * 2015-08-28 2021-09-07 德克萨斯仪器股份有限公司 用于有向无环图网络配置的节点和方法
WO2017141076A1 (fr) * 2016-02-19 2017-08-24 Telefonaktiebolaget Lm Ericsson (Publ) Protocole multidiffusion sans état destiné aux réseaux avec perte et de faible puissance
US9615266B1 (en) * 2016-04-04 2017-04-04 Cisco Technology, Inc. Networking device with an electronically steerable directional antenna array
EP3725035A1 (fr) * 2017-12-12 2020-10-21 Nokia Solutions and Networks Oy Procédé, système et appareil de gestion de session de multidiffusion dans un réseau de communication 5g
US20190229930A1 (en) * 2018-01-24 2019-07-25 Comcast Cable Communications, Llc Blockchain for the connected home
US10904778B1 (en) * 2020-03-04 2021-01-26 Cisco Technology, Inc. Detection and deduction of urgent messages in low power and lossy networks
CN113242586A (zh) * 2021-04-25 2021-08-10 重庆邮电大学 一种可靠的基于链路节能的移动性rpl路由方法
CN114374989A (zh) * 2021-11-30 2022-04-19 深圳市联洲国际技术有限公司 基于强化学习优化组网的方法、装置及系统
CN115426245B (zh) * 2022-08-29 2024-02-02 上海云轴信息科技有限公司 云平台网络故障自动检测方法、设备及计算机可读介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE1052489B (de) 1956-04-09 1959-03-12 Grubenlampenwerke Veb Alkalische Akkumulatorenbatterie aus Einzel- oder Doppelzellen
US7911977B2 (en) * 2005-05-31 2011-03-22 Cisco Technology, Inc. Designated router assignment per multicast group address/range
US8761183B2 (en) * 2006-12-20 2014-06-24 Verizon Patent And Licensing Inc. System and method for core network topology router placement planning
US8289883B2 (en) * 2007-12-21 2012-10-16 Samsung Electronics Co., Ltd. Hybrid multicast routing protocol for wireless mesh networks
US8937886B2 (en) * 2010-12-17 2015-01-20 Cisco Technology, Inc. Dynamic reroute scheduling in a directed acyclic graph (DAG)
US8595359B2 (en) * 2011-03-08 2013-11-26 Cisco Technology, Inc. Efficient message distribution for directed acyclic graphs
US8654649B2 (en) * 2011-07-27 2014-02-18 Cisco Technology, Inc. Reduced topology routing in shared media communication networks

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2013131867A1 (fr) 2013-09-12
FR2987964A1 (fr) 2013-09-13
FR2987964B1 (fr) 2014-05-09
US20150304118A1 (en) 2015-10-22

Similar Documents

Publication Publication Date Title
EP2823609A1 (fr) Procede de préselection d&#39;un routeur dans un reseau rpl
FR2978003A1 (fr) Procede de routage d&#39;un flux en mode non-stockage
CN102291320B (zh) Mac地址学习方法和边缘设备
WO2005060187A1 (fr) Systeme de groupes, element de groupe, procede et programme pour recuperer des defaillances
WO2008129536A2 (fr) Appareil, système et procédé de distribution de contenu numérique
EP2504950B1 (fr) Controle d&#39;admission pour abonnement de service
FR2917554A1 (fr) Dispositif de gestion de reception par des terminaux de contenus multimedia transmis par des infrastructures mettant en oeuvre des techniques de transmission differentes
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
WO2009071597A2 (fr) Procede d&#39;acheminement de messages sur un reseau et systeme de mise en oeuvre du procede
EP2823608B1 (fr) Procédé, dispositif et programme d&#39;ordinateur pour sélectionner un noeud routeur dans un réseau lln
EP2887743A1 (fr) Procédé de communication dans un réseau de télécommunications sans fil, programme d&#39;ordinateur et noeud de communication sans fil associés
WO2019106259A1 (fr) Procédé de configuration destiné à être mis en œuvre dans un réseau utilisant un protocole de routage dynamique
EP2997717A1 (fr) Procede et dispositif de selection d&#39;interface de communication
WO2015044565A1 (fr) Procédés de configuration et de gestion d&#39;un réseau ip, dispositifs et programmes d&#39;ordinateur correspondants
EP1654830B1 (fr) Procede de diffusion d&#39;information multicast etendue, systeme et produit logiciel correspondant
US20170033977A1 (en) Method, device and system for processing failure of network service node
FR3052942B1 (fr) Procede de dissemination de donnees dans un reseau maille
EP2847939A1 (fr) Systeme de transmission de donnees
FR2879881A1 (fr) Systeme de procede de gestion des ressources d&#39;un reseau mobile large bande comportant des acces fixes prolonges par des bornes d&#39;acces de reseau local sans fil
EP3506564A1 (fr) Procédé de routage ip multicast dynamique dans un réseau ad-hoc
EP2835954B1 (fr) Procédé de traitement, dans un réseau ad hoc de radiocommunication, stations de radiocommunication et programmes d&#39;ordinateur correspondants
EP3785463B1 (fr) Procédé de fédération d&#39;au moins deux réseaux de communication pour terminaux mobiles et réseau apte à être fédéré
FR3124681A1 (fr) Procédé de traitement d’une connexion entre un équipement utilisateur et un équipement distant dans un réseau de communication, procédé de contrôle, dispositifs, satellite, station terrestre, système et programmes d’ordinateur correspondants.
EP4142251A1 (fr) Procede de traitement d&#39;une requete d&#39;interet dans un reseau ndn

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: 20140908

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

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
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: 20150425