NOEUD

ROUTEUR DANS UN RÉSEAU LLN

DESCRIPTION

DOMAINE TECHNIQUE

L'invention se situe dans le contexte de multidiffusion (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 sélection d'un nœud routeur dans un réseau de télécommunications de type LLN (Low power and Lossy Network) par exemple comportant une pluralité de nœuds susceptibles d'agir comme routeurs de paquets de données en provenance ou à destination d'au moins un nœud hôte appartenant à un groupe de nœuds multicast susceptibles d'émettre et/ou de recevoir des paquets de données à travers ledit réseau LLN, ce dernier comportant en outre un nœud racine comportant une première table destinée à mémoriser des associations entre au moins un nœud routeur et au moins un nœud hôte d'un groupe multicast.

L'invention concerne également un dispositif et un programme d'ordinateur aptes à mettre en œuvre le procédé selon l'invention.

ÉTAT DE LA TECHNIQUE ANTÉRIEURE

La duplication des paquets de données échangés lors de communications de type multicast dans des réseaux de type LLN (Low power and Lossy Network) a pour effet d'engendrer un gaspillage des ressources telle que la bande passante, la capacité de calcul, l'espace mémoire et la réserve d'énergie qui sont, par essence, 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 (niveau lien du modèle OSI ; par exemple niveau MAC (pour Media Access Control)) de type broadcast, ce qui est souvent le cas dans les réseaux informatiques y compris dans les réseaux LLNs.

Dans le contexte d'un réseau 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 RPL. Cette situation correspond au cas où le nœud n'a pas d'information sur les nœuds du réseau RPL, ou n'implémente pas les fonctionnalités RPL. Un tel nœud peut être, par exemple, un nœud sans batterie et récupérant l'énergie nécessaire à la transmission d'un message, par exemple, d'une commande à 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 IP multicast sur une trame niveau 2 de type Broadcast qui sera reçue 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 (au niveau 2, cela pourrait se faire en unicast ou en broadcast) 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 duplications 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 assez 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 dans une trame 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]). Même si la requête du nœud destinataire a une portée locale au sens IP (link ocal 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 à portée directe du nœud destinataire. 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é.

Le but de l'invention est de pallier les inconvénients de l'art antérieur décrit ci-dessus.

EXPOSÉ DE L'INVENTION

Ce but est atteint au moyen d'un procédé de sélection d'un nœud routeur dans un réseau de télécommunications de type LLN (Lower power and Lossy channel Network), par exemple, comportant une pluralité de nœuds routeurs susceptibles d'agir comme routeurs de paquets de données en provenance ou à destination d'au moins un nœud hôte appartenant à un groupe de nœuds multicast susceptibles d'émettre et/ou de recevoir des paquets de données à travers ledit réseau, et un nœud racine comportant une première table destinée à mémoriser des associations entre au moins un nœud routeur et au moins un nœud hôte d'un groupe multicast.

Le procédé selon l'invention comporte les étapes suivantes:

- à la réception par un nœud routeur d'un paquet de données multicast provenant d'un nœud hôte ou d'une requête d'adhésion à un groupe multicast provenant d'un nœud hôte, ledit nœud routeur transmet au nœud racine une requête MER_Request (pour Multicast Edge Router Request) de configuration en tant que nœud routeur multicast pour servir ledit nœud hôte, et,

- à la réception de la requête MER_Request, le nœud racine détermine à partir de ladite première table d'association une configuration du nœud routeur et,

- transmet audit nœud routeur un message de réponse MER_Reply comportant la configuration déterminée.

La requête MER_Request est par exemple un message de type DAO (pour Destination Avertissement Object).

Préférentiellement, la requête MER_Request comporte l'adresse dudit nœud hôte, et le message de réponse MER_Reply comporte l'adresse dudit nœud hôte, et une durée de la configuration déterminée pour le nœud routeur vis-à-vis du nœud hôte.

