Résumé

  • Dans SSM, l’abonnement n’est plus seulement G : il devient (S,G), un groupe accompagné de l’adresse de la source choisie.
  • La suppression des RP, arbres partagés et mécanismes de découverte simplifie l’interdomaine, mais déplace la découverte de la source vers l’application.
  • Ce filtrage sélectionne une adresse ; il n’authentifie pas l’émetteur et ne supprime ni l’état des routeurs ni tous les risques de déni de service.

Une question retirée aux routeurs

Le changement le plus important de Source-Specific Multicast tient dans une paire de coordonnées. RFC 4607 définit un canal par (S,G). Le récepteur demande les datagrammes envoyés par l’adresse source S vers l’adresse de groupe G. Un paquet venant d’une autre source ne doit pas être livré à la socket qui a formulé cette demande.

Ce sens est attaché à des plages réservées : 232.0.0.0/8 en IPv4 et FF3x::/32 en IPv6. Pour ces adresses, une demande générique (*,G) ne constitue pas une version dégradée acceptable. Les routeurs ne doivent ni l’utiliser ni la propager. Tous les équipements du chemin doivent donc partager la même interprétation source-spécifique ; sinon, l’adresse garde sa forme mais perd son contrat.

Dans ASM, le réseau peut participer à la découverte des sources. Dans SSM, RFC 8815 place cette connaissance ailleurs : le récepteur doit apprendre S par un mécanisme hors bande, généralement au niveau applicatif. Le réseau cesse de répondre à « qui émet pour ce groupe ? ». Il exécute une réponse déjà choisie en périphérie.

La simplicité a un propriétaire

La recommandation de RFC 8815 pour l’interdomaine s’explique par ce retrait. Sur le chemin SSM, il n’est plus nécessaire d’entretenir un Rendezvous Point, un arbre partagé, une transition vers l’arbre du plus court chemin, des registres PIM, MSDP ou une découverte dynamique des RP. Le join qualifié par la source crée l’état (S,G) en direction de la source, via PIM-SSM.

Le gain opérationnel est tangible : moins de mécanismes de coordination, moins de dépendances spécifiques à la découverte réseau. Mais la source n’apparaît pas par magie. Une application, un guide de service ou un autre canal de contrôle doit fournir l’adresse. On peut donc tirer une inférence prudente : si ce canal se trompe, vieillit ou est détourné, le réseau SSM peut appliquer fidèlement un mauvais choix. Les RFC prouvent le déplacement de la découverte ; elles ne documentent aucun incident concret ni aucune faiblesse d’un service nommé.

La portée administrative compte. RFC 8815 recommande la dépréciation d’ASM pour le multicast interdomaine et recommande SSM ainsi qu’un support complet dans les hôtes et routeurs. Le texte n’interdit pas ASM à l’intérieur d’une seule organisation ou d’un seul domaine. Une BCP indique une direction d’architecture ; elle ne mesure pas le taux actuel de migration.

Le choix doit survivre au premier lien

RFC 4604 décrit comment IGMPv3 et MLDv2 transportent la demande source-spécifique. Une application qui tente une demande non qualifiée pour une adresse SSM devrait recevoir un échec. Les modes de compatibilité avec d’anciennes versions peuvent aussi empêcher la livraison du canal (S,G), car un rapport ancien ne peut pas exprimer le filtre de source demandé.

Sur un média partagé, la suppression de rapports devient elle-même un sujet de sûreté. Dans le cas de compatibilité décrit par RFC 4604, l’hôte compatible SSM ne doit pas supprimer son rapport source-spécifique simplement après avoir entendu le rapport d’un autre hôte. Ce geste pourrait empêcher le routeur de premier saut d’apprendre la demande complète et priver d’autres récepteurs du service. Deux rapports qui semblent redondants ne portent pas nécessairement la même information.

Ethernet ajoute une dernière limite. L’adresse multicast de couche liaison ne filtre pas selon l’adresse IP source. RFC 4607 exige donc que le module IP de l’hôte vérifie encore la source avant la remise à la socket. L’admission (S,G) traverse l’application, l’API de l’hôte, IGMPv3 ou MLDv2, le routeur désigné et le chemin PIM-SSM.

Sélectionner n’est pas prouver

La précision de (S,G) peut donner une fausse impression d’identité. RFC 4607 prévient qu’une adresse source falsifiée peut violer le modèle de service. Si l’application exige une authentification forte, elle doit ajouter un mécanisme de couche supérieure. SSM contrôle quelle adresse est admise ; il ne fournit pas une preuve cryptographique de l’émetteur.

Il subsiste également un coût d’état. Les abonnements créent du traitement, du trafic de contrôle et des entrées dans les routeurs. De très grands ensembles d’abonnements peuvent servir à un déni de service. RFC 4607 autorise des limites de débit ou d’état choisies avec soin. Retirer les RP ne signifie donc pas retirer toute surface d’épuisement.

Ce qui reste inconnu

Les trois textes ne donnent aucune part de déploiement actuelle par pays, opérateur ou secteur. Ils ne décrivent pas les valeurs par défaut des constructeurs, les défauts d’interopérabilité contemporains, ni la sécurité du canal de découverte d’un service particulier. Ils ne mesurent pas non plus les économies de bande passante ou la baisse d’incidents après migration. Ces questions nécessiteraient d’autres sources.

La conclusion défendable est plus précise. SSM rend le multicast interdomaine plus simple en exigeant une instruction plus riche. Le récepteur nomme la source ; l’hôte et le réseau conservent cette qualification ; l’application assume la découverte. Le réseau gagne en lisibilité parce qu’il refuse de deviner.

Sources