4.1. Extensions de l'interface du module IP

L'interface du module IP vers les protocoles de couche supérieure est étendue pour permettre à un protocole de demander la réception de tous les datagrammes envoyés à un canal particulier.

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

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

Où :

« socket » est défini à la section 2,

et, en citant [IGMPv3] :

« interface » est un identificateur local d'interface réseau indiquant sur quelle interface réseau 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 la réception du même canal sur plusieurs interfaces est souhaitée, un appel Subscribe séparé est nécessaire pour chaque interface.

L'interface ci-dessus est strictement une interface fonctionnelle abstraite -- sa fonctionnalité peut être fournie de manière spécifique à l'implémentation. Par exemple, sur les hôtes prenant en charge l'interface de programmation d'application de filtrage de source de multidiffusion [MSFAPI], les interfaces Subscribe et Unsubscribe peuvent être prises en charge par cette API. Lorsqu'un hôte est configuré pour connaître la plage d'adresses SSM (que le mécanisme de configuration soit manuel ou via un protocole), si une application lance une demande non spécifique à la source pour recevoir de la multidiffusion envoyée à une adresse de destination SSM, le système d'exploitation de l'hôte DOIT (SHOULD) renvoyer une erreur à l'application.

Les hôtes ne prenant pas en charge ces interfaces du module IP (par exemple, les hôtes ne prenant en charge que ASM) et leurs protocoles sous-jacents ne peuvent pas espérer recevoir de manière fiable le trafic envoyé sur un canal SSM. Comme spécifié à la section 5.2 ci-dessous, les routeurs ne configurent pas d'état de transfert SSM ni ne transfèrent de datagrammes en réponse à une demande de jointure ASM.

L'implémentation répandue des interfaces de réception de datagrammes IP (par exemple l'appel système recvfrom() dans Unix BSD) ne permet pas au récepteur de déterminer l'adresse de destination à laquelle un datagramme a été envoyé. Sur les hôtes ayant de telles implémentations, lorsqu'un socket recevant des datagrammes 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 DOIT (SHOULD) fournir un moyen permettant à l'hôte de déterminer les adresses source et de destination utilisées lors de l'envoi du datagramme. (À titre d'exemple, le système d'exploitation Linux fournit l'adresse de destination du paquet dans la réponse de l'appel système recvmsg().) En attendant cette capacité, les applications peuvent être contraintes d'utiliser des mécanismes de couche supérieure pour identifier le canal vers lequel le datagramme a été envoyé.