Optionnellement, la requête MER_Request comporte l'adresse du groupe multicast auquel est associé ledit nœud hôte.

Selon l'invention, la configuration du nœud routeur consiste à lui attribuer l'un des statuts suivants:

• PENDING : indiquant que ledit nœud routeur est en attente d'être configuré par le nœud racine,

· MER (Multicast Edge Router): indiquant que ledit nœud routeur est configuré en tant qu'unique routeur multicast pour le nœud hôte,

• NON_MER: indiquant que le nœud routeur n'est pas configuré en tant que routeur multicast pour le nœud hôte.

Dans un mode préféré de réalisation, le procédé selon la revendication comporte en outre une étape consistant à configurer dans chaque nœud routeur une deuxième table d'association comportant les informations suivantes :

- l'adresse du nœud hôte source du paquet de données multicast ou de la requête d'adhésion à un groupe multicast reçu par le nœud routeur;

- un statut du nœud routeur vis-à-vis dudit nœud hôte parmi l'un des statuts PENDING, MER, ou NON_MER. - une durée de vie du statut du nœud routeur vis-à-vis du nœud hôte. Ladite deuxième table d'association comporte en outre les informations suivantes :

- le type du nœud hôte indiquant si le nœud hôte est source des paquets de données multicast reçus par le nœud routeur ou destinataire des paquets de données multicast reçus par le nœud routeur (c.à.d. source d'une requête d'adhésion au groupe multicast);

- l'adresse du groupe multicast auquel est associé le nœud hôte.

Notons que la fonction du nœud routeur MER vis-à-vis d'un nœud hôte varie selon les informations contenues dans la deuxième table d'association dudit nœud hôte. Plus précisément cette fonction se décline selon quatre variantes possibles qui dépendent de l'utilisation ou non des champs optionnels [type de l'hôte] et [adresse multicast] dans les échanges MER_Request/Reply et les diagrammes d'état au niveau des nœuds routeurs et du nœud racine.

- Cas 1 : les champs [type de l'hôte] et [adresse multicast] ne sont PAS utilisés : dans ce cas, un nœud routeur avec statut MER vis-à-vis d'un nœud hôte signifie que ce nœud routeur est configuré comme routeur multicast pour ce nœud hôte, pour tout groupe multicast et quel que soit le rôle du nœud hôte dans chacun de ces groupes (source et/ou destination des paquets de données). Ainsi, par exemple, si le statut MER a été configuré suite à une demande d'adhésion à un groupe multicast #1 par le nœud hôte (cas d'un nœud hôte « destinataire ») le même nœud routeur avec statut MER servira aussi (automatiquement) de routeur multicast pour ce nœud hôte s'il est source d'un autre groupe multicast #2... une interaction avec le nœud racine via des messages MER_Request/Reply n'est alors pas nécessaire pour ce second groupe multicast.

