Résumé

  • Dans RFC 3970, un tunnel de trafic était actif dès qu’au moins un de ses chemins l’était ; des objets séparés mesuraient le temps du tunnel et celui du chemin principal.
  • Les routes configurée, calculée et enregistrée par la signalisation restaient distinctes, tandis que notifications facultatives et limitées, compteurs discontinus et TimeTicks cycliques ne formaient pas un journal exhaustif.

Le mot « actif » rassure parce qu’il paraît fermer la question. Pourtant, le modèle publié en janvier 2005 dans RFC 3970 l’ouvrait immédiatement. Un tunnel d’ingénierie de trafic était une entité logique réalisée par un ou plusieurs chemins. Il était déclaré actif lorsqu’au moins un chemin était actif. La route principale pouvait donc être indisponible pendant qu’un secours préservait l’état global.

Cette agrégation était utile. Elle devenait trompeuse seulement si on lui faisait dire davantage. Le MIB conservait séparément le temps total de fonctionnement du tunnel et le temps de fonctionnement de son chemin principal. La différence permettait d’observer la continuité du service sans confondre cette continuité avec le respect de la trajectoire préférée.

Le module reposait sur les mots normatifs de RFC 2119, la structure SMIv2 de RFC 2578, RFC 2579 et RFC 2580, puis sur l’architecture SNMP de RFC 3411 et son guide dans RFC 3410. Ces textes rappellent qu’un MIB est une représentation administrée : il expose des objets, pas une copie complète du réseau.

Trois routes, puis la circulation réelle

La hiérarchie séparait tunnels, chemins et sauts. À l’intérieur d’un chemin, RFC 3970 conservait trois récits. La route configurée exprimait la demande de l’opérateur. La route calculée venait d’un algorithme de contraintes dépendant de l’implémentation. La route enregistrée était celle rapportée par le protocole de signalisation. La valeur zéro signifiait qu’aucune route calculée ou enregistrée n’existait.

Ces objets ne formaient pas des sauvegardes interchangeables. Une contrainte pouvait produire un calcul différent de la liste initiale ; la signalisation pouvait établir encore autre chose ou échouer. Les exigences MPLS de RFC 2702, la signalisation RSVP-TE de RFC 3209 et l’histoire CR-LDP de RFC 3212 décrivaient des couches connexes, sans autoriser à déduire l’une de l’autre.

Les états du chemin étaient explicites. down signifiait échec de signalisation ; dormant, secours non signalé ; ready, chemin signalé mais ne transportant pas encore de trafic ; operational, chemin signalé et transportant effectivement. La réussite du plan de contrôle avait donc un état propre avant le passage des paquets.

Le MIB ne couvrait la configuration et l’observation qu’à l’entrée. Ce routeur devait employer un protocole tel que RSVP-TE pour informer les autres nœuds ; l’extension aux autres points restait à étudier. Une vue complète à l’entrée ne certifiait pas chaque transit ni l’application à la sortie.

La photographie n’était pas l’histoire

Les compteurs d’octets et de paquets pouvaient subir une discontinuité lors de la réinitialisation du système de gestion ou à d’autres moments. Un horodatage spécifique signalait la dernière rupture. Sans lui, une différence entre deux lectures pouvait mélanger deux époques de compteur.

L’âge du tunnel, son temps actif et le temps sur le principal utilisaient TimeTicks, avec retour cyclique après environ seize mois. RFC 3970 proposait des calculs par intervalle et obligeait la station à traiter ce retour. Un grand nombre isolé n’était donc ni une date de naissance ni une mémoire perpétuelle.

Les notifications perdaient volontairement du détail. Les alertes de montée, de descente, de changement de chemin actif et de reroutage étaient limitées à une par minute lors de changements rapides. Leur groupe de conformité était facultatif et leur génération pouvait être désactivée ; la valeur par défaut était justement désactivée. Aucun message reçu pouvait signifier stabilité, fonction absente, génération coupée, perte de transport ou événement absorbé par la limitation.

Le vocabulaire distinguait même changement et reroutage. Un changement remplaçait le chemin actif ou en activait un nouveau. Un reroutage conservait l’identité du chemin mais changeait sa suite de sauts. L’identité du chemin n’était pas celle de la route.

Lire un index libre ne le réservait pas

Une application commençait par lire teNextTunnelIndex. Deux gestionnaires pouvaient obtenir simultanément la même valeur. L’agent ne tranchait qu’au moment du SET ; le perdant devait relire. La première lecture offrait un candidat, pas un droit acquis.

Certaines modifications demandaient de placer tunnel ou chemin notInService, de changer les propriétés, puis de revenir à active, ce qui pouvait relancer la signalisation. Le RowStatus gouvernait le cycle de vie de la ligne conceptuelle ; il ne rapportait pas le résultat du plan de données.

La conformité minimale autorisait tous les objets obligatoires en lecture seule. La conformité complète ajoutait les capacités d’écriture prévues. Les notifications restaient facultatives. Une déclaration de conformité à RFC 3970 ne prouvait donc ni configuration distante, ni livraison d’événements.

Le tunnel pouvait partager un identifiant avec l’Interfaces MIB et, sous conditions, avec l’IP Tunnel MIB. Les conventions MPLS provenaient de RFC 3811. Ces raccords reliaient les modèles ; ils ne transformaient pas interface, encapsulation, chemin signalé et service rendu en une seule preuve.

Observer était sensible ; écrire pouvait déplacer le trafic

Une modification non autorisée des groupes administratifs changeait le sens des contraintes. Modifier chemins, bande passante ou sauts pouvait provoquer oscillations, détours et interruption. La simple lecture révélait extrémités, volumes et routes, informations parfois confidentielles. RFC 3970 recommandait donc authentification et confidentialité SNMPv3 et déconseillait les versions antérieures.

Mais l’authentification cryptographique ne répondait qu’à l’identité du principal. La politique devait encore décider quels objets celui-ci pouvait lire, créer, modifier ou détruire. Identité, autorisation et résultat réseau demeuraient indépendants.

La fiche RFC Editor, la recherche d’errata et le Datatracker IETF établissent le statut documentaire. RFC 9141 a ensuite corrigé une référence d’archive devenue obsolète dans les coordonnées de contact. Aucun de ces documents ne mesure adoption, disponibilité ou incidents.

RFC 3970 n’offrait donc pas une vérité unique mais une collection de vérités bornées : état agrégé, état par chemin, intentions, calcul, signalisation, compteurs et événements réduits. La supervision devenait fiable lorsque chaque valeur restait liée à son mécanisme d’observation.

Sources