9. Abrechnung (Accounting)

Dieses Abrechnungsprotokoll basiert auf einem servergesteuerten Modell (server directed model) mit Echtzeitfähigkeit für die Übermittlung von Abrechnungsinformationen. Mehrere Methoden zur Fehlertoleranz [RFC2975] sind in das Protokoll eingebaut, um den Verlust von Abrechnungsdaten in verschiedenen Fehlerszenarien und unter unterschiedlichen Annahmen über die Fähigkeiten der eingesetzten Geräte zu minimieren.

9.1. Servergesteuertes Modell (Server Directed Model)

Das servergesteuerte Modell bedeutet, dass das Gerät, das die Abrechnungsdaten erzeugt, vom Autorisierungsserver (falls kontaktiert) oder vom Abrechnungsserver Informationen darüber erhält, wie die Abrechnungsdaten weitergeleitet werden sollen. Dazu gehören Anforderungen an die Aktualität der Abrechnungsdatensätze.

Wie in [RFC2975] erläutert, ist die Echtzeitübertragung von Abrechnungsdatensätzen eine Anforderung, etwa für Kreditlimitprüfungen und Betrugserkennung. Stapelabrechnung ist keine Anforderung und wird von Diameter daher nicht unterstützt. Sollte künftig Stapelabrechnung erforderlich werden, müsste eine neue Diameter-Anwendung definiert oder ein anderes Protokoll verwendet werden. Beachten Sie jedoch, dass auch wenn auf der Diameter-Ebene Abrechnungsanfragen nacheinander verarbeitet werden, die darunter liegenden Transportprotokolle unter hoher Last typischerweise mehrere Anfragen im selben Paket bündeln. Für viele Anwendungen kann das ausreichen.

Die (Kette von) Autorisierungsservern steuert die Wahl der geeigneten Übertragungsstrategie auf Grundlage des Wissens über den Benutzer und Roaming-Partnerschaften. Der Server (oder Agenten) verwendet die AVPs Acct-Interim-Interval und Accounting-Realtime-Required, um den Diameter-Peer im Client-Betrieb zu steuern. Wenn Acct-Interim-Interval vorhanden ist, weist es den als Client agierenden Diameter-Knoten an, während einer Sitzung fortlaufend Abrechnungsdatensätze zu erzeugen. Accounting-Realtime-Required steuert das Verhalten des Clients, wenn die Übertragung von Abrechnungsdatensätzen vom Diameter-Client verzögert ausfällt oder fehlschlägt.

Der Diameter-Abrechnungsserver KANN das Intervall oder die Echtzeitanforderungen überschreiben, indem er Acct-Interim-Interval oder Accounting-Realtime-Required in der Accounting-Answer-Nachricht aufnimmt. Wenn eine dieser AVPs vorhanden ist, SOLL der zuletzt empfangene Wert für weitere Abrechnungsaktivitäten derselben Sitzung verwendet werden.

9.2. Protokollnachrichten (Protocol Messages)

Ein Diameter-Knoten, der eine erfolgreiche Authentifizierungs- und/oder Autorisierungsnachricht vom Diameter-Server erhält, SOLL Abrechnungsinformationen für die Sitzung sammeln. Die Accounting-Request-Nachricht überträgt die Abrechnungsinformationen an den Diameter-Server, der mit einer Accounting-Answer-Nachricht antworten MUSS, um den Empfang zu bestätigen. Die Accounting-Answer-Nachricht enthält die Result-Code-AVP, die anzeigen KANN, dass in der Abrechnungsnachricht ein Fehler vorlag. Der Wert der zuvor für die betreffende Sitzung empfangenen AVP Accounting-Realtime-Required kann anzeigen, dass die Benutzersitzung beendet werden muss, wenn eine abgelehnte Accounting-Request-Nachricht empfangen wurde.

9.3. Erweiterung und Anforderungen der Abrechnungsanwendung (Accounting Application Extension and Requirements)

Jede Diameter-Anwendung (z. B. NASREQ, Mobile IP) SOLL in einem Abschnitt mit dem Titel „Accounting AVPs“ ihre dienstspezifischen AVPs definieren, die in der Accounting-Request-Nachricht vorhanden sein MÜSSEN. Die Anwendung MUSS davon ausgehen, dass die in diesem Dokument beschriebenen AVPs in allen Abrechnungsnachrichten vorhanden sind, sodass in diesem Abschnitt nur die jeweiligen dienstspezifischen AVPs definiert werden müssen.

