Résumé

  • Dans RFC 3988, la MTU d’un LSP résultait du minimum des contraintes locales et des seuls voisins réellement choisis pour acheminer la FEC.
  • Une diminution devait remonter immédiatement, car une ancienne valeur optimiste pouvait provoquer des pertes; une augmentation pouvait attendre, car l’ancienne valeur prudente restait sûre.

Publié en février 2005 comme document expérimental, RFC 3988 ajoutait à LDP un signal de MTU. Sa fiche, ses errata et son historique circonscrivent le problème. LDP distribuait une étiquette, mais ne donnait pas au routeur d’entrée la taille utilisable sur tout le chemin commuté. Une configuration hors ligne trop généreuse pouvait donc autoriser un paquet qu’un LSR intérieur jetterait sans bruit.

Le nouveau TLV paraissait n’être qu’un nombre. Son calcul racontait pourtant qui détenait quelle part de vérité. Une session LDP ne suffisait pas à faire d’un voisin une contrainte du chemin. RFC 3988 distinguait les LSR pairs, qui annonçaient la FEC, des LSR aval retenus par la table de routage pour transporter effectivement les paquets. Seul ce second ensemble entrait dans le minimum. La présence dans le plan de contrôle n’établissait pas la présence dans le plan de données.

La portée des valeurs devait également rester visible. La MTU de lien incluait en-tête IP, charge utile et pile d’étiquettes, mais pas les en-têtes de couche inférieure. Le « lien » pouvait être une interface, un tunnel GRE ou IPsec, voire un autre LSP. La MTU de saut liait un LSR amont à un LSR aval; plusieurs liens de transfert imposaient leur minimum. La MTU de LSP couvrait tous les chemins de transfert valides jusqu’à la ou aux sorties.

RFC 3032, sa fiche, ses errata et son historique expliquent les quatre octets retirés par une étiquette MPLS ordinaire. Dans l’exemple de RFC 3988, un lien de 1 500 octets devient un saut de 1 496 octets. Un LSP transporté dans un autre LSP peut tomber à 1 492. La capacité n’est donc pas celle du port prise isolément; elle dépend de l’encapsulation reçue à cet endroit.

Le calcul remontait depuis la sortie, initialisée à la valeur sentinelle 65 535. Pour chaque aval choisi, le LSR prenait le plus petit chiffre entre sa MTU de saut et la MTU annoncée par cet aval. Il retenait ensuite le minimum de tous ces résultats. Si un Mapping ne portait aucun TLV, sa contribution devenait 65 535, afin que les limites locales connues continuent de borner le résultat. Cette sentinelle ne constituait nullement une mesure d’un chemin géant.

Un opérateur pouvait annoncer moins que le résultat calculé, jamais davantage. L’erreur admissible n’était donc pas symétrique. Sous-estimer la capacité laissait de la bande passante inutilisée. La surestimer transformait un chiffre de contrôle en permission d’émettre des paquets condamnés plus loin. Le TLV dessinait une enveloppe de prudence, non une promesse de débit.

La règle de mise à jour rendait cette asymétrie temporelle. Une nouvelle annonce aval ou un changement de l’ensemble aval déclenchait un nouveau calcul. Si le résultat baissait, le LSR devait le réannoncer immédiatement; s’il augmentait, il pouvait retarder l’annonce. Après un élargissement, l’ancienne petite valeur restait sûre. Après un rétrécissement, l’ancienne grande valeur devenait dangereuse. La fraîcheur utile dépendait donc du sens de la variation.

Le passage par un équipement qui ne comprenait pas le TLV ajoutait une limite de provenance. Les bits de propagation ordonnaient à ce LSR d’ignorer localement l’attribut inconnu tout en le transmettant. RFC 3988 reconnaissait qu’un calcul incorrect pouvait en résulter, mais préférait préserver le maximum d’information. Transporter une affirmation n’équivalait ni à la comprendre ni à la valider.

Ce comportement héritait de RFC 3036, dont la fiche, les errata et l’historique conservent la première spécification LDP. RFC 5036, avec sa fiche, ses errata et son historique, l’a ensuite remplacée. Cette filiation normalise le cadre LDP; elle ne prouve pas le déploiement de l’extension expérimentale.

À l’entrée, la valeur devenait la limite du prochain « réseau » au sens de RFC 1191, de sa fiche, de ses errata et de son historique. Un paquet IPv4 pouvait être fragmenté si cela était permis; avec DF, il devait être abandonné et signalé par ICMP. Cette réaction prouvait une décision d’entrée fondée sur l’enveloppe. Elle ne prouvait ni le passage de chaque saut ni la réception applicative.

Enfin, RFC 3209, sa fiche, ses errata et son historique fournissaient le contexte des tunnels RSVP-TE. RFC 3988 pouvait traiter un tunnel comme un lien. Une limite de chemin dépendait alors d’une autre limite, de la profondeur d’étiquettes, du choix des avals et de l’âge de leurs annonces.

L’apport historique de RFC 3988 tient à cette priorité accordée à la mauvaise nouvelle. Une restriction retardée crée une possibilité fictive et de la perte silencieuse. Une amélioration retardée crée surtout de la prudence. Le nombre reste pourtant une conclusion du plan de contrôle: même exact et récent, il n’est pas le reçu d’un paquet livré.

Sources