[CUWiN-Dev] CUWiN 1.0 wishlist?

[David Young]

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