Anwendungen können eines oder beide der folgenden Erweiterungsmodelle nutzen:

Getrennter Abrechnungsdienst (Split Accounting Service)

Die Abrechnungsnachricht trägt die Application Id der Diameter-Basis-Abrechnungsanwendung (siehe Abschnitt 2.4). Abrechnungsnachrichten können an andere Diameter-Knoten als die zugehörige Diameter-Anwendung geroutet werden. Dies können zentrale Abrechnungsserver sein, die mehreren Diameter-Anwendungen dienen. Diese Knoten MÜSSEN die Application Id der Diameter-Basis-Abrechnung beim Capabilities Exchange ankündigen.

Gekoppelter Abrechnungsdienst (Coupled Accounting Service)

Die Abrechnungsnachricht trägt die Application Id der sie nutzenden Anwendung. Die Anwendung verarbeitet die empfangenen Datensätze selbst oder leitet sie an einen Abrechnungsserver weiter. Beim Capabilities Exchange ist keine gesonderte Ankündigung der Abrechnungsanwendung erforderlich, und Abrechnungsnachrichten werden wie andere Anwendungsnachrichten geroutet.

Wenn eine Anwendung keinen eigenen Abrechnungsdienst definiert, ist das Modell der getrennten Abrechnung vorzuziehen.

9.4. Fehlertoleranz (Fault Resilience)

Mechanismen des Diameter-Basisprotokolls beheben kleinen Nachrichtenverlust und vorübergehende Netzstörungen.

Diameter-Peers im Client-Betrieb MÜSSEN Failover implementieren, um Serverausfälle und bestimmte Netzausfälle abzufedern. Peers im Agenten-Betrieb oder zugehörige Offline-Systeme MÜSSEN doppelte Abrechnungsdatensätze erkennen, die durch Senden desselben Datensatzes an mehrere Server und durch Duplikation von Nachrichten unterwegs entstehen. Die Erkennung MUSS auf der Prüfung der Paare Session-Id und Accounting-Record-Number basieren. Anhang C behandelt Anforderungen und Implementierungsfragen zur Duplikaterkennung.

Diameter-Clients DÜRFEN nichtflüchtigen Speicher für die sichere Ablage von Abrechnungsdatensätzen über Neustarts, längere Netzausfälle, Netzpartitionen und Serverausfälle hinweg haben. Ist solcher Speicher vorhanden, SOLL der Client neue Datensätze dort ablegen, sobald sie erzeugt wurden, bis eine positive Empfangsbestätigung vom Diameter-Server vorliegt. Nach einem Neustart MUSS der Client die Datensätze im nichtflüchtigen Speicher unter geeigneter Anpassung von Beendigungsursache, Sitzungsdauer und anderen relevanten Feldern an den Abrechnungsserver senden.

Eine spätere Protokollerweiterung kann AVPs enthalten, die die maximale Anzahl von Abrechnungsdatensätzen begrenzen, die auf dem Client gespeichert werden dürfen, ohne sie im nichtflüchtigen Speicher zu bestätigen oder an den Diameter-Server zu übertragen.

Der Client SOLLTE Abrechnungsdaten nicht aus einem seiner Speicherbereiche entfernen, bevor die korrekte Accounting-Answer empfangen wurde. Der Client KANN die ältesten unzugestellten oder noch nicht bestätigten Daten entfernen, wenn Ressourcen wie Speicher erschöpft sind. Ob unter dieser Bedingung neue Sitzungen akzeptiert werden, ist implementationsabhängig.

9.5. Abrechnungsdatensätze (Accounting Records)

In allen Abrechnungsdatensätzen MUSS die AVP Session-Id vorhanden sein; die AVP User-Name MUSS vorhanden sein, wenn sie dem Diameter-Client zur Verfügung steht.

Je nach Art des abgerechneten Dienstes und den Vorgaben des Autorisierungsservers für Zwischenabrechnung werden unterschiedliche Datensatztypen gesendet. Handelt es sich um ein einmaliges Ereignis, bei dem Beginn und Ende gleichzeitig sind, MUSS die AVP Accounting-Record-Type vorhanden sein und den Wert EVENT_RECORD haben.

