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

[Nicolas Montavont <montavont@clarinet.u-strasbg.fr>]

Hi,

Bernard Aboba wrote:

 >>I agree that using several SSIDs on AP is a way to use an AP for
 >>different networks/operators.
 >>But my point was the fact that the specification does not deal with a
 >>single AP advertising several SSIDs.
 >>
 >>
 >
 >In many ways, IEEE 802.11-1999 does not define an AP at all.  For example,
 >it does not define the forwarding behavior of an AP or map it to the
 >bridging model of IEEE 802.1D.
 >
We agree on this point so far !

 >>Your second point is not possible. The BSSID is the identifier of the
 >>BSS and in infrastructure mode it is the MAC address of the AP. So when
 >>a single AP has several SSID, it always has a single BSSID.
 >>
 >>
 >
 >The problem is that many drivers cannot handle this.  They see one
 >adverisement, and store the capabilities.  Then they see another
 >advertisement originating from the same BSSID, with different
 >capabilities, and they over-write the initial advertisement, assuming that
 >the AP has been re-configured.
 >
Yes, this is normal behavior. But what we need to work in the context of
IETF is not to enhance L2 mechanism or specify how to have several VLANs
on APs, but try to understand and take advantage of the L2 operations to
enhance L3 movements, especially new link detection.

 >>That is why I say before that maybe a specification is needed to deal
 >>with this...
 >>
 >>
 >
 >Unfortunately, it's somewhat late, because millions of NICs and APs have
 >already shipped.  That means that there is a backward compatibility issue
 >with a number of otherwise seemingly reasonable approaches.
 >
Of course. But if you use different BSSID on a single AP, I think a
specification is needed to calculate the BSSID (as it is done in ad-hoc
mode).
  From the IETF point of view, and especially for the Link Hint
definition, it is not really important to know if AP advertising
different SSIDs is the same or not. As we said in
draft-yegin-dna-link-hint, as soon as one of the BSSID or the SSID
changes, we consider that we change L2 link. This is a hint that the L3
link should have changed too, but it is not guaranteed.

 >>I think that puting L3 information into L2 frames can be very relevant
 >>for mobility operation. As we (IETF) need this information, it could be
 >>good to work on this and have a consensus on what we need exactly. Then
 >>we can submit our request to IEEE as the result of our work.
 >>
 >>
 >
 >The problem is understanding the right L2 frames to include this
 >information in.  The Beacon and Probe Response are not secured, and also
 >are relatively early in the process so that they might not reflect the
 >actual VLAN that the station is assigned to.
 >
Right. I think there are two different ways to use L2 frames: to decide
and anticipate movement, and on the other hand to enhance new link
detection. In our draft, we focus on the new link detection and we
consider (Re) Association Response as Link Up hint. At this point
(association procedure), information on the MN about SSID and BSSID can
be trusted.

 >  So probably the best that
 >can be achieved in prior to association is to advertise *all* the prefixes
 >associated with a given BSSID.  This might be a single prefix (in the case
 >where the BSSID/SSID corresponds to a single VLAN) or it might be multiple
 >(in the case where the VLAN is dynamically assigned and can vary).  The
 >station can make its decision as to which AP to associate based on the
 >advertisements, but they are only a "hint" because it is possible that the
 >actual prefix to which the station is connected may not be the expected
 >one. The station will do a reachability test on the assumption that the
 >prefix is the expected one, but if this fails it must be prepared to
 >obtain an address by conventional means (DHCPv4, RS/RA, DHCPv6, etc.).
 >
This is for new L3 link decision/anticipation. It seems to me difficult
to let know a MN every prefixes associated to an AP. Assume a public
access (VLAN1) and a private access (VLAN2) on the same AP. The VLAN2
certainly doesn't want public people knows its network information.

Anyway, I don't see the interest to know all prefixes on an AP. For a
given MN, some prefixes will not be available. I think to put all
prefixes associated with an SSID can be introduced in Beacon and Probe
Response in order to enhance the choice of the link attachment. This
information should influence the choice of the next AP for a MN.

Nicolas