- Cas 2 : les champs [type de l'hôte] et [adresse multicast] sont utilisés tous les deux: dans ce cas, un nœud routeur avec statut MER vis-à-vis d'un nœud hôte signifie que ce nœud routeur est configuré comme routeur multicast pour ce nœud hôte pour le groupe multicast dont l'adresse est contenue dans le champ [adresse multicast] et pour un rôle donné, source ou destination des paquets de données, de ce nœud hôte vis-à-vis de ce groupe multicast. Ainsi, il est potentiellement possible dans ce cas qu'un nœud hôte soit servi par différents nœuds routeurs MER pour des groupes multicast et/ou des rôles (source/destination) du nœud hôte différents.

- Cas 3 : le champ [type de l'hôte] n'est pas utilisé mais le champ [adresse multicast] est utilisé: dans ce cas, un nœud routeur avec statut MER vis-à-vis d'un nœud hôte signifie que ce nœud routeur est configuré comme routeur multicast pour ce nœud hôte pour le groupe multicast donné dont l'adresse est contenue dans le champ [adresse multicast] et ce quel que soit le rôle (source et/ou destination des paquets de données) du nœud hôte vis-à-vis de ce groupe multicast.

- Cas 4 : le champ [type de l'hôte] est utilisé mais le champ [adresse multicast] n'est pas utilisé : dans ce cas, un nœud routeur avec statut MER vis-à-vis d'un nœud hôte signifie que ce nœud routeur est configuré comme routeur multicast pour ce nœud hôte pour tout groupe multicast mais uniquement pour un rôle donné, source ou destination des paquets de données, du nœud hôte vis-à-vis de ce groupe multicast. Dans une première variante de mise en œuvre du procédé selon l'invention, lorsque le nœud hôte est source des paquets de données reçus par un nœud routeur ayant un statut MER vis-à-vis dudit nœud hôte, ce nœud routeur intercepte tous les paquets multicast émis par ledit nœud hôte et les re-route dans le réseau, et lorsque le nœud hôte est destinataire des paquets de données reçus par ledit nœud routeur, ce dernier intercepte les requêtes d'adhésion à un groupe multicast émises par ledit nœud hôte et déclenche la création, pour ledit groupe multicast, d'une branche de routage multicast dans ledit réseau.

Le procédé selon l'invention comporte en outre une étape de gestion de ladite deuxième table d'association dans laquelle, à la réception par le nœud routeur d'un paquet de données multicast comportant une adresse d'un nouveau nœud hôte source de paquets de données, ledit nœud routeur :

- enregistre dans ladite deuxième table d'association l'adresse dudit nouveau nœud hôte, une valeur PENDING pour le statut du nœud routeur vis-à-vis de ce nouveau nœud hôte, et une valeur non nulle pour la durée de vie du statut du nœud routeur vis-à-vis du nouveau nœud hôte, - génère un message MER_Request comportant l'adresse du nouveau nœud hôte, et optionnellement l'adresse du groupe multicast auquel est associé ce nouveau nœud hôte et le type du nœud hôte vis-à-vis du groupe multicast (dans ce cas de type «source »), et,

- transmet le message MER_Request généré au nœud racine.

Et, à la réception par le nœud routeur d'une requête d'adhésion à un groupe multicast provenant d'un nouveau nœud hôte, ledit nœud routeur :

- enregistre dans ladite deuxième table d'association l'adresse du nouveau nœud hôte, une valeur PENDING pour le statut dudit nœud routeur vis-à-vis de ce nouveau nœud hôte et une valeur non nulle pour la durée de vie du statut du nœud routeur vis-à-vis du nouveau nœud hôte,

- génère un message MER_Request comportant l'adresse du nouveau nœud hôte, et optionnellement l'adresse du groupe multicast auquel ce nouveau nœud hôte souhaite s'inscrire et le type du nœud hôte vis-à-vis du groupe multicast (dans ce cas de type « destination »), et,

- transmet le message MER_Request généré au nœud racine.

Dans les deux cas, le nœud routeur stocke le paquet (données ou requête d'adhésion) reçu en attendant une réponse MER_Reply du nœud racine si sa mémoire disponible le permet.

Selon une autre caractéristique du procédé de l'invention, dans le cas où le nœud routeur reçoit un message de réponse MER_Reply comportant un statut NON_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 de réponse MER_Reply reçu;

- Si oui, met son statut vis-à-vis du nœud hôte concerné à NON_MER, et,

- remplace la valeur de la durée de vie du statut du nœud routeur vis-à- vis du nœud hôte concerné par celle indiquée dans le message MER_Reply reçu.

Par ailleurs, si le nœud hôte concerné par le message MER_Reply est source du paquet de données reçu par le nœud routeur, ce dernier supprime de sa mémoire les paquets de données préalablement stockés pendant la phase d'attente de la réponse MER_Reply, et si ledit nœud hôte est destinataire du paquet de données reçu par le nœud routeur, ce dernier supprime le message reçu du nœud destinataire préalablement stocké (c.à.d. il supprime la requête d'adhésion au groupe multicast). Si le nœud routeur reçoit un message de réponse MER_Reply comportant un statut MER ledit nœud routeur :

- vérifie s'il existe dans la deuxième table d'association une entrée avec un nœud hôte concerné par le MER_Reply reçu,

- Si oui, ledit nœud routeur met son statut vis-à-vis du nœud hôte concerné à MER, et,

- remplace la durée de vie du statut du nœud routeur vis-à-vis du nœud hôte concerné par celle indiquée dans le message MER_Reply reçu.

Et, si le nœud hôte concerné par le message MER_Reply est source du paquet de données reçu par le nœud routeur, ce dernier re-route lesdits paquets à travers le réseau, et si ledit nœud hôte est destinataires desdits paquets, (c.à.d. lorsque le nœud routeur reçoit dudit nœud hôte une requête d'adhésion à un groupe multicast, le nœud routeur établit avec le réseau une branche multicast qui véhiculera les paquets multicast à destination dudit nœud hôte.

Par contre, si aucun nœud hôte de la deuxième table d'association n'est concerné par le message de réponse MER_Reply transmis par le nœud racine, ledit nœud routeur ignore le message reçu du nœud racine.

Dans tous les cas, le nœud routeur supprime l'entrée correspondant au message MER_Reply de la deuxième table d'association lorsque la durée de vie de son statut vis-à-vis d'un nœud hôte expire. Le procédé selon l'invention comporte en outre une étape de gestion de ladite première table d'association dans laquelle, du côté du nœud racine, à la réception par ce nœud racine du message MER_Request, ledit nœud racine vérifie si le message reçu correspond à une entrée préalablement mémorisée dans la première table d'association et, si le message provient d'un nœud routeur différent de celui qui est inscrit pour ladite entrée, le nœud racine envoie audit nœud routeur un message MER_Reply comportant les mêmes informations que celles mentionnées dans le message MER_Request avec un statut NON_MER pour ce routeur vis-à-vis du nœud hôte mentionné dans le message reçu, et la durée de vie restante de ladite entrée.

Selon une autre caractéristique du procédé de l'invention, pour la gestion de ladite première table d'association, si le message MER_Request reçu par le nœud racine ne correspond à aucune entrée préalablement mémorisée dans la première table d'association, ledit nœud racine ajoute une nouvelle entrée dans ladite première table d'association comportant, outre les informations contenues dans le message MER_Request, une durée de vie non nulle pour l'entrée ajoutée et un statut MER pour le nœud routeur vis-à-vis du nœud hôte mentionné dans le message reçu, ainsi que l'adresse dudit nœud routeur MER..

Le procédé selon l'invention est mis en œuvre par un dispositif de sélection d'un nœud routeur dans un réseau de télécommunications de type LLN (Low power and Lossy Network), par exemple, comportant une pluralité de nœuds routeurs susceptibles d'agir comme routeurs de paquets de données en provenance ou à destination d'au moins un nœud hôte appartenant à un groupe multicast susceptible d'émettre et/ou de recevoir des paquets de données à travers ledit réseau, un nœud racine comportant une première table destinée à mémoriser des associations entre au moins un nœud routeur et au moins un nœud hôte du groupe multicast.

Selon l'invention, chaque nœud routeur de ce dispositif est apte à transmettre au nœud racine une requête MER_Request (pour Multicast Edge Router Request) de configuration en tant que nœud routeur, et, le nœud racine de ce dispositif est apte à déterminer à partir de ladite première table d'association une configuration du nœud routeur et à transmettre audit nœud routeur un message de réponse MER_Reply comportant la configuration déterminée. 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 schématiquement les étapes du procédé selon l'invention exécutées au niveau d'un nœud routeur dans un réseau LLN pour configurer ce nœud routeur.

- la figure 2 illustre schématiquement les étapes du procédé selon l'invention exécutées au niveau du nœud racine d'un réseau LLN pour configurer un nœud routeur dans ce réseau.

- la figure 3 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 dans un réseau RPL selon l'invention ;

- la figure 4 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 dans un réseau RPL 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 Low power and Lossy Network) comportant une pluralité de nœuds RPL (pour Routing Protocol for LLN) (2, 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 chaque nœud RPL et au moins un nœud hôte (6, 8) d'un groupe multicast. Le 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 6 de paquets de données par le terme «source», et un nœud hôte destinataire 8 de paquets de données par le terme « récepteur». 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 en portée directe des nœuds hôtes (6, 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 (2, 3) 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 RPL multicast pour ledit nœud hôte (6, 8).

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.

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 est configuré pour mémoriser un statut qui peut avoir l'une des trois valeurs possibles:

^■ MER: le nœud RPL est un routeur MER pour une source ou un destinataire donné ;

^■ NON_MER : le nœud RPL n'est pas un routeur MER pour une source ou un destinataire donné; ^■ PENDING: le nœud RPL a envoyé une demande de statut MER au nœud racine 4 (MER_Request) et est en attente d'une réponse (MER_Reply) du nœud racine 4.

Le statut d'un nœud RPL 2, 3 vis-à-vis d'un nœud hôte est inscrit dans une entrée d'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: PENDING, MER, ou NON_MER,

La figure 1 illustre les étapes de la procédure de sélection d'un MER exécutées au niveau d'un nœud RPL (2, 3) en portée radio directe d'une source 6 ou d'un récepteur 8 dans le réseau LLN recevant un paquet de données multicast émis par la source 6 ou une requête d'adhésion à un groupe multicast provenant du récepteur 8. Dans l'exemple décrit ci-après, les champs optionnels [type de l'hôte] et [adresse multicast] sont utilisés.

A l'étape 10, le nœud RPL (2, 3) reçoit le paquet multicast comportant des données utiles ou une requête d'adhésion à un groupe multicast (p. ex. via un message MLD). A l'étape 12, le nœud RPL (2, 3) vérifie si le paquet reçu est une requête d'adhésion à un groupe multicast (p. ex. un message du type MLD (Multicast Listener Discovery) Report ou non).

Dans le cas où le paquet reçu est une requête d'adhésion à un groupe multicast de type MLD Report par exemple), à l'étape 14, le nœud RPL (2, 3) construit un triplé {Adresse de l'hôte, Type de l'hôte, Adresse multicast} comprenant l'adresse du nœud hôte (6) indiquée dans le paquet reçu (c.à.d. l'adresse du nœud hôte source du paquet), en affectant la valeur 'récepteur' au champ 'Type de l'hôte' et en affectant l'adresse multicast contenue dans la requête d'adhésion au champ 'Adresse multicast'. A l'étape 16 le nœud RPL (2, 3) vérifie si une entrée avec les mêmes valeurs Adresse de l'hôte, Type de l'hôte, et Adresse Multicast que celles dérivées à partir du paquet reçu existe déjà dans la deuxième table d'association.

Dans l'affirmative, l'étape 18, consiste à déterminer à partir de la deuxième table d'association le statut du nœud RPL vis-à-vis du nœud hôte identifié dans le message (requête d'adhésion MLD) reçu.

Si le nœud RPL (2, 3) a un statut MER, l'étape 20 consiste à créer une branche de routage multicast en direction dudit nœud RPL (2, 3) pour l'entrée trouvée (c.à.d. pour l'adresse multicast correspondante) si une telle branche n'existe pas déjà et à supprimer le message d'adhésion au groupe multicast (p. ex. MLD Report) reçu de la mémoire du nœud RPL (2, 3).

Si le nœud RPL (2, 3) a un statut NON_MER, le message d'adhésion au groupe multicast (p. ex. MLD Report) est ignoré, puis supprimé (étape 22) de la mémoire du nœud RPL (2, 3).

Si le nœud RPL a un statut PENDING, l'étape 24 consiste à stocker le message d'adhésion au groupe multicast (p. ex. MLD Report) reçu dans la mémoire du nœud RPL (2, 3).

A l'étape 26, le nœud RPL (2, 3) transmet un message MER_Request au nœud racine 4, et attend la réponse MER_Reply (étapes 28-30).

Après réception d'un message MER_Reply du nœud racine 4, le statut du nœud RPL (2, 3) et la durée de vie de ce statut sont mis à jour à l'étape 32.

Si aucune entrée avec les mêmes valeurs Adresse de l'hôte, Type de l'hôte, et Adresse Multicast que celles dérivées à partir du paquet reçu n'existe dans la table d'association, à l'étape 34, une entrée est créé avec Y Adresse de l'hôte, le Type de l'hôte, et l'Adresse Multicast dérivés à partir du paquet reçu, un statut PENDING pour le nœud RPL (2, 3) vis-à-vis de l'hôte et une durée de vie de ce statut.

Le procédé se poursuit avec les étapes 24 à 32.

Dans le cas où le paquet multicast reçu n'est pas une requête d'adhésion à un groupe multicast (par exemple le paquet n'est pas un message du type MLD Report) mais est un paquet multicast de données, à l'étape 40, le nœud RPL construit un triplet {Adresse de l'hôte, Type de l'hôte, Adresse multicast} comprenant l'adresse du nœud hôte (8) indiquée dans le paquet reçu (c.à.d. l'adresse source du paquet), en affectant la valeur 'source' au champ 'type de l'hôte' et en affectant l'adresse multicast indiquée dans le paquet (c.à.d. l'adresse multicast de destination du paquet) au champ 'Adresse multicast'. A l'étape 42, le nœud RPL (2, 3) vérifie si une entrée avec les mêmes valeurs Adresse de l'hôte, Type de l'hôte, et Adresse Multicast que celles dérivées à partir du paquet reçu existe déjà dans la table d'association.

Dans l'affirmative, l'étape 44, consiste à déterminer le statut du nœud RPL vis-à-vis du nœud hôte identifié dans le message reçu à partir de la deuxième table d'association.

Si le nœud RPL a un statut MER, l'étape 46 consiste à transférer le paquet reçu vers l'arbre multicast et à supprimer le paquet multicast reçu de la mémoire du nœud RPL s'il y existe.

Si le nœud RPL a un statut NON_MER, le paquet multicast est supprimé

(étape 48) de la mémoire du nœud RPL s'il y existe.

Si le nœud RPL a un statut PENDING, l'étape 52 consiste à stocker le paquet multicast reçu dans la mémoire du nœud RPL. A l'étape 54, le nœud RPL (2, 3) transmet un message MER_Request au nœud racine 4, et attend la réponse MER_Reply (étapes 56-58).

Après réception d'un message MER_Reply du nœud racine 4, le statut du nœud RPL (2, 3) est mis à jour à l'étape 60.

La figure 2 illustre les étapes de la procédure de sélection d'un MER exécutées au niveau du nœud racine 4 suite à la réception d'un message MER_Request à partir d'un nœud RPL (2, 3).

A l'étape 70, le nœud racine 4 reçoit un message MER_Request à partir d'un nœud RPL (2, 3).

A l'étape 72, le nœud racine 4 consulte la première table d'association pour vérifier si une entrée pour le même message MER_Request existe déjà dans cette table. La vérification se base sur la comparaison des champs (adresse de l'hôte, type de l'hôte, adresse multicast) de la première table d'association avec ceux mentionnés dans le message MER_Request reçu. Si une entrée existe déjà dans la première table, le nœud racine 4 génère (étape 74) un message MER_Reply en y incluant l'adresse de l'hôte @hôte, le type de l'hôte « type_hôte », l'adresse multicast « mcast@ », et une durée de vie égale à la durée de vie restante de l'entrée trouvée. Le nœud racine 4 inclus également dans le message MER_Reply un statut qui est fonction de l'adresse de l'initiateur du message MER_Request et de l'adresse du routeur MER indiquée dans l'entrée trouvée. Si l'initiateur du message MER_Request n'est pas celui enregistré dans l'entrée trouvée, le nœud racine 4 indique un champ statut mis à NON_MER dans le message MER_Reply. Si l'initiateur du message MER_Request est le même que celui enregistré dans l'entrée trouvée, le nœud racine 4 indique un champ statut mis à MER dans le message MER_Reply. A l'étape 76, le message MER_Reply est ensuite envoyé au nœud RPL (2, 3).

Si le message MER_Request reçu par le nœud racine 4 est nouveau, c'est à dire, si les champs dudit message n'ont pas encore été enregistrés dans la première table d'association, le nœud racine 4 ajoute une nouvelle entrée (étape 78) dans ladite première table d'association comprenant les valeurs indiquées pour les champs du message MER_Request, c'est-dire, l'adresse de l'hôte et optionnellement le type de l'hôte et l'adresse multicast. Le nœud racine 4 fixe aussi la durée de vie de l'entrée ajoutée à une valeur non nulle et indique dans cette entrée l'adresse du routeur RPL (2, 3) ayant envoyé le message MER_Request comme étant l'adresse du routeur multicast sélectionné par le nœud racine 4 (c'est-à-dire le Multicast Edge Router / MER) pour ledit nœud hôte (6, 8).

A l'étape 80 le nœud racine 4 génère ensuite un message MER_Reply (par exemple un message DAO ACK si le nœud RPL a envoyé un MER_Request sous la forme d'un message DAO) et envoie ce message au nœud RPL source du MER_Request (étape 76). Le message MER_Reply contient les mêmes informations que celles mentionnées dans le message MER_Request reçu avec en plus un champ statut mis à MER et un champ durée de vie égale à la durée de vie restante de l'entrée créée. Par ailleurs, si une durée de vie d'une entrée dans la table d'association arrive à expiration, le nœud racine 4 supprime l'entrée concernée de la première table d'association.

La figure 3 illustre la séquence d'échange de messages entre deux nœuds RPL, 2 et 3, et le nœud racine 4 pour configurer un nœud RPL pour la source 6.

A l'étape 90, 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(s) nœud(s) destinataire(s) du paquet de données.

A la réception du paquet diffusé, chacun des nœuds RPL 2 et 3 enregistre dans sa deuxième table d'association une entrée contenant l'adresse de la source 6 (@S) et optionnellement le type de l'hôte ('source') et l'adresse du groupe multicast (mcast@) si une telle entrée n'existe pas déjà, et met son statut à PENDING ainsi qu'une durée de vie non nulle de cette entrée dans ladite table.

Chacun des nœuds RPL 2, 3 génère ensuite un message MER_Request, par exemple un message DAO, comportant un champ dédié à l'adresse de la source @S, un champ optionnel dédié au type de l'hôte [type d'hôte = source] et un dernier champ optionnel dédié à l'adresse multicast du groupe mcast@ et envoie (étapes 92 et 94) le message MER_Request au nœud racine 4.

Dans ce cas, chaque nœud RPL 2, 3 peut, si sa mémoire disponible le lui permet, stocker le paquet multicast reçu de la source 6 en attendant la réponse MER_Reply du nœud racine 4.

A l'étape 98, le nœud racine 4 envoie au nœud RPL 2 un message MER_Reply comportant les mêmes informations que celles mentionnées dans le message MER_Request reçu de ce nœud RPL 2 avec en plus un champ statut mis à MER et un champ lifetime indiquant la durée de vie de ce nœud RPL 2 dans ce statut.

A la réception du message MER_Reply, le nœud RPL 2 met son statut à MER dans sa deuxième table d'association, transfère le paquet de données vers l'arbre multicast, et vide sa mémoire. Parallèlement, à l'étape 100, le nœud racine 4 envoie au nœud RPL 3 un message MER_Reply comportant les mêmes informations que celles mentionnées dans le message MER_Request reçu de ce nœud RPL 3 avec en plus un champ statut mis à NON_MER et un champ lifetime indiquant la durée de vie de ce nœud RPL3 dans ce statut.

A la réception du message MER_Reply, le nœud RPL 3 met son statut à NON_MER dans sa deuxième table d'association.

Lorsque le nœud RPL 2 reçoit ultérieurement un nouveau paquet multicast de la source 4 (étape 102), il re-route (étape 102) automatiquement le paquet de données reçu vers l'arbre multicast.

Et lorsque le nœud RPL 3 reçoit ultérieurement un nouveau paquet de la source 4 (étape 104), il ignore ce paquet et vide sa mémoire.

La figure 4 illustre la séquence d'échange de messages entre les deux nœuds RPL, 2 et 3, et le nœud racine 4 pour la sélection d'un nœud RPL routeur pour le récepteur 8.

A l'étape 106, la récepteur 8 diffuse une requête d'adhésion à un groupe multicast (p. ex. un message de type MLD report (Multicast Listener Discovery)) comportant, un entête indiquant l'adresse du récepteur @R (c.à.d. l'adresse source de la requête d'adhésion) et l'adresse multicast mcast@ du groupe auquel souhaite adhérer ledit récepteur 8.

A la réception de la requête d'adhésion au groupe multicast, chacun des nœuds RPL 2 et 3 enregistre dans sa deuxième table d'association l'adresse de l'hôte 8 et optionnellement le type de l'hôte (récepteur) ainsi que l'adresse multicast que l'hôte souhaite joindre, met le champ statut à PENDING dans ladite deuxième table d'association et configure le champ lifetime avec une durée de vie non nulle. Chaque nœud RPL 2, 3 mémorise la requête d'adhésion (p. ex. le message MLD Report) reçu si sa mémoire disponible le lui permet.

Chacun des nœuds RPL 2, 3 génère ensuite un message MER_Request (par exemple un message DAO) contenant un champ dédié à l'adresse de l'hôte, un champ optionnel dédié au type de l'hôte (type d'hôte = récepteur) et un dernier champ optionnel dédié à l'adresse multicast mcast@ du groupe, et envoie (étapes 108 et 110) le message M ER_Request au nœud racine 4.

A l'étape 112, le nœud racine 4 envoie au nœud RPL 2 un message M ER_Reply comportant les mêmes informations que celles mentionnées dans le message M ER_Request reçu de ce nœud RPL 2 avec en plus un champ statut mis à M ER et un champ lifetime indiquant la durée de vie de ce statut pour le nœud RPL2.

A la réception du message MER_Reply, le nœud RPL 2 met son statut à M ER dans sa deuxième table d'association, déclenche la création de la branche de l'arbre multicast, et supprime le message MLD de sa mémoire.

Parallèlement, à l'étape 114, le nœud racine 4 envoie au nœud RPL 3 un message MER_Reply comportant les mêmes informations que celles mentionnées dans le message M ER_Request reçu de ce nœud RPL 3 avec en plus un champ statut mis à NON_MER et un champ lifetime indiquant la durée de vie de ce statut pour le nœud RPL3.

A la réception du message MER_Reply, le nœud RPL 3 met son statut à NON_MER dans sa deuxième table d'association et supprime le message M LD de sa mémoire.

Le procédé selon l'invention s'applique à la fois dans le contexte des réseaux informatiques/télécom à faible ressources (Low 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 I P multicast grâce à :

• la définition d'un mécanisme d'échange de messages dans le réseau (p. ex. dans un réseau RPL) entre un ensemble de routeurs multicast 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 routeur (p. ex. routeur RPL) qui associent un routeur multicast sélectionné (M ER) 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 et des nœuds routeurs.

• 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].