Hat der abgerechnete Dienst eine messbare Dauer, MUSS die AVP die Werte START_RECORD, STOP_RECORD und gegebenenfalls INTERIM_RECORD verwenden. Hat der Autorisierungsserver keine Zwischenabrechnung für die Sitzung aktiviert, MÜSSEN für jeden sitzungsartigen Dienst zwei Abrechnungsdatensätze erzeugt werden. Beim ersten Accounting-Request einer Sitzung MUSS Accounting-Record-Type START_RECORD sein. Beim letzten Accounting-Request MUSS der Wert STOP_RECORD sein.

Ist Zwischenabrechnung aktiviert, MUSS der Diameter-Client zusätzliche Datensätze zwischen START_RECORD und STOP_RECORD erzeugen, gekennzeichnet als INTERIM_RECORD. Ihre Erzeugung wird durch Acct-Interim-Interval sowie durch erneute Authentifizierung oder Autorisierung der Sitzung gesteuert. Der Diameter-Client MUSS zuvor lokal zwischengespeicherte Zwischenabrechnungsdatensätze überschreiben, wenn für dieselbe Sitzung ein neuer Datensatz erzeugt wird. So existiert pro Sitzung auf einem Zugriffsgerät höchstens ein ausstehender Zwischendatensatz.

Ein bestimmter Wert von Accounting-Sub-Session-Id DARF nur in einer Abfolge von Abrechnungsdatensätzen eines Diameter-Clients vorkommen, außer zu Retransmissionszwecken. Diese Abfolge MUSS entweder ein einzelner Datensatz mit Accounting-Record-Type EVENT_RECORD sein oder mehrere Datensätze, beginnend mit START_RECORD, gefolgt von null oder mehr INTERIM_RECORD und genau einem STOP_RECORD. Die jeweilige Diameter-Anwendungsspezifikation MUSS die zulässigen Abfolgetypen definieren.

9.6. Korrelation von Abrechnungsdatensätzen (Correlation of Accounting Records)

Verwendet eine Anwendung Abrechnungsnachrichten, kann sie Datensätze mit einer bestimmten Anwendungssitzung korrelieren, indem sie die Session-Id dieser Sitzung in den Nachrichten nutzt. Abrechnungsnachrichten KÖNNEN auch eine andere Session-Id als die Anwendungssitzungen verwenden; dann sind weitere sitzungsbezogene Informationen für die Korrelation nötig.

Benötigt eine Anwendung mehrere Abrechnungs-Untersitzungen, dient die AVP Accounting-Sub-Session-Id zur Unterscheidung. Die Session-Id bleibt für alle Untersitzungen gleich und verknüpft sie mit einer Anwendungssitzung. Ein STOP_RECORD ohne Accounting-Sub-Session-Id, obwohl in START_RECORD-Nachrichten Untersitzungen verwendet wurden, bedeutet, dass alle Untersitzungen beendet sind.

Es gibt Fälle, in denen mehrere Anwendungssitzungen in einem einzigen Abrechnungsdatensatz zusammengeführt werden; der Datensatz kann mehrere Diameter-Anwendungen und Sitzungen desselben Benutzers zu einem Zeitpunkt umfassen. Dazu dient die AVP Acct-Multi-Session-Id. Die AVP Acct-Multi-Session-Id SOLL vom Server an das Zugriffsgerät signalisiert werden (typischerweise bei der Autorisierung), wenn feststeht, dass eine Anfrage zu einer bestehenden Sitzung gehört. Das Zugriffsgerät MUSS Acct-Multi-Session-Id dann in allen folgenden Abrechnungsnachrichten aufnehmen.

Die AVP Acct-Multi-Session-Id KANN den ursprünglichen Session-Id-Wert enthalten. Der Inhalt ist implementationsabhängig, MUSS aber global eindeutig gegenüber allen anderen Acct-Multi-Session-Ids sein und während der Lebensdauer der Sitzung unverändert bleiben.

Ein Diameter-Anwendungsdokument MUSS den genauen Sitzungsbegriff der Abrechnung definieren und KANN den Multi-Session-Begriff definieren. Beispielsweise behandelt die NASREQ-DIAMETER-Anwendung eine einzelne PPP-Verbindung zu einem NAS als eine Sitzung und eine Menge von Multilink-PPP-Sitzungen als eine Multi-Session.

