4. Host Requirements (Exigences pour les hôtes)

Cette section décrit les exigences pour les hôtes qui supportent le multicast spécifique à la source, y compris :

• Extensions de l'interface du module IP

• Extensions du module IP

• Allocation des adresses SSM

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

L'interface du module IP vers les protocoles de couche supérieure est étendue pour permettre aux protocoles 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 tel que défini précédemment dans la section 2,

et, en paraphrasant [IGMPv3],

"interface" est un identifiant local de l'interface réseau sur laquelle la réception du canal identifié par la paire (source-address, group-address) doit être activée ou désactivée. Une valeur spéciale peut être utilisée pour indiquer une interface "par défaut". Si la réception du même canal est souhaitée sur plusieurs interfaces, Subscribe est invoqué une fois pour chacune.

Ce qui précède sont des interfaces fonctionnelles strictement abstraites -- la fonctionnalité peut être fournie d'une manière spécifique à l'implémentation. Sur un hôte qui supporte l'interface de programmation d'application de filtrage de source multicast de [MSFAPI], par exemple, les interfaces Subscribe et Unsubscribe peuvent être supportées via cette API. Lorsqu'un hôte a été configuré pour connaître la plage d'adresses SSM (que le mécanisme de configuration soit manuel ou via un protocole), le système d'exploitation de l'hôte DEVRAIT (SHOULD) renvoyer une erreur à une application qui effectue une demande non spécifique à la source pour recevoir du multicast envoyé à une adresse de destination SSM.

Un hôte qui ne supporte pas ces interfaces de module IP (par exemple, les hôtes ASM uniquement) et leurs protocoles sous-jacents ne peut pas s'attendre à recevoir de manière fiable le trafic envoyé sur un canal SSM. Comme spécifié ci-dessous dans la section 5.2, les routeurs ne mettront pas en place d'état de transfert SSM ni ne transféreront de datagrammes en réponse à une demande 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 à un récepteur de déterminer l'adresse de destination à laquelle un datagramme a été envoyé. Sur un hôte avec une telle implémentation, l'adresse de destination d'un datagramme ne peut pas être déduite lorsque le socket sur lequel le datagramme est reçu est abonné (Subscribed) à plusieurs canaux. Les systèmes d'exploitation hôtes DEVRAIENT (SHOULD) fournir un moyen pour un hôte de déterminer à la fois la source et l'adresse de destination auxquelles un datagramme a été envoyé. (À titre d'exemple, le système d'exploitation Linux fournit la destination d'un paquet dans le cadre de la réponse à l'appel système recvmsg().) Tant que cette capacité n'est pas présente, les applications peuvent être forcées d'utiliser des mécanismes de couche supérieure pour identifier le canal auquel un datagramme a été envoyé.

