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