2. Operation (動作)

2. Operation (動作)

クライアントが RADIUS Accounting の使用を構成している場合, サービス提供の開始時に, 提供されているサービスの種類とその対象利用者を記述する Accounting Start (アカウンティング開始) パケットを生成し, RADIUS アカウンティングサーバへ送信します. サーバはパケットを受信した旨の確認応答を返します. サービス提供の終了時には, クライアントは提供されたサービスの種類と, 任意で経過時間, 入出力オクテット数, または入出力パケット数などの統計を記述する Accounting Stop (アカウンティング停止) パケットを生成し, RADIUS アカウンティングサーバへ送信します. サーバはパケットを受信した旨の確認応答を返します.

Accounting-Request (開始または停止のいずれであっても) はネットワーク経由で RADIUS アカウンティングサーバに送られます. クライアントは, 何らかのバックオフを用いて, 確認応答を受信するまで Accounting-Request パケットの送信を試み続けることが推奨される. 一定時間内に応答が返らない場合, 要求は複数回再送されます. クライアントは, プライマリサーバがダウンしているか到達不能な場合に, 代替サーバへ要求を転送してもよい. 代替サーバは, プライマリへの試行が一定回数失敗した後に用いることも, ラウンドロビン方式で用いることもできます. 再試行およびフォールバックアルゴリズムは現在研究中の論題であり, この文書では詳細には規定しません.

RADIUS アカウンティングサーバは, 要求を満たすために他のサーバへ要求を行ってもよい. その場合, サーバはクライアントとして動作します.

RADIUS アカウンティングサーバがアカウンティングパケットの記録に成功できない場合, クライアントへ Accounting-Response の確認応答を送信してはならない.

2.1. Proxy (プロキシ)

Proxy RADIUS については "RADIUS" の RFC [2] を参照すること. Proxy Accounting RADIUS も同様に動作します. 次の例に示します.

1. NAS は forwarding server (転送サーバ) に accounting-request を送信する.

2. 転送サーバは (必要なら) accounting-request を記録し, 他の Proxy-State 属性の後に (必要なら) 自らの Proxy-State を追加し, Request Authenticator を更新し, 要求をリモートサーバへ転送する.

3. リモートサーバは (必要なら) accounting-request を記録し, 要求にあったすべての Proxy-State 属性を順序どおりかつ変更せずに応答パケットへコピーし, forwarding server に accounting-response を送る.

4. 転送サーバは (ステップ 2 で追加した場合) 最後の Proxy-State を取り除き, Response Authenticator を更新し, NAS に accounting-response を送る.

転送サーバは, パケット内に既に存在する Proxy-State または Class 属性を変更してはならない.

転送サーバは, 再送を受け取るたびにすぐ転送するパススルー方式で転送機能を実装してもよいし, 再送の責任を負う方式 (転送サーバとリモートサーバ間のリンク特性が NAS と転送サーバ間と大きく異なる場合など) を取ってもよい.

再送の責任を負うプロキシサーバを実装する際は, 再送方針が堅牢でスケーラブルになるよう, 極めて注意深くすべきである.