Aller au contenu principal

Sujet

Routage multicast

Au sein de la facette Sujet, la veille thématique Routage multicast rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Un rapport IGMP prouvait une présence, pas un nombre de membres

Histoire d'Internet

Un rapport IGMP prouvait une présence, pas un nombre de membres

En 1989, une norme rendit l’adhésion au multicast visible aux routeurs voisins par un signal économe: un rapport pouvait représenter tout un groupe local, tandis que le silence après un départ devait expirer avec le temps.

16 oct. 2026
Le Mac pouvait rejoindre la conférence ; le réflecteur devait porter tout le monde : CU-SeeMe, 1993-1995

Histoire d'Internet

Le Mac pouvait rejoindre la conférence ; le réflecteur devait porter tout le monde : CU-SeeMe, 1993-1995

CU-SeeMe rendait possible l’envoi d’images en direct depuis un Macintosh modeste. Deux personnes pouvaient se relier directement. À partir de trois, il fallait changer d’échelle: un ordinateur Unix devait recevoir les flux, les copier et les redistribuer. La simplicité visible…

14 oct. 2026
Ellen Zegura et le cœur multicast qui pouvait changer de place

Dirigeants

Ellen Zegura et le cœur multicast qui pouvait changer de place

Quand les récepteurs d’un groupe multicast se dispersent, le routeur choisi comme cœur partagé peut cesser d’être bien placé. Dans un article de 1996, Ellen Zegura et Michael J. Donahoo ont proposé de traiter son déplacement comme une question de routage, tout en cherchant à…

13 oct. 2026
Au CERN, les paquets arrivaient ; beaucoup de questions restaient inaudibles : NANOG 1 et le MBONE en 1994

NANOG

Au CERN, les paquets arrivaient ; beaucoup de questions restaient inaudibles : NANOG 1 et le MBONE en 1994

Pour la première réunion de NANOG, prévue à Ann Arbor en juin 1994, les organisateurs annonçaient un projet de diffusion sur le MBONE. Les archives de la liste ne décrivent pas un flux uniformément réussi ou en panne: une personne ne trouvait pas la session, une autre demandait…

13 oct. 2026
L’adresse de groupe nommait son point de rendez-vous. Elle ne prouvait pas son existence : RFC 3956

Histoire d'Internet

L’adresse de groupe nommait son point de rendez-vous. Elle ne prouvait pas son existence : RFC 3956

Avec la RFC 3956, une adresse multicast IPv6 devenait aussi une instruction de calcul: elle indiquait quel RP essayer. La même formule donnait le même candidat partout, sans transformer ce candidat en route, service ou preuve de livraison.

7 oct. 2026
Le filtre pouvait changer une source à la fois — ou toutes d’un coup.

Histoire d'Internet

Le filtre pouvait changer une source à la fois — ou toutes d’un coup.

RFC 3678 n’a pas demandé aux applications multicast de réapprendre leur adhésion à un groupe. Le texte a conservé les anciens appels, puis ajouté deux manières de modifier un filtre de sources: ajuster un émetteur, ou remplacer tout l’état en une seule opération.

7 oct. 2026
Le récepteur réglait son débit sans rapport au serveur : RFC 3738

Histoire d'Internet

Le récepteur réglait son débit sans rapport au serveur : RFC 3738

En 2004, WEBRC a proposé une boucle de contrôle de congestion multicast sans demander à chaque récepteur de rendre compte au serveur. Chaque récepteur mesurait son chemin et choisissait un débit, exprimant ce choix par l’adhésion à des canaux multicast ou leur abandon: le…

6 oct. 2026
Le proxy IGMP était juste. Les deux sources SSM étaient pourtant devenues une seule

IETF

Le proxy IGMP était juste. Les deux sources SSM étaient pourtant devenues une seule

Un état IGMPv3 parfaitement agrégé peut coexister avec une perte d'identité dans le flux qu'il autorise. RFC 5135 trace cette frontière avec une précision rare: le proxy peut représenter correctement les abonnements tandis que le NAT réécrit deux sources privées en une même…

4 oct. 2026
Un paquet injecté a condamné l’objet entier

IETF

Un paquet injecté a condamné l’objet entier

Dans un cas construit, un flux multicast vérifiait l’authenticité seulement après avoir reconstitué chaque objet média. Un paquet injecté a suffi à faire échouer le contrôle final. Les récepteurs ont alors demandé une réparation en unicast: une petite falsification avait déjà…

3 oct. 2026
Le premier paquet devait arriver avant que sa branche étiquetée puisse exister : RFC 3353

Histoire d'Internet

Le premier paquet devait arriver avant que sa branche étiquetée puisse exister : RFC 3353

