Zusammenfassung

  • Die experimentelle Architektur vom Januar 1997 verteilt die Belege: Der Manager bestimmt Regeln, der Meter zählt, der Reader hält tatsächlich ausgelesene Stände fest. RFC 2063, Abschnitte 2.1–2.4.
  • Bei einem reinen Reader-Ausfall können Gesamtmengen erhalten bleiben. Ausgefallene Zwischenablesungen hinterlassen dennoch eine Lücke im zeitlichen Nachweis. RFC 2063, Abschnitt 2.5.

Nach dem Neustart steht wieder eine Zahl da

In einem ausdrücklich hypothetischen Ablauf liefert ein Auslesedienst zunächst einen Zählerstand, fällt dann aus und kehrt später zurück. Die Messinstanz zählt währenddessen weiter. Gelten unveränderte Regeln, besteht derselbe Fluss fort und bleibt sein Zustand ohne mehrdeutigen Zählerüberlauf erhalten, ergibt die Differenz zum letzten gesicherten Stand die beobachtete Verkehrsmenge über die Lücke. Daraus lässt sich eine mittlere Rate über das gesamte Zeitfenster ableiten. Die Zwischenablesungen fehlen jedoch. Auch die Zeitpunkte des ersten und letzten Pakets verraten nicht, ob der Verkehr dazwischen gleichmäßig oder in kurzen Spitzen ankam. Diese Grenze der Rekonstruktion ist eine Folgerung aus fehlenden Beobachtungen, kein dokumentierter Störungsfall. RFC 2063, Abschnitte 2.5, 3.3 und 5.2.

Regeln, Zähler und Auslesebelege

RFC 2063 erschien im Januar 1997 unter den Namen Nevil Brownlee (The University of Auckland), Cyndi Mills (BBN Systems and Technologies) und Greg Ruth (GTE Laboratories, Inc.). Der Entwurf im Umfeld der IETF hatte den Status Experimental; er war weder Internetstandard noch Protokollspezifikation. Der Text gliederte die benötigten Informationen und Anforderungen und erörterte Abwägungen bei der Umsetzung. RFC 2063, Status und Abschnitt 1.

Ein Fluss ist hier eine künstliche logische Verkehrseinheit mit Anfang, Ende und Verantwortungszuordnung. Konfigurierte Regeln weisen ihr voneinander unabhängige IP-Pakete anhand beobachteter Merkmale zu. Diese Zuordnung kann Benutzer, Rechner, Netze oder Gruppen betreffen; sie authentifiziert keinen vertraglich zahlungspflichtigen Kunden. Im Zählschema gehört jedes erfasste Paket genau einem Fluss. Überlappende Auswertungen benötigen entsprechend fein getrennte Zählgruppen und Nachverarbeitung. RFC 2063, Abschnitte 2.1 und 3.3.

Die Messinstanz, der Meter, hält kumulierte Paket- und Bytezahlen sowie erste und letzte Paketzeiten. Der Auslesedienst, der Reader, transportiert Nutzungsdaten zuverlässig zur Analyse und speichert sie je Meter in Dateien: mit Meter-Identität, Zeitstempel, Kennung der Ausleseregeln, Flussmerkmalen und Zählern. Die Steuerung, der Manager, wählt Flussregeln, Auflösung, Inaktivitätsgrenzen und Stichproben; dem Reader gibt sie Messinstanz, Intervall, Auswahl und Attribute vor. Diese Rollen dürfen auf demselben Rechner liegen. RFC 2063, Abschnitte 2 und 5.2.

Die Rule Set ID gehört zur Deutung der Messdaten. Zusammen mit Flussbeginn und Kontext hilft sie, einen fortlaufenden Zählbestand von einem neu angelegten Eintrag mit gleichen Adressen zu unterscheiden. RFC 2063 bevorzugt weiterlaufende Zähler gegenüber einem Löschen beim Lesen. Ein späterer Stand kann deshalb fehlende Nutzungsdatensätze abdecken; mehrfach gelesene Summen dürfen nicht als zusätzliches Verkehrsaufkommen addiert werden. RFC 2063, Abschnitte 3.2–3.3.

Unabhängiges Auslesen ohne gemeinsamen Stichtag

Die Architektur erlaubt jederzeit ganze Tabellen, einzelne Zeilen oder Attribute auszulesen; gemeinsame Ablesezeitpunkte sind nicht erforderlich. Zwei Reader mit gleichem Intervall, aber verschiedener Phase liefern daher gewöhnlich abweichende Stände. Das allein belegt keinen Datenfehler. Zusätzliche Reader sichern die Kontinuität des Auslesens, zusätzliche Meter am selben Segment dagegen die Messung beim Ausfall einer Messinstanz. RFC 2063, Abschnitte 2.2 und 2.5.

Die ebenfalls experimentelle Meter-MIB vom Januar 1997 gestaltet Tabellenindizes zustandslos und nutzt TimeFilter sowie GetBulk für geänderte Zeilen oder Attribute. Ein Durchlauf beginnt mit dem Schreiben von flowReaderLastTime; dieser Startvermerk belegt keine atomare Momentaufnahme der ganzen Tabelle. Ein Regelsatzwechsel kann auf einem Meter eine Momentaufnahme annähern. flowReaderLastTime, flowReaderPreviousTime und die Reader-Registrierung helfen bei der Speicherfreigabe; flowReaderTimeout kann einen überfälligen Reader austragen. Misslingt das Schreiben oder seine Authentisierung, kann Lesen dennoch gelingen und die Freigabe blockiert bleiben. RFC 2064, Abschnitte 3.2 und 4, Objekte flowReaderInfoTable, flowReaderLastTime, flowReaderPreviousTime und flowReaderTimeout.

