Zusammenfassung

  • RFC 3423 gab Transportbestätigungen die Aufgabe, Paketverlust und nicht reagierende Server sichtbar zu machen; das CRANE DATA ACK reichte nur bis zum letzten lückenlos verarbeiteten Datensatz, dessen Abrechnungsinformation dauerhaft abgelegt war.
  • Selbst diese Grenze war keine fertige Rechnung. DSN-Vollständigkeit, Serverwechsel, Duplikatbereinigung, Template-Konfiguration, Kanalschutz und nachgelagerte Verarbeitung brauchten eigene Belege.

Der Absturz nach erfolgreicher Zustellung

Ein Netzelement sendet einen Nutzungsdatensatz. Der zuverlässige Transport bestätigt die Bytes. Dann fällt der Empfänger zwischen Verarbeitung und Commit aus. Die Netzanzeige kann zu Recht grün sein; die Aussage „Datensatz sicher“ wäre trotzdem unbelegt.

RFC 3423 machte genau diesen Zwischenraum zum Thema des Common Reliable Accounting for Network Element von XACCT Technologies. Der Klartext, die RFC-Editor-Seite, der Datatracker-Eintrag, seine Historie, die Referenzen und die Errata-Suche halten den Status fest: Informational, November 2002, kein Internet Standard und keine Messung heutiger Verbreitung.

CRANE sollte große Mengen von Abrechnungsdaten aus Netzelementen an Mediation, BSS und OSS liefern. Bemerkenswert ist weniger das Produkt als die Entscheidung, Zuverlässigkeit nicht als eine einzige Eigenschaft zu behandeln.

Der Transport führte kein Hauptbuch

Unter CRANE musste ein zuverlässiger, verbindungsorientierter und geordneter Transport liegen. TCP war möglich; das Dokument bevorzugte historisches SCTP aus RFC 2960, unter anderem wegen Nachrichtenorientierung und schneller Fehlererkennung. Diese Präferenz belegt keine reale Installation.

Transport-ACKs erkannten verlorene Pakete und nicht reagierende Server. CRANE bestätigte erst nach Verarbeitung der Nachricht und Ablage der Abrechnungsinformation in persistentem Speicher. Die erste Schicht kannte den Weg der Bytes; die zweite übernahm Verantwortung für Anwendungszustand.

RFC 2975 hatte nichtflüchtige Speicherung und Duplikateliminierung bereits als Teil des allgemeinen Accounting-Problems beschrieben. RFC 3423 gab dieser Trennung einen sichtbaren Protokollpunkt. Ein lebender Socket war kein Ersatz für einen haltbaren Datensatz.

Das DATA ACK markierte eine zusammenhängende Grenze

Jede DATA-Nachricht trug eine Data Sequence Number. Nach Start oder Serverwechsel setzte der Client im ersten Datensatz das S-Bit zur Synchronisation. Jeder neu erzeugte Datensatz erhöhte die DSN um eins. Der Server akzeptierte die Reihenfolge und verwarf Vorgriffe.

Im DATA ACK stand die DSN der letzten korrekt verarbeiteten Nachricht innerhalb einer lückenlosen Folge. War 3122 offen, durfte ein gesehenes 3123 die Grenze nicht verschieben. Der Empfänger wiederholte sein aktuelles ACK, um die fehlende Strecke erneut anzufordern.

Diese Aussage blieb bewusst klein. Sie besagte nichts über den richtigen Teilnehmer, Tarif, Rechnungsbetrag oder Zahlungseingang. Sie garantierte auch nicht ewigen Bestand des Speichers. Sie war eine zeitgebundene Behauptung eines bestimmten Empfängers.

Eine Folge konnte auf mehrere Empfänger verteilt sein

Eine Session durfte priorisierte redundante Server enthalten. Der Client wählte den höchstpriorisierten, den er für betriebsfähig hielt. War keiner verfügbar, warteten Datensätze lokal, bis ein Server zurückkehrte oder der Platz ausging; dann sollte ein Alarm entstehen.