4.2. Requirements on the Host IP Module (Exigences sur le module IP de l'hôte)

Un datagramme entrant destiné à une adresse SSM DOIT (MUST) être délivré par le module IP à tous les sockets qui ont indiqué (via Subscribe) un désir de recevoir des données correspondant à l'adresse source, l'adresse de destination et l'interface d'arrivée du datagramme. Il NE DOIT PAS (MUST NOT) être délivré à d'autres sockets.

Lorsque le premier socket sur l'hôte H s'abonne à un canal (S,G) sur l'interface I, le module IP de l'hôte sur H envoie une demande sur l'interface I pour indiquer aux routeurs voisins que l'hôte souhaite recevoir du trafic envoyé par la source S vers la destination multicast spécifique à la source G. De même, lorsque le dernier socket sur un hôte se désabonne d'un canal sur l'interface I, le module IP de l'hôte envoie une demande de désabonnement pour ce canal à l'interface I.

Ces demandes seront généralement des messages Internet Group Management Protocol version 3 (IGMPv3) pour IPv4, ou des messages Multicast Listener Discovery Version 2 (MLDv2) pour IPv6 [IGMPv3,MLDv2]. Un hôte qui supporte le modèle de service SSM DOIT (MUST) implémenter la partie hôte de [IGMPv3] pour IPv4 et [MLDv2] pour IPv6. Il DOIT (MUST) également se conformer au comportement IGMPv3/MLDv2 décrit dans [GMP-SSM].

4.3. Allocation of Source-Specific Multicast Addresses (Allocation des adresses multicast spécifiques à la source)

L'adresse de destination SSM 232.0.0.0 est réservée, et elle ne doit pas être utilisée comme adresse de destination. De même, FF3x::4000:0000 est également réservée. Le but de réserver ces deux adresses est de préserver une destination SSM invalide pour IPv4 et IPv6, ce qui peut être utile dans une implémentation comme valeur nulle. La plage d'adresses 232.0.0.1 - 232.0.0.255 est actuellement réservée pour allocation par l'IANA. Les adresses de destination SSM dans la plage FF3x::4000:0001 à FF3x::7FFF:FFFF sont de même réservées pour allocation par l'IANA [IPv6-MALLOC]. La motivation pour réserver ces adresses est décrite ci-dessous dans la section 9, "Considérations de l'IANA".

La politique d'allocation du reste des adresses SSM aux applications émettrices est strictement déterminée localement par l'hôte émetteur.

Lors de l'allocation dynamique d'adresses SSM, un hôte ou un système d'exploitation hôte NE DOIT PAS (MUST NOT) allouer séquentiellement en commençant par la première adresse autorisée. Il est RECOMMANDÉ (RECOMMENDED) d'allouer des adresses SSM aux applications de manière aléatoire, tout en s'assurant que les adresses allouées ne sont pas données simultanément à plusieurs applications (et en évitant les adresses réservées). Pour IPv6, la randomisation devrait s'appliquer aux 31 bits les plus bas de l'adresse.

Comme décrit dans la section 6, le mappage d'un paquet IP avec une adresse de destination SSM sur une adresse multicast de couche liaison ne prend pas en compte l'adresse IP source du datagramme (sur les couches de liaison couramment utilisées comme Ethernet). Si tous les hôtes commençaient à la première adresse autorisée, alors avec une forte probabilité, de nombreux canaux spécifiques à la source sur des réseaux locaux à média partagé utiliseraient la même adresse multicast de couche liaison. En conséquence, le trafic destiné à un abonné de canal serait délivré au module IP d'un autre, qui devrait alors rejeter le datagramme.

Un système d'exploitation hôte DEVRAIT (SHOULD) fournir une interface pour permettre à une application de demander une allocation unique d'une adresse de destination de canal avant le début d'une session, et cette base de données d'allocation DEVRAIT (SHOULD) persister après les redémarrages de l'hôte. En fournissant des allocations persistantes, une application hôte peut annoncer la session à l'avance de son heure de début sur une page web ou dans un autre répertoire. (Nous notons que ce problème n'est pas spécifique aux applications SSM -- le même problème se pose pour ASM.)

Ce document ne définit ni les interfaces pour demander ou retourner des adresses, ni ne spécifie les algorithmes de l'hôte pour stocker ces allocations. Une API abstraite plausible est définie dans le RFC 2771 [RFC2771]. Notez que le RFC 2771 permet à une application de demander une adresse dans une plage spécifique d'adresses. Si cette interface est utilisée, l'adresse de départ de la plage DEVRAIT (SHOULD) être sélectionnée au hasard par l'application.

Pour IPv6, les adresses de canal SSM à portée administrative sont créées en choisissant un identifiant de portée approprié pour l'adresse de destination SSM. Les limites de portée multicast IPv6 normales [SCOPINGv6] sont appliquées au trafic envoyé à une adresse de destination SSM, y compris toutes les limites pertinentes appliquées à la fois à l'adresse source et à l'adresse de destination.

Aucune plage d'adresses à portée administrative mondialement convenue [ADMIN-SCOPE] n'est actuellement définie pour le multicast spécifique à la source IPv4. Pour IPv4, la portée administrative des adresses SSM peut être implémentée au sein d'un domaine administratif en filtrant le trafic SSM sortant envoyé à une adresse à portée aux routeurs de frontière du domaine.