Résumé

  • La RFC 1513 étendait RMON aux réseaux Token Ring. Son compteur dropEvents recensait les épisodes de manque de ressources de la sonde, pas le total exact des trames qu’elle n’avait pas pu traiter.
  • Le texte prévenait aussi qu’un rapport d’erreur « soft » livré de manière assurée pouvait être observé deux fois. Le rapporteur, son voisin amont, l’ordre des stations et la fenêtre d’échantillonnage faisaient donc partie de la preuve.
  • Voir un nombre, attribuer une panne, autoriser le retrait d’une station et constater le résultat étaient quatre actes distincts. Les RFC RMON ultérieures ont nommé séparément les compteurs de trames effectivement perdues.

La question que le compteur refusait

RMON proposait une économie élégante : laisser une sonde regarder le réseau en continu et ne remonter que des tables et des compteurs. La RFC 1271 organisait ce travail en neuf groupes. Beaucoup de ses vues étaient conçues pour Ethernet. Publiée en septembre 1993, la RFC 1513 ajoutait les objets nécessaires à IEEE 802.5 Token Ring ainsi que des groupes propres aux stations, à leur ordre, à leur configuration et au routage par la source.

Au cœur de cette architecture, une phrase empêchait un chiffre honnête de devenir une conclusion fausse. tokenRingMLStatsDropEvents augmentait lorsque la sonde rejetait des paquets faute de ressources. Mais la valeur n’était « pas nécessairement » le nombre de paquets rejetés : elle comptait les occurrences détectées de la condition.

Une occurrence pouvait couvrir une trame ou une rafale. Une autre pouvait durer davantage sans produire un chiffre plus grand. La sonde savait combien de fois elle avait reconnu sa pénurie ; elle ne prétendait pas avoir compté ce qu’elle n’avait précisément pas pu observer.

Ce n’est pas l’incertitude d’une mesure mal faite. C’est la frontière d’une mesure bien nommée.

La sonde faisait partie de l’événement

Le réseau observé n’était pas seul à pouvoir défaillir. L’observateur avait une capacité, des files, une mémoire et un cycle de vie. Lorsqu’il saturait, son compteur décrivait à la fois une lacune dans la visibilité et l’état de la sonde.

La RFC 1513 répétait cette sémantique dans les statistiques courantes, la vue « promiscuous » et les tables historiques par intervalle. Pour interpréter une variation, il fallait conserver l’interface source, l’index de la ligne de contrôle, son propriétaire, son statut, l’instant d’activation, l’intervalle et l’époque du compteur. Un redémarrage, une recréation de ligne ou un bouclage sur 32 bits pouvait fabriquer une continuité qui n’existait pas.

La suite de l’histoire rend la distinction encore plus nette. La RFC 4502 a défini des objets DroppedFrames dont la description précisait qu’ils donnaient, contrairement à dropEvents, le nombre exact de trames écartées de la collection. Deux noms, deux objets, deux prétentions probatoires.

Un rapport fiable pouvait être doublé

La RFC 1513 ajoutait une autre réserve. Les rapports d’erreurs non fatales pouvaient bénéficier d’une livraison assurée. Une sonde travaillant en écoute générale risquait donc de compter deux fois certaines erreurs.

La fiabilité du transport du rapport ne garantissait pas l’unicité de l’événement rapporté. C’est un paradoxe familier aux systèmes distribués : améliorer la livraison crée parfois des doublons qu’il faut reconnaître. Deux paquets vus ne suffisent pas à prouver deux erreurs physiques.

Il fallait rattacher le relevé à la station déclarante, au type d’erreur, à l’instant, au point de capture et à une règle de déduplication. Le document prouve que le doublon était possible ; il ne prouve aucune défaillance d’un produit ou d’un réseau nommé.

Le voisin n’était pas encore le coupable

La comptabilité des erreurs dépendait aussi de la topologie. Une erreur d’adresse copiée incrémentait l’entrée du voisin amont le plus proche de la station déclarante. Les erreurs de ligne et de rafale incrémentaient le rapporteur et son voisin amont. Les erreurs internes et d’abandon restaient attachées au rapporteur.

Ces règles construisaient une projection utile pour l’exploitation. Elles n’étaient pas une sentence causale. Un nom dans une case pouvait désigner celui qui avait parlé, celui qui se trouvait en amont ou la cible choisie par la règle de classement. Le groupe Ring Station Order donnait l’ordre des stations pour retrouver ce voisin, mais cette photographie ne prouvait ni la topologie au moment exact de l’erreur ni la livraison d’une trame.

Le tableau de bord moderne aime une cause unique. La RFC gardait au contraire les rôles séparés : rapporteur, voisin, catégorie comptable et cause physique.

Observer n’autorisait pas à agir

Le groupe de configuration permettait des opérations actives : retirer une station de l’anneau ou lui télécharger une configuration. Pourtant, la RFC rappelait que le niveau d’accès d’un objet disait seulement si lire ou écrire avait un sens protocolaire. Il était indépendant de la politique administrative d’autorisation.

Un objet read-write n’accordait donc aucun mandat. Et un dropEvents en hausse ne justifiait pas à lui seul une expulsion : la hausse pouvait d’abord révéler la saturation du témoin. Il fallait une autre chaîne de reçus — identité du demandeur, décision d’autorisation, cible, topologie préalable, commande, réponse, état après action et effet sur le service.

Les statistiques de routage par la source étaient elles aussi une vue partielle. Elles dépendaient d’informations optionnelles présentes dans certaines trames. Elles décrivaient ce que la sonde avait pu classer, pas un chemin universel ni l’arrivée du trafic.

Ce que l’archive permet d’affirmer

La notice RFC Editor et le Datatracker établissent la publication, la filiation et le statut historique. Les RFC 1271, 1757, 2021, 2819, 3577 et 4502 replacent ce module dans la famille RMON.

Elles ne prouvent ni déploiement précis, ni perte mesurée, ni panne, ni défaut de constructeur, ni efficacité d’une intervention. Le classement historique n’est pas un rapport d’incident.

Running-Code Primacy rappelle qu’une norme ne devient vérité opérationnelle qu’avec l’exécution et le résultat. Minimum Initial Specification invite à fixer un sens commun minimal sans masquer les décisions locales. On Reality Layers demande de ne pas confondre le symbole avec la réalité qu’il projette.

Le compteur 42 pouvait donc attester 42 détections de pénurie. Il ne pouvait pas, sans autres reçus, devenir 42 trames perdues, 42 pannes ou 42 motifs d’écarter une station.

Sources

  1. RFC 1513 — notice
  2. RFC 1513 — texte
  3. RFC 1513 — Datatracker
  4. RFC 1271 — notice
  5. RFC 1271 — texte
  6. RFC 1757 — notice
  7. RFC 1757 — texte
  8. RFC 2021 — notice
  9. RFC 2021 — texte
  10. RFC 2819 — notice
  11. RFC 2819 — texte
  12. RFC 3577 — notice
  13. RFC 3577 — texte
  14. RFC 4502 — notice
  15. RFC 4502 — texte
  16. Running-Code Primacy
  17. Minimum Initial Specification
  18. On Reality Layers