Résumé

  • Le RFC 869 a donné aux centres de surveillance une méthode commune pour interroger les hôtes, associer les réponses, recueillir états et statistiques, et recevoir des alertes spontanées. Il n’a pas rendu les rapports de tous les équipements interchangeables.
  • Le RFC 823 montre ce que cette distinction recouvrait pour une passerelle : interfaces, voisins, réseaux accessibles, matrice de trafic et compteurs de pertes, avec des formats de rapport qui dépendaient du type de machine.

Analyse

Une passerelle devait rendre son fonctionnement lisible

Le Host Monitoring Protocol (HMP) n’était pas seulement un moyen de vérifier qu’une machine répondait. Le RFC 823, consacré à la passerelle Internet de la DARPA, décrit la collecte de mesures et d’états par HMP. L’état d’une passerelle portait sur ses interfaces, ses passerelles voisines et les réseaux qu’elle pouvait atteindre. Sa matrice de trafic comptait les datagrammes selon leurs adresses IP source et destination et leur numéro de protocole. Un message de débit exposait, lui, des compteurs de trafic transmis, reçu ou abandonné, ventilés par interface et par voisin.

Ces données rendaient visible une partie du travail interne de la passerelle depuis le reste du réseau. La matrice pouvait révéler les flux qui la traversaient ; un compteur de pertes pouvait situer un problème dans l’équipement. Aucun de ces chiffres ne prouvait à lui seul qu’une application distante fonctionnait de bout en bout. Le RFC décrit un modèle d’ingénierie, pas un recensement indépendant des équipements réellement déployés.

Un cadre commun, mais des sens locaux

Publié en décembre 1983 par Robert Hinden, le RFC 869 remplaçait l’ancienne spécification IEN 197. Il qualifiait HMP de protocole de transport sans connexion et orienté transactions. Son en-tête comportait notamment le type de système, le type de message, un numéro de séquence, un champ « mot de passe ou numéro de séquence retourné » et une somme de contrôle. Le couple type de système/type de message indiquait comment interpréter les données. La liste comprenait les IMP, les contrôleurs d’accès aux terminaux (TAC), les passerelles et d’autres systèmes ; HMP utilisait le numéro de protocole IP 20.

Cette trame commune permettait de reconnaître les requêtes et de rapprocher une réponse de son interrogation. Elle ne transformait pas les compteurs d’une passerelle en description universelle de n’importe quel hôte. Le RFC précise que les types de message étaient définis pour chaque type de système selon ses besoins. Les annexes donnent des exemples de messages pour IMP, TAC et passerelles, mais l’introduction précise qu’ils ne font pas partie du protocole HMP. Le protocole normalisait la façon de demander et d’acheminer une réponse ; le format propre à l’équipement déterminait toujours ce que cette réponse signifiait.

Une alerte, un état et une statistique ne se lisaient pas de la même façon

Le RFC 869 plaçait l’essentiel de l’intelligence de surveillance dans un centre. L’hôte collectait les données puis les envoyait sur demande ou spontanément ; le centre devait s’assurer que les données demandées lui parvenaient. Pour les états et les statistiques, il lançait une interrogation puis pouvait la répéter si le délai expirait. Les numéros de séquence servaient à associer une réponse à sa requête et à repérer les statistiques reçues en double. Les mesures statistiques étaient mises en mémoire pendant un intervalle afin qu’une réponse perdue puisse être redemandée.

Les alertes spontanées suivaient une autre règle. L’hôte envoyait un datagramme lorsqu’un événement survenait, mais HMP ne prévoyait ni accusé de réception ni retransmission pour ce message. Une alerte était donc un signal rapide, pas un historique garanti des événements. L’état avait lui aussi une portée limitée : le centre pouvait conclure qu’un hôte était en service ou non selon ses réponses aux interrogations. Une absence de réponse ne permettait pas de savoir si l’hôte, le chemin, la requête ou la réponse avait échoué ; une réponse ne prouvait pas que le service applicatif fonctionnait.

La surveillance pouvait aussi modifier l’hôte

Une requête HMP pouvait demander des paramètres ou transporter des données de commande. Le RFC donne l’exemple de commutateurs ou de temporisateurs servant à régler les mesures, ainsi que celui d’un commutateur de redémarrage. L’hôte traitait les données puis renvoyait un accusé de commande, ou une erreur s’il ne pouvait pas les traiter. La signification et le format dépendaient de chaque type d’hôte. Cet accusé confirmait l’échange défini par le protocole ; le RFC n’en faisait pas la preuve qu’un service destiné à l’utilisateur fonctionnait après l’action.

Le RFC 1157 sur SNMP, publié en 1990, fournit un point de comparaison, pas une filiation démontrée. Il désigne le Simple Gateway Monitoring Protocol (SGMP) comme prédécesseur de SNMP et décrit un modèle centré sur la lecture ou la modification de variables, complété par un nombre limité d’alertes spontanées. L’histoire de HMP doit rester autonome : son enveloppe commune permettait à des équipements différents de fournir des rapports et de recevoir des données de commande propres à leur type.

En avril 1983, la liste des protocoles officiels, RFC 840, classait HMP comme « elective » et indiquait qu’il servait à surveiller les passerelles Internet et les TAC, ainsi qu’à déboguer les implémentations sur de petits ordinateurs distants. Le RFC 869 décrit lui aussi un usage sur passerelles et TAC alors que des implémentations pour d’autres hôtes étaient en préparation. Ces textes attestent un usage contemporain circonscrit, pas une adoption généralisée. Leur intérêt historique tient à la frontière qu’ils rendent visible : un échange commun rendait l’observation distante possible, mais le sens du rapport restait attaché à l’hôte qui l’émettait.

Sources