Résumé

  • Si seul le lecteur tombe en panne, un compteur resté en fonctionnement peut conserver les volumes cumulés. Leur récupération dépend toutefois de la continuité du flux et de la conservation des données nécessaires.
  • Les collectes manquées réduisent la résolution temporelle disponible. Les règles de classement, l’identité des flux et les relevés effectivement conservés déterminent ce que l’analyse peut encore établir. RFC 2063, §§ 2.5, 3.2–3.3 et 5.2.

Imaginons un lecteur arrêté entre deux collectes, tandis que son compteur poursuit la mesure : cette situation est hypothétique. Au redémarrage du lecteur, une entrée de flux peut encore livrer les nombres cumulés de paquets et d’octets, ainsi que les heures du premier et du dernier paquet. Si le même flux a subsisté, sous des règles inchangées, avec suffisamment d’état conservé et sans débordement ambigu des compteurs, la différence avec le dernier relevé donne le volume ajouté. Le § 2.5 décrit cette reprise conditionnelle. En revanche, plusieurs répartitions du trafic restent compatibles avec ces mêmes données : l’impossibilité de retrouver les pointes internes à l’interruption est une déduction de l’absence de collectes intermédiaires, et non le récit d’un incident documenté. RFC 2063.

Trois fonctions, trois parts de l’historique

Publié en janvier 1997 dans le corpus de l’IETF, le RFC 2063 est signé Nevil Brownlee (The University of Auckland), Cyndi Mills (BBN Systems and Technologies) et Greg Ruth (GTE Laboratories, Inc.). Expérimental, il ne constitue ni une norme Internet ni une spécification de protocole : il organise les informations, les besoins et les compromis de mise en œuvre. RFC 2063, § 1.

Son « flux » est une construction logique : des règles rassemblent des paquets IP indépendants selon leurs attributs. L’entité à laquelle ce trafic est imputé peut être un utilisateur, un hôte, un réseau ou un groupe, sans authentifier pour autant un payeur. Le compteur classe et cumule ; le lecteur achemine les données d’usage vers l’analyse ; le gestionnaire définit la mesure et pilote les lecteurs. Ces fonctions peuvent partager une machine. Le gestionnaire choisit notamment granularité, échantillonnage et gestion des flux inactifs ; il donne au lecteur les compteurs, intervalles, flux et attributs à relever. RFC 2063, §§ 2.1–2.4.

Le Rule Set ID identifie les règles de classement indispensables à l’interprétation. L’heure de début du flux aide à distinguer une entrée continue d’un nouveau flux présentant les mêmes adresses. Le relevé du lecteur comporte notamment l’identité du compteur, un horodatage, l’identifiant des règles de collecte, les descripteurs et les comptes ; le lecteur conserve ces relevés dans des fichiers sur disque, par compteur. Le texte recommande le cumul continu, sans remise à zéro à chaque lecture : additionner des relevés qui se recouvrent compterait plusieurs fois le même trafic. Dans ce schéma, chaque paquet appartient à un seul flux ; des analyses qui se chevauchent demandent des groupes élémentaires disjoints, puis un traitement des résultats. RFC 2063, §§ 3.2–3.3 et 5.2.

Des collectes libres, sans instantané commun

Le lecteur peut demander toute la table, certaines lignes ou certains attributs, sans synchronisation obligatoire. Deux lecteurs ayant la même période, mais des décalages différents, ont donc peu de chances d’obtenir exactement les mêmes valeurs. Ce désaccord ne suffit pas à démontrer une corruption. Des lecteurs redondants protègent la continuité des collectes ; des compteurs redondants sur un même segment couvrent la défaillance d’un compteur. Les deux protections portent sur des risques différents. RFC 2063, §§ 2.2 et 2.5.

La MIB expérimentale contemporaine du RFC 2064 permet des parcours indépendants grâce à des index sans état de parcours partagé ; TimeFilter et GetBulk facilitent la récupération sélective des entrées modifiées. Une collecte commence par l’écriture de flowReaderLastTime : ce marqueur ne certifie pas un instantané atomique de toute la table. Les lecteurs enregistrés, flowReaderLastTime et flowReaderPreviousTime contribuent à gérer la libération de mémoire ; flowReaderTimeout permet de retirer une inscription trop longtemps inactive. Une lecture peut même continuer alors qu’un échec d’écriture ou d’authentification entrave cette gestion. RFC 2064, § 3.2 et définition des objets.

Ce que la mémoire et les règles permettent de sauver

L’architecture de 1997 exige qu’un flux inactif ait été collecté par au moins un lecteur avant que son entrée soit réutilisée. Elle laisse cependant à développer la politique complète de conservation pour plusieurs lecteurs. On ne peut donc en déduire que chaque lecteur retrouvera toutes les entrées après son absence. Sous pression mémoire, des règles de secours plus grossières ou des collectes rapprochées peuvent maintenir le compteur en activité, avec une possible brève perte de données. La conservation effective, les changements de règles, l’identité du flux et le débordement des compteurs bornent la reprise. RFC 2063, §§ 3.2 et 4.5–4.6.

Les textes successifs doivent rester distincts. Le RFC 2063 prévoit un seul gestionnaire de contrôle par compteur ou lecteur ; le RFC 2064 distingue déjà un gestionnaire maître et envisage un instantané approché par changement de jeu de règles. En octobre 1999, le RFC 2722, de statut Informational, remplace le RFC 2063. La reprise après panne du lecteur y reste assortie d’une perte de résolution temporelle. Il permet des jeux de règles et gestionnaires concurrents, précise l’attente de tous les lecteurs enregistrés avant réutilisation des entrées et le retrait d’un lecteur défaillant après expiration du délai. L’alternance de deux jeux identiques sur un compteur peut produire des relevés identiques du jeu arrêté, sans garantir un basculement simultané entre plusieurs compteurs. Ces précisions de 1999 ne décrivent pas rétrospectivement toutes les réalisations de 1997. RFC 2063, § 2.3, RFC 2064, § 3, RFC 2722, §§ 2.3, 2.5 et 4.5.

Enfin, une panne du gestionnaire devrait laisser mesure et collecte continuer. L’arrêt annoncé d’un compteur peut donner lieu à une dernière collecte. Un redémarrage imprévu peut être signalé au gestionnaire ou découvert par interrogation du lecteur ; recharger les règles correctes ne restitue ni l’état disparu ni le trafic non mesuré. Les notifications proposées n’offrent pas de garantie de livraison. SNMP est un transport possible, sans être imposé ; intégrité et confidentialité relèvent des protocoles de gestion et de collecte. Tarification et objectifs de recouvrement restent hors périmètre : les volumes ne suffisent à établir ni facture valide, ni service utile rendu, ni paiement. RFC 2063, §§ 1, 5.3, 6.3 et 10.

Sources et portée des constats

Ces documents établissent une architecture et son évolution, sans démontrer un déploiement précis ou son degré d’adoption. Les trois essais ultérieurs de Lu Heng proposent ici une lecture éditoriale : distinguer publication et fonctionnement observé, réserver un sens commun aux mesures tout en laissant les choix d’exploitation locaux, et expliciter les hypothèses plutôt que défendre une solution. Ils ne prouvent aucun comportement technique de 1997 ni aucune intention politique des auteurs.