1. Introduction

Le modèle de service de multidiffusion (multicast) du protocole Internet (IP) est défini dans le RFC 1112 [RFC1112]. Le RFC 1112 spécifie qu'un datagramme envoyé à une adresse multicast IP (224.0.0.0 à 239.255.255.255) G est délivré à chaque "module de protocole de couche supérieure" qui a demandé la réception de datagrammes envoyés à l'adresse G. Le RFC 1112 appelle le service réseau identifié par une adresse de destination multicast G un "groupe d'hôtes". Ce modèle prend en charge à la fois la communication de groupe un-à-plusieurs et plusieurs-à-plusieurs. Ce document utilise le terme "Any-Source Multicast" (ASM) pour désigner le modèle de multicast défini dans le RFC 1112. Le RFC 3513 [RFC3513] spécifie la forme des adresses multicast IPv6 avec une sémantique ASM.

Les adresses IPv4 dans la plage 232/8 (232.0.0.0 à 232.255.255.255) sont actuellement désignées comme adresses de destination multicast spécifique à la source (SSM) et sont réservées à l'utilisation par des applications et protocoles spécifiques à la source [IANA-ALLOC].

Pour IPv6, le préfixe d'adresse FF3x::/32 est réservé à l'utilisation multicast spécifique à la source, où 'x' est tout identifiant de portée valide, par [IPv6-UBM]. En utilisant la terminologie de [IPv6-UBM], toutes les adresses SSM doivent avoir P=1, T=1, et plen=0. [IPv6-MALLOC] impose que le champ de préfixe réseau d'une adresse SSM soit également mis à zéro, par conséquent toutes les adresses SSM tombent dans la plage FF3x::/96. Des documents futurs pourraient autoriser un champ de préfixe réseau non nul si, par exemple, un nouveau mappage adresse IP vers adresse MAC est défini. Ainsi, l'allocation d'adresses devrait (SHOULD) se faire dans la plage FF3x::/96, mais un système devrait (SHOULD) traiter l'ensemble de FF3x::/32 comme des adresses SSM, pour permettre la compatibilité avec d'éventuelles utilisations futures du champ de préfixe réseau.

Les adresses dans la plage FF3x::4000:0001 à FF3x::7FFF:FFFF sont réservées dans [IPv6-MALLOC] pour allocation par l'IANA. Les adresses dans la plage FF3x::8000:0000 à FF3x::FFFF:FFFF sont autorisées pour allocation dynamique par un hôte, comme décrit dans [IPv6-MALLOC]. Les adresses dans la plage FF3x::0000:0000 à FF3x::3FFF:FFFF sont des adresses SSM IPv6 invalides. ([IPv6-MALLOC] indique que FF3x::0000:0001 à FF3x::3FFF:FFFF doivent définir P=0 et T=0, mais pour SSM, [IPv6-UBM] impose que P=1 et T=1, d'où leur désignation comme invalides.) Le traitement d'un paquet envoyé à une telle adresse invalide est indéfini -- un routeur ou un hôte PEUT (MAY) choisir de rejeter un tel paquet.

La sémantique de livraison multicast spécifique à la source est fournie pour un datagramme envoyé à une adresse SSM. C'est-à-dire qu'un datagramme avec une adresse IP source S et une adresse de destination SSM G est délivré à chaque "socket" de couche supérieure qui a spécifiquement demandé la réception de datagrammes envoyés à l'adresse G par la source S, et uniquement à ces sockets. Le service réseau identifié par (S,G), pour l'adresse SSM G et l'adresse de l'hôte source S, est appelé un "canal". Contrairement au modèle ASM du RFC 1112, SSM fournit un support de couche réseau pour la livraison un-à-plusieurs uniquement.

Les avantages du multicast spécifique à la source incluent :

Élimination de la livraison croisée de trafic lorsque deux sources utilisent simultanément la même adresse de destination spécifique à la source. L'utilisation simultanée d'une adresse de destination SSM par plusieurs sources et différentes applications est explicitement prise en charge.
Évitement de la nécessité d'une coordination entre hôtes lors du choix d'adresses spécifiques à la source, comme conséquence de ce qui précède.
Évitement de nombreux protocoles et algorithmes de routeur qui sont nécessaires pour fournir le modèle de service ASM. Par exemple, les "arbres partagés" et les points de rendez-vous (Rendezvous Points) du protocole PIM - Sparse Mode (PIM-SM) [PIM-SM] ne sont pas nécessaires pour supporter le modèle spécifique à la source. Les mécanismes de routeur requis pour supporter SSM sont en fait largement un sous-ensemble de ceux qui sont utilisés pour supporter ASM. Par exemple, le mécanisme d'arbre du plus court chemin du protocole PIM-SM peut être adapté pour fournir la sémantique SSM.

Comme ASM, l'ensemble des récepteurs est inconnu d'un émetteur SSM. Une source SSM ne reçoit ni l'identité des récepteurs ni leur nombre.

SSM est particulièrement bien adapté aux applications de type diffusion avec un ou plusieurs émetteurs dont les identités sont connues avant le début de l'application. Par exemple, une application de diffusion de données qui souhaite fournir une source de données secondaire au cas où la source primaire tomberait en panne pourrait implémenter cela en utilisant un canal pour chaque source et en annonçant les deux aux récepteurs. SSM peut être utilisé pour construire des applications multi-sources où les identités de tous les participants ne sont pas connues à l'avance, mais la fonctionnalité de "rendez-vous" multi-sources ne se produit pas dans la couche réseau dans ce cas. Tout comme dans une application qui utilise l'unicast comme transport sous-jacent, cette fonctionnalité peut être implémentée par l'application ou par une bibliothèque de couche application.

La découverte de ressources multicast sous la forme où un client envoie une requête multicast directement à un "groupe de localisation de service" auquel les serveurs écoutent n'est pas directement supportée par SSM.

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le RFC 2119 [RFC2119].

Ce document définit la sémantique des adresses multicast spécifiques à la source et spécifie les politiques régissant leur utilisation. En particulier, il définit une extension au service de réseau Internet qui s'applique aux datagrammes envoyés aux adresses SSM et définit les extensions d'hôte pour supporter le service réseau. Les hôtes, routeurs, applications et protocoles qui utilisent ces adresses DOIVENT (MUST) se conformer aux politiques décrites dans ce document. Le non-respect par un hôte peut empêcher cet hôte ou d'autres hôtes sur le même LAN de recevoir le trafic envoyé à un canal SSM. Le non-respect par un routeur peut entraîner la livraison de trafic SSM à des parties du réseau où il est indésirable, surchargeant inutilement le réseau.