Résumé

  • RFC 3037 recommandait l’implémentation de LDP aux équipements qui transféraient MPLS selon les chemins normalement choisis par le routage de destination ; il n’en faisait ni une obligation universelle ni une preuve d’exploitation.
  • Le document séparait le LDP de base de l’ingénierie de trafic à routes explicites et décrivait une chaîne distincte : découverte, TCP, négociation, session opérationnelle, association, programmation et paquet observé.

Un texte d’applicabilité répond à la question « où ce protocole convient-il ? ». Il ne répond pas à « où tourne-t-il ? ». Cette différence paraît élémentaire, mais une seule phrase de RFC 3037 pouvait facilement l’effacer : l’implémentation de LDP était recommandée pour les équipements transférant MPLS sur des chemins normalement routés.

Publié en janvier 2001 comme RFC Informational, le document situait LDP parmi plusieurs méthodes de distribution d’étiquettes. Sa recommandation portait sur une fonction et un type de chemin. Elle ne recensait aucun produit, ne lisait aucune configuration et n’observait aucun paquet.

Le périmètre suivait le prochain saut du routage ordinaire

Deux Label Switching Routers devaient partager le sens des étiquettes utilisées entre eux. LDP fournissait les procédures par lesquelles un LSR annonçait une association entre une classe d’équivalence de transfert et une étiquette. RFC 3037 visait les chemins déterminés par les protocoles de routage fondés sur la destination : le transfert MPLS saut par saut.

Cette indépendance avait une utilité concrète. Avec un plan de routage IP et un logiciel de programmation des cross-connects, LDP pouvait faire passer IP dans un réseau de commutateurs ATM ou Frame Relay sans superposition ni système d’adressage propre à ces technologies. Protocole autonome, il n’exigeait pas non plus qu’un même protocole de routage étendu pour les étiquettes soit présent à chaque saut.

Le verbe « pouvait » fixe toutefois une limite. Il décrit une architecture possible. Il ne montre pas que le logiciel de programmation existait sur un commutateur donné, que les pairs se voyaient, ni qu’un LSP avait été créé. Supprimer une dépendance de conception n’est pas prouver l’exécution.

Une route explicite appartenait à un autre contrat

Le chemin ordinaire n’était pas l’ingénierie de trafic. Un LSP explicitement routé pouvait s’écarter du prochain saut que le routage aurait choisi. RFC 3037 citait alors deux familles d’extensions, CR-LDP et RSVP-TE, et constatait qu’aucun consensus n’établissait leur supériorité technique. Le choix revenait aux administrateurs selon leur situation.

Le mécanisme d’extension de LDP rendait possible l’ajout de messages et de TLV. Cette possibilité n’incorporait pas automatiquement les fonctions supplémentaires au protocole de base. Il fallait encore définir l’extension, l’implémenter des deux côtés, la configurer et vérifier son comportement.

Le statut de la phrase de 2001 doit aussi rester daté. RFC 3468 a enregistré en 2003 une décision ultérieure du groupe MPLS et de l’IESG : concentrer les nouveaux travaux sur RSVP-TE et ne plus entreprendre de nouveau travail de groupe sur CR-LDP. Les RFC CR-LDP existants gardaient leur statut, et les contributions individuelles n’étaient pas interdites. Cette réorientation des travaux n’est ni un effacement rétroactif du constat de 2001, ni une mesure de tous les réseaux déployés.

La recommandation visait une capacité conditionnelle

RFC 3037 ne disait pas que chaque équipement MPLS devait implémenter LDP. Il recommandait cette implémentation aux appareils assurant un transfert MPLS selon des routes normales et fondées sur la destination. La condition et le niveau d’exigence faisaient partie du sens.

Même remplie, la recommandation ne franchissait pas les étapes suivantes. Un binaire peut contenir LDP alors que le service est désactivé. Un service actif peut ne découvrir aucun pair. Une découverte peut ne pas aboutir à TCP. TCP peut s’ouvrir sans accord sur les paramètres. Une session opérationnelle peut ne distribuer aucune association utile. Une association peut ne pas être programmée dans le plan de données. Une entrée de transfert peut ne voir aucun paquet.

Chaque transition exige son reçu. Attribuer au mot « recommandé » l’autorité de toute la chaîne transforme une préférence de conception en télémétrie imaginaire.

TCP ne formait qu’une partie de la chronologie