Un réseau multicast peut économiser des étiquettes en ne construisant une branche MPLS que lorsqu’un trafic réel apparaît. Cette prudence produit pourtant une question embarrassante: comment le routeur aval verra-t-il le paquet déclencheur si la branche censée le transporter…

3 oct. 2026
Des blocs réutilisables pouvaient échouer ensemble : RFC 3269

Histoire d'Internet

Des blocs réutilisables pouvaient échouer ensemble : RFC 3269

Le multicast fiable ne se résumait pas à assembler des pièces réutilisables. La RFC 3269 exigeait que chaque bloc RMT déclare ses limites et dépendances, puis que le protocole complet explique leur articulation.

2 oct. 2026
Dans BIER, la panne détectée en aval doit encore remonter

IETF

Dans BIER, la panne détectée en aval doit encore remonter

La surveillance d'un arbre de diffusion et la réception d'une alerte à sa tête sont deux événements distincts. La douzième version du projet BIER BFD précise le trajet de retour, l'identification de la session et la réponse attendue lorsqu'un récepteur perd la continuité.

2 oct. 2026
Le groupe multicast de PI n’était pas une adresse IPv4 : RFC 3091

Histoire d'Internet

Le groupe multicast de PI n’était pas une adresse IPv4 : RFC 3091

Le RFC 3091 imaginait que des clients reconstituent PI à partir d’un flux, de réponses UDP indexées ou du multicast. Mais son groupe multicast n’avait pas de représentation IPv4 valide; ailleurs, ses ports TCP et UDP dépassaient aussi la capacité des champs qui doivent les…

1 oct. 2026
Les notifications ont continué sans le Directory Agent ; de nouveaux services pouvaient rester invisibles : RFC 3082

Histoire d'Internet

Les notifications ont continué sans le Directory Agent ; de nouveaux services pouvaient rester invisibles : RFC 3082

La RFC 3082 voulait remplacer les interrogations répétées du réseau par des notifications de changement. Son scénario de reprise met en lumière une asymétrie plus fine: les service agents déjà informés peuvent continuer à émettre, tandis qu’un nouvel arrivant peut ne jamais…

1 oct. 2026
Un message authentifié n’est pas un titre de propriété

IETF

Un message authentifié n’est pas un titre de propriété

La révision 25 de GAAP renforce utilement la protection d’une revendication d’adresse multicast. Elle ne transforme pourtant ni la clé partagée en mandat, ni le chiffrement en registre de droits. Toute la décision opérationnelle tient dans cette séparation.

30 sept. 2026
GAAP-25 distingue le protocole commun de son exemple d’API Python

IETF

GAAP-25 distingue le protocole commun de son exemple d’API Python

Une signature de fonction dans un projet technique n’est pas forcément une obligation d’implémentation. La dernière révision de GAAP le dit désormais sans détour: l’accord entre entités porte sur les messages Claim, pas sur la forme du logiciel qui les produit.

30 sept. 2026
Le tableau annonçait des auditeurs. L’administrateur pouvait en créer la ligne : RFC 3019

Histoire d'Internet

Le tableau annonçait des auditeurs. L’administrateur pouvait en créer la ligne : RFC 3019

Une ligne du MIB de RFC 3019 pouvait venir d’un rapport MLD, de l’appartenance de la machine elle-même ou d’une écriture de gestion. L’outil rendait le multicast IPv6 administrable; il ne transformait pas sa table en preuve indépendante d’un auditeur distant.

30 sept. 2026
Les réplicas étaient d’accord. Les clients devaient pourtant revenir : RFC 2443

Histoire d'Internet

Les réplicas étaient d’accord. Les clients devaient pourtant revenir : RFC 2443

À la fin des années 1990, l’ATM pouvait transporter le multicast IP, mais les clients avaient encore besoin d’un service qui connaisse les groupes et leurs membres. La RFC 2443 a partagé cette connaissance entre plusieurs serveurs MARS. Sa règle la plus révélatrice concernait la…

29 sept. 2026
Trois liens sont devenus un ; le rafraîchissement est arrivé après la coupure

IETF

Trois liens sont devenus un ; le rafraîchissement est arrivé après la coupure

Deux routeurs PIM partagent trois liaisons point à point. L’optimisation choisit une seule copie au lieu d’en envoyer trois; la liaison retenue tombe avant que l’état local ne s’ajuste. Le rafraîchissement périodique réparera la découverte de source, mais il ne pourra jamais…

29 sept. 2026
Même le réseau sans configuration a son détenteur du veto

IETF

Même le réseau sans configuration a son détenteur du veto

Une nouvelle proposition de l’IETF laisse les applications choisir elles-mêmes leurs adresses multicast IPv6. Mais si le matériel voit une collision que l’application ne peut pas résoudre, cinq octets ajoutés à un enregistrement mDNS suffisent pour lui ordonner de céder la place.

28 sept. 2026