9.7. Abrechnungs-Befehlscodes (Accounting Command Codes)

Dieser Abschnitt definiert Befehlscode-Werte, die von allen Diameter-Implementierungen mit Abrechnungsdienst unterstützt werden MÜSSEN.

9.7.1. Accounting-Request

Der Befehl Accounting-Request (ACR), gekennzeichnet durch Befehlscode 271 und gesetztes „R“-Bit in den Befehlsflags, wird von einem als Client agierenden Diameter-Knoten gesendet, um Abrechnungsinformationen mit einem Peer auszutauschen.

Zusätzlich zu den unten aufgeführten AVPs SOLLEN Accounting-Request-Nachrichten dienstspezifische Abrechnungs-AVPs enthalten.

Nachrichtenformat (Message Format)

::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Destination-Host ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ Route-Record ]
    * [ AVP ]

9.7.2. Accounting-Answer

Der Befehl Accounting-Answer (ACA), gekennzeichnet durch Befehlscode 271 und gelöschtes „R“-Bit, bestätigt einen Accounting-Request. Er enthält dieselbe Session-Id wie die zugehörige Anfrage.

Nur der Ziel-Diameter-Server, der Home-Diameter-Server, SOLLTE mit Accounting-Answer antworten.

Zusätzlich zu den unten aufgeführten AVPs SOLLEN Accounting-Answer-Nachrichten dienstspezifische Abrechnungs-AVPs enthalten.

Nachrichtenformat (Message Format)