Le texte résumait une séquence précise. La découverte identifiait un pair potentiel. La procédure d’établissement créait une connexion TCP. Les LSR négociaient ensuite les paramètres, dont la méthode de distribution. Après accord, la session devenait opérationnelle et servait aux associations d’étiquettes.

TCP assurait une livraison fiable des messages de session. Grâce à lui, les associations et l’état du LSP n’avaient pas besoin d’un rafraîchissement périodique. Cette efficacité ne certifiait pas le sens de l’état. Un octet livré n’est pas une association acceptée ; une association acceptée n’est pas une entrée matérielle ; une entrée matérielle n’est pas une livraison applicative.

L’absence de rafraîchissement périodique rendait aussi l’histoire nécessaire. Lors d’un incident, la présence d’un état durable ne disait pas à elle seule si sa dépendance de routage était encore actuelle. La continuité de session, le prochain saut, le cycle de l’association et les compteurs du plan de données devaient conserver leurs propres dates.

Les modes traduisaient un pari sur la rareté

LDP proposait plusieurs axes indépendants. Downstream Unsolicited annonçait une association lorsque le LSR se disait prêt à transférer la FEC ; Downstream on Demand répondait à une demande précise. La rétention libérale gardait toutes les étiquettes apprises ; la rétention conservatrice rendait celles qui n’avaient pas d’usage immédiat. Le contrôle indépendant annonçait selon la décision locale ; le contrôle ordonné attendait l’association du prochain saut de la FEC ou le rôle de sortie.

RFC 3037 recommandait un assemblage lorsque les valeurs d’étiquette étaient rares, notamment sur ATM et Frame Relay : demande aval, rétention conservatrice et contrôle ordonné. Lorsque les étiquettes abondaient, annonce non sollicitée, rétention libérale et contrôle indépendant pouvaient préparer un changement de prochain saut sans nouvelle distribution.

Ce n’était pas un classement universel. Le protocole permettait d’autres combinaisons et des variantes hybrides. Économiser les étiquettes réduit les alternatives conservées ; garder les alternatives consomme de l’état. Annoncer tôt réduit une attente mais avance une assertion avant sa dépendance aval. Le choix n’est démontré correct qu’avec les contraintes et résultats du réseau concerné.

Une fonction obligatoire pouvait rester éteinte

La détection de boucle rendait la distinction presque littérale. LDP définissait un mécanisme pour les LSP traversant des nuages MPLS qui ne décrémentaient pas le TTL. Un LSR conforme devait l’implémenter. La configuration pouvait néanmoins le désactiver.

« Implémenté » et « activé » pouvaient donc être vrais séparément. Même activé sur une machine, le mécanisme n’était pas automatiquement cohérent dans tout le domaine. Il fallait connaître la configuration des autres LSR, les attributs propagés, la route et le chemin effectivement suivi.

Le système d’extension promettait lui aussi un traitement défini des messages ou TLV inconnus. RFC 3037 avertissait que toute évolution future ne serait pas nécessairement rétrocompatible. Savoir refuser proprement une capacité inconnue n’équivaut pas à partager cette capacité.

Les considérations d’échelle n’étaient pas des mesures

La distribution incrémentale supprimait le rafraîchissement périodique. Les modes conservateurs limitaient l’allocation lorsque les étiquettes étaient rares. La rétention libérale évitait certaines redistributions après un changement de prochain saut. En sens inverse, le nombre de connexions TCP supportées bornait le nombre de pairs, et la détection par vecteur de chemin ajoutait mémoire, calcul et trafic LDP.

Ces relations indiquaient quels coûts observer ; elles ne donnaient la capacité d’aucun produit. Le chiffre réel devait venir des connexions, de l’espace d’étiquettes, de la mémoire, du processeur, des messages, du temps de reconvergence et des paquets.

La sécurité restait également bornée. L’option TCP MD5 pouvait limiter l’injection de segments falsifiés dans le flux d’une session. Elle ne prouvait ni la légitimité d’une FEC, ni l’autorisation d’une route, ni la vérité d’une association, ni la sécurité du service transporté.

RFC 3037 ne promettait donc pas l’exécution. Il distribuait correctement les verbes : le standard recommande, le fournisseur implémente, l’opérateur active, les pairs négocient, le matériel installe et les paquets témoignent. Confondre ces sujets ferait du document une preuve qu’il n’a jamais prétendu fournir.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3037 ou les normes connexes. Ses essais servent ici de cadres analytiques explicitement déclarés.