Re: [DNA-BOF] Using L2 to provide Instantaneous MD & ND

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Paul,

Paul Tan wrote:
> Hi Greg,
> 
> thanks for your reply.
> 
> Please read my inline comments.
> 
> [LONGMAN DICTIONARY] rhetorical question -- a question that you ask as a 
> way of making a statement, without expecting an answer, such as `Who 
> knows what might happen?'
> 
> Cheers,
> Paul
> 
> Greg Daley wrote:
> 
>>> If the STA is going to perform a reachability test in any case,
>>> If the station have discovered the *prefix(es)* associated with an AP 
>>> earlier during its neighborhood discovery phase, and assuming that it 
>>> finally associates with this AP, do you think *reachability test* is 
>>> necessary ?
>>
>> I think it is necessary, because the configuration's presence
>> on the AP doesn't mean that the router is up, reachable or
>> working correctly.
> 
> True. Pardon me, I did not try to associate reachability with received 
> broadcast beacons.
> 
>> There's a WLAN accesspoint down the corridor from me which is
>> a black hole for people walking past it accepts their connections
>> and then doesn't route. Why? because there is no ethernet plugged in. 
> 
> Interesting!
> 
>> Also the reachability based on reception of broadcast beacons
>> is not sufficient to determine that the AP can hear your transmissions.
>> Probe-Request/Response may work, as will authentication,
>> but not passive beacon reception. 
> 
> AFAIK, in an infrastructure mode, station can communicate with the AP 
> which is always ONE-hop away. The link is always bi-directional, right ? 
> Beacons are broadcasted at a lower rate, thus travelled further. 
> Therefore, stations should be able to communicate (both ways) with AP.

The reachability is not bidirectional if the beacon
reaches the MN, and the MN transmits to the AP at
a higher rate for its packets.

Additionally, the transmission of the AR to MN is not
reflexive: That is, there may be a path of sufficient
quality from one to the other, but not the other way
around.

The MN's transmissions can get lost, even if beacons are
received.

Only if the MN can receive responses from the AP to
packets it transmits can we assume bidirectional
reachability is confirmed.

On top of this, we're actually not interested in
reachability with the AP, but through an AR.
This is possibly a different thing.

>>
>>>> what is the functionality of learning the possible prefixes?
>>>
>>> As I specified in my draft, the original purpose of these *advertised 
>>> prefix(es)* is to enhance Movement Detection operation. There might 
>>> be other possible use-cases ...can I pre-configure/verify a CoA (plus 
>>> DAD) for this prefix in advance or maybe *initialise* a fast-handoff 
>>> operation.
>>
>>
>> I don't think so.
>>
>> A lot of people have tried to get this (a way around DAD using
>> network state).  It's quite hard to do. 
> 
> Do you think it would be nice to have this capability ? Maybe, we did 
> not try hard enough. 8-)

Personally, I think Optimistic DAD is good enough.
If this is the case, there's no need to expend so
much effort on L2 solutions.

Greg