The Road to Version 1.0

We 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.

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

[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.

3495 reads