Résumé

  • Groupes dynamiques, initiateurs multiples et objectifs incompatibles conduisirent RFC 2102 à laisser hors du cœur de Nimrod la génération des routes multicast comme leur mécanisme de transmission.
  • L’interopérabilité se déplaça vers la structure de l’état installé : arbres partagés ou enracinés à la source pouvaient coexister si les routeurs interprétaient uniformément parents, enfants et identifiants de flux.
  • Une branche présente ne prouvait donc ni les membres actuels, ni l’autorisation, ni une couverture complète, ni le plus court chemin, ni la réservation ou la livraison.

Un arbre multicast est souvent raconté depuis sa racine. RFC 2102 le regardait depuis le milieu : un routeur reçoit un paquet marqué par un identifiant de flux et doit savoir vers quels enfants le dupliquer. La façon dont cette relation a été calculée pouvait varier. Son sens exécutable, lui, ne pouvait pas varier.

Laisser deux phases ouvertes

Le routage unicast et multicast comportent génération de route et transmission. Nimrod définissait des modes de transmission unicast, tout en laissant l’algorithme de route à l’agent. Pour le multicast, RFC 2102 ne fixait aucune des deux phases.

Le groupe change avec les arrivées et départs. L’état peut être créé par l’émetteur, par les récepteurs ou par les routeurs intermédiaires. Quant au calcul de l’arbre, minimiser son coût total, le délai de chaque destinataire, la durée de calcul et la quantité d’état produit des réponses différentes.

Le panorama du RFC matérialise ces arbitrages. DVMRP construit des arbres de source par reverse path forwarding mais diffuse largement travail et état. CBT réduit l’état avec un arbre partagé autour d’un cœur, au risque d’allonger les chemins. PIM combine arbre partagé et arbre propre à la source. MOSPF fait calculer les arbres à partir de l’état de liens et des adhésions. IDPR laisse la source calculer une route de politique puis installer la duplication dans les entités intermédiaires.

Une grammaire d’exécution commune

La diversité ne supprimait pas l’accord. RFC 2102 propose de l’établir sur la structure des informations de transmission. L’arbre de livraison est défini par l’état présent dans les routeurs, non par l’algorithme qui l’a produit. Plusieurs méthodes peuvent donc coopérer si elles donnent le même sens à cet état.

L’exemple Nimpim installe pour un flow-id un parent, une liste d’enfants et une cible. Un Join ajoute un enfant à un flux existant ou crée ce triplet avant de poursuivre en amont. Un Prune retire un enfant ; l’état disparaît seulement lorsque la liste devient vide. Les paquets portant le flow-id sont ensuite copiés selon cette relation.

Un récepteur peut ainsi raccorder une branche à un arbre créé par l’émetteur sans que celui-ci connaisse l’opération. Un arbre partagé peut céder la place à un arbre de source. RFC 2102 autorise la coexistence et la transition, tant que le nouvel état reste interprétable par tous les participants.

Ce que la ligne ne certifie pas

Un enfant dans une table n’est pas une liste de membres. RFC 1112 place l’intérêt des hôtes sur le lien directement attaché, avec ses propres délais et agrégations. L’état de transmission en est une projection ultérieure.

Ce n’est pas non plus une autorisation. Des restrictions propres aux destinations peuvent obliger un même groupe à utiliser plusieurs arbres pour des partitions disjointes. La branche visible ne révèle ni les destinations absentes ni la validité actuelle de la politique.

Elle ne garantit pas le chemin optimal : CBT peut détourner le trafic par son cœur ; le « plus court » chemin inverse de PIM dépend de métriques symétriques. Réservation et qualité restent également distinctes. RFC 2102 demande des informations sur les ressources partageables et sur les contraintes de qualité, mais la présence d’une branche ne prouve ni admission, ni délai, ni gigue.

Enfin, l’état ne certifie pas l’émission, la continuité des autres routeurs, la copie au dernier saut ou la consommation par l’application. Les questions de sécurité n’étant pas traitées dans le RFC, il ne peut pas davantage authentifier membre ou permission.

Une frontière historique plutôt qu’un déploiement

RFC 1992 acceptait déjà des cartes et modes de transmission multiples ; RFC 1753 séparait état utilisateur et état de service. RFC 2102 conserva cette architecture de frontières : mettre dans la couche commune seulement ce que deux implémentations doivent comprendre pour exécuter ensemble.

La « spécification initiale minimale » de Lu Heng offre un vocabulaire ultérieur à cette intuition, tandis que la primauté du code en fonctionnement interdit de prendre une publication pour une adoption. Il s’agit d’un parallèle analytique, non d’une filiation. RFC 2102 reste Informational et n’établit aucun déploiement de Nimrod.

Sa leçon durable est plus étroite : les méthodes peuvent différer, la sémantique d’exécution non. Une branche prouve une branche. Chaque affirmation plus large attend sa propre pièce.

Sources