$Id: NOTES,v 1.6 1997/02/01 01:19:17 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.14.
On Solaris IPv6 package Release 5 and on INRIA IPv6 for FreeBSD 2.1, 
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) will be defined in 
"Advanced Sockets API for IPv6", draft-stevens-advanced-api-00.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 the configured tunnel should 
be implemented as a virtual 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.
