Description of implementation

[Emmanuel Duros <eduros@chouette.inria.fr>]

Here is a summary of the INRIA proposal for the RIP modifications
to support UDLR.

We expect other implementation descriptions (WIDE project, Hugues
research lab) to start the discussion on which solution may be adopted
or what are the advantages/drawbacks of each solution, what can be
improved...


I) Description of the implementation presented at San Jose

RIPv2 messages are composed of a succession of 20 bytes segments. The
first segment may be an authentication segment. All other segments are
subnet-distance pairs. We propose to associate a specific password 
(authentication type = 2) with the satellite network. The handling of 
this authentication segment will be different by feeds and receivers.


*Handling by receivers

Upon reception of a RIP packet, receivers examine the authentication
segment. They note that this packet was sent by a satellite feed. They will
ignore all subnet-distance announces contained in this packet, but they
will add the source address of the packet [IP source] to the list of
"potential feeds".

At pseudo-regular intervals (random between 15 and 45 seconds), the
receivers will send to the potential feeds a RIP packet that will be
authenticated as a "satellite packet". This packet, however, will not be
sent to the regular multicast address of all the RIP routers. Instead, a
copy of this packet will be sent to the unicast address of each feed.

The IP source address of these routing messages is not set to the IP
address of the outgoing interface (by default the bidirectional
interface) but to the address of the interface which is connected to the
satellite network. Thus, feeds get the correct IP address of the
receivers as they receive the routing messages.

This procedure assumes that there is another route, beside the satellite
link, by which the receiver can send packets to the feed.


*processing by feeds

Processing of RIP packets by feeds is almost unchanged, except the
following :

- all packets sent over the multicast link are authenticated.
- all packets that are authenticated as satellite packets are
  processed even if they routed by another interface.


II) Preliminary discussion 

The way we modify routing daemons takes into account the unidirectional
feature of the link. We do know that receivers can not send routing
messages directly to feeds then we send them via regular connections. It
is the routing daemon that decides to re-route the messages because of
the unidirectional link. Would this be sufficient or a VIF approach
hiding at lower level the architecture of the network would be more
interesting (changes in routing daemons not required)?

Feeds are automatically detected by receivers and therefore there is no
complex management in each receiver, configuration files do not require
to define routes to feeds. Automatic configuration will be obviously
preferred. Otherwise, every time a new feed appears we need to define a
new route in each receiver.

A unidirectional link such as a satellite link can address a large
number of stations. If we have N feeds and M receivers, as we saw it
earlier, every receiver sends a routing message to every feed. Therefore,
we get periodically NxM routing messages in the Internet whatever the
approach (VIF or INRIA's). Would this be a real scaling problem, in what
proportion ? Sending the packets from the receivers to a "feeds" multicast
group reduce the "lots of feeds" problem. However, the problem would
probably be due to "lots of receivers". 


Emmanuel