Re: [DNA-BOF] BoF Last Call on DNA WG Charter.

[Bernard Aboba <aboba@internaut.com>]

> One is the physical link ID. This can be based on the access point ID in
> 802.11, SGSN ID in GPRS, RAN ID in 3GPP2.

802.11 does not have an access point ID.  It only has the BSSID but this
is not the same thing.  The difference become apparent when encountering
APs with multiple BSSIDs.  Many different designs now exhibit this -- such
as "dumb AP, smart switch" designs,  physical APs supporting "virtual AP"
capabilities, etc.

One of the consequences  of this is that a host can change points of
attachment and not know that it is connected to the same physical AP.

> In most of the cases, there is no
> one-to-one mapping between the physical link ID and the network-layer
> configuration parameters. This ID just identifies a physical association.

Indeed -- a single AP can offer access to multiple VLANs.

> The other is the network ID. For example, VLANID in 802.11, IP
> address/subnet obtained in PDP context in 3GPP or via PPP in 3GPP2. This
> identifies a logical association between the host and an IP subnet.
>
> Now, when a link-layer event (e.g., link up) takes place, it should be
> associated with a physical link ID and possibly with a network ID. Network
> ID is optional as this info might not be available all the time (e.g., when
> VLANID is not available).

If "link up" is defined correctly (e.g. the link is truly available for L3
usage) then the VLAN attachment needs to be defined at that point.
However, this is not the case in many implementation.  As a result, it is
possible to receive false "link up" events leading to potentially
incorrect conclusions about network attachment.  Yet another example of
why L2 indications need to be considered "hints".

> If a network ID is available, the host can quickly determine if it has
> changed subnet. If a network ID is not available, it has to play safe and
> perform network-layer discovery to detect if it needs to reconfigure.

So far the proposals that I've seen for transmission of the "network Id"
in L2 are really no better than "weak hints".  That is, they can
conceivably be wrong.  For example, a VLANID advertised in a Beacon or
Probe Response will not be valid if the VLANID is dynamically assigned as
proposed in [RFC3580].  The dynamic VLANID assignment occurs after
authentication (since it is sent in the AAA Accept), and possibly after
association, which is considered a "link up" event in some
implementations.  This means that VLANID can't always reliably be
communicated in the Association/Reassociation exchange either.