[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA-BOF] Using L2 to provide Instantaneous Movement Detection andNeighborhood Discovery



Title:
Hi Pekka,

Pekka Nikander wrote:
Bernard Aboba wrote:
That said, here are some issues that can arise from this proposal:

a. It assumes that the AP only offers access to a single network. APs
(like switches) are capable of supporting VLANs, in which case the AP can
offer access to multiple networks.  Which prefixes should it advertise in
this case?  If a network is advertised, can the host hearing the
advertisement then conclude it will be able to obtain access to that
network?

That's basically an operational issue.  We can't assume that all APs
will advertise prefixes ever, and therefore the clients must be
prepared to figure out the situation even then.  Some operational
guidance is needed, but IMHO nothing more.

Hence, I don't see that as a road block.  Personally, I think that
the *ability* for an AP to broadcast internetworking layer
configuration information would be great.
It would be great if the draft (or any proposal) can identify all possible scenario (e.g. VLAN) that the APs/stations will working in.
b. ...  This implies that advertisement in the Beacon and Probe
Response could be misleading.
Yes, this must be documented and the hosts must be prepared
for it.  If opti-DAD gets used, I don't see that as a problem,
though.  Some careful thinking is certainly needed.
Actually, how/when does a node determines that it must perform Opt-DAD, instead of the ordinary DAD?

For all these reasons, if prefix(es) are present in the Beacon and Probe
Response they need to be treated as *potential* networks to which the host
*might* be connected. This means that this particular advertisement would
act as a *weak* hint.

Agreed.  OTOH, maybe the advertisement itself could have a flag
that says
  - this AP does not provide any other upper layer configurations, or
  - this AP may provide also other upper layer configurations
Actually, the mobile node needs to check if the beacon frames (or probe request) contain an SPECIFIED element ID (TBD), as what I have proposed in the draft. Basically, an EXTENDED-beacon frame will look like this.

Beacon
|--- Frame Control
|--- Duration
|--- DestAddr
|--- SrcAddr
|--- SSID
|--- .....
|--- Extensible-App-IE (Element ID: TBD)
      |--- [ Network Prefix ]
      |--- [ AR Info ]
      |--- [Capabilities ]
|
|--- FCS


That would allow the advertisements to act both as weak or strong hints.



--Pekka Nikander