Résumé
- RFC 3034 appelait « segment sans TTL » une suite de commutateurs Frame Relay qui échangeaient les DLCI sans décrémenter le TTL MPLS ; le coût des sauts devait donc être appliqué à une frontière.
- LDP pouvait propager un Hop Count jusqu’à l’entrée, qui débitait cette longueur avant d’admettre un paquet unicast ; ce nombre restait une assertion de contrôle, pas la trace du parcours du paquet.
Le compteur devait descendre, mais l’équipement au milieu ne possédait pas l’instruction. Un FR-LSR pouvait recevoir une trame, chercher son DLCI, écrire le DLCI de sortie et la transmettre. Cette opération suffisait au commutateur. Elle ne suffisait pas au modèle MPLS, dans lequel le TTL limite la portée d’un paquet et empêche une boucle de vivre indéfiniment.
Publié en janvier 2001 avec le statut Proposed Standard, RFC 3034 a traité ce défaut comme une contrainte d’interface entre matériels. Il n’a pas prétendu que le cœur avait soudain acquis une fonction absente. Il a défini un segment où les sauts n’étaient pas débités un par un, puis organisé leur paiement groupé à la frontière.
Le DLCI devenait l’étiquette active
Sur une liaison Frame Relay, la valeur d’étiquette MPLS courante occupait le champ DLCI. Les autres étiquettes, ainsi que les autres champs de l’entrée supérieure de pile, utilisaient l’encapsulation MPLS générique. Dans le cœur, le commutateur agissait donc sur le DLCI alors que le TTL et les autres informations significatives demeuraient dans la pile.
Cette représentation était volontairement partagée. En passant à une autre encapsulation, un LSR devait reconstruire la pile logique, appliquer l’opération puis la réencoder. Deux liens successifs d’un même LSP pouvaient montrer des formats différents sans que l’état logique ait changé.
À la sortie, si la dernière étiquette était retirée, la pile ne portait aucun identifiant explicite du protocole réseau. L’association d’étiquette devait permettre de le déduire. Elle commandait ainsi l’interprétation et le transfert dans un périmètre précis ; elle ne prouvait ni l’identité de l’émetteur, ni l’autorisation de la route, ni le passage effectif de la trame.
Un saut invisible n’était pas un saut gratuit
RFC 3034 nommait « non-TTL segment » une suite de FR-LSR de même niveau qui ne touchaient pas au TTL. Sans compensation, cinq commutateurs auraient consommé autant de portée que zéro. Une boucle située dans ce domaine aurait alors contourné l’une des garanties attendues du TTL.
Le texte résumait le calcul par TTL de sortie = TTL d’entrée - d, où d dépendait des encapsulations d’entrée, de transfert et de sortie. Une commutation Frame Relay de même niveau appliquait zéro dans le cœur, car le débit était reporté. Un saut MPLS générique appliquait normalement un. L’entrée dans le segment Frame Relay pouvait appliquer le nombre total de sauts propagé.
Pour l’unicast, la longueur significative remontait vers l’entrée et y était soustraite avant le premier échange de DLCI. Pour le multicast, elle était propagée vers la sortie, qui effectuait le débit approprié. Le lieu de l’opération changeait ; l’exigence restait la même : le matériel incapable de modifier le TTL ne devait pas rendre sa portion de chemin inexistante.
L’admission pouvait être refusée avant le premier échange
Le paiement anticipé permettait de prendre une décision avant de remettre le paquet au segment. Si le TTL unicast devait expirer avant la sortie selon la longueur connue, l’entrée ne devait pas envoyer le paquet sous étiquette dans le segment sans TTL.
Elle devait alors tenter de produire l’erreur ICMP prévue par les règles MPLS ou transmettre le paquet sans étiquette avec le TTL correspondant au transfert IP. Pour un TTL entrant égal à un, seule la tentative d’erreur était possible.
Le verbe « tenter » compte. Une erreur construite n’est pas une erreur reçue par la source. Un paquet confié au transfert IP n’est pas un paquet livré. La preuve disponible à cette étape porte seulement sur la décision d’admission et sur les valeurs qui l’ont produite.
Hop Count décrivait une dépendance de contrôle
LDP pouvait joindre un objet Hop Count à l’association d’étiquette. Un nombre connu reçu de l’aval était incrémenté avant d’être annoncé à l’amont ; une valeur inconnue restait inconnue. Un dépassement du maximum interdisait de propager l’association et déclenchait une erreur.
Avec le contrôle ordonné, un FR-LSR attendait l’association aval avant de répondre et pouvait annoncer immédiatement un nombre incrémenté. Avec le contrôle indépendant, il pouvait distribuer plus tôt une association marquée « nombre inconnu », puis corriger l’annonce lorsque le chemin aval devenait connu. Si LDP n’apportait aucun nombre utilisable, le calcul décrit par RFC 3034 employait un défaut égal à un.
Ce défaut était une règle de comportement, pas une mesure. Il ne transformait pas un chemin inconnu en chemin observé d’un saut. Même une valeur connue restait construite par les messages de distribution : elle n’attestait ni que chaque commutateur était vivant, ni qu’un paquet donné avait emprunté cette suite, ni que la sortie l’avait reçu.
Une nouvelle route devait invalider l’ancienne arithmétique
Le nombre pouvait évoluer alors que l’amont possédait déjà une association. La fin d’une découverte aval, un changement de prochain saut ou une nouvelle association pouvait modifier la longueur. Le FR-LSR devait incrémenter et propager la nouvelle valeur vers l’entrée. Si elle dépassait le maximum, il devait retirer les étiquettes concernées à ses voisins amont afin que la détection de boucle ne repose pas sur une valeur impossible.
Les échecs réduisaient aussi l’autorité de l’état stocké. Une demande aval non satisfaite imposait de détruire l’association provisoire créée pour l’amont et d’envoyer un retrait. La perte d’une session LDP obligeait à jeter les associations apprises par cette connexion. Même la rétention libérale n’autorisait la réutilisation que si route et Hop Count répondaient aux conditions du RFC.
Une ligne présente dans une base d’étiquettes n’était donc pas une preuve suffisante. Il fallait encore savoir de quelle session elle provenait, si sa dépendance aval survivait et si son nombre correspondait à la route désormais choisie.
Adapter le matériel ne fusionnait pas les couches
RFC 3034 permettait au même équipement de participer au routage réseau, à la distribution d’étiquettes et à la commutation Frame Relay. Le contrôle Frame Relay traditionnel et le contrôle MPLS pouvaient coexister indépendamment, en ne partageant que des ressources bornées comme la partition de l’espace DLCI. Le fonctionnement combiné restait hors périmètre.
Cette séparation explique la portée exacte du compromis. Le plan de contrôle annonçait une longueur ; l’entrée en tirait un débit ; le cœur exécutait ses échanges de DLCI. Aucun de ces reçus ne remplaçait les autres. RFC 3034 a déplacé une opération pour respecter les limites du silicium. Il n’a pas déplacé la vérité du parcours dans le nombre annoncé.
Sources
- Notice RFC Editor de RFC 3034
- RFC 3034 en HTML
- RFC 3034 en texte
- RFC 3031, architecture MPLS
- RFC 3032, codage de la pile d’étiquettes MPLS
- RFC 3036, protocole LDP
- RFC 2427, interconnexion multiprotocole sur Frame Relay
- RFC 3035, MPLS avec commutation de VC ATM
- RFC 3443, traitement du TTL dans les réseaux MPLS
- Lu Heng sur la primauté du code en fonctionnement
- Lu Heng sur la spécification initiale minimale
- Lu Heng sur les couches de réalité
Lu Heng n’a ni rédigé ni approuvé RFC 3034 ou les normes connexes. Ses essais servent ici de cadres analytiques explicitement déclarés.
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
