Résumé
- Dans RFC 3353, une branche LSP multicast déclenchée par le trafic pouvait attendre le paquet qui, au niveau 2, ne pouvait justement pas arriver avant l’existence de cette branche.
- Le transfert mixte L2/L3 ou l’initiative du routeur amont ouvrait une voie de démarrage, sans confondre arrivée du paquet, état de routage, signalisation d’étiquette, réplication programmée et réception finale.
Le cas est simple à dessiner. Un flux multicast atteint déjà un premier destinataire par MPLS. Un second récepteur rejoint le groupe derrière un autre routeur. L’opérateur ne veut pas préallouer une étiquette à chaque groupe possible : il préfère attendre qu’un paquet prouve qu’un flux existe.
Mais le routeur aval ne peut pas déclencher la nouvelle branche en observant du trafic L2, puisque ce trafic ne possède encore aucune branche L2 pour lui parvenir. RFC 3353 appelle cela un problème de « poule et d’œuf ». Le terme ne désigne pas une curiosité logique. Il révèle le point exact où une politique apparemment automatique a besoin d’un acteur, d’un chemin provisoire et d’une séquence.
Publié en août 2002 comme document informatif, RFC 3353 ne normalisait pas un protocole multicast MPLS. Il classait les difficultés produites par la rencontre entre deux systèmes. Le routage IP multicast construisait des arbres, parfois partagés (*,G), parfois propres à une source (S,G). MPLS associait des classes d’équivalence à des chemins étiquetés. Mettre l’un sur l’autre ne transformait pas un arbre changeant en simple route unicast.
Le coût de l’état dépendait d’abord de la forme de l’arbre. Un arbre partagé consommait en principe une étiquette par groupe, mais demandait des capacités multipoint-à-multipoint et de fusion. Des arbres par source évitaient une partie de cette fusion, au prix d’une étiquette par source et par groupe. Le document refusait de proclamer un vainqueur, car la rareté des étiquettes, la topologie et les capacités du niveau 2 variaient.
Les protocoles de diffusion puis élagage rendaient le problème temporel. Ils créaient un état lorsqu’un paquet apparaissait, supprimaient les branches inutiles et laissaient expirer l’état après une période d’inactivité. Copier chaque variation dans un LSP produisait beaucoup de signalisation et de consommation d’étiquettes. Préconstruire tous les LSP gaspillait l’état. Attendre le trafic économisait des ressources, mais faisait du premier paquet une partie du plan de contrôle.
RFC 3353 distinguait trois déclencheurs. Le mode guidé par requête interceptait un Join, un Prune ou un message de réservation. Le mode guidé par topologie reproduisait la table de routage multicast avant même l’arrivée de données. Le mode guidé par trafic ne construisait que les arbres actifs. Aucun n’était gratuit : l’un couplait les protocoles, l’autre occupait des étiquettes sans usage, le troisième déplaçait la difficulté vers le démarrage.
Pour sortir du cercle, deux mécanismes apparaissaient. Le premier était l’initiative amont. Le routeur qui voyait déjà le paquet pouvait demander une étiquette au routeur aval ou annoncer lui-même une liaison, selon le mode de distribution. L’observation et l’action se trouvaient alors du même côté du vide.
Le second était le transfert mixte L2/L3. Un routeur pouvait commuter les paquets vers une branche existante au niveau 2 et router le même flux vers une nouvelle branche au niveau 3. Le premier paquet utilisait le chemin IP provisoire ; son arrivée permettait de créer l’état puis le LSP. Après vérification, la branche pouvait migrer vers MPLS. La fonction mixte n’était donc pas un compromis mal fini : elle préservait une voie réversible pendant la transition.
Cette coexistence exigeait de ne pas dupliquer le trafic par erreur. Le moteur L3 devait connaître les interfaces déjà desservies au niveau 2. Sans cette exclusion, la même copie pouvait sortir deux fois. La table de compatibilité du RFC rendait la contrainte concrète : un déclenchement par trafic avec demande d’étiquette du côté aval n’était valable que si le nœud amont savait maintenir cette branche L3 temporaire.
La portée probante de chaque signal restait limitée. Voir un paquet à l’amont prouvait une arrivée locale, pas l’existence de tous les récepteurs. Un défaut dans le cache de transfert multicast prouvait l’absence d’une entrée locale. Une ligne de table prouvait un état de contrôle. Un message d’étiquette prouvait une étape de signalisation. Une entrée matérielle prouvait une programmation locale. Même réunis, ces éléments demandaient encore une observation au récepteur pour conclure à la livraison.
L’exemple Unix du RFC montrait aussi que l’observation changeait lorsque l’exécution changeait de couche. Un premier paquet provoquait un défaut dans le Multicast Forwarding Cache du noyau ; le démon multicast renvoyait l’information de route. Si les paquets suivants étaient commutés en L2, les compteurs L3 ne les voyaient plus. L’entrée du cache risquait alors d’expirer alors que le flux continuait.
La solution évoquée consistait à alimenter les compteurs L3 avec des mesures L2. Elle était utile, mais elle changeait la sémantique de la mesure. Le compteur ne disait plus seulement ce que le moteur IP avait transféré ; il incorporait une projection produite par une autre couche. Sa fiabilité dépendait de la fraîcheur, de l’identifiant de branche, des remises à zéro et du lien entre mesure et entrée de cache.
La transition entre arbre partagé et arbre de source créait une autre zone grise. PIM-SM pouvait conserver simultanément (*,G) et (S,G). Pendant le basculement, les paquets d’une source pouvaient atteindre un routeur par les deux chemins. Le traitement L3 savait rejeter la mauvaise copie à partir de l’état source. Un transfert purement L2 devait tolérer un bref doublon, multiplier les étiquettes ou fusionner précisément les flux. L’étiquette ne remplaçait pas la décision de routage.
L’encapsulation imposait une frontière encore plus nette. Un émetteur pouvait encapsuler vers la racine d’un arbre partagé, qui décapsulait ensuite. Ces opérations étaient L3. Aucun LSP L2 unique ne pouvait traverser le point d’interprétation comme s’il n’existait pas. MPLS pouvait servir le tunnel ou d’autres branches, mais le diagramme devait conserver la rupture.
Même la signalisation « piggy-backée » avait un prix. Placer l’étiquette dans les messages multicast rapprochait route et label et réduisait les échanges séparés. Cela obligeait toutefois à modifier chaque protocole multicast, éliminait certaines combinaisons de déclencheurs et remplaçait souvent la fiabilité TCP de LDP par un état mou périodique. Une annonce synchronisée n’était toujours pas un reçu de réplication.
Les travaux ultérieurs ont donné davantage de structure à l’arbre. RFC 4461 a formulé les exigences des LSP P2MP à ingénierie de trafic : branches, feuilles, ajout, suppression, signalement de panne et passage à l’échelle. RFC 4875 a normalisé une signalisation RSVP-TE où plusieurs sous-LSP source-feuille sont assemblés aux routeurs de branchement. Il précise surtout qu’un état de signalisation peut se ramifier sans que le plan de données ne réplique effectivement les paquets. Le dessin de contrôle ne devient pas un constat de livraison.
RFC 5332 a corrigé une attente historique. RFC 3353 mentionnait des codepoints distincts pour MPLS unicast et multicast. En 2008, RFC 5332 a indiqué que cet usage n’avait jamais été déployé et a réaffecté le second codepoint aux étiquettes attribuées en amont sur les supports multiaccès. Puis RFC 6513 a conservé, dans les VPN multicast, le choix entre arbres de distribution et réplication à l’entrée par tunnels unicast. La réplication pouvait changer de lieu ; son coût ne disparaissait pas.
La contribution durable de RFC 3353 est donc moins un schéma de solution qu’une discipline de séquence. Avant la branche étiquetée, il fallait une observation, un chemin provisoire ou une initiative amont. Après la signalisation, il fallait encore programmer, répliquer et vérifier. Le premier paquet n’était pas la preuve que l’arbre existait ; il était la cause qui obligeait le réseau à décider comment le faire exister.
Sources
- RFC 3353 : IP Multicast dans un environnement MPLS
- Fiche RFC Editor de RFC 3353
- Errata de RFC 3353
- Historique IETF Datatracker de RFC 3353
- RFC 3031 : architecture MPLS
- RFC 3032 : encodage de la pile d’étiquettes MPLS
- RFC 3036 : spécification LDP
- RFC 2236 : IGMP version 2
- RFC 2362 : PIM en mode sparse
- RFC 4461 : exigences de signalisation P2MP TE MPLS
- RFC 4875 : extensions RSVP-TE pour LSP P2MP
- RFC 5332 : encapsulations multicast MPLS
- RFC 6513 : multicast dans les VPN IP MPLS/BGP
- Lu Heng : Running-Code Primacy
- Lu Heng : Minimum Initial Specification
- Lu Heng : Reality Layers
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
