RSPF meets the Route table quandary
- To: email@example.com
- Subject: RSPF meets the Route table quandary
- From: firstname.lastname@example.org (k1io, FN42jk)
- Date: Mon, 13 Jan 1992 17:59:20 -0500
Mike N1BEE and I have been discussing this, and I'll throw it out to the
assembled multitude before I release the RSPF2.2 spec to ftp. It's a
NOS implementation issue which may lead to a protocol change.
One of the things that RSPF does in order to cope with marginal packet
radio links is test routes. If an end-user is linked to the router via
a connectionless AX.25 link, then the router doesn't have any way of
knowing that the ES has gone away, or that the link has gone west.
Unlike, say, Ethernet, there's not much bandwidth to play with, and
flaky links are the rule. So RSPF currently "pings" ESs every so often
in order to see if they're still reachable.
Ping, however, gets to the real_subnet (that is, the AX.25 layer) via
IPROUTE. But the point of RSPF is to _create_ the IP routing table.
So in order to ping somebody, that somebody has to have the
subnet-in-question named as the path-of-choice in the NOS Route table.
But once it's in the Route table, its previous entry in that table is
lost. Yet the route to be pinged may not be the route of choice.
If there were a way to test routes without touching the Route table, it
would be easier. I rather like the way OSI treats IS-IS; it's not
_above_ the network layer, but _within_ it, so it can directly talk to
the real_subnet when needed. OSPF and RIP go so far as to put a
transport layer below the IGP; RPSF is an IGP that runs directly atop
IP, but still needs to go through IP.
One idea was to meddle directly in ARP. But I'm sure there are reasons
not to do that, not to mention non-ARP-using subnets. Suggestions?