::= < Diameter Header: 271, PXY >
    < Session-Id >
    { Result-Code }
    { Origin-Host }
    { Origin-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    [ Failed-AVP ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ AVP ]

9.8. Abrechnungs-AVPs (Accounting AVPs)

Dieser Abschnitt enthält AVPs, die abrechnungsrelevante Nutzungsinformationen zu einer bestimmten Sitzung beschreiben.

9.8.1. Accounting-Record-Type AVP

Die AVP Accounting-Record-Type (AVP-Code 480) ist vom Typ Enumerated und enthält den Typ des gesendeten Abrechnungsdatensatzes. Folgende Werte sind definiert:

EVENT_RECORD 1

Ein Ereignisdatensatz kennzeichnet ein einmaliges Ereignis (Beginn und Ende gleichzeitig). Er enthält alle relevanten Serviceinformationen und ist der einzige Datensatz des Dienstes.

START_RECORD 2

Start-, Zwischen- und Stopp-Datensätze kennzeichnen einen Dienst messbarer Dauer. Ein Start-Datensatz beginnt eine Abrechnungssitzung und enthält Informationen zum Sitzungsbeginn.

INTERIM_RECORD 3

Ein Zwischendatensatz enthält kumulative Abrechnungsinformationen für eine bestehende Abrechnungssitzung. Zwischendatensätze SOLLEN bei jeder erneuten Authentifizierung oder Autorisierung gesendet werden. Weitere Auslöser KÖNNEN durch anwendungsspezifische Diameter-Anwendungen definiert werden. Die Verwendung von INTERIM_RECORD steuert die AVP Acct-Interim-Interval.

STOP_RECORD 4

Ein Stopp-Datensatz beendet die Abrechnungssitzung und enthält kumulative Informationen zur laufenden Sitzung.

9.8.2. Acct-Interim-Interval AVP

Die AVP Acct-Interim-Interval (AVP-Code 85) ist vom Typ Unsigned32 und wird vom Diameter-Home-Autorisierungsserver an den Diameter-Client gesendet. Der Client entscheidet anhand dieser AVP, wie und wann Datensätze erzeugt werden. Je nach Wert ergeben sich ein, zwei oder 2+N Datensätze pro Sitzung gemäß den Anforderungen der Home-Organisation. Folgendes Verhalten wird durch die AVP gesteuert:

Fehlt Acct-Interim-Interval oder ist das Value-Feld 0, werden je nach Dienst EVENT_RECORD, START_RECORD und STOP_RECORD erzeugt.
Ist das Value-Feld ungleich null, MÜSSEN zwischen START_RECORD und STOP_RECORD INTERIM_RECORD-Datensätze erzeugt werden. Das Value-Feld ist das nominale Intervall in Sekunden zwischen diesen Datensätzen. Der erzeugende Knoten (Client) MUSS den ersten INTERIM_RECORD etwa erzeugen, wenn seit START_RECORD das nominale Intervall vergangen ist, danach jeweils nach weiterem Ablauf des Intervalls, bis die Sitzung endet und STOP_RECORD gesendet wird.

Der Client MUSS die Zeiten der Zwischendatensätze randomisieren, damit keine großen Abrechnungsnachrichten-Stürme zwischen Datensätzen oder um gemeinsame Sitzungsstartzeiten entstehen.

9.8.3. Accounting-Record-Number AVP

Die AVP Accounting-Record-Number (AVP-Code 485) ist vom Typ Unsigned32 und identifiziert den Datensatz innerhalb einer Sitzung. Da Session-Ids global eindeutig sind, ist auch die Kombination aus Session-Id und Accounting-Record-Number global eindeutig und eignet sich zum Abgleich mit Bestätigungen. Einfache Zuordnung: 0 für EVENT_RECORD und START_RECORD, 1 für den ersten INTERIM_RECORD, 2 für den zweiten usw., STOP_RECORD um eins höher als der letzte INTERIM_RECORD.

9.8.4. Acct-Session-Id AVP

Die AVP Acct-Session-Id (AVP-Code 44) ist vom Typ OctetString und wird nur bei RADIUS/Diameter-Übersetzung verwendet. Sie enthält den Inhalt des RADIUS-Attributs Acct-Session-Id.

9.8.5. Acct-Multi-Session-Id AVP

Die AVP Acct-Multi-Session-Id (AVP-Code 50) ist vom Typ UTF8String gemäß Abschnitt 8.8. Sie verknüpft mehrere zusammengehörige Abrechnungssitzungen mit jeweils eindeutiger Session-Id aber gleicher Acct-Multi-Session-Id. Sie KANN vom Diameter-Server in einer Autorisierungsantwort zurückgegeben werden und MUSS in allen Abrechnungsnachrichten der Sitzung enthalten sein.

9.8.6. Accounting-Sub-Session-Id AVP

Die AVP Accounting-Sub-Session-Id (AVP-Code 287) ist vom Typ Unsigned64 und enthält den Bezeichner der Abrechnungs-Untersitzung. Die Kombination aus Session-Id und dieser AVP MUSS pro Untersitzung eindeutig sein, und der Wert MUSS für jede neue Untersitzung um eins monoton steigen. Fehlt die AVP, werden keine Untersitzungen verwendet, außer bei einer Accounting-Request mit Accounting-Record-Type STOP_RECORD. STOP_RECORD ohne Accounting-Sub-Session-Id signalisiert das Ende aller Untersitzungen für die gegebene Session-Id.

9.8.7. Accounting-Realtime-Required AVP

Die AVP Accounting-Realtime-Required (AVP-Code 483) ist vom Typ Enumerated und wird vom Diameter-Home-Autorisierungsserver an den Client oder in der Accounting-Answer vom Abrechnungsserver gesendet. Der Client entscheidet anhand dieser AVP, wie zu verfahren ist, wenn das Senden der Datensätze vorübergehend verhindert ist, z. B. durch ein Netzproblem.

DELIVER_AND_GRANT 1

Der Wert DELIVER_AND_GRANT bedeutet, dass der Dienst NUR gewährt werden DARF, solange eine Verbindung zu einem Abrechnungsserver besteht. Die Menge alternativer Abrechnungsserver gilt dabei als ein Server. Das Umlegen des Abrechnungsdatenstroms auf einen Backup-Server ist kein Grund, den Dienst zu beenden.

GRANT_AND_STORE 2

Der Wert GRANT_AND_STORE bedeutet, dass der Dienst gewährt werden SOLL, wenn eine Verbindung besteht oder solange Datensätze noch wie in Abschnitt 9.4 beschrieben gespeichert werden können.

Dies ist das Standardverhalten, wenn die AVP in der Antwort des Autorisierungsservers fehlt.

GRANT_AND_LOSE 3

Der Wert GRANT_AND_LOSE bedeutet, dass der Dienst gewährt werden SOLL, auch wenn Datensätze weder zugestellt noch gespeichert werden können.