Der Wechsel konnte aus einem nicht reagierenden Port, zu vielen unbestätigten Bytes über eine eingestellte Dauer, einem STOP oder der Rückkehr des bevorzugten Servers folgen. Das Protokoll stellte Signale bereit, ließ die genaue Umschaltlogik aber der Implementierung.

Das Zahlenbeispiel verteilt die Wahrheit: Server 1 erhält 3042–3095, Server 2 erhält 3096–3122, Server 1 übernimmt wieder ab 3123. Kein einzelner Empfänger besitzt alles. Der Client schuldet dem Mediation- oder Billing-System dennoch die vollständige Folge.

Wiederholung an einen anderen Server setzte das Duplicate-Bit. Das nachgelagerte System sollte DSN zur Deduplizierung nutzen. Das Bit war eine Warnung, kein Nachweis einer zweiten Kopie und kein Beleg ihrer Beseitigung.

Dauerhaft falsch interpretiert bleibt falsch

CRANE sparte Bandbreite durch ausgehandelte Templates. Sie beschrieben Reihenfolge, Typ und Bedeutung der Schlüssel; einzelne Schlüssel konnten aktiviert oder deaktiviert werden. Alle Server einer Session sollten denselben Satz und Zustand führen.

Jeder Datensatz enthielt Template ID und Configuration ID. Kurze Historie konnte alte Konfigurationen lesbar halten. Die Transportordnung sollte verhindern, dass eine zukünftige Konfiguration zu früh erscheint, und ein Templatewechsel sollte auf ACKs der alten Daten warten.

Jeder Server durfte einmal Änderungen vorschlagen. Der Client entschied den endgültigen Satz und verteilte FINAL TMPL DATA; danach mussten die Empfänger ohne weitere Änderung zustimmen. So endete die Schleife, und die Entscheidungsgewalt blieb sichtbar.

Persistente Bytes ohne passende Konfiguration können vollständig und zugleich bedeutungslos sein. Speicherkorrektheit und Schemakorrektheit sind nicht identisch.

Verwandte Protokolle, andere Verträge

Die Einleitung verglich RADIUS und Diameter. RFC 2865 beschreibt RADIUS-Zugang, RFC 2866 RADIUS Accounting. Diameter erschien in RFC 3588 und wurde durch RFC 6733 ersetzt. RFC 3334 behandelt Anforderungen an policybasiertes Accounting.

Spätere IPFIX-Dokumente geben Kontext zu Protokoll, Informationsmodell und Implementierung. Sie zeigen wiederkehrende Probleme, aber weder CRANE-Einsatz noch direkte Abstammung oder Interoperabilität.

Die normativen Wörter folgen RFC 2119. MUST belegt die Forderung des Textes, nicht die Ausführung eines Programms.

Sicherheit kam nicht mit dem ACK

RFC 3423 erklärte, dass CRANE selbst keine starke Vertraulichkeit oder Integrität bot. Statisch provisionierte Adressen ordneten Partner, blieben ohne zusätzlichen Schutz aber spoofbar. Je nach Umgebung wurden untere Dienste wie IPsec oder TLS empfohlen.

Ein DATA ACK authentifizierte somit nicht automatisch den Peer und belegte keine unveränderte Übertragung. Kanal, Identität, Berechtigung, Template, Speicherung und Geschäftsergebnis blieben eigenständige Prüfungen.

Quellen und Begrenzung

Die Methode nutzt außerdem Heng Lus Texte über Realitätsschichten und laufenden Code als Primärquelle. Spezifikation, Binärdatei, Konfiguration, Beobachtung, Speicher und Abrechnung sind verbundene, nicht austauschbare Zustände.

Die Quellen stützen Mechanik und Geschichte. Sie belegen keine heutige Nutzung, gemessene Leistung, benannten Vorfall, fortbestehendes Produkt oder Konformität einer konkreten Anlage.