Zusammenfassung

  • RFC 869 gab einer Überwachungszentrale ein gemeinsames Verfahren, um Hosts abzufragen, Antworten zuzuordnen, Status- und Statistikmeldungen anzufordern und spontane Traps zu empfangen. Einheitliche Angaben aller Geräte daraus zu machen, war nicht das Ziel.
  • RFC 823 zeigt, was diese Trennung für ein Gateway bedeutete: Schnittstellen, Nachbarn, erreichbare Netze, eine Verkehrsmatrix und Verwerfungszähler ließen sich melden, doch Berichts- und Steuerdaten blieben vom jeweiligen Host-Typ abhängig.

Analyse

Ein Gateway musste mehr melden als ein Lebenszeichen

Das Host Monitoring Protocol (HMP) sollte nicht nur feststellen, ob ein Rechner antwortete. Die Spezifikation DARPA Internet Gateway von 1982 beschreibt, wie HMP Messwerte und Status von Gateways erfasste. Eine Statusmeldung enthielt Informationen über Schnittstellen, benachbarte Gateways und erreichbare Netze. Die Host Traffic Matrix zählte Datagramme nach IP-Quelladresse, Zieladresse und Protokollnummer. Eine Durchsatzmeldung führte Zähler für empfangene, weitergeleitete und gesendete Pakete sowie verworfene Daten, jeweils nach Schnittstelle und Nachbar aufgeschlüsselt.

Damit ließ sich ein Teil der internen Gateway-Arbeit von einem anderen Punkt des Netzes aus beobachten. Die Matrix zeigte, welche Kombinationen aus Quelle, Ziel und Protokoll das Gerät durchliefen; Verwerfungszähler konnten eine Fehlerklasse innerhalb des Gateways lokalisieren. Keiner dieser Werte bewies für sich, dass eine Anwendung eines Nutzers ihr Ziel erreichte. RFC 823 dokumentiert einen technischen Entwurf, keine unabhängige Zählung aller tatsächlich eingesetzten Gateways.

Der gemeinsame Teil war der Austausch, nicht das Gerätewörterbuch

Robert Hinden veröffentlichte RFC 869 im Dezember 1983 als Ersatz für die frühere Spezifikation IEN 197. HMP wird darin als verbindungsloses, transaktionsorientiertes Transportprotokoll beschrieben. Sein Header enthält unter anderem Systemtyp, Nachrichtentyp, Sequenznummer, ein Feld für Passwort oder zurückgelieferte Sequenznummer sowie eine Prüfsumme. System- und Nachrichtentyp legen gemeinsam fest, wie die Nutzdaten auszuwerten sind. Die Liste umfasst IMPs, Terminal Access Controller (TAC), Gateways und weitere Systeme; HMP verwendete die IP-Protokollnummer 20.

Der gemeinsame Rahmen machte Anfragen und Antworten erkennbar und zuordenbar. Er machte die Durchsatzzähler eines Gateways aber nicht zu einer universellen Beschreibung jedes Hosts. RFC 869 sagt, dass Nachrichtentypen je Systemtyp nach dessen Bedarf definiert werden. Die Anhänge führen Beispiele für IMP-, TAC- und Gateway-Nachrichten auf; die Einleitung stellt zugleich klar, dass diese Beispiele nicht Teil des HMP-Protokolls sind. Vereinheitlicht wurde, wie eine Zentrale fragen und eine Antwort zuordnen konnte. Was die Antwort bedeutete, bestimmte weiterhin das gerätespezifische Format.

Trap, Status und Statistik lieferten unterschiedliche Belege

RFC 869 verortete einen großen Teil der Überwachungslogik in der Zentrale. Der Host sammelte Daten und sandte sie auf Anfrage oder von sich aus; die Zentrale war dafür verantwortlich, angeforderte Daten korrekt zu erhalten. Status und Statistiken holte sie per Polling ab und konnte eine Anfrage nach Ablauf einer Frist wiederholen. Sequenznummern halfen, eine Antwort der Anfrage zuzuordnen und doppelte Statistikmeldungen zu erkennen. Statistikdaten blieben für ein Sammelintervall gespeichert, sodass eine verlorene Antwort erneut angefordert werden konnte.

Traps folgten einer anderen Regel. Trat ein Ereignis auf, sendete der Host ein Datagramm; HMP sah dafür aber weder Bestätigung noch erneute Übertragung vor. Ein Trap konnte schnell eintreffen, war jedoch kein garantiert vollständiges Ereignisprotokoll. Auch eine Statusmeldung hatte eine begrenzte Aussagekraft: Die Zentrale konnte aus Antworten auf ihre Polls ableiten, ob ein Host verfügbar war. Aus einer ausbleibenden Antwort ging nicht hervor, ob Host, Pfad, Anfrage oder Antwort ausgefallen war. Eine Antwort bewies umgekehrt nicht, dass ein Dienst höherer Ebene funktionierte.

Die Zentrale konnte den Host auch verändern

Ein Poll musste nicht nur Daten anfordern. RFC 869 erlaubte der Zentrale, Host-Parameter auszulesen oder Steuerdaten zu senden. Als Beispiele nennt das Dokument Schalter und Zeitgeber für Messungen sowie einen Neustartschalter zur Steuerung des Hosts. Das Gerät verarbeitete die Daten und sendete eine Steuerbestätigung zurück oder einen Fehler, falls es sie nicht verarbeiten konnte. Format und Bedeutung waren host-spezifisch. Die Bestätigung belegte den im Protokoll vorgesehenen Austausch; RFC 869 erklärt sie nicht zum Nachweis, dass ein nutzerseitiger Dienst danach funktionierte.

Die SNMP-Spezifikation RFC 1157 aus dem Jahr 1990 dient als Vergleich, nicht als Beleg für eine direkte HMP-Abstammung. RFC 1157 nennt das Simple Gateway Monitoring Protocol (SGMP) als Vorgänger von SNMP und beschreibt ein Modell zum Lesen und Ändern von Variablen mit einer begrenzten Zahl spontaner Meldungen. HMP ist eigenständig zu betrachten: Sein gemeinsamer Nachrichtenrahmen ließ unterschiedliche Geräte ihre eigenen Messwerte melden und typgebundene Steuerdaten entgegennehmen.

Die Liste der offiziellen Protokolle, RFC 840, stufte HMP im April 1983 als „Elective“ ein und vermerkte seinen Einsatz zur Überwachung von Internet-Gateways und TACs sowie zur Fehlersuche in Protokollimplementierungen auf kleinen entfernten Rechnern. Auch RFC 869 nennt Gateways und TACs als Einsatzgebiet; Implementierungen für weitere Hosts waren noch in Entwicklung. Das belegt einen begrenzten zeitgenössischen Einsatz, keine flächendeckende Verbreitung. Historisch aufschlussreich ist die gezogene Grenze: Der gemeinsame Nachrichtenaustausch ermöglichte Fernbeobachtung, doch die Bedeutung des Berichts blieb an den sendenden Host gebunden.

Quellen