Zusammenfassung

  • Im Zustand PendingU erlaubt RETRY_AND_TERMINATE bei Ablauf von Tx den Dienst und lässt die Aktualisierungsanfrage offen. Ein späterer Sendefehler oder eine temporäre Fehlermeldung führt zur Beendigung.
  • Die tatsächlich geltende Regel kann eine lokale Einstellung überschreiben. Der Wechsel einer bestehenden Kreditkontrollsitzung zu einem anderen Server verlangt zudem Freigabe und Zustandsverwaltung, nicht nur Erreichbarkeit.

Eine erfolgreiche Antwort kann zu spät kommen, um die gesamte Betriebsgeschichte zu erzählen. Davor lag möglicherweise eine Zeitspanne, in der eine Kreditkontrollanfrage offen blieb, während der Dienst weiter erbracht wurde. Das ist hier keine Behauptung über einen konkreten Betreiber. Es ist eine im Diameter-Protokoll vorgesehene Möglichkeit, die eine reine Erfolgsquote am Ende der Anfrage nicht sichtbar macht.

Der betrachtete Fall ist eine bereits bestehende Sitzung. Ihr Client hat eine Aktualisierung angefordert und wartet in PendingU. Läuft unter RETRY_AND_TERMINATE der Anwendungstimer Tx ab, wird der Dienst gewährt und der Zustand bleibt PendingU. Erst ein späterer Sendefehler oder eine definierte temporäre Fehlermeldung bewirkt die Beendigung des Dienstes und den Wechsel nach Idle. Diese Unterscheidung steht in RFC8506, Abschnitt 7, Tabelle 4; Abschnitt 5.7 erläutert die zugehörigen Fehlerverfahren.

Damit wird aus der pauschalen Frage „offen oder geschlossen bei einem Ausfall?“ eine präzisere: Welches Ereignis beendet die Bereitschaft, weiter zu liefern? Der Name der Regel allein beantwortet sie nicht.

Der Ablauf einer Frist ist noch kein Ergebnis

Sitzungsbasierte Kreditkontrolle reserviert Einheiten, aktualisiert ihre Nutzung und schließt mit einer Verbrauchsmeldung ab. Einheiten können Zeit, Datenvolumen oder eine Dienstmenge darstellen; sie sind nicht zwangsläufig Geldbeträge. Abschnitt 5.3 sieht Zwischenanfragen unter anderem bei Verbrauch der Zuteilung, Ablauf ihrer Gültigkeit oder Änderungen relevanter Bedingungen vor. Eine vorgezogene Anfrage kann eine Unterbrechung vermeiden helfen.

Die vorläufige Dienstgewährung ist deshalb keine vom Client erfundene unbegrenzte Zuteilung. Bereits verwendete Einheiten zu melden und neue zu erhalten bleiben unterschiedliche Schritte. Nach der Meldung früheren Verbrauchs besitzt der Client nicht automatisch neue freigegebene Einheiten. Die Fehlerregel legt Verhalten innerhalb dieses Austauschs fest, kein allgemeines Recht auf kostenlose Nutzung.

Während die Aktualisierung offen ist, kann noch eine erfolgreiche Antwort eintreffen. Dann hält die Zustandsmaschine Tx an und kehrt nach Open zurück. „Sendefehler“ umfasst dagegen etwa die fehlende Kommunikation mit dem gewünschten und gegebenenfalls einem alternativen Ziel sowie das endgültige Ausbleiben einer Antwort innerhalb der Anfragefrist. Eine „temporäre Fehlermeldung“ bezeichnet eine Protokollkategorie; sie ist nicht bloß ein anderer Ausdruck für langsame Verarbeitung.

Wer diese Ereignisse unter einem einzigen Zeitüberschreitungsalarm zusammenfasst, entfernt genau die Information, die das zunächst fortsetzende und später beendende Verhalten erklärt. Das mag ein übersichtlicheres Dashboard ergeben, aber keine bessere Grundlage für die Bewertung des Risikos.

Abschnitt 13 empfiehlt zehn Sekunden für Tx. Daraus folgt weder die reale Einstellung eines bestimmten Netzes noch eine garantierte Obergrenze von zehn Sekunden für vorläufige Leistung. Validity-Time betrifft die Gültigkeit der Einheiten; die serverseitige Sitzungsüberwachung hat wiederum einen anderen Zweck. Mehrere Timer sind keine austauschbaren Beschreibungen derselben unternehmerischen Zusage.

Die Grenzen der Fortsetzung

