2. Operation (Betrieb)

Wenn ein Client für die Verwendung von RADIUS Accounting konfiguriert ist, erzeugt er zu Beginn der Dienstbereitstellung ein Accounting-Start-Paket (Accounting Start packet), das die Art des bereitgestellten Dienstes und den Nutzer beschreibt, dem der Dienst bereitgestellt wird, und sendet es an den RADIUS-Accounting-Server, der eine Bestätigung zurücksendet, dass das Paket empfangen wurde. Am Ende der Dienstbereitstellung erzeugt der Client ein Accounting-Stop-Paket (Accounting Stop packet), das die Art des gelieferten Dienstes und optional Statistiken wie verstrichene Zeit, ein- und ausgehende Oktette oder ein- und ausgehende Pakete beschreibt. Er sendet es an den RADIUS-Accounting-Server, der eine Bestätigung zurücksendet, dass das Paket empfangen wurde.

Die Accounting-Request (unabhängig davon, ob Start oder Stop) wird über das Netz an den RADIUS-Accounting-Server übermittelt. Es wird empfohlen, dass der Client weiterhin versucht, das Accounting-Request-Paket zu senden, bis eine Bestätigung empfangen wird, unter Verwendung einer Form des Backoff (Backoff). Wird innerhalb einer gewissen Zeit keine Antwort zurückgegeben, wird die Anfrage mehrfach erneut gesendet. Der Client kann Anfragen auch an einen alternativen Server oder alternative Server weiterleiten, falls der primäre Server ausfällt oder nicht erreichbar ist. Ein alternativer Server kann entweder nach einer Reihe fehlgeschlagener Versuche gegenüber dem primären Server oder im Round-Robin-Verfahren (round-robin fashion) verwendet werden. Retry- und Fallback-Algorithmen (Retry and fallback algorithms) sind Gegenstand laufender Forschung und werden in diesem Dokument nicht im Detail spezifiziert.

Der RADIUS-Accounting-Server KANN Anfragen an andere Server stellen, um die Anfrage zu erfüllen; in diesem Fall agiert er als Client.

Kann der RADIUS-Accounting-Server das Accounting-Paket nicht erfolgreich aufzeichnen, DARF er dem Client KEINE Accounting-Response-Bestätigung (Accounting-Response acknowledgment) senden.

2.1. Proxy (Proxy)

Informationen zu Proxy RADIUS finden Sie im „RADIUS"-RFC [2]. Proxy Accounting RADIUS funktioniert auf dieselbe Weise, wie das folgende Beispiel veranschaulicht.

1. Der NAS sendet eine accounting-request an den Forwarding Server (Weiterleitungsserver).

2. Der Forwarding Server protokolliert die accounting-request (falls gewünscht), fügt nach allen anderen Proxy-State-Attributen sein Proxy-State (falls gewünscht) hinzu, aktualisiert den Request Authenticator und leitet die Anfrage an den Remote-Server weiter.

3. Der Remote-Server protokolliert die accounting-request (falls gewünscht), kopiert alle Proxy-State-Attribute in der Reihenfolge und unverändert aus der Anfrage in das Antwortpaket und sendet die accounting-response an den Forwarding Server.

4. Der Forwarding Server entfernt das zuletzt hinzugefügte Proxy-State (falls er in Schritt 2 eines hinzugefügt hat), aktualisiert den Response Authenticator und sendet die accounting-response an den NAS.

Ein Forwarding Server DARF bestehende Proxy-State- oder Class-Attribute im Paket NICHT ändern.

Ein Forwarding Server kann seine Weiterleitungsfunktion entweder im Durchleitungsmodus (pass through manner) ausführen, bei dem er erneute Übertragungen (retransmissions) unverzöglich weiterleitet, sobald er sie erhält, oder er kann die Verantwortung für erneute Übertragungen übernehmen, zum Beispiel in Fällen, in denen die Netzverbindung zwischen Forwarding- und Remote-Server sehr andere Eigenschaften hat als die Verbindung zwischen NAS und Forwarding Server.

Bei der Implementierung eines Proxy-Servers, der die Verantwortung für erneute Übertragungen übernimmt, ist äußerste Sorgfalt geboten, damit seine Richtlinie für erneute Übertragungen robust und skalierbar ist.