Résumé
- RFC 2105 décrivait une architecture Cisco de catégorie Informational : une étiquette courte et de longueur fixe indexait la Tag Information Base, puis était remplacée à chaque saut avec les informations de liaison.
- Les protocoles de routage construisaient d’abord la FIB ; l’allocation et la distribution des étiquettes transformaient ensuite ce résultat en état exécutable, parfois avant l’arrivée du premier paquet.
- La même primitive de transfert pouvait servir le routage par destination, le multicast, la hiérarchie, les routes explicites, ATM et la QoS, mais l’étiquette n’attestait qu’une association locale, ni le consensus, ni l’identité, ni l’autorisation, ni la livraison.
L’opération visible venait en dernier
Le cœur de RFC 2105 tient en quelques étapes. Le commutateur reçoit un paquet étiqueté et recherche une correspondance exacte dans sa TIB. L’entrée fournit une ou plusieurs combinaisons : étiquette de sortie, interface de sortie et informations de liaison. La machine remplace les champs concernés et expédie le paquet.
Cette recherche était plus simple que la recherche du préfixe le plus long couramment associée au transfert IP. Elle convenait au matériel rapide et restait identique pour une sortie unicast ou plusieurs sorties multicast. Le gain venait de la réutilisation d’une décision déjà préparée.
L’étiquette ne transportait pourtant pas cette préparation. Elle ne disait pas quelle route avait produit l’association, quel voisin l’avait distribuée, si ce voisin était encore le prochain saut, quelle politique avait imposé une route explicite ou si le paquet avait atteint sa destination. Une permutation correcte prouvait l’exécution d’une entrée locale à un instant, rien de plus.
Un moteur stable sous des modules de contrôle variables
La rupture architecturale se trouve dans la séparation entre transfert et contrôle. Le composant de transfert exécutait toujours le même enchaînement : indexer, remplacer, transmettre. Le composant de contrôle créait les associations et les distribuait. Chaque nouvelle fonction de routage pouvait prendre la forme d’un module supplémentaire sans réinventer le chemin rapide.
Cette indépendance permettait une évolution progressive du contrôle tout en conservant le matériel. Elle séparait aussi les responsabilités. Un circuit capable de remplacer parfaitement une étiquette pouvait appliquer un état issu d’une information de routage périmée, d’une distribution incomplète ou d’une politique non autorisée. La fidélité de l’exécution ne garantit pas l’actualité de la décision.
Le routage donnait d’abord une forme à l’état
Pour le routage par destination, un tag switch participait toujours à OSPF, BGP ou à un autre protocole et construisait une FIB. RFC 2105 prévoyait une allocation en aval, une allocation en aval à la demande ou une allocation en amont. Dans le cas ordinaire en aval, le commutateur allouait une étiquette à chaque route de la FIB, créait l’entrée TIB et annonçait l’association aux voisins.
Le voisin utilisait comme étiquette de sortie celle annoncée par le prochain saut de la route. L’annonce pouvait accompagner un protocole de routage existant ou passer par le Tag Distribution Protocol proposé. Une fois les côtés entrant et sortant renseignés, le transfert par échange d’étiquettes devenait possible.
L’ordre est essentiel : la portée réseau précédait son identifiant compact. TDP ne doit pas non plus être projeté rétroactivement sur LDP. RFC 5036 définit un protocole différent, avec découverte, sessions, messages de mapping et traitement d’erreurs propres.
L’allocation suivait la topologie, pas les rafales
Pour les routes de destination, RFC 2105 opposait son modèle aux mécanismes déclenchés par les flux. L’existence d’une entrée FIB pouvait provoquer l’allocation d’une étiquette avant tout paquet de données. Une étiquette pouvait désigner une route ou un groupe de routes.
Cette logique limitait la quantité d’état par la topologie connue, plutôt que par le nombre de conversations. Elle évitait de classifier chaque flux et résistait mieux aux variations de trafic. Mais un état précalculé ne survivait pas magiquement à la réalité qui l’avait produit. Route, prochain saut, voisinage et époque de distribution restaient ses conditions de validité.
Une TIB ancienne peut donc être très performante et néanmoins fausse. Le matériel continue de donner une réponse nette alors que la question du contrôle a changé.
Les recherches réseau subsistaient aux frontières
Un paquet sans étiquette exigeait une recherche réseau avant de recevoir sa première étiquette. Cette étape pouvait appartenir au premier routeur ou au premier équipement capable de Tag Switching sur le chemin.
L’agrégation créait une autre frontière. Si plusieurs routes regroupées derrière une seule étiquette ne partageaient pas le même prochain saut, le commutateur devait réexaminer la destination réseau. L’agrégation avait effacé une distinction dont la décision suivante avait encore besoin.
Le chemin rapide ne supprimait donc pas l’interprétation ; il évitait de la répéter partout. Dès que le contexte n’était pas encore créé ou avait été trop comprimé, l’en-tête réseau redevenait nécessaire.
La pile concentrait la connaissance extérieure aux bords
RFC 2105 proposait une pile d’étiquettes pour éviter que chaque équipement interne d’un domaine conserve toute la table extérieure. À l’entrée du domaine, le commutateur de bord ajoutait une étiquette interne au-dessus de l’étiquette existante. Le cœur ne traitait que le sommet pour atteindre la sortie. L’étiquette inférieure restait disponible pour la décision suivante, tandis que la supérieure pouvait être retirée à la sortie ou à l’avant-dernier saut.
La pile constituait une hiérarchie d’exécution, pas un journal. Chaque valeur n’avait de sens que dans son contexte local. Voir deux étiquettes ne révélait ni les annonces de contrôle, ni les alternatives rejetées, ni les changements de route survenus avant l’observation.
Une seule primitive pour plusieurs ambitions
En multicast, PIM ou un autre mécanisme construisait d’abord l’arbre. Le module Tag Switching associait ensuite des étiquettes locales aux interfaces de sortie et produisait une entrée TIB à sorties multiples. L’étiquette ne trouvait pas les récepteurs et ne construisait pas l’arbre.
Les routes explicites permettaient d’installer des associations différentes du chemin déterminé par la destination. L’ingénierie de trafic gagnait ainsi une primitive commune, mais le motif de la politique, sa capacité et son approbation restaient hors du paquet.
ATM semblait naturel parce que VPI et VCI fonctionnaient déjà comme des identifiants de commutation. Un commutateur ATM devait néanmoins participer au routage réseau et exécuter le contrôle Tag Switching ; l’agrégation pouvait encore nécessiter le transfert réseau. Un plan de contrôle ATM traditionnel pouvait coexister grâce à des ressources séparées, sans valider Tag Switching.
Pour la QoS, une classification initiale pouvait poser une étiquette de classe afin que les nœuds suivants retrouvent rapidement l’état d’ordonnancement. Les files et l’ordonnancement restaient orthogonaux. La présence de l’étiquette ne prouvait donc ni bande passante, ni perte, ni délai, ni résultat de service.
Un document Informational ne valait pas adoption
Le statut de RFC 2105 est sans ambiguïté : le texte ne provenait pas d’un groupe de travail IETF, n’était pas sur la voie des normes et ne définissait aucun standard Internet. Datatracker le classe aujourd’hui Legacy, sans approbation ni position formelle dans le processus normatif de l’IETF. La sécurité n’y est pas discutée ; la section de propriété intellectuelle signale la position possible de Cisco.
RFC 3031 a plus tard normalisé MPLS avec des labels localement significatifs, des FEC, des piles et des remplacements de proche en proche. La parenté structurelle est visible, mais RFC 3031 ne cite pas RFC 2105 par son numéro ni son titre. Tag Switching a montré une voie vers l’architecture ultérieure ; cela ne suffit pas à établir une causalité directe, une filiation logicielle ou un déploiement général.
Dans la grille de Lu Heng, la publication décrit ; le code exécuté rend réel. Une spécification minimale ne doit pas absorber les décisions futures, et la puissance symbolique ne doit pas emprunter la force de l’exécution. Ici, le document, l’association de contrôle, l’entrée TIB installée et la livraison observée constituent quatre preuves distinctes.
Sources
- RFC 2105, Cisco Systems' Tag Switching Architecture Overview
- Fiche RFC Editor de RFC 2105
- Fiche IETF Datatracker de RFC 2105
- Recherche d’errata pour RFC 2105
- RFC 3031, Multiprotocol Label Switching Architecture
- RFC 5036, LDP Specification
- RFC 1953, Ipsilon Flow Management Protocol Specification for IPv4
- RFC 1954, Transmission of Flow Labelled IPv4 on ATM Data Links
- RFC 2098, Toshiba's Router Architecture Extensions for ATM
- Running-Code Primacy
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
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
