$Id: NOTES,v 1.7 1997/03/21 09:11:13 masaki Exp $

----------------------------------
MRT Notes & Comments
----------------------------------

MRT is still a very rough experimental development base. The
goal/plan is to explore new technologies within MRT and
eventually feed them into more mature technologies (such as GateD
and other vendor implementations).

1) Thread architecture

MRT threads follow model of functional parallelism, where each
routing protocol instance, and routing information base (RIB) is
a separate thread. Each thread is scheduled by kernel with hints
from a controlling thread in MRT. Each thread maintains a FIFO
queue of events waiting to be processed.

In addition to protocol threads, MRT maintains user I/O threads,
a select socket thread and the main threads which handles timer
events.

2) IO Architecture

MRT is designed to allow different protocols to both run on
separate processors, and on separate machines. All MRT tools and
library understand common IPC language (via IO library). This is
still in the works...


----------------------------------
MRT Notes & Comments for IPV6
----------------------------------

The current version of MRT RIPng has been developed on Linux
2.1.24.  On Solaris IPv6 package Release 5, INRIA IPv6, and NRL
IPv6, some part of MRT RIPng doesn't work well due to lack of
functions needed by RIPng.  We are expecting those IPv6
implementations to follow both Basic and Advanced Socket API
being defined in IETF IPNG WG.

(1) Identify the incoming interface

RIPng has to use a link-local address to exchange routing
updates.  Since a link-local address doesn't include subnet
information, the kernel has to notify the routing daemon from
which interface the packet comes. This function (IPV6_RXINFO) has
been defined in "Advanced Sockets API for IPv6",
draft-stevens-advanced-api-01.txt.

(2) Multicasting over a configured tunnel

RIPng sends an update addressed to a multicast address (ff02::09)
even over a configured tunnel. The kernel has to support
multicasting over a configured tunnel; the kernel provides the
way to select the outgoing interface when multicasting. This
function (IPV6_MULTICAST_IF) is defined in "IPv6 Socket Interface
Extensions", draft-ietf-ipngwg-bsd-api-06.txt. Or, another
function equivalent (IPV6_TXINFO) should be provided. This
function as well as identifying the incoming interface above
implies that each configured tunnel should be implemented as a
virtual p-to-p interface in the kernel. Some IPv6 implementations
on the Unix system implements the configured tunnel as a route,
so they don't provide these essential functions.

(3) Source address selection

RIPng has to send out the update with a link-local source
address. The kernel should provides the way for the routing
daemon to specify the source address (IPV6_TXINFO), or
automatically select a link-local source address when sending out
to a link-local multicast address.