Abschnitt 8.14 definiert TERMINATE, CONTINUE und RETRY_AND_TERMINATE. Fehlt das Attribut zur Fehlerbehandlung, gilt TERMINATE. In PendingU beendet diese Einstellung den Dienst beim Ablauf von Tx. Die anderen beiden erlauben ihn zunächst. Bei einem späteren Sendefehler oder temporären Fehler trennen sich ihre Wege: CONTINUE gewährt weiterhin Dienst, RETRY_AND_TERMINATE beendet ihn. Ein erneuter Versuch an einem anderen Ziel setzt außerdem unterstützten Failover und ein verfügbares Ausweichziel voraus.

Eine ausdrückliche Ablehnung wird dadurch nicht unverbindlich. Tabelle 4 verlangt bei END_USER_SERVICE_DENIED die Beendigung unabhängig von CCFH. Auch darf man die Tabelle für eine Aktualisierung nicht auf jede Erstanmeldung übertragen: Die erste Abfrage in Verbindung mit einer AA-Request besitzt eine eigene Zustandsmaschine und trennt bei Tx-Ablauf. Der RFC behandelt Kreditautorisierung; dienstspezifische Authentifizierung und Autorisierung liegen außerhalb seines Gegenstands. Die Kontinuitätsregel ist kein genereller Freibrief, diese zu umgehen.

Hinzu kommt die Herkunft der wirksamen Vorgabe. Nach Abschnitt 5.7 überschreibt der Wert des heimischen AAA-Servers die lokale Konfiguration; der Wert aus einer Antwort des Kreditkontrollservers ersetzt wiederum den vorhandenen Wert. Eine Prüfung muss deshalb feststellen, welche Regel zum Zeitpunkt des Übergangs tatsächlich galt und woher sie kam. Der dokumentierte lokale Standardwert ist dafür kein hinreichender Nachweis.

Ein erreichbarer Ersatz besitzt nicht automatisch den Zustand

Den Dienst während einer offenen Anfrage fortzusetzen ist etwas anderes, als den Kreditkontrollstrom einer laufenden Sitzung zu einem Ersatzserver zu verlagern. Für Letzteres ist gemäß den Abschnitten 5.7 und 8.4 CC-Session-Failover maßgeblich. Bei fehlendem Attribut gilt FAILOVER_NOT_SUPPORTED; der Nachrichtenstrom dieser Sitzung darf dann nicht auf einen alternativen Server verschoben werden. Ein Ersatzziel für eine neue Sitzung auszuwählen ist ein anderer Fall. Ebenso kann ein Peer-Wechsel auf dem Transportweg stattfinden und Duplikate erzeugen, ohne einen zustandsbehafteten Sitzungswechsel zu erlauben.

Für Implementierungen mit Sitzungs-Failover empfiehlt der RFC die Übertragung des Sitzungs- und Kontozustands zwischen primärem und sekundärem Server und verlangt die korrekte Erkennung doppelter sowie außerhalb der Reihenfolge eintreffender Nachrichten. Den Mechanismus der Kommunikation zwischen diesen Servern liefert er nicht. Session-Id und CC-Request-Number identifizieren eine Anfrage. Dass beide vorhanden sind, beweist keine korrekte Replikation von Reservierungen. Ein erfolgreicher Erreichbarkeitstest löst daher nur einen Teil der Aufgabe.

Auch die Verbrauchserfassung bleibt erforderlich. Abschnitt 5.7 empfiehlt einen Ersatzweg für Accounting-Daten. Das Beispiel mit CONTINUE und DELIVER_AND_GRANT setzt ausdrücklich deren Erfassung und Austausch mit dem Kreditkontrollserver voraus. Fortgesetzter Dienst bedeutet also weder kostenlose noch ungemessene Leistung und auch keinen nachgewiesenen finanziellen Verlust. Die abschließende Abfrage in Abschnitt 5.4 betrifft weiterhin Verbrauch und nicht genutzte Reservierungen. Umgekehrt beweist die Freigabe einer serverseitigen Reservierung allein nicht, dass der Client seine Leistung eingestellt hat.

Die Aussagekraft der Quelle bleibt begrenzt

Der offizielle Eintrag führt RFC8506 als Proposed Standard vom März 2019, der RFC4006 ersetzt. Die Errata-Suche lieferte bei der Prüfung am 8. September 2026 keine passenden Einträge. Das ist kein Nachweis für Verbreitung, Produktkonformität oder einen Vorfall. Es liegen hier weder Messwerte zu Betroffenen noch eine Grundlage für Verlustberechnungen vor.

Lu Hengs Text über Realität statt Interessenwerbung als Produkt gibt dafür eine redaktionelle Orientierung: erst den Mechanismus erklären, dann bewerten. Sein Essay zum Prinzipal-Agent-Problem in der Internet-Governance hilft, nach Entscheidungsrechten und Folgen zu fragen. Er belegt keine Motivation eines bestimmten Diameter-Teams. Der technische Befund ist enger: Eine offene Kreditentscheidung kann mit bereits erbrachter Leistung zusammenfallen.