Hi Bernard,
Bernard Aboba wrote:
Are you referring/proposing a new message exchange prior to the actual
Association message ? E.g. Pre-AssociationRequest (to obtain L3
information ON-DEMAND) ? I guess it is even harder to convince the
802.11 WG.
I'm just suggesting that this information has two (distinct) purposes:
a. To help the station make better roaming decisions;
b. To enable the station to optimize DNA.
In discussing the issue it's worth distinguishing which benefit is
desired. For example, in advertising prefixes in the Beacon/Probe
Response benefit a) is more easily achievable than b).
AFAIK, DNA provides a *fast & reliable* mechanism for a host to
determine if
it requires configuration upon arrival on a *new* link.
Besides (a), I'm sure that it (simply by looking at the advertised
prefix) can also aid DNA in determining if
*new* configuration info is required or not. There might be some
scenarios where this might not
work, and it is worthwhile to list these scenarios.
Even if the station perform association with a new AP, it can
potentially associate with another neighboring AP at the next 'seconds'.
Possible ?
Yes, if the roaming latency (L2 + L3) is sufficiently short. Otherwise
the station will spend more time roaming than sending packets.
In my draft, I proposed that mobile stations maintain a table of all its
neighborhood APs/ARs. For each AP (BSSID), MN can learn the network
prefix or other L3 information for this AP. Therefore, after L2 handover
is completed, MN should be able to tell IMMEDIATELY using this table if
it has moved again. Right ?
Sure -- but there are situations in which a client will not return to the
same AP.
same AP ? Can you clarify these a bit more ? Thanks.
Also, an AP can have many BSSIDs, so the client can "return"
without knowing it using this technique.
Is it possible (practically) for an AP to have multiple BSSID (MAC
addresses) ? Can you
share the scenarios with us ? Thanks.
|