Kacheong Poon writes:
> > What other splits does NWAM potentially need to know about? For
> > example, there's the split between VLANs and the link below: you can't
> > have the VLAN configured and usable without the link as well. And
> > there's the split between the link and the physical instance -- the
> > former might be an aggregation of multiple physical instances, each
> > with administrative issues.
>
>
> Is it pre or post Clearview UV support? I suppose after UV
> is done, everything should be clear :-) A VLAN is a data link
> and I assume the IP interface centric view we have now in the
> NWAM handling (e.g. we use IFF_RUNNING flag to check whether
> the underlying link is plugged in) should probably work fine.
The discussion has covered WiFi authentication, and has noted that we
need to split up the IPv4/IPv6 configuration from the underlying
"phyint" because the latter can have parameters and states that are
common to the two.
The potential problem is that this isn't actually the lowest level
object. The phyint is up at the VLAN level in the underlying
architecture. It's *not* the administrative unit that is used to
control (say) WEP keys.
> We may make NWAM depend on UV if it can make NWAM architecture
> simpler.
I don't see how doing so helps or hurts here.
> > Getting into 802.1X is what concerns me here. The authentication
> > issues there are at the lowest possible level -- they authenticate a
> > "wire" -- and many of the other structures are above that level. If
> > we treat 'link' as the lowest level, where it means both "thing that
> > IP can plumb" and "thing that 801.X protects," then NWAM can't
> > represent (for instance) VLANs.
>
>
> I do not know about the planned 802.1x support and how its
> administrative model works. Could you please elaborate and explain
> the issues? For example, suppose a vlan data link is created
> (assuming UV again). How does 802.1x fit in the picture?
802.1X is so-called "link authentication." (Sorry about the overload
on the word "link" -- it's IEEE's fault.) It's essentially the same
thing that's been discussed here in terms of WiFi profiles.
When "link authentication" is in use, it's the physical port that's
protected. This means that if you're using VLANs, those VLANs are all
constructed _above_ that port, and are all unavailable until (and
dependent on) that authentication process. If you're using
aggregation, then the membership in the bundle depends on successful
authentication (and, again, any VLANs that exist are above that bundle
level).
In other words, tying WiFi parameters to a "link name" makes sense
only if we can uniquely identify the link, and aren't naming something
(like a phyint) that could be a VLAN or aggregation.
> > (Another wrinkle is wireless operation where one could in theory
> > maintain associations with multiple APs ... but we can probably ignore
> > that.)
>
>
> Assuming the above actually works, I suppose we should follow
> the vlan model (they are quite similar) and create a data link
> for each of those associations.
No, they're not at all similar.
In the multiple AP case, you have a separate security association with
each AP. Thus, each of these looks like a separate physical port, not
like a separate VLAN, and in fact you could construct independent
VLANs atop _each_ association.
> > (I'd also shy away from the word "finishes" here. Scanning may never
> > finish. Instead, I think it'd be nice to have something that reports
> > interesting _changes_ in state. If some link layer designer wants to
> > say that his link has a "finish" state, that's fine, but I think NWAM
> > comes out as more flexible if it doesn't admit this.)
>
>
> I guess the word "finish" is chosen poorly. It is in the
> context of one single wireless scan, and such scan does finish.
> The scanning in the above paragraph is similar to the periodic
> scanning of wireless networks. That scanning is on-going. When
> applied to the wired NIC context, it can be a similar periodic
> "link info scanning."
I still think it'd be better to have the underlying link report state
changes than to have it report "finish."
> > Should EV_WIRELESS_NET or EV_LINK_INFO appear there somewhere --
> > perhaps going from NWAM_LINK_PLUMBED to NWAM_LINK_CONNECTED? (Or does
> > it implicitly just loop-to-self everywhere?)
>
>
> That event is generated by a separate thread doing the periodic
> scan as described in the writeup. So it is "missing" from the
> diagram. It is "looping."
OK.
> > How do we deal with configuration changes that don't involve
> > EV_IF_UP/EV_IF_DOWN?
>
>
> What are the other configuration changes we need to deal with?
I suppose that's my real question: is the link configuration frozen at
the point where the link is EV_IF_UP?
If it is, then I'm not certain how we'd deal with (say) switching from
one AP to another when the signal fades. Does it look like this?
- detect persistently better AP in periodic scanning
- force a disassociation from the current AP
- wait for EV_IF_DOWN from driver
- reselect new AP
- issue connection request for new AP
- wait for EV_IF_UP from driver
- deal with event by reconfiguring IP (et al.)
It might help (at least me) to have some scenario walk-throughs.
> > Is there something that performs the NWAM_IF_QUERYING function
> > essentially all the time? Or are we relying on external providers to
> > do that and deliver EV_SIGNAL?
>
>
> In the current design, there is no on-going info querying.
> For example, if NWAM decides that DHCP is used to control an
> interface, NWAM will rely on dhcpagent to mark an interface
> up/down. And the NWAM daemon listens on a routing socket for
> these events.
But the DHCP information can change over time -- that's why there's a
lease interval and a FORCERENEW message.
> > If it's the latter, then why not just rely on EV_SIGNAL all the time
> > rather than having a 'querying' state ... ?
>
>
> I think this tied to the above other configuration changes.
> Please list them and we can accommodate them in the design.
I'd like to know:
- How WiFi's authentication is represented versus VLANs and
aggregations.
- How NWAM deals with things that may change on their own over time
(e.g., WiFi signal strength and DHCP parameters) -- is it push or
pull?
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
