[Xorp-hackers] On-demand routing and XORP.

[Bruce M Simpson]

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Here's an idea I've been kicking around about implementing on-demand
routing protocols in XORP.

There is an XRL interface called fea_fib_client which is used to notify
observers about changes in the forwarding plane's FIB. Currently only
the fib2mrib process uses this, to pump routes from the unicast RIB
into the multicast RIB as needed.

However, this interface could be extended to propagate the lower-layer
notifications which on-demand routing protocols require as follows.

1. Add resolve_route[46] methods to the fea_fib_client interface.

   I've attached a diff for this. Extending the XIF is easy enough
   but the changes would result in the regeneration of various files,
   and the users of fea_fib_client need to implement stubs for the
   methods they don't implement.

2. Map the underlying notifications as follows at the FtiConfig layer.

   This is a bit more complicated, perhaps someone else can volunteer
   to fill in the blanks.

Linux uses the 'netlink socket' interface. The following events would
be mapped to method calls:

	RTN_RESOLVE	-> Not implemented within Linux at this time.

	RTN_UNREACHABLE	-> A single resolve_route call for the address
			   for which we're missing a route.

FreeBSD uses the PF_ROUTE interface. The following events would be
mapped to method calls:

	RTM_RESOLVE	-> A call to resolve_route and to add_route for
			   the cloned route (BSD derived stacks require
			   that the RTF_XRESOLVE and RTF_CLONING flags
			   be used together).

	RTM_MISS	-> A single resolve_route call for the address
			   for which we're missing a route.

I believe this mechanism is general enough to be extended to Click and
other forwarding planes.

What might also be useful is if we further extended the API to pass
Linux RTM_NEWLINK and BSD RTM_IFINFO messages which contain link-layer
information, but this is something which others might like to think
about. (Both Linux and BSD could benefit from some rethinking of their
FIB interfaces, but that's another story).

Regards,
BMS

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="resolve_route1.diff"

Index: fea_fib_client.xif
===================================================================
RCS file: /usr/local/www/data/cvs/xorp/xrl/interfaces/fea_fib_client.xif,v
retrieving revision 1.3
diff -u -p -r1.3 fea_fib_client.xif
--- fea_fib_client.xif	26 Oct 2004 01:29:51 -0000	1.3
+++ fea_fib_client.xif	27 Oct 2004 02:30:35 -0000
@@ -63,4 +63,16 @@ interface fea_fib_client/0.1 {
 	 */
 	delete_route4	? network:ipv4net & ifname:txt & vifname: txt
 	delete_route6	? network:ipv6net & ifname:txt & vifname: txt
+
+	/**
+	 * Notification of a route resolution request. This is issued
+	 * when the forwarding plane cannot find any route to a given
+	 * destination, even a candidate default.
+	 *
+	 * @param network the address of the destination.
+	 * forwarding plane requires a route to be resolved by the
+	 * upper layer.
+	 */
+	resolve_route4	? network:ipv4net
+	resolve_route6	? network:ipv6net
 }

--liOOAslEiF7prFVr--