Dabei sieht RFC 2063 je Meter und Reader einen steuernden Manager vor; RFC 2064 unterscheidet bereits einen Master-Manager. Beide Aussagen gehören zu ihrem jeweiligen Dokumentstand. Architektur von 1997, zeitgenössische Meter-MIB.

Wie lange die Rückkehr noch hilft

Der Speicher setzt der Nachholung Grenzen. Nach RFC 2063 muss mindestens ein Reader einen inaktiven Fluss ausgelesen haben, bevor dessen Eintrag wiederverwendet wird. Bei mehreren Readern sollten die Betriebsverantwortlichen nach Abschnitt 4.5 eine Mindestanzahl auslesender Instanzen oder eine bestimmte Liste solcher Instanzen festlegen können, die die Flussdaten vor der Speicherfreigabe erfasst haben müssen. Diese Regelung bedurfte noch weiterer Ausarbeitung. LastCollectTime und Inaktivitätskontrolle bestimmen mit, wann Speicher wieder freigegeben werden kann. Bei hohem Füllstand nennt der Entwurf kürzere Ausleseintervalle oder einen gröberen Ersatzregelsatz; zum Weiterbetrieb kann kurzzeitig Messinformation verloren gehen. RFC 2063, Abschnitte 3.2, 4.5–4.6 und 5.3.

Ein Manager-Ausfall soll Messung und Auslesen weiterlaufen lassen. Vor einem kontrollierten Meter-Stopp kann eine letzte Erfassung angefordert werden; nach einem unkontrollierten Neustart können Meldung oder Abfrage die Wiederherstellung der Regeln anstoßen. Verlorenen Zustand oder unbeobachteten Verkehr stellt das Nachladen nicht wieder her. Die vorgeschlagenen Traps garantieren weder Zustellung noch authentisierte Belege. RFC 2063, Abschnitt 6.3.

Die als Informational veröffentlichte Revision RFC 2722 vom Oktober 1999 präzisiert später, dass vor einer Freigabe alle noch registrierten Reader ausgelesen haben müssen; ausgefallene Reader scheiden nach Ablauf ihrer Frist aus. Zwei identische, abwechselnd aktive Regelsätze auf einem Meter ermöglichen übereinstimmende Flussdaten des jeweils alten Satzes, ohne gleichzeitiges Umschalten mehrerer Meter zu garantieren. Diese spätere Fassung erlaubt auch parallele Regelsätze und Manager. Sie behält die Grenze zwischen Summenerhalt und verlorener Zeitauflösung bei. Ihre Präzisierungen dürfen nicht rückwirkend als Betriebseigenschaften von 1997 gelten. RFC 2722, Abschnitte 2.3, 2.5 und 4.5.

Quellen und Aussagegrenzen

Die Architektur von Januar 1997 erläutert Rollen und Abläufe; die zeitgenössische experimentelle Meter-MIB beschreibt die Verwaltungsobjekte zur Messdatenerfassung. Der amtliche Dokumenteintrag zu RFC 2063 führt den Status Experimental und die Ablösung durch RFC 2722. Die offizielle Errata-Abfrage liefert keine Treffer; Fehlerfreiheit folgt daraus nicht.

Die Architekturrevision vom Oktober 1999 und die spätere Meter-MIB desselben Monats dienen als spätere Vergleichsstände. Der Hintergrundbericht vom November 1991 erläutert die Trennung von Messarchitektur und Kostendeckungspolitik. Aus diesen Veröffentlichungen folgen keine Nachweise heutiger Verbreitung, Produktkompatibilität oder einer Entwicklungslinie zu NetFlow oder IPFIX.

RFC 2063 lässt Tarife und Kostendeckungsziele außerhalb seines Gegenstands; SNMP ist ein möglicher, nicht vorgeschriebener Transport. Integrität und Vertraulichkeit bleiben Aufgaben der Steuerungs- und Erfassungsprotokolle. Ein Messwert belegt für sich weder Abrechnungsberechtigung noch erfolgreiche Nutzdatenzustellung oder Zahlung. RFC 2063, Abschnitte 1, 5.3 und 10.

Lu Hengs späterer Beitrag über laufenden Code und Veröffentlichung liefert hier einen Deutungsrahmen: Ein publizierter Entwurf belegt noch keine beobachtete Umsetzung. Seine Überlegungen zu gemeinsamen Mindestregeln, lokalen Entscheidungen und freiwilliger Übernahme lenken den Blick auf gemeinsame Messsemantik und örtlich gewählte Betriebsbedingungen. Sein Beitrag zum redaktionellen Anspruch von BTW.Media begründet die Offenlegung von Struktur und Annahmen statt einer Lösungsempfehlung. Diese nachträglichen Perspektiven sind weder Funktionsnachweise noch Belege für politische Absichten der Autoren von 1997.