12. Opération Multicast

Cette section décrit une opération de routage multicast sur un réseau IPv6 RPL et, spécifiquement, comment les DAO unicast peuvent être utilisés pour relayer les enregistrements de groupe. La même construction DODAG peut être utilisée pour transférer le trafic unicast et multicast. Cette section se limite à une description de la manière dont les enregistrements de groupe peuvent être échangés et comment l'infrastructure de transfert fonctionne. Elle ne fournit pas une description complète du multicast au sein d'un LLN et, en particulier, ne décrit pas la génération de DODAG spécifiquement ciblés sur le multicast ou les détails de l'exploitation de RPL pour le multicast -- cela fera l'objet de spécifications ultérieures.

L'enregistrement de groupe multicast utilise des messages DAO qui sont identiques à l'unicast, sauf pour le type d'adresse qui est transporté. La principale différence est que le trafic multicast descendant est copié vers tous les enfants qui se sont enregistrés avec le groupe multicast, alors que le trafic unicast est passé à un seul enfant.

Les nœuds qui supportent le mode de fonctionnement avec stockage (Storing mode) de RPL DEVRAIENT également supporter les opérations DAO multicast comme décrit ci-dessous. Les nœuds qui ne supportent que le mode de fonctionnement sans stockage (Non-Storing mode) ne sont pas censés supporter cette section.

L'opération multicast est contrôlée par le champ MOP dans le DIO.

• Si le champ MOP nécessite un support multicast, alors un nœud qui rejoint le réseau RPL en tant que routeur doit fonctionner comme décrit dans cette section pour la signalisation et le transfert multicast au sein du réseau RPL. Un nœud qui ne supporte pas l'opération multicast requise par le champ MOP ne peut rejoindre qu'en tant que feuille.

• Si le champ MOP ne nécessite pas de support multicast, alors le multicast est géré par un autre moyen qui est hors de portée de cette spécification. (Des exemples peuvent inclure une série de copies unicast ou une inondation à portée limitée).

Un routeur pourrait choisir de passer un message DAO d'enregistrement d'auditeur à son parent préféré uniquement ; auquel cas, les paquets multicast revenant pourraient être perdus pour tous ses sous-DODAG si la transmission échoue sur ce lien. Alternativement, le routeur pourrait choisir de copier des parents supplémentaires comme il le ferait pour les messages DAO annonçant des destinations unicast ; auquel cas, il pourrait y avoir des doublons que le routeur devra élaguer.

En conséquence, les états de routage multicast sont installés dans chaque routeur sur le chemin des auditeurs à la racine du DODAG, permettant à la racine de copier un paquet multicast à tous ses routeurs enfants qui avaient émis un message DAO incluant une option Cible pour ce groupe multicast.

Pour un paquet multicast provenant de l'intérieur du DODAG, le paquet est passé aux parents préférés, et si cela échoue, alors aux alternatifs dans le DODAG. Le paquet est également copié à tous les enfants enregistrés, sauf celui qui a passé le paquet. Enfin, s'il y a un auditeur dans l'infrastructure externe, alors la racine du DODAG doit propager davantage le paquet dans l'infrastructure externe.

En conséquence, la racine du DODAG agit comme un point de rendez-vous proxy automatique pour le réseau RPL et comme source vers le domaine non-RPL pour tous les flux multicast démarrés dans le domaine RPL. Ainsi, indépendamment du fait que la racine soit réellement attachée à un domaine non-RPL, et indépendamment du fait que le DODAG soit ancré ou flottant, la racine peut servir les flux multicast internes à tout moment.