Hi -
> Then I saw the TODO list. I was recently interested in exploiting the capabilities of OSPF
> and was about to start experimenting on it. But I thought most of the work must have
> already been done until I saw 'OSPF modifications to handle 802.11 networks' and 'OSPF
> handling default routes via PPP' titles. Aren't those capabilities already implemented in
> the hundreds of commercial implementors of OSPF? What is so special about them? I think
> you must have some reason to list them so specifically
Well, starting with the 802.11 (wireless) networks. OSPF is currently
based on the assumption that all the hosts on a subnet are completely
reachable from all the other hosts on that subnet. That's fine for
Ethernet, but for wireless you can get into a situation where one host
is only reachable by sending traffic through another host. How to
handle this? One possibility (the obvious one, to me) is to use OSPF to
do what it's designed to do - detect network topology and route through
it. Exactly how to do it is a bit up in the air. Probably you need to
have OSPF running on all the hosts (not just the routers) on your
wireless LAN, and they need to ignore the subnet structure and act as if
there were point-to-point links between the hosts. Probably the whole
subnet should act as a sub-area; i.e, point-to-point links within the
subnet, but this gets summarized out to the rest of the network so all
everyone else sees is a single subnet.
As far as the default routes are concerned, that's mainly an operating
system issue. Linux routing support, in particular, is a bit weak. For
example, the only O/S routing primitives are "add route" and "delete
route" (and a few others), so if you kill your OSPF process, all its
routes stay in the routing table - you have to do a graceful shutdown to
have the process remove its routes. Generally, when you start the
routing process, it removes all the routes from the routing table (!) on
the assumption that they are "stale". That's fine if the routing
process is the only source of routing information, but in the case of
PPP you might get a default route that way, and it shouldn't be deleted
as a stale route. The latest thinking is that you have a Forwarding
Information Base (FIB) used to forward packets as well as multiple
Routing Information Bases (RIBs) constructed from the routing protocols
- an OSPF RIB, a PPP RIB, a static RIB configured by the administrator.
Then the FIB is constructed from the RIBs. This model explicitly allows
for multiple routing sources feeding in to your kernel routing table,
but it isn't well supported on UNIX.
UNIX in general needs a better management interface. I've been thinking
about SNMP as a generic UNIX management interface. Starting with the
kernel, you could make the routing table SNMP managable, then your OSPF
routing process could just use SNMP to install a RIB and tell the kernel
to import it into the FIB. Ultimately, it'd be nice if all the UNIX
system services were SNMP managable, then you could save the state of
your UNIX machine in a single file, instead of having all these
different config files spread all over /etc. You'd also be able to take
the running state of the UNIX system, snapshot it, and know that it
would return to that state when you restart - like "copy run start", if
you're familiar with Ciscos.
> What was the most impressive TODO list item was 'Wireless national data infrastructure'. I
> have been thinking on this line for several months.
The TODO list is out of date. I've finished the essay; it's in the
"papers and essays" section; I don't know if you read it.
> For example today's routers are dedicated computers where everything happens in the main
> processor and its memory and even the hard disk. If the same thing can happen in a small
> routing chip then it can be optimised at the signal level to the extent that recieving a
> bit and retransmitting it to the neighbor can be only separated by few cycles. If a
> complex thing like a DSP processor could designed why not a router chip with radio
> communication capability?
That's a pretty good idea. We basically do that with Ethernet and ATM
using switches, and DSP technology is pretty promising, so there's no
reason to think it couldn't happen.
I've got a couple of 802.11 wireless cards. They're nice, but clearly
limited, partly by their primitive design, partly by the restrictions
put on them by the FCC. In an environment with a lot of E-M
interference (i.e, a room full of computers), their range drops to about
30-40 meters. They need to do better than that to be really useful.
I figure hardware, not software, is driving this right now. Until we
have wireless hardware that can operate reliably up to a few kilometers
(cell phones do, so there's no reason why computers can't) the software
won't help. I'm thinking that an important next step is to write some
freely available E-M simulation software to help design microwave
circuitry. You can't design in the GHz range without it because the
normal low frequency electronic assumptions no longer apply, and all the
E-M design software I know of is proprietary and expensive. Having a
good E-M design program would open the door to ordinary people designing
the wireless hardware, so maybe then we'd get some better devices.
Looking over my email, it's got some pretty good ideas relating to
wireless, so I'm cc'ing it to my wireless mailing list/web page...
--
-bwb
Brent Baccala
baccala@freesoft.org
==============================================================================
For news from freesoft.org, subscribe to announce@freesoft.org:
mailto:announce-request@freesoft.org?subject=subscribe&body=subscribe
==============================================================================
This archive was generated by hypermail 2.1.0 : Tue May 22 2001 - 15:13:05 EDT