4.1. Extensions à l'interface du module IP (Extensions to the IP Module Interface)

L'interface entre le module IP et les protocoles de couche supérieure a été étendue pour permettre aux protocoles de demander la réception de tous les datagrammes envoyés à un canal spécifique.

Subscribe ( socket, source-address, group-address, interface )

Unsubscribe ( socket, source-address, group-address, interface )

où :

socket est défini comme à la section 2,

et, en référence à la description de [IGMPv3],

interface est l'identifiant local d'une interface réseau, utilisé pour identifier l'interface réseau sur laquelle activer ou désactiver la réception du canal identifié par la paire (source-address, group-address). Une valeur spéciale PEUT être utilisée pour indiquer l'interface « par défaut ». Si l'on souhaite recevoir le même canal sur plusieurs interfaces, un appel Subscribe distinct DOIT être effectué pour chaque interface.

Il s'agit d'une interface fonctionnelle strictement abstraite — cette fonctionnalité PEUT être fournie de manière spécifique à l'implémentation. Par exemple, sur un hôte prenant en charge l'API de filtrage de source multicast [MSFAPI], les interfaces Subscribe et Unsubscribe PEUVENT être prises en charge via cette API. Lorsqu'un hôte est configuré pour connaître la plage d'adresses SSM (Source-Specific Multicast, multicast spécifique à la source) — quelle que soit la méthode de configuration, manuelle ou par protocole — le système d'exploitation de l'hôte DEVRAIT retourner une erreur aux applications qui émettent des requêtes non spécifiques à la source pour recevoir du multicast envoyé à une adresse de destination SSM.

Les hôtes qui ne prennent pas en charge ces interfaces de module IP (par exemple, les hôtes ne prenant en charge que l'ASM, Any-Source Multicast) et leurs protocoles sous-jacents ne peuvent pas s'attendre à recevoir de manière fiable le trafic envoyé sur des canaux SSM. Comme décrit à la section 5.2 ci-dessous, les routeurs n'établissent pas d'état de transfert SSM et ne transfèrent pas les datagrammes en réponse aux requêtes de jointure ASM.

Les implémentations répandues de l'interface de réception de paquets IP (par exemple, l'appel système recvfrom() dans BSD Unix) ne permettent pas au récepteur de déterminer l'adresse de destination à laquelle le datagramme a été envoyé. Sur les hôtes disposant d'une telle implémentation, lorsque le socket recevant un datagramme est abonné à plusieurs canaux, il est impossible de déduire l'adresse de destination du datagramme. Le système d'exploitation de l'hôte DEVRAIT fournir un moyen permettant à l'hôte de déterminer l'adresse source et l'adresse de destination à laquelle un datagramme a été envoyé. (Par exemple, le système d'exploitation Linux fournit la destination du paquet dans la réponse à l'appel système recvmsg().) En l'absence de cette fonctionnalité, les applications peuvent être contraintes d'utiliser des mécanismes de couche supérieure pour identifier le canal auquel un datagramme a été envoyé.