[CUWiN-Dev] CUWiN 1.0 wishlist?
David Young
dyoung at pobox.com
Tue Aug 9 18:48:08 CDT 2005
On Thu, Aug 04, 2005 at 12:16:11PM -0500, Bill Comisky wrote:
> Dave,
>
> I wanted to revisit the CUWiN 1.0 discussion. A number of things have
> been fixed, and things seem to be running fairly smoothly here.. good
> uptimes, haven't seen nodes dropping into the debugger, etc. I wanted to
> get a feel for where you think CUWiN is relative to a 1.0 release, what
> the blocking issues are, and what kind of timeline you expect to get from
> 0.5.8 to 1.0.
First, an update on 0.5.8: I will make a snapshot of my NetBSD sources
for 0.5.8. I believe your routeviz patches should go into 0.5.8; I will
commit those and pull them onto the 0.5.8 branch tonight.
I expect for us to go clear through 0.6, 0.7, 0.8, and 0.9 before we get
to 1.0. I don't expect for us to release 1.0 for a year or more. Before
the system goes to 1.0, hslsd needs to become more feature-complete, the
name service needs to be debugged and its feature-set needs to be more
comprehensive, and the web UI needs to let us set up multiple interfaces,
firewall and bandwidth-shaping, etc. We also need to improve the route
visualization. I also think we need to support more applications "out
of the box." Important optional features will include a SIP proxy and
a captive portal. All of this will take at least a year.
> I want to make sure we're directing our energy here on those issues needed
> to get to 1.0, and also to make sure we're testing/looking for the right
> things on our testbed. Also, I know we've been getting a lot of interest
> from different groups (community groups, potential strategic partners,
> etc). It'd be helpful to have ballpark dates to provide them, and also to
> help us plan for deployments, upgrades, etc.
The really important thing to test is the routing. Virtually everything
else rests on that. Here are some things to look for:
* router bootstrap: it is important that a node joining the
network gets a near-complete set of linkstates quickly.
There is a procedure whereby a node downloads its neighbors'
linkstates. I describe it in some document in doc/local/. [1]
* flooding: every new/changed linkstate should reach most routers
in the n-hop neighborhood within 2**(n+1) seconds.
(Note: I hedge by saying "most" because linkstates *will*
get lost on a wireless network. I expect the losses to be
mitigated by repeat transmissions of the same LSU, esp. on
networks of high nodal degree.)
* global flooding: every new/changed linkstate should reach most routers
in the *entire* network within 150 seconds
(hsls_router.c:default_global_ival) or 4 * 2**(netradius+1)
seconds, whichever is less.
* linkstate purging: a router should purge from its database any
linkstate that is not updated for 3 times the global flooding
period---i.e., 3 * 150 seconds
* database updates: a router should recompute its routing
table with Shortest Paths First every tick (4 seconds) that
follows the addition/change/deletion of a linkstate
* routing table: after recomputation, the routing table should
contain the least-metric routes to all destinations that are
reachable by traversing directed links in the UP condition
* RIB: following recomputation of the routing table,
hslsd should add/change/delete the same destination-nexthop
pairs in zebra as it adds/changes/deletes from its own
routing table
* FIB: zebra should load the routes from the RIB into the
kernel forwarding table
* default routes: if dhcpselect gets a DHCP lease from a gateway,
it should re-write the hslsd configuration so that hslsd
advertises a default route
Dave
[1] I will describe the procedure briefly here. Basically, a node says
"bootstrap me!" and its neighbors start unicasting their linkstate
databases to it. A node "echoes" each received linkstate so that its
neighbors know which ones have been successfully received. No neighbor
should send a linkstate to the "bootstrappee" that it has already heard
the bootstrappee echo. A neighbor tries up to three times to send
a linkstate to the bootstrappee before it gives up. Neighbors send
linkstates from distant routers before near routers (as measured by hop
count), they do not send any hopcount-1 linkstates before all of the
hopcount linkstates have been sent, and they do not send any linkstate to
a bootstrappee that has been updated since the initial bootstrap request.
--
David Young OJC Technologies
dyoung at ojctech.com Urbana, IL * (217) 278-3933
More information about the CU-Wireless-Dev
mailing list