Section 4.3
On reading this section I am unsure about whether the discussion relates to failover between proxies or servers.
Suggested rewrite:
4.3. Fail-over with Status-Server
A client may wish to failover from one proxy to another in the event that it does not receive a
response to an Access-Request. In order to determine whether the lack of response is due to a
problem with the proxy or a downstream server, the client can send periodic Status-Server packets
to a proxy after lack of a response. The inter-packet period is Tw, as described in Section 4.1.
These packets will help the client determine if the failure was due to an issue on the path between
the client and proxy or the proxy itself, or whether the issue is occurring downstream.
If no response is received to Status-Server packets, the RADIUS client can initiate failover to
another proxy. By continuing to send Status-Server packets to the original proxy at an interval
of Tw, the RADIUS client can determine when the original proxy becomes responsive again.
Once three time periods have passed where Status-Server packets have
been sent and responded to, the original proxy should be deemed responsive
and RADIUS requests may sent to it again. This determination should
be made separately for each proxy that the client has a relationship
with. The same algorithm should be used for both authentication and
accounting ports. The client MUST treat each destination (ip, port)
combination as a unique proxy for the purposes of this
determination.
The above behavior is modelled after [RFC3539] Section 3.4.1. We
note that if a reliable transport is used for RADIUS, then the
algorithms specified in [RFC3539] MUST be used in preference to the
ones given here.
Section 5
You might want to add a table entry for User-Name.
|